linux-kernel - Re: [PATCH 06/17] fs: icache lock lru/writeback lists

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

Date:	Sat, 16 Oct 2010 18:55:27 +1100
From:	Nick Piggin <npiggin@...nel.dk>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Dave Chinner <david@...morbit.com>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 06/17] fs: icache lock lru/writeback lists

On Wed, Sep 29, 2010 at 09:52:40PM -0700, Andrew Morton wrote:
> On Wed, 29 Sep 2010 22:18:38 +1000 Dave Chinner <david@...morbit.com> wrote:
> 
> > The inode moves between different lists protected by the inode_lock. Introduce
> > a new lock that protects all of the lists (dirty, unused, in use, etc) that the
> > inode will move around as it changes state. As this is mostly a list for
> > protecting the writeback lists, name it wb_inode_list_lock and nest all the
> > list manipulations in this lock inside the current inode_lock scope.
> 
> All those spin_trylock()s are real ugly.  They're unexplained in the
> changelog and unexplained in code comments.
> 
> I'd suggest that each such site have a comment explaining why we're
> resorting to this.

They're really a side effect of how I'm building up the locking in steps
and then streamlining it in steps. Most of them disappear or get much
improved as inode removal, rcu, etc greatly help with lock ordering.

The intermediate steps are not supposed to be so pretty, so much as an
easily verifiable "ok, we have enough locking to cover what inode_lock
used to be protecting".

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