Hi all,
I am planning to release kexec-tools v2.0.17 in the next two weeks
to roughly coincide with the release of the v4.16 kernel.
I would like to ask interested parties to send any patches they would like
included in v2.0.17 within one week so that I can make an rc release.
For reference the
Hi again Dave,
would you care to review v6?
On Wed, Mar 28, 2018 at 03:15:14PM +0200, Michal Suchanek wrote:
> When the kernel does not know a syscall number it returns -ENOSYS but
> when kexec does not know a syscall number it returns -1. Return -ENOSYS
> from kexec as well.
>
> Signed-off-by:
On Thu, Mar 29, 2018 at 04:05:43PM -0300, Thiago Jung Bauermann wrote:
> kexec_file_load() on powerpc doesn't support kdump kernels yet, so it
> returns -ENOTSUPP in that case.
>
> I've recently learned that this errno is internal to the kernel and isn't
> supposed to be exposed to userspace. Ther
On Mon, Mar 26, 2018 at 02:16:34PM +0530, Hari Bathini wrote:
> PPC64 kernel now supports kexec_file_load system call. Leverage it by
> enabling that support here. Note that loading crash kernel with this
> system call is not yet supported in the kernel and trying to load one
> will fail with '-ENO
kexec_file_load() on powerpc doesn't support kdump kernels yet, so it
returns -ENOTSUPP in that case.
I've recently learned that this errno is internal to the kernel and isn't
supposed to be exposed to userspace. Therefore, change to -EOPNOTSUPP which
is defined in an uapi header.
This does indee
On Thu, Mar 29, 2018 at 02:46:44PM +, David Laight wrote:
> From: Dominik Brodowski
> > Sent: 29 March 2018 15:42
> > On Thu, Mar 29, 2018 at 07:20:27AM -0700, Matthew Wilcox wrote:
> > > On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote:
> > > > At least on 64-bit x86, it will
From: Dominik Brodowski
> Sent: 29 March 2018 15:42
> On Thu, Mar 29, 2018 at 07:20:27AM -0700, Matthew Wilcox wrote:
> > On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote:
> > > At least on 64-bit x86, it will likely be a hard requirement from v4.17
> > > onwards to not call system
On Thu, Mar 29, 2018 at 07:20:27AM -0700, Matthew Wilcox wrote:
> On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote:
> > At least on 64-bit x86, it will likely be a hard requirement from v4.17
> > onwards to not call system call functions in the kernel: It is better to
> > use use a
On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote:
> At least on 64-bit x86, it will likely be a hard requirement from v4.17
> onwards to not call system call functions in the kernel: It is better to
> use use a different calling convention for system calls there, where
> struct pt
As the syscall function should only be called from the system call table
but not from elsewhere in the kernel, move the prototype for
sys_kexec_load() to include/syscall.h.
Cc: Eric Biederman
Cc: kexec@lists.infradead.org
Signed-off-by: Dominik Brodowski
---
include/linux/kexec.h| 4
i
[ While most parts of this patch set have been sent out already at least
once, I send out *all* patches to lkml once again as this whole series
touches several different subsystems in sensitive areas. ]
System calls are interaction points between userspace and the kernel.
Therefore, system cal
do_kexec_load() can be called directly by compat_sys_kexec() as long as
the same parameters checks are completed which are currently handled
(also) by sys_kexec(). Therefore, move those to kexec_load_check(),
call that newly introduced helper function from both sys_kexec() and
compat_sys_kexec(), a
Hi Fukui-san
Thank you for the detailed report.
And sorry that makedumpfile doesn't have the enough compatibility.
Unfortunately, my idea is only to disable KASLR.
If no one propose another way, please consider it.
Thanks
Tachibana
> -Original Message-
> From: kexec [mailto:kexec-boun...
13 matches
Mail list logo
