lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <iocqkifz6dsywt2ueqppsdw53bgcp6i7ju7vadxxxu7pow6w5c@n2wqgypsiq2d>
Date: Sun, 9 Feb 2025 00:35:55 +0100
From: Alejandro Colomar <alx@...nel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: DJ Delorie <dj@...hat.com>, Eric Blake <eblake@...hat.com>, 
	Will Newton <will.newton@...aro.org>, Paul Eggert <eggert@...ucla.edu>, linux-man@...r.kernel.org, 
	Danilo Krummrich <dakr@...nel.org>, Tamir Duberstein <tamird@...il.com>, 
	Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, Benno Lossin <benno.lossin@...ton.me>, 
	Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>, 
	Trevor Gross <tmgross@...ch.edu>, rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] rust: alloc: satisfy `aligned_alloc` requirements

Hi Miguel,

On Sun, Feb 09, 2025 at 12:11:58AM +0100, Miguel Ojeda wrote:
> On Sat, Feb 8, 2025 at 8:18 PM Alejandro Colomar <alx@...nel.org> wrote:
> >
> > -  aligned_alloc()
> >
> >         It seems to be like memalign(), with *some* input validation.
> >         It makes sure that the input is a power of two, or it fails.
> >         However, it doesn't check that the input is multiple of
> >         _Alignof(void*).  That requirement is implementation-defined;
> >         neither POSIX nor ISO C impose any specific requirements, so the
> >         requirements that the input is a power of two are imposed by
> >         glibc.  The documentation matches the experimental behavior.
> 
> Thanks Alejandro.
> 
> I am not sure I agree -- I am confused about three points:
> 
>   - I am not sure the documentation is matching the experimental
> behavior. For instance, the Linux man pages say:
> 
>       "except for the added restriction that `size` should be a
> multiple of `alignment`"
> 
>     But a call like `aligned_alloc(8, 9)` succeeds. What does "added
> restriction" mean in this context? i.e. is it supposed to fail?

Your manual page is too old.  :)

	commit 7fd1e0f2be216a5e7f7aef0d03304bdf81bca9e0
	Author: DJ Delorie <dj@...hat.com>
	Date:   Mon May 8 20:43:35 2023 -0400

	    posix_memalign.3: Update aligned_alloc(3) to match C17
	    
	    Link: <https://sourceware.org/pipermail/libc-alpha/2023-May/147810.html>
	    Link: <https://patchwork.sourceware.org/project/glibc/patch/33ec9e0c1e587813b90e8aa771c2c8e6e379dd48.camel@posteo.net/>
	    Link: <https://lore.kernel.org/linux-man/d79b505c-5b19-331c-5b25-d40adc9cc843@wanadoo.fr/>
	    Cc: John Scott <jscott@...teo.net>
	    Cc: Paul Floyd <pjfloyd@...adoo.fr>
	    Signed-off-by: DJ Delorie <dj@...hat.com>
	    Signed-off-by: Alejandro Colomar <alx@...nel.org>

	diff --git a/man3/posix_memalign.3 b/man3/posix_memalign.3
	index 9bc6eb9a4..88e4a8b63 100644
	--- a/man3/posix_memalign.3
	+++ b/man3/posix_memalign.3
	@@ -91,9 +91,8 @@ .SH DESCRIPTION
	 is the same as
	 .BR memalign (),
	 except for the added restriction that
	-.I size
	-should be a multiple of
	-.IR alignment .
	+.I alignment
	+must be a power of two.
	 .PP
	 The obsolete function
	 .BR valloc ()


On retrospective, we should have added some more details to that commit
message.  DJ, has the requirement of the size been lifted?  Was it never
present?

If the implementation in glibc has changed over time, we should probably
add a HISTORY section documenting historic behavior.

>   - I am not sure if ISO C intends to require the power of two or not.
> One of the C23 drafts says `aligned_alloc()` is supposed to fail if
> 
>       "the value of `alignment` is not a valid alignment supported by
> the implementation the function"
> 
>     And then, elsewhere, that:
> 
>       "Valid alignments include only fundamental alignments, plus an
> additional implementation-defined set of values, which can be empty.
> Every valid alignment value shall be a nonnegative integral power of
> two."
> 
>     So if those are intended to be connected, then it sounds like a
> non-power-of-two is invalid and thus the function should fail.

Hmmm, you're probably true.  I hadn't read that part.

>   - What Danilo mentioned about the sections, e.g. is the "ERRORS"
> section in the Linux man pages supposed to apply to all the functions
> documented in the same page?
> 
>     Would it help to somehow indicate which errors apply for each function?

It probably needs some rewrite to make it more generic for all
functions.


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es/>

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