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

[Stephen Rothwell <sfr@canb.auug.org.au>]

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@canb.auug.org.au

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.