[PATCH 3.14 46/77] tracing/sched: Check preempt_count() for current when reading task->state

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: "Steven Rostedt (Red Hat)" 

commit aee4e5f3d3abb7a2239dd02f6d8fb173413fd02f upstream.

When recording the state of a task for the sched_switch tracepoint a check of
task_preempt_count() is performed to see if PREEMPT_ACTIVE is set. This is
because, technically, a task being preempted is really in the TASK_RUNNING
state, and that is what should be recorded when tracing a sched_switch,
even if the task put itself into another state (it hasn't scheduled out
in that state yet).

But with the change to use per_cpu preempt counts, the
task_thread_info(p)->preempt_count is no longer used, and instead
task_preempt_count(p) is used.

The problem is that this does not use the current preempt count but a stale
one from a previous sched_switch. The task_preempt_count(p) uses
saved_preempt_count and not preempt_count(). But for tracing sched_switch,
if p is current, we really want preempt_count().

I hit this bug when I was tracing sleep and the call from do_nanosleep()
scheduled out in the "RUNNING" state.

   sleep-4290  [000] 537272.259992: sched_switch: sleep:4290 
[120] R ==> swapper/0:0 [120]
   sleep-4290  [000] 537272.260015: kernel_stack: 
=> __schedule (8150864a)
=> schedule (815089f8)
=> do_nanosleep (8150b76c)
=> hrtimer_nanosleep (8108d66b)
=> SyS_nanosleep (8108d750)
=> return_to_handler (8150e8e5)
=> tracesys_phase2 (8150c844)

After a bit of hair pulling, I found that the state was really
TASK_INTERRUPTIBLE, but the saved_preempt_count had an old PREEMPT_ACTIVE
set and caused the sched_switch tracepoint to show it as RUNNING.

Link: http://lkml.kernel.org/r/20141210174428.3cb75...@gandalf.local.home

Acked-by: Ingo Molnar 
Cc: Peter Zijlstra 
Fixes: 01028747559a "sched: Create more preempt_count accessors"
Signed-off-by: Steven Rostedt 
Signed-off-by: Greg Kroah-Hartman 

---
 include/trace/events/sched.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -100,7 +100,7 @@ static inline long __trace_sched_switch_
/*
 * For all intents and purposes a preempted task is a running task.
 */
-   if (task_preempt_count(p) & PREEMPT_ACTIVE)
+   if (preempt_count() & PREEMPT_ACTIVE)
state = TASK_RUNNING | TASK_STATE_MAX;
 #endif
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 50/77] fs: nfsd: Fix signedness bug in compare_blob

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Rasmus Villemoes 

commit ef17af2a817db97d42dd2ec0a425231748e23dbc upstream.

Bugs similar to the one in acbbe6fbb240 (kcmp: fix standard comparison
bug) are in rich supply.

In this variant, the problem is that struct xdr_netobj::len has type
unsigned int, so the expression o1->len - o2->len _also_ has type
unsigned int; it has completely well-defined semantics, and the result
is some non-negative integer, which is always representable in a long
long. But this means that if the conditional triggers, we are
guaranteed to return a positive value from compare_blob.

In this case it could be fixed by

-   res = o1->len - o2->len;
+   res = (long long)o1->len - (long long)o2->len;

but I'd rather eliminate the usually broken 'return a - b;' idiom.

Reviewed-by: Jeff Layton 
Signed-off-by: Rasmus Villemoes 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/nfsd/nfs4state.c |   15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -1209,15 +1209,14 @@ static int copy_cred(struct svc_cred *ta
return 0;
 }
 
-static long long
+static int
 compare_blob(const struct xdr_netobj *o1, const struct xdr_netobj *o2)
 {
-   long long res;
-
-   res = o1->len - o2->len;
-   if (res)
-   return res;
-   return (long long)memcmp(o1->data, o2->data, o1->len);
+   if (o1->len < o2->len)
+   return -1;
+   if (o1->len > o2->len)
+   return 1;
+   return memcmp(o1->data, o2->data, o1->len);
 }
 
 static int same_name(const char *n1, const char *n2)
@@ -1401,7 +1400,7 @@ add_clp_to_name_tree(struct nfs4_client
 static struct nfs4_client *
 find_clp_in_name_tree(struct xdr_netobj *name, struct rb_root *root)
 {
-   long long cmp;
+   int cmp;
struct rb_node *node = root->rb_node;
struct nfs4_client *clp;
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 18/77] powerpc: Fix bad NULL pointer check in udbg_uart_getc_poll()

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Anton Blanchard 

commit cd32e2dcc9de6c27ecbbfc0e2079fb64b42bad5f upstream.

We have some code in udbg_uart_getc_poll() that tries to protect
against a NULL udbg_uart_in, but gets it all wrong.

Found with the LLVM static analyzer (scan-build).

Fixes: 309257484cc1 ("powerpc: Cleanup udbg_16550 and add support for LPC 
PIO-only UARTs")
Signed-off-by: Anton Blanchard 
[mpe: Add some newlines for readability while we're here]
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/powerpc/kernel/udbg_16550.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/arch/powerpc/kernel/udbg_16550.c
+++ b/arch/powerpc/kernel/udbg_16550.c
@@ -69,8 +69,12 @@ static void udbg_uart_putc(char c)
 
 static int udbg_uart_getc_poll(void)
 {
-   if (!udbg_uart_in || !(udbg_uart_in(UART_LSR) & LSR_DR))
+   if (!udbg_uart_in)
+   return -1;
+
+   if (!(udbg_uart_in(UART_LSR) & LSR_DR))
return udbg_uart_in(UART_RBR);
+
return -1;
 }
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 20/77] powerpc/powernv: Switch off MMU before entering nap/sleep/rvwinkle mode

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Paul Mackerras 

commit 8117ac6a6c2fa0f847ff6a21a1f32c8d2c8501d0 upstream.

Currently, when going idle, we set the flag indicating that we are in
nap mode (paca->kvm_hstate.hwthread_state) and then execute the nap
(or sleep or rvwinkle) instruction, all with the MMU on.  This is bad
for two reasons: (a) the architecture specifies that those instructions
must be executed with the MMU off, and in fact with only the SF, HV, ME
and possibly RI bits set, and (b) this introduces a race, because as
soon as we set the flag, another thread can switch the MMU to a guest
context.  If the race is lost, this thread will typically start looping
on relocation-on ISIs at 0xc...4400.

This fixes it by setting the MSR as required by the architecture before
setting the flag or executing the nap/sleep/rvwinkle instruction.

[ shre...@linux.vnet.ibm.com: Edited to handle LE ]
Signed-off-by: Paul Mackerras 
Signed-off-by: Shreyas B. Prabhu 
Cc: Benjamin Herrenschmidt 
Cc: Michael Ellerman 
Cc: linuxppc-...@lists.ozlabs.org
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/powerpc/include/asm/reg.h|2 ++
 arch/powerpc/kernel/idle_power7.S |   18 +-
 2 files changed, 19 insertions(+), 1 deletion(-)

--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -118,8 +118,10 @@
 #define __MSR  (MSR_ME | MSR_RI | MSR_IR | MSR_DR | MSR_ISF |MSR_HV)
 #ifdef __BIG_ENDIAN__
 #define MSR_   __MSR
+#define MSR_IDLE   (MSR_ME | MSR_SF | MSR_HV)
 #else
 #define MSR_   (__MSR | MSR_LE)
+#define MSR_IDLE   (MSR_ME | MSR_SF | MSR_HV | MSR_LE)
 #endif
 #define MSR_KERNEL (MSR_ | MSR_64BIT)
 #define MSR_USER32 (MSR_ | MSR_PR | MSR_EE)
--- a/arch/powerpc/kernel/idle_power7.S
+++ b/arch/powerpc/kernel/idle_power7.S
@@ -84,7 +84,23 @@ _GLOBAL(power7_nap)
std r9,_MSR(r1)
std r1,PACAR1(r13)
 
-_GLOBAL(power7_enter_nap_mode)
+   /*
+* Go to real mode to do the nap, as required by the architecture.
+* Also, we need to be in real mode before setting hwthread_state,
+* because as soon as we do that, another thread can switch
+* the MMU context to the guest.
+*/
+   LOAD_REG_IMMEDIATE(r5, MSR_IDLE)
+   li  r6, MSR_RI
+   andcr6, r9, r6
+   LOAD_REG_ADDR(r7, power7_enter_nap_mode)
+   mtmsrd  r6, 1   /* clear RI before setting SRR0/1 */
+   mtspr   SPRN_SRR0, r7
+   mtspr   SPRN_SRR1, r5
+   rfid
+
+   .globl  power7_enter_nap_mode
+power7_enter_nap_mode:
 #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
/* Tell KVM we're napping */
li  r4,KVM_HWTHREAD_IN_NAP


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 53/77] ceph: fix null pointer dereference in discard_cap_releases()

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: "Yan, Zheng" 

commit 00bd8edb861eb41d274938cfc0338999d9c593a3 upstream.

send_mds_reconnect() may call discard_cap_releases() after all
release messages have been dropped by cleanup_cap_releases()

Signed-off-by: Yan, Zheng 
Reviewed-by: Sage Weil 
Cc: Markus Blank-Burian 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/ceph/mds_client.c |   21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

--- a/fs/ceph/mds_client.c
+++ b/fs/ceph/mds_client.c
@@ -1461,15 +1461,18 @@ static void discard_cap_releases(struct
 
dout("discard_cap_releases mds%d\n", session->s_mds);
 
-   /* zero out the in-progress message */
-   msg = list_first_entry(>s_cap_releases,
-  struct ceph_msg, list_head);
-   head = msg->front.iov_base;
-   num = le32_to_cpu(head->num);
-   dout("discard_cap_releases mds%d %p %u\n", session->s_mds, msg, num);
-   head->num = cpu_to_le32(0);
-   msg->front.iov_len = sizeof(*head);
-   session->s_num_cap_releases += num;
+   if (!list_empty(>s_cap_releases)) {
+   /* zero out the in-progress message */
+   msg = list_first_entry(>s_cap_releases,
+   struct ceph_msg, list_head);
+   head = msg->front.iov_base;
+   num = le32_to_cpu(head->num);
+   dout("discard_cap_releases mds%d %p %u\n",
+session->s_mds, msg, num);
+   head->num = cpu_to_le32(0);
+   msg->front.iov_len = sizeof(*head);
+   session->s_num_cap_releases += num;
+   }
 
/* requeue completed messages */
while (!list_empty(>s_cap_releases_done)) {


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 14/77] ath5k: fix hardware queue index assignment

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Felix Fietkau 

commit 9e4982f6a51a2442f1bb588fee42521b44b4531c upstream.

Like with ath9k, ath5k queues also need to be ordered by priority.
queue_info->tqi_subtype already contains the correct index, so use it
instead of relying on the order of ath5k_hw_setup_tx_queue calls.

Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/ath/ath5k/qcu.c |8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

--- a/drivers/net/wireless/ath/ath5k/qcu.c
+++ b/drivers/net/wireless/ath/ath5k/qcu.c
@@ -225,13 +225,7 @@ ath5k_hw_setup_tx_queue(struct ath5k_hw
} else {
switch (queue_type) {
case AR5K_TX_QUEUE_DATA:
-   for (queue = AR5K_TX_QUEUE_ID_DATA_MIN;
-   ah->ah_txq[queue].tqi_type !=
-   AR5K_TX_QUEUE_INACTIVE; queue++) {
-
-   if (queue > AR5K_TX_QUEUE_ID_DATA_MAX)
-   return -EINVAL;
-   }
+   queue = queue_info->tqi_subtype;
break;
case AR5K_TX_QUEUE_UAPSD:
queue = AR5K_TX_QUEUE_ID_UAPSD;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 23/77] pstore-ram: Allow optional mapping with pgprot_noncached

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Tony Lindgren 

commit 027bc8b08242c59e19356b4b2c189f2d849ab660 upstream.

On some ARMs the memory can be mapped pgprot_noncached() and still
be working for atomic operations. As pointed out by Colin Cross
, in some cases you do want to use
pgprot_noncached() if the SoC supports it to see a debug printk
just before a write hanging the system.

On ARMs, the atomic operations on strongly ordered memory are
implementation defined. So let's provide an optional kernel parameter
for configuring pgprot_noncached(), and use pgprot_writecombine() by
default.

Cc: Arnd Bergmann 
Cc: Rob Herring 
Cc: Randy Dunlap 
Cc: Anton Vorontsov 
Cc: Colin Cross 
Cc: Olof Johansson 
Cc: Russell King 
Acked-by: Kees Cook 
Signed-off-by: Tony Lindgren 
Signed-off-by: Tony Luck 
Signed-off-by: Greg Kroah-Hartman 

---
 Documentation/ramoops.txt  |   13 +++--
 fs/pstore/ram.c|   13 +++--
 fs/pstore/ram_core.c   |   31 ++-
 include/linux/pstore_ram.h |4 +++-
 4 files changed, 47 insertions(+), 14 deletions(-)

--- a/Documentation/ramoops.txt
+++ b/Documentation/ramoops.txt
@@ -14,11 +14,19 @@ survive after a restart.
 
 1. Ramoops concepts
 
-Ramoops uses a predefined memory area to store the dump. The start and size of
-the memory area are set using two variables:
+Ramoops uses a predefined memory area to store the dump. The start and size
+and type of the memory area are set using three variables:
   * "mem_address" for the start
   * "mem_size" for the size. The memory size will be rounded down to a
   power of two.
+  * "mem_type" to specifiy if the memory type (default is pgprot_writecombine).
+
+Typically the default value of mem_type=0 should be used as that sets the 
pstore
+mapping to pgprot_writecombine. Setting mem_type=1 attempts to use
+pgprot_noncached, which only works on some platforms. This is because pstore
+depends on atomic operations. At least on ARM, pgprot_noncached causes the
+memory to be mapped strongly ordered, and atomic operations on strongly ordered
+memory are implementation defined, and won't work on many ARMs such as omaps.
 
 The memory area is divided into "record_size" chunks (also rounded down to
 power of two) and each oops/panic writes a "record_size" chunk of
@@ -55,6 +63,7 @@ Setting the ramoops parameters can be do
 static struct ramoops_platform_data ramoops_data = {
 .mem_size   = <...>,
 .mem_address= <...>,
+.mem_type   = <...>,
 .record_size= <...>,
 .dump_oops  = <...>,
 .ecc= <...>,
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -61,6 +61,11 @@ module_param(mem_size, ulong, 0400);
 MODULE_PARM_DESC(mem_size,
"size of reserved RAM used to store oops/panic logs");
 
+static unsigned int mem_type;
+module_param(mem_type, uint, 0600);
+MODULE_PARM_DESC(mem_type,
+   "set to 1 to try to use unbuffered memory (default 0)");
+
 static int dump_oops = 1;
 module_param(dump_oops, int, 0600);
 MODULE_PARM_DESC(dump_oops,
@@ -79,6 +84,7 @@ struct ramoops_context {
struct persistent_ram_zone *fprz;
phys_addr_t phys_addr;
unsigned long size;
+   unsigned int memtype;
size_t record_size;
size_t console_size;
size_t ftrace_size;
@@ -353,7 +359,8 @@ static int ramoops_init_przs(struct devi
size_t sz = cxt->record_size;
 
cxt->przs[i] = persistent_ram_new(*paddr, sz, 0,
- >ecc_info);
+ >ecc_info,
+ cxt->memtype);
if (IS_ERR(cxt->przs[i])) {
err = PTR_ERR(cxt->przs[i]);
dev_err(dev, "failed to request mem region 
(0x%zx@0x%llx): %d\n",
@@ -383,7 +390,7 @@ static int ramoops_init_prz(struct devic
return -ENOMEM;
}
 
-   *prz = persistent_ram_new(*paddr, sz, sig, >ecc_info);
+   *prz = persistent_ram_new(*paddr, sz, sig, >ecc_info, 
cxt->memtype);
if (IS_ERR(*prz)) {
int err = PTR_ERR(*prz);
 
@@ -431,6 +438,7 @@ static int ramoops_probe(struct platform
cxt->dump_read_cnt = 0;
cxt->size = pdata->mem_size;
cxt->phys_addr = pdata->mem_address;
+   cxt->memtype = pdata->mem_type;
cxt->record_size = pdata->record_size;
cxt->console_size = pdata->console_size;
cxt->ftrace_size = pdata->ftrace_size;
@@ -561,6 +569,7 @@ static void ramoops_register_dummy(void)
 
dummy_data->mem_size = mem_size;
dummy_data->mem_address = mem_address;
+   dummy_data->mem_type = 0;
dummy_data->record_size = record_size;
dummy_data->console_size = ramoops_console_size;

[PATCH 3.14 62/77] Revert "ARM: 7830/1: delay: dont bother reporting bogomips in /proc/cpuinfo"

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Pavel Machek 

commit 4bf9636c39ac70da091d5a2e28d3448eaa7f115c upstream.

Commit 9fc2105aeaaf ("ARM: 7830/1: delay: don't bother reporting
bogomips in /proc/cpuinfo") breaks audio in python, and probably
elsewhere, with message

  FATAL: cannot locate cpu MHz in /proc/cpuinfo

I'm not the first one to hit it, see for example

  
https://theredblacktree.wordpress.com/2014/08/10/fatal-cannot-locate-cpu-mhz-in-proccpuinfo/
  
https://devtalk.nvidia.com/default/topic/765800/workaround-for-fatal-cannot-locate-cpu-mhz-in-proc-cpuinf/?offset=1

Reading original changelog, I have to say "Stop breaking working setups.
You know who you are!".

Signed-off-by: Pavel Machek 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/kernel/setup.c |9 +
 arch/arm/kernel/smp.c   |   13 +++--
 2 files changed, 20 insertions(+), 2 deletions(-)

--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -1021,6 +1021,15 @@ static int c_show(struct seq_file *m, vo
seq_printf(m, "model name\t: %s rev %d (%s)\n",
   cpu_name, cpuid & 15, elf_platform);
 
+#if defined(CONFIG_SMP)
+   seq_printf(m, "BogoMIPS\t: %lu.%02lu\n",
+  per_cpu(cpu_data, i).loops_per_jiffy / (50UL/HZ),
+  (per_cpu(cpu_data, i).loops_per_jiffy / (5000UL/HZ)) 
% 100);
+#else
+   seq_printf(m, "BogoMIPS\t: %lu.%02lu\n",
+  loops_per_jiffy / (50/HZ),
+  (loops_per_jiffy / (5000/HZ)) % 100);
+#endif
/* dump out the processor features */
seq_puts(m, "Features\t: ");
 
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -388,8 +388,17 @@ asmlinkage void secondary_start_kernel(v
 
 void __init smp_cpus_done(unsigned int max_cpus)
 {
-   printk(KERN_INFO "SMP: Total of %d processors activated.\n",
-  num_online_cpus());
+   int cpu;
+   unsigned long bogosum = 0;
+
+   for_each_online_cpu(cpu)
+   bogosum += per_cpu(cpu_data, cpu).loops_per_jiffy;
+
+   printk(KERN_INFO "SMP: Total of %d processors activated "
+  "(%lu.%02lu BogoMIPS).\n",
+  num_online_cpus(),
+  bogosum / (50/HZ),
+  (bogosum / (5000/HZ)) % 100);
 
hyp_mode_check();
 }


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 22/77] pstore-ram: Fix hangs by using write-combine mappings

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Rob Herring 

commit 7ae9cb81933515dc7db1aa3c47ef7653717e3090 upstream.

Currently trying to use pstore on at least ARMs can hang as we're
mapping the peristent RAM with pgprot_noncached().

On ARMs, pgprot_noncached() will actually make the memory strongly
ordered, and as the atomic operations pstore uses are implementation
defined for strongly ordered memory, they may not work. So basically
atomic operations have undefined behavior on ARM for device or strongly
ordered memory types.

Let's fix the issue by using write-combine variants for mappings. This
corresponds to normal, non-cacheable memory on ARM. For many other
architectures, this change does not change the mapping type as by
default we have:

#define pgprot_writecombine pgprot_noncached

The reason why pgprot_noncached() was originaly used for pstore
is because Colin Cross  had observed lost
debug prints right before a device hanging write operation on some
systems. For the platforms supporting pgprot_noncached(), we can
add a an optional configuration option to support that. But let's
get pstore working first before adding new features.

Cc: Arnd Bergmann 
Cc: Anton Vorontsov 
Cc: Colin Cross 
Cc: Olof Johansson 
Cc: linux-kernel@vger.kernel.org
Acked-by: Kees Cook 
Signed-off-by: Rob Herring 
[t...@atomide.com: updated description]
Signed-off-by: Tony Lindgren 
Signed-off-by: Tony Luck 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/pstore/ram_core.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -392,7 +392,7 @@ static void *persistent_ram_vmap(phys_ad
page_start = start - offset_in_page(start);
page_count = DIV_ROUND_UP(size + offset_in_page(start), PAGE_SIZE);
 
-   prot = pgprot_noncached(PAGE_KERNEL);
+   prot = pgprot_writecombine(PAGE_KERNEL);
 
pages = kmalloc(sizeof(struct page *) * page_count, GFP_KERNEL);
if (!pages) {
@@ -422,7 +422,7 @@ static void *persistent_ram_iomap(phys_a
buffer_start_add = buffer_start_add_locked;
buffer_size_add = buffer_size_add_locked;
 
-   return ioremap(start, size);
+   return ioremap_wc(start, size);
 }
 
 static int persistent_ram_buffer_map(phys_addr_t start, phys_addr_t size,


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 66/77] arm64: kernel: refactor the CPU suspend API for retention states

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Lorenzo Pieralisi 

commit 714f59925595b9c2ea9c22b107b340d38e3b3bc9 upstream.

CPU suspend is the standard kernel interface to be used to enter
low-power states on ARM64 systems. Current cpu_suspend implementation
by default assumes that all low power states are losing the CPU context,
so the CPU registers must be saved and cleaned to DRAM upon state
entry. Furthermore, the current cpu_suspend() implementation assumes
that if the CPU suspend back-end method returns when called, this has
to be considered an error regardless of the return code (which can be
successful) since the CPU was not expected to return from a code path that
is different from cpu_resume code path - eg returning from the reset vector.

All in all this means that the current API does not cope well with low-power
states that preserve the CPU context when entered (ie retention states),
since first of all the context is saved for nothing on state entry for
those states and a successful state entry can return as a normal function
return, which is considered an error by the current CPU suspend
implementation.

This patch refactors the cpu_suspend() API so that it can be split in
two separate functionalities. The arm64 cpu_suspend API just provides
a wrapper around CPU suspend operation hook. A new function is
introduced (for architecture code use only) for states that require
context saving upon entry:

__cpu_suspend(unsigned long arg, int (*fn)(unsigned long))

__cpu_suspend() saves the context on function entry and calls the
so called suspend finisher (ie fn) to complete the suspend operation.
The finisher is not expected to return, unless it fails in which case
the error is propagated back to the __cpu_suspend caller.

The API refactoring results in the following pseudo code call sequence for a
suspending CPU, when triggered from a kernel subsystem:

/*
 * int cpu_suspend(unsigned long idx)
 * @idx: idle state index
 */
{
-> cpu_suspend(idx)
|---> CPU operations suspend hook called, if present
|--> if (retention_state)
|--> direct suspend back-end call (eg PSCI suspend)
 else
|--> __cpu_suspend(idx, _end_finisher);
}

By refactoring the cpu_suspend API this way, the CPU operations back-end
has a chance to detect whether idle states require state saving or not
and can call the required suspend operations accordingly either through
simple function call or indirectly through __cpu_suspend() which carries out
state saving and suspend finisher dispatching to complete idle state entry.

Reviewed-by: Catalin Marinas 
Reviewed-by: Hanjun Guo 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm64/include/asm/suspend.h |1 
 arch/arm64/kernel/sleep.S|   47 +++---
 arch/arm64/kernel/suspend.c  |   48 +++
 3 files changed, 64 insertions(+), 32 deletions(-)

--- a/arch/arm64/include/asm/suspend.h
+++ b/arch/arm64/include/asm/suspend.h
@@ -21,6 +21,7 @@ struct sleep_save_sp {
phys_addr_t save_ptr_stash_phys;
 };
 
+extern int __cpu_suspend(unsigned long arg, int (*fn)(unsigned long));
 extern void cpu_resume(void);
 extern int cpu_suspend(unsigned long);
 
--- a/arch/arm64/kernel/sleep.S
+++ b/arch/arm64/kernel/sleep.S
@@ -49,28 +49,39 @@
orr \dst, \dst, \mask   // dst|=(aff3>>rs3)
.endm
 /*
- * Save CPU state for a suspend.  This saves callee registers, and allocates
- * space on the kernel stack to save the CPU specific registers + some
- * other data for resume.
+ * Save CPU state for a suspend and execute the suspend finisher.
+ * On success it will return 0 through cpu_resume - ie through a CPU
+ * soft/hard reboot from the reset vector.
+ * On failure it returns the suspend finisher return value or force
+ * -EOPNOTSUPP if the finisher erroneously returns 0 (the suspend finisher
+ * is not allowed to return, if it does this must be considered failure).
+ * It saves callee registers, and allocates space on the kernel stack
+ * to save the CPU specific registers + some other data for resume.
  *
  *  x0 = suspend finisher argument
+ *  x1 = suspend finisher function pointer
  */
-ENTRY(__cpu_suspend)
+ENTRY(__cpu_suspend_enter)
stp x29, lr, [sp, #-96]!
stp x19, x20, [sp,#16]
stp x21, x22, [sp,#32]
stp x23, x24, [sp,#48]
stp x25, x26, [sp,#64]
stp x27, x28, [sp,#80]
+   /*
+* Stash suspend finisher and its argument in x20 and x19
+*/
+   mov x19, x0
+   mov x20, x1
mov x2, sp
sub sp, sp, #CPU_SUSPEND_SZ // allocate cpu_suspend_ctx
-   mov x1, sp
+   mov x0, sp
/*
-* x1 now points to struct cpu_suspend_ctx 

[PATCH 3.14 67/77] arm64: Move cpu_resume into the text section

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Laura Abbott 

commit c3684fbb446501b48dec6677a6a9f61c215053de upstream.

The function cpu_resume currently lives in the .data section.
There's no reason for it to be there since we can use relative
instructions without a problem. Move a few cpu_resume data
structures out of the assembly file so the .data annotation
can be dropped completely and cpu_resume ends up in the read
only text section.

Reviewed-by: Kees Cook 
Reviewed-by: Mark Rutland 
Reviewed-by: Lorenzo Pieralisi 
Tested-by: Mark Rutland 
Tested-by: Lorenzo Pieralisi 
Tested-by: Kees Cook 
Acked-by: Ard Biesheuvel 
Signed-off-by: Laura Abbott 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm64/kernel/sleep.S   |   36 ++--
 arch/arm64/kernel/suspend.c |4 ++--
 2 files changed, 8 insertions(+), 32 deletions(-)

--- a/arch/arm64/kernel/sleep.S
+++ b/arch/arm64/kernel/sleep.S
@@ -147,14 +147,12 @@ cpu_resume_after_mmu:
ret
 ENDPROC(cpu_resume_after_mmu)
 
-   .data
 ENTRY(cpu_resume)
bl  el2_setup   // if in EL2 drop to EL1 cleanly
 #ifdef CONFIG_SMP
mrs x1, mpidr_el1
-   adr x4, mpidr_hash_ptr
-   ldr x5, [x4]
-   add x8, x4, x5  // x8 = struct mpidr_hash phys address
+   adrpx8, mpidr_hash
+   add x8, x8, #:lo12:mpidr_hash // x8 = struct mpidr_hash phys address
 /* retrieve mpidr_hash members to compute the hash */
ldr x2, [x8, #MPIDR_HASH_MASK]
ldp w3, w4, [x8, #MPIDR_HASH_SHIFTS]
@@ -164,14 +162,15 @@ ENTRY(cpu_resume)
 #else
mov x7, xzr
 #endif
-   adr x0, sleep_save_sp
+   adrpx0, sleep_save_sp
+   add x0, x0, #:lo12:sleep_save_sp
ldr x0, [x0, #SLEEP_SAVE_SP_PHYS]
ldr x0, [x0, x7, lsl #3]
/* load sp from context */
ldr x2, [x0, #CPU_CTX_SP]
-   adr x1, sleep_idmap_phys
+   adrpx1, sleep_idmap_phys
/* load physical address of identity map page table in x1 */
-   ldr x1, [x1]
+   ldr x1, [x1, #:lo12:sleep_idmap_phys]
mov sp, x2
/*
 * cpu_do_resume expects x0 to contain context physical address
@@ -180,26 +179,3 @@ ENTRY(cpu_resume)
bl  cpu_do_resume   // PC relative jump, MMU off
b   cpu_resume_mmu  // Resume MMU, never returns
 ENDPROC(cpu_resume)
-
-   .align 3
-mpidr_hash_ptr:
-   /*
-* offset of mpidr_hash symbol from current location
-* used to obtain run-time mpidr_hash address with MMU off
- */
-   .quad   mpidr_hash - .
-/*
- * physical address of identity mapped page tables
- */
-   .type   sleep_idmap_phys, #object
-ENTRY(sleep_idmap_phys)
-   .quad   0
-/*
- * struct sleep_save_sp {
- * phys_addr_t *save_ptr_stash;
- * phys_addr_t save_ptr_stash_phys;
- * };
- */
-   .type   sleep_save_sp, #object
-ENTRY(sleep_save_sp)
-   .space  SLEEP_SAVE_SP_SZ// struct sleep_save_sp
--- a/arch/arm64/kernel/suspend.c
+++ b/arch/arm64/kernel/suspend.c
@@ -126,8 +126,8 @@ int __cpu_suspend(unsigned long arg, int
return ret;
 }
 
-extern struct sleep_save_sp sleep_save_sp;
-extern phys_addr_t sleep_idmap_phys;
+struct sleep_save_sp sleep_save_sp;
+phys_addr_t sleep_idmap_phys;
 
 static int __init cpu_suspend_init(void)
 {


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 65/77] arm64: kernel: add missing __init section marker to cpu_suspend_init

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Lorenzo Pieralisi 

commit 18ab7db6b749ac27aac08d572afbbd2f4d937934 upstream.

Suspend init function must be marked as __init, since it is not needed
after the kernel has booted. This patch moves the cpu_suspend_init()
function to the __init section.

Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm64/kernel/suspend.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm64/kernel/suspend.c
+++ b/arch/arm64/kernel/suspend.c
@@ -119,7 +119,7 @@ int cpu_suspend(unsigned long arg)
 extern struct sleep_save_sp sleep_save_sp;
 extern phys_addr_t sleep_idmap_phys;
 
-static int cpu_suspend_init(void)
+static int __init cpu_suspend_init(void)
 {
void *ctx_ptr;
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 70/77] perf/x86/intel/uncore: Make sure only uncore events are collected

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Jiri Olsa 

commit af91568e762d04931dcbdd6bef4655433d8b9418 upstream.

The uncore_collect_events functions assumes that event group
might contain only uncore events which is wrong, because it
might contain any type of events.

This bug leads to uncore framework touching 'not' uncore events,
which could end up all sorts of bugs.

One was triggered by Vince's perf fuzzer, when the uncore code
touched breakpoint event private event space as if it was uncore
event and caused BUG:

   BUG: unable to handle kernel paging request at 82822068
   IP: [] uncore_assign_events+0x188/0x250
   ...

The code in uncore_assign_events() function was looking for
event->hw.idx data while the event was initialized as a
breakpoint with different members in event->hw union.

This patch forces uncore_collect_events() to collect only uncore
events.

Reported-by: Vince Weaver 
Signed-off-by: Jiri Olsa 
Cc: Arnaldo Carvalho de Melo 
Cc: Frederic Weisbecker 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Yan, Zheng 
Link: 
http://lkml.kernel.org/r/1418243031-20367-2-git-send-email-jo...@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/cpu/perf_event_intel_uncore.c |   22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -2886,6 +2886,17 @@ static struct intel_uncore_box *uncore_e
return uncore_pmu_to_box(uncore_event_to_pmu(event), 
smp_processor_id());
 }
 
+/*
+ * Using uncore_pmu_event_init pmu event_init callback
+ * as a detection point for uncore events.
+ */
+static int uncore_pmu_event_init(struct perf_event *event);
+
+static bool is_uncore_event(struct perf_event *event)
+{
+   return event->pmu->event_init == uncore_pmu_event_init;
+}
+
 static int
 uncore_collect_events(struct intel_uncore_box *box, struct perf_event *leader, 
bool dogrp)
 {
@@ -2900,13 +2911,18 @@ uncore_collect_events(struct intel_uncor
return -EINVAL;
 
n = box->n_events;
-   box->event_list[n] = leader;
-   n++;
+
+   if (is_uncore_event(leader)) {
+   box->event_list[n] = leader;
+   n++;
+   }
+
if (!dogrp)
return n;
 
list_for_each_entry(event, >sibling_list, group_entry) {
-   if (event->state <= PERF_EVENT_STATE_OFF)
+   if (!is_uncore_event(event) ||
+   event->state <= PERF_EVENT_STATE_OFF)
continue;
 
if (n >= max_count)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH -mm] fs: shrinker: always scan at least one object of each type

2015-01-13 Thread Vladimir Davydov
On Tue, Jan 13, 2015 at 03:56:39PM -0800, Andrew Morton wrote:
> On Mon, 12 Jan 2015 13:20:46 +0300 Vladimir Davydov  
> wrote:
> 
> > In super_cache_scan() we divide the number of objects of particular type
> > by the total number of objects in order to distribute pressure among
> > different types of fs objects (inodes, dentries, fs-private objects).
> > As a result, in some corner cases we can get nr_to_scan=0 even if there
> > are some objects to reclaim, e.g. dentries=1, inodes=1, fs_objects=1,
> > nr_to_scan=1/3=0.
> > 
> > This is unacceptable for per memcg kmem accounting, because this means
> > that some objects may never get reclaimed after memcg death, preventing
> > it from being freed.
> > 
> > This patch therefore assures that super_cache_scan() will scan at least
> > one object of each type if any.
> > 
> > --- a/fs/super.c
> > +++ b/fs/super.c
> > @@ -92,13 +92,13 @@ static unsigned long super_cache_scan(struct shrinker 
> > *shrink,
> >  * prune the dcache first as the icache is pinned by it, then
> >  * prune the icache, followed by the filesystem specific caches
> >  */
> > -   sc->nr_to_scan = dentries;
> > +   sc->nr_to_scan = dentries + 1;
> > freed = prune_dcache_sb(sb, sc);
> > -   sc->nr_to_scan = inodes;
> > +   sc->nr_to_scan = inodes + 1;
> > freed += prune_icache_sb(sb, sc);
> >  
> > if (fs_objects) {
> > -   sc->nr_to_scan = fs_objects;
> > +   sc->nr_to_scan = fs_objects + 1;
> > freed += sb->s_op->free_cached_objects(sb, sc);
> > }
> 
> A reader of this code will wonder "why is it adding 1 everywhere". 
> Let's tell them?

Yeah, sounds reasonable. Thank you!

> 
> --- a/fs/super.c~fs-shrinker-always-scan-at-least-one-object-of-each-type-fix
> +++ a/fs/super.c
> @@ -91,6 +91,9 @@ static unsigned long super_cache_scan(st
>   /*
>* prune the dcache first as the icache is pinned by it, then
>* prune the icache, followed by the filesystem specific caches
> +  *
> +  * Ensure that we always scan at least one object - memcg kmem
> +  * accounting uses this to fully empty the caches.
>*/
>   sc->nr_to_scan = dentries + 1;
>   freed = prune_dcache_sb(sb, sc);
> _
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v9 1/4] drm/i2c: tda998x: Add DT support for audio

2015-01-13 Thread Jean-Francois Moine
On Tue, 13 Jan 2015 19:54:15 +
Russell King - ARM Linux  wrote:

> On Tue, Jan 13, 2015 at 09:41:01PM +0200, Jyri Sarha wrote:
> > On 01/13/2015 09:26 PM, Russell King - ARM Linux wrote:
> > >SCLK: _~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_
> > >   WS: __~
> > >I2S1: llmmllmmllm
> > >I2S2: llmmllmmllm
> > >I2S3: llmmllmmllm
> > >I2S4: llmmllmmllm
> > >
> > >So, what I'm saying is that it is_impossible_  to drive the TDA998x using
> > >multiple I2S streams which are not produced by the same I2S block.
> > 
> > This is besides the point, but it is possible that one of the multiple I2S
> > blocks is the bit-clock and frame-clock master to the i2s bus and the others
> > are slaves to it (banging their bits according to SCLK and WS of the I2S
> > master). However, in this situation there really is only one i2s bus with
> > multiple data pins.
> > 
> > Just my 0.02€ to this discussion.
> 
> Right, that's about the only way it could work.
> 
> To represent that in DT, I would imagine we'd need something like this:
> 
>   #address-cells = <1>;
>   #size-cells = <0>;
>   ...
> port@1 {/* AP1,2 = I2S */
>   #address-cells = <1>;
>   #size-cells = <0>;
> port-type = "i2s";
> reg = <0x01>; /* WS */
> tda998x_i2s1: endpoint@2 {
>   reg = <0x02>;   /* AP1 */
> remote-endpoint = <_i2s>;
> };
> tda998x_i2s2: endpoint@4 {
>   reg = <0x04>;   /* AP2 */
> remote-endpoint = <_i2s>;
> };
> };
> 
> where audio1_i2s is operating in master mode, and audio2_i2s is
> operating in slave mode for both WS and SCLK.
> 
> If we can agree on that, then I'm happy with the proposed binding.
> (Remember that #address-cells and #size-cells are required in the
> parent where we have reg= in the child.)

#address-cells and #size-cells may be defined in any of the upper
parent, so, as it is defined in the device, it is not needed in the
port (see of_n_addr_cells in drivers/of/base.c).

Well, I am a bit lost between (only one source / many channels - I2S
busses) and (many sources / one I2s bus!).

Anyway, I don't understand your example.
I'd expect that a port would be a DAI.

If yes, when playing is active, both endpoints receive an audio stream
from the remote audio devices, and the AP register is always set to
0x07 (= 0x01 | 0x02 | 0x04).
Then, it would have been simpler to have:

#address-cells = <1>;
#size-cells = <0>;
...
 port@7 {/* AP1,2 = I2S */
 port-type = "i2s";
 reg = <0x07>;  /* WS + AP1 + AP2 */
 tda998x_i2s1: endpoint@1 {
 remote-endpoint = <_i2s>;
 };
 tda998x_i2s2: endpoint@2 {
 remote-endpoint = <_i2s>;
 };
 };

If no, the two DAIs must be created from the endpoints, permitting
streaming on i2s1 alone, i2s2 alone or both i2s1+i2s2 at the same time.
Then, it would have been simpler to define the DAIs from the ports:

#address-cells = <1>;
#size-cells = <0>;
...
 port@3 {/* AP1 = I2S */
 port-type = "i2s";
 reg = <0x03>;  /* WS + AP1 */
 tda998x_i2s1: endpoint {
 remote-endpoint = <_i2s>;
 };
 };
 port@5 {/* AP2 = I2S */
 port-type = "i2s";
 reg = <0x05>;  /* WS + AP2 */
 tda998x_i2s1: endpoint {
 remote-endpoint = <_i2s>;
 };
};

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 72/77] perf session: Do not fail on processing out of order event

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Jiri Olsa 

commit f61ff6c06dc8f32c7036013ad802c899ec590607 upstream.

Linus reported perf report command being interrupted due to processing
of 'out of order' event, with following error:

  Timestamp below last timeslice flush
  0x5733a8 [0x28]: failed to process type: 3

I could reproduce the issue and in my case it was caused by one CPU
(mmap) being behind during record and userspace mmap reader seeing the
data after other CPUs data were already stored.

This is expected under some circumstances because we need to limit the
number of events that we queue for reordering when we receive a
PERF_RECORD_FINISHED_ROUND or when we force flush due to memory
pressure.

Reported-by: Linus Torvalds 
Signed-off-by: Jiri Olsa 
Acked-by: Ingo Molnar 
Cc: Andi Kleen 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: 
http://lkml.kernel.org/r/1417016371-30249-1-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
[zhangzhiqiang: backport to 3.10:
 - adjust context
 - commit f61ff6c06d struct events_stats was defined in tools/perf/util/event.h
   while 3.10 stable defined in tools/perf/util/hist.h.
 - 3.10 stable there is no pr_oe_time() which used for debug.
 - After the above adjustments, becomes same to the original patch:
   
https://github.com/torvalds/linux/commit/f61ff6c06dc8f32c7036013ad802c899ec590607
]
Signed-off-by: Zhiqiang Zhang 
Signed-off-by: Greg Kroah-Hartman 
---
 tools/perf/util/hist.h|1 +
 tools/perf/util/session.c |5 +++--
 2 files changed, 4 insertions(+), 2 deletions(-)

--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -36,6 +36,7 @@ struct events_stats {
u32 nr_invalid_chains;
u32 nr_unknown_id;
u32 nr_unprocessable_samples;
+   u32 nr_unordered_events;
 };
 
 enum hist_column {
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -638,8 +638,7 @@ int perf_session_queue_event(struct perf
return -ETIME;
 
if (timestamp < s->ordered_samples.last_flush) {
-   printf("Warning: Timestamp below last timeslice flush\n");
-   return -EINVAL;
+   s->stats.nr_unordered_events++;
}
 
if (!list_empty(sc)) {
@@ -1135,6 +1134,8 @@ static void perf_session__warn_about_err
"Do you have a KVM guest running and not using 
'perf kvm'?\n",
session->stats.nr_unprocessable_samples);
}
+   if (session->stats.nr_unordered_events != 0)
+   ui__warning("%u out of order events recorded.\n", 
session->stats.nr_unordered_events);
 }
 
 volatile int session_done;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] netdevice: Add missing parentheses in macro

2015-01-13 Thread Benjamin Poirier
For example, one could conceivably call
for_each_netdev_in_bond_rcu(condition ? bond1 : bond2, slave)
and get an unexpected result.

Signed-off-by: Benjamin Poirier 
---
 include/linux/netdevice.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 7f794db..52fd8e8 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2085,7 +2085,7 @@ extern rwlock_t   dev_base_lock;  
/* Device list lock */
list_for_each_entry_continue_rcu(d, &(net)->dev_base_head, dev_list)
 #define for_each_netdev_in_bond_rcu(bond, slave)   \
for_each_netdev_rcu(_net, slave)   \
-   if (netdev_master_upper_dev_get_rcu(slave) == bond)
+   if (netdev_master_upper_dev_get_rcu(slave) == (bond))
 #define net_device_entry(lh)   list_entry(lh, struct net_device, dev_list)
 
 static inline struct net_device *next_net_device(struct net_device *dev)
-- 
2.2.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2] ALSA: ASoC: soc-compress.c: fix NULL dereference

2015-01-13 Thread Qais Yousef

On 01/13/2015 04:20 PM, Mark Brown wrote:

On Tue, Jan 13, 2015 at 03:16:10PM +, Qais Yousef wrote:

On 01/13/2015 02:59 PM, Vinod Koul wrote:

being NULL, hence when trying to set rtd a few lines below we get an oops.

It is a good practice to add the oops here

Will this really be helpful? I think it'll be more clutter (the backtrace on
metag arch is not great):

It's better in general to leave it out unless it's adding something (for
example sometimes the particular call path is important) and even there
edit it down to relevant details - the splat from the full oops normally
overwhelms the commit message.


I think the commit message explains what's going. So unless Vinod 
insists I'll send v3 with the other 2 requested fixes.


Thanks for the review!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 75/77] mm, vmscan: prevent kswapd livelock due to pfmemalloc-throttled process being killed

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Vlastimil Babka 

commit 9e5e3661727eaf960d3480213f8e87c8d67b6956 upstream.

Charles Shirron and Paul Cassella from Cray Inc have reported kswapd
stuck in a busy loop with nothing left to balance, but
kswapd_try_to_sleep() failing to sleep.  Their analysis found the cause
to be a combination of several factors:

1. A process is waiting in throttle_direct_reclaim() on pgdat->pfmemalloc_wait

2. The process has been killed (by OOM in this case), but has not yet been
   scheduled to remove itself from the waitqueue and die.

3. kswapd checks for throttled processes in prepare_kswapd_sleep():

if (waitqueue_active(>pfmemalloc_wait)) {
wake_up(>pfmemalloc_wait);
return false; // kswapd will not go to sleep
}

   However, for a process that was already killed, wake_up() does not remove
   the process from the waitqueue, since try_to_wake_up() checks its state
   first and returns false when the process is no longer waiting.

4. kswapd is running on the same CPU as the only CPU that the process is
   allowed to run on (through cpus_allowed, or possibly single-cpu system).

5. CONFIG_PREEMPT_NONE=y kernel is used. If there's nothing to balance, kswapd
   encounters no voluntary preemption points and repeatedly fails
   prepare_kswapd_sleep(), blocking the process from running and removing
   itself from the waitqueue, which would let kswapd sleep.

So, the source of the problem is that we prevent kswapd from going to
sleep until there are processes waiting on the pfmemalloc_wait queue,
and a process waiting on a queue is guaranteed to be removed from the
queue only when it gets scheduled.  This was done to make sure that no
process is left sleeping on pfmemalloc_wait when kswapd itself goes to
sleep.

However, it isn't necessary to postpone kswapd sleep until the
pfmemalloc_wait queue actually empties.  To prevent processes from being
left sleeping, it's actually enough to guarantee that all processes
waiting on pfmemalloc_wait queue have been woken up by the time we put
kswapd to sleep.

This patch therefore fixes this issue by substituting 'wake_up' with
'wake_up_all' and removing 'return false' in the code snippet from
prepare_kswapd_sleep() above.  Note that if any process puts itself in
the queue after this waitqueue_active() check, or after the wake up
itself, it means that the process will also wake up kswapd - and since
we are under prepare_to_wait(), the wake up won't be missed.  Also we
update the comment prepare_kswapd_sleep() to hopefully more clearly
describe the races it is preventing.

Fixes: 5515061d22f0 ("mm: throttle direct reclaimers if PF_MEMALLOC reserves 
are low and swap is backed by network storage")
Signed-off-by: Vlastimil Babka 
Signed-off-by: Vladimir Davydov 
Cc: Mel Gorman 
Cc: Johannes Weiner 
Acked-by: Michal Hocko 
Acked-by: Rik van Riel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 mm/vmscan.c |   24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2860,18 +2860,20 @@ static bool prepare_kswapd_sleep(pg_data
return false;
 
/*
-* There is a potential race between when kswapd checks its watermarks
-* and a process gets throttled. There is also a potential race if
-* processes get throttled, kswapd wakes, a large process exits therby
-* balancing the zones that causes kswapd to miss a wakeup. If kswapd
-* is going to sleep, no process should be sleeping on pfmemalloc_wait
-* so wake them now if necessary. If necessary, processes will wake
-* kswapd and get throttled again
+* The throttled processes are normally woken up in balance_pgdat() as
+* soon as pfmemalloc_watermark_ok() is true. But there is a potential
+* race between when kswapd checks the watermarks and a process gets
+* throttled. There is also a potential race if processes get
+* throttled, kswapd wakes, a large process exits thereby balancing the
+* zones, which causes kswapd to exit balance_pgdat() before reaching
+* the wake up checks. If kswapd is going to sleep, no process should
+* be sleeping on pfmemalloc_wait, so wake them now if necessary. If
+* the wake up is premature, processes will wake kswapd and get
+* throttled again. The difference from wake ups in balance_pgdat() is
+* that here we are under prepare_to_wait().
 */
-   if (waitqueue_active(>pfmemalloc_wait)) {
-   wake_up(>pfmemalloc_wait);
-   return false;
-   }
+   if (waitqueue_active(>pfmemalloc_wait))
+   wake_up_all(>pfmemalloc_wait);
 
return pgdat_balanced(pgdat, order, classzone_idx);
 }


--
To unsubscribe from this list: send the line 

[PATCH 3.14 76/77] mm: propagate error from stack expansion even for guard page

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Linus Torvalds 

commit fee7e49d45149fba60156f5b59014f764d3e3728 upstream.

Jay Foad reports that the address sanitizer test (asan) sometimes gets
confused by a stack pointer that ends up being outside the stack vma
that is reported by /proc/maps.

This happens due to an interaction between RLIMIT_STACK and the guard
page: when we do the guard page check, we ignore the potential error
from the stack expansion, which effectively results in a missing guard
page, since the expected stack expansion won't have been done.

And since /proc/maps explicitly ignores the guard page (commit
d7824370e263: "mm: fix up some user-visible effects of the stack guard
page"), the stack pointer ends up being outside the reported stack area.

This is the minimal patch: it just propagates the error.  It also
effectively makes the guard page part of the stack limit, which in turn
measn that the actual real stack is one page less than the stack limit.

Let's see if anybody notices.  We could teach acct_stack_growth() to
allow an extra page for a grow-up/grow-down stack in the rlimit test,
but I don't want to add more complexity if it isn't needed.

Reported-and-tested-by: Jay Foad 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 include/linux/mm.h |2 +-
 mm/memory.c|4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1866,7 +1866,7 @@ extern int expand_downwards(struct vm_ar
 #if VM_GROWSUP
 extern int expand_upwards(struct vm_area_struct *vma, unsigned long address);
 #else
-  #define expand_upwards(vma, address) do { } while (0)
+  #define expand_upwards(vma, address) (0)
 #endif
 
 /* Look up the first VMA which satisfies  addr < vm_end,  NULL if none. */
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3204,7 +3204,7 @@ static inline int check_stack_guard_page
if (prev && prev->vm_end == address)
return prev->vm_flags & VM_GROWSDOWN ? 0 : -ENOMEM;
 
-   expand_downwards(vma, address - PAGE_SIZE);
+   return expand_downwards(vma, address - PAGE_SIZE);
}
if ((vma->vm_flags & VM_GROWSUP) && address + PAGE_SIZE == vma->vm_end) 
{
struct vm_area_struct *next = vma->vm_next;
@@ -3213,7 +3213,7 @@ static inline int check_stack_guard_page
if (next && next->vm_start == address + PAGE_SIZE)
return next->vm_flags & VM_GROWSUP ? 0 : -ENOMEM;
 
-   expand_upwards(vma, address + PAGE_SIZE);
+   return expand_upwards(vma, address + PAGE_SIZE);
}
return 0;
 }


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v3 2/3] i2c: iproc: Add Broadcom iProc I2C Driver

2015-01-13 Thread Uwe Kleine-König
Hello,

On Tue, Jan 13, 2015 at 06:14:17PM -0800, Ray Jui wrote:
> >> +  irq = platform_get_irq(pdev, 0);
> >> +  if (irq < 0) {
> > irq == 0 should be handled as error, too.
> > 
> Ah. I thought zero is a valid global interrupt number, and I see other
> drivers checking against < 0 as well. Is my understanding incorrect?
These are wrong, too. 0 should never be a valid interrupt number. There
are some exceptions but mostly for historic reasons. The right handling
is used for example in drivers/i2c/busses/i2c-efm32.c.

> >> +  dev_err(dev->device, "no irq resource\n");
> >> +  return irq;
> >> +  }
> [...]
> >> +static int bcm_iproc_i2c_remove(struct platform_device *pdev)
> >> +{
> >> +  struct bcm_iproc_i2c_dev *dev = platform_get_drvdata(pdev);
> >> +
> >> +  i2c_del_adapter(>adapter);
> >> +  bcm_iproc_i2c_disable(dev);
> > I think you have a problem here if bcm_iproc_i2c_remove is called while
> > an irq is still being serviced. I'm not sure how to prevent this
> > properly for a shared interrupt.
> > 
> Can I grab i2c_lock_adapter to ensure the bus is locked (so there's no
> outstanding transactions or IRQs by the time we remove the adapter)? But
> I see no I2C bus driver does this in their remove function...
The problem I pointed out is the reason for some driver authors not to
use devm_request_irq. If you use plain request_irq and the matching
free_irq in the .remove callback you can be sure that the irq isn't
running any more as soon as free_irq returns.

BTW, if you use vim, you can add

set cinoptions=(,:
if has("autocmd")
filetype plugin indent on
endif

to your .vimrc. Then while typing vim does the indention right and
consistent, and with the = command you can reindent.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 77/77] mm: Dont count the stack guard page towards RLIMIT_STACK

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Linus Torvalds 

commit 690eac53daff34169a4d74fc7bfbd388c4896abb upstream.

Commit fee7e49d4514 ("mm: propagate error from stack expansion even for
guard page") made sure that we return the error properly for stack
growth conditions.  It also theorized that counting the guard page
towards the stack limit might break something, but also said "Let's see
if anybody notices".

Somebody did notice.  Apparently android-x86 sets the stack limit very
close to the limit indeed, and including the guard page in the rlimit
check causes the android 'zygote' process problems.

So this adds the (fairly trivial) code to make the stack rlimit check be
against the actual real stack size, rather than the size of the vma that
includes the guard page.

Reported-and-tested-by: Chih-Wei Huang 
Cc: Jay Foad 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 mm/mmap.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2058,14 +2058,17 @@ static int acct_stack_growth(struct vm_a
 {
struct mm_struct *mm = vma->vm_mm;
struct rlimit *rlim = current->signal->rlim;
-   unsigned long new_start;
+   unsigned long new_start, actual_size;
 
/* address space limit tests */
if (!may_expand_vm(mm, grow))
return -ENOMEM;
 
/* Stack limit test */
-   if (size > ACCESS_ONCE(rlim[RLIMIT_STACK].rlim_cur))
+   actual_size = size;
+   if (size && (vma->vm_flags & (VM_GROWSUP | VM_GROWSDOWN)))
+   actual_size -= PAGE_SIZE;
+   if (actual_size > ACCESS_ONCE(rlim[RLIMIT_STACK].rlim_cur))
return -ENOMEM;
 
/* mlock limit tests */


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 73/77] spi: fsl: Fix problem with multi message transfers

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Stefan Roese 

commit 4302a59629f7a0bd70fd1605d2b558597517372a upstream.

When used via spidev with more than one messages to tranfer via
SPI_IOC_MESSAGE the current implementation would return with
-EINVAL, since bits_per_word and speed_hz are set in all
transfer structs. And in the 2nd loop status will stay at
-EINVAL as its not overwritten again via fsl_spi_setup_transfer().

This patch changes this behavious by first checking if one of
the messages uses different settings. If this is the case
the function will return with -EINVAL. If not, the messages
are transferred correctly.

Signed-off-by: Stefan Roese 
Signed-off-by: Mark Brown 
Cc: Esben Haabendal 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/spi/spi-fsl-spi.c |   20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

--- a/drivers/spi/spi-fsl-spi.c
+++ b/drivers/spi/spi-fsl-spi.c
@@ -362,18 +362,28 @@ static int fsl_spi_bufs(struct spi_devic
 static void fsl_spi_do_one_msg(struct spi_message *m)
 {
struct spi_device *spi = m->spi;
-   struct spi_transfer *t;
+   struct spi_transfer *t, *first;
unsigned int cs_change;
const int nsecs = 50;
int status;
 
-   cs_change = 1;
-   status = 0;
+   /* Don't allow changes if CS is active */
+   first = list_first_entry(>transfers, struct spi_transfer,
+   transfer_list);
list_for_each_entry(t, >transfers, transfer_list) {
-   if (t->bits_per_word || t->speed_hz) {
-   /* Don't allow changes if CS is active */
+   if ((first->bits_per_word != t->bits_per_word) ||
+   (first->speed_hz != t->speed_hz)) {
status = -EINVAL;
+   dev_err(>dev,
+   "bits_per_word/speed_hz should be same for the 
same SPI transfer\n");
+   return;
+   }
+   }
 
+   cs_change = 1;
+   status = -EINVAL;
+   list_for_each_entry(t, >transfers, transfer_list) {
+   if (t->bits_per_word || t->speed_hz) {
if (cs_change)
status = fsl_spi_setup_transfer(spi, t);
if (status < 0)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 59/77] ARM: dts: DRA7: wdt: Fix compatible property for watchdog node

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Lokesh Vutla 

commit be6688350a4470e417aaeca54d162652aab40ac5 upstream.

OMAP wdt driver supports only ti,omap3-wdt compatible. In DRA7 dt
wdt compatible property is defined as ti,omap4-wdt by mistake instead of
ti,omap3-wdt. Correcting the typo.

Fixes: 6e58b8f1daaf1a ("ARM: dts: DRA7: Add the dts files for dra7 SoC and 
dra7-evm board")
Signed-off-by: Lokesh Vutla 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/boot/dts/dra7.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -458,7 +458,7 @@
};
 
wdt2: wdt@4ae14000 {
-   compatible = "ti,omap4-wdt";
+   compatible = "ti,omap3-wdt";
reg = <0x4ae14000 0x80>;
interrupts = ;
ti,hwmods = "wd_timer2";


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 58/77] sched/deadline: Avoid double-accounting in case of missed deadlines

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Luca Abeni 

commit 269ad8015a6b2bb1cf9e684da4921eb6fa0a0c88 upstream.

The dl_runtime_exceeded() function is supposed to ckeck if
a SCHED_DEADLINE task must be throttled, by checking if its
current runtime is <= 0. However, it also checks if the
scheduling deadline has been missed (the current time is
larger than the current scheduling deadline), further
decreasing the runtime if this happens.
This "double accounting" is wrong:

- In case of partitioned scheduling (or single CPU), this
  happens if task_tick_dl() has been called later than expected
  (due to small HZ values). In this case, the current runtime is
  also negative, and replenish_dl_entity() can take care of the
  deadline miss by recharging the current runtime to a value smaller
  than dl_runtime

- In case of global scheduling on multiple CPUs, scheduling
  deadlines can be missed even if the task did not consume more
  runtime than expected, hence penalizing the task is wrong

This patch fix this problem by throttling a SCHED_DEADLINE task
only when its runtime becomes negative, and not modifying the runtime

Signed-off-by: Luca Abeni 
Signed-off-by: Peter Zijlstra (Intel) 
Acked-by: Juri Lelli 
Cc: Dario Faggioli 
Cc: Linus Torvalds 
Link: 
http://lkml.kernel.org/r/1418813432-20797-3-git-send-email-luca.ab...@unitn.it
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/sched/deadline.c |   19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -550,24 +550,7 @@ void init_dl_task_timer(struct sched_dl_
 static
 int dl_runtime_exceeded(struct rq *rq, struct sched_dl_entity *dl_se)
 {
-   int dmiss = dl_time_before(dl_se->deadline, rq_clock(rq));
-   int rorun = dl_se->runtime <= 0;
-
-   if (!rorun && !dmiss)
-   return 0;
-
-   /*
-* If we are beyond our current deadline and we are still
-* executing, then we have already used some of the runtime of
-* the next instance. Thus, if we do not account that, we are
-* stealing bandwidth from the system at each deadline miss!
-*/
-   if (dmiss) {
-   dl_se->runtime = rorun ? dl_se->runtime : 0;
-   dl_se->runtime -= rq_clock(rq) - dl_se->deadline;
-   }
-
-   return 1;
+   return (dl_se->runtime <= 0);
 }
 
 extern bool sched_rt_bandwidth_account(struct rt_rq *rt_rq);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 56/77] scripts/kernel-doc: dont eat struct members with __aligned

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Johannes Berg 

commit 7b990789a4c3420fa57596b368733158e432d444 upstream.

The change from \d+ to .+ inside __aligned() means that the following
structure:

  struct test {
u8 a __aligned(2);
u8 b __aligned(2);
  };

essentially gets modified to

  struct test {
u8 a;
  };

for purposes of kernel-doc, thus dropping a struct member, which in
turns causes warnings and invalid kernel-doc generation.

Fix this by replacing the catch-all (".") with anything that's not a
semicolon ("[^;]").

Fixes: 9dc30918b23f ("scripts/kernel-doc: handle struct member __aligned 
without numbers")
Signed-off-by: Johannes Berg 
Cc: Nishanth Menon 
Cc: Randy Dunlap 
Cc: Michal Marek 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 scripts/kernel-doc |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -1753,7 +1753,7 @@ sub dump_struct($$) {
# strip kmemcheck_bitfield_{begin,end}.*;
$members =~ s/kmemcheck_bitfield_.*?;//gos;
# strip attributes
-   $members =~ s/__aligned\s*\(.+\)//gos;
+   $members =~ s/__aligned\s*\([^;]*\)//gos;
 
create_parameterlist($members, ';', $file);
check_sections($file, $declaration_name, "struct", $sectcheck, 
$struct_actual, $nested);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 01/44] ocfs2: fix journal commit deadlock

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Junxiao Bi 

commit 136f49b9171074872f2a14ad0ab10486d1ba13ca upstream.

For buffer write, page lock will be got in write_begin and released in
write_end, in ocfs2_write_end_nolock(), before it unlock the page in
ocfs2_free_write_ctxt(), it calls ocfs2_run_deallocs(), this will ask
for the read lock of journal->j_trans_barrier.  Holding page lock and
ask for journal->j_trans_barrier breaks the locking order.

This will cause a deadlock with journal commit threads, ocfs2cmt will
get write lock of journal->j_trans_barrier first, then it wakes up
kjournald2 to do the commit work, at last it waits until done.  To
commit journal, kjournald2 needs flushing data first, it needs get the
cache page lock.

Since some ocfs2 cluster locks are holding by write process, this
deadlock may hung the whole cluster.

unlock pages before ocfs2_run_deallocs() can fix the locking order, also
put unlock before ocfs2_commit_trans() to make page lock is unlocked
before j_trans_barrier to preserve unlocking order.

Signed-off-by: Junxiao Bi 
Reviewed-by: Wengang Wang 
Reviewed-by: Mark Fasheh 
Cc: Joel Becker 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/ocfs2/aops.c |   16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

--- a/fs/ocfs2/aops.c
+++ b/fs/ocfs2/aops.c
@@ -917,7 +917,7 @@ void ocfs2_unlock_and_free_pages(struct
}
 }
 
-static void ocfs2_free_write_ctxt(struct ocfs2_write_ctxt *wc)
+static void ocfs2_unlock_pages(struct ocfs2_write_ctxt *wc)
 {
int i;
 
@@ -938,7 +938,11 @@ static void ocfs2_free_write_ctxt(struct
page_cache_release(wc->w_target_page);
}
ocfs2_unlock_and_free_pages(wc->w_pages, wc->w_num_pages);
+}
 
+static void ocfs2_free_write_ctxt(struct ocfs2_write_ctxt *wc)
+{
+   ocfs2_unlock_pages(wc);
brelse(wc->w_di_bh);
kfree(wc);
 }
@@ -2060,11 +2064,19 @@ out_write_size:
di->i_mtime_nsec = di->i_ctime_nsec = 
cpu_to_le32(inode->i_mtime.tv_nsec);
ocfs2_journal_dirty(handle, wc->w_di_bh);
 
+   /* unlock pages before dealloc since it needs acquiring j_trans_barrier
+* lock, or it will cause a deadlock since journal commit threads holds
+* this lock and will ask for the page lock when flushing the data.
+* put it here to preserve the unlock order.
+*/
+   ocfs2_unlock_pages(wc);
+
ocfs2_commit_trans(osb, handle);
 
ocfs2_run_deallocs(osb, >w_dealloc);
 
-   ocfs2_free_write_ctxt(wc);
+   brelse(wc->w_di_bh);
+   kfree(wc);
 
return copied;
 }


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 52/77] ceph: do_sync is never initialized

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Dan Carpenter 

commit 021b77bee210843bed1ea91b5cad58235ff9c8e5 upstream.

Probably this code was syncing a lot more often then intended because
the do_sync variable wasn't set to zero.

Fixes: c62988ec0910 ('ceph: avoid meaningless calling ceph_caps_revoking if 
sync_mode == WB_SYNC_ALL.')
Signed-off-by: Dan Carpenter 
Signed-off-by: Ilya Dryomov 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/ceph/addr.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/ceph/addr.c
+++ b/fs/ceph/addr.c
@@ -676,7 +676,7 @@ static int ceph_writepages_start(struct
int rc = 0;
unsigned wsize = 1 << inode->i_blkbits;
struct ceph_osd_request *req = NULL;
-   int do_sync;
+   int do_sync = 0;
u64 truncate_size, snap_size;
u32 truncate_seq;
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 10/44] ASoC: dwc: Ensure FIFOs are flushed to prevent channel swap

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Andrew Jackson 

commit 3475c3d034d7f276a474c8bd53f44b48c8bf669d upstream.

Flush the FIFOs when the stream is prepared for use.  This avoids
an inadvertent swapping of the left/right channels if the FIFOs are
not empty at startup.

Signed-off-by: Andrew Jackson 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/soc/dwc/designware_i2s.c |   14 ++
 1 file changed, 14 insertions(+)

--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -263,6 +263,19 @@ static void dw_i2s_shutdown(struct snd_p
snd_soc_dai_set_dma_data(dai, substream, NULL);
 }
 
+static int dw_i2s_prepare(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+   struct dw_i2s_dev *dev = snd_soc_dai_get_drvdata(dai);
+
+   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+   i2s_write_reg(dev->i2s_base, TXFFR, 1);
+   else
+   i2s_write_reg(dev->i2s_base, RXFFR, 1);
+
+   return 0;
+}
+
 static int dw_i2s_trigger(struct snd_pcm_substream *substream,
int cmd, struct snd_soc_dai *dai)
 {
@@ -294,6 +307,7 @@ static struct snd_soc_dai_ops dw_i2s_dai
.startup= dw_i2s_startup,
.shutdown   = dw_i2s_shutdown,
.hw_params  = dw_i2s_hw_params,
+   .prepare= dw_i2s_prepare,
.trigger= dw_i2s_trigger,
 };
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 13/44] pstore-ram: Allow optional mapping with pgprot_noncached

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Tony Lindgren 

commit 027bc8b08242c59e19356b4b2c189f2d849ab660 upstream.

On some ARMs the memory can be mapped pgprot_noncached() and still
be working for atomic operations. As pointed out by Colin Cross
, in some cases you do want to use
pgprot_noncached() if the SoC supports it to see a debug printk
just before a write hanging the system.

On ARMs, the atomic operations on strongly ordered memory are
implementation defined. So let's provide an optional kernel parameter
for configuring pgprot_noncached(), and use pgprot_writecombine() by
default.

Cc: Arnd Bergmann 
Cc: Rob Herring 
Cc: Randy Dunlap 
Cc: Anton Vorontsov 
Cc: Colin Cross 
Cc: Olof Johansson 
Cc: Russell King 
Acked-by: Kees Cook 
Signed-off-by: Tony Lindgren 
Signed-off-by: Tony Luck 
Signed-off-by: Greg Kroah-Hartman 

---
 Documentation/ramoops.txt  |   13 +++--
 fs/pstore/ram.c|   13 +++--
 fs/pstore/ram_core.c   |   31 ++-
 include/linux/pstore_ram.h |4 +++-
 4 files changed, 47 insertions(+), 14 deletions(-)

--- a/Documentation/ramoops.txt
+++ b/Documentation/ramoops.txt
@@ -14,11 +14,19 @@ survive after a restart.
 
 1. Ramoops concepts
 
-Ramoops uses a predefined memory area to store the dump. The start and size of
-the memory area are set using two variables:
+Ramoops uses a predefined memory area to store the dump. The start and size
+and type of the memory area are set using three variables:
   * "mem_address" for the start
   * "mem_size" for the size. The memory size will be rounded down to a
   power of two.
+  * "mem_type" to specifiy if the memory type (default is pgprot_writecombine).
+
+Typically the default value of mem_type=0 should be used as that sets the 
pstore
+mapping to pgprot_writecombine. Setting mem_type=1 attempts to use
+pgprot_noncached, which only works on some platforms. This is because pstore
+depends on atomic operations. At least on ARM, pgprot_noncached causes the
+memory to be mapped strongly ordered, and atomic operations on strongly ordered
+memory are implementation defined, and won't work on many ARMs such as omaps.
 
 The memory area is divided into "record_size" chunks (also rounded down to
 power of two) and each oops/panic writes a "record_size" chunk of
@@ -55,6 +63,7 @@ Setting the ramoops parameters can be do
 static struct ramoops_platform_data ramoops_data = {
 .mem_size   = <...>,
 .mem_address= <...>,
+.mem_type   = <...>,
 .record_size= <...>,
 .dump_oops  = <...>,
 .ecc= <...>,
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -61,6 +61,11 @@ module_param(mem_size, ulong, 0400);
 MODULE_PARM_DESC(mem_size,
"size of reserved RAM used to store oops/panic logs");
 
+static unsigned int mem_type;
+module_param(mem_type, uint, 0600);
+MODULE_PARM_DESC(mem_type,
+   "set to 1 to try to use unbuffered memory (default 0)");
+
 static int dump_oops = 1;
 module_param(dump_oops, int, 0600);
 MODULE_PARM_DESC(dump_oops,
@@ -79,6 +84,7 @@ struct ramoops_context {
struct persistent_ram_zone *fprz;
phys_addr_t phys_addr;
unsigned long size;
+   unsigned int memtype;
size_t record_size;
size_t console_size;
size_t ftrace_size;
@@ -331,7 +337,8 @@ static int ramoops_init_przs(struct devi
size_t sz = cxt->record_size;
 
cxt->przs[i] = persistent_ram_new(*paddr, sz, 0,
- >ecc_info);
+ >ecc_info,
+ cxt->memtype);
if (IS_ERR(cxt->przs[i])) {
err = PTR_ERR(cxt->przs[i]);
dev_err(dev, "failed to request mem region 
(0x%zx@0x%llx): %d\n",
@@ -361,7 +368,7 @@ static int ramoops_init_prz(struct devic
return -ENOMEM;
}
 
-   *prz = persistent_ram_new(*paddr, sz, sig, >ecc_info);
+   *prz = persistent_ram_new(*paddr, sz, sig, >ecc_info, 
cxt->memtype);
if (IS_ERR(*prz)) {
int err = PTR_ERR(*prz);
 
@@ -411,6 +418,7 @@ static int ramoops_probe(struct platform
cxt->dump_read_cnt = 0;
cxt->size = pdata->mem_size;
cxt->phys_addr = pdata->mem_address;
+   cxt->memtype = pdata->mem_type;
cxt->record_size = pdata->record_size;
cxt->console_size = pdata->console_size;
cxt->ftrace_size = pdata->ftrace_size;
@@ -541,6 +549,7 @@ static void ramoops_register_dummy(void)
 
dummy_data->mem_size = mem_size;
dummy_data->mem_address = mem_address;
+   dummy_data->mem_type = 0;
dummy_data->record_size = record_size;
dummy_data->console_size = ramoops_console_size;

[PATCH 3.14 61/77] ARM: OMAP4: PM: Only do static dependency configuration in omap4_init_static_deps

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Nishanth Menon 

commit 9008d83fe9dc2e0f19b8ba17a423b3759d8e0fd7 upstream.

Commit 705814b5ea6f ("ARM: OMAP4+: PM: Consolidate OMAP4 PM code to
re-use it for OMAP5")

Moved logic generic for OMAP5+ as part of the init routine by
introducing omap4_pm_init. However, the patch left the powerdomain
initial setup, an unused omap4430 es1.0 check and a spurious log
"Power Management for TI OMAP4." in the original code.

Remove the duplicate code which is already present in omap4_pm_init from
omap4_init_static_deps.

As part of this change, also move the u-boot version print out of the
static dependency function to the omap4_pm_init function.

Fixes: 705814b5ea6f ("ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it 
for OMAP5")
Signed-off-by: Nishanth Menon 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/mach-omap2/pm44xx.c |   29 +
 1 file changed, 9 insertions(+), 20 deletions(-)

--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -148,26 +148,6 @@ static inline int omap4_init_static_deps
struct clockdomain *ducati_clkdm, *l3_2_clkdm;
int ret = 0;
 
-   if (omap_rev() == OMAP4430_REV_ES1_0) {
-   WARN(1, "Power Management not supported on OMAP4430 ES1.0\n");
-   return -ENODEV;
-   }
-
-   pr_err("Power Management for TI OMAP4.\n");
-   /*
-* OMAP4 chip PM currently works only with certain (newer)
-* versions of bootloaders. This is due to missing code in the
-* kernel to properly reset and initialize some devices.
-* http://www.spinics.net/lists/arm-kernel/msg218641.html
-*/
-   pr_warn("OMAP4 PM: u-boot >= v2012.07 is required for full PM 
support\n");
-
-   ret = pwrdm_for_each(pwrdms_setup, NULL);
-   if (ret) {
-   pr_err("Failed to setup powerdomains\n");
-   return ret;
-   }
-
/*
 * The dynamic dependency between MPUSS -> MEMIF and
 * MPUSS -> L4_PER/L3_* and DUCATI -> L3_* doesn't work as
@@ -231,6 +211,15 @@ int __init omap4_pm_init(void)
 
pr_info("Power Management for TI OMAP4+ devices.\n");
 
+   /*
+* OMAP4 chip PM currently works only with certain (newer)
+* versions of bootloaders. This is due to missing code in the
+* kernel to properly reset and initialize some devices.
+* http://www.spinics.net/lists/arm-kernel/msg218641.html
+*/
+   if (cpu_is_omap44xx())
+   pr_warn("OMAP4 PM: u-boot >= v2012.07 is required for full PM 
support\n");
+
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
pr_err("Failed to setup powerdomains.\n");


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 12/44] pstore-ram: Fix hangs by using write-combine mappings

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Rob Herring 

commit 7ae9cb81933515dc7db1aa3c47ef7653717e3090 upstream.

Currently trying to use pstore on at least ARMs can hang as we're
mapping the peristent RAM with pgprot_noncached().

On ARMs, pgprot_noncached() will actually make the memory strongly
ordered, and as the atomic operations pstore uses are implementation
defined for strongly ordered memory, they may not work. So basically
atomic operations have undefined behavior on ARM for device or strongly
ordered memory types.

Let's fix the issue by using write-combine variants for mappings. This
corresponds to normal, non-cacheable memory on ARM. For many other
architectures, this change does not change the mapping type as by
default we have:

#define pgprot_writecombine pgprot_noncached

The reason why pgprot_noncached() was originaly used for pstore
is because Colin Cross  had observed lost
debug prints right before a device hanging write operation on some
systems. For the platforms supporting pgprot_noncached(), we can
add a an optional configuration option to support that. But let's
get pstore working first before adding new features.

Cc: Arnd Bergmann 
Cc: Anton Vorontsov 
Cc: Colin Cross 
Cc: Olof Johansson 
Cc: linux-kernel@vger.kernel.org
Acked-by: Kees Cook 
Signed-off-by: Rob Herring 
[t...@atomide.com: updated description]
Signed-off-by: Tony Lindgren 
Signed-off-by: Tony Luck 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/pstore/ram_core.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -345,7 +345,7 @@ static void *persistent_ram_vmap(phys_ad
page_start = start - offset_in_page(start);
page_count = DIV_ROUND_UP(size + offset_in_page(start), PAGE_SIZE);
 
-   prot = pgprot_noncached(PAGE_KERNEL);
+   prot = pgprot_writecombine(PAGE_KERNEL);
 
pages = kmalloc(sizeof(struct page *) * page_count, GFP_KERNEL);
if (!pages) {
@@ -372,7 +372,7 @@ static void *persistent_ram_iomap(phys_a
return NULL;
}
 
-   return ioremap(start, size);
+   return ioremap_wc(start, size);
 }
 
 static int persistent_ram_buffer_map(phys_addr_t start, phys_addr_t size,


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 11/44] PCI: Restore detection of read-only BARs

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Myron Stowe 

commit 36e8164882ca6d3c41cb91e6f09a3ed236841f80 upstream.

Commit 6ac665c63dca ("PCI: rewrite PCI BAR reading code") masked off
low-order bits from 'l', but not from 'sz'.  Both are passed to pci_size(),
which compares 'base == maxbase' to check for read-only BARs.  The masking
of 'l' means that comparison will never be 'true', so the check for
read-only BARs no longer works.

Resolve this by also masking off the low-order bits of 'sz' before passing
it into pci_size() as 'maxbase'.  With this change, pci_size() will once
again catch the problems that have been encountered to date:

  - AGP aperture BAR of AMD-7xx host bridges: if the AGP window is
disabled, this BAR is read-only and read as 0x0008 [1]

  - BARs 0-4 of ALi IDE controllers can be non-zero and read-only [1]

  - Intel Sandy Bridge - Thermal Management Controller [8086:0103];
BAR 0 returning 0xfed98004 [2]

  - Intel Xeon E5 v3/Core i7 Power Control Unit [8086:2fc0];
Bar 0 returning 0x1a [3]

Link: [1] 
https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/drivers/pci/probe.c?id=1307ef6621991f1c4bc3cec1b5a4ebd6fd3d66b9
 ("PCI: probing read-only BARs" (pre-git))
Link: [2] https://bugzilla.kernel.org/show_bug.cgi?id=43331
Link: [3] https://bugzilla.kernel.org/show_bug.cgi?id=85991
Reported-by: William Unruh 
Reported-by: Martin Lucina 
Signed-off-by: Myron Stowe 
Signed-off-by: Bjorn Helgaas 
CC: Matthew Wilcox 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/pci/probe.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -210,14 +210,17 @@ int __pci_read_base(struct pci_dev *dev,
res->flags |= IORESOURCE_SIZEALIGN;
if (res->flags & IORESOURCE_IO) {
l &= PCI_BASE_ADDRESS_IO_MASK;
+   sz &= PCI_BASE_ADDRESS_IO_MASK;
mask = PCI_BASE_ADDRESS_IO_MASK & (u32) IO_SPACE_LIMIT;
} else {
l &= PCI_BASE_ADDRESS_MEM_MASK;
+   sz &= PCI_BASE_ADDRESS_MEM_MASK;
mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
}
} else {
res->flags |= (l & IORESOURCE_ROM_ENABLE);
l &= PCI_ROM_ADDRESS_MASK;
+   sz &= PCI_ROM_ADDRESS_MASK;
mask = (u32)PCI_ROM_ADDRESS_MASK;
}
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 04/44] can: peak_usb: fix cleanup sequence order in case of error during init

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Stephane Grosjean 

commit af35d0f1cce7a990286e2b94c260a2c2d2a0e4b0 upstream.

This patch sets the correct reverse sequence order to the instructions
set to run, when any failure occurs during the initialization steps.
It also adds the missing unregistration call of the can device if the
failure appears after having been registered.

Signed-off-by: Stephane Grosjean 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/can/usb/peak_usb/pcan_usb_core.c |   17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
@@ -727,7 +727,7 @@ static int peak_usb_create_dev(struct pe
dev->cmd_buf = kmalloc(PCAN_USB_MAX_CMD_LEN, GFP_KERNEL);
if (!dev->cmd_buf) {
err = -ENOMEM;
-   goto lbl_set_intf_data;
+   goto lbl_free_candev;
}
 
dev->udev = usb_dev;
@@ -766,7 +766,7 @@ static int peak_usb_create_dev(struct pe
err = register_candev(netdev);
if (err) {
dev_err(>dev, "couldn't register CAN device: %d\n", err);
-   goto lbl_free_cmd_buf;
+   goto lbl_restore_intf_data;
}
 
if (dev->prev_siblings)
@@ -779,14 +779,14 @@ static int peak_usb_create_dev(struct pe
if (dev->adapter->dev_init) {
err = dev->adapter->dev_init(dev);
if (err)
-   goto lbl_free_cmd_buf;
+   goto lbl_unregister_candev;
}
 
/* set bus off */
if (dev->adapter->dev_set_bus) {
err = dev->adapter->dev_set_bus(dev, 0);
if (err)
-   goto lbl_free_cmd_buf;
+   goto lbl_unregister_candev;
}
 
/* get device number early */
@@ -798,11 +798,14 @@ static int peak_usb_create_dev(struct pe
 
return 0;
 
-lbl_free_cmd_buf:
-   kfree(dev->cmd_buf);
+lbl_unregister_candev:
+   unregister_candev(netdev);
 
-lbl_set_intf_data:
+lbl_restore_intf_data:
usb_set_intfdata(intf, dev->prev_siblings);
+   kfree(dev->cmd_buf);
+
+lbl_free_candev:
free_candev(netdev);
 
return err;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 02/44] ath9k_hw: fix hardware queue allocation

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Felix Fietkau 

commit ad8fdccf9c197a89e2d2fa78c453283dcc2c343f upstream.

The driver passes the desired hardware queue index for a WMM data queue
in qinfo->tqi_subtype. This was ignored in ath9k_hw_setuptxqueue, which
instead relied on the order in which the function is called.

Reported-by: Hubert Feurstein 
Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/ath/ath9k/mac.c |9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -311,14 +311,7 @@ int ath9k_hw_setuptxqueue(struct ath_hw
q = ATH9K_NUM_TX_QUEUES - 3;
break;
case ATH9K_TX_QUEUE_DATA:
-   for (q = 0; q < ATH9K_NUM_TX_QUEUES; q++)
-   if (ah->txq[q].tqi_type ==
-   ATH9K_TX_QUEUE_INACTIVE)
-   break;
-   if (q == ATH9K_NUM_TX_QUEUES) {
-   ath_err(common, "No available TX queue\n");
-   return -1;
-   }
+   q = qinfo->tqi_subtype;
break;
default:
ath_err(common, "Invalid TX queue type: %u\n", type);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 06/44] swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Stefano Stabellini 

commit 2c3fc8d26dd09b9d7069687eead849ee81c78e46 upstream.

Need to pass the pointer within the swiotlb internal buffer to the
swiotlb library, that in the case of xen_unmap_single is dev_addr, not
paddr.

Signed-off-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/xen/swiotlb-xen.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -390,7 +390,7 @@ static void xen_unmap_single(struct devi
 
/* NOTE: We use dev_addr here, not paddr! */
if (is_xen_swiotlb_buffer(dev_addr)) {
-   swiotlb_tbl_unmap_single(hwdev, paddr, size, dir);
+   swiotlb_tbl_unmap_single(hwdev, dev_addr, size, dir);
return;
}
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 05/44] can: peak_usb: fix memset() usage

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Stephane Grosjean 

commit dc50ddcd4c58a5a0226038307d6ef884bec9f8c2 upstream.

This patchs fixes a misplaced call to memset() that fills the request
buffer with 0. The problem was with sending PCAN_USBPRO_REQ_FCT
requests, the content set by the caller was thus lost.

With this patch, the memory area is zeroed only when requesting info
from the device.

Signed-off-by: Stephane Grosjean 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/can/usb/peak_usb/pcan_usb_pro.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
@@ -333,8 +333,6 @@ static int pcan_usb_pro_send_req(struct
if (!(dev->state & PCAN_USB_STATE_CONNECTED))
return 0;
 
-   memset(req_addr, '\0', req_size);
-
req_type = USB_TYPE_VENDOR | USB_RECIP_OTHER;
 
switch (req_id) {
@@ -345,6 +343,7 @@ static int pcan_usb_pro_send_req(struct
default:
p = usb_rcvctrlpipe(dev->udev, 0);
req_type |= USB_DIR_IN;
+   memset(req_addr, '\0', req_size);
break;
}
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 30/44] cdc-acm: memory leak in error case

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Oliver Neukum 

commit d908f8478a8d18e66c80a12adb27764920c1f1ca upstream.

If probe() fails not only the attributes need to be removed
but also the memory freed.

Reported-by: Ahmed Tamrawi 
Signed-off-by: Oliver Neukum 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/class/cdc-acm.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1366,6 +1366,7 @@ alloc_fail8:
_attr_wCountryCodes);
device_remove_file(>control->dev,
_attr_iCountryCodeRelDate);
+   kfree(acm->country_codes);
}
device_remove_file(>control->dev, _attr_bmCapabilities);
 alloc_fail7:


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 27/44] ALSA: hda - Fix wrong gpio_dir & gpio_mask hint setups for IDT/STAC codecs

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Takashi Iwai 

commit c507de88f6a336bd7296c9ec0073b2d4af8b4f5e upstream.

stac_store_hints() does utterly wrong for masking the values for
gpio_dir and gpio_data, likely due to copy errors.  Fortunately,
this feature is used very rarely, so the impact must be really small.

Reported-by: Rasmus Villemoes 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/pci/hda/patch_sigmatel.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -573,9 +573,9 @@ static void stac_store_hints(struct hda_
spec->gpio_mask;
}
if (get_int_hint(codec, "gpio_dir", >gpio_dir))
-   spec->gpio_mask &= spec->gpio_mask;
-   if (get_int_hint(codec, "gpio_data", >gpio_data))
spec->gpio_dir &= spec->gpio_mask;
+   if (get_int_hint(codec, "gpio_data", >gpio_data))
+   spec->gpio_data &= spec->gpio_mask;
if (get_int_hint(codec, "eapd_mask", >eapd_mask))
spec->eapd_mask &= spec->gpio_mask;
if (get_int_hint(codec, "gpio_mute", >gpio_mute))


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 29/44] genhd: check for int overflow in disk_expand_part_tbl()

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Jens Axboe 

commit 5fabcb4c33fe11c7e3afdf805fde26c1a54d0953 upstream.

We can get here from blkdev_ioctl() -> blkpg_ioctl() -> add_partition()
with a user passed in partno value. If we pass in 0x7fff, the
new target in disk_expand_part_tbl() overflows the 'int' and we
access beyond the end of ptbl->part[] and even write to it when we
do the rcu_assign_pointer() to assign the new partition.

Reported-by: David Ramos 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 block/genhd.c |   11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

--- a/block/genhd.c
+++ b/block/genhd.c
@@ -1070,9 +1070,16 @@ int disk_expand_part_tbl(struct gendisk
struct disk_part_tbl *old_ptbl = disk->part_tbl;
struct disk_part_tbl *new_ptbl;
int len = old_ptbl ? old_ptbl->len : 0;
-   int target = partno + 1;
+   int i, target;
size_t size;
-   int i;
+
+   /*
+* check for int overflow, since we can get here from blkpg_ioctl()
+* with a user passed 'partno'.
+*/
+   target = partno + 1;
+   if (target < 0)
+   return -EINVAL;
 
/* disk_max_parts() is zero during initialization, ignore if so */
if (disk_max_parts(disk) && target > disk_max_parts(disk))


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 28/44] USB: cdc-acm: check for valid interfaces

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Greg Kroah-Hartman 

commit 403dff4e2c94f275e24fd85f40b2732ffec268a1 upstream.

We need to check that we have both a valid data and control inteface for both
types of headers (union and not union.)

References: https://bugzilla.kernel.org/show_bug.cgi?id=83551
Reported-by: Simon Schubert <2+ker...@0x2c.org>
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/class/cdc-acm.c |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1087,10 +1087,11 @@ next_desc:
} else {
control_interface = usb_ifnum_to_if(usb_dev, 
union_header->bMasterInterface0);
data_interface = usb_ifnum_to_if(usb_dev, (data_interface_num = 
union_header->bSlaveInterface0));
-   if (!control_interface || !data_interface) {
-   dev_dbg(>dev, "no interfaces\n");
-   return -ENODEV;
-   }
+   }
+
+   if (!control_interface || !data_interface) {
+   dev_dbg(>dev, "no interfaces\n");
+   return -ENODEV;
}
 
if (data_interface_num != call_interface_num)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 26/44] ALSA: hda - using uninitialized data

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Dan Carpenter 

commit 69eba10e606a80665f8573221fec589430d9d1cb upstream.

In olden times the snd_hda_param_read() function always set "*start_id"
but in 2007 we introduced a new return and it causes uninitialized data
bugs in a couple of the callers: print_codec_info() and
hdmi_parse_codec().

Fixes: e8a7f136f5ed ('[ALSA] hda-intel - Improve HD-audio codec probing 
robustness')
Signed-off-by: Dan Carpenter 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/pci/hda/hda_codec.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -327,8 +327,10 @@ int snd_hda_get_sub_nodes(struct hda_cod
unsigned int parm;
 
parm = snd_hda_param_read(codec, nid, AC_PAR_NODE_COUNT);
-   if (parm == -1)
+   if (parm == -1) {
+   *start_id = 0;
return 0;
+   }
*start_id = (parm >> 16) & 0x7fff;
return (int)(parm & 0x7fff);
 }


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 31/44] writeback: fix a subtle race condition in I_DIRTY clearing

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Tejun Heo 

commit 9c6ac78eb3521c5937b2dd8a7d1b300f41092f45 upstream.

After invoking ->dirty_inode(), __mark_inode_dirty() does smp_mb() and
tests inode->i_state locklessly to see whether it already has all the
necessary I_DIRTY bits set.  The comment above the barrier doesn't
contain any useful information - memory barriers can't ensure "changes
are seen by all cpus" by itself.

And it sure enough was broken.  Please consider the following
scenario.

 CPU 0  CPU 1
 ---

enters __writeback_single_inode()
grabs inode->i_lock
tests PAGECACHE_TAG_DIRTY which is clear
 enters __set_page_dirty()
 grabs mapping->tree_lock
 sets PAGECACHE_TAG_DIRTY
 releases mapping->tree_lock
 leaves __set_page_dirty()

 enters __mark_inode_dirty()
 smp_mb()
 sees I_DIRTY_PAGES set
 leaves __mark_inode_dirty()
clears I_DIRTY_PAGES
releases inode->i_lock

Now @inode has dirty pages w/ I_DIRTY_PAGES clear.  This doesn't seem
to lead to an immediately critical problem because requeue_inode()
later checks PAGECACHE_TAG_DIRTY instead of I_DIRTY_PAGES when
deciding whether the inode needs to be requeued for IO and there are
enough unintentional memory barriers inbetween, so while the inode
ends up with inconsistent I_DIRTY_PAGES flag, it doesn't fall off the
IO list.

The lack of explicit barrier may also theoretically affect the other
I_DIRTY bits which deal with metadata dirtiness.  There is no
guarantee that a strong enough barrier exists between
I_DIRTY_[DATA]SYNC clearing and write_inode() writing out the dirtied
inode.  Filesystem inode writeout path likely has enough stuff which
can behave as full barrier but it's theoretically possible that the
writeout may not see all the updates from ->dirty_inode().

Fix it by adding an explicit smp_mb() after I_DIRTY clearing.  Note
that I_DIRTY_PAGES needs a special treatment as it always needs to be
cleared to be interlocked with the lockless test on
__mark_inode_dirty() side.  It's cleared unconditionally and
reinstated after smp_mb() if the mapping still has dirty pages.

Also add comments explaining how and why the barriers are paired.

Lightly tested.

Signed-off-by: Tejun Heo 
Cc: Jan Kara 
Cc: Mikulas Patocka 
Cc: Jens Axboe 
Cc: Al Viro 
Reviewed-by: Jan Kara 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/fs-writeback.c |   29 ++---
 1 file changed, 22 insertions(+), 7 deletions(-)

--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -470,12 +470,28 @@ __writeback_single_inode(struct inode *i
 * write_inode()
 */
spin_lock(>i_lock);
-   /* Clear I_DIRTY_PAGES if we've written out all dirty pages */
-   if (!mapping_tagged(mapping, PAGECACHE_TAG_DIRTY))
-   inode->i_state &= ~I_DIRTY_PAGES;
+
dirty = inode->i_state & I_DIRTY;
-   inode->i_state &= ~(I_DIRTY_SYNC | I_DIRTY_DATASYNC);
+   inode->i_state &= ~I_DIRTY;
+
+   /*
+* Paired with smp_mb() in __mark_inode_dirty().  This allows
+* __mark_inode_dirty() to test i_state without grabbing i_lock -
+* either they see the I_DIRTY bits cleared or we see the dirtied
+* inode.
+*
+* I_DIRTY_PAGES is always cleared together above even if @mapping
+* still has dirty pages.  The flag is reinstated after smp_mb() if
+* necessary.  This guarantees that either __mark_inode_dirty()
+* sees clear I_DIRTY_PAGES or we see PAGECACHE_TAG_DIRTY.
+*/
+   smp_mb();
+
+   if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY))
+   inode->i_state |= I_DIRTY_PAGES;
+
spin_unlock(>i_lock);
+
/* Don't write the inode if only I_DIRTY_PAGES was set */
if (dirty & (I_DIRTY_SYNC | I_DIRTY_DATASYNC)) {
int err = write_inode(inode, wbc);
@@ -1146,12 +1162,11 @@ void __mark_inode_dirty(struct inode *in
}
 
/*
-* make sure that changes are seen by all cpus before we test i_state
-* -- mikulas
+* Paired with smp_mb() in __writeback_single_inode() for the
+* following lockless i_state test.  See there for details.
 */
smp_mb();
 
-   /* avoid the locking if we can */
if ((inode->i_state & flags) == flags)
return;
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 34/44] nfsd4: fix xdr4 inclusion of escaped char

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Benjamin Coddington 

commit 5a64e56976f1ba98743e1678c0029a98e9034c81 upstream.

Fix a bug where nfsd4_encode_components_esc() includes the esc_end char as
an additional string encoding.

Signed-off-by: Benjamin Coddington 
Fixes: e7a0444aef4a "nfsd: add IPv6 addr escaping to fs_location hosts"
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/nfsd/nfs4xdr.c |3 +++
 1 file changed, 3 insertions(+)

--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -1743,6 +1743,9 @@ static __be32 nfsd4_encode_components_es
}
else
end++;
+   if (found_esc)
+   end = next;
+
str = end;
}
*pp = p;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 36/44] scripts/kernel-doc: dont eat struct members with __aligned

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Johannes Berg 

commit 7b990789a4c3420fa57596b368733158e432d444 upstream.

The change from \d+ to .+ inside __aligned() means that the following
structure:

  struct test {
u8 a __aligned(2);
u8 b __aligned(2);
  };

essentially gets modified to

  struct test {
u8 a;
  };

for purposes of kernel-doc, thus dropping a struct member, which in
turns causes warnings and invalid kernel-doc generation.

Fix this by replacing the catch-all (".") with anything that's not a
semicolon ("[^;]").

Fixes: 9dc30918b23f ("scripts/kernel-doc: handle struct member __aligned 
without numbers")
Signed-off-by: Johannes Berg 
Cc: Nishanth Menon 
Cc: Randy Dunlap 
Cc: Michal Marek 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 scripts/kernel-doc |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -1750,7 +1750,7 @@ sub dump_struct($$) {
# strip kmemcheck_bitfield_{begin,end}.*;
$members =~ s/kmemcheck_bitfield_.*?;//gos;
# strip attributes
-   $members =~ s/__aligned\s*\(.+\)//gos;
+   $members =~ s/__aligned\s*\([^;]*\)//gos;
 
create_parameterlist($members, ';', $file);
check_sections($file, $declaration_name, "struct", $sectcheck, 
$struct_actual, $nested);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 37/44] ARM: mvebu: disable I/O coherency on non-SMP situations on Armada 370/375/38x/XP

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Petazzoni 

commit e55355453600a33bb5ca4f71f2d7214875f3b061 upstream.

Enabling the hardware I/O coherency on Armada 370, Armada 375, Armada
38x and Armada XP requires a certain number of conditions:

 - On Armada 370, the cache policy must be set to write-allocate.

 - On Armada 375, 38x and XP, the cache policy must be set to
   write-allocate, the pages must be mapped with the shareable
   attribute, and the SMP bit must be set

Currently, on Armada XP, when CONFIG_SMP is enabled, those conditions
are met. However, when Armada XP is used in a !CONFIG_SMP kernel, none
of these conditions are met. With Armada 370, the situation is worse:
since the processor is single core, regardless of whether CONFIG_SMP
or !CONFIG_SMP is used, the cache policy will be set to write-back by
the kernel and not write-allocate.

Since solving this problem turns out to be quite complicated, and we
don't want to let users with a mainline kernel known to have
infrequent but existing data corruptions, this commit proposes to
simply disable hardware I/O coherency in situations where it is known
not to work.

And basically, the is_smp() function of the kernel tells us whether it
is OK to enable hardware I/O coherency or not, so this commit slightly
refactors the coherency_type() function to return
COHERENCY_FABRIC_TYPE_NONE when is_smp() is false, or the appropriate
type of the coherency fabric in the other case.

Thanks to this, the I/O coherency fabric will no longer be used at all
in !CONFIG_SMP configurations. It will continue to be used in
CONFIG_SMP configurations on Armada XP, Armada 375 and Armada 38x
(which are multiple cores processors), but will no longer be used on
Armada 370 (which is a single core processor).

In the process, it simplifies the implementation of the
coherency_type() function, and adds a missing call to of_node_put().

Signed-off-by: Thomas Petazzoni 
Fixes: e60304f8cb7bb545e79fe62d9b9762460c254ec2 ("arm: mvebu: Add hardware I/O 
Coherency support")
Cc:  # v3.8+
Acked-by: Gregory CLEMENT 
Link: 
https://lkml.kernel.org/r/1415871540-20302-3-git-send-email-thomas.petazz...@free-electrons.com
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/mach-mvebu/coherency.c |   23 +++
 1 file changed, 23 insertions(+)

--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -141,6 +141,29 @@ int __init coherency_init(void)
 {
struct device_node *np;
 
+   /*
+* The coherency fabric is needed:
+* - For coherency between processors on Armada XP, so only
+*   when SMP is enabled.
+* - For coherency between the processor and I/O devices, but
+*   this coherency requires many pre-requisites (write
+*   allocate cache policy, shareable pages, SMP bit set) that
+*   are only meant in SMP situations.
+*
+* Note that this means that on Armada 370, there is currently
+* no way to use hardware I/O coherency, because even when
+* CONFIG_SMP is enabled, is_smp() returns false due to the
+* Armada 370 being a single-core processor. To lift this
+* limitation, we would have to find a way to make the cache
+* policy set to write-allocate (on all Armada SoCs), and to
+* set the shareable attribute in page tables (on all Armada
+* SoCs except the Armada 370). Unfortunately, such decisions
+* are taken very early in the kernel boot process, at a point
+* where we don't know yet on which SoC we are running.
+*/
+   if (!is_smp())
+   return 0;
+
np = of_find_matching_node(NULL, of_coherency_table);
if (np) {
pr_info("Initializing Coherency fabric\n");


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 39/44] perf/x86/intel/uncore: Make sure only uncore events are collected

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Jiri Olsa 

commit af91568e762d04931dcbdd6bef4655433d8b9418 upstream.

The uncore_collect_events functions assumes that event group
might contain only uncore events which is wrong, because it
might contain any type of events.

This bug leads to uncore framework touching 'not' uncore events,
which could end up all sorts of bugs.

One was triggered by Vince's perf fuzzer, when the uncore code
touched breakpoint event private event space as if it was uncore
event and caused BUG:

   BUG: unable to handle kernel paging request at 82822068
   IP: [] uncore_assign_events+0x188/0x250
   ...

The code in uncore_assign_events() function was looking for
event->hw.idx data while the event was initialized as a
breakpoint with different members in event->hw union.

This patch forces uncore_collect_events() to collect only uncore
events.

Reported-by: Vince Weaver 
Signed-off-by: Jiri Olsa 
Cc: Arnaldo Carvalho de Melo 
Cc: Frederic Weisbecker 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Yan, Zheng 
Link: 
http://lkml.kernel.org/r/1418243031-20367-2-git-send-email-jo...@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/cpu/perf_event_intel_uncore.c |   22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -2657,6 +2657,17 @@ static struct intel_uncore_box *uncore_e
return uncore_pmu_to_box(uncore_event_to_pmu(event), 
smp_processor_id());
 }
 
+/*
+ * Using uncore_pmu_event_init pmu event_init callback
+ * as a detection point for uncore events.
+ */
+static int uncore_pmu_event_init(struct perf_event *event);
+
+static bool is_uncore_event(struct perf_event *event)
+{
+   return event->pmu->event_init == uncore_pmu_event_init;
+}
+
 static int
 uncore_collect_events(struct intel_uncore_box *box, struct perf_event *leader, 
bool dogrp)
 {
@@ -2671,13 +2682,18 @@ uncore_collect_events(struct intel_uncor
return -EINVAL;
 
n = box->n_events;
-   box->event_list[n] = leader;
-   n++;
+
+   if (is_uncore_event(leader)) {
+   box->event_list[n] = leader;
+   n++;
+   }
+
if (!dogrp)
return n;
 
list_for_each_entry(event, >sibling_list, group_entry) {
-   if (event->state <= PERF_EVENT_STATE_OFF)
+   if (!is_uncore_event(event) ||
+   event->state <= PERF_EVENT_STATE_OFF)
continue;
 
if (n >= max_count)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [alsa-devel] unload Audio drivers while playback stream is active case kernel crash

2015-01-13 Thread Takashi Iwai
At Tue, 13 Jan 2015 21:54:12 +,
Mark Brown wrote:
> 
> On Tue, Jan 13, 2015 at 06:24:44PM +0100, Takashi Iwai wrote:
> > Wang, Jiada (ESD) wrote:
> 
> > > I am using i.MX6Q sabreSD board, which have imx_wm892 machine driver, 
> > > wm8962 codec and SSI CPU DAI,
> 
> > > I got Kernel crash when unloading audio drivers (playback stream is 
> > > active)
> > > modprobe -r snd_soc_imx_wm8962
> > > modprobe -r snd_soc_fsl_ssi
> > > modprobe -r snd_soc_wm8962
> 
> > The root problem is that you can unload the module while playing.
> > The corresponding module refcounts should have been increased during
> > used.
> 
> > Do we miss [try_]module_get() somewhere in ASoC?
> 
> That doesn't help, users can still forcibly unbind the driver at runtime
> without loading the module - and there's always the potential for
> actually hotpluggable hardware.  The teardown paths should be able to
> cope somewhat gracefully.

The module refcount has to be handled while being used for stopping
module unload.  That's irrelevant from the dynamic unbinding support
itself.  Of course, the module refcount doesn't save the world, but
it's the right fix for this particular scenario.


Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 38/44] Btrfs: dont delay inode ref updates during log replay

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Chris Mason 

commit 6f8960541b1eb6054a642da48daae2320fddba93 upstream.

Commit 1d52c78afbb (Btrfs: try not to ENOSPC on log replay) added a
check to skip delayed inode updates during log replay because it
confuses the enospc code.  But the delayed processing will end up
ignoring delayed refs from log replay because the inode itself wasn't
put through the delayed code.

This can end up triggering a warning at commit time:

WARNING: CPU: 2 PID: 778 at fs/btrfs/delayed-inode.c:1410 
btrfs_assert_delayed_root_empty+0x32/0x34()

Which is repeated for each commit because we never process the delayed
inode ref update.

The fix used here is to change btrfs_delayed_delete_inode_ref to return
an error if we're currently in log replay.  The caller will do the ref
deletion immediately and everything will work properly.

Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/btrfs/delayed-inode.c |8 
 1 file changed, 8 insertions(+)

--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -1843,6 +1843,14 @@ int btrfs_delayed_update_inode(struct bt
struct btrfs_delayed_node *delayed_node;
int ret = 0;
 
+   /*
+* we don't do delayed inode updates during log recovery because it
+* leads to enospc problems.  This means we also can't do
+* delayed inode refs
+*/
+   if (BTRFS_I(inode)->root->fs_info->log_root_recovering)
+   return -EAGAIN;
+
delayed_node = btrfs_get_or_create_delayed_node(inode);
if (IS_ERR(delayed_node))
return PTR_ERR(delayed_node);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 40/44] perf: Fix events installation during moving group

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Jiri Olsa 

commit 9fc81d87420d0d3fd62d5e5529972c0ad9eab9cc upstream.

We allow PMU driver to change the cpu on which the event
should be installed to. This happened in patch:

  e2d37cd213dc ("perf: Allow the PMU driver to choose the CPU on which to 
install events")

This patch also forces all the group members to follow
the currently opened events cpu if the group happened
to be moved.

This and the change of event->cpu in perf_install_in_context()
function introduced in:

  0cda4c023132 ("perf: Introduce perf_pmu_migrate_context()")

forces group members to change their event->cpu,
if the currently-opened-event's PMU changed the cpu
and there is a group move.

Above behaviour causes problem for breakpoint events,
which uses event->cpu to touch cpu specific data for
breakpoints accounting. By changing event->cpu, some
breakpoints slots were wrongly accounted for given
cpu.

Vinces's perf fuzzer hit this issue and caused following
WARN on my setup:

   WARNING: CPU: 0 PID: 20214 at arch/x86/kernel/hw_breakpoint.c:119 
arch_install_hw_breakpoint+0x142/0x150()
   Can't find any breakpoint slot
   [...]

This patch changes the group moving code to keep the event's
original cpu.

Reported-by: Vince Weaver 
Signed-off-by: Jiri Olsa 
Cc: Arnaldo Carvalho de Melo 
Cc: Frederic Weisbecker 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Vince Weaver 
Cc: Yan, Zheng 
Link: 
http://lkml.kernel.org/r/1418243031-20367-3-git-send-email-jo...@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/events/core.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6887,11 +6887,11 @@ SYSCALL_DEFINE5(perf_event_open,
 
if (move_group) {
synchronize_rcu();
-   perf_install_in_context(ctx, group_leader, event->cpu);
+   perf_install_in_context(ctx, group_leader, group_leader->cpu);
get_ctx(ctx);
list_for_each_entry(sibling, _leader->sibling_list,
group_entry) {
-   perf_install_in_context(ctx, sibling, event->cpu);
+   perf_install_in_context(ctx, sibling, sibling->cpu);
get_ctx(ctx);
}
}


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 42/44] mm, vmscan: prevent kswapd livelock due to pfmemalloc-throttled process being killed

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Vlastimil Babka 

commit 9e5e3661727eaf960d3480213f8e87c8d67b6956 upstream.

Charles Shirron and Paul Cassella from Cray Inc have reported kswapd
stuck in a busy loop with nothing left to balance, but
kswapd_try_to_sleep() failing to sleep.  Their analysis found the cause
to be a combination of several factors:

1. A process is waiting in throttle_direct_reclaim() on pgdat->pfmemalloc_wait

2. The process has been killed (by OOM in this case), but has not yet been
   scheduled to remove itself from the waitqueue and die.

3. kswapd checks for throttled processes in prepare_kswapd_sleep():

if (waitqueue_active(>pfmemalloc_wait)) {
wake_up(>pfmemalloc_wait);
return false; // kswapd will not go to sleep
}

   However, for a process that was already killed, wake_up() does not remove
   the process from the waitqueue, since try_to_wake_up() checks its state
   first and returns false when the process is no longer waiting.

4. kswapd is running on the same CPU as the only CPU that the process is
   allowed to run on (through cpus_allowed, or possibly single-cpu system).

5. CONFIG_PREEMPT_NONE=y kernel is used. If there's nothing to balance, kswapd
   encounters no voluntary preemption points and repeatedly fails
   prepare_kswapd_sleep(), blocking the process from running and removing
   itself from the waitqueue, which would let kswapd sleep.

So, the source of the problem is that we prevent kswapd from going to
sleep until there are processes waiting on the pfmemalloc_wait queue,
and a process waiting on a queue is guaranteed to be removed from the
queue only when it gets scheduled.  This was done to make sure that no
process is left sleeping on pfmemalloc_wait when kswapd itself goes to
sleep.

However, it isn't necessary to postpone kswapd sleep until the
pfmemalloc_wait queue actually empties.  To prevent processes from being
left sleeping, it's actually enough to guarantee that all processes
waiting on pfmemalloc_wait queue have been woken up by the time we put
kswapd to sleep.

This patch therefore fixes this issue by substituting 'wake_up' with
'wake_up_all' and removing 'return false' in the code snippet from
prepare_kswapd_sleep() above.  Note that if any process puts itself in
the queue after this waitqueue_active() check, or after the wake up
itself, it means that the process will also wake up kswapd - and since
we are under prepare_to_wait(), the wake up won't be missed.  Also we
update the comment prepare_kswapd_sleep() to hopefully more clearly
describe the races it is preventing.

Fixes: 5515061d22f0 ("mm: throttle direct reclaimers if PF_MEMALLOC reserves 
are low and swap is backed by network storage")
Signed-off-by: Vlastimil Babka 
Signed-off-by: Vladimir Davydov 
Cc: Mel Gorman 
Cc: Johannes Weiner 
Acked-by: Michal Hocko 
Acked-by: Rik van Riel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 mm/vmscan.c |   24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2631,18 +2631,20 @@ static bool prepare_kswapd_sleep(pg_data
return false;
 
/*
-* There is a potential race between when kswapd checks its watermarks
-* and a process gets throttled. There is also a potential race if
-* processes get throttled, kswapd wakes, a large process exits therby
-* balancing the zones that causes kswapd to miss a wakeup. If kswapd
-* is going to sleep, no process should be sleeping on pfmemalloc_wait
-* so wake them now if necessary. If necessary, processes will wake
-* kswapd and get throttled again
+* The throttled processes are normally woken up in balance_pgdat() as
+* soon as pfmemalloc_watermark_ok() is true. But there is a potential
+* race between when kswapd checks the watermarks and a process gets
+* throttled. There is also a potential race if processes get
+* throttled, kswapd wakes, a large process exits thereby balancing the
+* zones, which causes kswapd to exit balance_pgdat() before reaching
+* the wake up checks. If kswapd is going to sleep, no process should
+* be sleeping on pfmemalloc_wait, so wake them now if necessary. If
+* the wake up is premature, processes will wake kswapd and get
+* throttled again. The difference from wake ups in balance_pgdat() is
+* that here we are under prepare_to_wait().
 */
-   if (waitqueue_active(>pfmemalloc_wait)) {
-   wake_up(>pfmemalloc_wait);
-   return false;
-   }
+   if (waitqueue_active(>pfmemalloc_wait))
+   wake_up_all(>pfmemalloc_wait);
 
return pgdat_balanced(pgdat, order, classzone_idx);
 }


--
To unsubscribe from this list: send the line 

[PATCH 3.10 35/44] nilfs2: fix the nilfs_iget() vs. nilfs_new_inode() races

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Ryusuke Konishi 

commit 705304a863cc41585508c0f476f6d3ec28cf7e00 upstream.

Same story as in commit 41080b5a2401 ("nfsd race fixes: ext2") (similar
ext2 fix) except that nilfs2 needs to use insert_inode_locked4() instead
of insert_inode_locked() and a bug of a check for dead inodes needs to
be fixed.

If nilfs_iget() is called from nfsd after nilfs_new_inode() calls
insert_inode_locked4(), nilfs_iget() will wait for unlock_new_inode() at
the end of nilfs_mkdir()/nilfs_create()/etc to unlock the inode.

If nilfs_iget() is called before nilfs_new_inode() calls
insert_inode_locked4(), it will create an in-core inode and read its
data from the on-disk inode.  But, nilfs_iget() will find i_nlink equals
zero and fail at nilfs_read_inode_common(), which will lead it to call
iget_failed() and cleanly fail.

However, this sanity check doesn't work as expected for reused on-disk
inodes because they leave a non-zero value in i_mode field and it
hinders the test of i_nlink.  This patch also fixes the issue by
removing the test on i_mode that nilfs2 doesn't need.

Signed-off-by: Ryusuke Konishi 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/nilfs2/inode.c |   32 
 fs/nilfs2/namei.c |   15 ---
 2 files changed, 36 insertions(+), 11 deletions(-)

--- a/fs/nilfs2/inode.c
+++ b/fs/nilfs2/inode.c
@@ -49,6 +49,8 @@ struct nilfs_iget_args {
int for_gc;
 };
 
+static int nilfs_iget_test(struct inode *inode, void *opaque);
+
 void nilfs_inode_add_blocks(struct inode *inode, int n)
 {
struct nilfs_root *root = NILFS_I(inode)->i_root;
@@ -347,6 +349,17 @@ const struct address_space_operations ni
.is_partially_uptodate  = block_is_partially_uptodate,
 };
 
+static int nilfs_insert_inode_locked(struct inode *inode,
+struct nilfs_root *root,
+unsigned long ino)
+{
+   struct nilfs_iget_args args = {
+   .ino = ino, .root = root, .cno = 0, .for_gc = 0
+   };
+
+   return insert_inode_locked4(inode, ino, nilfs_iget_test, );
+}
+
 struct inode *nilfs_new_inode(struct inode *dir, umode_t mode)
 {
struct super_block *sb = dir->i_sb;
@@ -382,7 +395,7 @@ struct inode *nilfs_new_inode(struct ino
if (S_ISREG(mode) || S_ISDIR(mode) || S_ISLNK(mode)) {
err = nilfs_bmap_read(ii->i_bmap, NULL);
if (err < 0)
-   goto failed_bmap;
+   goto failed_after_creation;
 
set_bit(NILFS_I_BMAP, >i_state);
/* No lock is needed; iget() ensures it. */
@@ -398,21 +411,24 @@ struct inode *nilfs_new_inode(struct ino
spin_lock(>ns_next_gen_lock);
inode->i_generation = nilfs->ns_next_generation++;
spin_unlock(>ns_next_gen_lock);
-   insert_inode_hash(inode);
+   if (nilfs_insert_inode_locked(inode, root, ino) < 0) {
+   err = -EIO;
+   goto failed_after_creation;
+   }
 
err = nilfs_init_acl(inode, dir);
if (unlikely(err))
-   goto failed_acl; /* never occur. When supporting
+   goto failed_after_creation; /* never occur. When supporting
nilfs_init_acl(), proper cancellation of
above jobs should be considered */
 
return inode;
 
- failed_acl:
- failed_bmap:
+ failed_after_creation:
clear_nlink(inode);
+   unlock_new_inode(inode);
iput(inode);  /* raw_inode will be deleted through
-generic_delete_inode() */
+nilfs_evict_inode() */
goto failed;
 
  failed_ifile_create_inode:
@@ -460,8 +476,8 @@ int nilfs_read_inode_common(struct inode
inode->i_atime.tv_nsec = le32_to_cpu(raw_inode->i_mtime_nsec);
inode->i_ctime.tv_nsec = le32_to_cpu(raw_inode->i_ctime_nsec);
inode->i_mtime.tv_nsec = le32_to_cpu(raw_inode->i_mtime_nsec);
-   if (inode->i_nlink == 0 && inode->i_mode == 0)
-   return -EINVAL; /* this inode is deleted */
+   if (inode->i_nlink == 0)
+   return -ESTALE; /* this inode is deleted */
 
inode->i_blocks = le64_to_cpu(raw_inode->i_blocks);
ii->i_flags = le32_to_cpu(raw_inode->i_flags);
--- a/fs/nilfs2/namei.c
+++ b/fs/nilfs2/namei.c
@@ -51,9 +51,11 @@ static inline int nilfs_add_nondir(struc
int err = nilfs_add_link(dentry, inode);
if (!err) {
d_instantiate(dentry, inode);
+   unlock_new_inode(inode);
return 0;
}
inode_dec_link_count(inode);
+   unlock_new_inode(inode);
iput(inode);
return err;
 }
@@ -182,6 +184,7 @@ out:
 out_fail:
drop_nlink(inode);

[PATCH 3.10 44/44] mm: Dont count the stack guard page towards RLIMIT_STACK

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Linus Torvalds 

commit 690eac53daff34169a4d74fc7bfbd388c4896abb upstream.

Commit fee7e49d4514 ("mm: propagate error from stack expansion even for
guard page") made sure that we return the error properly for stack
growth conditions.  It also theorized that counting the guard page
towards the stack limit might break something, but also said "Let's see
if anybody notices".

Somebody did notice.  Apparently android-x86 sets the stack limit very
close to the limit indeed, and including the guard page in the rlimit
check causes the android 'zygote' process problems.

So this adds the (fairly trivial) code to make the stack rlimit check be
against the actual real stack size, rather than the size of the vma that
includes the guard page.

Reported-and-tested-by: Chih-Wei Huang 
Cc: Jay Foad 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 mm/mmap.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2056,14 +2056,17 @@ static int acct_stack_growth(struct vm_a
 {
struct mm_struct *mm = vma->vm_mm;
struct rlimit *rlim = current->signal->rlim;
-   unsigned long new_start;
+   unsigned long new_start, actual_size;
 
/* address space limit tests */
if (!may_expand_vm(mm, grow))
return -ENOMEM;
 
/* Stack limit test */
-   if (size > ACCESS_ONCE(rlim[RLIMIT_STACK].rlim_cur))
+   actual_size = size;
+   if (size && (vma->vm_flags & (VM_GROWSUP | VM_GROWSDOWN)))
+   actual_size -= PAGE_SIZE;
+   if (actual_size > ACCESS_ONCE(rlim[RLIMIT_STACK].rlim_cur))
return -ENOMEM;
 
/* mlock limit tests */


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 19/44] HID: roccat: potential out of bounds in pyra_sysfs_write_settings()

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Dan Carpenter 

commit 606185b20caf4c57d7e41e5a5ea4aff460aef2ab upstream.

This is a static checker fix.  We write some binary settings to the
sysfs file.  One of the settings is the "->startup_profile".  There
isn't any checking to make sure it fits into the
pyra->profile_settings[] array in the profile_activated() function.

I added a check to pyra_sysfs_write_settings() in both places because
I wasn't positive that the other callers were correct.

Signed-off-by: Dan Carpenter 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hid/hid-roccat-pyra.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/hid/hid-roccat-pyra.c
+++ b/drivers/hid/hid-roccat-pyra.c
@@ -35,6 +35,8 @@ static struct class *pyra_class;
 static void profile_activated(struct pyra_device *pyra,
unsigned int new_profile)
 {
+   if (new_profile >= ARRAY_SIZE(pyra->profile_settings))
+   return;
pyra->actual_profile = new_profile;
pyra->actual_cpi = pyra->profile_settings[pyra->actual_profile].y_cpi;
 }
@@ -236,9 +238,11 @@ static ssize_t pyra_sysfs_write_settings
if (off != 0 || count != PYRA_SIZE_SETTINGS)
return -EINVAL;
 
-   mutex_lock(>pyra_lock);
-
settings = (struct pyra_settings const *)buf;
+   if (settings->startup_profile >= ARRAY_SIZE(pyra->profile_settings))
+   return -EINVAL;
+
+   mutex_lock(>pyra_lock);
 
retval = pyra_set_settings(usb_dev, settings);
if (retval) {


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 43/44] mm: propagate error from stack expansion even for guard page

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Linus Torvalds 

commit fee7e49d45149fba60156f5b59014f764d3e3728 upstream.

Jay Foad reports that the address sanitizer test (asan) sometimes gets
confused by a stack pointer that ends up being outside the stack vma
that is reported by /proc/maps.

This happens due to an interaction between RLIMIT_STACK and the guard
page: when we do the guard page check, we ignore the potential error
from the stack expansion, which effectively results in a missing guard
page, since the expected stack expansion won't have been done.

And since /proc/maps explicitly ignores the guard page (commit
d7824370e263: "mm: fix up some user-visible effects of the stack guard
page"), the stack pointer ends up being outside the reported stack area.

This is the minimal patch: it just propagates the error.  It also
effectively makes the guard page part of the stack limit, which in turn
measn that the actual real stack is one page less than the stack limit.

Let's see if anybody notices.  We could teach acct_stack_growth() to
allow an extra page for a grow-up/grow-down stack in the rlimit test,
but I don't want to add more complexity if it isn't needed.

Reported-and-tested-by: Jay Foad 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 include/linux/mm.h |2 +-
 mm/memory.c|4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1630,7 +1630,7 @@ extern int expand_downwards(struct vm_ar
 #if VM_GROWSUP
 extern int expand_upwards(struct vm_area_struct *vma, unsigned long address);
 #else
-  #define expand_upwards(vma, address) do { } while (0)
+  #define expand_upwards(vma, address) (0)
 #endif
 
 /* Look up the first VMA which satisfies  addr < vm_end,  NULL if none. */
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3200,7 +3200,7 @@ static inline int check_stack_guard_page
if (prev && prev->vm_end == address)
return prev->vm_flags & VM_GROWSDOWN ? 0 : -ENOMEM;
 
-   expand_downwards(vma, address - PAGE_SIZE);
+   return expand_downwards(vma, address - PAGE_SIZE);
}
if ((vma->vm_flags & VM_GROWSUP) && address + PAGE_SIZE == vma->vm_end) 
{
struct vm_area_struct *next = vma->vm_next;
@@ -3209,7 +3209,7 @@ static inline int check_stack_guard_page
if (next && next->vm_start == address + PAGE_SIZE)
return next->vm_flags & VM_GROWSUP ? 0 : -ENOMEM;
 
-   expand_upwards(vma, address + PAGE_SIZE);
+   return expand_upwards(vma, address + PAGE_SIZE);
}
return 0;
 }


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.18 115/150] sched: Add missing rcu protection to wake_up_all_idle_cpus

2015-01-13 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Andy Lutomirski 

commit fd7de1e8d5b2b2b35e71332fafb899f584597150 upstream.

Locklessly doing is_idle_task(rq->curr) is only okay because of
RCU protection.  The older variant of the broken code checked
rq->curr == rq->idle instead and therefore didn't need RCU.

Fixes: f6be8af1c95d ("sched: Add new API wake_up_if_idle() to wake up the idle 
cpu")
Signed-off-by: Andy Lutomirski 
Reviewed-by: Chuansheng Liu 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/729365dddca178506dfd0a9451006344cd6808bc.1417277372.git.l...@amacapital.net
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/sched/core.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1623,8 +1623,10 @@ void wake_up_if_idle(int cpu)
struct rq *rq = cpu_rq(cpu);
unsigned long flags;
 
-   if (!is_idle_task(rq->curr))
-   return;
+   rcu_read_lock();
+
+   if (!is_idle_task(rcu_dereference(rq->curr)))
+   goto out;
 
if (set_nr_if_polling(rq->idle)) {
trace_sched_wake_idle_without_ipi(cpu);
@@ -1635,6 +1637,9 @@ void wake_up_if_idle(int cpu)
/* Else cpu is not in idle, do nothing here */
raw_spin_unlock_irqrestore(>lock, flags);
}
+
+out:
+   rcu_read_unlock();
 }
 
 bool cpus_share_cache(int this_cpu, int that_cpu)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 22/44] x86_64, vdso: Fix the vdso address randomization algorithm

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Andy Lutomirski 

commit 394f56fe480140877304d342dec46d50dc823d46 upstream.

The theory behind vdso randomization is that it's mapped at a random
offset above the top of the stack.  To avoid wasting a page of
memory for an extra page table, the vdso isn't supposed to extend
past the lowest PMD into which it can fit.  Other than that, the
address should be a uniformly distributed address that meets all of
the alignment requirements.

The current algorithm is buggy: the vdso has about a 50% probability
of being at the very end of a PMD.  The current algorithm also has a
decent chance of failing outright due to incorrect handling of the
case where the top of the stack is near the top of its PMD.

This fixes the implementation.  The paxtest estimate of vdso
"randomisation" improves from 11 bits to 18 bits.  (Disclaimer: I
don't know what the paxtest code is actually calculating.)

It's worth noting that this algorithm is inherently biased: the vdso
is more likely to end up near the end of its PMD than near the
beginning.  Ideally we would either nix the PMD sharing requirement
or jointly randomize the vdso and the stack to reduce the bias.

In the mean time, this is a considerable improvement with basically
no risk of compatibility issues, since the allowed outputs of the
algorithm are unchanged.

As an easy test, doing this:

for i in `seq 1`
  do grep -P vdso /proc/self/maps |cut -d- -f1
done |sort |uniq -d

used to produce lots of output (1445 lines on my most recent run).
A tiny subset looks like this:

7fffdfffe000
7fffe01fe000
7fffe05fe000
7fffe07fe000
7fffe09fe000
7fffe0bfe000
7fffe0dfe000

Note the suspicious fe000 endings.  With the fix, I get a much more
palatable 76 repeated addresses.

Reviewed-by: Kees Cook 
Signed-off-by: Andy Lutomirski 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/vdso/vma.c |   43 +--
 1 file changed, 29 insertions(+), 14 deletions(-)

--- a/arch/x86/vdso/vma.c
+++ b/arch/x86/vdso/vma.c
@@ -117,30 +117,45 @@ subsys_initcall(init_vdso);
 
 struct linux_binprm;
 
-/* Put the vdso above the (randomized) stack with another randomized offset.
-   This way there is no hole in the middle of address space.
-   To save memory make sure it is still in the same PTE as the stack top.
-   This doesn't give that many random bits */
+/*
+ * Put the vdso above the (randomized) stack with another randomized
+ * offset.  This way there is no hole in the middle of address space.
+ * To save memory make sure it is still in the same PTE as the stack
+ * top.  This doesn't give that many random bits.
+ *
+ * Note that this algorithm is imperfect: the distribution of the vdso
+ * start address within a PMD is biased toward the end.
+ *
+ * Only used for the 64-bit and x32 vdsos.
+ */
 static unsigned long vdso_addr(unsigned long start, unsigned len)
 {
unsigned long addr, end;
unsigned offset;
-   end = (start + PMD_SIZE - 1) & PMD_MASK;
+
+   /*
+* Round up the start address.  It can start out unaligned as a result
+* of stack start randomization.
+*/
+   start = PAGE_ALIGN(start);
+
+   /* Round the lowest possible end address up to a PMD boundary. */
+   end = (start + len + PMD_SIZE - 1) & PMD_MASK;
if (end >= TASK_SIZE_MAX)
end = TASK_SIZE_MAX;
end -= len;
-   /* This loses some more bits than a modulo, but is cheaper */
-   offset = get_random_int() & (PTRS_PER_PTE - 1);
-   addr = start + (offset << PAGE_SHIFT);
-   if (addr >= end)
-   addr = end;
+
+   if (end > start) {
+   offset = get_random_int() % (((end - start) >> PAGE_SHIFT) + 1);
+   addr = start + (offset << PAGE_SHIFT);
+   } else {
+   addr = start;
+   }
 
/*
-* page-align it here so that get_unmapped_area doesn't
-* align it wrongfully again to the next page. addr can come in 4K
-* unaligned here as a result of stack start randomization.
+* Forcibly align the final address in case we have a hardware
+* issue that requires alignment for performance reasons.
 */
-   addr = PAGE_ALIGN(addr);
addr = align_vdso_addr(addr);
 
return addr;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 25/44] ALSA: usb-audio: extend KEF X300A FU 10 tweak to Arcam rPAC

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Jiri Jaburek 

commit d70a1b9893f820fdbcdffac408c909c50f2e6b43 upstream.

The Arcam rPAC seems to have the same problem - whenever anything
(alsamixer, udevd, 3.9+ kernel from 60af3d037eb8c, ..) attempts to
access mixer / control interface of the card, the firmware "locks up"
the entire device, resulting in
  SNDRV_PCM_IOCTL_HW_PARAMS failed (-5): Input/output error
from alsa-lib.

Other operating systems can somehow read the mixer (there seems to be
playback volume/mute), but any manipulation is ignored by the device
(which has hardware volume controls).

Signed-off-by: Jiri Jaburek 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/usb/mixer_maps.c |   15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

--- a/sound/usb/mixer_maps.c
+++ b/sound/usb/mixer_maps.c
@@ -322,8 +322,11 @@ static struct usbmix_name_map hercules_u
{ 0 }   /* terminator */
 };
 
-static const struct usbmix_name_map kef_x300a_map[] = {
-   { 10, NULL }, /* firmware locks up (?) when we try to access this FU */
+/* some (all?) SCMS USB3318 devices are affected by a firmware lock up
+ * when anything attempts to access FU 10 (control)
+ */
+static const struct usbmix_name_map scms_usb3318_map[] = {
+   { 10, NULL },
{ 0 }
 };
 
@@ -415,8 +418,14 @@ static struct usbmix_ctl_map usbmix_ctl_
.map = ebox44_map,
},
{
+   /* KEF X300A */
.id = USB_ID(0x27ac, 0x1000),
-   .map = kef_x300a_map,
+   .map = scms_usb3318_map,
+   },
+   {
+   /* Arcam rPAC */
+   .id = USB_ID(0x25c4, 0x0003),
+   .map = scms_usb3318_map,
},
{ 0 } /* terminator */
 };


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 16/44] iommu/vt-d: Fix an off-by-one bug in __domain_mapping()

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Jiang Liu 

commit cc4f14aa170d895c9a43bdb56f62070c8a6da908 upstream.

There's an off-by-one bug in function __domain_mapping(), which may
trigger the BUG_ON(nr_pages < lvl_pages) when
(nr_pages + 1) & superpage_mask == 0

The issue was introduced by commit 9051aa0268dc "intel-iommu: Combine
domain_pfn_mapping() and domain_sg_mapping()", which sets sg_res to
"nr_pages + 1" to avoid some of the 'sg_res==0' code paths.

It's safe to remove extra "+1" because sg_res is only used to calculate
page size now.

Reported-And-Tested-by: Sudeep Dutt 
Signed-off-by: Jiang Liu 
Acked-By: David Woodhouse 
Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/iommu/intel-iommu.c |8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1796,7 +1796,7 @@ static int __domain_mapping(struct dmar_
struct dma_pte *first_pte = NULL, *pte = NULL;
phys_addr_t uninitialized_var(pteval);
int addr_width = agaw_to_width(domain->agaw) - VTD_PAGE_SHIFT;
-   unsigned long sg_res;
+   unsigned long sg_res = 0;
unsigned int largepage_lvl = 0;
unsigned long lvl_pages = 0;
 
@@ -1807,10 +1807,8 @@ static int __domain_mapping(struct dmar_
 
prot &= DMA_PTE_READ | DMA_PTE_WRITE | DMA_PTE_SNP;
 
-   if (sg)
-   sg_res = 0;
-   else {
-   sg_res = nr_pages + 1;
+   if (!sg) {
+   sg_res = nr_pages;
pteval = ((phys_addr_t)phys_pfn << VTD_PAGE_SHIFT) | prot;
}
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 24/44] driver core: Fix unbalanced device reference in drivers_probe

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Alex Williamson 

commit bb34cb6bbd287b57e955bc5cfd42fcde6aaca279 upstream.

bus_find_device_by_name() acquires a device reference which is never
released.  This results in an object leak, which on older kernels
results in failure to release all resources of PCI devices.  libvirt
uses drivers_probe to re-attach devices to the host after assignment
and is therefore a common trigger for this leak.

Example:

# cd /sys/bus/pci/
# dmesg -C
# echo 1 > devices/\:01\:00.0/sriov_numvfs
# echo 0 > devices/\:01\:00.0/sriov_numvfs
# dmesg | grep 01:10
 pci :01:10.0: [8086:10ca] type 00 class 0x02
 kobject: ':01:10.0' (8801d79cd0a8): kobject_add_internal: parent: 
':00:01.0', set: 'devices'
 kobject: ':01:10.0' (8801d79cd0a8): kobject_uevent_env
 kobject: ':01:10.0' (8801d79cd0a8): fill_kobj_path: path = 
'/devices/pci:00/:00:01.0/:01:10.0'
 kobject: ':01:10.0' (8801d79cd0a8): kobject_uevent_env
 kobject: ':01:10.0' (8801d79cd0a8): fill_kobj_path: path = 
'/devices/pci:00/:00:01.0/:01:10.0'
 kobject: ':01:10.0' (8801d79cd0a8): kobject_uevent_env
 kobject: ':01:10.0' (8801d79cd0a8): fill_kobj_path: path = 
'/devices/pci:00/:00:01.0/:01:10.0'
 kobject: ':01:10.0' (8801d79cd0a8): kobject_cleanup, parent   
(null)
 kobject: ':01:10.0' (8801d79cd0a8): calling ktype release
 kobject: ':01:10.0': free name

[kobject freed as expected]

# dmesg -C
# echo 1 > devices/\:01\:00.0/sriov_numvfs
# echo :01:10.0 > drivers_probe
# echo 0 > devices/\:01\:00.0/sriov_numvfs
# dmesg | grep 01:10
 pci :01:10.0: [8086:10ca] type 00 class 0x02
 kobject: ':01:10.0' (8801d79ce0a8): kobject_add_internal: parent: 
':00:01.0', set: 'devices'
 kobject: ':01:10.0' (8801d79ce0a8): kobject_uevent_env
 kobject: ':01:10.0' (8801d79ce0a8): fill_kobj_path: path = 
'/devices/pci:00/:00:01.0/:01:10.0'
 kobject: ':01:10.0' (8801d79ce0a8): kobject_uevent_env
 kobject: ':01:10.0' (8801d79ce0a8): fill_kobj_path: path = 
'/devices/pci:00/:00:01.0/:01:10.0'
 kobject: ':01:10.0' (8801d79ce0a8): kobject_uevent_env
 kobject: ':01:10.0' (8801d79ce0a8): fill_kobj_path: path = 
'/devices/pci:00/:00:01.0/:01:10.0'

[no free]

Signed-off-by: Alex Williamson 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/base/bus.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -242,13 +242,15 @@ static ssize_t store_drivers_probe(struc
   const char *buf, size_t count)
 {
struct device *dev;
+   int err = -EINVAL;
 
dev = bus_find_device_by_name(bus, NULL, buf);
if (!dev)
return -ENODEV;
-   if (bus_rescan_devices_helper(dev, NULL) != 0)
-   return -EINVAL;
-   return count;
+   if (bus_rescan_devices_helper(dev, NULL) == 0)
+   err = count;
+   put_device(dev);
+   return err;
 }
 
 static struct device *next_device(struct klist_iter *i)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 32/44] serial: samsung: wait for transfer completion before clock disable

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Robert Baldyga 

commit 1ff383a4c3eda8893ec61b02831826e1b1f46b41 upstream.

This patch adds waiting until transmit buffer and shifter will be empty
before clock disabling.

Without this fix it's possible to have clock disabled while data was
not transmited yet, which causes unproper state of TX line and problems
in following data transfers.

Signed-off-by: Robert Baldyga 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/tty/serial/samsung.c |4 
 1 file changed, 4 insertions(+)

--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -534,11 +534,15 @@ static void s3c24xx_serial_pm(struct uar
  unsigned int old)
 {
struct s3c24xx_uart_port *ourport = to_ourport(port);
+   int timeout = 1;
 
ourport->pm_level = level;
 
switch (level) {
case 3:
+   while (--timeout && !s3c24xx_serial_txempty_nofifo(port))
+   udelay(100);
+
if (!IS_ERR(ourport->baudclk))
clk_disable_unprepare(ourport->baudclk);
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 41/44] perf session: Do not fail on processing out of order event

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Jiri Olsa 

commit f61ff6c06dc8f32c7036013ad802c899ec590607 upstream.

Linus reported perf report command being interrupted due to processing
of 'out of order' event, with following error:

  Timestamp below last timeslice flush
  0x5733a8 [0x28]: failed to process type: 3

I could reproduce the issue and in my case it was caused by one CPU
(mmap) being behind during record and userspace mmap reader seeing the
data after other CPUs data were already stored.

This is expected under some circumstances because we need to limit the
number of events that we queue for reordering when we receive a
PERF_RECORD_FINISHED_ROUND or when we force flush due to memory
pressure.

Reported-by: Linus Torvalds 
Signed-off-by: Jiri Olsa 
Acked-by: Ingo Molnar 
Cc: Andi Kleen 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: 
http://lkml.kernel.org/r/1417016371-30249-1-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
[zhangzhiqiang: backport to 3.10:
 - adjust context
 - commit f61ff6c06d struct events_stats was defined in tools/perf/util/event.h
   while 3.10 stable defined in tools/perf/util/hist.h.
 - 3.10 stable there is no pr_oe_time() which used for debug.
 - After the above adjustments, becomes same to the original patch:
   
https://github.com/torvalds/linux/commit/f61ff6c06dc8f32c7036013ad802c899ec590607
]
Signed-off-by: Zhiqiang Zhang 
Signed-off-by: Greg Kroah-Hartman 
---
 tools/perf/util/hist.h|1 +
 tools/perf/util/session.c |5 +++--
 2 files changed, 4 insertions(+), 2 deletions(-)

--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -34,6 +34,7 @@ struct events_stats {
u32 nr_invalid_chains;
u32 nr_unknown_id;
u32 nr_unprocessable_samples;
+   u32 nr_unordered_events;
 };
 
 enum hist_column {
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -656,8 +656,7 @@ static int perf_session_queue_event(stru
return -ETIME;
 
if (timestamp < s->ordered_samples.last_flush) {
-   printf("Warning: Timestamp below last timeslice flush\n");
-   return -EINVAL;
+   s->stats.nr_unordered_events++;
}
 
if (!list_empty(sc)) {
@@ -1057,6 +1056,8 @@ static void perf_session__warn_about_err
"Do you have a KVM guest running and not using 
'perf kvm'?\n",
session->stats.nr_unprocessable_samples);
}
+   if (session->stats.nr_unordered_events != 0)
+   ui__warning("%u out of order events recorded.\n", 
session->stats.nr_unordered_events);
 }
 
 #define session_done() (*(volatile int *)(_done))


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 17/44] HID: i2c-hid: fix race condition reading reports

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Jean-Baptiste Maneyrol 

commit 6296f4a8eb86f9abcc370fb7a1a116b8441c17fd upstream.

Current driver uses a common buffer for reading reports either
synchronously in i2c_hid_get_raw_report() and asynchronously in
the interrupt handler.
There is race condition if an interrupt arrives immediately after
the report is received in i2c_hid_get_raw_report(); the common
buffer is modified by the interrupt handler with the new report
and then i2c_hid_get_raw_report() proceed using wrong data.

Fix it by using a separate buffers for synchronous reports.

Signed-off-by: Jean-Baptiste Maneyrol 
[Antonio Borneo: cleanup, rebase to v3.17, submit mainline]
Signed-off-by: Antonio Borneo 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hid/i2c-hid/i2c-hid.c |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)

--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -134,6 +134,7 @@ struct i2c_hid {
   * descriptor. */
unsigned intbufsize;/* i2c buffer size */
char*inbuf; /* Input buffer */
+   char*rawbuf;/* Raw Input buffer */
char*cmdbuf;/* Command buffer */
char*argsbuf;   /* Command arguments buffer */
 
@@ -471,9 +472,11 @@ static void i2c_hid_find_max_report(stru
 static void i2c_hid_free_buffers(struct i2c_hid *ihid)
 {
kfree(ihid->inbuf);
+   kfree(ihid->rawbuf);
kfree(ihid->argsbuf);
kfree(ihid->cmdbuf);
ihid->inbuf = NULL;
+   ihid->rawbuf = NULL;
ihid->cmdbuf = NULL;
ihid->argsbuf = NULL;
ihid->bufsize = 0;
@@ -489,10 +492,11 @@ static int i2c_hid_alloc_buffers(struct
   report_size; /* report */
 
ihid->inbuf = kzalloc(report_size, GFP_KERNEL);
+   ihid->rawbuf = kzalloc(report_size, GFP_KERNEL);
ihid->argsbuf = kzalloc(args_len, GFP_KERNEL);
ihid->cmdbuf = kzalloc(sizeof(union command) + args_len, GFP_KERNEL);
 
-   if (!ihid->inbuf || !ihid->argsbuf || !ihid->cmdbuf) {
+   if (!ihid->inbuf || !ihid->rawbuf || !ihid->argsbuf || !ihid->cmdbuf) {
i2c_hid_free_buffers(ihid);
return -ENOMEM;
}
@@ -519,12 +523,12 @@ static int i2c_hid_get_raw_report(struct
 
ret = i2c_hid_get_report(client,
report_type == HID_FEATURE_REPORT ? 0x03 : 0x01,
-   report_number, ihid->inbuf, ask_count);
+   report_number, ihid->rawbuf, ask_count);
 
if (ret < 0)
return ret;
 
-   ret_count = ihid->inbuf[0] | (ihid->inbuf[1] << 8);
+   ret_count = ihid->rawbuf[0] | (ihid->rawbuf[1] << 8);
 
if (ret_count <= 2)
return 0;
@@ -533,7 +537,7 @@ static int i2c_hid_get_raw_report(struct
 
/* The query buffer contains the size, dropping it in the reply */
count = min(count, ret_count - 2);
-   memcpy(buf, ihid->inbuf + 2, count);
+   memcpy(buf, ihid->rawbuf + 2, count);
 
return count;
 }


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 23/44] x86, vdso: Use asm volatile in __getcpu

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Andy Lutomirski 

commit 1ddf0b1b11aa8a90cef6706e935fc31c75c406ba upstream.

In Linux 3.18 and below, GCC hoists the lsl instructions in the
pvclock code all the way to the beginning of __vdso_clock_gettime,
slowing the non-paravirt case significantly.  For unknown reasons,
presumably related to the removal of a branch, the performance issue
is gone as of

e76b027e6408 x86,vdso: Use LSL unconditionally for vgetcpu

but I don't trust GCC enough to expect the problem to stay fixed.

There should be no correctness issue, because the __getcpu calls in
__vdso_vlock_gettime were never necessary in the first place.

Note to stable maintainers: In 3.18 and below, depending on
configuration, gcc 4.9.2 generates code like this:

 9c3:   44 0f 03 e8 lsl%ax,%r13d
 9c7:   45 89 ebmov%r13d,%r11d
 9ca:   0f 03 d8lsl%ax,%ebx

This patch won't apply as is to any released kernel, but I'll send a
trivial backported version if needed.

[
 Backported by Andy Lutomirski.  Should apply to all affected
 versions.  This fixes a functionality bug as well as a performance
 bug: buggy kernels can infinite loop in __vdso_clock_gettime on
 affected compilers.  See, for exammple:

 https://bugzilla.redhat.com/show_bug.cgi?id=1178975
]

Fixes: 51c19b4f5927 x86: vdso: pvclock gettime support
Cc: Marcelo Tosatti 
Acked-by: Paolo Bonzini 
Signed-off-by: Andy Lutomirski 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/vsyscall.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/include/asm/vsyscall.h
+++ b/arch/x86/include/asm/vsyscall.h
@@ -34,7 +34,7 @@ static inline unsigned int __getcpu(void
native_read_tscp();
} else {
/* Load per CPU data from GDT */
-   asm("lsl %1,%0" : "=r" (p) : "r" (__PER_CPU_SEG));
+   asm volatile ("lsl %1,%0" : "=r" (p) : "r" (__PER_CPU_SEG));
}
 
return p;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 20/44] HID: add battery quirk for USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ISO keyboard

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Karl Relton 

commit da940db41dcf8c04166f711646df2f35376010aa upstream.

Apple bluetooth wireless keyboard (sold in UK) has always reported zero
for battery strength no matter what condition the batteries are actually
in. With this patch applied (applying same quirk as other Apple
keyboards), the battery strength is now correctly reported.

Signed-off-by: Karl Relton 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hid/hid-input.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -317,6 +317,9 @@ static const struct hid_device_id hid_ba
   USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ANSI),
  HID_BATTERY_QUIRK_PERCENT | HID_BATTERY_QUIRK_FEATURE },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
+  USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ISO),
+ HID_BATTERY_QUIRK_PERCENT | HID_BATTERY_QUIRK_FEATURE },
+   { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI),
  HID_BATTERY_QUIRK_PERCENT | HID_BATTERY_QUIRK_FEATURE },
{}


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 18/44] HID: i2c-hid: prevent buffer overflow in early IRQ

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Gwendal Grignou 

commit d1c7e29e8d276c669e8790bb8be9f505ddc4 upstream.

Before ->start() is called, bufsize size is set to HID_MIN_BUFFER_SIZE,
64 bytes. While processing the IRQ, we were asking to receive up to
wMaxInputLength bytes, which can be bigger than 64 bytes.

Later, when ->start is run, a proper bufsize will be calculated.

Given wMaxInputLength is said to be unreliable in other part of the
code, set to receive only what we can even if it results in truncated
reports.

Signed-off-by: Gwendal Grignou 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hid/i2c-hid/i2c-hid.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -341,7 +341,7 @@ static int i2c_hid_hwreset(struct i2c_cl
 static void i2c_hid_get_input(struct i2c_hid *ihid)
 {
int ret, ret_size;
-   int size = le16_to_cpu(ihid->hdesc.wMaxInputLength);
+   int size = ihid->bufsize;
 
ret = i2c_master_recv(ihid->client, ihid->inbuf, size);
if (ret != size) {


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 33/44] fs: nfsd: Fix signedness bug in compare_blob

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Rasmus Villemoes 

commit ef17af2a817db97d42dd2ec0a425231748e23dbc upstream.

Bugs similar to the one in acbbe6fbb240 (kcmp: fix standard comparison
bug) are in rich supply.

In this variant, the problem is that struct xdr_netobj::len has type
unsigned int, so the expression o1->len - o2->len _also_ has type
unsigned int; it has completely well-defined semantics, and the result
is some non-negative integer, which is always representable in a long
long. But this means that if the conditional triggers, we are
guaranteed to return a positive value from compare_blob.

In this case it could be fixed by

-   res = o1->len - o2->len;
+   res = (long long)o1->len - (long long)o2->len;

but I'd rather eliminate the usually broken 'return a - b;' idiom.

Reviewed-by: Jeff Layton 
Signed-off-by: Rasmus Villemoes 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/nfsd/nfs4state.c |   15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -1200,15 +1200,14 @@ static int copy_cred(struct svc_cred *ta
return 0;
 }
 
-static long long
+static int
 compare_blob(const struct xdr_netobj *o1, const struct xdr_netobj *o2)
 {
-   long long res;
-
-   res = o1->len - o2->len;
-   if (res)
-   return res;
-   return (long long)memcmp(o1->data, o2->data, o1->len);
+   if (o1->len < o2->len)
+   return -1;
+   if (o1->len > o2->len)
+   return 1;
+   return memcmp(o1->data, o2->data, o1->len);
 }
 
 static int same_name(const char *n1, const char *n2)
@@ -1365,7 +1364,7 @@ add_clp_to_name_tree(struct nfs4_client
 static struct nfs4_client *
 find_clp_in_name_tree(struct xdr_netobj *name, struct rb_root *root)
 {
-   long long cmp;
+   int cmp;
struct rb_node *node = root->rb_node;
struct nfs4_client *clp;
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 03/44] ath9k: fix BE/BK queue order

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Felix Fietkau 

commit 78063d81d353e10cbdd279c490593113b8fdae1c upstream.

Hardware queues are ordered by priority. Use queue index 0 for BK, which
has lower priority than BE.

Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/ath/ath9k/hw.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -215,8 +215,8 @@
 #define AH_WOW_BEACON_MISS BIT(3)
 
 enum ath_hw_txq_subtype {
-   ATH_TXQ_AC_BE = 0,
-   ATH_TXQ_AC_BK = 1,
+   ATH_TXQ_AC_BK = 0,
+   ATH_TXQ_AC_BE = 1,
ATH_TXQ_AC_VI = 2,
ATH_TXQ_AC_VO = 3,
 };


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 14/44] UBI: Fix invalid vfree()

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Richard Weinberger 

commit f38aed975c0c3645bbdfc5ebe35726e64caaf588 upstream.

The logic of vfree()'ing vol->upd_buf is tied to vol->updating.
In ubi_start_update() vol->updating is set long before vmalloc()'ing
vol->upd_buf. If we encounter a write failure in ubi_start_update()
before vmalloc() the UBI device release function will try to vfree()
vol->upd_buf because vol->updating is set.
Fix this by allocating vol->upd_buf directly after setting vol->updating.

Fixes:
[   31.559338] UBI warning: vol_cdev_release: update of volume 2 not finished, 
volume is damaged
[   31.559340] [ cut here ]
[   31.559343] WARNING: CPU: 1 PID: 2747 at mm/vmalloc.c:1446 
__vunmap+0xe3/0x110()
[   31.559344] Trying to vfree() nonexistent vm area (c90001f2b000)
[   31.559345] Modules linked in:
[   31.565620]  0bba 88002a0cbdb0 818f0497 
88003b9ba148
[   31.566347]  88002a0cbde0 8156f515 88003b9ba148 
0bba
[   31.567073]    88002a0cbe88 
8156c10a
[   31.567793] Call Trace:
[   31.568034]  [] dump_stack+0x4e/0x7a
[   31.568510]  [] ubi_io_write_vid_hdr+0x155/0x160
[   31.569084]  [] ubi_eba_write_leb+0x23a/0x870
[   31.569628]  [] vol_cdev_write+0x226/0x380
[   31.570155]  [] vfs_write+0xb5/0x1f0
[   31.570627]  [] SyS_pwrite64+0x6a/0xa0
[   31.571123]  [] system_call_fastpath+0x16/0x1b

Signed-off-by: Richard Weinberger 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mtd/ubi/upd.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

--- a/drivers/mtd/ubi/upd.c
+++ b/drivers/mtd/ubi/upd.c
@@ -133,6 +133,10 @@ int ubi_start_update(struct ubi_device *
ubi_assert(!vol->updating && !vol->changing_leb);
vol->updating = 1;
 
+   vol->upd_buf = vmalloc(ubi->leb_size);
+   if (!vol->upd_buf)
+   return -ENOMEM;
+
err = set_update_marker(ubi, vol);
if (err)
return err;
@@ -152,14 +156,12 @@ int ubi_start_update(struct ubi_device *
err = clear_update_marker(ubi, vol, 0);
if (err)
return err;
+
+   vfree(vol->upd_buf);
vol->updating = 0;
return 0;
}
 
-   vol->upd_buf = vmalloc(ubi->leb_size);
-   if (!vol->upd_buf)
-   return -ENOMEM;
-
vol->upd_ebs = div_u64(bytes + vol->usable_leb_size - 1,
   vol->usable_leb_size);
vol->upd_bytes = bytes;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 60/77] ARM: dts: Enable PWM node by default for s3c64xx

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Tomasz Figa 

commit 5e794de514f56de1e78e979ca09c56a91aa2e9f1 upstream.

The PWM block is required for system clock source so it must be always
enabled. This patch fixes boot issues on SMDK6410 which did not have
the node enabled explicitly for other purposes.

Fixes: eeb93d02 ("clocksource: of: Respect device tree node status")

Signed-off-by: Tomasz Figa 
Signed-off-by: Kukjin Kim 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/boot/dts/s3c6410-mini6410.dts |4 
 arch/arm/boot/dts/s3c64xx.dtsi |1 -
 2 files changed, 5 deletions(-)

--- a/arch/arm/boot/dts/s3c6410-mini6410.dts
+++ b/arch/arm/boot/dts/s3c6410-mini6410.dts
@@ -198,10 +198,6 @@
status = "okay";
 };
 
- {
-   status = "okay";
-};
-
  {
gpio_leds: gpio-leds {
samsung,pins = "gpk-4", "gpk-5", "gpk-6", "gpk-7";
--- a/arch/arm/boot/dts/s3c64xx.dtsi
+++ b/arch/arm/boot/dts/s3c64xx.dtsi
@@ -168,7 +168,6 @@
clocks = < PCLK_PWM>;
samsung,pwm-outputs = <0>, <1>;
#pwm-cells = <3>;
-   status = "disabled";
};
 
pinctrl0: pinctrl@7f008000 {


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 08/44] ASoC: sigmadsp: Refuse to load firmware files with a non-supported version

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Lars-Peter Clausen 

commit 50c0f21b42dd4cd02b51f82274f66912d9a7fa32 upstream.

Make sure to check the version field of the firmware header to make sure to
not accidentally try to parse a firmware file with a different layout.
Trying to do so can result in loading invalid firmware code to the device.

Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/soc/codecs/sigmadsp.c |7 +++
 1 file changed, 7 insertions(+)

--- a/sound/soc/codecs/sigmadsp.c
+++ b/sound/soc/codecs/sigmadsp.c
@@ -176,6 +176,13 @@ static int _process_sigma_firmware(struc
goto done;
}
 
+   if (ssfw_head->version != 1) {
+   dev_err(dev,
+   "Failed to load firmware: Invalid version %d. Supported 
firmware versions: 1\n",
+   ssfw_head->version);
+   goto done;
+   }
+
crc = crc32(0, fw->data + sizeof(*ssfw_head),
fw->size - sizeof(*ssfw_head));
pr_debug("%s: crc=%x\n", __func__, crc);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 09/44] ASoC: max98090: Fix ill-defined sidetone route

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Jarkko Nikula 

commit 48826ee590da03e9882922edf96d8d27bdfe9552 upstream.

Commit 5fe5b767dc6f ("ASoC: dapm: Do not pretend to support controls for non
mixer/mux widgets") revealed ill-defined control in a route between
"STENL Mux" and DACs in max98090.c:

max98090 i2c-193C9890:00: Control not supported for path STENL Mux -> [NULL] -> 
DACL
max98090 i2c-193C9890:00: ASoC: no dapm match for STENL Mux --> NULL --> DACL
max98090 i2c-193C9890:00: ASoC: Failed to add route STENL Mux -> NULL -> DACL
max98090 i2c-193C9890:00: Control not supported for path STENL Mux -> [NULL] -> 
DACR
max98090 i2c-193C9890:00: ASoC: no dapm match for STENL Mux --> NULL --> DACR
max98090 i2c-193C9890:00: ASoC: Failed to add route STENL Mux -> NULL -> DACR

Since there is no control between "STENL Mux" and DACs the control name must
be NULL not "NULL".

Signed-off-by: Jarkko Nikula 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/soc/codecs/max98090.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/sound/soc/codecs/max98090.c
+++ b/sound/soc/codecs/max98090.c
@@ -1364,8 +1364,8 @@ static const struct snd_soc_dapm_route m
{"STENL Mux", "Sidetone Left", "DMICL"},
{"STENR Mux", "Sidetone Right", "ADCR"},
{"STENR Mux", "Sidetone Right", "DMICR"},
-   {"DACL", "NULL", "STENL Mux"},
-   {"DACR", "NULL", "STENL Mux"},
+   {"DACL", NULL, "STENL Mux"},
+   {"DACR", NULL, "STENL Mux"},
 
{"AIFINL", NULL, "SHDN"},
{"AIFINR", NULL, "SHDN"},


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 15/44] UBI: Fix double free after do_sync_erase()

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Richard Weinberger 

commit aa5ad3b6eb8feb2399a5d26c8fb0060561bb9534 upstream.

If the erase worker is unable to erase a PEB it will
free the ubi_wl_entry itself.
The failing ubi_wl_entry must not free()'d again after
do_sync_erase() returns.

Signed-off-by: Richard Weinberger 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mtd/ubi/wl.c |   10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -1209,7 +1209,6 @@ static int wear_leveling_worker(struct u
 
err = do_sync_erase(ubi, e1, vol_id, lnum, 0);
if (err) {
-   kmem_cache_free(ubi_wl_entry_slab, e1);
if (e2)
kmem_cache_free(ubi_wl_entry_slab, e2);
goto out_ro;
@@ -1223,10 +1222,8 @@ static int wear_leveling_worker(struct u
dbg_wl("PEB %d (LEB %d:%d) was put meanwhile, erase",
   e2->pnum, vol_id, lnum);
err = do_sync_erase(ubi, e2, vol_id, lnum, 0);
-   if (err) {
-   kmem_cache_free(ubi_wl_entry_slab, e2);
+   if (err)
goto out_ro;
-   }
}
 
dbg_wl("done");
@@ -1262,10 +1259,9 @@ out_not_moved:
 
ubi_free_vid_hdr(ubi, vid_hdr);
err = do_sync_erase(ubi, e2, vol_id, lnum, torture);
-   if (err) {
-   kmem_cache_free(ubi_wl_entry_slab, e2);
+   if (err)
goto out_ro;
-   }
+
mutex_unlock(>move_mutex);
return 0;
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 07/44] ath5k: fix hardware queue index assignment

2015-01-13 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Felix Fietkau 

commit 9e4982f6a51a2442f1bb588fee42521b44b4531c upstream.

Like with ath9k, ath5k queues also need to be ordered by priority.
queue_info->tqi_subtype already contains the correct index, so use it
instead of relying on the order of ath5k_hw_setup_tx_queue calls.

Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/ath/ath5k/qcu.c |8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

--- a/drivers/net/wireless/ath/ath5k/qcu.c
+++ b/drivers/net/wireless/ath/ath5k/qcu.c
@@ -225,13 +225,7 @@ ath5k_hw_setup_tx_queue(struct ath5k_hw
} else {
switch (queue_type) {
case AR5K_TX_QUEUE_DATA:
-   for (queue = AR5K_TX_QUEUE_ID_DATA_MIN;
-   ah->ah_txq[queue].tqi_type !=
-   AR5K_TX_QUEUE_INACTIVE; queue++) {
-
-   if (queue > AR5K_TX_QUEUE_ID_DATA_MAX)
-   return -EINVAL;
-   }
+   queue = queue_info->tqi_subtype;
break;
case AR5K_TX_QUEUE_UAPSD:
queue = AR5K_TX_QUEUE_ID_UAPSD;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.10 00/44] 3.10.65-stable review

2015-01-13 Thread Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.10.65 release.
There are 44 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Fri Jan 16 07:22:13 UTC 2015.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.65-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
Linux 3.10.65-rc1

Linus Torvalds 
mm: Don't count the stack guard page towards RLIMIT_STACK

Linus Torvalds 
mm: propagate error from stack expansion even for guard page

Vlastimil Babka 
mm, vmscan: prevent kswapd livelock due to pfmemalloc-throttled process 
being killed

Jiri Olsa 
perf session: Do not fail on processing out of order event

Jiri Olsa 
perf: Fix events installation during moving group

Jiri Olsa 
perf/x86/intel/uncore: Make sure only uncore events are collected

Chris Mason 
Btrfs: don't delay inode ref updates during log replay

Thomas Petazzoni 
ARM: mvebu: disable I/O coherency on non-SMP situations on Armada 
370/375/38x/XP

Johannes Berg 
scripts/kernel-doc: don't eat struct members with __aligned

Ryusuke Konishi 
nilfs2: fix the nilfs_iget() vs. nilfs_new_inode() races

Benjamin Coddington 
nfsd4: fix xdr4 inclusion of escaped char

Rasmus Villemoes 
fs: nfsd: Fix signedness bug in compare_blob

Robert Baldyga 
serial: samsung: wait for transfer completion before clock disable

Tejun Heo 
writeback: fix a subtle race condition in I_DIRTY clearing

Oliver Neukum 
cdc-acm: memory leak in error case

Jens Axboe 
genhd: check for int overflow in disk_expand_part_tbl()

Greg Kroah-Hartman 
USB: cdc-acm: check for valid interfaces

Takashi Iwai 
ALSA: hda - Fix wrong gpio_dir & gpio_mask hint setups for IDT/STAC codecs

Dan Carpenter 
ALSA: hda - using uninitialized data

Jiri Jaburek 
ALSA: usb-audio: extend KEF X300A FU 10 tweak to Arcam rPAC

Alex Williamson 
driver core: Fix unbalanced device reference in drivers_probe

Andy Lutomirski 
x86, vdso: Use asm volatile in __getcpu

Andy Lutomirski 
x86_64, vdso: Fix the vdso address randomization algorithm

Giedrius Statkevičius 
HID: Add a new id 0x501a for Genius MousePen i608X

Karl Relton 
HID: add battery quirk for USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ISO 
keyboard

Dan Carpenter 
HID: roccat: potential out of bounds in pyra_sysfs_write_settings()

Gwendal Grignou 
HID: i2c-hid: prevent buffer overflow in early IRQ

Jean-Baptiste Maneyrol 
HID: i2c-hid: fix race condition reading reports

Jiang Liu 
iommu/vt-d: Fix an off-by-one bug in __domain_mapping()

Richard Weinberger 
UBI: Fix double free after do_sync_erase()

Richard Weinberger 
UBI: Fix invalid vfree()

Tony Lindgren 
pstore-ram: Allow optional mapping with pgprot_noncached

Rob Herring 
pstore-ram: Fix hangs by using write-combine mappings

Myron Stowe 
PCI: Restore detection of read-only BARs

Andrew Jackson 
ASoC: dwc: Ensure FIFOs are flushed to prevent channel swap

Jarkko Nikula 
ASoC: max98090: Fix ill-defined sidetone route

Lars-Peter Clausen 
ASoC: sigmadsp: Refuse to load firmware files with a non-supported version

Felix Fietkau 
ath5k: fix hardware queue index assignment

Stefano Stabellini 
swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single

Stephane Grosjean 
can: peak_usb: fix memset() usage

Stephane Grosjean 
can: peak_usb: fix cleanup sequence order in case of error during init

Felix Fietkau 
ath9k: fix BE/BK queue order

Felix Fietkau 
ath9k_hw: fix hardware queue allocation

Junxiao Bi 
ocfs2: fix journal commit deadlock


-

Diffstat:

 Documentation/ramoops.txt | 13 ++--
 Makefile  |  4 +--
 arch/arm/mach-mvebu/coherency.c   | 23 ++
 arch/x86/include/asm/vsyscall.h   |  2 +-
 arch/x86/kernel/cpu/perf_event_intel_uncore.c | 22 --
 arch/x86/vdso/vma.c   | 43 ++-
 block/genhd.c | 11 +--
 drivers/base/bus.c|  8 +++--
 drivers/hid/hid-core.c|  1 +
 drivers/hid/hid-ids.h |  1 +
 drivers/hid/hid-input.c   |  3 ++
 drivers/hid/hid-kye.c |  4 +++
 drivers/hid/hid-roccat-pyra.c |  8 +++--
 drivers/hid/i2c-hid/i2c-hid.c | 14 +
 drivers/hid/usbhid/hid-quirks.c   |  1 +
 drivers/iommu/intel-iommu.c   |  8 ++---
 drivers/mtd/ubi/upd.c | 10 ---
 drivers/mtd/ubi/wl.c  | 

[PATCH 3.14 69/77] Btrfs: dont delay inode ref updates during log replay

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Chris Mason 

commit 6f8960541b1eb6054a642da48daae2320fddba93 upstream.

Commit 1d52c78afbb (Btrfs: try not to ENOSPC on log replay) added a
check to skip delayed inode updates during log replay because it
confuses the enospc code.  But the delayed processing will end up
ignoring delayed refs from log replay because the inode itself wasn't
put through the delayed code.

This can end up triggering a warning at commit time:

WARNING: CPU: 2 PID: 778 at fs/btrfs/delayed-inode.c:1410 
btrfs_assert_delayed_root_empty+0x32/0x34()

Which is repeated for each commit because we never process the delayed
inode ref update.

The fix used here is to change btrfs_delayed_delete_inode_ref to return
an error if we're currently in log replay.  The caller will do the ref
deletion immediately and everything will work properly.

Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/btrfs/delayed-inode.c |8 
 1 file changed, 8 insertions(+)

--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -1854,6 +1854,14 @@ int btrfs_delayed_delete_inode_ref(struc
 {
struct btrfs_delayed_node *delayed_node;
 
+   /*
+* we don't do delayed inode updates during log recovery because it
+* leads to enospc problems.  This means we also can't do
+* delayed inode refs
+*/
+   if (BTRFS_I(inode)->root->fs_info->log_root_recovering)
+   return -EAGAIN;
+
delayed_node = btrfs_get_or_create_delayed_node(inode);
if (IS_ERR(delayed_node))
return PTR_ERR(delayed_node);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 74/77] mmc: sdhci: Fix sleep in atomic after inserting SD card

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Krzysztof Kozlowski 

commit 2836766a9d0bd02c66073f8dd44796e6cc23848d upstream.

Sleep in atomic context happened on Trats2 board after inserting or
removing SD card because mmc_gpio_get_cd() was called under spin lock.

Fix this by moving card detection earlier, before acquiring spin lock.
The mmc_gpio_get_cd() call does not have to be protected by spin lock
because it does not access any sdhci internal data.
The sdhci_do_get_cd() call access host flags (SDHCI_DEVICE_DEAD). After
moving it out side of spin lock it could theoretically race with driver
removal but still there is no actual protection against manual card
eject.

Dmesg after inserting SD card:
[   41.663414] BUG: sleeping function called from invalid context at 
drivers/gpio/gpiolib.c:1511
[   41.670469] in_atomic(): 1, irqs_disabled(): 128, pid: 30, name: kworker/u8:1
[   41.677580] INFO: lockdep is turned off.
[   41.681486] irq event stamp: 61972
[   41.684872] hardirqs last  enabled at (61971): [] 
_raw_spin_unlock_irq+0x24/0x5c
[   41.693118] hardirqs last disabled at (61972): [] 
_raw_spin_lock_irq+0x18/0x54
[   41.701190] softirqs last  enabled at (61648): [] 
__do_softirq+0x234/0x2c8
[   41.708914] softirqs last disabled at (61631): [] 
irq_exit+0xd0/0x114
[   41.716206] Preemption disabled at:[<  (null)>]   (null)
[   41.721500]
[   41.722985] CPU: 3 PID: 30 Comm: kworker/u8:1 Tainted: GW  
3.18.0-rc5-next-20141121 #883
[   41.732111] Workqueue: kmmcd mmc_rescan
[   41.735945] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[   41.743661] [] (show_stack) from [] 
(dump_stack+0x70/0xbc)
[   41.750867] [] (dump_stack) from [] 
(gpiod_get_raw_value_cansleep+0x18/0x30)
[   41.759628] [] (gpiod_get_raw_value_cansleep) from [] 
(mmc_gpio_get_cd+0x38/0x58)
[   41.768821] [] (mmc_gpio_get_cd) from [] 
(sdhci_request+0x50/0x1a4)
[   41.776808] [] (sdhci_request) from [] 
(mmc_start_request+0x138/0x268)
[   41.785051] [] (mmc_start_request) from [] 
(mmc_wait_for_req+0x58/0x1a0)
[   41.793469] [] (mmc_wait_for_req) from [] 
(mmc_wait_for_cmd+0x58/0x78)
[   41.801714] [] (mmc_wait_for_cmd) from [] 
(mmc_io_rw_direct_host+0x98/0x124)
[   41.810480] [] (mmc_io_rw_direct_host) from [] 
(sdio_reset+0x2c/0x64)
[   41.818641] [] (sdio_reset) from [] 
(mmc_rescan+0x254/0x2e4)
[   41.826028] [] (mmc_rescan) from [] 
(process_one_work+0x180/0x3f4)
[   41.833920] [] (process_one_work) from [] 
(worker_thread+0x34/0x4b0)
[   41.841991] [] (worker_thread) from [] 
(kthread+0xe4/0x104)
[   41.849285] [] (kthread) from [] 
(ret_from_fork+0x14/0x2c)
[   42.038276] mmc0: new high speed SDHC card at address 1234

Signed-off-by: Krzysztof Kozlowski 
Fixes: 94144a465dd0 ("mmc: sdhci: add get_cd() implementation")
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mmc/host/sdhci.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1343,6 +1343,8 @@ static void sdhci_request(struct mmc_hos
 
sdhci_runtime_pm_get(host);
 
+   present = mmc_gpio_get_cd(host->mmc);
+
spin_lock_irqsave(>lock, flags);
 
WARN_ON(host->mrq != NULL);
@@ -1371,7 +1373,6 @@ static void sdhci_request(struct mmc_hos
 * zero: cd-gpio is used, and card is removed
 * one: cd-gpio is used, and card is present
 */
-   present = mmc_gpio_get_cd(host->mmc);
if (present < 0) {
/* If polling, assume that the card is always present. */
if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
@@ -2082,15 +2083,18 @@ static void sdhci_card_event(struct mmc_
 {
struct sdhci_host *host = mmc_priv(mmc);
unsigned long flags;
+   int present;
 
/* First check if client has provided their own card event */
if (host->ops->card_event)
host->ops->card_event(host);
 
+   present = sdhci_do_get_cd(host);
+
spin_lock_irqsave(>lock, flags);
 
/* Check host->mrq first in case we are runtime suspended */
-   if (host->mrq && !sdhci_do_get_cd(host)) {
+   if (host->mrq && !present) {
pr_err("%s: Card removed during transfer!\n",
mmc_hostname(host->mmc));
pr_err("%s: Resetting controller.\n",


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 68/77] arm64: kernel: fix __cpu_suspend mm switch on warm-boot

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Lorenzo Pieralisi 

commit f43c27188a49111b58e9611afa2f0365b0b55625 upstream.

On arm64 the TTBR0_EL1 register is set to either the reserved TTBR0
page tables on boot or to the active_mm mappings belonging to user space
processes, it must never be set to swapper_pg_dir page tables mappings.

When a CPU is booted its active_mm is set to init_mm even though its
TTBR0_EL1 points at the reserved TTBR0 page mappings. This implies
that when __cpu_suspend is triggered the active_mm can point at
init_mm even if the current TTBR0_EL1 register contains the reserved
TTBR0_EL1 mappings.

Therefore, the mm save and restore executed in __cpu_suspend might
turn out to be erroneous in that, if the current->active_mm corresponds
to init_mm, on resume from low power it ends up restoring in the
TTBR0_EL1 the init_mm mappings that are global and can cause speculation
of TLB entries which end up being propagated to user space.

This patch fixes the issue by checking the active_mm pointer before
restoring the TTBR0 mappings. If the current active_mm == _mm,
the code sets the TTBR0_EL1 to the reserved TTBR0 mapping instead of
switching back to the active_mm, which is the expected behaviour
corresponding to the TTBR0_EL1 settings when __cpu_suspend was entered.

Fixes: 95322526ef62 ("arm64: kernel: cpu_{suspend/resume} implementation")
Cc: Will Deacon 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm64/kernel/suspend.c |   14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

--- a/arch/arm64/kernel/suspend.c
+++ b/arch/arm64/kernel/suspend.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -98,7 +99,18 @@ int __cpu_suspend(unsigned long arg, int
 */
ret = __cpu_suspend_enter(arg, fn);
if (ret == 0) {
-   cpu_switch_mm(mm->pgd, mm);
+   /*
+* We are resuming from reset with TTBR0_EL1 set to the
+* idmap to enable the MMU; restore the active_mm mappings in
+* TTBR0_EL1 unless the active_mm == _mm, in which case
+* the thread entered __cpu_suspend with TTBR0_EL1 set to
+* reserved TTBR0 page tables and should be restored as such.
+*/
+   if (mm == _mm)
+   cpu_set_reserved_ttbr0();
+   else
+   cpu_switch_mm(mm->pgd, mm);
+
flush_tlb_all();
 
/*


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 54/77] mtd: tests: abort torturetest on erase errors

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Brian Norris 

commit 68f29815034e9dc9ed53cad85946c32b07adc8cc upstream.

The torture test should quit once it actually induces an error in the
flash. This step was accidentally removed during refactoring.

Without this fix, the torturetest just continues infinitely, or until
the maximum cycle count is reached. e.g.:

   ...
   [ 7619.218171] mtd_test: error -5 while erasing EB 100
   [ 7619.297981] mtd_test: error -5 while erasing EB 100
   [ 7619.377953] mtd_test: error -5 while erasing EB 100
   [ 7619.457998] mtd_test: error -5 while erasing EB 100
   [ 7619.537990] mtd_test: error -5 while erasing EB 100
   ...

Fixes: 6cf78358c94f ("mtd: mtd_torturetest: use mtd_test helpers")
Signed-off-by: Brian Norris 
Cc: Akinobu Mita 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mtd/tests/torturetest.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/mtd/tests/torturetest.c
+++ b/drivers/mtd/tests/torturetest.c
@@ -264,7 +264,9 @@ static int __init tort_init(void)
int i;
void *patt;
 
-   mtdtest_erase_good_eraseblocks(mtd, bad_ebs, eb, ebcnt);
+   err = mtdtest_erase_good_eraseblocks(mtd, bad_ebs, eb, ebcnt);
+   if (err)
+   goto out;
 
/* Check if the eraseblocks contain only 0xFF bytes */
if (check) {


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 71/77] perf: Fix events installation during moving group

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Jiri Olsa 

commit 9fc81d87420d0d3fd62d5e5529972c0ad9eab9cc upstream.

We allow PMU driver to change the cpu on which the event
should be installed to. This happened in patch:

  e2d37cd213dc ("perf: Allow the PMU driver to choose the CPU on which to 
install events")

This patch also forces all the group members to follow
the currently opened events cpu if the group happened
to be moved.

This and the change of event->cpu in perf_install_in_context()
function introduced in:

  0cda4c023132 ("perf: Introduce perf_pmu_migrate_context()")

forces group members to change their event->cpu,
if the currently-opened-event's PMU changed the cpu
and there is a group move.

Above behaviour causes problem for breakpoint events,
which uses event->cpu to touch cpu specific data for
breakpoints accounting. By changing event->cpu, some
breakpoints slots were wrongly accounted for given
cpu.

Vinces's perf fuzzer hit this issue and caused following
WARN on my setup:

   WARNING: CPU: 0 PID: 20214 at arch/x86/kernel/hw_breakpoint.c:119 
arch_install_hw_breakpoint+0x142/0x150()
   Can't find any breakpoint slot
   [...]

This patch changes the group moving code to keep the event's
original cpu.

Reported-by: Vince Weaver 
Signed-off-by: Jiri Olsa 
Cc: Arnaldo Carvalho de Melo 
Cc: Frederic Weisbecker 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Vince Weaver 
Cc: Yan, Zheng 
Link: 
http://lkml.kernel.org/r/1418243031-20367-3-git-send-email-jo...@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/events/core.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7240,11 +7240,11 @@ SYSCALL_DEFINE5(perf_event_open,
 
if (move_group) {
synchronize_rcu();
-   perf_install_in_context(ctx, group_leader, event->cpu);
+   perf_install_in_context(ctx, group_leader, group_leader->cpu);
get_ctx(ctx);
list_for_each_entry(sibling, _leader->sibling_list,
group_entry) {
-   perf_install_in_context(ctx, sibling, event->cpu);
+   perf_install_in_context(ctx, sibling, sibling->cpu);
get_ctx(ctx);
}
}


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 55/77] nilfs2: fix the nilfs_iget() vs. nilfs_new_inode() races

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Ryusuke Konishi 

commit 705304a863cc41585508c0f476f6d3ec28cf7e00 upstream.

Same story as in commit 41080b5a2401 ("nfsd race fixes: ext2") (similar
ext2 fix) except that nilfs2 needs to use insert_inode_locked4() instead
of insert_inode_locked() and a bug of a check for dead inodes needs to
be fixed.

If nilfs_iget() is called from nfsd after nilfs_new_inode() calls
insert_inode_locked4(), nilfs_iget() will wait for unlock_new_inode() at
the end of nilfs_mkdir()/nilfs_create()/etc to unlock the inode.

If nilfs_iget() is called before nilfs_new_inode() calls
insert_inode_locked4(), it will create an in-core inode and read its
data from the on-disk inode.  But, nilfs_iget() will find i_nlink equals
zero and fail at nilfs_read_inode_common(), which will lead it to call
iget_failed() and cleanly fail.

However, this sanity check doesn't work as expected for reused on-disk
inodes because they leave a non-zero value in i_mode field and it
hinders the test of i_nlink.  This patch also fixes the issue by
removing the test on i_mode that nilfs2 doesn't need.

Signed-off-by: Ryusuke Konishi 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/nilfs2/inode.c |   32 
 fs/nilfs2/namei.c |   15 ---
 2 files changed, 36 insertions(+), 11 deletions(-)

--- a/fs/nilfs2/inode.c
+++ b/fs/nilfs2/inode.c
@@ -49,6 +49,8 @@ struct nilfs_iget_args {
int for_gc;
 };
 
+static int nilfs_iget_test(struct inode *inode, void *opaque);
+
 void nilfs_inode_add_blocks(struct inode *inode, int n)
 {
struct nilfs_root *root = NILFS_I(inode)->i_root;
@@ -347,6 +349,17 @@ const struct address_space_operations ni
.is_partially_uptodate  = block_is_partially_uptodate,
 };
 
+static int nilfs_insert_inode_locked(struct inode *inode,
+struct nilfs_root *root,
+unsigned long ino)
+{
+   struct nilfs_iget_args args = {
+   .ino = ino, .root = root, .cno = 0, .for_gc = 0
+   };
+
+   return insert_inode_locked4(inode, ino, nilfs_iget_test, );
+}
+
 struct inode *nilfs_new_inode(struct inode *dir, umode_t mode)
 {
struct super_block *sb = dir->i_sb;
@@ -382,7 +395,7 @@ struct inode *nilfs_new_inode(struct ino
if (S_ISREG(mode) || S_ISDIR(mode) || S_ISLNK(mode)) {
err = nilfs_bmap_read(ii->i_bmap, NULL);
if (err < 0)
-   goto failed_bmap;
+   goto failed_after_creation;
 
set_bit(NILFS_I_BMAP, >i_state);
/* No lock is needed; iget() ensures it. */
@@ -398,21 +411,24 @@ struct inode *nilfs_new_inode(struct ino
spin_lock(>ns_next_gen_lock);
inode->i_generation = nilfs->ns_next_generation++;
spin_unlock(>ns_next_gen_lock);
-   insert_inode_hash(inode);
+   if (nilfs_insert_inode_locked(inode, root, ino) < 0) {
+   err = -EIO;
+   goto failed_after_creation;
+   }
 
err = nilfs_init_acl(inode, dir);
if (unlikely(err))
-   goto failed_acl; /* never occur. When supporting
+   goto failed_after_creation; /* never occur. When supporting
nilfs_init_acl(), proper cancellation of
above jobs should be considered */
 
return inode;
 
- failed_acl:
- failed_bmap:
+ failed_after_creation:
clear_nlink(inode);
+   unlock_new_inode(inode);
iput(inode);  /* raw_inode will be deleted through
-generic_delete_inode() */
+nilfs_evict_inode() */
goto failed;
 
  failed_ifile_create_inode:
@@ -460,8 +476,8 @@ int nilfs_read_inode_common(struct inode
inode->i_atime.tv_nsec = le32_to_cpu(raw_inode->i_mtime_nsec);
inode->i_ctime.tv_nsec = le32_to_cpu(raw_inode->i_ctime_nsec);
inode->i_mtime.tv_nsec = le32_to_cpu(raw_inode->i_mtime_nsec);
-   if (inode->i_nlink == 0 && inode->i_mode == 0)
-   return -EINVAL; /* this inode is deleted */
+   if (inode->i_nlink == 0)
+   return -ESTALE; /* this inode is deleted */
 
inode->i_blocks = le64_to_cpu(raw_inode->i_blocks);
ii->i_flags = le32_to_cpu(raw_inode->i_flags);
--- a/fs/nilfs2/namei.c
+++ b/fs/nilfs2/namei.c
@@ -51,9 +51,11 @@ static inline int nilfs_add_nondir(struc
int err = nilfs_add_link(dentry, inode);
if (!err) {
d_instantiate(dentry, inode);
+   unlock_new_inode(inode);
return 0;
}
inode_dec_link_count(inode);
+   unlock_new_inode(inode);
iput(inode);
return err;
 }
@@ -182,6 +184,7 @@ out:
 out_fail:
drop_nlink(inode);

[PATCH 3.14 57/77] sched/deadline: Fix migration of SCHED_DEADLINE tasks

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Luca Abeni 

commit 6a503c3be937d275113b702e0421e5b0720abe8a upstream.

According to global EDF, tasks should be migrated between runqueues
without checking if their scheduling deadlines and runtimes are valid.
However, SCHED_DEADLINE currently performs such a check:
a migration happens doing:

deactivate_task(rq, next_task, 0);
set_task_cpu(next_task, later_rq->cpu);
activate_task(later_rq, next_task, 0);

which ends up calling dequeue_task_dl(), setting the new CPU, and then
calling enqueue_task_dl().

enqueue_task_dl() then calls enqueue_dl_entity(), which calls
update_dl_entity(), which can modify scheduling deadline and runtime,
breaking global EDF scheduling.

As a result, some of the properties of global EDF are not respected:
for example, a taskset {(30, 80), (40, 80), (120, 170)} scheduled on
two cores can have unbounded response times for the third task even
if 30/80+40/80+120/170 = 1.5809 < 2

This can be fixed by invoking update_dl_entity() only in case of
wakeup, or if this is a new SCHED_DEADLINE task.

Signed-off-by: Luca Abeni 
Signed-off-by: Peter Zijlstra (Intel) 
Acked-by: Juri Lelli 
Cc: Dario Faggioli 
Cc: Linus Torvalds 
Link: 
http://lkml.kernel.org/r/1418813432-20797-2-git-send-email-luca.ab...@unitn.it
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/sched/deadline.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -806,10 +806,10 @@ enqueue_dl_entity(struct sched_dl_entity
 * parameters of the task might need updating. Otherwise,
 * we want a replenishment of its runtime.
 */
-   if (!dl_se->dl_new && flags & ENQUEUE_REPLENISH)
-   replenish_dl_entity(dl_se, pi_se);
-   else
+   if (dl_se->dl_new || flags & ENQUEUE_WAKEUP)
update_dl_entity(dl_se, pi_se);
+   else if (flags & ENQUEUE_REPLENISH)
+   replenish_dl_entity(dl_se, pi_se);
 
__enqueue_dl_entity(dl_se);
 }


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 64/77] ACPI / PM: Fix PM initialization for devices that are not present

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: "Rafael J. Wysocki" 

commit 1b1f3e1699a9886f1070f94171097ab4ccdbfc95 upstream.

If an ACPI device object whose _STA returns 0 (not present and not
functional) has _PR0 or _PS0, its power_manageable flag will be set
and acpi_bus_init_power() will return 0 for it.  Consequently, if
such a device object is passed to the ACPI device PM functions, they
will attempt to carry out the requested operation on the device,
although they should not do that for devices that are not present.

To fix that problem make acpi_bus_init_power() return an error code
for devices that are not present which will cause power_manageable to
be cleared for them as appropriate in acpi_bus_get_power_flags().
However, the lists of power resources should not be freed for the
device in that case, so modify acpi_bus_get_power_flags() to keep
those lists even if acpi_bus_init_power() returns an error.
Accordingly, when deciding whether or not the lists of power
resources need to be freed, acpi_free_power_resources_lists()
should check the power.flags.power_resources flag instead of
flags.power_manageable, so make that change too.

Furthermore, if acpi_bus_attach() sees that flags.initialized is
unset for the given device, it should reset the power management
settings of the device and re-initialize them from scratch instead
of relying on the previous settings (the device may have appeared
after being not present previously, for example), so make it use
the 'valid' flag of the D0 power state as the initial value of
flags.power_manageable for it and call acpi_bus_init_power() to
discover its current power state.

Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Mika Westerberg 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/acpi/device_pm.c |2 +-
 drivers/acpi/scan.c  |   13 -
 2 files changed, 9 insertions(+), 6 deletions(-)

--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -257,7 +257,7 @@ int acpi_bus_init_power(struct acpi_devi
 
device->power.state = ACPI_STATE_UNKNOWN;
if (!acpi_device_is_present(device))
-   return 0;
+   return -ENXIO;
 
result = acpi_device_get_power(device, );
if (result)
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -865,7 +865,7 @@ static void acpi_free_power_resources_li
if (device->wakeup.flags.valid)
acpi_power_resources_list_free(>wakeup.resources);
 
-   if (!device->flags.power_manageable)
+   if (!device->power.flags.power_resources)
return;
 
for (i = ACPI_STATE_D0; i <= ACPI_STATE_D3_HOT; i++) {
@@ -1554,10 +1554,8 @@ static void acpi_bus_get_power_flags(str
device->power.flags.power_resources)
device->power.states[ACPI_STATE_D3_COLD].flags.os_accessible = 
1;
 
-   if (acpi_bus_init_power(device)) {
-   acpi_free_power_resources_lists(device);
+   if (acpi_bus_init_power(device))
device->flags.power_manageable = 0;
-   }
 }
 
 static void acpi_bus_get_flags(struct acpi_device *device)
@@ -2043,13 +2041,18 @@ static void acpi_bus_attach(struct acpi_
/* Skip devices that are not present. */
if (!acpi_device_is_present(device)) {
device->flags.visited = false;
+   device->flags.power_manageable = 0;
return;
}
if (device->handler)
goto ok;
 
if (!device->flags.initialized) {
-   acpi_bus_update_power(device, NULL);
+   device->flags.power_manageable =
+   device->power.states[ACPI_STATE_D0].flags.valid;
+   if (acpi_bus_init_power(device))
+   device->flags.power_manageable = 0;
+
device->flags.initialized = true;
}
device->flags.visited = false;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 17/77] ASoC: dwc: Ensure FIFOs are flushed to prevent channel swap

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Andrew Jackson 

commit 3475c3d034d7f276a474c8bd53f44b48c8bf669d upstream.

Flush the FIFOs when the stream is prepared for use.  This avoids
an inadvertent swapping of the left/right channels if the FIFOs are
not empty at startup.

Signed-off-by: Andrew Jackson 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/soc/dwc/designware_i2s.c |   14 ++
 1 file changed, 14 insertions(+)

--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -263,6 +263,19 @@ static void dw_i2s_shutdown(struct snd_p
snd_soc_dai_set_dma_data(dai, substream, NULL);
 }
 
+static int dw_i2s_prepare(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+   struct dw_i2s_dev *dev = snd_soc_dai_get_drvdata(dai);
+
+   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+   i2s_write_reg(dev->i2s_base, TXFFR, 1);
+   else
+   i2s_write_reg(dev->i2s_base, RXFFR, 1);
+
+   return 0;
+}
+
 static int dw_i2s_trigger(struct snd_pcm_substream *substream,
int cmd, struct snd_soc_dai *dai)
 {
@@ -294,6 +307,7 @@ static struct snd_soc_dai_ops dw_i2s_dai
.startup= dw_i2s_startup,
.shutdown   = dw_i2s_shutdown,
.hw_params  = dw_i2s_hw_params,
+   .prepare= dw_i2s_prepare,
.trigger= dw_i2s_trigger,
 };
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 47/77] serial: samsung: wait for transfer completion before clock disable

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Robert Baldyga 

commit 1ff383a4c3eda8893ec61b02831826e1b1f46b41 upstream.

This patch adds waiting until transmit buffer and shifter will be empty
before clock disabling.

Without this fix it's possible to have clock disabled while data was
not transmited yet, which causes unproper state of TX line and problems
in following data transfers.

Signed-off-by: Robert Baldyga 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/tty/serial/samsung.c |4 
 1 file changed, 4 insertions(+)

--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -544,11 +544,15 @@ static void s3c24xx_serial_pm(struct uar
  unsigned int old)
 {
struct s3c24xx_uart_port *ourport = to_ourport(port);
+   int timeout = 1;
 
ourport->pm_level = level;
 
switch (level) {
case 3:
+   while (--timeout && !s3c24xx_serial_txempty_nofifo(port))
+   udelay(100);
+
if (!IS_ERR(ourport->baudclk))
clk_disable_unprepare(ourport->baudclk);
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 45/77] writeback: fix a subtle race condition in I_DIRTY clearing

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Tejun Heo 

commit 9c6ac78eb3521c5937b2dd8a7d1b300f41092f45 upstream.

After invoking ->dirty_inode(), __mark_inode_dirty() does smp_mb() and
tests inode->i_state locklessly to see whether it already has all the
necessary I_DIRTY bits set.  The comment above the barrier doesn't
contain any useful information - memory barriers can't ensure "changes
are seen by all cpus" by itself.

And it sure enough was broken.  Please consider the following
scenario.

 CPU 0  CPU 1
 ---

enters __writeback_single_inode()
grabs inode->i_lock
tests PAGECACHE_TAG_DIRTY which is clear
 enters __set_page_dirty()
 grabs mapping->tree_lock
 sets PAGECACHE_TAG_DIRTY
 releases mapping->tree_lock
 leaves __set_page_dirty()

 enters __mark_inode_dirty()
 smp_mb()
 sees I_DIRTY_PAGES set
 leaves __mark_inode_dirty()
clears I_DIRTY_PAGES
releases inode->i_lock

Now @inode has dirty pages w/ I_DIRTY_PAGES clear.  This doesn't seem
to lead to an immediately critical problem because requeue_inode()
later checks PAGECACHE_TAG_DIRTY instead of I_DIRTY_PAGES when
deciding whether the inode needs to be requeued for IO and there are
enough unintentional memory barriers inbetween, so while the inode
ends up with inconsistent I_DIRTY_PAGES flag, it doesn't fall off the
IO list.

The lack of explicit barrier may also theoretically affect the other
I_DIRTY bits which deal with metadata dirtiness.  There is no
guarantee that a strong enough barrier exists between
I_DIRTY_[DATA]SYNC clearing and write_inode() writing out the dirtied
inode.  Filesystem inode writeout path likely has enough stuff which
can behave as full barrier but it's theoretically possible that the
writeout may not see all the updates from ->dirty_inode().

Fix it by adding an explicit smp_mb() after I_DIRTY clearing.  Note
that I_DIRTY_PAGES needs a special treatment as it always needs to be
cleared to be interlocked with the lockless test on
__mark_inode_dirty() side.  It's cleared unconditionally and
reinstated after smp_mb() if the mapping still has dirty pages.

Also add comments explaining how and why the barriers are paired.

Lightly tested.

Signed-off-by: Tejun Heo 
Cc: Jan Kara 
Cc: Mikulas Patocka 
Cc: Jens Axboe 
Cc: Al Viro 
Reviewed-by: Jan Kara 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/fs-writeback.c |   29 ++---
 1 file changed, 22 insertions(+), 7 deletions(-)

--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -476,12 +476,28 @@ __writeback_single_inode(struct inode *i
 * write_inode()
 */
spin_lock(>i_lock);
-   /* Clear I_DIRTY_PAGES if we've written out all dirty pages */
-   if (!mapping_tagged(mapping, PAGECACHE_TAG_DIRTY))
-   inode->i_state &= ~I_DIRTY_PAGES;
+
dirty = inode->i_state & I_DIRTY;
-   inode->i_state &= ~(I_DIRTY_SYNC | I_DIRTY_DATASYNC);
+   inode->i_state &= ~I_DIRTY;
+
+   /*
+* Paired with smp_mb() in __mark_inode_dirty().  This allows
+* __mark_inode_dirty() to test i_state without grabbing i_lock -
+* either they see the I_DIRTY bits cleared or we see the dirtied
+* inode.
+*
+* I_DIRTY_PAGES is always cleared together above even if @mapping
+* still has dirty pages.  The flag is reinstated after smp_mb() if
+* necessary.  This guarantees that either __mark_inode_dirty()
+* sees clear I_DIRTY_PAGES or we see PAGECACHE_TAG_DIRTY.
+*/
+   smp_mb();
+
+   if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY))
+   inode->i_state |= I_DIRTY_PAGES;
+
spin_unlock(>i_lock);
+
/* Don't write the inode if only I_DIRTY_PAGES was set */
if (dirty & (I_DIRTY_SYNC | I_DIRTY_DATASYNC)) {
int err = write_inode(inode, wbc);
@@ -1145,12 +1161,11 @@ void __mark_inode_dirty(struct inode *in
}
 
/*
-* make sure that changes are seen by all cpus before we test i_state
-* -- mikulas
+* Paired with smp_mb() in __writeback_single_inode() for the
+* following lockless i_state test.  See there for details.
 */
smp_mb();
 
-   /* avoid the locking if we can */
if ((inode->i_state & flags) == flags)
return;
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 51/77] nfsd4: fix xdr4 inclusion of escaped char

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Benjamin Coddington 

commit 5a64e56976f1ba98743e1678c0029a98e9034c81 upstream.

Fix a bug where nfsd4_encode_components_esc() includes the esc_end char as
an additional string encoding.

Signed-off-by: Benjamin Coddington 
Fixes: e7a0444aef4a "nfsd: add IPv6 addr escaping to fs_location hosts"
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/nfsd/nfs4xdr.c |3 +++
 1 file changed, 3 insertions(+)

--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -1809,6 +1809,9 @@ static __be32 nfsd4_encode_components_es
}
else
end++;
+   if (found_esc)
+   end = next;
+
str = end;
}
*pp = p;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 63/77] ARM: mvebu: disable I/O coherency on non-SMP situations on Armada 370/375/38x/XP

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Petazzoni 

commit e55355453600a33bb5ca4f71f2d7214875f3b061 upstream.

Enabling the hardware I/O coherency on Armada 370, Armada 375, Armada
38x and Armada XP requires a certain number of conditions:

 - On Armada 370, the cache policy must be set to write-allocate.

 - On Armada 375, 38x and XP, the cache policy must be set to
   write-allocate, the pages must be mapped with the shareable
   attribute, and the SMP bit must be set

Currently, on Armada XP, when CONFIG_SMP is enabled, those conditions
are met. However, when Armada XP is used in a !CONFIG_SMP kernel, none
of these conditions are met. With Armada 370, the situation is worse:
since the processor is single core, regardless of whether CONFIG_SMP
or !CONFIG_SMP is used, the cache policy will be set to write-back by
the kernel and not write-allocate.

Since solving this problem turns out to be quite complicated, and we
don't want to let users with a mainline kernel known to have
infrequent but existing data corruptions, this commit proposes to
simply disable hardware I/O coherency in situations where it is known
not to work.

And basically, the is_smp() function of the kernel tells us whether it
is OK to enable hardware I/O coherency or not, so this commit slightly
refactors the coherency_type() function to return
COHERENCY_FABRIC_TYPE_NONE when is_smp() is false, or the appropriate
type of the coherency fabric in the other case.

Thanks to this, the I/O coherency fabric will no longer be used at all
in !CONFIG_SMP configurations. It will continue to be used in
CONFIG_SMP configurations on Armada XP, Armada 375 and Armada 38x
(which are multiple cores processors), but will no longer be used on
Armada 370 (which is a single core processor).

In the process, it simplifies the implementation of the
coherency_type() function, and adds a missing call to of_node_put().

Signed-off-by: Thomas Petazzoni 
Fixes: e60304f8cb7bb545e79fe62d9b9762460c254ec2 ("arm: mvebu: Add hardware I/O 
Coherency support")
Acked-by: Gregory CLEMENT 
Link: 
https://lkml.kernel.org/r/1415871540-20302-3-git-send-email-thomas.petazz...@free-electrons.com
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman 


---
 arch/arm/mach-mvebu/coherency.c |   26 ++
 1 file changed, 26 insertions(+)

--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -125,6 +125,29 @@ int __init coherency_init(void)
 {
struct device_node *np;
 
+   /*
+* The coherency fabric is needed:
+* - For coherency between processors on Armada XP, so only
+*   when SMP is enabled.
+* - For coherency between the processor and I/O devices, but
+*   this coherency requires many pre-requisites (write
+*   allocate cache policy, shareable pages, SMP bit set) that
+*   are only meant in SMP situations.
+*
+* Note that this means that on Armada 370, there is currently
+* no way to use hardware I/O coherency, because even when
+* CONFIG_SMP is enabled, is_smp() returns false due to the
+* Armada 370 being a single-core processor. To lift this
+* limitation, we would have to find a way to make the cache
+* policy set to write-allocate (on all Armada SoCs), and to
+* set the shareable attribute in page tables (on all Armada
+* SoCs except the Armada 370). Unfortunately, such decisions
+* are taken very early in the kernel boot process, at a point
+* where we don't know yet on which SoC we are running.
+*/
+   if (!is_smp())
+   return 0;
+
np = of_find_matching_node(NULL, of_coherency_table);
if (np) {
struct resource res;
@@ -151,6 +174,9 @@ static int __init coherency_late_init(vo
 {
struct device_node *np;
 
+   if (!is_smp())
+   return 0;
+
np = of_find_matching_node(NULL, of_coherency_table);
if (np) {
bus_register_notifier(_bus_type,


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 43/77] genhd: check for int overflow in disk_expand_part_tbl()

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Jens Axboe 

commit 5fabcb4c33fe11c7e3afdf805fde26c1a54d0953 upstream.

We can get here from blkdev_ioctl() -> blkpg_ioctl() -> add_partition()
with a user passed in partno value. If we pass in 0x7fff, the
new target in disk_expand_part_tbl() overflows the 'int' and we
access beyond the end of ptbl->part[] and even write to it when we
do the rcu_assign_pointer() to assign the new partition.

Reported-by: David Ramos 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 block/genhd.c |   11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

--- a/block/genhd.c
+++ b/block/genhd.c
@@ -1070,9 +1070,16 @@ int disk_expand_part_tbl(struct gendisk
struct disk_part_tbl *old_ptbl = disk->part_tbl;
struct disk_part_tbl *new_ptbl;
int len = old_ptbl ? old_ptbl->len : 0;
-   int target = partno + 1;
+   int i, target;
size_t size;
-   int i;
+
+   /*
+* check for int overflow, since we can get here from blkpg_ioctl()
+* with a user passed 'partno'.
+*/
+   target = partno + 1;
+   if (target < 0)
+   return -EINVAL;
 
/* disk_max_parts() is zero during initialization, ignore if so */
if (disk_max_parts(disk) && target > disk_max_parts(disk))


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 19/77] powerpc/book3s: Fix partial invalidation of TLBs in MCE code.

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Mahesh Salgaonkar 

commit 682e77c861c4c60f79ffbeae5e1938ffed24a575 upstream.

The existing MCE code calls flush_tlb hook with IS=0 (single page) resulting
in partial invalidation of TLBs which is not right. This patch fixes
that by passing IS=0xc00 to invalidate whole TLB for successful recovery
from TLB and ERAT errors.

Signed-off-by: Mahesh Salgaonkar 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/powerpc/kernel/mce_power.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/powerpc/kernel/mce_power.c
+++ b/arch/powerpc/kernel/mce_power.c
@@ -78,7 +78,7 @@ static long mce_handle_derror(uint64_t d
}
if (dsisr & P7_DSISR_MC_TLB_MULTIHIT_MFTLB) {
if (cur_cpu_spec && cur_cpu_spec->flush_tlb)
-   cur_cpu_spec->flush_tlb(TLBIEL_INVAL_PAGE);
+   cur_cpu_spec->flush_tlb(TLBIEL_INVAL_SET);
/* reset error bits */
dsisr &= ~P7_DSISR_MC_TLB_MULTIHIT_MFTLB;
}
@@ -109,7 +109,7 @@ static long mce_handle_common_ierror(uin
break;
case P7_SRR1_MC_IFETCH_TLB_MULTIHIT:
if (cur_cpu_spec && cur_cpu_spec->flush_tlb) {
-   cur_cpu_spec->flush_tlb(TLBIEL_INVAL_PAGE);
+   cur_cpu_spec->flush_tlb(TLBIEL_INVAL_SET);
handled = 1;
}
break;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 21/77] PCI: Restore detection of read-only BARs

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Myron Stowe 

commit 36e8164882ca6d3c41cb91e6f09a3ed236841f80 upstream.

Commit 6ac665c63dca ("PCI: rewrite PCI BAR reading code") masked off
low-order bits from 'l', but not from 'sz'.  Both are passed to pci_size(),
which compares 'base == maxbase' to check for read-only BARs.  The masking
of 'l' means that comparison will never be 'true', so the check for
read-only BARs no longer works.

Resolve this by also masking off the low-order bits of 'sz' before passing
it into pci_size() as 'maxbase'.  With this change, pci_size() will once
again catch the problems that have been encountered to date:

  - AGP aperture BAR of AMD-7xx host bridges: if the AGP window is
disabled, this BAR is read-only and read as 0x0008 [1]

  - BARs 0-4 of ALi IDE controllers can be non-zero and read-only [1]

  - Intel Sandy Bridge - Thermal Management Controller [8086:0103];
BAR 0 returning 0xfed98004 [2]

  - Intel Xeon E5 v3/Core i7 Power Control Unit [8086:2fc0];
Bar 0 returning 0x1a [3]

Link: [1] 
https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/drivers/pci/probe.c?id=1307ef6621991f1c4bc3cec1b5a4ebd6fd3d66b9
 ("PCI: probing read-only BARs" (pre-git))
Link: [2] https://bugzilla.kernel.org/show_bug.cgi?id=43331
Link: [3] https://bugzilla.kernel.org/show_bug.cgi?id=85991
Reported-by: William Unruh 
Reported-by: Martin Lucina 
Signed-off-by: Myron Stowe 
Signed-off-by: Bjorn Helgaas 
CC: Matthew Wilcox 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/pci/probe.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -214,14 +214,17 @@ int __pci_read_base(struct pci_dev *dev,
res->flags |= IORESOURCE_SIZEALIGN;
if (res->flags & IORESOURCE_IO) {
l &= PCI_BASE_ADDRESS_IO_MASK;
+   sz &= PCI_BASE_ADDRESS_IO_MASK;
mask = PCI_BASE_ADDRESS_IO_MASK & (u32) IO_SPACE_LIMIT;
} else {
l &= PCI_BASE_ADDRESS_MEM_MASK;
+   sz &= PCI_BASE_ADDRESS_MEM_MASK;
mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
}
} else {
res->flags |= (l & IORESOURCE_ROM_ENABLE);
l &= PCI_ROM_ADDRESS_MASK;
+   sz &= PCI_ROM_ADDRESS_MASK;
mask = (u32)PCI_ROM_ADDRESS_MASK;
}
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 05/77] ath9k_hw: fix hardware queue allocation

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Felix Fietkau 

commit ad8fdccf9c197a89e2d2fa78c453283dcc2c343f upstream.

The driver passes the desired hardware queue index for a WMM data queue
in qinfo->tqi_subtype. This was ignored in ath9k_hw_setuptxqueue, which
instead relied on the order in which the function is called.

Reported-by: Hubert Feurstein 
Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/ath/ath9k/mac.c |9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -311,14 +311,7 @@ int ath9k_hw_setuptxqueue(struct ath_hw
q = ATH9K_NUM_TX_QUEUES - 3;
break;
case ATH9K_TX_QUEUE_DATA:
-   for (q = 0; q < ATH9K_NUM_TX_QUEUES; q++)
-   if (ah->txq[q].tqi_type ==
-   ATH9K_TX_QUEUE_INACTIVE)
-   break;
-   if (q == ATH9K_NUM_TX_QUEUES) {
-   ath_err(common, "No available TX queue\n");
-   return -1;
-   }
+   q = qinfo->tqi_subtype;
break;
default:
ath_err(common, "Invalid TX queue type: %u\n", type);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 13/77] iwlwifi: mvm: update values for Smart Fifo

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Emmanuel Grumbach 

commit b4c82adcba8cb4b23068a6b800ca98da3bee6888 upstream.

Interoperability issues were identified and root caused to
the Smart Fifo watermarks. These issues arose with
NetGear R7000. Fix this.

Fixes: 1f3b0ff8ecce ("iwlwifi: mvm: Add Smart FIFO support")
Reviewed-by: Johannes Berg 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/iwlwifi/mvm/fw-api.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/iwlwifi/mvm/fw-api.h
+++ b/drivers/net/wireless/iwlwifi/mvm/fw-api.h
@@ -1394,7 +1394,7 @@ enum iwl_sf_scenario {
 #define SF_NUM_TIMEOUT_TYPES 2 /* Aging timer and Idle timer */
 
 /* smart FIFO default values */
-#define SF_W_MARK_SISO 4096
+#define SF_W_MARK_SISO 6144
 #define SF_W_MARK_MIMO2 8192
 #define SF_W_MARK_MIMO3 6144
 #define SF_W_MARK_LEGACY 4096


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 30/77] HID: roccat: potential out of bounds in pyra_sysfs_write_settings()

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Dan Carpenter 

commit 606185b20caf4c57d7e41e5a5ea4aff460aef2ab upstream.

This is a static checker fix.  We write some binary settings to the
sysfs file.  One of the settings is the "->startup_profile".  There
isn't any checking to make sure it fits into the
pyra->profile_settings[] array in the profile_activated() function.

I added a check to pyra_sysfs_write_settings() in both places because
I wasn't positive that the other callers were correct.

Signed-off-by: Dan Carpenter 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hid/hid-roccat-pyra.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/hid/hid-roccat-pyra.c
+++ b/drivers/hid/hid-roccat-pyra.c
@@ -35,6 +35,8 @@ static struct class *pyra_class;
 static void profile_activated(struct pyra_device *pyra,
unsigned int new_profile)
 {
+   if (new_profile >= ARRAY_SIZE(pyra->profile_settings))
+   return;
pyra->actual_profile = new_profile;
pyra->actual_cpi = pyra->profile_settings[pyra->actual_profile].y_cpi;
 }
@@ -257,9 +259,11 @@ static ssize_t pyra_sysfs_write_settings
if (off != 0 || count != PYRA_SIZE_SETTINGS)
return -EINVAL;
 
-   mutex_lock(>pyra_lock);
-
settings = (struct pyra_settings const *)buf;
+   if (settings->startup_profile >= ARRAY_SIZE(pyra->profile_settings))
+   return -EINVAL;
+
+   mutex_lock(>pyra_lock);
 
retval = pyra_set_settings(usb_dev, settings);
if (retval) {


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 03/77] ocfs2: fix journal commit deadlock

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Junxiao Bi 

commit 136f49b9171074872f2a14ad0ab10486d1ba13ca upstream.

For buffer write, page lock will be got in write_begin and released in
write_end, in ocfs2_write_end_nolock(), before it unlock the page in
ocfs2_free_write_ctxt(), it calls ocfs2_run_deallocs(), this will ask
for the read lock of journal->j_trans_barrier.  Holding page lock and
ask for journal->j_trans_barrier breaks the locking order.

This will cause a deadlock with journal commit threads, ocfs2cmt will
get write lock of journal->j_trans_barrier first, then it wakes up
kjournald2 to do the commit work, at last it waits until done.  To
commit journal, kjournald2 needs flushing data first, it needs get the
cache page lock.

Since some ocfs2 cluster locks are holding by write process, this
deadlock may hung the whole cluster.

unlock pages before ocfs2_run_deallocs() can fix the locking order, also
put unlock before ocfs2_commit_trans() to make page lock is unlocked
before j_trans_barrier to preserve unlocking order.

Signed-off-by: Junxiao Bi 
Reviewed-by: Wengang Wang 
Reviewed-by: Mark Fasheh 
Cc: Joel Becker 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/ocfs2/aops.c |   16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

--- a/fs/ocfs2/aops.c
+++ b/fs/ocfs2/aops.c
@@ -899,7 +899,7 @@ void ocfs2_unlock_and_free_pages(struct
}
 }
 
-static void ocfs2_free_write_ctxt(struct ocfs2_write_ctxt *wc)
+static void ocfs2_unlock_pages(struct ocfs2_write_ctxt *wc)
 {
int i;
 
@@ -920,7 +920,11 @@ static void ocfs2_free_write_ctxt(struct
page_cache_release(wc->w_target_page);
}
ocfs2_unlock_and_free_pages(wc->w_pages, wc->w_num_pages);
+}
 
+static void ocfs2_free_write_ctxt(struct ocfs2_write_ctxt *wc)
+{
+   ocfs2_unlock_pages(wc);
brelse(wc->w_di_bh);
kfree(wc);
 }
@@ -2045,11 +2049,19 @@ out_write_size:
di->i_mtime_nsec = di->i_ctime_nsec = 
cpu_to_le32(inode->i_mtime.tv_nsec);
ocfs2_journal_dirty(handle, wc->w_di_bh);
 
+   /* unlock pages before dealloc since it needs acquiring j_trans_barrier
+* lock, or it will cause a deadlock since journal commit threads holds
+* this lock and will ask for the page lock when flushing the data.
+* put it here to preserve the unlock order.
+*/
+   ocfs2_unlock_pages(wc);
+
ocfs2_commit_trans(osb, handle);
 
ocfs2_run_deallocs(osb, >w_dealloc);
 
-   ocfs2_free_write_ctxt(wc);
+   brelse(wc->w_di_bh);
+   kfree(wc);
 
return copied;
 }


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 06/77] ath9k: fix BE/BK queue order

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Felix Fietkau 

commit 78063d81d353e10cbdd279c490593113b8fdae1c upstream.

Hardware queues are ordered by priority. Use queue index 0 for BK, which
has lower priority than BE.

Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/ath/ath9k/hw.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -216,8 +216,8 @@
 #define AH_WOW_BEACON_MISS BIT(3)
 
 enum ath_hw_txq_subtype {
-   ATH_TXQ_AC_BE = 0,
-   ATH_TXQ_AC_BK = 1,
+   ATH_TXQ_AC_BK = 0,
+   ATH_TXQ_AC_BE = 1,
ATH_TXQ_AC_VI = 2,
ATH_TXQ_AC_VO = 3,
 };


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 15/77] ASoC: sigmadsp: Refuse to load firmware files with a non-supported version

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Lars-Peter Clausen 

commit 50c0f21b42dd4cd02b51f82274f66912d9a7fa32 upstream.

Make sure to check the version field of the firmware header to make sure to
not accidentally try to parse a firmware file with a different layout.
Trying to do so can result in loading invalid firmware code to the device.

Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/soc/codecs/sigmadsp.c |7 +++
 1 file changed, 7 insertions(+)

--- a/sound/soc/codecs/sigmadsp.c
+++ b/sound/soc/codecs/sigmadsp.c
@@ -176,6 +176,13 @@ static int _process_sigma_firmware(struc
goto done;
}
 
+   if (ssfw_head->version != 1) {
+   dev_err(dev,
+   "Failed to load firmware: Invalid version %d. Supported 
firmware versions: 1\n",
+   ssfw_head->version);
+   goto done;
+   }
+
crc = crc32(0, fw->data + sizeof(*ssfw_head),
fw->size - sizeof(*ssfw_head));
pr_debug("%s: crc=%x\n", __func__, crc);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 12/77] swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Stefano Stabellini 

commit 2c3fc8d26dd09b9d7069687eead849ee81c78e46 upstream.

Need to pass the pointer within the swiotlb internal buffer to the
swiotlb library, that in the case of xen_unmap_single is dev_addr, not
paddr.

Signed-off-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/xen/swiotlb-xen.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -449,7 +449,7 @@ static void xen_unmap_single(struct devi
 
/* NOTE: We use dev_addr here, not paddr! */
if (is_xen_swiotlb_buffer(dev_addr)) {
-   swiotlb_tbl_unmap_single(hwdev, paddr, size, dir);
+   swiotlb_tbl_unmap_single(hwdev, dev_addr, size, dir);
return;
}
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.14 33/77] kvm: x86: drop severity of "generation wraparound" message

2015-01-13 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Paolo Bonzini 

commit a629df7eadffb03e6ce4a8616e62ea29fdf69b6b upstream.

Since most virtual machines raise this message once, it is a bit annoying.
Make it KERN_DEBUG severity.

Fixes: 7a2e8aaf0f6873b47bc2347f216ea5b0e4c258ab
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kvm/mmu.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4384,7 +4384,7 @@ void kvm_mmu_invalidate_mmio_sptes(struc
 * zap all shadow pages.
 */
if (unlikely(kvm_current_mmio_generation(kvm) == 0)) {
-   printk_ratelimited(KERN_INFO "kvm: zapping shadow pages for 
mmio generation wraparound\n");
+   printk_ratelimited(KERN_DEBUG "kvm: zapping shadow pages for 
mmio generation wraparound\n");
kvm_mmu_invalidate_zap_all_pages(kvm);
}
 }


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.18 126/150] Revert "Input: atmel_mxt_ts - use deep sleep mode when stopped"

2015-01-13 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Linus Torvalds 

commit 7f4054836d811c650c51f9c93088f8ebd61b0020 upstream.

This reverts commit 9d469d033d135d80742a4e39e6bbb4519dd5eee1.

It breaks the Chromebook Pixel touchpad (and touchscreen).

Reported-by: Dirk Hohndel 
Bisected-by: Linus Torvalds 
Cc: Nick Dyer 
Cc: Benson Leung 
Cc: Yufeng Shen 
Cc: Dmitry Torokhov 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/input/touchscreen/atmel_mxt_ts.c |   99 ---
 1 file changed, 26 insertions(+), 73 deletions(-)

--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -99,13 +99,9 @@
 #define MXT_T6_STATUS_COMSERR  (1 << 2)
 
 /* MXT_GEN_POWER_T7 field */
-struct t7_config {
-   u8 idle;
-   u8 active;
-} __packed;
-
-#define MXT_POWER_CFG_RUN  0
-#define MXT_POWER_CFG_DEEPSLEEP1
+#define MXT_POWER_IDLEACQINT   0
+#define MXT_POWER_ACTVACQINT   1
+#define MXT_POWER_ACTV2IDLETO  2
 
 /* MXT_GEN_ACQUIRE_T8 field */
 #define MXT_ACQUIRE_CHRGTIME   0
@@ -117,6 +113,7 @@ struct t7_config {
 #define MXT_ACQUIRE_ATCHCALSTHR7
 
 /* MXT_TOUCH_MULTI_T9 field */
+#define MXT_TOUCH_CTRL 0
 #define MXT_T9_ORIENT  9
 #define MXT_T9_RANGE   18
 
@@ -256,7 +253,6 @@ struct mxt_data {
bool update_input;
u8 last_message_count;
u8 num_touchids;
-   struct t7_config t7_cfg;
 
/* Cached parameters from object table */
u16 T5_address;
@@ -672,6 +668,20 @@ static void mxt_proc_t6_messages(struct
data->t6_status = status;
 }
 
+static int mxt_write_object(struct mxt_data *data,
+u8 type, u8 offset, u8 val)
+{
+   struct mxt_object *object;
+   u16 reg;
+
+   object = mxt_get_object(data, type);
+   if (!object || offset >= mxt_obj_size(object))
+   return -EINVAL;
+
+   reg = object->start_address;
+   return mxt_write_reg(data->client, reg + offset, val);
+}
+
 static void mxt_input_button(struct mxt_data *data, u8 *message)
 {
struct input_dev *input = data->input_dev;
@@ -1742,60 +1752,6 @@ err_free_object_table:
return error;
 }
 
-static int mxt_set_t7_power_cfg(struct mxt_data *data, u8 sleep)
-{
-   struct device *dev = >client->dev;
-   int error;
-   struct t7_config *new_config;
-   struct t7_config deepsleep = { .active = 0, .idle = 0 };
-
-   if (sleep == MXT_POWER_CFG_DEEPSLEEP)
-   new_config = 
-   else
-   new_config = >t7_cfg;
-
-   error = __mxt_write_reg(data->client, data->T7_address,
-   sizeof(data->t7_cfg), new_config);
-   if (error)
-   return error;
-
-   dev_dbg(dev, "Set T7 ACTV:%d IDLE:%d\n",
-   new_config->active, new_config->idle);
-
-   return 0;
-}
-
-static int mxt_init_t7_power_cfg(struct mxt_data *data)
-{
-   struct device *dev = >client->dev;
-   int error;
-   bool retry = false;
-
-recheck:
-   error = __mxt_read_reg(data->client, data->T7_address,
-   sizeof(data->t7_cfg), >t7_cfg);
-   if (error)
-   return error;
-
-   if (data->t7_cfg.active == 0 || data->t7_cfg.idle == 0) {
-   if (!retry) {
-   dev_dbg(dev, "T7 cfg zero, resetting\n");
-   mxt_soft_reset(data);
-   retry = true;
-   goto recheck;
-   } else {
-   dev_dbg(dev, "T7 cfg zero after reset, overriding\n");
-   data->t7_cfg.active = 20;
-   data->t7_cfg.idle = 100;
-   return mxt_set_t7_power_cfg(data, MXT_POWER_CFG_RUN);
-   }
-   }
-
-   dev_dbg(dev, "Initialized power cfg: ACTV %d, IDLE %d\n",
-   data->t7_cfg.active, data->t7_cfg.idle);
-   return 0;
-}
-
 static int mxt_configure_objects(struct mxt_data *data,
 const struct firmware *cfg)
 {
@@ -1809,12 +1765,6 @@ static int mxt_configure_objects(struct
dev_warn(dev, "Error %d updating config\n", error);
}
 
-   error = mxt_init_t7_power_cfg(data);
-   if (error) {
-   dev_err(dev, "Failed to initialize power cfg\n");
-   return error;
-   }
-
error = mxt_initialize_t9_input_device(data);
if (error)
return error;
@@ -2093,15 +2043,16 @@ static const struct attribute_group mxt_
 
 static void mxt_start(struct mxt_data *data)
 {
-   mxt_set_t7_power_cfg(data, MXT_POWER_CFG_RUN);
-
-   /* Recalibrate since chip has been in deep sleep */
-   mxt_t6_command(data, MXT_COMMAND_CALIBRATE, 1, false);
+   /* Touch enable */
+   mxt_write_object(data,
+   

  1   2   3   4   5   6   7   8   9   10   >