- 13 Nov, 2013 40 commits
-
-
Jingoo Han authored
Use devm_backlight_device_register() to make cleanup paths simpler, and remove unnecessary remove(). Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Jingoo Han authored
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. This is a cosmetic change to make the code simpler and enhance the readability. Signed-off-by:
-
Jingoo Han authored
Fix the following sparse warning: drivers/video/backlight/lp8788_bl.c:55:25: warning: symbol 'default_bl_config' was not declared. Should it be static? Signed-off-by:
-
Jingoo Han authored
Don't mix different enum types to fix the sparse warnings. drivers/video/backlight/lm3639_bl.c:80:51: warning: mixing different enum types drivers/video/backlight/lm3639_bl.c:80:51: int enum lm3639_fleds versus drivers/video/backlight/lm3639_bl.c:80:51: int enum lm3639_bleds drivers/video/backlight/lm3639_bl.c:82:51: warning: mixing different enum types drivers/video/backlight/lm3639_bl.c:82:51: int enum lm3639_fleds versus drivers/video/backlight/lm3639_bl.c:82:51: int enum lm3639_bleds Signed-off-by:
-
Jingoo Han authored
Fix the following sparse warnings: drivers/video/backlight/ld9040_gamma.h:172:3: warning: symbol 'gamma_table' was not declared. Should it be static? Signed-off-by:
-
Daniel Jeong authored
This patch is to fix sparse warning due to mixing different enum type. Signed-off-by:
Daniel Jeong <gshark.jeong@gmail.com> Cc: Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
Dan Carpenter authored
We dereference "pdata" later in the function so we can't leave it as NULL. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
-
Dan Carpenter authored
"rval" needs to be signed for the error handling to work. Signed-off-by:
-
Daniel Jeong authored
The LM3630 chip was revised by TI and chip name was also changed to LM3630A. And register map, default values and initial sequences are changed. The files, lm3630_bl.{c,h} are replaced by lm3630a_bl.{c,h} You can find more information about LM3630A(datasheet, evm etc) at http://www.ti.com/product/lm3630aSigned-off-by: -
Milo Kim authored
LP8555 is one of the LP855x family devices. This device needs pre_init_device() and post_init_device() driver structure. It's same as LP8557, so the device configuration code is shared with LP8557. Backlight outputs are generated from dual DC-DC boost converters. It's configurable EPROM settings which are defined in the platform data. Driver documentation and device tree bindings are updated. Signed-off-by:
Milo Kim <milo.kim@ti.com> Signed-off-by:
-
Jean Delvare authored
Zwane Mwaikambo's @arm.linux.org.uk address no longer works. In February 2013 he asked for his gmail address to be used instead [1] so let's just do that. [1] http://marc.info/?l=linux-kernel&m=136079068903214&w=2Signed-off-by:
Jean Delvare <jdelvare@suse.de> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Zwane Mwaikambo <zwanem@gmail.com> Signed-off-by:
-
Jingoo Han authored
Remove Richard Purdie as backlight subsystem maintainer, akpm: Richard is still responsive and is reviewing some of the patches, but appears to agree that listing him as the maintainer is no longer appropriate. [akpm@linux-foundation.org: s/USA/UK/] Signed-off-by:
Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Dirk Gouders authored
In one of those comments a typo was fixed, too. Signed-off-by:
Dirk Gouders <dirk@gouders.net> Cc: Joe Perches <joe@perches.com> Signed-off-by:
-
Dave Young authored
boot_delay does not work for earlyprintk because the kernel cmdline parsing is late. Change to use early_param so early kernel messages can also be delayed. Signed-off-by:
Dave Young <dyoung@redhat.com> Signed-off-by:
-
Ryan Mallon authored
Some setuid binaries will allow reading of files which have read permission by the real user id. This is problematic with files which use %pK because the file access permission is checked at open() time, but the kptr_restrict setting is checked at read() time. If a setuid binary opens a %pK file as an unprivileged user, and then elevates permissions before reading the file, then kernel pointer values may be leaked. This happens for example with the setuid pppd application on Ubuntu 12.04: $ head -1 /proc/kallsyms 00000000 T startup_32 $ pppd file /proc/kallsyms pppd: In file /proc/kallsyms: unrecognized option 'c1000000' This will only leak the pointer value from the first line, but other setuid binaries may leak more information. Fix this by adding a check that in addition to the current process having CAP_SYSLOG, that effective user and group ids are equal to the real ids. If a setuid binary reads the contents of a file which uses %pK then the pointer values will be printed as NULL if the real user is unprivileged. Update the sysctl documentation to reflect the changes, and also correct the documentation to state the kptr_restrict=0 is the default. This is a only temporary solution to the issue. The correct solution is to do the permission check at open() time on files, and to replace %pK with a function which checks the open() time permission. %pK uses in printk should be removed since no sane permission check can be done, and instead protected by using dmesg_restrict. Signed-off-by:
Ryan Mallon <rmallon@gmail.com> Cc: Kees Cook <keescook@chromium.org> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Joe Perches <joe@perches.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Andrew Morton authored
It was half-and-half. Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Joe Perches <joe@perches.com> Cc: Kees Cook <keescook@chromium.org> Cc: Tejun Heo <tj@kernel.org> Signed-off-by:
-
Kees Cook authored
This reports the names of consoles as they're being disabled to help identify which is which during cut-over. Helps answer the question "which boot console actually got activated?" once the regular console is running, mostly when debugging boot console failures. Signed-off-by:
Kees Cook <keescook@chromium.org> Acked-by:
Frederic Weisbecker <fweisbec@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Tejun Heo <tj@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Geert Uytterhoeven authored
It's already available in <linux/interrupt.h> Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Vineet Gupta authored
fpu_counter in task_struct was used only by sh/x86. Both of these now carry it in ARCH specific thread_struct, hence this can now be removed from generic task_struct, shrinking it slightly for other arches. Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Paul Mundt <paul.mundt@gmail.com> Signed-off-by:
-
Vineet Gupta authored
Only a couple of arches (sh/x86) use fpu_counter in task_struct so it can be moved out into ARCH specific thread_struct, reducing the size of task_struct for other arches. Compile tested i386_defconfig + gcc 4.7.3 Signed-off-by:
Ingo Molnar <mingo@kernel.org> Cc: Paul Mundt <paul.mundt@gmail.com> Signed-off-by:
-
Vineet Gupta authored
Only a couple of arches (sh/x86) use fpu_counter in task_struct so it can be moved out into ARCH specific thread_struct, reducing the size of task_struct for other arches. Compile tested sh defconfig + sh4-linux-gcc (4.6.3) Signed-off-by:
-
Roel Kluin authored
if (unlikely(x) > 0) doesn't seem to help branch prediction Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: "H. Peter Anvin" <hpa@linux.intel.com> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Geert Uytterhoeven authored
Commit 15d94b82 ("reboot: move shutdown/reboot related functions to kernel/reboot.c") moved all kexec-related functionality to kernel/reboot.c, so kernel/sys.c no longer needs to include <linux/kexec.h>. Signed-off-by:
-
Chen Gang authored
The wrapper function delayacct_add_tsk() already checked 'tsk->delays', and __delayacct_add_tsk() has no another direct callers, so can remove the redundancy checking code. And the label 'done' is also useless, so remove it, too. Signed-off-by:
Chen Gang <gang.chen@asianux.com> Signed-off-by:
-
Michal Nazarewicz authored
getenv() may return NULL if given environment variable does not exist which leads to NULL dereference when calling strncat. Besides that, the environment variable name was copied to a temporary env_var buffer, but this copying can be avoided by simply using the input string. Lastly, the whole loop can be greatly simplified by using the snprintf function instead of the playing with strncat. By the way, the current implementation allows a recursive variable expansion, as in: $ echo 'out ${A} out ' | A='a ${B} a' B=b /tmp/a out a b a out I'm assuming this is just a side effect and not a conscious decision (especially as this may lead to infinite loop), but I didn't want to change this behaviour without consulting. If the current behaviour is deamed incorrect, I'll be happy to send a patch without recursive processing. Signed-off-by:Michal Nazarewicz <mina86@mina86.com> Cc: Kees Cook <keescook@chromium.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Jesper Juhl <jj@codesealer.com> Signed-off-by:
-
Eric Sandeen authored
glibc recently changed the error string for ESTALE to remove "NFS" - https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=96945714ec61951cc748da2b4b8a80cf02127ee9 from: [ERR_REMAP (ESTALE)] = N_("Stale NFS file handle"), to: [ERR_REMAP (ESTALE)] = N_("Stale file handle"), And some have expressed concern that the kernel's errno.h comments still refer to NFS. So make that change... note that this is a comment-only change, and has no functional difference. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
-
Sebastian Capella authored
The name_to_dev_t function has a comment block which lists the supported syntaxes for the device name. Add a bullet for the <major>:<minor> syntax, which is already supported in the code Signed-off-by:
Sebastian Capella <sebastian.capella@linaro.org> Signed-off-by:
-
Andi Kleen authored
For some reason I managed to trick gcc into create CRC symbols that are not absolute anymore, but weak. Make modpost handle this case. Signed-off-by:
Andi Kleen <ak@linux.intel.com> Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by:
-
Andi Kleen authored
Use standard gcc __attribute__((alias(foo))) to define the syscall aliases instead of custom assembler macros. This is far cleaner, and also fixes my LTO kernel build. Signed-off-by:
-
Michael Opdenacker authored
Who needs cramfs when you have squashfs? At least, we should warn people that cramfs is obsolete. Signed-off-by:
Michael Opdenacker <michael.opdenacker@free-electrons.com> Signed-off-by:
-
Greg Thelen authored
Tests various percpu operations. Enable with CONFIG_PERCPU_TEST=m. Signed-off-by:
Greg Thelen <gthelen@google.com> Acked-by:
Tejun Heo <tj@kernel.org> Acked-by:
Johannes Weiner <hannes@cmpxchg.org> Signed-off-by:
-
Prarit Bhargava authored
The CONFIG_HPET_MMAP Kconfig option exposes the memory map of the HPET registers to userspace. The Kconfig help points out that in some cases this can be a security risk as some systems may erroneously configure the map such that additional data is exposed to userspace. This is a problem for distributions -- some users want the MMAP functionality but it comes with a significant security risk. In an effort to mitigate this risk, and due to the low number of users of the MMAP functionality, I've introduced a kernel parameter, hpet_mmap_enable, that is required in order to actually have the HPET MMAP exposed. Signed-off-by:
Prarit Bhargava <prarit@redhat.com> Acked-by:
Matt Wilson <msw@amazon.com> Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Mel Gorman authored
Commit 0255d491 ("mm: Account for a THP NUMA hinting update as one PTE update") was added to account for the number of PTE updates when marking pages prot_numa. task_numa_work was using the old return value to track how much address space had been updated. Altering the return value causes the scanner to do more work than it is configured or documented to in a single unit of work. This patch reverts that commit and accounts for the number of THP updates separately in vmstat. It is up to the administrator to interpret the pair of values correctly. This is a straight-forward operation and likely to only be of interest when actively debugging NUMA balancing problems. The impact of this patch is that the NUMA PTE scanner will scan slower when THP is enabled and workloads may converge slower as a result. On the flip size system CPU usage should be lower than recent tests reported. This is an illustrative example of a short single JVM specjbb test specjbb 3.12.0 3.12.0 vanilla acctupdates TPut 1 26143.00 ( 0.00%) 25747.00 ( -1.51%) TPut 7 185257.00 ( 0.00%) 183202.00 ( -1.11%) TPut 13 329760.00 ( 0.00%) 346577.00 ( 5.10%) TPut 19 442502.00 ( 0.00%) 460146.00 ( 3.99%) TPut 25 540634.00 ( 0.00%) 549053.00 ( 1.56%) TPut 31 512098.00 ( 0.00%) 519611.00 ( 1.47%) TPut 37 461276.00 ( 0.00%) 474973.00 ( 2.97%) TPut 43 403089.00 ( 0.00%) 414172.00 ( 2.75%) 3.12.0 3.12.0 vanillaacctupdates User 5169.64 5184.14 System 100.45 80.02 Elapsed 252.75 251.85 Performance is similar but note the reduction in system CPU time. While this showed a performance gain, it will not be universal but at least it'll be behaving as documented. The vmstats are obviously different but here is an obvious interpretation of them from mmtests. 3.12.0 3.12.0 vanillaacctupdates NUMA page range updates 1408326 11043064 NUMA huge PMD updates 0 21040 NUMA PTE updates 1408326 291624 "NUMA page range updates" == nr_pte_updates and is the value returned to the NUMA pte scanner. NUMA huge PMD updates were the number of THP updates which in combination can be used to calculate how many ptes were updated from userspace. Signed-off-by:
Mel Gorman <mgorman@suse.de> Reported-by:
Alex Thorlton <athorlton@sgi.com> Reviewed-by:
Rik van Riel <riel@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Jerome Marchand authored
The same calculation is currently done in three differents places. Factor that code so future changes has to be made at only one place. [akpm@linux-foundation.org: uninline vm_commit_limit()] Signed-off-by:
Jerome Marchand <jmarchan@redhat.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Michal Hocko <mhocko@suse.cz> Signed-off-by:
-
Zheng Liu authored
Now dirty_background_ratio/dirty_ratio contains a percentage of total avaiable memory, which contains free pages and reclaimable pages. The number of these pages is not equal to the number of total system memory. But they are described as a percentage of total system memory in Documentation/sysctl/vm.txt. So we need to fix them to avoid misunderstanding. Signed-off-by:
Zheng Liu <wenqing.lz@taobao.com> Cc: Rob Landley <rob@landley.net> Signed-off-by:
-
Zhi Yong Wu authored
Signed-off-by:
Zhi Yong Wu <wuzhy@linux.vnet.ibm.com> Signed-off-by:
-
Zhi Yong Wu authored
Signed-off-by:
-
Weijie Yang authored
The refcount routine was not fit the kernel get/put semantic exactly, There were too many judgement statements on refcount and it could be minus. This patch does the following: - move refcount judgement to zswap_entry_put() to hide resource free function. - add a new function zswap_entry_find_get(), so that callers can use easily in the following pattern: zswap_entry_find_get .../* do something */ zswap_entry_put - to eliminate compile error, move some functions declaration This patch is based on Minchan Kim <minchan@kernel.org> 's idea and suggestion. Signed-off-by:Weijie Yang <weijie.yang@samsung.com> Cc: Seth Jennings <sjennings@variantweb.net> Acked-by:
Minchan Kim <minchan@kernel.org> Cc: Bob Liu <bob.liu@oracle.com> Signed-off-by:
-
Weijie Yang authored
Consider the following scenario: thread 0: reclaim entry x (get refcount, but not call zswap_get_swap_cache_page) thread 1: call zswap_frontswap_invalidate_page to invalidate entry x. finished, entry x and its zbud is not freed as its refcount != 0 now, the swap_map[x] = 0 thread 0: now call zswap_get_swap_cache_page swapcache_prepare return -ENOENT because entry x is not used any more zswap_get_swap_cache_page return ZSWAP_SWAPCACHE_NOMEM zswap_writeback_entry do nothing except put refcount Now, the memory of zswap_entry x and its zpage leak. Modify: - check the refcount in fail path, free memory if it is not referenced. - use ZSWAP_SWAPCACHE_FAIL instead of ZSWAP_SWAPCACHE_NOMEM as the fail path can be not only caused by nomem but also by invalidate. Signed-off-by:
Bob Liu <bob.liu@oracle.com> Reviewed-by:
Seth Jennings <sjenning@linux.vnet.ibm.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Qiang Huang authored
Signed-off-by:
Qiang Huang <h.huangqiang@huawei.com> Reviewed-by:
Pekka Enberg <penberg@kernel.org> Acked-by:
David Rientjes <rientjes@google.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.cz> Cc: Glauber Costa <glommer@parallels.com> Signed-off-by:
-
