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: <1331135301.32316.29.camel@sauron.fi.intel.com>
Date:	Wed, 07 Mar 2012 17:48:21 +0200
From:	Artem Bityutskiy <dedekind1@...il.com>
To:	Fengguang Wu <fengguang.wu@...el.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, 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>,
	Adrian Hunter <ext-adrian.hunter@...ia.com>,
	Artem Bityutskiy <Artem.Bityutskiy@...ia.com>
Subject: Re: [PATCH 5/9] writeback: introduce the pageout work

On Sat, 2012-03-03 at 21:55 +0800, Fengguang Wu wrote:
>   13   1125  /c/linux/fs/ubifs/file.c <<do_truncation>>   <===== deadlockable

Sorry, but could you please explain once again how the deadlock may
happen?

> It seems they are all safe except for ubifs. ubifs may actually
> deadlock from the above do_truncation() caller. However it should be
> fixable because the ubifs call for writeback_inodes_sb_nr() sounds
> very brute force writeback and wait and there may well be better way
> out.

I do not think this "fixable" - this is part of UBIFS design to force
write-back when we are not sure we have enough space.

The problem is that we do not know how much space the dirty data in RAM
will take on the flash media (after it is actually written-back) - e.g.,
because we compress all the data (UBIFS performs on-the-flight
compression). So we do pessimistic assumptions and allow dirtying more
and more data as long as we know for sure that there is enough flash
space on the media for the worst-case scenario (data are not
compressible). This is what the UBIFS budgeting subsystem does.

Once the budgeting sub-system sees that we are not going to have enough
flash space for the worst-case scenario, it starts forcing write-back to
push some dirty data out to the flash media and update the budgeting
numbers, and get more realistic picture.

So basically, before you can change _anything_ on UBIFS file-system, you
need to budget for the space. Even when you truncate - because
truncation is also about allocating more space for writing the updated
inode and update the FS index. (Remember, all writes are out-of-place in
UBIFS because we work with raw flash, not a block device).

-- 
Best Regards,
Artem Bityutskiy

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