From: Yeoreum Yun <yeoreum.yun@arm.com>
To: Andrey Konovalov <andreyknvl@gmail.com>
Cc: ryabinin.a.a@gmail.com, glider@google.com, dvyukov@google.com,
vincenzo.frascino@arm.com, corbet@lwn.net,
catalin.marinas@arm.com, will@kernel.org,
akpm@linux-foundation.org, scott@os.amperecomputing.com,
jhubbard@nvidia.com, pankaj.gupta@amd.com, leitao@debian.org,
kaleshsingh@google.com, maz@kernel.org, broonie@kernel.org,
oliver.upton@linux.dev, james.morse@arm.com, ardb@kernel.org,
hardevsinh.palaniya@siliconsignals.io, david@redhat.com,
yang@os.amperecomputing.com, kasan-dev@googlegroups.com,
workflows@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org
Subject: Re: [PATCH v4 1/2] kasan/hw-tags: introduce kasan.write_only option
Date: Mon, 18 Aug 2025 16:18:42 +0100 [thread overview]
Message-ID: <aKNEUocjM16NpPpS@e129823.arm.com> (raw)
In-Reply-To: <CA+fCnZd9m3WBPimikuxSMNar-xbDaNFNQEJ9Bn=8uCMe-uYHeQ@mail.gmail.com>
Hi Andery,
> On Mon, Aug 18, 2025 at 3:11 PM Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> >
> > > > + hw_enable_tag_checks_write_only()) {
> > > > + kasan_arg_write_only == KASAN_ARG_WRITE_ONLY_OFF;
> > >
> > > Typo in == in the line above. But also I think we can just drop the
> > > line: kasan_arg_write_only is KASAN_ARG_WRITE_ONLY_ON after all, it's
> > > just not supported and thus kasan_flag_write_only is set to false to
> > > reflect that.
> >
> > Sorry :\ I've missed this fix from patch 3... this should be == to =.
> >
> > However, we couldn't remove kasan_arg_write_only check in condition.
> > If one of cpu get failed to hw_enable_tag_checks_write_only() then
> > By changing this with KASAN_ARG_WRITE_ONLY_OFF, It prevent to call
> > hw_eanble_tag_checks_write_only() in other cpu.
>
> Is it possible that the write-only mode will fail to be enabled on one
> CPU but then get enabled successfully for another?
>
> What would happen with the current code if the first CPU succeeds in
> enabling the write-only mode, and the second one fails?
The only failure case is when CPU doesn't support the MTE_STORE_ONLY feature.
Since MTE_STORE_ONLY is BOOT CPU feature, the CPUs have two state --
all CPUs have a MTE_STORE_ONLY feature or they doesn't have it.
So when boot-cpu try to enable the write-only option according to
"write_only=on" boot argument but the cpu doesn't have this feature,
hw_enable_tag_checks_write_only() will fail and prevent the calling
hw_enable_tag_checks_write_only() in other cpu by kasan_arg_write_only
as OFF to prevent other cpu call this function since it'll be failed
anyway.
So there is no case for failure -- the first CPU succeeds but second one
fails. if first one succeeds, all cpus will success ans vice versa.
This condition just to prevent to call
hw_enable_tags_checks_write_only() by other cpu if first cpu found it
doesn't support MTE_STORE_ONLY feature since other doesn't need to call
hw_eanble_tag_checks_write_only() function -- it'll be failed
so it is meaningless call.
>
> > As you said, kasan_flag_write_only reflects the state.
> > But like other option, I keep the condition to call the hw_enable_xxx()
> > by checking the "argments" and keep the "hw enable state" with
> > kasan_flag_write_only.
>
> Assuming we keep this behavior, please add a comment explaining all this.
Okay. :)
--
Sincerely,
Yeoreum Yun
next prev parent reply other threads:[~2025-08-18 15:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-18 7:50 [PATCH v4 0/2] introduce kasan.write_only option in hw-tags Yeoreum Yun
2025-08-18 7:50 ` [PATCH v4 1/2] kasan/hw-tags: introduce kasan.write_only option Yeoreum Yun
2025-08-18 9:52 ` Ben Horgan
2025-08-18 13:54 ` Yeoreum Yun
2025-08-18 9:53 ` Andrey Konovalov
2025-08-18 13:11 ` Yeoreum Yun
2025-08-18 14:42 ` Andrey Konovalov
2025-08-18 15:18 ` Yeoreum Yun [this message]
2025-08-18 7:50 ` [PATCH v4 2/2] kasan: apply write-only mode in kasan kunit testcases Yeoreum Yun
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=aKNEUocjM16NpPpS@e129823.arm.com \
--to=yeoreum.yun@arm.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=ardb@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=david@redhat.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=hardevsinh.palaniya@siliconsignals.io \
--cc=james.morse@arm.com \
--cc=jhubbard@nvidia.com \
--cc=kaleshsingh@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=leitao@debian.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=pankaj.gupta@amd.com \
--cc=ryabinin.a.a@gmail.com \
--cc=scott@os.amperecomputing.com \
--cc=vincenzo.frascino@arm.com \
--cc=will@kernel.org \
--cc=workflows@vger.kernel.org \
--cc=yang@os.amperecomputing.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