On Thu, Jan 12, 2006 at 07:17:41AM -0800, Paul E. McKenney wrote:
> On Thu, Jan 12, 2006 at 06:50:34PM +1100, Keith Owens wrote:
> > "Paul E. McKenney" (on Wed, 11 Jan 2006 22:51:15 -0800) wrote:
> > >On Thu, Jan 12, 2006 at 05:19:01PM +1100, Keith Owens wrote:
> > >> OK, I have thought about it and ...
> > >>
> > >> notifier_call_chain_lockfree() must be called with preempt disabled.
> > >>
> > >Fair enough! A comment, perhaps? In a former life I would have also
> > >demanded debug code to verify that preemption/interrupts/whatever were
> > >actually disabled, given the very subtle nature of any resulting bugs...
> >
> > Comment - OK. Debug code is not required, the reference to
> > smp_processor_id() already does all the debug checks that
> > notifier_call_chain_lockfree() needs. CONFIG_PREEMPT_DEBUG is your
> > friend.
>
> Ah, debug_smp_processor_id(). Very cool!!!
One other thing -- given that you are requiring that the read side
have preemption disabled, another update-side option would be to
use synchronize_sched() to wait for all preemption-disabled code
segments to complete. This would allow you to remove the per-CPU
reference counters from the read side, but would require that the
update side either (1) be able to block or (2) be able to defer
the cleanup to process context.
Just another option...
Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
