linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Linux 5.16-rc1
@ 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  4:56 ` Linux 5.16-rc1 Guenter Roeck
  0 siblings, 2 replies; 23+ messages in thread
From: Linus Torvalds @ 2021-11-14 22:28 UTC (permalink / raw)
  To: Linux Kernel Mailing List

It's been two weeks, and the merge window is thus closed.

I actually anticipated more problems during the merge window than we
hit - I was traveling with a laptop for a few days early on in the
merge window, and that's usually fairly painful. But - knock wood - it
all worked out fine. Partly thanks to a lot of people sending in their
pull requests fairly early, so that I could get a bit of a head start
before travels. But partly also because I didn't end up having any
"uhhuh, things aren't working and now I need to bisect where they
broke" events for me on any of my machines. At least yet.

So who knows? Maybe this will be one of those painless releases where
everything just works.

Sure.

Anyway, it's not a huge release, although it's also not a remarkably
small one like 5.15 was (ok, "remarkably small" is relative, when even
such small releases have 10k+ commits).. There's a bit of everything
in here, and you can look to the appended mergelog for some kind of
flavor, but I guess the folio work is worth mentioning, since it's an
unusually core thing that we don't tend to see most releases. The
intent is to have a more efficient and type-safe way to specify "head
of a group of pages", rather than the page pointers and
"compound_head()" and friends.

That said, the folio changes may be unusually core, but they certainly
aren't the bulk of the changes. Pretty small in the end, with the real
meat and potatoes being all the usual stuff. As always, most of the
changes are to drivers (gpu, networking, sound and staging stand out,
but it's all over) and architecture code. Hardware support is the bulk
of the code, it gets the bulk of the changes.  But we obviously have
all the normal other updates, with filesystem, networking, and core
kernel code. With documentation and tooling support filling the gaps.

And somewhat unusually, our library code stands out in the diffstat,
thanks to the big update to a more recent version of upstream libzstd.

Anyway, the merge window may have gone about as smoothly as I could
hope for, but let's get the whole stabilization phase started with
some serious testing, shall we?

Please?

                  Linus

---

Alex Williamson (1):
    VFIO updates

Alexandre Belloni (1):
    RTC updates

Andreas Gruenbacher (2):
    gfs2 mmap + page fault deadlocks fixes
    gfs2 updates

Andrew Morton (3):
    misc updates
    more updates
    more updates

Arnaldo Carvalho de Melo (2):
    perf tools updates
    more perf tools updates

Arnd Bergmann (6):
    ARM SoC updates
    ARM SoC DT updates
    ARM SoC driver updates
    ARM defconfig updates
    asm-generic cleanup
    ARM SoC fixes

Bartosz Golaszewski (1):
    gpio updates

Benson Leung (1):
    chrome platform updates

Bjorn Andersson (2):
    rpmsg updates
    remoteproc updates

Bjorn Helgaas (2):
    pci updates
    PCI fixes

Borislav Petkov (14):
    EDAC updates
    EFI updates
    RAS updates
    x86 build fix
    generic confidential computing updates
    x86 cleanups
    x86 cpu updates
    misc x86 changes
    x86 SEV updates
    x86 SGX updates
    x86 core updates
    x86 fixes
    perf fixes
    scheduler fixes

Bruce Fields (1):
    nfsd updates

Casey Schaufler (1):
    smack updates

Christian Brauner (2):
    pidfd updates
    prctl updates

Christoph Hellwig (1):
    dma-mapping updates

Corey Minyard (1):
    IPMI driver updates

Damien Le Moal (2):
    libata updates
    more libata updates

Dan Williams (2):
    cxl updates
    libnvdimm update

Daniel Thompson (1):
    kgdb update

Darrick Wong (2):
    xfs updates
    xfs cleanups

Dave Airlie (2):
    drm updates
    more drm updates

David Hildenbrand (1):
    virtio-mem update

David Howells (2):
    AFS updates
    netfs, 9p, afs and ceph (partial) foliation

David Kleikamp (1):
    jfs fix

David Sterba (2):
    btrfs updates
    btrfs fix

Dmitry Torokhov (1):
    input updates

Dominique Martinet (1):
    9p updates

Eric Biederman (4):
    ucount cleanups
    per signal_struct coredumps
    exit cleanups
    vm86 fix

Eric Biggers (1):
    fscrypt updates

Gao Xiang (2):
    erofs updates
    erofs fixes

Geert Uytterhoeven (1):
    m68k updates

Greg KH (7):
    USB / Thunderbolt updates
    staging driver updates
    char/misc driver updates
    driver core updates
    tty / serial driver updates
    USB fixes
    char/misc fix

Greg Ungerer (1):
    m68knommu updates

Guenter Roeck (1):
    hwmon updates

Gustavo A (2):
    hardening fixes and cleanups
    fallthrough fixes

Hans de Goede (1):
    x86 platform driver updates

Helge Deller (3):
    parisc updates
    more parisc architecture fixes and updates
    more parisc fixes

Herbert Xu (2):
    crypto updates
    crypto fix

Ilya Dryomov (1):
    ceph updates

Jaegeuk Kim (1):
    f2fs updates

Jakub Kicinski (2):
    networking updates
    networking fixes

James Bottomley (2):
    SCSI updates
    more SCSI updates

Jan Kara (2):
    quota, isofs, and reiserfs updates
    fsnotify updates

Jarkko Sakkinen (1):
    tpm updates

Jason Gunthorpe (1):
    rdma updates

Jassi Brar (1):
    mailbox updates

Jeff Layton (1):
    file locking updates

Jens Axboe (15):
    block updates
    block driver updates
    io_uring updates
    bdev size cleanups
    SCSI multi-actuator support
    CDROM updates
    QUEUE_FLAG_SCSI_PASSTHROUGH removal
    kiocb->ki_complete() cleanup
    block inode sync updates
    io_uring fixes
    more bdev size updates
    block fixes
    more block driver updates
    io_uring fix
    block fixes

Jiri Kosina (1):
    HID updates

Joerg Roedel (1):
    iommu updates

John Johansen (1):
    apparmor updates

Jonathan Corbet (1):
    documentation updates

Juergen Gross (1):
    xen updates

Julia Lawall (1):
    coccinelle updates

Kees Cook (4):
    thread_info update to move 'cpu' back from task_struct
    compiler hardening updates
    overflow updates
    seccomp updates

Lee Jones (2):
    MFD updates
    backlight updates

Linus Walleij (1):
    pin control updates

Luis Chamberlain (1):
    module updates

Mark Brown (3):
    regmap update
    regulator updates
    spi updates

Masahiro Yamada (1):
    Kbuild updates

Matthew Wilcox (1):
    memory folios

Mauro Carvalho Chehab (1):
    media updates

Max Filippov (1):
    xtensa updates

Michael Ellerman (1):
    powerpc updates

Michael Tsirkin (1):
    virtio updates

Michal Simek (1):
    microblaze update

Miguel Ojeda (2):
    compiler attributes update
    auxdisplay updates

Mike Marshall (1):
    orangefs fixes

Mike Snitzer (1):
    device mapper updates

Miklos Szeredi (2):
    fuse updates
    overlayfs updates

Mimi Zohar (1):
    integrity subsystem updates

Miquel Raynal (1):
    mtd updates

Namjae Jeon (1):
    exfat fix

Nick Terrell (1):
    zstd update

Palmer Dabbelt (1):
    RISC-V updates

Paolo Bonzini (2):
    KVM updates
    more kvm updates

Paul McKenney (2):
    RCU updates
    KCSAN updates

Paul Moore (3):
    selinux updates
    audit updates
    selinux fixes

Pavel Machek (1):
    LED updates

Petr Mladek (1):
    printk updates

Rafael Wysocki (7):
    ACPI updates
    power management updates
    thermal control updates
    PNP update
    more ACPI updates
    more power management updates
    more thermal control updates

Rich Felker (1):
    arch/sh updates

Rob Herring (2):
    devicetree updates
    devicetree fixes

Russell King (2):
    ARM updates
    ARM fixes

Sebastian Reichel (2):
    power supply and reset updates
    HSI update

Shuah Khan (2):
    Kselftest updates
    KUnit updates

Stafford Horne (1):
    OpenRISC updates

Stephen Boyd (2):
    clk updates
    more clk updates

Steve French (3):
    cifs updates
    ksmbd updates
    more cifs updates

Steven Rostedt (4):
    tracing updates
    more tracing updates
    tracing fixes
    tracing fixes

Takashi Iwai (2):
    sound updates
    sound fixes

Ted Ts'o (1):
    ext4 updates

Tejun Heo (2):
    workqueue updates
    cgroup updates

Thierry Reding (1):
    pwm updates

Thomas Bogendoerfer (2):
    MIPS updates
    more MIPS updates

Thomas Gleixner (11):
    irq updates
    perf updates
    locking updates
    objtool updates
    timer updates
    scheduler updates
    x86/apic update
    x86 fpu updates
    x86 static call update
    irq fixes
    timer fix

Trond Myklebust (1):
    NFS client updates

Ulf Hansson (1):
    MMC and MEMSTICK updates

Vasily Gorbik (2):
    s390 updates
    more s390 updates

Vinod Koul (1):
    dmaengine updates

Wei Liu (1):
    hyperv updates

Will Deacon (2):
    arm64 updates
    arm64 fixes

Wim Van Sebroeck (1):
    watchdog updates

Wolfram Sang (2):
    i2c fix
    i2c updates

^ permalink raw reply	[flat|nested] 23+ messages in thread

* linux-next: stats (Was: Linux 5.16-rc1)
  2021-11-14 22:28 Linux 5.16-rc1 Linus Torvalds
@ 2021-11-15  3:17 ` 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
  1 sibling, 1 reply; 23+ messages in thread
From: Stephen Rothwell @ 2021-11-15  3:17 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 2641 bytes --]

Hi all,

As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)

(No merge commits counted, next-20211101 was the first linux-next after
the merge window opened.)

Commits in v5.16-rc1 (relative to v5.15):          12319
Commits in next-20211101:                          11753
Commits with the same SHA1:                        10811
Commits with the same patch_id:                      475 (1)
Commits with the same subject line:                   43 (1)

(1) not counting those in the lines above.

So commits in -rc1 that were in next-20211101:     11329 91%

Some breakdown of the list of extra commits (relative to next-20211101)
in -rc1:

Top ten first word of commit summary:

     87 perf
     68 drm
     67 net
     31 mfd
     30 pci
     29 dt-bindings
     27 selftests
     27 kvm
     21 nfs
     21 alsa

Top ten authors:

     45 miquel.raynal@bootlin.com
     41 irogers@google.com
     19 acme@redhat.com
     16 mcgrof@kernel.org
     15 ming.lei@redhat.com
     15 kuba@kernel.org
     15 anna.schumaker@netapp.com
     13 axboe@kernel.dk
     13 alexandre.belloni@bootlin.com
     12 trond.myklebust@hammerspace.com

Top ten commiters:

     99 davem@davemloft.net
     92 acme@redhat.com
     64 axboe@kernel.dk
     51 alexander.deucher@amd.com
     50 lee.jones@linaro.org
     40 trond.myklebust@hammerspace.com
     36 stfrench@microsoft.com
     30 pbonzini@redhat.com
     29 daniel@iogearbox.net
     25 kuba@kernel.org

There are also 424 commits in next-20211101 that didn't make it into
v5.16-rc1.

Top ten first word of commit summary:

     53 bluetooth
     37 tools
     23 rcu
     21 drm
     18 arm
     17 iio
     13 soc
     13 mm
     10 h8300
      9 unicode

Top ten authors:

     47 paulmck@kernel.org
     16 yury.norov@gmail.com
     15 ojeda@kernel.org
     14 luiz.von.dentz@intel.com
     14 hch@lst.de
     14 frederic@kernel.org
     14 arnd@arndb.de
     14 akpm@linux-foundation.org
     13 brian.gix@intel.com
     11 ysato@users.sourceforge.jp

Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).

Top ten commiters:

     74 paulmck@kernel.org
     71 sfr@canb.auug.org.au
     53 marcel@holtmann.org
     17 jonathan.cameron@huawei.com
     16 yury.norov@gmail.com
     16 ysato@users.sourceforge.jp
     16 ojeda@kernel.org
     15 treding@nvidia.com
     13 dhowells@redhat.com
     11 nsaenz@kernel.org

Those commits by me are from Andrew's mmotm tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Linux 5.16-rc1
  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  4:56 ` Guenter Roeck
  2021-11-15  5:21   ` Linus Torvalds
  2021-11-15 16:14   ` Geert Uytterhoeven
  1 sibling, 2 replies; 23+ messages in thread
From: Guenter Roeck @ 2021-11-15  4:56 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

On Sun, Nov 14, 2021 at 02:28:55PM -0800, Linus Torvalds wrote:
> It's been two weeks, and the merge window is thus closed.
> 
> I actually anticipated more problems during the merge window than we
> hit - I was traveling with a laptop for a few days early on in the
> merge window, and that's usually fairly painful. But - knock wood - it
> all worked out fine. Partly thanks to a lot of people sending in their
> pull requests fairly early, so that I could get a bit of a head start
> before travels. But partly also because I didn't end up having any
> "uhhuh, things aren't working and now I need to bisect where they
> broke" events for me on any of my machines. At least yet.
> 
> So who knows? Maybe this will be one of those painless releases where
> everything just works.
> 

I don't think so.

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: 436 fail: 46
Failed tests:
	<all mips>
	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
	<all sheb>
	<all sparc32>
	<all xtensa>

Various compile errors:

arm:allmodconfig
arm64:allmodconfig
riscv32:allmodconfig
riscv64:allmodconfig
s390:allmodconfig

In function 'memcmp',
    inlined from 'kasan_memcmp' at lib/test_kasan.c:897:2:
include/linux/fortify-string.h:263:25: error:
	call to '__read_overflow' declared with attribute error: detected read beyond size of object

csky:defconfig
sparc64:allmodconfig

fs/netfs/read_helper.c: In function 'netfs_rreq_unlock':
fs/netfs/read_helper.c:435:25: error: implicit declaration of function 'flush_dcache_folio'

mips:allmodconfig

ERROR: modpost: missing MODULE_LICENSE() in drivers/pci/controller/pcie-mt7621.o
ERROR: modpost: "mips_cm_unlock_other" [drivers/pci/controller/pcie-mt7621.ko] undefined!
ERROR: modpost: "mips_cpc_base" [drivers/pci/controller/pcie-mt7621.ko] undefined!
ERROR: modpost: "mips_cm_lock_other" [drivers/pci/controller/pcie-mt7621.ko] undefined!
ERROR: modpost: "mips_cm_is64" [drivers/pci/controller/pcie-mt7621.ko] undefined!
ERROR: modpost: "mips_gcr_base" [drivers/pci/controller/pcie-mt7621.ko] undefined!

parisc:allmodconfig

arch/parisc/include/asm/jump_label.h: In function 'arch_static_branch':
arch/parisc/include/asm/jump_label.h:18:18: error: expected ':' before '__stringify'

and other similar errors.

drivers/gpu/drm/msm/msm_drv.h:531: error: "COND" redefined
arch/parisc/include/asm/assembly.h:37: note: this is the location of the previous definition

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

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'

With gcc 5.4, mips:mapta_defconfig

mips-linux-gcc.br_real: error: unrecognized command line option ‘-Wimplicit-fallthrough=5’

Various powerpc qemu builds:

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

sheb, gcc-6.3.0:

sh4eb-linux-gcc.br_real: error: unrecognized command line option ‘-Wimplicit-fallthrough=5’

sparc32, gcc 6.5.0:

sparc64-linux-gcc.br_real: error: unrecognized command line option ‘-Wimplicit-fallthrough=5’

xtensa, gcc 6.3.0 and gcc 6.4.0:

xtensa-linux-gcc.br_real: error: unrecognized command line option ‘-Wimplicit-fallthrough=5’

Some of those, like the kasan and the mips build errors, have been fixed
in -next. The "unrecognized command line option" is brand new. I did not
have time to look into the others. From a testing perspective this release
was a nightmare: at times there were more than 100 qemu boot test failures
in my tests. Ultimately that means that bisectability will be limited.

Not that it helps, but yesterday the situation looked much better than
today.

Guenter

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Linux 5.16-rc1
  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 16:14   ` Geert Uytterhoeven
  1 sibling, 2 replies; 23+ messages in thread
