Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756860AbZAXSmR (ORCPT ); Sat, 24 Jan 2009 13:42:17 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754592AbZAXSl5 (ORCPT ); Sat, 24 Jan 2009 13:41:57 -0500 Received: from ovro.ovro.caltech.edu ([192.100.16.2]:44070 "EHLO ovro.ovro.caltech.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754281AbZAXSl4 (ORCPT ); Sat, 24 Jan 2009 13:41:56 -0500 Date: Sat, 24 Jan 2009 10:41:54 -0800 From: Ira Snyder To: Rusty Russell Cc: linux-kernel@vger.kernel.org, Mark McLoughlin , netdev@vger.kernel.org, "David S. Miller" Subject: Re: [PATCH] virtio_net: use correct accessors for scatterlists Message-ID: <20090124184154.GA18513@ovro.caltech.edu> Mail-Followup-To: Rusty Russell , linux-kernel@vger.kernel.org, Mark McLoughlin , netdev@vger.kernel.org, "David S. Miller" References: <20090124001053.GA20156@ovro.caltech.edu> <200901250010.11434.rusty@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200901250010.11434.rusty@rustcorp.com.au> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (ovro.ovro.caltech.edu); Sat, 24 Jan 2009 10:41:56 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2726 Lines: 60 On Sun, Jan 25, 2009 at 12:10:10AM +1030, Rusty Russell wrote: > On Saturday 24 January 2009 10:40:53 Ira Snyder wrote: > > Without this fix, virtio_net makes incorrect usage of scatterlists. It sets > > the end of the scatterlist chain after the first element, despite the fact > > that more entries come after it. > > Yes, but shouldn't you also be doing sg_mark_end() here somewhere if we're > going to use this new sg mechanism? > sg_init_table() and sg_init_one() have an sg_mark_end() inside them, so the scatterlists are terminated at their last entry. In the only case where the scatterlist has a single entry, we use sg_init_one(), which is terminated correctly. In all other cases, we use skb_to_sgvec(), which calls sg_mark_end(). In other words, they're all magically terminated at the right place. I didn't even think about it until you mentioned it, but I just verified that in every case, they get terminated correctly. So the patch is ok as-is. The only reason they can't be terminated early is that the for_each_sg() loop in arch/x86/kernel/pci-nommu.c nommu_map_sg() gets a null pointer for s, and then we oops. It doesn't check that the scatterlist ended early. I'd argue that it is the definition of for_each_sg() that is wrong, because it doesn't check for sg == NULL, which sg_next() returns when you reach the end of the chain. I don't want to be changing core kernel code, though. > I despise the new scatterlist magic chaining no-typesafety crap too much to get around to doing the Right Thing, which is to change vq_ops->add_buf to take two (terminated) scatterlists instead of a sg array and two numbers. > I didn't want to change the API. I'm comfortable with how virtio_net works, but I haven't even tried to understand virtio_console or virtio_blk yet. The main problem I've run into is that the scatterlists are allocated on the stack. Since I'm trying to do DMA transfers, I run dma_map_sg() on them in add_buf(), and then I need to run dma_unmap_sg() on them in get_buf(), after the DMA has completed. I've resorted to making copies of the scatterlists. Also, I have no idea how get()/set(), get_status()/set_status(), and get_features()/finalize_features() are supposed to work. I'm going to try and hook up two instances of virtio_net in memory, and see if I can get them to communicate. Any pointers on that? :) > But if you want to look at that... :) Maybe later. I need to get something working first. Thanks for the input. Ira -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/