On Wed, Jun 12, 2013 at 09:00:19PM -0700, Kent Overstreet wrote:
> On Wed, Jun 12, 2013 at 08:58:31PM -0700, Tejun Heo wrote:
> > At first I named it percpu_ref_free() but it looked too symmetric to
> > init, more so than kill, so I was worried that people might get
> > confused that this is the no
On Wed, Jun 12, 2013 at 08:58:31PM -0700, Tejun Heo wrote:
> At first I named it percpu_ref_free() but it looked too symmetric to
> init, more so than kill, so I was worried that people might get
> confused that this is the normal interface to shutdown a percpu
> refcnt, so the weird cancel_init na
On Wed, Jun 12, 2013 at 08:56:36PM -0700, Kent Overstreet wrote:
> On Wed, Jun 12, 2013 at 08:52:35PM -0700, Tejun Heo wrote:
> > Normally, percpu_ref_init() initializes and percpu_ref_kill*()
> > initiates destruction which completes asynchronously. The
> > asynchronous destruction can be problem
On Wed, Jun 12, 2013 at 08:52:35PM -0700, Tejun Heo wrote:
> Normally, percpu_ref_init() initializes and percpu_ref_kill*()
> initiates destruction which completes asynchronously. The
> asynchronous destruction can be problematic in init failure path where
> the caller wants to destroy half-constr
Normally, percpu_ref_init() initializes and percpu_ref_kill*()
initiates destruction which completes asynchronously. The
asynchronous destruction can be problematic in init failure path where
the caller wants to destroy half-constructed object - distinguishing
half-constructed objects from the usu
5 matches
Mail list logo
