- 04 Jun, 2019 8 commits
-
-
Eric Dumazet authored
[ Upstream commit 8fb44d60 ] If llc_mac_hdr_init() returns an error, we must drop the skb since no llc_build_and_send_ui_pkt() caller will take care of this. BUG: memory leak unreferenced object 0xffff8881202b6800 (size 2048): comm "syz-executor907", pid 7074, jiffies 4294943781 (age 8.590s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 1a 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<00000000e25b5abe>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] [<00000000e25b5abe>] slab_post_alloc_hook mm/slab.h:439 [inline] [<00000000e25b5abe>] slab_alloc mm/slab.c:3326 [inline] [<00000000e25b5abe>] __do_kmalloc mm/slab.c:3658 [inline] [<00000000e25b5abe>] __kmalloc+0x161/0x2c0 mm/slab.c:3669 [<00000000a1ae188a>] kmalloc include/linux/slab.h:552 [inline] [<00000000a1ae188a>] sk_prot_alloc+0xd6/0x170 net/core/sock.c:1608 [<00000000ded25bbe>] sk_alloc+0x35/0x2f0 net/core/sock.c:1662 [<000000002ecae075>] llc_sk_alloc+0x35/0x170 net/llc/llc_conn.c:950 [<00000000551f7c47>] llc_ui_create+0x7b/0x140 net/llc/af_llc.c:173 [<0000000029027f0e>] __sock_create+0x164/0x250 net/socket.c:1430 [<000000008bdec225>] sock_create net/socket.c:1481 [inline] [<000000008bdec225>] __sys_socket+0x69/0x110 net/socket.c:1523 [<00000000b6439228>] __do_sys_socket net/socket.c:1532 [inline] [<00000000b6439228>] __se_sys_socket net/socket.c:1530 [inline] [<00000000b6439228>] __x64_sys_socket+0x1e/0x30 net/socket.c:1530 [<00000000cec820c1>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301 [<000000000c32554f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 BUG: memory leak unreferenced object 0xffff88811d750d00 (size 224): comm "syz-executor907", pid 7074, jiffies 4294943781 (age 8.600s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 f0 0c 24 81 88 ff ff 00 68 2b 20 81 88 ff ff ...$.....h+ .... backtrace: [<0000000053026172>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] [<0000000053026172>] slab_post_alloc_hook mm/slab.h:439 [inline] [<0000000053026172>] slab_alloc_node mm/slab.c:3269 [inline] [<0000000053026172>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579 [<00000000fa8f3c30>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:198 [<00000000d96fdafb>] alloc_skb include/linux/skbuff.h:1058 [inline] [<00000000d96fdafb>] alloc_skb_with_frags+0x5f/0x250 net/core/skbuff.c:5327 [<000000000a34a2e7>] sock_alloc_send_pskb+0x269/0x2a0 net/core/sock.c:2225 [<00000000ee39999b>] sock_alloc_send_skb+0x32/0x40 net/core/sock.c:2242 [<00000000e034d810>] llc_ui_sendmsg+0x10a/0x540 net/llc/af_llc.c:933 [<00000000c0bc8445>] sock_sendmsg_nosec net/socket.c:652 [inline] [<00000000c0bc8445>] sock_sendmsg+0x54/0x70 net/socket.c:671 [<000000003b687167>] __sys_sendto+0x148/0x1f0 net/socket.c:1964 [<00000000922d78d9>] __do_sys_sendto net/socket.c:1976 [inline] [<00000000922d78d9>] __se_sys_sendto net/socket.c:1972 [inline] [<00000000922d78d9>] __x64_sys_sendto+0x2a/0x30 net/socket.c:1972 [<00000000cec820c1>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301 [<000000000c32554f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
David Ahern authored
[ Upstream commit 31680ac2 ] IPv6 redirect is broken for VRF. __ip6_route_redirect walks the FIB entries looking for an exact match on ifindex. With VRF the flowi6_oif is updated by l3mdev_update_flow to the l3mdev index and the FLOWI_FLAG_SKIP_NH_OIF set in the flags to tell the lookup to skip the device match. For redirects the device match is requires so use that flag to know when the oif needs to be reset to the skb device index. Fixes: ca254490 ("net: Add VRF support to IPv6 stack") Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Mike Manning authored
[ Upstream commit 72f7cfab ] IPv6 does not consider if the socket is bound to a device when binding to an address. The result is that a socket can be bound to eth0 and then bound to the address of eth1. If the device is a VRF, the result is that a socket can only be bound to an address in the default VRF. Resolve by considering the device if sk_bound_dev_if is set. Signed-off-by:
Mike Manning <mmanning@vyatta.att-mail.com> Reviewed-by:
-
Eric Dumazet authored
[ Upstream commit 903869bd ] ip_sf_list_clear_all() needs to be defined even if !CONFIG_IP_MULTICAST Fixes: 3580d04a ("ipv4/igmp: fix another memory leak in igmpv3_del_delrec()") Signed-off-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 3580d04a ] syzbot reported memory leaks [1] that I have back tracked to a missing cleanup from igmpv3_del_delrec() when (im->sfmode != MCAST_INCLUDE) Add ip_sf_list_clear_all() and kfree_pmc() helpers to explicitely handle the cleanups before freeing. [1] BUG: memory leak unreferenced object 0xffff888123e32b00 (size 64): comm "softirq", pid 0, jiffies 4294942968 (age 8.010s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 e0 00 00 01 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000006105011b>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] [<000000006105011b>] slab_post_alloc_hook mm/slab.h:439 [inline] [<000000006105011b>] slab_alloc mm/slab.c:3326 [inline] [<000000006105011b>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 [<000000004bba8073>] kmalloc include/linux/slab.h:547 [inline] [<000000004bba8073>] kzalloc include/linux/slab.h:742 [inline] [<000000004bba8073>] ip_mc_add1_src net/ipv4/igmp.c:1961 [inline] [<000000004bba8073>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2085 [<00000000a46a65a0>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2475 [<000000005956ca89>] do_ip_setsockopt.isra.0+0x1795/0x1930 net/ipv4/ip_sockglue.c:957 [<00000000848e2d2f>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1246 [<00000000b9db185c>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2616 [<000000003028e438>] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3130 [<0000000015b65589>] __sys_setsockopt+0x98/0x120 net/socket.c:2078 [<00000000ac198ef0>] __do_sys_setsockopt net/socket.c:2089 [inline] [<00000000ac198ef0>] __se_sys_setsockopt net/socket.c:2086 [inline] [<00000000ac198ef0>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086 [<000000000a770437>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301 [<00000000d3adb93b>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 9c8bb163 ("igmp, mld: Fix memory leak in igmpv3/mld_del_delrec()") Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit df453700 ] According to Amit Klein and Benny Pinkas, IP ID generation is too weak and might be used by attackers. Even with recent net_hash_mix() fix (netns: provide pure entropy for net_hash_mix()) having 64bit key and Jenkins hash is risky. It is time to switch to siphash and its 128bit keys. Signed-off-by:
Amit Klein <aksecurity@gmail.com> Reported-by:
Benny Pinkas <benny@pinkas.net> Signed-off-by:
-
Raju Rangoju authored
[ Upstream commit b5730061 ] VLAN flows never get offloaded unless ivlan_vld is set in filter spec. It's not compulsory for vlan_ethtype to be set. So, always enable ivlan_vld bit for offloading VLAN flows regardless of vlan_ethtype is set or not. Fixes: ad9af3e0 (cxgb4: add tc flower match support for vlan) Signed-off-by:
Raju Rangoju <rajur@chelsio.com> Signed-off-by:
-
Jarod Wilson authored
[ Upstream commit 33403121 ] Once in a while, with just the right timing, 802.3ad slaves will fail to properly initialize, winding up in a weird state, with a partner system mac address of 00:00:00:00:00:00. This started happening after a fix to properly track link_failure_count tracking, where an 802.3ad slave that reported itself as link up in the miimon code, but wasn't able to get a valid speed/duplex, started getting set to BOND_LINK_FAIL instead of BOND_LINK_DOWN. That was the proper thing to do for the general "my link went down" case, but has created a link initialization race that can put the interface in this odd state. The simple fix is to instead set the slave link to BOND_LINK_DOWN again, if the link has never been up (last_link_up == 0), so the link state doesn't bounce from BOND_LINK_DOWN to BOND_LINK_FAIL -- it hasn't failed in this case, it simply hasn't been up yet, and this prevents the unnecessary state change from DOWN to FAIL and getting stuck in an init failure w/o a partner mac. Fixes: ea53abfa ("bonding/802.3ad: fix link_failure_count tracking") CC: Jay Vosburgh <j.vosburgh@gmail.com> CC: Veaceslav Falico <vfalico@gmail.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: "David S. Miller" <davem@davemloft.net> CC: netdev@vger.kernel.org Tested-by:
Heesoon Kim <Heesoon.Kim@stratus.com> Signed-off-by:
Jarod Wilson <jarod@redhat.com> Acked-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by:
-
- 31 May, 2019 32 commits
-
-
Greg Kroah-Hartman authored
-
Benjamin Coddington authored
[ Upstream commit c260121a ] Now that nfs_match_client drops the nfs_client_lock, we should be careful to always return it in the same condition: locked. Fixes: 950a578c ("NFS: make nfs_match_client killable") Reported-by: syzbot+228a82b263b5da91883d@syzkaller.appspotmail.com Signed-off-by:
Benjamin Coddington <bcodding@redhat.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Maxime Ripard authored
[ Upstream commit efa31801 ] The Allwinner BSP makes sure that we don't end up with a null start delay or with a delay larger than vtotal. The former condition is likely to happen now with the reworked start delay, so make sure we enforce the same boundaries. Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Reviewed-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/c9889cf5f7a3d101ef380905900b45a182596f56.1549896081.git-series.maxime.ripard@bootlin.comSigned-off-by:
-
Farhan Ali authored
[ Upstream commit d1ffa760 ] The quiesce function calls cio_cancel_halt_clear() and if we get an -EBUSY we go into a loop where we: - wait for any interrupts - flush all I/O in the workqueue - retry cio_cancel_halt_clear During the period where we are waiting for interrupts or flushing all I/O, the channel subsystem could have completed a halt/clear action and turned off the corresponding activity control bits in the subchannel status word. This means the next time we call cio_cancel_halt_clear(), we will again start by calling cancel subchannel and so we can be stuck between calling cancel and halt forever. Rather than calling cio_cancel_halt_clear() immediately after waiting, let's try to disable the subchannel. If we succeed in disabling the subchannel then we know nothing else can happen with the device. Suggested-by:
Eric Farman <farman@linux.ibm.com> Signed-off-by:
Farhan Ali <alifm@linux.ibm.com> Message-Id: <4d5a4b98ab1b41ac6131b5c36de18b76c5d66898.1555449329.git.alifm@linux.ibm.com> Reviewed-by:
Halil Pasic <pasic@linux.ibm.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
-
Maxime Ripard authored
[ Upstream commit da676c6a ] The current calculation for the video start delay in the current DSI driver is that it is the total vertical size, minus the front porch and sync length, plus 1. This equals to the active vertical size plus the back porch plus 1. That 1 is coming in the Allwinner BSP from an variable that is set to 1. However, if we look at the Allwinner BSP more closely, and especially in the "legacy" code for the display (in drivers/video/sunxi/legacy/), we can see that this variable is actually computed from the porches and the sync minus 10, clamped between 8 and 100. This fixes the start delay symptom we've seen on some panels (vblank timeouts with vertical white stripes at the bottom of the panel). Reviewed-by:
-
Chris Wilson authored
[ Upstream commit 60b80199 ] After an event is sent, we try to copy it into the user buffer of the first waiter in drm_read() and if the user buffer doesn't have enough room we put it back onto the list. However, we didn't wake up any subsequent waiter, so that event may sit on the list until either a new vblank event is sent or a new waiter appears. Rare, but in the worst case may lead to a stuck process. Testcase: igt/drm_read/short-buffer-wakeup Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170804082328.17173-1-chris@chris-wilson.co.ukSigned-off-by:
-
Noralf Trønnes authored
[ Upstream commit 56be6503 ] This makes it safe to access drm_device->dev after the parent device has been removed/unplugged. Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190225144232.20761-2-noralf@tronnes.orgSigned-off-by:
-
Eric Anholt authored
[ Upstream commit fc227715 ] Noted in review by Dave Emett for V3D 4.2 support. Signed-off-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190308174336.7866-1-eric@anholt.netReviewed-by:
Dave Emett <david.emett@broadcom.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 8ca51047 ] Building with clang shows a variable that is only used by the suspend/resume functions but defined outside of their #ifdef block: sound/soc/ti/davinci-mcasp.c:48:12: error: variable 'context_regs' is not needed and will not be emitted We commonly fix these by marking the PM functions as __maybe_unused, but here that would grow the davinci_mcasp structure, so instead add another #ifdef here. Fixes: 1cc0c054 ("ASoC: davinci-mcasp: Convert the context save/restore to use array") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Chris Lesiak authored
[ Upstream commit 5442dcaa ] This fixes a bug for messages containing both zero length and unidirectional xfers. The function spi_map_msg will allocate dummy tx and/or rx buffers for use with unidirectional transfers when the hardware can only do a bidirectional transfer. That dummy buffer will be used in place of a NULL buffer even when the xfer length is 0. Then in the function __spi_map_msg, if he hardware can dma, the zero length xfer will have spi_map_buf called on the dummy buffer. Eventually, __sg_alloc_table is called and returns -EINVAL because nents == 0. This fix prevents the error by not using the dummy buffer when the xfer length is zero. Signed-off-by:
Chris Lesiak <chris.lesiak@licor.com> Signed-off-by:
-
Trent Piepho authored
[ Upstream commit c842749e ] Commit 71abd290 ("spi: imx: Add support for SPI Slave mode") added an RX FIFO flush before start of a transfer. In slave mode, the master may have sent more data than expected and this data will still be in the RX FIFO at the start of the next transfer, and so needs to be flushed. However, the code to do the flush was accidentally saving this data into the previous transfer's RX buffer, clobbering the contents of whatever followed that buffer. Change it to empty the FIFO and throw away the data. Every one of the RX functions for the different eCSPI versions and modes reads the RX FIFO data using the same readl() call, so just use that, rather than using the spi_imx->rx function pointer and making sure all the different rx functions have a working "throw away" mode. There is another issue, which affects master mode when switching from DMA to PIO. There can be extra data in the RX FIFO which triggers this flush code, causing memory corruption in the same manner. I don't know why this data is unexpectedly in the FIFO. It's likely there is a different bug or erratum responsible for that. But regardless of that, I think this is proper fix the for bug at hand here. Fixes: 71abd290 ("spi: imx: Add support for SPI Slave mode") Cc: Jiada Wang <jiada_wang@mentor.com> Cc: Fabio Estevam <festevam@gmail.com> Cc: Stefan Agner <stefan@agner.ch> Cc: Shawn Guo <shawnguo@kernel.org> Signed-off-by:
Trent Piepho <tpiepho@impinj.com> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 26843bb1 ] While the sequencer is reset after each SPI message since commit 880c6d11 ("spi: rspi: Add support for Quad and Dual SPI Transfers on QSPI"), it was never reset for the first message, thus relying on reset state or bootloader settings. Fix this by initializing it explicitly during configuration. Fixes: 0b2182dd ("spi: add support for Renesas RSPI") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit fe4ed1b4 ] Currently dsi_display_init_dsi() calls dss_pll_enable() but it is not paired with dss_pll_disable() in dsi_display_uninit_dsi(). This leaves the DSS clocks enabled when the display is blanked wasting about extra 5mW of power while idle. The clock that is left on by not calling dss_pll_disable() is DSS_CLKCTRL bit 10 OPTFCLKEN_SYS_CLK that is the source clock for DSI PLL. We can fix this issue by by making the current dsi_pll_uninit() into dsi_pll_disable(). This way we can just call dss_pll_disable() from dsi_display_uninit_dsi() and the code becomes a bit easier to follow. However, we need to also consider that DSI PLL can be muxed for DVI too as pointed out by Tomi Valkeinen <tomi.valkeinen@ti.com>. In the DVI case, we want to unconditionally disable the clocks. To get around this issue, we separate out the DSI lane handling from dsi_pll_enable() and dsi_pll_disable() as suggested by Tomi in an earlier experimental patch. So we must only toggle the DSI regulator based on the vdds_dsi_enabled flag from dsi_display_init_dsi() and dsi_display_uninit_dsi(). We need to make these two changes together to avoid breaking things for DVI when fixing the DSI clock handling. And this all causes a slight renumbering of the error path for dsi_display_init_dsi(). Suggested-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Aditya Pakki authored
[ Upstream commit f37d8e67 ] pch_alloc_dma_buf allocated tx, rx DMA buffers which can fail. Further, these buffers are used without a check. The patch checks for these failures and sends the error upstream. Signed-off-by:
Aditya Pakki <pakki001@umn.edu> Signed-off-by:
-
James Smart authored
[ Upstream commit c95a3b4b ] During debug, it was seen that the driver is issuing commands specific to SLI3 on SLI4 devices. Although the adapter correctly rejected the command, this should not be done. Revise the code to stop sending these commands on a SLI4 adapter. Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 03aa4f19 ] Two saa7146/hexium files contain a construct that causes a warning when built with clang: drivers/media/pci/saa7146/hexium_orion.c:210:12: error: stack frame size of 2272 bytes in function 'hexium_probe' [-Werror,-Wframe-larger-than=] static int hexium_probe(struct saa7146_dev *dev) ^ drivers/media/pci/saa7146/hexium_gemini.c:257:12: error: stack frame size of 2304 bytes in function 'hexium_attach' [-Werror,-Wframe-larger-than=] static int hexium_attach(struct saa7146_dev *dev, struct saa7146_pci_extension_data *info) ^ This one happens regardless of KASAN, and the problem is that a constructor to initialize a dynamically allocated structure leads to a copy of that structure on the stack, whereas gcc initializes it in place. Link: https://bugs.llvm.org/show_bug.cgi?id=40776Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> [hverkuil-cisco@xs4all.nl: fix checkpatch warnings] Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
James Smart authored
[ Upstream commit 32a80c09 ] The driver is reporting support for NVME even when not configured for NVME operation. Fix (and make more readable) when NVME protocol support is indicated. Signed-off-by:
-
James Smart authored
[ Upstream commit d67f935b ] The FDMI manufacturer value being reported on Linux is inconsistent with other OS's. Set the value to "Emulex Corporation" for consistency. Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit f74267b5 ] The media_device is part of a static global vimc_device struct. The media framework expects this to be zeroed before it is used, however, since this is a global this is not the case if vimc is unbound and then bound again. So call memset to ensure any left-over values are cleared. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit ed713a4a ] clang-8 warns about one function here when KASAN is enabled, even without the 'asan-stack' option: drivers/media/usb/go7007/go7007-fw.c:1551:5: warning: stack frame size of 2656 bytes in function I have reported this issue in the llvm bugzilla, but to make it work with the clang-8 release, a small annotation is still needed. Link: https://bugs.llvm.org/show_bug.cgi?id=38809Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit e6f8bd59 ] When streaming is stopped all URBs are killed, but in fill_frame and in bulk_irq this results in an attempt to resubmit the killed URB. That is not what you want and causes spurious kernel messages. So check if streaming has stopped before resubmitting. Also check against gspca_dev->streaming rather than vb2_start_streaming_called() since vb2_start_streaming_called() will return true when in stop_streaming, but gspca_dev->streaming is set to false when stop_streaming is called. Fixes: 6992effe ("gspca: Kill all URBs before releasing any of them") Signed-off-by:
-
Helen Fornazier authored
[ Upstream commit 2978a505 ] The state TASK_UNINTERRUPTIBLE should be set just before schedule_timeout() call, so it knows the sleep mode it should enter. There is no point in setting TASK_UNINTERRUPTIBLE at the initialization of the thread as schedule_timeout() will set the state back to TASK_RUNNING. This fixes a warning in __might_sleep() call, as it's expecting the task to be in TASK_RUNNING state just before changing the state to a sleeping state. Reported-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
Helen Koike <helen.koike@collabora.com> Signed-off-by:
-
Kangjie Lu authored
[ Upstream commit 63a06181 ] devm_reset_control_get could fail, so the fix checks its return value and passes the error code upstream in case it fails. Signed-off-by:
Kangjie Lu <kjlu@umn.edu> Acked-by:
Avri Altman <avri.altman@wdc.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[ Upstream commit b9952f93 ] [Why] The kms_plane@plane-position-covered-pipe-*-planes subtests can produce a sequence of atomic commits such that neither active_changed nor mode_changed but connectors_changed. When this happens we remove the old stream from the context and add a new stream but the new stream doesn't have mode_changed=true set. This incorrect programming sequence causes CRC mismatches to occur in the test. The stream->mode_changed value should be set whenever a new stream is created. [How] A new stream is created whenever drm_atomic_crtc_needs_modeset is true. We previously covered the active_changed and mode_changed conditions for the CRTC but connectors_changed is also checked within drm_atomic_crtc_needs_modeset. So just use drm_atomic_crtc_needs_modeset directly to determine the mode_changed flag. Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
Sun peng Li <Sunpeng.Li@amd.com> Acked-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Murton Liu authored
[ Upstream commit 59979bf8 ] Check if we get any values equal to 0, and set to 1 if so. Signed-off-by:
Murton Liu <murton.liu@amd.com> Reviewed-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-by:
Sivapiriyan Kumarasamy <Sivapiriyan.Kumarasamy@amd.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 49dc762c ] The driver should really call dm365_isif_setup_pinmux() through a callback, but uses a hack to include a davinci specific machine header file when compile testing instead. This works almost everywhere, but not on the ARM omap1 platform, which has another header named mach/mux.h. This causes a build failure: drivers/staging/media/davinci_vpfe/dm365_isif.c:2028:2: error: implicit declaration of function 'davinci_cfg_reg' [-Werror,-Wimplicit-function-declaration] davinci_cfg_reg(DM365_VIN_CAM_WEN); ^ drivers/staging/media/davinci_vpfe/dm365_isif.c:2028:2: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes] drivers/staging/media/davinci_vpfe/dm365_isif.c:2028:18: error: use of undeclared identifier 'DM365_VIN_CAM_WEN' davinci_cfg_reg(DM365_VIN_CAM_WEN); ^ drivers/staging/media/davinci_vpfe/dm365_isif.c:2029:18: error: use of undeclared identifier 'DM365_VIN_CAM_VD' davinci_cfg_reg(DM365_VIN_CAM_VD); ^ drivers/staging/media/davinci_vpfe/dm365_isif.c:2030:18: error: use of undeclared identifier 'DM365_VIN_CAM_HD' davinci_cfg_reg(DM365_VIN_CAM_HD); ^ drivers/staging/media/davinci_vpfe/dm365_isif.c:2031:18: error: use of undeclared identifier 'DM365_VIN_YIN4_7_EN' davinci_cfg_reg(DM365_VIN_YIN4_7_EN); ^ drivers/staging/media/davinci_vpfe/dm365_isif.c:2032:18: error: use of undeclared identifier 'DM365_VIN_YIN0_3_EN' davinci_cfg_reg(DM365_VIN_YIN0_3_EN); ^ 7 errors generated. Exclude omap1 from compile-testing, under the assumption that all others still work. Fixes: 4907c73d ("media: staging: davinci_vpfe: allow building with COMPILE_TEST") Signed-off-by:
-
James Hutchinson authored
[ Upstream commit 981fbe3d ] Ref: https://bugzilla.kernel.org/show_bug.cgi?id=199323 Users are experiencing problems with the DVBSky S960/S960C USB devices since the following commit: 9d659ae1: ("locking/mutex: Add lock handoff to avoid starvation") The device malfunctions after running for an indeterminable period of time, and the problem can only be cleared by rebooting the machine. It is possible to encourage the problem to surface by blocking the signal to the LNB. Further debugging revealed the cause of the problem. In the following capture: - thread #1325 is running m88ds3103_set_frontend - thread #42 is running ts2020_stat_work a> [1325] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 07 80 [1325] usb 1-1: dvb_usb_v2_generic_io: <<< 08 [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 68 3f [42] usb 1-1: dvb_usb_v2_generic_io: <<< 08 ff [42] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 03 11 [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 60 3d [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 ff b> [1325] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 07 00 [1325] usb 1-1: dvb_usb_v2_generic_io: <<< 07 [42] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 03 11 [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 60 21 [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 ff [42] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 03 11 [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 60 66 [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 ff [1325] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 03 11 [1325] usb 1-1: dvb_usb_v2_generic_io: <<< 07 [1325] usb 1-1: dvb_usb_v2_generic_io: >>> 08 60 02 10 0b [1325] usb 1-1: dvb_usb_v2_generic_io: <<< 07 Two i2c messages are sent to perform a reset in m88ds3103_set_frontend: a. 0x07, 0x80 b. 0x07, 0x00 However, as shown in the capture, the regmap mutex is being handed over to another thread (ts2020_stat_work) in between these two messages. >From here, the device responds to every i2c message with an 07 message, and will only return to normal operation following a power cycle. Use regmap_multi_reg_write to group the two reset messages, ensuring both are processed before the regmap mutex is unlocked. Signed-off-by:
James Hutchinson <jahutchinson99@googlemail.com> Reviewed-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Stefan Brüns authored
[ Upstream commit fdfa59cd ] Commit 14f4eaed ("media: dvbsky: fix driver unregister logic") fixed a use-after-free by removing the reference to the frontend after deleting the backing i2c device. This has the unfortunate side effect the frontend device is never freed in the dvb core leaving a dangling device, leading to errors when the dvb core tries to register the frontend after e.g. a replug as reported here: https://www.spinics.net/lists/linux-media/msg138181.html media: dvbsky: issues with DVBSky T680CI === [ 561.119145] sp2 8-0040: CIMaX SP2 successfully attached [ 561.119161] usb 2-3: DVB: registering adapter 0 frontend 0 (Silicon Labs Si2168)... [ 561.119174] sysfs: cannot create duplicate filename '/class/dvb/ dvb0.frontend0' === The use after free happened as dvb_usbv2_disconnect calls in this order: - dvb_usb_device::props->exit(...) - dvb_usbv2_adapter_frontend_exit(...) + if (fe) dvb_unregister_frontend(fe) + dvb_usb_device::props->frontend_detach(...) Moving the release of the i2c device from exit() to frontend_detach() avoids the dangling pointer access and allows the core to unregister the frontend. This was originally reported for a DVBSky T680CI, but it also affects the MyGica T230C. As all supported devices structure the registration/ unregistration identically, apply the change for all device types. Signed-off-by:
Stefan Brüns <stefan.bruens@rwth-aachen.de> Signed-off-by:
-
Kangjie Lu authored
[ Upstream commit 0ab34a08 ] si2165_readreg8() may fail. Looking into si2165_readreg8(), we will find that "val_tmp" will be an uninitialized value when regmap_read() fails. "val_tmp" is then assigned to "val". So if si2165_readreg8() fails, "val" will be a random value. Further use will lead to undefined behaviors. The fix checks if si2165_readreg8() fails, and if so, returns its error code upstream. Signed-off-by:
Matthias Schwarzott <zzam@gentoo.org> Tested-by:
-
Kai-Heng Feng authored
[ Upstream commit 5b6e1321 ] igb sets different WoL settings in system suspend callback and runtime suspend callback. The suspend direct complete optimization leaves igb in runtime suspended state with wrong WoL setting during system suspend. To fix this, we need to disable suspend direct complete optimization to let igb always use suspend callback to set correct WoL during system suspend. Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Noralf Trønnes authored
[ Upstream commit a89bfc5d ] Buffers passed to spi_sync() must be dma-safe even for tiny buffers since some SPI controllers use DMA for all transfers. Example splat with CONFIG_DMA_API_DEBUG enabled: [ 23.750467] DMA-API: dw_dmac_pci 0000:00:15.0: device driver maps memory from stack [probable addr=000000001e49185d] [ 23.750529] WARNING: CPU: 1 PID: 1296 at kernel/dma/debug.c:1161 check_for_stack+0xb7/0x190 [ 23.750533] Modules linked in: mmc_block(+) spi_pxa2xx_platform(+) pwm_lpss_pci pwm_lpss spi_pxa2xx_pci sdhci_pci cqhci intel_mrfld_pwrbtn extcon_intel_mrfld sdhci intel_mrfld_adc led_class mmc_core ili9341 mipi_dbi tinydrm backlight ti_ads7950 industrialio_triggered_buffer kfifo_buf intel_soc_pmic_mrfld hci_uart btbcm [ 23.750599] CPU: 1 PID: 1296 Comm: modprobe Not tainted 5.0.0-rc7+ #236 [ 23.750605] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48 [ 23.750620] RIP: 0010:check_for_stack+0xb7/0x190 [ 23.750630] Code: 8b 6d 50 4d 85 ed 75 04 4c 8b 6d 10 48 89 ef e8 2f 8b 44 00 48 89 c6 4a 8d 0c 23 4c 89 ea 48 c7 c7 88 d0 82 b4 e8 40 7c f9 ff <0f> 0b 8b 05 79 00 4b 01 85 c0 74 07 5b 5d 41 5c 41 5d c3 8b 05 54 [ 23.750637] RSP: 0000:ffff97bbc0292fa0 EFLAGS: 00010286 [ 23.750646] RAX: 0000000000000000 RBX: ffff97bbc0290000 RCX: 0000000000000006 [ 23.750652] RDX: 0000000000000007 RSI: 0000000000000002 RDI: ffff94b33e115450 [ 23.750658] RBP: ffff94b33c8578b0 R08: 0000000000000002 R09: 00000000000201c0 [ 23.750664] R10: 00000006ecb0ccc6 R11: 0000000000034f38 R12: 000000000000316c [ 23.750670] R13: ffff94b33c84b250 R14: ffff94b33dedd5a0 R15: 0000000000000001 [ 23.750679] FS: 0000000000000000(0000) GS:ffff94b33e100000(0063) knlGS:00000000f7faf690 [ 23.750686] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 [ 23.750691] CR2: 00000000f7f54faf CR3: 000000000722c000 CR4: 00000000001006e0 [ 23.750696] Call Trace: [ 23.750713] debug_dma_map_sg+0x100/0x340 [ 23.750727] ? dma_direct_map_sg+0x3b/0xb0 [ 23.750739] spi_map_buf+0x25a/0x300 [ 23.750751] __spi_pump_messages+0x2a4/0x680 [ 23.750762] __spi_sync+0x1dd/0x1f0 [ 23.750773] spi_sync+0x26/0x40 [ 23.750790] mipi_dbi_typec3_command_read+0x14d/0x240 [mipi_dbi] [ 23.750802] ? spi_finalize_current_transfer+0x10/0x10 [ 23.750821] mipi_dbi_typec3_command+0x1bc/0x1d0 [mipi_dbi] Reported-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Kai-Heng Feng authored
[ Upstream commit 459d69c4 ] There are some new e1000e devices can only be woken up from D3 one time, by plugging Ethernet cable. Subsequent cable plugging does set PME bit correctly, but it still doesn't get woken up. Since e1000e connects to the root complex directly, we rely on ACPI to wake it up. In this case, the GPE from _PRW only works once and stops working after that. Though it appears to be a platform bug, e1000e maintainers confirmed that I219 does not support D3. So disable runtime PM on CNP+ chips. We may need to disable earlier generations if this bug also hit older platforms. Bugzilla: https://bugzilla.kernel.org/attachment.cgi?id=280819Signed-off-by:
-
