<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/fs, branch v3.0.85</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/fs?h=v3.0.85</id>
<link rel='self' href='https://git.amat.us/linux/atom/fs?h=v3.0.85'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-07-03T18:03:24Z</updated>
<entry>
<title>UBIFS: fix a horrid bug</title>
<updated>2013-07-03T18:03:24Z</updated>
<author>
<name>Artem Bityutskiy</name>
<email>artem.bityutskiy@linux.intel.com</email>
</author>
<published>2013-06-28T11:15:15Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c6c46477761504a89d5c68331f3b86fe31b51338'/>
<id>urn:sha1:c6c46477761504a89d5c68331f3b86fe31b51338</id>
<content type='text'>
commit 605c912bb843c024b1ed173dc427cd5c08e5d54d upstream.

Al Viro pointed me to the fact that '-&gt;readdir()' and '-&gt;llseek()' have no
mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are
in the middle of 'ubifs_readdir()'.

This means that 'file-&gt;private_data' can be freed while 'ubifs_readdir()' uses
it, and this is a very bad bug: not only 'ubifs_readdir()' can return garbage,
but this may corrupt memory and lead to all kinds of problems like crashes an
security holes.

This patch fixes the problem by using the 'file-&gt;f_version' field, which
'-&gt;llseek()' always unconditionally sets to zero. We set it to 1 in
'ubifs_readdir()' and whenever we detect that it became 0, we know there was a
seek and it is time to clear the state saved in 'file-&gt;private_data'.

I tested this patch by writing a user-space program which runds readdir and
seek in parallell. I could easily crash the kernel without these patches, but
could not crash it with these patches.

Reported-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Tested-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
Signed-off-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>UBIFS: prepare to fix a horrid bug</title>
<updated>2013-07-03T18:03:24Z</updated>
<author>
<name>Artem Bityutskiy</name>
<email>artem.bityutskiy@linux.intel.com</email>
</author>
<published>2013-06-28T11:15:14Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1f4f917e5e882de1e701d7b26955884ed16604d5'/>
<id>urn:sha1:1f4f917e5e882de1e701d7b26955884ed16604d5</id>
<content type='text'>
commit 33f1a63ae84dfd9ad298cf275b8f1887043ced36 upstream.

Al Viro pointed me to the fact that '-&gt;readdir()' and '-&gt;llseek()' have no
mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are
in the middle of 'ubifs_readdir()'.

First of all, this means that 'file-&gt;private_data' can be freed while
'ubifs_readdir()' uses it.  But this particular patch does not fix the problem.
This patch is only a preparation, and the fix will follow next.

In this patch we make 'ubifs_readdir()' stop using 'file-&gt;f_pos' directly,
because 'file-&gt;f_pos' can be changed by '-&gt;llseek()' at any point. This may
lead 'ubifs_readdir()' to returning inconsistent data: directory entry names
may correspond to incorrect file positions.

So here we introduce a local variable 'pos', read 'file-&gt;f_pose' once at very
the beginning, and then stick to 'pos'. The result of this is that when
'ubifs_dir_llseek()' changes 'file-&gt;f_pos' while we are in the middle of
'ubifs_readdir()', the latter "wins".

Reported-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Tested-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
Signed-off-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>perf: Disable monitoring on setuid processes for regular users</title>
<updated>2013-07-03T18:03:23Z</updated>
<author>
<name>Stephane Eranian</name>
<email>eranian@google.com</email>
</author>
<published>2013-06-20T09:36:28Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5d28835c59b02d4389003bbfa7c4276375f39ed6'/>
<id>urn:sha1:5d28835c59b02d4389003bbfa7c4276375f39ed6</id>
<content type='text'>
commit 2976b10f05bd7f6dab9f9e7524451ddfed656a89 upstream.

There was a a bug in setup_new_exec(), whereby
the test to disabled perf monitoring was not
correct because the new credentials for the
process were not yet committed and therefore
the get_dumpable() test was never firing.

The patch fixes the problem by moving the
perf_event test until after the credentials
are committed.

Signed-off-by: Stephane Eranian &lt;eranian@google.com&gt;
Tested-by: Jiri Olsa &lt;jolsa@redhat.com&gt;
Acked-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ceph: fix statvfs fr_size</title>
<updated>2013-06-20T18:28:21Z</updated>
<author>
<name>Sage Weil</name>
<email>sage@inktank.com</email>
</author>
<published>2013-02-22T23:31:00Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=088d9d4d782d66941fc9e29ff4eb0dd72f84493b'/>
<id>urn:sha1:088d9d4d782d66941fc9e29ff4eb0dd72f84493b</id>
<content type='text'>
commit 92a49fb0f79f3300e6e50ddf56238e70678e4202 upstream.

Different versions of glibc are broken in different ways, but the short of
it is that for the time being, frsize should == bsize, and be used as the
multiple for the blocks, free, and available fields.  This mirrors what is
done for NFS.  The previous reporting of the page size for frsize meant
that newer glibc and df would report a very small value for the fs size.

