Skip to contentSkip to conversation

vdso for parisc-linux

RFC In review Randolph Chung 2 participants 6 messages Oct 29, 2006 – Nov 2, 2006 PA-RISC architecture

lore
Share & tools
lore
#0 lore raw

RFC 1/1 vdso for parisc-linux

At kyle's urging, i've started an initial implementation of vdso support
for parisc-linux. I've attached what I have so far for some initial
comments. This is primarily based on the ppc vdso infrastructure.

Some things to consider:
1) The vdso object need to be mapped to userspace apps at some "default" location. In fact the kernel will look for an available vma using get_unmapped_area(). Right now I've arbitrarily picked 0x8000'0000. This should be reviewed.... one idea is to just map them at at the same place that shared libs are mapped (near 0x4000'0000). The bigger concern is whether we should make the mapping with MAP_SHARED so that the shared area is mapped congruent in all userspace apps that use the vdso. ppc doesn't do this.

2) our mmu_context_t used to be a single int that stores the space id of the current process. This has been extended into a struct that stores the space id and the vdso base address

3) 64-bit vdso does not work yet. Right now I am seeing binutils errors if i try to build a 64-bit vdso. For now this support is disabled -- it's not like we have 64-bit userspace anyway.

4) I haven't hooked up all the actual vdso functions yet, but with this patch userspace can see the functions exposed from the kernel, we can use gdb to put breakpoints in the vdso, etc.

5) We need to figure out which functions we want to expose. Several other archs expose gettimeofday and clock_get_time via vdso. For us, atomic ops are also prime candidates. Several archs also use the vdso to provide a cleaner signal trampoline interface. The latter mostly requires somebody to write up all the proper cfi instructions into sigtramp.S

As part of testing this, I also noticed that our gas does not support cfi directives that were added to binutils some time ago. I've submitted a patch for this.

glibc will need some work to get this to work. As a first step we need a dl-sysdep.h that defines:
#define NEED_DL_SYSINFO_DSO 1

If you use upstream glibc this is already enabled for all targets, but debian glibc will need this added if you want to test.

Anyway, please let me know if you have any comments.

randolph

arch/parisc/Makefile +10 -0
index 9b7e424..b6ff54e 100644
@@ -31,6 +31,16 @@ CROSS_COMPILE	:= hppa-linux-
 endif
 endif
 
+# Set default 32 bits cross compilers for vdso and boot wrapper
+CROSS32_COMPILE ?=
+
+CROSS32CC		:= $(CROSS32_COMPILE)gcc
+CROSS32AS		:= $(CROSS32_COMPILE)as
+CROSS32LD		:= $(CROSS32_COMPILE)ld
+CROSS32AR		:= $(CROSS32_COMPILE)ar
+CROSS32OBJCOPY		:= $(CROSS32_COMPILE)objcopy
+export CROSS32CC CROSS32AS CROSS32LD CROSS32AR CROSS32OBJCOPY
+
 FINAL_LD=$(CROSS_COMPILE)ld --warn-common --warn-section-align 
 
 OBJCOPY_FLAGS =-O binary -R .note -R .comment -S
arch/parisc/kernel/Makefile +1 -1
index 27827bc..db84c0d 100644
@@ -12,7 +12,7 @@ obj-y	     	:= cache.o pacache.o setup.o
 		   ptrace.o hardware.o inventory.o drivers.o semaphore.o \
 		   signal.o hpmc.o real2.o parisc_ksyms.o unaligned.o \
 		   process.o processor.o pdc_cons.o pdc_chassis.o unwind.o \
-		   topology.o
+		   topology.o vdso.o vdso32/
 
 obj-$(CONFIG_SMP)	+= smp.o
 obj-$(CONFIG_PA11)	+= pci-dma.o
arch/parisc/kernel/asm-offsets.c +27 -0
index c11a5bc..5effa4b 100644
@@ -32,12 +32,15 @@ #include <linux/sched.h>
 #include <linux/thread_info.h>
 #include <linux/ptrace.h>
 #include <linux/hardirq.h>
+#include <linux/time.h>
 
 #include <asm/pgtable.h>
 #include <asm/ptrace.h>
 #include <asm/processor.h>
 #include <asm/pdc.h>
 #include <asm/uaccess.h>
+#include <asm/vdso_datapage.h>
+#include <asm/compat.h>
 
 #define DEFINE(sym, val) \
 	asm volatile("\n->" #sym " %0 " #val : : "i" (val))
@@ -297,5 +300,29 @@ int main(void)
 	DEFINE(EXCDATA_IP, offsetof(struct exception_data, fault_ip));
 	DEFINE(EXCDATA_SPACE, offsetof(struct exception_data, fault_space));
 	DEFINE(EXCDATA_ADDR, offsetof(struct exception_data, fault_addr));
+
+	/* timeval/timezone offsets for use by vdso */
+	DEFINE(TZONE_TZ_MINWEST, offsetof(struct timezone, tz_minuteswest));
+	DEFINE(TZONE_TZ_DSTTIME, offsetof(struct timezone, tz_dsttime));
+
+	/* vdso datapage offsets */
+	DEFINE(VDSO_SYSCALL_MAP32, offsetof(struct vdso_data, syscall_map_32));
+#ifdef CONFIG_64BIT
+	DEFINE(VDSO_SYSCALL_MAP64, offsetof(struct vdso_data, syscall_map_64));
+#endif
+	DEFINE(VDSO_TZ_MINUTEWEST, offsetof(struct vdso_data, tz_minuteswest));
+	DEFINE(VDSO_TZ_DSTTIME, offsetof(struct vdso_data, tz_dsttime));
+	DEFINE(VDSO_WTOM_CLOCK_SEC, offsetof(struct vdso_data, wtom_clock_sec));
+	DEFINE(VDSO_WTOM_CLOCK_NSEC, offsetof(struct vdso_data, wtom_clock_nsec));
+
+#ifdef CONFIG_64BIT
+	DEFINE(TVAL64_TV_SEC, offsetof(struct timeval, tv_sec));
+	DEFINE(TVAL64_TV_USEC, offsetof(struct timeval, tv_usec));
+	DEFINE(TVAL32_TV_SEC, offsetof(struct compat_timeval, tv_sec));
+	DEFINE(TVAL32_TV_USEC, offsetof(struct compat_timeval, tv_usec));
+#else
+	DEFINE(TVAL32_TV_SEC, offsetof(struct timeval, tv_sec));
+	DEFINE(TVAL32_TV_USEC, offsetof(struct timeval, tv_usec));
+#endif
 	return 0;
 }
arch/parisc/kernel/vdso.c new file +617 -0

617 lines not on this page · raw message

arch/parisc/kernel/vdso32/Makefile new file +41 -0

41 lines not on this page · raw message

arch/parisc/kernel/vdso32/datapage.S new file +35 -0
new file mode 100644
index 0000000..e9fdc59
@@ -0,0 +1,35 @@
+/*
+ * Access to the shared data page by the vDSO & syscall map
+ *
+ * Copyright (C) 2006 Randolph Chung <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include <asm/processor.h>
+#include <asm/asm-offsets.h>
+#include <asm/unistd.h>
+#include <asm/vdso.h>
+
+	.text
+	.globl __get_datapage
+	.type __get_datapage, @function
+__get_datapage:
+	.proc
+	.callinfo NO_CALLS
+	.entry
+	/* We don't want that exposed or overridable as we want other objects
+	 * to be able to bl directly to here
+	 */
+	bl	.+12, %r1
+	depi	0, 31, 2, %r1
+	.global	__kernel_datapage_offset;
+__kernel_datapage_offset:
+	.long	0
+1:
+	bv	%r0(%r2)
+	ldw	0(%r1), %r28
+	.exit
+	.procend
arch/parisc/kernel/vdso32/gettimeofday.S new file +64 -0

64 lines not on this page · raw message

