04 Apr, 2014
40 commits
-
The site-specific OOM messages are unnecessary, because they duplicate
the MM subsystem generic OOM message.Signed-off-by: Jingoo Han
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The site-specific OOM messages are unnecessary, because they duplicate
the MM subsystem generic OOM message.Signed-off-by: Jingoo Han
Acked-by: Stefano Babic
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The site-specific OOM messages are unnecessary, because they duplicate
the MM subsystem generic OOM message.Signed-off-by: Jingoo Han
Acked-by: Maxime Ripard
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The site-specific OOM messages are unnecessary, because they duplicate
the MM subsystem generic OOM message.Signed-off-by: Jingoo Han
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The site-specific OOM messages are unnecessary, because they duplicate
the MM subsystem generic OOM message.Signed-off-by: Jingoo Han
Acked-by: Michael Hennerich
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The site-specific OOM messages are unnecessary, because they duplicate
the MM subsystem generic OOM message.Signed-off-by: Jingoo Han
Acked-by: Michael Hennerich
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The site-specific OOM messages are unnecessary, because they duplicate
the MM subsystem generic OOM message.Signed-off-by: Jingoo Han
Acked-by: Jinyoung Park
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
We don't have to update a backlight status every time a blanking or
unblanking event comes because the backlight status may have already
been what we want. Another thought is that one backlight device may be
shared by multiple framebuffers. We don't hope blanking one of the
framebuffers may turn the backlight off for all the other framebuffers,
since they are likely being active to display something.This patch makes the backlight status be updated only when the relevant
backlight device's use count changes from zero to one or from one to
zero.Signed-off-by: Liu Ying
Cc: Jingoo Han
Cc: Jean-Christophe PLAGNIOL-VILLARD
Cc: Tomi Valkeinen
Cc: Jani Nikula
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
We don't have to update the state and fb_blank properties of a backlight
device every time a blanking or unblanking event comes because they may
have already been what we want. Another thought is that one backlight
device may be shared by multiple framebuffers. The backlight driver
should take the backlight device as a resource shared by all the
associated framebuffers.This patch adds some logic to record each framebuffer's backlight usage
to determine the backlight device use count and whether the two
properties should be updated or not. To be more specific, only one
unblank operation on a certain blanked framebuffer may increase the
backlight device's use count by one, while one blank operation on a
certain unblanked framebuffer may decrease the use count by one, because
the userspace is likely to unblank an unblanked framebuffer or blank a
blanked framebuffer.Signed-off-by: Liu Ying
Cc: Jingoo Han
Cc: Jean-Christophe PLAGNIOL-VILLARD
Cc: Tomi Valkeinen
Cc: Jani Nikula
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Seems he's gone off to bigger/better things. So long, etc...
Signed-off-by: Joe Perches
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
microblaze-uclinux mailing list is almost dead and it is just causing
troubles for non subscribers which are getting email about waiting for
moderator. Approval never happens. Move it to LKML.Signed-off-by: Michal Simek
Reported-by: Richard Guy Briggs
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Dialog Semiconductor Ltd would like to add a new section called DIALOG
SEMICONDUCTOR DRIVERS which contains a new e-mail address that can cover
all Dialog supported drivers: support.opensource@diasemi.com.Signed-off-by: Opensource [Steve Twiss]
Signed-off-by: David Dajun Chen
Cc: Mark Brown
Cc: Joe Perches
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Mark it so.
Signed-off-by: Joe Perches
Acked-by: Geert Uytterhoeven
Cc: Inaky Perez-Gonzalez
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Now that irqchip drivers for xtensa live outside arch/xtensa we'd like
to add them to our maintenance list.Signed-off-by: Max Filippov
Cc: Chris Zankel
Cc: Marc Gauthier
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Paul Mundt's email address bounces regularly, and he hasn't taken any
SuperH patches for about one year.Signed-off-by: Geert Uytterhoeven
Suggested-by: Paul Bolle
Cc: Paul Mundt
Cc: Magnus Damm
Cc: Kuninori Morimoto
Cc: Laurent Pinchart
Cc: Simon Horman
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Bryan Wu and Lee Jones volunteer to maintain backlight drivers and help
to setup git-tree for backlight subsystem. Thus, I add them as
backlight co-maintainers.Signed-off-by: Jingoo Han
Acked-by: Bryan Wu
Acked-by: Lee Jones
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Fix a warning about possible circular locking dependency.
If do in following sequence:
enter suspend -> resume -> plug-out CPUx (echo 0 > cpux/online)
lockdep will show warning as following:
======================================================
[ INFO: possible circular locking dependency detected ]
3.10.0 #2 Tainted: G O
-------------------------------------------------------
sh/1271 is trying to acquire lock:
(console_lock){+.+.+.}, at: console_cpu_notify+0x20/0x2c
but task is already holding lock:
(cpu_hotplug.lock){+.+.+.}, at: cpu_hotplug_begin+0x2c/0x58
which lock already depends on the new lock.the existing dependency chain (in reverse order) is:
-> #2 (cpu_hotplug.lock){+.+.+.}:
lock_acquire+0x98/0x12c
mutex_lock_nested+0x50/0x3d8
cpu_hotplug_begin+0x2c/0x58
_cpu_up+0x24/0x154
cpu_up+0x64/0x84
smp_init+0x9c/0xd4
kernel_init_freeable+0x78/0x1c8
kernel_init+0x8/0xe4
ret_from_fork+0x14/0x2c-> #1 (cpu_add_remove_lock){+.+.+.}:
lock_acquire+0x98/0x12c
mutex_lock_nested+0x50/0x3d8
disable_nonboot_cpus+0x8/0xe8
suspend_devices_and_enter+0x214/0x448
pm_suspend+0x1e4/0x284
try_to_suspend+0xa4/0xbc
process_one_work+0x1c4/0x4fc
worker_thread+0x138/0x37c
kthread+0xa4/0xb0
ret_from_fork+0x14/0x2c-> #0 (console_lock){+.+.+.}:
__lock_acquire+0x1b38/0x1b80
lock_acquire+0x98/0x12c
console_lock+0x54/0x68
console_cpu_notify+0x20/0x2c
notifier_call_chain+0x44/0x84
__cpu_notify+0x2c/0x48
cpu_notify_nofail+0x8/0x14
_cpu_down+0xf4/0x258
cpu_down+0x24/0x40
store_online+0x30/0x74
dev_attr_store+0x18/0x24
sysfs_write_file+0x16c/0x19c
vfs_write+0xb4/0x190
SyS_write+0x3c/0x70
ret_fast_syscall+0x0/0x48Chain exists of:
console_lock --> cpu_add_remove_lock --> cpu_hotplug.lockPossible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(cpu_hotplug.lock);
lock(cpu_add_remove_lock);
lock(cpu_hotplug.lock);
lock(console_lock);
*** DEADLOCK ***There are three locks involved in two sequence:
a) pm suspend:
console_lock (@suspend_console())
cpu_add_remove_lock (@disable_nonboot_cpus())
cpu_hotplug.lock (@_cpu_down())
b) Plug-out CPUx:
cpu_add_remove_lock (@(cpu_down())
cpu_hotplug.lock (@_cpu_down())
console_lock (@console_cpu_notify()) => Lockdeps prints warning log.There should be not real deadlock, as flag of console_suspended can
protect this.Although console_suspend() releases console_sem, it doesn't tell lockdep
about it. That results in the lockdep warning about circular locking
when doing the following: enter suspend -> resume -> plug-out CPUx (echo
0 > cpux/online)Fix the problem by telling lockdep we actually released the semaphore in
console_suspend() and acquired it again in console_resume().Signed-off-by: Jane Li
Reviewed-by: Jan Kara
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The double asmlinkage was introduced in commit 7ff9554bb578 ("printk:
convert byte-buffer to variable-length record buffer").Signed-off-by: Simon Kagstrom
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This is just a tiny optimization. It removes duplicate computation of
the message size.Signed-off-by: Petr Mladek
Cc: Steven Rostedt
Cc: Frederic Weisbecker
Cc: Jan Kara
Cc: Michal Hocko
Cc: Kay Sievers
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
It seems that we have newer used the last byte in the ring buffer. In
fact, we have newer used the last 4 bytes because of padding.First problem is in the check for free space. The exact number of free
bytes is enough to store the length of data.Second problem is in the check where the ring buffer is rotated. The
left side counts the first unused index. It is unused, so it might be
the same as the size of the buffer.Note that the first problem has to be fixed together with the second
one. Otherwise, the buffer is rotated even when there is enough space
on the end of the buffer. Then the beginning of the buffer is rewritten
and valid entries get corrupted.Signed-off-by: Petr Mladek
Cc: Steven Rostedt
Cc: Frederic Weisbecker
Cc: Jan Kara
Cc: Michal Hocko
Cc: Kay Sievers
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
There is no check for potential "text_len" overflow. It is not needed
because only valid level is detected. It took me some time to
understand why. It would deserve a comment ;-)Signed-off-by: Petr Mladek
Cc: Steven Rostedt
Cc: Frederic Weisbecker
Cc: Jan Kara
Cc: Michal Hocko
Cc: Kay Sievers
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The kernel log level "c" was removed in commit 61e99ab8e35a ("printk:
remove the now unnecessary "C" annotation for KERN_CONT"). It is no
longer detected in printk_get_level(). Hence we do not need to check it
in vprintk_emit.Signed-off-by: Petr Mladek
Cc: Steven Rostedt
Cc: Frederic Weisbecker
Cc: Jan Kara
Cc: Michal Hocko
Cc: Kay Sievers
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The check for the exact log level is already done in printk_get_level.
We do not need to duplicate it in printk_skip_level.Signed-off-by: Petr Mladek
Cc: Steven Rostedt
Cc: Frederic Weisbecker
Cc: Jan Kara
Cc: Michal Hocko
Cc: Kay Sievers
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
All in-kernel users of %n in format strings have now been removed and
the %n directive is ignored. Remove the handling of %n so that it is
treated the same as any other invalid format string directive. Keep a
warning in place to deter new instances of %n in format strings.Signed-off-by: Ryan Mallon
Acked-by: Kees Cook
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
sparse says:
kernel/resource.c:518:5: warning:
symbol 'reallocate_resource' was not declared. Should it be static?Signed-off-by: Daeseok Youn
Reviewed-by: Yasuaki Ishimatsu
Acked-by: David Rientjes
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Code that is obj-y (always built-in) or dependent on a bool Kconfig
(built-in or absent) can never be modular. So using module_init as an
alias for __initcall can be somewhat misleading.Fix these up now, so that we can relocate module_init from init.h into
module.h in the future. If we don't do this, we'd have to add module.h
to obviously non-modular code, and that would be a worse thing.The audit targets the following module_init users for change:
kernel/user.c obj-y
kernel/kexec.c bool KEXEC (one instance per arch)
kernel/profile.c bool PROFILING
kernel/hung_task.c bool DETECT_HUNG_TASK
kernel/sched/stats.c bool SCHEDSTATS
kernel/user_namespace.c bool USER_NSNote that direct use of __initcall is discouraged, vs. one of the
priority categorized subgroups. As __initcall gets mapped onto
device_initcall, our use of subsys_initcall (which makes sense for these
files) will thus change this registration from level 6-device to level
4-subsys (i.e. slightly earlier). However no observable impact of that
difference has been observed during testing.Also, two instances of missing ";" at EOL are fixed in kexec.
Signed-off-by: Paul Gortmaker
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Eric Biederman
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
It is only used by procfs and procfs cannot be a module.
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
If the glibc xattr.h header is included after the uapi header,
compilation fails due to an enum re-using a #define from the uapi
header.Protect against this by guarding the define and enum inclusions against
each other.(See https://lists.debian.org/debian-glibc/2014/03/msg00029.html
and https://sourceware.org/glibc/wiki/Synchronizing_Headers
for more information.)Signed-off-by: Serge Hallyn
Cc: Andrew Morton
Cc: Allan McRae
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The Makefile is designed to use the host toolchain so it may be unsafe
to build the tests if the kernel has been configured and built for
another architecture. This fixes a build problem when the kernel has
been configured and built for the MIPS architecture but the host is not
MIPS (cross-compiled). The MIPS syscalls are only defined if one of the
following is true:1) _MIPS_SIM == _MIPS_SIM_ABI64
2) _MIPS_SIM == _MIPS_SIM_ABI32
3) _MIPS_SIM == _MIPS_SIM_NABI32Of course, none of these make sense on a non-MIPS toolchain and the
following build problem occurs when building on a non-MIPS host.linux/usr/include/linux/kexec.h:50: userspace cannot reference function or variable defined in the kernel
samples/seccomp/bpf-direct.c: In function `emulator':
samples/seccomp/bpf-direct.c:76:17: error: `__NR_write' undeclared (first use in this function)Signed-off-by: Markos Chandras
Reported-by: Paul Gortmaker
Cc: Ralf Baechle
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Use the more natural return of bool for these tests.
No difference observed in .o files produced by gcc for x86.
Remove the dentry description of kernel pointers left over from the 90's
and 2002's cleanup move of parts of fs.h to err.h.Signed-off-by: Joe Perches
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Most of the mechanical portions of SubmittingPatches exist to help patch
submitters replicate the output of git. Mention this explicitly, both
as a reminder that git will help with this process, and as signposting
to let git users know what they can safely skip.Signed-off-by: Josh Triplett
Acked-by: Borislav Petkov
Cc: Rob Landley
Cc: Randy Dunlap
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
SubmittingPatches already mentions referencing bugs fixed by a commit,
but doesn't mention citing relevant mailing list discussions. Add a
note to that effect, along with a recommendation to use the
https://lkml.kernel.org/ redirector.Portions based on text from git's SubmittingPatches.
Signed-off-by: Josh Triplett
Acked-by: Borislav Petkov
Cc: Rob Landley
Cc: Randy Dunlap
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Most commit messages use this style, and the recommendation frequently
comes up in discussions (especially in response to patches that don't
use it), but that recommendation doesn't actually appear anywhere in
Documentation. Add this style guideline to SubmittingPatches, using the
description from git's SubmittingPatches.Signed-off-by: Josh Triplett
Acked-by: Borislav Petkov
Cc: Rob Landley
Cc: Randy Dunlap
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
uselib hasn't been used since libc5; glibc does not use it. Support
turning it off.When disabled, also omit the load_elf_library implementation from
binfmt_elf.c, which only uselib invokes.bloat-o-meter:
add/remove: 0/4 grow/shrink: 0/1 up/down: 0/-785 (-785)
function old new delta
padzero 39 36 -3
uselib_flags 20 - -20
sys_uselib 168 - -168
SyS_uselib 168 - -168
load_elf_library 426 - -426The new CONFIG_USELIB defaults to `y'.
Signed-off-by: Josh Triplett
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
After commit 6307f8fee295 ("security: remove dead hook task_setgroups"),
set_groups will always return zero, so we could just remove return value
of set_groups.This patch reduces code size, and simplfies code to use set_groups,
because we don't need to check its return value any more.[akpm@linux-foundation.org: remove obsolete claims from set_groups() comment]
Signed-off-by: Wang YanQing
Cc: "Eric W. Biederman"
Cc: Serge Hallyn
Cc: Eric Paris
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
sys_sysfs is an obsolete system call no longer supported by libc.
- This patch adds a default CONFIG_SYSFS_SYSCALL=y
- Option can be turned off in expert mode.
- cond_syscall added to kernel/sys_ni.c
[akpm@linux-foundation.org: tweak Kconfig help text]
Signed-off-by: Fabian Frederick
Cc: Randy Dunlap
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This eliminates the following warning in quota/compat.c:
fs/quota/compat.c:43:17: warning: no previous prototype for `sys32_quotactl' [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Currently max_sane_readahead() returns zero on the cpu whose NUMA node
has no local memory which leads to readahead failure. Fix this
readahead failure by returning minimum of (requested pages, 512). Users
running applications on a memory-less cpu which needs readahead such as
streaming application see considerable boost in the performance.Result:
fadvise experiment with FADV_WILLNEED on a PPC machine having memoryless
CPU with 1GB testfile (12 iterations) yielded around 46.66% improvement.fadvise experiment with FADV_WILLNEED on a x240 machine with 1GB
testfile 32GB* 4G RAM numa machine (12 iterations) showed no impact on
the normal NUMA cases w/ patch.Kernel Avg Stddev
base 7.4975 3.92%
patched 7.4174 3.26%[Andrew: making return value PAGE_SIZE independent]
Suggested-by: Linus Torvalds
Signed-off-by: Raghavendra K T
Acked-by: Jan Kara
Cc: Wu Fengguang
Cc: David Rientjes
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
We release the slab_mutex while calling sysfs_slab_add from
__kmem_cache_create since commit 66c4c35c6bc5 ("slub: Do not hold
slub_lock when calling sysfs_slab_add()"), because kobject_uevent called
by sysfs_slab_add might block waiting for the usermode helper to exec,
which would result in a deadlock if we took the slab_mutex while
executing it.However, apart from complicating synchronization rules, releasing the
slab_mutex on kmem cache creation can result in a kmemcg-related race.
The point is that we check if the memcg cache exists before going to
__kmem_cache_create, but register the new cache in memcg subsys after
it. Since we can drop the mutex there, several threads can see that the
memcg cache does not exist and proceed to creating it, which is wrong.Fortunately, recently kobject_uevent was patched to call the usermode
helper with the UMH_NO_WAIT flag, making the deadlock impossible.
Therefore there is no point in releasing the slab_mutex while calling
sysfs_slab_add, so let's simplify kmem_cache_create synchronization and
fix the kmemcg-race mentioned above by holding the slab_mutex during the
whole cache creation path.Signed-off-by: Vladimir Davydov
Acked-by: Christoph Lameter
Cc: Greg KH
Cc: Pekka Enberg
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Currently kobject_uevent has somewhat unpredictable semantics. The
point is, since it may call a usermode helper and wait for it to execute
(UMH_WAIT_EXEC), it is impossible to say for sure what lock dependencies
it will introduce for the caller - strictly speaking it depends on what
fs the binary is located on and the set of locks fork may take. There
are quite a few kobject_uevent's users that do not take this into
account and call it with various mutexes taken, e.g. rtnl_mutex,
net_mutex, which might potentially lead to a deadlock.Since there is actually no reason to wait for the usermode helper to
execute there, let's make kobject_uevent start the helper asynchronously
with the aid of the UMH_NO_WAIT flag.Personally, I'm interested in this, because I really want kobject_uevent
to be called under the slab_mutex in the slub implementation as it used
to be some time ago, because it greatly simplifies synchronization and
automatically fixes a kmemcg-related race. However, there was a
deadlock detected on an attempt to call kobject_uevent under the
slab_mutex (see https://lkml.org/lkml/2012/1/14/45), which was reported
to be fixed by releasing the slab_mutex for kobject_uevent.Unfortunately, there was no information about who exactly blocked on the
slab_mutex causing the usermode helper to stall, neither have I managed
to find this out or reproduce the issue.BTW, this is not the first attempt to make kobject_uevent use
UMH_NO_WAIT. Previous one was made by commit f520360d93cd ("kobject:
don't block for each kobject_uevent"), but it was wrong (it passed
arguments allocated on stack to async thread) so it was reverted in
05f54c13cd0c ("Revert "kobject: don't block for each kobject_uevent".").
It targeted on speeding up the boot process though.Signed-off-by: Vladimir Davydov
Cc: Greg KH
Cc: Christoph Lameter
Cc: Pekka Enberg
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
