This is the start of the stable review cycle for the 4.19.121 release. There are 37 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.19.121-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below.
thanks,
greg k-h
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 4.19.121-rc1
Martin Blumenstingl martin.blumenstingl@googlemail.com mmc: meson-mx-sdio: remove the broken ->card_busy() op
Martin Blumenstingl martin.blumenstingl@googlemail.com mmc: meson-mx-sdio: Set MMC_CAP_WAIT_WHILE_BUSY
Veerabhadrarao Badiganti vbadigan@codeaurora.org mmc: sdhci-msm: Enable host capabilities pertains to R1b response
Adrian Hunter adrian.hunter@intel.com mmc: sdhci-pci: Fix eMMC driver strength for BYT-based controllers
Marek Behún marek.behun@nic.cz mmc: sdhci-xenon: fix annoying 1.8V regulator warning
Douglas Anderson dianders@chromium.org mmc: cqhci: Avoid false "cqhci: CQE stuck on" by not open-coding timeout loop
Qu Wenruo wqu@suse.com btrfs: transaction: Avoid deadlock due to bad initialization timing of fs_info::journal_info
Filipe Manana fdmanana@suse.com btrfs: fix partial loss of prealloc extent past i_size after fsync
Paul Moore paul@paul-moore.com selinux: properly handle multiple messages in selinux_netlink_send()
Andy Shevchenko andriy.shevchenko@linux.intel.com dmaengine: dmatest: Fix iteration non-stop logic
Andreas Gruenbacher agruenba@redhat.com nfs: Fix potential posix_acl refcnt leak in nfs3_set_acl
Arnd Bergmann arnd@arndb.de ALSA: opti9xx: shut up gcc-10 range warning
Suravee Suthikulpanit suravee.suthikulpanit@amd.com iommu/amd: Fix legacy interrupt remapping for x2APIC-enabled system
David Disseldorp ddiss@suse.de scsi: target/iblock: fix WRITE SAME zeroing
Tang Bin tangbin@cmss.chinamobile.com iommu/qcom: Fix local_base status check
Sean Christopherson sean.j.christopherson@intel.com vfio/type1: Fix VA->PA translation for PFNMAP VMAs in vaddr_get_pfn()
Yan Zhao yan.y.zhao@intel.com vfio: avoid possible overflow in vfio_iommu_type1_pin_pages
Leon Romanovsky leon@kernel.org RDMA/core: Fix race between destroy and release FD object
Leon Romanovsky leon@kernel.org RDMA/core: Prevent mixed use of FDs between shared ufiles
Alaa Hleihel alaa@mellanox.com RDMA/mlx4: Initialize ib_spec on the stack
Aharon Landau aharonl@mellanox.com RDMA/mlx5: Set GRH fields in query QP on RoCE
Martin Wilck mwilck@suse.com scsi: qla2xxx: check UNLOADING before posting async work
Martin Wilck mwilck@suse.com scsi: qla2xxx: set UNLOADING before waiting for session deletion
Gabriel Krisman Bertazi krisman@collabora.com dm multipath: use updated MPATHF_QUEUE_IO on mapping for bio-based mpath
Mikulas Patocka mpatocka@redhat.com dm writecache: fix data corruption when reloading the target
Sunwook Eom speed.eom@samsung.com dm verity fec: fix hash block number in verity_fec_decode
Dexuan Cui decui@microsoft.com PM: hibernate: Freeze kernel threads in software_resume()
Kai-Heng Feng kai.heng.feng@canonical.com PM: ACPI: Output correct message on target power state
Takashi Iwai tiwai@suse.de ALSA: pcm: oss: Place the plugin buffer overflow checks correctly
Wu Bo wubo40@huawei.com ALSA: hda/hdmi: fix without unlocked before return
Takashi Iwai tiwai@suse.de ALSA: usb-audio: Correct a typo of NuPrime DAC-10 USB ID
Hui Wang hui.wang@canonical.com ALSA: hda/realtek - Two front mics on a Lenovo ThinkCenter
Xiyu Yang xiyuyang19@fudan.edu.cn btrfs: fix block group leak when removing fails
Vasily Averin vvs@virtuozzo.com drm/qxl: qxl_release use after free
Vasily Averin vvs@virtuozzo.com drm/qxl: qxl_release leak in qxl_hw_surface_alloc()
Vasily Averin vvs@virtuozzo.com drm/qxl: qxl_release leak in qxl_draw_dirty_fb()
Ville Syrjälä ville.syrjala@linux.intel.com drm/edid: Fix off-by-one in DispID DTD pixel clock
-------------
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/core/rdma_core.c | 4 +-- 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-mpath.c | 6 ++-- drivers/md/dm-verity-fec.c | 2 +- drivers/md/dm-writecache.c | 52 +++++++++++++++++++-------- drivers/mmc/host/cqhci.c | 21 ++++++----- drivers/mmc/host/meson-mx-sdio.c | 11 +----- drivers/mmc/host/sdhci-msm.c | 2 ++ drivers/mmc/host/sdhci-pci-core.c | 3 ++ drivers/mmc/host/sdhci-xenon.c | 10 ++++++ drivers/scsi/qla2xxx/qla_os.c | 35 +++++++++---------- drivers/target/target_core_iblock.c | 2 +- drivers/vfio/vfio_iommu_type1.c | 6 ++-- fs/btrfs/extent-tree.c | 16 +++++---- fs/btrfs/transaction.c | 13 +++++-- fs/btrfs/tree-log.c | 43 +++++++++++++++++++++-- fs/nfs/nfs3acl.c | 22 ++++++++---- kernel/power/hibernate.c | 7 ++++ security/selinux/hooks.c | 70 ++++++++++++++++++++++++------------- 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 + sound/usb/quirks.c | 2 +- 36 files changed, 281 insertions(+), 151 deletions(-)
From: Ville Syrjälä ville.syrjala@linux.intel.com
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: stable@vger.kernel.org Signed-off-by: Ville Syrjälä ville.syrjala@linux.intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20200423151743.18767-1-ville.s... Reviewed-by: Manasi Navare manasi.d.navare@intel.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- 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 @@ -4706,7 +4706,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;
From: Vasily Averin vvs@virtuozzo.com
commit 85e9b88af1e6164f19ec71381efd5e2bcfc17620 upstream.
ret should be changed to release allocated struct qxl_release
Cc: stable@vger.kernel.org Fixes: 8002db6336dd ("qxl: convert qxl driver to proper use for reservations") Signed-off-by: Vasily Averin vvs@virtuozzo.com Link: http://patchwork.freedesktop.org/patch/msgid/22cfd55f-07c8-95d0-a2f7-191b715... Signed-off-by: Gerd Hoffmann kraxel@redhat.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/gpu/drm/qxl/qxl_draw.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/qxl/qxl_draw.c +++ b/drivers/gpu/drm/qxl/qxl_draw.c @@ -348,9 +348,10 @@ void qxl_draw_dirty_fb(struct qxl_device goto out_release_backoff;
rects = drawable_set_clipping(qdev, num_clips, clips_bo); - if (!rects) + if (!rects) { + ret = -EINVAL; goto out_release_backoff; - + } drawable = (struct qxl_drawable *)qxl_release_map(qdev, release);
drawable->clip.type = SPICE_CLIP_TYPE_RECTS;
From: Vasily Averin vvs@virtuozzo.com
commit a65aa9c3676ffccb21361d52fcfedd5b5ff387d7 upstream.
Cc: stable@vger.kernel.org Fixes: 8002db6336dd ("qxl: convert qxl driver to proper use for reservations") Signed-off-by: Vasily Averin vvs@virtuozzo.com Link: http://patchwork.freedesktop.org/patch/msgid/2e5a13ae-9ab2-5401-aa4d-03d5f55... Signed-off-by: Gerd Hoffmann kraxel@redhat.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/gpu/drm/qxl/qxl_cmd.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/qxl/qxl_cmd.c +++ b/drivers/gpu/drm/qxl/qxl_cmd.c @@ -472,9 +472,10 @@ int qxl_hw_surface_alloc(struct qxl_devi return ret;
ret = qxl_release_reserve_list(release, true); - if (ret) + if (ret) { + qxl_release_free(qdev, release); return ret; - + } cmd = (struct qxl_surface_cmd *)qxl_release_map(qdev, release); cmd->type = QXL_SURFACE_CMD_CREATE; cmd->flags = QXL_SURF_FLAG_KEEP_DATA;
From: Vasily Averin vvs@virtuozzo.com
commit 933db73351d359f74b14f4af095808260aff11f9 upstream.
qxl_release should not be accesses after qxl_push_*_ring_release() calls: userspace driver can process submitted command quickly, move qxl_release into release_ring, generate interrupt and trigger garbage collector.
It can lead to crashes in qxl driver or trigger memory corruption in some kmalloc-192 slab object
Gerd Hoffmann proposes to swap the qxl_release_fence_buffer_objects() + qxl_push_{cursor,command}_ring_release() calls to close that race window.
cc: stable@vger.kernel.org Fixes: f64122c1f6ad ("drm: add new QXL driver. (v1.4)") Signed-off-by: Vasily Averin vvs@virtuozzo.com Link: http://patchwork.freedesktop.org/patch/msgid/fa17b338-66ae-f299-68fe-8d32419... Signed-off-by: Gerd Hoffmann kraxel@redhat.com [backported to v.4.19 stable] Signed-off-by: Vasily Averin vvs@virtuozzo.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/gpu/drm/qxl/qxl_cmd.c | 5 ++--- drivers/gpu/drm/qxl/qxl_display.c | 6 +++--- drivers/gpu/drm/qxl/qxl_draw.c | 8 ++++---- drivers/gpu/drm/qxl/qxl_ioctl.c | 5 +---- 4 files changed, 10 insertions(+), 14 deletions(-)
--- a/drivers/gpu/drm/qxl/qxl_cmd.c +++ b/drivers/gpu/drm/qxl/qxl_cmd.c @@ -501,8 +501,8 @@ int qxl_hw_surface_alloc(struct qxl_devi /* no need to add a release to the fence for this surface bo, since it is only released when we ask to destroy the surface and it would never signal otherwise */ - qxl_push_command_ring_release(qdev, release, QXL_CMD_SURFACE, false); qxl_release_fence_buffer_objects(release); + qxl_push_command_ring_release(qdev, release, QXL_CMD_SURFACE, false);
surf->hw_surf_alloc = true; spin_lock(&qdev->surf_id_idr_lock); @@ -544,9 +544,8 @@ int qxl_hw_surface_dealloc(struct qxl_de cmd->surface_id = id; qxl_release_unmap(qdev, release, &cmd->release_info);
- qxl_push_command_ring_release(qdev, release, QXL_CMD_SURFACE, false); - qxl_release_fence_buffer_objects(release); + qxl_push_command_ring_release(qdev, release, QXL_CMD_SURFACE, false);
return 0; } --- a/drivers/gpu/drm/qxl/qxl_display.c +++ b/drivers/gpu/drm/qxl/qxl_display.c @@ -532,8 +532,8 @@ static int qxl_primary_apply_cursor(stru cmd->u.set.visible = 1; qxl_release_unmap(qdev, release, &cmd->release_info);
- qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false); qxl_release_fence_buffer_objects(release); + qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
return ret;
@@ -694,8 +694,8 @@ static void qxl_cursor_atomic_update(str cmd->u.position.y = plane->state->crtc_y + fb->hot_y;
qxl_release_unmap(qdev, release, &cmd->release_info); - qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false); qxl_release_fence_buffer_objects(release); + qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
if (old_cursor_bo) qxl_bo_unref(&old_cursor_bo); @@ -740,8 +740,8 @@ static void qxl_cursor_atomic_disable(st cmd->type = QXL_CURSOR_HIDE; qxl_release_unmap(qdev, release, &cmd->release_info);
- qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false); qxl_release_fence_buffer_objects(release); + qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false); }
static int qxl_plane_prepare_fb(struct drm_plane *plane, --- a/drivers/gpu/drm/qxl/qxl_draw.c +++ b/drivers/gpu/drm/qxl/qxl_draw.c @@ -241,8 +241,8 @@ void qxl_draw_opaque_fb(const struct qxl qxl_bo_physical_address(qdev, dimage->bo, 0); qxl_release_unmap(qdev, release, &drawable->release_info);
- qxl_push_command_ring_release(qdev, release, QXL_CMD_DRAW, false); qxl_release_fence_buffer_objects(release); + qxl_push_command_ring_release(qdev, release, QXL_CMD_DRAW, false);
out_free_palette: if (palette_bo) @@ -382,8 +382,8 @@ void qxl_draw_dirty_fb(struct qxl_device } qxl_bo_kunmap(clips_bo);
- qxl_push_command_ring_release(qdev, release, QXL_CMD_DRAW, false); qxl_release_fence_buffer_objects(release); + qxl_push_command_ring_release(qdev, release, QXL_CMD_DRAW, false);
out_release_backoff: if (ret) @@ -433,8 +433,8 @@ void qxl_draw_copyarea(struct qxl_device drawable->u.copy_bits.src_pos.y = sy; qxl_release_unmap(qdev, release, &drawable->release_info);
- qxl_push_command_ring_release(qdev, release, QXL_CMD_DRAW, false); qxl_release_fence_buffer_objects(release); + qxl_push_command_ring_release(qdev, release, QXL_CMD_DRAW, false);
out_free_release: if (ret) @@ -477,8 +477,8 @@ void qxl_draw_fill(struct qxl_draw_fill
qxl_release_unmap(qdev, release, &drawable->release_info);
- qxl_push_command_ring_release(qdev, release, QXL_CMD_DRAW, false); qxl_release_fence_buffer_objects(release); + qxl_push_command_ring_release(qdev, release, QXL_CMD_DRAW, false);
out_free_release: if (ret) --- a/drivers/gpu/drm/qxl/qxl_ioctl.c +++ b/drivers/gpu/drm/qxl/qxl_ioctl.c @@ -257,11 +257,8 @@ static int qxl_process_single_command(st apply_surf_reloc(qdev, &reloc_info[i]); }
+ qxl_release_fence_buffer_objects(release); ret = qxl_push_command_ring_release(qdev, release, cmd->type, true); - if (ret) - qxl_release_backoff_reserve_list(release); - else - qxl_release_fence_buffer_objects(release);
out_free_bos: out_free_release:
From: Xiyu Yang xiyuyang19@fudan.edu.cn
commit f6033c5e333238f299c3ae03fac8cc1365b23b77 upstream.
btrfs_remove_block_group() invokes btrfs_lookup_block_group(), which returns a local reference of the block group that contains the given bytenr to "block_group" with increased refcount.
When btrfs_remove_block_group() returns, "block_group" becomes invalid, so the refcount should be decreased to keep refcount balanced.
The reference counting issue happens in several exception handling paths of btrfs_remove_block_group(). When those error scenarios occur such as btrfs_alloc_path() returns NULL, the function forgets to decrease its refcnt increased by btrfs_lookup_block_group() and will cause a refcnt leak.
Fix this issue by jumping to "out_put_group" label and calling btrfs_put_block_group() when those error scenarios occur.
CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Xiyu Yang xiyuyang19@fudan.edu.cn Signed-off-by: Xin Tan tanxin.ctf@gmail.com Reviewed-by: David Sterba dsterba@suse.com Signed-off-by: David Sterba dsterba@suse.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- fs/btrfs/extent-tree.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)
--- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -10286,7 +10286,7 @@ int btrfs_remove_block_group(struct btrf path = btrfs_alloc_path(); if (!path) { ret = -ENOMEM; - goto out; + goto out_put_group; }
/* @@ -10323,7 +10323,7 @@ int btrfs_remove_block_group(struct btrf ret = btrfs_orphan_add(trans, BTRFS_I(inode)); if (ret) { btrfs_add_delayed_iput(inode); - goto out; + goto out_put_group; } clear_nlink(inode); /* One for the block groups ref */ @@ -10346,13 +10346,13 @@ int btrfs_remove_block_group(struct btrf
ret = btrfs_search_slot(trans, tree_root, &key, path, -1, 1); if (ret < 0) - goto out; + goto out_put_group; if (ret > 0) btrfs_release_path(path); if (ret == 0) { ret = btrfs_del_item(trans, tree_root, path); if (ret) - goto out; + goto out_put_group; btrfs_release_path(path); }
@@ -10494,9 +10494,9 @@ int btrfs_remove_block_group(struct btrf
ret = remove_block_group_free_space(trans, block_group); if (ret) - goto out; + goto out_put_group;
- btrfs_put_block_group(block_group); + /* Once for the block groups rbtree */ btrfs_put_block_group(block_group);
ret = btrfs_search_slot(trans, root, &key, path, -1, 1); @@ -10524,6 +10524,10 @@ int btrfs_remove_block_group(struct btrf /* once for the tree */ free_extent_map(em); } + +out_put_group: + /* Once for the lookup reference */ + btrfs_put_block_group(block_group); out: btrfs_free_path(path); return ret;
From: Hui Wang hui.wang@canonical.com
commit ef0b3203c758b6b8abdb5dca651880347eae6b8c upstream.
This new Lenovo ThinkCenter has two front mics which can't be handled by PA so far, so apply the fixup ALC283_FIXUP_HEADSET_MIC to change the location for one of the mics.
Cc: stable@vger.kernel.org Signed-off-by: Hui Wang hui.wang@canonical.com Link: https://lore.kernel.org/r/20200427030039.10121-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+)
--- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6991,6 +6991,7 @@ static const struct snd_pci_quirk alc269 SND_PCI_QUIRK(0x1558, 0x8560, "System76 Gazelle (gaze14)", ALC269_FIXUP_HEADSET_MIC), SND_PCI_QUIRK(0x1558, 0x8561, "System76 Gazelle (gaze14)", ALC269_FIXUP_HEADSET_MIC), SND_PCI_QUIRK(0x17aa, 0x1036, "Lenovo P520", ALC233_FIXUP_LENOVO_MULTI_CODECS), + SND_PCI_QUIRK(0x17aa, 0x1048, "ThinkCentre Station", ALC283_FIXUP_HEADSET_MIC), SND_PCI_QUIRK(0x17aa, 0x20f2, "Thinkpad SL410/510", ALC269_FIXUP_SKU_IGNORE), SND_PCI_QUIRK(0x17aa, 0x215e, "Thinkpad L512", ALC269_FIXUP_SKU_IGNORE), SND_PCI_QUIRK(0x17aa, 0x21b8, "Thinkpad Edge 14", ALC269_FIXUP_SKU_IGNORE),
From: Takashi Iwai tiwai@suse.de
commit 547d2c9cf4f1f72adfecacbd5b093681fb0e8b3e upstream.
The USB vendor ID of NuPrime DAC-10 is not 16b0 but 16d0.
Fixes: f656891c6619 ("ALSA: usb-audio: add more quirks for DSD interfaces") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200430124755.15940-1-tiwai@suse.de Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- sound/usb/quirks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -1385,7 +1385,7 @@ u64 snd_usb_interface_dsd_format_quirks(
case USB_ID(0x0d8c, 0x0316): /* Hegel HD12 DSD */ case USB_ID(0x10cb, 0x0103): /* The Bit Opus #3; with fp->dsd_raw */ - case USB_ID(0x16b0, 0x06b2): /* NuPrime DAC-10 */ + case USB_ID(0x16d0, 0x06b2): /* NuPrime DAC-10 */ case USB_ID(0x16d0, 0x09dd): /* Encore mDSD */ case USB_ID(0x16d0, 0x0733): /* Furutech ADL Stratos */ case USB_ID(0x16d0, 0x09db): /* NuPrime Audio DAC-9 */
From: Wu Bo wubo40@huawei.com
commit a2f647240998aa49632fb09b01388fdf2b87acfc upstream.
Fix the following coccicheck warning: sound/pci/hda/patch_hdmi.c:1852:2-8: preceding lock on line 1846
After add sanity check to pass klockwork check, The spdif_mutex should be unlock before return true in check_non_pcm_per_cvt().
Fixes: 960a581e22d9 ("ALSA: hda: fix some klockwork scan warnings") Signed-off-by: Wu Bo wubo40@huawei.com Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1587907042-694161-1-git-send-email-wubo40@huawei.c... Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- sound/pci/hda/patch_hdmi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
--- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1848,8 +1848,10 @@ static bool check_non_pcm_per_cvt(struct /* Add sanity check to pass klockwork check. * This should never happen. */ - if (WARN_ON(spdif == NULL)) + if (WARN_ON(spdif == NULL)) { + mutex_unlock(&codec->spdif_mutex); return true; + } non_pcm = !!(spdif->status & IEC958_AES0_NONAUDIO); mutex_unlock(&codec->spdif_mutex); return non_pcm;
From: Takashi Iwai tiwai@suse.de
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: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200424193350.19678-1-tiwai@suse.de Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- 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
From: Kai-Heng Feng kai.heng.feng@canonical.com
commit a9b760b0266f563b4784f695bbd0e717610dc10a upstream.
Transitioned power state logged at the end of setting ACPI power.
However, D3cold won't be in the message because state can only be D3hot at most.
Use target_state to corretly report when power state is D3cold.
Cc: All applicable stable@vger.kernel.org Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/acpi/device_pm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/acpi/device_pm.c +++ b/drivers/acpi/device_pm.c @@ -227,13 +227,13 @@ int acpi_device_set_power(struct acpi_de end: if (result) { dev_warn(&device->dev, "Failed to change power state to %s\n", - acpi_power_state_string(state)); + acpi_power_state_string(target_state)); } else { device->power.state = target_state; ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device [%s] transitioned to %s\n", device->pnp.bus_id, - acpi_power_state_string(state))); + acpi_power_state_string(target_state))); }
return result;
From: Dexuan Cui decui@microsoft.com
commit 2351f8d295ed63393190e39c2f7c1fee1a80578f upstream.
Currently the kernel threads are not frozen in software_resume(), so between dpm_suspend_start(PMSG_QUIESCE) and resume_target_kernel(), system_freezable_power_efficient_wq can still try to submit SCSI commands and this can cause a panic since the low level SCSI driver (e.g. hv_storvsc) has quiesced the SCSI adapter and can not accept any SCSI commands: https://lkml.org/lkml/2020/4/10/47
At first I posted a fix (https://lkml.org/lkml/2020/4/21/1318) trying to resolve the issue from hv_storvsc, but with the help of Bart Van Assche, I realized it's better to fix software_resume(), since this looks like a generic issue, not only pertaining to SCSI.
Cc: All applicable stable@vger.kernel.org Signed-off-by: Dexuan Cui decui@microsoft.com Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- kernel/power/hibernate.c | 7 +++++++ 1 file changed, 7 insertions(+)
--- a/kernel/power/hibernate.c +++ b/kernel/power/hibernate.c @@ -901,6 +901,13 @@ static int software_resume(void) error = freeze_processes(); if (error) goto Close_Finish; + + error = freeze_kernel_threads(); + if (error) { + thaw_processes(); + goto Close_Finish; + } + error = load_image_and_restore(); thaw_processes(); Finish:
Hi!
commit 2351f8d295ed63393190e39c2f7c1fee1a80578f upstream.
Currently the kernel threads are not frozen in software_resume(), so between dpm_suspend_start(PMSG_QUIESCE) and resume_target_kernel(), system_freezable_power_efficient_wq can still try to submit SCSI commands and this can cause a panic since the low level SCSI driver (e.g. hv_storvsc) has quiesced the SCSI adapter and can not accept any SCSI commands: https://lkml.org/lkml/2020/4/10/47
At first I posted a fix (https://lkml.org/lkml/2020/4/21/1318) trying to resolve the issue from hv_storvsc, but with the help of Bart Van Assche, I realized it's better to fix software_resume(), since this looks like a generic issue, not only pertaining to SCSI.
I believe it is too soon to merge this into stable. It is rather big hammer. Yes, it is right thing to do. But I'd wait for 5.7 to be released before merging it to stable.
It needs some testing and it did not get any.
Best regards, Pavel
Cc: All applicable stable@vger.kernel.org Signed-off-by: Dexuan Cui decui@microsoft.com Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
kernel/power/hibernate.c | 7 +++++++ 1 file changed, 7 insertions(+)
--- a/kernel/power/hibernate.c +++ b/kernel/power/hibernate.c @@ -901,6 +901,13 @@ static int software_resume(void) error = freeze_processes(); if (error) goto Close_Finish;
- error = freeze_kernel_threads();
- if (error) {
thaw_processes();
goto Close_Finish;
- }
- error = load_image_and_restore(); thaw_processes(); Finish:
From: Pavel Machek pavel@denx.de Sent: Tuesday, May 5, 2020 5:10 AM To: Greg Kroah-Hartman gregkh@linuxfoundation.org Cc: linux-kernel@vger.kernel.org; stable@vger.kernel.org; Dexuan Cui decui@microsoft.com; Rafael J. Wysocki rafael.j.wysocki@intel.com Subject: Re: [PATCH 4.19 11/37] PM: hibernate: Freeze kernel threads in software_resume()
Hi!
commit 2351f8d295ed63393190e39c2f7c1fee1a80578f upstream.
Currently the kernel threads are not frozen in software_resume(), so between dpm_suspend_start(PMSG_QUIESCE) and resume_target_kernel(), system_freezable_power_efficient_wq can still try to submit SCSI commands and this can cause a panic since the low level SCSI driver (e.g. hv_storvsc) has quiesced the SCSI adapter and can not accept any SCSI commands: https://lkml.org/lkml/2020/4/10/47
At first I posted a fix (https://lkml.org/lkml/2020/4/21/1318) trying to resolve the issue from hv_storvsc, but with the help of Bart Van Assche, I realized it's better to fix software_resume(), since this looks like a generic issue, not only pertaining to SCSI.
I believe it is too soon to merge this into stable. It is rather big hammer. Yes, it is right thing to do. But I'd wait for 5.7 to be released before merging it to stable.
It needs some testing and it did not get any.
Best regards, Pavel
Hi, I did do some testing in a Linux VM running on Hyper-V: Without the patch, I can easily hit the panic I described in the first link above. With the patch, my Linux VM can hibernate >10K times without seeing the panic and I don't see any issue caused by the patch.
That being said, I don't mind waiting for 5.7 before we merge the patch to stable. It would be good for the patch to get more testing from others.
Thanks, -- Dexuan
From: Sunwook Eom speed.eom@samsung.com
commit ad4e80a639fc61d5ecebb03caa5cdbfb91fcebfc upstream.
The error correction data is computed as if data and hash blocks were concatenated. But hash block number starts from v->hash_start. So, we have to calculate hash block number based on that.
Fixes: a739ff3f543af ("dm verity: add support for forward error correction") Cc: stable@vger.kernel.org Signed-off-by: Sunwook Eom speed.eom@samsung.com Reviewed-by: Sami Tolvanen samitolvanen@google.com Signed-off-by: Mike Snitzer snitzer@redhat.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/md/dm-verity-fec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/md/dm-verity-fec.c +++ b/drivers/md/dm-verity-fec.c @@ -436,7 +436,7 @@ int verity_fec_decode(struct dm_verity * fio->level++;
if (type == DM_VERITY_BLOCK_TYPE_METADATA) - block += v->data_blocks; + block = block - v->hash_start + v->data_blocks;
/* * For RS(M, N), the continuous FEC data is divided into blocks of N
From: Mikulas Patocka mpatocka@redhat.com
commit 31b22120194b5c0d460f59e0c98504de1d3f1f14 upstream.
The dm-writecache reads metadata in the target constructor. However, when we reload the target, there could be another active instance running on the same device. This is the sequence of operations when doing a reload:
1. construct new target 2. suspend old target 3. resume new target 4. destroy old target
Metadata that were written by the old target between steps 1 and 2 would not be visible by the new target.
Fix the data corruption by loading the metadata in the resume handler.
Also, validate block_size is at least as large as both the devices' logical block size and only read 1 block from the metadata during target constructor -- no need to read entirety of metadata now that it is done during resume.
Fixes: 48debafe4f2f ("dm: add writecache target") Cc: stable@vger.kernel.org # v4.18+ Signed-off-by: Mikulas Patocka mpatocka@redhat.com Signed-off-by: Mike Snitzer snitzer@redhat.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/md/dm-writecache.c | 52 ++++++++++++++++++++++++++++++++------------- 1 file changed, 37 insertions(+), 15 deletions(-)
--- a/drivers/md/dm-writecache.c +++ b/drivers/md/dm-writecache.c @@ -884,6 +884,24 @@ static int writecache_alloc_entries(stru return 0; }
+static int writecache_read_metadata(struct dm_writecache *wc, sector_t n_sectors) +{ + struct dm_io_region region; + struct dm_io_request req; + + region.bdev = wc->ssd_dev->bdev; + region.sector = wc->start_sector; + region.count = n_sectors; + req.bi_op = REQ_OP_READ; + req.bi_op_flags = REQ_SYNC; + req.mem.type = DM_IO_VMA; + req.mem.ptr.vma = (char *)wc->memory_map; + req.client = wc->dm_io; + req.notify.fn = NULL; + + return dm_io(&req, 1, ®ion, NULL); +} + static void writecache_resume(struct dm_target *ti) { struct dm_writecache *wc = ti->private; @@ -894,8 +912,18 @@ static void writecache_resume(struct dm_
wc_lock(wc);
- if (WC_MODE_PMEM(wc)) + if (WC_MODE_PMEM(wc)) { persistent_memory_invalidate_cache(wc->memory_map, wc->memory_map_size); + } else { + r = writecache_read_metadata(wc, wc->metadata_sectors); + if (r) { + size_t sb_entries_offset; + writecache_error(wc, r, "unable to read metadata: %d", r); + sb_entries_offset = offsetof(struct wc_memory_superblock, entries); + memset((char *)wc->memory_map + sb_entries_offset, -1, + (wc->metadata_sectors << SECTOR_SHIFT) - sb_entries_offset); + } + }
wc->tree = RB_ROOT; INIT_LIST_HEAD(&wc->lru); @@ -1978,6 +2006,12 @@ static int writecache_ctr(struct dm_targ ti->error = "Invalid block size"; goto bad; } + if (wc->block_size < bdev_logical_block_size(wc->dev->bdev) || + wc->block_size < bdev_logical_block_size(wc->ssd_dev->bdev)) { + r = -EINVAL; + ti->error = "Block size is smaller than device logical block size"; + goto bad; + } wc->block_size_bits = __ffs(wc->block_size);
wc->max_writeback_jobs = MAX_WRITEBACK_JOBS; @@ -2066,8 +2100,6 @@ invalid_optional: goto bad; } } else { - struct dm_io_region region; - struct dm_io_request req; size_t n_blocks, n_metadata_blocks; uint64_t n_bitmap_bits;
@@ -2124,19 +2156,9 @@ invalid_optional: goto bad; }
- region.bdev = wc->ssd_dev->bdev; - region.sector = wc->start_sector; - region.count = wc->metadata_sectors; - req.bi_op = REQ_OP_READ; - req.bi_op_flags = REQ_SYNC; - req.mem.type = DM_IO_VMA; - req.mem.ptr.vma = (char *)wc->memory_map; - req.client = wc->dm_io; - req.notify.fn = NULL; - - r = dm_io(&req, 1, ®ion, NULL); + r = writecache_read_metadata(wc, wc->block_size >> SECTOR_SHIFT); if (r) { - ti->error = "Unable to read metadata"; + ti->error = "Unable to read first block of metadata"; goto bad; } }
From: Gabriel Krisman Bertazi krisman@collabora.com
commit 5686dee34dbfe0238c0274e0454fa0174ac0a57a upstream.
When adding devices that don't have a scsi_dh on a BIO based multipath, I was able to consistently hit the warning below and lock-up the system.
The problem is that __map_bio reads the flag before it potentially being modified by choose_pgpath, and ends up using the older value.
The WARN_ON below is not trivially linked to the issue. It goes like this: The activate_path delayed_work is not initialized for non-scsi_dh devices, but we always set MPATHF_QUEUE_IO, asking for initialization. That is fine, since MPATHF_QUEUE_IO would be cleared in choose_pgpath. Nevertheless, only for BIO-based mpath, we cache the flag before calling choose_pgpath, and use the older version when deciding if we should initialize the path. Therefore, we end up trying to initialize the paths, and calling the non-initialized activate_path work.
[ 82.437100] ------------[ cut here ]------------ [ 82.437659] WARNING: CPU: 3 PID: 602 at kernel/workqueue.c:1624 __queue_delayed_work+0x71/0x90 [ 82.438436] Modules linked in: [ 82.438911] CPU: 3 PID: 602 Comm: systemd-udevd Not tainted 5.6.0-rc6+ #339 [ 82.439680] RIP: 0010:__queue_delayed_work+0x71/0x90 [ 82.440287] Code: c1 48 89 4a 50 81 ff 00 02 00 00 75 2a 4c 89 cf e9 94 d6 07 00 e9 7f e9 ff ff 0f 0b eb c7 0f 0b 48 81 7a 58 40 74 a8 94 74 a7 <0f> 0b 48 83 7a 48 00 74 a5 0f 0b eb a1 89 fe 4c 89 cf e9 c8 c4 07 [ 82.441719] RSP: 0018:ffffb738803977c0 EFLAGS: 00010007 [ 82.442121] RAX: ffffa086389f9740 RBX: 0000000000000002 RCX: 0000000000000000 [ 82.442718] RDX: ffffa086350dd930 RSI: ffffa0863d76f600 RDI: 0000000000000200 [ 82.443484] RBP: 0000000000000200 R08: 0000000000000000 R09: ffffa086350dd970 [ 82.444128] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa086350dd930 [ 82.444773] R13: ffffa0863d76f600 R14: 0000000000000000 R15: ffffa08636738008 [ 82.445427] FS: 00007f6abfe9dd40(0000) GS:ffffa0863dd80000(0000) knlGS:00000 [ 82.446040] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 82.446478] CR2: 0000557d288db4e8 CR3: 0000000078b36000 CR4: 00000000000006e0 [ 82.447104] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 82.447561] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 82.448012] Call Trace: [ 82.448164] queue_delayed_work_on+0x6d/0x80 [ 82.448472] __pg_init_all_paths+0x7b/0xf0 [ 82.448714] pg_init_all_paths+0x26/0x40 [ 82.448980] __multipath_map_bio.isra.0+0x84/0x210 [ 82.449267] __map_bio+0x3c/0x1f0 [ 82.449468] __split_and_process_non_flush+0x14a/0x1b0 [ 82.449775] __split_and_process_bio+0xde/0x340 [ 82.450045] ? dm_get_live_table+0x5/0xb0 [ 82.450278] dm_process_bio+0x98/0x290 [ 82.450518] dm_make_request+0x54/0x120 [ 82.450778] generic_make_request+0xd2/0x3e0 [ 82.451038] ? submit_bio+0x3c/0x150 [ 82.451278] submit_bio+0x3c/0x150 [ 82.451492] mpage_readpages+0x129/0x160 [ 82.451756] ? bdev_evict_inode+0x1d0/0x1d0 [ 82.452033] read_pages+0x72/0x170 [ 82.452260] __do_page_cache_readahead+0x1ba/0x1d0 [ 82.452624] force_page_cache_readahead+0x96/0x110 [ 82.452903] generic_file_read_iter+0x84f/0xae0 [ 82.453192] ? __seccomp_filter+0x7c/0x670 [ 82.453547] new_sync_read+0x10e/0x190 [ 82.453883] vfs_read+0x9d/0x150 [ 82.454172] ksys_read+0x65/0xe0 [ 82.454466] do_syscall_64+0x4e/0x210 [ 82.454828] entry_SYSCALL_64_after_hwframe+0x49/0xbe [...] [ 82.462501] ---[ end trace bb39975e9cf45daa ]---
Cc: stable@vger.kernel.org Signed-off-by: Gabriel Krisman Bertazi krisman@collabora.com Signed-off-by: Mike Snitzer snitzer@redhat.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/md/dm-mpath.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/md/dm-mpath.c +++ b/drivers/md/dm-mpath.c @@ -586,10 +586,12 @@ static struct pgpath *__map_bio(struct m
/* Do we need to select a new pgpath? */ pgpath = READ_ONCE(m->current_pgpath); - queue_io = test_bit(MPATHF_QUEUE_IO, &m->flags); - if (!pgpath || !queue_io) + if (!pgpath || !test_bit(MPATHF_QUEUE_IO, &m->flags)) pgpath = choose_pgpath(m, bio->bi_iter.bi_size);
+ /* MPATHF_QUEUE_IO might have been cleared by choose_pgpath. */ + queue_io = test_bit(MPATHF_QUEUE_IO, &m->flags); + if ((pgpath && queue_io) || (!pgpath && test_bit(MPATHF_QUEUE_IF_NO_PATH, &m->flags))) { /* Queue for the daemon to resubmit */
From: Martin Wilck mwilck@suse.com
commit 856e152a3c08bf7987cbd41900741d83d9cddc8e upstream.
The purpose of the UNLOADING flag is to avoid port login procedures to continue when a controller is in the process of shutting down. It makes sense to set this flag before starting session teardown.
Furthermore, use atomic test_and_set_bit() to avoid the shutdown being run multiple times in parallel. In qla2x00_disable_board_on_pci_error(), the test for UNLOADING is postponed until after the check for an already disabled PCI board.
Link: https://lore.kernel.org/r/20200421204621.19228-2-mwilck@suse.com Fixes: 45235022da99 ("scsi: qla2xxx: Fix driver unload by shutting down chip") Reviewed-by: Arun Easi aeasi@marvell.com Reviewed-by: Daniel Wagner dwagner@suse.de Reviewed-by: Roman Bolshakov r.bolshakov@yadro.com Reviewed-by: Himanshu Madhani himanshu.madhani@oracle.com Signed-off-by: Martin Wilck mwilck@suse.com Signed-off-by: Martin K. Petersen martin.petersen@oracle.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/scsi/qla2xxx/qla_os.c | 32 ++++++++++++++------------------ 1 file changed, 14 insertions(+), 18 deletions(-)
--- a/drivers/scsi/qla2xxx/qla_os.c +++ b/drivers/scsi/qla2xxx/qla_os.c @@ -3654,6 +3654,13 @@ qla2x00_remove_one(struct pci_dev *pdev) } qla2x00_wait_for_hba_ready(base_vha);
+ /* + * if UNLOADING flag is already set, then continue unload, + * where it was set first. + */ + if (test_and_set_bit(UNLOADING, &base_vha->dpc_flags)) + return; + if (IS_QLA25XX(ha) || IS_QLA2031(ha) || IS_QLA27XX(ha)) { if (ha->flags.fw_started) qla2x00_abort_isp_cleanup(base_vha); @@ -3671,15 +3678,6 @@ qla2x00_remove_one(struct pci_dev *pdev)
qla2x00_wait_for_sess_deletion(base_vha);
- /* - * if UNLOAD flag is already set, then continue unload, - * where it was set first. - */ - if (test_bit(UNLOADING, &base_vha->dpc_flags)) - return; - - set_bit(UNLOADING, &base_vha->dpc_flags); - qla_nvme_delete(base_vha);
dma_free_coherent(&ha->pdev->dev, @@ -5845,13 +5843,6 @@ qla2x00_disable_board_on_pci_error(struc struct pci_dev *pdev = ha->pdev; scsi_qla_host_t *base_vha = pci_get_drvdata(ha->pdev);
- /* - * if UNLOAD flag is already set, then continue unload, - * where it was set first. - */ - if (test_bit(UNLOADING, &base_vha->dpc_flags)) - return; - ql_log(ql_log_warn, base_vha, 0x015b, "Disabling adapter.\n");
@@ -5862,9 +5853,14 @@ qla2x00_disable_board_on_pci_error(struc return; }
- qla2x00_wait_for_sess_deletion(base_vha); + /* + * if UNLOADING flag is already set, then continue unload, + * where it was set first. + */ + if (test_and_set_bit(UNLOADING, &base_vha->dpc_flags)) + return;
- set_bit(UNLOADING, &base_vha->dpc_flags); + qla2x00_wait_for_sess_deletion(base_vha);
qla2x00_delete_all_vps(ha, base_vha);
From: Martin Wilck mwilck@suse.com
commit 5a263892d7d0b4fe351363f8d1a14c6a75955475 upstream.
qlt_free_session_done() tries to post async PRLO / LOGO, and waits for the completion of these async commands. If UNLOADING is set, this is doomed to timeout, because the async logout command will never complete.
The only way to avoid waiting pointlessly is to fail posting these commands in the first place if the driver is in UNLOADING state. In general, posting any command should be avoided when the driver is UNLOADING.
With this patch, "rmmod qla2xxx" completes without noticeable delay.
Link: https://lore.kernel.org/r/20200421204621.19228-3-mwilck@suse.com Fixes: 45235022da99 ("scsi: qla2xxx: Fix driver unload by shutting down chip") Acked-by: Arun Easi aeasi@marvell.com Reviewed-by: Himanshu Madhani himanshu.madhani@oracle.com Signed-off-by: Martin Wilck mwilck@suse.com Signed-off-by: Martin K. Petersen martin.petersen@oracle.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/scsi/qla2xxx/qla_os.c | 3 +++ 1 file changed, 3 insertions(+)
--- a/drivers/scsi/qla2xxx/qla_os.c +++ b/drivers/scsi/qla2xxx/qla_os.c @@ -4645,6 +4645,9 @@ qla2x00_alloc_work(struct scsi_qla_host struct qla_work_evt *e; uint8_t bail;
+ if (test_bit(UNLOADING, &vha->dpc_flags)) + return NULL; + QLA_VHA_MARK_BUSY(vha, bail); if (bail) return NULL;
From: Aharon Landau aharonl@mellanox.com
commit 2d7e3ff7b6f2c614eb21d0dc348957a47eaffb57 upstream.
GRH fields such as sgid_index, hop limit, et. are set in the QP context when QP is created/modified.
Currently, when query QP is performed, we fill the GRH fields only if the GRH bit is set in the QP context, but this bit is not set for RoCE. Adjust the check so we will set all relevant data for the RoCE too.
Since this data is returned to userspace, the below is an ABI regression.
Fixes: d8966fcd4c25 ("IB/core: Use rdma_ah_attr accessor functions") Link: https://lore.kernel.org/r/20200413132028.930109-1-leon@kernel.org Signed-off-by: Aharon Landau aharonl@mellanox.com Reviewed-by: Maor Gottlieb maorg@mellanox.com Signed-off-by: Leon Romanovsky leonro@mellanox.com Signed-off-by: Jason Gunthorpe jgg@mellanox.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/infiniband/hw/mlx5/qp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/infiniband/hw/mlx5/qp.c +++ b/drivers/infiniband/hw/mlx5/qp.c @@ -4887,7 +4887,9 @@ static void to_rdma_ah_attr(struct mlx5_ rdma_ah_set_path_bits(ah_attr, path->grh_mlid & 0x7f); rdma_ah_set_static_rate(ah_attr, path->static_rate ? path->static_rate - 5 : 0); - if (path->grh_mlid & (1 << 7)) { + + if (path->grh_mlid & (1 << 7) || + ah_attr->type == RDMA_AH_ATTR_TYPE_ROCE) { u32 tc_fl = be32_to_cpu(path->tclass_flowlabel);
rdma_ah_set_grh(ah_attr, NULL,
From: Alaa Hleihel alaa@mellanox.com
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/20200413132235.930642-1-leon@kernel.org Signed-off-by: Alaa Hleihel alaa@mellanox.com Reviewed-by: Maor Gottlieb maorg@mellanox.com Signed-off-by: Leon Romanovsky leonro@mellanox.com Signed-off-by: Jason Gunthorpe jgg@mellanox.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- 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 @@ -1606,8 +1606,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 */
From: Leon Romanovsky leonro@mellanox.com
commit 0fb00941dc63990a10951146df216fc7b0e20bc2 upstream.
FDs can only be used on the ufile that created them, they cannot be mixed to other ufiles. We are lacking a check to prevent it.
BUG: KASAN: null-ptr-deref in atomic64_sub_and_test include/asm-generic/atomic-instrumented.h:1547 [inline] BUG: KASAN: null-ptr-deref in atomic_long_sub_and_test include/asm-generic/atomic-long.h:460 [inline] BUG: KASAN: null-ptr-deref in fput_many+0x1a/0x140 fs/file_table.c:336 Write of size 8 at addr 0000000000000038 by task syz-executor179/284
CPU: 0 PID: 284 Comm: syz-executor179 Not tainted 5.5.0-rc5+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x94/0xce lib/dump_stack.c:118 __kasan_report+0x18f/0x1b7 mm/kasan/report.c:510 kasan_report+0xe/0x20 mm/kasan/common.c:639 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x15d/0x1b0 mm/kasan/generic.c:192 atomic64_sub_and_test include/asm-generic/atomic-instrumented.h:1547 [inline] atomic_long_sub_and_test include/asm-generic/atomic-long.h:460 [inline] fput_many+0x1a/0x140 fs/file_table.c:336 rdma_lookup_put_uobject+0x85/0x130 drivers/infiniband/core/rdma_core.c:692 uobj_put_read include/rdma/uverbs_std_types.h:96 [inline] _ib_uverbs_lookup_comp_file drivers/infiniband/core/uverbs_cmd.c:198 [inline] create_cq+0x375/0xba0 drivers/infiniband/core/uverbs_cmd.c:1006 ib_uverbs_create_cq+0x114/0x140 drivers/infiniband/core/uverbs_cmd.c:1089 ib_uverbs_write+0xaa5/0xdf0 drivers/infiniband/core/uverbs_main.c:769 __vfs_write+0x7c/0x100 fs/read_write.c:494 vfs_write+0x168/0x4a0 fs/read_write.c:558 ksys_write+0xc8/0x200 fs/read_write.c:611 do_syscall_64+0x9c/0x390 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x44ef99 Code: 00 b8 00 01 00 00 eb e1 e8 74 1c 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c4 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffc0b74c028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007ffc0b74c030 RCX: 000000000044ef99 RDX: 0000000000000040 RSI: 0000000020000040 RDI: 0000000000000005 RBP: 00007ffc0b74c038 R08: 0000000000401830 R09: 0000000000401830 R10: 00007ffc0b74c038 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00000000006be018 R15: 0000000000000000
Fixes: cf8966b3477d ("IB/core: Add support for fd objects") Link: https://lore.kernel.org/r/20200421082929.311931-2-leon@kernel.org Suggested-by: Jason Gunthorpe jgg@mellanox.com Signed-off-by: Leon Romanovsky leonro@mellanox.com Signed-off-by: Jason Gunthorpe jgg@mellanox.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/infiniband/core/rdma_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/core/rdma_core.c +++ b/drivers/infiniband/core/rdma_core.c @@ -381,7 +381,7 @@ lookup_get_fd_uobject(const struct uverb * and the caller is expected to ensure that uverbs_close_fd is never * done while a call top lookup is possible. */ - if (f->f_op != fd_type->fops) { + if (f->f_op != fd_type->fops || uobject->ufile != ufile) { fput(f); return ERR_PTR(-EBADF); }
From: Leon Romanovsky leonro@mellanox.com
commit f0abc761bbb9418876cc4d1ebc473e4ea6352e42 upstream.
The call to ->lookup_put() was too early and it caused an unlock of the read/write protection of the uobject after the FD was put. This allows a race:
CPU1 CPU2 rdma_lookup_put_uobject() lookup_put_fd_uobject() fput() fput() uverbs_uobject_fd_release() WARN_ON(uverbs_try_lock_object(uobj, UVERBS_LOOKUP_WRITE)); atomic_dec(usecnt)
Fix the code by changing the order, first unlock and call to ->lookup_put() after that.
Fixes: 3832125624b7 ("IB/core: Add support for idr types") Link: https://lore.kernel.org/r/20200423060122.6182-1-leon@kernel.org Suggested-by: Jason Gunthorpe jgg@mellanox.com Signed-off-by: Leon Romanovsky leonro@mellanox.com Signed-off-by: Jason Gunthorpe jgg@mellanox.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/infiniband/core/rdma_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/core/rdma_core.c +++ b/drivers/infiniband/core/rdma_core.c @@ -697,7 +697,6 @@ void rdma_lookup_put_uobject(struct ib_u enum rdma_lookup_mode mode) { assert_uverbs_usecnt(uobj, mode); - uobj->uapi_object->type_class->lookup_put(uobj, mode); /* * In order to unlock an object, either decrease its usecnt for * read access or zero it in case of exclusive access. See @@ -714,6 +713,7 @@ void rdma_lookup_put_uobject(struct ib_u break; }
+ uobj->uapi_object->type_class->lookup_put(uobj, mode); /* Pairs with the kref obtained by type->lookup_get */ uverbs_uobject_put(uobj); }
From: Yan Zhao yan.y.zhao@intel.com
commit 0ea971f8dcd6dee78a9a30ea70227cf305f11ff7 upstream.
add parentheses to avoid possible vaddr overflow.
Fixes: a54eb55045ae ("vfio iommu type1: Add support for mediated devices") Signed-off-by: Yan Zhao yan.y.zhao@intel.com Signed-off-by: Alex Williamson alex.williamson@redhat.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/vfio/vfio_iommu_type1.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/vfio/vfio_iommu_type1.c +++ b/drivers/vfio/vfio_iommu_type1.c @@ -598,7 +598,7 @@ static int vfio_iommu_type1_pin_pages(vo continue; }
- remote_vaddr = dma->vaddr + iova - dma->iova; + remote_vaddr = dma->vaddr + (iova - dma->iova); ret = vfio_pin_page_external(dma, remote_vaddr, &phys_pfn[i], do_accounting); if (ret)
On Mon 2020-05-04 19:57:34, Greg Kroah-Hartman wrote:
From: Yan Zhao yan.y.zhao@intel.com
commit 0ea971f8dcd6dee78a9a30ea70227cf305f11ff7 upstream.
add parentheses to avoid possible vaddr overflow.
AFAICT the values are unsigned, so yes, this is nice cleanup, but it does not really fix any problem, right? IOW it overflows, then underflows, but the result is still correct...
Best regards, Pavel
Fixes: a54eb55045ae ("vfio iommu type1: Add support for mediated devices") Signed-off-by: Yan Zhao yan.y.zhao@intel.com Signed-off-by: Alex Williamson alex.williamson@redhat.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
drivers/vfio/vfio_iommu_type1.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/vfio/vfio_iommu_type1.c +++ b/drivers/vfio/vfio_iommu_type1.c @@ -598,7 +598,7 @@ static int vfio_iommu_type1_pin_pages(vo continue; }
remote_vaddr = dma->vaddr + iova - dma->iova;
ret = vfio_pin_page_external(dma, remote_vaddr, &phys_pfn[i], do_accounting); if (ret)remote_vaddr = dma->vaddr + (iova - dma->iova);
From: Sean Christopherson sean.j.christopherson@intel.com
commit 5cbf3264bc715e9eb384e2b68601f8c02bb9a61d upstream.
Use follow_pfn() to get the PFN of a PFNMAP VMA instead of assuming that vma->vm_pgoff holds the base PFN of the VMA. This fixes a bug where attempting to do VFIO_IOMMU_MAP_DMA on an arbitrary PFNMAP'd region of memory calculates garbage for the PFN.
Hilariously, this only got detected because the first "PFN" calculated by vaddr_get_pfn() is PFN 0 (vma->vm_pgoff==0), and iommu_iova_to_phys() uses PA==0 as an error, which triggers a WARN in vfio_unmap_unpin() because the translation "failed". PFN 0 is now unconditionally reserved on x86 in order to mitigate L1TF, which causes is_invalid_reserved_pfn() to return true and in turns results in vaddr_get_pfn() returning success for PFN 0. Eventually the bogus calculation runs into PFNs that aren't reserved and leads to failure in vfio_pin_map_dma(). The subsequent call to vfio_remove_dma() attempts to unmap PFN 0 and WARNs.
WARNING: CPU: 8 PID: 5130 at drivers/vfio/vfio_iommu_type1.c:750 vfio_unmap_unpin+0x2e1/0x310 [vfio_iommu_type1] Modules linked in: vfio_pci vfio_virqfd vfio_iommu_type1 vfio ... CPU: 8 PID: 5130 Comm: sgx Tainted: G W 5.6.0-rc5-705d787c7fee-vfio+ #3 Hardware name: Intel Corporation Mehlow UP Server Platform/Moss Beach Server, BIOS CNLSE2R1.D00.X119.B49.1803010910 03/01/2018 RIP: 0010:vfio_unmap_unpin+0x2e1/0x310 [vfio_iommu_type1] Code: <0f> 0b 49 81 c5 00 10 00 00 e9 c5 fe ff ff bb 00 10 00 00 e9 3d fe RSP: 0018:ffffbeb5039ebda8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff9a55cbf8d480 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff9a52b771c200 RBP: 0000000000000000 R08: 0000000000000040 R09: 00000000fffffff2 R10: 0000000000000001 R11: ffff9a51fa896000 R12: 0000000184010000 R13: 0000000184000000 R14: 0000000000010000 R15: ffff9a55cb66ea08 FS: 00007f15d3830b40(0000) GS:ffff9a55d5600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000561cf39429e0 CR3: 000000084f75f005 CR4: 00000000003626e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vfio_remove_dma+0x17/0x70 [vfio_iommu_type1] vfio_iommu_type1_ioctl+0x9e3/0xa7b [vfio_iommu_type1] ksys_ioctl+0x92/0xb0 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x4c/0x180 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f15d04c75d7 Code: <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 f7 d8 64 89 01 48
Fixes: 73fa0d10d077 ("vfio: Type1 IOMMU implementation") Signed-off-by: Sean Christopherson sean.j.christopherson@intel.com Signed-off-by: Alex Williamson alex.williamson@redhat.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/vfio/vfio_iommu_type1.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/vfio/vfio_iommu_type1.c +++ b/drivers/vfio/vfio_iommu_type1.c @@ -385,8 +385,8 @@ static int vaddr_get_pfn(struct mm_struc vma = find_vma_intersection(mm, vaddr, vaddr + 1);
if (vma && vma->vm_flags & VM_PFNMAP) { - *pfn = ((vaddr - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff; - if (is_invalid_reserved_pfn(*pfn)) + if (!follow_pfn(vma, vaddr, pfn) && + is_invalid_reserved_pfn(*pfn)) ret = 0; }
From: Tang Bin tangbin@cmss.chinamobile.com
commit b52649aee6243ea661905bdc5fbe28cc5f6dec76 upstream.
The function qcom_iommu_device_probe() does not perform sufficient error checking after executing devm_ioremap_resource(), which can result in crashes if a critical error path is encountered.
Fixes: 0ae349a0f33f ("iommu/qcom: Add qcom_iommu") Signed-off-by: Tang Bin tangbin@cmss.chinamobile.com Reviewed-by: Bjorn Andersson bjorn.andersson@linaro.org Link: https://lore.kernel.org/r/20200418134703.1760-1-tangbin@cmss.chinamobile.com Signed-off-by: Joerg Roedel jroedel@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/iommu/qcom_iommu.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/iommu/qcom_iommu.c +++ b/drivers/iommu/qcom_iommu.c @@ -797,8 +797,11 @@ static int qcom_iommu_device_probe(struc qcom_iommu->dev = dev;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (res) + if (res) { qcom_iommu->local_base = devm_ioremap_resource(dev, res); + if (IS_ERR(qcom_iommu->local_base)) + return PTR_ERR(qcom_iommu->local_base); + }
qcom_iommu->iface_clk = devm_clk_get(dev, "iface"); if (IS_ERR(qcom_iommu->iface_clk)) {
From: David Disseldorp ddiss@suse.de
commit 1d2ff149b263c9325875726a7804a0c75ef7112e upstream.
SBC4 specifies that WRITE SAME requests with the UNMAP bit set to zero "shall perform the specified write operation to each LBA specified by the command". Commit 2237498f0b5c ("target/iblock: Convert WRITE_SAME to blkdev_issue_zeroout") modified the iblock backend to call blkdev_issue_zeroout() when handling WRITE SAME requests with UNMAP=0 and a zero data segment.
The iblock blkdev_issue_zeroout() call incorrectly provides a flags parameter of 0 (bool false), instead of BLKDEV_ZERO_NOUNMAP. The bool false parameter reflects the blkdev_issue_zeroout() API prior to commit ee472d835c26 ("block: add a flags argument to (__)blkdev_issue_zeroout") which was merged shortly before 2237498f0b5c.
Link: https://lore.kernel.org/r/20200419163109.11689-1-ddiss@suse.de Fixes: 2237498f0b5c ("target/iblock: Convert WRITE_SAME to blkdev_issue_zeroout") Reviewed-by: Bart Van Assche bvanassche@acm.org Signed-off-by: David Disseldorp ddiss@suse.de Signed-off-by: Martin K. Petersen martin.petersen@oracle.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/target/target_core_iblock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/target/target_core_iblock.c +++ b/drivers/target/target_core_iblock.c @@ -445,7 +445,7 @@ iblock_execute_zero_out(struct block_dev target_to_linux_sector(dev, cmd->t_task_lba), target_to_linux_sector(dev, sbc_get_write_same_sectors(cmd)), - GFP_KERNEL, false); + GFP_KERNEL, BLKDEV_ZERO_NOUNMAP); if (ret) return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
From: Suravee Suthikulpanit suravee.suthikulpanit@amd.com
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 suravee.suthikulpanit@amd.com Link: https://lore.kernel.org/r/1587562202-14183-1-git-send-email-suravee.suthikul... Signed-off-by: Joerg Roedel jroedel@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- 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 @@ -2836,7 +2836,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) {
From: Arnd Bergmann arnd@arndb.de
commit 5ce00760a84848d008554c693ceb6286f4d9c509 upstream.
gcc-10 points out a few instances of suspicious integer arithmetic leading to value truncation:
sound/isa/opti9xx/opti92x-ad1848.c: In function 'snd_opti9xx_configure': sound/isa/opti9xx/opti92x-ad1848.c:322:43: error: overflow in conversion from 'int' to 'unsigned char' changes value from '(int)snd_opti9xx_read(chip, 3) & -256 | 240' to '240' [-Werror=overflow] 322 | (snd_opti9xx_read(chip, reg) & ~(mask)) | ((value) & (mask))) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~ sound/isa/opti9xx/opti92x-ad1848.c:351:3: note: in expansion of macro 'snd_opti9xx_write_mask' 351 | snd_opti9xx_write_mask(chip, OPTi9XX_MC_REG(3), 0xf0, 0xff); | ^~~~~~~~~~~~~~~~~~~~~~ sound/isa/opti9xx/miro.c: In function 'snd_miro_configure': sound/isa/opti9xx/miro.c:873:40: error: overflow in conversion from 'int' to 'unsigned char' changes value from '(int)snd_miro_read(chip, 3) & -256 | 240' to '240' [-Werror=overflow] 873 | (snd_miro_read(chip, reg) & ~(mask)) | ((value) & (mask))) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~ sound/isa/opti9xx/miro.c:1010:3: note: in expansion of macro 'snd_miro_write_mask' 1010 | snd_miro_write_mask(chip, OPTi9XX_MC_REG(3), 0xf0, 0xff); | ^~~~~~~~~~~~~~~~~~~
These are all harmless here as only the low 8 bit are passed down anyway. Change the macros to inline functions to make the code more readable and also avoid the warning.
Strictly speaking those functions also need locking to make the read/write pair atomic, but it seems unlikely that anyone would still run into that issue.
Fixes: 1841f613fd2e ("[ALSA] Add snd-miro driver") Signed-off-by: Arnd Bergmann arnd@arndb.de Link: https://lore.kernel.org/r/20200429190216.85919-1-arnd@arndb.de Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- sound/isa/opti9xx/miro.c | 9 ++++++--- sound/isa/opti9xx/opti92x-ad1848.c | 9 ++++++--- 2 files changed, 12 insertions(+), 6 deletions(-)
--- a/sound/isa/opti9xx/miro.c +++ b/sound/isa/opti9xx/miro.c @@ -880,10 +880,13 @@ static void snd_miro_write(struct snd_mi spin_unlock_irqrestore(&chip->lock, flags); }
+static inline void snd_miro_write_mask(struct snd_miro *chip, + unsigned char reg, unsigned char value, unsigned char mask) +{ + unsigned char oldval = snd_miro_read(chip, reg);
-#define snd_miro_write_mask(chip, reg, value, mask) \ - snd_miro_write(chip, reg, \ - (snd_miro_read(chip, reg) & ~(mask)) | ((value) & (mask))) + snd_miro_write(chip, reg, (oldval & ~mask) | (value & mask)); +}
/* * Proc Interface --- a/sound/isa/opti9xx/opti92x-ad1848.c +++ b/sound/isa/opti9xx/opti92x-ad1848.c @@ -329,10 +329,13 @@ static void snd_opti9xx_write(struct snd }
-#define snd_opti9xx_write_mask(chip, reg, value, mask) \ - snd_opti9xx_write(chip, reg, \ - (snd_opti9xx_read(chip, reg) & ~(mask)) | ((value) & (mask))) +static inline void snd_opti9xx_write_mask(struct snd_opti9xx *chip, + unsigned char reg, unsigned char value, unsigned char mask) +{ + unsigned char oldval = snd_opti9xx_read(chip, reg);
+ snd_opti9xx_write(chip, reg, (oldval & ~mask) | (value & mask)); +}
static int snd_opti9xx_configure(struct snd_opti9xx *chip, long port,
From: Andreas Gruenbacher agruenba@redhat.com
commit 7648f939cb919b9d15c21fff8cd9eba908d595dc upstream.
nfs3_set_acl keeps track of the acl it allocated locally to determine if an acl needs to be released at the end. This results in a memory leak when the function allocates an acl as well as a default acl. Fix by releasing acls that differ from the acl originally passed into nfs3_set_acl.
Fixes: b7fa0554cf1b ("[PATCH] NFS: Add support for NFSv3 ACLs") Reported-by: Xiyu Yang xiyuyang19@fudan.edu.cn Signed-off-by: Andreas Gruenbacher agruenba@redhat.com Signed-off-by: Trond Myklebust trond.myklebust@hammerspace.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- fs/nfs/nfs3acl.c | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 deletions(-)
--- a/fs/nfs/nfs3acl.c +++ b/fs/nfs/nfs3acl.c @@ -255,37 +255,45 @@ int nfs3_proc_setacls(struct inode *inod
int nfs3_set_acl(struct inode *inode, struct posix_acl *acl, int type) { - struct posix_acl *alloc = NULL, *dfacl = NULL; + struct posix_acl *orig = acl, *dfacl = NULL, *alloc; int status;
if (S_ISDIR(inode->i_mode)) { switch(type) { case ACL_TYPE_ACCESS: - alloc = dfacl = get_acl(inode, ACL_TYPE_DEFAULT); + alloc = get_acl(inode, ACL_TYPE_DEFAULT); if (IS_ERR(alloc)) goto fail; + dfacl = alloc; break;
case ACL_TYPE_DEFAULT: - dfacl = acl; - alloc = acl = get_acl(inode, ACL_TYPE_ACCESS); + alloc = get_acl(inode, ACL_TYPE_ACCESS); if (IS_ERR(alloc)) goto fail; + dfacl = acl; + acl = alloc; break; } }
if (acl == NULL) { - alloc = acl = posix_acl_from_mode(inode->i_mode, GFP_KERNEL); + alloc = posix_acl_from_mode(inode->i_mode, GFP_KERNEL); if (IS_ERR(alloc)) goto fail; + acl = alloc; } status = __nfs3_proc_setacls(inode, acl, dfacl); - posix_acl_release(alloc); +out: + if (acl != orig) + posix_acl_release(acl); + if (dfacl != orig) + posix_acl_release(dfacl); return status;
fail: - return PTR_ERR(alloc); + status = PTR_ERR(alloc); + goto out; }
const struct xattr_handler *nfs3_xattr_handlers[] = {
From: Andy Shevchenko andriy.shevchenko@linux.intel.com
commit b9f960201249f20deea586b4ec814669b4c6b1c0 upstream.
Under some circumstances, i.e. when test is still running and about to time out and user runs, for example,
grep -H . /sys/module/dmatest/parameters/*
the iterations parameter is not respected and test is going on and on until user gives
echo 0 > /sys/module/dmatest/parameters/run
This is not what expected.
The history of this bug is interesting. I though that the commit 2d88ce76eb98 ("dmatest: add a 'wait' parameter") is a culprit, but looking closer to the code I think it simple revealed the broken logic from the day one, i.e. in the commit 0a2ff57d6fba ("dmaengine: dmatest: add a maximum number of test iterations") which adds iterations parameter.
So, to the point, the conditional of checking the thread to be stopped being first part of conjunction logic prevents to check iterations. Thus, we have to always check both conditions to be able to stop after given iterations.
Since it wasn't visible before second commit appeared, I add a respective Fixes tag.
Fixes: 2d88ce76eb98 ("dmatest: add a 'wait' parameter") Cc: Dan Williams dan.j.williams@intel.com Cc: Nicolas Ferre nicolas.ferre@microchip.com Signed-off-by: Andy Shevchenko andriy.shevchenko@linux.intel.com Acked-by: Nicolas Ferre nicolas.ferre@microchip.com Link: https://lore.kernel.org/r/20200424161147.16895-1-andriy.shevchenko@linux.int... Signed-off-by: Vinod Koul vkoul@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/dma/dmatest.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/dma/dmatest.c +++ b/drivers/dma/dmatest.c @@ -567,8 +567,8 @@ static int dmatest_func(void *data) flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT;
ktime = ktime_get(); - while (!kthread_should_stop() - && !(params->iterations && total_tests >= params->iterations)) { + while (!(kthread_should_stop() || + (params->iterations && total_tests >= params->iterations))) { struct dma_async_tx_descriptor *tx = NULL; struct dmaengine_unmap_data *um; dma_addr_t *dsts;
Hi!
So, to the point, the conditional of checking the thread to be stopped being first part of conjunction logic prevents to check iterations. Thus, we have to always check both conditions to be able to stop after given iterations.
I ... don't understand. AFAICT the code is equivalent. Both && and || operators permit "short" execution... but second part of expression has no sideeffects, so...
@@ -567,8 +567,8 @@ static int dmatest_func(void *data) flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT; ktime = ktime_get();
- while (!kthread_should_stop()
&& !(params->iterations && total_tests >= params->iterations)) {
- while (!(kthread_should_stop() ||
struct dma_async_tx_descriptor *tx = NULL; struct dmaengine_unmap_data *um; dma_addr_t *dsts;(params->iterations && total_tests >= params->iterations))) {
let a = kthread_should_stop() let b = (params->iterations && total_tests >= params->iterations)
You are changing !a & !b into !(a | b). But that's equivalent expression. I hate to admit, but I had to draw truth table to prove that.
!a & !b 0 0 -> 1 else -> 0
!(a | b) 0 0 -> 1 else -> 0 What am I missing?
Best regards, Pavel
On Tue, May 5, 2020 at 3:37 PM Pavel Machek pavel@denx.de wrote:
So, to the point, the conditional of checking the thread to be stopped being first part of conjunction logic prevents to check iterations. Thus, we have to always check both conditions to be able to stop after given iterations.
I ... don't understand. AFAICT the code is equivalent. Both && and || operators permit "short" execution... but second part of expression has no sideeffects, so...
..
You are changing !a & !b into !(a | b). But that's equivalent expression. I hate to admit, but I had to draw truth table to prove that.
!a & !b 0 0 -> 1 else -> 0
!(a | b) 0 0 -> 1 else -> 0
What am I missing?
Basic stuff. Compiler doesn't consider second part of conjunction when first one (see operator precedence) is already false, so, it means:
a & b 0 x -> false 1 0 -> false 1 1 -> true
x is not being considered at all. So, logically it's equivalent, run-time it's not.
On Tue 2020-05-05 15:51:16, Andy Shevchenko wrote:
On Tue, May 5, 2020 at 3:37 PM Pavel Machek pavel@denx.de wrote:
So, to the point, the conditional of checking the thread to be stopped being first part of conjunction logic prevents to check iterations. Thus, we have to always check both conditions to be able to stop after given iterations.
I ... don't understand. AFAICT the code is equivalent. Both && and || operators permit "short" execution... but second part of expression has no sideeffects, so...
..
You are changing !a & !b into !(a | b). But that's equivalent expression. I hate to admit, but I had to draw truth table to prove that.
...
What am I missing?
Basic stuff. Compiler doesn't consider second part of conjunction when first one (see operator precedence) is already false, so, it means:
a & b 0 x -> false 1 0 -> false 1 1 -> true
x is not being considered at all. So, logically it's equivalent, run-time it's not.
Yeah, I pointed that out above. Both && and || permit short execution. But that does not matter, as neither "params->iterations" nor "total_tests >= params->iterations" have side effects.
Where is the runtime difference?
- while (!kthread_should_stop() - && !(params->iterations && total_tests >= - params->iterations)) { + while (!(kthread_should_stop() || + (params->iterations && total_tests >= params->iterations))) {
Pavel
On Tue, May 5, 2020 at 3:58 PM Pavel Machek pavel@denx.de wrote:
On Tue 2020-05-05 15:51:16, Andy Shevchenko wrote:
On Tue, May 5, 2020 at 3:37 PM Pavel Machek pavel@denx.de wrote:
So, to the point, the conditional of checking the thread to be stopped being first part of conjunction logic prevents to check iterations. Thus, we have to always check both conditions to be able to stop after given iterations.
I ... don't understand. AFAICT the code is equivalent. Both && and || operators permit "short" execution... but second part of expression has no sideeffects, so...
..
You are changing !a & !b into !(a | b). But that's equivalent expression. I hate to admit, but I had to draw truth table to prove that.
...
What am I missing?
Basic stuff. Compiler doesn't consider second part of conjunction when first one (see operator precedence) is already false, so, it means:
a & b 0 x -> false 1 0 -> false 1 1 -> true
x is not being considered at all. So, logically it's equivalent, run-time it's not.
Yeah, I pointed that out above. Both && and || permit short execution. But that does not matter, as neither "params->iterations" nor "total_tests >= params->iterations" have side effects.
Where is the runtime difference?
We have to check *both* conditions. If we don't check iterations, we just wait indefinitely until somebody tells us to stop. Everything in the commit message and mentioned there commit IDs which you may check.
while (!kthread_should_stop()
&& !(params->iterations && total_tests >=
params->iterations)) {
while (!(kthread_should_stop() ||
(params->iterations && total_tests >= params->iterations))) {
On Tue 2020-05-05 16:19:11, Andy Shevchenko wrote:
On Tue, May 5, 2020 at 3:58 PM Pavel Machek pavel@denx.de wrote:
On Tue 2020-05-05 15:51:16, Andy Shevchenko wrote:
On Tue, May 5, 2020 at 3:37 PM Pavel Machek pavel@denx.de wrote:
So, to the point, the conditional of checking the thread to be stopped being first part of conjunction logic prevents to check iterations. Thus, we have to always check both conditions to be able to stop after given iterations.
I ... don't understand. AFAICT the code is equivalent. Both && and || operators permit "short" execution... but second part of expression has no sideeffects, so...
..
You are changing !a & !b into !(a | b). But that's equivalent expression. I hate to admit, but I had to draw truth table to prove that.
...
What am I missing?
Basic stuff. Compiler doesn't consider second part of conjunction when first one (see operator precedence) is already false, so, it means:
a & b 0 x -> false 1 0 -> false 1 1 -> true
x is not being considered at all. So, logically it's equivalent, run-time it's not.
Yeah, I pointed that out above. Both && and || permit short execution. But that does not matter, as neither "params->iterations" nor "total_tests >= params->iterations" have side effects.
Where is the runtime difference?
We have to check *both* conditions. If we don't check iterations, we just wait indefinitely until somebody tells us to stop. Everything in the commit message and mentioned there commit IDs which you may check.
No.
If kthread_should_stop() is true, we break the loop. Both old code and new code does that. Neither old nor new code checks the "params->iterations && total_tests >=dparams->iterations" condition, as both && and || do short execution).
If you wanted both conditions to always evaluate, you'd have to do
# while (!kthread_should_stop() # & !(params->iterations && total_tests >= # params->iterations)) {
(note && -> &). But, again, there's no reason to do that, as second part of expression does not have side effects.
while (!kthread_should_stop()
&& !(params->iterations && total_tests >=
params->iterations)) {
while (!(kthread_should_stop() ||
(params->iterations && total_tests >= params->iterations))) {
Best regards, Pavel
On Tue, May 5, 2020 at 4:37 PM Pavel Machek pavel@denx.de wrote:
On Tue 2020-05-05 16:19:11, Andy Shevchenko wrote:
On Tue, May 5, 2020 at 3:58 PM Pavel Machek pavel@denx.de wrote:
On Tue 2020-05-05 15:51:16, Andy Shevchenko wrote:
On Tue, May 5, 2020 at 3:37 PM Pavel Machek pavel@denx.de wrote:
So, to the point, the conditional of checking the thread to be stopped being first part of conjunction logic prevents to check iterations. Thus, we have to always check both conditions
vvv
to be able to stop after given iterations.
^^^
...
Yeah, I pointed that out above. Both && and || permit short execution. But that does not matter, as neither "params->iterations" nor "total_tests >= params->iterations" have side effects.
Where is the runtime difference?
We have to check *both* conditions. If we don't check iterations, we just wait indefinitely until somebody tells us to stop. Everything in the commit message and mentioned there commit IDs which you may check.
No.
Yes. Please, read carefully the commit message (for your convenience I emphasized above). I don't want to spend time on this basics stuff anymore.
If kthread_should_stop() is true, we break the loop. Both old code and new code does that. Neither old nor new code checks the "params->iterations && total_tests >=dparams->iterations" condition, as both && and || do short execution).
If you wanted both conditions to always evaluate, you'd have to do
# while (!kthread_should_stop() # & !(params->iterations && total_tests >= # params->iterations)) {
(note && -> &). But, again, there's no reason to do that, as second part of expression does not have side effects.
It fixes a bug in the code, try with and without this change. (I can reproduce it here)
On Tue 2020-05-05 17:05:37, Andy Shevchenko wrote:
On Tue, May 5, 2020 at 4:37 PM Pavel Machek pavel@denx.de wrote:
On Tue 2020-05-05 16:19:11, Andy Shevchenko wrote:
On Tue, May 5, 2020 at 3:58 PM Pavel Machek pavel@denx.de wrote:
On Tue 2020-05-05 15:51:16, Andy Shevchenko wrote:
On Tue, May 5, 2020 at 3:37 PM Pavel Machek pavel@denx.de wrote:
> So, to the point, the conditional of checking the thread to be stopped being > first part of conjunction logic prevents to check iterations. Thus, we have to > always check both conditions
vvv
> to be able to stop after given iterations.
^^^
_If_ you are already stopping due to kthread_should_stop(), you don't need to check iterations.
If you are not stopping, iterations are always checked.
No, the new code does not "always check both conditions" as you claim.
Yes. Please, read carefully the commit message (for your convenience I emphasized above). I don't want to spend time on this basics stuff anymore.
You may want to go through the basics once more. The change clearly does not do what you said it does; in fact, it does not do anything.
If you wanted both conditions to always evaluate, you'd have to do
# while (!kthread_should_stop() # & !(params->iterations && total_tests >= # params->iterations)) {
(note && -> &). But, again, there's no reason to do that, as second part of expression does not have side effects.
It fixes a bug in the code, try with and without this change. (I can reproduce it here)
I'm not sure if you made mistake during testing, or if you have buggy compiler or what... Pavel
On Tue, May 05, 2020 at 05:05:37PM +0300, Andy Shevchenko wrote:
On Tue, May 5, 2020 at 4:37 PM Pavel Machek pavel@denx.de wrote:
On Tue 2020-05-05 16:19:11, Andy Shevchenko wrote:
On Tue, May 5, 2020 at 3:58 PM Pavel Machek pavel@denx.de wrote:
On Tue 2020-05-05 15:51:16, Andy Shevchenko wrote:
On Tue, May 5, 2020 at 3:37 PM Pavel Machek pavel@denx.de wrote:
Yeah, I pointed that out above. Both && and || permit short execution. But that does not matter, as neither "params->iterations" nor "total_tests >= params->iterations" have side effects.
Where is the runtime difference?
We have to check *both* conditions. If we don't check iterations, we just wait indefinitely until somebody tells us to stop. Everything in the commit message and mentioned there commit IDs which you may check.
No.
Yes. Please, read carefully the commit message (for your convenience I emphasized above). I don't want to spend time on this basics stuff anymore.
I'm a bit confused about this too. Maybe it's too early in the morning, so I wrote this little test program:
#include <stdio.h> #include <stdlib.h>
int main(int argc, char *argv[]) { int a = atoi(argv[1]); int b = atoi(argv[2]);
if (!a && !b) printf("A"); else printf("B");
if (!(a || b)) printf("A"); else printf("B");
printf("\n");
return 0; }
Andy, could you give an example of two values which will print something other than "AA" or "BB"?
Heck, gcc even compiles these two conditions the same way:
if (!a && !b) 11a8: 83 7d f8 00 cmpl $0x0,-0x8(%rbp) 11ac: 75 12 jne 11c0 <main+0x57> 11ae: 83 7d fc 00 cmpl $0x0,-0x4(%rbp) 11b2: 75 0c jne 11c0 <main+0x57> printf("A"); 11b4: bf 41 00 00 00 mov $0x41,%edi 11b9: e8 a2 fe ff ff callq 1060 putchar@plt 11be: eb 0a jmp 11ca <main+0x61> else printf("B"); 11c0: bf 42 00 00 00 mov $0x42,%edi 11c5: e8 96 fe ff ff callq 1060 putchar@plt
if (!(a || b)) 11ca: 83 7d f8 00 cmpl $0x0,-0x8(%rbp) 11ce: 75 12 jne 11e2 <main+0x79> 11d0: 83 7d fc 00 cmpl $0x0,-0x4(%rbp) 11d4: 75 0c jne 11e2 <main+0x79> printf("A"); 11d6: bf 41 00 00 00 mov $0x41,%edi 11db: e8 80 fe ff ff callq 1060 putchar@plt 11e0: eb 0a jmp 11ec <main+0x83> else printf("B"); 11e2: bf 42 00 00 00 mov $0x42,%edi 11e7: e8 74 fe ff ff callq 1060 putchar@plt
On Tue 2020-05-05 11:32:27, Sasha Levin wrote:
On Tue, May 05, 2020 at 05:05:37PM +0300, Andy Shevchenko wrote:
On Tue, May 5, 2020 at 4:37 PM Pavel Machek pavel@denx.de wrote:
On Tue 2020-05-05 16:19:11, Andy Shevchenko wrote:
On Tue, May 5, 2020 at 3:58 PM Pavel Machek pavel@denx.de wrote:
On Tue 2020-05-05 15:51:16, Andy Shevchenko wrote:
On Tue, May 5, 2020 at 3:37 PM Pavel Machek pavel@denx.de wrote:
Yeah, I pointed that out above. Both && and || permit short execution. But that does not matter, as neither "params->iterations" nor "total_tests >= params->iterations" have side effects.
Where is the runtime difference?
We have to check *both* conditions. If we don't check iterations, we just wait indefinitely until somebody tells us to stop. Everything in the commit message and mentioned there commit IDs which you may check.
No.
Yes. Please, read carefully the commit message (for your convenience I emphasized above). I don't want to spend time on this basics stuff anymore.
I'm a bit confused about this too. Maybe it's too early in the morning, so I wrote this little test program:
#include <stdio.h> #include <stdlib.h>
int main(int argc, char *argv[]) { int a = atoi(argv[1]); int b = atoi(argv[2]);
if (!a && !b) printf("A"); else printf("B"); if (!(a || b)) printf("A"); else printf("B"); printf("\n"); return 0;
}
Andy, could you give an example of two values which will print something other than "AA" or "BB"?
The issue here is "sideffects". Does b have to be evaluated at all? There is no difference between
int a, b; if (a && b)
and
if ((!!a) & (!!b)) .
But there would be difference between
int a, b; if (a && b++)
and if ((!!a) & (!!(b++)))
But:
1) && and || behave same way w.r.t. side effects
2) in the patch we are talking about b has no important side effects
Best regards, Pavel
On Tue, May 5, 2020 at 6:57 PM Pavel Machek pavel@denx.de wrote:
On Tue 2020-05-05 11:32:27, Sasha Levin wrote:
On Tue, May 05, 2020 at 05:05:37PM +0300, Andy Shevchenko wrote:
...
I'm a bit confused about this too. Maybe it's too early in the morning, so I wrote this little test program:
#include <stdio.h> #include <stdlib.h>
int main(int argc, char *argv[]) { int a = atoi(argv[1]); int b = atoi(argv[2]);
if (!a && !b) printf("A"); else printf("B"); if (!(a || b)) printf("A"); else printf("B"); printf("\n"); return 0;
}
Andy, could you give an example of two values which will print something other than "AA" or "BB"?
The issue here is "sideffects". Does b have to be evaluated at all? There is no difference between
int a, b; if (a && b)
and
if ((!!a) & (!!b))
.
But there would be difference between
int a, b; if (a && b++)
and if ((!!a) & (!!(b++)))
But:
&& and || behave same way w.r.t. side effects
in the patch we are talking about b has no important side effects
I have to admit that this seems like a luck and the real issue somewhere else. Definitely another test should be performed.
Thank you, Pavel, for pointing this out.
From: Paul Moore paul@paul-moore.com
commit fb73974172ffaaf57a7c42f35424d9aece1a5af6 upstream.
Fix the SELinux netlink_send hook to properly handle multiple netlink messages in a single sk_buff; each message is parsed and subject to SELinux access control. Prior to this patch, SELinux only inspected the first message in the sk_buff.
Cc: stable@vger.kernel.org Reported-by: Dmitry Vyukov dvyukov@google.com Reviewed-by: Stephen Smalley stephen.smalley.work@gmail.com Signed-off-by: Paul Moore paul@paul-moore.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- security/selinux/hooks.c | 70 ++++++++++++++++++++++++++++++----------------- 1 file changed, 45 insertions(+), 25 deletions(-)
--- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -5595,40 +5595,60 @@ static int selinux_tun_dev_open(void *se
static int selinux_nlmsg_perm(struct sock *sk, struct sk_buff *skb) { - int err = 0; - u32 perm; + int rc = 0; + unsigned int msg_len; + unsigned int data_len = skb->len; + unsigned char *data = skb->data; struct nlmsghdr *nlh; struct sk_security_struct *sksec = sk->sk_security; + u16 sclass = sksec->sclass; + u32 perm;
- if (skb->len < NLMSG_HDRLEN) { - err = -EINVAL; - goto out; - } - nlh = nlmsg_hdr(skb); + while (data_len >= nlmsg_total_size(0)) { + nlh = (struct nlmsghdr *)data;
- err = selinux_nlmsg_lookup(sksec->sclass, nlh->nlmsg_type, &perm); - if (err) { - if (err == -EINVAL) { + /* NOTE: the nlmsg_len field isn't reliably set by some netlink + * users which means we can't reject skb's with bogus + * length fields; our solution is to follow what + * netlink_rcv_skb() does and simply skip processing at + * messages with length fields that are clearly junk + */ + if (nlh->nlmsg_len < NLMSG_HDRLEN || nlh->nlmsg_len > data_len) + return 0; + + rc = selinux_nlmsg_lookup(sclass, nlh->nlmsg_type, &perm); + if (rc == 0) { + rc = sock_has_perm(sk, perm); + if (rc) + return rc; + } else if (rc == -EINVAL) { + /* -EINVAL is a missing msg/perm mapping */ pr_warn_ratelimited("SELinux: unrecognized netlink" - " message: protocol=%hu nlmsg_type=%hu sclass=%s" - " pig=%d comm=%s\n", - sk->sk_protocol, nlh->nlmsg_type, - secclass_map[sksec->sclass - 1].name, - task_pid_nr(current), current->comm); - if (!enforcing_enabled(&selinux_state) || - security_get_allow_unknown(&selinux_state)) - err = 0; + " message: protocol=%hu nlmsg_type=%hu sclass=%s" + " pid=%d comm=%s\n", + sk->sk_protocol, nlh->nlmsg_type, + secclass_map[sclass - 1].name, + task_pid_nr(current), current->comm); + if (enforcing_enabled(&selinux_state) && + !security_get_allow_unknown(&selinux_state)) + return rc; + rc = 0; + } else if (rc == -ENOENT) { + /* -ENOENT is a missing socket/class mapping, ignore */ + rc = 0; + } else { + return rc; }
- /* Ignore */ - if (err == -ENOENT) - err = 0; - goto out; + /* move to the next message after applying netlink padding */ + msg_len = NLMSG_ALIGN(nlh->nlmsg_len); + if (msg_len >= data_len) + return 0; + data_len -= msg_len; + data += msg_len; }
- err = sock_has_perm(sk, perm); -out: - return err; + return rc; }
#ifdef CONFIG_NETFILTER
From: Filipe Manana fdmanana@suse.com
commit f135cea30de5f74d5bfb5116682073841fb4af8f upstream.
When we have an inode with a prealloc extent that starts at an offset lower than the i_size and there is another prealloc extent that starts at an offset beyond i_size, we can end up losing part of the first prealloc extent (the part that starts at i_size) and have an implicit hole if we fsync the file and then have a power failure.
Consider the following example with comments explaining how and why it happens.
$ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt
# Create our test file with 2 consecutive prealloc extents, each with a # size of 128Kb, and covering the range from 0 to 256Kb, with a file # size of 0. $ xfs_io -f -c "falloc -k 0 128K" /mnt/foo $ xfs_io -c "falloc -k 128K 128K" /mnt/foo
# Fsync the file to record both extents in the log tree. $ xfs_io -c "fsync" /mnt/foo
# Now do a redudant extent allocation for the range from 0 to 64Kb. # This will merely increase the file size from 0 to 64Kb. Instead we # could also do a truncate to set the file size to 64Kb. $ xfs_io -c "falloc 0 64K" /mnt/foo
# Fsync the file, so we update the inode item in the log tree with the # new file size (64Kb). This also ends up setting the number of bytes # for the first prealloc extent to 64Kb. This is done by the truncation # at btrfs_log_prealloc_extents(). # This means that if a power failure happens after this, a write into # the file range 64Kb to 128Kb will not use the prealloc extent and # will result in allocation of a new extent. $ xfs_io -c "fsync" /mnt/foo
# Now set the file size to 256K with a truncate and then fsync the file. # Since no changes happened to the extents, the fsync only updates the # i_size in the inode item at the log tree. This results in an implicit # hole for the file range from 64Kb to 128Kb, something which fsck will # complain when not using the NO_HOLES feature if we replay the log # after a power failure. $ xfs_io -c "truncate 256K" -c "fsync" /mnt/foo
So instead of always truncating the log to the inode's current i_size at btrfs_log_prealloc_extents(), check first if there's a prealloc extent that starts at an offset lower than the i_size and with a length that crosses the i_size - if there is one, just make sure we truncate to a size that corresponds to the end offset of that prealloc extent, so that we don't lose the part of that extent that starts at i_size if a power failure happens.
A test case for fstests follows soon.
Fixes: 31d11b83b96f ("Btrfs: fix duplicate extents after fsync of file with prealloc extents") CC: stable@vger.kernel.org # 4.14+ Signed-off-by: Filipe Manana fdmanana@suse.com Signed-off-by: David Sterba dsterba@suse.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- fs/btrfs/tree-log.c | 43 ++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 40 insertions(+), 3 deletions(-)
--- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -4182,6 +4182,9 @@ static int btrfs_log_prealloc_extents(st const u64 ino = btrfs_ino(inode); struct btrfs_path *dst_path = NULL; bool dropped_extents = false; + u64 truncate_offset = i_size; + struct extent_buffer *leaf; + int slot; int ins_nr = 0; int start_slot; int ret; @@ -4196,9 +4199,43 @@ static int btrfs_log_prealloc_extents(st if (ret < 0) goto out;
+ /* + * We must check if there is a prealloc extent that starts before the + * i_size and crosses the i_size boundary. This is to ensure later we + * truncate down to the end of that extent and not to the i_size, as + * otherwise we end up losing part of the prealloc extent after a log + * replay and with an implicit hole if there is another prealloc extent + * that starts at an offset beyond i_size. + */ + ret = btrfs_previous_item(root, path, ino, BTRFS_EXTENT_DATA_KEY); + if (ret < 0) + goto out; + + if (ret == 0) { + struct btrfs_file_extent_item *ei; + + leaf = path->nodes[0]; + slot = path->slots[0]; + ei = btrfs_item_ptr(leaf, slot, struct btrfs_file_extent_item); + + if (btrfs_file_extent_type(leaf, ei) == + BTRFS_FILE_EXTENT_PREALLOC) { + u64 extent_end; + + btrfs_item_key_to_cpu(leaf, &key, slot); + extent_end = key.offset + + btrfs_file_extent_num_bytes(leaf, ei); + + if (extent_end > i_size) + truncate_offset = extent_end; + } + } else { + ret = 0; + } + while (true) { - struct extent_buffer *leaf = path->nodes[0]; - int slot = path->slots[0]; + leaf = path->nodes[0]; + slot = path->slots[0];
if (slot >= btrfs_header_nritems(leaf)) { if (ins_nr > 0) { @@ -4236,7 +4273,7 @@ static int btrfs_log_prealloc_extents(st ret = btrfs_truncate_inode_items(trans, root->log_root, &inode->vfs_inode, - i_size, + truncate_offset, BTRFS_EXTENT_DATA_KEY); } while (ret == -EAGAIN); if (ret)
From: Qu Wenruo wqu@suse.com
commit fcc99734d1d4ced30167eb02e17f656735cb9928 upstream.
[BUG] One run of btrfs/063 triggered the following lockdep warning: ============================================ WARNING: possible recursive locking detected 5.6.0-rc7-custom+ #48 Not tainted -------------------------------------------- kworker/u24:0/7 is trying to acquire lock: ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs]
but task is already holding lock: ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs]
other info that might help us debug this: Possible unsafe locking scenario:
CPU0 ---- lock(sb_internal#2); lock(sb_internal#2);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by kworker/u24:0/7: #0: ffff88817b495948 ((wq_completion)btrfs-endio-write){+.+.}, at: process_one_work+0x557/0xb80 #1: ffff888189ea7db8 ((work_completion)(&work->normal_work)){+.+.}, at: process_one_work+0x557/0xb80 #2: ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs] #3: ffff888174ca4da8 (&fs_info->reloc_mutex){+.+.}, at: btrfs_record_root_in_trans+0x83/0xd0 [btrfs]
stack backtrace: CPU: 0 PID: 7 Comm: kworker/u24:0 Not tainted 5.6.0-rc7-custom+ #48 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] Call Trace: dump_stack+0xc2/0x11a __lock_acquire.cold+0xce/0x214 lock_acquire+0xe6/0x210 __sb_start_write+0x14e/0x290 start_transaction+0x66c/0x890 [btrfs] btrfs_join_transaction+0x1d/0x20 [btrfs] find_free_extent+0x1504/0x1a50 [btrfs] btrfs_reserve_extent+0xd5/0x1f0 [btrfs] btrfs_alloc_tree_block+0x1ac/0x570 [btrfs] btrfs_copy_root+0x213/0x580 [btrfs] create_reloc_root+0x3bd/0x470 [btrfs] btrfs_init_reloc_root+0x2d2/0x310 [btrfs] record_root_in_trans+0x191/0x1d0 [btrfs] btrfs_record_root_in_trans+0x90/0xd0 [btrfs] start_transaction+0x16e/0x890 [btrfs] btrfs_join_transaction+0x1d/0x20 [btrfs] btrfs_finish_ordered_io+0x55d/0xcd0 [btrfs] finish_ordered_fn+0x15/0x20 [btrfs] btrfs_work_helper+0x116/0x9a0 [btrfs] process_one_work+0x632/0xb80 worker_thread+0x80/0x690 kthread+0x1a3/0x1f0 ret_from_fork+0x27/0x50
It's pretty hard to reproduce, only one hit so far.
[CAUSE] This is because we're calling btrfs_join_transaction() without re-using the current running one:
btrfs_finish_ordered_io() |- btrfs_join_transaction() <<< Call #1 |- btrfs_record_root_in_trans() |- btrfs_reserve_extent() |- btrfs_join_transaction() <<< Call #2
Normally such btrfs_join_transaction() call should re-use the existing one, without trying to re-start a transaction.
But the problem is, in btrfs_join_transaction() call #1, we call btrfs_record_root_in_trans() before initializing current::journal_info.
And in btrfs_join_transaction() call #2, we're relying on current::journal_info to avoid such deadlock.
[FIX] Call btrfs_record_root_in_trans() after we have initialized current::journal_info.
CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Qu Wenruo wqu@suse.com Reviewed-by: David Sterba dsterba@suse.com Signed-off-by: David Sterba dsterba@suse.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- fs/btrfs/transaction.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
--- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -572,10 +572,19 @@ again: }
got_it: - btrfs_record_root_in_trans(h, root); - if (!current->journal_info) current->journal_info = h; + + /* + * btrfs_record_root_in_trans() needs to alloc new extents, and may + * call btrfs_join_transaction() while we're also starting a + * transaction. + * + * Thus it need to be called after current->journal_info initialized, + * or we can deadlock. + */ + btrfs_record_root_in_trans(h, root); + return h;
join_fail:
From: Douglas Anderson dianders@chromium.org
commit b1ac62a7ac386d76968af5f374a4a7a82a35fe31 upstream.
Open-coding a timeout loop invariably leads to errors with handling the timeout properly in one corner case or another. In the case of cqhci we might report "CQE stuck on" even if it wasn't stuck on. You'd just need this sequence of events to happen in cqhci_off():
1. Call ktime_get(). 2. Something happens to interrupt the CPU for > 100 us (context switch or interrupt). 3. Check time and; set "timed_out" to true since > 100 us. 4. Read CQHCI_CTL. 5. Both "reg & CQHCI_HALT" and "timed_out" are true, so break. 6. Since "timed_out" is true, falsely print the error message.
Rather than fixing the polling loop, use readx_poll_timeout() like many people do. This has been time tested to handle the corner cases.
Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host") Signed-off-by: Douglas Anderson dianders@chromium.org Acked-by: Adrian Hunter adrian.hunter@intel.com Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200413162717.1.Idece266f5c8793193b57a1ddb1066d03... Signed-off-by: Ulf Hansson ulf.hansson@linaro.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/mmc/host/cqhci.c | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-)
--- a/drivers/mmc/host/cqhci.c +++ b/drivers/mmc/host/cqhci.c @@ -13,6 +13,7 @@ #include <linux/delay.h> #include <linux/highmem.h> #include <linux/io.h> +#include <linux/iopoll.h> #include <linux/module.h> #include <linux/dma-mapping.h> #include <linux/slab.h> @@ -351,12 +352,16 @@ static int cqhci_enable(struct mmc_host /* CQHCI is idle and should halt immediately, so set a small timeout */ #define CQHCI_OFF_TIMEOUT 100
+static u32 cqhci_read_ctl(struct cqhci_host *cq_host) +{ + return cqhci_readl(cq_host, CQHCI_CTL); +} + static void cqhci_off(struct mmc_host *mmc) { struct cqhci_host *cq_host = mmc->cqe_private; - ktime_t timeout; - bool timed_out; u32 reg; + int err;
if (!cq_host->enabled || !mmc->cqe_on || cq_host->recovery_halt) return; @@ -366,15 +371,9 @@ static void cqhci_off(struct mmc_host *m
cqhci_writel(cq_host, CQHCI_HALT, CQHCI_CTL);
- timeout = ktime_add_us(ktime_get(), CQHCI_OFF_TIMEOUT); - while (1) { - timed_out = ktime_compare(ktime_get(), timeout) > 0; - reg = cqhci_readl(cq_host, CQHCI_CTL); - if ((reg & CQHCI_HALT) || timed_out) - break; - } - - if (timed_out) + err = readx_poll_timeout(cqhci_read_ctl, cq_host, reg, + reg & CQHCI_HALT, 0, CQHCI_OFF_TIMEOUT); + if (err < 0) pr_err("%s: cqhci: CQE stuck on\n", mmc_hostname(mmc)); else pr_debug("%s: cqhci: CQE off\n", mmc_hostname(mmc));
From: Marek Behún marek.behun@nic.cz
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 marek.behun@nic.cz Fixes: 8d876bf472db ("mmc: sdhci-xenon: wait 5ms after set 1.8V...") Cc: stable@vger.kernel.org # v4.16+ Link: https://lore.kernel.org/r/20200420080444.25242-1-marek.behun@nic.cz Signed-off-by: Ulf Hansson ulf.hansson@linaro.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- 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 = {
From: Adrian Hunter adrian.hunter@intel.com
commit 1a8eb6b373c2af6533c13d1ea11f504e5010ed9a upstream.
BIOS writers have begun the practice of setting 40 ohm eMMC driver strength even though the eMMC may not support it, on the assumption that the kernel will validate the value against the eMMC (Extended CSD DRIVER_STRENGTH [offset 197]) and revert to the default 50 ohm value if 40 ohm is invalid.
This is done to avoid changing the value for different boards.
Putting aside the merits of this approach, it is clear the eMMC's mask of supported driver strengths is more reliable than the value provided by BIOS. Add validation accordingly.
Signed-off-by: Adrian Hunter adrian.hunter@intel.com Fixes: 51ced59cc02e ("mmc: sdhci-pci: Use ACPI DSM to get driver strength for some Intel devices") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200422111629.4899-1-adrian.hunter@intel.com Signed-off-by: Ulf Hansson ulf.hansson@linaro.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/mmc/host/sdhci-pci-core.c | 3 +++ 1 file changed, 3 insertions(+)
--- a/drivers/mmc/host/sdhci-pci-core.c +++ b/drivers/mmc/host/sdhci-pci-core.c @@ -556,6 +556,9 @@ static int intel_select_drive_strength(s struct sdhci_pci_slot *slot = sdhci_priv(host); struct intel_host *intel_host = sdhci_pci_priv(slot);
+ if (!(mmc_driver_type_mask(intel_host->drv_strength) & card_drv)) + return 0; + return intel_host->drv_strength; }
From: Veerabhadrarao Badiganti vbadigan@codeaurora.org
commit 9d8cb58691f85cef687512262acb2c7109ee4868 upstream.
MSM sd host controller is capable of HW busy detection of device busy signaling over DAT0 line. And it requires the R1B response for commands that have this response associated with them.
So set the below two host capabilities for qcom SDHC. - MMC_CAP_WAIT_WHILE_BUSY - MMC_CAP_NEED_RSP_BUSY
Recent development of the mmc core in regards to this, revealed this as being a potential bug, hence the stable tag.
Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Veerabhadrarao Badiganti vbadigan@codeaurora.org Acked-by: Adrian Hunter adrian.hunter@intel.com Link: https://lore.kernel.org/r/1587363626-20413-2-git-send-email-vbadigan@codeaur... Signed-off-by: Ulf Hansson ulf.hansson@linaro.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/mmc/host/sdhci-msm.c | 2 ++ 1 file changed, 2 insertions(+)
--- a/drivers/mmc/host/sdhci-msm.c +++ b/drivers/mmc/host/sdhci-msm.c @@ -1909,6 +1909,8 @@ static int sdhci_msm_probe(struct platfo goto clk_disable; }
+ msm_host->mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY | MMC_CAP_NEED_RSP_BUSY; + pm_runtime_get_noresume(&pdev->dev); pm_runtime_set_active(&pdev->dev); pm_runtime_enable(&pdev->dev);
From: Martin Blumenstingl martin.blumenstingl@googlemail.com
commit e53b868b3cf5beeaa2f851ec6740112bf4d6a8cb upstream.
The Meson SDIO controller uses the DAT0 lane for hardware busy detection. Set MMC_CAP_WAIT_WHILE_BUSY accordingly. This fixes the following error observed with Linux 5.7 (pre-rc-1): mmc1: Card stuck being busy! __mmc_poll_for_busy blk_update_request: I/O error, dev mmcblk1, sector 17111080 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 0
Fixes: ed80a13bb4c4c9 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs") Signed-off-by: Martin Blumenstingl martin.blumenstingl@googlemail.com Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200416183513.993763-2-martin.blumenstingl@google... Signed-off-by: Ulf Hansson ulf.hansson@linaro.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/mmc/host/meson-mx-sdio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/mmc/host/meson-mx-sdio.c +++ b/drivers/mmc/host/meson-mx-sdio.c @@ -573,7 +573,7 @@ static int meson_mx_mmc_add_host(struct mmc->f_max = clk_round_rate(host->cfg_div_clk, clk_get_rate(host->parent_clk));
- mmc->caps |= MMC_CAP_ERASE | MMC_CAP_CMD23; + mmc->caps |= MMC_CAP_ERASE | MMC_CAP_CMD23 | MMC_CAP_WAIT_WHILE_BUSY; mmc->ops = &meson_mx_mmc_ops;
ret = mmc_of_parse(mmc);
From: Martin Blumenstingl martin.blumenstingl@googlemail.com
commit ddca1092c4324c89cf692b5efe655aa251864b51 upstream.
The recent commit 0d84c3e6a5b2 ("mmc: core: Convert to mmc_poll_for_busy() for erase/trim/discard") makes use of the ->card_busy() op for SD cards. This uncovered that the ->card_busy() op in the Meson SDIO driver was never working right: while polling the busy status with ->card_busy() meson_mx_mmc_card_busy() reads only one of the two MESON_MX_SDIO_IRQC register values 0x1f001f10 or 0x1f003f10. This translates to "three out of four DAT lines are HIGH" and "all four DAT lines are HIGH", which is interpreted as "the card is busy".
It turns out that no situation can be observed where all four DAT lines are LOW, meaning the card is not busy anymore. Upon further research the 3.10 vendor driver for this controller does not implement the ->card_busy() op.
Remove the ->card_busy() op from the meson-mx-sdio driver since it is not working. At the time of writing this patch it is not clear what's needed to make the ->card_busy() implementation work with this specific controller hardware. For all use-cases which have previously worked the MMC_CAP_WAIT_WHILE_BUSY flag is now taking over, even if we don't have a ->card_busy() op anymore.
Fixes: ed80a13bb4c4c9 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs") Signed-off-by: Martin Blumenstingl martin.blumenstingl@googlemail.com Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200416183513.993763-3-martin.blumenstingl@google... Signed-off-by: Ulf Hansson ulf.hansson@linaro.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/mmc/host/meson-mx-sdio.c | 9 --------- 1 file changed, 9 deletions(-)
--- a/drivers/mmc/host/meson-mx-sdio.c +++ b/drivers/mmc/host/meson-mx-sdio.c @@ -360,14 +360,6 @@ static void meson_mx_mmc_request(struct meson_mx_mmc_start_cmd(mmc, mrq->cmd); }
-static int meson_mx_mmc_card_busy(struct mmc_host *mmc) -{ - struct meson_mx_mmc_host *host = mmc_priv(mmc); - u32 irqc = readl(host->base + MESON_MX_SDIO_IRQC); - - return !!(irqc & MESON_MX_SDIO_IRQC_FORCE_DATA_DAT_MASK); -} - static void meson_mx_mmc_read_response(struct mmc_host *mmc, struct mmc_command *cmd) { @@ -509,7 +501,6 @@ static void meson_mx_mmc_timeout(struct static struct mmc_host_ops meson_mx_mmc_ops = { .request = meson_mx_mmc_request, .set_ios = meson_mx_mmc_set_ios, - .card_busy = meson_mx_mmc_card_busy, .get_cd = mmc_gpio_get_cd, .get_ro = mmc_gpio_get_ro, };
Hi Greg,
From: stable-owner@vger.kernel.org stable-owner@vger.kernel.org On Behalf Of Greg Kroah-Hartman Sent: 04 May 2020 18:57
This is the start of the stable review cycle for the 4.19.121 release. There are 37 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.
No build/boot issues seen for CIP configs for Linux 4.19.121-rc1 (2e3613309d93).
Build/test pipeline/logs: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/pipelines/1425... GitLab CI pipeline: https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master... Relevant LAVA jobs: https://lava.ciplatform.org/scheduler/alljobs?length=25&search=2e3613#ta...
Kind regards, Chris
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.19.121-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.19.y and the diffstat can be found below.
thanks,
greg k-h
Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 4.19.121-rc1
Martin Blumenstingl martin.blumenstingl@googlemail.com mmc: meson-mx-sdio: remove the broken ->card_busy() op
Martin Blumenstingl martin.blumenstingl@googlemail.com mmc: meson-mx-sdio: Set MMC_CAP_WAIT_WHILE_BUSY
Veerabhadrarao Badiganti vbadigan@codeaurora.org mmc: sdhci-msm: Enable host capabilities pertains to R1b response
Adrian Hunter adrian.hunter@intel.com mmc: sdhci-pci: Fix eMMC driver strength for BYT-based controllers
Marek Behún marek.behun@nic.cz mmc: sdhci-xenon: fix annoying 1.8V regulator warning
Douglas Anderson dianders@chromium.org mmc: cqhci: Avoid false "cqhci: CQE stuck on" by not open-coding timeout loop
Qu Wenruo wqu@suse.com btrfs: transaction: Avoid deadlock due to bad initialization timing of fs_info::journal_info
Filipe Manana fdmanana@suse.com btrfs: fix partial loss of prealloc extent past i_size after fsync
Paul Moore paul@paul-moore.com selinux: properly handle multiple messages in selinux_netlink_send()
Andy Shevchenko andriy.shevchenko@linux.intel.com dmaengine: dmatest: Fix iteration non-stop logic
Andreas Gruenbacher agruenba@redhat.com nfs: Fix potential posix_acl refcnt leak in nfs3_set_acl
Arnd Bergmann arnd@arndb.de ALSA: opti9xx: shut up gcc-10 range warning
Suravee Suthikulpanit suravee.suthikulpanit@amd.com iommu/amd: Fix legacy interrupt remapping for x2APIC-enabled system
David Disseldorp ddiss@suse.de scsi: target/iblock: fix WRITE SAME zeroing
Tang Bin tangbin@cmss.chinamobile.com iommu/qcom: Fix local_base status check
Sean Christopherson sean.j.christopherson@intel.com vfio/type1: Fix VA->PA translation for PFNMAP VMAs in vaddr_get_pfn()
Yan Zhao yan.y.zhao@intel.com vfio: avoid possible overflow in vfio_iommu_type1_pin_pages
Leon Romanovsky leon@kernel.org RDMA/core: Fix race between destroy and release FD object
Leon Romanovsky leon@kernel.org RDMA/core: Prevent mixed use of FDs between shared ufiles
Alaa Hleihel alaa@mellanox.com RDMA/mlx4: Initialize ib_spec on the stack
Aharon Landau aharonl@mellanox.com RDMA/mlx5: Set GRH fields in query QP on RoCE
Martin Wilck mwilck@suse.com scsi: qla2xxx: check UNLOADING before posting async work
Martin Wilck mwilck@suse.com scsi: qla2xxx: set UNLOADING before waiting for session deletion
Gabriel Krisman Bertazi krisman@collabora.com dm multipath: use updated MPATHF_QUEUE_IO on mapping for bio-based mpath
Mikulas Patocka mpatocka@redhat.com dm writecache: fix data corruption when reloading the target
Sunwook Eom speed.eom@samsung.com dm verity fec: fix hash block number in verity_fec_decode
Dexuan Cui decui@microsoft.com PM: hibernate: Freeze kernel threads in software_resume()
Kai-Heng Feng kai.heng.feng@canonical.com PM: ACPI: Output correct message on target power state
Takashi Iwai tiwai@suse.de ALSA: pcm: oss: Place the plugin buffer overflow checks correctly
Wu Bo wubo40@huawei.com ALSA: hda/hdmi: fix without unlocked before return
Takashi Iwai tiwai@suse.de ALSA: usb-audio: Correct a typo of NuPrime DAC-10 USB ID
Hui Wang hui.wang@canonical.com ALSA: hda/realtek - Two front mics on a Lenovo ThinkCenter
Xiyu Yang xiyuyang19@fudan.edu.cn btrfs: fix block group leak when removing fails
Vasily Averin vvs@virtuozzo.com drm/qxl: qxl_release use after free
Vasily Averin vvs@virtuozzo.com drm/qxl: qxl_release leak in qxl_hw_surface_alloc()
Vasily Averin vvs@virtuozzo.com drm/qxl: qxl_release leak in qxl_draw_dirty_fb()
Ville Syrjälä ville.syrjala@linux.intel.com drm/edid: Fix off-by-one in DispID DTD pixel clock
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/core/rdma_core.c | 4 +-- 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-mpath.c | 6 ++-- drivers/md/dm-verity-fec.c | 2 +- drivers/md/dm-writecache.c | 52 +++++++++++++++++++-------- drivers/mmc/host/cqhci.c | 21 ++++++----- drivers/mmc/host/meson-mx-sdio.c | 11 +----- drivers/mmc/host/sdhci-msm.c | 2 ++ drivers/mmc/host/sdhci-pci-core.c | 3 ++ drivers/mmc/host/sdhci-xenon.c | 10 ++++++ drivers/scsi/qla2xxx/qla_os.c | 35 +++++++++---------- drivers/target/target_core_iblock.c | 2 +- drivers/vfio/vfio_iommu_type1.c | 6 ++-- fs/btrfs/extent-tree.c | 16 +++++---- fs/btrfs/transaction.c | 13 +++++-- fs/btrfs/tree-log.c | 43 +++++++++++++++++++++-- fs/nfs/nfs3acl.c | 22 ++++++++---- kernel/power/hibernate.c | 7 ++++ security/selinux/hooks.c | 70 ++++++++++++++++++++++++------------- 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 + sound/usb/quirks.c | 2 +- 36 files changed, 281 insertions(+), 151 deletions(-)
On Tue, May 05, 2020 at 07:42:23AM +0000, Chris Paterson wrote:
Hi Greg,
From: stable-owner@vger.kernel.org stable-owner@vger.kernel.org On Behalf Of Greg Kroah-Hartman Sent: 04 May 2020 18:57
This is the start of the stable review cycle for the 4.19.121 release. There are 37 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.
No build/boot issues seen for CIP configs for Linux 4.19.121-rc1 (2e3613309d93).
Build/test pipeline/logs: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/pipelines/1425... GitLab CI pipeline: https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master... Relevant LAVA jobs: https://lava.ciplatform.org/scheduler/alljobs?length=25&search=2e3613#ta...
Thanks for testing two of these and letting me know.
greg k-h
On 04/05/2020 18:57, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.121 release. There are 37 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.19.121-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below.
thanks,
greg k-h
All tests are passing for Tegra ...
Test results for stable-v4.19: 11 builds: 11 pass, 0 fail 22 boots: 22 pass, 0 fail 32 tests: 32 pass, 0 fail
Linux version: 4.19.121-rc1-g2e3613309d93 Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000, tegra194-p2972-0000, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04
Cheers Jon
On Mon, 4 May 2020 at 23:32, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 4.19.121 release. There are 37 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.19.121-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.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.
NOTE: kernel warning noticed on stable rc 4.19 and 5.4 while running selftest bpf test cases on arm64 devices.
NETDEV WATCHDOG: eth0 (asix): transmit queue 0 timed out - net/sched/sch_generic.c:466 dev_watchdog
ref: https://lore.kernel.org/stable/CA+G9fYu4gE2vqSmgyYMfdMS-ZDfQiY1vhk2Jbni+wDJF...
Summary ------------------------------------------------------------------------
kernel: 4.19.121-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.19.y git commit: 2e3613309d936ae445288baa881ca1775f300f6f git describe: v4.19.120-38-g2e3613309d93 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.120-3...
No regressions (compared to build v4.19.120)
No fixes (compared to build v4.19.120)
Ran 28318 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 - nxp-ls2088 - 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 * linux-log-parser * ltp-cap_bounds-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-ipc-tests * perf * ltp-commands-tests * ltp-containers-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * network-basic-tests * v4l2-compliance * kselftest * kselftest/drivers * kselftest/filesystems * kselftest/net * kselftest/networking * libhugetlbfs * ltp-cve-tests * ltp-dio-tests * ltp-fs-tests * ltp-io-tests * 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
On 5/4/20 11:57 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.121 release. There are 37 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.19.121-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks, -- Shuah
On 5/4/20 10:57 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.121 release. There are 37 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: 155 pass: 155 fail: 0 Qemu test results: total: 417 pass: 417 fail: 0
Guenter
linux-stable-mirror@lists.linaro.org