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
[ Please CC me I am not subscribed to LKML and linux-kbuild ML ]
Hi Linus, Hi Mashiro,
thanks for the Linux v5.11-rc1 release.
With a new release I always do my first builds with my distro's
default compiler and linker (GCC v10.2.1 and GNU/ld BFD v2.35.1).
( It's approx. 40% faster than LLVM toolchain v11.0.1-rc2 here on
Debian/testing AMD64. )
The only warning I see for the first time (with v5.10.3 not observed):
sh ./scripts/depmod.sh depmod 5.11.0-rc1-1-amd64-gcc10-bfd
Warning: 'make modules_install' requires depmod. Please install it.
This is probably in the kmod package.
The only change I see in this area is:
436e980e2ed5 kbuild: don't hardcode depmod path
depmod from kmod Debian package is placed and I have no /sbin in my
user's path (and not before?):
$ dpkg -L kmod | grep bin | grep depmod
/sbin/depmod
$ which depmod
[ empty ]
$ echo $PATH
/opt/proxychains-ng/bin:/home/dileks/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
OK, this is a warning, but might confuse other users.
Please, let me know if you need further information and keep me CCed.
Thanks.
Regards,
- Sedat -
[1] https://git.kernel.org/linus/436e980e2ed526832de822cbf13c317a458b78e1
On Mon, Dec 28, 2020 at 8:30 AM Sedat Dilek <[email protected]> wrote:
>
> [ Please CC me I am not subscribed to LKML and linux-kbuild ML ]
>
> Hi Linus, Hi Mashiro,
>
> thanks for the Linux v5.11-rc1 release.
>
> With a new release I always do my first builds with my distro's
> default compiler and linker (GCC v10.2.1 and GNU/ld BFD v2.35.1).
> ( It's approx. 40% faster than LLVM toolchain v11.0.1-rc2 here on
> Debian/testing AMD64. )
>
> The only warning I see for the first time (with v5.10.3 not observed):
>
> sh ./scripts/depmod.sh depmod 5.11.0-rc1-1-amd64-gcc10-bfd
> Warning: 'make modules_install' requires depmod. Please install it.
> This is probably in the kmod package.
>
> The only change I see in this area is:
>
> 436e980e2ed5 kbuild: don't hardcode depmod path
>
> depmod from kmod Debian package is placed and I have no /sbin in my
> user's path (and not before?):
>
> $ dpkg -L kmod | grep bin | grep depmod
> /sbin/depmod
>
> $ which depmod
> [ empty ]
>
> $ echo $PATH
> /opt/proxychains-ng/bin:/home/dileks/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
>
> OK, this is a warning, but might confuse other users.
>
> Please, let me know if you need further information and keep me CCed.
>
> Thanks.
>
> Regards,
> - Sedat -
>
> [1] https://git.kernel.org/linus/436e980e2ed526832de822cbf13c317a458b78e1
[ Correct email-address of linux-kbuild ML ]
This might be distro-specific:
[ /etc/login.defs ]
99:# *REQUIRED* The default PATH settings, for superuser and normal users.
100:#
101:# (they are minimal, add the rest in the shell startup files)
102:ENV_SUPATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
103:ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
What is your recommendation?
- Sedat -
On Mon, Dec 28, 2020 at 9:04 AM Sedat Dilek <[email protected]> wrote:
>
> On Mon, Dec 28, 2020 at 8:30 AM Sedat Dilek <[email protected]> wrote:
> >
> > [ Please CC me I am not subscribed to LKML and linux-kbuild ML ]
> >
> > Hi Linus, Hi Mashiro,
> >
> > thanks for the Linux v5.11-rc1 release.
> >
> > With a new release I always do my first builds with my distro's
> > default compiler and linker (GCC v10.2.1 and GNU/ld BFD v2.35.1).
> > ( It's approx. 40% faster than LLVM toolchain v11.0.1-rc2 here on
> > Debian/testing AMD64. )
> >
> > The only warning I see for the first time (with v5.10.3 not observed):
> >
> > sh ./scripts/depmod.sh depmod 5.11.0-rc1-1-amd64-gcc10-bfd
> > Warning: 'make modules_install' requires depmod. Please install it.
> > This is probably in the kmod package.
> >
> > The only change I see in this area is:
> >
> > 436e980e2ed5 kbuild: don't hardcode depmod path
> >
> > depmod from kmod Debian package is placed and I have no /sbin in my
> > user's path (and not before?):
> >
> > $ dpkg -L kmod | grep bin | grep depmod
> > /sbin/depmod
> >
> > $ which depmod
> > [ empty ]
> >
> > $ echo $PATH
> > /opt/proxychains-ng/bin:/home/dileks/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
> >
> > OK, this is a warning, but might confuse other users.
> >
> > Please, let me know if you need further information and keep me CCed.
> >
> > Thanks.
> >
> > Regards,
> > - Sedat -
> >
> > [1] https://git.kernel.org/linus/436e980e2ed526832de822cbf13c317a458b78e1
>
> [ Correct email-address of linux-kbuild ML ]
>
> This might be distro-specific:
>
> [ /etc/login.defs ]
>
> 99:# *REQUIRED* The default PATH settings, for superuser and normal users.
> 100:#
> 101:# (they are minimal, add the rest in the shell startup files)
> 102:ENV_SUPATH
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> 103:ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
>
> What is your recommendation?
>
For now, I reverted the above commit and use DEPMOD="/sbin/depmod".
Can I pass DEPMOD="/sbin/depmod" to my make line to override the
default DEPMOD in the top level Makefile?
- Sedat -
[ Please CC me I am not subscribed to LKML and linux-kbuild ML ]
Hi Linus,
I also tested with LLVM toolchain v11.0.1-rc2 together with passing
LLVM=1 and LLVM_IAS=1 to my make line.
I had one ERROR:
error: too few operands for instruction in arch/x86/kvm/svm/sev.c
The issue was reported in ClangBuiltLinux (CBL) issue #1216.
A fix was offered in [2] and fixes the issue on the kernel-side.
I had one WARNING:
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
eb_relocate_parse_slow()+0x3d0: stack state mismatch: cfa1=7+120
cfa2=-1+0
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
eb_copy_relocations()+0x229: stack state mismatch: cfa1=7+120
cfa2=-1+0
Looks like a similar issue was reported as
"drivers/gpu/drm/i915/gem/i915_gem_execbuffer: objtool warning on
stack state mismatch" in [3].
I CCed Josh in the CBL issue #1192.
Thanks.
Regards,
- Sedat -
[1] https://github.com/ClangBuiltLinux/linux/issues/1216
[2] https://lore.kernel.org/kvm/[email protected]/
[3] https://github.com/ClangBuiltLinux/linux/issues/1192
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
On Mon, Dec 28, 2020 at 7:51 AM Guenter Roeck <[email protected]> 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
On Mon, Dec 28, 2020 at 8:45 PM Linus Torvalds
<[email protected]> wrote:
>
> On Mon, Dec 28, 2020 at 7:26 AM Sedat Dilek <[email protected]> wrote:
> >
> > I also tested with LLVM toolchain v11.0.1-rc2 together with passing
> > LLVM=1 and LLVM_IAS=1 to my make line.
> >
> > I had one ERROR:
> >
> > error: too few operands for instruction in arch/x86/kvm/svm/sev.c
>
> Looks like Paolo already picked up the fix, so this should be fixed
> when I get the next kvm pull request.
>
> That said, you might want to make sure the LLVM people know about this too.
>
Done.
- Sedat -
[1] https://github.com/ClangBuiltLinux/linux/issues/1216
[2] https://github.com/ClangBuiltLinux/linux/issues/1216#issuecomment-751846419
> The whole "implicit arguments" is a common thing in x86, where lots of
> instructions don't need to spell them out explicitly, because of fixed
> register allocation (example: divide/multiply instructions only work
> with ax/dx as a target etc).
>
> Linus
On Mon, Dec 28, 2020 at 8:40 PM Linus Torvalds
<[email protected]> wrote:
>
> On Mon, Dec 28, 2020 at 12:04 AM Sedat Dilek <[email protected]> wrote:
> >
> > > $ dpkg -L kmod | grep bin | grep depmod
> > > /sbin/depmod
> > >
> > > $ which depmod
> > > [ empty ]
> > >
> > > $ echo $PATH
> > > /opt/proxychains-ng/bin:/home/dileks/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
>
> Ok, I think this is a broken setup that has a separate /sbin but does
> not have it in the PATH.
>
> As you noticed, you can fix it with
>
> DEPMOD=/sbin/depmod
>
> or you could just make /sbin part of your PATH.
>
> It looks like on your distro, /sbin is restricted to just the
> super-user PATH, which is odd, but I guess there's at least _some_
> logic to it.
>
> I guess we could have some compatibility thing in scripts/depmod.sh,
> something like
>
> diff --git a/scripts/depmod.sh b/scripts/depmod.sh
> index e083bcae343f..a93261207453 100755
> --- a/scripts/depmod.sh
> +++ b/scripts/depmod.sh
> @@ -15,6 +15,8 @@ if ! test -r System.map ; then
> exit 0
> fi
>
> +# legacy behavior: "depmod" in /sbin
> +PATH="$PATH:/sbin"
> if [ -z $(command -v $DEPMOD) ]; then
> echo "Warning: 'make modules_install' requires $DEPMOD. Please
> install it." >&2
> echo "This is probably in the kmod package." >&2
>
> or similar. Does that work for you?
>
Looks like it works.
I see:
sh ./scripts/depmod.sh depmod 5.11.0-rc1-2-amd64-clang-ias
But no more a depmod warning.
Will you send a patch or apply this directly?
- Sedat -
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
On Mon, Dec 28, 2020 at 7:26 AM Sedat Dilek <[email protected]> wrote:
>
> I also tested with LLVM toolchain v11.0.1-rc2 together with passing
> LLVM=1 and LLVM_IAS=1 to my make line.
>
> I had one ERROR:
>
> error: too few operands for instruction in arch/x86/kvm/svm/sev.c
Looks like Paolo already picked up the fix, so this should be fixed
when I get the next kvm pull request.
That said, you might want to make sure the LLVM people know about this too.
The whole "implicit arguments" is a common thing in x86, where lots of
instructions don't need to spell them out explicitly, because of fixed
register allocation (example: divide/multiply instructions only work
with ax/dx as a target etc).
Linus
On Mon, Dec 28, 2020 at 12:04 AM Sedat Dilek <[email protected]> wrote:
>
> > $ dpkg -L kmod | grep bin | grep depmod
> > /sbin/depmod
> >
> > $ which depmod
> > [ empty ]
> >
> > $ echo $PATH
> > /opt/proxychains-ng/bin:/home/dileks/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
Ok, I think this is a broken setup that has a separate /sbin but does
not have it in the PATH.
As you noticed, you can fix it with
DEPMOD=/sbin/depmod
or you could just make /sbin part of your PATH.
It looks like on your distro, /sbin is restricted to just the
super-user PATH, which is odd, but I guess there's at least _some_
logic to it.
I guess we could have some compatibility thing in scripts/depmod.sh,
something like
diff --git a/scripts/depmod.sh b/scripts/depmod.sh
index e083bcae343f..a93261207453 100755
--- a/scripts/depmod.sh
+++ b/scripts/depmod.sh
@@ -15,6 +15,8 @@ if ! test -r System.map ; then
exit 0
fi
+# legacy behavior: "depmod" in /sbin
+PATH="$PATH:/sbin"
if [ -z $(command -v $DEPMOD) ]; then
echo "Warning: 'make modules_install' requires $DEPMOD. Please
install it." >&2
echo "This is probably in the kmod package." >&2
or similar. Does that work for you?
Linus
On Mon, Dec 28, 2020 at 12:59 PM Linus Torvalds
<[email protected]> wrote:
>
> On Mon, Dec 28, 2020 at 7:51 AM Guenter Roeck <[email protected]> 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
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 [email protected]
34 [email protected]
34 [email protected]
32 [email protected]
31 [email protected]
19 [email protected]
19 [email protected]
16 [email protected]
15 [email protected]
15 [email protected]
Top ten commiters:
158 [email protected]
88 [email protected]
59 [email protected]
57 [email protected]
50 [email protected]
37 [email protected]
36 [email protected]
33 [email protected]
30 [email protected]
30 [email protected]
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 [email protected]
20 [email protected]
19 [email protected]
16 [email protected]
15 [email protected]
15 [email protected]
14 [email protected]
14 [email protected]
13 [email protected]
12 [email protected]
Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).
Top ten commiters:
121 [email protected]
32 [email protected]
28 [email protected]
23 [email protected]
23 [email protected]
22 [email protected]
21 [email protected]
19 [email protected]
18 [email protected]
18 [email protected]
Those commits by me are from Andrew's mmotm tree.
--
Cheers,
Stephen Rothwell
Hi!
> >
> > > $ dpkg -L kmod | grep bin | grep depmod
> > > /sbin/depmod
> > >
> > > $ which depmod
> > > [ empty ]
> > >
> > > $ echo $PATH
> > > /opt/proxychains-ng/bin:/home/dileks/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
>
> Ok, I think this is a broken setup that has a separate /sbin but does
> not have it in the PATH.
That's how it is supposed to work, AFAICT. It is so on Debian here,
for example.
/sbin is for management commands, why would I have it in PATH when
running as normal user?
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
On Fri, Jan 1, 2021 at 5:14 PM Pavel Machek <[email protected]> wrote:
>
> Hi!
> > >
> > > > $ dpkg -L kmod | grep bin | grep depmod
> > > > /sbin/depmod
> > > >
> > > > $ which depmod
> > > > [ empty ]
> > > >
> > > > $ echo $PATH
> > > > /opt/proxychains-ng/bin:/home/dileks/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
> >
> > Ok, I think this is a broken setup that has a separate /sbin but does
> > not have it in the PATH.
>
> That's how it is supposed to work, AFAICT. It is so on Debian here,
> for example.
>
> /sbin is for management commands, why would I have it in PATH when
> running as normal user?
>
I am here on Debian/testing AMD64 and waiting for feedback [2].
For now I have applied the diff from [1].
- Sedat -
[1] https://marc.info/?l=linux-kbuild&m=160919738006768&w=2
[2] https://marc.info/?l=linux-kernel&m=160919729606750&w=2
On Fri, Jan 1, 2021 at 7:55 PM Sedat Dilek <[email protected]> wrote:
>
> On Fri, Jan 1, 2021 at 5:14 PM Pavel Machek <[email protected]> wrote:
> >
> > Hi!
> > > >
> > > > > $ dpkg -L kmod | grep bin | grep depmod
> > > > > /sbin/depmod
> > > > >
> > > > > $ which depmod
> > > > > [ empty ]
> > > > >
> > > > > $ echo $PATH
> > > > > /opt/proxychains-ng/bin:/home/dileks/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
> > >
> > > Ok, I think this is a broken setup that has a separate /sbin but does
> > > not have it in the PATH.
> >
> > That's how it is supposed to work, AFAICT. It is so on Debian here,
> > for example.
> >
> > /sbin is for management commands, why would I have it in PATH when
> > running as normal user?
> >
>
> I am here on Debian/testing AMD64 and waiting for feedback [2].
>
> For now I have applied the diff from [1].
>
> - Sedat -
>
> [1] https://marc.info/?l=linux-kbuild&m=160919738006768&w=2
> [2] https://marc.info/?l=linux-kernel&m=160919729606750&w=2
Fixed upstream, see "depmod: handle the case of /sbin/depmod without
/sbin in PATH".
- Sedat -
[1] https://git.kernel.org/linus/cedd1862be7e666be87ec824dabc6a2b05618f36
On Sat, Jan 2, 2021 at 3:55 AM Sedat Dilek <[email protected]> wrote:
>
> On Fri, Jan 1, 2021 at 5:14 PM Pavel Machek <[email protected]> wrote:
> >
> > Hi!
> > > >
> > > > > $ dpkg -L kmod | grep bin | grep depmod
> > > > > /sbin/depmod
> > > > >
> > > > > $ which depmod
> > > > > [ empty ]
> > > > >
> > > > > $ echo $PATH
> > > > > /opt/proxychains-ng/bin:/home/dileks/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
> > >
> > > Ok, I think this is a broken setup that has a separate /sbin but does
> > > not have it in the PATH.
> >
> > That's how it is supposed to work, AFAICT. It is so on Debian here,
> > for example.
> >
> > /sbin is for management commands, why would I have it in PATH when
> > running as normal user?
> >
>
> I am here on Debian/testing AMD64 and waiting for feedback [2].
>
> For now I have applied the diff from [1].
>
> - Sedat -
>
> [1] https://marc.info/?l=linux-kbuild&m=160919738006768&w=2
> [2] https://marc.info/?l=linux-kernel&m=160919729606750&w=2
PATH for the root on Debian is
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
depmod is used from 'make module_install'.
For the native module installation to the host machine,
module_install is run after 'su -'
or 'sudo', which successfully finds depmod in /sbin.
I also tested 'make deb-pkg' with/without
rootless builds. It also successfully found depmod
in /sbin, presumably dpkg tools automatically tweak
PATH env variable.
Maybe, the problem is when we run 'make modules_install'
for cross compilation, which we do not necessarily
require the root permission.
Users can still adjust PATH in ~/.profile, but
somebody may think breaking the legacy behavior
is annoying.
So, after some consideration, the workaround by Linus
looks good to me.
--
Best Regards
Masahiro Yamada
On Sat, Jan 2, 2021 at 8:52 AM Masahiro Yamada <[email protected]> wrote:
>
> On Sat, Jan 2, 2021 at 3:55 AM Sedat Dilek <[email protected]> wrote:
> >
> > On Fri, Jan 1, 2021 at 5:14 PM Pavel Machek <[email protected]> wrote:
> > >
> > > Hi!
> > > > >
> > > > > > $ dpkg -L kmod | grep bin | grep depmod
> > > > > > /sbin/depmod
> > > > > >
> > > > > > $ which depmod
> > > > > > [ empty ]
> > > > > >
> > > > > > $ echo $PATH
> > > > > > /opt/proxychains-ng/bin:/home/dileks/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
> > > >
> > > > Ok, I think this is a broken setup that has a separate /sbin but does
> > > > not have it in the PATH.
> > >
> > > That's how it is supposed to work, AFAICT. It is so on Debian here,
> > > for example.
> > >
> > > /sbin is for management commands, why would I have it in PATH when
> > > running as normal user?
> > >
> >
> > I am here on Debian/testing AMD64 and waiting for feedback [2].
> >
> > For now I have applied the diff from [1].
> >
> > - Sedat -
> >
> > [1] https://marc.info/?l=linux-kbuild&m=160919738006768&w=2
> > [2] https://marc.info/?l=linux-kernel&m=160919729606750&w=2
>
>
> PATH for the root on Debian is
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
>
>
> depmod is used from 'make module_install'.
>
> For the native module installation to the host machine,
> module_install is run after 'su -'
> or 'sudo', which successfully finds depmod in /sbin.
>
>
> I also tested 'make deb-pkg' with/without
> rootless builds. It also successfully found depmod
> in /sbin, presumably dpkg tools automatically tweak
> PATH env variable.
>
>
> Maybe, the problem is when we run 'make modules_install'
> for cross compilation, which we do not necessarily
> require the root permission.
>
> Users can still adjust PATH in ~/.profile, but
> somebody may think breaking the legacy behavior
> is annoying.
>
> So, after some consideration, the workaround by Linus
> looks good to me.
>
Happy new 2020+1,
Thanks for your feedback Masahiro.
Building a Linux kernel on Debian is mostly done using fakeroot binary
(so I do) - so in the user's (PATH) environment.
I cannot speak for the case of cross-compilation as I never used it in
the last years.
We are in the transition "Xmas -> New year -> Weekend" so a lot of
user's of Debian system will not test and hit the problem.
To be honest I wondered why there were no more reports on this.
With upcoming Sunday/Monday we will have Linux v5.11-rc2 released
which has an elegant solution by restoring common legacy behaviour by
putting "sbin" to the end of "PATH" (search).
Regards,
- Sedat -
On Sat, 2021-01-02 at 10:13 +0100, Sedat Dilek wrote:
[...]
> To be honest I wondered why there were no more reports on this.
Perhaps I'm not the only one who has /sbin and /usr/sbin in the
$PATH of normal accounts too (and idk what's the default
behaviour of distributions is - my .bashrc "fixes" the
$PATH).
MfG,
Bernd
--
Bernd Petrovitsch Email : [email protected]
There is no cloud, just other people computers. - FSFE
LUGA : http://www.luga.at
On Sat, Jan 2, 2021 at 12:05 PM Bernd Petrovitsch
<[email protected]> wrote:
>
> On Sat, 2021-01-02 at 10:13 +0100, Sedat Dilek wrote:
> [...]
> > To be honest I wondered why there were no more reports on this.
>
> Perhaps I'm not the only one who has /sbin and /usr/sbin in the
> $PATH of normal accounts too (and idk what's the default
> behaviour of distributions is - my .bashrc "fixes" the
> $PATH).
>
I was thinking more towards maxim/dictum:
"Never break userspace!" or "It worked before but now it is not."
Think of automated kernel build and test setups based on Debian.
Debian/testing AMD64 has...
[ /etc/login.defs ]
# *REQUIRED* The default PATH settings, for superuser and normal users.
#
# (they are minimal, add the rest in the shell startup files)
ENV_SUPATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
IMHO users should not need to fix their environment.
( The discussion is a bit obsolete as we now have a fix. )
- Sedat -
On Sat, 2021-01-02 at 12:26 +0100, Sedat Dilek wrote:
> On Sat, Jan 2, 2021 at 12:05 PM Bernd Petrovitsch
> <[email protected]> wrote:
> > On Sat, 2021-01-02 at 10:13 +0100, Sedat Dilek wrote:
> > [...]
> > > To be honest I wondered why there were no more reports on this.
> >
> > Perhaps I'm not the only one who has /sbin and /usr/sbin in the
> > $PATH of normal accounts too (and idk what's the default
> > behaviour of distributions is - my .bashrc "fixes" the
> > $PATH).
>
> I was thinking more towards maxim/dictum:
> "Never break userspace!" or "It worked before but now it is not."
But if userspace changed (and that could be a change by the
distribution which the user isn't aware) than ...
> Think of automated kernel build and test setups based on Debian.
>
> Debian/testing AMD64 has...
OK.
> [ /etc/login.defs ]
>
> # *REQUIRED* The default PATH settings, for superuser and normal users.
> #
> # (they are minimal, add the rest in the shell startup files)
> ENV_SUPATH
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
Well, "minimal" and /usr/local/games:/usr/games ...
/usr/local/* is the next ...
Yes, it's hard for the distribution to "guess" the local admins
habits and policies ....
> IMHO users should not need to fix their environment.
> ( The discussion is a bit obsolete as we now have a fix. )
FWIW, I have no (and don't see any) problems simply appending
/sbin:/usr/sbin to the $PATH in/for the kernel's scripts.
MfG,
Bernd
--
Bernd Petrovitsch Email : [email protected]
There is no cloud, just other people computers. - FSFE
LUGA : http://www.luga.at
> > IMHO users should not need to fix their environment.
> > ( The discussion is a bit obsolete as we now have a fix. )
>
> FWIW, I have no (and don't see any) problems simply appending
> /sbin:/usr/sbin to the $PATH in/for the kernel's scripts.
>
Another workaround is to pass DEPMOD=/path/to/depmod in the kernel-build script.
Again, such custom workarounds should not be necessary.
- Sedat -
On Sat, Jan 2, 2021 at 4:51 PM Masahiro Yamada <[email protected]> wrote:
>
> On Sat, Jan 2, 2021 at 3:55 AM Sedat Dilek <[email protected]> wrote:
> >
> > On Fri, Jan 1, 2021 at 5:14 PM Pavel Machek <[email protected]> wrote:
> > >
> > > Hi!
> > > > >
> > > > > > $ dpkg -L kmod | grep bin | grep depmod
> > > > > > /sbin/depmod
> > > > > >
> > > > > > $ which depmod
> > > > > > [ empty ]
> > > > > >
> > > > > > $ echo $PATH
> > > > > > /opt/proxychains-ng/bin:/home/dileks/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
> > > >
> > > > Ok, I think this is a broken setup that has a separate /sbin but does
> > > > not have it in the PATH.
> > >
> > > That's how it is supposed to work, AFAICT. It is so on Debian here,
> > > for example.
> > >
> > > /sbin is for management commands, why would I have it in PATH when
> > > running as normal user?
> > >
> >
> > I am here on Debian/testing AMD64 and waiting for feedback [2].
> >
> > For now I have applied the diff from [1].
> >
> > - Sedat -
> >
> > [1] https://marc.info/?l=linux-kbuild&m=160919738006768&w=2
> > [2] https://marc.info/?l=linux-kernel&m=160919729606750&w=2
>
>
> PATH for the root on Debian is
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
>
>
> depmod is used from 'make module_install'.
>
> For the native module installation to the host machine,
> module_install is run after 'su -'
> or 'sudo', which successfully finds depmod in /sbin.
>
>
> I also tested 'make deb-pkg' with/without
> rootless builds. It also successfully found depmod
> in /sbin, presumably dpkg tools automatically tweak
> PATH env variable.
I retract this hunk about deb-pkg.
(My test environment in the docker was wrong.)
I tested deb-pkg builds in the full debian installation
in KVM, and confirmed deb-pkg failed to build.
So, 'make deb-pkg' would have broken without
cedd1862be7e6
--
Best Regards
Masahiro Yamada
> PATH for the root on Debian is
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
>
Note that /sbin is now just a symlink to /usr/sbin on Debian since 10 (Buster) as per FHS[1][2].
[1] https://wiki.linuxfoundation.org/lsb/fhs
[2] https://arstechnica.com/information-technology/2019/09/debian-10-playing-catch-up-with-the-rest-of-the-linux-world-thats-a-good-thing/
--
- Ilkka
From: Bernd Petrovitsch
> Sent: 02 January 2021 11:05
>
> On Sat, 2021-01-02 at 10:13 +0100, Sedat Dilek wrote:
> [...]
> > To be honest I wondered why there were no more reports on this.
>
> Perhaps I'm not the only one who has /sbin and /usr/sbin in the
> $PATH of normal accounts too (and idk what's the default
> behaviour of distributions is - my .bashrc "fixes" the
> $PATH).
Yep, I've pretty much always added sbin to my non-root $PATH
for most of the last 30+ years.
Too much stuff that a 'techie' wants to run non-root is in there.
/usr/bin, /usr/sbin and /usr/lib should have got removed once
disks got large enough that the boot disk (aka /) didn't overflow
required some system files be moved into the 'user' disk.
(The last disks that weren't really big enough were the 600MB ones.
The user's home directories could go into /usr where they belong.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
From: Ilkka Prusi
> Sent: 02 January 2021 23:27
>
> > PATH for the root on Debian is
> > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> >
>
> Note that /sbin is now just a symlink to /usr/sbin on Debian since 10 (Buster) as per FHS[1][2].
>
> [1] https://wiki.linuxfoundation.org/lsb/fhs
> [2] https://arstechnica.com/information-technology/2019/09/debian-10-playing-catch-up-with-the-rest-
> of-the-linux-world-thats-a-good-thing/
Which is exactly 100% backwards :-)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
On Sun, Jan 03, 2021 at 05:45:16PM +0000, David Laight wrote:
> From: Ilkka Prusi
> > Note that /sbin is now just a symlink to /usr/sbin on Debian since 10 (Buster) as per FHS[1][2].
> >
> > [1] https://wiki.linuxfoundation.org/lsb/fhs
> > [2] https://arstechnica.com/information-technology/2019/09/debian-10-playing-catch-up-with-the-rest-
> > of-the-linux-world-thats-a-good-thing/
>
> Which is exactly 100% backwards :-)
I agree with you that, if all, it's /usr/sbin which should be a symlink,
to reduce typing and to get rid of a vestige of _The_ Unix machine having
/bin spill to a disk that used to have user homes.
But, /sbin is a symlink on only _some_ Debian installations. There's
currently a discussion whether to go deeper into this scheme, abandon it
or do nothing.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄⠀⠀⠀⠀ `----