linux-kernel - Re: kernel BUG at fs/dcache.c:648! with v3.11-7890-ge5c832d

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

Message-ID: <CA+55aFw=Yegyn9TSESWmvw8GqcaorOMuGCUnCmdP=k2yeXzMPA@mail.gmail.com>
Date:	Tue, 10 Sep 2013 21:12:39 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Waiman Long <waiman.long@...com>,
	Mace Moneta <moneta.mace@...il.com>,
	Josh Boyer <jwboyer@...il.com>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: Re: kernel BUG at fs/dcache.c:648! with v3.11-7890-ge5c832d

On Tue, Sep 10, 2013 at 8:56 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> I do.  What we need on the second pass (one where we currently
> take seq_writelock()) is exclusion against writers; nothing we are
> doing is worth disturbing the readers - we don't change any data
> structures.  And simple grabbing the spinlock, without touching the
> sequence number would achieve exactly that.  Writers will have to
> wait and won't be able to disturb us, readers won't notice anything
> happening.  So yes, this extra primitive does make sense here.

Ahh. Yes, as a fallback from the reader-side sequence lock that makes
perfect sense..

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