All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Coccinelle: alloc_cast: Add more memory allocating functions to the list
@ 2018-01-13 15:56 ` Himanshu Jha
  0 siblings, 0 replies; 21+ messages in thread
From: Himanshu Jha @ 2018-01-13 15:56 UTC (permalink / raw)
  To: yamada.masahiro
  Cc: Julia.Lawall, Gilles.Muller, nicolas.palix, michal.lkml, cocci,
	linux-kernel, Himanshu Jha

Add more memory allocating functions that are frequently used in the kernel
code to the existing list and remove the useless casts where it is
unnecessary.

But preserve those casts having __attribute__ such as __force, __iomem,
etc which are used by Sparse in the static analysis of the code.

Also remove two blank lines at EOF.

Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
---
 scripts/coccinelle/api/alloc/alloc_cast.cocci | 92 +++++++++++++++++++++------
 1 file changed, 71 insertions(+), 21 deletions(-)

diff --git a/scripts/coccinelle/api/alloc/alloc_cast.cocci b/scripts/coccinelle/api/alloc/alloc_cast.cocci
index 6c308ee..408ee38 100644
--- a/scripts/coccinelle/api/alloc/alloc_cast.cocci
+++ b/scripts/coccinelle/api/alloc/alloc_cast.cocci
@@ -5,10 +5,11 @@
 //# kmalloc, kzalloc, kcalloc, kmem_cache_alloc, kmem_cache_zalloc,
 //# kmem_cache_alloc_node, kmalloc_node and kzalloc_node and removes
 //# the casting as it is not required. The result in the patch case may
-//#need some reformatting.
+//# need some reformatting.
 //
 // Confidence: High
-// Copyright: 2014, Himangi Saraogi  GPLv2.
+// Copyright: (C) 2014 Himangi Saraogi GPLv2.
+// Copyright: (C) 2017 Himanshu Jha GPLv2.
 // Comments:
 // Options: --no-includes --include-headers
 //
@@ -18,55 +19,104 @@ virtual patch
 virtual org
 virtual report
 
+@initialize:python@
+@@
+import re
+pattern = '__'
+m = re.compile(pattern)
+
+@r1 depends on context || patch@
+type T;
+@@
+
+  (T *)
+  \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
+   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\|vmalloc\|vzalloc\|
+   dma_alloc_coherent\|dma_zalloc_coherent\|devm_kmalloc\|devm_kzalloc\|
+   kvmalloc\|kvzalloc\|kvmalloc_node\|kvzalloc_node\|pci_alloc_consistent\|
+   pci_zalloc_consistent\|kmem_alloc\|kmem_zalloc\|kmem_zone_alloc\|
+   kmem_zone_zalloc\|vmalloc_node\|vzalloc_node\)(...)
+
 //----------------------------------------------------------
 //  For context mode
 //----------------------------------------------------------
 
-@depends on context@
-type T;
+@script:python depends on context@
+t << r1.T;
+@@
+
+if m.search(t) != None:
+        cocci.include_match(False)
+
+@depends on context && r1@
+type r1.T;
 @@
 
 * (T *)
   \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
-   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\)(...)
+   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\|vmalloc\|vzalloc\|
+   dma_alloc_coherent\|dma_zalloc_coherent\|devm_kmalloc\|devm_kzalloc\|
+   kvmalloc\|kvzalloc\|kvmalloc_node\|kvzalloc_node\|pci_alloc_consistent\|
+   pci_zalloc_consistent\|kmem_alloc\|kmem_zalloc\|kmem_zone_alloc\|
+   kmem_zone_zalloc\|vmalloc_node\|vzalloc_node\)(...)
 
 //----------------------------------------------------------
 //  For patch mode
 //----------------------------------------------------------
 
-@depends on patch@
-type T;
+@script:python depends on patch@
+t << r1.T;
+@@
+
+if m.search(t) != None:
+        cocci.include_match(False)
+
+@depends on patch && r1@
+type r1.T;
 @@
 
 - (T *)
-  (\(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
-   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\)(...))
+  \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
+   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\|vmalloc\|vzalloc\|
+   dma_alloc_coherent\|dma_zalloc_coherent\|devm_kmalloc\|devm_kzalloc\|
+   kvmalloc\|kvzalloc\|kvmalloc_node\|kvzalloc_node\|pci_alloc_consistent\|
+   pci_zalloc_consistent\|kmem_alloc\|kmem_zalloc\|kmem_zone_alloc\|
+   kmem_zone_zalloc\|vmalloc_node\|vzalloc_node\)(...)
 
 //----------------------------------------------------------
 //  For org and report mode
 //----------------------------------------------------------
 
-@r depends on org || report@
+@r2 depends on org || report@
 type T;
 position p;
 @@
 
- (T@p *)\(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
-   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\)(...)
+ (T@p *)
+  \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
+   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\|vmalloc\|vzalloc\|
+   dma_alloc_coherent\|dma_zalloc_coherent\|devm_kmalloc\|devm_kzalloc\|
+   kvmalloc\|kvzalloc\|kvmalloc_node\|kvzalloc_node\|pci_alloc_consistent\|
+   pci_zalloc_consistent\|kmem_alloc\|kmem_zalloc\|kmem_zone_alloc\|
+   kmem_zone_zalloc\|vmalloc_node\|vzalloc_node\)(...)
 
 @script:python depends on org@
-p << r.p;
-t << r.T;
+p << r2.p;
+t << r2.T;
 @@
 
-coccilib.org.print_safe_todo(p[0], t)
+if m.search(t) != None:
+	cocci.include_match(False)
+else:
+	coccilib.org.print_safe_todo(p[0], t)
 
 @script:python depends on report@
-p << r.p;
-t << r.T;
+p << r2.p;
+t << r2.T;
 @@
 
-msg="WARNING: casting value returned by memory allocation function to (%s *) is useless." % (t)
-coccilib.report.print_report(p[0], msg)
-
-
+if m.search(t) != None:
+	cocci.include_match(False)
+else:
+	msg="WARNING: casting value returned by memory allocation function to (%s *) is useless." % (t)
+	coccilib.report.print_report(p[0], msg)
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [Cocci] [PATCH] Coccinelle: alloc_cast: Add more memory allocating functions to the list
@ 2018-01-13 15:56 ` Himanshu Jha
  0 siblings, 0 replies; 21+ messages in thread
From: Himanshu Jha @ 2018-01-13 15:56 UTC (permalink / raw)
  To: cocci

Add more memory allocating functions that are frequently used in the kernel
code to the existing list and remove the useless casts where it is
unnecessary.

But preserve those casts having __attribute__ such as __force, __iomem,
etc which are used by Sparse in the static analysis of the code.

Also remove two blank lines at EOF.

Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
---
 scripts/coccinelle/api/alloc/alloc_cast.cocci | 92 +++++++++++++++++++++------
 1 file changed, 71 insertions(+), 21 deletions(-)

diff --git a/scripts/coccinelle/api/alloc/alloc_cast.cocci b/scripts/coccinelle/api/alloc/alloc_cast.cocci
index 6c308ee..408ee38 100644
--- a/scripts/coccinelle/api/alloc/alloc_cast.cocci
+++ b/scripts/coccinelle/api/alloc/alloc_cast.cocci
@@ -5,10 +5,11 @@
 //# kmalloc, kzalloc, kcalloc, kmem_cache_alloc, kmem_cache_zalloc,
 //# kmem_cache_alloc_node, kmalloc_node and kzalloc_node and removes
 //# the casting as it is not required. The result in the patch case may
-//#need some reformatting.
+//# need some reformatting.
 //
 // Confidence: High
-// Copyright: 2014, Himangi Saraogi  GPLv2.
+// Copyright: (C) 2014 Himangi Saraogi GPLv2.
+// Copyright: (C) 2017 Himanshu Jha GPLv2.
 // Comments:
 // Options: --no-includes --include-headers
 //
@@ -18,55 +19,104 @@ virtual patch
 virtual org
 virtual report
 
+ at initialize:python@
+@@
+import re
+pattern = '__'
+m = re.compile(pattern)
+
+ at r1 depends on context || patch@
+type T;
+@@
+
+  (T *)
+  \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
+   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\|vmalloc\|vzalloc\|
+   dma_alloc_coherent\|dma_zalloc_coherent\|devm_kmalloc\|devm_kzalloc\|
+   kvmalloc\|kvzalloc\|kvmalloc_node\|kvzalloc_node\|pci_alloc_consistent\|
+   pci_zalloc_consistent\|kmem_alloc\|kmem_zalloc\|kmem_zone_alloc\|
+   kmem_zone_zalloc\|vmalloc_node\|vzalloc_node\)(...)
+
 //----------------------------------------------------------
 //  For context mode
 //----------------------------------------------------------
 
- at depends on context@
-type T;
+ at script:python depends on context@
+t << r1.T;
+@@
+
+if m.search(t) != None:
+        cocci.include_match(False)
+
+ at depends on context && r1@
+type r1.T;
 @@
 
 * (T *)
   \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
-   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\)(...)
+   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\|vmalloc\|vzalloc\|
+   dma_alloc_coherent\|dma_zalloc_coherent\|devm_kmalloc\|devm_kzalloc\|
+   kvmalloc\|kvzalloc\|kvmalloc_node\|kvzalloc_node\|pci_alloc_consistent\|
+   pci_zalloc_consistent\|kmem_alloc\|kmem_zalloc\|kmem_zone_alloc\|
+   kmem_zone_zalloc\|vmalloc_node\|vzalloc_node\)(...)
 
 //----------------------------------------------------------
 //  For patch mode
 //----------------------------------------------------------
 
- at depends on patch@
-type T;
+ at script:python depends on patch@
+t << r1.T;
+@@
+
+if m.search(t) != None:
+        cocci.include_match(False)
+
+ at depends on patch && r1@
+type r1.T;
 @@
 
 - (T *)
-  (\(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
-   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\)(...))
+  \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
+   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\|vmalloc\|vzalloc\|
+   dma_alloc_coherent\|dma_zalloc_coherent\|devm_kmalloc\|devm_kzalloc\|
+   kvmalloc\|kvzalloc\|kvmalloc_node\|kvzalloc_node\|pci_alloc_consistent\|
+   pci_zalloc_consistent\|kmem_alloc\|kmem_zalloc\|kmem_zone_alloc\|
+   kmem_zone_zalloc\|vmalloc_node\|vzalloc_node\)(...)
 
 //----------------------------------------------------------
 //  For org and report mode
 //----------------------------------------------------------
 
- at r depends on org || report@
+ at r2 depends on org || report@
 type T;
 position p;
 @@
 
- (T at p *)\(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
-   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\)(...)
+ (T@p *)
+  \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
+   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\|vmalloc\|vzalloc\|
+   dma_alloc_coherent\|dma_zalloc_coherent\|devm_kmalloc\|devm_kzalloc\|
+   kvmalloc\|kvzalloc\|kvmalloc_node\|kvzalloc_node\|pci_alloc_consistent\|
+   pci_zalloc_consistent\|kmem_alloc\|kmem_zalloc\|kmem_zone_alloc\|
+   kmem_zone_zalloc\|vmalloc_node\|vzalloc_node\)(...)
 
 @script:python depends on org@
-p << r.p;
-t << r.T;
+p << r2.p;
+t << r2.T;
 @@
 
-coccilib.org.print_safe_todo(p[0], t)
+if m.search(t) != None:
+	cocci.include_match(False)
+else:
+	coccilib.org.print_safe_todo(p[0], t)
 
 @script:python depends on report@
-p << r.p;
-t << r.T;
+p << r2.p;
+t << r2.T;
 @@
 
