Re: 2.6.14-rc3-rt2

[Andi Kleen <ak@suse.de>]

On Thursday 06 October 2005 11:48, Steven Rostedt wrote:
> On Thu, 6 Oct 2005, Ingo Molnar wrote:
> > * Steven Rostedt <rostedt@goodmis.org> wrote:
> > > > ahh ... I would not be surprised if this caused actual problems on
> > > > x64 in the upstream kernel too: using save_flags() over u32 will
> > > > corrupt a word on the stack ...
> > >
> > > Actually, it's still safe upstream.  The locks are taken via a function
> > > defined as:
> > >
> > > unsigned long acpi_os_acquire_lock(acpi_handle handle)
> > > {
> > > 	unsigned long flags;
> > > 	spin_lock_irqsave((spinlock_t *) handle, flags);
> > > 	return flags;
> > > }
> > >
> > > So a u32 flags with
> > >
> > >   flags = acpi_os_acquire_lock(lock);
> > >
> > > would be safe, unless a 64 bit machine stored the value of IR in the
> > > upper word, which I don't know of any archs that do that.
> >
> > ok. But this still looks very volatile. Nowhere do we guarantee (or can
> > we guarantee) that silently zeroing out the upper 32 bits of flags is
> > safe!
>
> Andi,
>
> So, should I send my patch upstream?

It's a theoretical only issue for mainline right now. The only architectures 
using the ACPI code are i386,x86-64,ia64. The first two are ok with 
truncating. The IA64 PSR is longer than 32bit, but unless I'm misreading the 
code they only care about the "i" bit which is also in the lower 32bit (Tony 
can probably confirm/deny) 

Still might be good to clean up, but certainly not a urgent issue.

-Andi