Message ID | 20170815.175219.753462032002961032.davem@davemloft.net |
---|---|
State | Accepted, archived |
Delegated to: | David Miller |
Headers | show |
On Tue, Aug 15, 2017 at 5:52 PM, David Miller <davem@davemloft.net> wrote: > > dingtianhong (4): > PCI: Disable PCIe Relaxed Ordering if unsupported > PCI: Disable Relaxed Ordering for some Intel processors > PCI: Disable Relaxed Ordering Attributes for AMD A1100 > PCI: fix oops when try to find Root Port for a PCI device I would *really* have liked to see an ack on these from Bjorn Helgaas. Was he even cc'd? And while singling those commits out, I would also really have liked to see an actual name there. The name exists in the sign-off chain: Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> but for some reason not in the actual commit author data, where it's just "dingtianhong". Pulled, but slightly unhappy. Linus
From: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue, 15 Aug 2017 19:21:16 -0700 > On Tue, Aug 15, 2017 at 5:52 PM, David Miller <davem@davemloft.net> wrote: >> >> dingtianhong (4): >> PCI: Disable PCIe Relaxed Ordering if unsupported >> PCI: Disable Relaxed Ordering for some Intel processors >> PCI: Disable Relaxed Ordering Attributes for AMD A1100 >> PCI: fix oops when try to find Root Port for a PCI device > > I would *really* have liked to see an ack on these from Bjorn Helgaas. > Was he even cc'd? > > And while singling those commits out, I would also really have liked > to see an actual name there. > > The name exists in the sign-off chain: > > Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> > > but for some reason not in the actual commit author data, where it's > just "dingtianhong". > > Pulled, but slightly unhappy. Bjorn did review these changes, and certainly shaped the final result, but indeed I should have gotten an explicit ACK from him. I'll make sure I do so next time.
Hi! Could we get this one in? wl1251 misses a spin_lock_init(). https://www.mail-archive.com/netdev@vger.kernel.org/msg177031.html It seems pretty trivial, yet getting the backtraces is not nice. Thanks, Pavel
Pavel Machek <pavel@ucw.cz> writes: > Could we get this one in? > > wl1251 misses a spin_lock_init(). > > https://www.mail-archive.com/netdev@vger.kernel.org/msg177031.html > > It seems pretty trivial, yet getting the backtraces is not nice. It's in wireless-drivers-next and will be in 4.14-rc1: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?id=6e9aae179f290f1a44fce7ef8e9a8e2dd68ed1e4
From: Kalle Valo <kvalo@codeaurora.org> Date: Wed, 30 Aug 2017 17:45:31 +0300 > Pavel Machek <pavel@ucw.cz> writes: > >> Could we get this one in? >> >> wl1251 misses a spin_lock_init(). >> >> https://www.mail-archive.com/netdev@vger.kernel.org/msg177031.html >> >> It seems pretty trivial, yet getting the backtraces is not nice. > > It's in wireless-drivers-next and will be in 4.14-rc1: > > https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?id=6e9aae179f290f1a44fce7ef8e9a8e2dd68ed1e4 Is the bug only present in net-next?
David Miller <davem@davemloft.net> writes: > From: Kalle Valo <kvalo@codeaurora.org> > Date: Wed, 30 Aug 2017 17:45:31 +0300 > >> Pavel Machek <pavel@ucw.cz> writes: >> >>> Could we get this one in? >>> >>> wl1251 misses a spin_lock_init(). >>> >>> https://www.mail-archive.com/netdev@vger.kernel.org/msg177031.html >>> >>> It seems pretty trivial, yet getting the backtraces is not nice. >> >> It's in wireless-drivers-next and will be in 4.14-rc1: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?id=6e9aae179f290f1a44fce7ef8e9a8e2dd68ed1e4 > > Is the bug only present in net-next? AFAICS the bug was introduced by 9df86e2e702c6 back in 2010. If the bug has been there for 7 years so waiting for a few more weeks should not hurt. And Pavel can also submit it to the stable release, it should apply without problems as wl1251 doesn't have had that many patches during the last few years (if ever).
From: Kalle Valo <kvalo@codeaurora.org> Date: Wed, 30 Aug 2017 20:31:31 +0300 > AFAICS the bug was introduced by 9df86e2e702c6 back in 2010. If the bug > has been there for 7 years so waiting for a few more weeks should not > hurt. As a maintainer you have a right to handle bug fixing in that way, but certainly that is not how I would handle this. It's easy to validate this fix, it's extremely unlikely to cause a regression, and fixes a problem someone actually was able to trigger. Deferring to -next only has the side effect of making people wait longer for the fix.
David Miller <davem@davemloft.net> writes: > From: Kalle Valo <kvalo@codeaurora.org> > Date: Wed, 30 Aug 2017 20:31:31 +0300 > >> AFAICS the bug was introduced by 9df86e2e702c6 back in 2010. If the bug >> has been there for 7 years so waiting for a few more weeks should not >> hurt. > > As a maintainer you have a right to handle bug fixing in that way, but > certainly that is not how I would handle this. > > It's easy to validate this fix, it's extremely unlikely to cause > a regression, and fixes a problem someone actually was able to > trigger. > > Deferring to -next only has the side effect of making people wait > longer for the fix. Yeah, you are right there. I did actually ponder which I tree should commit it back in July but due to various reasons decided differently.
On Thu 2017-08-31 07:44:58, Kalle Valo wrote: > David Miller <davem@davemloft.net> writes: > > > From: Kalle Valo <kvalo@codeaurora.org> > > Date: Wed, 30 Aug 2017 20:31:31 +0300 > > > >> AFAICS the bug was introduced by 9df86e2e702c6 back in 2010. If the bug > >> has been there for 7 years so waiting for a few more weeks should not > >> hurt. > > > > As a maintainer you have a right to handle bug fixing in that way, but > > certainly that is not how I would handle this. > > > > It's easy to validate this fix, it's extremely unlikely to cause > > a regression, and fixes a problem someone actually was able to > > trigger. > > > > Deferring to -next only has the side effect of making people wait > > longer for the fix. > > Yeah, you are right there. I did actually ponder which I tree should > commit it back in July but due to various reasons decided differently. Can we still get the fix to v4.13-final? :-). Thanks, Pavel
(Adding linux-wireless) Pavel Machek <pavel@ucw.cz> writes: > On Thu 2017-08-31 07:44:58, Kalle Valo wrote: >> David Miller <davem@davemloft.net> writes: >> >> > From: Kalle Valo <kvalo@codeaurora.org> >> > Date: Wed, 30 Aug 2017 20:31:31 +0300 >> > >> >> AFAICS the bug was introduced by 9df86e2e702c6 back in 2010. If the bug >> >> has been there for 7 years so waiting for a few more weeks should not >> >> hurt. >> > >> > As a maintainer you have a right to handle bug fixing in that way, but >> > certainly that is not how I would handle this. >> > >> > It's easy to validate this fix, it's extremely unlikely to cause >> > a regression, and fixes a problem someone actually was able to >> > trigger. >> > >> > Deferring to -next only has the side effect of making people wait >> > longer for the fix. >> >> Yeah, you are right there. I did actually ponder which I tree should >> commit it back in July but due to various reasons decided differently. > > Can we still get the fix to v4.13-final? :-). I'm not planning to submit pull requests to 4.13 anymore. If you think this is so important that it needs to be applied in the last minute (I don't) you could always try to convince Dave to take it directly. Or better yet, push it to the stable tree. If the merge window opens on Sunday I suspect that the commit will be in Linus' tree sometime next week. Then you can submit the request to the stable team to take it.