Project

General

Profile

Actions

Feature #3802

closed

Add ability to refer to function argument by its name specified in aspect file

Added by Evgeny Novikov over 11 years ago. Updated about 11 years ago.

Status:
Closed
Priority:
High
Category:
-
Start date:
12/14/2012
Due date:
% Done:

0%

Estimated time:
Published in build:
24ff9f3

Description

Often it may be helpful to refer to a function argument by its name specified in an aspect file. I mean, that we would like to write something like:

pointcut KALLOC: execution(static inline void *kcalloc(.., gfp_t flags, ..)
              || call(void * krealloc(.., gfp_t flags, ..))
              ...
              || call(int pskb_expand_head(.., gfp_t flags, ..))
              || call(struct sk_buff *skb_copy_expand(.., gfp_t flags, ..))
              ...

and then refer in corresponding advice bodies to flags instead of separating this pointcut to several ones in depend on the gft_t argument place:
pointcut ARG_3: execution(static inline void *kcalloc(..))
    || call(void * krealloc(..))
        ...
pointcut ARG_4: call(int pskb_expand_head(..))
    || call(struct sk_buff *skb_copy_expand(..))
    ...

and creating multiple advices referring to $argi for each of ARG_i pointcuts.

BTW, there is a special mechanism in, say, AspectJ and ACC, that is referred as "pointcut parameters". With help of it we will be able to shorten KALLOC pointcut definition:

pointcut KALLOC(flags): (execution(static inline void *kcalloc(..)
              || call(void * krealloc(..))
              ...
              || call(int pskb_expand_head(..))
              || call(struct sk_buff *skb_copy_expand(..))
              ...)
              && args(.., gfp_t flags, ..)

Although this notation as well as its "full" variant doesn't take care on parameter place, that may be important in some cases. To do this we either should use such the pointcut (it looks too expensive :)):
pointcut KALLOC: execution(static inline void *kcalloc($, $, gfp_t flags, ..)
              || call(void * krealloc($, $, gfp_t flags, ..))
              ...
              || call(int pskb_expand_head($, $, $, gfp_t flags, ..))
              || call(struct sk_buff *skb_copy_expand($, $, $, gfp_t flags, ..))
              ...

or something like this:
pointcut KALLOC: execution(static inline void *kcalloc(..<2>, gfp_t flags, ..)
              || call(void * krealloc(..<2>, gfp_t flags, ..))
              ...
              || call(int pskb_expand_head(..<3>, gfp_t flags, ..))
              || call(struct sk_buff *skb_copy_expand(..<3>, gfp_t flags, ..))
              ...

One more task is to combine together function calls that have flags and that haven't them (GFP_KERNEL is implied implicitly):
pointcut KALLOC: execution(static inline void *kcalloc(..<2>, gfp_t flags, ..)
              || call(void * krealloc(..<2>, gfp_t flags, ..))
              ...
              || call(int pskb_expand_head(..<3>, gfp_t flags, ..))
              || call(struct sk_buff *skb_copy_expand(..<3>, gfp_t flags, ..))
              ...
              || call(void *vmalloc(..))

But this case we should be able to write in advice body something like:
ldv_check_flags($defined<flags,GFP_KERNEL>);

may be it exceeds formalization requirements, since it may be easier and clearer to write a separate binding and a separate model function for memory allocation functions without flags.


Files

43_1a-new.zip (2.28 KB) 43_1a-new.zip Ilya Shchepetkov, 02/06/2013 01:23 PM

Related issues 4 (3 open1 closed)

Related to Linux Kernel Safety RuleDB - Feature #3220: 077: NOIO allocation under usb_lockOpenVitaly Mordan07/17/2012

Actions
Related to Linux Kernel Safety RuleDB - Feature #3317: 010: Usage of a GFP_ATOMIC flag in functions of memory allocation in a context of interrupt.ResolvedVladimir Gratinskiy08/01/201208/08/2012

Actions
Related to Linux Kernel Safety RuleDB - Feature #3232: 043: Using a blocking memory allocation when spinlock is heldOpenVitaly Mordan07/19/2012

Actions
Blocked by C Instrumentation Framework - Bug #3920: Matching for typedef names any parameters wildcard works incorrectly sometimesClosedEvgeny Novikov02/06/2013

Actions
Actions #1

Updated by Evgeny Novikov about 11 years ago

  • Status changed from Open to Resolved

Implemented in commit 24ff9f3 of the master branch.

Don't forget to update 10, 43 and 77 models after closing this issue!

Actions #2

Updated by Evgeny Novikov about 11 years ago

  • Status changed from Resolved to Closed
  • Published in build set to 24ff9f3

Small tests passed.

Actions #3

Updated by Ilya Shchepetkov about 11 years ago

I updated 43_1a model, but tests didn't pass:

error: redefinition of parameter 'flags'
note: previous definition of 'flags' was here 
In function 'kmalloc':

Test drivers: /ldv-tools/ldv-tests/rule-models/drivers/43_1a/test-alloc_skb/

New 43_1a model is in the attachment.

Actions #4

Updated by Evgeny Novikov about 11 years ago

  • Status changed from Closed to Open
Actions #5

Updated by Evgeny Novikov about 11 years ago

  • Status changed from Open to Closed

It should work properly after fixing #3920.

Actions

Also available in: Atom PDF