linux-kernel - Re: Linux 5.16-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 17 Nov 2021 21:18:56 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Michael Ellerman <mpe@...erman.id.au>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Anton Altaparmakov <anton@...era.com>,
        linux-ntfs-dev@...ts.sourceforge.net
Subject: Re: Linux 5.16-rc1

Hi Michael,

On Tue, Nov 16, 2021 at 12:39 PM Michael Ellerman <mpe@...erman.id.au> wrote:
> Guenter Roeck <linux@...ck-us.net> writes:
> > 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
> >
> > Bisect points to commit f22969a6604 ("powerpc/64s: Default to 64K pages for
> > 64 bit book3s"), and reverting that commit does fix the problem.
> > The problem is
> >       ntfs_inode *locked_nis[PAGE_SIZE / NTFS_BLOCK_SIZE];
> >
> > I don't see the problem in next-20211115, but I don't immediately see how it was fixed there.
>
> I still see it in next.
>
> I don't know what to do about it though. The NTFS folks presumably don't
> want to rewrite their code to avoid a warning on powerpc, we have no
> real interest in NTFS, and definitely no expertise in the NTFS code. We
> don't want to revert the 64K change, and even if we did the warning
> would still be there for other 64K page configs.

Do you have a pointer to that discussion? I couldn't find it.

Why does the ntfs code have a need to allocate an array
(regardless whether it's on the stack or not) with a size related to
PAGE_SIZE? Shouldn't the array's size be related to a parameter of
the file system on the storage device, instead of a parameter of the
system it is running on?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds