LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [announce] kexec for linux 2.6.6
@ 2004-05-12  4:26 Randy.Dunlap
  2004-05-12  5:00 ` Ulrich Drepper
  2004-05-12  5:05 ` [Fastboot] " Eric W. Biederman
  0 siblings, 2 replies; 31+ messages in thread
From: Randy.Dunlap @ 2004-05-12  4:26 UTC (permalink / raw)
  To: fastboot; +Cc: lkml


kexec for Linux 2.6.6 is now available at:
http://developer.osdl.org/rddunlap/kexec/2.6.6/


kexec userspace tools are at:
http://developer.osdl.org/rddunlap/kexec/kexec-tools/


For 2.6.6, the kexec_load syscall number had to move due to
some new syscall additions in 2.6.6.  However, I didn't
update the kexec userspace program for that 1-line change.
The change is in kexec-syscall.c, line 46:

change
#define __NR_kexec_load 274
to
#define __NR_kexec_load 283

(for i386).

There is one outstanding patch from Albert Herranz
that I will review and possibly use/merge soon.
His email is here:
  http://lists.osdl.org/pipermail/fastboot/2004-May/000290.html


And if anyone has suggestions for handling a variable/moving
syscall number (target), I'm interested in hearing them.

--
~Randy

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [announce] kexec for linux 2.6.6
  2004-05-12  4:26 [announce] kexec for linux 2.6.6 Randy.Dunlap
@ 2004-05-12  5:00 ` Ulrich Drepper
  2004-05-12  6:18   ` [Fastboot] " Eric W. Biederman
  2004-05-12  5:05 ` [Fastboot] " Eric W. Biederman
  1 sibling, 1 reply; 31+ messages in thread
From: Ulrich Drepper @ 2004-05-12  5:00 UTC (permalink / raw)
  To: Randy.Dunlap; +Cc: fastboot, lkml

Randy.Dunlap wrote:

> And if anyone has suggestions for handling a variable/moving
> syscall number (target), I'm interested in hearing them.

If all architectures would finally get a vdso implementation you could
just add the necessary stub in the vdso, add a symbol in the symbol
table of the vdso, and use in the userlevel code

  sym = dlsym (RTLD_DEFAULT, "the_symbol_name")

If the returned value is not NULL the symbol exists.

I've described this many times as one of the huge advantages of vdsos,
hopefully this time it clicks.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] [announce] kexec for linux 2.6.6
  2004-05-12  4:26 [announce] kexec for linux 2.6.6 Randy.Dunlap
  2004-05-12  5:00 ` Ulrich Drepper
@ 2004-05-12  5:05 ` Eric W. Biederman
  1 sibling, 0 replies; 31+ messages in thread
From: Eric W. Biederman @ 2004-05-12  5:05 UTC (permalink / raw)
  To: Randy.Dunlap; +Cc: fastboot, lkml

"Randy.Dunlap" <rddunlap@osdl.org> writes:

> kexec for Linux 2.6.6 is now available at:
> http://developer.osdl.org/rddunlap/kexec/2.6.6/
> 
> 
> kexec userspace tools are at:
> http://developer.osdl.org/rddunlap/kexec/kexec-tools/
> 
> 
> For 2.6.6, the kexec_load syscall number had to move due to
> some new syscall additions in 2.6.6.  However, I didn't
> update the kexec userspace program for that 1-line change.
> The change is in kexec-syscall.c, line 46:
> 
> change
> #define __NR_kexec_load 274
> to
> #define __NR_kexec_load 283
> 
> (for i386).
> 
> There is one outstanding patch from Albert Herranz
> that I will review and possibly use/merge soon.
> His email is here:
>   http://lists.osdl.org/pipermail/fastboot/2004-May/000290.html
> 
> 
> And if anyone has suggestions for handling a variable/moving
> syscall number (target), I'm interested in hearing them.

The easiest would be to update the ./configure script, and
have the syscall number as a parameter.  Quite possibly it
could just point to an appropriate file that would grep for 
__NR_kexec_load.  This does not prevent the recompile problem
but it does help a little.

On the issue of needing $BIGNUM testers, I see a small challenge.
kexec is near useless on an unstable kernel.  So it really needs
to get into a stable series or people will be fighting kernel
bugs so much that they won't be able to see kexec specific issues.

Possibly the sanest route is 2.7.early and then 2.6 at about
the same time.  At any point that kexec makes it into a mainline
kernel though the syscall number will be frozen and things will
get easier.

Eric


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-12  5:00 ` Ulrich Drepper
@ 2004-05-12  6:18   ` Eric W. Biederman
  2004-05-12 15:33     ` Ulrich Drepper
  0 siblings, 1 reply; 31+ messages in thread
From: Eric W. Biederman @ 2004-05-12  6:18 UTC (permalink / raw)
  To: Ulrich Drepper; +Cc: Randy.Dunlap, fastboot, lkml

Ulrich Drepper <drepper@redhat.com> writes:

> Randy.Dunlap wrote:
> 
> > And if anyone has suggestions for handling a variable/moving
> > syscall number (target), I'm interested in hearing them.
> 
> If all architectures would finally get a vdso implementation you could
> just add the necessary stub in the vdso, add a symbol in the symbol
> table of the vdso, and use in the userlevel code
> 
>   sym = dlsym (RTLD_DEFAULT, "the_symbol_name")
> 
> If the returned value is not NULL the symbol exists.
> 
> I've described this many times as one of the huge advantages of vdsos,
> hopefully this time it clicks.

For the momen the only finished port is x86, so we should be able
to do that, it would make the kernel patch a little bigger though.
Last time I saw that conversation I thought you didn't like symbols in
the vdso for syscalls because it slowed things down.

If no one is opposed that sounds like a fairly sane idea.

Eric

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-12  6:18   ` [Fastboot] " Eric W. Biederman
@ 2004-05-12 15:33     ` Ulrich Drepper
  2004-05-12 15:54       ` Eric W. Biederman
  0 siblings, 1 reply; 31+ messages in thread
From: Ulrich Drepper @ 2004-05-12 15:33 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: Randy.Dunlap, fastboot, lkml

Eric W. Biederman wrote:


>>  sym = dlsym (RTLD_DEFAULT, "the_symbol_name")
> [...]

> 
> For the momen the only finished port is x86, so we should be able
> to do that, it would make the kernel patch a little bigger though.
> Last time I saw that conversation I thought you didn't like symbols in
> the vdso for syscalls because it slowed things down.

I don't want to  use this in glibc for every syscall.  But for your
random application in need of a syscall it's fine.

And there is one more thing: the above code is actually not what should
be used.  The symbol able entries should be position independent.  So
one will have to compute the final address (which will be fun for archs
with function descriptors).  I'll have to see how randomization is
actually implemented.  The __kernel_vsyscall symbol is probably not
changed, so we need an out-of-band mechanisms to report the load address
to the userlevel code.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-12 15:33     ` Ulrich Drepper
@ 2004-05-12 15:54       ` Eric W. Biederman
  2004-05-12 16:31         ` Ulrich Drepper
  0 siblings, 1 reply; 31+ messages in thread
From: Eric W. Biederman @ 2004-05-12 15:54 UTC (permalink / raw)
  To: Ulrich Drepper; +Cc: Randy.Dunlap, fastboot, lkml

Ulrich Drepper <drepper@redhat.com> writes:

> Eric W. Biederman wrote:
> 
> 
> >>  sym = dlsym (RTLD_DEFAULT, "the_symbol_name")
> > [...]
> 
> > 
> > For the momen the only finished port is x86, so we should be able
> > to do that, it would make the kernel patch a little bigger though.
> > Last time I saw that conversation I thought you didn't like symbols in
> > the vdso for syscalls because it slowed things down.
> 
> I don't want to  use this in glibc for every syscall.  But for your
> random application in need of a syscall it's fine.

The question that had come up earlier was fast path syscalls like
gettimeofday.

> And there is one more thing: the above code is actually not what should
> be used.  The symbol able entries should be position independent.  So
> one will have to compute the final address (which will be fun for archs
> with function descriptors).  I'll have to see how randomization is
> actually implemented.  The __kernel_vsyscall symbol is probably not
> changed, so we need an out-of-band mechanisms to report the load address
> to the userlevel code.

We currently have AT_SYSINFO_EHDR and AT_SYSINFO which should
report the basic location information.

As a first draft we should be able to use the standard ELF mechanisms
for this.  It is not like PIC shared libraries were new.   Or is
there some specific problem you are thinking of with respect to
randomization?

Eric

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-12 15:54       ` Eric W. Biederman
@ 2004-05-12 16:31         ` Ulrich Drepper
  2004-05-12 16:57           ` Eric W. Biederman
  0 siblings, 1 reply; 31+ messages in thread
From: Ulrich Drepper @ 2004-05-12 16:31 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: Randy.Dunlap, fastboot, lkml

Eric W. Biederman wrote:

> As a first draft we should be able to use the standard ELF mechanisms
> for this.  It is not like PIC shared libraries were new.   Or is
> there some specific problem you are thinking of with respect to
> randomization?

The official kernel does not have vdso randomization.  Ingo has a patch
for the Red Hat kernel which is used in the FC2 kernel.  The patch
effectively only changes the location at which the vdso is mapped.  It
does not change the vdso content.  So the __kernel_vsyscall symbol in
the vdso's symbol table is not changed.

AT_SYSINFO is the right way to go forward but it is not directly
accessible to userlevel code.  And it is no pointer which will make
architectures with function descriptors unhappy.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-12 16:31         ` Ulrich Drepper
@ 2004-05-12 16:57           ` Eric W. Biederman
  2004-05-12 21:32             ` Randy.Dunlap
  0 siblings, 1 reply; 31+ messages in thread
From: Eric W. Biederman @ 2004-05-12 16:57 UTC (permalink / raw)
  To: Ulrich Drepper; +Cc: Randy.Dunlap, fastboot, lkml

Ulrich Drepper <drepper@redhat.com> writes:

> Eric W. Biederman wrote:
> 
> > As a first draft we should be able to use the standard ELF mechanisms
> > for this.  It is not like PIC shared libraries were new.   Or is
> > there some specific problem you are thinking of with respect to
> > randomization?
> 
> The official kernel does not have vdso randomization.  Ingo has a patch
> for the Red Hat kernel which is used in the FC2 kernel.  The patch
> effectively only changes the location at which the vdso is mapped.  It
> does not change the vdso content.  So the __kernel_vsyscall symbol in
> the vdso's symbol table is not changed.
> 
> AT_SYSINFO is the right way to go forward but it is not directly
> accessible to userlevel code.  And it is no pointer which will make
> architectures with function descriptors unhappy.

It sounds like the vdso just needs to be treated as a prelinked
vdso.  You can find everything you need with AT_SYSINFO_EHDR.

In the case of function descriptors they should be in a data segment
that can get copied to another page, and corrected.  Leaving the code
segment at it's randomized location.

Eric


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-12 16:57           ` Eric W. Biederman
@ 2004-05-12 21:32             ` Randy.Dunlap
  2004-05-12 22:08               ` David Mosberger
  2004-05-14  5:21               ` Eric W. Biederman
  0 siblings, 2 replies; 31+ messages in thread
From: Randy.Dunlap @ 2004-05-12 21:32 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: drepper, fastboot, linux-kernel, akpm

On 12 May 2004 10:57:27 -0600 Eric W. Biederman wrote:

| Ulrich Drepper <drepper@redhat.com> writes:
| 
| > Eric W. Biederman wrote:
| > 
| > > As a first draft we should be able to use the standard ELF mechanisms
| > > for this.  It is not like PIC shared libraries were new.   Or is
| > > there some specific problem you are thinking of with respect to
| > > randomization?
| > 
| > The official kernel does not have vdso randomization.  Ingo has a patch
| > for the Red Hat kernel which is used in the FC2 kernel.  The patch
| > effectively only changes the location at which the vdso is mapped.  It
| > does not change the vdso content.  So the __kernel_vsyscall symbol in
| > the vdso's symbol table is not changed.

[1:]
| > AT_SYSINFO is the right way to go forward but it is not directly
| > accessible to userlevel code.  And it is no pointer which will make
| > architectures with function descriptors unhappy.
| 
| It sounds like the vdso just needs to be treated as a prelinked
| vdso.  You can find everything you need with AT_SYSINFO_EHDR.
| 
| In the case of function descriptors they should be in a data segment
| that can get copied to another page, and corrected.  Leaving the code
| segment at it's randomized location.

Andrew tells me that he is OK with reserving a syscall number for
kexec, which is easy & quick.  I don't know when vdso will be available
(for non-x86[2]) or when the AT_SYSINFO data will work for userlevel
code[1. above].

So is there any reason not to reserve the syscall number for kexec
for now?  (patch is below)

--
~Randy


[2] kexec is currently only available for x86, but there is interest
in it for ia64 and ppc64 at least.



diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-pv/arch/i386/kernel/entry.S linux-266-kexec/arch/i386/kernel/entry.S
--- linux-266-pv/arch/i386/kernel/entry.S	2004-05-09 19:32:26.000000000 -0700
+++ linux-266-kexec/arch/i386/kernel/entry.S	2004-05-11 16:46:27.000000000 -0700
@@ -891,5 +891,6 @@ ENTRY(sys_call_table)
 	.long sys_mq_timedreceive	/* 280 */
 	.long sys_mq_notify
 	.long sys_mq_getsetattr
+	.long sys_ni_syscall		/* reserved for kexec */
 
 syscall_table_size=(.-sys_call_table)
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-pv/include/asm-i386/unistd.h linux-266-kexec/include/asm-i386/unistd.h
--- linux-266-pv/include/asm-i386/unistd.h	2004-05-09 19:32:52.000000000 -0700
+++ linux-266-kexec/include/asm-i386/unistd.h	2004-05-11 16:45:32.000000000 -0700
@@ -288,8 +288,9 @@
 #define __NR_mq_timedreceive	(__NR_mq_open+3)
 #define __NR_mq_notify		(__NR_mq_open+4)
 #define __NR_mq_getsetattr	(__NR_mq_open+5)
+#define __NR_sys_kexec_load	283
 
-#define NR_syscalls 283
+#define NR_syscalls 284
 
 /* user-visible error numbers are in the range -1 - -124: see <asm-i386/errno.h> */
 

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-12 21:32             ` Randy.Dunlap
@ 2004-05-12 22:08               ` David Mosberger
  2004-05-12 22:28                 ` Andrew Morton
  2004-05-14  5:21               ` Eric W. Biederman
  1 sibling, 1 reply; 31+ messages in thread
