From: Catalin Marinas <catalin.marinas@arm.com>
To: "Liao, Chang" <liaochang1@huawei.com>
Cc: mhiramat@kernel.org, oleg@redhat.com, peterz@infradead.org,
will@kernel.org, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: uprobes: Optimize cache flushes for xol slot
Date: Thu, 7 Nov 2024 18:35:57 +0000 [thread overview]
Message-ID: <Zy0IjTkqlCZ9DRWN@arm.com> (raw)
In-Reply-To: <3d166642-4062-42ed-9e24-1771cd819110@huawei.com>
On Wed, Nov 06, 2024 at 05:55:16PM +0800, Liao, Chang wrote:
> 在 2024/9/19 20:17, Liao Chang 写道:
> > On 09/23, Will Deacon wrote:
> >> However, we should use __GFP_ZERO anyway
> >> because I don't think it's a good idea to map an uninitialised page into
> >> userspace.
> > Agreed, and imo this even needs a separate "fix info leak" patch.
> >
> > Oleg.
>
> Given that Oleg's fix info leak patch has been merged [1], the risk of leakage
> is gone. So I am looking forward to your options about this patch. As many
> functions start with same instructions like 'stp fp, lr, [sp, #imm]' or
> 'paciasp'. So I think this patch could avoid unnecessary D/I cache synchronization.
>
> [1] https://lore.kernel.org/all/20240929162047.GA12611@redhat.com/
The patch is fine with the fix in __create_xol_area(). But please add a
comment on why it is safe to skip the cache maintenance, something like
"the initial cache maintenance was done via set_pte_at()" (well, I can
do this when applying).
--
Catalin
next prev parent reply other threads:[~2024-11-07 18:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-19 12:17 [PATCH] arm64: uprobes: Optimize cache flushes for xol slot Liao Chang
2024-09-19 14:18 ` Oleg Nesterov
2024-09-20 8:58 ` Liao, Chang
2024-09-20 11:03 ` Oleg Nesterov
2024-09-20 15:32 ` Catalin Marinas
2024-09-20 17:32 ` Oleg Nesterov
2024-09-22 14:09 ` Will Deacon
2024-09-22 14:39 ` Oleg Nesterov
2024-09-23 11:16 ` Liao, Chang
2024-09-23 1:57 ` Liao, Chang
2024-09-23 7:18 ` Will Deacon
2024-09-23 10:52 ` Oleg Nesterov
2024-09-26 12:06 ` Liao, Chang
2024-09-26 16:08 ` Oleg Nesterov
2024-09-23 11:16 ` Liao, Chang
2024-09-23 16:03 ` Catalin Marinas
2024-11-06 9:55 ` Liao, Chang
2024-11-07 18:35 ` Catalin Marinas [this message]
2024-11-08 16:49 ` Catalin Marinas
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=Zy0IjTkqlCZ9DRWN@arm.com \
--to=catalin.marinas@arm.com \
--cc=liaochang1@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mhiramat@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
/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.