linux-kernel - Re: Revoking filesystems [was Re: Sysfs attributes racing withunregistration]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <delay-force-umount@mdm.bga.com>
Date:	Sat, 07 Jan 2012 15:01:39 -0600
From:	Milton Miller <miltonm@....com>
To:	"Ted Ts'o" <tytso@....edu>
Cc:	<linux-kernel@...r.kernel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Tejun Heo <tj@...nel.org>,
	"Alexander E. Patrakov" <patrakov@...il.com>
Subject: Re: Revoking filesystems [was Re: Sysfs attributes racing withunregistration]

[resending with better headers]

On Thu Jan 05 2012 about 14:28:28 EST, Ted Ts'o wrote:
> On Thu, Jan 05, 2012 at 10:36:02AM -0800, Tejun Heo wrote:
> > Hello, Ted.
> >
> > On Thu, Jan 05, 2012 at 01:27:52PM -0500, Ted Ts'o wrote:
> > > So it's really more of a filesystem force-umount method. I could
> > > imagine that this could also be used to extend the functionality of
> > > umount(2) so that the MNT_FORCE flag could be used with non-NFS file
> > > systems as well as NFS file systems.
> >
> > I think these are two separate mechanisms. Filesystems need to be
> > able to handle IO errors no matter what and underlying device going
> > away is the same situation. There's no reason to mix that with force
> > unmount. That's a separate feature and whether to force unmount
> > filesystem on device removal or permanent failure is a policy decision
> > which belongs to userland - ie. if such behavior is desired, it should
> > be implemented via udev/udisk instead of hard coded logic in kernel.
> 
> I think it's needless complexity to loop this into userspace. If the
> block device is gone, it's *gone*. What else could userspace do with
> this information that block device has disappeared? Right now, once
> gone, it's never coming back. Even if the luser plugs the USB device
> back in, it's going to be coming back as a new block device node.


While user space has lost the ability to read that fs, there is lots
that can continue to work, espically if the system is not under memory
pressure.

First of all, what if the process I really care about is in a chroot
on another file system that was mounted under the failed filesystem?

I don't want the kernel killing my job and leaving a partial file on
some other file system just because some other disk went offline.

Second, as long as the file is cached in memory, I might be able
to use that busybox that is cached to shutdown my system or mount
the usb drive after it comes back as a new location, as long
as there isn't memory pressure.

> 
> So we might as well automatically forcibly unmount the file system at
> this point. I can imagine sending an optional notification that such
> a thing has happened, perhaps via a netlink socket, but why not have
> the kernel do the right thing automatically?
> 
> > I don't know enough to decide whether such forced unmount is a useful
> > feature tho. It can be neat for development but is there any real
> > necessity for the feature?
> 
> Well, if you want to complicate matters by having this go via a
> notification up to userspace, and then have the userspace thoughtfully
> consider (after looking up all sorts of complex rules stored in XML
> files whose schema is documented nowhere but in the source code) that
> the file system should go away because the block device has gone away,
> the userspace code will then have to send a forced unmount.
> 
> The other use case would be a system administrator who doesn't want to
> figure out which random shell is still cd'ed into a directory of a
> file system he/she wants to unmount, he can still force the umount.
> (Other Unix systems have had this feature in the past, and the result
> is the same as what happens if you are cd'ed into a directory which is
> later rmdir'ed.) It's an ungraceful way of running things, but
> sometimes it's the easist way to go.
> 
> - Ted

I can see something like this as an assist to userspace, but don't
forget that mounts are a tree.

milton
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/