Linux 6.16-rc1

Linux 6.16-rc1

[Linus Torvalds]

So it's Sunday afternoon, and we all know what that means by now: the
merge window is closed, rc1 has been cut and pushed out, and we're all
supposed to start testing (and fixing) all the new code.

I think we had a fairly normal merge window, although I did get the
feeling that there were a few more "late straggler" pull requests than
usual.  Not to a huge degree, but there was definitely an upward bump
at the end of the second week.

But on the whole, all the stats look pretty normal: about half the
diff is driver updates (all over, although as usual gpu and networking
account for a fairly large chunk of it).

On the non-driver front, it looks like basically one third arch
updates, one third documentation and tooling (perf tool and
selftests), and one third "the rest".

That last part is where all the core changes go: filesystems, core
kernel and MM, networking etc. Typically not huge changes, but often
some of the more important ones. Although maybe that "more important"
comment just shows my personal biases.

Anyway, mergelog below giving at least an approximate high-level feel
for what I've merged this time around. The full shortlog is as always
much too big. We had just under 13k non-merge commits, and closer to a
thousand merges. And 1783 unique author names...

                      Linus

---

Al Viro (4):
    mount propagation fix
    UFS updates
    automount updates
    mount fixes

Alex Williamson (1):
    VFIO updates

Alexandre Belloni (2):
    i3c updates
    RTC updates

Alexei Starovoitov (2):
    bpf updates
    bpf fixes

Andreas Gruenbacher (2):
    gfs2 updates
    gfs2 fix

Andreas Hindborg (1):
    configfs updates

Andrew Morton (5):
    MM updates
    non-MM updates
    more MM updates
    misc fixes
    more MM updates

Anna Schumaker (1):
    NFS clent updates

Ard Biesheuvel (1):
    EFI updates

Arnaldo Carvalho de Melo (1):
    perf tools updates

Arnd Bergmann (6):
    SoC driver updates
    ARM SoC updates
    SoC defconfig updates
    SoC devicetree updates
    sophgo SoC devicetree updates
    compiler version requirement update

Bartosz Golaszewski (1):
    gpio updates

Bjorn Andersson (2):
    remoteproc updates
    rpmsg updates

Bjorn Helgaas (1):
    pci updates

Borislav Petkov (5):
    x86 resource control updates
    EDAC updates
    mtrr update
    AMD SEV update
    EDAC fix

Carlos Maiolino (1):
    xfs updates

Casey Schaufler (1):
    smack update

Christian Brauner (12):
    vfs directory lookup updates
    final writepage conversion
    vfs mount api conversions
    misc vfs updates
    vfs freezing updates
    vfs mount updates
    pidfs updates
    coredump updates
    iomap updates
    vfs selftests updates
    vfs fixes
    netfs updates

Chuck Lever (1):
    nfsd updates

Corey Minyard (1):
    IPMI updates

Damien Le Moal (1):
    ata updates

Dan Williams (1):
    trusted security manager (TSM) updates

Dave Airlie (2):
    drm updates
    drm fixes

Dave Hansen (1):
    Intel software guard extension (SGX) updates

Dave Jiang (1):
    Compute Express Link (CXL) updates

David Kleikamp (1):
    jfs updates

David Sterba (2):
    btrfs updates
    btrfs fix

David Teigland (1):
    dlm updates

Dmitry Torokhov (1):
    input updates

Eric Biggers (2):
    fscrypt update
    CRC updates

Fan Wu (1):
    IPE update

Gao Xiang (1):
    erofs updates

Geert Uytterhoeven (1):
    m68k updates

Greg KH (6):
    driver core updates
    LICENSES update
    staging driver updates
    char / misc / iio driver updates
    tty/serial updates
    USB / Thunderbolt updates

Greg Ungerer (1):
    m68knommu updates

Guenter Roeck (1):
    hwmon updates

Heiko Carstens (2):
    s390 updates
    more s390 updates

Helge Deller (2):
    fbdev updates
    parisc updates

Herbert Xu (3):
    crypto updates
    crypto fix
    crypto fixes

Huacai Chen (1):
    LoongArch updates

Ilpo Järvinen (1):
    x86 platform drivers updates

Ilya Dryomov (1):
    ceph updates

Ingo Molnar (9):
    locking updates
    objtool updates
    scheduler updates
    perf events updates
    core x86 updates
    x86 cleanups
    x86 debug updates
    x86 vdso updates
    x86 build updates

Jaegeuk Kim (1):
    f2fs updates

Jakub Kicinski (1):
    networking fixes

James Bottomley (2):
    SCSI updates
    SCSI fixes

Jan Kara (2):
    fsnotify updates
    ext2 and isofs updates

Jarkko Sakkinen (1):
    tpm updates

Jason Gunthorpe (1):
    rdma updates

Jassi Brar (1):
    mailbox updates

Jens Axboe (4):
    block updates
    io_uring updates
    io_uring fixes
    more block updates

Jiri Kosina (1):
    HID updates

Joel Fernandes (1):
    RCU updates

Joel Granados (1):
    sysctl updates

Joerg Roedel (1):
    iommu updates

Johannes Berg (1):
    UML updates

John Paul Adrian Glaubitz (1):
    sh updates

Jonathan Corbet (1):
    documentation updates

Juergen Gross (1):
    xen updates

Kees Cook (3):
    seccomp updates
    hardening updates
    hardening fixes

Kent Overstreet (2):
    bcachefs updates
    more bcachefs updates

Konstantin Komarov (1):
     ntfs updates

Lee Jones (3):
    MFD updates
    LED updates
    backlight updates

Len Brown (1):
    turbostat updates

Linus Walleij (1):
    pin control updates

Madhavan Srinivasan (1):
    powerpc updates

Marek Szyprowski (1):
    dma-mapping updates

Mark Brown (5):
    regmap updates
    regulator updates
    spi updates
    regulator fix
    more spi updates

Masahiro Yamada (1):
    Kbuild updates

Masami Hiramatsu (1):
    bootconfig updates

Mauro Carvalho Chehab (1):
    media updates

Max Filippov (1):
    xtensa updates

Michael Tsirkin (1):
    virtio updates

Michal Simek (1):
    microblaze update

Miguel Ojeda (1):
    Rust updates

Mike Marshall (1):
    orangefs update

Miklos Szeredi (2):
    fuse updates
    overlayfs update

Mikulas Patocka (1):
    device mapper updates

Mimi Zohar (1):
    integrity updates

Miquel Raynal (1):
    MTD updates

Namjae Jeon (1):
    exfat updates

Palmer Dabbelt (1):
    RISC-V updates

Paolo Abeni (1):
    networking updates

Paolo Bonzini (2):
    kvm updates
    more kvm updates

Paul McKenney (2):
    rate-limit updates
    lkmm updates

Paul Moore (3):
    lsm update
    selinux updates
    audit updates

Petr Pavlu (1):
    module updates

Rafael Wysocki (6):
    thermal control updates
    ACPI updates
    power management updates
    more power management updates
    ACPI fixes
    power management fixes

Richard Weinberger (1):
    JFFS2 and UBIFS fixes

Rob Herring (1):
    devicetree updates

Russell King (1):
    ARM fixes

Sebastian Reichel (1):
    power supply and reset updates

Shuah Khan (2):
    Kselftest updates
    kunit updates

Simona Vetter (1):
    more drm fixes

Stafford Horne (1):
    OpenRISC updates

Stephen Boyd (1):
    clk updates

Steve French (3):
    smb client updates
    smb server updates
    more smb client updates

Steven Rostedt (5):
    tracing tools updates
    tracing updates
    ring-buffer updates
    tracing fixes
    more tracing fixes

Takashi Iwai (2):
    sound updates
    sound fixes

Ted Ts'o (1):
    ext4 updates

Tejun Heo (5):
    workqueue updates
    cgroup updates
    sched_ext updates
    cgroup fix
    sched_ext fixes

Tetsuo Handa (1):
    tomoyo update

Thomas Bogendoerfer (1):
    MIPS updates

Thomas Gleixner (13):
    core entry code updates
    irq core updates
    irq controller updates
    irq cleanups
    MSI updates
    timer cleanups
    clocksource updates
    timer core updates
    irq fix
    x86 perf fix
    timer fix
    x86 fixes
    timer cleanup

Thomas Weißschuh (1):
    nolibc updates

Tzung-Bi Shih (1):
    chrome-platform updates

Ulf Hansson (2):
    pmdomain updates
    MMC updates

Uwe Kleine-König (2):
    pwm updates
    pwm fixes

Vinod Koul (3):
    soundwire updates
    phy updates
    dmaengine updates

Vlastimil Babka (1):
    slab updates

Wei Liu (1):
    hyperv updates

Will Deacon (2):
    arm64 updates
    arm64 fixes

Wim Van Sebroeck (1):
    watchdog updates

Wolfram Sang (1):
    i2c updates

Yury Norov (1):
    bitmap updates

Re: Linux 6.16-rc1

[Guenter Roeck]

On Sun, Jun 08, 2025 at 02:17:49PM -0700, Linus Torvalds wrote:
> So it's Sunday afternoon, and we all know what that means by now: the
> merge window is closed, rc1 has been cut and pushed out, and we're all
> supposed to start testing (and fixing) all the new code.
> 

Build results:
	total: 159 pass: 159 fail: 0
Qemu test results:
	total: 633 pass: 628 fail: 5
Failed tests:
	arm:supermicro-x11spi-bmc:aspeed_g5_defconfig:mtd32,0,6,1:net=nic:aspeed-bmc-supermicro-x11spi:sqf
	arm:ast2600-evb:aspeed_g5_defconfig:mtd64,0,6,1:net=nic:aspeed-ast2600-evb:ext2
	arm:fuji-bmc:aspeed_g5_defconfig:mem1G:mtd128,0,8,1:net=nic:aspeed-bmc-facebook-fuji:f2fs
	arm:g220a-bmc:aspeed_g5_defconfig:mtd32,0,12,2:net=nic:aspeed-bmc-bytedance-g220a:sqf
	arm:qcom-dc-scm-v1-bmc:aspeed_g5_defconfig:mtd64,0,12,2:net=nic:aspeed-bmc-qcom-dc-scm-v1:ext2
Unit test results:
	pass: 592743 fail: 0

