- 30 May, 2013 40 commits
-
-
libin authored
commit fd9b86d3 upstream. Commit 201c373e ("sched/debug: Limit sd->*_idx range on sysctl") was an incomplete bug fix. This patch fixes sd->*_idx limit range to [0 ~ CPU_LOAD_IDX_MAX-1] avoiding array overflow caused by setting sd->*_idx to CPU_LOAD_IDX_MAX on sysctl. Signed-off-by:
Libin <huawei.libin@huawei.com> Cc: <jiang.liu@huawei.com> Cc: <guohanjun@huawei.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/51626610.2040607@huawei.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> [bwh: Backported to 3.2: adjust filename] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Namhyung Kim authored
commit 201c373e upstream. Various sd->*_idx's are used for refering the rq's load average table when selecting a cpu to run. However they can be set to any number with sysctl knobs so that it can crash the kernel if something bad is given. Fix it by limiting them into the actual range. Signed-off-by:
Namhyung Kim <namhyung@kernel.org> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1345104204-8317-1-git-send-email-namhyung@kernel.orgSigned-off-by:
-
Sarah Sharp authored
commit a83d6755 upstream. When a device attached to the roothub is suspended, the endpoint rings are stopped. The host may generate a completion event with the completion code set to 'Stopped' or 'Stopped Invalid' when the ring is halted. The current xHCI code prints a warning in that case, which can be really annoying if the USB device is coming into and out of suspend. Remove the unnecessary warning. Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by:
Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
-
Cliff Wickman authored
commit a9ff785e upstream. A panic can be caused by simply cat'ing /proc/<pid>/smaps while an application has a VM_PFNMAP range. It happened in-house when a benchmarker was trying to decipher the memory layout of his program. /proc/<pid>/smaps and similar walks through a user page table should not be looking at VM_PFNMAP areas. Certain tests in walk_page_range() (specifically split_huge_page_pmd()) assume that all the mapped PFN's are backed with page structures. And this is not usually true for VM_PFNMAP areas. This can result in panics on kernel page faults when attempting to address those page structures. There are a half dozen callers of walk_page_range() that walk through a task's entire page table (as N. Horiguchi pointed out). So rather than change all of them, this patch changes just walk_page_range() to ignore VM_PFNMAP areas. The logic of hugetlb_vma() is moved back into walk_page_range(), as we want to test any vma in the range. VM_PFNMAP areas are used by: - graphics memory manager gpu/drm/drm_gem.c - global reference unit sgi-gru/grufile.c - sgi special memory char/mspec.c - and probably several out-of-tree modules [akpm@linux-foundation.org: remove now-unused hugetlb_vma() stub] Signed-off-by:
Cliff Wickman <cpw@sgi.com> Reviewed-by:
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: David Sterba <dsterba@suse.cz> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Joseph Qi authored
commit b4ca2b4b upstream. Last time we found there is lock/unlock bug in ocfs2_file_aio_write, and then we did a thorough search for all lock resources in ocfs2_inode_info, including rw, inode and open lockres and found this bug. My kernel version is 3.0.13, and it is also in the lastest version 3.9. In ocfs2_fiemap, once ocfs2_get_clusters_nocache failed, it should goto out_unlock instead of out, because we need release buffer head, up read alloc sem and unlock inode. Signed-off-by:
Joseph Qi <joseph.qi@huawei.com> Reviewed-by:
Jie Liu <jeff.liu@oracle.com> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker <jlbec@evilplan.org> Acked-by:
Sunil Mushran <sunil.mushran@gmail.com> Signed-off-by:
-
Jiri Kosina authored
commit 10b3a32d upstream. Commit 902c098a ("random: use lockless techniques in the interrupt path") turned IRQ path from being spinlock protected into lockless cmpxchg-retry update. That commit removed r->lock serialization between crediting entropy bits from IRQ context and accounting when extracting entropy on userspace read path, but didn't turn the r->entropy_count reads/updates in account() to use cmpxchg as well. It has been observed, that under certain circumstances this leads to read() on /dev/urandom to return 0 (EOF), as r->entropy_count gets corrupted and becomes negative, which in turn results in propagating 0 all the way from account() to the actual read() call. Convert the accounting code to be the proper lockless counterpart of what has been partially done by 902c098a. Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Cc: Theodore Ts'o <tytso@mit.edu> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Ryusuke Konishi authored
commit 136e8770 upstream. nilfs2: fix issue of nilfs_set_page_dirty for page at EOF boundary DESCRIPTION: There are use-cases when NILFS2 file system (formatted with block size lesser than 4 KB) can be remounted in RO mode because of encountering of "broken bmap" issue. The issue was reported by Anthony Doggett <Anthony2486@interfaces.org.uk>: "The machine I've been trialling nilfs on is running Debian Testing, Linux version 3.2.0-4-686-pae (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.35-2), but I've also reproduced it (identically) with Debian Unstable amd64 and Debian Experimental (using the 3.8-trunk kernel). The problematic partitions were formatted with "mkfs.nilfs2 -b 1024 -B 8192"." SYMPTOMS: (1) System log contains error messages likewise: [63102.496756] nilfs_direct_assign: invalid pointer: 0 [63102.496786] NILFS error (device dm-17): nilfs_bmap_assign: broken bmap (inode number=28) [63102.496798] [63102.524403] Remounting filesystem read-only (2) The NILFS2 file system is remounted in RO mode. REPRODUSING PATH: (1) Create volume group with name "unencrypted" by means of vgcreate utility. (2) Run script (prepared by Anthony Doggett <Anthony2486@interfaces.org.uk>): ----------------[BEGIN SCRIPT]-------------------- VG=unencrypted lvcreate --size 2G --name ntest $VG mkfs.nilfs2 -b 1024 -B 8192 /dev/mapper/$VG-ntest mkdir /var/tmp/n mkdir /var/tmp/n/ntest mount /dev/mapper/$VG-ntest /var/tmp/n/ntest mkdir /var/tmp/n/ntest/thedir cd /var/tmp/n/ntest/thedir sleep 2 date darcs init sleep 2 dmesg|tail -n 5 date darcs whatsnew || true date sleep 2 dmesg|tail -n 5 ----------------[END SCRIPT]-------------------- REPRODUCIBILITY: 100% INVESTIGATION: As it was discovered, the issue takes place during segment construction after executing such sequence of user-space operations: open("_darcs/index", O_RDWR|O_CREAT|O_NOCTTY, 0666) = 7 fstat(7, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 ftruncate(7, 60) The error message "NILFS error (device dm-17): nilfs_bmap_assign: broken bmap (inode number=28)" takes place because of trying to get block number for third block of the file with logical offset #3072 bytes. As it is possible to see from above output, the file has 60 bytes of the whole size. So, it is enough one block (1 KB in size) allocation for the whole file. Trying to operate with several blocks instead of one takes place because of discovering several dirty buffers for this file in nilfs_segctor_scan_file() method. The root cause of this issue is in nilfs_set_page_dirty function which is called just before writing to an mmapped page. When nilfs_page_mkwrite function handles a page at EOF boundary, it fills hole blocks only inside EOF through __block_page_mkwrite(). The __block_page_mkwrite() function calls set_page_dirty() after filling hole blocks, thus nilfs_set_page_dirty function (= a_ops->set_page_dirty) is called. However, the current implementation of nilfs_set_page_dirty() wrongly marks all buffers dirty even for page at EOF boundary. As a result, buffers outside EOF are inconsistently marked dirty and queued for write even though they are not mapped with nilfs_get_block function. FIX: This modifies nilfs_set_page_dirty() not to mark hole blocks dirty. Thanks to Vyacheslav Dubeyko for his effort on analysis and proposals for this issue. Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Reported-by:
Anthony Doggett <Anthony2486@interfaces.org.uk> Reported-by:
Vyacheslav Dubeyko <slava@dubeyko.com> Cc: Vyacheslav Dubeyko <slava@dubeyko.com> Tested-by:
-
Brian Behlendorf authored
commit dfd20b2b upstream. The index on the page must be set before it is inserted in the radix tree. Otherwise there is a small race which can occur during lookup where the page can be found with the incorrect index. This will trigger the BUG_ON() in brd_lookup_page(). Signed-off-by:
Brian Behlendorf <behlendorf1@llnl.gov> Reported-by:
Chris Wedgwood <cw@f00f.org> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Aneesh Kumar K.V authored
commit 7c342512 upstream. We should not use set_pmd_at to update pmd_t with pgtable_t pointer. set_pmd_at is used to set pmd with huge pte entries and architectures like ppc64, clear few flags from the pte when saving a new entry. Without this change we observe bad pte errors like below on ppc64 with THP enabled. BUG: Bad page map in process ld mm=0xc000001ee39f4780 pte:7fc3f37848000001 pmd:c000001ec0000000 Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Cc: Hugh Dickins <hughd@google.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reviewed-by:
Andrea Arcangeli <aarcange@redhat.com> Signed-off-by:
-
Leonid Yegoshin authored
commit c2cc499c upstream. Page 'new' during MIGRATION can't be flushed with flush_cache_page(). Using flush_cache_page(vma, addr, pfn) is justified only if the page is already placed in process page table, and that is done right after flush_cache_page(). But without it the arch function has no knowledge of process PTE and does nothing. Besides that, flush_cache_page() flushes an application cache page, but the kernel has a different page virtual address and dirtied it. Replace it with flush_dcache_page(new) which is the proper usage. The old page is flushed in try_to_unmap_one() before migration. This bug takes place in Sead3 board with M14Kc MIPS CPU without cache aliasing (but Harvard arch - separate I and D cache) in tight memory environment (128MB) each 1-3days on SOAK test. It fails in cc1 during kernel build (SIGILL, SIGBUS, SIGSEG) if CONFIG_COMPACTION is switched ON. Signed-off-by:
Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: Leonid Yegoshin <yegoshin@mips.com> Acked-by:
Rik van Riel <riel@redhat.com> Cc: Michal Hocko <mhocko@suse.cz> Acked-by:
Mel Gorman <mgorman@suse.de> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Russell King <rmk@arm.linux.org.uk> Cc: David Miller <davem@davemloft.net> Signed-off-by:
-
Alexandre Bounine authored
commit 1ccc819d upstream. Fix bug in MSI interrupt handling which causes loss of event notifications. Typical indication of lost MSI interrupts are stalled message and doorbell transfers between RapidIO endpoints. To avoid loss of MSI interrupts all interrupts from the device must be disabled on entering the interrupt handler routine and re-enabled when exiting it. Re-enabling device interrupts will trigger new MSI message(s) if Tsi721 registered new events since entering interrupt handler routine. This patch is applicable to kernel versions starting from v3.2. Signed-off-by:
Alexandre Bounine <alexandre.bounine@idt.com> Cc: Matt Porter <mporter@kernel.crashing.org> Signed-off-by:
-
Xiao Guangrong authored
commit d34883d4 upstream. Commit 751efd86 ("mmu_notifier_unregister NULL Pointer deref and multiple ->release()") breaks the fix 3ad3d901 ("mm: mmu_notifier: fix freed page still mapped in secondary MMU"). Since hlist_for_each_entry_rcu() is changed now, we can not revert that patch directly, so this patch reverts the commit and simply fix the bug spotted by that patch This bug spotted by commit 751efd86 is: There is a race condition between mmu_notifier_unregister() and __mmu_notifier_release(). Assume two tasks, one calling mmu_notifier_unregister() as a result of a filp_close() ->flush() callout (task A), and the other calling mmu_notifier_release() from an mmput() (task B). A B t1 srcu_read_lock() t2 if (!hlist_unhashed()) t3 srcu_read_unlock() t4 srcu_read_lock() t5 hlist_del_init_rcu() t6 synchronize_srcu() t7 srcu_read_unlock() t8 hlist_del_rcu() <--- NULL pointer deref. This can be fixed by using hlist_del_init_rcu instead of hlist_del_rcu. The another issue spotted in the commit is "multiple ->release() callouts", we needn't care it too much because it is really rare (e.g, can not happen on kvm since mmu-notify is unregistered after exit_mmap()) and the later call of multiple ->release should be fast since all the pages have already been released by the first call. Anyway, this issue should be fixed in a separate patch. -stable suggestions: Any version that has commit 751efd86 need to be backported. I find the oldest version has this commit is 3.0-stable. [akpm@linux-foundation.org: tweak comments] Signed-off-by:
Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> Tested-by:
Robin Holt <holt@sgi.com> Signed-off-by:
-
Imre Deak authored
commit 4c663cfc upstream. Many callers of the wait_event_timeout() and wait_event_interruptible_timeout() expect that the return value will be positive if the specified condition becomes true before the timeout elapses. However, at the moment this isn't guaranteed. If the wake-up handler is delayed enough, the time remaining until timeout will be calculated as 0 - and passed back as a return value - even if the condition became true before the timeout has passed. Fix this by returning at least 1 if the condition becomes true. This semantic is in line with what wait_for_condition_timeout() does; see commit bb10ed09 ("sched: fix wait_for_completion_timeout() spurious failure under heavy load"). Daniel said "We have 3 instances of this bug in drm/i915. One case even where we switch between the interruptible and not interruptible wait_event_timeout variants, foolishly presuming they have the same semantics. I very much like this." One such bug is reported at https://bugs.freedesktop.org/show_bug.cgi?id=64133Signed-off-by:
Imre Deak <imre.deak@intel.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
David Howells <dhowells@redhat.com> Acked-by:
Jens Axboe <axboe@kernel.dk> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Cc: Dave Jones <davej@redhat.com> Cc: Lukas Czerner <lczerner@redhat.com> Signed-off-by:
-
OGAWA Hirofumi authored
commit 7b92d03c upstream. Intermediate value of fat_clusters can be overflowed on 32bits arch. Reported-by:
Krzysztof Strasburger <strasbur@chkw386.ch.pwr.wroc.pl> Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
-
Bastian Triller authored
commit c8f6d835 upstream. Like on UL30VT, the ACPI video driver can't control backlight correctly on Asus UL30A. Vendor driver (asus-laptop) can work. This patch is to add "Asus UL30A" to ACPI video detect blacklist in order to use asus-laptop for video control on the "Asus UL30A" rather than ACPI video driver. Signed-off-by:
Bastian Triller <bastian.triller@gmail.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Ben Hutchings authored
commit 5a1e99dd upstream. The comparison between traced and symbol addresses is backwards: if the traced address doesn't exactly match a symbol (which we don't expect it to), we'll show the next symbol and the offset to it, whereas we should show the previous symbol and the offset from it. Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ben Hutchings authored
commit 140c3c6a upstream. This works much better if we don't treat protocol numbers as addresses. Signed-off-by:
-
Trond Myklebust authored
commit a3c3cac5 upstream. The lockless RPC_IS_QUEUED() test in __rpc_execute means that we need to be careful about ordering the calls to rpc_test_and_set_running(task) and rpc_clear_queued(task). If we get the order wrong, then we may end up testing the RPC_TASK_RUNNING flag after __rpc_execute() has looped and changed the state of the rpc_task. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Jeff Layton authored
commit 506026c3 upstream. rpc_make_runnable is not generally called with the queue lock held, unless it's waking up a task that has been sitting on a waitqueue. This is safe when the task has not entered the FSM yet, but the comments don't really spell this out. Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
-
Wang YanQing authored
commit dab73b4e upstream. I meet emacs hang in start if I do the operation below: 1: echo 3 > /proc/sys/vm/drop_caches 2: emacs BigFile 3: Press CTRL-S follow 2 immediately Then emacs hang on, CTRL-Q can't resume, the terminal hang on, you can do nothing with this terminal except close it. The reason is before emacs takeover control the tty, we use CTRL-S to XOFF it. Then when emacs takeover the control, it may don't use the flow-control, so emacs hang. This patch fix it. This patch will fix a kind of strange tty relation hang problem, I believe I meet it with vim in ssh, and also see below bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465823Signed-off-by:
Wang YanQing <udknight@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Dan Carpenter authored
commit 2a0ebf80 upstream. The value of "offd" comes off the instance->rcv_buf[] and we used it as the offset into an array. The problem is that we check the upper bound but not for negative values. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Gregory CLEMENT authored
commit 2b8b2797 upstream. When platform data were moved from arch/arm/mach-mv78xx0/common.c to arch/arm/plat-orion/common.c with the commit "7e3819d8 ARM: orion: Consolidate ethernet platform data", there were few typo made on gigabit Ethernet interface ge10 and ge11. This commit writes back their initial value, which allows to use this interfaces again. Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
-
Michael S. Tsirkin authored
commit 6407d75a upstream. uapi should use __u32 not u32. Fix a macro in virtio_console.h which uses u32. Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> [bwh: Backported to 3.2: adjust filename] Signed-off-by:
-
Gabriel de Perthuis authored
commit 03b71c6c upstream. The search ioctl skips items that are too large for a result buffer, but inline items of a certain size occuring before any search result is found would trigger an overflow and stop the search entirely. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=57641Signed-off-by:
Gabriel de Perthuis <g2p.code+btrfs@gmail.com> Signed-off-by:
Josef Bacik <jbacik@fusionio.com> Signed-off-by:
-
Gomella, Andrew (NIH/NHLBI) [F] authored
commit 71381439 upstream. Here are two more devices that use FTDI USB-to-serial chips with new product ID's. The devices are the Newport Conex-AGP and Conex-CC motor controllers. (http://www.newport.com/CONEX-AGP-Integrated-Piezo-Motor-Rotation-Stages-/987623/1033/info.aspx) (http://www.newport.com/CONEX-CC-DC-Servo-Controller-Actuators/934114/1033/info.aspx) usb-devices command yields: P: Vendor=104d ProdID=3002 Rev=06.00 S: Manufacturer=Newport S: Product=CONEX-CC as well as P: Vendor=104d ProdID=3006 Rev=06.00 S: Manufacturer=Newport S: Product=CONEX-AGP Signed-off-by:
Andrew Gomella <andrew.gomella@nih.gov> Signed-off-by:
-
Mika Westerberg authored
commit 2a2d95e9 upstream. If the I2C bus is put to a low power state by an ACPI method it might pull the SDA line low (as its power is removed). Once the bus is put to full power state again, the SDA line is pulled back to high. This transition looks like a STOP condition from the controller point-of-view which sets STOP detected bit in its status register causing the driver to fail subsequent transfers. Fix this by always clearing all interrupts before we start a transfer. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Dan Williams authored
commit 49c6e370 upstream. A rebranded Novatel E371 for AT&T's LTE bands. Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Schemmel Hans-Christoph authored
commit 8ff10bdb upstream. /drivers/usb/serial/option.c: Blacklisted Cinterion's PLxx WWAN Interface (USB Interface 4), because it will be handled by QMI WWAN driver. Product IDs renamed. Signed-off-by:
Hans-Christoph Schemmel <hans-christoph.schemmel@gemalto.com> Signed-off-by:
-
Teppo Kotilainen authored
commit 73c042df upstream. Information from driver description files: diag: VID_19D2&PID_0412&MI_00 nmea: VID_19D2&PID_0412&MI_01 at: VID_19D2&PID_0412&MI_02 modem: VID_19D2&PID_0412&MI_03 net: VID_19D2&PID_0412&MI_04 Signed-off-by:
Teppo Kotilainen <qubit303@gmail.com> Signed-off-by:
-
Oliver Neukum authored
commit bac6b032 upstream. Werner Fink has reported problems with this hub. Signed-off-by:
Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Benjamin LaHaise authored
commit 6368087e upstream. When a 32 bit version of ipmitool is used on a 64 bit kernel, the ipmi_devintf code fails to correctly acquire ipmi_mutex. This results in incomplete data being retrieved in some cases, or other possible failures. Add a wrapper around compat_ipmi_ioctl() to take ipmi_mutex to fix this. Signed-off-by:
Benjamin LaHaise <bcrl@kvack.org> Signed-off-by:
Corey Minyard <cminyard@mvista.com> Signed-off-by:
-
Chen Gang authored
commit a5f2b3d6 upstream. When calling memcpy, read_data and write_data need additional 2 bytes. write_data: for checking: "if (size > IPMI_MAX_MSG_LENGTH)" for operating: "memcpy(bt->write_data + 3, data + 1, size - 1)" read_data: for checking: "if (msg_len < 3 || msg_len > IPMI_MAX_MSG_LENGTH)" for operating: "memcpy(data + 2, bt->read_data + 4, msg_len - 2)" Signed-off-by:
Chen Gang <gang.chen@asianux.com> Signed-off-by:
-
Oleg Nesterov authored
commit 264b83c0 upstream. argv_split(empty_or_all_spaces) happily succeeds, it simply returns argc == 0 and argv[0] == NULL. Change call_usermodehelper_exec() to check sub_info->path != NULL to avoid the crash. This is the minimal fix, todo: - perhaps we should change argv_split() to return NULL or change the callers. - kill or justify ->path[0] check - narrow the scope of helper_lock() Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Acked-By:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit 60705c89 upstream. Special preds are created when folding a series of preds that can be done in serial. These are allocated in an ops field of the pred structure. But they were never freed, causing memory leaks. This was discovered using the kmemleak checker: unreferenced object 0xffff8800797fd5e0 (size 32): comm "swapper/0", pid 1, jiffies 4294690605 (age 104.608s) hex dump (first 32 bytes): 00 00 01 00 03 00 05 00 07 00 09 00 0b 00 0d 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814b52af>] kmemleak_alloc+0x73/0x98 [<ffffffff8111ff84>] kmemleak_alloc_recursive.constprop.42+0x16/0x18 [<ffffffff81120e68>] __kmalloc+0xd7/0x125 [<ffffffff810d47eb>] kcalloc.constprop.24+0x2d/0x2f [<ffffffff810d4896>] fold_pred_tree_cb+0xa9/0xf4 [<ffffffff810d3781>] walk_pred_tree+0x47/0xcc [<ffffffff810d5030>] replace_preds.isra.20+0x6f8/0x72f [<ffffffff810d50b5>] create_filter+0x4e/0x8b [<ffffffff81b1c30d>] ftrace_test_event_filter+0x5a/0x155 [<ffffffff8100028d>] do_one_initcall+0xa0/0x137 [<ffffffff81afbedf>] kernel_init_freeable+0x14d/0x1dc [<ffffffff814b24b7>] kernel_init+0xe/0xdb [<ffffffff814d539c>] ret_from_fork+0x7c/0xb0 [<ffffffffffffffff>] 0xffffffffffffffff Cc: Tom Zanussi <tzanussi@gmail.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Alan Stern authored
commit 997ff893 upstream. HP's virtual UHCI host controller takes a long time to suspend (several hundred microseconds), even when no devices are attached. This provokes a warning message from uhci-hcd in the auto-stop case. To prevent this from happening, this patch adds a test to avoid performing an auto-stop when the wait_for_hp quirk flag is set. The controller will still suspend through the normal runtime PM mechanism. And since that pathway includes a 1-ms delay, the slowness of the virtual hardware won't matter. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by:
ZhenHua <zhen-hual@hp.com> Signed-off-by:
-
Alan Stern authored
commit e4f47e36 upstream. This patch shortens the logic in xhci_endpoint_init() by moving common calculations involving max_packet and max_burst outside the switch statement, rather than repeating the same code in multiple case-specific statements. It also replaces two usages of max_packet which were clearly intended to be max_burst all along. More importantly, it compensates for a common bug in high-speed bulk endpoint descriptors. In many devices there is a bulk endpoint having a wMaxPacketSize value smaller than 512, which is forbidden by the USB spec. Some xHCI controllers can't handle this and refuse to accept the endpoint. This patch changes the max_packet value to 512, which allows the controller to use the endpoint properly. In practice the bogus maxpacket size doesn't matter, because none of the transfers sent via these endpoints are longer than the maxpacket value anyway. Signed-off-by:
"Aurélien Leblond" <blablack@gmail.com> Signed-off-by:
-
Nithin Sujir authored
commit 44f3b503 upstream. On the 5718, 5719 and 5720 serdes devices, powering down function 0 results in all the other ports being powered down. Add code to skip function 0 power down. v2: - Modify tg3_phy_power_bug() function to use a switch instead of a complicated if statement. Suggested by Joe Perches. Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
Nithin Nayak Sujir <nsujir@broadcom.com> Signed-off-by:
-
Tirupathi Reddy authored
commit 42a5cf46 upstream. An inactive timer's base can refer to a offline cpu's base. In the current code, cpu_base's lock is blindly reinitialized each time a CPU is brought up. If a CPU is brought online during the period that another thread is trying to modify an inactive timer on that CPU with holding its timer base lock, then the lock will be reinitialized under its feet. This leads to following SPIN_BUG(). <0> BUG: spinlock already unlocked on CPU#3, kworker/u:3/1466 <0> lock: 0xe3ebe000, .magic: dead4ead, .owner: kworker/u:3/1466, .owner_cpu: 1 <4> [<c0013dc4>] (unwind_backtrace+0x0/0x11c) from [<c026e794>] (do_raw_spin_unlock+0x40/0xcc) <4> [<c026e794>] (do_raw_spin_unlock+0x40/0xcc) from [<c076c160>] (_raw_spin_unlock+0x8/0x30) <4> [<c076c160>] (_raw_spin_unlock+0x8/0x30) from [<c009b858>] (mod_timer+0x294/0x310) <4> [<c009b858>] (mod_timer+0x294/0x310) from [<c00a5e04>] (queue_delayed_work_on+0x104/0x120) <4> [<c00a5e04>] (queue_delayed_work_on+0x104/0x120) from [<c04eae00>] (sdhci_msm_bus_voting+0x88/0x9c) <4> [<c04eae00>] (sdhci_msm_bus_voting+0x88/0x9c) from [<c04d8780>] (sdhci_disable+0x40/0x48) <4> [<c04d8780>] (sdhci_disable+0x40/0x48) from [<c04bf300>] (mmc_release_host+0x4c/0xb0) <4> [<c04bf300>] (mmc_release_host+0x4c/0xb0) from [<c04c7aac>] (mmc_sd_detect+0x90/0xfc) <4> [<c04c7aac>] (mmc_sd_detect+0x90/0xfc) from [<c04c2504>] (mmc_rescan+0x7c/0x2c4) <4> [<c04c2504>] (mmc_rescan+0x7c/0x2c4) from [<c00a6a7c>] (process_one_work+0x27c/0x484) <4> [<c00a6a7c>] (process_one_work+0x27c/0x484) from [<c00a6e94>] (worker_thread+0x210/0x3b0) <4> [<c00a6e94>] (worker_thread+0x210/0x3b0) from [<c00aad9c>] (kthread+0x80/0x8c) <4> [<c00aad9c>] (kthread+0x80/0x8c) from [<c000ea80>] (kernel_thread_exit+0x0/0x8) As an example, this particular crash occurred when CPU #3 is executing mod_timer() on an inactive timer whose base is refered to offlined CPU #2. The code locked the timer_base corresponding to CPU #2. Before it could proceed, CPU #2 came online and reinitialized the spinlock corresponding to its base. Thus now CPU #3 held a lock which was reinitialized. When CPU #3 finally ended up unlocking the old cpu_base corresponding to CPU #2, we hit the above SPIN_BUG(). CPU #0 CPU #3 CPU #2 ------ ------- ------- ..... ...... <Offline> mod_timer() lock_timer_base spin_lock_irqsave(&base->lock) cpu_up(2) ..... ...... init_timers_cpu() .... ..... spin_lock_init(&base->lock) ..... spin_unlock_irqrestore(&base->lock) ...... <spin_bug> Allocation of per_cpu timer vector bases is done only once under "tvec_base_done[]" check. In the current code, spinlock_initialization of base->lock isn't under this check. When a CPU is up each time the base lock is reinitialized. Move base spinlock initialization under the check. Signed-off-by:
Tirupathi Reddy <tirupath@codeaurora.org> Link: http://lkml.kernel.org/r/1368520142-4136-1-git-send-email-tirupath@codeaurora.orgSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Robert Jennings authored
commit 120496ac upstream. This patch brings online all threads which are present but not online prior to migration/hibernation. After migration/hibernation those threads are taken back offline. During migration/hibernation all online CPUs must call H_JOIN, this is required by the hypervisor. Without this patch, threads that are offline (H_CEDE'd) will not be woken to make the H_JOIN call and the OS will be deadlocked (all threads either JOIN'd or CEDE'd). Signed-off-by:
Robert Jennings <rcj@linux.vnet.ibm.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Brian King authored
commit 444080d1 upstream. This fixes a hang that was observed during live partition migration. Since stop_topology_update must not be called from an interrupt context, call it earlier in the migration process. The hang observed can be seen below: WARNING: at kernel/timer.c:1011 Modules linked in: ip6t_LOG xt_tcpudp xt_pkttype ipt_LOG xt_limit ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw xt_NOTRACK ipt_REJECT xt_state iptable_raw iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables ip6table_filter ip6_tables x_tables ipv6 fuse loop ibmveth sg ext3 jbd mbcache raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid10 raid1 raid0 scsi_dh_alua scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc dm_round_robin dm_multipath scsi_dh sd_mod crc_t10dif ibmvfc scsi_transport_fc scsi_tgt scsi_mod dm_snapshot dm_mod NIP: c0000000000c52d8 LR: c00000000004be28 CTR: 0000000000000000 REGS: c00000005ffd77d0 TRAP: 0700 Not tainted (3.2.0-git-00001-g07d106d0) MSR: 8000000000021032 <ME,CE,IR,DR> CR: 48000084 XER: 00000001 CFAR: c00000000004be20 TASK = c00000005ec78860[0] 'swapper/3' THREAD: c00000005ec98000 CPU: 3 GPR00: 0000000000000001 c00000005ffd7a50 c000000000fbbc98 c000000000ec8340 GPR04: 00000000282a0020 0000000000000000 0000000000004000 0000000000000101 GPR08: 0000000000000012 c00000005ffd4000 0000000000000020 c000000000f3ba88 GPR12: 0000000000000000 c000000007f40900 0000000000000001 0000000000000004 GPR16: 0000000000000001 0000000000000000 0000000000000000 c000000001022310 GPR20: 0000000000000001 0000000000000000 0000000000200200 c000000001029e14 GPR24: 0000000000000000 0000000000000001 0000000000000040 c00000003f74bc80 GPR28: c00000003f74bc84 c000000000f38038 c000000000f16b58 c000000000ec8340 NIP [c0000000000c52d8] .del_timer_sync+0x28/0x60 LR [c00000000004be28] .stop_topology_update+0x20/0x38 Call Trace: [c00000005ffd7a50] [c00000005ec78860] 0xc00000005ec78860 (unreliable) [c00000005ffd7ad0] [c00000000004be28] .stop_topology_update+0x20/0x38 [c00000005ffd7b40] [c000000000028378] .__rtas_suspend_last_cpu+0x58/0x260 [c00000005ffd7bf0] [c0000000000fa230] .generic_smp_call_function_interrupt+0x160/0x358 [c00000005ffd7cf0] [c000000000036ec8] .smp_ipi_demux+0x88/0x100 [c00000005ffd7d80] [c00000000005c154] .icp_hv_ipi_action+0x5c/0x80 [c00000005ffd7e00] [c00000000012a088] .handle_irq_event_percpu+0x100/0x318 [c00000005ffd7f00] [c00000000012e774] .handle_percpu_irq+0x84/0xd0 [c00000005ffd7f90] [c000000000022ba8] .call_handle_irq+0x1c/0x2c [c00000005ec9ba20] [c00000000001157c] .do_IRQ+0x22c/0x2a8 [c00000005ec9bae0] [c0000000000054bc] hardware_interrupt_entry+0x18/0x1c Exception: 501 at .cpu_idle+0x194/0x2f8 LR = .cpu_idle+0x194/0x2f8 [c00000005ec9bdd0] [c000000000017e58] .cpu_idle+0x188/0x2f8 (unreliable) [c00000005ec9be90] [c00000000067ec18] .start_secondary+0x3e4/0x524 [c00000005ec9bf90] [c0000000000093e8] .start_secondary_prolog+0x10/0x14 Instruction dump: ebe1fff8 4e800020 fbe1fff8 7c0802a6 f8010010 7c7f1b78 f821ff81 78290464 80090014 5400019e 7c0000d0 78000fe0 <0b000000> 4800000c 7c210b78 7c421378 Signed-off-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
-
![Gomella, Andrew (NIH/NHLBI) [F]'s avatar](https://secure.gravatar.com/avatar/bfa6f109d396238589be34a784facb06?s=80&d=identicon "Gomella, Andrew (NIH/NHLBI) [F]")
