linux-kernel - Re: [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: <9ca0337d-e378-4de5-99be-1dfa1d4f8cff@web.de>
Date: Wed, 29 Jan 2025 10:40:18 +0100
From: Markus Elfring <Markus.Elfring@....de>
To: Easwar Hariharan <eahariha@...ux.microsoft.com>, cocci@...ia.fr
Cc: 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: [01/16] coccinelle: misc: secs_to_jiffies: Patch expressions too

>> …
>>> +++ 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?

Probably, yes.

>> 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/

I tend also to present possibilities for succinct SmPL code.
Unfortunately, software dependencies can trigger corresponding target conflicts.

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

Please take another look at related information sources.
Would you like to achieve any benefits from commutativity (for multiplications)?
https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/bd08cad3f802229dc629a13eefef2018c620e905/standard.iso#L241
https://github.com/coccinelle/coccinelle/blob/cca22217d1b4316224e80a18d0b08dd351234497/standard.iso#L241

Regards,
Markus