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