From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752481AbdDMIID (ORCPT ); Thu, 13 Apr 2017 04:08:03 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:37868 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751003AbdDMIH6 (ORCPT ); Thu, 13 Apr 2017 04:07:58 -0400 Subject: Re: [PATCH 2/6] locking: Introduce range reader/writer lock To: Davidlohr Bueso References: <20170406084620.22700-1-dave@stgolabs.net> <20170406084620.22700-3-dave@stgolabs.net> <2a5c78b9-23ac-3b81-71ee-6a88b965f859@linux.vnet.ibm.com> <20170406165039.GA30318@linux-80c1.suse> Cc: mingo@kernel.org, peterz@infradead.org, akpm@linux-foundation.org, jack@suse.cz, kirill.shutemov@linux.intel.com, mhocko@suse.com, mgorman@techsingularity.net, linux-kernel@vger.kernel.org, Davidlohr Bueso From: Laurent Dufour Date: Thu, 13 Apr 2017 10:07:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170406165039.GA30318@linux-80c1.suse> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17041308-0040-0000-0000-0000036825AF X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17041308-0041-0000-0000-000024F1EFD9 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-13_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704130066 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/04/2017 18:50, Davidlohr Bueso wrote: > On Thu, 06 Apr 2017, Laurent Dufour wrote: > >> How is 'seqnum' wrapping handled here ? >> I'd rather see something like time_before() here, isn't it ? > > Its a 64bit counter, no overflows. I should have miss something, what prevents this 64bit counter to not overflow ? At some point of time, this counter could reach ~0UL and then 0UL, which is breaking this check.