linux-kernel - Re: + printk-print-initial-logbuf-contents-before-re-enabling-interrupts.patch added to -mm tree

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:	Wed, 7 May 2014 10:46:23 +0100
From:	Will Deacon <will.deacon@....com>
To:	Jan Kara <jack@...e.cz>
Cc:	"mm-commits@...r.kernel.org" <mm-commits@...r.kernel.org>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"kay@...y.org" <kay@...y.org>, LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: +
 printk-print-initial-logbuf-contents-before-re-enabling-interrupts.patch
 added to -mm tree

On Tue, May 06, 2014 at 09:00:22PM +0100, Jan Kara wrote:
> On Tue 06-05-14 16:00:37, Will Deacon wrote:
> > On Tue, May 06, 2014 at 03:00:32PM +0100, Jan Kara wrote:
> > > On Tue 06-05-14 14:12:34, Will Deacon wrote:
> > > > Right, so there's the usual compromise here between throughput and latency.
> > >   I'd see that compromise if enabling & disabling interrupts would be
> > > taking considerable amount of time. I don't think that was your concern,
> > > was it? Maybe I just misunderstood you...
> > 
> > Well, that isn't the quickest operation on ARM (since it's
> > self-synchronising), but I was actually referring to the ability to drain
> > the log buffer (with interrupts disabled) vs the ability to service
> > interrupts quickly. The moment we re-enable interrupts, we can start adding
> > more messages to the buffer from the IRQ path (I didn't attempt to solve the
> > multi-CPU case, as I mentioned before).
>   I see. But practically the multi-CPU case is much more common than the
> IRQ case, isn't it?

I think they're both pretty niche, but still valid scenarios.

> > >   Sure. I have a patch which transitions printing to another CPU once in a
> > > while so single CPU isn't hogged for too long and that solves the issues I
> > > have observed. But Alan didn't like this solution so the issue is unfixed
> > > for now.
> > 
> > Interesting. Do you have a pointer to the thread?
>   The patchset posting starts here:
> https://lkml.org/lkml/2014/3/25/343
> 
>   Patch 5/8 is probably the most interesting for you (patches 1-4 are
> already in the mm tree).

Yikes, that's certainly more invasive than anything I had in mind!

Will
--
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/