linux-kernel - Re: [PATCHSET] printk: implement printk_header() and merging printk, take #3

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: <47B4EFAB.2040102@gmail.com>
Date:	Fri, 15 Feb 2008 10:49:31 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	jeff@...zik.org, linux-ide@...r.kernel.org,
	jengelh@...putergmbh.de, matthew@....cx, randy.dunlap@...cle.com,
	daniel.ritz-ml@...ssonline.ch, linux-kernel@...r.kernel.org
Subject: Re: [PATCHSET] printk: implement printk_header() and merging printk,
 take #3

Tejun Heo wrote:
> Hello,
> 
> Andrew Morton wrote:
>> On Thu, 14 Feb 2008 09:40:51 +0900
>> Tejun Heo <htejun@...il.com> wrote:
>>
>>> Can you please take a look at ata_eh_link_report() in
>>> drivers/ata/libata-eh.c?
>> I did.  Punishment?
> 
> Heh.. :-)
> 
>>>  Currently, it has some problems.
>> Yes, and the patches do clean that up.
> 
> Yeap, it does.
> 
>> ho hum.  What tends to happen with this sort of thing is that fi we merge
>> it, it ends up getting used more often than one expected...
> 
> Hmmm... Okay.  mprintk being printk, I'm not too sure how it can go over
> usual expectations but well, yeah, that actually is my expectation.
> 
>> If you stand back and squint at it, there are quite a few places where we
>> do this sort of thing: allocate a buffer, squirt characters into it,
>> reallocating and/or flushing as we proceed.  All sysfs and procfs read-side
>> code, for a start...
> 
> printk is a special case, I think.  It's the primary logging/debugging
> method which can't fail and as it's mostly interpreted by human beings
> (and developers in problematic cases), it has different maneuvering room
> on errors - ie. it's far better to print messages w/o header or proper
> log level than failing to print, which is quite different requirements
> from other components.

Andrew, any more comments or suggestions on how to proceed on this?  One
way or the other, I think this is a problem worth solving.

Thanks.

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