From: Ard Biesheuvel <ardb@kernel.org>
To: Lukas Wunner <lukas@wunner.de>
Cc: Ard Biesheuvel <ardb+git@google.com>,
linux-efi@vger.kernel.org, kazuma-kondo@nec.com
Subject: Re: [PATCH] efi/libstub: Cast away type warning in use of max()
Date: Thu, 28 Mar 2024 15:57:25 +0200 [thread overview]
Message-ID: <CAMj1kXFFkVn1Y_m2LcB7dK+ACNmtL-gnpsmT-_ucn3zrO4RdcA@mail.gmail.com> (raw)
In-Reply-To: <ZgVy4BP1dpho5PZ8@wunner.de>
On Thu, 28 Mar 2024 at 15:38, Lukas Wunner <lukas@wunner.de> wrote:
>
> On Thu, Mar 28, 2024 at 11:13:07AM +0200, Ard Biesheuvel wrote:
> > On Thu, 28 Mar 2024 at 10:21, Lukas Wunner <lukas@wunner.de> 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.
>
In this particular case, I prefer max() with the cast, because it
matches the other occurrence, where alloc_min is also used but there
it is u64 not unsigned long.
> It's also what checkpatch suggests, so by not using it you risk getting
> "helpful" fixup patches from the usual suspects.
>
Ugh yeah good point.
> It's your call buddy. :)
Thanks for the head's up
prev parent reply other threads:[~2024-03-28 13:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-26 10:18 [PATCH] efi/libstub: Cast away type warning in use of max() Ard Biesheuvel
2024-03-28 8:21 ` Lukas Wunner
2024-03-28 9:13 ` Ard Biesheuvel
2024-03-28 13:38 ` Lukas Wunner
2024-03-28 13:57 ` Ard Biesheuvel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMj1kXFFkVn1Y_m2LcB7dK+ACNmtL-gnpsmT-_ucn3zrO4RdcA@mail.gmail.com \
--to=ardb@kernel.org \
--cc=ardb+git@google.com \
--cc=kazuma-kondo@nec.com \
--cc=linux-efi@vger.kernel.org \
--cc=lukas@wunner.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).