Re: [PATCH v2 00/89] fs: new accessors for inode->i_ctime

Jeff Layton writes: > On Wed, 2023-07-05 at 14:58 -0400, Jeff Layton wrote: >> v2: >> - prepend patches to add missing ctime updates >> - add simple_rename_timestamp helper function >> - rename ctime accessor functions as inode_get_ctime/inode_set_ctime_* >> - drop individual

Re: [PATCH 24/30] panic: Refactor the panic path

"Guilherme G. Piccoli" writes: > The panic() function is somewhat convoluted - a lot of changes were > made over the years, adding comments that might be misleading/outdated > now, it has a code structure that is a bit complex to follow, with > lots of conditionals, for example. The panic

Re: [PATCH] kexec_file: Drop weak attribute from arch_kexec_apply_relocations[_add]

Baoquan He writes: > On 05/19/22 at 12:59pm, Eric W. Biederman wrote: >> Baoquan He writes: >> >> > Hi Eric, >> > >> > On 05/18/22 at 04:59pm, Eric W. Biederman wrote: >> >> "Naveen N. Rao" writes: >> >> >> >

Re: [PATCH] kexec_file: Drop weak attribute from arch_kexec_apply_relocations[_add]

Baoquan He writes: > Hi Eric, > > On 05/18/22 at 04:59pm, Eric W. Biederman wrote: >> "Naveen N. Rao" writes: >> >> > Since commit d1bcae833b32f1 ("ELF: Don't generate unused section >> > symbols") [1], binutils (v2.36+) starte

Re: [PATCH] kexec_file: Drop weak attribute from arch_kexec_apply_relocations[_add]

"Naveen N. Rao" writes: > Since commit d1bcae833b32f1 ("ELF: Don't generate unused section > symbols") [1], binutils (v2.36+) started dropping section symbols that > it thought were unused. This isn't an issue in general, but with > kexec_file.c, gcc is placing

Re: [PATCH] kexec_file: Drop pr_err in weak implementations of arch_kexec_apply_relocations[_add]

Michael Ellerman writes: > "Eric W. Biederman" writes: >> Looking at this the pr_err is absolutely needed. If an unsupported case >> winds up in the purgatory blob and the code can't handle it things >> will fail silently much worse later. > > It won't

Re: [PATCH] kexec_file: Drop pr_err in weak implementations of arch_kexec_apply_relocations[_add]

Looking at this the pr_err is absolutely needed. If an unsupported case winds up in the purgatory blob and the code can't handle it things will fail silently much worse later. So the proposed patch is unfortunately the wrong direction. "Naveen N. Rao" writes: > Baoquan He wrote: >> On

Re: [PATCH v2 18/18] uaccess: drop maining CONFIG_SET_FS users

gt; With CONFIG_SET_FS gone, so drop all remaining references to > set_fs()/get_fs(), mm_segment_t and uaccess_kernel(). For the bits I have looked at recently, and think I understand. Acked-by: "Eric W. Biederman" > > Signed-off-by: Arnd Bergmann > --- > fs/exec

Re: [PATCH 21/20] signal: Replace force_sigsegv(SIGSEGV) with force_fatal_sig(SIGSEGV)

s already here. > On Wed, Oct 20, 2021 at 11:52 PM Eric W. Biederman > wrote: >> Now that force_fatal_sig exists it is unnecessary and a bit confusing >> to use force_sigsegv in cases where the simpler force_fatal_sig is >> wanted. So change every instance we can to make t

[PATCH 21/20] signal: Replace force_sigsegv(SIGSEGV) with force_fatal_sig(SIGSEGV)

Now that force_fatal_sig exists it is unnecessary and a bit confusing to use force_sigsegv in cases where the simpler force_fatal_sig is wanted. So change every instance we can to make the code clearer. Signed-off-by: "Eric W. Biederman" --- arch/arc/kernel/process.c | 2 +-

[PATCH 00/20] exit cleanups

force_sig(SIGKILL). It is my plan after sending all of these changes out for review to place them in a topic branch for sending Linus. Especially for the changes that depend upon the new helper force_fatal_sig this is important. Eric W. Biederman (20): exit/doublefault: Remove apparently bogus

[PATCH 07/20] signal/powerpc: On swapcontext failure force SIGSEGV

