Re: Linux 5.11-rc1

Re: Linux 5.11-rc1

[Sedat Dilek]

[ 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

Re: Linux 5.11-rc1

[Sedat Dilek]

On Mon, Dec 28, 2020 at 8:30 AM Sedat Dilek <sedat.dilek@gmail.com> 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 -

Re: Linux 5.11-rc1

[Sedat Dilek]

On Mon, Dec 28, 2020 at 9:04 AM Sedat Dilek <sedat.dilek@gmail.com> wrote:
>
> On Mon, Dec 28, 2020 at 8:30 AM Sedat Dilek <sedat.dilek@gmail.com> 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 -

Re: Linux 5.11-rc1

[Linus Torvalds]

On Mon, Dec 28, 2020 at 12:04 AM Sedat Dilek <sedat.dilek@gmail.com> 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

Re: Linux 5.11-rc1

[Sedat Dilek]

On Mon, Dec 28, 2020 at 8:40 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, Dec 28, 2020 at 12:04 AM Sedat Dilek <sedat.dilek@gmail.com> 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 -

Re: Linux 5.11-rc1

[Pavel Machek]

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Linux 5.11-rc1

[Sedat Dilek]

On Fri, Jan 1, 2021 at 5:14 PM Pavel Machek <pavel@ucw.cz> 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

Re: Linux 5.11-rc1

[Sedat Dilek]

On Fri, Jan 1, 2021 at 7:55 PM Sedat Dilek <sedat.dilek@gmail.com> wrote:
>
> On Fri, Jan 1, 2021 at 5:14 PM Pavel Machek <pavel@ucw.cz> 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

Re: Linux 5.11-rc1

[Masahiro Yamada]

On Sat, Jan 2, 2021 at 3:55 AM Sedat Dilek <sedat.dilek@gmail.com> wrote:
>
> On Fri, Jan 1, 2021 at 5:14 PM Pavel Machek <pavel@ucw.cz> 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

Re: Linux 5.11-rc1

[Sedat Dilek]

On Sat, Jan 2, 2021 at 8:52 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Sat, Jan 2, 2021 at 3:55 AM Sedat Dilek <sedat.dilek@gmail.com> wrote:
> >
> > On Fri, Jan 1, 2021 at 5:14 PM Pavel Machek <pavel@ucw.cz> 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 -

Re: Linux 5.11-rc1

[Bernd Petrovitsch]

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 : bernd@petrovitsch.priv.at
There is no cloud, just other people computers. - FSFE
                     LUGA : http://www.luga.at

Re: Linux 5.11-rc1

[Sedat Dilek]

On Sat, Jan 2, 2021 at 12:05 PM Bernd Petrovitsch
<bernd@petrovitsch.priv.at> 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 -

Re: Linux 5.11-rc1

[Bernd Petrovitsch]

On Sat, 2021-01-02 at 12:26 +0100, Sedat Dilek wrote:
> On Sat, Jan 2, 2021 at 12:05 PM Bernd Petrovitsch
> <bernd@petrovitsch.priv.at> 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 : bernd@petrovitsch.priv.at
There is no cloud, just other people computers. - FSFE
                     LUGA : http://www.luga.at

Re: Linux 5.11-rc1

[Sedat Dilek]

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

RE: Linux 5.11-rc1

[David Laight]

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)

Re: Linux 5.11-rc1

[Masahiro Yamada]

On Sat, Jan 2, 2021 at 4:51 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Sat, Jan 2, 2021 at 3:55 AM Sedat Dilek <sedat.dilek@gmail.com> wrote:
> >
> > On Fri, Jan 1, 2021 at 5:14 PM Pavel Machek <pavel@ucw.cz> 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

Re: Linux 5.11-rc1

[Sedat Dilek]

[ 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/20201219063711.3526947-1-natechancellor@gmail.com/
[3] https://github.com/ClangBuiltLinux/linux/issues/1192

Re: Linux 5.11-rc1

[Linus Torvalds]

On Mon, Dec 28, 2020 at 7:26 AM Sedat Dilek <sedat.dilek@gmail.com> 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

Re: Linux 5.11-rc1

[Sedat Dilek]

On Mon, Dec 28, 2020 at 8:45 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, Dec 28, 2020 at 7:26 AM Sedat Dilek <sedat.dilek@gmail.com> 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

Re: Linux 5.11-rc1

[Ilkka Prusi]

> 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

RE: Linux 5.11-rc1

[David Laight]

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)

Re: Linux 5.11-rc1

