A recent refactoring of perf-record introduced the following:
perf record -a -B
Couldn't generating buildids. Use --no-buildid to profile anyway.
sleep: Terminated
I believe the triple negative was meant to be only a double negative.
:-) While I'm there, fixed the grammar on the error message.
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1328567272-13190-1-git-send-email-dsahern@gmail.com
Signed-off-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The current version of perf detects whether or not the perf.data file is
written in a different endianness using the attr_size field in the
header of the file. This field represents sizeof(struct perf_event_attr)
as known to perf record. If the sizes do not match, then perf tries the
byte-swapped version. If they match, then the tool assumes a different
endianness.
The issue with the approach is that it assumes the size of
perf_event_attr always has to match between perf record and perf report.
However, the kernel perf_event ABI is extensible. New fields can be
added to struct perf_event_attr. Consequently, it is not possible to use
attr_size to detect endianness.
This patch takes another approach by using the magic number written at
the beginning of the perf.data file to detect endianness. The magic
number is an eight-byte signature. It's primary purpose is to identify
(signature) a perf.data file. But it could also be used to encode the
endianness.
The patch introduces a new value for this signature. The key difference
is that the signature is written differently in the file depending on
the endianness. Thus, by comparing the signature from the file with the
tool's own signature it is possible to detect endianness. The new
signature is "PERFILE2".
Backward compatiblity with existing perf.data file is ensured.
Tested-by: David Ahern <dsahern@gmail.com>
Acked-by: David Ahern <dsahern@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Arun Sharma <asharma@fb.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Lin Ming <ming.m.lin@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Roberto Agostino Vitillo <ravitillo@lbl.gov>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Vince Weaver <vweaver1@eecs.utk.edu>
Link: http://lkml.kernel.org/r/1328187288-24395-15-git-send-email-eranian@google.com
Signed-off-by: Stephane Eranian <eranian@google.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Stephane Eranian reported that doing a scheduler latency
measurements with perf on AMD doesn't work out as expected due
to the fact that the sched_clock() granularity is too coarse,
i.e. done in jiffies due to the sched_clock_stable not set,
which, if set, would mean that we get to use the TSC as sample
source which would give us much higher precision.
However, there's no reason not to set sched_clock_stable on AMD
because all families from F10h and upwards do have an invariant
TSC and have the CPUID flag to prove (CPUID_8000_0007_EDX[8]).
Make it so, #1.
Signed-off-by: Borislav Petkov <bp@alien8.de>
Cc: Borislav Petkov <bp@amd64.org>
Cc: Venki Pallipadi <venki@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
Link: http://lkml.kernel.org/r/20120206132546.GA30854@quad
[ Should any non-standard system break the TSC, we should
mark them so explicitly, in their platform init handler, or
in a DMI quirk. ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
.. several days delayed. No reason, I just didn't think of it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQEcBAABAgAGBQJPKF4KAAoJEHm+PkMAQRiGw/YH+wXg2DpZUuHeBK52zMGlJBPc
DzX11/Uan3Y07gM0JbDzuVxwjX4vdxR2bV6r1qsLP8JEUnE8jyFC32DBGi5WAht7
F4KU/Uov2Ds5/wzvY4Iuo01C+JftQHXuy/Sbhck1d0LI0yjLejRaw+zuJv0x2/eS
7YqV+KTGE1lDuJs/Gyq1Vqr1g9831AuS1tv/g3gaqBuN6TcPBFCocaVxzwrUc+y6
94h26XbbOhQRIz38oqUkiqAGnvYS61ocyBcEiRHf0dXkNSDIINqlgukvd7YTXouA
jj/w/DWpMRcQuYAgqkrurr9+yWC9hVQcsvvQ5sAQnIPcxoR868sg1pO8Oheq+1g=
=kUzV
-----END PGP SIGNATURE-----
Merge tag 'v3.3-rc2' into perf/core
Linux 3.3-rc2
Pick up the latest fixes.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
The default 'M/sec' unit is not useful if the result is small enough.
Adjust it dynamically according to the value.
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Namhyung Kim <namhyung@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1328514285-26232-1-git-send-email-namhyung.kim@lge.com
Signed-off-by: Namhyung Kim <namhyung.kim@lge.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Currently we can put the object files in a different directory by using
'O=' comand line argument.
However the generated documentation files don't honor this directive,
This patch fixes that. It's been tested for man target but the others
seems currently broken so no tests have been done on them so far.
Link: http://lkml.kernel.org/r/1328541443-18003-1-git-send-email-fbuihuu@gmail.com
Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
By adding following objects:
bench/mem-memset-x86-64-asm.o
bench/mem-memcpy-x86-64-asm.o
the x86_64 perf binary ended up with executable stack.
The reason was that above objects are assembler sourced and are missing the
GNU-stack note section. In such case the linker assumes that the final binary
should not be restricted at all and mark the stack as RWX.
Adding section ".note.GNU-stack" definition to mentioned objects, with all
flags disabled, thus omiting those objects from linker stack flags decision.
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=783570
Reported-by: Clark Williams <williams@redhat.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1328100848-5630-1-git-send-email-jolsa@redhat.com
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
[ committer note: Remaining bits after what was already added to perf/urgent ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
So that we can get the perf bench exec stack fixes and then apply the
remaining fix for the files added after what is in perf/urgent.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This patch fixes an issue where perf report shows nan% for certain
perf.data files. The below is from a report for a do_fork probe:
-nan% sshd [kernel.kallsyms] [k] do_fork
-nan% packagekitd [kernel.kallsyms] [k] do_fork
-nan% dbus-daemon [kernel.kallsyms] [k] do_fork
-nan% bash [kernel.kallsyms] [k] do_fork
A git bisect shows commit f3bda2c as the cause. However, looking back
through the git history, I saw commit 640c03c which seems to have
removed the required initialization for perf_sample->period. The problem
only started showing after commit f3bda2c. The below patch re-introduces
the initialization and it fixes the problem for me.
With the below patch, for the same perf.data:
73.08% bash [kernel.kallsyms] [k] do_fork
8.97% 11-dhclient [kernel.kallsyms] [k] do_fork
6.41% sshd [kernel.kallsyms] [k] do_fork
3.85% 20-chrony [kernel.kallsyms] [k] do_fork
2.56% sendmail [kernel.kallsyms] [k] do_fork
This patch applies over current linux-tip commit 9949284.
Problem introduced in:
$ git describe 640c03c
v2.6.37-rc3-83-g640c03c
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: stable@kernel.org
Link: http://lkml.kernel.org/r/20120203170113.5190.25558.stgit@localhost6.localdomain6
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
In some perf ancient versions we used '[kernel.kallsyms._text]' as the
name for the kernel map.
This got changed with commit:
perf: 'perf kvm' tool for monitoring guest performance from host
commit a1645ce12a
Author: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
and we started to use following name '[kernel.kallsyms]_text'.
This name change is important for the report code dealing with ancient
perf data. When processing the kernel map event, we need to recognize
the old naming (dont match the last ']') and initialize the kernel map
correctly.
The subsequent call to maps__set_kallsyms_ref_reloc_sym deals with the
superfluous ']' to get correct symbol name.
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1328461865-6127-1-git-send-email-jolsa@redhat.com
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
By adding following objects:
bench/mem-memcpy-x86-64-asm.o
the x86_64 perf binary ended up with executable stack.
The reason was that above object are assembler sourced and is missing the
GNU-stack note section. In such case the linker assumes that the final binary
should not be restricted at all and mark the stack as RWX.
Adding section ".note.GNU-stack" definition to mentioned object, with all
flags disabled, thus omiting this object from linker stack flags decision.
Problem introduced in:
$ git describe ea7872b
v2.6.37-rc2-19-gea7872b
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=783570
Reported-by: Clark Williams <williams@redhat.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: stable@kernel.org
Link: http://lkml.kernel.org/r/1328100848-5630-1-git-send-email-jolsa@redhat.com
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
[ committer note: Backported fix to perf/urgent (3.3-rc2+) ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
With the new throttling/unthrottling code introduced with
commit:
e050e3f0a7 ("perf: Fix broken interrupt rate throttling")
we occasionally hit two WARN_ON_ONCE() checks in:
- intel_pmu_pebs_enable()
- intel_pmu_lbr_enable()
- x86_pmu_start()
The assertions are no longer problematic. There is a valid
path where they can trigger but it is harmless.
The assertion can be triggered with:
$ perf record -e instructions:pp ....
Leading to paths:
intel_pmu_pebs_enable
intel_pmu_enable_event
x86_perf_event_set_period
x86_pmu_start
perf_adjust_freq_unthr_context
perf_event_task_tick
scheduler_tick
And:
intel_pmu_lbr_enable
intel_pmu_enable_event
x86_perf_event_set_period
x86_pmu_start
perf_adjust_freq_unthr_context.
perf_event_task_tick
scheduler_tick
cpuc->enabled is always on because when we get to
perf_adjust_freq_unthr_context() the PMU is not totally
disabled. Furthermore when we need to adjust a period,
we only stop the event we need to change and not the
entire PMU. Thus, when we re-enable, cpuc->enabled is
already set. Note that when we stop the event, both
pebs and lbr are stopped if necessary (and possible).
Signed-off-by: Stephane Eranian <eranian@google.com>
Cc: peterz@infradead.org
Link: http://lkml.kernel.org/r/20120202110401.GA30911@quad
Signed-off-by: Ingo Molnar <mingo@elte.hu>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
rbd: fix safety of rbd_put_client()
rbd: fix a memory leak in rbd_get_client()
ceph: create a new session lock to avoid lock inversion
ceph: fix length validation in parse_reply_info()
ceph: initialize client debugfs outside of monc->mutex
ceph: change "ceph.layout" xattr to be "ceph.file.layout"
The rbd_client structure uses a kref to arrange for cleaning up and
freeing an instance when its last reference is dropped. The cleanup
routine is rbd_client_release(), and one of the things it does is
delete the rbd_client from rbd_client_list. It acquires node_lock
to do so, but the way it is done is still not safe.
The problem is that when attempting to reuse an existing rbd_client,
the structure found might already be in the process of getting
destroyed and cleaned up.
Here's the scenario, with "CLIENT" representing an existing
rbd_client that's involved in the race:
Thread on CPU A | Thread on CPU B
--------------- | ---------------
rbd_put_client(CLIENT) | rbd_get_client()
kref_put() | (acquires node_lock)
kref->refcount becomes 0 | __rbd_client_find() returns CLIENT
calls rbd_client_release() | kref_get(&CLIENT->kref);
| (releases node_lock)
(acquires node_lock) |
deletes CLIENT from list | ...and starts using CLIENT...
(releases node_lock) |
and frees CLIENT | <-- but CLIENT gets freed here
Fix this by having rbd_put_client() acquire node_lock. The result
could still be improved, but at least it avoids this problem.
Signed-off-by: Alex Elder <elder@dreamhost.com>
Signed-off-by: Sage Weil <sage@newdream.net>
This fixes the race in process_vm_core found by Oleg (see
http://article.gmane.org/gmane.linux.kernel/1235667/
for details).
This has been updated since I last sent it as the creation of the new
mm_access() function did almost exactly the same thing as parts of the
previous version of this patch did.
In order to use mm_access() even when /proc isn't enabled, we move it to
kernel/fork.c where other related process mm access functions already
are.
Signed-off-by: Chris Yeoh <yeohc@au1.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If an existing rbd client is found to be suitable for use in
rbd_get_client(), the rbd_options structure is not being
freed as it should. Fix that.
Signed-off-by: Alex Elder <elder@dreamhost.com>
Signed-off-by: Sage Weil <sage@newdream.net>
Lockdep was reporting a possible circular lock dependency in
dentry_lease_is_valid(). That function needs to sample the
session's s_cap_gen and and s_cap_ttl fields coherently, but needs
to do so while holding a dentry lock. The s_cap_lock field was
being used to protect the two fields, but that can't be taken while
holding a lock on a dentry within the session.
In most cases, the s_cap_gen and s_cap_ttl fields only get operated
on separately. But in three cases they need to be updated together.
Implement a new lock to protect the spots updating both fields
atomically is required.
Signed-off-by: Alex Elder <elder@dreamhost.com>
Reviewed-by: Sage Weil <sage@newdream.net>
"len" is read from network and thus needs validation. Otherwise, given
a bogus "len" value, p+len could be an out-of-bounds pointer, which is
used in further parsing.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Sage Weil <sage@newdream.net>
Initializing debufs under monc->mutex introduces a lock dependency for
sb->s_type->i_mutex_key, which (combined with several other dependencies)
leads to an annoying lockdep warning. There's no particular reason to do
the debugfs setup under this lock, so move it out.
It used to be the case that our first monmap could come from the OSD; that
is no longer the case with recent servers, so we will reliably set up the
client entry during the initial authentication.
We don't have to worry about racing with debugfs teardown by
ceph_debugfs_client_cleanup() because ceph_destroy_client() calls
ceph_msgr_flush() first, which will wait for the message dispatch work
to complete (and the debugfs init to complete).
Fixes: #1940
Signed-off-by: Sage Weil <sage@newdream.net>
The virtual extended attribute named "ceph.layout" is meaningful
only for regular files. Change its name to be "ceph.file.layout" to
more directly reflect that in the ceph xattr namespace. Preserve
the old "ceph.layout" name for the time being (until we decide it's
safe to get rid of it entirely).
Add a missing initializer for "readonly" in the terminating entry.
Signed-off-by: Alex Elder <elder@dreamhost.com>
Reviewed-by: Sage Weil <sage@newdream.net>
Loop over all features to enable it instead of explicitly enabling every
single feature. Reducing duplicate code and making it more robust to
later changes e.g. when adding more features.
Cc: Ingo Molnar <mingo@elte.hu>
Link: http://lkml.kernel.org/r/1323966762-8574-3-git-send-email-robert.richter@amd.com
Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This is a precursor patch that modifies names that refer to
kernel/module to also refer to user space names.
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Anton Arapov <anton@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Jim Keniston <jkenisto@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux-mm <linux-mm@kvack.org>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20120202142040.5967.64156.sendpatchset@srdronam.in.ibm.com
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
distclean as an alias for clean was removed from the perf Makefile by
commit a3d1ee10d1
However, that commit neglected to remove it from the help output of
the perf Makefile, which could result in a user trying the following.
$ cd tools/perf/
$ make help | grep distclean
distclean - alias to clean
$ make distclean
make: *** No rule to make target `distclean'. Stop.
This patch removes it from the Makefile help output.
Link: http://lkml.kernel.org/r/1328134591-19851-1-git-send-email-jkacur@redhat.com
Signed-off-by: John Kacur <jkacur@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/radeon/kms/blit: fix blit copy for very large buffers
drm/radeon/kms: fix TRAVIS panel setup
drm/radeon: fix use after free in ATRM bios reading code.
drm/radeon/kms: Fix device tree linkage of DP i2c buses too
drm/radeon: Set DESKTOP_HEIGHT register to the framebuffer (not mode) height.
drm/radeon/kms: disable output polling when suspended
drm/nv50/pm: signedness bug in nv50_pm_clocks_pre()
drm/nouveau/gem: fix fence_sync race / oops
drm/nouveau: fix typo on mxmdcb option
drm/nouveau/mxm: pretend to succeed, even if we can't shadow the MXM-SIS
drm/nouveau/disp: check that panel power gpio is enabled at init time
* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
bugs, x86: Fix printk levels for panic, softlockups and stack dumps
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf top: Fix number of samples displayed
perf tools: Fix strlen() bug in perf_event__synthesize_event_type()
perf tools: Fix broken build by defining _GNU_SOURCE in Makefile
x86/dumpstack: Remove unneeded check in dump_trace()
perf: Fix broken interrupt rate throttling
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/rt: Fix task stack corruption under __ARCH_WANT_INTERRUPTS_ON_CTXSW
sched: Fix ancient race in do_exit()
sched/nohz: Fix nohz cpu idle load balancing state with cpu hotplug
sched/s390: Fix compile error in sched/core.c
sched: Fix rq->nr_uninterruptible update race
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/reboot: Remove VersaLogic Menlow reboot quirk
x86/reboot: Skip DMI checks if reboot set by user
x86: Properly parenthesize cmpxchg() macro arguments
Evergreen and NI blit copy was broken if the buffer maps to a rectangle
whose one dimension is 16384 (max dimension allowed by these chips).
In the mainline kernel, the problem is exposed only when buffers are
very large (1G), but it's still a problem. The problem could be exposed
for smaller buffers if anyone modifies the algorithm for rectangle
construction in r600_blit_create_rect() (the reason why someone would
modify that algorithm is to tune the performance of buffer moves).
The root cause was in i2f() function which only operated on range between
0 and 16383. Fix this by extending the range of i2f() function to 0 to
32767.
While at it improve the function so that the range can be easily
extended in the future (if it becomes necessary), cleanup lines
over 80 characters, and replace in-line comments with one strategic
comment that explains the crux of the function.
Credits to michel@daenzer.net for pointing out the root cause of
the bug.
v2: Fix I2F_MAX_INPUT constant definition goof and warn only once
if input argument is out of range. Edit the comment a little
bit to avoid some linguistic confusion and make it look better
in general.
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Different versions of the DP to LVDS bridge chip
need different panel mode settings depending on
the chip version used.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add workarounds table entries for hardware bugs in
- FireWire part of Sound Blaster Audigy cards,
- Ricoh PCIe 1394 controllers.
Without these, several protocols, e.g. AV/C, do not work on the
Audigy, and the Ricoh PCIe controllers wouldn't work at all.
This does not concern the older Ricoh PCI controllers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
iQIcBAABAgAGBQJPJ/k1AAoJEHnzb7JUXXnQBWcP/Ao0EA9pw46YvQQ2jDwMlHfR
k76TntuUKJhVHCLUNvQjHGjNKiAkfKXeIu+a1XNAr8byVqDEbZEQpJheOVG3/O0Z
GyxS+Y/9Sy2JRED0ouWygGW1dN73Cw6GgvxfB6GzhPInq4wrdbdHIZ5XKE49kwyi
tz8gu/TE70e/0Y8MkfBdxJEOR1gmJwqFnVnZayaTV+qtBBnWaBIBkDThIQbmhJBw
oMYBfbs3V32d10GChTGv5LksVUil6tFpbW45x6xcIu24/c0R20033XP8fHEoXtXy
kQ3CnfBtFbsMeXHvbePwo/SVJUgk0oUBmLPVQmDOL30S6P3mV204ED+RsrwyrTdO
sIKWErgdJL/ApfGnqs4fg7cvSWsX3CFCKwztHG4wF1LDVofhq2uWM1ys/REOMTCX
zFPdbKwAPfFCwlZO4mhT1UXPHEzNTgZRzIqKpiowjLjx+cnXv0vOEPDQheSknRw5
416PAw7aWSz8VGmbZM063aFrtAmbq1jzLrtaIAjn7ha/2K/ys0/PaXBRwDClZNZ3
5ZA6u1TwFWFOYbuJ7ImwvSbC9C2LeWHUxDJ/8OCi9RFA78aEpSlhEyRfAmkKAetJ
hJVchUvJfP3LzEZ+IMNrWkI3H3Jf5MfcUvfZwNN2S6BvqDGlqYD+ldXhtHF5VyY2
l0KR4CsAvuQeL4gUxinP
=3Utr
-----END PGP SIGNATURE-----
Merge tag 'firewire-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
firewire fixes post v3.3-rc1
Add workarounds table entries for hardware bugs in
- FireWire part of Sound Blaster Audigy cards,
- Ricoh PCIe 1394 controllers.
Without these, several protocols, e.g. AV/C, do not work on the
Audigy, and the Ricoh PCIe controllers wouldn't work at all.
This does not concern the older Ricoh PCI controllers.
* tag 'firewire-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: ohci: disable MSI on Ricoh controllers
firewire: ohci: add reset packet quirk for SB Audigy
Add MODULE_LICENSE() as per the license in the comment at the top of the
file for this source module to fix build warning:
WARNING: modpost: missing MODULE_LICENSE() in drivers/staging/media/go7007/go7007-usb.o
see include/linux/module.h for more information
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Ross Cohen <rcohen@snurgle.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix 2 fatal errors in the device-drivers docbook.
Also add some missing files from drivers/base/; since several
of these are DMA-related, add a section for DMA Management.
docproc: drivers/base/sys.c: No such file or directory
docproc: drivers/tty/serial/8250.c: No such file or directory
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus2' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
lib: Fix 32-bit sparc udiv_qrnnd() definition in mpilib's longlong.h
lib: Fix multiple definitions of clz_tab
lib/digsig: checks for NULL return value
lib/mpi: added missing NULL check
lib/mpi: added comment on divide by 0 case
lib/mpi: check for possible zero length
lib/digsig: pkcs_1_v1_5_decode_emsa cleanup
lib/digsig: additional sanity checks against badly formated key payload
lib/mpi: removed unused functions
lib/mpi: checks for zero divisor length
lib/mpi: return error code on dividing by zero
lib/mpi: replaced MPI_NULL with normal NULL
lib/mpi: added missing NULL check
This copy of longlong.h is extremely dated and results in compile
errors on sparc32 when MPILIB is enabled, copy over the more uptodate
implementation from arch/sparc/math/sfp-util_32.h
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: James Morris <jmorris@namei.org>
Both sparc 32-bit's software divide assembler and MPILIB provide
clz_tab[] with identical contents.
Break it out into a seperate object file and select it when
SPARC32 or MPILIB is set.
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: James Morris <jmorris@namei.org>
- Fix a crash due to a regression (uninitialized refcnt) introduced in
3.2 with XRC support.
- Close race in how ucma reports events when connect fails.
- Process vendor-specific MADs in mlx4 so that eg FDR-10 data rate works.
- Fix regression in qib caused by over-aggressive PCIe tuning.
- Other small fixes for hardware drivers (ipath, nes, qib).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABCAAGBQJPKNzJAAoJEENa44ZhAt0heQsP/1XmbosLnTZ3RFmEFcvW4Akn
lCuxPqvF7tfMXzl4fkYOZ0bNvfB4xTbMVkWeQXnwK+e2p/kL8a/dWHaom79wgo7Z
qAldncGAZrXEn8E3IcHLgWKMtHK9/HpJZvxkqlACa7muQKunS41Qa/QqIL5MoUQm
PVsTkj3wjtdvN5XgrtmeY2efTY86tZDxDv8Glg76616SawsJ/J17FRMNAEl02vZ5
mFH2jtmlsSNNenwSkykwEJpX39teqLl/GreAKuxt2pZXhGi67aFcfu7OrS9LY5iy
LNP5a+gmykOAjq+dx9DGj24LRD4+pisDXb851e2tcZ1l1jrgedBGTqPWXldR0acq
+eFYmYmIGU7iFQZvKel9PFiPa2YEUZn8TtKN+e1vSkXqsLuI1qjBVf+i2fMUwszB
TyxRjX62S9J01CY5XKlBySAAoVWcf2NyP6IKAIF4nOKXR5g4KtMUmmkL5BamV/7c
YodAey8+0RTqLY2tgj0WKIswVAHg1ALXo8AzFwQRioau9Ro+T+2UsSzR6WzKpF7B
uhAyZynW8zNb7esSuXiiD5PfI4+gUlEyeesxuRFhufp45i3NQhhkW+6bRM5m0YkJ
MMww5UyFnXqiEiCrB35rAio+MrhIHLMYXP5/oPNblgYlRWpSN9ijnyeDrVN9D0aX
3BS5gakUhRntjwFcOz54
=81hM
-----END PGP SIGNATURE-----
Merge tag 'rdma-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband
InfiniBand/RDMA fixes for 3.3:
- Fix a crash due to a regression (uninitialized refcnt) introduced in
3.2 with XRC support.
- Close race in how ucma reports events when connect fails.
- Process vendor-specific MADs in mlx4 so that eg FDR-10 data rate works.
- Fix regression in qib caused by over-aggressive PCIe tuning.
- Other small fixes for hardware drivers (ipath, nes, qib).
* tag 'rdma-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband:
RDMA/nes: Copyright update
IB/mlx4: pass SMP vendor-specific attribute MADs to firmware
RDMA/nes: Fix fast memory registration opcode
RDMA/nes: Fix fast memory registration length
RDMA/ucma: Discard all events for new connections until accepted
IB/qib: Roll back PCIe tuning change
IB/qib: Use GFP_ATOMIC when locks are held
RDMA/nes: Add missing rcu_read_unlock() in nes_addr_resolve_neigh()
RDMA/nes: Fix for sending MPA reject frame
IB/ipath: Calling PTR_ERR() on right variable in create_file()
RDMA/core: Fix kernel panic by always initializing qp->usecnt
Once /proc/pid/mem is opened, the memory can't be released until
mem_release() even if its owner exits.
Change mem_open() to do atomic_inc(mm_count) + mmput(), this only
pins mm_struct. Change mem_rw() to do atomic_inc_not_zero(mm_count)
before access_remote_vm(), this verifies that this mm is still alive.
I am not sure what should mem_rw() return if atomic_inc_not_zero()
fails. With this patch it returns zero to match the "mm == NULL" case,
may be it should return -EINVAL like it did before e268337d.
Perhaps it makes sense to add the additional fatal_signal_pending()
check into the main loop, to ensure we do not hold this memory if
the target task was oom-killed.
Cc: stable@kernel.org
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
No functional changes, cleanup and preparation.
mem_read() and mem_write() are very similar. Move this code into the
new common helper, mem_rw(), which takes the additional "int write"
argument.
Cc: stable@kernel.org
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mem_release() can hit mm == NULL, add the necessary check.
Cc: stable@kernel.org
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
My email address has changed, the suse.de one is now dead, so update all
of my MAINTAINER entries with the correct one so that patches don't get
lost.
Also change the status of some of my entries as I'm supposed to be doing
this stuff now for real.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch fixes merge conflict resolution breakage introduced by merge
d3712b9dfc ("Merge tag 'for-linus' of git://github.com/prasad-joshi/logfs_upstream").
The commit changed 'mtd_can_have_bb()' function and made it always
return zero, which is incorrect. Instead, we need it to return whether
the underlying flash device can have bad eraseblocks or not. UBI needs
this information because it affects how it handles the underlying flash.
E.g., if the underlying flash is NOR, it cannot have bad blocks and any
write or erase error is fatal, and all we can do is to switch to R/O
mode. We do not need to reserve a pool of good eraseblocks for bad
eraseblocks handling, and so on.
This patch also removes 'mtd_can_have_bb()' invocations from Logfs to
ensure correct Logfs behavior.
I've tested that with this patch UBI works on top of NOR and NAND
flashes emulated by mtdram and nandsim correspondingly.
This patch is based on patch from Linus Torvalds.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Acked-by: Jörn Engel <joern@logfs.org>
Acked-by: Prasad Joshi <prasadjoshi.linux@gmail.com>
Acked-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Making perf_evlist__splice_list_tail globaly accessible.
It is used in the upcomming paches.
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/1327674868-10486-2-git-send-email-jolsa@redhat.com
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Properly set the parent device of DP i2c buses before registering them
too.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The value of this register is transferred to the V_COUNTER register at the
beginning of vertical blank. V_COUNTER is the reference for VLINE waits and
goes from VIEWPORT_Y_START to VIEWPORT_Y_START+VIEWPORT_HEIGHT during scanout,
so if VIEWPORT_Y_START is not 0, V_COUNTER actually went backwards at the
beginning of vertical blank, and VLINE waits excluding the whole scanout area
could never finish (possibly only if VIEWPORT_Y_START is larger than the length
of vertical blank in scanlines). Setting DESKTOP_HEIGHT to the framebuffer
height should prevent this for any kind of VLINE wait.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=45329 .
CC: stable@vger.kernel.org
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Polling the outputs when the device is suspended can result in erroneous
status updates. Disable output polling during suspend to prevent this
from happening.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
mpi_read_from_buffer() return value must not be NULL.
Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Reviewed-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: James Morris <jmorris@namei.org>
