- 25 Jun, 2016 13 commits
-
-
Michal Hocko authored
__GFP_REPEAT has a rather weak semantic but since it has been introduced around 2.6.12 it has been ignored for low order allocations. pte_alloc_one{_kernel} allocate PTE_ORDER which is 0. This means that this flag has never been actually useful here because it has always been used only for PAGE_ALLOC_COSTLY requests. Link: http://lkml.kernel.org/r/1464599699-30131-11-git-send-email-mhocko@kernel.orgSigned-off-by:Michal Hocko <mhocko@suse.com> Cc: Chen Liqin <liqin.linux@gmail.com> Cc: Lennox Wu <lennox.wu@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Michal Hocko authored
__GFP_REPEAT has a rather weak semantic but since it has been introduced around 2.6.12 it has been ignored for low order allocations. pmd_alloc_one allocate PMD_ORDER which is 1. This means that this flag has never been actually useful here because it has always been used only for PAGE_ALLOC_COSTLY requests. Link: http://lkml.kernel.org/r/1464599699-30131-10-git-send-email-mhocko@kernel.orgSigned-off-by:
-
Michal Hocko authored
__GFP_REPEAT has a rather weak semantic but since it has been introduced around 2.6.12 it has been ignored for low order allocations. pte_alloc_one{_kernel} allocate PTE_ORDER which is 0. This means that this flag has never been actually useful here because it has always been used only for PAGE_ALLOC_COSTLY requests. Link: http://lkml.kernel.org/r/1464599699-30131-9-git-send-email-mhocko@kernel.orgSigned-off-by: -
Michal Hocko authored
__GFP_REPEAT has a rather weak semantic but since it has been introduced around 2.6.12 it has been ignored for low order allocations. pte_alloc_one{_kernel}, pmd_alloc_one allocate PTE_ORDER resp. PMD_ORDER but both are not larger than 1. This means that this flag has never been actually useful here because it has always been used only for PAGE_ALLOC_COSTLY requests. Link: http://lkml.kernel.org/r/1464599699-30131-8-git-send-email-mhocko@kernel.orgSigned-off-by: -
Michal Hocko authored
__GFP_REPEAT has a rather weak semantic but since it has been introduced around 2.6.12 it has been ignored for low order allocations. pte_alloc_one_kernel uses __get_order_pte but this is obviously always zero because BITS_FOR_PTE is not larger than 9 yet the page size is always larger than 4K. This means that this flag has never been actually useful here because it has always been used only for PAGE_ALLOC_COSTLY requests. Link: http://lkml.kernel.org/r/1464599699-30131-7-git-send-email-mhocko@kernel.orgSigned-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Michal Hocko authored
__GFP_REPEAT has a rather weak semantic but since it has been introduced around 2.6.12 it has been ignored for low order allocations. {pte,pmd,pud}_alloc_one{_kernel}, late_pgtable_alloc use PGALLOC_GFP for __get_free_page (aka order-0). pgd_alloc is slightly more complex because it allocates from pgd_cache if PGD_SIZE != PAGE_SIZE and PGD_SIZE depends on the configuration (CONFIG_ARM64_VA_BITS, PAGE_SHIFT and CONFIG_PGTABLE_LEVELS). As per config PGTABLE_LEVELS int default 2 if ARM64_16K_PAGES && ARM64_VA_BITS_36 default 2 if ARM64_64K_PAGES && ARM64_VA_BITS_42 default 3 if ARM64_64K_PAGES && ARM64_VA_BITS_48 default 3 if ARM64_4K_PAGES && ARM64_VA_BITS_39 default 3 if ARM64_16K_PAGES && ARM64_VA_BITS_47 default 4 if !ARM64_64K_PAGES && ARM64_VA_BITS_48 we should have the following options CONFIG_ARM64_VA_BITS:48 CONFIG_PGTABLE_LEVELS:4 PAGE_SIZE:4k size:4096 pages:1 CONFIG_ARM64_VA_BITS:48 CONFIG_PGTABLE_LEVELS:4 PAGE_SIZE:16k size:16 pages:1 CONFIG_ARM64_VA_BITS:48 CONFIG_PGTABLE_LEVELS:3 PAGE_SIZE:64k size:512 pages:1 CONFIG_ARM64_VA_BITS:47 CONFIG_PGTABLE_LEVELS:3 PAGE_SIZE:16k size:16384 pages:1 CONFIG_ARM64_VA_BITS:42 CONFIG_PGTABLE_LEVELS:2 PAGE_SIZE:64k size:65536 pages:1 CONFIG_ARM64_VA_BITS:39 CONFIG_PGTABLE_LEVELS:3 PAGE_SIZE:4k size:4096 pages:1 CONFIG_ARM64_VA_BITS:36 CONFIG_PGTABLE_LEVELS:2 PAGE_SIZE:16k size:16384 pages:1 All of them fit into a single page (aka order-0). This means that this flag has never been actually useful here because it has always been used only for PAGE_ALLOC_COSTLY requests. Link: http://lkml.kernel.org/r/1464599699-30131-6-git-send-email-mhocko@kernel.orgSigned-off-by:Will Deacon <will.deacon@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Michal Hocko authored
__GFP_REPEAT has a rather weak semantic but since it has been introduced around 2.6.12 it has been ignored for low order allocations. efi_alloc_page_tables uses __GFP_REPEAT but it allocates an order-0 page. This means that this flag has never been actually useful here because it has always been used only for PAGE_ALLOC_COSTLY requests. Link: http://lkml.kernel.org/r/1464599699-30131-4-git-send-email-mhocko@kernel.orgSigned-off-by:
Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by:
-
Michal Hocko authored
__GFP_REPEAT has a rather weak semantic but since it has been introduced around 2.6.12 it has been ignored for low order allocations. PGALLOC_GFP uses __GFP_REPEAT but none of the allocation which uses this flag is for more than order-0. This means that this flag has never been actually useful here because it has always been used only for PAGE_ALLOC_COSTLY requests. Link: http://lkml.kernel.org/r/1464599699-30131-3-git-send-email-mhocko@kernel.orgSigned-off-by:
-
Michal Hocko authored
This is the third version of the patchset previously sent [1]. I have basically only rebased it on top of 4.7-rc1 tree and dropped "dm: get rid of superfluous gfp flags" which went through dm tree. I am sending it now because it is tree wide and chances for conflicts are reduced considerably when we want to target rc2. I plan to send the next step and rename the flag and move to a better semantic later during this release cycle so we will have a new semantic ready for 4.8 merge window hopefully. Motivation: While working on something unrelated I've checked the current usage of __GFP_REPEAT in the tree. It seems that a majority of the usage is and always has been bogus because __GFP_REPEAT has always been about costly high order allocations while we are using it for order-0 or very small orders very often. It seems that a big pile of them is just a copy&paste when a code has been adopted from one arch to another. I think it makes some sense to get rid of them because they are just making the semantic more unclear. Please note that GFP_REPEAT is documented as * __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt * _might_ fail. This depends upon the particular VM implementation. while !costly requests have basically nofail semantic. So one could reasonably expect that order-0 request with __GFP_REPEAT will not loop for ever. This is not implemented right now though. I would like to move on with __GFP_REPEAT and define a better semantic for it. $ git grep __GFP_REPEAT origin/master | wc -l 111 $ git grep __GFP_REPEAT | wc -l 36 So we are down to the third after this patch series. The remaining places really seem to be relying on __GFP_REPEAT due to large allocation requests. This still needs some double checking which I will do later after all the simple ones are sorted out. I am touching a lot of arch specific code here and I hope I got it right but as a matter of fact I even didn't compile test for some archs as I do not have cross compiler for them. Patches should be quite trivial to review for stupid compile mistakes though. The tricky parts are usually hidden by macro definitions and thats where I would appreciate help from arch maintainers. [1] http://lkml.kernel.org/r/1461849846-27209-1-git-send-email-mhocko@kernel.org This patch (of 19): __GFP_REPEAT has a rather weak semantic but since it has been introduced around 2.6.12 it has been ignored for low order allocations. Yet we have the full kernel tree with its usage for apparently order-0 allocations. This is really confusing because __GFP_REPEAT is explicitly documented to allow allocation failures which is a weaker semantic than the current order-0 has (basically nofail). Let's simply drop __GFP_REPEAT from those places. This would allow to identify place which really need allocator to retry harder and formulate a more specific semantic for what the flag is supposed to do actually. Link: http://lkml.kernel.org/r/1464599699-30131-2-git-send-email-mhocko@kernel.orgSigned-off-by:
-
Anthony Romano authored
When fallocate is interrupted it will undo a range that extends one byte past its range of allocated pages. This can corrupt an in-use page by zeroing out its first byte. Instead, undo using the inclusive byte range. Fixes: 1635f6a7 ("tmpfs: undo fallocation on failure") Link: http://lkml.kernel.org/r/1462713387-16724-1-git-send-email-anthony.romano@coreos.comSigned-off-by:
Anthony Romano <anthony.romano@coreos.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Hugh Dickins <hughd@google.com> Cc: Brandon Philips <brandon@ifup.co> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Mike Kravetz authored
The write at the end of the test to restore nr_hugepages to its previous value is failing. This is because it is trying to write the number of bytes in the char array as opposed to the number of bytes in the string. Link: http://lkml.kernel.org/r/1465331205-3284-1-git-send-email-mike.kravetz@oracle.comSigned-off-by:
Mike Kravetz <mike.kravetz@oracle.com> Cc: Shuah Khan <shuahkh@osg.samsung.com> Cc: Sri Jayaramappa <sjayaram@akamai.com> Cc: Eric B Munson <emunson@akamai.com> Signed-off-by:
-
Tetsuo Handa authored
Since commit 36324a99 ("oom: clear TIF_MEMDIE after oom_reaper managed to unmap the address space") changed to use find_lock_task_mm() for finding a mm_struct to reap, it is guaranteed that mm->mm_users > 0 because find_lock_task_mm() returns a task_struct with ->mm != NULL. Therefore, we can safely use atomic_inc(). Link: http://lkml.kernel.org/r/1465024759-8074-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jpSigned-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Acked-by:
-
Tetsuo Handa authored
Commit e2fe1456 ("oom_reaper: close race with exiting task") reduced frequency of needlessly selecting next OOM victim, but was calling mmput_async() when atomic_inc_not_zero() failed. Link: http://lkml.kernel.org/r/1464423365-5555-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jpSigned-off-by:
-
- 24 Jun, 2016 10 commits
-
-
git://git.infradead.org/linux-ubifsLinus Torvalds authored
Pull UBI/UBIFS fixes from Richard Weinberger: "This contains fixes for two critical bugs in UBI and UBIFS: - fix the possibility of losing data upon a power cut when UBI tries to recover from a write error - fix page migration on UBIFS. It turned out that the default page migration function is not suitable for UBIFS" * tag 'upstream-4.7-rc5' of git://git.infradead.org/linux-ubifs: UBIFS: Implement ->migratepage() mm: Export migrate_page_move_mapping and migrate_page_copy ubi: Make recover_peb power cut aware gpio: make library immune to error pointers gpio: make sure gpiod_to_irq() returns negative on NULL desc gpio: 104-idi-48: Fix missing spin_lock_init for ack_lock -
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
Pull drm fixes from Dave Airlie: "This is the drm fixes tree for 4.7-rc5. It's a bit larger than normal, due to fixes for production AMD Polaris GPUs. We only merged support for these in 4.7-rc1 so it would be good if we got all the fixes into final. The changes don't hit any other hardware. Other than the amdgpu Polaris changes: - A single fix for atomic modesetting WARN - Nouveau fix for when fbdev is disabled - i915 fixes for FBC on Haswell and displayport regression - Exynos fix for a display panel regression and some other minor changes - Atmel fixes for scaling and OF graph interaction - Allwiinner build, warning and probing fixes - AMD GPU non-polaris fix for num_rbs and some minor fixes Also I've just moved house, and my new place is Internet challenged due to incompetent incumbent ISPs, hopefully sorted out in a couple of weeks, so I might not be too responsive over the next while. It also helps Daniel is on holidays for those couple of weeks as well" * tag 'drm-fixes-for-v4.7-rc5' of git://people.freedesktop.org/~airlied/linux: (38 commits) drm/atomic: Make drm_atomic_legacy_backoff reset crtc->acquire_ctx drm/nouveau: fix for disabled fbdev emulation drm/i915/fbc: Disable on HSW by default for now drm/i915: Revert DisplayPort fast link training feature drm/amd/powerplay: enable clock stretch feature for polaris drm/amdgpu/gfx8: update golden setting for polaris10 drm/amd/powerplay: enable avfs feature for polaris drm/amdgpu/atombios: add avfs struct for Polaris10/11 drm/amd/powerplay: add avfs related define for polaris drm/amd/powrplay: enable stutter_mode for polaris. drm/amd/powerplay: disable UVD SMU handshake for MCLK. drm/amd/powerplay: initialize variables which were missed. drm/amd/powerplay: enable PowerContainment feature for polaris10/11. drm/amd/powerplay: need to notify system bios pcie device ready drm/amd/powerplay: fix bug that function parameter was incorect. drm/amd/powerplay: fix logic error. drm: atmel-hlcdc: Fix OF graph parsing drm: atmel-hlcdc: actually disable scaling when no scaling is required drm/amdgpu: initialize amdgpu_cgs_acpi_eval_object result value drm/amdgpu: precedence bug in amdgpu_device_init() ...
-
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pciLinus Torvalds authored
Pull PCI fix from Bjorn Helgaas: "Here's a small fix for v4.7. This problem was actually introduced in v4.6 when we unified Kconfig, making PCIe support available everywhere including sparc, where config reads into unaligned buffers cause warnings. This fix is from Dave Miller. As a reminder, any future PCI fixes for v4.7 will probably come from Alex Williamson, since I'll be on vacation for most of the rest of this cycle. I should be back about the time the merge window opens" * tag 'pci-v4.7-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI: Fix unaligned accesses in VC code
-
Maarten Lankhorst authored
Atomic updates may acquire more state than initially locked through drm_modeset_lock_crtc, running with heavy stress can cause a WARN_ON(crtc->acquire_ctx) in drm_modeset_lock_crtc: [ 601.491296] ------------[ cut here ]------------ [ 601.491366] WARNING: CPU: 0 PID: 2411 at drivers/gpu/drm/drm_modeset_lock.c:191 drm_modeset_lock_crtc+0xeb/0xf0 [drm] [ 601.491369] Modules linked in: drm i915 drm_kms_helper [ 601.491414] CPU: 0 PID: 2411 Comm: kms_cursor_lega Tainted: G U 4.7.0-rc4-patser+ #4798 [ 601.491417] Hardware name: Intel Corporation Skylake Client [ 601.491420] 0000000000000000 ffff88044d153c98 ffffffff812ead28 0000000000000000 [ 601.491425] 0000000000000000 ffff88044d153cd8 ffffffff810868e6 000000bf58058030 [ 601.491431] ffff880088b415e8 ffff880458058030 ffff88008a271548 ffff88008a271568 [ 601.491436] Call Trace: [ 601.491443] [<ffffffff812ead28>] dump_stack+0x4d/0x65 [ 601.491447] [<ffffffff810868e6>] __warn+0xc6/0xe0 [ 601.491452] [<ffffffff81086968>] warn_slowpath_null+0x18/0x20 [ 601.491472] [<ffffffffc00d4ffb>] drm_modeset_lock_crtc+0xeb/0xf0 [drm] [ 601.491491] [<ffffffffc00c5526>] drm_mode_cursor_common+0x66/0x180 [drm] [ 601.491509] [<ffffffffc00c91cc>] drm_mode_cursor_ioctl+0x3c/0x40 [drm] [ 601.491524] [<ffffffffc00bc94d>] drm_ioctl+0x14d/0x530 [drm] [ 601.491540] [<ffffffffc00c9190>] ? drm_mode_setcrtc+0x520/0x520 [drm] [ 601.491545] [<ffffffff81176aeb>] ? handle_mm_fault+0x106b/0x1430 [ 601.491550] [<ffffffff81108441>] ? stop_one_cpu+0x61/0x70 [ 601.491556] [<ffffffff811bb71d>] do_vfs_ioctl+0x8d/0x570 [ 601.491560] [<ffffffff81290d7e>] ? security_file_ioctl+0x3e/0x60 [ 601.491565] [<ffffffff811bbc74>] SyS_ioctl+0x74/0x80 [ 601.491571] [<ffffffff810e321c>] ? posix_get_monotonic_raw+0xc/0x10 [ 601.491576] [<ffffffff8175b11b>] entry_SYSCALL_64_fastpath+0x13/0x8f [ 601.491581] ---[ end trace 56f3d3d85f000d00 ]--- For good measure, test mode_config.acquire_ctx too, although this should never happen. Testcase: kms_cursor_legacy Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
A bit bigger than I would normally like, but most of the large changes are for polaris support and since polaris went upstream in 4.7, I'd like to get the fixes in so it's in good shape when the hw becomes available. The major changes only touch the polaris code so there is little chance for regressions on other asics. The rest are just the usual collection of bug fixes. * 'drm-fixes-4.7' of git://people.freedesktop.org/~agd5f/linux: drm/amd/powerplay: enable clock stretch feature for polaris drm/amdgpu/gfx8: update golden setting for polaris10 drm/amd/powerplay: enable avfs feature for polaris drm/amdgpu/atombios: add avfs struct for Polaris10/11 drm/amd/powerplay: add avfs related define for polaris drm/amd/powrplay: enable stutter_mode for polaris. drm/amd/powerplay: disable UVD SMU handshake for MCLK. drm/amd/powerplay: initialize variables which were missed. drm/amd/powerplay: enable PowerContainment feature for polaris10/11. drm/amd/powerplay: need to notify system bios pcie device ready drm/amd/powerplay: fix bug that function parameter was incorect. drm/amd/powerplay: fix logic error. drm/amdgpu: initialize amdgpu_cgs_acpi_eval_object result value drm/amdgpu: precedence bug in amdgpu_device_init() drm/amdgpu: fix num_rbs exposed to userspace (v2) drm/amdgpu: missing bounds check in amdgpu_set_pp_force_state()
-
Dave Airlie authored
Merge branch 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes Since HW trigger mode was suppoted we have faced with a issue that Display panel didn't work correctly when trigger mode was changed in booting time. For this, we keep trigger mode with SW trigger mode in default mode like we did before. However, we will need to consider PSR(Panel Self Reflash) mode to resolve this issue fundamentally later. * 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm/exynos: use logical AND in exynos_drm_plane_check_size() drm/exynos: remove superfluous inclusions of fbdev header drm/exynos: g2d: drop the _REG postfix from the stride defines drm/exynos: don't use HW trigger for Exynos5420/5422/5800 drm/exynos: fimd: don't set .has_hw_trigger in s3c6400 driver data drm/exynos: dp: Fix NULL pointer dereference due uninitialized connector
-
Dave Airlie authored
Two bug fixes for the atmel-hlcdc driver. * tag 'drm-atmel-hlcdc-fixes/for-4.7-rc5' of github.com:bbrezillon/linux-at91: drm: atmel-hlcdc: Fix OF graph parsing drm: atmel-hlcdc: actually disable scaling when no scaling is required
-
Dave Airlie authored
Merge tag 'sunxi-drm-fixes-for-4.7' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into drm-fixes Allwinner sun4i DRM driver fixes A bunch of fixes that address: - Compilation errors in various corner cases - Move to helpers - Fix the pixel clock computation - Fix our panel probe * tag 'sunxi-drm-fixes-for-4.7' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux: drm: sun4i: do cleanup if RGB output init fails drm/sun4i: Convert to connector register helpers drm/sun4i: remove simplefb at probe drm/sun4i: rgb: panel is an error pointer drm/sun4i: defer only if we didn't find our panel drm/sun4i: rgb: Validate the clock rate drm/sun4i: request exact rates to our parents drm: sun4i: fix probe error handling drm: sun4i: print DMA address correctly drm/sun4i: add COMMON_CLK dependency
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
Hi Dave, just a couple of display fixes, both stable stuff. Maybe we'll be able to enable fbc by default one day. * tag 'drm-intel-fixes-2016-06-22' of git://anongit.freedesktop.org/drm-intel: drm/i915/fbc: Disable on HSW by default for now drm/i915: Revert DisplayPort fast link training feature
-
git://github.com/skeggsb/linuxDave Airlie authored
* 'linux-4.7' of git://github.com/skeggsb/linux: drm/nouveau: fix for disabled fbdev emulation
-
- 23 Jun, 2016 3 commits
-
-
Dmitrii Tcvetkov authored
Hello, after this commit: commit f045f459 Author: Ben Skeggs <bskeggs@redhat.com> Date: Thu Jun 2 12:23:31 2016 +1000 drm/nouveau/fbcon: fix out-of-bounds memory accesses kernel started to oops when loading nouveau module when using GTX 780 Ti video adapter. This patch fixes the problem. Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=120591Signed-off-by:
Dmitrii Tcvetkov <demfloro@demfloro.ru> Suggested-by:
Ilia Mirkin <imirkin@alum.mit.edu> Fixes: f045f459 ("nouveau_fbcon_init()") Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
-
Linus Torvalds authored
None of the code actually wants a thread_info, it all wants a task_struct, and it's just converting to a thread_info pointer much too early. No semantic change. Signed-off-by: -
Linus Torvalds authored
None of the code actually wants a thread_info, it all wants a task_struct, and it's just converting back and forth between the two ("ti->task" to get the task_struct from the thread_info, and "task_thread_info(task)" to go the other way). No semantic change. Acked-by:Peter Zijlstra <peterz@infradead.org> Signed-off-by:
-
- 22 Jun, 2016 8 commits
-
-
Kirill A. Shutemov authored
During page migrations UBIFS might get confused and the following assert triggers: [ 213.480000] UBIFS assert failed in ubifs_set_page_dirty at 1451 (pid 436) [ 213.490000] CPU: 0 PID: 436 Comm: drm-stress-test Not tainted 4.4.4-00176-geaa802524636-dirty #1008 [ 213.490000] Hardware name: Allwinner sun4i/sun5i Families [ 213.490000] [<c0015e70>] (unwind_backtrace) from [<c0012cdc>] (show_stack+0x10/0x14) [ 213.490000] [<c0012cdc>] (show_stack) from [<c02ad834>] (dump_stack+0x8c/0xa0) [ 213.490000] [<c02ad834>] (dump_stack) from [<c0236ee8>] (ubifs_set_page_dirty+0x44/0x50) [ 213.490000] [<c0236ee8>] (ubifs_set_page_dirty) from [<c00fa0bc>] (try_to_unmap_one+0x10c/0x3a8) [ 213.490000] [<c00fa0bc>] (try_to_unmap_one) from [<c00fadb4>] (rmap_walk+0xb4/0x290) [ 213.490000] [<c00fadb4>] (rmap_walk) from [<c00fb1bc>] (try_to_unmap+0x64/0x80) [ 213.490000] [<c00fb1bc>] (try_to_unmap) from [<c010dc28>] (migrate_pages+0x328/0x7a0) [ 213.490000] [<c010dc28>] (migrate_pages) from [<c00d0cb0>] (alloc_contig_range+0x168/0x2f4) [ 213.490000] [<c00d0cb0>] (alloc_contig_range) from [<c010ec00>] (cma_alloc+0x170/0x2c0) [ 213.490000] [<c010ec00>] (cma_alloc) from [<c001a958>] (__alloc_from_contiguous+0x38/0xd8) [ 213.490000] [<c001a958>] (__alloc_from_contiguous) from [<c001ad44>] (__dma_alloc+0x23c/0x274) [ 213.490000] [<c001ad44>] (__dma_alloc) from [<c001ae08>] (arm_dma_alloc+0x54/0x5c) [ 213.490000] [<c001ae08>] (arm_dma_alloc) from [<c035cecc>] (drm_gem_cma_create+0xb8/0xf0) [ 213.490000] [<c035cecc>] (drm_gem_cma_create) from [<c035cf20>] (drm_gem_cma_create_with_handle+0x1c/0xe8) [ 213.490000] [<c035cf20>] (drm_gem_cma_create_with_handle) from [<c035d088>] (drm_gem_cma_dumb_create+0x3c/0x48) [ 213.490000] [<c035d088>] (drm_gem_cma_dumb_create) from [<c0341ed8>] (drm_ioctl+0x12c/0x444) [ 213.490000] [<c0341ed8>] (drm_ioctl) from [<c0121adc>] (do_vfs_ioctl+0x3f4/0x614) [ 213.490000] [<c0121adc>] (do_vfs_ioctl) from [<c0121d30>] (SyS_ioctl+0x34/0x5c) [ 213.490000] [<c0121d30>] (SyS_ioctl) from [<c000f2c0>] (ret_fast_syscall+0x0/0x34) UBIFS is using PagePrivate() which can have different meanings across filesystems. Therefore the generic page migration code cannot handle this case correctly. We have to implement our own migration function which basically does a plain copy but also duplicates the page private flag. UBIFS is not a block device filesystem and cannot use buffer_migrate_page(). Cc: stable@vger.kernel.org Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> [rw: Massaged changelog, build fixes, etc...] Signed-off-by:
Richard Weinberger <richard@nod.at> Acked-by:
Christoph Hellwig <hch@lst.de>
-
Richard Weinberger authored
Export these symbols such that UBIFS can implement ->migratepage. Cc: stable@vger.kernel.org Signed-off-by:
-
Richard Weinberger authored
recover_peb() was never power cut aware, if a power cut happened right after writing the VID header upon next attach UBI would blindly use the new partial written PEB and all data from the old PEB is lost. In order to make recover_peb() power cut aware, write the new VID with a proper crc and copy_flag set such that the UBI attach process will detect whether the new PEB is completely written or not. We cannot directly use ubi_eba_atomic_leb_change() since we'd have to unlock the LEB which is facing a write error. Cc: stable@vger.kernel.org Reported-by:
Jörg Pfähler <pfaehler@isse.de> Reviewed-by:
-
Linus Walleij authored
Most functions that take a GPIO descriptor in need to check the descriptor for IS_ERR(). We do this mostly in the VALIDATE_DESC() macro except for the gpiod_to_irq() function which needs special handling. Cc: stable@vger.kernel.org Reported-by:
Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by:
Alexandre Courbot <acourbot@nvidia.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
commit 54d77198 ("gpio: bail out silently on NULL descriptors") doesn't work for gpiod_to_irq(): drivers assume that NULL descriptors will give negative IRQ numbers in return. It has been pointed out that returning 0 is NO_IRQ and that drivers should be amended to treat this as an error, but that is for the longer term: now let us repair the semantics. Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Reported-by:
Hans de Goede <hdegoede@redhat.com> Tested-by:
-
Axel Lin authored
Fixes: 9ae48210 ("gpio: 104-idi-48: Clear pending interrupt once in IRQ handler") Signed-off-by:
Axel Lin <axel.lin@ingics.com> Acked-by:
William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespaceLinus Torvalds authored
Pull userns fix from Eric Biederman: "This contains just a single small patch that fixes a tiny hole in the logic of allowing unprivileged mounting of proc and sysfs. In practice I don't think anyone is affected because having MNT_RDONLY clear in mnt->mnt_flags but MS_RDONLY set in sb->s_flags is very weird for a filesystem, and weirder for proc and sysfs. However if it happens let's handle it correctly and then no one has to to worry about this crazy case" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: mnt: Account for MS_RDONLY in fs_fully_visible
-
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpioLinus Torvalds authored
Pull GPIO fixes from Linus Walleij: "More GPIO fixes. Most prominent the gpiod_to_irq() fix brought to my attention by Hans de Goede. The hardening patch is a consequence of the reasoning around that bug. - It was discovered that too many parts of the kernel does not respect gpiod_to_irq() returning zero for an invalid IRQ. While this gets fixed, we need to make it return negative errorcodes again. - Harden the library a bit when passed error pointers. It is a bug to use these, but let's be helpful and warn the users. - Fix an uninitialized spinlock in the 104-idi-48 driver" * tag 'gpio-v4.7-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: make library immune to error pointers gpio: make sure gpiod_to_irq() returns negative on NULL desc gpio: 104-idi-48: Fix missing spin_lock_init for ack_lock
-
- 21 Jun, 2016 6 commits
-
-
Lyude authored
>From https://bugs.freedesktop.org/show_bug.cgi?id=96461 : This was kind of a difficult bug to track down. If you're using a Haswell system running GNOME and you have fbc completely enabled and working, playing videos can result in video artifacts. Steps to reproduce: - Run GNOME - Ensure FBC is enabled and active - Download a movie, I used the ogg version of Big Buck Bunny for this - Run `gst-launch-1.0 filesrc location='some_movie.ogg' ! decodebin ! glimagesink` in a terminal - Watch for about over a minute, you'll see small horizontal lines go down the screen. For the time being, disable FBC for Haswell by default. Stefan Richter reported kernel freezes (no video artifacts) when fbc is on. (E3-1245 v3 with HD P4600; openbox and some KDE and LXDE applications, thread begins at https://lkml.org/lkml/2016/4/26/813). We also got reports from Steven Honeyman on openbox+roxterm. v2 (From Paulo): - Add extra information to the commit message - Add Fixes tag - Rebase Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96461 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96464 Fixes: a98ee793 ("drm/i915/fbc: enable FBC by default on HSW and BDW") Cc: stable@vger.kernel.org Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Lyude <cpaul@redhat.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Mika Kahola authored
It has been found out that in some HW combination the DisplayPort fast link training feature caused screen flickering. Let's revert this feature for now until we can ensure that the feature works for all platforms. This is a manual revert of commits 5fa836a9 ("drm/i915: DP link training optimization") and 4e96c977 ("drm/i915: eDP link training optimization"). Fixes: 5fa836a9 ("drm/i915: DP link training optimization") Fixes: 4e96c977 ("drm/i915: eDP link training optimization") Cc: <stable@vger.kernel.org> # v4.2+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91393Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
Rex Zhu authored
Power saving feature which reduces the amount of voltage needed for specific engine clocks. Signed-off-by:
Rex Zhu <Rex.Zhu@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Rex Zhu authored
Signed-off-by:
-
Rex Zhu authored
avfs feature is for voltage control based on gpu system clock on polaris10 Signed-off-by:
-
Rex Zhu authored
Signed-off-by:
-
