- 12 Jan, 2012 28 commits
-
-
Alan Stern authored
commit d8cae98c upstream. The documentation for usbmon is out of date; the usbfs "devices" file now exists in /sys/kernel/debug/usb rather than /proc/bus/usb. This patch (as1505) updates the documentation accordingly, and also mentions that the necessary information can be found by running lsusb. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> CC: Pete Zaitcev <zaitcev@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
K. Y. Srinivasan authored
commit 8f257a14 upstream. The function vmbus_exists() was introduced recently to deal with cases where the vmbus driver failed to initialize and yet other Hyper-V drivers attempted to register with the vmbus bus driver. This patch introduced a bug where vmbus_driver_unregister() would fail to unregister the driver. This patch fixes the problem. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Fuzhou Chen <fuzhouch@microsoft.com> Cc: Sasha Levin <levinsasha928@gmail.com> Signed-off-by:
-
K. Y. Srinivasan authored
commit cf6a2eac upstream. The hv vmbus driver was causing an OOPS since it was trying to register drivers on top of the bus even if initialization of the bus has failed for some reason (such as the odd chance someone would run a hv enabled kernel in a non-hv environment). Signed-off-by:
Sasha Levin <levinsasha928@gmail.com> Signed-off-by:
-
Jan Kara authored
commit 33c104d4 upstream. WARN_ON_ONCE(IS_RDONLY(inode)) tends to trip when filesystem hits error and is remounted read-only. This unnecessarily scares users (well, they should be scared because of filesystem error, but the stack trace distracts them from the right source of their fear ;-). We could as well just remove the WARN_ON but it's not hard to fix it to not trip on filesystem with errors and not use more cycles in the common case so that's what we do. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Jeff Mahoney authored
commit a9e36da6 upstream. This patch fixes a crash in reiserfs_delete_xattrs during umount. When shrink_dcache_for_umount clears the dcache from generic_shutdown_super, delayed evictions are forced to disk. If an evicted inode has extended attributes associated with it, it will need to walk the xattr tree to locate and remove them. But since shrink_dcache_for_umount will BUG if it encounters active dentries, the xattr tree must be released before it's called or it will crash during every umount. This patch forces the evictions to occur before generic_shutdown_super by calling shrink_dcache_sb first. The additional evictions caused by the removal of each associated xattr file and dir will be automatically handled as they're added to the LRU list. CC: reiserfs-devel@vger.kernel.org Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
-
Jan Kara authored
commit a06d789b upstream. When jqfmt mount option is not specified on remount, we mistakenly clear s_jquota_fmt value stored in superblock. Fix the problem. CC: reiserfs-devel@vger.kernel.org Signed-off-by:
-
Boaz Harrosh authored
commit 831c2dc5 upstream. As Reported by Randy Dunlap When MISC_FILESYSTEMS is not enabled and NFS4.1 is: fs/built-in.o: In function `objio_alloc_io_state': objio_osd.c:(.text+0xcb525): undefined reference to `ore_get_rw_state' fs/built-in.o: In function `_write_done': objio_osd.c:(.text+0xcb58d): undefined reference to `ore_check_io' fs/built-in.o: In function `_read_done': ... When MISC_FILESYSTEMS, which is more of a GUI thing then anything else, is not selected. exofs/Kconfig is never examined during Kconfig, and it can not do it's magic stuff to automatically select everything needed. We must split exofs/Kconfig in two. The ore one is always included. And the exofs one is left in it's old place in the menu. Reported-by:
Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
Boaz Harrosh <bharrosh@panasas.com> Signed-off-by:
-
Boaz Harrosh authored
commit 724577ca upstream. NFS might send us offsets that are not PAGE aligned. So we must read in the reminder of the first/last pages, in cases we need it for Parity calculations. We only add an sg segments to read the partial page. But we don't mark it as read=true because it is a lock-for-write page. TODO: In some cases (IO spans a single unit) we can just adjust the raid_unit offset/length, but this is left for later Kernels. Signed-off-by:
-
Boaz Harrosh authored
commit 361aba56 upstream. When reading RAID5 files, in rare cases, we calculated too few sg segments. There should be two extra for the beginning and end partial units. Also "too few sg segments" should not be a BUG_ON there is all the mechanics in place to handle it, as a short read. So just return -ENOMEM and the rest of the code will gracefully split the IO. Signed-off-by:
-
Boaz Harrosh authored
commit ffefb8ea upstream. The users of ore_check_io() expect the reported device (In case of error) to be indexed relative to the passed-in ore_components table, and not the logical dev index. This causes a crash inside objlayoutdriver in case of an IO error. Signed-off-by:
-
Steven Rostedt authored
commit 49908a1b upstream. A update is made to the sched:sched_switch event that adds some logic to the first parameter of the __print_flags() that shows the state of tasks. This change cause perf to fail parsing the flags. A simple fix is needed to have the parser be able to process ops within the argument. Reported-by:
Andrew Vagin <avagin@openvz.org> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Johannes Berg authored
commit 10667136 upstream. The ICT code erroneously uses PAGE_SIZE. The bug is that PAGE_SIZE isn't necessarily 4096, so on such platforms this code will not work correctly as we'll try to attempt to read an index in the table that the device never wrote, it always has 4096-byte pages. Additionally, the manual alignment code here is unnecessary -- Documentation/DMA-API-HOWTO.txt states: The cpu return address and the DMA bus master address are both guaranteed to be aligned to the smallest PAGE_SIZE order which is greater than or equal to the requested size. This invariant exists (for example) to guarantee that if you allocate a chunk which is smaller than or equal to 64 kilobytes, the extent of the buffer you receive will not cross a 64K boundary. Just use appropriate new constants and get rid of the alignment code. Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Johannes Berg authored
commit 9a215e40 upstream. The driver everywhere uses max TID count as 9, which is wrong, it should be 8. I think the reason it uses 9 here is off-by-one confusion by whoever wrote this. We do use the value IWL_MAX_TID_COUNT for "not QoS/no TID" but that is completely correct even if it is 8 and not 9 since 0-7 are only valid. As a side effect, this fixes the following bug: Open BA session requested for 00:23:cd:16:8a:7e tid 8 ------------[ cut here ]------------ kernel BUG at drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h:350! ... when you do echo "tx start 8" > /sys/kernel/debug/ieee80211/*/*/*/*/agg_status Reported-by:
Nikolay Martynov <mar.kolya@gmail.com> Signed-off-by:
-
Eli Cohen authored
commit e214a0fe upstream. Userspace verbs multicast attach/detach operations on a QP are done while holding the rwsem of the QP for reading. That's not sufficient since a reader lock allows more than one reader to acquire the lock. However, multicast attach/detach does list manipulation that can corrupt the list if multiple threads run in parallel. Fix this by acquiring the rwsem as a writer to serialize attach/detach operations. Add idr_write_qp() and put_qp_write() to encapsulate this. This fixes oops seen when running applications that perform multicast joins/leaves. Reported by: Mike Dubman <miked@mellanox.com> Signed-off-by:
Eli Cohen <eli@mellanox.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Ram Vepa authored
commit eddfb675 upstream. Prevent a receive data corruption by ensuring that the write to update the rcvhdrheadn register to generate an interrupt is at the very end of the receive processing. Signed-off-by:
Ramkrishna Vepa <ram.vepa@qlogic.com> Signed-off-by:
Mike Marciniszyn <mike.marciniszyn@qlogic.com> Signed-off-by:
-
Li Zhong authored
commit e4f387d8 upstream. Unpaired calling of probe_hcall_entry and probe_hcall_exit might happen as following, which could cause incorrect preempt count. __trace_hcall_entry => trace_hcall_entry -> probe_hcall_entry => get_cpu_var => preempt_disable __trace_hcall_exit => trace_hcall_exit -> probe_hcall_exit => put_cpu_var => preempt_enable where: A => B and A -> B means A calls B, but => means A will call B through function name, and B will definitely be called. -> means A will call B through function pointer, so B might not be called if the function pointer is not set. So error happens when only one of probe_hcall_entry and probe_hcall_exit get called during a hcall. This patch tries to move the preempt count operations from probe_hcall_entry and probe_hcall_exit to its callers. Reported-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by:
Li Zhong <zhong@linux.vnet.ibm.com> Tested-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Anton Blanchard authored
commit 37fb9a02 upstream. When re-enabling interrupts we have code to handle edge sensitive decrementers by resetting the decrementer to 1 whenever it is negative. If interrupts were disabled long enough that the decrementer wrapped to positive we do nothing. This means interrupts can be delayed for a long time until it finally goes negative again. While we hope interrupts are never be disabled long enough for the decrementer to go positive, we have a very good test team that can drive any kernel into the ground. The softlockup data we get back from these fails could be seconds in the future, completely missing the cause of the lockup. We already keep track of the timebase of the next event so use that to work out if we should trigger a decrementer exception. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Pontus Fuchs authored
commit 3f176494 upstream. Commit 80900d01 accidently broke the ABI for testmode commands. Restore the ABI again. Signed-off-by:
Pontus Fuchs <pontus.fuchs@gmail.com> Signed-off-by:
Luciano Coelho <coelho@ti.com> Signed-off-by:
-
Pontus Fuchs authored
commit f6efe96e upstream. An nvs with malformed contents could cause the processing of the calibration data to read beyond the end of the buffer. Prevent this from happening by adding bound checking. Signed-off-by:
-
Pontus Fuchs authored
commit 2131d3c2 upstream. Check for out of bound FEM index to prevent reading beyond ini memory end. Signed-off-by:
-
Rafał Miłecki authored
commit 775ab521 upstream. bcma used to lock up machine without enabling PCI or initializing CC. Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
Andres Salomon authored
commit afbca95f upstream. The libertas scan thread expects priv->scan_req to be non-NULL. In theory, it should always be set. In practice, we've seen the following oops: [ 8363.067444] Unable to handle kernel NULL pointer dereference at virtual address 00000004 [ 8363.067490] pgd = c0004000 [ 8363.078393] [00000004] *pgd=00000000 [ 8363.086711] Internal error: Oops: 17 [#1] PREEMPT [ 8363.091375] Modules linked in: fuse libertas_sdio libertas psmouse mousedev ov7670 mmp_camera joydev videobuf2_core videobuf2_dma_sg videobuf2_memops [last unloaded: scsi_wait_scan] [ 8363.107490] CPU: 0 Not tainted (3.0.0-gf7ccc69 #671) [ 8363.112799] PC is at lbs_scan_worker+0x108/0x5a4 [libertas] [ 8363.118326] LR is at 0x0 [ 8363.120836] pc : [<bf03a854>] lr : [<00000000>] psr: 60000113 [ 8363.120845] sp : ee66bf48 ip : 00000000 fp : 00000000 [ 8363.120845] r10: ee2c2088 r9 : c04e2efc r8 : eef97005 [ 8363.132231] r7 : eee0716f r6 : ee2c02c0 r5 : ee2c2088 r4 : eee07160 [ 8363.137419] r3 : 00000000 r2 : a0000113 r1 : 00000001 r0 : eee07160 [ 8363.143896] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 8363.157630] Control: 10c5387d Table: 2e754019 DAC: 00000015 [ 8363.163334] Process kworker/u:1 (pid: 25, stack limit = 0xee66a2f8) While I've not found a smoking gun, there are two places that raised red flags for me. The first is in _internal_start_scan, when we queue up a scan; we first queue the worker, and then set priv->scan_req. There's theoretically a 50mS delay which should be plenty, but doing things that way just seems racy (and not in the good way). The second is in the scan worker thread itself. Depending on the state of priv->scan_channel, we cancel pending scan runs and then requeue a run in 300mS. We then send the scan command down to the hardware, sleep, and if we get scan results for all the desired channels, we set priv->scan_req to NULL. However, it that's happened in less than 300mS, what happens with the pending scan run? This patch addresses both of those concerns. With the patch applied, we have not seen the oops in the past two weeks. Signed-off-by:
Andres Salomon <dilinger@queued.net> Signed-off-by:
-
Benjamin Herrenschmidt authored
commit c055fe07 upstream. We used to try to request 8 times more vram than needed, which would fail if the card has a too small BAR (observed with qemu & kvm). Signed-off-by:
-
Benjamin Herrenschmidt authored
commit 1bb0b7d2 upstream. When using a >8bpp framebuffer, offb advertises truecolor, not directcolor, and doesn't touch the color map even if it has a corresponding access method for the real hardware. Thus it needs to set the pseudo-palette with all 3 components of the color, like other truecolor framebuffers, not with copies of the color index like a directcolor framebuffer would do. This went unnoticed for a long time because it's pretty hard to get offb to kick in with anything but 8bpp (old BootX under MacOS will do that and qemu does it). Signed-off-by:
-
Larry Finger authored
commit 3f81f8f1 upstream. Testing on the openSUSE wireless forum has shown that a Linksys WUSB54GC v3 with USB ID 1737:0077 works with rt2800usb when the ID is written to /sys/.../new_id. This ID can therefore be moved out of UNKNOWN. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Acked-by:
Gertjan van Wingerde <gwingerde@gmail.com> Acked-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
-
Neil Horman authored
commit eea915bb upstream. This oops was reported recently: firmware_loading_store+0xf9/0x17b dev_attr_store+0x20/0x22 sysfs_write_file+0x101/0x134 vfs_write+0xac/0xf3 sys_write+0x4a/0x6e system_call_fastpath+0x16/0x1b The complete backtrace was unfortunately not captured, but details can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=769920 The cause is fairly clear. Its caused by the fact that firmware_loading_store has a case 0 in its switch statement that reads and writes the fw_priv->fw poniter without the protection of the fw_lock mutex. since there is a window between the time that _request_firmware sets fw_priv->fw to NULL and the time the corresponding sysfs file is unregistered, its possible for a user space application to race in, and write a zero to the loading file, causing a NULL dereference in firmware_loading_store. Fix it by extending the protection of the fw_lock mutex to cover all of the firware_loading_store function. Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
Joe Perches authored
commit 2eb7f204 upstream. The Japanese/Korean/Chinese versions still need updating. Also, the stable kernel 2.6.x.y descriptions are out of date and should be updated as well. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Joe Perches authored
commit bc7a2f3a upstream. The old address hasn't worked since the great intrusion of August 2011. Signed-off-by:
-
- 04 Jan, 2012 12 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: fix CAN MAINTAINERS SCM tree type mwifiex: fix crash during simultaneous scan and connect b43: fix regression in PIO case ath9k: Fix kernel panic in AR2427 in AP mode CAN MAINTAINERS update net: fsl: fec: fix build for mx23-only kernel sch_qfq: fix overflow in qfq_update_start() Revert "Bluetooth: Increase HCI reset timeout in hci_dev_do_close"
-
Al Viro authored
bitmap size sanity checks should be done *before* allocating ->s_root; there their cleanup on failure would be correct. As it is, we do iput() on root inode, but leak the root dentry... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Acked-by:
Josh Boyer <jwboyer@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Oleg Nesterov authored
This is the temporary simple fix for 3.2, we need more changes in this area. 1. do_signal_stop() assumes that the running untraced thread in the stopped thread group is not possible. This was our goal but it is not yet achieved: a stopped-but-resumed tracee can clone the running thread which can initiate another group-stop. Remove WARN_ON_ONCE(!current->ptrace). 2. A new thread always starts with ->jobctl = 0. If it is auto-attached and this group is stopped, __ptrace_unlink() sets JOBCTL_STOP_PENDING but JOBCTL_STOP_SIGMASK part is zero, this triggers WANR_ON(!signr) in do_jobctl_trap() if another debugger attaches. Change __ptrace_unlink() to set the artificial SIGSTOP for report. Alternatively we could change ptrace_init_task() to copy signr from current, but this means we can copy it for no reason and hide the possible similar problems. Acked-by:
Tejun Heo <tj@kernel.org> Cc: <stable@kernel.org> [3.1] Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
-
Oleg Nesterov authored
Test-case: int main(void) { int pid, status; pid = fork(); if (!pid) { for (;;) { if (!fork()) return 0; if (waitpid(-1, &status, 0) < 0) { printf("ERR!! wait: %m\n"); return 0; } } } assert(ptrace(PTRACE_ATTACH, pid, 0,0) == 0); assert(waitpid(-1, NULL, 0) == pid); assert(ptrace(PTRACE_SETOPTIONS, pid, 0, PTRACE_O_TRACEFORK) == 0); do { ptrace(PTRACE_CONT, pid, 0, 0); pid = waitpid(-1, NULL, 0); } while (pid > 0); return 1; } It fails because ->real_parent sees its child in EXIT_DEAD state while the tracer is going to change the state back to EXIT_ZOMBIE in wait_task_zombie(). The offending commit is 823b018e which moved the EXIT_DEAD check, but in fact we should not blame it. The original code was not correct as well because it didn't take ptrace_reparented() into account and because we can't really trust ->ptrace. This patch adds the additional check to close this particular race but it doesn't solve the whole problem. We simply can't rely on ->ptrace in this case, it can be cleared if the tracer is multithreaded by the exiting ->parent. I think we should kill EXIT_DEAD altogether, we should always remove the soon-to-be-reaped child from ->children or at least we should never do the DEAD->ZOMBIE transition. But this is too complex for 3.2. Reported-and-tested-by:Denys Vlasenko <vda.linux@googlemail.com> Tested-by:
Lukasz Michalik <lmi@ift.uni.wroc.pl> Acked-by:
-
git://git.samba.org/sfrench/cifs-2.6Linus Torvalds authored
* git://git.samba.org/sfrench/cifs-2.6: [CIFS] default ntlmv2 for cifs mount delayed to 3.3 cifs: fix bad buffer length check in coalesce_t2
-
John W. Linville authored
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
-
Linus Torvalds authored
This reverts commit 93b2ec01. The call to "schedule_work()" in rtc_initialize_alarm() happens too early, and can cause oopses at bootup Neil Brown explains why we do it: "If you set an alarm in the future, then shutdown and boot again after that time, then you will end up with a timer_queue node which is in the past. When this happens the queue gets stuck. That entry-in-the-past won't get removed until and interrupt happens and an interrupt won't happen because the RTC only triggers an interrupt when the alarm is "now". So you'll find that e.g. "hwclock" will always tell you that 'select' timed out. So we force the interrupt work to happen at the start just in case." and has a patch that convert it to do things in-process rather than with the worker thread, but right now it's too late to play around with this, so we just revert the patch that caused problems for now. Reported-by:
Sander Eikelenboom <linux@eikelenboom.it> Requested-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Requested-by:
John Stultz <john.stultz@linaro.org> Cc: Neil Brown <neilb@suse.de> Signed-off-by:
-
Steve French authored
Turned out the ntlmv2 (default security authentication) upgrade was harder to test than expected, and we ran out of time to test against Apple and a few other servers that we wanted to. Delay upgrade of default security from ntlm to ntlmv2 (on mount) to 3.3. Still works fine to specify it explicitly via "sec=ntlmv2" so this should be fine. Acked-by:
Jeff Layton <jlayton@samba.org> Signed-off-by:
Steve French <smfrench@gmail.com>
-
Jeff Layton authored
The current check looks to see if the RFC1002 length is larger than CIFSMaxBufSize, and fails if it is. The buffer is actually larger than that by MAX_CIFS_HDR_SIZE. This bug has been around for a long time, but the fact that we used to cap the clients MaxBufferSize at the same level as the server tended to paper over it. Commit c974befa changed that however and caused this bug to bite in more cases. Reported-and-Tested-by:
Konstantinos Skarlatos <k.skarlatos@gmail.com> Tested-by:
Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
-
Linus Torvalds authored
This reverts commit c0afabd3. It causes failures on Toshiba laptops - instead of disabling the alarm, it actually seems to enable it on the affected laptops, resulting in (for example) the laptop powering on automatically five minutes after shutdown. There's a patch for it that appears to work for at least some people, but it's too late to play around with this, so revert for now and try again in the next merge window. See for example http://bugs.debian.org/652869 Reported-and-bisected-by: Andreas Friedrich <afrie@gmx.net> (Toshiba Tecra) Reported-by: Antonio-M. Corbi Bellot <antonio.corbi@ua.es> (Toshiba Portege R500) Reported-by: Marco Santos <marco.santos@waynext.com> (Toshiba Portege Z830) Reported-by: Christophe Vu-Brugier <cvubrugier@yahoo.fr> (Toshiba Portege R830) Cc: Jonathan Nieder <jrnieder@gmail.com> Requested-by:
-
Mandeep Singh Baines authored
vfork parent uninterruptibly and unkillably waits for its child to exec/exit. This wait is of unbounded length. Ignore such waits in the hung_task detector. Signed-off-by:
Mandeep Singh Baines <msb@chromium.org> Reported-by:
-
