linux-toradex.git, branch v3.10.37

Linux 3.10.37

2014-04-14T13:42:31+00:00

cpufreq: Fix timer/workqueue corruption due to double queueing

2014-04-14T13:42:19+00:00

commit 3617f2ca6d0eba48114308532945a7f1577816a4 upstream.

When a CPU is hot removed we'll cancel all the delayed work items
via gov_cancel_work(). Normally this will just cancels a delayed
timer on each CPU that the policy is managing and the work won't
run, but if the work is already running the workqueue code will
wait for the work to finish before continuing to prevent the
work items from re-queuing themselves like they normally do. This
scheme will work most of the time, except for the case where the
work function determines that it should adjust the delay for all
other CPUs that the policy is managing. If this scenario occurs,
the canceling CPU will cancel its own work but queue up the other
CPUs works to run. For example:

 CPU0                                        CPU1
 ----                                        ----
 cpu_down()
  ...
  __cpufreq_remove_dev()
   cpufreq_governor_dbs()
    case CPUFREQ_GOV_STOP:
     gov_cancel_work(dbs_data, policy);
      cpu0 work is canceled
       timer is canceled
       cpu1 work is canceled                    
                                od_dbs_timer()
                                                 gov_queue_work(*, *, true);
 						  cpu0 work queued
 						  cpu1 work queued
						  cpu2 work queued
						  ...
       cpu1 work is canceled
       cpu2 work is canceled
       ...

At the end of the GOV_STOP case cpu0 still has a work queued to
run although the code is expecting all of the works to be
canceled. __cpufreq_remove_dev() will then proceed to
re-initialize all the other CPUs works except for the CPU that is
going down. The CPUFREQ_GOV_START case in cpufreq_governor_dbs()
will trample over the queued work and debugobjects will spit out
a warning:

WARNING: at lib/debugobjects.c:260 debug_print_object+0x94/0xbc()
ODEBUG: init active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x10
Modules linked in:
CPU: 0 PID: 1491 Comm: sh Tainted: G        W    3.10.0 #19
[] (unwind_backtrace+0x0/0x11c) from [] (show_stack+0x10/0x14)
[] (show_stack+0x10/0x14) from [] (warn_slowpath_common+0x4c/0x6c)
[] (warn_slowpath_common+0x4c/0x6c) from [] (warn_slowpath_fmt+0x2c/0x3c)
[] (warn_slowpath_fmt+0x2c/0x3c) from [] (debug_print_object+0x94/0xbc)
[] (debug_print_object+0x94/0xbc) from [] (__debug_object_init+0x2d0/0x340)
[] (__debug_object_init+0x2d0/0x340) from [] (init_timer_key+0x14/0xb0)
[] (init_timer_key+0x14/0xb0) from [] (cpufreq_governor_dbs+0x3e8/0x5f8)
[] (cpufreq_governor_dbs+0x3e8/0x5f8) from [] (__cpufreq_governor+0xdc/0x1a4)
[] (__cpufreq_governor+0xdc/0x1a4) from [] (__cpufreq_remove_dev.isra.10+0x3b4/0x434)
[] (__cpufreq_remove_dev.isra.10+0x3b4/0x434) from [] (cpufreq_cpu_callback+0x60/0x80)
[] (cpufreq_cpu_callback+0x60/0x80) from [] (notifier_call_chain+0x38/0x68)
[] (notifier_call_chain+0x38/0x68) from [] (__cpu_notify+0x28/0x40)
[] (__cpu_notify+0x28/0x40) from [] (_cpu_down+0x7c/0x2c0)
[] (_cpu_down+0x7c/0x2c0) from [] (cpu_down+0x24/0x40)
[] (cpu_down+0x24/0x40) from [] (store_online+0x2c/0x74)
[] (store_online+0x2c/0x74) from [] (dev_attr_store+0x18/0x24)
[] (dev_attr_store+0x18/0x24) from [] (sysfs_write_file+0x100/0x148)
[] (sysfs_write_file+0x100/0x148) from [] (vfs_write+0xcc/0x174)
[] (vfs_write+0xcc/0x174) from [] (SyS_write+0x38/0x64)
[] (SyS_write+0x38/0x64) from [] (ret_fast_syscall+0x0/0x30)

Signed-off-by: Stephen Boyd 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Cc: Krzysztof Kozlowski 
Signed-off-by: Greg Kroah-Hartman

cpufreq: Fix governor start/stop race condition

2014-04-14T13:42:19+00:00

commit 95731ebb114c5f0c028459388560fc2a72fe5049 upstream.

Cpufreq governors' stop and start operations should be carried out
in sequence.  Otherwise, there will be unexpected behavior, like in
the example below.

Suppose there are 4 CPUs and policy->cpu=CPU0, CPU1/2/3 are linked
to CPU0.  The normal sequence is:

 1) Current governor is userspace.  An application tries to set the
    governor to ondemand.  It will call __cpufreq_set_policy() in
    which it will stop the userspace governor and then start the
    ondemand governor.

 2) Current governor is userspace.  The online of CPU3 runs on CPU0.
    It will call cpufreq_add_policy_cpu() in which it will first
    stop the userspace governor, and then start it again.

If the sequence of the above two cases interleaves, it becomes:

 1) Application stops userspace governor
 2)                                  Hotplug stops userspace governor

which is a problem, because the governor shouldn't be stopped twice
in a row.  What happens next is:

 3) Application starts ondemand governor
 4)                                  Hotplug starts a governor

In step 4, the hotplug is supposed to start the userspace governor,
but now the governor has been changed by the application to ondemand,
so the ondemand governor is started once again, which is incorrect.

The solution is to prevent policy governors from being stopped
multiple times in a row.  A governor should only be stopped once for
one policy.  After it has been stopped, no more governor stop
operations should be executed.

Also add a mutex to serialize governor operations.

[rjw: Changelog.  And you owe me a beverage of my choice.]
Signed-off-by: Xiaoguang Chen 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Cc: Krzysztof Kozlowski 
Signed-off-by: Greg Kroah-Hartman

crypto: ghash-clmulni-intel - use C implementation for setkey()

2014-04-14T13:42:19+00:00

commit 8ceee72808d1ae3fb191284afc2257a2be964725 upstream.

The GHASH setkey() function uses SSE registers but fails to call
kernel_fpu_begin()/kernel_fpu_end(). Instead of adding these calls, and
then having to deal with the restriction that they cannot be called from
interrupt context, move the setkey() implementation to the C domain.

Note that setkey() does not use any particular SSE features and is not
expected to become a performance bottleneck.

Signed-off-by: Ard Biesheuvel 
Acked-by: H. Peter Anvin 
Fixes: 0e1227d356e9b (crypto: ghash - Add PCLMULQDQ accelerated implementation)
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

m68k: Skip futex_atomic_cmpxchg_inatomic() test

2014-04-14T13:42:19+00:00

commit e571c58f313d35c56e0018470e3375ddd1fd320e upstream.

Skip the futex_atomic_cmpxchg_inatomic() test in futex_init(). It causes a
fatal exception on 68030 (and presumably 68020 also).

Signed-off-by: Finn Thain 
Acked-by: Geert Uytterhoeven 
Link: http://lkml.kernel.org/r/alpine.LNX.2.00.1403061006440.5525@nippy.intranet
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

futex: Allow architectures to skip futex_atomic_cmpxchg_inatomic() test

2014-04-14T13:42:19+00:00

commit 03b8c7b623c80af264c4c8d6111e5c6289933666 upstream.

If an architecture has futex_atomic_cmpxchg_inatomic() implemented and there
is no runtime check necessary, allow to skip the test within futex_init().

This allows to get rid of some code which would always give the same result,
and also allows the compiler to optimize a couple of if statements away.

Signed-off-by: Heiko Carstens 
Cc: Finn Thain 
Cc: Geert Uytterhoeven 
Link: http://lkml.kernel.org/r/20140302120947.GA3641@osiris
Signed-off-by: Thomas Gleixner 
[geert: Backported to v3.10..v3.13]
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Greg Kroah-Hartman

ARC: [nsimosci] Unbork console

2014-04-14T13:42:19+00:00

commit 61fb4bfc010b0d2940f7fd87acbce6a0f03217cb upstream.

Despite the switch to right UART driver (prev patch), serial console
still doesn't work due to missing CONFIG_SERIAL_OF_PLATFORM

Also fix the default cmdline in DT to not refer to out-of-tree
ARC framebuffer driver for console.

Signed-off-by: Vineet Gupta 
Cc: Francois Bedard 
Signed-off-by: Greg Kroah-Hartman

ARC: [nsimosci] Change .dts to use generic 8250 UART

2014-04-14T13:42:18+00:00

commit 6eda477b3c54b8236868c8784e5e042ff14244f0 upstream.

The Synopsys APB DW UART has a couple of special features that are not
in the System C model. In 3.8, the 8250_dw driver didn't really use these
features, but from 3.9 onwards, the 8250_dw driver has become incompatible
with our model.

Signed-off-by: Mischa Jonker 
Signed-off-by: Vineet Gupta 
Cc: Francois Bedard 
Signed-off-by: Greg Kroah-Hartman

rds: prevent dereference of a NULL device in rds_iw_laddr_check

2014-04-14T13:42:18+00:00

[ Upstream commit bf39b4247b8799935ea91d90db250ab608a58e50 ]

Binding might result in a NULL device which is later dereferenced
without checking.

Signed-off-by: Sasha Levin 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

isdnloop: several buffer overflows

2014-04-14T13:42:18+00:00

[ Upstream commit 7563487cbf865284dcd35e9ef5a95380da046737 ]

There are three buffer overflows addressed in this patch.

1) In isdnloop_fake_err() we add an 'E' to a 60 character string and
then copy it into a 60 character buffer.  I have made the destination
buffer 64 characters and I'm changed the sprintf() to a snprintf().

2) In isdnloop_parse_cmd(), p points to a 6 characters into a 60
character buffer so we have 54 characters.  The ->eazlist[] is 11
characters long.  I have modified the code to return if the source
buffer is too long.

3) In isdnloop_command() the cbuf[] array was 60 characters long but the
max length of the string then can be up to 79 characters.  I made the
cbuf array 80 characters long and changed the sprintf() to snprintf().
I also removed the temporary "dial" buffer and changed it to use "p"
directly.

Unfortunately, we pass the "cbuf" string from isdnloop_command() to
isdnloop_writecmd() which truncates anything over 60 characters to make
it fit in card->omsg[].  (It can accept values up to 255 characters so
long as there is a '\n' character every 60 characters).  For now I have
just fixed the memory corruption bug and left the other problems in this
driver alone.

Signed-off-by: Dan Carpenter 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman