[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070405141321.GH28414@in.ibm.com>
Date: Thu, 5 Apr 2007 19:43:21 +0530
From: Srivatsa Vaddagiri <vatsa@...ibm.com>
To: "Paul Menage" <menage@...gle.com>
Cc: sekharan@...ibm.com, ckrm-tech@...ts.sourceforge.net,
linux-kernel@...r.kernel.org, xemul@...ru, rohitseth@...gle.com,
pj@....com, "Eric W. Biederman" <ebiederm@...ssion.com>,
winget@...gle.com, containers@...ts.osdl.org
Subject: Re: [ckrm-tech] [PATCH 7/7] containers (V7): Container interface to nsproxy subsystem
On Thu, Apr 05, 2007 at 06:13:25PM +0530, Srivatsa Vaddagiri wrote:
> Lets go back to the f_bc example here for a moment. Lets say T1 was in C1 and
> opened file f1. f1->f_bc points to C1->beancounter.
>
> T1 moves from C1 -> C2, but f1 is not migrated.
> C1->beancounter.count stays at 1 (to account for f1->f_bc).
Actually C1->beancounter.count should be at 2 (C1->beancounter and
f1->f_bc are pointing to it).
> File f1 is closed. C1->beancounter.count becomes zero.
C1->beancounter.count should go to 1 ..
> Now user issues rmdir C1. If rmdir finds (after taking manage_mutex that
> is)
>
> - zero tasks in C1
> - zero refcount in C1->beancounter
s/zero refcount in C1->beancounter/exactly 1 refcount in C1->beancounter
> why is it not safe to assume that C1->beancounter.count will continue to
> stay zero?
s/zero/at one
> Basically I am struggling to answer "How can a zero refcount (beancounter)
> object go non-zero when zero tasks are attached to it" ..
s/zero/one and s/non-zero/>1
Essentially bc_subsys->can_attach(struct bean_counter *b) can return
-EBUSY if (atomic_read(&b->count) > 1) ..
--
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists