All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Begunkov <asml.silence@gmail.com>
To: 姜智伟 <qq282012236@gmail.com>
Cc: axboe@kernel.dk, io-uring@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] io_uring: Add new functions to handle user fault scenarios
Date: Tue, 22 Apr 2025 09:50:07 +0100	[thread overview]
Message-ID: <63319d5c-00c4-48da-8388-fe46cd2191a8@gmail.com> (raw)
In-Reply-To: <CANHzP_tebha40yy=8rqeu9DMqfrS-veF3=rp76H8udDvs69rfA@mail.gmail.com>

On 4/22/25 09:22, 姜智伟 wrote:
> On Tue, Apr 22, 2025 at 3:59 PM Pavel Begunkov <asml.silence@gmail.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:

They should always come together, there is no way to review it
otherwise. Maintainers will decide how to apply patches best
when it's time for that.

-- 
Pavel Begunkov


      reply	other threads:[~2025-04-22  8:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-22  3:01 [PATCH] io_uring: Add new functions to handle user fault scenarios Zhiwei Jiang
2025-04-22  8:00 ` Pavel Begunkov
2025-04-22  8:22   ` 姜智伟
2025-04-22  8:50     ` Pavel Begunkov [this message]

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=63319d5c-00c4-48da-8388-fe46cd2191a8@gmail.com \
    --to=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=io-uring@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=qq282012236@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.