pagg
[Top] [All Lists]

Re: New 2.6.6 pagg and job patches available

To: Erik Jacobson <erikj@xxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: New 2.6.6 pagg and job patches available
From: Peter Williams <pwil3058@xxxxxxxxxxxxxx>
Date: Thu, 27 May 2004 13:17:47 +1000
Cc: pagg@xxxxxxxxxxx
In-reply-to: <40AD689C.7030106@xxxxxxxxxxxxxx>
References: <Pine.SGI.4.53.0405201609330.212943@xxxxxxxxxxxxxxxxxxxxxxx> <40AD689C.7030106@xxxxxxxxxxxxxx>
Sender: pagg-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
Peter Williams wrote:
Erik Jacobson wrote:

New pagg and job patches are available from the pagg web site for the
2.6.6 kernel.

oss.sgi.com/projects/pagg

Click 'download' on the left.

The patches I made available are:
linux-2.6.6-pagg.patch
and
linux-2.6.6-job.patch

Check out the README for some installation tips.

Note: we haven't finished processing all the community feedback yet.  So
there will likely be at least one more 2.6.6 pagg patch to come.
I also haven't implemented the patches from Peter Williams yet but hope to
soon.


Attached is a patch (against your latest 2.6.6 patch) to do the initialisation of tasks at registration and add real uid/gid and CPU affinity hooks.

The "initialisation of tasks" code still needs some work so that it cleans up properly when faced with memory allocation failures. Probably best left to someone more familiar with PAGG than me.

On a related note, shouldn't the deregistration code do something similar? i.e. call detach() on all of the deregistering clients paggs and remove form any task lists that they are on rather than just refusing to unload if there are any tasks with paggs belonging to the deregistering client. Otherwise every client will have to reinvent the wheel in order to do this when it is unloaded from the kernel.

I've just been perusing pagg_hook_unregister() with a view to implementing the above idea and noticed that there is a possible race condition in the code that checks for the presence of paggs from the client being deregistered in tasks. Because the tasklist_lock is released within the for loop it is possible for new tasks to be created and added in such a way that they miss being processed by this for loop.

--
Dr Peter Williams                                pwil3058@xxxxxxxxxxxxxx

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce


<Prev in Thread] Current Thread [Next in Thread>