On Thu, Nov 19, 2020 at 02:30:12PM +, Quentin Perret wrote:
> On Thursday 19 Nov 2020 at 11:07:24 (+), Will Deacon wrote:
> > Yeah, the cpuset code ignores the return value of set_cpus_allowed_ptr() in
> > update_tasks_cpumask() so the failure won't be propagated, b
On Thu, Nov 19, 2020 at 02:54:32PM +, Valentin Schneider wrote:
>
> On 19/11/20 13:13, Will Deacon wrote:
> > On Thu, Nov 19, 2020 at 11:27:55AM +, Valentin Schneider wrote:
> >>
> >> On 19/11/20 11:05, Will Deacon wrote:
> >> > On Thu, Nov 19
On Thu, Nov 19, 2020 at 05:11:27PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 13, 2020 at 09:37:05AM +, 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 support the 32-b
On Thu, Nov 19, 2020 at 05:19:56PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 19, 2020 at 11:06:04AM +, Will Deacon wrote:
> > On Thu, Nov 19, 2020 at 09:24:07AM +, Quentin Perret wrote:
> > > On Friday 13 Nov 2020 at 09:37:13 (+), Will Deacon wrote:
> > > &g
On Thu, Nov 19, 2020 at 05:14:48PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 13, 2020 at 09:37:13AM +, 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 a
On Thu, Nov 19, 2020 at 12:47:34PM +, Valentin Schneider wrote:
>
> On 13/11/20 09:37, Will Deacon wrote:
> > Asymmetric systems may not offer the same level of userspace ISA support
> > across all CPUs, meaning that some applications cannot be executed by
> > some CPU
Hi Valentin,
Thanks for the review.
On Thu, Nov 19, 2020 at 11:27:41AM +, Valentin Schneider wrote:
>
> On 13/11/20 09:37, Will Deacon wrote:
> > +const struct cpumask *system_32bit_el0_cpumask(void)
> > +{
> > + if (!system_supports_32bit_el0())
> > +
On Thu, Nov 19, 2020 at 11:27:55AM +, Valentin Schneider wrote:
>
> On 19/11/20 11:05, Will Deacon wrote:
> > On Thu, Nov 19, 2020 at 09:18:20AM +, Quentin Perret wrote:
> >> > @@ -1937,20 +1931,69 @@ static int __set_cpus_allowed_ptr(struct
> >> > tas
On Thu, Oct 22, 2020 at 01:23:55PM -0700, Sami Tolvanen wrote:
> Use scs_alloc() to allocate also IRQ and SDEI shadow stacks instead of
> using statically allocated stacks.
>
> Signed-off-by: Sami Tolvanen
> ---
> arch/arm64/include/asm/scs.h | 21 ++-
> arch/arm64/kernel/entry.S|
Hi Sami,
On Thu, Oct 22, 2020 at 01:23:54PM -0700, Sami Tolvanen wrote:
> The kernel currently uses kmem_cache to allocate shadow call stacks,
> which means an overflow may not be immediately detected and can
> potentially result in another task's shadow stack to be overwritten.
>
> This change
On Thu, Nov 19, 2020 at 09:47:44AM +, Quentin Perret wrote:
> On Friday 13 Nov 2020 at 09:37:16 (+), Will Deacon wrote:
> > Reject explicit requests to change the affinity mask of a task via
> > set_cpus_allowed_ptr() if the requested mask is not a subset of the
&g
On Thu, Nov 19, 2020 at 09:38:50AM +, Quentin Perret wrote:
> On Friday 13 Nov 2020 at 09:37:15 (+), Will Deacon wrote:
> > Asymmetric systems may not offer the same level of userspace ISA support
> > across all CPUs, meaning that some applications cannot be executed b
On Thu, Nov 19, 2020 at 09:29:22AM +, Quentin Perret wrote:
> On Friday 13 Nov 2020 at 09:37:14 (+), Will Deacon wrote:
> > If the scheduler cannot find an allowed CPU for a task,
> > cpuset_cpus_allowed_fallback() will widen the affinity to cpu_possible_mask
> > i
On Thu, Nov 19, 2020 at 09:24:07AM +, Quentin Perret wrote:
> On Friday 13 Nov 2020 at 09:37:13 (+), 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 a
Hi Quentin,
Thanks for having a look.
On Thu, Nov 19, 2020 at 09:18:20AM +, Quentin Perret wrote:
> On Friday 13 Nov 2020 at 09:37:12 (+), Will Deacon wrote:
> > -static int __set_cpus_allowed_ptr(struct task_struct *p,
> > - const struct cp
On Thu, 19 Nov 2020 13:51:19 +0800, Lu Baolu wrote:
> Fix the compile error below (CONFIG_PCI_ATS not set):
>
> drivers/iommu/intel/dmar.c: In function ‘vf_inherit_msi_domain’:
> drivers/iommu/intel/dmar.c:338:59: error: ‘struct pci_dev’ has no member
> named ‘physfn’; did you mean ‘is_physfn’?
On Tue, Nov 17, 2020 at 02:47:54PM +0100, Thierry Reding wrote:
> On Mon, Nov 16, 2020 at 11:48:39AM -0800, John Stultz wrote:
> > On Mon, Nov 16, 2020 at 8:36 AM Will Deacon wrote:
> > > On Mon, Nov 16, 2020 at 04:59:36PM +0100, Thierry Reding wrote:
> > > > On F
from the EFI stub */
> + *(.init.bss)/* from the EFI stub */
Acked-by: Will Deacon
Will
On Thu, Nov 19, 2020 at 04:32:48PM +0800, Youling Tang wrote:
> On 11/19/2020 03:18 PM, Ard Biesheuvel wrote:
> > On Thu, 19 Nov 2020 at 02:45, Youling Tang wrote:
> > > We currently try to emit *.init.rodata.* twice, once in INIT_DATA, and
> > > once
> > > in the line immediately following it.
On Wed, Nov 18, 2020 at 07:38:54PM +0200, Mike Rapoport wrote:
> On Wed, Nov 18, 2020 at 07:33:14PM +1300, Barry Song wrote:
> > memmap should be an useful kernel parameter which has been supported by
> > x86, mips and xtensa.
>
> Why is this parameter should be useful for ARM64?
> My
On Tue, 10 Nov 2020 15:19:08 +0800, Zhenzhong Duan wrote:
> "intel_iommu=off" command line is used to disable iommu but iommu is force
> enabled in a tboot system for security reason.
>
> However for better performance on high speed network device, a new option
> "intel_iommu=tboot_noforce" is
On Wed, Nov 18, 2020 at 07:32:25AM +0800, Lu Baolu wrote:
> Please consider this patch for v5.10.
Cheers, I'll stick this onto a fixes branch momentarily.
Will
On Tue, Nov 17, 2020 at 05:35:24PM +, Catalin Marinas wrote:
> On Thu, Oct 22, 2020 at 01:23:53PM -0700, 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
On Wed, 30 Sep 2020 13:14:23 +0530, vji...@codeaurora.org wrote:
> When ever a new iova alloc request comes iova is always searched
> from the cached node and the nodes which are previous to cached
> node. So, even if there is free iova space available in the nodes
> which are next to the cached
On Sun, 15 Nov 2020 21:59:51 +0100, Lukas Bulwahn wrote:
> Commit 6ee1b77ba3ac ("iommu/vt-d: Add svm/sva invalidate function")
> introduced intel_iommu_sva_invalidate() when CONFIG_INTEL_IOMMU_SVM.
> This function uses the dedicated static variable inv_type_granu_table
> and functions
On Fri, 23 Oct 2020 06:48:27 +, Chen Jun wrote:
> iommu_sva_unbind_device has no return value.
>
> Remove the description of the return value of the function.
Applied to arm64 (for-next/iommu/misc), thanks!
[1/1] iommu: Modify the description of iommu_sva_unbind_device
On Wed, Oct 28, 2020 at 11:18:24PM +, Suravee Suthikulpanit wrote:
> AMD IOMMU requires 4k-aligned pages for the event log, the PPR log,
> and the completion wait write-back regions. However, when allocating
> the pages, they could be part of large mapping (e.g. 2M) page.
> This causes #PF due
Hey Suravee (it's been a while!),
On Fri, Nov 13, 2020 at 12:57:18PM +0700, Suravee Suthikulpanit wrote:
> Please ignore to include the V3. I am working on V4 to resubmit.
Please can you put me on CC for that?
Thanks,
Will
On Tue, Nov 17, 2020 at 07:11:28PM +0800, Yang Yingliang wrote:
> On 2020/11/17 17:40, Lu Baolu wrote:
> > On 2020/11/17 10:52, Yang Yingliang wrote:
> > > If iommu_group_get() failed, it need return error code
> > > in iommu_probe_device().
> > >
> > > Fixes: cf193888bfbd ("iommu: Move new
On Tue, Nov 10, 2020 at 01:56:57PM +, Will Deacon wrote:
> Please can you pull these Arm SMMU updates for 5.11 so that they can get
> into -next? I think Bjorn is keen to get a bunch of DT updates moving, so
> the sooner we can get this lot out there, the better. Summary i
On Tue, Nov 17, 2020 at 11:09:53AM +0100, Joerg Roedel wrote:
> Luckily Will Deacon volunteered to handle incoming IOMMU patches and
> send them upstream. So please Cc him on any patches that you want to
> have merged upstream for the next release and on important fixes for
> v5.10.
On Tue, Nov 17, 2020 at 10:46:21AM +0100, Peter Zijlstra wrote:
> On Tue, Nov 17, 2020 at 10:29:36AM +0100, Peter Zijlstra wrote:
> > On Tue, Nov 17, 2020 at 09:15:46AM +0000, Will Deacon wrote:
> > > On Tue, Nov 17, 2020 at 09:30:16AM +0100, Peter Zijlstra wrote:
> > >
quire(>on_cpu) &&
> //true
> + * deactivate_task()ttwu_queue_wakelist())
> + * p->on_rq = 0;p->sched_remote_wakeup = X;
> + *
> + * Guarantees all stores of 'current' are visible before
> + * ->sched_remote_wakeup gets used.
I'm still not sure this is particularly clear -- don't we want to highlight
that the store of p->on_rq is unordered wrt the update to
p->sched_contributes_to_load() in deactivate_task()?
I dislike bitfields with a passion, but the fix looks good:
Acked-by: Will Deacon
Now the million dollar question is why KCSAN hasn't run into this. Hrmph.
Will
[1] https://lore.kernel.org/r/20201116131102.GA29992@willie-the-truck
On Mon, Nov 16, 2020 at 05:24:44PM +, Mel Gorman wrote:
> On Mon, Nov 16, 2020 at 05:49:28PM +0100, Peter Zijlstra wrote:
> > > So while we might be able to avoid a smp_rmb() before the read of
> > > sched_contributes_to_load and rely on p->on_cpu ordering there,
> > > we may still need a
On Mon, Nov 16, 2020 at 04:59:36PM +0100, Thierry Reding wrote:
> On Fri, Nov 06, 2020 at 04:27:10AM +, John Stultz wrote:
> > diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> > index 7be48c1bec96d..6f431b73e617d 100644
> > --- a/drivers/firmware/qcom_scm.c
> > +++
rch_get_random_long_early())
> rv = random_get_entropy();
> mix_pool_bytes(r, , sizeof(rv));
Acked-by: Will Deacon
Will
On Mon, Nov 16, 2020 at 09:10:54AM +, Mel Gorman wrote:
> I got cc'd internal bug report filed against a 5.8 and 5.9 kernel
> that loadavg was "exploding" on arch64 on a machines acting as a build
> servers. It happened on at least two different arm64 variants. That setup
> is complex to
On Fri, Nov 13, 2020 at 03:02:13PM +0100, Thomas Gleixner wrote:
> irq_cpustat_t is exactly the same as the asm-generic one. Define
> ack_bad_irq so the generic header does not emit the generic version of it.
>
> Signed-off-by: Thomas Gleixner
> Cc: Catalin Marinas
> Cc: Will
On Fri, Nov 13, 2020 at 12:39:34PM +, Will Deacon wrote:
> Hi Linus,
>
> Please can you pull these arm64 fixes for -rc4? It's all fairly simple
> and there's a summary in the tag; Paul has reviewed the trivial RCU change.
>
> The main issue remaining at this stage is the
2XX gold/silver CPU cores to kpti safelist
arm64: proton-pack: Add KRYO2XX silver CPUs to spectre-v2 safe-list
arm64: cpu_errata: Apply Erratum 845719 to KRYO2XX Silver
Will Deacon (4):
arm64: errata: Fix handling of 1418040 with late CPU onlining
arm64: kexec_file: Fix spa
On Fri, 13 Nov 2020 13:00:14 +0530, Anshuman Khandual wrote:
> During memory hotplug process, the linear mapping should not be created for
> a given memory range if that would fall outside the maximum allowed linear
> range. Else it might cause memory corruption in the kernel virtual space.
>
>
On Thu, 5 Nov 2020 00:22:09 +0100, Konrad Dybcio wrote:
> This series adds Spectre mitigations and errata data for
> Qualcomm KRYO2XX Gold (big) and Silver (LITTLE) series of
> CPU cores, used for example in MSM8998 and SDM660-series SoCs.
>
> Konrad Dybcio (4):
> arm64: Add MIDR value for
select_fallback_rq() to figure out the mask by itself.
Cc: Li Zefan
Cc: Tejun Heo
Cc: Johannes Weiner
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/cpuset.c
index 57b5b5d0a5fd
-bit applications, introduce
a restrict_cpus_allowed_ptr(), which allows the current affinity mask
for a task to be shrunk to the intersection of a parameter mask.
Signed-off-by: Will Deacon
---
include/linux/sched.h | 1 +
kernel/sched/core.c | 73 ++-
2
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 | 12
arch
Provide an implementation of arch_cpu_allowed_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 | 12
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.
Signed-off-by: Will Deacon
---
arch/arm64/kernel/process.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch
in cases where the affinity is forced.
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 8df38ebfe769..13bdb2ae4d3f 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1877,6 +1877,7
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
-off-by: Will Deacon
---
kernel/sched/core.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 818c8f7bdf2a..8df38ebfe769 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1696,6 +1696,11 @@ void
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
-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 4784011cecac..1540ab0fbf23 100644
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
.
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/cpucaps.h| 2 +-
arch/arm64/include/asm/cpufeature.h | 8 ++-
arch/arm64/kernel/cpufeature.c | 106 ++--
3 files changed, 107 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/include/asm/cpucaps.h b
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 | 7 +++
arch/arm64/kernel/cpufeature.c | 7 +++
2 files changed, 14 insertions
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
Cc: Ingo Molnar
Cc: Juri Lelli
Cc: Vincent Guittot
Cc: kernel-t...@android.com
--->8
Will Deacon (14):
arm64: cpuinfo: Split AArch32 registers out into a separate struct
arm64: Allow mismatched 32-bit EL0 support
KVM: arm64: Kill 32-bit vCPUs on systems with mismatched EL0 support
ar
On Tue, Nov 10, 2020 at 10:51:46AM -0800, John Stultz wrote:
> On Tue, Nov 10, 2020 at 5:35 AM Linus Walleij
> wrote:
> > On Fri, Nov 6, 2020 at 5:27 AM John Stultz wrote:
> >
> > > Allow the qcom_scm driver to be loadable as a permenent module.
> > >
> ...
> > I applied this patch to the
On Thu, Nov 12, 2020 at 12:14:22AM +, Will McVicker wrote:
> Depending on your host nm version, the generated header
> `include/generated/vdso32-offsets.h` may have the bottom bit set for the
> thumb vdso offset addresses (as observed when using llvm-nm). This
> results in an additional +1 for
On Wed, Nov 11, 2020 at 11:32:42AM +0530, Sai Prakash Ranjan wrote:
> On 2020-11-10 17:48, Will Deacon wrote:
> > On Fri, Oct 30, 2020 at 02:53:08PM +0530, Sai Prakash Ranjan wrote:
> > > Add a quirk IO_PGTABLE_QUIRK_SYS_CACHE to override the
> > > attributes set in TC
On Wed, Nov 11, 2020 at 12:10:50PM +0530, Sai Prakash Ranjan wrote:
> On 2020-11-10 17:48, Will Deacon wrote:
> > On Fri, Oct 30, 2020 at 02:53:09PM +0530, Sai Prakash Ranjan wrote:
> > > Add iommu domain attribute for using system cache aka last level
> > > cache by cli
Hi Joerg,
Please can you pull these Arm SMMU updates for 5.11 so that they can get
into -next? I think Bjorn is keen to get a bunch of DT updates moving, so
the sooner we can get this lot out there, the better. Summary in the tag.
There are a few other patches kicking around on the list, so I
On Mon, 9 Nov 2020 11:47:24 -0700, Jordan Crouse wrote:
> This short series adds support for the adreno-smmu implementation of the
> arm-smmu driver and the device-tree bindings to turn on the implementation
> for the sm845 and sc7180 GPUs. These changes are the last ones needed to
> enable
>
On Fri, Oct 30, 2020 at 02:53:09PM +0530, Sai Prakash Ranjan wrote:
> Add iommu domain attribute for using system cache aka last level
> cache by client drivers like GPU to set right attributes for caching
> the hardware pagetables into the system cache.
>
> Signed-off-by: Sai Prakash Ranjan
>
On Fri, Oct 30, 2020 at 02:53:08PM +0530, Sai Prakash Ranjan wrote:
> Add a quirk IO_PGTABLE_QUIRK_SYS_CACHE to override the
> attributes set in TCR for the page table walker when
> using system cache.
>
> Signed-off-by: Sai Prakash Ranjan
> ---
> drivers/iommu/io-pgtable-arm.c | 7 ++-
>
c
> @@ -12,7 +12,7 @@
>
> static int arm_smmu_gr0_ns(int offset)
> {
> - switch(offset) {
> + switch (offset) {
> case ARM_SMMU_GR0_sCR0:
> case ARM_SMMU_GR0_sACR:
> case ARM_SMMU_GR0_sGFSR:
Whatever...
Acked-by: Will Deacon
Will
ommu/arm/arm-smmu/arm-smmu-impl.c | 9 +
> drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 21 -
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 -
> 3 files changed, 17 insertions(+), 14 deletions(-)
Acked-by: Will Deacon
Will
On Tue, Nov 03, 2020 at 12:17:17PM +, Will Deacon wrote:
> Hi all,
>
> These patches were previously posted as part of a larger series enabling
> architectures to override __READ_ONCE():
>
> v3: https://lore.kernel.org/lkml/20200710165203.31284-1-w...@kernel.org/
emmap_populate_basepages().
>
> Signed-off-by: Sudarshan Rajagopalan
> Reviewed-by: Gavin Shan
> Reviewed-by: Anshuman Khandual
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Anshuman Khandual
> Cc: Mark Rutland
> Cc: Logan Gunthorpe
> Cc: David Hildenbrand
Hi Linus,
Here's the weekly batch of fixes for arm64. Not an awful lot here, but
there are still a few unresolved issues relating to CPU hotplug, RCU and
IRQ tracing that I hope to queue fixes for next week.
In the meantime, there's a summary for this lot in the tag.
Cheers,
Will
--->8
The
On Tue, Nov 03, 2020 at 10:28:13AM -0700, Jordan Crouse wrote:
> On Mon, Nov 02, 2020 at 06:18:45PM +, Robin Murphy wrote:
> > On 2020-11-02 17:14, Jordan Crouse wrote:
> > >From: Rob Clark
> > >
> > >For the Adreno GPU's SMMU, we want SCTLR.HUPCF set to ensure that
> > >pending translations
On Thu, Nov 05, 2020 at 09:15:24PM -0500, Qian Cai wrote:
> On Thu, 2020-11-05 at 15:28 -0800, Paul E. McKenney wrote:
> > On Thu, Nov 05, 2020 at 06:02:49PM -0500, Qian Cai wrote:
> > > On Thu, 2020-11-05 at 22:22 +, Will Deacon wrote:
> > > > Hmm, this
aul E. McKenney"
Suggested-by: Qian Cai
Signed-off-by: Will Deacon
---
arch/arm64/kernel/smp.c | 1 +
kernel/rcu/tree.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 09c96f57818c..18e9727d3f64 100644
---
arm64 as fixes for 5.11.
Cheers,
Will
Cc: Catalin Marinas
Cc: Qian Cai
Cc: "Paul E. McKenney"
--->8
Will Deacon (2):
arm64: psci: Avoid printing in cpu_psci_cpu_die()
arm64: smp: Tell RCU about CPUs that fail to come online
arch/arm64/kernel/psci.c | 2 --
arch/arm64/kern
Cc: Catalin Marinas
Signed-off-by: Will Deacon
---
arch/arm64/kernel/psci.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
index 43ae4e0c968f..6a4f3e37c3b4 100644
--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
@@ -75,8
On Fri, Nov 06, 2020 at 07:49:29AM +0100, Greg KH wrote:
> On Thu, Nov 05, 2020 at 06:56:26PM -0800, Prasad Sodagudi wrote:
> > Add register read/write operations tracing support.
> > ftrace events helps to trace register read and write
> > location details of memory mapped IO registers.
>
> This
On Fri, Nov 06, 2020 at 09:06:42AM +0800, tangyouling wrote:
> In the include/asm-generic/vmlinux.lds.h:978, the description is as follows:
> DISCARDS must be the last of output section definitions so that such archs
> put those in earlier section definitions.
Sure, I see that text, but I don't
On Fri, Oct 30, 2020 at 04:33:25PM +, Will Deacon wrote:
> On Wed, 28 Oct 2020 14:26:14 -0400, Qian Cai wrote:
> > The call to rcu_cpu_starting() in secondary_start_kernel() is not early
> > enough in the CPU-hotplug onlining process, which results in lockdep
> &
On Wed, Nov 04, 2020 at 06:48:52PM +0800, Youling Tang wrote:
> In the include/asm-generic/vmlinux.lds.h file, the "must be the last"
> comment indicates that DISCARDS should be placed in the last position
> of SECTIONS, like x86, mips, riscv, etc.
>
> Signed-off-by: Youling Tang
> ---
>
On Wed, Nov 04, 2020 at 11:40:09PM -0600, Tyler Hicks wrote:
> On 2020-11-04 12:08:12, Will Deacon wrote:
> > On Tue, Nov 03, 2020 at 09:59:52AM -0600, Tyler Hicks wrote:
> > > On 2020-09-21 14:15:55, Tyler Hicks wrote:
> > > > Provide the CONFIG_CMDLINE_EXTEND c
Hi Konrad,
[+Jeffrey]
On Thu, Nov 05, 2020 at 12:22:09AM +0100, Konrad Dybcio wrote:
> This series adds Spectre mitigations and errata data for
> Qualcomm KRYO2XX Gold (big) and Silver (LITTLE) series of
> CPU cores, used for example in MSM8998 and SDM660-series SoCs.
>
> Konrad Dybcio (4):
>
On Tue, Nov 03, 2020 at 09:59:52AM -0600, Tyler Hicks wrote:
> On 2020-09-21 14:15:55, Tyler Hicks wrote:
> > Provide the CONFIG_CMDLINE_EXTEND config option for arm64 kernels. This
> > config option can be used to extend the kernel command line parameters,
> > specified by the bootloader, with
On Tue, Nov 03, 2020 at 05:34:38PM +, Mark Brown wrote:
> On Tue, Nov 03, 2020 at 10:25:37AM +, Szabolcs Nagy wrote:
>
> > Re-mmap executable segments instead of mprotecting them in
> > case mprotect is seccomp filtered.
>
> > For the kernel mapped main executable we don't have the fd
>
On Fri, 30 Oct 2020 10:30:50 -0700, Vanshidhar Konda wrote:
> The current arm64 default config limits max NUMA nodes available on
> system to 4 (NODES_SHIFT = 2). Today's arm64 systems can reach or
> exceed 16 NUMA nodes. To accomodate current hardware and to fit
> NODES_SHIFT within page flags on
On Tue, Nov 03, 2020 at 12:58:45PM +, Mark Rutland wrote:
> On Tue, Nov 03, 2020 at 12:17:21PM +, Will Deacon wrote:
> > When building with LTO, there is an increased risk of the compiler
> > converting an address dependency headed by a READ_ONCE() invocation
> > into
On Tue, Nov 03, 2020 at 12:40:18PM +, Mark Rutland wrote:
> On Tue, Nov 03, 2020 at 12:17:18PM +, Will Deacon wrote:
> > asm/alternative.h contains both the macros needed to use alternatives,
> > as well the type definitions and function prototypes for applying them.
READ_ONCE() definition with one that provides acquire semantics when
building with LTO.
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/rwonce.h | 63 +++
arch/arm64/kernel/vdso/Makefile | 2 +-
arch/arm64/kernel/vdso32
In preparation for patching the internals of READ_ONCE() itself, replace
its usage on the alternatives patching patch with a volatile variable
instead.
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Will Deacon
---
arch/arm64/kernel/alternative.c | 7 ---
1 file changed, 4 insertions
the compiler is capable of breaking the dependencies.
Since LDAPR is not available on all CPUs, add a cpufeature to detect it at
runtime and allow the instruction to be used with alternative code
patching.
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Will Deacon
---
arch/arm64/Kconfig
CFI.
I plan to queue these on their own branch in the arm64 tree for 5.11 at
-rc3.
Cheers,
Will
Cc: Kees Cook
Cc: Catalin Marinas
Cc: Sami Tolvanen
Cc: Masahiro Yamada
Cc: Peter Zijlstra
Cc: linux-kernel@vger.kernel.org
--->8
Will Deacon (4):
arm64: alternatives: Split up alternativ
-by: Peter Zijlstra (Intel)
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/alternative-macros.h | 276
arch/arm64/include/asm/alternative.h| 267 +--
arch/arm64/include/asm/insn.h | 3 +-
3 files changed, 279 insertions(+), 267
Hi Linus,
Please pull these arm64 fixes for -rc2. The diffstat is a bit spread out
thanks to an invasive CPU erratum workaround which missed the merge window
and also a bunch of fixes to the recently added MTE selftests.
We're aware of an arm64 kprobes regression and have a tentative fix [1],
On Wed, 28 Oct 2020 14:26:14 -0400, Qian Cai wrote:
> The call to rcu_cpu_starting() in secondary_start_kernel() is not early
> enough in the CPU-hotplug onlining process, which results in lockdep
> splats as follows:
>
> WARNING: suspicious RCU usage
> -
>
On Wed, Oct 28, 2020 at 07:28:26PM +0200, Andy Shevchenko wrote:
> There is no evidence we need kernel.h inclusion in certain headers.
Did you run some tools to determine this or is it just a hunch?
Will
On Thu, Oct 29, 2020 at 09:17:35AM -0400, Qian Cai wrote:
> On Thu, 2020-10-29 at 09:10 +, Will Deacon wrote:
> > On Wed, Oct 28, 2020 at 02:26:14PM -0400, Qian Cai wrote:
> > > The call to rcu_cpu_starting() in secondary_start_kernel() is not early
> > > enough
On Mon, 19 Oct 2020 11:23:20 -0700, Bjorn Andersson wrote:
> This is the revised fourth attempt of inheriting the stream mapping for
> the framebuffer on many Qualcomm platforms, in order to not hit
> catastrophic faults during arm-smmu initialization.
>
> The new approach does, based on Robin's
On Tue, Oct 27, 2020 at 04:34:04PM -0600, Jordan Crouse wrote:
> This short series adds support for the adreno-smmu implementation of the
> arm-smmu driver and the device-tree bindings to turn on the implementation
> for the sm845 and sc7180 GPUs. These changes are the last ones needed to
>
On Wed, Oct 28, 2020 at 02:26:14PM -0400, Qian Cai wrote:
> The call to rcu_cpu_starting() in secondary_start_kernel() is not early
> enough in the CPU-hotplug onlining process, which results in lockdep
> splats as follows:
>
> WARNING: suspicious RCU usage
> -
>
On Wed, Oct 28, 2020 at 01:27:01PM +0100, Ard Biesheuvel wrote:
> On Wed, 28 Oct 2020 at 11:00, Will Deacon wrote:
> > On Tue, Oct 27, 2020 at 04:11:32PM +0100, Ard Biesheuvel wrote:
> > > Geert reports that commit be2881824ae9eb92 ("arm64/build: Assert for
> >
Hi Ard,
On Tue, Oct 27, 2020 at 04:11:32PM +0100, Ard Biesheuvel wrote:
> Geert reports that commit be2881824ae9eb92 ("arm64/build: Assert for
> unwanted sections") results in build errors on arm64 for configurations
> that have CONFIG_MODULES disabled.
>
> The commit in question added ASSERT()s
701 - 800 of 10389 matches
Mail list logo
