On Fri, Mar 6, 2020 at 9:05 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > On Fri, Mar 06, 2020 at 07:58:23PM +0000, Al Viro wrote: > > On Fri, Mar 06, 2020 at 07:43:22PM +0000, Al Viro wrote: > > > On Fri, Mar 06, 2020 at 05:25:49PM +0100, Miklos Szeredi wrote: > > > > On Tue, Mar 03, 2020 at 08:46:09AM +0100, Miklos Szeredi wrote: > > > > > > > > > > I'm doing a patch. Let's see how it fares in the face of all these > > > > > preconceptions. > > > > > > > > Here's a first cut. Doesn't yet have superblock info, just mount info. > > > > Probably has rough edges, but appears to work. > > > > > > For starters, you have just made namespace_sem held over copy_to_user(). > > > This is not going to fly. > > > > In case if the above is too terse: you grab your mutex while under > > namespace_sem (see attach_recursive_mnt()); the same mutex is held > > while calling dir_emit(). Which can (and normally does) copy data > > to userland-supplied buffer. > > > > NAK for that reason alone, and to be honest I had been too busy > > suppressing the gag reflex to read and comment any deeper. > > > > I really hate that approach, in case it's not clear from the above. > > To the degree that I don't trust myself to filter out the obscenities > > if I try to comment on it right now. > > > > The only blocking thing we can afford under namespace_sem is GFP_KERNEL > > allocation. > > Incidentally, attach_recursive_mnt() only gets you the root(s) of > attached tree(s); try mount --rbind and see how much you've missed. Okay. Both trivially fixable: - the dir_emit() can be taken out from under the mutex and the rb tree search repeated for every entry; possibly not as efficient, but I guess at this point that's irrelevant - addition of the mountfs entry moved to the right places Thanks, Miklos
