On Wed, Oct 07, 2020 at 12:39:27AM +0300, Jarkko Sakkinen wrote: > On Mon, Oct 05, 2020 at 07:57:05PM -0700, Sean Christopherson wrote: > > On Sat, Oct 03, 2020 at 07:50:56AM +0300, Jarkko Sakkinen wrote: > > > + __u16 exception_vector; > > > + __u16 exception_error_code; > > > + __u64 exception_addr; > > > + __u8 reserved[24]; > > > > I also think it's a waste of space to bother with multiple reserved fields. > > 24 bytes isn't so much that it guarantees we'll never run into problems in > > the future. But I care far less about this than I do about exit_reason. > > For me the real problem is that there has not been "no brainer" basis > for any size, so a one cache line worth of data is just something that > makes sense, because would neither make much sense to have less. > > I'll throw an argument to have it a bit bigger amount of reserved space > for future use. > > First, there is always some amount of unknown unknowns when it comes to > run-time structures, given the evolution of microarchitectures. So yes, > some more "state" might be needed in the future. > > Secondly, this is a bigger problem for the vDSO than it is for ioctl's > because we can have only one. With ioctl's, in the absolute worst case, > we can have a second version of the same ioctl. > > At least 256 bytes would be probably a good number, if we want to > increase it. The reserved space zero validation that I implemented to > this version probably does not add much to the overhead anyway. > > I'm not sure why care about one struct field more than making sure that > the run-time structure can stand time. So what I could do is to grow the reserved area and based on my response explain this in the changelog message but I need to make sure that I got the reasoning right behind the size. /Jarkko
