Re: [PATCH] ARM fix syscall trace return value

[Russell King]

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:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/