Is __alloc_pages_slowpath() Reentrant-Safe or Not?

Question

Can a call to __alloc_pages_slowpath() survive a device interrupt that also makes a call to __alloc_pages_slowpath() or does the second call corrupt the first one?

I am seeing a program call read(2) of a regular file on an XFS file system. The kernel stack trace shows that eventually __alloc_pages_slowpath() is called then an e1000e IRQ happens which also eventually calls __alloc_pages_slowpath() and then a log message "fooprog: page allocation failure. order:0, mode:0x4020" almost immediately happens.

The entire stack trace can be seen here: https://gist.github.com/790577

Answer 1

The "fooprog: page allocation failure. order:0, mode:0x4020" is due to an e1000e driver issue. Setting vm.min_free_kbytes to double its current value prevents them. __alloc_pages_slowpath() is probably reentrant-safe.

Update: (1) it's "normal behavior" to have huge stack traces printed into your Linux kernel system log when a network device driver tries to allocate a page and finds it can't. (2) someone submitted a patch and for six months it was ignored until I nicely asked them to follow up on getting the patch in. After that KVM/qemu virtio networking stopped locking up when when VMs ran out of memory. (3) the alternatives to Linux are sadly worse for me to use to do real work.