Re: [PATCH v4 1/1] printf: add support for printing symbolic error names

[Rasmus Villemoes <linux@rasmusvillemoes.dk>]

On 14/10/2019 15.02, Petr Mladek wrote:
> On Fri 2019-10-11 15:36:17, Rasmus Villemoes wrote:
>> It has been suggested several times to extend vsnprintf() to be able
>> to convert the numeric value of ENOSPC to print "ENOSPC". This
>> implements that as a %p extension: With %pe, one can do
> 
> Reviewed-by: Petr Mladek <pmladek@suse.com>
> 
> I like the patch. There are only two rather cosmetic things.
> 
>> diff --git a/lib/errname.c b/lib/errname.c
>> new file mode 100644
>> index 000000000000..30d3bab99477
>> --- /dev/null
>> +++ b/lib/errname.c
>> +const char *errname(int err)
>> +{
>> +	bool pos = err > 0;
>> +	const char *name = __errname(err > 0 ? err : -err);
>> +
>> +	return name ? name + pos : NULL;
> 
> This made me to check C standard. It seems that "true" really has
> to be "1".
> 
> But I think that I am not the only one who is not sure.
> I would prefer to make it less tricky and use, for example:
> 
> 	const char *name = __errname(err > 0 ? err : -err);
> 	if (!name)
> 		return NULL;
> 
> 	return err > 0 ? name + 1 : name;

I didn't even stop to think that using the value of a comparison
operator/bool in arithmetic might be the littlest bit surprising for C
programmers. But your suggestion isn't terrible, so go ahead and write
it that way. And can I get you to fix the missing "-" in the MIPS
"EDQUOT" special case while you're at it?

>> +static void __init
>> +errptr(void)
>> +{
>> +	char buf[PLAIN_BUF_SIZE];
>> +
>> +	test("-1234", "%pe", ERR_PTR(-1234));
>> +
>> +	/* Check that %pe with a non-ERR_PTR gets treated as ordinary %p. */
>> +	BUILD_BUG_ON(IS_ERR(PTR));
>> +	snprintf(buf, sizeof(buf), "(%p)", PTR);
>> +	test(buf, "(%pe)", PTR);
> 
> There is a small race. "(____ptrval____)" is used for %p before
> random numbers are initialized. The switch is done via workqueue
> work, see enable_ptr_key_workfn(). It means that it can be done
> in parallel.

I know.

> I doubt that anyone would ever hit the race. But it could be very confusing
> and hard to debug.

I thought about it and decided not to care, as long as the errptr test
comes after the hashing test, because if the hashing is not initialized
then one gets a warning. I also considered setting a flag in that case
and then skipping the errptr hash test, but again, decided that the
warning would be enough.

> I would replace it with:

> 	test_hashed("%pe", PTR);

Sure, that will repeat the warning, but it doesn't seem to prevent a
false positive: Between plain_hash_to_buffer emitting the warning (and
returning 0) and the caller test_hashed() then performing the test()
against the buffer contents, the hash can become initialized and thus
change how %p[e] gets formatted. But ok, perhaps it is cleaner to reuse
test_hashed and avoid the local buffer in errptr. So yeah, I suppose
this on top is fine:

diff --git a/lib/test_printf.c b/lib/test_printf.c
index 4fa0ccf58420..030daeb4fe21 100644
--- a/lib/test_printf.c
+++ b/lib/test_printf.c
@@ -596,14 +596,11 @@ flags(void)
 static void __init
 errptr(void)
 {
-       char buf[PLAIN_BUF_SIZE];
-
        test("-1234", "%pe", ERR_PTR(-1234));

        /* Check that %pe with a non-ERR_PTR gets treated as ordinary %p. */
        BUILD_BUG_ON(IS_ERR(PTR));
-       snprintf(buf, sizeof(buf), "(%p)", PTR);
-       test(buf, "(%pe)", PTR);
+       test_hashed("%pe", PTR);

 #ifdef CONFIG_SYMBOLIC_ERRNAME
        test("(-ENOTSOCK)", "(%pe)", ERR_PTR(-ENOTSOCK));



> If would like to have the two things fixed. I am not sure if you want
> to send one more revision. Or I could also change it by follow
> up patch when pushing.

I prefer you to fold in both changes instead of an extra patch, and if
you can't, I'll send a new revision.

Rasmus