- 08 Aug, 2014 40 commits
-
-
Josh Hunt authored
This taint flag will be set if the system has ever entered a softlockup state. Similar to TAINT_WARN it is useful to know whether or not the system has been in a softlockup state when debugging. [akpm@linux-foundation.org: apply the taint before calling panic()] Signed-off-by:
Josh Hunt <johunt@akamai.com> Cc: Jason Baron <jbaron@akamai.com> Cc: Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Fabian Frederick authored
All bfs related functions use bfs_ prefix. This patch also moves extern declaration to bfs.h and removes prototype from inode.c This fixes checkpatch warning: WARNING: externs should be avoided in .c files Signed-off-by:
Fabian Frederick <fabf@skynet.be> Cc: "Tigran A. Aivazian" <tigran@aivazian.fsnet.co.uk> Signed-off-by:
-
Joe Perches authored
Might as well do the right thing. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Fabian Frederick authored
kcalloc manages count*sizeof overflow. Signed-off-by:
-
Fabian Frederick authored
Use kernel.h definition. Signed-off-by:
-
Fabian Frederick authored
This fixes checkpatch warning: WARNING: debugfs_remove(NULL) is safe this check is probably not required Signed-off-by:
-
Fabian Frederick authored
kcalloc manages count*sizeof overflow. Signed-off-by:
Boaz Harrosh <bharrosh@panasas.com> Signed-off-by:
-
Joe Perches authored
Remove the final user, and the typedef itself. Signed-off-by:
-
Wei Yang authored
In case 1, it passes down the BLACK color from G to p and u, and maintains the color of n. By doing so, it maintains the black height of the sub-tree. While in the comment, it marks the color of n to BLACK. This is a typo and not consistents with the code. This patch fixs this typo in comment. Signed-off-by:
Wei Yang <weiyang@linux.vnet.ibm.com> Acked-by:
Michel Lespinasse <walken@google.com> Cc: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> Signed-off-by:
-
Alexandre Bounine authored
Rework Tsi721 RapidIO DMA engine support to allow handling data scatter/gather lists longer than number of hardware buffer descriptors in the DMA channel's descriptor list. The current implementation of Tsi721 DMA transfers requires that number of entries in a scatter/gather list provided by a caller of dmaengine_prep_rio_sg() should not exceed number of allocated hardware buffer descriptors. This patch removes the limitation by processing long scatter/gather lists by sections that can be transferred using hardware descriptor ring of configured size. It also introduces a module parameter "dma_desc_per_channel" to allow run-time configuration of Tsi721 hardware buffer descriptor rings. Signed-off-by:
Alexandre Bounine <alexandre.bounine@idt.com> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Andre van Herk <andre.van.herk@prodrive-technologies.com> Cc: Stef van Os <stef.van.os@prodrive-technologies.com> Cc: Vinod Koul <vinod.koul@intel.com> Cc: Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Alexandre Bounine authored
Add RapidIO DMA interface routines that directly use reference to the mport device object and/or target device destination ID as parameters. This allows to perform RapidIO DMA transfer requests by modules that do not have an access to the RapidIO device list. Signed-off-by:
-
Andrey Ryabinin authored
I'm working on address sanitizer project for kernel. Recently we started experiments with stack instrumentation, to detect out-of-bounds read/write bugs on stack. Just after booting I've hit out-of-bounds read on stack in idr_for_each (and in __idr_remove_all as well): struct idr_layer **paa = &pa[0]; while (id >= 0 && id <= max) { ... while (n < fls(id)) { n += IDR_BITS; p = *--paa; <--- here we are reading pa[-1] value. } } Despite the fact that after this dereference we are exiting out of loop and never use p, such behaviour is undefined and should be avoided. Fix this by moving pointer derference to the beggining of the loop, right before we will use it. Signed-off-by:Andrey Ryabinin <a.ryabinin@samsung.com> Reviewed-by:
Lai Jiangshan <laijs@cn.fujitsu.com> Cc: Tejun Heo <tj@kernel.org> Cc: Alexey Preobrazhensky <preobr@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Konstantin Khlebnikov <koct9i@gmail.com> Signed-off-by:
-
Vitaly Kuznetsov authored
We have a special check in read_vmcore() handler to check if the page was reported as ram or not by the hypervisor (pfn_is_ram()). However, when vmcore is read with mmap() no such check is performed. That can lead to unpredictable results, e.g. when running Xen PVHVM guest memcpy() after mmap() on /proc/vmcore will hang processing HVMMEM_mmio_dm pages creating enormous load in both DomU and Dom0. Fix the issue by mapping each non-ram page to the zero page. Keep direct path with remap_oldmem_pfn_range() to avoid looping through all pages on bare metal. The issue can also be solved by overriding remap_oldmem_pfn_range() in xen-specific code, as remap_oldmem_pfn_range() was been designed for. That, however, would involve non-obvious xen code path for all x86 builds with CONFIG_XEN_PVHVM=y and would prevent all other hypervisor-specific code on x86 arch from doing the same override. [fengguang.wu@intel.com: remap_oldmem_pfn_checked() can be static] [akpm@linux-foundation.org: clean up layout] Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by:
Andrew Jones <drjones@redhat.com> Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com> Acked-by:
Vivek Goyal <vgoyal@redhat.com> Cc: David Vrabel <david.vrabel@citrix.com> Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
Vladimir Davydov authored
It's only used in fork.c:mm_init(). Signed-off-by:
Vladimir Davydov <vdavydov@parallels.com> Signed-off-by:
-
Vladimir Davydov authored
If a forking process has a thread calling (un)mmap (silly but still), the child process may have some of its mm's vm usage counters (total_vm and friends) screwed up, because currently they are copied from oldmm w/o holding any locks (memcpy in dup_mm). This patch moves the counters initialization to dup_mmap() to be called under oldmm->mmap_sem, which eliminates any possibility of race. Signed-off-by:
-
Vladimir Davydov authored
mm->pinned_vm counts pages of mm's address space that were permanently pinned in memory by increasing their reference counter. The counter was introduced by commit bc3e53f6 ("mm: distinguish between mlocked and pinned pages"), while before it locked_vm had been used for such pages. Obviously, we should reset the counter on fork if !CLONE_VM, just like we do with locked_vm, but currently we don't. Let's fix it. This patch will fix the contents of /proc/pid/status:VmPin. ib_umem_get[infiniband] and perf_mmap still check pinned_vm against RLIMIT_MEMLOCK. It's left from the times when pinned pages were accounted under locked_vm, but today it looks wrong. It isn't clear how we should deal with it. We still have some drivers accounting pinned pages under mm->locked_vm - this is what commit bc3e53f6 was fighting against. It's infiniband/usnic and vfio. Signed-off-by:
-
Vladimir Davydov authored
mm initialization on fork/exec is spread all over the place, which makes the code look inconsistent. We have mm_init(), which is supposed to init/nullify mm's internals, but it doesn't init all the fields it should: - on fork ->mmap,mm_rb,vmacache_seqnum,map_count,mm_cpumask,locked_vm are zeroed in dup_mmap(); - on fork ->pmd_huge_pte is zeroed in dup_mm(), immediately before calling mm_init(); - ->cpu_vm_mask_var ptr is initialized by mm_init_cpumask(), which is called before mm_init() on both fork and exec; - ->context is initialized by init_new_context(), which is called after mm_init() on both fork and exec; Let's consolidate all the initializations in mm_init() to make the code look cleaner. Signed-off-by:
-
Alexey Dobriyan authored
If you're applying this patch, all /proc/$PID/* files were converted to seq_file interface and this code became unused. Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Alexey Dobriyan authored
Signed-off-by:
-
Alexey Dobriyan authored
Signed-off-by:
-
Alexey Dobriyan authored
Signed-off-by:
-
Alexey Dobriyan authored
Signed-off-by:
-
Alexey Dobriyan authored
Signed-off-by:
-
Alexey Dobriyan authored
Signed-off-by:
-
Alexey Dobriyan authored
Signed-off-by:
-
Alexey Dobriyan authored
Signed-off-by:
-
Alexey Dobriyan authored
Signed-off-by:
-
Alexey Dobriyan authored
Signed-off-by:
-
Alexey Dobriyan authored
/proc/tty/ldisc appear to be unused as a directory and it had been always that way. But it is userspace visible thing. Cowardly remove only in-kernel variable holding it. [akpm@linux-foundation.org: add comment] Signed-off-by:
-
Alexey Dobriyan authored
Signed-off-by:
-
Alexey Dobriyan authored
Currently lookup for /proc/$PID first goes through spinlock and whole list of misc /proc entries only to confirm that, yes, /proc/42 can not possibly match random proc entry. List is is several dozens entries long (52 entries on my setup). None of this is necessary. Try to convert dentry name to integer first. If it works, it must be /proc/$PID. If it doesn't, it must be random proc entry. Based on patch from Al Viro. Signed-off-by:
-
Alexey Dobriyan authored
* remove proc_create(NULL, ...) check, let it oops * warn about proc_create("", ...) and proc_create("very very long name", ...) proc code keeps length as u8, no 256+ name length possible * warn about proc_create("123", ...) /proc/$PID and /proc/misc namespaces are separate things, but dumb module might create funky a-la $PID entry. * remove post mortem strchr('/') check Triggering it implies either strchr() is buggy or memory corruption. It should be VFS check anyway. In reality, none of these checks will ever trigger, it is preparation for the next patch. Based on patch from Al Viro. Signed-off-by: -
Fabian Frederick authored
proc_uid_seq_operations, proc_gid_seq_operations and proc_projid_seq_operations are only called in proc_id_map_open with seq_open as const struct seq_operations so we can constify the 3 structures and update proc_id_map_open prototype. text data bss dec hex filename 6817 404 1984 9205 23f5 kernel/user_namespace.o-before 6913 308 1984 9205 23f5 kernel/user_namespace.o-after Signed-off-by:
-
Fabian Frederick authored
Use mm.h definition. Signed-off-by:
David Rientjes <rientjes@google.com> Signed-off-by:
-
Ionut Alexa authored
Fixed coding style warnings and errors. Signed-off-by:
Ionut Alexa <ionut.m.alexa@gmail.com> Signed-off-by:
-
Fabian Frederick authored
Fix 2 checkpatch warnings: WARNING: suspect code indent for conditional statements Signed-off-by:
-
Fabian Frederick authored
Fix checkpatch warning: WARNING: Missing a blank line after declarations Signed-off-by:
-
Fabian Frederick authored
Fix checkpatch warning WARNING: Use #include <linux/uaccess.h> instead of <asm/uaccess.h> Signed-off-by:
-
Fabian Frederick authored
Fixes checkpatch warnings: "WARNING: %Ld/%Lu are not-standard C, use %lld/%llu" Signed-off-by:
-
Fabian Frederick authored
Signed-off-by:
-