-msg="WARNING: casting value returned by memory allocation function to (%s *) is useless." % (t)
-coccilib.report.print_report(p[0], msg)
-
-
+if m.search(t) != None:
+	cocci.include_match(False)
+else:
+	msg="WARNING: casting value returned by memory allocation function to (%s *) is useless." % (t)
+	coccilib.report.print_report(p[0], msg)
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: [PATCH] Coccinelle: alloc_cast: Add more memory allocating functions to the list
  2018-01-13 15:56 ` [Cocci] " Himanshu Jha
@ 2018-01-13 16:24   ` Julia Lawall
  -1 siblings, 0 replies; 21+ messages in thread
From: Julia Lawall @ 2018-01-13 16:24 UTC (permalink / raw)
  To: Himanshu Jha
  Cc: yamada.masahiro, Julia.Lawall, Gilles Muller, nicolas.palix,
	michal.lkml, cocci, linux-kernel



On Sat, 13 Jan 2018, Himanshu Jha wrote:

> Add more memory allocating functions that are frequently used in the kernel
> code to the existing list and remove the useless casts where it is
> unnecessary.
>
> But preserve those casts having __attribute__ such as __force, __iomem,
> etc which are used by Sparse in the static analysis of the code.
>
> Also remove two blank lines at EOF.
>
> Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>

Acked-by: Julia Lawall <julia.lawall@lip6.fr>

> ---
>  scripts/coccinelle/api/alloc/alloc_cast.cocci | 92 +++++++++++++++++++++------
>  1 file changed, 71 insertions(+), 21 deletions(-)
>
> diff --git a/scripts/coccinelle/api/alloc/alloc_cast.cocci b/scripts/coccinelle/api/alloc/alloc_cast.cocci
> index 6c308ee..408ee38 100644
> --- a/scripts/coccinelle/api/alloc/alloc_cast.cocci
> +++ b/scripts/coccinelle/api/alloc/alloc_cast.cocci
> @@ -5,10 +5,11 @@
>  //# kmalloc, kzalloc, kcalloc, kmem_cache_alloc, kmem_cache_zalloc,
>  //# kmem_cache_alloc_node, kmalloc_node and kzalloc_node and removes
>  //# the casting as it is not required. The result in the patch case may
> -//#need some reformatting.
> +//# need some reformatting.
>  //
>  // Confidence: High
> -// Copyright: 2014, Himangi Saraogi  GPLv2.
> +// Copyright: (C) 2014 Himangi Saraogi GPLv2.
> +// Copyright: (C) 2017 Himanshu Jha GPLv2.
>  // Comments:
>  // Options: --no-includes --include-headers
>  //
> @@ -18,55 +19,104 @@ virtual patch
>  virtual org
>  virtual report
>
> +@initialize:python@
> +@@
> +import re
> +pattern = '__'
> +m = re.compile(pattern)
> +
> +@r1 depends on context || patch@
> +type T;
> +@@
> +
> +  (T *)
> +  \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
> +   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\|vmalloc\|vzalloc\|
> +   dma_alloc_coherent\|dma_zalloc_coherent\|devm_kmalloc\|devm_kzalloc\|
> +   kvmalloc\|kvzalloc\|kvmalloc_node\|kvzalloc_node\|pci_alloc_consistent\|
> +   pci_zalloc_consistent\|kmem_alloc\|kmem_zalloc\|kmem_zone_alloc\|
> +   kmem_zone_zalloc\|vmalloc_node\|vzalloc_node\)(...)
> +
>  //----------------------------------------------------------
>  //  For context mode
>  //----------------------------------------------------------
>
> -@depends on context@
> -type T;
> +@script:python depends on context@
> +t << r1.T;
> +@@
> +
> +if m.search(t) != None:
> +        cocci.include_match(False)
> +
> +@depends on context && r1@
> +type r1.T;
>  @@
>
>  * (T *)
>    \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
> -   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\)(...)
> +   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\|vmalloc\|vzalloc\|
> +   dma_alloc_coherent\|dma_zalloc_coherent\|devm_kmalloc\|devm_kzalloc\|
> +   kvmalloc\|kvzalloc\|kvmalloc_node\|kvzalloc_node\|pci_alloc_consistent\|
> +   pci_zalloc_consistent\|kmem_alloc\|kmem_zalloc\|kmem_zone_alloc\|
> +   kmem_zone_zalloc\|vmalloc_node\|vzalloc_node\)(...)
>
>  //----------------------------------------------------------
>  //  For patch mode
>  //----------------------------------------------------------
>
> -@depends on patch@
> -type T;
> +@script:python depends on patch@
> +t << r1.T;
> +@@
> +
> +if m.search(t) != None:
> +        cocci.include_match(False)
> +
> +@depends on patch && r1@
> +type r1.T;
>  @@
>
>  - (T *)
> -  (\(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
> -   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\)(...))
> +  \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
> +   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\|vmalloc\|vzalloc\|
> +   dma_alloc_coherent\|dma_zalloc_coherent\|devm_kmalloc\|devm_kzalloc\|
> +   kvmalloc\|kvzalloc\|kvmalloc_node\|kvzalloc_node\|pci_alloc_consistent\|
> +   pci_zalloc_consistent\|kmem_alloc\|kmem_zalloc\|kmem_zone_alloc\|
> +   kmem_zone_zalloc\|vmalloc_node\|vzalloc_node\)(...)
>
>  //----------------------------------------------------------
>  //  For org and report mode
>  //----------------------------------------------------------
>
> -@r depends on org || report@
> +@r2 depends on org || report@
>  type T;
>  position p;
>  @@
>
> - (T@p *)\(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
> -   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\)(...)
> + (T@p *)
> +  \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
> +   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\|vmalloc\|vzalloc\|
> +   dma_alloc_coherent\|dma_zalloc_coherent\|devm_kmalloc\|devm_kzalloc\|
> +   kvmalloc\|kvzalloc\|kvmalloc_node\|kvzalloc_node\|pci_alloc_consistent\|
> +   pci_zalloc_consistent\|kmem_alloc\|kmem_zalloc\|kmem_zone_alloc\|
> +   kmem_zone_zalloc\|vmalloc_node\|vzalloc_node\)(...)
>
>  @script:python depends on org@
> -p << r.p;
> -t << r.T;
> +p << r2.p;
> +t << r2.T;
>  @@
>
> -coccilib.org.print_safe_todo(p[0], t)
> +if m.search(t) != None:
> +	cocci.include_match(False)
> +else:
> +	coccilib.org.print_safe_todo(p[0], t)
>
>  @script:python depends on report@
> -p << r.p;
> -t << r.T;
> +p << r2.p;
> +t << r2.T;
>  @@
>
> -msg="WARNING: casting value returned by memory allocation function to (%s *) is useless." % (t)
> -coccilib.report.print_report(p[0], msg)
> -
> -
> +if m.search(t) != None:
> +	cocci.include_match(False)
> +else:
> +	msg="WARNING: casting value returned by memory allocation function to (%s *) is useless." % (t)
> +	coccilib.report.print_report(p[0], msg)
> --
> 2.7.4
>
>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [Cocci] [PATCH] Coccinelle: alloc_cast: Add more memory allocating functions to the list
@ 2018-01-13 16:24   ` Julia Lawall
  0 siblings, 0 replies; 21+ messages in thread
From: Julia Lawall @ 2018-01-13 16:24 UTC (permalink / raw)
  To: cocci



On Sat, 13 Jan 2018, Himanshu Jha wrote:

> Add more memory allocating functions that are frequently used in the kernel
> code to the existing list and remove the useless casts where it is
> unnecessary.
>
> But preserve those casts having __attribute__ such as __force, __iomem,
> etc which are used by Sparse in the static analysis of the code.
>
> Also remove two blank lines at EOF.
>
> Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>

Acked-by: Julia Lawall <julia.lawall@lip6.fr>

> ---
>  scripts/coccinelle/api/alloc/alloc_cast.cocci | 92 +++++++++++++++++++++------
>  1 file changed, 71 insertions(+), 21 deletions(-)
>
> diff --git a/scripts/coccinelle/api/alloc/alloc_cast.cocci b/scripts/coccinelle/api/alloc/alloc_cast.cocci
> index 6c308ee..408ee38 100644
> --- a/scripts/coccinelle/api/alloc/alloc_cast.cocci
> +++ b/scripts/coccinelle/api/alloc/alloc_cast.cocci
> @@ -5,10 +5,11 @@
>  //# kmalloc, kzalloc, kcalloc, kmem_cache_alloc, kmem_cache_zalloc,
>  //# kmem_cache_alloc_node, kmalloc_node and kzalloc_node and removes
>  //# the casting as it is not required. The result in the patch case may
> -//#need some reformatting.
> +//# need some reformatting.
>  //
>  // Confidence: High
> -// Copyright: 2014, Himangi Saraogi  GPLv2.
> +// Copyright: (C) 2014 Himangi Saraogi GPLv2.
> +// Copyright: (C) 2017 Himanshu Jha GPLv2.
>  // Comments:
>  // Options: --no-includes --include-headers
>  //
> @@ -18,55 +19,104 @@ virtual patch
>  virtual org
>  virtual report
>
> + at initialize:python@
> +@@
> +import re
> +pattern = '__'
> +m = re.compile(pattern)
> +
> + at r1 depends on context || patch@
> +type T;
> +@@
> +
> +  (T *)
> +  \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
> +   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\|vmalloc\|vzalloc\|
> +   dma_alloc_coherent\|dma_zalloc_coherent\|devm_kmalloc\|devm_kzalloc\|
> +   kvmalloc\|kvzalloc\|kvmalloc_node\|kvzalloc_node\|pci_alloc_consistent\|
> +   pci_zalloc_consistent\|kmem_alloc\|kmem_zalloc\|kmem_zone_alloc\|
> +   kmem_zone_zalloc\|vmalloc_node\|vzalloc_node\)(...)
> +
>  //----------------------------------------------------------
>  //  For context mode
>  //----------------------------------------------------------
>
> - at depends on context@
> -type T;
> + at script:python depends on context@
> +t << r1.T;
> +@@
> +
> +if m.search(t) != None:
> +        cocci.include_match(False)
> +
> + at depends on context && r1@
> +type r1.T;
>  @@
>
>  * (T *)
>    \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
> -   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\)(...)
> +   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\|vmalloc\|vzalloc\|
> +   dma_alloc_coherent\|dma_zalloc_coherent\|devm_kmalloc\|devm_kzalloc\|
> +   kvmalloc\|kvzalloc\|kvmalloc_node\|kvzalloc_node\|pci_alloc_consistent\|
> +   pci_zalloc_consistent\|kmem_alloc\|kmem_zalloc\|kmem_zone_alloc\|
> +   kmem_zone_zalloc\|vmalloc_node\|vzalloc_node\)(...)
>
>  //----------------------------------------------------------
>  //  For patch mode
>  //----------------------------------------------------------
>
> - at depends on patch@
> -type T;
> + at script:python depends on patch@
> +t << r1.T;
> +@@
> +
> +if m.search(t) != None:
> +        cocci.include_match(False)
> +
> + at depends on patch && r1@
> +type r1.T;
>  @@
>
>  - (T *)
> -  (\(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
> -   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\)(...))
> +  \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
> +   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\|vmalloc\|vzalloc\|
> +   dma_alloc_coherent\|dma_zalloc_coherent\|devm_kmalloc\|devm_kzalloc\|
> +   kvmalloc\|kvzalloc\|kvmalloc_node\|kvzalloc_node\|pci_alloc_consistent\|
> +   pci_zalloc_consistent\|kmem_alloc\|kmem_zalloc\|kmem_zone_alloc\|
> +   kmem_zone_zalloc\|vmalloc_node\|vzalloc_node\)(...)
>
>  //----------------------------------------------------------
>  //  For org and report mode
>  //----------------------------------------------------------
>
> - at r depends on org || report@
> + at r2 depends on org || report@
>  type T;
>  position p;
>  @@
>
> - (T at p *)\(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
> -   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\)(...)
> + (T at p *)
> +  \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
> +   kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\|vmalloc\|vzalloc\|
> +   dma_alloc_coherent\|dma_zalloc_coherent\|devm_kmalloc\|devm_kzalloc\|
> +   kvmalloc\|kvzalloc\|kvmalloc_node\|kvzalloc_node\|pci_alloc_consistent\|
> +   pci_zalloc_consistent\|kmem_alloc\|kmem_zalloc\|kmem_zone_alloc\|
> +   kmem_zone_zalloc\|vmalloc_node\|vzalloc_node\)(...)
>
>  @script:python depends on org@
> -p << r.p;
> -t << r.T;
> +p << r2.p;
> +t << r2.T;
>  @@
>
> -coccilib.org.print_safe_todo(p[0], t)
> +if m.search(t) != None:
> +	cocci.include_match(False)
> +else:
> +	coccilib.org.print_safe_todo(p[0], t)
>
>  @script:python depends on report@
> -p << r.p;
> -t << r.T;
> +p << r2.p;
> +t << r2.T;
>  @@
>
> -msg="WARNING: casting value returned by memory allocation function to (%s *) is useless." % (t)
> -coccilib.report.print_report(p[0], msg)
> -
> -
> +if m.search(t) != None:
> +	cocci.include_match(False)
> +else:
> +	msg="WARNING: casting value returned by memory allocation function to (%s *) is useless." % (t)
> +	coccilib.report.print_report(p[0], msg)
> --
> 2.7.4
>
>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list
  2018-01-13 15:56 ` [Cocci] " Himanshu Jha
  (?)
  (?)
