Skip to content
  1. Nov 02, 2022
    • Dmitry Vyukov's avatar
      nfc: Add KCOV annotations · 7e8cdc97
      Dmitry Vyukov authored
      
      
      Add remote KCOV annotations for NFC processing that is done
      in background threads. This enables efficient coverage-guided
      fuzzing of the NFC subsystem.
      
      The intention is to add annotations to background threads that
      process skb's that were allocated in syscall context
      (thus have a KCOV handle associated with the current fuzz test).
      This includes nci_recv_frame() that is called by the virtual nci
      driver in the syscall context.
      
      Signed-off-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: Bongsu Jeon <bongsu.jeon@samsung.com>
      Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7e8cdc97
    • Shailend Chand's avatar
      gve: Reduce alloc and copy costs in the GQ rx path · 82fd151d
      Shailend Chand authored
      
      
      Previously, even if just one of the many fragments of a 9k packet
      required a copy, we'd copy the whole packet into a freshly-allocated
      9k-sized linear SKB, and this led to performance issues.
      
      By having a pool of pages to copy into, each fragment can be
      independently handled, leading to a reduced incidence of
      allocation and copy.
      
      Signed-off-by: default avatarShailend Chand <shailend@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      82fd151d
    • Shane Parslow's avatar
      net: wwan: iosm: add rpc interface for xmm modems · d08b0f8f
      Shane Parslow authored
      
      
      Add a new iosm wwan port that connects to the modem rpc interface. This
      interface provides a configuration channel, and in the case of the 7360, is
      the only way to configure the modem (as it does not support mbim).
      
      The new interface is compatible with existing software, such as
      open_xdatachannel.py from the xmm7360-pci project [1].
      
      [1] https://github.com/xmm7360/xmm7360-pci
      
      Signed-off-by: default avatarShane Parslow <shaneparslow808@gmail.com>
      Reviewed-by: default avatarLoic Poulain <loic.poulain@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d08b0f8f
    • M Chetan Kumar's avatar
      net: wwan: t7xx: Add port for modem logging · 3349e4a4
      M Chetan Kumar authored
      
      
      The Modem Logging (MDL) port provides an interface to collect modem
      logs for debugging purposes. MDL is supported by the relay interface,
      and the mtk_t7xx port infrastructure. MDL allows user-space apps to
      control logging via mbim command and to collect logs via the relay
      interface, while port infrastructure facilitates communication between
      the driver and the modem.
      
      Signed-off-by: default avatarMoises Veleta <moises.veleta@linux.intel.com>
      Signed-off-by: default avatarM Chetan Kumar <m.chetan.kumar@linux.intel.com>
      Signed-off-by: default avatarDevegowda Chandrashekar <chandrashekar.devegowda@intel.com>
      Acked-by: default avatarRicardo Martinez <ricardo.martinez@linux.intel.com>
      Reviewed-by: default avatarSergey Ryazanov <ryazanov.s.a@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3349e4a4
    • M Chetan Kumar's avatar
      net: wwan: t7xx: use union to group port type specific data · fece7a8c
      M Chetan Kumar authored
      
      
      Use union inside t7xx_port to group port type specific data members.
      
      Signed-off-by: default avatarM Chetan Kumar <m.chetan.kumar@linux.intel.com>
      Reviewed-by: default avatarSergey Ryazanov <ryazanov.s.a@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fece7a8c
    • Eric Dumazet's avatar
      tcp: refine tcp_prune_ofo_queue() logic · b0e01253
      Eric Dumazet authored
      After commits 36a6503f ("tcp: refine tcp_prune_ofo_queue()
      to not drop all packets") and 72cd43ba
      
      
      ("tcp: free batches of packets in tcp_prune_ofo_queue()")
      tcp_prune_ofo_queue() drops a fraction of ooo queue,
      to make room for incoming packet.
      
      However it makes no sense to drop packets that are
      before the incoming packet, in sequence space.
      
      In order to recover from packet losses faster,
      it makes more sense to only drop ooo packets
      which are after the incoming packet.
      
      Tested:
      packetdrill test:
         0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
         +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
         +0 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [3800], 4) = 0
         +0 bind(3, ..., ...) = 0
         +0 listen(3, 1) = 0
      
         +0 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
         +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 0>
        +.1 < . 1:1(0) ack 1 win 1024
         +0 accept(3, ..., ...) = 4
      
       +.01 < . 200:300(100) ack 1 win 1024
         +0 > . 1:1(0) ack 1 <nop,nop, sack 200:300>
      
       +.01 < . 400:500(100) ack 1 win 1024
         +0 > . 1:1(0) ack 1 <nop,nop, sack 400:500 200:300>
      
       +.01 < . 600:700(100) ack 1 win 1024
         +0 > . 1:1(0) ack 1 <nop,nop, sack 600:700 400:500 200:300>
      
       +.01 < . 800:900(100) ack 1 win 1024
         +0 > . 1:1(0) ack 1 <nop,nop, sack 800:900 600:700 400:500 200:300>
      
       +.01 < . 1000:1100(100) ack 1 win 1024
         +0 > . 1:1(0) ack 1 <nop,nop, sack 1000:1100 800:900 600:700 400:500>
      
       +.01 < . 1200:1300(100) ack 1 win 1024
         +0 > . 1:1(0) ack 1 <nop,nop, sack 1200:1300 1000:1100 800:900 600:700>
      
      // this packet is dropped because we have no room left.
       +.01 < . 1400:1500(100) ack 1 win 1024
      
       +.01 < . 1:200(199) ack 1 win 1024
      // Make sure kernel did not drop 200:300 sequence
         +0 > . 1:1(0) ack 300 <nop,nop, sack 1200:1300 1000:1100 800:900 600:700>
      // Make room, since our RCVBUF is very small
         +0 read(4, ..., 299) = 299
      
       +.01 < . 300:400(100) ack 1 win 1024
         +0 > . 1:1(0) ack 500 <nop,nop, sack 1200:1300 1000:1100 800:900 600:700>
      
       +.01 < . 500:600(100) ack 1 win 1024
         +0 > . 1:1(0) ack 700 <nop,nop, sack 1200:1300 1000:1100 800:900>
      
         +0 read(4, ..., 400) = 400
      
       +.01 < . 700:800(100) ack 1 win 1024
         +0 > . 1:1(0) ack 900 <nop,nop, sack 1200:1300 1000:1100>
      
       +.01 < . 900:1000(100) ack 1 win 1024
         +0 > . 1:1(0) ack 1100 <nop,nop, sack 1200:1300>
      
       +.01 < . 1100:1200(100) ack 1 win 1024
      // This checks that 1200:1300 has not been removed from ooo queue
         +0 > . 1:1(0) ack 1300
      
      Suggested-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Acked-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
      Link: https://lore.kernel.org/r/20221101035234.3910189-1-edumazet@google.com
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      b0e01253
    • Dr. David Alan Gilbert's avatar
      net: core: inet[46]_pton strlen len types · 44827016
      Dr. David Alan Gilbert authored
      
      
      inet[46]_pton check the input length against
      a sane length limit (INET[6]_ADDRSTRLEN), but
      the strlen value gets truncated due to being stored in an int,
      so there's a theoretical potential for a >4G string to pass
      the limit test.
      Use size_t since that's what strlen actually returns.
      
      I've had a hunt for callers that could hit this, but
      I've not managed to find anything that doesn't get checked with
      some other limit first; but it's possible that I've missed
      something in the depth of the storage target paths.
      
      Signed-off-by: default avatarDr. David Alan Gilbert <linux@treblig.org>
      Link: https://lore.kernel.org/r/20221029014604.114024-1-linux@treblig.org
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      44827016
  2. Nov 01, 2022
  3. Oct 31, 2022