Re: [PATCH] ARM fix syscall trace return value

[Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>]

* Russell King (rmk+lkml@arm.linux.org.uk) wrote:
> On Tue, Feb 17, 2009 at 02:30:15PM -0500, Mathieu Desnoyers wrote:
> > I had the same result as you with the ccnt-based clock I am currently
> > developing, so I went back to a more "solid" and atomic
> > atomic_add_return clock. But I noticed that we still had entry/exit with
> > the same timestamps, so I was really unsure about what was happening,
> > because there is no trace corruption and because I have never, ever,
> > seen that kind of problem on any other architecture (x86, powerpc,
> > mips...). So I fixed the syscall_trace exit parameter,
> 
> Correction: you broke syscall_trace exit by corrupting the syscall number
> stored in the thread_info.
> 

Having a second look, yes, you are right. It's the instrumentation that
has been sent to me which was wrongly expecting scno to contain the
return value. So my patch is incorrect.

> > which now makes sure there is a dependency on the return value.
> 
> I've no idea what dependency you're talking about.  ARM is for the most
> part a very simple architecture and doesn't really have any dependencies.
> The only kind it has are those which are automatically fixed up by the
> hardware (so a load followed by an immediate use causes a pipeline stall.)
> 
> So I really can't figure out what you're going on about.  On top of that
> you're trying to make things do stuff in ways they weren't designed.  Your
> bug report makes zero sense to me.
> 
> > But I want to find out
> > why the atomic add return failed to be atomic in that particular
> > condition. I suspect there is a missing memory barrier in atomic.h.
> 
> In a single CPU context, memory barriers to the same location on ARM
> don't have any effect as far as program accesses are concerned.
> 
> So again we disagree.
> 
> So, how about you tell me exactly what you're doing, give me pointers to
> whatever test is failing, tell me about your hardware that you're testing
> on.
> 
> Until that happens, I'm disinclined to believe any of this reported "bug".
> 

Looking at my trace-clock-32-to-64 code tells me I might have problems
specific to little endian machines. I'll review that.

Thanks for the answer,

Best regards,

Mathieu

> -- 
> Russell King
>  Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
>  maintainer of:

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68