From: Gary Guo <gary@garyguo.net>
To: Danilo Krummrich <dakr@kernel.org>
Cc: "Tamir Duberstein" <tamird@gmail.com>,
"Miguel Ojeda" <ojeda@kernel.org>, "DJ Delorie" <dj@redhat.com>,
"Eric Blake" <eblake@redhat.com>,
"Paul Eggert" <eggert@cs.ucla.edu>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
rust-for-linux@vger.kernel.org, linux-man@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5] rust: alloc: satisfy POSIX alignment requirement
Date: Thu, 13 Feb 2025 11:21:35 +0000 [thread overview]
Message-ID: <20250213112135.7319862c@eugeo> (raw)
In-Reply-To: <Z6zT6mZuxonewQ9z@pollux>
On Wed, 12 Feb 2025 18:01:30 +0100
Danilo Krummrich <dakr@kernel.org> wrote:
> On Wed, Feb 12, 2025 at 04:38:48PM +0000, Gary Guo wrote:
> > On Wed, 12 Feb 2025 16:40:37 +0100
> > Danilo Krummrich <dakr@kernel.org> wrote:
> >
> > > On Wed, Feb 12, 2025 at 09:43:02AM -0500, Tamir Duberstein wrote:
> > > > diff --git a/rust/kernel/alloc/allocator_test.rs b/rust/kernel/alloc/allocator_test.rs
> > > > index e3240d16040b..17a475380253 100644
> > > > --- a/rust/kernel/alloc/allocator_test.rs
> > > > +++ b/rust/kernel/alloc/allocator_test.rs
> > > > @@ -62,6 +62,26 @@ unsafe fn realloc(
> > > > ));
> > > > }
> > > >
> > > > + // ISO C (ISO/IEC 9899:2011) defines `aligned_alloc`:
> > > > + //
> > > > + // > The value of alignment shall be a valid alignment supported by the implementation
> > > > + // [...].
> > > > + //
> > > > + // As an example of the "supported by the implementation" requirement, POSIX.1-2001 (IEEE
> > > > + // 1003.1-2001) defines `posix_memalign`:
> > > > + //
> > > > + // > The value of alignment shall be a power of two multiple of sizeof (void *).
> > > > + //
> > > > + // and POSIX-based implementations of `aligned_alloc` inherit this requirement. At the time
> > > > + // of writing, this is known to be the case on macOS (but not in glibc).
> > > > + //
> > > > + // Satisfy the stricter requirement to avoid spurious test failures on some platforms.
> > > > + let min_align = core::mem::size_of::<*const crate::ffi::c_void>();
> > > > + let layout = layout.align_to(min_align).unwrap_or_else(|_err| {
> > > > + crate::build_error!("invalid alignment")
> > >
> > > That's not what I thought this patch will look like. I thought you'll directly
> > > follow Gary's proposal, which is why I said you can keep the ACK.
> > >
> > > build_error!() doesn't work here, there is no guarantee that this can be
> > > evaluated at compile time.
> >
> > `align_to` will only fail if `min_align` is not a valid alignment (i.e.
> > not power of two), which the compiler should be easy to notice that the
> > size of pointer is indeed power of 2.
>
> From the documentation of align_to():
>
> "Returns an error if the combination of self.size() and the given align violates
> the conditions listed in Layout::from_size_align."
>
> Formally self.size() may still be unknown at compile time.
>
> Do I miss anything?
Ah, I think you're indeed correct. If I get a type that has the size of
`isize::MAX - 1` and alignment of 1, and then trying to align up to
pointer size will cause an error.
We should proceed with `map_err` then.
Best,
Gary
>
> >
> > I think both `build_error!` and `map_err` version below is fine to me.
> >
> > Best,
> > Gary
> >
> > >
> > > I think this should just be:
> > >
> > > let layout = layout.align_to(min_align).map_err(|_| AllocError)?.pad_to_align();
> > >
> > > - Danilo
prev parent reply other threads:[~2025-02-13 11:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-12 14:43 [PATCH v5] rust: alloc: satisfy POSIX alignment requirement Tamir Duberstein
2025-02-12 15:40 ` Danilo Krummrich
2025-02-12 15:42 ` Tamir Duberstein
2025-02-12 16:38 ` Gary Guo
2025-02-12 17:01 ` Danilo Krummrich
2025-02-12 18:44 ` Tamir Duberstein
2025-02-12 20:01 ` Danilo Krummrich
2025-02-12 20:47 ` Tamir Duberstein
2025-02-12 20:58 ` Danilo Krummrich
2025-02-12 21:24 ` Tamir Duberstein
2025-02-13 1:00 ` Tamir Duberstein
2025-02-13 11:21 ` Gary Guo [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=20250213112135.7319862c@eugeo \
--to=gary@garyguo.net \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=dj@redhat.com \
--cc=eblake@redhat.com \
--cc=eggert@cs.ucla.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tamird@gmail.com \
--cc=tmgross@umich.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.