linux-kernel - Re: [PATCH 5/9] writeback: introduce the pageout work

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]

Message-ID: <20120307054049.GA12256@localhost>
Date:	Tue, 6 Mar 2012 21:40:49 -0800
From:	Fengguang Wu <fengguang.wu@...el.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Jan Kara <jack@...e.cz>, Greg Thelen <gthelen@...gle.com>,
	Ying Han <yinghan@...gle.com>,
	"hannes@...xchg.org" <hannes@...xchg.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Rik van Riel <riel@...hat.com>, Mel Gorman <mgorman@...e.de>,
	Minchan Kim <minchan.kim@...il.com>,
	Linux Memory Management List <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 5/9] writeback: introduce the pageout work

On Tue, Mar 06, 2012 at 04:37:42PM -0800, Andrew Morton wrote:
> On Sat, 3 Mar 2012 21:25:55 +0800
> Fengguang Wu <fengguang.wu@...el.com> wrote:
> 
> > > > get_page() looks the perfect solution to verify if the struct inode
> > > > pointer (w/o igrab) is still live and valid.
> > > > 
> > > > [...upon rethinking...] Oh but still we need to lock some page to pin
> > > > the inode during the writeout. Then there is the dilemma: if the page
> > > > is locked, we effectively keep it from being written out...
> > > 
> > > No, all you need to do is to structure the code so that after the page
> > > gets unlocked, the kernel thread does not touch the address_space.  So
> > > the processing within the kthread is along the lines of
> > > 
> > > writearound(locked_page)
> > > {
> > > 	write some pages preceding locked_page;	/* touches address_space */
> > 
> > It seems the above line will lead to ABBA deadlock.
> > 
> > At least btrfs will lock a number of pages in lock_delalloc_pages().
> 
> Well, this code locks multiple pages too.  I forget what I did about
> that - probably trylock.  Dirty pages aren't locked for very long.

Yeah, trylock will be OK. And if the filesystems all do trylocks when
writing out any extra pages they try to piggy back, the ABBA deadlock
can be avoided. That makes the get_page()+trylock_page() scheme feasible.

Thanks,
Fengguang
--
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/