From: Marco Elver <elver@google.com>
To: vbabka@suse.cz
Cc: Imran Khan <imran.f.khan@oracle.com>,
glider@google.com, dvyukov@google.com, cl@linux.com,
penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com,
akpm@linux-foundation.org, roman.gushchin@linux.dev,
42.hyeyoo@gmail.com, linux-kernel@vger.kernel.org,
kasan-dev@googlegroups.com, linux-mm@kvack.org
Subject: Re: [PATCH v2] Introduce sysfs interface to disable kfence for selected slabs.
Date: Thu, 11 Aug 2022 15:21:48 +0200 [thread overview]
Message-ID: <CANpmjNNC3F88_Jr24DuFyubvQR2Huz6i3BGXgDgi5o_Gs0Znmg@mail.gmail.com> (raw)
In-Reply-To: <6b41bb2c-6305-2bf4-1949-84ba08fdbd72@suse.cz>
On Thu, 11 Aug 2022 at 12:07, <vbabka@suse.cz> wrote:
[...]
> > new flag SLAB_SKIP_KFENCE, it also can serve a dual purpose, where
> > someone might want to explicitly opt out by default and pass it to
> > kmem_cache_create() (for whatever reason; not that we'd encourage
> > that).
>
> Right, not be able to do that would be a downside (although it should be
> possible even with opt-in to add an opt-out cache flag that would just make
> sure the opt-in flag is not set even if eligible by global defaults).
True, but I'd avoid all this unnecessary complexity if possible.
> > I feel that the real use cases for selectively enabling caches for
> > KFENCE are very narrow, and a design that introduces lots of
> > complexity elsewhere, just to support this feature cannot be justified
> > (which is why I suggested the simpler design here back in
> > https://lore.kernel.org/lkml/CANpmjNNmD9z7oRqSaP72m90kWL7jYH+cxNAZEGpJP8oLrDV-vw@mail.gmail.com/
> > )
>
> I don't mind strongly either way, just a suggestion to consider.
While switching the semantics of the flag from opt-out to opt-in is
just as valid, I'm more comfortable with the opt-out flag: the rest of
the logic can stay the same, and we're aware of the fact that changing
cache coverage by KFENCE shouldn't be something that needs to be done
manually.
My main point is that opting out or in to only a few select caches
should be a rarely used feature, and accordingly it should be as
simple as possible. Honestly, I still don't quite see the point of it,
and my solution would be to just increase the KFENCE pool, increase
sample rate, or decrease the "skip covered threshold%". But in the
case described by Imran, perhaps a running machine is having trouble
and limiting the caches to be analyzed by KFENCE might be worthwhile
if a more aggressive configuration doesn't yield anything (and then
there's of course KASAN, but I recognize it's not always possible to
switch kernel and run the same workload with it).
The use case for the proposed change is definitely when an admin or
kernel dev is starting to debug a problem. KFENCE wasn't designed for
that (vs. deployment at scale, discovery of bugs). As such I'm having
a hard time admitting how useful this feature will really be, but
given the current implementation is simple, having it might actually
help a few people.
Imran, just to make sure my assumptions here are right, have you had
success debugging an issue in this way? Can you elaborate on what
"certain debugging scenarios" you mean (admin debugging something, or
a kernel dev, production fleet, or test machine)?
Thanks,
-- Marco
next prev parent reply other threads:[~2022-08-11 13:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-11 8:59 [PATCH v2] Introduce sysfs interface to disable kfence for selected slabs Imran Khan
2022-08-11 9:31 ` vbabka
2022-08-11 9:52 ` Marco Elver
2022-08-11 10:07 ` vbabka
2022-08-11 13:21 ` Marco Elver [this message]
2022-08-11 15:10 ` Imran Khan
2022-08-12 9:11 ` Marco Elver
2022-08-11 10:40 ` Hyeonggon Yoo
2022-08-12 10:28 ` Vlastimil Babka
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=CANpmjNNC3F88_Jr24DuFyubvQR2Huz6i3BGXgDgi5o_Gs0Znmg@mail.gmail.com \
--to=elver@google.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=imran.f.khan@oracle.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@suse.cz \
/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.