> On Jun 6, 2018, at 7:05 PM, Leizhen (ThunderTown)
> <thunder.leiz...@huawei.com> wrote:
>
>
>
>> On 2018/6/7 1:01, Andy Lutomirski wrote:
>> 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.
> OK, so that the user should take care whether the vDSO is disabled by itself
> or not, and use different strategies to process it appropriately, like glibc.
>
>>
>> (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.
> Should we add a warning? Which may help the user to aware this error in time.
>
It’s entirely valid to have a non working restorer if you never plan to return
from a signal handler. And anyone who writes their own libc should be able to
figure this out on their own, I think.
>>
>> .
>>
>
> --
> Thanks!
> BestRegards
>
