From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D137723C4F6 for ; Tue, 22 Jul 2025 09:48:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753177702; cv=none; b=Jx9CSH6qbXp9mdLhKqmGEho9sBMNxFwVEsSSoNJh1gtCKmRbYhd240qTUHUqf8RfAVA/B2hVHHfHt8RZdbDyOZzr/yiu6Bu4TdP7u2jjztWkMueVxnAmFyCkK1m1q5bIuJOvehqkAYoCv9fV7+V/UQjkpewETrzijLJlfA0fzYo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753177702; c=relaxed/simple; bh=dVcikr205Ak80qRUlwLt6JjiveksBUipnmRSJ08H5Go=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JjA2WLZas9ro5I9pOm/tTh6qbMbztRK8wBcSNC+CHKYui5X6QQJP5h2TcjJCROBnwy3P2Mv5I9Nrsz1wXgiF8ok/Lxu/BS5jWBa/XUW2fg0ds4tZ1LJunrtABKapBG4MytftGxVUx+9oREP94UnUpjourlNMEshXTYXcgxuz/3s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AF0A2152B; Tue, 22 Jul 2025 02:48:13 -0700 (PDT) Received: from J2N7QTR9R3 (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 86D623F66E; Tue, 22 Jul 2025 02:48:17 -0700 (PDT) Date: Tue, 22 Jul 2025 10:48:12 +0100 From: Mark Rutland To: Uros Bizjak Cc: Andrew Morton , linux-kernel@vger.kernel.org, "Eric W. Biederman" , Sebastian Andrzej Siewior , "Paul E. McKenney" , Alexey Gladkov , Roman Gushchin , MengEn Sun , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= Subject: Re: [PATCH RESEND v2 1/2] ucount: Fix atomic_long_inc_below() argument type Message-ID: References: <20250721174610.28361-1-ubizjak@gmail.com> <20250721154325.476b87e09aa5d778bcead478@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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Jul 22, 2025 at 08:44:29AM +0200, Uros Bizjak wrote: > On Tue, Jul 22, 2025 at 12:43 AM Andrew Morton > wrote: > > > > On Mon, 21 Jul 2025 19:45:57 +0200 Uros Bizjak wrote: > > > > > The type of u argument of atomic_long_inc_below() should be long > > > to avoid unwanted truncation to int. > > > > > > Fixes: f9c82a4ea89c ("Increase size of ucounts to atomic_long_t") > > > > Please (always!) provide a description of the userspace-visible effects > > of the bug. That way I (and others) can decide whether the fix should > > be backported. And people will be able to determine whether this patch > > may fix problems which they are observing. Thanks. > > The patch fixes the wrong argument type of an internal function to > prevent unwanted argument truncation. It fixes an internal locking > primitive; it should not have any direct effect on userspace. AFAICT there's no problem in practice because atomic_long_inc_below() is only used by inc_ucount(), and it looks like the value is constrained between 0 and INT_MAX. In inc_ucount() the limit value is taken from user_namespace::ucount_max[], and AFAICT that's only written by sysctls, to the table setup by setup_userns_sysctls(), where UCOUNT_ENTRY() limits the value between 0 and INT_MAX. This is certainly a cleanup, but there might be no functional issue in practice as above. Mark.