netdev - Re: [PATCH] net: ethernet: renesas: rswitch: Fix MAC address info

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]

Date:   Thu, 17 Nov 2022 10:38:16 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Leon Romanovsky <leon@...nel.org>
Cc:     Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>,
        Dan Carpenter <error27@...il.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>
Subject: Re: [PATCH] net: ethernet: renesas: rswitch: Fix MAC address info

Hi Leon,

On Thu, Nov 17, 2022 at 10:14 AM Leon Romanovsky <leon@...nel.org> wrote:
> On Thu, Nov 17, 2022 at 09:59:55AM +0100, Geert Uytterhoeven wrote:
> > On Thu, Nov 17, 2022 at 9:58 AM Yoshihiro Shimoda
> > <yoshihiro.shimoda.uh@...esas.com> wrote:
> > > > From: Leon Romanovsky, Sent: Thursday, November 17, 2022 3:09 PM
> > > > > --- a/drivers/net/ethernet/renesas/rswitch.c
> > > > > +++ b/drivers/net/ethernet/renesas/rswitch.c
> > > > > @@ -1714,7 +1714,7 @@ static int rswitch_init(struct rswitch_private *priv)
> > > > >     }
> > > > >
> > > > >     for (i = 0; i < RSWITCH_NUM_PORTS; i++)
> > > > > -           netdev_info(priv->rdev[i]->ndev, "MAC address %pMn",
> > > > > +           netdev_info(priv->rdev[i]->ndev, "MAC address %pM\n",
> > > >
> > > > You can safely drop '\n' from here. It is not needed while printing one
> > > > line.
> > >
> > > Oh, I didn't know that. I'll remove '\n' from here on v2 patch.
> >
> > Please don't remove it.  The convention is to have the newlines.
>
> Can you please explain why?

I'm quite sure this was discussed in the context of commits
5fd29d6ccbc98884 ("printk: clean up handling of log-levels and
newlines") and 4bcc595ccd80decb ("printk: reinstate KERN_CONT for
printing continuation lines"), but I couldn't find a pointer to an
official statement.

I did find[1], which states:

    The printk subsystem will, for every printk, check
    if the last printk has a newline termination and if
    it doesn't and the current printk does not start with
    KERN_CONT will insert a newline.

    The negative to this approach is the last printk,
    if it does not have a newline, is buffered and not
    emitted until another printk occurs.

    There is also the (now small) possibility that
    multiple concurrent kernel threads or processes
    could interleave printks without a terminating
    newline and a different process could emit a
    printk that starts with KERN_CONT and the emitted
    message could be garbled.

[1] https://lore.kernel.org/all/b867ee8a02043ec6b18c9330bfe3a091d66c816c.camel@perches.com

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds