user/sven/linux.git, branch v3.10.13

Linux 3.10.13

2013-09-27T00:18:49Z

fuse: readdir: check for slash in names

2013-09-27T00:18:30Z

commit efeb9e60d48f7778fdcad4a0f3ad9ea9b19e5dfd upstream. Userspace can add names containing a slash character to the directory listing. Don't allow this as it could cause all sorts of trouble. Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

fuse: hotfix truncate_pagecache() issue

2013-09-27T00:18:30Z

commit 06a7c3c2781409af95000c60a5df743fd4e2f8b4 upstream. The way how fuse calls truncate_pagecache() from fuse_change_attributes() is completely wrong. Because, w/o i_mutex held, we never sure whether 'oldsize' and 'attr->size' are valid by the time of execution of truncate_pagecache(inode, oldsize, attr->size). In fact, as soon as we released fc->lock in the middle of fuse_change_attributes(), we completely loose control of actions which may happen with given inode until we reach truncate_pagecache. The list of potentially dangerous actions includes mmap-ed reads and writes, ftruncate(2) and write(2) extending file size. The typical outcome of doing truncate_pagecache() with outdated arguments is data corruption from user point of view. This is (in some sense) acceptable in cases when the issue is triggered by a change of the file on the server (i.e. externally wrt fuse operation), but it is absolutely intolerable in scenarios when a single fuse client modifies a file without any external intervention. A real life case I discovered by fsx-linux looked like this: 1. Shrinking ftruncate(2) comes to fuse_do_setattr(). The latter sends FUSE_SETATTR to the server synchronously, but before getting fc->lock ... 2. fuse_dentry_revalidate() is asynchronously called. It sends FUSE_LOOKUP to the server synchronously, then calls fuse_change_attributes(). The latter updates i_size, releases fc->lock, but before comparing oldsize vs attr->size.. 3. fuse_do_setattr() from the first step proceeds by acquiring fc->lock and updating attributes and i_size, but now oldsize is equal to outarg.attr.size because i_size has just been updated (step 2). Hence, fuse_do_setattr() returns w/o calling truncate_pagecache(). 4. As soon as ftruncate(2) completes, the user extends file size by write(2) making a hole in the middle of file, then reads data from the hole either by read(2) or mmap-ed read. The user expects to get zero data from the hole, but gets stale data because truncate_pagecache() is not executed yet. The scenario above illustrates one side of the problem: not truncating the page cache even though we should. Another side corresponds to truncating page cache too late, when the state of inode changed significantly. Theoretically, the following is possible: 1. As in the previous scenario fuse_dentry_revalidate() discovered that i_size changed (due to our own fuse_do_setattr()) and is going to call truncate_pagecache() for some 'new_size' it believes valid right now. But by the time that particular truncate_pagecache() is called ... 2. fuse_do_setattr() returns (either having called truncate_pagecache() or not -- it doesn't matter). 3. The file is extended either by write(2) or ftruncate(2) or fallocate(2). 4. mmap-ed write makes a page in the extended region dirty. The result will be the lost of data user wrote on the fourth step. The patch is a hotfix resolving the issue in a simplistic way: let's skip dangerous i_size update and truncate_pagecache if an operation changing file size is in progress. This simplistic approach looks correct for the cases w/o external changes. And to handle them properly, more sophisticated and intrusive techniques (e.g. NFS-like one) would be required. I'd like to postpone it until the issue is well discussed on the mailing list(s). Changed in v2: - improved patch description to cover both sides of the issue. Signed-off-by: Maxim Patlasov Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

fuse: invalidate inode attributes on xattr modification

2013-09-27T00:18:30Z

commit d331a415aef98717393dda0be69b7947da08eba3 upstream. Calls like setxattr and removexattr result in updation of ctime. Therefore invalidate inode attributes to force a refresh. Signed-off-by: Anand Avati Reviewed-by: Brian Foster Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

fuse: postpone end_page_writeback() in fuse_writepage_locked()

2013-09-27T00:18:30Z

commit 4a4ac4eba1010ef9a804569058ab29e3450c0315 upstream. The patch fixes a race between ftruncate(2), mmap-ed write and write(2): 1) An user makes a page dirty via mmap-ed write. 2) The user performs shrinking truncate(2) intended to purge the page. 3) Before fuse_do_setattr calls truncate_pagecache, the page goes to writeback. fuse_writepage_locked fills FUSE_WRITE request and releases the original page by end_page_writeback. 4) fuse_do_setattr() completes and successfully returns. Since now, i_mutex is free. 5) Ordinary write(2) extends i_size back to cover the page. Note that fuse_send_write_pages do wait for fuse writeback, but for another page->index. 6) fuse_writepage_locked proceeds by queueing FUSE_WRITE request. fuse_send_writepage is supposed to crop inarg->size of the request, but it doesn't because i_size has already been extended back. Moving end_page_writeback to the end of fuse_writepage_locked fixes the race because now the fact that truncate_pagecache is successfully returned infers that fuse_writepage_locked has already called end_page_writeback. And this, in turn, infers that fuse_flush_writepages has already called fuse_send_writepage, and the latter used valid (shrunk) i_size. write(2) could not extend it because of i_mutex held by ftruncate(2). Signed-off-by: Maxim Patlasov Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

clk: wm831x: Initialise wm831x pointer on init

2013-09-27T00:18:30Z

commit 08442ce993deeb15a070c14cc3f3459e87d111e0 upstream. Otherwise any attempt to interact with the hardware will crash. This is what happens when drivers get written blind. Signed-off-by: Mark Brown Signed-off-by: Mike Turquette Signed-off-by: Greg Kroah-Hartman

mtd: nand: fix NAND_BUSWIDTH_AUTO for x16 devices

2013-09-27T00:18:29Z

commit 68e8078072e802e77134664f11d2ffbfbd2f8fbe upstream. The code for NAND_BUSWIDTH_AUTO is broken. According to Alexander: "I have a problem with attach NAND UBI in 16 bit mode. NAND works fine if I specify NAND_BUSWIDTH_16 option, but not working with NAND_BUSWIDTH_AUTO option. In second case NAND chip is identifyed with ONFI." See his report for the rest of the details: http://lists.infradead.org/pipermail/linux-mtd/2013-July/047515.html Anyway, the problem is that nand_set_defaults() is called twice, we intend it to reset the chip functions to their x16 buswidth verions if the buswidth changed from x8 to x16; however, nand_set_defaults() does exactly nothing if called a second time. Fix this by hacking nand_set_defaults() to reset the buswidth-dependent functions if they were set to the x8 version the first time. Note that this does not do anything to reset from x16 to x8, but that's not the supported use case for NAND_BUSWIDTH_AUTO anyway. Signed-off-by: Brian Norris Reported-by: Alexander Shiyan Tested-by: Alexander Shiyan Cc: Matthieu Castet Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman

of: Fix missing memory initialization on FDT unflattening

2013-09-27T00:18:29Z

commit 0640332e073be9207f0784df43595c0c39716e42 upstream. Any calls to dt_alloc() need to be zeroed. This is a temporary fix, but the allocation function itself needs to zero memory before returning it. This is a follow up to patch 9e4012752, "of: fdt: fix memory initialization for expanded DT" which fixed one call site but missed another. Signed-off-by: Grant Likely Acked-by: Wladislav Wiebe Signed-off-by: Greg Kroah-Hartman

mmc: tmio_mmc_dma: fix PIO fallback on SDHI

2013-09-27T00:18:29Z

commit f936f9b67b7f8c2eae01dd303a0e90bd777c4679 upstream. I'm testing SH-Mobile SDHI driver in DMA mode with a new DMA controller using 'bonnie++' and getting DMA error after which the tmio_mmc_dma.c code falls back to PIO but all commands time out after that. It turned out that the fallback code calls tmio_mmc_enable_dma() with RX/TX channels already freed and pointers to them cleared, so that the function bails out early instead of clearing the DMA bit in the CTL_DMA_ENABLE register. The regression was introduced by commit 162f43e31c5a376ec16336e5d0ac973373d54c89 (mmc: tmio: fix a deadlock). Moving tmio_mmc_enable_dma() calls to the top of the PIO fallback code in tmio_mmc_start_dma_{rx|tx}() helps. Signed-off-by: Sergei Shtylyov Acked-by: Guennadi Liakhovetski Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

rbd: fix I/O error propagation for reads

2013-09-27T00:18:29Z

commit 17c1cc1d9293a568a00545469078e29555cc7f39 upstream. When a request returns an error, the driver needs to report the entire extent of the request as completed. Writes already did this, since they always set xferred = length, but reads were skipping that step if an error other than -ENOENT occurred. Instead, rbd would end up passing 0 xferred to blk_end_request(), which would always report needing more data. This resulted in an assert failing when more data was required by the block layer, but all the object requests were done: [ 1868.719077] rbd: obj_request read result -108 xferred 0 [ 1868.719077] [ 1868.719518] end_request: I/O error, dev rbd1, sector 0 [ 1868.719739] [ 1868.719739] Assertion failure in rbd_img_obj_callback() at line 1736: [ 1868.719739] [ 1868.719739] rbd_assert(more ^ (which == img_request->obj_request_count)); Without this assert, reads that hit errors would hang forever, since the block layer considered them incomplete. Fixes: http://tracker.ceph.com/issues/5647 Signed-off-by: Josh Durgin Reviewed-by: Alex Elder Signed-off-by: Greg Kroah-Hartman