On Thu, 2022-07-14 at 17:14 +0000, Chuck Lever III wrote:

quoted

On Jul 14, 2022, at 1:12 PM, Jeff Layton [off-list ref] wrote:

On Thu, 2022-07-14 at 16:47 +0000, Chuck Lever III wrote:

quoted

quoted

On Jul 14, 2022, at 11:28 AM, Jeff Layton [off-list ref] wrote:

We'll need the nfs4_open to vet the filename. Change nfs4_set_delegation
to take the same arguments are nfs4_open_delegation.

^are^as

Nit: Considering that in the next patch you change the synopsis of
nfs4_open_delegation again but not nfs4_set_delegation, this
description causes a little whiplash.

Yeah, I should have squashed a couple of those together. I _did_ say it
was an RFC. I can resend a cleaned-up version later if you want to take
this in.

I'm interested in Neil's thoughts about this approach, but I'm
willing to run with it unless test results show a regression.

...and there is a regression. Partial lockdep pop here:

Jul 14 14:46:54 quad3 kernel: ============================================
Jul 14 14:46:54 quad3 kernel: WARNING: possible recursive locking detected
Jul 14 14:46:54 quad3 kernel: 5.19.0-rc5+ #316 Tainted: G           OE    
Jul 14 14:46:54 quad3 kernel: --------------------------------------------
Jul 14 14:46:54 quad3 kernel: nfsd/1148 is trying to acquire lock:
Jul 14 14:46:54 quad3 kernel: ffff88812a3a7388 (&inode->i_sb->s_type->i_mutex_dir_key/1){++++}-{3:3}, at: nfsd4_process_open2+0x1890/0x2710 [nfsd]
Jul 14 14:46:54 quad3 kernel: 
                              but task is already holding lock:
Jul 14 14:46:54 quad3 kernel: ffff88812a3a7388 (&inode->i_sb->s_type->i_mutex_dir_key/1){++++}-{3:3}, at: nfsd_lookup_dentry+0x16f/0x6a0 [nfsd]
Jul 14 14:46:54 quad3 kernel: 
                              other info that might help us debug this:
Jul 14 14:46:54 quad3 kernel:  Possible unsafe locking scenario:
Jul 14 14:46:54 quad3 kernel:        CPU0
Jul 14 14:46:54 quad3 kernel:        ----
Jul 14 14:46:54 quad3 kernel:   lock(&inode->i_sb->s_type->i_mutex_dir_key/1);
Jul 14 14:46:54 quad3 kernel:   lock(&inode->i_sb->s_type->i_mutex_dir_key/1);
Jul 14 14:46:54 quad3 kernel: 
                               *** DEADLOCK ***
Jul 14 14:46:54 quad3 kernel:  May be due to missing lock nesting notation
Jul 14 14:46:54 quad3 kernel: 1 lock held by nfsd/1148:
Jul 14 14:46:54 quad3 kernel:  #0: ffff88812a3a7388 (&inode->i_sb->s_type->i_mutex_dir_key/1){++++}-{3:3}, at: nfsd_lookup_dentry+0x16f/0x6a0 [nfsd]
Jul 14 14:46:54 quad3 kernel: 


The core problem is the unclear locking in nfsd_lookup_dentry. Sometimes
that returns with the i_rwsem held, but there's no clear indication of
whether that's the case when the function returns. I guess fh_unlock
just takes care of that (which is a little scary, tbqh).

Now that I've taken a stab at it, I don't see how we can fix this w/o
taking Neil's locking cleanups series first. I think I'll pull that in
and try to redo this series on top of it.

Cheers,
-- 
Jeff Layton [off-list ref]