linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2] fs/buffer: use min folio order to calculate upper limit in __getblk_slow()
@ 2025-06-19 12:10 Pankaj Raghav
  2025-06-19 12:59 ` Matthew Wilcox
  0 siblings, 1 reply; 3+ messages in thread
From: Pankaj Raghav @ 2025-06-19 12:10 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/

Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>
---
Changes since v1:
- Rebased on top of vfs/vfs-6.17.misc as it has a merge conflict.
- Added RVB tag from Jan Kara.

 fs/buffer.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/buffer.c b/fs/buffer.c
index a14d281c6a74..445df839a0f0 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1121,9 +1121,10 @@ __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);
 
 	if (unlikely(size & (bdev_logical_block_size(bdev) - 1) ||
-		     (size < 512 || size > PAGE_SIZE))) {
+		     (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: 6ae58121126dcf8efcc2611f216a36a5e50b8ad9
-- 
2.49.0


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH v2] fs/buffer: use min folio order to calculate upper limit in __getblk_slow()
  2025-06-19 12:10 [PATCH v2] fs/buffer: use min folio order to calculate upper limit in __getblk_slow() Pankaj Raghav
@ 2025-06-19 12:59 ` Matthew Wilcox
  2025-06-19 13:57   ` Pankaj Raghav (Samsung)
  0 siblings, 1 reply; 3+ messages in thread
From: Matthew Wilcox @ 2025-06-19 12:59 UTC (permalink / raw)
  To: Pankaj Raghav
  Cc: Alexander Viro, Jan Kara, mcgrof, Christian Brauner,
	linux-fsdevel, linux-kernel, gost.dev, kernel

On Thu, Jun 19, 2025 at 02:10:58PM +0200, Pankaj Raghav wrote:
> +++ b/fs/buffer.c
> @@ -1121,9 +1121,10 @@ __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);
>  
>  	if (unlikely(size & (bdev_logical_block_size(bdev) - 1) ||
> -		     (size < 512 || size > PAGE_SIZE))) {
> +		     (size < 512 || size > (1U << blocklog)))) {
>  		printk(KERN_ERR "getblk(): invalid block size %d requested\n",
>  					size);
>  		printk(KERN_ERR "logical block size: %d\n",

Is this what we want though?  If ext4 wants to create an 8kB block size
filesystem on top of a 512 byte sector size device, shouldn't it be
allowed to?  So just drop the max:

 	if (unlikely(size & (bdev_logical_block_size(bdev) - 1) ||
-		     (size < 512 || size > PAGE_SIZE))) {
+		     (size < 512)))) {

(also, surely logical_block_size is always at least 512, so do we really
need this check at all?)

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH v2] fs/buffer: use min folio order to calculate upper limit in __getblk_slow()
  2025-06-19 12:59 ` Matthew Wilcox
@ 2025-06-19 13:57   ` Pankaj Raghav (Samsung)
  0 siblings, 0 replies; 3+ messages in thread
From: Pankaj Raghav (Samsung) @ 2025-06-19 13:57 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Pankaj Raghav, Alexander Viro, Jan Kara, mcgrof,
	Christian Brauner, linux-fsdevel, linux-kernel, gost.dev

On Thu, Jun 19, 2025 at 01:59:12PM +0100, Matthew Wilcox wrote:
> On Thu, Jun 19, 2025 at 02:10:58PM +0200, Pankaj Raghav wrote:
> > +++ b/fs/buffer.c
> > @@ -1121,9 +1121,10 @@ __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);
> >  
> >  	if (unlikely(size & (bdev_logical_block_size(bdev) - 1) ||
> > -		     (size < 512 || size > PAGE_SIZE))) {
> > +		     (size < 512 || size > (1U << blocklog)))) {
> >  		printk(KERN_ERR "getblk(): invalid block size %d requested\n",
> >  					size);
> >  		printk(KERN_ERR "logical block size: %d\n",
> 
> Is this what we want though?  If ext4 wants to create an 8kB block size
> filesystem on top of a 512 byte sector size device, shouldn't it be

That will not be a problem because we set the min order of the FS on the
block device[1] from ext4[2] through set_blocksize() routine.

> allowed to?  So just drop the max:

But I do agree with dropping it because we have these checks all over the
place. So the question is: do we need it again in a low level function
such as __getblk_slow().

> 
>  	if (unlikely(size & (bdev_logical_block_size(bdev) - 1) ||
> -		     (size < 512 || size > PAGE_SIZE))) {
> +		     (size < 512)))) {
> 
> (also, surely logical_block_size is always at least 512, so do we really
> need this check at all?)

True!

Just the alignment check with logical block size should be enough.

--
Pankaj

[1] https://elixir.bootlin.com/linux/v6.16-rc2/source/block/bdev.c#L210
[2] https://elixir.bootlin.com/linux/v6.16-rc2/source/fs/ext4/super.c#L5110

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2025-06-19 13:57 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-19 12:10 [PATCH v2] fs/buffer: use min folio order to calculate upper limit in __getblk_slow() Pankaj Raghav
2025-06-19 12:59 ` Matthew Wilcox
2025-06-19 13:57   ` Pankaj Raghav (Samsung)

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