linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [Question] Can we use SIGRTMIN when vdso disabled on X86?
@ 2018-06-05 11:24 Leizhen (ThunderTown)
  2018-06-06  7:52 ` Is this a kernel BUG? ///Re: " Leizhen (ThunderTown)
  0 siblings, 1 reply; 10+ messages in thread
From: Leizhen (ThunderTown) @ 2018-06-05 11:24 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86l,
	Dominik Brodowski, Andy Lutomirski, linux-kernel
  Cc: yaomin2

[-- Attachment #1: Type: text/plain, Size: 1092 bytes --]

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?

-- 
Thanks!
BestRegards

[-- Attachment #2: rt_sigaction01.c --]
[-- Type: text/plain, Size: 4191 bytes --]

/******************************************************************************/
/* Copyright (c) Crackerjack Project., 2007                                   */
/*                                                                            */
/* This program is free software;  you can redistribute it and/or modify      */
/* it under the terms of the GNU General Public License as published by       */
/* the Free Software Foundation; either version 2 of the License, or          */
/* (at your option) any later version.                                        */
/*                                                                            */
/* This program is distributed in the hope that it will be useful,            */
/* but WITHOUT ANY WARRANTY;  without even the implied warranty of            */
/* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See                  */
/* the GNU General Public License for more details.                           */
/*                                                                            */
/* You should have received a copy of the GNU General Public License          */
/* along with this program;  if not, write to the Free Software Foundation,   */
/* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA           */
/*                                                                            */
/* History:     Porting from Crackerjack to LTP is done by                    */
/*              Manas Kumar Nayak maknayak@in.ibm.com>                        */
/******************************************************************************/

/******************************************************************************/
/* Description: This tests the rt_sigaction() syscall                         */
/*		rt_sigaction alters an action taken by a process on receipt   */
/* 		of a particular signal. The action is specified by the        */
/*		sigaction structure. The previous action on the signal is     */
/*		saved in oact.sigsetsize should indicate the size of a        */
/*		sigset_t type.                       			      */
/******************************************************************************/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>
#include <errno.h>
#include <sys/syscall.h>
#include <string.h>

#include "test.h"
#include "linux_syscall_numbers.h"
#include "lapi/rt_sigaction.h"

char *TCID = "rt_sigaction01";
static int testno;
int TST_TOTAL = 1;

static void cleanup(void)
{
	tst_rmdir();
}

static void setup(void)
{
	TEST_PAUSE;
	tst_tmpdir();
}

static int test_flags[] =
    { SA_RESETHAND | SA_SIGINFO, SA_RESETHAND, SA_RESETHAND | SA_SIGINFO,
SA_RESETHAND | SA_SIGINFO, SA_NOMASK };
char *test_flags_list[] =
    { "SA_RESETHAND|SA_SIGINFO", "SA_RESETHAND", "SA_RESETHAND|SA_SIGINFO",
"SA_RESETHAND|SA_SIGINFO", "SA_NOMASK" };

static void handler(int sig)
{
	tst_resm(TINFO, "Signal Handler Called with signal number %d\n", sig);
	return;
}

static int set_handler(int sig, int sig_to_mask, int mask_flags)
{
	struct sigaction sa, oldaction;

	sa.sa_handler = (void *)handler;
	sa.sa_flags = mask_flags;
	sigemptyset(&sa.sa_mask);
	sigaddset(&sa.sa_mask, sig);

	return ltp_rt_sigaction(sig, &sa, &oldaction, SIGSETSIZE);
}

int main(int ac, char **av)
{
	unsigned int flag;
	int signal;
	int lc;

	tst_parse_opts(ac, av, NULL, NULL);

	setup();

	for (lc = 0; TEST_LOOPING(lc); ++lc) {

		tst_count = 0;

		for (testno = 0; testno < TST_TOTAL; ++testno) {

			for (signal = SIGRTMIN; signal <= SIGRTMAX; signal++) {
				for (flag = 0;
				     flag <
				     (sizeof(test_flags) /
				      sizeof(test_flags[0])); flag++) {

					TEST(set_handler
					     (signal, 0, test_flags[flag]));

					if (TEST_RETURN == 0) {
						tst_resm(TINFO, "signal: %d ",
							 signal);
						tst_resm(TPASS,
							 "rt_sigaction call succeeded: result = %ld ",
							 TEST_RETURN);
						tst_resm(TINFO,
							 "sa.sa_flags = %s ",
							 test_flags_list[flag]);
						kill(getpid(), signal);
					} else {
						tst_resm(TFAIL | TTERRNO,
							 "rt_sigaction call "
							 "failed");
					}

				}

			}

		}

	}
	cleanup();
	tst_exit();
}

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
  2018-06-05 11:24 [Question] Can we use SIGRTMIN when vdso disabled on X86? Leizhen (ThunderTown)
@ 2018-06-06  7:52 ` Leizhen (ThunderTown)
  2018-06-06  9:17   ` Leizhen (ThunderTown)
  0 siblings, 1 reply; 10+ messages in thread
From: Leizhen (ThunderTown) @ 2018-06-06  7:52 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86l,
	Dominik Brodowski, Andy Lutomirski, linux-kernel
  Cc: yaomin2



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?
> 

-- 
Thanks!
BestRegards

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
  2018-06-06  7:52 ` Is this a kernel BUG? ///Re: " Leizhen (ThunderTown)
@ 2018-06-06  9:17   ` Leizhen (ThunderTown)
  2018-06-06 17:01     ` Andy Lutomirski
  2018-06-06 17:48     ` hpa
  0 siblings, 2 replies; 10+ messages in thread
From: Leizhen (ThunderTown) @ 2018-06-06  9:17 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86l,
	Dominik Brodowski, Andy Lutomirski, linux-kernel
  Cc: yaomin2, Thunder Town

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?
>>
> 

-- 
Thanks!
BestRegards

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
  2018-06-06  9:17   ` Leizhen (ThunderTown)
@ 2018-06-06 17:01     ` Andy Lutomirski
  2018-06-07  2:05       ` Leizhen (ThunderTown)
  2018-06-06 17:48     ` hpa
  1 sibling, 1 reply; 10+ messages in thread
From: Andy Lutomirski @ 2018-06-06 17:01 UTC (permalink / raw)
  To: thunder.leizhen
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, X86 ML,
	Dominik Brodowski, Andrew Lutomirski, LKML, yaomin2

On Wed, Jun 6, 2018 at 2:18 AM Leizhen (ThunderTown)
<thunder.leizhen@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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
  2018-06-06  9:17   ` Leizhen (ThunderTown)
  2018-06-06 17:01     ` Andy Lutomirski
@ 2018-06-06 17:48     ` hpa
  2018-06-07  1:45       ` Leizhen (ThunderTown)
  1 sibling, 1 reply; 10+ messages in thread
From: hpa @ 2018-06-06 17:48 UTC (permalink / raw)
  To: Leizhen (ThunderTown),
	Thomas Gleixner, Ingo Molnar, x86l, Dominik Brodowski,
	Andy Lutomirski, linux-kernel
  Cc: yaomin2, Thunder Town

On June 6, 2018 2:17:42 AM PDT, "Leizhen (ThunderTown)" <thunder.leizhen@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?
>>>
>> 

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
  2018-06-06 17:48     ` hpa
@ 2018-06-07  1:45       ` Leizhen (ThunderTown)
  2018-06-07 21:05         ` H. Peter Anvin
  0 siblings, 1 reply; 10+ messages in thread
From: Leizhen (ThunderTown) @ 2018-06-07  1:45 UTC (permalink / raw)
  To: hpa, Thomas Gleixner, Ingo Molnar, x86l, Dominik Brodowski,
	Andy Lutomirski, linux-kernel
  Cc: yaomin2



On 2018/6/7 1:48, hpa@zytor.com wrote:
> On June 6, 2018 2:17:42 AM PDT, "Leizhen (ThunderTown)" <thunder.leizhen@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?
>>>>
>>>
> 
> 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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
  2018-06-06 17:01     ` Andy Lutomirski
@ 2018-06-07  2:05       ` Leizhen (ThunderTown)
  2018-06-07  2:39         ` Andy Lutomirski
  0 siblings, 1 reply; 10+ messages in thread
From: Leizhen (ThunderTown) @ 2018-06-07  2:05 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, X86 ML,
	Dominik Brodowski, LKML, yaomin2



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:
>>
>> 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.

> 
> .
> 

-- 
Thanks!
BestRegards

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
  2018-06-07  2:05       ` Leizhen (ThunderTown)
@ 2018-06-07  2:39         ` Andy Lutomirski
  2018-06-07  3:10           ` Leizhen (ThunderTown)
  0 siblings, 1 reply; 10+ messages in thread
From: Andy Lutomirski @ 2018-06-07  2:39 UTC (permalink / raw)
  To: Leizhen (ThunderTown)
  Cc: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	X86 ML, Dominik Brodowski, LKML, yaomin2



> On Jun 6, 2018, at 7:05 PM, Leizhen (ThunderTown) <thunder.leizhen@huawei.com> wrote:
> 
> 
> 
>> 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:
>>> 
>>> 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
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
  2018-06-07  2:39         ` Andy Lutomirski
@ 2018-06-07  3:10           ` Leizhen (ThunderTown)
  0 siblings, 0 replies; 10+ messages in thread
From: Leizhen (ThunderTown) @ 2018-06-07  3:10 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	X86 ML, Dominik Brodowski, LKML, yaomin2



On 2018/6/7 10:39, Andy Lutomirski wrote:
> 
> 
>> On Jun 6, 2018, at 7:05 PM, Leizhen (ThunderTown) <thunder.leizhen@huawei.com> wrote:
>>
>>
>>
>>> 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:
>>>>
>>>> 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.

OK. Thanks a lot.

> 
>>>
>>> .
>>>
>>
>> -- 
>> Thanks!
>> BestRegards
>>
> 
> .
> 

-- 
Thanks!
BestRegards

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
  2018-06-07  1:45       ` Leizhen (ThunderTown)
@ 2018-06-07 21:05         ` H. Peter Anvin
  0 siblings, 0 replies; 10+ messages in thread
From: H. Peter Anvin @ 2018-06-07 21:05 UTC (permalink / raw)
  To: Leizhen (ThunderTown),
	Thomas Gleixner, Ingo Molnar, x86l, Dominik Brodowski,
	Andy Lutomirski, linux-kernel
  Cc: yaomin2

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2018-06-07 21:06 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-05 11:24 [Question] Can we use SIGRTMIN when vdso disabled on X86? Leizhen (ThunderTown)
2018-06-06  7:52 ` Is this a kernel BUG? ///Re: " Leizhen (ThunderTown)
2018-06-06  9:17   ` Leizhen (ThunderTown)
2018-06-06 17:01     ` Andy Lutomirski
2018-06-07  2:05       ` Leizhen (ThunderTown)
2018-06-07  2:39         ` Andy Lutomirski
2018-06-07  3:10           ` Leizhen (ThunderTown)
2018-06-06 17:48     ` hpa
2018-06-07  1:45       ` Leizhen (ThunderTown)
2018-06-07 21:05         ` H. Peter Anvin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).