- 27 Sep, 2013 40 commits
-
-
Miklos Szeredi authored
commit efeb9e60 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 <mszeredi@suse.cz> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Maxim Patlasov authored
commit 06a7c3c2 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 <mpatlasov@parallels.com> Signed-off-by:
-
Anand Avati authored
commit d331a415 upstream. Calls like setxattr and removexattr result in updation of ctime. Therefore invalidate inode attributes to force a refresh. Signed-off-by:
Anand Avati <avati@redhat.com> Reviewed-by:
Brian Foster <bfoster@redhat.com> Signed-off-by:
-
Maxim Patlasov authored
commit 4a4ac4eb 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:
-
Mark Brown authored
commit 08442ce9 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 <broonie@linaro.org> Signed-off-by:
Mike Turquette <mturquette@linaro.org> Signed-off-by:
-
Brian Norris authored
commit 68e80780 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 <computersforpeace@gmail.com> Reported-by:
Alexander Shiyan <shc_work@mail.ru> Tested-by:
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
-
Grant Likely authored
commit 0640332e 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 9e401275, "of: fdt: fix memory initialization for expanded DT" which fixed one call site but missed another. Signed-off-by:
Grant Likely <grant.likely@linaro.org> Acked-by:
Wladislav Wiebe <wladislav.kw@gmail.com> Signed-off-by:
-
Sergei Shtylyov authored
commit f936f9b6 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 162f43e3 (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 <sergei.shtylyov@cogentembedded.com> Acked-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
-
Josh Durgin authored
commit 17c1cc1d 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/5647Signed-off-by:
Josh Durgin <josh.durgin@inktank.com> Reviewed-by:
Alex Elder <alex.elder@linaro.org> Signed-off-by:
-
majianpeng authored
commit 494ddd11 upstream. Signed-off-by:
Jianpeng Ma <majianpeng@gmail.com> Reviewed-by:
Sage Weil <sage@inktank.com> Signed-off-by:
-
Sage Weil authored
commit 9542cf0b upstream. Fix a typo that used the wrong bitmask for the pg.seed calculation. This is normally unnoticed because in most cases pg_num == pgp_num. It is, however, a bug that is easily corrected. Signed-off-by:
Alex Elder <alex.elder@linary.org> Signed-off-by:
-
majianpeng authored
commit 73d9f7ee upstream. For nofail == false request, if __map_request failed, the caller does cleanup work, like releasing the relative pages. It doesn't make any sense to retry this request. Signed-off-by:
-
Richard Weinberger authored
commit f75b1b1b upstream. UML needs it's own probe_kernel_read() to handle kernel mode faults correctly. The implementation uses mincore() on the host side to detect whether a page is owned by the UML kernel process. This fixes also a possible crash when sysrq-t is used. Starting with 3.10 sysrq-t calls probe_kernel_read() to read details from the kernel workers. As kernel worker are completely async pointers may turn NULL while reading them. Signed-off-by:
Richard Weinberger <richard@nod.at> Cc: <stian@nixia.no> Cc: <tj@kernel.org> Signed-off-by:
-
Alex Deucher authored
commit 118bdbd8 upstream. This LCD monitor (1280x1024 native) has a completely bogus detailed timing (640x350@70hz). User reports that 1280x1024@60 has waves so prefer 1280x1024@75. Manufacturer: MED Model: 7b8 Serial#: 99188 Year: 2005 Week: 5 EDID Version: 1.3 Analog Display Input, Input Voltage Level: 0.700/0.700 V Sync: Separate Max Image Size [cm]: horiz.: 34 vert.: 27 Gamma: 2.50 DPMS capabilities: Off; RGB/Color Display First detailed timing is preferred mode redX: 0.645 redY: 0.348 greenX: 0.280 greenY: 0.605 blueX: 0.142 blueY: 0.071 whiteX: 0.313 whiteY: 0.329 Supported established timings: 720x400@70Hz 640x480@60Hz 640x480@72Hz 640x480@75Hz 800x600@56Hz 800x600@60Hz 800x600@72Hz 800x600@75Hz 1024x768@60Hz 1024x768@70Hz 1024x768@75Hz 1280x1024@75Hz Manufacturer's mask: 0 Supported standard timings: Supported detailed timing: clock: 25.2 MHz Image Size: 337 x 270 mm h_active: 640 h_sync: 688 h_sync_end 784 h_blank_end 800 h_border: 0 v_active: 350 v_sync: 350 v_sync_end 352 v_blanking: 449 v_border: 0 Monitor name: MD30217PG Ranges: V min: 56 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 145 MHz Serial No: 501099188 EDID (in hex): 00ffffffffffff0034a4b80774830100 050f010368221b962a0c55a559479b24 125054afcf00310a0101010101018180 000000000000d60980a0205e63103060 0200510e1100001e000000fc004d4433 3032313750470a202020000000fd0038 4c1e530e000a202020202020000000ff 003530313039393138380a2020200078 Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Reported-by: friedrich@mailstation.de Signed-off-by:
-
Borislav Petkov authored
commit f0a56c48 upstream. It can happen that configurations are running in a single-channel mode even with a dual-channel memory controller, by, say, putting the DIMMs only on the one channel and leaving the other empty. This causes a problem in init_csrows which implicitly assumes that when the second channel is enabled, i.e. channel 1, the struct dimm hierarchy will be present. Which is not. So always allocate two channels unconditionally. This provides for the nice side effect that the data structures are initialized so some day, when memory hotplug is supported, it should just work out of the box when all of a sudden a second channel appears. Reported-and-tested-by:
Roger Leigh <rleigh@debian.org> Signed-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
-
Jan Kara authored
commit 17b7f7cf upstream. Refuse RW mount of isofs filesystem. So far we just silently changed it to RO mount but when the media is writeable, block layer won't notice this change and thus will think device is used RW and will block eject button of the drive. That is unexpected by users because for non-writeable media eject button works just fine. Userspace mount(8) command handles this just fine and retries mounting with MS_RDONLY set so userspace shouldn't see any regression. Plus any tool mounting isofs is likely confronted with the case of read-only media where block layer already refuses to mount the filesystem without MS_RDONLY set so our behavior shouldn't be anything new for it. Reported-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Eric W. Biederman authored
commit aee1c13d upstream. Don't allow mounting the proc filesystem unless the caller has CAP_SYS_ADMIN rights over the pid namespace. The principle here is if you create or have capabilities over it you can mount it, otherwise you get to live with what other people have mounted. Andy pointed out that this is needed to prevent users in a user namespace from remounting proc and specifying different hidepid and gid options on already existing proc mounts. Reported-by:
Andy Lutomirski <luto@amacapital.net> Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Libin authored
commit a8f531eb upstream. In collapse_huge_page() there is a race window between releasing the mmap_sem read lock and taking the mmap_sem write lock, so find_vma() may return NULL. So check the return value to avoid NULL pointer dereference. collapse_huge_page khugepaged_alloc_page up_read(&mm->mmap_sem) down_write(&mm->mmap_sem) vma = find_vma(mm, address) Signed-off-by:
Libin <huawei.libin@huawei.com> Acked-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by:
Wanpeng Li <liwanp@linux.vnet.ibm.com> Reviewed-by:
Michal Hocko <mhocko@suse.cz> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Greg Thelen authored
commit 2bff24a3 upstream. A memory cgroup with (1) multiple threshold notifications and (2) at least one threshold >=2G was not reliable. Specifically the notifications would either not fire or would not fire in the proper order. The __mem_cgroup_threshold() signaling logic depends on keeping 64 bit thresholds in sorted order. mem_cgroup_usage_register_event() sorts them with compare_thresholds(), which returns the difference of two 64 bit thresholds as an int. If the difference is positive but has bit[31] set, then sort() treats the difference as negative and breaks sort order. This fix compares the two arbitrary 64 bit thresholds returning the classic -1, 0, 1 result. The test below sets two notifications (at 0x1000 and 0x81001000): cd /sys/fs/cgroup/memory mkdir x for x in 4096 2164264960; do cgroup_event_listener x/memory.usage_in_bytes $x | sed "s/^/$x listener:/" & done echo $$ > x/cgroup.procs anon_leaker 500M v3.11-rc7 fails to signal the 4096 event listener: Leaking... Done leaking pages. Patched v3.11-rc7 properly notifies: Leaking... 4096 listener:2013:8:31:14:13:36 Done leaking pages. The fixed bug is old. It appears to date back to the introduction of memcg threshold notifications in v2.6.34-rc1-116-g2e72b634 "memcg: implement memory thresholds" Signed-off-by:
Greg Thelen <gthelen@google.com> Acked-by:
Johannes Weiner <hannes@cmpxchg.org> Signed-off-by:
-
Jie Liu authored
commit 28e8be31 upstream. Call fiemap ioctl(2) with given start offset as well as an desired mapping range should show extents if possible. However, we somehow figure out the end offset of mapping via 'mapping_end -= cpos' before iterating the extent records which would cause problems if the given fiemap length is too small to a cluster size, e.g, Cluster size 4096: debugfs.ocfs2 1.6.3 Block Size Bits: 12 Cluster Size Bits: 12 The extended fiemap test utility From David: https://gist.github.com/anonymous/6172331 # dd if=/dev/urandom of=/ocfs2/test_file bs=1M count=1000 # ./fiemap /ocfs2/test_file 4096 10 start: 4096, length: 10 File /ocfs2/test_file has 0 extents: # Logical Physical Length Flags ^^^^^ <-- No extent is shown In this case, at ocfs2_fiemap(): cpos == mapping_end == 1. Hence the loop of searching extent records was not executed at all. This patch remove the in question 'mapping_end -= cpos', and loops until the cpos is larger than the mapping_end as usual. # ./fiemap /ocfs2/test_file 4096 10 start: 4096, length: 10 File /ocfs2/test_file has 1 extents: # Logical Physical Length Flags 0: 0000000000000000 0000000056a01000 0000000006a00000 0000 Signed-off-by:
Jie Liu <jeff.liu@oracle.com> Reported-by:
David Weber <wb@munzinger.de> Tested-by:
-
Oleg Nesterov authored
commit e79f525e upstream. Commit 8382fcac ("pidns: Outlaw thread creation after unshare(CLONE_NEWPID)") nacks CLONE_VM if the forking process unshared pid_ns, this obviously breaks vfork: int main(void) { assert(unshare(CLONE_NEWUSER | CLONE_NEWPID) == 0); assert(vfork() >= 0); _exit(0); return 0; } fails without this patch. Change this check to use CLONE_SIGHAND instead. This also forbids CLONE_THREAD automatically, and this is what the comment implies. We could probably even drop CLONE_SIGHAND and use CLONE_THREAD, but it would be safer to not do this. The current check denies CLONE_SIGHAND implicitely and there is no reason to change this. Eric said "CLONE_SIGHAND is fine. CLONE_THREAD would be even better. Having shared signal handling between two different pid namespaces is the case that we are fundamentally guarding against." Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Reported-by:
Colin Walters <walters@redhat.com> Acked-by:
-
Eric W. Biederman authored
commit a6064885 upstream. Serge Hallyn <serge.hallyn@ubuntu.com> writes: > Since commit af4b8a83 it's been > possible to get into a situation where a pidns reaper is > <defunct>, reparented to host pid 1, but never reaped. How to > reproduce this is documented at > > https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1168526 > (and see > https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1168526/comments/13) > In short, run repeated starts of a container whose init is > > Process.exit(0); > > sysrq-t when such a task is playing zombie shows: > > [ 131.132978] init x ffff88011fc14580 0 2084 2039 0x00000000 > [ 131.132978] ffff880116e89ea8 0000000000000002 ffff880116e89fd8 0000000000014580 > [ 131.132978] ffff880116e89fd8 0000000000014580 ffff8801172a0000 ffff8801172a0000 > [ 131.132978] ffff8801172a0630 ffff88011729fff0 ffff880116e14650 ffff88011729fff0 > [ 131.132978] Call Trace: > [ 131.132978] [<ffffffff816f6159>] schedule+0x29/0x70 > [ 131.132978] [<ffffffff81064591>] do_exit+0x6e1/0xa40 > [ 131.132978] [<ffffffff81071eae>] ? signal_wake_up_state+0x1e/0x30 > [ 131.132978] [<ffffffff8106496f>] do_group_exit+0x3f/0xa0 > [ 131.132978] [<ffffffff810649e4>] SyS_exit_group+0x14/0x20 > [ 131.132978] [<ffffffff8170102f>] tracesys+0xe1/0xe6 > > Further debugging showed that every time this happened, zap_pid_ns_processes() > started with nr_hashed being 3, while we were expecting it to drop to 2. > Any time it didn't happen, nr_hashed was 1 or 2. So the reaper was > waiting for nr_hashed to become 2, but free_pid() only wakes the reaper > if nr_hashed hits 1. The issue is that when the task group leader of an init process exits before other tasks of the init process when the init process finally exits it will be a secondary task sleeping in zap_pid_ns_processes and waiting to wake up when the number of hashed pids drops to two. This case waits forever as free_pid only sends a wake up when the number of hashed pids drops to 1. To correct this the simple strategy of sending a possibly unncessary wake up when the number of hashed pids drops to 2 is adopted. Sending one extraneous wake up is relatively harmless, at worst we waste a little cpu time in the rare case when a pid namespace appropaches exiting. We can detect the case when the pid namespace drops to just two pids hashed race free in free_pid. Dereferencing pid_ns->child_reaper with the pidmap_lock held is safe without out the tasklist_lock because it is guaranteed that the detach_pid will be called on the child_reaper before it is freed and detach_pid calls __change_pid which calls free_pid which takes the pidmap_lock. __change_pid only calls free_pid if this is the last use of the pid. For a thread that is not the thread group leader the threads pid will only ever have one user because a threads pid is not allowed to be the pid of a process, of a process group or a session. For a thread that is a thread group leader all of the other threads of that process will be reaped before it is allowed for the thread group leader to be reaped ensuring there will only be one user of the threads pid as a process pid. Furthermore because the thread is the init process of a pid namespace all of the other processes in the pid namespace will have also been already freed leading to the fact that the pid will not be used as a session pid or a process group pid for any other running process. Acked-by:
Serge Hallyn <serge.hallyn@canonical.com> Tested-by:
Serge Hallyn <serge.hallyn@ubuntu.com> Signed-off-by:
-
Alex Williamson authored
commit 3269ee0b upstream. At best the current code only seems to free the leaf pagetables and the root. If you're unlucky enough to have a large gap (like any QEMU guest with more than 3G of memory), only the first chunk of leaf pagetables are freed (plus the root). This is a massive memory leak. This patch re-writes the pagetable freeing function to use a recursive algorithm and manages to not only free all the pagetables, but does it without any apparent performance loss versus the current broken version. Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Reviewed-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
Joerg Roedel <joro@8bytes.org> Signed-off-by:
-
Gera Kazakov authored
commit f730f915 upstream. This patch fixes a >= v3.9+ regression in __core_scsi3_write_aptpl_to_file() + core_alua_write_tpg_metadata() write-out, where a return value of -EIO was incorrectly being returned upon success. This bug was originally introduced in: commit 0e9b10a9 Author: Al Viro <viro@zeniv.linux.org.uk> Date: Sat Feb 23 15:22:43 2013 -0500 target: writev() on single-element vector is pointless However, given that the return of core_scsi3_update_and_write_aptpl() was not used to determine if a command should be returned with non GOOD status, this bug was not being triggered in PR logic until v3.11-rc1 by commit: commit 459f213b Author: Andy Grover <agrover@redhat.com> Date: Thu May 16 10:41:02 2013 -0700 target: Allocate aptpl_buf inside update_and_write_aptpl() So, go ahead and only return -EIO if kernel_write() returned a negative value. Reported-by:
Gera Kazakov <gkazakov@msn.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Felix Fietkau authored
commit a1191927 upstream. The watchdog device on the AR933x is connected to the AHB clock, however the current code uses the reference clock. Due to the wrong rate, the watchdog driver can't calculate correct register values for a given timeout value and the watchdog unexpectedly restarts the system. The code uses the wrong value since the initial commit 04225e1d (MIPS: ath79: add AR933X specific clock init) The patch fixes the code to use the correct clock rate to avoid the problem. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
Gabor Juhos <juhosg@openwrt.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/5777/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Mark Brown authored
commit 61abeba5 upstream. The wm831x-status driver was not converted to use a REG resource when they were introduced and the rest of the wm831x drivers converted, causing it to fail to probe due to requesting the wrong resource type. Signed-off-by:
Bryan Wu <cooloney@gmail.com> Signed-off-by:
-
Oleg Nesterov authored
commit 878b5a6e upstream. Currently utask->depth is simply the number of allocated/pending return_instance's in uprobe_task->return_instances list. handle_trampoline() should decrement this counter every time we handle/free an instance, but due to typo it does this only if ->chained == T. This means that in the likely case this counter is never decremented and the probed task can't report more than MAX_URETPROBE_DEPTH events. Reported-by:
Mikhail Kulemin <Mikhail.Kulemin@ru.ibm.com> Reported-by:
Hemant Kumar Shaw <hkshaw@linux.vnet.ibm.com> Signed-off-by:
Anton Arapov <anton@redhat.com> Cc: masami.hiramatsu.pt@hitachi.com Cc: srikar@linux.vnet.ibm.com Cc: systemtap@sourceware.org Link: http://lkml.kernel.org/r/20130911154726.GA8093@redhat.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Stefan Behrens authored
commit bbb651e4 upstream. If you start the replace procedure on a read only filesystem, at the end the procedure fails to write the updated dev_items to the chunk tree. The problem is that this error is not indicated except for a WARN_ON(). If the user now thinks that everything was done as expected and destroys the source device (with mkfs or with a hammer). The next mount fails with "failed to read chunk root" and the filesystem is gone. This commit adds code to fail the attempt to start the replace procedure if the filesystem is mounted read-only. Signed-off-by:
Stefan Behrens <sbehrens@giantdisaster.de> Signed-off-by:
Josef Bacik <jbacik@fusionio.com> Signed-off-by:
Chris Mason <chris.mason@fusionio.com> Signed-off-by:
-
Bjørn Mork authored
commit ec532503 upstream. GIT_AUTHOR_DATE=1376465691 I took a quick look at the code and wonder if the problem is caused by an initial zero statistics message? This is all just a wild guess, but if it is correct, then the attached untested patch might fix it... Bjørn >From d78a0599d5b5d4da384eae08bf7da316389dfbe5 Mon Sep 17 00:00:00 2001 ts_packets and ets_packets counters can be 0. Don't fall over if they are. Fixes: [ 846.851711] divide error: 0000 [#1] SMP [ 846.851806] Modules linked in: smsdvb dvb_core ir_lirc_codec lirc_dev ir_sanyo_decoder ir_mce_kbd_decoder ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder rc_hauppauge smsusb smsmdtv rc_core pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) parport_pc ppdev lp parport cpufreq_userspace cpufreq_powersave cpufreq_stats cpufreq_conservative rfcomm bnep binfmt_misc uinput nfsd auth_rpcgss oid_registry nfs_acl nfs lockd dns_resolver fscache sunrpc ext4 jbd2 fuse tp_smapi(O) thinkpad_ec(O) loop firewire_sbp2 dm_crypt snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm thinkpad_acpi nvram snd_page_alloc hid_generic snd_seq_midi snd_seq_midi_event arc4 usbhid snd_rawmidi uvcvideo hid iwldvm coretemp kvm_intel mac8021 1 cdc_wdm [ 846.853477] cdc_acm snd_seq videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media kvm radeon r852 ttm joydev cdc_ether usbnet pcmcia mii sm_common nand btusb drm_kms_helper tpm_tis acpi_cpufreq bluetooth iwlwifi nand_ecc drm nand_ids i2c_i801 mtd snd_seq_device iTCO_wdt iTCO_vendor_support r592 memstick lpc_ich mperf tpm yenta_socket pcmcia_rsrc pcmcia_core cfg80211 snd_timer snd pcspkr i2c_algo_bit crc16 i2c_core tpm_bios processor mfd_core wmi psmouse mei_me rfkill mei serio_raw soundcore evdev battery button video ac microcode ext3 mbcache jbd md_mod dm_mirror dm_region_hash dm_log dm_mod sg sr_mod sd_mod cdrom crc_t10dif firewire_ohci sdhci_pci sdhci mmc_core firewire_core crc_itu_t thermal thermal_sys ahci libahci ehci_pci uhci_hcd ehci_hcd libata scsi_mod usbcore e1000 e usb_common [ 846.855310] ptp pps_core [ 846.855356] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 3.10-2-amd64 #1 Debian 3.10.5-1 [ 846.855490] Hardware name: LENOVO 4061WFA/4061WFA, BIOS 6FET92WW (3.22 ) 12/14/2011 [ 846.855609] task: ffffffff81613400 ti: ffffffff81600000 task.ti: ffffffff81600000 [ 846.855636] RIP: 0010:[<ffffffffa092be0c>] [<ffffffffa092be0c>] smsdvb_onresponse+0x264/0xa86 [smsdvb] [ 846.863906] RSP: 0018:ffff88013bc03cf0 EFLAGS: 00010046 [ 846.863906] RAX: 0000000000000000 RBX: ffff880133bf6000 RCX: 0000000000000000 [ 846.863906] RDX: 0000000000000000 RSI: ffff88005d3b58c0 RDI: ffff880133bf6000 [ 846.863906] RBP: ffff88005d1da000 R08: 0000000000000058 R09: 0000000000000015 [ 846.863906] R10: 0000000000001a0d R11: 000000000000021a R12: ffff88005d3b58c0 [ 846.863906] R13: ffff88005d1da008 R14: 00000000ffffff8d R15: ffff880036cf5060 [ 846.863906] FS: 0000000000000000(0000) GS:ffff88013bc00000(0000) knlGS:0000000000000000 [ 846.863906] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 846.863906] CR2: 00007f3a4b69ae50 CR3: 0000000036dac000 CR4: 00000000000407f0 [ 846.863906] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 846.863906] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 846.863906] Stack: [ 846.863906] ffff88007a102000 ffff88005d1da000 ffff88005d3b58c0 0000000000085824 [ 846.863906] ffffffffa08c5aa3 ffff88005d1da000 ffff8800a6907390 ffff8800a69073b0 [ 846.863906] ffff8800a6907000 ffffffffa08b642c 000000000000021a ffff8800a69073b0 [ 846.863906] Call Trace: [ 846.863906] <IRQ> [ 846.863906] [ 846.863906] [<ffffffffa08c5aa3>] ? smscore_onresponse+0x1d5/0x353 [smsmdtv] [ 846.863906] [<ffffffffa08b642c>] ? smsusb_onresponse+0x146/0x192 [smsusb] [ 846.863906] [<ffffffffa004cb1a>] ? usb_hcd_giveback_urb+0x6c/0xac [usbcore] [ 846.863906] [<ffffffffa0217be1>] ? ehci_urb_done+0x62/0x72 [ehci_hcd] [ 846.863906] [<ffffffffa0217c82>] ? qh_completions+0x91/0x364 [ehci_hcd] [ 846.863906] [<ffffffffa0219bba>] ? ehci_work+0x8a/0x68e [ehci_hcd] [ 846.863906] [<ffffffff8107336c>] ? timekeeping_get_ns.constprop.10+0xd/0x31 [ 846.863906] [<ffffffff81064d41>] ? update_cfs_rq_blocked_load+0xde/0xec [ 846.863906] [<ffffffff81058ec2>] ? run_posix_cpu_timers+0x25/0x575 [ 846.863906] [<ffffffffa021aa46>] ? ehci_irq+0x211/0x23d [ehci_hcd] [ 846.863906] [<ffffffffa004c0c1>] ? usb_hcd_irq+0x31/0x48 [usbcore] [ 846.863906] [<ffffffff810996fd>] ? handle_irq_event_percpu+0x49/0x1a4 [ 846.863906] [<ffffffff8109988a>] ? handle_irq_event+0x32/0x4b [ 846.863906] [<ffffffff8109bd76>] ? handle_fasteoi_irq+0x80/0xb6 [ 846.863906] [<ffffffff8100e93e>] ? handle_irq+0x18/0x20 [ 846.863906] [<ffffffff8100e657>] ? do_IRQ+0x40/0x95 [ 846.863906] [<ffffffff813883ed>] ? common_interrupt+0x6d/0x6d [ 846.863906] <EOI> [ 846.863906] [ 846.863906] [<ffffffff812a011c>] ? arch_local_irq_enable+0x4/0x8 [ 846.863906] [<ffffffff812a04f3>] ? cpuidle_enter_state+0x52/0xc1 [ 846.863906] [<ffffffff812a0636>] ? cpuidle_idle_call+0xd4/0x143 [ 846.863906] [<ffffffff8101398c>] ? arch_cpu_idle+0x5/0x17 [ 846.863906] [<ffffffff81072571>] ? cpu_startup_entry+0x10d/0x187 [ 846.863906] [<ffffffff816b3d3d>] ? start_kernel+0x3e8/0x3f3 [ 846.863906] [<ffffffff816b3777>] ? repair_env_string+0x54/0x54 [ 846.863906] [<ffffffff816b3598>] ? x86_64_start_kernel+0xf2/0xfd [ 846.863906] Code: 25 09 00 00 c6 83 da 08 00 00 03 8b 45 54 48 01 83 b6 08 00 00 8b 45 50 48 01 83 db 08 00 00 8b 4d 18 69 c1 ff ff 00 00 03 4d 14 <48> f7 f1 89 83 a8 09 00 00 e9 68 fe ff ff 48 8b 7f 10 e8 79 92 [ 846.863906] RIP [<ffffffffa092be0c>] smsdvb_onresponse+0x264/0xa86 [smsdvb] [ 846.863906] RSP <ffff88013bc03cf0> Reference: http://bugs.debian.org/719623Reported-by:
Johannes Rohr <jorohr@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
Mauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit 9d32069f upstream. changeset 768e6dad caused a regression on using mb86a20s in parallel mode, as the parallel mode selection got overriden by mb86a20s_init2. Signed-off-by:
-
Alexander Shiyan authored
commit 7b0dd9e6 upstream. The data pointer should point to DT data, and not to the ID array. Signed-off-by:
Kamil Debski <k.debski@samsung.com> Signed-off-by:
-
Andrzej Hajda authored
commit a19dec6e upstream. This patch fixes following error: include/media/v4l2-ctrls.h:193:15: error: field ‘_lock’ has incomplete type include/media/v4l2-ctrls.h: In function ‘v4l2_ctrl_lock’: include/media/v4l2-ctrls.h:570:2: error: implicit declaration of function ‘mutex_lock’ [-Werror=implicit-function-declaration] include/media/v4l2-ctrls.h: In function ‘v4l2_ctrl_unlock’: include/media/v4l2-ctrls.h:579:2: error: implicit declaration of function ‘mutex_unlock’ [-Werror=implicit-function-declaration] Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Alexey Khoroshilov authored
commit 2e923a05 upstream. free_buff_list and rec_buff_list are initialized in the middle of hdpvr_probe(), but if something bad happens before that, error handling code calls hdpvr_delete(), which contains iteration over the lists (via hdpvr_free_buffers()). The patch moves the lists initialization to the beginning and by the way fixes goto label in error handling of registering videodev. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
-
Andrzej Hajda authored
commit 8bfd4a68 upstream. Fixes the last three errors of media_api DocBook validatation: (...) media_api.xml:414: element imagedata: validity error : Value "SVG" for attribute format of imagedata is not among the enumerated set media_api.xml:432: element imagedata: validity error : Value "SVG" for attribute format of imagedata is not among the enumerated set media_api.xml:452: element imagedata: validity error : Value "SVG" for attribute format of imagedata is not among the enumerated set (...) Signed-off-by:
-
Sachin Kamat authored
commit 8a09a4cc upstream. Commit 1c1d86a1 ("[media] v4l2: always require v4l2_dev, rename parent to dev_parent") expects v4l2_dev to be always set. It converted most of the drivers using the parent field of video_device to v4l2_dev field. G2D driver did not set the parent field. Hence it got left out. Without this patch we get the following boot warning and G2D driver fails to register the video device. WARNING: CPU: 0 PID: 1 at drivers/media/v4l2-core/v4l2-dev.c:775 __video_register_device+0xfc0/0x1028() Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc1-00001-g1c3e372-dirty #9 [<c0014b7c>] (unwind_backtrace+0x0/0xf4) from [<c0011524>] (show_stack+0x10/0x14) [<c0011524>] (show_stack+0x10/0x14) from [<c041d7a8>] (dump_stack+0x7c/0xb0) [<c041d7a8>] (dump_stack+0x7c/0xb0) from [<c001dc94>] (warn_slowpath_common+0x6c/0x88) [<c001dc94>] (warn_slowpath_common+0x6c/0x88) from [<c001dd4c>] (warn_slowpath_null+0x1c/0x24) [<c001dd4c>] (warn_slowpath_null+0x1c/0x24) from [<c02cf8d4>] (__video_register_device+0xfc0/0x1028) [<c02cf8d4>] (__video_register_device+0xfc0/0x1028) from [<c0311a94>] (g2d_probe+0x1f8/0x398) [<c0311a94>] (g2d_probe+0x1f8/0x398) from [<c0247d54>] (platform_drv_probe+0x14/0x18) [<c0247d54>] (platform_drv_probe+0x14/0x18) from [<c0246b10>] (driver_probe_device+0x108/0x220) [<c0246b10>] (driver_probe_device+0x108/0x220) from [<c0246cf8>] (__driver_attach+0x8c/0x90) [<c0246cf8>] (__driver_attach+0x8c/0x90) from [<c0245050>] (bus_for_each_dev+0x60/0x94) [<c0245050>] (bus_for_each_dev+0x60/0x94) from [<c02462c8>] (bus_add_driver+0x1c0/0x24c) [<c02462c8>] (bus_add_driver+0x1c0/0x24c) from [<c02472d0>] (driver_register+0x78/0x140) [<c02472d0>] (driver_register+0x78/0x140) from [<c00087c8>] (do_one_initcall+0xf8/0x144) [<c00087c8>] (do_one_initcall+0xf8/0x144) from [<c05b29e8>] (kernel_init_freeable+0x13c/0x1d8) [<c05b29e8>] (kernel_init_freeable+0x13c/0x1d8) from [<c041a108>] (kernel_init+0xc/0x160) [<c041a108>] (kernel_init+0xc/0x160) from [<c000e2f8>] (ret_from_fork+0x14/0x3c) ---[ end trace 4e0ec028b0028e02 ]--- s5p-g2d 12800000.g2d: Failed to register video device s5p-g2d: probe of 12800000.g2d failed with error -22 Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Cc: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Sylwester Nawrocki authored
commit d2b903b4 upstream. This patch corrects media entities unregistration order to make sure the fimc.N.capture and fimc-lite video nodes are unregistered with fimc->lock mutex held. This prevents races between video device open() and defered probing and NULL pointer dereference in open() callback as follows: [ 77.645000] Unable to handle kernel NULL pointer dereference at virtual address 00000290t [ 77.655000] pgd = ee7a8000 [ 77.660000] [00000290] *pgd=6e13c831, *pte=00000000, *ppte=00000000 [ 77.665000] Internal error: Oops: 17 [#1] PREEMPT SMP ARM [ 77.670000] Modules linked in: s5p_fimc ipv6 exynos_fimc_is exynos_fimc_lite s5p_csis v4l2_mem2mem videobuf2_dma_contig videobuf2_memops exynos4_is_common videobuf2_core [last unloaded: s5p_fimc] [ 77.685000] CPU: 0 PID : 2998 Comm: v4l_id Tainted: G W 3.10.0-next-20130709-00039-g39f491b-dirty #1548 [ 77.695000] task: ee084000 ti: ee46e000 task.ti: ee46e000 [ 77.700000] PC is at __mutex_lock_slowpath+0x54/0x368 [ 77.705000] LR is at __mutex_lock_slowpath+0x24/0x368 [ 77.710000] pc : [<c038dc10>] lr : [<c038dbe0>] psr: 60000093 [ 77.710000] sp : ee46fd70 ip : 000008c8 fp : c054e34c [ 77.725000] r10: ee084000 r9 : 00000000 r8 : ee439480 [ 77.730000] r7 : ee46e000 r6 : 60000013 r5 : 00000290 r4 : 0000028c [ 77.735000] r3 : 00000000 r2 : 00000000 r1 : 20000093 r0 : 00000001 [ 77.740000] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [ 77.750000] Control: 10c5387d Table: 6e7a804a DAC: 00000015 [ 77.755000] Process v4l_id (pid: 2998, stack limit = 0xee46e238) [ 77.760000] Stack: (0xee46fd70 to 0xee470000) ... [ 77.935000] [<c038dc10>] (__mutex_lock_slowpath+0x54/0x368) from [<c038df30>] (mutex_lock+0xc/0x24) [ 77.945000] [<c038df30>] (mutex_lock+0xc/0x24) from [<bf03fa90>] (fimc_lite_open+0x12c/0x2bc [exynos_fimc_lite]) [ 77.955000] [<bf03fa90>] (fimc_lite_open+0x12c/0x2bc [exynos_fimc_lite]) from [<c02ab11c>] (v4l2_open+0xa0/0xe0) [ 77.965000] [<c02ab11c>] (v4l2_open+0xa0/0xe0) from [<c00b1de4>] (chrdev_open+0x88/0x170) [ 77.975000] [<c00b1de4>] (chrdev_open+0x88/0x170) from [<c00ac710>] (do_dentry_open.isra.14+0x1d8/0x258) [ 77.985000] [<c00ac710>] (do_dentry_open.isra.14+0x1d8/0x258) from [<c00ac860>] (finish_open+0x20/0x38) [ 77.995000] [<c00ac860>] (finish_open+0x20/0x38) from [<c00ba658>] (do_last.isra.43+0x538/0xb1c) [ 78.000000] [<c00ba658>] (do_last.isra.43+0x538/0xb1c) from [<c00bacf0>] (path_openat+0xb4/0x5c4) [ 78.010000] [<c00bacf0>] (path_openat+0xb4/0x5c4) from [<c00bb4b4>] (do_filp_open+0x2c/0x80) [ 78.020000] [<c00bb4b4>] (do_filp_open+0x2c/0x80) from [<c00ad744>] (do_sys_open+0xf4/0x1a8) [ 78.025000] [<c00ad744>] (do_sys_open+0xf4/0x1a8) from [<c000e320>] (ret_fast_syscall+0x0/0x30) [ 78.035000] Code: 1a000093 e10f6000 f10c0080 e2845004 (e1953f9f) Reported-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Arun Kumar K authored
commit d0b1c313 upstream. Gscaler video device registration was happening without reference to a parent v4l2_dev causing probe to fail. The patch creates a parent v4l2 device and uses it for the gsc m2m video device registration. This fixes regression introduced with comit commit 1c1d86a1 [media] v4l2: always require v4l2_dev, rename parent to dev_parent Signed-off-by:
Arun Kumar K <arun.kk@samsung.com> Signed-off-by:
-
Vasily Titskiy authored
commit 9e0bf92c upstream. The DuoSense touchscreen device causes a 10 second timeout. This fix removes the delay. Signed-off-by:
Vasily Titskiy <qehgt0@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Kees Cook authored
commit be67b68d upstream. Defensively check that the field to be worked on is not NULL. Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Manoj Chourasia authored
commit 212a871a upstream. This changes puts the commit 4fe9f8e2 back in place with the fixes for slab corruption because of the commit. When a device is unplugged, wait for all processes that have opened the device to close before deallocating the device. This commit was solving kernel crash because of the corruption in rb tree of vmalloc. The rootcause was the device data pointer was geting excessed after the memory associated with hidraw was freed. The commit 4fe9f8e2 was buggy as it was also freeing the hidraw first and then calling delete operation on the list associated with that hidraw leading to slab corruption. Signed-off-by:
Manoj Chourasia <mchourasia@nvidia.com> Tested-by:
Peter Wu <lekensteyn@gmail.com> Signed-off-by:
-
