[lkml]   [2011]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH 0/3] fork: Add the ability to create tasks with given pids
On 11/23/2011 10:19 PM, Pavel Emelyanov wrote:
> On 11/23/2011 08:24 PM, Tejun Heo wrote:
>> Hello,
>> On Wed, Nov 23, 2011 at 04:20:44PM +0000, Pedro Alves wrote:
>>>> Would CAP_CHECKPOINT be a shame too?
>>> I think CAP_CHECKPOINT (or something through some LSM) would be
>>> definitely better.
>>>> I'm reluctant about priviledge
>>>> through fd inheritance mostly because of its unusualness. I don't
>>>> think priv management is a good problem space for small creative
>>>> solutions. We're much better off with mundane mechanisms which people
>>>> are already familiar with and is easy to account for.
>>> fd inheritance wouldn't work for gdb; a user spawned gdb
>>> wouldn't inherit an open fd to kernel.ns_last_pid from anywhere.
>> I see. So, let's do it for root for now and later add finer grained
>> CAP as necessary/viable. Pavel, what do you think?
> OK, I'll send the respective patches soon.

Hm... Started testing this stuff and thought about Pedro's wish to use this
in gdb one more time :(

The thing is, that we (in checkpoint/restore) are going to use this sysctl
when creating a pid namespace from scratch, thus having full control over
all the forks happening in this namespace.

But when it comes to the ability for gdb to create a task with a given pid in
a _living_ namespace this solution simply won't work! It doesn't guarantee,
that after setting the last_pid via sysctl this last_pid stays the same at
the time we do call fork()/clone(). Because there are other tasks that can call
fork themselves ignoring any lask_pid locking we can play with.

That said I see only two real-life scenarios of how to use _this_ API:

1. creating tasks in a new pid namespace, making sure all the fork-ers care
about the proper locking;
2. forking tasks in a loop checking that getpid() returns desired value and
hoping that other tasks do not fork() at speed high enough for spoiling
every single last_pid value set via sysctl.

Is any of these scenarios suitable for Pedro? Other thoughts on this?

>> Thanks.

 \ /
  Last update: 2011-11-23 21:17    [W:0.086 / U:79.848 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site