Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp882356imm; Fri, 12 Oct 2018 08:11:34 -0700 (PDT) X-Google-Smtp-Source: ACcGV618v3Xv9x+AP+GR8vdHHBVZs3oJ9IXxPTA27yHM8H1vTQioJze6QmsWIuJnCxIvOfWudBQW X-Received: by 2002:a63:f744:: with SMTP id f4-v6mr5965701pgk.410.1539357094669; Fri, 12 Oct 2018 08:11:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539357094; cv=none; d=google.com; s=arc-20160816; b=D6ukFVUnpjr0eM/A8XPvNNucqTIREDJLnH/lmFDYnX9/+elFKnYHqn1rV/EPZfwxHI XHPKEThs52b0qmns4Ta3f9Ud6Tq9WBFo3vEH9HsycmQuM/EjTw6iUv3RlojT6arqYg64 JqRfFTZQpKZvSMOa66ij5tiqmtrkcBbuRC0Hv83da1EYqOLbWAhuchCXziNNrC7jlN8F 3PnLQxrF3x4ITIpSnLh8kWdEkoDtEOguhmRXfLKXKWlX7G5kaITfHbp+ntln0Tm1WheZ JxUJyx6Gg7UkVGuuTDd6JhA3NNYu0YyEvWRt1WLfeIv1tMy9tVyRuuLGBewOCs3WcAWO 1sAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=PlQPTvmOO0IKVsGYcqN6Lz03/FF3SKSdmbbO2gvt2k0=; b=MxbIqnLKCPVLc89Fx8Q47/8oeZVWCzDHVsxjCXL+9JLgvPzPaPkK05C/7SLdf2nC8M brd8yKgsmZDbO4woSYfNWldFbjHJWkUInbfFZnsFKAu+daooU8aK8RKQvspoKswygAdB jetJjYiSx0lJfdEoM5BQkF7G6ZJ9CpnyK82XJ/iXQI++D2IS7A2S0PbUhkVoyiEqevG6 wiDEV/g9xOF8YWMA0Aqp41YkKYvQMhAuA7tzhRt3L+n7CzMEq3wW5YMbey+Rm2fnvKAl 18O0PPUX0WcNd6AOaOFeZilNc+hzm8wbC2jggLic63/b1AwSLhE7K1jhMmKnTwy2iDCx GX1w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z13-v6si1335658pgc.119.2018.10.12.08.11.18; Fri, 12 Oct 2018 08:11:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729084AbeJLWmI (ORCPT + 99 others); Fri, 12 Oct 2018 18:42:08 -0400 Received: from nautica.notk.org ([91.121.71.147]:33220 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728830AbeJLWmI (ORCPT ); Fri, 12 Oct 2018 18:42:08 -0400 Received: by nautica.notk.org (Postfix, from userid 1001) id 6D95BC009; Fri, 12 Oct 2018 17:09:10 +0200 (CEST) Date: Fri, 12 Oct 2018 17:08:55 +0200 From: Dominique Martinet To: Dmitry Vyukov Cc: Leon Romanovsky , syzbot , David Miller , Eric Van Hensbergen , LKML , Latchesar Ionkov , netdev , Ron Minnich , syzkaller-bugs , v9fs-developer@lists.sourceforge.net Subject: Re: 9p/RDMA for syzkaller (Was: BUG: corrupted list in p9_read_work) Message-ID: <20181012150855.GA22149@nautica> References: <20181009020949.GA29622@nautica> <20181010144059.GA20918@nautica> <20181010155814.GC20918@nautica> <20181011131045.GA32030@nautica> <20181011141928.GB32030@nautica> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dmitry Vyukov wrote on Fri, Oct 12, 2018: > > I don't see any read on these fd despite epoll being set to wait for > > read events on these so I'm not quite sure where ibverbs knows if the > > commands worked or not, but hopefully that illustrats that it's slightly > > more complex than just socket/bind/listen/accept/write/close! :) > > Yes, it seems so. > > I guess I am still missing the big picture somewhat. > If we do "echo -n FOO > /sys/module/rdma_rxe/parameters/add" and let's > say FOO is a tun device. Does it mean that we will send/receive > packets from the tun? If yes, that would make things simpler. And do > we still need ring buffers in that case? If not and we still send/recv > via in-memory ring buffers, then why do we need tun at all? 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... > Leon, maybe you know how to setup a stub rdma that we could use as 9p > transport? If we do this, I guess it will also expose lots of > interesting rdma code paths for testing. I'm doing this on my free time atm so I can't invest too much, would love some help if you're aware of anything :) -- Dominique