Guys, please, review the patch.
--
Best regards,
Konstantin Khorenko,
Virtuozzo Linux Kernel Team
On 7/6/26 12:59, Konstantin Khorenko wrote:
> Commit 56ef1ee0584c switched the fusectl seq-file iterator from an
> unconditional spin_lock(&fcp->conn->lock) to spin_lock(fcp->req_lock),
> so that each fusectl list is walked under the lock that actually
> protects it. It set ->req_lock for the "pending_req" file (and the
> #if 0 processing/io variants), but missed the second consumer of the
> same start/next/stop callbacks: the "open_files" seq-file has its own
> open handler, fuse_conn_files_open().
>
> fuse_conn_priv is allocated with __seq_open_private() (kzalloc), so for
> open_files ->req_lock stayed NULL. The first read of
> /sys/fs/fuse/connections/<dev>/open_files then calls fuse_req_start()
> -> spin_lock(NULL) and the kernel panics with a NULL pointer
> dereference in the qspinlock slow path.
>
> The conn_files list is added to and removed from under conn->lock
> (fuse_file_alloc()/fuse_file_list_del()), so point ->req_lock at
> conn->lock for the open_files file too. This restores the exact lock
> that was used before 56ef1ee0584c for this path.
>
> Fixes: 56ef1ee0584c ("fuse: lock the input-queue lock when walking
> pending_req in fusectl")
> Feature: vStorage
> https://virtuozzo.atlassian.net/browse/VSTOR-137234
> Signed-off-by: Konstantin Khorenko <[email protected]>
> ---
> fs/fuse/control.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/fuse/control.c b/fs/fuse/control.c
> index 1f5d998be23d..6d210ac80610 100644
> --- a/fs/fuse/control.c
> +++ b/fs/fuse/control.c
> @@ -441,6 +441,7 @@ static int fuse_conn_files_open(struct inode *inode,
> struct file *filp)
>
> fcp->conn = conn;
> fcp->req_list = &conn->conn_files;
> + fcp->req_lock = &conn->lock;
> return 0;
> }
>
_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel
