Re: [Cocci] [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
On Wed, Feb 10, 2016 at 7:44 AM, Olaf Hering wrote: > On Wed, Feb 10, Luis R. Rodriguez wrote: > >> cherry picks for fixes or huge interest to keep it compatible with latest >> compilers qemu-xen-traditional seems to be more of a liability than a > > Hey, this is about gnutls, not gcc! Actually no, I also had backported another fix which I submitted part of this series, and it is present as of this release: mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains 98d23704138e0be17a3ed9eb2631077bf92cc028 v1.1-rc0~785 How are fixes of interested backported regularly for this to make it reasonable to at least keep this as a viable option which at least compiles? Only compiling is one thing, how are security fixes backported proactively? Luis ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
On Wed, Feb 10, 2016 at 09:46:30AM +, Ian Campbell wrote: > On Tue, 2016-02-09 at 19:04 -0800, Luis R. Rodriguez wrote: > > On Tue, Feb 9, 2016 at 10:23 AM, Olaf Hering wrote: > > > On Tue, Feb 09, Luis R. Rodriguez wrote: > > > > > > > Thanks so it seems the other option is to bump the release, can that > > > > be decided? What's the process for deciding that? > > > > > > Which release should be bumped? > > > > In so far as TLS is concerned: > > > > mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains > > f40d55081667a716312b9a8b6e13835c4074f56b > > v1.0-rc0~325 > > > > mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains > > 7d2a929feba319c18603e324b1750830d6c8b7a1 > > v1.5.0-rc0~660 > > > > mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains > > d321e1e526810 > > v2.5.0-rc0~125^2~2 > > > > As for the other fix I backported for the existing release carried: > > > > mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains > > 98d23704138e0be17a3ed9eb2631077bf92cc028 > > v1.1-rc0~785 > > > > I wanted to see what is the current version on Xen for > > qemu-xen-traditional-dir-remote thing, is this the right way to check > > what version is on /tools/qemu-xen-traditional-dir-remote ? > > > > mcgrof@ergon ~/devel/xen/tools/qemu-xen-traditional-dir-remote > > (git::dummy)$ cat VERSION > > 0.10.2 > > > > If so.. I'm scared. > > qemu-xen-traditional Device Model is the old Xen fork which is maintained > only in order to support old VMs which expect the hardware environment > provided by that old version of QEMU. > > The default Device Model since Xen 4.3 has been "qemu-xen", which is our > name for QEMU upstream. Xen 4.6 shipped with a bundled QEMU 2.2.1, but > users (and distros) are free to supply their own (see configure's --with- > system-qemu option) instead. > > Hopefully it is clear therefore why just upgrading qemu-xen-traditional to > a newer QEMU is not an option (or rather, that already exists and is the > default via qemu-xen) > > If you aren't interested in supporting VMs installed on very old versions > of Xen then it would be reasonable to: > ./configure --disable-qemu-traditional > and avoid it all together. > > So far as making qemu-xen-trad compatible with gcc5 while still retaining > support for building on the oldest platforms we want to support (whatever > those are) I have no real opinion, but it seems some sort of > abstraction/shim layer would be needed to satisfy both cases. Thanks for the details! If there is no proactive mechanism to scrape for cherry picks for fixes or huge interest to keep it compatible with latest compilers qemu-xen-traditional seems to be more of a liability than a helper, would it be too irrational to propose to just burry it and mark it as no longer supported? Luis ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] coccinelle: add style check for assignment in if
On Tue, 2016-02-09 at 13:55 +0100, SF Markus Elfring wrote: > > > Would you like to consider also the reuse of SmPL variables > > > like "org" and "report"? > > > > I think that there is no point for these things, because checkpatch > > already gives warnings about this issue. > > Can the check result display be more convenient from the semantic > patch script interface in comparison to the other tool? -ENOPARSE. More detail please. ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] [PATCH] Coccinelle: Add api/setup_timer.cocci
Acked-by: Julia Lawall
On Wed, 10 Feb 2016, Vaishali Thakkar wrote:
> Use the timer API function setup_timer instead of structure field
> assignments to initialize a timer.
>
> Signed-off-by: Vaishali Thakkar
> ---
> scripts/coccinelle/api/setup_timer.cocci | 199
> +++
> 1 file changed, 199 insertions(+)
> create mode 100644 scripts/coccinelle/api/setup_timer.cocci
>
> diff --git a/scripts/coccinelle/api/setup_timer.cocci
> b/scripts/coccinelle/api/setup_timer.cocci
> new file mode 100644
> index 000..8ee0ac3
> --- /dev/null
> +++ b/scripts/coccinelle/api/setup_timer.cocci
> @@ -0,0 +1,199 @@
> +/// Use setup_timer function instead of initializing timer with the function
> +/// and data fields
> +// Confidence: High
> +// Copyright: (C) 2016 Vaishali Thakkar, Oracle. GPLv2
> +// Options: --no-includes --include-headers
> +// Keywords: init_timer, setup_timer
> +
> +virtual patch
> +virtual context
> +virtual org
> +virtual report
> +
> +@match_immediate_function_data_after_init_timer
> +depends on patch && !context && !org && !report@
> +expression e, func, da;
> +@@
> +
> +-init_timer (&e);
> ++setup_timer (&e, func, da);
> +
> +(
> +-e.function = func;
> +-e.data = da;
> +|
> +-e.data = da;
> +-e.function = func;
> +)
> +
> +@match_function_and_data_after_init_timer
> +depends on patch && !context && !org && !report@
> +expression e1, e2, e3, e4, e5, a, b;
> +@@
> +
> +-init_timer (&e1);
> ++setup_timer (&e1, a, b);
> +
> +... when != a = e2
> +when != b = e3
> +(
> +-e1.function = a;
> +... when != b = e4
> +-e1.data = b;
> +|
> +-e1.data = b;
> +... when != a = e5
> +-e1.function = a;
> +)
> +
> +@r1 exists@
> +identifier f;
> +position p;
> +@@
> +
> +f(...) { ... when any
> + init_timer@p(...)
> + ... when any
> +}
> +
> +@r2 exists@
> +identifier g != r1.f;
> +struct timer_list t;
> +expression e8;
> +@@
> +
> +g(...) { ... when any
> + t.data = e8
> + ... when any
> +}
> +
> +// It is dangerous to use setup_timer if data field is initialized
> +// in another function.
> +
> +@script:python depends on r2@
> +p << r1.p;
> +@@
> +
> +cocci.include_match(False)
> +
> +@r3 depends on patch && !context && !org && !report@
> +expression e6, e7, c;
> +position r1.p;
> +@@
> +
> +-init_timer@p (&e6);
> ++setup_timer (&e6, c, 0UL);
> +... when != c = e7
> +-e6.function = c;
> +
> +//
>
> +
> +@match_immediate_function_data_after_init_timer_context
> +depends on !patch && (context || org || report)@
> +expression da, e, func;
> +position j0, j1, j2;
> +@@
> +
> +* init_timer@j0 (&e);
> +(
> +* e@j1.function = func;
> +* e...@j2.data = da;
> +|
> +* e...@j1.data = da;
> +* e@j2.function = func;
> +)
> +
> +@match_function_and_data_after_init_timer_context
> +depends on !patch &&
> +!match_immediate_function_data_after_init_timer_context &&
> +(context || org || report)@
> +expression a, b, e1, e2, e3, e4, e5;
> +position j0, j1, j2;
> +@@
> +
> +* init_timer@j0 (&e1);
> +... when != a = e2
> +when != b = e3
> +(
> +* e1@j1.function = a;
> +... when != b = e4
> +* e...@j2.data = b;
> +|
> +* e...@j1.data = b;
> +... when != a = e5
> +* e1@j2.function = a;
> +)
> +
> +@r3_context depends on !patch &&
> +!match_immediate_function_data_after_init_timer_context &&
> +!match_function_and_data_after_init_timer_context &&
> +(context || org || report)@
> +expression c, e6, e7;
> +position r1.p;
> +position j0, j1;
> +@@
> +
> +* init_timer@j0@p (&e6);
> +... when != c = e7
> +* e6@j1.function = c;
> +
> +//
>
> +
> +@script:python match_immediate_function_data_after_init_timer_org
> +depends on org@
> +j0 << match_immediate_function_data_after_init_timer_context.j0;
> +j1 << match_immediate_function_data_after_init_timer_context.j1;
> +j2 << match_immediate_function_data_after_init_timer_context.j2;
> +@@
> +
> +msg = "Use setup_timer function."
> +coccilib.org.print_todo(j0[0], msg)
> +coccilib.org.print_link(j1[0], "")
> +coccilib.org.print_link(j2[0], "")
> +
> +@script:python match_function_and_data_after_init_timer_org depends on org@
> +j0 << match_function_and_data_after_init_timer_context.j0;
> +j1 << match_function_and_data_after_init_timer_context.j1;
> +j2 << match_function_and_data_after_init_timer_context.j2;
> +@@
> +
> +msg = "Use setup_timer function."
> +coccilib.org.print_todo(j0[0], msg)
> +coccilib.org.print_link(j1[0], "")
> +coccilib.org.print_link(j2[0], "")
> +
> +@script:python r3_org depends on org@
> +j0 << r3_context.j0;
> +j1 << r3_context.j1;
> +@@
> +
> +msg = "Use setup_timer function."
> +coccilib.org.print_todo(j0[0], msg)
> +coccilib.org.print_link(j1[0], "")
> +
> +//
>
> +
> +@script:python match_immediate_function_data_after_init_timer_report
> +depends on report@
> +j0 << match_immediate_function_d
[Cocci] [PATCH] Coccinelle: Add api/setup_timer.cocci
Use the timer API function setup_timer instead of structure field
assignments to initialize a timer.
Signed-off-by: Vaishali Thakkar
---
scripts/coccinelle/api/setup_timer.cocci | 199 +++
1 file changed, 199 insertions(+)
create mode 100644 scripts/coccinelle/api/setup_timer.cocci
diff --git a/scripts/coccinelle/api/setup_timer.cocci
b/scripts/coccinelle/api/setup_timer.cocci
new file mode 100644
index 000..8ee0ac3
--- /dev/null
+++ b/scripts/coccinelle/api/setup_timer.cocci
@@ -0,0 +1,199 @@
+/// Use setup_timer function instead of initializing timer with the function
+/// and data fields
+// Confidence: High
+// Copyright: (C) 2016 Vaishali Thakkar, Oracle. GPLv2
+// Options: --no-includes --include-headers
+// Keywords: init_timer, setup_timer
+
+virtual patch
+virtual context
+virtual org
+virtual report
+
+@match_immediate_function_data_after_init_timer
+depends on patch && !context && !org && !report@
+expression e, func, da;
+@@
+
+-init_timer (&e);
++setup_timer (&e, func, da);
+
+(
+-e.function = func;
+-e.data = da;
+|
+-e.data = da;
+-e.function = func;
+)
+
+@match_function_and_data_after_init_timer
+depends on patch && !context && !org && !report@
+expression e1, e2, e3, e4, e5, a, b;
+@@
+
+-init_timer (&e1);
++setup_timer (&e1, a, b);
+
+... when != a = e2
+when != b = e3
+(
+-e1.function = a;
+... when != b = e4
+-e1.data = b;
+|
+-e1.data = b;
+... when != a = e5
+-e1.function = a;
+)
+
+@r1 exists@
+identifier f;
+position p;
+@@
+
+f(...) { ... when any
+ init_timer@p(...)
+ ... when any
+}
+
+@r2 exists@
+identifier g != r1.f;
+struct timer_list t;
+expression e8;
+@@
+
+g(...) { ... when any
+ t.data = e8
+ ... when any
+}
+
+// It is dangerous to use setup_timer if data field is initialized
+// in another function.
+
+@script:python depends on r2@
+p << r1.p;
+@@
+
+cocci.include_match(False)
+
+@r3 depends on patch && !context && !org && !report@
+expression e6, e7, c;
+position r1.p;
+@@
+
+-init_timer@p (&e6);
++setup_timer (&e6, c, 0UL);
+... when != c = e7
+-e6.function = c;
+
+//
+
+@match_immediate_function_data_after_init_timer_context
+depends on !patch && (context || org || report)@
+expression da, e, func;
+position j0, j1, j2;
+@@
+
+* init_timer@j0 (&e);
+(
+* e@j1.function = func;
+* e...@j2.data = da;
+|
+* e...@j1.data = da;
+* e@j2.function = func;
+)
+
+@match_function_and_data_after_init_timer_context
+depends on !patch &&
+!match_immediate_function_data_after_init_timer_context &&
+(context || org || report)@
+expression a, b, e1, e2, e3, e4, e5;
+position j0, j1, j2;
+@@
+
+* init_timer@j0 (&e1);
+... when != a = e2
+when != b = e3
+(
+* e1@j1.function = a;
+... when != b = e4
+* e...@j2.data = b;
+|
+* e...@j1.data = b;
+... when != a = e5
+* e1@j2.function = a;
+)
+
+@r3_context depends on !patch &&
+!match_immediate_function_data_after_init_timer_context &&
+!match_function_and_data_after_init_timer_context &&
+(context || org || report)@
+expression c, e6, e7;
+position r1.p;
+position j0, j1;
+@@
+
+* init_timer@j0@p (&e6);
+... when != c = e7
+* e6@j1.function = c;
+
+//
+
+@script:python match_immediate_function_data_after_init_timer_org
+depends on org@
+j0 << match_immediate_function_data_after_init_timer_context.j0;
+j1 << match_immediate_function_data_after_init_timer_context.j1;
+j2 << match_immediate_function_data_after_init_timer_context.j2;
+@@
+
+msg = "Use setup_timer function."
+coccilib.org.print_todo(j0[0], msg)
+coccilib.org.print_link(j1[0], "")
+coccilib.org.print_link(j2[0], "")
+
+@script:python match_function_and_data_after_init_timer_org depends on org@
+j0 << match_function_and_data_after_init_timer_context.j0;
+j1 << match_function_and_data_after_init_timer_context.j1;
+j2 << match_function_and_data_after_init_timer_context.j2;
+@@
+
+msg = "Use setup_timer function."
+coccilib.org.print_todo(j0[0], msg)
+coccilib.org.print_link(j1[0], "")
+coccilib.org.print_link(j2[0], "")
+
+@script:python r3_org depends on org@
+j0 << r3_context.j0;
+j1 << r3_context.j1;
+@@
+
+msg = "Use setup_timer function."
+coccilib.org.print_todo(j0[0], msg)
+coccilib.org.print_link(j1[0], "")
+
+//
+
+@script:python match_immediate_function_data_after_init_timer_report
+depends on report@
+j0 << match_immediate_function_data_after_init_timer_context.j0;
+j1 << match_immediate_function_data_after_init_timer_context.j1;
+@@
+
+msg = "Use setup_timer function for function on line %s." % (j1[0].line)
+coccilib.report.print_report(j0[0], msg)
+
+@script:python match_function_and_data_after_init_timer_report depends on
report@
+j0 << match_function_and_data_after_init_timer_context.j0;
+j1 << match_function_and_data_after_init_timer_context.j1;
+@@
+
+msg = "Use setup_timer function for
Re: [Cocci] coccinelle: add style check for assignment in if
>> Can the check result display be more convenient from the semantic >> patch script interface in comparison to the other tool? > > -ENOPARSE. More detail please. Kris Borer suggested a SmPL script which can generate (only) patches so far by the usual application of the Coccinelle software. I assume that this approach was limited just because Julia Lawall indicated that this functionality would be sufficient for a while. The documentation for the command "make coccicheck" mentions additional modes. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/coccinelle.txt?id=ec97946ed038f4b3faa587bc76152b198805b0c4#n170 They refer to specific output formats for the result from the static source code analysis. * How often would you like to look at proposed changes by the Org mode format (of Emacs)? http://orgmode.org/ * Do you find the report mode also useful occasionally? Are you interested to get further output variants? Examples: * CSV * XML Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
