linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: vgoyal@redhat.com (Vivek Goyal)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] asm-generic: add memfd_create system call to unistd.h
Date: Mon, 18 Aug 2014 13:15:40 -0400	[thread overview]
Message-ID: <20140818171540.GE4745@redhat.com> (raw)
In-Reply-To: <20140815135520.GT27466@arm.com>

On Fri, Aug 15, 2014 at 02:55:20PM +0100, Will Deacon wrote:
> On Tue, Aug 12, 2014 at 01:37:36PM +0100, Vivek Goyal wrote:
> > On Tue, Aug 12, 2014 at 12:10:30PM +0100, Will Deacon wrote:
> > > Hmm, so whilst I can easily wire-up the new syscall, it's pretty useless for
> > > anybody other than x86 at the moment. There are a bunch of arch helpers:
> > > 
> > >  arch_kexec_kernel_image_probe
> > >  arch_kexec_kernel_verify_sig
> > >  arch_kexec_kernel_image_load
> > >  arch_kimage_file_post_load_cleanup
> > > 
> > > which are only implemented for x86 (arch/x86/kernel/machine_kexec_64.c),
> > > even though I don't really see what makes them arch-specific as opposed to
> > > file format specific.
> > 
> > Yes, at this point of time, this system call will work only on x86. Agreed
> > that primarily it is file format details which are primarily in arch
> > specific section.
> > 
> > I think that some of the code will become arch independent as other
> > arches start implementing this syscall. 
> > 
> > > 
> > > So this syscall will always fail with -ENOEXEC at the moment. Is it still
> > > worth wiring it up?
> > 
> > I thought that for other arches I have not even defined the syscall. So
> > it probably will fail with -ENOSYS.
> 
> What I meant was, if I wire it into asm-generic/unistd.h then it will return
> -ENOEXEC for architectures using that file (e.g. arm64).
> 
> Patch below, but I don't think it's very useful.
> 

Hi Will,

I have not even defined a syscall number for other arches. IIUC, this
patch will forcibly introduce a syscall number for the new syscall for
arches which use asm-generic/unistd.h.

So question I have is that why should we do it now. One can do it once
somebody enables kexec_file_load() on arm64.

Right now I see that kexec_file_load() gets compiled if CONFIG_KEXEC=y. So
even on arm64 it must be getting compiled in. But it is not being hooked
up using system call table. So there should not be any way to invoke
syscalll definition. So my understand is that in current form, one can
not invoke kexec_file_load() on arm64. Is that right.

Now I have put one more patch to make compilation of kexec_file_load()
conditional on config option CONFIG_KEXEC_FILE. And this option can
be enabled only on x86_64. That means kexec_file_load() will not even
be compiled in on arm64 (once the patch gets merged). Right now patch
is sitting in andrew's tree.

http://ozlabs.org/~akpm/mmotm/broken-out/kexec-create-a-new-config-option-config_kexec_file-for-new-syscall.patch

Can you please help me understand that why do we need this patch if at
this point of time we are not even fixing a system call number for
kexec_file_load() for arches except x86_64.

Thanks
Vivek

  reply	other threads:[~2014-08-18 17:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-11 13:37 [PATCH 1/2] arm64: compat: wire up memfd_create and getrandom syscalls for aarch32 Will Deacon
2014-08-11 13:37 ` [PATCH 2/2] asm-generic: add memfd_create system call to unistd.h Will Deacon
2014-08-11 16:54   ` David Herrmann
2014-08-11 17:15     ` Will Deacon
2014-08-11 18:57       ` Arnd Bergmann
2014-08-11 19:37         ` Geert Uytterhoeven
2014-08-12 10:27           ` Will Deacon
2014-08-12 11:10             ` Will Deacon
2014-08-12 12:37               ` Vivek Goyal
2014-08-15 13:55                 ` Will Deacon
2014-08-18 17:15                   ` Vivek Goyal [this message]
2014-08-18 17:40                     ` Russell King - ARM Linux
2014-08-18 21:04                       ` Vivek Goyal
2014-08-12 10:28         ` Will Deacon
2014-08-11 16:55 ` [PATCH 1/2] arm64: compat: wire up memfd_create and getrandom syscalls for aarch32 David Herrmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140818171540.GE4745@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).