From: Eric W. Biederman <hidden> Date: 2021-08-17 16:48:36
Matthew Wilcox [off-list ref] writes:
On Fri, Aug 13, 2021 at 05:49:19PM -0700, Andy Lutomirski wrote:
quoted
[0] we have mandatory locks, too. Sigh.
I'd love to remove that. Perhaps we could try persuading more of the
distros to disable the CONFIG option first.
Yes. The support is disabled in RHEL8.
Does anyone know the appropriate people to talk to encourage other
distro's to encourage them to disable the CONFIG_MANDATORY_FILE_LOCKING?
Either that or we can wait until the code bit-rots, but distro's
disabling and removing a feature on their own is the more responsible
path.
Given how many hoops need to be jumped through to use mandatory file
locking once it is enabled, and the fact it has never worked in
containers makes me suspect there are no more users.
Eric
From: David Hildenbrand <hidden> Date: 2021-08-17 16:50:29
On 17.08.21 18:48, Eric W. Biederman wrote:
Matthew Wilcox [off-list ref] writes:
quoted
On Fri, Aug 13, 2021 at 05:49:19PM -0700, Andy Lutomirski wrote:
quoted
[0] we have mandatory locks, too. Sigh.
I'd love to remove that. Perhaps we could try persuading more of the
distros to disable the CONFIG option first.
Yes. The support is disabled in RHEL8.
kernel-ark also seems to not set it for Fedora and ARK
redhat/configs/common/generic/CONFIG_MANDATORY_FILE_LOCKING:#
CONFIG_MANDATORY_FILE_LOCKING is not set
--
Thanks,
David / dhildenb
On Tue, Aug 17, 2021 at 6:49 PM Eric W. Biederman [off-list ref] wrote:
Matthew Wilcox [off-list ref] writes:
quoted
On Fri, Aug 13, 2021 at 05:49:19PM -0700, Andy Lutomirski wrote:
quoted
[0] we have mandatory locks, too. Sigh.
I'd love to remove that. Perhaps we could try persuading more of the
distros to disable the CONFIG option first.
Yes. The support is disabled in RHEL8.
If it helps, it seems to be enabled on the just released debian stable:
$ grep CONFIG_MANDATORY_FILE_LOCKING /boot/config-5.10.0-8-amd64
CONFIG_MANDATORY_FILE_LOCKING=y
Also the new 5.13 kernel in experimental has it too:
$ grep CONFIG_MANDATORY_FILE_LOCKING /boot/config-5.13.0-trunk-amd64
CONFIG_MANDATORY_FILE_LOCKING=y
From: Jeff Layton <jlayton@kernel.org> Date: 2021-08-19 18:39:44
On Tue, 2021-08-17 at 11:48 -0500, Eric W. Biederman wrote:
Matthew Wilcox [off-list ref] writes:
quoted
On Fri, Aug 13, 2021 at 05:49:19PM -0700, Andy Lutomirski wrote:
quoted
[0] we have mandatory locks, too. Sigh.
I'd love to remove that. Perhaps we could try persuading more of the
distros to disable the CONFIG option first.
Yes. The support is disabled in RHEL8.
Does anyone know the appropriate people to talk to encourage other
distro's to encourage them to disable the CONFIG_MANDATORY_FILE_LOCKING?
Either that or we can wait until the code bit-rots, but distro's
disabling and removing a feature on their own is the more responsible
path.
Given how many hoops need to be jumped through to use mandatory file
locking once it is enabled, and the fact it has never worked in
containers makes me suspect there are no more users.
I'm all for ripping it out too. It's an insane interface anyway.
I've not heard a single complaint about this being turned off in
fedora/rhel or any other distro that has this disabled.
Cheers,
--
Jeff Layton [off-list ref]
On Thu, Aug 19, 2021 at 11:39 AM Jeff Layton [off-list ref] wrote:
I'm all for ripping it out too. It's an insane interface anyway.
I've not heard a single complaint about this being turned off in
fedora/rhel or any other distro that has this disabled.
I'd love to remove it, we could absolutely test it. The fact that
several major distros have it disabled makes me think it's fine.
But as always, it would be good to check Android.
The desktop distros tend to have the same tools and programs, so if
Fedora and RHEL haven't needed it for years, then it's likely stale in
Debian too (despite being enabled).
But Android tends to be very different. Does anybody know?
Linus
From: Jeff Layton <jlayton@kernel.org> Date: 2021-08-19 19:18:24
On Wed, 2021-08-18 at 11:34 +0200, Rodrigo Campos wrote:
On Tue, Aug 17, 2021 at 6:49 PM Eric W. Biederman [off-list ref] wrote:
quoted
Matthew Wilcox [off-list ref] writes:
quoted
On Fri, Aug 13, 2021 at 05:49:19PM -0700, Andy Lutomirski wrote:
quoted
[0] we have mandatory locks, too. Sigh.
I'd love to remove that. Perhaps we could try persuading more of the
distros to disable the CONFIG option first.
Yes. The support is disabled in RHEL8.
If it helps, it seems to be enabled on the just released debian stable:
$ grep CONFIG_MANDATORY_FILE_LOCKING /boot/config-5.10.0-8-amd64
CONFIG_MANDATORY_FILE_LOCKING=y
Also the new 5.13 kernel in experimental has it too:
$ grep CONFIG_MANDATORY_FILE_LOCKING /boot/config-5.13.0-trunk-amd64
CONFIG_MANDATORY_FILE_LOCKING=y
A pity. It would have been nice if they had turned it off a while ago. I
guess I should have done more outreach at the time. Sigh...
In any case, I'm still inclined toward just ripping it out at this
point. It's hard to believe that anyone really uses it.
--
Jeff Layton [off-list ref]
From: Eric Biggers <ebiggers@kernel.org> Date: 2021-08-19 19:55:13
On Thu, Aug 19, 2021 at 12:15:08PM -0700, Linus Torvalds wrote:
On Thu, Aug 19, 2021 at 11:39 AM Jeff Layton [off-list ref] wrote:
quoted
I'm all for ripping it out too. It's an insane interface anyway.
I've not heard a single complaint about this being turned off in
fedora/rhel or any other distro that has this disabled.
I'd love to remove it, we could absolutely test it. The fact that
several major distros have it disabled makes me think it's fine.
But as always, it would be good to check Android.
The desktop distros tend to have the same tools and programs, so if
Fedora and RHEL haven't needed it for years, then it's likely stale in
Debian too (despite being enabled).
But Android tends to be very different. Does anybody know?
As far as I know, Android never uses mandatory file locking. While
CONFIG_MANDATORY_LOCKING=y is typically set (as it's "default y" upstream),
I can't find anywhere in the Android source tree that uses the "mand" mount
option, let alone anything actually using mandatory locks. (I'm assuming that
Documentation/filesystems/mandatory-locking.rst is up-to-date regarding what
userspace actually has to do to use it.)
- Eric
On Thu, Aug 19, 2021 at 03:18:15PM -0400, Jeff Layton wrote:
On Wed, 2021-08-18 at 11:34 +0200, Rodrigo Campos wrote:
quoted
On Tue, Aug 17, 2021 at 6:49 PM Eric W. Biederman [off-list ref] wrote:
quoted
Matthew Wilcox [off-list ref] writes:
quoted
On Fri, Aug 13, 2021 at 05:49:19PM -0700, Andy Lutomirski wrote:
quoted
[0] we have mandatory locks, too. Sigh.
I'd love to remove that. Perhaps we could try persuading more of the
distros to disable the CONFIG option first.
Yes. The support is disabled in RHEL8.
If it helps, it seems to be enabled on the just released debian stable:
$ grep CONFIG_MANDATORY_FILE_LOCKING /boot/config-5.10.0-8-amd64
CONFIG_MANDATORY_FILE_LOCKING=y
Also the new 5.13 kernel in experimental has it too:
$ grep CONFIG_MANDATORY_FILE_LOCKING /boot/config-5.13.0-trunk-amd64
CONFIG_MANDATORY_FILE_LOCKING=y
A pity. It would have been nice if they had turned it off a while ago. I
guess I should have done more outreach at the time. Sigh...
Would it be acceptable to add a warning when MS_MANDLOCK is passed to
mount() and backport this to stable kernels in order to get reports
of any such use in a reasonably short time ? Anyway it sounds
important to at least warn about deprecation.
Willy
From: Jeff Layton <jlayton@kernel.org> Date: 2021-08-19 20:18:47
On Thu, 2021-08-19 at 12:15 -0700, Linus Torvalds wrote:
On Thu, Aug 19, 2021 at 11:39 AM Jeff Layton [off-list ref] wrote:
quoted
I'm all for ripping it out too. It's an insane interface anyway.
I've not heard a single complaint about this being turned off in
fedora/rhel or any other distro that has this disabled.
I'd love to remove it, we could absolutely test it. The fact that
several major distros have it disabled makes me think it's fine.
But as always, it would be good to check Android.
The desktop distros tend to have the same tools and programs, so if
Fedora and RHEL haven't needed it for years, then it's likely stale in
Debian too (despite being enabled).
But Android tends to be very different. Does anybody know?
Now that I think about it a little more, I actually did get one
complaint a few years ago:
Someone had upgraded from an earlier distro that supported the -o mand
mount option to a later one that had disabled it, and they had an (old)
fstab entry that specified it. They didn't actually use mandatory
locking and weren't sure why the option was set, so they removed it and
moved on.
I would feel a lot better about it if we had gotten Debian to turn it
off several years ago too, but I agree it's unlikely anyone uses this
and the risk of removing it is low.
I've spun up a patch to just rip it out. I'll do a bit of testing with
it tomorrow and then send it out.
Cheers,
--
Jeff Layton [off-list ref]
On Thu, Aug 19, 2021 at 1:18 PM Jeff Layton [off-list ref] wrote:
Now that I think about it a little more, I actually did get one
complaint a few years ago:
Someone had upgraded from an earlier distro that supported the -o mand
mount option to a later one that had disabled it, and they had an (old)
fstab entry that specified it.
Hmm. We might be able to turn the "return -EINVAL" into just a warning.
Yes, yes, currently if you turn off CONFIG_MANDATORY_FILE_LOCKING, we
already do that
VFS: "mand" mount option not supported
warning print, but then we fail the mount.
If CONFIG_MANDATORY_FILE_LOCKING goes away entirely, it might make
sense to turn that warning into something bigger, but then let the
mount continue - since now that "mand" flag would be purely a legacy
thing.
And yes, if we do that, we'd want the warning to be a big ugly thing,
just to make people very aware of it happening. Right now it's a
one-liner that is easy to miss, and the "oh, the mount failed" is the
thing that hopefully informs people about the fact that they need to
enable CONFIG_MANDATORY_FILE_LOCKING.
The logic being that if you can no longer enable mandatory locking in
the kernel, the current hard failure seems overly aggressive (and
might cause boot failures and inability to fix/report things when it
possibly keeps you from using the system at all).
Linus
From: Jeff Layton <jlayton@kernel.org> Date: 2021-08-19 21:43:20
On Thu, 2021-08-19 at 13:31 -0700, Linus Torvalds wrote:
On Thu, Aug 19, 2021 at 1:18 PM Jeff Layton [off-list ref] wrote:
quoted
Now that I think about it a little more, I actually did get one
complaint a few years ago:
Someone had upgraded from an earlier distro that supported the -o mand
mount option to a later one that had disabled it, and they had an (old)
fstab entry that specified it.
Hmm. We might be able to turn the "return -EINVAL" into just a warning.
Yes, yes, currently if you turn off CONFIG_MANDATORY_FILE_LOCKING, we
already do that
VFS: "mand" mount option not supported
warning print, but then we fail the mount.
If CONFIG_MANDATORY_FILE_LOCKING goes away entirely, it might make
sense to turn that warning into something bigger, but then let the
mount continue - since now that "mand" flag would be purely a legacy
thing.
And yes, if we do that, we'd want the warning to be a big ugly thing,
just to make people very aware of it happening. Right now it's a
one-liner that is easy to miss, and the "oh, the mount failed" is the
thing that hopefully informs people about the fact that they need to
enable CONFIG_MANDATORY_FILE_LOCKING.
The logic being that if you can no longer enable mandatory locking in
the kernel, the current hard failure seems overly aggressive (and
might cause boot failures and inability to fix/report things when it
possibly keeps you from using the system at all).
What sort of big, ugly warning did you have in mind?
I'm fine with that general approach though and will plan to roll that
change into the patch I'm testing.
Thanks,
--
Jeff Layton [off-list ref]
On Thu, Aug 19, 2021 at 2:43 PM Jeff Layton [off-list ref] wrote:
What sort of big, ugly warning did you have in mind?
I originally thought WARN_ON_ONCE() just to get the distro automatic
error handling involved, but it would probably be a big problem for
the people who end up having panic-on-warn or something.
So probably just a "make it a big box" thing that stands out, kind of
what lockdep etc does with
pr_warn("======...====\n");
around the messages..
I don't know if distros have some pattern we could use that would end
up being something that gets reported to the user?
Linus
From: Matthew Wilcox <willy@infradead.org> Date: 2021-08-20 02:14:10
On Thu, Aug 19, 2021 at 01:31:35PM -0700, Linus Torvalds wrote:
Yes, yes, currently if you turn off CONFIG_MANDATORY_FILE_LOCKING, we
already do that
VFS: "mand" mount option not supported
warning print, but then we fail the mount.
If CONFIG_MANDATORY_FILE_LOCKING goes away entirely, it might make
sense to turn that warning into something bigger, but then let the
mount continue - since now that "mand" flag would be purely a legacy
thing.
And yes, if we do that, we'd want the warning to be a big ugly thing,
just to make people very aware of it happening. Right now it's a
one-liner that is easy to miss, and the "oh, the mount failed" is the
thing that hopefully informs people about the fact that they need to
enable CONFIG_MANDATORY_FILE_LOCKING.
When I ripped out the NFS "intr" mount option fourteen years ago,
I just turned it into a noop (commit 150030b78a45). It has greatly
amused me every article I've read that's been written since then
that recommends using it. Just shows how much tribal knowledge we
have.
I think this is a little different, though; I was essetially making the
*wanted* behaviour of 'intr' the default (and disabling the unwanted
behaviour). With 'mand', we're losing the behaviour entirely, and it's
plausible that someone might care. Maybe something more like the old
sys_bdflush implementation?
if (msg_count < 5) {
msg_count++;
printk(KERN_INFO
"warning: process `%s' used the obsolete bdflush"
" system call\n", current->comm);
printk(KERN_INFO "Fix your initscripts?\n");
}
From: Amir Goldstein <amir73il@gmail.com> Date: 2021-08-20 06:36:51
On Thu, Aug 19, 2021 at 11:32 PM Linus Torvalds
[off-list ref] wrote:
On Thu, Aug 19, 2021 at 1:18 PM Jeff Layton [off-list ref] wrote:
quoted
Now that I think about it a little more, I actually did get one
complaint a few years ago:
Someone had upgraded from an earlier distro that supported the -o mand
mount option to a later one that had disabled it, and they had an (old)
fstab entry that specified it.
Hmm. We might be able to turn the "return -EINVAL" into just a warning.
Yes, yes, currently if you turn off CONFIG_MANDATORY_FILE_LOCKING, we
already do that
VFS: "mand" mount option not supported
warning print, but then we fail the mount.
If CONFIG_MANDATORY_FILE_LOCKING goes away entirely, it might make
sense to turn that warning into something bigger, but then let the
mount continue - since now that "mand" flag would be purely a legacy
thing.
And yes, if we do that, we'd want the warning to be a big ugly thing,
just to make people very aware of it happening. Right now it's a
one-liner that is easy to miss, and the "oh, the mount failed" is the
thing that hopefully informs people about the fact that they need to
enable CONFIG_MANDATORY_FILE_LOCKING.
The logic being that if you can no longer enable mandatory locking in
the kernel, the current hard failure seems overly aggressive (and
might cause boot failures and inability to fix/report things when it
possibly keeps you from using the system at all).
Allow me to play the devil's advocate here - if fstab has '-o mand' we have
no way of knowing if any application is relying on '-o mand' and adding
more !!!!! to the warning is mostly good for clearing our conscious ;-)
Not saying we cannot resort to that and not saying there is an easy
solution, but there is one more solution to consider - force rdonly mount.
Yes, it could break some systems and possibly fail boot, but then again
an ext4 fs can already become rdonly due to errors, so it wouldn't
be the first time that sysadmins/users run into this behavior.
Thanks,
Amir.
From: Amir Goldstein <amir73il@gmail.com> Date: 2021-08-20 07:15:09
On Fri, Aug 20, 2021 at 9:36 AM Amir Goldstein [off-list ref] wrote:
On Thu, Aug 19, 2021 at 11:32 PM Linus Torvalds
[off-list ref] wrote:
quoted
On Thu, Aug 19, 2021 at 1:18 PM Jeff Layton [off-list ref] wrote:
quoted
Now that I think about it a little more, I actually did get one
complaint a few years ago:
Someone had upgraded from an earlier distro that supported the -o mand
mount option to a later one that had disabled it, and they had an (old)
fstab entry that specified it.
Hmm. We might be able to turn the "return -EINVAL" into just a warning.
Yes, yes, currently if you turn off CONFIG_MANDATORY_FILE_LOCKING, we
already do that
VFS: "mand" mount option not supported
warning print, but then we fail the mount.
If CONFIG_MANDATORY_FILE_LOCKING goes away entirely, it might make
sense to turn that warning into something bigger, but then let the
mount continue - since now that "mand" flag would be purely a legacy
thing.
And yes, if we do that, we'd want the warning to be a big ugly thing,
just to make people very aware of it happening. Right now it's a
one-liner that is easy to miss, and the "oh, the mount failed" is the
thing that hopefully informs people about the fact that they need to
enable CONFIG_MANDATORY_FILE_LOCKING.
The logic being that if you can no longer enable mandatory locking in
the kernel, the current hard failure seems overly aggressive (and
might cause boot failures and inability to fix/report things when it
possibly keeps you from using the system at all).
Allow me to play the devil's advocate here - if fstab has '-o mand' we have
no way of knowing if any application is relying on '-o mand' and adding
more !!!!! to the warning is mostly good for clearing our conscious ;-)
Not saying we cannot resort to that and not saying there is an easy
solution, but there is one more solution to consider - force rdonly mount.
Yes, it could break some systems and possibly fail boot, but then again
an ext4 fs can already become rdonly due to errors, so it wouldn't
be the first time that sysadmins/users run into this behavior.
Adding an anecdote - this week I got a report from field support
engineers about failure to assemble a RAID0 array, which led to this
warning that *requires* user intervention, in the worse case for boot
device it requires changing kernel boot params:
md/raid0:%s: cannot assemble multi-zone RAID0 with default_layout setting
md/raid0: please set raid.default_layout to 1 or 2
c84a1372df92 md/raid0: avoid RAID0 data corruption due to layout confusion.
There is no way I would have gotten this report from the field if a failure
was not involved...
The rdonly mount is only needed to get the attention of support people
to look the the kernel logs and find the warning - at this point, not too
many !!!!! are needed ;-)
So we could make 'mand' an alias to 'ro' and print a warning that says:
"'mand' mount option is deprecated, please fix your init scripts.
For caution, your filesystem was mounted rdonly, feel free to remount
rw and move on..."
Thanks,
Amir.
From: David Laight <hidden> Date: 2021-08-20 08:30:45
From: Linus Torvalds
Sent: 19 August 2021 23:33
On Thu, Aug 19, 2021 at 2:43 PM Jeff Layton [off-list ref] wrote:
quoted
What sort of big, ugly warning did you have in mind?
I originally thought WARN_ON_ONCE() just to get the distro automatic
error handling involved, but it would probably be a big problem for
the people who end up having panic-on-warn or something.
Even panic-on-oops is a PITA.
Took us weeks to realise that a customer system that was randomly
rebooting was 'just' having a boring NULL pointer access.
So probably just a "make it a big box" thing that stands out, kind of
what lockdep etc does with
pr_warn("======...====\n");
around the messages..
I don't know if distros have some pattern we could use that would end
up being something that gets reported to the user?
Will users even see it?
A lot of recent distro installs try very hard to hide all the kernel
messages.
OTOH I guess '-o mand' is unlikely to be set on any of those systems.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
From: Jeff Layton <jlayton@kernel.org> Date: 2021-08-20 12:27:27
On Fri, 2021-08-20 at 10:14 +0300, Amir Goldstein wrote:
On Fri, Aug 20, 2021 at 9:36 AM Amir Goldstein [off-list ref] wrote:
quoted
On Thu, Aug 19, 2021 at 11:32 PM Linus Torvalds
[off-list ref] wrote:
quoted
On Thu, Aug 19, 2021 at 1:18 PM Jeff Layton [off-list ref] wrote:
quoted
Now that I think about it a little more, I actually did get one
complaint a few years ago:
Someone had upgraded from an earlier distro that supported the -o mand
mount option to a later one that had disabled it, and they had an (old)
fstab entry that specified it.
Hmm. We might be able to turn the "return -EINVAL" into just a warning.
Yes, yes, currently if you turn off CONFIG_MANDATORY_FILE_LOCKING, we
already do that
VFS: "mand" mount option not supported
warning print, but then we fail the mount.
If CONFIG_MANDATORY_FILE_LOCKING goes away entirely, it might make
sense to turn that warning into something bigger, but then let the
mount continue - since now that "mand" flag would be purely a legacy
thing.
And yes, if we do that, we'd want the warning to be a big ugly thing,
just to make people very aware of it happening. Right now it's a
one-liner that is easy to miss, and the "oh, the mount failed" is the
thing that hopefully informs people about the fact that they need to
enable CONFIG_MANDATORY_FILE_LOCKING.
The logic being that if you can no longer enable mandatory locking in
the kernel, the current hard failure seems overly aggressive (and
might cause boot failures and inability to fix/report things when it
possibly keeps you from using the system at all).
Allow me to play the devil's advocate here - if fstab has '-o mand' we have
no way of knowing if any application is relying on '-o mand' and adding
more !!!!! to the warning is mostly good for clearing our conscious ;-)
Not saying we cannot resort to that and not saying there is an easy
solution, but there is one more solution to consider - force rdonly mount.
Yes, it could break some systems and possibly fail boot, but then again
an ext4 fs can already become rdonly due to errors, so it wouldn't
be the first time that sysadmins/users run into this behavior.
Adding an anecdote - this week I got a report from field support
engineers about failure to assemble a RAID0 array, which led to this
warning that *requires* user intervention, in the worse case for boot
device it requires changing kernel boot params:
md/raid0:%s: cannot assemble multi-zone RAID0 with default_layout setting
md/raid0: please set raid.default_layout to 1 or 2
c84a1372df92 md/raid0: avoid RAID0 data corruption due to layout confusion.
There is no way I would have gotten this report from the field if a failure
was not involved...
The rdonly mount is only needed to get the attention of support people
to look the the kernel logs and find the warning - at this point, not too
many !!!!! are needed ;-)
So we could make 'mand' an alias to 'ro' and print a warning that says:
"'mand' mount option is deprecated, please fix your init scripts.
For caution, your filesystem was mounted rdonly, feel free to remount
rw and move on..."
That is a possibility, but I'm not sure it's any better than just
failing the mount. We could also just keep the code around and throw a
big, scary warning about its impending removal for a few releases before
ripping it out completely (like Willy T. was suggesting).
I'm fine with any of these approaches if the consensus is that it's too
risky to just remove it. OTOH, I've yet to ever hear of any application
that uses this feature, even in a historical sense. You have to jump
through so many hoops that nothing can rely on having it available.
--
Jeff Layton [off-list ref]
On Fri, Aug 20, 2021 at 08:27:12AM -0400, Jeff Layton wrote:
I'm fine with any of these approaches if the consensus is that it's too
risky to just remove it. OTOH, I've yet to ever hear of any application
that uses this feature, even in a historical sense.
Honestly, I agree. Some have fun of me because I'm often using old
stuff, but I don't even remember having used an application that
made use of mandatory locking. I remember having enabled it myself in
my kernels long ago after discovering its existence in the man pages,
just to test it. It doesn't rule out the possibility that it exists
somewhere though, but I think that the immediate removal combined
with the big fat warning in previous branches should be largely
enough to avoid the last minute surprise.
Willy
From: Jeff Layton <jlayton@kernel.org> Date: 2021-08-20 13:03:25
On Fri, 2021-08-20 at 14:38 +0200, Willy Tarreau wrote:
On Fri, Aug 20, 2021 at 08:27:12AM -0400, Jeff Layton wrote:
quoted
I'm fine with any of these approaches if the consensus is that it's too
risky to just remove it. OTOH, I've yet to ever hear of any application
that uses this feature, even in a historical sense.
Honestly, I agree. Some have fun of me because I'm often using old
stuff, but I don't even remember having used an application that
made use of mandatory locking. I remember having enabled it myself in
my kernels long ago after discovering its existence in the man pages,
just to test it. It doesn't rule out the possibility that it exists
somewhere though, but I think that the immediate removal combined
with the big fat warning in previous branches should be largely
enough to avoid the last minute surprise.
Good point. It wouldn't hurt to push such a warning into stable kernels
at the same time. There always is a lag when we do something like this
before some downstream user notices.
--
Jeff Layton [off-list ref]
On Fri, Aug 20, 2021 at 09:03:16AM -0400, Jeff Layton wrote:
Good point. It wouldn't hurt to push such a warning into stable kernels
at the same time. There always is a lag when we do something like this
before some downstream user notices.
Yes, that's why I proposed this. A warning can be backported into
stable without big consequences except warning future victims...
Willy
From: Steven Rostedt <rostedt@goodmis.org> Date: 2021-08-20 13:43:19
On Thu, 19 Aug 2021 15:32:31 -0700
Linus Torvalds [off-list ref] wrote:
I originally thought WARN_ON_ONCE() just to get the distro automatic
error handling involved, but it would probably be a big problem for
the people who end up having panic-on-warn or something.
So probably just a "make it a big box" thing that stands out, kind of
what lockdep etc does with
pr_warn("======...====\n");
around the messages..
I don't know if distros have some pattern we could use that would end
up being something that gets reported to the user?
People have started using my trace-printk notice message, that seems to
be big enough to get noticed.
**********************************************************
** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
** **
** trace_printk() being used. Allocating extra memory. **
** **
** This means that this is a DEBUG kernel and it is **
** unsafe for production use. **
** **
** If you see this message and you are not debugging **
** the kernel, report this immediately to your vendor! **
** **
** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
**********************************************************
There's been some talk about making that a more "generic" warning
message too.
-- Steve
On Fri, Aug 20, 2021 at 6:43 AM Steven Rostedt [off-list ref] wrote:
On Thu, 19 Aug 2021 15:32:31 -0700
Linus Torvalds [off-list ref] wrote:
quoted
I don't know if distros have some pattern we could use that would end
up being something that gets reported to the user?
People have started using my trace-printk notice message, that seems to
be big enough to get noticed.
Well, I think people who use ftrace are m,ore likely to look at kernel
messages than most...
So what would be more interesting is if there's some distro support
for showing kernel notifications..
I see new notifications for calendar events, for devices that got
mounted, for a lot of things - so I'm really wondering if somebody
already perhaps had something for specially formatted kernel
messages..
Linus
On Thu, Aug 19, 2021 at 12:15:08PM -0700, Linus Torvalds wrote:
On Thu, Aug 19, 2021 at 11:39 AM Jeff Layton [off-list ref] wrote:
quoted
I'm all for ripping it out too. It's an insane interface anyway.
I've not heard a single complaint about this being turned off in
fedora/rhel or any other distro that has this disabled.
I'd love to remove it, we could absolutely test it. The fact that
several major distros have it disabled makes me think it's fine.
It looks like it's enabled (checking the Pixel 4 kernel image), but it's
not specifically mentioned in any of the build configs that are used to
construct the image, so I think this is just catching the "default y". I
expect it'd be fine to turn this off.
I will ask around to see if it's actually used.
--
Kees Cook
From: "H. Peter Anvin" <hpa@zytor.com> Date: 2021-08-20 19:48:51
I thought the main user was Samba and/or otherwise providing file service for M$ systems?
On August 20, 2021 9:30:31 AM PDT, Kees Cook [off-list ref] wrote:
On Thu, Aug 19, 2021 at 12:15:08PM -0700, Linus Torvalds wrote:
quoted
On Thu, Aug 19, 2021 at 11:39 AM Jeff Layton [off-list ref] wrote:
quoted
I'm all for ripping it out too. It's an insane interface anyway.
I've not heard a single complaint about this being turned off in
fedora/rhel or any other distro that has this disabled.
I'd love to remove it, we could absolutely test it. The fact that
several major distros have it disabled makes me think it's fine.
It looks like it's enabled (checking the Pixel 4 kernel image), but it's
not specifically mentioned in any of the build configs that are used to
construct the image, so I think this is just catching the "default y". I
expect it'd be fine to turn this off.
I will ask around to see if it's actually used.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
From: Jeff Layton <jlayton@kernel.org> Date: 2021-08-20 21:29:38
No, Windows has deny-mode locking at open time, but the kernel's
mandatory locks are enforced during read/write (which is why they are
such a pain). Samba will not miss these at all.
If we want something to provide windows-like semantics, we'd probably
want to start with something like Pavel Shilovsky's O_DENY_* patches.
-- Jeff
On Fri, 2021-08-20 at 12:17 -0700, H. Peter Anvin wrote:
I thought the main user was Samba and/or otherwise providing file service for M$ systems?
On August 20, 2021 9:30:31 AM PDT, Kees Cook [off-list ref] wrote:
quoted
On Thu, Aug 19, 2021 at 12:15:08PM -0700, Linus Torvalds wrote:
quoted
On Thu, Aug 19, 2021 at 11:39 AM Jeff Layton [off-list ref] wrote:
quoted
I'm all for ripping it out too. It's an insane interface anyway.
I've not heard a single complaint about this being turned off in
fedora/rhel or any other distro that has this disabled.
I'd love to remove it, we could absolutely test it. The fact that
several major distros have it disabled makes me think it's fine.
It looks like it's enabled (checking the Pixel 4 kernel image), but it's
not specifically mentioned in any of the build configs that are used to
construct the image, so I think this is just catching the "default y". I
expect it'd be fine to turn this off.
I will ask around to see if it's actually used.
From: Jeff Layton <jlayton@kernel.org> Date: 2021-08-21 12:46:02
On Fri, 2021-08-20 at 17:29 -0400, Jeff Layton wrote:
No, Windows has deny-mode locking at open time, but the kernel's
mandatory locks are enforced during read/write (which is why they are
such a pain). Samba will not miss these at all.
If we want something to provide windows-like semantics, we'd probably
want to start with something like Pavel Shilovsky's O_DENY_* patches.
-- Jeff
Doh! It completely slipped my mind about byte-range locks on windows...
Those are mandatory and they do block read and write activity to the
ranges locked. They have weird semantics vs. POSIX locks (they stack
instead of splitting/merging, etc.).
Samba emulates these with (advisory) POSIX locks in most cases. Using
mandatory locks is probably possible, but I think it would add more
potential for deadlock and security issues.
--
Jeff Layton [off-list ref]
On Fri, Aug 20, 2021 at 10:30 AM David Laight [off-list ref] wrote:
From: Linus Torvalds
quoted
Sent: 19 August 2021 23:33
On Thu, Aug 19, 2021 at 2:43 PM Jeff Layton [off-list ref] wrote:
quoted
What sort of big, ugly warning did you have in mind?
I originally thought WARN_ON_ONCE() just to get the distro automatic
error handling involved, but it would probably be a big problem for
the people who end up having panic-on-warn or something.
Even panic-on-oops is a PITA.
Took us weeks to realise that a customer system that was randomly
rebooting was 'just' having a boring NULL pointer access.
quoted
So probably just a "make it a big box" thing that stands out, kind of
what lockdep etc does with
pr_warn("======...====\n");
around the messages..
Do we really need more of these?
They take time to print (especially on serial
consoles) and increase kernel size.
What's wrong with using an appropriate KERN_*, and letting userspace
make sure the admin/user will see the message (see below)?
quoted
I don't know if distros have some pattern we could use that would end
up being something that gets reported to the user?
Will users even see it?
A lot of recent distro installs try very hard to hide all the kernel
messages.
Exactly. E.g. Ubuntu doesn't show any kernel output during normal
operation.
On Fri, Aug 20, 2021 at 6:12 PM Linus Torvalds
[off-list ref] wrote:
On Fri, Aug 20, 2021 at 6:43 AM Steven Rostedt [off-list ref] wrote:
quoted
On Thu, 19 Aug 2021 15:32:31 -0700
Linus Torvalds [off-list ref] wrote:
quoted
I don't know if distros have some pattern we could use that would end
up being something that gets reported to the user?
So what would be more interesting is if there's some distro support
for showing kernel notifications..
I see new notifications for calendar events, for devices that got
mounted, for a lot of things - so I'm really wondering if somebody
already perhaps had something for specially formatted kernel
messages..
Isn't that what the old syslog and the new systemd are supposed to
handle in userspace?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
From: David Laight <hidden> Date: 2021-08-23 08:15:07
From: Geert Uytterhoeven
Sent: 23 August 2021 08:56
...
Exactly. E.g. Ubuntu doesn't show any kernel output during normal
operation.
Current ubuntu (x86) is getting to be a PITA.
It even runs the graphical login on tty0 - which is where
the kernel messages would end up.
It is almost impossible to get an actual VGA console.
I need to find a different distro that has less bloat in it.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
From: J. Bruce Fields <hidden> Date: 2021-08-23 22:15:52
On Sat, Aug 21, 2021 at 08:45:54AM -0400, Jeff Layton wrote:
On Fri, 2021-08-20 at 17:29 -0400, Jeff Layton wrote:
quoted
No, Windows has deny-mode locking at open time, but the kernel's
mandatory locks are enforced during read/write (which is why they are
such a pain). Samba will not miss these at all.
If we want something to provide windows-like semantics, we'd probably
want to start with something like Pavel Shilovsky's O_DENY_* patches.
-- Jeff
Doh! It completely slipped my mind about byte-range locks on windows...
Those are mandatory and they do block read and write activity to the
ranges locked. They have weird semantics vs. POSIX locks (they stack
instead of splitting/merging, etc.).
Samba emulates these with (advisory) POSIX locks in most cases. Using
mandatory locks is probably possible, but I think it would add more
potential for deadlock and security issues.
Right, so Windows byte-range locks are different from Windows open deny
modes.
But even if somebody wanted to implement them, I doubt they'd start with
the mandatory locking code you're removing here, so I think they're
irrelevant to this discussion.
--b.