<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/fs/xfs, branch linux-2.6.28.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.28.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.28.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2009-02-12T17:50:37Z</updated>
<entry>
<title>XFS: set b_error from bio error in xfs_buf_bio_end_io</title>
<updated>2009-02-12T17:50:37Z</updated>
<author>
<name>Lachlan McIlroy</name>
</author>
<published>2008-12-12T04:27:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ed9b1d5568deee0f1f07205259fb37553fe18eff'/>
<id>urn:sha1:ed9b1d5568deee0f1f07205259fb37553fe18eff</id>
<content type='text'>
commit cfbe52672fbc6f333892e8dde82c35e0a76aa5f5 upstream.

Preserve any error returned by the bio layer.

Reviewed-by: Eric Sandeen &lt;sandeen@sandeen.net&gt;
Reviewed-by: Tim Shimmin &lt;tes@sgi.com&gt;
Signed-off-by: Lachlan McIlroy &lt;lachlan@sgi.com&gt;
Cc: Neil Brown &lt;neilb@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>XFS: truncate readdir offsets to signed 32 bit values</title>
<updated>2009-01-18T18:44:06Z</updated>
<author>
<name>Christoph Hellwig</name>
</author>
<published>2009-01-08T19:00:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=891d1a57586691daf4c375579735f32e403b5468'/>
<id>urn:sha1:891d1a57586691daf4c375579735f32e403b5468</id>
<content type='text'>
commit 15440319767942a363f282d6585303d3d75088ba upstream.

John Stanley reported EOVERFLOW errors in readdir from his self-build
glibc.  I traced this down to glibc enabling d_off overflow checks
in one of the about five million different getdents implementations.

In 2.6.28 Dave Woodhouse moved our readdir double buffering required
for NFS4 readdirplus into nfsd and at that point we lost the capping
of the directory offsets to 32 bit signed values.  Johns glibc used
getdents64 to even implement readdir for normal 32 bit offset dirents,
and failed with EOVERFLOW only if this happens on the first dirent in
a getdents call.  I managed to come up with a testcase that uses
raw getdents and does the EOVERFLOW check manually.  We always hit
it with our last entry due to the special end of directory marker.

The patch below is a dumb version of just putting back the masking,
to make sure we have the same behavior as in 2.6.27 and earlier.

I will work on a better and cleaner fix for 2.6.30.

Reported-by: John Stanley &lt;jpsinthemix@verizon.net&gt;
Tested-by: John Stanley &lt;jpsinthemix@verizon.net&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Dave Chinner &lt;david@fromorbit.com&gt;
Signed-off-by: Lachlan McIlroy &lt;lachlan@sgi.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>[XFS] Fix hang after disallowed rename across directory quota domains</title>
<updated>2008-12-05T04:39:13Z</updated>
<author>
<name>Dave Chinner</name>
</author>
<published>2008-12-03T22:09:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=576a488a27f267af203f3ea69c700a1612335e9f'/>
<id>urn:sha1:576a488a27f267af203f3ea69c700a1612335e9f</id>
<content type='text'>
When project quota is active and is being used for directory tree
quota control, we disallow rename outside the current directory
tree. This requires a check to be made after all the inodes
involved in the rename are locked. We fail to unlock the inodes
correctly if we disallow the rename when the target is outside the
current directory tree. This results in a hang on the next access
to the inodes involved in failed rename.

Reported-by: Arkadiusz Miskiewicz &lt;arekm@maven.pl&gt;
Signed-off-by: Dave Chinner &lt;david@fromorbit.com&gt;
Tested-by: Arkadiusz Miskiewicz &lt;arekm@maven.pl&gt;
Signed-off-by: Lachlan McIlroy &lt;lachlan@sgi.com&gt;
</content>
</entry>
<entry>
<title>[XFS] XFS: Check for valid transaction headers in recovery</title>
<updated>2008-11-10T07:01:50Z</updated>
<author>
<name>David Chinner</name>
</author>
<published>2008-10-30T06:40:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=220ca310a53200b4bfbc7c4c6e365eea284ec44f'/>
<id>urn:sha1:220ca310a53200b4bfbc7c4c6e365eea284ec44f</id>
<content type='text'>
When we are about to add a new item to a transaction in recovery, we need
to check that it is valid first. Currently we just assert that header
magic number matches, but in production systems that is not present and we
add a corrupted transaction to the list to be processed. This results in a
kernel oops later when processing the corrupted transaction.

Instead, if we detect a corrupted transaction, abort recovery and leave
the user to clean up the mess that has occurred.

SGI-PV: 988145

SGI-Modid: xfs-linux-melb:xfs-kern:32356a

Signed-off-by: David Chinner &lt;david@fromorbit.com&gt;
Signed-off-by: Tim Shimmin &lt;tes@sgi.com&gt;
Signed-off-by: Eric Sandeen &lt;sandeen@sandeen.net&gt;
Signed-off-by: Lachlan McIlroy &lt;lachlan@sgi.com&gt;
</content>
</entry>
<entry>
<title>[XFS] handle memory allocation failures during log initialisation</title>
<updated>2008-11-10T06:57:06Z</updated>
<author>
<name>Dave Chinner</name>
</author>
<published>2008-11-10T05:50:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8f330f5149ef41ff943b04d914406cc417f62784'/>
<id>urn:sha1:8f330f5149ef41ff943b04d914406cc417f62784</id>
<content type='text'>
When there is no memory left in the system, xfs_buf_get_noaddr()
can fail. If this happens at mount time during xlog_alloc_log()
we fail to catch the error and oops.

Catch the error from xfs_buf_get_noaddr(), and allow other memory
allocations to fail and catch those errors too. Report the error
to the console and fail the mount with ENOMEM.

Tested by manually injecting errors into xfs_buf_get_noaddr() and
xlog_alloc_log().

Version 2:
o remove unnecessary casts of the returned pointer from kmem_zalloc()

SGI-PV: 987246

Signed-off-by: Dave Chinner &lt;david@fromorbit.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Lachlan McIlroy &lt;lachlan@sgi.com&gt;
</content>
</entry>
<entry>
<title>[XFS] Account for allocated blocks when expanding directories</title>
<updated>2008-11-10T06:51:14Z</updated>
<author>
<name>David Chinner</name>
</author>
<published>2008-10-30T06:38:12Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6f9f51adb6ac0a49fce49e01c47dcfc2810c6e9d'/>
<id>urn:sha1:6f9f51adb6ac0a49fce49e01c47dcfc2810c6e9d</id>
<content type='text'>
When we create a directory, we reserve a number of blocks for the maximum
possible expansion of of the directory due to various btree splits,
freespace allocation, etc. Unfortunately, each allocation is not reflected
in the total number of blocks still available to the transaction, so the
maximal reservation is used over and over again.

This leads to problems where an allocation group has only enough blocks
for *some* of the allocations required for the directory modification.
After the first N allocations, the remaining blocks in the allocation
group drops below the total reservation, and subsequent allocations fail
because the allocator will not allow the allocation to proceed if the AG
does not have the enough blocks available for the entire allocation total.

This results in an ENOSPC occurring after an allocation has already
occurred. This results in aborting the directory operation (leaving the
directory in an inconsistent state) and cancelling a dirty transaction,
which results in a filesystem shutdown.

Avoid the problem by reflecting the number of blocks allocated in any
directory expansion in the total number of blocks available to the
modification in progress. This prevents a directory modification from
being aborted part way through with an ENOSPC.

SGI-PV: 988144

SGI-Modid: xfs-linux-melb:xfs-kern:32340a

Signed-off-by: David Chinner &lt;david@fromorbit.com&gt;
Signed-off-by: Lachlan McIlroy &lt;lachlan@sgi.com&gt;
</content>
</entry>
<entry>
<title>[XFS] Wait for all I/O on truncate to zero file size</title>
<updated>2008-11-10T06:51:00Z</updated>
<author>
<name>Lachlan McIlroy</name>
</author>
<published>2008-10-30T05:59:06Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2cf7f0da3ae225848a2ee10d4e216448a770fd00'/>
<id>urn:sha1:2cf7f0da3ae225848a2ee10d4e216448a770fd00</id>
<content type='text'>
It's possible to have outstanding xfs_ioend_t's queued when the file size
is zero. This can happen in the direct I/O path when a direct I/O write
fails due to ENOSPC. In this case the xfs_ioend_t will still be queued (ie
xfs_end_io_direct() does not know that the I/O failed so can't force the
xfs_ioend_t to be flushed synchronously).

