Jingoo Han [Tue, 26 Mar 2013 23:25:33 +0000 (10:25 +1100)]
drivers/rtc/rtc-s3c.c: convert s3c_rtc to dev_pm_ops
Instead of using legacy suspend/resume methods, using newer dev_pm_ops
structure allows better control over power management. Also, 'wake_en'
variable is moved, because it is only used when CONFIG_PM_SLEEP is
enabled.
Signed-off-by: Jingoo Han <jg1.han@samsung.com> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bertrand Achard [Tue, 26 Mar 2013 23:25:32 +0000 (10:25 +1100)]
drivers/rtc/rtc-ds1307.c: long block operations bugfix
The rtc-ds1307 driver does not properly handle block operations bigger
than 32 bytes in either of the two modes supported (SMbus native, or
emulated if not supported by the SMbus platform driver).
It also does not properly handle userland-supplied input (block operation
length) through sysfs and may suffer a type of buffer overrun.
The driver has been modified with proper input validation, buffer sizes,
and now splits block transfers bigger than 32 bytes into separate
transfers.
Explanation : Buffer size allocated is I2C_SMBUS_BLOCK_MAX which equals to
32 as per the SMbus spec. Reads and write may be up to 56 bytes (to the
NVRAM). This patch allocated a 255 byte buffer, the maximum allowable
(address is an u8). It's not only a buffer problem, SMbus only supports
up to 32 bytes transfer at once, so it's needed to split bigger transfers.
Patch successfully tested on 3.2.27; cleanly applies on 3.7-rc4.
[akpm@linux-foundation.org: rework code to avoid 80-column overflows] Signed-off-by: Bertrand Achard <ba@cykian.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Laxman Dewangan [Tue, 26 Mar 2013 23:25:32 +0000 (10:25 +1100)]
drivers/rtc/rtc-tegra.c: fix build warning
Fix the below build warning:
drivers/rtc/rtc-tegra.c: In function 'tegra_rtc_probe':
drivers/rtc/rtc-tegra.c:353:33: warning: passing argument 1 of 'devm_rtc_device_register' from incompatible pointer type [enabled by default]
include/linux/rtc.h:136:27: note: expected 'struct device *' but argument is of type 'const char *'
drivers/rtc/rtc-tegra.c:353:33: warning: passing argument 2 of 'devm_rtc_device_register' from incompatible pointer type [enabled by default]
include/linux/rtc.h:136:27: note: expected 'const char *' but argument is of type 'struct device *'
Laxman Dewangan [Tue, 26 Mar 2013 23:25:32 +0000 (10:25 +1100)]
drivers/rtc/rtc-tegra.c: use managed rtc_device_register()
Use devm_rtc_device_register() for registering RTC device. This will
reduce the code for unregistering RTC device in cleanup path and remove
the implementation of remove callback of platform driver.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Cc: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Laxman Dewangan [Tue, 26 Mar 2013 23:25:31 +0000 (10:25 +1100)]
drivers/rtc/rtc-tegra.c: use struct dev_pm_ops for power management
Make the Tegra RTC controller driver define its PM callbacks through a
struct dev_pm_ops object rather than by using legacy PM hooks in struct
platform_driver.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Cc: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Laxman Dewangan [Tue, 26 Mar 2013 23:25:31 +0000 (10:25 +1100)]
drivers/rtc/rtc-tegra.c: protect suspend/resume callbacks with CONFIG_PM_SLEEP
CONFIG_PM doesn't actually enable any of the PM callbacks, it only allows
to enable CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME. This means if CONFIG_PM
is used to protect system sleep callbacks then it may end up unreferenced
if only runtime PM is enabled. Hence protecting sleep callbacks with
CONFIG_PM_SLEEP.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Cc: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
The "fix set time sync time issue" adds calls to udelay(), but
doesn't add the include file. End result is build breakage:
drivers/rtc/rtc-pxa.c: In function 'pxa_rtc_set_time':
drivers/rtc/rtc-pxa.c:267:2: error: implicit declaration of function 'udelay' [-Werror=implicit-function-declaration]
Signed-off-by: Olof Johansson <olof@lixom.net> Cc: Leo Song <liangs@marvell.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Devendra Naga [Tue, 26 Mar 2013 23:25:30 +0000 (10:25 +1100)]
below is the warning reported with the gcc (gcc (GCC) 4.7.2 20121109 (Red
Hat 4.7.2-8))
with make W=1
drivers/rtc/rtc-ds1286.c: In function `ds1286_read_alarm':
drivers/rtc/rtc-ds1286.c:273:16: warning: variable `cmd' set but not used [-Wunused-but-set-variable]
fixed by removing the variable
Signed-off-by: Devendra Naga <devendra.aaru@gmail.com> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Jingoo Han [Tue, 26 Mar 2013 23:25:15 +0000 (10:25 +1100)]
drivers/rtc/class.c: use struct device as the first argument for devm_rtc_device_register()
Other devm_* APIs use 'struct device *dev' as the first argument. Thus,
in order to sync with other devm_* functions, struct device is used as the
first argument for devm_rtc_device_register().
Signed-off-by: Jingoo Han <jg1.han@samsung.com> Cc: Tejun Heo <tj@kernel.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Jingoo Han [Tue, 26 Mar 2013 23:25:15 +0000 (10:25 +1100)]
drivers/rtc/rtc-v3020.c: use gpio_request_array()
Using gpio_request_array()/gpio_free_array() can make the code simpler
because it can set the direction and initial value in one shot and the for
loop is unnecessary.
Also, struct v3020_gpio is removed, because the struct v3020_gpio is
replaced with struct gpio.
Signed-off-by: Jingoo Han <jg1.han@samsung.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Igor Grinberg <grinberg@compulab.co.il> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Move the calls to memcpy_fromio() up into the loop in dmi_scan_machine(),
and move the signature checks back down into dmi_decode(). We need to
check at 16-byte intervals but keep a 32-byte buffer for an SMBIOS entry,
so shift the buffer after each iteration.
Merge smbios_present() into dmi_present(), so we look for an SMBIOS
signature at the beginning of the given buffer and then for a DMI
signature at an offset of 16 bytes.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Reported-by: Tim McGrath <tmhikaru@gmail.com> Tested-by: Tim Mcgrath <tmhikaru@gmail.com> Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
If the kernel was booted with the "quiet" boot option we have currently no
chance to see why an initrd fails. Change KERN_WARNING to KERN_ERR to see
what is going on.
Signed-off-by: Richard Weinberger <richard@nod.at> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Jim Cromie <jim.cromie@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Steven Rostedt [Tue, 26 Mar 2013 23:25:09 +0000 (10:25 +1100)]
init: scream bloody murder if interrupts are enabled too early
As I was testing a lot of my code recently, and having several
"successes", I accidentally noticed in the dmesg this little line:
[ 0.000000] start_kernel(): bug: interrupts were enabled *very* early, fixing it
Sure enough, one of my patches two commits ago enabled interrupts early.
The sad part here is that I never noticed it, and I ran several tests with
ktest too, and ktest did not notice this line.
What ktest looks for (and so does many other automated testing scripts) is
a back trace produced by a WARN_ON() or BUG(). As a back trace was never
produced, my buggy patch could have slipped into linux-next, or even
worse, mainline.
Adding a WARN(!irqs_disabled()) makes this bug a little more obvious:
[ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.000000] __ex_table already sorted, skipping sort
[ 0.000000] Checking aperture...
[ 0.000000] No AGP bridge found
[ 0.000000] Calgary: detecting Calgary via BIOS EBDA area
[ 0.000000] Calgary: Unable to locate Rio Grande table in EBDA - bailing!
[ 0.000000] Memory: 2003252k/2054848k available (4857k kernel code, 460k absent, 51136k reserved, 6210k data, 1096k init)
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] WARNING: at /home/rostedt/work/git/linux-trace.git/init/main.c:543 start_kernel+0x21e/0x415()
[ 0.000000] Hardware name: To Be Filled By O.E.M.
[ 0.000000] Interrupts were enabled *very* early, fixing it
[ 0.000000] Modules linked in:
[ 0.000000] Pid: 0, comm: swapper/0 Not tainted 3.8.0-test+ #286
[ 0.000000] Call Trace:
[ 0.000000] [<ffffffff81037b79>] warn_slowpath_common+0x83/0x9b
[ 0.000000] [<ffffffff81037c34>] warn_slowpath_fmt+0x46/0x48
[ 0.000000] [<ffffffff81ae4a39>] start_kernel+0x21e/0x415
[ 0.000000] [<ffffffff81ae4623>] ? repair_env_string+0x56/0x56
[ 0.000000] [<ffffffff81ae4312>] x86_64_start_reservations+0x10e/0x112
[ 0.000000] [<ffffffff81ae4120>] ? early_idt_handlers+0x120/0x120
[ 0.000000] [<ffffffff81ae4418>] x86_64_start_kernel+0x102/0x111
[ 0.000000] ---[ end trace 007d8b0491b4f5d8 ]---
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[ 0.000000] NR_IRQS:4352 nr_irqs:712 16
[ 0.000000] Console: colour VGA+ 80x25
[ 0.000000] console [ttyS0] enabled, bootconsole disabled
Do you see it?
The original version of this patch just slapped a WARN_ON() in there and
kept the printk(). Ard van Breemen suggested using the WARN() interface,
which makes the code a bit cleaner.
Also, while examining other warnings in init/main.c, I found two other
locations that deserve a bloody murder scream if their conditions are hit,
and updated them accordingly.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Cc: Ard van Breemen <ard@telegraafnet.nl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
We observed this problem has been occurring since 2.6.30 with
fs/binfmt_elf.c: create_elf_tables()->get_random_bytes(), introduced by f06295b44c296c8f ("ELF: implement AT_RANDOM for glibc PRNG seeding").
/*
* Generate 16 random bytes for userspace PRNG seeding.
*/
get_random_bytes(k_rand_bytes, sizeof(k_rand_bytes));
The patch introduces a wrapper around get_random_int() which has lower
overhead than calling get_random_bytes() directly.
With this patch applied:
$ cat /proc/sys/kernel/random/entropy_avail
2731
$ cat /proc/sys/kernel/random/entropy_avail
2802
$ cat /proc/sys/kernel/random/entropy_avail
2878
Analyzed by John Sobecki.
Signed-off-by: Jie Liu <jeff.liu@oracle.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Andreas Dilger <aedilger@gmail.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Arnd Bergmann <arnn@arndb.de> Cc: John Sobecki <john.sobecki@oracle.com> Cc: James Morris <james.l.morris@oracle.com> Cc: Jakub Jelinek <jakub@redhat.com> Cc: Ted Ts'o <tytso@mit.edu> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Kees Cook <keescook@chromium.org> Cc: Ulrich Drepper <drepper@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Josh Triplett [Tue, 26 Mar 2013 23:25:08 +0000 (10:25 +1100)]
fs: make binfmt support for #! scripts modular and removable
Add a new configuration option CONFIG_BINFMT_SCRIPT to configure support
for interpreted scripts starting with "#!"; allow compiling out that
support, or building it as a module. Embedded systems running exclusively
compiled binaries could leave this support out, and systems that don't
need scripts before mounting the root filesystem can build this as a
module.
Signed-off-by: Josh Triplett <josh@joshtriplett.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Eric Wong [Tue, 26 Mar 2013 23:25:08 +0000 (10:25 +1100)]
epoll: cleanup: hoist out f_op->poll calls
This reduces the amount of code inside the ready list iteration loops for
better readability IMHO.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Cc: Davide Libenzi <davidel@xmailserver.org> Cc: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Eric Wong [Tue, 26 Mar 2013 23:25:08 +0000 (10:25 +1100)]
epoll: lock ep->mtx in ep_free to silence lockdep
Technically we do not need to hold ep->mtx during ep_free since we are
certain there are no other users of ep at that point. However, lockdep
complains with a "suspicious rcu_dereference_check() usage!" message; so
lock the mutex before ep_remove to silence the warning.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Arve Hjønnevåg <arve@android.com> Cc: Davide Libenzi <davidel@xmailserver.org> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: NeilBrown <neilb@suse.de>, Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Eric Wong [Tue, 26 Mar 2013 23:25:08 +0000 (10:25 +1100)]
epoll: fix suspicious RCU usage in ep_poll_callback
The commit "epoll: use RCU to protect wakeup_source in epitem"
introduced the ep_pm_stay_awake_rcu function for ep_poll_callback
use, but I left it unused on accident. ep->mtx cannot be held in
ep_poll_callback, so RCU should be used here.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Paton J. Lewis [Tue, 26 Mar 2013 23:25:07 +0000 (10:25 +1100)]
epoll: support for disabling items, and a self-test app
It is not currently possible to reliably delete epoll items when using the
same epoll set from multiple threads. After calling epoll_ctl with
EPOLL_CTL_DEL, another thread might still be executing code related to an
event for that epoll item (in response to epoll_wait). Therefore the
deleting thread does not know when it is safe to delete resources
pertaining to the associated epoll item because another thread might be
using those resources.
The deleting thread could wait an arbitrary amount of time after calling
epoll_ctl with EPOLL_CTL_DEL and before deleting the item, but this is
inefficient and could result in the destruction of resources before
another thread is done handling an event returned by epoll_wait.
This patch enhances epoll_ctl to support EPOLL_CTL_DISABLE, which disables
an epoll item. If epoll_ctl returns -EBUSY in this case, then another
thread may handling a return from epoll_wait for this item. Otherwise if
epoll_ctl returns 0, then it is safe to delete the epoll item. This
allows multiple threads to use a mutex to determine when it is safe to
delete an epoll item and its associated resources, which allows epoll
items to be deleted both efficiently and without error in a multi-threaded
environment. Note that EPOLL_CTL_DISABLE is only useful in conjunction
with EPOLLONESHOT, and using EPOLL_CTL_DISABLE on an epoll item without
EPOLLONESHOT returns -EINVAL.
This patch also adds a new test_epoll self-test program to both
demonstrate the need for this feature and test it.
Signed-off-by: Paton J. Lewis <palewis@adobe.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Jason Baron <jbaron@redhat.com> Cc: Paul Holland <pholland@adobe.com> Cc: Davide Libenzi <davidel@xmailserver.org> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Eric Wong [Tue, 26 Mar 2013 23:25:06 +0000 (10:25 +1100)]
epoll: comment + BUILD_BUG_ON to prevent epitem bloat
This will prevent us from accidentally introducing a memory bloat
regression here in the future.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Cc: Davide Libenzi <davidel@xmailserver.org>, Cc: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
projects / karo-tx-linux.git / log