March 2020 - Linux-stable-mirror

Re: mmc: sdhci-of-esdhc: fix P2020 errata handling

by Daniel Walker (danielwa)

Hi, We got your patch from stable. On p2020 we had mmc issues, and bisected the issue to your patch. Both prior patches seems to modify quirks2. Fixes: 05cb6b2a66fa ("mmc: sdhci-of-esdhc: add erratum eSDHC-A001 and A-008358 support") Fixes: a46e42712596 ("mmc: sdhci-of-esdhc: add erratum eSDHC5 support") So I'm not sure if your changes were done correctly. Daniel

4 years

3
8
0 0

[PATCH] ARM: dts: imx6dl-yapp4: Fix Ursa board Ethernet connection

by Michal Vokáč

The Y Soft yapp4 platform supports up to two Ethernet ports. The Ursa board though has only one Ethernet port populated and that is the port@2. Since the introduction of this platform into mainline a wrong port was deleted and the Ethernet could never work. Fix this by deleting the correct port node. Fixes: 87489ec3a77f ("ARM: dts: imx: Add Y Soft IOTA Draco, Hydra and Ursa boards") Cc: stable(a)vger.kernel.org Signed-off-by: Michal Vokáč <michal.vokac(a)ysoft.com> --- arch/arm/boot/dts/imx6dl-yapp4-ursa.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/imx6dl-yapp4-ursa.dts b/arch/arm/boot/dts/imx6dl-yapp4-ursa.dts index 0d594e4bd559..a1173bf5bff5 100644 --- a/arch/arm/boot/dts/imx6dl-yapp4-ursa.dts +++ b/arch/arm/boot/dts/imx6dl-yapp4-ursa.dts @@ -38,7 +38,7 @@ }; &switch_ports { - /delete-node/ port@2; + /delete-node/ port@3; }; &touchscreen { -- 2.7.4

4 years

2
1
0 0

[PATCH] ext4: Do not zeroout extents beyond i_disksize

by Jan Kara

We do not want to create initialized extents beyond end of file because for e2fsck it is impossible to distinguish them from a case of corrupted file size / extent tree and so it complains like: Inode 12, i_size is 147456, should be 163840. Fix? no Code in ext4_ext_convert_to_initialized() and ext4_split_convert_extents() try to make sure it does not create initialized extents beyond inode size however they check against inode->i_size which is wrong. They should instead check against EXT4_I(inode)->i_disksize which is the current inode size on disk. That's what e2fsck is going to see in case of crash before all dirty data is written. This bug manifests as generic/456 test failure (with recent enough fstests where fsx got fixed to properly pass FALLOC_KEEP_SIZE_FL flags to the kernel) when run with dioread_lock mount option. CC: stable(a)vger.kernel.org Fixes: 21ca087a3891 ("ext4: Do not zero out uninitialized extents beyond i_size") Signed-off-by: Jan Kara <jack(a)suse.cz> --- fs/ext4/extents.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 954013d6076b..c5e190fd4589 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3532,8 +3532,8 @@ static int ext4_ext_convert_to_initialized(handle_t *handle, (unsigned long long)map->m_lblk, map_len); sbi = EXT4_SB(inode->i_sb); - eof_block = (inode->i_size + inode->i_sb->s_blocksize - 1) >> - inode->i_sb->s_blocksize_bits; + eof_block = (EXT4_I(inode)->i_disksize + inode->i_sb->s_blocksize - 1) + >> inode->i_sb->s_blocksize_bits; if (eof_block < map->m_lblk + map_len) eof_block = map->m_lblk + map_len; @@ -3785,8 +3785,8 @@ static int ext4_split_convert_extents(handle_t *handle, __func__, inode->i_ino, (unsigned long long)map->m_lblk, map->m_len); - eof_block = (inode->i_size + inode->i_sb->s_blocksize - 1) >> - inode->i_sb->s_blocksize_bits; + eof_block = (EXT4_I(inode)->i_disksize + inode->i_sb->s_blocksize - 1) + >> inode->i_sb->s_blocksize_bits; if (eof_block < map->m_lblk + map->m_len) eof_block = map->m_lblk + map->m_len; /* -- 2.16.4

4 years

3
3
0 0

[PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets

by Daniel Vetter

When doing an atomic modeset with ALLOW_MODESET drivers are allowed to pull in arbitrary other resources, including CRTCs (e.g. when reconfiguring global resources). But in nonblocking mode userspace has then no idea this happened, which can lead to spurious EBUSY calls, both: - when that other CRTC is currently busy doing a page_flip the ALLOW_MODESET commit can fail with an EBUSY - on the other CRTC a normal atomic flip can fail with EBUSY because of the additional commit inserted by the kernel without userspace's knowledge For blocking commits this isn't a problem, because everyone else will just block until all the CRTC are reconfigured. Only thing userspace can notice is the dropped frames without any reason for why frames got dropped. Consensus is that we need new uapi to handle this properly, but no one has any idea what exactly the new uapi should look like. As a stop-gap plug this problem by demoting nonblocking commits which might cause issues by including CRTCs not in the original request to blocking commits. v2: Add comments and a WARN_ON to enforce this only when allowed - we don't want to silently convert page flips into blocking plane updates just because the driver is buggy. v3: Fix inverted WARN_ON (Pekka). References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568 Cc: Daniel Stone <daniel(a)fooishbar.org> Cc: Pekka Paalanen <pekka.paalanen(a)collabora.co.uk> Cc: stable(a)vger.kernel.org Reviewed-by: Daniel Stone <daniels(a)collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 9ccfbf213d72..4c035abf98b8 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit); int drm_atomic_nonblocking_commit(struct drm_atomic_state *state) { struct drm_mode_config *config = &state->dev->mode_config; - int ret; + unsigned requested_crtc = 0; + unsigned affected_crtc = 0; + struct drm_crtc *crtc; + struct drm_crtc_state *crtc_state; + bool nonblocking = true; + int ret, i; + + /* + * For commits that allow modesets drivers can add other CRTCs to the + * atomic commit, e.g. when they need to reallocate global resources. + * + * But when userspace also requests a nonblocking commit then userspace + * cannot know that the commit affects other CRTCs, which can result in + * spurious EBUSY failures. Until we have better uapi plug this by + * demoting such commits to blocking mode. + */ + for_each_new_crtc_in_state(state, crtc, crtc_state, i) + requested_crtc |= drm_crtc_mask(crtc); ret = drm_atomic_check_only(state); if (ret) return ret; - DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state); + for_each_new_crtc_in_state(state, crtc, crtc_state, i) + affected_crtc |= drm_crtc_mask(crtc); + + if (affected_crtc != requested_crtc) { + /* adding other CRTC is only allowed for modeset commits */ + WARN_ON(!state->allow_modeset); + + DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid EBUSY\n", state); + nonblocking = false; + } else { + DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state); + } - return config->funcs->atomic_commit(state->dev, state, true); + return config->funcs->atomic_commit(state->dev, state, nonblocking); } EXPORT_SYMBOL(drm_atomic_nonblocking_commit); -- 2.24.1

4 years

2
5
0 0

[PATCH] virtio: virtio_console: add missing MODULE_DEVICE_TABLE() for rproc serial

by Alexander Lobakin

rproc_serial_id_table lacks an exposure to module devicetable, so when remoteproc firmware requests VIRTIO_ID_RPROC_SERIAL, no uevent is generated and no module autoloading occurs. Add missing MODULE_DEVICE_TABLE() annotation and move the existing one for VIRTIO_ID_CONSOLE right to the table itself. Fixes: 1b6370463e88 ("virtio_console: Add support for remoteproc serial") Cc: <stable(a)vger.kernel.org> # v3.8+ Signed-off-by: Alexander Lobakin <alobakin(a)dlink.ru> --- drivers/char/virtio_console.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index 4df9b40d6342..7e1bc0f580a2 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -2116,6 +2116,7 @@ static struct virtio_device_id id_table[] = { { VIRTIO_ID_CONSOLE, VIRTIO_DEV_ANY_ID }, { 0 }, }; +MODULE_DEVICE_TABLE(virtio, id_table); static unsigned int features[] = { VIRTIO_CONSOLE_F_SIZE, @@ -2128,6 +2129,7 @@ static struct virtio_device_id rproc_serial_id_table[] = { #endif { 0 }, }; +MODULE_DEVICE_TABLE(virtio, rproc_serial_id_table); static unsigned int rproc_serial_features[] = { }; @@ -2280,6 +2282,5 @@ static void __exit fini(void) module_init(init); module_exit(fini); -MODULE_DEVICE_TABLE(virtio, id_table); MODULE_DESCRIPTION("Virtio console driver"); MODULE_LICENSE("GPL"); -- 2.25.1

4 years

3
2
0 0

[PATCH AUTOSEL 5.4 01/73] cgroup-v1: cgroup_pidlist_next should update position index

by Sasha Levin

From: Vasily Averin <vvs(a)virtuozzo.com> [ Upstream commit db8dd9697238be70a6b4f9d0284cd89f59c0e070 ] if seq_file .next fuction does not change position index, read after some lseek can generate unexpected output. # mount | grep cgroup # dd if=/mnt/cgroup.procs bs=1 # normal output ... 1294 1295 1296 1304 1382 584+0 records in 584+0 records out 584 bytes copied dd: /mnt/cgroup.procs: cannot skip to specified offset 83 <<< generates end of last line 1383 <<< ... and whole last line once again 0+1 records in 0+1 records out 8 bytes copied dd: /mnt/cgroup.procs: cannot skip to specified offset 1386 <<< generates last line anyway 0+1 records in 0+1 records out 5 bytes copied https://bugzilla.kernel.org/show_bug.cgi?id=206283 Signed-off-by: Vasily Averin <vvs(a)virtuozzo.com> Signed-off-by: Tejun Heo <tj(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- kernel/cgroup/cgroup-v1.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c index 7f83f4121d8d0..2db582706ec5c 100644 --- a/kernel/cgroup/cgroup-v1.c +++ b/kernel/cgroup/cgroup-v1.c @@ -473,6 +473,7 @@ static void *cgroup_pidlist_next(struct seq_file *s, void *v, loff_t *pos) */ p++; if (p >= end) { + (*pos)++; return NULL; } else { *pos = *p; -- 2.20.1

4 years

5
79
0 0

[PATCH] libata: Return correct rc status in sata_pmp_eh_recover_pm() pwhen ATA_DFLAG_DETACH is set

by Kai-Heng Feng

During system resume from suspend, this can be observed on ASM1062 PMP controller: <6>[12007.593358] ata10.01: SATA link down (SStatus 0 SControl 330) <6>[12007.593469] ata10.02: hard resetting link <6>[12007.908353] ata10.02: SATA link down (SStatus 0 SControl 330) <6>[12007.911149] ata10.00: configured for UDMA/133 <0>[12007.972508] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: sata_pmp_eh_recover+0xa2b/0xa40 <0>[12007.972508] <4>[12007.972515] CPU: 2 PID: 230 Comm: scsi_eh_9 Tainted: P OE 4.15.0-46-generic #49-Ubuntu <4>[12007.972517] Hardware name: System manufacturer System Product Name/A320M-C, BIOS 1001 12/10/2017 <4>[12007.972518] Call Trace: <4>[12007.972525] dump_stack+0x63/0x8b <4>[12007.972530] panic+0xe4/0x244 <4>[12007.972533] ? sata_pmp_eh_recover+0xa2b/0xa40 <4>[12007.972536] __stack_chk_fail+0x19/0x20 <4>[12007.972538] sata_pmp_eh_recover+0xa2b/0xa40 <4>[12007.972543] ? ahci_do_softreset+0x260/0x260 [libahci] <4>[12007.972545] ? ahci_do_hardreset+0x140/0x140 [libahci] <4>[12007.972547] ? ata_phys_link_offline+0x60/0x60 <4>[12007.972549] ? ahci_stop_engine+0xc0/0xc0 [libahci] <4>[12007.972552] sata_pmp_error_handler+0x22/0x30 <4>[12007.972554] ahci_error_handler+0x45/0x80 [libahci] <4>[12007.972556] ata_scsi_port_error_handler+0x29b/0x770 <4>[12007.972558] ? ata_scsi_cmd_error_handler+0x101/0x140 <4>[12007.972559] ata_scsi_error+0x95/0xd0 <4>[12007.972562] ? scsi_try_target_reset+0x90/0x90 <4>[12007.972563] scsi_error_handler+0xd0/0x5b0 <4>[12007.972566] kthread+0x121/0x140 <4>[12007.972567] ? scsi_eh_get_sense+0x200/0x200 <4>[12007.972569] ? kthread_create_worker_on_cpu+0x70/0x70 <4>[12007.972572] ret_from_fork+0x22/0x40 <0>[12007.972591] Kernel Offset: 0xcc00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Since sata_pmp_eh_recover_pmp() doens't set rc when ATA_DFLAG_DETACH is set, sata_pmp_eh_recover() continues to run. During retry it triggers the stack protector. Set correct rc in sata_pmp_eh_recover_pmp() to let sata_pmp_eh_recover() jump to pmp_fail directly. BugLink: https://bugs.launchpad.net/bugs/1821434 Cc: stable(a)vger.kernel.org Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- drivers/ata/libata-pmp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/ata/libata-pmp.c b/drivers/ata/libata-pmp.c index 2ae1799f4992..51eeaea65833 100644 --- a/drivers/ata/libata-pmp.c +++ b/drivers/ata/libata-pmp.c @@ -764,6 +764,7 @@ static int sata_pmp_eh_recover_pmp(struct ata_port *ap, if (dev->flags & ATA_DFLAG_DETACH) { detach = 1; + rc = -ENODEV; goto fail; } -- 2.17.1

4 years

3
3
0 0

[PING] EFI/PTI fix not backported to 3.16.XX?

by Martin Galvan

Hi all, I've been running some tests on Debian 8 (which uses a 3.16.XX kernel), and saw that my system would occasionally reboot when performing an EFI variables dump. I did some digging and saw that this problem first appeared in 4.4.110 and was fixed by Pavel Tatashin in commit 7ec5d87df34a. At the same time, 4.9.XX, 4.14.XX and mainline have commit 67a9108ed431, which also solves the issue. However, the 3.16 stable line doesn't seem to have either fix, and therefore the crash is still there. I don't know whether any distros use 3.16 other than Debian, but it'd still be good to have this fix backported as well.

4 years, 1 month

3
4
0 0

[PATCH v2] drm/prime: fix extracting of the DMA addresses from a scatterlist

by Marek Szyprowski

Scatterlist elements contains both pages and DMA addresses, but one should not assume 1:1 relation between them. The sg->length is the size of the physical memory chunk described by the sg->page, while sg_dma_len(sg) is the size of the DMA (IO virtual) chunk described by the sg_dma_address(sg). The proper way of extracting both: pages and DMA addresses of the whole buffer described by a scatterlist it to iterate independently over the sg->pages/sg->length and sg_dma_address(sg)/sg_dma_len(sg) entries. Fixes: 42e67b479eab ("drm/prime: use dma length macro when mapping sg") Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com> --- drivers/gpu/drm/drm_prime.c | 37 +++++++++++++++++++++++++------------ 1 file changed, 25 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 1de2cde2277c..282774e469ac 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -962,27 +962,40 @@ int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct page **pages, unsigned count; struct scatterlist *sg; struct page *page; - u32 len, index; + u32 page_len, page_index; dma_addr_t addr; + u32 dma_len, dma_index; - index = 0; + /* + * Scatterlist elements contains both pages and DMA addresses, but + * one shoud not assume 1:1 relation between them. The sg->length is + * the size of the physical memory chunk described by the sg->page, + * while sg_dma_len(sg) is the size of the DMA (IO virtual) chunk + * described by the sg_dma_address(sg). + */ + page_index = 0; + dma_index = 0; for_each_sg(sgt->sgl, sg, sgt->nents, count) { - len = sg_dma_len(sg); + page_len = sg->length; page = sg_page(sg); + dma_len = sg_dma_len(sg); addr = sg_dma_address(sg); - while (len > 0) { - if (WARN_ON(index >= max_entries)) + while (pages && page_len > 0) { + if (WARN_ON(page_index >= max_entries)) return -1; - if (pages) - pages[index] = page; - if (addrs) - addrs[index] = addr; - + pages[page_index] = page; page++; + page_len -= PAGE_SIZE; + page_index++; + } + while (addrs && dma_len > 0) { + if (WARN_ON(dma_index >= max_entries)) + return -1; + addrs[dma_index] = addr; addr += PAGE_SIZE; - len -= PAGE_SIZE; - index++; + dma_len -= PAGE_SIZE; + dma_index++; } } return 0; -- 2.17.1

4 years, 1 month

7
8
0 0

Backport dependencies helper

by Sasha Levin

Hi all, I wanted to share a resource I've been using to help me with doing backports to various stable kernels. In the Stable Kernel world, when we need to backport a patch, we'd rather take any relevant dependencies to make the patch work cleanly on an older kernel, rather than modifying the patch and diverging from upstream. This raises an interesting problem: how do we figure out which other patches might be "interesting" to look at? git-blame is a great tool, but it takes a while to go through the history of a patch, and given the volume of patches we need to look at, it just isn't enough. So here's a tool in the form of a git repo that can help point out these interesting patches: https://git.kernel.org/pub/scm/linux/kernel/git/sashal/deps.git/ How does it work, you might ask? It's actually quite simple: Each directory represents a kernel version which we'll call K, and each file inside that directory is named after an upstream commit we'll call C, and it's content are the list of commits one would need to apply on top of kernel K to "reach" commit C. For example, let's say we want to apply: f8788d86ab28 ("Linux 5.6-rc3") On top of the v5.5 kernel tree. All we need to do is: $ cat v5.5/f8788d86ab28f61f7b46eb6be375f8a726783636 f8788d86ab28 ("Linux 5.6-rc3") 11a48a5a18c6 ("Linux 5.6-rc2") bb6d3fb354c5 ("Linux 5.6-rc1") If you don't feel like cloning the repo (which contains quite a few files), you can also use kernel.org's web interface in a script that might look something like this: #!/bin/bash curl https://git.kernel.org/pub/scm/linux/kernel/git/sashal/deps.git/plain/$1/$2 And then simply: $ ./deps.sh v5.5 f8788d86ab28f61f7b46eb6be375f8a726783636 f8788d86ab28 ("Linux 5.6-rc3") 11a48a5a18c6 ("Linux 5.6-rc2") bb6d3fb354c5 ("Linux 5.6-rc1") Caveats: - Each file is limited to 50 entries. I feel that at that point it stops being useful. - Each file stops if a merge commit is hit. - I might have bugs in my scripts and some entries are broken, please report those if you see them. -- Thanks, Sasha

4 years, 1 month

3
4
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2020