From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [PATCH 0/5] fuse: handle release synchronously (v4) Date: Sat, 18 Oct 2014 15:44:13 -0700 Message-ID: <87a94t577m.fsf@x220.int.ebiederm.org> References: <20140930191933.GC5011@tucsk.piliscsaba.szeredi.hu> <542BE551.1010705@parallels.com> <543F9E75.2090509@parallels.com> <20141017085509.GE5011@tucsk.piliscsaba.szeredi.hu> <20141018182241.GE7996@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain Cc: Linus Torvalds , Miklos Szeredi , Maxim Patlasov , Anand Avati , Linux Kernel Mailing List , Michael j Theall , fuse-devel , linux-fsdevel@vger.kernel.org To: Al Viro Return-path: In-Reply-To: <20141018182241.GE7996@ZenIV.linux.org.uk> (Al Viro's message of "Sat, 18 Oct 2014 19:22:41 +0100") Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Al Viro writes: > On Sat, Oct 18, 2014 at 08:40:05AM -0700, Linus Torvalds wrote: >> On Sat, Oct 18, 2014 at 8:35 AM, Linus Torvalds >> wrote: >> > >> > Look around for AIO. Look around for the loop driver. Look around for >> > a number of things that do "fget()" and that you completely ignored. >> >> .. actually, there are more instances of "get_file()" than of >> "fget()", the aio one just happened to be the latter form. Lots and >> lots of ways to get ahold of a file descriptor that keeps it open past >> the "last close". > > FWIW, procfs patch touches a very annoying issue: ->show_fdinfo() being > blocking. I would really like to get rid of that particular get_file() > and even more so - of get_files_struct() in there. > > I certainly agree that anyone who expects that close() means the end of IO > is completely misguided. Mappings don't disappear on close(), neither does > a descriptor returned by dup(), or one that child got over fork(), > or something sent over in SCM_RIGHTS datagram, or, as you suggested, made > backing store for /dev/loop, etc. > > What's more, in the example given upthread, somebody might've spotted that > file in /proc//fd/* and *opened* it. At which point umount would > have to fail with EBUSY. And the same lsof(8) might've done just that. > > It's not a matter of correctness or security, especially since somebody who > could do that, could've stopped your process, PTRACE_POKEd a fairly short > series of syscalls that would connect to AF_UNIX socket, send the file > over to them and clean after itself, then single-stepped through all of that, > restored the original state and resumed your process. > > It is a QoI matter, though. And get_files_struct() in there is a lot more > annoying than get_file()/fput(). Suppose you catch the process during > exit(). All of a sudden, read from /proc//fdinfo/ ends up doing > shitloads of filp_close(). It would be nice to avoid that. > > Folks, how much pain would it be to make ->show_fdinfo() non-blocking? I took a quick look and there are a couple of instances in tun, eventpoll, and fanotify/inotify that take a spinlock while traversing the data that needs to be printed. So it would take a good hard stare at those pieces of code to understand the locking, and potentially rewrite those routines. The only one I am particularly familiar with tun did not look fundamentally hard to change but it also isn't something I would casually do either, as it would be easy to introduce nasty races by accident. Eric