From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755112AbcIFFgP (ORCPT ); Tue, 6 Sep 2016 01:36:15 -0400 Received: from mail-bl2nam02on0127.outbound.protection.outlook.com ([104.47.38.127]:63902 "EHLO NAM02-BL2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752190AbcIFFgO (ORCPT ); Tue, 6 Sep 2016 01:36:14 -0400 From: KY Srinivasan To: Greg KH , Stephen Rothwell CC: Arnd Bergmann , David Miller , Networking , "linux-next@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Stephen Hemminger , Vitaly Kuznetsov Subject: RE: linux-next: manual merge of the char-misc tree with the net-next tree Thread-Topic: linux-next: manual merge of the char-misc tree with the net-next tree Thread-Index: AQHSB0Kwab156iSbA0W93lgU29XqDqBqxDyAgAEtPMA= Date: Tue, 6 Sep 2016 05:36:10 +0000 Message-ID: References: <20160905165650.180e6c89@canb.auug.org.au> <20160905113353.GB27586@kroah.com> In-Reply-To: <20160905113353.GB27586@kroah.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kys@microsoft.com; x-originating-ip: [61.3.28.83] x-ms-office365-filtering-correlation-id: 29a0438f-eb3e-4553-38c8-08d3d617b532 x-microsoft-exchange-diagnostics: 1;BY2PR0301MB2103;6:htvuPKkEwrMnQL4sZW5NnbIGSOLBEGdd9F0Y0G+4uZUF9rd4GfJFJOxd1QZZ9rHOHnMnlRamEqsApTvaFd5YkSCU838lXKH1QsOHrGDSzXJRFACABFIgYE36WmpWZwDIY3S5+kSqncI4y1KRuM/lOQDb30RPvnZb3iUNeRP2701BN876iApw6AS4PCqG+7j7+eqr5Vjm4dXms+zvSvySyVq0kobostYgwzTgKy0qbq3FPNi2jADe1hg7ZjElu7vrJC3qLaxIilJlSfBVdnZlVsDlocD/fcUaVhyiDiQSaO/LNUtfTF/1OChthuXVH1vK7xAG4M+4qf4eC7TCUtX2AQ==;5:TMubxwFHWwpE/ZuBfUcaRZ0UGbWg+A3h4KpenvzO0yYUnBAN2Bg4H7K/8lSJM2jgdJIL06rvAAxlD8Kyuw7CtKs/ffVGmZ4Y7TFie0rl6tVY1F7d26KzNlUn7lW4bxH5Q8Wevlu84aAlCSX3brCrdw==;24:eiolAwKgqO91b7gsrKwZYltqToj0B/cvlTU0KEpHwQ5Jn3axZqyg0XOulGFcZCZYMqQAS6z8jm5hLgFpjpfrQStazbGScTpdQutNeLfd3ig=;7:JPOFxnOqySNbYTrZbCXxyoaK5/hQmoJ7BZ6Oah8+5zGer5WLRK7+0tMvF8/Prx7RhtoXc/pj0u84ACj2O+OsHMk3pm4G0jWQqHeinLlzsy/g6dSQZg1r4Yjx/iDorzgJKW0xtFjj4OCKrTi4QY4ErWKYqNgyyp2wV0u2dzJCd4hWTGr1OPjNJANTTaQlMh71jYyF+UPQXByI0oQkmw2u6SrjjmYwCFL+2PuZ6HHCFOwGRg9fzCMnlQwerCuKh8jW x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB2103; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(9452136761055); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038);SRVR:BY2PR0301MB2103;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB2103; x-forefront-prvs: 0057EE387C x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(13464003)(189002)(199003)(24454002)(377454003)(53754006)(74316002)(68736007)(305945005)(5005710100001)(19580405001)(19580395003)(33656002)(5660300001)(2900100001)(5001770100001)(2950100001)(97736004)(7846002)(6116002)(2906002)(3846002)(102836003)(101416001)(4326007)(9686002)(7696003)(7736002)(586003)(76576001)(76176999)(3660700001)(50986999)(54356999)(86612001)(87936001)(8990500004)(189998001)(8936002)(86362001)(77096005)(92566002)(66066001)(3280700002)(106356001)(106116001)(99286002)(5002640100001)(10290500002)(10400500002)(105586002)(122556002)(10090500001)(81156014)(11100500001)(81166006)(8676002);DIR:OUT;SFP:1102;SCL:1;SRVR:BY2PR0301MB2103;H:DM2PR0301MB0783.namprd03.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2016 05:36:10.0993 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB2103 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id u865aKR2005514 > -----Original Message----- > From: Greg KH [mailto:greg@kroah.com] > Sent: Monday, September 5, 2016 5:04 PM > To: Stephen Rothwell > Cc: Arnd Bergmann ; David Miller ; > Networking ; linux-next@vger.kernel.org; linux- > kernel@vger.kernel.org; Stephen Hemminger ; > Vitaly Kuznetsov ; KY Srinivasan > Subject: Re: linux-next: manual merge of the char-misc tree with the net-next > tree > > On Mon, Sep 05, 2016 at 04:56:50PM +1000, Stephen Rothwell wrote: > > Hi all, > > > > Today's linux-next merge of the char-misc tree got a conflict in: > > > > include/linux/hyperv.h > > > > between commit: > > > > 30d1de08c87d ("hv_netvsc: make inline functions static") > > > > from the net-next tree and commit: > > > > bb08d431a914 ("Drivers: hv: ring_buffer: count on wrap around mappings in > get_next_pkt_raw()") > > > > from the char-misc tree. > > > > I fixed it up (the former moved the code modified by the latter, so the > > below patch applies to the new location of the code) and can carry the > > fix as necessary. This is now fixed as far as linux-next is concerned, > > but any non trivial conflicts should be mentioned to your upstream > > maintainer when your tree is submitted for merging. You may also want > > to consider cooperating with the maintainer of the conflicting tree to > > minimise any particularly complex conflicts. > > > > From: Stephen Rothwell > > Date: Mon, 5 Sep 2016 16:53:06 +1000 > > Subject: [PATCH] Drivers: hv: ring_buffer: merge fix up for "hv_netvsc: make > > inline functions static" > > > > Signed-off-by: Stephen Rothwell > > --- > > drivers/net/hyperv/netvsc.c | 32 +++++++++++--------------------- > > 1 file changed, 11 insertions(+), 21 deletions(-) > > > > diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c > > index 2a9ccc4d9e3c..026df6556068 100644 > > --- a/drivers/net/hyperv/netvsc.c > > +++ b/drivers/net/hyperv/netvsc.c > > @@ -42,31 +42,23 @@ static struct vmpacket_descriptor * > > get_next_pkt_raw(struct vmbus_channel *channel) > > { > > struct hv_ring_buffer_info *ring_info = &channel->inbound; > > - u32 read_loc = ring_info->priv_read_index; > > + u32 priv_read_loc = ring_info->priv_read_index; > > void *ring_buffer = hv_get_ring_buffer(ring_info); > > - struct vmpacket_descriptor *cur_desc; > > - u32 packetlen; > > u32 dsize = ring_info->ring_datasize; > > - u32 delta = read_loc - ring_info->ring_buffer->read_index; > > + /* > > + * delta is the difference between what is available to read and > > + * what was already consumed in place. We commit read index after > > + * the whole batch is processed. > > + */ > > + u32 delta = priv_read_loc >= ring_info->ring_buffer->read_index ? > > + priv_read_loc - ring_info->ring_buffer->read_index : > > + (dsize - ring_info->ring_buffer->read_index) + priv_read_loc; > > u32 bytes_avail_toread = (hv_get_bytes_to_read(ring_info) - delta); > > > > if (bytes_avail_toread < sizeof(struct vmpacket_descriptor)) > > return NULL; > > > > - if ((read_loc + sizeof(*cur_desc)) > dsize) > > - return NULL; > > - > > - cur_desc = ring_buffer + read_loc; > > - packetlen = cur_desc->len8 << 3; > > - > > - /* > > - * If the packet under consideration is wrapping around, > > - * return failure. > > - */ > > - if ((read_loc + packetlen + VMBUS_PKT_TRAILER) > (dsize - 1)) > > - return NULL; > > - > > - return cur_desc; > > + return ring_buffer + priv_read_loc; > > } > > > > /* > > @@ -78,16 +70,14 @@ static void put_pkt_raw(struct vmbus_channel > *channel, > > struct vmpacket_descriptor *desc) > > { > > struct hv_ring_buffer_info *ring_info = &channel->inbound; > > - u32 read_loc = ring_info->priv_read_index; > > u32 packetlen = desc->len8 << 3; > > u32 dsize = ring_info->ring_datasize; > > > > - BUG_ON((read_loc + packetlen + VMBUS_PKT_TRAILER) > dsize); > > - > > /* > > * Include the packet trailer. > > */ > > ring_info->priv_read_index += packetlen + VMBUS_PKT_TRAILER; > > + ring_info->priv_read_index %= dsize; > > } > > > > /* > > Ugh, messy. Thanks for this. > > KY, how did this happen? Thanks Stephen. Greg, sorry about this. We should have split Vitaly's patch to avoid this inter-tree issue. Vitaly and I will work to fix this. Regards, K. Y > > greg k-h