[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111228173502.GB19321@moon>
Date: Wed, 28 Dec 2011 21:35:02 +0400
From: Cyrill Gorcunov <gorcunov@...il.com>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: linux-kernel@...r.kernel.org,
Pavel Emelyanov <xemul@...allels.com>,
Glauber Costa <glommer@...allels.com>,
Andi Kleen <andi@...stfloor.org>, Tejun Heo <tj@...nel.org>,
Matt Helsley <matthltc@...ibm.com>,
Pekka Enberg <penberg@...nel.org>,
Eric Dumazet <eric.dumazet@...il.com>,
Vasiliy Kulikov <segoon@...nwall.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [patch 1/4] Add routine for generating an ID for kernel pointer
On Wed, Dec 28, 2011 at 05:21:51PM +0000, Alan Cox wrote:
> > It can happen in case of object re-allocated from slab. But in case
> > of two living pids it's impossible to get same pointers for different
> > objects. Or I misunderstood the question, Alan? It's up to application
> > to not compare objects from dead tasks.
>
> How will it know the task has not died and been reallocated, or its
> resources not been freed and reallocated during the comparison ?
>
> Your comparison appears to have a zero time validity - you can ask "is A
> the same as B" but by the time you get an answer your answer may no
> longer be true. It also externalises a current implementation
> detail in a very ugly way.
>
It's not differ from reading other data from /proc. How make you be sure
the PPid read from a task status is the same once you've finished reading
it? The same applies to say ps output, it's valid for almost zero time,
then one need to restart ps again to get new process tree snapshot. The
same here -- if I need a precise results I have to either stop tasks or
froze them and compare IDs. That's what I've had in mind.
> Would it also not be better to do the job right and simply have an
> interface to ask "who shares with A" or even something a bit more high
> level, it seems you are creating something nastier by trying to push all
> this in userspace than if you did the job or part of it kernel side where
> you had access to the right locking infrastructure and where the public
> API doesn't need to expose innards of the kernel ?
>
Need to think, thanks a lot for idea, Alan!
Cyrill
--
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