From: Linus Torvalds @ 2021-11-15  5:21 UTC (permalink / raw)
  To: Guenter Roeck; +Cc: Linux Kernel Mailing List

On Sun, Nov 14, 2021 at 8:56 PM Guenter Roeck <linux@roeck-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

               Linus

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Linux 5.16-rc1
  2021-11-15  5:21   ` Linus Torvalds
@ 2021-11-15  6:33     ` Guenter Roeck
  2021-11-15 17:07     ` Guenter Roeck
  1 sibling, 0 replies; 23+ messages in thread
From: Guenter Roeck @ 2021-11-15  6:33 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

On 11/14/21 9:21 PM, Linus Torvalds wrote:
> On Sun, Nov 14, 2021 at 8:56 PM Guenter Roeck <linux@roeck-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
> 

I have to, for qemu. In some cases the new compilers don't work with
old kernels (eg sparc) and I prefer to use a single compiler for all
kernel versions, in other cases newer versions of gcc have trouble (sheb),
and for xtensa building a compiler that works for a given hardware model
is tricky so I try to avoid it as long as I can.

Guenter


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Linux 5.16-rc1
  2021-11-15  4:56 ` Linux 5.16-rc1 Guenter Roeck
  2021-11-15  5:21   ` Linus Torvalds
@ 2021-11-15 16:14   ` Geert Uytterhoeven
  1 sibling, 0 replies; 23+ messages in thread
From: Geert Uytterhoeven @ 2021-11-15 16:14 UTC (permalink / raw)
  To: Guenter Roeck; +Cc: Linus Torvalds, Linux Kernel Mailing List

On Mon, Nov 15, 2021 at 5:58 AM Guenter Roeck <linux@roeck-us.net> wrote:
> On Sun, Nov 14, 2021 at 02:28:55PM -0800, Linus Torvalds wrote:
> > It's been two weeks, and the merge window is thus closed.
> >
> > I actually anticipated more problems during the merge window than we
> > hit - I was traveling with a laptop for a few days early on in the
> > merge window, and that's usually fairly painful. But - knock wood - it
> > all worked out fine. Partly thanks to a lot of people sending in their
> > pull requests fairly early, so that I could get a bit of a head start
> > before travels. But partly also because I didn't end up having any
> > "uhhuh, things aren't working and now I need to bisect where they
> > broke" events for me on any of my machines. At least yet.
> >
> > So who knows? Maybe this will be one of those painless releases where
> > everything just works.
> >
>
> I don't think so.
>
> Build results:
>         total: 153 pass: 141 fail: 12

Yeah, it doesn't look pretty.  See also
https://lore.kernel.org/lkml/20211115155105.3797527-1-geert@linux-m68k.org

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Linux 5.16-rc1
  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
                         ` (2 more replies)
  1 sibling, 3 replies; 23+ messages in thread
From: Guenter Roeck @ 2021-11-15 17:07 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

On 11/14/21 9:21 PM, Linus Torvalds wrote:
> On Sun, Nov 14, 2021 at 8:56 PM Guenter Roeck <linux@roeck-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

Errors:

In function 'memcmp',
     inlined from 'kasan_memcmp' at lib/test_kasan.c:897:2:
include/linux/fortify-string.h:263:25: error: call to '__read_overflow' declared with attribute error: detected read beyond size of object

Fixed in linux-next with commit 0fa83c99044a ("lib/test_kasan.c: use underlying
string helpers")


fs/netfs/read_helper.c: In function 'netfs_rreq_unlock':
fs/netfs/read_helper.c:435:25: error: implicit declaration of function 'flush_dcache_folio'

Fixed in linux-next with commit d2f0559fc2d1 ("csky,sparc: Declare flush_dcache_folio()").

mips:allmodconfig:

ERROR: modpost: missing MODULE_LICENSE() in drivers/pci/controller/pcie-mt7621.o
ERROR: modpost: "mips_cm_unlock_other" [drivers/pci/controller/pcie-mt7621.ko] undefined!
ERROR: modpost: "mips_cpc_base" [drivers/pci/controller/pcie-mt7621.ko] undefined!
ERROR: modpost: "mips_cm_lock_other" [drivers/pci/controller/pcie-mt7621.ko] undefined!
ERROR: modpost: "mips_cm_is64" [drivers/pci/controller/pcie-mt7621.ko] undefined!
ERROR: modpost: "mips_gcr_base" [drivers/pci/controller/pcie-mt7621.ko] undefined!

Not fixed in -next. Caused by commit 2bdd5238e756 ("PCI: mt7621: Add MediaTek MT7621
PCIe host controller driver")  which states "depends on (RALINK && SOC_MT7621) ||
(MIPS && COMPILE_TEST)" (I guess mips:allmodconfig wasn't tested).


parisc:allmodconfig: Lots of build failures in arch/parisc/include/asm/jump_label.h.
Not fixed in -next. The problem seens to be related to the thread_info changes,
or at least bisect points to commit 01463374c50e ("Merge tag 'cpu-to-thread_info-v5.16-rc1'
of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux").


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.


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.


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.
This is still seen in -next.

Guenter

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Linux 5.16-rc1
  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-16 11:36       ` Michael Ellerman
  2 siblings, 1 reply; 23+ messages in thread
From: Linus Torvalds @ 2021-11-15 17:53 UTC (permalink / raw)
  To: Guenter Roeck, Geert Uytterhoeven, Nick Terrell, Nick Terrell
  Cc: Linux Kernel Mailing List

On Mon, Nov 15, 2021 at 9:07 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> Top of tree is a bit better:

