xfs
[Top] [All Lists]

Re: [PATCH 2/2] xfs: fix getbmap vs mmap deadlock

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 2/2] xfs: fix getbmap vs mmap deadlock
From: Felix Blyakher <felixb@xxxxxxx>
Date: Thu, 16 Apr 2009 11:05:46 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20090409171412.GB25303@xxxxxxxxxxxxx>
References: <20090224133902.GC15820@xxxxxxxxxxxxx> <2B47193B-9486-4500-80C4-E96750BEA54B@xxxxxxx> <20090409171412.GB25303@xxxxxxxxxxxxx>

On Apr 9, 2009, at 12:14 PM, Christoph Hellwig wrote:

On Mon, Apr 06, 2009 at 07:42:57PM -0500, Felix Blyakher wrote:
Actually with the patch we either get all requested extents, or none
if we fail to get memory for them.
Should we teach the callers to expect ENOMEM and repeat the call
to xfs_getbmap with smaller number of extents?

The problem with any of that is that we don't actually get the exact
extent list but always a racy version.

Agree, but the alternative is ENOMEM, i.e. no bmap
at all.
Since the callers of xfs_getbmap are only ioctl's from
the user apps, we can move the logic of retrying the
call with the smaller number of extents to the app with
the understanding that it may not be exact snapshot of
the file's extents on a very active file. That would mean
that your change in kernel is good as is, but the API for
the GETBMAP[X] is changing by allowing ENOMEM returned.
We'll need to update the man page, and add ENOMEM handling
to xfs_bmap/xfs_io.

Felix

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