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]
Message-ID: <f806d901-8291-96e1-a100-e187d781f2ca@roeck-us.net>
Date:   Tue, 16 Nov 2021 06:50:24 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     Michael Ellerman <mpe@...erman.id.au>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 5.16-rc1

On 11/16/21 3:36 AM, Michael Ellerman wrote:
> Guenter Roeck <linux@...ck-us.net> writes:
>> On 11/14/21 9:21 PM, Linus Torvalds wrote:
>>> On Sun, Nov 14, 2021 at 8:56 PM Guenter Roeck <linux@...ck-us.net> wrote:
>>>>
>>>> With gcc 5.4, mips:mapta_defconfig
>>>> mips-linux-gcc.br_real: error: unrecognized command line option ‘-Wimplicit-fallthrough=5’
>>>
>>> This (and the gcc-6.x ones for sh4eb/sparc/xtensa) are already fixed
>>> in my tree. They're all "old gcc didn't support that flag" things with
>>> a trivial one-liner fix.
>>>
>>> I was hoping you didn't have older gcc versions, but you clearly do ;^p
>>>
>>
>> Top of tree is a bit better:
>>
>> Build results:
>> 	total: 153 pass: 141 fail: 12
>> Failed builds:
>> 	arm:allmodconfig
>> 	arm64:allmodconfig
>> 	csky:defconfig
>> 	csky:allmodconfig
>> 	mips:allmodconfig
>> 	parisc:allmodconfig
>> 	powerpc:allmodconfig
>> 	powerpc:ppc6xx_defconfig
>> 	riscv32:allmodconfig
>> 	riscv:allmodconfig
>> 	s390:allmodconfig
>> 	sparc64:allmodconfig
>> Qemu test results:
>> 	total: 482 pass: 476 fail: 6
>> Failed tests:
>> 	ppc64:mac99:ppc64_book3s_defconfig:smp:net,ne2k_pci:initrd
>> 	ppc64:mac99:ppc64_book3s_defconfig:smp:net,pcnet:ide:rootfs
>> 	ppc64:mac99:ppc64_book3s_defconfig:smp:net,e1000:sdhci:mmc:rootfs
>> 	ppc64:mac99:ppc64_book3s_defconfig:smp:net,e1000e:nvme:rootfs
>> 	ppc64:mac99:ppc64_book3s_defconfig:smp:net,virtio-net:scsi[DC395]:rootfs
> 
> 
> My qemu mac99 test is passing, but I guess your tests are enabling more
> devices or something to trigger that breakage?
> 
>> powerpc:allmodconfig
>>
>> 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.
> 
> I guess we need to bump CONFIG_FRAME_WARN a bit when 64K pages is
> enabled? But even that is a bit gross because the stack size doesn't
> increase based on the page size.
> 

It does for ntfs, actually. locked_nis is allocated on the stack. With a
page size of 64k, the array has 128 entries. Since it is a pointer, that
alone makes it 1k. If you don't care about NTFS support, best I could
suggest would be to make ntfs dependent on something like
	!PPC_PAGE_SHIFT || PPC_PAGE_SHIFT < 16
ppc supports 256k page size as well, so that code is always vulnerable to
stack size overflows, and presumably you don't want to set the frame size
limit to 6k in that case.

>> powerpc:ppc6xx_defconfig
>>
>> arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c: In function 'mcu_remove':
>> arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c:189:13: error: unused variable 'ret'
>>
>> Caused by commit 5d354dc35ebb ("powerpc/83xx/mpc8349emitx: Make mcu_gpiochip_remove()
>> return void"). Still seen in -next.
> 
> I have a fix queued for that, will hit -next tomorrow.
> 
>> powerpc:qemu_ppc64_book3s_defconfig:
>>
>> arch/powerpc/mm/slice.c: In function ‘slice_get_unmapped_area’:
>> arch/powerpc/mm/slice.c:639:1: error: the frame size of 1056 bytes is larger than 1024 bytes
>>
>> Bisect again points to commit f22969a6604 ("powerpc/64s: Default to 64K pages
>> for 64 bit book3s"), and reverting that commit does fix the problem.
> 
> I'm not sure what qemu_ppc64_book3s_defconfig is, it's not an upstream
> defconfig, and I couldn't quite see how it's generated in your scripts.
> 
> But if it's a 64-bit config it should be using 2048 bytes, from
> lib/Kconfig.debug:
> 
> config FRAME_WARN
> 	int "Warn for stack frames larger than"
> 	range 0 8192
> 	default 2048 if GCC_PLUGIN_LATENT_ENTROPY
> 	default 1536 if (!64BIT && (PARISC || XTENSA))
> 	default 1024 if (!64BIT && !PARISC)
> 	default 2048 if 64BIT
>

Ah, my fault there. It is a fixed configuration. I need to update that.
Sorry for the noise.

Guenter