11 Aug, 2020
18 commits
-
commit 75bbd2ea50ba1c5d9da878a17e92eac02fe0fd3a upstream.
Check `num_rsp` before using it as for-loop counter.
Cc: stable@vger.kernel.org
Signed-off-by: Peilin Ye
Signed-off-by: Marcel Holtmann
Signed-off-by: Greg Kroah-Hartman -
commit 51c19bf3d5cfaa66571e4b88ba2a6f6295311101 upstream.
Check upon `num_rsp` is insufficient. A malformed event packet with a
large `num_rsp` number makes hci_extended_inquiry_result_evt() go out
of bounds. Fix it.This patch fixes the following syzbot bug:
https://syzkaller.appspot.com/bug?id=4bf11aa05c4ca51ce0df86e500fce486552dc8d2
Reported-by: syzbot+d8489a79b781849b9c46@syzkaller.appspotmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Peilin Ye
Acked-by: Greg Kroah-Hartman
Signed-off-by: Marcel Holtmann
Signed-off-by: Greg Kroah-Hartman -
commit 11536442a3b4e1de6890ea5e805908debb74f94a upstream.
The variable authmode can be uninitialized. The danger would be if
it equals to _WPA_IE_ID_ (0xdd) or _WPA2_IE_ID_ (0x33). We can avoid
this by setting it to zero instead. This is the approach that was
used in the rtl8723bs driver.Fixes: 7b464c9fa5cc ("staging: r8188eu: Add files for new driver - part 4")
Co-developed-by: Dan Carpenter
Signed-off-by: Dan Carpenter
Signed-off-by: Dinghao Liu
Cc: stable
Link: https://lore.kernel.org/r/20200728072153.9202-1-dinghao.liu@zju.edu.cn
Signed-off-by: Greg Kroah-Hartman -
commit b4383c971bc5263efe2b0915ba67ebf2bf3f1ee5 upstream.
when firmware fails to load we should not call unregister_netdev()
this patch fixes a race condition between rtl871x_load_fw_cb() and
r871xu_dev_remove() and fixes the bug reported by syzbotReported-by: syzbot+80899a8a8efe8968cde7@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=80899a8a8efe8968cde7
Signed-off-by: Rustam Kovhaev
Cc: stable
Link: https://lore.kernel.org/r/20200716151324.1036204-1-rkovhaev@gmail.com
Signed-off-by: Greg Kroah-Hartman -
commit 3e338d3c95c735dc3265a86016bb4c022ec7cadc upstream.
syzbot report [1] describes a deadlock when write operation against an
ashmem fd executed at the time when ashmem is shrinking its cache results
in the following lock sequence:Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(fs_reclaim);
lock(&sb->s_type->i_mutex_key#13);
lock(fs_reclaim);
lock(&sb->s_type->i_mutex_key#13);kswapd takes fs_reclaim and then inode_lock while generic_perform_write
takes inode_lock and then fs_reclaim. However ashmem does not support
writing into backing shmem with a write syscall. The only way to change
its content is to mmap it and operate on mapped memory. Therefore the race
that lockdep is warning about is not valid. Resolve this by introducing a
separate lockdep class for the backing shmem inodes.[1]: https://lkml.kernel.org/lkml/0000000000000b5f9d059aa2037f@google.com/
Reported-by: syzbot+7a0d9d0b26efefe61780@syzkaller.appspotmail.com
Signed-off-by: Suren Baghdasaryan
Cc: stable
Reviewed-by: Joel Fernandes (Google)
Link: https://lore.kernel.org/r/20200730192632.3088194-1-surenb@google.com
Signed-off-by: Greg Kroah-Hartman -
commit 80982c7e834e5d4e325b6ce33757012ecafdf0bb upstream.
Some ioctls via OSS sequencer API may race and lead to UAF when the
port create and delete are performed concurrently, as spotted by a
couple of syzkaller cases. This patch is an attempt to address it by
serializing the ioctls with the existing register_mutex.Basically OSS sequencer API is an obsoleted interface and was designed
without much consideration of the concurrency. There are very few
applications with it, and the concurrent performance isn't asked,
hence this "big hammer" approach should be good enough.Reported-by: syzbot+1a54a94bd32716796edd@syzkaller.appspotmail.com
Reported-by: syzbot+9d2abfef257f3e2d4713@syzkaller.appspotmail.com
Suggested-by: Hillf Danton
Cc:
Link: https://lore.kernel.org/r/20200804185815.2453-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 7fe3530427e52dd53cd7366914864e29215180a4 upstream.
The ca0113 command had the wrong group_id, 0x48 when it should've been
0x30. The front microphone selection should now work.Signed-off-by: Connor McAdams
Cc:
Link: https://lore.kernel.org/r/20200803002928.8638-3-conmanx360@gmail.com
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit a00dc409de455b64e6cb2f6d40cdb8237cdb2e83 upstream.
When the ZxR headphone gain control was added, the ca0132_switch_get
function was not updated, which meant that the changes to the control
state were not saved when entering/exiting alsamixer.Signed-off-by: Connor McAdams
Cc:
Link: https://lore.kernel.org/r/20200803002928.8638-1-conmanx360@gmail.com
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit cc5edb1bd3f7bfe450f767b12423f6673822427b upstream.
Add a new quirk ID for the Recon3D, as tested by me.
Signed-off-by: Connor McAdams
Cc:
Link: https://lore.kernel.org/r/20200803002928.8638-2-conmanx360@gmail.com
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit f1ec5be17b9aafbc5f573da023850566b43d8e5e upstream.
There are several Loongson-3 based laptops produced by CZC or Lemote,
they use alc269/alc662 codecs and need specific pin-tables, this patch
add their pin-tables.Signed-off-by: Huacai Chen
Cc:
Link: https://lore.kernel.org/r/1596360400-32425-1-git-send-email-chenhc@lemote.com
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 07c9983b567d0ef33aefc063299de95a987e12a8 upstream.
This reverts commit 9a6418487b56 ("ALSA: hda: call runtime_allow()
for all hda controllers").The reverted patch already introduced some regressions on some
machines:
- on gemini-lake machines, the error of "azx_get_response timeout"
happens in the hda driver.
- on the machines with alc662 codec, the audio jack detection doesn't
work anymore.Fixes: 9a6418487b56 ("ALSA: hda: call runtime_allow() for all hda controllers")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208511
Cc:
Signed-off-by: Hui Wang
Link: https://lore.kernel.org/r/20200803064638.6139-1-hui.wang@canonical.com
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
when ctx->sqo_mm is zero, io_sq_wq_submit_work() frees 'req'
without deleting it from 'task_list'. After that, 'req' is
accessed in io_ring_ctx_wait_and_kill() which lead to
a use-after-free.Signed-off-by: Guoyu Huang
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
Liu reports that he can trigger a NULL pointer dereference with
IORING_OP_SENDMSG, by changing the sqe->opcode after we've validated
that the previous opcode didn't need a file and didn't assign one.Ensure we validate and read the opcode only once.
Reported-by: Liu Yong
Tested-by: Liu Yong
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit ec37198acca7b4c17b96247697406e47aafe0605 upstream.
I've confirmed that the ASMedia ASM1142 has the same problem as the
ASM2142/ASM3142, in that it too reports that it supports 64-bit DMA
addresses when in fact it does not. As with the ASM2142/ASM3142, this
can cause problems on systems where the upper bits matter, and adding
the XHCI_NO_64BIT_SUPPORT quirk completely fixes the issue.Acked-by: Mathias Nyman
Signed-off-by: Forest Crossman
Cc: stable
Link: https://lore.kernel.org/r/20200728042408.180529-3-cyrozap@gmail.com
Signed-off-by: Greg Kroah-Hartman -
commit 1841cb255da41e87bed9573915891d056f80e2e7 upstream.
Not all ASMedia host controllers have a device ID that matches its part
number. #define some of these IDs to make it clearer at a glance which
chips require what quirks.Acked-by: Mathias Nyman
Signed-off-by: Forest Crossman
Link: https://lore.kernel.org/r/20200728042408.180529-2-cyrozap@gmail.com
Cc: stable
Signed-off-by: Greg Kroah-Hartman -
commit 17a82716587e9d7c3b246a789add490b2b5dcab6 upstream.
In previous patches that added support for new iowarrior devices, the
handling of the report size was not done correct.Fix that up and update the copyright date for the driver
Reworked from an original patch written by Christoph Jung.
Fixes: bab5417f5f01 ("USB: misc: iowarrior: add support for the 100 device")
Fixes: 5f6f8da2d7b5 ("USB: misc: iowarrior: add support for the 28 and 28L devices")
Fixes: 461d8deb26a7 ("USB: misc: iowarrior: add support for 2 OEMed devices")
Cc: stable
Reported-by: Christoph Jung
Link: https://lore.kernel.org/r/20200726094939.1268978-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman -
commit 90c91dfb86d0ff545bd329d3ddd72c147e2ae198 upstream.
Kan and Andi reported that we fail to kill rotation when the flexible
events go empty, but the context does not. XXX moarFixes: fd7d55172d1e ("perf/cgroups: Don't rotate events for cgroups unnecessarily")
Reported-by: Andi Kleen
Reported-by: Kan Liang
Tested-by: Kan Liang
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20200305123851.GX2596@hirez.programming.kicks-ass.net
Cc: Robin Murphy
Signed-off-by: Greg Kroah-Hartman -
commit d2a4309c1ab6df424b2239fe2920d6f26f808d17 upstream.
When running qmi-firmware-update on the Sierra Wireless EM7305 in a Toshiba
laptop, it changed product ID to 0x9062 when entering QDL mode:usb 2-4: new high-speed USB device number 78 using xhci_hcd
usb 2-4: New USB device found, idVendor=1199, idProduct=9062, bcdDevice= 0.00
usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 2-4: Product: EM7305
usb 2-4: Manufacturer: Sierra Wireless, IncorporatedThe upgrade could complete after running
# echo 1199 9062 > /sys/bus/usb-serial/drivers/qcserial/new_idqcserial 2-4:1.0: Qualcomm USB modem converter detected
usb 2-4: Qualcomm USB modem converter now attached to ttyUSB0Signed-off-by: Erik Ekman
Link: https://lore.kernel.org/r/20200717185118.3640219-1-erik@kryo.se
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman
07 Aug, 2020
10 commits
-
Tested-by: Shuah Khan
Signed-off-by: Greg Kroah-Hartman -
commit bb0de3131f4c60a9bf976681e0fe4d1e55c7a821 upstream.
The sockmap code currently ignores the value of attach_bpf_fd when
detaching a program. This is contrary to the usual behaviour of
checking that attach_bpf_fd represents the currently attached
program.Ensure that attach_bpf_fd is indeed the currently attached
program. It turns out that all sockmap selftests already do this,
which indicates that this is unlikely to cause breakage.Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
Signed-off-by: Lorenz Bauer
Signed-off-by: Alexei Starovoitov
Link: https://lore.kernel.org/bpf/20200629095630.7933-5-lmb@cloudflare.com
Signed-off-by: Greg Kroah-Hartman -
commit f43cb0d672aa8eb09bfdb779de5900c040487d1d upstream.
Fix sockmap tests which rely on old bpf_prog_dispatch behaviour.
In the first case, the tests check that detaching without giving
a program succeeds. Since these are not the desired semantics,
invert the condition. In the second case, the clean up code doesn't
supply the necessary program fds.Fixes: bb0de3131f4c ("bpf: sockmap: Require attach_bpf_fd when detaching a program")
Reported-by: Martin KaFai Lau
Signed-off-by: Lorenz Bauer
Signed-off-by: Daniel Borkmann
Reviewed-by: Jakub Sitnicki
Link: https://lore.kernel.org/bpf/20200709115151.75829-1-lmb@cloudflare.com
Signed-off-by: Greg Kroah-Hartman -
This patch is used to fix ext4 direct I/O read error when
the read size is not aligned with block size.Then, I will use a test to explain the error.
(1) Make a file that is not aligned with block size:
$dd if=/dev/zero of=./test.jar bs=1000 count=3(2) I wrote a source file named "direct_io_read_file.c" as following:
#include
#include
#include
#include
#include
#include
#include
#define BUF_SIZE 1024int main()
{
int fd;
int ret;unsigned char *buf;
ret = posix_memalign((void **)&buf, 512, BUF_SIZE);
if (ret) {
perror("posix_memalign failed");
exit(1);
}
fd = open("./test.jar", O_RDONLY | O_DIRECT, 0755);
if (fd < 0){
perror("open ./test.jar failed");
exit(1);
}do {
ret = read(fd, buf, BUF_SIZE);
printf("ret=%d\n",ret);
if (ret < 0) {
perror("write test.jar failed");
}
} while (ret > 0);free(buf);
close(fd);
}(3) Compile the source file:
$gcc direct_io_read_file.c -D_GNU_SOURCE(4) Run the test program:
$./a.outThe result is as following:
ret=1024
ret=1024
ret=952
ret=-1
write test.jar failed: Invalid argument.I have tested this program on XFS filesystem, XFS does not have
this problem, because XFS use iomap_dio_rw() to do direct I/O
read. And the comparing between read offset and file size is done
in iomap_dio_rw(), the code is as following:if (pos < size) {
retval = filemap_write_and_wait_range(mapping, pos,
pos + iov_length(iov, nr_segs) - 1);if (!retval) {
retval = mapping->a_ops->direct_IO(READ, iocb,
iov, pos, nr_segs);
}
...
}...only when "pos < size", direct I/O can be done, or 0 will be return.
I have tested the fix patch on Ext4, it is up to the mustard of
EINVAL in man2(read) as following:
#include
ssize_t read(int fd, void *buf, size_t count);EINVAL
fd is attached to an object which is unsuitable for reading;
or the file was opened with the O_DIRECT flag, and either the
address specified in buf, the value specified in count, or the
current file offset is not suitably aligned.So I think this patch can be applied to fix ext4 direct I/O error.
However Ext4 introduces direct I/O read using iomap infrastructure
on kernel 5.5, the patch is commit
("ext4: introduce direct I/O read using iomap infrastructure"),
then Ext4 will be the same as XFS, they all use iomap_dio_rw() to do direct
I/O read. So this problem does not exist on kernel 5.5 for Ext4.>From above description, we can see this problem exists on all the kernel
versions between kernel 3.14 and kernel 5.4. It will cause the Applications
to fail to read. For example, when the search service downloads a new full
index file, the search engine is loading the previous index file and is
processing the search request, it can not use buffer io that may squeeze
the previous index file in use from pagecache, so the serch service must
use direct I/O read.Please apply this patch on these kernel versions, or please use the method
on kernel 5.5 to fix this problem.Fixes: 9fe55eea7e4b ("Fix race when checking i_size on direct i/o read")
Reviewed-by: Jan Kara
Co-developed-by: Wang Long
Signed-off-by: Wang Long
Signed-off-by: Jiang Ying
Signed-off-by: Greg Kroah-Hartman -
With the backport of f227e3ec3b5c ("random32: update the net random
state on interrupt and activity") and its associated fixes, the
arm64 build explodes early:In file included from ../include/linux/smp.h:67,
from ../include/linux/percpu.h:7,
from ../include/linux/prandom.h:12,
from ../include/linux/random.h:118,
from ../arch/arm64/include/asm/pointer_auth.h:6,
from ../arch/arm64/include/asm/processor.h:39,
from ../include/linux/mutex.h:19,
from ../include/linux/kernfs.h:12,
from ../include/linux/sysfs.h:16,
from ../include/linux/kobject.h:20,
from ../include/linux/of.h:17,
from ../include/linux/irqdomain.h:35,
from ../include/linux/acpi.h:13,
from ../include/acpi/apei.h:9,
from ../include/acpi/ghes.h:5,
from ../include/linux/arm_sdei.h:8,
from ../arch/arm64/kernel/asm-offsets.c:10:
../arch/arm64/include/asm/smp.h:100:29: error: field ‘ptrauth_key’ has
incomplete typeThis is due to struct ptrauth_keys_kernel not being defined before
we transitively include asm/smp.h from linux/random.h.Paper over it by moving the inclusion of linux/random.h *after* the
type has been defined.Signed-off-by: Marc Zyngier
Signed-off-by: Greg Kroah-Hartman -
commit c0842fbc1b18c7a044e6ff3e8fa78bfa822c7d1a upstream.
The addition of percpu.h to the list of includes in random.h revealed
some circular dependencies on arm64 and possibly other platforms. This
include was added solely for the pseudo-random definitions, which have
nothing to do with the rest of the definitions in this file but are
still there for legacy reasons.This patch moves the pseudo-random parts to linux/prandom.h and the
percpu.h include with it, which is now guarded by _LINUX_PRANDOM_H and
protected against recursive inclusion.A further cleanup step would be to remove this from
entirely, and make people who use the prandom infrastructure include
just the new header file. That's a bit of a churn patch, but grepping
for "prandom_" and "next_pseudo_random32" "struct rnd_state" should
catch most users.But it turns out that that nice cleanup step is fairly painful, because
a _lot_ of code currently seems to depend on the implicit include of
, which can currently come in a lot of ways, including
such fairly core headfers as .So the "nice cleanup" part may or may never happen.
Fixes: 1c9df907da83 ("random: fix circular include dependency on arm64 after addition of percpu.h")
Tested-by: Guenter Roeck
Acked-by: Willy Tarreau
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 83bdc7275e6206f560d247be856bceba3e1ed8f2 upstream.
It turns out that the plugin right now ends up being really unhappy
about the change from 'static' to 'extern' storage that happened in
commit f227e3ec3b5c ("random32: update the net random state on interrupt
and activity").This is probably a trivial fix for the latent_entropy plugin, but for
now, just remove net_rand_state from the list of things the plugin
worries about.Reported-by: Stephen Rothwell
Cc: Emese Revfy
Cc: Kees Cook
Cc: Willy Tarreau
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 1c9df907da83812e4f33b59d3d142c864d9da57f upstream.
Daniel Díaz and Kees Cook independently reported that commit
f227e3ec3b5c ("random32: update the net random state on interrupt and
activity") broke arm64 due to a circular dependency on include files
since the addition of percpu.h in random.h.The correct fix would definitely be to move all the prandom32 stuff out
of random.h but for backporting, a smaller solution is preferred.This one replaces linux/percpu.h with asm/percpu.h, and this fixes the
problem on x86_64, arm64, arm, and mips. Note that moving percpu.h
around didn't change anything and that removing it entirely broke
differently. When backporting, such options might still be considered
if this patch fails to help.[ It turns out that an alternate fix seems to be to just remove the
troublesome remove from the arm64
that causes the circular dependency.But we might as well do the whole belt-and-suspenders thing, and
minimize inclusion in too. Either will fix the
problem, and both are good changes. - Linus ]Reported-by: Daniel Díaz
Reported-by: Kees Cook
Tested-by: Marc Zyngier
Fixes: f227e3ec3b5c
Cc: Stephen Rothwell
Signed-off-by: Willy Tarreau
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit aa54ea903abb02303bf55855fb51e3fcee135d70 upstream.
Fix build error for the case:
defined(CONFIG_SMP) && !defined(CONFIG_CPU_V6)config: keystone_defconfig
CC arch/arm/kernel/signal.o
In file included from ../include/linux/random.h:14,
from ../arch/arm/kernel/signal.c:8:
../arch/arm/include/asm/percpu.h: In function ‘__my_cpu_offset’:
../arch/arm/include/asm/percpu.h:29:34: error: ‘current_stack_pointer’ undeclared (first use in this function); did you mean ‘user_stack_pointer’?
: "Q" (*(const unsigned long *)current_stack_pointer));
^~~~~~~~~~~~~~~~~~~~~
user_stack_pointerFixes: f227e3ec3b5c ("random32: update the net random state on interrupt and activity")
Signed-off-by: Grygorii Strashko
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit f227e3ec3b5cad859ad15666874405e8c1bbc1d4 upstream.
This modifies the first 32 bits out of the 128 bits of a random CPU's
net_rand_state on interrupt or CPU activity to complicate remote
observations that could lead to guessing the network RNG's internal
state.Note that depending on some network devices' interrupt rate moderation
or binding, this re-seeding might happen on every packet or even almost
never.In addition, with NOHZ some CPUs might not even get timer interrupts,
leaving their local state rarely updated, while they are running
networked processes making use of the random state. For this reason, we
also perform this update in update_process_times() in order to at least
update the state when there is user or system activity, since it's the
only case we care about.Reported-by: Amit Klein
Suggested-by: Linus Torvalds
Cc: Eric Dumazet
Cc: "Jason A. Donenfeld"
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc:
Signed-off-by: Willy Tarreau
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
05 Aug, 2020
12 commits
-
Tested-by: Shuah Khan
Signed-off-by: Greg Kroah-Hartman -
commit e4d9b04b973b2dbce7b42af95ea70d07da1c936d upstream.
Noticed with gcc 10 (fedora rawhide) that those variables were not being
declared as static, so end up with:ld: /tmp/build/perf/bench/epoll-wait.o:/git/perf/tools/perf/bench/epoll-wait.c:93: multiple definition of `end'; /tmp/build/perf/bench/futex-hash.o:/git/perf/tools/perf/bench/futex-hash.c:40: first defined here
ld: /tmp/build/perf/bench/epoll-wait.o:/git/perf/tools/perf/bench/epoll-wait.c:93: multiple definition of `start'; /tmp/build/perf/bench/futex-hash.o:/git/perf/tools/perf/bench/futex-hash.c:40: first defined here
ld: /tmp/build/perf/bench/epoll-wait.o:/git/perf/tools/perf/bench/epoll-wait.c:93: multiple definition of `runtime'; /tmp/build/perf/bench/futex-hash.o:/git/perf/tools/perf/bench/futex-hash.c:40: first defined here
ld: /tmp/build/perf/bench/epoll-ctl.o:/git/perf/tools/perf/bench/epoll-ctl.c:38: multiple definition of `end'; /tmp/build/perf/bench/futex-hash.o:/git/perf/tools/perf/bench/futex-hash.c:40: first defined here
ld: /tmp/build/perf/bench/epoll-ctl.o:/git/perf/tools/perf/bench/epoll-ctl.c:38: multiple definition of `start'; /tmp/build/perf/bench/futex-hash.o:/git/perf/tools/perf/bench/futex-hash.c:40: first defined here
ld: /tmp/build/perf/bench/epoll-ctl.o:/git/perf/tools/perf/bench/epoll-ctl.c:38: multiple definition of `runtime'; /tmp/build/perf/bench/futex-hash.o:/git/perf/tools/perf/bench/futex-hash.c:40: first defined here
make[4]: *** [/git/perf/tools/build/Makefile.build:145: /tmp/build/perf/bench/perf-in.o] Error 1Prefix those with bench__ and add them to bench/bench.h, so that we can
share those on the tools needing to access those variables from signal
handlers.Acked-by: Thomas Gleixner
Cc: Adrian Hunter
Cc: Davidlohr Bueso
Cc: Jiri Olsa
Cc: Namhyung Kim
Link: http://lore.kernel.org/lkml/20200303155811.GD13702@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
Cc: Ben Hutchings
Signed-off-by: Greg Kroah-Hartman -
commit ebcb9464a2ae3a547e97de476575c82ece0e93e2 upstream.
It is possible to return a pointer to a local variable when looking up
the architecture name for the running system and no normalization is
done on that value, i.e. we may end up returning the uts.machine local
variable.While this doesn't happen on most arches, as normalization takes place,
lets fix this by making that a static variable and optimize it a bit by
not always running uname(), only the first time.Noticed in fedora rawhide running with:
[perfbuilder@a5ff49d6e6e4 ~]$ gcc --version
gcc (GCC) 10.0.1 20200216 (Red Hat 10.0.1-0.8)Reported-by: Jiri Olsa
Cc: Adrian Hunter
Cc: Namhyung Kim
Signed-off-by: Arnaldo Carvalho de Melo
Cc: Ben Hutchings
Signed-off-by: Greg Kroah-Hartman -
commit cff20b3151ccab690715cb6cf0f5da5cccb32adf upstream.
To fix the build with newer gccs, that without this patch exit with:
LD /tmp/build/perf/tests/perf-in.o
ld: /tmp/build/perf/tests/bp_account.o:/git/perf/tools/perf/tests/bp_account.c:22: multiple definition of `the_var'; /tmp/build/perf/tests/bp_signal.o:/git/perf/tools/perf/tests/bp_signal.c:38: first defined here
make[4]: *** [/git/perf/tools/build/Makefile.build:145: /tmp/build/perf/tests/perf-in.o] Error 1First noticed in fedora:rawhide/32 with:
[perfbuilder@a5ff49d6e6e4 ~]$ gcc --version
gcc (GCC) 10.0.1 20200216 (Red Hat 10.0.1-0.8)Reported-by: Jiri Olsa
Cc: Adrian Hunter
Cc: Namhyung Kim
Signed-off-by: Arnaldo Carvalho de Melo
Cc: Ben Hutchings
Signed-off-by: Greg Kroah-Hartman -
commit bdd65589593edd79b6a12ce86b3b7a7c6dae5208 upstream.
0day reported a possible circular locking dependency:
Chain exists of:
&irq_desc_lock_class --> console_owner --> &port_lock_keyPossible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&port_lock_key);
lock(console_owner);
lock(&port_lock_key);
lock(&irq_desc_lock_class);The reason for this is a printk() in the i8259 interrupt chip driver
which is invoked with the irq descriptor lock held, which reverses the
lock operations vs. printk() from arbitrary contexts.Switch the printk() to printk_deferred() to avoid that.
Reported-by: kernel test robot
Signed-off-by: Thomas Gleixner
Signed-off-by: Ingo Molnar
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/87365abt2v.fsf@nanos.tec.linutronix.de
Signed-off-by: Greg Kroah-Hartman -
commit d2286ba7d574ba3103a421a2f9ec17cb5b0d87a1 upstream.
Prevent setting the tscdeadline timer if the lapic is hw disabled.
Fixes: bce87cce88 (KVM: x86: consolidate different ways to test for in-kernel LAPIC)
Cc:
Signed-off-by: Wanpeng Li
Message-Id:
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit b757b47a2fcba584d4a32fd7ee68faca510ab96f upstream.
If a stage-2 page-table contains an executable, read-only mapping at the
pte level (e.g. due to dirty logging being enabled), a subsequent write
fault to the same page which tries to install a larger block mapping
(e.g. due to dirty logging having been disabled) will erroneously inherit
the exec permission and consequently skip I-cache invalidation for the
rest of the block.Ensure that exec permission is only inherited by write faults when the
new mapping is of the same size as the existing one. A subsequent
instruction abort will result in I-cache invalidation for the entire
block mapping.Signed-off-by: Will Deacon
Signed-off-by: Marc Zyngier
Tested-by: Quentin Perret
Reviewed-by: Quentin Perret
Cc: Marc Zyngier
Cc:
Link: https://lore.kernel.org/r/20200723101714.15873-1-will@kernel.org
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 8754e1379e7089516a449821f88e1fe1ebbae5e1 ]
This patch fixed 2 issues with the usage of skb_cow in LAPB drivers
"lapbether" and "hdlc_x25":1) After skb_cow fails, kfree_skb should be called to drop a reference
to the skb. But in both drivers, kfree_skb is not called.2) skb_cow should be called before skb_push so that is can ensure the
safety of skb_push. But in "lapbether", it is incorrectly called after
skb_push.More details about these 2 issues:
1) The behavior of calling kfree_skb on failure is also the behavior of
netif_rx, which is called by this function with "return netif_rx(skb);".
So this function should follow this behavior, too.2) In "lapbether", skb_cow is called after skb_push. This results in 2
logical issues:
a) skb_push is not protected by skb_cow;
b) An extra headroom of 1 byte is ensured after skb_push. This extra
headroom has no use in this function. It also has no use in the
upper-layer function that this function passes the skb to
(x25_lapb_receive_frame in net/x25/x25_dev.c).
So logically skb_cow should instead be called before skb_push.Cc: Eric Dumazet
Cc: Martin Schiller
Signed-off-by: Xie He
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin -
[ Upstream commit d0d8aae64566b753c4330fbd5944b88af035f299 ]
Currently, maximum number of mapper pages are set to the pfn calculated
from the memblock size of the memblock containing kernel. This will work
until that memblock spans the entire memory. However, it will be set to
a wrong value if there are multiple memblocks defined in kernel
(e.g. with efi runtime services).Set the the maximum value to the pfn calculated from dram size.
Signed-off-by: Atish Patra
Signed-off-by: Palmer Dabbelt
Signed-off-by: Sasha Levin -
[ Upstream commit c2c633106453611be07821f53dff9e93a9d1c3f0 ]
There's a potential race in xennet_remove(); this is what the driver is
doing upon unregistering a network device:1. state = read bus state
2. if state is not "Closed":
3. request to set state to "Closing"
4. wait for state to be set to "Closing"
5. request to set state to "Closed"
6. wait for state to be set to "Closed"If the state changes to "Closed" immediately after step 1 we are stuck
forever in step 4, because the state will never go back from "Closed" to
"Closing".Make sure to check also for state == "Closed" in step 4 to prevent the
deadlock.Also add a 5 sec timeout any time we wait for the bus state to change,
to avoid getting stuck forever in wait_event().Signed-off-by: Andrea Righi
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin -
[ Upstream commit e6827d1abdc9b061a57d7b7d3019c4e99fabea2f ]
In the implementation of uld_send(), the skb is consumed on all
execution paths except one. Release skb when returning NET_XMIT_DROP.Signed-off-by: Navid Emamdoost
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin -
[ Upstream commit 039a7a30ec102ec866d382a66f87f6f7654f8140 ]
If a user task's stack is empty, or if it only has user regs, ORC
reports it as a reliable empty stack. But arch_stack_walk_reliable()
incorrectly treats it as unreliable.That happens because the only success path for user tasks is inside the
loop, which only iterates on non-empty stacks. Generally, a user task
must end in a user regs frame, but an empty stack is an exception to
that rule.Thanks to commit 71c95825289f ("x86/unwind/orc: Fix error handling in
__unwind_start()"), unwind_start() now sets state->error appropriately.
So now for both ORC and FP unwinders, unwind_done() and !unwind_error()
always means the end of the stack was successfully reached. So the
success path for kthreads is no longer needed -- it can also be used for
empty user tasks.Reported-by: Wang ShaoBo
Signed-off-by: Josh Poimboeuf
Signed-off-by: Thomas Gleixner
Tested-by: Wang ShaoBo
Link: https://lkml.kernel.org/r/f136a4e5f019219cbc4f4da33b30c2f44fa65b84.1594994374.git.jpoimboe@redhat.com
Signed-off-by: Sasha Levin
