0036-kernel-fs-seq_file-fallback-to-vmalloc-instead-of-oom-kill-processes.patch 2.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263
  1. From: Matthias Schiffer <mschiffer@universe-factory.net>
  2. Date: Mon, 4 Jan 2016 10:22:52 +0100
  3. Subject: kernel: fs, seq_file: fallback to vmalloc instead of oom kill processes
  4. diff --git a/target/linux/generic/patches-3.18/089-fs-seq_file-fallback-to-vmalloc-instead-of-oom-kill-.patch b/target/linux/generic/patches-3.18/089-fs-seq_file-fallback-to-vmalloc-instead-of-oom-kill-.patch
  5. new file mode 100644
  6. index 0000000..cad56f4
  7. --- /dev/null
  8. +++ b/target/linux/generic/patches-3.18/089-fs-seq_file-fallback-to-vmalloc-instead-of-oom-kill-.patch
  9. @@ -0,0 +1,53 @@
  10. +From 5cec38ac866bfb8775638e71a86e4d8cac30caae Mon Sep 17 00:00:00 2001
  11. +Message-Id: <5cec38ac866bfb8775638e71a86e4d8cac30caae.1451899087.git.mschiffer@universe-factory.net>
  12. +From: David Rientjes <rientjes@google.com>
  13. +Date: Fri, 12 Dec 2014 16:56:16 -0800
  14. +Subject: [PATCH] fs, seq_file: fallback to vmalloc instead of oom kill
  15. + processes
  16. +
  17. +Since commit 058504edd026 ("fs/seq_file: fallback to vmalloc allocation"),
  18. +seq_buf_alloc() falls back to vmalloc() when the kmalloc() for contiguous
  19. +memory fails. This was done to address order-4 slab allocations for
  20. +reading /proc/stat on large machines and noticed because
  21. +PAGE_ALLOC_COSTLY_ORDER < 4, so there is no infinite loop in the page
  22. +allocator when allocating new slab for such high-order allocations.
  23. +
  24. +Contiguous memory isn't necessary for caller of seq_buf_alloc(), however.
  25. +Other GFP_KERNEL high-order allocations that are <=
  26. +PAGE_ALLOC_COSTLY_ORDER will simply loop forever in the page allocator and
  27. +oom kill processes as a result.
  28. +
  29. +We don't want to kill processes so that we can allocate contiguous memory
  30. +in situations when contiguous memory isn't necessary.
  31. +
  32. +This patch does the kmalloc() allocation with __GFP_NORETRY for high-order
  33. +allocations. This still utilizes memory compaction and direct reclaim in
  34. +the allocation path, the only difference is that it will fail immediately
  35. +instead of oom kill processes when out of memory.
  36. +
  37. +[akpm@linux-foundation.org: add comment]
  38. +Signed-off-by: David Rientjes <rientjes@google.com>
  39. +Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
  40. +Cc: Christoph Hellwig <hch@infradead.org>
  41. +Cc: Al Viro <viro@zeniv.linux.org.uk>
  42. +Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
  43. +Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  44. +---
  45. + fs/seq_file.c | 6 +++++-
  46. + 1 file changed, 5 insertions(+), 1 deletion(-)
  47. +
  48. +--- a/fs/seq_file.c
  49. ++++ b/fs/seq_file.c
  50. +@@ -36,7 +36,11 @@ static void *seq_buf_alloc(unsigned long
  51. + {
  52. + void *buf;
  53. +
  54. +- buf = kmalloc(size, GFP_KERNEL | __GFP_NOWARN);
  55. ++ /*
  56. ++ * __GFP_NORETRY to avoid oom-killings with high-order allocations -
  57. ++ * it's better to fall back to vmalloc() than to kill things.
  58. ++ */
  59. ++ buf = kmalloc(size, GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN);
  60. + if (!buf && size > PAGE_SIZE)
  61. + buf = vmalloc(size);
  62. + return buf;