On Mon, Aug 31, 2015 at 09:16:28PM +0100, Arnaldo Carvalho de Melo wrote:
> Em Sat, Aug 29, 2015 at 03:16:52AM +, He Kuang escreveu:
> > This patch implements arch_get_reg_info() for arm64 to enable
> > HAVE_BPF_PROLOGUE feature. For arm64, structure pt_regs is not composed
> > by fields of reg
On Fri, Aug 28, 2015 at 12:49:47PM +0100, Horia Geantă wrote:
> This will allow device drivers to consistently use io{read,write}XXbe
> macros also for 64-bit accesses.
>
> Signed-off-by: Alex Porosanu
> Signed-off-by: Horia Geantă
> ---
> arch/arm64/include/asm/io.h | 4 +++-
> 1 file changed,
On Wed, Sep 02, 2015 at 04:36:09PM +0100, Pranith Kumar wrote:
> On Wed, Sep 2, 2015 at 11:23 AM, Pranith Kumar wrote:
> > On 09/02/2015 05:59 AM, Will Deacon wrote:
> >> I just thought it was worth making this point, because it is prohibited
> >> in SC and I don'
perations
Wang Long (1):
arm64: mm: add __init section marker to free_initrd_mem
Will Deacon (41):
arm64: move update_mmu_cache() into asm/pgtable.h
arm64: lib: use pair accessors for copy_*_user routines
arm64: force CONFIG_SMP=y and remove redundant #ifdefs
arm64:
On Fri, Aug 03, 2018 at 09:16:39AM +0200, Ard Biesheuvel wrote:
> On 3 August 2018 at 08:35, Mikulas Patocka wrote:
> >
> >
> > On Thu, 2 Aug 2018, Matt Sealey wrote:
> >
> >> The easiest explanation for this would be that the memory isn?t mapped
> >> correctly. You can?t use PCIe memory spaces wi
On Sun, Aug 05, 2018 at 10:35:03AM +0800, gengdongjiu wrote:
> 2018-07-27 18:06 GMT+08:00 Will Deacon :
> > On Thu, Jul 26, 2018 at 05:01:47PM -0400, Dongjiu Geng wrote:
> >> In order to remove the additional check before calling the
> >> ghes_notify_sea()
On Fri, Aug 03, 2018 at 07:58:44PM +0530, Sai Prakash Ranjan wrote:
> Introduce dynamic debug filtering mechanism to register
> tracing as dynamic_rtb() which will reduce a lot of
> overhead otherwise of tracing all the register reads/writes
> in all files.
>
> Now we can just specify the file nam
Hi Wei,
On Wed, Jun 20, 2018 at 10:18:00PM +0800, Wei Xu wrote:
> We have observed KVM guest sometimes failed to boot because of kernel stack
> overflow if KPTI is enabled on a hisilicon arm64 platform.
>
> We also tested with different kernel version and found it is only
> happened if the KPTI a
On Thu, Jun 21, 2018 at 12:25:05AM +0800, Wei Xu wrote:
> Hi James,
>
> On 2018/6/20 23:54, James Morse wrote:
> >Hi Wei,
> >
> >On 20/06/18 16:52, Wei Xu wrote:
> >>On 2018/6/20 22:42, Will Deacon wrote:
> >>>Hmm, I wonder if this is at all relate
force_sigsegv() instead of force_sig(), which
is explicitly designed to reset the SEGV handler to SIG_DFL in the case
of a recursive fault.
Signed-off-by: Will Deacon
---
Sending as an RFC since I only spotted this via code inspection and haven't
tried to trigger it yet.
arch/arm/k
On Thu, Jun 21, 2018 at 09:38:53AM +0100, James Morse wrote:
> On 20/06/18 17:25, Wei Xu wrote:
> > [ 0.042421] Insufficient stack space to handle exception!
> > [ 0.042423] ESR: 0x9646 -- DABT (current EL)
> > [ 0.043730] FAR: 0x093a80e0
> > [ 0.044714] Task
Hi Wei,
On Thu, Jun 21, 2018 at 11:14:28AM +0100, Wei Xu wrote:
> On 2018/6/21 10:18, Will Deacon wrote:
> > On Thu, Jun 21, 2018 at 09:38:53AM +0100, James Morse wrote:
> >> On 20/06/18 17:25, Wei Xu wrote:
> >>> [0.042421] Insufficient s
On Wed, Jun 20, 2018 at 12:55:35PM -0400, Mathieu Desnoyers wrote:
> - On Jun 20, 2018, at 12:36 PM, Will Deacon will.dea...@arm.com wrote:
>
> > When delivering a signal to a task that is using rseq, we call into
> > __rseq_handle_notify_resume() so that the regis
.
Signed-off-by: Will Deacon
---
RFC v1 -> v2: Kill rseq_signal_deliver()
arch/arm/kernel/signal.c | 4 ++--
arch/powerpc/kernel/signal.c | 4 ++--
arch/x86/entry/common.c | 2 +-
arch/x86/kernel/signal.c | 2 +-
include/linux/sched.h| 27 ---
ker
On Thu, Jun 21, 2018 at 10:44:37AM -0400, Mathieu Desnoyers wrote:
> - On Jun 21, 2018, at 7:54 AM, Will Deacon will.dea...@arm.com wrote:
>
> > When delivering a signal to a task that is using rseq, we call into
> > __rseq_handle_notify_resume() so that the regis
akes initializing it special
> for older compilers. By adding strategic brackets, it makes the build
> happy again.
>
> Fixes: 625e88be1f41 ("locking/qspinlock: Merge 'struct __qspinlock' into
> 'struct qspinlock'")
> Signed-off-by: Steven Rostedt (VMware)
> ---
Cheers for spotting this and fixing it up! I know it's already in -tip, but
anyway:
Acked-by: Will Deacon
Will
Hi Alan,
On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> More than one kernel developer has expressed the opinion that the LKMM
> should enforce ordering of writes by release-acquire chains and by
> locking. In other words, given the following code:
>
> WRITE_ONCE(x, 1);
>
Hi Wei,
On Fri, Jun 22, 2018 at 09:33:04AM +0100, Wei Xu wrote:
> On 2018/6/21 11:54, Will Deacon wrote:
> > On Thu, Jun 21, 2018 at 11:14:28AM +0100, Wei Xu wrote:
> >> On 2018/6/21 10:18, Will Deacon wrote:
> >>> Wei -- does the diff below help at all? Make sure y
On Fri, Jun 22, 2018 at 09:09:28AM +0100, Will Deacon wrote:
> On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> > More than one kernel developer has expressed the opinion that the LKMM
> > should enforce ordering of writes by release-acquire chains and by
> > loc
Hi Peter,
On Fri, Jun 22, 2018 at 12:31:29PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 22, 2018 at 10:55:47AM +0100, Will Deacon wrote:
> > On Fri, Jun 22, 2018 at 09:09:28AM +0100, Will Deacon wrote:
> > > On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> >
.
Signed-off-by: Will Deacon
---
v2 -> v3: Reintroduce rseq_signal_deliver()
arch/arm/kernel/signal.c | 4 ++--
arch/powerpc/kernel/signal.c | 4 ++--
arch/x86/entry/common.c | 2 +-
arch/x86/kernel/signal.c | 2 +-
include/linux/sched.h| 18 +++---
ker
Hi Wei,
Thanks for giving that a spin.
On Fri, Jun 22, 2018 at 06:45:15PM +0800, Wei Xu wrote:
> On 2018/6/22 17:23, Will Deacon wrote:
> >On Fri, Jun 22, 2018 at 09:33:04AM +0100, Wei Xu wrote:
> >>On 2018/6/21 11:54, Will Deacon wrote:
> >>>On Thu, Jun 21, 20
Hi again, Wei,
On Fri, Jun 22, 2018 at 09:18:27PM +0800, Wei Xu wrote:
> On 2018/6/22 19:16, Will Deacon wrote:
> >On Fri, Jun 22, 2018 at 06:45:15PM +0800, Wei Xu wrote:
> >>On 2018/6/22 17:23, Will Deacon wrote:
> >>>Perhaps just writing back the table entrie
On Fri, Jun 22, 2018 at 09:46:53PM +0800, Wei Xu wrote:
> On 2018/6/22 21:31, Will Deacon wrote:
> >On Fri, Jun 22, 2018 at 09:18:27PM +0800, Wei Xu wrote:
> >>On 2018/6/22 19:16, Will Deacon wrote:
> >>>On Fri, Jun 22, 2018 at 06:45:15PM +0800, Wei Xu wrote:
> &g
On Fri, Jun 22, 2018 at 11:28:21PM +0800, Wei Xu wrote:
> On 2018/6/22 22:28, Mark Rutland wrote:
> >On Fri, Jun 22, 2018 at 09:18:27PM +0800, Wei Xu wrote:
> >> [0.227507] Mem abort info:
> >> [0.230390] ESR = 0x9606
> >> [0.233517] Exception class = DABT (current E
Hi Alan,
On Fri, Jun 22, 2018 at 02:09:04PM -0400, Alan Stern wrote:
> On Fri, 22 Jun 2018, Will Deacon wrote:
> > On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> > > More than one kernel developer has expressed the opinion that the LKMM
> > > should en
Hi Linus,
On Fri, Aug 24, 2018 at 09:15:17AM -0700, Linus Torvalds wrote:
> On Fri, Aug 24, 2018 at 8:52 AM Will Deacon wrote:
> >
> > Now that our walk-cache invalidation routines imply a DSB before the
> > invalidation, we no longer need one when we are clearing an e
On Fri, Aug 24, 2018 at 07:56:09PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 24, 2018 at 04:52:37PM +0100, Will Deacon wrote:
> > __flush_tlb_[kernel_]pgtable() rely on set_pXd() having a DSB after
> > writing the new table entry and therefore avoid the barrier prior to the
>
On Mon, Aug 27, 2018 at 09:53:41AM +0200, Peter Zijlstra wrote:
> On Fri, Aug 24, 2018 at 04:52:44PM +0100, Will Deacon wrote:
> > +static inline unsigned long tlb_get_unmap_granule(struct mmu_gather *tlb)
> > +{
> > + if (tlb->cleared_ptes)
> > + ret
M64: PCI: Support ACPI-based PCI host controller").
>
> Drop the node local allocation as there is no benefit from doing so -
> the usage of these structures is independent from where the controller
> is located.
>
> Signed-off-by: Punit Agrawal
> Cc: Catalin Marinas
>
On Mon, Aug 27, 2018 at 08:52:39PM -0500, Rob Herring wrote:
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
>
> Cc: Will Deacon
> Cc: Mark Rutland
> Cc: linux-arm-ker...@lists.infradead.org
&g
On Fri, Aug 24, 2018 at 12:22:35PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in pr_err error message
>
> Signed-off-by: Colin Ian King
> ---
> kernel/locking/test-ww_mutex.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Given that this is pa
On Fri, Aug 24, 2018 at 05:05:59PM -0600, Shuah Khan (Samsung OSG) wrote:
> Add NUMA emulation support to emulate NUMA on non-NUMA platforms. A new
> CONFIG_NUMA_EMU option enables NUMA emulation and a new kernel command
> line option "numa=fake=N" allows users to specify the configuration for
> em
On Thu, Aug 30, 2018 at 02:26:51PM +0800, Jia He wrote:
> On 8/30/2018 9:00 AM, Jia He Wrote:
> > On 8/30/2018 7:22 AM, Andrew Morton Wrote:
> >> On Tue, 28 Aug 2018 12:20:46 +0800 Jia He wrote:
> >>> FYI,I watched a lockdep warning based on your mmotm master branch[1]
> >>
> >> Thanks. We'll nee
Hi Waiman,
On Tue, Aug 07, 2018 at 07:29:49PM -0400, Waiman Long wrote:
> On 07/24/2018 03:10 PM, Waiman Long wrote:
> > diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
> > index 3064c50..01fcb80 100644
> > --- a/kernel/locking/rwsem-xadd.c
> > +++ b/kernel/locking/rwsem-xad
On Thu, Aug 09, 2018 at 01:34:57PM +0100, Dave Martin wrote:
> On Wed, Aug 08, 2018 at 01:34:09PM +0100, Catalin Marinas wrote:
> > On Tue, Aug 07, 2018 at 11:24:34AM +0100, Marc Zyngier wrote:
> > > On 07/08/18 11:05, Dave Martin wrote:
> > > > On Tue, Aug 07, 2018 at 10:33:26AM +0100, Marc Zyngie
either Al Viro's
> or akpm's tree? Looks like akpm signed off on the last commits in
> reiserfs...
I think Andrew's tree makes the most sense for this, but perhaps we should
also patch MAINTAINERS so mark it as "Orphan"? Patch below.
Will
--->8
>From 07fbb021d
Hi Greg,
On Mon, Aug 13, 2018 at 12:30:11PM -0700, Greg Hackmann wrote:
> ARM64's pfn_valid() shifts away the upper PAGE_SHIFT bits of the input
> before seeing if the PFN is valid. This leads to false positives when
> some of the upper bits are set, but the lower bits match a valid PFN.
>
> For
rf: Disable PMU while processing counter overflows
arm64: perf: Add support for chaining event counters
Will Deacon (19):
drivers/perf: Initialise return value in armpmu_request_irqs()
arm64: barrier: Implement smp_cond_load_relaxed
arm64: locking: Replace ticket lock implemen
On Tue, Aug 14, 2018 at 08:17:48AM -0700, Greg Hackmann wrote:
> On 08/14/2018 03:40 AM, Will Deacon wrote:
> > Hi Greg,
> >
> > On Mon, Aug 13, 2018 at 12:30:11PM -0700, Greg Hackmann wrote:
> >> ARM64's pfn_valid() shifts away the upper PAGE_SHIFT bits of the
On Wed, Aug 22, 2018 at 10:11:41PM -0700, Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 9:54 PM Benjamin Herrenschmidt
> wrote:
> >
> >
> > So we do need a different flush instruction for the page tables vs. the
> > normal TLB pages.
>
> Right. ARM wants it too. x86 is odd in that a regular "i
rns out to be a performance issue, we can
> re-instate a more complete check, but in tlb_table_flush() eliding the
> call_rcu_sched().
>
> Cc: sta...@kernel.org
> Cc: Nicholas Piggin
> Cc: David Miller
> Cc: Will Deacon
> Cc: Martin Schwidefsky
> Cc: Michael Ellerman
> mm/memory.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Looks good to me, thanks:
Acked-by: Will Deacon
Will
> diff --git a/mm/memory.c b/mm/memory.c
> index 19f47d7b9b86..7c58310734eb 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -245,9 +245,6 @@ s
| 10 --
> 2 files changed, 13 insertions(+), 14 deletions(-)
I think we only use the notifiers in the KVM code, which appears to leave
the ->invalidate_range() callback empty, so that at least explains why we
haven't run into problems here.
But the change looks correct to me, so:
Acked-by: Will Deacon
Thanks,
Will
ic inline
but one that is defined in our asm/tlb.h after including asm-generic/tlb.h.
Ah, just noticed you've pushed this to master! Please could you take the
arm64 patch below on top, in order to fix the build?
Cheers,
Will
--->8
>From 48ea452db90a91ff2b62a94277daf565e715a126 Mon
On Wed, Aug 22, 2018 at 05:55:27PM +0200, Peter Zijlstra wrote:
> On Wed, Aug 22, 2018 at 05:30:15PM +0200, Peter Zijlstra wrote:
> > ARM
> > which later used this put an explicit TLB invalidate in their
> > __p*_free_tlb() functions, and PowerPC-radix followed that example.
>
> > +/*
> > + * If w
t; won't be called on part of the range in case of an unmap that spans
> > multiple vmas.
> >
> > ARM64 seems to be the only arch I could see that has notifiers and
> > uses the generic tlb_end_vma. I have not actually tested it.
> >
> > Signed-off-by: Nich
On Fri, Aug 24, 2018 at 06:24:19AM -0700, Guenter Roeck wrote:
> On Fri, Aug 24, 2018 at 02:10:27PM +0100, Will Deacon wrote:
> > On Fri, Aug 24, 2018 at 06:07:22AM -0700, Guenter Roeck wrote:
> > > On Thu, Aug 23, 2018 at 06:47:09PM +1000, Nicholas Piggin wrote:
> > >
On Fri, Aug 24, 2018 at 02:34:27PM +0100, Will Deacon wrote:
> On Fri, Aug 24, 2018 at 06:24:19AM -0700, Guenter Roeck wrote:
> > On Fri, Aug 24, 2018 at 02:10:27PM +0100, Will Deacon wrote:
> > > On Fri, Aug 24, 2018 at 06:07:22AM -0700, Guenter Roeck wrote:
> > > >
On Fri, Aug 24, 2018 at 07:06:51AM -0700, Guenter Roeck wrote:
> On 08/24/2018 06:50 AM, Will Deacon wrote:
>
> >>-#include
> >>+struct mmu_gather;
> >> static inline void tlb_flush(struct mmu_gather *tlb)
> >> {
> >>flush_tlb_mm(tlb-&g
Hi Peter,
On Fri, Aug 24, 2018 at 03:13:32PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 24, 2018 at 10:35:56AM +0200, Peter Zijlstra wrote:
>
> > Anyway, its sorted now; although I'd like to write me a fairly big
> > comment in asm-generic/tlb.h about things, before I forget again.
>
> How's som
large enough.
Signed-off-by: Will Deacon
---
arch/arm64/Kconfig| 1 +
arch/arm64/include/asm/tlb.h | 3 ---
arch/arm64/include/asm/tlbflush.h | 11 ---
3 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index
ic to take this into account.
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/tlb.h | 2 +-
arch/arm64/include/asm/tlbflush.h | 11 +++
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/include/asm/tlb.h b/arch/arm64/include/asm/tlb.h
index a3233167be6
Now that the core mmu_gather code keeps track of both the levels of page
table cleared and also whether or not these entries correspond to
intermediate entries, we can use this in our tlb_flush() callback to
reduce the number of invalidations we issue as well as their scope.
Signed-off-by: Will
in struct mmu_gather so that the
architecture code can operate accordingly if it's the intermediate
levels being invalidated.
Signed-off-by: Peter Zijlstra
Signed-off-by: Will Deacon
---
include/asm-generic/tlb.h | 31 +++
1 file changed, 23 insertions(+), 8 dele
Now that our walk-cache invalidation routines imply a DSB before the
invalidation, we no longer need one when we are clearing an entry during
unmap.
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/pgtable.h | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a
invalidation.
Signed-off-by: Will Deacon
---
include/asm-generic/tlb.h | 53 ---
mm/memory.c | 4 +++-
2 files changed, 48 insertions(+), 9 deletions(-)
diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index
-by: Will Deacon
---
arch/arm64/include/asm/tlbflush.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/include/asm/tlbflush.h
b/arch/arm64/include/asm/tlbflush.h
index 7e2a35424ca4..e257f8655b84 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
The inner workings of the mmu_gather-based TLB invalidation mechanism
are not relevant to nommu configurations, so guard them with an ifdef.
This allows us to implement future functions using static inlines
without breaking the build.
Signed-off-by: Will Deacon
---
include/asm-generic/tlb.h | 3
If there's one thing the RCU-based table freeing doesn't need, it's more
ifdeffery.
Remove the redundant !CONFIG_HAVE_RCU_TABLE_FREE code, since this option
is unconditionally selected in our Kconfig.
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/tlb.h | 12 +++-
long weekend
(Monday is a holiday in the UK) in the hope that it helps some of the
ongoing discussions.
Cheers,
Will
--->8
Peter Zijlstra (1):
asm-generic/tlb: Track freeing of page-table directories in struct
mmu_gather
Will Deacon (10):
arm64: tlb: Use last-level invalidation in
flush_tlb_kernel_range() is only ever used to invalidate last-level
entries, so we can restrict the scope of the TLB invalidation
instruction.
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/tlbflush.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include
Add a comment to explain why we can't get away with last-level
invalidation in flush_tlb_range()
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/tlbflush.h | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/include/asm/tlbflush.h
b/arch/arm64/include/asm/tlbflush.h
Hi Laura,
On Wed, Jul 25, 2018 at 03:05:58PM -0700, Laura Abbott wrote:
> On 07/25/2018 04:49 AM, Will Deacon wrote:
> >arch/arm64/kernel/sdei.c: At top level:
> >arch/arm64/kernel/sdei.c:127:6: error: conflicting types for ‘_on_sdei_stack’
> > bool _on_sdei_s
On Thu, Jul 26, 2018 at 05:01:47PM -0400, Dongjiu Geng wrote:
> In order to remove the additional check before calling the
> ghes_notify_sea(), make stub definition when !CONFIG_ACPI_APEI_SEA.
>
> Signed-off-by: Dongjiu Geng
> ---
Acked-by: Will Deacon
Will
> This cleanup
Hi Linus,
Inevitably, after saying that I hoped we would be done on the fixes front,
a couple of issues have cropped up over the last week. Next time I'll stay
schtum.
As usual, details are in the tag, but we've fixed an over-eager BUILD_BUG_ON()
which Arnd ran into with arndconfig, as well as en
On Fri, Jul 27, 2018 at 08:55:11PM +1000, Stephen Rothwell wrote:
> On Fri, 27 Jul 2018 19:06:47 +1000 Stephen Rothwell
> wrote:
> >
> > On Fri, 27 Jul 2018 19:02:07 +1000 Stephen Rothwell
> > wrote:
> > >
> > > After merging the kspp tree, today's linux-next build (x86_64
> > > allmodconfig) f
On Fri, Jul 27, 2018 at 01:55:22PM +0100, Will Deacon wrote:
> On Fri, Jul 27, 2018 at 08:55:11PM +1000, Stephen Rothwell wrote:
> > On Fri, 27 Jul 2018 19:06:47 +1000 Stephen Rothwell
> > wrote:
> > >
> > > On Fri, 27 Jul 2018 19:02:07 +1000 Stephen Rothwell
&g
On Fri, Jul 27, 2018 at 02:01:06PM +0100, Will Deacon wrote:
> On Fri, Jul 27, 2018 at 01:55:22PM +0100, Will Deacon wrote:
> > On Fri, Jul 27, 2018 at 08:55:11PM +1000, Stephen Rothwell wrote:
> > > On Fri, 27 Jul 2018 19:06:47 +1000 Stephen Rothwell
> > > wrote:
>
at may cause
> confusion.
>
> Signed-off-by: Waiman Long
> ---
> kernel/locking/rwsem-xadd.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
My nits with the commit message have been addressed, so:
Acked-by: Will Deacon
Thanks!
Will
On Mon, Jul 30, 2018 at 05:16:42PM +0100, Catalin Marinas wrote:
> On Mon, Jul 30, 2018 at 10:29:21AM -0500, Dave Kleikamp wrote:
> > machine_kexec flushes the reboot_code_buffer from the icache
> > after stopping the other cpus.
> >
> > Commit 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating
Hi Laura,
On Mon, Jul 30, 2018 at 07:47:52AM -0700, Laura Abbott wrote:
> On 07/30/2018 12:33 AM, Stephen Rothwell wrote:
> >On Fri, 27 Jul 2018 13:55:22 +0100 Will Deacon wrote:
> >>On Fri, Jul 27, 2018 at 08:55:11PM +1000, Stephen Rothwell wrote:
> >>>Actual
On Mon, Jul 30, 2018 at 11:46:24AM -0500, Dave Kleikamp wrote:
> On 07/30/2018 11:22 AM, Will Deacon wrote:
> > On Mon, Jul 30, 2018 at 05:16:42PM +0100, Catalin Marinas wrote:
> >> On Mon, Jul 30, 2018 at 10:29:21AM -0500, Dave Kleikamp wrote:
> >>> machine_kexec
c: Russell King
> Cc: John Paul Walters
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org,
> Signed-off-by: Alexei Colin
> ---
> arch/arm64/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
Thanks, this looks much cleaner than before:
Acke
On Mon, Jul 30, 2018 at 11:31:18AM -0700, Laura Abbott wrote:
> arm64 uses the full KBUILD_CFLAGS for building libstub as opposed
> to x86 which doesn't. This means that x86 doesn't pick up
> the gcc-plugins. We need to disable the stackleak plugin but
> doing this unconditionally breaks x86 build
On Mon, Jul 30, 2018 at 05:33:56PM +1000, Stephen Rothwell wrote:
> On Fri, 27 Jul 2018 13:55:22 +0100 Will Deacon wrote:
> > Thanks, Stephen. I managed to reproduce this by merging for-next/kspp from
> > Kees's tree and for-next/core from the arm64 tree. The failure happens w
On Tue, Jul 31, 2018 at 04:29:56PM -0400, Alex Bounine wrote:
> On 2018-07-31 08:54 AM, Alex Bounine wrote:
> >On 2018-07-31 04:41 AM, Will Deacon wrote:
> >>On Mon, Jul 30, 2018 at 06:50:34PM -0400, Alexei Colin wrote:
> >>>Platforms with a PCI bus will be offered t
On Thu, Aug 02, 2018 at 09:45:26AM +1200, Chris Packham wrote:
> GCC warns
>
> arm_pmu_platform.c:234:5: error: 'err' may be used uninitialized in this
> function [-Werror=maybe-uninitialized]
>
> This is because we rely on the for_each_cpu loop in armpmu_request_irqs
> to initialise err. The
Hi Linus,
Ard found a nasty arm64 regression in 4.18 where the AES ghash/gcm code
doesn't notify the kernel about its use of the vector registers, therefore
potentially corrupting live user state. The fix is straightforward and
Herbert agreed for it to go via arm64.
Please pull.
Thanks,
Will
-
Hi Stephen,
On Tue, Jul 24, 2018 at 08:50:15AM +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the arm64 tree got a conflict in:
>
> arch/arm64/Makefile
>
> between commits:
>
> 38fc42486775 ("arm64: Use aarch64elf and aarch64elfb emulation mode
> variants")
> 2893af07e507 (
On Tue, Jul 24, 2018 at 11:37:10AM +0200, Rafael J. Wysocki wrote:
> On Tue, Jul 24, 2018 at 11:33 AM, Arnd Bergmann wrote:
> > Kconfig reports a warning on x86 builds after the ARM64 dependency
> > was added.
> >
> > drivers/acpi/Kconfig:6:error: recursive dependency detected!
> > drivers/acpi/Kc
On Tue, Jul 24, 2018 at 11:46:23AM +0200, Arnd Bergmann wrote:
> On Tue, Jul 24, 2018 at 11:44 AM, Will Deacon wrote:
> > On Tue, Jul 24, 2018 at 11:37:10AM +0200, Rafael J. Wysocki wrote:
> >> On Tue, Jul 24, 2018 at 11:33 AM, Arnd Bergmann wrote:
>
> >
> > Ho
> Fixes: 5bcd44083a08 ("drivers: acpi: add dependency of EFI for arm64")
> > Signed-off-by: Arnd Bergmann
> > ---
> > v2: use 'select ARCH_SUPPORTS_ACPI' for all three.
>
> LGTM
>
> Reviewed-by: Rafael J. Wysocki
Same here:
Acked-by: Will Deacon
Would it be ok if I take this via the arm64 tree, since that's where the
warning was introduced?
Will
On Mon, Jul 23, 2018 at 12:27:35PM -0400, Johannes Weiner wrote:
> On Mon, Jul 23, 2018 at 05:35:35PM +0200, Arnd Bergmann wrote:
> > On Mon, Jul 23, 2018 at 5:23 PM, Johannes Weiner wrote:
> > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > > index 1b18b4722420..72c9b6778b0a 100644
On Tue, Jul 24, 2018 at 12:23:48PM +0200, Rafael J. Wysocki wrote:
> On Tue, Jul 24, 2018 at 12:21 PM, Will Deacon wrote:
> > On Tue, Jul 24, 2018 at 11:54:25AM +0200, Rafael J. Wysocki wrote:
> >> On Tue, Jul 24, 2018 at 11:48 AM, Arnd Bergmann wrote:
> >> > Kc
On Tue, Jul 24, 2018 at 09:45:14AM -0400, Alexei Colin wrote:
> ARM64 SoCs with a PCI bus present the RapiodIO options; SoCs with
> RapidIO IP blocks but without a PCI bus, need to select HAS_RAPIDIO in
> Kconfig.platforms.
>
> HAS_RAPIDIO was chosen over HAVE_RAPIDIO to be consistent with
> other
Hi Laura,
On Fri, Jul 20, 2018 at 02:41:52PM -0700, Laura Abbott wrote:
> This is the version of stackleak for arm64, hopefully ready for queueing
Thanks. I'll push these into linux-next tomorrow, once I've had a chance
to test my conflict resolution in entry.S.
Will
Hi Laura,
On Tue, Jul 24, 2018 at 05:38:07PM +0100, Will Deacon wrote:
> On Fri, Jul 20, 2018 at 02:41:52PM -0700, Laura Abbott wrote:
> > This is the version of stackleak for arm64, hopefully ready for queueing
>
> Thanks. I'll push these into linux-next tomorrow, once I&
On Tue, Jul 24, 2018 at 03:09:41PM +0530, Vivek Gautam wrote:
> On 7/24/2018 2:06 PM, Will Deacon wrote:
> >On Thu, Jul 19, 2018 at 11:23:56PM +0530, Vivek Gautam wrote:
> >>diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> >>index 7c69736a30f8..4c
.
These patches resolve the issue by allowing an architecture to define
COMPAT_SIGMINSTKSZ for compat tasks, which is then used by the sigaltstack
checking code.
Feedback welcome,
Will
--->8
Will Deacon (2):
signal: Introduce COMPAT_SIGMINSTKSZ for use in compat_sys_sigaltstack
arm64: com
arch/arm/ defines a SIGMINSTKSZ of 2k, so we should use the same value
for compat tasks.
Cc: Arnd Bergmann
Cc: Dominik Brodowski
Cc: "Eric W. Biederman"
Cc: Andrew Morton
Cc: Al Viro
Cc: Oleg Nesterov
Reported-by: Steve McIntyre
Signed-off-by: Will Deacon
---
arch/arm64/i
. COMPAT_SIGMINSTKSZ is just defined as SIGMINSTKSZ if it has not
been defined by the architecture.
Cc: Arnd Bergmann
Cc: Dominik Brodowski
Cc: "Eric W. Biederman"
Cc: Andrew Morton
Cc: Al Viro
Cc: Oleg Nesterov
Reported-by: Steve McIntyre
Signed-off-by: Will Deacon
---
include/linu
On Sun, Jul 15, 2018 at 03:35:45PM -0500, J. Agustín Vega-Frías wrote:
> On Fri, Jul 13, 2018 at 10:33 AM, Will Deacon wrote:
> > I'm mostly ok with this approach, but I have a concern with the way in which
> > the sysfs interface for carving up the config fields is impleme
On Tue, Jul 24, 2018 at 04:04:48PM +0100, Will Deacon wrote:
> On Mon, Jul 23, 2018 at 12:27:35PM -0400, Johannes Weiner wrote:
> > On Mon, Jul 23, 2018 at 05:35:35PM +0200, Arnd Bergmann wrote:
> > > On Mon, Jul 23, 2018 at 5:23 PM, Johannes Weiner
> > > wrote:
>
On Wed, Jul 25, 2018 at 04:54:27PM +0100, Dave Martin wrote:
> On Wed, Jul 25, 2018 at 02:45:11PM +0100, Will Deacon wrote:
> > @@ -3476,7 +3478,8 @@ int restore_altstack(const stack_t __user *uss)
> > stack_t new;
> > if (copy_from_user(&new, uss, sizeof(stack_t)
On Wed, Jul 11, 2018 at 02:34:21PM +0200, Andrea Parri wrote:
> On Wed, Jul 11, 2018 at 10:43:11AM +0100, Will Deacon wrote:
> > On Tue, Jul 10, 2018 at 11:38:21AM +0200, Andrea Parri wrote:
> > > This distinction between locking operations and "other acquires"
On Wed, Jul 11, 2018 at 04:47:58PM +0100, Mark Rutland wrote:
> On Wed, Jul 11, 2018 at 09:20:03AM +0200, Ard Biesheuvel wrote:
> > On 11 July 2018 at 03:09, Yandong.Zhao wrote:
> > > diff --git a/arch/arm64/include/asm/simd.h b/arch/arm64/include/asm/simd.h
> > > index fa8b3fe..784a8c2 100644
> >
On Thu, Jul 12, 2018 at 11:34:32AM +0200, Peter Zijlstra wrote:
> On Thu, Jul 12, 2018 at 09:40:40AM +0200, Peter Zijlstra wrote:
> > And I think if we raise atomic*_acquire() to require TSO (but ideally
> > raise it to RCsc) we're there.
>
> To clarify, just the RmW-acquire. Things like atomic_re
On Thu, Jun 28, 2018 at 05:18:28PM +0800, Shunyong Yang wrote:
> As PPTT spec doesn't define the physical package id,
> find_acpi_cpu_topology_package() will return offset of the node with
> Physical package field set when querying physical package id. So, it
> returns 162(0xA2) in following exampl
On Wed, Jul 11, 2018 at 05:05:32PM -0700, Kees Cook wrote:
> On Fri, Jun 29, 2018 at 12:05 PM, Laura Abbott wrote:
> > include/linux/stackleak.h | 1 +
> > [...]
> > diff --git a/include/linux/stackleak.h b/include/linux/stackleak.h
> > index e2da99b3a191..00d62b302efb 100644
> > ---
601 - 700 of 6287 matches
Mail list logo
