linux-kernel - Re: [Cocci] [PATCH v3] Coccinelle: Script to replace allocate and memset with zalloc functions

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:	Mon, 1 Aug 2016 14:03:25 +0200 (CEST)
From:	Julia Lawall <julia.lawall@...6.fr>
To:	SF Markus Elfring <elfring@...rs.sourceforge.net>
cc:	Amitoj Kaur Chawla <amitoj1606@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Coccinelle <cocci@...teme.lip6.fr>,
	Gilles Muller <Gilles.Muller@...6.fr>,
	Michal Marek <mmarek@...e.com>,
	Nicolas Palix <nicolas.palix@...g.fr>
Subject: Re: [Cocci] [PATCH v3] Coccinelle: Script to replace allocate and
 memset with zalloc functions

On Mon, 1 Aug 2016, SF Markus Elfring wrote:

> >> 1. Would it make sense to merge such SmPL rules into one
> >>    so that code duplication could be reduced a bit
> >>    in such a script?
> >
> > I think it would suffer in readability.
>
> How do you think about the following SmPL script example?
>
> @vz_combined
>  depends on patch && !context && !org && !report@
> type T;
> T* pointer;
> +statement S;
> expression express;
> @@
>  pointer =
> -          vmalloc
> +          vzalloc
>            (...);
>  if (!d)
>     S
> -memset(d, 0, sizeof(
> (
> -T
> |
> -*(express)
> )
> -));

OK, I thought you meant to make a big disjunctions for all of the before
and after functions.  This is a little better because it is bounded in
size.  But I don't understand why you have introduced the variable
express.  Normally one wants the cleared space to be the allocated size,
which is normally the size of *pointer.

The performance issue is that disjunctions on expressions, eg (A | B), are
implemented as (A | (!A & B)), ie with a negation of all the previous
options &d with each option.  So it is better to avoid very large
disjunctions on expressions.

julia

>
>
> > Perhaps in performance as well.
>
> I admit that I am unsure about the run-time characteristics
> for my suggestion.
>
> Regards,
> Markus
>