Linux 5.11-rc1

Linux 5.11-rc1

[Linus Torvalds]

Two weeks have passed, Christmas is over, and so is the merge window.

I want to thank all the maintainers who sent in their pull requests
early: we all wanted to get things done before the holidays really
hit, and mostly it seemed to work quite well.

In fact, it was rather nice to handle the big bulk of all the merge
window pull requests in the first three or four days of the merge
window.  I wouldn't want to do it that way every time - it would
stress me out - but as an occasional "let's get it over with so that
the second week is calm" it really wasn't bad at all.

It probably helped that 5.11 isn't going to be an LTS release and
isn't as big as 5.10 was, but it's not small either. Solidly average.

Well, it's average, unless you look at the actual diffs, and notice
another huge dump of AMD GPU descriptor header files, which completely
dwarfs all the "real" changes here. The AMD "Van Gogh" include file
additions are in fact about two thirds of the whole patch, even if it
comes from basically one single commit that just adds the register
definitions. We've had it before, I'm sure we'll see it in the future
too: header files probably generated from the hardware description for
all the possible bit masks etc get very very big.

Oh well. If you ignore that area, everything else looks normal. Driver
updates dominate, but all the usual other suspects are there: arch
updates, filesystems, networking, docs and tooling.

And while it doesn't look like a huge release, it's certainly still
big enough that what's appended below is just my "merge log". As
always, my merge logs credit only the people I pull from, which is a
much smaller set than all the people involved in actually writing the
patches. As usual we had more than 1500 actual developers, and roughly
12,500 changes merged. That's pretty much our average these days.

Please go kick the tires,

                Linus

---

Al Viro (3):
    epoll updates
    regset updates
    misc vfs updates

Alex Williamson (1):
    VFIO updates

Alexandre Belloni (1):
    RTC updates

Andreas Gruenbacher (1):
    gfs2 updates

Andrew Morton (5):
    misc updates
    more updates
    yet more updates
    still more updates
    KASAN updates

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

Arnd Bergmann (8):
    asm-generic cleanups
    asm-generic mmu-context cleanup
    asm-generic cross-architecture timer cleanup
    ARM SoC updates
    ARM SoC defconfig updates
    ARM device tree updates
    ARM SoC driver updates
    ARM SoC OMAP GenPD updates

Benson Leung (1):
    chrome platform updates

Bjorn Andersson (3):
    remoteproc updates
    hwspinlock updates
    rpmsg updates

Bjorn Helgaas (2):
    PCI updates
    PCI fixes

Boris Brezillon (1):
    i3c updates

Borislav Petkov (12):
    EDAC updates
    x86 RAS updates
    x86 microcode loader update
    x86 SGC support
    x86 cpuid updates
    x86 platform updates
    misc x86 updates
    x86 mm update
    x86 cleanups
    x86 cache resource control updates
    x86 build updates
    EFI updates

Casey Schaufler (2):
    smack updates
    smack fix

Catalin Marinas (2):
    arm64 updates
    more arm64 updates

Christian Brauner (4):
    time namespace updates
    misc fixes
    close_range/openat2 updates
    close_range fix

Christoph Hellwig (2):
    configfs update
    dma-mapping updates

Chuck Lever (1):
    nfsd updates

Corey Minyard (1):
    IPMI updates

Dan Williams (1):
    libnvdimm updates

Daniel Lezcano (2):
    thermal updates
    thermal fixlet

Daniel Vetter (1):
    more drm updates

Darrick Wong (1):
    xfs updates

Dave Airlie (2):
    drm updates
    drm fixes

David Kleikamp (1):
    jfs updates

David Sterba (1):
    btrfs updates

David Teigland (1):
    dlm updates

Dmitry Torokhov (1):
    input updates

Dominik Brodowski (1):
    pcmcia updates

Dominique Martinet (1):
    9p update

Eric Biederman (3):
    signal cleanup
    execve updates
    exec-update-lock update

Eric Biggers (2):
    fscrypt updates
    fsverity updates

Gao Xiang (1):
    erofs updates

Geert Uytterhoeven (1):
    m68k updates

Greg KH (5):
    USB / Thunderbolt updates
    tty / serial updates
    driver core updates
    char / misc driver updates
    staging / IIO driver updates

Greg Ungerer (1):
    m68knommu updates

Guenter Roeck (2):
    hwmon updates
    another hwmon update

Gustavo A (1):
    fallthrough fixes

Hans de Goede (1):
    x86 platform driver updates

Heiko Carstens (2):
    s390 updates
    more s390 updates

Helge Deller (1):
    parisc updates

Herbert Xu (2):
    crypto updates
    crypto fixes

Ilya Dryomov (1):
    ceph updates

Ingo Molnar (4):
    scheduler fix
    timer fixes
    locking fixes
    objtool fix

Jaegeuk Kim (1):
    f2fs updates

Jakub Kicinski (2):
    networking updates
    networking fixes

James Bottomley (1):
    SCSI updates

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

Jason Gunthorpe (1):
    rdma updates

Jassi Brar (1):
    mailbox updates

Jeff Layton (1):
    file locking fixes

Jens Axboe (6):
    TIF_NOTIFY_SIGNAL updates
    io_uring updates
    block updates
    block driver updates
    block fixes
    io_uring fixes

Jessica Yu (1):
    modules updates

Jiri Kosina (1):
    HID updates

Jon Mason (1):
    NTB fixes

Jonathan Corbet (2):
    documentation updates
    documentation fixes

Juergen Gross (2):
    xen updates
    more xen updates

Julia Lawall (1):
    coccinelle updates

Kees Cook (3):
    gcc-plugins updates
    pstore updates
    seccomp updates

Konrad Rzeszutek Wilk (1):
    swiotlb update

Lee Jones (2):
    MFD updates
    backlight update

Linus Walleij (2):
    pin control updates
    GPIO updates

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

Masahiro Yamada (2):
    Kbuild updates
    Kconfig updates

Mauro Carvalho Chehab (1):
    media updates

Michael Ellerman (2):
    powerpc updates
    powerpc fixes

Michael Tsirkin (1):
    virtio updates

Michal Simek (1):
    microblaze updates

Miguel Ojeda (1):
    auxdisplay updates

Mike Marshall (1):
    orangefs update

Mike Rapoport (1):
    memblock updates

Mike Snitzer (2):
    MD regression reverts
    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 update

Palmer Dabbelt (2):
    RISC-V updates
    RISC-V fix

Paolo Bonzini (1):
    KVM updates

Paul Moore (2):
    audit updates
    selinux updates

Pavel Machek (1):
    LED updates

Petr Mladek (1):
    printk updates

Rafael Wysocki (4):
    power management updates
    ACPI updates
    more power management updates
    more ACPI updates

Richard Weinberger (2):
    jffs2, ubi and ubifs updates
    UML updates

Rob Herring (2):
    devicetree updates
    devicetree fixes

Russell King (1):
    ARM updates

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

Shuah Khan (3):
    Kselftest fixes
    Kselftest updates
    Kunit updates

Stafford Horne (1):
    OpenRISC updates

Stephen Boyd (1):
    clk updates

Steve French (2):
    cifs updates
    cifs fixes

Steven Rostedt (2):
    tracing updates
    ktest updates

Takashi Iwai (2):
    sound updates
    sound fixes

Ted Ts'o (1):
    ext4 updates

Tetsuo Handa (1):
    tomoyo updates

Thierry Reding (1):
    pwm updates

Thomas Bogendoerfer (1):
    MIPS updates

Thomas Gleixner (12):
    core entry/exit updates
    RCU updates
    locking updates
    perf updates
    perf/kprobes updates
    timers and timekeeping updates
    scheduler updates
    kmap updates
    x86 FPU updates
    x86 apic updates
    irq updates
    irq updates

Trond Myklebust (1):
    NFS client updates

Ulf Hansson (1):
    MMC updates

Vinod Koul (1):
    dmaengine updates

Wei Liu (1):
    Hyper-V updates

Will Deacon (1):
    IOMMU updates

Wim Van Sebroeck (1):
    watchdog updates

Wolfram Sang (1):
    i2c updates

Re: Linux 5.11-rc1

[Guenter Roeck]

On Sun, Dec 27, 2020 at 04:04:11PM -0800, Linus Torvalds wrote:
> Two weeks have passed, Christmas is over, and so is the merge window.
> 
> I want to thank all the maintainers who sent in their pull requests
> early: we all wanted to get things done before the holidays really
> hit, and mostly it seemed to work quite well.
> 
> In fact, it was rather nice to handle the big bulk of all the merge
> window pull requests in the first three or four days of the merge
> window.  I wouldn't want to do it that way every time - it would
> stress me out - but as an occasional "let's get it over with so that
> the second week is calm" it really wasn't bad at all.
> 
> It probably helped that 5.11 isn't going to be an LTS release and
> isn't as big as 5.10 was, but it's not small either. Solidly average.
> 
> Well, it's average, unless you look at the actual diffs, and notice
> another huge dump of AMD GPU descriptor header files, which completely
> dwarfs all the "real" changes here. The AMD "Van Gogh" include file
> additions are in fact about two thirds of the whole patch, even if it
> comes from basically one single commit that just adds the register
> definitions. We've had it before, I'm sure we'll see it in the future
> too: header files probably generated from the hardware description for
> all the possible bit masks etc get very very big.
> 
> Oh well. If you ignore that area, everything else looks normal. Driver
> updates dominate, but all the usual other suspects are there: arch
> updates, filesystems, networking, docs and tooling.
> 
> And while it doesn't look like a huge release, it's certainly still
> big enough that what's appended below is just my "merge log". As
> always, my merge logs credit only the people I pull from, which is a
> much smaller set than all the people involved in actually writing the
> patches. As usual we had more than 1500 actual developers, and roughly
> 12,500 changes merged. That's pretty much our average these days.
> 
> Please go kick the tires,
> 

Build results:
	total: 153 pass: 151 fail: 2
Failed builds:
	arm64:allmodconfig
	ia64:defconfig
Qemu test results:
	total: 430 pass: 412 fail: 18
Failed tests:
	arm:raspi2:multi_v7_defconfig:bcm2836-rpi-2-b:initrd
	arm:raspi2:multi_v7_defconfig:sd:bcm2836-rpi-2-b:rootfs
	<all parisc>

Build errors:

arm64:allmodconfig:

ERROR: modpost: "irq_check_status_bit" [drivers/perf/arm_spe_pmu.ko] undefined!

Caused by: fdd029630434 ("genirq: Move status flag checks to core")

ia64:defconfig:

include/linux/mmzone.h:1156:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE

and various related warnings.

Caused by: 214496cb1870 ("ia64: make SPARSEMEM default and disable DISCONTIGMEM")

Fix submitted ("ia64: fix build failure caused by memory model changes").

qemu boot tests:

arm:raspi2:

Hangs during boot.

Caused by: ffdad793d579 ("irqchip/bcm2836: Make IPIs use handle_percpu_devid_irq()")

Fix submitted ("irqchip/bcm2836: Fix IPI acknowledgement after conversion to
handle_percpu_devid_irq").

parisc:

Failed to execute /sbin/init (error -12)

Caused by: c49dd3401802 ("mm: speedup mremap on 1GB or larger regions")

More details are in responses to the offending patches.

Guenter

Re: Linux 5.11-rc1

[Linus Torvalds]

On Mon, Dec 28, 2020 at 7:51 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> Build results:
>         total: 153 pass: 151 fail: 2

Thanks for doing these for the mainline rc's too. I've seen them for
the stable kernels, but it's lovely to see it for rc1.

> ERROR: modpost: "irq_check_status_bit" [drivers/perf/arm_spe_pmu.ko] undefined!
>
> Caused by: fdd029630434 ("genirq: Move status flag checks to core")

Ahh. Does it just need a

 EXPORT_SYMBOL_GPL(irq_check_status_bit);

in there? Because it looks like at least irq_is_percpu() and
irq_is_percpu_devid() are used in drivers/perf/ and can apparently be
modules.

Thomas?

> ia64:defconfig:
>
> include/linux/mmzone.h:1156:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE
>
> and various related warnings.
>
> Caused by: 214496cb1870 ("ia64: make SPARSEMEM default and disable DISCONTIGMEM")
>
> Fix submitted ("ia64: fix build failure caused by memory model changes").

Ok, I won't worry about that one.

> qemu boot tests:
>
> arm:raspi2 hangs during boot.
>
> Caused by: ffdad793d579 ("irqchip/bcm2836: Make IPIs use handle_percpu_devid_irq()")
>
> Fix submitted ("irqchip/bcm2836: Fix IPI acknowledgement after conversion to
> handle_percpu_devid_irq").

Same.

> parisc: Failed to execute /sbin/init (error -12)
>
> Caused by: c49dd3401802 ("mm: speedup mremap on 1GB or larger regions")

Looks like Kalesh is looking at it.

I don't think that was supposed to matter at all on parisc, but
clearly something bad happened.

parsic doesn't even enable HAVE_MOVE_PMD, much less the new
HAVE_MOVE_PUD. Strange.

                 Linus

Re: Linux 5.11-rc1

[Kalesh Singh]

On Mon, Dec 28, 2020 at 12:59 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, Dec 28, 2020 at 7:51 AM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > Build results:
> >         total: 153 pass: 151 fail: 2
>
> Thanks for doing these for the mainline rc's too. I've seen them for
> the stable kernels, but it's lovely to see it for rc1.
>
> > ERROR: modpost: "irq_check_status_bit" [drivers/perf/arm_spe_pmu.ko] undefined!
> >
> > Caused by: fdd029630434 ("genirq: Move status flag checks to core")
>
> Ahh. Does it just need a
>
>  EXPORT_SYMBOL_GPL(irq_check_status_bit);
>
> in there? Because it looks like at least irq_is_percpu() and
> irq_is_percpu_devid() are used in drivers/perf/ and can apparently be
> modules.
>
> Thomas?
>
> > ia64:defconfig:
> >
> > include/linux/mmzone.h:1156:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE
> >
> > and various related warnings.
> >
> > Caused by: 214496cb1870 ("ia64: make SPARSEMEM default and disable DISCONTIGMEM")
> >
> > Fix submitted ("ia64: fix build failure caused by memory model changes").
>
> Ok, I won't worry about that one.
>
> > qemu boot tests:
> >
> > arm:raspi2 hangs during boot.
> >
> > Caused by: ffdad793d579 ("irqchip/bcm2836: Make IPIs use handle_percpu_devid_irq()")
> >
> > Fix submitted ("irqchip/bcm2836: Fix IPI acknowledgement after conversion to
> > handle_percpu_devid_irq").
>
> Same.
>
> > parisc: Failed to execute /sbin/init (error -12)
> >
> > Caused by: c49dd3401802 ("mm: speedup mremap on 1GB or larger regions")
>
> Looks like Kalesh is looking at it.
>
> I don't think that was supposed to matter at all on parisc, but
> clearly something bad happened.
>
> parsic doesn't even enable HAVE_MOVE_PMD, much less the new
> HAVE_MOVE_PUD. Strange.

Hi Linus,

I had sent the fix for this issue which was taken into the -mm tree by
Andrew. (https://ozlabs.org/~akpm/mmotm/broken-out/mm-mremap-fix-extent-calculation.patch)

Please, let me know if there is anything else needed on my end.

Thanks,
Kalesh

>
>                  Linus

Re: Linux 5.11-rc1

[Guenter Roeck]

On 12/28/20 11:37 AM, Kalesh Singh wrote:

[ ... ]

>>> parisc: Failed to execute /sbin/init (error -12)
>>>
>>> Caused by: c49dd3401802 ("mm: speedup mremap on 1GB or larger regions")
>>
>> Looks like Kalesh is looking at it.
>>
>> I don't think that was supposed to matter at all on parisc, but
>> clearly something bad happened.
>>
>> parsic doesn't even enable HAVE_MOVE_PMD, much less the new
>> HAVE_MOVE_PUD. Strange.
> 
> Hi Linus,
> 
> I had sent the fix for this issue which was taken into the -mm tree by
> Andrew. (https://ozlabs.org/~akpm/mmotm/broken-out/mm-mremap-fix-extent-calculation.patch)
> 

... and I even tested it. Sorry, I should have mentioned it. For some
reason it completely left my mind.

Guenter

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

[Stephen Rothwell]

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

Hi all,

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

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

Commits in v5.11-rc1 (relative to v5.10):          12498
Commits in next-20201214:                          12038
Commits with the same SHA1:                        10988
Commits with the same patch_id:                      500 (1)
Commits with the same subject line:                   47 (1)

(1) not counting those in the lines above.

So commits in -rc1 that were in next-20201214:     11535 92%

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

Top ten first word of commit summary:

    135 perf
     76 drm
     49 kvm
     35 libceph
     31 clk
     27 net
     27 cifs
     26 dt-bindings
     24 tools
     23 ceph

Top ten authors:

     56 acme@redhat.com
     34 thomas.lendacky@amd.com
     34 idryomov@gmail.com
     32 tglx@linutronix.de
     31 leo.yan@linaro.org
     19 trond.myklebust@hammerspace.com
     19 peter.ujfalusi@ti.com
     16 sgarzare@redhat.com
     15 jolsa@kernel.org
     15 jlayton@kernel.org

Top ten commiters:

    158 acme@redhat.com
     88 kuba@kernel.org
     59 idryomov@gmail.com
     57 alexander.deucher@amd.com
     50 pbonzini@redhat.com
     37 axboe@kernel.dk
     36 sboyd@kernel.org
     33 tglx@linutronix.de
     30 stfrench@microsoft.com
     30 mst@redhat.com

There are also 503 commits in next-20201214 that didn't make it into
v5.11-rc1.

Top ten first word of commit summary:

     65 drm
     42 arm
     38 mm
     30 usb
     23 scsi
     23 btrfs
     14 fpga
     12 dt-bindings
     11 sparc32
     11 soc

Top ten authors:

     22 mchehab+huawei@kernel.org
     20 willy@infradead.org
     19 josef@toxicpanda.com
     16 jani.nikula@intel.com
     15 uma.shankar@intel.com
     15 akpm@linux-foundation.org
     14 rppt@kernel.org
     14 mdf@kernel.org
     13 pawell@cadence.com
     12 arnd@arndb.de

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

Top ten commiters:

    121 sfr@canb.auug.org.au
     32 peter.chen@nxp.com
     28 alexandre.torgue@st.com
     23 dsterba@suse.com
     23 dhowells@redhat.com
     22 martin.petersen@oracle.com
     21 mchehab+huawei@kernel.org
     19 geert+renesas@glider.be
     18 mdf@kernel.org
     18 arnd@arndb.de

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 --]