- 04 Jun, 2019 1 commit
-
-
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:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 31 May, 2019 39 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:
-
Brett Creeley authored
[ Upstream commit 5abac9d7 ] Currently we check if the __ICE_PREPARED_FOR_RESET bit is set prior to calling ice_prepare_for_reset in ice_reset_subtask(), but we aren't checking that bit in ice_do_reset() before calling ice_prepare_for_reset(). This is not consistent and can cause issues if ice_prepare_for_reset() is called prior to ice_do_reset(). Fix this by checking if the __ICE_PREPARED_FOR_RESET bit is set internal to ice_prepare_for_reset(). Signed-off-by:
Brett Creeley <brett.creeley@intel.com> Signed-off-by:
Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
YueHaibing authored
[ Upstream commit fa3c098c ] As Hans de Goede pointed, using this driver without ACPI makes little sense, so add ACPI dependency to Kconfig entry to fix a build error while CONFIG_ACPI is not set. drivers/extcon/extcon-axp288.c: In function 'axp288_extcon_probe': drivers/extcon/extcon-axp288.c:363:20: error: dereferencing pointer to incomplete type put_device(&adev->dev); Fixes: 0cf064db ("extcon: axp288: Convert to use acpi_dev_get_first_match_dev()") Reported-by:
Hulk Robot <hulkci@huawei.com> Suggested-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
Mukesh Ojha <mojha@codeaurora.org> Signed-off-by:
Chanwoo Choi <cw00.choi@samsung.com> Signed-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 85fb3526 ] The current code allows the TCON clock divider to have a range between 4 and 127 when feeding the DSI controller. The only display supported so far had a display clock rate that ended up using a divider of 4, but testing with other displays show that only 4 seems to be functional. This also aligns with what Allwinner is doing in their BSP, so let's just hardcode that we want a divider of 4 when using the DSI output. Reviewed-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:
-
Nicholas Kazlauskas authored
[ Upstream commit 4bc46da4 ] [Why] Seamless boot tries to reuse planes that were enabled for the first commit applied. In the case where Raven is booting with two monitors connected and the first commit contains two streams the screen corruption would occur because the second stream was trying to re-use a tg and plane that weren't previously enabled. The state on the first commit looks something like the following: TG0: enabled=1 TG1: enabled=0 TG2: enabled=0 TG3: enabled=0 New state: pipe=0, stream=0, plane=0, new_tg=0 New state: pipe=1, stream=1, plane=1, new_tg=1 New state: pipe=2, stream=NULL, plane=NULL, new_tg=NULL New state: pipe=3, stream=NULL, plane=NULL, new_tg=NULL Only one plane/tg is setup before we enter accelerated mode so we really want to disabling everything but that first plane. [How] Check if the stream is not NULL and if the tg is enabled before deciding whether to skip the plane disable. Also ensure we're also disabling on the current state's pipe_ctx so we don't overwrite the fields in the new pending state. Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
Anthony Koo <Anthony.Koo@amd.com> Acked-by:
Harry Wentland <Harry.Wentland@amd.com> Acked-by:
Leo Li <sunpeng.li@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Anthony Koo authored
[ Upstream commit dcf1a988 ] [Why] AUX arbitration occurs between SW and FW components. When AUX acquire fails, it causes engine->ddc to be NULL, which leads to an exception when we try to release the AUX engine. [How] When AUX engine acquire fails, it should return from the function without trying to continue the operation. The upper level will determine if it wants to retry. i.e. dce_aux_transfer_with_retries will be used and retry. Signed-off-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-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 7d7b25d0 ] The SND_SOC_DAVINCI_MCASP driver can use either edma or sdma as a back-end, and it takes the presence of the respective dma engine drivers in the configuration as an indication to which ones should be built. However, this is flawed in multiple ways: - With CONFIG_TI_EDMA=m and CONFIG_SND_SOC_DAVINCI_MCASP=y, is enabled as =m, and we get a link error: sound/soc/ti/davinci-mcasp.o: In function `davinci_mcasp_probe': davinci-mcasp.c:(.text+0x930): undefined reference to `edma_pcm_platform_register' - When CONFIG_SND_SOC_DAVINCI_MCASP=m has already been selected by another driver, the same link error appears even if CONFIG_TI_EDMA is disabled There are possibly other issues here, but it seems that the only reasonable solution is to always build both SND_SOC_TI_EDMA_PCM and SND_SOC_TI_SDMA_PCM as a dependency here. Both are fairly small and do not have any other compile-time dependencies, so the cost is very small, and makes the configuration stage much more consistent. Fixes: f2055e14 ("ASoC: ti: Merge davinci and omap directories") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Mark Brown <broonie@kernel.org> 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:
Nathan Chancellor <natechancellor@gmail.com> 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:
-
Steve Twiss authored
[ Upstream commit 5e6afb38 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: f6130be6 ("regulator: DA9055 regulator driver") Suggested-by:
Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by:
Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by:
-
Steve Twiss authored
[ Upstream commit 978995de ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 4068e518 ("regulator: da9062: DA9062 regulator driver") Suggested-by:
-
Steve Twiss authored
[ Upstream commit 275513b7 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: c90456e3 ("regulator: pv88090: new regulator driver") Suggested-by:
-
Steve Twiss authored
[ Upstream commit 119c4f50 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: e4ee831f ("regulator: Add WM831x DC-DC buck convertor support") Suggested-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by:
-
Steve Twiss authored
[ Upstream commit 1867af94 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 99cf3af5 ("regulator: pv88080: new regulator driver") Suggested-by:
-
Steve Twiss authored
[ Upstream commit 29d40b4a ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 69ca3e58 ("regulator: da9063: Add Dialog DA9063 voltage regulators support.") Suggested-by:
-
Steve Twiss authored
[ Upstream commit 65378de3 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 1028a37d ("regulator: da9211: new regulator driver") Suggested-by:
-
Steve Twiss authored
[ Upstream commit 89b2758c ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: b59320cc ("regulator: lp8755: new driver for LP8755") Suggested-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:
-
Steve Twiss authored
[ Upstream commit f5821363 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: f307a7e9 ("regulator: pv88060: new regulator driver") Suggested-by:
-
Steve Twiss authored
[ Upstream commit f132da25 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 3eb2c7ec ("regulator: Add LTC3589 support") Suggested-by:
-
Steve Twiss authored
[ Upstream commit 769fc8d4 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 37b918a0 ("regulator: Add LTC3676 support") Suggested-by:
-
Steve Twiss authored
[ Upstream commit f7a62172 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: d4d6b722 ("regulator: Add WM831x ISINK support") Suggested-by:
-
Steve Twiss authored
[ Upstream commit 8be64b6d ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: d1c6b4fe ("regulator: Add WM831x LDO support") Suggested-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:
-
Laurent Pinchart authored
[ Upstream commit 27a7e3e1 ] For HDMI pipelines, when the output gets disconnected the device handling CEC needs to be notified. Instead of guessing which device that would be (and sometimes getting it wrong), notify all devices in the pipeline. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> 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:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Laurent Pinchart authored
[ Upstream commit e482ae9b ] Writeback jobs are allocated when the WRITEBACK_FB_ID is set, and deleted when the jobs complete. This results in both a memory leak of the job and a leak of the framebuffer if the atomic commit returns before the job is queued for processing, for instance if the atomic check fails or if the commit runs in test-only mode. Fix this by implementing the drm_writeback_cleanup_job() function and calling it from __drm_atomic_helper_connector_destroy_state(). As writeback jobs are removed from the state when they're queued for processing, any job left in the state when the state gets destroyed needs to be cleaned up. The existing declaration of the drm_writeback_cleanup_job() function without an implementation hints that this problem was considered, but never addressed. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Brian Starkey <brian.starkey@arm.com> Acked-by:
Liviu Dudau <liviu.dudau@arm.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:
-
Li RongQing authored
[ Upstream commit 95e0b46f ] module.name will be allocated unconditionally when auditing load module, and audit_log_start() can fail with other reasons, or audit_log_exit maybe not called, caused module.name is not freed so free module.name in audit_free_context and __audit_syscall_exit unreferenced object 0xffff88af90837d20 (size 8): comm "modprobe", pid 1036, jiffies 4294704867 (age 3069.138s) hex dump (first 8 bytes): 69 78 67 62 65 00 ff ff ixgbe... backtrace: [<0000000008da28fe>] __audit_log_kern_module+0x33/0x80 [<00000000c1491e61>] load_module+0x64f/0x3850 [<000000007fc9ae3f>] __do_sys_init_module+0x218/0x250 [<0000000000d4a478>] do_syscall_64+0x117/0x400 [<000000004924ded8>] entry_SYSCALL_64_after_hwframe+0x49/0xbe [<000000007dc331dd>] 0xffffffffffffffff Fixes: ca86cad7 ("audit: log module name on init_module") Signed-off-by:
Zhang Yu <zhangyu31@baidu.com> Signed-off-by:
Li RongQing <lirongqing@baidu.com> [PM: manual merge fixup in __audit_syscall_exit()] Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
James Smart authored
[ Upstream commit 9b164068 ] When unloading the driver, mailbox commands may be sent without holding a reference on the ndlp. By the time the mailbox command completes, the ndlp may have reduced its ref counts and been freed. The problem was reported by KASAN. While unregistering due to driver unload, have the completion noop'd by setting the ndlp context NULL'd. Due to the unload, no further action was necessary. Also, while reviewing this path, the generic nulling of the context after handling should be slightly moved. Reported by: Bart Van Assche <bvanassche@acm.org> 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:
-
James Smart authored
[ Upstream commit 50e3f871 ] A patch in the 12.2.0.0 set caused a new lockdep warning: WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected 5.0.0-rc8-next-20190301-dbg+ #1 Not tainted Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&(&qp->io_buf_list_put_lock)->rlock); local_irq_disable(); lock(&(&phba->hbalock)->rlock); lock(&(&qp->io_buf_list_put_lock)->rlock); <Interrupt> lock(&(&phba->hbalock)->rlock); see: https://www.spinics.net/lists/linux-scsi/msg128389.html In summary, the new patch added taking the io_buf_list_put_lock while under an irq-disabled hbalock. This created a lock heirarchy dependent upon irq being disabled, and there are paths that take the io_buf_list_put_lock without disabling irq. Looking at the lpfc_io_free routine, which is where the new heirarchy was introduced, there is no reason to be taking out the hbalock and raising irq, as the functionality is replaced by the io_buf_list_xxx locks. Resolve by removing the hbalock/irq calls in lpfc_io_free. Fixes: 5e5b511d ("scsi: lpfc: Partition XRI buffer list across Hardware Queues") Reported-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
James Smart authored
[ Upstream commit ff6bf897 ] A prior patch which added support for non-uniform allocation of MSIX vectors now causes a smatch complaint: drivers/scsi/lpfc/lpfc_scsi.c:3674 lpfc_scsi_cmd_iocb_cmpl() error: we previously assumed 'phba->sli4_hba.hdwq' could be null (see line 3667) Resolve by removing the unnecessary check for a NULL hdwq table. Fixes 6a828b0f: ("scsi: lpfc: Support non-uniform allocation of MSIX vectors to hardware queues") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
