Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 3/4] clk/soc: mediatek: mt6779: Bind clock driver from platform device
From: matthias.bgg @ 2020-05-18 11:31 UTC (permalink / raw)
  To: Rob Herring, Matthias Brugger, Michael Turquette, Stephen Boyd
  Cc: Kate Stewart, devicetree, Greg Kroah-Hartman, linux-kernel,
	linux-mediatek, linux-arm-kernel, mtk01761, Thomas Gleixner,
	linux-clk, Allison Randal
In-Reply-To: <20200518113156.25009-1-matthias.bgg@kernel.org>

From: Matthias Brugger <matthias.bgg@gmail.com>

The mmsys driver is now the top level entry point for the multimedia
system (mmsys), we bind the clock driver by creating a platform device.
We also bind the MediaTek DRM driver which is not yet implement and
therefor will errror out for now.

Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
---

 drivers/clk/mediatek/clk-mt6779-mm.c | 9 ++-------
 drivers/soc/mediatek/mtk-mmsys.c     | 8 ++++++++
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt6779-mm.c b/drivers/clk/mediatek/clk-mt6779-mm.c
index fb5fbb8e3e41..059c1a41ac7a 100644
--- a/drivers/clk/mediatek/clk-mt6779-mm.c
+++ b/drivers/clk/mediatek/clk-mt6779-mm.c
@@ -84,15 +84,11 @@ static const struct mtk_gate mm_clks[] = {
 	GATE_MM1(CLK_MM_DISP_OVL_FBDC, "mm_disp_ovl_fbdc", "mm_sel", 16),
 };
 
-static const struct of_device_id of_match_clk_mt6779_mm[] = {
-	{ .compatible = "mediatek,mt6779-mmsys", },
-	{}
-};
-
 static int clk_mt6779_mm_probe(struct platform_device *pdev)
 {
+	struct device *dev = &pdev->dev;
+	struct device_node *node = dev->parent->of_node;
 	struct clk_onecell_data *clk_data;
-	struct device_node *node = pdev->dev.of_node;
 
 	clk_data = mtk_alloc_clk_data(CLK_MM_NR_CLK);
 
@@ -106,7 +102,6 @@ static struct platform_driver clk_mt6779_mm_drv = {
 	.probe = clk_mt6779_mm_probe,
 	.driver = {
 		.name = "clk-mt6779-mm",
-		.of_match_table = of_match_clk_mt6779_mm,
 	},
 };
 
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index fee64c8d3020..dc15808cf3a3 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -88,6 +88,10 @@ static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
 	.clk_driver = "clk-mt2712-mm",
 };
 
+static const struct mtk_mmsys_driver_data mt6779_mmsys_driver_data = {
+	.clk_driver = "clk-mt6779-mm",
+};
+
 static const struct mtk_mmsys_driver_data mt6797_mmsys_driver_data = {
 	.clk_driver = "clk-mt6797-mm",
 };
@@ -343,6 +347,10 @@ static const struct of_device_id of_match_mtk_mmsys[] = {
 		.compatible = "mediatek,mt2712-mmsys",
 		.data = &mt2712_mmsys_driver_data,
 	},
+	{
+		.compatible = "mediatek,mt6779-mmsys",
+		.data = &mt6779_mmsys_driver_data,
+	},
 	{
 		.compatible = "mediatek,mt6797-mmsys",
 		.data = &mt6797_mmsys_driver_data,
-- 
2.26.2


_______________________________________________
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 4/4] arm64: dts: mt6797: Fix mmsys node name
From: matthias.bgg @ 2020-05-18 11:31 UTC (permalink / raw)
  To: Rob Herring, Matthias Brugger, Michael Turquette, Stephen Boyd
  Cc: Kate Stewart, devicetree, Greg Kroah-Hartman, linux-kernel,
	linux-mediatek, linux-arm-kernel, mtk01761, Thomas Gleixner,
	linux-clk, Allison Randal
In-Reply-To: <20200518113156.25009-1-matthias.bgg@kernel.org>

From: Matthias Brugger <matthias.bgg@gmail.com>

Node names are supposed to match the class of the device. The
mmsys node is a syscon as it provides more then just a clock controller.
Update the name.

Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>

---

 arch/arm64/boot/dts/mediatek/mt6797.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt6797.dtsi b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
index 136ef9527a0d..3efd032481ce 100644
--- a/arch/arm64/boot/dts/mediatek/mt6797.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
@@ -233,7 +233,7 @@ uart3: serial@11005000 {
 		status = "disabled";
 	};
 
-	mmsys: mmsys_config@14000000 {
+	mmsys: syscon@14000000 {
 		compatible = "mediatek,mt6797-mmsys", "syscon";
 		reg = <0 0x14000000 0 0x1000>;
 		#clock-cells = <1>;
-- 
2.26.2


_______________________________________________
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: [PATCH 1/6] arm64: scs: Store absolute SCS stack pointer value in thread_info
From: Mark Rutland @ 2020-05-18 11:37 UTC (permalink / raw)
  To: Will Deacon
  Cc: Kees Cook, Jann Horn, Peter Zijlstra, Catalin Marinas,
	linux-kernel, Mark Rutland, Sami Tolvanen, kernel-team,
	Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200515172756.27185-2-will@kernel.org>

On Fri, May 15, 2020 at 06:27:51PM +0100, Will Deacon wrote:
> Storing the SCS information in thread_info as a {base,offset} pair
> introduces an additional load instruction on the ret-to-user path,
> since the SCS stack pointer in x18 has to be converted back to an offset
> by subtracting the base.
> 
> Replace the offset with the absolute SCS stack pointer value instead
> and avoid the redundant load.
> 
> Signed-off-by: Will Deacon <will@kernel.org>

One trivial nit below, but regardless this looks sound to me, and I
certainly prefer having the absolute address rather than an offset, so:

Reviewed-by: Mark Rutland <mark.rutland@arm.com>

> diff --git a/kernel/scs.c b/kernel/scs.c
> index 9389c28f0853..5ff8663e4a67 100644
> --- a/kernel/scs.c
> +++ b/kernel/scs.c
> @@ -60,8 +60,7 @@ int scs_prepare(struct task_struct *tsk, int node)
>  	if (!s)
>  		return -ENOMEM;
>  
> -	task_scs(tsk) = s;
> -	task_scs_offset(tsk) = 0;
> +	task_scs(tsk) = task_scs_sp(tsk) = s;

I think this would be more legible as two statements:

|	task_sys(tsk) = s;
|	task_scs_sp(tsk) = s;

... as we usually save `foo = bar = baz` stuff for the start of a
function or within loop conditions.

Thanks,
Mark.

>  	scs_account(tsk, 1);
>  	return 0;
>  }
> -- 
> 2.26.2.761.g0e0b3e54be-goog
> 

_______________________________________________
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 2/6] scs: Move accounting into alloc/free functions
From: Mark Rutland @ 2020-05-18 11:38 UTC (permalink / raw)
  To: Will Deacon
  Cc: Kees Cook, Jann Horn, Peter Zijlstra, Catalin Marinas,
	linux-kernel, Mark Rutland, Sami Tolvanen, kernel-team,
	Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200515172756.27185-3-will@kernel.org>

On Fri, May 15, 2020 at 06:27:52PM +0100, Will Deacon wrote:
> There's no need to perform the shadow stack page accounting independently
> of the lifetime of the underlying allocation, so call the accounting code
> from the {alloc,free}() functions and simplify the code in the process.
> 
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
>  kernel/scs.c | 45 +++++++++++++++++++++------------------------
>  1 file changed, 21 insertions(+), 24 deletions(-)

One (super trivial) nit below, but regardless this looks like a sound
and sensible cleanup, so:

Reviewed-by: Mark Rutland <mark.rutland@arm.com>

> diff --git a/kernel/scs.c b/kernel/scs.c
> index 5ff8663e4a67..aea841cd7586 100644
> --- a/kernel/scs.c
> +++ b/kernel/scs.c
> @@ -14,25 +14,35 @@

>  static void *scs_alloc(int node)
>  {

> +	void *s = kmem_cache_alloc_node(scs_cache, GFP_SCS, node);
> +
> +	if (!s)
> +		return NULL;

Super trivial nit, but could we omit the line space between these two,
to fit with usual style?

Mark.

_______________________________________________
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] arm64: Fix PTRACE_SYSEMU semantics
From: Will Deacon @ 2020-05-18 11:41 UTC (permalink / raw)
  To: Keno Fischer
  Cc: catalin.marinas, will.deacon, linux-kernel, oleg, sudeep.holla,
	linux-arm-kernel
In-Reply-To: <20200515222253.GA38408@juliacomputing.com>

On Fri, May 15, 2020 at 06:22:53PM -0400, Keno Fischer wrote:
> Quoth the man page:
> ```
>        If the tracee was restarted by PTRACE_SYSCALL or PTRACE_SYSEMU, the
>        tracee enters syscall-enter-stop just prior to entering any system
>        call (which will not be executed if the restart was using
>        PTRACE_SYSEMU, regardless of any change made to registers at this
>        point or how the tracee is restarted after this stop).
> ```
> 
> The parenthetical comment is currently true on x86 and powerpc,
> but not currently true on arm64. arm64 re-checks the _TIF_SYSCALL_EMU
> flag after the syscall entry ptrace stop. However, at this point,
> it reflects which method was used to re-start the syscall
> at the entry stop, rather than the method that was used to reach it.
> Fix that by recording the original flag before performing the ptrace
> stop, bringing the behavior in line with documentation and x86/powerpc.
> 
> Signed-off-by: Keno Fischer <keno@juliacomputing.com>
> ---
>  arch/arm64/kernel/ptrace.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index b3d3005d9515..b67b4d14aa17 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -1829,10 +1829,12 @@ static void tracehook_report_syscall(struct pt_regs *regs,
>  
>  int syscall_trace_enter(struct pt_regs *regs)
>  {
> -	if (test_thread_flag(TIF_SYSCALL_TRACE) ||
> -		test_thread_flag(TIF_SYSCALL_EMU)) {
> +	u32 flags = READ_ONCE(current_thread_info()->flags) &
> +		(_TIF_SYSCALL_EMU | _TIF_SYSCALL_TRACE);
> +
> +	if (flags) {

nit: but I'd rather the '&' operation was in the conditional so that the
'flags' variable holds all of the flags.

With that:

Acked-by: Will Deacon <will@kernel.org>

Also needs:

Cc: <stable@vger.kernel.org>
Fixes: f086f67485c5 ("arm64: ptrace: add support for syscall emulation")

Catalin -- can you pick this up for 5.7 please, with my 'nit' addressed?

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 1/4] rcu/kasan: record and print call_rcu() call stack
From: Walter Wu @ 2020-05-18 11:34 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: wsd_upstream, Paul E . McKenney, Linux-MM, Lai Jiangshan,
	Josh Triplett, kasan-dev, LKML, Joel Fernandes, linux-mediatek,
	Alexander Potapenko, Matthias Brugger, Andrey Ryabinin,
	Andrew Morton, Linux ARM, Mathieu Desnoyers
In-Reply-To: <CACT4Y+aSmcoSeC7J7RgoVV8CanwCrEz=zNZYG=_8KX3U-57A5Q@mail.gmail.com>

On Mon, 2020-05-18 at 12:21 +0200, 'Dmitry Vyukov' via kasan-dev wrote:
> On Mon, May 18, 2020 at 8:26 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> >
> > This feature will record the last two call_rcu() call stack and
> > prints up to 2 call_rcu() call stacks in KASAN report.
> >
> > When call_rcu() is called, we store the call_rcu() call stack into
> > slub alloc meta-data, so that the KASAN report can print rcu stack.
> >
> > [1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
> > [2]https://groups.google.com/forum/#!searchin/kasan-dev/better$20stack$20traces$20for$20rcu%7Csort:date/kasan-dev/KQsjT_88hDE/7rNUZprRBgAJ
> >
> > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> > Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> > Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > Cc: Dmitry Vyukov <dvyukov@google.com>
> > Cc: Alexander Potapenko <glider@google.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Paul E. McKenney <paulmck@kernel.org>
> > Cc: Josh Triplett <josh@joshtriplett.org>
> > Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> > Cc: Lai Jiangshan <jiangshanlai@gmail.com>
> > Cc: Joel Fernandes <joel@joelfernandes.org>
> > ---
> >  include/linux/kasan.h |  2 ++
> >  kernel/rcu/tree.c     |  2 ++
> >  lib/Kconfig.kasan     |  2 ++
> >  mm/kasan/common.c     |  4 ++--
> >  mm/kasan/generic.c    | 20 ++++++++++++++++++++
> >  mm/kasan/kasan.h      | 10 ++++++++++
> >  mm/kasan/report.c     | 24 ++++++++++++++++++++++++
> >  7 files changed, 62 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> > index 31314ca7c635..23b7ee00572d 100644
> > --- a/include/linux/kasan.h
> > +++ b/include/linux/kasan.h
> > @@ -174,11 +174,13 @@ static inline size_t kasan_metadata_size(struct kmem_cache *cache) { return 0; }
> >
> >  void kasan_cache_shrink(struct kmem_cache *cache);
> >  void kasan_cache_shutdown(struct kmem_cache *cache);
> > +void kasan_record_aux_stack(void *ptr);
> >
> >  #else /* CONFIG_KASAN_GENERIC */
> >
> >  static inline void kasan_cache_shrink(struct kmem_cache *cache) {}
> >  static inline void kasan_cache_shutdown(struct kmem_cache *cache) {}
> > +static inline void kasan_record_aux_stack(void *ptr) {}
> >
> >  #endif /* CONFIG_KASAN_GENERIC */
> >
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index 06548e2ebb72..36a4ff7f320b 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -57,6 +57,7 @@
> >  #include <linux/slab.h>
> >  #include <linux/sched/isolation.h>
> >  #include <linux/sched/clock.h>
> > +#include <linux/kasan.h>
> >  #include "../time/tick-internal.h"
> >
> >  #include "tree.h"
> > @@ -2668,6 +2669,7 @@ __call_rcu(struct rcu_head *head, rcu_callback_t func)
> >         head->func = func;
> >         head->next = NULL;
> >         local_irq_save(flags);
> > +       kasan_record_aux_stack(head);
> >         rdp = this_cpu_ptr(&rcu_data);
> >
> >         /* Add the callback to our list. */
> > diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> > index 81f5464ea9e1..4e83cf6e3caa 100644
> > --- a/lib/Kconfig.kasan
> > +++ b/lib/Kconfig.kasan
> > @@ -58,6 +58,8 @@ config KASAN_GENERIC
> >           For better error detection enable CONFIG_STACKTRACE.
> >           Currently CONFIG_KASAN_GENERIC doesn't work with CONFIG_DEBUG_SLAB
> >           (the resulting kernel does not boot).
> > +         In generic mode KASAN prints the last two call_rcu() call stacks in
> > +         reports.
> >
> >  config KASAN_SW_TAGS
> >         bool "Software tag-based mode"
> > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > index 2906358e42f0..8bc618289bb1 100644
> > --- a/mm/kasan/common.c
> > +++ b/mm/kasan/common.c
> > @@ -41,7 +41,7 @@
> >  #include "kasan.h"
> >  #include "../slab.h"
> >
> > -static inline depot_stack_handle_t save_stack(gfp_t flags)
> > +depot_stack_handle_t kasan_save_stack(gfp_t flags)
> >  {
> >         unsigned long entries[KASAN_STACK_DEPTH];
> >         unsigned int nr_entries;
> > @@ -54,7 +54,7 @@ static inline depot_stack_handle_t save_stack(gfp_t flags)
> >  static inline void set_track(struct kasan_track *track, gfp_t flags)
> >  {
> >         track->pid = current->pid;
> > -       track->stack = save_stack(flags);
> > +       track->stack = kasan_save_stack(flags);
> >  }
> >
> >  void kasan_enable_current(void)
> > diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> > index 56ff8885fe2e..78d8e0a75a8a 100644
> > --- a/mm/kasan/generic.c
> > +++ b/mm/kasan/generic.c
> > @@ -325,3 +325,23 @@ DEFINE_ASAN_SET_SHADOW(f2);
> >  DEFINE_ASAN_SET_SHADOW(f3);
> >  DEFINE_ASAN_SET_SHADOW(f5);
> >  DEFINE_ASAN_SET_SHADOW(f8);
> > +
> > +void kasan_record_aux_stack(void *addr)
> > +{
> > +       struct page *page = kasan_addr_to_page(addr);
> > +       struct kmem_cache *cache;
> > +       struct kasan_alloc_meta *alloc_info;
> > +       void *object;
> > +
> > +       if (!(page && PageSlab(page)))
> > +               return;
> > +
> > +       cache = page->slab_cache;
> > +       object = nearest_obj(cache, page, addr);
> > +       alloc_info = get_alloc_info(cache, object);
> > +
> > +       /* record last two call_rcu() call stacks */
> > +       if (alloc_info->rcu_stack[0])
> 
> Do we need this if?
> 
> If we do "alloc_info->rcu_stack[1] = alloc_info->rcu_stack[0]"
> unconditionally, then we will just move 0 from [0] to [1], which
> should be 0 at this point anyway.
> 

Yes, this if is redundant.

> I think it will be more reasonable to rename rcu_stack to aux_stack,
> the function that stores the stacks is kasan_record_aux_stack.
> 

ok, we will change it's name.

> > +               alloc_info->rcu_stack[1] = alloc_info->rcu_stack[0];
> > +       alloc_info->rcu_stack[0] = kasan_save_stack(GFP_NOWAIT);
> > +}
> > diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> > index e8f37199d885..870c5dd07756 100644
> > --- a/mm/kasan/kasan.h
> > +++ b/mm/kasan/kasan.h
> > @@ -104,7 +104,15 @@ struct kasan_track {
> >
> >  struct kasan_alloc_meta {
> >         struct kasan_track alloc_track;
> > +#ifdef CONFIG_KASAN_GENERIC
> > +       /*
> > +        * call_rcu() call stack is stored into struct kasan_alloc_meta.
> > +        * The free stack is stored into struct kasan_free_meta.
> > +        */
> > +       depot_stack_handle_t rcu_stack[2];
> > +#else
> >         struct kasan_track free_track[KASAN_NR_FREE_STACKS];
> > +#endif
> >  #ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> >         u8 free_pointer_tag[KASAN_NR_FREE_STACKS];
> >         u8 free_track_idx;
> > @@ -159,6 +167,8 @@ void kasan_report_invalid_free(void *object, unsigned long ip);
> >
> >  struct page *kasan_addr_to_page(const void *addr);
> >
> > +depot_stack_handle_t kasan_save_stack(gfp_t flags);
> > +
> >  #if defined(CONFIG_KASAN_GENERIC) && \
> >         (defined(CONFIG_SLAB) || defined(CONFIG_SLUB))
> >  void quarantine_put(struct kasan_free_meta *info, struct kmem_cache *cache);
> > diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> > index 80f23c9da6b0..5ee66cf7e27c 100644
> > --- a/mm/kasan/report.c
> > +++ b/mm/kasan/report.c
> > @@ -179,6 +179,17 @@ static struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> >         return &alloc_meta->free_track[i];
> >  }
> >
> > +#ifdef CONFIG_KASAN_GENERIC
> > +static void print_stack(depot_stack_handle_t stack)
> > +{
> > +       unsigned long *entries;
> > +       unsigned int nr_entries;
> > +
> > +       nr_entries = stack_depot_fetch(stack, &entries);
> > +       stack_trace_print(entries, nr_entries, 0);
> > +}
> > +#endif
> > +
> >  static void describe_object(struct kmem_cache *cache, void *object,
> >                                 const void *addr, u8 tag)
> >  {
> > @@ -192,6 +203,19 @@ static void describe_object(struct kmem_cache *cache, void *object,
> >                 free_track = kasan_get_free_track(cache, object, tag);
> >                 print_track(free_track, "Freed");
> >                 pr_err("\n");
> > +
> > +#ifdef CONFIG_KASAN_GENERIC
> > +               if (alloc_info->rcu_stack[0]) {
> > +                       pr_err("Last one call_rcu() call stack:\n");
> > +                       print_stack(alloc_info->rcu_stack[0]);
> > +                       pr_err("\n");
> > +               }
> > +               if (alloc_info->rcu_stack[1]) {
> > +                       pr_err("Second to last call_rcu() call stack:\n");
> > +                       print_stack(alloc_info->rcu_stack[1]);
> > +                       pr_err("\n");
> > +               }
> > +#endif
> >         }
> >
> >         describe_object_addr(cache, object, addr);
> > --
> > 2.18.0
> >
> > --
> > You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20200518062603.4570-1-walter-zh.wu%40mediatek.com.
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH] ARM: dts: at91: sama5d2_xplained: Add aliases for the dedicated I2C IPs
From: Tudor.Ambarus @ 2020-05-18 11:49 UTC (permalink / raw)
  To: alexandre.belloni, Nicolas.Ferre, Ludovic.Desroches
  Cc: devicetree, robh+dt, linux-kernel, linux-arm-kernel,
	Tudor.Ambarus

From: Tudor Ambarus <tudor.ambarus@microchip.com>

The sama5d2 SoC has two dedicated I2C IPs that are enabled on
sama5d2_xplained. Add alias for the i2c devices to not rely on
probe order for the i2c device numbering.

Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
---
 arch/arm/boot/dts/at91-sama5d2_xplained.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index 851b8587068b..a927165ea7c2 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -18,6 +18,8 @@
 
 	aliases {
 		serial0 = &uart1;	/* DBGU */
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
 		i2c2 = &i2c2;		/* XPRO EXT2 */
 	};
 
-- 
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: [PATCH v4 7/7] firmware: smccc: Add ARCH_SOC_ID support
From: Sudeep Holla @ 2020-05-18 11:55 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Mark Rutland, Lorenzo Pieralisi, Catalin Marinas,
	linux-kernel@vger.kernel.org, Steven Price, harb, Will Deacon,
	Linux ARM
In-Reply-To: <CAK8P3a20R+H6m5GZj2_0w3s-xF+J_qSVrQH8EjyQXe6+9WTYxw@mail.gmail.com>

On Mon, May 18, 2020 at 11:30:21AM +0200, Arnd Bergmann wrote:
> On Mon, May 18, 2020 at 11:12 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> > +static ssize_t
> > +jep106_cont_bank_code_show(struct device *dev, struct device_attribute *attr,
> > +                          char *buf)
> > +{
> > +       return sprintf(buf, "0x%02x\n", JEP106_BANK_CONT_CODE(soc_id_version));
> > +}
> > +
> > +static DEVICE_ATTR_RO(jep106_cont_bank_code);
> > +
> > +static ssize_t
> > +jep106_identification_code_show(struct device *dev,
> > +                               struct device_attribute *attr, char *buf)
> > +{
> > +       return sprintf(buf, "0x%02x\n", JEP106_ID_CODE(soc_id_version));
> > +}
>
> I think we should try hard to avoid nonstandard attributes for the soc device.
>

I agree with that in general but this is bit different for below mentioned
reason.

> Did you run into a problem with finding one of the existing attributes
> that can be used to hold the fields?
>

Not really! The 2 JEP106 codes can be used to derive the manufacturer which
could match one of the existing attributes. However doing so might require
importing the huge JEP106 list as it needs to be maintained and updated
in the kernel. Also that approach will have the compatibility issue and
that is the reason for introducing these attributes representing raw
values for userspace.

--
Regards,
Sudeep

_______________________________________________
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 3/6] arm64: scs: Use 'scs_sp' register alias for x18
From: Mark Rutland @ 2020-05-18 11:55 UTC (permalink / raw)
  To: Will Deacon
  Cc: Kees Cook, Jann Horn, Peter Zijlstra, Catalin Marinas,
	linux-kernel, Mark Rutland, Sami Tolvanen, kernel-team,
	Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200515172756.27185-4-will@kernel.org>

On Fri, May 15, 2020 at 06:27:53PM +0100, Will Deacon wrote:
> x18 holds the SCS stack pointer value, so introduce a register alias to
> make this easier to read in assembly code.
> 
> Signed-off-by: Will Deacon <will@kernel.org>

I scanned through arm64 for all instances of x18, and it looks like
you've covered all the relevant uses here. In kvm we save/restore x18 a
bunch becasue it might be a platform register, but we do that
unconditionally and without knowledge of what it contains, so I think
that's fine to leave as-is. Therefore:

Reviewed-by: Mark Rutland <mark.rutland@arm.com>

As an aside, the comment in entry-ftrace.S is now stale where it says
that x18 is safe to clobber. I can send a patch to clean that up, unless
you want to do that yourself.

Mark.

> ---
>  arch/arm64/include/asm/scs.h |  6 ++++--
>  arch/arm64/kernel/entry.S    | 10 +++++-----
>  arch/arm64/kernel/head.S     |  2 +-
>  3 files changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/scs.h b/arch/arm64/include/asm/scs.h
> index 6b8cf4352fe3..d46efdd2060a 100644
> --- a/arch/arm64/include/asm/scs.h
> +++ b/arch/arm64/include/asm/scs.h
> @@ -7,12 +7,14 @@
>  #include <asm/asm-offsets.h>
>  
>  #ifdef CONFIG_SHADOW_CALL_STACK
> +	scs_sp	.req	x18
> +
>  	.macro scs_load tsk, tmp
> -	ldr	x18, [\tsk, #TSK_TI_SCS_SP]
> +	ldr	scs_sp, [\tsk, #TSK_TI_SCS_SP]
>  	.endm
>  
>  	.macro scs_save tsk, tmp
> -	str	x18, [\tsk, #TSK_TI_SCS_SP]
> +	str	scs_sp, [\tsk, #TSK_TI_SCS_SP]
>  	.endm
>  #else
>  	.macro scs_load tsk, tmp
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index cb0516e6f963..741faf0706f1 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -394,7 +394,7 @@ alternative_insn eret, nop, ARM64_UNMAP_KERNEL_AT_EL0
>  	.macro	irq_stack_entry
>  	mov	x19, sp			// preserve the original sp
>  #ifdef CONFIG_SHADOW_CALL_STACK
> -	mov	x24, x18		// preserve the original shadow stack
> +	mov	x24, scs_sp		// preserve the original shadow stack
>  #endif
>  
>  	/*
> @@ -416,7 +416,7 @@ alternative_insn eret, nop, ARM64_UNMAP_KERNEL_AT_EL0
>  
>  #ifdef CONFIG_SHADOW_CALL_STACK
>  	/* also switch to the irq shadow stack */
> -	adr_this_cpu x18, irq_shadow_call_stack, x26
> +	adr_this_cpu scs_sp, irq_shadow_call_stack, x26
>  #endif
>  
>  9998:
> @@ -430,7 +430,7 @@ alternative_insn eret, nop, ARM64_UNMAP_KERNEL_AT_EL0
>  	.macro	irq_stack_exit
>  	mov	sp, x19
>  #ifdef CONFIG_SHADOW_CALL_STACK
> -	mov	x18, x24
> +	mov	scs_sp, x24
>  #endif
>  	.endm
>  
> @@ -1071,9 +1071,9 @@ SYM_CODE_START(__sdei_asm_handler)
>  #ifdef CONFIG_SHADOW_CALL_STACK
>  	/* Use a separate shadow call stack for normal and critical events */
>  	cbnz	w4, 3f
> -	adr_this_cpu dst=x18, sym=sdei_shadow_call_stack_normal, tmp=x6
> +	adr_this_cpu dst=scs_sp, sym=sdei_shadow_call_stack_normal, tmp=x6
>  	b	4f
> -3:	adr_this_cpu dst=x18, sym=sdei_shadow_call_stack_critical, tmp=x6
> +3:	adr_this_cpu dst=scs_sp, sym=sdei_shadow_call_stack_critical, tmp=x6
>  4:
>  #endif
>  
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 2b01c19c5483..1293baddfd20 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -426,7 +426,7 @@ SYM_FUNC_START_LOCAL(__primary_switched)
>  	mov	x29, sp
>  
>  #ifdef CONFIG_SHADOW_CALL_STACK
> -	adr_l	x18, init_shadow_call_stack	// Set shadow call stack
> +	adr_l	scs_sp, init_shadow_call_stack	// Set shadow call stack
>  #endif
>  
>  	str_l	x21, __fdt_pointer, x5		// Save FDT pointer
> -- 
> 2.26.2.761.g0e0b3e54be-goog
> 

_______________________________________________
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 0/1] net: ethernet: stmmac: simplify phy modes management for stm32
From: Christophe ROULLIER @ 2020-05-18 12:02 UTC (permalink / raw)
  To: robh@kernel.org, davem@davemloft.net, joabreu@synopsys.com,
	mark.rutland@arm.com, mcoquelin.stm32@gmail.com, Alexandre TORGUE,
	Peppe CAVALLARO
  Cc: devicetree@vger.kernel.org, andrew@lunn.ch,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20200427100038.19252-1-christophe.roullier@st.com>

Hi,

Just a "gentleman ping"

Regards,

Christophe.

On 27/04/2020 12:00, Christophe Roullier wrote:
> No new feature, just to simplify stm32 part to be easier to use.
> Add by default all Ethernet clocks in DT, and activate or not in function
> of phy mode, clock frequency, if property "st,ext-phyclk" is set or not.
> Keep backward compatibility
>
> version 3:
> Add acked from Alexandre Torgue
> Rebased on top of v5.7-rc2
>
> Christophe Roullier (1):
>    net: ethernet: stmmac: simplify phy modes management for stm32
>
>   .../net/ethernet/stmicro/stmmac/dwmac-stm32.c | 74 +++++++++++--------
>   1 file changed, 44 insertions(+), 30 deletions(-)
>
_______________________________________________
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 4/6] scs: Move scs_overflow_check() out of architecture code
From: Mark Rutland @ 2020-05-18 12:12 UTC (permalink / raw)
  To: Will Deacon
  Cc: Kees Cook, Jann Horn, Peter Zijlstra, Catalin Marinas,
	linux-kernel, Mark Rutland, Sami Tolvanen, kernel-team,
	Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200515172756.27185-5-will@kernel.org>

On Fri, May 15, 2020 at 06:27:54PM +0100, Will Deacon wrote:
> There is nothing architecture-specific about scs_overflow_check() as
> it's just a trivial wrapper around scs_corrupted().
> 
> For parity with task_stack_end_corrupted(), rename scs_corrupted() to
> task_scs_end_corrupted() and call it from schedule_debug() when
> CONFIG_SCHED_STACK_END_CHECK_is enabled. Finally, remove the unused
> scs_overflow_check() function entirely.
> 
> This has absolutely no impact on architectures that do not support SCS
> (currently arm64 only).
> 
> Signed-off-by: Will Deacon <will@kernel.org>

Pulling this out of arch code seems sane to me, and the arch-specific
chanes look sound. However, I have a concern with the changes within the
scheduler context-switch.

> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index a35d3318492c..56be4cbf771f 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -52,7 +52,6 @@
>  #include <asm/mmu_context.h>
>  #include <asm/processor.h>
>  #include <asm/pointer_auth.h>
> -#include <asm/scs.h>
>  #include <asm/stacktrace.h>
>  
>  #if defined(CONFIG_STACKPROTECTOR) && !defined(CONFIG_STACKPROTECTOR_PER_TASK)
> @@ -516,7 +515,6 @@ __notrace_funcgraph struct task_struct *__switch_to(struct task_struct *prev,
>  	entry_task_switch(next);
>  	uao_thread_switch(next);
>  	ssbs_thread_switch(next);
> -	scs_overflow_check(next);

Prior to this patch, we'd never switch to a task whose SCS had already
been corrupted.

With this patch, we only check that when switching away from a task, and
only when CONFIG_SCHED_STACK_END_CHECK is selected, which at first
glance seems to weaken that.

Arguably:

* If the next task's SCS was corrupted by that task while it was
  running, we had already lost at that point.

* If the next task's SCS was corrupted by another task, then that could
  also happen immediately after the check (though timing to avoid the
  check but affect the process could be harder).

... and a VMAP'd SCS would be much nicer in this regard.

Do we think this is weakening the check, or do we think it wasn't all
that helpful to begin with?

Mark.

>  
>  	/*
>  	 * Complete any pending TLB or cache maintenance on this CPU in case
> diff --git a/arch/arm64/kernel/scs.c b/arch/arm64/kernel/scs.c
> index adc97f826fab..955875dff9e1 100644
> --- a/arch/arm64/kernel/scs.c
> +++ b/arch/arm64/kernel/scs.c
> @@ -6,7 +6,7 @@
>   */
>  
>  #include <linux/percpu.h>
> -#include <asm/scs.h>
> +#include <linux/scs.h>
>  
>  /* Allocate a static per-CPU shadow stack */
>  #define DEFINE_SCS(name)						\
> diff --git a/include/linux/scs.h b/include/linux/scs.h
> index 0eb2485ef832..2fd3df50e93e 100644
> --- a/include/linux/scs.h
> +++ b/include/linux/scs.h
> @@ -47,7 +47,7 @@ static inline unsigned long *__scs_magic(void *s)
>  	return (unsigned long *)(s + SCS_SIZE) - 1;
>  }
>  
> -static inline bool scs_corrupted(struct task_struct *tsk)
> +static inline bool task_scs_end_corrupted(struct task_struct *tsk)
>  {
>  	unsigned long *magic = __scs_magic(task_scs(tsk));
>  	unsigned long sz = task_scs_sp(tsk) - task_scs(tsk);
> @@ -60,8 +60,8 @@ static inline bool scs_corrupted(struct task_struct *tsk)
>  static inline void scs_init(void) {}
>  static inline void scs_task_reset(struct task_struct *tsk) {}
>  static inline int scs_prepare(struct task_struct *tsk, int node) { return 0; }
> -static inline bool scs_corrupted(struct task_struct *tsk) { return false; }
>  static inline void scs_release(struct task_struct *tsk) {}
> +static inline bool task_scs_end_corrupted(struct task_struct *tsk) { return false; }
>  
>  #endif /* CONFIG_SHADOW_CALL_STACK */
>  
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 934e03cfaec7..a1d815a11b90 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3878,6 +3878,9 @@ static inline void schedule_debug(struct task_struct *prev, bool preempt)
>  #ifdef CONFIG_SCHED_STACK_END_CHECK
>  	if (task_stack_end_corrupted(prev))
>  		panic("corrupted stack end detected inside scheduler\n");
> +
> +	if (task_scs_end_corrupted(prev))
> +		panic("corrupted shadow stack detected inside scheduler\n");
>  #endif
>  
>  #ifdef CONFIG_DEBUG_ATOMIC_SLEEP
> diff --git a/kernel/scs.c b/kernel/scs.c
> index aea841cd7586..faf0ecd7b893 100644
> --- a/kernel/scs.c
> +++ b/kernel/scs.c
> @@ -98,7 +98,8 @@ void scs_release(struct task_struct *tsk)
>  	if (!s)
>  		return;
>  
> -	WARN(scs_corrupted(tsk), "corrupted shadow stack detected when freeing task\n");
> +	WARN(task_scs_end_corrupted(tsk),
> +	     "corrupted shadow stack detected when freeing task\n");
>  	scs_check_usage(tsk);
>  	scs_free(s);
>  }
> -- 
> 2.26.2.761.g0e0b3e54be-goog
> 

_______________________________________________
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 6/6] scs: Move DEFINE_SCS macro into core code
From: Mark Rutland @ 2020-05-18 12:14 UTC (permalink / raw)
  To: Will Deacon
  Cc: Kees Cook, Jann Horn, Peter Zijlstra, Catalin Marinas,
	linux-kernel, Mark Rutland, Sami Tolvanen, kernel-team,
	Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200515172756.27185-7-will@kernel.org>

On Fri, May 15, 2020 at 06:27:56PM +0100, Will Deacon wrote:
> Defining static shadow call stacks is not architecture-specific, so move
> the DEFINE_SCS() macro into the core header file.
> 
> Signed-off-by: Will Deacon <will@kernel.org>

I think that we'll have to pull this back into arch code if/when we deal
with VMAP'd stacks, so I'm not sure this is worthwhile given the
diffstat is balanced.

Mark.

> ---
>  arch/arm64/kernel/scs.c | 4 ----
>  include/linux/scs.h     | 4 ++++
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/kernel/scs.c b/arch/arm64/kernel/scs.c
> index 955875dff9e1..e8f7ff45dd8f 100644
> --- a/arch/arm64/kernel/scs.c
> +++ b/arch/arm64/kernel/scs.c
> @@ -8,10 +8,6 @@
>  #include <linux/percpu.h>
>  #include <linux/scs.h>
>  
> -/* Allocate a static per-CPU shadow stack */
> -#define DEFINE_SCS(name)						\
> -	DEFINE_PER_CPU(unsigned long [SCS_SIZE/sizeof(long)], name)	\
> -
>  DEFINE_SCS(irq_shadow_call_stack);
>  
>  #ifdef CONFIG_ARM_SDE_INTERFACE
> diff --git a/include/linux/scs.h b/include/linux/scs.h
> index 2fd3df50e93e..6dec390cf154 100644
> --- a/include/linux/scs.h
> +++ b/include/linux/scs.h
> @@ -26,6 +26,10 @@
>  /* An illegal pointer value to mark the end of the shadow stack. */
>  #define SCS_END_MAGIC		(0x5f6UL + POISON_POINTER_DELTA)
>  
> +/* Allocate a static per-CPU shadow stack */
> +#define DEFINE_SCS(name)						\
> +	DEFINE_PER_CPU(unsigned long [SCS_SIZE/sizeof(long)], name)	\
> +
>  #define task_scs(tsk)		(task_thread_info(tsk)->scs_base)
>  #define task_scs_sp(tsk)	(task_thread_info(tsk)->scs_sp)
>  
> -- 
> 2.26.2.761.g0e0b3e54be-goog
> 

_______________________________________________
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 5/6] scs: Remove references to asm/scs.h from core code
From: Mark Rutland @ 2020-05-18 12:15 UTC (permalink / raw)
  To: Will Deacon
  Cc: Kees Cook, Jann Horn, Peter Zijlstra, Catalin Marinas,
	linux-kernel, Mark Rutland, Sami Tolvanen, kernel-team,
	Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200515172756.27185-6-will@kernel.org>

On Fri, May 15, 2020 at 06:27:55PM +0100, Will Deacon wrote:
> asm/scs.h is no longer needed by the core code, so remove a redundant
> header inclusion and update the stale Kconfig text.
> 
> Signed-off-by: Will Deacon <will@kernel.org>

With the corruption checks moved out of arch code this looks sound to
me, so modulo my comments on the prior patch, assuming we factor that
out:

Reviewed-by: Mark Rutland <mark.rutland@arm.com>

Mark.

> ---
>  arch/Kconfig | 4 ++--
>  kernel/scs.c | 1 -
>  2 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 45dfca9a98d3..2e6f843d87c4 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -537,8 +537,8 @@ config ARCH_SUPPORTS_SHADOW_CALL_STACK
>  	bool
>  	help
>  	  An architecture should select this if it supports Clang's Shadow
> -	  Call Stack, has asm/scs.h, and implements runtime support for shadow
> -	  stack switching.
> +	  Call Stack and implements runtime support for shadow stack
> +	  switching.
>  
>  config SHADOW_CALL_STACK
>  	bool "Clang Shadow Call Stack"
> diff --git a/kernel/scs.c b/kernel/scs.c
> index faf0ecd7b893..222a7a9ad543 100644
> --- a/kernel/scs.c
> +++ b/kernel/scs.c
> @@ -10,7 +10,6 @@
>  #include <linux/scs.h>
>  #include <linux/slab.h>
>  #include <linux/vmstat.h>
> -#include <asm/scs.h>
>  
>  static struct kmem_cache *scs_cache;
>  
> -- 
> 2.26.2.761.g0e0b3e54be-goog
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [RFC PATCH v3 2/2] arm64: tlb: Use the TLBI RANGE feature in arm64
From: Zhenyu Ye @ 2020-05-18 12:21 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: linux-arch, suzuki.poulose, maz, linux-kernel, xiexiangyou,
	steven.price, zhangshaokun, linux-mm, arm, prime.zeng, guohanjun,
	olof, kuhn.chenqun, will, linux-arm-kernel
In-Reply-To: <20200514152840.GC1907@gaia>

Hi Catalin,

Thanks for your review.

On 2020/5/14 23:28, Catalin Marinas wrote:
> Hi Zhenyu,
> 
> On Tue, Apr 14, 2020 at 07:28:35PM +0800, Zhenyu Ye wrote:
>> diff --git a/arch/arm64/include/asm/tlb.h b/arch/arm64/include/asm/tlb.h
>> index b76df828e6b7..3a1816770bd1 100644
>> --- a/arch/arm64/include/asm/tlb.h
>> +++ b/arch/arm64/include/asm/tlb.h
>> @@ -38,7 +38,12 @@ static inline void tlb_flush(struct mmu_gather *tlb)
>>  		return;
>>  	}
>>  
>> -	__flush_tlb_range(&vma, tlb->start, tlb->end, stride, last_level);
>> +	if (cpus_have_const_cap(ARM64_HAS_TLBI_RANGE))
>> +		__flush_tlb_range_directly(&vma, tlb->start, tlb->end,
>> +					   stride, last_level);
>> +	else
>> +		__flush_tlb_range(&vma, tlb->start, tlb->end,
>> +				  stride, last_level);
> 
> I think you could move such check in __flush_tlb_range() and avoid
> cpus_have_const_cap() in two places. More on this below.
> 

Then we must mix the __flush_tlb_range() and the _directly one together.
I'm worried this will make the code very complicated.  See the end for
details.

>> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
>> index bc3949064725..a482188ea563 100644
>> --- a/arch/arm64/include/asm/tlbflush.h
>> +++ b/arch/arm64/include/asm/tlbflush.h
>> @@ -59,6 +59,44 @@
>>  		__ta;						\
>>  	})
>>  
>> +/*
>> + * This macro creates a properly formatted VA operand for the TLBI RANGE.
>> + * The value bit assignments are:
>> + *
>> + * +----------+------+-------+-------+-------+----------------------+
>> + * |   ASID   |  TG  | SCALE |  NUM  |  TTL  |        BADDR         |
>> + * +-----------------+-------+-------+-------+----------------------+
>> + * |63      48|47  46|45   44|43   39|38   37|36                   0|
>> + *
>> + * The address range is determined by below formula:
>> + * [BADDR, BADDR + (NUM + 1) * 2^(5*SCALE + 1) * PAGESIZE)
>> + *
>> + */
>> +#define __TLBI_VADDR_RANGE(addr, asid, tg, scale, num, ttl)	\
>> +	({							\
>> +		unsigned long __ta = (addr) >> PAGE_SHIFT;	\
>> +		__ta &= GENMASK_ULL(36, 0);			\
>> +		__ta |= (unsigned long)(ttl) << 37;		\
>> +		__ta |= (unsigned long)(num) << 39;		\
>> +		__ta |= (unsigned long)(scale) << 44;		\
>> +		__ta |= (unsigned long)(tg) << 46;		\
>> +		__ta |= (unsigned long)(asid) << 48;		\
>> +		__ta;						\
>> +	})
>> +
>> +#define TLB_RANGE_MASK_SHIFT 5
>> +#define TLB_RANGE_MASK GENMASK_ULL(TLB_RANGE_MASK_SHIFT - 1, 0)
>> +
>> +/*
>> + * __TG defines translation granule of the system, which is defined by
>> + * PAGE_SHIFT.  Used by TTL.
>> + *  - 4KB	: 1
>> + *  - 16KB	: 2
>> + *  - 64KB	: 3
>> + */
>> +#define __TG	((PAGE_SHIFT - 12) / 2 + 1)
> 
> I don't think we need __TLBI_VADDR_RANGE to take a tg argument since
> it's always the same.
> 

OK.

>> +
>> +
>>  /*
>>   *	TLB Invalidation
>>   *	================
>> @@ -171,12 +209,83 @@ static inline void flush_tlb_page(struct vm_area_struct *vma,
>>  	dsb(ish);
>>  }
>>  
>> +/* The maximum range size of one TLBI-RANGE instruction */
>> +#define MAX_TLBI_RANGE_SIZE	(1UL << 21)
> 
> Nitpick: call this MAX_TLBI_RANGE_PAGES as that's not an address range.
> 
> It may be useful to have a macro for the range here, something like:
> 
> #define __TLBI_PAGES(num, scale)	((num + 1) << (5 * scale + 1))
> 
> and define MAX_TLBI_RANGE_PAGES in terms of this macro as
> __TLBI_PAGES(31, 3).
> 

OK, thanks for your great suggestion.

>> +
>> +/*
>> + * This interface uses the *rvale1is* instruction to flush TLBs
>> + * in [start, end) directly.
>> + * This instruction is supported from ARM v8.4.
>> + */
>> +static inline void __flush_tlb_range_directly(struct vm_area_struct *vma,
>> +				unsigned long start, unsigned long end,
>> +				unsigned long stride, bool last_level)
>> +{
>> +	int num = 0;
>> +	int scale = 0;
>> +	unsigned long asid = ASID(vma->vm_mm);
>> +	unsigned long addr = 0;
>> +	unsigned long range_size;
>> +
>> +	start = round_down(start, stride);
>> +	end = round_up(end, stride);
>> +	range_size = (end - start) >> PAGE_SHIFT;
>> +
>> +	if (range_size > MAX_TLBI_RANGE_SIZE) {
>> +		flush_tlb_mm(vma->vm_mm);
>> +		return;
>> +	}
>> +
>> +	dsb(ishst);
>> +
>> +	/*
>> +	 * The minimum size of TLB RANGE is 2 PAGE;
>> +	 * Use normal TLB instruction to handle odd PAGEs
> 
> Nitpick: no need to capitalise PAGE.
> 

OK.

>> +	 */
>> +	if (range_size % 2 == 1) {
>> +		addr = __TLBI_VADDR(start, asid);
>> +		if (last_level) {
>> +			__tlbi(vale1is, addr);
>> +			__tlbi_user(vale1is, addr);
>> +		} else {
>> +			__tlbi(vae1is, addr);
>> +			__tlbi_user(vae1is, addr);
>> +		}
>> +		start += 1 << PAGE_SHIFT;
>> +		range_size -= 1;
>> +	}
>> +
>> +	range_size >>= 1;
>> +	while (range_size > 0) {
>> +		num = (range_size & TLB_RANGE_MASK) - 1;
>> +		if (num >= 0) {
>> +			addr = __TLBI_VADDR_RANGE(start, asid, __TG,
>> +						  scale, num, 0);
>> +			if (last_level) {
>> +				__tlbi(rvale1is, addr);
>> +				__tlbi_user(rvale1is, addr);
>> +			} else {
>> +				__tlbi(rvae1is, addr);
>> +				__tlbi_user(rvae1is, addr);
>> +			}
>> +			start += (num + 1) << (5 * scale + 1) << PAGE_SHIFT;
> 
> You could use the __TLBI_PAGES macro I proposed above.
> 

OK.

>> +		}
>> +		scale++;
>> +		range_size >>= TLB_RANGE_MASK_SHIFT;
>> +	}
> 
> So, you start from scale 0 and increment it until you reach the maximum.
> I think (haven't done the maths on paper) you could also start from the
> top with something like scale = ilog2(range_size) / 5. Not sure it's
> significantly better though, maybe avoiding the loop 3 times if your
> range is 2MB (which happens with huge pages).
> 

This optimization is only effective when the range is a multiple of 256KB
(when the page size is 4KB), and I'm worried about the performance
of ilog2().  I traced the __flush_tlb_range() last year and found that in
most cases the range is less than 256K (see details in [1]).

I will test the performance of your suggestion and then reply you again
here.

> Anyway, I think it would be more efficient if we combine the
> __flush_tlb_range() and the _directly one into the same function with a
> single loop for both. For example, if the stride is 2MB already, we can
> handle this with a single classic TLBI without all the calculations for
> the range operation. The hardware may also handle this better since the
> software already told it there can be only one entry in that 2MB range.
> So each loop iteration could figure which operation to use based on
> cpucaps, TLBI range ops, stride and reduce range_size accordingly.
> 

Summarize your suggestion in one sentence: use 'stride' to optimize the
preformance of TLBI.  This can also be done by dividing into two functions,
and this should indeed be taken into account in the TLBI RANGE feature.

But if we figure which operation to use based on cpucaps in each loop
iteration, then cpus_have_const_cap() will be called frequently, which
may affect performance of TLBI.  In my opinion, we should do as few
judgments as possible in the loop, so judge the cpucaps outside the
loop maybe a good choice.


[1] https://lkml.org/lkml/2019/11/11/593

Thanks,
Zhenyu


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCHv2 0/7] Support inhibiting input devices
From: Hans de Goede @ 2020-05-18 12:24 UTC (permalink / raw)
  To: Andrzej Pietrasiewicz, linux-input, linux-acpi, linux-iio,
	linux-arm-kernel, linux-samsung-soc, linux-tegra, patches,
	ibm-acpi-devel, platform-driver-x86
  Cc: Nick Dyer, Benjamin Tissoires, Laxman Dewangan,
	Peter Meerwald-Stadler, kernel, Fabio Estevam, Lars-Peter Clausen,
	Krzysztof Kozlowski, Jonathan Hunter, Kukjin Kim, NXP Linux Team,
	Sylvain Lemieux, Len Brown, Peter Hutterer, Michael Hennerich,
	Sascha Hauer, Henrique de Moraes Holschuh, Vladimir Zapolskiy,
	Barry Song, Ferruh Yigit, Dmitry Torokhov, Rafael J . Wysocki,
	Thierry Reding, Sangwon Jee, Pengutronix Kernel Team,
	Hartmut Knaack, Shawn Guo, Jonathan Cameron
In-Reply-To: <e6030957-97dc-5b04-7855-bc14a78164c8@collabora.com>

Hi,

On 5/18/20 12:48 PM, Andrzej Pietrasiewicz wrote:
> Hi Hans,
> 
> W dniu 15.05.2020 o 20:19, Hans de Goede pisze:
>> Hi Andrezj,
>>
>> On 5/15/20 6:49 PM, Andrzej Pietrasiewicz wrote:
>>> Userspace might want to implement a policy to temporarily disregard input
>>> from certain devices, including not treating them as wakeup sources.
>>>
>>> An example use case is a laptop, whose keyboard can be folded under the
>>> screen to create tablet-like experience. The user then must hold the laptop
>>> in such a way that it is difficult to avoid pressing the keyboard keys. It
>>> is therefore desirable to temporarily disregard input from the keyboard,
>>> until it is folded back. This obviously is a policy which should be kept
>>> out of the kernel, but the kernel must provide suitable means to implement
>>> such a policy.
>>
>> Actually libinput already binds together (inside libinput) SW_TABLET_MODE
>> generating evdev nodes and e.g. internal keyboards on devices with 360°
>> hinges for this reason. libinput simply closes the /dev/input/event#
>> node when folded and re-opens it when the keyboard should become active
>> again. Thus not only suppresses events but allows e.g. touchpads to
>> enter runtime suspend mode which saves power. Typically closing the
>> /dev/input/event# node will also disable the device as wakeup source.
>>
>> So I wonder what this series actually adds for functionality for
>> userspace which can not already be achieved this way?
>>
>> I also noticed that you keep the device open (do not call the
>> input_device's close callback) when inhibited and just throw away
> 
> I'm not sure if I understand you correctly, it is called:
> 
> +static inline void input_stop(struct input_dev *dev)
> +{
> +    if (dev->poller)
> +        input_dev_poller_stop(dev->poller);
> +    if (dev->close)
> +        dev->close(dev);
>                  ^^^^^^^^^^^^^^^^
> +static int input_inhibit(struct input_dev *dev)
> +{
> +    int ret = 0;
> +
> +    mutex_lock(&dev->mutex);
> +
> +    if (dev->inhibited)
> +        goto out;
> +
> +    if (dev->users) {
> +        if (dev->inhibit) {
> +            ret = dev->inhibit(dev);
> +            if (ret)
> +                goto out;
> +        }
> +        input_stop(dev);
>                  ^^^^^^^^^^^^^^^^
> 
> It will not be called when dev->users is zero, but if it is zero,
> then nobody has opened the device yet so there is nothing to close.

Ah, I missed that.

So if the device implements the inhibit call back then on
inhibit it will get both the inhibit and close callback called?

And what happens if the last user goes away and the device
is not inhibited?

I'm trying to understand here what the difference between the 2
is / what the goal of having a separate inhibit callback ?

IOW is there something which we want to do on close when
the close is being done to inhibit the device, which we do
not want to do on a normal close ?

Regards,

Hans



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [RFC PATCH v3 1/2] arm64: tlb: Detect the ARMv8.4 TLBI RANGE feature
From: Zhenyu Ye @ 2020-05-18 12:29 UTC (permalink / raw)
  To: Anshuman Khandual, Mark Rutland
  Cc: linux-arch, maz, suzuki.poulose, catalin.marinas, linux-kernel,
	xiexiangyou, steven.price, zhangshaokun, linux-mm, arm,
	prime.zeng, guohanjun, olof, kuhn.chenqun, will, linux-arm-kernel
In-Reply-To: <4d8cb48c-4f47-d966-f29b-3343bd966c5f@arm.com>

Hi Anshuman,

On 2020/5/18 12:22, Anshuman Khandual wrote:
>>>>  static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
>>>>  	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_RNDR_SHIFT, 4, 0),
>>>> +	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_TLBI_RANGE_SHIFT, 4, 0),
> 
> Hello Zhenyu,
> 
> This is already being added through another patch [1] in a series [2] which primarily
> has cpufeature changes. I will soon update the series making this feature FTR_HIDDEN.
> 
> [1] https://patchwork.kernel.org/patch/11523881/
> [2] https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=281211
> 
> I am planning to respin the series (V4) based on arm64 tree (for-next/cpufeature). So
> could you please rebase this patch (probably dropping cpufeature related changes) on
> upcoming V4, so that all the changes will be based on arm64 tree (for-next/cpufeature).
> 
> - Anshuman
> 

OK, I will rebase my patch based on your V4.

Zhenyu


_______________________________________________
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 1/3] mm/memory-failure: Add memory_failure_queue_kick()
From: Rafael J. Wysocki @ 2020-05-18 12:45 UTC (permalink / raw)
  To: James Morse
  Cc: Mark Rutland, Tony Luck, linux-acpi, Catalin Marinas, Xie XiuQi,
	linux-mm, Tyler Baicar, Borislav Petkov, Naoya Horiguchi,
	Will Deacon, Andrew Morton, linux-arm-kernel, Len Brown
In-Reply-To: <20200501164543.24423-2-james.morse@arm.com>

On Friday, May 1, 2020 6:45:41 PM CEST James Morse wrote:
> The GHES code calls memory_failure_queue() from IRQ context to schedule
> work on the current CPU so that memory_failure() can sleep.
> 
> For synchronous memory errors the arch code needs to know any signals
> that memory_failure() will trigger are pending before it returns to
> user-space, possibly when exiting from the IRQ.
> 
> Add a helper to kick the memory failure queue, to ensure the scheduled
> work has happened. This has to be called from process context, so may
> have been migrated from the original cpu. Pass the cpu the work was
> queued on.
> 
> Change memory_failure_work_func() to permit being called on the 'wrong'
> cpu.
> 
> Signed-off-by: James Morse <james.morse@arm.com>
> Tested-by: Tyler Baicar <baicar@os.amperecomputing.com>
> ---
>  include/linux/mm.h  |  1 +
>  mm/memory-failure.c | 15 ++++++++++++++-
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 5a323422d783..c606dbbfa5e1 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -3012,6 +3012,7 @@ enum mf_flags {
>  };
>  extern int memory_failure(unsigned long pfn, int flags);
>  extern void memory_failure_queue(unsigned long pfn, int flags);
> +extern void memory_failure_queue_kick(int cpu);
>  extern int unpoison_memory(unsigned long pfn);
>  extern int get_hwpoison_page(struct page *page);
>  #define put_hwpoison_page(page)	put_page(page)
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index a96364be8ab4..c4afb407bf0f 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1493,7 +1493,7 @@ static void memory_failure_work_func(struct work_struct *work)
>  	unsigned long proc_flags;
>  	int gotten;
>  
> -	mf_cpu = this_cpu_ptr(&memory_failure_cpu);
> +	mf_cpu = container_of(work, struct memory_failure_cpu, work);
>  	for (;;) {
>  		spin_lock_irqsave(&mf_cpu->lock, proc_flags);
>  		gotten = kfifo_get(&mf_cpu->fifo, &entry);
> @@ -1507,6 +1507,19 @@ static void memory_failure_work_func(struct work_struct *work)
>  	}
>  }
>  
> +/*
> + * Process memory_failure work queued on the specified CPU.
> + * Used to avoid return-to-userspace racing with the memory_failure workqueue.
> + */
> +void memory_failure_queue_kick(int cpu)
> +{
> +	struct memory_failure_cpu *mf_cpu;
> +
> +	mf_cpu = &per_cpu(memory_failure_cpu, cpu);
> +	cancel_work_sync(&mf_cpu->work);
> +	memory_failure_work_func(&mf_cpu->work);
> +}
> +
>  static int __init memory_failure_init(void)
>  {
>  	struct memory_failure_cpu *mf_cpu;
> 

I could apply this provided an ACK from the mm people.

Thanks!




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH] ARM: dts: imx: make src node name generic
From: Anson Huang @ 2020-05-18 12:39 UTC (permalink / raw)
  To: robh+dt, shawnguo, s.hauer, kernel, festevam, devicetree,
	linux-arm-kernel, linux-kernel
  Cc: Linux-imx

Node name should be generic, use "reset-controller" instead of "src" for
i.MX6/i.MX7 SoCs src nodes.

Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
 arch/arm/boot/dts/imx6qdl.dtsi | 2 +-
 arch/arm/boot/dts/imx6sl.dtsi  | 2 +-
 arch/arm/boot/dts/imx6sx.dtsi  | 2 +-
 arch/arm/boot/dts/imx6ul.dtsi  | 2 +-
 arch/arm/boot/dts/imx7s.dtsi   | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 1763c2b..39d4afd 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -858,7 +858,7 @@
 				interrupts = <0 57 IRQ_TYPE_LEVEL_HIGH>;
 			};
 
-			src: src@20d8000 {
+			src: reset-controller@20d8000 {
 				compatible = "fsl,imx6q-src", "fsl,imx51-src";
 				reg = <0x020d8000 0x4000>;
 				interrupts = <0 91 IRQ_TYPE_LEVEL_HIGH>,
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index fcb84fe..911d8cf 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -678,7 +678,7 @@
 				interrupts = <0 57 IRQ_TYPE_LEVEL_HIGH>;
 			};
 
-			src: src@20d8000 {
+			src: reset-controller@20d8000 {
 				compatible = "fsl,imx6sl-src", "fsl,imx51-src";
 				reg = <0x020d8000 0x4000>;
 				interrupts = <0 91 IRQ_TYPE_LEVEL_HIGH>,
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index d6f8317..e031337 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -754,7 +754,7 @@
 				interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
 			};
 
-			src: src@20d8000 {
+			src: reset-controller@20d8000 {
 				compatible = "fsl,imx6sx-src", "fsl,imx51-src";
 				reg = <0x020d8000 0x4000>;
 				interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>,
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 2ccf67c..35e7301 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -676,7 +676,7 @@
 				interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
 			};
 
-			src: src@20d8000 {
+			src: reset-controller@20d8000 {
 				compatible = "fsl,imx6ul-src", "fsl,imx51-src";
 				reg = <0x020d8000 0x4000>;
 				interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>,
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 76e3ffb..8bac491 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -624,7 +624,7 @@
 				clock-names = "ckil", "osc";
 			};
 
-			src: src@30390000 {
+			src: reset-controller@30390000 {
 				compatible = "fsl,imx7d-src", "syscon";
 				reg = <0x30390000 0x10000>;
 				interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
-- 
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

* Re: [PATCH v6 09/10] arm64: efi: Export screen_info
From: Ard Biesheuvel @ 2020-05-18 12:51 UTC (permalink / raw)
  To: Nikhil Mahale
  Cc: Mark Rutland, linux-arch, linux-hyperv@vger.kernel.org, linux-efi,
	Boqun Feng, Arnd Bergmann, gregkh, Catalin Marinas, Jason Wang,
	linux-kernel@vger.kernel.org, Michael Kelley,
	marcelo.cerri@canonical.com, olaf@aepfle.de, Marc Zyngier,
	Andy Whitcroft, vkuznets, KY Srinivasan, Will Deacon,
	Sunil Muthuswamy, Linux ARM
In-Reply-To: <4202ea20-6e51-31d3-44b1-3861798a8158@nvidia.com>

On Mon, 18 May 2020 at 06:25, Nikhil Mahale <nmahale@nvidia.com> wrote:
>
> On 5/13/20 7:56 PM, Nikhil Mahale wrote:
> > On 3/20/20 3:16 AM, Michael Kelley wrote:
> >> From: Arnd Bergmann <arnd@arndb.de> Sent: Wednesday, March 18, 2020 2:27 AM
> >>>
> >>> On Wed, Mar 18, 2020 at 1:18 AM Michael Kelley <mikelley@microsoft.com> wrote:
> >>>> From: Arnd Bergmann <arnd@arndb.de>
> >>>>> On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <mikelley@microsoft.com> wrote:
> >>>>>>
> >>>>>> The Hyper-V frame buffer driver may be built as a module, and
> >>>>>> it needs access to screen_info. So export screen_info.
> >>>>>>
> >>>>>> Signed-off-by: Michael Kelley <mikelley@microsoft.com>
> >>>>>
> >>>>> Is there any chance of using a more modern KMS based driver for the screen
> >>>>> than the old fbdev subsystem? I had hoped to one day completely remove
> >>>>> support for the old CONFIG_VIDEO_FBDEV and screen_info from modern
> >>>>> architectures.
> >>>>>
> >>>>
> >>>> The current hyperv_fb.c driver is all we have today for the synthetic Hyper-V
> >>>> frame buffer device.  That driver builds and runs on both ARM64 and x86.
> >>>>
> >>>> I'm not knowledgeable about video/graphics drivers, but when you
> >>>> say "a more modern KMS based driver", are you meaning one based on
> >>>> DRM & KMS?  Does DRM make sense for a "dumb" frame buffer device?
> >>>> Are there any drivers that would be a good pattern to look at?
> >>>
> >>> It used to be a lot harder to write a DRM driver compared to an fbdev
> >>> driver, but this has changed to the opposite over the years.
> >>>
> >>> A fairly minimal example would be drivers/gpu/drm/pl111/pl111_drv.c
> >>> or anything in drivers/gpu/drm/tiny/, but you may want to look at the
> >>> other hypervisor platforms first, i.e drivers/gpu/drm/virtio/virtgpu_drv.c,
> >>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c, drivers/gpu/drm/xen/xen_drm_front.c,
> >>> drivers/gpu/drm/qxl/qxl_drv.c, and drivers/gpu/drm/bochs/bochs_drv.c.
> >>>
> >>
> >> Thanks for the pointers, especially for the other hypervisors.
> >>
> > Sorry if anybody in 'to' or 'cc' is receiving this reply multiple times.
> > I had configured by email client incorrectly to reply.
> >
> > screen_info is still useful with a modern KMS-based driver.  It exposes
> > the mode parameters that the GOP driver chose.  This information is
> > needed to implement seamless or glitchless boot, by both ensuring that
> > the scanout parameters don't change and being able to read back the
> > scanout image to populate the initial contents of the new surface.
> >
> > This works today on arches which implement (U)EFI and export
> > screen_info, including x86 and powerpc, but doesn't work on arm or
> > arm64.  As arm64 systems that implement UEFI with real GOP drivers
> > become more prevalent, it would be nice to be have these features there
> > as well.
>
> In addition to this, even if a driver doesn't implement a framebuffer
> console, or if it does but has an option to disable it, the driver still
> needs to know whether the EFI console is using resources on the GPU so
> it can avoid clobbering them. For example screen_info provides information
> like offset and size of EFI console, using this information driver can
> reserve memory used by console and prevent corruption on it.
>
> I think arm64 should export screen_info.
>

If there are reasons why KMS or fbdev drivers may need to access the
information in screen_info, it should be exported. I don't think that
is under debate here.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH] arm: uprobes: Don't hook on thumb instructions
From: Fredrik Strupe @ 2020-05-18 12:59 UTC (permalink / raw)
  To: Russell King, Rabin Vincent, David A . Long, linux-arm-kernel,
	linux-kernel
  Cc: Fredrik Strupe

Since uprobes is not supported for thumb, check that the thumb bit is
not set when matching the uprobes instruction hooks.

The Arm UDF instructions used for uprobes triggering
(UPROBE_SWBP_ARM_INSN and UPROBE_SS_ARM_INSN) coincidentally share the
same encoding as a pair of unallocated 32-bit thumb instructions (not
UDF) when the condition code is 0b1111 (0xf). This in effect makes it
possible to trigger the uprobes functionality from thumb, and at that
using two unallocated instructions which are not permanently undefined.

Signed-off-by: Fredrik Strupe <fredrik@strupe.net>
Fixes: c7edc9e326d5 ("ARM: add uprobes support")
---
 arch/arm/probes/uprobes/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/probes/uprobes/core.c b/arch/arm/probes/uprobes/core.c
index c4b49b322e8a..f5f790c6e5f8 100644
--- a/arch/arm/probes/uprobes/core.c
+++ b/arch/arm/probes/uprobes/core.c
@@ -204,7 +204,7 @@ unsigned long uprobe_get_swbp_addr(struct pt_regs *regs)
 static struct undef_hook uprobes_arm_break_hook = {
 	.instr_mask	= 0x0fffffff,
 	.instr_val	= (UPROBE_SWBP_ARM_INSN & 0x0fffffff),
-	.cpsr_mask	= MODE_MASK,
+	.cpsr_mask	= (PSR_T_BIT | MODE_MASK),
 	.cpsr_val	= USR_MODE,
 	.fn		= uprobe_trap_handler,
 };
@@ -212,7 +212,7 @@ static struct undef_hook uprobes_arm_break_hook = {
 static struct undef_hook uprobes_arm_ss_hook = {
 	.instr_mask	= 0x0fffffff,
 	.instr_val	= (UPROBE_SS_ARM_INSN & 0x0fffffff),
-	.cpsr_mask	= MODE_MASK,
+	.cpsr_mask	= (PSR_T_BIT | MODE_MASK),
 	.cpsr_val	= USR_MODE,
 	.fn		= uprobe_trap_handler,
 };
-- 
2.20.1


_______________________________________________
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: [PATCH 3/6] arm64: scs: Use 'scs_sp' register alias for x18
From: Will Deacon @ 2020-05-18 13:03 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Mark Rutland, Kees Cook, Jann Horn, Peter Zijlstra,
	Catalin Marinas, linux-kernel, Sami Tolvanen, kernel-team,
	Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200518115547.GC1957@C02TD0UTHF1T.local>

On Mon, May 18, 2020 at 12:55:47PM +0100, Mark Rutland wrote:
> On Fri, May 15, 2020 at 06:27:53PM +0100, Will Deacon wrote:
> > x18 holds the SCS stack pointer value, so introduce a register alias to
> > make this easier to read in assembly code.
> > 
> > Signed-off-by: Will Deacon <will@kernel.org>
> 
> I scanned through arm64 for all instances of x18, and it looks like
> you've covered all the relevant uses here. In kvm we save/restore x18 a
> bunch becasue it might be a platform register, but we do that
> unconditionally and without knowledge of what it contains, so I think
> that's fine to leave as-is. Therefore:
> 
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> 
> As an aside, the comment in entry-ftrace.S is now stale where it says
> that x18 is safe to clobber. I can send a patch to clean that up, unless
> you want to do that yourself.

Thanks, I'll fix that up (see below). Also, apologies for typo'ing your
email address when I sent this out on Friday.

Will

--->8

From 7e86208cd6541c1229bc1fcd206596308d1727f8 Mon Sep 17 00:00:00 2001
From: Will Deacon <will@kernel.org>
Date: Mon, 18 May 2020 14:01:01 +0100
Subject: [PATCH] arm64: entry-ftrace.S: Update comment to indicate that x18 is
 live

The Shadow Call Stack pointer is held in x18, so update the ftrace
entry comment to indicate that it cannot be safely clobbered.

Reported-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
---
 arch/arm64/kernel/entry-ftrace.S | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S
index 833d48c9acb5..a338f40e64d3 100644
--- a/arch/arm64/kernel/entry-ftrace.S
+++ b/arch/arm64/kernel/entry-ftrace.S
@@ -23,8 +23,9 @@
  *
  * ... where <entry> is either ftrace_caller or ftrace_regs_caller.
  *
- * Each instrumented function follows the AAPCS, so here x0-x8 and x19-x30 are
- * live, and x9-x18 are safe to clobber.
+ * Each instrumented function follows the AAPCS, so here x0-x8 and x18-x30 are
+ * live (x18 holds the Shadow Call Stack pointer), and x9-x17 are safe to
+ * clobber.
  *
  * We save the callsite's context into a pt_regs before invoking any ftrace
  * callbacks. So that we can get a sensible backtrace, we create a stack record
-- 
2.26.2.761.g0e0b3e54be-goog

_______________________________________________
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 1/2] ARM: dts: imx50: Add src node interrupt
From: Anson Huang @ 2020-05-18 12:54 UTC (permalink / raw)
  To: robh+dt, shawnguo, s.hauer, kernel, festevam, devicetree,
	linux-arm-kernel, linux-kernel
  Cc: Linux-imx

Interrupt is a required property according to SRC binding, add
it for SRC node.

Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
 arch/arm/boot/dts/imx50.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
index d325658..567dcc5 100644
--- a/arch/arm/boot/dts/imx50.dtsi
+++ b/arch/arm/boot/dts/imx50.dtsi
@@ -336,6 +336,7 @@
 			src: src@53fd0000 {
 				compatible = "fsl,imx50-src", "fsl,imx51-src";
 				reg = <0x53fd0000 0x4000>;
+				interrupts = <75>;
 				#reset-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 2/2] ARM: dts: imx5: make src node name generic
From: Anson Huang @ 2020-05-18 12:54 UTC (permalink / raw)
  To: robh+dt, shawnguo, s.hauer, kernel, festevam, devicetree,
	linux-arm-kernel, linux-kernel
  Cc: Linux-imx
In-Reply-To: <1589806460-19592-1-git-send-email-Anson.Huang@nxp.com>

Node name should be generic, use "reset-controller" instead of "src" for
i.MX5 SoCs src nodes.

Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
	- If failed to apply this patch series, try them to be based on
	  https://patchwork.kernel.org/patch/11541935/ series, I should have
	  sent them in same series, sorry for that.
---
 arch/arm/boot/dts/imx50.dtsi | 2 +-
 arch/arm/boot/dts/imx51.dtsi | 2 +-
 arch/arm/boot/dts/imx53.dtsi | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
index 567dcc5..30726bf 100644
--- a/arch/arm/boot/dts/imx50.dtsi
+++ b/arch/arm/boot/dts/imx50.dtsi
@@ -333,7 +333,7 @@
 				status = "disabled";
 			};
 
-			src: src@53fd0000 {
+			src: reset-controller@53fd0000 {
 				compatible = "fsl,imx50-src", "fsl,imx51-src";
 				reg = <0x53fd0000 0x4000>;
 				interrupts = <75>;
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 3f1e913..d3583aa 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -439,7 +439,7 @@
 				status = "disabled";
 			};
 
-			src: src@73fd0000 {
+			src: reset-controller@73fd0000 {
 				compatible = "fsl,imx51-src";
 				reg = <0x73fd0000 0x4000>;
 				interrupts = <75>;
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 0d06dbd..afa57bf 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -588,7 +588,7 @@
 				status = "disabled";
 			};
 
-			src: src@53fd0000 {
+			src: reset-controller@53fd0000 {
 				compatible = "fsl,imx53-src", "fsl,imx51-src";
 				reg = <0x53fd0000 0x4000>;
 				interrupts = <75>;
-- 
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

* Re: [PATCH 29/29] module: move the set_fs hack for flush_icache_range to m68k
From: Jessica Yu @ 2020-05-18 13:04 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: linux-ia64, linux-sh, Roman Zippel, linux-mips, linux-mm,
	sparclinux, linux-riscv, linux-arch, linux-c6x-dev, linux-hexagon,
	x86, Geert Uytterhoeven, linux-xtensa, Arnd Bergmann, linux-um,
	linux-m68k, openrisc, linux-arm-kernel, Michal Simek,
	linux-kernel, linux-alpha, linux-fsdevel, Andrew Morton,
	linuxppc-dev
In-Reply-To: <20200515143646.3857579-30-hch@lst.de>

+++ Christoph Hellwig [15/05/20 16:36 +0200]:
>flush_icache_range generally operates on kernel addresses, but for some
>reason m68k needed a set_fs override.  Move that into the m68k code
>insted of keeping it in the module loader.
>
>Signed-off-by: Christoph Hellwig <hch@lst.de>
>Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
>Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
>---
> arch/m68k/mm/cache.c | 4 ++++
> kernel/module.c      | 8 --------
> 2 files changed, 4 insertions(+), 8 deletions(-)

Thanks for cleaning this up. For module.c:

Acked-by: Jessica Yu <jeyu@kernel.org>


_______________________________________________
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 2/4] kasan: record and print the free track
From: Walter Wu @ 2020-05-18 13:10 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: wsd_upstream, linux-mediatek, LKML, kasan-dev, Linux-MM,
	Alexander Potapenko, Matthias Brugger, Andrey Ryabinin, Linux ARM
In-Reply-To: <1589801235.16436.12.camel@mtksdccf07>

On Mon, 2020-05-18 at 19:27 +0800, Walter Wu wrote:
> On Mon, 2020-05-18 at 12:18 +0200, Dmitry Vyukov wrote:
> > On Mon, May 18, 2020 at 8:27 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> > >
> > > Move free track from slub alloc meta-data to slub free meta-data in
> > > order to make struct kasan_free_meta size is 16 bytes. It is a good
> > > size because it is the minimal redzone size and a good number of
> > > alignment.
> > >
> > > For free track in generic KASAN, we do the modification in struct
> > > kasan_alloc_meta and kasan_free_meta:
> > > - remove free track from kasan_alloc_meta.
> > > - add free track into kasan_free_meta.
> > >
> > > [1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
> > >
> > > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> > > Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> > > Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > > Cc: Dmitry Vyukov <dvyukov@google.com>
> > > Cc: Alexander Potapenko <glider@google.com>
> > > ---
> > >  mm/kasan/common.c  | 33 ++++++++++-----------------------
> > >  mm/kasan/generic.c | 18 ++++++++++++++++++
> > >  mm/kasan/kasan.h   |  7 +++++++
> > >  mm/kasan/report.c  | 20 --------------------
> > >  mm/kasan/tags.c    | 37 +++++++++++++++++++++++++++++++++++++
> > >  5 files changed, 72 insertions(+), 43 deletions(-)
> > >
> > > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > > index 8bc618289bb1..6500bc2bb70c 100644
> > > --- a/mm/kasan/common.c
> > > +++ b/mm/kasan/common.c
> > > @@ -51,7 +51,7 @@ depot_stack_handle_t kasan_save_stack(gfp_t flags)
> > >         return stack_depot_save(entries, nr_entries, flags);
> > >  }
> > >
> > > -static inline void set_track(struct kasan_track *track, gfp_t flags)
> > > +void kasan_set_track(struct kasan_track *track, gfp_t flags)
> > >  {
> > >         track->pid = current->pid;
> > >         track->stack = kasan_save_stack(flags);
> > > @@ -249,9 +249,7 @@ void kasan_cache_create(struct kmem_cache *cache, unsigned int *size,
> > >         *size += sizeof(struct kasan_alloc_meta);
> > >
> > >         /* Add free meta. */
> > > -       if (IS_ENABLED(CONFIG_KASAN_GENERIC) &&
> > > -           (cache->flags & SLAB_TYPESAFE_BY_RCU || cache->ctor ||
> > > -            cache->object_size < sizeof(struct kasan_free_meta))) {
> > > +       if (IS_ENABLED(CONFIG_KASAN_GENERIC)) {
> > 
> > Why do we need to increase object size unconditionally?
> > We only store info in free track when the object is free, so I would
> > assume we still can generally overlap free track and the object
> > itself. We store free track at the same time we use the quarantine
> > link, and the quarantine link was overlapped with the object just
> > fine.
> > With this change we indeed increase object size, which we do not want
> > in general.
> > 
> 
> If it doesn't add free meta, but we always store free track into the
> object, Is it safe?
> 
> > 
> > >                 cache->kasan_info.free_meta_offset = *size;
> > >                 *size += sizeof(struct kasan_free_meta);
> > >         }
> > > @@ -299,24 +297,6 @@ struct kasan_free_meta *get_free_info(struct kmem_cache *cache,
> > >         return (void *)object + cache->kasan_info.free_meta_offset;
> > >  }
> > >
> > > -
> > > -static void kasan_set_free_info(struct kmem_cache *cache,
> > > -               void *object, u8 tag)
> > > -{
> > > -       struct kasan_alloc_meta *alloc_meta;
> > > -       u8 idx = 0;
> > > -
> > > -       alloc_meta = get_alloc_info(cache, object);
> > > -
> > > -#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > -       idx = alloc_meta->free_track_idx;
> > > -       alloc_meta->free_pointer_tag[idx] = tag;
> > > -       alloc_meta->free_track_idx = (idx + 1) % KASAN_NR_FREE_STACKS;
> > > -#endif
> > > -
> > > -       set_track(&alloc_meta->free_track[idx], GFP_NOWAIT);
> > > -}
> > > -
> > >  void kasan_poison_slab(struct page *page)
> > >  {
> > >         unsigned long i;
> > > @@ -396,6 +376,13 @@ void * __must_check kasan_init_slab_obj(struct kmem_cache *cache,
> > >         alloc_info = get_alloc_info(cache, object);
> > >         __memset(alloc_info, 0, sizeof(*alloc_info));
> > >
> > > +       if (IS_ENABLED(CONFIG_KASAN_GENERIC)) {
> > > +               struct kasan_free_meta *free_info;
> > > +
> > > +               free_info = get_free_info(cache, object);
> > > +               __memset(free_info, 0, sizeof(*free_info));
> > 
> > If we overlap free track with object, this will not be needed as well, right?
> > 

I thought about it, I think you are right, because the free track must
be stored when object is free, so even don't clean this meta data. It
doesn't matter.

Thanks for your review. If there are no other problems, I will send next
patch. 

Thanks.


> 
> Should we not consider those objects which have adding free meta? If
> they exist, then we should init their meta data when object re-allocate.
> 
> struct kasan_free_meta {
>     struct qlist_node quarantine_link;
>     struct kasan_track free_track;
> };
> 
> 
> > > +       }
> > > +
> > >         if (IS_ENABLED(CONFIG_KASAN_SW_TAGS))
> > >                 object = set_tag(object,
> > >                                 assign_tag(cache, object, true, false));
> > > @@ -492,7 +479,7 @@ static void *__kasan_kmalloc(struct kmem_cache *cache, const void *object,
> > >                 KASAN_KMALLOC_REDZONE);
> > >
> > >         if (cache->flags & SLAB_KASAN)
> > > -               set_track(&get_alloc_info(cache, object)->alloc_track, flags);
> > > +               kasan_set_track(&get_alloc_info(cache, object)->alloc_track, flags);
> > >
> > >         return set_tag(object, tag);
> > >  }
> > > diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> > > index 78d8e0a75a8a..988bc095b738 100644
> > > --- a/mm/kasan/generic.c
> > > +++ b/mm/kasan/generic.c
> > > @@ -345,3 +345,21 @@ void kasan_record_aux_stack(void *addr)
> > >                 alloc_info->rcu_stack[1] = alloc_info->rcu_stack[0];
> > >         alloc_info->rcu_stack[0] = kasan_save_stack(GFP_NOWAIT);
> > >  }
> > > +
> > > +void kasan_set_free_info(struct kmem_cache *cache,
> > > +                               void *object, u8 tag)
> > > +{
> > > +       struct kasan_free_meta *free_meta;
> > > +
> > > +       free_meta = get_free_info(cache, object);
> > > +       kasan_set_track(&free_meta->free_track, GFP_NOWAIT);
> > > +}
> > > +
> > > +struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> > > +                               void *object, u8 tag)
> > > +{
> > > +       struct kasan_free_meta *free_meta;
> > > +
> > > +       free_meta = get_free_info(cache, object);
> > > +       return &free_meta->free_track;
> > > +}
> > > diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> > > index 870c5dd07756..87ee3626b8b0 100644
> > > --- a/mm/kasan/kasan.h
> > > +++ b/mm/kasan/kasan.h
> > > @@ -127,6 +127,9 @@ struct kasan_free_meta {
> > >          * Otherwise it might be used for the allocator freelist.
> > >          */
> > >         struct qlist_node quarantine_link;
> > > +#ifdef CONFIG_KASAN_GENERIC
> > > +       struct kasan_track free_track;
> > > +#endif
> > >  };
> > >
> > >  struct kasan_alloc_meta *get_alloc_info(struct kmem_cache *cache,
> > > @@ -168,6 +171,10 @@ void kasan_report_invalid_free(void *object, unsigned long ip);
> > >  struct page *kasan_addr_to_page(const void *addr);
> > >
> > >  depot_stack_handle_t kasan_save_stack(gfp_t flags);
> > > +void kasan_set_track(struct kasan_track *track, gfp_t flags);
> > > +void kasan_set_free_info(struct kmem_cache *cache, void *object, u8 tag);
> > > +struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> > > +                               void *object, u8 tag);
> > >
> > >  #if defined(CONFIG_KASAN_GENERIC) && \
> > >         (defined(CONFIG_SLAB) || defined(CONFIG_SLUB))
> > > diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> > > index 5ee66cf7e27c..7e9f9f6d5e85 100644
> > > --- a/mm/kasan/report.c
> > > +++ b/mm/kasan/report.c
> > > @@ -159,26 +159,6 @@ static void describe_object_addr(struct kmem_cache *cache, void *object,
> > >                 (void *)(object_addr + cache->object_size));
> > >  }
> > >
> > > -static struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> > > -               void *object, u8 tag)
> > > -{
> > > -       struct kasan_alloc_meta *alloc_meta;
> > > -       int i = 0;
> > > -
> > > -       alloc_meta = get_alloc_info(cache, object);
> > > -
> > > -#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > -       for (i = 0; i < KASAN_NR_FREE_STACKS; i++) {
> > > -               if (alloc_meta->free_pointer_tag[i] == tag)
> > > -                       break;
> > > -       }
> > > -       if (i == KASAN_NR_FREE_STACKS)
> > > -               i = alloc_meta->free_track_idx;
> > > -#endif
> > > -
> > > -       return &alloc_meta->free_track[i];
> > > -}
> > > -
> > >  #ifdef CONFIG_KASAN_GENERIC
> > >  static void print_stack(depot_stack_handle_t stack)
> > >  {
> > > diff --git a/mm/kasan/tags.c b/mm/kasan/tags.c
> > > index 25b7734e7013..201dee5d6ae0 100644
> > > --- a/mm/kasan/tags.c
> > > +++ b/mm/kasan/tags.c
> > > @@ -162,3 +162,40 @@ void __hwasan_tag_memory(unsigned long addr, u8 tag, unsigned long size)
> > >         kasan_poison_shadow((void *)addr, size, tag);
> > >  }
> > >  EXPORT_SYMBOL(__hwasan_tag_memory);
> > > +
> > > +void kasan_set_free_info(struct kmem_cache *cache,
> > > +                               void *object, u8 tag)
> > > +{
> > > +       struct kasan_alloc_meta *alloc_meta;
> > > +       u8 idx = 0;
> > > +
> > > +       alloc_meta = get_alloc_info(cache, object);
> > > +
> > > +#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > +       idx = alloc_meta->free_track_idx;
> > > +       alloc_meta->free_pointer_tag[idx] = tag;
> > > +       alloc_meta->free_track_idx = (idx + 1) % KASAN_NR_FREE_STACKS;
> > > +#endif
> > > +
> > > +       kasan_set_track(&alloc_meta->free_track[idx], GFP_NOWAIT);
> > > +}
> > > +
> > > +struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> > > +                               void *object, u8 tag)
> > > +{
> > > +       struct kasan_alloc_meta *alloc_meta;
> > > +       int i = 0;
> > > +
> > > +       alloc_meta = get_alloc_info(cache, object);
> > > +
> > > +#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > +       for (i = 0; i < KASAN_NR_FREE_STACKS; i++) {
> > > +               if (alloc_meta->free_pointer_tag[i] == tag)
> > > +                       break;
> > > +       }
> > > +       if (i == KASAN_NR_FREE_STACKS)
> > > +               i = alloc_meta->free_track_idx;
> > > +#endif
> > > +
> > > +       return &alloc_meta->free_track[i];
> > > +}
> > > --
> > > 2.18.0
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox