[GIT PULL] Block fix for 5.12 final

[GIT PULL] Block fix for 5.12 final

[Jens Axboe]

Hi Linus,

A single fix for a behavioral regression in this series, when re-reading
the partition table with partitions open. Please pull!


The following changes since commit f06c609645ecd043c79380fac94145926603fb33:

  block: remove the unused RQF_ALLOCED flag (2021-04-02 11:18:31 -0600)

are available in the Git repository at:

  git://git.kernel.dk/linux-block.git tags/block-5.12-2021-04-23

for you to fetch changes up to 68e6582e8f2dc32fd2458b9926564faa1fb4560e:

  block: return -EBUSY when there are open partitions in blkdev_reread_part (2021-04-21 10:49:37 -0600)

----------------------------------------------------------------
block-5.12-2021-04-23

----------------------------------------------------------------
Christoph Hellwig (1):
      block: return -EBUSY when there are open partitions in blkdev_reread_part

 block/ioctl.c | 2 ++
 1 file changed, 2 insertions(+)

-- 
Jens Axboe

Re: [GIT PULL] Block fix for 5.12 final

[Linus Torvalds]

On Fri, Apr 23, 2021 at 2:06 PM Jens Axboe <axboe@kernel.dk> wrote:
>
> A single fix for a behavioral regression in this series, when re-reading
> the partition table with partitions open.

Hmm. The fact that it's no longer calling blk_drop_partitions() didn't
just mean that the check for "bdev->bd_part_count" was lost (now
re-instated).

It also seems to mean that blkdev_reread_part() no longer does the

        sync_blockdev(bdev);
        invalidate_bdev(bdev);

to write back and invalidate any caches.

Are we sure cache writeback/invalidate isn't needed? Or does it get
done some other place?

            Linus

Re: [GIT PULL] Block fix for 5.12 final

[pr-tracker-bot]

The pull request you sent on Fri, 23 Apr 2021 15:06:07 -0600:

> git://git.kernel.dk/linux-block.git tags/block-5.12-2021-04-23

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/95838bd9fcfaa12452dc9fd6d6920faef6bb5a46

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] Block fix for 5.12 final

[Jens Axboe]

On 4/23/21 3:54 PM, Linus Torvalds wrote:
> On Fri, Apr 23, 2021 at 2:06 PM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> A single fix for a behavioral regression in this series, when re-reading
>> the partition table with partitions open.
> 
> Hmm. The fact that it's no longer calling blk_drop_partitions() didn't
> just mean that the check for "bdev->bd_part_count" was lost (now
> re-instated).
> 
> It also seems to mean that blkdev_reread_part() no longer does the
> 
>         sync_blockdev(bdev);
>         invalidate_bdev(bdev);
> 
> to write back and invalidate any caches.
> 
> Are we sure cache writeback/invalidate isn't needed? Or does it get
> done some other place?

Hmm yes, that's a good point, we dropped both of those in the call trace
as part of 4601b4b130de2329fe06df80ed5d77265f2058e5 - Christoph, what
was the reasoning here?

-- 
Jens Axboe

Re: [GIT PULL] Block fix for 5.12 final

[Christoph Hellwig]

On Fri, Apr 23, 2021 at 02:54:36PM -0700, Linus Torvalds wrote:
> On Fri, Apr 23, 2021 at 2:06 PM Jens Axboe <axboe@kernel.dk> wrote:
> >
> > A single fix for a behavioral regression in this series, when re-reading
> > the partition table with partitions open.
> 
> Hmm. The fact that it's no longer calling blk_drop_partitions() didn't
> just mean that the check for "bdev->bd_part_count" was lost (now
> re-instated).

It still calls blk_drop_partitions:

  blkdev_reread_part
    -> blkdev_get_by_dev
      -> __blkdev_get
        -> bdev_disk_changed
	  -> blk_drop_partitions

The difference is that before blkdev_reread_part called
bdev_disk_changed directly.  We now do it through blkdev_get to hook
into the driver.  But __blkdev_get ignores the return value from
bdev_disk_changed.

> It also seems to mean that blkdev_reread_part() no longer does the
> 
>         sync_blockdev(bdev);
>         invalidate_bdev(bdev);
> 
> to write back and invalidate any caches.
> 
> Are we sure cache writeback/invalidate isn't needed? Or does it get
> done some other place?

It is still in place.  But given how our cache coherency works not
actually needed anyway, but peeling that onion will take a while.