- 15 Jan, 2010 6 commits
-
-
Li Zefan authored
MATCH_FULL matching for PTR_STRING is not working correctly: # echo 'func == vt' > events/bkl/lock_kernel/filter # echo 1 > events/bkl/lock_kernel/enable ... # cat trace Xorg-1484 [000] 1973.392586: lock_kernel: ... func=vt_ioctl() gpm-1402 [001] 1974.027740: lock_kernel: ... func=vt_ioctl() We should pass to regex.match(..., len) the length (including '\0') of the source string instead of the length of the pattern string. Signed-off-by:Li Zefan <lizf@cn.fujitsu.com> LKML-Reference: <4B4E8763.5070707@cn.fujitsu.com> Acked-by:
Frederic Weisbecker <fweisbec@gmail.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org>
-
Li Zefan authored
The @str might not be NULL-terminated if it's of type DYN_STRING or STATIC_STRING, so we should use strnstr() instead of strstr(). Signed-off-by:
-
Li Zefan authored
It differs strstr() in that it limits the length to be searched in the first string. Signed-off-by:
-
Li Zefan authored
For '*foo' pattern, we should allow any string ending with 'foo', but event filtering incorrectly disallows strings like bar_foo_foo: Signed-off-by:
-
Li Zefan authored
MATCH_FRONT_ONLY actually is a full matching: # ./perf record -R -f -a -e lock:lock_acquire \ --filter 'name ~rcu_*' sleep 1 # ./perf trace (no output) We should pass the length of the pattern string to strncmp(). Signed-off-by:
-
Li Zefan authored
For '*foo' pattern, we should allow any string ending with 'foo', but ftrace filter incorrectly disallows strings like bar_foo_foo: # echo '*io' > set_ftrace_filter # cat set_ftrace_filter | grep 'req_bio_endio' # cat available_filter_functions | grep 'req_bio_endio' req_bio_endio Signed-off-by:
-
- 12 Jan, 2010 1 commit
-
-
Jan Kiszka authored
Let the arch argument be overruled by bits. Otherwise, building of external modules against a i386 target on a x86-64 host (and likely vice versa as well) fails unless ARCH=i386 is explicitly passed to make. Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com> LKML-Reference: <4B4AFE10.8050109@siemens.com> Signed-off-by:
-
- 07 Jan, 2010 21 commits
-
-
Ingo Molnar authored
Merge branch 'tip/tracing/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace into tracing/urgent
-
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6Linus Torvalds authored
* 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: drm/radeon/kms: rs600: use correct mask for SW interrupt gpu/drm/radeon/radeon_irq.c: move a dereference below a NULL test drm/radeon/radeon_device.c: move a dereference below a NULL test drm/radeon/radeon_fence.c: move a dereference below the NULL test drm/radeon/radeon_connectors.c: add a NULL test before dereference drm/radeon/kms: fix memory leak drm/kms: Fix &&/|| confusion in drm_fb_helper_connector_parse_command_line() drm/edid: Fix CVT width/height decode drm/edid: Skip empty CVT codepoints drm: remove address mask param for drm_pci_alloc() drm/radeon/kms: add missing breaks in i2c and ss lookups drm/radeon/kms: add primary dac adj values table drm/radeon/kms: fallback to default connector table
-
Dave Airlie authored
* korg/drm-radeon-next: drm/radeon/kms: rs600: use correct mask for SW interrupt gpu/drm/radeon/radeon_irq.c: move a dereference below a NULL test drm/radeon/radeon_device.c: move a dereference below a NULL test drm/radeon/radeon_fence.c: move a dereference below the NULL test drm/radeon/radeon_connectors.c: add a NULL test before dereference drm/radeon/kms: fix memory leak drm/radeon/kms: add missing breaks in i2c and ss lookups drm/radeon/kms: add primary dac adj values table drm/radeon/kms: fallback to default connector table
-
Luca Tettamanti authored
The mask happens to be the same, but the IH is reading the status, not the not the control register. Signed-off-by:
Luca Tettamanti <kronos.it@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Darren Jenkins authored
If a NULL value is possible, the dereference should only occur after the NULL test. Coverity CID: 13338 Signed-off-by:
Darren Jenkins <darrenrjenkins@gmail.com> Signed-off-by:
-
Darren Jenkins authored
If a NULL value is possible, the dereference should only occur after the NULL test. Coverity CID: 13335 Signed-off-by:
-
Darren Jenkins authored
If a NULL value is possible, the dereference should only occur after the NULL test. Coverity CID: 13334 Signed-off-by:
-
Darren Jenkins authored
The encoder variable can be NULL in this function so I believe it should be checked before dereference. Coverity CID: 13253 [airlied: extremely unlikely to happen] Signed-off-by:
-
Jiri Slaby authored
Stanse found a memory leak in radeon_master_create. master_priv is not freed/assigned on all paths. Fix that. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
Dave Airlie authored
* drm-core-next: drm/kms: Fix &&/|| confusion in drm_fb_helper_connector_parse_command_line() drm/edid: Fix CVT width/height decode drm/edid: Skip empty CVT codepoints drm: remove address mask param for drm_pci_alloc()
-
Roel Kluin authored
This always evaluates to true. Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Signed-off-by:
-
Adam Jackson authored
Signed-off-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
-
Adam Jackson authored
Signed-off-by:
-
Zhenyu Wang authored
drm_pci_alloc() has input of address mask for setting pci dma mask on the device, which should be properly setup by drm driver. And leave it as a param for drm_pci_alloc() would cause confusion or mistake would corrupt the correct dma mask setting, as seen on intel hw which set wrong dma mask for hw status page. So remove it from drm_pci_alloc() function. Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intelLinus Torvalds authored
* 'drm-intel-next' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel: (23 commits) drm/i915: remove full registers dump debug drm/i915: Add DP dpll limit on ironlake and use existing DPLL search function drm/i915: Select the correct BPC for LVDS on Ironlake drm/i915: Make the BPC in FDI rx/transcoder be consistent with that in pipeconf on Ironlake drm/i915: Enable/disable the dithering for LVDS based on VBT setting drm/i915: Permit pinning whilst the device is 'suspended' drm/i915: Hold struct mutex whilst pinning power context bo. drm/i915: fix unused var drm/i915: Storage class should be before const qualifier drm/i915: remove render reclock support drm/i915: Fix RC6 suspend/resume drm/i915: execbuf2 support drm/i915: Reload hangcheck timer too for Ironlake drm/i915: only enable hotplug for detected outputs drm/i915: Track whether cursor needs physical address in intel_device_info drm/i915: Implement IS_* macros using static tables drm/i915: Move PCI IDs into i915 driver drm/i915: Update LVDS connector status when receiving ACPI LID event drm/i915: Add MALATA PC-81005 to ACPI LID quirk list drm/i915: implement new pm ops for i915 ...
-
Jie Zhang authored
The MMU code uses the copy_*_user_page() variants in access_process_vm() rather than copy_*_user() as the former includes an icache flush. This is important when doing things like setting software breakpoints with gdb. So switch the NOMMU code over to do the same. This patch makes the reasonable assumption that copy_from_user_page() won't fail - which is probably fine, as we've checked the VMA from which we're copying is usable, and the copy is not allowed to cross VMAs. The one case where it might go wrong is if the VMA is a device rather than RAM, and that device returns an error which - in which case rubbish will be returned rather than EIO. Signed-off-by:
Jie Zhang <jie.zhang@analog.com> Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
David McCullough <david_mccullough@mcafee.com> Acked-by:
Paul Mundt <lethal@linux-sh.org> Acked-by:
Greg Ungerer <gerg@uclinux.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Mike Frysinger authored
When working with FDPIC, there are many shared mappings of read-only code regions between applications (the C library, applet packages like busybox, etc.), but the current do_mmap_pgoff() function will issue an icache flush whenever a VMA is added to an MM instead of only doing it when the map is initially created. The flush can instead be done when a region is first mmapped PROT_EXEC. Note that we may not rely on the first mapping of a region being executable - it's possible for it to be PROT_READ only, so we have to remember whether we've flushed the region or not, and then flush the entire region when a bit of it is made executable. However, this also affects the brk area. That will no longer be executable. We can mprotect() it to PROT_EXEC on MPU-mode kernels, but for NOMMU mode kernels, when it increases the brk allocation, making sys_brk() flush the extra from the icache should suffice. The brk area probably isn't used by NOMMU programs since the brk area can only use up the leavings from the stack allocation, where the stack allocation is larger than requested. Signed-off-by:
-
Mike Frysinger authored
The current code will load the stack size and protection markings, but then only use the markings in the MMU code path. The NOMMU code path always passes PROT_EXEC to the mmap() call. While this doesn't matter to most people whilst the code is running, it will cause a pointless icache flush when starting every FDPIC application. Typically this icache flush will be of a region on the order of 128KB in size, or may be the entire icache, depending on the facilities available on the CPU. In the case where the arch default behaviour seems to be desired (EXSTACK_DEFAULT), we probe VM_STACK_FLAGS for VM_EXEC to determine whether we should be setting PROT_EXEC or not. For arches that support an MPU (Memory Protection Unit - an MMU without the virtual mapping capability), setting PROT_EXEC or not will make an important difference. It should be noted that this change also affects the executability of the brk region, since ELF-FDPIC has that share with the stack. However, this is probably irrelevant as NOMMU programs aren't likely to use the brk region, preferring instead allocation via mmap(). Signed-off-by:
-
git://linux-nfs.org/~bfields/linuxLinus Torvalds authored
* 'for-2.6.33' of git://linux-nfs.org/~bfields/linux: sunrpc: fix peername failed on closed listener nfsd: make sure data is on disk before calling ->fsync nfsd: fix "insecure" export option
-
Steven Rostedt authored
If the very unlikely case happens where the writer moves the head by one between where the head page is read and where the new reader page is assigned _and_ the writer then writes and wraps the entire ring buffer so that the head page is back to what was originally read as the head page, the page to be swapped will have a corrupted next pointer. Simple solution is to wrap the assignment of the next pointer with a rb_list_head(). Signed-off-by: -
David Sharp authored
This reference at the end of rb_get_reader_page() was causing off-by-one writes to the prev pointer of the page after the reader page when that page is the head page, and therefore the reader page has the RB_PAGE_HEAD flag in its list.next pointer. This eventually results in a GPF in a subsequent call to rb_set_head_page() (usually from rb_get_reader_page()) when that prev pointer is dereferenced. The dereferenced register would characteristically have an address that appears shifted left by one byte (eg, ffxxxxxxxxxxxxyy instead of ffffxxxxxxxxxxxx) due to being written at an address one byte too high. Signed-off-by:
David Sharp <dhsharp@google.com> LKML-Reference: <1262826727-9090-1-git-send-email-dhsharp@google.com> Signed-off-by:
-
- 06 Jan, 2010 12 commits
-
-
Xiaotian Feng authored
There're some warnings of "nfsd: peername failed (err 107)!" socket error -107 means Transport endpoint is not connected. This warning message was outputed by svc_tcp_accept() [net/sunrpc/svcsock.c], when kernel_getpeername returns -107. This means socket might be CLOSED. And svc_tcp_accept was called by svc_recv() [net/sunrpc/svc_xprt.c] if (test_bit(XPT_LISTENER, &xprt->xpt_flags)) { <snip> newxpt = xprt->xpt_ops->xpo_accept(xprt); <snip> So this might happen when xprt->xpt_flags has both XPT_LISTENER and XPT_CLOSE. Let's take a look at commit b0401d72, this commit has moved the close processing after do recvfrom method, but this commit also introduces this warnings, if the xpt_flags has both XPT_LISTENER and XPT_CLOSED, we should close it, not accpet then close. Signed-off-by:Xiaotian Feng <dfeng@redhat.com> Cc: J. Bruce Fields <bfields@fieldses.org> Cc: Neil Brown <neilb@suse.de> Cc: Trond Myklebust <Trond.Myklebust@netapp.com> Cc: David S. Miller <davem@davemloft.net> Cc: stable@kernel.org Signed-off-by:
J. Bruce Fields <bfields@citi.umich.edu>
-
Christoph Hellwig authored
nfsd is not using vfs_fsync, so I missed it when changing the calling convention during the 2.6.32 window. This patch fixes it to not only start the data writeout, but also wait for it to complete before calling into ->fsync. Signed-off-by:
Christoph Hellwig <hch@lst.de> Cc: stable@kernel.org Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinciLinus Torvalds authored
* 'davinci-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci: DaVinci: DM365: Add the device_enable for the DaVinci Keyscan davinci: enable ARCH_HAS_HOLES_MEMORYMODEL for DaVinci davinci: da8xx/omap-l1: mark RTC as a wakeup source davinci: cp_intc: provide set_wake function Davinci VPFE Capture: Take i2c adapter id through platform data
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6: [SCSI] lpfc 8.3.7: Update Driver version to 8.3.7 [SCSI] lpfc 8.3.7: Fix discovery failures. [SCSI] lpfc 8.3.7: Fix SCSI protocol related errors. [SCSI] lpfc 8.3.7: Fix hardware/SLI relates issues [SCSI] lpfc 8.3.7: Fix NPIV operation errors [SCSI] lpfc 8.3.7: Fix FC protocol errors [SCSI] stex: fix scan of nonexistent lun [SCSI] pmcraid: fix to avoid twice scsi_dma_unmap for a command [SCSI] qla2xxx: Update version number to 8.03.01-k9. [SCSI] qla2xxx: Added to EEH support. [SCSI] qla2xxx: Extend base EEH support in qla2xxx. [SCSI] qla2xxx: Fix for a multiqueue bug in CPU affinity mode [SCSI] qla2xxx: Get the link data rate explicitly during device resync. [SCSI] cxgb3i: Fix a login over vlan issue
-
Zhenyu Wang authored
This one reverts 9e3a6d15. As reported by http://bugzilla.kernel.org/show_bug.cgi?id=14485, this dump will cause hang problem on some machine. If something really needs this kind of full registers dump, that could be done within intel-gpu-tools. Cc: Ben Gamari <bgamari.foss@gmail.com> Signed-off-by:
Eric Anholt <eric@anholt.net>
-
Zhao Yakui authored
For some clocks, the old Ironlake DPLL calculator wold give m/n/p combinations that didn't match the spreadsheet of what HW validation tests. Instead, use the G4X DPLL calculator, which does a better job at it. So we use the intel_g4x_find_best_pll to calculate the DPLL for CRT/HDMI/LVDS on ironlake. At the same time to consider the dpll setting for display port, we add the display port DPLL limit on ironlake, which will directly use the function of intel_find_pll_ironlake_dp to get the corresponding dpll setting. Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Signed-off-by:
-
Zhao Yakui authored
Select the correct BPC for LVDS on Ironlake. If it is 18-bit LVDS panel, the BPC will be 6. When it is 24-bit LVDS panel, the BPC will 8. At the same time the BPC will be 8 when the output device is CRT/HDMI/DP. Signed-off-by:
-
Zhao Yakui authored
Make the BPC in FDI rx/transcoder be consistent with that in pipeconf on Ironlake. Signed-off-by:
-
Zhao Yakui authored
Enable/disable the dithering for LVDS based on VBT setting. On the 965/g4x platform the dithering flag is defined in LVDS register. And on the ironlake the dithering flag is defined in pipeconf register. Signed-off-by:
-
Chris Wilson authored
As pinning (allocating and binding GTT memory) does not actually invoke GPU commands, it is safe, and indeed is attempted, during resumption from suspension: [drm:intel_init_clock_gating] *ERROR* failed to pin power context: -16 Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reported-by:
Hugh Dickins <hugh.dickins@tiscali.co.uk> Cc: stable@kernel.org Signed-off-by:
-
Chris Wilson authored
Hugh found an error path where we were attempting to unref a bo without holding the struct mutex: [drm:intel_init_clock_gating] *ERROR* failed to pin power context: -16 ------------[ cut here ]------------ WARNING: at drivers/gpu/drm/drm_gem.c:438 drm_gem_object_free+0x20/0x5e() Hardware name: ESPRIMO Mobile V5505 Modules linked in: snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device Pid: 3793, comm: s2ram Not tainted 2.6.33-rc2 #4 Call Trace: [<7815298e>] warn_slowpath_common+0x59/0x6b [<781529b3>] warn_slowpath_null+0x13/0x18 [<78317c1a>] ? drm_gem_object_free+0x20/0x5e [<78317c1a>] drm_gem_object_free+0x20/0x5e [<78317bfa>] ? drm_gem_object_free+0x0/0x5e [<7829df11>] kref_put+0x38/0x45 [<7833a5f0>] intel_init_clock_gating+0x232/0x271 [<78317bfa>] ? drm_gem_object_free+0x0/0x5e [<7832c307>] i915_restore_state+0x21a/0x2b3 [<7832379d>] i915_resume+0x3c/0xbb [<78174fe5>] ? trace_hardirqs_on_caller+0xfc/0x123 [<7831c756>] ? drm_class_resume+0x0/0x3e [<7831c78d>] drm_class_resume+0x37/0x3e [<78351e0a>] legacy_resume+0x1e/0x51 [<78351ece>] device_resume+0x91/0xab [<7831c756>] ? drm_class_resume+0x0/0x3e [<78352226>] dpm_resume+0x58/0x10f [<783522fb>] dpm_resume_end+0x1e/0x2c [<78180f80>] suspend_devices_and_enter+0x61/0x84 [<78180ff8>] enter_state+0x55/0x83 [<7818091c>] state_store+0x94/0xaa [<7829d09e>] kobj_attr_store+0x1e/0x23 [<782098e0>] sysfs_write_file+0x66/0x99 [<781cd2f0>] vfs_write+0x8a/0x108 [<781cd408>] sys_write+0x3c/0x63 [<78125c10>] sysenter_do_call+0x12/0x36 ---[ end trace a343537f29950fda ]--- It is in fact slightly more insiduous that first appears since we are attempting to not just free the object without the lock, but are trying to do the whole bo manipulation without holding the lock. Reported-by:
-
Andrew Morton authored
drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load': drivers/gpu/drm/i915/i915_dma.c:1114: warning: 'll_base' may be used uninitialized in this function Partly this is because gcc isn't smart enough. But `ll_base' does get used uninitialised in the DRM_DEBUG() call. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Eric Anholt <eric@anholt.net> Cc: Dave Airlie <airlied@linux.ie> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
