Feature #3232
open043: Using a blocking memory allocation when spinlock is held
0%
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¶
Updated by Evgeny Novikov over 12 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.
Updated by Evgeny Novikov over 12 years ago
Commit 1f558ed of the master branch has changed corresponding verdicts temporary to pass night tests.
Updated by Vadim Mutilin about 12 years ago
Commits which fix this type of errors in linux-stable repository
2636e65
Updated by Evgeny Novikov almost 12 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).
Updated by Ilya Shchepetkov almost 12 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.
Updated by Alexey Khoroshilov over 11 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
Updated by Alexey Khoroshilov over 11 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.
Updated by Vadim Mutilin about 11 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
Updated by Vitaly Mordan about 10 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.
Updated by Evgeny Novikov about 10 years ago
- Status changed from Resolved to Open
- Assignee changed from Ilya Shchepetkov to Vitaly Mordan