From: Hyeonggon Yoo <42.hyeyoo@gmail.com>
To: Alexander Atanasov <alexander.atanasov@virtuozzo.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Roman Gushchin <roman.gushchin@linux.dev>,
kernel@openvz.org, Kees Cook <keescook@chromium.org>,
Roman Gushchin <guro@fb.com>, Jann Horn <jannh@google.com>,
Vijayanand Jitta <vjitta@codeaurora.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH v2] mm: Make failslab writable again
Date: Tue, 27 Sep 2022 09:49:52 +0900 [thread overview]
Message-ID: <YzJIsFZQoCEYntvR@hyeyoo> (raw)
In-Reply-To: <30063d97-69f0-bea2-9d59-108140995bfc@virtuozzo.com>
On Fri, Sep 23, 2022 at 10:34:28AM +0300, Alexander Atanasov wrote:
> Hello,
>
> On 21.09.22 14:30, Hyeonggon Yoo wrote:
> > On Tue, Sep 20, 2022 at 03:11:11PM +0300, Alexander Atanasov wrote:
> > > In (060807f841ac mm, slub: make remaining slub_debug related attributes
> > > read-only) failslab was made read-only.
> > > I think it became a collateral victim to the two other options for which
> > > the reasons are perfectly valid.
> > > Here is why:
> > > - sanity_checks and trace are slab internal debug options,
> > > failslab is used for fault injection.
> > > - for fault injections, which by presumption are random, it
> > > does not matter if it is not set atomically. And you need to
> > > set atleast one more option to trigger fault injection.
> > > - in a testing scenario you may need to change it at runtime
> > > example: module loading - you test all allocations limited
> > > by the space option. Then you move to test only your module's
> > > own slabs.
> > > - when set by command line flags it effectively disables all
> > > cache merges.
> >
> > Maybe we can make failslab= boot parameter to consider cache filtering?
> >
> > With that, just pass something like this:
> > failslab=X,X,X,X,cache_filter slub_debug=A,<cache-name>>
>
> > Users should pass slub_debug=A,<cache-name> anyway to prevent cache merging.
>
> It will be good to have this in case you want to test cache that is used
> early. But why push something to command line option only when it can be
> changed at runtime?
Hmm okay. I'm not against changing it writable. (it looks okay to me.)
Just wanted to understand your use case!
Can you please elaborate why booting with slub_debug=A,<your cache name>
and enabling cache_filter after boot does not work?
Or is it trying to changnig these steps,
FROM
1. booting with slub_debug=A,<cache name>
2. write to cache_filter to enable cache filtering
3. setup probability, interval, times, size
TO
1. write to failslab attribute of <cache name> (may fail it has alias)
2. write to cache_filter to enable cache filtering
3. setup probability, interval, times, size
?
as you may know, SLAB_FAILSLAB does nothing when
cache_filter is disabled, and you should pass slub_debug=A,<cache name> anyway
to prevent doing cache merging with <cache name>.
--
Thanks,
Hyeonggon
next prev parent reply other threads:[~2022-09-27 0:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-20 12:11 Alexander Atanasov
2022-09-21 11:30 ` Hyeonggon Yoo
2022-09-23 7:34 ` Alexander Atanasov
2022-09-27 0:49 ` Hyeonggon Yoo [this message]
2022-09-27 7:44 ` Alexander Atanasov
2022-09-28 15:21 ` Hyeonggon Yoo
2022-10-14 8:48 ` Vlastimil Babka
2022-10-14 8:51 ` 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=YzJIsFZQoCEYntvR@hyeyoo \
--to=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.atanasov@virtuozzo.com \
--cc=cl@linux.com \
--cc=corbet@lwn.net \
--cc=guro@fb.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=kernel@openvz.org \
--cc=linux-doc@vger.kernel.org \
--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 \
--cc=vjitta@codeaurora.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox