2020-05-04 18:47:37

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 00/26] 4.14.179-rc1 review

This is the start of the stable review cycle for the 4.14.179 release.
There are 26 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.179-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 4.14.179-rc1

Paul Moore <[email protected]>
selinux: properly handle multiple messages in selinux_netlink_send()

Andy Shevchenko <[email protected]>
dmaengine: dmatest: Fix iteration non-stop logic

Andreas Gruenbacher <[email protected]>
nfs: Fix potential posix_acl refcnt leak in nfs3_set_acl

Arnd Bergmann <[email protected]>
ALSA: opti9xx: shut up gcc-10 range warning

Suravee Suthikulpanit <[email protected]>
iommu/amd: Fix legacy interrupt remapping for x2APIC-enabled system

David Disseldorp <[email protected]>
scsi: target/iblock: fix WRITE SAME zeroing

Tang Bin <[email protected]>
iommu/qcom: Fix local_base status check

Sean Christopherson <[email protected]>
vfio/type1: Fix VA->PA translation for PFNMAP VMAs in vaddr_get_pfn()

Yan Zhao <[email protected]>
vfio: avoid possible overflow in vfio_iommu_type1_pin_pages

Alaa Hleihel <[email protected]>
RDMA/mlx4: Initialize ib_spec on the stack

Aharon Landau <[email protected]>
RDMA/mlx5: Set GRH fields in query QP on RoCE

Sunwook Eom <[email protected]>
dm verity fec: fix hash block number in verity_fec_decode

Dexuan Cui <[email protected]>
PM: hibernate: Freeze kernel threads in software_resume()

Kai-Heng Feng <[email protected]>
PM: ACPI: Output correct message on target power state

Takashi Iwai <[email protected]>
ALSA: pcm: oss: Place the plugin buffer overflow checks correctly

Wu Bo <[email protected]>
ALSA: hda/hdmi: fix without unlocked before return

Hui Wang <[email protected]>
ALSA: hda/realtek - Two front mics on a Lenovo ThinkCenter

Adrian Hunter <[email protected]>
mmc: sdhci-pci: Fix eMMC driver strength for BYT-based controllers

Marek Behún <[email protected]>
mmc: sdhci-xenon: fix annoying 1.8V regulator warning

Filipe Manana <[email protected]>
btrfs: fix partial loss of prealloc extent past i_size after fsync

Xiyu Yang <[email protected]>
btrfs: fix block group leak when removing fails

Vasily Averin <[email protected]>
drm/qxl: qxl_release use after free

Vasily Averin <[email protected]>
drm/qxl: qxl_release leak in qxl_hw_surface_alloc()

Vasily Averin <[email protected]>
drm/qxl: qxl_release leak in qxl_draw_dirty_fb()

Ville Syrjälä <[email protected]>
drm/edid: Fix off-by-one in DispID DTD pixel clock

Theodore Ts'o <[email protected]>
ext4: fix special inode number checks in __ext4_iget()


-------------

Diffstat:

Makefile | 4 +--
drivers/acpi/device_pm.c | 4 +--
drivers/dma/dmatest.c | 4 +--
drivers/gpu/drm/drm_edid.c | 2 +-
drivers/gpu/drm/qxl/qxl_cmd.c | 10 +++---
drivers/gpu/drm/qxl/qxl_display.c | 6 ++--
drivers/gpu/drm/qxl/qxl_draw.c | 13 +++----
drivers/gpu/drm/qxl/qxl_ioctl.c | 5 +--
drivers/infiniband/hw/mlx4/main.c | 3 +-
drivers/infiniband/hw/mlx5/qp.c | 4 ++-
drivers/iommu/amd_iommu_init.c | 2 +-
drivers/iommu/qcom_iommu.c | 5 ++-
drivers/md/dm-verity-fec.c | 2 +-
drivers/mmc/host/sdhci-pci-core.c | 3 ++
drivers/mmc/host/sdhci-xenon.c | 10 ++++++
drivers/target/target_core_iblock.c | 2 +-
drivers/vfio/vfio_iommu_type1.c | 6 ++--
fs/btrfs/extent-tree.c | 16 +++++----
fs/btrfs/tree-log.c | 43 +++++++++++++++++++++--
fs/ext4/inode.c | 2 +-
fs/nfs/nfs3acl.c | 22 ++++++++----
kernel/power/hibernate.c | 7 ++++
security/selinux/hooks.c | 68 ++++++++++++++++++++++++-------------
sound/core/oss/pcm_plugin.c | 20 ++++++-----
sound/isa/opti9xx/miro.c | 9 +++--
sound/isa/opti9xx/opti92x-ad1848.c | 9 +++--
sound/pci/hda/patch_hdmi.c | 4 ++-
sound/pci/hda/patch_realtek.c | 1 +
28 files changed, 196 insertions(+), 90 deletions(-)



2020-05-04 18:47:43

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 08/26] mmc: sdhci-xenon: fix annoying 1.8V regulator warning

From: Marek Behún <[email protected]>

commit bb32e1987bc55ce1db400faf47d85891da3c9b9f upstream.

For some reason the Host Control2 register of the Xenon SDHCI controller
sometimes reports the bit representing 1.8V signaling as 0 when read
after it was written as 1. Subsequent read reports 1.

This causes the sdhci_start_signal_voltage_switch function to report
1.8V regulator output did not become stable

When CONFIG_PM is enabled, the host is suspended and resumend many
times, and in each resume the switch to 1.8V is called, and so the
kernel log reports this message annoyingly often.

Do an empty read of the Host Control2 register in Xenon's
.voltage_switch method to circumvent this.

This patch fixes this particular problem on Turris MOX.

Signed-off-by: Marek Behún <[email protected]>
Fixes: 8d876bf472db ("mmc: sdhci-xenon: wait 5ms after set 1.8V...")
Cc: [email protected] # v4.16+
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/mmc/host/sdhci-xenon.c | 10 ++++++++++
1 file changed, 10 insertions(+)

--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drivers/mmc/host/sdhci-xenon.c
@@ -238,6 +238,16 @@ static void xenon_voltage_switch(struct
{
/* Wait for 5ms after set 1.8V signal enable bit */
usleep_range(5000, 5500);
+
+ /*
+ * For some reason the controller's Host Control2 register reports
+ * the bit representing 1.8V signaling as 0 when read after it was
+ * written as 1. Subsequent read reports 1.
+ *
+ * Since this may cause some issues, do an empty read of the Host
+ * Control2 register here to circumvent this.
+ */
+ sdhci_readw(host, SDHCI_HOST_CONTROL2);
}

static const struct sdhci_ops sdhci_xenon_ops = {


2020-05-04 18:47:55

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 02/26] drm/edid: Fix off-by-one in DispID DTD pixel clock

From: Ville Syrjälä <[email protected]>

commit 6292b8efe32e6be408af364132f09572aed14382 upstream.

The DispID DTD pixel clock is documented as:
"00 00 00 h → FF FF FF h | Pixel clock ÷ 10,000 0.01 → 167,772.16 Mega Pixels per Sec"
Which seems to imply that we to add one to the raw value.

Reality seems to agree as there are tiled displays in the wild
which currently show a 10kHz difference in the pixel clock
between the tiles (one tile gets its mode from the base EDID,
the other from the DispID block).

Cc: [email protected]
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Manasi Navare <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/drm_edid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4502,7 +4502,7 @@ static struct drm_display_mode *drm_mode
struct drm_display_mode *mode;
unsigned pixel_clock = (timings->pixel_clock[0] |
(timings->pixel_clock[1] << 8) |
- (timings->pixel_clock[2] << 16));
+ (timings->pixel_clock[2] << 16)) + 1;
unsigned hactive = (timings->hactive[0] | timings->hactive[1] << 8) + 1;
unsigned hblank = (timings->hblank[0] | timings->hblank[1] << 8) + 1;
unsigned hsync = (timings->hsync[0] | (timings->hsync[1] & 0x7f) << 8) + 1;


2020-05-04 18:49:06

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 17/26] RDMA/mlx4: Initialize ib_spec on the stack

From: Alaa Hleihel <[email protected]>

commit c08cfb2d8d78bfe81b37cc6ba84f0875bddd0d5c upstream.

Initialize ib_spec on the stack before using it, otherwise we will have
garbage values that will break creating default rules with invalid parsing
error.

Fixes: a37a1a428431 ("IB/mlx4: Add mechanism to support flow steering over IB links")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alaa Hleihel <[email protected]>
Reviewed-by: Maor Gottlieb <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/infiniband/hw/mlx4/main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -1614,8 +1614,9 @@ static int __mlx4_ib_create_default_rule
int i;

for (i = 0; i < ARRAY_SIZE(pdefault_rules->rules_create_list); i++) {
+ union ib_flow_spec ib_spec = {};
int ret;
- union ib_flow_spec ib_spec;
+
switch (pdefault_rules->rules_create_list[i]) {
case 0:
/* no rule */


2020-05-04 18:49:11

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 22/26] iommu/amd: Fix legacy interrupt remapping for x2APIC-enabled system

From: Suravee Suthikulpanit <[email protected]>

commit b74aa02d7a30ee5e262072a7d6e8deff10b37924 upstream.

Currently, system fails to boot because the legacy interrupt remapping
mode does not enable 128-bit IRTE (GA), which is required for x2APIC
support.

Fix by using AMD_IOMMU_GUEST_IR_LEGACY_GA mode when booting with
kernel option amd_iommu_intr=legacy instead. The initialization
logic will check GASup and automatically fallback to using
AMD_IOMMU_GUEST_IR_LEGACY if GA mode is not supported.

Fixes: 3928aa3f5775 ("iommu/amd: Detect and enable guest vAPIC support")
Signed-off-by: Suravee Suthikulpanit <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/iommu/amd_iommu_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -2809,7 +2809,7 @@ static int __init parse_amd_iommu_intr(c
{
for (; *str; ++str) {
if (strncmp(str, "legacy", 6) == 0) {
- amd_iommu_guest_ir = AMD_IOMMU_GUEST_IR_LEGACY;
+ amd_iommu_guest_ir = AMD_IOMMU_GUEST_IR_LEGACY_GA;
break;
}
if (strncmp(str, "vapic", 5) == 0) {


2020-05-04 18:49:28

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 12/26] ALSA: pcm: oss: Place the plugin buffer overflow checks correctly

From: Takashi Iwai <[email protected]>

commit 4285de0725b1bf73608abbcd35ad7fd3ddc0b61e upstream.

The checks of the plugin buffer overflow in the previous fix by commit
f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
are put in the wrong places mistakenly, which leads to the expected
(repeated) sound when the rate plugin is involved. Fix in the right
places.

Also, at those right places, the zero check is needed for the
termination node, so added there as well, and let's get it done,
finally.

Fixes: f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/core/oss/pcm_plugin.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)

--- a/sound/core/oss/pcm_plugin.c
+++ b/sound/core/oss/pcm_plugin.c
@@ -211,21 +211,23 @@ static snd_pcm_sframes_t plug_client_siz
if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
plugin = snd_pcm_plug_last(plug);
while (plugin && drv_frames > 0) {
- if (check_size && drv_frames > plugin->buf_frames)
- drv_frames = plugin->buf_frames;
plugin_prev = plugin->prev;
if (plugin->src_frames)
drv_frames = plugin->src_frames(plugin, drv_frames);
+ if (check_size && plugin->buf_frames &&
+ drv_frames > plugin->buf_frames)
+ drv_frames = plugin->buf_frames;
plugin = plugin_prev;
}
} else if (stream == SNDRV_PCM_STREAM_CAPTURE) {
plugin = snd_pcm_plug_first(plug);
while (plugin && drv_frames > 0) {
plugin_next = plugin->next;
+ if (check_size && plugin->buf_frames &&
+ drv_frames > plugin->buf_frames)
+ drv_frames = plugin->buf_frames;
if (plugin->dst_frames)
drv_frames = plugin->dst_frames(plugin, drv_frames);
- if (check_size && drv_frames > plugin->buf_frames)
- drv_frames = plugin->buf_frames;
plugin = plugin_next;
}
} else
@@ -251,26 +253,28 @@ static snd_pcm_sframes_t plug_slave_size
plugin = snd_pcm_plug_first(plug);
while (plugin && frames > 0) {
plugin_next = plugin->next;
+ if (check_size && plugin->buf_frames &&
+ frames > plugin->buf_frames)
+ frames = plugin->buf_frames;
if (plugin->dst_frames) {
frames = plugin->dst_frames(plugin, frames);
if (frames < 0)
return frames;
}
- if (check_size && frames > plugin->buf_frames)
- frames = plugin->buf_frames;
plugin = plugin_next;
}
} else if (stream == SNDRV_PCM_STREAM_CAPTURE) {
plugin = snd_pcm_plug_last(plug);
while (plugin) {
- if (check_size && frames > plugin->buf_frames)
- frames = plugin->buf_frames;
plugin_prev = plugin->prev;
if (plugin->src_frames) {
frames = plugin->src_frames(plugin, frames);
if (frames < 0)
return frames;
}
+ if (check_size && plugin->buf_frames &&
+ frames > plugin->buf_frames)
+ frames = plugin->buf_frames;
plugin = plugin_prev;
}
} else


2020-05-05 08:41:30

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 4.14 00/26] 4.14.179-rc1 review


On 04/05/2020 18:57, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.179 release.
> There are 26 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.179-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

All tests are passing for Tegra ...

Test results for stable-v4.14:
8 builds: 8 pass, 0 fail
16 boots: 16 pass, 0 fail
24 tests: 24 pass, 0 fail

Linux version: 4.14.179-rc1-g6d39cf919746
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04

Cheers
Jon

--
nvpublic

2020-05-05 15:36:54

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.14 00/26] 4.14.179-rc1 review

On Mon, 4 May 2020 at 23:31, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.14.179 release.
> There are 26 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.179-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary
------------------------------------------------------------------------

kernel: 4.14.179-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 6d39cf91974673a74d6d976ecc107e43bb5c3eb4
git describe: v4.14.178-27-g6d39cf919746
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.178-27-g6d39cf919746

No regressions (compared to build v4.14.178)

No fixes (compared to build v4.14.178)

Ran 28789 total tests in the following environments and test suites.

Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
- x86-kasan

Test Suites
-----------
* build
* install-android-platform-tools-r2600
* install-android-platform-tools-r2800
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* kselftest/networking
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-sched-tests
* ltp-syscalls-tests
* v4l2-compliance
* ltp-hugetlb-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* network-basic-tests
* perf
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-native/networking
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net
* kselftest-vsyscall-mode-none/networking

--
Linaro LKFT
https://lkft.linaro.org

2020-05-05 15:49:48

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.14 00/26] 4.14.179-rc1 review

On 5/4/20 10:57 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.179 release.
> There are 26 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 171 pass: 171 fail: 0
Qemu test results:
total: 404 pass: 404 fail: 0

Guenter

2020-05-05 15:55:27

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 4.14 00/26] 4.14.179-rc1 review

On 5/4/20 11:57 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.179 release.
> There are 26 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.179-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah