Michael Ellerman [Sat, 26 May 2018 04:27:40 +0000 (14:27 +1000)]
powerpc/64s: Enhance the information in cpu_show_meltdown()
commit
ff348355e9c72493947be337bb4fae4fc1a41eba upstream.
Now that we have the security feature flags we can make the
information displayed in the "meltdown" file more informative.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ellerman [Sat, 26 May 2018 04:27:39 +0000 (14:27 +1000)]
powerpc/64s: Move cpu_show_meltdown()
commit
8ad33041563a10b34988800c682ada14b2612533 upstream.
This landed in setup_64.c for no good reason other than we had nowhere
else to put it. Now that we have a security-related file, that is a
better place for it so move it.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ellerman [Sat, 26 May 2018 04:27:38 +0000 (14:27 +1000)]
powerpc/powernv: Set or clear security feature flags
commit
77addf6e95c8689e478d607176b399a6242a777e upstream.
Now that we have feature flags for security related things, set or
clear them based on what we see in the device tree provided by
firmware.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ellerman [Sat, 26 May 2018 04:27:37 +0000 (14:27 +1000)]
powerpc/pseries: Set or clear security feature flags
commit
f636c14790ead6cc22cf62279b1f8d7e11a67116 upstream.
Now that we have feature flags for security related things, set or
clear them based on what we receive from the hypercall.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ellerman [Sat, 26 May 2018 04:27:36 +0000 (14:27 +1000)]
powerpc: Add security feature flags for Spectre/Meltdown
commit
9a868f634349e62922c226834aa23e3d1329ae7f upstream.
This commit adds security feature flags to reflect the settings we
receive from firmware regarding Spectre/Meltdown mitigations.
The feature names reflect the names we are given by firmware on bare
metal machines. See the hostboot source for details.
Arguably these could be firmware features, but that then requires them
to be read early in boot so they're available prior to asm feature
patching, but we don't actually want to use them for patching. We may
also want to dynamically update them in future, which would be
incompatible with the way firmware features work (at the moment at
least). So for now just make them separate flags.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ellerman [Sat, 26 May 2018 04:27:35 +0000 (14:27 +1000)]
powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags
commit
c4bc36628d7f8b664657d8bd6ad1c44c177880b7 upstream.
Add some additional values which have been defined for the
H_GET_CPU_CHARACTERISTICS hypercall.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ellerman [Sat, 26 May 2018 04:27:34 +0000 (14:27 +1000)]
powerpc/rfi-flush: Call setup_rfi_flush() after LPM migration
commit
921bc6cf807ceb2ab8005319cf39f33494d6b100 upstream.
We might have migrated to a machine that uses a different flush type,
or doesn't need flushing at all.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauricio Faria de Oliveira [Sat, 26 May 2018 04:27:33 +0000 (14:27 +1000)]
powerpc/rfi-flush: Differentiate enabled and patched flush types
commit
0063d61ccfc011f379a31acaeba6de7c926fed2c upstream.
Currently the rfi-flush messages print 'Using <type> flush' for all
enabled_flush_types, but that is not necessarily true -- as now the
fallback flush is always enabled on pseries, but the fixup function
overwrites its nop/branch slot with other flush types, if available.
So, replace the 'Using <type> flush' messages with '<type> flush is
available'.
Also, print the patched flush types in the fixup function, so users
can know what is (not) being used (e.g., the slower, fallback flush,
or no flush type at all if flush is disabled via the debugfs switch).
Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ellerman [Sat, 26 May 2018 04:27:32 +0000 (14:27 +1000)]
powerpc/rfi-flush: Always enable fallback flush on pseries
commit
84749a58b6e382f109abf1e734bc4dd43c2c25bb upstream.
This ensures the fallback flush area is always allocated on pseries,
so in case a LPAR is migrated from a patched to an unpatched system,
it is possible to enable the fallback flush in the target system.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ellerman [Sat, 26 May 2018 04:27:31 +0000 (14:27 +1000)]
powerpc/rfi-flush: Make it possible to call setup_rfi_flush() again
commit
abf110f3e1cea40f5ea15e85f5d67c39c14568a7 upstream.
For PowerVM migration we want to be able to call setup_rfi_flush()
again after we've migrated the partition.
To support that we need to check that we're not trying to allocate the
fallback flush area after memblock has gone away (i.e., boot-time only).
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ellerman [Sat, 26 May 2018 04:27:30 +0000 (14:27 +1000)]
powerpc/rfi-flush: Move the logic to avoid a redo into the debugfs code
commit
1e2a9fc7496955faacbbed49461d611b704a7505 upstream.
rfi_flush_enable() includes a check to see if we're already
enabled (or disabled), and in that case does nothing.
But that means calling setup_rfi_flush() a 2nd time doesn't actually
work, which is a bit confusing.
Move that check into the debugfs code, where it really belongs.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ellerman [Sat, 26 May 2018 04:27:29 +0000 (14:27 +1000)]
powerpc/powernv: Support firmware disable of RFI flush
commit
eb0a2d2620ae431c543963c8c7f08f597366fc60 upstream.
Some versions of firmware will have a setting that can be configured
to disable the RFI flush, add support for it.
Fixes:
6e032b350cd1 ("powerpc/powernv: Check device-tree for RFI flush settings")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ellerman [Sat, 26 May 2018 04:27:28 +0000 (14:27 +1000)]
powerpc/pseries: Support firmware disable of RFI flush
commit
582605a429e20ae68fd0b041b2e840af296edd08 upstream.
Some versions of firmware will have a setting that can be configured
to disable the RFI flush, add support for it.
Fixes:
8989d56878a7 ("powerpc/pseries: Query hypervisor for RFI flush settings")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Piggin [Sat, 26 May 2018 04:27:27 +0000 (14:27 +1000)]
powerpc/64s: Improve RFI L1-D cache flush fallback
commit
bdcb1aefc5b3f7d0f1dc8b02673602bca2ff7a4b upstream.
The fallback RFI flush is used when firmware does not provide a way
to flush the cache. It's a "displacement flush" that evicts useful
data by displacing it with an uninteresting buffer.
The flush has to take care to work with implementation specific cache
replacment policies, so the recipe has been in flux. The initial
slow but conservative approach is to touch all lines of a congruence
class, with dependencies between each load. It has since been
determined that a linear pattern of loads without dependencies is
sufficient, and is significantly faster.
Measuring the speed of a null syscall with RFI fallback flush enabled
gives the relative improvement:
P8 - 1.83x
P9 - 1.75x
The flush also becomes simpler and more adaptable to different cache
geometries.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Vrabel [Fri, 18 May 2018 15:55:46 +0000 (16:55 +0100)]
x86/kvm: fix LAPIC timer drift when guest uses periodic mode
commit
d8f2f498d9ed0c5010bc1bbc1146f94c8bf9f8cc upstream.
Since 4.10, commit
8003c9ae204e (KVM: LAPIC: add APIC Timer
periodic/oneshot mode VMX preemption timer support), guests using
periodic LAPIC timers (such as FreeBSD 8.4) would see their timers
drift significantly over time.
Differences in the underlying clocks and numerical errors means the
periods of the two timers (hv and sw) are not the same. This
difference will accumulate with every expiry resulting in a large
error between the hv and sw timer.
This means the sw timer may be running slow when compared to the hv
timer. When the timer is switched from hv to sw, the now active sw
timer will expire late. The guest VCPU is reentered and it switches to
using the hv timer. This timer catches up, injecting multiple IRQs
into the guest (of which the guest only sees one as it does not get to
run until the hv timer has caught up) and thus the guest's timer rate
is low (and becomes increasing slower over time as the sw timer lags
further and further behind).
I believe a similar problem would occur if the hv timer is the slower
one, but I have not observed this.
Fix this by synchronizing the deadlines for both timers to the same
time source on every tick. This prevents the errors from accumulating.
Fixes:
8003c9ae204e21204e49816c5ea629357e283b06
Cc: Wanpeng Li <wanpeng.li@hotmail.com>
Signed-off-by: David Vrabel <david.vrabel@nutanix.com>
Cc: stable@vger.kernel.org
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Wanpeng Li <wanpengli@tencent.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jim Mattson [Wed, 9 May 2018 21:29:35 +0000 (14:29 -0700)]
kvm: x86: IA32_ARCH_CAPABILITIES is always supported
commit
1eaafe91a0df4157521b6417b3dd8430bf5f52f0 upstream.
If there is a possibility that a VM may migrate to a Skylake host,
then the hypervisor should report IA32_ARCH_CAPABILITIES.RSBA[bit 2]
as being set (future work, of course). This implies that
CPUID.(EAX=7,ECX=0):EDX.ARCH_CAPABILITIES[bit 29] should be
set. Therefore, kvm should report this CPUID bit as being supported
whether or not the host supports it. Userspace is still free to clear
the bit if it chooses.
For more information on RSBA, see Intel's white paper, "Retpoline: A
Branch Target Injection Mitigation" (Document Number 337131-001),
currently available at https://bugzilla.kernel.org/show_bug.cgi?id=199511.
Since the IA32_ARCH_CAPABILITIES MSR is emulated in kvm, there is no
dependency on hardware support for this feature.
Signed-off-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Fixes:
28c1c9fabf48 ("KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES")
Cc: stable@vger.kernel.org
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wei Huang [Tue, 1 May 2018 14:49:54 +0000 (09:49 -0500)]
KVM: x86: Update cpuid properly when CR4.OSXAVE or CR4.PKE is changed
commit
c4d2188206bafa177ea58e9a25b952baa0bf7712 upstream.
The CPUID bits of OSXSAVE (function=0x1) and OSPKE (func=0x7, leaf=0x0)
allows user apps to detect if OS has set CR4.OSXSAVE or CR4.PKE. KVM is
supposed to update these CPUID bits when CR4 is updated. Current KVM
code doesn't handle some special cases when updates come from emulator.
Here is one example:
Step 1: guest boots
Step 2: guest OS enables XSAVE ==> CR4.OSXSAVE=1 and CPUID.OSXSAVE=1
Step 3: guest hot reboot ==> QEMU reset CR4 to 0, but CPUID.OSXAVE==1
Step 4: guest os checks CPUID.OSXAVE, detects 1, then executes xgetbv
Step 4 above will cause an #UD and guest crash because guest OS hasn't
turned on OSXAVE yet. This patch solves the problem by comparing the the
old_cr4 with cr4. If the related bits have been changed,
kvm_update_cpuid() needs to be called.
Signed-off-by: Wei Huang <wei@redhat.com>
Reviewed-by: Bandan Das <bsd@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Hildenbrand [Wed, 9 May 2018 14:12:17 +0000 (16:12 +0200)]
KVM: s390: vsie: fix < 8k check for the itdba
commit
f4a551b72358facbbe5714248dff78404272feee upstream.
By missing an "L", we might detect some addresses to be <8k,
although they are not.
e.g. for itdba =
100001fff
!(gpa & ~0x1fffU) -> 1
!(gpa & ~0x1fffUL) -> 0
So we would report a SIE validity intercept although everything is fine.
Fixes: 166ecb3 ("KVM: s390: vsie: support transactional execution")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Konrad Rzeszutek Wilk [Mon, 21 May 2018 21:54:49 +0000 (17:54 -0400)]
KVM/VMX: Expose SSBD properly to guests
commit
0aa48468d00959c8a37cd3ac727284f4f7359151 upstream.
The X86_FEATURE_SSBD is an synthetic CPU feature - that is
it bit location has no relevance to the real CPUID 0x7.EBX[31]
bit position. For that we need the new CPU feature name.
Fixes:
52817587e706 ("x86/cpufeatures: Disentangle SSBD enumeration")
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: kvm@vger.kernel.org
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: stable@vger.kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Link: https://lkml.kernel.org/r/20180521215449.26423-2-konrad.wilk@oracle.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gustavo A. R. Silva [Fri, 25 May 2018 21:47:57 +0000 (14:47 -0700)]
kernel/sys.c: fix potential Spectre v1 issue
commit
23d6aef74da86a33fa6bb75f79565e0a16ee97c2 upstream.
`resource' can be controlled by user-space, hence leading to a potential
exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
kernel/sys.c:1474 __do_compat_sys_old_getrlimit() warn: potential spectre issue 'get_current()->signal->rlim' (local cap)
kernel/sys.c:1455 __do_sys_old_getrlimit() warn: potential spectre issue 'get_current()->signal->rlim' (local cap)
Fix this by sanitizing *resource* before using it to index
current->signal->rlim
Notice that given that speculation windows are large, the policy is to
kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel&m=
152449131114778&w=2
Link: http://lkml.kernel.org/r/20180515030038.GA11822@embeddedor.com
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: <stable@vger.kernel.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>
David Hildenbrand [Fri, 25 May 2018 21:48:11 +0000 (14:48 -0700)]
kasan: fix memory hotplug during boot
commit
3f1959721558a976aaf9c2024d5bc884e6411bf7 upstream.
Using module_init() is wrong. E.g. ACPI adds and onlines memory before
our memory notifier gets registered.
This makes sure that ACPI memory detected during boot up will not result
in a kernel crash.
Easily reproducible with QEMU, just specify a DIMM when starting up.
Link: http://lkml.kernel.org/r/20180522100756.18478-3-david@redhat.com
Fixes:
786a8959912e ("kasan: disable memory hotplug")
Signed-off-by: David Hildenbrand <david@redhat.com>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.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>
David Hildenbrand [Fri, 25 May 2018 21:48:08 +0000 (14:48 -0700)]
kasan: free allocated shadow memory on MEM_CANCEL_ONLINE
commit
ed1596f9ab958dd156a66c9ff1029d3761c1786a upstream.
We have to free memory again when we cancel onlining, otherwise a later
onlining attempt will fail.
Link: http://lkml.kernel.org/r/20180522100756.18478-2-david@redhat.com
Fixes:
fa69b5989bb0 ("mm/kasan: add support for memory hotplug")
Signed-off-by: David Hildenbrand <david@redhat.com>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.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>
Andrey Ryabinin [Fri, 25 May 2018 21:47:38 +0000 (14:47 -0700)]
mm/kasan: don't vfree() nonexistent vm_area
commit
0f901dcbc31f88ae41a2aaa365f7802b5d520a28 upstream.
KASAN uses different routines to map shadow for hot added memory and
memory obtained in boot process. Attempt to offline memory onlined by
normal boot process leads to this:
Trying to vfree() nonexistent vm area (
000000005d3b34b9)
WARNING: CPU: 2 PID: 13215 at mm/vmalloc.c:1525 __vunmap+0x147/0x190
Call Trace:
kasan_mem_notifier+0xad/0xb9
notifier_call_chain+0x166/0x260
__blocking_notifier_call_chain+0xdb/0x140
__offline_pages+0x96a/0xb10
memory_subsys_offline+0x76/0xc0
device_offline+0xb8/0x120
store_mem_state+0xfa/0x120
kernfs_fop_write+0x1d5/0x320
__vfs_write+0xd4/0x530
vfs_write+0x105/0x340
SyS_write+0xb0/0x140
Obviously we can't call vfree() to free memory that wasn't allocated via
vmalloc(). Use find_vm_area() to see if we can call vfree().
Unfortunately it's a bit tricky to properly unmap and free shadow
allocated during boot, so we'll have to keep it. If memory will come
online again that shadow will be reused.
Matthew asked: how can you call vfree() on something that isn't a
vmalloc address?
vfree() is able to free any address returned by
__vmalloc_node_range(). And __vmalloc_node_range() gives you any
address you ask. It doesn't have to be an address in [VMALLOC_START,
VMALLOC_END] range.
That's also how the module_alloc()/module_memfree() works on
architectures that have designated area for modules.
[aryabinin@virtuozzo.com: improve comments]
Link: http://lkml.kernel.org/r/dabee6ab-3a7a-51cd-3b86-5468718e0390@virtuozzo.com
[akpm@linux-foundation.org: fix typos, reflow comment]
Link: http://lkml.kernel.org/r/20180201163349.8700-1-aryabinin@virtuozzo.com
Fixes:
fa69b5989bb0 ("mm/kasan: add support for memory hotplug")
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Reported-by: Paul Menzel <pmenzel+linux-kasan-dev@molgen.mpg.de>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: <stable@vger.kernel.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>
Davidlohr Bueso [Fri, 25 May 2018 21:47:30 +0000 (14:47 -0700)]
ipc/shm: fix shmat() nil address after round-down when remapping
commit
8f89c007b6dec16a1793cb88de88fcc02117bbbc upstream.
shmat()'s SHM_REMAP option forbids passing a nil address for; this is in
fact the very first thing we check for. Andrea reported that for
SHM_RND|SHM_REMAP cases we can end up bypassing the initial addr check,
but we need to check again if the address was rounded down to nil. As
of this patch, such cases will return -EINVAL.
Link: http://lkml.kernel.org/r/20180503204934.kk63josdu6u53fbd@linux-n805
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Reported-by: Andrea Arcangeli <aarcange@redhat.com>
Cc: Joe Lawrence <joe.lawrence@redhat.com>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: <stable@vger.kernel.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>
Davidlohr Bueso [Fri, 25 May 2018 21:47:27 +0000 (14:47 -0700)]
Revert "ipc/shm: Fix shmat mmap nil-page protection"
commit
a73ab244f0dad8fffb3291b905f73e2d3eaa7c00 upstream.
Patch series "ipc/shm: shmat() fixes around nil-page".
These patches fix two issues reported[1] a while back by Joe and Andrea
around how shmat(2) behaves with nil-page.
The first reverts a commit that it was incorrectly thought that mapping
nil-page (address=0) was a no no with MAP_FIXED. This is not the case,
with the exception of SHM_REMAP; which is address in the second patch.
I chose two patches because it is easier to backport and it explicitly
reverts bogus behaviour. Both patches ought to be in -stable and ltp
testcases need updated (the added testcase around the cve can be
modified to just test for SHM_RND|SHM_REMAP).
[1] lkml.kernel.org/r/
20180430172152.nfa564pvgpk3ut7p@linux-n805
This patch (of 2):
Commit
95e91b831f87 ("ipc/shm: Fix shmat mmap nil-page protection")
worked on the idea that we should not be mapping as root addr=0 and
MAP_FIXED. However, it was reported that this scenario is in fact
valid, thus making the patch both bogus and breaks userspace as well.
For example X11's libint10.so relies on shmat(1, SHM_RND) for lowmem
initialization[1].
[1] https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/linux/int10/linux.c#n347
Link: http://lkml.kernel.org/r/20180503203243.15045-2-dave@stgolabs.net
Fixes:
95e91b831f87 ("ipc/shm: Fix shmat mmap nil-page protection")
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Reported-by: Joe Lawrence <joe.lawrence@redhat.com>
Reported-by: Andrea Arcangeli <aarcange@redhat.com>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: <stable@vger.kernel.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>
Matthew Wilcox [Fri, 25 May 2018 21:47:24 +0000 (14:47 -0700)]
idr: fix invalid ptr dereference on item delete
commit
7a4deea1aa8bddfed4ef1b35fc2b6732563d8ad5 upstream.
If the radix tree underlying the IDR happens to be full and we attempt
to remove an id which is larger than any id in the IDR, we will call
__radix_tree_delete() with an uninitialised 'slot' pointer, at which
point anything could happen. This was easiest to hit with a single
entry at id 0 and attempting to remove a non-0 id, but it could have
happened with 64 entries and attempting to remove an id >= 64.
Roman said:
The syzcaller test boils down to opening /dev/kvm, creating an
eventfd, and calling a couple of KVM ioctls. None of this requires
superuser. And the result is dereferencing an uninitialized pointer
which is likely a crash. The specific path caught by syzbot is via
KVM_HYPERV_EVENTD ioctl which is new in 4.17. But I guess there are
other user-triggerable paths, so cc:stable is probably justified.
Matthew added:
We have around 250 calls to idr_remove() in the kernel today. Many of
them pass an ID which is embedded in the object they're removing, so
they're safe. Picking a few likely candidates:
drivers/firewire/core-cdev.c looks unsafe; the ID comes from an ioctl.
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c is similar
drivers/atm/nicstar.c could be taken down by a handcrafted packet
Link: http://lkml.kernel.org/r/20180518175025.GD6361@bombadil.infradead.org
Fixes:
0a835c4f090a ("Reimplement IDR and IDA using the radix tree")
Reported-by: <syzbot+35666cba7f0a337e2e79@syzkaller.appspotmail.com>
Debugged-by: Roman Kagan <rkagan@virtuozzo.com>
Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
Cc: <stable@vger.kernel.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>
Jens Axboe [Mon, 21 May 2018 18:21:14 +0000 (12:21 -0600)]
sr: pass down correctly sized SCSI sense buffer
commit
f7068114d45ec55996b9040e98111afa56e010fe upstream.
We're casting the CDROM layer request_sense to the SCSI sense
buffer, but the former is 64 bytes and the latter is 96 bytes.
As we generally allocate these on the stack, we end up blowing
up the stack.
Fix this by wrapping the scsi_execute() call with a properly
sized sense buffer, and copying back the bits for the CDROM
layer.
Cc: stable@vger.kernel.org
Reported-by: Piotr Gabriel Kosinski <pg.kosinski@gmail.com>
Reported-by: Daniel Shapira <daniel@twistlock.com>
Tested-by: Kees Cook <keescook@chromium.org>
Fixes:
82ed4db499b8 ("block: split scsi_request out of struct request")
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lidong Chen [Tue, 8 May 2018 08:50:16 +0000 (16:50 +0800)]
IB/umem: Use the correct mm during ib_umem_release
commit
8e907ed4882714fd13cfe670681fc6cb5284c780 upstream.
User-space may invoke ibv_reg_mr and ibv_dereg_mr in different threads.
If ibv_dereg_mr is called after the thread which invoked ibv_reg_mr has
exited, get_pid_task will return NULL and ib_umem_release will not
decrease mm->pinned_vm.
Instead of using threads to locate the mm, use the overall tgid from the
ib_ucontext struct instead. This matches the behavior of ODP and
disassociate in handling the mm of the process that called ibv_reg_mr.
Cc: <stable@vger.kernel.org>
Fixes:
87773dd56d54 ("IB: ib_umem_release() should decrement mm->pinned_vm from ib_umem_get")
Signed-off-by: Lidong Chen <lidongchen@tencent.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael J. Ruhl [Wed, 2 May 2018 13:42:51 +0000 (06:42 -0700)]
IB/hfi1: Use after free race condition in send context error path
commit
f9e76ca3771bf23d2142a81a88ddd8f31f5c4c03 upstream.
A pio send egress error can occur when the PSM library attempts to
to send a bad packet. That issue is still being investigated.
The pio error interrupt handler then attempts to progress the recovery
of the errored pio send context.
Code inspection reveals that the handling lacks the necessary locking
if that recovery interleaves with a PSM close of the "context" object
contains the pio send context.
The lack of the locking can cause the recovery to access the already
freed pio send context object and incorrectly deduce that the pio
send context is actually a kernel pio send context as shown by the
NULL deref stack below:
[<
ffffffff8143d78c>] _dev_info+0x6c/0x90
[<
ffffffffc0613230>] sc_restart+0x70/0x1f0 [hfi1]
[<
ffffffff816ab124>] ? __schedule+0x424/0x9b0
[<
ffffffffc06133c5>] sc_halted+0x15/0x20 [hfi1]
[<
ffffffff810aa3ba>] process_one_work+0x17a/0x440
[<
ffffffff810ab086>] worker_thread+0x126/0x3c0
[<
ffffffff810aaf60>] ? manage_workers.isra.24+0x2a0/0x2a0
[<
ffffffff810b252f>] kthread+0xcf/0xe0
[<
ffffffff810b2460>] ? insert_kthread_work+0x40/0x40
[<
ffffffff816b8798>] ret_from_fork+0x58/0x90
[<
ffffffff810b2460>] ? insert_kthread_work+0x40/0x40
This is the best case scenario and other scenarios can corrupt the
already freed memory.
Fix by adding the necessary locking in the pio send context error
handler.
Cc: <stable@vger.kernel.org> # 4.9.x
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Neuling [Fri, 18 May 2018 01:37:42 +0000 (11:37 +1000)]
powerpc/64s: Clear PCR on boot
commit
faf37c44a105f3608115785f17cbbf3500f8bc71 upstream.
Clear the PCR (Processor Compatibility Register) on boot to ensure we
are not running in a compatibility mode.
We've seen this cause problems when a crash (and kdump) occurs while
running compat mode guests. The kdump kernel then runs with the PCR
set and causes problems. The symptom in the kdump kernel (also seen in
petitboot after fast-reboot) is early userspace programs taking
sigills on newer instructions (seen in libc).
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: stable@vger.kernel.org
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Will Deacon [Mon, 21 May 2018 16:44:57 +0000 (17:44 +0100)]
arm64: lse: Add early clobbers to some input/output asm operands
commit
32c3fa7cdf0c4a3eb8405fc3e13398de019e828b upstream.
For LSE atomics that read and write a register operand, we need to
ensure that these operands are annotated as "early clobber" if the
register is written before all of the input operands have been consumed.
Failure to do so can result in the compiler allocating the same register
to both operands, leading to splats such as:
Unable to handle kernel paging request at virtual address
11111122222221
[...]
x1 :
1111111122222222 x0 :
1111111122222221
Process swapper/0 (pid: 1, stack limit = 0x000000008209f908)
Call trace:
test_atomic64+0x1360/0x155c
where x0 has been allocated as both the value to be stored and also the
atomic_t pointer.
This patch adds the missing clobbers.
Cc: <stable@vger.kernel.org>
Cc: Dave Martin <dave.martin@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Reported-by: Mark Salter <msalter@redhat.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Hellstrom [Wed, 23 May 2018 14:11:24 +0000 (16:11 +0200)]
drm/vmwgfx: Fix 32-bit VMW_PORT_HB_[IN|OUT] macros
commit
938ae7259c908ad031da35d551da297640bb640c upstream.
Depending on whether the kernel is compiled with frame-pointer or not,
the temporary memory location used for the bp parameter in these macros
is referenced relative to the stack pointer or the frame pointer.
Hence we can never reference that parameter when we've modified either
the stack pointer or the frame pointer, because then the compiler would
generate an incorrect stack reference.
Fix this by pushing the temporary memory parameter on a known location on
the stack before modifying the stack- and frame pointers.
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joe Jin [Thu, 17 May 2018 19:33:28 +0000 (12:33 -0700)]
xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent
commit
4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 upstream.
When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
but Dom Heap is increased by the same size. Tracing raidconfig we found
that the related ioctl() in megaraid_sas will call dma_alloc_coherent()
to apply memory. If the memory allocated by Dom0 is not in the DMA area,
it will exchange memory with Xen to meet the requiment. Later drivers
call dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent()
the check condition (dev_addr + size - 1 <= dma_mask) is always false,
it prevents calling xen_destroy_contiguous_region() to return the memory
to the Xen DMA heap.
This issue introduced by commit
6810df88dcfc2 "xen-swiotlb: When doing
coherent alloc/dealloc check before swizzling the MFNs.".
Signed-off-by: Joe Jin <joe.jin@oracle.com>
Tested-by: John Sobecki <john.sobecki@oracle.com>
Reviewed-by: Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: stable@vger.kernel.org
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sudip Mukherjee [Sat, 19 May 2018 21:29:36 +0000 (22:29 +0100)]
libata: blacklist Micron 500IT SSD with MU01 firmware
commit
136d769e0b3475d71350aa3648a116a6ee7a8f6c upstream.
While whitelisting Micron M500DC drives, the tweaked blacklist entry
enabled queued TRIM from M500IT variants also. But these do not support
queued TRIM. And while using those SSDs with the latest kernel we have
seen errors and even the partition table getting corrupted.
Some part from the dmesg:
[ 6.727384] ata1.00: ATA-9: Micron_M500IT_MTFDDAK060MBD, MU01, max UDMA/133
[ 6.727390] ata1.00:
117231408 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[ 6.741026] ata1.00: supports DRM functions and may not be fully accessible
[ 6.759887] ata1.00: configured for UDMA/133
[ 6.762256] scsi 0:0:0:0: Direct-Access ATA Micron_M500IT_MT MU01 PQ: 0 ANSI: 5
and then for the error:
[ 120.860334] ata1.00: exception Emask 0x1 SAct 0x7ffc0007 SErr 0x0 action 0x6 frozen
[ 120.860338] ata1.00: irq_stat 0x40000008
[ 120.860342] ata1.00: failed command: SEND FPDMA QUEUED
[ 120.860351] ata1.00: cmd 64/01:00:00:00:00/00:00:00:00:00/a0 tag 0 ncq dma 512 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x5 (timeout)
[ 120.860353] ata1.00: status: { DRDY }
[ 120.860543] ata1: hard resetting link
[ 121.166128] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 121.166376] ata1.00: supports DRM functions and may not be fully accessible
[ 121.186238] ata1.00: supports DRM functions and may not be fully accessible
[ 121.204445] ata1.00: configured for UDMA/133
[ 121.204454] ata1.00: device reported invalid CHS sector 0
[ 121.204541] sd 0:0:0:0: [sda] tag#18 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[ 121.204546] sd 0:0:0:0: [sda] tag#18 Sense Key : 0x5 [current]
[ 121.204550] sd 0:0:0:0: [sda] tag#18 ASC=0x21 ASCQ=0x4
[ 121.204555] sd 0:0:0:0: [sda] tag#18 CDB: opcode=0x93 93 08 00 00 00 00 00 04 28 80 00 00 00 30 00 00
[ 121.204559] print_req_error: I/O error, dev sda, sector 272512
After few reboots with these errors, and the SSD is corrupted.
After blacklisting it, the errors are not seen and the SSD does not get
corrupted any more.
Fixes:
243918be6393 ("libata: Do not blacklist Micron M500DC")
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tejun Heo [Tue, 8 May 2018 21:21:56 +0000 (14:21 -0700)]
libata: Blacklist some Sandisk SSDs for NCQ
commit
322579dcc865b94b47345ad1b6002ad167f85405 upstream.
Sandisk SSDs SD7SN6S256G and SD8SN8U256G are regularly locking up
regularly under sustained moderate load with NCQ enabled. Blacklist
for now.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Dave Jones <davej@codemonkey.org.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Corneliu Doban [Fri, 18 May 2018 22:03:57 +0000 (15:03 -0700)]
mmc: sdhci-iproc: add SDHCI_QUIRK2_HOST_OFF_CARD_ON for cygnus
commit
3de06d5a1f05c11c94cbb68af14dbfa7fb81d78b upstream.
The SDHCI_QUIRK2_HOST_OFF_CARD_ON is needed for the driver to
properly reset the host controller (reset all) on initialization
after exiting deep sleep.
Signed-off-by: Corneliu Doban <corneliu.doban@broadcom.com>
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Srinath Mannam <srinath.mannam@broadcom.com>
Fixes:
c833e92bbb60 ("mmc: sdhci-iproc: support standard byte register accesses")
Cc: stable@vger.kernel.org # v4.10+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Corneliu Doban [Fri, 18 May 2018 22:03:56 +0000 (15:03 -0700)]
mmc: sdhci-iproc: fix 32bit writes for TRANSFER_MODE register
commit
5f651b870485ee60f5abbbd85195a6852978894a upstream.
When the host controller accepts only 32bit writes, the value of the
16bit TRANSFER_MODE register, that has the same 32bit address as the
16bit COMMAND register, needs to be saved and it will be written
in a 32bit write together with the command as this will trigger the
host to send the command on the SD interface.
When sending the tuning command, TRANSFER_MODE is written and then
sdhci_set_transfer_mode reads it back to clear AUTO_CMD12 bit and
write it again resulting in wrong value to be written because the
initial write value was saved in a shadow and the read-back returned
a wrong value, from the register.
Fix sdhci_iproc_readw to return the saved value of TRANSFER_MODE
when a saved value exist.
Same fix for read of BLOCK_SIZE and BLOCK_COUNT registers, that are
saved for a different reason, although a scenario that will cause the
mentioned problem on this registers is not probable.
Fixes:
b580c52d58d9 ("mmc: sdhci-iproc: add IPROC SDHCI driver")
Signed-off-by: Corneliu Doban <corneliu.doban@broadcom.com>
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Cc: stable@vger.kernel.org # v4.1+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Srinath Mannam [Fri, 18 May 2018 22:03:55 +0000 (15:03 -0700)]
mmc: sdhci-iproc: remove hard coded mmc cap 1.8v
commit
4c94238f37af87a2165c3fb491b4a8b50e90649c upstream.
Remove hard coded mmc cap 1.8v from platform data as it is board specific.
The 1.8v DDR mmc caps can be enabled using DTS property for those
boards that support it.
Fixes:
b17b4ab8ce38 ("mmc: sdhci-iproc: define MMC caps in platform data")
Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Fri, 4 May 2018 12:23:01 +0000 (08:23 -0400)]
do d_instantiate/unlock_new_inode combinations safely
commit
1e2e547a93a00ebc21582c06ca3c6cfea2a309ee upstream.
For anything NFS-exported we do _not_ want to unlock new inode
before it has grown an alias; original set of fixes got the
ordering right, but missed the nasty complication in case of
lockdep being enabled - unlock_new_inode() does
lockdep_annotate_inode_mutex_key(inode)
which can only be done before anyone gets a chance to touch
->i_mutex. Unfortunately, flipping the order and doing
unlock_new_inode() before d_instantiate() opens a window when
mkdir can race with open-by-fhandle on a guessed fhandle, leading
to multiple aliases for a directory inode and all the breakage
that follows from that.
Correct solution: a new primitive (d_instantiate_new())
combining these two in the right order - lockdep annotate, then
d_instantiate(), then the rest of unlock_new_inode(). All
combinations of d_instantiate() with unlock_new_inode() should
be converted to that.
Cc: stable@kernel.org # 2.6.29 and later
Tested-by: Mike Marshall <hubcap@omnibond.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Hutchings [Thu, 17 May 2018 21:34:39 +0000 (22:34 +0100)]
ALSA: timer: Fix pause event notification
commit
3ae180972564846e6d794e3615e1ab0a1e6c4ef9 upstream.
Commit
f65e0d299807 ("ALSA: timer: Call notifier in the same spinlock")
combined the start/continue and stop/pause functions, and in doing so
changed the event code for the pause case to SNDRV_TIMER_EVENT_CONTINUE.
Change it back to SNDRV_TIMER_EVENT_PAUSE.
Fixes:
f65e0d299807 ("ALSA: timer: Call notifier in the same spinlock")
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Sun, 20 May 2018 20:46:23 +0000 (16:46 -0400)]
aio: fix io_destroy(2) vs. lookup_ioctx() race
commit
baf10564fbb66ea222cae66fbff11c444590ffd9 upstream.
kill_ioctx() used to have an explicit RCU delay between removing the
reference from ->ioctx_table and percpu_ref_kill() dropping the refcount.
At some point that delay had been removed, on the theory that
percpu_ref_kill() itself contained an RCU delay. Unfortunately, that was
the wrong kind of RCU delay and it didn't care about rcu_read_lock() used
by lookup_ioctx(). As the result, we could get ctx freed right under
lookup_ioctx(). Tejun has fixed that in
a6d7cff472e ("fs/aio: Add explicit
RCU grace period when freeing kioctx"); however, that fix is not enough.
Suppose io_destroy() from one thread races with e.g. io_setup() from another;
CPU1 removes the reference from current->mm->ioctx_table[...] just as CPU2
has picked it (under rcu_read_lock()). Then CPU1 proceeds to drop the
refcount, getting it to 0 and triggering a call of free_ioctx_users(),
which proceeds to drop the secondary refcount and once that reaches zero
calls free_ioctx_reqs(). That does
INIT_RCU_WORK(&ctx->free_rwork, free_ioctx);
queue_rcu_work(system_wq, &ctx->free_rwork);
and schedules freeing the whole thing after RCU delay.
In the meanwhile CPU2 has gotten around to percpu_ref_get(), bumping the
refcount from 0 to 1 and returned the reference to io_setup().
Tejun's fix (that queue_rcu_work() in there) guarantees that ctx won't get
freed until after percpu_ref_get(). Sure, we'd increment the counter before
ctx can be freed. Now we are out of rcu_read_lock() and there's nothing to
stop freeing of the whole thing. Unfortunately, CPU2 assumes that since it
has grabbed the reference, ctx is *NOT* going away until it gets around to
dropping that reference.
The fix is obvious - use percpu_ref_tryget_live() and treat failure as miss.
It's not costlier than what we currently do in normal case, it's safe to
call since freeing *is* delayed and it closes the race window - either
lookup_ioctx() comes before percpu_ref_kill() (in which case ctx->users
won't reach 0 until the caller of lookup_ioctx() drops it) or lookup_ioctx()
fails, ctx->users is unaffected and caller of lookup_ioctx() doesn't see
the object in question at all.
Cc: stable@kernel.org
Fixes:
a6d7cff472e "fs/aio: Add explicit RCU grace period when freeing kioctx"
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Chinner [Fri, 11 May 2018 01:20:57 +0000 (11:20 +1000)]
fs: don't scan the inode cache before SB_BORN is set
commit
79f546a696bff2590169fb5684e23d65f4d9f591 upstream.
We recently had an oops reported on a 4.14 kernel in
xfs_reclaim_inodes_count() where sb->s_fs_info pointed to garbage
and so the m_perag_tree lookup walked into lala land. It produces
an oops down this path during the failed mount:
radix_tree_gang_lookup_tag+0xc4/0x130
xfs_perag_get_tag+0x37/0xf0
xfs_reclaim_inodes_count+0x32/0x40
xfs_fs_nr_cached_objects+0x11/0x20
super_cache_count+0x35/0xc0
shrink_slab.part.66+0xb1/0x370
shrink_node+0x7e/0x1a0
try_to_free_pages+0x199/0x470
__alloc_pages_slowpath+0x3a1/0xd20
__alloc_pages_nodemask+0x1c3/0x200
cache_grow_begin+0x20b/0x2e0
fallback_alloc+0x160/0x200
kmem_cache_alloc+0x111/0x4e0
The problem is that the superblock shrinker is running before the
filesystem structures it depends on have been fully set up. i.e.
the shrinker is registered in sget(), before ->fill_super() has been
called, and the shrinker can call into the filesystem before
fill_super() does it's setup work. Essentially we are exposed to
both use-after-free and use-before-initialisation bugs here.
To fix this, add a check for the SB_BORN flag in super_cache_count.
In general, this flag is not set until ->fs_mount() completes
successfully, so we know that it is set after the filesystem
setup has completed. This matches the trylock_super() behaviour
which will not let super_cache_scan() run if SB_BORN is not set, and
hence will not allow the superblock shrinker from entering the
filesystem while it is being set up or after it has failed setup
and is being torn down.
Cc: stable@kernel.org
Signed-Off-By: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Sun, 6 May 2018 16:15:20 +0000 (12:15 -0400)]
affs_lookup(): close a race with affs_remove_link()
commit
30da870ce4a4e007c901858a96e9e394a1daa74a upstream.
we unlock the directory hash too early - if we are looking at secondary
link and primary (in another directory) gets removed just as we unlock,
we could have the old primary moved in place of the secondary, leaving
us to look into freed entry (and leaving our dentry with ->d_fsdata
pointing to a freed entry).
Cc: stable@vger.kernel.org # 2.4.4+
Acked-by: David Sterba <dsterba@suse.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Mon, 14 May 2018 17:23:50 +0000 (18:23 +0100)]
KVM: Fix spelling mistake: "cop_unsuable" -> "cop_unusable"
commit
ba3696e94d9d590d9a7e55f68e81c25dba515191 upstream.
Trivial fix to spelling mistake in debugfs_entries text.
Fixes:
669e846e6c4e ("KVM/MIPS32: MIPS arch specific APIs for KVM")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: kernel-janitors@vger.kernel.org
Cc: <stable@vger.kernel.org> # 3.10+
Signed-off-by: James Hogan <jhogan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maciej W. Rozycki [Mon, 14 May 2018 15:49:43 +0000 (16:49 +0100)]
MIPS: Fix ptrace(2) PTRACE_PEEKUSR and PTRACE_POKEUSR accesses to o32 FGRs
commit
9a3a92ccfe3620743d4ae57c987dc8e9c5f88996 upstream.
Check the TIF_32BIT_FPREGS task setting of the tracee rather than the
tracer in determining the layout of floating-point general registers in
the floating-point context, correcting access to odd-numbered registers
for o32 tracees where the setting disagrees between the two processes.
Fixes:
597ce1723e0f ("MIPS: Support for 64-bit FP with O32 binaries")
Signed-off-by: Maciej W. Rozycki <macro@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: <stable@vger.kernel.org> # 3.14+
Signed-off-by: James Hogan <jhogan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maciej W. Rozycki [Mon, 30 Apr 2018 14:56:47 +0000 (15:56 +0100)]
MIPS: ptrace: Expose FIR register through FP regset
commit
71e909c0cdad28a1df1fa14442929e68615dee45 upstream.
Correct commit
7aeb753b5353 ("MIPS: Implement task_user_regset_view.")
and expose the FIR register using the unused 4 bytes at the end of the
NT_PRFPREG regset. Without that register included clients cannot use
the PTRACE_GETREGSET request to retrieve the complete FPU register set
and have to resort to one of the older interfaces, either PTRACE_PEEKUSR
or PTRACE_GETFPREGS, to retrieve the missing piece of data. Also the
register is irreversibly missing from core dumps.
This register is architecturally hardwired and read-only so the write
path does not matter. Ignore data supplied on writes then.
Fixes:
7aeb753b5353 ("MIPS: Implement task_user_regset_view.")
Signed-off-by: James Hogan <jhogan@kernel.org>
Signed-off-by: Maciej W. Rozycki <macro@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: <stable@vger.kernel.org> # 3.13+
Patchwork: https://patchwork.linux-mips.org/patch/19273/
Signed-off-by: James Hogan <jhogan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NeilBrown [Thu, 26 Apr 2018 23:28:34 +0000 (09:28 +1000)]
MIPS: c-r4k: Fix data corruption related to cache coherence
commit
55a2aa08b3af519a9693f99cdf7fa6d8b62d9f65 upstream.
When DMA will be performed to a MIPS32 1004K CPS, the L1-cache for the
range needs to be flushed and invalidated first.
The code currently takes one of two approaches.
1/ If the range is less than the size of the dcache, then HIT type
requests flush/invalidate cache lines for the particular addresses.
HIT-type requests a globalised by the CPS so this is safe on SMP.
2/ If the range is larger than the size of dcache, then INDEX type
requests flush/invalidate the whole cache. INDEX type requests affect
the local cache only. CPS does not propagate them in any way. So this
invalidation is not safe on SMP CPS systems.
Data corruption due to '2' can quite easily be demonstrated by
repeatedly "echo 3 > /proc/sys/vm/drop_caches" and then sha1sum a file
that is several times the size of available memory. Dropping caches
means that large contiguous extents (large than dcache) are more likely.
This was not a problem before Linux-4.8 because option 2 was never used
if CONFIG_MIPS_CPS was defined. The commit which removed that apparently
didn't appreciate the full consequence of the change.
We could, in theory, globalize the INDEX based flush by sending an IPI
to other cores. These cache invalidation routines can be called with
interrupts disabled and synchronous IPI require interrupts to be
enabled. Asynchronous IPI may not trigger writeback soon enough. So we
cannot use IPI in practice.
We can already test if IPI would be needed for an INDEX operation with
r4k_op_needs_ipi(R4K_INDEX). If this is true then we mustn't try the
INDEX approach as we cannot use IPI. If this is false (e.g. when there
is only one core and hence one L1 cache) then it is safe to use the
INDEX approach without IPI.
This patch avoids options 2 if r4k_op_needs_ipi(R4K_INDEX), and so
eliminates the corruption.
Fixes:
c00ab4896ed5 ("MIPS: Remove cpu_has_safe_index_cacheops")
Signed-off-by: NeilBrown <neil@brown.name>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@linux-mips.org
Cc: <stable@vger.kernel.org> # 4.8+
Patchwork: https://patchwork.linux-mips.org/patch/19259/
Signed-off-by: James Hogan <jhogan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Fri, 25 May 2018 14:18:02 +0000 (16:18 +0200)]
Linux 4.14.44
James Hogan [Tue, 16 Jan 2018 14:45:21 +0000 (14:45 +0000)]
rtc: goldfish: Add missing MODULE_LICENSE
[ Upstream commit
82d632b85eb89f97051530f556cb49ee1c04bde7 ]
Fix the following warning in MIPS allmodconfig by adding a
MODULE_LICENSE() at the end of rtc-goldfish.c, based on the file header
comment which says GNU General Public License version 2:
WARNING: modpost: missing MODULE_LICENSE() in drivers/rtc/rtc-goldfish.o
Fixes:
f22d9cdcb5eb ("rtc: goldfish: Add RTC driver for Android emulator")
Signed-off-by: James Hogan <jhogan@kernel.org>
Cc: Miodrag Dinic <miodrag.dinic@mips.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: linux-rtc@vger.kernel.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexandre Belloni [Mon, 12 Feb 2018 22:47:49 +0000 (23:47 +0100)]
rtc: rp5c01: fix possible race condition
[ Upstream commit
bcdd559268039d8340d38fa58668393596e29fdc ]
The probe function is not allowed to fail after registering the RTC because
the following may happen:
CPU0: CPU1:
sys_load_module()
do_init_module()
do_one_initcall()
cmos_do_probe()
rtc_device_register()
__register_chrdev()
cdev->owner = struct module*
open("/dev/rtc0")
rtc_device_unregister()
module_put()
free_module()
module_free(mod->module_core)
/* struct module *module is now
freed */
chrdev_open()
spin_lock(cdev_lock)
cdev_get()
try_module_get()
module_is_live()
/* dereferences already
freed struct module* */
Switch to devm_rtc_allocate_device/rtc_register_device to register the rtc
as late as possible.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Thu, 15 Feb 2018 19:36:14 +0000 (19:36 +0000)]
rtc: tx4939: avoid unintended sign extension on a 24 bit shift
[ Upstream commit
347876ad47b9923ce26e686173bbf46581802ffa ]
The shifting of buf[5] by 24 bits to the left will be promoted to
a 32 bit signed int and then sign-extended to an unsigned long. If
the top bit of buf[5] is set then all then all the upper bits sec
end up as also being set because of the sign-extension. Fix this by
casting buf[5] to an unsigned long before the shift.
Detected by CoverityScan, CID#1465292 ("Unintended sign extension")
Fixes:
0e1492330cd2 ("rtc: add rtc-tx4939 driver")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexandre Belloni [Sun, 25 Feb 2018 20:14:31 +0000 (21:14 +0100)]
rtc: m41t80: fix race conditions
[ Upstream commit
10d0c768cc6d581523d673b9d1b54213f8a5eb24 ]
The IRQ is requested before the struct rtc is allocated and registered, but
this struct is used in the IRQ handler, leading to:
Unable to handle kernel NULL pointer dereference at virtual address
0000017c
pgd =
a38a2f9b
[
0000017c] *pgd=
00000000
Internal error: Oops: 5 [#1] ARM
Modules linked in:
CPU: 0 PID: 613 Comm: irq/48-m41t80 Not tainted 4.16.0-rc1+ #42
Hardware name: Atmel SAMA5
PC is at mutex_lock+0x14/0x38
LR is at m41t80_handle_irq+0x1c/0x9c
pc : [<
c06e864c>] lr : [<
c04b70f0>] psr:
20000013
sp :
dec73f30 ip :
00000000 fp :
dec56d98
r10:
df437cf0 r9 :
c0a03008 r8 :
c0145ffc
r7 :
df5c4300 r6 :
dec568d0 r5 :
df593000 r4 :
0000017c
r3 :
df592800 r2 :
60000013 r1 :
df593000 r0 :
0000017c
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control:
10c53c7d Table:
20004059 DAC:
00000051
Process irq/48-m41t80 (pid: 613, stack limit = 0xb52d091e)
Stack: (0xdec73f30 to 0xdec74000)
3f20:
dec56840 df5c4300 00000001 df5c4300
3f40:
c0145ffc c0146018 dec56840 ffffe000 00000001 c0146290 dec567c0 00000000
3f60:
c0146084 ed7c9a62 c014615c dec56d80 dec567c0 00000000 dec72000 dec56840
3f80:
c014615c c012ffc0 dec72000 dec567c0 c012fe80 00000000 00000000 00000000
3fa0:
00000000 00000000 00000000 c01010e8 00000000 00000000 00000000 00000000
3fc0:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fe0:
00000000 00000000 00000000 00000000 00000013 00000000 29282726 2d2c2b2a
[<
c06e864c>] (mutex_lock) from [<
c04b70f0>] (m41t80_handle_irq+0x1c/0x9c)
[<
c04b70f0>] (m41t80_handle_irq) from [<
c0146018>] (irq_thread_fn+0x1c/0x54)
[<
c0146018>] (irq_thread_fn) from [<
c0146290>] (irq_thread+0x134/0x1c0)
[<
c0146290>] (irq_thread) from [<
c012ffc0>] (kthread+0x140/0x148)
[<
c012ffc0>] (kthread) from [<
c01010e8>] (ret_from_fork+0x14/0x2c)
Exception stack(0xdec73fb0 to 0xdec73ff8)
3fa0:
00000000 00000000 00000000 00000000
3fc0:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fe0:
00000000 00000000 00000000 00000000 00000013 00000000
Code:
e3c33d7f e3c3303f f5d0f000 e593300c (
e1901f9f)
---[ end trace
22b027302eb7c604 ]---
genirq: exiting task "irq/48-m41t80" (613) is an active IRQ thread (irq 48)
Also, there is another possible race condition. The probe function is not
allowed to fail after the RTC is registered because the following may
happen:
CPU0: CPU1:
sys_load_module()
do_init_module()
do_one_initcall()
cmos_do_probe()
rtc_device_register()
__register_chrdev()
cdev->owner = struct module*
open("/dev/rtc0")
rtc_device_unregister()
module_put()
free_module()
module_free(mod->module_core)
/* struct module *module is now
freed */
chrdev_open()
spin_lock(cdev_lock)
cdev_get()
try_module_get()
module_is_live()
/* dereferences already
freed struct module* */
Switch to devm_rtc_allocate_device/rtc_register_device to allocate the rtc
before requesting the IRQ and register it as late as possible.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexandre Belloni [Wed, 21 Feb 2018 10:57:05 +0000 (11:57 +0100)]
rtc: rk808: fix possible race condition
[ Upstream commit
201fac95e799c3d0304ec724d555e1251b9f6e84 ]
The probe function is not allowed to fail after registering the RTC because
the following may happen:
CPU0: CPU1:
sys_load_module()
do_init_module()
do_one_initcall()
cmos_do_probe()
rtc_device_register()
__register_chrdev()
cdev->owner = struct module*
open("/dev/rtc0")
rtc_device_unregister()
module_put()
free_module()
module_free(mod->module_core)
/* struct module *module is now
freed */
chrdev_open()
spin_lock(cdev_lock)
cdev_get()
try_module_get()
module_is_live()
/* dereferences already
freed struct module* */
Switch to devm_rtc_allocate_device/rtc_register_device to register the rtc
as late as possible.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexandre Belloni [Thu, 8 Mar 2018 22:27:31 +0000 (23:27 +0100)]
rtc: hctosys: Ensure system time doesn't overflow time_t
[ Upstream commit
b3a5ac42ab18b7d1a8f2f072ca0ee76a3b754a43 ]
On 32bit platforms, time_t is still a signed 32bit long. If it is
overflowed, userspace and the kernel cant agree on the current system time.
This causes multiple issues, in particular with systemd:
https://github.com/systemd/systemd/issues/1143
A good workaround is to simply avoid using hctosys which is something I
greatly encourage as the time is better set by userspace.
However, many distribution enable it and use systemd which is rendering the
system unusable in case the RTC holds a date after 2038 (and more so after
2106). Many drivers have workaround for this case and they should be
eliminated so there is only one place left to fix when userspace is able to
cope with dates after the 31bit overflow.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bryan O'Donoghue [Wed, 28 Mar 2018 19:14:05 +0000 (20:14 +0100)]
rtc: snvs: Fix usage of snvs_rtc_enable
[ Upstream commit
1485991c024603b2fb4ae77beb7a0d741128a48e ]
commit
179a502f8c46 ("rtc: snvs: add Freescale rtc-snvs driver") introduces
the SNVS RTC driver with a function snvs_rtc_enable().
snvs_rtc_enable() can return an error on the enable path however this
driver does not currently trap that failure on the probe() path and
consequently if enabling the RTC fails we encounter a later error spinning
forever in rtc_write_sync_lp().
[ 36.093481] [<
c010d630>] (__irq_svc) from [<
c0c2e9ec>] (_raw_spin_unlock_irqrestore+0x34/0x44)
[ 36.102122] [<
c0c2e9ec>] (_raw_spin_unlock_irqrestore) from [<
c072e32c>] (regmap_read+0x4c/0x5c)
[ 36.110938] [<
c072e32c>] (regmap_read) from [<
c085d0f4>] (rtc_write_sync_lp+0x6c/0x98)
[ 36.118881] [<
c085d0f4>] (rtc_write_sync_lp) from [<
c085d160>] (snvs_rtc_alarm_irq_enable+0x40/0x4c)
[ 36.128041] [<
c085d160>] (snvs_rtc_alarm_irq_enable) from [<
c08567b4>] (rtc_timer_do_work+0xd8/0x1a8)
[ 36.137291] [<
c08567b4>] (rtc_timer_do_work) from [<
c01441b8>] (process_one_work+0x28c/0x76c)
[ 36.145840] [<
c01441b8>] (process_one_work) from [<
c01446cc>] (worker_thread+0x34/0x58c)
[ 36.153961] [<
c01446cc>] (worker_thread) from [<
c014aee4>] (kthread+0x138/0x150)
[ 36.161388] [<
c014aee4>] (kthread) from [<
c0107e14>] (ret_from_fork+0x14/0x20)
[ 36.168635] rcu_sched kthread starved for 2602 jiffies! g496 c495 f0x2 RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0
[ 36.178564] rcu_sched R running task 0 8 2 0x00000000
[ 36.185664] [<
c0c288b0>] (__schedule) from [<
c0c29134>] (schedule+0x3c/0xa0)
[ 36.192739] [<
c0c29134>] (schedule) from [<
c0c2db80>] (schedule_timeout+0x78/0x4e0)
[ 36.200422] [<
c0c2db80>] (schedule_timeout) from [<
c01a7ab0>] (rcu_gp_kthread+0x648/0x1864)
[ 36.208800] [<
c01a7ab0>] (rcu_gp_kthread) from [<
c014aee4>] (kthread+0x138/0x150)
[ 36.216309] [<
c014aee4>] (kthread) from [<
c0107e14>] (ret_from_fork+0x14/0x20)
This patch fixes by parsing the result of rtc_write_sync_lp() and
propagating both in the probe and elsewhere. If the RTC doesn't start we
don't proceed loading the driver and don't get into this loop mess later
on.
Fixes:
179a502f8c46 ("rtc: snvs: add Freescale rtc-snvs driver")
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Uwe Kleine-König [Thu, 25 Jan 2018 13:30:43 +0000 (14:30 +0100)]
serial: altera: ensure port->regshift is honored consistently
[ Upstream commit
0e254963b6ba4d63ac911e79537fea38dd03dc50 ]
Most register accesses in the altera driver honor port->regshift by
using altera_uart_writel(). There are a few accesses however that were
missed when the driver was converted to use port->regshift and some
others were added later in commit
4d9d7d896d77 ("serial: altera_uart:
add earlycon support").
Fixes:
2780ad42f5fe ("tty: serial: altera_uart: Use port->regshift to store bus shift")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vignesh R [Thu, 8 Feb 2018 12:55:41 +0000 (18:25 +0530)]
serial: 8250: Don't service RX FIFO if interrupts are disabled
[ Upstream commit
2e9fe539108320820016f78ca7704a7342788380 ]
Currently, data in RX FIFO is read based on UART_LSR register state even
if RDI and RLSI interrupts are disabled in UART_IER register.
This is because when IRQ handler is called due to TX FIFO empty event,
RX FIFO is serviced based on UART_LSR register status instead of
UART_IIR status. This defeats the purpose of disabling UART RX
FIFO interrupts during throttling(see, omap_8250_throttle()) as IRQ
handler continues to drain UART RX FIFO resulting in overflow of buffer
at tty layer.
Fix this by making sure that driver drains UART RX FIFO only when
UART_IIR_RDI is set along with UART_LSR_BI or UART_LSR_DR bits.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Fri, 23 Feb 2018 13:38:29 +0000 (14:38 +0100)]
serial: arc_uart: Fix out-of-bounds access through DT alias
[ Upstream commit
f9f5786987e81d166c60833edcb7d1836aa16944 ]
The arc_uart_ports[] array is indexed using a value derived from the
"serialN" alias in DT, which may lead to an out-of-bounds access.
Fix this by adding a range check.
Note that the array size is defined by a Kconfig symbol
(CONFIG_SERIAL_ARC_NR_PORTS), so this can even be triggered using a
legitimate DTB.
Fixes:
ea28fd56fcde69af ("serial/arc-uart: switch to devicetree based probing")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Fri, 23 Feb 2018 13:38:30 +0000 (14:38 +0100)]
serial: fsl_lpuart: Fix out-of-bounds access through DT alias
[ Upstream commit
ffab87fdecc655cc676f8be8dd1a2c5e22bd6d47 ]
The lpuart_ports[] array is indexed using a value derived from the
"serialN" alias in DT, which may lead to an out-of-bounds access.
Fix this by adding a range check.
Fixes:
c9e2e946fb0ba5d2 ("tty: serial: add Freescale lpuart driver support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Fri, 23 Feb 2018 13:38:31 +0000 (14:38 +0100)]
serial: imx: Fix out-of-bounds access through serial port index
[ Upstream commit
5673444821406dda5fc25e4b52aca419f8065a19 ]
The imx_ports[] array is indexed using a value derived from the
"serialN" alias in DT, or from platform data, which may lead to an
out-of-bounds access.
Fix this by adding a range check.
Fixes:
ff05967a07225ab6 ("serial/imx: add of_alias_get_id() reference back")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Fri, 23 Feb 2018 13:38:32 +0000 (14:38 +0100)]
serial: mxs-auart: Fix out-of-bounds access through serial port index
[ Upstream commit
dd345a31bfdec350d2593e6de5964e55c7f19c76 ]
The auart_port[] array is indexed using a value derived from the
"serialN" alias in DT, or from platform data, which may lead to an
out-of-bounds access.
Fix this by adding a range check.
Fixes:
1ea6607d4cdc9179 ("serial: mxs-auart: Allow device tree probing")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Fri, 23 Feb 2018 13:38:34 +0000 (14:38 +0100)]
serial: samsung: Fix out-of-bounds access through serial port index
[ Upstream commit
49ee23b71877831ac087d6083f6f397dc19c9664 ]
The s3c24xx_serial_ports[] array is indexed using a value derived from
the "serialN" alias in DT, or from an incrementing probe index, which
may lead to an out-of-bounds access.
Fix this by adding a range check.
Note that the array size is defined by a Kconfig symbol
(CONFIG_SERIAL_SAMSUNG_UARTS), so this can even be triggered using
a legitimate DTB or legitimate board code.
Fixes:
13a9f6c64fdc55eb ("serial: samsung: Consider DT alias when probing ports")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Fri, 23 Feb 2018 13:38:35 +0000 (14:38 +0100)]
serial: sh-sci: Fix out-of-bounds access through DT alias
[ Upstream commit
090fa4b0dccfa3d04e1c5ab0fe4eba16e6713895 ]
The sci_ports[] array is indexed using a value derived from the
"serialN" alias in DT, which may lead to an out-of-bounds access.
Fix this by adding a range check.
Note that the array size is defined by a Kconfig symbol
(CONFIG_SERIAL_SH_SCI_NR_UARTS), so this can even be triggered using a
legitimate DTB.
Fixes:
97ed9790c514066b ("serial: sh-sci: Remove unused platform data capabilities field")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Fri, 23 Feb 2018 13:38:37 +0000 (14:38 +0100)]
serial: xuartps: Fix out-of-bounds access through DT alias
[ Upstream commit
e7d75e18d0fc3f7193b65282b651f980c778d935 ]
The cdns_uart_port[] array is indexed using a value derived from the
"serialN" alias in DT, which may lead to an out-of-bounds access.
Fix this by adding a range check.
Fixes:
928e9263492069ee ("tty: xuartps: Initialize ports according to aliases")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Wed, 31 Jan 2018 17:33:09 +0000 (12:33 -0500)]
media: cx25821: prevent out-of-bounds read on array card
[ Upstream commit
67300abdbe9f1717532aaf4e037222762716d0f6 ]
Currently an out of range dev->nr is detected by just reporting the
issue and later on an out-of-bounds read on array card occurs because
of this. Fix this by checking the upper range of dev->nr with the size
of array card (removes the hard coded size), move this check earlier
and also exit with the error -ENOSYS to avoid the later out-of-bounds
array read.
Detected by CoverityScan, CID#711191 ("Out-of-bounds-read")
Fixes: commit
02b20b0b4cde ("V4L/DVB (12730): Add conexant cx25821 driver")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
[hans.verkuil@cisco.com: %ld -> %zd]
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans Verkuil [Thu, 1 Feb 2018 07:36:33 +0000 (02:36 -0500)]
media: vivid: fix incorrect capabilities for radio
[ Upstream commit
65243386f41d38460bfd4375d231a7c0346d0401 ]
The vivid driver has two custom controls that change the behavior of RDS.
Depending on the control setting the V4L2_CAP_READWRITE capability is toggled.
However, after an earlier commit the capability was no longer set correctly.
This is now fixed.
Fixes:
9765a32cd8 ("vivid: set device_caps in video_device")
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Masami Hiramatsu [Tue, 6 Feb 2018 08:02:23 +0000 (03:02 -0500)]
media: vb2: Fix videobuf2 to map correct area
[ Upstream commit
d13a0139d7874a0577b5955d6eed895517d23b72 ]
Fixes vb2_vmalloc_get_userptr() to ioremap correct area.
Since the current code does ioremap the page address, if the offset > 0,
it does not do ioremap the last page and results in kernel panic.
This fixes to pass the size + offset to ioremap so that ioremap
can map correct area. Also, this uses __pfn_to_phys() to get the physical
address of given PFN.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Reported-by: Takao Orito <orito.takao@socionext.com>
Reported-by: Fumihiro ATSUMI <atsumi@infinitegra.co.jp>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kieran Bingham [Mon, 8 Jan 2018 18:14:04 +0000 (13:14 -0500)]
media: i2c: adv748x: fix HDMI field heights
[ Upstream commit
9f564184e6cc21a86c26bab920afac1bab7653ff ]
The ADV748x handles interlaced media using V4L2_FIELD_ALTERNATE field
types. The correct specification for the height on the mbus is the
image height, in this instance, the field height.
The AFE component already correctly adjusts the height on the mbus, but
the HDMI component got left behind.
Adjust the mbus height to correctly describe the image height of the
fields when processing interlaced video for HDMI pipelines.
Fixes:
3e89586a64df ("media: i2c: adv748x: add adv748x driver")
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Laurent Pinchart [Sun, 3 Dec 2017 10:06:57 +0000 (05:06 -0500)]
media: v4l: vsp1: Fix display stalls when requesting too many inputs
[ Upstream commit
5e3e4cb5e24b92773b194aa90066170b12133bc6 ]
Make sure we don't accept more inputs than the hardware can handle. This
is a temporary fix to avoid display stall, we need to instead allocate
the BRU or BRS to display pipelines dynamically based on the number of
planes they each use.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brad Love [Fri, 5 Jan 2018 00:04:15 +0000 (19:04 -0500)]
media: em28xx: Add Hauppauge SoloHD/DualHD bulk models
[ Upstream commit
f2a326c928cca1f5e36a3dceaf66e8c6b34e9cb8 ]
Add additional pids to driver list
Signed-off-by: Brad Love <brad@nextdimension.cc>
Reviewed-by: Michael Ira Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brad Love [Fri, 5 Jan 2018 14:57:13 +0000 (09:57 -0500)]
media: lgdt3306a: Fix a double kfree on i2c device remove
[ Upstream commit
94448e21cf08b10f7dc7acdaca387594370396b0 ]
Both lgdt33606a_release and lgdt3306a_remove kfree state, but _release is
called first, then _remove operates on states members before kfree'ing it.
This can lead to random oops/GPF/etc on USB disconnect.
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Tue, 16 Jan 2018 21:52:15 +0000 (16:52 -0500)]
media: s3c-camif: fix out-of-bounds array access
[ Upstream commit
a398e043637a4819a0e96467bfecaabf3224dd62 ]
While experimenting with older compiler versions, I ran
into a warning that no longer shows up on gcc-4.8 or newer:
drivers/media/platform/s3c-camif/camif-capture.c: In function '__camif_subdev_try_format':
drivers/media/platform/s3c-camif/camif-capture.c:1265:25: error: array subscript is below array bounds
This is an off-by-one bug, leading to an access before the start of the
array, while newer compilers silently assume this undefined behavior
cannot happen and leave the loop at index 0 if no other entry matches.
As Sylvester explains, we actually need to ensure that the
value is within the range, so this reworks the loop to be
easier to parse correctly, and an additional check to fall
back on the first format value for any unexpected input.
I found an existing gcc bug for it and added a reduced version
of the function there.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69249#c3
Fixes:
babde1c243b2 ("[media] V4L: Add driver for S3C24XX/S3C64XX SoC series camera interface")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brad Love [Tue, 6 Mar 2018 19:15:36 +0000 (14:15 -0500)]
media: cx23885: Set subdev host data to clk_freq pointer
[ Upstream commit
5ceade1d97fc6687e050c44c257382c192f56276 ]
Currently clk_freq is ignored entirely, because the cx235840 driver
configures the xtal at the chip defaults. This is an issue if a
board is produced with a non-default frequency crystal. If clk_freq
is not zero the cx25840 will attempt to use the setting provided,
or fall back to defaults otherwise.
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brad Love [Tue, 6 Mar 2018 19:15:37 +0000 (14:15 -0500)]
media: cx23885: Override 888 ImpactVCBe crystal frequency
[ Upstream commit
779c79d4b833ec646b0aed878da38edb45bbe156 ]
Hauppauge produced a revision of ImpactVCBe using an 888,
with a 25MHz crystal, instead of using the default third
overtone 50Mhz crystal. This overrides that frequency so
that the cx25840 is properly configured. Without the proper
crystal setup the cx25840 cannot load the firmware or
decode video.
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Akinobu Mita [Mon, 19 Mar 2018 16:14:17 +0000 (12:14 -0400)]
media: ov5645: add missing of_node_put() in error path
[ Upstream commit
06fe932307d58108a11c3e603517dd2a73a57b80 ]
The device node obtained with of_graph_get_next_endpoint() should be
released by calling of_node_put(). But it was not released when
v4l2_fwnode_endpoint_parse() failed.
This change moves the of_node_put() call before the error check and
fixes the issue.
Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Acked-by: Todor Tomov <todor.tomov@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Mon, 19 Feb 2018 18:23:39 +0000 (13:23 -0500)]
media: Don't let tvp5150_get_vbi() go out of vbi_ram_default array
[ Upstream commit
3dd6b560dc5d59e7cb6dbda6e85dc9af7925fcf8 ]
As pointed by Dan, possible values for bits[3:0] of te Line Mode Registers
can range from 0x0 to 0xf, but the check logic allow values ranging
from 0x0 to 0xe.
As static arrays are initialized with zero, using a value without
an explicit initializer at the array won't cause any harm.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Sun, 11 Feb 2018 10:44:21 +0000 (05:44 -0500)]
media: dmxdev: fix error code for invalid ioctls
[ Upstream commit
a145f64c6107d3aa5a7cec9f8977d04ac2a896c9 ]
Returning -EINVAL when an ioctl is not implemented is a very
bad idea, as it is hard to distinguish from other error
contitions that an ioctl could lead. Replace it by its
right error code: -ENOTTY.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrzej Hajda [Fri, 16 Feb 2018 14:57:48 +0000 (15:57 +0100)]
clk: samsung: exynos3250: Fix PLL rates
[ Upstream commit
a8321e7887410a2b2e80ab89d1ef7b30562658ea ]
Rates declared in PLL rate tables should match exactly rates calculated
from PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a
393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is
393216003, after setting PLL's clk rate to
393216000 clk_get_rate
will return
393216003. If we now attempt to set rate of a PLL's child divider
clock to
393216000/2 its rate will be
131072001, rather than
196608000.
That is, the divider will be set to 3 instead of 2, because
393216003/2 is
greater than
196608000.
To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.
In this patch an erroneous P value for
74176002 output frequency is also
corrected.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrzej Hajda [Fri, 16 Feb 2018 14:57:49 +0000 (15:57 +0100)]
clk: samsung: exynos5250: Fix PLL rates
[ Upstream commit
2ac051eeabaa411ef89ae7cd5bb8e60cb41ad780 ]
Rates declared in PLL rate tables should match exactly rates calculated
from PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a
393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is
393216003, after setting PLL's clk rate to
393216000 clk_get_rate
will return
393216003. If we now attempt to set rate of a PLL's child divider
clock to
393216000/2 its rate will be
131072001, rather than
196608000.
That is, the divider will be set to 3 instead of 2, because
393216003/2 is
greater than
196608000.
To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrzej Hajda [Fri, 16 Feb 2018 14:57:51 +0000 (15:57 +0100)]
clk: samsung: exynos5433: Fix PLL rates
[ Upstream commit
ab0447845cffc0fd752df2ccd6b4e34006000ce4 ]
Rates declared in PLL rate tables should match exactly rates calculated from
the PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a
393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is
393216003, after setting PLL's clk rate to
393216000 clk_get_rate
will return
393216003. If we now attempt to set rate of a PLL's child divider
clock to
393216000/2 its rate will be
131072001, rather than
196608000.
That is, the divider will be set to 3 instead of 2, because
393216003/2 is
greater than
196608000.
To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrzej Hajda [Fri, 16 Feb 2018 14:57:50 +0000 (15:57 +0100)]
clk: samsung: exynos5260: Fix PLL rates
[ Upstream commit
cdb68fbd4e7962be742c4f29475220c5bf28d8a5 ]
Rates declared in PLL rate tables should match exactly rates calculated from
the PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a
393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is
393216003, after setting PLL's clk rate to
393216000 clk_get_rate
will return
393216003. If we now attempt to set rate of a PLL's child divider
clock to
393216000/2 its rate will be
131072001, rather than
196608000.
That is, the divider will be set to 3 instead of 2, because
393216003/2 is
greater than
196608000.
To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrzej Hajda [Fri, 16 Feb 2018 14:57:52 +0000 (15:57 +0100)]
clk: samsung: exynos7: Fix PLL rates
[ Upstream commit
7e4db0c2836e892766565965207eee051c8037b9 ]
Rates declared in PLL rate tables should match exactly rates calculated from
the PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a
393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is
393216003, after setting PLL's clk rate to
393216000 clk_get_rate
will return
393216003. If we now attempt to set rate of a PLL's child divider
clock to
393216000/2 its rate will be
131072001, rather than
196608000.
That is, the divider will be set to 3 instead of 2, because
393216003/2 is
greater than
196608000.
To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrzej Hajda [Fri, 16 Feb 2018 14:57:53 +0000 (15:57 +0100)]
clk: samsung: s3c2410: Fix PLL rates
[ Upstream commit
179db533c08431f509a3823077549773d519358b ]
Rates declared in PLL rate tables should match exactly rates calculated from
the PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a
393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is
393216003, after setting PLL's clk rate to
393216000 clk_get_rate
will return
393216003. If we now attempt to set rate of a PLL's child divider
clock to
393216000/2 its rate will be
131072001, rather than
196608000.
That is, the divider will be set to 3 instead of 2, because
393216003/2 is
greater than
196608000.
To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shawn Lin [Mon, 5 Mar 2018 03:25:58 +0000 (11:25 +0800)]
clk: rockchip: Prevent calculating mmc phase if clock rate is zero
[ Upstream commit
4bf59902b50012b1dddeeaa23b217d9c4956cdda ]
The MMC sample and drv clock for rockchip platforms are derived from
the bus clock output to the MMC/SDIO card. So it should never happens
that the clk rate is zero given it should inherits the clock rate from
its parent. If something goes wrong and makes the clock rate to be zero,
the calculation would be wrong but may still make the mmc tuning process
work luckily. However it makes people harder to debug when the following
data transfer is unstable.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marcel Ziswiler [Thu, 22 Feb 2018 23:04:51 +0000 (00:04 +0100)]
clk: tegra: Fix pll_u rate configuration
[ Upstream commit
c35b518f9ba06c9de79fb3ff62eed7462d804995 ]
Turns out latest upstream U-Boot does not configure/enable pll_u which
leaves it at some default rate of 500 kHz:
root@apalis-t30:~# cat /sys/kernel/debug/clk/clk_summary | grep pll_u
pll_u 3 3 0 500000 0
Of course this won't quite work leading to the following messages:
[ 6.559593] usb 2-1: new full-speed USB device number 2 using tegra-
ehci
[ 11.759173] usb 2-1: device descriptor read/64, error -110
[ 27.119453] usb 2-1: device descriptor read/64, error -110
[ 27.389217] usb 2-1: new full-speed USB device number 3 using tegra-
ehci
[ 32.559454] usb 2-1: device descriptor read/64, error -110
[ 47.929777] usb 2-1: device descriptor read/64, error -110
[ 48.049658] usb usb2-port1: attempt power cycle
[ 48.759475] usb 2-1: new full-speed USB device number 4 using tegra-
ehci
[ 59.349457] usb 2-1: device not accepting address 4, error -110
[ 59.509449] usb 2-1: new full-speed USB device number 5 using tegra-
ehci
[ 70.069457] usb 2-1: device not accepting address 5, error -110
[ 70.079721] usb usb2-port1: unable to enumerate USB device
Fix this by actually allowing the rate also being set from within
the Linux kernel.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Tue, 20 Feb 2018 15:15:21 +0000 (16:15 +0100)]
clk: hisilicon: mark wdt_mux_p[] as const
[ Upstream commit
df934cbcbff7afbc024bf05f02615917c61f6470 ]
The symbol is in the __initconst section but not marked init, which
caused a warning when building with LTO.
This makes it 'const' as was obviously intended.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes:
c80dfd9bf54e ("clk: hisilicon: add CRG driver for Hi3516CV300 SoC")
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shawn Lin [Wed, 14 Mar 2018 00:28:31 +0000 (08:28 +0800)]
clk: Don't show the incorrect clock phase
[ Upstream commit
1f9c63e8de3d7b377c9d74e4a17524cfb60e6384 ]
It's found that the clock phase output from clk_summary is
wrong compared to the actual phase reading from the register.
cat /sys/kernel/debug/clk/clk_summary | grep sdio_sample
sdio_sample 0 1 0
50000000 0 -22
It exposes an issue that clk core, clk_core_get_phase, always
returns the cached core->phase which should be either updated
by calling clk_set_phase or directly from the first place the
clk was registered.
When registering the clk, the core->phase geting from ->get_phase()
may return negative value indicating error. This is quite common
since the clk's phase may be highly related to its parent chain,
but it was temporarily orphan when registered, since its parent
chains hadn't be ready at that time, so the clk drivers decide to
return error in this case. However, if no clk_set_phase is called or
maybe the ->set_phase() isn't even implemented, the core->phase would
never be updated. This is wrong, and we should try to update it when
all its parent chains are settled down, like the way of updating clock
rate for that. But it's not deserved to complicate the code now and
just update it anyway when calling clk_core_get_phase, which would be
much simple and enough.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shawn Lin [Wed, 21 Mar 2018 02:39:19 +0000 (10:39 +0800)]
clk: rockchip: Fix wrong parent for SDMMC phase clock for rk3228
[ Upstream commit
4b0556a441dd37e598887215bc89b49a6ef525b3 ]
commit
c420c1e4db22 ("clk: rockchip: Prevent calculating mmc phase
if clock rate is zero") catches one gremlin again for clk-rk3228.c
that the parent of SDMMC phase clock should be sclk_sdmmc0, but not
sclk_sdmmc. However, the naming of the sdmmc clocks varies in the
manual with the card clock having the 0 while the hclk is named
without appended 0. So standardize one one format to prevent
confusion, as there also is only one (non-sdio) mmc controller on
the soc.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sylwester Nawrocki [Mon, 5 Feb 2018 15:43:56 +0000 (16:43 +0100)]
ASoC: samsung: i2s: Ensure the RCLK rate is properly determined
[ Upstream commit
647d04f8e07afc7c3b7a42b3ee01a8b28db29631 ]
If the RCLK mux clock configuration is specified in DT and no set_sysclk()
callback is used in the sound card driver the sclk_srcrate field will remain
set to 0, leading to an incorrect PSR divider setting.
To fix this the frequency value is retrieved from the CLK_I2S_RCLK_SRC clock,
so the actual RCLK mux selection is taken into account.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ranjani Sridharan [Fri, 9 Mar 2018 19:11:17 +0000 (11:11 -0800)]
ASoC: topology: create TLV data for dapm widgets
[ Upstream commit
bde8b3887add8368ecf0ca71117baf2fd56a6fc9 ]
This patch adds the change required to create the TLV data
for dapm widget kcontrols from topology. This also fixes the following
TLV read error shown in amixer while showing the card control contents.
"amixer: Control hw:1 element TLV read error: No such device or address"
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sylwester Nawrocki [Wed, 14 Mar 2018 16:41:13 +0000 (17:41 +0100)]
ASoC: samsung: odroid: Fix 32000 sample rate handling
[ Upstream commit
1d22c337dc8f3a25638f7262e7bcb5729a34d140 ]
In case of sample rates lower than 44100 currently there is too low MCLK
frequency set for the CODEC. Playback fails with following errors:
$ speaker-test -c2 -t sine -f 1500 -l2 -r 32000
Sine wave rate is 1500.0000Hz
Rate set to 32000Hz (requested 32000Hz)
Buffer size range from 128 to 131072
Period size range from 64 to 65536
Using max buffer size 131072
Periods = 4
Unable to set hw params for playback: Invalid argument
Setting of hwparams failed: Invalid argument
[ 497.883700] max98090 1-0010: Invalid master clock frequency
To fix this the I2S root clock's frequency is increased, depending
on sampling rate.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ezequiel Garcia [Tue, 20 Mar 2018 16:03:31 +0000 (13:03 -0300)]
ASoC: rockchip: rk3288-hdmi-analog: Select needed codecs
[ Upstream commit
b1d0db067fbe2598d62b248beea5d705a0ea7642 ]
The driver does not select all the codec drivers that needs.
Fix it by selecting the analog and HDMI codecs.
Cc: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Ujfalusi [Tue, 20 Feb 2018 14:19:05 +0000 (16:19 +0200)]
ASoC: hdmi-codec: Fix module unloading caused kernel crash
[ Upstream commit
5e558f8afaec8957932b1dbe5aeff800f9fc6957 ]
The hcp->chmap_info must not be freed up in the hdmi_codec_remove()
function as it leads to kernel crash due ALSA core's
pcm_chmap_ctl_private_free() is trying to free it up again when the card
destroyed via snd_card_free.
Commit
cd6111b26280a ("ASoC: hdmi-codec: add channel mapping control")
should not have added the kfree(hcp->chmap_info); to the hdmi_codec_remove
function.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Jyri Sarha <jsarha@ti.com>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Smart [Tue, 30 Jan 2018 23:58:45 +0000 (15:58 -0800)]
scsi: lpfc: Fix frequency of Release WQE CQEs
[ Upstream commit
04673e38f56b30cd39b1fa0f386137d818b17781 ]
The driver controls when the hardware sends completions that communicate
consumption of elements from the WQ. This is done by setting a WQEC bit
on a WQE.
The current driver sets it on every Nth WQE posting. However, the driver
isn't clearing the bit if the WQE is reused. Thus, if the queue depth
isn't evenly divisible by N, with enough time, it can be set on every
element, creating a lot of overhead and risking CQ full conditions.
Correct by clearing the bit when not setting it on an Nth element.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Smart [Tue, 30 Jan 2018 23:58:54 +0000 (15:58 -0800)]
scsi: lpfc: Fix soft lockup in lpfc worker thread during LIP testing
[ Upstream commit
161df4f09987ae2e9f0f97f0b38eee298b4a39ff ]
During link bounce testing in a point-to-point topology, the host may
enter a soft lockup on the lpfc_worker thread:
Call Trace:
lpfc_work_done+0x1f3/0x1390 [lpfc]
lpfc_do_work+0x16f/0x180 [lpfc]
kthread+0xc7/0xe0
ret_from_fork+0x3f/0x70
The driver was simultaneously setting a combination of flags that caused
lpfc_do_work()to effectively spin between slow path work and new event
data, causing the lockup.
Ensure in the typical wq completions, that new event data flags are set
if the slow path flag is running. The slow path will eventually
reschedule the wq handling.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Smart [Tue, 30 Jan 2018 23:58:55 +0000 (15:58 -0800)]
scsi: lpfc: Fix issue_lip if link is disabled
[ Upstream commit
2289e9598dde9705400559ca2606fb8c145c34f0 ]
The driver ignored checks on whether the link should be kept
administratively down after a link bounce. Correct the checks.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wilfried Weissmann [Fri, 23 Feb 2018 19:52:34 +0000 (20:52 +0100)]
scsi: mvsas: fix wrong endianness of sgpio api
[ Upstream commit
e75fba9c0668b3767f608ea07485f48d33c270cf ]
This patch fixes the byte order of the SGPIO api and brings it back in
sync with ledmon v0.80 and above.
[mkp: added missing SoB and fixed whitespace]
Signed-off-by: Wilfried Weissmann <wilfried.weissmann@gmx.at>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Douglas Gilbert [Wed, 7 Mar 2018 03:19:49 +0000 (22:19 -0500)]
scsi: core: Make SCSI Status CONDITION MET equivalent to GOOD
[ Upstream commit
1875ede02ed5e176a18dccbca84abc28d5b3e141 ]
The SCSI PRE-FETCH (10 or 16) command is present both on hard disks
and some SSDs. It is useful when the address of the next block(s) to
be read is known but it is not following the LBA of the current READ
(so read-ahead won't help). It returns two "good" SCSI Status values.
If the requested blocks have fitted (or will most likely fit (when
the IMMED bit is set)) into the disk's cache, it returns CONDITION
MET. If it didn't (or will not) fit then it returns GOOD status.
The goal of this patch is to stop the SCSI subsystem treating the
CONDITION MET SCSI status as an error. The current state makes the
PRE-FETCH command effectively unusable via pass-throughs.
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Reviewed-by: Bart Van Assche <bart.vanassche@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Carroll [Tue, 3 Apr 2018 21:50:42 +0000 (15:50 -0600)]
scsi: aacraid: Insure command thread is not recursively stopped
[ Upstream commit
1c6b41fb92936fa5facea464d5d7cbf855966d04 ]
If a recursive IOP_RESET is invoked, usually due to the eh_thread
handling errors after the first reset, be sure we flag that the command
thread has been stopped to avoid an Oops of the form;
[ 336.620256] CPU: 28 PID: 1193 Comm: scsi_eh_0 Kdump: loaded Not tainted 4.14.0-49.el7a.ppc64le #1
[ 336.620297] task:
c000003fd630b800 task.stack:
c000003fd61a4000
[ 336.620326] NIP:
c000000000176794 LR:
c00000000013038c CTR:
c00000000024bc10
[ 336.620361] REGS:
c000003fd61a7720 TRAP: 0300 Not tainted (4.14.0-49.el7a.ppc64le)
[ 336.620395] MSR:
9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR:
22084022 XER:
20040000
[ 336.620435] CFAR:
c000000000130388 DAR:
0000000000000000 DSISR:
40000000 SOFTE: 1
[ 336.620435] GPR00:
c00000000013038c c000003fd61a79a0 c0000000014c7e00 0000000000000000
[ 336.620435] GPR04:
000000000000000c 000000000000000c 9000000000009033 0000000000000477
[ 336.620435] GPR08:
0000000000000477 0000000000000000 0000000000000000 c008000010f7d940
[ 336.620435] GPR12:
c00000000024bc10 c000000007a33400 c0000000001708a8 c000003fe3b881d8
[ 336.620435] GPR16:
c000003fe3b88060 c000003fd61a7d10 fffffffffffff000 000000000000001e
[ 336.620435] GPR20:
0000000000000001 c000000000ebf1a0 0000000000000001 c000003fe3b88000
[ 336.620435] GPR24:
0000000000000003 0000000000000002 c000003fe3b88840 c000003fe3b887e8
[ 336.620435] GPR28:
c000003fe3b88000 c000003fc8181788 0000000000000000 c000003fc8181700
[ 336.620750] NIP [
c000000000176794] exit_creds+0x34/0x160
[ 336.620775] LR [
c00000000013038c] __put_task_struct+0x8c/0x1f0
[ 336.620804] Call Trace:
[ 336.620817] [
c000003fd61a79a0] [
c000003fe3b88000] 0xc000003fe3b88000 (unreliable)
[ 336.620853] [
c000003fd61a79d0] [
c00000000013038c] __put_task_struct+0x8c/0x1f0
[ 336.620889] [
c000003fd61a7a00] [
c000000000171418] kthread_stop+0x1e8/0x1f0
[ 336.620922] [
c000003fd61a7a40] [
c008000010f7448c] aac_reset_adapter+0x14c/0x8d0 [aacraid]
[ 336.620959] [
c000003fd61a7b00] [
c008000010f60174] aac_eh_host_reset+0x84/0x100 [aacraid]
[ 336.621010] [
c000003fd61a7b30] [
c000000000864f24] scsi_try_host_reset+0x74/0x180
[ 336.621046] [
c000003fd61a7bb0] [
c000000000867ac0] scsi_eh_ready_devs+0xc00/0x14d0
[ 336.625165] [
c000003fd61a7ca0] [
c0000000008699e0] scsi_error_handler+0x550/0x730
[ 336.632101] [
c000003fd61a7dc0] [
c000000000170a08] kthread+0x168/0x1b0
[ 336.639031] [
c000003fd61a7e30] [
c00000000000b528] ret_from_kernel_thread+0x5c/0xb4
[ 336.645971] Instruction dump:
[ 336.648743]
384216a0 7c0802a6 fbe1fff8 f8010010 f821ffd1 7c7f1b78 60000000 60000000
[ 336.657056]
39400000 e87f0838 f95f0838 7c0004ac <
7d401828>
314affff 7d40192d 40c2fff4
[ 336.663997] -[ end trace
4640cf8d4945ad95 ]-
So flag when the thread is stopped by setting the thread pointer to NULL.
Signed-off-by: Dave Carroll <david.carroll@microsemi.com>
Reviewed-by: Raghava Aditya Renukunta <raghavaaditya.renukunta@microsemi.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jianchao Wang [Wed, 7 Mar 2018 12:29:03 +0000 (20:29 +0800)]
scsi: iscsi_tcp: set BDI_CAP_STABLE_WRITES when data digest enabled
[ Upstream commit
89d0c804392bb962553f23dc4c119d11b6bd1675 ]
iscsi tcp will first send out data, then calculate and send data
digest. If we don't have BDI_CAP_STABLE_WRITES, the page cache will be
written in spite of the on going writeback. Consequently, wrong digest
will be got and sent to target.
To fix this, set BDI_CAP_STABLE_WRITES when data digest is enabled
in iscsi_tcp .slave_configure callback.
Signed-off-by: Jianchao Wang <jianchao.w.wang@oracle.com>
Acked-by: Chris Leech <cleech@redhat.com>
Acked-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
projects / platform / kernel / linux-rpi.git / log