* [PATCH] fs/buffer: use min folio order to calculate upper limit in __getblk_slow()
@ 2025-06-18 9:17 Pankaj Raghav
2025-06-18 15:40 ` Jan Kara
0 siblings, 1 reply; 4+ messages in thread
From: Pankaj Raghav @ 2025-06-18 9:17 UTC (permalink / raw)
To: Alexander Viro, Jan Kara, mcgrof, Christian Brauner
Cc: linux-fsdevel, linux-kernel, gost.dev, kernel, Pankaj Raghav
The maximum IO size that a block device can read as a single block is
based on the min folio order and not the PAGE_SIZE as we have bs > ps
support for block devices[1].
Calculate the upper limit based on the on min folio order.
[1] https://lore.kernel.org/linux-block/20250221223823.1680616-1-mcgrof@kernel.org/
Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>
---
I found this while I was adding bs > ps support to ext4. Ext4 uses this
routine to read the superblock.
fs/buffer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index 8cf4a1dc481e..98f90da69a0a 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1121,10 +1121,11 @@ __getblk_slow(struct block_device *bdev, sector_t block,
unsigned size, gfp_t gfp)
{
bool blocking = gfpflags_allow_blocking(gfp);
+ int blocklog = PAGE_SHIFT + mapping_min_folio_order(bdev->bd_mapping);
/* Size must be multiple of hard sectorsize */
- if (unlikely(size & (bdev_logical_block_size(bdev)-1) ||
- (size < 512 || size > PAGE_SIZE))) {
+ if (unlikely(size & (bdev_logical_block_size(bdev) - 1) ||
+ (size < 512 || size > (1U << blocklog)))) {
printk(KERN_ERR "getblk(): invalid block size %d requested\n",
size);
printk(KERN_ERR "logical block size: %d\n",
base-commit: e04c78d86a9699d136910cfc0bdcf01087e3267e
--
2.49.0
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] fs/buffer: use min folio order to calculate upper limit in __getblk_slow()
2025-06-18 9:17 [PATCH] fs/buffer: use min folio order to calculate upper limit in __getblk_slow() Pankaj Raghav
@ 2025-06-18 15:40 ` Jan Kara
2025-06-18 19:50 ` Pankaj Raghav (Samsung)
0 siblings, 1 reply; 4+ messages in thread
From: Jan Kara @ 2025-06-18 15:40 UTC (permalink / raw)
To: Pankaj Raghav
Cc: Alexander Viro, Jan Kara, mcgrof, Christian Brauner,
linux-fsdevel, linux-kernel, gost.dev, kernel
On Wed 18-06-25 11:17:10, Pankaj Raghav wrote:
> The maximum IO size that a block device can read as a single block is
> based on the min folio order and not the PAGE_SIZE as we have bs > ps
> support for block devices[1].
>
> Calculate the upper limit based on the on min folio order.
>
> [1] https://lore.kernel.org/linux-block/20250221223823.1680616-1-mcgrof@kernel.org/
>
> Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>
...
> ---
> I found this while I was adding bs > ps support to ext4. Ext4 uses this
> routine to read the superblock.
>
> fs/buffer.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/fs/buffer.c b/fs/buffer.c
> index 8cf4a1dc481e..98f90da69a0a 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -1121,10 +1121,11 @@ __getblk_slow(struct block_device *bdev, sector_t block,
> unsigned size, gfp_t gfp)
> {
> bool blocking = gfpflags_allow_blocking(gfp);
> + int blocklog = PAGE_SHIFT + mapping_min_folio_order(bdev->bd_mapping);
>
> /* Size must be multiple of hard sectorsize */
> - if (unlikely(size & (bdev_logical_block_size(bdev)-1) ||
> - (size < 512 || size > PAGE_SIZE))) {
> + if (unlikely(size & (bdev_logical_block_size(bdev) - 1) ||
> + (size < 512 || size > (1U << blocklog)))) {
So this doesn't quite make sense to me. Shouldn't it be capped from above
by PAGE_SIZE << mapping_max_folio_order(bdev->bd_mapping)?
Honza
> printk(KERN_ERR "getblk(): invalid block size %d requested\n",
> size);
> printk(KERN_ERR "logical block size: %d\n",
>
> base-commit: e04c78d86a9699d136910cfc0bdcf01087e3267e
> --
> 2.49.0
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] fs/buffer: use min folio order to calculate upper limit in __getblk_slow()
2025-06-18 15:40 ` Jan Kara
@ 2025-06-18 19:50 ` Pankaj Raghav (Samsung)
2025-06-19 10:13 ` Jan Kara
0 siblings, 1 reply; 4+ messages in thread
From: Pankaj Raghav (Samsung) @ 2025-06-18 19:50 UTC (permalink / raw)
To: Jan Kara
Cc: Pankaj Raghav, Alexander Viro, mcgrof, Christian Brauner,
linux-fsdevel, linux-kernel, gost.dev
> > diff --git a/fs/buffer.c b/fs/buffer.c
> > index 8cf4a1dc481e..98f90da69a0a 100644
> > --- a/fs/buffer.c
> > +++ b/fs/buffer.c
> > @@ -1121,10 +1121,11 @@ __getblk_slow(struct block_device *bdev, sector_t block,
> > unsigned size, gfp_t gfp)
> > {
> > bool blocking = gfpflags_allow_blocking(gfp);
> > + int blocklog = PAGE_SHIFT + mapping_min_folio_order(bdev->bd_mapping);
> >
> > /* Size must be multiple of hard sectorsize */
> > - if (unlikely(size & (bdev_logical_block_size(bdev)-1) ||
> > - (size < 512 || size > PAGE_SIZE))) {
> > + if (unlikely(size & (bdev_logical_block_size(bdev) - 1) ||
> > + (size < 512 || size > (1U << blocklog)))) {
>
> So this doesn't quite make sense to me. Shouldn't it be capped from above
> by PAGE_SIZE << mapping_max_folio_order(bdev->bd_mapping)?
This __getblk_slow() function is used to read a block from a block
device and fill the page cache along with creating buffer heads.
I think the reason we have this check is to make sure the size, which is
block size is within the limits from 512 (SECTOR_SIZE) to upper limit on block size.
That upper limit on block size was PAGE_SIZE before the lbs support in
block devices, but now the upper limit of block size is mapping_min_folio_order.
We set that in set_blocksize(). So a single block cannot be bigger than
(PAGE_SIZE << mapping_min_folio_order).
I hope that makes sense.
--
Pankaj Raghav
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] fs/buffer: use min folio order to calculate upper limit in __getblk_slow()
2025-06-18 19:50 ` Pankaj Raghav (Samsung)
@ 2025-06-19 10:13 ` Jan Kara
0 siblings, 0 replies; 4+ messages in thread
From: Jan Kara @ 2025-06-19 10:13 UTC (permalink / raw)
To: Pankaj Raghav (Samsung)
Cc: Jan Kara, Pankaj Raghav, Alexander Viro, mcgrof,
Christian Brauner, linux-fsdevel, linux-kernel, gost.dev
On Wed 18-06-25 21:50:56, Pankaj Raghav (Samsung) wrote:
> > > diff --git a/fs/buffer.c b/fs/buffer.c
> > > index 8cf4a1dc481e..98f90da69a0a 100644
> > > --- a/fs/buffer.c
> > > +++ b/fs/buffer.c
> > > @@ -1121,10 +1121,11 @@ __getblk_slow(struct block_device *bdev, sector_t block,
> > > unsigned size, gfp_t gfp)
> > > {
> > > bool blocking = gfpflags_allow_blocking(gfp);
> > > + int blocklog = PAGE_SHIFT + mapping_min_folio_order(bdev->bd_mapping);
> > >
> > > /* Size must be multiple of hard sectorsize */
> > > - if (unlikely(size & (bdev_logical_block_size(bdev)-1) ||
> > > - (size < 512 || size > PAGE_SIZE))) {
> > > + if (unlikely(size & (bdev_logical_block_size(bdev) - 1) ||
> > > + (size < 512 || size > (1U << blocklog)))) {
> >
> > So this doesn't quite make sense to me. Shouldn't it be capped from above
> > by PAGE_SIZE << mapping_max_folio_order(bdev->bd_mapping)?
>
> This __getblk_slow() function is used to read a block from a block
> device and fill the page cache along with creating buffer heads.
>
> I think the reason we have this check is to make sure the size, which is
> block size is within the limits from 512 (SECTOR_SIZE) to upper limit on block size.
>
> That upper limit on block size was PAGE_SIZE before the lbs support in
> block devices, but now the upper limit of block size is mapping_min_folio_order.
> We set that in set_blocksize(). So a single block cannot be bigger than
> (PAGE_SIZE << mapping_min_folio_order).
Ah, right. Thanks for explanation. Feel free to add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-06-19 10:13 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-18 9:17 [PATCH] fs/buffer: use min folio order to calculate upper limit in __getblk_slow() Pankaj Raghav
2025-06-18 15:40 ` Jan Kara
2025-06-18 19:50 ` Pankaj Raghav (Samsung)
2025-06-19 10:13 ` Jan Kara
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).