linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Linux 5.12-rc1
@ 2021-03-01  0:29 Linus Torvalds
  2021-03-01 20:53 ` Guenter Roeck
  0 siblings, 1 reply; 5+ messages in thread
From: Linus Torvalds @ 2021-03-01  0:29 UTC (permalink / raw)
  To: Linux Kernel Mailing List

So two weeks have passed since the 5.11 release, and so - like
clockwork - the merge window for 5.12 has closed, and 5.12-rc1 is out
there for your perusal.

That said, we have now have two unusual merge windows in a row: first
we had the holiday season, and this time around the Portland area had
over a quarter million people without electricity because we had a
winter ice storm that took down thousands of trees, and lots of
electricity lines.

So I was actually without electricity for six days of the merge
window, and was seriously considering just extending the merge window
to get everything done.

As you can tell, I didn't do that. To a large part because people were
actually very good about sending in their pull requests, so by the
time I finally got power back, everything was nicely lined up and I
got things merged up ok.

But partly this is also because 5.12 is a smaller release than some
previous ones - and that wasn't due to the lack of electricity, that
showed independently in the statistics in the linux-next tree. Of
course, "smaller" is all relative, but instead of the 12-13+k commits
we've had the last few releases, linux-next this time only had 10+k
commits lined up. So that helped things a bit.

That said, if my delayed merging caused issues for anybody, please
holler and explain to me, and I'll be flexible during the rc2 week.
But that's _not_ a blanket "I'll take late pulls", that's very much a
"if my delayed merge caused problems for some tree, explain why, and
I'll work with you".

Anyway, on to the actual changes. Even if it was a slightly smaller
merge window than previous ones, it's still big enough that appended
is just my usual merge log, not the full list of the 10982 non-merge
commits by 1500+ people. So it's  more of a flavor of the kinds of
things that have happened rather than a deep dive.

The one thing that perhaps stands out is that this release actually
did a fair amount of historical cleanup. Yes, overall we still have
more new lines than we have removed lines, but we did have some spring
cleaning, removing the legacy OPROFILE support (the user tools have
been using the "perf" interface for years), and removing several
legacy SoC platforms and various drivers that no longer make any
sense.

So even if we more than made up for that with all the _new_ drivers
and code we added, that kind of cleanup is always nice to see.

    Linus

---

Al Viro (6):
    sendfile updates
    ELF compat updates
    namei updates
    d_name whack-a-mole
    RCU-safe common_lsm_audit()
    misc vfs updates

Alexandre Belloni (2):
    i3c update
    RTC updates

Andreas Gruenbacher (1):
    gfs2 updates

Andrew Morton (2):
    misc updates
    more updates

Anna Schumaker (1):
    NFS Client Updates

Ard Biesheuvel via Borislav Petkov (1):
    EFI updates

Arnaldo Carvalho de Melo (1):
    perf tool updates

Arnd Bergmann (6):
    ARM SoC fixes
    ARM SoC platform removals
    ARM SoC updates
    ARM SoC defconfig updates
    ARM SoC devicetree updates
    ARM SoC driver updates

Bartosz Golaszewski (1):
    gpio updates

Benson Leung (1):
    chrome platform updates

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

Bjorn Helgaas (1):
    PCI updates

Borislav Petkov (14):
    EDAC updates
    RAS updates
    x86 SGX fixes
    x86 SEV-ES fix
    x86 platform updates
    x86 paravirt updates
    x86 mm cleanups
    x86 misc updates
    x86 microcode cleanup
    x86 FPU updates
    x86 CPUID cleanup
    x86 resource control updates
    x86 build updates
    x86 asm updates

Casey Schaufler (1):
    smack updates

Christian Brauner (1):
    idmapped mounts

Christoph Hellwig (1):
    dma-mapping updates

Chuck Lever (2):
    nfsd updates
    more nfsd updates

Corey Minyard (1):
    IPMI update

Damien Le Moal (1):
    zonefs updates

Dan Williams (2):
    libnvdimm and device-dax updates
    initial support for CXL (Compute Express Link)

Daniel Lezcano (1):
    thermal updates

Daniel Thompson (1):
    kgdb updates

Daniel Vetter (2):
    kcmp kconfig update
    follow_pfn() updates

Darrick Wong (3):
    iomap updates
    xfs updates
    more xfs updates

Dave Airlie (2):
    drm updates
    more drm updates

David Howells (1):
    keyring updates

David Kleikamp (1):
    jfs updates

David Miller (2):
    networking updates
    sparc updates

David Sterba (2):
    AFFS fix
    btrfs updates

Dennis Zhou (1):
    percpu updates

Dmitry Torokhov (1):
    input updates

Dominik Brodowski (1):
    pcmcia update

Eric Biederman (1):
    user namespace update

Eric Biggers (1):
    fsverity updates

Gao Xiang (1):
    erofs updates

Geert Uytterhoeven (1):
    m68k updates

Greentime Hu (1):
    nds32 updates

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

Greg Ungerer (1):
    m68knommu update

Guenter Roeck (1):
    hwmon updates

Guo Ren (1):
    arch/csky updates

Hans de Goede (1):
    x86 platform driver updates

Helge Deller (1):
    parisc updates

Herbert Xu (1):
    crypto update

Ilya Dryomov (1):
    ceph updates

Ingo Molnar (5):
    RCU updates
    locking updates
    tlb gather updates
    scheduler updates
    performance event updates

Jaegeuk Kim (1):
    f2fs updates

Jakub Kicinski (1):
    networking fixes

James Bottomley (2):
    SCSI updates
    more SCSI updates

Jan Kara (3):
    lazytime updates
    fsnotify update
    isofs, udf, and quota updates

Jarkko Sakkinen (1):
    tpm updates

Jason Gunthorpe (1):
    rdma updates

Jassi Brar (1):
    mailbox updates

Jeff Layton (1):
    fcntl fix

Jens Axboe (9):
    libata updates
    core block updates
    block driver updates
    io_uring updates
    block IPI updates
    more io_uring updates
    io_uring thread rewrite
    more block updates
    ide fix

Jessica Yu (1):
    module updates

Jiri Kosina (1):
    HID updates

Joerg Roedel (1):
    iommu updates

Jonathan Corbet (2):
    documentation updates
    documentation fixes

Juergen Gross (2):
    xen updates
    more xen updates

Kees Cook (6):
    pstore fix
    seccomp updates
    clang LTO updates
    more clang LTO updates
    clang LTO fixes
    orphan handling fix

Konrad Rzeszutek Wilk (1):
    swiotlb updates

Lee Jones (2):
    backlight updates
    MFD updates

Ley Foon Tan (1):
    arch/nios2 updates

Linus Walleij (1):
    pin control updates

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

Masahiro Yamada (2):
    Kbuild updates
    Kbuild fixes

Mauro Carvalho Chehab (1):
    media updates

Michael Ellerman (1):
    powerpc updates

Michael Tsirkin (1):
    virtio updates

Michal Simek (1):
    microblaze updates

Miguel Ojeda (1):
    auxdisplay updates

Mike Rapoport (1):
    memblock update

Mike Snitzer (1):
    device mapper updates

Mimi Zohar (1):
    IMA updates

Namjae Jeon (1):
    exfat updates

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

Paolo Bonzini (2):
    KVM updates
    more KVM updates

Paul Moore (2):
    selinux updates
    audit updates

Pavel Machek (1):
    LED updates

Petr Mladek (2):
    printk updates
    livepatching updates

Rafael Wysocki (7):
    power management updates
    ACPI updates
    PNP updates
    more power management updates
    more ACPI updates
    Simple Firmware Interface (SFI) support removal
    more ACPI updates

Richard Weinberger (3):
    UML updates
    MTD updates
    JFFS2/UBIFS and UBI updates

Rob Herring (1):
    devicetree updates

Russell King (1):
    ARM updates

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

Shuah Khan (1):
    Kselftest updates
    KUnit updates

Stafford Horne (1):
    OpenRISC updates

Stephen Boyd (1):
    clk updates

Steve French (1):
    cifs updates

Steven Rostedt (2):
    tracing updates
    tracing fixes

Takashi Iwai (1):
    sound updates

Ted Ts'o (1):
    ext4 updates

Tejun Heo (2):
    cgroup updates
    qorkqueue updates

Tetsuo Handa (1):
    tomoyo updates

Thierry Reding (1):
    pwm updates

Thomas Bogendoerfer (2):
    MIPS updates
    more MIPS updates

Thomas Gleixner (5):
    irq updates
    timer updates
    timer fixes
    objtool updates
    x86 irq entry updates

Ulf Hansson (1):
    MMC updates

Vasily Gorbik (2):
    s390 updates
    more s390 updates

Vinod Koul (1):
    dmaengine updates

Viresh Kumar (1):
    oprofile and dcookies removal

Wei Liu (1):
    Hyper-V updates

Will Deacon (2):
    arm64 updates
    arm64 fixes

Wim Van Sebroeck (1):
    watchdog updates

Wolfram Sang (2):
    i2c updates
    i2c fixes

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

* Re: Linux 5.12-rc1
  2021-03-01  0:29 Linux 5.12-rc1 Linus Torvalds
@ 2021-03-01 20:53 ` Guenter Roeck
  0 siblings, 0 replies; 5+ messages in thread
From: Guenter Roeck @ 2021-03-01 20:53 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

On Sun, Feb 28, 2021 at 04:29:34PM -0800, Linus Torvalds wrote:
> So two weeks have passed since the 5.11 release, and so - like
> clockwork - the merge window for 5.12 has closed, and 5.12-rc1 is out
> there for your perusal.
> 

Basic test results look pretty good.

Build results:
	total: 151 pass: 151 fail: 0
Qemu test results:
	total: 435 pass: 435 fail: 0

Guenter

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

* Re: Linux 5.12-rc1
  2021-03-01 21:34 ` Linus Torvalds
@ 2021-03-06  7:01   ` Sedat Dilek
  0 siblings, 0 replies; 5+ messages in thread
From: Sedat Dilek @ 2021-03-06  7:01 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

On Mon, Mar 1, 2021 at 10:34 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, Mar 1, 2021 at 12:35 AM Sedat Dilek <sedat.dilek@gmail.com> wrote:
> >
> > I wondered why there was approx. for 6 days no commits and got an
> > answer from an LWN posting "5.12 Merge window delayed".
> > Unsure, if there was a posting to LKML?
>
> There was no posting to lkml because lkml doesn't take html emails,
> and I only had mobile data (and not even that for the first 24 hours
> or so - even cell towers were down).
>
> I did send updates to several top-level maintainers and to the
> users@kernel.org mailing list, so a lot of people knew about it, but
> they in turn probably only ended up mentioning it on a need-to-know
> basis. As you mention, LWN did have a mention of it, but you'd have to
> find it.
>
> In normal times I would have just taken a laptop to the nearest
> Starbucks and worked that way, but not in the pandemic. Plus the local
> highway was actually shut down for three days because of downed trees
> on the road (this was not a Texas-style electricity generation problem
> - it was literally thousands of trees falling all over. We had one
> miss our house by a couple of meters).
>
> Two weeks later, and the roadways are still littered with trees and
> tons of branches everywhere you drive.
>
> And I didn't have a generator because our local power lines are
> actually buried, and we very seldom lose electricity. But when all the
> feeder lines are down because trees fell over, and it takes a week
> first for the tree crews to clear the roads and then the electric
> crews to replace literally miles of electric cable, it doesn't really
> help all that much that the local lines are buried and all in good
> working order ;)
>
> > Anyway, if you are not able to make your work someone else should jump
> > in like Greg did once.
>
> It was an option, it didn't seem worth it.
>
> And part of _that_ was that it looked like "ok, a couple of days", and
> then it just kept being "one more day" for several days.
>
> A lot of people lost power for just a day or two.
>
> The area I live in probably wasn't a huge priority, because it's
> somewhat sparsely populated, and nice and wooded.
>
> Which is really nice most of the time. It's not quite so nice when you
> can hear the trees keep falling around you, and you know you have a
> few really big ones right next to the house.. ;^p
>

Based on / Freely adapted from Goethe: I answer just when it suits me!

I can hardly imagine your feelings and/or emotions as I was NOT in
such a situation.

I remember "Blackout Münsterland - Münsterländer Schneechaos 2005" [1]
seen on German TV.
150km (approx. 92 miles) from my new home-town.

To make a story short:
Be proud you made a merge-window happen in real 14 -6 = 8 days.
That is amazing, really!

There exist emergency plans - especially for pandemic situations -
here in Germany.
For me it looks like no one cares - including the responsibles.
Exceptional circumstances or you might say "CHAOS".
Sometimes having no plan is good - but never forget your focus or targets.

I wanted to hear from you: Next time in such an exceptional situation
I/we will do ...

And hey yah: Linux v5.12-rc2 on a Saturday Morning @ 06-Mar-2021.
Congrats!

- Sedat -

[1] https://www.youtube.com/watch?v=jfKeGHqrip8

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

* Re: Linux 5.12-rc1
  2021-03-01  8:35 Sedat Dilek
@ 2021-03-01 21:34 ` Linus Torvalds
  2021-03-06  7:01   ` Sedat Dilek
  0 siblings, 1 reply; 5+ messages in thread
From: Linus Torvalds @ 2021-03-01 21:34 UTC (permalink / raw)
  To: Sedat Dilek; +Cc: Linux Kernel Mailing List

On Mon, Mar 1, 2021 at 12:35 AM Sedat Dilek <sedat.dilek@gmail.com> wrote:
>
> I wondered why there was approx. for 6 days no commits and got an
> answer from an LWN posting "5.12 Merge window delayed".
> Unsure, if there was a posting to LKML?

There was no posting to lkml because lkml doesn't take html emails,
and I only had mobile data (and not even that for the first 24 hours
or so - even cell towers were down).

I did send updates to several top-level maintainers and to the
users@kernel.org mailing list, so a lot of people knew about it, but
they in turn probably only ended up mentioning it on a need-to-know
basis. As you mention, LWN did have a mention of it, but you'd have to
find it.

In normal times I would have just taken a laptop to the nearest
Starbucks and worked that way, but not in the pandemic. Plus the local
highway was actually shut down for three days because of downed trees
on the road (this was not a Texas-style electricity generation problem
- it was literally thousands of trees falling all over. We had one
miss our house by a couple of meters).

Two weeks later, and the roadways are still littered with trees and
tons of branches everywhere you drive.

And I didn't have a generator because our local power lines are
actually buried, and we very seldom lose electricity. But when all the
feeder lines are down because trees fell over, and it takes a week
first for the tree crews to clear the roads and then the electric
crews to replace literally miles of electric cable, it doesn't really
help all that much that the local lines are buried and all in good
working order ;)

> Anyway, if you are not able to make your work someone else should jump
> in like Greg did once.

It was an option, it didn't seem worth it.

And part of _that_ was that it looked like "ok, a couple of days", and
then it just kept being "one more day" for several days.

A lot of people lost power for just a day or two.

The area I live in probably wasn't a huge priority, because it's
somewhat sparsely populated, and nice and wooded.

Which is really nice most of the time. It's not quite so nice when you
can hear the trees keep falling around you, and you know you have a
few really big ones right next to the house.. ;^p

                    Linus

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

* Linux 5.12-rc1
@ 2021-03-01  8:35 Sedat Dilek
  2021-03-01 21:34 ` Linus Torvalds
  0 siblings, 1 reply; 5+ messages in thread
From: Sedat Dilek @ 2021-03-01  8:35 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel

[ Please CC me I am not subscribed to LKML ]
[ Original post see [0] ]

Hi Linus,

Thanks for Linux v5.12-rc1 and all involved people.

[ Delayed merge-window ]

I wondered why there was approx. for 6 days no commits and got an
answer from an LWN posting "5.12 Merge window delayed".
Unsure, if there was a posting to LKML?

Anyway, if you are not able to make your work someone else should jump
in like Greg did once.
When Stephen could not do his work someone else jumped in and did the
Linux-next work.

There should be a clear communication and alternative workflow in such
situation.
Why not post such delays on <kernel.org> (if this is the official website)?

[ News - Clang-LTO ]

Always I read your "RC" announcement and would like to see some
pointers to interesting new stuff.
( I know "interesting" is very POV. )

Thanks for pointing to the several clean-ups in Linux v5.12-rc1.

As someone active on ClangBuiltLinux - we have now Clang-LTO support
for arm64 and x86-64.

Some issues I have seen and reported:

[ Issues - iwlwifi / iwldwm ]

I know of a call-trace for users of iwldwm device.
You will need "iwlwifi: avoid crash on unsupported debug collection"
patch (see [2]).

[ Issues -usb / xhci ]

I reported xhci-resets every 10min in "[xhci] usb 4-1: reset
SuperSpeed Gen 1 USB device number 2 using xhci_hcd" thread (see [3]).
No response, yet.

Some ideas and feedback from me, myself and I.

Have more fun!

Regards,
- Sedat -

[0] https://marc.info/?l=linux-kernel&m=161455865730695&w=2
[1] https://lwn.net/Articles/846406/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git/
[3] https://marc.info/?t=161417912800001&r=1&w=2

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

end of thread, other threads:[~2021-03-06  7:03 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-01  0:29 Linux 5.12-rc1 Linus Torvalds
2021-03-01 20:53 ` Guenter Roeck
2021-03-01  8:35 Sedat Dilek
2021-03-01 21:34 ` Linus Torvalds
2021-03-06  7:01   ` Sedat Dilek

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).