On Mon, May 27, 2019 at 09:20:01AM +0200, Michal Hocko wrote:
> On Wed 22-05-19 17:42:13, Mark Rutland wrote:
> > On Thu, May 16, 2019 at 01:05:29PM +0200, Michal Hocko wrote:
> > > On Thu 16-05-19 11:23:54, Mark Rutland wrote:
> > > > On Wed, May 15, 2019 at 06:58:
On Fri, May 24, 2019 at 05:12:40PM +0100, Dave Martin wrote:
> On Fri, May 24, 2019 at 04:38:48PM +0100, Mark Rutland wrote:
> > On Fri, May 24, 2019 at 03:53:06PM +0100, Dave Martin wrote:
> > > On Fri, May 24, 2019 at 02:02:17PM +0100, Mark Rutland wrote:
> > > >
On Fri, May 24, 2019 at 03:53:06PM +0100, Dave Martin wrote:
> On Fri, May 24, 2019 at 02:02:17PM +0100, Mark Rutland wrote:
> > On Fri, May 24, 2019 at 11:25:29AM +0100, Dave Martin wrote:
> > > +#define arch_calc_vm_prot_bits(prot, pkey) arm64_calc_vm_prot_bits(prot)
&g
On Thu, May 23, 2019 at 06:01:14PM -0700, Saravana Kannan wrote:
> The depends-on property is used to list the mandatory functional
> dependencies of a consumer device on zero or more supplier devices.
>
> Signed-off-by: Saravana Kannan
> ---
> .../devicetree/bindings/depends-on.txt| 26
Hi Dave,
This generally looks good, but I have a few comments below.
On Fri, May 24, 2019 at 11:25:29AM +0100, Dave Martin wrote:
> +#define arch_calc_vm_prot_bits(prot, pkey) arm64_calc_vm_prot_bits(prot)
> +static inline unsigned long arm64_calc_vm_prot_bits(unsigned long prot)
> +{
> + if
trying to suport that in other
implementations was painful, so aligning on a non-returning version
sounds reasonable to me.
>
> Suggested-by: Mark Rutland
> Signed-off-by: Andrea Parri
> Cc: Arnd Bergmann
> Cc: Greg Kroah-Hartman
> Cc: Jorgen Hansen
> Cc: Peter Zijlstra
&g
On Tue, May 21, 2019 at 05:20:04PM +0800, Tengfei Fan wrote:
> While printing a task's backtrace and this task isn't
> current task, it is possible that task's fp and fp+8
> have the same value, so cannot break the while loop.
> This can break while loop if this task had been
> rescheduled during
Hi,
This appears to be a bizarrely formatted reply to Anshuman's questions
[1] on the first posting [2] of this patch, and as it stands, it isn't
possible to follow.
Please follow the usual mailing list ettiquette, and reply inline to
questions.
I am not going to reply further to this post, but
On Thu, May 16, 2019 at 02:35:47AM +, Lei Wang wrote:
> From: Lei Wang
>
> This is the device tree bindings for new EDAC driver dmc520_edac.c.
>
> Signed-off-by: Lei Wang
> ---
> .../devicetree/bindings/edac/arm-dmc520.txt| 26
> ++
> 1 file changed, 26
> Signed-off-by: Andrea Parri
> > Cc: "Paul E. McKenney"
> > Cc: Josh Triplett
> > Cc: Steven Rostedt
> > Cc: Mathieu Desnoyers
> > Cc: Lai Jiangshan
> > Cc: Joel Fernandes
> > Cc: r...@vger.kernel.org
> > Cc: Peter Zijlstra
>
On Wed, May 22, 2019 at 11:18:59PM +0200, Arnd Bergmann wrote:
> On Wed, May 22, 2019 at 3:23 PM Mark Rutland wrote:
> >
> > Currently architectures return inconsistent types for atomic64 ops. Some
> > return
> > long (e..g. powerpc), some return long long (e.g
On Wed, May 22, 2019 at 12:06:31PM -0700, Palmer Dabbelt wrote:
> On Wed, 22 May 2019 06:22:44 PDT (-0700), mark.rutl...@arm.com wrote:
> > As a step towards making the atomic64 API use consistent types treewide,
> > let's have the s390 atomic64 implementation use s64 as the underlying
>
> and
On Thu, May 23, 2019 at 10:30:13AM +0200, Andrea Parri wrote:
> Hi Mark,
Hi Andrea,
> On Wed, May 22, 2019 at 02:22:32PM +0100, Mark Rutland wrote:
> > Currently architectures return inconsistent types for atomic64 ops. Some
> > return
> > long (e..g. powerpc), some re
On Thu, May 16, 2019 at 01:05:29PM +0200, Michal Hocko wrote:
> On Thu 16-05-19 11:23:54, Mark Rutland wrote:
> > Hi Michal,
> >
> > On Wed, May 15, 2019 at 06:58:47PM +0200, Michal Hocko wrote:
> > > On Tue 14-05-19 14:30:05, Anshuman Khandual wrote:
> > &
Hi Liming,
On Fri, May 17, 2019 at 01:49:04PM -0400, Liming Sun wrote:
> This commit adds the bootctl platform driver for Mellanox BlueField
> Soc, which controls the eMMC boot partition swapping and sends SMC
> calls to ATF running at exception level EL3 to program some system
> register. This
Now that atomic64_read() returns s64 consistently, we don't need to
explicitly cast its return value. Drop the redundant casts.
Signed-off-by: Mark Rutland
Cc: Herbert Xu
Cc: Peter Zijlstra
Cc: Will Deacon
---
drivers/crypto/nx/nx-842-pseries.c | 6 +++---
1 file changed, 3 insertions(+), 3
Now that atomic64_read() returns s64 consistently, we don't need to
explicitly cast its return value. Drop the redundant casts.
Signed-off-by: Mark Rutland
Cc: Heiko Carstens
Cc: Peter Zijlstra
Cc: Will Deacon
---
arch/s390/pci/pci_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
sts previously required to ensure consistent types.
Signed-off-by: Mark Rutland
Cc: Peter Zijlstra
Cc: Will Deacon
---
include/linux/types.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/types.h b/include/linux/types.h
index 231114ae38f4..05030f608be3 100
by the
generic instrumented atomic64 implementation, which uses s64
consistently.
Otherwise, there should be no functional change as a result of this
patch.
Signed-off-by: Mark Rutland
Cc: Borislav Petkov
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Russell King
Cc: Thomas Gleixner
Cc: Will Deacon
returns long on 64-bit. This will be converted in a subsequent
patch.
Otherwise, there should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland
Cc: Albert Ou
Cc: Palmer Dabbelt
Cc: Peter Zijlstra
Cc: Will Deacon
---
arch/riscv/include/asm/atomic.h | 44
.
Signed-off-by: Mark Rutland
Cc: Albert Ou
Cc: Palmer Dabbelt
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: sta...@vger.kernel.org
---
arch/riscv/include/asm/atomic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/include/asm/atomic.h b/arch/riscv/include/asm/atomic.h
returns long. This will be converted in a subsequent patch.
Otherwise, there should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland
Cc: David S. Miller
Cc: Peter Zijlstra
Cc: Will Deacon
---
arch/sparc/include/asm/atomic_64.h | 8
1 file changed, 4
to __atomic64_*() ops.
Otherwise, there should be no functional change as a result of this
patch.
Signed-off-by: Mark Rutland
Cc: Heiko Carstens
Cc: Peter Zijlstra
Cc: Will Deacon
---
arch/s390/include/asm/atomic.h | 38 +++---
1 file changed, 19 insertions
.
Signed-off-by: Mark Rutland
Cc: Peter Zijlstra
Cc: Russell King
Cc: Will Deacon
---
arch/arm/include/asm/atomic.h | 50 +--
1 file changed, 24 insertions(+), 26 deletions(-)
diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
index
-by: Mark Rutland
Cc: Catalin Marinas
Cc: Peter Zijlstra
Cc: Will Deacon
---
arch/arm64/include/asm/atomic_ll_sc.h | 20 ++--
arch/arm64/include/asm/atomic_lse.h | 34 +-
2 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/arch/arm64
returns long on 64-bit. This will be converted in a subsequent
patch.
Otherwise, there should be no functional change as a result of this
patch.
Signed-off-by: Mark Rutland
Cc: Michael Ellerman
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Will Deacon
---
arch/powerpc/include/asm/atomic.h | 44
, this
still returns long on 64-bit. This will be converted in a subsequent
patch.
Otherwise, there should be no functional change as a result of this
patch.
Signed-off-by: Mark Rutland
Cc: James Hogan
Cc: Paul Burton
Cc: Peter Zijlstra
Cc: Ralf Baechle
Cc: Will Deacon
---
arch/mips/include/asm
, this
still returns long. This will be converted in a subsequent patch.
Otherwise, there should be no functional change as a result of this
patch.
Signed-off-by: Mark Rutland
Cc: Fenghua Yu
Cc: Peter Zijlstra
Cc: Tony Luck
Cc: Will Deacon
---
arch/ia64/include/asm/atomic.h | 20
.
Signed-off-by: Mark Rutland
Cc: Peter Zijlstra
Cc: Will Deacon
---
include/asm-generic/atomic64.h | 20 ++--
lib/atomic64.c | 32
2 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/include/asm-generic/atomic64.h b
returns long. This will be converted in a subsequent patch.
Otherwise, there should be no functional change as a result of this
patch.
Signed-off-by: Mark Rutland
Cc: Ivan Kokshaysky
Cc: Matt Turner
Cc: Peter Zijlstra
Cc: Richard Henderson
Cc: Will Deacon
---
arch/alpha/include/asm/atomic.h
-off-by: Mark Rutland
Cc: Peter Zijlstra
Cc: Vineet Gupta
Cc: Will Deacon
---
arch/arc/include/asm/atomic.h | 41 -
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/arch/arc/include/asm/atomic.h b/arch/arc/include/asm/atomic.h
index
will make the atomic64 API
consistently use s64.
As a preparatory step, this patch updates the nx-842 code to treat the
return value of atomic64_read() as s64, using explicit casts. These
casts will be removed once the s64 conversion is complete.
Signed-off-by: Mark Rutland
Cc: Herbert Xu
Cc
will make the atomic64 API
consistently use s64.
As a preparatory step, this patch updates the s390 pci debug code to
treat the return value of atomic64_read() as s64, using an explicit
cast. This cast will be removed once the s64 conversion is complete.
Signed-off-by: Mark Rutland
Cc: Heiko
/type-cleanup
branch [3] on kernel.org.
Thanks,
Mark.
[1] https://lkml.kernel.org/r/20190310183051.87303-1-...@lca.pw
[2]
https://lkml.kernel.org/r/20190313091844.ga24...@hirez.programming.kicks-ass.net
[3] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git
atomics/type-cleanup
Mark
On Thu, May 16, 2019 at 02:21:45PM +0100, Raphael Gault wrote:
> In order to be able to access the counter directly for userspace,
> we need to provide the index of the counter using the userpage.
> We thus need to override the event_idx function to retrieve and
> convert the perf_event index to
On Fri, May 17, 2019 at 09:10:18AM +0200, Peter Zijlstra wrote:
> On Thu, May 16, 2019 at 02:21:46PM +0100, Raphael Gault wrote:
> > In order to prevent the userspace processes which are trying to access
> > the registers from the pmu registers on a big.LITTLE environment we
> > introduce a hook
On Thu, May 16, 2019 at 09:37:05AM -0500, Rob Herring wrote:
> On Thu, May 16, 2019 at 5:28 AM Hsin-Yi Wang wrote:
> >
> > Basically does similar things like __fixmap_remap_fdt(). It's supposed
> > to be called after fixmap_remap_fdt() is called at least once, so region
> > checking can be
On Thu, May 16, 2019 at 03:20:59PM +0100, Steven Price wrote:
> On 16/05/2019 15:16, Mark Rutland wrote:
> > On Thu, May 16, 2019 at 03:05:31PM +0100, Steven Price wrote:
> >> I suspect the following is sufficient to fix the problem:
> >>
> >> 8<-
&g
On Thu, May 16, 2019 at 05:13:14PM +0300, Mike Rapoport wrote:
> On Thu, May 16, 2019 at 02:41:06PM +0100, Mark Rutland wrote:
> > On Thu, May 16, 2019 at 02:38:20PM +0100, Mark Rutland wrote:
> > > Hi,
> > >
> > > Since commit:
> > >
> > &
On Thu, May 16, 2019 at 03:05:31PM +0100, Steven Price wrote:
> On 16/05/2019 14:41, Mark Rutland wrote:
> > On Thu, May 16, 2019 at 02:38:20PM +0100, Mark Rutland wrote:
> >> Hi,
> >>
> >> Since commit:
> >>
> >> 54c7a8916a887f35 ("i
On Thu, May 16, 2019 at 02:38:20PM +0100, Mark Rutland wrote:
> Hi,
>
> Since commit:
>
> 54c7a8916a887f35 ("initramfs: free initrd memory if opening /initrd.image
> fails")
Ugh, I dropped a paragarph here.
Since that commit, I'm seeing a boot-ti
Hi,
Since commit:
54c7a8916a887f35 ("initramfs: free initrd memory if opening /initrd.image
fails")
IIUC prior to that commit, we'd only attempt to free an intird if we had
one, whereas now we do so unconditionally. AFAICT, in this case
initrd_start has not been initialized (I'm not using an
On Thu, May 16, 2019 at 11:04:48AM +0530, Anshuman Khandual wrote:
> On 05/15/2019 05:19 PM, Mark Rutland wrote:
> > On Tue, May 14, 2019 at 02:30:07PM +0530, Anshuman Khandual wrote:
> >> Memory removal from an arch perspective involves tearing down two different
> >>
Hi Michal,
On Wed, May 15, 2019 at 06:58:47PM +0200, Michal Hocko wrote:
> On Tue 14-05-19 14:30:05, Anshuman Khandual wrote:
> > The arm64 pagetable dump code can race with concurrent modification of the
> > kernel page tables. When a leaf entries are modified concurrently, the dump
> > code may
Hi Anshuman,
On Tue, May 14, 2019 at 02:30:07PM +0530, Anshuman Khandual wrote:
> Memory removal from an arch perspective involves tearing down two different
> kernel based mappings i.e vmemmap and linear while releasing related page
> table and any mapped pages allocated for given physical
On Tue, May 14, 2019 at 02:30:05PM +0530, Anshuman Khandual wrote:
> The arm64 pagetable dump code can race with concurrent modification of the
> kernel page tables. When a leaf entries are modified concurrently, the dump
> code may log stale or inconsistent information for a VA range, but this is
On Thu, May 09, 2019 at 09:50:04AM +0100, Catalin Marinas wrote:
> Hi,
>
> On Wed, May 08, 2019 at 11:45:03AM -0700, Salman Qazi wrote:
> > What is the intention behind icache_is_aliasing on big.LITTLE systems
> > where some icaches are VIPT and others are PIPT? Is it meant to be
> > conservative
On Fri, May 03, 2019 at 12:12:25PM -0700, Sami Tolvanen wrote:
> Calling sys_ni_syscall through a syscall_fn_t pointer trips indirect
> call Control-Flow Integrity checking due to a function type
> mismatch. Use SYSCALL_DEFINE0 for __arm64_sys_ni_syscall instead and
> remove the now unnecessary
On Wed, May 01, 2019 at 01:04:51PM -0700, Sami Tolvanen wrote:
> Although a syscall defined using SYSCALL_DEFINE0 doesn't accept
> parameters, use the correct function type to avoid indirect call
> type mismatches with Control-Flow Integrity checking.
Generally, this makes sense, but I'm not sure
_t)(const struct pt_regs *regs);
For a second I was worried that we modify the regs to assign the return
value, but I see we do that in the syscall.c wrapper, where the pt_regs
argument isn't const.
We certainly chouldn't need to modify the regs when acquiring the
arguments, and as above this matches ,
On Wed, May 01, 2019 at 10:41:52PM +0530, Anup Patel wrote:
> On Wed, May 1, 2019 at 10:30 PM Mark Rutland wrote:
> >
> > On Mon, Apr 29, 2019 at 10:42:40PM -0700, Atish Patra wrote:
> > > On 4/29/19 4:40 PM, Palmer Dabbelt wrote:
> > > > On Tue, 23 Apr
On Mon, Apr 29, 2019 at 10:42:40PM -0700, Atish Patra wrote:
> On 4/29/19 4:40 PM, Palmer Dabbelt wrote:
> > On Tue, 23 Apr 2019 16:25:06 PDT (-0700), atish.pa...@wdc.com wrote:
> > > Currently, last stage boot loaders such as U-Boot can accept only
> > > uImage which is an unnecessary additional
On Wed, May 01, 2019 at 09:29:25AM -0600, Jens Axboe wrote:
> On 5/1/19 9:09 AM, Mark Rutland wrote:
> > I've manually minimized that to C below. AFAICT, that hits a leak, which
> > is what's triggering the OOM after the program is run a number of times
> > with the previ
s to
update_early_cpu_boot_status, to use a w register, but either way:
Acked-by: Mark Rutland
Mark.
>
> .popsection
>
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
tic inline bool arch_timer_set_evtstrm_feature(void)
> +{
> + elf_hwcap |= HWCAP_EVTSTRM;
> +#ifdef CONFIG_COMPAT
> + compat_elf_hwcap |= COMPAT_HWCAP_EVTSTRM;
> +#endif
This can go; 32-bit arm doesn't have COMPAT.
Otherwise, this looks good to me, so with those
On Tue, Apr 30, 2019 at 03:38:31PM -0700, Florian Fainelli wrote:
> Similar to commits c68b0274fb3cf ("ARM: reduce "Booted secondary
> processor" message to debug level") and 035e787543de7 ("ARM: 8644/1: Reduce
> "CPU:
> shutdown" message to debug level"), demote the secondary_start_kernel()
>
On Tue, Apr 30, 2019 at 10:22:23AM -0600, Jens Axboe wrote:
> On 4/30/19 10:20 AM, Mark Rutland wrote:
> > - io_mem_free(ctx->sq_ring);
> > - io_mem_free(ctx->sq_sqes);
> > - io_mem_free(ctx->cq_ring);
> > + if (ctx->sq_ring)
> > +
On Mon, Apr 29, 2019 at 11:31:26AM -0400, Liang, Kan wrote:
>
>
> On 4/29/2019 11:12 AM, Mark Rutland wrote:
> > On Mon, Apr 29, 2019 at 07:44:03AM -0700, kan.li...@linux.intel.com wrote:
> > > From: Kan Liang
> > >
> > > A fast path will be intro
On Mon, Apr 29, 2019 at 07:44:03AM -0700, kan.li...@linux.intel.com wrote:
> From: Kan Liang
>
> A fast path will be introduced in the following patches to speed up the
> cgroup events sched in, which only needs a simpler filter_match().
>
> Add filter_match() as a parameter for
On Mon, Apr 29, 2019 at 07:44:02AM -0700, kan.li...@linux.intel.com wrote:
> From: Kan Liang
>
> When counting system-wide events and cgroup events simultaneously, the
> value of system-wide events are miscounting. For example,
>
> perf stat -e cycles,instructions -e cycles,instructions -G
osstool GCC 8.1.0
toolchain, and I can confirm defconfig compiels cleanly and works as
expected. AFAICT, all usage in inline assembly has been updated, and the
removal of explicit stringification makes usage a bit easier to read,
which is a nice bonus!
I don't think we can make this any cleaner shor
On Wed, Apr 24, 2019 at 05:45:38PM +0100, Will Deacon wrote:
> On Wed, Apr 24, 2019 at 11:25:00AM -0400, Mathieu Desnoyers wrote:
> > +/*
> > + * aarch64 -mbig-endian generates mixed endianness code vs data:
> > + * little-endian code and big-endian data. Ensure the RSEQ_SIG signature
> > + *
On Wed, Apr 24, 2019 at 05:40:33PM +0100, Mark Rutland wrote:
> On Wed, Apr 24, 2019 at 11:25:00AM -0400, Mathieu Desnoyers wrote:
> > +/*
> > + * aarch64 -mbig-endian generates mixed endianness code vs data:
> > + * little-endian code and big-endian data. Ensure t
On Wed, Apr 24, 2019 at 11:25:00AM -0400, Mathieu Desnoyers wrote:
> Handle compiling with -mbig-endian on aarch64, which generates binaries
> with mixed code vs data endianness (little endian code, big endian
> data).
>
> Else mismatch between code endianness for the generated signatures and
>
On Wed, Apr 24, 2019 at 06:21:03PM +0800, Weikang shi wrote:
> From: swkhack
>
> The function lkdtm_WRITE_AFTER_FREE calls kfree(base) to free the memory
> of base. However, following kfree(base),
> it write the memory which base point to via base[offset] = 0x0abcdef0. This
> may result in a
>
Hi,
On Wed, Apr 24, 2019 at 05:59:52PM +0800, Weikang shi wrote:
> From: swkhack
>
> The function lkdtm_READ_AFTER_FREE calls kfree(base) to free the memory
> of base. However, following kfree(base),
> it access the memory which base point to via base[offset]. This may result in
> a
>
On Wed, Apr 24, 2019 at 11:29:28AM +0530, Anshuman Khandual wrote:
> On 04/23/2019 09:35 PM, Mark Rutland wrote:
> > On Tue, Apr 23, 2019 at 01:01:58PM +0530, Anshuman Khandual wrote:
> >> Generic usage for init_mm.pagetable_lock
> >>
> >> Unless I have missed
Hi Kees,
On Tue, Apr 23, 2019 at 04:26:22PM -0700, Kees Cook wrote:
> Clang's integrated assembler does not allow assembly macros defined
> in one inline asm block using the .macro directive to be used across
> separate asm blocks. LLVM developers consider this a feature and not a
> bug,
On Tue, Apr 23, 2019 at 06:04:45PM +0100, Will Deacon wrote:
> On Thu, Apr 18, 2019 at 12:28:18PM +0100, Mark Rutland wrote:
> > [adding linux-arch and relevant folk]
> >
> > On Wed, Apr 17, 2019 at 08:35:25PM +0800, Boyang Zhou wrote:
> > > The error information i
On Tue, Apr 23, 2019 at 01:01:58PM +0530, Anshuman Khandual wrote:
> Generic usage for init_mm.pagetable_lock
>
> Unless I have missed something else these are the generic init_mm kernel page
> table
> modifiers at runtime (at least which uses init_mm.page_table_lock)
>
> 1.
On Mon, Apr 22, 2019 at 10:44:10AM -0700, Nick Desaulniers wrote:
> On Tue, Apr 16, 2019 at 9:03 PM Kees Cook wrote:
> >
> > On Tue, Apr 16, 2019 at 12:08 PM Mark Rutland wrote:
> > >
> > > On Mon, Apr 15, 2019 at 10:22:27AM -0700, Nick Desaulniers wrote:
> &g
On Thu, Apr 11, 2019 at 10:37:51AM -0700, Dhaval Giani wrote:
> Hi Folks,
>
> This is a call for participation for the Linux Testing microconference
> at LPC this year.
>
> For those who were at LPC last year, as the closing panel mentioned,
> testing is probably the next big push needed to
[adding linux-arch and relevant folk]
On Wed, Apr 17, 2019 at 08:35:25PM +0800, Boyang Zhou wrote:
> The error information is that “offset value too large for defined data type”.
> Reason:
> On the X86 platform, the data type of “off" is unsigned long; but on the
> ARM64 platform, the data type
On Wed, Apr 17, 2019 at 10:15:35PM +0530, Anshuman Khandual wrote:
> On 04/17/2019 07:51 PM, Mark Rutland wrote:
> > On Wed, Apr 17, 2019 at 03:28:18PM +0530, Anshuman Khandual wrote:
> >> On 04/15/2019 07:18 PM, Mark Rutland wrote:
> >>> On Sun, Apr 14, 2019 at 11:29
On Wed, Apr 17, 2019 at 03:28:18PM +0530, Anshuman Khandual wrote:
> On 04/15/2019 07:18 PM, Mark Rutland wrote:
> > On Sun, Apr 14, 2019 at 11:29:13AM +0530, Anshuman Khandual wrote:
> >> Memory removal from an arch perspective involves tearing down two different
> >>
On Mon, Apr 15, 2019 at 10:22:27AM -0700, Nick Desaulniers wrote:
> On Mon, Apr 15, 2019 at 10:06 AM Mark Rutland wrote:
> > On Mon, Apr 15, 2019 at 07:38:21AM -0700, Kees Cook wrote:
> > > diff --git a/arch/arm64/include/asm/irqflags.h
> > > b/arch/arm64/include
On Mon, Apr 15, 2019 at 10:22:27AM -0700, Nick Desaulniers wrote:
> On Mon, Apr 15, 2019 at 10:06 AM Mark Rutland wrote:
> > It would be nice if we could simply rely on a more recent binutils these
> > days, which supports the generic S sysreg
> > definition. That would
On Mon, Apr 15, 2019 at 07:38:21AM -0700, Kees Cook wrote:
> From: Alex Matveev
>
> Clang's integrated assembler does not allow assembly macros defined
> in one inline asm block using the .macro directive to be used across
> separate asm blocks. LLVM developers consider this a feature and not a
On Fri, Apr 12, 2019 at 12:31:10PM +0200, Dmitry Vyukov wrote:
> On Fri, Apr 12, 2019 at 12:27 PM Mark Rutland wrote:
> >
> > The help text for CONFIG_ARCH_HAS_KCOV is stale, and describes the
> > feature as being enabled only for x86_64, when it is now enabled for
>
Hi Anshuman,
On Sun, Apr 14, 2019 at 11:29:13AM +0530, Anshuman Khandual wrote:
> Memory removal from an arch perspective involves tearing down two different
> kernel based mappings i.e vmemmap and linear while releasing related page
> table pages allocated for the physical memory range to be
On Fri, Apr 12, 2019 at 09:19:18AM -0600, Jeffrey Hugo wrote:
> > > + keyboard@3a {
> > > + /* QTEC0001 is the ACPI HID, which could be used for quirks
> > > */
> > > + compatible = "QTEC0001", "hid-over-i2c";
> >
> > As mentioned last time, please drop the ACPI HID,
On Thu, Apr 11, 2019 at 01:51:44PM -0700, Jeffrey Hugo wrote:
> This adds the initial DT for the Lenovo Miix 630 laptop. Supported
> functionality includes USB (host), microSD-card, keyboard, and trackpad.
>
> Signed-off-by: Jeffrey Hugo
> ---
>
> v2:
> -Changed "cls" to "clam" since feedback
for ARCH_HAS_FORTIFY_SOURCE, better describing when an architecture
should select CONFIG_ARCH_HAS_KCOV.
Signed-off-by: Mark Rutland
Cc: Andrew Morton
Cc: Dmitry Vyukov
Cc: Kees Cook
---
lib/Kconfig.debug | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
s is defined as part of architectural resets by the specification.
>
> This patch implements support for SYSTEM_RESET2 by making using of
> reboot_mode passed by the reboot infrastructure in the kernel.
>
> Cc: Mark Rutland
> Cc: Lorenzo Pieralisi
> Signed-off-by: Sudeep Holla
On Tue, Apr 09, 2019 at 06:12:04PM +0200, Peter Zijlstra wrote:
>
> I'm just doing my initial read-through,.. however
>
> On Tue, Apr 09, 2019 at 02:52:40PM +0100, Raphael Gault wrote:
> > + if (!(sec->sh.sh_flags & SHF_EXECINSTR)
> > + && (strcmp(sec->name,
that we can
> tell which CPU requested the disable. This then allows us to detect
> the above scenario and even redirect the IPI to make up for the failed
> queue.
>
> Cc: Heiko Carstens
> Cc: Kees Cook
> Cc: Hendrik Brueckner
> Cc: a...@redhat.com
> Cc: Martin Schwidef
ther any CPU in the system has a
> workaround for the counter. This is done by having an atomic
> variable tracking this.
>
> Signed-off-by: Marc Zyngier
Acked-by: Mark Rutland
Mark.
> ---
> arch/arm/include/asm/arch_timer.h| 14 ++--
> arch/arm64/include/asm/arch_ti
>
> Signed-off-by: Marc Zyngier
Acked-by: Mark Rutland
Mark.
> ---
> arch/arm64/include/asm/arch_timer.h | 4
> drivers/clocksource/arm_arch_timer.c | 25 +++--
> 2 files changed, 7 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm64/i
On Mon, Apr 08, 2019 at 04:49:05PM +0100, Marc Zyngier wrote:
> Let's start with the removal of the arch_timer_read_ool_enabled
> static key in arch_timer_reg_read_stable. IT is not a fast path,
Nit: s/IT/It/
> and we can simplify things a bit.
>
> Signed-off-by: Marc Zyngier
; if we have a workaround associated to that CPU.
>
> Signed-off-by: Marc Zyngier
Acked-by: Mark Rutland
Mark.
> ---
> arch/arm/include/asm/arch_timer.h| 4 +++
> arch/arm64/include/asm/arch_timer.h | 16 ++
> drivers/clocksource/arm_arch_timer.c | 46 +--
On Mon, Apr 08, 2019 at 04:49:03PM +0100, Marc Zyngier wrote:
> Only arch_timer_read_counter will guarantee that workarounds are
> applied. So let's use this one instead of arch_counter_get_cntvct.
>
> Signed-off-by: Marc Zyngier
Acked-by: Mark Rutland
Mark.
> ---
>
On Mon, Apr 08, 2019 at 04:49:02PM +0100, Marc Zyngier wrote:
> Only arch_timer_read_counter will guarantee that workarounds are
> applied. So let's use this one instead of arch_counter_get_cntvct.
>
> Signed-off-by: Marc Zyngier
Acked-by: Mark Rutland
Mark.
> ---
>
4.1.34. The
rest also looks sound, so with that typo fixed:
Reviewed-by: Mark Rutland
Mark.
> +
> extern unsigned long cr_alignment; /* defined in entry-armv.S */
>
> static inline unsigned long get_cr(void)
> diff --git a/arch/arm/vdso/vgettimeofday.c b/arch/arm/vdso/vgettimeofd
On Mon, Mar 11, 2019 at 12:49:46PM +0100, Torsten Duwe wrote:
> On Wed, Feb 13, 2019 at 11:11:04AM +, Julien Thierry wrote:
> > Hi Torsten,
> >
> > On 08/02/2019 15:08, Torsten Duwe wrote:
> > > Patch series v8, as discussed.
> > > The whole series applies cleanly on 5.0-rc5
>
> So what's
On Fri, Feb 08, 2019 at 04:10:14PM +0100, Torsten Duwe wrote:
> In preparation for arm64 supporting ftrace built on other compiler
> options, let's have makefiles remove the $(CC_FLAGS_FTRACE)
> flags, whatever these may be, rather than assuming '-pg'.
>
> There should be no functional
On Tue, Mar 26, 2019 at 11:55:25AM -0700, Jeffrey Hugo wrote:
> This adds the initial DT for the Lenovo Miix 630 laptop. Supported
> functionality includes USB (host), microSD-card, keyboard, and trackpad.
I was under the impression that the Miix 630 came with Windows, and the
firmware therefore
On Mon, Apr 01, 2019 at 09:14:43PM +0300, Aaro Koskinen wrote:
> From: Aaro Koskinen
>
> Add support for warm reset using SYSTEM_RESET2 introduced in PSCI
> 1.1 specification.
For reference, how do you intend to use this?
>
> Signed-off-by: Aaro Koskinen
> ---
> drivers/firmware/psci.c |
Hi Torsten,
Sorry for the long delay prior to this reply.
On Fri, Jan 18, 2019 at 05:39:08PM +0100, Torsten Duwe wrote:
> Once gcc8 adds 2 NOPs at the beginning of each function, replace the
> first NOP thus generated with a quick LR saver (move it to scratch reg
> x9), so the 2nd replacement
On Thu, Mar 21, 2019 at 01:02:27PM -0700, Sodagudi Prasad wrote:
> On 2019-03-21 06:34, Julien Thierry wrote:
> > Hi Prasad,
> >
> > On 21/03/2019 02:07, Prasad Sodagudi wrote:
> > > Preserves the bitfields of PMCR_EL0(AArch64) during PMU reset.
> > > Reset routine should write a 1 to PMCR.C and
e, %ld data)\n",
> + vdso_pages + 1, vdso_pages, 1L);
It's probably better to drop this pr_info() entirely. The number of data and
code pages hasn't changed since this was upstreamed, and the pointers were the
useful part for debugging.
If you respin this to delete the pr_info() entirely, then feel free to add:
Acked-by: Mark Rutland
Mark.
601 - 700 of 8690 matches
Mail list logo
