Fix ipoib regressions
Get series with b4
b4 am [email protected]Versions newest first
- v5 Latest10 patches 15 repliesIn review
Patches in v5 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/10 | IB/ipoib: fix IPOIB_MCAST_RUN flag usagedrivers/ | +5 | 0 replies | |
| 2/10 | IB/ipoib: Add a helper to restart the multicast taskdrivers/ | +29 | 0 replies | |
| 3/10 | IB/ipoib: make delayed tasks not hold up everythingdrivers/ drivers/ | +57 | 0 replies | |
| 4/10 | IB/ipoib: Handle -ENETRESET properly in our callbackdrivers/ | +6 | 0 replies | |
| 5/10 | IB/ipoib: don't restart our thread on ENETRESETdrivers/ | +2 | 0 replies | |
| 6/10 | IB/ipoib: remove unneeded locksdrivers/ | +0 | 0 replies | |
| 7/10 | IB/ipoib: fix race between mcast_dev_flush and mcast_joindrivers/ | +56 | 0 replies | |
| 8/10 | IB/ipoib: fix ipoib_mcast_restart_taskdrivers/ | +3 | 0 replies | |
| 9/10 | IB/ipoib: flush the ipoib_workqueue on unregisterdrivers/ | +2 | 0 replies | |
| 10/10 | IB/ipoib: cleanup a couple debug messagesdrivers/ | +5 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v5 yet.
Cover letter [PATCH FIX For-3.19 v5 00/10] Fix ipoib regressions
My 8 patch set taken into 3.19 caused some regressions. This patch set resolves those issues.
These patches are to resolve issues created by my previous patch set. While that set worked fine in my testing, there were problems with multicast joins after the initial set of joins had completed. Since my testing relied upon the normal set of multicast joins that happen when the interface is first brought up, I missed those problems.
Symptoms vary from failure to send packets due to a failed join, to loss of connectivity after a subnet manager restart, to failure to properly release multicast groups on shutdown resulting in hangs when the mlx4 driver attempts to unload itself via its reboot notifier handler.
This set of patches has passed a number of tests above and beyond my original tests. As suggested by Or Gerlitz I added IPv6 and IPv4 multicast tests. I also added both subnet manager restarts and manual shutdown/restart of individual ports at the switch in order to ensure that the ENETRESET path was properly tested. I included testing, then a subnet manager restart, then a quiescent period for caches to expire, then restarting testing to make sure that arp and neighbor discovery work after the subnet manager restart.
All in all, I have not been able to trip the multicast joins up any longer.
Additionally, the original impetus for my first 8 patch set was that it was simply too easy to break the IPoIB subsystem with this simple loop:
while true; do
ifconfig ib0 up
ifconfig ib0 down
done
Just to be safe, I made sure this problem did not resurface.
v5: fix an oversight in mcast_restart_task that leaked mcast joins
fix a failure to flush the ipoib_workqueue on deregister that meant we could end up running our code after our device had been removed, resulting in an oops
remove a debug message that could be trigger so fast that the kernel printk mechanism would starve out the mcast join task thread resulting in what looked like a mcast failure that was really just delayed action
Doug Ledford (10):
IB/ipoib: fix IPOIB_MCAST_RUN flag usage IB/ipoib: Add a helper to restart the multicast task IB/ipoib: make delayed tasks not hold up everything IB/ipoib: Handle -ENETRESET properly in our callback IB/ipoib: don't restart our thread on ENETRESET IB/ipoib: remove unneeded locks
IB/ipoib: fix race between mcast_dev_flush and mcast_join IB/ipoib: fix ipoib_mcast_restart_task
IB/ipoib: flush the ipoib_workqueue on unregister IB/ipoib: cleanup a couple debug messages
drivers/infiniband/ulp/ipoib/ipoib.h | 1 + drivers/infiniband/ulp/ipoib/ipoib_main.c | 2 + drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 234 ++++++++++++++----------- 3 files changed, 131 insertions(+), 106 deletions(-)
Signature · 6 lines
2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html