Peter Hurley [Sun, 10 Mar 2013 10:55:23 +0000 (21:55 +1100)]
ipc: refactor msg list search into separate function
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Acked-by: Stanislav Kinsbursky <skinsbursky@parallels.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Peter Hurley [Sun, 10 Mar 2013 10:55:23 +0000 (21:55 +1100)]
ipc: simplify msg list search
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Acked-by: Stanislav Kinsbursky <skinsbursky@parallels.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Peter Hurley [Sun, 10 Mar 2013 10:55:23 +0000 (21:55 +1100)]
ipc: implement MSG_COPY as a new receive mode
Teach the helper routines about MSG_COPY so that msgtyp is preserved as
the message number to copy.
The security functions affected by this change were audited and no
additional changes are necessary.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Acked-by: Stanislav Kinsbursky <skinsbursky@parallels.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Peter Hurley [Sun, 10 Mar 2013 10:55:22 +0000 (21:55 +1100)]
ipc: remove msg handling from queue scan
In preparation for refactoring the queue scan into a separate
function, relocate msg copying.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Acked-by: Stanislav Kinsbursky <skinsbursky@parallels.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Peter Hurley [Sun, 10 Mar 2013 10:55:22 +0000 (21:55 +1100)]
ipc: set EFAULT as default error in load_msg()
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Acked-by: Stanislav Kinsbursky <skinsbursky@parallels.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Peter Hurley [Sun, 10 Mar 2013 10:55:22 +0000 (21:55 +1100)]
ipc: tighten msg copy loops
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Acked-by: Stanislav Kinsbursky <skinsbursky@parallels.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Acked-by: Stanislav Kinsbursky <skinsbursky@parallels.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Peter Hurley [Sun, 10 Mar 2013 10:55:21 +0000 (21:55 +1100)]
ipc: clamp with min()
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Acked-by: Stanislav Kinsbursky <skinsbursky@parallels.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Tejun Heo [Sun, 10 Mar 2013 10:55:21 +0000 (21:55 +1100)]
idr: deprecate idr_pre_get() and idr_get_new[_above]()
Now that all in-kernel users are converted to ues the new alloc
interface, mark the old interface deprecated. We should be able to
remove these in a few releases.
Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Tejun Heo [Sun, 10 Mar 2013 10:55:21 +0000 (21:55 +1100)]
tidspbridge: convert to idr_alloc()
idr_get_new*() and friends are about to be deprecated. Convert to the
new idr_alloc() interface.
There are some peculiarities and possible bugs in the converted
functions. This patch preserves those.
* drv_insert_node_res_element() returns -ENOMEM on alloc failure,
-EFAULT if id space is exhausted. -EFAULT is at best misleading.
* drv_proc_insert_strm_res_element() is even weirder. It returns
-EFAULT if kzalloc() fails, -ENOMEM if idr preloading fails and
-EPERM if id space is exhausted. What's going on here?
* drv_proc_insert_strm_res_element() doesn't free *pstrm_res after
failure.
Tejun Heo [Sun, 10 Mar 2013 10:55:20 +0000 (21:55 +1100)]
mlx4: remove leftover idr_pre_get() call
6a9200603d ("IB/mlx4: convert to idr_alloc()") forgot to remove
idr_pre_get() call in mlx4_ib_cm_paravirt_init(). It's unnecessary
and idr_pre_get() will soon be deprecated. Remove it.
Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Jack Morgenstein <jackm@dev.mellanox.co.il> Cc: Or Gerlitz <ogerlitz@mellanox.com> Cc: Roland Dreier <roland@purestorage.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Tejun Heo [Sun, 10 Mar 2013 10:55:20 +0000 (21:55 +1100)]
nfsd: convert to idr_alloc()
idr_get_new*() and friends are about to be deprecated. Convert to the
new idr_alloc() interface.
Only compile-tested.
Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: J. Bruce Fields <bfields@redhat.com> Tested-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Nathan Zimmer [Sun, 10 Mar 2013 10:55:18 +0000 (21:55 +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 [Sun, 10 Mar 2013 10:55:18 +0000 (21:55 +1100)]
coredump: make wait_for_dump_helpers() freezable
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.
With this change it is trivial to convert this code to use
wait_event_freezable() and make this function freezable/killable, only
SIGKILL can set TIF_SIGPENDING.
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.
Note: wait_event_freezable() is "strange", perhaps it should be changed or
simply removed. In the latter case we can change this code again to use
freezer_do_not_count + wait_event_interruptible.
Signed-off-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Mandeep Singh Baines <msb@chromium.org> Cc: Neil Horman <nhorman@redhat.com> Cc: Tejun Heo <tj@kernel.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl>a Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Oleg Nesterov [Sun, 10 Mar 2013 10:55:17 +0000 (21:55 +1100)]
freezer: do not send a fake signal to a PF_DUMPCORE thread
A coredumping thread can't be frozen anyway but the fake signal sent by
freeze_task() can confuse dump_write/wait_for_dump_helpers/etc and
interrupt the coredump.
We are going to make the do_coredump() paths freezable but the fake
TIF_SIGPENDING doesn't help, it only makes sense when we assume that the
target can return to user-mode and call get_signal_to_deliver().
Change freeze_task() to check PF_DUMPCORE along with PF_KTHREAD. We need
to recheck PF_DUMPCORE under ->siglock to avoid the race with
zap_threads() which can set this flag right before we take the lock.
Signed-off-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Mandeep Singh Baines <msb@chromium.org> Cc: Neil Horman <nhorman@redhat.com> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Oleg Nesterov [Sun, 10 Mar 2013 10:55:17 +0000 (21:55 +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 [Sun, 10 Mar 2013 10:55:16 +0000 (21:55 +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 [Sun, 10 Mar 2013 10:55:16 +0000 (21:55 +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>
Andrey Vagin [Sun, 10 Mar 2013 10:55:16 +0000 (21:55 +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 [Sun, 10 Mar 2013 10:55:16 +0000 (21:55 +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>
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>
Bertrand Achard [Sun, 10 Mar 2013 10:55:15 +0000 (21:55 +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>
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>
Jingoo Han [Sun, 10 Mar 2013 10:54:59 +0000 (21:54 +1100)]
drivers/rtc/class.c: use struct device as the first argument for devm_rtc_device_register()
Other devm_* APIs use 'struct device *dev' as the first argument. Thus,
in order to sync with other devm_* functions, struct device is used as the
first argument for devm_rtc_device_register().
Signed-off-by: Jingoo Han <jg1.han@samsung.com> Cc: Tejun Heo <tj@kernel.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Jingoo Han [Sun, 10 Mar 2013 10:54:58 +0000 (21:54 +1100)]
drivers/rtc/rtc-v3020.c: use gpio_request_array()
Using gpio_request_array()/gpio_free_array() can make the code simpler
because it can set the direction and initial value in one shot and the for
loop is unnecessary.
Also, struct v3020_gpio is removed, because the struct v3020_gpio is
replaced with struct gpio.
Signed-off-by: Jingoo Han <jg1.han@samsung.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Igor Grinberg <grinberg@compulab.co.il> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
projects / karo-tx-linux.git / log