@ 2018-01-13 18:19 ` SF Markus Elfring
  -1 siblings, 0 replies; 21+ messages in thread
From: SF Markus Elfring @ 2018-01-13 18:19 UTC (permalink / raw)
  To: cocci

> Add more memory allocating functions that are frequently used in the kernel
> code to the existing list and remove the useless casts where it is
> unnecessary.

Thanks for your approach to extend this SmPL script.

I would find the term ?selection? more appropriate than the word ?list? here.



>+  \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|

I suggest to choose an other code layout for such growing SmPL disjunctions.
How are the chances to specify each function name on a separate script line?


Would you ever like to reduce code duplication by including external files?


Could an alternation (regular expression) be used for a SmPL constraint?

Regards,
Markus

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [Cocci] [PATCH] Coccinelle: alloc_cast: Add more memory allocating functions to the list
  2018-01-13 15:56 ` [Cocci] " Himanshu Jha
                   ` (2 preceding siblings ...)
  (?)
@ 2018-01-13 20:21 ` SF Markus Elfring
  2018-01-14  9:04   ` Julia Lawall
  -1 siblings, 1 reply; 21+ messages in thread
From: SF Markus Elfring @ 2018-01-13 20:21 UTC (permalink / raw)
  To: cocci

My software development attention was caught by another implementation detail
in this evolving SmPL script.


> + at initialize:python@

The added script rule should get a condition.
Would the specification ?depends on report? be appropriate there?


Regards,
Markus

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [Cocci] [PATCH] Coccinelle: alloc_cast: Add more memory allocating functions to the list
  2018-01-13 20:21 ` [Cocci] [PATCH] " SF Markus Elfring
@ 2018-01-14  9:04   ` Julia Lawall
  2018-01-14  9:54     ` [Cocci] " SF Markus Elfring
  0 siblings, 1 reply; 21+ messages in thread
From: Julia Lawall @ 2018-01-14  9:04 UTC (permalink / raw)
  To: cocci



On Sat, 13 Jan 2018, SF Markus Elfring wrote:

> My software development attention was caught by another implementation detail
> in this evolving SmPL script.
>
>
> > + at initialize:python@
>
> The added script rule should get a condition.
> Would the specification ?depends on report? be appropriate there?

To my recollection, which is defined in the initialized is used in all of
the cases, so there is no need for a depends on.

julia

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list
  2018-01-14  9:04   ` Julia Lawall
@ 2018-01-14  9:54     ` SF Markus Elfring
  2018-01-14  9:58       ` Julia Lawall
  0 siblings, 1 reply; 21+ messages in thread
From: SF Markus Elfring @ 2018-01-14  9:54 UTC (permalink / raw)
  To: cocci

>>> + at initialize:python@
>>
>> The added script rule should get a condition.
>> Would the specification ?depends on report? be appropriate there?
> 
> To my recollection,

I wonder about this wording ?


> which is defined in the initialized is used in all of the cases,

I imagine that you could know it better.


> so there is no need for a depends on.

The default usage mode for the affected SmPL script is ?report?.
https://bottest.wiki.kernel.org/coccicheck#modes

But can an other mode also be occasionally selected here?
How do you think about to avoid the extra initialisation
when only the operation mode ?context? or ?patch? would be active?

Regards,
Markus

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list
  2018-01-14  9:54     ` [Cocci] " SF Markus Elfring
@ 2018-01-14  9:58       ` Julia Lawall
  2018-01-14 10:20         ` SF Markus Elfring
  0 siblings, 1 reply; 21+ messages in thread
From: Julia Lawall @ 2018-01-14  9:58 UTC (permalink / raw)
  To: cocci



On Sun, 14 Jan 2018, SF Markus Elfring wrote:

> >>> + at initialize:python@
> >>
> >> The added script rule should get a condition.
> >> Would the specification ?depends on report? be appropriate there?
> >
> > To my recollection,
>
> I wonder about this wording ?

Well, you didn't keep the semantic patch in the message.

>
>
> > which is defined in the initialized is used in all of the cases,
>
> I imagine that you could know it better.
>
>
> > so there is no need for a depends on.
>
> The default usage mode for the affected SmPL script is ?report?.
> https://bottest.wiki.kernel.org/coccicheck#modes
>
> But can an other mode also be occasionally selected here?
> How do you think about to avoid the extra initialisation
> when only the operation mode ?context? or ?patch? would be active?

context and patch use the regular expression too.  All forms of the rule
need it, to keep the casts that contain sparse annotations.