From: David Mosberger @ 2004-05-12 22:08 UTC (permalink / raw)
  To: Randy.Dunlap; +Cc: Eric W. Biederman, drepper, fastboot, linux-kernel, akpm

>>>>> On Wed, 12 May 2004 14:32:33 -0700, "Randy.Dunlap" <rddunlap@osdl.org> said:

  Randy> I don't know when vdso will be available (for non-x86[2]) or

  Randy> [2] kexec is currently only available for x86, but there is interest
  Randy> in it for ia64 and ppc64 at least.

ia64 does have VDSO (and has had it for some time).

I quite like Uli's idea.

	--david

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-12 22:08               ` David Mosberger
@ 2004-05-12 22:28                 ` Andrew Morton
  2004-05-12 22:33                   ` David Mosberger
  0 siblings, 1 reply; 31+ messages in thread
From: Andrew Morton @ 2004-05-12 22:28 UTC (permalink / raw)
  To: davidm; +Cc: rddunlap, ebiederm, drepper, fastboot, linux-kernel

David Mosberger <davidm@napali.hpl.hp.com> wrote:
>
> >>>>> On Wed, 12 May 2004 14:32:33 -0700, "Randy.Dunlap" <rddunlap@osdl.org> said:
> 
>   Randy> I don't know when vdso will be available (for non-x86[2]) or
> 
>   Randy> [2] kexec is currently only available for x86, but there is interest
>   Randy> in it for ia64 and ppc64 at least.
> 
> ia64 does have VDSO (and has had it for some time).
> 
> I quite like Uli's idea.
> 

Is anyone doing VDSO development for x86?  I don't recall seeing anything.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-12 22:28                 ` Andrew Morton
@ 2004-05-12 22:33                   ` David Mosberger
  2004-05-12 23:16                     ` Andrew Morton
  0 siblings, 1 reply; 31+ messages in thread
From: David Mosberger @ 2004-05-12 22:33 UTC (permalink / raw)
  To: Andrew Morton; +Cc: davidm, rddunlap, ebiederm, drepper, fastboot, linux-kernel

>>>>> On Wed, 12 May 2004 15:28:15 -0700, Andrew Morton <akpm@osdl.org> said:

  >> ia64 does have VDSO (and has had it for some time).

  >> I quite like Uli's idea.

  Andrew> Is anyone doing VDSO development for x86?  I don't recall
  Andrew> seeing anything.

It's already there?

	--david

$ tail -17 arch/i386/kernel/vsyscall.lds
/*
 * This controls what symbols we export from the DSO.
 */
VERSION
{
  LINUX_2.5 {
    global:
        __kernel_vsyscall;
        __kernel_sigreturn;
        __kernel_rt_sigreturn;

    local: *;
  };
}

/* The ELF entry point can be used to set the AT_SYSINFO value.  */
ENTRY(__kernel_vsyscall);

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-12 22:33                   ` David Mosberger
@ 2004-05-12 23:16                     ` Andrew Morton
  2004-05-12 23:27                       ` David Mosberger
  2004-05-13  4:30                       ` Christoph Hellwig
  0 siblings, 2 replies; 31+ messages in thread
From: Andrew Morton @ 2004-05-12 23:16 UTC (permalink / raw)
  To: davidm; +Cc: rddunlap, ebiederm, drepper, fastboot, linux-kernel

David Mosberger <davidm@napali.hpl.hp.com> wrote:
>
> >>>>> On Wed, 12 May 2004 15:28:15 -0700, Andrew Morton <akpm@osdl.org> said:
> 
>   >> ia64 does have VDSO (and has had it for some time).
> 
>   >> I quite like Uli's idea.
> 
>   Andrew> Is anyone doing VDSO development for x86?  I don't recall
>   Andrew> seeing anything.
> 
> It's already there?

But it needs work for the kexec requirement.  If that work is purely the
addition of the kexec entry point then OK, that can be part of the kexec
patch.

But if we need additional infrastructure to "add new syscalls via VDSO" then
this should be in the base kernel, even if it's empty, yes?

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-12 23:16                     ` Andrew Morton
@ 2004-05-12 23:27                       ` David Mosberger
  2004-05-13  4:30                       ` Christoph Hellwig
  1 sibling, 0 replies; 31+ messages in thread
From: David Mosberger @ 2004-05-12 23:27 UTC (permalink / raw)
  To: Andrew Morton; +Cc: davidm, rddunlap, ebiederm, drepper, fastboot, linux-kernel

>>>>> On Wed, 12 May 2004 16:16:03 -0700, Andrew Morton <akpm@osdl.org> said:

  Andrew> But it needs work for the kexec requirement.

Sorry, I wasn't suggesting that kexec should be done that way _now_.

I don't think it's nearly as simple as just adding an entry point in
the DSO.  For example, how would strace be affected by the new entry
points?  The syscall entry path probably would have to be almost
duplicated to do a syscall-number-free entry.  What about syscall
restarting?  Would VDSO entry points work with statically linked
binaries? etc.

Perhaps Uli has answers to all of these, but no matter how you do it,
it'd be a pretty dramatic shift in how applications interact with the
kernel.

	--david

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-12 23:16                     ` Andrew Morton
  2004-05-12 23:27                       ` David Mosberger
@ 2004-05-13  4:30                       ` Christoph Hellwig
  2004-05-13  5:05                         ` Willy Tarreau
  2004-05-13  6:06                         ` Eric W. Biederman
  1 sibling, 2 replies; 31+ messages in thread
From: Christoph Hellwig @ 2004-05-13  4:30 UTC (permalink / raw)
  To: Andrew Morton; +Cc: davidm, rddunlap, ebiederm, drepper, fastboot, linux-kernel

On Wed, May 12, 2004 at 04:16:03PM -0700, Andrew Morton wrote:
> But if we need additional infrastructure to "add new syscalls via VDSO" then
> this should be in the base kernel, even if it's empty, yes?

Linus has vetoed dynamic syscall registration a few times.  And I agree
with him, dynamic syscalls are the best way to get completely crappy
interfaces.


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-13  4:30                       ` Christoph Hellwig
@ 2004-05-13  5:05                         ` Willy Tarreau
  2004-05-13  5:21                           ` William Lee Irwin III
  2004-05-13  5:48                           ` Christoph Hellwig
  2004-05-13  6:06                         ` Eric W. Biederman
  1 sibling, 2 replies; 31+ messages in thread
From: Willy Tarreau @ 2004-05-13  5:05 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton, davidm, rddunlap, ebiederm,
	drepper, fastboot, linux-kernel

On Thu, May 13, 2004 at 05:30:52AM +0100, Christoph Hellwig wrote:
> On Wed, May 12, 2004 at 04:16:03PM -0700, Andrew Morton wrote:
> > But if we need additional infrastructure to "add new syscalls via VDSO" then
> > this should be in the base kernel, even if it's empty, yes?
> 
> Linus has vetoed dynamic syscall registration a few times.  And I agree
> with him, dynamic syscalls are the best way to get completely crappy
> interfaces.

And why not definitely assign sort of a "multiplexed syscall" entry,
a la sys_socketcall() ? It could be shared by lots of non-mainline projects
and have a greater chance of being stable along the time.

Cheers,
Willy


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-13  5:05                         ` Willy Tarreau
@ 2004-05-13  5:21                           ` William Lee Irwin III
  2004-05-13  5:48                           ` Christoph Hellwig
  1 sibling, 0 replies; 31+ messages in thread
From: William Lee Irwin III @ 2004-05-13  5:21 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Christoph Hellwig, Andrew Morton, davidm, rddunlap, ebiederm,
	drepper, fastboot, linux-kernel

On Thu, May 13, 2004 at 07:05:15AM +0200, Willy Tarreau wrote:
> And why not definitely assign sort of a "multiplexed syscall" entry,
> a la sys_socketcall() ? It could be shared by lots of non-mainline projects
> and have a greater chance of being stable along the time.

That already exists and is every bit as hated as it should be.
It's called ioctl().


-- wli

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-13  5:05                         ` Willy Tarreau
  2004-05-13  5:21                           ` William Lee Irwin III
@ 2004-05-13  5:48                           ` Christoph Hellwig
  1 sibling, 0 replies; 31+ messages in thread
From: Christoph Hellwig @ 2004-05-13  5:48 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Andrew Morton, davidm, rddunlap, ebiederm, drepper, fastboot,
	linux-kernel

On Thu, May 13, 2004 at 07:05:15AM +0200, Willy Tarreau wrote:
> And why not definitely assign sort of a "multiplexed syscall" entry,
> a la sys_socketcall() ?

Because that's the worst possible API you could imagine.


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-13  4:30                       ` Christoph Hellwig
  2004-05-13  5:05                         ` Willy Tarreau
@ 2004-05-13  6:06                         ` Eric W. Biederman
  2004-05-13  6:20                           ` Andrew Morton
  2004-05-13  7:33                           ` Christoph Hellwig
  1 sibling, 2 replies; 31+ messages in thread
From: Eric W. Biederman @ 2004-05-13  6:06 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Andrew Morton, rddunlap, davidm, fastboot, linux-kernel, drepper

Christoph Hellwig <hch@infradead.org> writes:

> On Wed, May 12, 2004 at 04:16:03PM -0700, Andrew Morton wrote:
> > But if we need additional infrastructure to "add new syscalls via VDSO" then
> > this should be in the base kernel, even if it's empty, yes?
> 
> Linus has vetoed dynamic syscall registration a few times.  And I agree
> with him, dynamic syscalls are the best way to get completely crappy
> interfaces.

The only thing I was thinking of doing was to export the symbol
__kernel__NR_kexec_load.  With a little care we could probably export
the system call numbers just as easily from /proc/kallsyms.

