lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090217194040.GA14613@flint.arm.linux.org.uk>
Date:	Tue, 17 Feb 2009 19:40:40 +0000
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc:	Viktor Rosendahl <Viktor.Rosendahl@...ia.com>,
	ext Tony Lindgren <tony@...mide.com>,
	"Moiseichuk Leonid (Nokia-D/Helsinki)" <leonid.moiseichuk@...ia.com>,
	"Kallioinen Juha (Nokia-D/Helsinki)" <juha.kallioinen@...ia.com>,
	"Siamashka Siarhei (Nokia-D/Helsinki)" <siarhei.siamashka@...ia.com>,
	"Tamminen Eero (Nokia-D/Helsinki)" <eero.tamminen@...ia.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.arm.linux.org.uk" 
	<linux-arm-kernel@...ts.arm.linux.org.uk>
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:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