Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp1411241imb; Sat, 2 Mar 2019 14:24:21 -0800 (PST) X-Google-Smtp-Source: APXvYqzzMGbmw4NAgZEnHZYl5H/8tk51VkR7XrvQzqsd/U0YXrZpaerJwgoM7asJX9Et00tU1oYw X-Received: by 2002:a17:902:7881:: with SMTP id q1mr12172754pll.301.1551565461742; Sat, 02 Mar 2019 14:24:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551565461; cv=none; d=google.com; s=arc-20160816; b=xeQlgprrGgs2e3UbaSXmiZDLadEO2rXL/g9QabYylcUCYwQy7WgD8vPLpZqxJ/tTSO AOK6N2STW/oaDjQYmrkK+JO2StxySnCChgHMhMbs8Y7MzGE3GulSi45rjwLd7M36yMpv P/tZVZe+37blZFWIchdGABvYmItvlJTCazeJSGhn+zXqxz4ZnJTSgvYu0JN0E+vEE+6e 2e3zlwupllfEevYXGyLOH0bVe8rTUPbM6yCKm02MZP5/qj2b80Zze9YL+gGOSsSwJOVi gnm8o+t0pR8jrvOeFhySDipdYH8mQhDI3Cvlj/sfJY2jmc+EafJ6/UkLj14JACP2qP8A byrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=dovG5uOCWcgYhvaJzJOM0tsh7kh+OufaS2DSOvU3Fwg=; b=ADet1fnBm1XoDoUfHe7Q/FhFDOlH2Rq8oQ4hNOKYP4jwnUrKMiWAzFmVmvInmTEnxa zAKWyGToPA5tJZ02m/jykXO1C1Aiv2aV71eGZQY9iD3JfGTdSOlScGo/QXW/cF+9xDam ZJDQgTbHyRVXnYDVKa0Tuckmz5CF4gpESR/Aw56GH0Wa94/VpYODQhLeSu+R169JlHSe C643zmsi5r/IGfcKuxm3o0YCX0sW2IcW3XMNEGqOLC7zKVUvE0F3OwNBjk2MWMuKkhVj eOvUH5K33/wAIg9+khC9SkhimcLVMwiBlLrGDAXPFFIZgNcgL5jSFacYi1VeJV76wMjg pGbg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t135si1585878pgb.467.2019.03.02.14.24.05; Sat, 02 Mar 2019 14:24:21 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726942AbfCBWXq (ORCPT + 99 others); Sat, 2 Mar 2019 17:23:46 -0500 Received: from mail-qt1-f196.google.com ([209.85.160.196]:40012 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726225AbfCBWXp (ORCPT ); Sat, 2 Mar 2019 17:23:45 -0500 Received: by mail-qt1-f196.google.com with SMTP id j36so1420331qta.7 for ; Sat, 02 Mar 2019 14:23:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=dovG5uOCWcgYhvaJzJOM0tsh7kh+OufaS2DSOvU3Fwg=; b=rQv4T24lGQ0n3OUma2QBDt1owqTBSEqZ83YQJumHw+Ym+Pmez9LTCG5aOv/s98n7hx k/pqCIUnIyVzJ7zjyBT60VDtzY2Ymj9YXHqHe5UvIg+rwf0QEnoaFqXVuZ8AHWZ0gRnk 7bZn0M76FZaQaeGyex3JqtumdwvLyuLvpqhMD6x5x02XAE+IQMiq6Ewlt5W1X/cZMmwo v16XCQYs2xWWFJ0mVpY1EY/sV1QPyKi3y+MFcex2ynYCLsZPz1ls/SLjDcgo5jWNJZ/d jMLrGGcG/kq2wa5iv3StLAWUcpSa/czpaO1qE2fYSbA1iV9FXOVsbvAa0Ra+ev6/UpYc B6rw== X-Gm-Message-State: APjAAAXaZqy1G78Xxvx+ZJaPojKz+PH9D7pQbbe0FPNDhcJGgUM7Tc/D puhil+OxMVfjthskzbm7BO4= X-Received: by 2002:aed:21c2:: with SMTP id m2mr9841943qtc.107.1551565424367; Sat, 02 Mar 2019 14:23:44 -0800 (PST) Received: from dennisz-mbp.home ([2604:2000:1406:13e:1c79:146b:53ab:5b76]) by smtp.gmail.com with ESMTPSA id n14sm1297196qtk.97.2019.03.02.14.23.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Mar 2019 14:23:43 -0800 (PST) Date: Sat, 2 Mar 2019 17:23:41 -0500 From: Dennis Zhou To: Peng Fan Cc: Tejun Heo , Christoph Lameter , Vlad Buslov , "kernel-team@fb.com" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 02/12] percpu: do not search past bitmap when allocating an area Message-ID: <20190302222341.GA1196@dennisz-mbp.home> References: <20190228021839.55779-1-dennis@kernel.org> <20190228021839.55779-3-dennis@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Mar 02, 2019 at 01:32:04PM +0000, Peng Fan wrote: > Hi Dennis, > > > -----Original Message----- > > From: owner-linux-mm@kvack.org [mailto:owner-linux-mm@kvack.org] On > > Behalf Of Dennis Zhou > > Sent: 2019年2月28日 10:18 > > To: Dennis Zhou ; Tejun Heo ; Christoph > > Lameter > > Cc: Vlad Buslov ; kernel-team@fb.com; > > linux-mm@kvack.org; linux-kernel@vger.kernel.org > > Subject: [PATCH 02/12] percpu: do not search past bitmap when allocating an > > area > > > > pcpu_find_block_fit() guarantees that a fit is found within > > PCPU_BITMAP_BLOCK_BITS. Iteration is used to determine the first fit as it > > compares against the block's contig_hint. This can lead to incorrectly scanning > > past the end of the bitmap. The behavior was okay given the check after for > > bit_off >= end and the correctness of the hints from pcpu_find_block_fit(). > > > > This patch fixes this by bounding the end offset by the number of bits in a > > chunk. > > > > Signed-off-by: Dennis Zhou > > --- > > mm/percpu.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/mm/percpu.c b/mm/percpu.c > > index 53bd79a617b1..69ca51d238b5 100644 > > --- a/mm/percpu.c > > +++ b/mm/percpu.c > > @@ -988,7 +988,8 @@ static int pcpu_alloc_area(struct pcpu_chunk *chunk, > > int alloc_bits, > > /* > > * Search to find a fit. > > */ > > - end = start + alloc_bits + PCPU_BITMAP_BLOCK_BITS; > > + end = min_t(int, start + alloc_bits + PCPU_BITMAP_BLOCK_BITS, > > + pcpu_chunk_map_bits(chunk)); > > bit_off = bitmap_find_next_zero_area(chunk->alloc_map, end, start, > > alloc_bits, align_mask); > > if (bit_off >= end) > > -- > > From pcpu_alloc_area itself, I think this is correct to avoid bitmap_find_next_zero_area > scan past the boundaries of alloc_map, so > > Reviewed-by: Peng Fan > > There are a few points I did not understand well, > Per understanding pcpu_find_block_fit is to find the first bit off in a chunk which could satisfy > the bits allocation, so bits might be larger than PCPU_BITMAP_BLOCK_BITS. And if > pcpu_find_block_fit returns a good off, it means there is a area in the chunk could satisfy > the bits allocation, then the following pcpu_alloc_area will not scan past the boundaries of > alloc_map, right? > pcpu_find_block_fit() finds the chunk offset corresponding to the block that will be able to fit the chunk. Allocations are done by first fit, so scanning begins from the first_free of a block. Because the hints are always accurate, you never fail to find a fit in pcpu_alloc_area() if pcpu_find_block_fit() gives you an offset. This means you never scan past the end anyway. Thanks, Dennis