4.9-stable patches

added patches:
	drm-fb-helper-ignore-the-value-of-fb_var_screeninfo.pixclock.patch
	mm-memcg-fix-reclaim-deadlock-with-writeback.patch

diff --git a/queue-4.9/drm-fb-helper-ignore-the-value-of-fb_var_screeninfo.pixclock.patch b/queue-4.9/drm-fb-helper-ignore-the-value-of-fb_var_screeninfo.pixclock.patch
new file mode 100644 (file)
index 0000000..0d78bd3
--- /dev/null
+++ b/queue-4.9/drm-fb-helper-ignore-the-value-of-fb_var_screeninfo.pixclock.patch
@@ -0,0 +1,81 @@
+From 66a8d5bfb518f9f12d47e1d2dce1732279f9451e Mon Sep 17 00:00:00 2001
+From: Ivan Mironov <mironov.ivan@gmail.com>
+Date: Tue, 8 Jan 2019 12:23:53 +0500
+Subject: drm/fb-helper: Ignore the value of fb_var_screeninfo.pixclock
+
+From: Ivan Mironov <mironov.ivan@gmail.com>
+
+commit 66a8d5bfb518f9f12d47e1d2dce1732279f9451e upstream.
+
+Strict requirement of pixclock to be zero breaks support of SDL 1.2
+which contains hardcoded table of supported video modes with non-zero
+pixclock values[1].
+
+To better understand which pixclock values are considered valid and how
+driver should handle these values, I briefly examined few existing fbdev
+drivers and documentation in Documentation/fb/. And it looks like there
+are no strict rules on that and actual behaviour varies:
+
+       * some drivers treat (pixclock == 0) as "use defaults" (uvesafb.c);
+       * some treat (pixclock == 0) as invalid value which leads to
+         -EINVAL (clps711x-fb.c);
+       * some pass converted pixclock value to hardware (uvesafb.c);
+       * some are trying to find nearest value from predefined table
+          (vga16fb.c, video_gx.c).
+
+Given this, I believe that it should be safe to just ignore this value if
+changing is not supported. It seems that any portable fbdev application
+which was not written only for one specific device working under one
+specific kernel version should not rely on any particular behaviour of
+pixclock anyway.
+
+However, while enabling SDL1 applications to work out of the box when
+there is no /etc/fb.modes with valid settings, this change affects the
+video mode choosing logic in SDL. Depending on current screen
+resolution, contents of /etc/fb.modes and resolution requested by
+application, this may lead to user-visible difference (not always):
+image will be displayed in a right way, but it will be aligned to the
+left instead of center. There is no "right behaviour" here as well, as
+emulated fbdev, opposing to old fbdev drivers, simply ignores any
+requsts of video mode changes with resolutions smaller than current.
+
+The easiest way to reproduce this problem is to install sdl-sopwith[2],
+remove /etc/fb.modes file if it exists, and then try to run sopwith
+from console without X. At least in Fedora 29, sopwith may be simply
+installed from standard repositories.
+
+[1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c, vesa_timings
+[2] http://sdl-sopwith.sourceforge.net/
+
+Signed-off-by: Ivan Mironov <mironov.ivan@gmail.com>
+Cc: stable@vger.kernel.org
+Fixes: 79e539453b34e ("DRM: i915: add mode setting support")
+Fixes: 771fe6b912fca ("drm/radeon: introduce kernel modesetting for radeon hardware")
+Fixes: 785b93ef8c309 ("drm/kms: move driver specific fb common code to helper functions (v2)")
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-3-mironov.ivan@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+
+---
+ drivers/gpu/drm/drm_fb_helper.c |    7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/drm_fb_helper.c
++++ b/drivers/gpu/drm/drm_fb_helper.c
+@@ -1238,9 +1238,14 @@ int drm_fb_helper_check_var(struct fb_va
+       struct drm_framebuffer *fb = fb_helper->fb;
+       int depth;
+ 
+-      if (var->pixclock != 0 || in_dbg_master())
++      if (in_dbg_master())
+               return -EINVAL;
+ 
++      if (var->pixclock != 0) {
++              DRM_DEBUG("fbdev emulation doesn't support changing the pixel clock, value of pixclock is ignored\n");
++              var->pixclock = 0;
++      }
++
+       /* Need to resize the fb object !!! */
+       if (var->bits_per_pixel > fb->bits_per_pixel ||
+           var->xres > fb->width || var->yres > fb->height ||

diff --git a/queue-4.9/mm-memcg-fix-reclaim-deadlock-with-writeback.patch b/queue-4.9/mm-memcg-fix-reclaim-deadlock-with-writeback.patch
new file mode 100644 (file)
index 0000000..1a76165
--- /dev/null
+++ b/queue-4.9/mm-memcg-fix-reclaim-deadlock-with-writeback.patch
@@ -0,0 +1,146 @@
+From 63f3655f950186752236bb88a22f8252c11ce394 Mon Sep 17 00:00:00 2001
+From: Michal Hocko <mhocko@suse.com>
+Date: Tue, 8 Jan 2019 15:23:07 -0800
+Subject: mm, memcg: fix reclaim deadlock with writeback
+
+From: Michal Hocko <mhocko@suse.com>
+
+commit 63f3655f950186752236bb88a22f8252c11ce394 upstream.
+
+Liu Bo has experienced a deadlock between memcg (legacy) reclaim and the
+ext4 writeback
+
+  task1:
+    wait_on_page_bit+0x82/0xa0
+    shrink_page_list+0x907/0x960
+    shrink_inactive_list+0x2c7/0x680
+    shrink_node_memcg+0x404/0x830
+    shrink_node+0xd8/0x300
+    do_try_to_free_pages+0x10d/0x330
+    try_to_free_mem_cgroup_pages+0xd5/0x1b0
+    try_charge+0x14d/0x720
+    memcg_kmem_charge_memcg+0x3c/0xa0
+    memcg_kmem_charge+0x7e/0xd0
+    __alloc_pages_nodemask+0x178/0x260
+    alloc_pages_current+0x95/0x140
+    pte_alloc_one+0x17/0x40
+    __pte_alloc+0x1e/0x110
+    alloc_set_pte+0x5fe/0xc20
+    do_fault+0x103/0x970
+    handle_mm_fault+0x61e/0xd10
+    __do_page_fault+0x252/0x4d0
+    do_page_fault+0x30/0x80
+    page_fault+0x28/0x30
+
+  task2:
+    __lock_page+0x86/0xa0
+    mpage_prepare_extent_to_map+0x2e7/0x310 [ext4]
+    ext4_writepages+0x479/0xd60
+    do_writepages+0x1e/0x30
+    __writeback_single_inode+0x45/0x320
+    writeback_sb_inodes+0x272/0x600
+    __writeback_inodes_wb+0x92/0xc0
+    wb_writeback+0x268/0x300
+    wb_workfn+0xb4/0x390
+    process_one_work+0x189/0x420
+    worker_thread+0x4e/0x4b0
+    kthread+0xe6/0x100
+    ret_from_fork+0x41/0x50
+
+He adds
+ "task1 is waiting for the PageWriteback bit of the page that task2 has
+  collected in mpd->io_submit->io_bio, and tasks2 is waiting for the
+  LOCKED bit the page which tasks1 has locked"
+
+More precisely task1 is handling a page fault and it has a page locked
+while it charges a new page table to a memcg.  That in turn hits a
+memory limit reclaim and the memcg reclaim for legacy controller is
+waiting on the writeback but that is never going to finish because the
+writeback itself is waiting for the page locked in the #PF path.  So
+this is essentially ABBA deadlock:
+
+                                        lock_page(A)
+                                        SetPageWriteback(A)
+                                        unlock_page(A)
+  lock_page(B)
+                                        lock_page(B)
+  pte_alloc_pne
+    shrink_page_list
+      wait_on_page_writeback(A)
+                                        SetPageWriteback(B)
+                                        unlock_page(B)
+
+                                        # flush A, B to clear the writeback
+
+This accumulating of more pages to flush is used by several filesystems
+to generate a more optimal IO patterns.
+
+Waiting for the writeback in legacy memcg controller is a workaround for
+pre-mature OOM killer invocations because there is no dirty IO
+throttling available for the controller.  There is no easy way around
+that unfortunately.  Therefore fix this specific issue by pre-allocating
+the page table outside of the page lock.  We have that handy
+infrastructure for that already so simply reuse the fault-around pattern
+which already does this.
+
+There are probably other hidden __GFP_ACCOUNT | GFP_KERNEL allocations
+from under a fs page locked but they should be really rare.  I am not
+aware of a better solution unfortunately.
+
+[akpm@linux-foundation.org: fix mm/memory.c:__do_fault()]
+[akpm@linux-foundation.org: coding-style fixes]
+[mhocko@kernel.org: enhance comment, per Johannes]
+  Link: http://lkml.kernel.org/r/20181214084948.GA5624@dhcp22.suse.cz
+Link: http://lkml.kernel.org/r/20181213092221.27270-1-mhocko@kernel.org
+Fixes: c3b94f44fcb0 ("memcg: further prevent OOM with too many dirty pages")
+Signed-off-by: Michal Hocko <mhocko@suse.com>
+Reported-by: Liu Bo <bo.liu@linux.alibaba.com>
+Debugged-by: Liu Bo <bo.liu@linux.alibaba.com>
+Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
+Acked-by: Johannes Weiner <hannes@cmpxchg.org>
+Reviewed-by: Liu Bo <bo.liu@linux.alibaba.com>
+Cc: Jan Kara <jack@suse.cz>
+Cc: Dave Chinner <david@fromorbit.com>
+Cc: Theodore Ts'o <tytso@mit.edu>
+Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
+Cc: Shakeel Butt <shakeelb@google.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/memory.c |   22 ++++++++++++++++++++++
+ 1 file changed, 22 insertions(+)
+
+--- a/mm/memory.c
++++ b/mm/memory.c
+@@ -2823,6 +2823,28 @@ static int __do_fault(struct fault_env *
+       struct vm_fault vmf;
+       int ret;
+ 
++      /*
++       * Preallocate pte before we take page_lock because this might lead to
++       * deadlocks for memcg reclaim which waits for pages under writeback:
++       *                              lock_page(A)
++       *                              SetPageWriteback(A)
++       *                              unlock_page(A)
++       * lock_page(B)
++       *                              lock_page(B)
++       * pte_alloc_pne
++       *   shrink_page_list
++       *     wait_on_page_writeback(A)
++       *                              SetPageWriteback(B)
++       *                              unlock_page(B)
++       *                              # flush A, B to clear the writeback
++       */
++      if (pmd_none(*fe->pmd) && !fe->prealloc_pte) {
++              fe->prealloc_pte = pte_alloc_one(vma->vm_mm, fe->address);
++              if (!fe->prealloc_pte)
++                      return VM_FAULT_OOM;
++              smp_wmb(); /* See comment in __pte_alloc() */
++      }
++
+       vmf.virtual_address = (void __user *)(fe->address & PAGE_MASK);
+       vmf.pgoff = pgoff;
+       vmf.flags = fe->flags;

diff --git a/queue-4.9/series b/queue-4.9/series
index 9a4eb4ace201d3e7c09dab506437fb24766cfbbe..fc050edbbd7c5f0322d23bb95e30a48598716c83 100644 (file)
--- a/queue-4.9/series
+++ b/queue-4.9/series
@@ -47,3 +47,5 @@ block-loop-use-global-lock-for-ioctl-operation.patch
 loop-fold-__loop_release-into-loop_release.patch
 loop-get-rid-of-loop_index_mutex.patch
 loop-fix-double-mutex_unlock-loop_ctl_mutex-in-loop_control_ioctl.patch
+drm-fb-helper-ignore-the-value-of-fb_var_screeninfo.pixclock.patch
+mm-memcg-fix-reclaim-deadlock-with-writeback.patch