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:   Wed, 02 Feb 2022 15:22:25 +0530
From:   Maninder Singh <maninder1.s@...sung.com>
To:     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>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Vaneet Narang <v.narang@...sung.com>
Subject: RE: [PATCH RESEND v2] scripts/checkpatch.pl: remove _deferred and
 _deferred_once false warning

Hi,


>> printk_deferred and printk_deferred_once requires LOGLEVEL in argument,
>> but checkpatch.pl reports it as warning:
 
> When did that occur?  Please reference the specific commit.
> When printk_sched (now printk_deferred) was created it did not
> allow KERN_<LEVEL>.
 
> see commit 3ccf3e830615 ("printk/sched: Introduce special printk_sched() for those awkward moments")
 
I think with below commit:

98e35f5894cf208084688ec0c7bb7b713efc997f (printk: git rid of [sched_delayed] message for printk_deferred)

earlier it was passing hardcoded KERN_WARNING to all printk_deferred messages, but now it switched
to normal printk behavior.

-       if (in_sched)
-               text_len = scnprintf(text, sizeof(textbuf),
-                                    KERN_WARNING "[sched_delayed] ");
-
-       text_len += vscnprintf(text + text_len,
-                              sizeof(textbuf) - text_len, fmt, args);
+       text_len = vscnprintf(text, sizeof(textbuf), fmt, args);


I did not search that earlier, because we were fixing some issue in our local module code with printk_deferred
and then checkatch reported the issues, so thought of fixing it, becaue without level
pritk_deferred messages was shifted to default loglevel as done by normal printk.

So I thought it was designed to pass loglevel from starting stage and checjpatch reports falsely.
but seems checkpatch needs to fixed with that commit itself, because earlier it was not required to pass loglevel.


> There are many existing printk_deferred uses without KERN_<LEVEL>.

Either that needs to be fixed after that commit(98e35f5894cf) or their purpose is to
use KERN_DEFAULT log level i think.

Thanks,
Maninder Singh
 
 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