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

Date:	Mon, 8 Aug 2011 16:34:33 -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 Mon, Aug 8, 2011 at 2:37 PM, Don Zickus <dzickus@...hat.com> wrote:
> Maybe irq_work isn't what we needed.  I just wasn't smart enough to figure
> out how to make sure we can write data in an NMI context and read it in a
> normal context.  I supposed the whole swapping buffers could work and is
> simpler.
So each of the buffers has its own lock, right? If a lock protects a
pair of buffers, then: A reader takes the lock, and a writing NMI
comes in and writes to the non-readable buffer and swaps the two. The
reader still has the lock. Another NMI comes in, sees that the lock is
unavailable, and writes to the "backup" buffer, which is actually the
one the reader is still reading from. Bad corrupted read results.

Either way, I don't see how to make the idea work safely for one pair
of buffers shared by multiple CPU's. It works one-pair-per-CPU, but
that's not how the current design is. I guess it would need to
add/remove files every time a processor is added/removed, and there
have to be some other changes too, obviously. What do you think, Don?
Should this be a per-CPU thing, instead of global worst?

Other alternatives:
1. Try lock. The interrupts will simply not save their data if they
are locked out by readers.
2. Work queue + dynamic allocation. No, I don't mean irq_work. This
works, doesn't it? But it's a bit wasteful of cycles and memory.
--
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/