linux-kernel - [PATCH] doc fix - brlock was removed in the 3.13 kernel series

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>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1419506981-23952-1-git-send-email-der.herr@hofr.at>
Date:	Thu, 25 Dec 2014 06:29:41 -0500
From:	Nicholas Mc Guire <der.herr@...r.at>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	John Stultz <john.stultz@...aro.org>,
	Ingo Molnar <mingo@...nel.org>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Trond Myklebust <trond.myklebust@...marydata.com>,
	Rik van Riel <riel@...hat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	linux-kernel@...r.kernel.org, Nicholas Mc Guire <der.herr@...r.at>
Subject: [PATCH] doc fix - brlock was removed in the 3.13 kernel series

The brlock was completely removed in the 3.13 kernel series.
see commit 0f6ed63b1707 ("no need to keep brlock macros anymore...")

It seems that documentation in seqlock.h was not updated to reflect
this. This patch drops the (hopefully last) false brlock reference.
All remaining references to brlock refer to byte-range locks (notably
in cifs) and not to "Big Reader Lock" and should be correct.

patch is against 3.19.0-rc1 linux-next

Signed-off-by: Nicholas Mc Guire <der.herr@...r.at>
---
 include/linux/seqlock.h |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index f5df8f6..af7f5e9 100644
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -13,9 +13,8 @@
  *    from going forward. Unlike the regular rwlock, the read lock here is
  *    exclusive so that only one locking reader can get it.
  *
- * This is not as cache friendly as brlock. Also, this may not work well
- * for data that contains pointers, because any writer could
- * invalidate a pointer that a reader was following.
+ * This may not work well for data that contains pointers, because any
+ * writer could invalidate a pointer that a reader was following.
  *
  * Expected non-blocking reader usage:
  * 	do {
--
1.7.10.4

--
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/