linux-kernel - Re: [PATCH] io_uring: Add new functions to handle user fault scenarios

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANHzP_tebha40yy=8rqeu9DMqfrS-veF3=rp76H8udDvs69rfA@mail.gmail.com>
Date: Tue, 22 Apr 2025 16:22:52 +0800
From: 姜智伟 <qq282012236@...il.com>
To: Pavel Begunkov <asml.silence@...il.com>
Cc: axboe@...nel.dk, io-uring@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] io_uring: Add new functions to handle user fault scenarios

On Tue, Apr 22, 2025 at 3:59 PM Pavel Begunkov <asml.silence@...il.com> wrote:
>
> On 4/22/25 04:01, Zhiwei Jiang wrote:
> ...
> > I tracked the address that triggered the fault and the related function
> > graph, as well as the wake-up side of the user fault, and discovered this
> > : In the IOU worker, when fault in a user space page, this space is
> > associated with a userfault but does not sleep. This is because during
> > scheduling, the judgment in the IOU worker context leads to early return.
> > Meanwhile, the listener on the userfaultfd user side never performs a COPY
> > to respond, causing the page table entry to remain empty. However, due to
> > the early return, it does not sleep and wait to be awakened as in a normal
> > user fault, thus continuously faulting at the same address,so CPU loop.
> >
> > Therefore, I believe it is necessary to specifically handle user faults by
> > setting a new flag to allow schedule function to continue in such cases,
> > make sure the thread to sleep.Export the relevant functions and struct for
> > user fault.
>
> That's an interesting scenario. Not looking deeper into it, I don't see
> any callers to set_userfault_flag_for_ioworker(), and so there is no one
> to set IO_WORKER_F_FAULT. Is there a second patch patch I lost?
>
> --
> Pavel Begunkov
>
Sorry, the following changes haven't been submitted yet. I was planning
to submit them separately, thinking they belong to two different subsystems.
The other changes that haven't been submitted are as follows:
diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index d80f94346199..74bead069e85 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -32,6 +32,7 @@
 #include <linux/swapops.h>
 #include <linux/miscdevice.h>
 #include <linux/uio.h>
+#include "../io_uring/io-wq.h"

 static int sysctl_unprivileged_userfaultfd __read_mostly;

@@ -369,7 +370,10 @@ vm_fault_t handle_userfault(struct vm_fault *vmf,
unsigned long reason)
        vm_fault_t ret = VM_FAULT_SIGBUS;
        bool must_wait;
        unsigned int blocking_state;
+       struct io_worker *worker = current->worker_private;

+       if (worker)
+               set_userfault_flag_for_ioworker(worker);
        /*
         * We don't do userfault handling for the final child pid update
         * and when coredumping (faults triggered by get_dump_page()).
@@ -506,6 +510,9 @@ vm_fault_t handle_userfault(struct vm_fault *vmf,
unsigned long reason)

        __set_current_state(TASK_RUNNING);

+       if (worker)
+               clear_userfault_flag_for_ioworker(worker);
+
        /*
         * Here we race with the list_del; list_add in
         * userfaultfd_ctx_read(), however because we don't ever run