pagg
[Top] [All Lists]

Re: [patch] Minor PAGG attach/detach semantic change for 2.6.11

To: Kaigai Kohei <kaigai@xxxxxxxxxxxxx>
Subject: Re: [patch] Minor PAGG attach/detach semantic change for 2.6.11
From: Erik Jacobson <erikj@xxxxxxx>
Date: Fri, 30 Sep 2005 09:05:33 -0500
Cc: Erik Jacobson <erikj@xxxxxxx>, Kingsley Cheung <kingsley@xxxxxxxxxx>, pagg@xxxxxxxxxxx, tonyt@xxxxxxxxxx, paulmck@xxxxxxxxxx
In-reply-to: <433C9D38.8060801@xxxxxxxxxxxxx>
References: <20050617014512.GA10285@xxxxxxxxxx> <20050927201020.GA30433@xxxxxxx> <433A7FE4.5040109@xxxxxxxxxxxxx> <20050928141831.GA24110@xxxxxxx> <433B80B6.2010604@xxxxxxxxxxxxx> <20050929144738.GA7395@xxxxxxx> <433C9D38.8060801@xxxxxxxxxxxxx>
Sender: pagg-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6i
> I think implementing a new pnotify's client becomes easier,
> if pnotify_subscriber_list would be protected by rwlock.

The issue I have here is an rwlock is really a spinlock...  So that
would forbid kernel modules from sleeping.  This includes, for exmaple, 
waiting for memory to become free with kmalloc.  The modules wouldn't be
able to use semaphores on their own either.

We could investigate trying to convert the job code, for example, to never
sleep with the lock held but I'm not sure how easy that would be.

On the other hand, I understand the community is anxious about modules
being able to sleep in the fork or exit path.

I don't think we can do everything we want to do if the subscriber list
is locked with rwlock.  But I'm open to being convinced otherwise :)

Erik

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