Messages in this thread | | | Date | Tue, 18 Oct 2005 11:46:30 +0200 | From | Eric Dumazet <> | Subject | Re: VFS: file-max limit 50044 reached |
| |
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() ?
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 :) )
Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |