On Mon, Dec 1, 2014 at 8:39 AM, Konstantin Khlebnikov wrote:
> On Mon, Dec 1, 2014 at 7:21 PM, Andy Lutomirski wrote:
>> On Sun, Nov 30, 2014 at 11:03 PM, Konstantin Khlebnikov
>> wrote:
>>> Hmm. What about per-task/thread UUID? exported via separate file:
>>> /proc/PID/uuid
>>> It could be cre
On Sun, Nov 30, 2014 at 11:03 PM, Konstantin Khlebnikov
wrote:
> Hmm. What about per-task/thread UUID? exported via separate file:
> /proc/PID/uuid
> It could be created at the first access, thus this wouldn't shlowdown clone().
> Also it could be droped at execve(), so it'll describe execution
>
On Nov 30, 2014 1:47 AM, "Florian Weimer" wrote:
>
> * Andy Lutomirski:
>
> > The initial implementation is straightforward: highpid is simply a
> > 64-bit counter. If a high-end system can fork every 3 ns (which
> > would be amazing, given that just allocating a pid requires at
> > atomic operati
On Nov 30, 2014 9:45 AM, "David Herrmann" wrote:
>
> Hi Andy
>
> On Sat, Nov 29, 2014 at 12:05 AM, Andy Lutomirski wrote:
> > Pid reuse is common, which means that it's difficult or impossible
> > to read information about a pid from /proc without races.
> >
> > This introduces a second number as
Hi Andy
On Sat, Nov 29, 2014 at 12:05 AM, Andy Lutomirski wrote:
> Pid reuse is common, which means that it's difficult or impossible
> to read information about a pid from /proc without races.
>
> This introduces a second number associated with each (task, pidns)
> pair called highpid. Highpid
On Fri, Nov 28, 2014 at 7:34 PM, Eric W. Biederman
wrote:
> Andy Lutomirski writes:
>
>> Pid reuse is common, which means that it's difficult or impossible
>> to read information about a pid from /proc without races.
>
> Sigh.
>
> What we need are not race free pids, but a file descriptor based p
On Nov 28, 2014 9:24 PM, "Greg KH" wrote:
>
> On Fri, Nov 28, 2014 at 03:05:01PM -0800, Andy Lutomirski wrote:
> > Pid reuse is common, which means that it's difficult or impossible
> > to read information about a pid from /proc without races.
> >
> > This introduces a second number associated wit
Andy Lutomirski writes:
> Pid reuse is common, which means that it's difficult or impossible
> to read information about a pid from /proc without races.
Sigh.
What we need are not race free pids, but a file descriptor based process
management api. Possibly one that starts by handing you a proc
On Fri, Nov 28, 2014 at 03:05:01PM -0800, Andy Lutomirski wrote:
> Pid reuse is common, which means that it's difficult or impossible
> to read information about a pid from /proc without races.
>
> This introduces a second number associated with each (task, pidns)
> pair called highpid. Highpid i
[Adding CRIU people. Whoops.]
On Fri, Nov 28, 2014 at 3:05 PM, Andy Lutomirski wrote:
> Pid reuse is common, which means that it's difficult or impossible
> to read information about a pid from /proc without races.
>
> This introduces a second number associated with each (task, pidns)
> pair cal
Pid reuse is common, which means that it's difficult or impossible
to read information about a pid from /proc without races.
This introduces a second number associated with each (task, pidns)
pair called highpid. Highpid is a 64-bit number, and, barring
extremely unlikely circumstances or outrigh
11 matches
Mail list logo
