Occasionally we hit the BUG_ON(pmd_trans_huge(*pmd)) at the end of
__split_huge_page_pmd(): seen when doing madvise(,,MADV_DONTNEED).
It's invalid: we don't always have down_write of mmap_sem there: a racing
do_huge_pmd_wp_page() might have copied-on-write to another huge page
before our split_huge_page() got the anon_vma lock.
Forget the BUG_ON, just go back and try again if this happens.
Signed-off-by: Hugh Dickins <[email protected]>
Acked-by: Kirill A. Shutemov <[email protected]>
Cc: Andrea Arcangeli <[email protected]>
Cc: Naoya Horiguchi <[email protected]>
Cc: David Rientjes <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Fix race between swapoff and swapon. Swapoff used old_block_size from
swap_info outside of swapon_mutex so it could be overwritten by
concurrent swapon.
The race has visible effect only if more than one swap block device
exists with different block sizes (e.g. /dev/sda1 with block size 4096
and /dev/sdb1 with 512). In such case it leads to setting the blocksize
of swapped off device with wrong blocksize.
The bug can be triggered with multiple concurrent swapoff and swapon:
0. Swap for some device is on.
1. swapoff:
First the swapoff is called on this device and "struct swap_info_struct
*p" is assigned. This is done under swap_lock however this lock is
released for the call try_to_unuse().
2. swapon:
After the assignment above (and before acquiring swapon_mutex &
swap_lock by swapoff) the swapon is called on the same device.
The p->old_block_size is assigned to the value of block_size the device.
This block size should be the same as previous but sometimes it is not.
The swapon ends successfully.
3. swapoff:
Swapoff resumes, grabs the locks and mutex and continues to disable this
swap device. Now it sets the block size to value taken from swap_info
which was overwritten by swapon in 2.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Reported-by: Weijie Yang <[email protected]>
Cc: Bob Liu <[email protected]>
Cc: Konrad Rzeszutek Wilk <[email protected]>
Cc: Shaohua Li <[email protected]>
Cc: Minchan Kim <[email protected]>
Acked-by: Hugh Dickins <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Commit c4fe244857 ("sparc: fix PCI device proc file mmap(2)") added
proc_reg_get_unmapped_area in proc_reg_file_ops and
proc_reg_file_ops_no_compat, by which now mmap always returns EIO if
get_unmapped_area method is not defined for the target procfs file,
which causes regression of mmap on /proc/vmcore.
To address this issue, like get_unmapped_area(), call default
current->mm->get_unmapped_area on MMU-present architectures if
pde->proc_fops->get_unmapped_area, i.e. the one in actual file
operation in the procfs file, is not defined.
Reported-by: Michael Holzheu <[email protected]>
Signed-off-by: HATAYAMA Daisuke <[email protected]>
Cc: Alexey Dobriyan <[email protected]>
Cc: David S. Miller <[email protected]>
Tested-by: Michael Holzheu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Currently, proc_reg_get_unmapped_area truncates upper 32-bit of the
mapped virtual address returned from get_unmapped_area method in
pde->proc_fops due to the variable rv of signed integer on x86_64. This
is too small to have vitual address of unsigned long on x86_64 since on
x86_64, signed integer is of 4 bytes while unsigned long is of 8 bytes.
To fix this issue, use unsigned long instead.
Fixes a regression added in commit c4fe244857 ("sparc: fix PCI device
proc file mmap(2)").
Signed-off-by: HATAYAMA Daisuke <[email protected]>
Cc: Alexey Dobriyan <[email protected]>
Cc: David S. Miller <[email protected]>
Tested-by: Michael Holzheu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Toralf runs trinity on UML/i386. After some time it hangs and the last
message line is
BUG: soft lockup - CPU#0 stuck for 22s! [trinity-child0:1521]
It's found that pages_dirtied becomes very large. More than 1000000000
pages in this case:
period = HZ * pages_dirtied / task_ratelimit;
BUG_ON(pages_dirtied > 2000000000);
BUG_ON(pages_dirtied > 1000000000); <---------
UML debug printf shows that we got negative pause here:
ick: pause : -984
ick: pages_dirtied : 0
ick: task_ratelimit: 0
pause:
+ if (pause < 0) {
+ extern int printf(char *, ...);
+ printf("ick : pause : %li\n", pause);
+ printf("ick: pages_dirtied : %lu\n", pages_dirtied);
+ printf("ick: task_ratelimit: %lu\n", task_ratelimit);
+ BUG_ON(1);
+ }
trace_balance_dirty_pages(bdi,
Since pause is bounded by [min_pause, max_pause] where min_pause is also
bounded by max_pause. It's suspected and demonstrated that the
max_pause calculation goes wrong:
ick: pause : -717
ick: min_pause : -177
ick: max_pause : -717
ick: pages_dirtied : 14
ick: task_ratelimit: 0
The problem lies in the two "long = unsigned long" assignments in
bdi_max_pause() which might go negative if the highest bit is 1, and the
min_t(long, ...) check failed to protect it falling under 0. Fix all of
them by using "unsigned long" throughout the function.
Signed-off-by: Fengguang Wu <[email protected]>
Reported-by: Toralf Förster <[email protected]>
Tested-by: Toralf Förster <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
Cc: Richard Weinberger <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Buffer allocation has a very crude indefinite loop around waking the
flusher threads and performing global NOFS direct reclaim because it can
not handle allocation failures.
The most immediate problem with this is that the allocation may fail due
to a memory cgroup limit, where flushers + direct reclaim might not make
any progress towards resolving the situation at all. Because unlike the
global case, a memory cgroup may not have any cache at all, only
anonymous pages but no swap. This situation will lead to a reclaim
livelock with insane IO from waking the flushers and thrashing unrelated
filesystem cache in a tight loop.
Use __GFP_NOFAIL allocations for buffers for now. This makes sure that
any looping happens in the page allocator, which knows how to
orchestrate kswapd, direct reclaim, and the flushers sensibly. It also
allows memory cgroups to detect allocations that can't handle failure
and will allow them to ultimately bypass the limit if reclaim can not
make progress.
Reported-by: azurIt <[email protected]>
Signed-off-by: Johannes Weiner <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Commit 3812c8c8f3 ("mm: memcg: do not trap chargers with full
callstack on OOM") assumed that only a few places that can trigger a
memcg OOM situation do not return VM_FAULT_OOM, like optional page cache
readahead. But there are many more and it's impractical to annotate
them all.
First of all, we don't want to invoke the OOM killer when the failed
allocation is gracefully handled, so defer the actual kill to the end of
the fault handling as well. This simplifies the code quite a bit for
added bonus.
Second, since a failed allocation might not be the abrupt end of the
fault, the memcg OOM handler needs to be re-entrant until the fault
finishes for subsequent allocation attempts. If an allocation is
attempted after the task already OOMed, allow it to bypass the limit so
that it can quickly finish the fault and invoke the OOM killer.
Reported-by: azurIt <[email protected]>
Signed-off-by: Johannes Weiner <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
The err variable is intended to receive the timer_create() return before
checking it
Signed-off-by: Felipe Pena <[email protected]>
Cc: Frederic Weisbecker <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
In commit 27a7c64217 ("partitions/efi: account for pmbr size in lba")
we started treating bad sizes in lba field of the partition that has the
0xEE (GPT protective) as errors.
However, we may run into these "bad sizes" in the real world if someone
uses dd to copy an image from a smaller disk to a bigger disk. Since
this case used to work (even without using force_gpt), keep it working
and treat the size mismatch as a warning instead of an error.
Reported-by: Josh Triplett <[email protected]>
Reported-by: Sean Paul <[email protected]>
Signed-off-by: Doug Anderson <[email protected]>
Reviewed-by: Josh Triplett <[email protected]>
Acked-by: Davidlohr Bueso <[email protected]>
Tested-by: Artem Bityutskiy <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Commit 11feeb4980 ("kvm: optimize away THP checks in
kvm_is_mmio_pfn()") introduced a memory leak when KVM is run on gigantic
compound pages.
That commit depends on the assumption that PG_reserved is identical for
all head and tail pages of a compound page. So that if get_user_pages
returns a tail page, we don't need to check the head page in order to
know if we deal with a reserved page that requires different
refcounting.
The assumption that PG_reserved is the same for head and tail pages is
certainly correct for THP and regular hugepages, but gigantic hugepages
allocated through bootmem don't clear the PG_reserved on the tail pages
(the clearing of PG_reserved is done later only if the gigantic hugepage
is freed).
This patch corrects the gigantic compound page initialization so that we
can retain the optimization in 11feeb4980. The cacheline was already
modified in order to set PG_tail so this won't affect the boot time of
large memory systems.
[[email protected]: tweak comment layout and grammar]
Signed-off-by: Andrea Arcangeli <[email protected]>
Reported-by: andy123 <[email protected]>
Acked-by: Rik van Riel <[email protected]>
Cc: Gleb Natapov <[email protected]>
Cc: Mel Gorman <[email protected]>
Cc: Hugh Dickins <[email protected]>
Acked-by: Rafael Aquini <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
zswap_tree is not freed when swapoff, and it got re-kmalloced in swapon,
so a memory leak occurs.
Free the memory of zswap_tree in zswap_frontswap_invalidate_area().
Signed-off-by: Weijie Yang <[email protected]>
Reviewed-by: Bob Liu <[email protected]>
Cc: Minchan Kim <[email protected]>
Reviewed-by: Minchan Kim <[email protected]>
Cc: <[email protected]>
From: Weijie Yang <[email protected]>
Subject: mm/zswap: bugfix: memory leak when invalidate and reclaim occur concurrently
Consider the following scenario:
thread 0: reclaim entry x (get refcount, but not call zswap_get_swap_cache_page)
thread 1: call zswap_frontswap_invalidate_page to invalidate entry x.
finished, entry x and its zbud is not freed as its refcount != 0
now, the swap_map[x] = 0
thread 0: now call zswap_get_swap_cache_page
swapcache_prepare return -ENOENT because entry x is not used any more
zswap_get_swap_cache_page return ZSWAP_SWAPCACHE_NOMEM
zswap_writeback_entry do nothing except put refcount
Now, the memory of zswap_entry x and its zpage leak.
Modify:
- check the refcount in fail path, free memory if it is not referenced.
- use ZSWAP_SWAPCACHE_FAIL instead of ZSWAP_SWAPCACHE_NOMEM as the fail path
can be not only caused by nomem but also by invalidate.
[[email protected]: coding-style fixes]
Signed-off-by: Weijie Yang <[email protected]>
Reviewed-by: Bob Liu <[email protected]>
Cc: Minchan Kim <[email protected]>
Cc: <[email protected]>
Acked-by: Seth Jennings <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
We should clear the page's private flag when returing the page to the
hugepage pool. Otherwise, marked hugepage can be allocated to the user
who tries to allocate the non-reserved hugepage. If this user fail to
map this hugepage, he would try to return the page to the hugepage pool.
Since this page has a private flag, resv_huge_pages would mistakenly
increase. This patch fixes this situation.
Signed-off-by: Joonsoo Kim <[email protected]>
Cc: Rik van Riel <[email protected]>
Cc: Mel Gorman <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: "Aneesh Kumar K.V" <[email protected]>
Cc: KAMEZAWA Hiroyuki <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: Davidlohr Bueso <[email protected]>
Cc: David Gibson <[email protected]>
Cc: Wanpeng Li <[email protected]>
Cc: Naoya Horiguchi <[email protected]>
Cc: Hillf Danton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
After acquiring the semlock spinlock, operations must test that the
array is still valid.
- semctl() and exit_sem() would walk stale linked lists (ugly, but
should be ok: all lists are empty)
- semtimedop() would sleep forever - and if woken up due to a signal -
access memory after free.
The patch also:
- standardizes the tests for .deleted, so that all tests in one
function leave the function with the same approach.
- unconditionally tests for .deleted immediately after every call to
sem_lock - even it it means that for semctl(GETALL), .deleted will be
tested twice.
Both changes make the review simpler: After every sem_lock, there must
be a test of .deleted, followed by a goto to the cleanup code (if the
function uses "goto cleanup").
The only exception is semctl_down(): If sem_ids().rwsem is locked, then
the presence in ids->ipcs_idr is equivalent to !.deleted, thus no
additional test is required.
Signed-off-by: Manfred Spraul <[email protected]>
Cc: Mike Galbraith <[email protected]>
Acked-by: Davidlohr Bueso <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
for_each_online_cpu() needs the protection of {get,put}_online_cpus() so
cpu_online_mask doesn't change during the iteration.
cpu_hotplug.lock is held while a cpu is going down, it's a coarse lock
that is used kernel-wide to synchronize cpu hotplug activity. Memcg has
a cpu hotplug notifier, called while there may not be any cpu hotplug
refcounts, which drains per-cpu event counts to memcg->nocpu_base.events
to maintain a cumulative event count as cpus disappear. Without
get_online_cpus() in mem_cgroup_read_events(), it's possible to account
for the event count on a dying cpu twice, and this value may be
significantly large.
In fact, all memcg->pcp_counter_lock use should be nested by
{get,put}_online_cpus().
This fixes that issue and ensures the reported statistics are not vastly
over-reported during cpu hotplug.
Signed-off-by: David Rientjes <[email protected]>
Cc: Johannes Weiner <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: KAMEZAWA Hiroyuki <[email protected]>
Acked-by: KOSAKI Motohiro <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
When inserting a wrong value to /sys/devices/system/memory/memoryX/state file,
following messages are shown. And device_hotplug_lock is never released.
================================================
[ BUG: lock held when returning to user space! ]
3.12.0-rc4-debug+ #3 Tainted: G W
------------------------------------------------
bash/6442 is leaving the kernel with locks still held!
1 lock held by bash/6442:
#0: (device_hotplug_lock){+.+.+.}, at: [<ffffffff8146cbb5>] lock_device_hotplug_sysfs+0x15/0x50
This issue was introdued by commit fa2be40 (drivers: base: use standard
device online/offline for state change).
This patch releases device_hotplug_lcok when store_mem_state returns EINVAL.
Signed-off-by: Yasuaki Ishimatsu <[email protected]>
Reviewed-by: Toshi Kani <[email protected]>
CC: Seth Jennings <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Pull tmpfile fix from Al Viro:
"A fix for double iput() in ->tmpfile() on ext3 and ext4; I'd fucked it
up, Miklos has caught it"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
ext[34]: fix double put in tmpfile
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJSXfiQAAoJEK2W1qbAHj1nNXUP/1hVfXVIBMXNRmxrM9FJ1Rdj
Rg30aQK0qP6MkoPmjbdsPZmApq3uI++ihTPIhKQHrW70jjs1HsOAG5e9lHZXLx4b
mt3+1PNheLMf+J6zzdk1qyWYXmzs1XU/MzlhpmmkCydO0X8ONmri75FqwCZlOB0H
k/80Z8Q/3vva0pLsE5ubYlPiKoI1DPsUA9qO/Dkjh4QGDllsleVK5CjQPZiJJ4Ji
FkAeBYdo3BZ6ivUXx4MJRDu7N1992XhVWabwU0bEoNAj2IjHiwT0rwsNoWxOYIim
NsZFTboy/Aj3819w/QdqHKGEd4kd86MnxySkzK7/D57MRz6nqiwWGljGSIzth6ta
uqJB7wuq3s/1p4MVaEnaCpm0QzquNt3lgP7bXGx94Qwq9oxdgyL8ndZHQv1SpagC
gZT0PuFbg5XzpXt94XUeSODODnzG6SuBass5dxHHMrZdw/9hVPAavyyC+TcBIqLr
6+8N4monhhNkZDUiUHIlTzk0YrmUDVfFlI8D7gj9mDBPf+qJsjBp8L6LdZeq0ZWs
bC33oLQn/wEUv3Od1SQxMC34+xU65GT/raPg5H0xE0cRwKeloV7w9lKhiYLBbq5+
1sKFJ/rll2cwZhpQ6UombkTzjGWK1JfsMnRFkM4B248qwf/QR9BWwLnNMP3tryyl
smCkZ2DLncDKf7J8TN64
=NRC3
-----END PGP SIGNATURE-----
Merge tag 'dm-3.12-fix-cve' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device-mapper fix from Alasdair Kergon:
"A patch to avoid data corruption in a device-mapper snapshot.
This is primarily a data corruption bug that all users of
device-mapper snapshots will want to fix. The CVE is due to a data
leak under specific circumstances if, for example, the snapshot is
presented to a virtual machine: a block written as data inside the VM
can get interpreted incorrectly on the host outside the VM as
metadata, causing the host to provide the VM with access to blocks it
would not otherwise see. This is likely to affect few, if any,
people"
* tag 'dm-3.12-fix-cve' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm snapshot: fix data corruption
- A fix to the Lynxpoint IRQ handler
- Two late fixes to fallout from the gpiod refactoring
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJSXkvPAAoJEEEQszewGV1z+MUP/2ooJI2x0tm58NgJ34J1f+C4
+lI0KKdNLrF9blxzOM6yHO1HaMD5NF2h4TkY4c/6WeJNyOVfcGko8wYaqKFEi3pa
F30jn5wXFJfqMCP+lHKHQgqBfs+uYIt1jYuPcwu1ULkI8S1TGnU3p+9DuJuGDasD
1XzNuAHcOHQOaTA90D5qCTJDRBFZUVgeIOqtHbIng7dL3pTDJdDkybvd2d+W7wKK
+r/UpMTuxortVwcNfCRoI1lArnq+01cxwHhDSAuY7O0UujaQks34GWF4gIuKL0Kn
PhXWLYQBzOKafVUdgzyyxFxw+F8dqpm8DaUZ3sKTXsa07IHMyqfSa6iUtJClqcZS
+ukIdyL6nOAQVfNpyOGklaGcAhY5HFeYrrRmF9rxAygX9k4C0blbPNrL3vl5PrjH
fiUu8pdyB4THzN1BsAjx4JTrzWyEr5ZIY+FuoTBQTUMcl3NfQ9US7wJPTqXH3217
I6vOcxo4xohe4VWExg3yVZJ0QOjSvYzaiuv6n40zZi/oxymDnD/huuFpVs3u/5+X
4C5zpfZweNYnwHiUGl6dVMfenTGVY8MWcg1fQumsBfa2Rb3BJT5JdxeRGtg/muFN
n6jm3kzr6F5VVBG5o6aKtEjnxdSncjXX9U85EDpFv4Hrf5fXRKwV+1rhXD3akj6D
FcpwXlCt0Zf3YXlabbMM
=SG11
-----END PGP SIGNATURE-----
Merge tag 'gpio-v3.12-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull gpio fixes from Linus Walleij:
"Three GPIO fixes for the v3.12 series:
- A fix to the Lynxpoint IRQ handler
- Two late fixes to fallout from the gpiod refactoring"
* tag 'gpio-v3.12-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpiolib: let gpiod_request() return -EPROBE_DEFER
gpiolib: safer implementation of desc_to_gpio()
gpio/lynxpoint: check if the interrupt is enabled in IRQ handler
The index field of cpufreq_frequency_table has been renamed to
driver_data by commit 5070158 (cpufreq: rename index as driver_data
in cpufreq_frequency_table).
This patch updates the s3c64xx driver to match.
Signed-off-by: Charles Keepax <[email protected]>
Cc: 3.11+ <[email protected]> # 3.11+
Signed-off-by: Rafael J. Wysocki <[email protected]>
The mechanism causing devices depending on a given power resource
(that is, devices that can be in D0 only if that power resource is
on) to be resumed automatically when the power resource is turned
on (and their "inferred" power state becomes D0 as a result) is
inherently racy and in fact unnecessary.
It is racy, because if the power resource is turned on and then
immediately off, the device resume triggered by the first transition
to "on" may still happen, causing the power resource to be turned
on again. That again will trigger the "resume of dependent devices"
mechanism, but if the devices in question are not in use, they will
be suspended in the meantime causing the power resource to be turned
off. However, the "resume of dependent devices" will next resume
them again and so on. In some cases (USB port PM in particular) that
leads to an endless busy loop of flipping the resource on and off
continuously.
It is needless, because whoever turns a power resource on will most
likely turn it off at some point and the devices that go into "D0"
as a result of turning it on will then go back into D3cold
(generally, the state they were in before).
Moreover, turning on all power resources a device needs to go into
D0 is not sufficient for a full transition into D0 in general.
Namely, _PS0 may need to be executed in addition to that in some
cases. This means that the whole rationale of the "resume of
dependent devices" mechanism was incorrect to begin with and it's
best to remove it entirely.
Signed-off-by: Rafael J. Wysocki <[email protected]>
The expression in line 398 of intel_pstate.c causes the following
warning to be emitted:
drivers/cpufreq/intel_pstate.c:398:3: warning: left shift count >= width of type
which happens because unsigned long is 32-bit on some architectures.
Fix that by using a helper u64 variable and simplify the code
slightly.
Tested-by: Srinivas Pandruvada <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Rescind of subchannels were not being correctly handled. Fix the bug.
Signed-off-by: K. Y. Srinivasan <[email protected]>
Cc: <[email protected]> [3.11+]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The USB3503 driver had an incorrect depedency on REGMAP, instead of
REGMAP_I2C. This caused the build to fail since the necessary regmap
i2c pieces were not available.
Signed-off-by: Matthew Dawson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
When CMA fails to initialize in v3.12-rc4, the chipidea driver oopses
the kernel while trying to remove and put the HCD which doesn't exist:
WARNING: CPU: 0 PID: 6 at /home/rmk/git/linux-rmk/arch/arm/mm/dma-mapping.c:511
__dma_alloc+0x200/0x240()
coherent pool not initialised!
Modules linked in:
CPU: 0 PID: 6 Comm: kworker/u2:0 Tainted: G W 3.12.0-rc4+ #56
Workqueue: deferwq deferred_probe_work_func
Backtrace:
[<c001218c>] (dump_backtrace+0x0/0x10c) from [<c0012328>] (show_stack+0x18/0x1c)
r6:c05fd9cc r5:000001ff r4:00000000 r3:df86ad00
[<c0012310>] (show_stack+0x0/0x1c) from [<c05f3a4c>] (dump_stack+0x70/0x8c)
[<c05f39dc>] (dump_stack+0x0/0x8c) from [<c00230a8>] (warn_slowpath_common+0x6c/0x8c)
r4:df883a60 r3:df86ad00
[<c002303c>] (warn_slowpath_common+0x0/0x8c) from [<c002316c>] (warn_slowpath_fmt+0x38/0x40)
r8:ffffffff r7:00001000 r6:c083b808 r5:00000000 r4:df2efe80
[<c0023134>] (warn_slowpath_fmt+0x0/0x40) from [<c00196bc>] (__dma_alloc+0x200/0x240)
r3:00000000 r2:c05fda00
[<c00194bc>] (__dma_alloc+0x0/0x240) from [<c001982c>] (arm_dma_alloc+0x88/0xa0)
[<c00197a4>] (arm_dma_alloc+0x0/0xa0) from [<c03e2904>] (ehci_setup+0x1f4/0x438)
[<c03e2710>] (ehci_setup+0x0/0x438) from [<c03cbd60>] (usb_add_hcd+0x18c/0x664)
[<c03cbbd4>] (usb_add_hcd+0x0/0x664) from [<c03e89f4>] (host_start+0xf0/0x180)
[<c03e8904>] (host_start+0x0/0x180) from [<c03e7c34>] (ci_hdrc_probe+0x360/0x670
)
r6:df2ef410 r5:00000000 r4:df2c3010 r3:c03e8904
[<c03e78d4>] (ci_hdrc_probe+0x0/0x670) from [<c0311044>] (platform_drv_probe+0x20/0x24)
[<c0311024>] (platform_drv_probe+0x0/0x24) from [<c030fcac>] (driver_probe_device+0x9c/0x234)
...
---[ end trace c88ccaf3969e8422 ]---
Unable to handle kernel NULL pointer dereference at virtual address 00000028
pgd = c0004000
[00000028] *pgd=00000000
Internal error: Oops: 17 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 6 Comm: kworker/u2:0 Tainted: G W 3.12.0-rc4+ #56
Workqueue: deferwq deferred_probe_work_func
task: df86ad00 ti: df882000 task.ti: df882000
PC is at usb_remove_hcd+0x10/0x150
LR is at host_stop+0x1c/0x3c
pc : [<c03cacec>] lr : [<c03e88e4>] psr: 60000013
sp : df883b50 ip : df883b78 fp : df883b74
r10: c11f4c54 r9 : c0836450 r8 : df30c400
r7 : fffffff4 r6 : df2ef410 r5 : 00000000 r4 : df2c3010
r3 : 00000000 r2 : 00000000 r1 : df86b0a0 r0 : 00000000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c53c7d Table: 2f29404a DAC: 00000015
Process kworker/u2:0 (pid: 6, stack limit = 0xdf882240)
Stack: (0xdf883b50 to 0xdf884000)
...
Backtrace:
[<c03cacdc>] (usb_remove_hcd+0x0/0x150) from [<c03e88e4>] (host_stop+0x1c/0x3c)
r6:df2ef410 r5:00000000 r4:df2c3010
[<c03e88c8>] (host_stop+0x0/0x3c) from [<c03e8aa0>] (ci_hdrc_host_destroy+0x1c/0x20)
r5:00000000 r4:df2c3010
[<c03e8a84>] (ci_hdrc_host_destroy+0x0/0x20) from [<c03e7c80>] (ci_hdrc_probe+0x3ac/0x670)
[<c03e78d4>] (ci_hdrc_probe+0x0/0x670) from [<c0311044>] (platform_drv_probe+0x20/0x24)
[<c0311024>] (platform_drv_probe+0x0/0x24) from [<c030fcac>] (driver_probe_device+0x9c/0x234)
[<c030fc10>] (driver_probe_device+0x0/0x234) from [<c030ff28>] (__device_attach+0x44/0x48)
...
---[ end trace c88ccaf3969e8423 ]---
Fix this so at least we can continue booting and get to a shell prompt.
Signed-off-by: Russell King <[email protected]>
Tested-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Some USB drive enclosures do not correctly report an
overflow condition if they hold a drive with a capacity
over 2TB and are confronted with a READ_CAPACITY_10.
They answer with their capacity modulo 2TB.
The generic layer cannot cope with that. It must be told
to use READ_CAPACITY_16 from the beginning.
Signed-off-by: Oliver Neukum <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Interface 6 of this device speaks QMI as per tests done by us.
Credits go to Antonella for providing the hardware.
Signed-off-by: Enrico Mioso <[email protected]>
Signed-off-by: Antonella Pellizzari <[email protected]>
Tested-by: Dan Williams <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Due to missing braces on an if statement, in presence of a device_node a
port was always assigned -1, regardless of any alias entries in the
device tree. Conversely, if device_node was NULL, an unitialized port
ended up being used.
This patch adds the missing braces, fixing the issues.
Signed-off-by: Roel Kluin <[email protected]>
Acked-by: Tony Prisk <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
In GCC the sizeof(hdsp_version) is 8 because there is a 2 byte hole at
the end of the struct after ->firmware_rev.
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
This patch fixes a particular type of data corruption that has been
encountered when loading a snapshot's metadata from disk.
When we allocate a new chunk in persistent_prepare, we increment
ps->next_free and we make sure that it doesn't point to a metadata area
by further incrementing it if necessary.
When we load metadata from disk on device activation, ps->next_free is
positioned after the last used data chunk. However, if this last used
data chunk is followed by a metadata area, ps->next_free is positioned
erroneously to the metadata area. A newly-allocated chunk is placed at
the same location as the metadata area, resulting in data or metadata
corruption.
This patch changes the code so that ps->next_free skips the metadata
area when metadata are loaded in function read_exceptions.
The patch also moves a piece of code from persistent_prepare_exception
to a separate function skip_metadata to avoid code duplication.
CVE-2013-4299
Signed-off-by: Mikulas Patocka <[email protected]>
Cc: [email protected]
Cc: Mike Snitzer <[email protected]>
Signed-off-by: Alasdair G Kergon <[email protected]>
BugLink: http://bugs.launchpad.net/bugs/1235977
The profile introspection seq file has a locking bug when policy is viewed
from a virtual root (task in a policy namespace), introspection from the
real root is not affected.
The test for root
while (parent) {
is correct for the real root, but incorrect for tasks in a policy namespace.
This allows the task to walk backup the policy tree past its virtual root
causing it to be unlocked before the virtual root should be in the p_stop
fn.
This results in the following lockdep back trace:
[ 78.479744] [ BUG: bad unlock balance detected! ]
[ 78.479792] 3.11.0-11-generic #17 Not tainted
[ 78.479838] -------------------------------------
[ 78.479885] grep/2223 is trying to release lock (&ns->lock) at:
[ 78.479952] [<ffffffff817bf3be>] mutex_unlock+0xe/0x10
[ 78.480002] but there are no more locks to release!
[ 78.480037]
[ 78.480037] other info that might help us debug this:
[ 78.480037] 1 lock held by grep/2223:
[ 78.480037] #0: (&p->lock){+.+.+.}, at: [<ffffffff812111bd>] seq_read+0x3d/0x3d0
[ 78.480037]
[ 78.480037] stack backtrace:
[ 78.480037] CPU: 0 PID: 2223 Comm: grep Not tainted 3.11.0-11-generic #17
[ 78.480037] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 78.480037] ffffffff817bf3be ffff880007763d60 ffffffff817b97ef ffff8800189d2190
[ 78.480037] ffff880007763d88 ffffffff810e1c6e ffff88001f044730 ffff8800189d2190
[ 78.480037] ffffffff817bf3be ffff880007763e00 ffffffff810e5bd6 0000000724fe56b7
[ 78.480037] Call Trace:
[ 78.480037] [<ffffffff817bf3be>] ? mutex_unlock+0xe/0x10
[ 78.480037] [<ffffffff817b97ef>] dump_stack+0x54/0x74
[ 78.480037] [<ffffffff810e1c6e>] print_unlock_imbalance_bug+0xee/0x100
[ 78.480037] [<ffffffff817bf3be>] ? mutex_unlock+0xe/0x10
[ 78.480037] [<ffffffff810e5bd6>] lock_release_non_nested+0x226/0x300
[ 78.480037] [<ffffffff817bf2fe>] ? __mutex_unlock_slowpath+0xce/0x180
[ 78.480037] [<ffffffff817bf3be>] ? mutex_unlock+0xe/0x10
[ 78.480037] [<ffffffff810e5d5c>] lock_release+0xac/0x310
[ 78.480037] [<ffffffff817bf2b3>] __mutex_unlock_slowpath+0x83/0x180
[ 78.480037] [<ffffffff817bf3be>] mutex_unlock+0xe/0x10
[ 78.480037] [<ffffffff81376c91>] p_stop+0x51/0x90
[ 78.480037] [<ffffffff81211408>] seq_read+0x288/0x3d0
[ 78.480037] [<ffffffff811e9d9e>] vfs_read+0x9e/0x170
[ 78.480037] [<ffffffff811ea8cc>] SyS_read+0x4c/0xa0
[ 78.480037] [<ffffffff817ccc9d>] system_call_fastpath+0x1a/0x1f
Signed-off-by: John Johansen <[email protected]>
Signed-off-by: James Morris <[email protected]>
One bug fix and three reverts. The reverts back out the slightly
controversial feeding the entire device tree into the random pool and
the reserved-memory binding which isn't fully baked yet. Expect the
reserved-memory patches at least to resurface for v3.13. The bug fixes
removes a scary but harmless warning on SPARC that was introduced in the
v3.12 merge window. v3.13 will contain a proper fix that makes the new
code work on SPARC.
On the plus side, the diffstat looks *awesome*. I love removing lines of code.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAABAgAGBQJSXbO9AAoJEJZcAETA+ZUxuH4IAI/KF71fq0/O7en7GHo6ofcZ
3nA3fUyYpnjehaqmKDXxix4TUgKTYU1ZP6tn8VfM6fn0QthR2YXPYAqiIaRot3ab
arCPvJ9N52CU04Ug8dqMPEuFlSqRfTYc0EVPTbdgv8GYWX+rjP4qmOWS13exorai
hJSRFmbyvwOVvRAl7KtkBPEZ3ri40mfkTrMs61v55GajhaZFyoTQgMMNhboUskI7
qztWiecw1stlvbfQEoN+BA11ohp5kDf4d5jeTCMNFx81liBbZHYfwWbmwYPCH7/z
6s4gX6PQeCuygdhQK65q1tYebTmRbFxkuf8P/tO7lEpmR3fKIVBr+oMJff0q9ww=
=8W6e
-----END PGP SIGNATURE-----
Merge tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux
Pull device tree fixes and reverts from Grant Likely:
"One bug fix and three reverts. The reverts back out the slightly
controversial feeding the entire device tree into the random pool and
the reserved-memory binding which isn't fully baked yet. Expect the
reserved-memory patches at least to resurface for v3.13.
The bug fixes removes a scary but harmless warning on SPARC that was
introduced in the v3.12 merge window. v3.13 will contain a proper fix
that makes the new code work on SPARC.
On the plus side, the diffstat looks *awesome*. I love removing lines
of code"
* tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux:
Revert "drivers: of: add initialization code for dma reserved memory"
Revert "ARM: init: add support for reserved memory defined by device tree"
Revert "of: Feed entire flattened device tree into the random pool"
of: fix unnecessary warning on missing /cpus node
Pull DMA-mapping fix from Marek Szyprowski:
"A bugfix for the IOMMU-based implementation of dma-mapping subsystem
for ARM architecture"
* 'fixes-for-v3.12' of git://git.linaro.org/people/mszyprowski/linux-dma-mapping:
ARM: dma-mapping: Always pass proper prot flags to iommu_map()
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJSXSSbAAoJEIlPj0hw4a6QkIoQAMe69LtP8x4l7ZfgqT/QxwHK
COGw+KpPXZPxASpCJO9aTXW/Mr54X9BpC4if6OmpRA6BXyU2sTrp2TIeuPbZCFvg
DjFy4g6Snd9yvb0FPbIcUbMbUZUWmLA05PstUZV+FNub2l9ie7WWzfjyVNQv/izA
AJ6J5GDSPxHegoygeBCCrn0Qc5rgN6soxhRDndmVGLxlBNRs71ORojRMGUrWY2X/
OhxSj97hCXZHZyaQBI2JfuNzmFAVGvdLVN3NGzROKK1u8zKGn1I1kL39OU1QkCHZ
iUmBeJt7jzetS85XcDxCzcErWs6K6HjFqiSF1tC6GGOtX73oqNqV4weIzNSdO+lc
tLUGDfJSJdaVB6tNoGsywqx380CHyJi6WjUR21o2RSW8TtsNrzkpqLE0Aqv84tnl
dyTgykzmpKhtmchjHHO4mGDioCRDYLcok3gol2IRc6P+BYXzHgwvWkH/TWMhvVjK
IHGTd+cuUqrs7MmuxGZ/kQiqV6OegdFZYrW6E6vulITUMWNPxUaXFBu9njzrMxGt
2bLeC+xDTi2BW9ihaln+zVUxmHZ2TLq6fHMZ/XTWrwGNNdUhKU/jNIWqC25MxSX8
vOVnCLvT+AqqSU82ng3JL5LvnZFGlAd/cUdVEdo723xRNz6OgWLbrhi7Pq/OkjIJ
9VKoA3zX8mgiMl1Wgp9t
=wJOk
-----END PGP SIGNATURE-----
Merge tag 'stable/for-linus-3.12-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull Xen fixes from Stefano Stabellini:
"A small fix for Xen on x86_32 and a build fix for xen-tpmfront on
arm64"
* tag 'stable/for-linus-3.12-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
xen: Fix possible user space selector corruption
tpm: xen-tpmfront: fix missing declaration of xen_domain
Commit 1696d9d (ACPI: Remove the old /proc/acpi/event interface)
left /proc/acpi/event in the ACPI_BUTTON help in Kconfig, so
remove it from there.
[rjw: Changelog]
Signed-off-by: Krzysztof Mazur <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
In acpi_resume_power_resources() resource_lock should be released
when acpi_power_get_state() fails and before passing to next power
resource on the list.
Signed-off-by: Lan Tianyu <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Usually the active scan mask is freed in __iio_update_buffers() when the buffer
is disabled. But when the device is still sampling when it is removed we'll end
up disabling the buffers in iio_disable_all_buffers(). So we also need to free
the active scan mask here, otherwise it will be leaked.
Signed-off-by: Lars-Peter Clausen <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
We use jump label to enable pv-spinlock. With the changes in (442e0973e9
Merge branch 'x86/jumplabel'), the jump label behaviour has changed
that would result in eventual hang of the VM since we would end up in a
situation where slow path locks would halt the vcpus but we will not be
able to wakeup the vcpu by lock releaser using unlock kick.
Similar problem in Xen and more detailed description is available in
a945928ea2 (xen: Do not enable spinlocks before jump_label_init()
has executed)
This patch splits kvm_spinlock_init to separate jump label changes with
pvops patching and also make jump label enabling after jump_label_init().
Signed-off-by: Raghavendra K T <[email protected]>
Reviewed-by: Paolo Bonzini <[email protected]>
Reviewed-by: Steven Rostedt <[email protected]>
Signed-off-by: Gleb Natapov <[email protected]>
The pcm_usb_stream plugin requires the mremap explicitly for the read
buffer, as it expands itself once after reading the required size.
But the commit [314e51b9: mm: kill vma flag VM_RESERVED and
mm->reserved_vm counter] converted blindly to a combination of
VM_DONTEXPAND | VM_DONTDUMP like other normal drivers, and this
resulted in the failure of mremap().
For fixing this regression, we need to remove VM_DONTEXPAND for the
read-buffer mmap.
Reported-and-tested-by: James Miller <[email protected]>
Cc: <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
This reverts commit 9d8eab7af7. There is
still no consensus on the bindings for the reserved memory and various
drawbacks of the proposed solution has been shown, so the best now is to
revert it completely and start again from scratch later.
Signed-off-by: Marek Szyprowski <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
