linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dominique Martinet <asmadeus@codewreck.org>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Leon Romanovsky <leon@kernel.org>,
	syzbot <syzbot+2222c34dc40b515f30dc@syzkaller.appspotmail.com>,
	David Miller <davem@davemloft.net>,
	Eric Van Hensbergen <ericvh@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Latchesar Ionkov <lucho@ionkov.net>,
	netdev <netdev@vger.kernel.org>,
	Ron Minnich <rminnich@sandia.gov>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	v9fs-developer@lists.sourceforge.net
Subject: Re: BUG: corrupted list in p9_read_work
Date: Wed, 10 Oct 2018 16:40:59 +0200	[thread overview]
Message-ID: <20181010144059.GA20918@nautica> (raw)
In-Reply-To: <CACT4Y+bv5dWx0JwCzTPD3mWJRaMHOtRVcvpV5fdQ5KS7zAF_fA@mail.gmail.com>

Dmitry Vyukov wrote on Wed, Oct 10, 2018:
> How can they be faked?
> If we could create a private rdma/virtio stub instance per test
> process, then we could I think easily use that instance for 9p. But is
> it possible?

"RDMA" itself can be faked pretty easily nowadays, there's a "rxe"
driver that is soft RDMA over ethernet and can run over anything.

The problem is that you can't just give the client a file like trans fd;
you'd need to open an ""rdma socket"" (simplifying wording a bit), and
afaik there is no standard tool for it ; or rather, the problem is that
RDMA is packet based so even if there were you can't just write stuff
in a fd and hope it'll work, so you need a server.

If you're interested, 9p is trivial enough that I could provide you with
a trivial server that works like your file (just need to reimplement
something that parses header to packetize it properly; so you could
write to its stdin for example) ; that'd require some setup in the VM
(configure rxe and install that tool), but it would definitely be
possible.
What do you think ?


For virtio, I'm not as familiar with the environment so I do not know if
there are ways to fake it as easily unfortunately.

> Testing on real hardware is mostly outside of our priorities at the
> moment. I mean syzkaller itself can be run on anything, and one could
> extend descriptions to use a known rdma interface and run on a real
> hardware. But we can't afford this at the moment.

Sure, I understand that.

> As far as I understand RDMA maintainers run syzkaller on real
> hardware, but I don't know if they are up to including 9p into
> testing. +Leon

I'd be interested in knowing what kind of tests runs there :)

-- 
Dominique Martinet

  reply	other threads:[~2018-10-10 14:41 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-16  5:59 BUG: corrupted list in p9_read_work syzbot
2018-10-09  1:07 ` syzbot
2018-10-09  2:09   ` Dominique Martinet
2018-10-09  4:05     ` [PATCH 1/2] 9p/trans_fd: abort p9_read_work if req status changed Dominique Martinet
2018-10-09  4:05       ` [PATCH 2/2] 9p/trans_fd: put worker reqs on destroy Dominique Martinet
2018-10-09 13:19         ` Tomas Bortoli
2018-10-15 10:46           ` Dominique Martinet
2018-10-10 14:03     ` BUG: corrupted list in p9_read_work Dmitry Vyukov
2018-10-10 14:40       ` Dominique Martinet [this message]
2018-10-10 14:51         ` Dmitry Vyukov
2018-10-10 15:58           ` Dominique Martinet
2018-10-11 12:33             ` Dmitry Vyukov
2018-10-11 13:10               ` Dominique Martinet
2018-10-11 13:27                 ` Dmitry Vyukov
2018-10-11 13:40                   ` Dmitry Vyukov
2018-10-11 14:28                     ` 9p/RDMA for syzkaller (Was: BUG: corrupted list in p9_read_work) Dominique Martinet
2018-10-12 14:42                       ` Dmitry Vyukov
2018-10-11 14:19                   ` Dominique Martinet
2018-10-12 14:50                     ` Dmitry Vyukov
2018-10-12 15:08                       ` Dominique Martinet
2018-11-17  8:46                         ` Dominique Martinet
2018-11-20 11:20                           ` Dmitry Vyukov
2018-11-20 11:28                             ` Dominique Martinet
2018-10-10 14:29     ` BUG: corrupted list in p9_read_work Dmitry Vyukov
2018-10-10 14:48       ` Dominique Martinet
2018-10-10 14:49         ` syzbot
2018-10-10 16:00           ` Dominique Martinet
2018-10-10 16:02             ` syzbot
2018-10-10 16:10             ` Dominique Martinet
2018-10-10 16:29               ` syzbot
2018-10-10 16:36               ` Dmitry Vyukov
2018-10-10 22:55                 ` Dominique Martinet
2018-10-10 14:42     ` 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=20181010144059.GA20918@nautica \
    --to=asmadeus@codewreck.org \
    --cc=davem@davemloft.net \
    --cc=dvyukov@google.com \
    --cc=ericvh@gmail.com \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucho@ionkov.net \
    --cc=netdev@vger.kernel.org \
    --cc=rminnich@sandia.gov \
    --cc=syzbot+2222c34dc40b515f30dc@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=v9fs-developer@lists.sourceforge.net \
    /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).