From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bmailout3.hostsharing.net (bmailout3.hostsharing.net [176.9.242.62]) (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 E62D87E77B for ; Thu, 28 Mar 2024 13:47:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=176.9.242.62 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711633630; cv=none; b=WgShQntsVEDLpl1K2raER9A6az0O9K2OHz70neAeGiYTEC2iGakdWwVWUyhb3iymD/e06sy0uNdjhggWqPSVTmCc5/0H5z7a7ZMVisfhrkaQV8IXTWjSF/F7K7WiMHhJL3SxSBqeWAn/YMJdb0HRMeg+7WI3y3u/eoMEYb4GMAM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711633630; c=relaxed/simple; bh=+yIofdhgCqrgjkqxvRHQcjIVZRzo9K5tHymVvW3EjaM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OmnKkB/Sch7t8etC+Vn2Qg+DlZ9k77LN5hS35+tGhhzMdJS8nAKAWz06hO34fG6h9QwIs32RX/yO144Hst1bSVZhSOrIfpv7vh1aXmOlB5TphVMjOqtcyDZvf1isnZ6jJuZxnmRSwL4wmDel8/h0JTzBXylJcHSqA5t3BI3B+2A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=wunner.de; spf=none smtp.mailfrom=h08.hostsharing.net; arc=none smtp.client-ip=176.9.242.62 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=wunner.de Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=h08.hostsharing.net Received: from h08.hostsharing.net (h08.hostsharing.net [IPv6:2a01:37:1000::53df:5f1c:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.hostsharing.net", Issuer "RapidSSL TLS RSA CA G1" (verified OK)) by bmailout3.hostsharing.net (Postfix) with ESMTPS id 9198C100DA1C9; Thu, 28 Mar 2024 14:38:40 +0100 (CET) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 382D754B1D; Thu, 28 Mar 2024 14:38:40 +0100 (CET) Date: Thu, 28 Mar 2024 14:38:40 +0100 From: Lukas Wunner To: Ard Biesheuvel Cc: Ard Biesheuvel , linux-efi@vger.kernel.org, kazuma-kondo@nec.com Subject: Re: [PATCH] efi/libstub: Cast away type warning in use of max() Message-ID: References: <20240326101850.914032-2-ardb+git@google.com> Precedence: bulk X-Mailing-List: linux-efi@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: On Thu, Mar 28, 2024 at 11:13:07AM +0200, Ard Biesheuvel wrote: > On Thu, 28 Mar 2024 at 10:21, Lukas Wunner wrote: > > On Tue, Mar 26, 2024 at 11:18:51AM +0100, Ard Biesheuvel wrote: > > > Add a missing (u64) cast to alloc_min, which is passed into > > > efi_random_alloc() as unsigned long, while efi_physical_addr_t is u64. > > [...] > > > --- a/drivers/firmware/efi/libstub/randomalloc.c > > > +++ b/drivers/firmware/efi/libstub/randomalloc.c > > > @@ -120,7 +120,7 @@ efi_status_t efi_random_alloc(unsigned long size, > > > continue; > > > } > > > > > > - target = round_up(max(md->phys_addr, alloc_min), align) + target_slot * align; > > > + target = round_up(max(md->phys_addr, (u64)alloc_min), align) + target_slot * align; > > > > Why not > > > > max_t(u64, md->phys_addr, alloc_min) > > Why is that better? It just seems to be the idiomatic way to handle these casts in the kernel. It's also what checkpatch suggests, so by not using it you risk getting "helpful" fixup patches from the usual suspects. It's your call buddy. :)