mbox series

[v3,0/3] Limit NTFS_RW to page sizes smaller than 64k

Message ID 20211127154442.3676290-1-linux@roeck-us.net (mailing list archive)
Headers show
Series Limit NTFS_RW to page sizes smaller than 64k | expand

Message

Guenter Roeck Nov. 27, 2021, 3:44 p.m. UTC
This is the third attempt to fix the following build error.

fs/ntfs/aops.c: In function 'ntfs_write_mst_block':
fs/ntfs/aops.c:1311:1: error:
	the frame size of 2240 bytes is larger than 2048 bytes

The problem is that NTFS_RW code allocates page size dependent arrays on
the stack. This results in build failures if the page size is 64k or
larger.

Since commit f22969a66041 ("powerpc/64s: Default to 64K pages for 64 bit
book3s") this affects ppc:allmodconfig builds, but other architectures
supporting page sizes of 64k or larger are also affected.

Increasing the maximum frame size for affected architectures just to
silence this error does not really help. The frame size would have to be
set to a really large value for 256k pages. Also, a large frame size could
potentially result in stack overruns in this code and elsewhere and is
therefore not desirable. Make NTFS_RW dependent on page sizes smaller than
64k instead.

Previous attempts to fix the problem were local to the ntfs subsystem.
This attempt introduces the architecture independent configuration flag
PAGE_SIZE_LESS_THAN_64KB and uses it to restrict NTFS_RW. The last patch
of the series replaces a similar restriction for VMXNET3 with the new
flag. This patch is not necessary to fix the NTFS_RW problem and is
provided only for completeness.

Comments

Linus Torvalds Nov. 27, 2021, 5:49 p.m. UTC | #1
On Sat, Nov 27, 2021 at 7:44 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> This is the third attempt to fix the following build error.

Thanks, looks good to me.

Should I apply the patches directly, or were you planning on sending a
pull request when everybody was happy with it?

           Linus
Guenter Roeck Nov. 27, 2021, 10:26 p.m. UTC | #2
On 11/27/21 9:49 AM, Linus Torvalds wrote:
> On Sat, Nov 27, 2021 at 7:44 AM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> This is the third attempt to fix the following build error.
> 
> Thanks, looks good to me.
> 
> Should I apply the patches directly, or were you planning on sending a
> pull request when everybody was happy with it?
> 

Either way is fine with me. Either apply it now and have it fixed in -rc3,
or we can wait for a few days and I'll send you a pull request if there
are no objections by, say, Wednesday.

Guenter
Linus Torvalds Nov. 27, 2021, 10:31 p.m. UTC | #3
On Sat, Nov 27, 2021 at 2:26 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> Either way is fine with me. Either apply it now and have it fixed in -rc3,
> or we can wait for a few days and I'll send you a pull request if there
> are no objections by, say, Wednesday.

I'll just take the patches as-is and we can leave this issue behind us
(knock wood).

Thanks,

           Linus
Anton Altaparmakov Nov. 27, 2021, 10:44 p.m. UTC | #4
Hi Linus, Guenter,

> On 27 Nov 2021, at 22:31, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Sat, Nov 27, 2021 at 2:26 PM Guenter Roeck <linux@roeck-us.net> wrote:
>> 
>> Either way is fine with me. Either apply it now and have it fixed in -rc3,
>> or we can wait for a few days and I'll send you a pull request if there
>> are no objections by, say, Wednesday.
> 
> I'll just take the patches as-is and we can leave this issue behind us
> (knock wood).

That sounds good, thank you!

Best regards,

	Anton

> Thanks,
> 
>           Linus