Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965051AbeAKQgs (ORCPT + 1 other); Thu, 11 Jan 2018 11:36:48 -0500 Received: from shards.monkeyblade.net ([184.105.139.130]:39672 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964795AbeAKQgq (ORCPT ); Thu, 11 Jan 2018 11:36:46 -0500 Date: Thu, 11 Jan 2018 11:36:44 -0500 (EST) Message-Id: <20180111.113644.936229336500292786.davem@davemloft.net> To: ross.lagerwall@citrix.com Cc: xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, jgross@suse.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] xen-netfront: Fix race between device setup and open From: David Miller In-Reply-To: <0650f0ec-51ce-70ee-cd8a-6620f0c9eea8@citrix.com> References: <20180111.110810.1332044409040498618.davem@davemloft.net> <0650f0ec-51ce-70ee-cd8a-6620f0c9eea8@citrix.com> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Thu, 11 Jan 2018 08:36:46 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: From: Ross Lagerwall Date: Thu, 11 Jan 2018 16:27:20 +0000 > On 01/11/2018 04:08 PM, David Miller wrote: >> From: Ross Lagerwall >> Date: Thu, 11 Jan 2018 15:49:07 +0000 >> >>> I've now added CC'd netdev on the other two. >> That doesn't work. >> If you don't post the originals explicitly to netdev then it won't >> get properly queued in patchwork. >> > > The series fixes two crashes when using netfront. The first is > actually fixed in Xen common code, not netfront, which is why I only > CC'd netdev on the second. I can resend the originals to netdev if you > want but IMO it is not necessary. Everyone who reviews the networking side will appreciate the full context of the patch series so they can review the networking part in proper context. And if it is decided that these changes should go via my GIT tree wouldn't you want it to be all setup properly for that already without having to do anything more on your part? I don't see what the resistence is to giving people more information and allowing more flexibility for integrating and reviewing your work.