linux-kernel - Re: Re: [RESEND RFC PATCH 0/5] Add a hash value for each line in /dev/kmsg

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: <51F267CE.1040008@hitachi.com>
Date:	Fri, 26 Jul 2013 21:13:02 +0900
From:	Hidehiro Kawai <hidehiro.kawai.ez@...achi.com>
To:	Joe Perches <joe@...ches.com>
Cc:	linux-kernel@...r.kernel.org, yrl.pp-manager.tt@...achi.com,
	akpm@...ux-foundation.org, gregkh@...uxfoundation.org,
	kay@...y.org, davem@...emloft.net, itoukzo@...data.co.jp
Subject: Re: Re: [RESEND RFC PATCH 0/5] Add a hash value for each line
 in /dev/kmsg

Hello,

(2013/07/26 1:51), Joe Perches wrote:> On Thu, 2013-07-25 at 17:37 +0900, Hidehiro Kawai wrote:
>> ================
>> This patch series adds hash values of printk format strings into
>> each line of /dev/kmsg outputs as follows:
>>
>>         6,154,325061,-,b7db707c@...nel/smp.c:554;Brought up 4 CPUs
>>
>> These hash values allow use space to identify messages easily and
>> do valuable things.  There is no guarantee that the hash values
>> are unique.  However, user space can know which one collides to
>> others from a message-and-hash catalog generated at build time, so
>> finally it should be able to identify the messages.  User space
>> can also use filename:lineno information to do that, although the
>> information is not portable among various kernel versions.
>>
>>
>> Background
>> ==========
>> We sometimes want to identify each kernel message automatically
>> because of the following purposes:
>>
>> (1) Show more detailed information about the message by cooperating
>>     with external system
>> (2) Take actions automatically depending on the message, for example
>>     trigger a fail over or collect related information to analyze the
>>     problem
>
> If there are really "take action" uses, perhaps
> it'd be better to mark the specific areas of code
> where this needs to be done and add a notifier
> function there instead of depending on post effect
> processing.

It is one of the solution if we can add such notifiers easily, but I think
it's not true.  Adding a notifier means that it gives the portion of
the codes fixed meaning.  This is similar to adding a tracepoint.
Maintainer and developers have to keep the meaning consistent, but they
wouldn't like to do that so much.  Moreover, events users want to
handle differ depending on users and system vendors.  As the result,
we would have to add many notifiers into many places.

On the other hand, printk message handling is a flexible, readily
available and multipurpose way.

Regards,
-- 
Hidehiro Kawai
Hitachi, Yokohama Research Laboratory
Linux Technology Center


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