xfs
[Top] [All Lists]

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

To: Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx>
Subject: Re: [PATCH 0/4] xfs: fixes for XFS_DIFLAG2_DAX support
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 17 Feb 2016 11:23:53 +1100
Cc: xfs@xxxxxxxxxxx, jack@xxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20160216235353.GA25419@xxxxxxxxxxxxxxx>
References: <1455513734-15192-1-git-send-email-david@xxxxxxxxxxxxx> <20160216235353.GA25419@xxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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@xxxxxxxxxxxxx

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