Fixes http://tracker.ceph.com/issues/3793.

Signed-off-by: Sage Weil &lt;sage@inktank.com&gt;
Reviewed-by: Greg Farnum &lt;greg@inktank.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>jfs: fix a couple races</title>
<updated>2013-06-07T19:46:48Z</updated>
<author>
<name>Dave Kleikamp</name>
<email>dave.kleikamp@oracle.com</email>
</author>
<published>2013-05-01T16:08:38Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3b1a317977a8d16d743e8f85ed9a5a7f668b61d5'/>
<id>urn:sha1:3b1a317977a8d16d743e8f85ed9a5a7f668b61d5</id>
<content type='text'>
commit 73aaa22d5ffb2630456bac2f9a4ed9b81d0d7271 upstream.

This patch fixes races uncovered by xfstests testcase 068.

One race is the result of jfs_sync() trying to write a sync point to the
journal after it has been frozen (or possibly in the process). Since
freezing sync's the journal, there is no need to write a sync point so
we simply want to return.

The second involves jfs_write_inode() being called on a deleted inode.
It calls jfs_flush_journal which is held up by the jfs_commit thread
doing the final iput on the same deleted inode, which itself is
waiting for the I_SYNC flag to be cleared. jfs_write_inode need not
do anything when i_nlink is zero, which is the easy fix.

Reported-by: Michael L. Semon &lt;mlsemon35@gmail.com&gt;
Signed-off-by: Dave Kleikamp &lt;dave.kleikamp@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>cifs: fix potential buffer overrun when composing a new options string</title>
<updated>2013-06-07T19:46:48Z</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@redhat.com</email>
</author>
<published>2013-05-24T11:40:04Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1b968601f5b7e98cf519684589f853768d377144'/>
<id>urn:sha1:1b968601f5b7e98cf519684589f853768d377144</id>
<content type='text'>
commit 166faf21bd14bc5c5295a44874bf7f3930c30b20 upstream.

Consider the case where we have a very short ip= string in the original
mount options, and when we chase a referral we end up with a very long
IPv6 address. Be sure to allow for that possibility when estimating the
size of the string to allocate.

Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Signed-off-by: Steve French &lt;sfrench@us.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>nilfs2: fix issue of nilfs_set_page_dirty() for page at EOF boundary</title>
<updated>2013-06-07T19:46:36Z</updated>
<author>
<name>Ryusuke Konishi</name>
<email>konishi.ryusuke@lab.ntt.co.jp</email>
</author>
<published>2013-05-24T22:55:29Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ed2bfaffd22f37e669feea0a97ab81d187ccb768'/>
<id>urn:sha1:ed2bfaffd22f37e669feea0a97ab81d187ccb768</id>
<content type='text'>
commit 136e8770cd5d1fe38b3c613100dd6dc4db6d4fa6 upstream.

nilfs2: fix issue of nilfs_set_page_dirty for page at EOF boundary

DESCRIPTION:
 There are use-cases when NILFS2 file system (formatted with block size
lesser than 4 KB) can be remounted in RO mode because of encountering of
"broken bmap" issue.

The issue was reported by Anthony Doggett &lt;Anthony2486@interfaces.org.uk&gt;:
 "The machine I've been trialling nilfs on is running Debian Testing,
  Linux version 3.2.0-4-686-pae (debian-kernel@lists.debian.org) (gcc
  version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.35-2), but I've
  also reproduced it (identically) with Debian Unstable amd64 and Debian
  Experimental (using the 3.8-trunk kernel).  The problematic partitions
  were formatted with "mkfs.nilfs2 -b 1024 -B 8192"."

SYMPTOMS:
(1) System log contains error messages likewise:

    [63102.496756] nilfs_direct_assign: invalid pointer: 0
    [63102.496786] NILFS error (device dm-17): nilfs_bmap_assign: broken bmap (inode number=28)
    [63102.496798]
    [63102.524403] Remounting filesystem read-only

(2) The NILFS2 file system is remounted in RO mode.

REPRODUSING PATH:
(1) Create volume group with name "unencrypted" by means of vgcreate utility.
(2) Run script (prepared by Anthony Doggett &lt;Anthony2486@interfaces.org.uk&gt;):

----------------[BEGIN SCRIPT]--------------------

VG=unencrypted
lvcreate --size 2G --name ntest $VG
mkfs.nilfs2 -b 1024 -B 8192 /dev/mapper/$VG-ntest
mkdir /var/tmp/n
mkdir /var/tmp/n/ntest
mount /dev/mapper/$VG-ntest /var/tmp/n/ntest
mkdir /var/tmp/n/ntest/thedir
cd /var/tmp/n/ntest/thedir
sleep 2
date
darcs init
sleep 2
dmesg|tail -n 5
date
darcs whatsnew || true
date
sleep 2
dmesg|tail -n 5
----------------[END SCRIPT]--------------------

REPRODUCIBILITY: 100%

