Re: [PATCH v2 1/3] locking/rwsem/x86: Add stack frame dependency for __up_read()

[Miguel Bernal Marin <miguel.bernal.marin@linux.intel.com>]

On Thu, Sep 07, 2017 at 09:12:42AM +0200, Ingo Molnar wrote:
> 
> * Miguel Bernal Marin <miguel.bernal.marin@linux.intel.com> wrote:
> 
> > kernel/locking/rwsem.o: warning: objtool: up_read()+0x11: call without frame pointer save/setup
> > 
> > The warning means gcc 7.2.0 placed the __up_read() inline asm (and its
> > call instruction) before the frame pointer setup in up_read(),
> > which breaks frame pointer convention and can result in incorrect
> > stack traces.
> > 
> > Force a stack frame to be created before the call instruction by listing
> > the stack pointer as an output operand in the inline asm statement.
> > 
> > Signed-off-by: Miguel Bernal Marin <miguel.bernal.marin@linux.intel.com>
> > ---
> >  arch/x86/include/asm/rwsem.h | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/rwsem.h b/arch/x86/include/asm/rwsem.h
> > index a34e0d4b957d..762167afaec0 100644
> > --- a/arch/x86/include/asm/rwsem.h
> > +++ b/arch/x86/include/asm/rwsem.h
> > @@ -166,14 +166,16 @@ static inline bool __down_write_trylock(struct rw_semaphore *sem)
> >  static inline void __up_read(struct rw_semaphore *sem)
> >  {
> >  	long tmp;
> > +	register void *__sp asm(_ASM_SP);
> > +
> >  	asm volatile("# beginning __up_read\n\t"
> > -		     LOCK_PREFIX "  xadd      %1,(%2)\n\t"
> > +		     LOCK_PREFIX "  xadd      %1,(%3)\n\t"
> >  		     /* subtracts 1, returns the old value */
> >  		     "  jns        1f\n\t"
> >  		     "  call call_rwsem_wake\n" /* expects old value in %edx */
> >  		     "1:\n"
> >  		     "# ending __up_read\n"
> > -		     : "+m" (sem->count), "=d" (tmp)
> > +		     : "+m" (sem->count), "=d" (tmp), "+r" (__sp)
> >  		     : "a" (sem), "1" (-RWSEM_ACTIVE_READ_BIAS)
> >  		     : "memory", "cc");
> 
> Please also convert it to named operands (in separate patches!) - this apparently 
> BASIC inspired labeling syntax of GCC is utterly confusing, counterproductive and 
> somewhat embarrasing as well, considering that we write 2017.

Sorry for delay response,
So I will add the named operands on the v3

> 
> Thanks,
> 
> 	Ingo

-- 
Regards,

Miguel Bernal Marin                     Open Source Technology Center
https://clearlinux.org                              Intel Corporation