Messages in this thread Patch in this message | | | Subject | Re: [PATCH v4 1/1] printf: add support for printing symbolic error names | From | Rasmus Villemoes <> | Date | Tue, 15 Oct 2019 14:17:43 +0200 |
| |
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
| |