From: Peter Xu <peterx@redhat.com>
To: jimsiak <jimsiak@cslab.ece.ntua.gr>
Cc: Jinjiang Tu <tujinjiang@huawei.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
viro@zeniv.linux.org.uk, linux-mm@kvack.org,
wangkefeng.wang@huawei.com
Subject: Re: Using userfaultfd with KVM's async page fault handling causes processes to hung waiting for mmap_lock to be released
Date: Fri, 7 Mar 2025 17:41:58 -0500 [thread overview]
Message-ID: <Z8t2Np8fOM9jWmuu@x1.local> (raw)
In-Reply-To: <dee238e365f3727ab16d6685e186c53c@cslab.ece.ntua.gr>
On Fri, Mar 07, 2025 at 03:11:09PM +0200, jimsiak wrote:
> Hi,
>
> From my side, I managed to avoid the freezing of processes with the
> following change in function userfaultfd_release() in file fs/userfaultfd.c
> (https://elixir.bootlin.com/linux/v5.13/source/fs/userfaultfd.c#L842):
>
> I moved the following command from line 851:
> WRITE_ONCE(ctx->released, true);
> (https://elixir.bootlin.com/linux/v5.13/source/fs/userfaultfd.c#L851)
>
> to line 905, that is exactly before the functions returns 0.
>
> That simple workaround worked for my use case but I am far from sure that is
> a correct/sufficient fix for the problem at hand.
Updating the field after userfaultfd_ctx_put() might mean UAF, afaict.
Maybe it's possible to remove ctx->released but only rely on the mmap write
lock. However that'll need some closer look and more thoughts.
To me, the more straightforward way to fix it is to use the patch I
mentioned in the other email:
https://lore.kernel.org/all/ZLmT3BfcmltfFvbq@x1n/
Or does it mean it didn't work at all?
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2025-03-07 22:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-18 14:33 Using userfaultfd with KVM's async page fault handling causes processes to hung waiting for mmap_lock to be released Dimitris Siakavaras
2023-07-19 21:16 ` Axel Rasmussen
2023-07-19 21:54 ` Axel Rasmussen
2023-07-20 20:06 ` Peter Xu
2025-03-07 7:21 ` Jinjiang Tu
2025-03-07 8:07 ` Jinjiang Tu
2025-03-07 13:11 ` jimsiak
2025-03-07 22:41 ` Peter Xu [this message]
2025-03-10 6:40 ` Jinjiang Tu
2025-03-10 18:50 ` Peter Xu
2025-03-11 8:14 ` Jinjiang Tu
2025-03-12 9:18 ` Jinjiang Tu
2025-03-12 14:09 ` Peter Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z8t2Np8fOM9jWmuu@x1.local \
--to=peterx@redhat.com \
--cc=jimsiak@cslab.ece.ntua.gr \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tujinjiang@huawei.com \
--cc=viro@zeniv.linux.org.uk \
--cc=wangkefeng.wang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).