Re: [powerpc] ftrace warning kernel/trace/ftrace.c:2068 with code-patching selftests

2022-01-27 Thread Mark Rutland
On Thu, Jan 27, 2022 at 01:03:34PM +0100, Ard Biesheuvel wrote: > On Thu, 27 Jan 2022 at 12:47, Mark Rutland wrote: > > > > [adding LKML so this is easier for others to find] > > > > If anyone wants to follow the thread from the start, it's at: > > > >

Re: [powerpc] ftrace warning kernel/trace/ftrace.c:2068 with code-patching selftests

2022-01-27 Thread Mark Rutland
table, but I couldn't spot where, and suspect I'm mistaken. Do you know whether it currently does any boot-time dynamic relocation? Kees, there's an x86_64 relocation question for you at the end. On Wed, Jan 26, 2022 at 02:37:16PM +, Mark Rutland wrote: > Hi, > > Steve p

Re: [powerpc] ftrace warning kernel/trace/ftrace.c:2068 with code-patching selftests

2022-01-26 Thread Mark Rutland
Hi, Steve pointed me at this thread over IRC -- I'm not subscribed to this list so grabbed a copy of the thread thus far via b4. On Tue, Jan 25, 2022 at 11:20:27AM +0800, Yinan Liu wrote: > > Yeah, I think it's time to opt in, instead of opting out. I agree this must be opt-in rather than opt-ou

Re: [PATCH] of: unmap memory regions in /memreserve node

2021-12-02 Thread Mark Rutland
On Tue, Nov 30, 2021 at 04:43:31PM -0600, Rob Herring wrote: > +linuxppc-dev > > On Wed, Nov 24, 2021 at 09:33:47PM +0800, Calvin Zhang wrote: > > Reserved memory regions in /memreserve node aren't and shouldn't > > be referenced elsewhere. So mark them no-map to skip direct mapping > > for them.

Re: [RFC PATCH 0/8] Move task_struct::cpu back into thread_info

2021-09-14 Thread Mark Rutland
FWIW, for the series: Acked-by: Mark Rutland Mark. > While collaborating with Keith on adding THREAD_INFO_IN_TASK support to > ARM, we noticed that keeping CPU in task_struct is problematic for > architectures that define raw_smp_processor_id() in terms of this field, > as it re

Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends

2021-03-10 Thread Mark Rutland
On Tue, Mar 09, 2021 at 04:05:32PM -0600, Segher Boessenkool wrote: > Hi! > > On Tue, Mar 09, 2021 at 04:05:23PM +0000, Mark Rutland wrote: > > On Thu, Mar 04, 2021 at 03:54:48PM -0600, Segher Boessenkool wrote: > > > On Thu, Mar 04, 2021 at 02:57:30PM +, Mark Rutland

Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends

2021-03-09 Thread Mark Rutland
On Thu, Mar 04, 2021 at 03:54:48PM -0600, Segher Boessenkool wrote: > Hi! Hi Segher, > On Thu, Mar 04, 2021 at 02:57:30PM +, Mark Rutland wrote: > > It looks like GCC is happy to give us the function-entry-time FP if we use > > __builtin_frame_address(1), >

Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends

2021-03-05 Thread Mark Rutland
On Thu, Mar 04, 2021 at 08:01:29PM +0100, Marco Elver wrote: > On Thu, 4 Mar 2021 at 19:51, Mark Rutland wrote: > > On Thu, Mar 04, 2021 at 07:22:53PM +0100, Marco Elver wrote: > > > I was having this problem with KCSAN, where the compiler would > > > tail-call-optimi

Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends

2021-03-04 Thread Mark Rutland
On Thu, Mar 04, 2021 at 07:22:53PM +0100, Marco Elver wrote: > On Thu, 4 Mar 2021 at 19:02, Mark Rutland wrote: > > On Thu, Mar 04, 2021 at 06:25:33PM +0100, Marco Elver wrote: > > > On Thu, Mar 04, 2021 at 04:59PM +, Mark Rutland wrote: > > > > On Thu, Mar 04, 2

Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends

2021-03-04 Thread Mark Rutland
On Thu, Mar 04, 2021 at 06:25:33PM +0100, Marco Elver wrote: > On Thu, Mar 04, 2021 at 04:59PM +0000, Mark Rutland wrote: > > On Thu, Mar 04, 2021 at 04:30:34PM +0100, Marco Elver wrote: > > > On Thu, 4 Mar 2021 at 15:57, Mark Rutland wrote: > > > > [adding Mark Bro

Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends

2021-03-04 Thread Mark Rutland
On Thu, Mar 04, 2021 at 04:30:34PM +0100, Marco Elver wrote: > On Thu, 4 Mar 2021 at 15:57, Mark Rutland wrote: > > [adding Mark Brown] > > > > The bigger problem here is that skipping is dodgy to begin with, and > > this is still liable to break in some cas

Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends

2021-03-04 Thread Mark Rutland
[adding Mark Brown] On Wed, Mar 03, 2021 at 04:20:43PM +0100, Marco Elver wrote: > On Wed, Mar 03, 2021 at 03:52PM +0100, Christophe Leroy wrote: > > Le 03/03/2021 � 15:38, Marco Elver a �crit�: > > > On Wed, 3 Mar 2021 at 15:09, Christophe Leroy > > > wrote: > > > > > > > > It seems like

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Mark Rutland
On Tue, Jul 14, 2020 at 03:01:09PM +0200, Peter Zijlstra wrote: > On Tue, Jul 14, 2020 at 03:19:24PM +0300, Ard Biesheuvel wrote: > > So perhaps the answer is to have text_alloc() not with a 'where' > > argument but with a 'why' argument. Or more simply, just have separate > > alloc/free APIs for e

Re: [RFC][PATCH 0/2] Add support for using reserved memory for ima buffer pass

2020-05-05 Thread Mark Rutland
Hi Prakhar, On Mon, May 04, 2020 at 01:38:27PM -0700, Prakhar Srivastava wrote: > IMA during kexec(kexec file load) verifies the kernel signature and measures > the signature of the kernel. The signature in the logs can be used to verfiy > the > authenticity of the kernel. The logs don not get c

Re: [PATCH 18/28] mm: enforce that vmap can't map pages executable

2020-04-08 Thread Mark Rutland
On Wed, Apr 08, 2020 at 01:59:16PM +0200, Christoph Hellwig wrote: > To help enforcing the W^X protection don't allow remapping existing > pages as executable. > > Based on patch from Peter Zijlstra . > > Signed-off-by: Christoph Hellwig > --- > arch/x86/include/asm/pgtable_types.h | 6 ++ >

Re: [PATCH 26/28] arm64: use __vmalloc_node in arch_alloc_vmap_stack

2020-04-08 Thread Mark Rutland
On Wed, Apr 08, 2020 at 01:59:24PM +0200, Christoph Hellwig wrote: > arch_alloc_vmap_stack can use a slightly higher level vmalloc function. > > Signed-off-by: Christoph Hellwig Acked-by: Mark Rutland Mark. > --- > arch/arm64/include/asm/vmap_stack.h | 6 ++ >

Re: [RFC 02/11] perf/core: Data structure to present hazard data

2020-03-02 Thread Mark Rutland
On Mon, Mar 02, 2020 at 10:53:46AM +0530, Ravi Bangoria wrote: > From: Madhavan Srinivasan > > Introduce new perf sample_type PERF_SAMPLE_PIPELINE_HAZ to request kernel > to provide cpu pipeline hazard data. Also, introduce arch independent > structure 'perf_pipeline_haz_data' to pass hazard data

Re: [RFC 02/11] perf/core: Data structure to present hazard data

2020-03-02 Thread Mark Rutland
On Mon, Mar 02, 2020 at 10:53:46AM +0530, Ravi Bangoria wrote: > From: Madhavan Srinivasan > > Introduce new perf sample_type PERF_SAMPLE_PIPELINE_HAZ to request kernel > to provide cpu pipeline hazard data. Also, introduce arch independent > structure 'perf_pipeline_haz_data' to pass hazard data

Re: [PATCH v8 1/5] kasan: support backing vmalloc space with real shadow memory

2019-10-16 Thread Mark Rutland
Hi Andrey, On Wed, Oct 16, 2019 at 03:19:50PM +0300, Andrey Ryabinin wrote: > On 10/14/19 4:57 PM, Daniel Axtens wrote: > >>> + /* > >>> + * Ensure poisoning is visible before the shadow is made visible > >>> + * to other CPUs. > >>> + */ > >>> + smp_wmb(); > >> > >> I'm not quite understand wh

Re: [PATCH v8 1/5] kasan: support backing vmalloc space with real shadow memory

2019-10-14 Thread Mark Rutland
ful for architectures > that do not have a separate module space (e.g. powerpc64, which I am > currently working on). It also allows relaxing the module alignment > back to PAGE_SIZE. > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=202009 > Acked-by: Vasily Gorbik > Sign

Re: [PATCH v8 1/5] kasan: support backing vmalloc space with real shadow memory

2019-10-14 Thread Mark Rutland
On Tue, Oct 15, 2019 at 12:57:44AM +1100, Daniel Axtens wrote: > Hi Andrey, > > > >> + /* > >> + * Ensure poisoning is visible before the shadow is made visible > >> + * to other CPUs. > >> + */ > >> + smp_wmb(); > > > > I'm not quite understand what this barrier do and why it needed. > >

Re: [PATCH v6 1/5] kasan: support backing vmalloc space with real shadow memory

2019-09-02 Thread Mark Rutland
On Tue, Sep 03, 2019 at 12:32:49AM +1000, Daniel Axtens wrote: > Hi Mark, > > >> +static int kasan_depopulate_vmalloc_pte(pte_t *ptep, unsigned long addr, > >> + void *unused) > >> +{ > >> + unsigned long page; > >> + > >> + page = (unsigned long)__va(pte_pfn(*pt

Re: [PATCH v6 1/5] kasan: support backing vmalloc space with real shadow memory

2019-09-02 Thread Mark Rutland
ful for architectures > that do not have a separate module space (e.g. powerpc64, which I am > currently working on). It also allows relaxing the module alignment > back to PAGE_SIZE. > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=202009 > Acked-by: Vasily Gorbik > Sign

Re: [PATCH v4 1/3] kasan: support backing vmalloc space with real shadow memory

2019-08-19 Thread Mark Rutland
On Fri, Aug 16, 2019 at 10:41:00AM -0700, Andy Lutomirski wrote: > On Fri, Aug 16, 2019 at 10:08 AM Mark Rutland wrote: > > > > Hi Christophe, > > > > On Fri, Aug 16, 2019 at 09:47:00AM +0200, Christophe Leroy wrote: > > > Le 15/08/2019 à 02:16, Daniel Axtens

Re: [PATCH 6/6] arm64: document the choice of page attributes for pgprot_dmacoherent

2019-08-16 Thread Mark Rutland
s access size, requires strict > alignment and can also force write responses to come from the endpoint. > > ? It's a small change, but it better fits with the arm64 terminology > ("strongly ordered" is no longer used in the architecture). > > If you're happy with that, I can make the change and queue this patch > for 5.4. FWIW, with that wording: Acked-by: Mark Rutland Mark.

Re: [PATCH v4 1/3] kasan: support backing vmalloc space with real shadow memory

2019-08-16 Thread Mark Rutland
Hi Christophe, On Fri, Aug 16, 2019 at 09:47:00AM +0200, Christophe Leroy wrote: > Le 15/08/2019 à 02:16, Daniel Axtens a écrit : > > Hook into vmalloc and vmap, and dynamically allocate real shadow > > memory to back the mappings. > > > > Most mappings in vmalloc space are small, requiring less

Re: [PATCH v4 0/3] kasan: support backing vmalloc space with real shadow memory

2019-08-15 Thread Mark Rutland
't spotted such memory exhaustion after a week of Syzkaller fuzzing with the last patchset, across 3 machines, so that sounds fine to me. Otherwise, this looks good to me now! For the x86 and fork patch, feel free to add: Acked-by: Mark Rutland Mark. > > v1: https://lore.kernel.org

Re: [RFC V2 0/1] mm/debug: Add tests for architecture exported page table helpers

2019-08-09 Thread Mark Rutland
On Fri, Aug 09, 2019 at 03:16:33AM -0700, Matthew Wilcox wrote: > On Fri, Aug 09, 2019 at 01:03:17PM +0530, Anshuman Khandual wrote: > > Should alloc_gigantic_page() be made available as an interface for general > > use in the kernel. The test module here uses very similar implementation > > from

Re: [PATCH 4/4] mm/vmalloc: Hugepage vmalloc mappings

2019-06-10 Thread Mark Rutland
Hi, On Mon, Jun 10, 2019 at 02:38:38PM +1000, Nicholas Piggin wrote: > For platforms that define HAVE_ARCH_HUGE_VMAP, have vmap allow vmalloc to > allocate huge pages and map them > > This brings dTLB misses for linux kernel tree `git diff` from 45,000 to > 8,000 on a Kaby Lake KVM guest with 8MB

Re: [PATCH 04/15] arm64: switch to generic version of pte allocation

2019-05-03 Thread Mark Rutland
Hi, On Thu, May 02, 2019 at 06:28:31PM +0300, Mike Rapoport wrote: > The PTE allocations in arm64 are identical to the generic ones modulo the > GFP flags. > > Using the generic pte_alloc_one() functions ensures that the user page > tables are allocated with __GFP_ACCOUNT set. > > The arm64 defi

Re: [PATCH v12 04/31] arm64/mm: define ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT

2019-04-23 Thread Mark Rutland
On Tue, Apr 23, 2019 at 05:36:31PM +0200, Laurent Dufour wrote: > Le 18/04/2019 à 23:51, Jerome Glisse a écrit : > > On Tue, Apr 16, 2019 at 03:41:56PM +0100, Mark Rutland wrote: > > > On Tue, Apr 16, 2019 at 04:31:27PM +0200, Laurent Dufour wrote: > > > > Le 16/0

Re: [RESEND PATCH v3 02/11] arm64: mark (__)cpus_have_const_cap as __always_inline

2019-04-23 Thread Mark Rutland
bviously needed to be made __always_inline. I've built and booted this atop of defconfig and my usual suite of debug options for fuzzing, at EL1 under QEMU/KVM, and at EL2 under QEMU/TCG, with no issues in either case, so FWIW: Tested-by: Mark Rutland Thanks, Mark. > --- > >

Re: [PATCH v12 04/31] arm64/mm: define ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT

2019-04-16 Thread Mark Rutland
On Tue, Apr 16, 2019 at 04:31:27PM +0200, Laurent Dufour wrote: > Le 16/04/2019 à 16:27, Mark Rutland a écrit : > > On Tue, Apr 16, 2019 at 03:44:55PM +0200, Laurent Dufour wrote: > > > From: Mahendran Ganesh > > > > > > Set ARCH_SUPPORTS_SPECULATIVE_PAGE

Re: [PATCH v12 04/31] arm64/mm: define ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT

2019-04-16 Thread Mark Rutland
On Tue, Apr 16, 2019 at 03:44:55PM +0200, Laurent Dufour wrote: > From: Mahendran Ganesh > > Set ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT for arm64. This > enables Speculative Page Fault handler. > > Signed-off-by: Ganesh Mahendran This is missing your S-o-B. The first patch noted that the ARCH_S

Re: [PATCH 1/6] mm: change locked_vm's type from unsigned long to atomic64_t

2019-04-11 Thread Mark Rutland
On Thu, Apr 11, 2019 at 02:22:23PM +1000, Alexey Kardashevskiy wrote: > On 03/04/2019 07:41, Daniel Jordan wrote: > > - dev_dbg(dev, "[%d] RLIMIT_MEMLOCK %c%ld %ld/%ld%s\n", current->pid, > > + dev_dbg(dev, "[%d] RLIMIT_MEMLOCK %c%ld %lld/%lu%s\n", current->pid, > > incr ? '+' : '-

Re: [PATCH 3/7] powerpc/mm: Add a framework for Kernel Userspace Access Protection

2019-02-21 Thread Mark Rutland
On Thu, Feb 21, 2019 at 11:46:06AM +0100, Christophe Leroy wrote: > > > Le 21/02/2019 à 10:35, Russell Currey a écrit : > > From: Christophe Leroy > > > > This patch implements a framework for Kernel Userspace Access > > Protection. > > > > Then subarches will have to possibility to provide th

Re: [PATCH v14 02/12] powerpc/irq: use memblock functions returning virtual address

2019-01-24 Thread Mark Rutland
On Thu, Jan 24, 2019 at 07:25:53PM +0200, Mike Rapoport wrote: > On Thu, Jan 24, 2019 at 04:51:53PM +0000, Mark Rutland wrote: > > On Thu, Jan 24, 2019 at 04:19:33PM +, Christophe Leroy wrote: > > > Since only the virtual address of allocated blocks is used, > > > l

Re: [PATCH v14 07/12] powerpc: Activate CONFIG_THREAD_INFO_IN_TASK

2019-01-24 Thread Mark Rutland
On Thu, Jan 24, 2019 at 04:19:43PM +, Christophe Leroy wrote: > This patch activates CONFIG_THREAD_INFO_IN_TASK which > moves the thread_info into task_struct. > > Moving thread_info into task_struct has the following advantages: > - It protects thread_info from corruption in the case of stack

Re: [PATCH v14 05/12] powerpc: prep stack walkers for THREAD_INFO_IN_TASK

2019-01-24 Thread Mark Rutland
CONFIG_THREAD_INFO_IN_TASK is not selected these perform no > refcounting, and this should only be a structural change that does not > affect behaviour. > > Signed-off-by: Christophe Leroy I'm not familiar with the powerpc code, but AFAICT this is analagous to the arm64 code, and I&

Re: [PATCH v14 02/12] powerpc/irq: use memblock functions returning virtual address

2019-01-24 Thread Mark Rutland
y_nid() will panic itself rather than returning NULL. Otherwise, this looks like a nice cleanup. With the panics removed (or using the _nopanic() allocators), feel free to add: Acked-by: Mark Rutland Thanks, Mark.

Re: [PATCH 09/10] drivers/perf: perf/core: generalise event exclusion checking with perf macro

2018-11-19 Thread Mark Rutland
rs/perf/qcom_l3_pmu.c > - drivers/perf/arm_pmu.c > > And exclude_idle and exclude_hv are added in these files: > > - drivers/perf/xgene_pmu.c FWIW, that all sounds fine to me. Assuming you fix up the 'macro' nit: Acked-by: Mark Rutland ... unless we go for Peter

Re: [PATCH 01/10] perf/core: Add macro to test for event exclusion flags

2018-11-19 Thread Mark Rutland
fix that up here and in subsequent commit messages, for this patch feel free to add: Acked-by: Mark Rutland Mark. > --- > include/linux/perf_event.h | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h >

Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed

2018-11-01 Thread Mark Rutland
[adding the atomic maintainers] On Thu, Nov 01, 2018 at 12:17:31AM +, Trond Myklebust wrote: > On Wed, 2018-10-31 at 23:32 +, Paul Burton wrote: > > (Copying SunRPC & net maintainers.) > > > > Hi Guenter, > > > > On Wed, Oct 31, 2018 at 03:02:53PM -0700, Guenter Roeck wrote: > > > The al

Re: [RFC PATCH v1 1/9] timer: fix circular header dependency

2018-09-25 Thread Mark Rutland
On Tue, Sep 25, 2018 at 07:34:15AM +0200, Christophe LEROY wrote: > > > Le 24/09/2018 à 17:52, Christophe Leroy a écrit : > > When switching powerpc to CONFIG_THREAD_INFO_IN_TASK, include/sched.h > > has to be included in asm/smp.h for the following change, in order > > to avoid uncomplete defini

Re: [PATCH 1/5] arm64: entry: isb in el1_irq

2018-04-06 Thread Mark Rutland
On Fri, Apr 06, 2018 at 06:22:11PM +0100, Mark Rutland wrote: > Digging a bit, I also thing that our ct_user_exit and ct_user_enter > usage is on dodgy ground today. > > For example, in el0_dbg we call do_debug_exception() *before* calling > ct_user_exit. Which I believe means we&

Re: [PATCH 1/5] arm64: entry: isb in el1_irq

2018-04-06 Thread Mark Rutland
On Fri, Apr 06, 2018 at 06:30:50PM +0100, James Morse wrote: > Hi Mark, > > On 06/04/18 18:22, Mark Rutland wrote: > > Digging a bit, I also thing that our ct_user_exit and ct_user_enter > > usage is on dodgy ground today. > > [...] > > > I think similar appl

Re: [PATCH 1/5] arm64: entry: isb in el1_irq

2018-04-06 Thread Mark Rutland
On Fri, Apr 06, 2018 at 07:54:02PM +0300, Yury Norov wrote: > In general, kick_all_cpus_sync() is needed to switch contexts. But exit from > userspace is anyway the switch of context. And while in userspace, we cannot > do something wrong on kernel side. For me it means that we can safely drop > IP

Re: [PATCH 3/5] arm64: early ISB at exit from extended quiescent state

2018-04-06 Thread Mark Rutland
On Thu, Apr 05, 2018 at 08:17:58PM +0300, Yury Norov wrote: > This series enables delaying of kernel memory synchronization > for CPUs running in extended quiescent state (EQS) till the exit > of that state. > > ARM64 uses IPI mechanism to notify all cores in SMP system that > kernel text is chan

Re: [PATCH 1/5] arm64: entry: isb in el1_irq

2018-04-06 Thread Mark Rutland
On Thu, Apr 05, 2018 at 08:17:56PM +0300, Yury Norov wrote: > Kernel text patching framework relies on IPI to ensure that other > SMP cores observe the change. Target core calls isb() in IPI handler > path, but not at the beginning of el1_irq entry. There's a chance > that modified instruction will

Re: [PATCH 2/2] smp: introduce kick_active_cpus_sync()

2018-04-04 Thread Mark Rutland
On Wed, Apr 04, 2018 at 06:36:25AM +0300, Yury Norov wrote: > On Tue, Apr 03, 2018 at 02:48:32PM +0100, Mark Rutland wrote: > > On Sun, Apr 01, 2018 at 02:11:08PM +0300, Yury Norov wrote: > > > @@ -840,8 +861,10 @@ el0_svc: > > > mov wsc_nr, #__NR_sy

Re: [PATCH 2/2] smp: introduce kick_active_cpus_sync()

2018-04-03 Thread Mark Rutland
Hi Yury, On Sun, Apr 01, 2018 at 02:11:08PM +0300, Yury Norov wrote: > +/* > + * Flush I-cache if CPU is in extended quiescent state > + */ This comment is misleading. An ISB doesn't touch the I-cache; it forces a context synchronization event. > + .macro isb_if_eqs > +#ifndef CONFIG_TINY_R

Re: [PATCH v11 7/9] arm64/kasan: add and use kasan_map_populate()

2017-10-13 Thread Mark Rutland
Hi, On Fri, Oct 13, 2017 at 03:43:19PM +0100, Will Deacon wrote: > On Fri, Oct 13, 2017 at 10:10:09AM -0400, Pavel Tatashin wrote: > > I am getting the following panic during boot: > > > > [0.012637] pid_max: default: 32768 minimum: 301 > > [0.016037] Security Framework initialized > > [

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

2017-10-03 Thread Mark Rutland
Hi Pavel, On Wed, Sep 20, 2017 at 04:17:11PM -0400, Pavel Tatashin wrote: > During early boot, kasan uses vmemmap_populate() to establish its shadow > memory. But, that interface is intended for struct pages use. > > Because of the current project, vmemmap won't be zeroed during allocation, > but

Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow memory

2017-09-15 Thread Mark Rutland
On Fri, Sep 15, 2017 at 05:20:59PM -0400, Pavel Tatashin wrote: > Hi Mark, > > I had this option  back upto version 3, where zero flag was passed into > vmemmap_alloc_block(), but I was asked to remove it, because it required too > many changes in other places. Ok. Sorry for bringing back a point

Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow memory

2017-09-15 Thread Mark Rutland
On Thu, Sep 14, 2017 at 09:30:28PM -0400, Pavel Tatashin wrote: > Hi Mark, > > Thank you for looking at this. We can't do this because page table is not > set until cpu_replace_ttbr1() is called. So, we can't do memset() on this > memory until then. I see. Sorry, I had missed that we were on the

Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow memory

2017-09-14 Thread Mark Rutland
On Thu, Sep 14, 2017 at 06:35:16PM -0400, Pavel Tatashin wrote: > To optimize the performance of struct page initialization, > vmemmap_populate() will no longer zero memory. > > We must explicitly zero the memory that is allocated by vmemmap_populate() > for kasan, as this memory does not go throu

Re: [RFC 2/4] libnvdimm: Add a device-tree interface

2017-06-27 Thread Mark Rutland
Hi, On Tue, Jun 27, 2017 at 08:28:49PM +1000, Oliver O'Halloran wrote: > A fairly bare-bones set of device-tree bindings so libnvdimm can be used > on powerpc and other, less cool, device-tree based platforms. ;) > Cc: devicet...@vger.kernel.org > Signed-off-by: Oliver O'Halloran > --- > The cu

Re: [PATCH] of/irq: improve error message on irq discovery process failure

2016-11-11 Thread Mark Rutland
On Fri, Nov 11, 2016 at 08:30:43AM +1100, Benjamin Herrenschmidt wrote: > On Wed, 2016-11-09 at 19:04 +0000, Mark Rutland wrote: > > > > If we don't have an interrupt-map on a PCI controller, why don't we > > instead log a message regarding that being missing,

Re: [PATCH] of/irq: improve error message on irq discovery process failure

2016-11-09 Thread Mark Rutland
On Wed, Nov 09, 2016 at 12:05:08PM -0200, Guilherme G. Piccoli wrote: > On PowerPC machines some PCI slots might not have Level-triggered > interrupts capability (also know as Level Signaled Interrupts - LSI), > leading of_irq_parse_pci() to complain by presenting error messages > on the kernel log

Re: [PATCH v2 0/2] extend kexec_file_load system call

2016-08-18 Thread Mark Rutland
On Thu, Aug 11, 2016 at 08:03:56PM -0300, Thiago Jung Bauermann wrote: > This patch series is from AKASHI Takahiro. I will use it in my next > version of the kexec_file_load implementation for powerpc, so I am > rebasing it on top of v4.8-rc1. [...] > Original cover letter: > > Device tree blob

Re: [RFC 3/3] kexec: extend kexec_file_load system call

2016-07-19 Thread Mark Rutland
On Tue, Jul 19, 2016 at 08:24:06AM -0400, Vivek Goyal wrote: > On Tue, Jul 19, 2016 at 11:52:00AM +0100, Mark Rutland wrote: > > Regardless, this extended syscall changes some underlying assumptions > > made with the development of kexec_file_load, and I think treating this > &g

Re: [RFC 3/3] kexec: extend kexec_file_load system call

2016-07-19 Thread Mark Rutland
On Tue, Jul 19, 2016 at 08:55:56AM +0800, Dave Young wrote: > On 07/18/16 at 11:07am, Mark Rutland wrote: > > On Mon, Jul 18, 2016 at 10:30:24AM +0800, Dave Young wrote: > > > I do not think it is worth to add another syscall for extra fds. > > > We have open(2) as an ex

Re: [RFC 3/3] kexec: extend kexec_file_load system call

2016-07-18 Thread Mark Rutland
On Mon, Jul 18, 2016 at 10:30:24AM +0800, Dave Young wrote: > On 07/15/16 at 02:19pm, Mark Rutland wrote: > > On Fri, Jul 15, 2016 at 09:09:55AM -0400, Vivek Goyal wrote: > > > On Tue, Jul 12, 2016 at 10:42:01AM +0900, AKASHI Takahiro wrote: > > > > >

Re: [RFC 0/3] extend kexec_file_load system call

2016-07-15 Thread Mark Rutland
On Fri, Jul 15, 2016 at 12:29:09PM -0300, Thiago Jung Bauermann wrote: > Am Freitag, 15 Juli 2016, 14:33:47 schrieb Mark Rutland: > > On Fri, Jul 15, 2016 at 09:26:10AM -0400, Vivek Goyal wrote: > > > I don't know anything about DTB. So here comes a very basic questio

Re: [RFC 0/3] extend kexec_file_load system call

2016-07-15 Thread Mark Rutland
On Fri, Jul 15, 2016 at 09:26:10AM -0400, Vivek Goyal wrote: > On Fri, Jul 15, 2016 at 09:31:02AM +0200, Arnd Bergmann wrote: > > On Thursday, July 14, 2016 10:44:14 PM CEST Thiago Jung Bauermann wrote: > > > Am Donnerstag, 14 Juli 2016, 10:29:11 schrieb Arnd Bergmann: > > > > > > > > > > Right,

Re: [RFC 3/3] kexec: extend kexec_file_load system call

2016-07-15 Thread Mark Rutland
On Fri, Jul 15, 2016 at 09:09:55AM -0400, Vivek Goyal wrote: > On Tue, Jul 12, 2016 at 10:42:01AM +0900, AKASHI Takahiro wrote: > > [..] > > -SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd, > > +SYSCALL_DEFINE6(kexec_file_load, int, kernel_fd, int, initrd_fd, > > unsig

Re: [RFC 0/3] extend kexec_file_load system call

2016-07-14 Thread Mark Rutland
On Wed, Jul 13, 2016 at 09:57:28PM +0200, Arnd Bergmann wrote: > On Wednesday, July 13, 2016 6:58:32 PM CEST Mark Rutland wrote: > > > > > we may want to remove unnecessary devices and even add a dedicated > > > storage device for storing a core dump image. > >

Re: [RFC 0/3] extend kexec_file_load system call

2016-07-13 Thread Mark Rutland
On Thu, Jul 14, 2016 at 02:38:06AM +0900, AKASHI Takahiro wrote: > Apologies for the slow response. I'm attending LinuxCon this week. > > On Wed, Jul 13, 2016 at 10:34:47AM +0100, Mark Rutland wrote: > > On Wed, Jul 13, 2016 at 10:36:14AM +0800, Dave Young wrote: > > &

Re: [RFC 0/3] extend kexec_file_load system call

2016-07-13 Thread Mark Rutland
On Wed, Jul 13, 2016 at 10:01:33AM +0200, Arnd Bergmann wrote: > On Wednesday, July 13, 2016 10:36:14 AM CEST Dave Young wrote: > > On 07/12/16 at 03:50pm, Mark Rutland wrote: > > > On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote: > > > > On Tuesday,

Re: [RFC 0/3] extend kexec_file_load system call

2016-07-13 Thread Mark Rutland
On Wed, Jul 13, 2016 at 10:36:14AM +0800, Dave Young wrote: > But consider we can kexec to a different kernel and a different initrd so > there > will be use cases to pass a total different dtb as well. It depends on what you mean by "a different kernel", and what this implies for the DTB. I exp

Re: [RFC 0/3] extend kexec_file_load system call

2016-07-12 Thread Mark Rutland
On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote: > On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote: > > > > > > On Open Firmware, the DT is extracted from running firmware and copied > > > into dynamically allocated data structures. After a kexec, the runtime > > > inter

Re: [PATCH 4/9] arm64/uaccess: Enable hardened usercopy

2016-07-07 Thread Mark Rutland
Hi, On Wed, Jul 06, 2016 at 03:25:23PM -0700, Kees Cook wrote: > Enables CONFIG_HARDENED_USERCOPY checks on arm64. As done by KASAN in -next, > renames the low-level functions to __arch_copy_*_user() so a static inline > can do additional work before the copy. The checks themselves look fine, but

Re: [v8, 1/7] Documentation: DT: update Freescale DCFG compatible

2016-04-22 Thread Mark Rutland
On Fri, Apr 22, 2016 at 02:27:38PM +0800, Yangbo Lu wrote: > Update Freescale DCFG compatible with 'fsl,-dcfg' instead > of 'fsl,ls1021a-dcfg' to include more chips. > > Signed-off-by: Yangbo Lu > --- > Changes for v8: > - Added this patch > --- > Documentation/devicetree/bindings/arm/fsl.

Re: [PATCH V2] tick-broadcast: Register for hrtimer based broadcast as the fallback broadcast mode

2014-12-08 Thread Mark Rutland
On Mon, Dec 08, 2014 at 12:02:55PM +, Preeti U Murthy wrote: > On 12/08/2014 04:18 PM, Mark Rutland wrote: > > Hi Preeti, > > > > On Mon, Dec 08, 2014 at 06:55:43AM +, Preeti U Murthy wrote: > >> Commit 5d1638acb9f6 ('tick: Introduce hrtimer based bro

Re: [PATCH V2] tick-broadcast: Register for hrtimer based broadcast as the fallback broadcast mode

2014-12-08 Thread Mark Rutland
es registered, and everything works well with CPUs entering and exiting idle states where the cpu-local timers lose state. So: Tested-by: Mark Rutland One minor thing I noticed when testing was that /sys/devices/system/clockevents/broadcast/name contained "(null)", because we never set

Re: [PATCH] tick-broadcast: Register for hrtimer based broadcast as the default broadcast mode

2014-12-05 Thread Mark Rutland
Hi Preeti, Moving this out of the architecture code looks good to me! I have a couple of minor comments below. On Fri, Dec 05, 2014 at 12:47:57PM +, Preeti U Murthy wrote: > Commit 5d1638acb9f62fa7 added a hrtimer based broadcast mode for those > platforms in which local timers stop when CPU

Re: [PATCH 3/4] dt/bindings: Introduce the FSL QorIQ DPAA QMan

2014-10-23 Thread Mark Rutland
[...] > >> +QMan Node > >> + > >> +PROPERTIES > >> + > >> +- compatible > >> + Usage: Required > >> + Value type: > >> + Definition: Must include "fsl,qman" > >> + May include "fsl,-qman" > >> + > >> +- reg > >> + Usage: Required > >> + Value type:

Re: [PATCH 2/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan portal(s)

2014-10-23 Thread Mark Rutland
On Wed, Oct 22, 2014 at 09:04:54PM +0100, Emil Medve wrote: > Hello Mark, > > > Thanks for having a look at this > > On 10/22/2014 09:29 AM, Mark Rutland wrote: > > On Wed, Oct 22, 2014 at 03:09:30PM +0100, Emil Medve wrote: > >> Portals are used by so

Re: [PATCH 3/4] dt/bindings: Introduce the FSL QorIQ DPAA QMan

2014-10-22 Thread Mark Rutland
On Wed, Oct 22, 2014 at 03:09:31PM +0100, Emil Medve wrote: > The Queue Manager is part of the Data-Path Acceleration Architecture (DPAA). > QMan supports queuing and QoS scheduling of frames to CPUs, network interfaces > and DPAA logic modules, maintains packet ordering within flows. Besides > pro

Re: [PATCH 2/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan portal(s)

2014-10-22 Thread Mark Rutland
On Wed, Oct 22, 2014 at 03:09:30PM +0100, Emil Medve wrote: > Portals are used by software running on processor cores, accelerators and > network interfaces to communicate with the BMan What exactly is a portal? Is it a region of shared memory? A device? I only received emails 2 and 3 of this se

Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings

2014-10-07 Thread Mark Rutland
On Tue, Oct 07, 2014 at 05:21:11PM +0100, Rob Landley wrote: > On 10/07/14 00:28, Guenter Roeck wrote: > > Devicetree bindings are supposed to be operating system independent > > and should thus not describe how a specific functionality is implemented > > in Linux. > > So your argument is that lin

Re: [PATCH 06/44] gpio-poweroff: Drop reference to pm_power_off from devicetree bindings

2014-10-07 Thread Mark Rutland
On Tue, Oct 07, 2014 at 06:28:08AM +0100, Guenter Roeck wrote: > pm_power_off is an implementation detail. Replace it with a more generic > description of the driver's functionality. > > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland Acked-by: Mark Rutland &

Re: [PATCH 07/44] qnap-poweroff: Drop reference to pm_power_off from devicetree bindings

2014-10-07 Thread Mark Rutland
On Tue, Oct 07, 2014 at 06:28:09AM +0100, Guenter Roeck wrote: > Replace reference to pm_power_off (which is an implementation detail) > and replace it with a more generic description of the driver's functionality. > > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark R

Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings

2014-10-07 Thread Mark Rutland
On Tue, Oct 07, 2014 at 06:28:07AM +0100, Guenter Roeck wrote: > Devicetree bindings are supposed to be operating system independent > and should thus not describe how a specific functionality is implemented > in Linux. > > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rut

Re: [RFC PATCH] dt:numa: adding numa node mapping for memory nodes.

2014-09-17 Thread Mark Rutland
On Wed, Sep 17, 2014 at 04:37:30PM +0100, Kumar Gala wrote: > > On Sep 17, 2014, at 1:56 AM, Ganapatrao Kulkarni > wrote: > > > From: Ganapatrao Kulkarni > > > > This patch adds property "nid" to memory node to provide the memory range to > > numa node id mapping. > > > > Signed-off-by: Gana

Re: [PATCH v3 2/2] ASoC: fsl_asrc: Add ASRC ASoC CPU DAI and platform drivers

2014-07-29 Thread Mark Rutland
> + - big-endian : If this property is absent, the native endian mode will > + be in use as default, or the big endian mode will be in use > + for all the device registers. Native endian is meaningless. If a CPU supports both BE and LE, there is no native endianne

Re: [PATCH] devicetree/bindings: Add binding for micron n25q512a memory

2014-07-29 Thread Mark Rutland
On Mon, Jul 07, 2014 at 10:25:54PM +0100, Scott Wood wrote: > On Thu, 2014-07-03 at 23:08 -0500, Jain Priyanka-B32167 wrote: > > > > > -Original Message- > > > From: Wood Scott-B07421 > > > Sent: Friday, July 04, 2014 3:40 AM > > > To: Jain Priyanka-B32167 > > > Cc: devicet...@vger.kernel.

Re: [PATCH v2 1/3] dmaengine: mpc512x: add device tree binding document

2014-07-04 Thread Mark Rutland
Hi Alexander, Apologies for the late reply. DT-related email is somewhat a firehose and unfortunately I lose track of things. On Thu, Jun 19, 2014 at 02:59:19PM +0100, Alexander Popov wrote: > 2014-06-18 18:56 GMT+04:00 Alexander Popov : > > 2014-06-18 17:37 GMT+04:00 Mark Rutland : &g

Re: [RFC PATCH v2 4/6] mmc: sdhci: host: add new f_sdh30

2014-06-27 Thread Mark Rutland
On Fri, Jun 27, 2014 at 04:32:21AM +0100, Vincent Yang wrote: > 2014-06-26 19:03 GMT+08:00 Mark Rutland : > > On Thu, Jun 26, 2014 at 07:23:30AM +0100, Vincent Yang wrote: > >> This patch adds new host controller driver for > >> Fujitsu SDHCI controller f_sdh30. >

Re: [RFC PATCH v2 4/6] mmc: sdhci: host: add new f_sdh30

2014-06-26 Thread Mark Rutland
On Thu, Jun 26, 2014 at 07:23:30AM +0100, Vincent Yang wrote: > This patch adds new host controller driver for > Fujitsu SDHCI controller f_sdh30. > > Signed-off-by: Vincent Yang > --- > .../devicetree/bindings/mmc/sdhci-fujitsu.txt | 35 +++ > drivers/mmc/host/Kconfig

Re: [PATCH v2 1/3] dmaengine: mpc512x: add device tree binding document

2014-06-18 Thread Mark Rutland
On Wed, Jun 18, 2014 at 11:48:10AM +0100, Alexander Popov wrote: > Introduce a device tree binding document for the MPC512x DMA controller > > Signed-off-by: Alexander Popov > --- > .../devicetree/bindings/dma/mpc512x-dma.txt| 31 > ++ > 1 file changed, 31 insertions

Re: [PATCH 3/3] of: Handle memory@0 node on PPC32 only

2014-04-23 Thread Mark Rutland
Hi, > > diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig > > index 889005f..230c747 100644 > > --- a/drivers/of/Kconfig > > +++ b/drivers/of/Kconfig > > @@ -77,4 +77,7 @@ config OF_RESERVED_MEM > > help > > Helpers to allow for reservation of memory regions > > > > +config OF

Re: [PATCH 3/3] of: Handle memory@0 node on PPC32 only

2014-04-23 Thread Mark Rutland
On Tue, Apr 22, 2014 at 02:35:15PM +0100, Grant Likely wrote: > On Fri, 18 Apr 2014 13:59:24 +0100, Leif Lindholm > wrote: > > Hi Geert, > > > > On Fri, Apr 18, 2014 at 10:04:15AM +0200, Geert Uytterhoeven wrote: > > > On Thu, Apr 17, 2014 at 7:42 PM, Leif Lindholm > > > wrote: > > > > In orde

Re: [PATCH RFC v9 5/6] dma: mpc512x: add device tree binding document

2014-03-13 Thread Mark Rutland
On Wed, Mar 12, 2014 at 11:47:54AM +, Alexander Popov wrote: > From: Gerhard Sittig > > introduce a device tree binding document for the MPC512x DMA controller > > Signed-off-by: Gerhard Sittig > [ a13xp0p0...@gmail.com: turn this into a separate patch ] > --- > .../devicetree/bindings/dma

Re: [PATCH 4/7] ECHI Platform: Merge ppc-of EHCI driver into the ehci-platform driver

2014-02-21 Thread Mark Rutland
[Adding Tony Prisk to Cc] On Fri, Feb 21, 2014 at 06:31:30AM +, Alistair Popple wrote: > Currently the ppc-of driver uses the compatibility string > "usb-ehci". This means platforms that use device-tree and implement an > EHCI compatible interface have to either use the ppc-of driver or add >

Re: [PATCH 2/7] IBM Akebono: Add support for a new PHY interface to the IBM emac driver

2014-02-21 Thread Mark Rutland
On Fri, Feb 21, 2014 at 06:31:28AM +, Alistair Popple wrote: > The IBM PPC476GTR SoC that is used on the Akebono board uses a > different ethernet PHY interface that has wake on lan (WOL) support > with the IBM emac. This patch adds support to the IBM emac driver for > this new PHY interface. >

Re: 答复: [v7] clk: corenet: Adds the clock binding

2014-01-08 Thread Mark Rutland
On Wed, Jan 08, 2014 at 08:53:56AM +, Yuantian Tang wrote: > > > 发件人: Wood Scott-B07421 > 发送时间: 2014年1月8日 8:21 > 收件人: Tang Yuantian-B29983 > 抄送: ga...@kernel.crashing.org; mark.rutl...@arm.com; > devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.or

Re: [PATCH 1/2] powerpc/dts: fix lbc lack of error interrupt

2014-01-07 Thread Mark Rutland
On Tue, Jan 07, 2014 at 06:26:42AM +, Dongsheng Wang wrote: > From: Wang Dongsheng > > P1020, P1021, P1022, P1023 when the lbc get error, the error > interrupt will be triggered. The corresponding interrupt is > internal IRQ0. So system have to process the lbc IRQ0 interrupt. > > The corresp

Re: [PATCH v6 08/17] spi: mpc512x: adjust to OF based clock lookup

2013-12-02 Thread Mark Rutland
On Sat, Nov 30, 2013 at 10:51:28PM +, Gerhard Sittig wrote: > after device tree based clock lookup became available, the peripheral > driver need no longer construct clock names which include the PSC index, > remove the "psc%d_mclk" template and unconditionally use 'mclk' > > acquire and relea

Re: [PATCH v6 02/17] dts: mpc512x: introduce dt-bindings/clock/ header

2013-12-02 Thread Mark Rutland
with this, pointing out that this include file defines the set of clock IDs for the MPC512x clocks. Otherwise, this looks fine to me. Mark. > > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland > Cc: Stephen Warren > Cc: Ian Campbell > Cc: devicet...@vger.kernel.org

<    1   2   3   >