From: Kent Overstreet <kent.overstreet@linux.dev>
To: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>,
Dave Chinner <david@fromorbit.com>,
Matthew Wilcox <willy@infradead.org>,
lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-block@vger.kernel.org,
linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-nvme@lists.infradead.org,
Kent Overstreet <kent.overstreet@gmail.com>
Subject: Re: [LSF/MM/BPF TOPIC] Removing GFP_NOFS
Date: Thu, 8 Feb 2024 17:45:02 -0500 [thread overview]
Message-ID: <4qc7h3gun5lkv3p5piftgkhgmlbrgqteut3vxtjrme47kyn7q7@62ogk3chsrme> (raw)
In-Reply-To: <3aa399bb-5007-4d12-88ae-ed244e9a653f@kernel.org>
On Thu, Feb 08, 2024 at 08:55:05PM +0100, Vlastimil Babka (SUSE) wrote:
> - NOWAIT - as said already, we need to make sure we're not turning an
> allocation that relied on too-small-to-fail into a null pointer exception or
> BUG_ON(!page). It's probably not feasible to audit everything that can be
> called underneath when adding a new scoped NOWAIT. Static analysis probably
> won't be powerful enough as well. Kent suggested fault injection [1]. We
> have the framework for a system-wide one but I don't know if anyone is
> running it and how successful it is.
I've also got a better fault injection library in the pipeline - I'll be
posting it after memory allocation profiling is merged, since that has
the library code needed for the new fault injection.
The new stuff gives us (via the same hooks for memory allocation
profiling), per callsite individually controllable injection points -
which means it's way easier to inject memory allocation failures into
existing tests and write tests that cover a specific codepath.
e.g. what I used to do with this code was flip on random memory
allocation failures for all code in fs/bcachefs/ after mounting, and I
had every test doing that (at one point in time, bcachefs could handle
_any_ allocation failure after startup without reporting an error to
userspace, but sadly not quite anymore).
that, plus code coverage analysis should make this pretty tractable.
next prev parent reply other threads:[~2024-02-08 22:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-04 21:17 Matthew Wilcox
2024-01-05 10:13 ` Viacheslav Dubeyko
2024-01-05 10:26 ` [Lsf-pc] " Jan Kara
2024-01-05 14:17 ` Viacheslav Dubeyko
2024-01-05 14:35 ` Vlastimil Babka (SUSE)
2024-01-05 10:57 ` [Lsf-pc] " Jan Kara
2024-01-08 11:47 ` Johannes Thumshirn
2024-01-08 17:39 ` David Sterba
2024-01-09 7:43 ` Johannes Thumshirn
2024-01-09 22:23 ` Dave Chinner
2024-01-09 15:47 ` Luis Henriques
2024-01-09 18:04 ` Johannes Thumshirn
2024-01-08 6:39 ` Dave Chinner
2024-01-09 4:47 ` Dave Chinner
2024-02-08 16:02 ` Vlastimil Babka (SUSE)
2024-02-08 17:33 ` Michal Hocko
2024-02-08 19:55 ` Vlastimil Babka (SUSE)
2024-02-08 22:45 ` Kent Overstreet [this message]
2024-02-12 1:20 ` Dave Chinner
2024-02-12 2:06 ` Kent Overstreet
2024-02-12 4:35 ` Dave Chinner
2024-02-12 19:30 ` Kent Overstreet
2024-02-12 22:07 ` Dave Chinner
2024-01-09 22:44 ` Dave Chinner
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=4qc7h3gun5lkv3p5piftgkhgmlbrgqteut3vxtjrme47kyn7q7@62ogk3chsrme \
--to=kent.overstreet@linux.dev \
--cc=david@fromorbit.com \
--cc=kent.overstreet@gmail.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mhocko@suse.com \
--cc=vbabka@kernel.org \
--cc=willy@infradead.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