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

[PATCH] f2fs: flush data when enabling checkpoint back

by Jaegeuk Kim

During checkpoint=disable period, f2fs bypasses all the synchronous IOs such as sync and fsync. So, when enabling it back, we must flush all of them in order to keep the data persistent. Otherwise, suddern power-cut right after enabling checkpoint will cause data loss. Fixes: 4354994f097d ("f2fs: checkpoint disabling") Cc: stable(a)vger.kernel.org Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> --- fs/f2fs/super.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index 359cc5a2f8f5..073b51af62c8 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -1887,6 +1887,9 @@ static int f2fs_disable_checkpoint(struct f2fs_sb_info *sbi) static void f2fs_enable_checkpoint(struct f2fs_sb_info *sbi) { + /* we should flush all the data to keep data consistency */ + sync_inodes_sb(sbi->sb); + down_write(&sbi->gc_lock); f2fs_dirty_to_prefree(sbi); -- 2.30.0.280.ga3ce27912f-goog

4 years, 6 months

2
1
0 0

[PATCH v3] kdb: Make memory allocations more robust

by Sumit Garg

Currently kdb uses in_interrupt() to determine whether its library code has been called from the kgdb trap handler or from a saner calling context such as driver init. This approach is broken because in_interrupt() alone isn't able to determine kgdb trap handler entry from normal task context. This can happen during normal use of basic features such as breakpoints and can also be trivially reproduced using: echo g > /proc/sysrq-trigger We can improve this by adding check for in_dbg_master() instead which explicitly determines if we are running in debugger context. Cc: stable(a)vger.kernel.org Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- Changes in v3: - Refined commit description and Cc: stable(a)vger.kernel.org. Changes in v2: - Get rid of redundant in_atomic() check. kernel/debug/kdb/kdb_private.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/debug/kdb/kdb_private.h b/kernel/debug/kdb/kdb_private.h index 7a4a181..344eb0d 100644 --- a/kernel/debug/kdb/kdb_private.h +++ b/kernel/debug/kdb/kdb_private.h @@ -231,7 +231,7 @@ extern struct task_struct *kdb_curr_task(int); #define kdb_task_has_cpu(p) (task_curr(p)) -#define GFP_KDB (in_interrupt() ? GFP_ATOMIC : GFP_KERNEL) +#define GFP_KDB (in_dbg_master() ? GFP_ATOMIC : GFP_KERNEL) extern void *debug_kmalloc(size_t size, gfp_t flags); extern void debug_kfree(void *); -- 2.7.4

4 years, 6 months

3
4
0 0

[PATCH] hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist

by Thomas Hebb

It has been reported[0] that the Dell XPS 15 L502X exhibits similar freezing behavior to the other systems[1] on this blacklist. The issue was exposed by a prior change of mine to automatically load dell_smm_hwmon on a wider set of XPS models. To fix the regression, add this model to the blacklist. [0] https://bugzilla.kernel.org/show_bug.cgi?id=211081 [1] https://bugzilla.kernel.org/show_bug.cgi?id=195751 Fixes: b8a13e5e8f37 ("hwmon: (dell-smm) Use one DMI match for all XPS models") Cc: stable(a)vger.kernel.org Reported-by: Bob Hepple <bob.hepple(a)gmail.com> Tested-by: Bob Hepple <bob.hepple(a)gmail.com> Signed-off-by: Thomas Hebb <tommyhebb(a)gmail.com> --- drivers/hwmon/dell-smm-hwmon.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c index ec448f5f2dc3..73b9db9e3aab 100644 --- a/drivers/hwmon/dell-smm-hwmon.c +++ b/drivers/hwmon/dell-smm-hwmon.c @@ -1159,6 +1159,13 @@ static struct dmi_system_id i8k_blacklist_fan_support_dmi_table[] __initdata = { DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "XPS13 9333"), }, }, + { + .ident = "Dell XPS 15 L502X", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Dell System XPS L502X"), + }, + }, { } }; -- 2.30.0

4 years, 6 months

5
8
0 0

[PATCH v3] riscv: set max_pfn to the PFN of the last page

by Vincent Chen

The current max_pfn equals to zero. In this case, I found it caused users cannot get some page information through /proc such as kpagecount in v5.6 kernel because of new sanity checks. The following message is displayed by stress-ng test suite with the command "stress-ng --verbose --physpage 1 -t 1" on HiFive unleashed board. # stress-ng --verbose --physpage 1 -t 1 stress-ng: debug: [109] 4 processors online, 4 processors configured stress-ng: info: [109] dispatching hogs: 1 physpage stress-ng: debug: [109] cache allocate: reducing cache level from L3 (too high) to L0 stress-ng: debug: [109] get_cpu_cache: invalid cache_level: 0 stress-ng: info: [109] cache allocate: using built-in defaults as no suitable cache found stress-ng: debug: [109] cache allocate: default cache size: 2048K stress-ng: debug: [109] starting stressors stress-ng: debug: [109] 1 stressor spawned stress-ng: debug: [110] stress-ng-physpage: started [110] (instance 0) stress-ng: error: [110] stress-ng-physpage: cannot read page count for address 0x3fd34de000 in /proc/kpagecount, errno=0 (Success) stress-ng: error: [110] stress-ng-physpage: cannot read page count for address 0x3fd32db078 in /proc/kpagecount, errno=0 (Success) ... stress-ng: error: [110] stress-ng-physpage: cannot read page count for address 0x3fd32db078 in /proc/kpagecount, errno=0 (Success) stress-ng: debug: [110] stress-ng-physpage: exited [110] (instance 0) stress-ng: debug: [109] process [110] terminated stress-ng: info: [109] successful run completed in 1.00s # After applying this patch, the kernel can pass the test. # stress-ng --verbose --physpage 1 -t 1 stress-ng: debug: [104] 4 processors online, 4 processors configured stress-ng: info: [104] dispatching hogs: 1 physpage stress-ng: info: [104] cache allocate: using defaults, can't determine cache details from sysfs stress-ng: debug: [104] cache allocate: default cache size: 2048K stress-ng: debug: [104] starting stressors stress-ng: debug: [104] 1 stressor spawned stress-ng: debug: [105] stress-ng-physpage: started [105] (instance 0) stress-ng: debug: [105] stress-ng-physpage: exited [105] (instance 0) stress-ng: debug: [104] process [105] terminated stress-ng: info: [104] successful run completed in 1.01s # Fixes: 0651c263c8e3 (RISC-V: Move setup_bootmem() to mm/init.c) Cc: stable(a)vger.kernel.org Signed-off-by: Vincent Chen <vincent.chen(a)sifive.com> Reviewed-by: Anup Patel <anup(a)brainfault.org> Reviewed-by: Yash Shah <yash.shah(a)sifive.com> Tested-by: Yash Shah <yash.shah(a)sifive.com> Changes since v1: 1. Add Fixes line and Cc stable kernel Changes since v2: 1. Fix typo in Anup email address --- arch/riscv/mm/init.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index fab855963c73..157924baa191 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -149,7 +149,8 @@ void __init setup_bootmem(void) memblock_reserve(vmlinux_start, vmlinux_end - vmlinux_start); set_max_mapnr(PFN_DOWN(mem_size)); - max_low_pfn = PFN_DOWN(memblock_end_of_DRAM()); + max_pfn = PFN_DOWN(memblock_end_of_DRAM()); + max_low_pfn = max_pfn; #ifdef CONFIG_BLK_DEV_INITRD setup_initrd(); -- 2.7.4

4 years, 6 months

3
2
0 0

[PATCH v3] iommu/vt-d: do not use flush-queue when caching-mode is on

by Nadav Amit

From: Nadav Amit <namit(a)vmware.com> When an Intel IOMMU is virtualized, and a physical device is passed-through to the VM, changes of the virtual IOMMU need to be propagated to the physical IOMMU. The hypervisor therefore needs to monitor PTE mappings in the IOMMU page-tables. Intel specifications provide "caching-mode" capability that a virtual IOMMU uses to report that the IOMMU is virtualized and a TLB flush is needed after mapping to allow the hypervisor to propagate virtual IOMMU mappings to the physical IOMMU. To the best of my knowledge no real physical IOMMU reports "caching-mode" as turned on. Synchronizing the virtual and the physical IOMMU tables is expensive if the hypervisor is unaware which PTEs have changed, as the hypervisor is required to walk all the virtualized tables and look for changes. Consequently, domain flushes are much more expensive than page-specific flushes on virtualized IOMMUs with passthrough devices. The kernel therefore exploited the "caching-mode" indication to avoid domain flushing and use page-specific flushing in virtualized environments. See commit 78d5f0f500e6 ("intel-iommu: Avoid global flushes with caching mode.") This behavior changed after commit 13cf01744608 ("iommu/vt-d: Make use of iova deferred flushing"). Now, when batched TLB flushing is used (the default), full TLB domain flushes are performed frequently, requiring the hypervisor to perform expensive synchronization between the virtual TLB and the physical one. Getting batched TLB flushes to use page-specific invalidations again in such circumstances is not easy, since the TLB invalidation scheme assumes that "full" domain TLB flushes are performed for scalability. Disable batched TLB flushes when caching-mode is on, as the performance benefit from using batched TLB invalidations is likely to be much smaller than the overhead of the virtual-to-physical IOMMU page-tables synchronization. Fixes: 13cf01744608 ("iommu/vt-d: Make use of iova deferred flushing") Signed-off-by: Nadav Amit <namit(a)vmware.com> Cc: David Woodhouse <dwmw2(a)infradead.org> Cc: Lu Baolu <baolu.lu(a)linux.intel.com> Cc: Joerg Roedel <joro(a)8bytes.org> Cc: Will Deacon <will(a)kernel.org> Cc: stable(a)vger.kernel.org --- v2->v3: * Fix the fixes tag in the commit-log (Lu). * Minor English rephrasing of the commit-log. v1->v2: * disable flush queue for all domains if caching-mode is on for any IOMMU (Lu). --- drivers/iommu/intel/iommu.c | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 788119c5b021..de3dd617cf60 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -5373,6 +5373,36 @@ intel_iommu_domain_set_attr(struct iommu_domain *domain, return ret; } +static bool domain_use_flush_queue(void) +{ + struct dmar_drhd_unit *drhd; + struct intel_iommu *iommu; + bool r = true; + + if (intel_iommu_strict) + return false; + + /* + * The flush queue implementation does not perform page-selective + * invalidations that are required for efficient TLB flushes in virtual + * environments. The benefit of batching is likely to be much lower than + * the overhead of synchronizing the virtual and physical IOMMU + * page-tables. + */ + rcu_read_lock(); + for_each_active_iommu(iommu, drhd) { + if (!cap_caching_mode(iommu->cap)) + continue; + + pr_warn_once("IOMMU batching is disabled due to virtualization"); + r = false; + break; + } + rcu_read_unlock(); + + return r; +} + static int intel_iommu_domain_get_attr(struct iommu_domain *domain, enum iommu_attr attr, void *data) @@ -5383,7 +5413,7 @@ intel_iommu_domain_get_attr(struct iommu_domain *domain, case IOMMU_DOMAIN_DMA: switch (attr) { case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE: - *(int *)data = !intel_iommu_strict; + *(int *)data = domain_use_flush_queue(); return 0; default: return -ENODEV; -- 2.25.1

4 years, 6 months

2
1
0 0

Re: [PATCH] hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist

by Tom Hebb

Bob reports that blacklisting the fan type label is not sufficient. See his message to me below. On Mon, Jan 25, 2021 at 3:38 PM Bob Hepple <bob.hepple(a)gmail.com> wrote: > > Hi Tom, > > Big nope this end with L502x in i8k_blacklist_fan_type_dmi_table: > > Jan 26 09:35:47 achar kernel: psmouse serio1: TouchPad at > isa0060/serio1/input0 lost synchronization, throwing 1 bytes> > > ... and lots of trackpad stall/stutters. > > Cheers > > > Bob > > > > On Tue, 26 Jan 2021 at 08:09, Bob Hepple <bob.hepple(a)gmail.com> wrote: > > > > ... compiling now ... results in a coupla hours > > > > Cheers > > > > > > Bob > > > > On Tue, 26 Jan 2021 at 04:05, Tom Hebb <tommyhebb(a)gmail.com> wrote: > > > > > > On Mon, Jan 25, 2021 at 2:05 AM Pali Rohár <pali(a)kernel.org> wrote: > > > > > > > > On Saturday 23 January 2021 18:46:08 Thomas Hebb wrote: > > > > > It has been reported[0] that the Dell XPS 15 L502X exhibits similar > > > > > freezing behavior to the other systems[1] on this blacklist. The issue > > > > > was exposed by a prior change of mine to automatically load > > > > > dell_smm_hwmon on a wider set of XPS models. To fix the regression, add > > > > > this model to the blacklist. > > > > > > > > > > [0] https://bugzilla.kernel.org/show_bug.cgi?id=211081 > > > > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=195751 > > > > > > > > > > Fixes: b8a13e5e8f37 ("hwmon: (dell-smm) Use one DMI match for all XPS models") > > > > > Cc: stable(a)vger.kernel.org > > > > > Reported-by: Bob Hepple <bob.hepple(a)gmail.com> > > > > > Tested-by: Bob Hepple <bob.hepple(a)gmail.com> > > > > > Signed-off-by: Thomas Hebb <tommyhebb(a)gmail.com> > > > > > --- > > > > > > > > > > drivers/hwmon/dell-smm-hwmon.c | 7 +++++++ > > > > > 1 file changed, 7 insertions(+) > > > > > > > > > > diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c > > > > > index ec448f5f2dc3..73b9db9e3aab 100644 > > > > > --- a/drivers/hwmon/dell-smm-hwmon.c > > > > > +++ b/drivers/hwmon/dell-smm-hwmon.c > > > > > @@ -1159,6 +1159,13 @@ static struct dmi_system_id i8k_blacklist_fan_support_dmi_table[] __initdata = { > > > > > DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "XPS13 9333"), > > > > > }, > > > > > }, > > > > > + { > > > > > + .ident = "Dell XPS 15 L502X", > > > > > + .matches = { > > > > > + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), > > > > > + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Dell System XPS L502X"), > > > > > > > > Hello! Are you sure that it is required to completely disable fan > > > > support? And not only access to fan type label for which is different > > > > blaclist i8k_blacklist_fan_type_dmi_table? > > > > > > This is a good question. We didn't try the other list. Bob is the one with the > > > affected system. Could you try moving the added block of code from > > > i8k_blacklist_fan_support_dmi_table a few lines up to > > > i8k_blacklist_fan_type_dmi_table, Bob, to see if the issue reappears or if it > > > remains fixed? > > > > > > > > > > > And have you reported this issue to Dell support? > > > > > > > > > + }, > > > > > + }, > > > > > { } > > > > > }; > > > > > > > > > > -- > > > > > 2.30.0 > > > > > > > > > > > (Apologies for the previous HTML copy of this reply, to those directly CCed.) > > > > > > -Tom

4 years, 6 months

3
4
0 0

+ mm-rmap-fix-potential-pte_unmap-on-an-not-mapped-pte.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/rmap: fix potential pte_unmap on an not mapped pte has been added to the -mm tree. Its filename is mm-rmap-fix-potential-pte_unmap-on-an-not-mapped-pte.patch This patch should soon appear at https://ozlabs.org/~akpm/mmots/broken-out/mm-rmap-fix-potential-pte_unmap-o… and later at https://ozlabs.org/~akpm/mmotm/broken-out/mm-rmap-fix-potential-pte_unmap-o… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Miaohe Lin <linmiaohe(a)huawei.com> Subject: mm/rmap: fix potential pte_unmap on an not mapped pte For PMD-mapped page (usually THP), pvmw->pte is NULL. For PTE-mapped THP, pvmw->pte is mapped. But for HugeTLB pages, pvmw->pte is not mapped and set to the relevant page table entry. So in page_vma_mapped_walk_done(), we may do pte_unmap() for HugeTLB pte which is not mapped. Fix this by checking pvmw->page against PageHuge before trying to do pte_unmap(). Link: https://lkml.kernel.org/r/20210127093349.39081-1-linmiaohe@huawei.com Fixes: ace71a19cec5 ("mm: introduce page_vma_mapped_walk()") Signed-off-by: Hongxiang Lou <louhongxiang(a)huawei.com> Signed-off-by: Miaohe Lin <linmiaohe(a)huawei.com> Cc: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: Shakeel Butt <shakeelb(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Michel Lespinasse <walken(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/rmap.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/include/linux/rmap.h~mm-rmap-fix-potential-pte_unmap-on-an-not-mapped-pte +++ a/include/linux/rmap.h @@ -213,7 +213,8 @@ struct page_vma_mapped_walk { static inline void page_vma_mapped_walk_done(struct page_vma_mapped_walk *pvmw) { - if (pvmw->pte) + /* HugeTLB pte is set to the relevant page table entry without pte_mapped. */ + if (pvmw->pte && !PageHuge(pvmw->page)) pte_unmap(pvmw->pte); if (pvmw->ptl) spin_unlock(pvmw->ptl); _ Patches currently in -mm which might be from linmiaohe(a)huawei.com are mm-rmap-fix-potential-pte_unmap-on-an-not-mapped-pte.patch mm-page_owner-use-helper-function-zone_end_pfn-to-get-end_pfn.patch mm-fix-potential-pte_unmap_unlock-pte-error.patch mm-hugetlb-fix-potential-double-free-in-hugetlb_register_node-error-path.patch mm-hugetlb-avoid-unnecessary-hugetlb_acct_memory-call.patch mm-hugetlb-use-helper-huge_page_order-and-pages_per_huge_page.patch mm-hugetlb-fix-use-after-free-when-subpool-max_hpages-accounting-is-not-enabled.patch mm-workingsetc-avoid-unnecessary-max_nodes-estimation-in-count_shadow_nodes.patch z3fold-remove-unused-attribute-for-release_z3fold_page.patch z3fold-simplify-the-zhdr-initialization-code-in-init_z3fold_page.patch mm-compaction-remove-duplicated-vm_bug_on_page-pagelocked.patch hugetlbfs-remove-useless-bug_oninode-in-hugetlbfs_setattr.patch hugetlbfs-use-helper-macro-default_hstate-in-init_hugetlbfs_fs.patch hugetlbfs-correct-obsolete-function-name-in-hugetlbfs_read_iter.patch hugetlbfs-remove-meaningless-variable-avoid_reserve.patch hugetlbfs-make-hugepage-size-conversion-more-readable.patch hugetlbfs-correct-some-obsolete-comments-about-inode-i_mutex.patch mm-memory_hotplug-use-helper-function-zone_end_pfn-to-get-end_pfn.patch mm-rmap-correct-some-obsolete-comments-of-anon_vma.patch mm-zsmallocc-convert-to-use-kmem_cache_zalloc-in-cache_alloc_zspage.patch

4 years, 6 months

1
0
0 0

stable-rc/queue/4.4 baseline: 96 runs, 11 regressions (v4.4.253-20-gefb3258395d47)

by kernelci.org bot

stable-rc/queue/4.4 baseline: 96 runs, 11 regressions (v4.4.253-20-gefb3258395d47) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions --------------------+--------+-----------------+----------+---------------------+------------ dove-cubox | arm | lab-pengutronix | gcc-8 | mvebu_v7_defconfig | 1 panda | arm | lab-collabora | gcc-8 | omap2plus_defconfig | 1 qemu_arm-virt-gicv2 | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 1 qemu_arm-virt-gicv2 | arm | lab-broonie | gcc-8 | multi_v7_defconfig | 1 qemu_arm-virt-gicv2 | arm | lab-cip | gcc-8 | multi_v7_defconfig | 1 qemu_arm-virt-gicv2 | arm | lab-collabora | gcc-8 | multi_v7_defconfig | 1 qemu_arm-virt-gicv3 | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 1 qemu_arm-virt-gicv3 | arm | lab-broonie | gcc-8 | multi_v7_defconfig | 1 qemu_arm-virt-gicv3 | arm | lab-cip | gcc-8 | multi_v7_defconfig | 1 qemu_arm-virt-gicv3 | arm | lab-collabora | gcc-8 | multi_v7_defconfig | 1 qemu_x86_64 | x86_64 | lab-baylibre | gcc-8 | x86_64_defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F4.4/kernel/v4.4.253-… Test: baseline Tree: stable-rc Branch: queue/4.4 Describe: v4.4.253-20-gefb3258395d47 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: efb3258395d474462eb4dc5323e2ec19dc1fdce6 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions --------------------+--------+-----------------+----------+---------------------+------------ dove-cubox | arm | lab-pengutronix | gcc-8 | mvebu_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/60118eda74bb50aa32d3dfd5 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: mvebu_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/60118eda74bb50aa32d3dfd6 new failure (last pass: v4.4.253-20-g3a8011819531) platform | arch | lab | compiler | defconfig | regressions --------------------+--------+-----------------+----------+---------------------+------------ panda | arm | lab-collabora | gcc-8 | omap2plus_defconfig | 1 Details: https://kernelci.org/test/plan/id/601190baaa39362810d3dffb Results: 3 PASS, 1 FAIL, 1 SKIP Full config: omap2plus_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.dmesg.emerg: https://kernelci.org/test/case/id/601190baaa39362810d3e000 failing since 0 day (last pass: v4.4.253-20-gafb85ed554884, first fail: v4.4.253-20-g3a8011819531) 2 lines 2021-01-27 16:11:34.725000+00:00 kern :emerg : BUG: spinlock bad magic on CPU#0, udevd/110 2021-01-27 16:11:34.734000+00:00 kern :emerg : lock: emif_lock+0x0/0xfffff26c [emif], .magic: dead4ead, .owner: <none>/-1, .owner_cpu: -1 platform | arch | lab | compiler | defconfig | regressions --------------------+--------+-----------------+----------+---------------------+------------ qemu_arm-virt-gicv2 | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/601190bb790fd5c46fd3dfcc Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/601190bb790fd5c46fd3dfcd failing since 74 days (last pass: v4.4.243-18-gfc7e8c68369a, first fail: v4.4.243-19-g71b6c961c7fe) platform | arch | lab | compiler | defconfig | regressions --------------------+--------+-----------------+----------+---------------------+------------ qemu_arm-virt-gicv2 | arm | lab-broonie | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/601190f49ce3206422d3dfd7 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/601190f49ce3206422d3dfd8 failing since 74 days (last pass: v4.4.243-18-gfc7e8c68369a, first fail: v4.4.243-19-g71b6c961c7fe) platform | arch | lab | compiler | defconfig | regressions --------------------+--------+-----------------+----------+---------------------+------------ qemu_arm-virt-gicv2 | arm | lab-cip | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/601190c9e5a9170bdfd3dfc9 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/601190c9e5a9170bdfd3dfca failing since 74 days (last pass: v4.4.243-18-gfc7e8c68369a, first fail: v4.4.243-19-g71b6c961c7fe) platform | arch | lab | compiler | defconfig | regressions --------------------+--------+-----------------+----------+---------------------+------------ qemu_arm-virt-gicv2 | arm | lab-collabora | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/601190a9aa39362810d3dff2 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/601190a9aa39362810d3dff3 failing since 74 days (last pass: v4.4.243-18-gfc7e8c68369a, first fail: v4.4.243-19-g71b6c961c7fe) platform | arch | lab | compiler | defconfig | regressions --------------------+--------+-----------------+----------+---------------------+------------ qemu_arm-virt-gicv3 | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/6011909ca421998bc8d3dfc9 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/6011909ca421998bc8d3dfca failing since 74 days (last pass: v4.4.243-18-gfc7e8c68369a, first fail: v4.4.243-19-g71b6c961c7fe) platform | arch | lab | compiler | defconfig | regressions --------------------+--------+-----------------+----------+---------------------+------------ qemu_arm-virt-gicv3 | arm | lab-broonie | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/601190a96ef6a6965fd3dfef Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/601190a96ef6a6965fd3dff0 failing since 74 days (last pass: v4.4.243-18-gfc7e8c68369a, first fail: v4.4.243-19-g71b6c961c7fe) platform | arch | lab | compiler | defconfig | regressions --------------------+--------+-----------------+----------+---------------------+------------ qemu_arm-virt-gicv3 | arm | lab-cip | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/601190986ef6a6965fd3dfda Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/601190986ef6a6965fd3dfdb failing since 74 days (last pass: v4.4.243-18-gfc7e8c68369a, first fail: v4.4.243-19-g71b6c961c7fe) platform | arch | lab | compiler | defconfig | regressions --------------------+--------+-----------------+----------+---------------------+------------ qemu_arm-virt-gicv3 | arm | lab-collabora | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/601190a6aa39362810d3dfe6 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/601190a6aa39362810d3dfe7 failing since 74 days (last pass: v4.4.243-18-gfc7e8c68369a, first fail: v4.4.243-19-g71b6c961c7fe) platform | arch | lab | compiler | defconfig | regressions --------------------+--------+-----------------+----------+---------------------+------------ qemu_x86_64 | x86_64 | lab-baylibre | gcc-8 | x86_64_defconfig | 1 Details: https://kernelci.org/test/plan/id/60118f24ff1b323399d3dfe3 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig Compiler: gcc-8 (gcc (Debian 8.3.0-6) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.253-20-gefb3258395d4… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/60118f24ff1b323399d3dfe4 new failure (last pass: v4.4.253-20-g3a8011819531)

4 years, 6 months

1
0
0 0

[tip: efi/urgent] efi/apple-properties: Reinstate support for boolean properties

by tip-bot2 for Lukas Wunner

The following commit has been merged into the efi/urgent branch of tip: Commit-ID: 355845b738e76445c8522802552146d96cb4afa7 Gitweb: https://git.kernel.org/tip/355845b738e76445c8522802552146d96cb4afa7 Author: Lukas Wunner <lukas(a)wunner.de> AuthorDate: Thu, 31 Dec 2020 06:10:32 +01:00 Committer: Ard Biesheuvel <ardb(a)kernel.org> CommitterDate: Thu, 31 Dec 2020 10:28:53 +01:00 efi/apple-properties: Reinstate support for boolean properties Since commit 4466bf82821b ("efi/apple-properties: use PROPERTY_ENTRY_U8_ARRAY_LEN"), my MacBook Pro issues a -ENODATA error when trying to assign EFI properties to the discrete GPU: pci 0000:01:00.0: assigning 56 device properties pci 0000:01:00.0: error -61 assigning properties That's because some of the properties have no value. They're booleans whose presence can be checked by drivers, e.g. "use-backlight-blanking". Commit 6e98503dba64 ("efi/apple-properties: Remove redundant attribute initialization from unmarshal_key_value_pairs()") employed a trick to store such booleans as u8 arrays (which is the data type used for all other EFI properties on Macs): It cleared the property_entry's "is_array" flag, thereby denoting that the value is stored inline in the property_entry. Commit 4466bf82821b erroneously removed that trick. It was probably a little fragile to begin with. Reinstate support for boolean properties by explicitly invoking the PROPERTY_ENTRY_BOOL() initializer for properties with zero-length value. Fixes: 4466bf82821b ("efi/apple-properties: use PROPERTY_ENTRY_U8_ARRAY_LEN") Cc: <stable(a)vger.kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Lukas Wunner <lukas(a)wunner.de> Link: https://lore.kernel.org/r/be958bda75331a011d53c696d1deec8dccd06fd2.16093885… Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> --- drivers/firmware/efi/apple-properties.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/firmware/efi/apple-properties.c b/drivers/firmware/efi/apple-properties.c index 34f53d8..e192648 100644 --- a/drivers/firmware/efi/apple-properties.c +++ b/drivers/firmware/efi/apple-properties.c @@ -3,8 +3,9 @@ * apple-properties.c - EFI device properties on Macs * Copyright (C) 2016 Lukas Wunner <lukas(a)wunner.de> * - * Note, all properties are considered as u8 arrays. - * To get a value of any of them the caller must use device_property_read_u8_array(). + * Properties are stored either as: + * u8 arrays which can be retrieved with device_property_read_u8_array() or + * booleans which can be queried with device_property_present(). */ #define pr_fmt(fmt) "apple-properties: " fmt @@ -88,8 +89,12 @@ static void __init unmarshal_key_value_pairs(struct dev_header *dev_header, entry_data = ptr + key_len + sizeof(val_len); entry_len = val_len - sizeof(val_len); - entry[i] = PROPERTY_ENTRY_U8_ARRAY_LEN(key, entry_data, - entry_len); + if (entry_len) + entry[i] = PROPERTY_ENTRY_U8_ARRAY_LEN(key, entry_data, + entry_len); + else + entry[i] = PROPERTY_ENTRY_BOOL(key); + if (dump_properties) { dev_info(dev, "property: %s\n", key); print_hex_dump(KERN_INFO, pr_fmt(), DUMP_PREFIX_OFFSET,

4 years, 6 months

1
0
0 0

stable-rc/linux-5.4.y baseline: 170 runs, 5 regressions (v5.4.93)

by kernelci.org bot

stable-rc/linux-5.4.y baseline: 170 runs, 5 regressions (v5.4.93) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ---------------------+-------+---------------+----------+---------------------+------------ hifive-unleashed-a00 | riscv | lab-baylibre | gcc-8 | defconfig | 1 qemu_arm-versatilepb | arm | lab-baylibre | gcc-8 | versatile_defconfig | 1 qemu_arm-versatilepb | arm | lab-broonie | gcc-8 | versatile_defconfig | 1 qemu_arm-versatilepb | arm | lab-cip | gcc-8 | versatile_defconfig | 1 qemu_arm-versatilepb | arm | lab-collabora | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/linux-5.4.y/kernel/v5.4.93/p… Test: baseline Tree: stable-rc Branch: linux-5.4.y Describe: v5.4.93 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 131f8d8a889a5ca66a835eea82bba043ac91a7cf Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ---------------------+-------+---------------+----------+---------------------+------------ hifive-unleashed-a00 | riscv | lab-baylibre | gcc-8 | defconfig | 1 Details: https://kernelci.org/test/plan/id/601189c32412f12acad3dfdf Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-8 (riscv64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.93/riscv/defconfig… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.93/riscv/defconfig… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/601189c32412f12acad3dfe0 failing since 68 days (last pass: v5.4.77-152-ga3746663c3479, first fail: v5.4.78) platform | arch | lab | compiler | defconfig | regressions ---------------------+-------+---------------+----------+---------------------+------------ qemu_arm-versatilepb | arm | lab-baylibre | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/plan/id/601187002f54b8428bd3dff5 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: versatile_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.93/arm/versatile_d… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.93/arm/versatile_d… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/601187002f54b8428bd3dff6 failing since 73 days (last pass: v5.4.77-44-g28fe0e171c204, first fail: v5.4.77-46-ga3e34830d912) platform | arch | lab | compiler | defconfig | regressions ---------------------+-------+---------------+----------+---------------------+------------ qemu_arm-versatilepb | arm | lab-broonie | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/plan/id/60118721825a36dfa7d3dfdf Results: 0 PASS, 1 FAIL, 0 SKIP Full config: versatile_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.93/arm/versatile_d… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.93/arm/versatile_d… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/60118721825a36dfa7d3dfe0 failing since 73 days (last pass: v5.4.77-44-g28fe0e171c204, first fail: v5.4.77-46-ga3e34830d912) platform | arch | lab | compiler | defconfig | regressions ---------------------+-------+---------------+----------+---------------------+------------ qemu_arm-versatilepb | arm | lab-cip | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/plan/id/601187022f54b8428bd3dffe Results: 0 PASS, 1 FAIL, 0 SKIP Full config: versatile_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.93/arm/versatile_d… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.93/arm/versatile_d… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/601187022f54b8428bd3dfff failing since 73 days (last pass: v5.4.77-44-g28fe0e171c204, first fail: v5.4.77-46-ga3e34830d912) platform | arch | lab | compiler | defconfig | regressions ---------------------+-------+---------------+----------+---------------------+------------ qemu_arm-versatilepb | arm | lab-collabora | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/plan/id/601186a89a5dc57cead3e038 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: versatile_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.93/arm/versatile_d… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.93/arm/versatile_d… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/601186a89a5dc57cead3e039 failing since 73 days (last pass: v5.4.77-44-g28fe0e171c204, first fail: v5.4.77-46-ga3e34830d912)

4 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror