linux-kernel - Re: [RFC 1/3] mmiotrace full patch, preview 3

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] [day] [month] [year] [list]

Date:	Thu, 1 May 2008 20:45:10 +0300
From:	Pekka Paalanen <pq@....fi>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Pekka Paalanen <pq@....fi>, linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Pavel Roskin <proski@....org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC 1/3] mmiotrace full patch, preview 3

On Tue, 29 Apr 2008 23:40:21 +0300
Pekka Paalanen <pq@....fi> wrote:

> On Mon, 28 Apr 2008 21:45:04 +0300
> Pekka Paalanen <pq@....fi> wrote:
> 
> > The current state is that mmiotrace seems to work fine, also on SMP,
> > but on SMP there's a chance to miss events due to CPUs racing. At last
> > the log produced via ftrace framework is up-to-spec. Inserting user
> > comments (markers in mmiotrace-parlance) into the log is not yet
> > supported. All in all, after some more testing on my part, IMHO this
> > is in a mergeable state.
> 
> Ok, looks like I won't be able to do more testing than what I did today.
...
> 
> Tested with the patches and sched-devel/latest of
> Tue, 29 Apr 2008 11:47:55 +0000
> using testmmiotrace.ko and things looked fine.

Hi,

I did get the nvidia blob to work, with some help, and tried mmiotrace
on it. Worked perfectly. The machine is Thinkpad T61 with a Core 2 Duo.
Mmiotrace disabled and enabled the extra core without a glitch, and did
not even drop any events with the default ftrace buffer size. Previously
while tracing Nouveau, I had to increase the buffer size, which worked
well, too.

I did a second trace run after doing
echo 1 > /debug/tracing/trace_entries
and as expected, it lost a lot of events, but showed no problems. Then
I disabled mmiotrace while in X, the 2nd cpu core came back online, and
everything was good. Losing events is logged into the kernel log once
per mmiotrace activation, and into the trace whenever noticed.

(On athlon64 3000+, x86_64:)
Earlier I tried unaligned accesses with testmmiotrace.ko, by mapping
from an odd start address and doing 8, 16 and 32 bit reads and writes.
There were no crashes, and at a page boundary it resulted in a recursive
probe hit, which was resolved by disarming the both pages. Only one page
is re-armed, so the other page is left "blind", but did not seem to
harm stability.

Conclusion: green light from me!

-- 
Pekka Paalanen
http://www.iki.fi/pq/
--
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/