All of lore.kernel.org
 help / color / mirror / Atom feed
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.


  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 Linux 5.16-rc1 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.