<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/fs, branch v2.6.26</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v2.6.26</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v2.6.26'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2008-07-12T21:33:42Z</updated>
<entry>
<title>cifs: fix wksidarr declaration to be big-endian friendly</title>
<updated>2008-07-12T21:33:42Z</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@redhat.com</email>
</author>
<published>2008-07-12T20:48:00Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=536abdb0802f3fac1b217530741853843d63c281'/>
<id>urn:sha1:536abdb0802f3fac1b217530741853843d63c281</id>
<content type='text'>
The current definition of wksidarr works fine on little endian arches
(since cpu_to_le32 is a no-op there), but on big-endian arches, it fails
to compile with this error:

error: braced-group within expression allowed only inside a function

The problem is that this static declaration has cpu_to_le32 embedded
within it, and that expands into a function macro.  We need to use
__constant_cpu_to_le32() instead.

Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Cc: Steven French &lt;sfrench@us.ibm.com&gt;
Cc: &lt;stable@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>cifs: fix inode leak in cifs_get_inode_info_unix</title>
<updated>2008-07-12T21:33:42Z</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@redhat.com</email>
</author>
<published>2008-07-12T20:47:59Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=e911d0cc877ff027d5bd09fc33148ab76f0fdf0e'/>
<id>urn:sha1:e911d0cc877ff027d5bd09fc33148ab76f0fdf0e</id>
<content type='text'>
Try this:

    mount a share with unix extensions
    create a file on it
    umount the share

You'll get the following message in the ring buffer:

VFS: Busy inodes after unmount of cifs. Self-destruct in 5 seconds.  Have a
nice day...

...the problem is that cifs_get_inode_info_unix is creating and hashing
a new inode even when it's going to return error anyway. The first
lookup when creating a file returns an error so we end up leaking this
inode before we do the actual create. This appears to be a regression
caused by commit 0e4bbde94fdc33f5b3d793166b21bf768ca3e098.

The following patch seems to fix it for me, and fixes a minor
formatting nit as well.

Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Acked-by: Steven French &lt;sfrench@us.ibm.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Fix reference counting race on log buffers</title>
<updated>2008-07-11T18:37:18Z</updated>
<author>
<name>Dave Chinner</name>
<email>david@fromorbit.com</email>
</author>
<published>2008-07-11T07:43:55Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=49641f1acfdfd437ed9b0a70b86bf36626c02afe'/>
<id>urn:sha1:49641f1acfdfd437ed9b0a70b86bf36626c02afe</id>
<content type='text'>
When we release the iclog, we do an atomic_dec_and_lock to determine if
we are the last reference and need to trigger update of log headers and
writeout.  However, in xlog_state_get_iclog_space() we also need to
check if we have the last reference count there.  If we do, we release
the log buffer, otherwise we decrement the reference count.

But the compare and decrement in xlog_state_get_iclog_space() is not
atomic, so both places can see a reference count of 2 and neither will
release the iclog.  That leads to a filesystem hang.

Close the race by replacing the atomic_read() and atomic_dec() pair with
atomic_add_unless() to ensure that they are executed atomically.

Signed-off-by: Dave Chinner &lt;david@fromorbit.com&gt;
Reviewed-by: Tim Shimmin &lt;tes@sgi.com&gt;
Tested-by: Eric Sandeen &lt;sandeen@sandeen.net&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>exec: fix stack excutability without PT_GNU_STACK</title>
<updated>2008-07-10T20:25:43Z</updated>
<author>
<name>Hugh Dickins</name>
<email>hugh@veritas.com</email>
</author>
<published>2008-07-10T20:19:20Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=96a8e13ed44e380fc2bb6c711d74d5ba698c00b2'/>
<id>urn:sha1:96a8e13ed44e380fc2bb6c711d74d5ba698c00b2</id>
<content type='text'>
Kernel Bugzilla #11063 points out that on some architectures (e.g. x86_32)
exec'ing an ELF without a PT_GNU_STACK program header should default to an
executable stack; but this got broken by the unlimited argv feature because
stack vma is now created before the right personality has been established:
so breaking old binaries using nested function trampolines.

Therefore re-evaluate VM_STACK_FLAGS in setup_arg_pages, where stack
vm_flags used to be set, before the mprotect_fixup.  Checking through
our existing VM_flags, none would have changed since insert_vm_struct:
so this seems safer than finding a way through the personality labyrinth.

Reported-by: pageexec@freemail.hu
Signed-off-by: Hugh Dickins &lt;hugh@veritas.com&gt;
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>ocfs2: Fix flags in ocfs2_file_lock</title>
<updated>2008-07-10T16:25:39Z</updated>
<author>
<name>Mark Fasheh</name>
<email>mfasheh@suse.com</email>
</author>
<published>2008-07-10T16:25:39Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=e988cf1cfed4ed80bf40528e655fe18bed6a38b6'/>
<id>urn:sha1:e988cf1cfed4ed80bf40528e655fe18bed6a38b6</id>
<content type='text'>
The stack-glue merge changed the way we use flags in dlmglue in that we now
use the fs/dlm equivalents. Unfortunately, a merge error left the new flock
code only partially updated. This took a while to show up though, because
the lock level constants are actually identical between o2dlm and fs/dlm.
The *_CONVERT and *_NOQUEUE flags have different values though, which is
eventually causing a crash in flags_to_o2dlm().

Signed-off-by: Mark Fasheh &lt;mfasheh@suse.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2</title>
<updated>2008-07-09T04:48:26Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2008-07-09T04:48:26Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=b72e9ebe7efa5754aa53bbdb0040a2d6eeb34db3'/>
<id>urn:sha1:b72e9ebe7efa5754aa53bbdb0040a2d6eeb34db3</id>
<content type='text'>
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2:
  [PATCH] ocfs2/dlm: Fixes oops in dlm_new_lockres()
</content>
</entry>
<entry>
<title>Merge branch 'hotfixes' of git://git.linux-nfs.org/projects/trondmy/nfs-2.6</title>
<updated>2008-07-08T19:40:57Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2008-07-08T19:40:57Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f57e91682d141ea50d8c6d42cdc251b6256a3755'/>
<id>urn:sha1:f57e91682d141ea50d8c6d42cdc251b6256a3755</id>
<content type='text'>
* 'hotfixes' of git://git.linux-nfs.org/projects/trondmy/nfs-2.6:
  SUNRPC: Fix an rpcbind breakage for the case of IPv6 lookups
  SUNRPC: Fix a double-free in rpcbind
  NFS: Fix readdir cache invalidation
</content>
</entry>
<entry>
<title>reiserfs: discard prealloc in reiserfs_delete_inode</title>
<updated>2008-07-08T19:39:31Z</updated>
<author>
<name>Jeff Mahoney</name>
<email>jeffm@suse.com</email>
</author>
<published>2008-07-08T18:37:06Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=eb35c218d83ec0780d9db869310f2e333f628702'/>
<id>urn:sha1:eb35c218d83ec0780d9db869310f2e333f628702</id>
<content type='text'>
With the removal of struct file from the xattr code,
reiserfs_file_release() isn't used anymore, so the prealloc isn't
discarded.  This causes hangs later down the line.

This patch adds it to reiserfs_delete_inode.  In most cases it will be a
no-op due to it already having been called, but will avoid hangs with
xattrs.

Signed-off-by: Jeff Mahoney &lt;jeffm@suse.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>NFS: Fix readdir cache invalidation</title>
<updated>2008-07-08T19:22:40Z</updated>
<author>
<name>Trond Myklebust</name>
<email>Trond.Myklebust@netapp.com</email>
</author>
<published>2008-07-07T17:26:10Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=2aac05a91971fbd1bf6cbed78b8731eb7454b9b7'/>
<id>urn:sha1:2aac05a91971fbd1bf6cbed78b8731eb7454b9b7</id>
<content type='text'>
invalidate_inode_pages2_range() takes page offset arguments, not byte
ranges.

Another thought is that individual pages might perhaps get evicted by VM
pressure, in which case we might perhaps want to re-read not only the
evicted page, but all subsequent pages too (in case the server returns
more/less data per page so that the alignment of the next entry
changes). We should therefore remove the condition that we only do this on
page-&gt;index==0.

Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
</content>
</entry>
<entry>
<title>[PATCH] ocfs2/dlm: Fixes oops in dlm_new_lockres()</title>
<updated>2008-07-07T18:24:29Z</updated>
<author>
<name>Sunil Mushran</name>
<email>sunil.mushran@oracle.com</email>
</author>
<published>2008-07-07T17:06:29Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=18c6ac383f3e46cfce08d0bf972705852a4e1268'/>
<id>urn:sha1:18c6ac383f3e46cfce08d0bf972705852a4e1268</id>
<content type='text'>
Patch fixes a race that can result in an oops while adding a
lockres to the dlm lockres tracking list.

Bug introduced by mainline commit 29576f8bb54045be944ba809d4fca1ad77c94165.

Signed-off-by: Sunil Mushran &lt;sunil.mushran@oracle.com&gt;
Signed-off-by: Mark Fasheh &lt;mfasheh@suse.com&gt;
</content>
</entry>
</feed>
