- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] [PATCH v2] drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU

by Marek Szyprowski

When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver are contiguous, because of the underlying dma_alloc_attrs() function provides only such buffers. In such case it makes no sense to keep BO_NONCONTIG flag for the allocated GEM buffers. This allows to avoid failures for buffer contiguity checks in the subsequent operations on GEM objects. Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> CC: stable(a)vger.kernel.org # v4.4+ --- This issue is there since commit 0519f9a12d011 ("drm/exynos: add iommu support for exynos drm framework"), but this patch applies cleanly only to v4.4+ kernel releases due changes in the surrounding code. Changelog: v2: - added warning message when buffer flags are updadated (requested by Inki) v1: https://patchwork.kernel.org/patch/10034919/ - initial version --- drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c index 077de014d610..4400efe3974a 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c @@ -247,6 +247,15 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct drm_device *dev, if (IS_ERR(exynos_gem)) return exynos_gem; + if (!is_drm_iommu_supported(dev) && (flags & EXYNOS_BO_NONCONTIG)) { + /* + * when no IOMMU is available, all allocated buffers are + * contiguous anyway, so drop EXYNOS_BO_NONCONTIG flag + */ + flags &= ~EXYNOS_BO_NONCONTIG; + DRM_WARN("Non-contiguous allocation is not supported without IOMMU, falling back to contiguous buffer\n"); + } + /* set memory type and cache attribute from user side. */ exynos_gem->flags = flags; -- 2.14.2

7 years, 7 months

3
3
0 0

[Linux-stable-mirror] [PATCH] drm/vblank: Pass crtc_id to page_flip_ioctl.

by Maarten Lankhorst

We added crtc_id to the atomic ioctl, but forgot to add it for vblank and page flip events. Commit bd386e518056 ("drm: Reorganize drm_pending_event to support future event types [v2]") added it to the vblank event, but page flip event was still missing. Correct this and add a test for making sure we always set crtc_id correctly. Fixes: bd386e518056 ("drm: Reorganize drm_pending_event to support future event types [v2]") Fixes: 5db06a8a98f5 ("drm: Pass CRTC ID in userspace vblank events") Cc: Daniel Stone <daniels(a)collabora.com> Cc: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Gustavo Padovan <gustavo(a)padovan.org> Cc: Sean Paul <seanpaul(a)chromium.org> Cc: dri-devel(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v4.12+ Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> --- drivers/gpu/drm/drm_plane.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 19404e34cd59..37a93cdffb4a 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -1030,6 +1030,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev, e->event.base.type = DRM_EVENT_FLIP_COMPLETE; e->event.base.length = sizeof(e->event); e->event.vbl.user_data = page_flip->user_data; + e->event.vbl.crtc_id = crtc->base.id; ret = drm_event_reserve_init(dev, file_priv, &e->base, &e->event.base); if (ret) { kfree(e); -- 2.15.0

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH 4.14 00/18] 4.14.2-stable review

by Antoine Tenart

Hi Kevin, On Wed, Nov 22, 2017 at 03:43:51PM -0800, Kevin Hilman wrote: > kernelci.org bot <bot(a)kernelci.org> writes: > > > stable-rc/linux-4.14.y boot: 100 boots: 3 failed, 96 passed with 1 untried/unknown (v4.14.1-19-g6d0448582cf7) > > > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.1… > > Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.1-19-… > > > > Tree: stable-rc > > Branch: linux-4.14.y > > Git Describe: v4.14.1-19-g6d0448582cf7 > > Git Commit: 6d0448582cf754db0c8eedcb85edc01692892f50 > > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > Tested: 43 unique boards, 16 SoC families, 18 builds out of 189 > > TL;DR; All is well, but Cc'd Free Electrons for double check. Thanks for the hint, we'll double check this one. Antoine -- Antoine Ténart, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH 3.18 00/12] 3.18.84-stable review

by Greg Kroah-Hartman

On Wed, Nov 22, 2017 at 03:49:03PM -0800, Kevin Hilman wrote: > kernelci.org bot <bot(a)kernelci.org> writes: > > > stable-rc/linux-3.18.y boot: 44 boots: 2 failed, 42 passed (v3.18.83-12-g09d9c198f334) > > > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.1… > > Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.83-12… > > > > Tree: stable-rc > > Branch: linux-3.18.y > > Git Describe: v3.18.83-12-g09d9c198f334 > > Git Commit: 09d9c198f3343abad9fceeab61c33c351793aac7 > > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > Tested: 18 unique boards, 9 SoC families, 13 builds out of 177 > > > > Boot Regressions Detected: > > > > arm: > > > > multi_v7_defconfig: > > armada-xp-openblocks-ax3-4: > > lab-free-electrons: new failure (last pass: v3.18.83-10-g097340129e75) > > > > sama5_defconfig: > > at91-sama5d3_xplained_rootfs:nfs: > > lab-free-electrons: new failure (last pass: v3.18.83-10-g097340129e75) > > These are both passing now in the latest 3.18.y branch[1], so whatever it > was is now gone: Thanks for the manual verification on all of these. greg k-h

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH AUTOSEL for 4.9 01/54] dax: Avoid page invalidation races and unnecessary radix tree traversals

by alexander.levin＠verizon.com

