linux-kernel - Re: [PATCH v4 2/2] Output stall traces in /proc

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]

Message-ID: <CAAuSN905uf1p1Uz1Kuh6=XsM6H0QpYwHQO4mazE39WTj2oUTLA@mail.gmail.com>
Date:	Tue, 9 Aug 2011 14:44:31 -0700
From:	Alex Neronskiy <zakmagnus@...omium.org>
To:	Don Zickus <dzickus@...hat.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Mandeep Singh Baines <msb@...omium.org>
Subject: Re: [PATCH v4 2/2] Output stall traces in /proc

On Tue, Aug 9, 2011 at 2:08 PM, Don Zickus <dzickus@...hat.com> wrote:
> Well, looking at the code again, I think the spin_locks in the NMI handler
> will block the other cpus from writing to the page at the same time.  So
> it gets serialized that way, I think.  The next trick is to do something
> with procfs like swapping buffers successfully.
>
> I am trying to think how that would work, but I guess if you use the
> cmpxchg macros then
>
> procfs could cmpxchg a READ_BIT on the buffer and if successful (no
> WRITE_BIT), then proceed to read the buffer.  Otherwise use the other
> buffer.  A lock would have to be used to serialize access on the procfs.
>
> The NMI code could do the same with a WRITE_BIT and if succesful (no
> READ_BIT), then proceed to write the buffer.  Otherwise use the other
> buffer.  Because the NMI is serialized only one write could go on at any
> one time.
>
> I was reading the kernel/irq_work.c code to generate the above idea.
>
> Not sure if it works.  Thoughts?
>
> Cheers,
> Don
>
I don't think that the reader should use the other buffer if it finds
contention. Who knows what that other buffer contains? Maybe something
really stale, maybe nothing. However, I think it's okay for the reader
to wait to be able to obtain the lock from the writer; just not the
other way around. I have a similar idea sketched out and I'll try and
get a patch out soon. Basically, the reader will be really simple and
just obtain the lock on whatever buffer it's told and then read that
buffer and unlock. The worst that will happen is that it will read a
slightly stale value, and that's only because it read "before" the
buffers switched. The writer, meanwhile, merely tries to lock a
buffer, and if it fails, sets the other one as the writable one (this
state is not shared with the reader). Then it locks that one
(guaranteed no contention), writes out the data, tells the reader to
read from the new buffer from now on, and unlocks. Both readers and
writers are serialized.

It's probably pretty hard to follow that description. Hopefully the
patch will be clearer.
--
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/