- 13 Dec, 2016 4 commits
-
-
Daniel Vetter authored
With the last round of changes all ioctls called by modern drivers now have their own locking. Everything else is only allowed for legacy drivers and hence the lack of locking doesn't matter. One exception is nouveau, due to the DRIVER_KMS_LEGACY_CONTEXT flag. But that only works its magic on the context and bufs ioctls. And drm_bufs.c is protected with dev->struct_mutex, and drm_context.c by the same and dev->ctxlist_mutex. That should be all safe, and we can finally mandata drm-bkl-less ioctls for everyone! Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161210215255.7765-3-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
It only updates per-file feature flags. And all the ioctl which change behaviour depending upon these flags (they're all kms features) do _not_ hold the BKL. Therefor this is pure cargo-cult and can be removed. Note that there's a risk that the ioctl will behave inconsistently when userspace is racing with itself, but that's ok. The only thing it's not allowed to do is oops the kernel, and from an audit all places are safe. v2: Clarify that the inconsistency is only when userspace races (Chris). Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161210215255.7765-2-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
No one looks at the major/minor versions except the unique/busid stuff. If we protect that with the master_mutex (since it also affects the unique of each master, oh well) we can mark these two IOCTL with DRM_UNLOCKED. While doing this I realized that the comment for the magic_map is outdated, I've forgotten to update it in: commit d2b34ee6 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jun 17 09:33:21 2016 +0200 drm: Protect authmagic with master_mutex Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161210215255.7765-1-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Not setting the fb modifiers flag is something different from setting the fb modifiers to 0 (which means explicitly linear). We kinda failed to document that properly. Spotted by Kristian. Cc: hoegsberg@google.com Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1478694996-4200-1-git-send-email-daniel.vetter@ffwll.ch
-
- 12 Dec, 2016 2 commits
-
-
Daniel Vetter authored
Looping twice when we can do it once is silly. Also use a consistent style. Note that there's a good race with the connector list walking, since that is no longer protected by mode_config.mutex. But that's for a later patch to fix. v2: Actually try to not blow up, somehow I lost the hunk that checks we don't copy too much. Noticed by Chris. v3: - squash all drm_mode_getresources cleanups into one - use consistent style for walking objects (Chris) v4: - Use u64_to_user_ptr (Chris) - Don't forget to copy the last connector (Chris) v5: Chris was right ... Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161211192019.29603-1-daniel.vetter@ffwll.ch
-
Chris Wilson authored
Joonas complained that writing ww_mutex_lock(&resv->lock, ctx) was too intrusive compared to reservation_object_lock(resv, ctx); Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161115154642.31850-1-chris@chris-wilson.co.uk
-
- 08 Dec, 2016 4 commits
-
-
Maarten Lankhorst authored
When DPMS was introduced to atomic, vblanks only worked when the crtc was enabled and active. wait_for_vblanks were not converted to check for crtc_state->active, which may cause an attempt for vblank_get to fail. This is probably harmless, but convert from enable to active anyway. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1481204729-9058-2-git-send-email-maarten.lankhorst@linux.intel.com
-
Daniel Vetter authored
It's supported now! Spotted while reviewing Chris' patch to add a release hook. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161208102847.3063-1-daniel.vetter@ffwll.ch
-
Chris Wilson authored
Currently the reference for the dmabuf->obj is incremented for the dmabuf in drm_gem_prime_handle_to_fd() (at the high level userspace interface), but is released in drm_gem_dmabuf_release() (the lowlevel handler). Improve the symmetry of the dmabuf->obj ownership by acquiring the reference in drm_gem_dmabuf_export(). This makes it easier to use the prime functions directly. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Update kerneldoc.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161207214527.22533-1-chris@chris-wilson.co.uk
-
Daniel Vetter authored
vgem (and our igt tests using vgem) need this. I suspect etnaviv will fare similarly. v2. Make it build. Oops. Fixes: d5264ed3 ("drm: Return -ENOTSUPP when called for KMS cap with a non-KMS driver") Cc: Michel Dänzer <michel.daenzer@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161207144939.22756-1-daniel.vetter@ffwll.ch
-
- 07 Dec, 2016 2 commits
-
-
Gustavo Padovan authored
Instead of dealing with crtc details inside drm_atomic.c we should just export a function that creates a new crtc fence for us and use that. Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1481046437-18778-1-git-send-email-gustavo@padovan.org
-
zain wang authored
We will ignored PSR setting if panel not support it. So, in this case, we should return from analogix_dp_enable/disable_psr() without any error code. Let's retrun 0 instead of -EINVAL when panel not support PSR in analogix_dp_enable/disable_psr(). Signed-off-by: zain wang <wzz@rock-chips.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1481072253-8917-1-git-send-email-wzz@rock-chips.com
-
- 06 Dec, 2016 9 commits
-
-
Gustavo Padovan authored
We now support nonblocking commits on drm_atomic_helper_commit() so the comment is not valid anymore. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1480946626-30917-1-git-send-email-gustavo@padovan.org
-
Chris Wilson authored
If we cannot acquire the mode_config.mutex immediately, just back off and queue a new attempt after the poll interval. This is mostly to stop the hung task spam when the system is deadlocked, but it will also lessen the load (in such extreme cases). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> [danvet:s/lock/mutex/ per Eric's comment.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161206113715.30382-1-chris@chris-wilson.co.uk
-
Michel Dänzer authored
This is an attempt to make the previous fix a bit more robust going forward. v2: * Only allow DRM_CAP_TIMESTAMP_MONOTONIC with UMS drivers (Daniel Vetter, Alex Deucher) * Different logic to keep DRM_CAP_TIMESTAMP_MONOTONIC separate from the other caps (Daniel Vetter) Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161201073731.5716-1-michel@daenzer.net
-
Daniel Vetter authored
Backmerge v4.9-rc8 to get at commit e94bd173 Author: Michel Dänzer <michel.daenzer@amd.com> Date: Wed Nov 30 17:30:01 2016 +0900 drm: Don't call drm_for_each_crtc with a non-KMS driver so I can apply Michel's follow-up patch. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
Nicolai Stange authored
Since commit 8a357d10 ("drm: Nerf DRM_CONTROL nodes"), a struct drm_device's ->control member is always NULL. In the case of CONFIG_DEBUG_FS=y, amdgpu_debugfs_add_files() accesses ->control->debugfs_root though. This results in a NULL pointer dereference. Fix this by omitting the drm_debugfs_create_files() call for the control minor debugfs directory which is now non-existent anyway. Fixes: 8a357d10 ("drm: Nerf DRM_CONTROL nodes") Signed-off-by: Nicolai Stange <nicstange@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98915Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Mike Lothian <mike@fireburn.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161205203022.11671-1-nicstange@gmail.com
-
Marta Lofstedt authored
The drm_atomic_helper_connector_dpms will set the connector back the old DPMS state before returning. This makes it impossible to change DPMS state of the connector. Fixes: 0853695c v2: edit of commit message Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Eric Engestrom <eric.engestrom@imgtec.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: dri-devel@lists.freedesktop.org Cc: <drm-intel-fixes@lists.freedesktop.org> Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161205120408.13056-1-marta.lofstedt@intel.com
-
Dave Airlie authored
Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next Just refactoring HDMI driver by using infoframe helper function, fixing GSC Kconfig dependency issue and including trivial cleanups. * 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm/exynos: Use VIDEO_SAMSUNG_EXYNOS_GSC=n as GSC Kconfig dependency drm/exynos: gsc: fix spelling mistakes exynos-drm: Fix error messages to print flags and size drm/exynos/hdmi: refactor infoframe code
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
- lots of code cleanup - lots of bug fixes - expose rpm based fan info via hwmon - lots of clock and powergating fixes - SI register header cleanup and conversion to common format used by newer asics * 'drm-next-4.10' of git://people.freedesktop.org/~agd5f/linux: (54 commits) drm/amdgpu: drop is_display_hung from display funcs drm/amdgpu/uvd: reduce IB parsing overhead on UVD5+ (v2) drm/amdgpu/uvd: consolidate code for fetching addr from ctx drm/amdgpu: Disable DPM in virtualization drm/amdgpu: use AMDGPU_GEM_CREATE_VRAM_CLEARED for VM PD/PTs (v2) drm/amdgpu: improve AMDGPU_GEM_CREATE_VRAM_CLEARED handling (v2) drm/amdgpu: fix error handling in amdgpu_bo_create_restricted drm/amdgpu: fix amdgpu_fill_buffer (v2) drm/amdgpu: remove amdgpu_irq_get_delayed amdgpu: Wrap dev_err() calls on vm faults with printk_ratelimit() amdgpu: Use dev_err() over vanilla printk() in vm_decode_fault() drm/amd/amdgpu: port of DCE v6 to new headers (v3) drm/amdgpu: cleanup unused iterator members for sdma v2.4 drm/amdgpu: cleanup unused iterator members for sdma v3 drm/amdgpu:impl vgt_flush for VI(V5) drm/amdgpu: enable uvd mgcg for Fiji. drm/amdgpu: refine cz uvd clock gate logic. drm/amdgpu: change log level to KERN_INFO in ci_dpm.c drm/amdgpu: always un-gate UVD REGS path. drm/amdgpu/sdma: fix typo in packet setup ...
-
git://git.pengutronix.de/lst/linuxDave Airlie authored
- fix dma-buf export path to return correct SG table - trivially implement direct dma-buf mapping - allow DRAW_INSTANCED commands in validator - make the driver work on i.MX6SX, yielding a working 2D/3D stack together with Mareks MXS DRM driver * 'drm-etnaviv-next' of git://git.pengutronix.de/lst/linux: MAINTAINERS: add etnaviv mailinglist drm/etnaviv: move linear window on MC1.0 parts if necessary drm/etnaviv: don't invoke OOM killer from dump code drm/etnaviv: fix gem_prime_get_sg_table to return new SG table drm/etnaviv: Allow DRAW_INSTANCED commands drm/etnaviv: implement dma-buf mmap
-
- 05 Dec, 2016 12 commits
-
-
git://github.com/skeggsb/linuxDave Airlie authored
- BIT_PERF_PTRS uses 32-bit pointers to its subtables, we were parsing them as 16-bit, causing various issues on newer boards. - Support for MXM on GM20x and up. - More display-related fixes. * 'linux-4.10' of git://github.com/skeggsb/linux: drm/nouveau/mxm: warn more loudly on unsupported DCB version drm/nouveau/mxm: handle DCB 4.1 modification drm/nouveau/bios/mxm: handle digital connector table 1.1 drm/nouveau: Queue hpd_work on (runtime) resume drm/nouveau: Rename acpi_work to hpd_work drm/nouveau/kms/nv50: Fix atomic pageflip events. drm/nouveau/fb/ram/gp100-: fix memory detection where FBP_NUM != FBPA_NUM drm/nouveau/bios/volt: pointers are 32-bit drm/nouveau/bios/vmap: pointers are 32-bit drm/nouveau/bios/timing: pointers are 32-bit drm/nouveau/bios/therm: pointers are 32-bit drm/nouveau/bios/perf: pointers are 32-bit drm/nouveau/bios/iccsense: pointers are 32-bit drm/nouveau/bios/fan: pointers are 32-bit drm/nouveau/bios/cstep: pointers are 32-bit drm/nouveau/bios/boost: pointers are 32-bit
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Allows MXM DCB modification to be handled on GM20x and newer boards. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
I suspect the version bump is just to signify that the table now specifies pad macro/links instead of SOR/sublinks. For our usage of the table, just recognising the new version is enough. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Pan Bian authored
In function qxl_release_alloc(), when kmalloc() returns a NULL pointer, it returns value 0 and parameter *ret is uninitialized. 0 means no error to the callers of qxl_release_alloc(). The callers keep going and will try to reference the uninitialized variable. This patch fixes the bug, returning "-ENOMEM" when kmalloc() fails. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188911Signed-off-by: Pan Bian <bianpan2016@163.com> [seanpaul fixed up subject prefix] Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1480777902-7648-1-git-send-email-bianpan2016@163.com
-
Javier Martinez Canillas authored
Commit aeefb368 ("drm/exynos: gsc: add device tree support and remove usage of static mappings") made the DRM_EXYNOS_GSC Kconfig symbol to only be selectable if the exynos-gsc V4L2 driver isn't enabled, since both use the same HW IP block. But added the dependency as depends on !VIDEO_SAMSUNG_EXYNOS_GSC which is not correct since Kconfig expressions are not boolean but tristate. So it will only evaluate to 'n' if VIDEO_SAMSUNG_EXYNOS_GSC=y but will evaluate to 'm' if VIDEO_SAMSUNG_EXYNOS_GSC=m. This means that both the V4L2 and DRM drivers can be enabled if the former is enabled as a module, which isn't what we want since otherwise 2 drivers could attempt to use the hardware at the same time. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
-
Colin Ian King authored
Trivial fixes to spelling mistakes "precalser" to "prescaler" in dev_err messages Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
-
Shuah Khan authored
Fix exynos_drm_gem_create() error messages to include flags and size when flags and size are invalid. Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
-
Andrzej Hajda authored
Use core helpers to generate infoframes and generate vendor frame if necessary. Changelog: - changed 'ret >= 0' checks to '!ret' Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
-
Daniel Vetter authored
They're gone since 8a357d10 ("drm: Nerf DRM_CONTROL nodes"). Spotted while doing a full audit when revieng a similar patch from Nicolai for radeon. v2: Drink coffee first aka don't forget the unregister side. Cc: Dave Airlie <airlied@redhat.com> Fixes: 8a357d10 ("drm: Nerf DRM_CONTROL nodes") Cc: Nicolai Stange <nicstange@gmail.com> Acked-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161205072926.12546-1-daniel.vetter@ffwll.ch
-
Nicolai Stange authored
Since commit 8a357d10 ("drm: Nerf DRM_CONTROL nodes"), a struct drm_device's ->control member is always NULL. In the case of CONFIG_DEBUG_FS=y, radeon_debugfs_add_files() accesses ->control->debugfs_root though. This results in the following Oops: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 IP: radeon_debugfs_add_files+0x90/0x100 [radeon] PGD 0 Oops: 0000 [#1] SMP [...] Call Trace: ? work_on_cpu+0xb0/0xb0 radeon_fence_driver_init+0x120/0x150 [radeon] si_init+0x122/0xd50 [radeon] ? _raw_spin_unlock_irq+0x2c/0x40 ? device_pm_check_callbacks+0xb3/0xc0 radeon_device_init+0x958/0xda0 [radeon] radeon_driver_load_kms+0x9a/0x210 [radeon] drm_dev_register+0xa9/0xd0 [drm] drm_get_pci_dev+0x9c/0x1e0 [drm] radeon_pci_probe+0xb8/0xe0 [radeon] [...] Fix this by omitting the drm_debugfs_create_files() call for the control minor debugfs directory which is now non-existent anyway. Fixes: 8a357d10 ("drm: Nerf DRM_CONTROL nodes") Signed-off-by: Nicolai Stange <nicstange@gmail.com> Acked-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161203144700.2307-1-nicstange@gmail.com
-
Dave Airlie authored
Linux 4.9-rc8 Daniel requested this so we could apply some follow on fixes cleanly to -next.
-
- 04 Dec, 2016 2 commits
-
-
Linus Torvalds authored
-
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
Pull drm fixes from Dave Airlie: "A pretty small pull request: a couple of AMD powerxpress regression fixes and a power management fix, a couple of i915 fixes and one hdlcd fix, along with one core don't oops because of incorrect API usage fix" * tag 'drm-fixes-for-v4.9-rc8' of git://people.freedesktop.org/~airlied/linux: drm/i915: drop the struct_mutex when wedged or trying to reset drm/i915: Don't touch NULL sg on i915_gem_object_get_pages_gtt() error drm: Don't call drm_for_each_crtc with a non-KMS driver drm/radeon: fix check for port PM availability drm/amdgpu: fix check for port PM availability drm/amd/powerplay: initialize the soft_regs offset in struct smu7_hwmgr drm: hdlcd: Fix cleanup order
-
- 03 Dec, 2016 4 commits
-
-
Dave Airlie authored
Merge tag 'drm-intel-fixes-2016-12-01' of git://anongit.freedesktop.org/git/drm-intel into drm-fixes 2 intel fixes. * tag 'drm-intel-fixes-2016-12-01' of git://anongit.freedesktop.org/git/drm-intel: drm/i915: drop the struct_mutex when wedged or trying to reset drm/i915: Don't touch NULL sg on i915_gem_object_get_pages_gtt() error
-
Linus Torvalds authored
Merge more fixes from Andrew Morton: "2 fixes" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: mm, vmscan: add cond_resched() into shrink_node_memcg() mm: workingset: fix NULL ptr in count_shadow_nodes
-
Michal Hocko authored
Boris Zhmurov has reported RCU stalls during the kswapd reclaim: INFO: rcu_sched detected stalls on CPUs/tasks: 23-...: (22 ticks this GP) idle=92f/140000000000000/0 softirq=2638404/2638404 fqs=23 (detected by 4, t=6389 jiffies, g=786259, c=786258, q=42115) Task dump for CPU 23: kswapd1 R running task 0 148 2 0x00000008 Call Trace: shrink_node+0xd2/0x2f0 kswapd+0x2cb/0x6a0 mem_cgroup_shrink_node+0x160/0x160 kthread+0xbd/0xe0 __switch_to+0x1fa/0x5c0 ret_from_fork+0x1f/0x40 kthread_create_on_node+0x180/0x180 a closer code inspection has shown that we might indeed miss all the scheduling points in the reclaim path if no pages can be isolated from the LRU list. This is a pathological case but other reports from Donald Buczek have shown that we might indeed hit such a path: clusterd-989 [009] .... 118023.654491: mm_vmscan_direct_reclaim_end: nr_reclaimed=193 kswapd1-86 [001] dN.. 118023.987475: mm_vmscan_lru_isolate: isolate_mode=0 classzone=0 order=0 nr_requested=32 nr_scanned=4239830 nr_taken=0 file=1 kswapd1-86 [001] dN.. 118024.320968: mm_vmscan_lru_isolate: isolate_mode=0 classzone=0 order=0 nr_requested=32 nr_scanned=4239844 nr_taken=0 file=1 kswapd1-86 [001] dN.. 118024.654375: mm_vmscan_lru_isolate: isolate_mode=0 classzone=0 order=0 nr_requested=32 nr_scanned=4239858 nr_taken=0 file=1 kswapd1-86 [001] dN.. 118024.987036: mm_vmscan_lru_isolate: isolate_mode=0 classzone=0 order=0 nr_requested=32 nr_scanned=4239872 nr_taken=0 file=1 kswapd1-86 [001] dN.. 118025.319651: mm_vmscan_lru_isolate: isolate_mode=0 classzone=0 order=0 nr_requested=32 nr_scanned=4239886 nr_taken=0 file=1 kswapd1-86 [001] dN.. 118025.652248: mm_vmscan_lru_isolate: isolate_mode=0 classzone=0 order=0 nr_requested=32 nr_scanned=4239900 nr_taken=0 file=1 kswapd1-86 [001] dN.. 118025.984870: mm_vmscan_lru_isolate: isolate_mode=0 classzone=0 order=0 nr_requested=32 nr_scanned=4239914 nr_taken=0 file=1 [...] kswapd1-86 [001] dN.. 118084.274403: mm_vmscan_lru_isolate: isolate_mode=0 classzone=0 order=0 nr_requested=32 nr_scanned=4241133 nr_taken=0 file=1 this is minute long snapshot which didn't take a single page from the LRU. It is not entirely clear why only 1303 pages have been scanned during that time (maybe there was a heavy IRQ activity interfering). In any case it looks like we can really hit long periods without scheduling on non preemptive kernels so an explicit cond_resched() in shrink_node_memcg which is independent on the reclaim operation is due. Link: http://lkml.kernel.org/r/20161202095841.16648-1-mhocko@kernel.orgSigned-off-by: Michal Hocko <mhocko@suse.com> Reported-by: Boris Zhmurov <bb@kernelpanic.ru> Tested-by: Boris Zhmurov <bb@kernelpanic.ru> Reported-by: Donald Buczek <buczek@molgen.mpg.de> Reported-by: "Christopher S. Aker" <caker@theshore.net> Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Michal Hocko authored
Commit 0a6b76dd ("mm: workingset: make shadow node shrinker memcg aware") has made the workingset shadow nodes shrinker memcg aware. The implementation is not correct though because memcg_kmem_enabled() might become true while we are doing a global reclaim when the sc->memcg might be NULL which is exactly what Marek has seen: BUG: unable to handle kernel NULL pointer dereference at 0000000000000400 IP: [<ffffffff8122d520>] mem_cgroup_node_nr_lru_pages+0x20/0x40 PGD 0 Oops: 0000 [#1] SMP CPU: 0 PID: 60 Comm: kswapd0 Tainted: G O 4.8.10-12.pvops.qubes.x86_64 #1 task: ffff880011863b00 task.stack: ffff880011868000 RIP: mem_cgroup_node_nr_lru_pages+0x20/0x40 RSP: e02b:ffff88001186bc70 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88001186bd20 RCX: 0000000000000002 RDX: 000000000000000c RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88001186bc70 R08: 28f5c28f5c28f5c3 R09: 0000000000000000 R10: 0000000000006c34 R11: 0000000000000333 R12: 00000000000001f6 R13: ffffffff81c6f6a0 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880013c00000(0000) knlGS:ffff880013d00000 CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000400 CR3: 00000000122f2000 CR4: 0000000000042660 Call Trace: count_shadow_nodes+0x9a/0xa0 shrink_slab.part.42+0x119/0x3e0 shrink_node+0x22c/0x320 kswapd+0x32c/0x700 kthread+0xd8/0xf0 ret_from_fork+0x1f/0x40 Code: 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 3b 35 dd eb b1 00 55 48 89 e5 73 2c 89 d2 31 c9 31 c0 4c 63 ce 48 0f a3 ca 73 13 <4a> 8b b4 cf 00 04 00 00 41 89 c8 4a 03 84 c6 80 00 00 00 83 c1 RIP mem_cgroup_node_nr_lru_pages+0x20/0x40 RSP <ffff88001186bc70> CR2: 0000000000000400 ---[ end trace 100494b9edbdfc4d ]--- This patch fixes the issue by checking sc->memcg rather than memcg_kmem_enabled() which is sufficient because shrink_slab makes sure that only memcg aware shrinkers will get non-NULL memcgs and only if memcg_kmem_enabled is true. Fixes: 0a6b76dd ("mm: workingset: make shadow node shrinker memcg aware") Link: http://lkml.kernel.org/r/20161201132156.21450-1-mhocko@kernel.orgSigned-off-by: Michal Hocko <mhocko@suse.com> Reported-by: Marek Marczykowski-Górecki <marmarek@mimuw.edu.pl> Tested-by: Marek Marczykowski-Górecki <marmarek@mimuw.edu.pl> Acked-by: Vladimir Davydov <vdavydov.dev@gmail.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Acked-by: Balbir Singh <bsingharora@gmail.com> Cc: <stable@vger.kernel.org> [4.6+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
- 02 Dec, 2016 1 commit
-
-
Nicolas Pitre authored
When building a specific target such as bzImage, modules aren't normally built. However if CONFIG_TRIM_UNUSED_KSYMS is enabled, no built modules means none of the exported symbols are used and therefore they will all be trimmed away from the final kernel. A subsequent "make modules" will fail because modpost cannot find the needed symbols for those modules in the kernel binary. Let's make sure modules are also built whenever CONFIG_TRIM_UNUSED_KSYMS is enabled and that the kernel binary is properly rebuilt accordingly. Signed-off-by: Nicolas Pitre <nico@linaro.org> Tested-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-