Re: [LTP] [PATCH] syscalls: fix some failure on arch X86_64

[liubo <liubo2009@cn.fujitsu.com>]

Hi,
> Yes. I [mostly] fixed the rt_sigaction01 test a few hours ago. A
> summary of the issues with the old version:
>
> 1. The test as it was written before verified functionality by
> ensuring that coredumps and crashes didn't occur. The new version
> either catches the appropriate rt signal and increments, or catches
> SIGSEGV and continues. Eventually once all of the issues are worked
> out with SIGRTMIN, the known issue TINFO printout needs to be removed
> from include/ltp_signal.h
> 2. If the sa_flags field of a struct sigaction `object' specifies
> SA_SIGINFO, you should and must use sa_sigaction instead of
> sa_handler, as stated in the manpage, because sa_handler and
> sa_sigaction are a union structure on many architectures, or not
> present when rt_* not implemented.
> 3. An autoconf test was added to look for sa_sigaction in struct
> sigaction, as it isn't present on all architectures.
>
> So, while this does fix rt_sigaction01, by and large, the following
> issues still exist with the rt_sig* syscalls:
> 1. SIGRTMIN always SIGSEGV's because signal_fault is being called in
> arch/x86/kernel/signal.c . I need to put some printk's in the code to
> understand why -EFAULT is being thrown, and thus why signal_fault is
> being tossed.
> 2. rt_sigprocmask01 and rt_sigsuspend01 still segfault for the same
> reason, as noted in 1.
>
>     Someone in the kernel.org team should generate some kind of
> documentation to clarify several points (including architectural
> quirks) with the rt_sig* syscalls. This trial and error problem
> solving isn't very helpful and there are a fair number of gotchas
> involved with implementing a functional set of sigaction-like calls
> using rt_sig*.
>
> Thanks,
> -Garrett
>
>
>   
I've made a patch to fix this rt_sig problem, but I encounted a trouble.

I figured out that syscall __NR_rt_sigaction doesn't use struct
sigaction, and glibc defines a
struct called kernel_sigaction to fit __NR_rt_sigaction so that glibc
function can pass it.
And the struct sigaction may change in the future.

My trouble is if we define a struct to fit this syscall just as what
glibc does, after the struct
sigaction change, we'll define another struct as well.

Looking forward to any advice about this trouble...


Thanks,
Liubo 

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list