At this point that idea seems to add no real benefit.  Except for
allowing for a user space that can more easily track syscall renumber in
the kernel, which seems to be the wrong problem to solve.

So if kexec could actually get a reserved system call number that
would be the best solution I have seen in this thread.

Andrew how close are we to a point where we can look at kexec inclusion?

Eric

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-13  6:06                         ` Eric W. Biederman
@ 2004-05-13  6:20                           ` Andrew Morton
  2004-05-13  6:39                             ` Eric W. Biederman
  2004-05-13  7:33                           ` Christoph Hellwig
  1 sibling, 1 reply; 31+ messages in thread
From: Andrew Morton @ 2004-05-13  6:20 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: hch, rddunlap, davidm, fastboot, linux-kernel, drepper

ebiederm@xmission.com (Eric W. Biederman) wrote:
>
> So if kexec could actually get a reserved system call number that
>  would be the best solution I have seen in this thread.

I have no problem with that - it's a major feature, vendors will, I assume,
ship it so it's worth blowing the four bytes to pin the ABI down for
everyone.

>  Andrew how close are we to a point where we can look at kexec inclusion?

Well it's not exactly head-of-queue.  Do any vendors actually intend to
ship it?


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-13  6:20                           ` Andrew Morton
@ 2004-05-13  6:39                             ` Eric W. Biederman
  0 siblings, 0 replies; 31+ messages in thread
From: Eric W. Biederman @ 2004-05-13  6:39 UTC (permalink / raw)
  To: Andrew Morton; +Cc: hch, rddunlap, davidm, fastboot, linux-kernel, drepper

Andrew Morton <akpm@osdl.org> writes:

> ebiederm@xmission.com (Eric W. Biederman) wrote:
> >
> > So if kexec could actually get a reserved system call number that
> >  would be the best solution I have seen in this thread.
> 
> I have no problem with that - it's a major feature, vendors will, I assume,
> ship it so it's worth blowing the four bytes to pin the ABI down for
> everyone.
> 
> >  Andrew how close are we to a point where we can look at kexec inclusion?
> 
> Well it's not exactly head-of-queue.  Do any vendors actually intend to
> ship it?

I know of a few products kexec is embedded in already.  As for the
general purpose distro's I don't know.

Eric

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-13  6:06                         ` Eric W. Biederman
  2004-05-13  6:20                           ` Andrew Morton
@ 2004-05-13  7:33                           ` Christoph Hellwig
  2004-05-13  7:37                             ` Andrew Morton
  1 sibling, 1 reply; 31+ messages in thread
From: Christoph Hellwig @ 2004-05-13  7:33 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Andrew Morton, rddunlap, davidm, fastboot, linux-kernel, drepper

On Thu, May 13, 2004 at 12:06:08AM -0600, Eric W. Biederman wrote:
> So if kexec could actually get a reserved system call number that
> would be the best solution I have seen in this thread.

