[splitting topics for ease of threading] On Tue, 2019-12-03 at 08:55 +0200, Amir Goldstein wrote: > On Tue, Dec 3, 2019 at 7:12 AM James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Tue, 2019-12-03 at 06:51 +0200, Amir Goldstein wrote: > > > [cc: ebiederman] [...] > > > 2. Needs serious vetting by Eric (cc'ed) > > > 3. A lot of people have been asking me for filtering of "dirent" > > > fsnotify events (i.e. create/delete) by path, which is not > > > available in those vfs functions, so ifthe concept of current- > > > >mnt flies, fsnotify is going to want to use it as well. > > > > Just a caveat: current->mnt is used in this patch simply as a tag, > > which means it doesn't need to be refcounted. I think I can prove > > that it is absolutely valid if the cred is shifted because the > > reference is held by the code that shifted the cred, but it's > > definitely not valid except for a tag comparison outside of > > that. Thus, if it is useful for fsnotify, more thought will have > > to be given to refcounting it. > > > > Yes. Is there anything preventing us from taking refcount on > current->mnt? We could, but what would it usefully mean? It would just be the last mnt that had its credentials shifted. I think stashing a refcounted mnt in the task structure is reasonably easy: The creds are refcounted, so you simply follow all the task mnt_cred logic I added for releasing the ref in the correct places, so if you want to do that, I can simply rename this tag to something less generic ... unless you have some idea about using the last shift mnt? James
