- 31 Oct, 2013 4 commits
-
-
Ming Lei authored
Commit b1adaf65 ("[SCSI] block: add sg buffer copy helper functions") introduces two sg buffer copy helpers, and calls flush_kernel_dcache_page() on pages in SG list after these pages are written to. Unfortunately, the commit may introduce a potential bug: - Before sending some SCSI commands, kmalloc() buffer may be passed to block layper, so flush_kernel_dcache_page() can see a slab page finally - According to cachetlb.txt, flush_kernel_dcache_page() is only called on "a user page", which surely can't be a slab page. - ARCH's implementation of flush_kernel_dcache_page() may use page mapping information to do optimization so page_mapping() will see the slab page, then VM_BUG_ON() is triggered. Aaro Koskinen reported the bug on ARM/kirkwood when DEBUG_VM is enabled, and this patch fixes the bug by adding test of '!PageSlab(miter->page)' before calling flush_kernel_dcache_page(). Signed-off-by:
Ming Lei <ming.lei@canonical.com> Reported-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Tested-by:
Simon Baatz <gmbnomis@gmail.com> Cc: Russell King - ARM Linux <linux@arm.linux.org.uk> Cc: Will Deacon <will.deacon@arm.com> Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Tejun Heo <tj@kernel.org> Cc: "James E.J. Bottomley" <JBottomley@parallels.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: <stable@vger.kernel.org> [3.2+] Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Johannes Weiner authored
When memcg code needs to know whether any given memcg has children, it uses the cgroup child iteration primitives and returns true/false depending on whether the iteration loop is executed at least once or not. Because a cgroup's list of children is RCU protected, these primitives require the RCU read-lock to be held, which is not the case for all memcg callers. This results in the following splat when e.g. enabling hierarchy mode: WARNING: CPU: 3 PID: 1 at kernel/cgroup.c:3043 css_next_child+0xa3/0x160() CPU: 3 PID: 1 Comm: systemd Not tainted 3.12.0-rc5-00117-g83f11a9c-dirty #18 Hardware name: LENOVO 3680B56/3680B56, BIOS 6QET69WW (1.39 ) 04/26/2012 Call Trace: dump_stack+0x54/0x74 warn_slowpath_common+0x78/0xa0 warn_slowpath_null+0x1a/0x20 css_next_child+0xa3/0x160 mem_cgroup_hierarchy_write+0x5b/0xa0 cgroup_file_write+0x108/0x2a0 vfs_write+0xbd/0x1e0 SyS_write+0x4c/0xa0 system_call_fastpath+0x16/0x1b In the memcg case, we only care about children when we are attempting to modify inheritable attributes interactively. Racing with deletion could mean a spurious -EBUSY, no problem. Racing with addition is handled just fine as well through the memcg_create_mutex: if the child group is not on the list after the mutex is acquired, it won't be initialized from the parent's attributes until after the unlock. Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Acked-by:
Michal Hocko <mhocko@suse.cz> Signed-off-by:
-
Johannes Weiner authored
The memcg OOM lock is a mutex-type lock that is open-coded due to memcg's special needs. Add annotations for lockdep coverage. Signed-off-by:
-
Johannes Weiner authored
Commit 84235de3 ("fs: buffer: move allocation failure loop into the allocator") allowed __GFP_NOFAIL allocations to bypass the limit if they fail to reclaim enough memory for the charge. But because the main test case was on a 3.2-based system, the patch missed the fact that on newer kernels the charge function needs to return root_mem_cgroup when bypassing the limit, and not NULL. This will corrupt whatever memory is at NULL + percpu pointer offset. Fix this quickly before problems are reported. Signed-off-by:
-
- 30 Oct, 2013 19 commits
-
-
Linus Torvalds authored
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
-
Greg Thelen authored
As of commit 3ea67d06 ("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:
-
Greg Thelen authored
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:
-
Chen LinX authored
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:
-
Russell King authored
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: 5cedf721 ("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:
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/ttyLinus Torvalds authored
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
-
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
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
-
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/soundLinus Torvalds authored
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
-
git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds authored
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
-
Dan Carpenter authored
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:
-
Dan Carpenter authored
The DevInfo.u32Reserved[] array isn't initialized so it leaks kernel information to user space. Reported-by:
-
Dan Carpenter authored
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:
-
Dan Carpenter authored
In commit d496f94d ('[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 authored
We need to check "count" so we don't overflow the ei->data buffer. Reported-by:
-
Dan Carpenter authored
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:
-
Paolo Bonzini authored
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>
-
Tim Gardner authored
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:
-
David Herrmann authored
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>
-
Dave Airlie authored
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
-
- 29 Oct, 2013 5 commits
-
-
Linus Torvalds authored
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: -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
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 -
Linus Torvalds authored
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: -
Daniel Vetter authored
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=70507Tested-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:
-
Ingo Molnar authored
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>
-
- 28 Oct, 2013 12 commits
-
-
git://github.com/czankel/xtensa-linuxLinus Torvalds authored
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
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
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" -
Zhouyi Zhou authored
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:
-
Jiri Olsa authored
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:
-
Jiri Olsa authored
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 authored
Following commit tightened up the buffer size for output to strict width of used format columns: 99cf666c 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:
-
Rob Pearce authored
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:
-
Jani Nikula authored
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 657445fe 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=67950Tested-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:
-
Ville Syrjälä authored
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 6801c18c 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=69691Tested-by:
Qingshuai Tian <qingshuai.tian@intel.com> Signed-off-by:
-
Ingo Molnar authored
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 authored
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:
-
Ville Syrjälä authored
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 42571aef 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:
-
