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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <20110228152153.25e94457.sfr@canb.auug.org.au>
Date:	Mon, 28 Feb 2011 15:21:53 +1100
From:	Stephen Rothwell <sfr@...b.auug.org.au>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Davide Libenzi <davidel@...ilserver.org>,
	Daniel Baluta <daniel.baluta@...il.com>
Subject: linux-next: manual merge of the trivial tree with Linus' tree

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@...b.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/