linux.git/fs, branch v3.9-rc4

vfs,proc: guarantee unique inodes in /proc

2013-03-22T18:44:04+00:00

Dave Jones found another /proc issue with his Trinity tool: thanks to
the namespace model, we can have multiple /proc dentries that point to
the same inode, aliasing directories in /proc//net/ for example.

This ends up being a total disaster, because it acts like hardlinked
directories, and causes locking problems.  We rely on the topological
sort of the inodes pointed to by dentries, and if we have aliased
directories, that odering becomes unreliable.

In short: don't do this.  Multiple dentries with the same (directory)
inode is just a bad idea, and the namespace code should never have
exposed things this way.  But we're kind of stuck with it.

This solves things by just always allocating a new inode during /proc
dentry lookup, instead of using "iget_locked()" to look up existing
inodes by superblock and number.  That actually simplies the code a bit,
at the cost of potentially doing more inode [de]allocations.

That said, the inode lookup wasn't free either (and did a lot of locking
of inodes), so it is probably not that noticeable.  We could easily keep
the old lookup model for non-directory entries, but rather than try to
be excessively clever this just implements the minimal and simplest
workaround for the problem.

Reported-and-tested-by: Dave Jones 
Analyzed-by: Al Viro 
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds

Merge branch 'for-next' of git://git.samba.org/sfrench/cifs-2.6

2013-03-22T00:59:22+00:00

Pull CIFS fixes from Steve French:
 "Three small CIFS Fixes (the most important of the three fixes a recent
  problem authenticating to Windows 8 using cifs rather than SMB2)"

* 'for-next' of git://git.samba.org/sfrench/cifs-2.6:
  cifs: ignore everything in SPNEGO blob after mechTypes
  cifs: delay super block destruction until all cifsFileInfo objects are gone
  cifs: map NT_STATUS_SHARING_VIOLATION to EBUSY instead of ETXTBSY

Merge tag 'ext4_for_linue' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4

2013-03-22T00:56:10+00:00

Pull ext4 fixes from Ted Ts'o:
 "Fix a number of regression and other bugs in ext4, most of which were
  relatively obscure cornercases or races that were found using
  regression tests."

* tag 'ext4_for_linue' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: (21 commits)
  ext4: fix data=journal fast mount/umount hang
  ext4: fix ext4_evict_inode() racing against workqueue processing code
  ext4: fix memory leakage in mext_check_coverage
  ext4: use s_extent_max_zeroout_kb value as number of kb
  ext4: use atomic64_t for the per-flexbg free_clusters count
  jbd2: fix use after free in jbd2_journal_dirty_metadata()
  ext4: reserve metadata block for every delayed write
  ext4: update reserved space after the 'correction'
  ext4: do not use yield()
  ext4: remove unused variable in ext4_free_blocks()
  ext4: fix WARN_ON from ext4_releasepage()
  ext4: fix the wrong number of the allocated blocks in ext4_split_extent()
  ext4: update extent status tree after an extent is zeroed out
  ext4: fix wrong m_len value after unwritten extent conversion
  ext4: add self-testing infrastructure to do a sanity check
  ext4: avoid a potential overflow in ext4_es_can_be_merged()
  ext4: invalidate extent status tree during extent migration
  ext4: remove unnecessary wait for extent conversion in ext4_fallocate()
  ext4: add warning to ext4_convert_unwritten_extents_endio
  ext4: disable merging of uninitialized extents
  ...

cifs: ignore everything in SPNEGO blob after mechTypes

2013-03-21T17:40:19+00:00

We've had several reports of people attempting to mount Windows 8 shares
and getting failures with a return code of -EINVAL. The default sec=
mode changed recently to sec=ntlmssp. With that, we expect and parse a
SPNEGO blob from the server in the NEGOTIATE reply.

The current decode_negTokenInit function first parses all of the
mechTypes and then tries to parse the rest of the negTokenInit reply.
The parser however currently expects a mechListMIC or nothing to follow the
mechTypes, but Windows 8 puts a mechToken field there instead to carry
some info for the new NegoEx stuff.

In practice, we don't do anything with the fields after the mechTypes
anyway so I don't see any real benefit in continuing to parse them.
This patch just has the kernel ignore the fields after the mechTypes.
We'll probably need to reinstate some of this if we ever want to support
NegoEx.