Thanks for re-testing.

That doesn't actually look all that bad for -rc1.  Several of them
already have fixes, and most of the rest look "easily fixable".

Famous last words.

The most worrisome ones are probably the stack frame complaint ones
(libzstd and a couple of powerpc ones) that Geert also reported, but
they might at least to some degree be as simple as just due to the
same excessive inlining that was already fingered for the code bloat.

But it could be more fundamental - the kernel just doesn't like stack
allocations the same way user space does, so the sync-up to a newer
libzstd might be a bit more problematic than just "don't force
inlining".

Nick - you've been cc'd twice because you sign off your commits with
your work email, but then seem to actually prefer the personal one, so
I didn't know which to use and just added both. See

  https://lore.kernel.org/lkml/652edea7-28a0-70d9-c63f-d910b5942454@roeck-us.net/
  https://lore.kernel.org/lkml/20211115155105.3797527-1-geert@linux-m68k.org

if you didn't already.

               Linus

^ permalink raw reply	[flat|nested] 23+ messages in thread

* is arch/h8300 dead, was Re: linux-next: stats (Was: Linux 5.16-rc1)
  2021-11-15  3:17 ` linux-next: stats (Was: Linux 5.16-rc1) Stephen Rothwell
@ 2021-11-15 18:02   ` Christoph Hellwig
  0 siblings, 0 replies; 23+ messages in thread
From: Christoph Hellwig @ 2021-11-15 18:02 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linus Torvalds, Linux Kernel Mailing List, Yoshinori Sato,
	uclinux-h8-devel

On Mon, Nov 15, 2021 at 02:17:18PM +1100, Stephen Rothwell wrote:
> There are also 424 commits in next-20211101 that didn't make it into
> v5.16-rc1.
> 
> Top ten first word of commit summary:
> 
>      53 bluetooth
>      37 tools
>      23 rcu
>      21 drm
>      18 arm
>      17 iio
>      13 soc
>      10 h8300

At least two of the h8300 ones also were in linux-next for the previous
merge window and didn't make it (my set_fs removal patches).  What is
the maintainer status of h8300 when nothing gets sent on to Linus?

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Linux 5.16-rc1
  2021-11-15 17:07     ` Guenter Roeck
  2021-11-15 17:53       ` Linus Torvalds
@ 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
  2 siblings, 2 replies; 23+ messages in thread
From: Linus Torvalds @ 2021-11-15 18:10 UTC (permalink / raw)
  To: Guenter Roeck, Helge Deller; +Cc: Linux Kernel Mailing List

