Axel Lin [Mon, 6 May 2013 09:03:32 +0000 (17:03 +0800)]
irqchip: renesas-irqc: Fix irqc_probe error handling
commit
dfaf820a13ec160f06556e08dab423818ba87f14 upstream.
The code in goto err3 path is wrong because it will call fee_irq() with k == 0,
which means it does free_irq(p->irq[-1].requested_irq, &p->irq[-1]);
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Thu, 9 Jan 2014 20:25:15 +0000 (12:25 -0800)]
Linux 3.10.26
Nobuhiro Iwamatsu [Thu, 2 Jan 2014 20:58:53 +0000 (12:58 -0800)]
sh: add EXPORT_SYMBOL(min_low_pfn) and EXPORT_SYMBOL(max_low_pfn) to sh_ksyms_32.c
commit
ad70b029d2c678386384bd72c7fa2705c449b518 upstream.
Min_low_pfn and max_low_pfn were used in pfn_valid macro if defined
CONFIG_FLATMEM. When the functions that use the pfn_valid is used in
driver module, max_low_pfn and min_low_pfn is to undefined, and fail to
build.
ERROR: "min_low_pfn" [drivers/block/aoe/aoe.ko] undefined!
ERROR: "max_low_pfn" [drivers/block/aoe/aoe.ko] undefined!
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
This patch fix this problem.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@gmail.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Whitney [Mon, 6 Jan 2014 19:00:23 +0000 (14:00 -0500)]
ext4: fix bigalloc regression
commit
d0abafac8c9162f39c4f6b2f8141b772a09b3770 upstream.
Commit
f5a44db5d2 introduced a regression on filesystems created with
the bigalloc feature (cluster size > blocksize). It causes xfstests
generic/006 and /013 to fail with an unexpected JBD2 failure and
transaction abort that leaves the test file system in a read only state.
Other xfstests run on bigalloc file systems are likely to fail as well.
The cause is the accidental use of a cluster mask where a cluster
offset was needed in ext4_ext_map_blocks().
Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Catalin Marinas [Fri, 29 Nov 2013 10:56:14 +0000 (10:56 +0000)]
arm64: Use Normal NonCacheable memory for writecombine
commit
4f00130b70e5eee813cc7bc298e0f3fdf79673cc upstream.
This provides better performance compared to Device GRE and also allows
unaligned accesses. Such memory is intended to be used with standard RAM
(e.g. framebuffers) and not I/O.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Catalin Marinas [Wed, 1 May 2013 15:34:22 +0000 (16:34 +0100)]
arm64: Do not flush the D-cache for anonymous pages
commit
7249b79f6b4cc3c2aa9138dca52e535a4c789107 upstream.
The D-cache on AArch64 is VIPT non-aliasing, so there is no need to
flush it for anonymous pages.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Reported-by: Will Deacon <will.deacon@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Catalin Marinas [Wed, 1 May 2013 11:23:05 +0000 (12:23 +0100)]
arm64: Avoid cache flushing in flush_dcache_page()
commit
b5b6c9e9149d8a7c3f1d7b9d0c046c6184e1dd17 upstream.
The flush_dcache_page() function is called when the kernel modified a
page cache page. Since the D-cache on AArch64 does not have aliases
this function can simply mark the page as dirty for later flushing via
set_pte_at()/__sync_icache_dcache() if the page is executable (to ensure
the I-D cache coherency).
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Reported-by: Will Deacon <will.deacon@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Rutland [Tue, 26 Mar 2013 13:41:35 +0000 (13:41 +0000)]
ARM: KVM: arch_timers: zero CNTVOFF upon return to host
commit
f793c23ebbe5afd1cabf4a42a3a297022213756f upstream.
To use the virtual counters from the host, we need to ensure that
CNTVOFF doesn't change unexpectedly. When we change to a guest, we
replace the host's CNTVOFF, but we don't restore it when returning to
the host.
As the host sets CNTVOFF to zero, and never changes it, we can simply
zero CNTVOFF when returning to the host. This patch adds said zeroing to
the return to host path.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Christoffer Dall <cdall@cs.columbia.edu>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Zyngier [Wed, 30 Jan 2013 18:17:49 +0000 (18:17 +0000)]
ARM: hyp: initialize CNTVOFF to zero
commit
0af0b189abf73d232af782df2f999235cd2fed7f upstream.
In order to be able to use the virtual counter in a safe way,
make sure it is initialized to zero before dropping to SVC.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Dave Martin <dave.martin@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Rutland [Wed, 30 Jan 2013 17:51:26 +0000 (17:51 +0000)]
clocksource: arch_timer: use virtual counters
commit
0d651e4e65e96989f72236bf83bd4c6e55eb6ce4 upstream.
Switching between reading the virtual or physical counters is
problematic, as some core code wants a view of time before we're fully
set up. Using a function pointer and switching the source after the
first read can make time appear to go backwards, and having a check in
the read function is an unfortunate block on what we want to be a fast
path.
Instead, this patch makes us always use the virtual counters. If we're a
guest, or don't have hyp mode, we'll use the virtual timers, and as such
don't care about CNTVOFF as long as it doesn't change in such a way as
to make time appear to travel backwards. As the guest will use the
virtual timers, a (potential) KVM host must use the physical timers
(which can wake up the host even if they fire while a guest is
executing), and hence a host must have CNTVOFF set to zero so as to have
a consistent view of time between the physical timers and virtual
counters.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Catalin Marinas [Mon, 2 Sep 2013 15:33:54 +0000 (16:33 +0100)]
arm64: Remove unused cpu_name ascii in arch/arm64/mm/proc.S
commit
f3a1d7d53dccf51959aec16b574617cc6bfeca09 upstream.
This string has been moved to arch/arm64/kernel/cputable.c.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Catalin Marinas [Thu, 14 Nov 2013 15:15:37 +0000 (15:15 +0000)]
arm64: dts: Reserve the memory used for secondary CPU release address
commit
df503ba7f653c590b475ab80bde788edf5af70d5 upstream.
With the spin-table SMP booting method, secondary CPUs poll a location
passed in the DT. The foundation-v8.dts file doesn't have this memory
reserved and there is a risk of Linux using it before secondary CPUs are
started.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
AKASHI Takahiro [Thu, 3 Oct 2013 05:47:44 +0000 (06:47 +0100)]
arm64: check for number of arguments in syscall_get/set_arguments()
commit
7b22c03536a539142f931815528d55df455ffe2d upstream.
In ftrace_syscall_enter(),
syscall_get_arguments(..., 0, n, ...)
if (i == 0) { <handle orig_x0> ...; n--;}
memcpy(..., n * sizeof(args[0]));
If 'number of arguments(n)' is zero and 'argument index(i)' is also zero in
syscall_get_arguments(), none of arguments should be copied by memcpy().
Otherwise 'n--' can be a big positive number and unexpected amount of data
will be copied. Tracing system calls which take no argument, say sync(void),
may hit this case and eventually make the system corrupted.
This patch fixes the issue both in syscall_get_arguments() and
syscall_set_arguments().
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiang Liu [Fri, 27 Sep 2013 08:04:41 +0000 (09:04 +0100)]
arm64: fix possible invalid FPSIMD initialization state
commit
6db83cea1c975b9a102e17def7d2795814e1ae2b upstream.
If context switching happens during executing fpsimd_flush_thread(),
stale value in FPSIMD registers will be saved into current thread's
fpsimd_state by fpsimd_thread_switch(). That may cause invalid
initialization state for the new process, so disable preemption
when executing fpsimd_flush_thread().
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Cc: Jiang Liu <liuj97@gmail.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Feng Kan [Tue, 23 Jul 2013 17:52:31 +0000 (18:52 +0100)]
arm64: Change kernel stack size to 16K
commit
845ad05ec31e0f3872a321e10dbeaf872022632c upstream.
Written by Catalin Marinas, tested by APM on storm platform. This is needed
because of the failures encountered when running SpecWeb benchmark test.
Signed-off-by: Feng Kan <fkan@apm.com>
Acked-by: Kumar Sankaran <ksankaran@apm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Rutland [Tue, 9 Jul 2013 14:16:06 +0000 (15:16 +0100)]
arm64: virt: ensure visibility of __boot_cpu_mode
commit
82b2f495fba338d1e3098dde1df54944a9c19751 upstream.
Secondary CPUs write to __boot_cpu_mode with caches disabled, and thus a
cached value of __boot_cpu_mode may be incoherent with that in memory.
This could lead to a failure to detect mismatched boot modes.
This patch adds flushing to ensure that writes by secondaries to
__boot_cpu_mode are made visible before we test against it.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Christoffer Dall <cdall@cs.columbia.edu>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Catalin Marinas [Fri, 19 Jul 2013 14:08:15 +0000 (15:08 +0100)]
arm64: Only enable local interrupts after the CPU is marked online
commit
53ae3acd4390ffeecb3a11dbd5be347b5a3d98f2 upstream.
There is a slight chance that (timer) interrupts are triggered before a
secondary CPU has been marked online with implications on softirq thread
affinity.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Reported-by: Kirill Tkhai <tkhai@yandex.ru>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josh Durgin [Thu, 5 Sep 2013 00:57:31 +0000 (17:57 -0700)]
rbd: fix error handling from rbd_snap_name()
commit
da6a6b63978d45f9ae582d1f362f182012da3a22 upstream.
rbd_snap_name() calls rbd_dev_v{1,2}_snap_name() depending on the
format of the image. The format 1 version returns NULL on error, which
is handled by the caller. The format 2 version returns an ERR_PTR,
which the caller of rbd_snap_name() does not expect.
Fortunately this is unlikely to occur in practice because
rbd_snap_id_by_name() is called before rbd_snap_name(). This would hit
similar errors to rbd_snap_name() (like the snapshot not existing) and
return early, so rbd_snap_name() would not hit an error unless the
snapshot was removed between the two calls or memory was exhausted.
Use an ERR_PTR in rbd_dev_v1_snap_name() so that the specific error
can be propagated, and it is consistent with rbd_dev_v2_snap_name().
Handle the ERR_PTR in the only rbd_snap_name() caller.
Suggested-by: Alex Elder <alex.elder@linaro.org>
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josh Durgin [Fri, 30 Aug 2013 02:16:42 +0000 (19:16 -0700)]
rbd: ignore unmapped snapshots that no longer exist
commit
efadc98aab674153709cc357ba565f04e3164fcd upstream.
This prevents erroring out while adding a device when a snapshot
unrelated to the current mapping is deleted between reading the
snapshot context and reading the snapshot names. If the mapped
snapshot name is not found an error still occurs as usual.
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josh Durgin [Fri, 30 Aug 2013 00:26:31 +0000 (17:26 -0700)]
rbd: fix use-after free of rbd_dev->disk
commit
9875201e10496612080e7d164acc8f625c18725c upstream.
Removing a device deallocates the disk, unschedules the watch, and
finally cleans up the rbd_dev structure. rbd_dev_refresh(), called
from the watch callback, updates the disk size and rbd_dev
structure. With no locking between them, rbd_dev_refresh() may use the
device or rbd_dev after they've been freed.
To fix this, check whether RBD_DEV_FLAG_REMOVING is set before
updating the disk size in rbd_dev_refresh(). In order to prevent a
race where rbd_dev_refresh() is already revalidating the disk when
rbd_remove() is called, move the call to rbd_bus_del_dev() after the
watch is unregistered and all notifies are complete. It's safe to
defer deleting this structure because no new requests can be submitted
once the RBD_DEV_FLAG_REMOVING is set, since the device cannot be
opened.
Fixes: http://tracker.ceph.com/issues/5636
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josh Durgin [Fri, 30 Aug 2013 00:36:03 +0000 (17:36 -0700)]
rbd: make rbd_obj_notify_ack() synchronous
commit
20e0af67ce88c657d0601977b9941a2256afbdaa upstream.
The only user of rbd_obj_notify_ack() is rbd_watch_cb(). It used
asynchronously with no tracking of when the notify ack completes, so
it may still be in progress when the osd_client is shut down. This
results in a BUG() since the osd client assumes no requests are in
flight when it stops. Since all notifies are flushed before the
osd_client is stopped, waiting for the notify ack to complete before
returning from the watch callback ensures there are no notify acks in
flight during shutdown.
Rename rbd_obj_notify_ack() to rbd_obj_notify_ack_sync() to reflect
its new synchronous nature.
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josh Durgin [Fri, 30 Aug 2013 00:31:03 +0000 (17:31 -0700)]
rbd: complete notifies before cleaning up osd_client and rbd_dev
commit
9abc59908e0c5f983aaa91150da32d5b62cf60b7 upstream.
To ensure rbd_dev is not used after it's released, flush all pending
notify callbacks before calling rbd_dev_image_release(). No new
notifies can be added to the queue at this point because the watch has
already be unregistered with the osd_client.
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josh Durgin [Thu, 29 Aug 2013 04:43:09 +0000 (21:43 -0700)]
libceph: add function to ensure notifies are complete
commit
dd935f44a40f8fb02aff2cc0df2269c92422df1c upstream.
Without a way to flush the osd client's notify workqueue, a watch
event that is unregistered could continue receiving callbacks
indefinitely.
Unregistering the event simply means no new notifies are added to the
queue, but there may still be events in the queue that will call the
watch callback for the event. If the queue is flushed after the event
is unregistered, the caller can be sure no more watch callbacks will
occur for the canceled watch.
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josh Durgin [Thu, 29 Aug 2013 00:08:10 +0000 (17:08 -0700)]
rbd: fix null dereference in dout
commit
c35455791c1131e7ccbf56ea6fbdd562401c2ce2 upstream.
The order parameter is sometimes NULL in _rbd_dev_v2_snap_size(), but
the dout() always derefences it. Move this to another dout() protected
by a check that order is non-NULL.
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Reviewed-by: Alex Elder <alex.elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josh Durgin [Tue, 27 Aug 2013 21:45:46 +0000 (14:45 -0700)]
rbd: fix buffer size for writes to images with snapshots
commit
03507db631c94a48e316c7f638ffb2991544d617 upstream.
rbd_osd_req_create() needs to know the snapshot context size to create
a buffer large enough to send it with the message front. It gets this
from the img_request, which was not set for the obj_request yet. This
resulted in trying to write past the end of the front payload, hitting
this BUG:
libceph: BUG_ON(p > msg->front.iov_base + msg->front.iov_len);
Fix this by associating the obj_request with its img_request
immediately after it's created, before the osd request is created.
Fixes: http://tracker.ceph.com/issues/5760
Suggested-by: Alex Elder <alex.elder@linaro.org>
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Reviewed-by: Alex Elder <alex.elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
majianpeng [Wed, 21 Aug 2013 07:02:51 +0000 (15:02 +0800)]
ceph: allow sync_read/write return partial successed size of read/write.
commit
ee7289bfadda5f4ef60884547ebc9989c8fb314a upstream.
For sync_read/write, it may do multi stripe operations.If one of those
met erro, we return the former successed size rather than a error value.
There is a exception for write-operation met -EOLDSNAPC.If this occur,we
retry the whole write again.
Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
majianpeng [Tue, 6 Aug 2013 08:20:38 +0000 (16:20 +0800)]
ceph: fix bugs about handling short-read for sync read mode.
commit
02ae66d8b229708fd94b764f6c17ead1c7741fcf upstream.
cephfs . show_layout
>layyout.data_pool: 0
>layout.object_size:
4194304
>layout.stripe_unit:
4194304
>layout.stripe_count: 1
TestA:
>dd if=/dev/urandom of=test bs=1M count=2 oflag=direct
>dd if=/dev/urandom of=test bs=1M count=2 seek=4 oflag=direct
>dd if=test of=/dev/null bs=6M count=1 iflag=direct
The messages from func striped_read are:
ceph: file.c:350 : striped_read 0~
6291456 (read 0) got
2097152 HITSTRIPE SHORT
ceph: file.c:350 : striped_read
2097152~
4194304 (read
2097152) got 0 HITSTRIPE SHORT
ceph: file.c:381 : zero tail
4194304
ceph: file.c:390 : striped_read returns
6291456
The hole of file is from 2M--4M.But actualy it zero the last 4M include
the last 2M area which isn't a hole.
Using this patch, the messages are:
ceph: file.c:350 : striped_read 0~
6291456 (read 0) got
2097152 HITSTRIPE SHORT
ceph: file.c:358 : zero gap
2097152 to
4194304
ceph: file.c:350 : striped_read
4194304~
2097152 (read
4194304) got
2097152
ceph: file.c:384 : striped_read returns
6291456
TestB:
>echo majianpeng > test
>dd if=test of=/dev/null bs=2M count=1 iflag=direct
The messages are:
ceph: file.c:350 : striped_read 0~
6291456 (read 0) got 11 HITSTRIPE SHORT
ceph: file.c:350 : striped_read 11~
6291445 (read 11) got 0 HITSTRIPE SHORT
ceph: file.c:390 : striped_read returns 11
For this case,it did once more striped_read.It's no meaningless.
Using this patch, the message are:
ceph: file.c:350 : striped_read 0~
6291456 (read 0) got 11 HITSTRIPE SHORT
ceph: file.c:384 : striped_read returns 11
Big thanks to Yan Zheng for the patch.
Reviewed-by: Yan, Zheng <zheng.z.yan@intel.com>
Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Thu, 15 Aug 2013 05:58:59 +0000 (08:58 +0300)]
libceph: create_singlethread_workqueue() doesn't return ERR_PTRs
commit
dbcae088fa660086bde6e10d63bb3c9264832d85 upstream.
create_singlethread_workqueue() returns NULL on error, and it doesn't
return ERR_PTRs.
I tweaked the error handling a little to be consistent with earlier in
the function.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Thu, 15 Aug 2013 05:52:48 +0000 (08:52 +0300)]
libceph: potential NULL dereference in ceph_osdc_handle_map()
commit
b72e19b9225d4297a18715b0998093d843d170fa upstream.
There are two places where we read "nr_maps" if both of them are set to
zero then we would hit a NULL dereference here.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Thu, 15 Aug 2013 05:51:58 +0000 (08:51 +0300)]
libceph: fix error handling in handle_reply()
commit
1874119664dafda3ef2ed9b51b4759a9540d4a1a upstream.
We've tried to fix the error paths in this function before, but there
is still a hidden goto in the ceph_decode_need() macro which goes to the
wrong place. We need to release the "req" and unlock a mutex before
returning.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
majianpeng [Fri, 2 Aug 2013 10:14:48 +0000 (18:14 +0800)]
ceph: Add check returned value on func ceph_calc_ceph_pg.
commit
2fbcbff1d6b9243ef71c64a8ab993bc3c7bb7af1 upstream.
Func ceph_calc_ceph_pg maybe failed.So add check for returned value.
Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Signed-off-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Tue, 23 Jul 2013 13:48:01 +0000 (16:48 +0300)]
ceph: cleanup types in striped_read()
commit
688bac461ba3e9d221a879ab40b687f5d7b5b19c upstream.
We pass in a u64 value for "len" and then immediately truncate away the
upper 32 bits.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Reviewed-by: Alex Elder <alex.elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nathaniel Yazdani [Mon, 5 Aug 2013 04:04:30 +0000 (21:04 -0700)]
ceph: fix null pointer dereference
commit
c338c07c51e3106711fad5eb599e375eadb6855d upstream.
When register_session() is given an out-of-range argument for mds,
ceph_mdsmap_get_addr() will return a null pointer, which would be given to
ceph_con_open() & be dereferenced, causing a kernel oops. This fixes bug #4685
in the Ceph bug tracker <http://tracker.ceph.com/issues/4685>.
Signed-off-by: Nathaniel Yazdani <n1ght.4nd.d4y@gmail.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yan, Zheng [Mon, 24 Jun 2013 06:41:27 +0000 (14:41 +0800)]
libceph: call r_unsafe_callback when unsafe reply is received
commit
61c5d6bf7074ee32d014dcdf7698dc8c59eb712d upstream.
We can't use !req->r_sent to check if OSD request is sent for the
first time, this is because __cancel_request() zeros req->r_sent
when OSD map changes. Rather than adding a new variable to struct
ceph_osd_request to indicate if it's sent for the first time, We
can call the unsafe callback only when unsafe OSD reply is received.
If OSD's first reply is safe, just skip calling the unsafe callback.
The purpose of unsafe callback is adding unsafe request to a list,
so that fsync(2) can wait for the safe reply. fsync(2) doesn't need
to wait for a write(2) that hasn't returned yet. So it's OK to add
request to the unsafe list when the first OSD reply is received.
(ceph_sync_write() returns after receiving the first OSD reply)
Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sasha Levin [Mon, 1 Jul 2013 22:33:39 +0000 (18:33 -0400)]
ceph: avoid accessing invalid memory
commit
5446429630257f4723829409337a26c076907d5d upstream.
when mounting ceph with a dev name that starts with a slash, ceph
would attempt to access the character before that slash. Since we
don't actually own that byte of memory, we would trigger an
invalid access:
[ 43.499934] BUG: unable to handle kernel paging request at
ffff880fa3a97fff
[ 43.500984] IP: [<
ffffffff818f3884>] parse_mount_options+0x1a4/0x300
[ 43.501491] PGD
743b067 PUD
10283c4067 PMD
10282a6067 PTE
8000000fa3a97060
[ 43.502301] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 43.503006] Dumping ftrace buffer:
[ 43.503596] (ftrace buffer empty)
[ 43.504046] CPU: 0 PID: 10879 Comm: mount Tainted: G W 3.10.0-sasha #1129
[ 43.504851] task:
ffff880fa625b000 ti:
ffff880fa3412000 task.ti:
ffff880fa3412000
[ 43.505608] RIP: 0010:[<
ffffffff818f3884>] [<
ffffffff818f3884>] parse_mount_options$
[ 43.506552] RSP: 0018:
ffff880fa3413d08 EFLAGS:
00010286
[ 43.507133] RAX:
ffff880fa3a98000 RBX:
ffff880fa3a98000 RCX:
0000000000000000
[ 43.507893] RDX:
ffff880fa3a98001 RSI:
000000000000002f RDI:
ffff880fa3a98000
[ 43.508610] RBP:
ffff880fa3413d58 R08:
0000000000001f99 R09:
ffff880fa3fe64c0
[ 43.509426] R10:
ffff880fa3413d98 R11:
ffff880fa38710d8 R12:
ffff880fa3413da0
[ 43.509792] R13:
ffff880fa3a97fff R14:
0000000000000000 R15:
ffff880fa3413d90
[ 43.509792] FS:
00007fa9c48757e0(0000) GS:
ffff880fd2600000(0000) knlGS:
000000000000$
[ 43.509792] CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
[ 43.509792] CR2:
ffff880fa3a97fff CR3:
0000000fa3bb9000 CR4:
00000000000006b0
[ 43.509792] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 43.509792] DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
[ 43.509792] Stack:
[ 43.509792]
0000e5180000000e ffffffff85ca1900 ffff880fa38710d8 ffff880fa3413d98
[ 43.509792]
0000000000000120 0000000000000000 ffff880fa3a98000 0000000000000000
[ 43.509792]
ffffffff85cf32a0 0000000000000000 ffff880fa3413dc8 ffffffff818f3c72
[ 43.509792] Call Trace:
[ 43.509792] [<
ffffffff818f3c72>] ceph_mount+0xa2/0x390
[ 43.509792] [<
ffffffff81226314>] ? pcpu_alloc+0x334/0x3c0
[ 43.509792] [<
ffffffff81282f8d>] mount_fs+0x8d/0x1a0
[ 43.509792] [<
ffffffff812263d0>] ? __alloc_percpu+0x10/0x20
[ 43.509792] [<
ffffffff8129f799>] vfs_kern_mount+0x79/0x100
[ 43.509792] [<
ffffffff812a224d>] do_new_mount+0xcd/0x1c0
[ 43.509792] [<
ffffffff812a2e8d>] do_mount+0x15d/0x210
[ 43.509792] [<
ffffffff81220e55>] ? strndup_user+0x45/0x60
[ 43.509792] [<
ffffffff812a2fdd>] SyS_mount+0x9d/0xe0
[ 43.509792] [<
ffffffff83fd816c>] tracesys+0xdd/0xe2
[ 43.509792] Code: 4c 8b 5d c0 74 0a 48 8d 50 01 49 89 14 24 eb 17 31 c0 48 83 c9 ff $
[ 43.509792] RIP [<
ffffffff818f3884>] parse_mount_options+0x1a4/0x300
[ 43.509792] RSP <
ffff880fa3413d08>
[ 43.509792] CR2:
ffff880fa3a97fff
[ 43.509792] ---[ end trace
22469cd81e93af51 ]---
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Reviewed-by: Sage Weil <sage@inktan.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
majianpeng [Tue, 25 Jun 2013 06:48:19 +0000 (14:48 +0800)]
ceph: Free mdsc if alloc mdsc->mdsmap failed.
commit
fb3101b6f0db9ae3f35dc8e6ec908d0af8cdf12e upstream.
Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sage Weil [Sun, 9 Jun 2013 15:40:39 +0000 (08:40 -0700)]
rbd: fix a couple warnings
commit
e976cad0f0dbe5440a4ca38e29e1f932d9319125 upstream.
gcc isn't quite smart enough and generates these warnings:
drivers/block/rbd.c: In function 'rbd_img_request_fill':
drivers/block/rbd.c:1266:22: warning: 'bio_list' may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/block/rbd.c:2186:14: note: 'bio_list' was declared here
drivers/block/rbd.c:2247:10: warning: 'pages' may be used uninitialized in this function [-Wmaybe-uninitialized]
even though they are initialized for their respective code paths.
Signed-off-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yan, Zheng [Sun, 2 Jun 2013 10:40:23 +0000 (18:40 +0800)]
libceph: fix truncate size calculation
commit
ccca4e37b1a912da3db68aee826557ea66145273 upstream.
check the "not truncated yet" case
Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yan, Zheng [Fri, 31 May 2013 07:54:44 +0000 (15:54 +0800)]
libceph: fix safe completion
commit
eb845ff13a44477f8a411baedbf11d678b9daf0a upstream.
handle_reply() calls complete_request() only if the first OSD reply
has ONDISK flag.
Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Elder [Fri, 31 May 2013 22:40:44 +0000 (17:40 -0500)]
rbd: protect against concurrent unmaps
commit
82a442d239695a242c4d584464c9606322cd02aa upstream.
Make sure two concurrent unmap operations on the same rbd device
won't collide, by only proceeding with the removal and cleanup of a
device if is not already underway.
Signed-off-by: Alex Elder <elder@inktank.com>
Reviewed-by: Josh Durgin <josh.durgin@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Elder [Fri, 31 May 2013 20:17:01 +0000 (15:17 -0500)]
rbd: set removing flag while holding list lock
commit
751cc0e3cfabdda87c4c21519253c6751e97a8d4 upstream.
When unmapping a device, its id is supplied, and that is used to
look up which rbd device should be unmapped. Looking up the
device involves searching the rbd device list while holding
a spinlock that protects access to that list.
Currently all of this is done under protection of the control lock,
but that protection is going away soon. To ensure the rbd_dev is
still valid (still on the list) while setting its REMOVING flag, do
so while still holding the list lock. To do so, get rid of
__rbd_get_dev(), and open code what it did in the one place it
was used.
Signed-off-by: Alex Elder <elder@inktank.com>
Reviewed-by: Josh Durgin <josh.durgin@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Elder [Thu, 23 May 2013 01:54:25 +0000 (20:54 -0500)]
rbd: flush dcache after zeroing page data
commit
e215605417b87732c6debf65da6d953016a1e5bc upstream.
Neither zero_bio_chain() nor zero_pages() contains a call to flush
caches after zeroing a portion of a page. This can cause problems
on architectures that have caches that allow virtual address
aliasing.
This resolves:
http://tracker.ceph.com/issues/4777
Signed-off-by: Alex Elder <elder@inktank.com>
Reviewed-by: Josh Durgin <josh.durgin@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Elder [Thu, 23 May 2013 01:54:25 +0000 (20:54 -0500)]
libceph: add lingering request reference when registered
commit
96e4dac66f69d28af2b736e723364efbbdf9fdee upstream.
When an osd request is set to linger, the osd client holds onto the
request so it can be re-submitted following certain osd map changes.
The osd client holds a reference to the request until it is
unregistered. This is used by rbd for watch requests.
Currently, the reference is taken when the request is marked with
the linger flag. This means that if an error occurs after that
time but before the the request completes successfully, that
reference is leaked.
There's really no reason to take the reference until the request is
registered in the the osd client's list of lingering requests, and
that only happens when the lingering (watch) request completes
successfully.
So take that reference only when it gets registered following
succesful completion, and drop it (as before) when the request
gets unregistered. This avoids the reference problem on error
in rbd.
Rearrange ceph_osdc_unregister_linger_request() to avoid using
the request pointer after it may have been freed.
And hold an extra reference in kick_requests() while handling
a linger request that has not yet been registered, to ensure
it doesn't go away.
This resolves:
http://tracker.ceph.com/issues/3859
Signed-off-by: Alex Elder <elder@inktank.com>
Reviewed-by: Josh Durgin <josh.durgin@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Emil Goode [Tue, 28 May 2013 14:59:00 +0000 (16:59 +0200)]
ceph: improve error handling in ceph_mdsmap_decode
commit
c213b50b7dcbf06abcfbf1e4eee5b76586718bd9 upstream.
This patch makes the following improvements to the error handling
in the ceph_mdsmap_decode function:
- Add a NULL check for return value from kcalloc
- Make use of the variable err
Signed-off-by: Emil Goode <emilgoode@gmail.com>
Signed-off-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dinh Nguyen [Tue, 10 Dec 2013 18:49:18 +0000 (19:49 +0100)]
clocksource: dw_apb_timer_of: Fix read_sched_clock
commit
85dc6ee1237c8a4a7742e6abab96a20389b7d682 upstream.
The read_sched_clock should return the ~value because the clock is a
countdown implementation. read_sched_clock() should be the same as
__apbt_read_clocksource().
Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Moore [Tue, 10 Dec 2013 19:58:01 +0000 (14:58 -0500)]
selinux: process labeled IPsec TCP SYN-ACK packets properly in selinux_ip_postroute()
commit
c0828e50485932b7e019df377a6b0a8d1ebd3080 upstream.
Due to difficulty in arriving at the proper security label for
TCP SYN-ACK packets in selinux_ip_postroute(), we need to check packets
while/before they are undergoing XFRM transforms instead of waiting
until afterwards so that we can determine the correct security label.
Reported-by: Janak Desai <Janak.Desai@gtri.gatech.edu>
Signed-off-by: Paul Moore <pmoore@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Moore [Tue, 10 Dec 2013 19:57:54 +0000 (14:57 -0500)]
selinux: look for IPsec labels on both inbound and outbound packets
commit
817eff718dca4e54d5721211ddde0914428fbb7c upstream.
Previously selinux_skb_peerlbl_sid() would only check for labeled
IPsec security labels on inbound packets, this patch enables it to
check both inbound and outbound traffic for labeled IPsec security
labels.
Reported-by: Janak Desai <Janak.Desai@gtri.gatech.edu>
Signed-off-by: Paul Moore <pmoore@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Thu, 19 Dec 2013 01:08:48 +0000 (17:08 -0800)]
sh: always link in helper functions extracted from libgcc
commit
84ed8a99058e61567f495cc43118344261641c5f upstream.
E.g. landisk_defconfig, which has CONFIG_NTFS_FS=m:
ERROR: "__ashrdi3" [fs/ntfs/ntfs.ko] undefined!
For "lib-y", if no symbols in a compilation unit are referenced by other
units, the compilation unit will not be included in vmlinux. This
breaks modules that do reference those symbols.
Use "obj-y" instead to fix this.
http://kisskb.ellerman.id.au/kisskb/buildresult/
8838077/
This doesn't fix all cases. There are others, e.g. udivsi3.
This is also not limited to sh, many architectures handle this in the
same way.
A simple solution is to unconditionally include all helper functions.
A more complex solution is to make the choice of "lib-y" or "obj-y" depend
on CONFIG_MODULES:
obj-$(CONFIG_MODULES) += ...
lib-y($CONFIG_MODULES) += ...
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Paul Mundt <lethal@linux-sh.org>
Tested-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Reviewed-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephen Boyd [Tue, 10 Dec 2013 23:19:03 +0000 (15:19 -0800)]
gpio: msm: Fix irq mask/unmask by writing bits instead of numbers
commit
4cc629b7a20945ce35628179180329b6bc9e552b upstream.
We should be writing bits here but instead we're writing the
numbers that correspond to the bits we want to write. Fix it by
wrapping the numbers in the BIT() macro. This fixes gpios acting
as interrupts.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Roger Quadros [Thu, 5 Dec 2013 09:23:35 +0000 (11:23 +0200)]
gpio: twl4030: Fix regression for twl gpio LED output
commit
f5837ec11f8cfa6d53ebc5806582771b2c9988c6 upstream.
Commit
0b2aa8be introduced a regression that causes failure
in setting LED GPO direction to OUT.
This causes USB host probe failures for Beagleboard C4.
platform usb_phy_gen_xceiv.2: Driver usb_phy_gen_xceiv requests probe deferral
hsusb2_vcc: Failed to request enable GPIO510: -22
reg-fixed-voltage reg-fixed-voltage.0.auto: Failed to register regulator: -22
reg-fixed-voltage: probe of reg-fixed-voltage.0.auto failed with error -22
direction_out/direction_in must return 0 if the operation succeeded.
Also, don't update direction flag and output data if twl4030_set_gpio_direction()
failed inside twl_direction_out();
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Theodore Ts'o [Mon, 9 Dec 2013 02:12:59 +0000 (21:12 -0500)]
jbd2: don't BUG but return ENOSPC if a handle runs out of space
commit
f6c07cad081ba222d63623d913aafba5586c1d2c upstream.
If a handle runs out of space, we currently stop the kernel with a BUG
in jbd2_journal_dirty_metadata(). This makes it hard to figure out
what might be going on. So return an error of ENOSPC, so we can let
the file system layer figure out what is going on, to make it more
likely we can get useful debugging information). This should make it
easier to debug problems such as the one which was reported by:
https://bugzilla.kernel.org/show_bug.cgi?id=44731
The only two callers of this function are ext4_handle_dirty_metadata()
and ocfs2_journal_dirty(). The ocfs2 function will trigger a
BUG_ON(), which means there will be no change in behavior. The ext4
function will call ext4_error_inode() which will print the useful
debugging information and then handle the situation using ext4's error
handling mechanisms (i.e., which might mean halting the kernel or
remounting the file system read-only).
Also, since both file systems already call WARN_ON(), drop the WARN_ON
from jbd2_journal_dirty_metadata() to avoid two stack traces from
being displayed.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: ocfs2-devel@oss.oracle.com
Acked-by: Joel Becker <jlbec@evilplan.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martin Schwidefsky [Wed, 18 Dec 2013 13:36:18 +0000 (14:36 +0100)]
s390/3270: fix allocation of tty3270_screen structure
commit
36d9f4d3b68c7035ead3850dc85f310a579ed0eb upstream.
The tty3270_alloc_screen function is called from tty3270_install with
swapped arguments, the number of columns instead of rows and vice versa.
The number of rows is typically smaller than the number of columns which
makes the screen array too big but the individual cell arrays for the
lines too small. Creating lines longer than the number of rows will
clobber the memory after the end of the cell array.
The fix is simple, call tty3270_alloc_screen with the correct argument
order.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vladimir Davydov [Thu, 2 Jan 2014 20:58:47 +0000 (12:58 -0800)]
memcg: fix memcg_size() calculation
commit
695c60830764945cf61a2cc623eb1392d137223e upstream.
The mem_cgroup structure contains nr_node_ids pointers to
mem_cgroup_per_node objects, not the objects themselves.
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Acked-by: Michal Hocko <mhocko@suse.cz>
Cc: Glauber Costa <glommer@openvz.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Balbir Singh <bsingharora@gmail.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steven Whitehouse [Wed, 18 Dec 2013 14:14:52 +0000 (14:14 +0000)]
GFS2: Fix incorrect invalidation for DIO/buffered I/O
commit
dfd11184d894cd0a92397b25cac18831a1a6a5bc upstream.
In patch
209806aba9d540dde3db0a5ce72307f85f33468f we allowed
local deferred locks to be granted against a cached exclusive
lock. That opened up a corner case which this patch now
fixes.
The solution to the problem is to check whether we have cached
pages each time we do direct I/O and if so to unmap, flush
and invalidate those pages. Since the glock state machine
normally does that for us, mostly the code will be a no-op.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steven Whitehouse [Fri, 6 Dec 2013 11:52:34 +0000 (11:52 +0000)]
GFS2: don't hold s_umount over blkdev_put
commit
dfe5b9ad83a63180f358b27d1018649a27b394a9 upstream.
This is a GFS2 version of Tejun's patch:
4f331f01b9c43bf001d3ffee578a97a1e0633eac
vfs: don't hold s_umount over close_bdev_exclusive() call
In this case its blkdev_put itself that is the issue and this
patch uses the same solution of dropping and retaking s_umount.
Reported-by: Tejun Heo <tj@kernel.org>
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Torokhov [Fri, 27 Dec 2013 01:44:29 +0000 (17:44 -0800)]
Input: allocate absinfo data when setting ABS capability
commit
28a2a2e1aedbe2d8b2301e6e0e4e63f6e4177aca upstream.
We need to make sure we allocate absinfo data when we are setting one of
EV_ABS/ABS_XXX capabilities, otherwise we may bomb when we try to emit this
event.
Rested-by: Paul Cercueil <pcercuei@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Naoya Horiguchi [Thu, 2 Jan 2014 20:58:51 +0000 (12:58 -0800)]
mm/memory-failure.c: transfer page count from head page to tail page after split thp
commit
a3e0f9e47d5ef7858a26cc12d90ad5146e802d47 upstream.
Memory failures on thp tail pages cause kernel panic like below:
mce: [Hardware Error]: Machine check events logged
MCE exception done on CPU 7
BUG: unable to handle kernel NULL pointer dereference at
0000000000000058
IP: [<
ffffffff811b7cd1>] dequeue_hwpoisoned_huge_page+0x131/0x1e0
PGD
bae42067 PUD
ba47d067 PMD 0
Oops: 0000 [#1] SMP
...
CPU: 7 PID: 128 Comm: kworker/7:2 Tainted: G M O
3.13.0-rc4-131217-1558-00003-g83b7df08e462 #25
...
Call Trace:
me_huge_page+0x3e/0x50
memory_failure+0x4bb/0xc20
mce_process_work+0x3e/0x70
process_one_work+0x171/0x420
worker_thread+0x11b/0x3a0
? manage_workers.isra.25+0x2b0/0x2b0
kthread+0xe4/0x100
? kthread_create_on_node+0x190/0x190
ret_from_fork+0x7c/0xb0
? kthread_create_on_node+0x190/0x190
...
RIP dequeue_hwpoisoned_huge_page+0x131/0x1e0
CR2:
0000000000000058
The reasoning of this problem is shown below:
- when we have a memory error on a thp tail page, the memory error
handler grabs a refcount of the head page to keep the thp under us.
- Before unmapping the error page from processes, we split the thp,
where page refcounts of both of head/tail pages don't change.
- Then we call try_to_unmap() over the error page (which was a tail
page before). We didn't pin the error page to handle the memory error,
this error page is freed and removed from LRU list.
- We never have the error page on LRU list, so the first page state
check returns "unknown page," then we move to the second check
with the saved page flag.
- The saved page flag have PG_tail set, so the second page state check
returns "hugepage."
- We call me_huge_page() for freed error page, then we hit the above panic.
The root cause is that we didn't move refcount from the head page to the
tail page after split thp. So this patch suggests to do this.
This panic was introduced by commit
524fca1e73 ("HWPOISON: fix
misjudgement of page_action() for errors on mlocked pages"). Note that we
did have the same refcount problem before this commit, but it was just
ignored because we had only first page state check which returned "unknown
page." The commit changed the refcount problem from "doesn't work" to
"kernel panic."
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Reviewed-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rik van Riel [Thu, 2 Jan 2014 20:58:46 +0000 (12:58 -0800)]
mm: fix use-after-free in sys_remap_file_pages
commit
4eb919825e6c3c7fb3630d5621f6d11e98a18b3a upstream.
remap_file_pages calls mmap_region, which may merge the VMA with other
existing VMAs, and free "vma". This can lead to a use-after-free bug.
Avoid the bug by remembering vm_flags before calling mmap_region, and
not trying to dereference vma later.
Signed-off-by: Rik van Riel <riel@redhat.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: PaX Team <pageexec@freemail.hu>
Cc: Kees Cook <keescook@chromium.org>
Cc: Michel Lespinasse <walken@google.com>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Hugh Dickins <hughd@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jianguo Wu [Thu, 19 Dec 2013 01:08:59 +0000 (17:08 -0800)]
mm/hugetlb: check for pte NULL pointer in __page_check_address()
commit
98398c32f6687ee1e1f3ae084effb4b75adb0747 upstream.
In __page_check_address(), if address's pud is not present,
huge_pte_offset() will return NULL, we should check the return value.
Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: qiuxishi <qiuxishi@huawei.com>
Cc: Hanjun Guo <guohanjun@huawei.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joonsoo Kim [Thu, 19 Dec 2013 01:08:52 +0000 (17:08 -0800)]
mm/compaction: respect ignore_skip_hint in update_pageblock_skip
commit
6815bf3f233e0b10c99a758497d5d236063b010b upstream.
update_pageblock_skip() only fits to compaction which tries to isolate
by pageblock unit. If isolate_migratepages_range() is called by CMA, it
try to isolate regardless of pageblock unit and it don't reference
get_pageblock_skip() by ignore_skip_hint. We should also respect it on
update_pageblock_skip() to prevent from setting the wrong information.
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Reviewed-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Rafael Aquini <aquini@redhat.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>
Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mel Gorman [Thu, 19 Dec 2013 01:08:45 +0000 (17:08 -0800)]
mm: numa: guarantee that tlb_flush_pending updates are visible before page table updates
commit
af2c1401e6f9177483be4fad876d0073669df9df upstream.
According to documentation on barriers, stores issued before a LOCK can
complete after the lock implying that it's possible tlb_flush_pending
can be visible after a page table update. As per revised documentation,
this patch adds a smp_mb__before_spinlock to guarantee the correct
ordering.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rik van Riel [Thu, 19 Dec 2013 01:08:44 +0000 (17:08 -0800)]
mm: fix TLB flush race between migration, and change_protection_range
commit
20841405940e7be0617612d521e206e4b6b325db upstream.
There are a few subtle races, between change_protection_range (used by
mprotect and change_prot_numa) on one side, and NUMA page migration and
compaction on the other side.
The basic race is that there is a time window between when the PTE gets
made non-present (PROT_NONE or NUMA), and the TLB is flushed.
During that time, a CPU may continue writing to the page.
This is fine most of the time, however compaction or the NUMA migration
code may come in, and migrate the page away.
When that happens, the CPU may continue writing, through the cached
translation, to what is no longer the current memory location of the
process.
This only affects x86, which has a somewhat optimistic pte_accessible.
All other architectures appear to be safe, and will either always flush,
or flush whenever there is a valid mapping, even with no permissions
(SPARC).
The basic race looks like this:
CPU A CPU B CPU C
load TLB entry
make entry PTE/PMD_NUMA
fault on entry
read/write old page
start migrating page
change PTE/PMD to new page
read/write old page [*]
flush TLB
reload TLB from new entry
read/write new page
lose data
[*] the old page may belong to a new user at this point!
The obvious fix is to flush remote TLB entries, by making sure that
pte_accessible aware of the fact that PROT_NONE and PROT_NUMA memory may
still be accessible if there is a TLB flush pending for the mm.
This should fix both NUMA migration and compaction.
[mgorman@suse.de: fix build]
Signed-off-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Cc: Alex Thorlton <athorlton@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oleg Nesterov [Mon, 12 Aug 2013 16:14:00 +0000 (18:14 +0200)]
sched: fix the theoretical signal_wake_up() vs schedule() race
commit
e0acd0a68ec7dbf6b7a81a87a867ebd7ac9b76c4 upstream.
This is only theoretical, but after try_to_wake_up(p) was changed
to check p->state under p->pi_lock the code like
__set_current_state(TASK_INTERRUPTIBLE);
schedule();
can miss a signal. This is the special case of wait-for-condition,
it relies on try_to_wake_up/schedule interaction and thus it does
not need mb() between __set_current_state() and if(signal_pending).
However, this __set_current_state() can move into the critical
section protected by rq->lock, now that try_to_wake_up() takes
another lock we need to ensure that it can't be reordered with
"if (signal_pending(current))" check inside that section.
The patch is actually one-liner, it simply adds smp_wmb() before
spin_lock_irq(rq->lock). This is what try_to_wake_up() already
does by the same reason.
We turn this wmb() into the new helper, smp_mb__before_spinlock(),
for better documentation and to allow the architectures to change
the default implementation.
While at it, kill smp_mb__after_lock(), it has no callers.
Perhaps we can also add smp_mb__before/after_spinunlock() for
prepare_to_wait().
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mel Gorman [Thu, 19 Dec 2013 01:08:39 +0000 (17:08 -0800)]
mm: numa: avoid unnecessary work on the failure path
commit
eb4489f69f224356193364dc2762aa009738ca7f upstream.
If a PMD changes during a THP migration then migration aborts but the
failure path is doing more work than is necessary.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Alex Thorlton <athorlton@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mel Gorman [Thu, 19 Dec 2013 01:08:38 +0000 (17:08 -0800)]
mm: numa: ensure anon_vma is locked to prevent parallel THP splits
commit
c3a489cac38d43ea6dc4ac240473b44b46deecf7 upstream.
The anon_vma lock prevents parallel THP splits and any associated
complexity that arises when handling splits during THP migration. This
patch checks if the lock was successfully acquired and bails from THP
migration if it failed for any reason.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Alex Thorlton <athorlton@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mel Gorman [Thu, 19 Dec 2013 01:08:34 +0000 (17:08 -0800)]
mm: clear pmd_numa before invalidating
commit
67f87463d3a3362424efcbe8b40e4772fd34fc61 upstream.
On x86, PMD entries are similar to _PAGE_PROTNONE protection and are
handled as NUMA hinting faults. The following two page table protection
bits are what defines them
_PAGE_NUMA:set _PAGE_PRESENT:clear
A PMD is considered present if any of the _PAGE_PRESENT, _PAGE_PROTNONE,
_PAGE_PSE or _PAGE_NUMA bits are set. If pmdp_invalidate encounters a
pmd_numa, it clears the present bit leaving _PAGE_NUMA which will be
considered not present by the CPU but present by pmd_present. The
existing caller of pmdp_invalidate should handle it but it's an
inconsistent state for a PMD. This patch keeps the state consistent
when calling pmdp_invalidate.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Alex Thorlton <athorlton@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rob Herring [Mon, 30 Dec 2013 01:37:43 +0000 (19:37 -0600)]
Revert "of/address: Handle #address-cells > 2 specially"
commit
13fcca8f25f4e9ce7f55da9cd353bb743236e212 upstream.
This reverts commit
e38c0a1fbc5803cbacdaac0557c70ac8ca5152e7.
Nikita Yushchenko reports:
While trying to make freescale p2020ds and mpc8572ds boards working
with mainline kernel, I faced that commit
e38c0a1f (Handle
Both these boards have uli1575 chip.
Corresponding part in device tree is something like
uli1575@0 {
reg = <0x0 0x0 0x0 0x0 0x0>;
#size-cells = <2>;
#address-cells = <3>;
ranges = <0x2000000 0x0 0x80000000
0x2000000 0x0 0x80000000
0x0 0x20000000
0x1000000 0x0 0x0
0x1000000 0x0 0x0
0x0 0x10000>;
isa@1e {
...
I.e. it has #address-cells = <3>
With commit
e38c0a1f reverted, devices under uli1575 are registered
correctly, e.g. for rtc
OF: ** translation for device /pcie@
ffe09000/pcie@0/uli1575@0/isa@1e/rtc@70 **
OF: bus is isa (na=2, ns=1) on /pcie@
ffe09000/pcie@0/uli1575@0/isa@1e
OF: translating address:
00000001 00000070
OF: parent bus is default (na=3, ns=2) on /pcie@
ffe09000/pcie@0/uli1575@0
OF: walking ranges...
OF: ISA map, cp=0, s=1000, da=70
OF: parent translation for:
01000000 00000000 00000000
OF: with offset: 70
OF: one level translation:
00000000 00000000 00000070
OF: parent bus is pci (na=3, ns=2) on /pcie@
ffe09000/pcie@0
OF: walking ranges...
OF: default map, cp=
a0000000, s=
20000000, da=70
OF: default map, cp=0, s=10000, da=70
OF: parent translation for:
01000000 00000000 00000000
OF: with offset: 70
OF: one level translation:
01000000 00000000 00000070
OF: parent bus is pci (na=3, ns=2) on /pcie@
ffe09000
OF: walking ranges...
OF: PCI map, cp=0, s=10000, da=70
OF: parent translation for:
01000000 00000000 00000000
OF: with offset: 70
OF: one level translation:
01000000 00000000 00000070
OF: parent bus is default (na=2, ns=2) on /
OF: walking ranges...
OF: PCI map, cp=0, s=10000, da=70
OF: parent translation for:
00000000 ffc10000
OF: with offset: 70
OF: one level translation:
00000000 ffc10070
OF: reached root node
With commit
e38c0a1f in place, address translation fails:
OF: ** translation for device /pcie@
ffe09000/pcie@0/uli1575@0/isa@1e/rtc@70 **
OF: bus is isa (na=2, ns=1) on /pcie@
ffe09000/pcie@0/uli1575@0/isa@1e
OF: translating address:
00000001 00000070
OF: parent bus is default (na=3, ns=2) on /pcie@
ffe09000/pcie@0/uli1575@0
OF: walking ranges...
OF: ISA map, cp=0, s=1000, da=70
OF: parent translation for:
01000000 00000000 00000000
OF: with offset: 70
OF: one level translation:
00000000 00000000 00000070
OF: parent bus is pci (na=3, ns=2) on /pcie@
ffe09000/pcie@0
OF: walking ranges...
OF: default map, cp=
a0000000, s=
20000000, da=70
OF: default map, cp=0, s=10000, da=70
OF: not found !
Thierry Reding confirmed this commit was not needed after all:
"We ended up merging a different address representation for Tegra PCIe
and I've confirmed that reverting this commit doesn't cause any obvious
regressions. I think all other drivers in drivers/pci/host ended up
copying what we did on Tegra, so I wouldn't expect any other breakage
either."
There doesn't appear to be a simple way to support both behaviours, so
reverting this as nothing should be depending on the new behaviour.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rafael J. Wysocki [Tue, 31 Dec 2013 12:37:46 +0000 (13:37 +0100)]
intel_pstate: Fail initialization if P-state information is missing
commit
98a947abdd54e5de909bebadfced1696ccad30cf upstream.
If pstate.current_pstate is 0 after the initial
intel_pstate_get_cpu_pstates(), this means that we were unable to
obtain any useful P-state information and there is no reason to
continue, so free memory and return an error in that case.
This fixes the following divide error occuring in a nested KVM
guest:
Intel P-state driver initializing.
Intel pstate controlling: cpu 0
cpufreq: __cpufreq_add_dev: ->get() failed
divide error: 0000 [#1] SMP
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-0.rc4.git5.1.fc21.x86_64 #1
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
task:
ffff88001ea20000 ti:
ffff88001e9bc000 task.ti:
ffff88001e9bc000
RIP: 0010:[<
ffffffff815c551d>] [<
ffffffff815c551d>] intel_pstate_timer_func+0x11d/0x2b0
RSP: 0000:
ffff88001ee03e18 EFLAGS:
00010246
RAX:
0000000000000000 RBX:
ffff88001a454348 RCX:
0000000000006100
RDX:
0000000000000000 RSI:
0000000000000000 RDI:
0000000000000000
RBP:
ffff88001ee03e38 R08:
0000000000000000 R09:
0000000000000000
R10:
ffff88001ea20000 R11:
0000000000000000 R12:
00000c0a1ea20000
R13:
1ea200001ea20000 R14:
ffffffff815c5400 R15:
ffff88001a454348
FS:
0000000000000000(0000) GS:
ffff88001ee00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
CR2:
0000000000000000 CR3:
0000000001c0c000 CR4:
00000000000006f0
Stack:
fffffffb1a454390 ffffffff821a4500 ffff88001a454390 0000000000000100
ffff88001ee03ea8 ffffffff81083e9a ffffffff81083e15 ffffffff82d5ed40
ffffffff8258cc60 0000000000000000 ffffffff81ac39de 0000000000000000
Call Trace:
<IRQ>
[<
ffffffff81083e9a>] call_timer_fn+0x8a/0x310
[<
ffffffff81083e15>] ? call_timer_fn+0x5/0x310
[<
ffffffff815c5400>] ? pid_param_set+0x130/0x130
[<
ffffffff81084354>] run_timer_softirq+0x234/0x380
[<
ffffffff8107aee4>] __do_softirq+0x104/0x430
[<
ffffffff8107b5fd>] irq_exit+0xcd/0xe0
[<
ffffffff81770645>] smp_apic_timer_interrupt+0x45/0x60
[<
ffffffff8176efb2>] apic_timer_interrupt+0x72/0x80
<EOI>
[<
ffffffff810e15cd>] ? vprintk_emit+0x1dd/0x5e0
[<
ffffffff81757719>] printk+0x67/0x69
[<
ffffffff815c1493>] __cpufreq_add_dev.isra.13+0x883/0x8d0
[<
ffffffff815c14f0>] cpufreq_add_dev+0x10/0x20
[<
ffffffff814a14d1>] subsys_interface_register+0xb1/0xf0
[<
ffffffff815bf5cf>] cpufreq_register_driver+0x9f/0x210
[<
ffffffff81fb19af>] intel_pstate_init+0x27d/0x3be
[<
ffffffff81761e3e>] ? mutex_unlock+0xe/0x10
[<
ffffffff81fb1732>] ? cpufreq_gov_dbs_init+0x12/0x12
[<
ffffffff8100214a>] do_one_initcall+0xfa/0x1b0
[<
ffffffff8109dbf5>] ? parse_args+0x225/0x3f0
[<
ffffffff81f64193>] kernel_init_freeable+0x1fc/0x287
[<
ffffffff81f638d0>] ? do_early_param+0x88/0x88
[<
ffffffff8174b530>] ? rest_init+0x150/0x150
[<
ffffffff8174b53e>] kernel_init+0xe/0x130
[<
ffffffff8176e27c>] ret_from_fork+0x7c/0xb0
[<
ffffffff8174b530>] ? rest_init+0x150/0x150
Code: c1 e0 05 48 63 bc 03 10 01 00 00 48 63 83 d0 00 00 00 48 63 d6 48 c1 e2 08 c1 e1 08 4c 63 c2 48 c1 e0 08 48 98 48 c1 e0 08 48 99 <49> f7 f8 48 98 48 0f af f8 48 c1 ff 08 29 f9 89 ca c1 fa 1f 89
RIP [<
ffffffff815c551d>] intel_pstate_timer_func+0x11d/0x2b0
RSP <
ffff88001ee03e18>
---[ end trace
f166110ed22cc37a ]---
Kernel panic - not syncing: Fatal exception in interrupt
Reported-and-tested-by: Kashyap Chamarthy <kchamart@redhat.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Larry Finger [Wed, 11 Dec 2013 23:13:10 +0000 (17:13 -0600)]
rtlwifi: pci: Fix oops on driver unload
commit
9278db6279e28d4d433bc8a848e10b4ece8793ed upstream.
On Fedora systems, unloading rtl8192ce causes an oops. This patch fixes the
problem reported at https://bugzilla.redhat.com/show_bug.cgi?id=852761.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Berg [Mon, 16 Dec 2013 11:04:36 +0000 (12:04 +0100)]
radiotap: fix bitmap-end-finding buffer overrun
commit
bd02cd2549cfcdfc57cb5ce57ffc3feb94f70575 upstream.
Evan Huus found (by fuzzing in wireshark) that the radiotap
iterator code can access beyond the length of the buffer if
the first bitmap claims an extension but then there's no
data at all. Fix this.
Reported-by: Evan Huus <eapache@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tejun Heo [Wed, 18 Dec 2013 12:07:32 +0000 (07:07 -0500)]
libata, freezer: avoid block device removal while system is frozen
commit
85fbd722ad0f5d64d1ad15888cd1eb2188bfb557 upstream.
Freezable kthreads and workqueues are fundamentally problematic in
that they effectively introduce a big kernel lock widely used in the
kernel and have already been the culprit of several deadlock
scenarios. This is the latest occurrence.
During resume, libata rescans all the ports and revalidates all
pre-existing devices. If it determines that a device has gone
missing, the device is removed from the system which involves
invalidating block device and flushing bdi while holding driver core
layer locks. Unfortunately, this can race with the rest of device
resume. Because freezable kthreads and workqueues are thawed after
device resume is complete and block device removal depends on
freezable workqueues and kthreads (e.g. bdi_wq, jbd2) to make
progress, this can lead to deadlock - block device removal can't
proceed because kthreads are frozen and kthreads can't be thawed
because device resume is blocked behind block device removal.
839a8e8660b6 ("writeback: replace custom worker pool implementation
with unbound workqueue") made this particular deadlock scenario more
visible but the underlying problem has always been there - the
original forker task and jbd2 are freezable too. In fact, this is
highly likely just one of many possible deadlock scenarios given that
freezer behaves as a big kernel lock and we don't have any debug
mechanism around it.
I believe the right thing to do is getting rid of freezable kthreads
and workqueues. This is something fundamentally broken. For now,
implement a funny workaround in libata - just avoid doing block device
hot[un]plug while the system is frozen. Kernel engineering at its
finest. :(
v2: Add EXPORT_SYMBOL_GPL(pm_freezing) for cases where libata is built
as a module.
v3: Comment updated and polling interval changed to 10ms as suggested
by Rafael.
v4: Add #ifdef CONFIG_FREEZER around the hack as pm_freezing is not
defined when FREEZER is not configured thus breaking build.
Reported by kbuild test robot.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Tomaž Šolc <tomaz.solc@tablix.org>
Reviewed-by: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=62801
Link: http://lkml.kernel.org/r/20131213174932.GA27070@htj.dyndns.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Len Brown <len.brown@intel.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Robin H. Johnson [Mon, 16 Dec 2013 17:31:19 +0000 (09:31 -0800)]
libata: disable a disk via libata.force params
commit
b8bd6dc36186fe99afa7b73e9e2d9a98ad5c4865 upstream.
A user on StackExchange had a failing SSD that's soldered directly
onto the motherboard of his system. The BIOS does not give any option
to disable it at all, so he can't just hide it from the OS via the
BIOS.
The old IDE layer had hdX=noprobe override for situations like this,
but that was never ported to the libata layer.
This patch implements a disable flag for libata.force.
Example use:
libata.force=2.0:disable
[v2 of the patch, removed the nodisable flag per Tejun Heo]
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Link: http://unix.stackexchange.com/questions/102648/how-to-tell-linux-kernel-3-0-to-completely-ignore-a-failing-disk
Link: http://askubuntu.com/questions/352836/how-can-i-tell-linux-kernel-to-completely-ignore-a-disk-as-if-it-was-not-even-co
Link: http://superuser.com/questions/599333/how-to-disable-kernel-probing-for-drive
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vincent Pelletier [Tue, 21 May 2013 20:30:58 +0000 (22:30 +0200)]
libata: Add atapi_dmadir force flag
commit
966fbe193f47c68e70a80ec9991098e88e7959cb upstream.
Some device require DMADIR to be enabled, but are not detected as such
by atapi_id_dmadir. One such example is "Asus Serillel 2"
SATA-host-to-PATA-device bridge: the bridge itself requires DMADIR,
even if the bridged device does not.
As atapi_dmadir module parameter can cause problems with some devices
(as per Tejun Heo's memory), enabling it globally may not be possible
depending on the hardware.
This patch adds atapi_dmadir in the form of a "force" horkage value,
allowing global, per-bus and per-device control.
Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michele Baldessari [Mon, 25 Nov 2013 19:00:14 +0000 (19:00 +0000)]
libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for Seagate Momentus SpinPoint M8
commit
87809942d3fa60bafb7a58d0bdb1c79e90a6821d upstream.
We've received multiple reports in Fedora via (BZ 907193)
that the Seagate Momentus SpinPoint M8 errors out when enabling AA:
[ 2.555905] ata2.00: failed to enable AA (error_mask=0x1)
[ 2.568482] ata2.00: failed to enable AA (error_mask=0x1)
Add the ATA_HORKAGE_BROKEN_FPDMA_AA for this specific harddisk.
Reported-by: Nicholas <arealityfarbetween@googlemail.com>
Signed-off-by: Michele Baldessari <michele@acksyn.org>
Tested-by: Nicholas <arealityfarbetween@googlemail.com>
Acked-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josh Boyer [Fri, 11 Oct 2013 12:45:51 +0000 (08:45 -0400)]
cpupower: Fix segfault due to incorrect getopt_long arugments
commit
f447ef4a56dee4b68a91460bcdfe06b5011085f2 upstream.
If a user calls 'cpupower set --perf-bias 15', the process will end with
a SIGSEGV in libc because cpupower-set passes a NULL optarg to the atoi
call. This is because the getopt_long structure currently has all of
the options as having an optional_argument when they really have a
required argument. We change the structure to use required_argument to
match the short options and it resolves the issue.
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=
1000439
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Thomas Renninger <trenn@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anton Blanchard [Mon, 23 Dec 2013 01:19:51 +0000 (12:19 +1100)]
powerpc: Align p_end
commit
286e4f90a72c0b0621dde0294af6ed4b0baddabb upstream.
p_end is an 8 byte value embedded in the text section. This means it
is only 4 byte aligned when it should be 8 byte aligned. Fix this
by adding an explicit alignment.
This fixes an issue where POWER7 little endian builds with
CONFIG_RELOCATABLE=y fail to boot.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Neuling [Mon, 16 Dec 2013 04:12:43 +0000 (15:12 +1100)]
powerpc: Fix bad stack check in exception entry
commit
90ff5d688e61f49f23545ffab6228bd7e87e6dc7 upstream.
In EXCEPTION_PROLOG_COMMON() we check to see if the stack pointer (r1)
is valid when coming from the kernel. If it's not valid, we die but
with a nice oops message.
Currently we allocate a stack frame (subtract INT_FRAME_SIZE) before we
check to see if the stack pointer is negative. Unfortunately, this
won't detect a bad stack where r1 is less than INT_FRAME_SIZE.
This patch fixes the check to compare the modified r1 with
-INT_FRAME_SIZE. With this, bad kernel stack pointers (including NULL
pointers) are correctly detected again.
Kudos to Paulus for finding this.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kiszka [Sun, 29 Dec 2013 01:29:30 +0000 (02:29 +0100)]
KVM: x86: Fix APIC map calculation after re-enabling
commit
e66d2ae7c67bd9ac982a3d1890564de7f7eabf4b upstream.
Update arch.apic_base before triggering recalculate_apic_map. Otherwise
the recalculation will work against the previous state of the APIC and
will fail to build the correct map when an APIC is hardware-enabled
again.
This fixes a regression of
1e08ec4a13.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathy Vanhoef [Thu, 28 Nov 2013 11:21:45 +0000 (12:21 +0100)]
ath9k_htc: properly set MAC address and BSSID mask
commit
657eb17d87852c42b55c4b06d5425baa08b2ddb3 upstream.
Pick the MAC address of the first virtual interface as the new hardware MAC
address. Set BSSID mask according to this MAC address. This fixes CVE-2013-4579.
Signed-off-by: Mathy Vanhoef <vanhoefm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sujith Manoharan [Mon, 16 Dec 2013 01:34:59 +0000 (07:04 +0530)]
ath9k: Fix interrupt handling for the AR9002 family
commit
73f0b56a1ff64e7fb6c3a62088804bab93bcedc2 upstream.
This patch adds a driver workaround for a HW issue.
A race condition in the HW results in missing interrupts,
which can be avoided by a read/write with the ISR register.
All chips in the AR9002 series are affected by this bug - AR9003
and above do not have this problem.
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Korsgaard [Mon, 16 Dec 2013 10:35:35 +0000 (11:35 +0100)]
dm9601: work around tx fifo sync issue on dm962x
commit
4263c86dca5198da6bd3ad826d0b2304fbe25776 upstream.
Certain dm962x revisions contain an bug, where if a USB bulk transfer retry
(E.G. if bulk crc mismatch) happens right after a transfer with odd or
maxpacket length, the internal tx hardware fifo gets out of sync causing
the interface to stop working.
Work around it by adding up to 3 bytes of padding to ensure this situation
cannot trigger.
This workaround also means we never pass multiple-of-maxpacket size skb's
to usbnet, so the length adjustment to handle usbnet's padding of those can
be removed.
Reported-by: Joseph Chang <joseph_chang@davicom.com.tw>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Korsgaard [Mon, 16 Dec 2013 10:35:33 +0000 (11:35 +0100)]
dm9601: fix reception of full size ethernet frames on dm9620/dm9621a
commit
407900cfb54bdb2cfa228010b6697305f66b2948 upstream.
dm9620/dm9621a require room for 4 byte padding even in dm9601 (3 byte
header) mode.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ard Biesheuvel [Mon, 23 Dec 2013 17:49:30 +0000 (18:49 +0100)]
auxvec.h: account for AT_HWCAP2 in AT_VECTOR_SIZE_BASE
commit
f60900f2609e893c7f8d0bccc7ada4947dac4cd5 upstream.
Commit
2171364d1a92 ("powerpc: Add HWCAP2 aux entry") introduced a new
AT_ auxv entry type AT_HWCAP2 but failed to update AT_VECTOR_SIZE_BASE
accordingly.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Fixes: 2171364d1a92 (powerpc: Add HWCAP2 aux entry)
Acked-by: Michael Neuling <michael@neuling.org>
Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nithin Sujir [Fri, 20 Dec 2013 01:44:11 +0000 (17:44 -0800)]
tg3: Expand 4g_overflow_test workaround to skb fragments of any size.
commit
375679104ab3ccfd18dcbd7ba503734fb9a2c63a upstream.
The current driver assumes that an skb fragment can only be upto jumbo
size. Presumably this was a fast-path optimization. This assumption is
no longer true as fragments can be upto 32k.
v2: Remove unnecessary parantheses per Eric Dumazet.
Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Li Wang [Wed, 13 Nov 2013 07:22:14 +0000 (15:22 +0800)]
ceph: Avoid data inconsistency due to d-cache aliasing in readpage()
commit
56f91aad69444d650237295f68c195b74d888d95 upstream.
If the length of data to be read in readpage() is exactly
PAGE_CACHE_SIZE, the original code does not flush d-cache
for data consistency after finishing reading. This patches fixes
this.
Signed-off-by: Li Wang <liwang@ubuntukylin.com>
Signed-off-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Mon, 23 Dec 2013 14:31:58 +0000 (09:31 -0500)]
drm/radeon: 0x9649 is SUMO2 not SUMO
commit
d00adcc8ae9e22eca9d8af5f66c59ad9a74c90ec upstream.
Fixes rendering corruption due to incorrect
gfx configuration.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=63599
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian König [Fri, 20 Dec 2013 16:48:54 +0000 (17:48 +0100)]
drm/radeon: fix UVD 256MB check
commit
bae651dbd7ade3c5d6518f89599ae680a2fe2b85 upstream.
Otherwise the kernel might reject our decoding requests.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Tue, 17 Dec 2013 14:34:50 +0000 (14:34 +0000)]
drm/i915: Use the correct GMCH_CTRL register for Sandybridge+
commit
a885b3ccc74d8e38074e1c43a47c354c5ea0b01e upstream.
The GMCH_CTRL register (or MGCC in the spec) is at a different address
on Sandybridge, and the address to which we currently write to is
undefined. These stray writes appear to upset (hard hang) my Ivybridge
machine whilst it is in UEFI mode.
Note that the register is still marked as locked RO on Sandybridge, so
vgaarb is still dysfunctional.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Fri, 20 Dec 2013 00:41:46 +0000 (19:41 -0500)]
drm/radeon: fix asic gfx values for scrapper asics
commit
e2f6c88fb903e123edfd1106b0b8310d5117f774 upstream.
Fixes gfx corruption on certain TN/RL parts.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=60389
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Tue, 10 Dec 2013 12:20:59 +0000 (13:20 +0100)]
drm/i915: don't update the dri1 breadcrumb with modesetting
commit
6c719faca2aceca72f1bf5b1645c1734ed3e9447 upstream.
The update is horribly racy since it doesn't protect at all against
concurrent closing of the master fd. And it can't really since that
requires us to grab a mutex.
Instead of jumping through hoops and offloading this to a worker
thread just block this bit of code for the modesetting driver.
Note that the race is fairly easy to hit since we call the breadcrumb
function for any interrupt. So the vblank interrupt (which usually
keeps going for a bit) is enough. But even if we'd block this and only
update the breadcrumb for user interrupts from the CS we could hit
this race with kms/gem userspace: If a non-master is waiting somewhere
(and hence has interrupts enabled) and the master closes its fd
(probably due to crashing).
v2: Add a code comment to explain why fixing this for real isn't
really worth it. Also improve the commit message a bit.
v3: Fix the spelling in the comment.
Reported-by: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Cc: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Wed, 4 Dec 2013 14:52:06 +0000 (14:52 +0000)]
drm/i915: Hold mutex across i915_gem_release
commit
0d1430a3f4b7cfd8779b78740a4182321f3ca7f3 upstream.
Inorder to serialise the closing of the file descriptor and its
subsequent release of client requests with i915_gem_free_request(), we
need to hold the struct_mutex in i915_gem_release(). Failing to do so
has the potential to trigger an OOPS, later with a use-after-free.
Testcase: igt/gem_close_race
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70874
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71029
Reported-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ville Syrjälä [Mon, 2 Dec 2013 09:08:06 +0000 (11:08 +0200)]
drm/i915: Take modeset locks around intel_modeset_setup_hw_state()
commit
027476642811f8559cbe00ef6cc54db230e48a20 upstream.
Some lower level things get angry if we don't have modeset locks
during intel_modeset_setup_hw_state(). Actually the resume and
lid_notify codepaths alreday hold the locks, but the init codepath
doesn't, so fix that.
Note: This slipped through since we only disable pipes if the
plane/pipe linking doesn't match. Which is only relevant on older
gen3 mobile machines, if the BIOS fails to set up our preferred
linking.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-and-reported-by: Paul Bolle <pebolle@tiscali.nl>
[danvet: Add note now that I could confirm my theory with the log
files Paul Bolle provided.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Wed, 11 Dec 2013 16:43:58 +0000 (11:43 -0500)]
drm/radeon: add missing display tiling setup for oland
commit
227ae10f17a5f2fd1307b7e582b603ef7bbb7e97 upstream.
Fixes improperly set up display params for 2D tiling on
oland.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Mon, 2 Dec 2013 23:15:51 +0000 (18:15 -0500)]
drm/radeon: Fix sideport problems on certain RS690 boards
commit
8333f0fe133be420ce3fcddfd568c3a559ab274e upstream.
Some RS690 boards with 64MB of sideport memory show up as
having 128MB sideport + 256MB of UMA. In this case,
just skip the sideport memory and use UMA. This fixes
rendering corruption and should improve performance.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=35457
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rafał Miłecki [Sat, 7 Dec 2013 12:22:42 +0000 (13:22 +0100)]
drm/edid: add quirk for BPC in Samsung NP700G7A-S01PL notebook
commit
49d45a31b71d7d9da74485922bdb63faf3dc9684 upstream.
This bug in EDID was exposed by:
commit
eccea7920cfb009c2fa40e9ecdce8c36f61cab66
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Mon Mar 26 15:12:54 2012 -0400
drm/radeon/kms: improve bpc handling (v2)
Which resulted in kind of regression in 3.5. This fixes
https://bugs.freedesktop.org/show_bug.cgi?id=70934
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Williams [Tue, 17 Dec 2013 18:09:32 +0000 (10:09 -0800)]
net_dma: mark broken
commit
77873803363c9e831fc1d1e6895c084279090c22 upstream.
net_dma can cause data to be copied to a stale mapping if a
copy-on-write fault occurs during dma. The application sees missing
data.
The following trace is triggered by modifying the kernel to WARN if it
ever triggers copy-on-write on a page that is undergoing dma:
WARNING: CPU: 24 PID: 2529 at lib/dma-debug.c:485 debug_dma_assert_idle+0xd2/0x120()
ioatdma 0000:00:04.0: DMA-API: cpu touching an active dma mapped page [pfn=0x16bcd9]
Modules linked in: iTCO_wdt iTCO_vendor_support ioatdma lpc_ich pcspkr dca
CPU: 24 PID: 2529 Comm: linbug Tainted: G W 3.13.0-rc1+ #353
00000000000001e5 ffff88016f45f688 ffffffff81751041 ffff88017ab0ef70
ffff88016f45f6d8 ffff88016f45f6c8 ffffffff8104ed9c ffffffff810f3646
ffff8801768f4840 0000000000000282 ffff88016f6cca10 00007fa2bb699349
Call Trace:
[<
ffffffff81751041>] dump_stack+0x46/0x58
[<
ffffffff8104ed9c>] warn_slowpath_common+0x8c/0xc0
[<
ffffffff810f3646>] ? ftrace_pid_func+0x26/0x30
[<
ffffffff8104ee86>] warn_slowpath_fmt+0x46/0x50
[<
ffffffff8139c062>] debug_dma_assert_idle+0xd2/0x120
[<
ffffffff81154a40>] do_wp_page+0xd0/0x790
[<
ffffffff811582ac>] handle_mm_fault+0x51c/0xde0
[<
ffffffff813830b9>] ? copy_user_enhanced_fast_string+0x9/0x20
[<
ffffffff8175fc2c>] __do_page_fault+0x19c/0x530
[<
ffffffff8175c196>] ? _raw_spin_lock_bh+0x16/0x40
[<
ffffffff810f3539>] ? trace_clock_local+0x9/0x10
[<
ffffffff810fa1f4>] ? rb_reserve_next_event+0x64/0x310
[<
ffffffffa0014c00>] ? ioat2_dma_prep_memcpy_lock+0x60/0x130 [ioatdma]
[<
ffffffff8175ffce>] do_page_fault+0xe/0x10
[<
ffffffff8175c862>] page_fault+0x22/0x30
[<
ffffffff81643991>] ? __kfree_skb+0x51/0xd0
[<
ffffffff813830b9>] ? copy_user_enhanced_fast_string+0x9/0x20
[<
ffffffff81388ea2>] ? memcpy_toiovec+0x52/0xa0
[<
ffffffff8164770f>] skb_copy_datagram_iovec+0x5f/0x2a0
[<
ffffffff8169d0f4>] tcp_rcv_established+0x674/0x7f0
[<
ffffffff816a68c5>] tcp_v4_do_rcv+0x2e5/0x4a0
[..]
---[ end trace
e30e3b01191b7617 ]---
Mapped at:
[<
ffffffff8139c169>] debug_dma_map_page+0xb9/0x160
[<
ffffffff8142bf47>] dma_async_memcpy_pg_to_pg+0x127/0x210
[<
ffffffff8142cce9>] dma_memcpy_pg_to_iovec+0x119/0x1f0
[<
ffffffff81669d3c>] dma_skb_copy_datagram_iovec+0x11c/0x2b0
[<
ffffffff8169d1ca>] tcp_rcv_established+0x74a/0x7f0:
...the problem is that the receive path falls back to cpu-copy in
several locations and this trace is just one of the areas. A few
options were considered to fix this:
1/ sync all dma whenever a cpu copy branch is taken
2/ modify the page fault handler to hold off while dma is in-flight
Option 1 adds yet more cpu overhead to an "offload" that struggles to compete
with cpu-copy. Option 2 adds checks for behavior that is already documented as
broken when using get_user_pages(). At a minimum a debug mode is warranted to
catch and flag these violations of the dma-api vs get_user_pages().
Thanks to David for his reproducer.
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Alexander Duyck <alexander.h.duyck@intel.com>
Reported-by: David Whipple <whipple@securedatainnovations.ch>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Richter [Sun, 15 Dec 2013 15:18:01 +0000 (16:18 +0100)]
firewire: sbp2: bring back WRITE SAME support
commit
ce027ed98fd176710fb14be9d6015697b62436f0 upstream.
Commit
54b2b50c20a6 "[SCSI] Disable WRITE SAME for RAID and virtual
host adapter drivers" disabled WRITE SAME support for all SBP-2 attached
targets. But as described in the changelog of commit
b0ea5f19d3d8
"firewire: sbp2: allow WRITE SAME and REPORT SUPPORTED OPERATION CODES",
it is not required to blacklist WRITE SAME.
Bring the feature back by reverting the sbp2.c hunk of commit
54b2b50c20a6.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kirill Tkhai [Wed, 27 Nov 2013 15:59:13 +0000 (19:59 +0400)]
sched/rt: Fix rq's cpupri leak while enqueue/dequeue child RT entities
commit
757dfcaa41844595964f1220f1d33182dae49976 upstream.
This patch touches the RT group scheduling case.
Functions inc_rt_prio_smp() and dec_rt_prio_smp() change (global) rq's
priority, while rt_rq passed to them may be not the top-level rt_rq.
This is wrong, because changing of priority on a child level does not
guarantee that the priority is the highest all over the rq. So, this
leak makes RT balancing unusable.
The short example: the task having the highest priority among all rq's
RT tasks (no one other task has the same priority) are waking on a
throttle rt_rq. The rq's cpupri is set to the task's priority
equivalent, but real rq->rt.highest_prio.curr is less.
The patch below fixes the problem.
Signed-off-by: Kirill Tkhai <tkhai@yandex.ru>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
CC: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/49231385567953@web4m.yandex.ru
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mel Gorman [Thu, 19 Dec 2013 01:08:40 +0000 (17:08 -0800)]
sched: numa: skip inaccessible VMAs
commit
3c67f474558748b604e247d92b55dfe89654c81d upstream.
Inaccessible VMA should not be trapping NUMA hint faults. Skip them.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Alex Thorlton <athorlton@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lukas Czerner [Wed, 30 Oct 2013 15:10:52 +0000 (11:10 -0400)]
ext4: fix FITRIM in no journal mode
commit
8f9ff189205a6817aee5a1f996f876541f86e07c upstream.
When using FITRIM ioctl on a file system without journal it will
only trim the block group once, no matter how many times you invoke
FITRIM ioctl and how many block you release from the block group.
It is because we only clear EXT4_GROUP_INFO_WAS_TRIMMED_BIT in journal
callback. Fix this by clearing the bit in no journal mode as well.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reported-by: Jorge Fábregas <jorge.fabregas@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
projects / firefly-linux-kernel-4.4.55.git / log