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>,
	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: 9p/RDMA for syzkaller (Was: BUG: corrupted list in p9_read_work)
Date: Sat, 17 Nov 2018 09:46:49 +0100	[thread overview]
Message-ID: <20181117084649.GA24182@nautica> (raw)
In-Reply-To: <20181012150855.GA22149@nautica>

Dominique Martinet wrote on Fri, Oct 12, 2018:
> Hmm, good point; I hadn't looked at the network level how this is
> emulated.
> When I use a single VM I do not see anything with tcpdump on any
> interface, so I assume the kernel short-cuts the interface in this case.
> When communicating between two machines there obviously is traffic; it
> appears to be transported over udp - I see the messages I sent in plain
> text in the dump and there is only a handful of packets for the whole
> connecting and teardown so it's definitely much simpler.
> 
> This might have some knob I am not aware of to force the driver to send
> udp in the local setup, if we can it's going to be much easier to
> reimplement the rxe emulation protocol with raw syscalls than what I was
> describing earlier...

I've taken a little bit of time to look at this.
Unfortunately, I haven't been able to find any knob to make a
single-machine setup send UDP over an interface; would have hoped that
playing with multiple interfaces might be a way around this (e.g. use
the rxe driver on one interface and listen on the udp port on the other
one), but I couldn't get this to work and don't see anything in the code
that hints it might be configurable.
It seems to realize that the remote IP is assigned locally anyway and
while I cannot "bind" to an address that wasn't added to the rxe driver
at the rdma_cm level, trying to connect to it never sends any packet to
a ncat listening on 4791/udp on that interface...
If anyone has an idea, it'd be great!

Protocole-wise, once we get that to work it doesn't look very difficult
to implement some basic "accept connection and send acks/replies" small
server, but we need the first part to work...


-- 
Dominique

  reply	other threads:[~2018-11-17  8:47 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
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 [this message]
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=20181117084649.GA24182@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=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).