Messages in this thread | | | Date | Tue, 17 Feb 2009 19:40:40 +0000 | From | Russell King <> | Subject | Re: [PATCH] ARM fix syscall trace return value |
| |
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.
> 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".
-- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
| |