Re: [PATCH v9] y2038: Introduce the __ASSUME_TIME64_SYSCALLS define

[Lukasz Majewski <lukma at denx dot de>]

Hi Alistair, Zack,

> On Fri, Aug 30, 2019 at 10:03 AM Zack Weinberg <zackw@panix.com>
> wrote:
> >
> > On Thu, Aug 29, 2019 at 6:00 PM Alistair Francis
> > <alistair23@gmail.com> wrote:  
> > > On Thu, Aug 29, 2019 at 1:24 PM Joseph Myers
> > > <joseph@codesourcery.com> wrote:  
> > > > On Wed, 28 Aug 2019, Zack Weinberg wrote:  
> > > > > OK, how does this look?  
> > > >
> > > > This version is OK.  
> > >
> > > Great! Thanks for your help Zack.
> > >
> > > Do you want to send this out as a patch?  
> >
> > I could just go ahead and apply it to master, maybe that would be
> > the simplest thing?  Or would you prefer to incorporate it into
> > either your patch series or Lukasz' patch series, so that it lands
> > along with the rest of the work?  (In the latter case, you should
> > be able to feed my previous message directly to 'git am'.)  
> 
> Yes, applying it to master is even better!

+1

(I also would prefer to have this flag applied directly to the master
branch, without the need wait for any other patches - to avoid blocking
work, which can be done in parallel).

> 
> Alistair
> 
> >
> > On Wed, Aug 28, 2019 at 5:46 PM Lukasz Majewski <lukma@denx.de>
> > wrote:  
> > > > +#ifndef _LINUX_KERNEL_FEATURES_H
> > > > +#define _LINUX_KERNEL_FEATURES_H 1  
> > >
> > > I assume that the above is just plain "guard" define (without any
> > > extra meaning for glibc or other library)?  
> >
> > Yes.  We have a lot of internal headers that are missing
> > multiple-inclusion guards, so for some time now, whenever I need to
> > modify an internal header that doesn't have a guard, I add one at
> > the same time.
> >
> > On Fri, Aug 30, 2019 at 12:37 PM Joseph Myers
> > <joseph@codesourcery.com> wrote:  
> > > On Fri, 30 Aug 2019, Rich Felker wrote:  
> > > > To clarify, none of the timespec ones "exactly match" -- the
> > > > suffixed syscalls on 32-bit require filling the padding around
> > > > tv_nsec, whereas  
> > >
> > > What do you mean by "require filling the padding"?  I thought the
> > > conclusion in the kernel was that it dealt with zeroing the
> > > padding  
> > ...
> >
> > The kernel should always explicitly clear all of the padding in any
> > structure it writes to user space, anything else risks leaking
> > kernel data (e.g. the compiler decides it can use a 64-bit load and
> > store to copy from the kernel's struct timespec to the user space
> > struct timespec because those high bits are don't-care in the
> > destination ... oops, the previous allocation had a kernel pointer
> > in that 64-bit slot and we just exposed the KASLR base).
> >
> > Regardless, though, I don't think the text I wrote needs to mention
> > this concern, since it actually doesn't talk at all about the
> > "exactly match" rule.  The set of system calls covered by the new
> > macro is just listed as a fact.  Please let me know if you disagree?
> >
> > zw  



Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

Attachment: pgpRJcqRwhSdL.pgp
Description: OpenPGP digital signature