Project

General

Profile

Feature #3232

043: Using a blocking memory allocation when spinlock is held

Added by Evgeny Novikov over 6 years ago. Updated over 4 years ago.

Status:
Open
Priority:
Normal
Assignee:
Start date:
07/19/2012
Due date:
% Done:

0%

Estimated time:
Published in build:

Description

(copied almost as is from kernel-rules/rules/DRVRULES_en.trl)

Summary

You should use GFP_ATOMIC flag when calling memory allocation functions when spinlock is held.

Description

A sleeping memory allocations should be forbidden when spinlock is held. Sleeping memory allocation may cause context switch to the other process if the allocation system (e.g. SLAB) can't allocate memory right now. This erroneous behavior can result in:
  • General decrease of system productivity. The other system processes (including real-time processes) that use locked resource will depend on memory allocation.
  • OS corruption in embedded systems (those without MMU and address pages), because an implicit deadlock happens if memory allocation is impossible at the moment.

Therefore, having a spinlock acquired, you should use GFP_ATOMIC flag when calling memory allocation functions, such as `kmalloc`, `vmalloc`, `get_free_pages` etc.

Links

Sample bugfix in drivers/net/wireless/orinoco/wext.c


Related issues

Related to C Instrumentation Framework - Feature #3802: Add ability to refer to function argument by its name specified in aspect fileClosed2012-12-14

History

#1 Updated by Evgeny Novikov over 6 years ago

Corresponding models 43_1 (old aspect model) and 43_1a (new aspect model) were already implemented. In fixing #453 and related issues old aspect model was completely removed and test sets were fixed respectively (43_1a id is used instead of 43_1). There is such the difference for the medium test set:

-driver=kbdrivers--0043-2.6.31.6--test-0043-2.6.31.6-verdict-unsafe-drivers--char--hvc_console.c.tar.bz2;origin=external;kernel=linux-2.6.31.6;model=43_1a;module=drivers/kbdrivers/0043-2.6.31.6/test-0043-2.6.31.6-verdict-unsafe-drivers--char--hvc_console.c/hvc_console.ko;main=ldv_main0_sequence_infinite_withcheck_stateful;verdict=unsafe                                     
-driver=kbdrivers--0043-2.6.31.6--test-0043-2.6.31.6-verdict-unsafe-drivers--char--n_r3964.c.tar.bz2;origin=external;kernel=linux-2.6.31.6;model=43_1a;module=drivers/kbdrivers/0043-2.6.31.6/test-0043-2.6.31.6-verdict-unsafe-drivers--char--n_r3964.c/n_r3964.ko;main=ldv_main0_sequence_infinite_withcheck_stateful;verdict=unsafe                                                 
-driver=kbdrivers--0043-2.6.31.6--test-0043-2.6.31.6-verdict-unsafe-drivers--net--hamradio--6pack.c.tar.bz2;origin=external;kernel=linux-2.6.31.6;model=43_1a;module=drivers/kbdrivers/0043-2.6.31.6/test-0043-2.6.31.6-verdict-unsafe-drivers--net--hamradio--6pack.c/6pack.ko;main=ldv_main0_sequence_infinite_withcheck_stateful;verdict=unsafe                                     
+driver=kbdrivers--0043-2.6.31.6--test-0043-2.6.31.6-verdict-unsafe-drivers--char--hvc_console.c.tar.bz2;origin=external;kernel=linux-2.6.31.6;model=43_1a;module=drivers/kbdrivers/0043-2.6.31.6/test-0043-2.6.31.6-verdict-unsafe-drivers--char--hvc_console.c/hvc_console.ko;main=ldv_main0_sequence_infinite_withcheck_stateful;verdict=safe                                       
+driver=kbdrivers--0043-2.6.31.6--test-0043-2.6.31.6-verdict-unsafe-drivers--char--n_r3964.c.tar.bz2;origin=external;kernel=linux-2.6.31.6;model=43_1a;module=drivers/kbdrivers/0043-2.6.31.6/test-0043-2.6.31.6-verdict-unsafe-drivers--char--n_r3964.c/n_r3964.ko;main=ldv_main0_sequence_infinite_withcheck_stateful;verdict=safe                                                   
+driver=kbdrivers--0043-2.6.31.6--test-0043-2.6.31.6-verdict-unsafe-drivers--net--hamradio--6pack.c.tar.bz2;origin=external;kernel=linux-2.6.31.6;model=43_1a;module=drivers/kbdrivers/0043-2.6.31.6/test-0043-2.6.31.6-verdict-unsafe-drivers--net--hamradio--6pack.c/6pack.ko;main=ldv_main0_sequence_infinite_withcheck_stateful;verdict=safe
-driver=test-0043-drivers-net-wireless-orinoco-wext-safe.tar.bz2;origin=external;kernel=linux-2.6.32.15;model=43_1a;module=drivers/test-0043-drivers-net-wireless-orinoco-wext-safe/wext.ko;main=ldv_main0_sequence_infinite_withcheck_stateful;verdict=unsafe
+driver=test-0043-drivers-net-wireless-orinoco-wext-safe.tar.bz2;origin=external;kernel=linux-2.6.32.15;model=43_1a;module=drivers/test-0043-drivers-net-wireless-orinoco-wext-safe/wext.ko;main=ldv_main0_sequence_infinite_withcheck_stateful;verdict=safe

One should investigate what has happened and may be tune 43_1a model or/and tests.

#2 Updated by Evgeny Novikov over 6 years ago

Commit 1f558ed of the master branch has changed corresponding verdicts temporary to pass night tests.

#3 Updated by Vadim Mutilin over 6 years ago

Commits which fix this type of errors in linux-stable repository
2636e65

#4 Updated by Evgeny Novikov about 6 years ago

  • Status changed from New to Open
  • Assignee set to Ilya Shchepetkov

Please, use ability to refer to function argument by its name specified in aspect file (implemented in #3802).

#5 Updated by Ilya Shchepetkov about 6 years ago

  • Status changed from Open to Resolved

The ability to refer to function argument by its name specified in aspect file was added in the commit b4b7331 of master branch.

Tests passed.

#6 Updated by Alexey Khoroshilov about 6 years ago

  • Subject changed from 43_1: Using a blocking memory allocation when spinlock is held to 043_1: Using a blocking memory allocation when spinlock is held

#7 Updated by Alexey Khoroshilov over 5 years ago

More correct statement:
Having a spinlock acquired, you should use GFP_ATOMIC or GFP_NOWAIT flag when calling memory allocation functions.
GFP_NOWAIT is similar to GFP_ATOMIC, but it asks to not use emergency pool if there is no regular memory found.

Even more correct statement (bit-level):
Having a spinlock acquired, you should call memory allocation functions with __GFP_WAIT flag unset.

#8 Updated by Vadim Mutilin over 5 years ago

  • Subject changed from 043_1: Using a blocking memory allocation when spinlock is held to 043: Using a blocking memory allocation when spinlock is held

#9 Updated by Vitaly Mordan over 4 years ago

Some functions in "before: ALLOC", "around: ALLOC_AROUND" and "before: ALLOC_WITHOUT" (for example, static inline void *kmalloc(.., gfp_t flags, ..) and static inline void *kzalloc(.., gfp_t flags, ..)) will always return 0, which makes some pathes in program infeasible.

#10 Updated by Evgeny Novikov over 4 years ago

  • Status changed from Resolved to Open
  • Assignee changed from Ilya Shchepetkov to Vitaly Mordan

Also available in: Atom PDF