Possible to backport this vhost-net fix to 3.10?

[Eddie Chapman <eddie@ehuk.net>]

Hi,

I've been regularly seeing on the 3.10 stable kernels the same problem 
as reported by Romain Francoise here:
https://lkml.org/lkml/2013/1/23/492

An example from my setup is at the bottom of this mail. It's a problem 
as qemu fails to run when it hits this, only solution is to do all qemu 
launches with vhost=off after it happens. It starts happening after the 
machine has been running for a while and after a few VMs have been 
started. I guess that is the fragmentation issue as the machine is never 
under any serious memory pressure when it happens.

I see this set of changes for 3.16 has a couple of fixes which appear to 
address the problem:
https://lkml.org/lkml/2014/6/11/302

I was just wondering if there are any plans to backport these to 3.10, 
or even if it is actually possible (I'm not a kernel dev so wouldn't know)?

If not, are there any other workarounds other than vhost=off?

thanks,
Eddie

[1948751.794040] qemu-system-x86: page allocation failure: order:4, 
mode:0x1040d0
[1948751.810341] CPU: 4 PID: 41198 Comm: qemu-system-x86 Not tainted 
3.10.53-rc1 #3
[1948751.826846] Hardware name: Intel Corporation S1200BTL/S1200BTL, 
BIOS S1200BT.86B.02.00.0041.120520121743 12/05/2012
[1948751.847285]  0000000000000004 ffff8802eaf3b9d8 ffffffff8162ff4d 
ffff8802eaf3ba68
[1948751.864257]  ffffffff810ab771 0000000000000001 ffff8802eaf3bb48 
ffff8802eaf3ba68
[1948751.881209]  ffffffff810abe68 ffffffff81ca2f40 ffffffff00000000 
0000000200000040
[1948751.898276] Call Trace:
[1948751.909628]  [<ffffffff8162ff4d>] dump_stack+0x19/0x1c
[1948751.924284]  [<ffffffff810ab771>] warn_alloc_failed+0x111/0x126
[1948751.939774]  [<ffffffff810abe68>] ? 
__alloc_pages_direct_compact+0x181/0x198
[1948751.956650]  [<ffffffff810ac5ae>] __alloc_pages_nodemask+0x72f/0x77c
[1948751.972853]  [<ffffffff810ac676>] __get_free_pages+0x12/0x41
[1948751.988297]  [<ffffffffa04ac71b>] vhost_net_open+0x23/0x171 [vhost_net]
[1948752.004938]  [<ffffffff8130d6c3>] misc_open+0x119/0x17d
[1948752.020111]  [<ffffffff810e99b4>] chrdev_open+0x134/0x155
[1948752.035604]  [<ffffffff81053193>] ? lg_local_unlock+0x1e/0x31
[1948752.051436]  [<ffffffff810e9880>] ? cdev_put+0x24/0x24
[1948752.066540]  [<ffffffff810e46b8>] do_dentry_open+0x15c/0x20f
[1948752.082214]  [<ffffffff810e484b>] finish_open+0x34/0x3f
[1948752.097234]  [<ffffffff810f2737>] do_last+0x996/0xbcb
[1948752.111983]  [<ffffffff810ef98e>] ? link_path_walk+0x5e/0x791
[1948752.127447]  [<ffffffff810f0296>] ? path_init+0x11d/0x403
[1948752.142517]  [<ffffffff810f2a32>] path_openat+0xc6/0x43b
[1948752.157207]  [<ffffffff81070f08>] ? __lock_acquire+0x9ae/0xa4a
[1948752.172369]  [<ffffffff815ac2ef>] ? rtnl_unlock+0x9/0xb
[1948752.186893]  [<ffffffff810f2eac>] do_filp_open+0x38/0x84
[1948752.201503]  [<ffffffff81633673>] ? _raw_spin_unlock+0x26/0x2a
[1948752.216719]  [<ffffffff810fdfef>] ? __alloc_fd+0xf6/0x10a
[1948752.231521]  [<ffffffff810e437c>] do_sys_open+0x114/0x1a6
[1948752.246396]  [<ffffffff810e4438>] SyS_open+0x19/0x1b
[1948752.260709]  [<ffffffff816341d2>] system_call_fastpath+0x16/0x1b