linux-kernel - Re: [dm-devel] [PATCH] deadlock with suspend and quotas

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:	Thu, 1 Dec 2011 01:03:13 +0100
From:	Jan Kara <jack@...e.cz>
To:	Mikulas Patocka <mpatocka@...hat.com>
Cc:	Alasdair G Kergon <agk@...hat.com>, Jan Kara <jack@...e.cz>,
	esandeen@...hat.com, linux-kernel@...r.kernel.org,
	dm-devel@...hat.com, linux-fsdevel@...r.kernel.org,
	Christopher Chaltain <christopher.chaltain@...onical.com>,
	Valerie Aurora <val@...consulting.com>
Subject: Re: [dm-devel] [PATCH] deadlock with suspend and quotas

On Wed 30-11-11 11:53:40, Mikulas Patocka wrote:
> 
> 
> On Wed, 30 Nov 2011, Alasdair G Kergon wrote:
> 
> > On Tue, Nov 29, 2011 at 11:19:01AM +0100, Jan Kara wrote:
> > > So I believe the consensus was that we should not block sync or flusher
> 
> Well, I think that not blocking sync actually doesn't help at all.
> 
> Suppose at first that you have a perfectly-barriered filesystem --- that 
> is filesystem, that contains barriers around all code paths that could 
> possibly create dirty data. In this case it is impossible to have dirty 
> data while the filesystem is suspended. --- In this case you can call 
> sync on suspened filesystem as much as you like, sync never finds ady 
> dirty data, consequently it never tries to write anything and it can't 
> deadlock. So skipping sync has no effect.
> 
> Suppose as a second case that you have imperfectly-barriered filesystem 
> --- that means there exists a code path that creates dirty data while the 
> filesystem is suspended. In this case if you skip sync, you are violating 
> sync semantics, because the application can create dirty data while 
> suspended, call sync while still suspended and assume that the dirty data 
> was written.
  Except that currently we are in situation c) with e.g. ext4 and xfs. We
have perfectly-barriered filesystem *but* there are dirty bits set in this
filesystem although we are certain there are no dirty data. This
inconsistency between dirty bits and fact whether a page contains dirty
data is due to way how page faults are handled. I've already tried to
explain this in this thread in https://lkml.org/lkml/2011/11/29/109 but
apparently I failed. I can try to explain it once more but in fact I don't
think this technical detail makes a difference in this discussion. So in our
situation c) skipping sync makes difference and does not break guarantees
sync should have.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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/