[Bug libc/20251] 32bit programs pass garbage in struct flock for OFD locks

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20251

--- Comment #5 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to jlayton@poochiereds.net from comment #4)
> Care to propose a patch? I'm not as familiar with the glibc internals so I'd
> appreciate some guidance here.

I am checking on it.

> 
> FWIW, I don't see how we can fix this at runtime. I was only proposing a
> build-time fix. i.e.: ensure that non-LFS programs that try to use OFD locks
> will fail to build. If you see some way to reliably cope with this for
> programs already built, then maybe that would be better.

An option for former would be just to avoid define OFD locks commands for
non-LFS configurations, but I think we can make it work at runtime.

> 
> At the time this was implemented though, the idea was to forbid its usage on
> non-LFS platforms. We could revisit that decision, but I don't really see
> the point in supporting what amounts to a legacy flock struct with this.

The idea is GLIBC abi might not be tied to kernel in a sense it might define
strucs with different layout than what kernel expect. We try to avoid it, since
it requires a lot of boilerplate code to transform from and to the syscall
itself.

But to correctly fix this issue I can't really think a different way than
provided both LFS and non-LFS symbol (the default and *64 variant). 

And by using 2 different symbols it is safe the variadic argument to non-LFS
flock or just return EINVAL (I do not have a strong preference here).  However
we still need to provide a compat symbol with current semantic.

-- 
You are receiving this mail because:
You are on the CC list for the bug.