Online Linux Driver Verification Service (alpha)

0043

RULE_ERROR

Using a blocking memory allocation when spinlock is held

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:

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

Example

drivers/net/wireless/orinoco/wext.c

Notes

Without MMU, it's impossible to unload some pages to the swap if we want to reuse memory. Assume a kernel module (e.g. driver) has acquired a lock, calls a sleeping memory allocation function, and goes to the waiting state. It can get back to the active state (thus releasing the lock) only if any other kernel module will turn some of its pages back to the system.

Embedded systems usually use few kernel processes; moreover, most of them are system ones (not modules/drivers). The situation when system process is waiting for unlocking and can't release some of its pages is quite possible. This situation leads to a failure of the whole system or its part.