"Eric W. Biederman" wrote:
> Frankly the only reason this appears to be worth touching is that we
> have a userspace regression. Otherwise I would call the current
> behavior more correct and desirable than ignoring the signal longer.
>
> If I am reading sitaution properly I suggest we go back t
On Thu, May 30, 2019 at 4:41 PM Oleg Nesterov wrote:
> On 05/30, Arnd Bergmann wrote:
> Plus every file touched by this patch asks for more cleanups. Say, do_poll()
> should return -ERESTARTNOHAND, not -EINTR, after that we can remove the ugly
> EINTR->ERESTARTNOHAND in its callers. And more.
>
>
On Thu, May 30, 2019 at 3:54 AM Eric W. Biederman wrote:
> Arnd Bergmann writes:
> > On Wed, May 29, 2019 at 6:12 PM Oleg Nesterov wrote:
> >
> > Not sure about the order of the cleanups, but probably something like
> > this would work:
> >
> > 1. fix the race (to be backported)
> > 2. unify se
Oleg Nesterov writes:
> On 05/30, Eric W. Biederman wrote:
>>
>> ebied...@xmission.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
>> fucn
On Thu, May 30, 2019 at 8:48 AM Deepa Dinamani wrote:
>
> > On May 30, 2019, at 8:38 AM, Eric W. Biederman
> > wrote:
> >
> > ebied...@xmission.com (Eric W. Biederman) writes:
> >
> >> Which means I believe we have a semantically valid change in behavior
> >> that is causing a regression.
> >
>
From: Eric W. Biederman
> Sent: 30 May 2019 16:38
> ebied...@xmission.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 -ENORE
On 05/30, David Laight wrote:
>
> 4) As an optimisation a signal that arrives after the timer
>expires, but before the mask is restored can be 'deemed'
>to have happened before the timeout expired and EINTR
>returned.
This is what pselect/ppoll already does.
Oleg.
On 05/30, Eric W. Biederman wrote:
>
> ebied...@xmission.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 wil
On 05/30, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
>
> > Al, Linus, Eric, please help.
> >
> > The previous discussion was very confusing, we simply can not understand
> > each
> > other.
> >
> > To me everything looks very simple and clear, but perhaps I missed something
> > obvious? P
> On May 30, 2019, at 8:38 AM, Eric W. Biederman wrote:
>
> ebied...@xmission.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 -
ebied...@xmission.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 pr
From: Eric W. Biederman
> Sent: 30 May 2019 14:01
> Oleg Nesterov writes:
>
> > Al, Linus, Eric, please help.
> >
> > The previous discussion was very confusing, we simply can not understand
> > each
> > other.
> >
> > To me everything looks very simple and clear, but perhaps I missed something
On 05/30, Arnd Bergmann wrote:
>
> I think this is a nice simplification, but it would help not to mix up the
> minimal regression fix with the rewrite of those functions.
Yes, yes, agreed.
Plus every file touched by this patch asks for more cleanups. Say, do_poll()
should return -ERESTARTNOHAND,
Eric Wong writes:
> Agreed... I believe cmogstored has always had a bug in the way
> it uses epoll_pwait because it failed to check interrupts if:
>
> a) an FD is ready + interrupt
> b) epoll_pwait returns 0 on interrupt
>
> The bug remains in userspace for a), which I will fix by adding
> an in
Oleg Nesterov writes:
> Al, Linus, Eric, please help.
>
> The previous discussion was very confusing, we simply can not understand each
> other.
>
> To me everything looks very simple and clear, but perhaps I missed something
> obvious? Please correct me.
If I have read this thread correctly the
From: Eric Wong
> Sent: 29 May 2019 19:50
...
> > Personally I think that is wrong.
> > Given code like the above that has:
> > while (!interrupted) {
> > pselect(..., &sigint);
> > // process available data
> > }
> >
> > You want the
Arnd Bergmann writes:
> On Wed, May 29, 2019 at 6:12 PM Oleg Nesterov wrote:
>>
>> Al, Linus, Eric, please help.
>>
>> The previous discussion was very confusing, we simply can not understand each
>> other.
>>
>> To me everything looks very simple and clear, but perhaps I missed something
>> obv
On Wed, May 29, 2019 at 6:12 PM Oleg Nesterov wrote:
>
> Al, Linus, Eric, please help.
>
> The previous discussion was very confusing, we simply can not understand each
> other.
>
> To me everything looks very simple and clear, but perhaps I missed something
> obvious? Please correct me.
Thanks f
David Laight wrote:
> From: Oleg Nesterov
> > Sent: 29 May 2019 17:12
> > Al, Linus, Eric, please help.
> >
> > The previous discussion was very confusing, we simply can not understand
> > each
> > other.
> >
> > To me everything looks very simple and clear, but perhaps I missed something
> > o
On Wed, May 29, 2019 at 9:12 AM Oleg Nesterov wrote:
>
> Al, Linus, Eric, please help.
>
> The previous discussion was very confusing, we simply can not understand each
> other.
>
> To me everything looks very simple and clear, but perhaps I missed something
> obvious? Please correct me.
>
> I thi
Resending due to inadvertent conversion of prior message to html.
On Wed, May 29, 2019 at 9:12 AM Oleg Nesterov wrote:
> Al, Linus, Eric, please help.
>
> The previous discussion was very confusing, we simply can not understand each
> other.
>
> To me everything looks very simple and clear, but p
From: Oleg Nesterov
> Sent: 29 May 2019 17:12
> Al, Linus, Eric, please help.
>
> The previous discussion was very confusing, we simply can not understand each
> other.
>
> To me everything looks very simple and clear, but perhaps I missed something
> obvious? Please correct me.
>
> I think that
On Gwe, 2005-08-05 at 12:42 +0200, Michael Kerrisk wrote:
> 1. POSIX made the behaviour of pselect() explicit -- the
>timeout must not be modified. The idea was to avoid the
>vagueness of the select() specification; it had to be vague
>because of existing implementations. By contras
> Michael Kerrisk wrote:
> > Please consider making Linux pselect() conform to POSIX on this
> > point.
>
> There is no question the implementation will conform. But this not
> dependent on changing the syscall interface. We deliberately decided to
> not require the kernel interface to be diffe
Michael Kerrisk wrote:
> Please consider making Linux pselect() conform to POSIX on this
> point.
There is no question the implementation will conform. But this not
dependent on changing the syscall interface. We deliberately decided to
not require the kernel interface to be different from sele
>For people who prefer programming above documenting,
>here is a simple small thing to do:
>
>POSIX.1g and Austin document a pselect() call intended to
>remove the race condition that is present when one wants
>to wait on either a signal or some file descriptor.
>(See also Stevens, Unix Network Pr
26 matches
Mail list logo
