1. 01 Sep, 2022 6 commits
    • David Howells's avatar
      rxrpc: Remove rxrpc_get_reply_time() which is no longer used · 21457f4a
      David Howells authored
      Remove rxrpc_get_reply_time() as that is no longer used now that the call
      issue time is used instead of the reply time.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      21457f4a
    • David Howells's avatar
      afs: Use the operation issue time instead of the reply time for callbacks · 7903192c
      David Howells authored
      rxrpc and kafs between them try to use the receive timestamp on the first
      data packet (ie. the one with sequence number 1) as a base from which to
      calculate the time at which callback promise and lock expiration occurs.
      
      However, we don't know how long it took for the server to send us the reply
      from it having completed the basic part of the operation - it might then,
      for instance, have to send a bunch of a callback breaks, depending on the
      particular operation.
      
      Fix this by using the time at which the operation is issued on the client
      as a base instead.  That should never be longer than the server's idea of
      the expiry time.
      
      Fixes: 78107055 ("afs: Fix calculation of callback expiry time")
      Fixes: 2070a3e4 ("rxrpc: Allow the reply time to be obtained on a client call")
      Suggested-by: default avatarJeffrey E Altman <jaltman@auristor.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      7903192c
    • David Howells's avatar
      rxrpc: Fix calc of resend age · 214a9dc7
      David Howells authored
      Fix the calculation of the resend age to add a microsecond value as
      microseconds, not nanoseconds.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      214a9dc7
    • David Howells's avatar
      rxrpc: Fix local destruction being repeated · d3d86303
      David Howells authored
      If the local processor work item for the rxrpc local endpoint gets requeued
      by an event (such as an incoming packet) between it getting scheduled for
      destruction and the UDP socket being closed, the rxrpc_local_destroyer()
      function can get run twice.  The second time it can hang because it can end
      up waiting for cleanup events that will never happen.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      d3d86303
    • David Howells's avatar
      rxrpc: Fix an insufficiently large sglist in rxkad_verify_packet_2() · 0d40f728
      David Howells authored
      rxkad_verify_packet_2() has a small stack-allocated sglist of 4 elements,
      but if that isn't sufficient for the number of fragments in the socket
      buffer, we try to allocate an sglist large enough to hold all the
      fragments.
      
      However, for large packets with a lot of fragments, this isn't sufficient
      and we need at least one additional fragment.
      
      The problem manifests as skb_to_sgvec() returning -EMSGSIZE and this then
      getting returned by userspace.  Most of the time, this isn't a problem as
      rxrpc sets a limit of 5692, big enough for 4 jumbo subpackets to be glued
      together; occasionally, however, the server will ignore the reported limit
      and give a packet that's a lot bigger - say 19852 bytes with ->nr_frags
      being 7.  skb_to_sgvec() then tries to return a "zeroth" fragment that
      seems to occur before the fragments counted by ->nr_frags and we hit the
      end of the sglist too early.
      
      Note that __skb_to_sgvec() also has an skb_walk_frags() loop that is
      recursive up to 24 deep.  I'm not sure if I need to take account of that
      too - or if there's an easy way of counting those frags too.
      
      Fix this by counting an extra frag and allocating a larger sglist based on
      that.
      
      Fixes: d0d5c0cd ("rxrpc: Use skb_unshare() rather than skb_cow_data()")
      Reported-by: default avatarMarc Dionne <marc.dionne@auristor.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: linux-afs@lists.infradead.org
      0d40f728
    • David Howells's avatar
      rxrpc: Fix ICMP/ICMP6 error handling · ac56a0b4
      David Howells authored
      Because rxrpc pretends to be a tunnel on top of a UDP/UDP6 socket, allowing
      it to siphon off UDP packets early in the handling of received UDP packets
      thereby avoiding the packet going through the UDP receive queue, it doesn't
      get ICMP packets through the UDP ->sk_error_report() callback.  In fact, it
      doesn't appear that there's any usable option for getting hold of ICMP
      packets.
      
      Fix this by adding a new UDP encap hook to distribute error messages for
      UDP tunnels.  If the hook is set, then the tunnel driver will be able to
      see ICMP packets.  The hook provides the offset into the packet of the UDP
      header of the original packet that caused the notification.
      
      An alternative would be to call the ->error_handler() hook - but that
      requires that the skbuff be cloned (as ip_icmp_error() or ipv6_cmp_error()
      do, though isn't really necessary or desirable in rxrpc's case is we want
      to parse them there and then, not queue them).
      
      Changes
      =======
      ver #3)
       - Fixed an uninitialised variable.
      
      ver #2)
       - Fixed some missing CONFIG_AF_RXRPC_IPV6 conditionals.
      
      Fixes: 5271953c ("rxrpc: Use the UDP encap_rcv hook")
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      ac56a0b4
  2. 30 Aug, 2022 2 commits
  3. 29 Aug, 2022 3 commits
    • David S. Miller's avatar
      Merge branch 'u64_stats-fixups' · cb10b0f9
      David S. Miller authored
      Sebastian Andrzej Siewior says:
      
      ====================
      net: u64_stats fixups for 32bit.
      
      while looking at the u64-stats patch
      	https://lore.kernel.org/all/20220817162703.728679-10-bigeasy@linutronix.de
      
      I noticed that u64_stats_fetch_begin() is used. That suspicious thing
      about it is that network processing, including stats update, is
      performed in NAPI and so I would expect to see
      u64_stats_fetch_begin_irq() in order to avoid updates from NAPI during
      the read. This is only needed on 32bit-UP where the seqcount is not
      used. This is address in 2/2. The remaining user take some kind of
      precaution and may use u64_stats_fetch_begin().
      
      I updated the previously mentioned patch to get rid of
      u64_stats_fetch_begin_irq(). If this is not considered stable patch
      worthy then it can be ignored and considred fixed by the other series
      which removes the special 32bit cases.
      
      The xrs700x driver reads and writes the counter from preemptible context
      so the only missing piece here is at least disable preemption on the
      writer side to avoid preemption while the writer is in progress. The
      possible reader would spin then until the writer completes its write
      critical section which is considered bad. This is addressed in 1/2 by
      using u64_stats_update_begin_irqsave() and so disable interrupts during
      the write critical section.
      The other closet resemblance I found is mdio_bus.c::mdiobus_stats_acct()
      where preemtion is disabled unconditionally. This is something I want to
      avoid since it also affects 64bit.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cb10b0f9
    • Sebastian Andrzej Siewior's avatar
      net: Use u64_stats_fetch_begin_irq() for stats fetch. · 278d3ba6
      Sebastian Andrzej Siewior authored
      On 32bit-UP u64_stats_fetch_begin() disables only preemption. If the
      reader is in preemptible context and the writer side
      (u64_stats_update_begin*()) runs in an interrupt context (IRQ or
      softirq) then the writer can update the stats during the read operation.
      This update remains undetected.
      
      Use u64_stats_fetch_begin_irq() to ensure the stats fetch on 32bit-UP
      are not interrupted by a writer. 32bit-SMP remains unaffected by this
      change.
      
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Catherine Sullivan <csully@google.com>
      Cc: David Awogbemila <awogbemila@google.com>
      Cc: Dimitris Michailidis <dmichail@fungible.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: Jeroen de Borst <jeroendb@google.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Paolo Abeni <pabeni@redhat.com>
      Cc: Simon Horman <simon.horman@corigine.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-wireless@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Cc: oss-drivers@corigine.com
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      278d3ba6
    • Sebastian Andrzej Siewior's avatar
      net: dsa: xrs700x: Use irqsave variant for u64 stats update · 3f8ae9fe
      Sebastian Andrzej Siewior authored
      xrs700x_read_port_counters() updates the stats from a worker using the
      u64_stats_update_begin() version. This is okay on 32-UP since on the
      reader side preemption is disabled.
      On 32bit-SMP the writer can be preempted by the reader at which point
      the reader will spin on the seqcount until writer continues and
      completes the update.
      
      Assigning the mib_mutex mutex to the underlying seqcount would ensure
      proper synchronisation. The API for that on the u64_stats_init() side
      isn't available. Since it is the only user, just use disable interrupts
      during the update.
      
      Use u64_stats_update_begin_irqsave() on the writer side to ensure an
      uninterrupted update.
      
      Fixes: ee00b24f ("net: dsa: add Arrow SpeedChips XRS700x driver")
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: George McCollister <george.mccollister@gmail.com>
      Cc: Vivien Didelot <vivien.didelot@gmail.com>
      Cc: Vladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Acked-by: default avatarGeorge McCollister <george.mccollister@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3f8ae9fe
  4. 27 Aug, 2022 7 commits
  5. 26 Aug, 2022 2 commits
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 2e085ec0
      David S. Miller authored
      Daniel borkmann says:
      
      ====================
      The following pull-request contains BPF updates for your *net* tree.
      
      We've added 11 non-merge commits during the last 14 day(s) which contain
      a total of 13 files changed, 61 insertions(+), 24 deletions(-).
      
      The main changes are:
      
      1) Fix BPF verifier's precision tracking around BPF ring buffer, from Kumar Kartikeya Dwivedi.
      
      2) Fix regression in tunnel key infra when passing FLOWI_FLAG_ANYSRC, from Eyal Birger.
      
      3) Fix insufficient permissions for bpf_sys_bpf() helper, from YiFei Zhu.
      
      4) Fix splat from hitting BUG when purging effective cgroup programs, from Pu Lehui.
      
      5) Fix range tracking for array poke descriptors, from Daniel Borkmann.
      
      6) Fix corrupted packets for XDP_SHARED_UMEM in aligned mode, from Magnus Karlsson.
      
      7) Fix NULL pointer splat in BPF sockmap sk_msg_recvmsg(), from Liu Jian.
      
      8) Add READ_ONCE() to bpf_jit_limit when reading from sysctl, from Kuniyuki Iwashima.
      
      9) Add BPF selftest lru_bug check to s390x deny list, from Daniel Müller.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2e085ec0
    • David S. Miller's avatar
      Merge tag 'wireless-2022-08-26' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless · 4ba9d38b
      David S. Miller authored
      Johannes Berg says:
      
      ====================
      pull-request: wireless-2022-08-26
      
      Here are a couple of fixes for the current cycle,
      see the tag description below.
      
      Just a couple of fixes:
       * two potential leaks
       * use-after-free in certain scan races
       * warning in IBSS code
       * error return from a debugfs file was wrong
       * possible NULL-ptr-deref when station lookup fails
      
      Please pull and let me know if there's any problem.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4ba9d38b
  6. 25 Aug, 2022 20 commits