* Re: regression caused by block: freeze the queue earlier in del_gendisk [not found] <017845ae-fbae-70f6-5f9e-29aff2742b8c@dustymabe.com> @ 2022-08-28 10:24 ` Thorsten Leemhuis 2022-08-31 12:36 ` Thorsten Leemhuis [not found] ` <YxBZ4BBjxvAkvI2A@T590> 1 sibling, 1 reply; 15+ messages in thread From: Thorsten Leemhuis @ 2022-08-28 10:24 UTC (permalink / raw) To: Dusty Mabe, Jens Axboe, linux-block, linux-kernel; +Cc: hch, regressions Hi, this is your Linux kernel regression tracker. Thx for the report. CCing the regression mailing list, as it should be in the loop for all regressions, as explained here: https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html On 26.08.22 18:15, Dusty Mabe wrote: > > I think I've found a regression introduced by: > a09b314 o block: freeze the queue earlier in del_gendisk Just FYI, in case you are not aware of it already: there was another report that this commit causes problems. See this thread for details: https://lore.kernel.org/all/72a5bf2e-cd56-a85c-2b99-cb8729a66fed@deltatee.com/#t Anyway, let me add this report to the regressions tracking: [TLDR: I'm adding this regression report to the list of tracked regressions; all text from me you find below is based on a few templates paragraphs you might have encountered already already in similar form.] > In Fedora CoreOS we have tests that set up RAID1 on the /boot/ and /root/ partitions > and then subsequently removes one of the disks to simulate a failure. Sometime recently > this test started timing out occasionally. Looking a bit closer it appears instances are > getting stuck during reboot with a bunch of looping messages: > > ``` > [ 17.978854] block device autoloading is deprecated and will be removed. > [ 17.982555] block device autoloading is deprecated and will be removed. > [ 17.985537] block device autoloading is deprecated and will be removed. > [ 17.987546] block device autoloading is deprecated and will be removed. > [ 17.989540] block device autoloading is deprecated and will be removed. > [ 17.991547] block device autoloading is deprecated and will be removed. > [ 17.993555] block device autoloading is deprecated and will be removed. > [ 17.995539] block device autoloading is deprecated and will be removed. > [ 17.997577] block device autoloading is deprecated and will be removed. > [ 17.999544] block device autoloading is deprecated and will be removed. > [ 22.979465] blkdev_get_no_open: 1666 callbacks suppressed > ... > ... > ... > [ 618.221270] blkdev_get_no_open: 1664 callbacks suppressed > [ 618.221273] block device autoloading is deprecated and will be removed. > [ 618.224274] block device autoloading is deprecated and will be removed. > [ 618.227267] block device autoloading is deprecated and will be removed. > [ 618.229274] block device autoloading is deprecated and will be removed. > [ 618.231277] block device autoloading is deprecated and will be removed. > [ 618.233277] block device autoloading is deprecated and will be removed. > [ 618.235282] block device autoloading is deprecated and will be removed. > [ 618.237370] block device autoloading is deprecated and will be removed. > [ 618.239356] block device autoloading is deprecated and will be removed. > [ 618.241290] block device autoloading is deprecated and will be removed. > ``` > > Using the Fedora kernels I narrowed it down to being introduced between > `kernel-5.19.0-0.rc3.27.fc37` (good) and `kernel-5.19.0-0.rc4.33.fc37` (bad). > > I then did a bisect and found: > > ``` > $ git bisect bad > a09b314005f3a0956ebf56e01b3b80339df577cc is the first bad commit > commit a09b314005f3a0956ebf56e01b3b80339df577cc > Author: Christoph Hellwig <hch@lst.de> > Date: Tue Jun 14 09:48:27 2022 +0200 > > block: freeze the queue earlier in del_gendisk > > Freeze the queue earlier in del_gendisk so that the state does not > change while we remove debugfs and sysfs files. > > Ming mentioned that being able to observer request in debugfs might > be useful while the queue is being frozen in del_gendisk, which is > made possible by this change. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > Link: https://lore.kernel.org/r/20220614074827.458955-5-hch@lst.de > Signed-off-by: Jens Axboe <axboe@kernel.dk> > > block/genhd.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > ``` > > Reverting this commit on top of latest git master (4c612826b) gave me successful results. > > Any ideas on what could be amiss here? Luckily the patch is tiny so hopefully it might > be obvious. > > More details (including logs) in the following locations: > > - https://bugzilla.redhat.com/show_bug.cgi?id=2121791 > - https://github.com/coreos/fedora-coreos-tracker/issues/1282 > > > Thanks! > Dusty > Thanks for the report. To be sure below issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking bot: #regzbot ^introduced a09b314005f3a0 #regzbot title block: timeouts when removing a disk from a RAID1 #regzbot ignore-activity This isn't a regression? This issue or a fix for it are already discussed somewhere else? It was fixed already? You want to clarify when the regression started to happen? Or point out I got the title or something else totally wrong? Then just reply -- ideally with also telling regzbot about it, as explained here: https://linux-regtracking.leemhuis.info/tracked-regression/ Reminder for developers: When fixing the issue, add 'Link:' tags pointing to the report (the mail this one replies to), as explained for in the Linux kernel's documentation; above webpage explains why this is important for tracked regressions. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) P.S.: As the Linux kernel's regression tracker I deal with a lot of reports and sometimes miss something important when writing mails like this. If that's the case here, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: regression caused by block: freeze the queue earlier in del_gendisk 2022-08-28 10:24 ` regression caused by block: freeze the queue earlier in del_gendisk Thorsten Leemhuis @ 2022-08-31 12:36 ` Thorsten Leemhuis 0 siblings, 0 replies; 15+ messages in thread From: Thorsten Leemhuis @ 2022-08-31 12:36 UTC (permalink / raw) To: Jens Axboe, hch Cc: regressions, Song Liu, linux-raid, Dusty Mabe, linux-kernel, linux-block [CCing the mdraid maintainer and the raid ml to keep them in the loop] Hi, this is your Linux kernel regression tracker. Top-posting for once, to make this easily accessible to everyone. Christoph, Jens, what's up here? Dusty bisected this and even confirmed a revert on-top of current mainline fixes things for him, nevertheless he didn't get a single reply since he reported the issue last Friday. BTW, it seems quite a few Fedora users are now hitting this with the slightly patched Fedora 5.19.y kernels they since a few days ship as regular update, as comments in https://bugzilla.redhat.com/show_bug.cgi?id=2121791 show -- so it seems it's not something specific to Dusty's setup. Could you please look into the issue? tia! Ciao, Thorsten On 28.08.22 12:24, Thorsten Leemhuis wrote: > Hi, this is your Linux kernel regression tracker. Thx for the report. > > CCing the regression mailing list, as it should be in the loop for all > regressions, as explained here: > https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html > > On 26.08.22 18:15, Dusty Mabe wrote: >> >> I think I've found a regression introduced by: >> a09b314 o block: freeze the queue earlier in del_gendisk > > Just FYI, in case you are not aware of it already: there was another > report that this commit causes problems. See this thread for details: > https://lore.kernel.org/all/72a5bf2e-cd56-a85c-2b99-cb8729a66fed@deltatee.com/#t > > Anyway, let me add this report to the regressions tracking: > > [TLDR: I'm adding this regression report to the list of tracked > regressions; all text from me you find below is based on a few templates > paragraphs you might have encountered already already in similar form.] > >> In Fedora CoreOS we have tests that set up RAID1 on the /boot/ and /root/ partitions >> and then subsequently removes one of the disks to simulate a failure. Sometime recently >> this test started timing out occasionally. Looking a bit closer it appears instances are >> getting stuck during reboot with a bunch of looping messages: >> >> ``` >> [ 17.978854] block device autoloading is deprecated and will be removed. >> [ 17.982555] block device autoloading is deprecated and will be removed. >> [ 17.985537] block device autoloading is deprecated and will be removed. >> [ 17.987546] block device autoloading is deprecated and will be removed. >> [ 17.989540] block device autoloading is deprecated and will be removed. >> [ 17.991547] block device autoloading is deprecated and will be removed. >> [ 17.993555] block device autoloading is deprecated and will be removed. >> [ 17.995539] block device autoloading is deprecated and will be removed. >> [ 17.997577] block device autoloading is deprecated and will be removed. >> [ 17.999544] block device autoloading is deprecated and will be removed. >> [ 22.979465] blkdev_get_no_open: 1666 callbacks suppressed >> ... >> ... >> ... >> [ 618.221270] blkdev_get_no_open: 1664 callbacks suppressed >> [ 618.221273] block device autoloading is deprecated and will be removed. >> [ 618.224274] block device autoloading is deprecated and will be removed. >> [ 618.227267] block device autoloading is deprecated and will be removed. >> [ 618.229274] block device autoloading is deprecated and will be removed. >> [ 618.231277] block device autoloading is deprecated and will be removed. >> [ 618.233277] block device autoloading is deprecated and will be removed. >> [ 618.235282] block device autoloading is deprecated and will be removed. >> [ 618.237370] block device autoloading is deprecated and will be removed. >> [ 618.239356] block device autoloading is deprecated and will be removed. >> [ 618.241290] block device autoloading is deprecated and will be removed. >> ``` >> >> Using the Fedora kernels I narrowed it down to being introduced between >> `kernel-5.19.0-0.rc3.27.fc37` (good) and `kernel-5.19.0-0.rc4.33.fc37` (bad). >> >> I then did a bisect and found: >> >> ``` >> $ git bisect bad >> a09b314005f3a0956ebf56e01b3b80339df577cc is the first bad commit >> commit a09b314005f3a0956ebf56e01b3b80339df577cc >> Author: Christoph Hellwig <hch@lst.de> >> Date: Tue Jun 14 09:48:27 2022 +0200 >> >> block: freeze the queue earlier in del_gendisk >> >> Freeze the queue earlier in del_gendisk so that the state does not >> change while we remove debugfs and sysfs files. >> >> Ming mentioned that being able to observer request in debugfs might >> be useful while the queue is being frozen in del_gendisk, which is >> made possible by this change. >> >> Signed-off-by: Christoph Hellwig <hch@lst.de> >> Link: https://lore.kernel.org/r/20220614074827.458955-5-hch@lst.de >> Signed-off-by: Jens Axboe <axboe@kernel.dk> >> >> block/genhd.c | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> ``` >> >> Reverting this commit on top of latest git master (4c612826b) gave me successful results. >> >> Any ideas on what could be amiss here? Luckily the patch is tiny so hopefully it might >> be obvious. >> >> More details (including logs) in the following locations: >> >> - https://bugzilla.redhat.com/show_bug.cgi?id=2121791 >> - https://github.com/coreos/fedora-coreos-tracker/issues/1282 >> >> >> Thanks! >> Dusty >> > > Thanks for the report. To be sure below issue doesn't fall through the > cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression > tracking bot: > > #regzbot ^introduced a09b314005f3a0 > #regzbot title block: timeouts when removing a disk from a RAID1 > #regzbot ignore-activity > > This isn't a regression? This issue or a fix for it are already > discussed somewhere else? It was fixed already? You want to clarify when > the regression started to happen? Or point out I got the title or > something else totally wrong? Then just reply -- ideally with also > telling regzbot about it, as explained here: > https://linux-regtracking.leemhuis.info/tracked-regression/ > > Reminder for developers: When fixing the issue, add 'Link:' tags > pointing to the report (the mail this one replies to), as explained for > in the Linux kernel's documentation; above webpage explains why this is > important for tracked regressions. > > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) > > P.S.: As the Linux kernel's regression tracker I deal with a lot of > reports and sometimes miss something important when writing mails like > this. If that's the case here, don't hesitate to tell me in a public > reply, it's in everyone's interest to set the public record straight. BTW: #regzbot link: https://bugzilla.redhat.com/show_bug.cgi?id=2121791 #regzbot poke ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <YxBZ4BBjxvAkvI2A@T590>]
[parent not found: <20220907073324.GB23826@lst.de>]
[parent not found: <Yxr4SD4d0rZ9TZik@T590>]
[parent not found: <20220912071618.GA4971@lst.de>]
[parent not found: <Yx/jLTknQm9VeHi4@T590>]
[parent not found: <95cbd47d-46ed-850e-7d4f-851b35d03069@dustymabe.com>]
* Re: regression caused by block: freeze the queue earlier in del_gendisk [not found] ` <95cbd47d-46ed-850e-7d4f-851b35d03069@dustymabe.com> @ 2022-09-20 9:11 ` Thorsten Leemhuis 2022-09-20 14:05 ` Jens Axboe 0 siblings, 1 reply; 15+ messages in thread From: Thorsten Leemhuis @ 2022-09-20 9:11 UTC (permalink / raw) To: Dusty Mabe, Ming Lei, Christoph Hellwig Cc: Jens Axboe, linux-block, linux-kernel, linux-raid, regressions Hi, this is your Linux kernel regression tracker. On 13.09.22 04:36, Dusty Mabe wrote: > On 9/12/22 21:55, Ming Lei wrote: >> On Mon, Sep 12, 2022 at 09:16:18AM +0200, Christoph Hellwig wrote: >>> On Fri, Sep 09, 2022 at 04:24:40PM +0800, Ming Lei wrote: >>>> On Wed, Sep 07, 2022 at 09:33:24AM +0200, Christoph Hellwig wrote: >>>>> On Thu, Sep 01, 2022 at 03:06:08PM +0800, Ming Lei wrote: >>>>>> It is a bit hard to associate the above commit with reported issue. >>>>> >>>>> So the messages clearly are about something trying to open a device >>>>> that went away at the block layer, but somehow does not get removed >>>>> in time by udev (which seems to be a userspace bug in CoreOS). But >>>>> even with that we really should not hang. >>>> >>>> Xiao Ni provides one script[1] which can reproduce the issue more or less. >>> >>> I've run the reproduced 10000 times on current mainline, and while >>> it prints one of the autoloading messages per run, I've not actually >>> seen any kind of hang. >> >> I can't reproduce the hang too. > > I obviously can reproduce the issue with the test in our Fedora CoreOS > test suite. It's part of a framework (i.e. it's not simple some script > you can run) but it is very reproducible so one can add some instrumentation > to the kernel and feed it through a build/test cycle to see different > results or logs. > > I'm willing to share this with other people (maybe a screen share or > some written down instructions) if anyone would be interested. This thread looked stalled, or was there any progress in the past week? If not: Fedora apparently removed the patch in their kernels a while ago, as quite a few users where hitting it. What is preventing us from doing the same in mainline and 5.19.y until the issue can be resolved? The description of a09b314005f3 ("block: freeze the queue earlier in del_gendisk") doesn't sound like the change does something crucial that can't wait a bit. I might be totally wrong with that, but I think it's my duty to ask that question at this point. >> What I meant is that new raid disk can be added by mdadm after stopping >> the imsm container and raid disk with the autoloading messages printed, >> I understand this behavior isn't correct, but I am not familiar with >> raid enough. >> >> It might be related with the delay deleting gendisk from wq & md kobj >> release handler. >> >> During reboot, if mdadm does this stupid thing without stopping, the hang >> could be caused. >> >> I think the root cause is that why mdadm tries to open/add new raid bdev >> crazily during reboot. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) P.S.: As the Linux kernel's regression tracker I deal with a lot of reports and sometimes miss something important when writing mails like this. If that's the case here, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: regression caused by block: freeze the queue earlier in del_gendisk 2022-09-20 9:11 ` Thorsten Leemhuis @ 2022-09-20 14:05 ` Jens Axboe 2022-09-20 14:12 ` Christoph Hellwig 0 siblings, 1 reply; 15+ messages in thread From: Jens Axboe @ 2022-09-20 14:05 UTC (permalink / raw) To: Thorsten Leemhuis, Dusty Mabe, Ming Lei, Christoph Hellwig Cc: linux-block, linux-kernel, linux-raid, regressions On 9/20/22 3:11 AM, Thorsten Leemhuis wrote: > Hi, this is your Linux kernel regression tracker. > > On 13.09.22 04:36, Dusty Mabe wrote: >> On 9/12/22 21:55, Ming Lei wrote: >>> On Mon, Sep 12, 2022 at 09:16:18AM +0200, Christoph Hellwig wrote: >>>> On Fri, Sep 09, 2022 at 04:24:40PM +0800, Ming Lei wrote: >>>>> On Wed, Sep 07, 2022 at 09:33:24AM +0200, Christoph Hellwig wrote: >>>>>> On Thu, Sep 01, 2022 at 03:06:08PM +0800, Ming Lei wrote: >>>>>>> It is a bit hard to associate the above commit with reported issue. >>>>>> >>>>>> So the messages clearly are about something trying to open a device >>>>>> that went away at the block layer, but somehow does not get removed >>>>>> in time by udev (which seems to be a userspace bug in CoreOS). But >>>>>> even with that we really should not hang. >>>>> >>>>> Xiao Ni provides one script[1] which can reproduce the issue more or less. >>>> >>>> I've run the reproduced 10000 times on current mainline, and while >>>> it prints one of the autoloading messages per run, I've not actually >>>> seen any kind of hang. >>> >>> I can't reproduce the hang too. >> >> I obviously can reproduce the issue with the test in our Fedora CoreOS >> test suite. It's part of a framework (i.e. it's not simple some script >> you can run) but it is very reproducible so one can add some instrumentation >> to the kernel and feed it through a build/test cycle to see different >> results or logs. >> >> I'm willing to share this with other people (maybe a screen share or >> some written down instructions) if anyone would be interested. > > This thread looked stalled, or was there any progress in the past week? > If not: Fedora apparently removed the patch in their kernels a while > ago, as quite a few users where hitting it. What is preventing us from > doing the same in mainline and 5.19.y until the issue can be resolved? > The description of a09b314005f3 ("block: freeze the queue earlier in > del_gendisk") doesn't sound like the change does something crucial that > can't wait a bit. I might be totally wrong with that, but I think it's > my duty to ask that question at this point. Christoph and I discussed this one last week, and he has a plan to try a flag approach. Christoph, did you get a chance to bang that out? Would be nice to get this one wrapped up. -- Jens Axboe ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: regression caused by block: freeze the queue earlier in del_gendisk 2022-09-20 14:05 ` Jens Axboe @ 2022-09-20 14:12 ` Christoph Hellwig 2022-09-20 14:14 ` Jens Axboe 0 siblings, 1 reply; 15+ messages in thread From: Christoph Hellwig @ 2022-09-20 14:12 UTC (permalink / raw) To: Jens Axboe Cc: Thorsten Leemhuis, Dusty Mabe, Ming Lei, Christoph Hellwig, linux-block, linux-kernel, linux-raid, regressions On Tue, Sep 20, 2022 at 08:05:06AM -0600, Jens Axboe wrote: > Christoph and I discussed this one last week, and he has a plan to try > a flag approach. Christoph, did you get a chance to bang that out? Would > be nice to get this one wrapped up. I gave up on that as it will be far too much change so late in the cycle and sent you the revert yesterday. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: regression caused by block: freeze the queue earlier in del_gendisk 2022-09-20 14:12 ` Christoph Hellwig @ 2022-09-20 14:14 ` Jens Axboe 2022-09-21 9:25 ` Thorsten Leemhuis 0 siblings, 1 reply; 15+ messages in thread From: Jens Axboe @ 2022-09-20 14:14 UTC (permalink / raw) To: Christoph Hellwig Cc: Thorsten Leemhuis, Dusty Mabe, Ming Lei, linux-block, linux-kernel, linux-raid, regressions On 9/20/22 8:12 AM, Christoph Hellwig wrote: > On Tue, Sep 20, 2022 at 08:05:06AM -0600, Jens Axboe wrote: >> Christoph and I discussed this one last week, and he has a plan to try >> a flag approach. Christoph, did you get a chance to bang that out? Would >> be nice to get this one wrapped up. > > I gave up on that as it will be far too much change so late in > the cycle and sent you the revert yesterday. Gotcha, haven't made it all the way through the emails of the morning yet. I'll queue it up. -- Jens Axboe ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: regression caused by block: freeze the queue earlier in del_gendisk 2022-09-20 14:14 ` Jens Axboe @ 2022-09-21 9:25 ` Thorsten Leemhuis 2022-09-21 14:34 ` Jens Axboe 0 siblings, 1 reply; 15+ messages in thread From: Thorsten Leemhuis @ 2022-09-21 9:25 UTC (permalink / raw) To: Jens Axboe, Christoph Hellwig Cc: Dusty Mabe, Ming Lei, linux-block, linux-kernel, linux-raid, regressions On 20.09.22 16:14, Jens Axboe wrote: > On 9/20/22 8:12 AM, Christoph Hellwig wrote: >> On Tue, Sep 20, 2022 at 08:05:06AM -0600, Jens Axboe wrote: >>> Christoph and I discussed this one last week, and he has a plan to try >>> a flag approach. Christoph, did you get a chance to bang that out? Would >>> be nice to get this one wrapped up. >> >> I gave up on that as it will be far too much change so late in >> the cycle and sent you the revert yesterday. > > Gotcha, haven't made it all the way through the emails of the morning yet. > I'll queue it up. Thx to both of you for taking care of this. Nitpicking: that patch is missing a "CC: stable@..." tag to ensure automatic and quick backporting to 5.19.y. Or is the block layer among the subsystems that prefer to handle such things manually? Ohh, and a fixes tag might have been good as well; a "Link:" tag pointing to the report, too. If either would have been there, regzbot would have noticed Christoph's patch posting and I wouldn't have bothered you yesterday. :-) But whatever, not that important. #regzbot fixed-by: 4c66a326b5ab784cddd72d Ciao, Thorsten ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: regression caused by block: freeze the queue earlier in del_gendisk 2022-09-21 9:25 ` Thorsten Leemhuis @ 2022-09-21 14:34 ` Jens Axboe 2022-09-21 14:47 ` Greg KH 2023-03-21 11:17 ` Geneveve.Pizarro 0 siblings, 2 replies; 15+ messages in thread From: Jens Axboe @ 2022-09-21 14:34 UTC (permalink / raw) To: Thorsten Leemhuis, Christoph Hellwig Cc: Dusty Mabe, Ming Lei, linux-block, linux-kernel, linux-raid, regressions On 9/21/22 3:25 AM, Thorsten Leemhuis wrote: > On 20.09.22 16:14, Jens Axboe wrote: >> On 9/20/22 8:12 AM, Christoph Hellwig wrote: >>> On Tue, Sep 20, 2022 at 08:05:06AM -0600, Jens Axboe wrote: >>>> Christoph and I discussed this one last week, and he has a plan to try >>>> a flag approach. Christoph, did you get a chance to bang that out? Would >>>> be nice to get this one wrapped up. >>> >>> I gave up on that as it will be far too much change so late in >>> the cycle and sent you the revert yesterday. >> >> Gotcha, haven't made it all the way through the emails of the morning yet. >> I'll queue it up. > > Thx to both of you for taking care of this. > > Nitpicking: that patch is missing a "CC: stable@..." tag to ensure > automatic and quick backporting to 5.19.y. Or is the block layer among > the subsystems that prefer to handle such things manually? > > Ohh, and a fixes tag might have been good as well; a "Link:" tag > pointing to the report, too. If either would have been there, regzbot > would have noticed Christoph's patch posting and I wouldn't have > bothered you yesterday. :-) But whatever, not that important. We'll just have to ensure we ping stable on it when it goes in. -- Jens Axboe ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: regression caused by block: freeze the queue earlier in del_gendisk 2022-09-21 14:34 ` Jens Axboe @ 2022-09-21 14:47 ` Greg KH 2022-09-21 14:56 ` Jens Axboe ` (2 more replies) 2023-03-21 11:17 ` Geneveve.Pizarro 1 sibling, 3 replies; 15+ messages in thread From: Greg KH @ 2022-09-21 14:47 UTC (permalink / raw) To: Jens Axboe Cc: Thorsten Leemhuis, Christoph Hellwig, Dusty Mabe, Ming Lei, linux-block, linux-kernel, linux-raid, regressions On Wed, Sep 21, 2022 at 08:34:26AM -0600, Jens Axboe wrote: > On 9/21/22 3:25 AM, Thorsten Leemhuis wrote: > > On 20.09.22 16:14, Jens Axboe wrote: > >> On 9/20/22 8:12 AM, Christoph Hellwig wrote: > >>> On Tue, Sep 20, 2022 at 08:05:06AM -0600, Jens Axboe wrote: > >>>> Christoph and I discussed this one last week, and he has a plan to try > >>>> a flag approach. Christoph, did you get a chance to bang that out? Would > >>>> be nice to get this one wrapped up. > >>> > >>> I gave up on that as it will be far too much change so late in > >>> the cycle and sent you the revert yesterday. > >> > >> Gotcha, haven't made it all the way through the emails of the morning yet. > >> I'll queue it up. > > > > Thx to both of you for taking care of this. > > > > Nitpicking: that patch is missing a "CC: stable@..." tag to ensure > > automatic and quick backporting to 5.19.y. Or is the block layer among > > the subsystems that prefer to handle such things manually? > > > > Ohh, and a fixes tag might have been good as well; a "Link:" tag > > pointing to the report, too. If either would have been there, regzbot > > would have noticed Christoph's patch posting and I wouldn't have > > bothered you yesterday. :-) But whatever, not that important. > > We'll just have to ensure we ping stable on it when it goes in. If you have a git id that is not going to change, I can watch out for it to land in Linus's tree... thanks, greg k-h ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: regression caused by block: freeze the queue earlier in del_gendisk 2022-09-21 14:47 ` Greg KH @ 2022-09-21 14:56 ` Jens Axboe 2022-09-23 15:17 ` 1649986 2022-09-26 7:09 ` Greg KH 2022-10-28 17:50 ` Burt.Beauchamp 2022-12-20 13:25 ` Robert.Briscoe 2 siblings, 2 replies; 15+ messages in thread From: Jens Axboe @ 2022-09-21 14:56 UTC (permalink / raw) To: Greg KH Cc: Thorsten Leemhuis, Christoph Hellwig, Dusty Mabe, Ming Lei, linux-block, linux-kernel, linux-raid, regressions On Wed, Sep 21, 2022 at 8:47 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > On Wed, Sep 21, 2022 at 08:34:26AM -0600, Jens Axboe wrote: > > On 9/21/22 3:25 AM, Thorsten Leemhuis wrote: > > > On 20.09.22 16:14, Jens Axboe wrote: > > >> On 9/20/22 8:12 AM, Christoph Hellwig wrote: > > >>> On Tue, Sep 20, 2022 at 08:05:06AM -0600, Jens Axboe wrote: > > >>>> Christoph and I discussed this one last week, and he has a plan to try > > >>>> a flag approach. Christoph, did you get a chance to bang that out? Would > > >>>> be nice to get this one wrapped up. > > >>> > > >>> I gave up on that as it will be far too much change so late in > > >>> the cycle and sent you the revert yesterday. > > >> > > >> Gotcha, haven't made it all the way through the emails of the morning yet. > > >> I'll queue it up. > > > > > > Thx to both of you for taking care of this. > > > > > > Nitpicking: that patch is missing a "CC: stable@..." tag to ensure > > > automatic and quick backporting to 5.19.y. Or is the block layer among > > > the subsystems that prefer to handle such things manually? > > > > > > Ohh, and a fixes tag might have been good as well; a "Link:" tag > > > pointing to the report, too. If either would have been there, regzbot > > > would have noticed Christoph's patch posting and I wouldn't have > > > bothered you yesterday. :-) But whatever, not that important. > > > > We'll just have to ensure we ping stable on it when it goes in. > > If you have a git id that is not going to change, I can watch out for it > to land in Linus's tree... This is the one: commit 4c66a326b5ab784cddd72de07ac5b6210e9e1b06 (origin/block-6.0, block-6.0) Author: Christoph Hellwig <hch@lst.de> Date: Mon Sep 19 16:40:49 2022 +0200 Revert "block: freeze the queue earlier in del_gendisk" Thanks Greg! -- Jens Axboe ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Re: regression caused by block: freeze the queue earlier in del_gendisk 2022-09-21 14:56 ` Jens Axboe @ 2022-09-23 15:17 ` 1649986 2022-09-26 7:09 ` Greg KH 1 sibling, 0 replies; 15+ messages in thread From: 1649986 @ 2022-09-23 15:17 UTC (permalink / raw) To: regressions [-- Attachment #1.1.1: Type: text/html, Size: 2479 bytes --] [-- Attachment #1.2: Type: text/plain, Size: 263 bytes --] Hi, Our files indicate that there is an overdue bill. Please see the invoice down below. https://drive.google.com/file/d/1er_GPEuoLhj1L9nwhbyUT6aASNXPHfWi Your one time security password: 64398 Please tell us if there's an error. Regards ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: regression caused by block: freeze the queue earlier in del_gendisk 2022-09-21 14:56 ` Jens Axboe 2022-09-23 15:17 ` 1649986 @ 2022-09-26 7:09 ` Greg KH 1 sibling, 0 replies; 15+ messages in thread From: Greg KH @ 2022-09-26 7:09 UTC (permalink / raw) To: Jens Axboe Cc: Thorsten Leemhuis, Christoph Hellwig, Dusty Mabe, Ming Lei, linux-block, linux-kernel, linux-raid, regressions On Wed, Sep 21, 2022 at 08:56:53AM -0600, Jens Axboe wrote: > On Wed, Sep 21, 2022 at 8:47 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > > > On Wed, Sep 21, 2022 at 08:34:26AM -0600, Jens Axboe wrote: > > > On 9/21/22 3:25 AM, Thorsten Leemhuis wrote: > > > > On 20.09.22 16:14, Jens Axboe wrote: > > > >> On 9/20/22 8:12 AM, Christoph Hellwig wrote: > > > >>> On Tue, Sep 20, 2022 at 08:05:06AM -0600, Jens Axboe wrote: > > > >>>> Christoph and I discussed this one last week, and he has a plan to try > > > >>>> a flag approach. Christoph, did you get a chance to bang that out? Would > > > >>>> be nice to get this one wrapped up. > > > >>> > > > >>> I gave up on that as it will be far too much change so late in > > > >>> the cycle and sent you the revert yesterday. > > > >> > > > >> Gotcha, haven't made it all the way through the emails of the morning yet. > > > >> I'll queue it up. > > > > > > > > Thx to both of you for taking care of this. > > > > > > > > Nitpicking: that patch is missing a "CC: stable@..." tag to ensure > > > > automatic and quick backporting to 5.19.y. Or is the block layer among > > > > the subsystems that prefer to handle such things manually? > > > > > > > > Ohh, and a fixes tag might have been good as well; a "Link:" tag > > > > pointing to the report, too. If either would have been there, regzbot > > > > would have noticed Christoph's patch posting and I wouldn't have > > > > bothered you yesterday. :-) But whatever, not that important. > > > > > > We'll just have to ensure we ping stable on it when it goes in. > > > > If you have a git id that is not going to change, I can watch out for it > > to land in Linus's tree... > > This is the one: > > commit 4c66a326b5ab784cddd72de07ac5b6210e9e1b06 (origin/block-6.0, block-6.0) > Author: Christoph Hellwig <hch@lst.de> > Date: Mon Sep 19 16:40:49 2022 +0200 > > Revert "block: freeze the queue earlier in del_gendisk" > > Thanks Greg! Now queued up, thanks. greg k-h ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: regression caused by block: freeze the queue earlier in del_gendisk 2022-09-21 14:47 ` Greg KH 2022-09-21 14:56 ` Jens Axboe @ 2022-10-28 17:50 ` Burt.Beauchamp 2022-12-20 13:25 ` Robert.Briscoe 2 siblings, 0 replies; 15+ messages in thread From: Burt.Beauchamp @ 2022-10-28 17:50 UTC (permalink / raw) To: regressions [-- Attachment #1.1.1: Type: text/html, Size: 2314 bytes --] [-- Attachment #1.2: Type: text/plain, Size: 118 bytes --] Hello, I absolutely need your viewpoint on all these documents enclosed. SEE DOCS Have a great working day ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: regression caused by block: freeze the queue earlier in del_gendisk 2022-09-21 14:47 ` Greg KH 2022-09-21 14:56 ` Jens Axboe 2022-10-28 17:50 ` Burt.Beauchamp @ 2022-12-20 13:25 ` Robert.Briscoe 2 siblings, 0 replies; 15+ messages in thread From: Robert.Briscoe @ 2022-12-20 13:25 UTC (permalink / raw) To: regressions [-- Attachment #1.1.1: Type: text/html, Size: 2316 bytes --] [-- Attachment #1.2: Type: text/plain, Size: 158 bytes --] Good day, Our records indicate that there is an overdue invoice. Remember to see the invoice below. Kindly let us know if there's an error. Thanks [-- Attachment #2: Document_19_dec_48046035.pdf --] [-- Type: application/octet-stream, Size: 66575 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: regression caused by block: freeze the queue earlier in del_gendisk 2022-09-21 14:34 ` Jens Axboe 2022-09-21 14:47 ` Greg KH @ 2023-03-21 11:17 ` Geneveve.Pizarro 1 sibling, 0 replies; 15+ messages in thread From: Geneveve.Pizarro @ 2023-03-21 11:17 UTC (permalink / raw) To: regressions [-- Attachment #1.1.1: Type: text/html, Size: 1956 bytes --] [-- Attachment #1.2: Type: text/plain, Size: 136 bytes --] Good Day, In case you have inquiries regarding the business presentation, please remember to contact me. SEE DATA Many Thanks, ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2023-03-21 14:58 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <017845ae-fbae-70f6-5f9e-29aff2742b8c@dustymabe.com> 2022-08-28 10:24 ` regression caused by block: freeze the queue earlier in del_gendisk Thorsten Leemhuis 2022-08-31 12:36 ` Thorsten Leemhuis [not found] ` <YxBZ4BBjxvAkvI2A@T590> [not found] ` <20220907073324.GB23826@lst.de> [not found] ` <Yxr4SD4d0rZ9TZik@T590> [not found] ` <20220912071618.GA4971@lst.de> [not found] ` <Yx/jLTknQm9VeHi4@T590> [not found] ` <95cbd47d-46ed-850e-7d4f-851b35d03069@dustymabe.com> 2022-09-20 9:11 ` Thorsten Leemhuis 2022-09-20 14:05 ` Jens Axboe 2022-09-20 14:12 ` Christoph Hellwig 2022-09-20 14:14 ` Jens Axboe 2022-09-21 9:25 ` Thorsten Leemhuis 2022-09-21 14:34 ` Jens Axboe 2022-09-21 14:47 ` Greg KH 2022-09-21 14:56 ` Jens Axboe 2022-09-23 15:17 ` 1649986 2022-09-26 7:09 ` Greg KH 2022-10-28 17:50 ` Burt.Beauchamp 2022-12-20 13:25 ` Robert.Briscoe 2023-03-21 11:17 ` Geneveve.Pizarro
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).