Re: [PATCH v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()

Re: [PATCH v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()

[Markus Elfring]

…
> +++ b/scripts/coccinelle/api/memdup_user.cocci
> @@ -39,6 +39,28 @@ …
…
> +@depends on patch@
> +expression from,to,size;
> +identifier l1,l2;
> +@@
> +
> +-  to = \(kvmalloc\|kvzalloc\)(size,\(GFP_KERNEL\|GFP_USER\));
> ++  to = vmemdup_user(from,size);

I propose to combine the desired adjustment with the previous SmPL rule
by using another disjunction.


> +@rv depends on !patch@
> +expression from,to,size;
> +position p;
> +statement S1,S2;
> +@@
> +
> +*  to = \(kvmalloc@p\|kvzalloc@p\)(size,\(GFP_KERNEL\|GFP_USER\));
> +   if (to==NULL || ...) S1
> +   if (copy_from_user(to, from, size) != 0)
> +   S2

* Can it be helpful to omit the SmPL asterisk functionality from
  the operation modes “org” and “report”?

* Should the operation mode “context” work without an extra position metavariable?

Regards,
Markus

Re: [PATCH v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()

[Markus Elfring]

…
> +++ b/scripts/coccinelle/api/memdup_user.cocci
> @@ -39,6 +39,28 @@ …
…
> +@depends on patch@
> +expression from,to,size;
> +identifier l1,l2;
> +@@
> +
> +-  to = \(kvmalloc\|kvzalloc\)(size,\(GFP_KERNEL\|GFP_USER\));
> ++  to = vmemdup_user(from,size);

I propose to combine the desired adjustment with the previous SmPL rule
by using another disjunction.


> +@rv depends on !patch@
> +expression from,to,size;
> +position p;
> +statement S1,S2;
> +@@
> +
> +*  to = \(kvmalloc@p\|kvzalloc@p\)(size,\(GFP_KERNEL\|GFP_USER\));
> +   if (to==NULL || ...) S1
> +   if (copy_from_user(to, from, size) != 0)
> +   S2

* Can it be helpful to omit the SmPL asterisk functionality from
  the operation modes “org” and “report”?

* Should the operation mode “context” work without an extra position metavariable?

Regards,
Markus

Re: [PATCH v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]



On Tue, 21 Jul 2020, Markus Elfring wrote:

> …
> > +++ b/scripts/coccinelle/api/memdup_user.cocci
> > @@ -39,6 +39,28 @@ …
> …
> > +@depends on patch@
> > +expression from,to,size;
> > +identifier l1,l2;
> > +@@
> > +
> > +-  to = \(kvmalloc\|kvzalloc\)(size,\(GFP_KERNEL\|GFP_USER\));
> > ++  to = vmemdup_user(from,size);
>
> I propose to combine the desired adjustment with the previous SmPL rule
> by using another disjunction.
>
>
> > +@rv depends on !patch@
> > +expression from,to,size;
> > +position p;
> > +statement S1,S2;
> > +@@
> > +
> > +*  to = \(kvmalloc@p\|kvzalloc@p\)(size,\(GFP_KERNEL\|GFP_USER\));
> > +   if (to==NULL || ...) S1
> > +   if (copy_from_user(to, from, size) != 0)
> > +   S2
>
> * Can it be helpful to omit the SmPL asterisk functionality from
>   the operation modes “org” and “report”?
>
> * Should the operation mode “context” work without an extra position metavariable?

This is fine as is in all three aspects.

julia

Re: [Cocci] [PATCH v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]



On Tue, 21 Jul 2020, Markus Elfring wrote:

> …
> > +++ b/scripts/coccinelle/api/memdup_user.cocci
> > @@ -39,6 +39,28 @@ …
> …
> > +@depends on patch@
> > +expression from,to,size;
> > +identifier l1,l2;
> > +@@
> > +
> > +-  to = \(kvmalloc\|kvzalloc\)(size,\(GFP_KERNEL\|GFP_USER\));
> > ++  to = vmemdup_user(from,size);
>
> I propose to combine the desired adjustment with the previous SmPL rule
> by using another disjunction.
>
>
> > +@rv depends on !patch@
> > +expression from,to,size;
> > +position p;
> > +statement S1,S2;
> > +@@
> > +
> > +*  to = \(kvmalloc@p\|kvzalloc@p\)(size,\(GFP_KERNEL\|GFP_USER\));
> > +   if (to==NULL || ...) S1
> > +   if (copy_from_user(to, from, size) != 0)
> > +   S2
>
> * Can it be helpful to omit the SmPL asterisk functionality from
>   the operation modes “org” and “report”?
>
> * Should the operation mode “context” work without an extra position metavariable?

This is fine as is in all three aspects.

julia

[-- Attachment #2: Type: text/plain, Size: 136 bytes --]

_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [PATCH v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]



On Tue, 21 Jul 2020, Markus Elfring wrote:

> …
> > +++ b/scripts/coccinelle/api/memdup_user.cocci
> > @@ -39,6 +39,28 @@ …
> …
> > +@depends on patch@
> > +expression from,to,size;
> > +identifier l1,l2;
> > +@@
> > +
> > +-  to = \(kvmalloc\|kvzalloc\)(size,\(GFP_KERNEL\|GFP_USER\));
> > ++  to = vmemdup_user(from,size);
>
> I propose to combine the desired adjustment with the previous SmPL rule
> by using another disjunction.
>
>
> > +@rv depends on !patch@
> > +expression from,to,size;
> > +position p;
> > +statement S1,S2;
> > +@@
> > +
> > +*  to = \(kvmalloc@p\|kvzalloc@p\)(size,\(GFP_KERNEL\|GFP_USER\));
> > +   if (to==NULL || ...) S1
> > +   if (copy_from_user(to, from, size) != 0)
> > +   S2
>
> * Can it be helpful to omit the SmPL asterisk functionality from
>   the operation modes “org” and “report”?
>
> * Should the operation mode “context” work without an extra position metavariable?

This is fine as is in all three aspects.

julia

Re: [v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()

[Markus Elfring]

> This is fine as is in all three aspects.

I have tried again to point specific data processing consequences out
for operation modes of scripts in the semantic patch language.

Regards,
Markus

Re: [v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()

[Markus Elfring]

> This is fine as is in all three aspects.

I have tried again to point specific data processing consequences out
for operation modes of scripts in the semantic patch language.

Regards,
Markus

Re: [PATCH v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()

[Markus Elfring]

>>> +@depends on patch@
>>> +expression from,to,size;
>>> +identifier l1,l2;
>>> +@@
>>> +
>>> +-  to = \(kvmalloc\|kvzalloc\)(size,\(GFP_KERNEL\|GFP_USER\));
>>> ++  to = vmemdup_user(from,size);
>>
>> I propose to combine the desired adjustment with the previous SmPL rule
>> by using another disjunction.

How do you think about to check run time characteristics for
the following SmPL script sketches?

A)
@R1@
@@
// Change something

@R2@
@@
// Change another thing


B)
@Replacement_with_disjunction@
@@
(
// R1: Change something
|
// R2: Change another thing
)


>>> +@rv depends on !patch@
>>> +expression from,to,size;
>>> +position p;
>>> +statement S1,S2;
>>> +@@
>>> +
>>> +*  to = \(kvmalloc@p\|kvzalloc@p\)(size,\(GFP_KERNEL\|GFP_USER\));
>>> +   if (to==NULL || ...) S1
>>> +   if (copy_from_user(to, from, size) != 0)
>>> +   S2
>>
>> * Can it be helpful to omit the SmPL asterisk functionality from
>>   the operation modes “org” and “report”?
>>
>> * Should the operation mode “context” work without an extra position metavariable?
>
> This is fine as is in all three aspects.

Is every technique from the Coccinelle software required for
each operation mode in such data processing approaches?

Regards,
Markus

Re: [PATCH v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()

[Markus Elfring]

>>> +@depends on patch@
>>> +expression from,to,size;
>>> +identifier l1,l2;
>>> +@@
>>> +
>>> +-  to = \(kvmalloc\|kvzalloc\)(size,\(GFP_KERNEL\|GFP_USER\));
>>> ++  to = vmemdup_user(from,size);
>>
>> I propose to combine the desired adjustment with the previous SmPL rule
>> by using another disjunction.

How do you think about to check run time characteristics for
the following SmPL script sketches?

A)
@R1@
@@
// Change something

@R2@
@@
// Change another thing


B)
@Replacement_with_disjunction@
@@
(
// R1: Change something
|
// R2: Change another thing
)


>>> +@rv depends on !patch@
>>> +expression from,to,size;
>>> +position p;
>>> +statement S1,S2;
>>> +@@
>>> +
>>> +*  to = \(kvmalloc@p\|kvzalloc@p\)(size,\(GFP_KERNEL\|GFP_USER\));
>>> +   if (to==NULL || ...) S1
>>> +   if (copy_from_user(to, from, size) != 0)
>>> +   S2
>>
>> * Can it be helpful to omit the SmPL asterisk functionality from
>>   the operation modes “org” and “report”?
>>
>> * Should the operation mode “context” work without an extra position metavariable?
>
> This is fine as is in all three aspects.

Is every technique from the Coccinelle software required for
each operation mode in such data processing approaches?

Regards,
Markus

Re: [PATCH v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]



On Wed, 22 Jul 2020, Markus Elfring wrote:

> >>> +@depends on patch@
> >>> +expression from,to,size;
> >>> +identifier l1,l2;
> >>> +@@
> >>> +
> >>> +-  to = \(kvmalloc\|kvzalloc\)(size,\(GFP_KERNEL\|GFP_USER\));
> >>> ++  to = vmemdup_user(from,size);
> >>
> >> I propose to combine the desired adjustment with the previous SmPL rule
> >> by using another disjunction.
>
> How do you think about to check run time characteristics for
> the following SmPL script sketches?
>
> A)
> @R1@
> @@
> // Change something
>
> @R2@
> @@
> // Change another thing
>
>
> B)
> @Replacement_with_disjunction@
> @@
> (
> // R1: Change something
> |
> // R2: Change another thing
> )

Markus, you are welcome to try this since you are concerned about it.
But it doesn't matter.

julia

>
>
> >>> +@rv depends on !patch@
> >>> +expression from,to,size;
> >>> +position p;
> >>> +statement S1,S2;
> >>> +@@
> >>> +
> >>> +*  to = \(kvmalloc@p\|kvzalloc@p\)(size,\(GFP_KERNEL\|GFP_USER\));
> >>> +   if (to==NULL || ...) S1
> >>> +   if (copy_from_user(to, from, size) != 0)
> >>> +   S2
> >>
> >> * Can it be helpful to omit the SmPL asterisk functionality from
> >>   the operation modes “org” and “report”?
> >>
> >> * Should the operation mode “context” work without an extra position metavariable?
> >
> > This is fine as is in all three aspects.
>
> Is every technique from the Coccinelle software required for
> each operation mode in such data processing approaches?
>
> Regards,
> Markus
>

Re: [Cocci] [PATCH v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]



On Wed, 22 Jul 2020, Markus Elfring wrote:

> >>> +@depends on patch@
> >>> +expression from,to,size;
> >>> +identifier l1,l2;
> >>> +@@
> >>> +
> >>> +-  to = \(kvmalloc\|kvzalloc\)(size,\(GFP_KERNEL\|GFP_USER\));
> >>> ++  to = vmemdup_user(from,size);
> >>
> >> I propose to combine the desired adjustment with the previous SmPL rule
> >> by using another disjunction.
>
> How do you think about to check run time characteristics for
> the following SmPL script sketches?
>
> A)
> @R1@
> @@
> // Change something
>
> @R2@
> @@
> // Change another thing
>
>
> B)
> @Replacement_with_disjunction@
> @@
> (
> // R1: Change something
> |
> // R2: Change another thing
> )

