regressions.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* 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

* 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).