-a20.dtsi
> @@ -199,7 +199,7 @@
> };
>
> pmu {
> - compatible = "arm,cortex-a7-pmu", "arm,cortex-a15-pmu";
> + compatible = "arm,cortex-a7-pmu";
> interrupts = ,
>;
Acked-by: Will Deacon
Will
Hi Peter,
On Thu, Dec 06, 2018 at 04:08:50PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 30, 2018 at 05:34:29PM +0000, Will Deacon wrote:
> > This is version two of the patches I originally posted here:
> >
> >
> > http://lkml.kernel.org/r/1543347902-21170-1-git-sen
Hi Alex,
Thanks for running these tests and providing the in-depth analysis.
On Mon, Dec 03, 2018 at 09:20:25PM +, Alexander Van Brunt wrote:
> > If we roll a TLB invalidation routine without the trailing DSB, what sort of
> > performance does that get you?
>
> It is not as good. In some cas
On Fri, Dec 07, 2018 at 09:18:47AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the arm64 tree got a conflict in:
>
> arch/arm64/kernel/cpu_errata.c
>
> between commit:
>
> ce8c80c536da ("arm64: Add workaround for Cortex-A76 erratum 1286807")
>
> from Linus' tre
On Thu, Nov 22, 2018 at 03:10:57AM +, k...@linuxonhyperv.com wrote:
> From: Michael Kelley
>
> Add ARM64-specific code to enable Hyper-V. This code includes:
> * Detecting Hyper-V and initializing the guest/Hyper-V interface
> * Setting up Hyper-V's synthetic clocks
> * Making hypercalls usin
Hi all,
On Thu, Nov 22, 2018 at 03:10:56AM +, k...@linuxonhyperv.com wrote:
> From: Michael Kelley
>
> hyperv-tlfs.h defines Hyper-V interfaces from the Hyper-V Top Level
> Functional Spec (TLFS). The TLFS is distinctly oriented to x86/x64,
> and Hyper-V has not separated out the architectur
On Thu, Dec 06, 2018 at 08:42:03PM +, Alexander Van Brunt wrote:
> > > > If we roll a TLB invalidation routine without the trailing DSB, what
> > > >sort of
> > > > performance does that get you?
> > >
> > > It is not as good. In some cases, it is really bad. Skipping the
> > > invalidate wa
resulting from incorrect use
> of conditional GAS directives.
>
> Patches #1 to #3 are groundwork for #4.
>
> Cc: Robin Murphy
> Cc: Will Deacon
> Cc: Catalin Marinas
> Cc: Marc Zyngier
> Cc: Suzuki Poulose
> Cc: Dave Martin
>
> Ard Biesheuvel (5):
>
Hi Ganapat,
On Thu, Dec 06, 2018 at 11:51:24AM +, Kulkarni, Ganapatrao wrote:
> This patchset adds PMU driver for Cavium's ThunderX2 SoC UNCORE devices.
> The SoC has PMU support in L3 cache controller (L3C) and in the
> DDR4 Memory Controller (DMC).
>
>
> v11:
> Updated Patch 2 with m
On Tue, Dec 04, 2018 at 05:29:56PM +0100, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Use the new helpers dev_iommu_fwspec_get()/set() to access
> the dev->iommu_fwspec pointer. This makes it easier to move
> that pointer later into another struct.
>
> Cc: Will De
On Wed, Dec 05, 2018 at 09:42:04AM -0600, Rob Herring wrote:
> On Wed, Dec 5, 2018 at 4:08 AM Will Deacon wrote:
> > On Mon, Dec 03, 2018 at 03:31:57PM -0600, Rob Herring wrote:
> > > +properties:
> > > + compatible:
> > > +oneOf:
> >
Hi Rob,
Thanks for reviewing this.
On Thu, Dec 06, 2018 at 08:47:04AM -0600, Rob Herring wrote:
> On Wed, Nov 14, 2018 at 11:52 PM AKASHI Takahiro
> wrote:
> >
> > Added function, fdt_setprop_reg(), will be used later to handle
> > kexec-specific property in arm64's kexec_file implementation.
>
On Thu, Dec 06, 2018 at 08:23:20PM +0100, Ard Biesheuvel wrote:
> On Thu, 6 Dec 2018 at 20:21, Andy Lutomirski wrote:
> >
> > On Thu, Dec 6, 2018 at 11:04 AM Ard Biesheuvel
> > wrote:
> > >
> > > On Thu, 6 Dec 2018 at 19:54, Andy Lutomirski wrote:
> > > >
> >
> > > > That’s not totally nuts. Do
this is consistent
>with the majority and results in userspace perf retrying without
>exclusion.
>
> All drivers touched by this patchset have been compile tested.
For the bits under arch/arm/ and drivers/perf:
Acked-by: Will Deacon
Note that I've queued the TX2 uncore
On Fri, Nov 30, 2018 at 04:08:52PM +, Al Viro wrote:
> On Fri, Nov 30, 2018 at 09:16:49AM -0600, Eric W. Biederman wrote:
> > >> > + inode_lock(parent->d_inode);
> > >> > dentry->d_fsdata = NULL;
> > >> > drop_nlink(dentry->d_inode);
> > >> > d_delete(dentry);
> >
resolves the issue spotted by Peter, where an IRQ coming in during the
decrement can cause a reschedule to be missed.
Feedback welcome.
Will
--->8
Will Deacon (2):
preempt: Move PREEMPT_NEED_RESCHED definition into arch code
arm64: preempt: Provide our own implementation of asm/preempt.h
a
: Will Deacon
---
arch/s390/include/asm/preempt.h | 2 ++
arch/x86/include/asm/preempt.h | 3 +++
include/linux/preempt.h | 3 ---
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/s390/include/asm/preempt.h b/arch/s390/include/asm/preempt.h
index 23a14d187fb1
t count is
only 32 bits wide, we can simply pack it next to the resched flag and
load the whole thing in one go, so that a dec-and-test operation doesn't
need to load twice.
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/Kbuild| 1 -
arch/arm64/include/asm/pre
On Thu, Nov 29, 2018 at 03:28:19PM -0800, Atish Patra wrote:
> Both RISC-V & ARM64 are using cpu-map device tree to describe
> their cpu topology. It's better to move the relevant code to
> a common place instead of duplicate code.
>
> Signed-off-by: Atish Patra
> ---
> arch/arm64/include/asm/to
Hi Anders,
On Fri, Nov 30, 2018 at 04:09:56PM +0100, Anders Roxell wrote:
> Both of those functions end up calling ftrace_modify_code(), which is
> expensive because it changes the page tables and flush caches.
> Microseconds add up because this is called in a loop for each dyn_ftrace
> record, an
Hi Steve, Arnd,
On Tue, Dec 04, 2018 at 12:50:12AM -0500, Steven Rostedt wrote:
> On Mon, 3 Dec 2018 22:51:52 +0100
> Arnd Bergmann wrote:
> > On Mon, Dec 3, 2018 at 8:22 PM Will Deacon wrote:
> > > On Fri, Nov 30, 2018 at 04:09:56PM +0100, Anders Roxell wrote:
> >
Hi Naresh,
On Tue, Dec 04, 2018 at 05:56:09PM +0530, Naresh Kamboju wrote:
> FYI,
>
> The Linux -next build failed due to below warnings/errors.
>
> include/asm-generic/bitops/atomic.h: In function 'set_bit':
> include/asm-generic/bitops/atomic.h:17:2: error: implicit declaration
> of function '
> ARM 32-bit platforms and update the comment above to explain these
> limitations.
>
> Signed-off-by: Florian Fainelli
> ---
> Changes in v3:
>
> - directly incorporate Will's comment, Will can you add your
> Signed-off-by?
Of course:
Co-developed-by: Will Deacon
Signed-off-by: Will Deacon
Will
On Fri, Nov 09, 2018 at 02:37:51PM +, Jan Glauber wrote:
> I'm seeing the following oops reproducible with upstream kernel on arm64
> (ThunderX2):
[...]
> It happens after 1-3 hours of running 'stress-ng --dev 128'. This testcase
> does a scandir of /dev and then calls random stuff like ioctl
Hi Toshi, Thomas,
On Wed, Jun 27, 2018 at 04:13:22PM +, Kani, Toshi wrote:
> On Wed, 2018-06-27 at 16:56 +0100, Will Deacon wrote:
> > On Wed, Jun 27, 2018 at 08:13:47AM -0600, Toshi Kani wrote:
> > > From: Chintan Pandya
> > >
> > > The following kernel
Hi Kees,
On Fri, Jun 29, 2018 at 01:25:20PM -0700, Kees Cook wrote:
> On Fri, Jun 29, 2018 at 1:22 PM, Laura Abbott wrote:
> > On 06/29/2018 01:19 PM, Kees Cook wrote:
> >>
> >> On Fri, Jun 29, 2018 at 12:05 PM, Laura Abbott wrote:
> >>>
> >>> Implementation of stackleak based heavily on the x86
KBUILD_CPPFLAGS += -mlittle-endian
> CHECKFLAGS += -D__AARCH64EL__
> AS += -EL
> LD += -EL
> -LDFLAGS += -maarch64linux
> +LDFLAGS += -maarch64elf
> UTS_MACHINE := aarch64
> endif
Acked-by: Will Deacon
Will
On Thu, Jun 28, 2018 at 04:50:40PM -0400, Mathieu Desnoyers wrote:
> - On Jun 28, 2018, at 12:47 PM, Will Deacon will.dea...@arm.com wrote:
> > On Tue, Jun 26, 2018 at 12:11:52PM -0400, Mathieu Desnoyers wrote:
> >> - On Jun 26, 2018, at 11:14 AM, Will Deacon will.de
On Fri, Jun 29, 2018 at 11:45:36AM -0700, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> removes the VLA in favor of a maximum size and adds a sanity check
> at registration time. The sizes are all explicitly enumerated already,
> so this just collects them
Hi Andrew,
On Fri, Jul 06, 2018 at 05:30:49PM -0700, Andrew Morton wrote:
> On Tue, 19 Jun 2018 13:53:08 +0100 Will Deacon wrote:
>
> > In preparation for implementing the asm-generic atomic bitops in terms
> > of atomic_long_*, we need to prevent asm/atomic.h implementation
Implement calls to rseq_signal_deliver, rseq_handle_notify_resume
and rseq_syscall so that we can select HAVE_RSEQ on arm64.
Acked-by: Mark Rutland
Signed-off-by: Will Deacon
---
arch/arm64/Kconfig| 1 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32
27;ve tested both native and compat (little-endian only) with the selftests
and they pass successfully on my Seattle box.
Thanks,
Will
--->8
Will Deacon (3):
arm64: rseq: Implement backend rseq calls and select HAVE_RSEQ
asm-generic: unistd.h: Wire up sys_rseq
rseq/selftests: Add sup
The new rseq call arrived in 4.18-rc1, so provide it in the asm-generic
unistd.h for architectures such as arm64.
Cc: Arnd Bergmann
Signed-off-by: Will Deacon
---
include/uapi/asm-generic/unistd.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/uapi/asm-generic
Hook up arm64 support to the rseq selftests.
Signed-off-by: Will Deacon
---
tools/testing/selftests/rseq/param_test.c | 20 +
tools/testing/selftests/rseq/rseq-arm64.h | 594 ++
tools/testing/selftests/rseq/rseq.h | 2 +
3 files changed, 616 insertions
On Fri, Jul 06, 2018 at 02:10:55PM -0700, Paul E. McKenney wrote:
> On Fri, Jul 06, 2018 at 04:37:21PM -0400, Alan Stern wrote:
> > On Thu, 5 Jul 2018, Andrea Parri wrote:
> >
> > > > At any rate, it looks like instead of strengthening the relation, I
> > > > should write a patch that removes it e
On Mon, Jul 09, 2018 at 12:06:22PM -0400, Mathieu Desnoyers wrote:
> - On Jul 9, 2018, at 10:19 AM, Will Deacon will.dea...@arm.com wrote:
>
> > Hello,
> >
> > This is version two of the patches previously posted here:
> >
> > http://lkml.kernel.org
Thanks, Laura.
I'll take this as a fix, and add a comment to the Makefile to justify
why we need the linux target.
Will
On Mon, Jul 09, 2018 at 01:09:56PM -0700, Laura Abbott wrote:
> This reverts commit 38fc4248677552ce35efc09902fdcb06b61d7ef9.
>
> This breaks compilation with Fedora gcc-8 too
On Tue, Jul 10, 2018 at 03:10:51PM +0900, Tetsuo Handa wrote:
> From 2642b4a1904259384f2018ea8df03ac49509c57a Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Tue, 10 Jul 2018 15:01:20 +0900
> Subject: [PATCH] locking/rwsem: Convert the other sem->count to
> 'atomic_long_t'
>
> Since "locki
On Tue, Jul 10, 2018 at 11:30:39AM +0200, Paul Kocialkowski wrote:
> On Tue, 2018-07-10 at 10:01 +0100, Will Deacon wrote:
> > Thanks, Laura.
> >
> > I'll take this as a fix, and add a comment to the Makefile to justify
> > why we need the linux target.
>
>
On Mon, Jul 02, 2018 at 12:03:56PM +0100, Mark Rutland wrote:
> This series reworks arm64's syscall handling to minimize the propagation
> of user-controlled register values into speculated code paths. As with
> x86 [1], a wrapper is generated for each syscall, which extracts the
> argument from a
Hi Arnd,
On Tue, Jul 10, 2018 at 02:55:41PM +0200, Arnd Bergmann wrote:
> On Fri, Jul 6, 2018 at 7:47 PM, Nikunj Kela wrote:
> > Flatmem is useful in reducing kernel memory usage.
> > One usecase is in kdump kernel. We are able to save
> > ~14M by moving to flatmem scheme.
> >
> > Cc: xe-ker...@e
On Tue, Jul 10, 2018 at 03:25:14PM +0200, Arnd Bergmann wrote:
> On Tue, Jul 10, 2018 at 3:06 PM, Will Deacon wrote:
> > On Tue, Jul 10, 2018 at 02:55:41PM +0200, Arnd Bergmann wrote:
> >> On Fri, Jul 6, 2018 at 7:47 PM, Nikunj Kela wrote:
> >> > Flatmem is useful i
Hi Suzuki,
On Tue, Jul 10, 2018 at 09:57:57AM +0100, Suzuki K Poulose wrote:
> This series adds support for counting PMU events using 64bit counters
> for arm64 PMU.
>
> The Arm v8 PMUv3 supports combining two adjacent 32bit counters
> (low even and hig odd counters) to count a given "event" in 6
On Mon, Jul 09, 2018 at 01:17:54PM -0400, Mathieu Desnoyers wrote:
> - On Jul 9, 2018, at 12:53 PM, Will Deacon will.dea...@arm.com wrote:
>
> > On Mon, Jul 09, 2018 at 12:06:22PM -0400, Mathieu Desnoyers wrote:
> >> - On Jul 9, 2018, at 10:19 AM, Will Deacon will
Hi Arnd,
On Mon, Jul 09, 2018 at 03:19:44PM +0100, Will Deacon wrote:
> The new rseq call arrived in 4.18-rc1, so provide it in the asm-generic
> unistd.h for architectures such as arm64.
>
> Cc: Arnd Bergmann
> Signed-off-by: Will Deacon
> ---
> include/uapi/asm
On Tue, Jul 10, 2018 at 05:16:27PM +0200, Arnd Bergmann wrote:
> Building without NUMA but with FLATMEM results in a link error
> because mem_map[] is not available:
>
> aarch64-linux-ld -EB -maarch64elfb --no-undefined -X -pie -shared -Bsymbolic
> --no-apply-dynamic-relocs --build-id -o .tmp_vml
On Tue, Jul 10, 2018 at 11:37:24AM +0100, Dave Martin wrote:
> On Mon, Jul 09, 2018 at 03:21:59PM +0100, Mark Rutland wrote:
> > On Fri, Jul 06, 2018 at 05:38:45PM +0100, Will Deacon wrote:
> > > On Mon, Jul 02, 2018 at 12:04:07PM +0100, Mark Rutland wrote:
> > > >
On Tue, Jul 10, 2018 at 11:38:21AM +0200, Andrea Parri wrote:
> On Mon, Jul 09, 2018 at 04:01:57PM -0400, Alan Stern wrote:
> > More than one kernel developer has expressed the opinion that the LKMM
> > should enforce ordering of writes by locking. In other words, given
>
> I'd like to step back
Hi Huacai,
On Tue, Jul 10, 2018 at 07:45:22PM +0800, 陈华才 wrote:
> I don't think this is a hardware bug, in design, SFB will flushed to L1
> cache in three cases:
> 1, data in SFB is full (be a complete cache line);
> 2, there is a subsequent read access in the same cache line;
> 3, a 'sync' instru
Hi again, Andrew,
On Mon, Jul 09, 2018 at 03:10:06PM -0700, Andrew Morton wrote:
> On Mon, 9 Jul 2018 12:32:51 +0100 Will Deacon wrote:
> > On Fri, Jul 06, 2018 at 05:30:49PM -0700, Andrew Morton wrote:
> > > On Tue, 19 Jun 2018 13:53:08 +0100 Will Deacon
> > &g
albeit for varying reasons.
> Therefore this patch changes the model in accordance with the
> developers' wishes.
>
> Signed-off-by: Alan Stern
Thanks, I'm happy with this version of the patch:
Reviewed-by: Will Deacon
Will
On Wed, Jul 11, 2018 at 06:05:51PM +0800, Jiaxun Yang wrote:
> On 2018-7-10 Tue at 20:17:27，Peter Zijlstra Wrote：
>
> Hi Peter
> Since Huacai unable to send email via client, I'm going to reply for him
>
> > Sure.. we all got that far. And no, this isn't the _real_ problem. This
> > is a manife
On Wed, Jul 11, 2018 at 07:06:28PM +0800, Yandong.Zhao wrote:
> From: Yandong Zhao
>
> It does not matter if the caller of may_use_simd() migrates to
> another cpu after the call, but it is still important that the
> kernel_neon_busy percpu instance that is read matches the cpu the
> task is runn
On Wed, Jul 11, 2018 at 11:47:20AM +0100, Mark Rutland wrote:
> On Tue, Jul 10, 2018 at 11:39:02AM +0100, Will Deacon wrote:
> > On Mon, Jul 02, 2018 at 12:03:56PM +0100, Mark Rutland wrote:
> > > This series reworks arm64's syscall handling to minimize the propagation
&
Implement calls to rseq_signal_deliver, rseq_handle_notify_resume
and rseq_syscall so that we can select HAVE_RSEQ on arm64.
Signed-off-by: Will Deacon
---
arch/arm64/Kconfig| 1 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 2 ++
arch/arm64
Hi all,
This patch wires up rseq for native and compat tasks under arm64. Both
have been tested with the selftests and they pass successfully on my Seattle
box.
Cheers,
Will
--->8
Will Deacon (3):
arm64: rseq: Implement backend rseq calls and select HAVE_RSEQ
asm-generic: unistd.h: W
The new rseq call arrived in 4.18-rc1, so provide it in the asm-generic
unistd.h for architectures such as arm64.
Signed-off-by: Will Deacon
---
include/uapi/asm-generic/unistd.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/uapi/asm-generic/unistd.h
b/include
Hook up arm64 support to the rseq selftests.
Signed-off-by: Will Deacon
---
tools/testing/selftests/rseq/param_test.c | 20 +
tools/testing/selftests/rseq/rseq-arm64.h | 594 ++
tools/testing/selftests/rseq/rseq.h | 2 +
3 files changed, 616 insertions
Hi Mathieu,
On Mon, Jun 25, 2018 at 02:10:10PM -0400, Mathieu Desnoyers wrote:
> - On Jun 25, 2018, at 1:54 PM, Will Deacon will.dea...@arm.com wrote:
> > +#define __RSEQ_ASM_DEFINE_TABLE(label, version, flags, start_ip,
> > \
> > +
Hi Wei,
On Wed, Jun 27, 2018 at 01:16:44AM +0800, Wei Xu wrote:
> Today I tried the kernel 4.18-rc2(defconfig, no change on top) with qemu
> 2.12.0.
> The guest sometimes still failed to boot. But the crash reason is different.
> Could you please share any hint?
> Thanks!
>
> The guest boot log i
On Wed, Jun 27, 2018 at 02:22:03PM +0100, Wei Xu wrote:
> On 2018/6/26 18:47, Will Deacon wrote:
> > If you look at the __idmap_kpti_put_pgtable_ent_ng asm macro, can you try
> > replacing:
> >
> > dc civac, cur_\()\type\()p
> >
> > with:
>
Hi Toshi,
On Wed, Jun 27, 2018 at 08:13:47AM -0600, Toshi Kani wrote:
> From: Chintan Pandya
>
> The following kernel panic was observed on ARM64 platform due to a stale
> TLB entry.
>
> 1. ioremap with 4K size, a valid pte page table is set.
> 2. iounmap it, its pte entry is set to 0.
> 3.
---
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/jump_label.h | 16
> arch/arm64/kernel/jump_label.c | 6 +++---
> 3 files changed, 8 insertions(+), 15 deletions(-)
Looks good, cheers:
Acked-by: Will Deacon
Will
always been
> undocumented and silently ignored. A comment in
> ld/emultempl/aarch64elf.em explains that it's "Only here for backwards
> compatibility".
>
> Since this flag is a no-op on ARM64, we can safely drop it.
Makes sense:
Acked-by: Will Deacon
Will
Hi Mathieu,
On Tue, Jun 26, 2018 at 12:11:52PM -0400, Mathieu Desnoyers wrote:
> - On Jun 26, 2018, at 11:14 AM, Will Deacon will.dea...@arm.com wrote:
> > On Mon, Jun 25, 2018 at 02:10:10PM -0400, Mathieu Desnoyers wrote:
> >> I notice you are using the instructions
Andi Kleen
> CC: Dave Watson
> CC: Chris Lameter
> CC: Ingo Molnar
> CC: "H. Peter Anvin"
> CC: Ben Maurer
> CC: Steven Rostedt
> CC: Josh Triplett
> CC: Linus Torvalds
> CC: Andrew Morton
> CC: Russell King
> CC: Catalin Marinas
> C
.
Cc: Yoshinori Sato
Signed-off-by: Will Deacon
---
arch/h8300/include/asm/atomic.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/h8300/include/asm/atomic.h b/arch/h8300/include/asm/atomic.h
index 941e7554e886..b174dec099bf 100644
--- a/arch/h8300/include/asm/ato
patches from
the series which were merged in 4.16.
* Moved bit.h to be linux/bit.h instead of asm-generic/bit.h
Thanks,
Will
--->8
Will Deacon (9):
h8300: Don't include linux/kernel.h in asm/atomic.h
m68k: Don't use asm-generic/bitops/lock.h
asm-generic: Move some macr
ust define the lock bitops in terms of the atomic bitops in the
asm/bitops.h header.
Acked-by: Geert Uytterhoeven
Signed-off-by: Will Deacon
---
arch/m68k/include/asm/bitops.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/m68k/include/asm/bitops.h b/arch/m68k/i
The openrisc implementation of asm/cmpxchg.h pulls in linux/bitops.h
so that it can refer to BITS_PER_BYTE. It also transitively relies on
this pulling in linux/compiler.h for READ_ONCE.
Replace the #include with linux/bits.h and linux/compiler.h
Signed-off-by: Will Deacon
---
arch/openrisc
new header file, linux/bits.h
Signed-off-by: Will Deacon
---
include/linux/bitops.h | 22 +-
include/linux/bits.h | 26 ++
2 files changed, 27 insertions(+), 21 deletions(-)
create mode 100644 include/linux/bits.h
diff --git a/include/linux/bitops.h
asm-generic/bitops/ext2-atomic-setbit.h provides the ext2 atomic bitop
definitions, so we don't need to define our own.
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/bitops.h | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/arm64/include/asm/bitops.h b
The atomic bitops can actually be implemented pretty efficiently using
the atomic_fetch_* ops, rather than explicit use of spinlocks.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Signed-off-by: Will Deacon
---
include/asm-generic/bitops/atomic.h | 188 +++-
1 file
The sh implementation of asm/cmpxchg-xchg.h pulls in linux/bitops.h
so that it can refer to BITS_PER_BYTE. It also transitively relies on
this pulling in linux/compiler.h for READ_ONCE.
Replace the #include with linux/bits.h and linux/compiler.h
Signed-off-by: Will Deacon
---
arch/sh/include
The lock bitops can be implemented more efficiently using the atomic_fetch_*
ops, which provide finer-grained control over the memory ordering semantics
than the bitops.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Signed-off-by: Will Deacon
---
include/asm-generic/bitops/lock.h | 68
The asm-generic/bitops/{atomic,lock}.h implementations are built around
the atomic-fetch ops, which we implement efficiently for both LSE and
LL/SC systems. Use that instead of our hand-rolled, out-of-line bitops.S.
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/bitops.h | 14
On Thu, May 24, 2018 at 10:58:43AM +0100, Suzuki K Poulose wrote:
> On 22/05/18 16:06, Marc Zyngier wrote:
> >As for Spectre variant-2, we rely on SMCCC 1.1 to provide the
> >discovery mechanism for detecting the SSBD mitigation.
> >
> >A new capability is also allocated for that purpose, and a
> >
On Thu, May 24, 2018 at 01:16:38PM +0100, Marc Zyngier wrote:
> On 24/05/18 13:01, Mark Rutland wrote:
> > On Tue, May 22, 2018 at 04:06:43PM +0100, Marc Zyngier wrote:
> >> In order to allow userspace to be mitigated on demand, let's
> >> introduce a new thread flag that prevents the mitigation fr
On Tue, May 22, 2018 at 04:06:44PM +0100, Marc Zyngier wrote:
> If running on a system that performs dynamic SSBD mitigation, allow
> userspace to request the mitigation for itself. This is implemented
> as a prctl call, allowing the mitigation to be enabled or disabled at
> will for this particula
On Thu, May 24, 2018 at 02:44:10PM +0200, Peter Zijlstra wrote:
> On Thu, May 24, 2018 at 11:59:43AM +0100, Will Deacon wrote:
> > +static inline void set_bit(unsigned int nr, volatile unsigned long *p)
> > {
> > + p += BIT_WORD(nr);
> > + atomic_long_f
On Wed, May 23, 2018 at 09:26:35AM -0700, Linus Torvalds wrote:
> On Wed, May 23, 2018 at 8:35 AM Will Deacon wrote:
>
> > In other words, qrwlock requires consistent locking order wrt spinlocks.
>
> I *thought* lockdep already tracked and detected this. Or is that only with
&
r probe twice before giving up. This shouldn't have a
> significant impact on boot times as past discussions about deferred
> probe have given no evidence of deferred probe having a substantial
> impact.
>
> Cc: Will Deacon
> Cc: Robin Murphy
> Cc: Joerg Roedel
> Cc: Ma
pud
Peter Maydell (1):
arm64: fault: Don't leak data in ESR context for user fault on kernel VA
Will Deacon (1):
arm64: lse: Add early clobbers to some input/output asm operands
arch/arm64/include/asm/atomic_lse.h | 24 -
arch/arm64/kernel/arm64ksyms.c
Hi Linus,
Please pull these arm64 fixes for -rc5. There's a small memblock accounting
problem when freeing the initrd and a Spectre-v2 mitigation for NVIDIA Denver
CPUs which just requires a match on the CPU ID register.
Thanks,
Will
--->8
The following changes since commit 6da6c0db5316275015e
in will build atomic_add_unless() atop of
> this, provided it is given a preprocessor definition.
>
> No functional change is intended as a result of this patch.
>
> Signed-off-by: Mark Rutland
> Acked-by: Peter Zijlstra (Intel)
> Cc: Boqun Feng
> Cc: Will Deacon
> Cc
ll help when generating the atomic headers in future.
Apart from the Alpha patch:
Reviewed-by: Will Deacon
I also tried to compare disassembly before/after, but the changes to
add_unless made that quite fiddly for anything using it as a backend.
Do you plan to move arm64 over to atomic-instrument
Hi all,
On Tue, Jun 19, 2018 at 09:17:10AM +0200, Peter Zijlstra wrote:
> On Mon, Jun 18, 2018 at 11:51:41AM -0700, Paul Burton wrote:
> > On Fri, Jun 15, 2018 at 02:07:38PM +0800, Huacai Chen wrote:
> > > After commit 7f56b58a92aaf2c ("locking/mcs: Use smp_cond_load_acquire()
> > > in MCS spin lo
On Tue, Jun 19, 2018 at 11:18:01AM +0100, Mark Rutland wrote:
> On Mon, Jun 18, 2018 at 08:21:27PM +0100, Mark Rutland wrote:
> > On Mon, Jun 18, 2018 at 05:38:06PM +0100, Will Deacon wrote:
> > > On Mon, Jun 18, 2018 at 11:19:01AM +0100, Mark Rutland wrote:
> > > &
new header file, linux/bits.h
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Will Deacon
---
include/linux/bitops.h | 22 +-
include/linux/bits.h | 26 ++
2 files changed, 27 insertions(+), 21 deletions(-)
create mode 100644 include/linux/bits.h
/1/619
The only change is that I have rebased onto v4.18-rc1.
Ingo -- please can you queue this via -tip when you start picking up
patches for 4.19? It doesn't conflict with Mark's atomic API rework.
Thanks,
Will
--->8
Will Deacon (9):
h8300: Don't include linux/kernel
ust define the lock bitops in terms of the atomic bitops in the
asm/bitops.h header.
Acked-by: Geert Uytterhoeven
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Will Deacon
---
arch/m68k/include/asm/bitops.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/m68k/i
) etc.
Cc: Yoshinori Sato
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Will Deacon
---
arch/h8300/include/asm/atomic.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/h8300/include/asm/atomic.h b/arch/h8300/include/asm/atomic.h
index 941e7554e886..b174dec099bf 1
The lock bitops can be implemented more efficiently using the atomic_fetch_*
ops, which provide finer-grained control over the memory ordering semantics
than the bitops.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Will Deacon
---
include/asm-generic
The asm-generic/bitops/{atomic,lock}.h implementations are built around
the atomic-fetch ops, which we implement efficiently for both LSE and
LL/SC systems. Use that instead of our hand-rolled, out-of-line bitops.S.
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Will Deacon
---
arch/arm64
asm-generic/bitops/ext2-atomic-setbit.h provides the ext2 atomic bitop
definitions, so we don't need to define our own.
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/bitops.h | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a
: Will Deacon
---
arch/openrisc/include/asm/cmpxchg.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/openrisc/include/asm/cmpxchg.h
b/arch/openrisc/include/asm/cmpxchg.h
index d29f7db53906..f9cd43a39d72 100644
--- a/arch/openrisc/include/asm/cmpxchg.h
+++ b/arch
The atomic bitops can actually be implemented pretty efficiently using
the atomic_* ops, rather than explicit use of spinlocks.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Will Deacon
---
include/asm-generic/bitops/atomic.h | 188
: Will Deacon
---
arch/sh/include/asm/cmpxchg-xchg.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/sh/include/asm/cmpxchg-xchg.h
b/arch/sh/include/asm/cmpxchg-xchg.h
index 1e881f5db659..593a9704782b 100644
--- a/arch/sh/include/asm/cmpxchg-xchg.h
+++ b/arch/sh/include
Hi Ard,
Sorry, I forgot to reply to this.
On Wed, May 30, 2018 at 11:53:20AM +0200, Ard Biesheuvel wrote:
> On 30 May 2018 at 11:14, Will Deacon wrote:
> > On Wed, May 30, 2018 at 12:48:06PM +0800, YaoJun wrote:
> >> To protect against KSMA(Kernel Space Mirroring Attack), make
On Tue, Jun 19, 2018 at 05:23:41PM +0200, Ard Biesheuvel wrote:
> On 19 June 2018 at 17:20, Will Deacon wrote:
> > Hi Ard,
> >
> > Sorry, I forgot to reply to this.
> >
> > On Wed, May 30, 2018 at 11:53:20AM +0200, Ard Biesheuvel wrote:
> >> On 30 May 20
901 - 1000 of 6287 matches
Mail list logo
