linux-kernel - Re: [PATCH 01/16] coccinelle: misc: secs_to

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: <2402812d-b818-4d1b-9653-767c9cd89dda@linux.microsoft.com>
Date: Tue, 28 Jan 2025 21:05:58 -0800
From: Easwar Hariharan <eahariha@...ux.microsoft.com>
To: Markus Elfring <Markus.Elfring@....de>
Cc: cocci@...ia.fr, eahariha@...ux.microsoft.com,
 LKML <linux-kernel@...r.kernel.org>, kernel-janitors@...r.kernel.org,
 linux-block@...r.kernel.org, linux-btrfs@...r.kernel.org,
 linux-ide@...r.kernel.org, linux-nvme@...ts.infradead.org,
 linux-pm@...r.kernel.org, linux-rdma@...r.kernel.org,
 linux-scsi@...r.kernel.org, linux-sound@...r.kernel.org,
 linux-spi@...r.kernel.org, linux-xfs@...r.kernel.org,
 ceph-devel@...r.kernel.org, platform-driver-x86@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, ibm-acpi-devel@...ts.sourceforge.net,
 imx@...ts.linux.dev, kernel@...gutronix.de,
 linux-arm-kernel@...ts.infradead.org,
 Andrew Morton <akpm@...ux-foundation.org>, Carlos Maiolino <cem@...nel.org>,
 Chris Mason <clm@...com>, Christoph Hellwig <hch@....de>,
 Damien Le Moal <dlemoal@...nel.org>, "Darrick J. Wong" <djwong@...nel.org>,
 David Sterba <dsterba@...e.com>, Dick Kennedy <dick.kennedy@...adcom.com>,
 Dongsheng Yang <dongsheng.yang@...ystack.cn>,
 Fabio Estevam <festevam@...il.com>, Frank Li <Frank.Li@....com>,
 Hans de Goede <hdegoede@...hat.com>,
 Henrique de Moraes Holschuh <hmh@....eng.br>,
 James Bottomley <James.Bottomley@...senPartnership.com>,
 James Smart <james.smart@...adcom.com>, Jaroslav Kysela <perex@...ex.cz>,
 Jason Gunthorpe <jgg@...pe.ca>, Jens Axboe <axboe@...nel.dk>,
 Josef Bacik <josef@...icpanda.com>, Julia Lawall <Julia.Lawall@...ia.fr>,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
 Ilya Dryomov <idryomov@...il.com>,
 Kalesh Anakkur Purayil <kalesh-anakkur.purayil@...adcom.com>,
 Keith Busch <kbusch@...nel.org>, Leon Romanovsky <leon@...nel.org>,
 Mark Brown <broonie@...nel.org>,
 "Martin K. Petersen" <martin.petersen@...cle.com>,
 Nicolas Palix <nicolas.palix@...g.fr>, Niklas Cassel <cassel@...nel.org>,
 Oded Gabbay <ogabbay@...nel.org>, Ricardo Ribalda <ribalda@...gle.com>,
 Sagi Grimberg <sagi@...mberg.me>, Sascha Hauer <s.hauer@...gutronix.de>,
 Sebastian Reichel <sre@...nel.org>,
 Selvin Xavier <selvin.xavier@...adcom.com>, Shawn Guo <shawnguo@...nel.org>,
 Shyam Sundar S K <Shyam-sundar.S-k@....com>, Takashi Iwai <tiwai@...e.com>,
 Victor Gambier <victor.gambier@...ia.fr>, Xiubo Li <xiubli@...hat.com>,
 Yaron Avizrat <yaron.avizrat@...el.com>
Subject: Re: [PATCH 01/16] coccinelle: misc: secs_to_jiffies: Patch
 expressions too

On 1/28/2025 1:02 PM, Markus Elfring wrote:
>> Teach the script to suggest conversions for timeout patterns where the
>> arguments to msecs_to_jiffies() are expressions as well.
> 
> I propose to take another look at implementation details for such a script variant
> according to the semantic patch language.
> 
> 
> …
>> +++ b/scripts/coccinelle/misc/secs_to_jiffies.cocci
>> @@ -11,12 +11,22 @@
>>
>>  virtual patch
> …
>> -@...ends on patch@ constant C; @@
>> +@...ends on patch@
>> +expression E;
>> +@@
>>
>> -- msecs_to_jiffies(C * MSEC_PER_SEC)
>> -+ secs_to_jiffies(C)
>> +-msecs_to_jiffies
>> ++secs_to_jiffies
>> + (E
>> +- * \( 1000 \| MSEC_PER_SEC \)
>> + )
> 
> 1. I do not see a need to keep an SmPL rule for the handling of constants
>    (or literals) after the suggested extension for expressions.

Can you explain why? Would the expression rule also address the cases
where it's a constant or literal?

> 2. I find it nice that you indicate an attempt to make the shown SmPL code
>    a bit more succinct.
>    Unfortunately, further constraints should be taken better into account
>    for the current handling of isomorphisms (and corresponding SmPL disjunctions).
>    Thus I would find an SmPL rule (like the following) more appropriate.
> 

Sorry, I couldn't follow your sentence construction or reasoning here. I
don't see how my patch is deficient, or different from your suggestion
below, especially given that it follows your feedback from part 1:
https://lore.kernel.org/all/9088f9a2-c4ab-4098-a255-25120df5c497@web.de/

Can you point out specifically what SmPL isomorphisms or disjunctions
are broken with the patch in its current state?

Thanks,
Easwar