Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1161799ybz; Fri, 1 May 2020 16:02:43 -0700 (PDT) X-Google-Smtp-Source: APiQypJ7b2t9BzNzq2mkAnFGiTYEQ2aHjaI+HdEJmAqG2WRtyZbSPvOOcoJCx3lvWYnLLB6yZ0Wk X-Received: by 2002:a17:906:55c4:: with SMTP id z4mr5371033ejp.353.1588374163584; Fri, 01 May 2020 16:02:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588374163; cv=none; d=google.com; s=arc-20160816; b=ekIIWr+sW5TzPeZzm4TOF5xq+JpO8IfRs3YU/kDsadNCyNqvctFquTnh0bip1QweEK aM3hkIiwLswXGhXn5IWeD0x3ZOdJuh9/3+Gc1MZC1k4oiQXfO4hKazK5sOlnqrjtA81I TJhH2iIaDzN/WhkBOeQ3wAd4UscipZpKYis3HOri9hyDiMtrJnZj81ibazGGZClFkVY2 g4ZePQ4DdMFkKTKmdbzx1sdXZr9W/a+Q6fhLPX5fo7hPv7ZIAzRfarE6JqMgHhuIasr+ YW7M2owecDypPridRHeTi/9eeRDYwTgMRrK58EE09O9NkHrzYkGCEgzi+TllptA3AEVI 4Thw== 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-disposition:mime-version:references:reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=iJq/HXoLXNZA0ZBzGlr3Z7P0Dp6bfFk0S/RkKGhMhm8=; b=Du6r9pQDe87jFXOYdgSUmdmOUGbzsD1ojYEKlJCRXxRHbh0lh/1BitG4Q9MwbRqOyq mfBHxcfxHOvauxyPVroaAqoosMQLanBKYDbQhLpgjrpYvNaHAo9bK+0NlkeTLbe1LBTB +bKNolpnRQMK4oDxN/IEZRYcfWKEe5p5S5INKSY5HBMa8db8F449QbyZLbKKBbJuvvO9 YZYflYH5xYt93lF7wDTAonxlNolyaN6K0zZVJEGogGd1yam3XU7Jud3oJKCRpFz4cJYu szfkjGpM+jaxXOHROmr6IBxXNvAN3syPSFQAHTEw2g4kWqHGXKioNB2JdVW9yj3i69Yx trNw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=lWrP9NNe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p62si2253730edp.385.2020.05.01.16.02.19; Fri, 01 May 2020 16:02:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=lWrP9NNe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726554AbgEAXAx (ORCPT + 99 others); Fri, 1 May 2020 19:00:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:51846 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726045AbgEAXAx (ORCPT ); Fri, 1 May 2020 19:00:53 -0400 Received: from paulmck-ThinkPad-P72.home (50-39-105-78.bvtn.or.frontiernet.net [50.39.105.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5EA22216FD; Fri, 1 May 2020 23:00:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588374052; bh=/VNzG6AkJ+SF4n242b/HlctCnNZjDVdY4zeOfMiCbSU=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=lWrP9NNeusUD0yK9zSglDcn3WrvF77Ru32i29rUQ2BVDLrenBfrSi+BLTAoOvlqFY ile7EkxM6bBouE8PxX60i/1rjJHagdEwEHZSiioF25nNFWwgHe0NGZolGZkdbD0CQK G+Llt52Ga4lVM7soTlu9h3lLGFZwPvWFqKd+szZw= Received: by paulmck-ThinkPad-P72.home (Postfix, from userid 1000) id 310B83522B72; Fri, 1 May 2020 16:00:52 -0700 (PDT) Date: Fri, 1 May 2020 16:00:52 -0700 From: "Paul E. McKenney" To: "Uladzislau Rezki (Sony)" Cc: LKML , linux-mm@kvack.org, Andrew Morton , "Theodore Y . Ts'o" , Matthew Wilcox , Joel Fernandes , RCU , Oleksiy Avramchenko Subject: Re: [PATCH 20/24] rcu/tree: Make kvfree_rcu() tolerate any alignment Message-ID: <20200501230052.GG7560@paulmck-ThinkPad-P72> Reply-To: paulmck@kernel.org References: <20200428205903.61704-1-urezki@gmail.com> <20200428205903.61704-21-urezki@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200428205903.61704-21-urezki@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 28, 2020 at 10:58:59PM +0200, Uladzislau Rezki (Sony) wrote: > From: "Joel Fernandes (Google)" > > Handle cases where the the object being kvfree_rcu()'d is not aligned by > 2-byte boundaries. > > Signed-off-by: Uladzislau Rezki (Sony) > Signed-off-by: Joel Fernandes (Google) > --- > kernel/rcu/tree.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > index 501cac02146d..649bad7ad0f0 100644 > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -2877,6 +2877,9 @@ struct kvfree_rcu_bulk_data { > #define KVFREE_BULK_MAX_ENTR \ > ((PAGE_SIZE - sizeof(struct kvfree_rcu_bulk_data)) / sizeof(void *)) > > +/* Encoding the offset of a fake rcu_head to indicate the head is a wrapper. */ > +#define RCU_HEADLESS_KFREE BIT(31) Did I miss the check for freeing something larger than 2GB? Or is this impossible, even on systems with many terabytes of physical memory? Even if it is currently impossible, what prevents it from suddenly becoming all too possible at some random point in the future? If you think that this will never happen, please keep in mind that the first time I heard "640K ought to be enough for anybody", it sounded eminently reasonable to me. Besides... Isn't the offset in question the offset of an rcu_head struct within the enclosing structure? If so, why not keep the current requirement that this be at least 16-bit aligned, especially given that some work is required to make that alignment less than pointer sized? Then you can continue using bit 0. This alignment requirement is included in the RCU requirements documentation and is enforced within the __call_rcu() function. So let's leave this at bit 0. Thanx, Paul > /** > * struct kfree_rcu_cpu_work - single batch of kfree_rcu() requests > * @rcu_work: Let queue_rcu_work() invoke workqueue handler after grace period > @@ -3078,9 +3081,9 @@ static void kfree_rcu_work(struct work_struct *work) > next = head->next; > > /* We tag the headless object, if so adjust offset. */ > - headless = (((unsigned long) head - offset) & BIT(0)); > + headless = !!(offset & RCU_HEADLESS_KFREE); > if (headless) > - offset -= 1; > + offset &= ~(RCU_HEADLESS_KFREE); > > ptr = (void *) head - offset; > > @@ -3356,7 +3359,7 @@ void kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func) > * that has to be freed as well as dynamically > * attached wrapper/head. > */ > - func = (rcu_callback_t) (sizeof(unsigned long *) + 1); > + func = (rcu_callback_t)(sizeof(unsigned long *) | RCU_HEADLESS_KFREE); > } > > head->func = func; > -- > 2.20.1 >