- 01 Jul, 2015 40 commits
-
-
Joe Perches authored
Commit 2106241a ("ASoC: Intel: create common folder and move common files in") moved the files around. Update the patterns. Signed-off-by:
Joe Perches <joe@perches.com> Cc: Jie Yang <yang.jie@intel.com> Acked-by:
Jie Yang <yang.jie@intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Sudip Mukherjee authored
The webpage mentioned is not working, Signed-off-by:
Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by:
-
Laurent Navet authored
@emulex.com addresses respond to use @avagotech.com. Signed-off-by:
Laurent Navet <laurent.navet@gmail.com> Acked-By:
Devesh Sharma <devesh.sharma@avagotech.com> Signed-off-by:
-
Pekka Enberg authored
Use kvfree() instead of open-coding it. Signed-off-by:
Pekka Enberg <penberg@kernel.org> Cc: Kent Overstreet <kmo@daterainc.com> Signed-off-by:
-
Pekka Enberg authored
Use kvfree() instead of open-coding it. Signed-off-by:
-
Pekka Enberg authored
Use kvfree() instead of open-coding it. Signed-off-by:
-
Pekka Enberg authored
Use kvfree() instead of open-coding it. Signed-off-by:
-
Pekka Enberg authored
Use kvfree() instead of open-coding it. Signed-off-by:
-
Pekka Enberg authored
Use kvfree() instead of open-coding it. Signed-off-by:
-
Pekka Enberg authored
Use kvfree() instead of open-coding it. Signed-off-by:
-
Pekka Enberg authored
Use kvfree() instead of open-coding it. Signed-off-by:
-
Pekka Enberg authored
Use kvfree() instead of open-coding it. Signed-off-by:
-
Antonio Ospite authored
The comment about /dev/kmsg does not mention the additional values which may actually be exported, fix that. Also move up the part of the comment instructing the users to ignore these additional values, this way the reading is more fluent and logically compact. Signed-off-by:
Antonio Ospite <ao2@ao2.it> Cc: Joe Perches <joe@perches.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Tejun Heo <tj@kernel.org> Signed-off-by:
-
Masanari Iida authored
Signed-off-by:
Masanari Iida <standby24x7@gmail.com> Cc: Guan Xuetao <gxt@mprc.pku.edu.cn> Signed-off-by:
-
Dave Gordon authored
do_device_access() takes a separate parameter to indicate the direction of data transfer, which it used to use to select the appropriate function out of sg_pcopy_{to,from}_buffer(). However these two functions now have So this patch makes it bypass these wrappers and call the underlying function sg_copy_buffer() directly; this has the same calling style as do_device_access() i.e. a separate direction-of-transfer parameter and no pointers-to-const, so skipping the wrappers not only eliminates the warning, it also make the code simpler :) [akpm@linux-foundation.org: fix very broken build] Signed-off-by:Dave Gordon <david.s.gordon@intel.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
-
Dave Gordon authored
The 'buf' parameter of sg(p)copy_from_buffer() can and should be const-qualified, although because of the shared implementation of _to_buffer() and _from_buffer(), we have to cast this away internally. This means that callers who have a 'const' buffer containing the data to be copied to the sg-list no longer have to cast away the const-ness themselves. It also enables improved coverage by code analysis tools. Signed-off-by:
-
Dave Gordon authored
The kerneldoc for the functions doesn't match the code; the last two parameters (buflen, skip) have been transposed, which is confusing, especially as they're both integral types and the compiler won't warn about swapping them. These functions and the kerneldoc were introduced in commit: df642cea lib/scatterlist: introduce sg_pcopy_from_buffer() ... Author: Akinobu Mita <akinobu.mita@gmail.com> Date: Mon Jul 8 16:01:54 2013 -0700 The only difference between sg_pcopy_{from,to}_buffer() and sg_copy_{from,to}_buffer() is an additional argument that specifies the number of bytes to skip the SG list before copying. The functions have the extra argument at the end, but the kerneldoc lists it in penultimate position. Signed-off-by:Akinobu Mita <akinobu.mita@gmail.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Signed-off-by:
-
Davidlohr Bueso authored
In ipc_obtain_object_check we return -EIDRM when a bogus sequence number is detected via ipc_checkid, while the ipc manpages state the following return codes for such errors: EIDRM <ID> points to a removed identifier. EINVAL Invalid <ID> value, or unaligned, etc. EIDRM should only be returned upon a RMID call (->deleted check), and thus return EINVAL for wrong seq. This difference in semantics has also caused real bugs, ie: https://bugzilla.redhat.com/show_bug.cgi?id=246509Signed-off-by:
Davidlohr Bueso <dbueso@suse.de> Cc: Manfred Spraul <manfred@colorfullife.com> Signed-off-by:
-
Davidlohr Bueso authored
The ipc_lock helper is used by all forms of sysv ipc to acquire the ipc object's spinlock. Upon error (bogus identifier), we always return -EINVAL, whether the problem be in the idr path or because we raced with a task performing RMID. For the later, however, all ipc related manpages, state the that for: EIDRM <ID> points to a removed identifier. And return: EINVAL Invalid <ID> value, or unaligned, etc. Which (EINVAL) should only return once the ipc resource is deleted. For all types of ipc this is done immediately upon a RMID command. However, shared memory behaves slightly different as it can merely mark a segment for deletion, and delay the actual freeing until there are no more active consumers. Per shmctl(IPC_RMID) manpage: "" Mark the segment to be destroyed. The segment will only actually be destroyed after the last process detaches it (i.e., when the shm_nattch member of the associated structure shmid_ds is zero). "" Unlike ipc_lock, paths that behave "correctly", at least per the manpage, involve controlling the ipc resource via *ctl(), doing the exact same validity check as ipc_lock after right acquiring the spinlock: if (!ipc_valid_object()) { err = -EIDRM; goto out_unlock; } Thus make ipc_lock consistent with the rest of ipc code and return -EIDRM in ipc_lock when !ipc_valid_object(). Signed-off-by: -
Davidlohr Bueso authored
... to ipc_obtain_object_idr, which is more meaningful and makes the code slightly easier to follow. Signed-off-by:
-
Davidlohr Bueso authored
We currently use a full barrier on the sender side to to avoid receiver tasks disappearing on us while still performing on the sender side wakeup. We lack however, the proper CPU-CPU interactions pairing on the receiver side which busy-waits for the message. Similarly, we do not need a full smp_mb, and can relax the semantics for the writer and reader sides of the message. This is safe as we are only ordering loads and stores to r_msg. And in both smp_wmb and smp_rmb, there are no stores after the calls _anyway_. This obviously applies for pipelined_send and expunge_all, for EIRDM when destroying a queue. Signed-off-by:
-
Davidlohr Bueso authored
Upon every shm_lock call, we BUG_ON if an error was returned, indicating racing either in idr or in shm_destroy. Move this logic into the locking. [akpm@linux-foundation.org: simplify code] Signed-off-by:
-
Pekka Enberg authored
Use kvfree() instead of open-coding it. Signed-off-by:
-
Akinobu Mita authored
This replaces the plain loop over the sglist array with for_each_sg() macro which consists of sg_next() function calls. Since arc doesn't select ARCH_HAS_SG_CHAIN, it is not necessary to use for_each_sg() in order to loop over each sg element. But this can help find problems with drivers that do not properly initialize their sg tables when CONFIG_DEBUG_SG is enabled. Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Josh Triplett authored
If devpts failed to initialize, it would store an ERR_PTR in the global devpts_mnt. A subsequent open of /dev/ptmx would call devpts_new_index, which would dereference devpts_mnt and crash. Avoid storing invalid values in devpts_mnt; leave it NULL instead. Make both devpts_new_index and devpts_pty_new fail gracefully with ENODEV in that case, which then becomes the return value to the userspace open call on /dev/ptmx. [akpm@linux-foundation.org: remove unneeded static] Signed-off-by:
Josh Triplett <josh@joshtriplett.org> Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Reviewed-by:
Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
-
Thiébaud Weksteen authored
Signed-off-by:
Thiébaud Weksteen <thiebaud@weksteen.fr> Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
-
Thiébaud Weksteen authored
Signed-off-by:
-
Thiébaud Weksteen authored
Signed-off-by:
-
Thiébaud Weksteen authored
Signed-off-by:
-
Jan Kiszka authored
Signed-off-by:
-
Jan Kiszka authored
This makes the usage more flexible. Signed-off-by:
-
Thiébaud Weksteen authored
Add a gdb script to verify the consistency of lists. Signed-off-by:
-
Quentin Lambert authored
Replace occurences of the pci api by appropriate call to the dma api. A simplified version of the semantic patch that finds this problem is as follows: (http://coccinelle.lip6.fr) @deprecated@ idexpression id; position p; @@ ( pci_dma_supported@p ( id, ...) | pci_alloc_consistent@p ( id, ...) ) @bad1@ idexpression id; position deprecated.p; @@ ...when != &id->dev when != pci_get_drvdata ( id ) when != pci_enable_device ( id ) ( pci_dma_supported@p ( id, ...) | pci_alloc_consistent@p ( id, ...) ) @depends on !bad1@ idexpression id; expression direction; position deprecated.p; @@ ( - pci_dma_supported@p ( id, + dma_supported ( &id->dev, ... + , GFP_ATOMIC ) | - pci_alloc_consistent@p ( id, + dma_alloc_coherent ( &id->dev, ... + , GFP_ATOMIC ) ) Signed-off-by:
Quentin Lambert <lambert.quentin@gmail.com> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Fabian Frederick authored
err is only assigned to -EIO. Return that value at the end of fail context. Signed-off-by:
Fabian Frederick <fabf@skynet.be> Signed-off-by:
-
Fabian Frederick authored
bh is initialized unconditionally in affs_remove_link() Signed-off-by:
-
Fabian Frederick authored
bh is initialized unconditionally in affs_add_entry() Signed-off-by:
-
Firo Yang authored
kmem_cache_alloc() returns void*. Signed-off-by:
Firo Yang <firogm@gmail.com> Signed-off-by:
-
Lorenzo Stoakes authored
Fix kernel gcov support for GCC 5.1. Similar to commit a992bf83 ("gcov: add support for GCC 4.9"), this patch takes into account the existence of a new gcov counter (see gcc's gcc/gcov-counter.def.) Firstly, it increments GCOV_COUNTERS (to 10), which makes the data structure struct gcov_info compatible with GCC 5.1. Secondly, a corresponding counter function __gcov_merge_icall_topn (Top N value tracking for indirect calls) is included in base.c with the other gcov counters unused for kernel profiling. Signed-off-by:
Lorenzo Stoakes <lstoakes@gmail.com> Cc: Andrey Ryabinin <a.ryabinin@samsung.com> Cc: Yuan Pengfei <coolypf@qq.com> Tested-by:
Peter Oberparleiter <oberpar@linux.vnet.ibm.com> Reviewed-by:
-
HATAYAMA Daisuke authored
Commit f06e5153 ("kernel/panic.c: add "crash_kexec_post_notifiers" option for kdump after panic_notifers") introduced "crash_kexec_post_notifiers" kernel boot option, which toggles wheather panic() calls crash_kexec() before panic_notifiers and dump kmsg or after. The problem is that the commit overlooks panic_on_oops kernel boot option. If it is enabled, crash_kexec() is called directly without going through panic() in oops path. To fix this issue, this patch adds a check to "crash_kexec_post_notifiers" in the condition of kexec_should_crash(). Also, put a comment in kexec_should_crash() to explain not obvious things on this patch. Signed-off-by:
HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> Acked-by:
Baoquan He <bhe@redhat.com> Tested-by:
Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> Reviewed-by:
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> Cc: Baoquan He <bhe@redhat.com> Signed-off-by:
-
HATAYAMA Daisuke authored
For compatibility with the behaviour before the commit f06e5153 ("kernel/panic.c: add "crash_kexec_post_notifiers" option for kdump after panic_notifers"), the 2nd crash_kexec() should be called only if crash_kexec_post_notifiers is enabled. Note that crash_kexec() returns immediately if kdump crash kernel is not loaded, so in this case, this patch makes no functionality change, but the point is to make it explicit, from the caller panic() side, that the 2nd crash_kexec() does nothing. Signed-off-by:
Ingo Molnar <mingo@kernel.org> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> Cc: Baoquan He <bhe@redhat.com> Signed-off-by:
-
