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]

Message-ID: <CAPXgP11XnrFayb-g5HFu3wPtw8=xLfSY7HNCCbiSoehj8KsGcw@mail.gmail.com>
Date:	Wed, 11 Jul 2012 17:14:49 +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:01 PM, Joe Perches <joe@...ches.com> wrote:

> On Wed, 2012-07-11 at 12:33 +0200, Kay Sievers wrote:
> Interesting idea, perhaps workable, but it has
> a few defects I can see.
>
> It works for most uses, but it doesn't work for
> when there are multiple function sites like
>
> void dump_info(struct foo *bar)
> {
>         if (bar->baz)
>                 pr_cont("baz...");
> }
>
> ---
>
>         pr_info("Some initiator: ")
>         dump_info(&descriptor);

Yeah, it's just the common case, not for the "creative" ones. :)

> Another negative is that is uses a local stack
> variable for the entire line which increases
> stack pressure.

The thing is to avoid malloc(), and ~100 bytes are kind of OK for the
time we do the printk, I guess

> It also fails to immediately output after some
> defect unlike your change to output directly to
> console.

Which is really only that important for stuff that causes crashes
between the outputting fragments.

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.

> 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.

> 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.

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/