Re: CVS commit: src/sys/kern
In article <20110228005040.ga26...@netbsd.org>,
David Holland wrote:
>On Sun, Feb 27, 2011 at 07:12:16PM -0500, Christos Zoulas wrote:
> > don't depend on F_OK being 0.
> > :
> > - if ((SCARG(uap, flags) & ~(R_OK | W_OK | X_OK)) != 0) {
> > + if ((SCARG(uap, flags) & ~(F_OK | R_OK | W_OK | X_OK)) != 0) {
>
>That doesn't work; if F_OK isn't zero and the user passes 0, we end up
>in the kauth assertion again.
>
>mlelstv and I were just (more or less pointlessly) thrashing out
>various ways to fix that in chat, but it ends up overcomplicated, so I
>suggest reverting the above and instead adding
>
>+ CTASSERT(F_OK == 0);
>if ((SCARG(uap, flags) & ~(R_OK | W_OK | X_OK)) != 0) {
>
>so that if in the unlikely event that anyone ever tries to change F_OK
>it will then get further attention.
Sounds good to me.
christos
Re: CVS commit: src/sys/kern
On Sun, Feb 27, 2011 at 07:12:16PM -0500, Christos Zoulas wrote:
> don't depend on F_OK being 0.
> :
> - if ((SCARG(uap, flags) & ~(R_OK | W_OK | X_OK)) != 0) {
> + if ((SCARG(uap, flags) & ~(F_OK | R_OK | W_OK | X_OK)) != 0) {
That doesn't work; if F_OK isn't zero and the user passes 0, we end up
in the kauth assertion again.
mlelstv and I were just (more or less pointlessly) thrashing out
various ways to fix that in chat, but it ends up overcomplicated, so I
suggest reverting the above and instead adding
+ CTASSERT(F_OK == 0);
if ((SCARG(uap, flags) & ~(R_OK | W_OK | X_OK)) != 0) {
so that if in the unlikely event that anyone ever tries to change F_OK
it will then get further attention.
--
David A. Holland
dholl...@netbsd.org
Re: CVS commit: src/sys/arch/i386/stand/boot
On Sat, Feb 26, 2011 at 06:22:59PM +, Jonathan A. Kollasch wrote: > Module Name: src > Committed By: jakllsch > Date: Sat Feb 26 18:22:59 UTC 2011 > > Modified Files: > src/sys/arch/i386/stand/boot: Makefile.boot > > Log Message: > Enable LIBSA_PRINTF_LONGLONG_SUPPORT. > Useful in any of the cases where we already print a (64-bit) daddr_t. I'm surprised that doesn't explode the sizes of the boot code. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/lib/librumphijack
On Sun Feb 27 2011 at 08:12:37 +0300, Valeriy E. Ushakov wrote:
> On Fri, Feb 25, 2011 at 16:01:42 +, Antti Kantee wrote:
>
> > Module Name:src
> > Committed By: pooka
> > Date: Fri Feb 25 16:01:42 UTC 2011
> >
> > Modified Files:
> > src/lib/librumphijack: Makefile hijackdlsym.c
> >
> > Log Message:
> > Ok, for reasons I can't begin to understand, the binaries I tested
> > yesterday on powerpc broke overnight. Apparently adding one more
> > function before the call to dlsym() fixes things again. I hope
> > I don't have to add another one tomorrow
> >
> >
> > To generate a diff of this commit:
> > cvs rdiff -u -r1.7 -r1.8 src/lib/librumphijack/Makefile
> > cvs rdiff -u -r1.1 -r1.2 src/lib/librumphijack/hijackdlsym.c
>
> I think this is caused by revision 1.121 of rtld.c (hi, mac!) that
> added "hackish_return_address" for ppc.
>
> #ifdef __powerpc__
> static void *
> hackish_return_address(void)
> {
> return __builtin_return_address(1);
> }
> #endif
>
> void *
> dlsym(void *handle, const char *name)
> {
> ...
> #ifdef __powerpc__
> retaddr = hackish_return_address();
> #else
> retaddr = __builtin_return_address(0);
> #endif
> ...
> }
>
>
> hackish_return_address will be inlined (simple static function) and,
> as far as I can tell, gcc does NOT adjust the "level" argument to
> __builtin_return_address.
>
> The net effect is that dlsym uses caller's caller address to detect
> which module the call comes from, and if caller's caller is in a
> different module wrong things happen.
>
> That explains why you need an extra frame.
What I really can't understand is that I have a very distinct impression
that things worked on Thursday (and screencaps to show it). Then, after
riz installed a new userland, things were broken on Friday. However,
I was using the same ld.elf_so binary I had compiled for debugging,
so it cannot be that the new toolchain inlined the call while the old
one didn't.
Anyway, apparently I don't have to put yet another callframe there,
since things are still working ;)
http://www.netbsd.org/~riz/macppc-atf/
Btw, if someone is looking for something interesting, look at the
posix_fadvise test.
--
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
