Hi Peter,
Cheers for taking a look.
On Tue, Dec 15, 2020 at 06:36:45PM +0100, Peter Zijlstra wrote:
> On Tue, Dec 08, 2020 at 01:28:20PM +, Will Deacon wrote:
> > The aim of this series is to allow 32-bit ARM applications to run on
> > arm64 SoCs where not all of the CPUs sup
bal iova rcache on iova alloc failure
Will Deacon (10):
Merge branch 'stable/for-linus-5.10-rc2' of
git://git.kernel.org/.../konrad/swiotlb into for-next/iommu/vt-d
Merge branch 'for-next/iommu/io-pgtable-domain-attr' into
for-next/iommu/arm-smmu
Merge branch 'for-next/iommu/arm-sm
C
> # which is only understood by binutils starting with version 2.33.1.
> - depends on LD_IS_LLD || LD_VERSION >= 23301 || (CC_IS_GCC &&
> GCC_VERSION < 90100)
> + depends on LD_IS_LLD || LD_VERSION >= 23301 || (CC_IS_GCC &&
> GCC_VERSION < 90100)
> depends on !CC_IS_CLANG || AS_HAS_CFI_NEGATE_RA_STATE
> depends on (!FUNCTION_GRAPH_TRACER || DYNAMIC_FTRACE_WITH_REGS)
> help
Acked-by: Will Deacon
Will
On Thu, 10 Dec 2020 10:24:36 -0600, Suravee Suthikulpanit wrote:
> Currently, macros related to the interrupt remapping table length are
> defined separately. This has resulted in an oversight in which one of
> the macros were missed when changing the length. To prevent this,
> redefine the macros
On Fri, Dec 11, 2020 at 09:49:28AM +, Marc Zyngier wrote:
> On 2020-12-11 08:01, Yanan Wang wrote:
> > @@ -461,25 +462,56 @@ static int stage2_map_set_prot_attr(enum
> > kvm_pgtable_prot prot,
> > return 0;
> > }
> >
> > +static bool stage2_set_valid_leaf_pte_pre(u64 addr, u32 level,
> >
Hi Yanan,
On Fri, Dec 11, 2020 at 04:01:15PM +0800, Yanan Wang wrote:
> In dirty-logging, or dirty-logging-stopped time, even normal running
> time of a guest configed with huge mappings and numbers of vCPUs,
> translation faults by different vCPUs on the same GPA could occur
> successively
_flags(ipi_base + i, IRQ_HIDDEN);
> +
> + /* The recheduling IPI is special... */
> + if (i == IPI_RESCHEDULE)
> + __irq_modify_status(ipi_base + i, 0, IRQ_RAW, ~0);
Acked-by: Will Deacon
Although this part isn't the controversial bit :)
Will
Hi Marc,
On Tue, Nov 24, 2020 at 02:14:45PM +, Marc Zyngier wrote:
> Some interrupts (such as the rescheduling IPI) rely on not going through
> the irq_enter()/irq_exit() calls. To distinguish such interrupts, add
> a new IRQ flag that allows the low-level handling code to sidestep the
>
ether: managing both the
'tlb_flush_pending' flag on the 'mm_struct' and explicit TLB
invalidation for the sort-dirty path, much like mprotect() does already.
Signed-off-by: Will Deacon
---
fs/proc/task_mmu.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/proc/
+rh74kzedmo_f1d35xnz...@mail.gmail.com
Signed-off-by: Will Deacon
---
arch/ia64/include/asm/tlb.h | 2 +-
arch/x86/kernel/ldt.c | 2 +-
fs/exec.c | 2 +-
include/linux/mm_types.h| 3 +--
mm/hugetlb.c| 16 +---
mm/madvise.c| 6 +++---
mm
a range starting at TASK_SIZE. Such a large range
will be converted into a 'fullmm' flush by the low-level invalidation
code, so change the caller to invoke tlb_gather_mmu_fullmm() directly.
Cc: Thomas Gleixner
Signed-off-by: Will Deacon
---
arch/x86/kernel/ldt.c | 8 +++-
1 file changed, 7
If __tlb_remove_tlb_entry() is not defined by the architecture then
we provide an empty definition in asm-generic/tlb.h.
Remove the redundant empty definitions for sparc64 and x86.
Suggested-by: Peter Zijlstra
Signed-off-by: Will Deacon
---
arch/sparc/include/asm/tlb_64.h | 1 -
arch/x86
reclaimed. Although this behaviour is documented in
asm-generic/tlb.h, it's subtle and easily missed.
Introduce tlb_gather_mmu_fullmm() to make it clearer that this is for the
entire mm and WARN() if tlb_gather_mmu() is called with the 'fullmm'
address range.
Signed-off-by: Will Deacon
---
include
Signed-off-by: Will Deacon
---
arch/ia64/include/asm/tlb.h | 2 +-
arch/x86/kernel/ldt.c | 2 +-
fs/exec.c | 2 +-
include/linux/mm_types.h| 3 +--
mm/hugetlb.c| 2 +-
mm/madvise.c| 6 +++---
mm/memory.c | 4 ++--
Zijlstra
Cc: Thomas Gleixner
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: Mohamed Alzayat
Cc: "Aneesh Kumar K.V"
Cc: linux...@kvack.org
--->8
Will Deacon (6):
mm: proc: Invalidate TLB after clearing soft-dirty page state
tlb: mmu_gather: Remove unused start/end arguments from
t
On Wed, Dec 09, 2020 at 10:07:46AM -0800, Linus Torvalds wrote:
> On Wed, Dec 9, 2020 at 6:12 AM Will Deacon wrote:
> >
> > Please pull this one-liner AMD IOMMU fix for 5.10. It's actually a fix
> > for a fix, where the size of the interrupt remapping table was increa
On Wed, Dec 09, 2020 at 06:35:09PM +, Catalin Marinas wrote:
> On Wed, Dec 09, 2020 at 04:39:50PM +, Will Deacon wrote:
> > diff --git a/arch/arm64/include/asm/cpufeature.h
> > b/arch/arm64/include/asm/cpufeature.h
> > index da250e4741bd..3424f5881390 100644
> &g
On Wed, Dec 09, 2020 at 09:58:12AM -0800, Linus Torvalds wrote:
> On Wed, Dec 9, 2020 at 8:40 AM Will Deacon wrote:
> >
> > @@ -3978,8 +3994,17 @@ static vm_fault_t do_fault_around(struct vm_fault
> > *vmf)
> >
> > /* check if the page fault is solve
for the initial state of prefaulted PTEs,
introduce arch_wants_old_faultaround_pte(), which allows an architecture
to opt-in to 'old' prefaulted PTEs at runtime based on whatever criteria
it may have.
Cc: Jan Kara
Cc: Minchan Kim
Cc: Andrew Morton
Cc: Kirill A. Shutemov
Cc: Linus Torvalds
Reported-by: V
/msg143831.html
[2] 315d09bf30c2 ("Revert "mm: make faultaround produce old ptes"")
Cc: Catalin Marinas
Cc: Jan Kara
Cc: Minchan Kim
Cc: Andrew Morton
Cc: Kirill A. Shutemov
Cc: Linus Torvalds
Cc: Vinayak Menon
Cc: Andrew Morton
Cc:
--->8
Will Deacon (2):
mm: Allow a
on MIDR matching if necessary.
Cc: Catalin Marinas
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/cpufeature.h | 12
arch/arm64/include/asm/pgtable.h| 8 +++-
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/cpufeature.h
b/arch/arm64
Hi Linus,
Please pull this one-liner AMD IOMMU fix for 5.10. It's actually a fix
for a fix, where the size of the interrupt remapping table was increased
but a related constant for the size of the interrupt table was forgotten.
Cheers,
Will
--->8
The following changes since commit
n from every corner and very few of
> them have Acks. I think many (but not all) of the commits to this
> file go through trees that feed into the SoC tree (Arnd and Olof)
> because those maintainers care about enabling drivers for boards that
> they're supporting, but changes come fro
On Mon, 7 Dec 2020 19:57:58 +0800, Keqian Zhu wrote:
> Although handling a mapping request with no permissions is a
> trivial no-op, defer the early return until after the size/range
> checks so that we are consistent with other mapping requests.
Applied to arm64 (for-next/iommu/misc), thanks!
On Fri, 4 Dec 2020 02:34:49 +0800, John Garry wrote:
> This series contains some minor tidy-ups by deleting an unreferenced
> function and unexporting some functions, highlighted by:
>
On Mon, 7 Dec 2020 20:01:50 +0800, Kunkun Jiang wrote:
> Knowing from the code, the macro "iopte_type(pte, l)" doesn't use the
> parameter "l" (level). So we'd better to remove it.
Applied to arm64 (for-next/iommu/misc), thanks!
[1/1] iommu/io-pgtalbe-arm: Remove "iopte_type(pte, l)" extra
The scheduler now knows enough about these braindead systems to place
32-bit tasks accordingly, so throw out the safety checks and allow the
ret-to-user path to avoid do_notify_resume() if there is nothing to do.
Signed-off-by: Will Deacon
---
arch/arm64/kernel/process.c | 14
in cases where the affinity is forced.
Reviewed-by: Quentin Perret
Signed-off-by: Will Deacon
---
kernel/sched/core.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 58474569a2ea..92ac3e53f50a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched
for compat tasks and forced migration due to a hotplug event will
hang if no 32-bit CPUs are available.
On detecting a mismatch, prevent offlining of either the mismatching CPU
if it is 32-bit capable, or find the first active 32-bit capable CPU
otherwise.
Signed-off-by: Will Deacon
---
arch/arm64
for 32-bit applications, introduce
force_compatible_cpus_allowed_ptr(), which restricts the affinity mask
for a task to contain only compatible CPUs.
Reviewed-by: Quentin Perret
Signed-off-by: Will Deacon
---
include/linux/sched.h | 1 +
kernel/sched/core.c | 100
Allow systems with mismatched 32-bit support at EL0 to run 32-bit
applications based on a new kernel parameter.
Signed-off-by: Will Deacon
---
Documentation/admin-guide/kernel-parameters.txt | 8
arch/arm64/kernel/cpufeature.c | 7 +++
2 files changed, 15
Provide an implementation of task_cpu_possible_mask() so that we can
prevent 64-bit-only cores being added to the 'cpus_mask' for compat
tasks on systems with mismatched 32-bit support at EL0,
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/mmu_context.h | 13 +
1 file changed
When exec'ing a 32-bit task on a system with mismatched support for
32-bit EL0, try to ensure that it starts life on a CPU that can actually
run it.
Reviewed-by: Quentin Perret
Signed-off-by: Will Deacon
---
arch/arm64/kernel/process.c | 14 +-
1 file changed, 13 insertions(+), 1
lly overriding the affinity mask for a
task which requires migration to a compatible CPU.
Cc: Li Zefan
Cc: Tejun Heo
Cc: Johannes Weiner
Signed-off-by: Will Deacon
---
include/linux/cpuset.h | 3 ++-
kernel/cgroup/cpuset.c | 33 +++--
2 files changed, 21 inserti
select_fallback_rq() to figure out the mask by itself.
Cc: Li Zefan
Cc: Tejun Heo
Cc: Johannes Weiner
Reviewed-by: Quentin Perret
Signed-off-by: Will Deacon
---
kernel/cgroup/cpuset.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup
.
Reviewed-by: Quentin Perret
Signed-off-by: Will Deacon
---
include/linux/mmu_context.h | 8
kernel/sched/core.c | 8 +---
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/include/linux/mmu_context.h b/include/linux/mmu_context.h
index 03dee12d2b61..bc4ac3c525e6 100644
Since 32-bit applications will be killed if they are caught trying to
execute on a 64-bit-only CPU in a mismatched system, advertise the set
of 32-bit capable CPUs to userspace in sysfs.
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Will Deacon
---
.../ABI/testing/sysfs-devices-system-cpu
.
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/cpucaps.h| 3 +-
arch/arm64/include/asm/cpufeature.h | 8 ++-
arch/arm64/kernel/cpufeature.c | 106 ++--
3 files changed, 108 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/include/asm/cpucaps.h b
If a vCPU is caught running 32-bit code on a system with mismatched
support at EL0, then we should kill it.
Acked-by: Marc Zyngier
Signed-off-by: Will Deacon
---
arch/arm64/kvm/arm.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/arm.c b/arch
-by: Will Deacon
---
arch/arm64/kernel/process.c | 19 ++-
arch/arm64/kernel/signal.c | 26 ++
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index ed919f633ed8..9a2532d848f0 100644
In preparation for late initialisation of the "sanitised" AArch32 register
state, move the AArch32 registers out of 'struct cpuinfo' and into their
own struct definition.
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/cpu.h | 44 +++--
arch/arm64/kernel/cp
Zyngier
Cc: Greg Kroah-Hartman
Cc: Peter Zijlstra
Cc: Morten Rasmussen
Cc: Qais Yousef
Cc: Suren Baghdasaryan
Cc: Quentin Perret
Cc: Tejun Heo
Cc: Li Zefan
Cc: Johannes Weiner
Cc: Ingo Molnar
Cc: Juri Lelli
Cc: Vincent Guittot
Cc: kernel-t...@android.com
--->8
Will Deacon (15):
ar
On Mon, Dec 07, 2020 at 05:59:16PM -0800, Yury Norov wrote:
> (CC: Alexey Klimov)
>
> On Mon, Dec 7, 2020 at 3:25 AM Will Deacon wrote:
> >
> > On Sat, Dec 05, 2020 at 08:54:06AM -0800, Yury Norov wrote:
> > > ARM64 doesn't implement find_first_{zero}_bit in arch
On Mon, Dec 07, 2020 at 06:19:31PM +, Catalin Marinas wrote:
> On Fri, Dec 04, 2020 at 09:59:10AM +, Will Deacon wrote:
> > On Thu, Dec 03, 2020 at 11:32:11PM +0100, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > The __system_mat
On Mon, Dec 07, 2020 at 02:11:20PM +, Quentin Perret wrote:
> On Monday 07 Dec 2020 at 13:40:52 (+), Will Deacon wrote:
> > Why not use the RESERVEDMEM_OF_DECLARE() interface for the hypervisor
> > memory? That way, the hypervisor memory can either be statica
Hi Quentin,
On Tue, Nov 17, 2020 at 06:15:56PM +, Quentin Perret wrote:
> When memory protection is enabled, the Hyp code needs the ability to
> create and manage its own page-table. To do so, introduce a new set of
> hypercalls to initialize Hyp memory protection.
>
> During the init hcall,
On Mon, Dec 07, 2020 at 12:01:09PM +, Robin Murphy wrote:
> On 2020-12-05 08:29, Keqian Zhu wrote:
> > ... then we have more chance to detect wrong code logic.
>
> I don't follow that justification - it's still the same check with the same
> outcome, so how does moving it have any effect on
On Mon, Dec 07, 2020 at 07:23:29PM +0800, Tian Tao wrote:
> Use devm_add_action_or_reset to avoid the situation where the release
> function is not called when devm_add_action returns an error.
>
> Signed-off-by: Tian Tao
>
> v2:
> check the return value about evm_add_action_or_reset()
> ---
>
On Sat, Dec 05, 2020 at 08:54:06AM -0800, Yury Norov wrote:
> ARM64 doesn't implement find_first_{zero}_bit in arch code and doesn't
> enable it in config. It leads to using find_next_bit() which is less
> efficient:
[...]
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index
On Mon, Dec 07, 2020 at 11:05:45AM +, Mark Rutland wrote:
> On Mon, Dec 07, 2020 at 10:20:03AM +, Will Deacon wrote:
> > On Fri, Dec 04, 2020 at 06:01:52PM +, Quentin Perret wrote:
> > > On Thursday 03 Dec 2020 at 12:57:33 (+), Fuad Tabba wrote:
> > >
On Mon, 7 Dec 2020 17:35:53 +0800, Yong Wu wrote:
> Currently direct_mapping always use the smallest pgsize which is SZ_4K
> normally to mapping. This is unnecessary. we could gather the size, and
> call iommu_map then, iommu_map could decide how to map better with the
> just right pgsize.
>
>
On Mon, 7 Dec 2020 03:19:20 -0600, Suravee Suthikulpanit wrote:
> According to the AMD IOMMU spec, the commit 73db2fc595f3
> ("iommu/amd: Increase interrupt remapping table limit to 512 entries")
> also requires the interrupt table length (IntTabLen) to be set to 9
> (power of 2) in the device
On Sat, Dec 05, 2020 at 04:29:57PM +0800, Keqian Zhu wrote:
> ... then we have more chance to detect wrong code logic.
This could do with being a bit more explicit. Something like:
Although handling a mapping request with no permissions is a
trivial no-op, defer the early return
171 | static __always_inline __u16 __swab16p(const __u16 *p)
> |^~~
>
> [1]: https://lkml.org/lkml/2018/9/13/78
> Cc: Mathieu Poirier
> Cc: Suzuki K Poulose
> Cc: Mike Leach
> Cc: Leo Yan
> Cc: John Garry
> Cc: Will Deacon
> Cc: Peter Zijls
On Mon, Dec 07, 2020 at 04:14:04PM +0800, Kunkun Jiang wrote:
> Knowing from the code, the macro "iopte_type(pte, l)" doesn't use the
> parameter "l" (level). So we'd better to remove it.
>
> Fixes: e1d3c0fd701df(iommu: add ARM LPAE page table allocator)
> Signed-off-by: Kunkun Jiang
> ---
>
On Fri, Dec 04, 2020 at 06:01:52PM +, Quentin Perret wrote:
> On Thursday 03 Dec 2020 at 12:57:33 (+), Fuad Tabba wrote:
>
> > > +int hyp_create_idmap(void);
> > > +int hyp_map_vectors(void);
> > > +int hyp_back_vmemmap(phys_addr_t phys, unsigned long size, phys_addr_t
> > > back);
> > >
On Fri, Dec 04, 2020 at 09:44:43AM +0800, Wei Li wrote:
> For the memory hole, sparse memory model that define SPARSEMEM_VMEMMAP
> do not free the reserved memory for the page map, decrease the section
> size can reduce the waste of reserved memory.
>
> Signed-off-by: Wei Li
> Signed-off-by:
ror,-Wunused-function]
>
> Move it into that #ifdef section.
>
> Fixes: 7cf283c7bd62 ("arm64: uaccess: remove redundant PAN toggling")
> Signed-off-by: Arnd Bergmann
> ---
> arch/arm64/kernel/cpufeature.c | 36 --
> 1 file changed, 17 ins
On Thu, Dec 03, 2020 at 02:32:13PM -0800, Nick Desaulniers wrote:
> On Thu, Dec 3, 2020 at 10:23 AM Will Deacon wrote:
> > On Thu, Dec 03, 2020 at 09:07:30AM -0800, Sami Tolvanen wrote:
> > > Without LLVM_IAS=1, Clang uses two different assemblers when LTO is
> > >
Hi Arnd,
On Thu, Dec 03, 2020 at 11:27:26PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> When CONFIG_HW_PERF_EVENTS is disabled, the hardware lockup detector
> fails to link:
>
> ld.lld: error: undefined symbol: hw_nmi_get_sample_period
> >>> referenced by watchdog_hld.c
> >>>
On Thu, Dec 03, 2020 at 09:07:30AM -0800, Sami Tolvanen wrote:
> On Thu, Dec 3, 2020 at 3:26 AM Will Deacon wrote:
> > On Tue, Dec 01, 2020 at 01:36:51PM -0800, Sami Tolvanen wrote:
> > > This patch series adds support for building the kernel with Clang's
> > >
Hi Sami,
On Tue, Dec 01, 2020 at 01:36:51PM -0800, Sami Tolvanen wrote:
> This patch series adds support for building the kernel with Clang's
> Link Time Optimization (LTO). In addition to performance, the primary
> motivation for LTO is to allow Clang's Control-Flow Integrity (CFI)
> to be used
Hi,
On Thu, Dec 03, 2020 at 04:42:20PM +0800, liwei (GF) wrote:
> On 2020/11/30 18:06, Will Deacon wrote:
> > On Fri, Nov 27, 2020 at 02:03:22PM +0800, Wei Li wrote:
> >> /* Perf callbacks */
> >> static int arm_spe_pmu_event_init(struct perf_event *event)
&g
On Wed, Dec 02, 2020 at 01:52:16PM +, Qais Yousef wrote:
> On 12/01/20 16:56, Will Deacon wrote:
> > On Fri, Nov 27, 2020 at 01:12:17PM +, Qais Yousef wrote:
> > > On 11/24/20 15:50, Will Deacon wrote:
> > > > Scheduling a 32-bit application on a
On Wed, Dec 02, 2020 at 12:59:52PM +, Qais Yousef wrote:
> On 12/01/20 22:13, Will Deacon wrote:
> > On Fri, Nov 27, 2020 at 01:41:22PM +, Qais Yousef wrote:
> > > On 11/24/20 15:50, Will Deacon wrote:
> > > > diff --git a/arch/arm64/kernel/cpufeature.
On Wed, Dec 02, 2020 at 08:18:03AM +, Marc Zyngier wrote:
> On 2020-12-01 16:57, Will Deacon wrote:
> > On Fri, Nov 27, 2020 at 06:16:35PM +, Marc Zyngier wrote:
> > > On 2020-11-27 17:24, Quentin Perret wrote:
> > > > On Friday 27 Nov 2020 at 17:14:
Hi Linus,
I'm sad to say that we've got an unusually large arm64 fixes pull for
-rc7 which addresses numerous significant instrumentation issues with
our entry code. Without these patches, lockdep is hopelessly unreliable
in some configurations [1,2] and syzkaller is therefore not a lot of use
On Tue, Dec 01, 2020 at 12:10:40PM +0800, Leo Yan wrote:
> On Mon, Nov 30, 2020 at 04:46:51PM +, Will Deacon wrote:
> > On Mon, Nov 30, 2020 at 06:24:54PM +0200, James Clark wrote:
> > > Enable PID_IN_CONTEXTIDR by default when Arm SPE is enabled.
> > > This flag
On Tue, Dec 01, 2020 at 01:50:38PM -0800, Andy Lutomirski wrote:
> On Tue, Dec 1, 2020 at 1:28 PM Will Deacon wrote:
> >
> > On Mon, Nov 30, 2020 at 10:31:51AM -0800, Andy Lutomirski wrote:
> > > other arch folk: there's some background here:
> > >
On Tue, Dec 01, 2020 at 03:56:49PM +, Quentin Perret wrote:
> On Tuesday 01 Dec 2020 at 14:11:21 (+), Qais Yousef wrote:
> > For cpusets, if hotunplug results in an empty cpuset, then all tasks are
> > moved
> > to the nearest ancestor if I read the code correctly. In our case, only
> >
On Fri, Nov 27, 2020 at 01:41:22PM +, Qais Yousef wrote:
> On 11/24/20 15:50, Will Deacon wrote:
> > If we want to support 32-bit applications, then when we identify a CPU
> > with mismatched 32-bit EL0 support we must ensure that we will always
> > have an active 32-bi
On Tue, 17 Nov 2020 18:25:30 +0800, John Garry wrote:
> This series contains a patch to solve the longterm IOVA issue which
> leizhen originally tried to address at [0].
>
> A sieved kernel log is at the following, showing periodic dumps of IOVA
> sizes, per CPU and per depot bin, per IOVA size
On Mon, Nov 30, 2020 at 10:31:51AM -0800, Andy Lutomirski wrote:
> other arch folk: there's some background here:
>
> https://lkml.kernel.org/r/calcetrvxube8lfnn-qs+dzroqaiw+sfug1j047ybyv31sat...@mail.gmail.com
>
> On Sun, Nov 29, 2020 at 12:16 PM Andy Lutomirski wrote:
> >
> > On Sat, Nov 28,
On Tue, Dec 01, 2020 at 03:35:02PM +, John Garry wrote:
> On 17/11/2020 10:25, John Garry wrote:
> Is there any chance that we can get these picked up for 5.11? We've seen
> this issue solved here for a long time.
>
> Or, @Robin, let me know if not happy with this since v1.
>
> BTW, patch #4
will causes
> guest errors such as infinite-loop (soft lockup will occur in result),
> because of
> calling the inappropriate fault handler. So, a solution that can strictly
> distinguish conditions is introduced in PATCH 3/3.
For the series:
Acked-by: Will Deacon
Thanks for reporting these, helping me to understand the issues and then
spinning a v2 so promptly.
Will
On Wed, Dec 02, 2020 at 01:20:33AM +0800, wangyanan (Y) wrote:
> On 2020/12/1 22:35, Marc Zyngier wrote:
>
> > Hi Yanan,
> >
> > On 2020-12-01 14:11, wangyanan (Y) wrote:
> > > On 2020/12/1 21:46, Will Deacon wrote:
> > > > On Tue, Dec 01,
On Wed, Dec 02, 2020 at 01:19:35AM +0800, wangyanan (Y) wrote:
> On 2020/12/1 22:16, Will Deacon wrote:
> > On Tue, Dec 01, 2020 at 03:21:23PM +0800, wangyanan (Y) wrote:
> > > On 2020/11/30 21:21, Will Deacon wrote:
> > > > On Mon, Nov 30, 2020 at 08:1
On Fri, Nov 27, 2020 at 06:16:35PM +, Marc Zyngier wrote:
> On 2020-11-27 17:24, Quentin Perret wrote:
> > On Friday 27 Nov 2020 at 17:14:11 (+), Marc Zyngier wrote:
>
> [...]
>
> > > Yeah, the sanitized read feels better, if only because that is
> > > what we are going to read in all
On Fri, Nov 27, 2020 at 01:19:16PM +, Qais Yousef wrote:
> On 11/24/20 15:50, Will Deacon wrote:
>
> [...]
>
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index d2003a7d5ab5..818c8f7bdf2a 100644
> > --- a/kernel/sched/core.c
> > +++ b
On Fri, Nov 27, 2020 at 01:17:59PM +, Qais Yousef wrote:
> On 11/24/20 15:50, Will Deacon wrote:
> > Allow systems with mismatched 32-bit support at EL0 to run 32-bit
> > applications based on a new kernel parameter.
> >
> > Signed-off-by: Will Deacon
> > -
On Fri, Nov 27, 2020 at 01:12:17PM +, Qais Yousef wrote:
> On 11/24/20 15:50, Will Deacon wrote:
> > Scheduling a 32-bit application on a 64-bit-only CPU is a bad idea.
> >
> > Ensure that 32-bit applications always take the slow-path when returning
> &g
On Fri, Nov 27, 2020 at 01:09:41PM +, Qais Yousef wrote:
> On 11/24/20 15:50, Will Deacon wrote:
> > When confronted with a mixture of CPUs, some of which support 32-bit
>
> Confronted made me laugh, well chosen word! :D
>
> For some reason made me think of thi
On Fri, Nov 27, 2020 at 01:23:06PM +, Qais Yousef wrote:
> On 11/24/20 15:50, Will Deacon wrote:
> > When exec'ing a 32-bit task on a system with mismatched support for
> > 32-bit EL0, try to ensure that it starts life on a CPU that can actually
> > run it.
> >
>
On Tue, Dec 01, 2020 at 02:05:03PM +, Marc Zyngier wrote:
> On 2020-12-01 13:46, Will Deacon wrote:
> > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> > index 0271b4a3b9fe..12526d8c7ae4 100644
> > --- a/arch/arm64/kvm/hyp/pgtable.c
> &g
On Tue, Dec 01, 2020 at 03:21:23PM +0800, wangyanan (Y) wrote:
> On 2020/11/30 21:21, Will Deacon wrote:
> > On Mon, Nov 30, 2020 at 08:18:45PM +0800, Yanan Wang wrote:
> > > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> > > index 0271b4
On Tue, Dec 01, 2020 at 10:30:41AM +0800, wangyanan (Y) wrote:
> On 2020/12/1 0:01, Will Deacon wrote:
> > On Mon, Nov 30, 2020 at 11:24:19PM +0800, wangyanan (Y) wrote:
> > > On 2020/11/30 21:34, Will Deacon wrote:
> > > > On Mon, Nov 30, 2020 at 08:18:46PM +0800, Ya
On Tue, Dec 01, 2020 at 01:52:46PM +0100, Peter Zijlstra wrote:
> On Tue, Dec 01, 2020 at 12:56:27PM +0100, Sven Schnelle wrote:
> > Peter Zijlstra writes:
> > > On Mon, Nov 30, 2020 at 01:00:03PM -0800, Guenter Roeck wrote:
> > >> On Fri, Nov 20, 2020 at 12:41:46PM +0100, Peter Zijlstra wrote:
>
On Mon, 30 Nov 2020 15:34:40 -0800, Sami Tolvanen wrote:
> As discussed a few months ago [1][2], virtually mapped shadow call stacks
> are better for safety and robustness. This series dusts off the VMAP
> option from the original SCS patch series and switches the kernel to use
> virtually mapped
On Tue, Dec 01, 2020 at 10:18:19AM +, Will Deacon wrote:
> On Mon, Nov 30, 2020 at 01:13:07PM -0800, Sami Tolvanen wrote:
> > On Mon, Nov 30, 2020 at 3:49 AM Will Deacon wrote:
> > > On Tue, Nov 24, 2020 at 11:59:40AM -0800, Sami Tolvanen wrote:
> > > >
On Mon, Nov 30, 2020 at 01:13:07PM -0800, Sami Tolvanen wrote:
> On Mon, Nov 30, 2020 at 3:49 AM Will Deacon wrote:
> >
> > On Tue, Nov 24, 2020 at 11:59:40AM -0800, Sami Tolvanen wrote:
> > > Use scs_alloc() to allocate also IRQ and SDEI shadow stacks instead of
> >
On Tue, Dec 01, 2020 at 01:48:30AM +0800, Rongwei Wang wrote:
> MSR ARM driver aims to provide interfacs for user to read or write data to all
> system registers. Its functions is same as MSR driver (x86 platform). It
> mainly
> depends on kprobe and undef exception to read or write system
On Mon, 30 Nov 2020 17:07:09 +, Vincenzo Frascino wrote:
> UL in the definition of SYS_TFSR_EL1_TF1 was misspelled causing
> compilation issues when trying to implement in kernel MTE async
> mode.
>
> Fix the macro correcting the typo.
>
> Note: MTE async mode will be introduced with a
N_CONTEXTIDR, but SPE itself is optional and not enabled by
> default so the impact is minimised.
>
> Cc: Will Deacon
> Cc: Mark Rutland
> Cc: Al Grant
> Cc: Leo Yan
> Cc: John Garry
> Cc: Suzuki K Poulose
> Signed-off-by: James Clark
> ---
> drivers/perf/Kco
Hi,
Cheers for the quick reply. See below for more questions...
On Mon, Nov 30, 2020 at 11:24:19PM +0800, wangyanan (Y) wrote:
> On 2020/11/30 21:34, Will Deacon wrote:
> > On Mon, Nov 30, 2020 at 08:18:46PM +0800, Yanan Wang wrote:
> > > diff --git a/arch/arm64/kvm/hyp/pgta
On Mon, Nov 30, 2020 at 08:18:47PM +0800, Yanan Wang wrote:
> If we get a FSC_PERM fault, just using (logging_active && writable) to
> determine
> calling kvm_pgtable_stage2_map(). There will be two more cases we should
> consider.
>
> (1) After logging_active is configged back to false from
On Mon, Nov 30, 2020 at 08:18:46PM +0800, Yanan Wang wrote:
> In dirty logging case(logging_active == True), we need to collapse a block
> entry into a table if necessary. After dirty logging is canceled, when merging
> tables back into a block entry, we should not only free the non-huge page
>
On Mon, Nov 30, 2020 at 08:18:45PM +0800, Yanan Wang wrote:
> When installing a new leaf pte onto an invalid ptep, we need to
> get_page(ptep).
> When just updating a valid leaf ptep, we shouldn't get_page(ptep).
> Incorrect page_count of translation tables might lead to memory leak,
> when
Hi Sami,
On Wed, Nov 18, 2020 at 02:07:14PM -0800, Sami Tolvanen wrote:
> This patch series adds support for building the kernel with Clang's
> Link Time Optimization (LTO). In addition to performance, the primary
> motivation for LTO is to allow Clang's Control-Flow Integrity (CFI) to
> be used
gt; select ARCH_SUPPORTS_SHADOW_CALL_STACK if CC_HAVE_SHADOW_CALL_STACK
> + select ARCH_SUPPORTS_LTO_CLANG
> + select ARCH_SUPPORTS_THINLTO
Acked-by: Will Deacon
Will
TH_REGS
I don't really understand why this is in the arch header file, rather
than have the core code check for "fpatchable-function-entry=2" and expose
a CC_HAS_PATCHABLE_FUNCTION_ENTRY, but in the interest of making some
progress on this series:
Acked-by: Will Deacon
Will
501 - 600 of 10389 matches
Mail list logo
