On Fri, Apr 13, 2018 at 09:33:17AM -0700, Linus Torvalds wrote:
> On Fri, Apr 13, 2018 at 2:42 AM, Russell King - ARM Linux
> wrote:
> >
> > Yes, it does solve the problem at hand with strace - the exact patch I
> > tested against 4.16 is below.
>
> Ok, good.
>
> > However, FPE_FLTUNK is not def
On Fri, Apr 13, 2018 at 06:54:08PM +0100, Russell King - ARM Linux wrote:
> On Fri, Apr 13, 2018 at 06:08:28PM +0100, Dave Martin wrote:
> > On Fri, Apr 13, 2018 at 09:33:17AM -0700, Linus Torvalds wrote:
> > > On Fri, Apr 13, 2018 at 2:42 AM, Russell King - ARM
On Fri, Apr 13, 2018 at 11:23:36AM -0700, Linus Torvalds wrote:
> On Fri, Apr 13, 2018 at 10:54 AM, Russell King - ARM Linux
> wrote:
> >
> > FPE_FLTINV means "floating point invalid operation". Does it really
> > cover the case where hardware has failed, or is it intended to cover
> > the case w
On Fri, Apr 13, 2018 at 07:50:17PM +0100, Russell King - ARM Linux wrote:
> On Fri, Apr 13, 2018 at 07:35:38PM +0100, Dave Martin wrote:
> > If that's the case though, I don't see how a userspace testsuite is
> > hitting this code path. Maybe I've misunderstood
On Sun, Apr 15, 2018 at 10:57:33AM -0500, Eric W. Biederman wrote:
>
> Call clear_siginfo to ensure every stack allocated siginfo is properly
> initialized before being passed to the signal sending functions.
>
> Note: It is not safe to depend on C initializers to initialize struct
> siginfo on t
On Tue, Apr 17, 2018 at 02:37:38PM -0500, Eric W. Biederman wrote:
> Dave Martin writes:
>
> > Hmmm
> >
> > memset()/clear_siginfo() may ensure that there are no uninitialised
> > explicit fields except for those in inactive union members, but I'm not
> >
On Wed, Apr 18, 2018 at 09:22:09AM -0500, Eric W. Biederman wrote:
> Dave Martin writes:
>
> > On Tue, Apr 17, 2018 at 02:37:38PM -0500, Eric W. Biederman wrote:
[...]
> >> My intention is to leave 0 instances of clear_siginfo in the
> >> architecture specific
On Sun, Apr 15, 2018 at 11:16:04AM -0700, Linus Torvalds wrote:
[...]
> The other thing we should do is to get rid of the stupid padding.
> Right now "struct siginfo" is pointlessly padded to 128 bytes. That is
> completely insane, when it's always just zero in the kernel.
Agreed, inside the ker
Hi,
On Fri, May 03, 2024 at 02:01:22PM +0100, Joey Gouly wrote:
> Allow EL0 or EL1 to access POR_EL0 without being trapped to EL2.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
> Acked-by: Catalin Marinas
> ---
> arch/arm64/include/asm/el2_setup.h | 10 +-
> 1
On Fri, May 03, 2024 at 02:01:24PM +0100, Joey Gouly wrote:
> POR_EL0 is a register that can be modified by userspace directly,
> so it must be context switched.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
> arch/arm64/include/asm/cpufeature.h | 6 ++
> arc
On Tue, Jul 16, 2024 at 04:17:12PM +0530, Anshuman Khandual wrote:
>
>
> On 5/3/24 18:31, Joey Gouly wrote:
> > Now that PKEYs support has been implemented, enable it for CPUs that
> > support S1POE.
> >
> > Signed-off-by: Joey Gouly
> > Cc: Catalin Marinas
> > Cc: Will Deacon
> > Acked-by: C
On Fri, May 03, 2024 at 02:01:28PM +0100, Joey Gouly wrote:
> Expose a HWCAP and ID_AA64MMFR3_EL1_S1POE to userspace, so they can be used to
> check if the CPU supports the feature.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
>
> This takes the last bit of HWCAP
On Fri, May 03, 2024 at 02:01:31PM +0100, Joey Gouly wrote:
> Modify arch_calc_vm_prot_bits() and vm_get_page_prot() such that the pkey
> value is set in the vm_flags and then into the pgprot value.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
> arch/arm64/includ
On Fri, May 03, 2024 at 02:01:33PM +0100, Joey Gouly wrote:
> If a memory fault occurs that is due to an overlay/pkey fault, report that to
> userspace with a SEGV_PKUERR.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
> arch/arm64/include/asm/traps.h | 1 +
> arc
On Mon, Jun 03, 2024 at 02:51:46PM +0530, Amit Daniel Kachhap wrote:
>
>
> On 5/31/24 22:09, Mark Brown wrote:
> > On Tue, May 28, 2024 at 12:26:54PM +0530, Amit Daniel Kachhap wrote:
> > > On 5/3/24 18:31, Joey Gouly wrote:
> >
> > > > +#define POE_MAGIC 0x504f4530
> > > > +struct poe_cont
Hi,
On Fri, May 03, 2024 at 02:01:36PM +0100, Joey Gouly wrote:
> Add PKEY support to signals, by saving and restoring POR_EL0 from the
> stackframe.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
> Reviewed-by: Mark Brown
> Acked-by: Szabolcs Nagy
> ---
> arch/arm64
Hi,
On Fri, May 03, 2024 at 02:01:37PM +0100, Joey Gouly wrote:
> Now that PKEYs support has been implemented, enable it for CPUs that
> support S1POE.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
> Acked-by: Catalin Marinas
> ---
> arch/arm64/include/asm/pkeys.h | 2
On Fri, May 03, 2024 at 02:01:35PM +0100, Joey Gouly wrote:
> Implement the PKEYS interface, using the Permission Overlay Extension.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
> arch/arm64/include/asm/mmu.h | 1 +
> arch/arm64/include/asm/mmu_context.
On Thu, Jul 25, 2024 at 07:11:41PM +0100, Mark Brown wrote:
> On Thu, Jul 25, 2024 at 04:58:27PM +0100, Dave Martin wrote:
>
> > I'll post a draft patch separately, since I think the update could
> > benefit from separate discussion, but my back-of-the-envelope
> &
On Fri, Jul 26, 2024 at 06:39:27PM +0100, Mark Brown wrote:
> On Fri, Jul 26, 2024 at 05:14:01PM +0100, Dave Martin wrote:
> > On Thu, Jul 25, 2024 at 07:11:41PM +0100, Mark Brown wrote:
>
> > > That'd have to be a variably sized structure with pairs of sysreg
> >
On Thu, Aug 01, 2024 at 11:55:02AM +0100, Joey Gouly wrote:
> On Thu, Jul 25, 2024 at 04:49:50PM +0100, Dave Martin wrote:
> > On Fri, May 03, 2024 at 02:01:31PM +0100, Joey Gouly wrote:
> > > Modify arch_calc_vm_prot_bits() and vm_get_page_prot() such that the pkey
> &g
On Thu, Aug 01, 2024 at 04:54:41PM +0100, Joey Gouly wrote:
> On Thu, Jul 25, 2024 at 05:00:18PM +0100, Dave Martin wrote:
> > Hi,
> >
> > On Fri, May 03, 2024 at 02:01:36PM +0100, Joey Gouly wrote:
> > > Add PKEY support to signals, by saving and restoring POR_
On Thu, Aug 01, 2024 at 05:04:03PM +0100, Joey Gouly wrote:
> On Thu, Jul 25, 2024 at 04:49:08PM +0100, Dave Martin wrote:
> > On Fri, May 03, 2024 at 02:01:28PM +0100, Joey Gouly wrote:
> > > Expose a HWCAP and ID_AA64MMFR3_EL1_S1POE to userspace, so they can be
> > >
Hi,
On Thu, Aug 01, 2024 at 05:01:10PM +0100, Joey Gouly wrote:
> On Thu, Jul 25, 2024 at 04:57:09PM +0100, Dave Martin wrote:
> > On Fri, May 03, 2024 at 02:01:33PM +0100, Joey Gouly wrote:
> > > If a memory fault occurs that is due to an overlay/pkey fault, report
> > &
Hi,
On Tue, Aug 06, 2024 at 02:43:57PM +0100, Joey Gouly wrote:
> On Tue, Aug 06, 2024 at 02:33:37PM +0100, Dave Martin wrote:
> > Hi,
> >
> > On Thu, Aug 01, 2024 at 05:01:10PM +0100, Joey Gouly wrote:
> > > On Thu, Jul 25, 2024 at 04:57:09PM +0100, Dave Martin
On Tue, Aug 06, 2024 at 03:31:03PM +0100, Joey Gouly wrote:
> On Tue, Aug 06, 2024 at 11:35:32AM +0100, Joey Gouly wrote:
> > On Thu, Aug 01, 2024 at 05:22:45PM +0100, Dave Martin wrote:
> > > On Thu, Aug 01, 2024 at 04:54:41PM +0100, Joey Gouly wrote:
> > > > On T
On Thu, Aug 15, 2024 at 02:18:15PM +0100, Joey Gouly wrote:
> Hi Catalin,
>
> On Wed, Aug 14, 2024 at 04:03:47PM +0100, Catalin Marinas wrote:
> > Hi Joey,
> >
> > On Tue, Aug 06, 2024 at 03:31:03PM +0100, Joey Gouly wrote:
> > > diff --git arch/arm64/kernel/signal.c arch/arm64/kernel/signal.c
>
On Tue, Aug 20, 2024 at 10:54:41AM +0100, Joey Gouly wrote:
> On Mon, Aug 19, 2024 at 06:09:06PM +0100, Catalin Marinas wrote:
> > On Thu, Aug 15, 2024 at 04:09:26PM +0100, Dave P Martin wrote:
> > > On Thu, Aug 15, 2024 at 02:18:15PM +0100, Joey Gouly wrote:
> > > > That's a lot of words to say, o
On Tue, Aug 20, 2024 at 03:06:06PM +0100, Joey Gouly wrote:
> On Tue, Aug 20, 2024 at 02:54:50PM +0100, Dave Martin wrote:
> > On Tue, Aug 20, 2024 at 10:54:41AM +0100, Joey Gouly wrote:
> > > On Mon, Aug 19, 2024 at 06:09:06PM +0100, Catalin Marinas wrote:
> > > >
On Tue, Oct 15, 2024 at 12:41:16PM +0100, Will Deacon wrote:
> On Tue, Oct 15, 2024 at 10:59:11AM +0100, Joey Gouly wrote:
> > On Mon, Oct 14, 2024 at 06:10:23PM +0100, Will Deacon wrote:
> > > Kevin, Joey,
> > >
> > > On Wed, Oct 09, 2024 at 03:43:01PM +0100, Will Deacon wrote:
> > > > On Tue, Se
On Tue, Sep 24, 2024 at 01:27:58PM +0200, Kevin Brodsky wrote:
> On 22/08/2024 17:11, Joey Gouly wrote:
> > @@ -1178,6 +1237,9 @@ static void setup_return(struct pt_regs *regs, struct
> > k_sigaction *ka,
> > sme_smstop();
> > }
> >
> > + if (system_supports_poe())
> > +
Hi all,
On Mon, Jan 06, 2025 at 08:48:05AM -0800, Kees Cook wrote:
> On Sat, Jan 04, 2025 at 11:38:34PM +0900, Akihiko Odaki wrote:
> > elf.h had a comment saying:
> > > Notes used in ET_CORE. Architectures export some of the arch register
> > > sets using the corresponding note types via the PTRA
On Sat, Jan 04, 2025 at 11:38:34PM +0900, Akihiko Odaki wrote:
> elf.h had a comment saying:
> > Notes used in ET_CORE. Architectures export some of the arch register
> > sets using the corresponding note types via the PTRACE_GETREGSET and
> > PTRACE_SETREGSET requests.
> > The note name for these
Hi,
On Sat, Jan 04, 2025 at 11:38:38PM +0900, Akihiko Odaki wrote:
> Now KEXEC_CORE_NOTE_NAME is only used at one place and it does not seem
> to provide any value anymore. Replace the remaining usage with the
> literal and remove the macro.
>
> Signed-off-by: Akihiko Odaki
> ---
> arch/s390/ke
Hi,
On Sat, Jan 04, 2025 at 11:38:33PM +0900, Akihiko Odaki wrote:
> elf.h had a comment saying:
> > Notes used in ET_CORE. Architectures export some of the arch register
> > sets using the corresponding note types via the PTRACE_GETREGSET and
> > PTRACE_SETREGSET requests.
> > The note name for t
Hi,
On Tue, Jan 07, 2025 at 09:45:56PM +0900, Akihiko Odaki wrote:
> Use note name macros to match with the userspace's expectation.
>
> Signed-off-by: Akihiko Odaki
> ---
> arch/s390/kernel/crash_dump.c | 62
> ---
> 1 file changed, 23 insertions(+), 39
On Tue, Jan 07, 2025 at 09:45:53PM +0900, Akihiko Odaki wrote:
> Use note name macros to match with the userspace's expectation.
Also (and more importantly) get rid of duplicated knowledge about the
mapping of note types to note names, so that elf.h is the authoritative
source of this information?
On Wed, Jan 08, 2025 at 01:53:51PM +0900, Akihiko Odaki wrote:
> On 2025/01/08 1:17, Dave Martin wrote:
> > Hi,
> >
> > On Tue, Jan 07, 2025 at 09:45:56PM +0900, Akihiko Odaki wrote:
> > > Use note name macros to match with the userspace's expectation.
> &
Hi,
On Wed, Jan 08, 2025 at 01:34:24PM +0900, Akihiko Odaki wrote:
> On 2025/01/08 1:18, Dave Martin wrote:
> > On Tue, Jan 07, 2025 at 09:45:53PM +0900, Akihiko Odaki wrote:
> > > Use note name macros to match with the userspace's expectation.
> >
> > Als
> watchpoint registers */
>
> -/* Note types with note name "GNU" */
> +/* Note used in other file types. */
For this, it may make sense to be vaguer, e.g.
/* Other notes */
(We don't dump NT_GNU_PROPERTY_TYPE_0 in coredumps, but I don't think
it would be nonsensical to do so.)
> +#define NN_GNU_PROPERTY_TYPE_0 "GNU"
> #define NT_GNU_PROPERTY_TYPE_0 5
[...]
With or without those changes,
Reviewed-by: Dave Martin
ypes are not taken from elf.h anyway, I think this is
probably out of scope for this series. I haven't tried to understand
fully what that code is doing.
Anyway:
Reviewed-by: Dave Martin
>
> Acked-by: Baoquan He
> Signed-off-by: Akihiko Odaki
> ---
> arch/powerpc/kerne
On Sat, Jan 11, 2025 at 02:48:45PM +0900, Akihiko Odaki wrote:
> Use note name macros to match with the userspace's expectation.
>
> Signed-off-by: Akihiko Odaki
> Acked-by: Baoquan He
Reviewed-by: Dave Martin
> ---
> fs/binfmt_elf.c | 21 ++---
&
On Sat, Jan 11, 2025 at 02:48:47PM +0900, Akihiko Odaki wrote:
> Use note name macros to match with the userspace's expectation.
>
> Signed-off-by: Akihiko Odaki
> Acked-by: Baoquan He
Reviewed-by: Dave Martin
> ---
> fs/proc/kcore.c | 12 ++
Hi,
On Sat, Jan 11, 2025 at 02:48:48PM +0900, Akihiko Odaki wrote:
> Use note name macros to match with the userspace's expectation.
>
> Signed-off-by: Akihiko Odaki
> Acked-by: Heiko Carstens
Reviewed-by: Dave Martin
(I'm not in a position to test this, though.)
>
Hi,
On Sat, Jan 11, 2025 at 02:48:49PM +0900, Akihiko Odaki wrote:
> KEXEC_CORE_NOTE_NAME is no longer used.
>
> Signed-off-by: Akihiko Odaki
> Acked-by: Baoquan He
Reviewed-by: Dave Martin
> ---
> include/linux/kexec.h | 2 --
> include/linux/vmcore_info.h | 1
Hi,
On Thu, Jan 09, 2025 at 02:29:19PM +0900, Akihiko Odaki wrote:
> On 2025/01/08 22:50, Dave Martin wrote:
> > On Wed, Jan 08, 2025 at 01:53:51PM +0900, Akihiko Odaki wrote:
> > > On 2025/01/08 1:17, Dave Martin wrote:
> > > > Hi,
> > > >
> &
NT_LOONGARCH_HW_WATCH0xa06 /* LoongArch hardware
> watchpoint registers */
>
> -/* Note types with note name "GNU" */
> -#define NT_GNU_PROPERTY_TYPE_0 5
> -
> /* Note header in a PT_NOTE section */
> typedef struct elf32_note {
>Elf32_Word n_namesz; /* Name size */
Reviewed-by: Dave Martin
Cheers
---Dave
On Mon, Jul 14, 2025 at 10:37:11PM -0700, Kees Cook wrote:
> On Tue, 01 Jul 2025 14:55:53 +0100, Dave Martin wrote:
> > This series aims to clean up an aspect of coredump generation:
> >
> > ELF coredumps contain a set of notes describing the state of machine
> > regi
Instead of having the core code guess the note name for each regset,
use USER_REGSET_NOTE_TYPE() to pick the correct name from elf.h.
Signed-off-by: Dave Martin
Cc: Madhavan Srinivasan
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: Oleg Nesterov
Cc: Kees Cook
Cc: Akihiko
ttps://refspecs.linuxfoundation.org/elf/gabi41.pdf
[2] elf: Define note name macros
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/uapi/linux/elf.h?id=7da8e4ad4df0dd12f37357af62ce1b63e75ae2e6
Dave Martin (23):
regset: Fix kerneldoc for struct regset_get() in
50 matches
Mail list logo