[Adam Borowski]

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
⠈⠳⣄⠀⠀⠀⠀ `----

Linux 5.11-rc1

[Linus Torvalds]

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

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

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

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

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

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

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

Please go kick the tires,

                Linus

---

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

Alex Williamson (1):
    VFIO updates

Alexandre Belloni (1):
    RTC updates

Andreas Gruenbacher (1):
    gfs2 updates

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

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

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

Benson Leung (1):
    chrome platform updates

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

Bjorn Helgaas (2):
    PCI updates
    PCI fixes

Boris Brezillon (1):
    i3c updates

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

Casey Schaufler (2):
    smack updates
    smack fix

Catalin Marinas (2):
    arm64 updates
    more arm64 updates

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

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

Chuck Lever (1):
    nfsd updates

Corey Minyard (1):
    IPMI updates

Dan Williams (1):
    libnvdimm updates

Daniel Lezcano (2):
    thermal updates
    thermal fixlet

Daniel Vetter (1):
    more drm updates

Darrick Wong (1):
    xfs updates

Dave Airlie (2):
    drm updates
    drm fixes

David Kleikamp (1):
    jfs updates

David Sterba (1):
    btrfs updates

David Teigland (1):
    dlm updates

Dmitry Torokhov (1):
    input updates

Dominik Brodowski (1):
    pcmcia updates

Dominique Martinet (1):
    9p update

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

Eric Biggers (2):
    fscrypt updates
    fsverity updates

Gao Xiang (1):
    erofs updates

Geert Uytterhoeven (1):
    m68k updates

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

Greg Ungerer (1):
    m68knommu updates

Guenter Roeck (2):
    hwmon updates
    another hwmon update

Gustavo A (1):
    fallthrough fixes

Hans de Goede (1):
    x86 platform driver updates

Heiko Carstens (2):
    s390 updates
    more s390 updates

Helge Deller (1):
    parisc updates

Herbert Xu (2):
    crypto updates
    crypto fixes

Ilya Dryomov (1):
    ceph updates

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

Jaegeuk Kim (1):
    f2fs updates

Jakub Kicinski (2):
    networking updates
    networking fixes

James Bottomley (1):
    SCSI updates

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

Jason Gunthorpe (1):
    rdma updates

Jassi Brar (1):
    mailbox updates

Jeff Layton (1):
    file locking fixes

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

Jessica Yu (1):
    modules updates

Jiri Kosina (1):
    HID updates

Jon Mason (1):
    NTB fixes

Jonathan Corbet (2):
    documentation updates
    documentation fixes

Juergen Gross (2):
    xen updates
    more xen updates

Julia Lawall (1):
    coccinelle updates

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

Konrad Rzeszutek Wilk (1):
    swiotlb update

Lee Jones (2):
    MFD updates
    backlight update

Linus Walleij (2):
    pin control updates
    GPIO updates

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

Masahiro Yamada (2):
    Kbuild updates
    Kconfig updates

Mauro Carvalho Chehab (1):
    media updates

Michael Ellerman (2):
    powerpc updates
    powerpc fixes

Michael Tsirkin (1):
    virtio updates

Michal Simek (1):
    microblaze updates

Miguel Ojeda (1):
    auxdisplay updates

Mike Marshall (1):
    orangefs update

Mike Rapoport (1):
    memblock updates

Mike Snitzer (2):
    MD regression reverts
    device mapper updates

Miklos Szeredi (2):
    fuse updates
    overlayfs updates

Mimi Zohar (1):
    integrity subsystem updates

Miquel Raynal (1):
    MTD updates

Namjae Jeon (1):
    exfat update

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

Paolo Bonzini (1):
    KVM updates

Paul Moore (2):
    audit updates
    selinux updates

Pavel Machek (1):
    LED updates

Petr Mladek (1):
    printk updates

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

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

Rob Herring (2):
    devicetree updates
    devicetree fixes

Russell King (1):
    ARM updates

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

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

Stafford Horne (1):
    OpenRISC updates

Stephen Boyd (1):
    clk updates

Steve French (2):
    cifs updates
    cifs fixes

Steven Rostedt (2):
    tracing updates
    ktest updates

Takashi Iwai (2):
    sound updates
    sound fixes

Ted Ts'o (1):
    ext4 updates

Tetsuo Handa (1):
    tomoyo updates

Thierry Reding (1):
    pwm updates

Thomas Bogendoerfer (1):
    MIPS updates

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

Trond Myklebust (1):
    NFS client updates

Ulf Hansson (1):
    MMC updates

Vinod Koul (1):
    dmaengine updates

Wei Liu (1):
    Hyper-V updates

Will Deacon (1):
    IOMMU updates

Wim Van Sebroeck (1):
    watchdog updates

Wolfram Sang (1):
    i2c updates

Re: Linux 5.11-rc1

[Guenter Roeck]

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

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

Build errors:

arm64:allmodconfig:

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

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

ia64:defconfig:

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

and various related warnings.

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

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

qemu boot tests:

arm:raspi2:

Hangs during boot.

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

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

parisc:

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

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

More details are in responses to the offending patches.

Guenter

Re: Linux 5.11-rc1

[Linus Torvalds]

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

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

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

Ahh. Does it just need a

 EXPORT_SYMBOL_GPL(irq_check_status_bit);

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

Thomas?

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

Ok, I won't worry about that one.

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

Same.

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

Looks like Kalesh is looking at it.

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

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

                 Linus

Re: Linux 5.11-rc1

[Kalesh Singh]

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

Hi Linus,

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

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

Thanks,
Kalesh

>
>                  Linus

Re: Linux 5.11-rc1

[Guenter Roeck]

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

[ ... ]

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

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

Guenter