On Mon, Nov 15, 2021 at 9:07 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> parisc:allmodconfig: Lots of build failures in arch/parisc/include/asm/jump_label.h.
> Not fixed in -next. The problem seens to be related to the thread_info changes,
> or at least bisect points to commit 01463374c50e ("Merge tag 'cpu-to-thread_info-v5.16-rc1'
> of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux").

I don't think they are related to the thread_info changes except very
incidentally.

From the errors ("expected ':' before '__stringify'") it looks like
__stringify() isn't defined there, and I do think that header file
should include <linux/compiler.h> to get it.

I don't actually see how that merge commit you bisected to could
possibly matter (the diff doesn't show any header file include
changes, or any parisc ones), but I suspect you might have bisected to
it because we did end up having actual thread_info errors on parsic
that weren't fixed until commit 2a2e8202c7a1 ("parisc: move CPU field
back into thread_info").

So I suspect the parisc build problems started with thread_info issues
at that merge commit you pinpoint, and then by commit 2a2e8202c7a1
some other header file simplification had exposed that "no
__stringify()" thing).

Helge - apparently from allmodconfig and others, we have:

   arch/parisc/include/asm/jump_label.h: In function 'arch_static_branch':
   arch/parisc/include/asm/jump_label.h:18:18: error: expected ':'
before '__stringify'

and others, which does look like just a missing header file (that was
presumably previously implicitly included earlier, and now the
implicit include is gone).

                    Linus

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Linux 5.16-rc1
  2021-11-15 18:10       ` Linus Torvalds
@ 2021-11-15 18:19         ` Helge Deller
  2021-11-15 18:38         ` Guenter Roeck
  1 sibling, 0 replies; 23+ messages in thread
From: Helge Deller @ 2021-11-15 18:19 UTC (permalink / raw)
  To: Linus Torvalds, Guenter Roeck; +Cc: Linux Kernel Mailing List

On 11/15/21 19:10, Linus Torvalds wrote:
> On Mon, Nov 15, 2021 at 9:07 AM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> parisc:allmodconfig: Lots of build failures in arch/parisc/include/asm/jump_label.h.
>> Not fixed in -next. The problem seens to be related to the thread_info changes,
>> or at least bisect points to commit 01463374c50e ("Merge tag 'cpu-to-thread_info-v5.16-rc1'
>> of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux").
>
> I don't think they are related to the thread_info changes except very
> incidentally.

Yes.

> From the errors ("expected ':' before '__stringify'") it looks like
> __stringify() isn't defined there, and I do think that header file
> should include <linux/compiler.h> to get it.
>
> I don't actually see how that merge commit you bisected to could
> possibly matter (the diff doesn't show any header file include
> changes, or any parisc ones), but I suspect you might have bisected to
> it because we did end up having actual thread_info errors on parsic
> that weren't fixed until commit 2a2e8202c7a1 ("parisc: move CPU field
> back into thread_info").
>
> So I suspect the parisc build problems started with thread_info issues
> at that merge commit you pinpoint, and then by commit 2a2e8202c7a1
> some other header file simplification had exposed that "no
> __stringify()" thing).
>
> Helge - apparently from allmodconfig and others, we have:
>
>    arch/parisc/include/asm/jump_label.h: In function 'arch_static_branch':
>    arch/parisc/include/asm/jump_label.h:18:18: error: expected ':'
> before '__stringify'
>
> and others, which does look like just a missing header file (that was
> presumably previously implicitly included earlier, and now the
> implicit include is gone).

Yes, a header is missing.

I fixed it an hour ago in my for-next tree:
https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git/commit/?h=for-next&id=3ca6cc35f0c8d268b5d35e02e92b1ee99b4569d6

Helge

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Linux 5.16-rc1
  2021-11-15 18:10       ` Linus Torvalds
  2021-11-15 18:19         ` Helge Deller
@ 2021-11-15 18:38         ` Guenter Roeck
  1 sibling, 0 replies; 23+ messages in thread
From: Guenter Roeck @ 2021-11-15 18:38 UTC (permalink / raw)
  To: Linus Torvalds, Helge Deller; +Cc: Linux Kernel Mailing List

On 11/15/21 10:10 AM, Linus Torvalds wrote:
> On Mon, Nov 15, 2021 at 9:07 AM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> parisc:allmodconfig: Lots of build failures in arch/parisc/include/asm/jump_label.h.
>> Not fixed in -next. The problem seens to be related to the thread_info changes,
>> or at least bisect points to commit 01463374c50e ("Merge tag 'cpu-to-thread_info-v5.16-rc1'
>> of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux").
> 
> I don't think they are related to the thread_info changes except very
> incidentally.
> 
>>From the errors ("expected ':' before '__stringify'") it looks like
> __stringify() isn't defined there, and I do think that header file
> should include <linux/compiler.h> to get it.
> 
> I don't actually see how that merge commit you bisected to could
> possibly matter (the diff doesn't show any header file include
> changes, or any parisc ones), but I suspect you might have bisected to
> it because we did end up having actual thread_info errors on parsic
> that weren't fixed until commit 2a2e8202c7a1 ("parisc: move CPU field
> back into thread_info").
> 
> So I suspect the parisc build problems started with thread_info issues
> at that merge commit you pinpoint, and then by commit 2a2e8202c7a1
> some other header file simplification had exposed that "no
> __stringify()" thing).
> 
> Helge - apparently from allmodconfig and others, we have:
> 
>     arch/parisc/include/asm/jump_label.h: In function 'arch_static_branch':
>     arch/parisc/include/asm/jump_label.h:18:18: error: expected ':'
> before '__stringify'
> 
> and others, which does look like just a missing header file (that was
> presumably previously implicitly included earlier, and now the
> implicit include is gone).
> 

Geert pinpointed this problem to

     due to static_branch_likely() in crypto/api.c

Commit adad556efcdd4 ("crypto: api - Fix built-in testing dependency failures")
added "#include <linux/jump_label.h>". That extra include isn't needed because
crypto/internal.h already includes it. Removing it from crypto/api.c
fixes the problem for parisc, but I don't know if that is the correct fix.
Alternatively, linux/completion.h would have to be included from crypto/api.c
before including linux/jump_label.h.

Guenter

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Linux 5.16-rc1
  2021-11-15 17:53       ` Linus Torvalds
@ 2021-11-15 20:39         ` Nick Terrell
  0 siblings, 0 replies; 23+ messages in thread
From: Nick Terrell @ 2021-11-15 20:39 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Guenter Roeck, Geert Uytterhoeven, Nick Terrell,
	Linux Kernel Mailing List



> On Nov 15, 2021, at 9:53 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> On Mon, Nov 15, 2021 at 9:07 AM Guenter Roeck <linux@roeck-us.net> wrote:
>> 
>> Top of tree is a bit better:
> 
> Thanks for re-testing.
> 
> That doesn't actually look all that bad for -rc1.  Several of them
> already have fixes, and most of the rest look "easily fixable".
> 
> Famous last words.
> 
> The most worrisome ones are probably the stack frame complaint ones
> (libzstd and a couple of powerpc ones) that Geert also reported, but
> they might at least to some degree be as simple as just due to the
> same excessive inlining that was already fingered for the code bloat.
> 
> But it could be more fundamental - the kernel just doesn't like stack
> allocations the same way user space does, so the sync-up to a newer
> libzstd might be a bit more problematic than just "don't force
> inlining".

On x86-64 I’ve measured zstd’s stack usage to be 1.6KB for compression,
this is up from 1.4KB before the change. I suspect it is a problem with these
functions on this compiler + architecture combo, where the compiler isn’t
able to inline + constant propagate + run dead code elimination. The functions
mentioned rely on these optimizations to be efficient, and I suspect if the
optimizations fail there will be a lot of unnecessary stack usage.

The solution should be to remove the dependency on compiler optimizations
for efficient stack usage in these functions. So we don’t end up with excess
stack usage on non-x86/arm architectures.

On my todo list is:

1. Reduce stack usage of the mentioned functions
2. Reduce code size bloat of lib/zstd/zstd_opt.c

I’m working on this now, and expect to have a pull request ready to go
tomorrow.

> Nick - you've been cc'd twice because you sign off your commits with
> your work email, but then seem to actually prefer the personal one, so
> I didn't know which to use and just added both. See

Sorry for the confusion. Both work, but I prefer my work email.

>  https://lore.kernel.org/lkml/652edea7-28a0-70d9-c63f-d910b5942454@roeck-us.net/
>  https://lore.kernel.org/lkml/20211115155105.3797527-1-geert@linux-m68k.org
> 
> if you didn't already.
> 
>               Linus

Best,
Nick Terrell



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Linux 5.16-rc1
  2021-11-15 17:07     ` Guenter Roeck
  2021-11-15 17:53       ` Linus Torvalds
  2021-11-15 18:10       ` Linus Torvalds
@ 2021-11-16 11:36       ` Michael Ellerman
  2021-11-16 14:50         ` Guenter Roeck
  2021-11-17 20:18         ` Geert Uytterhoeven
  2 siblings, 2 replies; 23+ messages in thread
From: Michael Ellerman @ 2021-11-16 11:36 UTC (permalink / raw)
  To: Guenter Roeck, Linus Torvalds; +Cc: Linux Kernel Mailing List

Guenter Roeck <linux@roeck-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@roeck-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.

> 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


cheers

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Linux 5.16-rc1
  2021-11-16 11:36       ` Michael Ellerman
@ 2021-11-16 14:50         ` Guenter Roeck
  2021-11-17 20:18         ` Geert Uytterhoeven
  1 sibling, 0 replies; 23+ messages in thread
From: Guenter Roeck @ 2021-11-16 14:50 UTC (permalink / raw)
  To: Michael Ellerman, Linus Torvalds; +Cc: Linux Kernel Mailing List

On 11/16/21 3:36 AM, Michael Ellerman wrote:
> Guenter Roeck <linux@roeck-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@roeck-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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Linux 5.16-rc1
  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
  1 sibling, 1 reply; 23+ messages in thread
From: Geert Uytterhoeven @ 2021-11-17 20:18 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Guenter Roeck, Linus Torvalds, Linux Kernel Mailing List,
	Anton Altaparmakov, linux-ntfs-dev

Hi Michael,

On Tue, Nov 16, 2021 at 12:39 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
> Guenter Roeck <linux@roeck-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@linux-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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Linux 5.16-rc1
  2021-11-17 20:18         ` Geert Uytterhoeven
@ 2021-11-17 23:29           ` Anton Altaparmakov
  2021-11-18  0:28             ` Linus Torvalds
  0 siblings, 1 reply; 23+ messages in thread
From: Anton Altaparmakov @ 2021-11-17 23:29 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Michael Ellerman, Guenter Roeck, Linus Torvalds,
	Linux Kernel Mailing List, linux-ntfs-dev

Hi Geert,

> On 17 Nov 2021, at 20:18, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Michael,
> On Tue, Nov 16, 2021 at 12:39 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>> Guenter Roeck <linux@roeck-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?

Yes and no.  (-:  As always the devil is in the details.

What you would know of as the inode table in a traditional Linux file system is in NTFS an actual file on disk and we access it via the page cache.  What we need here is an array to store pointers to in-memory inodes that correspond to inodes in the inode table page being written out.  We used to have a specific array using the per-filesystem parameteres but because those are variable (e.g. an inode can be 1024 bytes or it can be 4096 bytes depending on your sector size and also depending on how you format the volume in Windows) thus the array was a dynamically sized array.  This at some point in time was frowned upon so a commit was made to change the dynamically sized array to a statically/constant sized one.  To do that the maximum possible size had to be used and that means using NTFS_BLOCK_SIZE as the inode size (that is 512 bytes constant).  This then means that the number of inodes that can be present in a page is at most PAGE_SIZE / NTFS_BLOCK_SIZE and thus this is the size o
 f the array.  The correct array size would be PAGE_SIZE / vol->mft_record_size and with MFT record size normally being 1024 bytes or on 4k sector disks usually 4096 bytes the array we actually need is normally either half or an eight of the size we actually allocate with the PAGE_SIZE / NTFS_BLOCK_SIZE but there is no helping that if we want it to be statically/constant sized array.

Unless that particular kernel can support such small stack sizes I think the solution would be to simply modify the frame size warning not to complain until a bigger size, maybe 3kiB instead of 2kiB or something and that warning would not happen any more.

Best regards,

	Anton
-- 
Anton Altaparmakov <anton at tuxera.com> (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Linux 5.16-rc1
  2021-11-17 23:29           ` Anton Altaparmakov
@ 2021-11-18  0:28             ` Linus Torvalds
  2021-11-18  1:26               ` Anton Altaparmakov
  0 siblings, 1 reply; 23+ messages in thread
From: Linus Torvalds @ 2021-11-18  0:28 UTC (permalink / raw)
  To: Anton Altaparmakov
  Cc: Geert Uytterhoeven, Michael Ellerman, Guenter Roeck,
	Linux Kernel Mailing List, linux-ntfs-dev

On Wed, Nov 17, 2021 at 3:29 PM Anton Altaparmakov <anton@tuxera.com> wrote:
>
> What we need here is an array to store pointers to in-memory inodes that correspond to inodes in the inode table page being written out.

Do we actually need the array?

The ntfs_inode pointers in that array are always locked (using
'mrec_lock'), so ti could be just a linked list of entries.

Yeah, that would require adding a 'next' pointer to 'struct
_ntfs_inode', but maybe that would be the right thing to do?

I don't know the code, but it looks to me like it's literally just a
stack of locked ntfs_inode pointers - where the lock is taken before
adding it to the stack, and released after taking it off the stack. So
a singly-linked list would seem to be a very simple implementation.

                      Linus

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Linux 5.16-rc1
  2021-11-18  0:28             ` Linus Torvalds
@ 2021-11-18  1:26               ` Anton Altaparmakov
  2021-11-18  1:54                 ` Linus Torvalds
  0 siblings, 1 reply; 23+ messages in thread
From: Anton Altaparmakov @ 2021-11-18  1:26 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Geert Uytterhoeven, Michael Ellerman, Guenter Roeck,
	Linux Kernel Mailing List, linux-ntfs-dev

Hi Linus,

> On 18 Nov 2021, at 00:28, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> On Wed, Nov 17, 2021 at 3:29 PM Anton Altaparmakov <anton@tuxera.com> wrote:
>> 
>> What we need here is an array to store pointers to in-memory inodes that correspond to inodes in the inode table page being written out.
> 
> Do we actually need the array?
> 
> The ntfs_inode pointers in that array are always locked (using
> 'mrec_lock'), so ti could be just a linked list of entries.
> 
> Yeah, that would require adding a 'next' pointer to 'struct
> _ntfs_inode', but maybe that would be the right thing to do?
> 
> I don't know the code, but it looks to me like it's literally just a
> stack of locked ntfs_inode pointers - where the lock is taken before
> adding it to the stack, and released after taking it off the stack. So
> a singly-linked list would seem to be a very simple implementation.

Thanks for the idea.  Yes, you are correct.  That would be a viable alternative at the cost of that extra pointer in the ntfs_inode structure.

I am concerned that whilst this would fix this compiler warning, we have other such arrays in fs/ntfs/mft.c::write_mft_record_nolock() and ntfs_sync_mft_mirror() where in each of those functions we have:

	struct buffer_head *bhs[MAX_BHS];

And at the top of mft.c we have:

	#define MAX_BHS (PAGE_SIZE / NTFS_BLOCK_SIZE)

So those arrays are each the same size as the one the compiler warns about in fs/ntfs/aops.c::ntfs_write_mst_block() where we have:

	ntfs_inode *locked_nis[PAGE_SIZE / NTFS_BLOCK_SIZE];

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?

Best regards,

	Anton
-- 
Anton Altaparmakov <anton at tuxera.com> (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Linux 5.16-rc1
  2021-11-18  1:26               ` Anton Altaparmakov
@ 2021-11-18  1:54                 ` Linus Torvalds
  2021-11-18 21:23                   ` Guenter Roeck
  0 siblings, 1 reply; 23+ messages in thread
From: Linus Torvalds @ 2021-11-18  1:54 UTC (permalink / raw)
  To: Anton Altaparmakov
  Cc: Geert Uytterhoeven, Michael Ellerman, Guenter Roeck,
	Linux Kernel Mailing List, linux-ntfs-dev

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.

I dunno. It all seems a bit dubious.

                Linus

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Linux 5.16-rc1
  2021-11-18  1:54                 ` Linus Torvalds
@ 2021-11-18 21:23                   ` Guenter Roeck
  2021-11-18 22:34                     ` Linus Torvalds
  0 siblings, 1 reply; 23+ messages in thread
From: Guenter Roeck @ 2021-11-18 21:23 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Anton Altaparmakov, Geert Uytterhoeven, Michael Ellerman,
	Linux Kernel Mailing List, linux-ntfs-dev

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.


^ permalink raw reply related	[flat|nested] 23+ messages in thread

* Re: Linux 5.16-rc1
  2021-11-18 21:23                   ` Guenter Roeck
@ 2021-11-18 22:34                     ` Linus Torvalds
  2021-11-18 23:08                       ` Guenter Roeck
  0 siblings, 1 reply; 23+ messages in thread
From: Linus Torvalds @ 2021-11-18 22:34 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Anton Altaparmakov, Geert Uytterhoeven, Michael Ellerman,
	Linux Kernel Mailing List, linux-ntfs-dev

On Thu, Nov 18, 2021 at 1:23 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> Like this ?

Ugh. Yes. Like that.

But now I have to go dig my eyes out with a rusty spoon and try to
forget I ever saw that thing.

Because a thing of beauty it ain't.

I would still hope somebody comes up with something prettier.

          Linus

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Linux 5.16-rc1
  2021-11-18 22:34                     ` Linus Torvalds
@ 2021-11-18 23:08                       ` Guenter Roeck
  0 siblings, 0 replies; 23+ messages in thread
From: Guenter Roeck @ 2021-11-18 23:08 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Anton Altaparmakov, Geert Uytterhoeven, Michael Ellerman,
	Linux Kernel Mailing List, linux-ntfs-dev

On Thu, Nov 18, 2021 at 02:34:51PM -0800, Linus Torvalds wrote:
> On Thu, Nov 18, 2021 at 1:23 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > Like this ?
> 
> Ugh. Yes. Like that.
> 
> But now I have to go dig my eyes out with a rusty spoon and try to
> forget I ever saw that thing.
> 
> Because a thing of beauty it ain't.
> 
Hah.

> I would still hope somebody comes up with something prettier.
> 

It doesn't really have to be that fancy, but I suspect we'll end up
with something along that line. Kconfig doesn't support arithmetik,
so

config PAGE_SIZE
	int
	default 1 << PAGE_SHIFT

doesn't work, requiring the complex defaults.

Also,

	depends on !PAGE_SIZE || PAGE_SIZE < xxx

doesn't work either, making something like HAVE_PAGE_SIZE mandatory
unless PAGE_SIZE is made available for all architectures, which seems
excessive.

Of course,
	depends on !PPC
would be the simple solution.

Guenter

^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2021-11-18 23:08 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2021-11-18 22:34                     ` Linus Torvalds
2021-11-18 23:08                       ` Guenter Roeck
2021-11-15 16:14   ` Geert Uytterhoeven

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).