1. 08 Nov, 2019 5 commits
    • Linus Torvalds's avatar
      Merge tag 'drm-fixes-2019-11-08' of git://anongit.freedesktop.org/drm/drm · efc61f7c
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "Weekly fixes for drm: amdgpu has a few but they are pretty scattered
        fixes, the fbdev one is a build regression fix that we didn't want to
        risk leaving out, otherwise a couple of i915, one radeon and a core
        atomic fix.
      
        core:
         - add missing documentation for GEM shmem madvise helpers
         - Fix for a state dereference in atomic self-refresh helpers
      
        fbdev:
         - One compilation fix for c2p fbdev helpers
      
        amdgpu:
         - Fix navi14 display issue root cause and revert workaround
         - GPU reset scheduler interaction fix
         - Fix fan boost on multi-GPU
         - Gfx10 and sdma5 fixes for navi
         - GFXOFF fix for renoir
         - Add navi14 PCI ID
         - GPUVM fix for arcturus
      
        radeon:
         - Port an SI power fix from amdgpu
      
        i915:
         - Fix HPD poll to avoid kworker consuming a lot of cpu cycles.
         - Do not use TBT type for non Type-C ports"
      
      * tag 'drm-fixes-2019-11-08' of git://anongit.freedesktop.org/drm/drm:
        drm/radeon: fix si_enable_smc_cac() failed issue
        drm/amdgpu/renoir: move gfxoff handling into gfx9 module
        drm/amdgpu: add warning for GRBM 1-cycle delay issue in gfx9
        drm/amdgpu: add dummy read by engines for some GCVM status registers in gfx10
        drm/amdgpu: register gpu instance before fan boost feature enablment
        drm/amd/swSMU: fix smu workload bit map error
        drm/shmem: Add docbook comments for drm_gem_shmem_object madvise fields
        drm/amdgpu: add navi14 PCI ID
        Revert "drm/amd/display: setting the DIG_MODE to the correct value."
        drm/amd/display: Add ENGINE_ID_DIGD condition check for Navi14
        drm/amdgpu: dont schedule jobs while in reset
        drm/amdgpu/arcturus: properly set BANK_SELECT and FRAGMENT_SIZE
        drm/atomic: fix self-refresh helpers crtc state dereference
        drm/i915/dp: Do not switch aux to TBT mode for non-TC ports
        drm/i915: Avoid HPD poll detect triggering a new detect cycle
        fbdev: c2p: Fix link failure on non-inlining
      efc61f7c
    • Linus Torvalds's avatar
      Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux · d988f887
      Linus Torvalds authored
      Pull clk fixes from Stephen Boyd:
       "Fixes for various clk driver issues that happened because of code we
        merged this merge window.
      
        The Amlogic driver was missing some flags causing rates to be rounded
        improperly or clk_set_rate() to fail. The Samsung driver wasn't
        freeing everything on error paths and improperly saving/restoring PLL
        state across suspend/resume. The at91 driver was calling msleep() too
        early when scheduling hadn't started, so we put in place a quick
        solution until we can handle this sort of problem in the core
        framework.
      
        There were also problems with the Allwinner driver and operator
        precedence being incorrect causing subtle bugs. Finally, the TI driver
        was duplicating aliases and not delaying long enough leading to some
        unexpected timeouts"
      
      * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
        clk: ti: clkctrl: Fix failed to enable error with double udelay timeout
        clk: ti: dra7-atl-clock: Remove ti_clk_add_alias call
        clk: sunxi-ng: a80: fix the zero'ing of bits 16 and 18
        clk: sunxi: Fix operator precedence in sunxi_divs_clk_setup
        clk: ast2600: Fix enabling of clocks
        clk: at91: avoid sleeping early
        clk: imx8m: Use SYS_PLL1_800M as intermediate parent of CLK_ARM
        clk: samsung: exynos5420: Preserve PLL configuration during suspend/resume
        clk: samsung: exynos542x: Move G3D subsystem clocks to its sub-CMU
        clk: samsung: exynos5433: Fix error paths
        clk: at91: sam9x60: fix programmable clock
        clk: meson: g12a: set CLK_MUX_ROUND_CLOSEST on the cpu clock muxes
        clk: meson: g12a: fix cpu clock rate setting
        clk: meson: gxbb: let sar_adc_clk_div set the parent clock rate
      d988f887
    • Dave Airlie's avatar
      Merge tag 'drm-fixes-5.4-2019-11-06' of git://people.freedesktop.org/~agd5f/linux into drm-fixes · ff923458
      Dave Airlie authored
      drm-fixes-5.4-2019-11-06:
      
      amdgpu:
      - Fix navi14 display issue root cause and revert workaround
      - GPU reset scheduler interaction fix
      - Fix fan boost on multi-GPU
      - Gfx10 and sdma5 fixes for navi
      - GFXOFF fix for renoir
      - Add navi14 PCI ID
      - GPUVM fix for arcturus
      
      radeon:
      - Port an SI power fix from amdgpu
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      From: Alex Deucher <alexdeucher@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191107032241.1021217-1-alexander.deucher@amd.com
      ff923458
    • Dave Airlie's avatar
      Merge tag 'drm-intel-fixes-2019-11-06' of... · 67322bec
      Dave Airlie authored
      Merge tag 'drm-intel-fixes-2019-11-06' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
      
      - Fix HPD poll to avoid kworker consuming a lot of cpu cycles.
      - Do not use TBT type for non Type-C ports.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      
      From: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191106213958.GA16525@intel.com
      67322bec
    • Dave Airlie's avatar
      Merge tag 'drm-misc-fixes-2019-11-07-1' of... · 72d74a06
      Dave Airlie authored
      Merge tag 'drm-misc-fixes-2019-11-07-1' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
      
       - Some new documentation for GEM shmem madvise helpers
       - Fix for a state dereference in atomic self-refresh helpers
       - One compilation fix for c2p fbdev helpers
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      
      From: Maxime Ripard <mripard@kernel.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191107082215.GA34850@gilmour.lan
      72d74a06
  2. 07 Nov, 2019 7 commits
  3. 06 Nov, 2019 26 commits
    • Rob Herring's avatar
      drm/shmem: Add docbook comments for drm_gem_shmem_object madvise fields · 105401b6
      Rob Herring authored
      Add missing docbook comments to madvise fields in struct
      drm_gem_shmem_object which fixes these warnings:
      
      include/drm/drm_gem_shmem_helper.h:87: warning: Function parameter or member 'madv' not described in 'drm_gem_shmem_object'
      include/drm/drm_gem_shmem_helper.h:87: warning: Function parameter or member 'madv_list' not described in 'drm_gem_shmem_object'
      
      Fixes: 17acb9f3 ("drm/shmem: Add madvise state and purge helpers")
      Reported-by: default avatarSean Paul <sean@poorly.run>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Maxime Ripard <mripard@kernel.org>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Reviewed-by: default avatarSean Paul <sean@poorly.run>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191101153754.22803-1-robh@kernel.org
      105401b6
    • Jason Gerecke's avatar
      HID: wacom: generic: Treat serial number and related fields as unsigned · ff479731
      Jason Gerecke authored
      The HID descriptors for most Wacom devices oddly declare the serial
      number and other related fields as signed integers. When these numbers
      are ingested by the HID subsystem, they are automatically sign-extended
      into 32-bit integers. We treat the fields as unsigned elsewhere in the
      kernel and userspace, however, so this sign-extension causes problems.
      In particular, the sign-extended tool ID sent to userspace as ABS_MISC
      does not properly match unsigned IDs used by xf86-input-wacom and libwacom.
      
      We introduce a function 'wacom_s32tou' that can undo the automatic sign
      extension performed by 'hid_snto32'. We call this function when processing
      the serial number and related fields to ensure that we are dealing with
      and reporting the unsigned form. We opt to use this method rather than
      adding a descriptor fixup in 'wacom_hid_usage_quirk' since it should be
      more robust in the face of future devices.
      
      Ref: https://github.com/linuxwacom/input-wacom/issues/134
      Fixes: f85c9dc6 ("HID: wacom: generic: Support tool ID and additional tool types")
      CC: <stable@vger.kernel.org> # v4.10+
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: default avatarAaron Armstrong Skomra <aaron.skomra@wacom.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      ff479731
    • Tianci.Yin's avatar
      drm/amdgpu: add navi14 PCI ID · 5e200fb9
      Tianci.Yin authored
      Add the navi14 PCI device id.
      Reviewed-by: default avatarHawking Zhang <Hawking.Zhang@amd.com>
      Signed-off-by: default avatarTianci.Yin <tianci.yin@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      5e200fb9
    • Zhan Liu's avatar
      Revert "drm/amd/display: setting the DIG_MODE to the correct value." · a85a64d3
      Zhan Liu authored
      This reverts commit 385857ad.
      
      Reason for revert: Root cause of this issue is found. The workaround is not needed anymore.
      Signed-off-by: default avatarZhan Liu <zhan.liu@amd.com>
      Reviewed-by: default avatarHersen Wu <hersenxs.wu@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      a85a64d3
    • Zhan Liu's avatar
      drm/amd/display: Add ENGINE_ID_DIGD condition check for Navi14 · f9686cee
      Zhan Liu authored
      [Why]
      Navi10 has 6 PHY, but Navi14 only has 5 PHY, that is
      because there is no ENGINE_ID_DIGD in Navi14. Without
      this patch, many HDMI related issues (e.g. HDMI S3
      resume failure, HDMI pink screen on boot) will be
      observed.
      
      [How]
      If "eng_id" is larger than ENGINE_ID_DIGD, then
      add "eng_id" by 1.
      Signed-off-by: default avatarZhan Liu <zhan.liu@amd.com>
      Reviewed-by: default avatarHersen Wu <hersenxs.wu@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      f9686cee
    • Shirish S's avatar
      drm/amdgpu: dont schedule jobs while in reset · f2efc6e6
      Shirish S authored
      [Why]
      
      doing kthread_park()/unpark() from drm_sched_entity_fini
      while GPU reset is in progress defeats all the purpose of
      drm_sched_stop->kthread_park.
      If drm_sched_entity_fini->kthread_unpark() happens AFTER
      drm_sched_stop->kthread_park nothing prevents from another
      (third) thread to keep submitting job to HW which will be
      picked up by the unparked scheduler thread and try to submit
      to HW but fail because the HW ring is deactivated.
      
      [How]
      grab the reset lock before calling drm_sched_entity_fini()
      Signed-off-by: default avatarShirish S <shirish.s@amd.com>
      Suggested-by: default avatarChristian König <christian.koenig@amd.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Reviewed-by: default avatarAndrey Grodzovsky <andrey.grodzovsky@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      f2efc6e6
    • Alex Deucher's avatar
      drm/amdgpu/arcturus: properly set BANK_SELECT and FRAGMENT_SIZE · 576daab3
      Alex Deucher authored
      These were not aligned for optimal performance for GPUVM.
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      576daab3
    • Linus Torvalds's avatar
      Merge branch 'akpm' (patches from Andrew) · 4dd58158
      Linus Torvalds authored
      Merge more fixes from Andrew Morton:
       "17 fixes"
      
      Mostly mm fixes and one ocfs2 locking fix.
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        mm: memcontrol: fix network errors from failing __GFP_ATOMIC charges
        mm/memory_hotplug: fix updating the node span
        scripts/gdb: fix debugging modules compiled with hot/cold partitioning
        mm: slab: make page_cgroup_ino() to recognize non-compound slab pages properly
        MAINTAINERS: update information for "MEMORY MANAGEMENT"
        dump_stack: avoid the livelock of the dump_lock
        zswap: add Vitaly to the maintainers list
        mm/page_alloc.c: ratelimit allocation failure warnings more aggressively
        mm/khugepaged: fix might_sleep() warn with CONFIG_HIGHPTE=y
        mm, vmstat: reduce zone->lock holding time by /proc/pagetypeinfo
        mm, vmstat: hide /proc/pagetypeinfo from normal users
        mm/mmu_notifiers: use the right return code for WARN_ON
        ocfs2: protect extent tree in ocfs2_prepare_inode_for_write()
        mm: thp: handle page cache THP correctly in PageTransCompoundMap
        mm, meminit: recalculate pcpu batch and high limits after init completes
        mm/gup_benchmark: fix MAP_HUGETLB case
        mm: memcontrol: fix NULL-ptr deref in percpu stats flush
      4dd58158
    • Rob Clark's avatar
      drm/atomic: fix self-refresh helpers crtc state dereference · 86de88cf
      Rob Clark authored
      drm_self_refresh_helper_update_avg_times() was incorrectly accessing the
      new incoming state after drm_atomic_helper_commit_hw_done().  But this
      state might have already been superceeded by an !nonblock atomic update
      resulting in dereferencing an already free'd crtc_state.
      
      TODO I *think* this will more or less do the right thing.. althought I'm
      not 100% sure if, for example, we enter psr in a nonblock commit, and
      then leave psr in a !nonblock commit that overtakes the completion of
      the nonblock commit.  Not sure if this sort of scenario can happen in
      practice.  But not crashing is better than crashing, so I guess we
      should either take this patch or rever the self-refresh helpers until
      Sean can figure out a better solution.
      
      Fixes: d4da4e33 ("drm: Measure Self Refresh Entry/Exit times to avoid thrashing")
      Cc: Sean Paul <seanpaul@chromium.org>
      Signed-off-by: default avatarRob Clark <robdclark@chromium.org>
      [seanpaul fixed up some checkpatch warns]
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191104173737.142558-1-robdclark@gmail.com
      86de88cf
    • Johannes Weiner's avatar
      mm: memcontrol: fix network errors from failing __GFP_ATOMIC charges · 869712fd
      Johannes Weiner authored
      While upgrading from 4.16 to 5.2, we noticed these allocation errors in
      the log of the new kernel:
      
        SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
          cache: tw_sock_TCPv6(960:helper-logs), object size: 232, buffer size: 240, default order: 1, min order: 0
          node 0: slabs: 5, objs: 170, free: 0
      
              slab_out_of_memory+1
              ___slab_alloc+969
              __slab_alloc+14
              kmem_cache_alloc+346
              inet_twsk_alloc+60
              tcp_time_wait+46
              tcp_fin+206
              tcp_data_queue+2034
              tcp_rcv_state_process+784
              tcp_v6_do_rcv+405
              __release_sock+118
              tcp_close+385
              inet_release+46
              __sock_release+55
              sock_close+17
              __fput+170
              task_work_run+127
              exit_to_usermode_loop+191
              do_syscall_64+212
              entry_SYSCALL_64_after_hwframe+68
      
      accompanied by an increase in machines going completely radio silent
      under memory pressure.
      
      One thing that changed since 4.16 is e699e2c6 ("net, mm: account
      sock objects to kmemcg"), which made these slab caches subject to cgroup
      memory accounting and control.
      
      The problem with that is that cgroups, unlike the page allocator, do not
      maintain dedicated atomic reserves.  As a cgroup's usage hovers at its
      limit, atomic allocations - such as done during network rx - can fail
      consistently for extended periods of time.  The kernel is not able to
      operate under these conditions.
      
      We don't want to revert the culprit patch, because it indeed tracks a
      potentially substantial amount of memory used by a cgroup.
      
      We also don't want to implement dedicated atomic reserves for cgroups.
      There is no point in keeping a fixed margin of unused bytes in the
      cgroup's memory budget to accomodate a consumer that is impossible to
      predict - we'd be wasting memory and get into configuration headaches,
      not unlike what we have going with min_free_kbytes.  We do this for
      physical mem because we have to, but cgroups are an accounting game.
      
      Instead, account these privileged allocations to the cgroup, but let
      them bypass the configured limit if they have to.  This way, we get the
      benefits of accounting the consumed memory and have it exert pressure on
      the rest of the cgroup, but like with the page allocator, we shift the
      burden of reclaimining on behalf of atomic allocations onto the regular
      allocations that can block.
      
      Link: http://lkml.kernel.org/r/20191022233708.365764-1-hannes@cmpxchg.org
      Fixes: e699e2c6 ("net, mm: account sock objects to kmemcg")
      Signed-off-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Reviewed-by: default avatarShakeel Butt <shakeelb@google.com>
      Cc: Suleiman Souhlal <suleiman@google.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: <stable@vger.kernel.org>	[4.18+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      869712fd
    • David Hildenbrand's avatar
      mm/memory_hotplug: fix updating the node span · 656d5711
      David Hildenbrand authored
      We recently started updating the node span based on the zone span to
      avoid touching uninitialized memmaps.
      
      Currently, we will always detect the node span to start at 0, meaning a
      node can easily span too many pages.  pgdat_is_empty() will still work
      correctly if all zones span no pages.  We should skip over all zones
      without spanned pages and properly handle the first detected zone that
      spans pages.
      
      Unfortunately, in contrast to the zone span (/proc/zoneinfo), the node
      span cannot easily be inspected and tested.  The node span gives no real
      guarantees when an architecture supports memory hotplug, meaning it can
      easily contain holes or span pages of different nodes.
      
      The node span is not really used after init on architectures that
      support memory hotplug.
      
      E.g., we use it in mm/memory_hotplug.c:try_offline_node() and in
      mm/kmemleak.c:kmemleak_scan().  These users seem to be fine.
      
      Link: http://lkml.kernel.org/r/20191027222714.5313-1-david@redhat.com
      Fixes: 00d6c019 ("mm/memory_hotplug: don't access uninitialized memmaps in shrink_pgdat_span()")
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Oscar Salvador <osalvador@suse.de>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      656d5711
    • Ilya Leoshkevich's avatar
      scripts/gdb: fix debugging modules compiled with hot/cold partitioning · 8731acc5
      Ilya Leoshkevich authored
      gcc's -freorder-blocks-and-partition option makes it group frequently
      and infrequently used code in .text.hot and .text.unlikely sections
      respectively.  At least when building modules on s390, this option is
      used by default.
      
      gdb assumes that all code is located in .text section, and that .text
      section is located at module load address.  With such modules this is no
      longer the case: there is code in .text.hot and .text.unlikely, and
      either of them might precede .text.
      
      Fix by explicitly telling gdb the addresses of code sections.
      
      It might be tempting to do this for all sections, not only the ones in
      the white list.  Unfortunately, gdb appears to have an issue, when
      telling it about e.g. loadable .note.gnu.build-id section causes it to
      think that non-loadable .note.Linux section is loaded at address 0,
      which in turn causes NULL pointers to be resolved to bogus symbols.  So
      keep using the white list approach for the time being.
      
      Link: http://lkml.kernel.org/r/20191028152734.13065-1-iii@linux.ibm.comSigned-off-by: default avatarIlya Leoshkevich <iii@linux.ibm.com>
      Reviewed-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Cc: Kieran Bingham <kbingham@kernel.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8731acc5
    • Roman Gushchin's avatar
      mm: slab: make page_cgroup_ino() to recognize non-compound slab pages properly · 221ec5c0
      Roman Gushchin authored
      page_cgroup_ino() doesn't return a valid memcg pointer for non-compound
      slab pages, because it depends on PgHead AND PgSlab flags to be set to
      determine the memory cgroup from the kmem_cache.  It's correct for
      compound pages, but not for generic small pages.  Those don't have PgHead
      set, so it ends up returning zero.
      
      Fix this by replacing the condition to PageSlab() && !PageTail().
      
      Before this patch:
        [root@localhost ~]# ./page-types -c /sys/fs/cgroup/user.slice/user-0.slice/user@0.service/ | grep slab
        0x0000000000000080	        38        0  _______S___________________________________	slab
      
      After this patch:
        [root@localhost ~]# ./page-types -c /sys/fs/cgroup/user.slice/user-0.slice/user@0.service/ | grep slab
        0x0000000000000080	       147        0  _______S___________________________________	slab
      
      Also, hwpoison_filter_task() uses output of page_cgroup_ino() in order
      to filter error injection events based on memcg.  So if
      page_cgroup_ino() fails to return memcg pointer, we just fail to inject
      memory error.  Considering that hwpoison filter is for testing, affected
      users are limited and the impact should be marginal.
      
      [n-horiguchi@ah.jp.nec.com: changelog additions]
      Link: http://lkml.kernel.org/r/20191031012151.2722280-1-guro@fb.com
      Fixes: 4d96ba35 ("mm: memcg/slab: stop setting page->mem_cgroup pointer for slab pages")
      Signed-off-by: default avatarRoman Gushchin <guro@fb.com>
      Reviewed-by: default avatarShakeel Butt <shakeelb@google.com>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
      Cc: Daniel Jordan <daniel.m.jordan@oracle.com>
      Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      221ec5c0
    • Song Liu's avatar
      MAINTAINERS: update information for "MEMORY MANAGEMENT" · 6981b76c
      Song Liu authored
      I was trying to find the mm tree in MAINTAINERS by searching "Morton".
      Unfortunately, I didn't find one.  And I didn't even locate the MEMORY
      MANAGEMENT section quickly, because Andrew's name was not listed there.
      
      Thanks to Johannes who helped me find the mm tree.
      
      Let save other's time searching around by adding:
      
      M:	Andrew Morton <akpm@linux-foundation.org>
      T:	git git://github.com/hnaz/linux-mm.git
      
      [akpm@linux-foundation.org: add ozlabs.org quilt trees]
      Link: http://lkml.kernel.org/r/20191030202217.3498133-1-songliubraving@fb.comSigned-off-by: default avatarSong Liu <songliubraving@fb.com>
      Acked-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6981b76c
    • Kevin Hao's avatar
      dump_stack: avoid the livelock of the dump_lock · 5cbf2fff
      Kevin Hao authored
      In the current code, we use the atomic_cmpxchg() to serialize the output
      of the dump_stack(), but this implementation suffers the thundering herd
      problem.  We have observed such kind of livelock on a Marvell cn96xx
      board(24 cpus) when heavily using the dump_stack() in a kprobe handler.
      Actually we can let the competitors to wait for the releasing of the
      lock before jumping to atomic_cmpxchg().  This will definitely mitigate
      the thundering herd problem.  Thanks Linus for the suggestion.
      
      [akpm@linux-foundation.org: fix comment]
      Link: http://lkml.kernel.org/r/20191030031637.6025-1-haokexin@gmail.com
      Fixes: b58d9774 ("dump_stack: serialize the output from dump_stack()")
      Signed-off-by: default avatarKevin Hao <haokexin@gmail.com>
      Suggested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5cbf2fff
    • Vitaly Wool's avatar
      a3163130
    • Johannes Weiner's avatar
      mm/page_alloc.c: ratelimit allocation failure warnings more aggressively · 1be334e5
      Johannes Weiner authored
      While investigating a bug related to higher atomic allocation failures,
      we noticed the failure warnings positively drowning the console, and in
      our case trigger lockup warnings because of a serial console too slow to
      handle all that output.
      
      But even if we had a faster console, it's unclear what additional
      information the current level of repetition provides.
      
      Allocation failures happen for three reasons: The machine is OOM, the VM
      is failing to handle reasonable requests, or somebody is making
      unreasonable requests (and didn't acknowledge their opportunism with
      __GFP_NOWARN).  Having the memory dump, a callstack, and the ratelimit
      stats on skipped failure warnings should provide enough information to
      let users/admins/developers know whether something is wrong and point
      them in the right direction for debugging, bpftracing etc.
      
      Limit allocation failure warnings to one spew every ten seconds.
      
      Link: http://lkml.kernel.org/r/20191028194906.26899-1-hannes@cmpxchg.orgSigned-off-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1be334e5
    • Ville Syrjälä's avatar
      mm/khugepaged: fix might_sleep() warn with CONFIG_HIGHPTE=y · ec649c9d
      Ville Syrjälä authored
      I got some khugepaged spew on a 32bit x86:
      
        BUG: sleeping function called from invalid context at include/linux/mmu_notifier.h:346
        in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 25, name: khugepaged
        INFO: lockdep is turned off.
        CPU: 1 PID: 25 Comm: khugepaged Not tainted 5.4.0-rc5-elk+ #206
        Hardware name: System manufacturer P5Q-EM/P5Q-EM, BIOS 2203    07/08/2009
        Call Trace:
         dump_stack+0x66/0x8e
         ___might_sleep.cold.96+0x95/0xa6
         __might_sleep+0x2e/0x80
         collapse_huge_page.isra.51+0x5ac/0x1360
         khugepaged+0x9a9/0x20f0
         kthread+0xf5/0x110
         ret_from_fork+0x2e/0x38
      
      Looks like it's due to CONFIG_HIGHPTE=y pte_offset_map()->kmap_atomic()
      vs.  mmu_notifier_invalidate_range_start().  Let's do the naive approach
      and just reorder the two operations.
      
      Link: http://lkml.kernel.org/r/20191029201513.GG1208@intel.com
      Fixes: 810e24e0 ("mm/mmu_notifiers: annotate with might_sleep()")
      Signed-off-by: default avatarVille Syrjl <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Jérôme Glisse <jglisse@redhat.com>
      Cc: Ralph Campbell <rcampbell@nvidia.com>
      Cc: Ira Weiny <ira.weiny@intel.com>
      Cc: Jason Gunthorpe <jgg@mellanox.com>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ec649c9d
    • Michal Hocko's avatar
      mm, vmstat: reduce zone->lock holding time by /proc/pagetypeinfo · 93b3a674
      Michal Hocko authored
      pagetypeinfo_showfree_print is called by zone->lock held in irq mode.
      This is not really nice because it blocks both any interrupts on that
      cpu and the page allocator.  On large machines this might even trigger
      the hard lockup detector.
      
      Considering the pagetypeinfo is a debugging tool we do not really need
      exact numbers here.  The primary reason to look at the outuput is to see
      how pageblocks are spread among different migratetypes and low number of
      pages is much more interesting therefore putting a bound on the number
      of pages on the free_list sounds like a reasonable tradeoff.
      
      The new output will simply tell
        [...]
        Node    6, zone   Normal, type      Movable >100000 >100000 >100000 >100000  41019  31560  23996  10054   3229    983    648
      
      instead of
        Node    6, zone   Normal, type      Movable 399568 294127 221558 102119  41019  31560  23996  10054   3229    983    648
      
      The limit has been chosen arbitrary and it is a subject of a future
      change should there be a need for that.
      
      While we are at it, also drop the zone lock after each free_list
      iteration which will help with the IRQ and page allocator responsiveness
      even further as the IRQ lock held time is always bound to those 100k
      pages.
      
      [akpm@linux-foundation.org: tweak comment text, per David Hildenbrand]
      Link: http://lkml.kernel.org/r/20191025072610.18526-3-mhocko@kernel.orgSigned-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Suggested-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Reviewed-by: default avatarWaiman Long <longman@redhat.com>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Acked-by: default avatarDavid Hildenbrand <david@redhat.com>
      Acked-by: default avatarRafael Aquini <aquini@redhat.com>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Jann Horn <jannh@google.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Roman Gushchin <guro@fb.com>
      Cc: Song Liu <songliubraving@fb.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      93b3a674
    • Michal Hocko's avatar
      mm, vmstat: hide /proc/pagetypeinfo from normal users · abaed011
      Michal Hocko authored
      /proc/pagetypeinfo is a debugging tool to examine internal page
      allocator state wrt to fragmentation.  It is not very useful for any
      other use so normal users really do not need to read this file.
      
      Waiman Long has noticed that reading this file can have negative side
      effects because zone->lock is necessary for gathering data and that a)
      interferes with the page allocator and its users and b) can lead to hard
      lockups on large machines which have very long free_list.
      
      Reduce both issues by simply not exporting the file to regular users.
      
      Link: http://lkml.kernel.org/r/20191025072610.18526-2-mhocko@kernel.org
      Fixes: 467c996c ("Print out statistics in relation to fragmentation avoidance to /proc/pagetypeinfo")
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Reported-by: default avatarWaiman Long <longman@redhat.com>
      Acked-by: default avatarMel Gorman <mgorman@suse.de>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Acked-by: default avatarWaiman Long <longman@redhat.com>
      Acked-by: default avatarRafael Aquini <aquini@redhat.com>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: David Hildenbrand <david@redhat.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Roman Gushchin <guro@fb.com>
      Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Cc: Jann Horn <jannh@google.com>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      abaed011
    • Jason Gunthorpe's avatar
      mm/mmu_notifiers: use the right return code for WARN_ON · df2ec764
      Jason Gunthorpe authored
      The return code from the op callback is actually in _ret, while the
      WARN_ON was checking ret which causes it to misfire.
      
      Link: http://lkml.kernel.org/r/20191025175502.GA31127@ziepe.ca
      Fixes: 8402ce61 ("mm/mmu_notifiers: check if mmu notifier callbacks are allowed to fail")
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      df2ec764
    • Shuning Zhang's avatar
      ocfs2: protect extent tree in ocfs2_prepare_inode_for_write() · e74540b2
      Shuning Zhang authored
      When the extent tree is modified, it should be protected by inode
      cluster lock and ip_alloc_sem.
      
      The extent tree is accessed and modified in the
      ocfs2_prepare_inode_for_write, but isn't protected by ip_alloc_sem.
      
      The following is a case.  The function ocfs2_fiemap is accessing the
      extent tree, which is modified at the same time.
      
        kernel BUG at fs/ocfs2/extent_map.c:475!
        invalid opcode: 0000 [#1] SMP
        Modules linked in: tun ocfs2 ocfs2_nodemanager configfs ocfs2_stackglue [...]
        CPU: 16 PID: 14047 Comm: o2info Not tainted 4.1.12-124.23.1.el6uek.x86_64 #2
        Hardware name: Oracle Corporation ORACLE SERVER X7-2L/ASM, MB MECH, X7-2L, BIOS 42040600 10/19/2018
        task: ffff88019487e200 ti: ffff88003daa4000 task.ti: ffff88003daa4000
        RIP: ocfs2_get_clusters_nocache.isra.11+0x390/0x550 [ocfs2]
        Call Trace:
          ocfs2_fiemap+0x1e3/0x430 [ocfs2]
          do_vfs_ioctl+0x155/0x510
          SyS_ioctl+0x81/0xa0
          system_call_fastpath+0x18/0xd8
        Code: 18 48 c7 c6 60 7f 65 a0 31 c0 bb e2 ff ff ff 48 8b 4a 40 48 8b 7a 28 48 c7 c2 78 2d 66 a0 e8 38 4f 05 00 e9 28 fe ff ff 0f 1f 00 <0f> 0b 66 0f 1f 44 00 00 bb 86 ff ff ff e9 13 fe ff ff 66 0f 1f
        RIP  ocfs2_get_clusters_nocache.isra.11+0x390/0x550 [ocfs2]
        ---[ end trace c8aa0c8180e869dc ]---
        Kernel panic - not syncing: Fatal exception
        Kernel Offset: disabled
      
      This issue can be reproduced every week in a production environment.
      
      This issue is related to the usage mode.  If others use ocfs2 in this
      mode, the kernel will panic frequently.
      
      [akpm@linux-foundation.org: coding style fixes]
      [Fix new warning due to unused function by removing said function - Linus ]
      Link: http://lkml.kernel.org/r/1568772175-2906-2-git-send-email-sunny.s.zhang@oracle.comSigned-off-by: default avatarShuning Zhang <sunny.s.zhang@oracle.com>
      Reviewed-by: default avatarJunxiao Bi <junxiao.bi@oracle.com>
      Reviewed-by: default avatarGang He <ghe@suse.com>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Joseph Qi <jiangqi903@gmail.com>
      Cc: Changwei Ge <gechangwei@live.cn>
      Cc: Jun Piao <piaojun@huawei.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e74540b2
    • Yang Shi's avatar
      mm: thp: handle page cache THP correctly in PageTransCompoundMap · 169226f7
      Yang Shi authored
      We have a usecase to use tmpfs as QEMU memory backend and we would like
      to take the advantage of THP as well.  But, our test shows the EPT is
      not PMD mapped even though the underlying THP are PMD mapped on host.
      The number showed by /sys/kernel/debug/kvm/largepage is much less than
      the number of PMD mapped shmem pages as the below:
      
        7f2778200000-7f2878200000 rw-s 00000000 00:14 262232 /dev/shm/qemu_back_mem.mem.Hz2hSf (deleted)
        Size:            4194304 kB
        [snip]
        AnonHugePages:         0 kB
        ShmemPmdMapped:   579584 kB
        [snip]
        Locked:                0 kB
      
        cat /sys/kernel/debug/kvm/largepages
        12
      
      And some benchmarks do worse than with anonymous THPs.
      
      By digging into the code we figured out that commit 127393fb ("mm:
      thp: kvm: fix memory corruption in KVM with THP enabled") checks if
      there is a single PTE mapping on the page for anonymous THP when setting
      up EPT map.  But the _mapcount < 0 check doesn't work for page cache THP
      since every subpage of page cache THP would get _mapcount inc'ed once it
      is PMD mapped, so PageTransCompoundMap() always returns false for page
      cache THP.  This would prevent KVM from setting up PMD mapped EPT entry.
      
      So we need handle page cache THP correctly.  However, when page cache
      THP's PMD gets split, kernel just remove the map instead of setting up
      PTE map like what anonymous THP does.  Before KVM calls get_user_pages()
      the subpages may get PTE mapped even though it is still a THP since the
      page cache THP may be mapped by other processes at the mean time.
      
      Checking its _mapcount and whether the THP has PTE mapped or not.
      Although this may report some false negative cases (PTE mapped by other
      processes), it looks not trivial to make this accurate.
      
      With this fix /sys/kernel/debug/kvm/largepage would show reasonable
      pages are PMD mapped by EPT as the below:
      
        7fbeaee00000-7fbfaee00000 rw-s 00000000 00:14 275464 /dev/shm/qemu_back_mem.mem.SKUvat (deleted)
        Size:            4194304 kB
        [snip]
        AnonHugePages:         0 kB
        ShmemPmdMapped:   557056 kB
        [snip]
        Locked:                0 kB
      
        cat /sys/kernel/debug/kvm/largepages
        271
      
      And the benchmarks are as same as anonymous THPs.
      
      [yang.shi@linux.alibaba.com: v4]
        Link: http://lkml.kernel.org/r/1571865575-42913-1-git-send-email-yang.shi@linux.alibaba.com
      Link: http://lkml.kernel.org/r/1571769577-89735-1-git-send-email-yang.shi@linux.alibaba.com
      Fixes: dd78fedd ("rmap: support file thp")
      Signed-off-by: default avatarYang Shi <yang.shi@linux.alibaba.com>
      Reported-by: default avatarGang Deng <gavin.dg@linux.alibaba.com>
      Tested-by: default avatarGang Deng <gavin.dg@linux.alibaba.com>
      Suggested-by: default avatarHugh Dickins <hughd@google.com>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: <stable@vger.kernel.org>	[4.8+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      169226f7
    • Mel Gorman's avatar
      mm, meminit: recalculate pcpu batch and high limits after init completes · 3e8fc007
      Mel Gorman authored
      Deferred memory initialisation updates zone->managed_pages during the
      initialisation phase but before that finishes, the per-cpu page
      allocator (pcpu) calculates the number of pages allocated/freed in
      batches as well as the maximum number of pages allowed on a per-cpu
      list.  As zone->managed_pages is not up to date yet, the pcpu
      initialisation calculates inappropriately low batch and high values.
      
      This increases zone lock contention quite severely in some cases with
      the degree of severity depending on how many CPUs share a local zone and
      the size of the zone.  A private report indicated that kernel build
      times were excessive with extremely high system CPU usage.  A perf
      profile indicated that a large chunk of time was lost on zone->lock
      contention.
      
      This patch recalculates the pcpu batch and high values after deferred
      initialisation completes for every populated zone in the system.  It was
      tested on a 2-socket AMD EPYC 2 machine using a kernel compilation
      workload -- allmodconfig and all available CPUs.
      
      mmtests configuration: config-workload-kernbench-max Configuration was
      modified to build on a fresh XFS partition.
      
      kernbench
                                      5.4.0-rc3              5.4.0-rc3
                                        vanilla           resetpcpu-v2
      Amean     user-256    13249.50 (   0.00%)    16401.31 * -23.79%*
      Amean     syst-256    14760.30 (   0.00%)     4448.39 *  69.86%*
      Amean     elsp-256      162.42 (   0.00%)      119.13 *  26.65%*
      Stddev    user-256       42.97 (   0.00%)       19.15 (  55.43%)
      Stddev    syst-256      336.87 (   0.00%)        6.71 (  98.01%)
      Stddev    elsp-256        2.46 (   0.00%)        0.39 (  84.03%)
      
                         5.4.0-rc3    5.4.0-rc3
                           vanilla resetpcpu-v2
      Duration User       39766.24     49221.79
      Duration System     44298.10     13361.67
      Duration Elapsed      519.11       388.87
      
      The patch reduces system CPU usage by 69.86% and total build time by
      26.65%.  The variance of system CPU usage is also much reduced.
      
      Before, this was the breakdown of batch and high values over all zones
      was:
      
          256               batch: 1
          256               batch: 63
          512               batch: 7
          256               high:  0
          256               high:  378
          512               high:  42
      
      512 pcpu pagesets had a batch limit of 7 and a high limit of 42.  After
      the patch:
      
          256               batch: 1
          768               batch: 63
          256               high:  0
          768               high:  378
      
      [mgorman@techsingularity.net: fix merge/linkage snafu]
        Link: http://lkml.kernel.org/r/20191023084705.GD3016@techsingularity.netLink: http://lkml.kernel.org/r/20191021094808.28824-2-mgorman@techsingularity.netSigned-off-by: default avatarMel Gorman <mgorman@techsingularity.net>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Acked-by: default avatarDavid Hildenbrand <david@redhat.com>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Qian Cai <cai@lca.pw>
      Cc: <stable@vger.kernel.org>	[4.1+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3e8fc007
    • John Hubbard's avatar
      mm/gup_benchmark: fix MAP_HUGETLB case · 64801d19
      John Hubbard authored
      The MAP_HUGETLB ("-H" option) of gup_benchmark fails:
      
        $ sudo ./gup_benchmark -H
        mmap: Invalid argument
      
      This is because gup_benchmark.c is passing in a file descriptor to
      mmap(), but the fd came from opening up the /dev/zero file.  This
      confuses the mmap syscall implementation, which thinks that, if the
      caller did not specify MAP_ANONYMOUS, then the file must be a huge page
      file.  So it attempts to verify that the file really is a huge page
      file, as you can see here:
      
      ksys_mmap_pgoff()
      {
          if (!(flags & MAP_ANONYMOUS)) {
              retval = -EINVAL;
              if (unlikely(flags & MAP_HUGETLB && !is_file_hugepages(file)))
                  goto out_fput; /* THIS IS WHERE WE END UP */
      
          else if (flags & MAP_HUGETLB) {
              ...proceed normally, /dev/zero is ok here...
      
      ...and of course is_file_hugepages() returns "false" for the /dev/zero
      file.
      
      The problem is that the user space program, gup_benchmark.c, really just
      wants anonymous memory here.  The simplest way to get that is to pass
      MAP_ANONYMOUS whenever MAP_HUGETLB is specified, so that's what this
      patch does.
      
      Link: http://lkml.kernel.org/r/20191021212435.398153-2-jhubbard@nvidia.comSigned-off-by: default avatarJohn Hubbard <jhubbard@nvidia.com>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Reviewed-by: default avatarJérôme Glisse <jglisse@redhat.com>
      Cc: Keith Busch <keith.busch@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      64801d19
    • Shakeel Butt's avatar
      mm: memcontrol: fix NULL-ptr deref in percpu stats flush · 7961eee3
      Shakeel Butt authored
      __mem_cgroup_free() can be called on the failure path in
      mem_cgroup_alloc().  However memcg_flush_percpu_vmstats() and
      memcg_flush_percpu_vmevents() which are called from __mem_cgroup_free()
      access the fields of memcg which can potentially be null if called from
      failure path from mem_cgroup_alloc().  Indeed syzbot has reported the
      following crash:
      
      	kasan: CONFIG_KASAN_INLINE enabled
      	kasan: GPF could be caused by NULL-ptr deref or user memory access
      	general protection fault: 0000 [#1] PREEMPT SMP KASAN
      	CPU: 0 PID: 30393 Comm: syz-executor.1 Not tainted 5.4.0-rc2+ #0
      	Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      	RIP: 0010:memcg_flush_percpu_vmstats+0x4ae/0x930 mm/memcontrol.c:3436
      	Code: 05 41 89 c0 41 0f b6 04 24 41 38 c7 7c 08 84 c0 0f 85 5d 03 00 00 44 3b 05 33 d5 12 08 0f 83 e2 00 00 00 4c 89 f0 48 c1 e8 03 <42> 80 3c 28 00 0f 85 91 03 00 00 48 8b 85 10 fe ff ff 48 8b b0 90
      	RSP: 0018:ffff888095c27980 EFLAGS: 00010206
      	RAX: 0000000000000012 RBX: ffff888095c27b28 RCX: ffffc90008192000
      	RDX: 0000000000040000 RSI: ffffffff8340fae7 RDI: 0000000000000007
      	RBP: ffff888095c27be0 R08: 0000000000000000 R09: ffffed1013f0da33
      	R10: ffffed1013f0da32 R11: ffff88809f86d197 R12: fffffbfff138b760
      	R13: dffffc0000000000 R14: 0000000000000090 R15: 0000000000000007
      	FS:  00007f5027170700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
      	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      	CR2: 0000000000710158 CR3: 00000000a7b18000 CR4: 00000000001406f0
      	DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      	DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      	Call Trace:
      	__mem_cgroup_free+0x1a/0x190 mm/memcontrol.c:5021
      	mem_cgroup_free mm/memcontrol.c:5033 [inline]
      	mem_cgroup_css_alloc+0x3a1/0x1ae0 mm/memcontrol.c:5160
      	css_create kernel/cgroup/cgroup.c:5156 [inline]
      	cgroup_apply_control_enable+0x44d/0xc40 kernel/cgroup/cgroup.c:3119
      	cgroup_mkdir+0x899/0x11b0 kernel/cgroup/cgroup.c:5401
      	kernfs_iop_mkdir+0x14d/0x1d0 fs/kernfs/dir.c:1124
      	vfs_mkdir+0x42e/0x670 fs/namei.c:3807
      	do_mkdirat+0x234/0x2a0 fs/namei.c:3830
      	__do_sys_mkdir fs/namei.c:3846 [inline]
      	__se_sys_mkdir fs/namei.c:3844 [inline]
      	__x64_sys_mkdir+0x5c/0x80 fs/namei.c:3844
      	do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
      	entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Fixing this by moving the flush to mem_cgroup_free as there is no need
      to flush anything if we see failure in mem_cgroup_alloc().
      
      Link: http://lkml.kernel.org/r/20191018165231.249872-1-shakeelb@google.com
      Fixes: bb65f89b ("mm: memcontrol: flush percpu vmevents before releasing memcg")
      Fixes: c350a99e ("mm: memcontrol: flush percpu vmstats before releasing memcg")
      Signed-off-by: default avatarShakeel Butt <shakeelb@google.com>
      Reported-by: syzbot+515d5bcfe179cdf049b2@syzkaller.appspotmail.com
      Reviewed-by: default avatarRoman Gushchin <guro@fb.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7961eee3
  4. 05 Nov, 2019 2 commits
    • Linus Torvalds's avatar
      Merge tag 'for-linus-2019-11-05' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux · 26bc6721
      Linus Torvalds authored
      Pull clone3 stack argument update from Christian Brauner:
       "This changes clone3() to do basic stack validation and to set up the
        stack depending on whether or not it is growing up or down.
      
        With clone3() the expectation is now very simply that the .stack
        argument points to the lowest address of the stack and that
        .stack_size specifies the initial stack size. This is diferent from
        legacy clone() where the "stack" argument had to point to the lowest
        or highest address of the stack depending on the architecture.
      
        clone3() was released with 5.3. Currently, it is not documented and
        very unclear to userspace how the stack and stack_size argument have
        to be passed. After talking to glibc folks we concluded that changing
        clone3() to determine stack direction and doing basic validation is
        the right course of action.
      
        Note, this is a potentially user visible change. In the very unlikely
        case, that it breaks someone's use-case we will revert. (And then e.g.
        place the new behavior under an appropriate flag.)
      
        Note that passing an empty stack will continue working just as before.
        Breaking someone's use-case is very unlikely. Neither glibc nor musl
        currently expose a wrapper for clone3(). There is currently also no
        real motivation for anyone to use clone3() directly. First, because
        using clone{3}() with stacks requires some assembly (see glibc and
        musl). Second, because it does not provide features that legacy
        clone() doesn't. New features for clone3() will first happen in v5.5
        which is why v5.4 is still a good time to try and make that change now
        and backport it to v5.3.
      
        I did a codesearch on https://codesearch.debian.net, github, and
        gitlab and could not find any software currently relying directly on
        clone3(). I expect this to change once we land CLONE_CLEAR_SIGHAND
        which was a request coming from glibc at which point they'll likely
        start using it"
      
      * tag 'for-linus-2019-11-05' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux:
        clone3: validate stack arguments
      26bc6721
    • Linus Torvalds's avatar
      Merge tag 'gpio-v5.4-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio · 7111fa11
      Linus Torvalds authored
      Pull GPIO fixes from Linus Walleij:
       "More GPIO fixes! We found a late regression in the Intel Merrifield
        driver. Oh well. We fixed it up.
      
         - Fix a build error in the tools used for kselftest
      
         - A series of reverts to bring the Intel Merrifield back to working.
      
        We will likely unrevert the reverts for v5.5 but we can't have v5.4
        broken"
      
      * tag 'gpio-v5.4-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
        Revert "gpio: merrifield: Pass irqchip when adding gpiochip"
        Revert "gpio: merrifield: Restore use of irq_base"
        Revert "gpio: merrifield: Move hardware initialization to callback"
        tools: gpio: Use !building_out_of_srctree to determine srctree
      7111fa11