From: Jan Kara <jack(a)suse.cz> [ Upstream commit e3fce68cdbed297d927e993b3ea7b8b1cee545da ] Currently dax_iomap_rw() takes care of invalidating page tables and evicting hole pages from the radix tree when write(2) to the file happens. This invalidation is only necessary when there is some block allocation resulting from write(2). Furthermore in current place the invalidation is racy wrt page fault instantiating a hole page just after we have invalidated it. So perform the page invalidation inside dax_iomap_actor() where we can do it only when really necessary and after blocks have been allocated so nobody will be instantiating new hole pages anymore. Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Ross Zwisler <ross.zwisler(a)linux.intel.com> Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> --- fs/dax.c | 28 +++++++++++----------------- 1 file changed, 11 insertions(+), 17 deletions(-) diff --git a/fs/dax.c b/fs/dax.c index bf6218da7928..800748f10b3d 100644 --- a/fs/dax.c +++ b/fs/dax.c @@ -1265,6 +1265,17 @@ iomap_dax_actor(struct inode *inode, loff_t pos, loff_t length, void *data, if (WARN_ON_ONCE(iomap->type != IOMAP_MAPPED)) return -EIO; + /* + * Write can allocate block for an area which has a hole page mapped + * into page tables. We have to tear down these mappings so that data + * written by write(2) is visible in mmap. + */ + if ((iomap->flags & IOMAP_F_NEW) && inode->i_mapping->nrpages) { + invalidate_inode_pages2_range(inode->i_mapping, + pos >> PAGE_SHIFT, + (end - 1) >> PAGE_SHIFT); + } + while (pos < end) { unsigned offset = pos & (PAGE_SIZE - 1); struct blk_dax_ctl dax = { 0 }; @@ -1329,23 +1340,6 @@ iomap_dax_rw(struct kiocb *iocb, struct iov_iter *iter, if (iov_iter_rw(iter) == WRITE) flags |= IOMAP_WRITE; - /* - * Yes, even DAX files can have page cache attached to them: A zeroed - * page is inserted into the pagecache when we have to serve a write - * fault on a hole. It should never be dirtied and can simply be - * dropped from the pagecache once we get real data for the page. - * - * XXX: This is racy against mmap, and there's nothing we can do about - * it. We'll eventually need to shift this down even further so that - * we can check if we allocated blocks over a hole first. - */ - if (mapping->nrpages) { - ret = invalidate_inode_pages2_range(mapping, - pos >> PAGE_SHIFT, - (pos + iov_iter_count(iter) - 1) >> PAGE_SHIFT); - WARN_ON_ONCE(ret); - } - while (iov_iter_count(iter)) { ret = iomap_apply(inode, pos, iov_iter_count(iter), flags, ops, iter, iomap_dax_actor); -- 2.11.0

7 years, 7 months

2
54
0 0

[Linux-stable-mirror] [PATCH] x86/entry/64: Add missing irqflags tracing to native_load_gs_index()

by Andy Lutomirski

Running this code with IRQs enabled (where dummy_lock is a spinlock): static void check_load_gs_index(void) { /* This will fail. */ load_gs_index(0xffff); spin_lock(&dummy_lock); spin_unlock(&dummy_lock); } Will generate a lockdep warning. The issue is that the actual write to %gs would cause an exception with IRQs disabled, and the exception handler would, as an inadvertent side effect, update irqflag tracing to reflect the IRQs-off status. native_load_gs_index() would then turn IRQs back on and return with irqflag tracing still thinking that IRQs were off. The dummy lock-and-unlock causes lockdep to notice the error and warn. Fix it by adding the missing tracing. Apparently nothing did this in a context where it mattered. I haven't tried to find a code path that would actually exhibit the warning if appropriately nasty user code were running. I suspect that the security impact of this bug is very, very low -- production systems don't run with lockdep enabled, and the warning is mostly harmless anyway. Found during a quick audit of the entry code to try to track down an unrelated bug that Ingo found in some still-in-development code. Cc: stable(a)vger.kernel.org Signed-off-by: Andy Lutomirski <luto(a)kernel.org> --- Hi Ingo- You asked me to look for an irqflag tracing bug, so I found one :) arch/x86/entry/entry_64.S | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index a2b30ec69497..3c288f260fdf 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -51,15 +51,19 @@ ENTRY(native_usergs_sysret64) END(native_usergs_sysret64) #endif /* CONFIG_PARAVIRT */ -.macro TRACE_IRQS_IRETQ +.macro TRACE_IRQS_FLAGS flags:req #ifdef CONFIG_TRACE_IRQFLAGS - bt $9, EFLAGS(%rsp) /* interrupts off? */ + bt $9, \flags /* interrupts off? */ jnc 1f TRACE_IRQS_ON 1: #endif .endm +.macro TRACE_IRQS_IRETQ + TRACE_IRQS_FLAGS EFLAGS(%rsp) +.endm + /* * When dynamic function tracer is enabled it will add a breakpoint * to all locations that it is about to modify, sync CPUs, update @@ -943,11 +947,13 @@ ENTRY(native_load_gs_index) FRAME_BEGIN pushfq DISABLE_INTERRUPTS(CLBR_ANY & ~CLBR_RDI) + TRACE_IRQS_OFF SWAPGS .Lgs_change: movl %edi, %gs 2: ALTERNATIVE "", "mfence", X86_BUG_SWAPGS_FENCE SWAPGS + TRACE_IRQS_FLAGS (%rsp) popfq FRAME_END ret -- 2.13.6

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [RESEND][PATCH v2] cxl: Check if vphb exists before iterating over AFU devices

by Vaibhav Jain

During an eeh a kernel-oops is reported if no vPHB to allocated to the AFU. This happens as during AFU init, an error in creation of vPHB is a non-fatal error. Hence afu->phb should always be checked for NULL before iterating over it for the virtual AFU pci devices. This patch fixes the kenel-oops by adding a NULL pointer check for afu->phb before it is dereferenced. Fixes: 9e8df8a2196("cxl: EEH support") Cc: stable(a)vger.kernel.org Signed-off-by: Vaibhav Jain <vaibhav(a)linux.vnet.ibm.com> --- Changelog: Resend -> Added the 'Fixes' info and marking the patch to stable tree [Mpe] v2 -> Added the vphb NULL check to cxl_vphb_error_detected() [Andrew] --- drivers/misc/cxl/pci.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c index bb7fd3f4edab..18773343ab3e 100644 --- a/drivers/misc/cxl/pci.c +++ b/drivers/misc/cxl/pci.c @@ -2083,6 +2083,9 @@ static pci_ers_result_t cxl_vphb_error_detected(struct cxl_afu *afu, /* There should only be one entry, but go through the list * anyway */ + if (afu->phb == NULL) + return result; + list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) { if (!afu_dev->driver) continue; @@ -2124,8 +2127,7 @@ static pci_ers_result_t cxl_pci_error_detected(struct pci_dev *pdev, * Tell the AFU drivers; but we don't care what they * say, we're going away. */ - if (afu->phb != NULL) - cxl_vphb_error_detected(afu, state); + cxl_vphb_error_detected(afu, state); } return PCI_ERS_RESULT_DISCONNECT; } @@ -2265,6 +2267,9 @@ static pci_ers_result_t cxl_pci_slot_reset(struct pci_dev *pdev) if (cxl_afu_select_best_mode(afu)) goto err; + if (afu->phb == NULL) + continue; + list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) { /* Reset the device context. * TODO: make this less disruptive @@ -2327,6 +2332,9 @@ static void cxl_pci_resume(struct pci_dev *pdev) for (i = 0; i < adapter->slices; i++) { afu = adapter->afu[i]; + if (afu->phb != NULL) + continue; + list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) { if (afu_dev->driver && afu_dev->driver->err_handler && afu_dev->driver->err_handler->resume) -- 2.14.3

7 years, 7 months

2
2
0 0

Re: [Linux-stable-mirror] [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid resource if buffer length too long

by alexander.levin＠verizon.com

On Wed, Nov 15, 2017 at 03:39:22PM +0000, Moore, Robert wrote: >> -----Original Message----- >> From: alexander.levin(a)verizon.com [mailto:alexander.levin@verizon.com] >> Sent: Tuesday, November 14, 2017 6:46 PM >> To: linux-kernel(a)vger.kernel.org; stable(a)vger.kernel.org >> Cc: Moore, Robert <robert.moore(a)intel.com>; Zheng, Lv >> <lv.zheng(a)intel.com>; Wysocki, Rafael J <rafael.j.wysocki(a)intel.com>; >> alexander.levin(a)verizon.com >> Subject: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid >> resource if buffer length too long >> >> From: Bob Moore <robert.moore(a)intel.com> >> >> [ Upstream commit 57707a9a7780fab426b8ae9b4c7b65b912a748b3 ] >> >> ACPICA commit 9f76de2d249b18804e35fb55d14b1c2604d627a1 >> ACPICA commit b2e89d72ef1e9deefd63c3fd1dee90f893575b3a >> ACPICA commit 23b5bbe6d78afd3c5abf3adb91a1b098a3000b2e >> >> The declared buffer length must be the same as the length of the byte >> initializer list, otherwise not a valid resource descriptor. [snip] >[Moore, Robert] > >Please explain what you are doing here. Proposing this commit for the 4.9 LTS tree. -- Thanks, Sasha

7 years, 7 months

2
4
0 0

[Linux-stable-mirror] [PATCH AUTOSEL for 3.18 1/8] ima: fix hash algorithm initialization

by alexander.levin＠verizon.com

From: Boshi Wang <wangboshi(a)huawei.com> [ Upstream commit ebe7c0a7be92bbd34c6ff5b55810546a0ee05bee ] The hash_setup function always sets the hash_setup_done flag, even when the hash algorithm is invalid. This prevents the default hash algorithm defined as CONFIG_IMA_DEFAULT_HASH from being used. This patch sets hash_setup_done flag only for valid hash algorithms. Fixes: e7a2ad7eb6f4 "ima: enable support for larger default filedata hash algorithms" Signed-off-by: Boshi Wang <wangboshi(a)huawei.com> Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> --- security/integrity/ima/ima_main.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c index 62f59eca32d3..01590949eddd 100644 --- a/security/integrity/ima/ima_main.c +++ b/security/integrity/ima/ima_main.c @@ -52,6 +52,8 @@ static int __init hash_setup(char *str) ima_hash_algo = HASH_ALGO_SHA1; else if (strncmp(str, "md5", 3) == 0) ima_hash_algo = HASH_ALGO_MD5; + else + return 1; goto out; } @@ -61,6 +63,8 @@ static int __init hash_setup(char *str) break; } } + if (i == HASH_ALGO__LAST) + return 1; out: hash_setup_done = 1; return 1; -- 2.11.0

7 years, 7 months

1
7
0 0

[Linux-stable-mirror] [PATCH AUTOSEL for 4.4 01/16] ima: fix hash algorithm initialization

by alexander.levin＠verizon.com

From: Boshi Wang <wangboshi(a)huawei.com> [ Upstream commit ebe7c0a7be92bbd34c6ff5b55810546a0ee05bee ] The hash_setup function always sets the hash_setup_done flag, even when the hash algorithm is invalid. This prevents the default hash algorithm defined as CONFIG_IMA_DEFAULT_HASH from being used. This patch sets hash_setup_done flag only for valid hash algorithms. Fixes: e7a2ad7eb6f4 "ima: enable support for larger default filedata hash algorithms" Signed-off-by: Boshi Wang <wangboshi(a)huawei.com> Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> --- security/integrity/ima/ima_main.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c index c21f09bf8b99..98289ba2a2e6 100644 --- a/security/integrity/ima/ima_main.c +++ b/security/integrity/ima/ima_main.c @@ -52,6 +52,8 @@ static int __init hash_setup(char *str) ima_hash_algo = HASH_ALGO_SHA1; else if (strncmp(str, "md5", 3) == 0) ima_hash_algo = HASH_ALGO_MD5; + else + return 1; goto out; } @@ -61,6 +63,8 @@ static int __init hash_setup(char *str) break; } } + if (i == HASH_ALGO__LAST) + return 1; out: hash_setup_done = 1; return 1; -- 2.11.0

7 years, 7 months

1
15
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror