Re: sysctl_doeproc() race

On 13.03.2018 13:26, Robert Elz wrote: > Sure - I was not suggesting that anything shouild be done to this code to > make it run faster - I had seen that "could just use ..." comment ages ago, > and (as I assume its original author did, even more ages previously) that > it just wasn't worth the

Re: sysctl_doeproc() race

Date:Tue, 13 Mar 2018 12:04:42 +0100 From:Kamil Rytarowski Message-ID: <5be4edf8-4722-e586-ea3e-0021862a4...@gmx.com> | I was testing it on a headless desktop. Benchmarking with -j4 or -j8 in | the background couldn't be reliable so the system was

Re: sysctl_doeproc() race

On 13.03.2018 09:17, Robert Elz wrote: > Not a surprise there either - where it might make a difference is when > the number of processes is more in the thousands. I'm not sure how > 20-30 processes counts as a "regular running system" though, my > laptop has > 130 processes at the minute, and

Re: sysctl_doeproc() race

Date:Tue, 13 Mar 2018 03:27:50 +0100 From:Kamil Rytarowski Message-ID: <24955bcc-ce92-150f-75cc-60bc62287...@gmx.com> | The approach with iterating over pid_table[] didn't work well for me and | I've abandoned it quickly. I am not surprised at

Re: sysctl_doeproc() race

On 11.03.2018 19:20, Kamil Rytarowski wrote: > On 11.03.2018 18:23, Robert Elz wrote: >> Date:Sun, 11 Mar 2018 16:02:57 +0100 >> From:Kamil Rytarowski >> Message-ID: <10b0efe2-35bb-d1e8-ed28-587f643bd...@gmx.com> >> >> | We already use markers so I

Re: sysctl_doeproc() race

On 11.03.2018 18:23, Robert Elz wrote: > Date:Sun, 11 Mar 2018 16:02:57 +0100 > From:Kamil Rytarowski > Message-ID: <10b0efe2-35bb-d1e8-ed28-587f643bd...@gmx.com> > > | We already use markers so I prefer to stick to this solution and it > | makes

Re: sysctl_doeproc() race

On 11.03.2018 17:25, Robert Elz wrote: > Date:Sun, 11 Mar 2018 16:02:57 +0100 > From:Kamil Rytarowski > Message-ID: <10b0efe2-35bb-d1e8-ed28-587f643bd...@gmx.com> > > | POSIX people told me that polling of a process entity is reliable only > | for

Re: sysctl_doeproc() race

Date:Sun, 11 Mar 2018 16:02:57 +0100 From:Kamil Rytarowski Message-ID: <10b0efe2-35bb-d1e8-ed28-587f643bd...@gmx.com> | We already use markers so I prefer to stick to this solution and it | makes this code reliable. Actually, since I sent the

Re: sysctl_doeproc() race

Date:Sun, 11 Mar 2018 16:02:57 +0100 From:Kamil Rytarowski Message-ID: <10b0efe2-35bb-d1e8-ed28-587f643bd...@gmx.com> | POSIX people told me that polling of a process entity is reliable only | for parent (whether a real one or a tracer in non-POSIX

Re: sysctl_doeproc() race

On 11.03.2018 13:00, Robert Elz wrote: > Date:Sun, 11 Mar 2018 11:06:33 +0100 > From:Martin Husemann > Message-ID: <20180311100633.ge23...@mail.duskware.de> > > | I don't get this part - how would we end up with the new process using > | the

Re: sysctl_doeproc() race

On 11.03.2018 13:12, Martin Husemann wrote: > On Sun, Mar 11, 2018 at 07:00:46PM +0700, Robert Elz wrote: >> That process can exit, its zombie be cleaned up, and then a new process >> created which happens to have the same pid as the previous one had > > Theoretically, but for all practical cases

Re: sysctl_doeproc() race

On Sun, Mar 11, 2018 at 07:00:46PM +0700, Robert Elz wrote: > That process can exit, its zombie be cleaned up, and then a new process > created which happens to have the same pid as the previous one had Theoretically, but for all practical cases (and give the way we assign pids) this sounds

Re: sysctl_doeproc() race

Date:Sun, 11 Mar 2018 11:06:33 +0100 From:Martin Husemann Message-ID: <20180311100633.ge23...@mail.duskware.de> | I don't get this part - how would we end up with the new process using | the same pid? >From what I can see from glancing at the

Re: sysctl_doeproc() race

On Sun, Mar 11, 2018 at 12:57:10AM +0100, Kamil Rytarowski wrote: > We keep relocking proc_lock, and a zombie might be consumed by its > parent and later its body reused for a new process. We will end up with > a return result with two processes with the same pid. I don't get this part - how

Re: sysctl_doeproc() race

On 10.03.2018 23:49, Robert Elz wrote: > Date:Sat, 10 Mar 2018 21:47:31 +0100 > From:Kamil Rytarowski > Message-ID: <6cbea372-5520-8d76-72ac-68409f5a3...@gmx.com> > > | This does not fix the race, > > Some races aren't worth fixing.What is the

Re: sysctl_doeproc() race

Date:Sat, 10 Mar 2018 21:47:31 +0100 From:Kamil Rytarowski Message-ID: <6cbea372-5520-8d76-72ac-68409f5a3...@gmx.com> | This does not fix the race, Some races aren't worth fixing.What is the real issue here? | We will end up with the same

Re: sysctl_doeproc() race

On 10.03.2018 21:47, Kamil Rytarowski wrote: > On 10.03.2018 20:45, Christos Zoulas wrote: >> In article , >> Kamil Rytarowski wrote: >>> I've been observing a race with the ptrace(2) ATF tests. >>> >>> There is a function

Re: sysctl_doeproc() race

On 10.03.2018 20:45, Christos Zoulas wrote: > In article , > Kamil Rytarowski wrote: >> I've been observing a race with the ptrace(2) ATF tests. >> >> There is a function await_zombie() that checks whether a process (traced

Re: sysctl_doeproc() race

In article , Kamil Rytarowski wrote: >I've been observing a race with the ptrace(2) ATF tests. > >There is a function await_zombie() that checks whether a process (traced >by a debugger) died and is now a zombie. The current

sysctl_doeproc() race

I've been observing a race with the ptrace(2) ATF tests. There is a function await_zombie() that checks whether a process (traced by a debugger) died and is now a zombie. The current code might return a single process twice, from the allproc list and later from zombproc. I detect that in both