On 20-12-23 17:27:37, Christoph Hellwig wrote: > On Thu, Dec 24, 2020 at 01:16:50AM +0900, Minwoo Im wrote: > > Hello, > > > > On 20-12-23 16:49:04, Christoph Hellwig wrote: > > > set_blocksize just sets the block sise used for buffer heads and should > > > not be called by the driver. blkdev_get updates the block size, so > > > you must already have the fd re-reading the partition table open? > > > I'm not entirely sure how we can work around this except by avoiding > > > buffer head I/O in the partition reread code. Note that this affects > > > all block drivers where the block size could change at runtime. > > > > Thank you Christoph for your comment on this. > > > > Agreed. BLKRRPART leads us to block_read_full_page which takes buffer > > heads for I/O. > > > > Yes, __blkdev_get() sets i_blkbits of block device inode via > > set_init_blocksize. And Yes again as nvme-cli already opened the block > > device fd and requests the BLKRRPART with that fd. Also, __bdev_get() > > only updates the i_blkbits(blocksize) in case bdev->bd_openers == 0 which > > is the first time to open this block device. > > > > Then, how about having NVMe driver prevent underflow case for the > > request->__data_len is smaller than the logical block size like: > > Not sure this helps. I think we need to fix this proper and in the > block layer. The long term fix is to stop messing with i_blksize > at all, but that is going to take very long. Agreed. > > I think for now the only thing we can do is to set a flag in the > gendisk when the block size changes and then reject all I/O until > the next first open that sets the blocksize. Let me prepare work around patch for this issue soon. Thanks!
