25 Jun, 2016
22 commits
-
Currently we may put reserved by mempool elements into quarantine via
kasan_kfree(). This is totally wrong since quarantine may really free
these objects. So when mempool will try to use such element,
use-after-free will happen. Or mempool may decide that it no longer
need that element and double-free it.So don't put object into quarantine in kasan_kfree(), just poison it.
Rename kasan_kfree() to kasan_poison_kfree() to respect that.Also, we shouldn't use kasan_slab_alloc()/kasan_krealloc() in
kasan_unpoison_element() because those functions may update allocation
stacktrace. This would be wrong for the most of the remove_element call
sites.(The only call site where we may want to update alloc stacktrace is
in mempool_alloc(). Kmemleak solves this by calling
kmemleak_update_trace(), so we could make something like that too.
But this is out of scope of this patch).Fixes: 55834c59098d ("mm: kasan: initial memory quarantine implementation")
Link: http://lkml.kernel.org/r/575977C3.1010905@virtuozzo.com
Signed-off-by: Andrey Ryabinin
Reported-by: Kuthonuzo Luruo
Acked-by: Alexander Potapenko
Cc: Dmitriy Vyukov
Cc: Kostya Serebryany
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Update the contact info for Muli, clean-up my name, and update the
mailing list to the IOMMU mailing list.Link: http://lkml.kernel.org/r/1465493059-11840-2-git-send-email-jdmason@kudzu.us
Signed-off-by: Jon Mason
Cc: Muli Ben-Yehuda
Cc: Greg Kroah-Hartman
Cc: Krzysztof Kozlowski
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Bartlomiej Zolnierkiewicz
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
jbd2_alloc is explicit about its allocation preferences wrt. the
allocation size. Sub page allocations go to the slab allocator and
larger are using either the page allocator or vmalloc. This is all good
but the logic is unnecessarily complex.1) as per Ted, the vmalloc fallback is a left-over:
: jbd2_alloc is only passed in the bh->b_size, which can't be PAGE_SIZE, so
: the code path that calls vmalloc() should never get called. When we
: conveted jbd2_alloc() to suppor sub-page size allocations in commit
: d2eecb039368, there was an assumption that it could be called with a size
: greater than PAGE_SIZE, but that's certaily not true today.Moreover vmalloc allocation might even lead to a deadlock because the
callers expect GFP_NOFS context while vmalloc is GFP_KERNEL.2) __GFP_REPEAT for requests
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
__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 it is only used in pte_alloc_one,
pte_alloc_one_kernel which does order-0 request. 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-17-git-send-email-mhocko@kernel.org
Signed-off-by: Michal Hocko
Cc: Guan Xuetao
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
__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.pgtable_alloc_one uses __GFP_REPEAT flag for L2_USER_PGTABLE_ORDER but
the order is either 0 or 3 if L2_KERNEL_PGTABLE_SHIFT for HPAGE_SHIFT.
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-16-git-send-email-mhocko@kernel.org
Signed-off-by: Michal Hocko
Acked-by: Chris Metcalf [for tile]
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
__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 {pgd,pmd}_alloc allocate from
{pgd,pmd}_cache but both caches are allocating up to PAGE_SIZE objects.
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-15-git-send-email-mhocko@kernel.org
Signed-off-by: Michal Hocko
Cc: Yoshinori Sato
Cc: Rich Felker
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
__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.page_table_alloc then uses the flag for a single page allocation. 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-14-git-send-email-mhocko@kernel.org
Signed-off-by: Michal Hocko
Acked-by: Heiko Carstens
Cc: Martin Schwidefsky
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
__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.{pud,pmd}_alloc_one is using __GFP_REPEAT but it always allocates from
pgtable_cache which is initialzed to PAGE_SIZE objects. 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-13-git-send-email-mhocko@kernel.org
Signed-off-by: Michal Hocko
Acked-by: David S. Miller
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
__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.{pud,pmd}_alloc_one are allocating from {PGT,PUD}_CACHE initialized in
pgtable_cache_init which doesn't have larger than sizeof(void *) << 12
size and that fits into !costly allocation request size.PGALLOC_GFP is used only in radix__pgd_alloc which uses either order-0
or order-4 requests. The first one doesn't need the flag while the
second does. Drop __GFP_REPEAT from PGALLOC_GFP and add it for the
order-4 one.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-12-git-send-email-mhocko@kernel.org
Signed-off-by: Michal Hocko
Cc: Benjamin Herrenschmidt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
__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.org
Signed-off-by: Michal Hocko
Cc: Chen Liqin
Cc: Lennox Wu
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
__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.org
Signed-off-by: Michal Hocko
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
__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.org
Signed-off-by: Michal Hocko
Cc: Ley Foon Tan
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
__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.org
Signed-off-by: Michal Hocko
Cc: John Crispin
Cc: Ralf Baechle
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
__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.org
Signed-off-by: Michal Hocko
Acked-by: Vineet Gupta
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
__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_48we 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:1All 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.org
Signed-off-by: Michal Hocko
Acked-by: Will Deacon
Cc: Catalin Marinas
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
__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.org
Signed-off-by: Michal Hocko
Acked-by: Matt Fleming
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
__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.org
Signed-off-by: Michal Hocko
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Andy Lutomirski
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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
36So 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.org
Signed-off-by: Michal Hocko
Cc: "David S. Miller"
Cc: "H. Peter Anvin"
Cc: "James E.J. Bottomley"
Cc: "Theodore Ts'o"
Cc: Andy Lutomirski
Cc: Benjamin Herrenschmidt
Cc: Catalin Marinas
Cc: Chen Liqin
Cc: Chris Metcalf [for tile]
Cc: Guan Xuetao
Cc: Heiko Carstens
Cc: Helge Deller
Cc: Ingo Molnar
Cc: Jan Kara
Cc: John Crispin
Cc: Lennox Wu
Cc: Ley Foon Tan
Cc: Martin Schwidefsky
Cc: Matt Fleming
Cc: Ralf Baechle
Cc: Rich Felker
Cc: Russell King
Cc: Thomas Gleixner
Cc: Vineet Gupta
Cc: Will Deacon
Cc: Yoshinori Sato
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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: 1635f6a74152f1d ("tmpfs: undo fallocation on failure")
Link: http://lkml.kernel.org/r/1462713387-16724-1-git-send-email-anthony.romano@coreos.com
Signed-off-by: Anthony Romano
Cc: Vlastimil Babka
Cc: Hugh Dickins
Cc: Brandon Philips
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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.com
Signed-off-by: Mike Kravetz
Cc: Shuah Khan
Cc: Sri Jayaramappa
Cc: Eric B Munson
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Since commit 36324a990cf5 ("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.jp
Signed-off-by: Tetsuo Handa
Acked-by: Michal Hocko
Cc: Arnd Bergmann
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Commit e2fe14564d33 ("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.jp
Signed-off-by: Tetsuo Handa
Acked-by: Michal Hocko
Cc: Arnd Bergmann
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
24 Jun, 2016
13 commits
-
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 -
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 fixesAlso 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()
... -
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 -
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] [] dump_stack+0x4d/0x65
[ 601.491447] [] __warn+0xc6/0xe0
[ 601.491452] [] warn_slowpath_null+0x18/0x20
[ 601.491472] [] drm_modeset_lock_crtc+0xeb/0xf0 [drm]
[ 601.491491] [] drm_mode_cursor_common+0x66/0x180 [drm]
[ 601.491509] [] drm_mode_cursor_ioctl+0x3c/0x40 [drm]
[ 601.491524] [] drm_ioctl+0x14d/0x530 [drm]
[ 601.491540] [] ? drm_mode_setcrtc+0x520/0x520 [drm]
[ 601.491545] [] ? handle_mm_fault+0x106b/0x1430
[ 601.491550] [] ? stop_one_cpu+0x61/0x70
[ 601.491556] [] do_vfs_ioctl+0x8d/0x570
[ 601.491560] [] ? security_file_ioctl+0x3e/0x60
[ 601.491565] [] SyS_ioctl+0x74/0x80
[ 601.491571] [] ? posix_get_monotonic_raw+0xc/0x10
[ 601.491576] [] 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
Reviewed-by: Daniel Vetter
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie -
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() -
…/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 -
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 -
…el/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 -
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 -
* 'linux-4.7' of git://github.com/skeggsb/linux:
drm/nouveau: fix for disabled fbdev emulation -
Hello,
after this commit:
commit f045f459d925138fe7d6193a8c86406bda7e49da
Author: Ben Skeggs
Date: Thu Jun 2 12:23:31 2016 +1000
drm/nouveau/fbcon: fix out-of-bounds memory accesseskernel 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=120591
Signed-off-by: Dmitrii Tcvetkov
Suggested-by: Ilia Mirkin
Fixes: f045f459d925 ("nouveau_fbcon_init()")
Signed-off-by: Ben Skeggs
Cc: stable@vger.kernel.org -
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
-
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
Signed-off-by: Linus Torvalds
23 Jun, 2016
5 commits
-
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] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[ 213.490000] [] (show_stack) from [] (dump_stack+0x8c/0xa0)
[ 213.490000] [] (dump_stack) from [] (ubifs_set_page_dirty+0x44/0x50)
[ 213.490000] [] (ubifs_set_page_dirty) from [] (try_to_unmap_one+0x10c/0x3a8)
[ 213.490000] [] (try_to_unmap_one) from [] (rmap_walk+0xb4/0x290)
[ 213.490000] [] (rmap_walk) from [] (try_to_unmap+0x64/0x80)
[ 213.490000] [] (try_to_unmap) from [] (migrate_pages+0x328/0x7a0)
[ 213.490000] [] (migrate_pages) from [] (alloc_contig_range+0x168/0x2f4)
[ 213.490000] [] (alloc_contig_range) from [] (cma_alloc+0x170/0x2c0)
[ 213.490000] [] (cma_alloc) from [] (__alloc_from_contiguous+0x38/0xd8)
[ 213.490000] [] (__alloc_from_contiguous) from [] (__dma_alloc+0x23c/0x274)
[ 213.490000] [] (__dma_alloc) from [] (arm_dma_alloc+0x54/0x5c)
[ 213.490000] [] (arm_dma_alloc) from [] (drm_gem_cma_create+0xb8/0xf0)
[ 213.490000] [] (drm_gem_cma_create) from [] (drm_gem_cma_create_with_handle+0x1c/0xe8)
[ 213.490000] [] (drm_gem_cma_create_with_handle) from [] (drm_gem_cma_dumb_create+0x3c/0x48)
[ 213.490000] [] (drm_gem_cma_dumb_create) from [] (drm_ioctl+0x12c/0x444)
[ 213.490000] [] (drm_ioctl) from [] (do_vfs_ioctl+0x3f4/0x614)
[ 213.490000] [] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c)
[ 213.490000] [] (SyS_ioctl) from [] (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
[rw: Massaged changelog, build fixes, etc...]
Signed-off-by: Richard Weinberger
Acked-by: Christoph Hellwig -
Export these symbols such that UBIFS can implement
->migratepage.Cc: stable@vger.kernel.org
Signed-off-by: Richard Weinberger
Acked-by: Christoph Hellwig -
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
Reviewed-by: Jörg Pfähler
Signed-off-by: Richard Weinberger -
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
Reviewed-by: Grygorii Strashko
Acked-by: Alexandre Courbot
Signed-off-by: Linus Walleij -
commit 54d77198fdfbc4f0fe11b4252c1d9c97d51a3264
("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
Reported-by: Hans de Goede
Tested-by: Hans de Goede
Signed-off-by: Linus Walleij
