linux-kernel - Re: [PATCH v4] scripts/checkpatch.pl: remove _deferred and _deferred

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] [day] [month] [year] [list]

Message-ID: <Yh9ldXlLYz5/vyuf@alley>
Date:   Wed, 2 Mar 2022 13:39:17 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Maninder Singh <maninder1.s@...sung.com>
Cc:     Joe Perches <joe@...ches.com>,
        "apw@...onical.com" <apw@...onical.com>,
        "dwaipayanray1@...il.com" <dwaipayanray1@...il.com>,
        "lukas.bulwahn@...il.com" <lukas.bulwahn@...il.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Vaneet Narang <v.narang@...sung.com>
Subject: Re: [PATCH v4] scripts/checkpatch.pl: remove _deferred and
 _deferred_once false warning

On Wed 2022-03-02 10:02:59, Maninder Singh wrote:
> Hi,
> 
> > On Mon, 2022-02-28 at 13:07 +0530, Maninder Singh wrote:
> > > with commit 98e35f5894cf ("printk: git rid of [sched_delayed] message for
> > > printk_deferred") printk_deferred and printk_deferred_once requires
> > > LOGLEVEL in argument, but checkpatch.pl was not fixed and still reports
> > > it as warning:
> > > 
> > > WARNING: Possible unnecessary KERN_ALERT
> > > printk_deferred(KERN_ALERT "checking deferred\n");
> >  
> > I don't care for this patch at all.
> 
> But still it needs to be fixed, either with current suggested patch or with something else.
>  
> > I think it's be better to modify vprintk_emit when LOGLEVEL_SCHED
> > is used and if a KERN_<LEVEL> exists in the format, use it.
> > Perhaps instead:
> > ---
> >  kernel/printk/printk.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >  
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > index 1ce242f34d2be..6b5baf14f6d56 100644
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -2247,7 +2247,13 @@ asmlinkage int vprintk_emit(int facility, int level,
> >                  return 0;
> >  
> >          if (level == LOGLEVEL_SCHED) {
> > -                level = LOGLEVEL_DEFAULT;
> > +                level = printk_get_level(fmt);
> > +                if (level) {
> > +                        level -= '0';
> > +                        fmt = printk_skip_level(fmt);
> > +                } else {
> > +                        level = LOGLEVEL_DEFAULT;
> > +                }
> >                  in_sched = true;
> >          }
>  
> And I think it is already handled for printk (facility = 0).

Yes, this is not needed. The log level will be updated by parsing
"fmt" even LOGLEVEL_SCHED was used. It is well described by Maninder
below.


> after setting level to KERN_DEFAULT at first for in_sched case to make it normal
> printk case as it is changed from vprintk_store as per the string in printk based on
> current default loglevel.
> 
> int vprintk_store(int facility, int level,
>                   const struct dev_printk_info *dev_info,
>                   const char *fmt, va_list args)
> {
> ...
>         /* Extract log level or control flags. */
>         if (facility == 0)
>                 printk_parse_prefix(&prefix_buf[0], &level, &flags);
> ..
> 
> So, for printk, printk_deferred, printk_deferred_once, its level is picked if its provided.
> thus level in printk_deferred is "not unnecessary".
> And checkpatch.pl should not give w WARNING for this.

Alternative solution would be to introduce pr_<level>_deferred()
wrappers. But there is a pushback against it. printk_deferred()
is a whack-a-mole approach. There is a chance that it will get
obsoleted by the offload to kthreads, see
https://lore.kernel.org/r/20220207194323.273637-1-john.ogness@linutronix.de

Best Regards,
Petr