linux-kernel - Re: pr_cat() + CATSTR(name, size)?

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, 11 Jul 2012 17:48:21 +0200
From:	Kay Sievers <kay@...y.org>
To:	Joe Perches <joe@...ches.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: pr_cat() + CATSTR(name, size)?

On Wed, Jul 11, 2012 at 5:30 PM, Joe Perches <joe@...ches.com> wrote:
> On Wed, 2012-07-11 at 17:14 +0200, Kay Sievers wrote:
>> On Wed, Jul 11, 2012 at 5:01 PM, Joe Perches <joe@...ches.com> wrote:
> []
>> There are _many_ cases the console lock is held, and we don't print
>> stuff immediately out to the console, and we never ensured that in the
>> past. There was never a guarantee that stuff ended up on the console,
>> kmsg was always and needs to be a store+forward model.
>
> I'm less concerned with kmsg than you.
> I think it's more a nicety than anything.

Sure, just saying, that there is never a guarantee that stuff lands
directly on the console  at print time, we never had that. It just
usually gets there directly. There is trylock(console_sem), if we can
not get that, we always leave the data in the buffer and let someone
else push it with the next unlock, and that can be later. That
behaviour was always the case.

>> > It would require all sites with continuation lines
>> > be modified.  Because it requires in-situ code
>> > modifications, I'd prefer a cookie based approach.
>>
>> Well, it would be mostly for the dev_printk() stuff, which should
>> ideally never be merged with stuff that could go wrong.
>
> Perhaps that's ideal, but not practical.
> printk continuations are more prevalent.

We can't have everything. We can not merge the data at least, for
integrity reasons. We can only make it *look* like it belonged
together, like we do when we run into a race or the console is locked
and we can not merge continuation fragments into one record.

>> > I think it's more flexible, allows the cookie to be
>> > passed into extending functions and doesn't demand
>> > (much) extra stack.
>> >
>> > Something like:
>> > https://lkml.org/lkml/2012/4/3/231
>> > https://lkml.org/lkml/2011/11/14/349
>>
>> Hmm, how do we manage memory allocations here? We can get around that
>> somehow? It's something the common printk() must really avoid.
>
> Well, I think the malloc costs are pretty low
> and could devolve pretty easily when OOM.

We need to avoid allocating memory in situations where we want to
printk(), it's just not possible. That's why all the kmsg/printk can
not really do any plain malloc. All printk memory needs to be static,
on the stack or somehow pre-allocated.

> Anyway, interesting idea, keep at it, see what
> comes out of it.

Just depends on us, I guess. :)

Thanks,
Kay
--
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/