On Mon, 2 Oct 2023 at 17:24, Krister Johansen <kjlx@xxxxxxxxxxxxxxxxxx> wrote: > > The submount code uses the parent nodeid passed into the function in > order to create the root dentry for the new submount. This nodeid does > not get its remote reference count incremented by a lookup option. > > If the parent inode is evicted from its superblock, due to memory > pressure for example, it can result in a forget opertation being sent to > the server. Should this nodeid be forgotten while it is still in use in > a submount, users of the submount get an error from the server on any > subsequent access. In the author's case, this was an EBADF on all > subsequent operations that needed to reference the root. > > Debugging the problem revealed that the dentry shrinker triggered a forget > after killing the dentry with the last reference, despite the root > dentry in another superblock still using the nodeid. There's some context missing here. There are two dentries: a mount point in the parent mount and the root of the submount. The server indicates that the looked up inode is a submount using FUSE_ATTR_SUBMOUNT. Then AFAICS the following happens: 1) the mountpoint dentry is created with nlookup = 1. The S_AUTOMOUNT flag is set on the mountpoint inode. 2) the lookup code sees S_AUTOMOUNT and triggers the submount operation, which sets up the new super_block and the root dentry with the user supplied nodeid and with nlookup = 0 (because it wasn't actually looked up). How the automount gets torn down is another story. You say that the mount point gets evicted due to memory pressure. But it can't get evicted while the submount is attached. So the submount must first get detached, and then the mount point can be reclaimed. The question is: how does the submount gets detached. Do you have an idea? Thanks, Miklos
