- 20 May, 2020 37 commits
-
-
Arnd Bergmann authored
[ Upstream commit 6e31ded6 ] nfs currently behaves differently on 32-bit and 64-bit kernels regarding the on-disk format of nfs_fscache_inode_auxdata. That format should really be the same on any kernel, and we should avoid the 'timespec' type in order to remove that from the kernel later on. Using plain 'timespec64' would not be good here, since that includes implied padding and would possibly leak kernel stack data to the on-disk format on 32-bit architectures. struct __kernel_timespec would work as a replacement, but open-coding the two struct members in nfs_fscache_inode_auxdata makes it more obvious what's going on here, and keeps the current format for 64-bit architectures. Cc: David Howells <dhowells@redhat.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Dave Wysochanski authored
[ Upstream commit d9bfced1 ] Commit 402cb8dd ("fscache: Attach the index key and aux data to the cookie") added the index_key and index_key_len parameters to fscache_acquire_cookie(), and updated the callers in the NFS client. One of the callers was inside nfs_fscache_get_super_cookie() and was changed to use the full struct nfs_fscache_key as the index_key. However, a couple members of this structure contain pointers and thus will change each time the same NFS share is remounted. Since index_key is used for fscache_cookie->key_hash and this subsequently is used to compare cookies, the effectiveness of fscache with NFS is reduced to the point at which a umount occurs. Any subsequent remount of the same share will cause a unique NFS super_block index_key and key_hash to be generated for the same data, rendering any prior fscache data unable to be found. A simple reproducer demonstrates the problem. 1. Mount share with 'fsc', create a file, drop page cache systemctl start cachefilesd mount -o vers=3,fsc 127.0.0.1:/export /mnt dd if=/dev/zero of=/mnt/file1.bin bs=4096 count=1 echo 3 > /proc/sys/vm/drop_caches 2. Read file into page cache and fscache, then unmount dd if=/mnt/file1.bin of=/dev/null bs=4096 count=1 umount /mnt 3. Remount and re-read which should come from fscache mount -o vers=3,fsc 127.0.0.1:/export /mnt echo 3 > /proc/sys/vm/drop_caches dd if=/mnt/file1.bin of=/dev/null bs=4096 count=1 4. Check for READ ops in mountstats - there should be none grep READ: /proc/self/mountstats Looking at the history and the removed function, nfs_super_get_key(), we should only use nfs_fscache_key.key plus any uniquifier, for the fscache index_key. Fixes: 402cb8dd ("fscache: Attach the index key and aux data to the cookie") Signed-off-by:
Dave Wysochanski <dwysocha@redhat.com> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Adrian Hunter authored
[ Upstream commit c077dc5e ] First, it should be noted that the CQE timeout (60 seconds) is substantial so a CQE request that times out is really stuck, and the race between timeout and completion is extremely unlikely. Nevertheless this patch fixes an issue with it. Commit ad73d6fe ("mmc: complete requests from ->timeout") preserved the existing functionality, to complete the request. However that had only been necessary because the block layer timeout handler had been marking the request to prevent it from being completed normally. That restriction was removed at the same time, the result being that a request that has gone will have been completed anyway. That is, the completion was unnecessary. At the time, the unnecessary completion was harmless because the block layer would ignore it, although that changed in kernel v5.0. Note for stable, this patch will not apply cleanly without patch "mmc: core: Fix recursive locking issue in CQE recovery path" Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Fixes: ad73d6fe ("mmc: complete requests from ->timeout") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200508062227.23144-1-adrian.hunter@intel.comSigned-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Veerabhadrarao Badiganti authored
[ Upstream commit e6bfb1bf ] In the request completion path with CQE, request type is being checked after the request is getting completed. This is resulting in returning the wrong request type and leading to the IO hang issue. ASYNC request type is getting returned for DCMD type requests. Because of this mismatch, mq->cqe_busy flag is never getting cleared and the driver is not invoking blk_mq_hw_run_queue. So requests are not getting dispatched to the LLD from the block layer. All these eventually leading to IO hang issues. So, get the request type before completing the request. Cc: <stable@vger.kernel.org> Fixes: 1e8e55b6 ("mmc: block: Add CQE support") Signed-off-by:
Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Acked-by:
-
Dan Carpenter authored
[ Upstream commit 37e31d2d ] The i40iw_arp_table() function can return -EOVERFLOW if i40iw_alloc_resource() fails so we can't just test for "== -1". Fixes: 4e9042e6 ("i40iw: add hw and utils files") Link: https://lore.kernel.org/r/20200422092211.GA195357@mwandaSigned-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Grace Kao authored
[ Upstream commit 69388e15 ] According to Braswell NDA Specification Update (#557593), concurrent read accesses may result in returning 0xffffffff and write instructions may be dropped. We have an established format for the commit references, i.e. cdca06e4 ("pinctrl: baytrail: Add missing spinlock usage in byt_gpio_irq_handler") Fixes: 0bd50d71 ("pinctrl: cherryview: prevent concurrent access to GPIO controllers") Signed-off-by:
Grace Kao <grace.kao@intel.com> Reported-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit ccd025ea ] It appears that pin configuration for GPIO chip hasn't been enabled yet due to absence of ->set_config() callback. Enable it here for Intel Baytrail. Fixes: c501d0b1 ("pinctrl: baytrail: Add pin control operations") Depends-on: 2956b5d9 ("pinctrl / gpio: Introduce .set_config() callback for GPIO chips") Signed-off-by:
-
Andreas Gruenbacher authored
[ Upstream commit 566a2ab3 ] Make sure we don't walk past the end of the metadata in gfs2_walk_metadata: the inode holds fewer pointers than indirect blocks. Slightly clean up gfs2_iomap_get. Fixes: a27a0c9b ("gfs2: gfs2_walk_metadata fix") Cc: stable@vger.kernel.org # v5.3+ Signed-off-by:
Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Signed-off-by:
-
Kai-Heng Feng authored
[ Upstream commit 52e4e368 ] Commit 317d9313 ("ALSA: hda/realtek - Set default power save node to 0") makes the ALC225 have pop noise on S3 resume and cold boot. The previous fix enable power save node universally for ALC225, however it makes some ALC225 systems unable to produce any sound. So let's only enable power save node for the affected Dell Wyse platform. Fixes: 317d9313 ("ALSA: hda/realtek - Set default power save node to 0") BugLink: https://bugs.launchpad.net/bugs/1866357Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20200503152449.22761-2-kai.heng.feng@canonical.comSigned-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Vasily Averin authored
[ Upstream commit 5e698222 ] Commit 89163f93 ("ipc/util.c: sysvipc_find_ipc() should increase position index") is causing this bug (seen on 5.6.8): # ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages # ipcmk -Q Message queue id: 0 # ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages 0x82db8127 0 root 644 0 0 # ipcmk -Q Message queue id: 1 # ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages 0x82db8127 0 root 644 0 0 0x76d1fb2a 1 root 644 0 0 # ipcrm -q 0 # ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages 0x76d1fb2a 1 root 644 0 0 0x76d1fb2a 1 root 644 0 0 # ipcmk -Q Message queue id: 2 # ipcrm -q 2 # ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages 0x76d1fb2a 1 root 644 0 0 0x76d1fb2a 1 root 644 0 0 # ipcmk -Q Message queue id: 3 # ipcrm -q 1 # ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages 0x7c982867 3 root 644 0 0 0x7c982867 3 root 644 0 0 0x7c982867 3 root 644 0 0 0x7c982867 3 root 644 0 0 Whenever an IPC item with a low id is deleted, the items with higher ids are duplicated, as if filling a hole. new_pos should jump through hole of unused ids, pos can be updated inside "for" cycle. Fixes: 89163f93 ("ipc/util.c: sysvipc_find_ipc() should increase position index") Reported-by:
Andreas Schwab <schwab@suse.de> Reported-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Vasily Averin <vvs@virtuozzo.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Acked-by:
Waiman Long <longman@redhat.com> Cc: NeilBrown <neilb@suse.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Oberparleiter <oberpar@linux.ibm.com> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: Manfred Spraul <manfred@colorfullife.com> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/4921fe9b-9385-a2b4-1dc4-1099be6d2e39@virtuozzo.comSigned-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Vasily Averin authored
[ Upstream commit 5b5703db ] v2: removed TODO reminder Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Kai Vehmanen authored
[ Upstream commit ca76282b ] A race exists between build_pcms() and build_controls() phases of codec setup. Build_pcms() sets up notifier for jack events. If a monitor event is received before build_controls() is run, the initial jack state is lost and never reported via mixer controls. The problem can be hit at least with SOF as the controller driver. SOF calls snd_hda_codec_build_controls() in its workqueue-based probe and this can be delayed enough to hit the race condition. Fix the issue by invalidating the per-pin ELD information when build_controls() is called. The existing call to hdmi_present_sense() will update the ELD contents. This ensures initial monitor state is correctly reflected via mixer controls. BugLink: https://github.com/thesofproject/linux/issues/1687Signed-off-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20200428123836.24512-1-kai.vehmanen@linux.intel.comSigned-off-by:
-
Chris Wilson authored
[ Upstream commit 8c539776 ] Make a note of the first time we discover the turbo mode has been disabled by the BIOS, as otherwise we complain every time we try to update the mode. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Lubomir Rintel authored
[ Upstream commit 0c894463 ] When a channel configuration fails, the status of the channel is set to DEV_ERROR so that an attempt to submit it fails. However, this status sticks until the heat end of the universe, making it impossible to recover from the error. Let's reset it when the channel is released so that further use of the channel with correct configuration is not impacted. Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> Link: https://lore.kernel.org/r/20200419164912.670973-5-lkundrak@v3.skSigned-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Madhuparna Bhowmik authored
[ Upstream commit 2e45676a ] pd->dma.dev is read in irq handler pd_irq(). However, it is set to pdev->dev after request_irq(). Therefore, set pd->dma.dev to pdev->dev before request_irq() to avoid data race between pch_dma_probe() and pd_irq(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com> Link: https://lore.kernel.org/r/20200416062335.29223-1-madhuparnabhowmik10@gmail.comSigned-off-by:
-
Ilie Halip authored
[ Upstream commit 3c1918c8 ] When building with the LLVM linker this error occurrs: LD arch/riscv/kernel/vdso/vdso-syms.o ld.lld: error: no input files This happens because the lld treats -R as an alias to -rpath, as opposed to ld where -R means --just-symbols. Use the long option name for compatibility between the two. Link: https://github.com/ClangBuiltLinux/linux/issues/805Reported-by:
Dmitry Golovin <dima@golovin.in> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Ilie Halip <ilie.halip@gmail.com> Reviewed-by:
Fangrui Song <maskray@google.com> Signed-off-by:
Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 24adbc16 ] We autotune rcvbuf whenever SO_RCVLOWAT is set to account for 100% overhead in tcp_set_rcvlowat() This works well when skb->len/skb->truesize ratio is bigger than 0.5 But if we receive packets with small MSS, we can end up in a situation where not enough bytes are available in the receive queue to satisfy RCVLOWAT setting. As our sk_rcvbuf limit is hit, we send zero windows in ACK packets, preventing remote peer from sending more data. Even autotuning does not help, because it only triggers at the time user process drains the queue. If no EPOLLIN is generated, this can not happen. Note poll() has a similar issue, after commit c7004482 ("tcp: Respect SO_RCVLOWAT in tcp_poll().") Fixes: 03f45c88 ("tcp: avoid extra wakeups for SO_RCVLOWAT users") Signed-off-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Kelly Littlepage authored
[ Upstream commit cc4de047 ] The stated intent of the original commit is to is to "return the timestamp corresponding to the highest sequence number data returned." The current implementation returns the timestamp for the last byte of the last fully read skb, which is not necessarily the last byte in the recv buffer. This patch converts behavior to the original definition, and to the behavior of the previous draft versions of commit 98aaa913 ("tcp: Extend SOF_TIMESTAMPING_RX_SOFTWARE to TCP recvmsg") which also match this behavior. Fixes: 98aaa913 ("tcp: Extend SOF_TIMESTAMPING_RX_SOFTWARE to TCP recvmsg") Co-developed-by:
Iris Liu <iris@onechronos.com> Signed-off-by:
Kelly Littlepage <kelly@onechronos.com> Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Zefan Li authored
[ Upstream commit 090e28b2 ] If systemd is configured to use hybrid mode which enables the use of both cgroup v1 and v2, systemd will create new cgroup on both the default root (v2) and netprio_cgroup hierarchy (v1) for a new session and attach task to the two cgroups. If the task does some network thing then the v2 cgroup can never be freed after the session exited. One of our machines ran into OOM due to this memory leak. In the scenario described above when sk_alloc() is called cgroup_sk_alloc() thought it's in v2 mode, so it stores the cgroup pointer in sk->sk_cgrp_data and increments the cgroup refcnt, but then sock_update_netprioidx() thought it's in v1 mode, so it stores netprioidx value in sk->sk_cgrp_data, so the cgroup refcnt will never be freed. Currently we do the mode switch when someone writes to the ifpriomap cgroup control file. The easiest fix is to also do the switch when a task is attached to a new cgroup. Fixes: bd1060a1 ("sock, cgroup: add sock->sk_cgroup") Reported-by:
Yang Yingliang <yangyingliang@huawei.com> Tested-by:
Zefan Li <lizefan@huawei.com> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Paolo Abeni authored
[ Upstream commit 57644431 ] In commit b406472b ("net: ipv4: avoid mixed n_redirects and rate_tokens usage") I missed the fact that a 0 'rate_tokens' will bypass the backoff algorithm. Since rate_tokens is cleared after a redirect silence, and never incremented on redirects, if the host keeps receiving packets requiring redirect it will reply ignoring the backoff. Additionally, the 'rate_last' field will be updated with the cadence of the ingress packet requiring redirect. If that rate is high enough, that will prevent the host from generating any other kind of ICMP messages The check for a zero 'rate_tokens' value was likely a shortcut to avoid the more complex backoff algorithm after a redirect silence period. Address the issue checking for 'n_redirects' instead, which is incremented on successful redirect, and does not interfere with other ICMP replies. Fixes: b406472b ("net: ipv4: avoid mixed n_redirects and rate_tokens usage") Reported-and-tested-by:
Colin Walters <walters@redhat.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit 3047211c ] There is a soft dependency against dsa_loop_bdinfo.ko which sets up the MDIO device registration, since there are no symbols referenced by dsa_loop.ko, there is no automatic loading of dsa_loop_bdinfo.ko which is needed. Fixes: 98cd1552 ("net: dsa: Mock-up driver") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Luo bin authored
[ Upstream commit e8a1b0ef ] if some function in ndo_stop interface returns failure because of hardware fault, must go on excuting rest steps rather than return failure directly, otherwise will cause memory leak.And bump the timeout for SET_FUNC_STATE to ensure that cmd won't return failure when hw is busy. Otherwise hw may stomp host memory if we free memory regardless of the return value of SET_FUNC_STATE. Fixes: 51ba902a ("net-next/hinic: Initialize hw interface") Signed-off-by:
Luo bin <luobin9@huawei.com> Signed-off-by:
-
Michael S. Tsirkin authored
[ Upstream commit 01c32598 ] When we fill up a receive VQ, try_fill_recv currently tries to count kicks using a 64 bit stats counter. Turns out, on a 32 bit kernel that uses a seqcount. sequence counts are "lock" constructs where you need to make sure that writers are serialized. In turn, this means that we mustn't run two try_fill_recv concurrently. Which of course we don't. We do run try_fill_recv sometimes from a softirq napi context, and sometimes from a fully preemptible context, but the later always runs with napi disabled. However, when it comes to the seqcount, lockdep is trying to enforce the rule that the same lock isn't accessed from preemptible and softirq context - it doesn't know about napi being enabled/disabled. This causes a false-positive warning: WARNING: inconsistent lock state ... inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. As a work around, shut down the warning by switching to u64_stats_update_begin_irqsave - that works by disabling interrupts on 32 bit only, is a NOP on 64 bit. Reported-by:
Thomas Gleixner <tglx@linutronix.de> Suggested-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit e776af60 ] If user provides wrong virtual address in TCP_ZEROCOPY_RECEIVE operation we want to return -EINVAL error. But depending on zc->recv_skip_hint content, we might return -EIO error if the socket has SOCK_DONE set. Make sure to return -EINVAL in this case. BUG: KMSAN: uninit-value in tcp_zerocopy_receive net/ipv4/tcp.c:1833 [inline] BUG: KMSAN: uninit-value in do_tcp_getsockopt+0x4494/0x6320 net/ipv4/tcp.c:3685 CPU: 1 PID: 625 Comm: syz-executor.0 Not tainted 5.7.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x220 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 tcp_zerocopy_receive net/ipv4/tcp.c:1833 [inline] do_tcp_getsockopt+0x4494/0x6320 net/ipv4/tcp.c:3685 tcp_getsockopt+0xf8/0x1f0 net/ipv4/tcp.c:3728 sock_common_getsockopt+0x13f/0x180 net/core/sock.c:3131 __sys_getsockopt+0x533/0x7b0 net/socket.c:2177 __do_sys_getsockopt net/socket.c:2192 [inline] __se_sys_getsockopt+0xe1/0x100 net/socket.c:2189 __x64_sys_getsockopt+0x62/0x80 net/socket.c:2189 do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:297 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45c829 Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f1deeb72c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000037 RAX: ffffffffffffffda RBX: 00000000004e01e0 RCX: 000000000045c829 RDX: 0000000000000023 RSI: 0000000000000006 RDI: 0000000000000009 RBP: 000000000078bf00 R08: 0000000020000200 R09: 0000000000000000 R10: 00000000200001c0 R11: 0000000000000246 R12: 00000000ffffffff R13: 00000000000001d8 R14: 00000000004d3038 R15: 00007f1deeb736d4 Local variable ----zc@do_tcp_getsockopt created at: do_tcp_getsockopt+0x1a74/0x6320 net/ipv4/tcp.c:3670 do_tcp_getsockopt+0x1a74/0x6320 net/ipv4/tcp.c:3670 Fixes: 05255b82 ("tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive") Signed-off-by:
syzbot <syzkaller@googlegroups.com> Acked-by:
-
Maciej Żenczykowski authored
[ Upstream commit 09454fd0 ] This reverts commit 19bda36c: | ipv6: add mtu lock check in __ip6_rt_update_pmtu | | Prior to this patch, ipv6 didn't do mtu lock check in ip6_update_pmtu. | It leaded to that mtu lock doesn't really work when receiving the pkt | of ICMPV6_PKT_TOOBIG. | | This patch is to add mtu lock check in __ip6_rt_update_pmtu just as ipv4 | did in __ip_rt_update_pmtu. The above reasoning is incorrect. IPv6 *requires* icmp based pmtu to work. There's already a comment to this effect elsewhere in the kernel: $ git grep -p -B1 -A3 'RTAX_MTU lock' net/ipv6/route.c=4813= static int rt6_mtu_change_route(struct fib6_info *f6i, void *p_arg) ... /* In IPv6 pmtu discovery is not optional, so that RTAX_MTU lock cannot disable it. We still use this lock to block changes caused by addrconf/ndisc. */ This reverts to the pre-4.9 behaviour. Cc: Eric Dumazet <edumazet@google.com> Cc: Willem de Bruijn <willemb@google.com> Cc: Xin Long <lucien.xin@gmail.com> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
Maciej Żenczykowski <maze@google.com> Fixes: 19bda36c ("ipv6: add mtu lock check in __ip6_rt_update_pmtu") Signed-off-by:
-
Guillaume Nault authored
[ Upstream commit b8c15839 ] We don't want to disconnect a session because of a stray PADT arriving while the interface is in promiscuous mode. Furthermore, multicast and broadcast packets make no sense here, so only PACKET_HOST is accepted. Reported-by:
David Balažic <xerces9@gmail.com> Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Guillaume Nault <gnault@redhat.com> Signed-off-by:
-
Heiner Kallweit authored
[ Upstream commit 9de5d235 ] phy_restart_aneg() enables aneg in the PHY. That's not what we want if phydev->autoneg is disabled. In this case still update EEE advertisement register, but don't enable aneg and don't trigger an aneg restart. Fixes: f75abeb8 ("net: phy: restart phy autonegotiation after EEE advertisment change") Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Paolo Abeni authored
[ Upstream commit eead1c2e ] The cipso and calipso code can set the MLS_CAT attribute on successful parsing, even if the corresponding catmap has not been allocated, as per current configuration and external input. Later, selinux code tries to access the catmap if the MLS_CAT flag is present via netlbl_catmap_getlong(). That may cause null ptr dereference while processing incoming network traffic. Address the issue setting the MLS_CAT flag only if the catmap is really allocated. Additionally let netlbl_catmap_getlong() cope with NULL catmap. Reported-by:
Matthew Sheets <matthew.sheets@gd-ms.com> Fixes: 4b8feff2 ("netlabel: fix the horribly broken catmap functions") Fixes: ceba1832 ("calipso: Set the calipso socket label to match the secattr.") Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
Cong Wang authored
[ Upstream commit dd912306 ] syzbot managed to trigger a recursive NETDEV_FEAT_CHANGE event between bonding master and slave. I managed to find a reproducer for this: ip li set bond0 up ifenslave bond0 eth0 brctl addbr br0 ethtool -K eth0 lro off brctl addif br0 bond0 ip li set br0 up When a NETDEV_FEAT_CHANGE event is triggered on a bonding slave, it captures this and calls bond_compute_features() to fixup its master's and other slaves' features. However, when syncing with its lower devices by netdev_sync_lower_features() this event is triggered again on slaves when the LRO feature fails to change, so it goes back and forth recursively until the kernel stack is exhausted. Commit 17b85d29 intentionally lets __netdev_update_features() return -1 for such a failure case, so we have to just rely on the existing check inside netdev_sync_lower_features() and skip NETDEV_FEAT_CHANGE event only for this specific failure case. Fixes: fd867d51 ("net/core: generic support for disabling netdev features down stack") Reported-by: syzbot+e73ceacfd8560cc8a3ca@syzkaller.appspotmail.com Reported-by: syzbot+c2fb6f9ddcea95ba49b5@syzkaller.appspotmail.com Cc: Jarod Wilson <jarod@redhat.com> Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Jann Horn <jannh@google.com> Reviewed-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Acked-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
Raul E Rangel authored
[ Upstream commit 45a3fe3b ] The AMD eMMC 5.0 controller does not support 64 bit DMA. Fixes: 34597a3f ("mmc: sdhci-acpi: Add support for ACPI HID of AMD Controller with HS400") Signed-off-by:
Raul E Rangel <rrangel@chromium.org> Link: https://marc.info/?l=linux-mmc&m=158879884514552&w=2Reviewed-by:
-
Wu Bo authored
commit 83c6f239 upstream. If the __copy_from_user function failed we need to call sg_remove_request in sg_write. Link: https://lore.kernel.org/r/610618d9-e983-fd56-ed0f-639428343af7@huawei.comAcked-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
Wu Bo <wubo40@huawei.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Stefan Hajnoczi authored
[ Upstream commit 90b5feb8 ] A userspace process holding a file descriptor to a virtio_blk device can still invoke block_device_operations after hot unplug. This leads to a use-after-free accessing vblk->vdev in virtblk_getgeo() when ioctl(HDIO_GETGEO) is invoked: BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 IP: [<ffffffffc00e5450>] virtio_check_driver_offered_feature+0x10/0x90 [virtio] PGD 800000003a92f067 PUD 3a930067 PMD 0 Oops: 0000 [#1] SMP CPU: 0 PID: 1310 Comm: hdio-getgeo Tainted: G OE ------------ 3.10.0-1062.el7.x86_64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 task: ffff9be5fbfb8000 ti: ffff9be5fa890000 task.ti: ffff9be5fa890000 RIP: 0010:[<ffffffffc00e5450>] [<ffffffffc00e5450>] virtio_check_driver_offered_feature+0x10/0x90 [virtio] RSP: 0018:ffff9be5fa893dc8 EFLAGS: 00010246 RAX: ffff9be5fc3f3400 RBX: ffff9be5fa893e30 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff9be5fbc10b40 RBP: ffff9be5fa893dc8 R08: 0000000000000301 R09: 0000000000000301 R10: 0000000000000000 R11: 0000000000000000 R12: ffff9be5fdc24680 R13: ffff9be5fbc10b40 R14: ffff9be5fbc10480 R15: 0000000000000000 FS: 00007f1bfb968740(0000) GS:ffff9be5ffc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000090 CR3: 000000003a894000 CR4: 0000000000360ff0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: [<ffffffffc016ac37>] virtblk_getgeo+0x47/0x110 [virtio_blk] [<ffffffff8d3f200d>] ? handle_mm_fault+0x39d/0x9b0 [<ffffffff8d561265>] blkdev_ioctl+0x1f5/0xa20 [<ffffffff8d488771>] block_ioctl+0x41/0x50 [<ffffffff8d45d9e0>] do_vfs_ioctl+0x3a0/0x5a0 [<ffffffff8d45dc81>] SyS_ioctl+0xa1/0xc0 A related problem is that virtblk_remove() leaks the vd_index_ida index when something still holds a reference to vblk->disk during hot unplug. This causes virtio-blk device names to be lost (vda, vdb, etc). Fix these issues by protecting vblk->vdev with a mutex and reference counting vblk so the vd_index_ida index can be removed in all cases. Fixes: 48e4043d ("virtio: add virtio disk geometry feature") Reported-by:
Lance Digby <ldigby@redhat.com> Signed-off-by:
Stefan Hajnoczi <stefanha@redhat.com> Link: https://lore.kernel.org/r/20200430140442.171016-1-stefanha@redhat.comSigned-off-by:
Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit dc30b405 ] The current gcc-10 snapshot produces a false-positive warning: net/core/drop_monitor.c: In function 'trace_drop_common.constprop': cc1: error: writing 8 bytes into a region of size 0 [-Werror=stringop-overflow=] In file included from net/core/drop_monitor.c:23: include/uapi/linux/net_dropmon.h:36:8: note: at offset 0 to object 'entries' with size 4 declared here 36 | __u32 entries; | ^~~~~~~ I reported this in the gcc bugzilla, but in case it does not get fixed in the release, work around it by using a temporary variable. Fixes: 9a8afc8d ("Network Drop Monitor: Adding drop monitor implementation & Netlink protocol") Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94881Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit ee8d2267 ] Should an irq requested with 'devm_request_irq' be released explicitly, it should be done by 'devm_free_irq()', not 'free_irq()'. Fixes: 6c821bd9 ("net: Add MOXA ART SoCs ethernet driver") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 10e3cc18 ] A call to 'dma_alloc_coherent()' is hidden in 'sonic_alloc_descriptors()', called from 'sonic_probe1()'. This is correctly freed in the remove function, but not in the error handling path of the probe function. Fix it and add the missing 'dma_free_coherent()' call. While at it, rename a label in order to be slightly more informative. Fixes: efcce839 ("[PATCH] macsonic/jazzsonic network drivers update") Signed-off-by:
-
Hugh Dickins authored
[ Upstream commit ea0dfeb4 ] Recent commit 71725ed1 ("mm: huge tmpfs: try to split_huge_page() when punching hole") has allowed syzkaller to probe deeper, uncovering a long-standing lockdep issue between the irq-unsafe shmlock_user_lock, the irq-safe xa_lock on mapping->i_pages, and shmem inode's info->lock which nests inside xa_lock (or tree_lock) since 4.8's shmem_uncharge(). user_shm_lock(), servicing SysV shmctl(SHM_LOCK), wants shmlock_user_lock while its caller shmem_lock() holds info->lock with interrupts disabled; but hugetlbfs_file_setup() calls user_shm_lock() with interrupts enabled, and might be interrupted by a writeback endio wanting xa_lock on i_pages. This may not risk an actual deadlock, since shmem inodes do not take part in writeback accounting, but there are several easy ways to avoid it. Requiring interrupts disabled for shmlock_user_lock would be easy, but it's a high-level global lock for which that seems inappropriate. Instead, recall that the use of info->lock to guard info->flags in shmem_lock() dates from pre-3.1 days, when races with SHMEM_PAGEIN and SHMEM_TRUNCATE could occur: nowadays it serves no purpose, the only flag added or removed is VM_LOCKED itself, and calls to shmem_lock() an inode are already serialized by the caller. Take info->lock out of the chain and the possibility of deadlock or lockdep warning goes away. Fixes: 4595ef88 ("shmem: make shmem_inode_info::lock irq-safe") Reported-by: syzbot+c8a8197c8852f566b9d9@syzkaller.appspotmail.com Reported-by: syzbot+40b71e145e73f78f81ad@syzkaller.appspotmail.com Signed-off-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
Yang Shi <yang.shi@linux.alibaba.com> Cc: Yang Shi <yang.shi@linux.alibaba.com> Link: http://lkml.kernel.org/r/alpine.LSU.2.11.2004161707410.16322@eggly.anvils Link: https://lore.kernel.org/lkml/000000000000e5838c05a3152f53@google.com/ Link: https://lore.kernel.org/lkml/0000000000003712b305a331d3b1@google.com/Signed-off-by:
-
Florian Fainelli authored
commit 86f8b1c0 upstream. Prior to 1d27732f ("net: dsa: setup and teardown ports"), we would not treat failures to set-up an user port as fatal, but after this commit we would, which is a regression for some systems where interfaces may be declared in the Device Tree, but the underlying hardware may not be present (pluggable daughter cards for instance). Fixes: 1d27732f ("net: dsa: setup and teardown ports") Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
- 14 May, 2020 3 commits
-
-
Greg Kroah-Hartman authored
-
Oleg Nesterov authored
[ Upstream commit b5f20061 ] Commit cc731525 ("signal: Remove kernel interal si_code magic") changed the value of SI_FROMUSER(SI_MESGQ), this means that mq_notify() no longer works if the sender doesn't have rights to send a signal. Change __do_notify() to use do_send_sig_info() instead of kill_pid_info() to avoid check_kill_permission(). This needs the additional notify.sigev_signo != 0 check, shouldn't we change do_mq_notify() to deny sigev_signo == 0 ? Test-case: #include <signal.h> #include <mqueue.h> #include <unistd.h> #include <sys/wait.h> #include <assert.h> static int notified; static void sigh(int sig) { notified = 1; } int main(void) { signal(SIGIO, sigh); int fd = mq_open("/mq", O_RDWR|O_CREAT, 0666, NULL); assert(fd >= 0); struct sigevent se = { .sigev_notify = SIGEV_SIGNAL, .sigev_signo = SIGIO, }; assert(mq_notify(fd, &se) == 0); if (!fork()) { assert(setuid(1) == 0); mq_send(fd, "",1,0); return 0; } wait(NULL); mq_unlink("/mq"); assert(notified); return 0; } [manfred@colorfullife.com: 1) Add self_exec_id evaluation so that the implementation matches do_notify_parent 2) use PIDTYPE_TGID everywhere] Fixes: cc731525 ("signal: Remove kernel interal si_code magic") Reported-by:
Yoji <yoji.fujihar.min@gmail.com> Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Manfred Spraul <manfred@colorfullife.com> Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: Markus Elfring <elfring@users.sourceforge.net> Cc: <1vier1@web.de> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/e2a782e4-eab9-4f5c-c749-c07a8f7a4e66@colorfullife.comSigned-off-by:
-
Ivan Delalande authored
commit e08df079 upstream. If the trapping instruction contains a ':', for a memory access through segment registers for example, the sed substitution will insert the '*' marker in the middle of the instruction instead of the line address: 2b: 65 48 0f c7 0f cmpxchg16b %gs:*(%rdi) <-- trapping instruction I started to think I had forgotten some quirk of the assembly syntax before noticing that it was actually coming from the script. Fix it to add the address marker at the right place for these instructions: 28: 49 8b 06 mov (%r14),%rax 2b:* 65 48 0f c7 0f cmpxchg16b %gs:(%rdi) <-- trapping instruction 30: 0f 94 c0 sete %al Fixes: 18ff44b1 ("scripts/decodecode: make faulting insn ptr more robust") Signed-off-by:
Ivan Delalande <colona@arista.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Link: http://lkml.kernel.org/r/20200419223653.GA31248@visorSigned-off-by:
-
