> On Nov 19, 2023, at 2:18 PM, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: > > >> On Nov 18, 2023, at 6:36 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: >> >> On Sat, Nov 18, 2023 at 05:11:39PM -0500, Chuck Lever wrote: >> >>> We don't hold f_pos_lock in offset_dir_llseek(), though. >> >> We'd better... Which call chain leads to it without ->f_pos_lock? > > I based that comment on code audit. It does not appear to be > obviously held in this code path on first (or second) reading. > > However, let me look again, and test with lockdep_assert() to > confirm. lockdep assertion failure Call Trace: <TASK> ? show_regs+0x5d/0x64 ? offset_dir_llseek+0x39/0xa3 ? __warn+0xab/0x158 ? report_bug+0xd0/0x144 ? offset_dir_llseek+0x39/0xa3 ? handle_bug+0x45/0x74 ? exc_invalid_op+0x18/0x68 ? asm_exc_invalid_op+0x1b/0x20 ? offset_dir_llseek+0x39/0xa3 ? __pfx_nfs3svc_encode_entryplus3+0x10/0x10 [nfsd] vfs_llseek+0x1f/0x31 nfsd_readdir+0x64/0xb7 [nfsd] nfsd3_proc_readdirplus+0xde/0x122 [nfsd] nfsd_dispatch+0xe8/0x1cf [nfsd] svc_process_common+0x43c/0x5d6 [sunrpc] ? __pfx_nfsd_dispatch+0x10/0x10 [nfsd] svc_process+0xc6/0xe3 [sunrpc] svc_handle_xprt+0x371/0x42f [sunrpc] svc_recv+0x10b/0x155 [sunrpc] nfsd+0xb1/0xe3 [nfsd] ? __pfx_nfsd+0x10/0x10 [nfsd] kthread+0x113/0x11b ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2a/0x43 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> -- Chuck Lever
