- 14 Oct, 2014 40 commits
-
-
Rasmus Villemoes authored
The kernel used to contain two functions for length-delimited, case-insensitive string comparison, strnicmp with correct semantics and a slightly buggy strncasecmp. The latter is the POSIX name, so strnicmp was renamed to strncasecmp, and strnicmp made into a wrapper for the new strncasecmp to avoid breaking existing users. To allow the compat wrapper strnicmp to be removed at some point in the future, and to avoid the extra indirection cost, do s/strnicmp/strncasecmp/g. Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Russell King <linux@arm.linux.org.uk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Rasmus Villemoes authored
The previous patch made strnicmp into a wrapper for strncasecmp. This patch makes all in-tree users of strnicmp call strncasecmp directly, while still making sure that the strnicmp symbol can be used by out-of-tree modules. It should be considered a temporary hack until all in-tree callers have been converted. Signed-off-by:
-
Rasmus Villemoes authored
lib/string.c contains two functions, strnicmp and strncasecmp, which do roughly the same thing, namely compare two strings case-insensitively up to a given bound. They have slightly different implementations, but the only important difference is that strncasecmp doesn't handle len==0 appropriately; it effectively becomes strcasecmp in that case. strnicmp correctly says that two strings are always equal in their first 0 characters. strncasecmp is the POSIX name for this functionality. So rename the non-broken function to the standard name. To minimize the impact on the rest of the kernel (and since both are exported to modules), make strnicmp a wrapper for strncasecmp. Signed-off-by:
-
Andrew Morton authored
x86_64 allnoconfig: arch/x86/kernel/cpu/common.c:968: warning: 'syscall32_cpu_init' defined but not used Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Tim Gardner authored
In file included from scripts/sortextable.c:194:0: scripts/sortextable.c: In function `main': scripts/sortextable.h:176:3: warning: `relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] memset(relocs, 0, relocs_size); ^ scripts/sortextable.h:106:6: note: `relocs_size' was declared here int relocs_size; ^ In file included from scripts/sortextable.c:192:0: scripts/sortextable.h:176:3: warning: `relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] memset(relocs, 0, relocs_size); ^ scripts/sortextable.h:106:6: note: `relocs_size' was declared here int relocs_size; ^ gcc 4.9.1 Signed-off-by:Tim Gardner <tim.gardner@canonical.com> Reviewed-by:
Jamie Iles <jamie.iles@oracle.com> Signed-off-by:
-
Javier Barrio authored
- headers_install requires at least two arguments - missed closing quote Signed-off-by:
Javier Barrio <javier.barrio.mart@gmail.com> Cc: Michal Marek <mmarek@suse.cz> Signed-off-by:
-
Mark Rustad authored
Resolve some shadow warnings produced in W=2 builds by changing the name of some parameters and local variables. Change instances of "s64" because that clashes with the well-known typedef. Also change a local variable with the name "up" because that clashes with the name of of the "up" function for semaphores. These are hazards so eliminate the hazards by renaming them. Signed-off-by:
Mark Rustad <mark.d.rustad@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Rob Jones authored
Using __seq_open_private() removes boilerplate code from sysvipc_proc_open(). The resultant code is shorter and easier to follow. However, please note that __seq_open_private() call kzalloc() rather than kmalloc() which may affect timing due to the memory initialisation overhead. Signed-off-by:
Rob Jones <rob.jones@codethink.co.uk> Signed-off-by:
-
Oleg Nesterov authored
do_shmat() is the only user of ->start_stack (proc just reports its value), and this check looks ugly and wrong. The reason for this check is not clear at all, and it wrongly assumes that the stack can only grow down. But the main problem is that in general mm->start_stack has nothing to do with stack_vma->vm_start. Not only the application can switch to another stack and even unmap this area, setup_arg_pages() expands the stack without updating mm->start_stack during exec(). This means that in the likely case "addr > start_stack - size - PAGE_SIZE * 5" is simply impossible after find_vma_intersection() == F, or the stack can't grow anyway because of RLIMIT_STACK. Many thanks to Hugh for his explanations. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Acked-by:
Hugh Dickins <hughd@google.com> Cc: Cyrill Gorcunov <gorcunov@gmail.com> Cc: Davidlohr Bueso <davidlohr.bueso@hp.com> Signed-off-by:
-
Andrey Vagin authored
proc_dointvec_minmax() returns zero if a new value has been set. So we don't need to check all charecters have been handled. Below you can find two examples. In the new value has not been handled properly. $ strace ./a.out open("/proc/sys/kernel/auto_msgmni", O_WRONLY) = 3 write(3, "0\n\0", 3) = 2 close(3) = 0 exit_group(0) $ cat /sys/kernel/debug/tracing/trace $strace ./a.out open("/proc/sys/kernel/auto_msgmni", O_WRONLY) = 3 write(3, "0\n", 2) = 2 close(3) = 0 $ cat /sys/kernel/debug/tracing/trace a.out-697 [000] .... 3280.998235: unregister_ipcns_notifier <-proc_ipcauto_dointvec_minmax Fixes: 9eefe520 ("ipc: do not use a negative value to re-enable msgmni automatic recomputin") Signed-off-by:Andrey Vagin <avagin@openvz.org> Cc: Mathias Krause <minipli@googlemail.com> Cc: Manfred Spraul <manfred@colorfullife.com> Cc: Joe Perches <joe@perches.com> Cc: Davidlohr Bueso <davidlohr@hp.com> Signed-off-by:
-
Mark Rustad authored
Resolve shadow warnings that are produced in W=2 builds by renaming a global with a too-generic name and renaming a formal parameter. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
-
Mike Travis authored
Use the optimized ioresource lookup, "region_is_ram", for the ioremap function. If the region is not found, it falls back to the "page_is_ram" function. If it is found and it is RAM, then the usual warning message is issued, and the ioremap operation is aborted. Otherwise, the ioremap operation continues. Signed-off-by:
Mike Travis <travis@sgi.com> Acked-by:
Alex Thorlton <athorlton@sgi.com> Reviewed-by:
Cliff Wickman <cpw@sgi.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Mark Salter <msalter@redhat.com> Cc: Dave Young <dyoung@redhat.com> Cc: Rik van Riel <riel@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Mel Gorman <mgorman@suse.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Mike Travis authored
We have a large university system in the UK that is experiencing very long delays modprobing the driver for a specific I/O device. The delay is from 8-10 minutes per device and there are 31 devices in the system. This 4 to 5 hour delay in starting up those I/O devices is very much a burden on the customer. There are two causes for requiring a restart/reload of the drivers. First is periodic preventive maintenance (PM) and the second is if any of the devices experience a fatal error. Both of these trigger this excessively long delay in bringing the system back up to full capability. The problem was tracked down to a very slow IOREMAP operation and the excessively long ioresource lookup to insure that the user is not attempting to ioremap RAM. These patches provide a speed up to that function. The modprobe time appears to be affected quite a bit by previous activity on the ioresource list, which I suspect is due to cache preloading. While the overall improvement is impacted by other overhead of starting the devices, this drastically improves the modprobe time. Also our system is considerably smaller so the percentages gained will not be the same. Best case improvement with the modprobe on our 20 device smallish system was from 'real 5m51.913s' to 'real 0m18.275s'. This patch (of 2): Since the ioremap operation is verifying that the specified address range is NOT RAM, it will search the entire ioresource list if the condition is true. To make matters worse, it does this one 4k page at a time. For a 128M BAR region this is 32 passes to determine the entire region does not contain any RAM addresses. This patch provides another resource lookup function, region_is_ram, that searches for the entire region specified, verifying that it is completely contained within the resource region. If it is found, then it is checked to be RAM or not, within a single pass. The return result reflects if it was found or not (-1), and whether it is RAM (1) or not (0). This allows the caller to fallback to the previous page by page search if it was not found. [akpm@linux-foundation.org: fix spellos and typos in comment] Signed-off-by:
-
Fabian Frederick authored
This patch defines maximum block number to 2^31. It also converts bitmap_size and array_size to unsigned int in omfs_get_imap Signed-off-by:
Fabian Frederick <fabf@skynet.be> Suggested-by:
Bob Copeland <me@bobcopeland.com> Acked-by:
-
Thierry Reding authored
When PM_SLEEP is not enabled, the r592_clear_interrupts() function is never used. If so, don't build it to prevent a compiler warning. Signed-off-by:
Thierry Reding <treding@nvidia.com> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by:
-
Fabian Frederick authored
sys_tz is already declared in include/linux/time.h Signed-off-by:
-
Fabian Frederick authored
Four functions declared variables twice resulting in shadow warnings. This patch renames internal variables and adds blank line after declarations. Signed-off-by:
-
Fabian Frederick authored
head is set to AFFS_HEAD(bh) but never used. Signed-off-by:
-
Fabian Frederick authored
key is set in affs_fill_super but never used. Signed-off-by:
-
Lai Jiangshan authored
The comment is copied from Documentation/rbtree.txt, but this comment is so important that it should also be in the code. Signed-off-by:
Lai Jiangshan <laijs@cn.fujitsu.com> Acked-by:
Michel Lespinasse <walken@google.com> Signed-off-by:
-
Vivek Goyal authored
David Howells brought to my attention the mails generated by kbuild test bot and following sparse warnings were present. This patch fixes these warnings. arch/x86/kernel/kexec-bzimage64.c:270:5: warning: symbol 'bzImage64_probe' was not declared. Should it be static? arch/x86/kernel/kexec-bzimage64.c:328:6: warning: symbol 'bzImage64_load' was not declared. Should it be static? arch/x86/kernel/kexec-bzimage64.c:517:5: warning: symbol 'bzImage64_cleanup' was not declared. Should it be static? arch/x86/kernel/kexec-bzimage64.c:531:5: warning: symbol 'bzImage64_verify_sig' was not declared. Should it be static? arch/x86/kernel/kexec-bzimage64.c:546:23: warning: symbol 'kexec_bzImage64_ops' was not declared. Should it be static? Signed-off-by:
Vivek Goyal <vgoyal@redhat.com> Reported-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Baoquan He authored
This is a cleanup. In function parse_crashkernel_suffix, the parameter crash_base is not used. So here remove it. Signed-off-by:
Baoquan He <bhe@redhat.com> Acked-by:
-
Baoquan He authored
Add a check if crashk_res_low exists just like GART region does. If crashk_res_low doesn't exist, calling exclude_mem_range is unnecessary. Meanwhile, since crashk_res_low has been initialized at definition, it's safe just use "if (crashk_low_res.end)" to check if it's exist. And this can make it consistent with other places of check. Signed-off-by:
-
Baoquan He authored
In locate_mem_hole functions, a memory hole is located and added as kexec_segment. But from the name of locate_mem_hole, it should only take responsibility of searching a available memory hole to contain data of a specified size. So in this patch add a new field 'mem' into kexec_buf, then take that kexec segment adding code out of locate_mem_hole_top_down and locate_mem_hole_bottom_up. This make clear of the functionality of locate_mem_hole just like it declars to do. And by this locate_mem_hole_callback chould be used later if anyone want to locate a memory hole for other use. Meanwhile Vivek suggested opening code function __kexec_add_segment(), that way we have to retreive ksegment pointer once and it is easy to read. So just do it in this patch and remove __kexec_add_segment() since no one use it anymore. Signed-off-by:
-
Baoquan He authored
Make the Makefile of kexec purgatory be consistent with others in linux src tree, and make it look generic and simple. Signed-off-by:
-
Oleg Nesterov authored
format_corename() can only pass the leader's pid to the core handler, but there is no simple way to figure out which thread originated the coredump. As Jan explains, this also means that there is no simple way to create the backtrace of the crashed process: As programs are mostly compiled with implicit gcc -fomit-frame-pointer one needs program's .eh_frame section (equivalently PT_GNU_EH_FRAME segment) or .debug_frame section. .debug_frame usually is present only in separate debug info files usually not even installed on the system. While .eh_frame is a part of the executable/library (and it is even always mapped for C++ exceptions unwinding) it no longer has to be present anywhere on the disk as the program could be upgraded in the meantime and the running instance has its executable file already unlinked from disk. One possibility is to echo 0x3f >/proc/*/coredump_filter and dump all the file-backed memory including the executable's .eh_frame section. But that can create huge core files, for example even due to mmapped data files. Other possibility would be to read .eh_frame from /proc/PID/mem at the core_pattern handler time of the core dump. For the backtrace one needs to read the register state first which can be done from core_pattern handler: ptrace(PTRACE_SEIZE, tid, 0, PTRACE_O_TRACEEXIT) close(0); // close pipe fd to resume the sleeping dumper waitpid(); // should report EXIT PTRACE_GETREGS or other requests The remaining problem is how to get the 'tid' value of the crashed thread. It could be read from the first NT_PRSTATUS note of the core file but that makes the core_pattern handler complicated. Unfortunately %t is already used so this patch uses %i/%I. Automatic Bug Reporting Tool (https://github.com/abrt/abrt/wiki/overview) is experimenting with this. It is using the elfutils (https://fedorahosted.org/elfutils/) unwinder for generating the backtraces. Apart from not needing matching executables as mentioned above, another advantage is that we can get the backtrace without saving the core (which might be quite large) to disk. [mmilata@redhat.com: final paragraph of changelog] Signed-off-by:Jan Kratochvil <jan.kratochvil@redhat.com> Signed-off-by:
-
Oleg Nesterov authored
Kill _NSIG_WORDS_is_unsupported_size(), use BUILD_BUG() instead. This simplifies the code, avoids the nested-externs warnings, and this way we do not defer the problem to linker. Also, fix the indentation in _SIG_SET_BINOP() and _SIG_SET_OP(). Note: this patch assumes that the code like "if (0) BUILD_BUG();" is valid. If not (say __compiletime_error() is not defined and thus __compiletime_error_fallback() uses a negative array) we should fix BUILD_BUG() and/or BUILD_BUG_ON_MSG(). This code should be fine by definition, this is the documented purpose of BUILD_BUG(). [sfr@canb.auug.org.au: fix powerpc build failures] Signed-off-by:
Josh Triplett <josh@joshtriplett.org> Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Fabian Frederick authored
sys_tz is already declared extern struct in include/linux/time.h Signed-off-by:
-
Fabian Frederick authored
Merge conditional unlock/lock in the same condition to avoid sparse warning: fs/reiserfs/journal.c:703:36: warning: context imbalance in 'add_to_chunk' - unexpected unlock Signed-off-by:
-
Fabian Frederick authored
ucg is defined and set in ufs_bitmap_search but never used. Signed-off-by:
-
Fabian Frederick authored
sys_tz is already declared in include/linux/time.h Signed-off-by:
-
Andreas Rohner authored
Support for fdatasync() has been implemented in NILFS2 for a long time, but whenever the corresponding inode is dirty the implementation falls back to a full-flegded sync(). Since every write operation has to update the modification time of the file, the inode will almost always be dirty and fdatasync() will fall back to sync() most of the time. But this fallback is only necessary for a change of the file size and not for a change of the various timestamps. This patch adds a new flag NILFS_I_INODE_SYNC to differentiate between those two situations. * If it is set the file size was changed and a full sync is necessary. * If it is not set then only the timestamps were updated and fdatasync() can go ahead. There is already a similar flag I_DIRTY_DATASYNC on the VFS layer with the exact same semantics. Unfortunately it cannot be used directly, because NILFS2 doesn't implement write_inode() and doesn't clear the VFS flags when inodes are written out. So the VFS writeback thread can clear I_DIRTY_DATASYNC at any time without notifying NILFS2. So I_DIRTY_DATASYNC has to be mapped onto NILFS_I_INODE_SYNC in nilfs_update_inode(). Signed-off-by:
Andreas Rohner <andreas.rohner@gmx.net> Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Signed-off-by:
-
Andreas Rohner authored
Under normal circumstances nilfs_sync_fs() writes out the super block, which causes a flush of the underlying block device. But this depends on the THE_NILFS_SB_DIRTY flag, which is only set if the pointer to the last segment crosses a segment boundary. So if only a small amount of data is written before the call to nilfs_sync_fs(), no flush of the block device occurs. In the above case an additional call to blkdev_issue_flush() is needed. To prevent unnecessary overhead, the new flag nilfs->ns_flushed_device is introduced, which is cleared whenever new logs are written and set whenever the block device is flushed. For convenience the function nilfs_flush_device() is added, which contains the above logic. Signed-off-by:
-
Himangi Saraogi authored
The Linux kernel coding style guidelines suggest not using typedefs for structure types. This patch gets rid of the typedef for befs_btree_node. The following Coccinelle semantic patch detects the case. @tn1@ type td; @@ typedef struct { ... } td; @script:python tf@ td << tn1.td; tdres; @@ coccinelle.tdres = td; @@ type tn1.td; identifier tf.tdres; @@ -typedef struct + tdres { ... } -td ; @@ type tn1.td; identifier tf.tdres; @@ -td + struct tdres Signed-off-by:Himangi Saraogi <himangi774@gmail.com> Acked-by:
Julia Lawall <julia.lawall@lip6.fr> Signed-off-by:
-
Daniel Glöckner authored
Commit b5ada460 ("drivers/rtc/rtc-cmos.c: fix compilation warning when !CONFIG_PM_SLEEP") broke wakeup from S5 by making cmos_poweroff a nop unless CONFIG_PM_SLEEP was defined. Fix this by restricting the #ifdef to cmos_resume and restoring the old dependency on CONFIG_PM for cmos_suspend and cmos_poweroff. Signed-off-by:
Daniel Glöckner <daniel-gl@gmx.net> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Chen Gang authored
Some drivers need 'devm_ioremap_resource' or 'devm_ioremap' which need HAS_IOMEM, so let them depend on it. The related error (with allmodconfig under score): MODPOST 1365 modules ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-xgene.ko] undefined! ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-stk17ta8.ko] undefined! ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1742.ko] undefined! ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1553.ko] undefined! ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1511.ko] undefined! ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1286.ko] undefined! ERROR: "devm_ioremap" [drivers/rtc/rtc-rp5c01.ko] undefined! ERROR: "devm_ioremap" [drivers/rtc/rtc-msm6242.ko] undefined! ERROR: "devm_ioremap" [drivers/rtc/rtc-m48t59.ko] undefined! ERROR: "devm_ioremap" [drivers/rtc/rtc-m48t35.ko] undefined! ERROR: "devm_ioremap" [drivers/rtc/rtc-bq4802.ko] undefined! Signed-off-by:Chen Gang <gang.chen.5i5j@gmail.com> Signed-off-by:
-
Andy Shevchenko authored
Instead of pushing each byte let's reduce stack usage by using %*ph specifier. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Arnd Bergmann authored
As pointed out by Sergei Shtylyov, the pcf8563_irq function contains a bug in the error handling: an interrupt handler is not supposed to return an errno value but an 'enum irqreturn'. Let's fix this by returning IRQ_NONE in case of a communication error. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Arnd Bergmann authored
gcc-4.9 found a potential condition under which the 'pending' variable may be used uninitialized: drivers/rtc/rtc-pcf8563.c: In function 'pcf8563_irq': drivers/rtc/rtc-pcf8563.c:173:5: warning: 'pending' may be used uninitialized in this function [-Wmaybe-uninitialized] This is because in the pcf8563_get_alarm_mode() function, we check any nonzero return of pcf8563_read_block_data, but in the irq function we only check for negative values, so a possible positive value does not get detected if the compiler chooses not to inline the entire call chain. Checking for any non-zero value in the interrupt handler as well is just as correct and lets the compiler know what we are doing, without needing a bogus initialization. Signed-off-by:
-
Javier Martinez Canillas authored
The MAX7802 PMIC has a Real-Time-Clock (RTC) with two alarms. This patch adds support for the RTC and is based on a driver added by Simon Glass to the Chrome OS kernel 3.8 tree. [akpm@linux-foundation.org: add comment clarifying ffs() use] Signed-off-by:
Javier Martinez Canillas <javier.martinez@collabora.co.uk> Reviewed-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Cc: Doug Anderson <dianders@chromium.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Olof Johansson <olof@lixom.net> Cc: Simon Glass <sjg@chromium.org> Signed-off-by:
-
