- 06 Jun, 2014 40 commits
-
-
Manfred Spraul authored
Right now, perform_atomic_semop gets the content of sem_queue as individual fields. Changes that, instead pass a pointer to sem_queue. This is a preparation for the next patch: it uses sem_queue to store the reason why a task must sleep. Signed-off-by:
Manfred Spraul <manfred@colorfullife.com> Cc: Davidlohr Bueso <davidlohr.bueso@hp.com> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Manfred Spraul authored
count_semzcnt and count_semncnt are more of less identical. The patch creates a single function that either counts the number of tasks waiting for zero or waiting due to a decrease operation. Compared to the initial version, the BUG_ONs were removed. Signed-off-by:
-
Manfred Spraul authored
GETZCNT is supposed to return the number of threads that wait until a semaphore value becomes 0. The current implementation overlooks complex operations that contain both wait-for-zero operation and operations that alter at least one semaphore. The patch fixes that. It's intentionally copy&paste, this will be cleaned up in the next patch. Signed-off-by:
-
Davidlohr Bueso authored
The need for volatile is not obvious, document it. Signed-off-by:
Davidlohr Bueso <davidlohr@hp.com> Signed-off-by:
-
Davidlohr Bueso authored
Nothing big and no logical changes, just get rid of some redundant function declarations. Move msg_[init/exit]_ns down the end of the file. Signed-off-by:
-
Davidlohr Bueso authored
Call __set_current_state() instead of assigning the new state directly. Signed-off-by:
Manfred Spraul <manfred@colorfullif.com> Cc: Aswin Chandramouleeswaran <aswin@hp.com> Signed-off-by:
-
Davidlohr Bueso authored
This is useful in the future and allows users to better understand the reasoning behind the changes. Also use UL as we're dealing with it anyways. Signed-off-by:
-
Manfred Spraul authored
System V shared memory a) can be abused to trigger out-of-memory conditions and the standard measures against out-of-memory do not work: - it is not possible to use setrlimit to limit the size of shm segments. - segments can exist without association with any processes, thus the oom-killer is unable to free that memory. b) is typically used for shared information - today often multiple GB. (e.g. database shared buffers) The current default is a maximum segment size of 32 MB and a maximum total size of 8 GB. This is often too much for a) and not enough for b), which means that lots of users must change the defaults. This patch increases the default limits (nearly) to the maximum, which is perfect for case b). The defaults are used after boot and as the initial value for each new namespace. Admins/distros that need a protection against a) should reduce the limits and/or enable shm_rmid_forced. Unix has historically required setting these limits for shared memory, and Linux inherited such behavior. The consequence of this is added complexity for users and administrators. One very common example are Database setup/installation documents and scripts, where users must manually calculate the values for these limits. This also requires (some) knowledge of how the underlying memory management works, thus causing, in many occasions, the limits to just be flat out wrong. Disabling these limits sooner could have saved companies a lot of time, headaches and money for support. But it's never too late, simplify users life now. Further notes: - The patch only changes default, overrides behave as before: # sysctl kernel.shmall=33554432 would recreate the previous limit for SHMMAX (for the current namespace). - Disabling sysv shm allocation is possible with: # sysctl kernel.shmall=0 (not a new feature, also per-namespace) - The limits are intentionally set to a value slightly less than ULONG_MAX, to avoid triggering overflows in user space apps. [not unreasonable, see http://marc.info/?l=linux-mm&m=139638334330127] Signed-off-by:Michael Kerrisk <mtk.manpages@gmail.com> Acked-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Signed-off-by:
-
Manfred Spraul authored
SHMMAX is the upper limit for the size of a shared memory segment, counted in bytes. The actual allocation is that size, rounded up to the next full page. Add a check that prevents the creation of segments where the rounded up size causes an integer overflow. Signed-off-by:
-
Manfred Spraul authored
shm_tot counts the total number of pages used by shm segments. If SHMALL is ULONG_MAX (or nearly ULONG_MAX), then the number can overflow. Subsequent calls to shmctl(,SHM_INFO,) would return wrong values for shm_tot. The patch adds a detection for overflows. Signed-off-by:
-
Manfred Spraul authored
The increase of SHMMAX/SHMALL is a 4 patch series. The change itself is trivial, the only problem are interger overflows. The overflows are not new, but if we make huge values the default, then the code should be free from overflows. SHMMAX: - shmmem_file_setup places a hard limit on the segment size: MAX_LFS_FILESIZE. On 32-bit, the limit is > 1 TB, i.e. 4 GB-1 byte segments are possible. Rounded up to full pages the actual allocated size is 0. --> must be fixed, patch 3 - shmat: - find_vma_intersection does not handle overflows properly. --> must be fixed, patch 1 - the rest is fine, do_mmap_pgoff limits mappings to TASK_SIZE and checks for overflows (i.e.: map 2 GB, starting from addr=2.5GB fails). SHMALL: - after creating 8192 segments size (1L<<63)-1, shm_tot overflows and returns 0. --> must be fixed, patch 2. Userspace: - Obviously, there could be overflows in userspace. There is nothing we can do, only use values smaller than ULONG_MAX. I ended with "ULONG_MAX - 1L<<24": - TASK_SIZE cannot be used because it is the size of the current task. Could be 4G if it's a 32-bit task on a 64-bit kernel. - The maximum size is not standardized across archs: I found TASK_MAX_SIZE, TASK_SIZE_MAX and TASK_SIZE_64. - Just in case some arch revives a 4G/4G split, nearly ULONG_MAX is a valid segment size. - Using "0" as a magic value for infinity is even worse, because right now 0 means 0, i.e. fail all allocations. This patch (of 4): find_vma_intersection() does not work as intended if addr+size overflows. The patch adds a manual check before the call to find_vma_intersection. Signed-off-by: -
Paul McQuade authored
trailing whitespace Signed-off-by:
Paul McQuade <paulmcquad@gmail.com> Signed-off-by:
-
Paul McQuade authored
Use #include <linux/uaccess.h> instead of <asm/uaccess.h> Use #include <linux/types.h> instead of <asm/types.h> Signed-off-by:
-
Mathias Krause authored
There is no need to recreate the very same ipc_ops structure on every kernel entry for msgget/semget/shmget. Just declare it static and be done with it. While at it, constify it as we don't modify the structure at runtime. Found in the PaX patch, written by the PaX Team. Signed-off-by:
Mathias Krause <minipli@googlemail.com> Cc: PaX Team <pageexec@freemail.hu> Cc: Davidlohr Bueso <davidlohr@hp.com> Cc: Manfred Spraul <manfred@colorfullife.com> Signed-off-by:
-
Paul Bolle authored
Commit 9ba4bcb6 ("initramfs: read CONFIG_RD_ variables for initramfs compression") removed the users of the various INITRAMFS_COMPRESSION_* Kconfig symbols. So since v3.13 the entire "Built-in initramfs compression mode" choice is a set of knobs connected to nothing. The entire choice can safely be removed. Signed-off-by:
Paul Bolle <pebolle@tiscali.nl> Cc: P J P <ppandit@redhat.com> Signed-off-by:
-
Fabian Frederick authored
Also convert spaces to tabs (checkpatch warnings) if (!dentry) KERN_NOTICE converted to pr_err (like if (!inode) error process) [akpm@linux-foundation.org: use KBUILD_MODNAME, per Joe] Signed-off-by:
Fabian Frederick <fabf@skynet.be> Cc: Joe Perches <joe@perches.com> Cc: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Fabian Frederick authored
Also add pr_fmt in internal.h Signed-off-by:
-
Fabian Frederick authored
Signed-off-by:
-
Fabian Frederick authored
- Define pr_fmt in plateform.c and ram_core.c for global prefix. - Coalesce format fragments. - Separate format/arguments on lines > 80 characters. Note: Some pr_foo() were initially declared without prefix and therefore this could break existing log analyzer. [akpm@linux-foundation.org: missed a couple of prefix removals] Signed-off-by:
-
Fabian Frederick authored
schedstr, sleepstr and kvmstr are only used in strcmp & strlen Signed-off-by:
-
Fabian Frederick authored
Signed-off-by:
-
Fabian Frederick authored
- Remove AFFS: prefix (defined in pr_fmt) - Use __func__ - Separate format/arguments on lines > 80 characters. Signed-off-by:
-
Fabian Frederick authored
-All printk(KERN_foo converted to pr_foo() -Default printk converted to pr_warn() -Add pr_fmt to affs.h Signed-off-by:
-
Fabian Frederick authored
- affs_do_readpage_ofs is always called with from = 0 ie reading from page->index - File parameter is never used Signed-off-by:
-
Hans Verkuil authored
When running sparse over drivers/media/v4l2-core/v4l2-ioctl.c I get these errors: drivers/media/v4l2-core/v4l2-ioctl.c:2043:9: error: bad integer constant expression drivers/media/v4l2-core/v4l2-ioctl.c:2044:9: error: bad integer constant expression drivers/media/v4l2-core/v4l2-ioctl.c:2045:9: error: bad integer constant expression drivers/media/v4l2-core/v4l2-ioctl.c:2046:9: error: bad integer constant expression etc. The root cause of that turns out to be in include/asm-generic/ioctl.h: #include <uapi/asm-generic/ioctl.h> /* provoke compile error for invalid uses of size argument */ extern unsigned int __invalid_size_argument_for_IOC; #define _IOC_TYPECHECK(t) \ ((sizeof(t) == sizeof(t[1]) && \ sizeof(t) < (1 << _IOC_SIZEBITS)) ? \ sizeof(t) : __invalid_size_argument_for_IOC) If it is defined as this (as is already done if __KERNEL__ is not defined): #define _IOC_TYPECHECK(t) (sizeof(t)) then all is well with the world. This patch allows sparse to work correctly. Signed-off-by:Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by:
Josh Triplett <josh@joshtriplett.org> Signed-off-by:
-
Fabian Frederick authored
-uid->gid -split some function declarations -if/then/else warning Signed-off-by:
-
Kees Cook authored
This adds several behavioral tests to sysctl string and number writing to detect unexpected cases that behaved differently when the sysctl kernel.sysctl_writes_strict != 1. [ original ] root@localhost:~# make test_num == Testing sysctl behavior against /proc/sys/kernel/domainname == Writing test file ... ok Checking sysctl is not set to test value ... ok Writing sysctl from shell ... ok Resetting sysctl to original value ... ok Writing entire sysctl in single write ... ok Writing middle of sysctl after synchronized seek ... FAIL Writing beyond end of sysctl ... FAIL Writing sysctl with multiple long writes ... FAIL Writing entire sysctl in short writes ... FAIL Writing middle of sysctl after unsynchronized seek ... ok Checking sysctl maxlen is at least 65 ... ok Checking sysctl keeps original string on overflow append ... FAIL Checking sysctl stays NULL terminated on write ... ok Checking sysctl stays NULL terminated on overwrite ... ok make: *** [test_num] Error 1 root@localhost:~# make test_string == Testing sysctl behavior against /proc/sys/vm/swappiness == Writing test file ... ok Checking sysctl is not set to test value ... ok Writing sysctl from shell ... ok Resetting sysctl to original value ... ok Writing entire sysctl in single write ... ok Writing middle of sysctl after synchronized seek ... FAIL Writing beyond end of sysctl ... FAIL Writing sysctl with multiple long writes ... ok make: *** [test_string] Error 1 [ with CONFIG_PROC_SYSCTL_STRICT_WRITES ] root@localhost:~# make run_tests == Testing sysctl behavior against /proc/sys/kernel/domainname == Writing test file ... ok Checking sysctl is not set to test value ... ok Writing sysctl from shell ... ok Resetting sysctl to original value ... ok Writing entire sysctl in single write ... ok Writing middle of sysctl after synchronized seek ... ok Writing beyond end of sysctl ... ok Writing sysctl with multiple long writes ... ok Writing entire sysctl in short writes ... ok Writing middle of sysctl after unsynchronized seek ... ok Checking sysctl maxlen is at least 65 ... ok Checking sysctl keeps original string on overflow append ... ok Checking sysctl stays NULL terminated on write ... ok Checking sysctl stays NULL terminated on overwrite ... ok == Testing sysctl behavior against /proc/sys/vm/swappiness == Writing test file ... ok Checking sysctl is not set to test value ... ok Writing sysctl from shell ... ok Resetting sysctl to original value ... ok Writing entire sysctl in single write ... ok Writing middle of sysctl after synchronized seek ... ok Writing beyond end of sysctl ... ok Writing sysctl with multiple long writes ... ok Signed-off-by:Kees Cook <keescook@chromium.org> Cc: Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Kees Cook authored
When writing to a sysctl string, each write, regardless of VFS position, begins writing the string from the start. This means the contents of the last write to the sysctl controls the string contents instead of the first: open("/proc/sys/kernel/modprobe", O_WRONLY) = 1 write(1, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 4096) = 4096 write(1, "/bin/true", 9) = 9 close(1) = 0 $ cat /proc/sys/kernel/modprobe /bin/true Expected behaviour would be to have the sysctl be "AAAA..." capped at maxlen (in this case KMOD_PATH_LEN: 256), instead of truncating to the contents of the second write. Similarly, multiple short writes would not append to the sysctl. The old behavior is unlike regular POSIX files enough that doing audits of software that interact with sysctls can end up in unexpected or dangerous situations. For example, "as long as the input starts with a trusted path" turns out to be an insufficient filter, as what must also happen is for the input to be entirely contained in a single write syscall -- not a common consideration, especially for high level tools. This provides kernel.sysctl_writes_strict as a way to make this behavior act in a less surprising manner for strings, and disallows non-zero file position when writing numeric sysctls (similar to what is already done when reading from non-zero file positions). For now, the default (0) is to warn about non-zero file position use, but retain the legacy behavior. Setting this to -1 disables the warning, and setting this to 1 enables the file position respecting behavior. [akpm@linux-foundation.org: fix build] [akpm@linux-foundation.org: move misplaced hunk, per Randy] Signed-off-by: -
Kees Cook authored
Consolidate buffer length checking with new-line/end-of-line checking. Additionally, instead of reading user memory twice, just do the assignment during the loop. This change doesn't affect the potential races here. It was already possible to read a sysctl that was in the middle of a write. In both cases, the string will always be NULL terminated. The pre-existing race remains a problem to be solved. Signed-off-by:
-
Kees Cook authored
When writing to a sysctl string, each write, regardless of VFS position, began writing the string from the start. This meant the contents of the last write to the sysctl controlled the string contents instead of the first. This misbehavior was featured in an exploit against Chrome OS. While it's not in itself a vulnerability, it's a weirdness that isn't on the mind of most auditors: "This filter looks correct, the first line written would not be meaningful to sysctl" doesn't apply here, since the size of the write and the contents of the final write are what matter when writing to sysctls. This adds the sysctl kernel.sysctl_writes_strict to control the write behavior. The default (0) reports when VFS position is non-0 on a write, but retains legacy behavior, -1 disables the warning, and 1 enables the position-respecting behavior. The long-term plan here is to wait for userspace to be fixed in response to the new warning and to then switch the default kernel behavior to the new position-respecting behavior. This patch (of 4): The char buffer arguments are needlessly cast in weird places. Clean it up so things are easier to read. Signed-off-by:
-
Alexander Gordeev authored
As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() or pci_enable_msi_exact() and pci_enable_msix_range() or pci_enable_msix_exact() interfaces. The patch has no runtime effect. Signed-off-by:
Alexander Gordeev <agordeev@redhat.com> Cc: Matt Porter <mporter@kernel.crashing.org> Acked-by:
Alexandre Bounine <alexandre.bounine@idt.com> Signed-off-by:
-
Lai Jiangshan authored
idr_layer->layer is always accessed in read path, move it in the front. idr_layer->bitmap is moved on the bottom. And rcu_head shares with bitmap due to they do not be accessed at the same time. idr->id_free/id_free_cnt/lock are free list fields, and moved to the bottom. They will be removed in near future. Signed-off-by:
Lai Jiangshan <laijs@cn.fujitsu.com> Cc: Tejun Heo <tj@kernel.org> Signed-off-by:
-
Lai Jiangshan authored
If "idr->hint == p" is true, it also implies "idr->hint" is true(not NULL). Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Lai Jiangshan authored
After idr subsystem is changed to RCU-awared, the free layer will not go to the free list. The free list will not be filled up when idr_remove(). So we don't need to shink it too. Signed-off-by:
-
Lai Jiangshan authored
When the smaller id is not found, idr_replace() returns -ENOENT. But when the id is bigger enough, idr_replace() returns -EINVAL, actually there is no difference between these two kinds of ids. These are all unallocated id, the return values of the idr_replace() for these ids should be the same: -ENOENT. Signed-off-by:
-
Lai Jiangshan authored
If the ida has at least one existing id, and when an unallocated ID which meets a certain condition is passed to the ida_remove(), the system will crash because it hits NULL pointer dereference. The condition is that the unallocated ID shares the same lowest idr layer with the existing ID, but the idr slot would be different if the unallocated ID were to be allocated. In this case the matching idr slot for the unallocated_id is NULL, causing @bitmap to be NULL which the function dereferences without checking crashing the kernel. See the test code: static void test3(void) { int id; DEFINE_IDA(test_ida); printk(KERN_INFO "Start test3\n"); if (ida_pre_get(&test_ida, GFP_KERNEL) < 0) return; if (ida_get_new(&test_ida, &id) < 0) return; ida_remove(&test_ida, 4000); /* bug: null deference here */ printk(KERN_INFO "End of test3\n"); } It happens only when the caller tries to free an unallocated ID which is the caller's fault. It is not a bug. But it is better to add the proper check and complain rather than crashing the kernel. [tj@kernel.org: updated patch description] Signed-off-by: -
Lai Jiangshan authored
If unallocated_id = (ANY * idr_max(idp->layers) + existing_id) is passed to idr_remove(). The existing_id will be removed unexpectedly. The following test shows this unexpected id-removal: static void test4(void) { int id; DEFINE_IDR(test_idr); printk(KERN_INFO "Start test4\n"); id = idr_alloc(&test_idr, (void *)1, 42, 43, GFP_KERNEL); BUG_ON(id != 42); idr_remove(&test_idr, 42 + IDR_SIZE); TEST_BUG_ON(idr_find(&test_idr, 42) != (void *)1); idr_destroy(&test_idr); printk(KERN_INFO "End of test4\n"); } ida_remove() shares the similar problem. It happens only when the caller tries to free an unallocated ID which is the caller's fault. It is not a bug. But it is better to add the proper check and complain rather than removing an existing_id silently. Signed-off-by: -
Lai Jiangshan authored
idr_replace() open-codes the logic to calculate the maximum valid ID given the height of the idr tree; unfortunately, the open-coded logic doesn't account for the fact that the top layer may have unused slots and over-shifts the limit to zero when the tree is at its maximum height. The following test code shows it fails to replace the value for id=((1<<27)+42): static void test5(void) { int id; DEFINE_IDR(test_idr); #define TEST5_START ((1<<27)+42) /* use the highest layer */ printk(KERN_INFO "Start test5\n"); id = idr_alloc(&test_idr, (void *)1, TEST5_START, 0, GFP_KERNEL); BUG_ON(id != TEST5_START); TEST_BUG_ON(idr_replace(&test_idr, (void *)2, TEST5_START) != (void *)1); idr_destroy(&test_idr); printk(KERN_INFO "End of test5\n"); } Fix the bug by using idr_max() which correctly takes into account the maximum allowed shift. sub_alloc() shares the same problem and may incorrectly fail with -EAGAIN; however, this bug doesn't affect correct operation because idr_get_empty_slot(), which already uses idr_max(), retries with the increased @id in such cases. [tj@kernel.org: Updated patch description.] Signed-off-by: -
Fabian Frederick authored
+ some pr_warning -> pr_warn and checkpatch warning fixes Signed-off-by:
-
Masami Hiramatsu authored
Add a "crash_kexec_post_notifiers" boot option to run kdump after running panic_notifiers and dump kmsg. This can help rare situations where kdump fails because of unstable crashed kernel or hardware failure (memory corruption on critical data/code), or the 2nd kernel is already broken by the 1st kernel (it's a broken behavior, but who can guarantee that the "crashed" kernel works correctly?). Usage: add "crash_kexec_post_notifiers" to kernel boot option. Note that this actually increases risks of the failure of kdump. This option should be set only if you worry about the rare case of kdump failure rather than increasing the chance of success. Signed-off-by:
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Acked-by:
Motohiro Kosaki <Motohiro.Kosaki@us.fujitsu.com> Acked-by:
Vivek Goyal <vgoyal@redhat.com> Cc: Eric Biederman <ebiederm@xmission.com> Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com> Cc: Satoru MORIYA <satoru.moriya.br@hitachi.com> Cc: Tomoki Sekiyama <tomoki.sekiyama@hds.com> Signed-off-by:
-