Markus, you are welcome to try this since you are concerned about it.
But it doesn't matter.

julia

>
>
> >>> +@rv depends on !patch@
> >>> +expression from,to,size;
> >>> +position p;
> >>> +statement S1,S2;
> >>> +@@
> >>> +
> >>> +*  to = \(kvmalloc@p\|kvzalloc@p\)(size,\(GFP_KERNEL\|GFP_USER\));
> >>> +   if (to==NULL || ...) S1
> >>> +   if (copy_from_user(to, from, size) != 0)
> >>> +   S2
> >>
> >> * Can it be helpful to omit the SmPL asterisk functionality from
> >>   the operation modes “org” and “report”?
> >>
> >> * Should the operation mode “context” work without an extra position metavariable?
> >
> > This is fine as is in all three aspects.
>
> Is every technique from the Coccinelle software required for
> each operation mode in such data processing approaches?
>
> Regards,
> Markus
>

[-- Attachment #2: Type: text/plain, Size: 136 bytes --]

_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [PATCH v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]



On Wed, 22 Jul 2020, Markus Elfring wrote:

> >>> +@depends on patch@
> >>> +expression from,to,size;
> >>> +identifier l1,l2;
> >>> +@@
> >>> +
> >>> +-  to = \(kvmalloc\|kvzalloc\)(size,\(GFP_KERNEL\|GFP_USER\));
> >>> ++  to = vmemdup_user(from,size);
> >>
> >> I propose to combine the desired adjustment with the previous SmPL rule
> >> by using another disjunction.
>
> How do you think about to check run time characteristics for
> the following SmPL script sketches?
>
> A)
> @R1@
> @@
> // Change something
>
> @R2@
> @@
> // Change another thing
>
>
> B)
> @Replacement_with_disjunction@
> @@
> (
> // R1: Change something
> |
> // R2: Change another thing
> )

Markus, you are welcome to try this since you are concerned about it.
But it doesn't matter.

julia

>
>
> >>> +@rv depends on !patch@
> >>> +expression from,to,size;
> >>> +position p;
> >>> +statement S1,S2;
> >>> +@@
> >>> +
> >>> +*  to = \(kvmalloc@p\|kvzalloc@p\)(size,\(GFP_KERNEL\|GFP_USER\));
> >>> +   if (to==NULL || ...) S1
> >>> +   if (copy_from_user(to, from, size) != 0)
> >>> +   S2
> >>
> >> * Can it be helpful to omit the SmPL asterisk functionality from
> >>   the operation modes “org” and “report”?
> >>
> >> * Should the operation mode “context” work without an extra position metavariable?
> >
> > This is fine as is in all three aspects.
>
> Is every technique from the Coccinelle software required for
> each operation mode in such data processing approaches?
>
> Regards,
> Markus
>

Re: [v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()

[Markus Elfring]

> Markus, you are welcome to try this since you are concerned about it.

I dare to point software design variations for some reasons.


> But it doesn't matter.

Under which circumstances would you begin to care more for involved differences
in corresponding run time characteristics?

Regards,
Markus

Re: [v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()

[Markus Elfring]

> Markus, you are welcome to try this since you are concerned about it.

I dare to point software design variations for some reasons.


> But it doesn't matter.

Under which circumstances would you begin to care more for involved differences
in corresponding run time characteristics?

Regards,
Markus

Re: [v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()

[Julia Lawall]

On Wed, 22 Jul 2020, Markus Elfring wrote:

> > Markus, you are welcome to try this since you are concerned about it.
>
> I dare to point software design variations for some reasons.
>
>
> > But it doesn't matter.
>
> Under which circumstances would you begin to care more for involved differences
> in corresponding run time characteristics?

When the difference is hours vs seconds.  In this case, there are
tradeoffs between the two options, andI don't know which would be faster,
but I think it is extremely unlikely that the difference is noticible.
But if you are concerned about it, you are welcome to try.

julia

Re: [Cocci] [v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()

[Julia Lawall]

On Wed, 22 Jul 2020, Markus Elfring wrote:

> > Markus, you are welcome to try this since you are concerned about it.
>
> I dare to point software design variations for some reasons.
>
>
> > But it doesn't matter.
>
> Under which circumstances would you begin to care more for involved differences
> in corresponding run time characteristics?

When the difference is hours vs seconds.  In this case, there are
tradeoffs between the two options, andI don't know which would be faster,
but I think it is extremely unlikely that the difference is noticible.
But if you are concerned about it, you are welcome to try.

julia
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()

[Julia Lawall]

On Wed, 22 Jul 2020, Markus Elfring wrote:

> > Markus, you are welcome to try this since you are concerned about it.
>
> I dare to point software design variations for some reasons.
>
>
> > But it doesn't matter.
>
> Under which circumstances would you begin to care more for involved differences
> in corresponding run time characteristics?

When the difference is hours vs seconds.  In this case, there are
tradeoffs between the two options, andI don't know which would be faster,
but I think it is extremely unlikely that the difference is noticible.
But if you are concerned about it, you are welcome to try.

julia

Re: [v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()

[Markus Elfring]

>> Under which circumstances would you begin to care more for involved differences
>> in corresponding run time characteristics?
>
> When the difference is hours vs seconds.

Such a view can be influenced by execution environments in considerable ways.


> In this case, there are tradeoffs between the two options,

I am trying to improve the awareness for possible software design variations.


> andI don't know which would be faster,

I am curious if more contributors would get into the mood to compare
data processing approaches a bit more.


> but I think it is extremely unlikely that the difference is noticible.

But the following effects may be known for the evaluation of a SmPL rule
which was combined for two code parts.

* The SmPL dependencies are checked only once.

* Can the source code search efforts be reduced a bit?


> But if you are concerned about it, you are welcome to try.

Will anybody become interested to measure the software behaviour exactly?

Regards,
Markus

Re: [v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()

[Markus Elfring]

>> Under which circumstances would you begin to care more for involved differences
>> in corresponding run time characteristics?
>
> When the difference is hours vs seconds.

Such a view can be influenced by execution environments in considerable ways.


> In this case, there are tradeoffs between the two options,

I am trying to improve the awareness for possible software design variations.


> andI don't know which would be faster,

I am curious if more contributors would get into the mood to compare
data processing approaches a bit more.


> but I think it is extremely unlikely that the difference is noticible.

But the following effects may be known for the evaluation of a SmPL rule
which was combined for two code parts.

* The SmPL dependencies are checked only once.

* Can the source code search efforts be reduced a bit?


> But if you are concerned about it, you are welcome to try.

Will anybody become interested to measure the software behaviour exactly?

Regards,
Markus