- 11 Aug, 2017 40 commits
-
-
Mike Manning authored
commit 308453aa upstream. The MAC address of the physical interface is only copied to the VLAN when it is first created, resulting in an inconsistency after MAC address changes of only newly created VLANs having an up-to-date MAC. The VLANs should continue inheriting the MAC address of the physical interface until the VLAN MAC address is explicitly set to any value. This allows IPv6 EUI64 addresses for the VLAN to reflect any changes to the MAC of the physical interface and thus for DAD to behave as expected. Signed-off-by:
Mike Manning <mmanning@brocade.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Phil Reid authored
[ Upstream commit 13288bdf ] Some system have multiple dw devices. Currently the driver uses a fixed name for the debugfs dir. Append dev name to the debugfs dir name to make it unique. Signed-off-by:
Phil Reid <preid@electromag.com.au> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Sasha Levin <alexander.levin@verizon.com> Signed-off-by:
-
Peter Ujfalusi authored
[ Upstream commit 63c3194b ] The RESET register only have one self clearing bit and it should not be cached. If it is cached, when we sync the registers back to the chip we will initiate a software reset as well, which is not desirable. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by:
Jarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 45e86971 ] Using ancient compilers (gcc-4.5 or older) on ARM, we get a link failure with the vfio-pci driver: ERROR: "__aeabi_lcmp" [drivers/vfio/pci/vfio-pci.ko] undefined! The reason is that the compiler tries to do a comparison of a 64-bit range. This changes it to convert to a 32-bit number explicitly first, as newer compilers do for themselves. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Jordan Crouse authored
[ Upstream commit a6cb3b86 ] For every submission buffer object one of MSM_SUBMIT_BO_WRITE and MSM_SUBMIT_BO_READ must be set (and nothing else). If we allowed zero then the buffer object would never get queued to be unreferenced. Signed-off-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
-
Jordan Crouse authored
[ Upstream commit 88b333b0 ] Currently the value written to CP_RB_WPTR is calculated on the fly as (rb->next - rb->start). But as the code is designed rb->next is wrapped before writing the commands so if a series of commands happened to fit perfectly in the ringbuffer, rb->next would end up being equal to rb->size / 4 and thus result in an out of bounds address to CP_RB_WPTR. The easiest way to fix this is to mask WPTR when writing it to the hardware; it makes the hardware happy and the rest of the ringbuffer math appears to work and there isn't any point in upsetting anything. Signed-off-by:
-
Leon Romanovsky authored
[ Upstream commit c1d5f8ff ] This patch removes BUG_ON() macro from mlx4_alloc_icm_coherent() by checking DMA address alignment in advance and performing proper folding in case of error. Fixes: 5b0bf5e2 ("mlx4_core: Support ICM tables in coherent memory") Reported-by:
Ozgur Karatas <okaratas@member.fsf.org> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
-
Zheng Li authored
ipv6: Should use consistent conditional judgement for ip6 fragment between __ip6_append_data and ip6_finish_output [ Upstream commit e4c5e13a ] There is an inconsistent conditional judgement between __ip6_append_data and ip6_finish_output functions, the variable length in __ip6_append_data just include the length of application's payload and udp6 header, don't include the length of ipv6 header, but in ip6_finish_output use (skb->len > ip6_skb_dst_mtu(skb)) as judgement, and skb->len include the length of ipv6 header. That causes some particular application's udp6 payloads whose length are between (MTU - IPv6 Header) and MTU were fragmented by ip6_fragment even though the rst->dev support UFO feature. Add the length of ipv6 header to length in __ip6_append_data to keep consistent conditional judgement as ip6_finish_output for ip6 fragment. Signed-off-by:
Zheng Li <james.z.li@ericsson.com> Signed-off-by:
-
Pali Rohár authored
[ Upstream commit 4cf48f1d ] Trying to initialize eMMC slot as SDIO or SD cause failure in n900 port of qemu. eMMC itself is not detected and is not working. Real Nokia N900 harware does not have this problem. As eMMC is really not SDIO or SD based such change is harmless and will fix support for qemu. Signed-off-by:
Pali Rohár <pali.rohar@gmail.com> Acked-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Chun-Hao Lin authored
[ Upstream commit 610c9087 ] This chip is the same as RTL8168, but its device id is 0x8161. Signed-off-by:
Chun-Hao Lin <hau@realtek.com> Signed-off-by:
-
Thomas Gleixner authored
[ Upstream commit 0dad3a30 ] If mce_device_init() fails then the mce device pointer is NULL and the AMD mce code happily dereferences it. Add a sanity check. Reported-by:
Markus Trippelsdorf <markus@trippelsdorf.de> Reported-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Jarkko Sakkinen authored
commit 13b47cfc upstream. While cleaning up sysfs callback that prints EK we discovered a kernel memory leak. This commit fixes the issue by zeroing the buffer used for TPM command/response. The leak happen when we use either tpm_vtpm_proxy, tpm_ibmvtpm or xen-tpmfront. Cc: stable@vger.kernel.org Fixes: 08837438 ("TPM: sysfs functions consolidation") Reported-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Tested-by:
Stefan Berger <stefanb@linux.vnet.ibm.com> Signed-off-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by:
James Morris <james.l.morris@oracle.com> Signed-off-by:
-
Eric Dumazet authored
commit 6e7bc478 upstream. My recent change missed fact that UFO would perform a complete UDP checksum before segmenting in frags. In this case skb->ip_summed is set to CHECKSUM_NONE. We need to add this valid case to skb_needs_check() Fixes: b2504a5d ("net: reduce skb_warn_bad_offload() noise") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Kees Cook authored
commit e9a330c4 upstream. The per-prz spinlock should be using the dynamic initializer so that lockdep can correctly track it. Without this, under lockdep, we get a warning at boot that the lock is in non-static memory. Fixes: 10970449 ("pstore: Make spinlock per zone instead of global") Fixes: 76d5692a ("pstore: Correctly initialize spinlock and flags") Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Kees Cook authored
commit 76d5692a upstream. The ram backend wasn't always initializing its spinlock correctly. Since it was coming from kzalloc memory, though, it was harmless on architectures that initialize unlocked spinlocks to 0 (at least x86 and ARM). This also fixes a possibly ignored flag setting too. When running under CONFIG_DEBUG_SPINLOCK, the following Oops was visible: [ 0.760836] persistent_ram: found existing buffer, size 29988, start 29988 [ 0.765112] persistent_ram: found existing buffer, size 30105, start 30105 [ 0.769435] persistent_ram: found existing buffer, size 118542, start 118542 [ 0.785960] persistent_ram: found existing buffer, size 0, start 0 [ 0.786098] persistent_ram: found existing buffer, size 0, start 0 [ 0.786131] pstore: using zlib compression [ 0.790716] BUG: spinlock bad magic on CPU#0, swapper/0/1 [ 0.790729] lock: 0xffffffc0d1ca9bb0, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 [ 0.790742] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc2+ #913 [ 0.790747] Hardware name: Google Kevin (DT) [ 0.790750] Call trace: [ 0.790768] [<ffffff900808ae88>] dump_backtrace+0x0/0x2bc [ 0.790780] [<ffffff900808b164>] show_stack+0x20/0x28 [ 0.790794] [<ffffff9008460ee0>] dump_stack+0xa4/0xcc [ 0.790809] [<ffffff9008113cfc>] spin_dump+0xe0/0xf0 [ 0.790821] [<ffffff9008113d3c>] spin_bug+0x30/0x3c [ 0.790834] [<ffffff9008113e28>] do_raw_spin_lock+0x50/0x1b8 [ 0.790846] [<ffffff9008a2d2ec>] _raw_spin_lock_irqsave+0x54/0x6c [ 0.790862] [<ffffff90083ac3b4>] buffer_size_add+0x48/0xcc [ 0.790875] [<ffffff90083acb34>] persistent_ram_write+0x60/0x11c [ 0.790888] [<ffffff90083aab1c>] ramoops_pstore_write_buf+0xd4/0x2a4 [ 0.790900] [<ffffff90083a9d3c>] pstore_console_write+0xf0/0x134 [ 0.790912] [<ffffff900811c304>] console_unlock+0x48c/0x5e8 [ 0.790923] [<ffffff900811da18>] register_console+0x3b0/0x4d4 [ 0.790935] [<ffffff90083aa7d0>] pstore_register+0x1a8/0x234 [ 0.790947] [<ffffff90083ac250>] ramoops_probe+0x6b8/0x7d4 [ 0.790961] [<ffffff90085ca548>] platform_drv_probe+0x7c/0xd0 [ 0.790972] [<ffffff90085c76ac>] driver_probe_device+0x1b4/0x3bc [ 0.790982] [<ffffff90085c7ac8>] __device_attach_driver+0xc8/0xf4 [ 0.790996] [<ffffff90085c4bfc>] bus_for_each_drv+0xb4/0xe4 [ 0.791006] [<ffffff90085c7414>] __device_attach+0xd0/0x158 [ 0.791016] [<ffffff90085c7b18>] device_initial_probe+0x24/0x30 [ 0.791026] [<ffffff90085c648c>] bus_probe_device+0x50/0xe4 [ 0.791038] [<ffffff90085c35b8>] device_add+0x3a4/0x76c [ 0.791051] [<ffffff90087d0e84>] of_device_add+0x74/0x84 [ 0.791062] [<ffffff90087d19b8>] of_platform_device_create_pdata+0xc0/0x100 [ 0.791073] [<ffffff90087d1a2c>] of_platform_device_create+0x34/0x40 [ 0.791086] [<ffffff900903c910>] of_platform_default_populate_init+0x58/0x78 [ 0.791097] [<ffffff90080831fc>] do_one_initcall+0x88/0x160 [ 0.791109] [<ffffff90090010ac>] kernel_init_freeable+0x264/0x31c [ 0.791123] [<ffffff9008a25bd0>] kernel_init+0x18/0x11c [ 0.791133] [<ffffff9008082ec0>] ret_from_fork+0x10/0x50 [ 0.793717] console [pstore-1] enabled [ 0.797845] pstore: Registered ramoops as persistent store backend [ 0.804647] ramoops: attached 0x100000@0xf7edc000, ecc: 0/0 Fixes: 663deb47 ("pstore: Allow prz to control need for locking") Fixes: 10970449 ("pstore: Make spinlock per zone instead of global") Reported-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Joel Fernandes authored
commit 663deb47 upstream. In preparation of not locking at all for certain buffers depending on if there's contention, make locking optional depending on the initialization of the prz. Signed-off-by:
Joel Fernandes <joelaf@google.com> [kees: moved locking flag into prz instead of via caller arguments] Signed-off-by:
-
Andrzej Hajda authored
commit a2370ba2 upstream. Bool values should be negated using logical operators. Using bitwise operators results in unexpected and possibly incorrect results. Reported-by:
David Binderman <dcb314@hotmail.com> Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Al Viro authored
commit 49d31c2f upstream. take_dentry_name_snapshot() takes a safe snapshot of dentry name; if the name is a short one, it gets copied into caller-supplied structure, otherwise an extra reference to external name is grabbed (those are never modified). In either case the pointer to stable string is stored into the same structure. dentry must be held by the caller of take_dentry_name_snapshot(), but may be freely dropped afterwards - the snapshot will stay until destroyed by release_dentry_name_snapshot(). Intended use: struct name_snapshot s; take_dentry_name_snapshot(&s, dentry); ... access s.name ... release_dentry_name_snapshot(&s); Replaces fsnotify_oldname_...(), gets used in fsnotify to obtain the name to pass down with event. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Valentin Vidic authored
commit 860f01e9 upstream. systemd by default starts watchdog on reboot and sets the timer to ShutdownWatchdogSec=10min. Reboot handler in ipmi_watchdog than reduces the timer to 120s which is not enough time to boot a Xen machine with a lot of RAM. As a result the machine is rebooted the second time during the long run of (XEN) Scrubbing Free RAM..... Fix this by setting the timer to 120s only if it was previously set to a low value. Signed-off-by:
Valentin Vidic <Valentin.Vidic@CARNet.hr> Signed-off-by:
Corey Minyard <cminyard@mvista.com> Signed-off-by:
-
Daniel Borkmann authored
commit 628185cf upstream. Shahar reported a soft lockup in tc_classify(), where we run into an endless loop when walking the classifier chain due to tp->next == tp which is a state we should never run into. The issue only seems to trigger under load in the tc control path. What happens is that in tc_ctl_tfilter(), thread A allocates a new tp, initializes it, sets tp_created to 1, and calls into tp->ops->change() with it. In that classifier callback we had to unlock/lock the rtnl mutex and returned with -EAGAIN. One reason why we need to drop there is, for example, that we need to request an action module to be loaded. This happens via tcf_exts_validate() -> tcf_action_init/_1() meaning after we loaded and found the requested action, we need to redo the whole request so we don't race against others. While we had to unlock rtnl in that time, thread B's request was processed next on that CPU. Thread B added a new tp instance successfully to the classifier chain. When thread A returned grabbing the rtnl mutex again, propagating -EAGAIN and destroying its tp instance which never got linked, we goto replay and redo A's request. This time when walking the classifier chain in tc_ctl_tfilter() for checking for existing tp instances we had a priority match and found the tp instance that was created and linked by thread B. Now calling again into tp->ops->change() with that tp was successful and returned without error. tp_created was never cleared in the second round, thus kernel thinks that we need to link it into the classifier chain (once again). tp and *back point to the same object due to the match we had earlier on. Thus for thread B's already public tp, we reset tp->next to tp itself and link it into the chain, which eventually causes the mentioned endless loop in tc_classify() once a packet hits the data path. Fix is to clear tp_created at the beginning of each request, also when we replay it. On the paths that can cause -EAGAIN we already destroy the original tp instance we had and on replay we really need to start from scratch. It seems that this issue was first introduced in commit 12186be7 ("net_cls: fix unconfigured struct tcf_proto keeps chaining and avoid kernel panic when we use cls_cgroup"). Fixes: 12186be7 ("net_cls: fix unconfigured struct tcf_proto keeps chaining and avoid kernel panic when we use cls_cgroup") Reported-by:
Shahar Klein <shahark@mellanox.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Cc: Cong Wang <xiyou.wangcong@gmail.com> Acked-by:
Amit Pundir <amit.pundir@linaro.org> Signed-off-by:
-
Ben Hutchings authored
commit 4f9dce23 upstream. The driver connects and disconnects the PHY device whenever the net device is brought up and down. The ethtool get_settings, set_settings and nway_reset operations will dereference a null or dangling pointer if called while it is down. I think it would be preferable to keep the PHY connected, but there may be good reasons not to. As an immediate fix for this bug: - Set the phydev pointer to NULL after disconnecting the PHY - Change those three operations to return -ENODEV while the PHY is not connected Signed-off-by:
Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
-
Daniel Borkmann authored
commit 2061dcd6 upstream. I.e. one-to-many sockets in SCTP are not required to explicitly call into connect(2) or sctp_connectx(2) prior to data exchange. Instead, they can directly invoke sendmsg(2) and the SCTP stack will automatically trigger connection establishment through 4WHS via sctp_primitive_ASSOCIATE(). However, this in its current implementation is racy: INIT is being sent out immediately (as it cannot be bundled anyway) and the rest of the DATA chunks are queued up for later xmit when connection is established, meaning sendmsg(2) will return successfully. This behaviour can result in an undesired side-effect that the kernel made the application think the data has already been transmitted, although none of it has actually left the machine, worst case even after close(2)'ing the socket. Instead, when the association from client side has been shut down e.g. first gracefully through SCTP_EOF and then close(2), the client could afterwards still receive the server's INIT_ACK due to a connection with higher latency. This INIT_ACK is then considered out of the blue and hence responded with ABORT as there was no alive assoc found anymore. This can be easily reproduced f.e. with sctp_test application from lksctp. One way to fix this race is to wait for the handshake to actually complete. The fix defers waiting after sctp_primitive_ASSOCIATE() and sctp_primitive_SEND() succeeded, so that DATA chunks cooked up from sctp_sendmsg() have already been placed into the output queue through the side-effect interpreter, and therefore can then be bundeled together with COOKIE_ECHO control chunks. strace from example application (shortened): socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP) = 3 sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")}, msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5 sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")}, msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5 sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")}, msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5 sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")}, msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5 sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")}, msg_iov(0)=[], msg_controllen=48, {cmsg_len=48, cmsg_level=0x84 /* SOL_??? */, cmsg_type=, ...}, msg_flags=0}, 0) = 0 // graceful shutdown for SOCK_SEQPACKET via SCTP_EOF close(3) = 0 tcpdump before patch (fooling the application): 22:33:36.306142 IP 192.168.1.114.41462 > 192.168.1.115.8888: sctp (1) [INIT] [init tag: 3879023686] [rwnd: 106496] [OS: 10] [MIS: 65535] [init TSN: 3139201684] 22:33:36.316619 IP 192.168.1.115.8888 > 192.168.1.114.41462: sctp (1) [INIT ACK] [init tag: 3345394793] [rwnd: 106496] [OS: 10] [MIS: 10] [init TSN: 3380109591] 22:33:36.317600 IP 192.168.1.114.41462 > 192.168.1.115.8888: sctp (1) [ABORT] tcpdump after patch: 14:28:58.884116 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [INIT] [init tag: 438593213] [rwnd: 106496] [OS: 10] [MIS: 65535] [init TSN: 3092969729] 14:28:58.888414 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [INIT ACK] [init tag: 381429855] [rwnd: 106496] [OS: 10] [MIS: 10] [init TSN: 2141904492] 14:28:58.888638 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [COOKIE ECHO] , (2) [DATA] (B)(E) [TSN: 3092969729] [...] 14:28:58.893278 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [COOKIE ACK] , (2) [SACK] [cum ack 3092969729] [a_rwnd 106491] [#gap acks 0] [#dup tsns 0] 14:28:58.893591 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [DATA] (B)(E) [TSN: 3092969730] [...] 14:28:59.096963 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SACK] [cum ack 3092969730] [a_rwnd 106496] [#gap acks 0] [#dup tsns 0] 14:28:59.097086 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [DATA] (B)(E) [TSN: 3092969731] [...] , (2) [DATA] (B)(E) [TSN: 3092969732] [...] 14:28:59.103218 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SACK] [cum ack 3092969732] [a_rwnd 106486] [#gap acks 0] [#dup tsns 0] 14:28:59.103330 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [SHUTDOWN] 14:28:59.107793 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SHUTDOWN ACK] 14:28:59.107890 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [SHUTDOWN COMPLETE] Looks like this bug is from the pre-git history museum. ;) Fixes: 08707d54 ("lksctp-2_5_31-0_5_1.patch") Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Acked-by:
Vlad Yasevich <vyasevich@gmail.com> Signed-off-by:
-
Jan Stancek authored
commit 4762fb98 upstream. Use spin_lock_bh in ip6_fl_purge() to prevent following potentially deadlock scenario between ip6_fl_purge() and ip6_fl_gc() timer. ================================= [ INFO: inconsistent lock state ] 3.19.0 #1 Not tainted --------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. swapper/5/0 [HC0[0]:SC1[1]:HE1:SE0] takes: (ip6_fl_lock){+.?...}, at: [<ffffffff8171155d>] ip6_fl_gc+0x2d/0x180 {SOFTIRQ-ON-W} state was registered at: [<ffffffff810ee9a0>] __lock_acquire+0x4a0/0x10b0 [<ffffffff810efd54>] lock_acquire+0xc4/0x2b0 [<ffffffff81751d2d>] _raw_spin_lock+0x3d/0x80 [<ffffffff81711798>] ip6_flowlabel_net_exit+0x28/0x110 [<ffffffff815f9759>] ops_exit_list.isra.1+0x39/0x60 [<ffffffff815fa320>] cleanup_net+0x100/0x1e0 [<ffffffff810ad80a>] process_one_work+0x20a/0x830 [<ffffffff810adf4b>] worker_thread+0x11b/0x460 [<ffffffff810b42f4>] kthread+0x104/0x120 [<ffffffff81752bfc>] ret_from_fork+0x7c/0xb0 irq event stamp: 84640 hardirqs last enabled at (84640): [<ffffffff81752080>] _raw_spin_unlock_irq+0x30/0x50 hardirqs last disabled at (84639): [<ffffffff81751eff>] _raw_spin_lock_irq+0x1f/0x80 softirqs last enabled at (84628): [<ffffffff81091ad1>] _local_bh_enable+0x21/0x50 softirqs last disabled at (84629): [<ffffffff81093b7d>] irq_exit+0x12d/0x150 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(ip6_fl_lock); <Interrupt> lock(ip6_fl_lock); *** DEADLOCK *** Signed-off-by:
Jan Stancek <jstancek@redhat.com> Signed-off-by:
-
Oliver Neukum authored
commit 575ced7f upstream. Just return an error upon failure. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Signed-off-by:
-
Oliver Neukum authored
commit 60bcabd0 upstream. This fixes the oops discovered by the Umap2 project and Alan Stern. The intf member needs to be set before the firmware is downloaded. Signed-off-by:
-
Calvin Owens authored
commit 5ec8a175 upstream. In _base_make_ioc_operational(), we walk ioc->reply_queue_list and pull a pointer out of successive elements of ioc->reply_post[] for each entry in that list if RDPQ is enabled. Since the code pulls the pointer for the next iteration at the bottom of the loop, it triggers the a KASAN dump on the final iteration: BUG: KASAN: slab-out-of-bounds in _base_make_ioc_operational+0x47b7/0x47e0 [mpt3sas] at addr ffff880754816ab0 Read of size 8 by task modprobe/305 <snip> Call Trace: [<ffffffff81dfc591>] dump_stack+0x4d/0x6c [<ffffffff814c9689>] print_trailer+0xf9/0x150 [<ffffffff814ceda4>] object_err+0x34/0x40 [<ffffffff814d1231>] kasan_report_error+0x221/0x530 [<ffffffff814d1673>] __asan_report_load8_noabort+0x43/0x50 [<ffffffffa0043637>] _base_make_ioc_operational+0x47b7/0x47e0 [mpt3sas] [<ffffffffa0049a51>] mpt3sas_base_attach+0x1991/0x2120 [mpt3sas] [<ffffffffa0053c93>] _scsih_probe+0xeb3/0x16b0 [mpt3sas] [<ffffffff81ebd047>] local_pci_probe+0xc7/0x170 [<ffffffff81ebf2cf>] pci_device_probe+0x20f/0x290 [<ffffffff820d50cd>] really_probe+0x17d/0x600 [<ffffffff820d56a3>] __driver_attach+0x153/0x190 [<ffffffff820cffac>] bus_for_each_dev+0x11c/0x1a0 [<ffffffff820d421d>] driver_attach+0x3d/0x50 [<ffffffff820d378a>] bus_add_driver+0x44a/0x5f0 [<ffffffff820d666c>] driver_register+0x18c/0x3b0 [<ffffffff81ebcb76>] __pci_register_driver+0x156/0x200 [<ffffffffa00c8135>] _mpt3sas_init+0x135/0x1000 [mpt3sas] [<ffffffff81000423>] do_one_initcall+0x113/0x2b0 [<ffffffff813caa5a>] do_init_module+0x1d0/0x4d8 [<ffffffff81273909>] load_module+0x6729/0x8dc0 [<ffffffff81276123>] SYSC_init_module+0x183/0x1a0 [<ffffffff8127625e>] SyS_init_module+0xe/0x10 [<ffffffff828fe7d7>] entry_SYSCALL_64_fastpath+0x12/0x6a Fix this by pulling the value at the beginning of the loop. Signed-off-by:
Calvin Owens <calvinowens@fb.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by:
Jens Axboe <axboe@fb.com> Acked-by:
Chaitra Basappa <chaitra.basappa@broadcom.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Sudeep Holla authored
commit cb710ab1 upstream. We already check if the message is empty before calling the client tx_done callback. Calling completion on a wait event is also invalid if the message is empty. This patch moves the existing empty message check earlier. Fixes: 2b6d83e2 ("mailbox: Introduce framework for mailbox") Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Signed-off-by:
Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by:
-
Sudeep Holla authored
commit cc6eeaa3 upstream. If a wait_for_completion_timeout() call returns due to a timeout, complete() can get called after returning from the wait which is incorrect and can cause subsequent transmissions on a channel to fail. Since the wait_for_completion_timeout() sees the completion variable is non-zero caused by the erroneous/spurious complete() call, and it immediately returns without waiting for the time as expected by the client. This patch fixes the issue by skipping complete() call for the timer expiry. Fixes: 2b6d83e2 ("mailbox: Introduce framework for mailbox") Reported-by:
Alexey Klimov <alexey.klimov@arm.com> Signed-off-by:
-
Sudeep Holla authored
commit c61b781e upstream. There exists a race when msg_submit return immediately as there was an active request being processed which may have completed just before it's checked again in mbox_send_message. This will result in return to the caller without waiting in mbox_send_message even when it's blocking Tx. This patch fixes the issue by waiting for the completion always if Tx is in blocking mode. Fixes: 2b6d83e2 ("mailbox: Introduce framework for mailbox") Reported-by:
-
Lior David authored
commit dfb5b098 upstream. When FW crashes with no_fw_recovery option, driver waits for manual recovery with wil->mutex held, this can easily create deadlocks. Fix the problem by moving the wait outside the lock. Signed-off-by:
Lior David <qca_liord@qca.qualcomm.com> Signed-off-by:
Maya Erez <qca_merez@qca.qualcomm.com> Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
-
Annie Cherkaev authored
commit 9f5af546 upstream. This fixes a potential buffer overflow in isdn_net.c caused by an unbounded strcpy. [ ISDN seems to be effectively unmaintained, and the I4L driver in particular is long deprecated, but in case somebody uses this.. - Linus ] Signed-off-by:
Jiten Thakkar <jitenmt@gmail.com> Signed-off-by:
Annie Cherkaev <annie.cherk@gmail.com> Cc: Karsten Keil <isdn@linux-pingi.de> Cc: Kees Cook <keescook@chromium.org> Signed-off-by:
-
Chris Metcalf authored
commit 990486c8 upstream. It's possible that the destination can be shadowed in userspace (as, for example, the perf buffers are now). So we should take care not to leak data that could be inspected by userspace. Signed-off-by:
Chris Metcalf <cmetcalf@ezchip.com> Signed-off-by:
-
Chris Metcalf authored
commit 30035e45 upstream. The strscpy() API is intended to be used instead of strlcpy(), and instead of most uses of strncpy(). - Unlike strlcpy(), it doesn't read from memory beyond (src + size). - Unlike strlcpy() or strncpy(), the API provides an easy way to check for destination buffer overflow: an -E2BIG error return value. - The provided implementation is robust in the face of the source buffer being asynchronously changed during the copy, unlike the current implementation of strlcpy(). - Unlike strncpy(), the destination buffer will be NUL-terminated if the string in the source buffer is too long. - Also unlike strncpy(), the destination buffer will not be updated beyond the NUL termination, avoiding strncpy's behavior of zeroing the entire tail end of the destination buffer. (A memset() after the strscpy() can be used if this behavior is desired.) - The implementation should be reasonably performant on all platforms since it uses the asm/word-at-a-time.h API rather than simple byte copy. Kernel-to-kernel string copy is not considered to be performance critical in any case. Signed-off-by:
-
Jia-Ju Bai authored
commit e8f4ae85 upstream. The driver may sleep under a spin lock, the function call path is: isdn_ppp_mp_receive (acquire the lock) isdn_ppp_mp_reassembly isdn_ppp_push_higher isdn_ppp_decompress isdn_ppp_ccp_reset_trans isdn_ppp_ccp_reset_alloc_state kzalloc(GFP_KERNEL) --> may sleep To fixed it, the "GFP_KERNEL" is replaced with "GFP_ATOMIC". Signed-off-by:
Jia-Ju Bai <baijiaju1990@163.com> Signed-off-by:
-
Florian Fainelli authored
commit 0878fff1 upstream. The Generic PHY driver is a catch-all PHY driver and it should preserve whatever prior initialization has been done by boot loader or firmware agents. For specific PHY device configuration it is expected that a specialized PHY driver would take over that role. Resetting the generic PHY was a bad idea that has lead to several complaints and downstream workarounds e.g: in OpenWrt/LEDE so restore the behavior prior to 87aa9f9c ("net: phy: consolidate PHY reset in phy_init_hw()"). Reported-by:
Felix Fietkau <nbd@nbd.name> Fixes: 87aa9f9c ("net: phy: consolidate PHY reset in phy_init_hw()") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Al Viro authored
commit 96c26653 upstream. ... rather than relying on ciptool(8) never passing it anything else. Give it e.g. an AF_UNIX connected socket (from socketpair(2)) and it'll oops, trying to evaluate &l2cap_pi(sock->sk)->chan->dst... Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Johan Hedberg authored
commit 88d9077c upstream. The bnep_get_device function may be triggered by an ioctl just after a connection has gone down. In such a case the respective L2CAP chan->conn pointer will get set to NULL (by l2cap_chan_del). This patch adds a missing NULL check for this case in the bnep_get_device() function. Reported-by:
Patrik Flykt <patrik.flykt@linux.intel.com> Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
-
Al Viro authored
commit 71bb99a0 upstream. same story as cmtp Signed-off-by:
-
Cheah Kok Cheong authored
commit bf279ece upstream. Move comedi_proc_init to the end to avoid orphaned proc entry if module loading failed. Signed-off-by:
Cheah Kok Cheong <thrust73@gmail.com> Reviewed-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 138bb148 which is commit ba4a648f upstream. Michal Hocko writes: JFYI. We have encountered a regression after applying this patch on a large ppc machine. While the patch is the right thing to do it doesn't work well with the current vmalloc area size on ppc and large machines where NUMA nodes are very far from each other. Just for the reference the boot fails on such a machine with bunch of warning preceeding it. See http://lkml.kernel.org/r/20170724134240.GL25221@dhcp22.suse.cz It seems the right thing to do is to enlarge the vmalloc space on ppc but this is not the case in the upstream kernel yet AFAIK. It is also questionable whether that is a stable material but I will decision on you here. We have reverted this patch from our 4.4 based kernel. Newer kernels do not have enlarged vmalloc space yet AFAIK so they won't work properly eiter. This bug is quite rare though because you need a specific HW configuration to trigger the issue - namely NUMA nodes have to be far away from each other in the physical memory space. Cc: Michal Hocko <mhocko@kernel.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
-
