On Wed, Jun 6, 2018 at 2:18 AM Leizhen (ThunderTown)
<thunder.leiz...@huawei.com> wrote:
>
> I found that glibc has already dealt with this case. So this issue must have
> been met before, should it be maintained by libc/user?
>
> if (GLRO(dl_sysinfo_dso) == NULL)
> {
> kact.sa_flags |= SA_RESTORER;
>
> kact.sa_restorer = ((act->sa_flags & SA_SIGINFO)
> ? &restore_rt : &restore);
> }
>
>
> On 2018/6/6 15:52, Leizhen (ThunderTown) wrote:
> >
> >
> > On 2018/6/5 19:24, Leizhen (ThunderTown) wrote:
> >> After I executed "echo 0 > /proc/sys/abi/vsyscall32" to disable vdso, the
> >> rt_sigaction01 test case from ltp_2015 failed.
> >> The test case source code please refer to the attachment, and the output
> >> as blow:
> >>
> >> -----------------
> >> ./rt_sigaction01
> >> rt_sigaction01 0 TINFO : signal: 34
> >> rt_sigaction01 1 TPASS : rt_sigaction call succeeded: result = 0
> >> rt_sigaction01 0 TINFO : sa.sa_flags = SA_RESETHAND|SA_SIGINFO
> >> rt_sigaction01 0 TINFO : Signal Handler Called with signal number 34
> >>
> >> Segmentation fault
> >> ------------------
> >>
> >>
> >> Is this the desired result? In function ia32_setup_rt_frame, I found below
> >> code:
> >>
> >> if (ksig->ka.sa.sa_flags & SA_RESTORER)
> >> restorer = ksig->ka.sa.sa_restorer;
> >> else
> >> restorer = current->mm->context.vdso +
> >> vdso_image_32.sym___kernel_rt_sigreturn;
> >> put_user_ex(ptr_to_compat(restorer), &frame->pretcode);
> >>
> >> Because the vdso is disabled, so current->mm->context.vdso is NULL, which
> >> cause the result of frame->pretcode invalid.
> >>
> >> I'm not sure whether this is a kernel bug or just an error of test case
> >> itself. Can anyone help me?
> >>
> >
>
>
I can't tell from your email what you're testing, what behavior you
expect, and what you saw. A program that sets up a signal handler
without supplying a restorer will not work if the vDSO is off, and
this is by design.
(FWIW, there is a very longstanding libc bug that causes this case to
get severely screwed up if the user's SS is not the expected value,
and that bug was just fixed very recently. But I doubt this is what
you're seeing.)
I suppose we could improve the kernel to at least push NULL instead of
some random address a bit above 0, but it'll still crash.
