On Fri, 2015-01-23 at 09:01 +0200, Or Gerlitz wrote: > On Thu, Jan 22, 2015 at 4:31 PM, Doug Ledford <[email protected]> wrote: > > My 8 patch set taken into 3.19 caused some regressions. This patch > > set resolves those issues. > > Doug, Roland - eight rc1 patches followed ten rc6 fixes - sounds a bit > too much to me.
We can do as we wish upstream, but these are going live in our product ASAP. The original 8 rc1 patches took so long to get upstream that they had already been live in 6.5-z and 6.6 and were slated for 7.1. We had a few customers report problems, but not as many as you might think. The new patches are going to go out and fix those problems, period. I can't wait for 3.20 to fix these issues. C'est la vie. FWIW, I expect that these patches (plus the one patch I didn't put in this same thread) to be live on production machines probably within 10 days (or less). I'll let you know how that goes. > If we (and Linus) like or not, probably the right > thing to do is revert the rc1 patches and come up with a set of > hopefully < 18 patches for 3.20 - using squashes and such, and there's > not much time for that too, BTW. I'm not going to squash them. I used to write big monolithic patches, back in the day when I was a newbie kernel engineer. Trying to review or understand the nuances of those patches was nigh on impossible. Here, each patch was unique in the issue it addressed and done that way particularly to make it easier to follow the logic later when someone might review this code and these changes. A big monolithic patch that hides these revisions hides the nuances that made getting this right difficult. I'm not going to go back to those days. Git is just fine with these patches being separated. > Taking into account Doug's listing of the remaining problems in the > original set which are not addressed by the patch Erez suggested, this > isn't an option either. I agree with you on this point. But, I would also point out, that if you are looking for justification to take this current patch set, that's the real justification. It's all about understanding the problem, and dealing with it properly. My patch set does that. Patch count and line count are secondary to understanding when it comes to determining if a change is acceptable in late rc stage IMO. > Alex, you acked all the series, haven't you noticed the IPv6 and IPv4 > multicast breakage or it worked for you? Surprisingly enough, not many people use multicast. And the whole reason I didn't see the problem in the first place is that the initial multicast setup that's necessary to make the links come up works OK, it's only new joins after that which are effected. We haven't had any reports of multicast not working except from you. Your report was valid, just no one else cared (I'm sure someone would have eventually, but out of the people using 6.5-z and 6.6 kernels, no one reported multicast issues, just other issues). > Or. > > > 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(-) > -- > 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 -- Doug Ledford <[email protected]> GPG KeyID: 0E572FDD
signature.asc
Description: This is a digitally signed message part
