linux-kernel - Re: [PATCH] [revised -- version 2] Info dump on Oops or panic()

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: <Pine.LNX.4.64.0706281850490.617@internets.corp.google.com>
Date:	Thu, 28 Jun 2007 19:15:14 -0700 (PDT)
From:	Joshua Wise <jwise@...gle.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Kyle McMartin <kyle@...artin.ca>, linux-kernel@...r.kernel.org,
	thockin@...gle.com, mikew@...gle.com, masouds@...gle.com
Subject: Re: [PATCH] [revised -- version 2] Info dump on Oops or panic()

On Thu, 28 Jun 2007, Andrew Morton wrote:
> Your email client is doing space-stuffing.  It's easy enough to fix at this
> end, but even easier if you fix it ;)

Aw darn :( Stupid PINE. I'll fix it for the next patch.

>> +	atomic_notifier_call_chain(&info_dumper_list, 0, NULL);
[...]
> So...  Please consider abandoning the notifier-chain and just go for a
> simple function call.

As we discovered some minutes ago, there appears to be infrastructure for this
already -- the die_chain. For thsoe of you who don't know, the die_chain
gets called from notify_die. It exists on almost all architectures. On i386,
it gets called from die() on arch/i386/kernel/traps.c:417 -- before
registers are scrolled by. So, if we want our own specific output there,
like utsname or uptime, then we can get it.

There exists a DIE_PANIC type on some architectures, but it's never actually
... used. So, I will probably write a patch to add it on all architectures,
and use it in the panic routines.

>> +ATOMIC_NOTIFIER_HEAD(info_dumper_list);
>> +EXPORT_SYMBOL(info_dumper_list);
>
> That export isn't needed.

If I want someone else to access it, like a module, it is... But, I guess
if I wanted to act as per canon, I should just do register functions, and
export those. On the die_chain, those are EXPORT_SYMBOL_GPL, FWIW

> Again, a deref of current->nsproxy->uts_ns->name at oops-time has risks.
>
> This string could be precalculated, no?

Yes, and will be.

> I don't know what to do here.  It will be hard to find a read-the-time
> function which is a) lockless and b) available on all architectures and
> configs.
>
> If you can find a way to use plain old jiffies, that'd be good.

jiffies sounds good enough to me.

There seems to be some opposition to the utsname and uptime patches. I'll
take a look at those here and see what I can do to make those a little more
pleasing to non-Google users. Expect a patch for DIE_PANIC tomorrow...

joshua

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