Greg Kroah-Hartman [Sat, 30 Mar 2019 07:44:13 +0000 (08:44 +0100)]
Merge 4.14.109 into android-4.14-q
Changes in 4.14.109
mmc: pxamci: fix enum type confusion
drm/vmwgfx: Don't double-free the mode stored in par->set_mode
iommu/amd: fix sg->dma_address for sg->offset bigger than PAGE_SIZE
libceph: wait for latest osdmap in ceph_monc_blacklist_add()
udf: Fix crash on IO error during truncate
mips: loongson64: lemote-2f: Add IRQF_NO_SUSPEND to "cascade" irqaction.
MIPS: Ensure ELF appended dtb is relocated
MIPS: Fix kernel crash for R6 in jump label branch function
scsi: ibmvscsi: Protect ibmvscsi_head from concurrent modificaiton
scsi: ibmvscsi: Fix empty event pool access during host removal
futex: Ensure that futex address is aligned in handle_futex_death()
perf probe: Fix getting the kernel map
objtool: Move objtool_file struct off the stack
ALSA: x86: Fix runtime PM for hdmi-lpe-audio
ext4: fix NULL pointer dereference while journal is aborted
ext4: fix data corruption caused by unaligned direct AIO
ext4: brelse all indirect buffer in ext4_ind_remove_space()
media: v4l2-ctrls.c/uvc: zero v4l2_event
Bluetooth: hci_uart: Check if socket buffer is ERR_PTR in h4_recv_buf()
Bluetooth: Fix decrementing reference count twice in releasing socket
Bluetooth: hci_ldisc: Initialize hci_dev before open()
Bluetooth: hci_ldisc: Postpone HCI_UART_PROTO_READY bit set in hci_uart_set_proto()
drm: Reorder set_property_atomic to avoid returning with an active ww_ctx
netfilter: ebtables: remove BUGPRINT messages
x86/unwind: Handle NULL pointer calls better in frame unwinder
x86/unwind: Add hardcoded ORC entry for NULL
locking/lockdep: Add debug_locks check in __lock_downgrade()
ALSA: hda - Record the current power state before suspend/resume calls
ALSA: hda - Enforces runtime_resume after S3 and S4 for each codec
lib/int_sqrt: optimize small argument
USB: core: only clean up what we allocated
scsi: ufs: fix wrong command type of UTRD for UFSHCI v2.1
PCI: designware-ep: dw_pcie_ep_set_msi() should only set MMC bits
PCI: designware-ep: Read-only registers need DBI_RO_WR_EN to be writable
PCI: endpoint: Use EPC's device in dma_alloc_coherent()/dma_free_coherent()
rtc: Fix overflow when converting time64_t to rtc_time
sched/cpufreq/schedutil: Fix error path mutex unlock
pwm-backlight: Enable/disable the PWM before/after LCD enable toggle.
power: supply: charger-manager: Fix incorrect return value
ath10k: avoid possible string overflow
Linux 4.14.109
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Mark Salyzyn [Wed, 9 May 2018 19:26:22 +0000 (12:26 -0700)]
Revert "ANDROID: input: keychord: Add keychord driver"
This reverts commit
08a0437bf8d9085dd063171b5b37aae89fa42470.
Remove keychord driver, replaced in user space by
https://android-review.googlesource.com/c/677629.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Cc: Mike Lockwood <lockwood@android.com>
Cc: Amit Pundir <amit.pundir@linaro.org>
Bug:
64114943
Bug:
129556081
Change-Id: I6afdb551f273b6d0e25bf4b23cd8b88e39fbe47f
Mark Salyzyn [Wed, 9 May 2018 19:24:54 +0000 (12:24 -0700)]
Revert "ANDROID: input: keychord: log when keychord triggered"
This reverts commit
4017c45e8bc6f34710fd3727c5bc18184b26879c.
Remove keychord driver, replaced in user space by
https://android-review.googlesource.com/c/677629.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Cc: JP Abgrall <jpa@google.com>
Cc: Amit Pundir <amit.pundir@linaro.org>
Bug:
64114943
Bug:
129556081
Change-Id: I6db729ae86ea9d01e2f2266c5572a4fcafcbb325
Mark Salyzyn [Wed, 9 May 2018 19:23:28 +0000 (12:23 -0700)]
Revert "ANDROID: input: keychord: Fix a slab out-of-bounds read."
This reverts commit
92fc7f9aa0298cc112b2893e4e0bcf522f2659a8.
Remove keychord driver, replaced in user space by
https://android-review.googlesource.com/c/677629.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Cc: Amit Pundir <amit.pundir@linaro.org>
Bug:
64114943
Bug:
63962952
Bug:
129556081
Change-Id: I0a652b72b0ee62974c408ffb0987cc2ef9e346c1
Mark Salyzyn [Wed, 9 May 2018 19:19:32 +0000 (12:19 -0700)]
Revert "ANDROID: input: keychord: Fix races in keychord_write."
This reverts commit
8253552b9900cf4497e1c7d15a83ddc5995abcd8.
Remove keychord driver, replaced in user space by
https://android-review.googlesource.com/c/677629.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug:
64114943
Bug:
64133562
Bug:
63974334
Bug:
129556081
Change-Id: Ie94621b0adf8b1f8c0d249f74385cc2914b1aec0
Mark Salyzyn [Wed, 9 May 2018 19:17:36 +0000 (12:17 -0700)]
Revert "ANDROID: input: keychord: Fix for a memory leak in keychord."
This reverts commit
29be5c0c2ef587e7958ef16cc8357e8880e92cd9.
Remove keychord driver, replaced in user space by
https://android-review.googlesource.com/c/677629.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug:
64114943
Bug:
64483974
Bug:
129556081
Change-Id: I4191a02aa70f3c4eb517b9a0ec092380b90130b4
Mark Salyzyn [Fri, 29 Mar 2019 21:23:43 +0000 (14:23 -0700)]
ANDROID: drop CONFIG_INPUT_KEYCHORD from cuttlefish
Remove keychord driver, replaced in user space by
https://android-review.googlesource.com/c/677629.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug:
129556081
Change-Id: Ie8a2b9977a21022c204a19f1a8d781ea5a23c656
Linus Torvalds [Fri, 15 Mar 2019 18:26:07 +0000 (11:26 -0700)]
UPSTREAM: filemap: add a comment about FAULT_FLAG_RETRY_NOWAIT behavior
I thought Josef Bacik's patch to drop the mmap_sem was buggy, because
when looking at the error cases, there was one case where we returned
VM_FAULT_RETRY without actually dropping the mmap_sem.
Josef had to explain to me (using small words) that yes, that's actually
what we're supposed to do, and his patch was correct. Which not only
convinced me he knew what he was doing and I should stop arguing with
him, but also that I should add a comment to the case I was confused
about.
Bug:
124328118
Change-Id: I968005b3673da3adad843c2660111e9a70f98c26
Patiently-pointed-out-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
8b0f9fa2e02dc95216577c3387b0707c5f60fbaf)
Signed-off-by: Minchan Kim <minchan@google.com>
Josef Bacik [Wed, 13 Mar 2019 18:44:22 +0000 (11:44 -0700)]
BACKPORT: filemap: drop the mmap_sem for all blocking operations
Currently we only drop the mmap_sem if there is contention on the page
lock. The idea is that we issue readahead and then go to lock the page
while it is under IO and we want to not hold the mmap_sem during the IO.
The problem with this is the assumption that the readahead does anything.
In the case that the box is under extreme memory or IO pressure we may end
up not reading anything at all for readahead, which means we will end up
reading in the page under the mmap_sem.
Even if the readahead does something, it could get throttled because of io
pressure on the system and the process is in a lower priority cgroup.
Holding the mmap_sem while doing IO is problematic because it can cause
system-wide priority inversions. Consider some large company that does a
lot of web traffic. This large company has load balancing logic in it's
core web server, cause some engineer thought this was a brilliant plan.
This load balancing logic gets statistics from /proc about the system,
which trip over processes mmap_sem for various reasons. Now the web
server application is in a protected cgroup, but these other processes may
not be, and if they are being throttled while their mmap_sem is held we'll
stall, and cause this nice death spiral.
Instead rework filemap fault path to drop the mmap sem at any point that
we may do IO or block for an extended period of time. This includes while
issuing readahead, locking the page, or needing to call ->readpage because
readahead did not occur. Then once we have a fully uptodate page we can
return with VM_FAULT_RETRY and come back again to find our nicely in-cache
page that was gotten outside of the mmap_sem.
This patch also adds a new helper for locking the page with the mmap_sem
dropped. This doesn't make sense currently as generally speaking if the
page is already locked it'll have been read in (unless there was an error)
before it was unlocked. However a forthcoming patchset will change this
with the ability to abort read-ahead bio's if necessary, making it more
likely that we could contend for a page lock and still have a not uptodate
page. This allows us to deal with this case by grabbing the lock and
issuing the IO without the mmap_sem held, and then returning
VM_FAULT_RETRY to come back around.
Test: fio mmap ioengine with 8-thread on 4cpu under memory pressure for
stability check
Test: locking holding latency measure with lockstat for performance
check
Bug:
124328118
Change-Id: I18368917b23fecc592e8e4a65b0f3f5576218e45
[josef@toxicpanda.com: v6]
Link: http://lkml.kernel.org/r/20181212152757.10017-1-josef@toxicpanda.com
[kirill@shutemov.name: fix race in filemap_fault()]
Link: http://lkml.kernel.org/r/20181228235106.okk3oastsnpxusxs@kshutemo-mobl1
[akpm@linux-foundation.org: coding style fixes]
Link: http://lkml.kernel.org/r/20181211173801.29535-4-josef@toxicpanda.com
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Jan Kara <jack@suse.cz>
Tested-by: syzbot+b437b5a429d680cf2217@syzkaller.appspotmail.com
Cc: Dave Chinner <david@fromorbit.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
6b4c9f4469819a0c1a38a0a4541337e0f9bf6c11)
Signed-off-by: Minchan Kim <minchan@google.com>
Josef Bacik [Wed, 13 Mar 2019 18:44:14 +0000 (11:44 -0700)]
BACKPORT: filemap: kill page_cache_read usage in filemap_fault
Patch series "drop the mmap_sem when doing IO in the fault path", v6.
Now that we have proper isolation in place with cgroups2 we have started
going through and fixing the various priority inversions. Most are all
gone now, but this one is sort of weird since it's not necessarily a
priority inversion that happens within the kernel, but rather because of
something userspace does.
We have giant applications that we want to protect, and parts of these
giant applications do things like watch the system state to determine how
healthy the box is for load balancing and such. This involves running
'ps' or other such utilities. These utilities will often walk
/proc/<pid>/whatever, and these files can sometimes need to
down_read(&task->mmap_sem). Not usually a big deal, but we noticed when
we are stress testing that sometimes our protected application has latency
spikes trying to get the mmap_sem for tasks that are in lower priority
cgroups.
This is because any down_write() on a semaphore essentially turns it into
a mutex, so even if we currently have it held for reading, any new readers
will not be allowed on to keep from starving the writer. This is fine,
except a lower priority task could be stuck doing IO because it has been
throttled to the point that its IO is taking much longer than normal. But
because a higher priority group depends on this completing it is now stuck
behind lower priority work.
In order to avoid this particular priority inversion we want to use the
existing retry mechanism to stop from holding the mmap_sem at all if we
are going to do IO. This already exists in the read case sort of, but
needed to be extended for more than just grabbing the page lock. With
io.latency we throttle at submit_bio() time, so the readahead stuff can
block and even page_cache_read can block, so all these paths need to have
the mmap_sem dropped.
The other big thing is ->page_mkwrite. btrfs is particularly shitty here
because we have to reserve space for the dirty page, which can be a very
expensive operation. We use the same retry method as the read path, and
simply cache the page and verify the page is still setup properly the next
pass through ->page_mkwrite().
I've tested these patches with xfstests and there are no regressions.
This patch (of 3):
If we do not have a page at filemap_fault time we'll do this weird forced
page_cache_read thing to populate the page, and then drop it again and
loop around and find it. This makes for 2 ways we can read a page in
filemap_fault, and it's not really needed. Instead add a FGP_FOR_MMAP
flag so that pagecache_get_page() will return a unlocked page that's in
pagecache. Then use the normal page locking and readpage logic already in
filemap_fault. This simplifies the no page in page cache case
significantly.
Bug:
124328118
Change-Id: I89088ef20a5cf5468e358064fc0bc85fcc6e3fc2
[akpm@linux-foundation.org: fix comment text]
[josef@toxicpanda.com: don't unlock null page in FGP_FOR_MMAP case]
Link: http://lkml.kernel.org/r/20190312201742.22935-1-josef@toxicpanda.com
Link: http://lkml.kernel.org/r/20181211173801.29535-2-josef@toxicpanda.com
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
a75d4c33377277b6034dd1e2663bce444f952c14)
Signed-off-by: Minchan Kim <minchan@google.com>
Josef Bacik [Wed, 13 Mar 2019 18:44:18 +0000 (11:44 -0700)]
UPSTREAM: filemap: pass vm_fault to the mmap ra helpers
All of the arguments to these functions come from the vmf.
Cut down on the amount of arguments passed by simply passing in the vmf
to these two helpers.
Bug:
124328118
Change-Id: I5029f277431aaa50ee58df185fa13d7c58b3d774
Link: http://lkml.kernel.org/r/20181211173801.29535-3-josef@toxicpanda.com
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
2a1180f1bd389e9d47693e5eb384b95f482d8d19)
Signed-off-by: Minchan Kim <minchan@google.com>
Chenbo Feng [Fri, 29 Mar 2019 00:52:21 +0000 (17:52 -0700)]
ANDROID: Remove Android paranoid check for socket creation
For 4.14+ kernels, eBPF cgroup socket filter is used to control socket
creation on devices. Remove this check since it is no longer useful.
Signed-off-by: Chenbo Feng <fengc@google.com>
Bug:
128944261
Test: CtsNetTestCasesInternetPermission
Change-Id: I2f353663389fc0f992e5a1b424c12215a2b074b0
Matthew Wilcox [Fri, 5 Jan 2018 00:17:59 +0000 (16:17 -0800)]
BACKPORT: mm/debug.c: provide useful debugging information for VM_BUG
With the recent addition of hashed kernel pointers, places which need to
produce useful debug output have to specify %px, not %p. This patch
fixes all the VM debug to use %px. This is appropriate because it's
debug output that the user should never be able to trigger, and kernel
developers need to see the actual pointers.
Link: http://lkml.kernel.org/r/20171219133236.GE13680@bombadil.infradead.org
Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: "Tobin C. Harding" <me@tobin.cc>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
152a2d199e1385c6ccef17c24555103b30447c91)
Signed-off-by: Sandeep Patil <sspatil@android.com>
Conflicts:
mm/debug.c
Bug:
124090075
Test: Build and boot cuttlefish
Change-Id: I280ec3e95c64904576d65ab3b8b90330da54416b
Borislav Petkov [Fri, 26 Jan 2018 12:11:36 +0000 (13:11 +0100)]
UPSTREAM: x86/alternative: Print unadorned pointers
After commit
ad67b74d2469 ("printk: hash addresses printed with %p")
pointers are being hashed when printed. However, this makes the alternative
debug output completely useless. Switch to %px in order to see the
unadorned kernel pointers.
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: riel@redhat.com
Cc: ak@linux.intel.com
Cc: peterz@infradead.org
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: jikos@kernel.org
Cc: luto@amacapital.net
Cc: dave.hansen@intel.com
Cc: torvalds@linux-foundation.org
Cc: keescook@google.com
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: tim.c.chen@linux.intel.com
Cc: gregkh@linux-foundation.org
Cc: pjt@google.com
Link: https://lkml.kernel.org/r/20180126121139.31959-2-bp@alien8.de
(cherry picked from commit
0e6c16c652cadaffd25a6bb326ec10da5bcec6b4)
Signed-off-by: Sandeep Patil <sspatil@android.com>
Bug:
78533979
Test: Build and boot cuttlefish
Change-Id: Ifd8e85564bce6530201ee1a8ea032a8ac2e65aee
Ravi Bangoria [Sat, 6 Jan 2018 05:42:46 +0000 (11:12 +0530)]
UPSTREAM: trace_uprobe: Display correct offset in uprobe_events
Recently, how the pointers being printed with %p has been changed
by commit
ad67b74d2469 ("printk: hash addresses printed with %p").
This is causing a regression while showing offset in the
uprobe_events file. Instead of %p, use %px to display offset.
Before patch:
# perf probe -vv -x /tmp/a.out main
Opening /sys/kernel/debug/tracing//uprobe_events write=1
Writing event: p:probe_a/main /tmp/a.out:0x58c
# cat /sys/kernel/debug/tracing/uprobe_events
p:probe_a/main /tmp/a.out:0x0000000049a0f352
After patch:
# cat /sys/kernel/debug/tracing/uprobe_events
p:probe_a/main /tmp/a.out:0x000000000000058c
Link: http://lkml.kernel.org/r/20180106054246.15375-1-ravi.bangoria@linux.vnet.ibm.com
Cc: stable@vger.kernel.org
Fixes:
ad67b74d2469 ("printk: hash addresses printed with %p")
Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
(cherry picked from commit
0e4d819d0893dc043ea7b7cb6baf4be1e310bd96)
Signed-off-by: Sandeep Patil <sspatil@android.com>
Bug:
78533979
Test: Build and boot cuttlefish
Change-Id: Iede3934b79b35063691f79abaf2d2b45e4a68cf8
Kees Cook [Tue, 2 Jan 2018 20:15:53 +0000 (12:15 -0800)]
UPSTREAM: usercopy: Remove pointer from overflow report
Using %p was already mostly useless in the usercopy overflow reports,
so this removes it entirely to avoid confusion now that %p-hashing
is enabled.
Fixes:
ad67b74d2469d9b8 ("printk: hash addresses printed with %p")
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit
4f5e838605c264fcf16c3ff9495bd83da99acc6a)
Signed-off-by: Sandeep Patil <sspatil@android.com>
Bug:
78533979
Test: Build and boot cuttlefish
Change-Id: I6818c6a678844f174f4ac7ca08b945ec7ce229d5
Kees Cook [Tue, 19 Dec 2017 21:52:23 +0000 (13:52 -0800)]
UPSTREAM: Do not hash userspace addresses in fault handlers
The hashing of %p was designed to restrict kernel addresses. There is
no reason to hash the userspace values seen during a segfault report,
so switch these to %px. (Some architectures already use %lx.)
Fixes:
ad67b74d2469d9b8 ("printk: hash addresses printed with %p")
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
10a7e9d849150a2879efc0b04d8a51068c9dd0c5)
Signed-off-by: Sandeep Patil <sspatil@android.com>
Bug:
78533979
Test: Build and boot cuttlefish
Change-Id: Ibd04bf839ec7c86884ad2366324bf9cd69d05f34
Geert Uytterhoeven [Thu, 14 Dec 2017 23:32:58 +0000 (15:32 -0800)]
UPSTREAM: mm/slab.c: do not hash pointers when debugging slab
If CONFIG_DEBUG_SLAB/CONFIG_DEBUG_SLAB_LEAK are enabled, the slab code
prints extra debug information when e.g. corruption is detected. This
includes pointers, which are not very useful when hashed.
Fix this by using %px to print unhashed pointers instead where it makes
sense, and by removing the printing of a last user pointer referring to
code.
[geert+renesas@glider.be: v2]
Link: http://lkml.kernel.org/r/1513179267-2509-1-git-send-email-geert+renesas@glider.be
Link: http://lkml.kernel.org/r/1512641861-5113-1-git-send-email-geert+renesas@glider.be
Fixes:
ad67b74d2469d9b8 ("printk: hash addresses printed with %p")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Christoph Lameter <cl@linux.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: "Tobin C . Harding" <me@tobin.cc>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
85c3e4a5a185f22649c6bf33bdce7bb1ac890921)
Signed-off-by: Sandeep Patil <sspatil@android.com>
Bug:
78533979
Test: Build and boot cuttlefish
Change-Id: I721a4ca47adfbb70b3fa1859a66a3c5fbca0dd00
Tobin C. Harding [Wed, 1 Nov 2017 04:32:22 +0000 (15:32 +1100)]
UPSTREAM: kasan: use %px to print addresses instead of %p
Pointers printed with %p are now hashed by default. Kasan needs the
actual address. We can use the new printk specifier %px for this
purpose.
Use %px instead of %p to print addresses.
Signed-off-by: Tobin C. Harding <me@tobin.cc>
(cherry picked from commit
6424f6bb432752c7eb90cbeeb1c31d6125bba39a)
Signed-off-by: Sandeep Patil <sspatil@android.com>
Bug:
78533979
Test: Build and boot cuttlefish
Change-Id: I8059d086c2cb2ec8ca01520acb2227335330e067
Tobin C. Harding [Wed, 22 Nov 2017 23:59:45 +0000 (10:59 +1100)]
UPSTREAM: vsprintf: add printk specifier %px
printk specifier %p now hashes all addresses before printing. Sometimes
we need to see the actual unmodified address. This can be achieved using
%lx but then we face the risk that if in future we want to change the
way the Kernel handles printing of pointers we will have to grep through
the already existent 50 000 %lx call sites. Let's add specifier %px as a
clear, opt-in, way to print a pointer and maintain some level of
isolation from all the other hex integer output within the Kernel.
Add printk specifier %px to print the actual unmodified address.
Signed-off-by: Tobin C. Harding <me@tobin.cc>
(cherry picked from commit
7b1924a1d930eb27fc79c4e4e2a6c1c970623e68)
Signed-off-by: Sandeep Patil <sspatil@android.com>
Bug:
78533979
Test: Build and boot cuttlefish
Change-Id: I3fe64ef81cfb62d49822511cf8087e17abc6da37
Tobin C. Harding [Wed, 1 Nov 2017 04:32:23 +0000 (15:32 +1100)]
UPSTREAM: printk: hash addresses printed with %p
Currently there exist approximately 14 000 places in the kernel where
addresses are being printed using an unadorned %p. This potentially
leaks sensitive information regarding the Kernel layout in memory. Many
of these calls are stale, instead of fixing every call lets hash the
address by default before printing. This will of course break some
users, forcing code printing needed addresses to be updated.
Code that _really_ needs the address will soon be able to use the new
printk specifier %px to print the address.
For what it's worth, usage of unadorned %p can be broken down as
follows (thanks to Joe Perches).
$ git grep -E '%p[^A-Za-z0-9]' | cut -f1 -d"/" | sort | uniq -c
1084 arch
20 block
10 crypto
32 Documentation
8121 drivers
1221 fs
143 include
101 kernel
69 lib
100 mm
1510 net
40 samples
7 scripts
11 security
166 sound
152 tools
2 virt
Add function ptr_to_id() to map an address to a 32 bit unique
identifier. Hash any unadorned usage of specifier %p and any malformed
specifiers.
Signed-off-by: Tobin C. Harding <me@tobin.cc>
(cherry picked from commit
ad67b74d2469d9b82aaa572d76474c95bc484d57)
Signed-off-by: Sandeep Patil <sspatil@android.com>
Bug:
78533979
Test: Build and boot cuttlefish
Test: CONFIG_TEST_PRINTF
Change-Id: I9aa3dea0d40a13f5c858ad2253a8a712195ab1d5
Tobin C. Harding [Wed, 22 Nov 2017 23:56:39 +0000 (10:56 +1100)]
UPSTREAM: vsprintf: refactor %pK code out of pointer()
Currently code to handle %pK is all within the switch statement in
pointer(). This is the wrong level of abstraction. Each of the other switch
clauses call a helper function, pK should do the same.
Refactor code out of pointer() to new function restricted_pointer().
Signed-off-by: Tobin C. Harding <me@tobin.cc>
(cherry picked from commit
57e734423adda83f3b05505875343284efe3b39c)
Signed-off-by: Sandeep Patil <sspatil@android.com>
Bug:
78533979
Test: Build and boot cuttlefish
Change-Id: Ie78731eb52813a696a33d831b52ae7542ab2a90f
Tobin C. Harding [Wed, 22 Nov 2017 23:55:24 +0000 (10:55 +1100)]
UPSTREAM: docs: correct documentation for %pK
Current documentation indicates that %pK prints a leading '0x'. This is
not the case.
Correct documentation for printk specifier %pK.
Signed-off-by: Tobin C. Harding <me@tobin.cc>
(cherry picked from commit
553d8e8b107159088cc4e2855a2bd9a358365e3f)
Signed-off-by: Sandeep Patil <sspatil@android.com>
Bug:
78533979
Test: n/a
Change-Id: I055e337b876fa3235c65182fbe6b85f17da4295f
Jaegeuk Kim [Thu, 21 Mar 2019 03:13:59 +0000 (20:13 -0700)]
Merge upstream-f2fs-stable-linux-4.14.y into android-4.14
* origin/upstream-f2fs-stable-linux-4.14.y:
f2fs: set pin_file under CAP_SYS_ADMIN
f2fs: fix to avoid deadlock in f2fs_read_inline_dir()
f2fs: fix to adapt small inline xattr space in __find_inline_xattr()
f2fs: fix to do sanity check with inode.i_inline_xattr_size
f2fs: give some messages for inline_xattr_size
f2fs: don't trigger read IO for beyond EOF page
f2fs: fix to add refcount once page is tagged PG_private
f2fs: remove wrong comment in f2fs_invalidate_page()
f2fs: fix to use kvfree instead of kzfree
f2fs: print more parameters in trace_f2fs_map_blocks
f2fs: trace f2fs_ioc_shutdown
f2fs: fix to avoid deadlock of atomic file operations
f2fs: fix to dirty inode for i_mode recovery
f2fs: give random value to i_generation
f2fs: no need to take page lock in readdir
f2fs: fix to update iostat correctly in IPU path
f2fs: fix encrypted page memory leak
f2fs: make fault injection covering __submit_flush_wait()
f2fs: fix to retry fill_super only if recovery failed
f2fs: silence VM_WARN_ON_ONCE in mempool_alloc
f2fs: correct spelling mistake
f2fs: fix wrong #endif
f2fs: don't clear CP_QUOTA_NEED_FSCK_FLAG
f2fs: don't allow negative ->write_io_size_bits
f2fs: fix to check inline_xattr_size boundary correctly
Revert "f2fs: fix to avoid deadlock of atomic file operations"
Revert "f2fs: fix to check inline_xattr_size boundary correctly"
f2fs: do not use mutex lock in atomic context
f2fs: fix potential data inconsistence of checkpoint
f2fs: fix to avoid deadlock of atomic file operations
f2fs: fix to check inline_xattr_size boundary correctly
f2fs: jump to label 'free_node_inode' when failing from d_make_root()
f2fs: fix to document inline_xattr_size option
f2fs: fix to data block override node segment by mistake
f2fs: fix typos in code comments
f2fs: use xattr_prefix to wrap up
f2fs: sync filesystem after roll-forward recovery
f2fs: flush quota blocks after turnning it off
f2fs: avoid null pointer exception in dcc_info
f2fs: don't wake up too frequently, if there is lots of IOs
f2fs: try to keep CP_TRIMMED_FLAG after successful umount
f2fs: add quick mode of checkpoint=disable for QA
f2fs: run discard jobs when put_super
f2fs: fix to set sbi dirty correctly
f2fs: fix to initialize variable to avoid UBSAN/smatch warning
f2fs: UBSAN: set boolean value iostat_enable correctly
f2fs: add brackets for macros
f2fs: check if file namelen exceeds max value
f2fs: fix to trigger fsck if dirent.name_len is zero
f2fs: no need to check return value of debugfs_create functions
f2fs: export FS_NOCOW_FL flag to user
f2fs: check inject_rate validity during configuring
f2fs: remove set but not used variable 'err'
f2fs: fix compile warnings: 'struct *' declared inside parameter list
f2fs: change error code to -ENOMEM from -EINVAL
Change-Id: Id02c25e6dafae1bc8cb3a1b047a421355073202e
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Todd Kjos [Wed, 27 Mar 2019 23:12:31 +0000 (16:12 -0700)]
ANDROID: binder: remove extra declaration left after backport
When backporting commit
1a7c3d9bb7a9 ("binder: create
userspace-to-binder-buffer copy function"), an extra "int target_fd;"
was left in the code. This resulted in the possibility of accessing
an uninitialized variable which was flagged by gcc.
Bug:
67668716
Change-Id: I787ed89579e9d40e8530d79be67cc663ec755e54
Signed-off-by: Todd Kjos <tkjos@google.com>
Todd Kjos [Tue, 19 Mar 2019 16:53:01 +0000 (09:53 -0700)]
FROMGIT: binder: fix BUG_ON found by selinux-testsuite
The selinux-testsuite found an issue resulting in a BUG_ON()
where a conditional relied on a size_t going negative when
checking the validity of a buffer offset.
(cherry picked from commit
5997da82145bb7c9a56d834894cb81f81f219344
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
char-misc-linus)
Bug:
67668716
Bug:
129336614
Change-Id: Ib3b408717141deadddcb6b95ad98c0b97d9d98ea
Fixes:
7a67a39320df ("binder: add function to copy binder object from buffer")
Reported-by: Paul Moore <paul@paul-moore.com>
Tested-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Todd Kjos <tkjos@google.com>
Greg Kroah-Hartman [Wed, 27 Mar 2019 05:13:56 +0000 (14:13 +0900)]
Linux 4.14.109
Arnd Bergmann [Wed, 28 Mar 2018 22:06:10 +0000 (00:06 +0200)]
ath10k: avoid possible string overflow
commit
6707ba0105a2d350710bc0a537a98f49eb4b895d upstream.
The way that 'strncat' is used here raised a warning in gcc-8:
drivers/net/wireless/ath/ath10k/wmi.c: In function 'ath10k_wmi_tpc_stats_final_disp_tables':
drivers/net/wireless/ath/ath10k/wmi.c:4649:4: error: 'strncat' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
Effectively, this is simply a strcat() but the use of strncat() suggests
some form of overflow check. Regardless of whether this might actually
overflow, using strlcat() instead of strncat() avoids the warning and
makes the code more robust.
Fixes:
bc64d05220f3 ("ath10k: debugfs support to get final TPC stats for 10.4 variants")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Baolin Wang [Fri, 16 Nov 2018 11:01:10 +0000 (19:01 +0800)]
power: supply: charger-manager: Fix incorrect return value
commit
f25a646fbe2051527ad9721853e892d13a99199e upstream.
Fix incorrect return value.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Enric Balletbo i Serra [Wed, 28 Mar 2018 17:03:23 +0000 (19:03 +0200)]
pwm-backlight: Enable/disable the PWM before/after LCD enable toggle.
commit
5fb5caee92ba35a4a3baa61d45a78eb057e2c031 upstream.
Before this patch the enable signal was set before the PWM signal and
vice-versa on power off. This sequence is wrong, at least, it is on
the different panels datasheets that I checked, so I inverted the sequence
to follow the specs.
For reference the following panels have the mentioned sequence:
- N133HSE-EA1 (Innolux)
- N116BGE (Innolux)
- N156BGE-L21 (Innolux)
- B101EAN0 (Auo)
- B101AW03 (Auo)
- LTN101NT05 (Samsung)
- CLAA101WA01A (Chunghwa)
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jules Maselbas [Thu, 29 Mar 2018 14:43:01 +0000 (15:43 +0100)]
sched/cpufreq/schedutil: Fix error path mutex unlock
commit
1b5d43cfb69759d8ef8d30469cea31d0c037aed5 upstream.
This patch prevents the 'global_tunables_lock' mutex from being
unlocked before being locked. This mutex is not locked if the
sugov_kthread_create() function fails.
Signed-off-by: Jules Maselbas <jules.maselbas@arm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Chris Redpath <chris.redpath@arm.com>
Cc: Dietmar Eggermann <dietmar.eggemann@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Patrick Bellasi <patrick.bellasi@arm.com>
Cc: Stephen Kyle <stephen.kyle@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Cc: nd@arm.com
Link: http://lkml.kernel.org/r/20180329144301.38419-1-jules.maselbas@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Baolin Wang [Mon, 25 Dec 2017 11:10:37 +0000 (19:10 +0800)]
rtc: Fix overflow when converting time64_t to rtc_time
commit
36d46cdb43efea74043e29e2a62b13e9aca31452 upstream.
If we convert one large time values to rtc_time, in the original formula
'days * 86400' can be overflowed in 'unsigned int' type to make the formula
get one incorrect remain seconds value. Thus we can use div_s64_rem()
function to avoid this situation.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kishon Vijay Abraham I [Thu, 11 Jan 2018 08:30:57 +0000 (14:00 +0530)]
PCI: endpoint: Use EPC's device in dma_alloc_coherent()/dma_free_coherent()
commit
b330104fa76df3eae6e199a23791fed5d35f06b4 upstream.
After commit
723288836628 ("of: restrict DMA configuration"),
of_dma_configure() doesn't configure the coherent_dma_mask/dma_mask
of endpoint function device (since it doesn't have a DT node associated
with and hence no dma-ranges property), resulting in
dma_alloc_coherent() (used in pci_epf_alloc_space()) to fail.
Fix it by making dma_alloc_coherent() use EPC's device for allocating
memory address.
Link: http://lkml.kernel.org/r/64d63468-d28f-8fcd-a6f3-cf2a6401c8cb@ti.com
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
[lorenzo.pieralisi@arm.com: tweaked commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Tested-by: Cyrille Pitchen <cyrille.pitchen@free-electrons.com>
Tested-by: Niklas Cassel <niklas.cassel@axis.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Niklas Cassel [Tue, 19 Dec 2017 23:29:24 +0000 (00:29 +0100)]
PCI: designware-ep: Read-only registers need DBI_RO_WR_EN to be writable
commit
1cab826b30c6275d479a6ab1dea1067e15dbec62 upstream.
Certain registers that pcie-designware-ep tries to write to are read-only
registers. However, these registers can become read/write if we first
enable the DBI_RO_WR_EN bit. Set/unset the DBI_RO_WR_EN bit before/after
writing these registers.
Tested-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Joao Pinto <jpinto@synopsys.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Niklas Cassel [Tue, 19 Dec 2017 23:29:23 +0000 (00:29 +0100)]
PCI: designware-ep: dw_pcie_ep_set_msi() should only set MMC bits
commit
099a95f3591ade29da52131895a3ba9f92a0e82c upstream.
Previously, dw_pcie_ep_set_msi() wrote all bits in the Message Control
register, thus overwriting the PCI_MSI_FLAGS_64BIT bit.
By clearing the PCI_MSI_FLAGS_64BIT bit, we break MSI
on systems where the RC has set a 64 bit MSI address.
Fix dw_pcie_ep_set_msi() so that it only sets MMC bits.
Tested-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Joao Pinto <jpinto@synopsys.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
kehuanlin [Wed, 6 Sep 2017 09:58:39 +0000 (17:58 +0800)]
scsi: ufs: fix wrong command type of UTRD for UFSHCI v2.1
commit
83dc7e3dea76b77b6bcc289eb86c5b5c145e8dff upstream.
Since the command type of UTRD in UFS 2.1 specification is the same with
UFS 2.0. And it assumes the future UFS specification will follow the
same definition.
Signed-off-by: kehuanlin <kehuanlin@pinecone.net>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrey Konovalov [Mon, 11 Dec 2017 21:48:41 +0000 (22:48 +0100)]
USB: core: only clean up what we allocated
commit
32fd87b3bbf5f7a045546401dfe2894dbbf4d8c3 upstream.
When cleaning up the configurations, make sure we only free the number
of configurations and interfaces that we could have allocated.
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Zijlstra [Fri, 17 Nov 2017 23:28:04 +0000 (15:28 -0800)]
lib/int_sqrt: optimize small argument
commit
3f3295709edea6268ff1609855f498035286af73 upstream.
The current int_sqrt() computation is sub-optimal for the case of small
@x. Which is the interesting case when we're going to do cumulative
distribution functions on idle times, which we assume to be a random
variable, where the target residency of the deepest idle state gives an
upper bound on the variable (5e6ns on recent Intel chips).
In the case of small @x, the compute loop:
while (m != 0) {
b = y + m;
y >>= 1;
if (x >= b) {
x -= b;
y += m;
}
m >>= 2;
}
can be reduced to:
while (m > x)
m >>= 2;
Because y==0, b==m and until x>=m y will remain 0.
And while this is computationally equivalent, it runs much faster
because there's less code, in particular less branches.
cycles: branches: branch-misses:
OLD:
hot: 45.109444 +- 0.044117 44.333392 +- 0.002254 0.018723 +- 0.000593
cold: 187.737379 +- 0.156678 44.333407 +- 0.002254 6.272844 +- 0.004305
PRE:
hot: 67.937492 +- 0.064124 66.999535 +- 0.000488 0.066720 +- 0.001113
cold: 232.004379 +- 0.332811 66.999527 +- 0.000488 6.914634 +- 0.006568
POST:
hot: 43.633557 +- 0.034373 45.333132 +- 0.002277 0.023529 +- 0.000681
cold: 207.438411 +- 0.125840 45.333132 +- 0.002277 6.976486 +- 0.004219
Averages computed over all values <128k using a LFSR to generate order.
Cold numbers have a LFSR based branch trace buffer 'confuser' ran between
each int_sqrt() invocation.
Link: http://lkml.kernel.org/r/20171020164644.876503355@infradead.org
Fixes:
30493cc9dddb ("lib/int_sqrt.c: optimize square root algorithm")
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Suggested-by: Anshul Garg <aksgarg1989@gmail.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Joe Perches <joe@perches.com>
Cc: David Miller <davem@davemloft.net>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Michael Davidson <md@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hui Wang [Tue, 19 Mar 2019 01:28:44 +0000 (09:28 +0800)]
ALSA: hda - Enforces runtime_resume after S3 and S4 for each codec
commit
b5a236c175b0d984552a5f7c9d35141024c2b261 upstream.
Recently we found the audio jack detection stop working after suspend
on many machines with Realtek codec. Sometimes the audio selection
dialogue didn't show up after users plugged headhphone/headset into
the headset jack, sometimes after uses plugged headphone/headset, then
click the sound icon on the upper-right corner of gnome-desktop, it
also showed the speaker rather than the headphone.
The root cause is that before suspend, the codec already call the
runtime_suspend since this codec is not used by any apps, then in
resume, it will not call runtime_resume for this codec. But for some
realtek codec (so far, alc236, alc255 and alc891) with the specific
BIOS, if it doesn't run runtime_resume after suspend, all codec
functions including jack detection stop working anymore.
This problem existed for a long time, but it was not exposed, that is
because when problem happens, if users play sound or open
sound-setting to check audio device, this will trigger calling to
runtime_resume (via snd_hda_power_up), then the codec starts working
again before users notice this problem.
Since we don't know how many codec and BIOS combinations have this
problem, to fix it, let the driver call runtime_resume for all codecs
in pm_resume, maybe for some codecs, this is not needed, but it is
harmless. After a codec is runtime resumed, if it is not used by any
apps, it will be runtime suspended soon and furthermore we don't run
suspend frequently, this change will not add much power consumption.
Fixes:
cc72da7d4d06 ("ALSA: hda - Use standard runtime PM for codec power-save control")
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 29 Jan 2019 13:03:33 +0000 (14:03 +0100)]
ALSA: hda - Record the current power state before suspend/resume calls
commit
98081ca62cbac31fb0f7efaf90b2e7384ce22257 upstream.
Currently we deal with single codec and suspend codec callbacks for
all S3, S4 and runtime PM handling. But it turned out that we want
distinguish the call patterns sometimes, e.g. for applying some init
sequence only at probing and restoring from hibernate.
This patch slightly modifies the common PM callbacks for HD-audio
codec and stores the currently processed PM event in power_state of
the codec's device.power field, which is currently unused. The codec
callback can take a look at this event value and judges which purpose
it's being called.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Waiman Long [Thu, 10 Jan 2019 04:03:25 +0000 (23:03 -0500)]
locking/lockdep: Add debug_locks check in __lock_downgrade()
commit
71492580571467fb7177aade19c18ce7486267f5 upstream.
Tetsuo Handa had reported he saw an incorrect "downgrading a read lock"
warning right after a previous lockdep warning. It is likely that the
previous warning turned off lock debugging causing the lockdep to have
inconsistency states leading to the lock downgrade warning.
Fix that by add a check for debug_locks at the beginning of
__lock_downgrade().
Debugged-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Reported-by: syzbot+53383ae265fb161ef488@syzkaller.appspotmail.com
Signed-off-by: Waiman Long <longman@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
Link: https://lkml.kernel.org/r/1547093005-26085-1-git-send-email-longman@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jann Horn [Fri, 1 Mar 2019 03:12:01 +0000 (04:12 +0100)]
x86/unwind: Add hardcoded ORC entry for NULL
commit
ac5ceccce5501e43d217c596e4ee859f2a3fef79 upstream.
When the ORC unwinder is invoked for an oops caused by IP==0,
it currently has no idea what to do because there is no debug information
for the stack frame of NULL.
But if RIP is NULL, it is very likely that the last successfully executed
instruction was an indirect CALL/JMP, and it is possible to unwind out in
the same way as for the first instruction of a normal function. Hardcode
a corresponding ORC entry.
With an artificially-added NULL call in prctl_set_seccomp(), before this
patch, the trace is:
Call Trace:
? __x64_sys_prctl+0x402/0x680
? __ia32_sys_prctl+0x6e0/0x6e0
? __do_page_fault+0x457/0x620
? do_syscall_64+0x6d/0x160
? entry_SYSCALL_64_after_hwframe+0x44/0xa9
After this patch, the trace looks like this:
Call Trace:
__x64_sys_prctl+0x402/0x680
? __ia32_sys_prctl+0x6e0/0x6e0
? __do_page_fault+0x457/0x620
do_syscall_64+0x6d/0x160
entry_SYSCALL_64_after_hwframe+0x44/0xa9
prctl_set_seccomp() still doesn't show up in the trace because for some
reason, tail call optimization is only disabled in builds that use the
frame pointer unwinder.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: syzbot <syzbot+ca95b2b7aef9e7cbd6ab@syzkaller.appspotmail.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: linux-kbuild@vger.kernel.org
Link: https://lkml.kernel.org/r/20190301031201.7416-2-jannh@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jann Horn [Fri, 1 Mar 2019 03:12:00 +0000 (04:12 +0100)]
x86/unwind: Handle NULL pointer calls better in frame unwinder
commit
f4f34e1b82eb4219d8eaa1c7e2e17ca219a6a2b5 upstream.
When the frame unwinder is invoked for an oops caused by a call to NULL, it
currently skips the parent function because BP still points to the parent's
stack frame; the (nonexistent) current function only has the first half of
a stack frame, and BP doesn't point to it yet.
Add a special case for IP==0 that calculates a fake BP from SP, then uses
the real BP for the next frame.
Note that this handles first_frame specially: Return information about the
parent function as long as the saved IP is >=first_frame, even if the fake
BP points below it.
With an artificially-added NULL call in prctl_set_seccomp(), before this
patch, the trace is:
Call Trace:
? prctl_set_seccomp+0x3a/0x50
__x64_sys_prctl+0x457/0x6f0
? __ia32_sys_prctl+0x750/0x750
do_syscall_64+0x72/0x160
entry_SYSCALL_64_after_hwframe+0x44/0xa9
After this patch, the trace is:
Call Trace:
prctl_set_seccomp+0x3a/0x50
__x64_sys_prctl+0x457/0x6f0
? __ia32_sys_prctl+0x750/0x750
do_syscall_64+0x72/0x160
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: syzbot <syzbot+ca95b2b7aef9e7cbd6ab@syzkaller.appspotmail.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: linux-kbuild@vger.kernel.org
Link: https://lkml.kernel.org/r/20190301031201.7416-1-jannh@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Mon, 18 Feb 2019 23:37:21 +0000 (00:37 +0100)]
netfilter: ebtables: remove BUGPRINT messages
commit
d824548dae220820bdf69b2d1561b7c4b072783f upstream.
They are however frequently triggered by syzkaller, so remove them.
ebtables userspace should never trigger any of these, so there is little
value in making them pr_debug (or ratelimited).
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Sun, 30 Dec 2018 12:28:42 +0000 (12:28 +0000)]
drm: Reorder set_property_atomic to avoid returning with an active ww_ctx
commit
227ad6d957898a88b1746e30234ece64d305f066 upstream.
Delay the drm_modeset_acquire_init() until after we check for an
allocation failure so that we can return immediately upon error without
having to unwind.
WARNING: lock held when returning to user space!
4.20.0+ #174 Not tainted
------------------------------------------------
syz-executor556/8153 is leaving the kernel with locks still held!
1 lock held by syz-executor556/8153:
#0:
000000005100c85c (crtc_ww_class_acquire){+.+.}, at:
set_property_atomic+0xb3/0x330 drivers/gpu/drm/drm_mode_object.c:462
Reported-by: syzbot+6ea337c427f5083ebdf2@syzkaller.appspotmail.com
Fixes:
144a7999d633 ("drm: Handle properties in the core for atomic drivers")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Sean Paul <sean@poorly.run>
Cc: David Airlie <airlied@linux.ie>
Cc: <stable@vger.kernel.org> # v4.14+
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181230122842.21917-1-chris@chris-wilson.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kefeng Wang [Sat, 23 Feb 2019 04:33:27 +0000 (12:33 +0800)]
Bluetooth: hci_ldisc: Postpone HCI_UART_PROTO_READY bit set in hci_uart_set_proto()
commit
56897b217a1d0a91c9920cb418d6b3fe922f590a upstream.
task A: task B:
hci_uart_set_proto flush_to_ldisc
- p->open(hu) -> h5_open //alloc h5 - receive_buf
- set_bit HCI_UART_PROTO_READY - tty_port_default_receive_buf
- hci_uart_register_dev - tty_ldisc_receive_buf
- hci_uart_tty_receive
- test_bit HCI_UART_PROTO_READY
- h5_recv
- clear_bit HCI_UART_PROTO_READY while() {
- p->open(hu) -> h5_close //free h5
- h5_rx_3wire_hdr
- h5_reset() //use-after-free
}
It could use ioctl to set hci uart proto, but there is
a use-after-free issue when hci_uart_register_dev() fail in
hci_uart_set_proto(), see stack above, fix this by setting
HCI_UART_PROTO_READY bit only when hci_uart_register_dev()
return success.
Reported-by: syzbot+899a33dc0fa0dbaf06a6@syzkaller.appspotmail.com
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Jeremy Cline <jcline@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jeremy Cline [Wed, 6 Feb 2019 17:54:16 +0000 (12:54 -0500)]
Bluetooth: hci_ldisc: Initialize hci_dev before open()
commit
32a7b4cbe93b0a0ef7e63d31ca69ce54736c4412 upstream.
The hci_dev struct hdev is referenced in work queues and timers started
by open() in some protocols. This creates a race between the
initialization function and the work or timer which can result hdev
being dereferenced while it is still null.
The syzbot report contains a reliable reproducer which causes a null
pointer dereference of hdev in hci_uart_write_work() by making the
memory allocation for hdev fail.
To fix this, ensure hdev is valid from before calling a protocol's
open() until after calling a protocol's close().
Reported-by: syzbot+257790c15bcdef6fe00c@syzkaller.appspotmail.com
Signed-off-by: Jeremy Cline <jcline@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Myungho Jung [Sun, 3 Feb 2019 00:56:36 +0000 (16:56 -0800)]
Bluetooth: Fix decrementing reference count twice in releasing socket
commit
e20a2e9c42c9e4002d9e338d74e7819e88d77162 upstream.
When releasing socket, it is possible to enter hci_sock_release() and
hci_sock_dev_event(HCI_DEV_UNREG) at the same time in different thread.
The reference count of hdev should be decremented only once from one of
them but if storing hdev to local variable in hci_sock_release() before
detached from socket and setting to NULL in hci_sock_dev_event(),
hci_dev_put(hdev) is unexpectedly called twice. This is resolved by
referencing hdev from socket after bt_sock_unlink() in
hci_sock_release().
Reported-by: syzbot+fdc00003f4efff43bc5b@syzkaller.appspotmail.com
Signed-off-by: Myungho Jung <mhjungk@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Myungho Jung [Tue, 22 Jan 2019 08:33:26 +0000 (00:33 -0800)]
Bluetooth: hci_uart: Check if socket buffer is ERR_PTR in h4_recv_buf()
commit
1dc2d785156cbdc80806c32e8d2c7c735d0b4721 upstream.
h4_recv_buf() callers store the return value to socket buffer and
recursively pass the buffer to h4_recv_buf() without protection. So,
ERR_PTR returned from h4_recv_buf() can be dereferenced, if called again
before setting the socket buffer to NULL from previous error. Check if
skb is ERR_PTR in h4_recv_buf().
Reported-by: syzbot+017a32f149406df32703@syzkaller.appspotmail.com
Signed-off-by: Myungho Jung <mhjungk@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans Verkuil [Tue, 18 Dec 2018 13:37:08 +0000 (08:37 -0500)]
media: v4l2-ctrls.c/uvc: zero v4l2_event
commit
f45f3f753b0a3d739acda8e311b4f744d82dc52a upstream.
Control events can leak kernel memory since they do not fully zero the
event. The same code is present in both v4l2-ctrls.c and uvc_ctrl.c, so
fix both.
It appears that all other event code is properly zeroing the structure,
it's these two places.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reported-by: syzbot+4f021cf3697781dbd9fb@syzkaller.appspotmail.com
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
zhangyi (F) [Sat, 23 Mar 2019 15:43:05 +0000 (11:43 -0400)]
ext4: brelse all indirect buffer in ext4_ind_remove_space()
commit
674a2b27234d1b7afcb0a9162e81b2e53aeef217 upstream.
All indirect buffers get by ext4_find_shared() should be released no
mater the branch should be freed or not. But now, we forget to release
the lower depth indirect buffers when removing space from the same
higher depth indirect block. It will lead to buffer leak and futher
more, it may lead to quota information corruption when using old quota,
consider the following case.
- Create and mount an empty ext4 filesystem without extent and quota
features,
- quotacheck and enable the user & group quota,
- Create some files and write some data to them, and then punch hole
to some files of them, it may trigger the buffer leak problem
mentioned above.
- Disable quota and run quotacheck again, it will create two new
aquota files and write the checked quota information to them, which
probably may reuse the freed indirect block(the buffer and page
cache was not freed) as data block.
- Enable quota again, it will invoke
vfs_load_quota_inode()->invalidate_bdev() to try to clean unused
buffers and pagecache. Unfortunately, because of the buffer of quota
data block is still referenced, quota code cannot read the up to date
quota info from the device and lead to quota information corruption.
This problem can be reproduced by xfstests generic/231 on ext3 file
system or ext4 file system without extent and quota features.
This patch fix this problem by releasing the missing indirect buffers,
in ext4_ind_remove_space().
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lukas Czerner [Fri, 15 Mar 2019 03:20:25 +0000 (23:20 -0400)]
ext4: fix data corruption caused by unaligned direct AIO
commit
372a03e01853f860560eade508794dd274e9b390 upstream.
Ext4 needs to serialize unaligned direct AIO because the zeroing of
partial blocks of two competing unaligned AIOs can result in data
corruption.
However it decides not to serialize if the potentially unaligned aio is
past i_size with the rationale that no pending writes are possible past
i_size. Unfortunately if the i_size is not block aligned and the second
unaligned write lands past i_size, but still into the same block, it has
the potential of corrupting the previous unaligned write to the same
block.
This is (very simplified) reproducer from Frank
// 41472 = (10 * 4096) + 512
// 37376 = 41472 - 4096
ftruncate(fd, 41472);
io_prep_pwrite(iocbs[0], fd, buf[0], 4096, 37376);
io_prep_pwrite(iocbs[1], fd, buf[1], 4096, 41472);
io_submit(io_ctx, 1, &iocbs[1]);
io_submit(io_ctx, 1, &iocbs[2]);
io_getevents(io_ctx, 2, 2, events, NULL);
Without this patch the 512B range from 40960 up to the start of the
second unaligned write (41472) is going to be zeroed overwriting the data
written by the first write. This is a data corruption.
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
00009200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
*
0000a000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0000a200 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31
With this patch the data corruption is avoided because we will recognize
the unaligned_aio and wait for the unwritten extent conversion.
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
00009200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
*
0000a200 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31
*
0000b200
Reported-by: Frank Sorenson <fsorenso@redhat.com>
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Fixes:
e9e3bcecf44c ("ext4: serialize unaligned asynchronous DIO")
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiufei Xue [Fri, 15 Mar 2019 03:19:22 +0000 (23:19 -0400)]
ext4: fix NULL pointer dereference while journal is aborted
commit
fa30dde38aa8628c73a6dded7cb0bba38c27b576 upstream.
We see the following NULL pointer dereference while running xfstests
generic/475:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000008
PGD
8000000c84bad067 P4D
8000000c84bad067 PUD
c84e62067 PMD 0
Oops: 0000 [#1] SMP PTI
CPU: 7 PID: 9886 Comm: fsstress Kdump: loaded Not tainted 5.0.0-rc8 #10
RIP: 0010:ext4_do_update_inode+0x4ec/0x760
...
Call Trace:
? jbd2_journal_get_write_access+0x42/0x50
? __ext4_journal_get_write_access+0x2c/0x70
? ext4_truncate+0x186/0x3f0
ext4_mark_iloc_dirty+0x61/0x80
ext4_mark_inode_dirty+0x62/0x1b0
ext4_truncate+0x186/0x3f0
? unmap_mapping_pages+0x56/0x100
ext4_setattr+0x817/0x8b0
notify_change+0x1df/0x430
do_truncate+0x5e/0x90
? generic_permission+0x12b/0x1a0
This is triggered because the NULL pointer handle->h_transaction was
dereferenced in function ext4_update_inode_fsync_trans().
I found that the h_transaction was set to NULL in jbd2__journal_restart
but failed to attached to a new transaction while the journal is aborted.
Fix this by checking the handle before updating the inode.
Fixes:
b436b9bef84d ("ext4: Wait for proper transaction commit on fsync")
Signed-off-by: Jiufei Xue <jiufei.xue@linux.alibaba.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ville Syrjälä [Wed, 24 Oct 2018 15:48:24 +0000 (18:48 +0300)]
ALSA: x86: Fix runtime PM for hdmi-lpe-audio
commit
8dfb839cfe737a17def8e5f88ee13c295230364a upstream.
Commit
46e831abe864 ("drm/i915/lpe: Mark LPE audio runtime pm as
"no callbacks"") broke runtime PM with lpe audio. We can no longer
runtime suspend the GPU since the sysfs power/control for the
lpe-audio device no longer exists and the device is considered
always active. We can fix this by not marking the device as
active.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Fixes:
46e831abe864 ("drm/i915/lpe: Mark LPE audio runtime pm as "no callbacks"")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181024154825.18185-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josh Poimboeuf [Tue, 19 Mar 2019 00:09:38 +0000 (19:09 -0500)]
objtool: Move objtool_file struct off the stack
commit
0c671812f152b628bd87c0af49da032cc2a2c319 upstream.
Objtool uses over 512k of stack, thanks to the hash table embedded in
the objtool_file struct. This causes an unnecessarily large stack
allocation and breaks users with low stack limits.
Move the struct off the stack.
Fixes:
042ba73fe7eb ("objtool: Add several performance improvements")
Reported-by: Vassili Karpov <moosotc@gmail.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/df92dcbc4b84b02ffa252f46876df125fb56e2d7.1552954176.git.jpoimboe@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Adrian Hunter [Mon, 4 Mar 2019 13:13:21 +0000 (15:13 +0200)]
perf probe: Fix getting the kernel map
commit
eaeffeb9838a7c0dec981d258666bfcc0fa6a947 upstream.
Since commit
4d99e4136580 ("perf machine: Workaround missing maps for
x86 PTI entry trampolines"), perf tools has been creating more than one
kernel map, however 'perf probe' assumed there could be only one.
Fix by using machine__kernel_map() to get the main kernel map.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiufei Xue <jiufei.xue@linux.alibaba.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: stable@vger.kernel.org
Cc: Xu Yu <xuyu@linux.alibaba.com>
Fixes:
4d99e4136580 ("perf machine: Workaround missing maps for x86 PTI entry trampolines")
Fixes:
d83212d5dd67 ("kallsyms, x86: Export addresses of PTI entry trampolines")
Link: http://lkml.kernel.org/r/2ed432de-e904-85d2-5c36-5897ddc5b23b@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chen Jie [Fri, 15 Mar 2019 03:44:38 +0000 (03:44 +0000)]
futex: Ensure that futex address is aligned in handle_futex_death()
commit
5a07168d8d89b00fe1760120714378175b3ef992 upstream.
The futex code requires that the user space addresses of futexes are 32bit
aligned. sys_futex() checks this in futex_get_keys() but the robust list
code has no alignment check in place.
As a consequence the kernel crashes on architectures with strict alignment
requirements in handle_futex_death() when trying to cmpxchg() on an
unaligned futex address which was retrieved from the robust list.
[ tglx: Rewrote changelog, proper sizeof() based alignement check and add
comment ]
Fixes:
0771dfefc9e5 ("[PATCH] lightweight robust futexes: core")
Signed-off-by: Chen Jie <chenjie6@huawei.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: <dvhart@infradead.org>
Cc: <peterz@infradead.org>
Cc: <zengweilin@huawei.com>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/1552621478-119787-1-git-send-email-chenjie6@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tyrel Datwyler [Wed, 20 Mar 2019 18:41:51 +0000 (13:41 -0500)]
scsi: ibmvscsi: Fix empty event pool access during host removal
commit
7f5203c13ba8a7b7f9f6ecfe5a4d5567188d7835 upstream.
The event pool used for queueing commands is destroyed fairly early in the
ibmvscsi_remove() code path. Since, this happens prior to the call so
scsi_remove_host() it is possible for further calls to queuecommand to be
processed which manifest as a panic due to a NULL pointer dereference as
seen here:
PANIC: "Unable to handle kernel paging request for data at address
0x00000000"
Context process backtrace:
DSISR:
0000000042000000 ????Syscall Result:
0000000000000000
4 [
c000000002cb3820] memcpy_power7 at
c000000000064204
[Link Register] [
c000000002cb3820] ibmvscsi_send_srp_event at
d000000003ed14a4
5 [
c000000002cb3920] ibmvscsi_send_srp_event at
d000000003ed14a4 [ibmvscsi] ?(unreliable)
6 [
c000000002cb39c0] ibmvscsi_queuecommand at
d000000003ed2388 [ibmvscsi]
7 [
c000000002cb3a70] scsi_dispatch_cmd at
d00000000395c2d8 [scsi_mod]
8 [
c000000002cb3af0] scsi_request_fn at
d00000000395ef88 [scsi_mod]
9 [
c000000002cb3be0] __blk_run_queue at
c000000000429860
10 [
c000000002cb3c10] blk_delay_work at
c00000000042a0ec
11 [
c000000002cb3c40] process_one_work at
c0000000000dac30
12 [
c000000002cb3cd0] worker_thread at
c0000000000db110
13 [
c000000002cb3d80] kthread at
c0000000000e3378
14 [
c000000002cb3e30] ret_from_kernel_thread at
c00000000000982c
The kernel buffer log is overfilled with this log:
[11261.952732] ibmvscsi: found no event struct in pool!
This patch reorders the operations during host teardown. Start by calling
the SRP transport and Scsi_Host remove functions to flush any outstanding
work and set the host offline. LLDD teardown follows including destruction
of the event pool, freeing the Command Response Queue (CRQ), and unmapping
any persistent buffers. The event pool destruction is protected by the
scsi_host lock, and the pool is purged prior of any requests for which we
never received a response. Finally, move the removal of the scsi host from
our global list to the end so that the host is easily locatable for
debugging purposes during teardown.
Cc: <stable@vger.kernel.org> # v2.6.12+
Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tyrel Datwyler [Wed, 20 Mar 2019 18:41:50 +0000 (13:41 -0500)]
scsi: ibmvscsi: Protect ibmvscsi_head from concurrent modificaiton
commit
7205981e045e752ccf96cf6ddd703a98c59d4339 upstream.
For each ibmvscsi host created during a probe or destroyed during a remove
we either add or remove that host to/from the global ibmvscsi_head
list. This runs the risk of concurrent modification.
This patch adds a simple spinlock around the list modification calls to
prevent concurrent updates as is done similarly in the ibmvfc driver and
ipr driver.
Fixes:
32d6e4b6e4ea ("scsi: ibmvscsi: add vscsi hosts to global list_head")
Cc: <stable@vger.kernel.org> # v4.10+
Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Archer Yan [Fri, 8 Mar 2019 03:29:19 +0000 (03:29 +0000)]
MIPS: Fix kernel crash for R6 in jump label branch function
commit
47c25036b60f27b86ab44b66a8861bcf81cde39b upstream.
Insert Branch instruction instead of NOP to make sure assembler don't
patch code in forbidden slot. In jump label function, it might
be possible to patch Control Transfer Instructions(CTIs) into
forbidden slot, which will generate Reserved Instruction exception
in MIPS release 6.
Signed-off-by: Archer Yan <ayan@wavecomp.com>
Reviewed-by: Paul Burton <paul.burton@mips.com>
[paul.burton@mips.com:
- Add MIPS prefix to subject.
- Mark for stable from v4.0, which introduced r6 support, onwards.]
Signed-off-by: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@vger.kernel.org
Cc: stable@vger.kernel.org # v4.0+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yasha Cherikovsky [Fri, 8 Mar 2019 12:58:51 +0000 (14:58 +0200)]
MIPS: Ensure ELF appended dtb is relocated
commit
3f0a53bc6482fb09770982a8447981260ea258dc upstream.
This fixes booting with the combination of CONFIG_RELOCATABLE=y
and CONFIG_MIPS_ELF_APPENDED_DTB=y.
Sections that appear after the relocation table are not relocated
on system boot (except .bss, which has special handling).
With CONFIG_MIPS_ELF_APPENDED_DTB, the dtb is part of the
vmlinux ELF, so it must be relocated together with everything else.
Fixes:
069fd766271d ("MIPS: Reserve space for relocation table")
Signed-off-by: Yasha Cherikovsky <yasha.che3@gmail.com>
Signed-off-by: Paul Burton <paul.burton@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # v4.7+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yifeng Li [Mon, 4 Mar 2019 22:00:22 +0000 (06:00 +0800)]
mips: loongson64: lemote-2f: Add IRQF_NO_SUSPEND to "cascade" irqaction.
commit
5f5f67da9781770df0403269bc57d7aae608fecd upstream.
Timekeeping IRQs from CS5536 MFGPT are routed to i8259, which then
triggers the "cascade" IRQ on MIPS CPU. Without IRQF_NO_SUSPEND in
cascade_irqaction, MFGPT interrupts will be masked in suspend mode,
and the machine would be unable to resume once suspended.
Previously, MIPS IRQs were not disabled properly, so the original
code appeared to work. Commit
a3e6c1eff5 ("MIPS: IRQ: Fix disable_irq on
CPU IRQs") uncovers the bug. To fix it, add IRQF_NO_SUSPEND to
cascade_irqaction.
This commit is functionally identical to
0add9c2f1cff ("MIPS:
Loongson-3: Add IRQF_NO_SUSPEND to Cascade irqaction"), but it forgot
to apply the same fix to Loongson2.
Signed-off-by: Yifeng Li <tomli@tomli.me>
Signed-off-by: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@vger.kernel.org
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: Huacai Chen <chenhc@lemote.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # v3.19+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Mon, 11 Mar 2019 14:04:18 +0000 (15:04 +0100)]
udf: Fix crash on IO error during truncate
commit
d3ca4651d05c0ff7259d087d8c949bcf3e14fb46 upstream.
When truncate(2) hits IO error when reading indirect extent block the
code just bugs with:
kernel BUG at linux-4.15.0/fs/udf/truncate.c:249!
...
Fix the problem by bailing out cleanly in case of IO error.
CC: stable@vger.kernel.org
Reported-by: jean-luc malet <jeanluc.malet@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ilya Dryomov [Wed, 20 Mar 2019 08:46:58 +0000 (09:46 +0100)]
libceph: wait for latest osdmap in ceph_monc_blacklist_add()
commit
bb229bbb3bf63d23128e851a1f3b85c083178fa1 upstream.
Because map updates are distributed lazily, an OSD may not know about
the new blacklist for quite some time after "osd blacklist add" command
is completed. This makes it possible for a blacklisted but still alive
client to overwrite a post-blacklist update, resulting in data
corruption.
Waiting for latest osdmap in ceph_monc_blacklist_add() and thus using
the post-blacklist epoch for all post-blacklist requests ensures that
all such requests "wait" for the blacklist to come into force on their
respective OSDs.
Cc: stable@vger.kernel.org
Fixes:
6305a3b41515 ("libceph: support for blacklisting clients")
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Jason Dillaman <dillaman@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stanislaw Gruszka [Wed, 13 Mar 2019 09:03:17 +0000 (10:03 +0100)]
iommu/amd: fix sg->dma_address for sg->offset bigger than PAGE_SIZE
commit
4e50ce03976fbc8ae995a000c4b10c737467beaa upstream.
Take into account that sg->offset can be bigger than PAGE_SIZE when
setting segment sg->dma_address. Otherwise sg->dma_address will point
at diffrent page, what makes DMA not possible with erros like this:
xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa70c0 flags=0x0020]
xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7040 flags=0x0020]
xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7080 flags=0x0020]
xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7100 flags=0x0020]
xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7000 flags=0x0020]
Additinally with wrong sg->dma_address unmap_sg will free wrong pages,
what what can cause crashes like this:
Feb 28 19:27:45 kernel: BUG: Bad page state in process cinnamon pfn:39e8b1
Feb 28 19:27:45 kernel: Disabling lock debugging due to kernel taint
Feb 28 19:27:45 kernel: flags: 0x2ffff0000000000()
Feb 28 19:27:45 kernel: raw:
02ffff0000000000 0000000000000000 ffffffff00000301 0000000000000000
Feb 28 19:27:45 kernel: raw:
0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
Feb 28 19:27:45 kernel: page dumped because: nonzero _refcount
Feb 28 19:27:45 kernel: Modules linked in: ccm fuse arc4 nct6775 hwmon_vid amdgpu nls_iso8859_1 nls_cp437 edac_mce_amd vfat fat kvm_amd ccp rng_core kvm mt76x0u mt76x0_common mt76x02_usb irqbypass mt76_usb mt76x02_lib mt76 crct10dif_pclmul crc32_pclmul chash mac80211 amd_iommu_v2 ghash_clmulni_intel gpu_sched i2c_algo_bit ttm wmi_bmof snd_hda_codec_realtek snd_hda_codec_generic drm_kms_helper snd_hda_codec_hdmi snd_hda_intel drm snd_hda_codec aesni_intel snd_hda_core snd_hwdep aes_x86_64 crypto_simd snd_pcm cfg80211 cryptd mousedev snd_timer glue_helper pcspkr r8169 input_leds realtek agpgart libphy rfkill snd syscopyarea sysfillrect sysimgblt fb_sys_fops soundcore sp5100_tco k10temp i2c_piix4 wmi evdev gpio_amdpt pinctrl_amd mac_hid pcc_cpufreq acpi_cpufreq sg ip_tables x_tables ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) fscrypto(E) sd_mod(E) hid_generic(E) usbhid(E) hid(E) dm_mod(E) serio_raw(E) atkbd(E) libps2(E) crc32c_intel(E) ahci(E) libahci(E) libata(E) xhci_pci(E) xhci_hcd(E)
Feb 28 19:27:45 kernel: scsi_mod(E) i8042(E) serio(E) bcache(E) crc64(E)
Feb 28 19:27:45 kernel: CPU: 2 PID: 896 Comm: cinnamon Tainted: G B W E 4.20.12-arch1-1-custom #1
Feb 28 19:27:45 kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450M Pro4, BIOS P1.20 06/26/2018
Feb 28 19:27:45 kernel: Call Trace:
Feb 28 19:27:45 kernel: dump_stack+0x5c/0x80
Feb 28 19:27:45 kernel: bad_page.cold.29+0x7f/0xb2
Feb 28 19:27:45 kernel: __free_pages_ok+0x2c0/0x2d0
Feb 28 19:27:45 kernel: skb_release_data+0x96/0x180
Feb 28 19:27:45 kernel: __kfree_skb+0xe/0x20
Feb 28 19:27:45 kernel: tcp_recvmsg+0x894/0xc60
Feb 28 19:27:45 kernel: ? reuse_swap_page+0x120/0x340
Feb 28 19:27:45 kernel: ? ptep_set_access_flags+0x23/0x30
Feb 28 19:27:45 kernel: inet_recvmsg+0x5b/0x100
Feb 28 19:27:45 kernel: __sys_recvfrom+0xc3/0x180
Feb 28 19:27:45 kernel: ? handle_mm_fault+0x10a/0x250
Feb 28 19:27:45 kernel: ? syscall_trace_enter+0x1d3/0x2d0
Feb 28 19:27:45 kernel: ? __audit_syscall_exit+0x22a/0x290
Feb 28 19:27:45 kernel: __x64_sys_recvfrom+0x24/0x30
Feb 28 19:27:45 kernel: do_syscall_64+0x5b/0x170
Feb 28 19:27:45 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
Cc: stable@vger.kernel.org
Reported-and-tested-by: Jan Viktorin <jan.viktorin@gmail.com>
Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Fixes:
80187fd39dcb ('iommu/amd: Optimize map_sg and unmap_sg')
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Zimmermann [Mon, 18 Mar 2019 14:47:58 +0000 (15:47 +0100)]
drm/vmwgfx: Don't double-free the mode stored in par->set_mode
commit
c2d311553855395764e2e5bf401d987ba65c2056 upstream.
When calling vmw_fb_set_par(), the mode stored in par->set_mode gets free'd
twice. The first free is in vmw_fb_kms_detach(), the second is near the
end of vmw_fb_set_par() under the name of 'old_mode'. The mode-setting code
only works correctly if the mode doesn't actually change. Removing
'old_mode' in favor of using par->set_mode directly fixes the problem.
Cc: <stable@vger.kernel.org>
Fixes:
a278724aa23c ("drm/vmwgfx: Implement fbdev on kms v2")
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Thu, 7 Mar 2019 10:09:19 +0000 (11:09 +0100)]
mmc: pxamci: fix enum type confusion
commit
e60a582bcde01158a64ff948fb799f21f5d31a11 upstream.
clang points out several instances of mismatched types in this drivers,
all coming from a single declaration:
drivers/mmc/host/pxamci.c:193:15: error: implicit conversion from enumeration type 'enum dma_transfer_direction' to
different enumeration type 'enum dma_data_direction' [-Werror,-Wenum-conversion]
direction = DMA_DEV_TO_MEM;
~ ^~~~~~~~~~~~~~
drivers/mmc/host/pxamci.c:212:62: error: implicit conversion from enumeration type 'enum dma_data_direction' to
different enumeration type 'enum dma_transfer_direction' [-Werror,-Wenum-conversion]
tx = dmaengine_prep_slave_sg(chan, data->sg, host->dma_len, direction,
The behavior is correct, so this must be a simply typo from
dma_data_direction and dma_transfer_direction being similarly named
types with a similar purpose.
Fixes:
6464b7140951 ("mmc: pxamci: switch over to dmaengine use")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Lawrence [Tue, 26 Mar 2019 16:05:55 +0000 (09:05 -0700)]
ANDROID: dm-bow: Fix 32 bit compile errors
See https://www.kernel.org/doc/html/v4.17/core-api/printk-formats.html
Also 64-bit modulus not defined on 32-bit architectures
Test: i386_defconfig and x86_64_cuttlefish_defconfig compile
Change-Id: I57b9372e12e97b9a18232191b525e7601bc57a24
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Paul Lawrence [Thu, 21 Mar 2019 20:23:03 +0000 (13:23 -0700)]
ANDROID: Add dm-bow to cuttlefish configuration
Change-Id: I7f265cb8c6274da414d2477da9953546510ce26b
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Todd Kjos [Thu, 14 Feb 2019 23:22:57 +0000 (15:22 -0800)]
UPSTREAM: binder: fix handling of misaligned binder object
Fixes crash found by syzbot:
kernel BUG at drivers/android/binder_alloc.c:LINE! (2)
(cherry pick from commit
26528be6720bb40bc8844e97ee73a37e530e9c5e)
Bug:
67668716
Reported-and-tested-by: syzbot+55de1eb4975dec156d8f@syzkaller.appspotmail.com
Signed-off-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: Ib8597dd05a158f78503d4affe6c5f46ded16a811
Todd Kjos [Wed, 13 Feb 2019 19:48:53 +0000 (11:48 -0800)]
UPSTREAM: binder: fix sparse issue in binder_alloc_selftest.c
Fixes sparse issues reported by the kbuild test robot running
on https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
char-misc-testing:
bde4a19fc04f5 ("binder: use userspace pointer as base
of buffer space")
Error output (drivers/android/binder_alloc_selftest.c):
sparse: warning: incorrect type in assignment (different address spaces)
sparse: expected void *page_addr
sparse: got void [noderef] <asn:1> *user_data
sparse: error: subtraction of different types can't work
Fixed by adding necessary "__user" tags.
(cherry pick from commit
36f30937922ce75390c73f99e650e4f2eb56b0e6)
Bug:
67668716
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: Ia0a16d163251381d4bc04f46a44dddbc18b10a85
Todd Kjos [Fri, 8 Feb 2019 18:35:20 +0000 (10:35 -0800)]
BACKPORT: binder: use userspace pointer as base of buffer space
Now that alloc->buffer points to the userspace vm_area
rename buffer->data to buffer->user_data and rename
local pointers that hold user addresses. Also use the
"__user" tag to annotate all user pointers so sparse
can flag cases where user pointer vaues are copied to
kernel pointers. Refactor code to use offsets instead
of user pointers.
(cherry pick from commit
bde4a19fc04f5f46298c86b1acb7a4af1d5f138d)
Bug:
67668716
Change-Id: I9d04b844c5994d1f6214da795799e6b373bc9816
Signed-off-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Todd Kjos [Wed, 5 Dec 2018 23:19:25 +0000 (15:19 -0800)]
UPSTREAM: binder: fix kerneldoc header for struct binder_buffer
Fix the incomplete kerneldoc header for struct binder_buffer.
(cherry pick from commit
7a2670a5bc917e4e7c9be5274efc004f9bd1216a)
Bug:
67668716
Signed-off-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I6bb942e6a9466b02653349943524462f205af839
Todd Kjos [Fri, 8 Feb 2019 18:35:19 +0000 (10:35 -0800)]
BACKPORT: binder: remove user_buffer_offset
Remove user_buffer_offset since there is no kernel
buffer pointer anymore.
(cherry pick from commit
c41358a5f5217abd7c051e8d42397e5b80f3b3ed)
Bug:
67668716
Signed-off-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I399219867704dc5013453a7738193c742fc970ad
Todd Kjos [Fri, 8 Feb 2019 18:35:18 +0000 (10:35 -0800)]
UPSTREAM: binder: remove kernel vm_area for buffer space
Remove the kernel's vm_area and the code that maps
buffer pages into it.
(cherry pick from commit
880211667b203dd32724f3be224c44c0400aa0a6)
Bug:
67668716
Signed-off-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I2595bb8416c2bbfcf97ad3d7380ae94e29c209fb
Todd Kjos [Fri, 8 Feb 2019 18:35:17 +0000 (10:35 -0800)]
UPSTREAM: binder: avoid kernel vm_area for buffer fixups
Refactor the functions to validate and fixup struct
binder_buffer pointer objects to avoid using vm_area
pointers. Instead copy to/from kernel space using
binder_alloc_copy_to_buffer() and
binder_alloc_copy_from_buffer(). The following
functions were refactored:
refactor binder_validate_ptr()
binder_validate_fixup()
binder_fixup_parent()
(cherry pick from commit
db6b0b810bf945d1991917ffce0e93383101f2fa)
Bug:
67668716
Signed-off-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: Ic222af9b6c56bf48fd0b65debe981d19a7809e77
Todd Kjos [Fri, 8 Feb 2019 18:35:16 +0000 (10:35 -0800)]
BACKPORT: binder: add function to copy binder object from buffer
When creating or tearing down a transaction, the binder driver
examines objects in the buffer and takes appropriate action.
To do this without needing to dereference pointers into the
buffer, the local copies of the objects are needed. This patch
introduces a function to validate and copy binder objects
from the buffer to a local structure.
(cherry pick from commit
7a67a39320dfba4b36d3be5dae4581194e650316)
Bug:
67668716
Signed-off-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I42dfe238a2d20bdeff479068ca87a80e4577e64a
Todd Kjos [Fri, 8 Feb 2019 18:35:15 +0000 (10:35 -0800)]
BACKPORT: binder: add functions to copy to/from binder buffers
Avoid vm_area when copying to or from binder buffers.
Instead, new copy functions are added that copy from
kernel space to binder buffer space. These use
kmap_atomic() and kunmap_atomic() to create temporary
mappings and then memcpy() is used to copy within
that page.
Also, kmap_atomic() / kunmap_atomic() use the appropriate
cache flushing to support VIVT cache architectures.
Allow binder to build if CPU_CACHE_VIVT is defined.
Several uses of the new functions are added here. More
to follow in subsequent patches.
(cherry picked from commit
8ced0c6231ead26eca8cb416dcb7cc1c2cdd41d8)
Bug:
67668716
Change-Id: I6a93d2396d0a80c352a1d563fc7fb523a753e38c
Signed-off-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Todd Kjos [Fri, 8 Feb 2019 18:35:14 +0000 (10:35 -0800)]
UPSTREAM: binder: create userspace-to-binder-buffer copy function
The binder driver uses a vm_area to map the per-process
binder buffer space. For 32-bit android devices, this is
now taking too much vmalloc space. This patch removes
the use of vm_area when copying the transaction data
from the sender to the buffer space. Instead of using
copy_from_user() for multi-page copies, it now uses
binder_alloc_copy_user_to_buffer() which uses kmap()
and kunmap() to map each page, and uses copy_from_user()
for copying to that page.
(cherry picked from
1a7c3d9bb7a926e88d5f57643e75ad1abfc55013)
Bug:
67668716
Signed-off-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I59ff83455984fce4626476e30601ed8b99858a92
Paul Lawrence [Fri, 22 Mar 2019 15:25:28 +0000 (08:25 -0700)]
ANDROID: dm-bow: backport to 4.14
Change-Id: Ib89b91adaa11b84744de9167bda57ff0056f4415
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Paul Lawrence [Tue, 23 Oct 2018 15:56:04 +0000 (08:56 -0700)]
ANDROID: dm-bow: Add dm-bow feature
Based on https://www.redhat.com/archives/dm-devel/2019-March/msg00025.html
Third version of dm-bow. Key changes:
Free list added
Support for block sizes other than 4k
Handles writes during trim phase, and overlapping trims
Integer overflow error
Support trims even if underlying device doesn't
Numerous small bug fixes
bow == backup on write
USE CASE:
dm-bow takes a snapshot of an existing file system before mounting.
The user may, before removing the device, commit the snapshot.
Alternatively the user may remove the device and then run a command
line utility to restore the device to its original state.
dm-bow does not require an external device
dm-bow efficiently uses all the available free space on the file system.
IMPLEMENTATION:
dm-bow can be in one of three states.
In state one, the free blocks on the device are identified by issuing
an FSTRIM to the filesystem.
In state two, any writes cause the overwritten data to be backup up
to the available free space. While in this state, the device can be
restored by unmounting the filesystem, removing the dm-bow device
and running a usermode tool over the underlying device.
In state three, the changes are committed, dm-bow is in pass-through
mode and the drive can no longer be restored.
It is planned to use this driver to enable restoration of a failed
update attempt on Android devices using ext4.
Test: Can boot Android with userdata mounted on this device. Can commit
userdata after SUW has run. Can then reboot, make changes and roll back.
Known issues:
Mutex is held around entire flush operation, including lengthy I/O. Plan
is to convert to state machine with pending queues.
Interaction with block encryption is unknown, especially with respect
to sector 0.
Bug:
119769411
Change-Id: Id70988bbd797ebe3e76fc175094388b423c8da8c
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Greg Kroah-Hartman [Sat, 23 Mar 2019 20:12:16 +0000 (21:12 +0100)]
Merge 4.14.108 into android-4.14
Changes in 4.14.108
9p: use inode->i_lock to protect i_size_write() under 32-bit
9p/net: fix memory leak in p9_client_create
ASoC: fsl_esai: fix register setting issue in RIGHT_J mode
iio: adc: exynos-adc: Fix NULL pointer exception on unbind
stm class: Fix an endless loop in channel allocation
crypto: caam - fixed handling of sg list
crypto: ahash - fix another early termination in hash walk
crypto: rockchip - fix scatterlist nents error
crypto: rockchip - update new iv to device in multiple operations
drm/imx: ignore plane updates on disabled crtcs
gpu: ipu-v3: Fix i.MX51 CSI control registers offset
drm/imx: imx-ldb: add missing of_node_puts
gpu: ipu-v3: Fix CSI offsets for imx53
s390/dasd: fix using offset into zero size array error
Input: pwm-vibra - prevent unbalanced regulator
Input: pwm-vibra - stop regulator after disabling pwm, not before
ARM: OMAP2+: Variable "reg" in function omap4_dsi_mux_pads() could be uninitialized
ASoC: dapm: fix out-of-bounds accesses to DAPM lookup tables
ASoC: rsnd: fixup rsnd_ssi_master_clk_start() user count check
KVM: arm/arm64: Reset the VCPU without preemption and vcpu state loaded
ARM: OMAP2+: fix lack of timer interrupts on CPU1 after hotplug
Input: cap11xx - switch to using set_brightness_blocking()
Input: ps2-gpio - flush TX work when closing port
Input: matrix_keypad - use flush_delayed_work()
mac80211: Fix Tx aggregation session tear down with ITXQs
ipvs: fix dependency on nf_defrag_ipv6
floppy: check_events callback should not return a negative number
NFS: Don't use page_file_mapping after removing the page
mm/gup: fix gup_pmd_range() for dax
Revert "mm: use early_pfn_to_nid in page_ext_init"
mm: page_alloc: fix ref bias in page_frag_alloc() for 1-byte allocs
net: hns: Fix object reference leaks in hns_dsaf_roce_reset()
i2c: cadence: Fix the hold bit setting
i2c: bcm2835: Clear current buffer pointers and counts after a transfer
auxdisplay: ht16k33: fix potential user-after-free on module unload
Input: st-keyscan - fix potential zalloc NULL dereference
clk: sunxi-ng: v3s: Fix TCON reset de-assert bit
clk: sunxi: A31: Fix wrong AHB gate number
esp: Skip TX bytes accounting when sending from a request socket
ARM: 8824/1: fix a migrating irq bug when hotplug cpu
af_key: unconditionally clone on broadcast
assoc_array: Fix shortcut creation
keys: Fix dependency loop between construction record and auth key
scsi: libiscsi: Fix race between iscsi_xmit_task and iscsi_complete_task
net: systemport: Fix reception of BPDUs
pinctrl: meson: meson8b: fix the sdxc_a data 1..3 pins
qmi_wwan: apply SET_DTR quirk to Sierra WP7607
net: mv643xx_eth: disable clk on error path in mv643xx_eth_shared_probe()
mailbox: bcm-flexrm-mailbox: Fix FlexRM ring flush timeout issue
ASoC: topology: free created components in tplg load error
qed: Fix iWARP syn packet mac address validation.
arm64: Relax GIC version check during early boot
net: marvell: mvneta: fix DMA debug warning
tmpfs: fix link accounting when a tmpfile is linked in
ixgbe: fix older devices that do not support IXGBE_MRQC_L3L4TXSWEN
ARCv2: lib: memcpy: fix doing prefetchw outside of buffer
ARC: uacces: remove lp_start, lp_end from clobber list
ARCv2: support manual regfile save on interrupts
phonet: fix building with clang
mac80211_hwsim: propagate genlmsg_reply return code
net: thunderx: make CFG_DONE message to run through generic send-ack sequence
nfp: bpf: fix code-gen bug on BPF_ALU | BPF_XOR | BPF_K
nfp: bpf: fix ALU32 high bits clearance bug
net: set static variable an initial value in atl2_probe()
tmpfs: fix uninitialized return value in shmem_link
media: videobuf2-v4l2: drop WARN_ON in vb2_warn_zero_bytesused()
stm class: Prevent division by zero
libnvdimm/label: Clear 'updating' flag after label-set update
libnvdimm, pfn: Fix over-trim in trim_pfn_device()
libnvdimm/pmem: Honor force_raw for legacy pmem regions
libnvdimm: Fix altmap reservation size calculation
fix cgroup_do_mount() handling of failure exits
crypto: arm/crct10dif - revert to C code for short inputs
crypto: arm64/crct10dif - revert to C code for short inputs
crypto: hash - set CRYPTO_TFM_NEED_KEY if ->setkey() fails
crypto: testmgr - skip crc32c context test for ahash algorithms
crypto: arm64/aes-ccm - fix logical bug in AAD MAC handling
crypto: arm64/aes-ccm - fix bugs in non-NEON fallback routine
CIFS: Do not reset lease state to NONE on lease break
CIFS: Fix read after write for files with read caching
tracing: Use strncpy instead of memcpy for string keys in hist triggers
tracing: Do not free iter->trace in fail path of tracing_open_pipe()
xen: fix dom0 boot on huge systems
ACPI / device_sysfs: Avoid OF modalias creation for removed device
mmc: sdhci-esdhc-imx: fix HS400 timing issue
spi: ti-qspi: Fix mmap read when more than one CS in use
spi: pxa2xx: Setup maximum supported DMA transfer length
regulator: s2mps11: Fix steps for buck7, buck8 and LDO35
regulator: max77620: Initialize values for DT properties
regulator: s2mpa01: Fix step values for some LDOs
clocksource/drivers/exynos_mct: Move one-shot check from tick clear to ISR
clocksource/drivers/exynos_mct: Clear timer interrupt when shutdown
s390/setup: fix early warning messages
s390/virtio: handle find on invalid queue gracefully
scsi: virtio_scsi: don't send sc payload with tmfs
scsi: aacraid: Fix performance issue on logical drives
scsi: sd: Optimal I/O size should be a multiple of physical block size
scsi: target/iscsi: Avoid iscsit_release_commands_from_conn() deadlock
fs/devpts: always delete dcache dentry-s in dput()
splice: don't merge into linked buffers
m68k: Add -ffreestanding to CFLAGS
Btrfs: setup a nofs context for memory allocation at __btrfs_set_acl
btrfs: ensure that a DUP or RAID1 block group has exactly two stripes
Btrfs: fix corruption reading shared and compressed extents after hole punching
crypto: pcbc - remove bogus memcpy()s with src == dest
libertas_tf: don't set URB_ZERO_PACKET on IN USB transfer
irqchip/gic-v3-its: Avoid parsing _indirect_ twice for Device table
x86/kprobes: Prohibit probing on optprobe template code
cpufreq: tegra124: add missing of_node_put()
cpufreq: pxa2xx: remove incorrect __init annotation
ext4: add mask of ext4 flags to swap
ext4: fix crash during online resizing
IB/hfi1: Close race condition on user context disable and close
cxl: Wrap iterations over afu slices inside 'afu_list_lock'
ext2: Fix underflow in ext2_max_size()
clk: uniphier: Fix update register for CPU-gear
clk: clk-twl6040: Fix imprecise external abort for pdmclk
clk: ingenic: Fix round_rate misbehaving with non-integer dividers
clk: ingenic: Fix doc of ingenic_cgu_div_info
usb: chipidea: tegra: Fix missed ci_hdrc_remove_device()
nfit: acpi_nfit_ctl(): Check out_obj->type in the right place
mm: hwpoison: fix thp split handing in soft_offline_in_use_page()
mm/vmalloc: fix size check for remap_vmalloc_range_partial()
kernel/sysctl.c: add missing range check in do_proc_dointvec_minmax_conv
device property: Fix the length used in PROPERTY_ENTRY_STRING()
intel_th: Don't reference unassigned outputs
parport_pc: fix find_superio io compare code, should use equal test.
i2c: tegra: fix maximum transfer size
crypto: arm64/aes-neonbs - fix returning final keystream block
drm/i915: Relax mmap VMA check
serial: uartps: Fix stuck ISR if RX disabled with non-empty FIFO
serial: 8250_of: assume reg-shift of 2 for mrvl,mmp-uart
serial: 8250_pci: Fix number of ports for ACCES serial cards
serial: 8250_pci: Have ACCES cards that use the four port Pericom PI7C9X7954 chip use the pci_pericom_setup()
jbd2: clear dirty flag when revoking a buffer from an older transaction
jbd2: fix compile warning when using JBUFFER_TRACE
security/selinux: fix SECURITY_LSM_NATIVE_LABELS on reused superblock
powerpc/32: Clear on-stack exception marker upon exception return
powerpc/wii: properly disable use of BATs when requested.
powerpc/powernv: Make opal log only readable by root
powerpc/83xx: Also save/restore SPRG4-7 during suspend
powerpc: Fix 32-bit KVM-PR lockup and host crash with MacOS guest
powerpc/ptrace: Simplify vr_get/set() to avoid GCC warning
powerpc/hugetlb: Don't do runtime allocation of 16G pages in LPAR configuration
powerpc/traps: fix recoverability of machine check handling on book3s/32
powerpc/traps: Fix the message printed when stack overflows
ARM: s3c24xx: Fix boolean expressions in osiris_dvs_notify
arm64: Fix HCR.TGE status for NMI contexts
arm64: debug: Ensure debug handlers check triggering exception level
arm64: KVM: Fix architecturally invalid reset value for FPEXC32_EL2
dm: fix to_sector() for 32bit
dm integrity: limit the rate of error messages
cpcap-charger: generate events for userspace
NFS: Fix I/O request leakages
NFS: Fix an I/O request leakage in nfs_do_recoalesce
NFS: Don't recoalesce on error in nfs_pageio_complete_mirror()
nfsd: fix memory corruption caused by readdir
nfsd: fix wrong check in write_v4_end_grace()
NFSv4.1: Reinitialise sequence results before retransmitting a request
PM / wakeup: Rework wakeup source timer cancellation
bcache: never writeback a discard operation
x86/unwind/orc: Fix ORC unwind table alignment
perf intel-pt: Fix CYC timestamp calculation after OVF
perf auxtrace: Define auxtrace record alignment
perf intel-pt: Fix overlap calculation for padding
perf intel-pt: Fix divide by zero when TSC is not available
md: Fix failed allocation of md_register_thread
tpm/tpm_crb: Avoid unaligned reads in crb_recv()
tpm: Unify the send callback behaviour
rcu: Do RCU GP kthread self-wakeup from softirq and interrupt
media: imx: prpencvf: Stop upstream before disabling IDMA channel
media: uvcvideo: Avoid NULL pointer dereference at the end of streaming
media: vimc: Add vimc-streamer for stream control
media: imx: csi: Disable CSI immediately after last EOF
media: imx: csi: Stop upstream before disabling IDMA channel
drm/radeon/evergreen_cs: fix missing break in switch statement
KVM: Call kvm_arch_memslots_updated() before updating memslots
KVM: x86/mmu: Detect MMIO generation wrap in any address space
KVM: x86/mmu: Do not cache MMIO accesses while memslots are in flux
KVM: nVMX: Sign extend displacements of VMX instr's mem operands
KVM: nVMX: Apply addr size mask to effective address for VMX instructions
KVM: nVMX: Ignore limit checks on VMX instructions using flat segments
s390/setup: fix boot crash for machine without EDAT-1
Linux 4.14.108
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Greg Kroah-Hartman [Sat, 23 Mar 2019 13:35:32 +0000 (14:35 +0100)]
Linux 4.14.108
Martin Schwidefsky [Mon, 18 Feb 2019 17:10:08 +0000 (18:10 +0100)]
s390/setup: fix boot crash for machine without EDAT-1
commit
86a86804e4f18fc3880541b3d5a07f4df0fe29cb upstream.
The fix to make WARN work in the early boot code created a problem
on older machines without EDAT-1. The setup_lowcore_dat_on function
uses the pointer from lowcore_ptr[0] to set the DAT bit in the new
PSWs. That does not work if the kernel page table is set up with
4K pages as the prefix address maps to absolute zero.
To make this work the PSWs need to be changed with via address 0 in
form of the S390_lowcore definition.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Cornelia Huck <cohuck@redhat.com>
Fixes:
94f85ed3e2f8 ("s390/setup: fix early warning messages")
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sean Christopherson [Wed, 23 Jan 2019 22:39:25 +0000 (14:39 -0800)]
KVM: nVMX: Ignore limit checks on VMX instructions using flat segments
commit
34333cc6c2cb021662fd32e24e618d1b86de95bf upstream.
Regarding segments with a limit==0xffffffff, the SDM officially states:
When the effective limit is FFFFFFFFH (4 GBytes), these accesses may
or may not cause the indicated exceptions. Behavior is
implementation-specific and may vary from one execution to another.
In practice, all CPUs that support VMX ignore limit checks for "flat
segments", i.e. an expand-up data or code segment with base=0 and
limit=0xffffffff. This is subtly different than wrapping the effective
address calculation based on the address size, as the flat segment
behavior also applies to accesses that would wrap the 4g boundary, e.g.
a 4-byte access starting at 0xffffffff will access linear addresses
0xffffffff, 0x0, 0x1 and 0x2.
Fixes:
f9eb4af67c9d ("KVM: nVMX: VMX instructions: add checks for #GP/#SS exceptions")
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sean Christopherson [Wed, 23 Jan 2019 22:39:24 +0000 (14:39 -0800)]
KVM: nVMX: Apply addr size mask to effective address for VMX instructions
commit
8570f9e881e3fde98801bb3a47eef84dd934d405 upstream.
The address size of an instruction affects the effective address, not
the virtual/linear address. The final address may still be truncated,
e.g. to 32-bits outside of long mode, but that happens irrespective of
the address size, e.g. a 32-bit address size can yield a 64-bit virtual
address when using FS/GS with a non-zero base.
Fixes:
064aea774768 ("KVM: nVMX: Decoding memory operands of VMX instructions")
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sean Christopherson [Wed, 23 Jan 2019 22:39:23 +0000 (14:39 -0800)]
KVM: nVMX: Sign extend displacements of VMX instr's mem operands
commit
946c522b603f281195af1df91837a1d4d1eb3bc9 upstream.
The VMCS.EXIT_QUALIFCATION field reports the displacements of memory
operands for various instructions, including VMX instructions, as a
naturally sized unsigned value, but masks the value by the addr size,
e.g. given a ModRM encoded as -0x28(%ebp), the -0x28 displacement is
reported as 0xffffffd8 for a 32-bit address size. Despite some weird
wording regarding sign extension, the SDM explicitly states that bits
beyond the instructions address size are undefined:
In all cases, bits of this field beyond the instruction’s address
size are undefined.
Failure to sign extend the displacement results in KVM incorrectly
treating a negative displacement as a large positive displacement when
the address size of the VMX instruction is smaller than KVM's native
size, e.g. a 32-bit address size on a 64-bit KVM.
The very original decoding, added by commit
064aea774768 ("KVM: nVMX:
Decoding memory operands of VMX instructions"), sort of modeled sign
extension by truncating the final virtual/linear address for a 32-bit
address size. I.e. it messed up the effective address but made it work
by adjusting the final address.
When segmentation checks were added, the truncation logic was kept
as-is and no sign extension logic was introduced. In other words, it
kept calculating the wrong effective address while mostly generating
the correct virtual/linear address. As the effective address is what's
used in the segment limit checks, this results in KVM incorreclty
injecting #GP/#SS faults due to non-existent segment violations when
a nested VMM uses negative displacements with an address size smaller
than KVM's native address size.
Using the -0x28(%ebp) example, an EBP value of 0x1000 will result in
KVM using 0x100000fd8 as the effective address when checking for a
segment limit violation. This causes a 100% failure rate when running
a 32-bit KVM build as L1 on top of a 64-bit KVM L0.
Fixes:
f9eb4af67c9d ("KVM: nVMX: VMX instructions: add checks for #GP/#SS exceptions")
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sean Christopherson [Tue, 5 Feb 2019 21:01:13 +0000 (13:01 -0800)]
KVM: x86/mmu: Do not cache MMIO accesses while memslots are in flux
commit
ddfd1730fd829743e41213e32ccc8b4aa6dc8325 upstream.
When installing new memslots, KVM sets bit 0 of the generation number to
indicate that an update is in-progress. Until the update is complete,
there are no guarantees as to whether a vCPU will see the old or the new
memslots. Explicity prevent caching MMIO accesses so as to avoid using
an access cached from the old memslots after the new memslots have been
installed.
Note that it is unclear whether or not disabling caching during the
update window is strictly necessary as there is no definitive
documentation as to what ordering guarantees KVM provides with respect
to updating memslots. That being said, the MMIO spte code does not
allow reusing sptes created while an update is in-progress, and the
associated documentation explicitly states:
We do not want to use an MMIO sptes created with an odd generation
number, ... If KVM is unlucky and creates an MMIO spte while the
low bit is 1, the next access to the spte will always be a cache miss.
At the very least, disabling the per-vCPU MMIO cache during updates will
make its behavior consistent with the MMIO spte behavior and
documentation.
Fixes:
56f17dd3fbc4 ("kvm: x86: fix stale mmio cache bug")
Cc: <stable@vger.kernel.org>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sean Christopherson [Tue, 5 Feb 2019 21:01:12 +0000 (13:01 -0800)]
KVM: x86/mmu: Detect MMIO generation wrap in any address space
commit
e1359e2beb8b0a1188abc997273acbaedc8ee791 upstream.
The check to detect a wrap of the MMIO generation explicitly looks for a
generation number of zero. Now that unique memslots generation numbers
are assigned to each address space, only address space 0 will get a
generation number of exactly zero when wrapping. E.g. when address
space 1 goes from 0x7fffe to 0x80002, the MMIO generation number will
wrap to 0x2. Adjust the MMIO generation to strip the address space
modifier prior to checking for a wrap.
Fixes:
4bd518f1598d ("KVM: use separate generations for each address space")
Cc: <stable@vger.kernel.org>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sean Christopherson [Tue, 5 Feb 2019 20:54:17 +0000 (12:54 -0800)]
KVM: Call kvm_arch_memslots_updated() before updating memslots
commit
152482580a1b0accb60676063a1ac57b2d12daf6 upstream.
kvm_arch_memslots_updated() is at this point in time an x86-specific
hook for handling MMIO generation wraparound. x86 stashes 19 bits of
the memslots generation number in its MMIO sptes in order to avoid
full page fault walks for repeat faults on emulated MMIO addresses.
Because only 19 bits are used, wrapping the MMIO generation number is
possible, if unlikely. kvm_arch_memslots_updated() alerts x86 that
the generation has changed so that it can invalidate all MMIO sptes in
case the effective MMIO generation has wrapped so as to avoid using a
stale spte, e.g. a (very) old spte that was created with generation==0.
Given that the purpose of kvm_arch_memslots_updated() is to prevent
consuming stale entries, it needs to be called before the new generation
is propagated to memslots. Invalidating the MMIO sptes after updating
memslots means that there is a window where a vCPU could dereference
the new memslots generation, e.g. 0, and incorrectly reuse an old MMIO
spte that was created with (pre-wrap) generation==0.
Fixes:
e59dbe09f8e6 ("KVM: Introduce kvm_arch_memslots_updated()")
Cc: <stable@vger.kernel.org>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gustavo A. R. Silva [Fri, 15 Feb 2019 20:29:26 +0000 (14:29 -0600)]
drm/radeon/evergreen_cs: fix missing break in switch statement
commit
cc5034a5d293dd620484d1d836aa16c6764a1c8c upstream.
Add missing break statement in order to prevent the code from falling
through to case CB_TARGET_MASK.
This bug was found thanks to the ongoing efforts to enable
-Wimplicit-fallthrough.
Fixes:
dd220a00e8bd ("drm/radeon/kms: add support for streamout v7")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steve Longerbeam [Mon, 21 Jan 2019 23:35:51 +0000 (21:35 -0200)]
media: imx: csi: Stop upstream before disabling IDMA channel
commit
4bc1ab41eee9d02ad2483bf8f51a7b72e3504eba upstream.
Move upstream stream off to just after receiving the last EOF completion
and disabling the CSI (and thus before disabling the IDMA channel) in
csi_stop(). For symmetry also move upstream stream on to beginning of
csi_start().
Doing this makes csi_s_stream() more symmetric with prp_s_stream() which
will require the same change to fix a hard lockup.
Signed-off-by: Steve Longerbeam <slongerbeam@gmail.com>
Cc: stable@vger.kernel.org # for 4.13 and up
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steve Longerbeam [Mon, 21 Jan 2019 23:35:50 +0000 (21:35 -0200)]
media: imx: csi: Disable CSI immediately after last EOF
commit
2e0fe66e0a136252f4d89dbbccdcb26deb867eb8 upstream.
Disable the CSI immediately after receiving the last EOF before stream
off (and thus before disabling the IDMA channel). Do this by moving the
wait for EOF completion into a new function csi_idmac_wait_last_eof().
This fixes a complete system hard lockup on the SabreAuto when streaming
from the ADV7180, by repeatedly sending a stream off immediately followed
by stream on:
while true; do v4l2-ctl -d4 --stream-mmap --stream-count=3; done
Eventually this either causes the system lockup or EOF timeouts at all
subsequent stream on, until a system reset.
The lockup occurs when disabling the IDMA channel at stream off. Disabling
the CSI before disabling the IDMA channel appears to be a reliable fix for
the hard lockup.
Fixes:
4a34ec8e470cb ("[media] media: imx: Add CSI subdev driver")
Reported-by: Gaël PORTAY <gael.portay@collabora.com>
Signed-off-by: Steve Longerbeam <slongerbeam@gmail.com>
Cc: stable@vger.kernel.org # for 4.13 and up
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lucas A. M. Magalhães [Tue, 22 Jan 2019 01:05:01 +0000 (20:05 -0500)]
media: vimc: Add vimc-streamer for stream control
commit
adc589d2a20808fb99d46a78175cd023f2040338 upstream.
Add a linear pipeline logic for the stream control. It's created by
walking backwards on the entity graph. When the stream starts it will
simply loop through the pipeline calling the respective process_frame
function of each entity.
Fixes:
f2fe89061d797 ("vimc: Virtual Media Controller core, capture
and sensor")
Cc: stable@vger.kernel.org # for v4.20
Signed-off-by: Lucas A. M. Magalhães <lucmaga@gmail.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
[hverkuil-cisco@xs4all.nl: fixed small space-after-tab issue in the patch]
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sakari Ailus [Wed, 30 Jan 2019 10:09:41 +0000 (05:09 -0500)]
media: uvcvideo: Avoid NULL pointer dereference at the end of streaming
commit
9dd0627d8d62a7ddb001a75f63942d92b5336561 upstream.
The UVC video driver converts the timestamp from hardware specific unit
to one known by the kernel at the time when the buffer is dequeued. This
is fine in general, but the streamoff operation consists of the
following steps (among other things):
1. uvc_video_clock_cleanup --- the hardware clock sample array is
released and the pointer to the array is set to NULL,
2. buffers in active state are returned to the user and
3. buf_finish callback is called on buffers that are prepared.
buf_finish includes calling uvc_video_clock_update that accesses the
hardware clock sample array.
The above is serialised by a queue specific mutex. Address the problem
by skipping the clock conversion if the hardware clock sample array is
already released.
Fixes:
9c0863b1cc48 ("[media] vb2: call buf_finish from __queue_cancel")
Reported-by: Chiranjeevi Rapolu <chiranjeevi.rapolu@intel.com>
Tested-by: Chiranjeevi Rapolu <chiranjeevi.rapolu@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steve Longerbeam [Mon, 21 Jan 2019 23:35:52 +0000 (21:35 -0200)]
media: imx: prpencvf: Stop upstream before disabling IDMA channel
commit
a19c22677377b87e4354f7306f46ad99bc982a9f upstream.
Upstream must be stopped immediately after receiving the last EOF and
before disabling the IDMA channel. This can be accomplished by moving
upstream stream off to just after receiving the last EOF completion in
prp_stop(). For symmetry also move upstream stream on to end of
prp_start().
This fixes a complete system hard lockup on the SabreAuto when streaming
from the ADV7180, by repeatedly sending a stream off immediately followed
by stream on:
while true; do v4l2-ctl -d1 --stream-mmap --stream-count=3; done
Eventually this either causes the system lockup or EOF timeouts at all
subsequent stream on, until a system reset.
The lockup occurs when disabling the IDMA channel at stream off. Stopping
the video data stream entering the IDMA channel before disabling the
channel itself appears to be a reliable fix for the hard lockup.
Fixes:
f0d9c8924e2c3 ("[media] media: imx: Add IC subdev drivers")
Reported-by: Gaël PORTAY <gael.portay@collabora.com>
Tested-by: Gaël PORTAY <gael.portay@collabora.com>
Signed-off-by: Steve Longerbeam <slongerbeam@gmail.com>
Cc: stable@vger.kernel.org # for 4.13 and up
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zhang, Jun [Tue, 18 Dec 2018 14:55:01 +0000 (06:55 -0800)]
rcu: Do RCU GP kthread self-wakeup from softirq and interrupt
commit
1d1f898df6586c5ea9aeaf349f13089c6fa37903 upstream.
The rcu_gp_kthread_wake() function is invoked when it might be necessary
to wake the RCU grace-period kthread. Because self-wakeups are normally
a useless waste of CPU cycles, if rcu_gp_kthread_wake() is invoked from
this kthread, it naturally refuses to do the wakeup.
Unfortunately, natural though it might be, this heuristic fails when
rcu_gp_kthread_wake() is invoked from an interrupt or softirq handler
that interrupted the grace-period kthread just after the final check of
the wait-event condition but just before the schedule() call. In this
case, a wakeup is required, even though the call to rcu_gp_kthread_wake()
is within the RCU grace-period kthread's context. Failing to provide
this wakeup can result in grace periods failing to start, which in turn
results in out-of-memory conditions.
This race window is quite narrow, but it actually did happen during real
testing. It would of course need to be fixed even if it was strictly
theoretical in nature.
This patch does not Cc stable because it does not apply cleanly to
earlier kernel versions.
Fixes:
48a7639ce80c ("rcu: Make callers awaken grace-period kthread")
Reported-by: "He, Bo" <bo.he@intel.com>
Co-developed-by: "Zhang, Jun" <jun.zhang@intel.com>
Co-developed-by: "He, Bo" <bo.he@intel.com>
Co-developed-by: "xiao, jin" <jin.xiao@intel.com>
Co-developed-by: Bai, Jie A <jie.a.bai@intel.com>
Signed-off: "Zhang, Jun" <jun.zhang@intel.com>
Signed-off: "He, Bo" <bo.he@intel.com>
Signed-off: "xiao, jin" <jin.xiao@intel.com>
Signed-off: Bai, Jie A <jie.a.bai@intel.com>
Signed-off-by: "Zhang, Jun" <jun.zhang@intel.com>
[ paulmck: Switch from !in_softirq() to "!in_interrupt() &&
!in_serving_softirq() to avoid redundant wakeups and to also handle the
interrupt-handler scenario as well as the softirq-handler scenario that
actually occurred in testing. ]
Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
Link: https://lkml.kernel.org/r/CD6925E8781EFD4D8E11882D20FC406D52A11F61@SHSMSX104.ccr.corp.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jarkko Sakkinen [Fri, 8 Feb 2019 16:30:58 +0000 (18:30 +0200)]
tpm: Unify the send callback behaviour
commit
f5595f5baa30e009bf54d0d7653a9a0cc465be60 upstream.
The send() callback should never return length as it does not in every
driver except tpm_crb in the success case. The reason is that the main
transmit functionality only cares about whether the transmit was
successful or not and ignores the count completely.
Suggested-by: Stefan Berger <stefanb@linux.ibm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Tested-by: Alexander Steffen <Alexander.Steffen@infineon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jarkko Sakkinen [Mon, 4 Feb 2019 13:59:43 +0000 (15:59 +0200)]
tpm/tpm_crb: Avoid unaligned reads in crb_recv()
commit
3d7a850fdc1a2e4d2adbc95cc0fc962974725e88 upstream.
The current approach to read first 6 bytes from the response and then tail
of the response, can cause the 2nd memcpy_fromio() to do an unaligned read
(e.g. read 32-bit word from address aligned to a 16-bits), depending on how
memcpy_fromio() is implemented. If this happens, the read will fail and the
memory controller will fill the read with 1's.
This was triggered by
170d13ca3a2f, which should be probably refined to
check and react to the address alignment. Before that commit, on x86
memcpy_fromio() turned out to be memcpy(). By a luck GCC has done the right
thing (from tpm_crb's perspective) for us so far, but we should not rely on
that. Thus, it makes sense to fix this also in tpm_crb, not least because
the fix can be then backported to stable kernels and make them more robust
when compiled in differing environments.
Cc: stable@vger.kernel.org
Cc: James Morris <jmorris@namei.org>
Cc: Tomas Winkler <tomas.winkler@intel.com>
Cc: Jerry Snitselaar <jsnitsel@redhat.com>
Fixes:
30fc8d138e91 ("tpm: TPM 2.0 CRB Interface")
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Aditya Pakki [Mon, 4 Mar 2019 22:48:54 +0000 (16:48 -0600)]
md: Fix failed allocation of md_register_thread
commit
e406f12dde1a8375d77ea02d91f313fb1a9c6aec upstream.
mddev->sync_thread can be set to NULL on kzalloc failure downstream.
The patch checks for such a scenario and frees allocated resources.
Committer node:
Added similar fix to raid5.c, as suggested by Guoqing.
Cc: stable@vger.kernel.org # v3.16+
Acked-by: Guoqing Jiang <gqjiang@suse.com>
Signed-off-by: Aditya Pakki <pakki001@umn.edu>
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>