arch/parisc/kernel/vdso32/note.S new file +25 -0
new file mode 100644
index 0000000..d4b5be4
@@ -0,0 +1,25 @@
+/*
+ * This supplies .note.* sections to go into the PT_NOTE inside the vDSO text.
+ * Here we can supply some information useful to userland.
+ */
+
+#include <linux/uts.h>
+#include <linux/version.h>
+
+#define ASM_ELF_NOTE_BEGIN(name, flags, vendor, type)			      \
+	.section name, flags;						      \
+	.balign 4;							      \
+	.long 1f - 0f;		/* name length */			      \
+	.long 3f - 2f;		/* data length */			      \
+	.long type;		/* note type */				      \
+0:	.asciz vendor;		/* vendor name */			      \
+1:	.balign 4;							      \
+2:
+
+#define ASM_ELF_NOTE_END						      \
+3:	.balign 4;		/* pad out section */			      \
+	.previous
+
+	ASM_ELF_NOTE_BEGIN(".note.kernel-version", "a", UTS_SYSNAME, 0)
+	.long LINUX_VERSION_CODE
+	ASM_ELF_NOTE_END
arch/parisc/kernel/vdso32/sigtramp.S new file +167 -0

167 lines not on this page · raw message

arch/parisc/kernel/vdso32/vdso32.lds.S new file +111 -0

111 lines not on this page · raw message

arch/parisc/kernel/vdso32/vdso32_wrapper.S new file +13 -0
new file mode 100644
index 0000000..edd9e91
@@ -0,0 +1,13 @@
+#include <linux/init.h>
+#include <asm/page.h>
+
+	.section ".data.page_aligned"
+
+	.globl vdso32_start, vdso32_end
+	.balign PAGE_SIZE
+vdso32_start:
+	.incbin "arch/parisc/kernel/vdso32/vdso32.so"
+	.balign PAGE_SIZE
+vdso32_end:
+
+	.previous
arch/parisc/mm/init.c +3 -0
index 0e449f9..06c74de 100644
@@ -29,6 +29,7 @@ #include <asm/tlb.h>
 #include <asm/pdc_chassis.h>
 #include <asm/mmzone.h>
 #include <asm/sections.h>
+#include <asm/vdso.h>
 
 DEFINE_PER_CPU(struct mmu_gather, mmu_gathers);
 
@@ -541,6 +542,8 @@ #ifdef CONFIG_DEBUG_KERNEL /* double-san
 	       _text, _etext,
 	       ((unsigned long)_etext - (unsigned long)_text) >> 10);
 #endif
+
+	vdso_init();
 }
 
 unsigned long *empty_zero_page __read_mostly;
include/asm-parisc/auxvec.h +5 -0
index 9c3ac4b..d49902d 100644
@@ -1,4 +1,9 @@
 #ifndef __ASMPARISC_AUXVEC_H
 #define __ASMPARISC_AUXVEC_H
 
+/* The vDSO location. We have to use the same value as x86 for glibc's
+ * sake :-)
+ */
+#define AT_SYSINFO_EHDR		33
+
 #endif
include/asm-parisc/cacheflush.h +5 -5
index 2bc41f2..b62563d 100644
@@ -83,13 +83,13 @@ static inline void flush_cache_range(str
 {
 	int sr3;
 
-	if (!vma->vm_mm->context) {
+	if (!vma->vm_mm->context.space_id) {
 		BUG();
 		return;
 	}
 
 	sr3 = mfsp(3);
-	if (vma->vm_mm->context == sr3) {
+	if (vma->vm_mm->context.space_id == sr3) {
 		flush_user_dcache_range(start,end);
 		flush_user_icache_range(start,end);
 	} else {
@@ -149,7 +149,7 @@ flush_user_cache_page_non_current(struct
 
 	/* make us current */
 	mtctl(__pa(vma->vm_mm->pgd), 25);
-	mtsp(vma->vm_mm->context, 3);
+	mtsp(vma->vm_mm->context.space_id, 3);
 
 	flush_user_dcache_page(vmaddr);
 	if(vma->vm_flags & VM_EXEC)
@@ -164,7 +164,7 @@ flush_user_cache_page_non_current(struct
 static inline void
 __flush_cache_page(struct vm_area_struct *vma, unsigned long vmaddr)
 {
-	if (likely(vma->vm_mm->context == mfsp(3))) {
+	if (likely(vma->vm_mm->context.space_id == mfsp(3))) {
 		flush_user_dcache_page(vmaddr);
 		if (vma->vm_flags & VM_EXEC)
 			flush_user_icache_page(vmaddr);
@@ -176,7 +176,7 @@ __flush_cache_page(struct vm_area_struct
 static inline void
 flush_cache_page(struct vm_area_struct *vma, unsigned long vmaddr, unsigned long pfn)
 {
-	BUG_ON(!vma->vm_mm->context);
+	BUG_ON(!vma->vm_mm->context.space_id);
 
 	if (likely(translation_exists(vma, vmaddr, pfn)))
 		__flush_cache_page(vma, vmaddr);
include/asm-parisc/elf.h +11 -0
index adea65f..81e232d 100644
@@ -297,6 +297,17 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_N
 
 struct task_struct;
 
+#define ARCH_HAS_SETUP_ADDITIONAL_PAGES
+struct linux_binprm;
+extern int arch_setup_additional_pages(struct linux_binprm *bprm,
+				       int executable_stack);
+#define VDSO_AUX_ENT(a,b) NEW_AUX_ENT(a,b);
+
+#define ARCH_DLINFO						\
+do {								\
+	NEW_AUX_ENT(AT_SYSINFO_EHDR, current->mm->context.vdso_base); \
+} while (0)
+
 extern int dump_task_fpu (struct task_struct *, elf_fpregset_t *);
 #define ELF_CORE_COPY_FPREGS(tsk, elf_fpregs) dump_task_fpu(tsk, elf_fpregs)
 
include/asm-parisc/mmu.h +4 -2
index 6a310cf..b9175c9 100644
@@ -1,7 +1,9 @@
 #ifndef _PARISC_MMU_H_
 #define _PARISC_MMU_H_
 
-/* On parisc, we store the space id here */
-typedef unsigned long mm_context_t;
+typedef struct {
+	unsigned long space_id;
+	unsigned long vdso_base;
+} mm_context_t;
 
 #endif /* _PARISC_MMU_H_ */
include/asm-parisc/mmu_context.h +8 -8
index 9c05836..0fa9679 100644
@@ -21,24 +21,24 @@ init_new_context(struct task_struct *tsk
 {
 	BUG_ON(atomic_read(&mm->mm_users) != 1);
 
-	mm->context = alloc_sid();
+	mm->context.space_id = alloc_sid();
 	return 0;
 }
 
 static inline void
 destroy_context(struct mm_struct *mm)
 {
-	free_sid(mm->context);
-	mm->context = 0;
+	free_sid(mm->context.space_id);
+	mm->context.space_id = 0;
 }
 
 static inline void load_context(mm_context_t context)
 {
-	mtsp(context, 3);
+	mtsp(context.space_id, 3);
 #if SPACEID_SHIFT == 0
-	mtctl(context << 1,8);
+	mtctl(context.space_id << 1,8);
 #else
-	mtctl(context >> (SPACEID_SHIFT - 1),8);
+	mtctl(context.space_id >> (SPACEID_SHIFT - 1),8);
 #endif
 }
 
@@ -65,8 +65,8 @@ static inline void activate_mm(struct mm
 
 	BUG_ON(next == &init_mm); /* Should never happen */
 
-	if (next->context == 0)
-	    next->context = alloc_sid();
+	if (next->context.space_id == 0)
+	    next->context.space_id = alloc_sid();
 
 	switch_mm(prev,next,current);
 }
include/asm-parisc/page.h +3 -1
index dcf9047..091048d 100644
@@ -12,9 +12,11 @@ # define PAGE_SHIFT	16
 #else
 # error "unknown default kernel page size"
 #endif
-#define PAGE_SIZE	(1UL << PAGE_SHIFT)
+#define PAGE_SIZE	(1 << PAGE_SHIFT)
 #define PAGE_MASK	(~(PAGE_SIZE-1))
 
+/* We do define AT_SYSINFO_EHDR but don't use the gate mechanism */
+#define __HAVE_ARCH_GATE_AREA		1
 
 #ifndef __ASSEMBLY__
 
include/asm-parisc/processor.h +2 -2
index fd7866d..74ba37b 100644
@@ -181,7 +181,7 @@ typedef unsigned int elf_caddr_t;
 
 #define start_thread_som(regs, new_pc, new_sp) do {	\
 	unsigned long *sp = (unsigned long *)new_sp;	\
-	__u32 spaceid = (__u32)current->mm->context;	\
+	__u32 spaceid = (__u32)current->mm->context.space_id;	\
 	unsigned long pc = (unsigned long)new_pc;	\
 	/* offset pc for priv. level */			\
 	pc |= 3;					\
@@ -285,7 +285,7 @@ #endif
 
 #define start_thread(regs, new_pc, new_sp) do {		\
 	elf_addr_t *sp = (elf_addr_t *)new_sp;		\
-	__u32 spaceid = (__u32)current->mm->context;	\
+	__u32 spaceid = (__u32)current->mm->context.space_id;	\
 	elf_addr_t pc = (elf_addr_t)new_pc | 3;		\
 	elf_caddr_t *argv = (elf_caddr_t *)bprm->exec + 1;	\
 							\
include/asm-parisc/tlbflush.h +5 -5
index f662e83..5625b76 100644
@@ -47,9 +47,9 @@ #ifdef CONFIG_SMP
 	flush_tlb_all();
 #else
 	if (mm) {
-		if (mm->context != 0)
-			free_sid(mm->context);
-		mm->context = alloc_sid();
+		if (mm->context.space_id != 0)
+			free_sid(mm->context.space_id);
+		mm->context.space_id = alloc_sid();
 		if (mm == current->active_mm)
 			load_context(mm->context);
 	}
@@ -66,7 +66,7 @@ static inline void flush_tlb_page(struct
 	/* For one page, it's not worth testing the split_tlb variable */
 
 	mb();
-	mtsp(vma->vm_mm->context,1);
+	mtsp(vma->vm_mm->context.space_id,1);
 	purge_tlb_start();
 	pdtlb(addr);
 	pitlb(addr);
@@ -82,7 +82,7 @@ static inline void flush_tlb_range(struc
 	if (npages >= 512)  /* 2MB of space: arbitrary, should be tuned */
 		flush_tlb_all();
 	else {
-		mtsp(vma->vm_mm->context,1);
+		mtsp(vma->vm_mm->context.space_id,1);
 		purge_tlb_start();
 		if (split_tlb) {
 			while (npages--) {
include/asm-parisc/vdso.h new file +44 -0

44 lines not on this page · raw message

include/asm-parisc/vdso_datapage.h new file +43 -0

43 lines not on this page · raw message

_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

#1 lore raw
Quoted 3 lines · Randolph Chung

At kyle's urging, i've started an initial implementation of vdso support
for parisc-linux. I've attached what I have so far for some initial
comments. This is primarily based on the ppc vdso infrastructure.

Awesome work, thanks for working on a vDSO initial implementation!

Quoted 9 lines

Some things to consider:
1) The vdso object need to be mapped to userspace apps at some "default" location. In fact the kernel will look for an available vma using get_unmapped_area(). Right now I've arbitrarily picked 0x8000'0000. This should be reviewed.... one idea is to just map them at at the same place that shared libs are mapped (near 0x4000'0000). The bigger concern is whether we should make the mapping with MAP_SHARED so that the shared area is mapped congruent in all userspace apps that use the vdso. ppc doesn't do this.

Users may enable or disable the vDSO on their system as a configuration option. Therefore glibc can't rely on the vDSO being present. How would this effect a prelinking implementation for hppa? I think I would rather see the vDSO at a high address, and enable MAP_SHARED. What is wrong with enabling MAP_SHARED?

Quoted 3 lines

2) our mmu_context_t used to be a single int that stores the space id of the current process. This has been extended into a struct that stores the space id and the vdso base address

This is good, we need the vdso base.

Quoted 3 lines

4) I haven't hooked up all the actual vdso functions yet, but with this patch userspace can see the functions exposed from the kernel, we can use gdb to put breakpoints in the vdso, etc.

You use the word "can", but have you tried to put breakpoints in the vDSO code pages?

Quoted 6 lines

5) We need to figure out which functions we want to expose. Several other archs expose gettimeofday and clock_get_time via vdso. For us, atomic ops are also prime candidates. Several archs also use the vdso to provide a cleaner signal trampoline interface. The latter mostly requires somebody to write up all the proper cfi instructions into sigtramp.S

atomic ops are *not* prime candidates for vDSO's, I was wrong about this. There are special requirements for the atomic operations which require access to kernel locks, no scheduling, and no signals. All of these are impossible to do if gdb can write to code, thus we put the atomic ops on the gateway page (which has the aforementioned special properties).

The rest of your suggestions are great. Signal trampoline handlers are #1 on the list of cleanups. We already know HPUX does something similar.

Quoted 7 lines

As part of testing this, I also noticed that our gas does not support cfi directives that were added to binutils some time ago. I've submitted a patch for this.

glibc will need some work to get this to work. As a first step we need a dl-sysdep.h that defines:
#define NEED_DL_SYSINFO_DSO 1

Thanks!

Quoted 4 lines

If you use upstream glibc this is already enabled for all targets, but debian glibc will need this added if you want to test.

Anyway, please let me know if you have any comments.

What testing do we need to do before you check this into git?

Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

#2 lore raw
Quoted 10 lines
Quoted 9 lines

Some things to consider:
1) The vdso object need to be mapped to userspace apps at some "default" location. In fact the kernel will look for an available vma using get_unmapped_area(). Right now I've arbitrarily picked 0x8000'0000. This should be reviewed.... one idea is to just map them at at the same place that shared libs are mapped (near 0x4000'0000). The bigger concern is whether we should make the mapping with MAP_SHARED so that the shared area is mapped congruent in all userspace apps that use the vdso. ppc doesn't do this.

Quoted 3 lines

Users may enable or disable the vDSO on their system as a configuration option. Therefore glibc can't rely on the vDSO being present. How would this effect a prelinking implementation for hppa? I

glibc looks for a special ELF AUX header to find out about the address of the vdso. If it's not present, then it won't call the vdso....

The implementation for this is cleaner in cvs glibc than in debian glibc.

I'm not quite sure how this interacts with prelink.

Quoted 2 lines

think I would rather see the vDSO at a high address, and enable MAP_SHARED. What is wrong with enabling MAP_SHARED?

I can't think of one, although it needs to be marked MAY_WRITE so that if we put a breakpoint the page will get COW'ed. Need to look at this some more.

Quoted 6 lines
Quoted 3 lines

4) I haven't hooked up all the actual vdso functions yet, but with this patch userspace can see the functions exposed from the kernel, we can use gdb to put breakpoints in the vdso, etc.

You use the word "can", but have you tried to put breakpoints in the vDSO code pages?

yes, it works.

Quoted 6 lines

atomic ops are *not* prime candidates for vDSO's, I was wrong about this. There are special requirements for the atomic operations which require access to kernel locks, no scheduling, and no signals. All of these are impossible to do if gdb can write to code, thus we put the atomic ops on the gateway page (which has the aforementioned special properties).

i can't quite see how lws disables scheduling... maybe you can enlighten me :)

Quoted 3 lines

The rest of your suggestions are great. Signal trampoline handlers are #1 on the list of cleanups. We already know HPUX does something similar.

Well, there are two parts:
1) Finding "sigreturn"
2) Finding the system state on the stack

Right now this is all done on parisc-linux by poking in memory using magic constants.

On HPUX, #1 is available symbolically, but #2 still requires poking in memory using magic constants. It is particularly nasty on HPUX because the kernel can store state in either narrow or wide mode and the offsets are not fixed.

Quoted 6 lines
Quoted 4 lines

If you use upstream glibc this is already enabled for all targets, but debian glibc will need this added if you want to test.

Anyway, please let me know if you have any comments.

What testing do we need to do before you check this into git?

What I have is just infrastructure, we need to add some functionality into it :)

randolph
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

#3 lore raw
Quoted 15 lines · Randolph Chung
Quoted 6 lines

atomic ops are *not* prime candidates for vDSO's, I was wrong about this. There are special requirements for the atomic operations which require access to kernel locks, no scheduling, and no signals. All of these are impossible to do if gdb can write to code, thus we put the atomic ops on the gateway page (which has the aforementioned special properties).

i can't quite see how lws disables scheduling... maybe you can enlighten me :)

Well, there are two parts:
1) Finding "sigreturn"
2) Finding the system state on the stack

Quoted 7 lines

Right now this is all done on parisc-linux by poking in memory using magic constants.

On HPUX, #1 is available symbolically, but #2 still requires poking in memory using magic constants. It is particularly nasty on HPUX because the kernel can store state in either narrow or wide mode and the offsets are not fixed.

On parisc-linux there is *always* a 32-bit system state on the stack. If you have a 64-bit kernel there is an auxiliary section which contains the register top-halves. I think we can conjure up some magic to determine which structure is on the stack.

Quoted 4 lines
Quoted 1 line

What testing do we need to do before you check this into git?

What I have is just infrastructure, we need to add some functionality into it :)

Yes, but if it gets checked into git it makes it easier to keep it from bitrotting.
With your HK timezone it makes coordinating more difficult.

Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

#5 lore raw
In reply to Randolph Chung
Quoted 9 lines · Randolph Chung
Quoted 6 lines

atomic ops are *not* prime candidates for vDSO's, I was wrong about this. There are special requirements for the atomic operations which require access to kernel locks, no scheduling, and no signals. All of these are impossible to do if gdb can write to code, thus we put the atomic ops on the gateway page (which has the aforementioned special properties).

i can't quite see how lws disables scheduling... maybe you can enlighten me :)

LWS doesn't disable scheduling. See arch/parisc/kernel/syscall.S

arch/parisc/kernel/syscall.S
547 /* NOTES:
548 This all works becuse intr_do_signal
549 and schedule both check the return iasq
550 and see that we are on the kernel page
551 so this process is never scheduled off
552 or is ever sent any signal of any sort,
553 thus it is wholly atomic from usrspaces
554 perspective
555 */

Checks like this:
arch/parisc/kernel/entry.S
1023 intr_do_resched:
1024 /* Only call schedule on return to userspace. If we're returning 1025 * to kernel space, we may schedule if CONFIG_PREEMPT, otherwise 1026 * we jump back to intr_restore.
1027 */
1028 LDREG PT_IASQ0(%r16), %r20
1029 CMPIB= 0, %r20, intr_do_preempt
1030 nop

Mean that if we take an interrupt while on the gateway page, the PT_IASQ0 should be zero and prevent intr_do_preempt, or intr_do_signal, or any other protected intr_* action.

Scheduling isn't a bit problem, but signals cause deadlocks.

Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

#4 lore raw
In reply to Carlos O'Donell
Quoted 6 lines
Quoted 2 lines

What I have is just infrastructure, we need to add some functionality into it :)

Yes, but if it gets checked into git it makes it easier to keep it from bitrotting.
With your HK timezone it makes coordinating more difficult.

For people who are interested, this is now on the vdso branch in git.

randolph

_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux