All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric W. Biederman <ebiederm@xmission.com>
To: ltp@lists.linux.it
Subject: [LTP] rt_sigqueueinfo: Invalid argument
Date: Mon, 08 Oct 2018 17:52:57 +0200	[thread overview]
Message-ID: <87va6cwi3q.fsf@xmission.com> (raw)
In-Reply-To: <CA+G9fYvK4CBeAzcvzh1w5bcq9tgpFpum5yTjrnCxYQHmfzJ4_A@mail.gmail.com> (Naresh Kamboju's message of "Mon, 8 Oct 2018 20:22:00 +0530")

Naresh Kamboju <naresh.kamboju@linaro.org> writes:

> + Eric
>
> Eric,
> If you have any comments.
> Good note is that, you broke the test and we need to fix it for better
> test coverage :-)


Ok.  So I have tracked down the test and I think I see what is going on.
I believe this is the source code to your failing test:
https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/rt_sigqueueinfo/rt_sigqueueinfo01.c

There are two cases I have changed that might possibly break something.
One was verifying that si_signo matched sig.  This is my second report
and it feels credible that that change was a regression in userspace and
I have fixed that in my development branch and that should be showing
up in linux-next in a day or so.

The other change is verifying that the tail end of siginfo_t is 0 if
we don't recognize the si_code.  In this case SI_QUEUE is hard coded
so that check should not be coming into play.

Thank you for letting me know this broke an ltp test.

I was hoping that no one would care but it is clear now that people
really do ignore si_signo in favor of the signal parameter of the system
call.  So not fixing this would be introducing regressions in
applications.

Eric

> Thank you.
>
> On Mon, 8 Oct 2018 at 18:36, Jan Stancek <jstancek@redhat.com> wrote:
>>
>>
>>
>> ----- Original Message -----
>> > Hi!
>> > > rt_sigqueueinfo01 failed on all device (x86_64, i386, arm / arm64)
>> > > started failing from Linux version 4.19.0-rc6-next-20181004.
>> > > Do you see this failure at your end?
>> > >
>> > > rt_sigqueueinfo01: rt_sigqueueinfo: Invalid argument
>> > > rt_sigqueueinfo01: rt_sigqueueinfo: Invalid argument
>> > > rt_sigqueueinfo01    1  TFAIL  :  rt_sigqueueinfo01.c:97: Test Failed
>> > > rt_sigqueueinfo01    0  TINFO  :  Failed to record test working dir
>> > > rt_sigqueueinfo01    1  TFAIL  :  rt_sigqueueinfo01.c:97: Test Failed
>> > > rt_sigqueueinfo01    0  TINFO  :  Failed to record test working dir
>> > > rt_sigqueueinfo01    2  TFAIL  :  rt_sigqueueinfo01.c:97: Test Failed
>> > >
>> > > Full log  details.
>> > > https://lkft.validation.linaro.org/scheduler/job/451548#L10339
>> >
>> > I do not recall seeing this test to fail.
>> >
>> > However the test is old messy code, one thing that I guess may happen is
>> > that there is random garbage in the siginfo_t structure we pass to the
>> > syscall and in you case you were unlucky enough so that kernel rejects
>> > the value, but that is just wild guess.
>>
>
> Jan,
>
>> Mainline doesn't seem to mind if we pass garbage atm. (4.19-rc7)
>> but we should initialize entire struct anyway.
>>
>> In -next there is:
>>   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/kernel/signal.c?id=e75dc036c445b91b8b2ad4e6c9b05f04b6be6d3f
>> and test doesn't set si_signo.
>
> Thanks for the quick reply.
> This help me a lot.
>
>>
>> Regards,
>> Jan
>>
>> >
>
> Cyril,
>
>> > Btw, I've opened an issue to clean up the test in:
>> >
>> > https://github.com/linux-test-project/ltp/issues/404
>
> Thanks for creating an issue. I have subscribed to this one.
>
> - Naresh
>
>> >
>> > --
>> > Cyril Hrubis
>> > chrubis@suse.cz
>> >

      reply	other threads:[~2018-10-08 15:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-08 12:26 [LTP] rt_sigqueueinfo: Invalid argument Naresh Kamboju
2018-10-08 12:45 ` Cyril Hrubis
2018-10-08 13:06   ` Jan Stancek
2018-10-08 14:52     ` Naresh Kamboju
2018-10-08 15:52       ` Eric W. Biederman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87va6cwi3q.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.