Re: [PATCH 0/4] xfs: fixes for XFS_DIFLAG2_DAX support

From: Dave Chinner <david@fromorbit.com>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: jack@suse.cz, xfs@oss.sgi.com
Subject: Re: [PATCH 0/4] xfs: fixes for XFS_DIFLAG2_DAX support
Date: Wed, 17 Feb 2016 11:23:53 +1100	[thread overview]
Message-ID: <20160217002353.GA19486@dastard> (raw)
In-Reply-To: <20160216235353.GA25419@linux.intel.com>

On Tue, Feb 16, 2016 at 04:53:53PM -0700, Ross Zwisler wrote:
> On Mon, Feb 15, 2016 at 04:22:10PM +1100, Dave Chinner wrote:
> > Hi folks,
> > 
> > This is a series to add the correct constraints to using the on-disk
> > inode flag to enable DAX on per-file basis. The same constraints are
> > placed on setting the flag on directories for inheritance purposes.
> > 
> > These constraints are:
> > 	- the inode flag is limited to regular files or directory
> > 	  inodes.
> > 	- the S_DAX flag is only ever set on regular files
> > 	- the flag can only ever be set on filesystems which have
> > 	  blocksize == PAGE_SIZE (for now)
> > 	- When the flag is set or cleared, the current mapping
> > 	  contents are flushed and then invalidated so that the new
> > 	  access mode starts with an empty mapping.
> > 	- Setting or clearing the flag is atomic w.r.t. IO and
> > 	  page faults.
> > 
> > I've tested these manually with xfs_io (patchset for supporting
> > chattr +x/-x to be sent soon), and it all appears to work as
> > expected. I'd like to push these for 4.5-rc6 so the initial kernel
> > with support for this flag doesn't do silly things, so comments,
> > testing and review woul dbe appreciated.
> 
> I'm seeing the following errors with xfs/305 when running these four patches +
> v4.5-rc4:
> 
> ================================================
> [ BUG: lock held when returning to user space! ]
> 4.5.0-rc4+ #4 Not tainted
> ------------------------------------------------
> fsstress/2311 is leaving the kernel with locks still held!
> 2 locks held by fsstress/2311:
>  #0:  (&(&ip->i_iolock)->mr_lock){++++++}, at: [<     inline     >] mrupdate_nested fs/xfs/mrlock.h:48
>  #0:  (&(&ip->i_iolock)->mr_lock){++++++}, at: [<ffffffff8149ba82>] xfs_ilock+0x152/0x1f0 fs/xfs/xfs_inode.c:170
>  #1:  (&(&ip->i_mmaplock)->mr_lock){+.+.+.}, at: [<     inline     >] mrupdate_nested fs/xfs/mrlock.h:48
>  #1:  (&(&ip->i_mmaplock)->mr_lock){+.+.+.}, at: [<ffffffff8149baad>] xfs_ilock+0x17d/0x1f0 fs/xfs/xfs_inode.c:175

I can see an error path where this might occur on a project quota
related test (fsstress can change projid, that can fail the quota
reservation, leaks locks). I'll fix and resend later today.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs