"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
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
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
>>
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.
> >
> > AKA pselect is fine. While epoll_pwait ca
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
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
results in a return value of 0,
0 or success
> and a signal
> delivered, where previously that did not happen.
Yes.
And to me this doesn't look right. OK, OK, probably this is because I never
read the docs, only the source code in fs/select.c. But to me pselect() should
either return succes
ons yet but
> fucntions return -ENORESTARTNOHAND will never return -EINTR and are
> immune from this problem.
>
> AKA pselect is fine. While epoll_pwait can be affected.
This was my understanding as well.
> Has anyone contacted Omar Kilani to see if that is his issue?
> ht
e from this problem.
AKA pselect is fine. While epoll_pwait can be affected.
Has anyone contacted Omar Kilani to see if that is his issue?
https://lore.kernel.org/lkml/CA+8F9hicnF=kvjXPZFQy=pa2hjus3js+g9vswfhnqqynpmh...@mail.gmail.com/
So far the only regression report I am seeing is from Eric Won
ask changing system call
> can be defined. The naive way and by reading posix. I will pick
> on pselect.
>
> The naive way:
> int pselect(int nfds, fd_set *readfds, fd_set *writefds,
> fd_set *exceptfds, const struct timespec *timeout,
>
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
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
this thread correctly the core issue is that ther is a
program that used to work and that fails now. The question is why.
There are two ways the semantics for a sigmask changing system call
can be defined. The naive way and by reading posix. I will pick
on pselect.
The naive way:
int pselect(int
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(..., );
> > // process available data
> >
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
>>
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
interrupted = 1;
> > }
> >
> > int main(void)
> > {
> > sigset_t sigint, empty;
> >
> > sigemptyset();
> > sigaddset(, SIGINT);
> > sigprocmask(SIG_BLOCK, , NULL);
sigset_t sigint, empty;
>
> sigemptyset();
> sigaddset(, SIGINT);
> sigprocmask(SIG_BLOCK, , NULL);
>
> signal(SIGINT, sigint_handler);
>
> sigemptyset();// so pselect() unblocks SIGINT
>
>
ed = 1;
> }
>
> int main(void)
> {
> sigset_t sigint, empty;
>
> sigemptyset();
> sigaddset(, SIGINT);
> sigprocmask(SIG_BLOCK, , NULL);
>
> signal(SIGINT, sigint_handler);
>
>
ty;
>
> sigemptyset();
> sigaddset(, SIGINT);
> sigprocmask(SIG_BLOCK, , NULL);
>
> signal(SIGINT, sigint_handler);
>
> sigemptyset();// so pselect() unblocks SIGINT
>
> ret =
);
signal(SIGINT, sigint_handler);
sigemptyset();// so pselect() unblocks SIGINT
ret = pselect(..., );
if (ret >= 0) // sucess or timeout
assert(!interrupted);
if (interrup
On 9/20/18, Deepa Dinamani wrote:
> The series transitions the ppoll, io_getevents, and pselect syscalls
> to be y2038 safe.
>
> This is part of the work proceeding for syscalls for y2038.
> It is based on the series [1] from Arnd Bergmann.
>
> The overview of the se
This changes the select and pselect system calls to use the
new schedule_timeout_hr function. Since many applications
use the select function instead of nanosleep, this provides
a higher resolution sleep to them.
BUG: the same needs to be done for the compat syscalls, the
current patch breaks
This changes the select and pselect system calls to use the
new schedule_timeout_hr function. Since many applications
use the select function instead of nanosleep, this provides
a higher resolution sleep to them.
BUG: the same needs to be done for the compat syscalls, the
current patch breaks
David,
> On Fri, 2005-08-05 at 14:49 +0200, Michael Kerrisk wrote:
> > If I change your program to do something like the above, I also
> > do not see a message from the handler -- i.e., it is not being
> > called, and I'm pretty sure it should be.
>
> Hm, yes. What happens is we come back out of
David,
On Fri, 2005-08-05 at 14:49 +0200, Michael Kerrisk wrote:
If I change your program to do something like the above, I also
do not see a message from the handler -- i.e., it is not being
called, and I'm pretty sure it should be.
Hm, yes. What happens is we come back out of the
is necessary that the handler is called. This is the purpose of
these interfaces. If this means more complexity is needed then this is
how the cookie crumbles. One use case for pselect would be something
like this:
int got_signal;
void sigint_handler(int sig) {
got_signal = 1;
}
{
..
that the handler is called. This is the purpose of
these interfaces. If this means more complexity is needed then this is
how the cookie crumbles. One use case for pselect would be something
like this:
int got_signal;
void sigint_handler(int sig) {
got_signal = 1;
}
{
...
while (1
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 imp
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 contrast
> 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 r
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 differen
> From: David Woodhouse <[EMAIL PROTECTED]>
> Subject: Re: Add pselect, ppoll system calls.
> Date: Wed, 15 Jun 2005 12:36:54 +0100
>
> On Mon, 2005-06-13 at 08:38 -0700, Ulrich Drepper wrote:
> > > Eep -- I hadn't noticed that difference. Will update patch
> &g
Hello David,
By the way, looking at the comments to the last version of
the pselect()/ppoll()patch, I see that the treatment of
the timeout argument is made dependent on the personality.
http://marc.theaimsgroup.com/?l=linux-kernel=111883591220436=2
I'm not sure that this is a good idea; my
Hello David,
By the way, looking at the comments to the last version of
the pselect()/ppoll()patch, I see that the treatment of
the timeout argument is made dependent on the personality.
http://marc.theaimsgroup.com/?l=linux-kernelm=111883591220436w=2
I'm not sure that this is a good idea
From: David Woodhouse [EMAIL PROTECTED]
Subject: Re: Add pselect, ppoll system calls.
Date: Wed, 15 Jun 2005 12:36:54 +0100
On Mon, 2005-06-13 at 08:38 -0700, Ulrich Drepper wrote:
Eep -- I hadn't noticed that difference. Will update patch
accordingly.
And change [the poll timeout
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
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
>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
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
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
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
44 matches
Mail list logo
