linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [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).