Could you please show the syscall we should reserve, e.g. it's API.
We had quite some histroy of syscalls that got reserved and the real
submission was rejected neverless because the API was broken.


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-13  7:33                           ` Christoph Hellwig
@ 2004-05-13  7:37                             ` Andrew Morton
  2004-05-13  7:49                               ` Christoph Hellwig
  0 siblings, 1 reply; 31+ messages in thread
From: Andrew Morton @ 2004-05-13  7:37 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: ebiederm, rddunlap, davidm, fastboot, linux-kernel, drepper

Christoph Hellwig <hch@infradead.org> wrote:
>
> On Thu, May 13, 2004 at 12:06:08AM -0600, Eric W. Biederman wrote:
> > So if kexec could actually get a reserved system call number that
> > would be the best solution I have seen in this thread.
> 
> Could you please show the syscall we should reserve, e.g. it's API.
> We had quite some histroy of syscalls that got reserved and the real
> submission was rejected neverless because the API was broken.

The (old) kexec patch I have here implements the API which is described at
http://lwn.net/Articles/15468/.  I doubt if it changed?

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-13  7:37                             ` Andrew Morton
@ 2004-05-13  7:49                               ` Christoph Hellwig
  2004-05-13  8:04                                 ` Andrew Morton
  2004-05-13 15:02                                 ` Randy.Dunlap
  0 siblings, 2 replies; 31+ messages in thread
From: Christoph Hellwig @ 2004-05-13  7:49 UTC (permalink / raw)
  To: Andrew Morton; +Cc: ebiederm, rddunlap, davidm, fastboot, linux-kernel, drepper

On Thu, May 13, 2004 at 12:37:27AM -0700, Andrew Morton wrote:
> The (old) kexec patch I have here implements the API which is described at
> http://lwn.net/Articles/15468/.  I doubt if it changed?

That API looks sane to me.


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-13  7:49                               ` Christoph Hellwig
@ 2004-05-13  8:04                                 ` Andrew Morton
  2004-05-13 13:52                                   ` Eric W. Biederman
  2004-05-13 15:02                                 ` Randy.Dunlap
  1 sibling, 1 reply; 31+ messages in thread
From: Andrew Morton @ 2004-05-13  8:04 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: ebiederm, rddunlap, davidm, fastboot, linux-kernel, drepper

Christoph Hellwig <hch@infradead.org> wrote:
>
> On Thu, May 13, 2004 at 12:37:27AM -0700, Andrew Morton wrote:
> > The (old) kexec patch I have here implements the API which is described at
> > http://lwn.net/Articles/15468/.  I doubt if it changed?
> 
> That API looks sane to me.

yup.  Here's the syscall itself, btw:

+/*
+ * Exec Kernel system call: for obvious reasons only root may call it.
+ * 
+ * This call breaks up into three pieces.  
+ * - A generic part which loads the new kernel from the current
+ *   address space, and very carefully places the data in the
+ *   allocated pages.
+ *
+ * - A generic part that interacts with the kernel and tells all of
+ *   the devices to shut down.  Preventing on-going dmas, and placing
+ *   the devices in a consistent state so a later kernel can
+ *   reinitialize them.
+ *
+ * - A machine specific part that includes the syscall number
+ *   and the copies the image to it's final destination.  And
+ *   jumps into the image at entry.
+ *
+ * kexec does not sync, or unmount filesystems so if you need
+ * that to happen you need to do that yourself.
+ */
+struct kimage *kexec_image = 0;
+
+asmlinkage long sys_kexec_load(unsigned long entry, unsigned long nr_segments, 
+	struct kexec_segment *segments, unsigned long flags)
+{

+struct kexec_segment {
+	void *buf;
+	size_t bufsz;
+	void *mem;
+	size_t memsz;
+};


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-13  8:04                                 ` Andrew Morton
@ 2004-05-13 13:52                                   ` Eric W. Biederman
  0 siblings, 0 replies; 31+ messages in thread
From: Eric W. Biederman @ 2004-05-13 13:52 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Christoph Hellwig, rddunlap, davidm, fastboot, linux-kernel, drepper


I have no plans to change this API.  It has been reviewed and agreed upon.
At some point we might run into a problem where the flag field is needed
but currently it is a must be zero field.

Eric

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-13  7:49                               ` Christoph Hellwig
  2004-05-13  8:04                                 ` Andrew Morton
@ 2004-05-13 15:02                                 ` Randy.Dunlap
  1 sibling, 0 replies; 31+ messages in thread
From: Randy.Dunlap @ 2004-05-13 15:02 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: akpm, ebiederm, davidm, fastboot, linux-kernel, drepper

On Thu, 13 May 2004 08:49:31 +0100 Christoph Hellwig wrote:

| On Thu, May 13, 2004 at 12:37:27AM -0700, Andrew Morton wrote:
| > The (old) kexec patch I have here implements the API which is described at
| > http://lwn.net/Articles/15468/.  I doubt if it changed?
| 
| That API looks sane to me.

and current patches are kept at:
  http://developer.osdl.org/rddunlap/kexec/

for review, testing, etc.

--
~Randy

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-12 21:32             ` Randy.Dunlap
  2004-05-12 22:08               ` David Mosberger
@ 2004-05-14  5:21               ` Eric W. Biederman
  2004-05-14 18:14                 ` Adam Litke
  1 sibling, 1 reply; 31+ messages in thread
From: Eric W. Biederman @ 2004-05-14  5:21 UTC (permalink / raw)
  To: Randy.Dunlap; +Cc: akpm, fastboot, drepper, linux-kernel

"Randy.Dunlap" <rddunlap@osdl.org> writes:

> On 12 May 2004 10:57:27 -0600 Eric W. Biederman wrote:
> 
> | Ulrich Drepper <drepper@redhat.com> writes:
> | 
> | > Eric W. Biederman wrote:
> | > 
> | > > As a first draft we should be able to use the standard ELF mechanisms
> | > > for this.  It is not like PIC shared libraries were new.   Or is
> | > > there some specific problem you are thinking of with respect to
> | > > randomization?
> | > 
> | > The official kernel does not have vdso randomization.  Ingo has a patch
> | > for the Red Hat kernel which is used in the FC2 kernel.  The patch
> | > effectively only changes the location at which the vdso is mapped.  It
> | > does not change the vdso content.  So the __kernel_vsyscall symbol in
> | > the vdso's symbol table is not changed.
> 
> [1:]
> | > AT_SYSINFO is the right way to go forward but it is not directly
> | > accessible to userlevel code.  And it is no pointer which will make
> | > architectures with function descriptors unhappy.
> | 
> | It sounds like the vdso just needs to be treated as a prelinked
> | vdso.  You can find everything you need with AT_SYSINFO_EHDR.
> | 
> | In the case of function descriptors they should be in a data segment
> | that can get copied to another page, and corrected.  Leaving the code
> | segment at it's randomized location.
> 
> Andrew tells me that he is OK with reserving a syscall number for
> kexec, which is easy & quick.  I don't know when vdso will be available
> (for non-x86[2]) or when the AT_SYSINFO data will work for userlevel
> code[1. above].
> 
> So is there any reason not to reserve the syscall number for kexec
> for now?  (patch is below)
> 
> --
> ~Randy
> 
> 
> [2] kexec is currently only available for x86, but there is interest
> in it for ia64 and ppc64 at least.

