linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Akinobu Mita <akinobu.mita@gmail.com>,
	linux-fsdevel@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Re: xarray, fault injection and syzkaller
Date: Thu, 3 Nov 2022 17:07:46 -0300	[thread overview]
Message-ID: <Y2QfkszbNaI297nl@nvidia.com> (raw)
In-Reply-To: <Y2Qd2dBqpOXuJm22@casper.infradead.org>

On Thu, Nov 03, 2022 at 08:00:25PM +0000, Matthew Wilcox wrote:
> On Thu, Nov 03, 2022 at 04:09:04PM -0300, Jason Gunthorpe wrote:
> > 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.
> 
> Hahaha.  I didn't intentionally set out to thwart memory allocation
> fault injection.  Realistically, do we want it to fail though?
> GFP_KERNEL allocations of small sizes are supposed to never fail.
> (for those not aware, node allocations are 576 bytes; typically the slab
> allocator bundles 28 of them into an order-2 allocation).

I don't know, I have code to handle these failures, I want to test it
:)

> I think a simple solution if we really do want to make allocations fail
> is to switch error injection from "fail one allocation per N" to "fail
> M allocations per N".  eg, 7 allocations succeed, 3 allocations fail,
> 7 succeed, 3 fail, ...  It's more realistic because you do tend to see
> memory allocation failures come in bursts.

The systemic testing I've setup just walks nth through the entire
range until it no longer triggers. This hits every injection point and
checks the failure path of it. This is also what syzkaller does
automatically from what I can tell

If we make it probabilistic it is harder to reliably trigger these
fault points.

Jason

  reply	other threads:[~2022-11-03 20:10 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-03 19:09 xarray, fault injection and syzkaller Jason Gunthorpe
2022-11-03 20:00 ` Matthew Wilcox
2022-11-03 20:07   ` Jason Gunthorpe [this message]
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=Y2QfkszbNaI297nl@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).