linux-kernel - Re: printk meeting at LPC

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: <20190917075216.agzoy6cnol5eio6y@pathway.suse.cz>
Date:   Tue, 17 Sep 2019 09:52:16 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Daniel Vetter <daniel.vetter@...ll.ch>,
        AndreaParri <parri.andrea@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        Paul Turner <pjt@...gle.com>,
        Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        Peter Zijlstra <peterz@...radead.org>,
        John Ogness <john.ogness@...utronix.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        LinusTorvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Theodore Ts'o <tytso@....edu>,
        PraritBhargava <prarit@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: printk meeting at LPC

On Mon 2019-09-16 09:43:14, Steven Rostedt wrote:
> On Mon, 16 Sep 2019 12:46:24 +0200
> Petr Mladek <pmladek@...e.com> wrote:
> > > By the way, do we need to keep printk() return bytes like printf() ?
> > > Maybe we can make printk() return "void", for almost nobody can do
> > > meaningful things with the return value.  
> > 
> > It is true that I have never seen anyone checking the return value.
> > On the other hand, it is a minor detail. And I would prefer to stay
> > compatible with the userland printf() as much as possible.
> 
> I understand your wanting to keep compatibility with printf(), but I
> would suggest that we only do so if it doesn't complicate any of the
> design. I'm actually leaning on recommending that we remove the return
> value, to prevent there becoming a dependency on it. I don't see any
> reason to have the "number of bytes processed" as the return value
> being useful within the kernel.

Heh, I did some grepping and the return value is actually used on
three locations:

$> git grep "= printk("
drivers/scsi/aic7xxx/aic79xx_core.c:	printed = printk("%s[0x%x]", name, value);
drivers/scsi/aic7xxx/aic79xx_core.c:		printed += printk(" ");
drivers/scsi/aic7xxx/aic79xx_core.c:			printed += printk("%s%s",
drivers/scsi/aic7xxx/aic79xx_core.c:		printed += printk(") ");
drivers/scsi/aic7xxx/aic79xx_core.c:		printed += printk(" ");
drivers/scsi/aic7xxx/aic79xx_core.c:		cur_col = printk("\n%3d FIFO_USE[0x%x] ", SCB_GET_TAG(scb),
drivers/scsi/aic7xxx/aic79xx_core.c:		cur_col += printk("SHADDR = 0x%x%x, SHCNT = 0x%x ",
drivers/scsi/aic7xxx/aic79xx_core.c:		cur_col += printk("HADDR = 0x%x%x, HCNT = 0x%x ",
drivers/scsi/aic7xxx/aic7xxx_core.c:	printed  = printk("%s[0x%x]", name, value);
drivers/scsi/aic7xxx/aic7xxx_core.c:		printed += printk(" ");
drivers/scsi/aic7xxx/aic7xxx_core.c:			printed += printk("%s%s",
drivers/scsi/aic7xxx/aic7xxx_core.c:		printed += printk(") ");
drivers/scsi/aic7xxx/aic7xxx_core.c:		printed += printk(" ");
drivers/scsi/aic7xxx/aic7xxx_core.c:		cur_col  = printk("\n%3d ", i);
drivers/scsi/aic7xxx/aic7xxx_core.c:		cur_col  = printk("\n%3d ", scb->hscb->tag);
drivers/scsi/libsas/sas_ata.c:	r = printk("%s" SAS_FMT "ata%u: %s: %pV",
kernel/locking/lockdep.c:			len += printk("%*s   %s", depth, "", usage_str[bit]);
kernel/locking/lockdep.c:			len += printk(KERN_CONT " at:\n");

It is probably not a big deal. For example, lockdep uses the value
just for formatting (extra spaces) when printing backtrace.

I agree that it does not make sense to return the value if it
complicates the code too much. Well, we will need to count
the string length also from another reason (reservation).

Best Regards,
Petr