Re: [PATCH] ARM fix syscall trace return value

Mathieu Desnoyers
2009-02-17T20:13:37Z

* 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/