Also been work on x86-64 and ppc32.   So if we are going to reserve
syscall numbers  it would also be nice to have those reserved as well.

Eric

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-14  5:21               ` Eric W. Biederman
@ 2004-05-14 18:14                 ` Adam Litke
  2004-05-15  2:25                   ` Eric W. Biederman
  0 siblings, 1 reply; 31+ messages in thread
From: Adam Litke @ 2004-05-14 18:14 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: Randy.Dunlap, akpm, fastboot, drepper, linux-kernel

On Thu, 2004-05-13 at 22:21, Eric W. Biederman wrote:
> Also been work on x86-64 and ppc32.   So if we are going to reserve
> syscall numbers  it would also be nice to have those reserved as well.

Don't forget about ppc64.

-- 
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-14 18:14                 ` Adam Litke
@ 2004-05-15  2:25                   ` Eric W. Biederman
  2004-05-17  0:49                     ` H. Peter Anvin
  0 siblings, 1 reply; 31+ messages in thread
From: Eric W. Biederman @ 2004-05-15  2:25 UTC (permalink / raw)
  To: Adam Litke; +Cc: akpm, Randy.Dunlap, fastboot, drepper, linux-kernel

Adam Litke <agl@us.ibm.com> writes:

> On Thu, 2004-05-13 at 22:21, Eric W. Biederman wrote:
> > Also been work on x86-64 and ppc32.   So if we are going to reserve
> > syscall numbers  it would also be nice to have those reserved as well.
> 
> Don't forget about ppc64.

Randy already mentioned it.  :)
Making the list of at least attempted ports:

x86, ppc64, ia64, x86-64, ppc32

But x86 and ppc64 seem to have the most developer interest.

Eric

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
  2004-05-15  2:25                   ` Eric W. Biederman
@ 2004-05-17  0:49                     ` H. Peter Anvin
  0 siblings, 0 replies; 31+ messages in thread
From: H. Peter Anvin @ 2004-05-17  0:49 UTC (permalink / raw)
  To: linux-kernel

Followup to:  <m11xlmxw7m.fsf@ebiederm.dsl.xmission.com>
By author:    ebiederm@xmission.com (Eric W. Biederman)
In newsgroup: linux.dev.kernel
> 
> Randy already mentioned it.  :)
> Making the list of at least attempted ports:
> 
> x86, ppc64, ia64, x86-64, ppc32
> 
> But x86 and ppc64 seem to have the most developer interest.
> 

It should probably be reserved on all architectures, unless the
architecture maintainers explicitly don't want to support it.

	-hpa

^ permalink raw reply	[flat|nested] 31+ messages in thread

end of thread, other threads:[~2004-05-17  0:50 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-05-12  4:26 [announce] kexec for linux 2.6.6 Randy.Dunlap
2004-05-12  5:00 ` Ulrich Drepper
2004-05-12  6:18   ` [Fastboot] " Eric W. Biederman
2004-05-12 15:33     ` Ulrich Drepper
2004-05-12 15:54       ` Eric W. Biederman
2004-05-12 16:31         ` Ulrich Drepper
2004-05-12 16:57           ` Eric W. Biederman
2004-05-12 21:32             ` Randy.Dunlap
2004-05-12 22:08               ` David Mosberger
2004-05-12 22:28                 ` Andrew Morton
2004-05-12 22:33                   ` David Mosberger
2004-05-12 23:16                     ` Andrew Morton
2004-05-12 23:27                       ` David Mosberger
2004-05-13  4:30                       ` Christoph Hellwig
2004-05-13  5:05                         ` Willy Tarreau
2004-05-13  5:21                           ` William Lee Irwin III
2004-05-13  5:48                           ` Christoph Hellwig
2004-05-13  6:06                         ` Eric W. Biederman
2004-05-13  6:20                           ` Andrew Morton
2004-05-13  6:39                             ` Eric W. Biederman
2004-05-13  7:33                           ` Christoph Hellwig
2004-05-13  7:37                             ` Andrew Morton
2004-05-13  7:49                               ` Christoph Hellwig
2004-05-13  8:04                                 ` Andrew Morton
2004-05-13 13:52                                   ` Eric W. Biederman
2004-05-13 15:02                                 ` Randy.Dunlap
2004-05-14  5:21               ` Eric W. Biederman
2004-05-14 18:14                 ` Adam Litke
2004-05-15  2:25                   ` Eric W. Biederman
2004-05-17  0:49                     ` H. Peter Anvin
2004-05-12  5:05 ` [Fastboot] " Eric W. Biederman

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).