Re: PR/56780 CVS commit: src/tests/lib/libc/sys

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR kern/56780; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: PR/56780 CVS commit: src/tests/lib/libc/sys
Date: Wed, 06 Apr 2022 03:59:06 +0700

     Date:        Tue,  5 Apr 2022 16:20:02 +0000 (UTC)
     From:        Martin Husemann <martin%duskware.de@localhost>
     Message-ID:  <20220405162002.8DBFC1A923B%mollari.NetBSD.org@localhost>
 
   |   - mmap with MAP_FIXED for a not page aligned value (that is what you
   |     have made it to do in most cases, but not very portable), but I think
   |     this is not what it was originally about.
 
 My guess is that it probably was, if all that was wanted was an allocated
 addr, there'd have been no reason to init it to SIZE_MAX.   The only reason
 for doing that is because the value is intended to be used.
 
   |     If we want to make it test for that, the fixed address should be picked
   |     better
 
 Perhaps, or probably, but that's very hard.
 
   |     and get a comment
 
 but that, certainly.   Tests generally should have comments to indicate
 what is supposed to be happening, and why, - since they often involve bizarre
 interactions that no-one would normally ever do.
 
   |     (i.e. it should be within the VM space limits
   |     for the architecture,
 
 doing that portably is hard.
 
   |     and if we do below maybe it should be made sure
   |     that the address is inside an unmapped region)
 
 and that's probably even harder.
 
 I suspect that the test was written with knowledge of how the
 kernel actually checks for errors, and knows that the alignment
 test is done first.
 
 Since SIZE_MAX (biggest possible value in a size_t) must be 2^n - 1
 for some n, we know it cannot be aligned, unless n == 0 (which is not an
 interesting architecture, nothing much would work at all on that).
 
 So, the test knows it has an unaligned value, knows that the kernel will
 test for that before it bothers looking at other characteristics of
 the addr (much cheaper that way, and also allows the subsequent checks
 to be simpler), even before the fd is checked (also more expensive test)
 so it knows that the correct thing should have happened.
 
 (If only it hadn't been for that pesky &).
 
 Of course there's a lot of knowledge about the way the tested object
 (kernel mmap() interface here) is implemented embedded here - unfortunately
 that's in common with a lot of the tests.
 
 A test for an attempt to mmap() an allocated addr would be a useful
 thing to add though.   But just &stack_var isn't going to cut it,
 not even &anything_else -- a suitably aligned data struct would need
 to be hand crafted first, and probably avoid using anything malloc()'d
 as that might be mmap'd, and that might be confusing.  So most likely
 
 	static char array[4 * PAGE_SIZE];
 	intptr_t a = array;
 	a += ALIGNMENT;
 	a &= ~(ALIGNMENT - 1);
 	void *addr = a;
 	/* etc, try to mmap(addr, ...) 1 or 2 pages */
 
 kre