From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4C06A3546E2 for ; Mon, 10 Aug 2026 03:22:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786332124; cv=none; b=Y1m+GRUnQRSfDyRRpQ9z+08pb+31t5GstA5Tg68LMu/X7CaEfA0KJck9nn2O2Gmqfxm6IZUmlRn7Ber7mZo5/zqSnZC0EWbJHRbGBrS0AzfY0wYHwh3N/Zyv4MyGCKwB51thashZEbCfVrCxjlp7SLk6SpOKmTT6uWNrRUCT2io= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786332124; c=relaxed/simple; bh=Y4YT6X+eq060H7yWCbvxNnP6ZYaEPkieOLlpCns9NIo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=I6E9jasbUTIi7BmxxpRC3rppEbi6co3Y7RqLg6hHIg7vvxmf4rDFpNef64VvRaXEcqHgjLUftgqheu3IwJOLEwiszQP1vVz0/26CyyrBdcigXr+zpRh74BsvfruFf1U5qANNnzHfeUcfY3QcerxdVu4ITbdftxYdGct9uJJQUUw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=XMg7xexI; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="XMg7xexI" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=8TjGFoXlF/ytQT8rm9ADFZepaiWE5JQy8cHAE80+I10=; b=XMg7xexIOJkI5TFBsySMXeHs0f uSLNSaM0LZLiWWkWqV6GKiEQL5m+UaP7o8gMkF5n+o7h31jMIisallq5RdyACr5B/njvuP57uLb9O +TN0+aPkCwnF4SA3+OiNwRlAzE95i1b59KYuGdtDfvs198uc468Ss4YKCRVGwzfx/JClozTepM6zG /14nwnkjB3IxUpRuOXg9dY0tPH3qyQlmAY0d1WZNSEg5eSMspoqIPH2HF7wayf+XQ0AUAQTefXRDu zGPXqS+Ct99EuxOADe4+2LG5w0YUV0VSkDEE1ex49ZQmVLgBWP5RUSEjbUyyP2bslaGG8Y5DM41C1 pc/2YTow==; Received: from willy by casper.infradead.org with local (Exim 4.99.1 #2 (Red Hat Linux)) id 1wtGaH-0000000ABz8-0sTb; Mon, 10 Aug 2026 03:21:53 +0000 Date: Mon, 10 Aug 2026 04:21:53 +0100 From: Matthew Wilcox To: Andrew Morton Cc: Longlong Xia , Mike Rapoport , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Longlong Xia Subject: Re: [PATCH 1/1] mm/mm_init: compute hash mask with unsigned arithmetic Message-ID: References: <20260809123119.3811851-1-xialonglong2025@163.com> <20260809181400.148e68eff30394f6b029f4d1@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260809181400.148e68eff30394f6b029f4d1@linux-foundation.org> On Sun, Aug 09, 2026 at 06:14:00PM -0700, Andrew Morton wrote: > > >> Use an unsigned literal so the mask is computed with unsigned > > >> arithmetic. Supported compiler settings already produce the same > > >> result, so this is a source-level cleanup with no functional change. > > > If complier already takes care of this then why do we want this patch? > > > > Fair point. Since supported compilers already produce the intended > > result and this patch has no functional impact, the benefit is only > > making the unsigned arithmetic explicit. So please disregard this patch. > > It's a very small thing, but I believe the patch improves the code. > > I mean, we erroneously compute a large negative number then subtract 1 > from it then copy that larger negative number into a signed scalar. That is an erroneous description of this code. 1 << 31 is the largest-magnitude negative number, ie it's INT_MIN. We then subtract one from it, so it wraps back around to INT_MAX. So the number assigned to *_hash_mask is always positive. > The copied bit pattern happens to be what we'd have got if the code had > been correct, but the code isn't correct! The code is correct as long as we compile with -fwrapv or whatever that got renamed to. And I don't see that changing.