07 Jul, 2014
40 commits
-
commit 4a3a99045177369700c60d074c0e525e8093b0fc upstream.
Jan points out that I forgot to make the needed fixes to the
lz4_uncompress_unknownoutputsize() function to mirror the changes done
in lz4_decompress() with regards to potential pointer overflows.The only in-kernel user of this function is the zram code, which only
takes data from a valid compressed buffer that it made itself, so it's
not a big issue. But due to external kernel modules using this
function, it's better to be safe here.Reported-by: Jan Beulich
Cc: "Don A. Bailey"
Signed-off-by: Greg Kroah-Hartman -
commit b9cd18de4db3c9ffa7e17b0dc0ca99ed5aa4d43a upstream.
The 'sysret' fastpath does not correctly restore even all regular
registers, much less any segment registers or reflags values. That is
very much part of why it's faster than 'iret'.Normally that isn't a problem, because the normal ptrace() interface
catches the process using the signal handler infrastructure, which
always returns with an iret.However, some paths can get caught using ptrace_event() instead of the
signal path, and for those we need to make sure that we aren't going to
return to user space using 'sysret'. Otherwise the modifications that
may have been done to the register set by the tracer wouldn't
necessarily take effect.Fix it by forcing IRET path by setting TIF_NOTIFY_RESUME from
arch_ptrace_stop_needed() which is invoked from ptrace_stop().Signed-off-by: Tejun Heo
Reported-by: Andy Lutomirski
Acked-by: Oleg Nesterov
Suggested-by: Linus Torvalds
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit f44a5f45f544561302e855e7bd104e5f506ec01b upstream.
Receiving a ICMP response to an IPIP packet in a non-linear skb could
cause a kernel panic in __skb_pull.The problem was introduced in
commit f2edb9f7706dcb2c0d9a362b2ba849efe3a97f5e ("ipvs: implement
passive PMTUD for IPIP packets").Signed-off-by: Peter Christensen
Acked-by: Julian Anastasov
Signed-off-by: Simon Horman
Signed-off-by: Greg Kroah-Hartman -
commit 8c9eb041cf76038eb3b62ee259607eec9b89f48d upstream.
kvm_arch_vcpu_free() is called in 2 code paths:
1) kvm_vm_ioctl()
kvm_vm_ioctl_create_vcpu()
kvm_arch_vcpu_destroy()
kvm_arch_vcpu_free()
2) kvm_put_kvm()
kvm_destroy_vm()
kvm_arch_destroy_vm()
kvm_mips_free_vcpus()
kvm_arch_vcpu_free()Neither of the paths handles VCPU free. We need to do it in
kvm_arch_vcpu_free() corresponding to the memory allocation in
kvm_arch_vcpu_create().Signed-off-by: Deng-Cheng Zhu
Reviewed-by: James Hogan
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit c6c0a6637f9da54f9472144d44f71cf847f92e20 upstream.
The kfree() function already NULL checks the parameter so remove the
redundant NULL checks before kfree() calls in arch/mips/kvm/.Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: Gleb Natapov
Cc: kvm@vger.kernel.org
Cc: Ralf Baechle
Cc: linux-mips@linux-mips.org
Cc: Sanjay Lal
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit 22e7478ddbcb670e33fab72d0bbe7c394c3a2c84 upstream.
Prior to commit 0e4f6a791b1e (Fix reiserfs_file_release()), reiserfs
truncates serialized on i_mutex. They mostly still do, with the exception
of reiserfs_file_release. That blocks out other writers via the tailpack
mutex and the inode openers counter adjusted in reiserfs_file_open.However, NFS will call reiserfs_setattr without having called ->open, so
we end up with a race when nfs is calling ->setattr while another
process is releasing the file. Ultimately, it triggers the
BUG_ON(inode->i_size != new_file_size) check in maybe_indirect_to_direct.The solution is to pull the lock into reiserfs_setattr to encompass the
truncate_setsize call as well.Signed-off-by: Jeff Mahoney
Signed-off-by: Jan Kara
Signed-off-by: Greg Kroah-Hartman -
commit 556b8883cfac3d3203557e161ea8005f8b5479b2 upstream.
Commit daba542 ("xfs: skip verification on initial "guess"
superblock read") dropped the use of a verifier for the initial
superblock read so we can probe the sector size of the filesystem
stored in the superblock. It, however, now fails to validate that
what was read initially is actually an XFS superblock and hence will
fail the sector size check and return ENOSYS.This causes probe-based mounts to fail because it expects XFS to
return EINVAL when it doesn't recognise the superblock format.Reported-by: Plamen Petrov
Tested-by: Plamen Petrov
Signed-off-by: Dave Chinner
Reviewed-by: Christoph Hellwig
Signed-off-by: Dave Chinner
Signed-off-by: Greg Kroah-Hartman -
commit 6663a4fa6711050036562ddfd2086edf735fae21 upstream.
Commit 59a53afe70fd530040bdc69581f03d880157f15a "powerpc: Don't setup
CPUs with bad status" broke ePAPR SMP booting. ePAPR says that CPUs
that aren't presently running shall have status of disabled, with
enable-method being used to determine whether the CPU can be enabled.Fix by checking for spin-table, which is currently the only supported
enable-method.Signed-off-by: Scott Wood
Cc: Michael Neuling
Cc: Emil Medve
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit dd58a092c4202f2bd490adab7285b3ff77f8e467 upstream.
The Vector Crypto category instructions are supported by current POWER8
chips, advertise them to userspace using a specific bit to properly
differentiate with chips of the same architecture level that might not
have them.Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit 59a53afe70fd530040bdc69581f03d880157f15a upstream.
OPAL will mark a CPU that is guarded as "bad" in the status property of the CPU
node.Unfortunatley Linux doesn't check this property and will put the bad CPU in the
present map. This has caused hangs on booting when we try to unsplit the core.This patch checks the CPU is avaliable via this status property before putting
it in the present map.Signed-off-by: Michael Neuling
Tested-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit b69a1da94f3d1589d1942b5d1b384d8cfaac4500 upstream.
Commit cd64d1697cf0 ("powerpc: mtmsrd not defined") added a check for
CONFIG_PPC_CPU were a check for CONFIG_PPC_FPU was clearly intended.Fixes: cd64d1697cf0 ("powerpc: mtmsrd not defined")
Signed-off-by: Paul Bolle
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit 3df48c981d5a9610e02e9270b1bc4274fb536710 upstream.
In commit 330a1eb "Core EBB support for 64-bit book3s" I messed up
clear_task_ebb(). It clears some but not all of the task's Event Based
Branch (EBB) registers when we duplicate a task struct.That allows a child task to observe the EBBHR & EBBRR of its parent,
which it should not be able to do.Fix it by clearing EBBHR & EBBRR.
Signed-off-by: Michael Ellerman
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit 6e0fdf9af216887e0032c19d276889aad41cad00 upstream.
Commit b0d278b7d3ae ("powerpc/perf_event: Reduce latency of calling
perf_event_do_pending") added a check for CONFIG_PMAC were a check for
CONFIG_PPC_PMAC was clearly intended.Fixes: b0d278b7d3ae ("powerpc/perf_event: Reduce latency of calling perf_event_do_pending")
Signed-off-by: Paul Bolle
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit 5d73320a96fcce80286f1447864c481b5f0b96fa upstream.
commit 8f9c0119d7ba (compat: fs: Generic compat_sys_sendfile
implementation) changed the PowerPC 64bit sendfile call from
sys_sendile64 to sys_sendfile.Unfortunately this broke sendfile of lengths greater than 2G because
sys_sendfile caps at MAX_NON_LFS. Restore what we had previously which
fixes the bug.Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit c4cad90f9e9dcb85afc5e75a02ae3522ed077296 upstream.
We had a mix & match of flags used when creating legacy ports
depending on where we found them in the device-tree. Among others
we were missing UPF_SKIP_TEST for some kind of ISA ports which is
a problem as quite a few UARTs out there don't support the loopback
test (such as a lot of BMCs).Let's pick the set of flags used by the SoC code and generalize it
which means autoconf, no loopback test, irq maybe shared and fixed
port.Sending to stable as the lack of UPF_SKIP_TEST is breaking
serial on some machines so I want this back into distrosSigned-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit 09567e7fd44291bfc08accfdd67ad8f467842332 upstream.
We have a bug in our hugepage handling which exhibits as an infinite
loop of hash faults. If the fault is being taken in the kernel it will
typically trigger the softlockup detector, or the RCU stall detector.The bug is as follows:
1. mmap(0xa0000000, ..., MAP_FIXED | MAP_HUGE_TLB | MAP_ANONYMOUS ..)
2. Slice code converts the slice psize to 16M.
3. The code on lines 539-540 of slice.c in slice_get_unmapped_area()
synchronises the mm->context with the paca->context. So the paca slice
mask is updated to include the 16M slice.
3. Either:
* mmap() fails because there are no huge pages available.
* mmap() succeeds and the mapping is then munmapped.
In both cases the slice psize remains at 16M in both the paca & mm.
4. mmap(0xa0000000, ..., MAP_FIXED | MAP_ANONYMOUS ..)
5. The slice psize is converted back to 64K. Because of the check on line 539
of slice.c we DO NOT update the paca->context. The paca slice mask is now
out of sync with the mm slice mask.
6. User/kernel accesses 0xa0000000.
7. The SLB miss handler slb_allocate_realmode() **uses the paca slice mask**
to create an SLB entry and inserts it in the SLB.
18. With the 16M SLB entry in place the hardware does a hash lookup, no entry
is found so a data access exception is generated.
19. The data access handler calls do_page_fault() -> handle_mm_fault().
10. __handle_mm_fault() creates a THP mapping with do_huge_pmd_anonymous_page().
11. The hardware retries the access, there is still nothing in the hash table
so once again a data access exception is generated.
12. hash_page() calls into __hash_page_thp() and inserts a mapping in the
hash. Although the THP mapping maps 16M the hashing is done using 64K
as the segment page size.
13. hash_page() returns immediately after calling __hash_page_thp(), skipping
over the code at line 1125. Resulting in the mismatch between the
paca->context and mm->context not being detected.
14. The hardware retries the access, the hash it generates using the 16M
SLB entry does NOT match the hash we inserted.
15. We take another data access and go into __hash_page_thp().
16. We see a valid entry in the hpte_slot_array and so we call updatepp()
which succeeds.
17. Goto 14.We could fix this in two ways. The first would be to remove or modify
the check on line 539 of slice.c.The second option is to cause the check of paca psize in hash_page() on
line 1125 to also be done for THP pages.We prefer the latter, because the check & update of the paca psize is
not done until we know it's necessary. It's also done only on the
current cpu, so we don't need to IPI all other cpus.Without further rearranging the code, the simplest fix is to pull out
the code that checks paca psize and call it in two places. Firstly for
THP/hugetlb, and secondly for other mappings as before.Thanks to Dave Jones for trinity, which originally found this bug.
Signed-off-by: Michael Ellerman
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit 54f112a3837d4e7532bbedbbbf27c0de277be510 upstream.
In pseries_eeh_get_state(), EEH_STATE_UNAVAILABLE is always
overwritten by EEH_STATE_NOT_SUPPORT because of the missed
"break" there. The patch fixes the issue.Reported-by: Joe Perches
Signed-off-by: Gavin Shan
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit 18dd78c427513fb0f89365138be66e6ee8700d1b upstream.
NFS_INO_INVALID_DATA cannot be ignored, even if we have a delegation.
We're still having some problems with data corruption when multiple
clients are appending to a file and those clients are being granted
write delegations on open.To reproduce:
Client A:
vi /mnt/`hostname -s`
while :; do echo "XXXXXXXXXXXXXXX" >>/mnt/file; sleep $(( $RANDOM % 5 )); doneClient B:
vi /mnt/`hostname -s`
while :; do echo "YYYYYYYYYYYYYYY" >>/mnt/file; sleep $(( $RANDOM % 5 )); doneWhat's happening is that in nfs_update_inode() we're recognizing that
the file size has changed and we're setting NFS_INO_INVALID_DATA
accordingly, but then we ignore the cache_validity flags in
nfs_write_pageuptodate() because we have a delegation. As a result,
in nfs_updatepage() we're extending the write to cover the full page
even though we've not read in the data to begin with.Signed-off-by: Scott Mayhew
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit a914722f333b3359d2f4f12919380a334176bb89 upstream.
Otherwise the kernel oopses when remounting with IPv6 server because
net is dereferenced in dev_get_by_name.Use net ns of current thread so that dev_get_by_name does not operate on
foreign ns. Changing the address is prohibited anyway so this should not
affect anything.Signed-off-by: Mateusz Guzik
Cc: linux-nfs@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit abbec2da13f0e4c5d9b78b7e2c025a3e617228ba upstream.
The addition of lockdep code to write_seqcount_begin/end has lead to
a bunch of false positive claims of ABBA deadlocks with the so_lock
spinlock. Audits show that this simply cannot happen because the
read side code does not spin while holding so_lock.Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 43b6535e717d2f656f71d9bd16022136b781c934 upstream.
Fix a bug, whereby nfs_update_inode() was declaring the inode to be
up to date despite not having checked all the attributes.
The bug occurs because the temporary variable in which we cache
the validity information is 'sanitised' before reapplying to
nfsi->cache_validity.Reported-by: Kinglong Mee
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 12337901d654415d9f764b5f5ba50052e9700f37 upstream.
Note nobody's ever noticed because the typical client probably never
requests FILES_AVAIL without also requesting something else on the list.Signed-off-by: Christoph Hellwig
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman -
commit 48385408b45523d9a432c66292d47ef43efcbb94 upstream.
27b11428b7de ("nfsd4: remove lockowner when removing lock stateid")
introduced a memory leak.Reported-by: Jeff Layton
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman -
commit 6df200f5d5191bdde4d2e408215383890f956781 upstream.
Return the NULL pointer when the allocation fails.
Reported-by: Fengguang Wu
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit c789102c20bbbdda6831a273e046715be9d6af79 upstream.
If the accept() call fails, we need to put the module reference.
Signed-off-by: Trond Myklebust
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman -
commit 60e1751cb52cc6d1ae04b6bd3c2b96e770b5823f upstream.
Avoid that closing /dev/infiniband/umad or /dev/infiniband/issm
triggers a use-after-free. __fput() invokes f_op->release() before it
invokes cdev_put(). Make sure that the ib_umad_device structure is
freed by the cdev_put() call instead of f_op->release(). This avoids
that changing the port mode from IB into Ethernet and back to IB
followed by restarting opensmd triggers the following kernel oops:general protection fault: 0000 [#1] PREEMPT SMP
RIP: 0010:[] [] module_put+0x2c/0x170
Call Trace:
[] cdev_put+0x20/0x30
[] __fput+0x1ae/0x1f0
[] ____fput+0xe/0x10
[] task_work_run+0xac/0xe0
[] do_notify_resume+0x9f/0xc0
[] int_signal+0x12/0x17Reference: https://bugzilla.kernel.org/show_bug.cgi?id=75051
Signed-off-by: Bart Van Assche
Reviewed-by: Yann Droneaud
Signed-off-by: Roland Dreier
Signed-off-by: Greg Kroah-Hartman -
commit 8ec0a0e6b58218bdc1db91dd70ebfcd6ad8dd6cd upstream.
Avoid leaking a kref count in ib_umad_open() if port->ib_dev == NULL
or if nonseekable_open() fails.Avoid leaking a kref count, that sm_sem is kept down and also that the
IB_PORT_SM capability mask is not cleared in ib_umad_sm_open() if
nonseekable_open() fails.Since container_of() never returns NULL, remove the code that tests
whether container_of() returns NULL.Moving the kref_get() call from the start of ib_umad_*open() to the
end is safe since it is the responsibility of the caller of these
functions to ensure that the cdev pointer remains valid until at least
when these functions return.Signed-off-by: Bart Van Assche
[ydroneaud@opteya.com: rework a bit to reduce the amount of code changed]
Signed-off-by: Yann Droneaud
[ nonseekable_open() can't actually fail, but.... - Roland ]
Signed-off-by: Roland Dreier
Signed-off-by: Greg Kroah-Hartman -
commit 024ca90151f5e4296d30f72c13ff9a075e23c9ec upstream.
Avoid that the loops that iterate over the request ring can encounter
a pointer to a SCSI command in req->scmnd that is no longer associated
with that request. If the function srp_unmap_data() is invoked twice
for a SCSI command that is not in flight then that would cause
ib_fmr_pool_unmap() to be invoked with an invalid pointer as argument,
resulting in a kernel oops.Reported-by: Sagi Grimberg
Reference: http://thread.gmane.org/gmane.linux.drivers.rdma/19068/focus=19069
Signed-off-by: Bart Van Assche
Reviewed-by: Sagi Grimberg
Signed-off-by: Roland Dreier
Signed-off-by: Greg Kroah-Hartman -
commit 7e6d3e5c70f13874fb06e6b67696ed90ce79bd48 upstream.
This patch addresses an issue where the legacy diagpacket is sent in
from the user, but the driver operates on only the extended
diagpkt. This patch specifically initializes the extended diagpkt
based on the legacy packet.Reported-by: Rickard Strandqvist
Reviewed-by: Mike Marciniszyn
Signed-off-by: Dennis Dalessandro
Signed-off-by: Roland Dreier
Signed-off-by: Greg Kroah-Hartman -
commit 911eccd284d13d78c92ec4f1f1092c03457d732a upstream.
The code used a literal 1 in dispatching an IB_EVENT_PKEY_CHANGE.
As of the dual port qib QDR card, this is not necessarily correct.
Change to use the port as specified in the call.
Reported-by: Alex Estrin
Reviewed-by: Dennis Dalessandro
Signed-off-by: Mike Marciniszyn
Signed-off-by: Roland Dreier
Signed-off-by: Greg Kroah-Hartman -
commit 43bc889380c2ad9aa230eccc03a15cc52cf710d4 upstream.
The i386 ABI disagrees with most other ABIs regarding alignment of
data type larger than 4 bytes: on most ABIs a padding must be added at
end of the structures, while it is not required on i386.So for most ABIs struct mlx5_ib_create_srq gets implicitly padded to be
aligned on a 8 bytes multiple, while for i386, such padding is not
added.Tool pahole could be used to find such implicit padding:
$ pahole --anon_include \
--nested_anon_include \
--recursive \
--class_name mlx5_ib_create_srq \
drivers/infiniband/hw/mlx5/mlx5_ib.oThen, structure layout can be compared between i386 and x86_64:
# +++ obj-i386/drivers/infiniband/hw/mlx5/mlx5_ib.o.pahole.txt 2014-03-28 11:43:07.386413682 +0100
# --- obj-x86_64/drivers/infiniband/hw/mlx5/mlx5_ib.o.pahole.txt 2014-03-27 13:06:17.788472721 +0100
# @@ -69,7 +68,6 @@ struct mlx5_ib_create_srq {
# __u64 db_addr; /* 8 8 */
# __u32 flags; /* 16 4 */
#
# - /* size: 20, cachelines: 1, members: 3 */
# - /* last cacheline: 20 bytes */
# + /* size: 24, cachelines: 1, members: 3 */
# + /* padding: 4 */
# + /* last cacheline: 24 bytes */
# };ABI disagreement will make an x86_64 kernel try to read past
the buffer provided by an i386 binary.When boundary check will be implemented, the x86_64 kernel will
refuse to read past the i386 userspace provided buffer and the
uverb will fail.Anyway, if the structure lay in memory on a page boundary and
next page is not mapped, ib_copy_from_udata() will fail and the
uverb will fail.This patch makes create_srq_user() takes care of the input
data size to handle the case where no padding was provided.This way, x86_64 kernel will be able to handle struct mlx5_ib_create_srq
as sent by unpatched and patched i386 libmlx5.Link: http://marc.info/?i=cover.1399309513.git.ydroneaud@opteya.com
Fixes: e126ba97dba9e ("mlx5: Add driver for Mellanox Connect-IB adapter")
Signed-off-by: Yann Droneaud
Signed-off-by: Roland Dreier
Signed-off-by: Greg Kroah-Hartman -
commit a8237b32a3faab155a5dc8f886452147ce73da3e upstream.
The i386 ABI disagrees with most other ABIs regarding alignment of
data type larger than 4 bytes: on most ABIs a padding must be added at
end of the structures, while it is not required on i386.So for most ABI struct mlx5_ib_create_cq get padded to be aligned on a
8 bytes multiple, while for i386, such padding is not added.The tool pahole can be used to find such implicit padding:
$ pahole --anon_include \
--nested_anon_include \
--recursive \
--class_name mlx5_ib_create_cq \
drivers/infiniband/hw/mlx5/mlx5_ib.oThen, structure layout can be compared between i386 and x86_64:
# +++ obj-i386/drivers/infiniband/hw/mlx5/mlx5_ib.o.pahole.txt 2014-03-28 11:43:07.386413682 +0100
# --- obj-x86_64/drivers/infiniband/hw/mlx5/mlx5_ib.o.pahole.txt 2014-03-27 13:06:17.788472721 +0100
# @@ -34,9 +34,8 @@ struct mlx5_ib_create_cq {
# __u64 db_addr; /* 8 8 */
# __u32 cqe_size; /* 16 4 */
#
# - /* size: 20, cachelines: 1, members: 3 */
# - /* last cacheline: 20 bytes */
# + /* size: 24, cachelines: 1, members: 3 */
# + /* padding: 4 */
# + /* last cacheline: 24 bytes */
# };This ABI disagreement will make an x86_64 kernel try to read past the
buffer provided by an i386 binary.When boundary check will be implemented, a x86_64 kernel will refuse
to read past the i386 userspace provided buffer and the uverb will
fail.Anyway, if the structure lies in memory on a page boundary and next
page is not mapped, ib_copy_from_udata() will fail when trying to read
the 4 bytes of padding and the uverb will fail.This patch makes create_cq_user() takes care of the input data size to
handle the case where no padding is provided.This way, x86_64 kernel will be able to handle struct
mlx5_ib_create_cq as sent by unpatched and patched i386 libmlx5.Link: http://marc.info/?i=cover.1399309513.git.ydroneaud@opteya.com
Fixes: e126ba97dba9e ("mlx5: Add driver for Mellanox Connect-IB adapter")
Signed-off-by: Yann Droneaud
Signed-off-by: Roland Dreier
Signed-off-by: Greg Kroah-Hartman -
commit bde92cf455a03a91badb7046855592d8c008e929 upstream.
Peter Wu noticed the following splat on his machine when updating
/proc/sys/kernel/watchdog_thresh:BUG: sleeping function called from invalid context at mm/slub.c:965
in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: init
3 locks held by init/1:
#0: (sb_writers#3){.+.+.+}, at: [] vfs_write+0x143/0x180
#1: (watchdog_proc_mutex){+.+.+.}, at: [] proc_dowatchdog+0x33/0x110
#2: (cpu_hotplug.lock){.+.+.+}, at: [] get_online_cpus+0x32/0x80
Preemption disabled at:[] proc_dowatchdog+0xe4/0x110CPU: 0 PID: 1 Comm: init Not tainted 3.16.0-rc1-testing #34
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
dump_stack+0x4e/0x7a
__might_sleep+0x11d/0x190
kmem_cache_alloc_trace+0x4e/0x1e0
perf_event_alloc+0x55/0x440
perf_event_create_kernel_counter+0x26/0xe0
watchdog_nmi_enable+0x75/0x140
update_timers_all_cpus+0x53/0xa0
proc_dowatchdog+0xe4/0x110
proc_sys_call_handler+0xb3/0xc0
proc_sys_write+0x14/0x20
vfs_write+0xad/0x180
SyS_write+0x49/0xb0
system_call_fastpath+0x16/0x1b
NMI watchdog: disabled (cpu0): hardware events not enabledWhat happened is after updating the watchdog_thresh, the lockup detector
is restarted to utilize the new value. Part of this process involved
disabling preemption. Once preemption was disabled, perf tried to
allocate a new event (as part of the restart). This caused the above
BUG_ON as you can't sleep with preemption disabled.The preemption restriction seemed agressive as we are not doing anything
on that particular cpu, but with all the online cpus (which are
protected by the get_online_cpus lock). Remove the restriction and the
BUG_ON goes away.Signed-off-by: Don Zickus
Acked-by: Michal Hocko
Reported-by: Peter Wu
Tested-by: Peter Wu
Acked-by: David Rientjes
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit a9e0436b303e94ba57d3bd4b1fcbeaa744b7ebeb upstream.
Use the prescaler index, rather than its value, to configure the watchdog.
This will prevent a mismatch with the prescaler used to calculate the cycles.Signed-off-by: Per Gundberg
Reviewed-by: Guenter Roeck
Reviewed-by: Michael Brunner
Tested-by: Michael Brunner
Signed-off-by: Wim Van Sebroeck
Signed-off-by: Greg Kroah-Hartman -
commit 23afeb613ec0e10aecfae7838a14d485db62ac52 upstream.
On some AR934x based systems, where the frequency of
the AHB bus is relatively high, the built-in watchdog
causes a spurious restart when it gets enabled.The possible cause of these restarts is that the timeout
value written into the TIMER register does not reaches
the hardware in time.Add an explicit delay into the ath79_wdt_enable function
to avoid the spurious restarts.Signed-off-by: Gabor Juhos
Reviewed-by: Guenter Roeck
Signed-off-by: Wim Van Sebroeck
Signed-off-by: Greg Kroah-Hartman -
commit 938626d96a3ffb9eb54552bb0d3a4f2b30ffdeb0 upstream.
Implementation of ->set_timeout() is supposed to set 'timeout' field of 'struct
watchdog_device' passed to it. sp805 was rather setting this in a local
variable. Fix it.Reported-by: Arun Ramamurthy
Signed-off-by: Viresh Kumar
Reviewed-by: Guenter Roeck
Signed-off-by: Wim Van Sebroeck
Signed-off-by: Greg Kroah-Hartman -
commit 72abc8f4b4e8574318189886de627a2bfe6cd0da upstream.
I hit the same assert failed as Dolev Raviv reported in Kernel v3.10
shows like this:[ 9641.164028] UBIFS assert failed in shrink_tnc at 131 (pid 13297)
[ 9641.234078] CPU: 1 PID: 13297 Comm: mmap.test Tainted: G O 3.10.40 #1
[ 9641.234116] [] (unwind_backtrace+0x0/0x12c) from [] (show_stack+0x20/0x24)
[ 9641.234137] [] (show_stack+0x20/0x24) from [] (dump_stack+0x20/0x28)
[ 9641.234188] [] (dump_stack+0x20/0x28) from [] (shrink_tnc_trees+0x25c/0x350 [ubifs])
[ 9641.234265] [] (shrink_tnc_trees+0x25c/0x350 [ubifs]) from [] (ubifs_shrinker+0x25c/0x310 [ubifs])
[ 9641.234307] [] (ubifs_shrinker+0x25c/0x310 [ubifs]) from [] (shrink_slab+0x1d4/0x2f8)
[ 9641.234327] [] (shrink_slab+0x1d4/0x2f8) from [] (do_try_to_free_pages+0x300/0x544)
[ 9641.234344] [] (do_try_to_free_pages+0x300/0x544) from [] (try_to_free_pages+0x2d0/0x398)
[ 9641.234363] [] (try_to_free_pages+0x2d0/0x398) from [] (__alloc_pages_nodemask+0x494/0x7e8)
[ 9641.234382] [] (__alloc_pages_nodemask+0x494/0x7e8) from [] (new_slab+0x78/0x238)
[ 9641.234400] [] (new_slab+0x78/0x238) from [] (__slab_alloc.constprop.42+0x1a4/0x50c)
[ 9641.234419] [] (__slab_alloc.constprop.42+0x1a4/0x50c) from [] (kmem_cache_alloc_trace+0x54/0x188)
[ 9641.234459] [] (kmem_cache_alloc_trace+0x54/0x188) from [] (do_readpage+0x168/0x468 [ubifs])
[ 9641.234553] [] (do_readpage+0x168/0x468 [ubifs]) from [] (ubifs_readpage+0x424/0x464 [ubifs])
[ 9641.234606] [] (ubifs_readpage+0x424/0x464 [ubifs]) from [] (filemap_fault+0x304/0x418)
[ 9641.234638] [] (filemap_fault+0x304/0x418) from [] (__do_fault+0xd4/0x530)
[ 9641.234665] [] (__do_fault+0xd4/0x530) from [] (handle_pte_fault+0x480/0xf54)
[ 9641.234690] [] (handle_pte_fault+0x480/0xf54) from [] (handle_mm_fault+0x140/0x184)
[ 9641.234716] [] (handle_mm_fault+0x140/0x184) from [] (do_page_fault+0x150/0x3ac)
[ 9641.234737] [] (do_page_fault+0x150/0x3ac) from [] (do_DataAbort+0x3c/0xa0)
[ 9641.234759] [] (do_DataAbort+0x3c/0xa0) from [] (__dabt_usr+0x38/0x40)After analyzing the code, I found a condition that may cause this failed
in correct operations. Thus, I think this assertion is wrong and should be
removed.Suppose there are two clean znodes and one dirty znode in TNC. So the
per-filesystem atomic_t @clean_zn_cnt is (2). If commit start, dirty_znode
is set to COW_ZNODE in get_znodes_to_commit() in case of potentially ops
on this znode. We clear COW bit and DIRTY bit in write_index() without
@tnc_mutex locked. We don't increase @clean_zn_cnt in this place. As the
comments in write_index() shows, if another process hold @tnc_mutex and
dirty this znode after we clean it, @clean_zn_cnt would be decreased to (1).
We will increase @clean_zn_cnt to (2) with @tnc_mutex locked in
free_obsolete_znodes() to keep it right.If shrink_tnc() performs between decrease and increase, it will release
other 2 clean znodes it holds and found @clean_zn_cnt is less than zero
(1 - 2 = -1), then hit the assertion. Because free_obsolete_znodes() will
soon correct @clean_zn_cnt and no harm to fs in this case, I think this
assertion could be removed.2 clean zondes and 1 dirty znode, @clean_zn_cnt == 2
Thread A (commit) Thread B (write or others) Thread C (shrinker)
->write_index
->clear_bit(DIRTY_NODE)
->clear_bit(COW_ZNODE)@clean_zn_cnt == 2
->mutex_locked(&tnc_mutex)
->dirty_cow_znode
->!ubifs_zn_cow(znode)
->!test_and_set_bit(DIRTY_NODE)
->atomic_dec(&clean_zn_cnt)
->mutex_unlocked(&tnc_mutex)@clean_zn_cnt == 1
->mutex_locked(&tnc_mutex)
->shrink_tnc
->destroy_tnc_subtree
->atomic_sub(&clean_zn_cnt, 2)
->ubifs_assert mutex_unlocked(&tnc_mutex)@clean_zn_cnt == -1
->mutex_lock(&tnc_mutex)
->free_obsolete_znodes
->atomic_inc(&clean_zn_cnt)
->mutux_unlock(&tnc_mutex)@clean_zn_cnt == 0 (correct after shrink)
Signed-off-by: hujianyang
Signed-off-by: Artem Bityutskiy
Signed-off-by: Greg Kroah-Hartman -
commit 691a7c6f28ac90cccd0dbcf81348ea90b211bdd0 upstream.
There is a race condition in UBIFS:
Thread A (mmap) Thread B (fsync)
->__do_fault ->write_cache_pages
-> ubifs_vm_page_mkwrite
-> budget_space
-> lock_page
-> release/convert_page_budget
-> SetPagePrivate
-> TestSetPageDirty
-> unlock_page
-> lock_page
-> TestClearPageDirty
-> ubifs_writepage
-> do_writepage
-> release_budget
-> ClearPagePrivate
-> unlock_page
-> !(ret & VM_FAULT_LOCKED)
-> lock_page
-> set_page_dirty
-> ubifs_set_page_dirty
-> TestSetPageDirty (set page dirty without budgeting)
-> unlock_pageThis leads to situation where we have a diry page but no budget allocated for
this page, so further write-back may fail with -ENOSPC.In this fix we return from page_mkwrite without performing unlock_page. We
return VM_FAULT_LOCKED instead. After doing this, the race above will not
happen.Signed-off-by: hujianyang
Tested-by: Laurence Withers
Signed-off-by: Artem Bityutskiy
Signed-off-by: Greg Kroah-Hartman -
commit ab6c15bc6620ebe220970cc040b29bcb2757f373 upstream.
Previously, the lower limit for the MIPS SC initialization loop was
set incorrectly allowing one extra loop leading to writes
beyond the MSC ioremap'd space. More precisely, the value of the 'imp'
in the last loop increased beyond the msc_irqmap_t boundaries and
as a result of which, the 'n' variable was loaded with an incorrect
value. This value was used later on to calculate the offset in the
MSC01_IC_SUP which led to random crashes like the following one:CPU 0 Unable to handle kernel paging request at virtual address e75c0200,
epc == 8058dba4, ra == 8058db90
[...]
Call Trace:
[] init_msc_irqs+0x104/0x154
[] arch_init_irq+0xd8/0x154
[] start_kernel+0x220/0x36cKernel panic - not syncing: Attempted to kill the idle task!
This patch fixes the problem
Signed-off-by: Markos Chandras
Reviewed-by: James Hogan
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7118/
Signed-off-by: Ralf Baechle
Signed-off-by: Greg Kroah-Hartman -
commit 91ad11d7cc6f4472ebf177a6252fbf0fd100d798 upstream.
On MIPS calls to _mcount in modules generate 2 instructions to load
the _mcount address (and therefore 2 relocations). The mcount_loc
table should only reference the first of these, so the second is
filtered out by checking the relocation offset and ignoring ones that
immediately follow the previous one seen.However if a module has an _mcount call at offset 0, the second
relocation would not be filtered out due to old_r_offset == 0
being taken to mean that the current relocation is the first one
seen, and both would end up in the mcount_loc table.This results in ftrace_make_nop() patching both (adjacent)
instructions to branches over the _mcount call sequence like so:0xffffffffc08a8000: 04 00 00 10 b 0xffffffffc08a8014
0xffffffffc08a8004: 04 00 00 10 b 0xffffffffc08a8018
0xffffffffc08a8008: 2d 08 e0 03 move at,ra
...The second branch is in the delay slot of the first, which is
defined to be unpredictable - on the platform on which this bug was
encountered, it triggers a reserved instruction exception.Fix by initializing old_r_offset to ~0 and using that instead of 0
to determine whether the current relocation is the first seen.Signed-off-by: Alex Smith
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7098/
Signed-off-by: Ralf Baechle
Signed-off-by: Greg Kroah-Hartman
