Re: [PATCH 2/2] x86: ia32_signal: remove unnecessary padding

[Mikael Pettersson]

Ingo Molnar writes:
 > 
 > * Hiroshi Shimamoto <h-shimamoto@xxxxxxxxxxxxx> wrote:
 > 
 > > From: Hiroshi Shimamoto <h-shimamoto@xxxxxxxxxxxxx>
 > > 
 > > Impact: cleanup
 > > 
 > > Remove unnecessary paddings, this saves 4 bytes.
 > > 
 > > Signed-off-by: Hiroshi Shimamoto <h-shimamoto@xxxxxxxxxxxxx>
 > > ---
 > >  arch/x86/ia32/ia32_signal.c |    5 +----
 > >  1 files changed, 1 insertions(+), 4 deletions(-)
 > 
 > applied your patches to tip/x86/signal:
 > 
 >  9cc3c49: x86: ia32_signal: remove unnecessary padding
 >  4a61204: x86: signal_32: introduce retcode and rt_retcode
 > 
 > thanks!
 > 
 > A question - this change:
 > 
 > > @@ -427,12 +427,10 @@ int ia32_setup_frame(int sig, struct k_sigaction *ka,
 > >  		u16 poplmovl;
 > >  		u32 val;
 > >  		u16 int80;
 > > -		u16 pad;
 > >  	} __attribute__((packed)) code = {
 > >  		0xb858,		 /* popl %eax ; movl $...,%eax */
 > >  		__NR_ia32_sigreturn,
 > >  		0x80cd,		/* int $0x80 */
 > > -		0,
 > >  	};
 > >  
 > >  	frame = get_sigframe(ka, regs, sizeof(*frame), &fpstate);
 > > @@ -508,8 +506,7 @@ int ia32_setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
 > >  		u8 movl;
 > >  		u32 val;
 > >  		u16 int80;
 > > -		u16 pad;
 > > -		u8  pad2;
 > > +		u8  pad;
 > >  	} __attribute__((packed)) code = {
 > >  		0xb8,
 > >  		__NR_ia32_rt_sigreturn,
 > 
 > does not impact any ABI, because it's only about the signal trampoline 
 > the kernel pushes to the user-space stack - not about any 
 > userspace-visible signal frame detail, right?

As long as the 'char retcode[8]' field isn't reduced in size
(you can _never_ do that!), and the initial instruction
sequence up to the 'int $0x80' isn't changed (you can't change
that either), I believe this is safe.

It does cause each signal delivery to leak 2 uninitialised
kernel bytes to the end of retcode[], which seems unnecessary.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/