1. 02 10月, 2018 1 次提交
    • D
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · c8424ddd
      David S. Miller 提交于
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter fixes for net
      
      The following patchset contains Netfilter fixes for your net tree:
      
      1) Skip ip_sabotage_in() for packet making into the VRF driver,
         otherwise packets are dropped, from David Ahern.
      
      2) Clang compilation warning uncovering typo in the
         nft_validate_register_store() call from nft_osf, from Stefan Agner.
      
      3) Double sizeof netlink message length calculations in ctnetlink,
         from zhong jiang.
      
      4) Missing rb_erase() on batch full in rbtree garbage collector,
         from Taehee Yoo.
      
      5) Calm down compilation warning in nf_hook(), from Florian Westphal.
      
      6) Missing check for non-null sk in xt_socket before validating
         netns procedence, from Flavio Leitner.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c8424ddd
  2. 30 9月, 2018 14 次提交
  3. 29 9月, 2018 19 次提交
    • D
      Merge branch 'netpoll-second-round-of-fixes' · f13d1b48
      David S. Miller 提交于
      Eric Dumazet says:
      
      ====================
      netpoll: second round of fixes.
      
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC).
      
      This capture, showing one ksoftirqd eating all cycles
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      It seems that all networking drivers that do use NAPI
      for their TX completions, should not provide a ndo_poll_controller() :
      
      Most NAPI drivers have netpoll support already handled
      in core networking stack, since netpoll_poll_dev()
      uses poll_napi(dev) to iterate through registered
      NAPI contexts for a device.
      
      First patch is a fix in poll_one_napi().
      
      Then following patches take care of ten drivers.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f13d1b48
    • E
      ibmvnic: remove ndo_poll_controller · 0c3b9d1b
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      ibmvnic uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      
      ibmvnic_netpoll_controller() was completely wrong anyway,
      as it was scheduling NAPI to service RX queues (instead of TX),
      so I doubt netpoll ever worked on this driver.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
      Cc: John Allen <jallen@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c3b9d1b
    • E
      sfc-falcon: remove ndo_poll_controller · a4f570be
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      sfc-falcon uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Solarflare linux maintainers <linux-net-drivers@solarflare.com>
      Cc: Edward Cree <ecree@solarflare.com>
      Cc: Bert Kenward <bkenward@solarflare.com>
      Acked-By: NBert Kenward <bkenward@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a4f570be
    • E
      sfc: remove ndo_poll_controller · 9447a10f
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      sfc uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Edward Cree <ecree@solarflare.com>
      Cc: Bert Kenward <bkenward@solarflare.com>
      Cc: Solarflare linux maintainers <linux-net-drivers@solarflare.com>
      Acked-By: NBert Kenward <bkenward@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9447a10f
    • E
      net: ena: remove ndo_poll_controller · 21627982
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      ena uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Netanel Belgazal <netanel@amazon.com>
      Cc: Saeed Bishara <saeedb@amazon.com>
      Cc: Zorik Machulsky <zorik@amazon.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      21627982
    • E
      qlogic: netxen: remove ndo_poll_controller · 3548fcf7
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      netxen uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Manish Chopra <manish.chopra@cavium.com>
      Cc: Rahul Verma <rahul.verma@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3548fcf7
    • E
      qlcnic: remove ndo_poll_controller · 81b059b2
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      qlcnic uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Harish Patil <harish.patil@cavium.com>
      Cc: Manish Chopra <manish.chopra@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      81b059b2
    • E
      virtio_net: remove ndo_poll_controller · 260dd2c3
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      virto_net uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: "Michael S. Tsirkin" <mst@redhat.com>
      Cc: Jason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      260dd2c3
    • E
      net: hns: remove ndo_poll_controller · 4bd2c03b
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      hns uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
      Cc: Salil Mehta <salil.mehta@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4bd2c03b
    • E
      ehea: remove ndo_poll_controller · 226a2dd6
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      ehea uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Douglas Miller <dougmill@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      226a2dd6
    • E
      hinic: remove ndo_poll_controller · e71fb423
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      hinic uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      
      Note that hinic_netpoll() was incorrectly scheduling NAPI
      on both RX and TX queues.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Aviad Krawczyk <aviad.krawczyk@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e71fb423
    • E
      netpoll: do not test NAPI_STATE_SCHED in poll_one_napi() · c24498c6
      Eric Dumazet 提交于
      Since we do no longer require NAPI drivers to provide
      an ndo_poll_controller(), napi_schedule() has not been done
      before poll_one_napi() invocation.
      
      So testing NAPI_STATE_SCHED is likely to cause early returns.
      
      While we are at it, remove outdated comment.
      
      Note to future bisections : This change might surface prior
      bugs in drivers. See commit 73f21c65 ("bnxt_en: Fix TX
      timeout during netpoll.") for one occurrence.
      
      Fixes: ac3d9dd0 ("netpoll: make ndo_poll_controller() optional")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Tested-by: NSong Liu <songliubraving@fb.com>
      Cc: Michael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c24498c6
    • D
      Merge tag 'mac80211-for-davem-2018-09-27' of... · 05c5e9ff
      David S. Miller 提交于
      Merge tag 'mac80211-for-davem-2018-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      
      Johannes Berg says:
      
      ====================
      More patches than I'd like perhaps, but each seems reasonable:
       * two new spectre-v1 mitigations in nl80211
       * TX status fix in general, and mesh in particular
       * powersave vs. offchannel fix
       * regulatory initialization fix
       * fix for a queue hang due to a bad return value
       * allocate TXQs for active monitor interfaces, fixing my
         earlier patch to avoid unnecessary allocations where I
         missed this case needed them
       * fix TDLS data frames priority assignment
       * fix scan results processing to take into account duplicate
         channel numbers (over different operating classes, but we
         don't necessarily know the operating class)
       * various hwsim fixes for radio destruction and new radio
         announcement messages
       * remove an extraneous kernel-doc line
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      05c5e9ff
    • S
      qed: Fix shmem structure inconsistency between driver and the mfw. · 5f672090
      Sudarsana Reddy Kalluru 提交于
      The structure shared between driver and the management FW (mfw) differ in
      sizes. This would lead to issues when driver try to access the structure
      members which are not-aligned with the mfw copy e.g., data_ptr usage in the
      case of mfw_tlv request.
      Align the driver structure with mfw copy, add reserved field(s) to driver
      structure for the members not used by the driver.
      
      Fixes: dd006921 ("qed: Add MFW interfaces for TLV request support.)
      Signed-off-by: NSudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
      Signed-off-by: NMichal Kalderon <Michal.Kalderon@cavium.com>
      5f672090
    • S
    • S
      MAINTAINERS: change bridge maintainers · ce7d17d6
      Stephen Hemminger 提交于
      I haven't been doing reviews only but not active development on bridge
      code for several years. Roopa and Nikolay have been doing most of
      the new features and have agreed to take over as new co-maintainers.
      Signed-off-by: NStephen Hemminger <stephen@networkplumber.org>
      Acked-by: NRoopa Prabhu <roopa@cumulusnetworks.com>
      Acked-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      ce7d17d6
    • D
      Merge branch 's390-qeth-fixes' · 26258cb3
      David S. Miller 提交于
      Julian Wiedmann says:
      
      ====================
      s390/qeth: fixes 2019-09-26
      
      please apply two qeth patches for -net. The first is a trivial cleanup
      required for patch #2 by Jean, which fixes a potential endless loop.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      26258cb3
    • J
      s390: qeth: Fix potential array overrun in cmd/rc lookup · 048a7f8b
      Jean Delvare 提交于
      Functions qeth_get_ipa_msg and qeth_get_ipa_cmd_name are modifying
      the last member of global arrays without any locking that I can see.
      If two instances of either function are running at the same time,
      it could cause a race ultimately leading to an array overrun (the
      contents of the last entry of the array is the only guarantee that
      the loop will ever stop).
      
      Performing the lookups without modifying the arrays is admittedly
      slower (two comparisons per iteration instead of one) but these
      are operations which are rare (should only be needed in error
      cases or when debugging, not during successful operation) and it
      seems still less costly than introducing a mutex to protect the
      arrays in question.
      
      As a side bonus, it allows us to declare both arrays as const data.
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      Cc: Julian Wiedmann <jwi@linux.ibm.com>
      Cc: Ursula Braun <ubraun@linux.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      048a7f8b
    • Z
      s390: qeth_core_mpc: Use ARRAY_SIZE instead of reimplementing its function · 065a2cdc
      zhong jiang 提交于
      Use the common code ARRAY_SIZE macro instead of a private implementation.
      Reviewed-by: NJean Delvare <jdelvare@suse.de>
      Signed-off-by: Nzhong jiang <zhongjiang@huawei.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      065a2cdc
  4. 28 9月, 2018 6 次提交
    • F
      netfilter: xt_socket: check sk before checking for netns. · 40e4f26e
      Flavio Leitner 提交于
      Only check for the network namespace if the socket is available.
      
      Fixes: f5646501 ("netfilter: check if the socket netns is correct.")
      Reported-by: NGuenter Roeck <linux@roeck-us.net>
      Tested-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NFlavio Leitner <fbl@redhat.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      40e4f26e
    • F
      netfilter: avoid erronous array bounds warning · 421c119f
      Florian Westphal 提交于
      Unfortunately some versions of gcc emit following warning:
        $ make net/xfrm/xfrm_output.o
        linux/compiler.h:252:20: warning: array subscript is above array bounds [-Warray-bounds]
        hook_head = rcu_dereference(net->nf.hooks_arp[hook]);
                                  ^~~~~~~~~~~~~~~~~~~~~
      xfrm_output_resume passes skb_dst(skb)->ops->family as its 'pf' arg so compiler
      can't know that we'll never access hooks_arp[].
      (NFPROTO_IPV4 or NFPROTO_IPV6 are only possible cases).
      
      Avoid this by adding an explicit WARN_ON_ONCE() check.
      
      This patch has no effect if the family is a compile-time constant as gcc
      will remove the switch() construct entirely.
      Reported-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Reviewed-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      421c119f
    • T
      netfilter: nft_set_rbtree: add missing rb_erase() in GC routine · a13f814a
      Taehee Yoo 提交于
      The nft_set_gc_batch_check() checks whether gc buffer is full.
      If gc buffer is full, gc buffer is released by
      the nft_set_gc_batch_complete() internally.
      In case of rbtree, the rb_erase() should be called before calling the
      nft_set_gc_batch_complete(). therefore the rb_erase() should
      be called before calling the nft_set_gc_batch_check() too.
      
      test commands:
         table ip filter {
      	   set set1 {
      		   type ipv4_addr; flags interval, timeout;
      		   gc-interval 10s;
      		   timeout 1s;
      		   elements = {
      			   1-2,
      			   3-4,
      			   5-6,
      			   ...
      			   10000-10001,
      		   }
      	   }
         }
         %nft -f test.nft
      
      splat looks like:
      [  430.273885] kasan: GPF could be caused by NULL-ptr deref or user memory access
      [  430.282158] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
      [  430.283116] CPU: 1 PID: 190 Comm: kworker/1:2 Tainted: G    B             4.18.0+ #7
      [  430.283116] Workqueue: events_power_efficient nft_rbtree_gc [nf_tables_set]
      [  430.313559] RIP: 0010:rb_next+0x81/0x130
      [  430.313559] Code: 08 49 bd 00 00 00 00 00 fc ff df 48 bb 00 00 00 00 00 fc ff df 48 85 c0 75 05 eb 58 48 89 d4
      [  430.313559] RSP: 0018:ffff88010cdb7680 EFLAGS: 00010207
      [  430.313559] RAX: 0000000000b84854 RBX: dffffc0000000000 RCX: ffffffff83f01973
      [  430.313559] RDX: 000000000017090c RSI: 0000000000000008 RDI: 0000000000b84864
      [  430.313559] RBP: ffff8801060d4588 R08: fffffbfff09bc349 R09: fffffbfff09bc349
      [  430.313559] R10: 0000000000000001 R11: fffffbfff09bc348 R12: ffff880100f081a8
      [  430.313559] R13: dffffc0000000000 R14: ffff880100ff8688 R15: dffffc0000000000
      [  430.313559] FS:  0000000000000000(0000) GS:ffff88011b400000(0000) knlGS:0000000000000000
      [  430.313559] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  430.313559] CR2: 0000000001551008 CR3: 000000005dc16000 CR4: 00000000001006e0
      [  430.313559] Call Trace:
      [  430.313559]  nft_rbtree_gc+0x112/0x5c0 [nf_tables_set]
      [  430.313559]  process_one_work+0xc13/0x1ec0
      [  430.313559]  ? _raw_spin_unlock_irq+0x29/0x40
      [  430.313559]  ? pwq_dec_nr_in_flight+0x3c0/0x3c0
      [  430.313559]  ? set_load_weight+0x270/0x270
      [  430.313559]  ? __switch_to_asm+0x34/0x70
      [  430.313559]  ? __switch_to_asm+0x40/0x70
      [  430.313559]  ? __switch_to_asm+0x34/0x70
      [  430.313559]  ? __switch_to_asm+0x34/0x70
      [  430.313559]  ? __switch_to_asm+0x40/0x70
      [  430.313559]  ? __switch_to_asm+0x34/0x70
      [  430.313559]  ? __switch_to_asm+0x40/0x70
      [  430.313559]  ? __switch_to_asm+0x34/0x70
      [  430.313559]  ? __switch_to_asm+0x34/0x70
      [  430.313559]  ? __switch_to_asm+0x40/0x70
      [  430.313559]  ? __switch_to_asm+0x34/0x70
      [  430.313559]  ? __schedule+0x6d3/0x1f50
      [  430.313559]  ? find_held_lock+0x39/0x1c0
      [  430.313559]  ? __sched_text_start+0x8/0x8
      [  430.313559]  ? cyc2ns_read_end+0x10/0x10
      [  430.313559]  ? save_trace+0x300/0x300
      [  430.313559]  ? sched_clock_local+0xd4/0x140
      [  430.313559]  ? find_held_lock+0x39/0x1c0
      [  430.313559]  ? worker_thread+0x353/0x1120
      [  430.313559]  ? worker_thread+0x353/0x1120
      [  430.313559]  ? lock_contended+0xe70/0xe70
      [  430.313559]  ? __lock_acquire+0x4500/0x4500
      [  430.535635]  ? do_raw_spin_unlock+0xa5/0x330
      [  430.535635]  ? do_raw_spin_trylock+0x101/0x1a0
      [  430.535635]  ? do_raw_spin_lock+0x1f0/0x1f0
      [  430.535635]  ? _raw_spin_lock_irq+0x10/0x70
      [  430.535635]  worker_thread+0x15d/0x1120
      [ ... ]
      
      Fixes: 8d8540c4 ("netfilter: nft_set_rbtree: add timeout support")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      a13f814a
    • D
      rxrpc: Fix error distribution · f3344303
      David Howells 提交于
      Fix error distribution by immediately delivering the errors to all the
      affected calls rather than deferring them to a worker thread.  The problem
      with the latter is that retries and things can happen in the meantime when we
      want to stop that sooner.
      
      To this end:
      
       (1) Stop the error distributor from removing calls from the error_targets
           list so that peer->lock isn't needed to synchronise against other adds
           and removals.
      
       (2) Require the peer's error_targets list to be accessed with RCU, thereby
           avoiding the need to take peer->lock over distribution.
      
       (3) Don't attempt to affect a call's state if it is already marked complete.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      f3344303
    • D
      rxrpc: Fix transport sockopts to get IPv4 errors on an IPv6 socket · 37a675e7
      David Howells 提交于
      It seems that enabling IPV6_RECVERR on an IPv6 socket doesn't also turn on
      IP_RECVERR, so neither local errors nor ICMP-transported remote errors from
      IPv4 peer addresses are returned to the AF_RXRPC protocol.
      
      Make the sockopt setting code in rxrpc_open_socket() fall through from the
      AF_INET6 case to the AF_INET case to turn on all the AF_INET options too in
      the AF_INET6 case.
      
      Fixes: f2aeed3a ("rxrpc: Fix error reception on AF_INET6 sockets")
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      37a675e7
    • D
      rxrpc: Make service call handling more robust · 0099dc58
      David Howells 提交于
      Make the following changes to improve the robustness of the code that sets
      up a new service call:
      
       (1) Cache the rxrpc_sock struct obtained in rxrpc_data_ready() to do a
           service ID check and pass that along to rxrpc_new_incoming_call().
           This means that I can remove the check from rxrpc_new_incoming_call()
           without the need to worry about the socket attached to the local
           endpoint getting replaced - which would invalidate the check.
      
       (2) Cache the rxrpc_peer struct, thereby allowing the peer search to be
           done once.  The peer is passed to rxrpc_new_incoming_call(), thereby
           saving the need to repeat the search.
      
           This also reduces the possibility of rxrpc_publish_service_conn()
           BUG()'ing due to the detection of a duplicate connection, despite the
           initial search done by rxrpc_find_connection_rcu() having turned up
           nothing.
      
           This BUG() shouldn't ever get hit since rxrpc_data_ready() *should* be
           non-reentrant and the result of the initial search should still hold
           true, but it has proven possible to hit.
      
           I *think* this may be due to __rxrpc_lookup_peer_rcu() cutting short
           the iteration over the hash table if it finds a matching peer with a
           zero usage count, but I don't know for sure since it's only ever been
           hit once that I know of.
      
           Another possibility is that a bug in rxrpc_data_ready() that checked
           the wrong byte in the header for the RXRPC_CLIENT_INITIATED flag
           might've let through a packet that caused a spurious and invalid call
           to be set up.  That is addressed in another patch.
      
       (3) Fix __rxrpc_lookup_peer_rcu() to skip peer records that have a zero
           usage count rather than stopping and returning not found, just in case
           there's another peer record behind it in the bucket.
      
       (4) Don't search the peer records in rxrpc_alloc_incoming_call(), but
           rather either use the peer cached in (2) or, if one wasn't found,
           preemptively install a new one.
      
      Fixes: 8496af50 ("rxrpc: Use RCU to access a peer's service connection tree")
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      0099dc58