kernel/linux.git, branch v4.19.47

Linux 4.19.47

2019-05-31T13:46:35+00:00

NFS: Fix a double unlock from nfs_match,get_client

2019-05-31T13:46:35+00:00

[ Upstream commit c260121a97a3e4df6536edbc2f26e166eff370ce ] Now that nfs_match_client drops the nfs_client_lock, we should be careful to always return it in the same condition: locked. Fixes: 950a578c6128 ("NFS: make nfs_match_client killable") Reported-by: syzbot+228a82b263b5da91883d@syzkaller.appspotmail.com Signed-off-by: Benjamin Coddington Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin

drm/sun4i: dsi: Enforce boundaries on the start delay

2019-05-31T13:46:35+00:00

[ Upstream commit efa31801203ac2f5c6a82a28cb991c7163ee0f1d ] 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 Reviewed-by: Paul Kocialkowski Link: https://patchwork.freedesktop.org/patch/msgid/c9889cf5f7a3d101ef380905900b45a182596f56.1549896081.git-series.maxime.ripard@bootlin.com Signed-off-by: Sasha Levin

vfio-ccw: Prevent quiesce function going into an infinite loop

2019-05-31T13:46:35+00:00

[ Upstream commit d1ffa760d22aa1d8190478e5ef555c59a771db27 ] 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 Signed-off-by: Farhan Ali Message-Id: <4d5a4b98ab1b41ac6131b5c36de18b76c5d66898.1555449329.git.alifm@linux.ibm.com> Reviewed-by: Eric Farman Acked-by: Halil Pasic Signed-off-by: Cornelia Huck Signed-off-by: Sasha Levin

drm/sun4i: dsi: Change the start delay calculation

2019-05-31T13:46:34+00:00

[ Upstream commit da676c6aa6413d59ab0a80c97bbc273025e640b2 ] 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: Paul Kocialkowski Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/6e5f72e68f47ca0223877464bf12f0c3f3978de8.1549896081.git-series.maxime.ripard@bootlin.com Signed-off-by: Sasha Levin

drm: Wake up next in drm_read() chain if we are forced to putback the event

2019-05-31T13:46:34+00:00

[ Upstream commit 60b801999c48b6c1dd04e653a38e2e613664264e ] 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 Cc: Daniel Vetter Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20170804082328.17173-1-chris@chris-wilson.co.uk Signed-off-by: Sasha Levin

drm/drv: Hold ref on parent device during drm_device lifetime

2019-05-31T13:46:34+00:00

[ Upstream commit 56be6503aab2bc3a30beae408071b9be5e1bae51 ] This makes it safe to access drm_device->dev after the parent device has been removed/unplugged. Signed-off-by: Noralf Trønnes Reviewed-by: Gerd Hoffmann Link: https://patchwork.freedesktop.org/patch/msgid/20190225144232.20761-2-noralf@tronnes.org Signed-off-by: Sasha Levin

drm/v3d: Handle errors from IRQ setup.

2019-05-31T13:46:34+00:00

[ Upstream commit fc22771547e7e8a63679f0218e943d72b107de65 ] Noted in review by Dave Emett for V3D 4.2 support. Signed-off-by: Eric Anholt Link: https://patchwork.freedesktop.org/patch/msgid/20190308174336.7866-1-eric@anholt.net Reviewed-by: Dave Emett Signed-off-by: Sasha Levin

ASoC: davinci-mcasp: Fix clang warning without CONFIG_PM

2019-05-31T13:46:34+00:00

[ Upstream commit 8ca5104715cfd14254ea5aecc390ae583b707607 ] 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: 1cc0c054f380 ("ASoC: davinci-mcasp: Convert the context save/restore to use array") Signed-off-by: Arnd Bergmann Acked-by: Peter Ujfalusi Reviewed-by: Nathan Chancellor Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: Fix zero length xfer bug

2019-05-31T13:46:34+00:00

[ Upstream commit 5442dcaa0d90fc376bdfc179a018931a8f43dea4 ] 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 Signed-off-by: Mark Brown Signed-off-by: Sasha Levin