linux-stable.git, branch v3.2.23

Linux 3.2.23

2012-07-12T03:32:21+00:00

vfs: make O_PATH file descriptors usable for 'fchdir()'

2012-07-12T03:32:20+00:00

commit 332a2e1244bd08b9e3ecd378028513396a004a24 upstream.

We already use them for openat() and friends, but fchdir() also wants to
be able to use O_PATH file descriptors.  This should make it comparable
to the O_SEARCH of Solaris.  In particular, O_PATH allows you to access
(not-quite-open) a directory you don't have read persmission to, only
execute permission.

Noticed during development of multithread support for ksh93.

Reported-by: ольга крыжановская 
Cc: Al Viro 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

tcm_fc: Resolve suspicious RCU usage warnings

2012-07-12T03:32:19+00:00

commit 863555be0c81558b1af277addcf68acb8f778860 upstream.

Use rcu_dereference_protected to tell rcu that the ft_lport_lock
is held during ft_lport_create. This resolved "suspicious RCU usage"
warnings when debugging options are turned on.

Signed-off-by: Mark Rustad 
Tested-by: Ross Brattain 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Ben Hutchings

mm: Hold a file reference in madvise_remove

2012-07-12T03:32:19+00:00

commit 9ab4233dd08036fe34a89c7dc6f47a8bf2eb29eb upstream.

Otherwise the code races with munmap (causing a use-after-free
of the vma) or with close (causing a use-after-free of the struct
file).

The bug was introduced by commit 90ed52ebe481 ("[PATCH] holepunch: fix
mmap_sem i_mutex deadlock")

Cc: Hugh Dickins 
Cc: Miklos Szeredi 
Cc: Badari Pulavarty 
Cc: Nick Piggin 
Signed-off-by: Andy Lutomirski 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.2:
 - Adjust context
 - madvise_remove() calls vmtruncate_range(), not do_fallocate()]
Signed-off-by: Ben Hutchings

mtd: cafe_nand: fix an & vs | mistake

2012-07-12T03:32:18+00:00

commit 48f8b641297df49021093763a3271119a84990a2 upstream.

The intent here was clearly to set result to true if the 0x40000000 flag
was set.  But instead there was a | vs & typo and we always set result
to true.

Artem: check the spec at
wiki.laptop.org/images/5/5c/88ALP01_Datasheet_July_2007.pdf
and this fix looks correct.

Signed-off-by: Dan Carpenter 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: David Woodhouse 
Signed-off-by: Ben Hutchings

aio: make kiocb->private NUll in init_sync_kiocb()

2012-07-12T03:32:18+00:00

commit 2dfd06036ba7ae8e7be2daf5a2fff1dac42390bf upstream.

Ocfs2 uses kiocb.*private as a flag of unsigned long size. In
commit a11f7e6 ocfs2: serialize unaligned aio, the unaligned
io flag is involved in it to serialize the unaligned aio. As
*private is not initialized in init_sync_kiocb() of do_sync_write(),
this unaligned io flag may be unexpectly set in an aligned dio.
And this will cause OCFS2_I(inode)->ip_unaligned_aio decreased
to -1 in ocfs2_dio_end_io(), thus the following unaligned dio
will hang forever at ocfs2_aiodio_wait() in ocfs2_file_aio_write().

Signed-off-by: Junxiao Bi 
Acked-by: Jeff Moyer 
Signed-off-by: Joel Becker 
Signed-off-by: Ben Hutchings

ocfs2: clear unaligned io flag when dio fails

2012-07-12T03:32:17+00:00

commit 3e5d3c35a68c9a933bdbdd8685bd1a205b57e806 upstream.

The unaligned io flag is set in the kiocb when an unaligned
dio is issued, it should be cleared even when the dio fails,
or it may affect the following io which are using the same
kiocb.

Signed-off-by: Junxiao Bi 
Signed-off-by: Joel Becker 
Signed-off-by: Ben Hutchings

cifs: when server doesn't set CAP_LARGE_READ_X, cap default rsize at MaxBufferSize

2012-07-12T03:32:17+00:00

commit ec01d738a1691dfc85b96b9f796020267a7be577 upstream.

When the server doesn't advertise CAP_LARGE_READ_X, then MS-CIFS states
that you must cap the size of the read at the client's MaxBufferSize.
Unfortunately, testing with many older servers shows that they often
can't service a read larger than their own MaxBufferSize.

Since we can't assume what the server will do in this situation, we must
be conservative here for the default. When the server can't do large
reads, then assume that it can't satisfy any read larger than its
MaxBufferSize either.

Luckily almost all modern servers can do large reads, so this won't
affect them. This is really just for older win9x and OS/2 era servers.
Also, note that this patch just governs the default rsize. The admin can
always override this if he so chooses.

Reported-by: David H. Durgee 
Signed-off-by: Jeff Layton 
Signed-off-by: Steven French 
Signed-off-by: Ben Hutchings

Btrfs: run delayed directory updates during log replay

2012-07-12T03:32:17+00:00

commit b6305567e7d31b0bec1b8cb9ec0cadd7f7086f5f upstream.

While we are resolving directory modifications in the
tree log, we are triggering delayed metadata updates to
the filesystem btrees.

This commit forces the delayed updates to run so the
replay code can find any modifications done.  It stops
us from crashing because the directory deleltion replay
expects items to be removed immediately from the tree.

Signed-off-by: Chris Mason 
Signed-off-by: Ben Hutchings

bridge: Assign rtnl_link_ops to bridge devices created via ioctl (v2)

2012-07-12T03:32:16+00:00

[ Upstream commit 149ddd83a92b02c658d6c61f3276eb6500d585e8 ]

This ensures that bridges created with brctl(8) or ioctl(2) directly
also carry IFLA_LINKINFO when dumped over netlink. This also allows
to create a bridge with ioctl(2) and delete it with RTM_DELLINK.

Signed-off-by: Thomas Graf 
Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings