[PATCH v2 1/5] ACPICA: OSL: Add direct inclusion of extra header.

[Lv Zheng]

This is a linuxized result of an ACPICA commit to upgrade the extra
header mechanism.

This patch enhances the extra header solution to allow Linux to use
ACPI_USE_NATIVE_INTERFACE_HEADER and the file name can be automatically
replaced during ACPICA release process. Using this way, the rest of the
ACPICA users needn't know the name of the extra header file. Lv Zheng.

Signed-off-by: Lv Zheng 
---
 include/acpi/acpi.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/acpi/acpi.h b/include/acpi/acpi.h
index ca0cb60..682398b 100644
--- a/include/acpi/acpi.h
+++ b/include/acpi/acpi.h
@@ -62,8 +62,8 @@
 #include  /* Resource Descriptor structs */
 #include  /* OSL interfaces (ACPICA-to-OS) */
 #include/* ACPI core subsystem external 
interfaces */
-#ifdef ACPI_NATIVE_INTERFACE_HEADER
-#include ACPI_NATIVE_INTERFACE_HEADER
+#ifdef ACPI_USE_NATIVE_INTERFACE_HEADER
+#include 
 #endif
 
 #endif /* __ACPI_H__ */
-- 
1.7.10

--
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 v2 2/5] ACPICA: Add to remove mis-ordered inclusion of from .

[Lv Zheng]

>From ACPICA's perspective,  should be included after
inclusion of .  But currently in Linux,
 included by  has
included  to find ACPICA types for inline functions.

This causes the following problem:
1. Redundant code in  and :
   Linux must be careful to keep conditions for  inclusion
   consistent with the conditions for  inclusion.
   Which finally leads to the issue that we have to keep many useless macro
   definitions in  or .
   Such conditions include:
 COMPILER_DEPENDENT_UINT64
 COMPILER_DEPENDENT_INT64
 ACPI_INLINE
 ACPI_SYSTEM_XFACE
 ACPI_EXTERNAL_XFACE
 ACPI_INTERNAL_XFACE
 ACPI_INTERNAL_VAR_XFACE
 ACPI_MUTEX_TYPE
 DEBUGGER_THREADING
 ACPI_ACQUIRE_GLOBAL_LOCK
 ACPI_RELEASE_GLOBAL_LOCK
 ACPI_FLUSH_CPU_CACHE
   They have default implementations in 
   while Linux need to keep a copy in  to avoid build errors.
   Typical Linux build error if we deletes COMPILER_DEPENDENT_x and
   ACPI_x_XFACE definitions from asm/acpi.h:
  CC  init/main.o
In file included from include/acpi/platform/aclinux.h:293:0,
 from include/acpi/platform/acenv.h:149,
 from include/acpi/acpi.h:56,
 from include/linux/acpi.h:41,
 from init/main.c:27:
include/acpi/actypes.h:129:1: error: unknown type name 
'COMPILER_DEPENDENT_UINT64'
include/acpi/actypes.h:130:1: error: unknown type name 
'COMPILER_DEPENDENT_INT64'
In file included from include/acpi/platform/aclinux.h:293:0,
 from include/acpi/platform/acenv.h:149,
 from include/acpi/acpi.h:56,
 from include/linux/acpi.h:41,
 from init/main.c:27:
include/acpi/actypes.h:1025:21: error: expected ')' before '*' token
include/acpi/actypes.h:1028:21: error: expected ')' before '*' token
In file included from include/acpi/acpi.h:63:0,
 from include/linux/acpi.h:41,
 from init/main.c:27:
include/acpi/acpiosxf.h:240:7: error: unknown type name 'acpi_osd_handler'
include/acpi/acpiosxf.h:247:6: error: unknown type name 'acpi_osd_handler'
include/acpi/acpiosxf.h:260:3: error: unknown type name 
'acpi_osd_exec_callback'

This patch introduces  to fix this issue by splitting
conditions and declarations (most of them are inline functions) into 2
header files so that the wrong inclusion of  can be removed
from .

Signed-off-by: Lv Zheng 
---
 include/acpi/acpi_opt.h |   90 ++
 include/acpi/platform/aclinux.h |  101 +--
 2 files changed, 101 insertions(+), 90 deletions(-)
 create mode 100644 include/acpi/acpi_opt.h

diff --git a/include/acpi/acpi_opt.h b/include/acpi/acpi_opt.h
new file mode 100644
index 000..51ccbe5
--- /dev/null
+++ b/include/acpi/acpi_opt.h
@@ -0,0 +1,90 @@
+/*
+ * Extra OS specific ACPI defines for Linux.
+ *
+ * Copyright (C) 2014, Intel Corporation
+ * Authors: Lv Zheng 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _ACPI_OPT_H_
+#define _ACPI_OPT_H_
+
+#ifdef __KERNEL__
+
+/*
+ * Overrides for in-kernel ACPICA
+ */
+acpi_status __init acpi_os_initialize(void);
+
+acpi_status acpi_os_terminate(void);
+
+/*
+ * Memory allocation/deallocation
+ */
+
+/*
+ * The irqs_disabled() check is for resume from RAM.
+ * Interrupts are off during resume, just like they are for boot.
+ * However, boot has  (system_state != SYSTEM_RUNNING)
+ * to quiet __might_sleep() in kmalloc() and resume does not.
+ */
+static inline void *acpi_os_allocate(acpi_size size)
+{
+   return kmalloc(size, irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL);
+}
+
+/* Use native linux version of acpi_os_allocate_zeroed */
+
+static inline void *acpi_os_allocate_zeroed(acpi_size size)
+{
+   return kzalloc(size, irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL);
+}
+
+static inline void acpi_os_free(void *memory)
+{
+   kfree(memory);
+}
+
+static inline void *acpi_os_acquire_object(acpi_cache_t *cache)
+{
+   return kmem_cache_zalloc(cache,
+irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL);
+}
+
+static inline acpi_thread_id acpi_os_get_thread_id(void)
+{
+   return (acpi_thread_id)(unsigned long)current;
+}
+
+/*
+ * When lockdep is enabled, the spin_lock_init() macro stringifies it's
+ * argument and uses that as a name for the lock in debugging.
+ * By executing spin_lock_init() in a macro the key changes from "lock" for
+ * all locks to the name of the argument of acpi_os_create_lock(), which
+ * prevents lockdep from reporting false positives for ACPICA locks.
+ */
+#define acpi_os_create_lock(__handle) \
+   ({ \
+   spinlock_t *lock = ACPI_ALLOCATE(sizeof(*lock)); \
+   if (lock) { \
+   *(__h

[PATCH v2 5/5] ACPICA: Remove deprecated _LINUX definitions for ACPICA.

[Lv Zheng]

There are _LINUX defined so that when Linux kernel is compiled using broken
compilers that having not __linux__ defined can still include
 from .

This behavior is deprecated as all drivers/acpi/acpica files are compiled
without including , thus without _LINUX defined.  As there is
no issues encountered when we compile ACPICA code without _LINUX defined,
it is OK to remove _LINUX from  now.

Signed-off-by: Lv Zheng 
---
 include/linux/acpi.h |4 
 1 file changed, 4 deletions(-)

diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 7a8f2cd..9c559f7 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -31,10 +31,6 @@
 
 #ifdef CONFIG_ACPI
 
-#ifndef _LINUX
-#define _LINUX
-#endif
-
 #include 
 #include 
 
-- 
1.7.10

--
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 v2 3/5] ACPICA: Add to remove mis-ordered inclusion of from .

[Lv Zheng]

There is a mis-order inclusion for .

As we will enforce including  for all Linux ACPI users, we
can find the inclusion order is as follows:


  
   
(acenv.h before including aclinux.h)

...
 (aclinux.h before including asm/acpi.h)
  @Redundant@
  (ACPICA specific stuff)
...
...
  (Linux ACPI specific stuff) ? - - - - - - - - - - - - +
 (aclinux.h after including asm/acpi.h)   @Invisible@   |
(acenv.h after including aclinux.h)   @Invisible@   |
   other ACPICA headers   @Invisible@   |
|..
   |
   |
   (Excluded)   |
   (Linux ACPI specific stuff) ! <- - - - - - - - - - - - - +

NOTE that, in ACPICA,  is more like Kconfig
generated  for Linux, it is meant to be included
before including any ACPICA code.

In the above figure, there is a question mark for "Linux ACPI specific
stuff" in  which should be included after including all other
ACPICA header files.  Thus they really need to be moved to the position
marked with exclaimation mark or the definitions in the blocks marked with
"@Invisible@" will be invisible to such architecture specific "Linux ACPI
specific stuff" header blocks.  This leaves 2 issues:
1. All environmental definitions in these blocks should have a copy in the
   area marked with "@Redundant@" if they are required by the "Linux ACPI
   specific stuff".
2. We cannot use any ACPICA defined types in .

This patch splits architecture specific ACPICA stuff from  to
fix this issue.

Signed-off-by: Lv Zheng 
Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: linux-i...@vger.kernel.org
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
---
 arch/ia64/include/asm/acenv.h   |   71 +++
 arch/ia64/include/asm/acpi.h|   50 ---
 arch/x86/include/asm/acenv.h|   65 +++
 arch/x86/include/asm/acpi.h |   45 -
 include/acpi/platform/aclinux.h |2 +-
 5 files changed, 137 insertions(+), 96 deletions(-)
 create mode 100644 arch/ia64/include/asm/acenv.h
 create mode 100644 arch/x86/include/asm/acenv.h

diff --git a/arch/ia64/include/asm/acenv.h b/arch/ia64/include/asm/acenv.h
new file mode 100644
index 000..e0896eb
--- /dev/null
+++ b/arch/ia64/include/asm/acenv.h
@@ -0,0 +1,71 @@
+/*
+ * IA64 specific ACPICA environments and implementation
+ *
+ * Copyright (C) 2014, Intel Corporation
+ *   Author: Lv Zheng 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _ASM_IA64_ACENV_H
+#define _ASM_IA64_ACENV_H
+
+#include 
+
+#define COMPILER_DEPENDENT_INT64   long
+#define COMPILER_DEPENDENT_UINT64  unsigned long
+
+/*
+ * Calling conventions:
+ *
+ * ACPI_SYSTEM_XFACE- Interfaces to host OS (handlers, threads)
+ * ACPI_EXTERNAL_XFACE  - External ACPI interfaces
+ * ACPI_INTERNAL_XFACE  - Internal ACPI interfaces
+ * ACPI_INTERNAL_VAR_XFACE  - Internal variable-parameter list interfaces
+ */
+#define ACPI_SYSTEM_XFACE
+#define ACPI_EXTERNAL_XFACE
+#define ACPI_INTERNAL_XFACE
+#define ACPI_INTERNAL_VAR_XFACE
+
+/* Asm macros */
+
+#define ACPI_FLUSH_CPU_CACHE()
+
+#ifdef CONFIG_ACPI
+
+static inline int
+ia64_acpi_acquire_global_lock(unsigned int *lock)
+{
+   unsigned int old, new, val;
+   do {
+   old = *lock;
+   new = (((old & ~0x3) + 2) + ((old >> 1) & 0x1));
+   val = ia64_cmpxchg4_acq(lock, new, old);
+   } while (unlikely (val != old));
+   return (new < 3) ? -1 : 0;
+}
+
+static inline int
+ia64_acpi_release_global_lock(unsigned int *lock)
+{
+   unsigned int old, new, val;
+   do {
+   old = *lock;
+   new = old & ~0x3;
+   val = ia64_cmpxchg4_acq(lock, new, old);
+   } while (unlikely (val != old));
+   return old & 0x1;
+}
+
+#define ACPI_ACQUIRE_GLOBAL_LOCK(facs, Acq)\
+   ((Acq) = ia64_acpi_acquire_global_lock(&facs->global_lock))
+
+#define ACPI_RELEASE_GLOBAL_LOCK(facs, Acq)\
+   ((Acq) = ia64_acpi_release_global_lock(&facs->global_lock))
+
+#endif
+
+#endif /* _ASM_IA64_ACENV_H */
diff --git a/arch/ia64/include/asm/acpi.h b/arch/ia64/include/asm/acpi.h
index d651102..b0ddcfd 100644
--- a/arch/ia64/include/asm/acpi.h
+++ b/arch/ia64/include/asm/acpi.h
@@ -34,56 +34,6 @@
 #include 
 #include 
 
-#define COMPILER_DEPENDENT_INT64   long
-

[PATCH v2 4/5] ACPICA: Cleanup redudant definitions that already have defaults in .

[Lv Zheng]

Since mis-order issues have been solved, we can cleanup redundant
definitions that already have defaults in .

This patch removes redudant environments for __KERNEL__ surrounded code.

Signed-off-by: Lv Zheng 
Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: linux-i...@vger.kernel.org
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
---
 arch/ia64/include/asm/acenv.h   |   15 ---
 arch/x86/include/asm/acenv.h|   16 
 include/acpi/platform/aclinux.h |1 -
 3 files changed, 32 deletions(-)

diff --git a/arch/ia64/include/asm/acenv.h b/arch/ia64/include/asm/acenv.h
index e0896eb..3f9eaee 100644
--- a/arch/ia64/include/asm/acenv.h
+++ b/arch/ia64/include/asm/acenv.h
@@ -17,23 +17,8 @@
 #define COMPILER_DEPENDENT_INT64   long
 #define COMPILER_DEPENDENT_UINT64  unsigned long
 
-/*
- * Calling conventions:
- *
- * ACPI_SYSTEM_XFACE- Interfaces to host OS (handlers, threads)
- * ACPI_EXTERNAL_XFACE  - External ACPI interfaces
- * ACPI_INTERNAL_XFACE  - Internal ACPI interfaces
- * ACPI_INTERNAL_VAR_XFACE  - Internal variable-parameter list interfaces
- */
-#define ACPI_SYSTEM_XFACE
-#define ACPI_EXTERNAL_XFACE
-#define ACPI_INTERNAL_XFACE
-#define ACPI_INTERNAL_VAR_XFACE
-
 /* Asm macros */
 
-#define ACPI_FLUSH_CPU_CACHE()
-
 #ifdef CONFIG_ACPI
 
 static inline int
diff --git a/arch/x86/include/asm/acenv.h b/arch/x86/include/asm/acenv.h
index 6978584..6687329 100644
--- a/arch/x86/include/asm/acenv.h
+++ b/arch/x86/include/asm/acenv.h
@@ -14,22 +14,6 @@
 
 #include 
 
-#define COMPILER_DEPENDENT_INT64   long long
-#define COMPILER_DEPENDENT_UINT64  unsigned long long
-
-/*
- * Calling conventions:
- *
- * ACPI_SYSTEM_XFACE- Interfaces to host OS (handlers, threads)
- * ACPI_EXTERNAL_XFACE  - External ACPI interfaces
- * ACPI_INTERNAL_XFACE  - Internal ACPI interfaces
- * ACPI_INTERNAL_VAR_XFACE  - Internal variable-parameter list interfaces
- */
-#define ACPI_SYSTEM_XFACE
-#define ACPI_EXTERNAL_XFACE
-#define ACPI_INTERNAL_XFACE
-#define ACPI_INTERNAL_VAR_XFACE
-
 /* Asm macros */
 
 #define ACPI_FLUSH_CPU_CACHE() wbinvd()
diff --git a/include/acpi/platform/aclinux.h b/include/acpi/platform/aclinux.h
index 99d0546..90eea12 100644
--- a/include/acpi/platform/aclinux.h
+++ b/include/acpi/platform/aclinux.h
@@ -48,7 +48,6 @@
 
 #define ACPI_USE_SYSTEM_CLIBRARY
 #define ACPI_USE_DO_WHILE_0
-#define ACPI_MUTEX_TYPE ACPI_BINARY_SEMAPHORE
 
 #ifdef __KERNEL__
 
-- 
1.7.10

--
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 v2 0/5] ACPICA: Fix some mis-ordered inclusions.

[Lv Zheng]

This patch fixes some mis-ordered inclusions for Linux resident ACPICA.

There is no real issue in the Linux kernel, but this can help to cleanup
the code so that (benefits):
1. Redundant environment definitions can be removed from  and
   .
2. Lift a burden off the ACPICA release automation - copying default ACPICA
   environment setting to all  file each time a new environment
   is introduced just in order to avoid build errors.
3. The wrong  inclusion can be removed from
   .
4. Using ACPICA defined types in  is possible.
5. Using "static inline" to define ACPICA OSL functions is still possible
   and won't cause build errors any longer.
6. All non back ported prototypes are collected in a single file.

The patch set has passed the following build/boot tests.
Build tests are performed as follows:
1. i386 + default + COFNIG_ACPI=y
2. i386 + default + COFNIG_ACPI=n
3. x86_64 + default + COFNIG_ACPI=y
4. x86_64 + default + COFNIG_ACPI=n
Boot tests are performed as follows:
1. i386 + default + COFNIG_ACPI=y
2. x86_64 + default + COFNIG_ACPI=y
Where:
1. i386: machine named as "Dell Inspiron Mini 1010"
2. x86_64: machine named as "HP Compaq 8200 Elite SFF PC"
3. default: kernel configuration with following items enabled:
   All hardware drivers related to the machines of i386/x86_64
   All drivers/acpi configurations
   All platform drivers
   All ACPI drivers
   4 DRM drivers that implement ACPI opregion
   All buses with ACPI bindings
   All cpufreq configurations
   All xen configurations
   All ACPI tabln drivers

Lv Zheng (5):
  ACPICA: OSL: Add direct inclusion of extra header.
  ACPICA: Add  to remove mis-ordered inclusion of
 from .
  ACPICA: Add  to remove mis-ordered inclusion of
 from .
  ACPICA: Cleanup redudant definitions that already have defaults in
.
  ACPICA: Remove deprecated _LINUX definitions for ACPICA.

 arch/ia64/include/asm/acenv.h   |   56 +
 arch/ia64/include/asm/acpi.h|   50 ---
 arch/x86/include/asm/acenv.h|   49 ++
 arch/x86/include/asm/acpi.h |   45 -
 include/acpi/acpi.h |4 +-
 include/acpi/acpi_opt.h |   90 +
 include/acpi/platform/aclinux.h |  104 +--
 include/linux/acpi.h|4 --
 8 files changed, 209 insertions(+), 193 deletions(-)
 create mode 100644 arch/ia64/include/asm/acenv.h
 create mode 100644 arch/x86/include/asm/acenv.h
 create mode 100644 include/acpi/acpi_opt.h

-- 
1.7.10

--
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 19/28] nios2: Device tree support

[Ley Foon Tan]

On Tue, Apr 22, 2014 at 9:42 PM, Arnd Bergmann  wrote:
> On Friday 18 April 2014, Ley Foon Tan wrote:
>> diff --git a/arch/nios2/boot/dts/3c120_devboard.dts 
>> b/arch/nios2/boot/dts/3c120_devboard.dts

>> +/dts-v1/;
>> +
>> +/ {
>> + model = "ALTR,qsys_ghrd_3c120";
>> + compatible = "ALTR,qsys_ghrd_3c120";
>
> You have a mix of "ALTR" and "altr" prefixes. The general recommendation
> is to use lower-case letters, which is also what is used on ARM socfpga,
> and what is documented in 
> Documentation/devicetree/bindings/vendor-prefixes.txt
> for Altera.
Yes, the vendor prefix should be changed to lower case. FYI, this dts
file is generated by our dts generator tool called sopc2dts.
Our tool already aware of this requirement, but haven't support this yet.
I can edit this file manually to change 'ALTR' to 'altr', but I will
update nios2 code to match for both "ALTR" and "altr" for backward
compatibility. "ALTR" will be deprecated later. Are you okay with
this?


>
>> + sopc@0 {
>> + device_type = "soc";
>> + ranges;
>> + #address-cells = < 1 >;
>> + #size-cells = < 1 >;
>> + compatible = "ALTR,avalon", "simple-bus";
>> + bus-frequency = < 12500 >;
>> +
>> + pb_cpu_to_io: bridge@0x800 {
>> + compatible = "simple-bus";
>> + reg = < 0x0800 0x0080 >;
>
> Are these all synthesized devices, or is there also some hardwired
> logic? It often makes sense to split out the reusable parts into
> a separate .dtsi file that gets included by every implementation.
All these are synthesized devices and the system hierarchy is also not
fixed and it is depends on user hardware design. It is highly
configurable.
So, we can't have a common .dtsi file.

>
>> + #address-cells = < 1 >;
>> + #size-cells = < 1 >;
>> + ranges = < 0x0040 0x0840 0x0020
>> + 0x4D40 0x08004D40 0x0008
>> + 0x4D50 0x08004D50 0x0008
>> + 0x4000 0x08004000 0x0400
>> + 0x4400 0x08004400 0x0040
>> + 0x4800 0x08004800 0x0040
>> + 0x2000 0x08002000 0x2000
>> + 0x4C80 0x08004C80 0x0020
>> + 0x4CC0 0x08004CC0 0x0010
>> + 0x4CE0 0x08004CE0 0x0010
>> + 0x4D00 0x08004D00 0x0010 >;
>
> A few style comments:
>
> - no whitespace in the after '<' or before '>
> - put each entry into its own '<...>' group.
> - lower-case characters for hex digits
Okay, I will change this and I will feedback this to our dts generator
tool team to support these format in future.

> - The ranges should reflect what the bus actually translates,
>   which is typically not individual bytes but rather whole
>   address ranges.
The ranges here reflect the address range translate by each device and
user can assign any base address they desired in our FPGA. The address
ranges might not in continuous regions as well. So, we will keep this
translation way.

> - sort numerically.
>
> The above could look like
>
> ranges = <0x 0x0800 0x0001>,
>  <0x0040 0x0840 0x1000>;
Okay, I will sort this.

>
>> + timer_1ms: timer@0x40 {
>> + compatible = "ALTR,timer-1.0";
>> +
>> + sysid: sysid@0x4d40 {
>> + compatible = "ALTR,sysid-1.0";
>> + reg = < 0x4D40 0x0008 >;
>
>> + jtag_uart: serial@0x4d50 {
>> + compatible = "ALTR,juart-1.0";
>> + reg = < 0x4D50 0x0008 >;
>> +
>> + tse_mac: ethernet@0x4000 {
>> + compatible = "ALTR,tse-1.0";
>
>
> Does each one of these have a binding document in
> Documentation/devicetree/bindings?
jtag_uart and tse drivers are upstreamed. They already have their own
bindings doc:
Documentation/devicetree/bindings/serial/altera_jtaguart.txt
Documentation/devicetree/bindings/net/altera_tse.txt

I will add the binding doc for timer, but sysid driver is not in
mainline kernel yet. I will remove sysid entry from this file.

>
> I've looked only at the tse binding, which you seem to be
> violating in a few places:
>
> - compatible string is "ALTR,tse-1.0", not "altr,tse-1.0"
I will change to  "altr,tse-1.0".

>
>> + reg = < 0x4000 0x0400
>> + 0x4400 0x0040
>> + 0x4800 0x0040
>> + 0x2000 0x2000 >;
>> + 

Re: [PATCH v6 06/19] usb: phy: msm: Fix checkpatch.pl warnings

[Ivan T. Ivanov]

On Tue, 2014-04-22 at 16:30 +0100, Srinivas Kandagatla wrote:
> 
> On 22/04/14 10:20, Ivan T. Ivanov wrote:
> > @@ -79,8 +78,7 @@ static int msm_hsusb_init_vddcx(struct msm_otg *motg, int 
> > init)
> > ret = regulator_set_voltage(motg->vddcx, 0,
> > USB_PHY_VDD_DIG_VOL_MAX);
> > if (ret)
> > -   dev_err(motg->phy.dev, "unable to set the voltage "
> > -   "for hsusb vddcx\n");
> > +   dev_err(motg->phy.dev, "Cannot set vddcx voltage\n");
> 
> 
> > @@ -137,15 +133,13 @@ static int msm_hsusb_ldo_set_mode(struct msm_otg 
> > *motg, int on)
> > ret = regulator_set_optimum_mode(motg->v1p8,
> > USB_PHY_1P8_HPM_LOAD);
> > if (ret < 0) {
> > -   pr_err("%s: Unable to set HPM of the regulator "
> > -   "HSUSB_1p8\n", __func__);
> > +   pr_err("Could not set HPM for v1p8\n");
> > return ret;
> > }
> 
> 
> > @@ -390,8 +382,7 @@ static int msm_hsusb_config_vddcx(struct msm_otg *motg, 
> > int high)
> >
> > ret = regulator_set_voltage(motg->vddcx, min_vol, max_vol);
> > if (ret) {
> > -   pr_err("%s: unable to set the voltage for regulator "
> > -   "HSUSB_VDDCX\n", __func__);
> > +   dev_err(motg->phy.dev, "Cannot set vddcx voltage\n");
> > return ret;
> > }
> >
> 
> 
> I see some of pr_err not moved to dev_err?, while others have been moved.

Right, intention was to just shorten messages to fit one line, to make 
checkpatch.pl happy.

Thanks, 
Ivan

> Also noticed that the error messages are changed as part of this fix. 
> IMHO, changing an error message would have a side-effects on logging 
> tools, anyway Am not sure if its true in this case.
> 
> Thanks,
> srini
> --

--
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: [Resend Patch 9/9] I2C/ACPI: Add CONFIG_I2C_ACPI config

[Zheng, Lv]

Hi, Tianyu

> From: Lan, Tianyu
> Sent: Wednesday, April 23, 2014 1:40 PM
> 
> On 2014年04月22日 19:45, Mika Westerberg wrote:
> > On Tue, Apr 22, 2014 at 02:24:15PM +0800, Lan Tianyu wrote:
> >> This patch is to add CONFIG_I2C_ACPI. Current there is a race between
> >> removing I2C ACPI operation region and ACPI AML code accessing.
> >> So make i2c core built-in if CONFIG_I2C_ACPI is set.
> >>
> >> Signed-off-by: Lan Tianyu 
> >> ---
> >>  drivers/i2c/Kconfig  | 17 -
> >>  drivers/i2c/Makefile |  2 +-
> >>  include/linux/i2c.h  |  2 +-
> >>  3 files changed, 18 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
> >> index 7b7ea32..c670d49 100644
> >> --- a/drivers/i2c/Kconfig
> >> +++ b/drivers/i2c/Kconfig
> >> @@ -2,7 +2,9 @@
> >>  # I2C subsystem configuration
> >>  #
> >>
> >> -menuconfig I2C
> >> +menu "I2C support"
> >> +
> >> +config I2C
> >>tristate "I2C support"
> >>select RT_MUTEXES
> >>---help---
> >> @@ -21,6 +23,17 @@ menuconfig I2C
> >>  This I2C support can also be built as a module.  If so, the module
> >>  will be called i2c-core.
> >>
> >> +config I2C_ACPI
> >> +  bool "I2C ACPI support"
> >> +  select I2C
> >> +  depends on ACPI
> >> +  default y
> >> +  help
> >> +Say Y here if you want to enable I2C ACPI function. ACPI table
> >> +provides I2C slave devices' information to enumerate these devices.
> >> +This option also allows ACPI AML code to access I2C slave devices
> >> +via I2C ACPI operation region to fulfill ACPI method.
> >> +
> >
> > I'm wondering, can we provide some sort of wrapper function from ACPI core
> > that is guaranteed to be built in to the kernel image and use it instead of
> > adding new Kconfig options?
> >
> Cc: LV
> 
> LV tried to fix the issue via wrapper solution in the ACPI code before.
> https://lkml.org/lkml/2013/7/23/87
> 
> He has a plan to resolve the issue in ACPICA later.
> 
> Other choice is to increase the i2c-core module count to prevent it
> being unloaded when i2c operation region handler is installed. Remove
> the code When LV finish his job.

You may see it implemented in ACPICA after several release.
If you need a fix for now, you can use the patch pointed to by the link you've 
provided,
Or you could find an updated one here:
 acpi-ipmi13.patch archived in 
(https://bugzilla.kernel.org/attachment.cgi?id=112611)

I think the solution you've provided in this patch is also reasonable for now.
IPMI also uses a similar solution to solve this issue.
Please refer to the CONFIG_ACPI_IPMI.

The story can be found at:
http://www.spinics.net/lists/linux-acpi/msg49044.html
And the similar solution can be found at:
http://www.spinics.net/lists/linux-acpi/msg49184.html

Thanks and best regards
-Lv

> 
> --
> Best regards
> Tianyu Lan
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH 2/4] mm/memcontrol.c: use accessor to get id from css

[Jianyu Zhan]

On Wed, Apr 23, 2014 at 3:49 AM, Andrew Morton
 wrote:
> I'd expect Tejun to process this series, but you didn't cc him on 2/4.

Oh, I reposed too much confidence in get_maintainer.pl.  I thought it
would cc tj as usual. :-)

Tj said he has a patchset queued for addressing this problem and will
be sent out soon,
so just forget this patch and wait.


Thanks,
Jianyu Zhan
--
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 v2 1/2] perf record: Propagate exit status of a command line workload

[Namhyung Kim]

Currently perf record doesn't propagate the exit status of a workload
given by the command line.  But sometimes it'd useful if it's
propagated so that a monitoring script can handle errors
appropriately.

To do that, it got rid of exit handlers and run/call them directly in
the __cmd_record().  I don't see any reason why those are in a form of
exit handlers in the first place.  Also it cleaned up the resouce
management code in record__exit().

With this change, perf record returns the child exit status in case of
normal termination.  (Not sure what should be returned on abnormal
cases though).

Example run of Stephane's case:

  $ perf record false && echo yes || echo no
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.013 MB perf.data (~589 samples) ]
  no

And Jiri's case (error in parent):

  $ perf record -m 10G true && echo yes || echo no
  rounding mmap pages size to 17179869184 bytes (4194304 pages)
  failed to mmap with 12 (Cannot allocate memory)
  no

Reported-by: Stephane Eranian 
Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-record.c | 119 ++--
 1 file changed, 49 insertions(+), 70 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index eb524f91bffe..d315be9e9be2 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -152,26 +152,6 @@ static void sig_handler(int sig)
signr = sig;
 }
 
-static void record__sig_exit(int exit_status __maybe_unused, void *arg)
-{
-   struct record *rec = arg;
-   int status;
-
-   if (rec->evlist->workload.pid > 0) {
-   if (!child_finished)
-   kill(rec->evlist->workload.pid, SIGTERM);
-
-   wait(&status);
-   if (WIFSIGNALED(status))
-   psignal(WTERMSIG(status), rec->progname);
-   }
-
-   if (signr == -1 || signr == SIGUSR1)
-   return;
-
-   signal(signr, SIG_DFL);
-}
-
 static int record__open(struct record *rec)
 {
char msg[512];
@@ -243,27 +223,6 @@ static int process_buildids(struct record *rec)
  size, 
&build_id__mark_dso_hit_ops);
 }
 
-static void record__exit(int status, void *arg)
-{
-   struct record *rec = arg;
-   struct perf_data_file *file = &rec->file;
-
-   if (status != 0)
-   return;
-
-   if (!file->is_pipe) {
-   rec->session->header.data_size += rec->bytes_written;
-
-   if (!rec->no_buildid)
-   process_buildids(rec);
-   perf_session__write_header(rec->session, rec->evlist,
-  file->fd, true);
-   perf_session__delete(rec->session);
-   perf_evlist__delete(rec->evlist);
-   symbol__exit();
-   }
-}
-
 static void perf_event__synthesize_guest_os(struct machine *machine, void 
*data)
 {
int err;
@@ -356,6 +315,7 @@ static void workload_exec_failed_signal(int signo, 
siginfo_t *info,
 static int __cmd_record(struct record *rec, int argc, const char **argv)
 {
int err;
+   int status = 0;
unsigned long waking = 0;
const bool forks = argc > 0;
struct machine *machine;
@@ -367,7 +327,6 @@ static int __cmd_record(struct record *rec, int argc, const 
char **argv)
 
rec->progname = argv[0];
 
-   on_exit(record__sig_exit, rec);
signal(SIGCHLD, sig_handler);
signal(SIGINT, sig_handler);
signal(SIGTERM, sig_handler);
@@ -394,26 +353,21 @@ static int __cmd_record(struct record *rec, int argc, 
const char **argv)
 
if (record__open(rec) != 0) {
err = -1;
-   goto out_delete_session;
+   goto out_child;
}
 
if (!rec->evlist->nr_groups)
perf_header__clear_feat(&session->header, HEADER_GROUP_DESC);
 
-   /*
-* perf_session__delete(session) will be called at record__exit()
-*/
-   on_exit(record__exit, rec);
-
if (file->is_pipe) {
err = perf_header__write_pipe(file->fd);
if (err < 0)
-   goto out_delete_session;
+   goto out_child;
} else {
err = perf_session__write_header(session, rec->evlist,
 file->fd, false);
if (err < 0)
-   goto out_delete_session;
+   goto out_child;
}
 
if (!rec->no_buildid
@@ -421,7 +375,7 @@ static int __cmd_record(struct record *rec, int argc, const 
char **argv)
pr_err("Couldn't generate buildids. "
   "Use --no-buildid to profile anyway.\n");
err = -1;
-   goto out_delete_session;
+   goto out_child;
}
 
machine = &session->machines.host;
@@ -431,7 +385,7 @@ stat

[PATCH v2 2/2] perf tools: Get rid of on_exit() feature test

[Namhyung Kim]

The on_exit() function was only used in perf record but it's gone in
previous patch.

Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-record.c | 31 -
 tools/perf/config/Makefile  |  8 ---
 tools/perf/config/feature-checks/Makefile   |  4 
 tools/perf/config/feature-checks/test-all.c |  5 
 tools/perf/config/feature-checks/test-on-exit.c | 16 -
 5 files changed, 64 deletions(-)
 delete mode 100644 tools/perf/config/feature-checks/test-on-exit.c

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index d315be9e9be2..34f8c11e833b 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -30,37 +30,6 @@
 #include 
 #include 
 
-#ifndef HAVE_ON_EXIT_SUPPORT
-#ifndef ATEXIT_MAX
-#define ATEXIT_MAX 32
-#endif
-static int __on_exit_count = 0;
-typedef void (*on_exit_func_t) (int, void *);
-static on_exit_func_t __on_exit_funcs[ATEXIT_MAX];
-static void *__on_exit_args[ATEXIT_MAX];
-static int __exitcode = 0;
-static void __handle_on_exit_funcs(void);
-static int on_exit(on_exit_func_t function, void *arg);
-#define exit(x) (exit)(__exitcode = (x))
-
-static int on_exit(on_exit_func_t function, void *arg)
-{
-   if (__on_exit_count == ATEXIT_MAX)
-   return -ENOMEM;
-   else if (__on_exit_count == 0)
-   atexit(__handle_on_exit_funcs);
-   __on_exit_funcs[__on_exit_count] = function;
-   __on_exit_args[__on_exit_count++] = arg;
-   return 0;
-}
-
-static void __handle_on_exit_funcs(void)
-{
-   int i;
-   for (i = 0; i < __on_exit_count; i++)
-   __on_exit_funcs[i] (__exitcode, __on_exit_args[i]);
-}
-#endif
 
 struct record {
struct perf_tooltool;
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index ee21fa95ebcf..7b7003d11983 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -156,7 +156,6 @@ CORE_FEATURE_TESTS =\
libpython-version   \
libslang\
libunwind   \
-   on-exit \
stackprotector-all  \
timerfd \
libdw-dwarf-unwind
@@ -182,7 +181,6 @@ VF_FEATURE_TESTS =  \
libelf-getphdrnum   \
libelf-mmap \
libpython-version   \
-   on-exit \
stackprotector-all  \
timerfd \
libunwind-debug-frame   \
@@ -541,12 +539,6 @@ ifneq ($(filter -lbfd,$(EXTLIBS)),)
   CFLAGS += -DHAVE_LIBBFD_SUPPORT
 endif
 
-ifndef NO_ON_EXIT
-  ifeq ($(feature-on-exit), 1)
-CFLAGS += -DHAVE_ON_EXIT_SUPPORT
-  endif
-endif
-
 ifndef NO_BACKTRACE
   ifeq ($(feature-backtrace), 1)
 CFLAGS += -DHAVE_BACKTRACE_SUPPORT
diff --git a/tools/perf/config/feature-checks/Makefile 
b/tools/perf/config/feature-checks/Makefile
index 2da103c53f89..64c84e5f0514 100644
--- a/tools/perf/config/feature-checks/Makefile
+++ b/tools/perf/config/feature-checks/Makefile
@@ -24,7 +24,6 @@ FILES=\
test-libslang.bin   \
test-libunwind.bin  \
test-libunwind-debug-frame.bin  \
-   test-on-exit.bin\
test-stackprotector-all.bin \
test-timerfd.bin\
test-libdw-dwarf-unwind.bin
@@ -133,9 +132,6 @@ test-liberty-z.bin:
 test-cplus-demangle.bin:
$(BUILD) -liberty
 
-test-on-exit.bin:
-   $(BUILD)
-
 test-backtrace.bin:
$(BUILD)
 
diff --git a/tools/perf/config/feature-checks/test-all.c 
b/tools/perf/config/feature-checks/test-all.c
index fc37eb3ca17b..fe5c1e5c952f 100644
--- a/tools/perf/config/feature-checks/test-all.c
+++ b/tools/perf/config/feature-checks/test-all.c
@@ -69,10 +69,6 @@
 # include "test-libbfd.c"
 #undef main
 
-#define main main_test_on_exit
-# include "test-on-exit.c"
-#undef main
-
 #define main main_test_backtrace
 # include "test-backtrace.c"
 #undef main
@@ -110,7 +106,6 @@ int main(int argc, char *argv[])
main_test_gtk2(argc, argv);
main_test_gtk2_infobar(argc, argv);
main_test_libbfd();
-   main_test_on_exit();
main_test_backtrace();
main_test_libnuma();
main_test_timerfd();
diff --git a/tools/perf/config/feature-checks/test-on-exit.c 
b/tools/perf/config/feature-checks/test-on-exit.c
deleted file mode 100644
index 8e88b16e6ded..
--- a/tools/perf/config/feature-checks/test-on-exit.c
+++ /dev/null
@@ -1,16 +0,0 @@
-#include 
-#include 
-
-static void exit_fn(int status, void *__data)
-{
-   printf("exit status: %d, data: %d\n", status, *(int *)__data);
-}
-
-static int data = 123;
-
-int main(void)
-{
-   on_exit(exit_fn, &data);
-
-   return 321;
-}
-- 
1.9.2

--
To unsubscribe fr

Re: [RESEND PATCH v3 8/9] tty: cadence: Document DT binding

[Michal Simek]

On 04/05/2014 02:23 AM, Soren Brinkmann wrote:
> Add binding documentation for the Cadence UART.
> 
> Signed-off-by: Soren Brinkmann 
> Acked-by: Peter Crosthwaite 
> Acked-by: Rob Herring 
> Tested-by: Michal Simek 
> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  .../devicetree/bindings/serial/cdns,uart.txt | 20 
> 
>  1 file changed, 20 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/serial/cdns,uart.txt
> 
> diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.txt 
> b/Documentation/devicetree/bindings/serial/cdns,uart.txt
> new file mode 100644
> index ..a3eb154c32ca
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/cdns,uart.txt
> @@ -0,0 +1,20 @@
> +Binding for Cadence UART Controller
> +
> +Required properties:
> +- compatible : should be "cdns,uart-r1p8", or "xlnx,xuartps"
> +- reg: Should contain UART controller registers location and length.
> +- interrupts: Should contain UART controller interrupts.
> +- clocks: Must contain phandles to the UART clocks
> +  See ../clocks/clock-bindings.txt for details.
> +- clock-names: Tuple to identify input clocks, must contain "uart_clk" and 
> "pclk"
> +  See ../clocks/clock-bindings.txt for details.
> +
> +
> +Example:
> + uart@e000 {
> + compatible = "cdns,uart-r1p8";
> + clocks = <&clkc 23>, <&clkc 40>;
> + clock-names = "uart_clk", "pclk";
> + reg = <0xE000 0x1000>;
> + interrupts = <0 27 4>;
> + };
> 

Applied to zynq/dt2 branch.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature

Re: [RESEND PATCH v3 9/9] ARM: zynq: DT: Migrate UART to Cadence binding

[Michal Simek]

On 04/05/2014 02:23 AM, Soren Brinkmann wrote:
> The Zynq UART is Cadence IP and the driver has been renamed accordingly.
> Migrate the DT to use the new binding for the UART driver.
> 
> Signed-off-by: Soren Brinkmann 
> Acked-by: Peter Crosthwaite 
> Acked-by: Rob Herring 
> Tested-by: Michal Simek 
> ---
> This change depends on 'tty: xuartps: Rebrand driver as Cadence UART',
> which introduces the new clock-names.
> 
> Changes in v3: None
> Changes in v2: None
> 
> Signed-off-by: Soren Brinkmann 
> ---
>  arch/arm/boot/dts/zynq-7000.dtsi | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/zynq-7000.dtsi 
> b/arch/arm/boot/dts/zynq-7000.dtsi
> index 789d0bacc110..d27eb5c21831 100644
> --- a/arch/arm/boot/dts/zynq-7000.dtsi
> +++ b/arch/arm/boot/dts/zynq-7000.dtsi
> @@ -73,19 +73,19 @@
>   };
>  
>   uart0: uart@e000 {
> - compatible = "xlnx,xuartps";
> + compatible = "xlnx,xuartps", "cdns,uart-r1p8";
>   status = "disabled";
>   clocks = <&clkc 23>, <&clkc 40>;
> - clock-names = "ref_clk", "aper_clk";
> + clock-names = "uart_clk", "pclk";
>   reg = <0xE000 0x1000>;
>   interrupts = <0 27 4>;
>   };
>  
>   uart1: uart@e0001000 {
> - compatible = "xlnx,xuartps";
> + compatible = "xlnx,xuartps", "cdns,uart-r1p8";
>   status = "disabled";
>   clocks = <&clkc 24>, <&clkc 41>;
> - clock-names = "ref_clk", "aper_clk";
> + clock-names = "uart_clk", "pclk";
>   reg = <0xE0001000 0x1000>;
>   interrupts = <0 50 4>;
>   };
> 

Applied to zynq/dt2 branch.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

[H. Peter Anvin]

On 04/22/2014 10:04 AM, Linus Torvalds wrote:


The segment table is shared for a process. So you can have one thread
doing a load_ldt() that invalidates a segment, while another thread is
busy taking a page fault. The segment was valid at page fault time and
is saved on the kernel stack, but by the time the page fault returns,
it is no longer valid and the iretq will fault.

Anyway, if done correctly, this whole espfix should be totally free
for normal processes, since it should only trigger if SS is a LDT
entry (bit #2 set in the segment descriptor). So the normal fast-path
should just have a simple test for that.

And if you have a SS that is a descriptor in the LDT, nobody cares
about performance any more.



I just realized that with the LDT being a process-level object (unlike 
the GDT), we need to remove the filtering on the espfix hack, both for 
32-bit and 64-bit kernels.  Otherwise there is a race condition between 
executing the LAR instruction in the filter and the IRET, which could 
allow the leak to become manifest.


The "good" part is that I think the espfix hack is harmless even with a 
32/64-bit stack segment, although it has a substantial performance penalty.


Does anyone have any idea if there is a real use case for non-16-bit LDT 
segments used as the stack segment?  Does Wine use anything like that?


Very old NPTL Linux binaries use LDT segments, but only for data segments.

-hpa


--
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] mmc: dw_mmc: Don't print data errors

[Seungwon Jeon]

On Wed, April 23, 2014, Doug Anderson wrote:
> Data errors are completely expected during tuning.  Printing them out
> is confusing people looking at the kernel logs.  They see things like:
> 
>  [3.613296] dwmmc_exynos 1220.dwmmc0: data error, status 0x0088
> 
> ...and they think something is wrong with their hardware.
> 
> Remove the printouts.  We'll leave it up to a higher level to report
> about errors.
Yes, your saying makes sense.
But in normal I/O, actual error information such as status below is useful, 
isn't it?

Thanks,
Seungwon Jeon

> 
> Signed-off-by: Doug Anderson 
> ---
>  drivers/mmc/host/dw_mmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index cced599..4c8d423 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1248,7 +1248,7 @@ static int dw_mci_data_complete(struct dw_mci *host, 
> struct mmc_data *data)
>   data->error = -EIO;
>   }
> 
> - dev_err(host->dev, "data error, status 0x%08x\n", status);
> + dev_dbg(host->dev, "data error, status 0x%08x\n", status);
> 
>   /*
>* After an error, there may be data lingering
> --
> 1.9.1.423.g4596e3a
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
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 1/4] cpuidle: config: Add SOC_EXYNOS5420 entry to select cpuidle-big-little driver

[Chander Kashyap]

Hi Daniel,

On 22 April 2014 16:12, Daniel Lezcano  wrote:
> On 04/21/2014 01:49 PM, Chander Kashyap wrote:
>>
>> Exynos5420 is a big-little SoC from Samsung. It has 4 A15 and 4 A7 cores.
>> In order to use generic cpuidle-big-little driver, this patch adds
>> Exynos5420
>> specific check to initialize generic cpuidle driver.
>>
>> Signed-off-by: Chander Kashyap 
>> Signed-off-by: Chander Kashyap 
>> ---
>>   drivers/cpuidle/Kconfig.arm |2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
>> index 97ccc31..5244d87 100644
>> --- a/drivers/cpuidle/Kconfig.arm
>> +++ b/drivers/cpuidle/Kconfig.arm
>> @@ -4,7 +4,7 @@
>>
>>   config ARM_BIG_LITTLE_CPUIDLE
>> bool "Support for ARM big.LITTLE processors"
>> -   depends on ARCH_VEXPRESS_TC2_PM
>> +   depends on ARCH_VEXPRESS_TC2_PM || SOC_EXYNOS5420
>
>
> For the sake of consistency, I would prefer:
>
> depends on ARCH_VEXPRESS_TC2_PM || ARCH_EXYNOS

Yes i will change it.

Thanks
>
> and let the current code (and future platform driver) to handle the loading
> of the driver.
>
>
>> select ARM_CPU_SUSPEND
>> select CPU_IDLE_MULTIPLE_DRIVERS
>> help
>>
>
>
> --
>   Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro:   Facebook |
>  Twitter |
>  Blog
>



-- 
with warm regards,
Chander Kashyap
--
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: [PATCHSET 00/17] perf report: Add -F option for specifying output fields (v4)

[Namhyung Kim]

Hi Don,

On Tue, 22 Apr 2014 17:16:47 -0400, Don Zickus wrote:
> On Wed, Apr 16, 2014 at 12:05:37PM +0900, Namhyung Kim wrote:
>> Hello,
>> 
>> This is a patchset implementing -F/--fields option to setup output
>> field/column as Ingo requested.  It depends on my --percentage
>> patchset [1].
>> 
>> The -F option can receive any sort keys that -s option recognize, plus
>> following fields (name can be changed):
>> 
>>   overhead, overhead_sys, overhead_us, sample, period
>> 
>> The overhead_guest_sys and overhead_guest_us might be avaiable when
>> you profile guest machines.
>> 
>> Output will be sorted by in order of fields and sort keys passed by -s
>> option will be added to the output field list automatically.  If you
>> want to change the order of sorting you can give -s option in addition
>> to -F option.  To support old behavior, it'll also prepend 'overhead'
>> field to the sort keys unless you give -F option explicitly.
>
> So I am struggling a little bit to get this working correctly.  I had it
> in my head that I could sort internally with -s and re-sort the output
> based on -F, but it doesn't seem to be working that way.

Hmm.. probably it's me miss something on perf mem side..  I don't have
an access to a machine to test it now.

>
> For example with
>
> ./perf mem record -a grep -r foo /* > /dev/null
> ./perf mem report -F overhead,symbol_daddr,pid -s symbol_daddr,pid --stdio 
>
> I was thinking I could sort everything based on the symbol_daddr and pid.
> Then re-sort the output to display the highest 'symbol_daddr,pid' pair.
> But it didn't seem to work that way.  Instead it seems like I get the
> original sort just displayed in the -F format.

Could you please show me the output of your example?

Thanks,
Namhyung
--
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 04/10] drm/nouveau/fb: add GK20A support

[Alexandre Courbot]

On Wed, Apr 23, 2014 at 11:07 AM, Alexandre Courbot  wrote:
> On 04/22/2014 07:40 PM, Thierry Reding wrote:
>>
>> * PGP Signed by an unknown key
>>
>>
>> On Mon, Apr 21, 2014 at 03:02:16PM +0900, Alexandre Courbot wrote:
>> [...]
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c
>>> b/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c
>>
>> [...]
>>>
>>> +   pages = dma_alloc_from_contiguous(dev, ncmin, order);
>>> +   if (!pages) {
>>> +   gk20a_ram_put(pfb, &mem);
>>> +   return -ENOMEM;
>>> +   }
>>> +
>>> +   dma_addr = pfn_to_dma(nv_device_base(nv_device(pfb)),
>>> + page_to_pfn(pages));
>>
>>
>> This breaks compilation on x86 because neither pfn_to_dma() nor
>> dma_to_pfn() are available. Is there some other way this can be
>> allocated so that these functions don't need to be called?
>
>
> Mmm, this is bad. There is probably another more portable way to do this.
> Let me look for it.

page_to_phys()/phys_to_page() can be used by drivers and will work
just fine here since the CPU and GPU use the same physical addresses
to access memory.

Thanks,
Alex.
--
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/

[GIT PULL] serial: Cadence

[Michal Simek]

Hi Greg,

this is around for a while and I would like to close it.
I have applied patches 1-7 from v3.
Patches 8 and 9 should go through arm-soc tree and I will add them
to my zynq/dt branch.

Please apply these patches to your tree.
If this should go through different tree please let me know.

Thanks,
Michal


The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5:

  Linux 3.15-rc1 (2014-04-13 14:18:35 -0700)

are available in the git repository at:

  git://git.monstr.eu/linux-2.6-microblaze.git tags/cadence-uart-for-3.16

for you to fetch changes up to 05a06a30d212f76e7822ef1093fa002baac021a7:

  tty: xuartps: Rebrand driver as Cadence UART (2014-04-23 08:00:10 +0200)


tty: Cadence uart rebranding and cleanup


Michal Simek (2):
  tty: xuartps: Fix kernel-doc errors in the driver
  tty: xuartps: Initialize ports according to aliases

Soren Brinkmann (5):
  tty: xuartps: Clean up
  tty: xuartps: Print warning in clock notifier
  tty: xuartps: Refactor read-modify-writes
  tty: xuartps: Don't write IRQ disable register to enable interrupts
  tty: xuartps: Rebrand driver as Cadence UART

 drivers/tty/serial/Kconfig |9 +-
 drivers/tty/serial/xilinx_uartps.c | 1129 
+++--
 include/uapi/linux/serial_core.h   |2 +-
 3 files changed, 546 insertions(+), 594 deletions(-)


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature

[f2fs-dev][PATCH 2/2 v2] f2fs: introduce f2fs_seek_block to support SEEK_{DATA, HOLE} in llseek

[Chao Yu]

In This patch we introduce f2fs_seek_block to support SEEK_{DATA,HOLE} of
lseek(2).

change log from v1:
 o fix bug when lseek from middle of page and fix wrong calculation of
PGOFS_OF_NEXT_DNODE macro.

Signed-off-by: Chao Yu 
---
 fs/f2fs/f2fs.h |6 
 fs/f2fs/file.c |   92 +++-
 2 files changed, 97 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 97da71d..2397301 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1074,6 +1074,12 @@ static inline void f2fs_stop_checkpoint(struct 
f2fs_sb_info *sbi)
((is_inode_flag_set(F2FS_I(i), FI_ACL_MODE)) ? \
 (F2FS_I(i)->i_acl_mode) : ((i)->i_mode))
 
+/* get offset of first page in next direct node */
+#define PGOFS_OF_NEXT_DNODE(pgofs, fi) \
+   ((pgofs < ADDRS_PER_INODE(fi)) ? ADDRS_PER_INODE(fi) :  \
+   (pgofs - ADDRS_PER_INODE(fi) + ADDRS_PER_BLOCK) /   \
+   ADDRS_PER_BLOCK * ADDRS_PER_BLOCK + ADDRS_PER_INODE(fi))
+
 /*
  * file.c
  */
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 60e7d54..655d7a8 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -194,6 +194,96 @@ out:
return ret;
 }
 
+static loff_t f2fs_seek_block(struct file *file, loff_t offset, int whence)
+{
+   struct inode *inode = file->f_mapping->host;
+   loff_t maxbytes = inode->i_sb->s_maxbytes;
+   struct dnode_of_data dn;
+   pgoff_t pgofs, end_offset;
+   loff_t data_ofs = offset, isize;
+   int err = 0;
+
+   mutex_lock(&inode->i_mutex);
+
+   isize = i_size_read(inode);
+   if (offset >= isize)
+   goto fail;
+
+   /* handle inline data case */
+   if (f2fs_has_inline_data(inode)) {
+   if (whence == SEEK_HOLE)
+   data_ofs = isize;
+   goto found;
+   }
+
+   pgofs = (pgoff_t)(offset >> PAGE_CACHE_SHIFT);
+
+   for (; data_ofs < isize; data_ofs = pgofs << PAGE_CACHE_SHIFT) {
+   set_new_dnode(&dn, inode, NULL, NULL, 0);
+   err = get_dnode_of_data(&dn, pgofs, LOOKUP_NODE_RA);
+   if (err && err != -ENOENT) {
+   goto fail;
+   } else if (err == -ENOENT) {
+   /* direct node is not exist */
+   if (whence == SEEK_DATA) {
+   pgofs = PGOFS_OF_NEXT_DNODE(pgofs,
+   F2FS_I(inode));
+   continue;
+   } else {
+   goto found;
+   }
+   }
+
+   end_offset = IS_INODE(dn.node_page) ?
+   ADDRS_PER_INODE(F2FS_I(inode)) : ADDRS_PER_BLOCK;
+
+   /* find data/hole in dnode block */
+   for (; dn.ofs_in_node < end_offset;
+   dn.ofs_in_node++, pgofs++,
+   data_ofs = pgofs << PAGE_CACHE_SHIFT) {
+   block_t blkaddr;
+   blkaddr = datablock_addr(dn.node_page, dn.ofs_in_node);
+
+   if ((whence == SEEK_DATA && blkaddr != NULL_ADDR) ||
+   (whence == SEEK_HOLE && blkaddr == NULL_ADDR)) {
+   f2fs_put_dnode(&dn);
+   goto found;
+   }
+   }
+   f2fs_put_dnode(&dn);
+   }
+
+   if (whence == SEEK_DATA)
+   goto fail;
+   else
+   data_ofs = isize;
+found:
+   mutex_unlock(&inode->i_mutex);
+   return vfs_setpos(file, data_ofs, maxbytes);
+fail:
+   mutex_unlock(&inode->i_mutex);
+   return -ENXIO;
+}
+
+static loff_t f2fs_llseek(struct file *file, loff_t offset, int whence)
+{
+   struct inode *inode = file->f_mapping->host;
+   loff_t maxbytes = inode->i_sb->s_maxbytes;
+
+   switch (whence) {
+   case SEEK_SET:
+   case SEEK_CUR:
+   case SEEK_END:
+   return generic_file_llseek_size(file, offset, whence,
+   maxbytes, i_size_read(inode));
+   case SEEK_DATA:
+   case SEEK_HOLE:
+   return f2fs_seek_block(file, offset, whence);
+   }
+
+   return -EINVAL;
+}
+
 static int f2fs_file_mmap(struct file *file, struct vm_area_struct *vma)
 {
file_accessed(file);
@@ -678,7 +768,7 @@ long f2fs_compat_ioctl(struct file *file, unsigned int cmd, 
unsigned long arg)
 #endif
 
 const struct file_operations f2fs_file_operations = {
-   .llseek = generic_file_llseek,
+   .llseek = f2fs_llseek,
.read   = do_sync_read,
.write  = do_sync_write,
.aio_read   = generic_file_aio_read,
-- 
1.7.9.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo inf

Re: [PATCHSET 0/9] perf tools: Fixup for the --percentage change

[Ingo Molnar]

* Namhyung Kim  wrote:

> Hi Ingo,
> 
> On Tue, 22 Apr 2014 11:55:57 +0200, Ingo Molnar wrote:
> > I gave it some quick testing and after fixing a trivial merge conflict 
> > in tools/lib/lockdep/Makefile all seems to be working fine.
> 
> Thanks for testing!
> 
> >
> > But while looking at it I remembered one of my old UI complains about 
> > perf top and report, the hard to read nature of:
> >
> >Event count (approx.): 226958779
> >
> > the values displayed are typically way too large to be easily human 
> > readable. More importantly, they are also nonsensical! That we have a 
> > sampling interval and can sum up all the intervals sampled has very 
> > little meaning to the overwhelming majority of humans looking at the 
> > data.
> >
> > And printing that just spams the visual field and confuses people.
> >
> > People care about the quality and speed of sampling itself, not 
> > directly the interval of sampling (which will often be variable with 
> > auto-freq sampling).
> 
> You meant 'period' by 'interval', right?

Yeah.

> There's --show-total-period option (should be equivalent to -F period
> later) in perf report, so there might be people want to see the numbers
> IMHO.
> 
> >
> > So instead of:
> >
> >   Samples: 42K of event 'cycles', Event count (approx.): 226958779
> >
> > How about only printing this in 'perf top' and 'perf report':
> >
> >   Captured 42.1K 'cycles' event samples
> >
> > Note the extra decimal (which helps monitor smaller changes as well), 
> > and note the different wording.
> >
> > Thoughts?
> 
> Well, I'm okay to add the extra decimal, but it seems that it only makes
> sense when the unit is 'K'..
> 
> And I think it might be worth adding filtered sample count as well if
> filtering is enabled something like:
> 
>   Captured 13.2K/42.1K 'cycles' event samples

Yeah. Maybe make it:

Filtered 13.2K out of 42.1K 'cycles' event samples

or so.

Thanks,

Ingo
--
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 0/3] tools lib traceevent: Options for plugins

[Namhyung Kim]

Hi Steven,

On Tue, 22 Apr 2014 15:48:24 -0400, Steven Rostedt wrote:
> trace-cmd has a way to set options for plugins, via the command
> line parameter. For example, you can add or remove the parent
> from being printed in function tracing by adding:
>
>   -O parent=1
>   -O parent=0
>
> This is passed later to the plugin in. But the plugin itself requires
> registering to the application what options it supplies.
>
> This is a three patch series. The first is to set a flag in pevent
> that would prevent plugins from being loaded. This can be supplied
> by the command line as well to produce the old "raw" events.
>
> The second patch adds the infrastructure to let plugins have options.
>
> The third patch adds the options "parent" and "indent" to the
> function plugin. The indent option lets the user print functions
> with or without indenting by their parents.
>
> All that needs to be done now is to add the options to the perf
> command line. Namhyung? ;-)

Well, I'll think about it, maybe next week (or later ;-p)?

Thanks,
Namhyung
--
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/

[git pull] Input updates for 3.15-rc2

[Dmitry Torokhov]

Hi Linus,

Please pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
or
master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus

to receive updates for the input subsystem.

The main change is that we now publish "firmware ID" for the serio
devices to help userspace figure out the kind of touchpads it is dealing
with: i8042 will export PS/2 port's PNP IDs as firmware IDs.

You will also get more quirks for Synaptics touchpads in various Lenovo
laptops, a change to elantech driver to recognize even more models, and
fixups to wacom and couple other drivers.

Changelog:
-

Adam Thomson (1):
  Input: da9055_onkey - remove use of regmap_irq_get_virq()

Alexander Stein (1):
  Input: ads7846 - fix device usage within attribute show

Hans de Goede (5):
  Input: serio - add firmware_id sysfs attribute
  Input: i8042 - add firmware_id support
  Input: Add INPUT_PROP_TOPBUTTONPAD device property
  Input: synaptics - report INPUT_PROP_TOPBUTTONPAD property
  Input: synaptics - add min/max quirk for ThinkPad T431s, L440, L540, S1 
Yoga and X1

Jason Gerecke (4):
  Input: wacom - use full 32-bit HID Usage value in switch statement
  Input: wacom - override 'pressure_max' with value from HID_USAGE_PRESSURE
  Input: wacom - references to 'wacom->data' should use 'unsigned char*'
  Input: wacom - handle 1024 pressure levels in wacom_tpc_pen

Jordan Rife (1):
  Input: elantech - add support for newer elantech touchpads

Lejun Zhu (1):
  Input: soc_button_array - fix a crash during rmmod

Ping Cheng (1):
  Input: wacom - missed the last bit of expresskey for DTU-1031


Diffstat:


 drivers/input/misc/da9055_onkey.c |   1 -
 drivers/input/misc/soc_button_array.c |   1 +
 drivers/input/mouse/elantech.c|   1 +
 drivers/input/mouse/synaptics.c   |  97 +-
 drivers/input/serio/i8042-x86ia64io.h |  15 +++
 drivers/input/serio/i8042.c   |   6 +
 drivers/input/serio/serio.c   |  14 ++
 drivers/input/tablet/wacom_sys.c  | 246 --
 drivers/input/tablet/wacom_wac.c  |  29 ++--
 drivers/input/touchscreen/ads7846.c   |   2 +-
 include/linux/serio.h |   1 +
 include/uapi/linux/input.h|   1 +
 12 files changed, 263 insertions(+), 151 deletions(-)

-- 
Dmitry



pgpQvphoXZii1.pgp
Description: PGP signature

Re: mapping instructions to dynamic languages like java, python, ruby

[Namhyung Kim]

Hi Stephane,

On Tue, 22 Apr 2014 21:05:11 +0200, Stephane Eranian wrote:
> Hi Don,
>
> I have been working on the JIT code support for a while now.
> I have something working well for more than Java now. It reuses
> some of the same principles as the OProfile support but extend
> them to support more advanced JIT features such as address
> recycling and code movements.
>
> I intend to contribute that code for perf once it is finalized.
> Note that it uses a module developed by Sonny Rao to
> export the perf timestamp time source via a posix-clock.
> This clock discussion has been going on for a while and
> never reached a conclusion. So I decided to go with the
> simple posix-clock module for the time being.

I'm looking forward to seeing your patches soon!

Thanks,
Namhyung
--
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] dmaengine: edma: No need save/restore interrupt flags during spin_lock in IRQ

[Vinod Koul]

On Thu, Apr 17, 2014 at 12:58:33AM -0500, Joel Fernandes wrote:
> The vchan lock in edma_callback is acquired in hard interrupt context. As
> interrupts are already disabled, there's no point in save/restoring interrupt
> mask bit or cpsr flags.
> 
> Get rid of flags local variable and use spin_lock instead of 
> spin_lock_irqsave.

Applied, thanks

-- 
~Vinod

> 
> Signed-off-by: Joel Fernandes 
> ---
>  drivers/dma/edma.c |9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index 91849aa..25a75e2 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -638,7 +638,6 @@ static void edma_callback(unsigned ch_num, u16 ch_status, 
> void *data)
>   struct edma_chan *echan = data;
>   struct device *dev = echan->vchan.chan.device->dev;
>   struct edma_desc *edesc;
> - unsigned long flags;
>   struct edmacc_param p;
>  
>   edesc = echan->edesc;
> @@ -649,7 +648,7 @@ static void edma_callback(unsigned ch_num, u16 ch_status, 
> void *data)
>  
>   switch (ch_status) {
>   case EDMA_DMA_COMPLETE:
> - spin_lock_irqsave(&echan->vchan.lock, flags);
> + spin_lock(&echan->vchan.lock);
>  
>   if (edesc) {
>   if (edesc->cyclic) {
> @@ -665,11 +664,11 @@ static void edma_callback(unsigned ch_num, u16 
> ch_status, void *data)
>   }
>   }
>  
> - spin_unlock_irqrestore(&echan->vchan.lock, flags);
> + spin_unlock(&echan->vchan.lock);
>  
>   break;
>   case EDMA_DMA_CC_ERROR:
> - spin_lock_irqsave(&echan->vchan.lock, flags);
> + spin_lock(&echan->vchan.lock);
>  
>   edma_read_slot(EDMA_CHAN_SLOT(echan->slot[0]), &p);
>  
> @@ -700,7 +699,7 @@ static void edma_callback(unsigned ch_num, u16 ch_status, 
> void *data)
>   edma_trigger_channel(echan->ch_num);
>   }
>  
> - spin_unlock_irqrestore(&echan->vchan.lock, flags);
> + spin_unlock(&echan->vchan.lock);
>  
>   break;
>   default:
> -- 
> 1.7.9.5
> 

-- 
--
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 0/6] input: cyapa: integrated with gen5 trackpad supported in one driver.

[Dmitry Torokhov]

Hi Dudley,

On Tue, Apr 22, 2014 at 08:39:43AM +, Dudley Du wrote:
> Hi Dmitry,
> 
> Could you help review the patches of input: cyapa for re-architecture
> and supporting new trackpad devices, I'm really looking forward your
> responses.

It is on my TODO list, sorry it takes too long...

Thanks.

-- 
Dmitry
--
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 4/9] perf tools: Introduce hists__inc_dump_events()

[Namhyung Kim]

On Tue, 22 Apr 2014 18:53:55 +0200, Jiri Olsa wrote:
> On Tue, Apr 22, 2014 at 05:49:46PM +0900, Namhyung Kim wrote:
>
> SNIP
>
>> index f955ae5a41c5..883340d7d43e 100644
>> --- a/tools/perf/util/hist.c
>> +++ b/tools/perf/util/hist.c
>> @@ -333,6 +333,19 @@ void hists__inc_nr_events(struct hists *hists, u32 type)
>>  __events_stats__add(&hists->stats, type, 1);
>>  }
>>  
>> +void hists__inc_dump_events(struct hists *hists)
>> +{
>> +if (!dump_trace)
>> +return;
>> +
>> +/*
>> + * If dump_trace is enabled, perf will exit before accounting
>> + * sample events during hists__output_resort().  Thus it needs to
>> + * be done separately.
>> + */
>> +__events_stats__add(&hists->stats, PERF_RECORD_SAMPLE, 1);
>> +}
>
> hum, we already clear all the stats before resorting for output so why done
> we call hists__inc_nr_entries from add_hist_entry? (at out label)

In short, because it could be seen by perf top's display thread before
the entry actually moves in the output tree.

Let me explain what this series does again.

There're three main fields in the hists->stats to affect the output:
number of samples, number of hist entries and total periods.

Also there're three stages to process samples: at first, samples are
converted to a hist entry and added to the input tree, and then they are
moved to the collapsed tree if needed, and finally they're moved to the
output tree to be shown to user.

The (part of) stats are accounted when samples are added to the input
tree and then reset before moving to the output tree, and re-counted
during insertion to the output tree.

I can see some reason to do it this way but it's basically not necessary
and could make a problem in multi-threaded programs like perf top.

The perf report does all these passes sequentially in a single thread so
it seems no problem.  But perf top uses two threads - one for gathering
samples (in the input tree) and another for (collapsing and) moving them
to the output tree.  Thus accounting stat in parallel can result in an
inaccurate stats and the output.

So I'd like to get rid of the accounting on the input stage as you can
see it just gets dropped before doing output resort.  I originally make
the all three stats are accounted when doing output resort but changed
mind to account number of samples in the input stage and others in the
output stage.  Because it'd make more sense accounting number of events
(sample event) in the input stage (as all other events are also
accounted in the input stage) and it'd make less changes in code.

So yes, it has a same problem of inaccurate number of samples, but its
impact should be smaller than other stats - seeing increasing sample
count (could be slightly inaccurate) without new entries in the browser.

Thoughts?

Thanks,
Namhyung
--
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] soc_button_array: fix a crash during rmmod

[Dmitry Torokhov]

On Tue, Apr 22, 2014 at 02:38:39PM +0800, Zhu, Lejun wrote:
> When the system has zero or one button available, trying to rmmod
> soc_button_array will cause crash. Fix this by properly handling -ENODEV
> in probe().
> 
> Signed-off-by: Lejun Zhu 

Applied, thank you.

> ---
>  drivers/input/misc/soc_button_array.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/input/misc/soc_button_array.c
> b/drivers/input/misc/soc_button_array.c
> index 08ead2a..20c80f5 100644
> --- a/drivers/input/misc/soc_button_array.c
> +++ b/drivers/input/misc/soc_button_array.c
> @@ -169,6 +169,7 @@ static int soc_button_pnp_probe(struct pnp_dev *pdev,
>   soc_button_remove(pdev);
>   return error;
>   }
> + continue;
>   }
> 
>   priv->children[i] = pd;
> -- 
> 1.8.3.2
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

-- 
Dmitry
--
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 V2] ARM: EXYNOS: cpu hotplug: use v7_exit_coherency_flush macro for cache disabling

[Leela Krishna Amudala]

A common macro v7_exit_coherency_flush available which does the below tasks in
the seqeunce.
-clearing C bit
-clearing L1 cache
-exit SMP
-instruction and data synchronization

So removing the local functions which does the same thing and use the macro 
instead.

Signed-off-by: Leela Krishna Amudala 
Acked-by: Nicolas Pitre 
---
Changes since V1:
- removed unwanted primary_part variable in exynos_cpu_die()
- given more description in commit message
  suggested by Daniel Lezcano 

 arch/arm/mach-exynos/hotplug.c |   63 +---
 1 file changed, 1 insertion(+), 62 deletions(-)

diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..9ca692d 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -24,56 +24,6 @@
 #include "common.h"
 #include "regs-pmu.h"
 
-static inline void cpu_enter_lowpower_a9(void)
-{
-   unsigned int v;
-
-   asm volatile(
-   "   mcr p15, 0, %1, c7, c5, 0\n"
-   "   mcr p15, 0, %1, c7, c10, 4\n"
-   /*
-* Turn off coherency
-*/
-   "   mrc p15, 0, %0, c1, c0, 1\n"
-   "   bic %0, %0, %3\n"
-   "   mcr p15, 0, %0, c1, c0, 1\n"
-   "   mrc p15, 0, %0, c1, c0, 0\n"
-   "   bic %0, %0, %2\n"
-   "   mcr p15, 0, %0, c1, c0, 0\n"
- : "=&r" (v)
- : "r" (0), "Ir" (CR_C), "Ir" (0x40)
- : "cc");
-}
-
-static inline void cpu_enter_lowpower_a15(void)
-{
-   unsigned int v;
-
-   asm volatile(
-   "   mrc p15, 0, %0, c1, c0, 0\n"
-   "   bic %0, %0, %1\n"
-   "   mcr p15, 0, %0, c1, c0, 0\n"
- : "=&r" (v)
- : "Ir" (CR_C)
- : "cc");
-
-   flush_cache_louis();
-
-   asm volatile(
-   /*
-   * Turn off coherency
-   */
-   "   mrc p15, 0, %0, c1, c0, 1\n"
-   "   bic %0, %0, %1\n"
-   "   mcr p15, 0, %0, c1, c0, 1\n"
-   : "=&r" (v)
-   : "Ir" (0x40)
-   : "cc");
-
-   isb();
-   dsb();
-}
-
 static inline void cpu_leave_lowpower(void)
 {
unsigned int v;
@@ -132,19 +82,8 @@ static inline void platform_do_lowpower(unsigned int cpu, 
int *spurious)
 void __ref exynos_cpu_die(unsigned int cpu)
 {
int spurious = 0;
-   int primary_part = 0;
 
-   /*
-* we're ready for shutdown now, so do it.
-* Exynos4 is A9 based while Exynos5 is A15; check the CPU part
-* number by reading the Main ID register and then perform the
-* appropriate sequence for entering low power.
-*/
-   asm("mrc p15, 0, %0, c0, c0, 0" : "=r"(primary_part) : : "cc");
-   if ((primary_part & 0xfff0) == 0xc0f0)
-   cpu_enter_lowpower_a15();
-   else
-   cpu_enter_lowpower_a9();
+   v7_exit_coherency_flush(louis);
 
platform_do_lowpower(cpu, &spurious);
 
-- 
1.7.9.5

--
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] extcon: palmas: explicitly set edev name as node name

[Kishon Vijay Abraham I]

Hi Chanwoo,

On Thursday 10 April 2014 09:19 AM, Chanwoo Choi wrote:
> Hi Kishon,
> 
> On 03/28/2014 03:51 PM, Kishon Vijay Abraham I wrote:
>> commit ca488 (extcon: of: Remove unnecessary function call by using the
>> name of device_node) started using node name instead of device name
>> to get the extcon device. This breaks dwc3-omap since it's not able to
>> get the extcon device anymore. Fixed it by setting edev name of
>> palmas to be the same as its node name.
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> Reported-by: Felipe Balbi 
>> ---
> 
> Applied this patch
> but, you could check this patch on extcon-next branch
> after few days. becuase I have firewall issue of kerner.org.

I see the commit being merged in extcon-next branch. Will you be sending it in
this -rc cycle?

Thanks
Kishon
--
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: [Bugfix] sched: fix possible invalid memory access caused by CPU hot-addition

[Peter Zijlstra]

On Wed, Apr 23, 2014 at 07:32:13AM +0200, Peter Zijlstra wrote:
> On Wed, Apr 23, 2014 at 10:45:13AM +0800, Jiang Liu wrote:
> > Hi Peter,
> > It's not for memoryless node, but to solve a race window
> > in CPU hot-addition. The related CPU hot-addition flow is:
> > 1) Handle CPU hot-addition event
> > 1.a) gather platform specific information
> > 1.b) associate hot-added CPU with a node
> > 1.c) create CPU device
> > 2) User online hot-added CPUs through sysfs:
> > 2.a)cpu_up()
> > 2.b)->try_online_node()
> > 2.c)->hotadd_new_pgdat()
> > 2.d)->node_set_online()
> > 
> > So between 1.b and 2.c, kmalloc_node(nid) may cause invalid
> > memory access without the node_online(nid) check.
> 
> Any why was all this not in the Changelog?

Also, do explain what kind of hardware you needed to trigger this. This
code has been like this for a good while.
--
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: [Resend Patch 9/9] I2C/ACPI: Add CONFIG_I2C_ACPI config

[Lan Tianyu]

On 2014年04月22日 19:45, Mika Westerberg wrote:
> On Tue, Apr 22, 2014 at 02:24:15PM +0800, Lan Tianyu wrote:
>> This patch is to add CONFIG_I2C_ACPI. Current there is a race between
>> removing I2C ACPI operation region and ACPI AML code accessing.
>> So make i2c core built-in if CONFIG_I2C_ACPI is set.
>>
>> Signed-off-by: Lan Tianyu 
>> ---
>>  drivers/i2c/Kconfig  | 17 -
>>  drivers/i2c/Makefile |  2 +-
>>  include/linux/i2c.h  |  2 +-
>>  3 files changed, 18 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
>> index 7b7ea32..c670d49 100644
>> --- a/drivers/i2c/Kconfig
>> +++ b/drivers/i2c/Kconfig
>> @@ -2,7 +2,9 @@
>>  # I2C subsystem configuration
>>  #
>>  
>> -menuconfig I2C
>> +menu "I2C support"
>> +
>> +config I2C
>>  tristate "I2C support"
>>  select RT_MUTEXES
>>  ---help---
>> @@ -21,6 +23,17 @@ menuconfig I2C
>>This I2C support can also be built as a module.  If so, the module
>>will be called i2c-core.
>>  
>> +config I2C_ACPI
>> +bool "I2C ACPI support"
>> +select I2C
>> +depends on ACPI
>> +default y
>> +help
>> +  Say Y here if you want to enable I2C ACPI function. ACPI table
>> +  provides I2C slave devices' information to enumerate these devices.
>> +  This option also allows ACPI AML code to access I2C slave devices
>> +  via I2C ACPI operation region to fulfill ACPI method.
>> +
> 
> I'm wondering, can we provide some sort of wrapper function from ACPI core
> that is guaranteed to be built in to the kernel image and use it instead of
> adding new Kconfig options?
> 
Cc: LV

LV tried to fix the issue via wrapper solution in the ACPI code before.
https://lkml.org/lkml/2013/7/23/87

He has a plan to resolve the issue in ACPICA later.

Other choice is to increase the i2c-core module count to prevent it
being unloaded when i2c operation region handler is installed. Remove
the code When LV finish his job.

-- 
Best regards
Tianyu Lan
--
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: [Bugfix] sched: fix possible invalid memory access caused by CPU hot-addition

[Jiang Liu]

On 2014/4/23 13:32, Peter Zijlstra wrote:
> On Wed, Apr 23, 2014 at 10:45:13AM +0800, Jiang Liu wrote:
>> Hi Peter,
>>  It's not for memoryless node, but to solve a race window
>> in CPU hot-addition. The related CPU hot-addition flow is:
>> 1) Handle CPU hot-addition event
>> 1.a) gather platform specific information
>> 1.b) associate hot-added CPU with a node
>> 1.c) create CPU device
>> 2) User online hot-added CPUs through sysfs:
>> 2.a) cpu_up()
>> 2.b) ->try_online_node()
>> 2.c) ->hotadd_new_pgdat()
>> 2.d) ->node_set_online()
>>
>> So between 1.b and 2.c, kmalloc_node(nid) may cause invalid
>> memory access without the node_online(nid) check.
> 
> Any why was all this not in the Changelog?
Sorry, will add above message into changelog.
Thanks!
Gerry
--
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] ARM: EXYNOS: cpu hotplug: use v7_exit_coherency_flush macro for cache disabling

[Leela Krishna Amudala]

Hi Daniel,

Thanks for reviewing the patch.

On Tue, Apr 22, 2014 at 8:06 PM, Daniel Lezcano
 wrote:
> On 04/22/2014 04:18 PM, Leela Krishna Amudala wrote:
>>
>> Remove the duplicated code for cache disabling and use
>> "v7_exit_coherency_flush"
>> macro to do the same job.
>
>
> Hi Leela,
>
> thanks for this patch! It would be nice if you can describe why those macros
> can be replaced by the generic v7_exit_coherency_flush macro.
>

Okay, will give the description in commit message

>
>>
>> Signed-off-by: Leela Krishna Amudala 
>>
>> ---
>> cpu hotplug is tested with 3.15-rc1 on Origen(which has cortex A9) and
>> Arndale octa(which has cortex A7 and A15) boards.
>>
>>   arch/arm/mach-exynos/hotplug.c |   56
>> ++--
>>   1 file changed, 2 insertions(+), 54 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/hotplug.c
>> b/arch/arm/mach-exynos/hotplug.c
>> index 5eead53..9eb8d1b 100644
>> --- a/arch/arm/mach-exynos/hotplug.c
>> +++ b/arch/arm/mach-exynos/hotplug.c
>> @@ -24,56 +24,6 @@
>>   #include "common.h"
>>   #include "regs-pmu.h"
>>
>> -static inline void cpu_enter_lowpower_a9(void)
>> -{
>> -   unsigned int v;
>> -
>> -   asm volatile(
>> -   "   mcr p15, 0, %1, c7, c5, 0\n"
>> -   "   mcr p15, 0, %1, c7, c10, 4\n"
>> -   /*
>> -* Turn off coherency
>> -*/
>> -   "   mrc p15, 0, %0, c1, c0, 1\n"
>> -   "   bic %0, %0, %3\n"
>> -   "   mcr p15, 0, %0, c1, c0, 1\n"
>> -   "   mrc p15, 0, %0, c1, c0, 0\n"
>> -   "   bic %0, %0, %2\n"
>> -   "   mcr p15, 0, %0, c1, c0, 0\n"
>> - : "=&r" (v)
>> - : "r" (0), "Ir" (CR_C), "Ir" (0x40)
>> - : "cc");
>> -}
>> -
>> -static inline void cpu_enter_lowpower_a15(void)
>> -{
>> -   unsigned int v;
>> -
>> -   asm volatile(
>> -   "   mrc p15, 0, %0, c1, c0, 0\n"
>> -   "   bic %0, %0, %1\n"
>> -   "   mcr p15, 0, %0, c1, c0, 0\n"
>> - : "=&r" (v)
>> - : "Ir" (CR_C)
>> - : "cc");
>> -
>> -   flush_cache_louis();
>> -
>> -   asm volatile(
>> -   /*
>> -   * Turn off coherency
>> -   */
>> -   "   mrc p15, 0, %0, c1, c0, 1\n"
>> -   "   bic %0, %0, %1\n"
>> -   "   mcr p15, 0, %0, c1, c0, 1\n"
>> -   : "=&r" (v)
>> -   : "Ir" (0x40)
>> -   : "cc");
>> -
>> -   isb();
>> -   dsb();
>> -}
>> -
>>   static inline void cpu_leave_lowpower(void)
>>   {
>> unsigned int v;
>> @@ -141,10 +91,8 @@ void __ref exynos_cpu_die(unsigned int cpu)
>>  * appropriate sequence for entering low power.
>>  */
>> asm("mrc p15, 0, %0, c0, c0, 0" : "=r"(primary_part) : : "cc");
>
>
> Can't you remove this asm line above as well as the primary_part variable ?

Didn't notice it, will remove this.

>
>
>> -   if ((primary_part & 0xfff0) == 0xc0f0)
>> -   cpu_enter_lowpower_a15();
>> -   else
>> -   cpu_enter_lowpower_a9();
>> +
>> +   v7_exit_coherency_flush(louis);
>>
>> platform_do_lowpower(cpu, &spurious);
>>
>>
>
>
> --
>   Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro:   Facebook |
>  Twitter |
>  Blog
>
--
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 1/3] tools: Unify export.h

[Rusty Russell]

Borislav Petkov  writes:
> From: Borislav Petkov 
>
> So tools/ has been growing three, at a different stage of their
> development export.h headers and so we should unite into one. Add
> tools/include/ to the include path of virtio and liblockdep to pick the
> shared header now.

Acked-by: Rusty Russell 

Thanks,
Rusty.

>
> Cc: Sasha Levin 
> Cc: Peter Zijlstra 
> Cc: Paul Mackerras 
> Cc: Ingo Molnar 
> Cc: Arnaldo Carvalho de Melo 
> Cc: Rusty Russell 
> Cc: "Michael S. Tsirkin" 
> Cc: linux-kernel@vger.kernel.org
> Cc: virtio-...@lists.oasis-open.org
> Cc: virtualizat...@lists.linux-foundation.org
> Signed-off-by: Borislav Petkov 
> ---
>  tools/{virtio => include}/linux/export.h  | 5 +
>  tools/lib/lockdep/Makefile| 2 +-
>  tools/lib/lockdep/uinclude/linux/export.h | 7 ---
>  tools/perf/MANIFEST   | 1 +
>  tools/perf/Makefile.perf  | 2 +-
>  tools/perf/util/include/linux/export.h| 6 --
>  tools/virtio/Makefile | 2 +-
>  7 files changed, 9 insertions(+), 16 deletions(-)
>  rename tools/{virtio => include}/linux/export.h (70%)
>  delete mode 100644 tools/lib/lockdep/uinclude/linux/export.h
>  delete mode 100644 tools/perf/util/include/linux/export.h
>
> diff --git a/tools/virtio/linux/export.h b/tools/include/linux/export.h
> similarity index 70%
> rename from tools/virtio/linux/export.h
> rename to tools/include/linux/export.h
> index 7311d326894a..d07e586b9ba0 100644
> --- a/tools/virtio/linux/export.h
> +++ b/tools/include/linux/export.h
> @@ -1,5 +1,10 @@
> +#ifndef _TOOLS_LINUX_EXPORT_H_
> +#define _TOOLS_LINUX_EXPORT_H_
> +
>  #define EXPORT_SYMBOL(sym)
>  #define EXPORT_SYMBOL_GPL(sym)
>  #define EXPORT_SYMBOL_GPL_FUTURE(sym)
>  #define EXPORT_UNUSED_SYMBOL(sym)
>  #define EXPORT_UNUSED_SYMBOL_GPL(sym)
> +
> +#endif
> diff --git a/tools/lib/lockdep/Makefile b/tools/lib/lockdep/Makefile
> index 07b0b7542511..41d4a99ce46e 100644
> --- a/tools/lib/lockdep/Makefile
> +++ b/tools/lib/lockdep/Makefile
> @@ -112,7 +112,7 @@ export Q VERBOSE
>  
>  LIBLOCKDEP_VERSION = $(LL_VERSION).$(LL_PATCHLEVEL).$(LL_EXTRAVERSION)
>  
> -INCLUDES = -I. -I/usr/local/include -I./uinclude -I./include 
> $(CONFIG_INCLUDES)
> +INCLUDES = -I. -I/usr/local/include -I./uinclude -I./include -I../../include 
> $(CONFIG_INCLUDES)
>  
>  # Set compile option CFLAGS if not set elsewhere
>  CFLAGS ?= -g -DCONFIG_LOCKDEP -DCONFIG_STACKTRACE -DCONFIG_PROVE_LOCKING 
> -DBITS_PER_LONG=__WORDSIZE -DLIBLOCKDEP_VERSION='"$(LIBLOCKDEP_VERSION)"' 
> -rdynamic -O0 -g
> diff --git a/tools/lib/lockdep/uinclude/linux/export.h 
> b/tools/lib/lockdep/uinclude/linux/export.h
> deleted file mode 100644
> index 6bdf3492c535..
> --- a/tools/lib/lockdep/uinclude/linux/export.h
> +++ /dev/null
> @@ -1,7 +0,0 @@
> -#ifndef _LIBLOCKDEP_LINUX_EXPORT_H_
> -#define _LIBLOCKDEP_LINUX_EXPORT_H_
> -
> -#define EXPORT_SYMBOL(sym)
> -#define EXPORT_SYMBOL_GPL(sym)
> -
> -#endif
> diff --git a/tools/perf/MANIFEST b/tools/perf/MANIFEST
> index c0c87c87b60f..81783c2037fc 100644
> --- a/tools/perf/MANIFEST
> +++ b/tools/perf/MANIFEST
> @@ -7,6 +7,7 @@ tools/lib/symbol/kallsyms.h
>  tools/include/asm/bug.h
>  tools/include/linux/compiler.h
>  tools/include/linux/hash.h
> +tools/include/linux/export.h
>  include/linux/const.h
>  include/linux/perf_event.h
>  include/linux/rbtree.h
> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index e96923310d57..595fcbeb8262 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -222,7 +222,7 @@ LIB_H += util/include/linux/const.h
>  LIB_H += util/include/linux/ctype.h
>  LIB_H += util/include/linux/kernel.h
>  LIB_H += util/include/linux/list.h
> -LIB_H += util/include/linux/export.h
> +LIB_H += ../include/linux/export.h
>  LIB_H += util/include/linux/poison.h
>  LIB_H += util/include/linux/rbtree.h
>  LIB_H += util/include/linux/rbtree_augmented.h
> diff --git a/tools/perf/util/include/linux/export.h 
> b/tools/perf/util/include/linux/export.h
> deleted file mode 100644
> index b43e2dc21e04..
> --- a/tools/perf/util/include/linux/export.h
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -#ifndef PERF_LINUX_MODULE_H
> -#define PERF_LINUX_MODULE_H
> -
> -#define EXPORT_SYMBOL(name)
> -
> -#endif
> diff --git a/tools/virtio/Makefile b/tools/virtio/Makefile
> index 3187c62d9814..9325f4693821 100644
> --- a/tools/virtio/Makefile
> +++ b/tools/virtio/Makefile
> @@ -3,7 +3,7 @@ test: virtio_test vringh_test
>  virtio_test: virtio_ring.o virtio_test.o
>  vringh_test: vringh_test.o vringh.o virtio_ring.o
>  
> -CFLAGS += -g -O2 -Wall -I. -I ../../usr/include/ -Wno-pointer-sign 
> -fno-strict-overflow -fno-strict-aliasing -fno-common -MMD -U_FORTIFY_SOURCE
> +CFLAGS += -g -O2 -Wall -I. -I../include/ -I ../../usr/include/ 
> -Wno-pointer-sign -fno-strict-overflow -fno-strict-aliasing -fno-common -MMD 
> -U_FORTIFY_SOURCE
>  vpath %.c ../../drivers/virtio ../../drivers/vhost
>  mod:
>   ${MAKE} -

Re: Futex Question (64 bits?)

[Rusty Russell]

Ryan Nicholl  writes:
> I would like to know if it would be possible to use a 64 bit futex
> call? If not, I would like to request it be added. (It is acknowledged
> in the manpages that it must be added eventually anyway.)

It could be done; it's just not been done yet.

Simple matter of coding ;)

Cheers,
Rusty.
--
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 3/9] drivers/hid/hid-lg4ff.c: avoid world-writable sysfs files.

[Rusty Russell]

si...@mungewell.org writes:
>> In line with practice for module parameters, we're adding a build-time
>> check that sysfs files aren't world-writable.
>
> So this is the equivalent of 'chmod 774 ...' rather than 'chmod
> 777...'?

Yep.  Though not sure why it was 777 rather than 666...

> Yep I'm OK with that, however what it the recommended way to make sure
> that the end user is able to send changes to this /sys portal? I asked the
> same question before regarding the led class /sys interface, but never got
> any suggestions.
>
> Signed-off-by: Simon Wood 

If you need that, we'll need to make an exception.  That's one purpose
of spamming everyone with these changs...

Do you?

Cheers,
Rusty.
--
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] Fix: tracing: use 'E' instead of 'X' for unsigned module tain flag

[Rusty Russell]

Mathieu Desnoyers  writes:
> In the following commit:
>
> commit 57673c2b0baa900dddae3b9eb3d7748ebf550eb3
> Author: Rusty Russell 
> Date:   Mon Mar 31 14:39:57 2014 +1030
>
> Use 'E' instead of 'X' for unsigned module taint flag.
>
> One site has been forgotten in trace events module.h.

Hmm, these are crying out to be unified.

Applied,
Rusty.
--
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] fix printk output

[Rusty Russell]

Sergei Ianovich  writes:
> On Tue, 2013-12-10 at 15:59 +1030, Rusty Russell wrote:
>> BTW, did you actually hit this?
>
> # modprobe usb_storage
> [  600.807274] usbcore: registered new interface driver usb-storage
> # modprobe -r usb_storage
> [  604.216318] waiting module removal not supported: please upgrade[
> 604.222164] usbcore: deregistering interface driver usb-storage
> # modprobe -V
> kmod version 9
>
> I am using the latest kmod package from emdebian unstable-grip.

Sorry, was off on leave.

Hmm, Lucas intimated that kmod version 11 started passing this flag
correctly.

In fact, kmod's modprobe *never* used the O_NONBLOCK
(ie. KMOD_REMOVE_NOWAIT) flag, until it was finally enforced in

commit 7ab8804448377fb6b8854f2dd288608db01bb43b
Author: Lucas De Marchi 
Date:   Fri Sep 20 01:30:07 2013 -0500

See: tools/modprobe.c at that commit:

static int rmmod_do_remove_module(struct kmod_module *mod)
{
const char *modname = kmod_module_get_name(mod);
struct kmod_list *deps, *itr;
int flags = 0, err;
...
if (force)
flags |= KMOD_REMOVE_FORCE;

err = kmod_module_remove_module(mod, flags);

Perhaps we need to just get rid of the kernel message, since we're
getting far too many false reports :(

Cheers,
Rusty.


--
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] sched / idle: Make cpuidle_idle_call() void

[Peter Zijlstra]

On Wed, Apr 23, 2014 at 01:36:42AM +0200, Rafael J. Wysocki wrote:
> On Tuesday, April 22, 2014 01:49:30 PM Peter Zijlstra wrote:
> > On Mon, Apr 21, 2014 at 01:26:58AM +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki 
> > > 
> > > The only value ever returned by cpuidle_idle_call() is 0 and its
> > > only caller ignores that value anyway, so make it void.
> > > 
> > > Signed-off-by: Rafael J. Wysocki 
> > 
> > Thanks!
> 
> OK, thanks, so should it go through my tree or through tip?

I'll take it through tip where there's more patches that touch this
code.
--
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: debug_dma_assert_idle - snd_hda_intel - cpu touching an active dma mapped cacheline

[poma]

On 23.04.2014 02:53, poma wrote:
> 
> This one comes and goes...
> 
> [ cut here ]
> WARNING: CPU: 2 PID: 521 at lib/dma-debug.c:593
> debug_dma_assert_idle+0x159/0x1d0()
> snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped
> cacheline [cln=0x03019000]
> [ cut here ]
> WARNING: CPU: 3 PID: 927 at lib/dma-debug.c:593
> debug_dma_assert_idle+0x159/0x1d0()
> snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped
> cacheline [cln=0x03019000]
> 
> CPU: 3 PID: 927 Comm: firewalld Not tainted 3.15.0-0.rc2.git1.1.fc21.i686 #1
> 
> Call Trace:
> 
>  [] dump_stack+0x48/0x60
> 
>  [] warn_slowpath_common+0x82/0xa0
> 
>  [] ? debug_dma_assert_idle+0x159/0x1d0
> 
>  [] ? debug_dma_assert_idle+0x159/0x1d0
> 
>  [] warn_slowpath_fmt+0x3e/0x60
> 
>  [] debug_dma_assert_idle+0x159/0x1d0
> 
>  [] ? anon_vma_prepare+0x29/0x140
> 
>  [] do_wp_page+0xce/0x890
> 
>  [] ? ext4_releasepage+0x95/0x130
> 
>  [] handle_mm_fault+0x662/0xb70
> 
>  [] ? ext4_releasepage+0x95/0x130
> 
>  [] __do_page_fault+0x1a7/0x5d0
> 
>  [] ? trace_hardirqs_on_caller+0x13c/0x1e0
> 
>  [] ? __audit_syscall_entry+0x8c/0xe0
> 
>  [] ? trace_hardirqs_on+0xb/0x10
> 
>  [] ? trace_hardirqs_on_caller+0x13c/0x1e0
> 
>  [] ? trace_hardirqs_on_caller+0x13c/0x1e0
> 
>  [] ? __do_page_fault+0x5d0/0x5d0
> 
>  [] do_page_fault+0x1a/0x20
> 
>  [] error_code+0x6c/0x74
> ---[ end trace 0464944e27da06b8 ]---
> Mapped at:
> 
> [] debug_dma_alloc_coherent+0x22/0x70
> 
> [] snd_dma_alloc_pages+0x170/0x260 [snd_pcm]
> 
> [] snd_dma_alloc_pages_fallback+0x62/0x90 [snd_pcm]
> 
> [] snd_malloc_sgbuf_pages+0xf0/0x211 [snd_pcm]
> 
> [] snd_dma_alloc_pages+0x203/0x260 [snd_pcm]
> CPU: 2 PID: 521 Comm: firewalld Tainted: GW
> 3.15.0-0.rc2.git1.1.fc21.i686 #1
> Call Trace:
>  [] dump_stack+0x48/0x60
>  [] warn_slowpath_common+0x82/0xa0
>  [] ? debug_dma_assert_idle+0x159/0x1d0
>  [] ? debug_dma_assert_idle+0x159/0x1d0
>  [] warn_slowpath_fmt+0x3e/0x60
>  [] debug_dma_assert_idle+0x159/0x1d0
>  [] ? anon_vma_prepare+0x29/0x140
>  [] do_wp_page+0xce/0x890
>  [] ? ext4_releasepage+0x95/0x130
>  [] handle_mm_fault+0x662/0xb70
>  [] ? ext4_releasepage+0x95/0x130
>  [] __do_page_fault+0x1a7/0x5d0
>  [] ? __audit_syscall_entry+0x8c/0xe0
>  [] ? trace_hardirqs_on+0xb/0x10
>  [] ? trace_hardirqs_on_caller+0x13c/0x1e0
>  [] ? __do_page_fault+0x5d0/0x5d0
>  [] do_page_fault+0x1a/0x20
>  [] error_code+0x6c/0x74
> ---[ end trace 0464944e27da06b9 ]---
> Mapped at:
>  [] debug_dma_alloc_coherent+0x22/0x70
>  [] snd_dma_alloc_pages+0x170/0x260 [snd_pcm]
>  [] snd_dma_alloc_pages_fallback+0x62/0x90 [snd_pcm]
>  [] snd_malloc_sgbuf_pages+0xf0/0x211 [snd_pcm]
>  [] snd_dma_alloc_pages+0x203/0x260 [snd_pcm]
> 
> 
> https://bugzilla.redhat.com/attachment.cgi?id=888686
> 
> dma debug: account for cachelines and read-only mappings in overlap tracking
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/lib/dma-debug.c?id=3b7a6418c7494b8bf0bf0537ddee1dedbca10f51
> 
> Are these two in some relation?

Yep.

3.15.0-0.rc2.git1.1.fc21.x86_64  PASSED
3.15.0-0.rc2.git1.1.fc21.i686FAILED
3.15.0-0.rc2.git1.2.fc21.i686PASSED <-

3.15.0-0.rc2.git1.2.fc21.i686 is
3.15.0-0.rc2.git1.1.fc21.i686 with reverted linux-next git commit 3b7a641
"dma debug: account for cachelines and read-only mappings in overlap
tracking"
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/lib/dma-debug.c?id=3b7a641


Information for build kernel-3.15.0-0.rc2.git1.1.fc21
http://koji.fedoraproject.org/koji/buildinfo?buildID=512446


poma

--
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: Microblaze image hanging in qemu with 3.15-rc

[Michal Simek]

Hi Guenter,


On 04/22/2014 07:23 PM, Guenter Roeck wrote:
> Hi all,
> 
> when trying to run a microblaze image with 3.15-rc1 or 3.15-rc2 in qemu,
> I get the following hangup. This used to work with earlier kernels
> with the same configuration.
> 
> Is this a known problem, or is something wrong with my configuration 
> or with my qemu command line ?

Is this BE/LE version? Which qemu do you use?
There is endian autodetection in timer and intc driver
which can caused this problem.

Thanks,
Michal


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature

Re: [Bugfix] sched: fix possible invalid memory access caused by CPU hot-addition

[Peter Zijlstra]

On Wed, Apr 23, 2014 at 10:45:13AM +0800, Jiang Liu wrote:
> Hi Peter,
>   It's not for memoryless node, but to solve a race window
> in CPU hot-addition. The related CPU hot-addition flow is:
> 1) Handle CPU hot-addition event
> 1.a) gather platform specific information
> 1.b) associate hot-added CPU with a node
> 1.c) create CPU device
> 2) User online hot-added CPUs through sysfs:
> 2.a)  cpu_up()
> 2.b)  ->try_online_node()
> 2.c)  ->hotadd_new_pgdat()
> 2.d)  ->node_set_online()
> 
> So between 1.b and 2.c, kmalloc_node(nid) may cause invalid
> memory access without the node_online(nid) check.

Any why was all this not in the Changelog?
--
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 5/4] ipc,shm: minor cleanups

[Michael Kerrisk (man-pages)]

On 04/23/2014 07:25 AM, Davidlohr Bueso wrote:
> On Wed, 2014-04-23 at 07:07 +0200, Michael Kerrisk (man-pages) wrote:
>> On 04/23/2014 04:53 AM, Davidlohr Bueso wrote:
>>> -  Breakup long function names/args.
>>> -  Cleaup variable declaration.
>>> -  s/current->mm/mm
>>>
>>> Signed-off-by: Davidlohr Bueso 
>>> ---
>>>  ipc/shm.c | 40 +---
>>>  1 file changed, 17 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/ipc/shm.c b/ipc/shm.c
>>> index f000696..584d02e 100644
>>> --- a/ipc/shm.c
>>> +++ b/ipc/shm.c
>>> @@ -480,15 +480,13 @@ static const struct vm_operations_struct shm_vm_ops = 
>>> {
>>>  static int newseg(struct ipc_namespace *ns, struct ipc_params *params)
>>>  {
>>> key_t key = params->key;
>>> -   int shmflg = params->flg;
>>> +   int id, error, shmflg = params->flg;
>>
>> It's largely a matter of taste (and I may be in a minority), and I know
>> there's certainly precedent in the kernel code, but I don't much like the 
>> style of mixing variable declarations that have initializers, with other
>> unrelated declarations (e.g., variables without initializers). What is 
>> the gain? One less line of text? That's (IMO) more than offset by the 
>> small loss of readability.
> 
> Yes, it's taste. And yes, your in the minority, at least in many core
> kernel components and ipc.

I figured so. Just giving the minority a small voice ;-).


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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 2/3] f2fs: pass flags field to setxattr functions

[Jaegeuk Kim]

This patch passes the "flags" field to the low level setxattr functions
to use XATTR_REPLACE in the following patches.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/acl.c   |  2 +-
 fs/f2fs/xattr.c | 13 +++--
 fs/f2fs/xattr.h |  4 ++--
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/fs/f2fs/acl.c b/fs/f2fs/acl.c
index e93e4ec..dbe2141 100644
--- a/fs/f2fs/acl.c
+++ b/fs/f2fs/acl.c
@@ -240,7 +240,7 @@ static int __f2fs_set_acl(struct inode *inode, int type,
}
}
 
-   error = f2fs_setxattr(inode, name_index, "", value, size, ipage);
+   error = f2fs_setxattr(inode, name_index, "", value, size, ipage, 0);
 
kfree(value);
if (!error)
diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c
index 1de057d..bbe9c2b 100644
--- a/fs/f2fs/xattr.c
+++ b/fs/f2fs/xattr.c
@@ -108,7 +108,8 @@ static int f2fs_xattr_generic_set(struct dentry *dentry, 
const char *name,
if (strcmp(name, "") == 0)
return -EINVAL;
 
-   return f2fs_setxattr(dentry->d_inode, type, name, value, size, NULL);
+   return f2fs_setxattr(dentry->d_inode, type, name,
+   value, size, NULL, flags);
 }
 
 static size_t f2fs_xattr_advise_list(struct dentry *dentry, char *list,
@@ -157,7 +158,7 @@ static int f2fs_xattr_advise_set(struct dentry *dentry, 
const char *name,
 #ifdef CONFIG_F2FS_FS_SECURITY
 static int __f2fs_setxattr(struct inode *inode, int index,
const char *name, const void *value, size_t size,
-   struct page *ipage);
+   struct page *ipage, int);
 
 static int f2fs_initxattrs(struct inode *inode, const struct xattr 
*xattr_array,
void *page)
@@ -168,7 +169,7 @@ static int f2fs_initxattrs(struct inode *inode, const 
struct xattr *xattr_array,
for (xattr = xattr_array; xattr->name != NULL; xattr++) {
err = __f2fs_setxattr(inode, F2FS_XATTR_INDEX_SECURITY,
xattr->name, xattr->value,
-   xattr->value_len, (struct page *)page);
+   xattr->value_len, (struct page *)page, 0);
if (err < 0)
break;
}
@@ -479,7 +480,7 @@ cleanup:
 
 static int __f2fs_setxattr(struct inode *inode, int index,
const char *name, const void *value, size_t size,
-   struct page *ipage)
+   struct page *ipage, int flags)
 {
struct f2fs_inode_info *fi = F2FS_I(inode);
struct f2fs_xattr_entry *here, *last;
@@ -586,7 +587,7 @@ exit:
 
 int f2fs_setxattr(struct inode *inode, int index, const char *name,
const void *value, size_t size,
-   struct page *ipage)
+   struct page *ipage, int flags)
 {
struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
int err;
@@ -596,7 +597,7 @@ int f2fs_setxattr(struct inode *inode, int index, const 
char *name,
f2fs_lock_op(sbi);
/* protect xattr_ver */
down_write(&F2FS_I(inode)->i_sem);
-   err = __f2fs_setxattr(inode, index, name, value, size, ipage);
+   err = __f2fs_setxattr(inode, index, name, value, size, ipage, flags);
up_write(&F2FS_I(inode)->i_sem);
f2fs_unlock_op(sbi);
 
diff --git a/fs/f2fs/xattr.h b/fs/f2fs/xattr.h
index 79bc2bb..34ab7db 100644
--- a/fs/f2fs/xattr.h
+++ b/fs/f2fs/xattr.h
@@ -114,14 +114,14 @@ extern const struct xattr_handler 
f2fs_xattr_security_handler;
 extern const struct xattr_handler *f2fs_xattr_handlers[];
 
 extern int f2fs_setxattr(struct inode *, int, const char *,
-   const void *, size_t, struct page *);
+   const void *, size_t, struct page *, int);
 extern int f2fs_getxattr(struct inode *, int, const char *, void *, size_t);
 extern ssize_t f2fs_listxattr(struct dentry *, char *, size_t);
 #else
 
 #define f2fs_xattr_handlersNULL
 static inline int f2fs_setxattr(struct inode *inode, int index,
-   const char *name, const void *value, size_t size)
+   const char *name, const void *value, size_t size, int flags)
 {
return -EOPNOTSUPP;
 }
-- 
1.8.4.474.g128a96c

--
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 5/4] ipc,shm: minor cleanups

[Davidlohr Bueso]

On Wed, 2014-04-23 at 07:07 +0200, Michael Kerrisk (man-pages) wrote:
> On 04/23/2014 04:53 AM, Davidlohr Bueso wrote:
> > -  Breakup long function names/args.
> > -  Cleaup variable declaration.
> > -  s/current->mm/mm
> > 
> > Signed-off-by: Davidlohr Bueso 
> > ---
> >  ipc/shm.c | 40 +---
> >  1 file changed, 17 insertions(+), 23 deletions(-)
> > 
> > diff --git a/ipc/shm.c b/ipc/shm.c
> > index f000696..584d02e 100644
> > --- a/ipc/shm.c
> > +++ b/ipc/shm.c
> > @@ -480,15 +480,13 @@ static const struct vm_operations_struct shm_vm_ops = 
> > {
> >  static int newseg(struct ipc_namespace *ns, struct ipc_params *params)
> >  {
> > key_t key = params->key;
> > -   int shmflg = params->flg;
> > +   int id, error, shmflg = params->flg;
> 
> It's largely a matter of taste (and I may be in a minority), and I know
> there's certainly precedent in the kernel code, but I don't much like the 
> style of mixing variable declarations that have initializers, with other
> unrelated declarations (e.g., variables without initializers). What is 
> the gain? One less line of text? That's (IMO) more than offset by the 
> small loss of readability.

Yes, it's taste. And yes, your in the minority, at least in many core
kernel components and ipc.

Thanks,
Davidlohr

--
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/3] f2fs: return errors right after checking them

[Jaegeuk Kim]

This patch adds two error conditions early in the setxattr operations.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/xattr.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c
index bbe9c2b..6073f9f 100644
--- a/fs/f2fs/xattr.c
+++ b/fs/f2fs/xattr.c
@@ -509,8 +509,16 @@ static int __f2fs_setxattr(struct inode *inode, int index,
here = __find_xattr(base_addr, index, len, name);
 
found = IS_XATTR_LAST_ENTRY(here) ? 0 : 1;
-   last = here;
 
+   if ((flags & XATTR_REPLACE) && !found) {
+   error = -ENODATA;
+   goto exit;
+   } else if ((flags & XATTR_CREATE) && found) {
+   error = -EEXIST;
+   goto exit;
+   }
+
+   last = here;
while (!IS_XATTR_LAST_ENTRY(last))
last = XATTR_NEXT_ENTRY(last);
 
-- 
1.8.4.474.g128a96c

--
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 1/3] f2fs: clean up long variable names

[Jaegeuk Kim]

This patch includes simple clean-ups to reduce unnecessary long variable names.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/xattr.c | 86 +
 fs/f2fs/xattr.h |  6 ++--
 2 files changed, 47 insertions(+), 45 deletions(-)

diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c
index 503c245..1de057d 100644
--- a/fs/f2fs/xattr.c
+++ b/fs/f2fs/xattr.c
@@ -26,7 +26,7 @@
 #include "xattr.h"
 
 static size_t f2fs_xattr_generic_list(struct dentry *dentry, char *list,
-   size_t list_size, const char *name, size_t name_len, int type)
+   size_t list_size, const char *name, size_t len, int type)
 {
struct f2fs_sb_info *sbi = F2FS_SB(dentry->d_sb);
int total_len, prefix_len = 0;
@@ -53,11 +53,11 @@ static size_t f2fs_xattr_generic_list(struct dentry 
*dentry, char *list,
return -EINVAL;
}
 
-   total_len = prefix_len + name_len + 1;
+   total_len = prefix_len + len + 1;
if (list && total_len <= list_size) {
memcpy(list, prefix, prefix_len);
-   memcpy(list + prefix_len, name, name_len);
-   list[prefix_len + name_len] = '\0';
+   memcpy(list + prefix_len, name, len);
+   list[prefix_len + len] = '\0';
}
return total_len;
 }
@@ -112,7 +112,7 @@ static int f2fs_xattr_generic_set(struct dentry *dentry, 
const char *name,
 }
 
 static size_t f2fs_xattr_advise_list(struct dentry *dentry, char *list,
-   size_t list_size, const char *name, size_t name_len, int type)
+   size_t list_size, const char *name, size_t len, int type)
 {
const char *xname = F2FS_SYSTEM_ADVISE_PREFIX;
size_t size;
@@ -155,9 +155,10 @@ static int f2fs_xattr_advise_set(struct dentry *dentry, 
const char *name,
 }
 
 #ifdef CONFIG_F2FS_FS_SECURITY
-static int __f2fs_setxattr(struct inode *inode, int name_index,
-   const char *name, const void *value, size_t value_len,
+static int __f2fs_setxattr(struct inode *inode, int index,
+   const char *name, const void *value, size_t size,
struct page *ipage);
+
 static int f2fs_initxattrs(struct inode *inode, const struct xattr 
*xattr_array,
void *page)
 {
@@ -241,26 +242,26 @@ const struct xattr_handler *f2fs_xattr_handlers[] = {
NULL,
 };
 
-static inline const struct xattr_handler *f2fs_xattr_handler(int name_index)
+static inline const struct xattr_handler *f2fs_xattr_handler(int index)
 {
const struct xattr_handler *handler = NULL;
 
-   if (name_index > 0 && name_index < ARRAY_SIZE(f2fs_xattr_handler_map))
-   handler = f2fs_xattr_handler_map[name_index];
+   if (index > 0 && index < ARRAY_SIZE(f2fs_xattr_handler_map))
+   handler = f2fs_xattr_handler_map[index];
return handler;
 }
 
-static struct f2fs_xattr_entry *__find_xattr(void *base_addr, int name_index,
-   size_t name_len, const char *name)
+static struct f2fs_xattr_entry *__find_xattr(void *base_addr, int index,
+   size_t len, const char *name)
 {
struct f2fs_xattr_entry *entry;
 
list_for_each_xattr(entry, base_addr) {
-   if (entry->e_name_index != name_index)
+   if (entry->e_name_index != index)
continue;
-   if (entry->e_name_len != name_len)
+   if (entry->e_name_len != len)
continue;
-   if (!memcmp(entry->e_name, name, name_len))
+   if (!memcmp(entry->e_name, name, len))
break;
}
return entry;
@@ -396,42 +397,43 @@ static inline int write_all_xattrs(struct inode *inode, 
__u32 hsize,
return 0;
 }
 
-int f2fs_getxattr(struct inode *inode, int name_index, const char *name,
+int f2fs_getxattr(struct inode *inode, int index, const char *name,
void *buffer, size_t buffer_size)
 {
struct f2fs_xattr_entry *entry;
void *base_addr;
int error = 0;
-   size_t value_len, name_len;
+   size_t size, len;
 
if (name == NULL)
return -EINVAL;
-   name_len = strlen(name);
-   if (name_len > F2FS_NAME_LEN)
+
+   len = strlen(name);
+   if (len > F2FS_NAME_LEN)
return -ERANGE;
 
base_addr = read_all_xattrs(inode, NULL);
if (!base_addr)
return -ENOMEM;
 
-   entry = __find_xattr(base_addr, name_index, name_len, name);
+   entry = __find_xattr(base_addr, index, len, name);
if (IS_XATTR_LAST_ENTRY(entry)) {
error = -ENODATA;
goto cleanup;
}
 
-   value_len = le16_to_cpu(entry->e_value_size);
+   size = le16_to_cpu(entry->e_value_size);
 
-   if (buffer && value_len > buffer_size) {
+   if (buffer && size > buffer_size) {
  

Re: [PATCH] vfs: rw_copy_check_uvector() - free iov on error

[Eric Biggers]

On Wed, Apr 23, 2014 at 12:06:39AM -0500, Eric Biggers wrote:
> The proposed patch doesn't work because in compat_rw_copy_check_uvector(), 
> 'iov'
> is incremented in the loop before it is freed or returned.  This probably 
> should
> be changed to indexing with 'seg', like in the non-compat version...

Also, there is still a memory leak in vmsplice() as it does not free the iov
buffer if 0 is returned from rw_copy_check_uvector() (possible if all segments
are of zero length).
--
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] autofs - fix lockref lookup

[Ian Kent]

autofs needs to be able to see private data dentry flags for
its dentrys that are being created but not yet hashed and for
its dentys that have been rmdir()ed but not yet freed. It
needs to do this so it can block processes in these states
until a status has been returned to indicate the given
operation is complete.

It does this by keeping two lists, active and expring, of
dentrys in this state and uses ->d_release() to keep them
stable while it checks the reference count to determine
if they should be used.

But with the recent lockref changes dentrys being freed
sometimes don't transition to a reference count of 0 before
being freed so autofs can occassionally use a dentry that
is invalid which can lead to a panic.

Signed-off-by: Ian Kent 
---
 fs/autofs4/root.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
index 2caf36a..cc87c1a 100644
--- a/fs/autofs4/root.c
+++ b/fs/autofs4/root.c
@@ -179,7 +179,7 @@ static struct dentry *autofs4_lookup_active(struct dentry 
*dentry)
spin_lock(&active->d_lock);
 
/* Already gone? */
-   if (!d_count(active))
+   if ((int) d_count(active) <= 0)
goto next;
 
qstr = &active->d_name;
@@ -230,7 +230,7 @@ static struct dentry *autofs4_lookup_expiring(struct dentry 
*dentry)
 
spin_lock(&expiring->d_lock);
 
-   /* Bad luck, we've already been dentry_iput */
+   /* We've already been dentry_iput or unlinked */
if (!expiring->d_inode)
goto next;
 

--
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] pinctrl-baytrail: fix for irq descriptor conflict on ASUS T100TA

[Adam Williamson]

On Mon, 2014-04-21 at 10:30 -0400, Benjamin Tissoires wrote:
> On Mon, Apr 21, 2014 at 9:28 AM, Jin, Yao  wrote:
> >
> >
> > On 2014/4/21 14:27, Jin, Yao wrote:
> >>
> >>
> >> On 2014/4/20 23:28, Adam Williamson wrote:
> >>> On Sun, 2014-04-20 at 20:08 +0800, Jin, Yao wrote:
>  For the issue that touch screen doesn't work, could you check power
>  state of LPSS devices? For example:
> 
>  cd /sys/bus/acpi/devices
>  grep -H . */power_state
> 
>  If they are D3cold, it should be the reason why touch screen doesn't
>  work. That's another issue, unrelated to this gpio patch.
> >>>
> >>> The touch screen worked fine with kernel 3.14, and Benjamin looked at
> >>> debug output from the attempt to load the touchscreen driver when
> >>> diagnosing the problem, he's not just guessing. I am building a kernel
> >>> without your patch to confirm that fixes it.
> >>>
> >>
> >> I tried the clean kernel 3.14 with the boot option "nomodeset text" on
> >> Dell Venue 11 Pro (If without "nomodeset",my ubuntu is being "black
> >> screen", but that should be another i915 issue).
> >>
> >> After system starup, I executed the "startx" to launch the xwindow. In
> >> xwindow, the touchscreen work.
> >>
> >> I tried the kernel 3.14 again with my gpio patch applied, the result was
> >> the same, the touchscreen work.
> >>
> >> I also check the DSDT table of Dell Venue 11 Pro by searching the
> >> keyword "Interrupt", I can't find any clue for the irq conflict.
> >>
> >> I'm sorry I don't have a Dell Venue 8 for testing, but I guess it's
> >> similar to Dell Venue 11 Pro.
> 
> Sorry, my bad. Actually, this patch does not break the touchscreen,
> but the other Adam applied does:
> https://github.com/AdamWill/baytrail-m/blob/master/kernel/baytrail_gpio_quirk.patch
> 
> This one was to enable wifi, but it actually breaks the touchscreen.
> I'll try to figure out which part of the patch breaks the touchscreen.
> 
> The good point is that I have a reproducer now on the Lenovo Miix 2,
> so I'll be able to spot the pb easily.
> 
> Sorry for having been rude, and thanks for the tests.

Well, I can't actually concur. See my results in
https://bugzilla.kernel.org/show_bug.cgi?id=68291#c44 .

1. A kernel with neither patch applied (and no hid-rmi driver) results
in a working touchscreen.
2. A kernel with only v3 of Doug's patch from
https://bugzilla.kernel.org/show_bug.cgi?id=67921 results in a working
touchscreen.
3. A kernel with both v3 of Doug's patch and this IRQ descriptor
conflict "fix" results in a broken touchscreen.

Seems to me there really is some kind of problem with this patch...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

--
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] proc: fix documentation for /proc/stat, line "intr"

[Michael Kerrisk (man-pages)]

On Wed, Apr 23, 2014 at 12:35 AM, Randy Dunlap  wrote:
> On 04/22/14 11:19, Michael Kerrisk (man-pages) wrote:
>> On 04/22/2014 05:29 PM, Jan Moskyto Matejka wrote:
>>> The sum at the beginning of line "intr" includes also unnumbered interrupts.
>>> It implies that the sum at the beginning isn't the sum of the remainder of 
>>> the
>>> line, not even an estimation.
>>>
>>> Fixed the documentation to mention that.
>>
>> I'm not really doubting what you claim, Jan, but it would be really
>> helpful if you provided some data to support the proposed change
>> (Kernel source references, or notes about testing you've done, or
>> pointers to mailing list threads, authoritative note that you are
>> the maintainer of some relevant kernel subsystem...). Do you have
>> something like that? (It's also useful for the change log.)
>
> I wouldn't mind more of a changelog, but the additional text is
> certainly correct.
>
> Thanks.  I'll apply the patch, but more changelog comments are welcome.

And I see now that this text could also reasonably fit into the
proc(5) man page. So I've added, with a Reviewed-by: tag for Randy.
Thanks for the text, Jan.

Cheers,

Michael


>>> Signed-off-by: Jan Moskyto Matejka 
>>> ---
>>>  Documentation/filesystems/proc.txt | 5 +++--
>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/filesystems/proc.txt 
>>> b/Documentation/filesystems/proc.txt
>>> index f00bee1..4e6f9d0 100644
>>> --- a/Documentation/filesystems/proc.txt
>>> +++ b/Documentation/filesystems/proc.txt
>>> @@ -1245,8 +1245,9 @@ second).  The meanings of the columns are as follows, 
>>> from left to right:
>>>
>>>  The "intr" line gives counts of interrupts  serviced since boot time, for 
>>> each
>>>  of the  possible system interrupts.   The first  column  is the  total of  
>>> all
>>> -interrupts serviced; each  subsequent column is the  total for that 
>>> particular
>>> -interrupt.
>>> +interrupts serviced  including  unnumbered  architecture specific  
>>> interrupts;
>>> +each  subsequent column is the  total for that particular numbered 
>>> interrupt.
>>> +Unnumbered interrupts are not shown, only summed into the total.
>>>
>>>  The "ctxt" line gives the total number of context switches across all CPUs.
>>>
>>>
>>
>>
>
>
> --
> ~Randy



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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 3/9] perf tools: Account entry stats when it's added to the output tree

[Namhyung Kim]

On Tue, 22 Apr 2014 19:10:49 +0200, Jiri Olsa wrote:
> On Tue, Apr 22, 2014 at 05:49:45PM +0900, Namhyung Kim wrote:
>
> SNIP
>
>>  
>> diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
>> index 1c77714f668d..f955ae5a41c5 100644
>> --- a/tools/perf/util/hist.c
>> +++ b/tools/perf/util/hist.c
>> @@ -344,9 +344,11 @@ void hists__inc_nr_entries(struct hists *hists, struct 
>> hist_entry *h)
>>  hists__calc_col_len(hists, h);
>>  hists->nr_non_filtered_entries++;
>>  hists->stats.total_non_filtered_period += h->stat.period;
>> +hists->stats.nr_non_filtered_samples += h->stat.nr_events;
>>  }
>>  hists->nr_entries++;
>>  hists->stats.total_period += h->stat.period;
>> +hists__add_nr_events(hists, PERF_RECORD_SAMPLE, h->stat.nr_events);
>
> while at it.. could hists__remove_entry_filter call hists__inc_nr_entries too?

Nope, I (and Arnaldo) want to the default stats invariant - they are not
changed by any filter.  As you can see hists__remove_entry_filter() only
updates non-filtered stats.

>
> not sure about those 2 extra lines in hists__remove_entry_filter:
>
> if (h->ms.unfolded)
> hists->nr_non_filtered_entries += h->nr_rows;
> h->row_offset = 0;
>
> maybe they should be added into hists__inc_nr_entries?

Hmm.. this seems like a mix of generic code and UI-specific code.  The
->nr_rows, ->row_offset and ->ms.unfolded are only used by TUI browser
code AFAIK and it takes the folding state into account.

I think we should just make it folded to make things simple - and
finally get rid of the UI-specific bits in the generic code.

Thanks,
Namhyung
--
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: [PATCHv2 2/3] regmap: Add the DT binding documentation for endianness

[li.xi...@freescale.com]

> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Tuesday, April 15, 2014 5:10 AM
> To: Xiubo Li-B47053
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCHv2 2/3] regmap: Add the DT binding documentation for
> endianness
> 
> On Thu, Apr 03, 2014 at 07:04:00AM +, li.xi...@freescale.com wrote:
> 
> > > Generally just not
> > > mentioning regmap is better for a binding definition, the binding should
> > > be usable by all OSs and not just Linux.
> 
> > How about move the endianness OF parsing to the driver/of/ ?
> > Is this will be better ?
> 
> Where the code is is sensible enough, it's an issue about how the
> binding documentation was written rather than about the code.

Sorry for late.

Well, I will try to enhance this.

Thanks,

BRs
Xiubo
--
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 1/4] ipc/shm.c: check for ulong overflows in shmat

[Michael Kerrisk (man-pages)]

On 04/21/2014 04:26 PM, Manfred Spraul wrote:
> find_vma_intersection does not work as intended if addr+size overflows.
> The patch adds a manual check before the call to find_vma_intersection.
> 
> Signed-off-by: Manfred Spraul 
> ---
>  ipc/shm.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/ipc/shm.c b/ipc/shm.c
> index 7645961..382e2fb 100644
> --- a/ipc/shm.c
> +++ b/ipc/shm.c
> @@ -1160,6 +1160,9 @@ long do_shmat(int shmid, char __user *shmaddr, int 
> shmflg, ulong *raddr,
>   down_write(¤t->mm->mmap_sem);
>   if (addr && !(shmflg & SHM_REMAP)) {
>   err = -EINVAL;
> + if (addr + size < addr)
> + goto invalid;
> +
>   if (find_vma_intersection(current->mm, addr, addr + size))
>   goto invalid;
>   /*
> 

Acked-by: Michael Kerrisk 

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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 5/4] ipc,shm: minor cleanups

[Michael Kerrisk (man-pages)]

On 04/23/2014 04:53 AM, Davidlohr Bueso wrote:
> -  Breakup long function names/args.
> -  Cleaup variable declaration.
> -  s/current->mm/mm
> 
> Signed-off-by: Davidlohr Bueso 
> ---
>  ipc/shm.c | 40 +---
>  1 file changed, 17 insertions(+), 23 deletions(-)
> 
> diff --git a/ipc/shm.c b/ipc/shm.c
> index f000696..584d02e 100644
> --- a/ipc/shm.c
> +++ b/ipc/shm.c
> @@ -480,15 +480,13 @@ static const struct vm_operations_struct shm_vm_ops = {
>  static int newseg(struct ipc_namespace *ns, struct ipc_params *params)
>  {
>   key_t key = params->key;
> - int shmflg = params->flg;
> + int id, error, shmflg = params->flg;

It's largely a matter of taste (and I may be in a minority), and I know
there's certainly precedent in the kernel code, but I don't much like the 
style of mixing variable declarations that have initializers, with other
unrelated declarations (e.g., variables without initializers). What is 
the gain? One less line of text? That's (IMO) more than offset by the 
small loss of readability.

Cheers,

Michael

>   size_t size = params->u.size;
> - int error;
> - struct shmid_kernel *shp;
>   size_t numpages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> - struct file *file;
>   char name[13];
> - int id;
>   vm_flags_t acctflag = 0;
> + struct shmid_kernel *shp;
> + struct file *file;
>  
>   if (size < SHMMIN || size > ns->shm_ctlmax)
>   return -EINVAL;
> @@ -681,7 +679,8 @@ copy_shmid_from_user(struct shmid64_ds *out, void __user 
> *buf, int version)
>   }
>  }
>  
> -static inline unsigned long copy_shminfo_to_user(void __user *buf, struct 
> shminfo64 *in, int version)
> +static inline unsigned long copy_shminfo_to_user(void __user *buf,
> +  struct shminfo64 *in, int 
> version)
>  {
>   switch (version) {
>   case IPC_64:
> @@ -711,8 +710,8 @@ static inline unsigned long copy_shminfo_to_user(void 
> __user *buf, struct shminf
>   * Calculate and add used RSS and swap pages of a shm.
>   * Called with shm_ids.rwsem held as a reader
>   */
> -static void shm_add_rss_swap(struct shmid_kernel *shp,
> - unsigned long *rss_add, unsigned long *swp_add)
> +static void shm_add_rss_swap(struct shmid_kernel *shp, unsigned long 
> *rss_add,
> +  unsigned long *swp_add)
>  {
>   struct inode *inode;
>  
> @@ -739,7 +738,7 @@ static void shm_add_rss_swap(struct shmid_kernel *shp,
>   * Called with shm_ids.rwsem held as a reader
>   */
>  static void shm_get_stat(struct ipc_namespace *ns, unsigned long *rss,
> - unsigned long *swp)
> +  unsigned long *swp)
>  {
>   int next_id;
>   int total, in_use;
> @@ -1047,21 +1046,16 @@ out_unlock1:
>  long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr,
> unsigned long shmlba)
>  {
> - struct shmid_kernel *shp;
> - unsigned long addr;
> - unsigned long size;
> + unsigned long addr, size, flags, prot, populate = 0;
>   struct file *file;
> - interr;
> - unsigned long flags;
> - unsigned long prot;
> - int acc_mode;
> + int acc_mode, err = -EINVAL;
>   struct ipc_namespace *ns;
>   struct shm_file_data *sfd;
> + struct shmid_kernel *shp;
>   struct path path;
>   fmode_t f_mode;
> - unsigned long populate = 0;
> + struct mm_struct *mm = current->mm;
>  
> - err = -EINVAL;
>   if (shmid < 0)
>   goto out;
>   else if ((addr = (ulong)shmaddr)) {
> @@ -1161,20 +1155,20 @@ long do_shmat(int shmid, char __user *shmaddr, int 
> shmflg, ulong *raddr,
>   if (err)
>   goto out_fput;
>  
> - down_write(¤t->mm->mmap_sem);
> + down_write(&mm->mmap_sem);
>   if (addr && !(shmflg & SHM_REMAP)) {
>   err = -EINVAL;
>   if (addr + size < addr)
>   goto invalid;
>  
> - if (find_vma_intersection(current->mm, addr, addr + size))
> + if (find_vma_intersection(mm, addr, addr + size))
>   goto invalid;
>   /*
>* If shm segment goes below stack, make sure there is some
>* space left for the stack to grow (at least 4 pages).
>*/
> - if (addr < current->mm->start_stack &&
> - addr > current->mm->start_stack - size - PAGE_SIZE * 5)
> + if (addr < mm->start_stack &&
> + addr > mm->start_stack - size - PAGE_SIZE * 5)
>   goto invalid;
>   }
>  
> @@ -1184,7 +1178,7 @@ long do_shmat(int shmid, char __user *shmaddr, int 
> shmflg, ulong *raddr,
>   if (IS_ERR_VALUE(addr))
>   err = (long)addr;
>  invalid:
> - up_write(¤t->mm->mmap_sem);
> + up_write(&mm->mmap_sem);
>   if (populate)
>   mm_populate(addr, populate);
>  
> 


-- 
Michael Kerrisk
Linux ma

Re: [PATCH 3/4] ipc/shm.c: check for integer overflow during shmget.

[Michael Kerrisk (man-pages)]

On 04/21/2014 04:26 PM, Manfred Spraul wrote:
> SHMMAX is the upper limit for the size of a shared memory segment,
> counted in bytes. The actual allocation is that size, rounded up to
> the next full page.
> Add a check that prevents the creation of segments where the
> rounded up size causes an integer overflow.
> 
> Signed-off-by: Manfred Spraul 
> ---
>  ipc/shm.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/ipc/shm.c b/ipc/shm.c
> index 2dfa3d6..f000696 100644
> --- a/ipc/shm.c
> +++ b/ipc/shm.c
> @@ -493,6 +493,9 @@ static int newseg(struct ipc_namespace *ns, struct 
> ipc_params *params)
>   if (size < SHMMIN || size > ns->shm_ctlmax)
>   return -EINVAL;
>  
> + if (numpages << PAGE_SHIFT < size)
> + return -ENOSPC;
> +
>   if (ns->shm_tot + numpages < ns->shm_tot ||
>   ns->shm_tot + numpages > ns->shm_ctlall)
>   return -ENOSPC;
> 

Acked-by: Michael Kerrisk 

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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] vfs: rw_copy_check_uvector() - free iov on error

[Eric Biggers]

The proposed patch doesn't work because in compat_rw_copy_check_uvector(), 'iov'
is incremented in the loop before it is freed or returned.  This probably should
be changed to indexing with 'seg', like in the non-compat version...
--
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 4/4] ipc/shm.c: Increase the defaults for SHMALL, SHMMAX.

[Michael Kerrisk (man-pages)]

On 04/21/2014 04:26 PM, Manfred Spraul wrote:
> System V shared memory
> 
> a) can be abused to trigger out-of-memory conditions and the standard
>measures against out-of-memory do not work:
> 
> - it is not possible to use setrlimit to limit the size of shm segments.
> 
> - segments can exist without association with any processes, thus
>   the oom-killer is unable to free that memory.
> 
> b) is typically used for shared information - today often multiple GB.
>(e.g. database shared buffers)
> 
> The current default is a maximum segment size of 32 MB and a maximum total
> size of 8 GB. This is often too much for a) and not enough for b), which
> means that lots of users must change the defaults.
> 
> This patch increases the default limits (nearly) to the maximum, which is
> perfect for case b). The defaults are used after boot and as the initial
> value for each new namespace.
> 
> Admins/distros that need a protection against a) should reduce the limits
> and/or enable shm_rmid_forced.
> 
> Further notes:
> - The patch only changes default, overrides behave as before:
> # sysctl kernel.shmall=33554432
>   would recreate the previous limit for SHMMAX (for the current namespace).
> 
> - Disabling sysv shm allocation is possible with:
> # sysctl kernel.shmall=0
>   (not a new feature, also per-namespace)
> 
> - The limits are intentionally set to a value slightly less than ULONG_MAX,
>   to avoid triggering overflows in user space apps.
>   [not unreasonable, see http://marc.info/?l=linux-mm&m=139638334330127]
> 
> Signed-off-by: Manfred Spraul 
> Reported-by: Davidlohr Bueso 
> Cc: mtk.manpa...@gmail.com
> ---
>  include/linux/shm.h  | 3 +--
>  include/uapi/linux/shm.h | 8 +++-
>  2 files changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/shm.h b/include/linux/shm.h
> index 1e2cd2e..57d7770 100644
> --- a/include/linux/shm.h
> +++ b/include/linux/shm.h
> @@ -3,9 +3,8 @@
>  
>  #include 
>  #include 
> -
> -#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) 
> */
>  #include 
> +
>  struct shmid_kernel /* private to the kernel */
>  {
>   struct kern_ipc_permshm_perm;
> diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h
> index 78b6941..74e786d 100644
> --- a/include/uapi/linux/shm.h
> +++ b/include/uapi/linux/shm.h
> @@ -9,15 +9,13 @@
>  
>  /*
>   * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can
> - * be increased by sysctl
> + * be modified by sysctl.
>   */
>  
> -#define SHMMAX 0x200  /* max shared seg size (bytes) */
>  #define SHMMIN 1  /* min shared seg size (bytes) */
>  #define SHMMNI 4096   /* max num of segs system wide */
> -#ifndef __KERNEL__
> -#define SHMALL (SHMMAX/getpagesize()*(SHMMNI/16))
> -#endif
> +#define SHMMAX (ULONG_MAX - (1L<<24)) /* max shared seg size (bytes) 
> */
> +#define SHMALL (ULONG_MAX - (1L<<24)) /* max shm system wide (pages) 
> */
>  #define SHMSEG SHMMNI /* max shared segs per process 
> */

Acked-by: Michael Kerrisk 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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 2/4] ipc/shm.c: check for overflows of shm_tot

[Michael Kerrisk (man-pages)]

On 04/21/2014 04:26 PM, Manfred Spraul wrote:
> shm_tot counts the total number of pages used by shm segments.
> 
> If SHMALL is ULONG_MAX (or nearly ULONG_MAX), then the number
> can overflow.  Subsequent calls to shmctl(,SHM_INFO,) would return
> wrong values for shm_tot.
> 
> The patch adds a detection for overflows.
> 
> Signed-off-by: Manfred Spraul 
> ---
>  ipc/shm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/ipc/shm.c b/ipc/shm.c
> index 382e2fb..2dfa3d6 100644
> --- a/ipc/shm.c
> +++ b/ipc/shm.c
> @@ -493,7 +493,8 @@ static int newseg(struct ipc_namespace *ns, struct 
> ipc_params *params)
>   if (size < SHMMIN || size > ns->shm_ctlmax)
>   return -EINVAL;
>  
> - if (ns->shm_tot + numpages > ns->shm_ctlall)
> + if (ns->shm_tot + numpages < ns->shm_tot ||
> + ns->shm_tot + numpages > ns->shm_ctlall)
>   return -ENOSPC;
>  
>   shp = ipc_rcu_alloc(sizeof(*shp));
> 

Acked-by: Michael Kerrisk 

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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/

linux-next: Tree for Apr 23

[Stephen Rothwell]

Hi all,

This tree still fails (more than usual) the powerpc allyesconfig build.

Changes since 20140422:

New tree: drm-panel

The arm tree still produces quite a few build warnings.

The powerpc tree still had its build failure.

The vfs tree still had its build failure so I applied a fix patch.

The mmc tree lost its build failure.

The wireless-next tree gained a build failure for which I applied a patch.

The audit tree lost its build failure.

The akpm-current tree lost its build failure but gained another for which
I applied a patch.

The akpm tree lost a couple of patches that were applied elsewhere.

Non-merge commits (relative to Linus' tree): 2170
 2030 files changed, 72452 insertions(+), 44079 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 214 trees (counting Linus' and 28 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (4d0fa8a0f012 Merge tag 'gpio-v3.15-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio)
Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator)
Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1)
Merging arc-current/for-curr (a798c10faf62 Linux 3.15-rc2)
Merging arm-current/fixes (244b47838626 ARM: 8026/1: Fix emulation of multiply 
accumulate instructions)
Merging m68k-current/for-linus (50be9eba831d m68k: Update defconfigs for 
v3.14-rc1)
Merging metag-fixes/fixes (0414855fdc4a Linux 3.14-rc5)
Merging powerpc-merge/merge (cc4f265ad9a3 powerpc/powernv Adapt opal-elog and 
opal-dump to new sysfs_remove_file_self)
Merging sparc/master (a798c10faf62 Linux 3.15-rc2)
Merging net/master (7b07bd4e5187 net: sxgbe: Added phy_found error path)
Merging ipsec/master (a32452366b72 vti4: Don't count header length twice.)
CONFLICT (content): Merge conflict in net/ipv4/ip_vti.c
Merging sound-current/for-linus (8dc9abb93dde ALSA: hda/realtek - Add headset 
Mic support for Dell machine)
Merging pci-current/for-linus (f5d3352b2751 PCI: tegra: Use new OF interrupt 
mapping when possible)
Merging wireless/master (c82552c5b0cb ath9k: add a recv budget)
Merging driver-core.current/driver-core-linus (94f8cc0eea03 drivers/base/dd.c 
incorrect pr_debug() parameters)
Merging tty.current/tty-linus (12de375ec493 Revert "serial: 8250, disable "too 
much work" messages")
Merging usb.current/usb-linus (94d72f008909 uas: fix deadlocky memory 
allocations)
Merging staging.current/staging-linus (a798c10faf62 Linux 3.15-rc2)
Merging char-misc.current/char-misc-linus (03367ef5ea81 Drivers: hv: vmbus: 
Negotiate version 3.0 when running on ws2012r2 hosts)
Merging input-current/for-linus (46a2986ebbe1 Input: synaptics - add min/max 
quirk for ThinkPad T431s, L440, L540, S1 Yoga and X1)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (eb4a5346e777 hwrng: bcm2835 - fix oops when rng 
h/w is accessed during registration)
Merging ide/master (5b40dd30bbfa ide: Fix SC1200 dependencies)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (1f42e5dd5065 of: Add self test for 
of_match_node())
Merging rr-fixes/fixes (7122c3e9154b scrip

Re: [RFC PATCH v5 2/2] Use kernfs_break_active_protection() for device online store callbacks

[Li Zhong]

On Tue, 2014-04-22 at 16:44 -0400, Tejun Heo wrote:
> Hello,
> 
> On Tue, Apr 22, 2014 at 11:34:39AM +0800, Li Zhong wrote:
> > > Is this assumption true?  If so, can we add lockdep assertions in
> > > places to verify and enforce this?  If not, aren't we just feeling
> > > good when the reality is broken?
> > 
> > It seems not true ... I think there are devices that don't have the
> > online/offline concept, we just need to add it, remove it, like ethernet
> > cards. 
> > 
> > Maybe we could change the comments above, like:
> > /* We assume device_hotplug_lock must be acquired before 
> >  * removing devices, which have online/offline sysfs knob, 
> >  * and some locks are needed to serialize the online/offline
> >  * callbacks and device removing. ...
> > ? 
> > 
> > And we could add lockdep assertions in cpu and memory related code? e.g.
> > remove_memory(), unregister_cpu()
> > 
> > Currently, remove_memory() has comments for the function:
> > 
> >  * NOTE: The caller must call lock_device_hotplug() to serialize hotplug
> >  * and online/offline operations before this call, as required by
> >  * try_offline_node().
> >  */
> > 
> > maybe it could be removed with the lockdep assertion.
> 
> I'm confused about the overall locking scheme.  What's the role of
> device_hotplug_lock?  Is that solely to prevent the sysfs deadlock
> issue?  Or does it serve other synchronization purposes depending on
> the specific subsystem?  If the former, the lock no longer needs to
> exist.  The only thing necessary would be synchronization between
> device_del() deleting the sysfs file and the unbreak helper invoking
> device-specific callback.  If the latter, we probably should change
> that.  Sharing hotplug lock across multiple subsystems through driver
> core sounds like a pretty bad idea.

I think it's the latter. I think device_{on|off}line is better to be
done in some sort of lock which prevents the device from being removed,
including some preparation work that needs be done before device_del().

Thanks, Zhong

> 
> Thanks.
> 


--
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] zram: correct offset usage in zram_bio_discard

[Joonsoo Kim]

On Wed, Apr 23, 2014 at 11:52:08AM +0800, Weijie Yang wrote:
> On Wed, Apr 23, 2014 at 11:08 AM, Joonsoo Kim  wrote:
> > On Wed, Apr 23, 2014 at 10:32:30AM +0800, Weijie Yang wrote:
> >> On Wed, Apr 23, 2014 at 3:55 AM, Andrew Morton
> >>  wrote:
> >> > On Tue, 22 Apr 2014 11:14:02 +0800 Weijie Yang  
> >> > wrote:
> >> >
> >> >> we want to skip the logical block which is partially covered by
> >> >> the discard bio, so check the remaining size and subtract it if
> >> >> there is a need to goto the next logical block.
> >> >>
> >> >> This patch corrects the offset usage in zram_bio_discard.
> >> >>
> >> >
> >> > What were the end-user visible effects of the bug?
> >> >
> >> > Please always include this information when fixing something so that
> >> > others can work out which kernel(s) need patching.
> >> >
> >>
> >> Thanks for your advise, I will resend this patch and add the end-user
> >> visible effect information.
> >
> > Thanks for fixing it.
> >
> > As far as I understand, there is no end-user visible effect, because
> > request size is alway PAGE_SIZE aligned and if n < PAGE_SIZE,
> > no real operation happens. Am I missing?
> 
> The zram only limit ZRAM_LOGICAL_BLOCK_SIZE(4K) aligned,
> not PAGE_SIZE aligned.
> 
> Consider the following scenario:
> on some architecture or config, PAGE_SIZE is 64K for example
> filesystem is set up on zram disk without PAGE_SIZE aligned.
> a discard bio leads to a offset = 4K, size=72K
> normally, it should not really discard any physical block as it partially
> cover two physical blocks.
> However, with the current offset usage, it will discard the second
> physical block and free its memory, which will cause filesystem breakdown.
> 

I misunderstood what discard_granularity means. I thought that if I set
discard_granularity=PAGE_SIZE, the size of discard request is aligned to
PAGE_SIZE. But, by looking at the code, I notice that isn't true. So now, I
understand your patch compeletely. Thanks again.

Thanks.
--
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 3/9] perf tools: Account entry stats when it's added to the output tree

[Namhyung Kim]

On Tue, 22 Apr 2014 16:54:49 +0200, Jiri Olsa wrote:
> On Tue, Apr 22, 2014 at 05:49:45PM +0900, Namhyung Kim wrote:
>
> SNIP
>
>>  }
>>  
>>  static int process_sample_event(struct perf_tool *tool,
>> @@ -234,19 +230,17 @@ static int __cmd_annotate(struct perf_annotate *ann)
>>  total_nr_samples = 0;
>>  evlist__for_each(session->evlist, pos) {
>>  struct hists *hists = &pos->hists;
>> -u32 nr_samples = hists->stats.nr_events[PERF_RECORD_SAMPLE];
>>  
>> -if (nr_samples > 0) {
>
> so this condition of having some data is handled in the
> resort I guess.. hm, it will just iterate 0 times ;-)

Right.  But I decided to keep this logic as is - will explain on other thread.

>
>> -total_nr_samples += nr_samples;
>> -hists__collapse_resort(hists, NULL);
>> -hists__output_resort(hists);
>> +hists__collapse_resort(hists, NULL);
>> +hists__output_resort(hists);
>>  
>> -if (symbol_conf.event_group &&
>> -!perf_evsel__is_group_leader(pos))
>> -continue;
>> +if (symbol_conf.event_group &&
>> +!perf_evsel__is_group_leader(pos))
>> +continue;
>>  
>> -hists__find_annotations(hists, pos, ann);
>> -}
>> +hists__find_annotations(hists, pos, ann);
>> +
>> +total_nr_samples += hists->stats.nr_events[PERF_RECORD_SAMPLE];
>>  }
>>  
>>  if (total_nr_samples == 0) {
>>  
>
> SNIP
>
>> diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
>> index 1c77714f668d..f955ae5a41c5 100644
>> --- a/tools/perf/util/hist.c
>> +++ b/tools/perf/util/hist.c
>> @@ -344,9 +344,11 @@ void hists__inc_nr_entries(struct hists *hists, struct 
>> hist_entry *h)
>
> I was wondering for a while about the name of this function
> since it no longer increments only nr_entries.. but could not
> think about any good replacement ;-)
>
> We could also add hists__reset_nr_entries for the zeroing code.

How about hists__inc_stats() and hists__reset_stats()?

>
>
>>  hists__calc_col_len(hists, h);
>
> also having hists__calc_col_len called here seems strange

Agreed.  I'll move this out of the function.

Thanks,
Namhyung
--
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] proc: fix documentation for /proc/stat, line "intr"

[Michael Kerrisk (man-pages)]

On 04/23/2014 12:35 AM, Randy Dunlap wrote:
> On 04/22/14 11:19, Michael Kerrisk (man-pages) wrote:
>> On 04/22/2014 05:29 PM, Jan Moskyto Matejka wrote:
>>> The sum at the beginning of line "intr" includes also unnumbered interrupts.
>>> It implies that the sum at the beginning isn't the sum of the remainder of 
>>> the
>>> line, not even an estimation.
>>>
>>> Fixed the documentation to mention that.
>>
>> I'm not really doubting what you claim, Jan, but it would be really
>> helpful if you provided some data to support the proposed change
>> (Kernel source references, or notes about testing you've done, or 
>> pointers to mailing list threads, authoritative note that you are
>> the maintainer of some relevant kernel subsystem...). Do you have
>> something like that? (It's also useful for the change log.)
> 
> I wouldn't mind more of a changelog, but the additional text is
> certainly correct.

Sorry -- I wrote the reply in a hurry, having first mistaken the patch
as being something to apply in man-pages. I should have looked more
closely ;-).

> Thanks.  I'll apply the patch, but more changelog comments are welcome.

Amen.

Cheers,

Michael


>>> Signed-off-by: Jan Moskyto Matejka 
>>> ---
>>>  Documentation/filesystems/proc.txt | 5 +++--
>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/filesystems/proc.txt 
>>> b/Documentation/filesystems/proc.txt
>>> index f00bee1..4e6f9d0 100644
>>> --- a/Documentation/filesystems/proc.txt
>>> +++ b/Documentation/filesystems/proc.txt
>>> @@ -1245,8 +1245,9 @@ second).  The meanings of the columns are as follows, 
>>> from left to right:
>>>  
>>>  The "intr" line gives counts of interrupts  serviced since boot time, for 
>>> each
>>>  of the  possible system interrupts.   The first  column  is the  total of  
>>> all
>>> -interrupts serviced; each  subsequent column is the  total for that 
>>> particular
>>> -interrupt.
>>> +interrupts serviced  including  unnumbered  architecture specific  
>>> interrupts;
>>> +each  subsequent column is the  total for that particular numbered 
>>> interrupt.
>>> +Unnumbered interrupts are not shown, only summed into the total.
>>>  
>>>  The "ctxt" line gives the total number of context switches across all CPUs.
>>>  
>>>
>>
>>
> 
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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 2/9] perf hists: Introduce hists__add_nr_events()

[Namhyung Kim]

On Tue, 22 Apr 2014 16:52:03 +0200, Jiri Olsa wrote:
> On Tue, Apr 22, 2014 at 05:49:44PM +0900, Namhyung Kim wrote:
>> +static void hists__add_nr_events(struct hists *hists, u32 type, u32 val)
>> +{
>> +__events_stats__add(&hists->stats, type, val);
>> +}
>
> adding static function with no usage breaks build..
> we dont want that, eventhough it's fixed in the next commit

Oops, my bad.  Will fix!

Thanks,
Namhyung
--
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: [Bugfix] sched: fix possible invalid memory access caused by CPU hot-addition

[Jiang Liu]

On 2014/4/23 9:59, David Rientjes wrote:
> On Tue, 22 Apr 2014, Peter Zijlstra wrote:
> 
>> On Tue, Apr 22, 2014 at 01:01:51PM -0700, Andrew Morton wrote:
>>> On Tue, 22 Apr 2014 10:15:15 +0200 Peter Zijlstra  
>>> wrote:
>>>
 On Tue, Apr 22, 2014 at 01:27:15PM +0800, Jiang Liu wrote:
> When calling kzalloc_node(size, flags, node), we should first check
> whether node is onlined, otherwise it may cause invalid memory access
> as below.

 But this is only for memory less node crap, right? 
>>>
>>> um, why are memoryless nodes crap?
>>
>> Why wouldn't they be? Having CPUs with no local memory seems decidedly
>> suboptimal.
> 
> The quick fix for memoryless node issues is usually just do cpu_to_mem() 
> rather than cpu_to_node() in the caller.  This assumes that the arch is 
> setup correctly to handle memoryless nodes with 
> CONFIG_HAVE_MEMORYLESS_NODES (and we've had problems recently with 
> memoryless nodes not being configured correctly on powerpc).
> 
> That type of a fix would probably be better handled in the slab allocator, 
> though, since kmalloc_node(nid) shouldn't crash just because nid is 
> memoryless, we should be doing local_memory_node(node) when allocating the 
> slab pages.
> 
> However, I don't think memoryless nodes are the problem here since Jiang 
> is testing for !node_online(nid) in his patch, so it's a problem with 
> cpu_to_node() pointing to an offline node.  It makes sense for the page 
> allocator to crash in such a case, the node id is erroneous.
> 
> So either the cpu-to-node mapping is invalid or alloc_fair_sched_group() 
> is allocating memory for a cpu on an offline node.  The 
> for_each_possible_cpu() looks suspicious.  There's no guarantee that 
> local_memory_node(node) for an offline node will return anything with 
> affinity, so falling back to NUMA_NO_NODE looks appropriate in Jiang's 
> patch.
Hi David,
That's the case, alloc_fair_sched_group() is trying to allocate
memory for CPU in offline node, which then access non-exist NODE_DATA.
Thanks!
Gerry

> 
--
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 1/9] perf report: Count number of entries and samples separately

[Namhyung Kim]

Hi Jiri,

On Tue, 22 Apr 2014 16:51:03 +0200, Jiri Olsa wrote:
> On Tue, Apr 22, 2014 at 05:49:43PM +0900, Namhyung Kim wrote:
>> Those stats are counted counted in multiple places so that they can
>> confuse readers of the code.  This is a preparation of later change
>> and do not intend any functional difference.

[SNIP]
>> +rep->nr_samples++;
>> +if (he->stat.nr_events == 1) {
>> +/* count new entries only */
>> +rep->nr_entries++;
>> +}
>
> smeels like we could use function for this ^^^
>
> also it took me a while to figure out the reason for the condition,
> maybe there could be more comment about that

Okay, so I changed it like below:

static void report__inc_stats(struct report *rep, struct hist_entry *he)
{
/*
 * The @he is either of a newly created one or an existing one
 * merging current sample.  We only want to count a new one so
 * checking ->nr_events being 1.
 */
if (he->stat.nr_events == 1)
rep->nr_entries++;
}

This also eliminated the unneeded nr_samples field.

Thanks,
Namhyung
--
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: [PATCHSET 0/9] perf tools: Fixup for the --percentage change

[Namhyung Kim]

Hi Ingo,

On Tue, 22 Apr 2014 11:55:57 +0200, Ingo Molnar wrote:
> I gave it some quick testing and after fixing a trivial merge conflict 
> in tools/lib/lockdep/Makefile all seems to be working fine.

Thanks for testing!

>
> But while looking at it I remembered one of my old UI complains about 
> perf top and report, the hard to read nature of:
>
>Event count (approx.): 226958779
>
> the values displayed are typically way too large to be easily human 
> readable. More importantly, they are also nonsensical! That we have a 
> sampling interval and can sum up all the intervals sampled has very 
> little meaning to the overwhelming majority of humans looking at the 
> data.
>
> And printing that just spams the visual field and confuses people.
>
> People care about the quality and speed of sampling itself, not 
> directly the interval of sampling (which will often be variable with 
> auto-freq sampling).

You meant 'period' by 'interval', right?

There's --show-total-period option (should be equivalent to -F period
later) in perf report, so there might be people want to see the numbers
IMHO.

>
> So instead of:
>
>   Samples: 42K of event 'cycles', Event count (approx.): 226958779
>
> How about only printing this in 'perf top' and 'perf report':
>
>   Captured 42.1K 'cycles' event samples
>
> Note the extra decimal (which helps monitor smaller changes as well), 
> and note the different wording.
>
> Thoughts?

Well, I'm okay to add the extra decimal, but it seems that it only makes
sense when the unit is 'K'..

And I think it might be worth adding filtered sample count as well if
filtering is enabled something like:

  Captured 13.2K/42.1K 'cycles' event samples


Thanks,
Namhyung
--
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 01/19] tick: trivial cleanups

[Viresh Kumar]

On 23 April 2014 02:53, Frederic Weisbecker  wrote:
> On Mon, Apr 21, 2014 at 03:24:57PM +0530, Viresh Kumar wrote:
>> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
>> index 6558b7a..9e9ddba 100644
>> --- a/kernel/time/tick-sched.c
>> +++ b/kernel/time/tick-sched.c
>> @@ -108,7 +108,6 @@ static ktime_t tick_init_jiffy_update(void)
>>   return period;
>>  }
>>
>> -
>>  static void tick_sched_do_timer(ktime_t now)
>>  {
>>   int cpu = smp_processor_id();
>> @@ -248,8 +247,8 @@ void tick_nohz_full_kick_all(void)
>>   return;
>>
>>   preempt_disable();
>> - smp_call_function_many(tick_nohz_full_mask,
>> -nohz_full_kick_ipi, NULL, false);
>> + smp_call_function_many(tick_nohz_full_mask, nohz_full_kick_ipi, NULL,
>> +false);
>
> Breaking < 80 char lines is arguable although I'm not sure it still matters 
> in 2014.

I agree. In case we don't care anymore, checkpatch.pl must be fixed..

> But I don't see much the point of the above change. I usually prefer when 
> line contents
> are a bit balanced. It may be a matter of taste I guess.

When I tried doing it, I though it might come in a single line, but
then it didn't.
The way I wrap things normally is I let 'vim' do it after 80 columns. And it
tries to fit max in a single line.. So this happened.

I can drop it if you want.. :)
--
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] cpufreq: powernow-k8: Fix checkpatch warnings

[Viresh Kumar]

On 23 April 2014 02:43, Stratos Karafotis  wrote:
> @@ -342,7 +333,7 @@ static int core_voltage_pre_transition(struct 
> powernow_k8_data *data,
> return 1;
>
> if (savefid != data->currfid) {
> -   printk(KERN_ERR PFX "ph1 err, currfid changed 0x%x\n",
> +   pr_err("ph1 err, currfid changed 0x%x\n",
> data->currfid);

This will come in single line?

> @@ -529,43 +510,39 @@ static int check_pst_table(struct powernow_k8_data 
> *data, struct pst_s *pst,
>
> for (j = 0; j < data->numps; j++) {
> if (pst[j].vid > LEAST_VID) {
> -   printk(KERN_ERR FW_BUG PFX "vid %d invalid : 0x%x\n",
> -  j, pst[j].vid);
> +   pr_err(FW_BUG "vid %d invalid : 0x%x\n", j,
> +  pst[j].vid);

Same here.

>  static const char missing_pss_msg[] =
> KERN_ERR

remove this and use pr_err_once instead of printk_once()

> -   FW_BUG PFX "No compatible ACPI _PSS objects found.\n"
> -   FW_BUG PFX "First, make sure Cool'N'Quiet is enabled in the BIOS.\n"
> -   FW_BUG PFX "If that doesn't help, try upgrading your BIOS.\n";
> +   FW_BUG KBUILD_MODNAME
> +   "No compatible ACPI _PSS objects found.\n"

Don't break these, even if they cross 80 columns.

> +   FW_BUG KBUILD_MODNAME
> +   "First, make sure Cool'N'Quiet is enabled in the BIOS.\n"
> +   FW_BUG KBUILD_MODNAME
> +   "If that doesn't help, try upgrading your BIOS.\n";
>

On 23 April 2014 02:43, Stratos Karafotis  wrote:
> Fix the following checkpatch warnings:
>
> - WARNING: Prefer pr_err(... to printk(KERN_ERR ...
> - WARNING: Prefer pr_info(... to printk(KERN_INFO ...
> - WARNING: Prefer pr_warn(... to printk(KERN_WARNING ...
> - WARNING: quoted string split across lines
> - WARNING: line over 80 characters
> - WARNING: please, no spaces at the start of a line
>
> Also, define the pr_fmt macro instead of PFX for the module name.
>
> Signed-off-by: Stratos Karafotis 
> ---
>  drivers/cpufreq/powernow-k8.c | 180 
> ++
>  drivers/cpufreq/powernow-k8.h |  11 ++-
>  2 files changed, 84 insertions(+), 107 deletions(-)
>
> diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c
> index 1b6ae6b..fa0386e 100644
> --- a/drivers/cpufreq/powernow-k8.c
> +++ b/drivers/cpufreq/powernow-k8.c
> @@ -27,6 +27,8 @@
>   *  power and thermal data sheets, (e.g. 30417.pdf, 30430.pdf, 43375.pdf)
>   */
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
>  #include 
>  #include 
>  #include 
> @@ -45,7 +47,6 @@
>  #include 
>  #include 
>
> -#define PFX "powernow-k8: "
>  #define VERSION "version 2.20.00"
>  #include "powernow-k8.h"
>
> @@ -161,7 +162,7 @@ static int write_new_fid(struct powernow_k8_data *data, 
> u32 fid)
> u32 i = 0;
>
> if ((fid & INVALID_FID_MASK) || (data->currvid & INVALID_VID_MASK)) {
> -   printk(KERN_ERR PFX "internal error - overflow on fid 
> write\n");
> +   pr_err("internal error - overflow on fid write\n");
> return 1;
> }
>
> @@ -175,9 +176,7 @@ static int write_new_fid(struct powernow_k8_data *data, 
> u32 fid)
> do {
> wrmsr(MSR_FIDVID_CTL, lo, data->plllock * 
> PLL_LOCK_CONVERSION);
> if (i++ > 100) {
> -   printk(KERN_ERR PFX
> -   "Hardware error - pending bit very stuck - "
> -   "no further pstate changes possible\n");
> +   pr_err("Hardware error - pending bit very stuck - no 
> further pstate changes possible\n");
> return 1;
> }
> } while (query_current_values_with_pending_wait(data));
> @@ -185,16 +184,14 @@ static int write_new_fid(struct powernow_k8_data *data, 
> u32 fid)
> count_off_irt(data);
>
> if (savevid != data->currvid) {
> -   printk(KERN_ERR PFX
> -   "vid change on fid trans, old 0x%x, new 0x%x\n",
> -   savevid, data->currvid);
> +   pr_err("vid change on fid trans, old 0x%x, new 0x%x\n",
> +  savevid, data->currvid);
> return 1;
> }
>
> if (fid != data->currfid) {
> -   printk(KERN_ERR PFX
> -   "fid trans failed, fid 0x%x, curr 0x%x\n", fid,
> -   data->currfid);
> +   pr_err("fid trans failed, fid 0x%x, curr 0x%x\n", fid,
> +  data->currfid);
> return 1;
> }
>
> @@ -209,7 +206,7 @@ static int write_new_vid(struct powernow_k8_data *data, 
> u32 vid)
> int i = 0;
>
> if ((data->currfid & INVALID_FID_MASK) || (vid & INVALID_VID_MASK)) {
> -   printk(KERN_ERR PFX "internal error - overflow on vid 
> write\n");
> +   pr_err("interna

[PATCH] ceph: fix corruption when using page_count 0 page in rbd

[Chunwei Chen]

It has been reported that using ZFSonLinux on rbd will result in memory
corruption. The bug report can be found here:

https://github.com/zfsonlinux/spl/issues/241
http://tracker.ceph.com/issues/7790

The reason is that ZFS will send pages with page_count 0 into rbd, which in
turns send them to tcp_sendpage. However, tcp_sendpage cannot deal with
page_count 0, as it will do get_page and put_page, and erroneously free the
page.

This type of issue has been noted before, and handled in iscsi, drbd,
etc. So, rbd should also handle this. This fix address this issue by fall back
to slower sendmsg when page_count 0 detected.

Cc: Sage Weil 
Cc: Yehuda Sadeh 
Cc: sta...@vger.kernel.org
Signed-off-by: Chunwei Chen 
---
 net/ceph/messenger.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/net/ceph/messenger.c b/net/ceph/messenger.c
index 4f55f9c..9a964e7 100644
--- a/net/ceph/messenger.c
+++ b/net/ceph/messenger.c
@@ -557,7 +557,7 @@ static int ceph_tcp_sendmsg(struct socket *sock, struct 
kvec *iov,
return r;
 }
 
-static int ceph_tcp_sendpage(struct socket *sock, struct page *page,
+static int __ceph_tcp_sendpage(struct socket *sock, struct page *page,
 int offset, size_t size, bool more)
 {
int flags = MSG_DONTWAIT | MSG_NOSIGNAL | (more ? MSG_MORE : MSG_EOR);
@@ -570,6 +570,24 @@ static int ceph_tcp_sendpage(struct socket *sock, struct 
page *page,
return ret;
 }
 
+static int ceph_tcp_sendpage(struct socket *sock, struct page *page,
+int offset, size_t size, bool more)
+{
+   int ret;
+   struct kvec iov;
+
+   /* sendpage cannot properly handle pages with page_count == 0,
+* we need to fallback to sendmsg if that's the case */
+   if (page_count(page) >= 1)
+   return __ceph_tcp_sendpage(sock, page, offset, size, more);
+
+   iov.iov_base = kmap(page) + offset;
+   iov.iov_len = size;
+   ret = ceph_tcp_sendmsg(sock, &iov, 1, size, more);
+   kunmap(page);
+
+   return ret;
+}
 
 /*
  * Shutdown/close the socket for the given connection.
-- 
1.8.5.2

--
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] cpufreq: Kconfig: Fix spelling errors

[Viresh Kumar]

On 23 April 2014 01:10, Stratos Karafotis  wrote:
> Fix 4 spelling errors in help sections.
>
> Signed-off-by: Stratos Karafotis 
> ---
>  drivers/cpufreq/Kconfig.arm | 4 ++--
>  drivers/cpufreq/Kconfig.x86 | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)

Acked-by: Viresh Kumar 
--
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 2/2] usb: gadget: Add xilinx axi usb2 device support

[sundeep subbaraya]

Hi,

On Tue, Apr 22, 2014 at 8:19 PM, Felipe Balbi  wrote:
> Hi,
>
> On Tue, Apr 22, 2014 at 12:58:41PM +0530, sundeep subbaraya wrote:
>> Hi,
>>
>> On Mon, Apr 21, 2014 at 10:09 PM, Alan Stern  
>> wrote:
>> > On Mon, 21 Apr 2014, Felipe Balbi wrote:
>> >
>> >> Hi,
>> >>
>> >> On Fri, Apr 18, 2014 at 07:34:08PM +0530, sundeep subbaraya wrote:
>> >>
>> >> 
>> >>
>> >> > >> in ep_queue driver starts dma transfer from/to IP buffer to/from 
>> >> > >> req->buf.
>> >> > >> If transfer is completed then request is not added to ep request 
>> >> > >> queue
>> >> > >> and returns from ep_queue.
>> >> > >> If transfer is not completed (actual < length) then request is added
>> >> > >> to queue and returns from ep_queue.
>> >> > >
>> >> > > This is wrong. Why wouldn't you give gadget driver the chance to 
>> >> > > decide
>> >> > > if it needs to queue the request again or not ?
>> >> >
>> >> > When does gadget driver decides to queue the same request again?
>> >> > if -EBUSY is returned from ep_queue or req.status != 0 in completion
>> >> > routine?
>> >>
>> >> whenever it so decides. Different gadget drivers might have different
>> >> requirements. The code is open and sits under drivers/usb/gadget/ why
>> >> don't you have a read ?
>> >
>> > I get the impression that the two of you are arguing past each other.
>> > It appears that Sundeep is talking about transferring data from the
>> > gadget driver's buffer to an internal buffer in the UDC hardware, but
>> > Felipe is talking about transferring data from the UDC to the host.
>> >
>> > As I understand it, Sundeep said that when the gadget driver queues a
>> > data-IN request, the UDC driver copies as much of the data buffer as
>> > possible into a hardware FIFO.  If it succeeds in copying all the data
>> > into the FIFO then the request's completion routine gets called
>> > immediately, even though the data doesn't get sent from the FIFO to the
>> > host until the host asks for it.
>> >
>> > If only part of the data can be copied into the FIFO then the request
>> > is added to the ep's request queue before the usb_ep_queue() call
>> > returns.  When space becomes available in the FIFO, the data will be
>> > copied and eventually sent to the host.  When all the data has been
>> > copied to the FIFO, the request's completion routine will be called.
>
> there seems to be a slight problem with this approach: how will the IP
> know that even though you copied X bytes into the FIFO, it should wait
> for another Y bytes before shifting data to the wire ? How will it know
> that it shouldn't generate CRC yet because there's still data to be
> added ?

No. IP does/need not know that it has to wait for Y bytes.We just
write X bytes into
HW buffer and count as X in buffer count register. IP generates CRC
for bytes based
on Count register and sends data to Host. Let us consider this
scenario of bulk IN transfer:
req.length = 5120 and   wMaxPacketSize = 512, ep_queue is called once
and is returned with
status 0. In ep_queue this code snippet,
   if (xudc_write_fifo(ep, req) == 1)
req = NULL;
   if(req != NULL)
 list_add_tail(&req->queue, &ep->queue);

xudc_write_fifo does the following if HW buffers not busy:
 copies 512 bytes to HW buffer
 set count and ready registers so that IP can start data transfer to host
 changes req.actual to 512 and returns 0(if req.length >
wMaxPacketSize) and 1(if req.length < wMaxPacketSize).
Since return is zero this request is added to queue. When data
transfer to host is completed IP generates
an interrupt. In the interrupt handler we again call write_fifo if
request list is not empty.
   if (list_empty(&ep->queue))
req = NULL;
else
req = list_entry(ep->queue.next, struct xusb_req, queue);
if (!req)
return;

if (ep->is_in)
xudc_write_fifo(ep, req);
else
xudc_read_fifo(ep, req);

This happens 10 times(since length 5120) and completion is called.

> If there's no space in the FIFO yet, why copy data at all ?

If HW buffers are busy(IP is still transferring previous data to Host
from buffer) then xudc_write_fifo returns
0 without changing req.actual. When previous data transfer completes
then Interrupt then again write_fifo
from handler.

>> > Thus there never is any need for the gadget driver to queue the request
>> > again.

Yes

>> >An incomplete transfer means the FIFO didn't have enough room
>> > when the request was submitted; it doesn't mean that the data didn't
>> > eventually get sent to the host.
>>
>> Exactly Alan,this is what I was trying to say. Probably I was not
>> clear in explaining. I didnt see any harm this way and even this
>> implementation is same like at91_udc.c. I have been reading
>> mas_storage to understand when does gadget driver tries to enqueue a
>> request again. Since different gadget drivers might have different
>> 

linux-next: build failure after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from arch/arm/mm/flush.c:20:0:
include/linux/hugetlb.h: In function 'hugepages_supported':
include/linux/hugetlb.h:468:9: error: 'HPAGE_SHIFT' undeclared (first use in 
this function)

And a few more similarly.

Caused by commit c669debfbf05 ("hugetlb: ensure hugepage access is denied
if hugepages are not supported").

I added the following fix patch:

From 91e29eff2be1b6bc0c9ea33b1ee901dd4877e924 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell 
Date: Wed, 23 Apr 2014 14:12:56 +1000
Subject: [PATCH] hugetlb: ensure hugepage access is denied if hugepages are
 not supported -fix

Signed-off-by: Stephen Rothwell 
---
 include/linux/hugetlb.h | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 4eace5e94117..cbee9847e425 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -214,6 +214,15 @@ static inline int is_file_hugepages(struct file *file)
return 0;
 }
 
+static inline bool hugepages_supported(void)
+{
+   /*
+* Some platform decide whether they support huge pages at boot
+* time. On these, such as powerpc, HPAGE_SHIFT is set to 0 when
+* there is no such support
+*/
+   return HPAGE_SHIFT != 0;
+}
 
 #else /* !CONFIG_HUGETLBFS */
 
@@ -458,14 +467,4 @@ static inline spinlock_t *huge_pte_lock(struct hstate *h,
return ptl;
 }
 
-static inline bool hugepages_supported(void)
-{
-   /*
-* Some platform decide whether they support huge pages at boot
-* time. On these, such as powerpc, HPAGE_SHIFT is set to 0 when
-* there is no such support
-*/
-   return HPAGE_SHIFT != 0;
-}
-
 #endif /* _LINUX_HUGETLB_H */
-- 
1.9.2

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/


pgphfx1Jy3405.pgp
Description: PGP signature

[PATCH] usb: phy: tahvo: Use devm_extcon_dev_* function for resource management of extcon

[Chanwoo Choi]

This patch uses devm_extcon_dev_{allocate, register} function for automatically
resource management of extcon device instead of legacy method and simplifies
the behavior of register/unregister for extcon device.

Signed-off-by: Chanwoo Choi 
---
This patch has dependency about following patches[1-2]:
[1] https://lkml.org/lkml/2014/4/21/140
[2] https://lkml.org/lkml/2014/4/21/164

 drivers/usb/phy/phy-tahvo.c | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/phy/phy-tahvo.c b/drivers/usb/phy/phy-tahvo.c
index cc61ee4..8cde928 100644
--- a/drivers/usb/phy/phy-tahvo.c
+++ b/drivers/usb/phy/phy-tahvo.c
@@ -57,7 +57,7 @@ struct tahvo_usb {
struct clk  *ick;
int irq;
int tahvo_mode;
-   struct extcon_dev   extcon;
+   struct extcon_dev   *extcon;
 };
 
 static const char *tahvo_cable[] = {
@@ -118,7 +118,7 @@ static void check_vbus_state(struct tahvo_usb *tu)
prev_state = tu->vbus_state;
tu->vbus_state = reg & TAHVO_STAT_VBUS;
if (prev_state != tu->vbus_state) {
-   extcon_set_cable_state(&tu->extcon, "USB", tu->vbus_state);
+   extcon_set_cable_state(tu->extcon, "USB", tu->vbus_state);
sysfs_notify(&tu->pt_dev->dev.kobj, NULL, "vbus_state");
}
 }
@@ -127,7 +127,7 @@ static void tahvo_usb_become_host(struct tahvo_usb *tu)
 {
struct retu_dev *rdev = dev_get_drvdata(tu->pt_dev->dev.parent);
 
-   extcon_set_cable_state(&tu->extcon, "USB-HOST", true);
+   extcon_set_cable_state(tu->extcon, "USB-HOST", true);
 
/* Power up the transceiver in USB host mode */
retu_write(rdev, TAHVO_REG_USBR, USBR_REGOUT | USBR_NSUSPEND |
@@ -146,7 +146,7 @@ static void tahvo_usb_become_peripheral(struct tahvo_usb 
*tu)
 {
struct retu_dev *rdev = dev_get_drvdata(tu->pt_dev->dev.parent);
 
-   extcon_set_cable_state(&tu->extcon, "USB-HOST", false);
+   extcon_set_cable_state(tu->extcon, "USB-HOST", false);
 
/* Power up transceiver and set it in USB peripheral mode */
retu_write(rdev, TAHVO_REG_USBR, USBR_SLAVE_CONTROL | USBR_REGOUT |
@@ -360,11 +360,15 @@ static int tahvo_usb_probe(struct platform_device *pdev)
 */
tu->vbus_state = retu_read(rdev, TAHVO_REG_IDSR) & TAHVO_STAT_VBUS;
 
-   tu->extcon.name = DRIVER_NAME;
-   tu->extcon.supported_cable = tahvo_cable;
-   tu->extcon.dev.parent = &pdev->dev;
+   tu->extcon = devm_extcon_dev_allocate(&pdev->dev, tahvo_cable);
+   if (!tu->extcon) {
+   dev_err(&pdev->dev, "failed to allocate memory for extcon\n");
+   return -ENOMEM;
+   }
+   tu->extcon->name = DRIVER_NAME;
+   tu->extcon->dev.parent = &pdev->dev;
 
-   ret = extcon_dev_register(&tu->extcon);
+   ret = devm_extcon_dev_register(&pdev->dev, tu->extcon);
if (ret) {
dev_err(&pdev->dev, "could not register extcon device: %d\n",
ret);
@@ -372,9 +376,9 @@ static int tahvo_usb_probe(struct platform_device *pdev)
}
 
/* Set the initial cable state. */
-   extcon_set_cable_state(&tu->extcon, "USB-HOST",
+   extcon_set_cable_state(tu->extcon, "USB-HOST",
   tu->tahvo_mode == TAHVO_MODE_HOST);
-   extcon_set_cable_state(&tu->extcon, "USB", tu->vbus_state);
+   extcon_set_cable_state(tu->extcon, "USB", tu->vbus_state);
 
/* Create OTG interface */
tahvo_usb_power_off(tu);
@@ -391,7 +395,7 @@ static int tahvo_usb_probe(struct platform_device *pdev)
if (ret < 0) {
dev_err(&pdev->dev, "cannot register USB transceiver: %d\n",
ret);
-   goto err_extcon_unreg;
+   goto err_disable_clk;
}
 
dev_set_drvdata(&pdev->dev, tu);
@@ -418,8 +422,6 @@ err_free_irq:
free_irq(tu->irq, tu);
 err_remove_phy:
usb_remove_phy(&tu->phy);
-err_extcon_unreg:
-   extcon_dev_unregister(&tu->extcon);
 err_disable_clk:
if (!IS_ERR(tu->ick))
clk_disable(tu->ick);
@@ -434,7 +436,6 @@ static int tahvo_usb_remove(struct platform_device *pdev)
sysfs_remove_group(&pdev->dev.kobj, &tahvo_attr_group);
free_irq(tu->irq, tu);
usb_remove_phy(&tu->phy);
-   extcon_dev_unregister(&tu->extcon);
if (!IS_ERR(tu->ick))
clk_disable(tu->ick);
 
-- 
1.8.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: [perf] yet another 32/64-bit range check failure

[Vince Weaver]

On Tue, 22 Apr 2014, Vince Weaver wrote:

> This is allowing events to be allocated memory but not being freed somehow
> before returning EINVAL (a memory leak).
> At least it looks like this is happening in the huge traces I have trying 
> to track down the perf_fuzzer memory corruption bug.

I can't find where the memory leak happens, but it looks like this in the 
trace:

[ 3524.626452] perf_fuz-17980 1271584315us : sys_enter: NR 298 (698e40, 
706, , f, 8000, 8000)
[ 3524.642312] perf_fuz-17980 1271584324us : kmalloc: 
call_site=8113a575 ptr=88007d5b0800 bytes_req=1272 bytes_alloc=2048 
gfp_flags=GFP_KERNEL|GFP_ZERO
[ 3524.662598] perf_fuz-17980 1271584337us : sys_exit: NR 298 = -22

The call site for the kmalloc is in perf_event_alloc()

The memory is eventually freed as:

[ 3547.895534]   -0   0.Ns. 1271595088us : kfree: 
call_site=811316aa ptr=88007d5b0800


Vince
--
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] mmc: dw_mmc: Don't print data errors

[Alim Akhtar]

Hi Doug,

On Wed, Apr 23, 2014 at 5:21 AM, Doug Anderson  wrote:
> Data errors are completely expected during tuning.  Printing them out
> is confusing people looking at the kernel logs.  They see things like:
>
>  [3.613296] dwmmc_exynos 1220.dwmmc0: data error, status 0x0088
>
> ...and they think something is wrong with their hardware.
>
> Remove the printouts.  We'll leave it up to a higher level to report
> about errors.
>
> Signed-off-by: Doug Anderson 

This looks reasonable
Reviewed-by: Alim Akhtar 

> ---
>  drivers/mmc/host/dw_mmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index cced599..4c8d423 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1248,7 +1248,7 @@ static int dw_mci_data_complete(struct dw_mci *host, 
> struct mmc_data *data)
> data->error = -EIO;
> }
>
> -   dev_err(host->dev, "data error, status 0x%08x\n", status);
> +   dev_dbg(host->dev, "data error, status 0x%08x\n", status);
>
> /*
>  * After an error, there may be data lingering
> --
> 1.9.1.423.g4596e3a
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Regards,
Alim
--
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 0/6][v2] audit: implement multicast socket for journald

[Eric Paris]

On Tue, 2014-04-22 at 22:25 -0400, Steve Grubb wrote:
> On Tuesday, April 22, 2014 09:31:52 PM Richard Guy Briggs wrote:
> > This is a patch set Eric Paris and I have been working on to add a
> > restricted capability read-only netlink multicast socket to kernel audit to
> > enable userspace clients such as systemd/journald to receive audit logs, in
> > addition to the bidirectional auditd userspace client.
> 
> Do have the ability to separate of secadm_r and sysadm_r? By allowing this, 
> we 
> will leak to a sysadmin that he is being audited by the security officer. In 
> a 
> lot of cases, they are one in the same person. But for others, they are not. 
> I 
> have a feeling this will cause problems for MLS systems.

Why?  This requires CAP_AUDIT_READ.  Just don't give CAP_AUDIT_READ to
places you don't want to have read permission.  Exactly the same as you
don't give CAP_AUDIT_CONTROL to sysadm_r.  (If we are giving
CAP_AUDIT_CONTROL to sysadm_r and you think that any file protections
on /var/log/audit/audit.log are adequate we are fooling ourselves!)

> Also, shouldn't we have an audit event for every attempt to connect to this 
> socket? We really need to know where this information is getting leaked to.

We certainly can.  What would you like to see in that event?

-Eric

--
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 0/6][v2] audit: implement multicast socket for journald

[David Miller]

From: Richard Guy Briggs 
Date: Tue, 22 Apr 2014 21:49:29 -0400

> On 14/04/22, David Miller wrote:
>> From: Richard Guy Briggs 
>> Date: Tue, 22 Apr 2014 21:31:52 -0400
>> 
>> > This is a patch set Eric Paris and I have been working on to add a 
>> > restricted
>> > capability read-only netlink multicast socket to kernel audit to enable
>> > userspace clients such as systemd/journald to receive audit logs, in 
>> > addition
>> > to the bidirectional auditd userspace client.
>> 
>> Series applied, thanks Richard.
> 
> Thanks for your patience, David.  Can I assume you adopted the 3 audit
> patches too, becuase of the dependence?

Yes.
--
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] zram: correct offset usage in zram_bio_discard

[Weijie Yang]

On Wed, Apr 23, 2014 at 11:08 AM, Joonsoo Kim  wrote:
> On Wed, Apr 23, 2014 at 10:32:30AM +0800, Weijie Yang wrote:
>> On Wed, Apr 23, 2014 at 3:55 AM, Andrew Morton
>>  wrote:
>> > On Tue, 22 Apr 2014 11:14:02 +0800 Weijie Yang  
>> > wrote:
>> >
>> >> we want to skip the logical block which is partially covered by
>> >> the discard bio, so check the remaining size and subtract it if
>> >> there is a need to goto the next logical block.
>> >>
>> >> This patch corrects the offset usage in zram_bio_discard.
>> >>
>> >
>> > What were the end-user visible effects of the bug?
>> >
>> > Please always include this information when fixing something so that
>> > others can work out which kernel(s) need patching.
>> >
>>
>> Thanks for your advise, I will resend this patch and add the end-user
>> visible effect information.
>
> Thanks for fixing it.
>
> As far as I understand, there is no end-user visible effect, because
> request size is alway PAGE_SIZE aligned and if n < PAGE_SIZE,
> no real operation happens. Am I missing?

The zram only limit ZRAM_LOGICAL_BLOCK_SIZE(4K) aligned,
not PAGE_SIZE aligned.

Consider the following scenario:
on some architecture or config, PAGE_SIZE is 64K for example
filesystem is set up on zram disk without PAGE_SIZE aligned.
a discard bio leads to a offset = 4K, size=72K
normally, it should not really discard any physical block as it partially
cover two physical blocks.
However, with the current offset usage, it will discard the second
physical block and free its memory, which will cause filesystem breakdown.

regards,

> Anyway,
>
> Acked-by: Joonsoo Kim 
>
> Thanks.
--
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 5/5] NFS: avoid deadlocks with loop-back mounted NFS filesystems.

[NeilBrown]

Support for loop-back mounted NFS filesystems is useful when NFS is
used to access shared storage in a high-availability cluster.

If the node running the NFS server fails some other node can mount the
filesystem and start providing NFS service.  If that node already had
the filesystem NFS mounted, it will now have it loop-back mounted.

nfsd can suffer a deadlock when allocating memory and entering direct
reclaim.
While direct reclaim does not write to the NFS filesystem it can send
and wait for a COMMIT through nfs_release_page().

This patch modifies nfs_release_page() and the functions it calls so
that if the COMMIT is sent to the local host (i.e. is routed over the
loop-back interface) then nfs_release_page() will not wait forever for
that COMMIT to complete.

Aborting early should be safe as kswapd uses the same code but never
waits for the COMMIT.

Always aborting early could upset the balance of memory management so
when the commit was sent to the local host we still wait but with a
100ms timeout.  This is enough to significantly slow down any process
that is allocating lots of memory and often long enough to let the
commit complete.

In those rare cases where it is nfsd, or something that nfsd is
waiting for, that is calling nfs_release_page(), 100ms is not so long
that throughput will be affected.

When fail-over happens a remote (foreign) client will first become
disconnected and then turn into a local client.
To prevent deadlocks from happening at this point, we still have a
timeout when the COMMIT has been sent to a remote client. In this case
the timeout is longer (1 second).

So when a node that has mounted a remote filesystem loses the
connection, nfs_release_page() will stop blocking and start failing.
Memory allocators will then be able to make progress without blocking
in NFS.  Any process which writes to a file will still be blocked in
balance_dirty_pages().

I really need a version of wait_on_bit and friends which supports
timeouts for this patch.  I've hacked something that works by abusing
current->journal_info, but I don't expect that to go upstream.

I cannot simply use schedule_timeout in the wait_bit function as there
could be false wakeups due to hash collisions in bit_waitqueue().
One possibility would to be to have a 'private' field in 'struct
wait_bit_key' that was initialized to 0, and have the address of
that struct passed to the 'action' function.
There are currently 26 of these action functions so it wouldn't be too
hard to change the interface...

It might be good to use something like SetPageReclaim() to ensure that
the page is reclaimed as soon as the COMMIT does complete, but I don't
understand that code well enough yet to supply a patch.

Signed-off-by: NeilBrown 
---
 fs/nfs/file.c   |2 +
 fs/nfs/write.c  |   73 ++-
 include/linux/freezer.h |   10 ++
 include/uapi/linux/nfs_fs.h |3 ++
 4 files changed, 79 insertions(+), 9 deletions(-)

diff --git a/fs/nfs/file.c b/fs/nfs/file.c
index 5bb790a69c71..64a2999fe290 100644
--- a/fs/nfs/file.c
+++ b/fs/nfs/file.c
@@ -474,7 +474,7 @@ static int nfs_release_page(struct page *page, gfp_t gfp)
 */
if (mapping && (gfp & GFP_KERNEL) == GFP_KERNEL &&
!(current->flags & PF_FSTRANS)) {
-   int how = FLUSH_SYNC;
+   int how = FLUSH_SYNC | FLUSH_COND_CONNECTED;
 
/* Don't let kswapd deadlock waiting for OOM RPC calls */
if (current_is_kswapd())
diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index 9a3b6a4cd6b9..eadd3317fd85 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1440,6 +1441,43 @@ void nfs_writeback_done(struct rpc_task *task, struct 
nfs_write_data *data)
 
 
 #if IS_ENABLED(CONFIG_NFS_V3) || IS_ENABLED(CONFIG_NFS_V4)
+
+static int _wait_bit_connected(struct rpc_clnt *cl)
+{
+   if (fatal_signal_pending(current))
+   return -ERESTARTSYS;
+   if (!cl || rpc_is_foreign(cl)) {
+   /* it might not stay foreign forever */
+   freezable_schedule_timeout_unsafe(HZ);
+   } else {
+   unsigned long *commit_start = current->journal_info;
+   unsigned long waited = jiffies - *commit_start;
+
+   /* we could block forever here ... */
+   if (waited >= HZ/10)
+   /* Too long, give up */
+   return -EAGAIN;
+
+   freezable_schedule_timeout_unsafe(HZ/10 - waited);
+   }
+   return 0;
+}
+
+static int nfs_wait_bit_connected(void *word)
+{
+   struct nfs_inode *nfsi = container_of(word, struct nfs_inode, flags);
+
+   return _wait_bit_connected(NFS_CLIENT(&nfsi->vfs_inode));
+}
+
+static int rpc_wait_bit_connected(void *word)
+{
+   struct rpc_task *task = container_of(word, struct rpc_task, 
tk_runstate);
+
+   return _wait

linux-next: build failure after merge of the wireless-next tree

[Stephen Rothwell]

Hi John,

After merging the wireless-next tree, today's linux-next build (powerpc
allyesconfig) failed like this:

drivers/net/wireless/mwifiex/pcie.c: In function 'mwifiex_pcie_fw_dump_work':
drivers/net/wireless/mwifiex/pcie.c:2290:3: error: implicit declaration of 
function 'vmalloc' [-Werror=implicit-function-declaration]
   entry->mem_ptr = vmalloc(memory_size + 1);
   ^
drivers/net/wireless/mwifiex/pcie.c:2290:18: warning: assignment makes pointer 
from integer without a cast [enabled by default]
   entry->mem_ptr = vmalloc(memory_size + 1);
  ^
drivers/net/wireless/mwifiex/pcie.c:2361:4: error: implicit declaration of 
function 'vfree' [-Werror=implicit-function-declaration]
vfree(entry->mem_ptr);
^

Caused by commit e050c76fcf49 ("mwifiex: add firmware dump feature for
PCIe").

I have applied this patch for today:

From: Stephen Rothwell 
Date: Wed, 23 Apr 2014 13:44:59 +1000
Subject: [PATCH] mwifiex: using vmallog requires including vmalloc.h

Signed-off-by: Stephen Rothwell 
---
 drivers/net/wireless/mwifiex/pcie.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/mwifiex/pcie.c 
b/drivers/net/wireless/mwifiex/pcie.c
index 51989b31137a..9c1f42754bbe 100644
--- a/drivers/net/wireless/mwifiex/pcie.c
+++ b/drivers/net/wireless/mwifiex/pcie.c
@@ -17,6 +17,7 @@
  * this warranty disclaimer.
  */
 
+#include 
 #include 
 
 #include "decl.h"
-- 
1.9.2

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpFq4GVhQ7eu.pgp
Description: PGP signature

[PATCH 4/5] SUNRPC: track when a client connection is routed to the local host.

[NeilBrown]

If requests are being sent to the local host, then NFS will
need to take care to avoid deadlocks.

So keep track when accepting a connection or sending a UDP request
and set a flag in the svc_xprt when the peer connected to is local.

The interface rpc_is_foreign() is provided to check is a given client
is connected to a foreign server.  When it returns zero it is either
not connected or connected to a local server and in either case
greater care is needed.

Signed-off-by: NeilBrown 
---
 include/linux/sunrpc/clnt.h |1 +
 include/linux/sunrpc/xprt.h |1 +
 net/sunrpc/clnt.c   |   25 +
 net/sunrpc/xprtsock.c   |   17 +
 4 files changed, 44 insertions(+)

diff --git a/include/linux/sunrpc/clnt.h b/include/linux/sunrpc/clnt.h
index 8af2804bab16..5d626cc5ab01 100644
--- a/include/linux/sunrpc/clnt.h
+++ b/include/linux/sunrpc/clnt.h
@@ -173,6 +173,7 @@ voidrpc_force_rebind(struct rpc_clnt *);
 size_t rpc_peeraddr(struct rpc_clnt *, struct sockaddr *, size_t);
 const char *rpc_peeraddr2str(struct rpc_clnt *, enum rpc_display_format_t);
 intrpc_localaddr(struct rpc_clnt *, struct sockaddr *, size_t);
+intrpc_is_foreign(struct rpc_clnt *);
 
 #endif /* __KERNEL__ */
 #endif /* _LINUX_SUNRPC_CLNT_H */
diff --git a/include/linux/sunrpc/xprt.h b/include/linux/sunrpc/xprt.h
index 8097b9df6773..318ee37bc358 100644
--- a/include/linux/sunrpc/xprt.h
+++ b/include/linux/sunrpc/xprt.h
@@ -340,6 +340,7 @@ int xs_swapper(struct rpc_xprt *xprt, int 
enable);
 #define XPRT_CONNECTION_ABORT  (7)
 #define XPRT_CONNECTION_CLOSE  (8)
 #define XPRT_CONGESTED (9)
+#define XPRT_LOCAL (10)
 
 static inline void xprt_set_connected(struct rpc_xprt *xprt)
 {
diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index 0edada973434..454cea69b373 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -1109,6 +1109,31 @@ const char *rpc_peeraddr2str(struct rpc_clnt *clnt,
 }
 EXPORT_SYMBOL_GPL(rpc_peeraddr2str);
 
+/**
+ * rpc_is_foreign - report is rpc client was recently connected to
+ *  remote host
+ * @clnt: RPC client structure
+ *
+ * If the client is not connected, or connected to the local host
+ * (any IP address), then return 0.  Only return non-zero if the
+ * most recent state was a connection to a remote host.
+ * For UDP the client always appears to be connected, and the
+ * remoteness of the host is of the destination of the last transmission.
+ */
+int rpc_is_foreign(struct rpc_clnt *clnt)
+{
+   struct rpc_xprt *xprt;
+   int conn_foreign;
+
+   rcu_read_lock();
+   xprt = rcu_dereference(clnt->cl_xprt);
+   conn_foreign = (xprt && xprt_connected(xprt)
+   && !test_bit(XPRT_LOCAL, &xprt->state));
+   rcu_read_unlock();
+   return conn_foreign;
+}
+EXPORT_SYMBOL_GPL(rpc_is_foreign);
+
 static const struct sockaddr_in rpc_inaddr_loopback = {
.sin_family = AF_INET,
.sin_addr.s_addr= htonl(INADDR_ANY),
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index 0addefca8e77..74796cf37d5b 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -642,6 +642,15 @@ static int xs_udp_send_request(struct rpc_task *task)
xdr->len - req->rq_bytes_sent, status);
 
if (status >= 0) {
+   struct dst_entry *dst;
+   rcu_read_lock();
+   dst = rcu_dereference(transport->sock->sk->sk_dst_cache);
+   if (dst && dst->dev && (dst->dev->features & NETIF_F_LOOPBACK))
+   set_bit(XPRT_LOCAL, &xprt->state);
+   else
+   clear_bit(XPRT_LOCAL, &xprt->state);
+   rcu_read_unlock();
+
req->rq_xmit_bytes_sent += status;
if (status >= req->rq_slen)
return 0;
@@ -1527,6 +1536,7 @@ static void xs_sock_mark_closed(struct rpc_xprt *xprt)
 static void xs_tcp_state_change(struct sock *sk)
 {
struct rpc_xprt *xprt;
+   struct dst_entry *dst;
 
read_lock_bh(&sk->sk_callback_lock);
if (!(xprt = xprt_from_sock(sk)))
@@ -1556,6 +1566,13 @@ static void xs_tcp_state_change(struct sock *sk)
 
xprt_wake_pending_tasks(xprt, -EAGAIN);
}
+   rcu_read_lock();
+   dst = rcu_dereference(sk->sk_dst_cache);
+   if (dst && dst->dev && (dst->dev->features & NETIF_F_LOOPBACK))
+   set_bit(XPRT_LOCAL, &xprt->state);
+   else
+   clear_bit(XPRT_LOCAL, &xprt->state);
+   rcu_read_unlock();
spin_unlock(&xprt->transport_lock);
break;
case TCP_FIN_WAIT1:


--
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

[PATCH 3/5] nfsd: Only set PF_LESS_THROTTLE when really needed.

[NeilBrown]

PF_LESS_THROTTLE has a very specific use case: to avoid deadlocks
and live-locks while writing to the page cache in a loop-back
NFS mount situation.

It therefore makes sense to *only* set PF_LESS_THROTTLE in this
situation.
We now know when a request came from the local-host so it could be a
loop-back mount.  We already know when we are handling write requests,
and when we are doing anything else.

So combine those two to allow nfsd to still be throttled (like any
other process) in every situation except when it is known to be
problematic.

Signed-off-by: NeilBrown 
---
 fs/nfsd/nfssvc.c |6 --
 fs/nfsd/vfs.c|   12 
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/fs/nfsd/nfssvc.c b/fs/nfsd/nfssvc.c
index 9a4a5f9e7468..1879e43f2868 100644
--- a/fs/nfsd/nfssvc.c
+++ b/fs/nfsd/nfssvc.c
@@ -591,12 +591,6 @@ nfsd(void *vrqstp)
nfsdstats.th_cnt++;
mutex_unlock(&nfsd_mutex);
 
-   /*
-* We want less throttling in balance_dirty_pages() so that nfs to
-* localhost doesn't cause nfsd to lock up due to all the client's
-* dirty pages.
-*/
-   current->flags |= PF_LESS_THROTTLE;
set_freezable();
 
/*
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 6d7be3f80356..2acd00445ad0 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -913,6 +913,16 @@ nfsd_vfs_write(struct svc_rqst *rqstp, struct svc_fh *fhp, 
struct file *file,
int stable = *stablep;
int use_wgather;
loff_t  pos = offset;
+   unsigned intpflags = current->flags;
+
+   if (rqstp->rq_local)
+   /*
+* We want less throttling in balance_dirty_pages()
+* and shrink_inactive_list() so that nfs to
+* localhost doesn't cause nfsd to lock up due to all
+* the client's dirty pages or its congested queue.
+*/
+   current->flags |= PF_LESS_THROTTLE;
 
dentry = file->f_path.dentry;
inode = dentry->d_inode;
@@ -950,6 +960,8 @@ out_nfserr:
err = 0;
else
err = nfserrno(host_err);
+   if (rqstp->rq_local)
+   tsk_restore_flags(current, pflags, PF_LESS_THROTTLE);
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 2/5] SUNRPC: track whether a request is coming from a loop-back interface.

[NeilBrown]

If an incoming NFS request is coming from the local host, then
nfsd will need to perform some special handling.  So detect that
possibility and make the source visible in rq_local.

Signed-off-by: NeilBrown 
---
 include/linux/sunrpc/svc.h  |1 +
 include/linux/sunrpc/svc_xprt.h |1 +
 net/sunrpc/svcsock.c|   10 ++
 3 files changed, 12 insertions(+)

diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h
index 04e763221246..a0dbbd1e00e9 100644
--- a/include/linux/sunrpc/svc.h
+++ b/include/linux/sunrpc/svc.h
@@ -254,6 +254,7 @@ struct svc_rqst {
u32 rq_prot;/* IP protocol */
unsigned short
rq_secure  : 1; /* secure port */
+   unsigned short  rq_local   : 1; /* local request */
 
void *  rq_argp;/* decoded arguments */
void *  rq_resp;/* xdr'd results */
diff --git a/include/linux/sunrpc/svc_xprt.h b/include/linux/sunrpc/svc_xprt.h
index b05963f09ebf..b99bdfb0fcf9 100644
--- a/include/linux/sunrpc/svc_xprt.h
+++ b/include/linux/sunrpc/svc_xprt.h
@@ -63,6 +63,7 @@ struct svc_xprt {
 #defineXPT_DETACHED10  /* detached from tempsocks list 
*/
 #define XPT_LISTENER   11  /* listening endpoint */
 #define XPT_CACHE_AUTH 12  /* cache auth info */
+#define XPT_LOCAL  13  /* connection from loopback interface */
 
struct svc_serv *xpt_server;/* service for transport */
atomic_txpt_reserved;   /* space on outq that is rsvd */
diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index b6e59f0a9475..193115fe968c 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -811,6 +811,7 @@ static struct svc_xprt *svc_tcp_accept(struct svc_xprt 
*xprt)
struct socket   *newsock;
struct svc_sock *newsvsk;
int err, slen;
+   struct dst_entry *dst;
RPC_IFDEBUG(char buf[RPC_MAX_ADDRBUFLEN]);
 
dprintk("svc: tcp_accept %p sock %p\n", svsk, sock);
@@ -867,6 +868,14 @@ static struct svc_xprt *svc_tcp_accept(struct svc_xprt 
*xprt)
}
svc_xprt_set_local(&newsvsk->sk_xprt, sin, slen);
 
+   clear_bit(XPT_LOCAL, &newsvsk->sk_xprt.xpt_flags);
+   rcu_read_lock();
+   dst = rcu_dereference(newsock->sk->sk_dst_cache);
+   if (dst && dst->dev &&
+   (dst->dev->features & NETIF_F_LOOPBACK))
+   set_bit(XPT_LOCAL, &newsvsk->sk_xprt.xpt_flags);
+   rcu_read_unlock();
+
if (serv->sv_stats)
serv->sv_stats->nettcpconn++;
 
@@ -1112,6 +1121,7 @@ static int svc_tcp_recvfrom(struct svc_rqst *rqstp)
 
rqstp->rq_xprt_ctxt   = NULL;
rqstp->rq_prot= IPPROTO_TCP;
+   rqstp->rq_local   = !!test_bit(XPT_LOCAL, &svsk->sk_xprt.xpt_flags);
 
p = (__be32 *)rqstp->rq_arg.head[0].iov_base;
calldir = p[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 1/5] MM: avoid throttling reclaim for loop-back nfsd threads.

[NeilBrown]

When a loop-back NFS mount is active and the backing device for the
NFS mount becomes congested, that can impose throttling delays on the
nfsd threads.

These delays significantly reduce throughput and so the NFS mount
remains congested.

This results in a live lock and the reduced throughput persists.

This live lock has been found in testing with the 'wait_iff_congested'
call, and could possibly be caused by the 'congestion_wait' call.

This livelock is similar to the deadlock which justified the
introduction of PF_LESS_THROTTLE, and the same flag can be used to
remove this livelock.

To minimise the impact of the change, we still throttle nfsd when the
filesystem it is writing to is congested, but not when some separate
filesystem (e.g. the NFS filesystem) is congested.

Signed-off-by: NeilBrown 
---
 mm/vmscan.c |   18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index a9c74b409681..e011a646de95 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1424,6 +1424,18 @@ putback_inactive_pages(struct lruvec *lruvec, struct 
list_head *page_list)
list_splice(&pages_to_free, page_list);
 }
 
+/* If a kernel thread (such as nfsd for loop-back mounts) services
+ * a backing device by writing to the page cache it sets PF_LESS_THROTTLE.
+ * In that case we should only throttle if the backing device it is
+ * writing to is congested.  In other cases it is safe to throttle.
+ */
+static int current_may_throttle(void)
+{
+   return !(current->flags & PF_LESS_THROTTLE) ||
+   current->backing_dev_info == NULL ||
+   bdi_write_congested(current->backing_dev_info);
+}
+
 /*
  * shrink_inactive_list() is a helper for shrink_zone().  It returns the number
  * of reclaimed pages
@@ -1552,7 +1564,8 @@ shrink_inactive_list(unsigned long nr_to_scan, struct 
lruvec *lruvec,
 * implies that pages are cycling through the LRU faster than
 * they are written so also forcibly stall.
 */
-   if (nr_unqueued_dirty == nr_taken || nr_immediate)
+   if ((nr_unqueued_dirty == nr_taken || nr_immediate)
+   && current_may_throttle())
congestion_wait(BLK_RW_ASYNC, HZ/10);
}
 
@@ -1561,7 +1574,8 @@ shrink_inactive_list(unsigned long nr_to_scan, struct 
lruvec *lruvec,
 * is congested. Allow kswapd to continue until it starts encountering
 * unqueued dirty pages or cycling through the LRU too quickly.
 */
-   if (!sc->hibernation_mode && !current_is_kswapd())
+   if (!sc->hibernation_mode && !current_is_kswapd()
+   && current_may_throttle())
wait_iff_congested(zone, BLK_RW_ASYNC, HZ/10);
 
trace_mm_vmscan_lru_shrink_inactive(zone->zone_pgdat->node_id,


--
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/RFC 0/5] Support loop-back NFS mounts - take 2

[NeilBrown]

This is a somewhat shorter patchset for loop-back NFS support than
last time, thanks to the excellent feedback and particularly to Dave
Chinner.  Thanks.

Avoiding the wait-for-congestion which can trigger a livelock is much
the same, though I've reduced the cases in which the wait is
by-passed.
I did this using current->backing_dev_info which is otherwise serving
no purpose on the current kernel.

Avoiding the deadlocks has been turned on its head.
Instead of nfsd checking if it is a loop-back mount and setting
PF_FSTRANS, which then needs lots of changes too PF_FSTRANS and
__GFP_FS handling, it is now NFS which checks for a loop-back
filesystem.

There is more verbosity in that patch (Fifth of Five) but the essence
is that nfs_release_page will now not wait indefinitely for a COMMIT
request to complete when sent to the local host.  It still waits a
little while as some delay can be important. But it won't wait
forever.
The duration of "a little while" is currently 100ms, though I do
wonder if a bigger number would serve just as well.

Unlike the previous series, this set should remove deadlocks that
could happen during the actual fail-over process.  This is achieved by
having nfs_release_page monitor the connection and if it changes from
a remote to a local connection, or just disconnects, then it will
timeout.  It currently polls every second, though this probably could
be longer too.  It only needs to be the same order of magnitude as the
time it takes node failure to be detected and failover to happen, and
I suspect that is closer to 1 minute.  So maybe a 10 or 20 second poll
interval would be just as good.

Implementing this timeout requires some horrible code as the
wait_on_bit functions don't support timeouts.  If the general approach
is found acceptable I'll explore ways to improve the timeout code.

Comments, criticism, etc very welcome as always,

Thanks,
NeilBrown


---

NeilBrown (5):
  MM: avoid throttling reclaim for loop-back nfsd threads.
  SUNRPC: track whether a request is coming from a loop-back interface.
  nfsd: Only set PF_LESS_THROTTLE when really needed.
  SUNRPC: track when a client connection is routed to the local host.
  NFS: avoid deadlocks with loop-back mounted NFS filesystems.


 fs/nfs/file.c   |2 +
 fs/nfs/write.c  |   73 +++
 fs/nfsd/nfssvc.c|6 ---
 fs/nfsd/vfs.c   |   12 ++
 include/linux/freezer.h |   10 +
 include/linux/sunrpc/clnt.h |1 +
 include/linux/sunrpc/svc.h  |1 +
 include/linux/sunrpc/svc_xprt.h |1 +
 include/linux/sunrpc/xprt.h |1 +
 include/uapi/linux/nfs_fs.h |3 ++
 mm/vmscan.c |   18 +-
 net/sunrpc/clnt.c   |   25 +
 net/sunrpc/svcsock.c|   10 +
 net/sunrpc/xprtsock.c   |   17 +
 14 files changed, 163 insertions(+), 17 deletions(-)

-- 
Signature

--
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 03/10] staging: rtl8188eu: Remove _ReadLEDSetting() function.

[navin patidar]

On Tue, Apr 22, 2014 at 7:58 PM, Larry Finger  wrote:
>
> To me, the opposite case is true. If you have not tested, then you need to
> explicitly state "compile tested only" in the commit message. Without saying
> that, your signed-off-by is implying that you have tested, as well as
> declaring that you own the copyright to the material.

I didn't know that  signed-off-by implies both tested and authored.
thanks for clearing that up.

regards,
--navin-patidar
--
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/

[RFC][PATCH 2/3] printk: Add printk_once_deferred

[John Stultz]

Two of the three prink_deferred uses are really printk_once style
uses, so add a printk_once_deferred macro to simplify those call
sites.

Cc: Jan Kara 
Cc: Peter Zijlstra 
Cc: Jiri Bohac 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Andrew Morton 
Signed-off-by: John Stultz 
---
 include/linux/printk.h  | 11 +++
 kernel/sched/deadline.c |  7 +--
 kernel/sched/rt.c   |  8 +---
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index 7847301..bd21234 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -266,9 +266,20 @@ extern asmlinkage void dump_stack(void) __cold;
printk(fmt, ##__VA_ARGS__); \
}   \
 })
+#define printk_once_deferred(fmt, ...) \
+({ \
+   static bool __print_once __read_mostly; \
+   \
+   if (!__print_once) {\
+   __print_once = true;\
+   printk_deferred(fmt, ##__VA_ARGS__);\
+   }   \
+})
 #else
 #define printk_once(fmt, ...)  \
no_printk(fmt, ##__VA_ARGS__)
+#define printk_once_deferred(fmt, ...) \
+   no_printk(fmt, ##__VA_ARGS__)
 #endif
 
 #define pr_emerg_once(fmt, ...)\
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 657ed68..3ec96bd 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -348,12 +348,7 @@ static void replenish_dl_entity(struct sched_dl_entity 
*dl_se,
 * entity.
 */
if (dl_time_before(dl_se->deadline, rq_clock(rq))) {
-   static bool lag_once = false;
-
-   if (!lag_once) {
-   lag_once = true;
-   printk_deferred("sched: DL replenish lagged to much\n");
-   }
+   printk_once_deferred("sched: DL replenish lagged to much\n");
dl_se->deadline = rq_clock(rq) + pi_se->dl_deadline;
dl_se->runtime = pi_se->dl_runtime;
}
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index c19b3cc..722e9a3 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -851,14 +851,8 @@ static int sched_rt_runtime_exceeded(struct rt_rq *rt_rq)
 * but accrue some time due to boosting.
 */
if (likely(rt_b->rt_runtime)) {
-   static bool once = false;
-
rt_rq->rt_throttled = 1;
-
-   if (!once) {
-   once = true;
-   printk_deferred("sched: RT throttling 
activated\n");
-   }
+   printk_once_deferred("sched: RT throttling 
activated\n");
} else {
/*
 * In case we did anyway, make it go away,
-- 
1.8.3.2

--
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/

[RFC][PATCH 3/3] timekeeping: Use printk_deferred when holding timekeeping seqlock

[John Stultz]

Jiri Bohac pointed out that there are rare but potential deadlock
possibilities when calling printk while holding the timekeeping
seqlock.

This is due to printk() triggering console sem wakeup, which can
cause scheduling code to trigger hrtimers which may try to read
the time.

Specifically, as Jiri pointed out, that path is:
  printk
vprintk_emit
  console_unlock
up(&console_sem)
  __up
wake_up_process
  try_to_wake_up
ttwu_do_activate
  ttwu_activate
activate_task
  enqueue_task
enqueue_task_fair
  hrtick_update
hrtick_start_fair
  hrtick_start_fair
get_time
  ktime_get
--> endless loop on
read_seqcount_retry(&timekeeper_seq, ...)

This patch tries to avoid this issue by using printk_deferred (previously
named printk_sched) which should defer printing via a irq_work_queue.

Cc: Jan Kara 
Cc: Peter Zijlstra 
Cc: Jiri Bohac 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Andrew Morton 
Reported-by: Jiri Bohac 
Signed-off-by: John Stultz 
---
 kernel/time/ntp.c | 15 +--
 kernel/time/timekeeping.c |  7 ---
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 419a52c..5b0ac4d 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -786,8 +786,9 @@ static long hardpps_update_freq(struct pps_normtime 
freq_norm)
time_status |= STA_PPSERROR;
pps_errcnt++;
pps_dec_freq_interval();
-   pr_err("hardpps: PPSERROR: interval too long - %ld s\n",
-   freq_norm.sec);
+   printk_deferred(KERN_ERR
+   "hardpps: PPSERROR: interval too long - %ld s\n",
+   freq_norm.sec);
return 0;
}
 
@@ -800,7 +801,8 @@ static long hardpps_update_freq(struct pps_normtime 
freq_norm)
delta = shift_right(ftemp - pps_freq, NTP_SCALE_SHIFT);
pps_freq = ftemp;
if (delta > PPS_MAXWANDER || delta < -PPS_MAXWANDER) {
-   pr_warning("hardpps: PPSWANDER: change=%ld\n", delta);
+   printk_deferred(KERN_WARNING
+   "hardpps: PPSWANDER: change=%ld\n", delta);
time_status |= STA_PPSWANDER;
pps_stbcnt++;
pps_dec_freq_interval();
@@ -844,8 +846,9 @@ static void hardpps_update_phase(long error)
 * the time offset is updated.
 */
if (jitter > (pps_jitter << PPS_POPCORN)) {
-   pr_warning("hardpps: PPSJITTER: jitter=%ld, limit=%ld\n",
-  jitter, (pps_jitter << PPS_POPCORN));
+   printk_deferred(KERN_WARNING
+   "hardpps: PPSJITTER: jitter=%ld, limit=%ld\n",
+   jitter, (pps_jitter << PPS_POPCORN));
time_status |= STA_PPSJITTER;
pps_jitcnt++;
} else if (time_status & STA_PPSTIME) {
@@ -902,7 +905,7 @@ void __hardpps(const struct timespec *phase_ts, const 
struct timespec *raw_ts)
time_status |= STA_PPSJITTER;
/* restart the frequency calibration interval */
pps_fbase = *raw_ts;
-   pr_err("hardpps: PPSJITTER: bad pulse\n");
+   printk_deferred(KERN_ERR "hardpps: PPSJITTER: bad pulse\n");
return;
}
 
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index f7df8ea..ffd3113 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -852,8 +852,9 @@ static void __timekeeping_inject_sleeptime(struct 
timekeeper *tk,
struct timespec *delta)
 {
if (!timespec_valid_strict(delta)) {
-   printk(KERN_WARNING "__timekeeping_inject_sleeptime: Invalid "
-   "sleep delta value!\n");
+   printk_deferred(KERN_WARNING
+   "__timekeeping_inject_sleeptime: Invalid "
+   "sleep delta value!\n");
return;
}
tk_xtime_add(tk, delta);
@@ -1157,7 +1158,7 @@ static void timekeeping_adjust(struct timekeeper *tk, s64 
offset)
 
if (unlikely(tk->clock->maxadj &&
(tk->mult + adj > tk->clock->mult + tk->clock->maxadj))) {
-   printk_once(KERN_WARNING
+   printk_once_deferred(KERN_WARNING
"Adjusting %s more than 11%% (%ld vs %ld)\n",
tk->clock->name, (long)tk->mult + adj,
(long)tk->clock->mult + tk->clock->maxadj);
-- 
1.8.3.2

--
To unsubscribe from this list: send t

[RFC][PATCH 0/3] Convert timekeeping core to use printk_deferred

[John Stultz]

Jiri pointed out a potential deadlock when calling printk while holding
the timekeeping seqlock.

Annoyingly, the seqlock lockdep enablement doesn't catch this, as
printk disables lockdep.

When looking for possible solutions, one idea was to use a local buffer
and defer the printk to later. Ends up there is already similar
functionality in printk_sched() to avoid similar style deadlocks w/
the scheduler. 

Thus this patchset renames printk_sched to printk_deferred and then
moves the affected timekeeping printks to make use of it.

There were some points in the discussion between Jan and Peter that
made it seem that there may still be problems lurking in the console
layer, and I'm not sure I fully understand their point, so this solution
may be incomplete.

Additionally, the same issue likely affects any WARN_ONs as well, but
I wanted to get some thoughts on this approach before trying to remove
or convert affected WARN_ONS.

Your thoughts and feedback are greatly appreciated!

thanks
-john


Cc: Jan Kara 
Cc: Peter Zijlstra 
Cc: Jiri Bohac 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Andrew Morton 

John Stultz (3):
  printk: Rename printk_sched to printk_deferred
  printk: Add printk_once_deferred
  timekeeping: Use printk_deferred when holding timekeeping seqlock

 include/linux/printk.h| 17 ++---
 kernel/printk/printk.c|  8 
 kernel/sched/core.c   |  2 +-
 kernel/sched/deadline.c   |  7 +--
 kernel/sched/rt.c |  8 +---
 kernel/time/ntp.c | 15 +--
 kernel/time/timekeeping.c |  7 ---
 7 files changed, 34 insertions(+), 30 deletions(-)

-- 
1.8.3.2

--
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/

[RFC][PATCH 1/3] printk: Rename printk_sched to printk_deferred

[John Stultz]

After learning we'll need some sort of deferred printk functionality
in the timekeeping core, Peter suggested we rename the printk_sched
function so it can be reused by needed subsystems.

This only changes the function name and name of the associated buffer.
No logic changes.

Cc: Jan Kara 
Cc: Peter Zijlstra 
Cc: Jiri Bohac 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Andrew Morton 
Signed-off-by: John Stultz 
---
 include/linux/printk.h  | 6 +++---
 kernel/printk/printk.c  | 8 
 kernel/sched/core.c | 2 +-
 kernel/sched/deadline.c | 2 +-
 kernel/sched/rt.c   | 2 +-
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index 8752f75..7847301 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -128,9 +128,9 @@ asmlinkage __printf(1, 2) __cold
 int printk(const char *fmt, ...);
 
 /*
- * Special printk facility for scheduler use only, _DO_NOT_USE_ !
+ * Special printk facility for scheduler/timekeeping use only, _DO_NOT_USE_ !
  */
-__printf(1, 2) __cold int printk_sched(const char *fmt, ...);
+__printf(1, 2) __cold int printk_deferred(const char *fmt, ...);
 
 /*
  * Please don't use printk_ratelimit(), because it shares ratelimiting state
@@ -165,7 +165,7 @@ int printk(const char *s, ...)
return 0;
 }
 static inline __printf(1, 2) __cold
-int printk_sched(const char *s, ...)
+int printk_deferred(const char *s, ...)
 {
return 0;
 }
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index a45b509..a9763e4 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2443,14 +2443,14 @@ late_initcall(printk_late_init);
 #define PRINTK_PENDING_SCHED   0x02
 
 static DEFINE_PER_CPU(int, printk_pending);
-static DEFINE_PER_CPU(char [PRINTK_BUF_SIZE], printk_sched_buf);
+static DEFINE_PER_CPU(char [PRINTK_BUF_SIZE], printk_deferred_buf);
 
 static void wake_up_klogd_work_func(struct irq_work *irq_work)
 {
int pending = __this_cpu_xchg(printk_pending, 0);
 
if (pending & PRINTK_PENDING_SCHED) {
-   char *buf = __get_cpu_var(printk_sched_buf);
+   char *buf = __get_cpu_var(printk_deferred_buf);
pr_warn("[sched_delayed] %s", buf);
}
 
@@ -2473,7 +2473,7 @@ void wake_up_klogd(void)
preempt_enable();
 }
 
-int printk_sched(const char *fmt, ...)
+int printk_deferred(const char *fmt, ...)
 {
unsigned long flags;
va_list args;
@@ -2481,7 +2481,7 @@ int printk_sched(const char *fmt, ...)
int r;
 
local_irq_save(flags);
-   buf = __get_cpu_var(printk_sched_buf);
+   buf = __get_cpu_var(printk_deferred_buf);
 
va_start(args, fmt);
r = vsnprintf(buf, PRINTK_BUF_SIZE, fmt, args);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 268a45e..423704c 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1320,7 +1320,7 @@ out:
 * leave kernel.
 */
if (p->mm && printk_ratelimit()) {
-   printk_sched("process %d (%s) no longer affine to 
cpu%d\n",
+   printk_deferred("process %d (%s) no longer affine to 
cpu%d\n",
task_pid_nr(p), p->comm, cpu);
}
}
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index b080957..657ed68 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -352,7 +352,7 @@ static void replenish_dl_entity(struct sched_dl_entity 
*dl_se,
 
if (!lag_once) {
lag_once = true;
-   printk_sched("sched: DL replenish lagged to much\n");
+   printk_deferred("sched: DL replenish lagged to much\n");
}
dl_se->deadline = rq_clock(rq) + pi_se->dl_deadline;
dl_se->runtime = pi_se->dl_runtime;
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index bd2267a..c19b3cc 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -857,7 +857,7 @@ static int sched_rt_runtime_exceeded(struct rt_rq *rt_rq)
 
if (!once) {
once = true;
-   printk_sched("sched: RT throttling 
activated\n");
+   printk_deferred("sched: RT throttling 
activated\n");
}
} else {
/*
-- 
1.8.3.2

--
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/

[perf] yet another 32/64-bit range check failure

[Vince Weaver]

More fun found by the perf_fuzzer...

In kernel/events/core.c 
SYSCALL_DEFINE5(perf_event_open,

We check if flags is valid like this:

/* for future expandability... */
if (flags & ~PERF_FLAG_ALL)
return -EINVAL;

but flags is a 64-bit value but ~PERF_FLAG_ALL is 32-bit.

This means values like 0x8000ULL are treated as valid even though 
they aren't.

This is allowing events to be allocated memory but not being freed somehow
before returning EINVAL (a memory leak).
At least it looks like this is happening in the huge traces I have trying 
to track down the perf_fuzzer memory corruption bug.

I'd send a patch to fix the above, but it's late and I can't figure out 
where exactly to stick ULL to get PERF_FLAG_ALL to be upgraded to 64-bit.

Vince
--
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 09/10] staging: rtl8188eu: Remove unused enum LED_STATE_871x members.

[navin patidar]

dan, It is ok to rearrange and remove members of  enum LED_STATE_871x
and  enum LED_CTL_MODE.
these enum are not related to firmware .

regards,
--navin-patidar

On Tue, Apr 22, 2014 at 4:05 PM, Dan Carpenter  wrote:
> It's ok to renumber all of these?  It's not something the firmware will
> care about?  Have you tested this?  Same for patch 10/10.
>
> (These questions are just questions.  I don't ask rhetorical questions
> on email.  I don't know the answers).
>
> regards,
> dan carpenter
>
--
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 20/28] nios2: Time keeping

[Ley Foon Tan]

On Tue, Apr 22, 2014 at 9:44 PM, Arnd Bergmann  wrote:
> On Friday 18 April 2014, Ley Foon Tan wrote:
>> +static inline unsigned long read_timersnapshot(void)
>> +{
>> +   unsigned long count;
>> +
>> +   outw(0, timer_membase + ALTERA_TIMER_SNAPL_REG);
>> +   count =
>> +   inw(timer_membase + ALTERA_TIMER_SNAPH_REG) << 16 |
>> +   inw(timer_membase + ALTERA_TIMER_SNAPL_REG);
>> +
>> +   return count;
>> +}
>> +
>> +static inline void write_timerperiod(unsigned long period)
>> +{
>> +   outw(period, timer_membase + ALTERA_TIMER_PERIODL_REG);
>> +   outw(period >> 16, timer_membase + ALTERA_TIMER_PERIODH_REG);
>> +}
>
> It's wrong to use 'outw' if this device is not on an PC-style ISA bus,
> which I assume it is not. Since timer_membase is an __iomem pointer,
> I'm sure you want to use writew() instead.
>
> Arnd
Sure, will change all outw() to writew() and inw() to readw().

Ley Foon
--
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 2/6] netlink: have netlink per-protocol bind function return an error code.

[Richard Guy Briggs]

On 14/04/22, David Miller wrote:
> From: Richard Guy Briggs 
> Date: Fri, 18 Apr 2014 13:34:06 -0400
> 
> > @@ -1449,6 +1453,26 @@ static int netlink_bind(struct socket *sock, struct 
> > sockaddr *addr,
> > if (!nladdr->nl_groups && (nlk->groups == NULL || !(u32)nlk->groups[0]))
> > return 0;
> >  
> > +   if (nlk->netlink_bind && nladdr->nl_groups) {
> > +   int i;
> > +
> > +   for (i = 0; i < nlk->ngroups; i++) {
> > +   int undo;
> > +
> > +   if (!test_bit(i, (long unsigned int 
> > *)&nladdr->nl_groups))
> > +   continue;
> > +   err = nlk->netlink_bind(i);
> > +   if (!err)
> > +   continue;
> > +   if (!nlk->portid)
> > +   netlink_remove(sk);
> > +   for (undo = 0; undo < i; undo++)
> > +   if (nlk->netlink_unbind)
> > +   nlk->netlink_unbind(undo);
> > +   return err;
> > +   }
> > +   }
> > +
> 
> It took me a while to figure out why you need to do the netlink_remove() in
> the error path.
> 
> I think it's really asking for trouble to allow the socket to have temporary
> visibility if we end up signalling an error.

The risk seems small, but I agree it is sloppy.

> It seems safest if we only do the autobind/insert once we are absolutely
> certain that the bind() will fully succeed.  This means that you have to
> do this bind validation loop before autobind/insert.

Ok, done.  This revision ends up being a bit cleaner than the previous
one because I've refactored out the unbind loop into netlink_unbind()
due to it needing to be called if the netlink_insert/autobind() fails as
well.  In the factorization process I noticed that unrequested groups
were being unnecessarily unbound.  It also provoked assigning the var
"groups" from "nladdr->nl_groups" making things easier to read.

> Please make this change and resubmit this series, thanks.

Compiled and tested.  New patchset to follow.

- RGB

--
Richard Guy Briggs 
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red 
Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
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] sysfs, device-tree: aid for debugging device tree boot problems

[Greg Kroah-Hartman]

On Tue, Apr 22, 2014 at 06:25:25PM -0700, Frank Rowand wrote:
> Create some infrastructure to aid trouble shooting device tree related
> boot issues.
> 
> Add a %driver_name file to each device tree node sysfs directory which has had
> a driver bound to it.  This allows detecting device tree nodes which failed
> to be bound to any driver.

Why is this needed, shouldn't there already be a "driver" symlink in
sysfs for these devices when a driver binds to them?  The rest of the
driver model works that way, why is of devices any different?

> Examples of using the %driver_name file (note that /proc/device-tree is a
> link to the base of the device tree sysfs tree):
> 
> 
>   1) To find list of device tree nodes with no driver:
> 
>   # A few false positives may be reported.  For example,
>   #   node_full_path of "." is the board.
>   #
>   # output is: node_full_path compatible_string
>   #
>   cd /proc/device-tree
>   for k in `find . -type d`; do
>  if [[ -f ${k}/compatible && ! -f ${k}/%driver_name ]] ; then
> if [[ "`cat ${k}/compatible`" != "simple-bus" ]] ; then
>echo `echo ${k} | sed -e 's|./||'` `cat ${k}/compatible`
> fi
>  fi
>   done | sort
> 
> 
>   2) To find list of device tree nodes with a bound driver:
> 
>   # output is:  node_full_path driver_name
>   #
>   cd /proc/device-tree
>   for k in `find . -name %driver_name` ; do
>  echo `echo ${k} | sed -e 's|./||' -e 's|/%driver_name$||'` `cat ${k}`
>   done | sort
> 
> 
>   3) To find list of device tree nodes with a bound driver:
> 
>   # output is:  driver_name node_full_path
>   #
>   cd /proc/device-tree
>   for k in `find . -name %driver_name` ; do
>  echo `cat ${k}` `echo ${k} | sed -e 's|./||' -e 's|/%driver_name$||'`
>   done | sort

If we take this patch, these examples should be somewhere in the
documentation to make it easy for others.

> Signed-off-by: Frank Rowand 

Minor nit, your From: line doesn't match this signed-off-by: so
something has to change (or add a new From: line, like SubmittingPatches
decribes how to do.)

thanks,

greg k-h
--
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] zram: correct offset usage in zram_bio_discard

[Joonsoo Kim]

On Wed, Apr 23, 2014 at 10:32:30AM +0800, Weijie Yang wrote:
> On Wed, Apr 23, 2014 at 3:55 AM, Andrew Morton
>  wrote:
> > On Tue, 22 Apr 2014 11:14:02 +0800 Weijie Yang  
> > wrote:
> >
> >> we want to skip the logical block which is partially covered by
> >> the discard bio, so check the remaining size and subtract it if
> >> there is a need to goto the next logical block.
> >>
> >> This patch corrects the offset usage in zram_bio_discard.
> >>
> >
> > What were the end-user visible effects of the bug?
> >
> > Please always include this information when fixing something so that
> > others can work out which kernel(s) need patching.
> >
> 
> Thanks for your advise, I will resend this patch and add the end-user
> visible effect information.

Thanks for fixing it.

As far as I understand, there is no end-user visible effect, because
request size is alway PAGE_SIZE aligned and if n < PAGE_SIZE,
no real operation happens. Am I missing?

Anyway,

Acked-by: Joonsoo Kim 

Thanks.
--
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/