So I did debate calling it 5.0, but if we all help each other, I'm
sure we can count to 20. It's a nice round number, and I didn't want
to make a pattern of it. I think 5.0 happens next year, because then I
*really* run out of fingers and toes.
Anyway, 4.20-rc1 is tagged and pushed out, and the merge window is
over. This was a fairly big merge window, but it didn't break any
records, just solid. And things look pretty regular, with about 70% of
the patch is driver updates (gpu drivers are looming large as usual,
but there's changes all over). The rest is arch updates (x86, arm64,
arm, powerpc and the new C-SKY architecture), header files,
networking, core mm and kernel, and tooling.
In fact, tooling is quite noticeable. A fair amount of selftest
changes, but also various perf tooling updates.
There's a vfs pull request I declined and it might still go in later
in a slightly reduced form, but apart from that I think everything got
merged. We had one pull request that almost missed the merge windows
due to a silly change in my email setup, but I verified that nothing
else had happened to hit that special case.
One thing I _would_ like to point out as the merge window closes: I
tend to delay some pull requests that I want to take a closer look at
until the second week of the merge window when things are calming
down, and that _really_ means that I'd like to get all the normal pull
requests in the first week of the two-week merge window. And most
people really followed that, but by Wednesday this week I had gotten a
big frustrated that I kept getting new pull requests when I wanted to
really just spend most of the day looking through the ones that
deserved a bit of extra attention.
And yes, people generally kind of know about this and I really do get
*most* pull requests early. But I'm considering trying to make that a
more explicit rule that I will literally stop taking new pull requests
some time during the second week unless you have a good reason for why
it was delayed.
Because yes, the merge window is two weeks, but it's two weeks partly
exactly _because_ people (not just me) sometimes need extra time to
resolve any possible issues, not because regular everyday pull
requests should spread out over the whole two weeks. The development
for things meant for the next release should have been done by the
time the merge window opens.
Anyway, let's see. Maybe it won't be needed. It hasn't become a
problem, it just was starting to feel a bit tight there.
Oh, and I did try to do the reply emails. And I'm _entirely_ sure that
I must have missed acknowledging emails for a few pull requests. I'm
hoping that by the time the next merge window rolls around, we'll just
have new automation for it, so that everybody just automatically gets
notified when their pull request hit mainline. In the meantime, you
have a good chance - but not a guarantee - that I'll send a "Pulled"
ack email when I start processing a pull request.
And as usual for rc1, the log below is just the list of people I
pulled from with a one-liner "mergelog". Very much a high-level
summary of merges, for details you need to look into the git tree..
Linus
---
Al Viro (8):
tty ioctl updates
vfs fixes
compat_ioctl fixes
alpha syscall glue updates
more ->lookup() cleanups
AFS updates
misc vfs updates
9p fix
Alex Williamson (1):
VFIO updates
Alexandre Belloni (1):
RTC updates
Andrew Morton (3):
updates
more updates
more updates
Arnd Bergmann (4):
ARM SoC device tree updates
ARM SoC defconfig updates
ARM SoC driver updates
ARM SoC platform updates
Bartlomiej Zolnierkiewicz (1):
fbdev updates
Benson Leung (1):
chrome-platform updates
Bjorn Andersson (2):
remoteproc updates
rpmsg updates
Bjorn Helgaas (1):
PCI updates
Bob Peterson (1):
gfs2 updates
Boris Brezillon (1):
mtd updates
Borislav Petkov (2):
EDAC updates
more EDAC updates
Bruce Fields (1):
nfsd updates
Catalin Marinas (2):
arm64 updates
more arm64 updates
Christoph Hellwig (3):
dma mapping updates
more dma-mapping updates
dma-mapping fix
Corey Minyard (1):
IPMI updates
Dan Williams (1):
libnvdimm updates
Darren Hart (1):
x86 platform driver updates
Dave Airlie (2):
drm updates
drm fixes
Dave Chinner (1):
vfs dedup fixes
David Kleikamp (1):
jfs updates
David Miller (8):
sparc updates
networking updates
sparc fix
sparc fixes
networking fixes
networking fixes
sparc fixes
networking fixes
David Sterba (2):
btrfs updates
more btrfs updates
Dennis Zhou (1):
percpu fixes
Dmitry Torokhov (1):
input updates
Dominik Brodowski (1):
pcmcia fixes
Dominique Martinet (1):
9p updates
Eduardo Valentin (1):
thermal SoC updates
Eric Biederman (1):
siginfo updates
Geert Uytterhoeven (1):
m68k updates
Greg KH (5):
USB/PHY updates
driver core updates
char/misc driver updates
staging/IIO driver updates
tty/serial updates
Greg Ungerer (1):
m68k nommu fix
Guenter Roeck (1):
hwmon updates
Guo Ren (2):
C-SKY architecture port
csky dtb fixups
Helge Deller (2):
parisc updates
parisc updates
Herbert Xu (1):
crypto updates
Ilya Dryomov (1):
ceph updates
Ingo Molnar (22):
RCU updates
EFI updates
locking and misc x86 updates
perf updates
RAS updates
scheduler updates
x86 apic updates
x86 asm updates
x86 boot updates
x86 build update
x86 cpu updates
x86 grub2 updates
x86 hyperv updates
x86 mm updates
x86 paravirt updates
x86 platform updates
x86 pti updates
x86 vdso updates
irq fixes
perf updates and fixes
x86 fixes
scheduler fixes
Jacek Anaszewski (2):
LED updates
LED fix
Jaegeuk Kim (1):
f2fs updates
James Bottomley (2):
SCSI updates
more SCSI updates
James Morris (6):
security subsystem updates
integrity updates
TPM updates
smack updates
LoadPin updates
keys updates
Jan Kara (2):
fsnotify updates
ext2 and udf updates
Jason Gunthorpe (1):
rdma updates
Jassi Brar (1):
mailbox updates
Jens Axboe (4):
block layer updates
libata updates
more block layer updates
block layer fixes
Jiri Kosina (1):
HID updates
Joerg Roedel (1):
IOMMU updates
John Johansen (1):
apparmor updates
Jon Mason (1):
NTB updates
Jonathan Corbet (1):
documentation updates
Juergen Gross (1):
xen fixes
Kees Cook (3):
pstore updates
VLA removal
stackleak gcc plugin
Konrad Rzeszutek Wilk (1):
xen swiotlb fix
Lee Jones (2):
MFD updates
backlight updates
Linus Walleij (2):
pin control updates
GPIO updates
Mark Brown (3):
regmap updates
spi updates
regulator updates
Mark Salter (1):
c6x update
Martin Schwidefsky (1):
s390 updates
Masahiro Yamada (2):
Kbuild updates
Kbuild updates
Matthew Wilcox (1):
XArray conversion
Mauro Carvalho Chehab (2):
media updates
new experimental media request API
Max Filippov (1):
Xtensa fixes and cleanups
Michael Ellerman (2):
powerpc updates
powerpc fixes
Michael Tsirkin (1):
virtio/vhost updates
Miguel Ojeda (1):
compiler attribute updates
Mike Marshall (1):
orangefs updates
Mike Snitzer (1):
device mapper updates
Miklos Szeredi (2):
fuse updates
overlayfs updates
Nicolas Pitre (1):
cramfs fixes
Olof Johansson (1):
ARM SoC fixes
Palmer Dabbelt (3):
RISC-V updates
more RISC-V updates
RISC-V defconfig update
Paul Burton (2):
MIPS fixes
MIPS updates
Paul Moore (1):
SELinux updates
Petr Mladek (1):
printk updates
Radim Krčmář (1):
KVM updates
Rafael Wysocki (4):
power management updates
ACPI updates
more power management updates
more ACPI updates
Richard Weinberger (2):
UML updates
UBIFS updates
Rob Herring (2):
Devicetree updates
Devicetree fixes
Russell King (1):
ARM updates
Sebastian Reichel (1):
power supply and reset updates
Shaohua Li (1):
md updates
Shuah Khan (1):
kselftest updates
Stephen Boyd (1):
clk updates
Steve French (2):
cifs updates
cifs fixes and updates
Steven Rostedt (2):
tracing fixes
tracing updates
Takashi Iwai (2):
sound updates
sound fixes
Ted Ts'o (1):
ext4 updates
Tejun Heo (1):
cgroup updates
Thierry Reding (1):
pwm updates
Thomas Gleixner (3):
timekeeping updates
irq updates
more timer updates
Tony Luck (1):
ia64 updates
Trond Myklebust (2):
NFS client updates
NFS client bugfixes
Ulf Hansson (1):
MMC updates
Vinod Koul (1):
dmaengine updates
Wim Van Sebroeck (1):
watchdog updates
Wolfram Sang (2):
i2c updates
i2c fixes
Zhang Rui (1):
thermal management updates
Linus Torvalds <[email protected]> writes:
...
> Mike Snitzer (1):
> device mapper updates
Hi Mike,
Replying here because I can't find the device-mapper pull or the patch
in question on LKML. I guess I should be subscribed to dm-devel.
We have a box that doesn't boot any more, bisect points at one of:
cef6f55a9fb4 Mike Snitzer dm table: require that request-based DM be layered on blk-mq devices
953923c09fe8 Mike Snitzer dm: rename DM_TYPE_MQ_REQUEST_BASED to DM_TYPE_REQUEST_BASED
6a23e05c2fe3 Jens Axboe dm: remove legacy request-based IO path
It's a Power8 system running Rawhide, it does have multipath, but I'm
told it was setup by the Fedora installer, ie. nothing fancy.
The symptom is the system can't find its root filesystem and drops into
the initramfs shell. The dmesg includes a bunch of errors like below:
[ 43.263460] localhost multipathd[1344]: sdb: fail to get serial
[ 43.268762] localhost multipathd[1344]: mpatha: failed in domap for addition of new path sdb
[ 43.268762] localhost multipathd[1344]: uevent trigger error
[ 43.282065] localhost kernel: device-mapper: table: table load rejected: not all devices are blk-mq request-stackable
[ 43.282096] localhost kernel: device-mapper: table: unable to determine table type
[ 43.275898] localhost multipathd[1344]: sdd: fail to get serial
[ 43.282597] localhost multipathd[1344]: mpatha: failed in domap for addition of new path sdd
[ 43.282642] localhost multipathd[1344]: uevent trigger error
[ 43.286540] localhost multipathd[1344]: sdc: fail to get serial
[ 43.296366] localhost kernel: device-mapper: table: table load rejected: not all devices are blk-mq request-stackable
[ 43.296392] localhost kernel: device-mapper: table: unable to determine table type
[ 43.292218] localhost multipathd[1344]: mpathb: failed in domap for addition of new path sdc
[ 43.292218] localhost multipathd[1344]: uevent trigger error
[ 43.306193] localhost kernel: device-mapper: table: table load rejected: not all devices are blk-mq request-stackable
[ 43.306212] localhost kernel: device-mapper: table: unable to determine table type
[ 150.523303] localhost dracut-initqueue[1325]: Warning: dracut-initqueue timeout - starting timeout scripts
There's more info here if you want it:
https://github.com/linuxppc/linux/issues/203
Any ideas what's going wrong here?
cheers
On Mon, Nov 05 2018 at 5:25am -0500,
Michael Ellerman <[email protected]> wrote:
> Linus Torvalds <[email protected]> writes:
> ...
> > Mike Snitzer (1):
> > device mapper updates
>
> Hi Mike,
>
> Replying here because I can't find the device-mapper pull or the patch
> in question on LKML. I guess I should be subscribed to dm-devel.
>
> We have a box that doesn't boot any more, bisect points at one of:
>
> cef6f55a9fb4 Mike Snitzer dm table: require that request-based DM be layered on blk-mq devices
> 953923c09fe8 Mike Snitzer dm: rename DM_TYPE_MQ_REQUEST_BASED to DM_TYPE_REQUEST_BASED
> 6a23e05c2fe3 Jens Axboe dm: remove legacy request-based IO path
>
>
> It's a Power8 system running Rawhide, it does have multipath, but I'm
> told it was setup by the Fedora installer, ie. nothing fancy.
>
> The symptom is the system can't find its root filesystem and drops into
> the initramfs shell. The dmesg includes a bunch of errors like below:
>
> [ 43.263460] localhost multipathd[1344]: sdb: fail to get serial
> [ 43.268762] localhost multipathd[1344]: mpatha: failed in domap for addition of new path sdb
> [ 43.268762] localhost multipathd[1344]: uevent trigger error
> [ 43.282065] localhost kernel: device-mapper: table: table load rejected: not all devices are blk-mq request-stackable
...
>
> Any ideas what's going wrong here?
"table load rejected: not all devices are blk-mq request-stackable"
speaks to the fact that you aren't using blk-mq for scsi (aka scsi-mq).
You need to use scsi_mod.use_blk_mq=Y on the kernel commandline (or set
CONFIG_SCSI_MQ_DEFAULT in your kernel config)
Mike
On Mon, Nov 05, 2018 at 08:51:57AM -0500, Mike Snitzer wrote:
> On Mon, Nov 05 2018 at 5:25am -0500,
> Michael Ellerman <[email protected]> wrote:
>
> > Linus Torvalds <[email protected]> writes:
> > ...
> > > Mike Snitzer (1):
> > > device mapper updates
> >
> > Hi Mike,
> >
> > Replying here because I can't find the device-mapper pull or the patch
> > in question on LKML. I guess I should be subscribed to dm-devel.
> >
> > We have a box that doesn't boot any more, bisect points at one of:
> >
> > cef6f55a9fb4 Mike Snitzer dm table: require that request-based DM be layered on blk-mq devices
> > 953923c09fe8 Mike Snitzer dm: rename DM_TYPE_MQ_REQUEST_BASED to DM_TYPE_REQUEST_BASED
> > 6a23e05c2fe3 Jens Axboe dm: remove legacy request-based IO path
> >
> >
> > It's a Power8 system running Rawhide, it does have multipath, but I'm
> > told it was setup by the Fedora installer, ie. nothing fancy.
> >
> > The symptom is the system can't find its root filesystem and drops into
> > the initramfs shell. The dmesg includes a bunch of errors like below:
> >
> > [ 43.263460] localhost multipathd[1344]: sdb: fail to get serial
> > [ 43.268762] localhost multipathd[1344]: mpatha: failed in domap for addition of new path sdb
> > [ 43.268762] localhost multipathd[1344]: uevent trigger error
> > [ 43.282065] localhost kernel: device-mapper: table: table load rejected: not all devices are blk-mq request-stackable
> ...
> >
> > Any ideas what's going wrong here?
>
> "table load rejected: not all devices are blk-mq request-stackable"
> speaks to the fact that you aren't using blk-mq for scsi (aka scsi-mq).
>
> You need to use scsi_mod.use_blk_mq=Y on the kernel commandline (or set
> CONFIG_SCSI_MQ_DEFAULT in your kernel config)
Thanks Mike!, above solution worked and the system booted fine now:-)
# uname -r
4.20.0-rc1+
# cat /proc/cmdline
root=/dev/mapper/fedora_ltc--test--ci2-root ro rd.lvm.lv=fedora_ltc-test-ci2/root rd.lvm.lv=fedora_ltc-test-ci2/swap scsi_mod.use_blk_mq=Y
CONFIG_SCSI_MQ_DEFAULT kernel was not set in my kernel config, will set in future runs.
Thanks Michael!
Regards,
-Satheesh.
>
> Mike
>
On 11/5/18 7:35 AM, Satheesh Rajendran wrote:
> On Mon, Nov 05, 2018 at 08:51:57AM -0500, Mike Snitzer wrote:
>> On Mon, Nov 05 2018 at 5:25am -0500,
>> Michael Ellerman <[email protected]> wrote:
>>
>>> Linus Torvalds <[email protected]> writes:
>>> ...
>>>> Mike Snitzer (1):
>>>> device mapper updates
>>>
>>> Hi Mike,
>>>
>>> Replying here because I can't find the device-mapper pull or the patch
>>> in question on LKML. I guess I should be subscribed to dm-devel.
>>>
>>> We have a box that doesn't boot any more, bisect points at one of:
>>>
>>> cef6f55a9fb4 Mike Snitzer dm table: require that request-based DM be layered on blk-mq devices
>>> 953923c09fe8 Mike Snitzer dm: rename DM_TYPE_MQ_REQUEST_BASED to DM_TYPE_REQUEST_BASED
>>> 6a23e05c2fe3 Jens Axboe dm: remove legacy request-based IO path
>>>
>>>
>>> It's a Power8 system running Rawhide, it does have multipath, but I'm
>>> told it was setup by the Fedora installer, ie. nothing fancy.
>>>
>>> The symptom is the system can't find its root filesystem and drops into
>>> the initramfs shell. The dmesg includes a bunch of errors like below:
>>>
>>> [ 43.263460] localhost multipathd[1344]: sdb: fail to get serial
>>> [ 43.268762] localhost multipathd[1344]: mpatha: failed in domap for addition of new path sdb
>>> [ 43.268762] localhost multipathd[1344]: uevent trigger error
>>> [ 43.282065] localhost kernel: device-mapper: table: table load rejected: not all devices are blk-mq request-stackable
>> ...
>>>
>>> Any ideas what's going wrong here?
>>
>> "table load rejected: not all devices are blk-mq request-stackable"
>> speaks to the fact that you aren't using blk-mq for scsi (aka scsi-mq).
>>
>> You need to use scsi_mod.use_blk_mq=Y on the kernel commandline (or set
>> CONFIG_SCSI_MQ_DEFAULT in your kernel config)
>
> Thanks Mike!, above solution worked and the system booted fine now:-)
This quirk will go away for the next kernel, fwiw, since the non-mq
path for SCSI will be dropped as well.
--
Jens Axboe
On Sun, Nov 04, 2018 at 04:12:45PM -0800, Linus Torvalds wrote:
>
> Because yes, the merge window is two weeks, but it's two weeks partly
> exactly _because_ people (not just me) sometimes need extra time to
> resolve any possible issues, not because regular everyday pull
> requests should spread out over the whole two weeks. The development
> for things meant for the next release should have been done by the
> time the merge window opens.
>
> Anyway, let's see. Maybe it won't be needed. It hasn't become a
> problem, it just was starting to feel a bit tight there.
I'm curious what others find to be the cause of hitting the second half
of the merge window. For my part, I have traditionally monitored the
tail end of the RC period waiting for the version tag to land. Other
times, like this time, work and travel get hectic, and I realize later
than I should that it was time to send in the PR.
I imagine many of us have just written notification scripts for version
tags, or emails from you matching certain subject patterns - but for my
part, a more predictable end of the RC period and/or an explicit email
to maintainers listed in the MAINTAINER file would be helpful. Would you
consider adding a step to your git tag process to scan the MAINTAINERS
file and send us a "Ready your PRs!" email with a note about preferring
to get these during the first week wherever possible? This seems like it
could be easily automated, easily filtered by those that might not want
it, and reduces the number of times you have to explain your preference
as new maintainers come and go.
--
Darren Hart
VMware Open Source Technology Center
Mike Snitzer <[email protected]> writes:
> On Mon, Nov 05 2018 at 5:25am -0500,
> Michael Ellerman <[email protected]> wrote:
>
>> Linus Torvalds <[email protected]> writes:
>> ...
>> > Mike Snitzer (1):
>> > device mapper updates
>>
>> Hi Mike,
>>
>> Replying here because I can't find the device-mapper pull or the patch
>> in question on LKML. I guess I should be subscribed to dm-devel.
>>
>> We have a box that doesn't boot any more, bisect points at one of:
>>
>> cef6f55a9fb4 Mike Snitzer dm table: require that request-based DM be layered on blk-mq devices
>> 953923c09fe8 Mike Snitzer dm: rename DM_TYPE_MQ_REQUEST_BASED to DM_TYPE_REQUEST_BASED
>> 6a23e05c2fe3 Jens Axboe dm: remove legacy request-based IO path
>>
>>
>> It's a Power8 system running Rawhide, it does have multipath, but I'm
>> told it was setup by the Fedora installer, ie. nothing fancy.
>>
>> The symptom is the system can't find its root filesystem and drops into
>> the initramfs shell. The dmesg includes a bunch of errors like below:
>>
>> [ 43.263460] localhost multipathd[1344]: sdb: fail to get serial
>> [ 43.268762] localhost multipathd[1344]: mpatha: failed in domap for addition of new path sdb
>> [ 43.268762] localhost multipathd[1344]: uevent trigger error
>> [ 43.282065] localhost kernel: device-mapper: table: table load rejected: not all devices are blk-mq request-stackable
> ...
>>
>> Any ideas what's going wrong here?
>
> "table load rejected: not all devices are blk-mq request-stackable"
> speaks to the fact that you aren't using blk-mq for scsi (aka scsi-mq).
>
> You need to use scsi_mod.use_blk_mq=Y on the kernel commandline (or set
> CONFIG_SCSI_MQ_DEFAULT in your kernel config)
Thanks.
Looks like CONFIG_SCSI_MQ_DEFAULT is default y, so new configs should
pick that up by default. We must have had an old .config that didn't get
that update.
cheers
Hi all,
As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)
(No merge commits counted, next-20181019 was the last linux-next before
the merge window opened.)
Commits in v4.20-rc1 (relative to v4.19): 12125
Commits in next-20181019: 11296
Commits with the same SHA1: 10466
Commits with the same patch_id: 526 (1)
Commits with the same subject line: 56 (1)
(1) not counting those in the lines above.
So commits in -rc1 that were in next-20181019: 11048 91%
Some breakdown of the list of extra commits (relative to next-20181019)
in -rc1:
Top ten first word of commit summary:
86 net
60 powerpc
56 perf
54 media
36 drm
33 pci
32 thermal
32 bpf
23 ubifs
21 selftests
Top ten authors:
36 [email protected]
28 [email protected]
28 [email protected]
25 [email protected]
24 [email protected]
23 [email protected]
21 [email protected]
21 [email protected]
21 [email protected]
21 [email protected]
Top ten commiters:
161 [email protected]
72 [email protected]
65 [email protected]
54 [email protected]
41 [email protected]
33 [email protected]
32 [email protected]
31 [email protected]
31 [email protected]
29 [email protected]
There are also 250 commits in next-20181019 that didn't make it into
v4.20-rc1.
Top ten first word of commit summary:
28 vfs
21 mm
18 leaking_addresses
14 arm
11 nfc
10 interconnect
10 btrfs
9 xtensa
7 arm-soc
6 drm
Top ten authors:
38 [email protected]
19 [email protected]
18 [email protected]
11 [email protected]
9 [email protected]
9 [email protected]
7 [email protected]
6 [email protected]
5 [email protected]
5 [email protected]
Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).
Top ten commiters:
75 [email protected]
40 [email protected]
18 [email protected]
13 [email protected]
11 [email protected]
10 [email protected]
9 [email protected]
9 [email protected]
7 [email protected]
7 [email protected]
Those commits by me are from the quilt series (mainly Andrew's mmotm
tree).
--
Cheers,
Stephen Rothwell