On Fri, Oct 05, 2018 at 04:17:30PM +0100, Marc Zyngier wrote:
> On Fri, 05 Oct 2018 15:13:48 +0100,
> Matthias Brugger wrote:
> >
> >
> >
> > On 05/10/2018 15:42, Marc Zyngier wrote:
> > > On 05/10/18 13:33, Matthias Brugger wrote:
> > >>
> > >>
> > >> On 05/10/2018 12:55, Marc Zyngier wrote:
>
) too.
>
> Signed-off-by: Andrey Ryabinin
> ---
> include/linux/linkage.h | 1 +
> 1 file changed, 1 insertion(+)
Looks sensible to me:
Acked-by: Will Deacon
Will
> diff --git a/include/linux/linkage.h b/include/linux/linkage.h
> index d7618c41f74c..7c47b1a471d4 100
64/lib/strrchr.S| 2 +-
> 10 files changed, 21 insertions(+), 16 deletions(-)
Acked-by: Will Deacon
Please post these again after the merge window and we'll figure out how to
get them queued.
Will
On Mon, Oct 29, 2018 at 02:55:58PM +0530, Ashish Mhetre wrote:
> From: Alex Van Brunt
>
> Accessed bit is used to age a page and in generic implementation there is
> flush_tlb while clearing the accessed bit.
> Flushing a TLB is overhead on ARM64 as access flag faults don't get
> translation tabl
Hi Andrey, Andrew,
On Mon, Oct 29, 2018 at 11:16:15AM +, Andrey Ryabinin wrote:
> On 10/29/2018 01:29 PM, Will Deacon wrote:
> > On Thu, Sep 20, 2018 at 04:56:30PM +0300, Andrey Ryabinin wrote:
> >> ARM64 has asm implementation of memchr(), memcmp(), str[r]chr(),
> >
Hi John,
On Fri, Oct 26, 2018 at 09:57:47PM +0800, John Garry wrote:
> Currently it is acceptable to set the distance between 2 separate nodes to
> LOCAL_DISTANCE.
>
> Reject this as it is invalid.
>
> This change avoids a crash reported in [1].
>
> [1] https://www.spinics.net/lists/arm-kernel/
Hi Anders,
On Mon, Oct 15, 2018 at 01:16:00PM +0200, Anders Roxell wrote:
> Commit 1404d6f13e47 ("arm64: dump: Add checking for writable and exectuable
> pages")
> has successfully identified code that leaves a page with W+X
> permissions.
>
> [3.245140] arm64/mm: Found insecure W+X mapping
On Mon, Oct 29, 2018 at 12:14:09PM +, John Garry wrote:
> On 29/10/2018 11:25, Will Deacon wrote:
> >On Fri, Oct 26, 2018 at 09:57:47PM +0800, John Garry wrote:
> >>Currently it is acceptable to set the distance between 2 separate nodes to
> >>LOCAL_DISTANCE.
&g
On Mon, Oct 29, 2018 at 06:15:42PM +0530, Anshuman Khandual wrote:
> On 10/29/2018 06:02 PM, John Garry wrote:
> > On 29/10/2018 12:16, Will Deacon wrote:
> >> On Mon, Oct 29, 2018 at 12:14:09PM +, John Garry wrote:
> >>> On 29/10/2018 11:25, Will Deacon wrote:
Hi Jessica,
On Fri, Oct 26, 2018 at 07:25:01PM +0200, Jessica Yu wrote:
> The arm64 module loader keeps a pointer into info->sechdrs to keep track
> of section header information for .plt section(s). A pointer to the
> relevent section header (struct elf64_shdr) in info->sechdrs is stored
> in mod
On Mon, Oct 29, 2018 at 01:11:24PM +0100, Arnd Bergmann wrote:
> On 10/29/18, Will Deacon wrote:
> > On Mon, Oct 15, 2018 at 01:16:00PM +0200, Anders Roxell wrote:
>
> >> -static int __kprobes patch_text(kprobe_opcode_t *addr, u32 opcode)
> >> +void *alloc_insn_p
efined properly instead of
> set and checked with a build bug. This also allows us to use the same
> define for riscv.
>
> Signed-off-by: Logan Gunthorpe
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Arnd Bergmann
> Cc: Andrew Morton
> Cc: Christoph Hellwig
&g
k);
> static void __kprobes
> post_kprobe_handler(struct kprobe_ctlblk *, struct pt_regs *);
>
> +static int __kprobes patch_text(kprobe_opcode_t *addr, u32 opcode)
> +{
> + void *addrs[1];
> + u32 insns[1];
> +
> + addrs[0] = (void *)addr;
> + insns[0] = (u32)opcode;
I know they exist already, but I think you can drop these casts (Catalin can
do it when he picks this up -- no need to respin).
With that:
Acked-by: Will Deacon
Thanks for respinning so quickly.
Will
[Sorry to be "that person" but please can you use plain text for your mail?
This is getting really hard to follow.]
On Tue, Oct 30, 2018 at 11:17:34AM +0530, Ashish Mhetre wrote:
> On 29/10/18 4:25 PM, Will Deacon wrote:
> On Mon, Oct 29, 2018 at 02:55:58PM +0530, Ash
On Tue, Oct 30, 2018 at 04:58:41PM +0100, Peter Zijlstra wrote:
> On Mon, Oct 29, 2018 at 11:17:14PM +0200, Igor Stoppa wrote:
> >
> >
> > On 25/10/2018 01:13, Peter Zijlstra wrote:
> > > On Wed, Oct 24, 2018 at 12:35:03AM +0300, Igor Stoppa wrote:
> > > > +static __always_inline
> > > > +bool __
Hi Arnaldo,
On Wed, Oct 31, 2018 at 12:45:50PM -0300, Arnaldo Carvalho de Melo wrote:
> So I noticed the following build failure thare point to:
>
> commit 09d62154f61316f7e97eae3f31ef8770c7e4b386
> Author: Daniel Borkmann
> Date: Fri Oct 19 15:51:02 2018 +0200
>
> tools, perf: add and us
[+PeterZ -- please include him on stuff like this]
Hi Gao,
On Tue, Oct 30, 2018 at 02:04:41PM +0800, Gao Xiang wrote:
> It is better to use wrapped smp_cond_load_relaxed
> instead of open-coded busy waiting for bit_spinlock.
>
> Signed-off-by: Gao Xiang
> ---
>
> change log v2:
> - fix the in
On Fri, Nov 02, 2018 at 11:45:00AM +0530, Anshuman Khandual wrote:
> On 10/17/2018 07:39 AM, Andrea Arcangeli wrote:
> > What we need to do during split is an invalidate of the huge TLB.
> > There's no pmd_trans_splitting anymore, so we only clear the present
> > bit in the PTE despite pmd_present
AL_DISTANCE)) {
> + pr_err("Invalid distance[node%d -> node%d] = %d\n",
> +nodea, nodeb, distance);
> + return -EINVAL;
> + }
> +
> numa_set_distance(nodea, nodeb, distance);
> - pr_debug("distance[node%d -> node%d] = %d\n",
> - nodea, nodeb, distance);
Looks good to me, although I'm not sure which tree this should go through.
Acked-by: Will Deacon
Will
d
> for these, to be used by subsequent patches.
>
> Signed-off-by: Mark Rutland
> Signed-off-by: Kristina Martsenko
> Cc: Catalin Marinas
> Cc: Marc Zyngier
> Cc: Suzuki K Poulose
> Cc: Will Deacon
> ---
> arch/arm64/include/asm/esr.h| 3 ++-
> arch/
On Wed, Oct 10, 2018 at 05:12:57PM +0100, Will Deacon wrote:
> On Wed, Oct 03, 2018 at 03:03:01PM +0200, Peter Zijlstra wrote:
> > arch/x86/include/asm/qspinlock.h | 15 +++
> > kernel/locking/qspinlock.c | 16 +++-
> > 2 files changed
On Fri, Oct 12, 2018 at 05:55:28AM -0700, Sodagudi Prasad wrote:
> On 2018-10-10 09:49, Will Deacon wrote:
> >On Tue, Oct 09, 2018 at 01:56:14PM -0700, Sodagudi Prasad wrote:
> >>This is regarding - thread "try to fix contention between expire_timers
> >>and
>
nts when they are not part of a 64-bit counter
- Fix WARN_ON_ONCE() that triggers for reserved regions that don't
correspond to mapped memory
----
Will Deacon (2):
arm64: Fix /proc/iomem for reserved but not memory regions
Hi Ganapat,
On Thu, Oct 04, 2018 at 11:12:09AM +0530, Ganapatrao Kulkarni wrote:
> can you please pull this patch?
I still don't like the idea of just removing events like this, especially
when other architectures (including some x86 and Power CPUs afaict) playa
similar games for generic events,
On Fri, Oct 05, 2018 at 01:27:08PM +0100, John Garry wrote:
> On 04/10/2018 13:22, Will Deacon wrote:
> >Hi Ganapat,
> >
> >On Thu, Oct 04, 2018 at 11:12:09AM +0530, Ganapatrao Kulkarni wrote:
> >>can you please pull this patch?
> >
> >I still don't
On Fri, Oct 05, 2018 at 01:09:33AM +0530, Ganapatrao Kulkarni wrote:
> On Thu, Oct 4, 2018 at 5:51 PM Will Deacon wrote:
> > On Thu, Oct 04, 2018 at 11:12:09AM +0530, Ganapatrao Kulkarni wrote:
> > > can you please pull this patch?
> >
> > I still don't like th
[apologies if you get this twice -- my GPU hung (!) whilst sending my
previous response]
On Wed, Oct 31, 2018 at 06:14:56PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Oct 31, 2018 at 07:08:29PM +0100, Daniel Borkmann escreveu:
> > On 10/31/2018 06:44 PM, Will Deacon wrote:
> &g
Peter,
On Thu, Nov 01, 2018 at 09:11:52AM +0800, kbuild test robot wrote:
> FYI, the error/warning still remains.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 5b7449810ae6d652629c550d3974c8453836d229
> commit: 7aa54be2976550f17c11a1c3e3630002d
[ Nit: Please wrap your lines when replying -- I've done it for you here ]
On Tue, Oct 30, 2018 at 08:16:21AM +0530, Anshuman Khandual wrote:
> On 10/29/2018 08:14 PM, John Garry wrote:
> > I think we should either factor out the sanity check
> >> into a core helper or make the core code
Hello, Jessica,
On Tue, Oct 30, 2018 at 02:19:10PM +0100, Jessica Yu wrote:
> +++ Will Deacon [29/10/18 15:28 +]:
> >On Fri, Oct 26, 2018 at 07:25:01PM +0200, Jessica Yu wrote:
> >>diff --git a/arch/arm64/include/asm/module.h
> >>b/arch/arm64/include/asm/modu
On Thu, Nov 01, 2018 at 11:25:31AM -0400, Yangtao Li wrote:
> Signed-off-by: Yangtao Li
> ---
> arch/arm64/kernel/crash_dump.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/crash_dump.c b/arch/arm64/kernel/crash_dump.c
> index f46d57c31443..6b5037ed15
being flushed after somebody else has already done something to that
page).
This also makes the whole "need_flush" logic unnecessary, since we now
always end up flushing the TLB for every valid entry.
Reported-and-tested-by: Jann Horn
Acked-by: Will Deacon
Tested-by: Ingo Molnar
A
, 1 insertion(+)
>
> diff --git a/.mailmap b/.mailmap
> index a76be45fef6c..28fecafa6506 100644
> --- a/.mailmap
> +++ b/.mailmap
> @@ -159,6 +159,7 @@ Peter Oruba
> Peter Oruba
> Pratyush Anand
> Praveen BP
> +Punit Agrawal
> Qais Yousef
> Oleksij Rempe
t; ---
>
> v2:
>
> - Do sechdrs[pltsec->plt_shndx].sh_addr instead of pointer math
>
> Note: Addressed Will's comment about the pltsec -> plt_info rename and
> removed that change to reduce unnecessary code churn. I didn't include the
> Ack's for this reason
Hi Ingo,
On Mon, Oct 08, 2018 at 06:15:24PM +0100, Mark Rutland wrote:
> On Tue, Sep 04, 2018 at 11:48:24AM +0100, Mark Rutland wrote:
> > As previously requested, this is a (trivial) rebase of the remaining
> > generated
> > atomic patches atop of v4.19-rc2, avoiding any potential conflict with
On Fri, Oct 19, 2018 at 12:35:56PM +0100, Catalin Marinas wrote:
> On Tue, Oct 16, 2018 at 05:14:39PM +0100, Kristina Martsenko wrote:
> > On 05/10/2018 10:04, Ramana Radhakrishnan wrote:
> > > On 05/10/2018 09:47, Kristina Martsenko wrote:
> > The other special case is the XPACLRI instruction, whi
On Mon, Oct 22, 2018 at 12:08:30PM +0200, Peter Zijlstra wrote:
> ARGH; so, this:
>
> #define __GEN_RMWcc(fullop, _var, cc, clobbers, ...) \
> ({\
> bool c = false;
On Fri, Sep 14, 2018 at 09:10:49PM +, Kani, Toshi wrote:
> On Fri, 2018-09-14 at 14:36 -0600, Toshi Kani wrote:
> > On Wed, 2018-09-12 at 11:26 +0100, Will Deacon wrote:
> > > The recently merged API for ensuring break-before-make on page-table
> > > entries when
On Fri, Sep 14, 2018 at 08:37:48PM +, Kani, Toshi wrote:
> On Wed, 2018-09-12 at 11:26 +0100, Will Deacon wrote:
> > Now that the core code checks this for us, we don't need to do it in the
> > backend.
> >
> > Cc: Chintan Pandya
> > Cc: Toshi Kani
&
On Mon, Aug 27, 2018 at 04:33:06PM +0200, Mian Yousaf Kaukab wrote:
> Checking CSV3 support directly in case CONFIG_UNMAP_KERNEL_AT_EL0
> is not enabled.
>
> Signed-off-by: Mian Yousaf Kaukab
> ---
> arch/arm64/kernel/cpu_errata.c | 24
> 1 file changed, 24 insertions(+)
On Mon, Aug 27, 2018 at 04:33:09PM +0200, Mian Yousaf Kaukab wrote:
> Return status based no ssbd_state. Return string "Unknown" in case
> CONFIG_ARM64_SSBD is disabled or arch workaround2 is not available
> in the firmware.
>
> Signed-off-by: Mian Yousaf Kaukab
> ---
> arch/arm64/kernel/cpu_err
On Mon, Aug 27, 2018 at 04:33:08PM +0200, Mian Yousaf Kaukab wrote:
> Only report mitigation present if hardening callback has been
> successfully installed.
>
> Signed-off-by: Mian Yousaf Kaukab
> ---
> arch/arm64/kernel/cpu_errata.c | 34 +-
> 1 file changed, 33
On Wed, Sep 05, 2018 at 11:25:33AM +0200, Mian Yousaf Kaukab wrote:
> On Mon, Aug 27, 2018 at 04:33:04PM +0200, Mian Yousaf Kaukab wrote:
> > GENERIC_CPU_VULNERABILITIES provide a common way to figure out if a
> > system is affected by vulnerabilities like meltdown and other variants
> > of spectre
On Mon, Sep 17, 2018 at 07:22:07PM +0200, Robert Richter wrote:
> On 27.08.18 16:33:07, Mian Yousaf Kaukab wrote:
> > Hard-coded since patches are merged and there are no configuration
> > options.
>
> Could you add a list of upstream patches to the description that are
> required to solve this? T
On Tue, Sep 18, 2018 at 06:55:34AM -0400, Mikulas Patocka wrote:
> This patch is not correct, because the stacktrace is supposed to work
> around discontiguous interrupt stacks.
>
> You should replace 'frame->fp <= fp' with 'frame->fp == fp'.
No, just drop the patch. It was already reverted upst
On Tue, Sep 18, 2018 at 12:40:57PM +0530, Sai Prakash Ranjan wrote:
> On 9/18/2018 5:09 AM, Steven Rostedt wrote:
> >On Sun, 9 Sep 2018 01:57:06 +0530
> >Sai Prakash Ranjan wrote:
> >
> >>The new asm-generic/io-instrumented.h will keep arch code
> >>clean and separate from instrumented version wh
On Mon, Sep 17, 2018 at 06:10:05PM +0100, John Garry wrote:
>
> >>+
> >>+#define SMMU_EVENT_ATTR(_name, _id) \
> >>+(&((struct perf_pmu_events_attr[]) { \
> >>+{ .attr = __ATTR(_name, 0444, smmu_pmu_event_show, NULL), \
> >>+ .id = _id, }
#x27; range tracking for classical
> ARM in __pte_free_tlb().
>
> Cc: Will Deacon
> Cc: "Aneesh Kumar K.V"
> Cc: Andrew Morton
> Cc: Nick Piggin
> Cc: Russell King
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> arch/arm/include/asm/tlb.h | 255
> +
On Tue, Sep 18, 2018 at 11:52:27AM +0200, Robert Richter wrote:
> On 18.09.18 09:38:05, Will Deacon wrote:
> > On Mon, Sep 17, 2018 at 07:22:07PM +0200, Robert Richter wrote:
> > > On 27.08.18 16:33:07, Mian Yousaf Kaukab wrote:
> > > > Hard-coded since patch
On Thu, Mar 14, 2024 at 05:49:23PM +1000, Gavin Shan wrote:
> The issue is reported by Yihuang Yu who have 'netperf' test on
> NVidia's grace-grace and grace-hopper machines. The 'netperf'
> client is started in the VM hosted by grace-hopper machine,
> while the 'netperf' server is running on grace
On Tue, Mar 19, 2024 at 03:36:31AM -0400, Michael S. Tsirkin wrote:
> On Mon, Mar 18, 2024 at 04:59:24PM +0000, Will Deacon wrote:
> > On Thu, Mar 14, 2024 at 05:49:23PM +1000, Gavin Shan wrote:
> > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> &
On Tue, Mar 19, 2024 at 02:59:23PM +1000, Gavin Shan wrote:
> On 3/19/24 02:59, Will Deacon wrote:
> > On Thu, Mar 14, 2024 at 05:49:23PM +1000, Gavin Shan wrote:
> > > The issue is reported by Yihuang Yu who have 'netperf' test on
> > > NVidia's grace-gra
On Tue, Mar 26, 2024 at 09:38:55AM +, Keir Fraser wrote:
> On Tue, Mar 26, 2024 at 03:49:02AM -0400, Michael S. Tsirkin wrote:
> > > Secondly, the debugging code is enhanced so that the available head for
> > > (last_avail_idx - 1) is read for twice and recorded. It means the
> > > available
>
On Tue, Mar 26, 2024 at 11:43:13AM +, Will Deacon wrote:
> On Tue, Mar 26, 2024 at 09:38:55AM +, Keir Fraser wrote:
> > On Tue, Mar 26, 2024 at 03:49:02AM -0400, Michael S. Tsirkin wrote:
> > > > Secondly, the debugging code is enhanced so that t
> some places treat it as an empty ring, others - non empty.
> This patch does not attempt to change the existing behaviour.
>
> Cc: sta...@vger.kernel.org
> Reported-by: Gavin Shan
> Reported-by: Will Deacon
> Suggested-by: Will Deacon
> Fixes: 275bf960ac69 (&qu
rn false;
> -}
> -
> bool kvm_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
> {
> u64 size = (range->end - range->start) << PAGE_SHIFT;
Thanks. It's nice to see this code retire:
Acked-by: Will Deacon
Also, if you're in the business of hacking t
On Mon, Apr 15, 2024 at 10:03:51AM -0700, Sean Christopherson wrote:
> On Sat, Apr 13, 2024, Marc Zyngier wrote:
> > On Fri, 12 Apr 2024 15:54:22 +0100, Sean Christopherson
> > wrote:
> > >
> > > On Fri, Apr 12, 2024, Marc Zyngier wrote:
> > > > On
On Thu, Apr 18, 2024 at 12:53:26PM -0700, Sean Christopherson wrote:
> On Thu, Apr 18, 2024, Will Deacon wrote:
> > On Mon, Apr 15, 2024 at 10:03:51AM -0700, Sean Christopherson wrote:
> > > On Sat, Apr 13, 2024, Marc Zyngier wrote:
> > > > On Fri, 12 Apr 2024 15:54
Hi Klara,
On Fri, May 17, 2024 at 01:00:31AM +0200, Klara Modin wrote:
> On 2024-05-05 18:06, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > BPF just-in-time compiler depended on CONFIG_MODULES because it used
> > module_alloc() to allocate memory for the generated code.
> >
> > S
Hi Mike,
On Mon, Sep 18, 2023 at 10:29:46AM +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> Extend execmem parameters to accommodate more complex overrides of
> module_alloc() by architectures.
>
> This includes specification of a fallback range required by arm, arm64
> and powerp
; -{
> - return __vmalloc_node_range(PAGE_SIZE, 1, VMALLOC_START, VMALLOC_END,
> - GFP_KERNEL, PAGE_KERNEL_ROX, VM_FLUSH_RESET_PERMS,
> - NUMA_NO_NODE, __builtin_return_address(0));
> -}
It's slightly curious that we didn't clear the tag here, so it's nice that
it all happens magically with your series:
Acked-by: Will Deacon
Will
On Thu, Oct 26, 2023 at 11:58:00AM +0300, Mike Rapoport wrote:
> On Mon, Oct 23, 2023 at 06:14:20PM +0100, Will Deacon wrote:
> > On Mon, Sep 18, 2023 at 10:29:46AM +0300, Mike Rapoport wrote:
> > > diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
> &
On Mon, Oct 30, 2023 at 09:00:53AM +0200, Mike Rapoport wrote:
> On Thu, Oct 26, 2023 at 11:24:39AM +0100, Will Deacon wrote:
> > On Thu, Oct 26, 2023 at 11:58:00AM +0300, Mike Rapoport wrote:
> > > On Mon, Oct 23, 2023 at 06:14:20PM +0100, Will Deacon wrote:
> > > >
On Wed, 11 Oct 2023 19:57:26 +0200, Luca Weiss wrote:
> From: Vladimir Lypak
>
> If the IOMMU has a power domain then some state will be lost in
> qcom_iommu_suspend and TZ will reset device if we don't call
> qcom_scm_restore_sec_cfg before accessing it again.
>
>
> [...]
Applied to will (for
On Tue, 12 Sep 2023 15:31:38 +0200, Konrad Dybcio wrote:
> After the recent cleanups ([1], [2]) some in-tree abusers that directly
> accessed the RPM bus clocks, effectively circumventing and working
> against the efforts of the interconnect framework, were found.
>
> Patches 1-5 drop deprecated r
e_policy check
arm64: topology: Reorder init_amu_fie() a bit
arm64: topology: Make AMUs work with modular cpufreq drivers
Wei Li (1):
drivers/perf: Add support for ARMv8.3-SPE
Will Deacon (23):
mm: Allow architectures to request 'old' entries when prefaulting
On Wed, Apr 07, 2021 at 05:49:02PM +0800, Qi Liu wrote:
> PCIe PMU Root Complex Integrated End Point(RCiEP) device is supported
> to sample bandwidth, latency, buffer occupation etc.
>
> Each PMU RCiEP device monitors multiple root ports, and each RCiEP is
> registered as a pmu in /sys/bus/event_s
On Wed, Apr 07, 2021 at 04:31:31PM +0100, Alexandru Elisei wrote:
> On 3/26/21 3:16 AM, Yanan Wang wrote:
> > We currently uniformly permorm CMOs of D-cache and I-cache in function
> > user_mem_abort before calling the fault handlers. If we get concurrent
> > guest faults(e.g. translation faults, p
eturn ioremap_np(offset, size) ?: ioremap(offset, size);
but however it's done, the logic looks good to me and thanks Hector for
updating this:
Acked-by: Will Deacon
Will
mp;aic_vipi_flag, cpu));
> +
> + /*
> + * The atomic_fetch_or_release() above must complete before the
> + * atomic_read_acquire() below to avoid racing aic_ipi_unmask().
> + */
(same here)
> + smp_mb__after_atomic();
&g
1 +
> arch/arm64/kernel/Makefile | 5 +
> arch/arm64/kernel/syscall.c | 16 ++++
> 3 files changed, 22 insertions(+)
Acked-by: Will Deacon
Will
On Thu, Apr 01, 2021 at 04:23:44PM -0700, Kees Cook wrote:
> This provides the ability for architectures to enable kernel stack base
> address offset randomization. This feature is controlled by the boot
> param "randomize_kstack_offset=on/off", with its default value set by
> CONFIG_RANDOMIZE_KSTA
Hi John,
On Thu, Apr 08, 2021 at 01:55:02PM +0100, John Garry wrote:
> On 08/04/2021 10:01, Jonathan Cameron wrote:
> > On Wed, 7 Apr 2021 21:40:05 +0100
> > Will Deacon wrote:
> >
> > > On Wed, Apr 07, 2021 at 05:49:02PM +0800, Qi Liu wrote:
> > > >
Hi Joerg,
There's hardly anything on the SMMU front for 5.13, but please pull
these regardless. Summary in the tag.
Cheers,
Will
--->8
The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0:
Linux 5.12-rc3 (2021-03-14 14:41:02 -0700)
are available in the Git repository
d asynchronous
> tag check faults")
> Cc: Catalin Marinas
> Cc: Will Deacon
> Reported-by: Will Deacon
> Signed-off-by: Vincenzo Frascino
> ---
> arch/arm64/include/asm/mte.h | 8
> arch/arm64/kernel/entry-common.c | 6 ++
> arch/arm64/kernel
On Thu, Apr 08, 2021 at 04:06:23PM +0100, Mark Rutland wrote:
> On Thu, Apr 08, 2021 at 03:56:04PM +0100, Will Deacon wrote:
> > On Thu, Apr 08, 2021 at 03:37:23PM +0100, Vincenzo Frascino wrote:
> > > diff --git a/arch/arm64/kernel/entry-common.c
> > > b/arch/
: Implement this_cpu operations
Vladimir Murzin (1):
arm64: compat: align cacheflush syscall with arch/arm
Will Deacon (9):
Merge tag 'for-3.19' of
git://git.linaro.org/people/ard.biesheuvel/linux-arm into ard/efi-for-3.19
arm64: entry: avoid writing lr explicitly for con
On Thu, Dec 11, 2014 at 10:08:33AM +, Philipp Zabel wrote:
> Hi Abhilash,
>
> Am Donnerstag, den 11.12.2014, 08:28 +0530 schrieb Abhilash Kesavan:
> > Currently, the SRAM allocator returns device memory via ioremap.
> > This causes issues on ARM64 when the internal SoC SRAM allocated by
> > th
Hi all,
Sorry for the late reply, it seems that neither myself or the
arm-linux-kernel list were on CC for this thread.
On Mon, Jan 05, 2015 at 04:51:31AM +, Nicolas Pitre wrote:
> On Sun, 4 Jan 2015, Russell King - ARM Linux wrote:
> > I encourage you *not* to back down like this. Linus is
Hi Ted,
On Mon, Jan 05, 2015 at 01:34:36AM +, Theodore Ts'o wrote:
> On Sun, Jan 04, 2015 at 09:26:59PM +, Russell King - ARM Linux wrote:
> >
> > With the revert in place, we now have insanely small bogomips values
> > reported via /proc/cpuinfo when hardware timers are used. That needs
049e1000 135168 _nv013521rm+0x4d/0xd0
> [nvidia] phys=e014 ioremap
>
> Signed-off-by: Min-Hua Chen
> ---
Thanks, this looks useful for debugging.
Acked-by: Will Deacon
I assume this can wait for 3.20?
Will
> arch/arm64/mm/ioremap.c |1 +
> 1 file changed, 1 inser
On Sun, Jan 04, 2015 at 08:37:24PM +, Pavel Machek wrote:
> On Sun 2015-01-04 15:25:02, Nicolas Pitre wrote:
> > On Sun, 4 Jan 2015, Pavel Machek wrote:
> >
> > > On Sun 2015-01-04 15:03:02, Nicolas Pitre wrote:
> > > > If that is still unacceptable to you for whatever reason, then the
> > >
;
> Signed-off-by: Michael S. Tsirkin
>
> Acked-by: Will Deacon
> ---
Did you want us to take this via the arm64 tree, or are you planning to
merge it via another route?
Will
> arch/arm64/include/asm/uaccess.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
On Mon, Jan 05, 2015 at 11:52:42PM +, AKASHI Takahiro wrote:
> Hi Will,
Hi Akashi,
> What's the current status of this patch?
> I'm pretty sure that the bug is reproducable and can be fixed
> with my patch since I've got a report from another guy
> who had the same problem and tried my patch.
On Mon, Jan 05, 2015 at 07:31:20PM +, Daniel Thompson wrote:
> On Mon, Jan 05, 2015 at 03:57:39PM +0100, Peter Zijlstra wrote:
> > On Fri, Nov 21, 2014 at 04:24:26PM +, Daniel Thompson wrote:
> > > diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> > > index 266cba46
MU. Need test by someone to make sure I don't
> >> break anything.
> >
> > The IOMMU changes look trivial. We may want to address the comment in
> > of_iommu_configure about parent nodes. We should be sure these changes
> > work with how we would do searching pare
d because this matches the limit
> imposed in __hw_perf_event_init(). This causes a doubling of the interrupt
> rate for large threshold values, however even with a very fast counter
> ticking at 4GHz the interrupt rate would only be ~1Hz.
>
> Signed-off-by: Daniel Thompson
Acked-by: Will De
On Fri, Nov 21, 2014 at 04:24:27PM +, Daniel Thompson wrote:
> If the overflow threshold for a counter is set above or near the
> 0x boundary then the kernel may lose track of the overflow
> causing only events that occur *after* the overflow to be recorded.
> Specifically the problem o
On Mon, Dec 01, 2014 at 06:36:04PM +, Linus Torvalds wrote:
> On Mon, Dec 1, 2014 at 10:25 AM, Kirill A. Shutemov
> wrote:
> >
> > No idea about oom_score, but kernel happily accepts chmod on any file
> > under /proc/PID/net/.
>
> /proc used to accept that fairly widely, but no, we tightened
On Thu, Dec 04, 2014 at 03:46:33PM +, Alexander Graf wrote:
> With binutils 2.25 the default alignment for 32bit arm sections changed to
> have everything 64k aligned. Armv7 binaries built with this binutils version
> run successfully on an arm64 system.
>
> Since effectively there is now the
On Fri, Dec 05, 2014 at 11:14:55AM +, Catalin Marinas wrote:
> On Thu, Dec 04, 2014 at 09:15:12PM +, Olof Johansson wrote:
> > On Thu, Dec 4, 2014 at 7:46 AM, Alexander Graf wrote:
> > > With binutils 2.25 the default alignment for 32bit arm sections changed to
> > > have everything 64k al
On Thu, Dec 04, 2014 at 12:03:05PM +, Catalin Marinas wrote:
> On Mon, Sep 15, 2014 at 12:33:25PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Sep 15, 2014 at 07:07:20PM +0800, Wang, Yalin wrote:
> > > @@ -636,6 +646,11 @@ static int keep_initrd;
> > > void free_initrd_mem(unsigned long
On Fri, Dec 05, 2014 at 09:45:08AM +, Russell King - ARM Linux wrote:
> On Fri, Dec 05, 2014 at 10:22:22AM +0100, Arend van Spriel wrote:
> > For our brcm80211 development we are working on getting brcmfmac driver
> > up and running on a Broadcom ARM-based platform. The wireless device is
> > a
On Thu, Dec 04, 2014 at 02:56:31PM +, Dave Jones wrote:
> On Thu, Dec 04, 2014 at 10:51:03AM +0000, Will Deacon wrote:
>
> > and, as before, it has a weird child process that I can't backtrace:
> >
> > trinity-c1 R running task0 8618
On Sat, Dec 06, 2014 at 05:23:59PM +, Alexander Graf wrote:
> On 04.12.14 19:20, Will Deacon wrote:
> > On Thu, Dec 04, 2014 at 03:46:33PM +, Alexander Graf wrote:
> >> With binutils 2.25 the default alignment for 32bit arm sections changed to
> >> have ev
On Mon, Dec 08, 2014 at 07:49:08AM +, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the xen-tip tree got a conflict in
> arch/arm/include/asm/dma-mapping.h between commits a3a60f81ee6f
> ("dma-mapping: replace set_arch_dma_coherent_ops with
> arch_setup_dma_ops") and 4bb257
On Tue, Jan 20, 2015 at 09:35:45PM +, Paul E. McKenney wrote:
> On Tue, Jan 20, 2015 at 10:34:43AM +0100, Peter Zijlstra wrote:
> > On Tue, Jan 13, 2015 at 04:33:54PM +0000, Will Deacon wrote:
> > > I started dusting off a series I've been working to implement a rela
ssed through an
> > integer.
> >
> > Fix that up using __force.
> >
> > Signed-off-by: Michael S. Tsirkin
> >
> > Acked-by: Will Deacon
>
> I'm not sure who's going to merge this series. In the meantime, I
> cherry-picked the arm64 patch.
Hello Linus,
arm64 fixes seem to come in pairs recently, so please pull these two for
-rc6. We've got a fix for removing device-tree blobs when doing a make
clean and another one addressing a missing include, which fixes build
failures in -next for allmodconfig (spotted by Mark's buildbot).
Hopef
Hi Andy,
Thanks for the patch.
On Fri, Jan 23, 2015 at 05:31:54PM +, Andy Whitcroft wrote:
> When compiling the kernel with very recent gcc-4.9 compilers we see the
> following errors:
>
> /tmp/ccEayz7S.s: Assembler messages:
> /tmp/ccEayz7S.s:41: Error: .err encountered
> /tmp/c
1101 - 1200 of 6344 matches
Mail list logo
