HATAYAMA Daisuke [Wed, 20 Mar 2013 04:08:38 +0000 (15:08 +1100)]
vmcore: round-up offset of vmcore object in page-size boundary
To satisfy mmap()'s page-size bounary requirement, round-up offset of each
vmcore objects in page-size boundary; each offset is connected to
user-space virtual address through mapping of mmap().
HATAYAMA Daisuke [Wed, 20 Mar 2013 04:08:38 +0000 (15:08 +1100)]
vmcore: check if vmcore objects satify mmap()'s page-size boundary requirement
If there's some vmcore object that doesn't satisfy page-size boundary
requirement, remap_pfn_range() fails to remap it to user-space.
Objects that possibly don't satisfy the requirement are ELF note segments
only. The memory chunks corresponding to PT_LOAD entries are guaranteed
to satisfy page-size boundary requirement by the copy from old memory to
buffer in 2nd kernel done in later patch.
This patch doesn't copy each note segment into the 2nd kernel since they
amount to so large in total if there are multiple CPUs. For example,
current maximum number of CPUs in x86_64 is 5120, where note segments
exceed 1MB with NT_PRSTATUS only.
HATAYAMA Daisuke [Wed, 20 Mar 2013 04:08:38 +0000 (15:08 +1100)]
vmcore: check NT_VMCORE_PAD as a mark indicating the end of ELF note buffer
Modern kernel marks the end of ELF note buffer with NT_VMCORE_PAD type
note in order to make the buffer satisfy mmap()'s page-size boundary
requirement. This patch makes finishing reading each buffer if the note
type now being read is NT_VMCORE_PAD type.
HATAYAMA Daisuke [Wed, 20 Mar 2013 04:08:37 +0000 (15:08 +1100)]
kexec: fill note buffers by NT_VMCORE_PAD notes in page-size boundary
Fill both crash_notes and vmcoreinfo_note buffers by NT_VMCORE_PAD note
type to make them satisfy mmap()'s page-size boundary requirement.
So far, end of note segments has been marked by zero-filled elf header.
Instead, this patch writes NT_VMCORE_PAD note in the end of note segments
until the offset on page-size boundary.
Also, old kernel can treat the ELF segments created without null header
because it stops reading ELF segments if real size it reads reachs
p_memsz.
HATAYAMA Daisuke [Wed, 20 Mar 2013 04:08:37 +0000 (15:08 +1100)]
elf: introduce NT_VMCORE_PAD type
The NT_VMCORE_PAD type is introduced to make both crash_notes buffer and
vmcoreinfo_note buffer satisfy mmap()'s page-size boundary requirement by
filling them with this note type.
The purpose of this type is just to align the buffer in page-size
boundary; it has no meaning in contents, which are fully filled with zero.
This note type belongs to "VMCOREINFO" name space and the type in this
name space is 7. The reason why the numbers from 1 to 5 is not chosen is
that for the ones from 1 to 4, there are the corresponding note types
using the same number in "CORE" name space, and crash utility and
makedumpfile don't distinguish note types by name space at all; for the
remaining 5, this has somehow not been used since v2.4.0 kernel despite
the fact that NT_AUXV is defined as 6. It looks that it avoids some
dependency to 5. Here simply 5 is not chosen for conservative viewpoint.
By this change, gdb and binutils work well without any change, but
makedumpfile and crash utility need their changes to distinguish two note
types in "VMCOREINFO" name space.
HATAYAMA Daisuke [Wed, 20 Mar 2013 04:08:37 +0000 (15:08 +1100)]
kexec, elf: introduce NT_VMCORE_DEBUGINFO note type
This patch introduces NT_VMCORE_DEBUGINFO to a unique note type in
VMCOREINFO name, which has had no name so far. The name means that it's a
kind of note type in vmcoreinfo that contains system kernel's debug
information.
HATAYAMA Daisuke [Wed, 20 Mar 2013 04:08:36 +0000 (15:08 +1100)]
vmcore: allocate per-cpu crash_notes objects on page-size boundary
To satisfy mmap()'s page-size boundary requirement, allocate per-cpu
crash_notes objects on page-size boundary.
/proc/vmcore on the 2nd kernel checks if each note objects is allocated on
page-size boundary. If there's some object not satisfying the page-size
boundary requirement, /proc/vmcore doesn't provide mmap() interface.
HATAYAMA Daisuke [Wed, 20 Mar 2013 04:08:36 +0000 (15:08 +1100)]
vmcore: read buffers for vmcore objects copied from old memory
If flag MEM_TYPE_CURRENT_KERNEL is set, the object is copied in the buffer
on the 2nd kernel, then read_vmcore() reads the buffer. If the flag is
not set, read_vmcore() reads old memory as usual.
HATAYAMA Daisuke [Wed, 20 Mar 2013 04:08:36 +0000 (15:08 +1100)]
vmcore: clean up read_vmcore()
Clean up read_vmcore(). Part for objects in vmcore_list can be written
uniformly to part for ELF headers. By this change, duplicate and
complicated codes are removed, so it's more clear to see what's done
there.
Also, by this change, map_offset_to_paddr() is no longer used. Remove it.
and the first one is kept in old memory and the 2nd one is copied into
buffer on 2nd kernel.
This kind of non-page-size-aligned area can always occur since any part of
System RAM can be converted into reserved area at runtime.
If not doing copying like this and if remapping non page-size aligned
pages on old memory directly, mmap() had to export memory which is not
dump target to user-space. In the above example this is reserved
0x9f800-0xa0000.
HATAYAMA Daisuke [Wed, 20 Mar 2013 04:08:35 +0000 (15:08 +1100)]
vmcore, procfs: introduce a flag to distinguish objects copied in 2nd kernel
The part of dump target memory is copied into the 2nd kernel if it doesn't
satisfy mmap()'s page-size boundary requirement. To distinguish such
copied object from usual old memory, a flag MEM_TYPE_CURRENT_KERNEL is
introduced. If this flag is set, the object is considered to have been
copied into a buffer on the 2nd kernel.
HATAYAMA Daisuke [Wed, 20 Mar 2013 04:08:34 +0000 (15:08 +1100)]
vmcore: round up buffer size of ELF headers by PAGE_SIZE
To satisfy mmap() page-size boundary requirement, round up buffer size of
ELF headers by PAGE_SIZE. The resulting value becomes offset of ELF note
segments and it's assigned in unique PT_NOTE program header entry.
Also, some part that assumes past ELF headers' size is replaced by this
new rounded-up value.
HATAYAMA Daisuke [Wed, 20 Mar 2013 04:08:34 +0000 (15:08 +1100)]
vmcore: allocate buffer for ELF headers on page-size alignment
Allocate buffer for ELF headers on page-size aligned boudary to satisfy
mmap() requirement. For this, __get_free_pages() is used instead of
kmalloc().
Also, later patch will decrease actually used buffer size for ELF headers,
so it's necessary to keep original buffer size and actually used buffer
size separately. elfcorebuf_sz_orig keeps the original one and
elfcorebuf_sz the actually used one.
HATAYAMA Daisuke [Wed, 20 Mar 2013 04:08:34 +0000 (15:08 +1100)]
vmcore, sysfs: export ELF note segment size instead of vmcoreinfo data size
Currently, vmcoreinfo exports data part only, but kexec-tool sets it in
p_memsz member as a whole ELF note segment size. Due to this, it would be
no problem on the current ELF note segment size, but if it grows in the
future, then read possibly doesn't reach ELF note header in larger p_memsz
position, failing to read a whole ELF segment.
Note: kexec-tools assigns PAGE_SIZE to p_memsz for other ELF note types.
Due to the above reason, the same issue occurs if actual ELF note data
exceeds (PAGE_SIZE - 2 * KEXEC_NOTE_HEAD_BYTES).
HATAYAMA Daisuke [Wed, 20 Mar 2013 04:08:34 +0000 (15:08 +1100)]
vmcore: rearrange program headers without assuming consecutive PT_NOTE entries
Current code assumes all PT_NOTE headers are placed at the beginning of
program header table and they are consecutive. But the assumption could
be broken by future changes on either kexec-tools or the 1st kernel. This
patch removes the assumption and rearranges program headers as the
following conditions are satisfied:
- PT_NOTE entry is unique at the first entry,
- the order of program headers are unchanged during this
rearrangement, only their positions are changed in positive
direction.
- unused part that occurs in the bottom of program headers are filled
with 0.
Also, this patch adds one exceptional case where the number of PT_NOTE
entries is somehow 0. Then, immediately go out of the function.
HATAYAMA Daisuke [Wed, 20 Mar 2013 04:08:33 +0000 (15:08 +1100)]
vmcore: clean up by removing unnecessary variable
The variable j has int type but it's compared with u64 type.
Also, the purpose of the variable j is exactly what the variable real_sz
is used for now. Replace the variable j by the variable real_sz and
remove the variable j.
HATAYAMA Daisuke [Wed, 20 Mar 2013 04:08:33 +0000 (15:08 +1100)]
vmcore: reference e_phoff member explicitly to get position of program header table
Currently, read to /proc/vmcore is done by read_oldmem() that uses
ioremap/iounmap per a single page. For example, if memory is 1GB,
ioremap/iounmap is called (1GB / 4KB)-times, that is, 262144 times. This
causes big performance degradation.
In particular, the current main user of this mmap() is makedumpfile, which
not only reads memory from /proc/vmcore but also does other processing
like filtering, compression and IO work. Update of page table and the
following TLB flush makes such processing much slow; though I have yet to
make patch for makedumpfile and yet to confirm how it's improved.
To address the issue, this patch implements mmap() on /proc/vmcore to
improve read performance. My simple benchmark shows the improvement from
200 [MiB/sec] to over 50.0 [GiB/sec].
This patch:
Currently, the code assumes that position of program header table is next
to ELF header. But future change can break the assumption on kexec-tools
and the 1st kernel. To avoid worst case, reference e_phoff member
explicitly to get position of program header table in file-offset.
Nathan Zimmer [Wed, 20 Mar 2013 04:08:31 +0000 (15:08 +1100)]
procfs: improve scaling in proc
I am currently tracking a hotlock reported by a customer on a large
system, 512 cores. I am currently running 3.8-rc7 but the issue looks
like it has been this way for a very long time. The offending lock is
proc_dir_entry->pde_unload_lock.
This patch converts the lock to use rcu. However the pde_openers list
still is controlled by a spin lock. I tested on a 4096 machine and the
lock doesn't seem hot at least according to perf.
This is a refresh of what was orignally suggested by Eric Dumazet some
time ago. I have also taken in some comments from Andrew and several
other people whose names escape me but I am quite grateful too.
Supporting numbers, lower is better, they are from the test I posted earlier.
cpuinfo baseline Rcu
tasks read-sec read-sec
1 0.0141 0.0141
2 0.0140 0.0142
4 0.0140 0.0141
8 0.0145 0.0140
16 0.0553 0.0168
32 0.1688 0.0549
64 0.5017 0.1690
128 1.7005 0.5038
256 5.2513 2.0804
512 8.0529 3.0162
Signed-off-by: Nathan Zimmer <nzimmer@sgi.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Oleg Nesterov [Wed, 20 Mar 2013 04:08:31 +0000 (15:08 +1100)]
coredump: change wait_for_dump_helpers() to use wait_event_interruptible()
wait_for_dump_helpers() calls wake_up/kill_fasync from inside the
wait_event-like loop. This is not needed and in fact this is not strictly
correct, we can/should do this only once after we change pipe->writers.
We could even check if it becomes zero.
Change this code to use use wait_event_interruptible(), this can also help
to make this wait freezable.
With this patch we check pipe->readers without pipe_lock(), this is fine.
Once we see pipe->readers == 1 we know that the handler decremented the
counter, this is all we need.
Signed-off-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Mandeep Singh Baines <msb@chromium.org> Cc: Neil Horman <nhorman@redhat.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Oleg Nesterov [Wed, 20 Mar 2013 04:08:30 +0000 (15:08 +1100)]
coredump: introduce dump_interrupted()
By discussion with Mandeep.
Change dump_write(), dump_seek() and do_coredump() to check
signal_pending() and abort if it is true. dump_seek() does this only
before f_op->llseek(), otherwise it relies on dump_write().
We need this change to ensure that the coredump won't delay suspend, and
to ensure it reacts to SIGKILL "quickly enough", a core dump can take a
lot of time. In particular this can help oom-killer.
We add the new trivial helper, dump_interrupted() to add the comments and
to simplify the potential freezer changes. Perhaps it will have more
callers.
Ideally it should do try_to_freeze() but then we need the unpleasant
changes in dump_write() and wait_for_dump_helpers(). It is not trivial to
change dump_write() to restart if f_op->write() fails because of
freezing(). We need to handle the short writes, we need to clear
TIF_SIGPENDING (and we can't rely on recalc_sigpending() unless we change
it to check PF_DUMPCORE). And if the buggy f_op->write() sets
TIF_SIGPENDING we can not distinguish this case from the race with
freeze_task() + __thaw_task().
So we simply accept the fact that the freezer can truncate a core-dump but
at least you can reliably suspend. Hopefully we can tolerate this
unlikely case and the necessary complications doesn't worth a trouble.
But if we decide to make the coredumping freezable later we can do this on
top of this change.
Signed-off-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Mandeep Singh Baines <msb@chromium.org> Cc: Neil Horman <nhorman@redhat.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Oleg Nesterov [Wed, 20 Mar 2013 04:08:30 +0000 (15:08 +1100)]
coredump: sanitize the setting of signal->group_exit_code
Now that the coredumping process can be SIGKILL'ed, the setting of
->group_exit_code in do_coredump() can race with complete_signal() and
SIGKILL or 0x80 can be "lost", or wait(status) can report status ==
SIGKILL | 0x80.
But the main problem is that it is not clear to me what should we do if
binfmt->core_dump() succeeds but SIGKILL was sent, that is why this patch
comes as a separate change.
This patch adds 0x80 if ->core_dump() succeeds and the process was not
killed. But perhaps we can (should?) re-set ->group_exit_code changed by
SIGKILL back to "siginfo->si_signo |= 0x80" in case when core_dumped == T.
Signed-off-by: Oleg Nesterov <oleg@redhat.com> Tested-by: Mandeep Singh Baines <msb@chromium.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Neil Horman <nhorman@redhat.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Roland McGrath <roland@hack.frob.com> Cc: Tejun Heo <tj@kernel.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Oleg Nesterov [Wed, 20 Mar 2013 04:08:30 +0000 (15:08 +1100)]
coredump: ensure that SIGKILL always kills the dumping thread
prepare_signal() blesses SIGKILL sent to the dumping process but this
signal can be "lost" anyway. The problems is, complete_signal() sees
SIGNAL_GROUP_EXIT and skips the "kill them all" logic. And even if the
dumping process is single-threaded (so the target is always "correct"),
the group-wide SIGKILL is not recorded in task->pending and thus
__fatal_signal_pending() won't be true. A multi-threaded case has even
more problems.
And even ignoring all technical details, SIGNAL_GROUP_EXIT doesn't look
right to me. This coredumping process is not exiting yet, it can do a lot
of work dumping the core.
With this patch the dumping process doesn't have SIGNAL_GROUP_EXIT, we set
signal->group_exit_task instead. This makes signal_group_exit() true and
thus this should equally close the races with exit/exec/stop but allows to
kill the dumping thread reliably.
Notes:
- It is not clear what should we do with ->group_exit_code
if the dumper was killed, see the next change.
- we need more (hopefully straightforward) changes to ensure
that SIGKILL actually interrupts the coredump. Basically we
need to check __fatal_signal_pending() in dump_write() and
dump_seek().
Signed-off-by: Oleg Nesterov <oleg@redhat.com> Tested-by: Mandeep Singh Baines <msb@chromium.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Neil Horman <nhorman@redhat.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Roland McGrath <roland@hack.frob.com> Cc: Tejun Heo <tj@kernel.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Oleg Nesterov [Wed, 20 Mar 2013 04:08:29 +0000 (15:08 +1100)]
coredump: only SIGKILL should interrupt the coredumping task
There are 2 well known and ancient problems with coredump/signals, and a
lot of related bug reports:
- do_coredump() clears TIF_SIGPENDING but of course this can't help
if, say, SIGCHLD comes after that.
In this case the coredump can fail unexpectedly. See for example
wait_for_dump_helper()->signal_pending() check but there are other
reasons.
- At the same time, dumping a huge core on the slow media can take a
lot of time/resources and there is no way to kill the coredumping
task reliably. In particular this is not oom_kill-friendly.
This patch tries to fix the 1st problem, and makes the preparation for the
next changes.
We add the new SIGNAL_GROUP_COREDUMP flag set by zap_threads() to indicate
that this process dumps the core. prepare_signal() checks this flag and
nacks any signal except SIGKILL.
Note that this check tries to be conservative, in the long term we should
probably treat the SIGNAL_GROUP_EXIT case equally but this needs more
discussion. See marc.info/?l=linux-kernel&m=120508897917439
Notes:
- recalc_sigpending() doesn't check SIGNAL_GROUP_COREDUMP.
The patch assumes that dump_write/etc paths should never
call it, but we can change it as well.
- There is another source of TIF_SIGPENDING, freezer. This
will be addressed separately.
Signed-off-by: Oleg Nesterov <oleg@redhat.com> Tested-by: Mandeep Singh Baines <msb@chromium.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Neil Horman <nhorman@redhat.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Roland McGrath <roland@hack.frob.com> Cc: Tejun Heo <tj@kernel.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Lucas De Marchi [Wed, 20 Mar 2013 04:08:29 +0000 (15:08 +1100)]
kmod: remove call_usermodehelper_fns()
This function suffers from not being able to determine if the cleanup is
called in case it returns -ENOMEM. Nobody is using it anymore, so let's
remove it.
Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi> Cc: Oleg Nesterov <oleg@redhat.com> Cc: David Howells <dhowells@redhat.com> Cc: James Morris <james.l.morris@oracle.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Tejun Heo <tj@kernel.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Lucas De Marchi [Wed, 20 Mar 2013 04:08:29 +0000 (15:08 +1100)]
usermodehelper: split remaining calls to call_usermodehelper_fns()
These are the only users of call_usermodehelper_fns(). This function
suffers from not being able to determine if the cleanup is called. Even
if in this places the cleanup pointer is NULL, convert them to use the
separate call_usermodehelper_setup() + call_usermodehelper_exec()
functions so we can remove the _fns variant.
Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi> Cc: Oleg Nesterov <oleg@redhat.com> Cc: David Howells <dhowells@redhat.com> Cc: James Morris <james.l.morris@oracle.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Tejun Heo <tj@kernel.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Lucas De Marchi [Wed, 20 Mar 2013 04:08:29 +0000 (15:08 +1100)]
coredump: remove trailling whitespace
Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi> Cc: Oleg Nesterov <oleg@redhat.com> Cc: David Howells <dhowells@redhat.com> Cc: James Morris <james.l.morris@oracle.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Tejun Heo <tj@kernel.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Lucas De Marchi [Wed, 20 Mar 2013 04:08:28 +0000 (15:08 +1100)]
KEYS: split call to call_usermodehelper_fns()
Use call_usermodehelper_setup() + call_usermodehelper_exec() instead of
calling call_usermodehelper_fns(). In case there's an OOM in this last
function the cleanup function may not be called - in this case we would
miss a call to key_put().
Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi> Cc: Oleg Nesterov <oleg@redhat.com> Cc: David Howells <dhowells@redhat.com> Acked-by: James Morris <james.l.morris@oracle.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Tejun Heo <tj@kernel.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Lucas De Marchi [Wed, 20 Mar 2013 04:08:28 +0000 (15:08 +1100)]
kmod: split call to call_usermodehelper_fns()
Use call_usermodehelper_setup() + call_usermodehelper_exec() instead of
calling call_usermodehelper_fns(). In case the latter returns -ENOMEM the
cleanup function may had not been called - in this case we would not free
argv and module_name.
Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi> Cc: Oleg Nesterov <oleg@redhat.com> Cc: David Howells <dhowells@redhat.com> Cc: James Morris <james.l.morris@oracle.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Tejun Heo <tj@kernel.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: David Howells <dhowells@redhat.com> Cc: James Morris <james.l.morris@oracle.com> Cc: Lucas De Marchi <lucas.demarchi@profusion.mobi> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Lucas De Marchi [Wed, 20 Mar 2013 04:08:27 +0000 (15:08 +1100)]
usermodehelper: export call_usermodehelper_exec() and call_usermodehelper_setup()
call_usermodehelper_setup() + call_usermodehelper_exec() need to be called
instead of call_usermodehelper_fns() when the cleanup function needs to be
called even when an ENOMEM error occurs. In this case using
call_usermodehelper_fns() the user can't distinguish if the cleanup
function was called or not.
Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Cc: David Howells <dhowells@redhat.com> Cc: James Morris <james.l.morris@oracle.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Tejun Heo <tj@kernel.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Andrey Vagin [Wed, 20 Mar 2013 04:08:27 +0000 (15:08 +1100)]
selftest: add a test case for PTRACE_PEEKSIGINFO
* Dump signals from process-wide and per-thread queues with
different sizes of buffers.
* Check error paths for buffers with restricted permissions. A part of
buffer or a whole buffer is for read-only.
* Try to get nonexistent signal.
Signed-off-by: Andrew Vagin <avagin@openvz.org> Cc: Roland McGrath <roland@redhat.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Cc: David Howells <dhowells@redhat.com> Cc: Dave Jones <davej@redhat.com> Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> Cc: Pavel Emelyanov <xemul@parallels.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Pedro Alves <palves@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Andrey Vagin [Wed, 20 Mar 2013 04:08:27 +0000 (15:08 +1100)]
ptrace: add ability to retrieve signals without removing from a queue (v4)
This patch adds a new ptrace request PTRACE_PEEKSIGINFO.
This request is used to retrieve information about pending signals
starting with the specified sequence number. Siginfo_t structures are
copied from the child into the buffer starting at "data".
The argument "addr" is a pointer to struct ptrace_peeksiginfo_args.
struct ptrace_peeksiginfo_args {
u64 off; /* from which siginfo to start */
u32 flags;
s32 nr; /* how may siginfos to take */
};
"nr" has type "s32", because ptrace() returns "long", which has 32 bits on
i386 and a negative values is used for errors.
Currently here is only one flag PTRACE_PEEKSIGINFO_SHARED for dumping
signals from process-wide queue. If this flag is not set, signals are
read from a per-thread queue.
The request PTRACE_PEEKSIGINFO returns a number of dumped signals. If a
signal with the specified sequence number doesn't exist, ptrace returns
zero. The request returns an error, if no signal has been dumped.
Errors:
EINVAL - one or more specified flags are not supported or nr is negative
EFAULT - buf or addr is outside your accessible address space.
A result siginfo contains a kernel part of si_code which usually striped,
but it's required for queuing the same siginfo back during restore of
pending signals.
This functionality is required for checkpointing pending signals. Pedro
Alves suggested using it in "gdb" to peek at pending signals. gdb already
uses PTRACE_GETSIGINFO to get the siginfo for the signal which was already
dequeued. This functionality allows gdb to look at the pending signals
which were not reported yet.
The prototype of this code was developed by Oleg Nesterov.
Signed-off-by: Andrew Vagin <avagin@openvz.org> Cc: Roland McGrath <roland@redhat.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Cc: David Howells <dhowells@redhat.com> Cc: Dave Jones <davej@redhat.com> Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> Cc: Pavel Emelyanov <xemul@parallels.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Pedro Alves <palves@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Namjae Jeon [Wed, 20 Mar 2013 04:08:26 +0000 (15:08 +1100)]
fat (exportfs): rebuild directory-inode if fat_dget()
This patch enables rebuilding of directory inodes which are not present in
the cache.This is done by traversing the disk clusters to find the
directory entry of the parent directory and using its i_pos to build the
inode.
The traversal is done by fat_scan_logstart() which is similar to
fat_scan() but matches i_pos values instead of names.fat_scan_logstart()
needs an inode parameter to work, for which a dummy inode is created by
it's caller fat_rebuild_parent(). This dummy inode is destroyed after the
traversal completes.
All this is done only if the nostale_ro nfs mount option is specified.
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com> Signed-off-by: Ravishankar N <ravi.n1@samsung.com> Signed-off-by: Amit Sahrawat <a.sahrawat@samsung.com> Acked-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Namjae Jeon [Wed, 20 Mar 2013 04:08:26 +0000 (15:08 +1100)]
fat (exportfs): rebuild inode if ilookup() fails
If the cache lookups fail,use the i_pos value to find the directory entry
of the inode and rebuild the inode.Since this involves accessing the FAT
media, do this only if the nostale_ro nfs mount option is specified.
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com> Signed-off-by: Ravishankar N <ravi.n1@samsung.com> Signed-off-by: Amit Sahrawat <a.sahrawat@samsung.com> Acked-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Namjae Jeon [Wed, 20 Mar 2013 04:08:26 +0000 (15:08 +1100)]
fat: restructure export_operations
Define two nfs export_operation structures,one for 'stale_rw' mounts and
the other for 'nostale_ro'. The latter uses i_pos as a basis for encoding
and decoding file handles.
Also, assign i_pos to kstat->ino. The logic for rebuilding the inode is
added in the subsequent patches.
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com> Signed-off-by: Ravishankar N <ravi.n1@samsung.com> Signed-off-by: Amit Sahrawat <a.sahrawat@samsung.com> Acked-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Namjae Jeon [Wed, 20 Mar 2013 04:08:25 +0000 (15:08 +1100)]
fat: introduce 2 new values for the -o nfs mount option
This patchset eliminates the client side ESTALE errors when a FAT
partition exported over NFS has its dentries evicted from the cache. The
idea is to find the on-disk location_'i_pos' of the dirent of the inode
that has been evicted and use it to rebuild the inode.
This patch:
Provide two possible values 'stale_rw' and 'nostale_ro' for the -o nfs
mount option.The first one allows all file operations but does not reduce
ESTALE errors on memory constrained systems. The second one eliminates
ESTALE errors but mounts the filesystem as read-only. Not specifying a
value defaults to 'stale_rw'.
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com> Signed-off-by: Ravishankar N <ravi.n1@samsung.com> Signed-off-by: Amit Sahrawat <a.sahrawat@samsung.com> Acked-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
fs/hfsplus/bfind.c: In function 'hfs_find_1st_rec_by_cnid':
(1) include/uapi/linux/swab.h:60:2: warning: 'search_cnid' may be used uninitialized in this function [-Wmaybe-uninitialized]
(2) include/uapi/linux/swab.h:60:2: warning: 'cur_cnid' may be used uninitialized in this function [-Wmaybe-uninitialized]
Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Jingoo Han [Wed, 20 Mar 2013 04:08:23 +0000 (15:08 +1100)]
rtc: rtc-sh: switch to using SIMPLE_DEV_PM_OPS
Switch to using the SIMPLE_DEV_PM_OPS macro to declare the driver's
pm_ops. It reduces code size. Also, CONFIG_PM_SLEEP is added to prevent
build warning when CONFIG_PM_SLEEP is not selected.
Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Jingoo Han [Wed, 20 Mar 2013 04:08:12 +0000 (15:08 +1100)]
drivers/rtc/rtc-s3c.c: convert s3c_rtc to dev_pm_ops
Instead of using legacy suspend/resume methods, using newer dev_pm_ops
structure allows better control over power management. Also, 'wake_en'
variable is moved, because it is only used when CONFIG_PM_SLEEP is
enabled.
Signed-off-by: Jingoo Han <jg1.han@samsung.com> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bertrand Achard [Wed, 20 Mar 2013 04:08:11 +0000 (15:08 +1100)]
drivers/rtc/rtc-ds1307.c: long block operations bugfix
The rtc-ds1307 driver does not properly handle block operations bigger
than 32 bytes in either of the two modes supported (SMbus native, or
emulated if not supported by the SMbus platform driver).
It also does not properly handle userland-supplied input (block operation
length) through sysfs and may suffer a type of buffer overrun.
The driver has been modified with proper input validation, buffer sizes,
and now splits block transfers bigger than 32 bytes into separate
transfers.
Explanation : Buffer size allocated is I2C_SMBUS_BLOCK_MAX which equals to
32 as per the SMbus spec. Reads and write may be up to 56 bytes (to the
NVRAM). This patch allocated a 255 byte buffer, the maximum allowable
(address is an u8). It's not only a buffer problem, SMbus only supports
up to 32 bytes transfer at once, so it's needed to split bigger transfers.
Patch successfully tested on 3.2.27; cleanly applies on 3.7-rc4.
[akpm@linux-foundation.org: rework code to avoid 80-column overflows] Signed-off-by: Bertrand Achard <ba@cykian.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Laxman Dewangan [Wed, 20 Mar 2013 04:08:11 +0000 (15:08 +1100)]
drivers/rtc/rtc-tegra.c: use managed rtc_device_register()
Use devm_rtc_device_register() for registering RTC device. This will
reduce the code for unregistering RTC device in cleanup path and remove
the implementation of remove callback of platform driver.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Cc: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Laxman Dewangan [Wed, 20 Mar 2013 04:08:11 +0000 (15:08 +1100)]
drivers/rtc/rtc-tegra.c: use struct dev_pm_ops for power management
Make the Tegra RTC controller driver define its PM callbacks through a
struct dev_pm_ops object rather than by using legacy PM hooks in struct
platform_driver.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Cc: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Laxman Dewangan [Wed, 20 Mar 2013 04:08:10 +0000 (15:08 +1100)]
drivers/rtc/rtc-tegra.c: protect suspend/resume callbacks with CONFIG_PM_SLEEP
CONFIG_PM doesn't actually enable any of the PM callbacks, it only allows
to enable CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME. This means if CONFIG_PM
is used to protect system sleep callbacks then it may end up unreferenced
if only runtime PM is enabled. Hence protecting sleep callbacks with
CONFIG_PM_SLEEP.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Cc: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
The "fix set time sync time issue" adds calls to udelay(), but
doesn't add the include file. End result is build breakage:
drivers/rtc/rtc-pxa.c: In function 'pxa_rtc_set_time':
drivers/rtc/rtc-pxa.c:267:2: error: implicit declaration of function 'udelay' [-Werror=implicit-function-declaration]
Signed-off-by: Olof Johansson <olof@lixom.net> Cc: Leo Song <liangs@marvell.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
projects / karo-tx-linux.git / log