Hi Linus,
please pull from 'for-linus' branch of
git://git390.osdl.marist.edu/pub/scm/linux-2.6.git for-linus
to receive s390 updates. Please note that this includes the new s390 vdso
support which Martin posted on linux-kernel and linux-arch.
I'm aware that I missed the merge window. This is because I would have
liked to see the kernel message catalogue go in first since the vdso code
did depend on the kmsg patches and would have generated a merge conflict.
But...
So since this is late feel free to ignore and we will have to wait for
the 2.6.29 merge window.
The s390 vdso preparation patch "arch_setup_additional_pages argument"
touches other architectures (x86, sh and powerpc):
arch_setup_additional_pages currently gets two arguments, the binary
format descripton and an indication if the process uses an executable
stack or not. The second argument is not used by anybody, it could
be removed without replacement.
What actually does make sense is to pass an indication if the process
uses the elf interpreter or not. The glibc code will not use anything
from the vdso if the process does not use the dynamic linker, so for
statically linked binaries the architecture backend can choose not
to map the vdso.
Thanks,
Heiko
Christian Borntraeger (3):
[S390] vmcp: remove BKL
[S390] pgtables: Fix race in enable_sie vs. page table ops
[S390] s390: Fix build for !CONFIG_S390_GUEST + CONFIG_VIRTIO_CONSOLE
Frank Munzert (2):
[S390] tape block: complete request with correct locking
[S390] tape: disable interrupts in tape_open and tape_release
Heiko Carstens (3):
[S390] Fix sysdev class file creation.
[S390] Change default IPL method to IPL_VM.
[S390] No more 4kb stacks.
Jan Glauber (2):
[S390] qdio: prevent double qdio shutdown in case of I/O errors
[S390] qdio: remove incorrect memset
Martin Schwidefsky (2):
[S390] arch_setup_additional_pages arguments
[S390] introduce vdso on s390
Roel Kluin (1):
[S390] appldata: unsigned ops->size cannot be negative
arch/powerpc/include/asm/elf.h | 2 +-
arch/powerpc/kernel/vdso.c | 3 +-
arch/s390/Kconfig | 19 ++--
arch/s390/appldata/appldata_base.c | 2 +-
arch/s390/include/asm/auxvec.h | 2 +
arch/s390/include/asm/elf.h | 16 ++
arch/s390/include/asm/kvm_virtio.h | 2 +-
arch/s390/include/asm/mmu.h | 4 +-
arch/s390/include/asm/mmu_context.h | 19 ++-
arch/s390/include/asm/page.h | 2 +
arch/s390/include/asm/pgtable.h | 8 +-
arch/s390/include/asm/thread_info.h | 5 -
arch/s390/include/asm/vdso.h | 39 +++++
arch/s390/kernel/Makefile | 7 +-
arch/s390/kernel/asm-offsets.c | 15 ++
arch/s390/kernel/smp.c | 24 ++--
arch/s390/kernel/time.c | 31 ++++
arch/s390/kernel/vdso.c | 232 ++++++++++++++++++++++++++++++
arch/s390/kernel/vdso32/Makefile | 55 +++++++
arch/s390/kernel/vdso32/clock_getres.S | 39 +++++
arch/s390/kernel/vdso32/clock_gettime.S | 128 ++++++++++++++++
arch/s390/kernel/vdso32/gettimeofday.S | 82 +++++++++++
arch/s390/kernel/vdso32/note.S | 12 ++
arch/s390/kernel/vdso32/vdso32.lds.S | 138 ++++++++++++++++++
arch/s390/kernel/vdso32/vdso32_wrapper.S | 13 ++
arch/s390/kernel/vdso64/Makefile | 55 +++++++
arch/s390/kernel/vdso64/clock_getres.S | 39 +++++
arch/s390/kernel/vdso64/clock_gettime.S | 89 ++++++++++++
arch/s390/kernel/vdso64/gettimeofday.S | 56 +++++++
arch/s390/kernel/vdso64/note.S | 12 ++
arch/s390/kernel/vdso64/vdso64.lds.S | 138 ++++++++++++++++++
arch/s390/kernel/vdso64/vdso64_wrapper.S | 13 ++
arch/s390/mm/pgtable.c | 16 +-
arch/sh/include/asm/elf.h | 2 +-
arch/sh/kernel/vsyscall/vsyscall.c | 3 +-
arch/x86/include/asm/elf.h | 2 +-
arch/x86/vdso/vdso32-setup.c | 2 +-
arch/x86/vdso/vma.c | 2 +-
drivers/s390/char/tape_block.c | 6 +-
drivers/s390/char/tape_core.c | 8 +-
drivers/s390/char/vmcp.c | 3 -
drivers/s390/cio/qdio_debug.c | 19 +--
drivers/s390/cio/qdio_main.c | 1 -
fs/binfmt_elf.c | 2 +-
44 files changed, 1286 insertions(+), 81 deletions(-)
create mode 100644 arch/s390/include/asm/vdso.h
create mode 100644 arch/s390/kernel/vdso.c
create mode 100644 arch/s390/kernel/vdso32/Makefile
create mode 100644 arch/s390/kernel/vdso32/clock_getres.S
create mode 100644 arch/s390/kernel/vdso32/clock_gettime.S
create mode 100644 arch/s390/kernel/vdso32/gettimeofday.S
create mode 100644 arch/s390/kernel/vdso32/note.S
create mode 100644 arch/s390/kernel/vdso32/vdso32.lds.S
create mode 100644 arch/s390/kernel/vdso32/vdso32_wrapper.S
create mode 100644 arch/s390/kernel/vdso64/Makefile
create mode 100644 arch/s390/kernel/vdso64/clock_getres.S
create mode 100644 arch/s390/kernel/vdso64/clock_gettime.S
create mode 100644 arch/s390/kernel/vdso64/gettimeofday.S
create mode 100644 arch/s390/kernel/vdso64/note.S
create mode 100644 arch/s390/kernel/vdso64/vdso64.lds.S
create mode 100644 arch/s390/kernel/vdso64/vdso64_wrapper.S
* Heiko Carstens <[email protected]> wrote:
> The s390 vdso preparation patch "arch_setup_additional_pages argument"
> touches other architectures (x86, sh and powerpc):
>
> arch_setup_additional_pages currently gets two arguments, the binary
> format descripton and an indication if the process uses an executable
> stack or not. The second argument is not used by anybody, it could be
> removed without replacement.
hm, this is the first time i've seen this change, and it looks a bit
weird:
--- a/arch/x86/include/asm/elf.h
+++ b/arch/x86/include/asm/elf.h
@@ -325,7 +325,7 @@ struct linux_binprm;
#define ARCH_HAS_SETUP_ADDITIONAL_PAGES 1
extern int arch_setup_additional_pages(struct linux_binprm *bprm,
- int executable_stack);
+ int uses_interp);
why didnt you just add a new uses_interp argument?
executable_stack is passed in to potentially enable architectures to be
aware of how conservative/legacy the address-space of the binary is -
whether to randomize the vdso, etc. exec-shield used to take advantage
of that.
But there seems to be no in-tree use of that (and if one arises it can
just add back that parameter), and i dont want to stand in the way of
your pull request either, so for the x86 bits:
Acked-by: Ingo Molnar <[email protected]>
Ingo
On Fri, 2008-10-24 at 13:37 +0200, Ingo Molnar wrote:
> * Heiko Carstens <[email protected]> wrote:
>
> > The s390 vdso preparation patch "arch_setup_additional_pages argument"
> > touches other architectures (x86, sh and powerpc):
> >
> > arch_setup_additional_pages currently gets two arguments, the binary
> > format descripton and an indication if the process uses an executable
> > stack or not. The second argument is not used by anybody, it could be
> > removed without replacement.
>
> hm, this is the first time i've seen this change,
The code is relatively new and I planned it for the merge window for
2.6.29. I still have to nag our performance team to do some tests with
it.
> and it looks a bit weird:
>
> --- a/arch/x86/include/asm/elf.h
> +++ b/arch/x86/include/asm/elf.h
> @@ -325,7 +325,7 @@ struct linux_binprm;
>
> #define ARCH_HAS_SETUP_ADDITIONAL_PAGES 1
> extern int arch_setup_additional_pages(struct linux_binprm *bprm,
> - int executable_stack);
> + int uses_interp);
>
> why didnt you just add a new uses_interp argument?
I could have but I noticed at the same time that executable_stack is
unused. If somebody finds a need for the executable_stack argument it
can easily re-added but I can't think of a use for it. Ergo I removed
it.
> executable_stack is passed in to potentially enable architectures to be
> aware of how conservative/legacy the address-space of the binary is -
> whether to randomize the vdso, etc. exec-shield used to take advantage
> of that.
What has address space layout / randomization to do with
executable_stack? You lost me there.
> But there seems to be no in-tree use of that (and if one arises it can
> just add back that parameter), and i dont want to stand in the way of
> your pull request either, so for the x86 bits:
>
> Acked-by: Ingo Molnar <[email protected]>
Thanks. I'll add it.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
* Martin Schwidefsky <[email protected]> wrote:
> On Fri, 2008-10-24 at 13:37 +0200, Ingo Molnar wrote:
> > * Heiko Carstens <[email protected]> wrote:
> >
> > > The s390 vdso preparation patch "arch_setup_additional_pages argument"
> > > touches other architectures (x86, sh and powerpc):
> > >
> > > arch_setup_additional_pages currently gets two arguments, the binary
> > > format descripton and an indication if the process uses an executable
> > > stack or not. The second argument is not used by anybody, it could be
> > > removed without replacement.
> >
> > hm, this is the first time i've seen this change,
>
> The code is relatively new and I planned it for the merge window for
> 2.6.29. I still have to nag our performance team to do some tests
> with it.
okay, then i'm confused, the subject line says v2.6.28:
[GIT PULL] s390 updates for 2.6.28-rc1
(i have still no objections to those small x86 bits.)
> > #define ARCH_HAS_SETUP_ADDITIONAL_PAGES 1
> > extern int arch_setup_additional_pages(struct linux_binprm *bprm,
> > - int executable_stack);
> > + int uses_interp);
> >
> > why didnt you just add a new uses_interp argument?
>
> I could have but I noticed at the same time that executable_stack is
> unused. If somebody finds a need for the executable_stack argument
> it can easily re-added but I can't think of a use for it. Ergo I
> removed it.
>
> > executable_stack is passed in to potentially enable architectures
> > to be aware of how conservative/legacy the address-space of the
> > binary is - whether to randomize the vdso, etc. exec-shield used
> > to take advantage of that.
>
> What has address space layout / randomization to do with
> executable_stack? You lost me there.
it's just a historic/quirky connection (non-executable stack was the
first and biggest step towards a more flexible address space layout) -
you were correct to have it cleaned up.
Ingo
On Mon, 2008-10-27 at 12:51 +0100, Ingo Molnar wrote:
> * Martin Schwidefsky <[email protected]> wrote:
> > On Fri, 2008-10-24 at 13:37 +0200, Ingo Molnar wrote:
> > > * Heiko Carstens <[email protected]> wrote:
> > >
> > > > The s390 vdso preparation patch "arch_setup_additional_pages argument"
> > > > touches other architectures (x86, sh and powerpc):
> > > >
> > > > arch_setup_additional_pages currently gets two arguments, the binary
> > > > format descripton and an indication if the process uses an executable
> > > > stack or not. The second argument is not used by anybody, it could be
> > > > removed without replacement.
> > >
> > > hm, this is the first time i've seen this change,
> >
> > The code is relatively new and I planned it for the merge window for
> > 2.6.29. I still have to nag our performance team to do some tests
> > with it.
>
> okay, then i'm confused, the subject line says v2.6.28:
>
> [GIT PULL] s390 updates for 2.6.28-rc1
>
> (i have still no objections to those small x86 bits.)
Yeah, that was a misunderstanding between Heiko and me. I planned it for
2.6.29 and didn't tell him about it before I left for vacation. Heiko
just went ahead and added it the 2.6.28-rc1 pull request.
> > > #define ARCH_HAS_SETUP_ADDITIONAL_PAGES 1
> > > extern int arch_setup_additional_pages(struct linux_binprm *bprm,
> > > - int executable_stack);
> > > + int uses_interp);
> > >
> > > why didnt you just add a new uses_interp argument?
> >
> > I could have but I noticed at the same time that executable_stack is
> > unused. If somebody finds a need for the executable_stack argument
> > it can easily re-added but I can't think of a use for it. Ergo I
> > removed it.
> >
> > > executable_stack is passed in to potentially enable architectures
> > > to be aware of how conservative/legacy the address-space of the
> > > binary is - whether to randomize the vdso, etc. exec-shield used
> > > to take advantage of that.
> >
> > What has address space layout / randomization to do with
> > executable_stack? You lost me there.
>
> it's just a historic/quirky connection (non-executable stack was the
> first and biggest step towards a more flexible address space layout) -
> you were correct to have it cleaned up.
Ok, thanks. Less confused now.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
* Martin Schwidefsky <[email protected]> wrote:
> On Mon, 2008-10-27 at 12:51 +0100, Ingo Molnar wrote:
> > * Martin Schwidefsky <[email protected]> wrote:
> > > On Fri, 2008-10-24 at 13:37 +0200, Ingo Molnar wrote:
> > > > * Heiko Carstens <[email protected]> wrote:
> > > >
> > > > > The s390 vdso preparation patch "arch_setup_additional_pages argument"
> > > > > touches other architectures (x86, sh and powerpc):
> > > > >
> > > > > arch_setup_additional_pages currently gets two arguments, the binary
> > > > > format descripton and an indication if the process uses an executable
> > > > > stack or not. The second argument is not used by anybody, it could be
> > > > > removed without replacement.
> > > >
> > > > hm, this is the first time i've seen this change,
> > >
> > > The code is relatively new and I planned it for the merge window for
> > > 2.6.29. I still have to nag our performance team to do some tests
> > > with it.
> >
> > okay, then i'm confused, the subject line says v2.6.28:
> >
> > [GIT PULL] s390 updates for 2.6.28-rc1
> >
> > (i have still no objections to those small x86 bits.)
>
> Yeah, that was a misunderstanding between Heiko and me. I planned it
> for 2.6.29 and didn't tell him about it before I left for vacation.
> Heiko just went ahead and added it the 2.6.28-rc1 pull request.
ah, that's the happy variant.
> > it's just a historic/quirky connection (non-executable stack was
> > the first and biggest step towards a more flexible address space
> > layout) - you were correct to have it cleaned up.
>
> Ok, thanks. Less confused now.
maybe someone gets interested in cleaning up those bits. Our ASRL-fu
is still a bit ... random all around.
Ingo