Linus,
Al Viro discovered some breakage with the parsing of the set_ftrace_filter
as well as the removing of function probes.
This fixes the code with Al's suggestions. I also added a few selftests
to test the broken cases such that they wont happen again.
Please pull the latest trace-v4.16-rc1
From: "Steven Rostedt (VMware)"
__unregister_ftrace_function_probe() will incorrectly parse the glob filter
because it resets the search variable that was setup by filter_parse_regex().
Al Viro reported this:
After that call of filter_parse_regex() we could have func_g.search not
equal
1) Make allocations less aggressive in x_tables, from Minchal Hocko.
2) Fix netfilter flowtable Kconfig deps, from Pablo Neira Ayuso.
3) Fix connection loss problems in rtlwifi, from Larry Finger.
4) Correct DRAM dump length for some chips in ath10k driver,
from Yu Wang.
5) Fix ABORT handli
On Fri, Feb 9, 2018 at 11:25 AM, Joerg Roedel wrote:
>
> Ugh, okay. So I switch to movsl, that should at least perform on-par
> with the chain of 'pushl' instructions I had before.
It should generally be roughly in the same ballpark.
I think the instruction scheduling ends up basically breaking
On Mon, Dec 11, 2017 at 10:54:51AM +, Chris Wilson wrote:
> Quoting Matthew Wilcox (2017-11-30 17:36:30)
> > About 40 of the approximately 180 users of the IDR in the kernel are
> > "1-based" instead of "0-based". That is, they never want to have ID 0
> > allocated; they want to see IDs alloca
On Fri, Feb 9, 2018 at 10:59 AM, Juergen Gross wrote:
>
> Do you want me to setup the patches for pulling again?
No, I've pulled, I just don't want to see these unexplained merges again.
Preferably I don't want to see back-merges at all, but when I do see
them, I want to see an explanation for w
The summary email did not make it for some reason.
However.
All these drivers is using watchdog_init_timeout() to set timeout.
If the timeout-parameter is set to an valid value, it will allways pick
that and not even consider if timeout-secs is set in devicetree.
Most of the patches will just rem
watchdog_init_timeout() will allways pick timeout_param since it
defaults to a valid timeout.
Following best practice described in
Documentation/watchdog/watchdog-kernel-api.txt to make use of
the parameter logic.
Signed-off-by: Marcus Folkesson
---
drivers/watchdog/sama5d4_wdt.c | 4 ++--
1 fi
On 02/09/2018 08:02 PM, Joerg Roedel wrote:
On Fri, Feb 09, 2018 at 09:05:02AM -0800, Linus Torvalds wrote:
On Fri, Feb 9, 2018 at 1:25 AM, Joerg Roedel wrote:
+
+ /* Copy over the stack-frame */
+ cld
+ rep movsb
Ugh. This is going to be horrendous. Maybe not noticeable on
watchdog_init_timeout() will allways pick timeout_param since it
defaults to a valid timeout.
By following best practice described in
Documentation/watchdog/watchdog-kernel-api.txt, it also
let us to set timout-sec property in devicetree.
Signed-off-by: Marcus Folkesson
---
Documentation/device
watchdog_init_timeout() will allways pick timeout_param since it
defaults to a valid timeout.
By following best practice described in
Documentation/watchdog/watchdog-kernel-api.txt, it also
let us to set timout-sec property in devicetree.
Signed-off-by: Marcus Folkesson
---
Documentation/device
watchdog_init_timeout() will allways pick timeout_param since it
defaults to a valid timeout.
By following best practice described in
Documentation/watchdog/watchdog-kernel-api.txt, it also
let us to set timout-sec property in devicetree.
Signed-off-by: Marcus Folkesson
---
Documentation/device
On Fri, Feb 9, 2018 at 8:27 PM, syzbot
wrote:
> Hello,
>
> syzbot hit the following crash on net-next commit
> 617aebe6a97efa539cc4b8a52adccd89596e6be0 (Sun Feb 4 00:25:42 2018 +)
> Merge tag 'usercopy-v4.16-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
>
> So far this cra
From: Jason Wang
Date: Fri, 9 Feb 2018 17:45:49 +0800
> To avoid slab to warn about exceeded size, fail early if queue
> occupies more than KMALLOC_MAX_SIZE.
>
> Reported-by: syzbot+e4d4f9ddd42955397...@syzkaller.appspotmail.com
> Fixes: 2e0ab8ca83c12 ("ptr_ring: array based FIFO for pointers")
From: Jason Wang
Date: Fri, 9 Feb 2018 17:45:50 +0800
> This patch switch to use kvmalloc_array() for using a vmalloc()
> fallback to help in case kmalloc() fails.
>
> Reported-by: syzbot+e4d4f9ddd42955397...@syzkaller.appspotmail.com
> Fixes: 2e0ab8ca83c12 ("ptr_ring: array based FIFO for poin
watchdog_init_timeout() will allways pick timeout_param since it
defaults to a valid timeout.
Following best practice described in
Documentation/watchdog/watchdog-kernel-api.txt to make use of
the parameter logic.
Signed-off-by: Marcus Folkesson
---
drivers/watchdog/coh901327_wdt.c | 2 +-
1 fi
On 9 February 2018 at 18:02, Sebastian Andrzej Siewior
wrote:
> On 2017-12-26 10:29:20 [+], Ard Biesheuvel wrote:
>> As reported by Sebastian, the way the arm64 NEON crypto code currently
>> keeps kernel mode NEON enabled across calls into skcipher_walk_xxx() is
> …
>> So let's clean this up f
All these drivers is using watchdog_init_timeout() to set timeout.
If the timeout-parameter is set to an valid value, it will allways pick
that and not even consider if timeout-secs is set in the devicetree.
Most of the patches will just remove the initial value for
timeout-parameter.
Some of the
On Thu, Feb 1, 2018 at 11:22 PM, Eric Biggers wrote:
> On Sun, Dec 31, 2017 at 10:58:01AM -0800, syzbot wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 5aa90a84589282b87666f92b6c3c917c8080a9bf
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> compiler: gc
watchdog_init_timeout() will allways pick timeout_param since it
defaults to a valid timeout.
Following best practice described in
Documentation/watchdog/watchdog-kernel-api.txt to make use of
the parameter logic.
Signed-off-by: Marcus Folkesson
---
drivers/watchdog/pnx4008_wdt.c | 2 +-
1 file
watchdog_init_timeout() will allways pick timeout_param since it
defaults to a valid timeout.
By following best practice described in
Documentation/watchdog/watchdog-kernel-api.txt, it also
let us to set timout-sec property in devicetree.
Signed-off-by: Marcus Folkesson
---
Documentation/device
On Fri, Feb 09, 2018 at 11:17:35AM -0800, Linus Torvalds wrote:
> Yeah, it's only true on the very latest uarchs, and even there it's
> not perfect for small copies.
>
> On the older machines that are relevant for 32-bit code, it's often
> tens of cycles just for the ucode overhead, I think, and "
From: Niklas Cassel
Date: Fri, 9 Feb 2018 17:22:44 +0100
> A couple of small stmmac irq fixes/cleanups.
Seires applied.
Change log:
v2 - v3
Andrew Morton's comments:
- Moved read of pgdat->first_deferred_pfn into
deferred_zone_grow_lock, thus got rid of READ_ONCE()/WRITE_ONCE()
- Replaced spin_lock() with spin_lock_irqsave() in
deferred_grow_zone
- Updated
Deferred page initialization allows the boot cpu to initialize a small
subset of the system's pages early in boot, with other cpus doing the rest
later on.
It is, however, problematic to know how many pages the kernel needs during
boot. Different modules and kernel parameters may change the requi
On Fri, Feb 9, 2018 at 11:02 AM, Joerg Roedel wrote:
>
> Okay, I used movsb because I remembered that being the recommendation
> for the most efficient memcpy, and it safes me an instruction. But that
> is probably only true on modern CPUs.
Yeah, it's only true on the very latest uarchs, and even
On 2/9/18 12:16 AM, Kirill A. Shutemov wrote:
On Thu, Feb 08, 2018 at 08:47:35PM -0800, Yang Shi wrote:
On 2/8/18 8:33 PM, Kirill A. Shutemov wrote:
On Thu, Feb 08, 2018 at 02:39:26PM -0800, Andrew Morton wrote:
On Tue, 6 Feb 2018 08:06:36 +0800 Yang Shi wrote:
For PTE-mapped THP, the c
For PTE-mapped THP, the compound THP has not been split to normal 4K
pages yet, the whole THP is considered referenced if any one of sub
page is referenced.
When walking PTE-mapped THP by pvmw, all relevant PTEs will be checked
to retrieve referenced bit. But, the current code just returns the
res
Em Fri, Feb 09, 2018 at 08:10:57PM +0100, Jiri Olsa escreveu:
> On Fri, Feb 09, 2018 at 03:37:11PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Feb 09, 2018 at 10:27:34AM +0100, Jiri Olsa escreveu:
> > Humm, its a nice hack, but it would be even better if it didn't showed
> > it as if it was
Hi Andy,
On Fri, Feb 09, 2018 at 05:47:43PM +, Andy Lutomirski wrote:
> One thing worth noting is that performance of this whole series is
> going to be abysmal due to the complete lack of 32-bit PCID. Maybe
> any kernel built with this option set that runs on a CPU that has the
> PCID bit se
On Fri, Feb 09, 2018 at 03:37:11PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Feb 09, 2018 at 10:27:34AM +0100, Jiri Olsa escreveu:
> > On Wed, Feb 07, 2018 at 10:52:35AM -0800, Stephane Eranian wrote:
> >
> > SNIP
> >
> > > >> Similar to what I get if I do instead:
> > > >> $ perf record -
On Fri, Feb 09, 2018 at 05:48:36PM +, Andy Lutomirski wrote:
> Can you rename the helper from pti_set_user_pgd() to
> pti_set_user_top_level_entry() or similar? The name was already a bit
> absurd, but now it's just nuts.
Sure, I can do that, just pti_set_user_top_level_entry() is a bit long.
On Fri, Feb 09, 2018 at 05:43:55PM +, Andy Lutomirski wrote:
> The 64-bit code mostly uses a bunch of push instructions for this.
I had it implemented with tons of push instructions first, but that
doesn't work in cases where the stack switch needs to happen only after
everything is copied o
On Fri, Feb 09, 2018 at 09:05:02AM -0800, Linus Torvalds wrote:
> On Fri, Feb 9, 2018 at 1:25 AM, Joerg Roedel wrote:
> > +
> > + /* Copy over the stack-frame */
> > + cld
> > + rep movsb
>
> Ugh. This is going to be horrendous. Maybe not noticeable on modern
> CPU's, but the wh
On 09/02/18 19:48, Linus Torvalds wrote:
> On Fri, Feb 9, 2018 at 6:28 AM, Juergen Gross wrote:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
>> for-linus-4.16-rc1-tag
>
> So I've pulled this, but the back-merges *really* annoy me.
>
> Seriously, DON'T DO MERGES IF YOU CANNOT
On Fri, Feb 09, 2018 at 05:55:12PM +, Suzuki K Poulose wrote:
> We enable hardware DBM bit in a capable CPU, very early in the
> boot via __cpu_setup. This doesn't give us a flexibility of
> optionally disable the feature, as the clearing the bit
> is a bit costly as the TLB can cache the setti
On Fri, 2018-02-09 at 11:31 +0100, Rafael J. Wysocki wrote:
> On Wed, Feb 7, 2018 at 2:18 PM, Aishwarya Pant
> wrote:
> > The descriptions have been collected from git commit logs and
> > reading
> > through code.
> >
> > Signed-off-by: Aishwarya Pant
> > ---
> > Documentation/ABI/testing/sysfs
Hi Klaus,
Am Samstag, 3. Februar 2018, 16:50:16 CET schrieb Klaus Goger:
> Enable the NXP SGTL5000 audio codec on the RK3399-Q7 EVK baseboard
> Haikou.
>
> The i2s0_2ch_bus definition is only done in the SoM dtsi as it is
> missing the LRCK_RX pin (that is used otherwise) and therefore not
> gene
On Fri, Feb 9, 2018 at 6:28 AM, Juergen Gross wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-4.16-rc1-tag
So I've pulled this, but the back-merges *really* annoy me.
Seriously, DON'T DO MERGES IF YOU CANNOT EVEN BE BOTHERED TO WRITE A
REASON FOR THEM!
There a
On Fri, 9 Feb 2018, Paul E. McKenney wrote:
> This commit adds comments to the litmus tests summarizing what these
> tests are intended to demonstrate.
>
> Suggested-by: Ingo Molnar
> Signed-off-by: Paul E. McKenney
> [ paulmck: Apply Andrea's and Alan's feedback. ]
> ---
> --- a/tools/memory-
Em Fri, Feb 09, 2018 at 03:37:11PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Feb 09, 2018 at 10:27:34AM +0100, Jiri Olsa escreveu:
> > On Wed, Feb 07, 2018 at 10:52:35AM -0800, Stephane Eranian wrote:
> >
> > SNIP
> >
> > > >> Similar to what I get if I do instead:
> > > >> $ perf recor
Hi Linus,
Here are the target-pending updates for v4.16-rc1. Please go ahead and
pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next
The highlights include:
- Numerous target-core-user improvements related to queue full and timeout
handling. (MNC)
- Prev
Em Fri, Feb 09, 2018 at 10:27:34AM +0100, Jiri Olsa escreveu:
> On Wed, Feb 07, 2018 at 10:52:35AM -0800, Stephane Eranian wrote:
>
> SNIP
>
> > >> Similar to what I get if I do instead:
> > >> $ perf record -e '{branches,branches,branches,branches}' my_test
> > >> $ perf report --group
> > >>
>
On Mon, Feb 5, 2018 at 9:32 AM, Amir Goldstein wrote:
> The comment claims that this helper will try not to loose bits, but
> for 64bit long it looses the high bits before hashing 64bit long into
> 32bit int. Use the helper hash_long() to do the right thing for 64bit
> long. For 32bit long, there
On Fri, Feb 09, 2018 at 05:54:51PM +, Suzuki K Poulose wrote:
> Now that the features and errata workarounds have the same
> rules and flow, group the handling of the tables.
>
> Cc: Dave Martin
> Signed-off-by: Suzuki K Poulose
The naming gets a bit confusing, particularly with
setup_syste
On Thu, Feb 08, 2018 at 07:04:56PM +, Mathieu Desnoyers wrote:
> - On Feb 8, 2018, at 1:56 PM, Will Deacon will.dea...@arm.com wrote:
>
> > On Thu, Feb 08, 2018 at 08:03:50AM +0100, Ingo Molnar wrote:
> >>
> >> * Will Deacon wrote:
> >>
> >> > For the sake of avoiding the conflict, can
On Fri, Feb 09, 2018 at 05:54:49PM +, Suzuki K Poulose wrote:
> So far we have treated the feature capabilities as system wide
> and this doesn't help with features that could be detected on
doesn't -> wouldn't (since no such features exist yet)
detected to "detected locally" (maybe)
> one o
On 02/09/2018 12:18 PM, Greg Kroah-Hartman wrote:
Oops, yeah, I'll pick them up for the next release, sorry. Was
traveling all this week and with the middle of the merge window, finding
all of the stable patches that can be applied right now was hard. After
4.16-rc1 is out, it will get easier.
On Fri, Feb 09, 2018 at 12:01:45PM -0600, Timur Tabi wrote:
> On Fri, Feb 9, 2018 at 7:39 AM, Greg Kroah-Hartman
> wrote:
> > This is the start of the stable review cycle for the 4.14.19 release.
> > There are 22 patches in this series, all will be posted as a response
> > to this one. If anyone
On Fri, Feb 09, 2018 at 05:54:48PM +, Suzuki K Poulose wrote:
> Right now we run through the errata workarounds check on all boot
> active CPUs, with SCOPE_ALL. This doesn't help with detecting the
> errata's with a SYSTEM_SCOPE. While nobody uses it, let us clean
> this up in preparation for m
On Fri, Feb 09, 2018 at 05:54:45PM +, Suzuki K Poulose wrote:
> We are about to group the handling of all capabilities (features
> and errata workarounds). This patch open codes the wrapper routines
> to make it easier to merge the handling.
>
> Cc: Dave Martin
> Signed-off-by: Suzuki K Poulo
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 1465078
Signed-off-by: Gustavo A. R. Silva
---
This code was compiled with GCC 7.3.0
drivers/acpi/spcr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/driver
We have errata work around processing code in cpu_errata.c,
which calls back into helpers defined in cpufeature.c. Now
that we are going to make the handling of capabilities
generic, by adding the information to each capability,
move the errata work around specific processing code.
No functional ch
We trigger CPU errata work around check on the boot CPU from
smp_prepare_boot_cpu() to make sure that we run the checks only
after the CPU feature infrastructure is initialised. While this
is correct, we can also do this from init_cpu_features() which
initilises the infrastructure, and is called on
We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
to the userspace and the CPU hwcaps used by the kernel, which
include cpu features and CPU errata work arounds. Capabilities
have some properties that decide how they should be treated :
1) Detection, i.e scope : A cap could be "de
We have errata work around processing code in cpu_errata.c,
which calls back into helpers defined in cpufeature.c. Now
that we are going to make the handling of capabilities
generic, by adding the information to each capability,
move the errata work around specific processing code.
No functional ch
When a CPU is brought up, it is checked against the caps that are
known to be enabled on the system (via verify_local_cpu_capabilities()).
Based on the state of the capability on the CPU vs. that of System we
could have the following combinations of conflict.
x-
When a CPU is brought up, it is checked against the caps that are
known to be enabled on the system (via verify_local_cpu_capabilities()).
Based on the state of the capability on the CPU vs. that of System we
could have the following combinations of conflict.
x-
Now that each capability describes how to treat the conflicts
of CPU cap state vs System wide cap state, we can unify the
verification logic to a single place.
Reviewed-by: Dave Martin
Signed-off-by: Suzuki K Poulose
---
arch/arm64/kernel/cpufeature.c | 89 ++
While processing the list of capabilities, it is useful to
filter out some of the entries based on the given mask for the
scope of the capabilities to allow better control. This can be
used later for handling LOCAL vs SYSTEM wide capabilities and more.
All capabilities should have their scope set t
On 09/02/18 17:54, Suzuki K Poulose wrote:
This series reworks the arm64 CPU capabilities handling (which
manages the system features and errata). The current infrastructure
doesn't allow fine control for handling different features or errata.
There is one rule for features and another rule for e
While processing the list of capabilities, it is useful to
filter out some of the entries based on the given mask for the
scope of the capabilities to allow better control. This can be
used later for handling LOCAL vs SYSTEM wide capabilities and more.
All capabilities should have their scope set t
We are about to group the handling of all capabilities (features
and errata workarounds). This patch open codes the wrapper routines
to make it easier to merge the handling.
Cc: Dave Martin
Signed-off-by: Suzuki K Poulose
---
arch/arm64/kernel/cpufeature.c | 60 +
So far we have treated the feature capabilities as system wide
and this doesn't help with features that could be detected on
one or more CPUs (e.g, KPTI, Software prefetch). This patch
splits the feature detection to two phases :
1) Local CPU features are checked on all boot time active CPUs.
2)
Now that the features and errata workarounds have the same
rules and flow, group the handling of the tables.
Cc: Dave Martin
Signed-off-by: Suzuki K Poulose
---
arch/arm64/kernel/cpufeature.c | 72 --
1 file changed, 41 insertions(+), 31 deletions(-)
dif
So far we have treated the feature capabilities as system wide
and this doesn't help with features that could be detected on
one or more CPUs (e.g, KPTI, Software prefetch). This patch
splits the feature detection to two phases :
1) Local CPU features are checked on all boot time active CPUs.
2)
Now that the features and errata workarounds have the same
rules and flow, group the handling of the tables.
Cc: Dave Martin
Signed-off-by: Suzuki K Poulose
---
arch/arm64/kernel/cpufeature.c | 72 --
1 file changed, 41 insertions(+), 31 deletions(-)
dif
KPTI is treated as a system wide feature and is only detected if all
the CPUs in the sysetm needs the defense, unless it is forced via kernel
command line. This leaves a system with a mix of CPUs with and without
the defense vulnerable. Also, if a late CPU needs KPTI but KPTI was not
activated at b
KPTI is treated as a system wide feature and is only detected if all
the CPUs in the sysetm needs the defense, unless it is forced via kernel
command line. This leaves a system with a mix of CPUs with and without
the defense vulnerable. Also, if a late CPU needs KPTI but KPTI was not
activated at b
On 2017-12-26 10:29:20 [+], Ard Biesheuvel wrote:
> As reported by Sebastian, the way the arm64 NEON crypto code currently
> keeps kernel mode NEON enabled across calls into skcipher_walk_xxx() is
…
> So let's clean this up for arm64: update the NEON based skcipher drivers to
> no longer keep t
On Fri, Feb 9, 2018 at 7:39 AM, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 4.14.19 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
Is it
Now that we have the flexibility of defining system features based
on individual CPUs, introduce CPU feature type that can be detected
on a local SCOPE and ignores the conflict on late CPUs. This is
applicable for ARM64_HAS_NO_HW_PREFETCH, where it is fine for
the system to have CPUs without hardwa
We expect all CPUs to be running at the same EL inside the kernel
with or without VHE enabled and we have strict checks to ensure
that any mismatch triggers a kernel panic. If VHE is enabled,
we use the feature based on the boot CPU and all other CPUs
should follow. This makes it a perfect candidat
Add helpers for checking if the given CPU midr falls in a range
of variants/revisions for a given model.
Cc: Will Deacon
Cc: Mark Rutland
Reviewed-by: Dave Martin
Signed-off-by: Suzuki K Poulose
---
arch/arm64/include/asm/cpufeature.h | 7 ++-
arch/arm64/include/asm/cputype.h| 30 +++
Add helpers for checking if the given CPU midr falls in a range
of variants/revisions for a given model.
Cc: Will Deacon
Cc: Mark Rutland
Reviewed-by: Dave Martin
Signed-off-by: Suzuki K Poulose
---
arch/arm64/include/asm/cpufeature.h | 7 ++-
arch/arm64/include/asm/cputype.h| 30 +++
We are about to introduce generic MIDR range helpers. Clean
up the existing helpers in erratum handling, preparing them
to use generic version.
Cc: Will Deacon
Cc: Mark Rutland
Reviewed-by: Dave Martin
Signed-off-by: Suzuki K Poulose
---
arch/arm64/kernel/cpu_errata.c | 100 ++
Some capabilities have different criteria for detection and associated
actions based on the matching criteria, even though they all share the
same capability bit. So far we have used multiple entries with the same
capability bit to handle this. This is prone to errors, as the
cpu_enable is invoked
Add helpers for detecting an errata on list of midr ranges
of affected CPUs, with the same work around.
Cc: Will Deacon
Cc: Mark Rutland
Reviewed-by: Dave Martin
Signed-off-by: Suzuki K Poulose
---
arch/arm64/include/asm/cpufeature.h | 1 +
arch/arm64/include/asm/cputype.h| 8 +
arc
Some capabilities have different criteria for detection and associated
actions based on the matching criteria, even though they all share the
same capability bit. So far we have used multiple entries with the same
capability bit to handle this. This is prone to errors, as the
cpu_enable is invoked
Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer
from an erratum 1024718, which causes incorrect updates when DBM/AP
bits in a page table entry is modified without a break-before-make
sequence. The work around is to skip enabling the hardware DBM feature
on the affected cores. The
We enable hardware DBM bit in a capable CPU, very early in the
boot via __cpu_setup. This doesn't give us a flexibility of
optionally disable the feature, as the clearing the bit
is a bit costly as the TLB can cache the settings. Instead,
we delay enabling the feature until the CPU is brought up
in
We enable hardware DBM bit in a capable CPU, very early in the
boot via __cpu_setup. This doesn't give us a flexibility of
optionally disable the feature, as the clearing the bit
is a bit costly as the TLB can cache the settings. Instead,
we delay enabling the feature until the CPU is brought up
in
Update the MIDR encodings for the Cortex-A55 and Cortex-A35
Cc: Mark Rutland
Reviewed-by: Dave Martin
Signed-off-by: Suzuki K Poulose
---
arch/arm64/include/asm/cputype.h | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer
from an erratum 1024718, which causes incorrect updates when DBM/AP
bits in a page table entry is modified without a break-before-make
sequence. The work around is to skip enabling the hardware DBM feature
on the affected cores. The
The kernel detects and uses some of the features based on the boot
CPU and expects that all the following CPUs conform to it. e.g,
with VHE and the boot CPU running at EL2, the kernel decides to
keep the kernel running at EL2. If another CPU is brought up without
this capability, we use custom hook
The kernel detects and uses some of the features based on the boot
CPU and expects that all the following CPUs conform to it. e.g,
with VHE and the boot CPU running at EL2, the kernel decides to
keep the kernel running at EL2. If another CPU is brought up without
this capability, we use custom hook
Add helpers for detecting an errata on list of midr ranges
of affected CPUs, with the same work around.
Cc: Will Deacon
Cc: Mark Rutland
Reviewed-by: Dave Martin
Signed-off-by: Suzuki K Poulose
---
arch/arm64/include/asm/cpufeature.h | 1 +
arch/arm64/include/asm/cputype.h| 8 +
arc
We are about to group the handling of all capabilities (features
and errata workarounds). This patch open codes the wrapper routines
to make it easier to merge the handling.
Cc: Dave Martin
Signed-off-by: Suzuki K Poulose
---
arch/arm64/kernel/cpufeature.c | 60 +
We expect all CPUs to be running at the same EL inside the kernel
with or without VHE enabled and we have strict checks to ensure
that any mismatch triggers a kernel panic. If VHE is enabled,
we use the feature based on the boot CPU and all other CPUs
should follow. This makes it a perfect candidat
Right now we run through the errata workarounds check on all boot
active CPUs, with SCOPE_ALL. This doesn't help with detecting the
errata's with a SYSTEM_SCOPE. While nobody uses it, let us clean
this up in preparation for merging capability handling.
So, we run the checks with SCOPE_LOCAL_CPU on
Now that each capability describes how to treat the conflicts
of CPU cap state vs System wide cap state, we can unify the
verification logic to a single place.
Reviewed-by: Dave Martin
Signed-off-by: Suzuki K Poulose
---
arch/arm64/kernel/cpufeature.c | 89 ++
We are about to introduce generic MIDR range helpers. Clean
up the existing helpers in erratum handling, preparing them
to use generic version.
Cc: Will Deacon
Cc: Mark Rutland
Reviewed-by: Dave Martin
Signed-off-by: Suzuki K Poulose
---
arch/arm64/kernel/cpu_errata.c | 100 ++
Right now we run through the errata workarounds check on all boot
active CPUs, with SCOPE_ALL. This doesn't help with detecting the
errata's with a SYSTEM_SCOPE. While nobody uses it, let us clean
this up in preparation for merging capability handling.
So, we run the checks with SCOPE_LOCAL_CPU on
Update the MIDR encodings for the Cortex-A55 and Cortex-A35
Cc: Mark Rutland
Reviewed-by: Dave Martin
Signed-off-by: Suzuki K Poulose
---
arch/arm64/include/asm/cputype.h | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
Now that we have the flexibility of defining system features based
on individual CPUs, introduce CPU feature type that can be detected
on a local SCOPE and ignores the conflict on late CPUs. This is
applicable for ARM64_HAS_NO_HW_PREFETCH, where it is fine for
the system to have CPUs without hardwa
We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
to the userspace and the CPU hwcaps used by the kernel, which
include cpu features and CPU errata work arounds. Capabilities
have some properties that decide how they should be treated :
1) Detection, i.e scope : A cap could be "de
From: Dave Martin
We issue the enable() call back for all CPU hwcaps capabilities
available on the system, on all the CPUs. So far we have ignored
the argument passed to the call back, which had a prototype to
accept a "void *" for use with on_each_cpu() and later with
stop_machine(). However, wi
We trigger CPU errata work around check on the boot CPU from
smp_prepare_boot_cpu() to make sure that we run the checks only
after the CPU feature infrastructure is initialised. While this
is correct, we can also do this from init_cpu_features() which
initilises the infrastructure, and is called on
This series reworks the arm64 CPU capabilities handling (which
manages the system features and errata). The current infrastructure
doesn't allow fine control for handling different features or errata.
There is one rule for features and another rule for errata.
* Features are checked only once, aft
Make use of the swap macro and remove unnecessary variable _buf_.
This makes the code easier to read and maintain. Also, reduces the
stack usage.
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
kernel/trace/trace.c | 6 +-
1 file changed, 1 inserti
201 - 300 of 829 matches
Mail list logo
