This patch uses the new update_thread_flag() helper to simplify an
if () set; else clear; construct.
No functional change.
Signed-off-by: Dave Martin
Cc: "David S. Miller"
---
arch/sparc/include/asm/elf_64.h | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/
This patch uses the new update_thread_flag() helpers to simplify a
couple of if () set; else clear; constructs.
No functional change.
Signed-off-by: Dave Martin
Cc: Ralf Baechle
Cc: James Hogan
---
arch/mips/kernel/elf.c | 10 ++
arch/mips/kernel/process.c | 15
This patch uses the new update_thread_flag() helper to simplify a
couple of if () set; else clear; constructs.
No functional change.
Signed-off-by: Dave Martin
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
---
arch/powerpc/include/asm/elf.h | 10 ++
1 file
This patch uses the new update_thread_flag() helpers to simplify a
couple of if () set; else clear; constructs.
No functional change.
Signed-off-by: Dave Martin
Cc: Catalin Marinas
Cc: Will Deacon
---
arch/arm64/kernel/fpsimd.c | 19 +++
1 file changed, 7 insertions(+), 12
This patch uses the new update_thread_flag() helper to simplify an
if () set; else clear; construct.
No functional change.
Signed-off-by: Dave Martin
Cc: Russell King
---
arch/arm/kernel/elf.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/kernel/elf.c b
, cond)
which do the equivalent of:
if (cond)
set*_thread_flag([...,] flag);
else
clear*_thread_flag([...,] flag);
Signed-off-by: Dave Martin
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Steven Rostedt
Cc: Oleg Nesterov
---
Note, this patch assumes
p.
The core changes are in the first patch; other changes are split
per-arch.
Dave Martin (6):
thread_info: Add update_thread_flag() helpers
ARM: Use update_thread_flag()
arm64: Use update{,_tsk}_thread_flag()
MIPS: Use update{,_tsk}_thread_flag()
powerpc: Use update_thread
On Tue, Jul 26, 2016 at 05:55:43PM +0100, Catalin Marinas wrote:
> On Tue, Jul 26, 2016 at 10:50:08AM +0100, Daniel Thompson wrote:
> > On 25/07/16 18:13, Catalin Marinas wrote:
> > >On Fri, Jul 22, 2016 at 11:51:32AM -0400, David Long wrote:
> > >>OK, it sounds like an improvement. I do worry a li
On Wed, Jul 27, 2016 at 12:19:59PM +0100, Daniel Thompson wrote:
[...]
> It is interesting to note that you force large_func() to stack its arguments
> (by providing 8 dummy int arguments first) then the implicit
> pass-by-reference behavior is still preserved even for a stacked argument;
> large
On Wed, Nov 30, 2016 at 03:15:01PM +, Suzuki K Poulose wrote:
> Here is a sample program which demonstrates how to use mrs
> emulation to fetch the ID registers.
Are we planning to add this in Documentation/? If so, we might want
some tweaks (noted below).
>
> 8>
> /*
> * Sample pr
isters, or (more rarely) P-registers or FFR would be
unexpectedly replaced with zeros or stale data belonging to the same
task.
Thus I have seen no evidence that suggests non-SVE systems can be
affected, but it's difficult to say for certain.
I have a strong suspicion that the complexit
}_task_vl() will be fleshed out
with actual functionality in subsequent patches.
Signed-off-by: Dave Martin
---
arch/arm64/include/asm/fpsimd.h| 16
arch/arm64/include/asm/processor.h | 4
arch/arm64/kernel/fpsimd.c | 13 +
include/uapi/linux/prctl.h
This patch adds initial documentation of the ABI provided by the
kernel to enable userspace software to make use of SVE.
Signed-off-by: Dave Martin
---
Documentation/arm64/sve.txt | 475
1 file changed, 475 insertions(+)
create mode 100644
-- this behaviour will be refined in susequent
patches.
Signed-off-by: Dave Martin
---
arch/arm64/include/asm/fpsimd.h | 3 ++
arch/arm64/kernel/fpsimd.c | 65 +++--
2 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm
On Wed, Sep 16, 2015 at 03:20:58PM +0100, Suzuki K. Poulose wrote:
> From: "Suzuki K. Poulose"
>
> This is an updated reincarnation of my "arm64: Expose CPU feature registers"
> series [1], which does much more.
[...]
Do you get whitespace errors for some patches in this series?
git am complai
On Wed, Sep 16, 2015 at 03:21:05PM +0100, Suzuki K. Poulose wrote:
> From: "Suzuki K. Poulose"
>
> This patch adds an infrastructure to keep track of the CPU feature
> registers on the system. For each register, the infrastructure keeps
> track of the system wide safe value of the feature bits. A
On Tue, Sep 22, 2015 at 04:14:21PM +0800, chenfeng wrote:
> Hi all,
> The sparse memory section size, SECTION_SIZE_BITS, currently is 1GB
> for arm64 by default. However, it might generate wasted memmap memory
> space for those memory sections less than 1GB. e.g.
>
> for 512MB memory section, stil
cted, otherwise
show_stack() is used as a fallback.
Signed-off-by: Dave Martin
---
For arches that don't need anything except the stack pointer to
start the backtrace, we might be able to define a generic
arch_dump_backtrace() that invokes show_stack with sp instead of
just assuming the sp is
On Wed, May 27, 2020 at 10:55:29AM +0100, Will Deacon wrote:
> On Sun, May 24, 2020 at 02:56:35AM -0400, Keno Fischer wrote:
> > Just ran into this issue again, with what I think may be most compelling
> > example yet why this is problematic:
> >
> > The tracee incurred a signal, we PTRACE_SYSEMU'
On Tue, May 26, 2020 at 09:45:05PM +0100, Will Deacon wrote:
> On Tue, 26 May 2020 10:31:14 -0700, Nick Desaulniers wrote:
> > Custom toolchains that modify the default target to -mthumb cannot
It's probably too late to water this down, but it's unfortunate to have
this comment in the upstream com
On Wed, Jun 24, 2020 at 04:26:46PM +0100, Will Deacon wrote:
> On Wed, Jun 24, 2020 at 02:48:55PM +0100, Dave Martin wrote:
> > On Wed, Jun 24, 2020 at 12:26:47PM +0100, Will Deacon wrote:
> > > On Wed, Jun 24, 2020 at 12:46:32PM +0200, Ard Biesheuvel wrote:
> > > >
On Wed, Jun 24, 2020 at 05:48:41PM +0200, Ard Biesheuvel wrote:
> On Wed, 24 Jun 2020 at 17:45, Kees Cook wrote:
> >
> > On Wed, Jun 24, 2020 at 05:31:06PM +0200, Ard Biesheuvel wrote:
> > > On Wed, 24 Jun 2020 at 17:21, Kees Cook wrote:
> > > >
> > > > On Wed, Jun 24, 2020 at 12:46:32PM +0200, A
On Wed, Jun 24, 2020 at 06:40:48PM +0200, Ard Biesheuvel wrote:
> On Wed, 24 Jun 2020 at 18:29, Dave Martin wrote:
> >
> > On Wed, Jun 24, 2020 at 05:48:41PM +0200, Ard Biesheuvel wrote:
> > > On Wed, 24 Jun 2020 at 17:45, Kees Cook wrote:
> > > >
> > &g
On Thu, Jun 11, 2020 at 03:11:02PM +0100, Catalin Marinas wrote:
> On Thu, Jun 11, 2020 at 06:42:12PM +0900, Wooyeon Kim wrote:
> > I am in charge of camera driver development in Samsung S.LSI division.
> >
> > In order to guarantee real time processing such as Camera 3A algorithm in
> > current o
On Wed, Sep 30, 2020 at 07:04:53PM +0800, Leo Yan wrote:
[...]
> > > > > >> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > > > > >> b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > > > > >> index a033f34846a6..f0c369259554 100644
> > > > > >> --- a/tools/perf/u
On Tue, Sep 29, 2020 at 01:57:43PM -0700, Chang S. Bae wrote:
> Signal frames do not have a fixed format and can vary in size when a number
> of things change: support XSAVE features, 32 vs. 64-bit apps. Add the code
> to support a runtime method for userspace to dynamically discover how large
> a
On Tue, Sep 29, 2020 at 01:57:42PM -0700, Chang S. Bae wrote:
> During signal entry, the kernel pushes data onto the normal userspace
> stack. On x86, the data pushed onto the user stack includes XSAVE state,
> which has grown over time as new features and larger registers have been
> added to the
On Mon, Oct 05, 2020 at 10:17:06PM +0100, H.J. Lu wrote:
> On Mon, Oct 5, 2020 at 6:45 AM Dave Martin wrote:
> >
> > On Tue, Sep 29, 2020 at 01:57:42PM -0700, Chang S. Bae wrote:
> > > During signal entry, the kernel pushes data onto the normal userspace
> > > st
On Mon, Oct 05, 2020 at 02:24:47PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 10/5/20 1:54 PM, Ard Biesheuvel wrote:
> >On Mon, 5 Oct 2020 at 20:18, Jeremy Linton wrote:
> >>
> >>The AES code uses a 'br x7' as part of a function called by
> >>a macro, that ends up needing a BTI_J as a target.
> >
>
On Tue, Oct 06, 2020 at 09:27:48AM +0100, Will Deacon wrote:
> On Mon, Oct 05, 2020 at 10:48:54PM -0500, Jeremy Linton wrote:
> > The AES code uses a 'br x7' as part of a function called by
> > a macro. That branch needs a bti_j as a target. This results
> > in a panic as seen below. Instead of try
On Tue, Oct 06, 2020 at 11:25:11AM +0100, Catalin Marinas wrote:
> On Tue, Oct 06, 2020 at 11:01:21AM +0100, Dave P Martin wrote:
> > On Tue, Oct 06, 2020 at 09:27:48AM +0100, Will Deacon wrote:
> > > On Mon, Oct 05, 2020 at 10:48:54PM -0500, Jeremy Linton wrote:
> > > > The AES code uses a 'br x7'
On Tue, Oct 06, 2020 at 05:12:29AM -0700, H.J. Lu wrote:
> On Tue, Oct 6, 2020 at 2:25 AM Dave Martin wrote:
> >
> > On Mon, Oct 05, 2020 at 10:17:06PM +0100, H.J. Lu wrote:
> > > On Mon, Oct 5, 2020 at 6:45 AM Dave Martin wrote:
> > > >
> > > > O
On Tue, Oct 06, 2020 at 08:18:03AM -0700, H.J. Lu wrote:
> On Tue, Oct 6, 2020 at 5:12 AM H.J. Lu wrote:
> >
> > On Tue, Oct 6, 2020 at 2:25 AM Dave Martin wrote:
> > >
> > > On Mon, Oct 05, 2020 at 10:17:06PM +0100, H.J. Lu wrote:
> > > > On M
On Tue, Oct 06, 2020 at 08:34:06AM -0700, H.J. Lu wrote:
> On Tue, Oct 6, 2020 at 8:25 AM Dave Martin wrote:
> >
> > On Tue, Oct 06, 2020 at 05:12:29AM -0700, H.J. Lu wrote:
> > > On Tue, Oct 6, 2020 at 2:25 AM Dave Martin wrote:
> > > >
> > > > O
On Tue, Oct 06, 2020 at 08:33:47AM -0700, Dave Hansen wrote:
> On 10/6/20 8:25 AM, Dave Martin wrote:
> > Or are people reporting real stack overruns on x86 today?
>
> We have real overruns. We have ~2800 bytes of XSAVE (regisiter) state
> mostly from AVX-512, and a 2048 byte M
On Tue, Sep 29, 2020 at 10:19:02AM +0800, Leo Yan wrote:
> On Mon, Sep 28, 2020 at 03:47:56PM +0100, Dave Martin wrote:
> > On Mon, Sep 28, 2020 at 02:59:34PM +0100, André Przywara wrote:
> > > On 28/09/2020 14:21, Dave Martin wrote:
> > >
> > > Hi Dave,
>
On Tue, Aug 25, 2020 at 04:34:27PM -0700, Yu, Yu-cheng wrote:
> On 8/25/2020 4:20 PM, Dave Hansen wrote:
> >On 8/25/20 2:04 PM, Yu, Yu-cheng wrote:
> I think this is more arch-specific. Even if it becomes a new syscall,
> we still need to pass the same parameters.
> >>>
> >>>Right, but wit
On Wed, Aug 26, 2020 at 06:51:48PM +0200, Florian Weimer wrote:
> * Dave Martin:
>
> > On Tue, Aug 25, 2020 at 04:34:27PM -0700, Yu, Yu-cheng wrote:
> >> On 8/25/2020 4:20 PM, Dave Hansen wrote:
> >> >On 8/25/20 2:04 PM, Yu, Yu-cheng wrote:
> >> >>&
> crypto_skcipher_encrypt+0x50/0x84
> test_skcipher_vec_cfg+0x224/0x5f0
> test_skcipher+0xbc/0x120
> alg_test_skcipher+0xa0/0x1b0
> alg_test+0x3dc/0x47c
> cryptomgr_test+0x38/0x60
>
> Fixes: 0e89640b640d ("crypto: arm64 - Use modern annotations for assembly
On Tue, Oct 06, 2020 at 05:45:24PM +, Bae, Chang Seok wrote:
> On Mon, 2020-10-05 at 14:42 +0100, Dave Martin wrote:
> > On Tue, Sep 29, 2020 at 01:57:43PM -0700, Chang S. Bae wrote:
> > >
> > > +/*
> > > + * The FP state frame contains an XSAVE buffer
On Tue, Oct 06, 2020 at 08:21:00PM +0200, Florian Weimer wrote:
> * Dave Martin via Libc-alpha:
>
> > On Tue, Oct 06, 2020 at 08:33:47AM -0700, Dave Hansen wrote:
> >> On 10/6/20 8:25 AM, Dave Martin wrote:
> >> > Or are people reporting real stack overruns on x
On Tue, Oct 06, 2020 at 11:30:42AM -0700, Dave Hansen wrote:
> On 10/6/20 10:00 AM, Dave Martin wrote:
> > On Tue, Oct 06, 2020 at 08:33:47AM -0700, Dave Hansen wrote:
> >> On 10/6/20 8:25 AM, Dave Martin wrote:
> >>> Or are people reporting real stack overruns o
On Tue, Oct 06, 2020 at 10:44:14AM -0700, H.J. Lu wrote:
> On Tue, Oct 6, 2020 at 9:55 AM Dave Martin wrote:
> >
> > On Tue, Oct 06, 2020 at 08:34:06AM -0700, H.J. Lu wrote:
> > > On Tue, Oct 6, 2020 at 8:25 AM Dave Martin wrote:
> > > >
> > > > O
On Wed, Oct 07, 2020 at 06:30:03AM -0700, H.J. Lu wrote:
> On Wed, Oct 7, 2020 at 3:47 AM Dave Martin wrote:
> >
> > On Tue, Oct 06, 2020 at 10:44:14AM -0700, H.J. Lu wrote:
[...]
> > > I updated my glibc patch to add both _SC_MINSIGSTKSZ and _SC_SIGSTKSZ.
> > >
On Tue, Sep 29, 2020 at 10:19:02AM +0800, Leo Yan wrote:
> On Mon, Sep 28, 2020 at 03:47:56PM +0100, Dave Martin wrote:
> > On Mon, Sep 28, 2020 at 02:59:34PM +0100, André Przywara wrote:
> > > On 28/09/2020 14:21, Dave Martin wrote:
> > >
> > > Hi Dave,
>
On Thu, Oct 08, 2020 at 10:43:50PM +, Bae, Chang Seok wrote:
> On Wed, 2020-10-07 at 11:05 +0100, Dave Martin wrote:
> > On Tue, Oct 06, 2020 at 05:45:24PM +, Bae, Chang Seok wrote:
> > > On Mon, 2020-10-05 at 14:42 +0100, Dave Martin wrote:
> > > > On Tue, Se
On Tue, Sep 22, 2020 at 11:12:25AM +0100, Andre Przywara wrote:
> The Scalable Vector Extension (SVE) is an ARMv8 architecture extension
> that introduces very long vector operations (up to 2048 bits).
(8192, in fact, though don't expect to see that on real hardware any
time soon... qemu and the
On Mon, Sep 28, 2020 at 02:59:34PM +0100, André Przywara wrote:
> On 28/09/2020 14:21, Dave Martin wrote:
>
> Hi Dave,
>
> > On Tue, Sep 22, 2020 at 11:12:25AM +0100, Andre Przywara wrote:
> >> The Scalable Vector Extension (SVE) is an ARMv8 architecture extension
>
On Thu, May 07, 2020 at 06:59:10PM +0530, Anshuman Khandual wrote:
> All HWCAP name arrays (i.e hwcap_str, compat_hwcap_str, compat_hwcap2_str)
> that are scanned for /proc/cpuinfo output are detached from their bit fild
> definitions making it difficult to corelate. This is also bit problematic
>
On Mon, May 11, 2020 at 11:04:03PM +0100, Cristian Marussi wrote:
> Hi Dave
>
> thanks for the review first of all.
>
> On Wed, May 06, 2020 at 04:25:50PM +0100, Dave Martin wrote:
> > On Mon, May 04, 2020 at 05:38:47PM +0100, Cristian Marussi wrote:
> > > Add co
On Fri, Jun 05, 2020 at 11:37:05AM +0100, Mark Rutland wrote:
> Hi Wooyeon,
>
> There are a *lot* of people Cc' here, many of whomo will find this
> irrelevant. Please try to keep the Cc list constrained to a reasonable
> number of interested parties.
>
> On Fri, Jun 05, 2020 at 04:30:52PM +0900,
On Fri, Aug 28, 2020 at 02:16:02PM +0100, Boyan Karatotev wrote:
> Pointer Authentication (PAuth) is a security feature introduced in ARMv8.3.
> It introduces instructions to sign addresses and later check for potential
> corruption using a second modifier value and one of a set of keys. The
> sign
On Fri, Aug 28, 2020 at 02:16:03PM +0100, Boyan Karatotev wrote:
> PAuth signs and verifies return addresses on the stack. It does so by
> inserting a Pointer Authentication code (PAC) into some of the unused top
> bits of an address. This is achieved by adding paciasp/autiasp instructions
> at the
On Fri, Aug 28, 2020 at 02:16:05PM +0100, Boyan Karatotev wrote:
> Kernel documentation states that it will change PAuth keys on exec() calls.
>
> Verify that all keys are correctly switched to new ones.
>
> Cc: Shuah Khan
> Cc: Catalin Marinas
> Cc: Will Deacon
> Signed-off-by: Boyan Karatote
On Mon, Aug 31, 2020 at 12:04:49PM +0100, Boyan Karatotev wrote:
> Kernel documentation states that it will change PAuth keys on exec() calls.
>
> Verify that all keys are correctly switched to new ones.
>
> Cc: Shuah Khan
> Cc: Catalin Marinas
> Cc: Will Deacon
> Reviewed-by: Vincenzo Frascin
On Tue, Sep 01, 2020 at 11:11:37AM -0700, Dave Hansen wrote:
> On 9/1/20 10:45 AM, Andy Lutomirski wrote:
> >>> For arm64 (and sparc etc.) we continue to use the regular mmap/mprotect
> >>> family of calls. One or two additional arch-specific mmap flags are
> >>> sufficient for now.
> >>>
> >>> Is
On Thu, Sep 03, 2020 at 11:12:02AM +0100, Boyan Karatotev wrote:
> On 02/09/2020 17:49, Dave Martin wrote:
> > On Fri, Aug 28, 2020 at 02:16:03PM +0100, Boyan Karatotev wrote:
> >> PAuth signs and verifies return addresses on the stack. It does so by
> >> inserting a
On Thu, Sep 03, 2020 at 11:20:25AM +0100, Boyan Karatotev wrote:
> On 02/09/2020 18:00, Dave Martin wrote:
> > On Fri, Aug 28, 2020 at 02:16:05PM +0100, Boyan Karatotev wrote:
> >> Kernel documentation states that it will change PAuth keys on exec() calls.
> >>
&g
On Thu, Sep 03, 2020 at 10:46:33AM +0100, Boyan Karatotev wrote:
> On 02/09/2020 17:48, Dave Martin wrote:
> > On Fri, Aug 28, 2020 at 02:16:02PM +0100, Boyan Karatotev wrote:
> >> Pointer Authentication (PAuth) is a security feature introduced in ARMv8.3.
> >> It intr
On Thu, Sep 03, 2020 at 11:48:37AM +0100, Boyan Karatotev wrote:
> On 02/09/2020 18:08, Dave Martin wrote:
> > On Mon, Aug 31, 2020 at 12:04:49PM +0100, Boyan Karatotev wrote:
> >> +/*
> >> + * fork() does not change keys. Only exec() does so call a worker program.
>
On Thu, Aug 27, 2020 at 06:26:11AM -0700, H.J. Lu wrote:
> On Wed, Aug 26, 2020 at 12:57 PM Dave Hansen wrote:
> >
> > On 8/26/20 11:49 AM, Yu, Yu-cheng wrote:
> > >> I would expect things like Go and various JITs to call it directly.
> > >>
> > >> If we wanted to be fancy and add a potentially mo
On Mon, Oct 26, 2020 at 05:45:42PM +0100, Florian Weimer via Libc-alpha wrote:
> * Dave Martin via Libc-alpha:
>
> > Would it now help to add something like:
> >
> > int mchangeprot(void *addr, size_t len, int old_flags, int new_flags)
> > {
> > int re
This patch also moves the variable 'blen' as the function's local
> variable, this allows to remove the unnecessary braces and improve the
> readability.
>
> Suggested-by: Dave Martin
> Signed-off-by: Leo Yan
> Reviewed-by: Andre Przywara
> ---
> .../ar
On Mon, Oct 26, 2020 at 05:39:42PM -0500, Jeremy Linton via Libc-alpha wrote:
> Hi,
>
> On 10/26/20 12:52 PM, Dave Martin wrote:
> >On Mon, Oct 26, 2020 at 04:57:55PM +, Szabolcs Nagy via Libc-alpha wrote:
> >>The 10/26/2020 16:24, Dave Martin via Libc-alpha wr
On Mon, Oct 26, 2020 at 02:52:46PM +, Catalin Marinas via Libc-alpha wrote:
> On Sat, Oct 24, 2020 at 02:01:30PM +0300, Topi Miettinen wrote:
> > On 23.10.2020 12.02, Catalin Marinas wrote:
> > > On Thu, Oct 22, 2020 at 01:02:18PM -0700, Kees Cook wrote:
> > > > Regardless, it makes sense to me
On Wed, Oct 21, 2020 at 10:44:46PM -0500, Jeremy Linton via Libc-alpha wrote:
> Hi,
>
> There is a problem with glibc+systemd on BTI enabled systems. Systemd
> has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny
> PROT_EXEC changes. Glibc enables BTI only on segments which are m
On Mon, Oct 26, 2020 at 04:57:55PM +, Szabolcs Nagy via Libc-alpha wrote:
> The 10/26/2020 16:24, Dave Martin via Libc-alpha wrote:
> > Unrolling this discussion a bit, this problem comes from a few sources:
> >
> > 1) systemd is trying to implement a policy tha
7;blen' as the function's local
> variable, this allows to remove the unnecessary braces and improve the
> readability.
>
> Suggested-by: Dave Martin
> Signed-off-by: Leo Yan
> Reviewed-by: Andre Przywara
Mostly looks fine to me now, thought there are a few potention
On Wed, Nov 11, 2020 at 03:53:20PM +, Dave Martin wrote:
> On Wed, Nov 11, 2020 at 07:11:33AM +, Leo Yan wrote:
> > When outputs strings to the decoding buffer with function snprintf(),
> > SPE decoder needs to detects if any error returns from snprintf() and if
> >
ailing out in switch-cases,
> it returns error at the end of arm_spe_pkt_desc().
>
> This patch changes the caller arm_spe_dump() to respect the updated
> return value semantics of arm_spe_pkt_desc().
>
> Suggested-by: Dave Martin
> Signed-off-by: Leo Yan
>
> >> arm_spe_pkt_snprintf() which is used to wrap up the complex logics, and
> > >> it's used by the caller arm_spe_pkt_desc().
> > >>
> > >> This patch also moves the variable 'blen' as the function's local
> > >> variable,
On Thu, Oct 29, 2020 at 11:02:22AM +, Catalin Marinas via Libc-alpha wrote:
> On Tue, Oct 27, 2020 at 02:15:22PM +, Dave P Martin wrote:
> > I also wonder whether we actually care whether the pages are marked
> > executable or not here; probably the flags can just be independent. This
> >
struct arm_spe_pkt {
>
> #define SPE_ADDR_PKT_GET_NS(v) (((v) & BIT_ULL(63)) >>
> 63)
> #define SPE_ADDR_PKT_GET_EL(v) (((v) & GENMASK_ULL(62,
> 61)) >> 61)
> +#define SPE_ADDR_PKT_GET_CH(v)
imes in a flow, the error is a cumulative value and simply
> returns its final value.
>
> This patch also moves the variable 'blen' as the function's local
> variable, this allows to remove the unnecessary braces and improve the
> readability.
>
> Suggested-by:
On Tue, Nov 03, 2020 at 10:13:49AM +, André Przywara wrote:
> On 03/11/2020 06:40, Leo Yan wrote:
>
> Hi Dave, Leo,
>
> > On Mon, Nov 02, 2020 at 05:06:53PM +, Dave Martin wrote:
> >> On Fri, Oct 30, 2020 at 02:57:09AM +, Leo Yan wrote:
> >>&g
On Tue, Nov 03, 2020 at 06:51:01AM +, Leo Yan wrote:
> On Mon, Nov 02, 2020 at 04:25:36PM +0000, Dave Martin wrote:
> > On Fri, Oct 30, 2020 at 02:57:23AM +, Leo Yan wrote:
> > > From: Andre Przywara
> > >
> > > When SPE records a physical addres
On Thu, Jul 02, 2020 at 08:23:02AM +0100, Will Deacon wrote:
> On Wed, Jul 01, 2020 at 06:07:25PM +0100, Dave P Martin wrote:
> > On Tue, Jun 30, 2020 at 06:37:34PM +0100, Will Deacon wrote:
> > > When building with LTO, there is an increased risk of the compiler
> > > converting an address depende
On Tue, Jun 30, 2020 at 06:37:34PM +0100, 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 a control dependency and consequently allowing for harmful
> reordering by the CPU.
>
> Ens
On Mon, Jul 06, 2020 at 09:34:55AM -0700, Paul E. McKenney wrote:
> On Mon, Jul 06, 2020 at 05:00:23PM +0100, Dave Martin wrote:
> > On Thu, Jul 02, 2020 at 08:23:02AM +0100, Will Deacon wrote:
> > > On Wed, Jul 01, 2020 at 06:07:25PM +0100, Dave P Martin wrote:
> > > &
On Fri, Jul 03, 2020 at 01:51:10PM -0700, Randy Dunlap wrote:
> Drop the doubled word "for".
>
> Signed-off-by: Randy Dunlap
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: linux-arm-ker...@lists.infrad
On Sat, Jul 04, 2020 at 04:02:46PM +0200, Greg Kroah-Hartman wrote:
> Here is a tiny new syscall, readfile, that makes it simpler to read
> small/medium sized files all in one shot, no need to do open/read/close.
> This is especially helpful for tools that poke around in procfs or
> sysfs, making a
On Mon, Jul 06, 2020 at 07:35:11PM +0100, Will Deacon wrote:
> On Mon, Jul 06, 2020 at 05:08:20PM +0100, Dave Martin wrote:
> > On Tue, Jun 30, 2020 at 06:37:34PM +0100, Will Deacon wrote:
> > > diff --git a/arch/arm64/include/asm/rwonce.h
> > > b/arch/arm64/include/
On Mon, Jul 06, 2020 at 10:36:28AM -0700, Paul E. McKenney wrote:
> On Mon, Jul 06, 2020 at 06:05:57PM +0100, Dave Martin wrote:
> > On Mon, Jul 06, 2020 at 09:34:55AM -0700, Paul E. McKenney wrote:
> > > On Mon, Jul 06, 2020 at 05:00:23PM +0100, Dave Martin wrote:
> > >
On Tue, Sep 15, 2020 at 04:18:28PM +0100, Boyan Karatotev wrote:
> On 07/09/2020 11:27 am, Dave Martin wrote:
> > On Thu, Sep 03, 2020 at 11:20:25AM +0100, Boyan Karatotev wrote:
> >> On 02/09/2020 18:00, Dave Martin wrote:
> >>> On Fri, Aug 28, 2020 at 02:16:05P
-fno-stack-protector
>
> Use cc-disable-warning so that it gets disabled for GCC and does nothing
> for Clang.
>
> Fixes: ebcc5928c5d9 ("arm64: Silence gcc warnings about arch ABI drift")
> Link: https://github.com/ClangBuiltLinux/linux/issues/511
> Reported-by: Q
On Tue, Jun 11, 2019 at 12:31:34PM -0700, Yu-cheng Yu wrote:
> On Tue, 2019-06-11 at 12:41 +0100, Dave Martin wrote:
> > On Mon, Jun 10, 2019 at 07:24:43PM +0200, Florian Weimer wrote:
> > > * Yu-cheng Yu:
> > >
> > > > To me, looking at PT_GNU_PROPERT
On Wed, Jun 12, 2019 at 12:04:01PM -0700, Yu-cheng Yu wrote:
> On Wed, 2019-06-12 at 10:32 +0100, Dave Martin wrote:
> > On Tue, Jun 11, 2019 at 12:31:34PM -0700, Yu-cheng Yu wrote:
> > > On Tue, 2019-06-11 at 12:41 +0100, Dave Martin wrote:
> > > > On Mon, Ju
On Thu, Jun 13, 2019 at 01:28:21PM +0100, Catalin Marinas wrote:
> On Thu, Jun 13, 2019 at 12:37:32PM +0100, Dave P Martin wrote:
> > On Thu, Jun 13, 2019 at 11:15:34AM +0100, Vincenzo Frascino wrote:
> > > On 12/06/2019 16:35, Catalin Marinas wrote:
> > > > On Wed, Jun 12, 2019 at 03:21:10PM +0100
On Thu, Jun 13, 2019 at 11:15:34AM +0100, Vincenzo Frascino wrote:
> Hi Catalin,
>
> On 12/06/2019 16:35, Catalin Marinas wrote:
> > Hi Vincenzo,
> >
> > Some minor comments below but it looks fine to me overall. Cc'ing
> > Szabolcs as well since I'd like a view from the libc people.
> >
>
> Th
On Wed, Jun 12, 2019 at 01:43:20PM +0200, Andrey Konovalov wrote:
> From: Catalin Marinas
>
> It is not desirable to relax the ABI to allow tagged user addresses into
> the kernel indiscriminately. This patch introduces a prctl() interface
> for enabling or disabling the tagged ABI with a global
On Thu, Jun 13, 2019 at 06:38:01PM +0200, Anisse Astier wrote:
> Otherwise this will create userspace build issues for any program
> (strace, qemu) that includes both (with musl libc) and
> (which then includes ), like this:
>
> error: redefinition of 'struct prctl_mm_map'
>struct
On Tue, May 28, 2019 at 06:18:16PM +0530, Amit Daniel Kachhap wrote:
> Hi Dave,
[...]
> >Were you planning to repost this?
> >
> >Alternatively, I can fix up the diagnostic messages discussed here and
> >post it together with the SVE support. I'll do that locally for now,
> >but let me know what
On Thu, Apr 11, 2019 at 04:58:41PM +0100, Julien Grall wrote:
> Hi Dave,
>
> On 4/5/19 4:07 PM, Dave Martin wrote:
> >On Fri, Apr 05, 2019 at 10:02:45AM +0100, Julien Grall wrote:
> >>>>+#ifdef CONFIG_KERNEL_MODE_NEON
> >>>>+
> >>>>
On Mon, May 04, 2020 at 05:38:47PM +0100, Cristian Marussi wrote:
> Add core SCMI Notifications protocol-registration support: allow protocols
> to register their own set of supported events, during their initialization
> phase. Notification core can track multiple platform instances by their
> han
On Wed, Jun 24, 2020 at 10:38:48AM +0100, Catalin Marinas wrote:
> On Tue, Jun 23, 2020 at 07:05:07PM +0100, Peter Maydell wrote:
> > On Wed, 17 Jun 2020 at 13:39, Steven Price wrote:
> > > These patches add support to KVM to enable MTE within a guest. It is
> > > based on Catalin's v4 MTE user sp
On Wed, Jun 24, 2020 at 12:26:47PM +0100, Will Deacon wrote:
> On Wed, Jun 24, 2020 at 12:46:32PM +0200, Ard Biesheuvel wrote:
> > On Wed, 24 Jun 2020 at 12:44, Will Deacon wrote:
> > > On Tue, Jun 23, 2020 at 09:44:11PM -0700, Kees Cook wrote:
> > > > On Tue, Jun 23, 2020 at 08:31:42PM -0700, 'Fa
On Fri, Mar 31, 2017 at 04:28:16PM +0100, Ard Biesheuvel wrote:
> On 22 March 2017 at 14:50, Dave Martin wrote:
>
> Hi Dave,
>
> > The Scalable Vector Extension (SVE) [1] is an extension to AArch64 which
> > adds extra SIMD functionality and supports much larger vect
On Mon, Apr 03, 2017 at 11:01:28AM +0100, Ard Biesheuvel wrote:
> On 3 April 2017 at 10:45, Dave Martin wrote:
> > On Fri, Mar 31, 2017 at 04:28:16PM +0100, Ard Biesheuvel wrote:
[...]
> >> Given the above, I think it is perfectly reasonable to conditionally
> >> d
On Wed, Jul 19, 2017 at 05:01:21PM +0100, Mark Rutland wrote:
> This series adds support for the ARMv8.3 pointer authentication extension.
>
> Since RFC [1]:
> * Make the KVM context switch (semi-lazy)
> * Rebase to v4.13-rc1
> * Improve pointer authentication documentation
> * Add hwcap documenta
s"?
I'm not sure of the history here.
> Signed-off-by: Mark Rutland
> Cc: Catalin Marinas
> Cc: Dave Martin
> Cc: Suzuki K Poulose
> Cc: Will Deacon
> ---
> Documentation/arm64/elf_hwcaps.txt | 133
> +
> 1 file changed,
501 - 600 of 664 matches
Mail list logo
