From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 6910B2BD4 for ; Fri, 1 Apr 2016 17:59:37 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP; 01 Apr 2016 08:59:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,427,1455004800"; d="scan'208";a="77372178" Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by fmsmga004.fm.intel.com with ESMTP; 01 Apr 2016 08:59:36 -0700 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.174]) by IRSMSX151.ger.corp.intel.com ([169.254.4.72]) with mapi id 14.03.0248.002; Fri, 1 Apr 2016 16:59:34 +0100 From: "Burakov, Anatoly" To: "Burakov, Anatoly" , Thomas Monjalon CC: "dev@dpdk.org" , "david.verbeiren@gmail.com" Thread-Topic: [dpdk-dev] [PATCH] ivshmem: avoid infinite loop when concatenating adjacent segments Thread-Index: AQHRjCDcVQzmqUgQmkq7FI/uBNvi5591MguggAATfQA= Date: Fri, 1 Apr 2016 15:59:33 +0000 Message-ID: References: <1450564772-20000-1-git-send-email-david.verbeiren@intel.com> <3289545.8FCtugvDy0@xps13> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZTg3MTVlYzYtMGNjMi00ZTE4LTliMGEtYzFiOTI0MjRhZWQ0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImJHZ2RoK2NUVk53bW5cL3I5ZDg2RTl4RTFROTQ3YmJpeFBWTDNcL0w3Y1pBRT0ifQ== x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] ivshmem: avoid infinite loop when concatenating adjacent segments X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 15:59:37 -0000 > > Please Anatoly, > > What do you think of this patch? > > > > 2015-12-19 23:39, David Verbeiren: > > > This patch aligns the logic used to check for the presence of > > > adjacent segments in has_adjacent_segments() with the logic used in > > > cleanup_segments() when actually deciding to concatenate or not a > > > pair of segments. > > > > > > This fixes an infinite loop that happened when segments where > > > adjacent in their physical or virtual addresses but not in their > > > ioremap > > > addresses: has_adjacent_segments() reported the presence of adjacent > > > segments while cleanup_segments() was not considering them for > > > concatenation, resulting in an infinite loop since the result of > > > has_adjacent_segments() is used in the decision to continue looping > > > in cleanup_segments(). > > > > > > Signed-off-by: David Verbeiren >=20 > Yes, looking back on this, it made no sense. Or rather it did make some > twisted sense, but led to a bug. So, >=20 > Acked-by: Anatoly Burakov >=20 >=20 Actually, scratch that. I think additional changes are needed. This patch i= s OK, but it is incomplete and introduces a different bug. If the segments aren't aren't fully adjacent, that would still cause "overl= aps" to be non-zero since it expects everything to be >=3D start and < end.= If start1 =3D=3D start2, that segment is both adjacent and overlapping. So= in order to avoid throwing errors when not fully adjacent, but not overlap= ping, segments are present, we need to also fix the overlapping() function = to report only overlaps and not adjacency. Thanks, Anatoly