linux-kernel - [PATCH v4 0/1] printf: add support for printing symbolic error names

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: <20191011133617.9963-1-linux@rasmusvillemoes.dk>
Date:   Fri, 11 Oct 2019 15:36:16 +0200
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Joe Perches <joe@...ches.com>, Petr Mladek <pmladek@...e.com>,
        Uwe Kleine-König <uwe@...ine-koenig.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Jonathan Corbet <corbet@....net>,
        Rasmus Villemoes <linux@...musvillemoes.dk>
Subject: [PATCH v4 0/1] printf: add support for printing symbolic error names

This is a bit much for under the ---, so a separate cover letter for
this single patch.

v4: Dropped Uwe's ack since it's changed quite a bit. Change
errcode->errname as suggested by Petr. Make it 'default y if PRINTK'
so it's available in the common case, while those who have gone to
great lengths to shave their kernel to the bare minimum are not
affected.

Also require the caller to use %pe instead of printing all ERR_PTRs
symbolically. I can see some value in having the call site explicitly
indicate that they're printing an ERR_PTR (i.e., having the %pe), but
I also still believe it would make sense to print ordinary %p,
ERR_PTR() symbolically instead of as a random hash value that's not
stable across reboots. But in the interest of getting this in, I'll
leave that for now. It's easy enough to do later by just changing the
"case 'e'" to do a break (with an updated comment), then do an
IS_ERR() check after the switch.

Something I've glossed over in previous versions, and nobody has
commented on, is that I produced "ENOSPC" while the 'fallback' would
print "-28" (i.e., there's no minus in the symbolic case). I don't
care much either way, but here I've tried to show how I'd do it if we
want the minus also in the symbolic case. At first, I tried just using
the standard idiom

  if (buf < end)
    *buf = '-';
  buf++;

followed by string(sym, ...). However, that doesn't work very well if
one wants to honour field width - for that to work, the whole string
including - must come from the errname() lookup and be handled by
string(). The simplest seemed to be to just unconditionally prefix all
strings with "-" when building the tables, and then change errname()
back to supporting both positive and negative error numbers.

As I said, I don't care much either way, so if somebody thinks this is
too complicated and would prefer just printing "ENOSPC" (because
really the minus doesn't offer much except that it's perhaps easier to
recognize for a kernel developer) just speak up.

I've also given some thought to Petr's suggestion of how to improve
the handling of ERR_PTRs that are accidentally passed to
%p<something-that-would-dereference-it>. But I'll do that as a
separate series on top - for now I think this should go into -next if
nobody complains loudly.

Rasmus Villemoes (1):
  printf: add support for printing symbolic error names

 Documentation/core-api/printk-formats.rst |  12 ++
 include/linux/errname.h                   |  16 ++
 lib/Kconfig.debug                         |   9 +
 lib/Makefile                              |   1 +
 lib/errname.c                             | 222 ++++++++++++++++++++++
 lib/test_printf.c                         |  24 +++
 lib/vsprintf.c                            |  27 +++
 7 files changed, 311 insertions(+)
 create mode 100644 include/linux/errname.h
 create mode 100644 lib/errname.c

-- 
2.20.1