Arnd Bergmann 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 defeats th
needed they should simply be deleted
from the code base. Disabling CONFIG_BUG which removes the BUG
annotations from the binaries without modifying the source code seems
like the wrong approach.
Acked-by: "Eric W. Biederman"
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
rs" boot parameter so that
> you can't change the value of the parameter.
Nacked-by: "Eric W. Biederman"
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
&g
dwal...@fifo99.com writes:
> On Fri, Jul 10, 2015 at 08:41:28AM -0500, Eric W. Biederman wrote:
>> Hidehiro Kawai writes:
>>
>> > You can call panic notifiers and kmsg dumpers before kdump by
>> > specifying "crash_kexec_post_notifiers" as a boot par
:08AM -0400, Vivek Goyal 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:
>
Vivek Goyal 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
>> > >> >
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 thing
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):
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
usly added
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.
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 comp
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_sigin
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
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 th
path.
> 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&qu
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 crea
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
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
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 u
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
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
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
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/
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
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.
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
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
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
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:
Nathan Fontenot writes:
> version 2 of the patch set with updates from comments.
>
> The Dynamic Logical Partitioning (DLPAR) capabilities of the powerpc pseries
> platform allows for the addition and removal of resources (i.e. cpus,
> memory, pci devices) from a partition. The removal of a resou
Ian Campbell writes:
> On Wed, 2010-03-10 at 12:06 +, Yinghai Lu wrote:
>> On Wed, Mar 10, 2010 at 2:55 AM, wrote:
>> > From: Ian Campbell
>> >
>> > Move arch_init_copy_chip_data and arch_free_chip_data into function
>> > pointers in struct irq_chip since they operate on irq_desc->chip_dat
Ian Campbell writes:
> On Wed, 2010-03-10 at 17:18 +0000, Eric W. Biederman wrote:
>> Ian Campbell writes:
>>
>> > On Wed, 2010-03-10 at 10:55 +, i...@hellion.org.uk wrote:
>> >>
>> >> arch_init_chip_data cannot be moved into struct irq_c
Ian Campbell writes:
> On Wed, 2010-03-10 at 17:42 +0000, Eric W. Biederman wrote:
>>
>>
>> Ian Xen in this sense is simply not x86. irq_cfg is not acpi or
>> ioapic or anything but x86 specific. It has everything to do with
>> having a per cpu vector table o
Ian Campbell writes:
> On Wed, 2010-03-10 at 10:55 +, i...@hellion.org.uk wrote:
>>
>> arch_init_chip_data cannot be moved into struct irq_chip at this time
>> because irq_desc->chip is not known at the time the irq_desc is
>> setup. For now rename arch_init_chip_data to arch_init_irq_desc (
Yinghai Lu writes:
> On 03/10/2010 04:51 AM, Ian Campbell wrote:
>> On Wed, 2010-03-10 at 12:06 +, Yinghai Lu wrote:
>>> On Wed, Mar 10, 2010 at 2:55 AM, wrote:
From: Ian Campbell
Move arch_init_copy_chip_data and arch_free_chip_data into function
pointers in struct irq
ome of these code
>> paths.
>>
>> Signed-off-by: Ian Campbell
>> Acked-by: Michael Ellerman [PowerPC rename portion]
>> Cc: Thomas Gleixner
>> Cc: Ingo Molnar
>> Cc: H. Peter Anvin
>> Cc: Eric W. Biederman
>> Cc: Yinghai Lu
>> Cc:
Ian Campbell writes:
> On Sat, 2010-03-13 at 00:29 +0000, Eric W. Biederman wrote:
>> [...]
>> > after that xen could use
>> > irq_to_desc_alloc_node_f(irq, node, xen_init_chip_data);
>> >
>> > as need...
>> >
>> > at last we don&#x
Could you try the fix Wolfram Sang sent to linux-kernel yesterday?
Peter Zijlstra writes:
> On Fri, 2010-04-02 at 11:33 +0530, Sachin Sant wrote:
>> With 2.6.34-rc3 boot on a Power5 box :
>>
>> loop: module loaded
>> BUG: key 6b6b6b6b6b6b6b6b not in .data!
>> [ cut here ]--
ed one segment for each memory region. Increase this hard limit to 16K
>> which is reasonably large.
>>
>> And change ->segment from a static array to a dynamically allocated memory.
>>
>> Cc: Neil Horman
>> Cc: huang ying
>> Cc: Eric W. Biederman
Anton Blanchard 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 not be in the r
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 do
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 fi
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 inode_ctime_set_{sec
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
_sysctl interface. So just remove the binary sysctl number.
Making the kernel sanity checks happy.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
arch/ppc/kernel/ppc_htab.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/ppc/kernel/ppc_htab.c b/arch/
C_VMCORE is disabled and CONFIG_CRASH_DUMP is enabled.
>
> I tested it on x86_64. Compile tested it on i386 and ppc64. ia64 and
> sh versions are completely untested.
Given the current state of the code:
Acked-by: "Eric W. Biederman" <[EMAIL PROTECTED]>
To process a kernel cr
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[EMAIL PROTECTED] (Linas Vepstas) writes:
> This is a patch (& bug report) for a crash in sysctl_set_parent()
> in 2.6.22-git2.
>
> Problem: 2.6.22-git2 crashes with a stack trace
> [c1d0fb00] c0067b4c .sysctl_set_parent+0x48/0x7c
> [c1d0fb90] c0069b40 .register_
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 CONFIG_COMPA
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 04/25
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
"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 kexec_arch_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+) started
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:
>> >>
>> >
27; version of clear_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"
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_siginfo_t
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
>
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
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
>
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
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
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
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
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
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 +-
hat is 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 m
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
> local
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
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
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", sysctl_mount_point)
ode will
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
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
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:
>> >>
>> >> &
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
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: Er
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
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.
>>
>> On 11/25/16 at 05:24pm,
git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Signed-off-by: "Eric W. Biederman"
---
arch/powerpc/include/uapi/asm/siginfo.h | 15 +++
arch/powerpc/kernel/traps.c | 10 +-
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/ar
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 implementation. It displays
Ram Pai writes:
> On Fri, Jan 19, 2018 at 10:09:41AM -0600, Eric W. Biederman wrote:
>> Ram Pai writes:
>>
>> > Currently the architecture specific code is expected to
>> > display the protection keys in smap for a given vma.
>> > This
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 everything looks good?
I am a b
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 which are arch
>>> independent, and include/linux
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 series is same as v10 and was simply rebased on 4.15 kernel. Can
> mm mai
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
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"
---
arch/alpha/kernel/osf_sys.c
still need to fix their ABI so that signalfd
and 32bit compat code will work properly.
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 84 ++---
1 file changed, 2 insertions(+), 82 deletions(-)
diff --git a/kernel/signal.
least until they are fixed.
Signed-off-by: "Eric W. Biederman"
---
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/signal.c
@@ -2835,15 +2835
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 diagnostic messages while dying. I struggled to find
Linus Torvalds writes:
> (
>
> On Sun, Apr 15, 2018 at 8:56 AM, Eric W. Biederman
> wrote:
>>
>> Would you consider the patchset below for -rc2?
>
> Ugh.
The point of this series is to squash the potential for regressions even
from the weird broken code that fill
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 below, though it's a bit
Dave Martin writes:
> 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
Linus Torvalds writes:
> (
>
> On Sun, Apr 15, 2018 at 8:56 AM, Eric W. Biederman
> wrote:
[snip bit about wanting what is effectively force_sig_fault instead of
clear_siginfo everywhere]
> The other thing we should do is to get rid of the stupid padding.
> Right now &
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 always just zero in the
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.
>
> Unfortunately, that f
Arnd Bergmann writes:
> On Thu, Apr 19, 2018 at 5:20 PM, Arnd Bergmann wrote:
>> On Thu, Apr 19, 2018 at 4:59 PM, Eric W. Biederman
>> wrote:
>>> I suspect you want to use __kernel_ulong_t here instead of a raw
>>> unsigned long. If nothing else it seems in
chmidt
Cc: linuxppc-dev@lists.ozlabs.org
Fixes: 9bad068c24d7 ("[PATCH] ppc32: support for e500 and 85xx")
Fixes: 0ed70f6105ef ("PPC32: Provide proper siginfo information on various
exceptions.")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Sig
: linuxppc-dev@lists.ozlabs.org
Fixes: 9bad068c24d7 ("[PATCH] ppc32: support for e500 and 85xx")
Fixes: 0ed70f6105ef ("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
ux-al...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: "Eric W. Biederman"
---
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_compat.c b/arch/x86/kernel/
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 only reset on a hard reboot. In order to validate a
>
ebied...@xmission.com (Eric W. Biederman) writes:
> 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 Mim
1 - 100 of 114 matches
Mail list logo