When we truncate a file on unlink we don't know to wait for these
xfs_ioend_ts and we can have a use-after-free situation if the inode is
reclaimed before the xfs_ioend_t is finally processed.

As was suggested by Dave Chinner lets wait for all I/Os to complete when
truncating the file size to zero.

SGI-PV: 981668

SGI-Modid: xfs-linux-melb:xfs-kern:32216a

Signed-off-by: Lachlan McIlroy &lt;lachlan@sgi.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@infradead.org&gt;
</content>
</entry>
<entry>
<title>[XFS] Fix use-after-free with log and quotas</title>
<updated>2008-11-10T06:43:23Z</updated>
<author>
<name>Lachlan McIlroy</name>
</author>
<published>2008-10-30T05:53:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9ccbece546cf836f67f6d9bb4bf2f70f7476cb2c'/>
<id>urn:sha1:9ccbece546cf836f67f6d9bb4bf2f70f7476cb2c</id>
<content type='text'>
Destroying the quota stuff on unmount can access the log - ie
XFS_QM_DONE() ends up in xfs_dqunlock() which calls
xfs_trans_unlocked_item() and then xfs_log_move_tail(). By this time the
log has already been destroyed. Just move the cleanup of the quota code
earlier in xfs_unmountfs() before the call to xfs_log_unmount(). Moving
XFS_QM_DONE() up near XFS_QM_DQPURGEALL() seems like a good spot.

SGI-PV: 987086

SGI-Modid: xfs-linux-melb:xfs-kern:32148a

Signed-off-by: Lachlan McIlroy &lt;lachlan@sgi.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@infradead.org&gt;
Signed-off-by: Peter Leckie &lt;pleckie@sgi.com&gt;
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/viro/bdev</title>
<updated>2008-10-23T17:23:07Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2008-10-23T17:23:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=22484856402bfa1ff3defe47f6029ab0418240d9'/>
<id>urn:sha1:22484856402bfa1ff3defe47f6029ab0418240d9</id>
<content type='text'>
* git://git.kernel.org/pub/scm/linux/kernel/git/viro/bdev: (66 commits)
  [PATCH] kill the rest of struct file propagation in block ioctls
  [PATCH] get rid of struct file use in blkdev_ioctl() BLKBSZSET
  [PATCH] get rid of blkdev_locked_ioctl()
  [PATCH] get rid of blkdev_driver_ioctl()
  [PATCH] sanitize blkdev_get() and friends
  [PATCH] remember mode of reiserfs journal
  [PATCH] propagate mode through swsusp_close()
  [PATCH] propagate mode through open_bdev_excl/close_bdev_excl
  [PATCH] pass fmode_t to blkdev_put()
  [PATCH] kill the unused bsize on the send side of /dev/loop
  [PATCH] trim file propagation in block/compat_ioctl.c
  [PATCH] end of methods switch: remove the old ones
  [PATCH] switch sr
  [PATCH] switch sd
  [PATCH] switch ide-scsi
  [PATCH] switch tape_block
  [PATCH] switch dcssblk
  [PATCH] switch dasd
  [PATCH] switch mtd_blkdevs
  [PATCH] switch mmc
  ...
</content>
</entry>
<entry>
<title>[PATCH] Remove XFS buffered readdir hack</title>
<updated>2008-10-23T09:13:06Z</updated>
<author>
<name>David Woodhouse</name>
</author>
<published>2008-07-31T19:38:04Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d88f1833fcbb5663c86253039966f880f8f46b1a'/>
<id>urn:sha1:d88f1833fcbb5663c86253039966f880f8f46b1a</id>
<content type='text'>
Now that we've moved the readdir hack to the nfsd code, we can
remove the local version from the XFS code.

Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
</feed>
