xfs | 1 Mar 01:41 2012
Picon

[XFS updates] XFS development tree branch, for-next, updated. v3.2-rc1-11460-g4b217ed

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "XFS development tree".

The branch, for-next has been updated
  8960501 xfs: include reservations in quota reporting
  18535a7 xfs: merge xfs_qm_export_dquot into xfs_qm_scall_getquota
  ad637a1 xfs: only take the ILOCK in xfs_reclaim_inode()
      from  9006fb91cfdf22812923f0536c7531c429c1aeab (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 89605011915aec5c6194e53a9f02631d68aea6bc
Author: Christoph Hellwig <hch <at> infradead.org>
Date:   Mon Feb 20 02:28:17 2012 +0000

    xfs: include reservations in quota reporting

    Report all quota usage including the currently pending reservations.  This
    avoids the need to flush delalloc space before gathering quota information,
    and matches quota enforcement, which already takes the reservations into
    account.

    This fixes xfstests 270.

    Reviewed-by: Dave Chinner <dchinner <at> redhat.com>
    Signed-off-by: Christoph Hellwig <hch <at> lst.de>
(Continue reading)

xfs | 1 Mar 01:41 2012
Picon

[XFS updates] XFS development tree branch, master, updated. v3.2-rc1-11460-g4b217ed

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "XFS development tree".

The branch, master has been updated
  8960501 xfs: include reservations in quota reporting
  18535a7 xfs: merge xfs_qm_export_dquot into xfs_qm_scall_getquota
  ad637a1 xfs: only take the ILOCK in xfs_reclaim_inode()
      from  9006fb91cfdf22812923f0536c7531c429c1aeab (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 89605011915aec5c6194e53a9f02631d68aea6bc
Author: Christoph Hellwig <hch <at> infradead.org>
Date:   Mon Feb 20 02:28:17 2012 +0000

    xfs: include reservations in quota reporting

    Report all quota usage including the currently pending reservations.  This
    avoids the need to flush delalloc space before gathering quota information,
    and matches quota enforcement, which already takes the reservations into
    account.

    This fixes xfstests 270.

    Reviewed-by: Dave Chinner <dchinner <at> redhat.com>
    Signed-off-by: Christoph Hellwig <hch <at> lst.de>
(Continue reading)

Ben Myers | 1 Mar 04:03 2012
Picon

Re: Warning from unlock_new_inode

Hi Dave,

Eric mentioned a really excellent bugfix earlier.  This must be it.

On Wed, Feb 29, 2012 at 12:49:06PM +1100, Dave Chinner wrote:
> xfs: fix inode lookup race
> 
> From: Dave Chinner <dchinner <at> redhat.com>
> 
> When we get concurrent lookups of the same inode that is not in the
> per-AG inode cache, there is a race condition that triggers warnings
> in unlock_new_inode() indicating that we are initialising an inode
> that isn't in a the correct state for a new inode.
> 
> When we do an inode lookup via a file handle or a bulkstat, we don't
> serialise lookups at a higher level through the dentry cache (i.e.
> pathless lookup), and so we can get concurrent lookups of the same
> inode.
> 
> The race condition is between the insertion of the inode into the
> cache in the case of a cache miss and a concurrently lookup:
> 
> Thread 1			Thread 2
> xfs_iget()
>   xfs_iget_cache_miss()
>     xfs_iread()
>     lock radix tree
>     radix_tree_insert()
>     				rcu_read_lock
> 				radix_tree_lookup
(Continue reading)

xfs | 1 Mar 04:29 2012
Picon

[XFS updates] XFS development tree branch, for-next, updated. v3.2-rc1-11461-gcd21cea

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "XFS development tree".

The branch, for-next has been updated
  cd21cea xfs: fix inode lookup race
      from  4b217ed9e30f94b6e8e5e262020ef0ceab6113af (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit cd21cea3aa527024797ba2089b3c37e94c385606
Author: Dave Chinner <dchinner <at> redhat.com>
Date:   Wed Feb 29 21:22:40 2012 -0600

    xfs: fix inode lookup race

    When we get concurrent lookups of the same inode that is not in the
    per-AG inode cache, there is a race condition that triggers warnings
    in unlock_new_inode() indicating that we are initialising an inode
    that isn't in a the correct state for a new inode.

    When we do an inode lookup via a file handle or a bulkstat, we don't
    serialise lookups at a higher level through the dentry cache (i.e.
    pathless lookup), and so we can get concurrent lookups of the same
    inode.

    The race condition is between the insertion of the inode into the
(Continue reading)

xfs | 1 Mar 04:30 2012
Picon

[XFS updates] XFS development tree branch, for-linus, updated. v3.2-rc1-11438-g5cfc459

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "XFS development tree".

The branch, for-linus has been updated
  5cfc459 xfs: fix inode lookup race
      from  c922bbc819324558e61402a7a76c10c550ca61bc (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 5cfc459ec18d1f0bbf6971966d35cdb8e66cfbbc
Author: Dave Chinner <dchinner <at> redhat.com>
Date:   Wed Feb 29 21:22:40 2012 -0600

    xfs: fix inode lookup race

    When we get concurrent lookups of the same inode that is not in the
    per-AG inode cache, there is a race condition that triggers warnings
    in unlock_new_inode() indicating that we are initialising an inode
    that isn't in a the correct state for a new inode.

    When we do an inode lookup via a file handle or a bulkstat, we don't
    serialise lookups at a higher level through the dentry cache (i.e.
    pathless lookup), and so we can get concurrent lookups of the same
    inode.

    The race condition is between the insertion of the inode into the
(Continue reading)

Dave Chinner | 1 Mar 04:58 2012

Re: Warning from unlock_new_inode

On Wed, Feb 29, 2012 at 09:03:24PM -0600, Ben Myers wrote:
> > The race condition is between the insertion of the inode into the
> > cache in the case of a cache miss and a concurrently lookup:
> > 
> > Thread 1			Thread 2
> > xfs_iget()
> >   xfs_iget_cache_miss()
> >     xfs_iread()
> >     lock radix tree
> >     radix_tree_insert()
> >     				rcu_read_lock
> > 				radix_tree_lookup
> > 				lock inode flags
> > 				XFS_INEW not set
> > 				igrab()
> > 				unlock inode flags
> > 				rcu_read_unlock
> > 				use uninitialised inode
> > 				.....
> >     lock inode flags
> >     set XFS_INEW
> >     unlock inode flags
> >     unlock radix tree
> >   xfs_setup_inode()
> >     inode flags = I_NEW
> >     unlock_new_inode()
> >       WARNING as inode flags != I_NEW

.....

(Continue reading)

Debian Bug Tracking System | 1 Mar 05:03 2012
Picon

Processed: found 661580 in

Processing commands for control <at> bugs.debian.org:

> found 661580
Bug #661580 [xfsprogs] mkfs.xfs fails to detect correct sector size
Ignoring request to alter fixed versions of bug #661580 to the same values previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
--

-- 
661580: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661580
Debian Bug Tracking System
Contact owner <at> bugs.debian.org with problems

_______________________________________________
xfs mailing list
xfs <at> oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Debian Bug Tracking System | 1 Mar 05:30 2012
Picon

Processed: notfound 661580 in 3.1.7

Processing commands for control <at> bugs.debian.org:

> notfound 661580 3.1.7
Bug #661580 [xfsprogs] mkfs.xfs fails to detect correct sector size
Bug No longer marked as found in versions xfsprogs/3.1.7.
> thanks
Stopping processing here.

Please contact me if you need assistance.
--

-- 
661580: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661580
Debian Bug Tracking System
Contact owner <at> bugs.debian.org with problems

_______________________________________________
xfs mailing list
xfs <at> oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Debian Bug Tracking System | 1 Mar 05:33 2012
Picon

Processed: found 661580 in 3.1.4

Processing commands for control <at> bugs.debian.org:

> found 661580 3.1.4
Bug #661580 [xfsprogs] mkfs.xfs fails to detect correct sector size
Bug Marked as found in versions xfsprogs/3.1.4.
> thanks
Stopping processing here.

Please contact me if you need assistance.
--

-- 
661580: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661580
Debian Bug Tracking System
Contact owner <at> bugs.debian.org with problems

_______________________________________________
xfs mailing list
xfs <at> oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Goswin von Brederlow | 1 Mar 04:53 2012
Picon

Bug#661580: mkfs.xfs fails to detect correct sector size

Eric Sandeen <sandeen <at> sandeen.net> writes:

> On 2/28/12 3:11 AM, Christoph Hellwig wrote:
>> Carlos, didn't you plan to look into this issue?
>> 
>> Goswin, how do you determin that mkfs is still doing unaligned I/O
>> when forcing the large sevtor size?  Once we set the sector size XFS
>> can't do I/O smaller than it.
>
> I did think this was supposed to be working already:
>
>         get_topology(&xi, &ft);
>
>         if (ft.sectoralign) {
>                 /*
>                  * Older Linux software RAID versions want the sector size
>                  * to match the block size to avoid switching I/O sizes.
>                  * For the legacy libdisk case we thus set the sector size to
>                  * match the block size.  For systems using libblkid we assume
>                  * that the kernel is recent enough to not require this and
>                  * ft.sectoralign will never be set.
>                  */
>                 sectorsize = blocksize;
>         } else if (!ssflag) {
>                 /*
>                  * Unless specified manually on the command line use the
>                  * advertised sector size of the device.
>                  */
>                 sectorsize = ft.sectorsize ? ft.sectorsize : XFS_MIN_SECTORSIZE;
>         }
(Continue reading)


Gmane