14 Oct, 2016
1 commit
-
The timeout loop terminates when the loop count is zero, but the decrement
of the count variable is post check. So count is -1 when we check for the
timeout and therefor the error message is supressed.Change it to predecrement, so the error message is emitted.
[ tglx: Massaged changelog ]
Fixes: a2c225101234 ("irqchip: gic-v3: Refactor gic_enable_redist to support both enabling and disabling")
Signed-off-by: Dan Carpenter
Acked-by: Sudeep Holla
Cc: Marc Zyngier
Cc: kernel-janitors@vger.kernel.org
Cc: Jason Cooper
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20161014072534.GA15168@mwanda
Signed-off-by: Thomas Gleixner
21 Sep, 2016
1 commit
-
Merge urgent fixes so pending patches for 4.9 can be applied.
20 Sep, 2016
1 commit
-
gic_raise_softirq() walks the list of cpus using for_each_cpu(), it calls
gic_compute_target_list() which advances the iterator by the number of
CPUs in the cluster.If gic_compute_target_list() reaches the last CPU it leaves the iterator
pointing at the last CPU. This means the next time round the for_each_cpu()
loop cpumask_next() will be called with an invalid CPU.This triggers a warning when built with CONFIG_DEBUG_PER_CPU_MAPS:
[ 3.077738] GICv3: CPU1: found redistributor 1 region 0:0x000000002f120000
[ 3.077943] CPU1: Booted secondary processor [410fd0f0]
[ 3.078542] ------------[ cut here ]------------
[ 3.078746] WARNING: CPU: 1 PID: 0 at ../include/linux/cpumask.h:121 gic_raise_softirq+0x12c/0x170
[ 3.078812] Modules linked in:
[ 3.078869]
[ 3.078930] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0-rc5+ #5188
[ 3.078994] Hardware name: Foundation-v8A (DT)
[ 3.079059] task: ffff80087a1a0080 task.stack: ffff80087a19c000
[ 3.079145] PC is at gic_raise_softirq+0x12c/0x170
[ 3.079226] LR is at gic_raise_softirq+0xa4/0x170
[ 3.079296] pc : [] lr : [] pstate: 200001c9
[ 3.081139] Call trace:
[ 3.081202] Exception stack(0xffff80087a19fbe0 to 0xffff80087a19fd10)[ 3.082269] [] gic_raise_softirq+0x12c/0x170
[ 3.082354] [] smp_send_reschedule+0x34/0x40
[ 3.082433] [] resched_curr+0x50/0x88
[ 3.082512] [] check_preempt_curr+0x60/0xd0
[ 3.082593] [] ttwu_do_wakeup+0x20/0xe8
[ 3.082672] [] ttwu_do_activate+0x90/0xc0
[ 3.082753] [] try_to_wake_up+0x224/0x370
[ 3.082836] [] default_wake_function+0x10/0x18
[ 3.082920] [] __wake_up_common+0x5c/0xa0
[ 3.083003] [] __wake_up_locked+0x14/0x20
[ 3.083086] [] complete+0x40/0x60
[ 3.083168] [] secondary_start_kernel+0x15c/0x1d0
[ 3.083240] [] 0x808911a4
[ 3.113401] Detected PIPT I-cache on CPU2Avoid updating the iterator if the next call to cpumask_next() would
cause the for_each_cpu() loop to exit.There is no change to gic_raise_softirq()'s behaviour, (cpumask_next()s
eventual call to _find_next_bit() will return early as start >= nbits),
this patch just silences the warning.Fixes: 021f653791ad ("irqchip: gic-v3: Initial support for GICv3")
Signed-off-by: James Morse
Acked-by: Marc Zyngier
Cc: linux-arm-kernel@lists.infradead.org
Cc: Jason Cooper
Link: http://lkml.kernel.org/r/1474306155-3303-1-git-send-email-james.morse@arm.com
Signed-off-by: Thomas Gleixner
13 Sep, 2016
2 commits
-
In order to add ACPI support we need to isolate ACPI&DT common code and
move DT logic to corresponding functions. To achieve this we are using
firmware agnostic handle which can be unpacked to either DT or ACPI node.No functional changes other than a very minor one:
1. Terminate its_init call with -ENODEV for non-DT case which allows
to remove hack from its-gic-v3.c.
2. Fix ITS base register address type (from 'unsigned long' to 'phys_addr_t'),
as a bonus we get nice string formatting.
3. Since there is only one of ITS parent domain convert it to static global
variable and drop the parameter from its_probe_one. Users can refer to it
in more convenient way then.Signed-off-by: Hanjun Guo
Signed-off-by: Tomasz Nowicki
Signed-off-by: Marc Zyngier -
Currently, when running on FVP, CPU 0 boots up with its BPR changed from
the reset value. This renders it impossible to (preemptively) prioritize
interrupts on CPU 0.This is harmless on normal systems since Linux typically does not
support preemptive interrupts. It does however cause problems in
systems with additional changes (such as patches for NMI simulation).Many thanks to Andrew Thoelke for suggesting the BPR as having the
potential to harm preemption.Suggested-by: Andrew Thoelke
Signed-off-by: Daniel Thompson
Signed-off-by: Marc Zyngier
18 Aug, 2016
1 commit
-
As per the GICv3 specification, to power down a processor using GICv3
and allow automatic power-on if an interrupt must be sent to a processor,
software must set Enable to zero for all interrupt groups(by writing
to GICC_CTLR or ICC_IGRPEN{0,1}_EL1/3 as appropriate.When commit 3708d52fc6bb ("irqchip: gic-v3: Implement CPU PM notifier")
was introduced there were no firmware implementations(in particular PSCI)
handling this.Linux kernel may not be aware of the CPU power state details and might
fail to identify the power states that require quiescing the CPU
interface. Even if it can be aware of those details, it can't determine
which CPU power state have been triggered at the platform level and how
the power control is implemented.This patch make disabling redistributor and group1 non-secure interrupts
in the power down path and re-enabling of redistributor in the power-up
path conditional. It will be handled in the kernel if and only if the
non-secure accesses are permitted to access and modify control registers.
It is left to the platform implementation otherwise.Cc: Marc Zyngier
Cc: Lorenzo Pieralisi
Cc: Thomas Gleixner
Cc: Jason Cooper
Tested-by: Christopher Covington
Signed-off-by: Sudeep Holla
Signed-off-by: Marc Zyngier
14 Jul, 2016
1 commit
-
Install the callbacks via the state machine.
Signed-off-by: Richard Cochran
Signed-off-by: Anna-Maria Gleixner
Reviewed-by: Sebastian Andrzej Siewior
Acked-by: Jason Cooper
Cc: Linus Torvalds
Cc: Marc Zyngier
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: rt@linutronix.de
Link: http://lkml.kernel.org/r/20160713153333.163186301@linutronix.de
Signed-off-by: Ingo Molnar
03 Jun, 2016
1 commit
-
Make sure the two sides of the bitwise operation are bool.
Signed-off-by: Andrew Jones
Signed-off-by: Marc Zyngier
20 May, 2016
1 commit
-
Pull KVM updates from Paolo Bonzini:
"Small release overall.x86:
- miscellaneous fixes
- AVIC support (local APIC virtualization, AMD version)s390:
- polling for interrupts after a VCPU goes to halted state is now
enabled for s390
- use hardware provided information about facility bits that do not
need any hypervisor activity, and other fixes for cpu models and
facilities
- improve perf output
- floating interrupt controller improvements.MIPS:
- miscellaneous fixesPPC:
- bugfixes onlyARM:
- 16K page size support
- generic firmware probing layer for timer and GICChristoffer Dall (KVM-ARM maintainer) says:
"There are a few changes in this pull request touching things
outside KVM, but they should all carry the necessary acks and it
made the merge process much easier to do it this way."though actually the irqchip maintainers' acks didn't make it into the
patches. Marc Zyngier, who is both irqchip and KVM-ARM maintainer,
later acked at http://mid.gmane.org/573351D1.4060303@arm.com ('more
formally and for documentation purposes')"* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (82 commits)
KVM: MTRR: remove MSR 0x2f8
KVM: x86: make hwapic_isr_update and hwapic_irr_update look the same
svm: Manage vcpu load/unload when enable AVIC
svm: Do not intercept CR8 when enable AVIC
svm: Do not expose x2APIC when enable AVIC
KVM: x86: Introducing kvm_x86_ops.apicv_post_state_restore
svm: Add VMEXIT handlers for AVIC
svm: Add interrupt injection via AVIC
KVM: x86: Detect and Initialize AVIC support
svm: Introduce new AVIC VMCB registers
KVM: split kvm_vcpu_wake_up from kvm_vcpu_kick
KVM: x86: Introducing kvm_x86_ops VCPU blocking/unblocking hooks
KVM: x86: Introducing kvm_x86_ops VM init/destroy hooks
KVM: x86: Rename kvm_apic_get_reg to kvm_lapic_get_reg
KVM: x86: Misc LAPIC changes to expose helper functions
KVM: shrink halt polling even more for invalid wakeups
KVM: s390: set halt polling to 80 microseconds
KVM: halt_polling: provide a way to qualify wakeups during poll
KVM: PPC: Book3S HV: Re-enable XICS fast path for irqfd-generated interrupts
kvm: Conditionally register IRQ bypass consumer
...
11 May, 2016
2 commits
-
The GICv3 driver wrongly assumes that it runs on the non-secure
side of a secure-enabled system, while it could be on a system
with a single security state, or a GICv3 with GICD_CTLR.DS set.Either way, it is important to configure this properly, or
interrupts will simply not be delivered on this HW.Cc: stable@vger.kernel.org
Reported-by: Peter Maydell
Tested-by: Peter Maydell
Signed-off-by: Marc Zyngier -
When an IPI is generated by a CPU, the pattern looks roughly like:
smp_wmb();
On the receiving CPU we rely on the fact that, once we've taken the
interrupt, then the freshly written shared data must be visible to us.
Put another way, the CPU isn't going to speculate taking an interrupt.Unfortunately, this assumption turns out to be broken.
Consider that CPUx wants to send an IPI to CPUy, which will cause CPUy
to read some shared_data. Before CPUx has done anything, a random
peripheral raises an IRQ to the GIC and the IRQ line on CPUy is raised.
CPUy then takes the IRQ and starts executing the entry code, heading
towards gic_handle_irq. Furthermore, let's assume that a bunch of the
previous interrupts handled by CPUy were SGIs, so the branch predictor
kicks in and speculates that irqnr will be
Signed-off-by: Marc Zyngier
03 May, 2016
3 commits
-
Fill up the recently introduced gic_kvm_info with the hardware
information used for virtualization.Signed-off-by: Julien Grall
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
Signed-off-by: Christoffer Dall -
The ACPI code requires to use global variables in order to collect
information from the tables.To make clear those variables are ACPI specific, gather all of them in a
single structure.Furthermore, even if some of the variables are not marked with
__initdata, they are all only used during the initialization. Therefore,
the new variable, which hold the structure, can be marked with
__initdata.Signed-off-by: Julien Grall
Acked-by: Christoffer Dall
Reviewed-by: Hanjun Guo
Signed-off-by: Christoffer Dall -
Currently, most of the pr_* messages in the GICv3 driver don't have a
prefix. Add one to make clear where the messages come from.Signed-off-by: Julien Grall
Signed-off-by: Christoffer Dall
02 May, 2016
1 commit
-
Plug the partitioning layer into the GICv3 PPI code, parsing the
DT and building the partition affinities and providing the generic
code with partition data and callbacks.Signed-off-by: Marc Zyngier
Cc: Mark Rutland
Cc: devicetree@vger.kernel.org
Cc: Jason Cooper
Cc: Will Deacon
Cc: Rob Herring
Link: http://lkml.kernel.org/r/1460365075-7316-5-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner
09 Mar, 2016
4 commits
-
Always return IRQ_SET_MASK_OK_DONE instead of IRQ_SET_MASK_OK when the
affinity has been updated. When using stacked irqchips, returning
IRQ_SET_MASK_OK_DONE means skipping all descendant irqchips.Signed-off-by: Antoine Tenart
Acked-by: Marc Zyngier
Signed-off-by: Marc Zyngier -
Following ACPI spec:
On systems supporting GICv3 and above, GICR Base Address in MADT GICC
structure holds the 64-bit physical address of the associated Redistributor.
If all of the GIC Redistributors are in the always-on power domain,
GICR structures should be used to describe the Redistributors instead,
and this field must be set to 0.It means that we have two ways to initialize registirbutors map.
1. via GICD structure which can accommodate many redistributors as a region
2. via GICC which is able to describe single redistributorThis patch is going to add support for second option.
Considering redistributors, GICD and GICC subtables have be mutually
exclusive. While discovering and mapping redistributor, we need to know
its size in advance. For the GICC case, redistributor can be in
a power-domain that is off, thus we cannot relay on GICR TYPER register.
Therefore, we get GIC version from distributor register and map 2xSZ_64K
for GICv3 and 4xSZ_64K for GICv4.Acked-by: Marc Zyngier
Signed-off-by: Hanjun Guo
Signed-off-by: Tomasz Nowicki
Signed-off-by: Marc Zyngier -
With the refator of gic_of_init(), GICv3/4 can be initialized
by gic_init_bases() with gic distributor base address and gic
redistributor region(s).So get the redistributor region base addresses from MADT GIC
redistributor subtable, and the distributor base address from
GICD subtable to init GICv3 irqchip in ACPI way.Note: GIC redistributor base address may also be provided in
GICC structures on systems supporting GICv3 and above if the GIC
Redistributors are not in the always-on power domain, this
patch didn't implement such feature yet.Acked-by: Marc Zyngier
Signed-off-by: Tomasz Nowicki
Signed-off-by: Hanjun Guo
Signed-off-by: Marc Zyngier -
Isolate hardware abstraction (FDT) code to gic_of_init().
Rest of the logic goes to gic_init_bases() and expects well
defined data to initialize GIC properly. The same solution
is used for GICv2 driver.This is needed for ACPI initialization later.
Acked-by: Marc Zyngier
Signed-off-by: Tomasz Nowicki
Signed-off-by: Hanjun Guo
Signed-off-by: Marc Zyngier
15 Oct, 2015
1 commit
-
Commit f833f57ff254 ("irqchip: Convert all alloc/xlate users from
of_node to fwnode") converted the GICv3 driver to using irq_fwspec
as part of its 'translate' method.Too bad it ended up with a copy of the GICv2 'translate' method,
which screws up LPI translation (by not translating them at all).Restore the code in its original shape, and just change what is
really required...Signed-off-by: Marc Zyngier
Cc:
Cc: Suravee Suthikulpanit
Cc: Duc Dang
Cc: Jason Cooper
Link: http://lkml.kernel.org/r/1444822037-16983-2-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner
14 Oct, 2015
2 commits
-
Since we now have a generic data structure to express an
interrupt specifier, convert all hierarchical irqchips that
are OF based to use a fwnode_handle as part of their alloc
and xlate (which becomes translate) callbacks.As most of these drivers have dependencies (they exchange IRQ
specifiers), change them all in a single, massive patch...Signed-off-by: Marc Zyngier
Reviewed-and-tested-by: Hanjun Guo
Tested-by: Lorenzo Pieralisi
Cc:
Cc: Tomasz Nowicki
Cc: Suravee Suthikulpanit
Cc: Graeme Gregory
Cc: Jake Oshins
Cc: Jiang Liu
Cc: Jason Cooper
Cc: Rafael J. Wysocki
Link: http://lkml.kernel.org/r/1444737105-31573-6-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner -
The struct irq_domain contains a "struct device_node *" field
(of_node) that is almost the only link between the irqdomain
and the device tree infrastructure.In order to prepare for the removal of that field, convert all
users to use irq_domain_get_of_node() instead.Signed-off-by: Marc Zyngier
Reviewed-and-tested-by: Hanjun Guo
Tested-by: Lorenzo Pieralisi
Cc:
Cc: Tomasz Nowicki
Cc: Suravee Suthikulpanit
Cc: Graeme Gregory
Cc: Jake Oshins
Cc: Jiang Liu
Cc: Jason Cooper
Cc: Rafael J. Wysocki
Link: http://lkml.kernel.org/r/1444737105-31573-2-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner
10 Oct, 2015
4 commits
-
On 32bit platforms, we cannot assure that an I/O ldrd or strd will be
done atomically. Besides, an hypervisor would be unable to emulate such
accesses.
In order to allow the AArch32 version of the driver to split them into
two 32bit accesses while keeping the requirement for atomic writes, this
patch specializes the IROUTER and TYPER accesses.
Since the latter is an ID register, it won't need to be read atomically,
but we still avoid future confusion by using gic_read_typer instead of a
generic gic_readq.Reviewed-by: Marc Zyngier
Signed-off-by: Jean-Philippe Brucker
Signed-off-by: Marc Zyngier -
This patch does a few simple compatibility-related changes:
- change the system register access prototypes to their actual size,
- homogenise mpidr accesses with unsigned long,
- force the 64bit register values to unsigned long long.Note: the list registers are 64bit on GICv3, but the AArch32 vGIC driver
will need to split their values into two 32bit registers: LRn and LRCn.Reviewed-by: Marc Zyngier
Signed-off-by: Jean-Philippe Brucker
Signed-off-by: Marc Zyngier -
This patch moves the GICv3 system register access helpers to
arch/arm64/. Their 32bit counterparts will need to use mrc/mcr accesses
instead of mrs_s/msr_s.[maz: fixed conflict with Cavium erratum handling]
Reviewed-by: Marc Zyngier
Signed-off-by: Jean-Philippe Brucker
Signed-off-by: Marc Zyngier -
In order for gic_enable_sre to be used by the arm64 core code,
move it to arm-gic-v3.h. As a bonus, we now also check if
system registers have been already enabled, and return early
if they have.In all cases, the function now returns a boolean indicating if
the enabling has been successful.Reviewed-by: Catalin Marinas
Signed-off-by: Marc Zyngier
29 Sep, 2015
2 commits
-
Use newly introduced jump label API.
Make this a separate patch for easier backporting to older kernels of
the errata patch set.Signed-off-by: Robert Richter
Reviewed-by: Marc Zygnier
Acked-by: Catalin Marinas
Cc: Tirumalesh Chalamarla
Cc: linux-arm-kernel@lists.infradead.org
Cc: Jason Cooper
Link: http://lkml.kernel.org/r/1442869119-1814-7-git-send-email-rric@kernel.org
Signed-off-by: Thomas Gleixner -
This patch implements Cavium ThunderX erratum 23154.
The gicv3 of ThunderX requires a modified version for reading the IAR
status to ensure data synchronization. Since this is in the fast-path
and called with each interrupt, runtime patching is used using jump
label patching for smallest overhead (no-op). This is the same
technique as used for tracepoints.Signed-off-by: Robert Richter
Reviewed-by: Marc Zygnier
Acked-by: Catalin Marinas
Cc: Tirumalesh Chalamarla
Cc: linux-arm-kernel@lists.infradead.org
Cc: Jason Cooper
Cc: Will Deacon
Link: http://lkml.kernel.org/r/1442869119-1814-3-git-send-email-rric@kernel.org
Signed-off-by: Thomas Gleixner
16 Sep, 2015
2 commits
-
set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:IRQF_VALID -> !IRQ_NOREQUEST
IRQF_PROBE -> !IRQ_NOPROBE
IRQF_NOAUTOEN -> IRQ_NOAUTOENFor IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also modify IRQ_NOPROBE and this has been maintained although it
is not clear that is really needed. There appears to be a great deal of
blind copy and paste of this code.Signed-off-by: Rob Herring
Cc: linux-arm-kernel@lists.infradead.org
Cc: Russell King
Cc: Jason Cooper
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Stephen Warren
Cc: Lee Jones
Cc: Alexander Shiyan
Cc: Maxime Ripard
Cc: linux-rpi-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Link: http://lkml.kernel.org/r/1440889285-5637-3-git-send-email-robh@kernel.org
Signed-off-by: Thomas Gleixner -
Get rid of the handler_data abuse.
Signed-off-by: Thomas Gleixner
Acked-by: Marc Zyngier
27 Aug, 2015
2 commits
-
Commit 0a4377de3056 ("genirq: Introduce irq_set_vcpu_affinity() to
target an interrupt to a VCPU") added just what we needed at the
lowest level to allow an interrupt to be deactivated by a guest.When such a request reaches the GIC, it knows it doesn't need to
perform the deactivation anymore, and can safely leave the guest
do its magic. This of course requires additional support in both
VFIO and KVM.Signed-off-by: Marc Zyngier
Reviewed-and-tested-by: Eric Auger
Cc: Christoffer Dall
Cc: Jiang Liu
Cc:
Cc: kvmarm@lists.cs.columbia.edu
Cc: Jason Cooper
Link: http://lkml.kernel.org/r/1440604845-28229-3-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner -
So far, GICv3 has been used in with EOImode == 0. The effect of this
mode is to perform the priority drop and the deactivation of the
interrupt at the same time.While this works perfectly for Linux (we only have a single priority),
it causes issues when an interrupt is forwarded to a guest, and when
we want the guest to perform the EOI itself.For this case, the GIC architecture provides EOImode == 1, where:
- A write to ICC_EOIR1_EL1 drops the priority of the interrupt and
leaves it active. Other interrupts at the same priority level can
now be taken, but the active interrupt cannot be taken again
- A write to ICC_DIR_EL1 marks the interrupt as inactive, meaning
it can now be taken again.This patch converts the driver to be able to use this new mode,
depending on whether or not the kernel can behave as a hypervisor.
No feature change.Signed-off-by: Marc Zyngier
Reviewed-and-tested-by: Eric Auger
Cc: Christoffer Dall
Cc: Jiang Liu
Cc:
Cc: kvmarm@lists.cs.columbia.edu
Cc: Jason Cooper
Link: http://lkml.kernel.org/r/1440604845-28229-2-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner
12 Jul, 2015
1 commit
-
The IRQCHIP_DECLARE macro moved to to 'include/linux/irqchip.h', so
the local irqchip.h became an empty shell, which solely includes
include/linux/irqchip.hInclude the global header in all irqchip drivers instead of the local
header, so we can remove it.Signed-off-by: Joel Porquet
Cc: vgupta@synopsys.com
Cc: monstr@monstr.eu
Cc: ralf@linux-mips.org
Cc: jason@lakedaemon.net
Link: http://lkml.kernel.org/r/1882096.X39jVG8e0D@joel-zenbook
Signed-off-by: Thomas Gleixner
06 Jun, 2015
1 commit
-
GIC requires to disable the interrupt before changing the trigger type.
irqchip core provides IRQCHIP_SET_TYPE_MASKED flag and ensures that the
interrupt is masked before calling chip.irq_set_type() if the irqchip
sets the flag.This patch adds IRQCHIP_SET_TYPE_MASKED to GIC irqchip so that the core
can manage disabling the interrupt while changing the trigger type.Signed-off-by: Sudeep Holla
Reviewed-by: Marc Zyngier
Cc: Jason Cooper
Link: http://lkml.kernel.org/r/1433501997-19205-1-git-send-email-sudeep.holla@arm.com
Signed-off-by: Thomas Gleixner
21 Apr, 2015
1 commit
-
Pull final removal of deprecated cpus_* cpumask functions from Rusty Russell:
"This is the final removal (after several years!) of the obsolete
cpus_* functions, prompted by their mis-use in staging.With these function removed, all cpu functions should only iterate to
nr_cpu_ids, so we finally only allocate that many bits when cpumasks
are allocated offstack"* tag 'cpumask-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: (25 commits)
cpumask: remove __first_cpu / __next_cpu
cpumask: resurrect CPU_MASK_CPU0
linux/cpumask.h: add typechecking to cpumask_test_cpu
cpumask: only allocate nr_cpumask_bits.
Fix weird uses of num_online_cpus().
cpumask: remove deprecated functions.
mips: fix obsolete cpumask_of_cpu usage.
x86: fix more deprecated cpu function usage.
ia64: remove deprecated cpus_ usage.
powerpc: fix deprecated CPU_MASK_CPU0 usage.
CPU_MASK_ALL/CPU_MASK_NONE: remove from deprecated region.
staging/lustre/o2iblnd: Don't use cpus_weight
staging/lustre/libcfs: replace deprecated cpus_ calls with cpumask_
staging/lustre/ptlrpc: Do not use deprecated cpus_* functions
blackfin: fix up obsolete cpu function usage.
parisc: fix up obsolete cpu function usage.
tile: fix up obsolete cpu function usage.
arm64: fix up obsolete cpu function usage.
mips: fix up obsolete cpu function usage.
x86: fix up obsolete cpu function usage.
...
09 Apr, 2015
1 commit
-
Add the required hooks for the internal state of an interrupt
to be exposed to other subsystems.Signed-off-by: Marc Zyngier
Cc: linux-arm-kernel@lists.infradead.org
Cc: Abhijeet Dharmapurikar
Cc: Stephen Boyd
Cc: Phong Vo
Cc: Linus Walleij
Cc: Tin Huynh
Cc: Y Vo
Cc: Toan Le
Cc: Bjorn Andersson
Cc: Jason Cooper
Cc: Arnd Bergmann
Link: http://lkml.kernel.org/r/1426676484-21812-4-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner
08 Mar, 2015
1 commit
-
While playing with KASan support for arm64/arm the following appeared on boot:
==================================================================
BUG: AddressSanitizer: out of bounds access in __asan_load8+0x14/0x1c at addr ffffffc000ad0dc0
Read of size 8 by task swapper/0/1
page:ffffffbdc202b400 count:1 mapcount:0 mapping: (null) index:0x0
flags: 0x400(reserved)
page dumped because: kasan: bad access detected
Address belongs to variable __cpu_logical_map+0x200/0x220
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc6-next-20150129+ #481
Hardware name: FVP Base (DT)
Call trace:
[] dump_backtrace+0x0/0x184
[] show_stack+0x10/0x1c
[] dump_stack+0xa0/0xf8
[] kasan_report_error+0x23c/0x264
[] check_memory_region+0xc0/0xe4
[] __asan_load8+0x10/0x1c
[] gic_raise_softirq+0xc4/0x1b4
[] smp_send_reschedule+0x30/0x3c
[] try_to_wake_up+0x394/0x434
[] wake_up_process+0x2c/0x6c
[] wake_up_worker+0x38/0x48
[] insert_work+0xac/0xec
[] __queue_work+0x1a8/0x374
[] queue_work_on+0x5c/0x7c
[] call_usermodehelper_exec+0x170/0x188
[] kobject_uevent_env+0x650/0x6bc
[] kobject_uevent+0xc/0x18
[] kset_register+0xa8/0xc8
[] bus_register+0x134/0x2e8
[] subsys_virtual_register+0x2c/0x5c
[] wq_sysfs_init+0x14/0x20
[] do_one_initcall+0xa8/0x1fc
[] kernel_init_freeable+0x1ec/0x294
[] kernel_init+0xc/0xec
Memory state around the buggy address:
ffffff80003e0820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffffff80003e0830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffff80003e0840: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
^
ffffff80003e0850: 00 00 fa fa fa fa fa fa 00 00 00 00 00 00 00 00
==================================================================The reason for that cpumask_next() returns >= nr_cpu_ids if no further cpus
set, but "==" condition is checked only, so we end up with out-of-bounds
access to cpu_logical_map.Fix is by using the condition check for cpumask_next.
Signed-off-by: Vladimir Murzin
Signed-off-by: Marc Zyngier
Link: https://lkml.kernel.org/r/1425659870-11832-7-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper
05 Mar, 2015
1 commit
-
Thanks to spatch, plus manual removal of "&*". Then a sweep for
for_each_cpu_mask => for_each_cpu.Signed-off-by: Rusty Russell
Acked-by: Rafael J. Wysocki
Cc: Thomas Gleixner
Cc: Herbert Xu
Cc: Jason Cooper
Cc: Chris Metcalf
Cc: netdev@vger.kernel.org
17 Feb, 2015
1 commit
-
Pull irqchip updates from Ingo Molnar:
"Various irqchip driver updates, plus a genirq core update that allows
the initial spreading of irqs amonst CPUs without having to do it from
user-space"* 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
genirq: Fix null pointer reference in irq_set_affinity_hint()
irqchip: gic: Allow interrupt level to be set for PPIs
irqchip: mips-gic: Handle pending interrupts once in __gic_irq_dispatch()
irqchip: Conexant CX92755 interrupts controller driver
irqchip: Devicetree: document Conexant Digicolor irq binding
irqchip: omap-intc: Remove unused legacy interface for omap2
irqchip: omap-intc: Fix support for dm814 and dm816
irqchip: mtk-sysirq: Get irq number from register resource size
irqchip: renesas-intc-irqpin: r8a7779 IRLM setup support
genirq: Set initial affinity in irq_set_affinity_hint()
26 Jan, 2015
1 commit
-
During a recent cleanup of the arm64 DTs it has become clear that
the handling of PPIs in xxxx_set_type() is incorrect. The ARM TRMs
for GICv2 and later allow for "implementation defined" support for
setting the edge or level type of the PPI interrupts and don't restrict
the activation level of the signal. Current ARM implementations
do restrict the PPI level type to IRQ_TYPE_LEVEL_LOW, but licensees
of the IP can decide to shoot themselves in the foot at any time.Signed-off-by: Liviu Dudau
Acked-by: Marc Zyngier
Cc: LAKML
Cc: Russell King
Cc: Rob Herring
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Jason Cooper
Cc: Haojian Zhuang
Link: http://lkml.kernel.org/r/1421772779-25764-1-git-send-email-Liviu.Dudau@arm.com
Signed-off-by: Thomas Gleixner
