1. 01 3月, 2022 12 次提交
  2. 28 2月, 2022 5 次提交
    • A
      net: ipa: fix a build dependency · caef14b7
      Alex Elder 提交于
      An IPA build problem arose in the linux-next tree the other day.
      The problem is that a recent commit adds a new dependency on some
      code, and the Kconfig file for IPA doesn't reflect that dependency.
      As a result, some configurations can fail to build (particularly
      when COMPILE_TEST is enabled).
      
      The recent patch adds calls to qmp_get(), qmp_put(), and qmp_send(),
      and those are built based on the QCOM_AOSS_QMP config option.  If
      that symbol is not defined, stubs are defined, so we just need to
      ensure QCOM_AOSS_QMP is compatible with QCOM_IPA, or it's not
      defined.
      Reported-by: NRandy Dunlap <rdunlap@infradead.org>
      Fixes: 34a08176 ("net: ipa: request IPA register values be retained")
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Tested-by: NRandy Dunlap <rdunlap@infradead.org>
      Acked-by: NRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      caef14b7
    • J
      atm: firestream: check the return value of ioremap() in fs_init() · d4e26aae
      Jia-Ju Bai 提交于
      The function ioremap() in fs_init() can fail, so its return value should
      be checked.
      Reported-by: NTOTE Robot <oslab@tsinghua.edu.cn>
      Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d4e26aae
    • C
      net: sparx5: Add #include to remove warning · 90d40252
      Casper Andersson 提交于
      main.h uses NUM_TARGETS from main_regs.h, but
      the missing include never causes any errors
      because everywhere main.h is (currently)
      included, main_regs.h is included before.
      But since it is dependent on main_regs.h
      it should always be included.
      Signed-off-by: NCasper Andersson <casper.casan@gmail.com>
      Reviewed-by: NJoacim Zetterling <joacim.zetterling@westermo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      90d40252
    • T
      net/smc: Fix cleanup when register ULP fails · 4d08b7b5
      Tony Lu 提交于
      This patch calls smc_ib_unregister_client() when tcp_register_ulp()
      fails, and make sure to clean it up.
      
      Fixes: d7cd421d ("net/smc: Introduce TCP ULP support")
      Signed-off-by: NTony Lu <tonylu@linux.alibaba.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4d08b7b5
    • J
      net: ipv6: ensure we call ipv6_mc_down() at most once · 9995b408
      j.nixdorf@avm.de 提交于
      There are two reasons for addrconf_notify() to be called with NETDEV_DOWN:
      either the network device is actually going down, or IPv6 was disabled
      on the interface.
      
      If either of them stays down while the other is toggled, we repeatedly
      call the code for NETDEV_DOWN, including ipv6_mc_down(), while never
      calling the corresponding ipv6_mc_up() in between. This will cause a
      new entry in idev->mc_tomb to be allocated for each multicast group
      the interface is subscribed to, which in turn leaks one struct ifmcaddr6
      per nontrivial multicast group the interface is subscribed to.
      
      The following reproducer will leak at least $n objects:
      
      ip addr add ff2e::4242/32 dev eth0 autojoin
      sysctl -w net.ipv6.conf.eth0.disable_ipv6=1
      for i in $(seq 1 $n); do
      	ip link set up eth0; ip link set down eth0
      done
      
      Joining groups with IPV6_ADD_MEMBERSHIP (unprivileged) or setting the
      sysctl net.ipv6.conf.eth0.forwarding to 1 (=> subscribing to ff02::2)
      can also be used to create a nontrivial idev->mc_list, which will the
      leak objects with the right up-down-sequence.
      
      Based on both sources for NETDEV_DOWN events the interface IPv6 state
      should be considered:
      
       - not ready if the network interface is not ready OR IPv6 is disabled
         for it
       - ready if the network interface is ready AND IPv6 is enabled for it
      
      The functions ipv6_mc_up() and ipv6_down() should only be run when this
      state changes.
      
      Implement this by remembering when the IPv6 state is ready, and only
      run ipv6_mc_down() if it actually changed from ready to not ready.
      
      The other direction (not ready -> ready) already works correctly, as:
      
       - the interface notification triggered codepath for NETDEV_UP /
         NETDEV_CHANGE returns early if ipv6 is disabled, and
       - the disable_ipv6=0 triggered codepath skips fully initializing the
         interface as long as addrconf_link_ready(dev) returns false
       - calling ipv6_mc_up() repeatedly does not leak anything
      
      Fixes: 3ce62a84 ("ipv6: exit early in addrconf_notify() if IPv6 is disabled")
      Signed-off-by: NJohannes Nixdorf <j.nixdorf@avm.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9995b408
  3. 26 2月, 2022 13 次提交
  4. 25 2月, 2022 10 次提交
    • C
      net: sparx5: Fix add vlan when invalid operation · b3a34dc3
      Casper Andersson 提交于
      Check if operation is valid before changing any
      settings in hardware. Otherwise it results in
      changes being made despite it not being a valid
      operation.
      
      Fixes: 78eab33b ("net: sparx5: add vlan support")
      Signed-off-by: NCasper Andersson <casper.casan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b3a34dc3
    • J
      net: chelsio: cxgb3: check the return value of pci_find_capability() · 767b9825
      Jia-Ju Bai 提交于
      The function pci_find_capability() in t3_prep_adapter() can fail, so its
      return value should be checked.
      
      Fixes: 4d22de3e ("Add support for the latest 1G/10G Chelsio adapter, T3")
      Reported-by: NTOTE Robot <oslab@tsinghua.edu.cn>
      Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      767b9825
    • D
      Merge branch 'ibmvnic-fixes' · 5a83dd14
      David S. Miller 提交于
      Sukadev Bhattiprolu says:
      
      ====================
      ibmvnic: Fix a race in ibmvnic_probe()
      
      If we get a transport (reset) event right after a successful CRQ_INIT
      during ibmvnic_probe() but before we set the adapter state to VNIC_PROBED,
      we will throw away the reset assuming that the adapter is still in the
      probing state. But since the adapter has completed the CRQ_INIT any
      subsequent CRQs the we send will be ignored by the vnicserver until
      we release/init the CRQ again. This can leave the adapter unconfigured.
      
      While here fix a couple of other bugs that were observed (Patches 1,2,4).
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a83dd14
    • S
      ibmvnic: Allow queueing resets during probe · fd98693c
      Sukadev Bhattiprolu 提交于
      We currently don't allow queuing resets when adapter is in VNIC_PROBING
      state - instead we throw away the reset and return EBUSY. The reasoning
      is probably that during ibmvnic_probe() the ibmvnic_adapter itself is
      being initialized so performing a reset during this time can lead us to
      accessing fields in the ibmvnic_adapter that are not fully initialized.
      A review of the code shows that all the adapter state neede to process a
      reset is initialized before registering the CRQ so that should no longer
      be a concern.
      
      Further the expectation is that if we do get a reset (transport event)
      during probe, the do..while() loop in ibmvnic_probe() will handle this
      by reinitializing the CRQ.
      
      While that is true to some extent, it is possible that the reset might
      occur _after_ the CRQ is registered and CRQ_INIT message was exchanged
      but _before_ the adapter state is set to VNIC_PROBED. As mentioned above,
      such a reset will be thrown away. While the client assumes that the
      adapter is functional, the vnic server will wait for the client to reinit
      the adapter. This disconnect between the two leaves the adapter down
      needing manual intervention.
      
      Because ibmvnic_probe() has other work to do after initializing the CRQ
      (such as registering the netdev at a minimum) and because the reset event
      can occur at any instant after the CRQ is initialized, there will always
      be a window between initializing the CRQ and considering the adapter
      ready for resets (ie state == PROBED).
      
      So rather than discarding resets during this window, allow queueing them
      - but only process them after the adapter is fully initialized.
      
      To do this, introduce a new completion state ->probe_done and have the
      reset worker thread wait on this before processing resets.
      
      This change brings up two new situations in or just after ibmvnic_probe().
      First after one or more resets were queued, we encounter an error and
      decide to retry the initialization.  At that point the queued resets are
      no longer relevant since we could be talking to a new vnic server. So we
      must purge/flush the queued resets before restarting the initialization.
      As a side note, since we are still in the probing stage and we have not
      registered the netdev, it will not be CHANGE_PARAM reset.
      
      Second this change opens up a potential race between the worker thread
      in __ibmvnic_reset(), the tasklet and the ibmvnic_open() due to the
      following sequence of events:
      
      	1. Register CRQ
      	2. Get transport event before CRQ_INIT completes.
      	3. Tasklet schedules reset:
      		a) add rwi to list
      		b) schedule_work() to start worker thread which runs
      		   and waits for ->probe_done.
      	4. ibmvnic_probe() decides to retry, purges rwi_list
      	5. Re-register crq and this time rest of probe succeeds - register
      	   netdev and complete(->probe_done).
      	6. Worker thread resumes in __ibmvnic_reset() from 3b.
      	7. Worker thread sets ->resetting bit
      	8. ibmvnic_open() comes in, notices ->resetting bit, sets state
      	   to IBMVNIC_OPEN and returns early expecting worker thread to
      	   finish the open.
      	9. Worker thread finds rwi_list empty and returns without
      	   opening the interface.
      
      If this happens, the ->ndo_open() call is effectively lost and the
      interface remains down. To address this, ensure that ->rwi_list is
      not empty before setting the ->resetting  bit. See also comments in
      __ibmvnic_reset().
      
      Fixes: 6a2fb0e9 ("ibmvnic: driver initialization for kdump/kexec")
      Signed-off-by: NSukadev Bhattiprolu <sukadev@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fd98693c
    • S
      ibmvnic: clear fop when retrying probe · f628ad53
      Sukadev Bhattiprolu 提交于
      Clear ->failover_pending flag that may have been set in the previous
      pass of registering CRQ. If we don't clear, a subsequent ibmvnic_open()
      call would be misled into thinking a failover is pending and assuming
      that the reset worker thread would open the adapter. If this pass of
      registering the CRQ succeeds (i.e there is no transport event), there
      wouldn't be a reset worker thread.
      
      This would leave the adapter unconfigured and require manual intervention
      to bring it up during boot.
      
      Fixes: 5a18e1e0 ("ibmvnic: Fix failover case for non-redundant configuration")
      Signed-off-by: NSukadev Bhattiprolu <sukadev@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f628ad53
    • S
      ibmvnic: init init_done_rc earlier · ae16bf15
      Sukadev Bhattiprolu 提交于
      We currently initialize the ->init_done completion/return code fields
      before issuing a CRQ_INIT command. But if we get a transport event soon
      after registering the CRQ the taskslet may already have recorded the
      completion and error code. If we initialize here, we might overwrite/
      lose that and end up issuing the CRQ_INIT only to timeout later.
      
      If that timeout happens during probe, we will leave the adapter in the
      DOWN state rather than retrying to register/init the CRQ.
      
      Initialize the completion before registering the CRQ so we don't lose
      the notification.
      
      Fixes: 032c5e82 ("Driver for IBM System i/p VNIC protocol")
      Signed-off-by: NSukadev Bhattiprolu <sukadev@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ae16bf15
    • S
      ibmvnic: register netdev after init of adapter · 570425f8
      Sukadev Bhattiprolu 提交于
      Finish initializing the adapter before registering netdev so state
      is consistent.
      
      Fixes: c26eba03 ("ibmvnic: Update reset infrastructure to support tunable parameters")
      Signed-off-by: NSukadev Bhattiprolu <sukadev@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      570425f8
    • S
      ibmvnic: complete init_done on transport events · 36491f2d
      Sukadev Bhattiprolu 提交于
      If we get a transport event, set the error and mark the init as
      complete so the attempt to send crq-init or login fail sooner
      rather than wait for the timeout.
      
      Fixes: bbd669a8 ("ibmvnic: Fix completion structure initialization")
      Signed-off-by: NSukadev Bhattiprolu <sukadev@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      36491f2d
    • S
      ibmvnic: define flush_reset_queue helper · 83da53f7
      Sukadev Bhattiprolu 提交于
      Define and use a helper to flush the reset queue.
      
      Fixes: 2770a798 ("ibmvnic: Introduce hard reset recovery")
      Signed-off-by: NSukadev Bhattiprolu <sukadev@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      83da53f7
    • S
      ibmvnic: initialize rc before completing wait · 765559b1
      Sukadev Bhattiprolu 提交于
      We should initialize ->init_done_rc before calling complete(). Otherwise
      the waiting thread may see ->init_done_rc as 0 before we have updated it
      and may assume that the CRQ was successful.
      
      Fixes: 6b278c0c ("ibmvnic delay complete()")
      Signed-off-by: NSukadev Bhattiprolu <sukadev@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      765559b1