julia

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list
  2018-01-14  9:58       ` Julia Lawall
@ 2018-01-14 10:20         ` SF Markus Elfring
  2018-01-14 10:28           ` Julia Lawall
  0 siblings, 1 reply; 21+ messages in thread
From: SF Markus Elfring @ 2018-01-14 10:20 UTC (permalink / raw)
  To: cocci

> Well, you didn't keep the semantic patch in the message.

You can take another look in other information systems (if desired).
https://systeme.lip6.fr/pipermail/cocci/2018-January/004848.html


>> How do you think about to avoid the extra initialisation
>> when only the operation mode ?context? or ?patch? would be active?
> 
> context and patch use the regular expression too.

Where?


> All forms of the rule need it, to keep the casts that contain sparse annotations.

How do ?annotations? matter here?


Is a specific variable used only by two SmPL rules?

?
> +m = re.compile(pattern)
?
> @script:python depends on report@
?
> +if m.search(t) != None:
?


Why are two underscores used as a search pattern in this use case?

Regards,
Markus

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list
  2018-01-14 10:20         ` SF Markus Elfring
@ 2018-01-14 10:28           ` Julia Lawall
  2018-01-14 10:46             ` SF Markus Elfring
  0 siblings, 1 reply; 21+ messages in thread
From: Julia Lawall @ 2018-01-14 10:28 UTC (permalink / raw)
  To: cocci



On Sun, 14 Jan 2018, SF Markus Elfring wrote:

> > Well, you didn't keep the semantic patch in the message.
>
> You can take another look in other information systems (if desired).
> https://systeme.lip6.fr/pipermail/cocci/2018-January/004848.html
>
>
> >> How do you think about to avoid the extra initialisation
> >> when only the operation mode ?context? or ?patch? would be active?
> >
> > context and patch use the regular expression too.
>
> Where?

Look at the script code just under the comment "For context mode" and just
under the comment "For patch mode".  Both of them use m.  m is declared in
the initialize.

>
>
> > All forms of the rule need it, to keep the casts that contain sparse annotations.
>
> How do ?annotations? matter here?
>
>
> Is a specific variable used only by two SmPL rules?
>
> ?
> > +m = re.compile(pattern)
> ?
> > @script:python depends on report@
> ?
> > +if m.search(t) != None:
> ?
>
>
> Why are two underscores used as a search pattern in this use case?

How about just removing the script code and looking your self at what
happens in eg the patch case if it is not there.

__ are typically used in sparse annotations.

julia

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list
  2018-01-14 10:28           ` Julia Lawall
@ 2018-01-14 10:46             ` SF Markus Elfring
  2018-01-14 11:28               ` Himanshu Jha
  0 siblings, 1 reply; 21+ messages in thread
From: SF Markus Elfring @ 2018-01-14 10:46 UTC (permalink / raw)
  To: cocci

> Look at the script code just under the comment "For context mode" and just
> under the comment "For patch mode".  Both of them use m.

I would like to apologise that I overlooked these places somehow.


> __ are typically used in sparse annotations.

Is this search pattern worth for a corresponding comment in the Python code?


How do you think about to pass it to the method ?compile? directly (without the variable ?pattern?)?

Regards,
Markus

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list
  2018-01-14 10:46             ` SF Markus Elfring
@ 2018-01-14 11:28               ` Himanshu Jha
       [not found]                 ` <5e10af93-14cd-371d-2262-bef2fb2ca387@users.sourceforge.net>
  0 siblings, 1 reply; 21+ messages in thread
From: Himanshu Jha @ 2018-01-14 11:28 UTC (permalink / raw)
  To: cocci

On Sun, Jan 14, 2018 at 11:46:34AM +0100, SF Markus Elfring wrote:
> > Look at the script code just under the comment "For context mode" and just
> > under the comment "For patch mode".  Both of them use m.
> 
> I would like to apologise that I overlooked these places somehow.

Rather than apologising, start looking the SmPL grammar documentation
first. For eg. You asked about the 'initialize' code so take your time
and read what actually initialize does rather than writing about each
and very change. If its not mentioned there then ask Julia, that is what
I do. But first search around the documentation.

> 
> > __ are typically used in sparse annotations.

Now, again look for what __attribute__ means and why is it used ? How is
it benefiticial to sparse for static analysis. Even wikipedia explains
that!

> Is this search pattern worth for a corresponding comment in the Python code?
> 
> 
> How do you think about to pass it to the method ?compile? directly (without the variable ?pattern?)?

Would removing that boost performance ?
pattern variable improves readability and I mean people can easily guess
"Ok he searching for a pattern ..."

Whatever you wish to suggest, don't just email directly! Look for
documentation, explore, test the patch with the -next tree and show the
benchmarks to the relevant people. And finally prepare a patch and send
upstream.

Respect the developers, they also have their job.
Don't ask trivial questions to Julia or any other develper before
searching and exploring. She also has her research and other productive
stuff to do and not just sitting idle replying to each and every email.

Also, don't linger on *trivial* stuffs that improve the comment, add a
tabspace etc.

Lastly, you have a habit of saying:
"How about this ... ?' "How about that ...  ?"
"What if ... ?"

You have all the tools, documentations, source code, and you can explore
it yourself too before asking. That is what we call *opensource* :-)

BONUS:
https://www.kernel.org/doc/html/latest/dev-tools/coccinelle.html
http://coccinelle.lip6.fr/docs/index.html
https://en.wikipedia.org/wiki/Sparse#Annotations


