Skip to main content

Browse the archive

https://github.com/torvalds/linux
17 August 2024, 15:42:30 UTC
sort by:
Revision Author Date Message Commit Date
52469b4 Linus Torvalds 31 October 2013, 22:21:26 UTC Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull NUMA balancing memory corruption fixes from Ingo Molnar: "So these fixes are definitely not something I'd like to sit on, but as I said to Mel at the KS the timing is quite tight, with Linus planning v3.12-final within a week. Fedora-19 is affected: comet:~> grep NUMA_BALANCING /boot/config-3.11.3-201.fc19.x86_64 CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y CONFIG_NUMA_BALANCING=y AFAICS Ubuntu will be affected as well, once it updates the kernel: hubble:~> grep NUMA_BALANCING /boot/config-3.8.0-32-generic CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y CONFIG_NUMA_BALANCING=y These 6 commits are a minimalized set of cherry-picks needed to fix the memory corruption bugs. All commits are fixes, except "mm: numa: Sanitize task_numa_fault() callsites" which is a cleanup that made two followup fixes simpler. I've done targeted testing with just this SHA1 to try to make sure there are no cherry-picking artifacts. The original non-cherry-picked set of fixes were exposed to linux-next for a couple of weeks" * 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: mm: Account for a THP NUMA hinting update as one PTE update mm: Close races between THP migration and PMD numa clearing mm: numa: Sanitize task_numa_fault() callsites mm: Prevent parallel splits during THP migration mm: Wait for THP migrations to complete during NUMA hinting faults mm: numa: Do not account for a hinting fault if we raced 31 October 2013, 22:21:26 UTC
026f8f6 Linus Torvalds 31 October 2013, 17:38:59 UTC Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input updates from Dmitry Torokhov: "A bit later than I would want, but the changes are very minor - a few new device IDs for new hardware in existing drivers, fix for battery in Wacom devices not be considered system battery and cause emergency hibernations, and a couple of other bug fixes" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: ALPS - add support for model found on Dell XT2 Input: wacom - add support for ISDv4 0x10E sensor Input: wacom - add support for ISDv4 0x10F sensor Input: wacom - export battery scope Input: cm109 - convert high volume dev_err() to dev_err_ratelimited() Input: move name/timer init to input_alloc_dev() Input: i8042 - i8042_flush fix for a full 8042 buffer Input: pxa27x_keypad - fix NULL pointer dereference 31 October 2013, 17:38:59 UTC
e764702 Linus Torvalds 31 October 2013, 17:13:28 UTC Merge tag 'pm+acpi-3.12-late' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI and power management fixes from Rafael J Wysocki: "Last-minute ACPI and power management fixes for 3.12 - Revert epoll and select commits related to the freezer, introduced during the 3.11 cycle, that cause mysterious user space breakage to occur during resume from suspend to RAM for multiple users of 32-bit x86 systems. Material for 3.11.y stable kernels. - Revert a recent ACPI-based PCI hotplug (ACPIPHP) commit that was part of boot problem fixes for one machine, but turns out to cause issues with hotplug on Thunderbolt chains with multiple devices. It also turns out to be unnecessary after another fix in the same area that went in later. From Mika Westerberg" * tag 'pm+acpi-3.12-late' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: Revert "ACPI / hotplug / PCI: Avoid doing too much for spurious notifies" Revert "select: use freezable blocking call" Revert "epoll: use freezable blocking call" 31 October 2013, 17:13:28 UTC
5beea88 Yunkang Tang 31 October 2013, 07:55:58 UTC Input: ALPS - add support for model found on Dell XT2 This patch adds support for touchpad found on Dell XT2. It's a dual device with device ID: 73, 00, 14, that comply with "ALPS_PROTO_V2". Signed-off-by: Yunkang Tang <yunkang.tang@cn.alps.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 31 October 2013, 07:59:20 UTC
74c85e1 Dave Airlie 31 October 2013, 05:29:10 UTC Merge branch 'drm-fixes-3.12' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Just a few small fixes for radeon (audio regression fix, stability fix, and an endian bug noticed by coverity). * 'drm-fixes-3.12' of git://people.freedesktop.org/~agd5f/linux: drm/radeon/dpm: fix incompatible casting on big endian drm/radeon: disable bapm on KB drm/radeon: use sw CTS/N values for audio on DCE4+ 31 October 2013, 05:29:10 UTC
12aee27 Linus Torvalds 30 October 2013, 21:27:10 UTC Merge branch 'akpm' (fixes from Andrew Morton) Merge three fixes from Andrew Morton. * emailed patches from Andrew Morton <akpm@linux-foundation.org>: memcg: use __this_cpu_sub() to dec stats to avoid incorrect subtrahend casting percpu: fix this_cpu_sub() subtrahend casting for unsigneds mm/pagewalk.c: fix walk_page_range() access of wrong PTEs 30 October 2013, 21:27:10 UTC
5e8cfc3 Greg Thelen 30 October 2013, 20:56:21 UTC memcg: use __this_cpu_sub() to dec stats to avoid incorrect subtrahend casting As of commit 3ea67d06e467 ("memcg: add per cgroup writeback pages accounting") memcg counter errors are possible when moving charged memory to a different memcg. Charge movement occurs when processing writes to memory.force_empty, moving tasks to a memcg with memcg.move_charge_at_immigrate=1, or memcg deletion. An example showing error after memory.force_empty: $ cd /sys/fs/cgroup/memory $ mkdir x $ rm /data/tmp/file $ (echo $BASHPID >> x/tasks && exec mmap_writer /data/tmp/file 1M) & [1] 13600 $ grep ^mapped x/memory.stat mapped_file 1048576 $ echo 13600 > tasks $ echo 1 > x/memory.force_empty $ grep ^mapped x/memory.stat mapped_file 4503599627370496 mapped_file should end with 0. 4503599627370496 == 0x10,0000,0000,0000 == 0x100,0000,0000 pages 1048576 == 0x10,0000 == 0x100 pages This issue only affects the source memcg on 64 bit machines; the destination memcg counters are correct. So the rmdir case is not too important because such counters are soon disappearing with the entire memcg. But the memcg.force_empty and memory.move_charge_at_immigrate=1 cases are larger problems as the bogus counters are visible for the (possibly long) remaining life of the source memcg. The problem is due to memcg use of __this_cpu_from(.., -nr_pages), which is subtly wrong because it subtracts the unsigned int nr_pages (either -1 or -512 for THP) from a signed long percpu counter. When nr_pages=-1, -nr_pages=0xffffffff. On 64 bit machines stat->count[idx] is signed 64 bit. So memcg's attempt to simply decrement a count (e.g. from 1 to 0) boils down to: long count = 1 unsigned int nr_pages = 1 count += -nr_pages /* -nr_pages == 0xffff,ffff */ count is now 0x1,0000,0000 instead of 0 The fix is to subtract the unsigned page count rather than adding its negation. This only works once "percpu: fix this_cpu_sub() subtrahend casting for unsigneds" is applied to fix this_cpu_sub(). Signed-off-by: Greg Thelen <gthelen@google.com> Acked-by: Tejun Heo <tj@kernel.org> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 30 October 2013, 21:27:03 UTC
bd09d9a Greg Thelen 30 October 2013, 20:56:20 UTC percpu: fix this_cpu_sub() subtrahend casting for unsigneds this_cpu_sub() is implemented as negation and addition. This patch casts the adjustment to the counter type before negation to sign extend the adjustment. This helps in cases where the counter type is wider than an unsigned adjustment. An alternative to this patch is to declare such operations unsupported, but it seemed useful to avoid surprises. This patch specifically helps the following example: unsigned int delta = 1 preempt_disable() this_cpu_write(long_counter, 0) this_cpu_sub(long_counter, delta) preempt_enable() Before this change long_counter on a 64 bit machine ends with value 0xffffffff, rather than 0xffffffffffffffff. This is because this_cpu_sub(pcp, delta) boils down to this_cpu_add(pcp, -delta), which is basically: long_counter = 0 + 0xffffffff Also apply the same cast to: __this_cpu_sub() __this_cpu_sub_return() this_cpu_sub_return() All percpu_test.ko passes, especially the following cases which previously failed: l -= ui_one; __this_cpu_sub(long_counter, ui_one); CHECK(l, long_counter, -1); l -= ui_one; this_cpu_sub(long_counter, ui_one); CHECK(l, long_counter, -1); CHECK(l, long_counter, 0xffffffffffffffff); ul -= ui_one; __this_cpu_sub(ulong_counter, ui_one); CHECK(ul, ulong_counter, -1); CHECK(ul, ulong_counter, 0xffffffffffffffff); ul = this_cpu_sub_return(ulong_counter, ui_one); CHECK(ul, ulong_counter, 2); ul = __this_cpu_sub_return(ulong_counter, ui_one); CHECK(ul, ulong_counter, 1); Signed-off-by: Greg Thelen <gthelen@google.com> Acked-by: Tejun Heo <tj@kernel.org> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 30 October 2013, 21:27:03 UTC
3017f07 Chen LinX 30 October 2013, 20:56:18 UTC mm/pagewalk.c: fix walk_page_range() access of wrong PTEs When walk_page_range walk a memory map's page tables, it'll skip VM_PFNMAP area, then variable 'next' will to assign to vma->vm_end, it maybe larger than 'end'. In next loop, 'addr' will be larger than 'next'. Then in /proc/XXXX/pagemap file reading procedure, the 'addr' will growing forever in pagemap_pte_range, pte_to_pagemap_entry will access the wrong pte. BUG: Bad page map in process procrank pte:8437526f pmd:785de067 addr:9108d000 vm_flags:00200073 anon_vma:f0d99020 mapping: (null) index:9108d CPU: 1 PID: 4974 Comm: procrank Tainted: G B W O 3.10.1+ #1 Call Trace: dump_stack+0x16/0x18 print_bad_pte+0x114/0x1b0 vm_normal_page+0x56/0x60 pagemap_pte_range+0x17a/0x1d0 walk_page_range+0x19e/0x2c0 pagemap_read+0x16e/0x200 vfs_read+0x84/0x150 SyS_read+0x4a/0x80 syscall_call+0x7/0xb Signed-off-by: Liu ShuoX <shuox.liu@intel.com> Signed-off-by: Chen LinX <linx.z.chen@intel.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: <stable@vger.kernel.org> [3.10.x+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 30 October 2013, 21:27:03 UTC
c56b097 Russell King 30 October 2013, 14:16:16 UTC mm: list_lru: fix almost infinite loop causing effective livelock I've seen a fair number of issues with kswapd and other processes appearing to get stuck in v3.12-rc. Using sysrq-p many times seems to indicate that it gets stuck somewhere in list_lru_walk_node(), called from prune_icache_sb() and super_cache_scan(). I never seem to be able to trigger a calltrace for functions above that point. So I decided to add the following to super_cache_scan(): @@ -81,10 +81,14 @@ static unsigned long super_cache_scan(struct shrinker *shrink, inodes = list_lru_count_node(&sb->s_inode_lru, sc->nid); dentries = list_lru_count_node(&sb->s_dentry_lru, sc->nid); total_objects = dentries + inodes + fs_objects + 1; +printk("%s:%u: %s: dentries %lu inodes %lu total %lu\n", current->comm, current->pid, __func__, dentries, inodes, total_objects); /* proportion the scan between the caches */ dentries = mult_frac(sc->nr_to_scan, dentries, total_objects); inodes = mult_frac(sc->nr_to_scan, inodes, total_objects); +printk("%s:%u: %s: dentries %lu inodes %lu\n", current->comm, current->pid, __func__, dentries, inodes); +BUG_ON(dentries == 0); +BUG_ON(inodes == 0); /* * prune the dcache first as the icache is pinned by it, then @@ -99,7 +103,7 @@ static unsigned long super_cache_scan(struct shrinker *shrink, freed += sb->s_op->free_cached_objects(sb, fs_objects, sc->nid); } - +printk("%s:%u: %s: dentries %lu inodes %lu freed %lu\n", current->comm, current->pid, __func__, dentries, inodes, freed); drop_super(sb); return freed; } and shortly thereafter, having applied some pressure, I got this: update-apt-xapi:1616: super_cache_scan: dentries 25632 inodes 2 total 25635 update-apt-xapi:1616: super_cache_scan: dentries 1023 inodes 0 ------------[ cut here ]------------ Kernel BUG at c0101994 [verbose debug info unavailable] Internal error: Oops - BUG: 0 [#3] SMP ARM Modules linked in: fuse rfcomm bnep bluetooth hid_cypress CPU: 0 PID: 1616 Comm: update-apt-xapi Tainted: G D 3.12.0-rc7+ #154 task: daea1200 ti: c3bf8000 task.ti: c3bf8000 PC is at super_cache_scan+0x1c0/0x278 LR is at trace_hardirqs_on+0x14/0x18 Process update-apt-xapi (pid: 1616, stack limit = 0xc3bf8240) ... Backtrace: (super_cache_scan) from [<c00cd69c>] (shrink_slab+0x254/0x4c8) (shrink_slab) from [<c00d09a0>] (try_to_free_pages+0x3a0/0x5e0) (try_to_free_pages) from [<c00c59cc>] (__alloc_pages_nodemask+0x5) (__alloc_pages_nodemask) from [<c00e07c0>] (__pte_alloc+0x2c/0x13) (__pte_alloc) from [<c00e3a70>] (handle_mm_fault+0x84c/0x914) (handle_mm_fault) from [<c001a4cc>] (do_page_fault+0x1f0/0x3bc) (do_page_fault) from [<c001a7b0>] (do_translation_fault+0xac/0xb8) (do_translation_fault) from [<c000840c>] (do_DataAbort+0x38/0xa0) (do_DataAbort) from [<c00133f8>] (__dabt_usr+0x38/0x40) Notice that we had a very low number of inodes, which were reduced to zero my mult_frac(). Now, prune_icache_sb() calls list_lru_walk_node() passing that number of inodes (0) into that as the number of objects to scan: long prune_icache_sb(struct super_block *sb, unsigned long nr_to_scan, int nid) { LIST_HEAD(freeable); long freed; freed = list_lru_walk_node(&sb->s_inode_lru, nid, inode_lru_isolate, &freeable, &nr_to_scan); which does: unsigned long list_lru_walk_node(struct list_lru *lru, int nid, list_lru_walk_cb isolate, void *cb_arg, unsigned long *nr_to_walk) { struct list_lru_node *nlru = &lru->node[nid]; struct list_head *item, *n; unsigned long isolated = 0; spin_lock(&nlru->lock); restart: list_for_each_safe(item, n, &nlru->list) { enum lru_status ret; /* * decrement nr_to_walk first so that we don't livelock if we * get stuck on large numbesr of LRU_RETRY items */ if (--(*nr_to_walk) == 0) break; So, if *nr_to_walk was zero when this function was entered, that means we're wanting to operate on (~0UL)+1 objects - which might as well be infinite. Clearly this is not correct behaviour. If we think about the behaviour of this function when *nr_to_walk is 1, then clearly it's wrong - we decrement first and then test for zero - which results in us doing nothing at all. A post-decrement would give the desired behaviour - we'd try to walk one object and one object only if *nr_to_walk were one. It also gives the correct behaviour for zero - we exit at this point. Fixes: 5cedf721a7cd ("list_lru: fix broken LRU_RETRY behaviour") Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Dave Chinner <dchinner@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Andrew Morton <akpm@linux-foundation.org> [ Modified to make sure we never underflow the count: this function gets called in a loop, so the 0 -> ~0ul transition is dangerous - Linus ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 30 October 2013, 19:57:46 UTC
ced5d6b Linus Torvalds 30 October 2013, 19:29:06 UTC Merge tag 'tty-3.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull serial fixes from Greg KH: "Here are 3 tiny fixes that are needed for 3.12-final for some serial drivers. One of them is a revert of a broken patch, and two others are fixes for reported bugs. All of these have been in linux-next for a while, I forgot I had not sent them to you yet, my fault" (Actually, Greg, you _had_ sent two of the three, so this pulls in just one actual new fix) * tag 'tty-3.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: tty/serial: at91: fix uart/usart selection for older products 30 October 2013, 19:29:06 UTC
b8cab70 Linus Torvalds 30 October 2013, 19:27:12 UTC Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux Pull drm fixes from Dave Airlie: "Mainly Intel regression fixes and quirks, along with a simple one liner to fix rendernodes ioctl access (off by default, but testers want to test it)" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm: allow DRM_IOCTL_VERSION on render-nodes drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb drm/i915: No LVDS hardware on Intel D410PT and D425KT drm/i915/dp: workaround BIOS eDP bpp clamping issue drm/i915: Add HSW CRT output readout support drm/i915: Add support for pipe_bpp readout 30 October 2013, 19:27:12 UTC
182b4fd Linus Torvalds 30 October 2013, 19:26:29 UTC Merge tag 'sound-3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A few small HD-audio regression fixes, mostly for stable kernels, too" * tag 'sound-3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda - Fix silent headphone on Thinkpads with AD1984A codec ALSA: hda - Add missing initial vmaster hook at build_controls callback ALSA: hda - Fix unbalanced runtime PM refcount after S3/S4 30 October 2013, 19:26:29 UTC
96d33b0 Linus Torvalds 30 October 2013, 19:25:15 UTC Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm Pull KVM fixes from Paolo Bonzini: "Fixes for the 3.12 debugfs problem - removing the duplicate directory name, and using a better the error code" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: use a more sensible error number when debugfs directory creation fails KVM: Fix modprobe failure for kvm_intel/kvm_amd 30 October 2013, 19:25:15 UTC
a8b3365 Dan Carpenter 29 October 2013, 20:01:43 UTC Staging: sb105x: info leak in mp_get_count() The icount.reserved[] array isn't initialized so it leaks stack information to userspace. Reported-by: Nico Golde <nico@ngolde.de> Reported-by: Fabian Yamaguchi <fabs@goesec.de> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 30 October 2013, 19:24:50 UTC
8d1e722 Dan Carpenter 29 October 2013, 20:01:11 UTC Staging: bcm: info leak in ioctl The DevInfo.u32Reserved[] array isn't initialized so it leaks kernel information to user space. Reported-by: Nico Golde <nico@ngolde.de> Reported-by: Fabian Yamaguchi <fabs@goesec.de> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 30 October 2013, 19:24:49 UTC
b5e2f33 Dan Carpenter 29 October 2013, 20:00:15 UTC staging: wlags49_h2: buffer overflow setting station name We need to check the length parameter before doing the memcpy(). I've actually changed it to strlcpy() as well so that it's NUL terminated. You need CAP_NET_ADMIN to trigger these so it's not the end of the world. Reported-by: Nico Golde <nico@ngolde.de> Reported-by: Fabian Yamaguchi <fabs@goesec.de> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 30 October 2013, 19:24:49 UTC
f856567 Dan Carpenter 29 October 2013, 19:11:06 UTC aacraid: missing capable() check in compat ioctl In commit d496f94d22d1 ('[SCSI] aacraid: fix security weakness') we added a check on CAP_SYS_RAWIO to the ioctl. The compat ioctls need the check as well. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 30 October 2013, 19:24:49 UTC
c2c65cd Dan Carpenter 29 October 2013, 19:07:47 UTC staging: ozwpan: prevent overflow in oz_cdev_write() We need to check "count" so we don't overflow the ei->data buffer. Reported-by: Nico Golde <nico@ngolde.de> Reported-by: Fabian Yamaguchi <fabs@goesec.de> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 30 October 2013, 19:24:49 UTC
201f99f Dan Carpenter 29 October 2013, 19:06:04 UTC uml: check length in exitcode_proc_write() We don't cap the size of buffer from the user so we could write past the end of the array here. Only root can write to this file. Reported-by: Nico Golde <nico@ngolde.de> Reported-by: Fabian Yamaguchi <fabs@goesec.de> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 30 October 2013, 19:24:49 UTC
ab12259 Mika Westerberg 30 October 2013, 12:40:36 UTC Revert "ACPI / hotplug / PCI: Avoid doing too much for spurious notifies" Commit 2dc4128 (ACPI / hotplug / PCI: Avoid doing too much for spurious notifies) changed the enable_slot() to check return value of pci_scan_slot() and if it is zero return early from the function. It means that there were no new devices in this particular slot. However, if a device appeared deeper in the hierarchy the code now ignores it causing things like Thunderbolt chaining fail to recognize new devices. The problem with Alex Williamson's machine was solved with commit a47d8c8 (ACPI / hotplug / PCI: Avoid parent bus rescans on spurious device checks) and hence we should be able to restore the original functionality that we always rescan on bus check notification. On a device check notification we still check what acpiphp_rescan_slot() returns and on zero bail out early. Fixes: 2dc41281b1d1 (ACPI / hotplug / PCI: Avoid doing too much for spurious notifies) Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 30 October 2013, 14:28:52 UTC
59612d1 Rafael J. Wysocki 29 October 2013, 22:43:08 UTC Revert "select: use freezable blocking call" This reverts commit 9745cdb36da8 (select: use freezable blocking call) that triggers problems during resume from suspend to RAM on Paul Bolle's 32-bit x86 machines. Paul says: Ever since I tried running (release candidates of) v3.11 on the two working i686s I still have lying around I ran into issues on resuming from suspend. Reverting 9745cdb36da8 (select: use freezable blocking call) resolves those issues. Resuming from suspend on i686 on (release candidates of) v3.11 and later triggers issues like: traps: systemd[1] general protection ip:b738e490 sp:bf882fc0 error:0 in libc-2.16.so[b731c000+1b0000] and traps: rtkit-daemon[552] general protection ip:804d6e5 sp:b6cb32f0 error:0 in rtkit-daemon[8048000+d000] Once I hit the systemd error I can only get out of the mess that the system is at that point by power cycling it. Since we are reverting another freezer-related change causing similar problems to happen, this one should be reverted as well. References: https://lkml.org/lkml/2013/10/29/583 Reported-by: Paul Bolle <pebolle@tiscali.nl> Fixes: 9745cdb36da8 (select: use freezable blocking call) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 3.11+ <stable@vger.kernel.org> # 3.11+ 30 October 2013, 14:28:35 UTC
c511851 Rafael J. Wysocki 29 October 2013, 12:12:56 UTC Revert "epoll: use freezable blocking call" This reverts commit 1c441e921201 (epoll: use freezable blocking call) which is reported to cause user space memory corruption to happen after suspend to RAM. Since it appears to be extremely difficult to root cause this problem, it is best to revert the offending commit and try to address the original issue in a better way later. References: https://bugzilla.kernel.org/show_bug.cgi?id=61781 Reported-by: Natrio <natrio@list.ru> Reported-by: Jeff Pohlmeyer <yetanothergeek@gmail.com> Bisected-by: Leo Wolf <jclw@ymail.com> Fixes: 1c441e921201 (epoll: use freezable blocking call) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 3.11+ <stable@vger.kernel.org> # 3.11+ 30 October 2013, 14:27:53 UTC
0c8eb04 Paolo Bonzini 30 October 2013, 11:12:13 UTC KVM: use a more sensible error number when debugfs directory creation fails I don't know if this was due to cut and paste, or somebody was really using a D20 to pick the error code for kvm_init_debugfs as suggested by Linus (EFAULT is 14, so the possibility cannot be entirely ruled out). In any case, this patch fixes it. Reported-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> 30 October 2013, 11:15:34 UTC
d780a31 Tim Gardner 29 October 2013, 15:13:54 UTC KVM: Fix modprobe failure for kvm_intel/kvm_amd The x86 specific kvm init creates a new conflicting debugfs directory which causes modprobe issues with kvm_intel and kvm_amd. For example, sudo modprobe kvm_amd modprobe: ERROR: could not insert 'kvm_amd': Bad address The simplest fix is to just rename the directory. The following KVM config options are set: CONFIG_KVM_GUEST=y CONFIG_KVM_DEBUG_FS=y CONFIG_HAVE_KVM=y CONFIG_HAVE_KVM_IRQCHIP=y CONFIG_HAVE_KVM_IRQ_ROUTING=y CONFIG_HAVE_KVM_EVENTFD=y CONFIG_KVM_APIC_ARCHITECTURE=y CONFIG_KVM_MMIO=y CONFIG_KVM_ASYNC_PF=y CONFIG_HAVE_KVM_MSI=y CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y CONFIG_KVM=m CONFIG_KVM_INTEL=m CONFIG_KVM_AMD=m CONFIG_KVM_DEVICE_ASSIGNMENT=y Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Gleb Natapov <gleb@redhat.com> Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com> Cc: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> [Change debugfs directory name. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> 30 October 2013, 11:10:42 UTC
3d3b78c David Herrmann 28 October 2013, 09:55:49 UTC drm: allow DRM_IOCTL_VERSION on render-nodes DRM_IOCTL_VERSION is a reliable way to get the driver-name and version information. It's not related to the interface-version (SET_VERSION ioctl) so we can safely enable it on render-nodes. Note that gbm uses udev-BUSID to load the correct mesa driver. However, the VERSION ioctl should be the more reliable way to do this (in case we add new DRM-bus drivers which have no BUSID or similar). Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com> 30 October 2013, 04:41:56 UTC
2f2632f Dave Airlie 30 October 2013, 02:30:12 UTC Merge tag 'drm-intel-fixes-2013-10-29' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Regression and warn fixes for i915. * tag 'drm-intel-fixes-2013-10-29' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb drm/i915: No LVDS hardware on Intel D410PT and D425KT drm/i915/dp: workaround BIOS eDP bpp clamping issue drm/i915: Add HSW CRT output readout support drm/i915: Add support for pipe_bpp readout 30 October 2013, 02:30:12 UTC
7314e61 Linus Torvalds 29 October 2013, 17:21:34 UTC Fix a few incorrectly checked [io_]remap_pfn_range() calls Nico Golde reports a few straggling uses of [io_]remap_pfn_range() that really should use the vm_iomap_memory() helper. This trivially converts two of them to the helper, and comments about why the third one really needs to continue to use remap_pfn_range(), and adds the missing size check. Reported-by: Nico Golde <nico@ngolde.de> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org. 29 October 2013, 17:21:34 UTC
f9ec2e6 Linus Torvalds 29 October 2013, 15:36:50 UTC Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf tooling fixes from Ingo Molnar: "This contains five tooling fixes: - fix a remaining mmap2 assumption which resulted in perf top output breakage - fix mmap ring-buffer processing bug that corrupts data - fix for a severe python scripting memory leak - fix broken (and user-visible) -g option handling - fix stdio output The diffstat size is larger than what we'd like to see this late :-/" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf tools: Fixup mmap event consumption perf top: Split -G and --call-graph perf record: Split -g and --call-graph perf hists: Add color overhead for stdio output buffer perf tools: Fix up /proc/PID/maps parsing perf script python: Fix mem leak due to missing Py_DECREFs on dict entries 29 October 2013, 15:36:50 UTC
2a999aa Linus Torvalds 29 October 2013, 15:33:36 UTC Kconfig: make KOBJECT_RELEASE debugging require timer debugging Without the timer debugging, the delayed kobject release will just result in undebuggable oopses if it triggers any latent bugs. That doesn't actually help debugging at all. So make DEBUG_KOBJECT_RELEASE depend on DEBUG_OBJECTS_TIMERS to avoid having people enable one without the other. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 29 October 2013, 15:33:36 UTC
1fbc0d7 Daniel Vetter 29 October 2013, 11:04:08 UTC drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb Originally I've thought that this is leftover hw state dirt from the BIOS. But after way too much helpless flailing around on my part I've noticed that the actual bug is when we change the state of an already active pipe. For example when we change the fdi lines from 2 to 3 without switching off outputs in-between we'll never see the crucial on->off transition in the ->modeset_global_resources hook the current logic relies on. Patch version 2 got this right by instead also checking whether the pipe is indeed active. But that in turn broke things when pipes have been turned off through dpms since the bifurcate enabling is done in the ->crtc_mode_set callback. To address this issues discussed with Ville in the patch review move the setting of the bifurcate bit into the ->crtc_enable hook. That way we won't wreak havoc with this state when userspace puts all other outputs into dpms off state. This also moves us forward with our overall goal to unify the modeset and dpms on paths (which we need to have to allow runtime pm in the dpms off state). Unfortunately this requires us to move the bifurcate helpers around a bit. Also update the commit message, I've misanalyzed the bug rather badly. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70507 Tested-by: Jan-Michael Brummer <jan.brummer@tabos.org> Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> 29 October 2013, 12:52:56 UTC
0255d49 Mel Gorman 07 October 2013, 10:28:47 UTC mm: Account for a THP NUMA hinting update as one PTE update A THP PMD update is accounted for as 512 pages updated in vmstat. This is large difference when estimating the cost of automatic NUMA balancing and can be misleading when comparing results that had collapsed versus split THP. This patch addresses the accounting issue. Signed-off-by: Mel Gorman <mgorman@suse.de> Reviewed-by: Rik van Riel <riel@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Cc: <stable@kernel.org> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1381141781-10992-10-git-send-email-mgorman@suse.de Signed-off-by: Ingo Molnar <mingo@kernel.org> 29 October 2013, 10:38:17 UTC
3f926ab Mel Gorman 07 October 2013, 10:28:46 UTC mm: Close races between THP migration and PMD numa clearing THP migration uses the page lock to guard against parallel allocations but there are cases like this still open Task A Task B --------------------- --------------------- do_huge_pmd_numa_page do_huge_pmd_numa_page lock_page mpol_misplaced == -1 unlock_page goto clear_pmdnuma lock_page mpol_misplaced == 2 migrate_misplaced_transhuge pmd = pmd_mknonnuma set_pmd_at During hours of testing, one crashed with weird errors and while I have no direct evidence, I suspect something like the race above happened. This patch extends the page lock to being held until the pmd_numa is cleared to prevent migration starting in parallel while the pmd_numa is being cleared. It also flushes the old pmd entry and orders pagetable insertion before rmap insertion. Signed-off-by: Mel Gorman <mgorman@suse.de> Reviewed-by: Rik van Riel <riel@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Cc: <stable@kernel.org> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1381141781-10992-9-git-send-email-mgorman@suse.de Signed-off-by: Ingo Molnar <mingo@kernel.org> 29 October 2013, 10:38:05 UTC
c61109e Mel Gorman 07 October 2013, 10:28:45 UTC mm: numa: Sanitize task_numa_fault() callsites There are three callers of task_numa_fault(): - do_huge_pmd_numa_page(): Accounts against the current node, not the node where the page resides, unless we migrated, in which case it accounts against the node we migrated to. - do_numa_page(): Accounts against the current node, not the node where the page resides, unless we migrated, in which case it accounts against the node we migrated to. - do_pmd_numa_page(): Accounts not at all when the page isn't migrated, otherwise accounts against the node we migrated towards. This seems wrong to me; all three sites should have the same sementaics, furthermore we should accounts against where the page really is, we already know where the task is. So modify all three sites to always account; we did after all receive the fault; and always account to where the page is after migration, regardless of success. They all still differ on when they clear the PTE/PMD; ideally that would get sorted too. Signed-off-by: Mel Gorman <mgorman@suse.de> Reviewed-by: Rik van Riel <riel@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Cc: <stable@kernel.org> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1381141781-10992-8-git-send-email-mgorman@suse.de Signed-off-by: Ingo Molnar <mingo@kernel.org> 29 October 2013, 10:37:52 UTC
587fe58 Mel Gorman 07 October 2013, 10:28:44 UTC mm: Prevent parallel splits during THP migration THP migrations are serialised by the page lock but on its own that does not prevent THP splits. If the page is split during THP migration then the pmd_same checks will prevent page table corruption but the unlock page and other fix-ups potentially will cause corruption. This patch takes the anon_vma lock to prevent parallel splits during migration. Signed-off-by: Mel Gorman <mgorman@suse.de> Reviewed-by: Rik van Riel <riel@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Cc: <stable@kernel.org> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1381141781-10992-7-git-send-email-mgorman@suse.de Signed-off-by: Ingo Molnar <mingo@kernel.org> 29 October 2013, 10:37:39 UTC
42836f5 Mel Gorman 07 October 2013, 10:28:43 UTC mm: Wait for THP migrations to complete during NUMA hinting faults The locking for migrating THP is unusual. While normal page migration prevents parallel accesses using a migration PTE, THP migration relies on a combination of the page_table_lock, the page lock and the existance of the NUMA hinting PTE to guarantee safety but there is a bug in the scheme. If a THP page is currently being migrated and another thread traps a fault on the same page it checks if the page is misplaced. If it is not, then pmd_numa is cleared. The problem is that it checks if the page is misplaced without holding the page lock meaning that the racing thread can be migrating the THP when the second thread clears the NUMA bit and faults a stale page. This patch checks if the page is potentially being migrated and stalls using the lock_page if it is potentially being migrated before checking if the page is misplaced or not. Signed-off-by: Mel Gorman <mgorman@suse.de> Reviewed-by: Rik van Riel <riel@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Cc: <stable@kernel.org> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1381141781-10992-6-git-send-email-mgorman@suse.de Signed-off-by: Ingo Molnar <mingo@kernel.org> 29 October 2013, 10:37:19 UTC
1dd49bf Mel Gorman 07 October 2013, 10:28:42 UTC mm: numa: Do not account for a hinting fault if we raced If another task handled a hinting fault in parallel then do not double account for it. Signed-off-by: Mel Gorman <mgorman@suse.de> Reviewed-by: Rik van Riel <riel@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Cc: <stable@kernel.org> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1381141781-10992-5-git-send-email-mgorman@suse.de Signed-off-by: Ingo Molnar <mingo@kernel.org> 29 October 2013, 10:37:05 UTC
cd65718 Ingo Molnar 29 October 2013, 08:06:07 UTC Merge tag 'perf-urgent-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent Pull perf/urgent fixes from Arnaldo Carvalho de Melo: * Add color overhead for stdio output buffer, which fixes --stdio output being chopped up on the hot (red) entries, fix from Jiri Olsa. * Get 'perf record -g -a sleep 1' working again, removing the need for -- separating perf options from the workload, restoring ages old behaviour, fix from Jiri Olsa. More patches allowing ~/.perfconfig setting up of default callchain collecting method ("fp" or "dwarf") left for next merge window. * Fixup mmap event consumption, where we were acking the consumption by writing the tail before actually accessing the event, which could lead to using overwritten records in things like 'perf record --call-graph'. From Zhouyi Zhou. Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 29 October 2013, 08:06:07 UTC
c9ca72f Linus Torvalds 28 October 2013, 23:58:05 UTC Merge tag 'xtensa-next-20131015' of git://github.com/czankel/xtensa-linux Pull Xtensa patchset from Chris Zankel: "The main patch fixes a bug that can cause a kernel panic, and was introduced in rc1. The other two have been discovered by a uclibc test and 'coccinelle'" * tag 'xtensa-next-20131015' of git://github.com/czankel/xtensa-linux: xtensa: Cocci spatch "noderef" xtensa: don't use alternate signal stack on threads xtensa: fix fast_syscall_spill_registers_fixup 28 October 2013, 23:58:05 UTC
5d914a9 Linus Torvalds 28 October 2013, 23:57:13 UTC Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "This is a set of four patches that revert functionality introduced in the merge window to sg. The locking changes turned out to introduce this bug: [ 205.372901] [ BUG: lock held when returning to user space! ] [...] [ 205.373285] #0: (&sdp->o_sem){.+.+..}, at: [<ffffffff8161e650>] sg_open+0x3a0/0x4d0 The fix is large, so at this late stage we'd like to revert the functionality and start again in the next merge window" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: [SCSI] Revert "sg: use rwsem to solve race during exclusive open" [SCSI] Revert "sg: no need sg_open_exclusive_lock" [SCSI] Revert "sg: checking sdp->detached isn't protected when open" [SCSI] Revert "sg: push file descriptor list locking down to per-device locking" 28 October 2013, 23:57:13 UTC
8e50d38 Zhouyi Zhou 24 October 2013, 07:43:33 UTC perf tools: Fixup mmap event consumption The tail position of the event buffer should only be modified after actually use that event. If not the event buffer could be invalid before use, and segment fault occurs when invoking perf top -G. Signed-off-by: Zhouyi Zhou <yizhouzhou@ict.ac.cn> Cc: David Ahern <dsahern@gmail.com> Cc: Zhouyi Zhou <yizhouzhou@ict.ac.cn> Link: http://lkml.kernel.org/r/1382600613-32177-1-git-send-email-zhouzhouyi@gmail.com [ Simplified the logic using exit gotos and renamed write_tail method to mmap_consume ] Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 28 October 2013, 19:06:00 UTC
ae779a6 Jiri Olsa 26 October 2013, 14:25:34 UTC perf top: Split -G and --call-graph Splitting -G and --call-graph for record command, so we could use '-G' with no option. The '-G' option now takes NO argument and enables the configured unwind method, which is currently the frame pointers method. It will be possible to configure unwind method via config file in upcoming patches. All current '-G' arguments is overtaken by --call-graph option. NOTE: The documentation for top --call-graph option was wrongly copied from report command. Signed-off-by: Jiri Olsa <jolsa@redhat.com> Tested-by: David Ahern <dsahern@gmail.com> Tested-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: David Ahern <dsahern@gmail.com> Acked-by: Ingo Molnar <mingo@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: David Ahern <dsahern@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1382797536-32303-3-git-send-email-jolsa@redhat.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 28 October 2013, 19:06:00 UTC
09b0fd4 Jiri Olsa 26 October 2013, 14:25:33 UTC perf record: Split -g and --call-graph Splitting -g and --call-graph for record command, so we could use '-g' with no option. The '-g' option now takes NO argument and enables the configured unwind method, which is currently the frame pointers method. It will be possible to configure unwind method via config file in upcoming patches. All current '-g' arguments is overtaken by --call-graph option. Signed-off-by: Jiri Olsa <jolsa@redhat.com> Tested-by: David Ahern <dsahern@gmail.com> Tested-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: David Ahern <dsahern@gmail.com> Acked-by: Ingo Molnar <mingo@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: David Ahern <dsahern@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1382797536-32303-2-git-send-email-jolsa@redhat.com [ reordered -g/--call-graph on --help and expanded the man page according to comments by David Ahern and Namhyung Kim ] Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 28 October 2013, 19:05:59 UTC
9754c4f Jiri Olsa 25 October 2013, 11:24:53 UTC perf hists: Add color overhead for stdio output buffer Following commit tightened up the buffer size for output to strict width of used format columns: 99cf666 perf hists: Fix formatting of long symbol names This works fine until you hit color overhead output which places extra bytes into output buffer. We need to account for color overhead in the output buffer. Adding maximum color byte size to the output buffer size. Signed-off-by: Jiri Olsa <jolsa@redhat.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1382700293-1803-1-git-send-email-jolsa@redhat.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 28 October 2013, 19:05:59 UTC
645378d Rob Pearce 27 October 2013, 16:13:42 UTC drm/i915: No LVDS hardware on Intel D410PT and D425KT The Intel D410PT(LW) and D425KT Mini-ITX desktop boards both show up as having LVDS but the hardware is not populated. This patch adds them to the list of such systems. Patch is against 3.11.4 v2: Patch revised to match the D425KT exactly as the D425KTW does have LVDS. According to Intel's documentation, the D410PTL and D410PLTW don't. Signed-off-by: Rob Pearce <rob@flitspace.org.uk> Cc: stable@vger.kernel.org [danvet: Pimp commit message to my liking and add cc: stable.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> 28 October 2013, 16:48:30 UTC
c6cd2ee Jani Nikula 21 October 2013, 07:52:07 UTC drm/i915/dp: workaround BIOS eDP bpp clamping issue This isn't a real fix to the problem, but rather a stopgap measure while trying to find a proper solution. There are several laptops out there that fail to light up the eDP panel in UEFI boot mode. They seem to be mostly IVB machines, including but apparently not limited to Dell XPS 13, Asus TX300, Asus UX31A, Asus UX32VD, Acer Aspire S7. They seem to work in CSM or legacy boot. The difference between UEFI and CSM is that the BIOS provides a different VBT to the kernel. The UEFI VBT typically specifies 18 bpp and 1.62 GHz link for eDP, while CSM VBT has 24 bpp and 2.7 GHz link. We end up clamping to 18 bpp in UEFI mode, which we can fit in the 1.62 Ghz link, and for reasons yet unknown fail to light up the panel. Dithering from 24 to 18 bpp itself seems to work; if we use 18 bpp with 2.7 GHz link, the eDP panel lights up. So essentially this is a link speed issue, and *not* a bpp clamping issue. The bug raised its head since commit 657445fe8660100ad174600ebfa61536392b7624 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat May 4 10:09:18 2013 +0200 Revert "drm/i915: revert eDP bpp clamping code changes" which started clamping bpp *before* computing the link requirements, and thus affecting the required bandwidth. Clamping after the computations kept the link at 2.7 GHz. Even though the BIOS tells us to use 18 bpp through the VBT, it happily boots up at 24 bpp and 2.7 GHz itself! Use this information to selectively ignore the VBT provided value. We can't ignore the VBT eDP bpp altogether, as there are other laptops that do require the clamping to be used due to EDID reporting higher bpp than the panel can support. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59841 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67950 Tested-by: Ulf Winkelvos <ulf@winkelvos.de> Tested-by: jkp <jkp@iki.fi> CC: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> 28 October 2013, 16:48:30 UTC
7195a50 Ville Syrjälä 24 September 2013, 11:24:05 UTC drm/i915: Add HSW CRT output readout support Call intel_ddi_get_config() to get the pipe_bpp settings from DDI. The sync polarity settings from DDI are irrelevant for CRT output, so override them with data from the ADPA register. Note: This is already merged in drm-intel-next-queued as commit 6801c18c0a43386bb44712cbc028a7e05adb9f0d Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Tue Sep 24 14:24:05 2013 +0300 drm/i915: Add HSW CRT output readout support but is required for the following edp bpp bugfix. v2: Extract intel_crt_get_flags() Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69691 Tested-by: Qingshuai Tian <qingshuai.tian@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> 28 October 2013, 16:48:24 UTC
d17cccb Ingo Molnar 28 October 2013, 14:56:50 UTC Merge tag 'perf-urgent-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent Pull perf/urgent fixes from Arnaldo Carvalho de Melo: * Fix up /proc/PID/maps parsing, where perfectly fine mmap entries were being trown away when synthesizing PERF_RECORD_MMAP for preexisting threads, prevenging symbol resolution to work for those threads, broken in the MMAP2 removal. Reported and pinpointed by Markus Trippelsdorf, * Fix mem leak in the python 'perf script' backend, due to missing Py_DECREFs on dict entries, fix from Joseph Schuchart. Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> 28 October 2013, 14:56:50 UTC
2fd869f Arnaldo Carvalho de Melo 28 October 2013, 12:38:12 UTC perf tools: Fix up /proc/PID/maps parsing When introducing support for MMAP2 we considered more parts of each map representation in /proc/PID/maps, and when disabling it we forgot to reduce the number of expected parsed/assigned entries in the sscanf call, fix it to expect the right number of desired fields, 5. Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de> Based-on-a-patch-by: Markus Trippelsdorf <markus@trippelsdorf.de> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-vrbo1wik997ahjzl1chm3bdm@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 28 October 2013, 12:38:12 UTC
4f56d12 Ville Syrjälä 21 October 2013, 07:52:06 UTC drm/i915: Add support for pipe_bpp readout On CTG+ read out the pipe bpp setting from hardware and fill it into pipe config. Also check it appropriately. v2: Don't do the pipe_bpp extraction inside the PCH only code block on ILK+. Avoid the PIPECONF read as we already have read it for the PIPECONF_EANBLE check. Note: This is already in drm-intel-next-queued as commit 42571aefafb1d330ef84eb29418832f72e7dfb4c Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Sep 6 23:29:00 2013 +0300 drm/i915: Add support for pipe_bpp readout but is needed for the following bugfix. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> 28 October 2013, 08:34:37 UTC
959f585 Linus Torvalds 27 October 2013, 23:12:03 UTC Linux 3.12-rc7 27 October 2013, 23:12:03 UTC
a2ff820 Linus Torvalds 27 October 2013, 17:45:00 UTC Merge branch 'parisc-3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc fix from Helge Deller: "This is a 2-line patch to save the CPU register which holds our task thread info pointer before calling a firmware function and then to restore it again afterwards. This is necessary because on some 64bit machines the high-order 32bits are being clobbered by the firmware call, and thus we failed to bring up secondary CPUs (and instead crashed the kernel) in some situations eg if we had more than 4GB RAM. This patch fixes a bug which has been since ever in the parisc linux kernel and which prevented some people to use a 64bit kernel" * 'parisc-3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Do not crash 64bit SMP kernels on machines with >= 4GB RAM 27 October 2013, 17:45:00 UTC
aff22d3 Linus Torvalds 27 October 2013, 17:29:25 UTC Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fix from Ingo Molnar: "This tree contains a clockevents regression fix for certain ARM subarchitectures" * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: clockevents: Sanitize ticks to nsec conversion 27 October 2013, 17:29:25 UTC
e2756f5 Linus Torvalds 27 October 2013, 17:28:35 UTC Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fixes from Ingo Molnar: "The tree contains three fixes: - Two tooling fixes - Reversal of the new 'MMAP2' extended mmap record ABI, introduced in this merge window. (Patches were proposed to fix it but it was all a bit late and we felt it's safer to just delay the ABI one more kernel release and do it right)" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf: Disable PERF_RECORD_MMAP2 support perf scripting perl: Fix build error on Fedora 12 perf probe: Fix to initialize fname always before use it 27 October 2013, 17:28:35 UTC
1c99ca4 Linus Torvalds 27 October 2013, 17:18:15 UTC Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull locking fix from Ingo Molnar: "This tree fixes a boot crash in CONFIG_DEBUG_MUTEXES=y kernels, on kernels built with GCC 3.x (there are still such distros)" Side note: it's not just a fix for old gcc versions, it's also removing an incredibly broken/subtle check that LLVM had issues with, and that made no sense. * 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: mutex: Avoid gcc version dependent __builtin_constant_p() usage 27 October 2013, 17:18:15 UTC
acda24c Linus Torvalds 27 October 2013, 17:16:33 UTC Merge git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending Pull SCSI target fixes from Nicholas Bellinger: "Here are the outstanding target pending fixes for v3.12-rc7. This includes a number of EXTENDED_COPY related fixes as a result of Thomas and Doug's continuing testing and feedback. Also included is an important vhost/scsi fix that addresses a long standing issue where the 'write' parameter for get_user_pages_fast() was incorrectly set for virtio-scsi WRITEs -> DMA_TO_DEVICE, and not for virtio-scsi READs -> DMA_FROM_DEVICE. This resulted in random userspace segfaults and other unpleasantness on KVM host, and unfortunately has been an issue since the initial merge of vhost/scsi in v3.6. This patch is CC'ed to stable, along with two other less critical items" * git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending: vhost/scsi: Fix incorrect usage of get_user_pages_fast write parameter target/pscsi: fix return value check target: Fail XCOPY for non matching source + destination block_size target: Generate failure for XCOPY I/O with non-zero scsi_status target: Add missing XCOPY I/O operation sense_buffer iser-target: check device before dereferencing its variable target: Return an error for WRITE SAME with ANCHOR==1 target: Fix assignment of LUN in tracepoints target: Reject EXTENDED_COPY when emulate_3pc is disabled target: Allow non zero ListID in EXTENDED_COPY parameter list target: Make target_do_xcopy failures return INVALID_PARAMETER_LIST 27 October 2013, 17:16:33 UTC
63e6560 Linus Torvalds 27 October 2013, 17:13:03 UTC Merge branch 'fixes' of git://git.infradead.org/users/vkoul/slave-dma Pull slave-dmaengine fixes from Vinod Koul: "Here is the late fixes pull request for dmaengine while you fly back from KS. We have a new dmaengine ML hosted by vger so a patch for that along with addition of Dave as driver mainatainer for ioat. Other fixes are memeory leak fixes on edma driver, small fixes on rcar-hpbdma driver by Sergei" * 'fixes' of git://git.infradead.org/users/vkoul/slave-dma: dmaengine: edma: fix another memory leak dma: edma: Fix memory leak MAINTAINERS: add to ioatdma maintainer list MAINTAINERS: add the new dmaengine mailing list 27 October 2013, 17:13:03 UTC
54e181e Helge Deller 26 October 2013, 21:19:25 UTC parisc: Do not crash 64bit SMP kernels on machines with >= 4GB RAM Since the beginning of the parisc-linux port, sometimes 64bit SMP kernels were not able to bring up other CPUs than the monarch CPU and instead crashed the kernel. The reason was unclear, esp. since it involved various machines (e.g. J5600, J6750 and SuperDome). Testing showed, that those crashes didn't happened when less than 4GB were installed, or if a 32bit Linux kernel was booted. In the end, the fix for those SMP problems is trivial: During the early phase of the initialization of the CPUs, including the monarch CPU, the PDC_PSW firmware function to enable WIDE (=64bit) mode is called. It's documented that this firmware function may clobber various registers, and one one of those possibly clobbered registers is %cr30 which holds the task thread info pointer. Now, if %cr30 would always have been clobbered, then this bug would have been detected much earlier. But lots of testing finally showed, that - at least for %cr30 - on some machines only the upper 32bits of the 64bit register suddenly turned zero after the firmware call. So, after finding the root cause, the explanation for the various crashes became clear: - On 32bit SMP Linux kernels all upper 32bit were zero, so we didn't faced this problem. - Monarch CPUs in 64bit mode always booted sucessfully, because the inital task thread info pointer was below 4GB. - Secondary CPUs booted sucessfully on machines with less than 4GB RAM because the upper 32bit were zero anyay. - Secondary CPus failed to boot if we had more than 4GB RAM and the task thread info pointer was located above the 4GB boundary. Finally, the patch to fix this problem is trivial by saving the %cr30 register before the firmware call and restoring it afterwards. Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: John David Anglin <dave.anglin@bell.net> Cc: <stable@vger.kernel.org> # 2.6.12+ Signed-off-by: Helge Deller <deller@gmx.de> 27 October 2013, 14:58:44 UTC
20582e3 Linus Torvalds 26 October 2013, 03:38:47 UTC Merge tag 'pm+acpi-3.12-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI and power management fixes from "These fix two bugs in the intel_pstate driver, a hibernate bug leading to nasty resume failures sometimes and acpi-cpufreq initialization bug that causes problems to happen during module unload when intel_pstate is in use. Specifics: - Fix for rounding errors in intel_pstate causing CPU utilization to be underestimated from Brennan Shacklett. - intel_pstate fix to always use the correct max pstate value when computing the min pstate from Dirk Brandewie. - Hibernation fix for deadlocking resume in cases when the probing of the device containing the image is deferred from Russ Dill. - acpi-cpufreq fix to prevent the module from staying in memory when the driver cannot be registered and then attempting to unregister things that have never been registered on exit" * tag 'pm+acpi-3.12-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: acpi-cpufreq: Fail initialization if driver cannot be registered PM / hibernate: Move software_resume to late_initcall_sync intel_pstate: Correct calculation of min pstate value intel_pstate: Improve accuracy by not truncating until final result 26 October 2013, 03:38:47 UTC
1ac3293 Takashi Iwai 25 October 2013, 22:24:14 UTC ALSA: hda - Fix silent headphone on Thinkpads with AD1984A codec AD1984A codec has a couple of pins with EAPD controls, and the generic codec driver tries to turn each of them on/off depending on the pin active state. However, Thinkpads seem to use EAPD of the speaker pin as a master EAPD for controlling the mute of all outputs, including the headphone. This results in the dead headphone output via the headphone plugging because it mutes the speaker and turns off EAPD. The fix is to simply add spec->gen.keep_on_eapd flag. [This is a regression fix on 3.12 where we moved the AD codec parser to the generic parser. 3.11 and earlier didn't show this problem because still static quirks have been used.] Reported-and-tested-by: Vito Caputo <vcaputo@gnugeneration.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> 25 October 2013, 22:30:32 UTC
b63eae0 Takashi Iwai 25 October 2013, 21:43:10 UTC ALSA: hda - Add missing initial vmaster hook at build_controls callback The generic parser has a support of vmaster hook, but this is initialized only in the init callback with the check of the presence of the corresponding kctl. However, since kctl is NULL at the very first init callback that is called before build_controls callback, the vmaster hook sync is skipped there. Eventually this leads to the uninitialized state depending on the hook implementation. This patch adds a simple workaround, just calling the sync function explicitly at build_controls callback. Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> 25 October 2013, 21:43:10 UTC
d255c59 Linus Torvalds 25 October 2013, 19:15:13 UTC Merge tag 'for-linus-20131025' of git://git.infradead.org/linux-mtd Pull final mtd fixes from Brian Norris: "A few more last-minute regression fixes, prepared jointly by me and David Woodhouse: - Revert pxa3xx to its old name to avoid breaking existing 'mtdparts=' boot strings. - Return GPMI NAND to its legacy ECC layout for backwards compatibility. We will revisit this in 3.13. A note from David on the latter fix: 'This leaves a harmless cosmetic warning about an unused function. At this point in the cycle I really don't care.'" * tag 'for-linus-20131025' of git://git.infradead.org/linux-mtd: mtd: gpmi: fix ECC regression mtd: nand: pxa3xx: Fix registered MTD name 25 October 2013, 19:15:13 UTC
60a01f5 Nicholas Bellinger 25 October 2013, 17:44:15 UTC vhost/scsi: Fix incorrect usage of get_user_pages_fast write parameter This patch addresses a long-standing bug where the get_user_pages_fast() write parameter used for setting the underlying page table entry permission bits was incorrectly set to write=1 for data_direction=DMA_TO_DEVICE, and passed into get_user_pages_fast() via vhost_scsi_map_iov_to_sgl(). However, this parameter is intended to signal WRITEs to pinned userspace PTEs for the virtio-scsi DMA_FROM_DEVICE -> READ payload case, and *not* for the virtio-scsi DMA_TO_DEVICE -> WRITE payload case. This bug would manifest itself as random process segmentation faults on KVM host after repeated vhost starts + stops and/or with lots of vhost endpoints + LUNs. Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Asias He <asias@redhat.com> Cc: <stable@vger.kernel.org> # 3.6+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> 25 October 2013, 18:03:34 UTC
58932e9 Wei Yongjun 25 October 2013, 13:53:33 UTC target/pscsi: fix return value check In case of error, the function scsi_host_lookup() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Cc: <stable@vger.kernel.org> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> 25 October 2013, 17:42:09 UTC
f55ac56 Linus Torvalds 25 October 2013, 17:16:47 UTC Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull vfs fixes (try two) from Al Viro: "nfsd performance regression fix + seq_file lseek(2) fix" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: seq_file: always update file->f_pos in seq_lseek() nfsd regression since delayed fput() 25 October 2013, 17:16:47 UTC
031e277 David Woodhouse 25 October 2013, 14:03:59 UTC mtd: gpmi: fix ECC regression The "legacy" ECC layout used until 3.12-rc1 uses all the OOB area by computing the ECC strength and ECC step size ourselves. Commit 2febcdf84b ("mtd: gpmi: set the BCHs geometry with the ecc info") makes the driver use the ECC info (ECC strength and ECC step size) provided by the MTD code, and creates a different NAND ECC layout for the BCH, and use the new ECC layout. This causes a regression: We can not mount the ubifs which was created by the old NAND ECC layout. This patch fixes this issue by reverting to the legacy ECC layout. We will probably introduce a new device-tree property to indicate that the new ECC layout can be used. For now though, for the imminent 3.12 release, we just unconditionally revert to the 3.11 behaviour. This leaves a harmless cosmetic warning about an unused function. At this point in the cycle I really don't care. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Huang Shijie <b32955@freescale.com> Acked-by: Marek Vasut <marex@denx.de> Tested-by: Marek Vasut <marex@denx.de> 25 October 2013, 17:09:43 UTC
05e1674 Gu Zheng 25 October 2013, 10:15:06 UTC seq_file: always update file->f_pos in seq_lseek() This issue was first pointed out by Jiaxing Wang several months ago, but no further comments: https://lkml.org/lkml/2013/6/29/41 As we know pread() does not change f_pos, so after pread(), file->f_pos and m->read_pos become different. And seq_lseek() does not update file->f_pos if offset equals to m->read_pos, so after pread() and seq_lseek()(lseek to m->read_pos), then a subsequent read may read from a wrong position, the following program produces the problem: char str1[32] = { 0 }; char str2[32] = { 0 }; int poffset = 10; int count = 20; /*open any seq file*/ int fd = open("/proc/modules", O_RDONLY); pread(fd, str1, count, poffset); printf("pread:%s\n", str1); /*seek to where m->read_pos is*/ lseek(fd, poffset+count, SEEK_SET); /*supposed to read from poffset+count, but this read from position 0*/ read(fd, str2, count); printf("read:%s\n", str2); out put: pread: ck_netbios_ns 12665 read: nf_conntrack_netbios /proc/modules: nf_conntrack_netbios_ns 12665 0 - Live 0xffffffffa038b000 nf_conntrack_broadcast 12589 1 nf_conntrack_netbios_ns, Live 0xffffffffa0386000 So we always update file->f_pos to offset in seq_lseek() to fix this issue. Signed-off-by: Jiaxing Wang <hello.wjx@gmail.com> Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 25 October 2013, 14:46:40 UTC
75c0758 Rafael J. Wysocki 25 October 2013, 14:22:47 UTC acpi-cpufreq: Fail initialization if driver cannot be registered Make acpi_cpufreq_init() return error codes when the driver cannot be registered so that the module doesn't stay useless in memory and so that acpi_cpufreq_exit() doesn't attempt to unregister things that have never been registered when the module is unloaded. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> 25 October 2013, 14:22:47 UTC
4208c47 Linus Torvalds 25 October 2013, 10:49:23 UTC Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC fixes from Olof Johansson: "There's really only one bugfix in this branch, which is a fix for timers on the integrator platform. Since Linus Walleij is resurrecting support for the platform it seems valuable to get the fix into 3.12 even though the regression has been around a while. The rest are a handful of maintainers updates. If you prefer to hold those until 3.13 then just merge the first patch on the branch which is the fix" * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: MAINTAINERS: Add maintainers entry for Rockchip SoCs MAINTAINERS: Tegra updates, and driver ownership MAINTAINERS: ARM: mvebu: add Sebastian Hesselbarth ARM: integrator: deactivate timer0 on the Integrator/CP 25 October 2013, 10:49:23 UTC
065b4a2 James Bottomley 25 October 2013, 09:27:02 UTC [SCSI] Revert "sg: use rwsem to solve race during exclusive open" This reverts commit 15b06f9a02406e5460001db6d5af5c738cd3d4e7. This is one of four patches that was causing this bug [ 205.372823] ================================================ [ 205.372901] [ BUG: lock held when returning to user space! ] [ 205.372979] 3.12.0-rc6-hw-debug-pagealloc+ #67 Not tainted [ 205.373055] ------------------------------------------------ [ 205.373132] megarc.bin/5283 is leaving the kernel with locks still held! [ 205.373212] 1 lock held by megarc.bin/5283: [ 205.373285] #0: (&sdp->o_sem){.+.+..}, at: [<ffffffff8161e650>] sg_open+0x3a0/0x4d0 Cc: Vaughan Cao <vaughan.cao@oracle.com> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> 25 October 2013, 09:59:54 UTC
98481ff James Bottomley 25 October 2013, 09:26:38 UTC [SCSI] Revert "sg: no need sg_open_exclusive_lock" This reverts commit 00b2d9d6d05b56fc1d77071ff8ccbd2c65b48dec. This is one of four patches that was causing this bug [ 205.372823] ================================================ [ 205.372901] [ BUG: lock held when returning to user space! ] [ 205.372979] 3.12.0-rc6-hw-debug-pagealloc+ #67 Not tainted [ 205.373055] ------------------------------------------------ [ 205.373132] megarc.bin/5283 is leaving the kernel with locks still held! [ 205.373212] 1 lock held by megarc.bin/5283: [ 205.373285] #0: (&sdp->o_sem){.+.+..}, at: [<ffffffff8161e650>] sg_open+0x3a0/0x4d0 Cc: Vaughan Cao <vaughan.cao@oracle.com> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> 25 October 2013, 09:59:32 UTC
bafc8ad James Bottomley 25 October 2013, 09:25:14 UTC [SCSI] Revert "sg: checking sdp->detached isn't protected when open" This reverts commit e32c9e6300e3af659cbfe45e90a1e7dcd3572ada. This is one of four patches that was causing this bug [ 205.372823] ================================================ [ 205.372901] [ BUG: lock held when returning to user space! ] [ 205.372979] 3.12.0-rc6-hw-debug-pagealloc+ #67 Not tainted [ 205.373055] ------------------------------------------------ [ 205.373132] megarc.bin/5283 is leaving the kernel with locks still held! [ 205.373212] 1 lock held by megarc.bin/5283: [ 205.373285] #0: (&sdp->o_sem){.+.+..}, at: [<ffffffff8161e650>] sg_open+0x3a0/0x4d0 Cc: Vaughan Cao <vaughan.cao@oracle.com> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> 25 October 2013, 09:59:02 UTC
c0d3b9c James Bottomley 25 October 2013, 09:21:57 UTC [SCSI] Revert "sg: push file descriptor list locking down to per-device locking" This reverts commit 1f962ebcdfa15cede59e9edb299d1330949eec92. This is one of four patches that was causing this bug [ 205.372823] ================================================ [ 205.372901] [ BUG: lock held when returning to user space! ] [ 205.372979] 3.12.0-rc6-hw-debug-pagealloc+ #67 Not tainted [ 205.373055] ------------------------------------------------ [ 205.373132] megarc.bin/5283 is leaving the kernel with locks still held! [ 205.373212] 1 lock held by megarc.bin/5283: [ 205.373285] #0: (&sdp->o_sem){.+.+..}, at: [<ffffffff8161e650>] sg_open+0x3a0/0x4d0 Cc: Vaughan Cao <vaughan.cao@oracle.com> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> 25 October 2013, 09:58:07 UTC
88829df Linus Torvalds 25 October 2013, 06:32:01 UTC Merge tag 'ecryptfs-3.12-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs Pull ecryptfs fixes from Tyler Hicks: "Two important fixes - Fix long standing memory leak in the (rarely used) public key support - Fix large file corruption on 32 bit architectures" * tag 'ecryptfs-3.12-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs: eCryptfs: fix 32 bit corruption issue ecryptfs: Fix memory leakage in keystore.c 25 October 2013, 06:32:01 UTC
d3c345d Russ Dill 24 October 2013, 13:25:26 UTC PM / hibernate: Move software_resume to late_initcall_sync software_resume is being called after deferred_probe_initcall in drivers base. If the probing of the device that contains the resume image is deferred, and the system has been instructed to wait for it to show up, this wait will occur in software_resume. This causes a deadlock. Move software_resume into late_initcall_sync so that it happens after all the other late_initcalls. Signed-off-by: Russ Dill <Russ.Dill@ti.com> Acked-by: Pavel Machek <Pavel@ucw.cz> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 24 October 2013, 23:58:49 UTC
18a84e9 Ezequiel Garcia 19 October 2013, 21:19:25 UTC mtd: nand: pxa3xx: Fix registered MTD name In a recent commit: commit f455578dd961087a5cf94730d9f6489bb1d355f0 Author: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Date: Mon Aug 12 14:14:53 2013 -0300 mtd: nand: pxa3xx: Remove hardcoded mtd name There's no advantage in using a hardcoded name for the mtd device. Instead use the provided by the platform_device. The MTD name was changed to use the one provided by the platform_device. However, this can be problematic as some users want to set partitions using the kernel parameter 'mtdparts', where the name is needed. Therefore, to avoid regressions in users relying in 'mtdparts' we revert the change and use the previous one 'pxa3xx_nand-0'. While at it, let's put a big comment and prevent this change from happening ever again. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com> 24 October 2013, 21:44:28 UTC
43b7c6c Colin Ian King 24 October 2013, 14:08:07 UTC eCryptfs: fix 32 bit corruption issue Shifting page->index on 32 bit systems was overflowing, causing data corruption of > 4GB files. Fix this by casting it first. https://launchpad.net/bugs/1243636 Signed-off-by: Colin Ian King <colin.king@canonical.com> Reported-by: Lars Duesing <lars.duesing@camelotsweb.de> Cc: stable@vger.kernel.org # v3.11+ Signed-off-by: Tyler Hicks <tyhicks@canonical.com> 24 October 2013, 19:36:30 UTC
7261828 Vinod Koul 24 October 2013, 16:47:50 UTC dmaengine: edma: fix another memory leak commit 4b6271a6 fix a menory leak but one more existed in driver so fix that Signed-off-by: Vinod Koul <vinod.koul@intel.com> 24 October 2013, 16:47:50 UTC
4b6271a Valentin Ilie 24 October 2013, 13:14:22 UTC dma: edma: Fix memory leak When it fails to allocate a slot, edesc should be free'd before return; Signed-off-by: Valentin Ilie <valentin.ilie@gmail.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> 24 October 2013, 16:46:15 UTC
c0268e8 Joseph Schuchart 24 October 2013, 13:10:51 UTC perf script python: Fix mem leak due to missing Py_DECREFs on dict entries We are using the Python scripting interface in perf to extract kernel events relevant for performance analysis of HPC codes. We noticed that the "perf script" call allocates a significant amount of memory (in the order of several 100 MiB) during it's run, e.g. 125 MiB for a 25 MiB input file: $> perf record -o perf.data -a -R -g fp \ -e power:cpu_frequency -e sched:sched_switch \ -e sched:sched_migrate_task -e sched:sched_process_exit \ -e sched:sched_process_fork -e sched:sched_process_exec \ -e cycles -m 4096 --freq 4000 $> /usr/bin/time perf script -i perf.data -s dummy_script.py 0.84user 0.13system 0:01.92elapsed 51%CPU (0avgtext+0avgdata 125532maxresident)k 73072inputs+0outputs (57major+33086minor)pagefaults 0swaps Upon further investigation using the valgrind massif tool, we noticed that Python objects that are created in trace-event-python.c via PyString_FromString*() (and their Integer and Long counterparts) are never free'd. The reason for this seem to be missing Py_DECREF calls on the objects that are returned by these functions and stored in the Python dictionaries. The Python dictionaries do not steal references (as opposed to Python tuples and lists) but instead add their own reference. Hence, the reference that is returned by these object creation functions is never released and the memory is leaked. (see [1,2]) The attached patch fixes this by wrapping all relevant calls to PyDict_SetItemString() and decrementing the reference counter immediately after the Python function call. This reduces the allocated memory to a reasonable amount: $> /usr/bin/time perf script -i perf.data -s dummy_script.py 0.73user 0.05system 0:00.79elapsed 99%CPU (0avgtext+0avgdata 49132maxresident)k 0inputs+0outputs (0major+14045minor)pagefaults 0swaps For comparison, with a 120 MiB input file the memory consumption reported by time drops from almost 600 MiB to 146 MiB. The patch has been tested using Linux 3.8.2 with Python 2.7.4 and Linux 3.11.6 with Python 2.7.5. Please let me know if you need any further information. [1] http://docs.python.org/2/c-api/tuple.html#PyTuple_SetItem [2] http://docs.python.org/2/c-api/dict.html#PyDict_SetItemString Signed-off-by: Joseph Schuchart <joseph.schuchart@tu-dresden.de> Reviewed-by: Tom Zanussi <tom.zanussi@linux.intel.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Tom Zanussi <tom.zanussi@linux.intel.com> Link: http://lkml.kernel.org/r/1381468543-25334-4-git-send-email-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 24 October 2013, 13:16:54 UTC
48502dd Nicholas Bellinger 24 October 2013, 07:27:00 UTC target: Fail XCOPY for non matching source + destination block_size This patch adds an explicit check + failure for XCOPY I/O to source + destination devices with a non-matching block_size. This limitiation is currently due to the fact that the scatterlist memory allocated for the XCOPY READ operation is passed zero-copy to the XCOPY WRITE operation. Reported-by: Thomas Glanzmann <thomas@glanzmann.de> Reported-by: Douglas Gilbert <dgilbert@interlog.com> Cc: Thomas Glanzmann <thomas@glanzmann.de> Cc: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> 24 October 2013, 07:28:52 UTC
8a955d6 Nicholas Bellinger 24 October 2013, 07:15:27 UTC target: Generate failure for XCOPY I/O with non-zero scsi_status This patch adds the missing non-zero se_cmd->scsi_status check required for local XCOPY I/O within target_xcopy_issue_pt_cmd() to signal an exception case failure. This will trigger the generation of SAM_STAT_CHECK_CONDITION status from within target_xcopy_do_work() process context code. Reported-by: Thomas Glanzmann <thomas@glanzmann.de> Reported-by: Douglas Gilbert <dgilbert@interlog.com> Cc: Thomas Glanzmann <thomas@glanzmann.de> Cc: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> 24 October 2013, 07:28:27 UTC
366bda1 Nicholas Bellinger 24 October 2013, 07:10:36 UTC target: Add missing XCOPY I/O operation sense_buffer This patch adds the missing xcopy_pt_cmd->sense_buffer[] required for correctly handling CHECK_CONDITION exceptions within the locally generated XCOPY I/O path. Also update target_xcopy_read_source() + target_xcopy_setup_pt_cmd() to pass this buffer into transport_init_se_cmd() to correctly setup se_cmd->sense_buffer. Reported-by: Thomas Glanzmann <thomas@glanzmann.de> Reported-by: Douglas Gilbert <dgilbert@interlog.com> Cc: Thomas Glanzmann <thomas@glanzmann.de> Cc: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> 24 October 2013, 07:28:08 UTC
e6bbe66 Takashi Iwai 23 October 2013, 23:20:24 UTC ALSA: hda - Fix unbalanced runtime PM refcount after S3/S4 When a machine goes to S3/S4 after power-save is enabled, the runtime PM refcount might be incorrectly decreased because the power-down triggered soon after resume assumes that the controller was already powered up, and issues the pm_notify down. This patch fixes the incorrect pm_notify call simply by checking the current value properly. Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> 24 October 2013, 07:21:45 UTC
e6036c0 Linus Torvalds 24 October 2013, 06:45:34 UTC Merge tag 'md/3.12-fixes' of git://neil.brown.name/md Pull md bugfixes from Neil Brown: "Assorted md bug-fixes for 3.12. All tagged for -stable releases too" * tag 'md/3.12-fixes' of git://neil.brown.name/md: raid5: avoid finding "discard" stripe raid5: set bio bi_vcnt 0 for discard request md: avoid deadlock when md_set_badblocks. md: Fix skipping recovery for read-only arrays. 24 October 2013, 06:45:34 UTC
be6e8c7 Linus Torvalds 24 October 2013, 06:44:47 UTC Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "This is a set of two fixes which cause oopses (Buslogic, qla2xxx) and one fix which may cause a hang because of request miscounting (sd)" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: [SCSI] sd: call blk_pm_runtime_init before add_disk [SCSI] qla2xxx: Fix request queue null dereference. [SCSI] BusLogic: Fix an oops when intializing multimaster adapter 24 October 2013, 06:44:47 UTC
0a66614 Vu Pham 21 October 2013, 21:48:54 UTC iser-target: check device before dereferencing its variable This patch changes isert_connect_release() to correctly check for the existence struct isert_device *device before checking for isert_device->use_frwr. Signed-off-by: Vu Pham <vu@mellanox.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> 24 October 2013, 04:42:33 UTC
d47648f Shaohua Li 19 October 2013, 06:51:42 UTC raid5: avoid finding "discard" stripe SCSI discard will damage discard stripe bio setting, eg, some fields are changed. If the stripe is reused very soon, we have wrong bios setting. We remove discard stripe from hash list, so next time the strip will be fully initialized. Suitable for backport to 3.7+. Cc: <stable@vger.kernel.org> (3.7+) Signed-off-by: Shaohua Li <shli@fusionio.com> Signed-off-by: NeilBrown <neilb@suse.de> 24 October 2013, 02:00:24 UTC
37c61ff Shaohua Li 19 October 2013, 06:50:28 UTC raid5: set bio bi_vcnt 0 for discard request SCSI layer will add new payload for discard request. If two bios are merged to one, the second bio has bi_vcnt 1 which is set in raid5. This will confuse SCSI and cause oops. Suitable for backport to 3.7+ Cc: stable@vger.kernel.org (v3.7+) Reported-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: Shaohua Li <shli@fusionio.com> Signed-off-by: NeilBrown <neilb@suse.de> Acked-by: Martin K. Petersen <martin.petersen@oracle.com> 24 October 2013, 01:57:36 UTC
905b029 Bian Yu 12 October 2013, 05:10:03 UTC md: avoid deadlock when md_set_badblocks. When operate harddisk and hit errors, md_set_badblocks is called after scsi_restart_operations which already disabled the irq. but md_set_badblocks will call write_sequnlock_irq and enable irq. so softirq can preempt the current thread and that may cause a deadlock. I think this situation should use write_sequnlock_irqsave/irqrestore instead. I met the situation and the call trace is below: [ 638.919974] BUG: spinlock recursion on CPU#0, scsi_eh_13/1010 [ 638.921923] lock: 0xffff8800d4d51fc8, .magic: dead4ead, .owner: scsi_eh_13/1010, .owner_cpu: 0 [ 638.923890] CPU: 0 PID: 1010 Comm: scsi_eh_13 Not tainted 3.12.0-rc5+ #37 [ 638.925844] Hardware name: To be filled by O.E.M. To be filled by O.E.M./MAHOBAY, BIOS 4.6.5 03/05/2013 [ 638.927816] ffff880037ad4640 ffff880118c03d50 ffffffff8172ff85 0000000000000007 [ 638.929829] ffff8800d4d51fc8 ffff880118c03d70 ffffffff81730030 ffff8800d4d51fc8 [ 638.931848] ffffffff81a72eb0 ffff880118c03d90 ffffffff81730056 ffff8800d4d51fc8 [ 638.933884] Call Trace: [ 638.935867] <IRQ> [<ffffffff8172ff85>] dump_stack+0x55/0x76 [ 638.937878] [<ffffffff81730030>] spin_dump+0x8a/0x8f [ 638.939861] [<ffffffff81730056>] spin_bug+0x21/0x26 [ 638.941836] [<ffffffff81336de4>] do_raw_spin_lock+0xa4/0xc0 [ 638.943801] [<ffffffff8173f036>] _raw_spin_lock+0x66/0x80 [ 638.945747] [<ffffffff814a73ed>] ? scsi_device_unbusy+0x9d/0xd0 [ 638.947672] [<ffffffff8173fb1b>] ? _raw_spin_unlock+0x2b/0x50 [ 638.949595] [<ffffffff814a73ed>] scsi_device_unbusy+0x9d/0xd0 [ 638.951504] [<ffffffff8149ec47>] scsi_finish_command+0x37/0xe0 [ 638.953388] [<ffffffff814a75e8>] scsi_softirq_done+0xa8/0x140 [ 638.955248] [<ffffffff8130e32b>] blk_done_softirq+0x7b/0x90 [ 638.957116] [<ffffffff8104fddd>] __do_softirq+0xfd/0x330 [ 638.958987] [<ffffffff810b964f>] ? __lock_release+0x6f/0x100 [ 638.960861] [<ffffffff8174a5cc>] call_softirq+0x1c/0x30 [ 638.962724] [<ffffffff81004c7d>] do_softirq+0x8d/0xc0 [ 638.964565] [<ffffffff8105024e>] irq_exit+0x10e/0x150 [ 638.966390] [<ffffffff8174ad4a>] smp_apic_timer_interrupt+0x4a/0x60 [ 638.968223] [<ffffffff817499af>] apic_timer_interrupt+0x6f/0x80 [ 638.970079] <EOI> [<ffffffff810b964f>] ? __lock_release+0x6f/0x100 [ 638.971899] [<ffffffff8173fa6a>] ? _raw_spin_unlock_irq+0x3a/0x50 [ 638.973691] [<ffffffff8173fa60>] ? _raw_spin_unlock_irq+0x30/0x50 [ 638.975475] [<ffffffff81562393>] md_set_badblocks+0x1f3/0x4a0 [ 638.977243] [<ffffffff81566e07>] rdev_set_badblocks+0x27/0x80 [ 638.978988] [<ffffffffa00d97bb>] raid5_end_read_request+0x36b/0x4e0 [raid456] [ 638.980723] [<ffffffff811b5a1d>] bio_endio+0x1d/0x40 [ 638.982463] [<ffffffff81304ff3>] req_bio_endio.isra.65+0x83/0xa0 [ 638.984214] [<ffffffff81306b9f>] blk_update_request+0x7f/0x350 [ 638.985967] [<ffffffff81306ea1>] blk_update_bidi_request+0x31/0x90 [ 638.987710] [<ffffffff813085e0>] __blk_end_bidi_request+0x20/0x50 [ 638.989439] [<ffffffff8130862f>] __blk_end_request_all+0x1f/0x30 [ 638.991149] [<ffffffff81308746>] blk_peek_request+0x106/0x250 [ 638.992861] [<ffffffff814a62a9>] ? scsi_kill_request.isra.32+0xe9/0x130 [ 638.994561] [<ffffffff814a633a>] scsi_request_fn+0x4a/0x3d0 [ 638.996251] [<ffffffff813040a7>] __blk_run_queue+0x37/0x50 [ 638.997900] [<ffffffff813045af>] blk_run_queue+0x2f/0x50 [ 638.999553] [<ffffffff814a5750>] scsi_run_queue+0xe0/0x1c0 [ 639.001185] [<ffffffff814a7721>] scsi_run_host_queues+0x21/0x40 [ 639.002798] [<ffffffff814a2e87>] scsi_restart_operations+0x177/0x200 [ 639.004391] [<ffffffff814a4fe9>] scsi_error_handler+0xc9/0xe0 [ 639.005996] [<ffffffff814a4f20>] ? scsi_unjam_host+0xd0/0xd0 [ 639.007600] [<ffffffff81072f6b>] kthread+0xdb/0xe0 [ 639.009205] [<ffffffff81072e90>] ? flush_kthread_worker+0x170/0x170 [ 639.010821] [<ffffffff81748cac>] ret_from_fork+0x7c/0xb0 [ 639.012437] [<ffffffff81072e90>] ? flush_kthread_worker+0x170/0x170 This bug was introduce in commit 2e8ac30312973dd20e68073653 (the first time rdev_set_badblock was call from interrupt context), so this patch is appropriate for 3.5 and subsequent kernels. Cc: <stable@vger.kernel.org> (3.5+) Signed-off-by: Bian Yu <bianyu@kedacom.com> Reviewed-by: Jianpeng Ma <majianpeng@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de> 24 October 2013, 01:57:11 UTC
61e4947 Lukasz Dorau 24 October 2013, 01:55:17 UTC md: Fix skipping recovery for read-only arrays. Since: commit 7ceb17e87bde79d285a8b988cfed9eaeebe60b86 md: Allow devices to be re-added to a read-only array. spares are activated on a read-only array. In case of raid1 and raid10 personalities it causes that not-in-sync devices are marked in-sync without checking if recovery has been finished. If a read-only array is degraded and one of its devices is not in-sync (because the array has been only partially recovered) recovery will be skipped. This patch adds checking if recovery has been finished before marking a device in-sync for raid1 and raid10 personalities. In case of raid5 personality such condition is already present (at raid5.c:6029). Bug was introduced in 3.10 and causes data corruption. Cc: stable@vger.kernel.org Signed-off-by: Pawel Baldysiak <pawel.baldysiak@intel.com> Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com> Signed-off-by: NeilBrown <neilb@suse.de> 24 October 2013, 01:55:17 UTC
cdf6e80 Alex Deucher 23 October 2013, 20:13:42 UTC drm/radeon/dpm: fix incompatible casting on big endian We use u16 for voltage values throughout the driver so switch the table values to a u16 as well. Fixes an incompatible cast error in ci_patch_clock_voltage_limits_with_vddc_leakage() picked up by coverity. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 23 October 2013, 20:25:18 UTC
d48d88b Alex Deucher 23 October 2013, 15:20:46 UTC drm/radeon: disable bapm on KB May cause stability problems on some boards. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 23 October 2013, 20:25:18 UTC
de92680 Alex Deucher 22 October 2013, 14:46:59 UTC drm/radeon: use sw CTS/N values for audio on DCE4+ Use the driver calculated CTS and N values rather than having hardware generate them. This allows us to use the modeline pixel clock rather than the actual pll clock when setting up the dto for audio. Fixes problems with audio playback rate on certain asics if the pll clock does not match the pixel clock exactly. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 23 October 2013, 20:25:12 UTC
18ebd56 Dave Jiang 22 October 2013, 22:29:20 UTC MAINTAINERS: add to ioatdma maintainer list Signed-off-by: Dave Jiang <dave.jiang@intel.com> [djbw: add dmaengine list] Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> 23 October 2013, 16:21:18 UTC
17b5956 Vinod Koul 22 October 2013, 07:28:56 UTC MAINTAINERS: add the new dmaengine mailing list We have a new mailing list hosted by vger for dmaengine Acked-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> 23 October 2013, 16:18:05 UTC
10c580e Aaron Lu 10 October 2013, 05:22:36 UTC [SCSI] sd: call blk_pm_runtime_init before add_disk Sujit has found a race condition that would make q->nr_pending unbalanced, it occurs as Sujit explained: " sd_probe_async() -> add_disk() -> disk_add_event() -> schedule(disk_events_workfn) sd_revalidate_disk() blk_pm_runtime_init() return; Let's say the disk_events_workfn() calls sd_check_events() which tries to send test_unit_ready() and because of sd_revalidate_disk() trying to send another commands the test_unit_ready() might be re-queued as the tagged command queuing is disabled. So the race condition is - Thread 1 | Thread 2 sd_revalidate_disk() | sd_check_events() ...nr_pending = 0 as q->dev = NULL| scsi_queue_insert() blk_runtime_pm_init() | blk_pm_requeue_request() -> | nr_pending = -1 since | q->dev != NULL " The problem is, the test_unit_ready request doesn't get counted the first time it is queued, so the later decrement of q->nr_pending in blk_pm_requeue_request makes it unbalanced. Fix this by calling blk_pm_runtime_init before add_disk so that all requests initiated there will all be counted. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Reported-and-tested-by: Sujit Reddy Thumma <sthumma@codeaurora.org> Cc: stable@vger.kernel.org Signed-off-by: James Bottomley <JBottomley@Parallels.com> 23 October 2013, 13:09:18 UTC
36008cf Chad Dupuis 03 October 2013, 07:21:13 UTC [SCSI] qla2xxx: Fix request queue null dereference. If an invalid IOCB is returned on the response queue then the index into the request queue map could be invalid and could return to us a bogus value. This could cause us to try to deference an invalid pointer and cause an exception. If we encounter this condition, simply return as no context can be established for this response. Signed-off-by: Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> 23 October 2013, 13:09:18 UTC
97b9410 Thomas Gleixner 24 September 2013, 19:50:23 UTC clockevents: Sanitize ticks to nsec conversion Marc Kleine-Budde pointed out, that commit 77cc982 "clocksource: use clockevents_config_and_register() where possible" caused a regression for some of the converted subarchs. The reason is, that the clockevents core code converts the minimal hardware tick delta to a nanosecond value for core internal usage. This conversion is affected by integer math rounding loss, so the backwards conversion to hardware ticks will likely result in a value which is less than the configured hardware limitation. The affected subarchs used their own workaround (SIGH!) which got lost in the conversion. The solution for the issue at hand is simple: adding evt->mult - 1 to the shifted value before the integer divison in the core conversion function takes care of it. But this only works for the case where for the scaled math mult/shift pair "mult <= 1 << shift" is true. For the case where "mult > 1 << shift" we can apply the rounding add only for the minimum delta value to make sure that the backward conversion is not less than the given hardware limit. For the upper bound we need to omit the rounding add, because the backwards conversion is always larger than the original latch value. That would violate the upper bound of the hardware device. Though looking closer at the details of that function reveals another bogosity: The upper bounds check is broken as well. Checking for a resulting "clc" value greater than KTIME_MAX after the conversion is pointless. The conversion does: u64 clc = (latch << evt->shift) / evt->mult; So there is no sanity check for (latch << evt->shift) exceeding the 64bit boundary. The latch argument is "unsigned long", so on a 64bit arch the handed in argument could easily lead to an unnoticed shift overflow. With the above rounding fix applied the calculation before the divison is: u64 clc = (latch << evt->shift) + evt->mult - 1; So we need to make sure, that neither the shift nor the rounding add is overflowing the u64 boundary. [ukl: move assignment to rnd after eventually changing mult, fix build issue and correct comment with the right math] Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Russell King - ARM Linux <linux@arm.linux.org.uk> Cc: Marc Kleine-Budde <mkl@pengutronix.de> Cc: nicolas.ferre@atmel.com Cc: Marc Pignat <marc.pignat@hevs.ch> Cc: john.stultz@linaro.org Cc: kernel@pengutronix.de Cc: Ronald Wahl <ronald.wahl@raritan.com> Cc: LAK <linux-arm-kernel@lists.infradead.org> Cc: Ludovic Desroches <ludovic.desroches@atmel.com> Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1380052223-24139-1-git-send-email-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 23 October 2013, 10:51:21 UTC
320437a Linus Torvalds 23 October 2013, 07:10:25 UTC Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Martin Schwidefsky: "Several last minute bug fixes. Two of them are on the larger side for rc7, the dasd format patch for older storage devices and the store-clock-fast patch where we have been to optimistic with an optimization" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/time: correct use of store clock fast s390/vmlogrdr: fix array access in vmlogrdr_open() s390/compat,signal: fix return value of copy_siginfo_(to|from)_user32() s390/dasd: check for availability of prefix command during format s390/mm,kvm: fix software dirty bits vs. kvm for old machines 23 October 2013, 07:10:25 UTC
back to top