linux-next: manual merge of the trivial tree with Linus' tree

From: Stephen Rothwell
Date: Sun Feb 27 2011 - 23:22:15 EST


Hi Jiri,

Today's linux-next merge of the trivial tree got a conflict in
fs/eventpoll.c between commit 22bacca48a1755f79b7e0f192ddb9fbb7fc6e64e
("epoll: prevent creating circular epoll structures") from Linus' tree
and commit bf6a41db7726e6c09b9c6ac993457b7260473406 ("fs/eventpoll.c: fix
spelling") from the trivial tree.

Just context. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@xxxxxxxxxxxxxxxx

diff --cc fs/eventpoll.c
index 4a09af9,7513066..0000000
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@@ -62,14 -62,7 +62,14 @@@
* This mutex is acquired by ep_free() during the epoll file
* cleanup path and it is also acquired by eventpoll_release_file()
* if a file has been pushed inside an epoll set and it is then
- * close()d without a previous call toepoll_ctl(EPOLL_CTL_DEL).
+ * close()d without a previous call to epoll_ctl(EPOLL_CTL_DEL).
+ * It is also acquired when inserting an epoll fd onto another epoll
+ * fd. We do this so that we walk the epoll tree and ensure that this
+ * insertion does not create a cycle of epoll file descriptors, which
+ * could lead to deadlock. We need a global mutex to prevent two
+ * simultaneous inserts (A into B and B into A) from racing and
+ * constructing a cycle without either insert observing that it is
+ * going to.
* It is possible to drop the "ep->mtx" and to use the global
* mutex "epmutex" (together with "ep->lock") to have it working,
* but having "ep->mtx" will make the interface more scalable.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/