- 31 Jul, 2012 40 commits
-
-
Will Deacon authored
The msgsnd and msgrcv system calls use size_t to represent the size of the message being transferred. POSIX states that values of msgsz greater than SSIZE_MAX cause the result to be implementation-defined. On Linux, this equates to returning -EINVAL if (long) msgsz < 0. For compat tasks where !CONFIG_ARCH_WANT_OLD_COMPAT_IPC and compat_size_t is smaller than size_t, negative size values passed from userspace will be interpreted as positive values by do_msg{rcv,snd} and will fail to exit early with -EINVAL. This patch changes the compat prototypes for msg{rcv,snd} so that the message size is represented as a compat_ssize_t, which we cast to the native ssize_t type for the core IPC code. Cc: Arnd Bergmann <arnd@arndb.de> Acked-by:Chris Metcalf <cmetcalf@tilera.com> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Will Deacon authored
Commit 48b25c43 ("ipc: provide generic compat versions of IPC syscalls") added a new ARCH_WANT_OLD_COMPAT_IPC config option for architectures to select if their compat target requires the old IPC syscall interface. For architectures (such as AArch64) that do not require the internal calling conventions provided by this option, but have a compat target where the C library passes the IPC_64 flag explicitly, compat_ipc_parse_version no longer strips out the flag before calling the native system call implementation, resulting in unknown SHM/IPC commands and -EINVAL being returned to userspace. This patch separates the selection of the internal calling conventions for the IPC syscalls from the version parsing, allowing architectures to select __ARCH_WANT_COMPAT_IPC_PARSE_VERSION if they want to use version parsing whilst retaining the newer syscall calling conventions. Acked-by:
-
Will Deacon authored
If the SHMLBA definition for a native task differs from the definition for a compat task, the do_shmat() function would need to handle both. This patch introduces COMPAT_SHMLBA, which is used by the compat shmat syscall when calling the ipc code and allows architectures such as AArch64 (where the native SHMLBA is 64k but the compat (AArch32) definition is 16k) to provide the correct semantics for compat IPC system calls. Cc: David S. Miller <davem@davemloft.net> Cc: Chris Zankel <chris@zankel.net> Cc: Arnd Bergmann <arnd@arndb.de> Acked-by:
-
Vivek Goyal authored
The last line of vmcoreinfo note does not end with \n. Parsing all the lines in note becomes easier if all lines end with \n instead of trying to special case the last line. I know at least one tool, vmcore-dmesg in kexec-tools tree which made the assumption that all lines end with \n. I think it is a good idea to fix it. Signed-off-by:
Vivek Goyal <vgoyal@redhat.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp> Signed-off-by:
-
Akinobu Mita authored
The function dup_task() may fail at the following function calls in the following order. 0) alloc_task_struct_node() 1) alloc_thread_info_node() 2) arch_dup_task_struct() Error by 0) is not a matter, it can just return. But error by 1) requires releasing task_struct allocated by 0) before it returns. Likewise, error by 2) requires releasing task_struct and thread_info allocated by 0) and 1). The existing error handling calls free_task_struct() and free_thread_info() which do not only release task_struct and thread_info, but also call architecture specific arch_release_task_struct() and arch_release_thread_info(). The problem is that task_struct and thread_info are not fully initialized yet at this point, but arch_release_task_struct() and arch_release_thread_info() are called with them. For example, x86 defines its own arch_release_task_struct() that releases a task_xstate. If alloc_thread_info_node() fails in dup_task(), arch_release_task_struct() is called with task_struct which is just allocated and filled with garbage in this error handling. This actually happened with tools/testing/fault-injection/failcmd.sh # env FAILCMD_TYPE=fail_page_alloc \ ./tools/testing/fault-injection/failcmd.sh --times=100 \ --min-order=0 --ignore-gfp-wait=0 \ -- make -C tools/testing/selftests/ run_tests In order to fix this issue, make free_{task_struct,thread_info}() not to call arch_release_{task_struct,thread_info}() and call arch_release_{task_struct,thread_info}() implicitly where needed. Default arch_release_task_struct() and arch_release_thread_info() are defined as empty by default. So this change only affects the architectures which implement their own arch_release_task_struct() or arch_release_thread_info() as listed below. arch_release_task_struct(): x86, sh arch_release_thread_info(): mn10300, tile Signed-off-by:Akinobu Mita <akinobu.mita@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: David Howells <dhowells@redhat.com> Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com> Cc: Paul Mundt <lethal@linux-sh.org> Cc: Chris Metcalf <cmetcalf@tilera.com> Cc: Salman Qazi <sqazi@google.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Andrew Morton authored
To make way for "fork: fix error handling in dup_task()", which fixes the errors more completely. Cc: Salman Qazi <sqazi@google.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Ingo Molnar <mingo@elte.hu> Cc: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by:
-
Huang Shijie authored
The current code can be replaced by vma_pages(). So use it to simplify the code. [akpm@linux-foundation.org: initialise `len' at its definition site] Signed-off-by:
Huang Shijie <shijie8@gmail.com> Signed-off-by:
-
Djalal Harouni authored
__mem_open() which is called by both /proc/<pid>/environ and /proc/<pid>/mem ->open() handlers will allow the use of negative offsets. /proc/<pid>/mem has negative offsets but not /proc/<pid>/environ. Clean this by moving the 'force FMODE_UNSIGNED_OFFSET flag' to mem_open() to allow negative offsets only on /proc/<pid>/mem. Signed-off-by:
Djalal Harouni <tixxdz@opendz.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Brad Spengler <spender@grsecurity.net> Acked-by:
Kees Cook <keescook@chromium.org> Cc: David Rientjes <rientjes@google.com> Signed-off-by:
-
Djalal Harouni authored
Currently the following offset and environment address range check in environ_read() of /proc/<pid>/environ is buggy: int this_len = mm->env_end - (mm->env_start + src); if (this_len <= 0) break; Large or negative offsets on /proc/<pid>/environ converted to 'unsigned long' may pass this check since '(mm->env_start + src)' can overflow and 'this_len' will be positive. This can turn /proc/<pid>/environ to act like /proc/<pid>/mem since (mm->env_start + src) will point and read from another VMA. There are two fixes here plus some code cleaning: 1) Fix the overflow by checking if the offset that was converted to unsigned long will always point to the [mm->env_start, mm->env_end] address range. 2) Remove the truncation that was made to the result of the check, storing the result in 'int this_len' will alter its value and we can not depend on it. For kernels that have commit b409e578 ("proc: clean up /proc/<pid>/environ handling") which adds the appropriate ptrace check and saves the 'mm' at ->open() time, this is not a security issue. This patch is taken from the grsecurity patch since it was just made available. Signed-off-by: -
Jovi Zhang authored
In commit 898b374a ("exec: replace call_usermodehelper_pipe with use of umh init function and resolve limit"), the core limits recursive check value was changed from 0 to 1, but the corresponding comments were not updated. Signed-off-by:
Jovi Zhang <bookjovi@gmail.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
Tetsuo Handa authored
The system deadlocks (at least since 2.6.10) when call_usermodehelper(UMH_WAIT_EXEC) request triggers call_usermodehelper(UMH_WAIT_PROC) request. This is because "khelper thread is waiting for the worker thread at wait_for_completion() in do_fork() since the worker thread was created with CLONE_VFORK flag" and "the worker thread cannot call complete() because do_execve() is blocked at UMH_WAIT_PROC request" and "the khelper thread cannot start processing UMH_WAIT_PROC request because the khelper thread is waiting for the worker thread at wait_for_completion() in do_fork()". The easiest example to observe this deadlock is to use a corrupted /sbin/hotplug binary (like shown below). # : > /tmp/dummy # chmod 755 /tmp/dummy # echo /tmp/dummy > /proc/sys/kernel/hotplug # modprobe whatever call_usermodehelper("/tmp/dummy", UMH_WAIT_EXEC) is called from kobject_uevent_env() in lib/kobject_uevent.c upon loading/unloading a module. do_execve("/tmp/dummy") triggers a call to request_module("binfmt-0000") from search_binary_handler() which in turn calls call_usermodehelper(UMH_WAIT_PROC). In order to avoid deadlock, as a for-now and easy-to-backport solution, do not try to call wait_for_completion() in call_usermodehelper_exec() if the worker thread was created by khelper thread with CLONE_VFORK flag. Future and fundamental solution might be replacing singleton khelper thread with some workqueue so that recursive calls up to max_active dependency loop can be handled without deadlock. [akpm@linux-foundation.org: add comment to kmod_thread_locker] Signed-off-by:Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Arjan van de Ven <arjan@linux.intel.com> Acked-by:
Rusty Russell <rusty@rustcorp.com.au> Cc: Tejun Heo <tj@kernel.org> Cc: Oleg Nesterov <oleg@redhat.com> Signed-off-by:
-
Andrew Morton authored
This function's interface is, uh, subtle. Attempt to apologise for it. Cc: WANG Cong <xiyou.wangcong@gmail.com> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Kees Cook <keescook@chromium.org> Cc: Serge Hallyn <serge.hallyn@canonical.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Steven J. Magnani authored
Nearly identical shortname parsing is performed in fat_search_long() and __fat_readdir(). Extract this code into a function that may be called by both. Signed-off-by:
Steven J. Magnani <steve@digidescorp.com> Acked-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
-
Steven J. Magnani authored
Simplify code by providing accessor functions for the directory entry start cluster fields. Signed-off-by:
-
Namjae Jeon authored
Use -ENOMEM return value instead of -EINVAL when kzalloc() fails. Signed-off-by:
Namjae Jeon <linkinjeon@gmail.com> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Vyacheslav Dubeyko authored
Add omitted comments for different structures in driver implementation. Signed-off-by:
Vyacheslav Dubeyko <slava@dubeyko.com> Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Signed-off-by:
-
Vyacheslav Dubeyko authored
Add omitted comments for structures in nilfs2_fs.h. Signed-off-by:
-
Ryusuke Konishi authored
An fs-thaw ioctl causes deadlock with a chcp or mkcp -s command: chcp D ffff88013870f3d0 0 1325 1324 0x00000004 ... Call Trace: nilfs_transaction_begin+0x11c/0x1a0 [nilfs2] wake_up_bit+0x20/0x20 copy_from_user+0x18/0x30 [nilfs2] nilfs_ioctl_change_cpmode+0x7d/0xcf [nilfs2] nilfs_ioctl+0x252/0x61a [nilfs2] do_page_fault+0x311/0x34c get_unmapped_area+0x132/0x14e do_vfs_ioctl+0x44b/0x490 __set_task_blocked+0x5a/0x61 vm_mmap_pgoff+0x76/0x87 __set_current_blocked+0x30/0x4a sys_ioctl+0x4b/0x6f system_call_fastpath+0x16/0x1b thaw D ffff88013870d890 0 1352 1351 0x00000004 ... Call Trace: rwsem_down_failed_common+0xdb/0x10f call_rwsem_down_write_failed+0x13/0x20 down_write+0x25/0x27 thaw_super+0x13/0x9e do_vfs_ioctl+0x1f5/0x490 vm_mmap_pgoff+0x76/0x87 sys_ioctl+0x4b/0x6f filp_close+0x64/0x6c system_call_fastpath+0x16/0x1b where the thaw ioctl deadlocked at thaw_super() when called while chcp was waiting at nilfs_transaction_begin() called from nilfs_ioctl_change_cpmode(). This deadlock is 100% reproducible. This is because nilfs_ioctl_change_cpmode() first locks sb->s_umount in read mode and then waits for unfreezing in nilfs_transaction_begin(), whereas thaw_super() locks sb->s_umount in write mode. The locking of sb->s_umount here was intended to make snapshot mounts and the downgrade of snapshots to checkpoints exclusive. This fixes the deadlock issue by replacing the sb->s_umount usage in nilfs_ioctl_change_cpmode() with a dedicated mutex which protects snapshot mounts. Signed-off-by:
-
Ryusuke Konishi authored
The checkpoint deletion ioctl (rmcp ioctl) has potential for breaking snapshot because it is not fully exclusive with checkpoint mode change ioctl (chcp ioctl). The rmcp ioctl first tests if the specified checkpoint is a snapshot or not within nilfs_cpfile_delete_checkpoint function, and then calls nilfs_cpfile_delete_checkpoints function to actually invalidate the checkpoint only if it's not a snapshot. However, the checkpoint can be changed into a snapshot by the chcp ioctl between these two operations. In that case, calling nilfs_cpfile_delete_checkpoints() wrongly invalidates the snapshot, which leads to snapshot list corruption and snapshot count mismatch. This fixes the issue by changing nilfs_cpfile_delete_checkpoints() so that it reconfirms the target checkpoints are snapshot or not. This second check is exclusive with the chcp operation since it is protected by an existing semaphore. Signed-off-by:
-
Fernando Luis Vazquez Cao authored
->delete_inode(), ->write_super_lockfs(), ->unlockfs() are gone so remove references to them in the NTFS code. Noticed while cleaning up the fsfreeze mess. Signed-off-by:
Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp> Signed-off-by:
-
Vyacheslav Dubeyko authored
Add omitted comment for ns_mount_state field of the_nilfs structure. Signed-off-by:
-
Vladimir Serbinenko authored
On minix2 and minix3 usually max_size is 7fffffff and the check in question prohibits creation of last block spanning right before 7fffffff, due to downward rounding during the division. Fix it by using multiplication instead. [akpm@linux-foundation.org: fix up code layout, use local `sb'] Signed-off-by:
Vladimir Serbinenko <phcoder@gmail.com> Signed-off-by:
-
Nick Bowler authored
Set the of_match_table for this driver so that devices can be described in the device tree. Signed-off-by:
Nick Bowler <nbowler@elliptictech.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Nick Bowler authored
The owner member is supposed to be set to the module implementing the device driver, i.e., THIS_MODULE. This enables the appropriate module link in sysfs. Signed-off-by:
-
Devendra Naga authored
Freeing will trigger when driver unloads, so using devm_kfree() is not needed. Signed-off-by:
Devendra Naga <devendra.aaru@gmail.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Ashish Jangam <ashish.jangam@kpitcummins.com> Cc: David Dajun Chen <dchen@diasemi.com> Signed-off-by:
-
Uwe Kleine-König authored
Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Uwe Kleine-König authored
This allows automatic driver loading for all supported device types. Signed-off-by:
-
Sachin Kamat authored
Fixes the following checkpatch warnings: WARNING: Use #include <linux/uaccess.h> instead of <asm/uaccess.h> WARNING: Use #include <linux/io.h> instead of <asm/io.h> Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by:
-
Andrew Morton authored
When the driver detects that the clock time is invalid, it attempts to write a sane time into the hardware. We curently assume that everything is OK if those writes succeeded. But it is better to re-read the time from the hardware to ensure that the new settings got there OK. Cc: Devendra Naga <devendra.aaru@gmail.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Anatolij Gustschin <agust@denx.de> Cc: Andreas Dumberger <andreas.dumberger@tqs.de> Signed-off-by:
-
Devendra Naga authored
r9701_get_datetime() calls rtc_valid_tm() and returns the value returned by rtc_valid_tm(), which can be used in the `if', so calling rtc_valid_tm() a second time is not required. Signed-off-by:
-
Bengt Jonsson authored
AB8500 ED (Early Drop) is no longer supported by the kernel. Signed-off-by:
Bengt Jonsson <bengt.g.jonsson@stericsson.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Ramesh Chandrasekaran authored
RTC: Fix to correct improper implementation of clock update irq (RTC_UIE) and enable UIE Emulation. [akpm@linux-foundation.org: checkpatch fixes] Signed-off-by:
Ramesh Chandrasekaran <ramesh.chandrasekaran@stericsson.com> Signed-off-by:
-
Mattias Wallin authored
The pl031 interrupt is shared between the timer part and the clockwatch part of the same HW block on the ux500, so mark it IRQF_SHARED on this variant. This patch also adds the IRQF_NO_SUSPEND flag to the rtc irq on all variants as we don't want this pretty important IRQ to be disabled in suspend. Signed-off-by:
Mattias Wallin <mattias.wallin@stericsson.com> Signed-off-by:
Rickard Andersson <rickard.andersson@stericsson.com> Reviewed-by:
Jonas Aberg <jonas.aberg@stericsson.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Linus Walleij authored
Instead of hard-checking for certain vendor codes, follow the pattern of other AMBA (PrimeCell) drivers and use variables in the vendor data. Get rid of the locally cached vendor and hardware revision since we already have the nice vendor data variable in the state. Signed-off-by:
-
Linus Walleij authored
Move the per-vendor operations for this RTC into a encapsulating struct so we can have more per-vendor variables than just the ops. Signed-off-by:
-
Linus Walleij authored
Allocate memory, region, remap and irq for device state using devm_* helpers to simplify memory accounting. Signed-off-by:
-
Linus Walleij authored
Make sure we prepare/unprepare the clock for the COH901331 RTC driver as is required by the clk API especially if you use common clock. Signed-off-by:
-
Alan Cox authored
Fix a case where users can try to allocate arbitarily large amounts of memory. 64K is overkill for a config request so apply an upper bound. Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Kamil Dudka authored
drivers/message/i2o/i2o_proc.c: the pointer returned from chtostr() points to an array which is no longer valid ... when being used in the calling function. Although it may work, the behavior is undefined. Detected by cppcheck. Signed-off-by:
Kamil Dudka <kdudka@redhat.com> Signed-off-by:
-
Thiago Rafael Becker authored
Variables t4, t5, t6 and t7 are only used when CRC_LE_BITS != 32. Fix the following compilation warnings: lib/crc32.c: In function 'crc32_body': lib/crc32.c:77:55: warning: unused variable 't7' lib/crc32.c:77:41: warning: unused variable 't6' lib/crc32.c:77:27: warning: unused variable 't5' lib/crc32.c:77:13: warning: unused variable 't4' Signed-off-by:
Thiago Rafael Becker <trbecker@trbecker.org> Cc: "Darrick J. Wong" <djwong@us.ibm.com> Cc: Bob Pearson <rpearson@systemfabricworks.com> Signed-off-by:
-
