1. 01 Jun, 2020 1 commit
  2. 29 May, 2020 4 commits
  3. 28 May, 2020 1 commit
  4. 20 May, 2020 3 commits
  5. 18 May, 2020 4 commits
    • Abhishek Pandit-Subedi's avatar
      Bluetooth: hci_qca: Enable WBS support for wcn3991 · a228f7a4
      Abhishek Pandit-Subedi authored
      WCN3991 supports transparent WBS (host encoded mSBC). Add a flag to the
      device match data to show WBS is supported.
      
      This requires the matching firmware for WCN3991 in linux-firmware:
              1a8b0dc00f77 (qca: Enable transparent WBS for WCN3991)
      Signed-off-by: default avatarAbhishek Pandit-Subedi <abhishekpandit@chromium.org>
      Reviewed-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      a228f7a4
    • Hsin-Yu Chao's avatar
      Bluetooth: Add SCO fallback for invalid LMP parameters error · 56b5453a
      Hsin-Yu Chao authored
      Bluetooth PTS test case HFP/AG/ACC/BI-12-I accepts SCO connection
      with invalid parameter at the first SCO request expecting AG to
      attempt another SCO request with the use of "safe settings" for
      given codec, base on section 5.7.1.2 of HFP 1.7 specification.
      
      This patch addresses it by adding "Invalid LMP Parameters" (0x1e)
      to the SCO fallback case. Verified with below log:
      
      < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
              Handle: 256
              Transmit bandwidth: 8000
              Receive bandwidth: 8000
              Max latency: 13
              Setting: 0x0003
                Input Coding: Linear
                Input Data Format: 1's complement
                Input Sample Size: 8-bit
                # of bits padding at MSB: 0
                Air Coding Format: Transparent Data
              Retransmission effort: Optimize for link quality (0x02)
              Packet type: 0x0380
                3-EV3 may not be used
                2-EV5 may not be used
                3-EV5 may not be used
      > HCI Event: Command Status (0x0f) plen 4
            Setup Synchronous Connection (0x01|0x0028) ncmd 1
              Status: Success (0x00)
      > HCI Event: Number of Completed Packets (0x13) plen 5
              Num handles: 1
              Handle: 256
              Count: 1
      > HCI Event: Max Slots Change (0x1b) plen 3
              Handle: 256
              Max slots: 1
      > HCI Event: Synchronous Connect Complete (0x2c) plen 17
              Status: Invalid LMP Parameters / Invalid LL Parameters (0x1e)
              Handle: 0
              Address: 00:1B:DC:F2:21:59 (OUI 00-1B-DC)
              Link type: eSCO (0x02)
              Transmission interval: 0x00
              Retransmission window: 0x02
              RX packet length: 0
              TX packet length: 0
              Air mode: Transparent (0x03)
      < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
              Handle: 256
              Transmit bandwidth: 8000
              Receive bandwidth: 8000
              Max latency: 8
              Setting: 0x0003
                Input Coding: Linear
                Input Data Format: 1's complement
                Input Sample Size: 8-bit
                # of bits padding at MSB: 0
                Air Coding Format: Transparent Data
              Retransmission effort: Optimize for link quality (0x02)
              Packet type: 0x03c8
                EV3 may be used
                2-EV3 may not be used
                3-EV3 may not be used
                2-EV5 may not be used
                3-EV5 may not be used
      > HCI Event: Command Status (0x0f) plen 4
            Setup Synchronous Connection (0x01|0x0028) ncmd 1
              Status: Success (0x00)
      > HCI Event: Max Slots Change (0x1b) plen 3
              Handle: 256
              Max slots: 5
      > HCI Event: Max Slots Change (0x1b) plen 3
              Handle: 256
              Max slots: 1
      > HCI Event: Synchronous Connect Complete (0x2c) plen 17
              Status: Success (0x00)
              Handle: 257
              Address: 00:1B:DC:F2:21:59 (OUI 00-1B-DC)
              Link type: eSCO (0x02)
              Transmission interval: 0x06
              Retransmission window: 0x04
              RX packet length: 30
              TX packet length: 30
              Air mode: Transparent (0x03)
      Signed-off-by: default avatarHsin-Yu Chao <hychao@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      56b5453a
    • Łukasz Rymanowski's avatar
      Bluetooth: Fix for GAP/SEC/SEM/BI-10-C · 49c06c9e
      Łukasz Rymanowski authored
      Security Mode 1 level 4, force us to use have key size 16 octects long.
      This patch adds check for that.
      
      This is required for the qualification test GAP/SEC/SEM/BI-10-C
      
      Logs from test when ATT is configured with sec level BT_SECURITY_FIPS
      
      < ACL Data TX: Handle 3585 flags 0x00 dlen 11                                                                       #28 [hci0] 3.785965
            SMP: Pairing Request (0x01) len 6
              IO capability: DisplayYesNo (0x01)
              OOB data: Authentication data not present (0x00)
              Authentication requirement: Bonding, MITM, SC, No Keypresses (0x0d)
              Max encryption key size: 16
              Initiator key distribution: EncKey Sign (0x05)
              Responder key distribution: EncKey IdKey Sign (0x07)
      > ACL Data RX: Handle 3585 flags 0x02 dlen 11                                                                       #35 [hci0] 3.883020
            SMP: Pairing Response (0x02) len 6
              IO capability: DisplayYesNo (0x01)
              OOB data: Authentication data not present (0x00)
              Authentication requirement: Bonding, MITM, SC, No Keypresses (0x0d)
              Max encryption key size: 7
              Initiator key distribution: EncKey Sign (0x05)
              Responder key distribution: EncKey IdKey Sign (0x07)
      < ACL Data TX: Handle 3585 flags 0x00 dlen 6                                                                        #36 [hci0] 3.883136
            SMP: Pairing Failed (0x05) len 1
              Reason: Encryption key size (0x06)
      Signed-off-by: default avatarŁukasz Rymanowski <lukasz.rymanowski@codecoup.pl>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      49c06c9e
    • Gustavo A. R. Silva's avatar
      Bluetooth: L2CAP: Replace zero-length array with flexible-array · 631512f8
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      sizeof(flexible-array-member) triggers a warning because flexible array
      members have incomplete type[1]. There are some instances of code in
      which the sizeof operator is being incorrectly/erroneously applied to
      zero-length arrays and the result is zero. Such instances may be hiding
      some bugs. So, this work (flexible-array member conversions) will also
      help to get completely rid of those sorts of issues.
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavoars@kernel.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      631512f8
  6. 17 May, 2020 10 commits
    • John Hubbard's avatar
      rds: convert get_user_pages() --> pin_user_pages() · dbfe7d74
      John Hubbard authored
      This code was using get_user_pages_fast(), in a "Case 2" scenario
      (DMA/RDMA), using the categorization from [1]. That means that it's
      time to convert the get_user_pages_fast() + put_page() calls to
      pin_user_pages_fast() + unpin_user_pages() calls.
      
      There is some helpful background in [2]: basically, this is a small
      part of fixing a long-standing disconnect between pinning pages, and
      file systems' use of those pages.
      
      [1] Documentation/core-api/pin_user_pages.rst
      
      [2] "Explicit pinning of user-space pages":
          https://lwn.net/Articles/807108/
      
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: netdev@vger.kernel.org
      Cc: linux-rdma@vger.kernel.org
      Cc: rds-devel@oss.oracle.com
      Signed-off-by: default avatarJohn Hubbard <jhubbard@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dbfe7d74
    • David S. Miller's avatar
      Merge branch 'mptcp-do-not-block-on-subflow-socket' · 9740a7ae
      David S. Miller authored
      Florian Westphal says:
      
      ====================
      mptcp: do not block on subflow socket
      
      This series reworks mptcp_sendmsg logic to avoid blocking on the subflow
      socket.
      
      It does so by removing the wait loop from mptcp_sendmsg_frag helper.
      
      In order to do that, it moves prerequisites that are currently
      handled in mptcp_sendmsg_frag (and cause it to wait until they are
      met, e.g. frag cache refill) into the callers.
      
      The worker can just reschedule in case no subflow socket is ready,
      since it can't wait -- doing so would block other work items and
      doesn't make sense anyway because we should not (re)send data
      in case resources are already low.
      
      The sendmsg path can use the existing wait logic until memory
      becomes available.
      
      Because large send requests can result in multiple mptcp_sendmsg_frag
      calls from mptcp_sendmsg, we may need to restart the socket lookup in
      case subflow can't accept more data or memory is low.
      
      Doing so blocks on the mptcp socket, and existing wait handling
      releases the msk lock while blocking.
      
      Lastly, no need to use GFP_ATOMIC for extension allocation:
      extend __skb_ext_alloc with gfp_t arg instead of hard-coded ATOMIC and
      then relax the allocation constraints for mptcp case: those requests
      occur in process context.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9740a7ae
    • Florian Westphal's avatar
      net: allow __skb_ext_alloc to sleep · 4930f483
      Florian Westphal authored
      mptcp calls this from the transmit side, from process context.
      Allow a sleeping allocation instead of unconditional GFP_ATOMIC.
      Acked-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4930f483
    • Florian Westphal's avatar
      mptcp: remove inner wait loop from mptcp_sendmsg_frag · 5c826443
      Florian Westphal authored
      previous patches made sure we only call into this function
      when these prerequisites are met, so no need to wait on the
      subflow socket anymore.
      
      Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/7Acked-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5c826443
    • Florian Westphal's avatar
      mptcp: fill skb page frag cache outside of mptcp_sendmsg_frag · 17091708
      Florian Westphal authored
      The mptcp_sendmsg_frag helper contains a loop that will wait on the
      subflow sk.
      
      It seems preferrable to only wait in mptcp_sendmsg() when blocking io is
      requested.  mptcp_sendmsg already has such a wait loop that is used when
      no subflow socket is available for transmission.
      
      This is another preparation patch that makes sure we call
      mptcp_sendmsg_frag only if the page frag cache has been refilled.
      
      Followup patch will remove the wait loop from mptcp_sendmsg_frag().
      
      The retransmit worker doesn't need to do this refill as it won't
      transmit new mptcp-level data.
      Acked-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      17091708
    • Florian Westphal's avatar
      mptcp: fill skb extension cache outside of mptcp_sendmsg_frag · 149f7c71
      Florian Westphal authored
      The mptcp_sendmsg_frag helper contains a loop that will wait on the
      subflow sk.
      
      It seems preferrable to only wait in mptcp_sendmsg() when blocking io is
      requested.  mptcp_sendmsg already has such a wait loop that is used when
      no subflow socket is available for transmission.
      
      This is a preparation patch that makes sure we call
      mptcp_sendmsg_frag only if a skb extension has been allocated.
      
      Moreover, such allocation currently uses GFP_ATOMIC while it
      could use sleeping allocation instead.
      
      Followup patches will remove the wait loop from mptcp_sendmsg_frag()
      and will allow to do a sleeping allocation for the extension.
      Acked-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      149f7c71
    • Florian Westphal's avatar
      mptcp: avoid blocking in tcp_sendpages · 72511aab
      Florian Westphal authored
      The transmit loop continues to xmit new data until an error is returned
      or all data was transmitted.
      
      For the blocking i/o case, this means that tcp_sendpages() may block on
      the subflow until more space becomes available, i.e. we end up sleeping
      with the mptcp socket lock held.
      
      Instead we should check if a different subflow is ready to be used.
      
      This restarts the subflow sk lookup when the tx operation succeeded
      and the tcp subflow can't accept more data or if tcp_sendpages
      indicates -EAGAIN on a blocking mptcp socket.
      
      In that case we also need to set the NOSPACE bit to make sure we get
      notified once memory becomes available.
      
      In case all subflows are busy, the existing logic will wait until a
      subflow is ready, releasing the mptcp socket lock while doing so.
      
      The mptcp worker already sets DONTWAIT, so no need to make changes there.
      
      v2:
       * set NOSPACE bit
       * add a comment to clarify that mptcp-sk sndbuf limits need to
         be checked as well.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      72511aab
    • Florian Westphal's avatar
      mptcp: break and restart in case mptcp sndbuf is full · fb529e62
      Florian Westphal authored
      Its not enough to check for available tcp send space.
      
      We also hold on to transmitted data for mptcp-level retransmits.
      Right now we will send more and more data if the peer can ack data
      at the tcp level fast enough, since that frees up tcp send buffer space.
      
      But we also need to check that data was acked and reclaimed at the mptcp
      level.
      
      Therefore add needed check in mptcp_sendmsg, flush tcp data and
      wait until more mptcp snd space becomes available if we are over the
      limit.  Before we wait for more data, also make sure we start the
      retransmit timer if we ran out of sndbuf space.
      
      Otherwise there is a very small chance that we wait forever:
      
       * receiver is waiting for data
       * sender is blocked because mptcp socket buffer is full
       * at tcp level, all data was acked
       * mptcp-level snd_una was not updated, because last ack
         that acknowledged the last data packet carried an older
         MPTCP-ack.
      
      Restarting the retransmit timer avoids this problem: if TCP
      subflow is idle, data is retransmitted from the RTX queue.
      
      New data will make the peer send a new, updated MPTCP-Ack.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fb529e62
    • Florian Westphal's avatar
      mptcp: move common nospace-pattern to a helper · a0e17064
      Florian Westphal authored
      Paolo noticed that ssk_check_wmem() has same pattern, so add/use
      common helper for both places.
      Suggested-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a0e17064
    • David Ahern's avatar
      selftests: Drop 'pref medium' in route checks · eb682677
      David Ahern authored
      The 'pref medium' attribute was moved in iproute2 to be near the prefix
      which is where it applies versus after the last nexthop. The nexthop
      tests were updated to drop the string from route checking, but it crept
      in again with the compat tests.
      
      Fixes: 4dddb5be ("selftests: net: add new testcases for nexthop API compat mode sysctl")
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Cc: Roopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb682677
  7. 16 May, 2020 17 commits