From: Guenter Roeck <linux@roeck-us.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Anton Altaparmakov <anton@tuxera.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"linux-ntfs-dev@lists.sourceforge.net"
<linux-ntfs-dev@lists.sourceforge.net>
Subject: Re: Linux 5.16-rc1
Date: Thu, 18 Nov 2021 13:23:49 -0800 [thread overview]
Message-ID: <20211118212349.GA3424901@roeck-us.net> (raw)
In-Reply-To: <CAHk-=wjoQYuOfhsiPXUvFbUbSd5iHmmoRHMP+zv+bzHKkWqAyA@mail.gmail.com>
On Wed, Nov 17, 2021 at 05:54:06PM -0800, Linus Torvalds wrote:
> On Wed, Nov 17, 2021 at 5:26 PM Anton Altaparmakov <anton@tuxera.com> wrote:
> >
> > So is it worth doing the singly linked list to fix one file only to have compilation fail a few files later when it gets to mft.c?
>
> Heh.
>
> That does sound dubious.
>
> Honestly, maybe the solution here is to just make the Kconfig depend
> on the page size not being excessive for what NTFS wants to do.
>
> Because I'm not sure that "powerpc with 64kB pages" is all that
> relevant for NTFS to begin with.
>
> The main problem is that the page size thing isn't some generic
> Kconfig entry, different architectures have different names for it. On
> PPC, the confic name is PPC_*K_PAGES and PPC_PAGE_SHIFT.
>
> And arm64 has something very similar.
>
> We have other things that do that, ie KASAN support has
>
> select HAVE_ARCH_KASAN if PPC32 && PPC_PAGE_SHIFT <= 14
>
> (and something very similar for arm64).
>
> But those KASAN dependencies are inside the core architecture Kconfig
> files, so it can fairly naturally use that page size config variable
> as a conditional.
>
> For something like NTFS, we don't really have a generic Kconfig
> variable to test.
>
> It wouldn't be _hard_ to add, but it would have to be done somewhat
> sensibly and preferably in a way that doesn't require every
> architecture to change how their page size selection (or lack of
> selection) is done.
>
> The simplest thing would probably be to add something like
> config BIG_PAGES
> bool
>
> to some generic file, and then add
>
> select BIG_PAGES
>
> to PPC and arm64 for the 64kB+ page size, and add a
>
> depends on !BIG_PAGES
>
> to the NTFS Kconfig entry.
>
> But that honestly looks a bit hacky to me. It would be less hacky to
> just add a PAGE_SIZE config variable, and have architectures just set
> it, and then NTFS could do
>
> depends on PAGE_SIZE < 65536
>
> or whatever. I just don't know if it's worth it if this is only for NTFS.
>
Like this ?
Guenter
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index dea74d7717c0..fd3fb2ab2350 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -767,6 +767,16 @@ config PPC_PAGE_SHIFT
default 14 if PPC_16K_PAGES
default 12
+config HAVE_PAGE_SIZE
+ def_bool y
+
+config PAGE_SIZE
+ int
+ default 262144 if PPC_256K_PAGES
+ default 65536 if PPC_64K_PAGES
+ default 16384 if PPC_16K_PAGES
+ default 4096
+
config THREAD_SHIFT
int "Thread shift" if EXPERT
range 13 15
diff --git a/fs/ntfs/Kconfig b/fs/ntfs/Kconfig
index 1667a7e590d8..912361014bb0 100644
--- a/fs/ntfs/Kconfig
+++ b/fs/ntfs/Kconfig
@@ -1,6 +1,16 @@
# SPDX-License-Identifier: GPL-2.0-only
+
+config NTFS_PAGE_SIZE_LIMIT
+ int
+ default 262144 if FRAME_WARN >= 8192
+ default 131072 if FRAME_WARN >= 4096
+ default 65536 if FRAME_WARN >= 2048
+ default 32768 if FRAME_WARN >= 1024
+ default 16384
+
config NTFS_FS
tristate "NTFS file system support"
+ depends on !WERROR || !HAVE_PAGE_SIZE || PAGE_SIZE < NTFS_PAGE_SIZE_LIMIT
select NLS
help
NTFS is the file system of Microsoft Windows NT, 2000, XP and 2003.
next prev parent reply other threads:[~2021-11-18 21:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-14 22:28 Linus Torvalds
2021-11-15 3:17 ` linux-next: stats (Was: Linux 5.16-rc1) Stephen Rothwell
2021-11-15 18:02 ` is arch/h8300 dead, was " Christoph Hellwig
2021-11-15 4:56 ` Linux 5.16-rc1 Guenter Roeck
2021-11-15 5:21 ` Linus Torvalds
2021-11-15 6:33 ` Guenter Roeck
2021-11-15 17:07 ` Guenter Roeck
2021-11-15 17:53 ` Linus Torvalds
2021-11-15 20:39 ` Nick Terrell
2021-11-15 18:10 ` Linus Torvalds
2021-11-15 18:19 ` Helge Deller
2021-11-15 18:38 ` Guenter Roeck
2021-11-16 11:36 ` Michael Ellerman
2021-11-16 14:50 ` Guenter Roeck
2021-11-17 20:18 ` Geert Uytterhoeven
2021-11-17 23:29 ` Anton Altaparmakov
2021-11-18 0:28 ` Linus Torvalds
2021-11-18 1:26 ` Anton Altaparmakov
2021-11-18 1:54 ` Linus Torvalds
2021-11-18 21:23 ` Guenter Roeck [this message]
2021-11-18 22:34 ` Linus Torvalds
2021-11-18 23:08 ` Guenter Roeck
2021-11-15 16:14 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211118212349.GA3424901@roeck-us.net \
--to=linux@roeck-us.net \
--cc=anton@tuxera.com \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-ntfs-dev@lists.sourceforge.net \
--cc=mpe@ellerman.id.au \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome