From: Thorsten Leemhuis <email@example.com> To: "Nguyen, Anthony L" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "Brandeburg, Jesse" <email@example.com> Cc: "Torvalds, Linus" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org> Subject: Re: [PATCH net] igb: fix deadlock caused by taking RTNL in RPM resume path Date: Wed, 22 Dec 2021 13:50:07 +0100 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> Scratch that mail, I was totally wrong, as I accidentally looked at yesterdays linux-next tree, which due to an error of a local cron job looked like todays linux-next tree to me. The real one from today is out now and contains the patch. I apologise for the noise. Ciao, Thorsten On 22.12.21 06:17, Thorsten Leemhuis wrote: > On 20.12.21 20:56, Nguyen, Anthony L wrote: >> On Sun, 2021-12-19 at 09:31 +0100, Thorsten Leemhuis wrote: >>> Hi, this is your Linux kernel regression tracker speaking. >>> >>> On 29.11.21 22:14, Heiner Kallweit wrote: >>>> Recent net core changes caused an issue with few Intel drivers >>>> (reportedly igb), where taking RTNL in RPM resume path results in a >>>> deadlock. See  for a bug report. I don't think the core changes >>>> are wrong, but taking RTNL in RPM resume path isn't needed. >>>> The Intel drivers are the only ones doing this. See  for a >>>> discussion on the issue. Following patch changes the RPM resume >>>> path >>>> to not take RTNL. >>>> >>>>  https://bugzilla.kernel.org/show_bug.cgi?id=215129 >>>>  >>>> https://email@example.com/t/ >>>> >>>> Fixes: bd869245a3dc ("net: core: try to runtime-resume detached >>>> device in __dev_open") >>>> Fixes: f32a21376573 ("ethtool: runtime-resume netdev parent before >>>> ethtool ioctl ops") >>>> Tested-by: Martin Stolpe <firstname.lastname@example.org> >>>> Signed-off-by: Heiner Kallweit <email@example.com> >>> >>> Long story short: what is taken this fix so long to get mainlined? It >>> to >>> me seems progressing unnecessary slow, especially as it's a >>> regression >>> that made it into v5.15 and thus for weeks now seems to bug more and >>> more people. >>> >>> >>> The long story, starting with the background details: >>> >>> The quoted patch fixes a regression among others caused by >>> f32a21376573 >>> ("ethtool: runtime-resume netdev parent before ethtool ioctl ops"), >>> which got merged for v5.15-rc1. >>> >>> The regression ("kernel hangs during power down") was afaik first >>> reported on Wed, 24 Nov (IOW: nearly a month ago) and forwarded to >>> the >>> list shortly afterwards: >>> https://bugzilla.kernel.org/show_bug.cgi?id=215129 >>> https://firstname.lastname@example.org/ >>> >>> The quoted patch to fix the regression was posted on Mon, 29 Nov (thx >>> Heiner for providing it!). Obviously reviewing patches can take a few >>> days when they are complicated, as the other messages in this thread >>> show. But according to >>> https://bugzilla.kernel.org/show_bug.cgi?id=215129#c8 the patch was >>> ACKed by Thu, 7 Dec. To quote: ```The patch is on its way via the >>> Intel >>> network driver tree: >>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/tnguy/net-queue/+/refs/heads/dev-queue``` >>> >>> And that's where the patch afaics still is. It hasn't even reached >>> linux-next yet, unless I'm missing something. A merge into mainline >>> thus >>> is not even in sight; this seems especially bad with the holiday >>> season >>> coming up, as getting the fix mainlined is a prerequisite to get it >>> backported to 5.15.y, as our latest stable kernel is affected by >>> this. >> >> I've been waiting for our validation team to get to this patch to do >> some additional testing. However, as you mentioned, with the holidays >> coming up, it seems the tester is now out. As it looks like some in the >> community have been able to do some testing on this, I'll go ahead and >> send this on. > > Thx. I see the patch now in addition to dev-queue is also in master of > this repo: > > https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git/ > > But the fix still didn't make it in todays linux-next. Seems neither > your master branch nor branches like '1GbE' (which seem to be the ones > from which such fixes later get send to the net tree) are in linux-next > afaic. > > Just wondering: Wouldn't it be better if they were? This would allow the > users of linux-next and CIs checking it to test the fix before it's send > to the net tree, which last week seems to have happened only a few hours > (6209dd778f66) before net was merged into mainline (180f3bcfe362). > > Ciao, Thorsten
prev parent reply other threads:[~2021-12-22 12:50 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-29 21:14 Heiner Kallweit 2021-11-29 23:09 ` Stephen Hemminger 2021-11-30 6:33 ` Heiner Kallweit 2021-11-30 1:17 ` Jakub Kicinski 2021-11-30 6:46 ` Heiner Kallweit 2021-11-30 17:12 ` Jakub Kicinski 2021-11-30 21:35 ` Heiner Kallweit 2021-12-01 0:51 ` Jakub Kicinski 2021-12-19 8:31 ` Thorsten Leemhuis 2021-12-20 19:56 ` Nguyen, Anthony L 2021-12-22 5:17 ` Thorsten Leemhuis 2021-12-22 12:50 ` Thorsten Leemhuis [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH net] igb: fix deadlock caused by taking RTNL in RPM resume path' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).