* Re: [PATCH v2 1/3] scsi: core: allow auto suspend override by low-level driver
From: Bart Van Assche @ 2019-09-12 13:43 UTC (permalink / raw)
To: Stanley Chu, linux-scsi, martin.petersen, avri.altman,
alim.akhtar, pedrom.sousa, sthumma, jejb
Cc: marc.w.gonzalez, andy.teng, chun-hung.wu, kuohong.wang, evgreen,
subhashj, linux-mediatek, peter.wang, vivek.gautam, matthias.bgg,
linux-arm-kernel, beanhuo
In-Reply-To: <1568270135-32442-2-git-send-email-stanley.chu@mediatek.com>
On 9/12/19 7:35 AM, Stanley Chu wrote:
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index 64c96c7828ee..461aafadd208 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -1300,7 +1300,8 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
> device_enable_async_suspend(&sdev->sdev_gendev);
> scsi_autopm_get_target(starget);
> pm_runtime_set_active(&sdev->sdev_gendev);
> - pm_runtime_forbid(&sdev->sdev_gendev);
> + if (sdev->rpm_autosuspend_delay < 0)
> + pm_runtime_forbid(&sdev->sdev_gendev);
> pm_runtime_enable(&sdev->sdev_gendev);
> scsi_autopm_put_target(starget);
So we have a single new struct member, rpm_autosuspend_delay, that
controls two different behaviors: (a) whether or not runtime suspend is
enabled at device creation time and (b) the power management autosuspend
delay. I don't like this. Should two separate variables be introduced
instead of using a single variable to control both behaviors?
> diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
> index 202f4d6a4342..133b282fae5a 100644
> --- a/include/scsi/scsi_device.h
> +++ b/include/scsi/scsi_device.h
> @@ -199,7 +199,7 @@ struct scsi_device {
> unsigned broken_fua:1; /* Don't set FUA bit */
> unsigned lun_in_cdb:1; /* Store LUN bits in CDB[1] */
> unsigned unmap_limit_for_ws:1; /* Use the UNMAP limit for WRITE SAME */
> -
> + int rpm_autosuspend_delay;
> atomic_t disk_events_disable_depth; /* disable depth for disk events */
>
> DECLARE_BITMAP(supported_events, SDEV_EVT_MAXBITS); /* supported events */
>
Since the default value for the autosuspend delay is the same for all
SCSI devices attached to a SCSI host is the same, please add a variable
with the same name in the SCSI host template and use that value as the
default value for SCSI devices. If the rpm_autosuspend_delay variable
only occurs in struct scsi_device then LLD authors are forced to
introduce a slave_configure function. Introducing such a function can be
avoided if the default autosuspend delay can be specified in the host
template.
Bart.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/3] scsi: ufs-mediatek: enable auto suspend capability
From: Bart Van Assche @ 2019-09-12 13:46 UTC (permalink / raw)
To: Stanley Chu, linux-scsi, martin.petersen, avri.altman,
alim.akhtar, pedrom.sousa, sthumma, jejb
Cc: marc.w.gonzalez, andy.teng, chun-hung.wu, kuohong.wang, evgreen,
subhashj, linux-mediatek, peter.wang, vivek.gautam, matthias.bgg,
linux-arm-kernel, beanhuo
In-Reply-To: <1568270135-32442-4-git-send-email-stanley.chu@mediatek.com>
On 9/12/19 7:35 AM, Stanley Chu wrote:
> Enable auto suspend capability in MediaTek UFS driver.
>
> Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
> Reviewed-by: Avri Altman <avri.altman@wdc.com>
> ---
> drivers/scsi/ufs/ufs-mediatek.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
> index 0f6ff33ce52e..b7b177c6194c 100644
> --- a/drivers/scsi/ufs/ufs-mediatek.c
> +++ b/drivers/scsi/ufs/ufs-mediatek.c
> @@ -117,6 +117,11 @@ static int ufs_mtk_setup_clocks(struct ufs_hba *hba, bool on,
> return ret;
> }
>
> +static void ufs_mtk_set_caps(struct ufs_hba *hba)
> +{
> + hba->caps |= UFSHCD_CAP_RPM_AUTOSUSPEND;
> +}
> +
> /**
> * ufs_mtk_init - find other essential mmio bases
> * @hba: host controller instance
> @@ -147,6 +152,8 @@ static int ufs_mtk_init(struct ufs_hba *hba)
> if (err)
> goto out_variant_clear;
>
> + ufs_mtk_set_caps(hba);
> +
> /*
> * ufshcd_vops_init() is invoked after
> * ufshcd_setup_clock(true) in ufshcd_hba_init() thus
Please inline the ufs_mtk_set_caps() function. Introducing single line
functions like is done in this patch doesn't improve readability.
Thanks,
Bart.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] pinctrl: at91-pio4: implement .get_multiple and .set_multiple
From: Linus Walleij @ 2019-09-12 13:46 UTC (permalink / raw)
To: Alexandre Belloni
Cc: open list:GPIO SUBSYSTEM, Ludovic Desroches, Linux ARM,
linux-kernel@vger.kernel.org
In-Reply-To: <20190911091101.GC21254@piout.net>
On Wed, Sep 11, 2019 at 10:11 AM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> On 11/09/2019 01:27:10+0100, Linus Walleij wrote:
> > > +#if ATMEL_PIO_NPINS_PER_BANK != BITS_PER_LONG
> >
> > Should it not be > rather than != ?
>
> Realistically, the only case that could happen would be
> ATMEL_PIO_NPINS_PER_BANK == 32 and BITS_PER_LONG ==64. so I would go for
> ATMEL_PIO_NPINS_PER_BANK < BITS_PER_LONG
OK I see.
> > > + word = BIT_WORD(bank * ATMEL_PIO_NPINS_PER_BANK);
> > > + offset = bank * ATMEL_PIO_NPINS_PER_BANK % BITS_PER_LONG;
> > > +#endif
> >
> > This doesn't look good for multiplatform kernels.
>
> I don't think we have multiplatform kernels that run both in 32 and 64
> bits. I don't believe ATMEL_PIO_NPINS_PER_BANK will ever change, it has
> been 32 on all the atmel SoCs since 2001.
So there is a bit missing from the commit message: the info that
the same driver is being used on 32 and 64 bit builds, and that is
the reason we allow compile-time ifdef things.
Can you add this to the commit message, or maybe
inline in the code, or both?
It confused me so it will confuse others.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] mm/kasan: dump alloc and free stack for page allocator
From: Vlastimil Babka @ 2019-09-12 13:53 UTC (permalink / raw)
To: Qian Cai, Walter Wu
Cc: wsd_upstream, Arnd Bergmann, linux-mm, Andrey Konovalov,
linux-mediatek, linux-kernel, kasan-dev, Martin Schwidefsky,
Alexander Potapenko, linux-arm-kernel, Matthias Brugger,
Andrey Ryabinin, Andrew Morton, Dmitry Vyukov
In-Reply-To: <5E358F4B-552C-4542-9655-E01C7B754F14@lca.pw>
On 9/11/19 5:19 PM, Qian Cai wrote:
>
> The new config looks redundant and confusing. It looks to me more of a document update
> in Documentation/dev-tools/kasan.txt to educate developers to select PAGE_OWNER and
> DEBUG_PAGEALLOC if needed.
Agreed. But if you want it fully automatic, how about something
like this (on top of mmotm/next)? If you agree I'll add changelog
and send properly.
----8<----
From a528d14c71d7fdf5872ca8ab3bd1b5bad26670c9 Mon Sep 17 00:00:00 2001
From: Vlastimil Babka <vbabka@suse.cz>
Date: Thu, 12 Sep 2019 15:51:23 +0200
Subject: [PATCH] make KASAN enable page_owner with free stack capture
---
include/linux/page_owner.h | 1 +
lib/Kconfig.kasan | 4 ++++
mm/Kconfig.debug | 5 +++++
mm/page_alloc.c | 6 +++++-
mm/page_owner.c | 37 ++++++++++++++++++++++++-------------
5 files changed, 39 insertions(+), 14 deletions(-)
diff --git a/include/linux/page_owner.h b/include/linux/page_owner.h
index 8679ccd722e8..6ffe8b81ba85 100644
--- a/include/linux/page_owner.h
+++ b/include/linux/page_owner.h
@@ -6,6 +6,7 @@
#ifdef CONFIG_PAGE_OWNER
extern struct static_key_false page_owner_inited;
+extern bool page_owner_free_stack_disabled;
extern struct page_ext_operations page_owner_ops;
extern void __reset_page_owner(struct page *page, unsigned int order);
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index 6c9682ce0254..dc560c7562e8 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -41,6 +41,8 @@ config KASAN_GENERIC
select SLUB_DEBUG if SLUB
select CONSTRUCTORS
select STACKDEPOT
+ select PAGE_OWNER
+ select PAGE_OWNER_FREE_STACK
help
Enables generic KASAN mode.
Supported in both GCC and Clang. With GCC it requires version 4.9.2
@@ -63,6 +65,8 @@ config KASAN_SW_TAGS
select SLUB_DEBUG if SLUB
select CONSTRUCTORS
select STACKDEPOT
+ select PAGE_OWNER
+ select PAGE_OWNER_FREE_STACK
help
Enables software tag-based KASAN mode.
This mode requires Top Byte Ignore support by the CPU and therefore
diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
index 327b3ebf23bf..a71d52636687 100644
--- a/mm/Kconfig.debug
+++ b/mm/Kconfig.debug
@@ -13,6 +13,7 @@ config DEBUG_PAGEALLOC
depends on DEBUG_KERNEL
depends on !HIBERNATION || ARCH_SUPPORTS_DEBUG_PAGEALLOC && !PPC && !SPARC
select PAGE_POISONING if !ARCH_SUPPORTS_DEBUG_PAGEALLOC
+ select PAGE_OWNER_FREE_STACK if PAGE_OWNER
---help---
Unmap pages from the kernel linear mapping after free_pages().
Depending on runtime enablement, this results in a small or large
@@ -62,6 +63,10 @@ config PAGE_OWNER
If unsure, say N.
+config PAGE_OWNER_FREE_STACK
+ def_bool n
+ depends on PAGE_OWNER
+
config PAGE_POISONING
bool "Poison pages after freeing"
select PAGE_POISONING_NO_SANITY if HIBERNATION
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c5d62f1c2851..d9e44671af3f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -710,8 +710,12 @@ static int __init early_debug_pagealloc(char *buf)
if (kstrtobool(buf, &enable))
return -EINVAL;
- if (enable)
+ if (enable) {
static_branch_enable(&_debug_pagealloc_enabled);
+#ifdef CONFIG_PAGE_OWNER
+ page_owner_free_stack_disabled = false;
+#endif
+ }
return 0;
}
diff --git a/mm/page_owner.c b/mm/page_owner.c
index dee931184788..d4551d7012d0 100644
--- a/mm/page_owner.c
+++ b/mm/page_owner.c
@@ -24,13 +24,15 @@ struct page_owner {
short last_migrate_reason;
gfp_t gfp_mask;
depot_stack_handle_t handle;
-#ifdef CONFIG_DEBUG_PAGEALLOC
+#ifdef CONFIG_PAGE_OWNER_FREE_STACK
depot_stack_handle_t free_handle;
#endif
};
static bool page_owner_disabled = true;
+bool page_owner_free_stack_disabled = true;
DEFINE_STATIC_KEY_FALSE(page_owner_inited);
+static DEFINE_STATIC_KEY_FALSE(page_owner_free_stack);
static depot_stack_handle_t dummy_handle;
static depot_stack_handle_t failure_handle;
@@ -46,6 +48,11 @@ static int __init early_page_owner_param(char *buf)
if (strcmp(buf, "on") == 0)
page_owner_disabled = false;
+ if (IS_ENABLED(CONFIG_KASAN)) {
+ page_owner_disabled = false;
+ page_owner_free_stack_disabled = false;
+ }
+
return 0;
}
early_param("page_owner", early_page_owner_param);
@@ -91,6 +98,8 @@ static void init_page_owner(void)
register_failure_stack();
register_early_stack();
static_branch_enable(&page_owner_inited);
+ if (!page_owner_free_stack_disabled)
+ static_branch_enable(&page_owner_free_stack);
init_early_allocated_pages();
}
@@ -148,11 +157,11 @@ void __reset_page_owner(struct page *page, unsigned int order)
{
int i;
struct page_ext *page_ext;
-#ifdef CONFIG_DEBUG_PAGEALLOC
+#ifdef CONFIG_PAGE_OWNER_FREE_STACK
depot_stack_handle_t handle = 0;
struct page_owner *page_owner;
- if (debug_pagealloc_enabled())
+ if (static_branch_unlikely(&page_owner_free_stack))
handle = save_stack(GFP_NOWAIT | __GFP_NOWARN);
#endif
@@ -161,8 +170,8 @@ void __reset_page_owner(struct page *page, unsigned int order)
if (unlikely(!page_ext))
continue;
__clear_bit(PAGE_EXT_OWNER_ACTIVE, &page_ext->flags);
-#ifdef CONFIG_DEBUG_PAGEALLOC
- if (debug_pagealloc_enabled()) {
+#ifdef CONFIG_PAGE_OWNER_FREE_STACK
+ if (static_branch_unlikely(&page_owner_free_stack)) {
page_owner = get_page_owner(page_ext);
page_owner->free_handle = handle;
}
@@ -451,14 +460,16 @@ void __dump_page_owner(struct page *page)
stack_trace_print(entries, nr_entries, 0);
}
-#ifdef CONFIG_DEBUG_PAGEALLOC
- handle = READ_ONCE(page_owner->free_handle);
- if (!handle) {
- pr_alert("page_owner free stack trace missing\n");
- } else {
- nr_entries = stack_depot_fetch(handle, &entries);
- pr_alert("page last free stack trace:\n");
- stack_trace_print(entries, nr_entries, 0);
+#ifdef CONFIG_PAGE_OWNER_FREE_STACK
+ if (static_branch_unlikely(&page_owner_free_stack)) {
+ handle = READ_ONCE(page_owner->free_handle);
+ if (!handle) {
+ pr_alert("page_owner free stack trace missing\n");
+ } else {
+ nr_entries = stack_depot_fetch(handle, &entries);
+ pr_alert("page last free stack trace:\n");
+ stack_trace_print(entries, nr_entries, 0);
+ }
}
#endif
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: KASAN: slab-out-of-bounds Read in handle_vmptrld
From: Vitaly Kuznetsov @ 2019-09-12 13:54 UTC (permalink / raw)
To: kvm
Cc: mark.rutland, x86, wanpengli, narmstrong, catalin.marinas,
will.deacon, hpa, khilman, joro, rkrcmar, mingo, syzbot,
devicetree, syzkaller-bugs, robh+dt, bp, linux-amlogic, tglx,
linux-arm-kernel, jmattson, linux-kernel, sean.j.christopherson,
carlo, pbonzini
In-Reply-To: <000000000000a9d4f705924cff7a@google.com>
syzbot <syzbot+46f1dd7dbbe2bfb98b10@syzkaller.appspotmail.com> writes:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 1e3778cb Merge tag 'scsi-fixes' of git://git.kernel.org/pu..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15bdfc5e600000
> kernel config: https://syzkaller.appspot.com/x/.config?x=b89bb446a3faaba4
> dashboard link: https://syzkaller.appspot.com/bug?extid=46f1dd7dbbe2bfb98b10
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1709421a600000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=168fc4b2600000
>
> The bug was bisected to:
>
> commit a87f854ddcf7ff7e044d72db0aa6da82f26d69a6
> Author: Neil Armstrong <narmstrong@baylibre.com>
> Date: Wed Oct 11 15:39:40 2017 +0000
>
> ARM64: dts: meson-gx: remove unnecessary uart compatible
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17e78a6e600000
> final crash: https://syzkaller.appspot.com/x/report.txt?x=14178a6e600000
> console output: https://syzkaller.appspot.com/x/log.txt?x=10178a6e600000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+46f1dd7dbbe2bfb98b10@syzkaller.appspotmail.com
> Fixes: a87f854ddcf7 ("ARM64: dts: meson-gx: remove unnecessary uart
> compatible")
>
> L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and
> https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for
> details.
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in handle_vmptrld
> arch/x86/kvm/vmx/nested.c:4789 [inline]
> BUG: KASAN: slab-out-of-bounds in handle_vmptrld+0x777/0x800
> arch/x86/kvm/vmx/nested.c:4749
> Read of size 4 at addr ffff888091e10000 by task syz-executor758/10006
>
> CPU: 1 PID: 10006 Comm: syz-executor758 Not tainted 5.3.0-rc7+ #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> print_address_description.cold+0xd4/0x306 mm/kasan/report.c:351
> __kasan_report.cold+0x1b/0x36 mm/kasan/report.c:482
> kasan_report+0x12/0x17 mm/kasan/common.c:618
> __asan_report_load_n_noabort+0xf/0x20 mm/kasan/generic_report.c:142
> handle_vmptrld arch/x86/kvm/vmx/nested.c:4789 [inline]
> handle_vmptrld+0x777/0x800 arch/x86/kvm/vmx/nested.c:4749
> vmx_handle_exit+0x299/0x15e0 arch/x86/kvm/vmx/vmx.c:5886
> vcpu_enter_guest+0x1087/0x5e90 arch/x86/kvm/x86.c:8088
> vcpu_run arch/x86/kvm/x86.c:8152 [inline]
> kvm_arch_vcpu_ioctl_run+0x464/0x1750 arch/x86/kvm/x86.c:8360
> kvm_vcpu_ioctl+0x4dc/0xfd0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2765
> vfs_ioctl fs/ioctl.c:46 [inline]
> file_ioctl fs/ioctl.c:509 [inline]
> do_vfs_ioctl+0xdb6/0x13e0 fs/ioctl.c:696
> ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
> __do_sys_ioctl fs/ioctl.c:720 [inline]
> __se_sys_ioctl fs/ioctl.c:718 [inline]
> __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
> do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
Hm, the bisection seems bogus but the stack points us to the following
piece of code:
4776) if (kvm_vcpu_map(vcpu, gpa_to_gfn(vmptr), &map)) {
<skip>
4783) return nested_vmx_failValid(vcpu,
4784) VMXERR_VMPTRLD_INCORRECT_VMCS_REVISION_ID);
4785) }
4786)
4787) new_vmcs12 = map.hva;
4788)
*4789) if (new_vmcs12->hdr.revision_id != VMCS12_REVISION ||
4790) (new_vmcs12->hdr.shadow_vmcs &&
4791) !nested_cpu_has_vmx_shadow_vmcs(vcpu))) {
the reported problem seems to be on VMCS12 region access but it's part
of guest memory and we successfuly managed to map it. We're definitely
within 1-page range. Maybe KASAN is just wrong here?
--
Vitaly
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 1/3] coresight: etm4x: save/restore state across CPU low power states
From: Suzuki K Poulose @ 2019-09-12 14:03 UTC (permalink / raw)
To: andrew.murray, mathieu.poirier, alexander.shishkin
Cc: Al.Grant, coresight, leo.yan, sudeep.holla, linux-arm-kernel,
mike.leach
In-Reply-To: <20190816154615.39854-2-andrew.murray@arm.com>
Hi Andrew,
On 08/16/2019 04:46 PM, Andrew Murray wrote:
> Some hardware will ignore bit TRCPDCR.PU which is used to signal
> to hardware that power should not be removed from the trace unit.
> Let's mitigate against this by conditionally saving and restoring
> the trace unit state when the CPU enters low power states.
>
> This patchset introduces a firmware property named
> 'arm,coresight-loses-context-with-cpu' - when this is present the
> hardware state will be conditionally saved and restored.
>
> A module parameter 'pm_save_enable' is also introduced which can
> be configured to override the firmware property. This can be set
> to never allow save/restore or to conditionally allow it (only for
> self-hosted). The default value is determined by firmware.
>
> We avoid saving the hardware state when self-hosted coresight isn't
> in use to reduce PM latency - we can't determine this by reading the
> claim tags (TRCCLAIMCLR) as these are 'trace' registers which need
> power and clocking, something we can't easily provide in the PM
> context. Therefore we rely on the existing drvdata->mode internal
> state that is set when self-hosted coresight is used (and powered).
The patch looks good to me. Some very minor comments below.
>
> Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-etm4x.c | 318 ++++++++++++++++++
> drivers/hwtracing/coresight/coresight-etm4x.h | 64 ++++
> drivers/hwtracing/coresight/coresight.c | 6 +
> include/linux/coresight.h | 6 +
> 4 files changed, 394 insertions(+)
>
> +static void etm4_cpu_restore(struct etmv4_drvdata *drvdata)
> +{
> + int i;
> + struct etmv4_save_state *state = drvdata->save_state;
> +
> + CS_UNLOCK(drvdata->base);
> +
> + writel_relaxed(state->trcclaimset, drvdata->base + TRCCLAIMSET);
> +
> + writel_relaxed(state->trcprgctlr, drvdata->base + TRCPRGCTLR);
> + writel_relaxed(state->trcprocselr, drvdata->base + TRCPROCSELR);
> + writel_relaxed(state->trcconfigr, drvdata->base + TRCCONFIGR);
> + writel_relaxed(state->trcauxctlr, drvdata->base + TRCAUXCTLR);
> + writel_relaxed(state->trceventctl0r, drvdata->base + TRCEVENTCTL0R);
> + writel_relaxed(state->trceventctl1r, drvdata->base + TRCEVENTCTL1R);
> + writel_relaxed(state->trcstallctlr, drvdata->base + TRCSTALLCTLR);
> + writel_relaxed(state->trctsctlr, drvdata->base + TRCTSCTLR);
> + writel_relaxed(state->trcsyncpr, drvdata->base + TRCSYNCPR);
> + writel_relaxed(state->trcccctlr, drvdata->base + TRCCCCTLR);
> + writel_relaxed(state->trcbbctlr, drvdata->base + TRCBBCTLR);
> + writel_relaxed(state->trctraceidr, drvdata->base + TRCTRACEIDR);
> + writel_relaxed(state->trcqctlr, drvdata->base + TRCQCTLR);
> +
> + writel_relaxed(state->trcvictlr, drvdata->base + TRCVICTLR);
> + writel_relaxed(state->trcviiectlr, drvdata->base + TRCVIIECTLR);
> + writel_relaxed(state->trcvissctlr, drvdata->base + TRCVISSCTLR);
> + writel_relaxed(state->trcvipcssctlr, drvdata->base + TRCVIPCSSCTLR);
> + writel_relaxed(state->trcvdctlr, drvdata->base + TRCVDCTLR);
> + writel_relaxed(state->trcvdsacctlr, drvdata->base + TRCVDSACCTLR);
> + writel_relaxed(state->trcvdarcctlr, drvdata->base + TRCVDARCCTLR);
> +
> + for (i = 0; i < drvdata->nrseqstate; i++)
> + writel_relaxed(state->trcseqevr[i],
> + drvdata->base + TRCSEQEVRn(i));
minor nit: alignment issues here and below for the multi-line
write_relaxed() invocations.
...
> +static int etm4_cpu_pm_notify(struct notifier_block *nb, unsigned long cmd,
> + void *v)
> +{
> + struct etmv4_drvdata *drvdata;
> + unsigned int cpu = smp_processor_id();
> +
> + if (!etmdrvdata[cpu])
> + return 0;
Please could we be consistent with the return value. i.e, use something
in line with NOTIFY_*. NOTIFY_OK ?
With the above fixed:
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 2/3] dt-bindings: arm: coresight: Add support for coresight-loses-context-with-cpu
From: Suzuki K Poulose @ 2019-09-12 14:06 UTC (permalink / raw)
To: andrew.murray, mathieu.poirier, alexander.shishkin
Cc: Al.Grant, coresight, leo.yan, sudeep.holla, linux-arm-kernel,
mike.leach
In-Reply-To: <20190816154615.39854-3-andrew.murray@arm.com>
On 08/16/2019 04:46 PM, Andrew Murray wrote:
> Some coresight components, because of choices made during hardware
> integration, require their state to be saved and restored across CPU low
> power states.
>
> The software has no reliable method of detecting when save/restore is
> required thus let's add a binding to inform the kernel.
>
> Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> ---
> Documentation/devicetree/bindings/arm/coresight.txt | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
> index fcc3bacfd8bc..d02c42d21f2f 100644
> --- a/Documentation/devicetree/bindings/arm/coresight.txt
> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
> @@ -87,6 +87,15 @@ its hardware characteristcs.
>
> * port or ports: see "Graph bindings for Coresight" below.
>
> +* Optional properties for all components:
> +
> + * arm,coresight-loses-context-with-cpu : boolean. Indicates that the
> + hardware will lose register context on CPU power down (e.g. CPUIdle).
> + An example of where this may be needed are systems which contain a
> + coresight component and CPU in the same power domain. When the CPU
> + powers down the coresight component also powers down and loses its
> + context. This property is currently only used for the ETM 4.x driver.
> +
> * Optional properties for ETM/PTMs:
>
> * arm,cp14: must be present if the system accesses ETM/PTM management
>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file
From: Will Deacon @ 2019-09-12 14:02 UTC (permalink / raw)
To: Guo Ren
Cc: julien.thierry, Catalin Marinas, Palmer Dabbelt, Will Deacon,
christoffer.dall, Atish Patra, Julien Grall, gary, linux-riscv,
kvmarm, Mike Rapoport, Christoph Hellwig, aou, Arnd Bergmann,
suzuki.poulose, Marc Zyngier, Paul Walmsley, linux-arm-kernel,
Anup Patel, Linux Kernel Mailing List, iommu, james.morse
In-Reply-To: <CAJF2gTSC1sGgmiTCgzKUTdPyUZ3LG4H7N8YbMyWr-E+eifGuYg@mail.gmail.com>
On Sun, Sep 08, 2019 at 07:52:55AM +0800, Guo Ren wrote:
> On Mon, Jun 24, 2019 at 6:40 PM Will Deacon <will@kernel.org> wrote:
> > > I'll keep my system use the same ASID for SMP + IOMMU :P
> >
> > You will want a separate allocator for that:
> >
> > https://lkml.kernel.org/r/20190610184714.6786-2-jean-philippe.brucker@arm.com
>
> Yes, it is hard to maintain ASID between IOMMU and CPUMMU or different
> system, because it's difficult to synchronize the IO_ASID when the CPU
> ASID is rollover.
> But we could still use hardware broadcast TLB invalidation instruction
> to uniformly manage the ASID and IO_ASID, or OTHER_ASID in our IOMMU.
That's probably a bad idea, because you'll likely stall execution on the
CPU until the IOTLB has completed invalidation. In the case of ATS, I think
an endpoint ATC is permitted to take over a minute to respond. In reality, I
suspect the worst you'll ever see would be in the msec range, but that's
still an unacceptable period of time to hold a CPU.
> Welcome to join our disscusion:
> "Introduce an implementation of IOMMU in linux-riscv"
> 9 Sep 2019, 10:45 Jade-room-I&II (Corinthia Hotel Lisbon) RISC-V MC
I attended this session, but it unfortunately raised many more questions
than it answered.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] mm/kasan: dump alloc and free stack for page allocator
From: Walter Wu @ 2019-09-12 14:08 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Qian Cai, wsd_upstream, Arnd Bergmann, linux-mm, Andrey Konovalov,
linux-mediatek, linux-kernel, kasan-dev, Martin Schwidefsky,
Alexander Potapenko, linux-arm-kernel, Matthias Brugger,
Andrey Ryabinin, Andrew Morton, Dmitry Vyukov
In-Reply-To: <c4d2518f-4813-c941-6f47-73897f420517@suse.cz>
> extern void __reset_page_owner(struct page *page, unsigned int order);
> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> index 6c9682ce0254..dc560c7562e8 100644
> --- a/lib/Kconfig.kasan
> +++ b/lib/Kconfig.kasan
> @@ -41,6 +41,8 @@ config KASAN_GENERIC
> select SLUB_DEBUG if SLUB
> select CONSTRUCTORS
> select STACKDEPOT
> + select PAGE_OWNER
> + select PAGE_OWNER_FREE_STACK
> help
> Enables generic KASAN mode.
> Supported in both GCC and Clang. With GCC it requires version 4.9.2
> @@ -63,6 +65,8 @@ config KASAN_SW_TAGS
> select SLUB_DEBUG if SLUB
> select CONSTRUCTORS
> select STACKDEPOT
> + select PAGE_OWNER
> + select PAGE_OWNER_FREE_STACK
> help
What is the difference between PAGE_OWNER+PAGE_OWNER_FREE_STACK and
DEBUG_PAGEALLOC?
If you directly enable PAGE_OWNER+PAGE_OWNER_FREE_STACK
PAGE_OWNER_FREE_STACK,don't you think low-memory device to want to use
KASAN?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] mm/kasan: dump alloc and free stack for page allocator
From: Andrey Ryabinin @ 2019-09-12 14:08 UTC (permalink / raw)
To: Vlastimil Babka, Qian Cai, Walter Wu
Cc: wsd_upstream, Arnd Bergmann, linux-mm, Andrey Konovalov,
linux-kernel, kasan-dev, Martin Schwidefsky, Alexander Potapenko,
linux-arm-kernel, Matthias Brugger, linux-mediatek, Andrew Morton,
Dmitry Vyukov
In-Reply-To: <c4d2518f-4813-c941-6f47-73897f420517@suse.cz>
On 9/12/19 4:53 PM, Vlastimil Babka wrote:
> On 9/11/19 5:19 PM, Qian Cai wrote:
>>
>> The new config looks redundant and confusing. It looks to me more of a document update
>> in Documentation/dev-tools/kasan.txt to educate developers to select PAGE_OWNER and
>> DEBUG_PAGEALLOC if needed.
>
> Agreed. But if you want it fully automatic, how about something
> like this (on top of mmotm/next)? If you agree I'll add changelog
> and send properly.
>
> ----8<----
>
> From a528d14c71d7fdf5872ca8ab3bd1b5bad26670c9 Mon Sep 17 00:00:00 2001
> From: Vlastimil Babka <vbabka@suse.cz>
> Date: Thu, 12 Sep 2019 15:51:23 +0200
> Subject: [PATCH] make KASAN enable page_owner with free stack capture
>
> ---
> include/linux/page_owner.h | 1 +
> lib/Kconfig.kasan | 4 ++++
> mm/Kconfig.debug | 5 +++++
> mm/page_alloc.c | 6 +++++-
> mm/page_owner.c | 37 ++++++++++++++++++++++++-------------
> 5 files changed, 39 insertions(+), 14 deletions(-)
>
Looks ok to me. This certainly better than full dependency on the DEBUG_PAGEALLOC which we don't need.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] mm/kasan: dump alloc and free stack for page allocator
From: Qian Cai @ 2019-09-12 14:10 UTC (permalink / raw)
To: Vlastimil Babka, Walter Wu
Cc: wsd_upstream, Arnd Bergmann, linux-mm, Andrey Konovalov,
linux-mediatek, linux-kernel, kasan-dev, Martin Schwidefsky,
Alexander Potapenko, linux-arm-kernel, Matthias Brugger,
Andrey Ryabinin, Andrew Morton, Dmitry Vyukov
In-Reply-To: <c4d2518f-4813-c941-6f47-73897f420517@suse.cz>
On Thu, 2019-09-12 at 15:53 +0200, Vlastimil Babka wrote:
> On 9/11/19 5:19 PM, Qian Cai wrote:
> >
> > The new config looks redundant and confusing. It looks to me more of a document update
> > in Documentation/dev-tools/kasan.txt to educate developers to select PAGE_OWNER and
> > DEBUG_PAGEALLOC if needed.
>
>
> Agreed. But if you want it fully automatic, how about something
> like this (on top of mmotm/next)? If you agree I'll add changelog
> and send properly.
>
> ----8<----
>
> From a528d14c71d7fdf5872ca8ab3bd1b5bad26670c9 Mon Sep 17 00:00:00 2001
> From: Vlastimil Babka <vbabka@suse.cz>
> Date: Thu, 12 Sep 2019 15:51:23 +0200
> Subject: [PATCH] make KASAN enable page_owner with free stack capture
>
> ---
> include/linux/page_owner.h | 1 +
> lib/Kconfig.kasan | 4 ++++
> mm/Kconfig.debug | 5 +++++
> mm/page_alloc.c | 6 +++++-
> mm/page_owner.c | 37 ++++++++++++++++++++++++-------------
> 5 files changed, 39 insertions(+), 14 deletions(-)
>
> diff --git a/include/linux/page_owner.h b/include/linux/page_owner.h
> index 8679ccd722e8..6ffe8b81ba85 100644
> --- a/include/linux/page_owner.h
> +++ b/include/linux/page_owner.h
> @@ -6,6 +6,7 @@
>
> #ifdef CONFIG_PAGE_OWNER
> extern struct static_key_false page_owner_inited;
> +extern bool page_owner_free_stack_disabled;
> extern struct page_ext_operations page_owner_ops;
>
> extern void __reset_page_owner(struct page *page, unsigned int order);
> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> index 6c9682ce0254..dc560c7562e8 100644
> --- a/lib/Kconfig.kasan
> +++ b/lib/Kconfig.kasan
> @@ -41,6 +41,8 @@ config KASAN_GENERIC
> select SLUB_DEBUG if SLUB
> select CONSTRUCTORS
> select STACKDEPOT
> + select PAGE_OWNER
> + select PAGE_OWNER_FREE_STACK
> help
> Enables generic KASAN mode.
> Supported in both GCC and Clang. With GCC it requires version 4.9.2
> @@ -63,6 +65,8 @@ config KASAN_SW_TAGS
> select SLUB_DEBUG if SLUB
> select CONSTRUCTORS
> select STACKDEPOT
> + select PAGE_OWNER
> + select PAGE_OWNER_FREE_STACK
> help
> Enables software tag-based KASAN mode.
> This mode requires Top Byte Ignore support by the CPU and therefore
I don't know how KASAN people will feel about this. Especially, KASAN_SW_TAGS
was designed for people who complain about memory footprint of KASAN_GENERIC is
too high as far as I can tell.
I guess it depends on them to test the new memory footprint of KASAN to see if
they are happy with it.
> diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
> index 327b3ebf23bf..a71d52636687 100644
> --- a/mm/Kconfig.debug
> +++ b/mm/Kconfig.debug
> @@ -13,6 +13,7 @@ config DEBUG_PAGEALLOC
> depends on DEBUG_KERNEL
> depends on !HIBERNATION || ARCH_SUPPORTS_DEBUG_PAGEALLOC && !PPC && !SPARC
> select PAGE_POISONING if !ARCH_SUPPORTS_DEBUG_PAGEALLOC
> + select PAGE_OWNER_FREE_STACK if PAGE_OWNER
> ---help---
> Unmap pages from the kernel linear mapping after free_pages().
> Depending on runtime enablement, this results in a small or large
> @@ -62,6 +63,10 @@ config PAGE_OWNER
>
> If unsure, say N.
>
> +config PAGE_OWNER_FREE_STACK
> + def_bool n
> + depends on PAGE_OWNER
> +
> config PAGE_POISONING
> bool "Poison pages after freeing"
> select PAGE_POISONING_NO_SANITY if HIBERNATION
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index c5d62f1c2851..d9e44671af3f 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -710,8 +710,12 @@ static int __init early_debug_pagealloc(char *buf)
> if (kstrtobool(buf, &enable))
> return -EINVAL;
>
> - if (enable)
> + if (enable) {
> static_branch_enable(&_debug_pagealloc_enabled);
> +#ifdef CONFIG_PAGE_OWNER
> + page_owner_free_stack_disabled = false;
> +#endif
> + }
>
> return 0;
> }
> diff --git a/mm/page_owner.c b/mm/page_owner.c
> index dee931184788..d4551d7012d0 100644
> --- a/mm/page_owner.c
> +++ b/mm/page_owner.c
> @@ -24,13 +24,15 @@ struct page_owner {
> short last_migrate_reason;
> gfp_t gfp_mask;
> depot_stack_handle_t handle;
> -#ifdef CONFIG_DEBUG_PAGEALLOC
> +#ifdef CONFIG_PAGE_OWNER_FREE_STACK
> depot_stack_handle_t free_handle;
> #endif
> };
>
> static bool page_owner_disabled = true;
> +bool page_owner_free_stack_disabled = true;
> DEFINE_STATIC_KEY_FALSE(page_owner_inited);
> +static DEFINE_STATIC_KEY_FALSE(page_owner_free_stack);
>
> static depot_stack_handle_t dummy_handle;
> static depot_stack_handle_t failure_handle;
> @@ -46,6 +48,11 @@ static int __init early_page_owner_param(char *buf)
> if (strcmp(buf, "on") == 0)
> page_owner_disabled = false;
>
> + if (IS_ENABLED(CONFIG_KASAN)) {
> + page_owner_disabled = false;
> + page_owner_free_stack_disabled = false;
> + }
> +
> return 0;
> }
> early_param("page_owner", early_page_owner_param);
> @@ -91,6 +98,8 @@ static void init_page_owner(void)
> register_failure_stack();
> register_early_stack();
> static_branch_enable(&page_owner_inited);
> + if (!page_owner_free_stack_disabled)
> + static_branch_enable(&page_owner_free_stack);
> init_early_allocated_pages();
> }
>
> @@ -148,11 +157,11 @@ void __reset_page_owner(struct page *page, unsigned int order)
> {
> int i;
> struct page_ext *page_ext;
> -#ifdef CONFIG_DEBUG_PAGEALLOC
> +#ifdef CONFIG_PAGE_OWNER_FREE_STACK
> depot_stack_handle_t handle = 0;
> struct page_owner *page_owner;
>
> - if (debug_pagealloc_enabled())
> + if (static_branch_unlikely(&page_owner_free_stack))
> handle = save_stack(GFP_NOWAIT | __GFP_NOWARN);
> #endif
>
> @@ -161,8 +170,8 @@ void __reset_page_owner(struct page *page, unsigned int order)
> if (unlikely(!page_ext))
> continue;
> __clear_bit(PAGE_EXT_OWNER_ACTIVE, &page_ext->flags);
> -#ifdef CONFIG_DEBUG_PAGEALLOC
> - if (debug_pagealloc_enabled()) {
> +#ifdef CONFIG_PAGE_OWNER_FREE_STACK
> + if (static_branch_unlikely(&page_owner_free_stack)) {
> page_owner = get_page_owner(page_ext);
> page_owner->free_handle = handle;
> }
> @@ -451,14 +460,16 @@ void __dump_page_owner(struct page *page)
> stack_trace_print(entries, nr_entries, 0);
> }
>
> -#ifdef CONFIG_DEBUG_PAGEALLOC
> - handle = READ_ONCE(page_owner->free_handle);
> - if (!handle) {
> - pr_alert("page_owner free stack trace missing\n");
> - } else {
> - nr_entries = stack_depot_fetch(handle, &entries);
> - pr_alert("page last free stack trace:\n");
> - stack_trace_print(entries, nr_entries, 0);
> +#ifdef CONFIG_PAGE_OWNER_FREE_STACK
> + if (static_branch_unlikely(&page_owner_free_stack)) {
> + handle = READ_ONCE(page_owner->free_handle);
> + if (!handle) {
> + pr_alert("page_owner free stack trace missing\n");
> + } else {
> + nr_entries = stack_depot_fetch(handle, &entries);
> + pr_alert("page last free stack trace:\n");
> + stack_trace_print(entries, nr_entries, 0);
> + }
> }
> #endif
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
From: Robin Gong @ 2019-09-12 14:19 UTC (permalink / raw)
To: Jurgen Lambrecht, Leonard Crestez, Fabio Estevam
Cc: Aisheng Dong, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
u.kleine-koenig@pengutronix.de
In-Reply-To: <5274ab9f-999a-9d11-35fa-43b57187607b@televic.com>
> -----Original Message-----
On 2019/9/12 20:12 Jurgen Lambrecht <J.Lambrecht@TELEVIC.com> wrote:
>
> On 9/12/19 11:45 AM, Jurgen Lambrecht wrote:
> > CAUTION: This Email originated from outside Televic. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> >
> >
> > On 9/12/19 4:06 AM, Robin Gong wrote:
> >>> (this looked the most interesting commit)
> >> I identified this issue which caused by
> >> SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3 (41)exceed the structure
> >> sdma_script_start_addrs(40) so that illegal memory touch, such as
> >> slob block header, thus kernel trap into while() loop forever in slob_free().
> Please see the below code piece in sdma_add_scripts().
> >> for (i = 0; i < sdma->script_number; i++)
> >> if (addr_arr[i] > 0)
> >> saddr_arr[i] = addr_arr[i]; That issue was
> >> brought by commit a572460be9cf (dmaengine: imx-sdma:
> >> Add support for version 3 firmware) because the
> >> SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3
> >> (38->41 3 scripts added) not align with script number added in
> >> sdma_script_start_addrs(2 scripts). Please have a try with the below
> >> patch:
> >> diff --git a/include/linux/platform_data/dma-imx-sdma.h
> >> b/include/linux/platform_data/dma-imx-sdma.h
> >> index 6eaa53c..30e676b 100644
> >> --- a/include/linux/platform_data/dma-imx-sdma.h
> >> +++ b/include/linux/platform_data/dma-imx-sdma.h
> >> @@ -51,7 +51,10 @@ struct sdma_script_start_addrs {
> >> /* End of v2 array */
> >> s32 zcanfd_2_mcu_addr;
> >> s32 zqspi_2_mcu_addr;
> >> + s32 mcu_2_ecspi_addr;
> >> /* End of v3 array */
> >> + s32 mcu_2_zqspi_addr;
> >> + /* End of v4 array */
> >> };
> >>
> > Yes, this patch solves it! I can now use SLOB slab allocator. I tried
> > several reboots and power cycles.
> > I tried with different dts (without earlycon, without sdma on uart and
> > ecspi).
> > I did not try other kernels, only 4.19.66+fscl with our patches and
> > sdma
> > v3.5 built-in.
> I tried again v5.3 rc6 with SLOB, but it still booted OK, then took latest v5.3 rc8
> from mainline, and it also boots OK - tried several times also with power cycle.
>
> Then I added your patch, and it "still" boots :-). So OK:
>
> Linux imx6ul-33927318 5.3.0-rc8-dirty #3 PREEMPT Thu Sep 12 13:54:25 CEST
> 2019 armv7l GNU/Linux
Thanks for your test on v5.3. Yes, that potential memory corrupt only happen
on one word, most time it may hid well during kernel bootup, and it's so luck
for us that your 'SLOB + firmware built in' case could expose it :).Thanks for
your report, I'll post a formal patch for review later.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] mm/kasan: dump alloc and free stack for page allocator
From: Vlastimil Babka @ 2019-09-12 14:31 UTC (permalink / raw)
To: Walter Wu
Cc: Qian Cai, wsd_upstream, Arnd Bergmann, linux-mm, Andrey Konovalov,
linux-mediatek, linux-kernel, kasan-dev, Martin Schwidefsky,
Alexander Potapenko, linux-arm-kernel, Matthias Brugger,
Andrey Ryabinin, Andrew Morton, Dmitry Vyukov
In-Reply-To: <1568297308.19040.5.camel@mtksdccf07>
On 9/12/19 4:08 PM, Walter Wu wrote:
>
>> extern void __reset_page_owner(struct page *page, unsigned int order);
>> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
>> index 6c9682ce0254..dc560c7562e8 100644
>> --- a/lib/Kconfig.kasan
>> +++ b/lib/Kconfig.kasan
>> @@ -41,6 +41,8 @@ config KASAN_GENERIC
>> select SLUB_DEBUG if SLUB
>> select CONSTRUCTORS
>> select STACKDEPOT
>> + select PAGE_OWNER
>> + select PAGE_OWNER_FREE_STACK
>> help
>> Enables generic KASAN mode.
>> Supported in both GCC and Clang. With GCC it requires version 4.9.2
>> @@ -63,6 +65,8 @@ config KASAN_SW_TAGS
>> select SLUB_DEBUG if SLUB
>> select CONSTRUCTORS
>> select STACKDEPOT
>> + select PAGE_OWNER
>> + select PAGE_OWNER_FREE_STACK
>> help
>
> What is the difference between PAGE_OWNER+PAGE_OWNER_FREE_STACK and
> DEBUG_PAGEALLOC?
Same memory usage, but debug_pagealloc means also extra checks and
restricting memory access to freed pages to catch UAF.
> If you directly enable PAGE_OWNER+PAGE_OWNER_FREE_STACK
> PAGE_OWNER_FREE_STACK,don't you think low-memory device to want to use
> KASAN?
OK, so it should be optional? But I think it's enough to distinguish no
PAGE_OWNER at all, and PAGE_OWNER+PAGE_OWNER_FREE_STACK together - I
don't see much point in PAGE_OWNER only for this kind of debugging.
So how about this? KASAN wouldn't select PAGE_OWNER* but it would be
recommended in the help+docs. When PAGE_OWNER and KASAN are selected by
user, PAGE_OWNER_FREE_STACK gets also selected, and both will be also
runtime enabled without explicit page_owner=on.
I mostly want to avoid another boot-time option for enabling
PAGE_OWNER_FREE_STACK.
Would that be enough flexibility for low-memory devices vs full-fledged
debugging?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
From: Russell King - ARM Linux admin @ 2019-09-12 14:40 UTC (permalink / raw)
To: Robin Gong
Cc: Aisheng Dong, Jurgen Lambrecht, dl-linux-imx,
u.kleine-koenig@pengutronix.de, Leonard Crestez, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <VE1PR04MB663817327D9A585F0C4A158589B00@VE1PR04MB6638.eurprd04.prod.outlook.com>
On Thu, Sep 12, 2019 at 02:19:51PM +0000, Robin Gong wrote:
> > -----Original Message-----
> On 2019/9/12 20:12 Jurgen Lambrecht <J.Lambrecht@TELEVIC.com> wrote:
> >
> > On 9/12/19 11:45 AM, Jurgen Lambrecht wrote:
> > > CAUTION: This Email originated from outside Televic. Do not click links or
> > open attachments unless you recognize the sender and know the content is
> > safe.
> > >
> > >
> > > On 9/12/19 4:06 AM, Robin Gong wrote:
> > >>> (this looked the most interesting commit)
> > >> I identified this issue which caused by
> > >> SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3 (41)exceed the structure
> > >> sdma_script_start_addrs(40) so that illegal memory touch, such as
> > >> slob block header, thus kernel trap into while() loop forever in slob_free().
> > Please see the below code piece in sdma_add_scripts().
> > >> for (i = 0; i < sdma->script_number; i++)
> > >> if (addr_arr[i] > 0)
> > >> saddr_arr[i] = addr_arr[i]; That issue was
> > >> brought by commit a572460be9cf (dmaengine: imx-sdma:
> > >> Add support for version 3 firmware) because the
> > >> SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3
> > >> (38->41 3 scripts added) not align with script number added in
> > >> sdma_script_start_addrs(2 scripts). Please have a try with the below
> > >> patch:
> > >> diff --git a/include/linux/platform_data/dma-imx-sdma.h
> > >> b/include/linux/platform_data/dma-imx-sdma.h
> > >> index 6eaa53c..30e676b 100644
> > >> --- a/include/linux/platform_data/dma-imx-sdma.h
> > >> +++ b/include/linux/platform_data/dma-imx-sdma.h
> > >> @@ -51,7 +51,10 @@ struct sdma_script_start_addrs {
> > >> /* End of v2 array */
> > >> s32 zcanfd_2_mcu_addr;
> > >> s32 zqspi_2_mcu_addr;
> > >> + s32 mcu_2_ecspi_addr;
> > >> /* End of v3 array */
> > >> + s32 mcu_2_zqspi_addr;
> > >> + /* End of v4 array */
> > >> };
> > >>
> > > Yes, this patch solves it! I can now use SLOB slab allocator. I tried
> > > several reboots and power cycles.
> > > I tried with different dts (without earlycon, without sdma on uart and
> > > ecspi).
> > > I did not try other kernels, only 4.19.66+fscl with our patches and
> > > sdma
> > > v3.5 built-in.
> > I tried again v5.3 rc6 with SLOB, but it still booted OK, then took latest v5.3 rc8
> > from mainline, and it also boots OK - tried several times also with power cycle.
> >
> > Then I added your patch, and it "still" boots :-). So OK:
> >
> > Linux imx6ul-33927318 5.3.0-rc8-dirty #3 PREEMPT Thu Sep 12 13:54:25 CEST
> > 2019 armv7l GNU/Linux
> Thanks for your test on v5.3. Yes, that potential memory corrupt only happen
> on one word, most time it may hid well during kernel bootup, and it's so luck
> for us that your 'SLOB + firmware built in' case could expose it :).Thanks for
> your report, I'll post a formal patch for review later.
It sounds like this code is very fragile, and it seems like this mistake
could easily happen again in the future.
How about ensuring that sdma->script_number * sizeof(u32) <
sizeof(struct sdma_script_start_addrs), since sdma_add_scripts() has
no protection against overrunning the structure size.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 0/2] mm/debug: Add tests for architecture exported page table helpers
From: Christophe Leroy @ 2019-09-12 14:42 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Heiko Carstens, Michal Hocko, Dave Hansen, Paul Mackerras,
sparclinux, Thomas Gleixner, linux-s390, Jason Gunthorpe,
Michael Ellerman, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Tetsuo Handa, Gerald Schaefer, linux-snps-arc,
Kees Cook, Masahiro Yamada, Mark Brown, Kirill A . Shutemov,
Dan Williams, Vlastimil Babka, linux-arm-kernel,
Sri Krishna chowdary, Ard Biesheuvel, Greg Kroah-Hartman,
linux-mips, Ralf Baechle, linux-kernel, Paul Burton,
Mike Rapoport, Vineet Gupta, Martin Schwidefsky, Andrew Morton,
linuxppc-dev, David S. Miller, Mike Kravetz
In-Reply-To: <1568268173-31302-1-git-send-email-anshuman.khandual@arm.com>
Hi,
I didn't get patch 1 of this series, and it is not on linuxppc-dev
patchwork either. Can you resend ?
Thanks
Christophe
Le 12/09/2019 à 08:02, Anshuman Khandual a écrit :
> This series adds a test validation for architecture exported page table
> helpers. Patch in the series adds basic transformation tests at various
> levels of the page table. Before that it exports gigantic page allocation
> function from HugeTLB.
>
> This test was originally suggested by Catalin during arm64 THP migration
> RFC discussion earlier. Going forward it can include more specific tests
> with respect to various generic MM functions like THP, HugeTLB etc and
> platform specific tests.
>
> https://lore.kernel.org/linux-mm/20190628102003.GA56463@arrakis.emea.arm.com/
>
> Testing:
>
> Successfully build and boot tested on both arm64 and x86 platforms without
> any test failing. Only build tested on some other platforms.
>
> But I would really appreciate if folks can help validate this test on other
> platforms and report back problems. All suggestions, comments and inputs
> welcome. Thank you.
>
> Changes in V2:
>
> - Fixed small typo error in MODULE_DESCRIPTION()
> - Fixed m64k build problems for lvalue concerns in pmd_xxx_tests()
> - Fixed dynamic page table level folding problems on x86 as per Kirril
> - Fixed second pointers during pxx_populate_tests() per Kirill and Gerald
> - Allocate and free pte table with pte_alloc_one/pte_free per Kirill
> - Modified pxx_clear_tests() to accommodate s390 lower 12 bits situation
> - Changed RANDOM_NZVALUE value from 0xbe to 0xff
> - Changed allocation, usage, free sequence for saved_ptep
> - Renamed VMA_FLAGS as VMFLAGS
> - Implemented a new method for random vaddr generation
> - Implemented some other cleanups
> - Dropped extern reference to mm_alloc()
> - Created and exported new alloc_gigantic_page_order()
> - Dropped the custom allocator and used new alloc_gigantic_page_order()
>
> Changes in V1:
>
> https://lore.kernel.org/linux-mm/1567497706-8649-1-git-send-email-anshuman.khandual@arm.com/
>
> - Added fallback mechanism for PMD aligned memory allocation failure
>
> Changes in RFC V2:
>
> https://lore.kernel.org/linux-mm/1565335998-22553-1-git-send-email-anshuman.khandual@arm.com/T/#u
>
> - Moved test module and it's config from lib/ to mm/
> - Renamed config TEST_ARCH_PGTABLE as DEBUG_ARCH_PGTABLE_TEST
> - Renamed file from test_arch_pgtable.c to arch_pgtable_test.c
> - Added relevant MODULE_DESCRIPTION() and MODULE_AUTHOR() details
> - Dropped loadable module config option
> - Basic tests now use memory blocks with required size and alignment
> - PUD aligned memory block gets allocated with alloc_contig_range()
> - If PUD aligned memory could not be allocated it falls back on PMD aligned
> memory block from page allocator and pud_* tests are skipped
> - Clear and populate tests now operate on real in memory page table entries
> - Dummy mm_struct gets allocated with mm_alloc()
> - Dummy page table entries get allocated with [pud|pmd|pte]_alloc_[map]()
> - Simplified [p4d|pgd]_basic_tests(), now has random values in the entries
>
> Original RFC V1:
>
> https://lore.kernel.org/linux-mm/1564037723-26676-1-git-send-email-anshuman.khandual@arm.com/
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Steven Price <Steven.Price@arm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Sri Krishna chowdary <schowdary@nvidia.com>
> Cc: Dave Hansen <dave.hansen@intel.com>
> Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Vineet Gupta <vgupta@synopsys.com>
> Cc: James Hogan <jhogan@kernel.org>
> Cc: Paul Burton <paul.burton@mips.com>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Kirill A. Shutemov <kirill@shutemov.name>
> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: Mike Kravetz <mike.kravetz@oracle.com>
> Cc: linux-snps-arc@lists.infradead.org
> Cc: linux-mips@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-ia64@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-s390@vger.kernel.org
> Cc: linux-sh@vger.kernel.org
> Cc: sparclinux@vger.kernel.org
> Cc: x86@kernel.org
> Cc: linux-kernel@vger.kernel.org
>
> Anshuman Khandual (2):
> mm/hugetlb: Make alloc_gigantic_page() available for general use
> mm/pgtable/debug: Add test validating architecture page table helpers
>
> arch/x86/include/asm/pgtable_64_types.h | 2 +
> include/linux/hugetlb.h | 9 +
> mm/Kconfig.debug | 14 +
> mm/Makefile | 1 +
> mm/arch_pgtable_test.c | 429 ++++++++++++++++++++++++
> mm/hugetlb.c | 24 +-
> 6 files changed, 477 insertions(+), 2 deletions(-)
> create mode 100644 mm/arch_pgtable_test.c
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
From: Robin Gong @ 2019-09-12 14:47 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Aisheng Dong, Jurgen Lambrecht, dl-linux-imx,
u.kleine-koenig@pengutronix.de, Leonard Crestez, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190912144023.GZ13294@shell.armlinux.org.uk>
On 2019/9/12 22:40 Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> On Thu, Sep 12, 2019 at 02:19:51PM +0000, Robin Gong wrote:
> > > -----Original Message-----
> > On 2019/9/12 20:12 Jurgen Lambrecht <J.Lambrecht@TELEVIC.com> wrote:
> > >
> > > On 9/12/19 11:45 AM, Jurgen Lambrecht wrote:
> > > > CAUTION: This Email originated from outside Televic. Do not click
> > > > links or
> > > open attachments unless you recognize the sender and know the
> > > content is safe.
> > > >
> > > >
> > > > On 9/12/19 4:06 AM, Robin Gong wrote:
> > > >>> (this looked the most interesting commit)
> > > >> I identified this issue which caused by
> > > >> SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3 (41)exceed the structure
> > > >> sdma_script_start_addrs(40) so that illegal memory touch, such as
> > > >> slob block header, thus kernel trap into while() loop forever in
> slob_free().
> > > Please see the below code piece in sdma_add_scripts().
> > > >> for (i = 0; i < sdma->script_number; i++)
> > > >> if (addr_arr[i] > 0)
> > > >> saddr_arr[i] = addr_arr[i]; That issue
> > > >> was brought by commit a572460be9cf (dmaengine: imx-sdma:
> > > >> Add support for version 3 firmware) because the
> > > >> SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3
> > > >> (38->41 3 scripts added) not align with script number added in
> > > >> sdma_script_start_addrs(2 scripts). Please have a try with the
> > > >> below
> > > >> patch:
> > > >> diff --git a/include/linux/platform_data/dma-imx-sdma.h
> > > >> b/include/linux/platform_data/dma-imx-sdma.h
> > > >> index 6eaa53c..30e676b 100644
> > > >> --- a/include/linux/platform_data/dma-imx-sdma.h
> > > >> +++ b/include/linux/platform_data/dma-imx-sdma.h
> > > >> @@ -51,7 +51,10 @@ struct sdma_script_start_addrs {
> > > >> /* End of v2 array */
> > > >> s32 zcanfd_2_mcu_addr;
> > > >> s32 zqspi_2_mcu_addr;
> > > >> + s32 mcu_2_ecspi_addr;
> > > >> /* End of v3 array */
> > > >> + s32 mcu_2_zqspi_addr;
> > > >> + /* End of v4 array */
> > > >> };
> > > >>
> > > > Yes, this patch solves it! I can now use SLOB slab allocator. I
> > > > tried several reboots and power cycles.
> > > > I tried with different dts (without earlycon, without sdma on uart
> > > > and ecspi).
> > > > I did not try other kernels, only 4.19.66+fscl with our patches
> > > > and sdma
> > > > v3.5 built-in.
> > > I tried again v5.3 rc6 with SLOB, but it still booted OK, then took
> > > latest v5.3 rc8 from mainline, and it also boots OK - tried several times also
> with power cycle.
> > >
> > > Then I added your patch, and it "still" boots :-). So OK:
> > >
> > > Linux imx6ul-33927318 5.3.0-rc8-dirty #3 PREEMPT Thu Sep 12 13:54:25
> > > CEST
> > > 2019 armv7l GNU/Linux
> > Thanks for your test on v5.3. Yes, that potential memory corrupt only
> > happen on one word, most time it may hid well during kernel bootup,
> > and it's so luck for us that your 'SLOB + firmware built in' case
> > could expose it :).Thanks for your report, I'll post a formal patch for review
> later.
>
> It sounds like this code is very fragile, and it seems like this mistake could
> easily happen again in the future.
>
> How about ensuring that sdma->script_number * sizeof(u32) < sizeof(struct
> sdma_script_start_addrs), since sdma_add_scripts() has no protection against
> overrunning the structure size.
Yes, that's what my thought: add conditional checking, and warning log triggered
if sdma->script_number * sizeof(u32) > sizeof(struct sdma_script_start_addrs).
>
> --
> RMK's Patch system:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> armlinux.org.uk%2Fdeveloper%2Fpatches%2F&data=02%7C01%7Cyibin.
> gong%40nxp.com%7C45c63241e494447ce5b508d7378f28d5%7C686ea1d3bc
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C637038960316627129&sdata=d
> QRdAxrau8EL2X7etr9MlKxNccoe70jM2dsMeUM3%2BbY%3D&reserved=
> 0
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps
> up According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file
From: Guo Ren @ 2019-09-12 14:59 UTC (permalink / raw)
To: Will Deacon
Cc: julien.thierry, Catalin Marinas, Palmer Dabbelt, Will Deacon,
christoffer.dall, Atish Patra, Julien Grall, gary, linux-riscv,
kvmarm, Mike Rapoport, Christoph Hellwig, aou, Arnd Bergmann,
suzuki.poulose, Marc Zyngier, Paul Walmsley, linux-arm-kernel,
Anup Patel, Linux Kernel Mailing List, iommu, james.morse
In-Reply-To: <20190912140256.fwbutgmadpjbjnab@willie-the-truck>
Thx Will for reply.
On Thu, Sep 12, 2019 at 3:03 PM Will Deacon <will@kernel.org> wrote:
>
> On Sun, Sep 08, 2019 at 07:52:55AM +0800, Guo Ren wrote:
> > On Mon, Jun 24, 2019 at 6:40 PM Will Deacon <will@kernel.org> wrote:
> > > > I'll keep my system use the same ASID for SMP + IOMMU :P
> > >
> > > You will want a separate allocator for that:
> > >
> > > https://lkml.kernel.org/r/20190610184714.6786-2-jean-philippe.brucker@arm.com
> >
> > Yes, it is hard to maintain ASID between IOMMU and CPUMMU or different
> > system, because it's difficult to synchronize the IO_ASID when the CPU
> > ASID is rollover.
> > But we could still use hardware broadcast TLB invalidation instruction
> > to uniformly manage the ASID and IO_ASID, or OTHER_ASID in our IOMMU.
>
> That's probably a bad idea, because you'll likely stall execution on the
> CPU until the IOTLB has completed invalidation. In the case of ATS, I think
> an endpoint ATC is permitted to take over a minute to respond. In reality, I
> suspect the worst you'll ever see would be in the msec range, but that's
> still an unacceptable period of time to hold a CPU.
Just as I've said in the session that IOTLB invalidate delay is
another topic, My main proposal is to introduce stage1.pgd and
stage2.pgd as address space identifiers between different TLB systems
based on vmid, asid. My last part of sildes will show you how to
translate stage1/2.pgd to as/vmid in PCI ATS system and the method
could work with SMMU-v3 and intel Vt-d. (It's regret for me there is
no time to show you the whole slides.)
In our light IOMMU implementation, there's no IOTLB invalidate delay
problem. Becasue IOMMU is very close to CPU MMU and interconnect's
delay is the same with SMP CPUs MMU (no PCI, VM supported).
To solve the problem, we could define a async mode in sfence.vma.b to
slove the problem and finished with per_cpu_irq/exception.
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers
From: Christophe Leroy @ 2019-09-12 15:00 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Heiko Carstens, Michal Hocko, Dave Hansen, Paul Mackerras,
sparclinux, Thomas Gleixner, linux-s390, Jason Gunthorpe,
Michael Ellerman, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Tetsuo Handa, Gerald Schaefer, linux-snps-arc,
Kees Cook, Masahiro Yamada, Mark Brown, Kirill A . Shutemov,
Dan Williams, Vlastimil Babka, linux-arm-kernel,
Sri Krishna chowdary, Ard Biesheuvel, Greg Kroah-Hartman,
linux-mips, Ralf Baechle, linux-kernel, Paul Burton,
Mike Rapoport, Vineet Gupta, Martin Schwidefsky, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <1568268173-31302-3-git-send-email-anshuman.khandual@arm.com>
On 09/12/2019 06:02 AM, Anshuman Khandual wrote:
> This adds a test module which will validate architecture page table helpers
> and accessors regarding compliance with generic MM semantics expectations.
> This will help various architectures in validating changes to the existing
> page table helpers or addition of new ones.
>
> Test page table and memory pages creating it's entries at various level are
> all allocated from system memory with required alignments. If memory pages
> with required size and alignment could not be allocated, then all depending
> individual tests are skipped.
Build failure on powerpc book3s/32. This is because asm/highmem.h is
missing. It can't be included from asm/book3s/32/pgtable.h because it
creates circular dependency. So it has to be included from
mm/arch_pgtable_test.c
CC mm/arch_pgtable_test.o
In file included from ./arch/powerpc/include/asm/book3s/pgtable.h:8:0,
from ./arch/powerpc/include/asm/pgtable.h:18,
from ./include/linux/mm.h:99,
from ./arch/powerpc/include/asm/io.h:29,
from ./include/linux/io.h:13,
from ./include/linux/irq.h:20,
from ./arch/powerpc/include/asm/hardirq.h:6,
from ./include/linux/hardirq.h:9,
from ./include/linux/interrupt.h:11,
from ./include/linux/kernel_stat.h:9,
from ./include/linux/cgroup.h:26,
from ./include/linux/hugetlb.h:9,
from mm/arch_pgtable_test.c:14:
mm/arch_pgtable_test.c: In function 'arch_pgtable_tests_init':
./arch/powerpc/include/asm/book3s/32/pgtable.h:365:13: error: implicit
declaration of function 'kmap_atomic'
[-Werror=implicit-function-declaration]
((pte_t *)(kmap_atomic(pmd_page(*(dir))) + \
^
./include/linux/mm.h:2008:31: note: in expansion of macro 'pte_offset_map'
(pte_alloc(mm, pmd) ? NULL : pte_offset_map(pmd, address))
^
mm/arch_pgtable_test.c:377:9: note: in expansion of macro 'pte_alloc_map'
ptep = pte_alloc_map(mm, pmdp, vaddr);
^
cc1: some warnings being treated as errors
make[2]: *** [mm/arch_pgtable_test.o] Error 1
Christophe
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Steven Price <Steven.Price@arm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Sri Krishna chowdary <schowdary@nvidia.com>
> Cc: Dave Hansen <dave.hansen@intel.com>
> Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Vineet Gupta <vgupta@synopsys.com>
> Cc: James Hogan <jhogan@kernel.org>
> Cc: Paul Burton <paul.burton@mips.com>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Kirill A. Shutemov <kirill@shutemov.name>
> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: linux-snps-arc@lists.infradead.org
> Cc: linux-mips@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-ia64@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-s390@vger.kernel.org
> Cc: linux-sh@vger.kernel.org
> Cc: sparclinux@vger.kernel.org
> Cc: x86@kernel.org
> Cc: linux-kernel@vger.kernel.org
>
> Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> arch/x86/include/asm/pgtable_64_types.h | 2 +
> mm/Kconfig.debug | 14 +
> mm/Makefile | 1 +
> mm/arch_pgtable_test.c | 429 ++++++++++++++++++++++++
> 4 files changed, 446 insertions(+)
> create mode 100644 mm/arch_pgtable_test.c
>
> diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h
> index 52e5f5f2240d..b882792a3999 100644
> --- a/arch/x86/include/asm/pgtable_64_types.h
> +++ b/arch/x86/include/asm/pgtable_64_types.h
> @@ -40,6 +40,8 @@ static inline bool pgtable_l5_enabled(void)
> #define pgtable_l5_enabled() 0
> #endif /* CONFIG_X86_5LEVEL */
>
> +#define mm_p4d_folded(mm) (!pgtable_l5_enabled())
> +
> extern unsigned int pgdir_shift;
> extern unsigned int ptrs_per_p4d;
>
> diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
> index 327b3ebf23bf..ce9c397f7b07 100644
> --- a/mm/Kconfig.debug
> +++ b/mm/Kconfig.debug
> @@ -117,3 +117,17 @@ config DEBUG_RODATA_TEST
> depends on STRICT_KERNEL_RWX
> ---help---
> This option enables a testcase for the setting rodata read-only.
> +
> +config DEBUG_ARCH_PGTABLE_TEST
> + bool "Test arch page table helpers for semantics compliance"
> + depends on MMU
> + depends on DEBUG_KERNEL
> + help
> + This options provides a kernel module which can be used to test
> + architecture page table helper functions on various platform in
> + verifying if they comply with expected generic MM semantics. This
> + will help architectures code in making sure that any changes or
> + new additions of these helpers will still conform to generic MM
> + expected semantics.
> +
> + If unsure, say N.
> diff --git a/mm/Makefile b/mm/Makefile
> index d996846697ef..bb572c5aa8c5 100644
> --- a/mm/Makefile
> +++ b/mm/Makefile
> @@ -86,6 +86,7 @@ obj-$(CONFIG_HWPOISON_INJECT) += hwpoison-inject.o
> obj-$(CONFIG_DEBUG_KMEMLEAK) += kmemleak.o
> obj-$(CONFIG_DEBUG_KMEMLEAK_TEST) += kmemleak-test.o
> obj-$(CONFIG_DEBUG_RODATA_TEST) += rodata_test.o
> +obj-$(CONFIG_DEBUG_ARCH_PGTABLE_TEST) += arch_pgtable_test.o
> obj-$(CONFIG_PAGE_OWNER) += page_owner.o
> obj-$(CONFIG_CLEANCACHE) += cleancache.o
> obj-$(CONFIG_MEMORY_ISOLATION) += page_isolation.o
> diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c
> new file mode 100644
> index 000000000000..8b4a92756ad8
> --- /dev/null
> +++ b/mm/arch_pgtable_test.c
> @@ -0,0 +1,429 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * This kernel module validates architecture page table helpers &
> + * accessors and helps in verifying their continued compliance with
> + * generic MM semantics.
> + *
> + * Copyright (C) 2019 ARM Ltd.
> + *
> + * Author: Anshuman Khandual <anshuman.khandual@arm.com>
> + */
> +#define pr_fmt(fmt) "arch_pgtable_test: %s " fmt, __func__
> +
> +#include <linux/gfp.h>
> +#include <linux/hugetlb.h>
> +#include <linux/kernel.h>
> +#include <linux/mm.h>
> +#include <linux/mman.h>
> +#include <linux/mm_types.h>
> +#include <linux/module.h>
> +#include <linux/pfn_t.h>
> +#include <linux/printk.h>
> +#include <linux/random.h>
> +#include <linux/spinlock.h>
> +#include <linux/swap.h>
> +#include <linux/swapops.h>
> +#include <linux/sched/mm.h>
> +#include <asm/pgalloc.h>
> +#include <asm/pgtable.h>
> +
> +/*
> + * Basic operations
> + *
> + * mkold(entry) = An old and not a young entry
> + * mkyoung(entry) = A young and not an old entry
> + * mkdirty(entry) = A dirty and not a clean entry
> + * mkclean(entry) = A clean and not a dirty entry
> + * mkwrite(entry) = A write and not a write protected entry
> + * wrprotect(entry) = A write protected and not a write entry
> + * pxx_bad(entry) = A mapped and non-table entry
> + * pxx_same(entry1, entry2) = Both entries hold the exact same value
> + */
> +#define VMFLAGS (VM_READ|VM_WRITE|VM_EXEC)
> +
> +/*
> + * On s390 platform, the lower 12 bits are used to identify given page table
> + * entry type and for other arch specific requirements. But these bits might
> + * affect the ability to clear entries with pxx_clear(). So while loading up
> + * the entries skip all lower 12 bits in order to accommodate s390 platform.
> + * It does not have affect any other platform.
> + */
> +#define RANDOM_ORVALUE (0xfffffffffffff000UL)
> +#define RANDOM_NZVALUE (0xff)
> +
> +static bool pud_aligned;
> +static bool pmd_aligned;
> +
> +static void pte_basic_tests(struct page *page, pgprot_t prot)
> +{
> + pte_t pte = mk_pte(page, prot);
> +
> + WARN_ON(!pte_same(pte, pte));
> + WARN_ON(!pte_young(pte_mkyoung(pte)));
> + WARN_ON(!pte_dirty(pte_mkdirty(pte)));
> + WARN_ON(!pte_write(pte_mkwrite(pte)));
> + WARN_ON(pte_young(pte_mkold(pte)));
> + WARN_ON(pte_dirty(pte_mkclean(pte)));
> + WARN_ON(pte_write(pte_wrprotect(pte)));
> +}
> +
> +#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE
> +static void pmd_basic_tests(struct page *page, pgprot_t prot)
> +{
> + pmd_t pmd;
> +
> + /*
> + * Memory block here must be PMD_SIZE aligned. Abort this
> + * test in case we could not allocate such a memory block.
> + */
> + if (!pmd_aligned) {
> + pr_warn("Could not proceed with PMD tests\n");
> + return;
> + }
> +
> + pmd = mk_pmd(page, prot);
> + WARN_ON(!pmd_same(pmd, pmd));
> + WARN_ON(!pmd_young(pmd_mkyoung(pmd)));
> + WARN_ON(!pmd_dirty(pmd_mkdirty(pmd)));
> + WARN_ON(!pmd_write(pmd_mkwrite(pmd)));
> + WARN_ON(pmd_young(pmd_mkold(pmd)));
> + WARN_ON(pmd_dirty(pmd_mkclean(pmd)));
> + WARN_ON(pmd_write(pmd_wrprotect(pmd)));
> + /*
> + * A huge page does not point to next level page table
> + * entry. Hence this must qualify as pmd_bad().
> + */
> + WARN_ON(!pmd_bad(pmd_mkhuge(pmd)));
> +}
> +#else
> +static void pmd_basic_tests(struct page *page, pgprot_t prot) { }
> +#endif
> +
> +#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
> +static void pud_basic_tests(struct page *page, pgprot_t prot)
> +{
> + pud_t pud;
> +
> + /*
> + * Memory block here must be PUD_SIZE aligned. Abort this
> + * test in case we could not allocate such a memory block.
> + */
> + if (!pud_aligned) {
> + pr_warn("Could not proceed with PUD tests\n");
> + return;
> + }
> +
> + pud = pfn_pud(page_to_pfn(page), prot);
> + WARN_ON(!pud_same(pud, pud));
> + WARN_ON(!pud_young(pud_mkyoung(pud)));
> + WARN_ON(!pud_write(pud_mkwrite(pud)));
> + WARN_ON(pud_write(pud_wrprotect(pud)));
> + WARN_ON(pud_young(pud_mkold(pud)));
> +
> +#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
> + /*
> + * A huge page does not point to next level page table
> + * entry. Hence this must qualify as pud_bad().
> + */
> + WARN_ON(!pud_bad(pud_mkhuge(pud)));
> +#endif
> +}
> +#else
> +static void pud_basic_tests(struct page *page, pgprot_t prot) { }
> +#endif
> +
> +static void p4d_basic_tests(struct page *page, pgprot_t prot)
> +{
> + p4d_t p4d;
> +
> + memset(&p4d, RANDOM_NZVALUE, sizeof(p4d_t));
> + WARN_ON(!p4d_same(p4d, p4d));
> +}
> +
> +static void pgd_basic_tests(struct page *page, pgprot_t prot)
> +{
> + pgd_t pgd;
> +
> + memset(&pgd, RANDOM_NZVALUE, sizeof(pgd_t));
> + WARN_ON(!pgd_same(pgd, pgd));
> +}
> +
> +#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
> +static void pud_clear_tests(pud_t *pudp)
> +{
> + pud_t pud = READ_ONCE(*pudp);
> +
> + pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
> + WRITE_ONCE(*pudp, pud);
> + pud_clear(pudp);
> + pud = READ_ONCE(*pudp);
> + WARN_ON(!pud_none(pud));
> +}
> +
> +static void pud_populate_tests(struct mm_struct *mm, pud_t *pudp, pmd_t *pmdp)
> +{
> + pud_t pud;
> +
> + /*
> + * This entry points to next level page table page.
> + * Hence this must not qualify as pud_bad().
> + */
> + pmd_clear(pmdp);
> + pud_clear(pudp);
> + pud_populate(mm, pudp, pmdp);
> + pud = READ_ONCE(*pudp);
> + WARN_ON(pud_bad(pud));
> +}
> +#else
> +static void pud_clear_tests(pud_t *pudp) { }
> +static void pud_populate_tests(struct mm_struct *mm, pud_t *pudp, pmd_t *pmdp)
> +{
> +}
> +#endif
> +
> +#if !defined(__PAGETABLE_PUD_FOLDED) && !defined(__ARCH_HAS_5LEVEL_HACK)
> +static void p4d_clear_tests(p4d_t *p4dp)
> +{
> + p4d_t p4d = READ_ONCE(*p4dp);
> +
> + p4d = __p4d(p4d_val(p4d) | RANDOM_ORVALUE);
> + WRITE_ONCE(*p4dp, p4d);
> + p4d_clear(p4dp);
> + p4d = READ_ONCE(*p4dp);
> + WARN_ON(!p4d_none(p4d));
> +}
> +
> +static void p4d_populate_tests(struct mm_struct *mm, p4d_t *p4dp, pud_t *pudp)
> +{
> + p4d_t p4d;
> +
> + /*
> + * This entry points to next level page table page.
> + * Hence this must not qualify as p4d_bad().
> + */
> + pud_clear(pudp);
> + p4d_clear(p4dp);
> + p4d_populate(mm, p4dp, pudp);
> + p4d = READ_ONCE(*p4dp);
> + WARN_ON(p4d_bad(p4d));
> +}
> +#else
> +static void p4d_clear_tests(p4d_t *p4dp) { }
> +static void p4d_populate_tests(struct mm_struct *mm, p4d_t *p4dp, pud_t *pudp)
> +{
> +}
> +#endif
> +
> +#ifndef __ARCH_HAS_5LEVEL_HACK
> +static void pgd_clear_tests(struct mm_struct *mm, pgd_t *pgdp)
> +{
> + pgd_t pgd = READ_ONCE(*pgdp);
> +
> + if (mm_p4d_folded(mm))
> + return;
> +
> + pgd = __pgd(pgd_val(pgd) | RANDOM_ORVALUE);
> + WRITE_ONCE(*pgdp, pgd);
> + pgd_clear(pgdp);
> + pgd = READ_ONCE(*pgdp);
> + WARN_ON(!pgd_none(pgd));
> +}
> +
> +static void pgd_populate_tests(struct mm_struct *mm, pgd_t *pgdp, p4d_t *p4dp)
> +{
> + pgd_t pgd;
> +
> + if (mm_p4d_folded(mm))
> + return;
> +
> + /*
> + * This entry points to next level page table page.
> + * Hence this must not qualify as pgd_bad().
> + */
> + p4d_clear(p4dp);
> + pgd_clear(pgdp);
> + pgd_populate(mm, pgdp, p4dp);
> + pgd = READ_ONCE(*pgdp);
> + WARN_ON(pgd_bad(pgd));
> +}
> +#else
> +static void pgd_clear_tests(struct mm_struct *mm, pgd_t *pgdp) { }
> +static void pgd_populate_tests(struct mm_struct *mm, pgd_t *pgdp, p4d_t *p4dp)
> +{
> +}
> +#endif
> +
> +static void pte_clear_tests(struct mm_struct *mm, pte_t *ptep)
> +{
> + pte_t pte = READ_ONCE(*ptep);
> +
> + pte = __pte(pte_val(pte) | RANDOM_ORVALUE);
> + WRITE_ONCE(*ptep, pte);
> + pte_clear(mm, 0, ptep);
> + pte = READ_ONCE(*ptep);
> + WARN_ON(!pte_none(pte));
> +}
> +
> +static void pmd_clear_tests(pmd_t *pmdp)
> +{
> + pmd_t pmd = READ_ONCE(*pmdp);
> +
> + pmd = __pmd(pmd_val(pmd) | RANDOM_ORVALUE);
> + WRITE_ONCE(*pmdp, pmd);
> + pmd_clear(pmdp);
> + pmd = READ_ONCE(*pmdp);
> + WARN_ON(!pmd_none(pmd));
> +}
> +
> +static void pmd_populate_tests(struct mm_struct *mm, pmd_t *pmdp,
> + pgtable_t pgtable)
> +{
> + pmd_t pmd;
> +
> + /*
> + * This entry points to next level page table page.
> + * Hence this must not qualify as pmd_bad().
> + */
> + pmd_clear(pmdp);
> + pmd_populate(mm, pmdp, pgtable);
> + pmd = READ_ONCE(*pmdp);
> + WARN_ON(pmd_bad(pmd));
> +}
> +
> +static struct page *alloc_mapped_page(void)
> +{
> + struct page *page;
> + gfp_t gfp_mask = GFP_KERNEL | __GFP_ZERO;
> +
> + page = alloc_gigantic_page_order(get_order(PUD_SIZE), gfp_mask,
> + first_memory_node, &node_states[N_MEMORY]);
> + if (page) {
> + pud_aligned = true;
> + pmd_aligned = true;
> + return page;
> + }
> +
> + page = alloc_pages(gfp_mask, get_order(PMD_SIZE));
> + if (page) {
> + pmd_aligned = true;
> + return page;
> + }
> + return alloc_page(gfp_mask);
> +}
> +
> +static void free_mapped_page(struct page *page)
> +{
> + if (pud_aligned) {
> + unsigned long pfn = page_to_pfn(page);
> +
> + free_contig_range(pfn, 1ULL << get_order(PUD_SIZE));
> + return;
> + }
> +
> + if (pmd_aligned) {
> + int order = get_order(PMD_SIZE);
> +
> + free_pages((unsigned long)page_address(page), order);
> + return;
> + }
> + free_page((unsigned long)page_address(page));
> +}
> +
> +static unsigned long get_random_vaddr(void)
> +{
> + unsigned long random_vaddr, random_pages, total_user_pages;
> +
> + total_user_pages = (TASK_SIZE - FIRST_USER_ADDRESS) / PAGE_SIZE;
> +
> + random_pages = get_random_long() % total_user_pages;
> + random_vaddr = FIRST_USER_ADDRESS + random_pages * PAGE_SIZE;
> +
> + WARN_ON(random_vaddr > TASK_SIZE);
> + WARN_ON(random_vaddr < FIRST_USER_ADDRESS);
> + return random_vaddr;
> +}
> +
> +static int __init arch_pgtable_tests_init(void)
> +{
> + struct mm_struct *mm;
> + struct page *page;
> + pgd_t *pgdp;
> + p4d_t *p4dp, *saved_p4dp;
> + pud_t *pudp, *saved_pudp;
> + pmd_t *pmdp, *saved_pmdp, pmd;
> + pte_t *ptep;
> + pgtable_t saved_ptep;
> + pgprot_t prot;
> + unsigned long vaddr;
> +
> + prot = vm_get_page_prot(VMFLAGS);
> + vaddr = get_random_vaddr();
> + mm = mm_alloc();
> + if (!mm) {
> + pr_err("mm_struct allocation failed\n");
> + return 1;
> + }
> +
> + page = alloc_mapped_page();
> + if (!page) {
> + pr_err("memory allocation failed\n");
> + return 1;
> + }
> +
> + pgdp = pgd_offset(mm, vaddr);
> + p4dp = p4d_alloc(mm, pgdp, vaddr);
> + pudp = pud_alloc(mm, p4dp, vaddr);
> + pmdp = pmd_alloc(mm, pudp, vaddr);
> + ptep = pte_alloc_map(mm, pmdp, vaddr);
> +
> + /*
> + * Save all the page table page addresses as the page table
> + * entries will be used for testing with random or garbage
> + * values. These saved addresses will be used for freeing
> + * page table pages.
> + */
> + pmd = READ_ONCE(*pmdp);
> + saved_p4dp = p4d_offset(pgdp, 0UL);
> + saved_pudp = pud_offset(p4dp, 0UL);
> + saved_pmdp = pmd_offset(pudp, 0UL);
> + saved_ptep = pmd_pgtable(pmd);
> +
> + pte_basic_tests(page, prot);
> + pmd_basic_tests(page, prot);
> + pud_basic_tests(page, prot);
> + p4d_basic_tests(page, prot);
> + pgd_basic_tests(page, prot);
> +
> + pte_clear_tests(mm, ptep);
> + pmd_clear_tests(pmdp);
> + pud_clear_tests(pudp);
> + p4d_clear_tests(p4dp);
> + pgd_clear_tests(mm, pgdp);
> +
> + pmd_populate_tests(mm, pmdp, saved_ptep);
> + pud_populate_tests(mm, pudp, saved_pmdp);
> + p4d_populate_tests(mm, p4dp, saved_pudp);
> + pgd_populate_tests(mm, pgdp, saved_p4dp);
> +
> + p4d_free(mm, saved_p4dp);
> + pud_free(mm, saved_pudp);
> + pmd_free(mm, saved_pmdp);
> + pte_free(mm, saved_ptep);
> +
> + mm_dec_nr_puds(mm);
> + mm_dec_nr_pmds(mm);
> + mm_dec_nr_ptes(mm);
> + __mmdrop(mm);
> +
> + free_mapped_page(page);
> + return 0;
> +}
> +
> +static void __exit arch_pgtable_tests_exit(void) { }
> +
> +module_init(arch_pgtable_tests_init);
> +module_exit(arch_pgtable_tests_exit);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Anshuman Khandual <anshuman.khandual@arm.com>");
> +MODULE_DESCRIPTION("Test architecture page table helpers");
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] mm/kasan: dump alloc and free stack for page allocator
From: Walter Wu @ 2019-09-12 15:13 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Qian Cai, wsd_upstream, Arnd Bergmann, linux-mm, Andrey Konovalov,
linux-mediatek, linux-kernel, kasan-dev, Martin Schwidefsky,
Alexander Potapenko, linux-arm-kernel, Matthias Brugger,
Andrey Ryabinin, Andrew Morton, Dmitry Vyukov
In-Reply-To: <613f9f23-c7f0-871f-fe13-930c35ef3105@suse.cz>
On Thu, 2019-09-12 at 16:31 +0200, Vlastimil Babka wrote:
> On 9/12/19 4:08 PM, Walter Wu wrote:
> >
> >> extern void __reset_page_owner(struct page *page, unsigned int order);
> >> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> >> index 6c9682ce0254..dc560c7562e8 100644
> >> --- a/lib/Kconfig.kasan
> >> +++ b/lib/Kconfig.kasan
> >> @@ -41,6 +41,8 @@ config KASAN_GENERIC
> >> select SLUB_DEBUG if SLUB
> >> select CONSTRUCTORS
> >> select STACKDEPOT
> >> + select PAGE_OWNER
> >> + select PAGE_OWNER_FREE_STACK
> >> help
> >> Enables generic KASAN mode.
> >> Supported in both GCC and Clang. With GCC it requires version 4.9.2
> >> @@ -63,6 +65,8 @@ config KASAN_SW_TAGS
> >> select SLUB_DEBUG if SLUB
> >> select CONSTRUCTORS
> >> select STACKDEPOT
> >> + select PAGE_OWNER
> >> + select PAGE_OWNER_FREE_STACK
> >> help
> >
> > What is the difference between PAGE_OWNER+PAGE_OWNER_FREE_STACK and
> > DEBUG_PAGEALLOC?
>
> Same memory usage, but debug_pagealloc means also extra checks and
> restricting memory access to freed pages to catch UAF.
>
> > If you directly enable PAGE_OWNER+PAGE_OWNER_FREE_STACK
> > PAGE_OWNER_FREE_STACK,don't you think low-memory device to want to use
> > KASAN?
>
> OK, so it should be optional? But I think it's enough to distinguish no
> PAGE_OWNER at all, and PAGE_OWNER+PAGE_OWNER_FREE_STACK together - I
> don't see much point in PAGE_OWNER only for this kind of debugging.
>
If it's possible, it should be optional.
My experience is that PAGE_OWNER usually debug memory leakage.
> So how about this? KASAN wouldn't select PAGE_OWNER* but it would be
> recommended in the help+docs. When PAGE_OWNER and KASAN are selected by
> user, PAGE_OWNER_FREE_STACK gets also selected, and both will be also
> runtime enabled without explicit page_owner=on.
> I mostly want to avoid another boot-time option for enabling
> PAGE_OWNER_FREE_STACK.
> Would that be enough flexibility for low-memory devices vs full-fledged
> debugging?
We usually see feature option to decide whether it meet the platform.
The boot-time option isn't troubled to us, because enable the feature
owner should know what he should add to do.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] drm: bridge/dw_hdmi: add audio sample channel status setting
From: Jernej Škrabec @ 2019-09-12 15:25 UTC (permalink / raw)
To: Cheng-yi Chiang
Cc: moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
Doug Anderson, kuninori.morimoto.gx, Neil Armstrong, David Airlie,
dri-devel, cain.cai, Andrzej Hajda, Laurent Pinchart, Yakir Yang,
sam, Jerome Brunet, Xing Zheng, linux-rockchip, Dylan Reid,
tzungbi, Jonas Karlman, Jeffy Chen, 蔡枫,
linux-arm-kernel, linux-kernel, Daniel Vetter,
Enric Balletbo i Serra, kuankuan.y
In-Reply-To: <CAFv8NwJGa0HXsnv2MvJhknpr9PxUL3jH2HZLSLiSD5s_nHiQhQ@mail.gmail.com>
Dne sreda, 11. september 2019 ob 19:02:38 CEST je Cheng-yi Chiang napisal(a):
> On Thu, Sep 12, 2019 at 12:54 AM Jernej Škrabec <jernej.skrabec@siol.net>
wrote:
> > Dne sreda, 11. september 2019 ob 18:23:59 CEST je Neil Armstrong
napisal(a):
> > > On 11/09/2019 10:26, Cheng-Yi Chiang wrote:
> > > > From: Yakir Yang <ykk@rock-chips.com>
> > > >
> > > > When transmitting IEC60985 linear PCM audio, we configure the
> > > > Aduio Sample Channel Status information in the IEC60958 frame.
> > > > The status bit is already available in iec.status of
> > > > hdmi_codec_params.
> > > >
> > > > This fix the issue that audio does not come out on some monitors
> > > > (e.g. LG 22CV241)
> > > >
> > > > Note that these registers are only for interfaces:
> > > > I2S audio interface, General Purpose Audio (GPA), or AHB audio DMA
> > > > (AHBAUDDMA).
> > > > For S/PDIF interface this information comes from the stream.
> > > >
> > > > Currently this function dw_hdmi_set_channel_status is only called
> > > > from dw-hdmi-i2s-audio in I2S setup.
> > > >
> > > > Signed-off-by: Yakir Yang <ykk@rock-chips.com>
> > > > Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
> > > > ---
> > > >
> > > > Change from v2 to v3:
> > > > 1. Reuse what is already set in iec.status in hw_param.
> > > > 2. Remove all useless definition of registers and values.
> > > > 3. Note that the original sampling frequency is not written to
> > > >
> > > > the channel status as we reuse create_iec958_consumer in
> > > > pcm_iec958.c.
> > > > Without that it can still play audio fine.
> > > >
> > > > .../drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 1 +
> > > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 20
> > > > +++++++++++++++++++
> > > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 2 ++
> > > > include/drm/bridge/dw_hdmi.h | 1 +
> > > > 4 files changed, 24 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> > > > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c index
> > > > 34d8e837555f..20f4f92dd866 100644
> > > > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> > > > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> > > > @@ -102,6 +102,7 @@ static int dw_hdmi_i2s_hw_params(struct device
> > > > *dev,
> > > > void *data,>
> > > >
> > > > }
> > > >
> > > > dw_hdmi_set_sample_rate(hdmi, hparms->sample_rate);
> > > >
> > > > + dw_hdmi_set_channel_status(hdmi, hparms->iec.status);
> > > >
> > > > dw_hdmi_set_channel_count(hdmi, hparms->channels);
> > > > dw_hdmi_set_channel_allocation(hdmi, hparms-
> > >
> > >cea.channel_allocation);
> > >
> > > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > > > bd65d0479683..aa7efd4da1c8 100644
> > > > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > > @@ -582,6 +582,26 @@ static unsigned int hdmi_compute_n(unsigned int
> > > > freq,
> > > > unsigned long pixel_clk)>
> > > >
> > > > return n;
> > > >
> > > > }
> > > >
> > > > +/*
> > > > + * When transmitting IEC60958 linear PCM audio, these registers allow
> > > > to
> > > > + * configure the channel status information of all the channel status
> > > > + * bits in the IEC60958 frame. For the moment this configuration is
> > > > only
> > > > + * used when the I2S audio interface, General Purpose Audio (GPA),
> > > > + * or AHB audio DMA (AHBAUDDMA) interface is active
> > > > + * (for S/PDIF interface this information comes from the stream).
> > > > + */
> > > > +void dw_hdmi_set_channel_status(struct dw_hdmi *hdmi,
> > > > + u8 *channel_status)
> > > > +{
> > > > + /*
> > > > + * Set channel status register for frequency and word length.
> > > > + * Use default values for other registers.
> > > > + */
> > > > + hdmi_writeb(hdmi, channel_status[3], HDMI_FC_AUDSCHNLS7);
> > > > + hdmi_writeb(hdmi, channel_status[4], HDMI_FC_AUDSCHNLS8);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(dw_hdmi_set_channel_status);
> > > > +
> > > >
> > > > static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
> > > >
> > > > unsigned long pixel_clk, unsigned int sample_rate)
> > > >
> > > > {
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > > > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h index
> > > > 6988f12d89d9..fcff5059db24 100644
> > > > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > > > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > > > @@ -158,6 +158,8 @@
> > > >
> > > > #define HDMI_FC_SPDDEVICEINF 0x1062
> > > > #define HDMI_FC_AUDSCONF 0x1063
> > > > #define HDMI_FC_AUDSSTAT 0x1064
> > > >
> > > > +#define HDMI_FC_AUDSCHNLS7 0x106e
> > > > +#define HDMI_FC_AUDSCHNLS8 0x106f
> > > >
> > > > #define HDMI_FC_DATACH0FILL 0x1070
> > > > #define HDMI_FC_DATACH1FILL 0x1071
> > > > #define HDMI_FC_DATACH2FILL 0x1072
> > > >
> > > > diff --git a/include/drm/bridge/dw_hdmi.h
> > > > b/include/drm/bridge/dw_hdmi.h
> > > > index cf528c289857..4b3e863c4f8a 100644
> > > > --- a/include/drm/bridge/dw_hdmi.h
> > > > +++ b/include/drm/bridge/dw_hdmi.h
> > > > @@ -156,6 +156,7 @@ void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi,
> > > > bool
> > > > hpd, bool rx_sense);>
> > > >
> > > > void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int
> > > > rate);
> > > > void dw_hdmi_set_channel_count(struct dw_hdmi *hdmi, unsigned int
> > > > cnt);
> > > >
> > > > +void dw_hdmi_set_channel_status(struct dw_hdmi *hdmi, u8
> > > > *channel_status);
> > > >
> > > > void dw_hdmi_set_channel_allocation(struct dw_hdmi *hdmi, unsigned
> > > > int
> > > > ca);
> > > > void dw_hdmi_audio_enable(struct dw_hdmi *hdmi);
> > > > void dw_hdmi_audio_disable(struct dw_hdmi *hdmi);
> > >
> > > Looks fine for me:
> > > Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
> > >
> > > Jonas ? Jernej ? Russell ?
> >
> > Patch itself is fine, I'm just wondering if more information should be
> > copied from status array to registers. But I think they are not 1:1
> > mapping so some
> > more work would be needed. Anyway, patch is:
> Hi Jernej,
> Yes you are right. I was thinking about the same thing.
> But there are also some fields in the IEC60958 spec not mapped to the
> registers on dw-hdmi.
> So I ended up just writing the two registers in the original ykk's
> patch, and ignoring "original sampling frequency" like pcm_iec958.
> It turns out that audio plays fine on my LG monitor. So I suggest we
> can keep this patch as simple as it is, and add more register setting
> if we find issue.
> Thanks!
I think that for reliable audio passthrough support these registers will have
to be updated, but as I said, I'm fine with this patch as-is.
Best regards,
Jernej
>
> > Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >
> > Best regards,
> > Jernej
> >
> > > If it's ok for you I'll apply it.
> > >
> > > Neil
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/4] Fix UART DMA freezes for iMX6
From: Fabio Estevam @ 2019-09-12 15:31 UTC (permalink / raw)
To: Philipp Puschmann, Robin Gong, Fugang Duan
Cc: linux-serial, Greg Kroah-Hartman, Sascha Hauer, linux-kernel,
Vinod, NXP Linux Team, Sascha Hauer, Jiri Slaby, dmaengine,
Dan Williams, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190911144943.21554-1-philipp.puschmann@emlix.com>
[Adding Robin and Andy]
On Wed, Sep 11, 2019 at 11:50 AM Philipp Puschmann
<philipp.puschmann@emlix.com> wrote:
>
> For some years and since many kernel versions there are reports that
> RX UART DMA channel stops working at one point. So far the usual workaround was
> to disable RX DMA. This patches try to fix the underlying problem.
>
> When a running sdma script does not find any usable destination buffer to put
> its data into it just leads to stopping the channel being scheduled again. As
> solution we we manually retrigger the sdma script for this channel and by this
> dissolve the freeze.
>
> While this seems to work fine so far a further patch in this series increases
> the number of RX DMA periods for UART to reduce use cases running into such
> a situation.
>
> This patch series was tested with the current kernel and backported to
> kernel 4.15 with a special use case using a WL1837MOD via UART and provoking
> the hanging of UART RX DMA within seconds after starting a test application.
> It resulted in well known
> "Bluetooth: hci0: command 0x0408 tx timeout"
> errors and complete stop of UART data reception. Our Bluetooth traffic consists
> of many independent small packets, mostly only a few bytes, causing high usage
> of periods.
>
>
> Philipp Puschmann (4):
> dmaengine: imx-sdma: fix buffer ownership
> dmaengine: imx-sdma: fix dma freezes
> serial: imx: adapt rx buffer and dma periods
> dmaengine: imx-sdma: drop redundant variable
>
> drivers/dma/imx-sdma.c | 32 ++++++++++++++++++++++----------
> drivers/tty/serial/imx.c | 5 ++---
> 2 files changed, 24 insertions(+), 13 deletions(-)
>
> --
> 2.23.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V3 01/15] arm64: dts: imx8qxp: add fallback compatible string for scu pd
From: Dong Aisheng @ 2019-09-12 15:30 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Dong Aisheng, devicetree, dongas86, catalin.marinas, will.deacon,
oliver.graute, robh+dt, linux-imx, kernel, fabio.estevam,
Mark Rutland, shawnguo
In-Reply-To: <1568302252-28066-1-git-send-email-aisheng.dong@nxp.com>
According to binding doc, add the fallback compatible string for
scu pd.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Tested-by: Oliver Graute <oliver.graute@kococonnector.com>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
ChangeLog:
v2: new patch
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 1133b41..d851341 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -170,7 +170,7 @@
};
pd: imx8qx-pd {
- compatible = "fsl,imx8qxp-scu-pd";
+ compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd";
#power-domain-cells = <1>;
};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V3 00/15] arm64: dts: imx8: architecture improvement and adding imx8qm support
From: Dong Aisheng @ 2019-09-12 15:30 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Dong Aisheng, devicetree, dongas86, catalin.marinas, will.deacon,
oliver.graute, robh+dt, linux-imx, kernel, fabio.estevam,
shawnguo
IMX SCU based platforms (e.g. MX8QM/MX8QXP) are comprised of a number of SS
(Subsystems), those SS may be shared between different SoCs while most of them
can be reused like Devices Resources, Clocks, Power domains and etc.
This patch series aims to improve the MX8 architecture to comply with the HW
design to save a lot of duplicated codes and benefits us a better
maintainability and scalability in the future.
This patch series depends on another clk new binding series:
https://patchwork.kernel.org/cover/11046287/
NOTE: for the missing undocumented compatible strings for the new SoC IMX8QM
in this patch series. It will be sent in another patch series later.
ChangeLog:
v2->v3:
* use clock-indices property instead of bit-offset property suggested by Shawn Guo
* rebase to latest shawn/for-next
v1->v2:
* change to the new two cells scu clock binding, so original adding scu clocks
patches were removed.
* Move scu pd node above clk node
Dong Aisheng (15):
arm64: dts: imx8qxp: add fallback compatible string for scu pd
arm64: dts: imx8qxp: move scu pd node before scu clock node
arm64: dts: imx8qxp: orginize dts in subsystems
arm64: dts: imx8: add lsio lpcg clocks
arm64: dts: imx8: add conn lpcg clocks
arm64: dts: imx8: add adma lpcg clocks
arm64: dts: imx8: switch to two cell scu clock binding
arm64: dts: imx8: switch to new lpcg clock binding
arm64: dts: imx8qm: add lsio ss support
arm64: dts: imx8qm: add conn ss support
arm64: dts: imx8: split adma ss into dma and audio ss
arm64: dts: imx8qm: add dma ss support
arm64: dts: imx: add imx8qm common dts file
arm64: dts: imx: add imx8qm mek support
arm64: defconfig: add imx8qm mek support
arch/arm64/boot/dts/freescale/Makefile | 1 +
arch/arm64/boot/dts/freescale/imx8-ss-adma.dtsi | 8 +
arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi | 67 ++++
arch/arm64/boot/dts/freescale/imx8-ss-conn.dtsi | 192 +++++++++
arch/arm64/boot/dts/freescale/imx8-ss-ddr.dtsi | 19 +
arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi | 209 ++++++++++
arch/arm64/boot/dts/freescale/imx8-ss-lsio.dtsi | 310 +++++++++++++++
arch/arm64/boot/dts/freescale/imx8qm-mek.dts | 144 +++++++
arch/arm64/boot/dts/freescale/imx8qm-ss-conn.dtsi | 21 +
arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi | 51 +++
arch/arm64/boot/dts/freescale/imx8qm-ss-lsio.dtsi | 61 +++
arch/arm64/boot/dts/freescale/imx8qm.dtsi | 180 +++++++++
arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dts | 16 +-
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 8 +-
arch/arm64/boot/dts/freescale/imx8qxp-ss-adma.dtsi | 37 ++
arch/arm64/boot/dts/freescale/imx8qxp-ss-conn.dtsi | 21 +
arch/arm64/boot/dts/freescale/imx8qxp-ss-lsio.dtsi | 61 +++
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 431 ++-------------------
arch/arm64/configs/defconfig | 1 +
19 files changed, 1420 insertions(+), 418 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/imx8-ss-adma.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8-ss-conn.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8-ss-ddr.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8-ss-lsio.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-mek.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-ss-conn.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-ss-lsio.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8qm.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-ss-adma.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-ss-conn.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-ss-lsio.dtsi
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V3 02/15] arm64: dts: imx8qxp: move scu pd node before scu clock node
From: Dong Aisheng @ 2019-09-12 15:30 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Dong Aisheng, devicetree, dongas86, catalin.marinas, will.deacon,
oliver.graute, robh+dt, linux-imx, kernel, fabio.estevam,
Mark Rutland, shawnguo
In-Reply-To: <1568302252-28066-1-git-send-email-aisheng.dong@nxp.com>
SCU clock depends on SCU Power domain. So let's move scu pd node
before scu clock to make it probe earlier.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Tested-by: Oliver Graute <oliver.graute@kococonnector.com>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
ChangeLog:
v2: new patch
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index d851341..ced62ee 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -152,6 +152,11 @@
&lsio_mu1 1 3
&lsio_mu1 3 3>;
+ pd: imx8qx-pd {
+ compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd";
+ #power-domain-cells = <1>;
+ };
+
clk: clock-controller {
compatible = "fsl,imx8qxp-clk";
#clock-cells = <1>;
@@ -169,11 +174,6 @@
#size-cells = <1>;
};
- pd: imx8qx-pd {
- compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd";
- #power-domain-cells = <1>;
- };
-
rtc: rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V3 04/15] arm64: dts: imx8: add lsio lpcg clocks
From: Dong Aisheng @ 2019-09-12 15:30 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Dong Aisheng, devicetree, dongas86, catalin.marinas, will.deacon,
oliver.graute, robh+dt, linux-imx, kernel, fabio.estevam,
Mark Rutland, shawnguo
In-Reply-To: <1568302252-28066-1-git-send-email-aisheng.dong@nxp.com>
Add lsio lpcg clocks
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Tested-by: Oliver Graute <oliver.graute@kococonnector.com>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
ChangeLog:
v2->v3:
* update to use clock-indices property instead of bit-offset property
v1->v2:
* Use old SCU clock binding temporarily to avoid build warning due to SCU
clock cell will be changed to 2.
* add power domain property
---
arch/arm64/boot/dts/freescale/imx8-ss-lsio.dtsi | 155 +++++++++++++++++++++++-
1 file changed, 154 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-lsio.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-lsio.dtsi
index 00eaadb..ff29e7f 100644
--- a/arch/arm64/boot/dts/freescale/imx8-ss-lsio.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8-ss-lsio.dtsi
@@ -4,12 +4,28 @@
* Dong Aisheng <aisheng.dong@nxp.com>
*/
+#include <dt-bindings/firmware/imx/rsrc.h>
+
lsio_subsys: bus@5d000000 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x5d000000 0x0 0x5d000000 0x1000000>;
+ lsio_mem_clk: clock-lsio-mem {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <200000000>;
+ clock-output-names = "lsio_mem_clk";
+ };
+
+ lsio_bus_clk: clock-lsio-bus {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <100000000>;
+ clock-output-names = "lsio_bus_clk";
+ };
+
lsio_gpio0: gpio@5d080000 {
reg = <0x5d080000 0x10000>;
interrupts = <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
@@ -131,8 +147,145 @@ lsio_subsys: bus@5d000000 {
power-domains = <&pd IMX_SC_R_MU_13A>;
};
- lsio_lpcg: clock-controller@5d400000 {
+ /* LPCG clocks */
+ lsio_lpcg: clock-controller-legacy@5d400000 {
reg = <0x5d400000 0x400000>;
#clock-cells = <1>;
};
+
+ pwm0_lpcg: clock-controller@5d400000 {
+ reg = <0x5d400000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&clk IMX_LSIO_PWM0_CLK>, <&clk IMX_LSIO_PWM0_CLK>,
+ <&clk IMX_LSIO_PWM0_CLK>, <&lsio_bus_clk>,
+ <&clk IMX_LSIO_PWM0_CLK>;
+ clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_1>,
+ <IMX_LPCG_CLK_4>, <IMX_LPCG_CLK_5>,
+ <IMX_LPCG_CLK_6>;
+ clock-output-names = "pwm0_lpcg_ipg_clk",
+ "pwm0_lpcg_ipg_hf_clk",
+ "pwm0_lpcg_ipg_s_clk",
+ "pwm0_lpcg_ipg_slv_clk",
+ "pwm0_lpcg_ipg_mstr_clk";
+ power-domains = <&pd IMX_SC_R_PWM_0>;
+ };
+
+ pwm1_lpcg: clock-controller@5d410000 {
+ reg = <0x5d410000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&clk IMX_LSIO_PWM1_CLK>, <&clk IMX_LSIO_PWM1_CLK>,
+ <&clk IMX_LSIO_PWM1_CLK>, <&lsio_bus_clk>,
+ <&clk IMX_LSIO_PWM1_CLK>;
+ clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_1>,
+ <IMX_LPCG_CLK_4>, <IMX_LPCG_CLK_5>,
+ <IMX_LPCG_CLK_6>;
+ clock-output-names = "pwm1_lpcg_ipg_clk",
+ "pwm1_lpcg_ipg_hf_clk",
+ "pwm1_lpcg_ipg_s_clk",
+ "pwm1_lpcg_ipg_slv_clk",
+ "pwm1_lpcg_ipg_mstr_clk";
+ power-domains = <&pd IMX_SC_R_PWM_1>;
+ };
+
+ pwm2_lpcg: clock-controller@5d420000 {
+ reg = <0x5d420000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&clk IMX_LSIO_PWM2_CLK>, <&clk IMX_LSIO_PWM2_CLK>,
+ <&clk IMX_LSIO_PWM2_CLK>, <&lsio_bus_clk>,
+ <&clk IMX_LSIO_PWM2_CLK>;
+ clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_1>,
+ <IMX_LPCG_CLK_4>, <IMX_LPCG_CLK_5>,
+ <IMX_LPCG_CLK_6>;
+ clock-output-names = "pwm2_lpcg_ipg_clk",
+ "pwm2_lpcg_ipg_hf_clk",
+ "pwm2_lpcg_ipg_s_clk",
+ "pwm2_lpcg_ipg_slv_clk",
+ "pwm2_lpcg_ipg_mstr_clk";
+ power-domains = <&pd IMX_SC_R_PWM_2>;
+ };
+
+ pwm3_lpcg: clock-controller@5d430000 {
+ reg = <0x5d430000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&clk IMX_LSIO_PWM3_CLK>, <&clk IMX_LSIO_PWM3_CLK>,
+ <&clk IMX_LSIO_PWM3_CLK>, <&lsio_bus_clk>,
+ <&clk IMX_LSIO_PWM3_CLK>;
+ clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_1>,
+ <IMX_LPCG_CLK_4>, <IMX_LPCG_CLK_5>,
+ <IMX_LPCG_CLK_6>;
+ clock-output-names = "pwm3_lpcg_ipg_clk",
+ "pwm3_lpcg_ipg_hf_clk",
+ "pwm3_lpcg_ipg_s_clk",
+ "pwm3_lpcg_ipg_slv_clk",
+ "pwm3_lpcg_ipg_mstr_clk";
+ power-domains = <&pd IMX_SC_R_PWM_3>;
+ };
+
+ pwm4_lpcg: clock-controller@5d440000 {
+ reg = <0x5d440000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&clk IMX_LSIO_PWM4_CLK>, <&clk IMX_LSIO_PWM4_CLK>,
+ <&clk IMX_LSIO_PWM4_CLK>, <&lsio_bus_clk>,
+ <&clk IMX_LSIO_PWM4_CLK>;
+ clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_1>,
+ <IMX_LPCG_CLK_4>, <IMX_LPCG_CLK_5>,
+ <IMX_LPCG_CLK_6>;
+ clock-output-names = "pwm4_lpcg_ipg_clk",
+ "pwm4_lpcg_ipg_hf_clk",
+ "pwm4_lpcg_ipg_s_clk",
+ "pwm4_lpcg_ipg_slv_clk",
+ "pwm4_lpcg_ipg_mstr_clk";
+ power-domains = <&pd IMX_SC_R_PWM_4>;
+ };
+
+ pwm5_lpcg: clock-controller@5d450000 {
+ reg = <0x5d450000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&clk IMX_LSIO_PWM5_CLK>, <&clk IMX_LSIO_PWM5_CLK>,
+ <&clk IMX_LSIO_PWM5_CLK>, <&lsio_bus_clk>,
+ <&clk IMX_LSIO_PWM5_CLK>;
+ clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_1>,
+ <IMX_LPCG_CLK_4>, <IMX_LPCG_CLK_5>,
+ <IMX_LPCG_CLK_6>;
+ clock-output-names = "pwm5_lpcg_ipg_clk",
+ "pwm5_lpcg_ipg_hf_clk",
+ "pwm5_lpcg_ipg_s_clk",
+ "pwm5_lpcg_ipg_slv_clk",
+ "pwm5_lpcg_ipg_mstr_clk";
+ power-domains = <&pd IMX_SC_R_PWM_5>;
+ };
+
+ pwm6_lpcg: clock-controller@5d460000 {
+ reg = <0x5d460000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&clk IMX_LSIO_PWM6_CLK>, <&clk IMX_LSIO_PWM6_CLK>,
+ <&clk IMX_LSIO_PWM6_CLK>, <&lsio_bus_clk>,
+ <&clk IMX_LSIO_PWM6_CLK>;
+ clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_1>,
+ <IMX_LPCG_CLK_4>, <IMX_LPCG_CLK_5>,
+ <IMX_LPCG_CLK_6>;
+ clock-output-names = "pwm6_lpcg_ipg_clk",
+ "pwm6_lpcg_ipg_hf_clk",
+ "pwm6_lpcg_ipg_s_clk",
+ "pwm6_lpcg_ipg_slv_clk",
+ "pwm6_lpcg_ipg_mstr_clk";
+ power-domains = <&pd IMX_SC_R_PWM_6>;
+ };
+
+ pwm7_lpcg: clock-controller@5d470000 {
+ reg = <0x5d470000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&clk IMX_LSIO_PWM7_CLK>, <&clk IMX_LSIO_PWM7_CLK>,
+ <&clk IMX_LSIO_PWM7_CLK>, <&lsio_bus_clk>,
+ <&clk IMX_LSIO_PWM7_CLK>;
+ clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_1>,
+ <IMX_LPCG_CLK_4>, <IMX_LPCG_CLK_5>,
+ <IMX_LPCG_CLK_6>;
+ clock-output-names = "pwm7_lpcg_ipg_clk",
+ "pwm7_lpcg_ipg_hf_clk",
+ "pwm7_lpcg_ipg_s_clk",
+ "pwm7_lpcg_ipg_slv_clk",
+ "pwm7_lpcg_ipg_mstr_clk";
+ power-domains = <&pd IMX_SC_R_PWM_7>;
+ };
};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox