Project

General

Profile

Actions

Feature #3232

open

043: Using a blocking memory allocation when spinlock is held

Added by Evgeny Novikov over 11 years ago. Updated over 9 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 1 (0 open1 closed)

Related to C Instrumentation Framework - Feature #3802: Add ability to refer to function argument by its name specified in aspect fileClosedEvgeny Novikov12/14/2012

Actions
Actions #1

Updated by Evgeny Novikov over 11 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.

Actions #2

Updated by Evgeny Novikov over 11 years ago

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

Actions #3

Updated by Vadim Mutilin over 11 years ago

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

Actions #4

Updated by Evgeny Novikov about 11 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).

Actions #5

Updated by Ilya Shchepetkov about 11 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.

Actions #6

Updated by Alexey Khoroshilov about 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
Actions #7

Updated by Alexey Khoroshilov over 10 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.

Actions #8

Updated by Vadim Mutilin over 10 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
Actions #9

Updated by Vitaly Mordan over 9 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.

Actions #10

Updated by Evgeny Novikov over 9 years ago

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

Also available in: Atom PDF