Messages in this thread | ![/](/images/icornerl.gif) | | From | Amir Goldstein <> | Date | Sat, 6 Apr 2024 08:25:03 +0300 | Subject | Re: [syzbot] [kernfs?] possible deadlock in kernfs_fop_llseek |
| |
On Sat, Apr 6, 2024 at 7:09 AM Al Viro <viro@zeniv.linux.org.uk> wrote: > > On Thu, Apr 04, 2024 at 12:33:40PM +0300, Amir Goldstein wrote: > > > We do not (anymore) lock ovl inode in ovl_llseek(), see: > > b1f9d3858f72 ovl: use ovl_inode_lock in ovl_llseek() > > but ovl inode is held in operations (e.g. ovl_rename) > > which trigger copy up and call vfs_llseek() on the lower file. > > OK, but why do we bother with ovl_inode_lock() there? > Note that serialization on struct file level is provided > on syscall level - see call of fdget_pos() in there. > IOW, which object are you protecting? If it's struct file > passed your way, you should already have the serialization. > If it's underlying file on disk, that's up to vfs_llseek().
You're right.
> Exclusion with copyup by a different operation?
Nah, don't see how this is relevant to file->f_pos.
> > I'm not saying it's wrong - it's just that the thing is > tricky enough, so some clarification might be a good idea.
I think I just used inode_lock() in 9e46b840c705 ("ovl: support stacked SEEK_HOLE/SEEK_DATA") as a common coding pattern in overlayfs when protecting the "master" copy of overlay inode attributes, but it was not needed for file->f_pos.
Miklos, please ack that I am not missing anything and that ovl_inode_lock() is indeed redundant in ovl_llseek().
Anyway, this lock is not part of the lockdep issue that started this thread.
Thanks, Amir.
| ![\](/images/icornerr.gif) |