[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87lfynrh8r.fsf@xmission.com>
Date: Thu, 30 May 2019 12:20:52 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Oleg Nesterov <oleg@...hat.com>
Cc: Deepa Dinamani <deepa.kernel@...il.com>,
Al Viro <viro@...IV.linux.org.uk>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
arnd@...db.de, dbueso@...e.de, axboe@...nel.dk, dave@...olabs.net,
e@...24.org, jbaron@...mai.com, linux-fsdevel@...r.kernel.org,
linux-aio@...ck.org, omar.kilani@...il.com, tglx@...utronix.de,
stable@...r.kernel.org
Subject: Re: pselect/etc semantics
Oleg Nesterov <oleg@...hat.com> writes:
> On 05/30, Eric W. Biederman wrote:
>>
>> ebiederm@...ssion.com (Eric W. Biederman) writes:
>>
>> > Which means I believe we have a semantically valid change in behavior
>> > that is causing a regression.
>>
>> I haven't made a survey of all of the functions yet but
>> fucntions return -ENORESTARTNOHAND will never return -EINTR and are
>> immune from this problem.
>
> Hmm. handle_signal:
>
> case -ERESTARTNOHAND:
> regs->ax = -EINTR;
> break;
>
> but I am not sure I understand which problem do you mean..
Yes. My mistake. I looked at the transparent restart case for when a
signal is not pending and failed to look at what happens when a signal
is delivered.
So yes. Everything changed does appear to have a behavioral difference
where they can now succeed and not return -EINTR.
Eric
Powered by blists - more mailing lists