From: Jason Gunthorpe <jgg@nvidia.com>
To: Akinobu Mita <akinobu.mita@gmail.com>,
Matthew Wilcox <willy@infradead.org>,
linux-fsdevel@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: xarray, fault injection and syzkaller
Date: Thu, 3 Nov 2022 16:09:04 -0300 [thread overview]
Message-ID: <Y2QR0EDvq7p9i1xw@nvidia.com> (raw)
Hi All,
I wonder if anyone has some thoughts on this - I have spent some time
setting up syzkaller for a new subsystem and I've noticed that nth
fault injection does not reliably cause things like xa_store() to
fail.
It seems the basic reason is that xarray will usually do two
allocations, one in an atomic context which fault injection does
reliably fail, but then it almost always follows up with a second
allocation in a non-atomic context that doesn't fail because nth has
become 0.
This reduces the available coverage that syzkaller can achieve by
randomizing fault injections. It does very rarely provoke a failure,
which I guess is because the atomic allocation fails naturally
sometimes with low probability and the nth takes out the non-atomic
allocation.. But it is rare and very annoying to reproduce.
Does anyone have some thoughts on what is an appropriate way to cope
with this? It seems like some sort of general problem with these sorts
of fallback allocations, so perhaps a GFP_ flag of some sort that
causes allows the fault injection to fail but not decrement nth?
Thanks,
Jason
next reply other threads:[~2022-11-03 19:09 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-03 19:09 Jason Gunthorpe [this message]
2022-11-03 20:00 ` xarray, fault injection and syzkaller Matthew Wilcox
2022-11-03 20:07 ` Jason Gunthorpe
2022-11-04 0:11 ` Dmitry Vyukov
2022-11-04 0:21 ` Jason Gunthorpe
2022-11-04 17:47 ` Dmitry Vyukov
2022-11-04 18:03 ` Jason Gunthorpe
2022-11-04 18:21 ` Dmitry Vyukov
2022-11-04 18:30 ` Jason Gunthorpe
2022-11-04 18:38 ` Dmitry Vyukov
2022-11-04 18:45 ` Jason Gunthorpe
2022-11-04 22:43 ` Qi Zheng
2022-11-05 12:16 ` Qi Zheng
2022-11-06 17:36 ` Dmitry Vyukov
2022-11-07 2:13 ` Qi Zheng
2022-11-07 3:31 ` [PATCH] mm: fix unexpected changes to {failslab|fail_page_alloc}.attr Qi Zheng
2022-11-07 12:42 ` Jason Gunthorpe
2022-11-07 15:05 ` Qi Zheng
2022-11-07 16:26 ` Jason Gunthorpe
2022-11-08 2:47 ` Qi Zheng
2022-11-08 3:52 ` [PATCH v2] " Qi Zheng
2022-11-08 8:44 ` Wei Yongjun
2022-11-08 8:58 ` Qi Zheng
2022-11-08 9:32 ` Wei Yongjun
2022-11-08 9:45 ` Qi Zheng
2022-11-08 12:04 ` Jason Gunthorpe
2022-11-09 3:57 ` Wei Yongjun
2022-11-08 17:36 ` Akinobu Mita
2022-11-14 3:59 ` Qi Zheng
2022-11-04 18:42 ` xarray, fault injection and syzkaller Dmitry Vyukov
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=Y2QR0EDvq7p9i1xw@nvidia.com \
--to=jgg@nvidia.com \
--cc=akinobu.mita@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=syzkaller-bugs@googlegroups.com \
--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;
as well as URLs for NNTP newsgroup(s).