The test failures are all due to commit 0aa7b390fc40 ("mtd: core: always
create master device") which breaks mtd partitioning.

One side note: Various qemu machines configured to use Macronix flash chips
are no longer able to access the chips. This is primarily due to commit
947c86e481a0 ("mtd: spi-nor: macronix: Drop the redundant flash info
fields"). After that change, SFDP support for affected chips is mandatory,
and qemu does not or not correctly support that. This affects quanta-gsj,
kudo-bmc, ast2600-evb, and supermicro-x11spi-bmc machines (and possibly
others).

Guenter

linux-next: stats (Was: Linux 6.16-rc1)

[Stephen Rothwell]

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

Hi all,

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

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

Commits in v6.16-rc1 (relative to v6.15):          12899
Commits in next-20250526:                          12253
Commits with the same SHA1:                        11854
Commits with the same patch_id:                      157 (1)
Commits with the same subject line:                    8 (1)

(1) not counting those in the lines above.

So commits in -rc1 that were in next-20250526:     12019 93%

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

Top ten first word of commit summary:

     79 net
     65 drm
     63 bcachefs
     48 selftests
     39 riscv
     23 netfilter
     22 perf
     21 tools
     21 asoc
     19 can

Top ten authors:

     62 kent.overstreet@linux.dev
     19 biju.das.jz@bp.renesas.com
     17 rostedt@goodmis.org
     15 fw@strlen.de
     14 phil@nwl.cc
     13 kees@kernel.org
     12 rui.zhang@intel.com
     12 cleger@rivosinc.com
     11 masahiroy@kernel.org
     11 jiawenwu@trustnetic.com

Top ten committers:

     81 pabeni@redhat.com
     63 kent.overstreet@linux.dev
     50 kuba@kernel.org
     47 palmer@dabbelt.com
     41 alexander.deucher@amd.com
     35 akpm@linux-foundation.org
     31 pablo@netfilter.org
     30 broonie@kernel.org
     30 anna.schumaker@oracle.com
     29 stfrench@microsoft.com

There are also 234 commits in next-20250526 that didn't make it into
v6.16-rc1.

Top ten first word of commit summary:

     47 drm
     43 arm
     25 apparmor
     17 arm64
     13 dt-bindings
      9 pci
      8 i2c
      7 soc
      7 extcon
      6 pm

Top ten authors:

     18 john.johansen@canonical.com
     16 himal.prasad.ghimiray@intel.com
     12 linus.walleij@linaro.org
     11 potin.lai.pt@gmail.com
      8 ninad@linux.ibm.com
      8 dario.binacchi@amarulasolutions.com
      7 krzysztof.kozlowski@linaro.org
      7 arnd@arndb.de
      6 christian.bruel@foss.st.com
      5 tomasz.lis@intel.com

Top ten committers:

     29 alexandre.torgue@foss.st.com
     28 andrew@codeconstruct.com.au
     25 john.johansen@canonical.com
     15 himal.prasad.ghimiray@intel.com
     14 cw00.choi@samsung.com
     12 florian.fainelli@broadcom.com
     11 andi@smida.it
      8 michal.wajdeczko@intel.com
      5 srini@kernel.org
      5 matthew.d.roper@intel.com

-- 
Cheers,
Stephen Rothwell

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

Re: Linux 6.16-rc1

[Linus Torvalds]

On Tue, 10 Jun 2025 at 18:25, Guenter Roeck <linux@roeck-us.net> wrote:
>
> The test failures are all due to commit 0aa7b390fc40 ("mtd: core: always
> create master device") which breaks mtd partitioning.

Ok, I just merged the pull request that reverted that one.

> One side note: Various qemu machines configured to use Macronix flash chips
> are no longer able to access the chips. This is primarily due to commit
> 947c86e481a0 ("mtd: spi-nor: macronix: Drop the redundant flash info
> fields"). After that change, SFDP support for affected chips is mandatory,
> and qemu does not or not correctly support that. This affects quanta-gsj,
> kudo-bmc, ast2600-evb, and supermicro-x11spi-bmc machines (and possibly
> others).

.. but this issue presumably remains, unless there's been some subtler
indirect fix that I didn't realize.

Miguel, that one came through you too. Comments? I do think that
running things in qemu is likely important for a lot of these things
that don't actually have a ton of hardware that is easily automated...

            Linus

Re: Linux 6.16-rc1

[Pratyush Yadav]

Hi Linus,

On Fri, Jun 20 2025, Linus Torvalds wrote:

> On Tue, 10 Jun 2025 at 18:25, Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> The test failures are all due to commit 0aa7b390fc40 ("mtd: core: always
>> create master device") which breaks mtd partitioning.
>
> Ok, I just merged the pull request that reverted that one.
>
>> One side note: Various qemu machines configured to use Macronix flash chips
>> are no longer able to access the chips. This is primarily due to commit
>> 947c86e481a0 ("mtd: spi-nor: macronix: Drop the redundant flash info
>> fields"). After that change, SFDP support for affected chips is mandatory,
>> and qemu does not or not correctly support that. This affects quanta-gsj,
>> kudo-bmc, ast2600-evb, and supermicro-x11spi-bmc machines (and possibly
>> others).
>
> .. but this issue presumably remains, unless there's been some subtler
> indirect fix that I didn't realize.
>
> Miguel, that one came through you too. Comments? I do think that
> running things in qemu is likely important for a lot of these things
> that don't actually have a ton of hardware that is easily automated...

There isn't a fix AFAIK. From the thread [0], there seemed to be a
conclusion that it was a qemu problem and not directly a problem on the
driver side. So I dropped this down my list of priorities of things to
look into.

I don't have much idea of how people use qemu for testing, but since you
say this is important for testing workloads, I can take a deeper dive
next week and have an answer by -rc4.

[0] https://lore.kernel.org/linux-mtd/8d4bd876-3571-46e5-857a-948e58b21c5b@roeck-us.net/

-- 
Regards,
Pratyush Yadav

Re: Linux 6.16-rc1

[Linus Torvalds]

On Sat, 21 Jun 2025 at 05:44, Pratyush Yadav <pratyush@kernel.org> wrote:
>
> I don't have much idea of how people use qemu for testing, but since you
> say this is important for testing workloads, I can take a deeper dive
> next week and have an answer by -rc4.

Thanks. I'm not sure *how* important this is, but if it affects
Guenter's test coverage, I assume it affects others too.

But it's not entirely clear how much it *does* affect Guenter. He says
five failed tests, but those are all accounted for by the master
device thing.

Guenter, maybe you can clarify?

             Linus

Re: Linux 6.16-rc1

[Guenter Roeck]

On Sat, Jun 21, 2025 at 08:59:46AM -0700, Linus Torvalds wrote:
> On Sat, 21 Jun 2025 at 05:44, Pratyush Yadav <pratyush@kernel.org> wrote:
> >
> > I don't have much idea of how people use qemu for testing, but since you
> > say this is important for testing workloads, I can take a deeper dive
> > next week and have an answer by -rc4.
> 
> Thanks. I'm not sure *how* important this is, but if it affects
> Guenter's test coverage, I assume it affects others too.
> 
> But it's not entirely clear how much it *does* affect Guenter. He says
> five failed tests, but those are all accounted for by the master
> device thing.
> 
> Guenter, maybe you can clarify?
> 

Sorry for the delay; I was travelling.

I modified qemu to make the flash type configurable, so it is not a problem
for me. However, anyone using upstream qemu will see the problem. My qemu patch
adding the option to configure the flash type was rejected, so those affected
will have to wait for a proper qemu fix.

I would suggest to not make any changes in the kernel: The qemu problems should be
fixed in qemu. I only brought this up to raise awareness that there is a qemu related
problem, not to ask for a change in the Linux kernel.

Guenter

Re: Linux 6.16-rc1

[Pratyush Yadav]

On Sun, Jun 22 2025, Guenter Roeck wrote:

> On Sat, Jun 21, 2025 at 08:59:46AM -0700, Linus Torvalds wrote:
>> On Sat, 21 Jun 2025 at 05:44, Pratyush Yadav <pratyush@kernel.org> wrote:
>> >
>> > I don't have much idea of how people use qemu for testing, but since you
>> > say this is important for testing workloads, I can take a deeper dive
>> > next week and have an answer by -rc4.
>> 
>> Thanks. I'm not sure *how* important this is, but if it affects
>> Guenter's test coverage, I assume it affects others too.
>> 
>> But it's not entirely clear how much it *does* affect Guenter. He says
>> five failed tests, but those are all accounted for by the master
>> device thing.
>> 
>> Guenter, maybe you can clarify?
>> 
>
> Sorry for the delay; I was travelling.
>
> I modified qemu to make the flash type configurable, so it is not a problem
> for me. However, anyone using upstream qemu will see the problem. My qemu patch
> adding the option to configure the flash type was rejected, so those affected
> will have to wait for a proper qemu fix.
>
> I would suggest to not make any changes in the kernel: The qemu problems should be
> fixed in qemu. I only brought this up to raise awareness that there is a qemu related
> problem, not to ask for a change in the Linux kernel.

In case you missed it, see my reply in [0]. For me the flash works fine
with qemu v10.0.0. Which version do you have?

Anyway, I agree with you. Without further evidence, I think the kernel
side is fine and no fixes should be needed.

[0] https://lore.kernel.org/linux-mtd/mafs01prbvbjm.fsf@kernel.org/

-- 
Regards,
Pratyush Yadav

Re: Linux 6.16-rc1

[Guenter Roeck]

On Mon, Jun 23, 2025 at 01:17:27PM +0200, Pratyush Yadav wrote:
> On Sun, Jun 22 2025, Guenter Roeck wrote:
> 
> > On Sat, Jun 21, 2025 at 08:59:46AM -0700, Linus Torvalds wrote:
> >> On Sat, 21 Jun 2025 at 05:44, Pratyush Yadav <pratyush@kernel.org> wrote:
> >> >
> >> > I don't have much idea of how people use qemu for testing, but since you
> >> > say this is important for testing workloads, I can take a deeper dive
> >> > next week and have an answer by -rc4.
> >> 
> >> Thanks. I'm not sure *how* important this is, but if it affects
> >> Guenter's test coverage, I assume it affects others too.
> >> 
> >> But it's not entirely clear how much it *does* affect Guenter. He says
> >> five failed tests, but those are all accounted for by the master
> >> device thing.
> >> 
> >> Guenter, maybe you can clarify?
> >> 
> >
> > Sorry for the delay; I was travelling.
> >
> > I modified qemu to make the flash type configurable, so it is not a problem
> > for me. However, anyone using upstream qemu will see the problem. My qemu patch
> > adding the option to configure the flash type was rejected, so those affected
> > will have to wait for a proper qemu fix.
> >
> > I would suggest to not make any changes in the kernel: The qemu problems should be
> > fixed in qemu. I only brought this up to raise awareness that there is a qemu related
> > problem, not to ask for a change in the Linux kernel.
> 
> In case you missed it, see my reply in [0]. For me the flash works fine
> with qemu v10.0.0. Which version do you have?
> 
10.0.2. I didn't try with other versions.

> Anyway, I agree with you. Without further evidence, I think the kernel
> side is fine and no fixes should be needed.
> 
Correct.

Thanks,
Guenter

> [0] https://lore.kernel.org/linux-mtd/mafs01prbvbjm.fsf@kernel.org/
> 
> -- 
> Regards,
> Pratyush Yadav