Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
On 06/06/18 18:45, Leizhen (ThunderTown) wrote: >> >> The use of signals without SA_RESTORER is considered obsolete, but it's >> somewhat surprising that the vdso isn't there; it should be mapped even for >> static binaries esp. on i386 since it is the preferred way to do system >> calls (you don't need to parse the ELF for that.) Are you explicitly >> disabling the VDSO? If so, Don't Do That. > > Yes, the vdso was explicitly disabled by the tester. Thanks. > Are there any use cases that calls for this? Maybe we should drop this option. -hpa
Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
On 06/06/18 18:45, Leizhen (ThunderTown) wrote: >> >> The use of signals without SA_RESTORER is considered obsolete, but it's >> somewhat surprising that the vdso isn't there; it should be mapped even for >> static binaries esp. on i386 since it is the preferred way to do system >> calls (you don't need to parse the ELF for that.) Are you explicitly >> disabling the VDSO? If so, Don't Do That. > > Yes, the vdso was explicitly disabled by the tester. Thanks. > Are there any use cases that calls for this? Maybe we should drop this option. -hpa
Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
On 2018/6/7 10:39, Andy Lutomirski wrote:
>
>
>> On Jun 6, 2018, at 7:05 PM, Leizhen (ThunderTown)
>> wrote:
>>
>>
>>
>>> On 2018/6/7 1:01, Andy Lutomirski wrote:
>>> On Wed, Jun 6, 2018 at 2:18 AM Leizhen (ThunderTown)
>>> 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)
? _rt : );
}
> 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_sigaction010 TINFO : signal: 34
>> rt_sigaction011 TPASS : rt_sigaction call succeeded: result = 0
>> rt_sigaction010 TINFO : sa.sa_flags = SA_RESETHAND|SA_SIGINFO
>> rt_sigaction010 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), >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.
OK. Thanks a lot.
>
>>>
>>> .
>>>
>>
>> --
>> Thanks!
>> BestRegards
>>
>
> .
>
--
Thanks!
BestRegards
Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
On 2018/6/7 10:39, Andy Lutomirski wrote:
>
>
>> On Jun 6, 2018, at 7:05 PM, Leizhen (ThunderTown)
>> wrote:
>>
>>
>>
>>> On 2018/6/7 1:01, Andy Lutomirski wrote:
>>> On Wed, Jun 6, 2018 at 2:18 AM Leizhen (ThunderTown)
>>> 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)
? _rt : );
}
> 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_sigaction010 TINFO : signal: 34
>> rt_sigaction011 TPASS : rt_sigaction call succeeded: result = 0
>> rt_sigaction010 TINFO : sa.sa_flags = SA_RESETHAND|SA_SIGINFO
>> rt_sigaction010 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), >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.
OK. Thanks a lot.
>
>>>
>>> .
>>>
>>
>> --
>> Thanks!
>> BestRegards
>>
>
> .
>
--
Thanks!
BestRegards
Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
> On Jun 6, 2018, at 7:05 PM, Leizhen (ThunderTown)
> wrote:
>
>
>
>> On 2018/6/7 1:01, Andy Lutomirski wrote:
>> On Wed, Jun 6, 2018 at 2:18 AM Leizhen (ThunderTown)
>> 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)
>>>? _rt : );
>>>}
>>>
>>>
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_sigaction010 TINFO : signal: 34
> rt_sigaction011 TPASS : rt_sigaction call succeeded: result = 0
> rt_sigaction010 TINFO : sa.sa_flags = SA_RESETHAND|SA_SIGINFO
> rt_sigaction010 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), >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
>
Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
> On Jun 6, 2018, at 7:05 PM, Leizhen (ThunderTown)
> wrote:
>
>
>
>> On 2018/6/7 1:01, Andy Lutomirski wrote:
>> On Wed, Jun 6, 2018 at 2:18 AM Leizhen (ThunderTown)
>> 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)
>>>? _rt : );
>>>}
>>>
>>>
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_sigaction010 TINFO : signal: 34
> rt_sigaction011 TPASS : rt_sigaction call succeeded: result = 0
> rt_sigaction010 TINFO : sa.sa_flags = SA_RESETHAND|SA_SIGINFO
> rt_sigaction010 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), >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
>
Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
On 2018/6/7 1:01, Andy Lutomirski wrote:
> On Wed, Jun 6, 2018 at 2:18 AM Leizhen (ThunderTown)
> 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)
>> ? _rt : );
>> }
>>
>>
>> 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_sigaction010 TINFO : signal: 34
rt_sigaction011 TPASS : rt_sigaction call succeeded: result = 0
rt_sigaction010 TINFO : sa.sa_flags = SA_RESETHAND|SA_SIGINFO
rt_sigaction010 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), >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.
>
> .
>
--
Thanks!
BestRegards
Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
On 2018/6/7 1:01, Andy Lutomirski wrote:
> On Wed, Jun 6, 2018 at 2:18 AM Leizhen (ThunderTown)
> 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)
>> ? _rt : );
>> }
>>
>>
>> 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_sigaction010 TINFO : signal: 34
rt_sigaction011 TPASS : rt_sigaction call succeeded: result = 0
rt_sigaction010 TINFO : sa.sa_flags = SA_RESETHAND|SA_SIGINFO
rt_sigaction010 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), >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.
>
> .
>
--
Thanks!
BestRegards
Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
On 2018/6/7 1:48, h...@zytor.com wrote:
> On June 6, 2018 2:17:42 AM PDT, "Leizhen (ThunderTown)"
> 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)
>> ? _rt : );
>> }
>>
>>
>> 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_sigaction010 TINFO : signal: 34
rt_sigaction011 TPASS : rt_sigaction call succeeded: result =
>> 0
rt_sigaction010 TINFO : sa.sa_flags = SA_RESETHAND|SA_SIGINFO
rt_sigaction010 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), >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?
>>>
>
> The use of signals without SA_RESTORER is considered obsolete, but it's
> somewhat surprising that the vdso isn't there; it should be mapped even for
> static binaries esp. on i386 since it is the preferred way to do system calls
> (you don't need to parse the ELF for that.) Are you explicitly disabling the
> VDSO? If so, Don't Do That.
Yes, the vdso was explicitly disabled by the tester. Thanks.
>
--
Thanks!
BestRegards
Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
On 2018/6/7 1:48, h...@zytor.com wrote:
> On June 6, 2018 2:17:42 AM PDT, "Leizhen (ThunderTown)"
> 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)
>> ? _rt : );
>> }
>>
>>
>> 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_sigaction010 TINFO : signal: 34
rt_sigaction011 TPASS : rt_sigaction call succeeded: result =
>> 0
rt_sigaction010 TINFO : sa.sa_flags = SA_RESETHAND|SA_SIGINFO
rt_sigaction010 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), >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?
>>>
>
> The use of signals without SA_RESTORER is considered obsolete, but it's
> somewhat surprising that the vdso isn't there; it should be mapped even for
> static binaries esp. on i386 since it is the preferred way to do system calls
> (you don't need to parse the ELF for that.) Are you explicitly disabling the
> VDSO? If so, Don't Do That.
Yes, the vdso was explicitly disabled by the tester. Thanks.
>
--
Thanks!
BestRegards
Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
On June 6, 2018 2:17:42 AM PDT, "Leizhen (ThunderTown)"
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)
> ? _rt : );
> }
>
>
>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_sigaction010 TINFO : signal: 34
>>> rt_sigaction011 TPASS : rt_sigaction call succeeded: result =
>0
>>> rt_sigaction010 TINFO : sa.sa_flags = SA_RESETHAND|SA_SIGINFO
>>> rt_sigaction010 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), >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?
>>>
>>
The use of signals without SA_RESTORER is considered obsolete, but it's
somewhat surprising that the vdso isn't there; it should be mapped even for
static binaries esp. on i386 since it is the preferred way to do system calls
(you don't need to parse the ELF for that.) Are you explicitly disabling the
VDSO? If so, Don't Do That.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
On June 6, 2018 2:17:42 AM PDT, "Leizhen (ThunderTown)"
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)
> ? _rt : );
> }
>
>
>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_sigaction010 TINFO : signal: 34
>>> rt_sigaction011 TPASS : rt_sigaction call succeeded: result =
>0
>>> rt_sigaction010 TINFO : sa.sa_flags = SA_RESETHAND|SA_SIGINFO
>>> rt_sigaction010 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), >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?
>>>
>>
The use of signals without SA_RESTORER is considered obsolete, but it's
somewhat surprising that the vdso isn't there; it should be mapped even for
static binaries esp. on i386 since it is the preferred way to do system calls
(you don't need to parse the ELF for that.) Are you explicitly disabling the
VDSO? If so, Don't Do That.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
On Wed, Jun 6, 2018 at 2:18 AM Leizhen (ThunderTown)
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)
> ? _rt : );
> }
>
>
> 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_sigaction010 TINFO : signal: 34
> >> rt_sigaction011 TPASS : rt_sigaction call succeeded: result = 0
> >> rt_sigaction010 TINFO : sa.sa_flags = SA_RESETHAND|SA_SIGINFO
> >> rt_sigaction010 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), >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.
Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
On Wed, Jun 6, 2018 at 2:18 AM Leizhen (ThunderTown)
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)
> ? _rt : );
> }
>
>
> 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_sigaction010 TINFO : signal: 34
> >> rt_sigaction011 TPASS : rt_sigaction call succeeded: result = 0
> >> rt_sigaction010 TINFO : sa.sa_flags = SA_RESETHAND|SA_SIGINFO
> >> rt_sigaction010 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), >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.
Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
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)
? _rt : );
}
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_sigaction010 TINFO : signal: 34
>> rt_sigaction011 TPASS : rt_sigaction call succeeded: result = 0
>> rt_sigaction010 TINFO : sa.sa_flags = SA_RESETHAND|SA_SIGINFO
>> rt_sigaction010 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), >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?
>>
>
--
Thanks!
BestRegards
Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
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)
? _rt : );
}
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_sigaction010 TINFO : signal: 34
>> rt_sigaction011 TPASS : rt_sigaction call succeeded: result = 0
>> rt_sigaction010 TINFO : sa.sa_flags = SA_RESETHAND|SA_SIGINFO
>> rt_sigaction010 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), >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?
>>
>
--
Thanks!
BestRegards
