- 27 Jan, 2017 12 commits
-
-
Kees Cook authored
Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Nils Wallménius authored
This is a left over from radeon, amdgpu doesn't support any non-atombios parts and amdgpu_device_init would bail if the check for atombios failed anyway. Reviewed-by:
Edward O'Callaghan <funfunctor@folklore1984.net> Signed-off-by:
Nils Wallménius <nils.wallmenius@gmail.com> Signed-off-by:
-
Tom St Denis authored
Support wider address spaces, make it 32-bit so we don't have to revisit this for a while. Signed-off-by:
Tom St Denis <tom.stdenis@amd.com> Reviewed-by:
Chunming Zhou <david1.zhou@amd.com> Signed-off-by:
-
Arindam Nath authored
Change History -------------- v4: Changes suggested by Emil, Christian - return -ENODATA for asics with unlimited sessions v3: changes suggested by Christian - Add a check for UVD IP block using AMDGPU_HW_IP_UVD query type. - Add a check for asic_type to be less than CHIP_POLARIS10 since starting Polaris, we support unlimited UVD instances. - Add kerneldoc style comment for amdgpu_uvd_used_handles(). v2: as suggested by Christian - Add a new query AMDGPU_INFO_NUM_HANDLES - Create a helper function to return the number of currently used UVD handles. - Modify the logic to count the number of used UVD handles since handles can be freed in non-linear fashion. v1: - User might want to query the maximum number of UVD instances supported by firmware. In addition to that, if there are multiple applications using UVD handles at the same time, he might also want to query the currently used number of handles. For this we add two variables max_handles and used_handles inside drm_amdgpu_info_hw_ip. So now an application (or libdrm) can use AMDGPU_INFO IOCTL with AMDGPU_INFO_HW_IP_INFO query type to get these values. Signed-off-by:
Arindam Nath <arindam.nath@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Rex Zhu authored
Signed-off-by:
Rex Zhu <Rex.Zhu@amd.com> Reviewed-by:
-
Tom St Denis authored
Where possible replace numeric constants in the table with their register names. Compile tested + executed on a Tahiti. Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
Huang Rui authored
Signed-off-by:
Huang Rui <ray.huang@amd.com> Acked-by:
-
Chris Wilson authored
drivers/gpu/drm/sti/sti_plane.c:76:33: error: ‘struct drm_framebuffer’ has no member named ‘pixel_format’; did you mean ‘format’? I didn't look to hard at the casting to a char * and just did a mechanical transformation of s/pixel_format/format->format/ as given in commit 438b74a5 ("drm: Nuke fb->pixel_format"). Fixes: 438b74a5 ("drm: Nuke fb->pixel_format") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Acked-by:
Vincent Abriou <vincent.abriou@st.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
git://anongit.freedesktop.org/git/drm-miscDave Airlie authored
- cleanups&fixes for dw-hdmi bride driver (Laurent) - updates for adv bridge driver (John Stultz) for nexus - drm_crtc_from_index helper rollout (Shawn Guo) - removing drm_framebuffer_unregister_private from drivers&core - target_vblank (Andrey Grodzovsky) - misc tiny stuff * tag 'drm-misc-next-2017-01-23' of git://anongit.freedesktop.org/git/drm-misc: (49 commits) drm: qxl: Open code teardown function for qxl drm: qxl: Open code probing sequence for qxl drm/bridge: adv7511: Re-write the i2c address before EDID probing drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be reused internally drm/bridge: adv7511: Enable HPD interrupts to support hotplug and improve monitor detection drm/bridge: adv7511: Switch to using drm_kms_helper_hotplug_event() drm/bridge: adv7511: Use work_struct to defer hotplug handing to out of irq context drm: vc4: use crtc helper drm_crtc_from_index() drm: tegra: use crtc helper drm_crtc_from_index() drm: nouveau: use crtc helper drm_crtc_from_index() drm: mediatek: use crtc helper drm_crtc_from_index() drm: kirin: use crtc helper drm_crtc_from_index() drm: exynos: use crtc helper drm_crtc_from_index() dt-bindings: display: dw-hdmi: Clean up DT bindings documentation drm: bridge: dw-hdmi: Assert SVSRET before resetting the PHY drm: bridge: dw-hdmi: Fix the name of the PHY reset macros drm: bridge: dw-hdmi: Define and use macros for PHY register addresses drm: bridge: dw-hdmi: Detect PHY type at runtime drm: bridge: dw-hdmi: Handle overflow workaround based on device version ...
-
git://anongit.freedesktop.org/git/drm-intelDave Airlie authored
Final block of feature work for 4.11: - gen8 pd cleanup from Matthew Auld - more cleanups for view/vma (Chris) - dmc support on glk (Anusha Srivatsa) - use core crc api (Tomue) - track wedged requests using fence.error (Chris) - lots of psr fixes (Nagaraju, Vathsala) - dp mst support, acked for merging through drm-intel by Takashi (Libin) - huc loading support, including uapi for libva to use it (Anusha Srivatsa) * tag 'drm-intel-next-2017-01-23' of git://anongit.freedesktop.org/git/drm-intel: (111 commits) drm/i915: Update DRIVER_DATE to 20170123 drm/i915: reinstate call to trace_i915_vma_bind drm/i915: Assert that created vma has a whole number of pages drm/i915: Assert the drm_mm_node is allocated when on the VM lists drm/i915: Treat an error from i915_vma_instance() as unlikely drm/i915: Reject vma creation larger than address space drm/i915: Use common LRU inactive vma bumping for unpin_from_display drm/i915: Do an unlocked wait before set-cache-level ioctl drm/i915/huc: Assert that HuC vma is placed in GuC accessible range drm/i915/huc: Avoid attempting to authenticate non-existent fw drm/i915: Set adjustment to zero on Up/Down interrupts if freq is already max/min drm/i915: Remove the double handling of 'flags from intel_mode_from_pipe_config() drm/i915: Remove crtc->config usage from intel_modeset_readout_hw_state() drm/i915: Release temporary load-detect state upon switching drm/i915: Remove i915_gem_object_to_ggtt() drm/i915: Remove i915_vma_create from VMA API drm/i915: Add a check that the VMA instance we lookup matches the request drm/i915: Rename some warts in the VMA API drm/i915: Track pinned vma in intel_plane_state drm/i915/get_params: Add HuC status to getparams ...
-
Dave Airlie authored
This reverts commit 54a07c7b, and reinstates the original. [airlied: this might be a bad plan for git]. commit 3846fd9b Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jan 11 10:01:17 2017 +0100 drm/probe-helpers: Drop locking from poll_enable It was only needed to protect the connector_list walking, see commit 8c4ccc4a Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jul 9 23:44:26 2015 +0200 drm/probe-helper: Grab mode_config.mutex in poll_init/enable Unfortunately the commit message of that patch fails to mention that the new locking check was for the connector_list. But that requirement disappeared in commit c36a3254 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Dec 15 16:58:43 2016 +0100 drm: Convert all helpers to drm_connector_list_iter and so we can drop this again. This fixes a locking inversion on nouveau, where the rpm code needs to re-enable. But in other places the rpm_get() calls are nested within the big modeset locks. While at it, also improve the kerneldoc for these two functions a notch. v2: Update the kerneldoc even more to explain that these functions can't be called concurrently, or bad things happen (Chris).
-
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linuxDave Airlie authored
Backmerge Linus master to get the connector locking revert. * 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux: (645 commits) sysctl: fix proc_doulongvec_ms_jiffies_minmax() Revert "drm/probe-helpers: Drop locking from poll_enable" MAINTAINERS: add Dan Streetman to zbud maintainers MAINTAINERS: add Dan Streetman to zswap maintainers mm: do not export ioremap_page_range symbol for external module mn10300: fix build error of missing fpu_save() romfs: use different way to generate fsid for BLOCK or MTD frv: add missing atomic64 operations mm, page_alloc: fix premature OOM when racing with cpuset mems update mm, page_alloc: move cpuset seqcount checking to slowpath mm, page_alloc: fix fast-path race with cpuset update or removal mm, page_alloc: fix check for NULL preferred_zone kernel/panic.c: add missing \n fbdev: color map copying bounds checking frv: add atomic64_add_unless() mm/mempolicy.c: do not put mempolicy before using its nodemask radix-tree: fix private list warnings Documentation/filesystems/proc.txt: add VmPin mm, memcg: do not retry precharge charges proc: add a schedule point in proc_pid_readdir() ...
-
- 26 Jan, 2017 3 commits
-
-
Eric Dumazet authored
We perform the conversion between kernel jiffies and ms only when exporting kernel value to user space. We need to do the opposite operation when value is written by user. Only matters when HZ != 1000 Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: stable@vger.kernel.org Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrlLinus Torvalds authored
Pull pin control fixes from Linus Walleij: "A bunch of pin control fixes for v4.10 that didn't get sent off until now, sorry for the delay. It's only driver fixes: - A bunch of fixes to the Intel drivers: broxton, baytrail. Bugs related to register offsets, IRQ, debounce functionality. - Fix a conflict amongst UART settings on the meson. - Fix the ethernet setting on the Uniphier. - A compilation warning squelched" * tag 'pinctrl-v4.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: uniphier: fix Ethernet (RMII) pin-mux setting for LD20 pinctrl: meson: fix uart_ao_b for GXBB and GXL/GXM pinctrl: amd: avoid maybe-uninitalized warning pinctrl: baytrail: Do not add all GPIOs to IRQ domain pinctrl: baytrail: Rectify debounce support pinctrl: intel: Set pin direction properly pinctrl: broxton: Use correct PADCFGLOCK offset -
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
Pull drm revert from Dave Airlie: "Revert one patch missing some prereqs. One of the connector fixes was missing some prereqs, we have an alternate driver fix that should work that I'll send tomorrow. Today is a holiday here so quickly smashing this out" Daniel Vetter explains: "I pushed a locking change to fix a nouveau rpm issue to -fixes that needed the connector_list rework. And that's only in -next, but I missed that. Dave has the revert in a pull, and he'll follow-up with the hack nouveau patch for 4.10, and then we'll reapply the proper fix again for -next and revert the hacks. A bit a mess, but should be sorted soon" * tag 'drm-fixes-for-v4.10-rc6-revert-one' of git://people.freedesktop.org/~airlied/linux: Revert "drm/probe-helpers: Drop locking from poll_enable"
-
- 25 Jan, 2017 25 commits
-
-
Dave Airlie authored
This reverts commit 3846fd9b. There were some precursor commits missing for this around connector locking, we should probably merge Lyude's nouveau avoid the problem patch.
-
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds authored
Pull virtio/vhost fixes from Michael Tsirkin: - ARM DMA fixes - vhost vsock bugfix * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: vring: Force use of DMA API for ARM-based systems with legacy devices virtio_mmio: Set DMA masks appropriately vhost/vsock: handle vhost_vq_init_access() error
-
Linus Torvalds authored
Merge fixes from Andrew Morton: "26 fixes" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: (26 commits) MAINTAINERS: add Dan Streetman to zbud maintainers MAINTAINERS: add Dan Streetman to zswap maintainers mm: do not export ioremap_page_range symbol for external module mn10300: fix build error of missing fpu_save() romfs: use different way to generate fsid for BLOCK or MTD frv: add missing atomic64 operations mm, page_alloc: fix premature OOM when racing with cpuset mems update mm, page_alloc: move cpuset seqcount checking to slowpath mm, page_alloc: fix fast-path race with cpuset update or removal mm, page_alloc: fix check for NULL preferred_zone kernel/panic.c: add missing \n fbdev: color map copying bounds checking frv: add atomic64_add_unless() mm/mempolicy.c: do not put mempolicy before using its nodemask radix-tree: fix private list warnings Documentation/filesystems/proc.txt: add VmPin mm, memcg: do not retry precharge charges proc: add a schedule point in proc_pid_readdir() mm: alloc_contig: re-allow CMA to compact FS pages mm/slub.c: trace free objects at KERN_INFO ...
-
Dan Streetman authored
Add myself as zbud maintainer. Link: http://lkml.kernel.org/r/20170124221705.26523-1-ddstreet@ieee.orgSigned-off-by:
Dan Streetman <ddstreet@ieee.org> Cc: Seth Jennings <sjenning@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Dan Streetman authored
Add myself as zswap maintainer. Link: http://lkml.kernel.org/r/20170124212200.19052-1-ddstreet@ieee.orgSigned-off-by:
Seth Jennings <sjenning@redhat.com> Signed-off-by:
-
zhong jiang authored
Recently, I've found cases in which ioremap_page_range was used incorrectly, in external modules, leading to crashes. This can be partly attributed to the fact that ioremap_page_range is lower-level, with fewer protections, as compared to the other functions that an external module would typically call. Those include: ioremap_cache ioremap_nocache ioremap_prot ioremap_uc ioremap_wc ioremap_wt ...each of which wraps __ioremap_caller, which in turn provides a safer way to achieve the mapping. Therefore, stop EXPORT-ing ioremap_page_range. Link: http://lkml.kernel.org/r/1485173220-29010-1-git-send-email-zhongjiang@huawei.comSigned-off-by:zhong jiang <zhongjiang@huawei.com> Reviewed-by:
John Hubbard <jhubbard@nvidia.com> Suggested-by:
Michal Hocko <mhocko@suse.com> Signed-off-by:
-
Randy Dunlap authored
When CONFIG_FPU is not enabled on arch/mn10300, <asm/switch_to.h> causes a build error with a call to fpu_save(): kernel/built-in.o: In function `.L410': core.c:(.sched.text+0x28a): undefined reference to `fpu_save' Fix this by including <asm/fpu.h> in <asm/switch_to.h> so that an empty static inline fpu_save() is defined. Link: http://lkml.kernel.org/r/dc421c4f-4842-4429-1b99-92865c2f24b6@infradead.orgSigned-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
kbuild test robot <fengguang.wu@intel.com> Reviewed-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Coly Li authored
Commit 8a59f5d2 ("fs/romfs: return f_fsid for statfs(2)") generates a 64bit id from sb->s_bdev->bd_dev. This is only correct when romfs is defined with CONFIG_ROMFS_ON_BLOCK. If romfs is only defined with CONFIG_ROMFS_ON_MTD, sb->s_bdev is NULL, referencing sb->s_bdev->bd_dev will triger an oops. Richard Weinberger points out that when CONFIG_ROMFS_BACKED_BY_BOTH=y, both CONFIG_ROMFS_ON_BLOCK and CONFIG_ROMFS_ON_MTD are defined. Therefore when calling huge_encode_dev() to generate a 64bit id, I use the follow order to choose parameter, - CONFIG_ROMFS_ON_BLOCK defined use sb->s_bdev->bd_dev - CONFIG_ROMFS_ON_BLOCK undefined and CONFIG_ROMFS_ON_MTD defined use sb->s_dev when, - both CONFIG_ROMFS_ON_BLOCK and CONFIG_ROMFS_ON_MTD undefined leave id as 0 When CONFIG_ROMFS_ON_MTD is defined and sb->s_mtd is not NULL, sb->s_dev is set to a device ID generated by MTD_BLOCK_MAJOR and mtd index, otherwise sb->s_dev is 0. This is a try-best effort to generate a uniq file system ID, if all the above conditions are not meet, f_fsid of this romfs instance will be 0. Generally only one romfs can be built on single MTD block device, this method is enough to identify multiple romfs instances in a computer. Link: http://lkml.kernel.org/r/1482928596-115155-1-git-send-email-colyli@suse.deSigned-off-by:
Coly Li <colyli@suse.de> Reported-by:
Nong Li <nongli1031@gmail.com> Tested-by:
-
Sudip Mukherjee authored
Some more atomic64 operations were missing and as a result frv allmodconfig was failing. Add the missing operations. Link: http://lkml.kernel.org/r/1485193844-12850-1-git-send-email-sudip.mukherjee@codethink.co.ukSigned-off-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Cc: David Howells <dhowells@redhat.com> Signed-off-by:
-
Vlastimil Babka authored
Ganapatrao Kulkarni reported that the LTP test cpuset01 in stress mode triggers OOM killer in few seconds, despite lots of free memory. The test attempts to repeatedly fault in memory in one process in a cpuset, while changing allowed nodes of the cpuset between 0 and 1 in another process. The problem comes from insufficient protection against cpuset changes, which can cause get_page_from_freelist() to consider all zones as non-eligible due to nodemask and/or current->mems_allowed. This was masked in the past by sufficient retries, but since commit 682a3385 ("mm, page_alloc: inline the fast path of the zonelist iterator") we fix the preferred_zoneref once, and don't iterate over the whole zonelist in further attempts, thus the only eligible zones might be placed in the zonelist before our starting point and we always miss them. A previous patch fixed this problem for current->mems_allowed. However, cpuset changes also update the task's mempolicy nodemask. The fix has two parts. We have to repeat the preferred_zoneref search when we detect cpuset update by way of seqcount, and we have to check the seqcount before considering OOM. [akpm@linux-foundation.org: fix typo in comment] Link: http://lkml.kernel.org/r/20170120103843.24587-5-vbabka@suse.cz Fixes: c33d6c06 ("mm, page_alloc: avoid looking up the first zone in a zonelist twice") Signed-off-by:
Vlastimil Babka <vbabka@suse.cz> Reported-by:
Ganapatrao Kulkarni <gpkulkarni@gmail.com> Acked-by:
Mel Gorman <mgorman@techsingularity.net> Acked-by:
Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Michal Hocko <mhocko@suse.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Vlastimil Babka authored
This is a preparation for the following patch to make review simpler. While the primary motivation is a bug fix, this also simplifies the fast path, although the moved code is only enabled when cpusets are in use. Link: http://lkml.kernel.org/r/20170120103843.24587-4-vbabka@suse.czSigned-off-by:
-
Vlastimil Babka authored
Ganapatrao Kulkarni reported that the LTP test cpuset01 in stress mode triggers OOM killer in few seconds, despite lots of free memory. The test attempts to repeatedly fault in memory in one process in a cpuset, while changing allowed nodes of the cpuset between 0 and 1 in another process. One possible cause is that in the fast path we find the preferred zoneref according to current mems_allowed, so that it points to the middle of the zonelist, skipping e.g. zones of node 1 completely. If the mems_allowed is updated to contain only node 1, we never reach it in the zonelist, and trigger OOM before checking the cpuset_mems_cookie. This patch fixes the particular case by redoing the preferred zoneref search if we switch back to the original nodemask. The condition is also slightly changed so that when the last non-root cpuset is removed, we don't miss it. Note that this is not a full fix, and more patches will follow. Link: http://lkml.kernel.org/r/20170120103843.24587-3-vbabka@suse.cz Fixes: 682a3385 ("mm, page_alloc: inline the fast path of the zonelist iterator") Signed-off-by:
-
Vlastimil Babka authored
Patch series "fix premature OOM regression in 4.7+ due to cpuset races". This is v2 of my attempt to fix the recent report based on LTP cpuset stress test [1]. The intention is to go to stable 4.9 LTSS with this, as triggering repeated OOMs is not nice. That's why the patches try to be not too intrusive. Unfortunately why investigating I found that modifying the testcase to use per-VMA policies instead of per-task policies will bring the OOM's back, but that seems to be much older and harder to fix problem. I have posted a RFC [2] but I believe that fixing the recent regressions has a higher priority. Longer-term we might try to think how to fix the cpuset mess in a better and less error prone way. I was for example very surprised to learn, that cpuset updates change not only task->mems_allowed, but also nodemask of mempolicies. Until now I expected the parameter to alloc_pages_nodemask() to be stable. I wonder why do we then treat cpusets specially in get_page_from_freelist() and distinguish HARDWALL etc, when there's unconditional intersection between mempolicy and cpuset. I would expect the nodemask adjustment for saving overhead in g_p_f(), but that clearly doesn't happen in the current form. So we have both crazy complexity and overhead, AFAICS. [1] https://lkml.kernel.org/r/CAFpQJXUq-JuEP=QPidy4p_=FN0rkH5Z-kfB4qBvsf6jMS87Edg@mail.gmail.com [2] https://lkml.kernel.org/r/7c459f26-13a6-a817-e508-b65b903a8378@suse.cz This patch (of 4): Since commit c33d6c06 ("mm, page_alloc: avoid looking up the first zone in a zonelist twice") we have a wrong check for NULL preferred_zone, which can theoretically happen due to concurrent cpuset modification. We check the zoneref pointer which is never NULL and we should check the zone pointer. Also document this in first_zones_zonelist() comment per Michal Hocko. Fixes: c33d6c06 ("mm, page_alloc: avoid looking up the first zone in a zonelist twice") Link: http://lkml.kernel.org/r/20170120103843.24587-2-vbabka@suse.czSigned-off-by:
-
Jiri Slaby authored
When a system panics, the "Rebooting in X seconds.." message is never printed because it lacks a new line. Fix it. Link: http://lkml.kernel.org/r/20170119114751.2724-1-jslaby@suse.czSigned-off-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
Kees Cook authored
Copying color maps to userspace doesn't check the value of to->start, which will cause kernel heap buffer OOB read due to signedness wraps. CVE-2016-8405 Link: http://lkml.kernel.org/r/20170105224249.GA50925@beast Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Sudip Mukherjee authored
The build of frv allmodconfig was failing with the error: lib/atomic64_test.c:209:9: error: implicit declaration of function 'atomic64_add_unless' All the atomic64 operations were defined in frv, but atomic64_add_unless() was not done. Implement atomic64_add_unless() as done in other arches. Link: http://lkml.kernel.org/r/1484781236-6698-1-git-send-email-sudipm.mukherjee@gmail.comSigned-off-by:
-
Vlastimil Babka authored
Since commit be97a41b ("mm/mempolicy.c: merge alloc_hugepage_vma to alloc_pages_vma") alloc_pages_vma() can potentially free a mempolicy by mpol_cond_put() before accessing the embedded nodemask by __alloc_pages_nodemask(). The commit log says it's so "we can use a single exit path within the function" but that's clearly wrong. We can still do that when doing mpol_cond_put() after the allocation attempt. Make sure the mempolicy is not freed prematurely, otherwise __alloc_pages_nodemask() can end up using a bogus nodemask, which could lead e.g. to premature OOM. Fixes: be97a41b ("mm/mempolicy.c: merge alloc_hugepage_vma to alloc_pages_vma") Link: http://lkml.kernel.org/r/20170118141124.8345-1-vbabka@suse.czSigned-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by:
David Rientjes <rientjes@google.com> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: <stable@vger.kernel.org> [4.0+] Signed-off-by:
-
Matthew Wilcox authored
The newly introduced warning in radix_tree_free_nodes() was testing the wrong variable; it should have been 'old' instead of 'node'. Fixes: ea07b862 ("mm: workingset: fix use-after-free in shadow node shrinker") Link: http://lkml.kernel.org/r/20170118163746.GA32495@cmpxchg.orgSigned-off-by:
Matthew Wilcox <mawilcox@microsoft.com> Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Signed-off-by:
-
Fabian Frederick authored
Commit bc3e53f6 ("mm: distinguish between mlocked and pinned pages") added VmPin in /proc/<pid>/status. Report that in Documentation/filesystems/proc.txt Also move Umask after Name to keep correct order. Link: http://lkml.kernel.org/r/20170114201219.30387-1-fabf@skynet.beSigned-off-by:
Fabian Frederick <fabf@skynet.be> Cc: Christoph Lameter <cl@linux.com> Signed-off-by:
-
David Rientjes authored
When memory.move_charge_at_immigrate is enabled and precharges are depleted during move, mem_cgroup_move_charge_pte_range() will attempt to increase the size of the precharge. Prevent precharges from ever looping by setting __GFP_NORETRY. This was probably the intention of the GFP_KERNEL & ~__GFP_NORETRY, which is pointless as written. Fixes: 0029e19e ("mm: memcontrol: remove explicit OOM parameter in charge path") Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1701130208510.69402@chino.kir.corp.google.comSigned-off-by:
-
Eric Dumazet authored
We have seen proc_pid_readdir() invocations holding cpu for more than 50 ms. Add a cond_resched() to be gentle with other tasks. [akpm@linux-foundation.org: coding style fix] Link: http://lkml.kernel.org/r/1484238380.15816.42.camel@edumazet-glaptop3.roam.corp.google.comSigned-off-by:
-
Lucas Stach authored
Commit 73e64c51 ("mm, compaction: allow compaction for GFP_NOFS requests") changed compation to skip FS pages if not explicitly allowed to touch them, but missed to update the CMA compact_control. This leads to a very high isolation failure rate, crippling performance of CMA even on a lightly loaded system. Re-allow CMA to compact FS pages by setting the correct GFP flags, restoring CMA behavior and performance to the kernel 4.9 level. Fixes: 73e64c51 (mm, compaction: allow compaction for GFP_NOFS requests) Link: http://lkml.kernel.org/r/20170113115155.24335-1-l.stach@pengutronix.deSigned-off-by:
Lucas Stach <l.stach@pengutronix.de> Acked-by:
-
Daniel Thompson authored
Currently when trace is enabled (e.g. slub_debug=T,kmalloc-128 ) the trace messages are mostly output at KERN_INFO. However the trace code also calls print_section() to hexdump the head of a free object. This is hard coded to use KERN_ERR, meaning the console is deluged with trace messages even if we've asked for quiet. Fix this the obvious way but adding a level parameter to print_section(), allowing calls from the trace code to use the same trace level as other trace messages. Link: http://lkml.kernel.org/r/20170113154850.518-1-daniel.thompson@linaro.orgSigned-off-by:
Daniel Thompson <daniel.thompson@linaro.org> Acked-by:
Christoph Lameter <cl@linux.com> Acked-by:
-
Andrea Arcangeli authored
With >=32 CPUs the userfaultfd selftest triggered a graceful but unexpected SIGBUS because VM_FAULT_RETRY was returned by handle_userfault() despite the UFFDIO_COPY wasn't completed. This seems caused by rwsem waking the thread blocked in handle_userfault() and we can't run up_read() before the wait_event sequence is complete. Keeping the wait_even sequence identical to the first one, would require running userfaultfd_must_wait() again to know if the loop should be repeated, and it would also require retaking the rwsem and revalidating the whole vma status. It seems simpler to wait the targeted wakeup so that if false wakeups materialize we still wait for our specific wakeup event, unless of course there are signals or the uffd was released. Debug code collecting the stack trace of the wakeup showed this: $ ./userfaultfd 100 99999 nr_pages: 25600, nr_pages_per_cpu: 800 bounces: 99998, mode: racing ver poll, userfaults: 32 35 90 232 30 138 69 82 34 30 139 40 40 31 20 19 43 13 15 28 27 38 21 43 56 22 1 17 31 8 4 2 bounces: 99997, mode: rnd ver poll, Bus error (core dumped) save_stack_trace+0x2b/0x50 try_to_wake_up+0x2a6/0x580 wake_up_q+0x32/0x70 rwsem_wake+0xe0/0x120 call_rwsem_wake+0x1b/0x30 up_write+0x3b/0x40 vm_mmap_pgoff+0x9c/0xc0 SyS_mmap_pgoff+0x1a9/0x240 SyS_mmap+0x22/0x30 entry_SYSCALL_64_fastpath+0x1f/0xbd 0xffffffffffffffff FAULT_FLAG_ALLOW_RETRY missing 70 CPU: 24 PID: 1054 Comm: userfaultfd Tainted: G W 4.8.0+ #30 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 Call Trace: dump_stack+0xb8/0x112 handle_userfault+0x572/0x650 handle_mm_fault+0x12cb/0x1520 __do_page_fault+0x175/0x500 trace_do_page_fault+0x61/0x270 do_async_page_fault+0x19/0x90 async_page_fault+0x25/0x30 This always happens when the main userfault selftest thread is running clone() while glibc runs either mprotect or mmap (both taking mmap_sem down_write()) to allocate the thread stack of the background threads, while locking/userfault threads already run at full throttle and are susceptible to false wakeups that may cause handle_userfault() to return before than expected (which results in graceful SIGBUS at the next attempt). This was reproduced only with >=32 CPUs because the loop to start the thread where clone() is too quick with fewer CPUs, while with 32 CPUs there's already significant activity on ~32 locking and userfault threads when the last background threads are started with clone(). This >=32 CPUs SMP race condition is likely reproducible only with the selftest because of the much heavier userfault load it generates if compared to real apps. We'll have to allow "one more" VM_FAULT_RETRY for the WP support and a patch floating around that provides it also hidden this problem but in reality only is successfully at hiding the problem. False wakeups could still happen again the second time handle_userfault() is invoked, even if it's a so rare race condition that getting false wakeups twice in a row is impossible to reproduce. This full fix is needed for correctness, the only alternative would be to allow VM_FAULT_RETRY to be returned infinitely. With this fix the WP support can stick to a strict "one more" VM_FAULT_RETRY logic (no need of returning it infinite times to avoid the SIGBUS). Link: http://lkml.kernel.org/r/20170111005535.13832-2-aarcange@redhat.comSigned-off-by:Andrea Arcangeli <aarcange@redhat.com> Reported-by:
Shubham Kumar Sharma <shubham.kumar.sharma@oracle.com> Tested-by:
Mike Kravetz <mike.kravetz@oracle.com> Acked-by:
-
Arnd Bergmann authored
gcc-7 produces a harmless false-postive warning about a possible NULL pointer access: drivers/memstick/core/memstick.c: In function 'h_memstick_read_dev_id': drivers/memstick/core/memstick.c:309:3: error: argument 2 null where non-null expected [-Werror=nonnull] memcpy(mrq->data, buf, mrq->data_len); This can't happen because the caller sets the command to 'MS_TPC_READ_REG', which causes the data direction to be 'READ' and the NULL pointer not accessed. As a simple workaround for the warning, we can pass a pointer to the data that we actually want to read into. This is not needed here, but also harmless, and lets the compiler know that the access is ok. Link: http://lkml.kernel.org/r/20170111144143.548867-1-arnd@arndb.deSigned-off-by:Arnd Bergmann <arnd@arndb.de> Cc: Alex Dubov <oakad@yahoo.com> Signed-off-by:
-
