Messages in this thread | | | Date | Sat, 6 Apr 2024 05:09:23 +0100 | From | Al Viro <> | Subject | Re: [syzbot] [kernfs?] possible deadlock in kernfs_fop_llseek |
| |
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(). Exclusion with copyup by a different operation?
I'm not saying it's wrong - it's just that the thing is tricky enough, so some clarification might be a good idea.
| |