Linux-Fsdevel Archive on lore.kernel.org
 help / color / Atom feed
* Deprecated mandatory file locking
@ 2019-08-14 17:33 Jan Kara
  2019-08-14 17:46 ` Jan Kara
  0 siblings, 1 reply; 4+ messages in thread
From: Jan Kara @ 2019-08-14 17:33 UTC (permalink / raw)
  To: Jeff Layton; +Cc: linux-fsdevel

Hello Jeff,

we've got a report from user
(https://bugzilla.suse.com/show_bug.cgi?id=1145007) wondering why his fstab
entry (for root filesystem!) using 'mand' mount option stopped working.
Now I understand your rationale in 9e8925b67a "locks: Allow disabling
mandatory locking at compile time" but I guess there's some work to do wrt
documentation. At least mount(8) manpage could mention that mandatory
locking is broken and may be disabled referencing the rationale in fcntl
manpage? Or the kernel could mention something in the log about failing
mount because of 'mand' mount option?  What do you think? Because it took
me some code searching to understand why the mount is actually failing
which we can hardly expect from a normal sysadmin...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Deprecated mandatory file locking
  2019-08-14 17:33 Deprecated mandatory file locking Jan Kara
@ 2019-08-14 17:46 ` Jan Kara
  2019-08-15 19:18   ` Jeff Layton
  0 siblings, 1 reply; 4+ messages in thread
From: Jan Kara @ 2019-08-14 17:46 UTC (permalink / raw)
  To: Jeff Layton; +Cc: linux-fsdevel


Resending to proper Jeff's address...

On Wed 14-08-19 19:33:45, Jan Kara wrote:
> Hello Jeff,
> 
> we've got a report from user
> (https://bugzilla.suse.com/show_bug.cgi?id=1145007) wondering why his fstab
> entry (for root filesystem!) using 'mand' mount option stopped working.
> Now I understand your rationale in 9e8925b67a "locks: Allow disabling
> mandatory locking at compile time" but I guess there's some work to do wrt
> documentation. At least mount(8) manpage could mention that mandatory
> locking is broken and may be disabled referencing the rationale in fcntl
> manpage? Or the kernel could mention something in the log about failing
> mount because of 'mand' mount option?  What do you think? Because it took
> me some code searching to understand why the mount is actually failing
> which we can hardly expect from a normal sysadmin...
> 
> 								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Deprecated mandatory file locking
  2019-08-14 17:46 ` Jan Kara
@ 2019-08-15 19:18   ` Jeff Layton
  2019-08-16 15:31     ` Jan Kara
  0 siblings, 1 reply; 4+ messages in thread
From: Jeff Layton @ 2019-08-15 19:18 UTC (permalink / raw)
  To: Jan Kara; +Cc: linux-fsdevel

On Wed, 2019-08-14 at 19:46 +0200, Jan Kara wrote:
> Resending to proper Jeff's address...
> 
> On Wed 14-08-19 19:33:45, Jan Kara wrote:
> > Hello Jeff,
> > 
> > we've got a report from user
> > (https://bugzilla.suse.com/show_bug.cgi?id=1145007) wondering why his fstab
> > entry (for root filesystem!) using 'mand' mount option stopped working.
> > Now I understand your rationale in 9e8925b67a "locks: Allow disabling
> > mandatory locking at compile time" but I guess there's some work to do wrt
> > documentation. At least mount(8) manpage could mention that mandatory
> > locking is broken and may be disabled referencing the rationale in fcntl
> > manpage? Or the kernel could mention something in the log about failing
> > mount because of 'mand' mount option?  What do you think? Because it took
> > me some code searching to understand why the mount is actually failing
> > which we can hardly expect from a normal sysadmin...
> > 
> > 								Honza

Wow, I think this is the first actual user fallout we've ever had from
that change! Why was he setting that option? Does he actually use
mandatory locking?

I think a pr_notice() or pr_warn() at mount time when someone tries to
use it sounds like a very reasonable thing to do. Perhaps we can just
stick one in may_mandlock()?

I'll draft up a patch, and also update
Documentation/filesystems/mandatory-locking.txt with the current
situation.

Thanks,
-- 
Jeff Layton <jlayton@kernel.org>


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Deprecated mandatory file locking
  2019-08-15 19:18   ` Jeff Layton
@ 2019-08-16 15:31     ` Jan Kara
  0 siblings, 0 replies; 4+ messages in thread
From: Jan Kara @ 2019-08-16 15:31 UTC (permalink / raw)
  To: Jeff Layton; +Cc: Jan Kara, linux-fsdevel

On Thu 15-08-19 15:18:45, Jeff Layton wrote:
> On Wed, 2019-08-14 at 19:46 +0200, Jan Kara wrote:
> > Resending to proper Jeff's address...
> > 
> > On Wed 14-08-19 19:33:45, Jan Kara wrote:
> > > Hello Jeff,
> > > 
> > > we've got a report from user
> > > (https://bugzilla.suse.com/show_bug.cgi?id=1145007) wondering why his fstab
> > > entry (for root filesystem!) using 'mand' mount option stopped working.
> > > Now I understand your rationale in 9e8925b67a "locks: Allow disabling
> > > mandatory locking at compile time" but I guess there's some work to do wrt
> > > documentation. At least mount(8) manpage could mention that mandatory
> > > locking is broken and may be disabled referencing the rationale in fcntl
> > > manpage? Or the kernel could mention something in the log about failing
> > > mount because of 'mand' mount option?  What do you think? Because it took
> > > me some code searching to understand why the mount is actually failing
> > > which we can hardly expect from a normal sysadmin...
> > > 
> > > 								Honza
> 
> Wow, I think this is the first actual user fallout we've ever had from
> that change! Why was he setting that option? Does he actually use
> mandatory locking?

Yeah, reportedly they had an application that required mandatory locking.
But they don't use it anymore so they just removed the mount option.

> I think a pr_notice() or pr_warn() at mount time when someone tries to
> use it sounds like a very reasonable thing to do. Perhaps we can just
> stick one in may_mandlock()?

Yeah, sounds reasonable to me.

> I'll draft up a patch, and also update
> Documentation/filesystems/mandatory-locking.txt with the current
> situation.

Thanks!

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-14 17:33 Deprecated mandatory file locking Jan Kara
2019-08-14 17:46 ` Jan Kara
2019-08-15 19:18   ` Jeff Layton
2019-08-16 15:31     ` Jan Kara

Linux-Fsdevel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \
		linux-fsdevel@vger.kernel.org linux-fsdevel@archiver.kernel.org
	public-inbox-index linux-fsdevel


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox