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 <[email protected]>
>
> 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