-- 
Thanks
Himanshu Jha

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list
       [not found]                 ` <5e10af93-14cd-371d-2262-bef2fb2ca387@users.sourceforge.net>
@ 2018-01-14 12:48                   ` Julia Lawall
       [not found]                     ` <a0a4aa2c-56c7-a7b8-f1ec-77c5fc1a8150@users.sourceforge.net>
  0 siblings, 1 reply; 21+ messages in thread
From: Julia Lawall @ 2018-01-14 12:48 UTC (permalink / raw)
  To: cocci

> 4. Is is more efficient to use the Python key word ?in? to look for
>    a short string instead of fiddling with the programming interface
>    for regular expressions?

If you test it and find that it is significantly more efficient, then
please send a patch accordingly.

>
> 5. Please omit the variable ?msg? in the last SmPL rule.
>    The need data can be passed directly instead.

The use of the msg variable is common in the semantic patches in the
kernel.  Ampng other things it increases the chance that the line will fit
in 80 characters.  It is not completely a success here, but at least it is
more of a success than it would be otherwise.

julia

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list
       [not found]                     ` <a0a4aa2c-56c7-a7b8-f1ec-77c5fc1a8150@users.sourceforge.net>
@ 2018-01-14 13:05                       ` Julia Lawall
  0 siblings, 0 replies; 21+ messages in thread
From: Julia Lawall @ 2018-01-14 13:05 UTC (permalink / raw)
  To: cocci



On Sun, 14 Jan 2018, SF Markus Elfring wrote:

> >> 4. Is is more efficient to use the Python key word ?in? to look for
> >>    a short string instead of fiddling with the programming interface
> >>    for regular expressions?
> >
> > If you test it and find that it is significantly more efficient,
> > then please send a patch accordingly.
>
> Should the support for a specific key word in this programming language
> be generally faster or just more direct than invoking a component
> from another software library?
>
> Do we need to start an official benchmarking session to achieve
> another decision in any software design direction?

I have no idea about python.  If you find a performance improvement, send
a patch,  If you don't find a performance improvement, I don't care about
the issue.  In any case, the ball is entirely in your court.  There is no
"we".


>
>
> >> 5. Please omit the variable ?msg? in the last SmPL rule.
> >>    The need data can be passed directly instead.
> >
> > The use of the msg variable is common in the semantic patches in the kernel.
>
> Can this implementation detail be adjusted?
>
>
> > Ampng other things it increases the chance that the line will fit
> > in 80 characters.  It is not completely a success here, but at least it is
> > more of a success than it would be otherwise.
>
> Such data can also be passed as function parameters (in a scripting language)
> without storing them into variables before in some use cases.

But then, if a pleasant indentation scheme is followed, the very long
string will be further to the right and will even more exceed the 80
column boundary.  If python is so sensitive that it cares about the
introduction of a variable that is only used immediately afterwards, then
it would seem that the problem is with python.

julia

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list
  2018-01-13 15:56 ` [Cocci] " Himanshu Jha
                   ` (3 preceding siblings ...)
  (?)
@ 2018-01-15  6:27 ` SF Markus Elfring
  2018-01-15  6:39   ` Julia Lawall
  -1 siblings, 1 reply; 21+ messages in thread
From: SF Markus Elfring @ 2018-01-15  6:27 UTC (permalink / raw)
  To: cocci

> +// Copyright: (C) 2017 Himanshu Jha GPLv2.

* Is the addition ?(C)? required?
* Does the year number need an update?



My software development attention was caught by further implementation details
in this evolving SmPL script.


> + at depends on context && r1@

Will the use of a position variable be helpful here?



> +  \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|

Did you consider to handle the relevant function names by a metavariable
instead of a SmPL disjunction?

Regards,
Markus

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list
  2018-01-15  6:27 ` SF Markus Elfring
@ 2018-01-15  6:39   ` Julia Lawall
       [not found]     ` <545310fc-d64e-a970-3c76-6dfd15f9a8b3@users.sourceforge.net>
  0 siblings, 1 reply; 21+ messages in thread
From: Julia Lawall @ 2018-01-15  6:39 UTC (permalink / raw)
  To: cocci

> > + at depends on context && r1@
>
> Will the use of a position variable be helpful here?

No.  There is no need to repeat the same check for each place where a
given type occurs.  If the type always looks the same, checking it once is
sufficient for all uses.

> > +  \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
>
> Did you consider to handle the relevant function names by a metavariable
> instead of a SmPL disjunction?

If you put the names into the constraints of a metavariable there will be
no file filtering based on the function names and the semantic patch will
run more slowly.

julia

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list
       [not found]     ` <545310fc-d64e-a970-3c76-6dfd15f9a8b3@users.sourceforge.net>
@ 2018-01-15  9:24       ` Julia Lawall
       [not found]         ` <502cdb22-4fc3-6802-bb05-a6d90b5fbe77@users.sourceforge.net>
  0 siblings, 1 reply; 21+ messages in thread
From: Julia Lawall @ 2018-01-15  9:24 UTC (permalink / raw)
  To: cocci



On Mon, 15 Jan 2018, SF Markus Elfring wrote:

> >>> + at depends on context && r1@
> >>
> >> Will the use of a position variable be helpful here?
> >
> > No.  There is no need to repeat the same check for each place where a
> > given type occurs.
>
> I imagine that information from a position which was detected by the SmPL
> rule ?r1? should be reused by subsequent SmPL rules.

I don't fully understand the above, but if python code inherits a position
variable, its effect only applies to that position.  If there are three
different positions, but the other inputs are the same, the python code
will still be run three times. There is no need for this in the context or
patch case, because the behavior of the python code does not depend on the
position in any way.

>
>
> > If the type always looks the same, checking it once is sufficient
> > for all uses.
>
> Can it be safer to take specific source places into account precisely
> (by metavariable inheritance)?

There is nothing more or less safe about it.

>
> >>> +  \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|
> >>
> >> Did you consider to handle the relevant function names by a metavariable
> >> instead of a SmPL disjunction?
> >
> > If you put the names into the constraints of a metavariable there will be
> > no file filtering based on the function names
>
> Why?
>
> Is this a limitation by the Coccinelle software so far?
>
>
> Can they become more appealing?
>
> * SmPL list constraint
>
> * Advanced regular expression

Constraints can be arbitrarily complicated and don't necessarily fit into
the various filtering options provided (grep, id-utils, glimpse).  Now
that you can put script code into constraints, they can also have side
effects.  Thus, the user needs to be able to understand how often they
will be run.

>
> > and the semantic patch will run more slowly.
>
> How did you determine such software behaviour?

If Coccinelle knows the set of words that must be present in a file for
the rule to match, and if an index has been prepared with glimpse or
id-utils, then no time is spent on irrelevant files.  Parsing an
irrelevant file is surely more expensive than doing nothing with it.  If
no index is available, then Coccinelle will search line by line for the
important words before trying to parse the file.  Reading through each
word of a file once is still likely much cheaper than parsing, which may
perform up to four attempts on each function.  I don't know what is the
exact tradeoff in teh case of this specific rule, because the functions
involved are very common.

julia

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list
       [not found]             ` <5ffcc601-e80b-7860-659c-ed6572be470a@users.sourceforge.net>