Reported-by: Jason Burgess 
Reported-by: Yan Li 
Signed-off-by: Jeff Layton 
Cc: 
Signed-off-by: Steve French

ext4: fix data=journal fast mount/umount hang

2013-03-20T13:42:11+00:00

In data=journal mode, if we unmount the file system before a
transaction has a chance to complete, when the journal inode is being
evicted, we can end up calling into jbd2_log_wait_commit() for the
last transaction, after the journalling machinery has been shut down.

Arguably we should adjust ext4_should_journal_data() to return FALSE
for the journal inode, but the only place it matters is
ext4_evict_inode(), and so to save a bit of CPU time, and to make the
patch much more obviously correct by inspection(tm), we'll fix it by
explicitly not trying to waiting for a journal commit when we are
evicting the journal inode, since it's guaranteed to never succeed in
this case.

This can be easily replicated via: 

     mount -t ext4 -o data=journal /dev/vdb /vdb ; umount /vdb

------------[ cut here ]------------
WARNING: at /usr/projects/linux/ext4/fs/jbd2/journal.c:542 __jbd2_log_start_commit+0xba/0xcd()
Hardware name: Bochs
JBD2: bad log_start_commit: 3005630206 3005630206 0 0
Modules linked in:
Pid: 2909, comm: umount Not tainted 3.8.0-rc3 #1020
Call Trace:
 [] warn_slowpath_common+0x68/0x7d
 [] ? __jbd2_log_start_commit+0xba/0xcd
 [] warn_slowpath_fmt+0x2b/0x2f
 [] __jbd2_log_start_commit+0xba/0xcd
 [] jbd2_log_start_commit+0x24/0x34
 [] ext4_evict_inode+0x71/0x2e3
 [] evict+0x94/0x135
 [] iput+0x10a/0x110
 [] jbd2_journal_destroy+0x190/0x1ce
 [] ? bit_waitqueue+0x50/0x50
 [] ext4_put_super+0x52/0x294
 [] generic_shutdown_super+0x48/0xb4
 [] kill_block_super+0x22/0x60
 [] deactivate_locked_super+0x22/0x49
 [] deactivate_super+0x30/0x33
 [] mntput_no_expire+0x107/0x10c
 [] sys_umount+0x2cf/0x2e0
 [] sys_oldumount+0x12/0x14
 [] syscall_call+0x7/0xb
---[ end trace 6a954cc790501c1f ]---
jbd2_log_wait_commit: error: j_commit_request=-1289337090, tid=0

Signed-off-by: "Theodore Ts'o" 
Reviewed-by: Jan Kara 
Cc: stable@vger.kernel.org

ext4: fix ext4_evict_inode() racing against workqueue processing code

2013-03-20T13:39:42+00:00

Commit 84c17543ab56 (ext4: move work from io_end to inode) triggered a
regression when running xfstest #270 when the file system is mounted
with dioread_nolock.

The problem is that after ext4_evict_inode() calls ext4_ioend_wait(),
this guarantees that last io_end structure has been freed, but it does
not guarantee that the workqueue structure, which was moved into the
inode by commit 84c17543ab56, is actually finished.  Once
ext4_flush_completed_IO() calls ext4_free_io_end() on CPU #1, this
will allow ext4_ioend_wait() to return on CPU #2, at which point the
evict_inode() codepath can race against the workqueue code on CPU #1
accessing EXT4_I(inode)->i_unwritten_work to find the next item of
work to do.

Fix this by calling cancel_work_sync() in ext4_ioend_wait(), which
will be renamed ext4_ioend_shutdown(), since it is only used by
ext4_evict_inode().  Also, move the call to ext4_ioend_shutdown()
until after truncate_inode_pages() and filemap_write_and_wait() are
called, to make sure all dirty pages have been written back and
flushed from the page cache first.

BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [] cwq_activate_delayed_work+0x3b/0x7e
*pdpt = 0000000030bc3001 *pde = 0000000000000000 
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
Modules linked in:
Pid: 6, comm: kworker/u:0 Not tainted 3.8.0-rc3-00013-g84c1754-dirty #91 Bochs Bochs
EIP: 0060:[] EFLAGS: 00010046 CPU: 0
EIP is at cwq_activate_delayed_work+0x3b/0x7e
EAX: 00000000 EBX: 00000000 ECX: f505fe54 EDX: 00000000
ESI: ed5b697c EDI: 00000006 EBP: f64b7e8c ESP: f64b7e84
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
CR0: 8005003b CR2: 00000000 CR3: 30bc2000 CR4: 000006f0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process kworker/u:0 (pid: 6, ti=f64b6000 task=f64b4160 task.ti=f64b6000)
Stack:
 f505fe00 00000006 f64b7e9c c01de3d7 f6435540 00000003 f64b7efc c01def1d
 f6435540 00000002 00000000 0000008a c16d0808 c040a10b c16d07d8 c16d08b0
 f505fe00 c16d0780 00000000 00000000 ee153df4 c1ce4a30 c17d0e30 00000000
