From: Chandra S. <sek...@us...> - 2006-05-05 00:12:55
|
On Thu, 2006-05-04 at 16:20 -0700, Paul E. McKenney wrote: > On Thu, May 04, 2006 at 02:34:23PM -0700, Chandra Seetharaman wrote: > > On Thu, 2006-05-04 at 14:23 -0400, Alan Stern wrote: > > > Alan Stern wrote: > > > > > > > I assumed that a notifier called during fork might need to block. If > > > > that's so then you have no choice but to use a blocking notifier. > > > > > > I forgot to mention -- if you can guarantee that these per-task notifier > > > chains will never be used outside the task's context, then a raw_notifier > > > will work. No need for locking when by definition only a single CPU can > > > be using the resource at any time. Nor is unregistering from within a > > > callout a problem. > > > > unregistering from the callout might still be a problem, since we cannot > > be sure that the next pointer in the freed notifier_block will be sane. > > If you reference-count the entire chain, then any subsequently removed > notifier_block it guaranteed to remain sane. Splitting the reference > count across multiple CPUs keeps the cost of reference counting quite > low. Paul, I am not able to get my head around to understand the reference count logic. call_chain is defined as: static int __kprobes notifier_call_chain(struct notifier_block **nl, unsigned long val, void *v) { 1: int ret = NOTIFY_DONE; 2: struct notifier_block *nb; 3: 4: nb = rcu_dereference(*nl); 5: while (nb) { 6: ret = nb->notifier_call(nb, val, v); 7: if ((ret & NOTIFY_STOP_MASK) == NOTIFY_STOP_MASK) 8: break; 9: nb = rcu_dereference(nb->next); a: } b: return ret; } Assume that the user of the notifier chain kmalloc'd a notifier_block and registered initially. When the user's notifier_call is called from line 6 above, the user kfrees the notifier_block, how having a reference count for the whole chain would help in making sure that nb->next is sane in line 9 ? Or, Are you describing a different mechanism without using this notifier chain mechanism. Thanks in advance for clarifying this. chandra > > Thanx, Paul > > > > Of course, this assumes you can make that guarantee. The implication is > > > that a driver can't register or unregister for one of these chains unless > > > the driver is running in the task's context. That makes rmmod awkward, as > > > Chandra pointed out. > > > > > > Alan Stern > > > > > -- > > > > ---------------------------------------------------------------------- > > Chandra Seetharaman | Be careful what you choose.... > > - sek...@us... | .......you may get it. > > ---------------------------------------------------------------------- > > > > > > > > > > ------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > Lse-tech mailing list > > Lse...@li... > > https://lists.sourceforge.net/lists/listinfo/lse-tech > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Lse-tech mailing list > Lse...@li... > https://lists.sourceforge.net/lists/listinfo/lse-tech -- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - sek...@us... | .......you may get it. ---------------------------------------------------------------------- |