xfs
[Top] [All Lists]

Re: XFS memory allocation deadlock in 2.6.38

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: XFS memory allocation deadlock in 2.6.38
From: Michel Lespinasse <walken@xxxxxxxxxx>
Date: Thu, 24 Mar 2011 16:45:40 -0700
Cc: Sean Noonan <Sean.Noonan@xxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Martin Bligh <Martin.Bligh@xxxxxxxxxxxx>, Trammell Hudson <Trammell.Hudson@xxxxxxxxxxxx>, Christos Zoulas <Christos.Zoulas@xxxxxxxxxxxx>, "linux-xfs@xxxxxxxxxxx" <linux-xfs@xxxxxxxxxxx>, Stephen Degler <Stephen.Degler@xxxxxxxxxxxx>, linux-mm@xxxxxxxxx
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301010343; bh=ZCID/4ZHw9zWRgslqhSGCBPaCRA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=CY8Q7FqgNrVBbKQiJbPwlx/tQcrGASo+lVrroghW52W4AnILEfykNvMMm2meEexdm XXc/jEgIBzIJwXNYErM3w==
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gAMCfGjViP837otjHEPkmaAl2QohEbIby+eP8Qb3Vxw=; b=vyGKeKC5CsrvNU/G/u0XqtpmqRt5o1OseTUCUfm1jsZvBJ5uE3dk/3VX5QFFtUruog kYcFw1u+IZjdGL6Nopbg==
Domainkey-signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=h6CSU72FPhsEfm+qVScuPPuGmQcD/qeUptcrieXtt7wIiaA1cuJMH4yIYtyBnDwBGR IGWV3hEdn2rdcL2mw6KA==
In-reply-to: <20110324174311.GA31576@xxxxxxxxxxxxx>
References: <081DDE43F61F3D43929A181B477DCA95639B52FD@xxxxxxxxxxxxxxxxxxxx> <081DDE43F61F3D43929A181B477DCA95639B5327@xxxxxxxxxxxxxxxxxxxx> <20110324174311.GA31576@xxxxxxxxxxxxx>
On Thu, Mar 24, 2011 at 10:43 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> Michel,
>
> can you take a look at this bug report?  It looks like a regression
> in your mlock handling changes.

I had a quick look and at this point I can describe how the patch will
affect behavior of this test, but not why this causes a deadlock with
xfs.

The test creates a writable, shared mapping of a file that does not
have data blocks allocated on disk, and also uses the MAP_POPULATE
flag.

Before 5ecfda041e4b4bd858d25bbf5a16c2a6c06d7272, make_pages_present
during the mmap would cause data blocks to get allocated on disk with
an xfs_vm_page_mkwrite call, and then the file pages would get mapped
as writable ptes.

After 5ecfda041e4b4bd858d25bbf5a16c2a6c06d7272, make_pages_present
does NOT cause data blocks to get allocated on disk. Instead,
xfs_vm_readpages is called, which (I suppose) does not allocate the
data blocks and returns zero filled pages instead, which get mapped as
readonly ptes. Later, the test tries writing into the mmap'ed block,
causing minor page faults, xfs_vm_page_mkwrite calls and data block
allocations to occur.


Regarding the deadlock: I am curious to see if it could be made to
happen before 5ecfda041e4b4bd858d25bbf5a16c2a6c06d7272. Could you test
what happens if you remove the MAP_POPULATE flag from your mmap call,
and instead read all pages from userspace right after the mmap ? I
expect you would then be able to trigger the deadlock before
5ecfda041e4b4bd858d25bbf5a16c2a6c06d7272.


This leaves the issue of the change of behavior for MAP_POPULATE on
ftruncated file holes. I'm not sure what to say there though, because
MAP_POPULATE is documented to cause file read-ahead (and it still does
after 5ecfda041e4b4bd858d25bbf5a16c2a6c06d7272), but that doesn't say
anything about block allocation.


Hope this helps,

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

<Prev in Thread] Current Thread [Next in Thread>