t;[PATCH] ppc64: VMX (Altivec) support & signal32 rework, from Ben Herrenschmidt") Signed-off-by: "Eric W. Biederman" --- arch/powerpc/kernel/signal_32.c | 6 -- arch/powerpc/kernel/signal_64.c | 9 ++--- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a

Re: [PATCH RESEND v3 6/6] powerpc/signal: Use unsafe_copy_siginfo_to_user()

Christophe Leroy writes: > Le 13/09/2021 à 18:21, Eric W. Biederman a écrit : >> ebied...@xmission.com (Eric W. Biederman) writes: >> >>> Christophe Leroy writes: >>> >>>> Use unsafe_copy_siginfo_to_user() in order to do the copy >>>&g

Re: [PATCH RESEND v3 6/6] powerpc/signal: Use unsafe_copy_siginfo_to_user()

ebied...@xmission.com (Eric W. Biederman) writes: > Christophe Leroy writes: > >> Use unsafe_copy_siginfo_to_user() in order to do the copy >> within the user access block. >> >> On an mpc 8321 (book3s/32) the improvment is about 5% on a process >> sending a

Re: [PATCH RESEND v3 6/6] powerpc/signal: Use unsafe_copy_siginfo_to_user()

Christophe Leroy writes: > Use unsafe_copy_siginfo_to_user() in order to do the copy > within the user access block. > > On an mpc 8321 (book3s/32) the improvment is about 5% on a process > sending a signal to itself. > > Signed-off-by: Christophe Leroy > --- > v3: Don't leave compat aside, use

Re: [PATCH RESEND v3 4/6] signal: Add unsafe_copy_siginfo_to_user32()

Christophe Leroy writes: > In the same spirit as commit fb05121fd6a2 ("signal: Add > unsafe_get_compat_sigset()"), implement an 'unsafe' version of > copy_siginfo_to_user32() in order to use it within user access blocks. > > To do so, we need inline version of copy_siginfo_to_external32() as we

Re: [PATCH v2 3/5] signal: Add unsafe_copy_siginfo_to_user()

Christophe Leroy writes: > On 9/8/21 6:17 PM, Eric W. Biederman wrote: >> Christophe Leroy writes: >> >>> Le 02/09/2021 à 20:43, Eric W. Biederman a écrit : >>>> Christophe Leroy writes: >>>> >>>>> In the same spirit as c

Re: [PATCH v2 3/5] signal: Add unsafe_copy_siginfo_to_user()

Christophe Leroy writes: > Le 02/09/2021 à 20:43, Eric W. Biederman a écrit : >> Christophe Leroy writes: >> >>> In the same spirit as commit fb05121fd6a2 ("signal: Add >>> unsafe_get_compat_sigset()"), implement an 'unsafe' version of >>> c

Re: [PATCH v2 5/5] powerpc/signal: Use unsafe_copy_siginfo_to_user()

Christophe Leroy writes: > Use unsafe_copy_siginfo_to_user() in order to do the copy > within the user access block. > > On an mpc 8321 (book3s/32) the improvment is about 5% on a process > sending a signal to itself. Nacked-by: "Eric W. Biederman" copy_siginf

Re: [PATCH v2 3/5] signal: Add unsafe_copy_siginfo_to_user()

_user(). Looking at your use cases you need the 32bit compat version of this as well. The 32bit compat version is too complicated to become a macro, so I don't think you can make this work correctly for the 32bit compat case. Probably-Not-by: "Eric W. Biederman" Eric > Signed-off-

Re: [PATCH v5 1/6] kexec: move locking into do_kexec_load

Arnd Bergmann writes: > From: Arnd Bergmann > > The locking is the same between the native and compat version of > sys_kexec_load(), so it can be done in the common implementation > to reduce duplication. Acked-by: "Eric W. Biederman" > > Co-developed-by:

Re: [PATCH v5 2/6] kexec: avoid compat_alloc_user_space

call handler directly actually > makes the code simpler, as the conversion for compat mode can now be > done on kernel memory. Acked-by: "Eric W. Biederman" > > Co-developed-by: Eric Biederman > Co-developed-by: Christoph Hellwig > Link: https://lore.kernel.org/lkm

Re: [PATCH 3/4] exec: simplify the compat syscall handling

Christoph Hellwig writes: > diff --git a/fs/exec.c b/fs/exec.c > index 06e07278b456fa..b34c1eb9e7ad8e 100644 > --- a/fs/exec.c > +++ b/fs/exec.c > @@ -391,47 +391,34 @@ static int bprm_mm_init(struct linux_binprm *bprm) > return err; > } > > -struct user_arg_ptr { > -#ifdef

Re: [PATCH RFC PKS/PMEM 51/58] kernel: Utilize new kmap_thread()

ira.we...@intel.com writes: > From: Ira Weiny > > This kmap() call is localized to a single thread. To avoid the over > head of global PKRS updates use the new kmap_thread() call. Acked-by: "Eric W. Biederman" > > Cc: Eric Biederman > Signed-off-by: Ira Wein

Re: [PATCH v2] All arch: remove system call sys_sysctl

Rich Felker writes: > On Thu, Jun 11, 2020 at 12:01:11PM -0500, Eric W. Biederman wrote: >> Rich Felker writes: >> >> > On Thu, Jun 11, 2020 at 06:43:00AM -0500, Eric W. Biederman wrote: >> >> Xiaoming Ni writes: >> >> >> >> &

Re: [PATCH v2] All arch: remove system call sys_sysctl

Rich Felker writes: > On Thu, Jun 11, 2020 at 06:43:00AM -0500, Eric W. Biederman wrote: >> Xiaoming Ni writes: >> >> > Since the commit 61a47c1ad3a4dc ("sysctl: Remove the sysctl system call"), >> > sys_sysctl is actually unavailable: any input can o

Re: [PATCH v2] All arch: remove system call sys_sysctl

ll still compile if we remove this header for a separate patch. The concerns and justifications for the uapi header are completely different then for the removing the sys_sysctl implementation. Otherwise Acked-by: "Eric W. Biederman" Eric

Re: [PATCH 12/13] sysctl: add helper to register empty subdir

Luis Chamberlain writes: > The way to create a subdirectory from the base set of directories > is a bit obscure, so provide a helper which makes this clear, and > also helps remove boiler plate code required to do this work. I agreee calling: register_sysctl("fs/binfmt_misc",

Re: [PATCH 02/13] cdrom: use new sysctl subdir helper register_sysctl_subdir()

Luis Chamberlain writes: > This simplifies the code considerably. The following coccinelle With register_sysctl the code would read: cdrom_sysctl_header = register_sysctl("dev/cdrom", cdrom_table); Please go that direction. Thank you. Eric

Re: [PATCH 01/13] sysctl: add new register_sysctl_subdir() helper

ebied...@xmission.com (Eric W. Biederman) writes: > Luis Chamberlain writes: > >> Often enough all we need to do is create a subdirectory so that >> we can stuff sysctls underneath it. However, *if* that directory >> was already created early on the boot sequence we reall

Re: [PATCH 01/13] sysctl: add new register_sysctl_subdir() helper

Luis Chamberlain writes: > Often enough all we need to do is create a subdirectory so that > we can stuff sysctls underneath it. However, *if* that directory > was already created early on the boot sequence we really have no > need to use the full boiler plate code for it, we can just use >

Re: remove set_fs calls from the coredump code v6

Christoph Hellwig writes: > On Tue, May 05, 2020 at 03:28:50PM -0500, Eric W. Biederman wrote: >> We probably can. After introducing a kernel_compat_siginfo that is >> the size that userspace actually would need. >> >> It isn't something I want to mess with until

Re: remove set_fs calls from the coredump code v6

Linus Torvalds writes: > On Tue, May 5, 2020 at 3:13 AM Christoph Hellwig wrote: >> >> this series gets rid of playing with the address limit in the exec and >> coredump code. Most of this was fairly trivial, the biggest changes are >> those to the spufs coredump code. > > Ack, nice, and looks

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

David Hildenbrand writes: > On 30.04.20 18:33, Eric W. Biederman wrote: >> David Hildenbrand writes: >> >>> On 30.04.20 17:38, Eric W. Biederman wrote: >>>> David Hildenbrand writes: >>>> >>>>> Some devices/drivers that add memo

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

David Hildenbrand writes: > On 30.04.20 17:38, Eric W. Biederman wrote: >> David Hildenbrand writes: >> >>> Some devices/drivers that add memory via add_memory() and friends (e.g., >>> dax/kmem, but also virtio-mem in the future) don't want to create en

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

; If there is no entry, it will simply return with -EINVAL. > > [1] > https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap You know what this justification is rubbish, and I have previously explained why it is rubbish. Nacked-by: "Eric W. Biederman"

Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image

David Hildenbrand writes: >>> ACPI SRAT is embeded into efi, need read out the rsdp pointer. If we don't >>> pass the efi, it won't get the SRAT table correctly, if I remember >>> correctly. Yeah, I remeber kvm guest can get memory hotplugged with >>> ACPI only, this won't happen on bare metal

Re: remove set_fs calls from the exec and coredump code v2

Christoph Hellwig writes: > On Fri, Apr 17, 2020 at 05:41:52PM -0500, Eric W. Biederman wrote: >> > this series gets rid of playing with the address limit in the exec and >> > coredump code. Most of this was fairly trivial, the biggest changes are >> > th

Re: [PATCH 1/2] signal: Factor copy_siginfo_to_external32 from copy_siginfo_to_user32

Christophe Leroy writes: > Le 17/04/2020 à 23:09, Eric W. Biederman a écrit : >> >> To remove the use of set_fs in the coredump code there needs to be a >> way to convert a kernel siginfo to a userspace compat siginfo. >> >> Call that function copy_si

Re: remove set_fs calls from the exec and coredump code v2

Christoph Hellwig writes: > Hi all, > > this series gets rid of playing with the address limit in the exec and > coredump code. Most of this was fairly trivial, the biggest changes are > those to the spufs coredump code. > > Changes since v1: > - properly spell NUL > - properly handle the

[PATCH 2/2] signal: Remove the set_fs in binfmt_elf.c:fill_siginfo_note

copy_siginfo_to_external32 to handle the compat case. Signed-off-by: "Eric W. Biederman" --- fs/binfmt_elf.c| 5 + fs/compat_binfmt_elf.c | 2 +- include/linux/signal.h | 7 +++ 3 files changed, 9 insertions(+), 5 deletions(-) diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index 13

[PATCH 1/2] signal: Factor copy_siginfo_to_external32 from copy_siginfo_to_user32

times for utime and stime. As only SIGCHLD is affected and SIGCHLD never causes a coredump I have avoided handling that case. Signed-off-by: "Eric W. Biederman" --- include/linux/compat.h | 1 + kernel/signal.c| 108 +++-- 2 files changed, 63

Re: [PATCH 2/8] signal: clean up __copy_siginfo_to_user32

quite buggy because as a result. My general sense is putting all of the weird details up front and center in kernel/signal.c is the only way for this code will be looked at and successfully maintained. How about these patches to solve set_fs with binfmt_elf instead: Eric W. Biederman (2):

Re: [PATCH 4/8] binfmt_elf: open code copy_siginfo_to_user to kernelspace buffer

Christoph Hellwig writes: > On Wed, Apr 15, 2020 at 10:20:11AM +0200, Arnd Bergmann wrote: >> > I'd rather keep it out of this series and to >> > an interested party. Then again x32 doesn't seem to have a whole lot >> > of interested parties.. >> >> Fine with me. It's on my mental list of

Re: [PATCH 1/4] fs: always build llseek.

Michal Suchanek writes: > 64bit !COMPAT does not build because the llseek syscall is in the > tables. Do I read this right you have a 128 bit offset to llseek on ppc64? Looking at the signature it does not appear to make sense to build this function on any 64bit platform. Perhaps the proper

Re: [PATCH 1/4] fs: always build llseek.

ebied...@xmission.com (Eric W. Biederman) writes: > Michal Suchanek writes: > >> 64bit !COMPAT does not build because the llseek syscall is in the >> tables. > > Do I read this right you have a 128 bit offset to llseek on ppc64? > > Looking at the signature it

[REVIEW][PATCH 0/9] signal/powerpc: siginfo cleanups

them in the powerpc tree let me know. All of the prerequisites should have been merged through Linus's tree several releases ago. Eric W. Biederman (9): signal/powerpc: Use force_sig_mceerr as appropriate signal/powerpc: Remove pkey parameter from __bad_area signal/powerpc: Call

[REVIEW][PATCH 9/9] signal/powerpc: Use force_sig_fault where appropriate

Signed-off-by: "Eric W. Biederman" --- arch/powerpc/kernel/process.c | 9 +--- arch/powerpc/mm/fault.c | 9 +--- arch/powerpc/platforms/cell/spu_base.c| 4 ++-- arch/powerpc/platforms/cell/spufs/fault.c | 26 +++ 4 fil

[REVIEW][PATCH 8/9] signal/powerpc: Simplify _exception_pkey by using force_sig_pkuerr

Call force_sig_pkuerr directly instead of rolling it by hand in _exception_pkey. Signed-off-by: "Eric W. Biederman" --- arch/powerpc/kernel/traps.c | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/tra

[REVIEW][PATCH 7/9] signal/poewrpc: Specialize _exception_pkey for handling pkey exceptions

Now that _exception no longer calls _exception_pkey it is no longer necessary to handle any signal with any si_code. All pkey exceptions are SIGSEGV with paired with SEGV_PKUERR. So just handle that case and remove the now unnecessary parameters from _exception_pkey. Signed-off-by: "E

[REVIEW][PATCH 6/9] signal/powerpc: Call force_sig_fault from _exception

The callers of _exception don't need the pkey exception logic because they are not processing a pkey exception. So just call exception_common directly and then call force_sig_fault to generate the appropriate siginfo and deliver the appropriate signal. Signed-off-by: "Eric W. Bied

[REVIEW][PATCH 5/9] signal/powerpc: Factor the common exception code into exception_common

the individual exception handlers to generate the signals themselves. Signed-off-by: "Eric W. Biederman" --- arch/powerpc/kernel/traps.c | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c index f6

[REVIEW][PATCH 4/9] signal/powerpc: Remove pkey parameter from __bad_area_nosemaphore

Now that bad_key_fault_exception no longer calls __bad_area_nosemaphore there is no reason for __bad_area_nosemaphore to handle pkeys. Signed-off-by: "Eric W. Biederman" --- arch/powerpc/mm/fault.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/arch/

[REVIEW][PATCH 3/9] signal/powerpc: Call _exception_pkey directly from bad_key_fault_exception

This removes the need for other code paths to deal with pkey exceptions. Signed-off-by: "Eric W. Biederman" --- arch/powerpc/mm/fault.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c index e5

[REVIEW][PATCH 2/9] signal/powerpc: Remove pkey parameter from __bad_area

There are no callers of __bad_area that pass in a pkey parameter so it makes no sense to take one. Signed-off-by: "Eric W. Biederman" --- arch/powerpc/mm/fault.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fau

[REVIEW][PATCH 1/9] signal/powerpc: Use force_sig_mceerr as appropriate

In do_sigbus isolate the mceerr signaling code and call force_sig_mceerr instead of falling through to the force_sig_info that works for all of the other signals. Signed-off-by: "Eric W. Biederman" --- arch/powerpc/mm/fault.c | 18 +++--- 1 file changed, 11 insert

[REVIEW][PATCH 15/17] signal: Add TRAP_UNK si_code for undiagnosted trap exceptions

...@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: "Eric W. Biederman" <ebied...@xmission.com> --- arch/x86/kernel/signal_compat.c| 2 +- include/uapi/asm-generic/siginfo.h | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/signal_com

[REVIEW][PATCH 13/17] signal/powerpc: Replace FPE_FIXME with FPE_FLTUNK

ious exceptions.") History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git Signed-off-by: "Eric W. Biederman" <ebied...@xmission.com> --- arch/powerpc/include/uapi/asm/siginfo.h | 7 --- arch/powerpc/kernel/traps.c | 6 +++--- 2 files

[REVIEW][PATCH 17/17] signal/powerpc: Replace TRAP_FIXME with TRAP_UNK

ious exceptions.") History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git Signed-off-by: "Eric W. Biederman" <ebied...@xmission.com> --- arch/powerpc/include/uapi/asm/siginfo.h | 8 arch/powerpc/kernel/traps.c | 4 ++-- 2 files changed,

Re: [PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures

Arnd Bergmann <a...@arndb.de> writes: > On Thu, Apr 19, 2018 at 5:20 PM, Arnd Bergmann <a...@arndb.de> wrote: >> On Thu, Apr 19, 2018 at 4:59 PM, Eric W. Biederman <ebied...@xmission.com> >> wrote: >>> I suspect you want to use __kernel_ulong

Re: [PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures

Arnd Bergmann writes: > Most architectures now use the asm-generic copy of the sysvipc data > structures (msqid64_ds, semid64_ds, shmid64_ds), which use 32-bit > __kernel_time_t on 32-bit architectures but have padding behind them to > allow extending the type to 64-bit. > >

Re: [RFC PATCH 0/3] Dealing with the aliases of SI_USER

Dave Martin writes: > 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

Re: [RFC PATCH 0/3] Dealing with the aliases of SI_USER

Linus Torvalds <torva...@linux-foundation.org> writes: > ( > > On Sun, Apr 15, 2018 at 8:56 AM, Eric W. Biederman > <ebied...@xmission.com> wrote: [snip bit about wanting what is effectively force_sig_fault instead of clear_siginfo everywhere] > The other thing

Re: [RFC PATCH 1/3] signal: Ensure every siginfo we send has all bits initialized

Dave Martin <dave.mar...@arm.com> writes: > On Tue, Apr 17, 2018 at 02:37:38PM -0500, Eric W. Biederman wrote: >> Dave Martin <dave.mar...@arm.com> writes: >> >> > Hmmm >> > >> > memset()/clear_siginfo() may ensure that there are no uninitial

Re: [RFC PATCH 1/3] signal: Ensure every siginfo we send has all bits initialized

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 > sure that this approach is guaranteed to sanitise the padding seen by > userspace. > > Rationale

Re: [RFC PATCH 0/3] Dealing with the aliases of SI_USER

Linus Torvalds <torva...@linux-foundation.org> writes: > ( > > On Sun, Apr 15, 2018 at 8:56 AM, Eric W. Biederman > <ebied...@xmission.com> wrote: >> >> Would you consider the patchset below for -rc2? > > Ugh. The point of this series is to squa

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

Russell King - ARM Linux writes: > On Fri, Apr 13, 2018 at 12:53:49PM -0700, Linus Torvalds wrote: >> On Fri, Apr 13, 2018 at 11:45 AM, Dave Martin wrote: >> > >> > Most uses I've seen do nothing more than use the FPE_xyz value to >> > format

[RFC PATCH 3/3] signal: Stop special casing TRAP_FIXME and FPE_FIXME in siginfo_layout

. At least until they are fixed. Signed-off-by: "Eric W. Biederman" <ebied...@xmission.com> --- kernel/signal.c | 9 - 1 file changed, 9 deletions(-) diff --git a/kernel/signal.c b/kernel/signal.c index d56f4d496c89..fc82d2c0918f 100644 --- a/kernel/signal.c +++ b/kernel/sign

[RFC PATCH 2/3] signal: Reduce copy_siginfo_to_user to just copy_to_user

still need to fix their ABI so that signalfd and 32bit compat code will work properly. Signed-off-by: "Eric W. Biederman" <ebied...@xmission.com> --- kernel/signal.c | 84 ++--- 1 file changed, 2 insertions(+), 82 deletions(-) dif

[RFC PATCH 1/3] signal: Ensure every siginfo we send has all bits initialized

to make it clear that siginfo siginfo is not used on other paths in the function in which it is declared. Instances of using memset to initialize siginfo have been replaced with calls clear_siginfo for clarity. Signed-off-by: "Eric W. Biederman" <ebied...@xmission.com> --- arch/alpha/

[RFC PATCH 0/3] Dealing with the aliases of SI_USER

siginfos the status quo returns to what it was before I introduced siginfo_layout (AKA regressions go bye-bye). I believe given the issues these changes are a candiate for -rc2. Otherwise I will keep these changes for the next merge window. Eric W. Biederman (3): signal: Ensure every siginfo we

Re: [PATCH v11 00/10] Application Data Integrity feature introduced by SPARC M7

Khalid Aziz writes: > On 02/07/2018 12:38 AM, ebied...@xmission.com wrote: >> Khalid Aziz writes: >> >>> On 02/01/2018 07:29 PM, ebied...@xmission.com wrote: Khalid Aziz writes: > V11 changes: > This

Re: [PATCH v11 00/10] Application Data Integrity feature introduced by SPARC M7

Khalid Aziz writes: > On 02/01/2018 07:29 PM, ebied...@xmission.com wrote: >> Khalid Aziz writes: >> >>> V11 changes: >>> This series is same as v10 and was simply rebased on 4.15 kernel. Can >>> mm maintainers please review patches 2, 7, 8 and 9

Re: [PATCH v11 00/10] Application Data Integrity feature introduced by SPARC M7

Khalid Aziz writes: > V11 changes: > This series is same as v10 and was simply rebased on 4.15 kernel. Can > mm maintainers please review patches 2, 7, 8 and 9 which are arch > independent, and include/linux/mm.h and mm/ksm.c changes in patch 10 > and ack these if

Re: [PATCH v10 27/27] mm: display pkey in smaps if arch_pkeys_enabled() is true

Ram Pai <linux...@us.ibm.com> writes: > On Fri, Jan 19, 2018 at 10:09:41AM -0600, Eric W. Biederman wrote: >> Ram Pai <linux...@us.ibm.com> writes: >> >> > Currently the architecture specific code is expected to >> > display the protection keys

Re: [PATCH v10 27/27] mm: display pkey in smaps if arch_pkeys_enabled() is true

Ram Pai writes: > Currently the architecture specific code is expected to > display the protection keys in smap for a given vma. > This can lead to redundant code and possibly to divergent > formats in which the key gets displayed. > > This patch changes the

[PATCH 06/11] signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP

ef ("PPC32: Provide proper siginfo information on various exceptions.") History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git Signed-off-by: "Eric W. Biederman" <ebied...@xmission.com> --- arch/powerpc/include/uapi/asm/siginfo.h | 15 +++

Re: [RFC v6 35/62] powerpc: Deliver SEGV signal on pkey violation

Ram Pai writes: > diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c > index d4e545d..fe1e7c7 100644 > --- a/arch/powerpc/kernel/traps.c > +++ b/arch/powerpc/kernel/traps.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include >

Re: [PATCH v2 2/5] ia64: reuse append_elf_note() and final_note() functions

Hari Bathini writes: > Hi Dave, > > > Thanks for the review. > > > On Thursday 01 December 2016 10:26 AM, Dave Young wrote: >> Hi Hari >> >> Personally I like V1 more, but split the patch 2 is easier for ia64 >> people to reivew. I did basic x86 testing, it runs ok.

Re: [RFC] kexec_file: Add support for purgatory built as PIE

Baoquan He writes: > On 11/02/16 at 04:00am, Thiago Jung Bauermann wrote: >> Hello, >> >> The kexec_file code currently builds the purgatory as a partially linked >> object >> (using ld -r). Is there a particular reason to use that instead of a >> position >> independent

Re: [PATHC v2 0/9] ima: carry the measurement list across kexec

Thiago Jung Bauermann <bauer...@linux.vnet.ibm.com> writes: > Hello Eric, > > Am Dienstag, 20 September 2016, 11:07:29 schrieb Eric W. Biederman: >> A semi-generic concept called a hand-over buffer seems to be a >> construction of infrustructure for no actual reas

Re: [PATCH v5 00/10] ima: carry the measurement list across kexec

g. There may be people who want to receive the measurment list but don't want to support kexec'ing other kernels or the other way around. I can very much see bootloaders that expect they will be the first kernel to not want to compile in the extra code for receiving the measurment list. But again

Re: [PATHC v2 0/9] ima: carry the measurement list across kexec

Thiago Jung Bauermann <bauer...@linux.vnet.ibm.com> writes: > Am Samstag, 17 September 2016, 00:17:37 schrieb Eric W. Biederman: >> Thiago Jung Bauermann <bauer...@linux.vnet.ibm.com> writes: >> > Hello Eric, >> > >> > Am Freitag, 16 September 2

Re: [PATHC v2 0/9] ima: carry the measurement list across kexec

Thiago Jung Bauermann <bauer...@linux.vnet.ibm.com> writes: > Hello Eric, > > Am Freitag, 16 September 2016, 14:47:13 schrieb Eric W. Biederman: >> Mimi Zohar <zo...@linux.vnet.ibm.com> writes: >> > Hi Andrew, >> > >> > On Wed, 2016-08-31 a

Re: [PATHC v2 0/9] ima: carry the measurement list across kexec

ebied...@xmission.com (Eric W. Biederman) writes: > Mimi Zohar <zo...@linux.vnet.ibm.com> writes: > >> Hi Andrew, >> >> On Wed, 2016-08-31 at 18:38 -0400, Mimi Zohar wrote: >>> On Wed, 2016-08-31 at 13:50 -0700, Andrew Morton wrote: >>> >

Re: [PATHC v2 0/9] ima: carry the measurement list across kexec

Mimi Zohar writes: > Hi Andrew, > > On Wed, 2016-08-31 at 18:38 -0400, Mimi Zohar wrote: >> On Wed, 2016-08-31 at 13:50 -0700, Andrew Morton wrote: >> > On Tue, 30 Aug 2016 18:40:02 -0400 Mimi Zohar >> > wrote: >> > >> > > The TPM PCRs are

Re: [PATCH v4 0/5] kexec_file: Add buffer hand-over for the next kernel

Thiago Jung Bauermann <bauer...@linux.vnet.ibm.com> writes: > Am Mittwoch, 07 September 2016, 09:19:40 schrieb Eric W. Biederman: >> ebied...@xmission.com (Eric W. Biederman) writes: >> > Thiago Jung Bauermann <bauer...@linux.vnet.ibm.com> writes: >> >> H

Re: [PATCH v4 0/5] kexec_file: Add buffer hand-over for the next kernel

ebied...@xmission.com (Eric W. Biederman) writes: > Thiago Jung Bauermann <bauer...@linux.vnet.ibm.com> writes: > >> Hello, >> >> The purpose of this new version of the series is to fix a small issue that >> I found, which is that the kernel doesn't remove th

Re: [PATCH v4 0/5] kexec_file: Add buffer hand-over for the next kernel

ange is to fix checkpatch > warnings in the last patch. This is fundamentally broken. You do not increase the integrity of a system by dropping integrity checks. No. No. No. No. Nacked-by: "Eric W. Biederman" <ebied...@xmission.com> Eric

Re: [PATCH v4 3/5] kexec_file: Allow skipping checksum calculation for some segments.

lly makes kexec unsafe to use. If any updates need to be made they should be made before they are part of the entire image checksum. No way should this be merged anywhere ever. Nacked-by: "Eric W. Biederman" <ebied...@xmission.com> > > Signed-off-by: Thiago Jung Ba

Re: [RFC 0/3] extend kexec_file_load system call

ebied...@xmission.com (Eric W. Biederman) writes: > Petr Tesarik <ptesa...@suse.cz> writes: > >> On Tue, 12 Jul 2016 13:25:11 -0300 >> Thiago Jung Bauermann <bauer...@linux.vnet.ibm.com> wrote: >> >>> Hi Eric, >>> >>> I'm tryi

Re: [RFC 0/3] extend kexec_file_load system call

anding your thoughts on them a bit. >> >> Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman: >> > AKASHI Takahiro <takahiro.aka...@linaro.org> writes: >> > > Device tree blob must be passed to a second kernel on DTB-capable >> >

Re: [RFC 0/3] extend kexec_file_load system call

bably adding a feature (like code execution) that can be used to defeat the signature scheme I am going to nack this. Nacked-by: "Eric W. Biederman" <ebied...@xmission.com> I am happy to see support for other architectures, but for the sake of not movin

Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available

wrote: On Tue, Jul 14, 2015 at 01:59:19PM +, dwal...@fifo99.com wrote: On Mon, Jul 13, 2015 at 08:19:45PM -0500, Eric W. Biederman wrote: dwal...@fifo99.com writes: On Fri, Jul 10, 2015 at 08:41:28AM -0500, Eric W. Biederman wrote: Hidehiro Kawai

Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available

Vivek Goyal vgo...@redhat.com writes: On Tue, Jul 14, 2015 at 05:29:53PM +, dwal...@fifo99.com wrote: [..] If a machine is failing, there are high chance it can't deliver you the notification. Detecting that failure suing some kind of polling mechanism might be more

Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available

dwal...@fifo99.com writes: On Fri, Jul 10, 2015 at 08:41:28AM -0500, Eric W. Biederman wrote: Hidehiro Kawai hidehiro.kawai...@hitachi.com writes: You can call panic notifiers and kmsg dumpers before kdump by specifying crash_kexec_post_notifiers as a boot parameter. However, it doesn't

Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available

parameter so that you can't change the value of the parameter. Nacked-by: Eric W. Biederman ebied...@xmission.com You are confusing kexec on panic and CONFIG_CRASH_DUMP which is about the tools for reading the state of the previous kernel. Eric Signed-off-by: Hidehiro Kawai hidehiro.kawai

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

which removes the BUG annotations from the binaries without modifying the source code seems like the wrong approach. Acked-by: Eric W. Biederman ebied...@xmission.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

Arnd Bergmann a...@arndb.de writes: On Thursday 23 May 2013, Geert Uytterhoeven wrote: The problem is: trying to fix that will mean the result is a larger kernel than if you just do the usual arch-implemented thing of placing an defined faulting instruction at the BUG() site - which

Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden

Anton Blanchard an...@samba.org writes: On ppc64 the crashkernel region almost always overlaps an area of firmware. This works fine except when using the sysfs interface to reduce the kdump region. If we free the firmware area we are guaranteed to crash. That is ppc64 bug. firmware should

  1   2   >