- 01 May, 2013 40 commits
-
-
Randy Dunlap authored
Make virtualization drivers be logically grouped together (physically near each other) in the kconfig menu by moving "Virtualization drivers" to be near "Virtio drivers", Microsort Hyper-V, and Xen driver support. This is just a user-friendly, visual search change. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Alexander Graf <agraf@suse.de> Cc: Stuart Yoder <stuart.yoder@freescale.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Stephen Boyd authored
The help text for this config is duplicated across the x86, parisc, and s390 Kconfig.debug files. Arnd Bergman noted that the help text was slightly misleading and should be fixed to state that enabling this option isn't a problem when using pre 4.4 gcc. To simplify the rewording, consolidate the text into lib/Kconfig.debug and modify it there to be more explicit about when you should say N to this config. Also, make the text a bit more generic by stating that this option enables compile time checks so we can cover architectures which emit warnings vs. ones which emit errors. The details of how an architecture decided to implement the checks isn't as important as the concept of compile time checking of copy_from_user() calls. While we're doing this, remove all the copy_from_user_overflow() code that's duplicated many times and place it into lib/ so that any architecture supporting this option can get the function for free. Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Acked-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Ingo Molnar <mingo@kernel.org> Acked-by:
H. Peter Anvin <hpa@zytor.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Acked-by:
Helge Deller <deller@gmx.de> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Chris Metcalf <cmetcalf@tilera.com> Signed-off-by:
-
zhangwei(Jovi) authored
Macro FIX_SIZE is same as PAGE_ALIGN at present, so use PAGE_ALIGN instead. Thanks Andrew found this. Signed-off-by:
zhangwei(Jovi) <jovi.zhangwei@huawei.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Eric Dumazet <edumazet@google.com> Signed-off-by:
-
zhangwei(Jovi) authored
It's better to place FIX_SIZE macro in relay.c, instead of relay.h Signed-off-by:
-
zhangwei(Jovi) authored
Currently argument `actor' is never used in the relay reading path, so remove it. Signed-off-by:
-
Wei Yongjun authored
Use platform_device_put() instead of platform_device_unregister() if platform_device_add() fail, and platform_device_del() should be used in the error handling case after platform_device_add() success. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Cc: Evgeniy Polyakov <zbr@ioremap.net> Cc: Greg KH <greg@kroah.com> Cc: Neil Brown <neilb@suse.de> Signed-off-by:
-
Wei Yongjun authored
Use platform_device_put() instead of platform_device_unregister() if platform_device_add() fail, and platform_device_del() should be used in the error handling case after platform_device_add() success. Signed-off-by:
-
Wei Yongjun authored
Use platform_device_put() instead of platform_device_unregister() if platform_device_add() fail, and platform_device_del() should be used in the error handling case after platform_device_add() success. Signed-off-by:
-
Wei Yongjun authored
Use platform_device_put() instead of platform_device_unregister() if platform_device_add() fails, and also add the return value check of platform_device_add_data(). Signed-off-by:
-
Jingoo Han authored
r592_pm_ops is not exported. Also, CONFIG_PM_SLEEP is used to remove unnecessary ifdefs. Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by:
-
liguang authored
Signed-off-by:
liguang <lig.fnst@cn.fujitsu.com> Cc: Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
liguang authored
Signed-off-by:
-
Fengguang Wu authored
drivers/pps/kc.c:37:1: sparse: symbol 'pps_kc_hardpps_lock' was not declared. Should it be static? drivers/pps/kc.c:39:19: sparse: symbol 'pps_kc_hardpps_dev' was not declared. Should it be static? drivers/pps/kc.c:40:5: sparse: symbol 'pps_kc_hardpps_mode' was not declared. Should it be static? Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Cc: Rodolfo Giometti <giometti@enneenne.com> Signed-off-by:
-
Florian Fainelli authored
Make CONFIG_PPS_DEBUG and CONFIG_NTP_PPS be hidden if CONFIG_PPS is not selected, so that we are not prompted for these configuration options if CONFIG_PPS is not set. Signed-off-by:
Florian Fainelli <florian@openwrt.org> Cc: Rodolfo Giometti <giometti@enneenne.com> Signed-off-by:
-
Mihnea Dobrescu-Balaur authored
Signed-off-by:
Mihnea Dobrescu-Balaur <mihneadb@gmail.com> Cc: Ed Cashin <ecashin@coraid.com> Signed-off-by:
-
Michal Belczyk authored
Raise the default max request size for nbd to 128KB (from 127KB) to get it 4KB aligned. This patch also allows the max request size to be increased (via /sys/block/nbd<x>/queue/max_sectors_kb) to 32MB. The patch makes nbd network traffic more efficient by: - reducing request fragmentation (4KB alignment) - reducing the number of requests (fewer round trips, less network overhead) Especially in high latency networks, larger request size can make a dramatic Signed-off-by:
Paul Clements <paul.clements@steeleye.com> Signed-off-by:
Michal Belczyk <belczyk@bsd.krakow.pl> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Raphael S.Carvalho authored
Move BITS_PER_PAGE from pid_namespace.c to pid_namespace.h, since we can simplify the define PID_MAP_ENTRIES by using the BITS_PER_PAGE. [akpm@linux-foundation.org: kernel/pid.c:54:1: warning: "BITS_PER_PAGE" redefined] Signed-off-by:
Raphael S.Carvalho <raphael.scarv@gmail.com> Signed-off-by:
-
Raphael S. Carvalho authored
find_next_offset() searches for an available "cleaned bit" in the respective pid bitmap (page), so returns the offset if found, otherwise it returns a value equals to BITS_PER_PAGE. For example, suppose find_next_offset didn't find any available bit, so there's no purpose to call mk_pid (Wasteful Cpu Cycles). Therefore, I found it could be better to call mk_pid after the checking (offset < BITS_PER_PAGE) returned sucessfully! Another point: If (offset < BITS_PER_PAGE) results in a "failure", then mk_pid would be called again afterwards. [akpm@linux-foundation.org: simplify code] Signed-off-by:
-
Davidlohr Bueso authored
Signed-off-by:
Davidlohr Bueso <davidlohr.bueso@hp.com> Reviewed-by:
Michel Lespinasse <walken@google.com> Signed-off-by:
-
Davidlohr Bueso authored
Account for the rbtree having 2**bh(v)-1 internal nodes. While this can be seen as a consequence of other checks, Michel states that it nicely sums up what the other properties are for. Signed-off-by:
-
Zhang Yanfei authored
Simplify the logic of variable assignments. [akpm@linux-foundation.org: replace min_t with min, remove unneeded casts] Signed-off-by:
Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Reviewed-by:
Simon Horman <horms@verge.net.au> Cc: Joe Perches <joe@perches.com> Signed-off-by:
-
Zhang Yanfei authored
The types of the following local variables: - ubytes/mbytes in kimage_load_crash_segment()/kimage_load_normal_segment() - r in vmcoreinfo_append_str() are wrong, so fix them. Signed-off-by:
-
Oleg Nesterov authored
threadgroup_lock() takes signal->cred_guard_mutex to ensure that thread_group_leader() is stable. This doesn't look nice, the scope of this lock in do_execve() is huge. And as Dave pointed out this can lead to deadlock, we have the following dependencies: do_execve: cred_guard_mutex -> i_mutex cgroup_mount: i_mutex -> cgroup_mutex attach_task_by_pid: cgroup_mutex -> cred_guard_mutex Change de_thread() to take threadgroup_change_begin() around the switch-the-leader code and change threadgroup_lock() to avoid ->cred_guard_mutex. Note that de_thread() can't sleep with ->group_rwsem held, this can obviously deadlock with the exiting leader if the writer is active, so it does threadgroup_change_end() before schedule(). Reported-by:
Dave Jones <davej@redhat.com> Acked-by:
Tejun Heo <tj@kernel.org> Acked-by:
Li Zefan <lizefan@huawei.com> Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Oleg Nesterov authored
set_task_comm() does memset() + wmb() before strlcpy(). This buys nothing and to add to the confusion, the comment is wrong. - We do not need memset() to be "safe from non-terminating string reads", the final char is always zero and we never change it. - wmb() is paired with nothing, it cannot prevent from printing the mixture of the old/new data unless the reader takes the lock. Signed-off-by:
-
David Rientjes authored
Currently, a write to a procfs file will return the number of bytes successfully written. If the actual string is longer than this, the remainder of the string will not be be written and userspace will complete the operation by issuing additional write()s. Hence $ echo -n "abcdefghijklmnopqrs" > /proc/self/comm results in $ cat /proc/$$/comm pqrs since the final four bytes were written with a second write() since TASK_COMM_LEN == 16. This is obviously an undesired result and not equivalent to prctl(PR_SET_NAME). The implementation should not need to know the definition of TASK_COMM_LEN. This patch truncates the string to the first TASK_COMM_LEN bytes and returns the bytes written as the length of the string written so the second write() is suppressed. $ cat /proc/$$/comm abcdefghijklmno Signed-off-by:
David Rientjes <rientjes@google.com> Acked-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
-
Oleg Nesterov authored
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:
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:
-
Oleg Nesterov authored
Cleanup. Every linux_binfmt->core_dump() sets PF_DUMPCORE, move this into zap_threads() called by do_coredump(). Signed-off-by:
-
Oleg Nesterov authored
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 authored
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 authored
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 authored
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:
-
Lucas De Marchi authored
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:
-
Lucas De Marchi authored
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 authored
Signed-off-by:
-
Lucas De Marchi authored
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:
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:
-
Lucas De Marchi authored
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 authored
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. [akpm@linux-foundation.org: export call_usermodehelper_setup() to modules] Signed-off-by:
-
Andrey Vagin authored
* 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:
-
Andrey Vagin authored
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: -
Vyacheslav Dubeyko authored
Signed-off-by:
Vyacheslav Dubeyko <slava@dubeyko.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Hin-Tak Leung <htl10@users.sourceforge.net> Signed-off-by:
-