INVESTIGATION:
As it was discovered, the issue takes place during segment
construction after executing such sequence of user-space operations:

  open("_darcs/index", O_RDWR|O_CREAT|O_NOCTTY, 0666) = 7
  fstat(7, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
  ftruncate(7, 60)

The error message "NILFS error (device dm-17): nilfs_bmap_assign: broken
bmap (inode number=28)" takes place because of trying to get block
number for third block of the file with logical offset #3072 bytes.  As
it is possible to see from above output, the file has 60 bytes of the
whole size.  So, it is enough one block (1 KB in size) allocation for
the whole file.  Trying to operate with several blocks instead of one
takes place because of discovering several dirty buffers for this file
in nilfs_segctor_scan_file() method.

The root cause of this issue is in nilfs_set_page_dirty function which
is called just before writing to an mmapped page.

When nilfs_page_mkwrite function handles a page at EOF boundary, it
fills hole blocks only inside EOF through __block_page_mkwrite().

The __block_page_mkwrite() function calls set_page_dirty() after filling
hole blocks, thus nilfs_set_page_dirty function (=
a_ops-&gt;set_page_dirty) is called.  However, the current implementation
of nilfs_set_page_dirty() wrongly marks all buffers dirty even for page
at EOF boundary.

As a result, buffers outside EOF are inconsistently marked dirty and
queued for write even though they are not mapped with nilfs_get_block
function.

FIX:
This modifies nilfs_set_page_dirty() not to mark hole blocks dirty.

Thanks to Vyacheslav Dubeyko for his effort on analysis and proposals
for this issue.

Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
Reported-by: Anthony Doggett &lt;Anthony2486@interfaces.org.uk&gt;
Reported-by: Vyacheslav Dubeyko &lt;slava@dubeyko.com&gt;
Cc: Vyacheslav Dubeyko &lt;slava@dubeyko.com&gt;
Tested-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ocfs2: goto out_unlock if ocfs2_get_clusters_nocache() failed in ocfs2_fiemap()</title>
<updated>2013-06-07T19:46:36Z</updated>
<author>
<name>Joseph Qi</name>
<email>joseph.qi@huawei.com</email>
</author>
<published>2013-05-24T22:55:34Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=70d53e5acf842b00efe048846aaf49d1f664b23d'/>
<id>urn:sha1:70d53e5acf842b00efe048846aaf49d1f664b23d</id>
<content type='text'>
commit b4ca2b4b577c3530e34dcfaafccb2cc680ce95d1 upstream.

Last time we found there is lock/unlock bug in ocfs2_file_aio_write, and
then we did a thorough search for all lock resources in
ocfs2_inode_info, including rw, inode and open lockres and found this
bug.  My kernel version is 3.0.13, and it is also in the lastest version
3.9.  In ocfs2_fiemap, once ocfs2_get_clusters_nocache failed, it should
goto out_unlock instead of out, because we need release buffer head, up
read alloc sem and unlock inode.

Signed-off-by: Joseph Qi &lt;joseph.qi@huawei.com&gt;
Reviewed-by: Jie Liu &lt;jeff.liu@oracle.com&gt;
Cc: Mark Fasheh &lt;mfasheh@suse.com&gt;
Cc: Joel Becker &lt;jlbec@evilplan.org&gt;
Acked-by: Sunil Mushran &lt;sunil.mushran@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>fat: fix possible overflow for fat_clusters</title>
<updated>2013-06-07T19:46:35Z</updated>
<author>
<name>OGAWA Hirofumi</name>
<email>hirofumi@mail.parknet.co.jp</email>
</author>
<published>2013-05-24T22:55:08Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2b90057252cfde394556c989a0eb740ed6734389'/>
<id>urn:sha1:2b90057252cfde394556c989a0eb740ed6734389</id>
<content type='text'>
commit 7b92d03c3239f43e5b86c9cc9630f026d36ee995 upstream.

Intermediate value of fat_clusters can be overflowed on 32bits arch.

Reported-by: Krzysztof Strasburger &lt;strasbur@chkw386.ch.pwr.wroc.pl&gt;
Signed-off-by: OGAWA Hirofumi &lt;hirofumi@mail.parknet.co.jp&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>cifs: only set ops for inodes in I_NEW state</title>
<updated>2013-06-07T19:46:35Z</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@redhat.com</email>
</author>
<published>2013-05-07T15:28:31Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=dae84f25ac695ff740ce1ca2226e5451ba296fc3'/>
<id>urn:sha1:dae84f25ac695ff740ce1ca2226e5451ba296fc3</id>
<content type='text'>
commit c2b93e0699723700f886ce17bb65ffd771195a6d upstream.

It's generally not safe to reset the inode ops once they've been set. In
the case where the inode was originally thought to be a directory and
then later found to be a DFS referral, this can lead to an oops when we
try to trigger an inode op on it after changing the ops to the blank
referral operations.

Reported-and-Tested-by: Sachin Prabhu &lt;sprabhu@redhat.com&gt;
Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Signed-off-by: Steve French &lt;smfrench@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
