Instead of opencoding the fsync calling sequence use vfs_fsync. This also
gets rid of the useless i_mutex over the data writeout.
Consolidate the remaining special code for syncing directories and document
it's quirks.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
The server incorrectly assumes that the operations in the
array start with value 0. The first operation (OP_ACCESS)
has a value of 3, causing the check in nfsd4_decode_compound
to be off.
Instead of comparing that the operation number is less than
the number of elements in the array, the server should verify
that it is less than the maximum valid operation number
defined by LAST_NFS4_OP.
Signed-off-by: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
The transmitter supports all sample rates up to 192KHz, so the driver
should not give a limit.
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
There is no such GPIO for udc vbus sensing, put '-1' instead of default
'0' as '0' does mean a valid GPIO.
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Setting LC_CTYPE=C breaks localized messages in some setups. With only
LC_COLLATE=C and LC_NUMERIC=C, we get almost all we need, except for not
so defined character classes and tolower()/toupper(). The former is not
a big issue, because we can assume that e.g. [:alpha:] will always
include a-zA-Z and we only ever process ASCII input. The latter seems
only affect arch/sh/tools/gen-mach-types, which we can handle separately.
So after this patch the meaning of ranges like [a-z], the behavior of
sort and join, etc. should be the same everywhere and at the same time
gcc should be able to print localized waring and error messages.
LC_NUMERIC=C might not be necessary, but setting it doesn't hurt.
Reported-by: Simon Horman <horms@verge.net.au>
Reported-by: Sergei Trofimovich <slyfox@inbox.ru>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Tested-by: Simon Horman <horms@verge.net.au>
Tested-by: Masami Hiramatsu <mhiramat@redhat.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
In an x86 build with CONFIG_KERNEL_LZMA enabled and dash as sh,
arch/x86/boot/compressed/vmlinux.bin.lzma ends with
'\xf0\x7d\x39\x00' (16 bytes) instead of the 4 bytes intended and
the resulting vmlinuz fails to boot. This improves on the
previous behavior, in which the file contained the characters
'-ne ' as well, but not by much.
Previous commits replaced "echo -ne" first with "/bin/echo -ne",
then "printf" in the hope of improving portability, but none of
these commands is guaranteed to support hexadecimal escapes on
POSIX systems. So use the shell to convert from hexadecimal to
octal.
With this change, an LZMA-compressed kernel built with dash as sh
boots correctly again.
Reported-by: Sebastian Dalfuß <sd@sedf.de>
Reported-by: Oliver Hartkopp <oliver@hartkopp.net>
Reported-by: Michael Guntsche <mike@it-loops.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Cc: Michael Tokarev <mjt@tls.msk.ru>
Cc: Alek Du <alek.du@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
There were multiple reports which indicate that vendor messed up horribly
and the same VID/PID combination is used for completely different devices,
some of them requiring the blacklist entry and other not.
Remove the blacklist entry for this combination of VID/PID completely, and let
the user decide and unbind the driver via sysfs eventually, if needed. Proper
fix would be fixing the vendor.
References:
http://lkml.org/lkml/2009/2/10/434http://bugzilla.kernel.org/show_bug.cgi?id=13411
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Without this patch xf86-input-wacom driver wasn't able to properly recognise
pad button events. It was also causing some problems with button mapping.
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Added device IDs for the new model of the Apple Wireless Keyboard
(November 2009).
Signed-off-by: Christian Schuerer-Waldheim <csw@xray.at>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This fix is required for xorg driver to recognise 2 pad buttons
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Under Xen 64 bit guests actually run their kernel in ring 3,
however the hypervisor takes care of squashing descriptor the
RPLs transparently (in order to allow them to continue to
differentiate between user and kernel space CS using the RPL).
Therefore the Xen paravirt backend should use RPL==0 instead of
1 (or 3). Using RPL==1 causes generic arch code to take
incorrect code paths because it uses "testl $3, <CS>, je foo"
type tests for a userspace CS and this considers 1==userspace.
This issue was previously masked because get_kernel_rpl() was
omitted when setting CS in kernel_thread(). This was fixed when
kernel_thread() was unified with 32 bit in
f443ff4201.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Christian Kujau <lists@nerdbynature.de>
Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Brian Gerst <brgerst@gmail.com>
LKML-Reference: <1263377768-19600-2-git-send-email-ian.campbell@citrix.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
These were originally named _nopmd and _pmd to follow their asm-generic
counterparts, but we rename them to -2level and -3level for general
consistency.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
All SH-X2 and SH-X3 parts support an extended TLB mode, which has been
left as experimental since support was originally merged. Now that it's
had some time to stabilize and get some exposure to various platforms,
we can drop it as an option and default enable it across the board.
This is also good future proofing for newer parts that will drop support
for the legacy TLB mode completely.
This will also force 3-level page tables for all newer parts, which is
necessary both for the varying page sizes and larger memories.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
In 65f63384 "xen: improve error handling in do_suspend" I said:
- xs_suspend()/xs_resume() and dpm_suspend_noirq()/dpm_resume_noirq() were not
nested in the obvious way.
and changed the ordering of the calls as so:
BEFORE AFTER
xs_suspend dpm_suspend_noirq
dpm_suspend_noirq xs_suspend
*SUSPEND* *SUSPEND*
dpm_resume_noirq dpm_resume_noirq
xs_resume xs_resume
Clearly this is not an improvement and I was talking rubbish.
In particular the new ordering is susceptible to a hang if a xenstore write is
in progress at the point at which the suspend kicks in. When the suspend
process calls xs_suspend it tries to take the request_mutex but if a write is
in progress it could be looping in xenbus_xs.c:read_reply() waiting for
something to arrive on &xs_state.reply_list while holding the request_mutex
(taken in the caller of read_reply).
However if we have done dpm_suspend_noirq before xs_suspend then we won't get
any more xenstore interrupts and process_msg() will never be woken up to add
anything to the reply_list.
Fix this by calling xs_suspend before dpm_suspend_noirq. If dpm_suspend_noirq
fails then make sure we go through the xs_suspend_cancel() code path.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stable Kernel <stable@kernel.org>
This fixes the problem of the initialization code not correctly
mapping the entire MMIO space on a UV system. A side effect is
the map_high() interface needed to be changed to accommodate
different address and size shifts.
Signed-off-by: Mike Travis <travis@sgi.com>
Reviewed-by: Mike Habeck <habeck@sgi.com>
Cc: <stable@kernel.org>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
LKML-Reference: <4B479202.7080705@sgi.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
This stubs out all of the PxSEGADDR() wrappers for non-legacy code.
29-bit will continue to work with these, while 32-bit code will now blow
up on compile rather than at runtime.
The vast majority of the in-tree offenders are gone, with the only
remaining culprits being unable to support 32-bit mode.
Hopefully this will prevent anyone from ever using these again.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This introduces some much overdue chainsawing of the fixed PMB support.
fixed PMB was introduced initially to work around the fact that dynamic
PMB mode was relatively broken, though they were never intended to
converge. The main areas where there are differences are whether the
system is booted in 29-bit mode or 32-bit mode, and whether legacy
mappings are to be preserved. Any system booting in true 32-bit mode will
not care about legacy mappings, so these are roughly decoupled.
Regardless of the entry point, PMB and 32BIT are directly related as far
as the kernel is concerned, so we also switch back to having one select
the other.
With legacy mappings iterated through and applied in the initialization
path it's now possible to finally merge the two implementations and
permit dynamic remapping overtop of remaining entries regardless of
whether boot mappings are crafted by hand or inherited from the boot
loader.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Add --line option to support showing probable source-code lines.
perf probe --line SRC:LN[-LN|+NUM]
or
perf probe --line FUNC[:LN[-LN|+NUM]]
This option shows source-code with line number if the line can
be probed. Lines without line number (and blue color) means that
the line can not be probed, because debuginfo doesn't have the
information of those lines.
The argument specifies the range of lines, "source.c:100-120"
shows lines between 100th to l20th in source.c file. And
"func:10+20" shows 20 lines from 10th line of func function.
e.g.
# ./perf probe --line kernel/sched.c:1080
<kernel/sched.c:1080>
*
* called with rq->lock held and irqs disabled
*/
static void hrtick_start(struct rq *rq, u64 delay)
{
struct hrtimer *timer = &rq->hrtick_timer;
1086 ktime_t time = ktime_add_ns(timer->base->get_time(), delay);
hrtimer_set_expires(timer, time);
1090 if (rq == this_rq()) {
1091 hrtimer_restart(timer);
1092 } else if (!rq->hrtick_csd_pending) {
1093 __smp_call_function_single(cpu_of(rq), &rq->hrtick_csd,
1094 rq->hrtick_csd_pending = 1;
If you specifying function name, this shows function-relative
line number.
# ./perf probe --line schedule
<schedule:0>
asmlinkage void __sched schedule(void)
1 {
struct task_struct *prev, *next;
unsigned long *switch_count;
struct rq *rq;
int cpu;
need_resched:
preempt_disable();
9 cpu = smp_processor_id();
10 rq = cpu_rq(cpu);
11 rcu_sched_qs(cpu);
12 prev = rq->curr;
13 switch_count = &prev->nivcsw;
Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: systemtap <systemtap@sources.redhat.com>
Cc: DLE <dle-develop@lists.sourceforge.net>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <20100106144534.27218.77939.stgit@dhcp-100-2-132.bos.redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
DSOs don't have this problem because the kernel emits a
PERF_MMAP for each new executable mapping it performs on
monitored threads.
To fix the kernel case we simulate the same behaviour, by having
'perf record' to synthesize a PERF_MMAP for the kernel, encoded
like this:
[root@doppio ~]# perf record -a -f sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.344 MB perf.data (~15038 samples) ]
[root@doppio ~]# perf report -D | head -10
0xd0 [0x40]: event: 1
.
. ... raw event: size 64 bytes
. 0000: 01 00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 ......@........
. 0010: 00 00 00 81 ff ff ff ff 00 00 00 00 00 00 00 00 ...............
. 0020: 00 00 00 00 00 00 00 00 5b 6b 65 72 6e 65 6c 2e ........ [kernel
. 0030: 6b 61 6c 6c 73 79 6d 73 2e 5f 74 65 78 74 5d 00 kallsyms._text]
. 0xd0
[0x40]: PERF_RECORD_MMAP 0/0: [0xffffffff81000000((nil)) @ (nil)]: [kernel.kallsyms._text]
I.e. we identify such event as having:
.pid = 0
.filename = [kernel.kallsyms.REFNAME]
.start = REFNAME addr in /proc/kallsyms at 'perf record' time
and use now a hardcoded value of '.text' for REFNAME.
Then, later, in 'perf report', if there are any kernel hits and
thus we need to resolve kernel symbols, we search for REFNAME
and if its address changed, relocation happened and we thus must
change the kernel mapping routines to one that uses .pgoff as
the relocation to apply.
This way we use the same mechanism used for the other DSOs and
don't have to do a two pass in all the kernel symbols.
Reported-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
LKML-Reference: <1262717431-1246-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
To avoid the funny:
[root@doppio ~]# perf record -a -f sleep 2s
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.334 MB perf.data (~14572 samples) ]
[root@doppio ~]# perf report --no-call-graph
selected -g but no callchain data. Did you call perf record without -g?
And fix the bug reported by peterz when we do indeed record with
callchains and then ask for a report without:
[root@doppio ~]# perf record -a -g -f sleep 2s
[root@doppio ~]# perf report --no-call-graph
Segmentation fault
[root@doppio ~]#
Reported-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1262699685-27820-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