Call Trace:
 [] cwq_dec_nr_in_flight+0x71/0xfb
 [] process_one_work+0x5d8/0x637
 [] ? ext4_end_bio+0x300/0x300
 [] worker_thread+0x249/0x3ef
 [] kthread+0xd8/0xeb
 [] ? manage_workers+0x4bb/0x4bb
 [] ? trace_hardirqs_on+0x27/0x37
 [] ret_from_kernel_thread+0x1b/0x28
 [] ? __init_kthread_worker+0x71/0x71
Code: 01 83 15 ac ff 6c c1 00 31 db 89 c6 8b 00 a8 04 74 12 89 c3 30 db 83 05 b0 ff 6c c1 01 83 15 b4 ff 6c c1 00 89 f0 e8 42 ff ff ff <8b> 13 89 f0 83 05 b8 ff 6c c1
 6c c1 00 31 c9 83
EIP: [] cwq_activate_delayed_work+0x3b/0x7e SS:ESP 0068:f64b7e84
CR2: 0000000000000000
---[ end trace a1923229da53d8a4 ]---

Signed-off-by: "Theodore Ts'o" 
Cc: Jan Kara

Merge tag 'for-linus-v3.9-rc4' of git://oss.sgi.com/xfs/xfs

2013-03-19T22:17:40+00:00

Pull XFS fixes from Ben Myers:

 - Fix for a potential infinite loop which was introduced in commit
   4d559a3bcb73 ("xfs: limit speculative prealloc near ENOSPC
   thresholds")

 - Fix for the return type of xfs_iomap_eof_prealloc_initial_size from
   commit a1e16c26660b ("xfs: limit speculative prealloc size on sparse
   files")

 - Fix for a failed buffer readahead causing subsequent callers to fail
   incorrectly

* tag 'for-linus-v3.9-rc4' of git://oss.sgi.com/xfs/xfs:
  xfs: ensure we capture IO errors correctly
  xfs: fix xfs_iomap_eof_prealloc_initial_size type
  xfs: fix potential infinite loop in xfs_iomap_prealloc_size()

xfs: ensure we capture IO errors correctly

2013-03-18T18:39:10+00:00

Failed buffer readahead can leave the buffer in the cache marked
with an error. Most callers that then issue a subsequent read on the
buffer do not zero the b_error field out, and so we may incorectly
detect an error during IO completion due to the stale error value
left on the buffer.

Avoid this problem by zeroing the error before IO submission. This
ensures that the only IO errors that are detected those captured
from are those captured from bio submission or completion.

Signed-off-by: Dave Chinner 
Reviewed-by: Mark Tinguely 
Signed-off-by: Ben Myers 

(cherry picked from commit c163f9a1760229a95d04e37b332de7d5c1c225cd)

xfs: fix xfs_iomap_eof_prealloc_initial_size type

2013-03-18T18:38:50+00:00

Fix the return type of xfs_iomap_eof_prealloc_initial_size() to
xfs_fsblock_t to reflect the fact that the return value may be an
unsigned 64 bits if XFS_BIG_BLKNOS is defined.

Signed-off-by: Mark Tinguely 
Reviewed-by: Dave Chinner 
Signed-off-by: Ben Myers 

(cherry picked from commit e8108cedb1c5d1dc359690d18ca997e97a0061d2)

xfs: fix potential infinite loop in xfs_iomap_prealloc_size()

2013-03-18T18:30:38+00:00

If freesp == 0, we could end up in an infinite loop while squashing
the preallocation. Break the loop when we've killed the prealloc
entirely.

Signed-off-by: Brian Foster 
Reviewed-by: Dave Chinner 
Signed-off-by: Ben Myers 

(cherry picked from commit e78c420bfc2608bb5f9a0b9165b1071c1e31166a)