@ 2018-01-15 11:18               ` Julia Lawall
  0 siblings, 0 replies; 21+ messages in thread
From: Julia Lawall @ 2018-01-15 11:18 UTC (permalink / raw)
  To: cocci



On Mon, 15 Jan 2018, SF Markus Elfring wrote:

> > In the report rule we print the position, so having the position among the
> > inherited metavariables is useful.
>
> Do position variables influence (in a positive way?) how fast a source code place
> is matched in a non-script rule?

To some extent.  You are welcome to compare the performance.  I expect
that the difference would be small in this case, because there would only
be a few of these calls per file anyway.

> >>> If no index is available,
> >>
> >> How often will this be the usual case?   ;-)
> >
> > It depends on the user of Coccinelle.
>
> Can SmPL scripts adapt to the situation when an index was selected (or not)?

It doesn't really matter.  The point is that constraints are arbitrarily
complex, and the filtering, however it is done, is intended to be a simple
and fast process.

julia

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] Coccinelle: alloc_cast: Add more memory allocating functions to the list
  2018-01-13 15:56 ` [Cocci] " Himanshu Jha
@ 2018-01-16 14:33   ` Masahiro Yamada
  -1 siblings, 0 replies; 21+ messages in thread
From: Masahiro Yamada @ 2018-01-16 14:33 UTC (permalink / raw)
  To: Himanshu Jha
  Cc: Julia Lawall, Gilles Muller, Nicolas Palix, Michal Marek, cocci,
	Linux Kernel Mailing List

2018-01-14 0:56 GMT+09:00 Himanshu Jha <himanshujha199640@gmail.com>:
> Add more memory allocating functions that are frequently used in the kernel
> code to the existing list and remove the useless casts where it is
> unnecessary.
>
> But preserve those casts having __attribute__ such as __force, __iomem,
> etc which are used by Sparse in the static analysis of the code.
>
> Also remove two blank lines at EOF.
>
> Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
> ---
>  scripts/coccinelle/api/alloc/alloc_cast.cocci | 92 +++++++++++++++++++++------
>  1 file changed, 71 insertions(+), 21 deletions(-)


Applied to linux-kbuild/misc. Thanks!


-- 
Best Regards
Masahiro Yamada

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [Cocci] [PATCH] Coccinelle: alloc_cast: Add more memory allocating functions to the list
@ 2018-01-16 14:33   ` Masahiro Yamada
  0 siblings, 0 replies; 21+ messages in thread
From: Masahiro Yamada @ 2018-01-16 14:33 UTC (permalink / raw)
  To: cocci

2018-01-14 0:56 GMT+09:00 Himanshu Jha <himanshujha199640@gmail.com>:
> Add more memory allocating functions that are frequently used in the kernel
> code to the existing list and remove the useless casts where it is
> unnecessary.
>
> But preserve those casts having __attribute__ such as __force, __iomem,
> etc which are used by Sparse in the static analysis of the code.
>
> Also remove two blank lines at EOF.
>
> Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
> ---
>  scripts/coccinelle/api/alloc/alloc_cast.cocci | 92 +++++++++++++++++++++------
>  1 file changed, 71 insertions(+), 21 deletions(-)


Applied to linux-kbuild/misc. Thanks!


-- 
Best Regards
Masahiro Yamada

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2018-01-16 14:35 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-13 15:56 [PATCH] Coccinelle: alloc_cast: Add more memory allocating functions to the list Himanshu Jha
2018-01-13 15:56 ` [Cocci] " Himanshu Jha
2018-01-13 16:24 ` Julia Lawall
2018-01-13 16:24   ` [Cocci] " Julia Lawall
2018-01-13 18:19 ` [Cocci] " SF Markus Elfring
2018-01-13 20:21 ` [Cocci] [PATCH] " SF Markus Elfring
2018-01-14  9:04   ` Julia Lawall
2018-01-14  9:54     ` [Cocci] " SF Markus Elfring
2018-01-14  9:58       ` Julia Lawall
2018-01-14 10:20         ` SF Markus Elfring
2018-01-14 10:28           ` Julia Lawall
2018-01-14 10:46             ` SF Markus Elfring
2018-01-14 11:28               ` Himanshu Jha
     [not found]                 ` <5e10af93-14cd-371d-2262-bef2fb2ca387@users.sourceforge.net>
2018-01-14 12:48                   ` Julia Lawall
     [not found]                     ` <a0a4aa2c-56c7-a7b8-f1ec-77c5fc1a8150@users.sourceforge.net>
2018-01-14 13:05                       ` Julia Lawall
2018-01-15  6:27 ` SF Markus Elfring
2018-01-15  6:39   ` Julia Lawall
     [not found]     ` <545310fc-d64e-a970-3c76-6dfd15f9a8b3@users.sourceforge.net>
2018-01-15  9:24       ` Julia Lawall
     [not found]         ` <502cdb22-4fc3-6802-bb05-a6d90b5fbe77@users.sourceforge.net>
     [not found]           ` <alpine.DEB.2.20.1801151137430.3305@hadrien>
     [not found]             ` <5ffcc601-e80b-7860-659c-ed6572be470a@users.sourceforge.net>
2018-01-15 11:18               ` Julia Lawall
2018-01-16 14:33 ` [PATCH] " Masahiro Yamada
2018-01-16 14:33   ` [Cocci] " Masahiro Yamada

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.