linux-kernel - Re: [PATCH 5/5] lib: Add error string support to printks

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, 18 Sep 2013 20:27:50 -0500
From:	Daniel Santos <danielfsantos@....net>
To:	David Howells <dhowells@...hat.com>
CC:	Joe Perches <joe@...ches.com>,
	Daniel Santos <daniel.santos@...ox.com>,
	linux-kbuild <linux-kbuild@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Michal Marek <mmarek@...e.cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Michael Kerrisk <mtk.manpages@...il.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	George Spelvin <linux@...izon.com>
Subject: Re: [PATCH 5/5] lib: Add error string support to printks


On 09/18/2013 06:04 AM, David Howells wrote:
> Joe Perches <joe@...ches.com> wrote:
>
>> On Tue, 2013-09-17 at 18:08 -0500, danielfsantos@....net wrote:
>>> This adds an extension for the integral format specifier suffix of 'e',
>>> so that the format %[duxXo]e will result in printing an number (as
>>> before) in addition to a name and descrption for an error code, if such
>>> support is enabled and a name and descrption is found.
>>>
>>> My initial thought was to use the glibc extension of '%m', but this
>>> format specifier uses the value of libc's errno and adding a value
>>> breaks gcc's printf parsing.  I'm not convinced that the 'e' extension
>>> is optimal, although there are only four instances of this pattern in
>>> the kernel that would need to be changed.
>>>
>>>      git grep -E '".*%[#0\ +\-]*[0-9]*[hljzt]*[idoxXu]e'
>>>
>>> Alternatively, 'E' was another thought for a suffix as well.
>> I'd much rather see another %p extension used instead
>> of generating odd output given normal printf formats.
>>
>> %pE might work
> I guess you'd use that with ERR_PTR().  On one hand, it would look decidedly
> odd, but on the other hand, we have errors in pointers in a lot of places
> already which wouldn't then need converting back - so it doesn't seem entirely
> unreasonable.
>
> David

Hmm, this discussion makes me pine for the gnu libc '%m' extension even 
further.  I wish there was an easy way to tell gcc that you want it to 
check your format, but here are my extensions.  Oh well.

Honestly, I'm not too keen on the %pE idea, although I can see that %p 
is where all of the kernel extensions currently are. Unless I'm 
incorrect, if I use ERR_PTR() on a signed int on a x86_64 where pointer 
is 64 bits and int is 32, wouldn't that mean a signed conversion 
instruction where the sign bit has to be moved from bit 31 to 63?

Either way, %pE does seem to make a lot of sense for conditions where we 
already have a pointer that we would otherwise use PTR_ERR() to convert, 
but it just seems klunky to use it on an int, to have it treated like a 
pointer and then re-interpreted as an int.  Maybe we can add %pE as well 
as %dE and leave [ioxXu] out of it?

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