<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/fs, branch v3.4.52</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/fs?h=v3.4.52</id>
<link rel='self' href='https://git.amat.us/linux/atom/fs?h=v3.4.52'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-07-03T17:59:05Z</updated>
<entry>
<title>UBIFS: fix a horrid bug</title>
<updated>2013-07-03T17:59:05Z</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=4e3010bf3aab410b6a983fcd05fe65e671648f55'/>
<id>urn:sha1:4e3010bf3aab410b6a983fcd05fe65e671648f55</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-03T17:59:05Z</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=eafde0bc4fbb118408050b7f32dde3575930ef16'/>
<id>urn:sha1:eafde0bc4fbb118408050b7f32dde3575930ef16</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-03T17:59:04Z</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=f57f135abe8d94c8d83763de99b01d223b60e1df'/>
<id>urn:sha1:f57f135abe8d94c8d83763de99b01d223b60e1df</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>inotify: invalid mask should return a error number but not set it</title>
<updated>2013-06-27T18:27:34Z</updated>
<author>
<name>Zhao Hongjiang</name>
<email>zhaohongjiang@huawei.com</email>
</author>
<published>2013-04-30T22:26:46Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3c103fee36561149e04587684e068a2854ba6e5b'/>
<id>urn:sha1:3c103fee36561149e04587684e068a2854ba6e5b</id>
<content type='text'>
commit 04df32fa10ab9a6f0643db2949d42efc966bc844 upstream.

When we run the crackerjack testsuite, the inotify_add_watch test is
stalled.

This is caused by the invalid mask 0 - the task is waiting for the event
but it never comes.  inotify_add_watch() should return -EINVAL as it did
before commit 676a0675cf92 ("inotify: remove broken mask checks causing
unmount to be EINVAL").  That commit removes the invalid mask check, but
that check is needed.

Check the mask's ALL_INOTIFY_BITS before the inotify_arg_to_mask() call.
If none are set, just return -EINVAL.

Because IN_UNMOUNT is in ALL_INOTIFY_BITS, this change will not trigger
the problem that above commit fixed.

[akpm@linux-foundation.org: fix build]
Signed-off-by: Zhao Hongjiang &lt;zhaohongjiang@huawei.com&gt;
Acked-by: Jim Somerville &lt;Jim.Somerville@windriver.com&gt;
Cc: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
Cc: Jerome Marchand &lt;jmarchan@redhat.com&gt;
Cc: Eric Paris &lt;eparis@parisplace.org&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>ceph: fix statvfs fr_size</title>
<updated>2013-06-20T18:58:47Z</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=999899ad5860fb34e679ca2a853074e54fda9d93'/>
<id>urn:sha1:999899ad5860fb34e679ca2a853074e54fda9d93</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>libceph: wrap auth ops in wrapper functions</title>
<updated>2013-06-20T18:58:47Z</updated>
<author>
<name>Sage Weil</name>
<email>sage@inktank.com</email>
</author>
<published>2013-03-25T17:26:14Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=aa80dd9dbe86743ae6e52c836f6ab1472c469927'/>
<id>urn:sha1:aa80dd9dbe86743ae6e52c836f6ab1472c469927</id>
<content type='text'>
commit 27859f9773e4a0b2042435b13400ee2c891a61f4 upstream.

Use wrapper functions that check whether the auth op exists so that callers
do not need a bunch of conditional checks.  Simplifies the external
interface.

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

</content>
</entry>
<entry>
<title>libceph: add update_authorizer auth method</title>
<updated>2013-06-20T18:58:46Z</updated>
<author>
<name>Sage Weil</name>
<email>sage@inktank.com</email>
</author>
<published>2013-03-25T17:26:01Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=29c65a277a64645af853e8c9a9b3dda0ddc421e0'/>
<id>urn:sha1:29c65a277a64645af853e8c9a9b3dda0ddc421e0</id>
<content type='text'>
commit 0bed9b5c523d577378b6f83eab5835fe30c27208 upstream.

Currently the messenger calls out to a get_authorizer con op, which will
create a new authorizer if it doesn't yet have one.  In the meantime, when
we rotate our service keys, the authorizer doesn't get updated.  Eventually
it will be rejected by the server on a new connection attempt and get
invalidated, and we will then rebuild a new authorizer, but this is not
ideal.

Instead, if we do have an authorizer, call a new update_authorizer op that
will verify that the current authorizer is using the latest secret.  If it
is not, we will build a new one that does.  This avoids the transient
failure.

This fixes one of the sorry sequence of events for bug

	http://tracker.ceph.com/issues/4282

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

</content>
</entry>
<entry>
<title>ceph: ceph_pagelist_append might sleep while atomic</title>
<updated>2013-06-20T18:58:43Z</updated>
<author>
<name>Jim Schutt</name>
<email>jaschut@sandia.gov</email>
</author>
<published>2013-05-15T18:03:35Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c7ed0848c61d75c58f1c5b13c308f7fcaf94ed89'/>
<id>urn:sha1:c7ed0848c61d75c58f1c5b13c308f7fcaf94ed89</id>
<content type='text'>
commit 39be95e9c8c0b5668c9f8806ffe29bf9f4bc0f40 upstream.

Ceph's encode_caps_cb() worked hard to not call __page_cache_alloc()
while holding a lock, but it's spoiled because ceph_pagelist_addpage()
always calls kmap(), which might sleep.  Here's the result:

[13439.295457] ceph: mds0 reconnect start
[13439.300572] BUG: sleeping function called from invalid context at include/linux/highmem.h:58
[13439.309243] in_atomic(): 1, irqs_disabled(): 0, pid: 12059, name: kworker/1:1
    . . .
[13439.376225] Call Trace:
[13439.378757]  [&lt;ffffffff81076f4c&gt;] __might_sleep+0xfc/0x110
[13439.384353]  [&lt;ffffffffa03f4ce0&gt;] ceph_pagelist_append+0x120/0x1b0 [libceph]
[13439.391491]  [&lt;ffffffffa0448fe9&gt;] ceph_encode_locks+0x89/0x190 [ceph]
[13439.398035]  [&lt;ffffffff814ee849&gt;] ? _raw_spin_lock+0x49/0x50
[13439.403775]  [&lt;ffffffff811cadf5&gt;] ? lock_flocks+0x15/0x20
[13439.409277]  [&lt;ffffffffa045e2af&gt;] encode_caps_cb+0x41f/0x4a0 [ceph]
[13439.415622]  [&lt;ffffffff81196748&gt;] ? igrab+0x28/0x70
[13439.420610]  [&lt;ffffffffa045e9f8&gt;] ? iterate_session_caps+0xe8/0x250 [ceph]
[13439.427584]  [&lt;ffffffffa045ea25&gt;] iterate_session_caps+0x115/0x250 [ceph]
[13439.434499]  [&lt;ffffffffa045de90&gt;] ? set_request_path_attr+0x2d0/0x2d0 [ceph]
[13439.441646]  [&lt;ffffffffa0462888&gt;] send_mds_reconnect+0x238/0x450 [ceph]
[13439.448363]  [&lt;ffffffffa0464542&gt;] ? ceph_mdsmap_decode+0x5e2/0x770 [ceph]
[13439.455250]  [&lt;ffffffffa0462e42&gt;] check_new_map+0x352/0x500 [ceph]
[13439.461534]  [&lt;ffffffffa04631ad&gt;] ceph_mdsc_handle_map+0x1bd/0x260 [ceph]
[13439.468432]  [&lt;ffffffff814ebc7e&gt;] ? mutex_unlock+0xe/0x10
[13439.473934]  [&lt;ffffffffa043c612&gt;] extra_mon_dispatch+0x22/0x30 [ceph]
[13439.480464]  [&lt;ffffffffa03f6c2c&gt;] dispatch+0xbc/0x110 [libceph]
[13439.486492]  [&lt;ffffffffa03eec3d&gt;] process_message+0x1ad/0x1d0 [libceph]
[13439.493190]  [&lt;ffffffffa03f1498&gt;] ? read_partial_message+0x3e8/0x520 [libceph]
    . . .
[13439.587132] ceph: mds0 reconnect success
[13490.720032] ceph: mds0 caps stale
[13501.235257] ceph: mds0 recovery completed
[13501.300419] ceph: mds0 caps renewed

Fix it up by encoding locks into a buffer first, and when the number
of encoded locks is stable, copy that into a ceph_pagelist.

[elder@inktank.com: abbreviated the stack info a bit.]

Signed-off-by: Jim Schutt &lt;jaschut@sandia.gov&gt;
Reviewed-by: Alex Elder &lt;elder@inktank.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ceph: add cpu_to_le32() calls when encoding a reconnect capability</title>
<updated>2013-06-20T18:58:43Z</updated>
<author>
<name>Jim Schutt</name>
<email>jaschut@sandia.gov</email>
</author>
<published>2013-05-15T18:03:35Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a169043d55452c50a80673f47ab30763cdba407a'/>
<id>urn:sha1:a169043d55452c50a80673f47ab30763cdba407a</id>
<content type='text'>
commit c420276a532a10ef59849adc2681f45306166b89 upstream.

In his review, Alex Elder mentioned that he hadn't checked that
num_fcntl_locks and num_flock_locks were properly decoded on the
server side, from a le32 over-the-wire type to a cpu type.
I checked, and AFAICS it is done; those interested can consult
    Locker::_do_cap_update()
in src/mds/Locker.cc and src/include/encoding.h in the Ceph server
code (git://github.com/ceph/ceph).

I also checked the server side for flock_len decoding, and I believe
that also happens correctly, by virtue of having been declared
__le32 in struct ceph_mds_cap_reconnect, in src/include/ceph_fs.h.

Signed-off-by: Jim Schutt &lt;jaschut@sandia.gov&gt;
Reviewed-by: Alex Elder &lt;elder@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:49:34Z</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=2e6c53ddade9836cb96821539c664cd6dff0be42'/>
<id>urn:sha1:2e6c53ddade9836cb96821539c664cd6dff0be42</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>
</feed>
