On 2020-09-08 16:55, Miklos Szeredi wrote:
On Tue, Sep 8, 2020 at 10:17 AM Pradeep P V K
<pragalla@xxxxxxxxxxxxxxxx> wrote:
From: Pradeep P V K <ppvk@xxxxxxxxxxxxxx>
There is a potential race between fuse_abort_conn() and
fuse_copy_page() as shown below, due to which VM_BUG_ON_PAGE
crash is observed for accessing a free page.
context#1: context#2:
fuse_dev_do_read() fuse_abort_conn()
->fuse_copy_args() ->end_requests()
This shouldn't happen due to FR_LOCKED logic. Are you seeing this on
an upstream kernel? Which version?
Thanks,
Miklos
This is happen just after unlock_request() in fuse_ref_page(). In
unlock_request(), it will clear the FR_LOCKED bit.
As there is no protection between context#1 & context#2 during
unlock_request(), there are chances that it could happen.
The value of request flags under "fuse_req" DS is "1561" and this tells
FR_PRIVATE bit is set and there by, it adds the request to end_io list
and free.
This was seen on upstream kernel - v4.19 stable.
Thanks and Regards,
Pradeep
