aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-01-26drm/edid: Set AVI infoframe Q even when QS=0Ville Syrjälä4-4/+13
HDMI 2.0 recommends that we set the Q bits in the AVI infoframe even when the sink does not support quantization range selection (QS=0). According to CEA-861 we can do that as long as the Q we send matches the default quantization range for the mode. Previously I think I had misread the spec as saying that you can't send a non-zero Q at all when QS=0. But that's not what the spec actually says. v2: Fix typo in commit message (Jani) Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]> Acked-by: Eric Anholt <[email protected]>
2017-01-26drm/edid: Introduce drm_hdmi_avi_infoframe_quant_range()Ville Syrjälä4-17/+40
Pull the logic to populate the quantization range information in the AVI infoframe into a small helper. We'll be adding a bit more logic to it, and having it in a central place seems like a good idea since it's based on the CEA-861 spec. Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]> Acked-by: Eric Anholt <[email protected]>
2017-01-26drm/edid: Introduce drm_default_rgb_quant_range()Ville Syrjälä5-3/+29
Make the code selecting the RGB quantization range a little less magicy by wrapping it up in a small helper. v2: s/adjusted_mode/mode in vc4 to make it actually compile v3: Add a comment proposed by Eric Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]> Acked-by: Eric Anholt <[email protected]>
2017-01-26drm/edid: Have drm_edid.h include hdmi.hVille Syrjälä1-2/+1
drm_edid.h depends on hdmi.h on account of enum hdmi_picture_aspect, so let's just include hdmi.h and drop some useless struct declarations. Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]> Acked-by: Eric Anholt <[email protected]>
2017-01-26drm: Silence the compiler for drm_mode_get_hv_timings()Chris Wilson1-2/+1
Since moving drm_crtc_get_hv_timings() into drm_modes.c, the compiler has been able to get smarter and spots that drm_mode_copy() is trying to preserve garbage from the stack. Fixes: 196cd5d3758c ("drm: s/drm_crtc_get_hv_timings/drm_mode_get_hv_timings/") Signed-off-by: Chris Wilson <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Alex Deucher <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-26drm: mali-dp: fix stride setting for multi-plane formatsMihail Atanassov4-10/+50
Hardware has multiple (2 or 3, depending on model) stride registers per layer; add a function that correctly takes that into account. On hardware that only has 2 stride registers, ensure that 3-plane (YUV) content has identical strides for both chroma planes. Signed-off-by: Mihail Atanassov <[email protected]> [Removed smart layer stride setup, comment and commit message clarifications] Signed-off-by: Liviu Dudau <[email protected]>
2017-01-26drm: mali-dp: Add plane offset to the plane's physical start address registerLiviu Dudau1-0/+1
Add the fb->offset[] value to the plane's physical start address registe. Without that, packed formats are rendered incorrectly. Signed-off-by: Liviu Dudau <[email protected]>
2017-01-26drm: mali-dp: Check for sufficient address spaceMihail Atanassov2-0/+22
If the device-tree 'reg' node doesn't reserve enough space for the DP, fail to bind. Reviewed-by: Brian Starkey <[email protected]> Signed-off-by: Mihail Atanassov <[email protected]> [renamed added function to malidp_has_sufficient_address_space] Signed-off-by: Liviu Dudau <[email protected]>
2017-01-26drm: mali-dp: Check hw version matches device-treeMihail Atanassov2-0/+54
Refuse to bind if the device-tree compatible string lists a different hardware version. Reviewed-by: Brian Starkey <[email protected]> Signed-off-by: Mihail Atanassov <[email protected]> Signed-off-by: Liviu Dudau <[email protected]>
2017-01-26drm: mali-dp: Rename malidp_input_format to malidp_pixel_formatBrian Starkey3-20/+20
We're going to use the same format list for output formats, so rename everything related to input formats to avoid confusion. Signed-off-by: Brian Starkey <[email protected]> [touched commit title to clarify the final struct name] Signed-off-by: Liviu Dudau <[email protected]>
2017-01-26drm/i915: Pevent copying uninitialised garbage into vma->ggtt_viewChris Wilson1-1/+1
Since tweaking i915_vma_compare() we allowed constructors to skip clearing the ggtt_view believing that we didn't access the unused members. That, as it turns out, was not entirely true. In particular, i915_gem_fault() uses ret = remap_io_mapping(area, area->vm_start + (vma->ggtt_view.partial.offset << PAGE_SHIFT), (ggtt->mappable_base + vma->node.start) >> PAGE_SHIFT, min_t(u64, vma->size, area->vm_end - area->vm_start), &ggtt->mappable); i.e. the ggtt_view.partial for both normal and partial views. If we allowed garbage into the normal vma->ggtt_view and then try userspace tried to mmap it, we could explode in an unobvious fashion. Fixes: 7b92c047bae2 ("drm/i915: Eliminate superfluous i915_ggtt_view_rotated") Fixes: 3bf4d5751943 ("drm/i915: Stop clearing i915_ggtt_view") Reported-by: Matthew Auld <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Matthew Auld <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Tested-by: Matthew Auld <[email protected]> Reviewed-by: Matthew Auld <[email protected]> (cherry picked from commit 7c518460303353084ebcfca99bc4b67ce33745a1)
2017-01-26drm/doc: Fix typos for early_unregister docDaniel Vetter3-3/+3
There's no late_unregister. While at it switch to the new canonical reference style. Cc: Chris Wilson <[email protected]> Acked-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-26drm: s/drm_crtc_get_hv_timings/drm_mode_get_hv_timings/Daniel Vetter6-27/+27
The function operates on modes, not CRTCs. Also move it into drm_modes.[hc]. Spotted while reviewing CRTC docs. Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-26drm/moc: Mark legacy fields in drm_driver as suchDaniel Vetter2-6/+8
No point in documenting these, they only confuse. Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-26drm: Nuke ums vgaarb supportDaniel Vetter2-29/+0
i915, nouveau (ever since merged to upstream) and radeon all lack ums support in upstream. No point keeping the ums vgaarb support around. Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-26drm: remove device_is_agp callbackDaniel Vetter7-33/+6
With that the drm_pci_device_is_agp function becomes trivial, so inline that too. And while at it, move the drm_pci_agp_destroy declaration into drm-internal.h, since it's not used by drivers. Cc: Alex Deucher <[email protected]> Cc: Ben Skeggs <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-26drm/mga: remove device_is_agp callbackDaniel Vetter2-38/+19
It's only for a device quirk, and we might as well do that in the load callback. Acked-by: Alex Deucher <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-26drm/i810: drop device_is_agp callbackDaniel Vetter4-18/+10
Use the same trick we used for i915 when we still had ums support: Just initialize the agp support unconditionally in the driver load function. Unfortunately that means we need to export drm_agp_init again, but I think that's a lesser evil. Acked-by: Alex Deucher <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-26drm/doc: Clarify connector overviewDaniel Vetter1-5/+4
There was a bit of mix-up between initialization and registering. v2: Review from Gustavo. Reviewed-by: Gustavo Padovan <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-26Revert "drm/probe-helpers: Drop locking from poll_enable"Dave Airlie3-22/+34
This reverts commit 3846fd9b86001bea171943cc3bb9222cb6da6b42. There were some precursor commits missing for this around connector locking, we should probably merge Lyude's nouveau avoid the problem patch.
2017-01-25Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds3-5/+35
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
2017-01-25drm: Update kerneldoc for drm_crtc.[hc]Daniel Vetter3-7/+47
After going through all the trouble of splitting out parts from drm_crtc.[hc] and then properly documenting each I've entirely forgotten to show the same TLC for CRTCs themselves! Let's make amends asap. v2: Review from Eric. Reviewed-by: Eric Engestrom <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2017-01-25drm/gma500: Nuke device_is_agp callbackDaniel Vetter1-6/+0
Returning 0 for an on-chip gpu doesn't change anything at all. Cc: Patrik Jakobsson <[email protected]> Reviewed-by: Gustavo Padovan <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-25drm/kms-core: Use recommened kerneldoc for struct member refsDaniel Vetter21-147/+150
I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... v2: Review from Eric. Cc: Jani Nikula <[email protected]> Cc: Chris Wilson <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-25drm/core: Use recommened kerneldoc for struct member refsDaniel Vetter10-33/+33
I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... v2: Review from Gustavo. Cc: Jani Nikula <[email protected]> Cc: Chris Wilson <[email protected]> Reviewed-by: Gustavo Padovan <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-25drm/gem|prime|mm: Use recommened kerneldoc for struct member refsDaniel Vetter4-23/+23
I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... Cc: Jani Nikula <[email protected]> Cc: Chris Wilson <[email protected]> Reviewed-by: Gustavo Padovan <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-25drm/kms-helpers: Use recommened kerneldoc for struct member refsDaniel Vetter11-181/+197
I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... v2: Comments from Gustavo. Cc: Jani Nikula <[email protected]> Cc: Chris Wilson <[email protected]> Rewiewed-by: Gustavo Padovan <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-25drm/dp: Store drm_device in MST topology managerDhinakaran Pandiyan5-8/+12
struct drm_dp_mst_topology_mgr currently stores a pointer to struct dev. Changing this to instead hold a pointer to drm_device is more useful as it gives access to DRM structures. This also makes it consistent with other DRM structures like drm_crtc, drm_connector etc. Signed-off-by: Dhinakaran Pandiyan <[email protected]> Reviewed-by: Dave Airlie <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-01-24Merge branch 'akpm' (patches from Andrew)Linus Torvalds28-78/+237
Merge fixes from Andrew Morton: "26 fixes" * emailed patches from Andrew Morton <[email protected]>: (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 ...
2017-01-24MAINTAINERS: add Dan Streetman to zbud maintainersDan Streetman1-0/+1
Add myself as zbud maintainer. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Dan Streetman <[email protected]> Cc: Seth Jennings <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-01-24MAINTAINERS: add Dan Streetman to zswap maintainersDan Streetman1-0/+1
Add myself as zswap maintainer. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Dan Streetman <[email protected]> Acked-by: Seth Jennings <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-01-24mm: do not export ioremap_page_range symbol for external modulezhong jiang1-1/+0
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/[email protected] Signed-off-by: zhong jiang <[email protected]> Reviewed-by: John Hubbard <[email protected]> Suggested-by: John Hubbard <[email protected]> Acked-by: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-01-24mn10300: fix build error of missing fpu_save()Randy Dunlap1-1/+1
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/[email protected] Signed-off-by: Randy Dunlap <[email protected]> Reported-by: kbuild test robot <[email protected]> Reviewed-by: David Howells <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-01-24romfs: use different way to generate fsid for BLOCK or MTDColy Li1-1/+22
Commit 8a59f5d25265 ("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/[email protected] Signed-off-by: Coly Li <[email protected]> Reported-by: Nong Li <[email protected]> Tested-by: Nong Li <[email protected]> Cc: Richard Weinberger <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-01-24frv: add missing atomic64 operationsSudip Mukherjee1-1/+18
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.uk Signed-off-by: Sudip Mukherjee <[email protected]> Cc: David Howells <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-01-24mm, page_alloc: fix premature OOM when racing with cpuset mems updateVlastimil Babka1-11/+24
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 682a3385e773 ("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. [[email protected]: fix typo in comment] Link: http://lkml.kernel.org/r/[email protected] Fixes: c33d6c06f60f ("mm, page_alloc: avoid looking up the first zone in a zonelist twice") Signed-off-by: Vlastimil Babka <[email protected]> Reported-by: Ganapatrao Kulkarni <[email protected]> Acked-by: Mel Gorman <[email protected]> Acked-by: Hillf Danton <[email protected]> Cc: Michal Hocko <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-01-24mm, page_alloc: move cpuset seqcount checking to slowpathVlastimil Babka1-21/+26
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/[email protected] Signed-off-by: Vlastimil Babka <[email protected]> Acked-by: Mel Gorman <[email protected]> Acked-by: Hillf Danton <[email protected]> Cc: Ganapatrao Kulkarni <[email protected]> Cc: Michal Hocko <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-01-24mm, page_alloc: fix fast-path race with cpuset update or removalVlastimil Babka1-1/+9
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/[email protected] Fixes: 682a3385e773 ("mm, page_alloc: inline the fast path of the zonelist iterator") Signed-off-by: Vlastimil Babka <[email protected]> Reported-by: Ganapatrao Kulkarni <[email protected]> Acked-by: Michal Hocko <[email protected]> Acked-by: Mel Gorman <[email protected]> Acked-by: Hillf Danton <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-01-24mm, page_alloc: fix check for NULL preferred_zoneVlastimil Babka2-2/+6
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/[email protected] This patch (of 4): Since commit c33d6c06f60f ("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: c33d6c06f60f ("mm, page_alloc: avoid looking up the first zone in a zonelist twice") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Vlastimil Babka <[email protected]> Acked-by: Mel Gorman <[email protected]> Acked-by: Hillf Danton <[email protected]> Cc: Ganapatrao Kulkarni <[email protected]> Cc: Michal Hocko <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-01-24kernel/panic.c: add missing \nJiri Slaby1-1/+1
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/[email protected] Signed-off-by: Jiri Slaby <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-01-24fbdev: color map copying bounds checkingKees Cook1-12/+14
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: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Kees Cook <[email protected]> Reported-by: Peter Pi (@heisecode) of Trend Micro Cc: Min Chong <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: Tomi Valkeinen <[email protected]> Cc: Bartlomiej Zolnierkiewicz <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-01-24frv: add atomic64_add_unless()Sudip Mukherjee1-0/+16
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/[email protected] Signed-off-by: Sudip Mukherjee <[email protected]> Cc: David Howells <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-01-24mm/mempolicy.c: do not put mempolicy before using its nodemaskVlastimil Babka1-1/+1
Since commit be97a41b291e ("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: be97a41b291e ("mm/mempolicy.c: merge alloc_hugepage_vma to alloc_pages_vma") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Vlastimil Babka <[email protected]> Acked-by: Kirill A. Shutemov <[email protected]> Acked-by: Michal Hocko <[email protected]> Acked-by: David Rientjes <[email protected]> Cc: Aneesh Kumar K.V <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: <[email protected]> [4.0+] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-01-24radix-tree: fix private list warningsMatthew Wilcox1-1/+1
The newly introduced warning in radix_tree_free_nodes() was testing the wrong variable; it should have been 'old' instead of 'node'. Fixes: ea07b862ac8e ("mm: workingset: fix use-after-free in shadow node shrinker") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Matthew Wilcox <[email protected]> Signed-off-by: Johannes Weiner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-01-24Documentation/filesystems/proc.txt: add VmPinFabian Frederick1-2/+3
Commit bc3e53f682d9 ("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/[email protected] Signed-off-by: Fabian Frederick <[email protected]> Cc: Christoph Lameter <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-01-24mm, memcg: do not retry precharge chargesDavid Rientjes1-2/+2
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: 0029e19ebf84 ("mm: memcontrol: remove explicit OOM parameter in charge path") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: David Rientjes <[email protected]> Acked-by: Michal Hocko <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Vladimir Davydov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-01-24proc: add a schedule point in proc_pid_readdir()Eric Dumazet1-0/+2
We have seen proc_pid_readdir() invocations holding cpu for more than 50 ms. Add a cond_resched() to be gentle with other tasks. [[email protected]: coding style fix] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-01-24mm: alloc_contig: re-allow CMA to compact FS pagesLucas Stach1-0/+1
Commit 73e64c51afc5 ("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: 73e64c51afc5 (mm, compaction: allow compaction for GFP_NOFS requests) Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Lucas Stach <[email protected]> Acked-by: Michal Hocko <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Mel Gorman <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-01-24mm/slub.c: trace free objects at KERN_INFODaniel Thompson1-10/+13
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/[email protected] Signed-off-by: Daniel Thompson <[email protected]> Acked-by: Christoph Lameter <[email protected]> Acked-by: David Rientjes <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Joonsoo Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-01-24userfaultfd: fix SIGBUS resulting from false rwsem wakeupsAndrea Arcangeli1-2/+35
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/[email protected] Signed-off-by: Andrea Arcangeli <[email protected]> Reported-by: Shubham Kumar Sharma <[email protected]> Tested-by: Mike Kravetz <[email protected]> Acked-by: Hillf Danton <[email protected]> Cc: Michael Rapoport <[email protected]> Cc: "Dr. David Alan Gilbert" <[email protected]> Cc: Pavel Emelyanov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.