On Tue, Oct 18, 2005 at 11:46:30AM +0200, Eric Dumazet wrote:
> Paul E. McKenney a écrit :
> >
> >
> >>+/*
> >>+ * Should we directly call rcu_do_batch() here ?
> >>+ * if (unlikely(rdp->count > 10000))
> >>+ * rcu_do_batch(rdp);
> >>+ */
> >
> >
> >Good thing that the above is commented out! ;-)
> >
> >Doing this can result in self-deadlock, for example with the following:
> >
> > spin_lock(&mylock);
> > /* do some stuff. */
> > call_rcu(&p->rcu_head, my_rcu_callback);
> > /* do some more stuff. */
> > spin_unlock(&mylock);
> >
> >void my_rcu_callback(struct rcu_head *p)
> >{
> > spin_lock(&mylock);
> > /* self-deadlock via call_rcu() via rcu_do_batch()!!! */
> > spin_unlock(&mylock);
> >}
> >
> >
> > Thanx, Paul
>
> Thanks Paul for reminding us that call_rcu() should not ever call the
> callback function, as very well documented in Documentation/RCU/UP.txt
> (Example 3: Death by Deadlock)
>
> But is the same true for call_rcu_bh() ?
Yes, same rules for this aspect of call_rcu_bh() and call_rcu().
> I intentionally wrote the comment to remind readers that a low maxbatch can
> trigger OOM in case a CPU is filled by some kind of DOS (network IRQ flood
> for example, targeting the IP dst cache)
>
> To solve this problem, may be we could add a requirement to
> call_rcu_bh/callback functions : If they have to lock a spinlock, only use
> a spin_trylock() and make them returns a status (0 : sucessfull callback,
> 1: please requeue me)
>
> As most callback functions just kfree() some memory, most of OOM would be
> cleared.
>
> int my_rcu_callback(struct rcu_head *p)
> {
> if (!spin_trylock(&mylock))
> return 1; /* please call me later */
> /* do something here */
> ...
> spin_unlock(&mylock);
> return 0;
> }
>
> (Changes to rcu_do_batch() are left as an exercice :) )
Another approach that would keep the current easier-to-use semantics
would be to schedule a tasklet or workqueue to process the callbacks
in a safe context.
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]
