Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
From:   Andy Lutomirski <luto@amacapital.net>
In-Reply-To: <5B1892F5.9000206@huawei.com>
Date:   Wed, 6 Jun 2018 19:39:50 -0700
Cc:     Andy Lutomirski <luto@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, X86 ML <x86@kernel.org>,
        Dominik Brodowski <linux@dominikbrodowski.net>,
        LKML <linux-kernel@vger.kernel.org>, yaomin2@huawei.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <A95BD803-E0E2-4E49-B3EF-D056F1D69883@amacapital.net>
References: <5B1672FE.4050705@huawei.com> <5B1792C9.8010203@huawei.com> <5B17A6B6.70300@huawei.com> <CALCETrXiaqyAKzcT17P35Gf6fNBchPYF_JsQ+3ezNeETs_UTbA@mail.gmail.com> <5B1892F5.9000206@huawei.com>
To:     "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Jun 6, 2018, at 7:05 PM, Leizhen (ThunderTown) <thunder.leizhen@huawei.=
com> wrote:
>=20
>=20
>=20
>> On 2018/6/7 1:01, Andy Lutomirski wrote:
>> On Wed, Jun 6, 2018 at 2:18 AM Leizhen (ThunderTown)
>> <thunder.leizhen@huawei.com> wrote:
>>>=20
>>> I found that glibc has already dealt with this case. So this issue must h=
ave been met before, should it be maintained by libc/user?
>>>=20
>>>        if (GLRO(dl_sysinfo_dso) =3D=3D NULL)
>>>        {
>>>                kact.sa_flags |=3D SA_RESTORER;
>>>=20
>>>                kact.sa_restorer =3D ((act->sa_flags & SA_SIGINFO)
>>>                        ? &restore_rt : &restore);
>>>        }
>>>=20
>>>=20
>>>> On 2018/6/6 15:52, Leizhen (ThunderTown) wrote:
>>>>=20
>>>>=20
>>>>> On 2018/6/5 19:24, Leizhen (ThunderTown) wrote:
>>>>> After I executed "echo 0 > /proc/sys/abi/vsyscall32" to disable vdso, t=
he rt_sigaction01 test case from ltp_2015 failed.
>>>>> The test case source code please refer to the attachment, and the outp=
ut as blow:
>>>>>=20
>>>>> -----------------
>>>>> ./rt_sigaction01
>>>>> rt_sigaction01    0  TINFO  :  signal: 34
>>>>> rt_sigaction01    1  TPASS  :  rt_sigaction call succeeded: result =3D=
 0
>>>>> rt_sigaction01    0  TINFO  :  sa.sa_flags =3D SA_RESETHAND|SA_SIGINFO=

>>>>> rt_sigaction01    0  TINFO  :  Signal Handler Called with signal numbe=
r 34
>>>>>=20
>>>>> Segmentation fault
>>>>> ------------------
>>>>>=20
>>>>>=20
>>>>> Is this the desired result? In function ia32_setup_rt_frame, I found b=
elow code:
>>>>>=20
>>>>>     if (ksig->ka.sa.sa_flags & SA_RESTORER)
>>>>>             restorer =3D ksig->ka.sa.sa_restorer;
>>>>>     else
>>>>>             restorer =3D current->mm->context.vdso +
>>>>>                     vdso_image_32.sym___kernel_rt_sigreturn;
>>>>>     put_user_ex(ptr_to_compat(restorer), &frame->pretcode);
>>>>>=20
>>>>> Because the vdso is disabled, so current->mm->context.vdso is NULL, wh=
ich cause the result of frame->pretcode invalid.
>>>>>=20
>>>>> I'm not sure whether this is a kernel bug or just an error of test cas=
e itself. Can anyone help me?
>>>>>=20
>>>>=20
>>>=20
>>>=20
>>=20
>> 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 itse=
lf or not, and use different strategies to process it appropriately, like gl=
ibc.
>=20
>>=20
>> (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.)
>>=20
>> 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 ti=
me.
>=20

It=E2=80=99s 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 shoul=
d be able to figure this out on their own, I think.

>>=20
>> .
>>=20
>=20
> --=20
> Thanks!
> BestRegards
>=20