Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1447194

RE: [RFC 3/3] kexec: extend kexec_file_load system call

Show all headers | View raw

From: Dave Young
> On 07/15/16 at 02:19pm, Mark Rutland wrote:
> > On Fri, Jul 15, 2016 at 09:09:55AM -0400, Vivek Goyal wrote:
> > > On Tue, Jul 12, 2016 at 10:42:01AM +0900, AKASHI Takahiro wrote:
> > >
> > > [..]
> > > > -SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
> > > > +SYSCALL_DEFINE6(kexec_file_load, int, kernel_fd, int, initrd_fd,
> > > >  		unsigned long, cmdline_len, const char __user *, cmdline_ptr,
> > > > -		unsigned long, flags)
> > > > +		unsigned long, flags, const struct kexec_fdset __user *, ufdset)
> > >
> > > Can one add more parameters to existing syscall. Can it break existing
> > > programs with new kernel? I was of the impression that one can't do that.
> > > But may be I am missing something.
> >
> > I think the idea was that we would only look at the new params if a new
> > flags was set, and otherwise it would behave as the old syscall.
> >
> > Regardless, I think it makes far more sense to add a kexec_file_load2
> > syscall if we're going to modify the prototype at all. It's a rather
> > different proposition to the existing syscall, and needs to be treated
> > as such.
> 
> I do not think it is worth to add another syscall for extra fds.
> We have open(2) as an example for different numbers of arguments
> already.

Probably works 'by luck' and no one has actually thought about why.
That ioctl() works is (probably) even more lucky.

There are ABI that use different calling conventions for varags functions
(eg always stack all the arguments). I guess linux doesn't run on any of them.

ioctl() is a particular problem because the 'arg' might be an integer or a pointer.
Fortunately all the 64bit ABI linux uses pass the arg parameter in a register
(and don't use different registers for pointer and data arguments).

You could have two 'libc' functions that refer to the same system call entry.
Certainly safer than a varargs function.

	David

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC 3/3] kexec: extend kexec_file_load system call AKASHI Takahiro <takahiro.akashi@linaro.org> - 2016-07-12 03:40 +0200
  Re: [RFC 3/3] kexec: extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-15 15:20 +0200
    Re: [RFC 3/3] kexec: extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-15 15:30 +0200
      Re: [RFC 3/3] kexec: extend kexec_file_load system call Dave Young <dyoung@redhat.com> - 2016-07-18 04:40 +0200
        Re: [RFC 3/3] kexec: extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-18 12:10 +0200
          Re: [RFC 3/3] kexec: extend kexec_file_load system call Dave Young <dyoung@redhat.com> - 2016-07-19 03:00 +0200
            Re: [RFC 3/3] kexec: extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-19 13:00 +0200
              Re: [RFC 3/3] kexec: extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-19 14:30 +0200
                Re: [RFC 3/3] kexec: extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-19 14:50 +0200
                Re: [RFC 3/3] kexec: extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-19 15:30 +0200
        RE: [RFC 3/3] kexec: extend kexec_file_load system call David Laight <David.Laight@ACULAB.COM> - 2016-07-20 13:50 +0200
          Re: [RFC 3/3] kexec: extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-21 11:30 +0200
    Re: [RFC 3/3] kexec: extend kexec_file_load system call Dave Young <dyoung@redhat.com> - 2016-07-18 04:40 +0200

csiph-web