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.
NTFS_RW and VMXNET3 require a page size smaller than 64kB. Add generic
Kconfig option for use outside architecture code to avoid architecture
specific Kconfig options in that code.
Suggested-by: Michael Ellerman <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
---
v3: Added patch: declare new configuration flag in generic code
arch/Kconfig | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/Kconfig b/arch/Kconfig
index 26b8ed11639d..d3c4ab249e9c 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -991,6 +991,16 @@ config HAVE_ARCH_COMPAT_MMAP_BASES
and vice-versa 32-bit applications to call 64-bit mmap().
Required for applications doing different bitness syscalls.
+config PAGE_SIZE_LESS_THAN_64KB
+ def_bool y
+ depends on !ARM64_64K_PAGES
+ depends on !IA64_PAGE_SIZE_64KB
+ depends on !PAGE_SIZE_64KB
+ depends on !PARISC_PAGE_SIZE_64KB
+ depends on !PPC_64K_PAGES
+ depends on !PPC_256K_PAGES
+ depends on !PAGE_SIZE_256KB
+
# This allows to use a set of generic functions to determine mmap base
# address by giving priority to top-down scheme only if the process
# is not in legacy mode (compat task, unlimited stack size or
--
2.33.0
NTFS_RW code allocates page size dependent arrays on the stack. This
results in build failures if the page size is 64k or larger.
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
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.
Signed-off-by: Guenter Roeck <[email protected]>
---
v3: Use generic configuration flag
v2: More comprehensive dependencies
fs/ntfs/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/ntfs/Kconfig b/fs/ntfs/Kconfig
index 1667a7e590d8..f93e69a61283 100644
--- a/fs/ntfs/Kconfig
+++ b/fs/ntfs/Kconfig
@@ -52,6 +52,7 @@ config NTFS_DEBUG
config NTFS_RW
bool "NTFS write support"
depends on NTFS_FS
+ depends on PAGE_SIZE_LESS_THAN_64KB
help
This enables the partial, but safe, write support in the NTFS driver.
--
2.33.0
Use the architecture independent Kconfig option PAGE_SIZE_LESS_THAN_64KB
to indicate that VMXNET3 requires a page size smaller than 64kB.
Signed-off-by: Guenter Roeck <[email protected]>
---
v3: Added patch to make VMXNET3 page size dependency architecture
independent
drivers/net/Kconfig | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 10506a4b66ef..6cccc3dc00bc 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -567,9 +567,7 @@ config XEN_NETDEV_BACKEND
config VMXNET3
tristate "VMware VMXNET3 ethernet driver"
depends on PCI && INET
- depends on !(PAGE_SIZE_64KB || ARM64_64K_PAGES || \
- IA64_PAGE_SIZE_64KB || PARISC_PAGE_SIZE_64KB || \
- PPC_64K_PAGES)
+ depends on PAGE_SIZE_LESS_THAN_64KB
help
This driver supports VMware's vmxnet3 virtual ethernet NIC.
To compile this driver as a module, choose M here: the
--
2.33.0
On Sat, Nov 27, 2021 at 7:44 AM Guenter Roeck <[email protected]> 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
On 11/27/21 9:49 AM, Linus Torvalds wrote:
> On Sat, Nov 27, 2021 at 7:44 AM Guenter Roeck <[email protected]> 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
On Sat, Nov 27, 2021 at 2:26 PM Guenter Roeck <[email protected]> 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
Hi Linus, Guenter,
> On 27 Nov 2021, at 22:31, Linus Torvalds <[email protected]> wrote:
> On Sat, Nov 27, 2021 at 2:26 PM Guenter Roeck <[email protected]> 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
--
Anton Altaparmakov <anton at tuxera.com> (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer