Re: sysfs permissions on dynamic attributes (led delay_on and delay_off)

[Colin Cross]

On Fri, Jul 20, 2012 at 9:08 PM, Greg KH  wrote:
> On Fri, Jul 20, 2012 at 05:46:14PM -0700, Colin Cross wrote:
>> I'm trying to use the standard ledtrig-timer.c code to handle led
>> blinking for notifications on an Android device, and I'm hitting some
>> issues with setting permissions on the dynamically created delay_on
>> and delay_off attributes.  For most sysfs files, we have userspace
>> uevent parser that watches for device add notifications and
>> chowns/chmods attributes.  This doesn't work for delay_on and
>> delay_off, because they are created later, when "timer" is written to
>> the trigger attribute.  There is no uevent when the new files are
>> created, and sysfs doesn't support inotify, so I don't see any way to
>> receive an event to set the permissions.  This issue exists any time
>> that device_create_file is called after device_add.
>>
>> What is the appropriate way to get an event to set the permissions?
>> Add inotify support for sysfs file creation?  Send a KOBJ_CHANGE
>> uevent in device_create_file?
>
> No.
>
>> Send a KOBJ_CHANGE uevent from the driver after calling
>> device_create_file?
>
> Yes.
>
>> Dynamically create a timer device under /sys/class/leds/ so a new
>> add uevent gets sent?
>
> Ick.
>
>> Promote blinking to be a core led feature instead of a trigger, so the
>> files are always present?
>
> That's the best thing, why not just do that?

It doesn't solve the general case.  For example, any driver that is
loaded as a module and then calls device_create_file will suffer the
same problem.  But since it solves the one I care about, I'll look
into it.
--
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: [RFC] firmware load: defer request_firmware during early boot and resume

[Ming Lei]

CC guys who discussed the problem in the below link in Jan. :

  http://marc.info/?t=13252895602=10=2

On Fri, Jul 20, 2012 at 8:33 PM, Ming Lei  wrote:
> The RFC patch is just for discussing if the idea of deferring
> request_firmware is doable for addressing the issue of
> request_firmware in resume path, which is caused by driver
> unbind/rebind during resume.
>
> At least usb bus is involved in such things, one driver may be
> unbound and rebound in resume path at several situations, and
> request_firmware is often called inside probe().
>
> Also the idea should be helpful for other hotplug buses too,
> at least there was the similar problem report on pcmcia bus.

Looks it works well in my two test cases: one is to call request_firmware
in early boot(initcall), another one is to call request_firmware in probe()
of resume path(caused by unbind & rebind).  And without the patch, both
two request_firmware return failure and can't complete the loading.

V1:
only defer handling the requests called from probe()

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 6cd2c6c..fb02eff 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -123,7 +123,7 @@ static bool driver_deferred_probe_enable = false;
  * list and schedules the deferred probe workqueue to process them.  It
  * should be called anytime a driver is successfully bound to a device.
  */
-static void driver_deferred_probe_trigger(void)
+void driver_deferred_probe_trigger(void)
 {
if (!driver_deferred_probe_enable)
return;
@@ -144,6 +144,7 @@ static void driver_deferred_probe_trigger(void)
 */
queue_work(deferred_wq, _probe_work);
 }
+EXPORT_SYMBOL_GPL(driver_deferred_probe_trigger);

 /**
  * deferred_probe_initcall() - Enable probing of deferred devices
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 5401814..1b13536 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include "base.h"

 #define to_dev(obj) container_of(obj, struct device, kobj)

@@ -593,6 +594,11 @@ request_firmware(const struct firmware
**firmware_p, const char *name,
if (IS_ERR_OR_NULL(fw_priv))
return PTR_RET(fw_priv);

+   /* only defer handling the requests called from probe() */
+   if (!klist_node_attached(>p->knode_driver) &&
+   system_state != SYSTEM_RUNNING)
+   return -EPROBE_DEFER;
+
ret = usermodehelper_read_trylock();
if (WARN_ON(ret)) {
dev_err(device, "firmware: %s will not be loaded\n", name);
diff --git a/include/linux/device.h b/include/linux/device.h
index d0e4d99..a63d3171 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -244,7 +244,7 @@ extern struct device_driver *driver_find(const char *name,
 struct bus_type *bus);
 extern int driver_probe_done(void);
 extern void wait_for_device_probe(void);
-
+extern void driver_deferred_probe_trigger(void);

 /* sysfs interface for exporting driver attributes */

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index e07f5e0..c8d74c6 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -378,6 +378,7 @@ extern enum system_states {
SYSTEM_POWER_OFF,
SYSTEM_RESTART,
SYSTEM_SUSPEND_DISK,
+   SYSTEM_SUSPEND,
 } system_state;

 #define TAINT_PROPRIETARY_MODULE   0
diff --git a/init/main.c b/init/main.c
index e60679d..02fc1c2 100644
--- a/init/main.c
+++ b/init/main.c
@@ -809,6 +809,9 @@ static noinline int init_post(void)
current->signal->flags |= SIGNAL_UNKILLABLE;
flush_delayed_fput();

+   /* defer handling request_firmware in probe of initcall path */
+   driver_deferred_probe_trigger();
+
if (ramdisk_execute_command) {
run_init_process(ramdisk_execute_command);
printk(KERN_WARNING "Failed to execute %s\n",
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 1da39ea..61c723f 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -224,6 +224,9 @@ int suspend_devices_and_enter(suspend_state_t state)
goto Recover_platform;
}
suspend_test_finish("suspend devices");
+
+   system_state = SYSTEM_SUSPEND;
+
if (suspend_test(TEST_DEVICES))
goto Recover_platform;

@@ -301,6 +304,12 @@ static int enter_state(suspend_state_t state)
  Finish:
pr_debug("PM: Finishing wakeup.\n");
suspend_finish();
+
+   system_state = SYSTEM_RUNNING;
+
+   /* defer handling request_firmware in probe of resume path */
+   driver_deferred_probe_trigger();
+
  Unlock:
mutex_unlock(_mutex);
return error;



Thanks,
-- 
Ming Lei
--
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  

Re: sysfs permissions on dynamic attributes (led delay_on and delay_off)

[Greg KH]

On Fri, Jul 20, 2012 at 05:46:14PM -0700, Colin Cross wrote:
> I'm trying to use the standard ledtrig-timer.c code to handle led
> blinking for notifications on an Android device, and I'm hitting some
> issues with setting permissions on the dynamically created delay_on
> and delay_off attributes.  For most sysfs files, we have userspace
> uevent parser that watches for device add notifications and
> chowns/chmods attributes.  This doesn't work for delay_on and
> delay_off, because they are created later, when "timer" is written to
> the trigger attribute.  There is no uevent when the new files are
> created, and sysfs doesn't support inotify, so I don't see any way to
> receive an event to set the permissions.  This issue exists any time
> that device_create_file is called after device_add.
> 
> What is the appropriate way to get an event to set the permissions?
> Add inotify support for sysfs file creation?  Send a KOBJ_CHANGE
> uevent in device_create_file?

No.

> Send a KOBJ_CHANGE uevent from the driver after calling
> device_create_file?

Yes.

> Dynamically create a timer device under /sys/class/leds/ so a new
> add uevent gets sent?

Ick.

> Promote blinking to be a core led feature instead of a trigger, so the
> files are always present?

That's the best thing, why not just do that?

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/

[PATCH 18/19] kprobes: introduce ftrace based optimization

[Steven Rostedt]

From: Masami Hiramatsu 

Introduce function trace based kprobes optimization.

With using ftrace optimization, kprobes on the mcount calling
address, use ftrace's mcount call instead of breakpoint.
Furthermore, this optimization works with preemptive kernel
not like as current jump-based optimization. Of cource,
this feature works only if the probe is on mcount call.

Only if kprobe.break_handler is set, that probe is not
optimized with ftrace (nor put on ftrace). The reason why this
limitation comes is that this break_handler may be used only
from jprobes which changes ip address (for fetching the function
arguments), but function tracer ignores modified ip address.

Changes in v2:
 - Fix ftrace_ops registering right after setting its filter.
 - Unregister ftrace_ops if there is no kprobe using.
 - Remove notrace dependency from __kprobes macro.

Link: 
http://lkml.kernel.org/r/20120605102832.27845.63461.stgit@localhost.localdomain

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Ananth N Mavinakayanahalli 
Cc: "Frank Ch. Eigler" 
Cc: Andrew Morton 
Cc: Frederic Weisbecker 
Signed-off-by: Masami Hiramatsu 
Signed-off-by: Steven Rostedt 
---
 include/linux/kprobes.h |   27 
 kernel/kprobes.c|  105 +--
 2 files changed, 119 insertions(+), 13 deletions(-)

diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
index b6e1f8c..aa0d05e 100644
--- a/include/linux/kprobes.h
+++ b/include/linux/kprobes.h
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_KPROBES
 #include 
@@ -48,14 +49,26 @@
 #define KPROBE_REENTER 0x0004
 #define KPROBE_HIT_SSDONE  0x0008
 
+/*
+ * If function tracer is enabled and the arch supports full
+ * passing of pt_regs to function tracing, then kprobes can
+ * optimize on top of function tracing.
+ */
+#if defined(CONFIG_FUNCTION_TRACER) && defined(ARCH_SUPPORTS_FTRACE_SAVE_REGS) 
\
+   && defined(ARCH_SUPPORTS_KPROBES_ON_FTRACE)
+# define KPROBES_CAN_USE_FTRACE
+#endif
+
 /* Attach to insert probes on any functions which should be ignored*/
 #define __kprobes  __attribute__((__section__(".kprobes.text")))
+
 #else /* CONFIG_KPROBES */
 typedef int kprobe_opcode_t;
 struct arch_specific_insn {
int dummy;
 };
 #define __kprobes
+
 #endif /* CONFIG_KPROBES */
 
 struct kprobe;
@@ -128,6 +141,7 @@ struct kprobe {
   * NOTE:
   * this flag is only for optimized_kprobe.
   */
+#define KPROBE_FLAG_FTRACE 8 /* probe is using ftrace */
 
 /* Has this kprobe gone ? */
 static inline int kprobe_gone(struct kprobe *p)
@@ -146,6 +160,13 @@ static inline int kprobe_optimized(struct kprobe *p)
 {
return p->flags & KPROBE_FLAG_OPTIMIZED;
 }
+
+/* Is this kprobe uses ftrace ? */
+static inline int kprobe_ftrace(struct kprobe *p)
+{
+   return p->flags & KPROBE_FLAG_FTRACE;
+}
+
 /*
  * Special probe type that uses setjmp-longjmp type tricks to resume
  * execution at a specified entry with a matching prototype corresponding
@@ -295,6 +316,12 @@ extern int proc_kprobes_optimization_handler(struct 
ctl_table *table,
 #endif
 
 #endif /* CONFIG_OPTPROBES */
+#ifdef KPROBES_CAN_USE_FTRACE
+extern void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
+ struct pt_regs *regs);
+extern int arch_prepare_kprobe_ftrace(struct kprobe *p);
+#endif
+
 
 /* Get the kprobe at this addr (if any) - called with preemption disabled */
 struct kprobe *get_kprobe(void *addr);
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 9e47f44..69c16ef 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -759,6 +759,10 @@ static __kprobes void try_to_optimize_kprobe(struct kprobe 
*p)
struct kprobe *ap;
struct optimized_kprobe *op;
 
+   /* Impossible to optimize ftrace-based kprobe */
+   if (kprobe_ftrace(p))
+   return;
+
/* For preparing optimization, jump_label_text_reserved() is called */
jump_label_lock();
mutex_lock(_mutex);
@@ -915,9 +919,64 @@ static __kprobes struct kprobe *alloc_aggr_kprobe(struct 
kprobe *p)
 }
 #endif /* CONFIG_OPTPROBES */
 
+#ifdef KPROBES_CAN_USE_FTRACE
+static struct ftrace_ops kprobe_ftrace_ops __read_mostly = {
+   .regs_func = kprobe_ftrace_handler,
+   .flags = FTRACE_OPS_FL_SAVE_REGS,
+};
+static int kprobe_ftrace_enabled;
+
+/* Must ensure p->addr is really on ftrace */
+static int __kprobes prepare_kprobe(struct kprobe *p)
+{
+   if (!kprobe_ftrace(p))
+   return arch_prepare_kprobe(p);
+
+   return arch_prepare_kprobe_ftrace(p);
+}
+
+/* Caller must lock kprobe_mutex */
+static void __kprobes arm_kprobe_ftrace(struct kprobe *p)
+{
+   int ret;
+
+   ret = ftrace_set_filter_ip(_ftrace_ops,
+  (unsigned long)p->addr, 0, 0);
+   WARN(ret < 0, "Failed 

[PATCH 14/19] kprobes: Inverse taking of module_mutex with kprobe_mutex

[Steven Rostedt]

From: Steven Rostedt 

Currently module_mutex is taken before kprobe_mutex, but this
can cause issues when we have kprobes register ftrace, as the ftrace
mutex is taken before enabling a tracepoint, which currently takes
the module mutex.

If module_mutex is taken before kprobe_mutex, then we can not
have kprobes use the ftrace infrastructure.

There seems to be no reason that the kprobe_mutex can't be taken
before the module_mutex. Running lockdep shows that it is safe
among the kernels I've run.

Link: 
http://lkml.kernel.org/r/20120605102814.27845.21047.stgit@localhost.localdomain

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Ananth N Mavinakayanahalli 
Cc: "Frank Ch. Eigler" 
Cc: Andrew Morton 
Cc: Frederic Weisbecker 
Cc: Masami Hiramatsu 
Signed-off-by: Steven Rostedt 
---
 kernel/kprobes.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index c62b854..7a8a122 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -561,9 +561,9 @@ static __kprobes void kprobe_optimizer(struct work_struct 
*work)
 {
LIST_HEAD(free_list);
 
+   mutex_lock(_mutex);
/* Lock modules while optimizing kprobes */
mutex_lock(_mutex);
-   mutex_lock(_mutex);
 
/*
 * Step 1: Unoptimize kprobes and collect cleaned (unused and disarmed)
@@ -586,8 +586,8 @@ static __kprobes void kprobe_optimizer(struct work_struct 
*work)
/* Step 4: Free cleaned kprobes after quiesence period */
do_free_cleaned_kprobes(_list);
 
-   mutex_unlock(_mutex);
mutex_unlock(_mutex);
+   mutex_unlock(_mutex);
 
/* Step 5: Kick optimizer again if needed */
if (!list_empty(_list) || !list_empty(_list))
-- 
1.7.10.4




signature.asc
Description: This is a digitally signed message part

[PATCH 13/19] ftrace: add ftrace_set_filter_ip() for address based filter

[Steven Rostedt]

From: Masami Hiramatsu 

Add a new filter update interface ftrace_set_filter_ip()
to set ftrace filter by ip address, not only glob pattern.

Link: 
http://lkml.kernel.org/r/20120605102808.27845.67952.stgit@localhost.localdomain

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Ananth N Mavinakayanahalli 
Cc: "Frank Ch. Eigler" 
Cc: Andrew Morton 
Cc: Frederic Weisbecker 
Signed-off-by: Masami Hiramatsu 
Signed-off-by: Steven Rostedt 
---
 include/linux/ftrace.h |3 +++
 kernel/trace/ftrace.c  |   59 ++--
 2 files changed, 60 insertions(+), 2 deletions(-)

diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 9962e95..3e71112 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -317,6 +317,8 @@ struct dyn_ftrace {
 };
 
 int ftrace_force_update(void);
+int ftrace_set_filter_ip(struct ftrace_ops *ops, unsigned long ip,
+int remove, int reset);
 int ftrace_set_filter(struct ftrace_ops *ops, unsigned char *buf,
   int len, int reset);
 int ftrace_set_notrace(struct ftrace_ops *ops, unsigned char *buf,
@@ -544,6 +546,7 @@ static inline int ftrace_text_reserved(void *start, void 
*end)
  */
 #define ftrace_regex_open(ops, flag, inod, file) ({ -ENODEV; })
 #define ftrace_set_early_filter(ops, buf, enable) do { } while (0)
+#define ftrace_set_filter_ip(ops, ip, remove, reset) ({ -ENODEV; })
 #define ftrace_set_filter(ops, buf, len, reset) ({ -ENODEV; })
 #define ftrace_set_notrace(ops, buf, len, reset) ({ -ENODEV; })
 #define ftrace_free_filter(ops) do { } while (0)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 528d997..9dcf15d 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3242,8 +3242,27 @@ ftrace_notrace_write(struct file *file, const char 
__user *ubuf,
 }
 
 static int
-ftrace_set_regex(struct ftrace_ops *ops, unsigned char *buf, int len,
-int reset, int enable)
+ftrace_match_addr(struct ftrace_hash *hash, unsigned long ip, int remove)
+{
+   struct ftrace_func_entry *entry;
+
+   if (!ftrace_location(ip))
+   return -EINVAL;
+
+   if (remove) {
+   entry = ftrace_lookup_ip(hash, ip);
+   if (!entry)
+   return -ENOENT;
+   free_hash_entry(hash, entry);
+   return 0;
+   }
+
+   return add_hash_entry(hash, ip);
+}
+
+static int
+ftrace_set_hash(struct ftrace_ops *ops, unsigned char *buf, int len,
+   unsigned long ip, int remove, int reset, int enable)
 {
struct ftrace_hash **orig_hash;
struct ftrace_hash *hash;
@@ -3272,6 +3291,11 @@ ftrace_set_regex(struct ftrace_ops *ops, unsigned char 
*buf, int len,
ret = -EINVAL;
goto out_regex_unlock;
}
+   if (ip) {
+   ret = ftrace_match_addr(hash, ip, remove);
+   if (ret < 0)
+   goto out_regex_unlock;
+   }
 
mutex_lock(_lock);
ret = ftrace_hash_move(ops, enable, orig_hash, hash);
@@ -3288,6 +3312,37 @@ ftrace_set_regex(struct ftrace_ops *ops, unsigned char 
*buf, int len,
return ret;
 }
 
+static int
+ftrace_set_addr(struct ftrace_ops *ops, unsigned long ip, int remove,
+   int reset, int enable)
+{
+   return ftrace_set_hash(ops, 0, 0, ip, remove, reset, enable);
+}
+
+/**
+ * ftrace_set_filter_ip - set a function to filter on in ftrace by address
+ * @ops - the ops to set the filter with
+ * @ip - the address to add to or remove from the filter.
+ * @remove - non zero to remove the ip from the filter
+ * @reset - non zero to reset all filters before applying this filter.
+ *
+ * Filters denote which functions should be enabled when tracing is enabled
+ * If @ip is NULL, it failes to update filter.
+ */
+int ftrace_set_filter_ip(struct ftrace_ops *ops, unsigned long ip,
+int remove, int reset)
+{
+   return ftrace_set_addr(ops, ip, remove, reset, 1);
+}
+EXPORT_SYMBOL_GPL(ftrace_set_filter_ip);
+
+static int
+ftrace_set_regex(struct ftrace_ops *ops, unsigned char *buf, int len,
+int reset, int enable)
+{
+   return ftrace_set_hash(ops, buf, len, 0, 0, reset, enable);
+}
+
 /**
  * ftrace_set_filter - set a function to filter on in ftrace
  * @ops - the ops to set the filter with
-- 
1.7.10.4




signature.asc
Description: This is a digitally signed message part

[PATCH 08/19] ftrace/x86: Remove function_trace_stop check from graph caller

[Steven Rostedt]

From: Steven Rostedt 

The graph caller is called by the mcount callers, which already does
the check against the function_trace_stop variable. No reason to
check it again.

Link: http://lkml.kernel.org/r/20120711195745.588538...@goodmis.org

Signed-off-by: Steven Rostedt 
---
 arch/x86/kernel/entry_32.S |3 ---
 arch/x86/kernel/entry_64.S |3 ---
 2 files changed, 6 deletions(-)

diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 4dc3017..061ac17 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -1241,9 +1241,6 @@ END(mcount)
 
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 ENTRY(ftrace_graph_caller)
-   cmpl $0, function_trace_stop
-   jne ftrace_stub
-
pushl %eax
pushl %ecx
pushl %edx
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 52bda2e..38308fa 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -213,9 +213,6 @@ END(mcount)
 
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 ENTRY(ftrace_graph_caller)
-   cmpl $0, function_trace_stop
-   jne ftrace_stub
-
MCOUNT_SAVE_FRAME
 
leaq 8(%rbp), %rdi
-- 
1.7.10.4




signature.asc
Description: This is a digitally signed message part

[PATCH 17/19] ftrace: Make ftrace_location() a nop on !DYNAMIC_FTRACE

[Steven Rostedt]

From: Steven Rostedt 

When CONFIG_DYNAMIC_FTRACE is not set, ftrace_location() is not defined.
If a user (like kprobes) references this function, it will break
the compile when CONFIG_DYNAMIC_FTRACE is not set.

Add ftrace_location() as a nop (return 0) when DYNAMIC_FTRACE
is not defined.

Link: http://lkml.kernel.org/r/20120612225426.961092...@goodmis.org

Signed-off-by: Steven Rostedt 
---
 include/linux/ftrace.h |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 3e71112..a52f2f4 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -520,7 +520,7 @@ extern int skip_trace(unsigned long ip);
 
 extern void ftrace_disable_daemon(void);
 extern void ftrace_enable_daemon(void);
-#else
+#else /* CONFIG_DYNAMIC_FTRACE */
 static inline int skip_trace(unsigned long ip) { return 0; }
 static inline int ftrace_force_update(void) { return 0; }
 static inline void ftrace_disable_daemon(void) { }
@@ -538,6 +538,10 @@ static inline int ftrace_text_reserved(void *start, void 
*end)
 {
return 0;
 }
+static inline unsigned long ftrace_location(unsigned long ip)
+{
+   return 0;
+}
 
 /*
  * Again users of functions that have ftrace_ops may not
-- 
1.7.10.4




signature.asc
Description: This is a digitally signed message part

[PATCH 07/19] ftrace/x86_32: Simplify parameter setup for ftrace_regs_caller

[Steven Rostedt]

From: Uros Bizjak 

The final position of the stack after saving regs and setting up
the parameters for ftrace_regs_call, is the position of the pt_regs
needed for the 4th parameter. Instead of saving it into a temporary
reg and pushing the reg, simply push the stack pointer.

Link: http://lkml.kernel.org/r/1342702344.12353.16.ca...@gandalf.stny.rr.com

Signed-off-by: Uros Bizjak 
Signed-off-by: Steven Rostedt 
---
 arch/x86/kernel/entry_32.S |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 46caa56..4dc3017 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -1169,10 +1169,9 @@ ENTRY(ftrace_regs_caller)
movl $__KERNEL_CS,13*4(%esp)
 
movl 12*4(%esp), %eax   /* Load ip (1st parameter) */
-   movl 0x4(%ebp), %edx/* Load parent ip (2cd parameter) */
-   lea  (%esp), %ecx
-   pushl %ecx  /* Save pt_regs as 4th parameter */
+   movl 0x4(%ebp), %edx/* Load parent ip (2nd parameter) */
leal function_trace_op, %ecx /* Save ftrace_pos in 3rd parameter */
+   pushl %esp  /* Save pt_regs as 4th parameter */
 
 GLOBAL(ftrace_regs_call)
call ftrace_stub
-- 
1.7.10.4




signature.asc
Description: This is a digitally signed message part

[PATCH 09/19] ftrace: Add default recursion protection for function tracing

[Steven Rostedt]

From: Steven Rostedt 

As more users of the function tracer utility are being added, they do
not always add the necessary recursion protection. To protect from
function recursion due to tracing, if the callback ftrace_ops does not
specifically specify that it protects against recursion (by setting
the FTRACE_OPS_FL_RECURSION_SAFE flag), the list operation will be
called by the mcount trampoline which adds recursion protection.

If the flag is set, then the function will be called directly with no
extra protection.

Note, the list operation is called if more than one function callback
is registered, or if the arch does not support all of the function
tracer features.

Signed-off-by: Steven Rostedt 
---
 include/linux/ftrace.h|5 +
 kernel/trace/ftrace.c |   10 --
 kernel/trace/trace_events.c   |1 +
 kernel/trace/trace_functions.c|4 ++--
 kernel/trace/trace_irqsoff.c  |2 +-
 kernel/trace/trace_sched_wakeup.c |2 +-
 kernel/trace/trace_selftest.c |7 +--
 kernel/trace/trace_stack.c|1 +
 8 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index ab39990..65a14e4 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -85,6 +85,10 @@ typedef void (*ftrace_func_t)(unsigned long ip, unsigned 
long parent_ip,
  *passing regs to the handler.
  *Note, if this flag is set, the SAVE_REGS flag will automatically
  *get set upon registering the ftrace_ops, if the arch supports it.
+ * RECURSION_SAFE - The ftrace_ops can set this to tell the ftrace 
infrastructure
+ *that the call back has its own recursion protection. If it does
+ *not set this, then the ftrace infrastructure will add recursion
+ *protection for the caller.
  */
 enum {
FTRACE_OPS_FL_ENABLED   = 1 << 0,
@@ -93,6 +97,7 @@ enum {
FTRACE_OPS_FL_CONTROL   = 1 << 3,
FTRACE_OPS_FL_SAVE_REGS = 1 << 4,
FTRACE_OPS_FL_SAVE_REGS_IF_SUPPORTED= 1 << 5,
+   FTRACE_OPS_FL_RECURSION_SAFE= 1 << 6,
 };
 
 struct ftrace_ops {
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index c55f7e2..ad765b4 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -66,6 +66,7 @@
 
 static struct ftrace_ops ftrace_list_end __read_mostly = {
.func   = ftrace_stub,
+   .flags  = FTRACE_OPS_FL_RECURSION_SAFE,
 };
 
 /* ftrace_enabled is a method to turn ftrace on or off */
@@ -221,12 +222,13 @@ static void update_ftrace_function(void)
 
/*
 * If we are at the end of the list and this ops is
-* not dynamic and the arch supports passing ops, then have the
-* mcount trampoline call the function directly.
+* recursion safe and not dynamic and the arch supports passing ops,
+* then have the mcount trampoline call the function directly.
 */
if (ftrace_ops_list == _list_end ||
(ftrace_ops_list->next == _list_end &&
 !(ftrace_ops_list->flags & FTRACE_OPS_FL_DYNAMIC) &&
+(ftrace_ops_list->flags & FTRACE_OPS_FL_RECURSION_SAFE) &&
 !FTRACE_FORCE_LIST_FUNC)) {
/* Set the ftrace_ops that the arch callback uses */
if (ftrace_ops_list == _ops)
@@ -867,6 +869,7 @@ static void unregister_ftrace_profiler(void)
 #else
 static struct ftrace_ops ftrace_profile_ops __read_mostly = {
.func   = function_profile_call,
+   .flags  = FTRACE_OPS_FL_RECURSION_SAFE,
 };
 
 static int register_ftrace_profiler(void)
@@ -1049,6 +1052,7 @@ static struct ftrace_ops global_ops = {
.func   = ftrace_stub,
.notrace_hash   = EMPTY_HASH,
.filter_hash= EMPTY_HASH,
+   .flags  = FTRACE_OPS_FL_RECURSION_SAFE,
 };
 
 static DEFINE_MUTEX(ftrace_regex_lock);
@@ -3967,6 +3971,7 @@ void __init ftrace_init(void)
 
 static struct ftrace_ops global_ops = {
.func   = ftrace_stub,
+   .flags  = FTRACE_OPS_FL_RECURSION_SAFE,
 };
 
 static int __init ftrace_nodyn_init(void)
@@ -4023,6 +4028,7 @@ ftrace_ops_control_func(unsigned long ip, unsigned long 
parent_ip,
 
 static struct ftrace_ops control_ops = {
.func = ftrace_ops_control_func,
+   .flags = FTRACE_OPS_FL_RECURSION_SAFE,
 };
 
 static inline void
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 8c66968..6825d83 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -1721,6 +1721,7 @@ function_test_events_call(unsigned long ip, unsigned long 
parent_ip,
 static struct ftrace_ops trace_ops __initdata  =
 {
.func = function_test_events_call,
+   .flags = FTRACE_OPS_FL_RECURSION_SAFE,
 };
 
 static __init void event_trace_self_test_with_function(void)

[PATCH 12/19] ftrace: Add selftest to test function save-regs support

[Steven Rostedt]

From: Steven Rostedt 

Add selftests to test the save-regs functionality of ftrace.

If the arch supports saving regs, then it will make sure that regs is
at least not NULL in the callback.

If the arch does not support saving regs, it makes sure that the
registering of the ftrace_ops that requests saving regs fails.
It then tests the registering of the ftrace_ops succeeds if the
'IF_SUPPORTED' flag is set. Then it makes sure that the regs passed to
the function is NULL.

Signed-off-by: Steven Rostedt 
---
 kernel/trace/trace.h  |2 +-
 kernel/trace/trace_selftest.c |  114 +
 2 files changed, 115 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 55e1f7f..593debe 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -472,11 +472,11 @@ extern void trace_find_cmdline(int pid, char comm[]);
 
 #ifdef CONFIG_DYNAMIC_FTRACE
 extern unsigned long ftrace_update_tot_cnt;
+#endif
 #define DYN_FTRACE_TEST_NAME trace_selftest_dynamic_test_func
 extern int DYN_FTRACE_TEST_NAME(void);
 #define DYN_FTRACE_TEST_NAME2 trace_selftest_dynamic_test_func2
 extern int DYN_FTRACE_TEST_NAME2(void);
-#endif
 
 extern int ring_buffer_expanded;
 extern bool tracing_selftest_disabled;
diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
index 86422f9..1003a4d 100644
--- a/kernel/trace/trace_selftest.c
+++ b/kernel/trace/trace_selftest.c
@@ -543,6 +543,116 @@ out:
 # define trace_selftest_function_recursion() ({ 0; })
 #endif /* CONFIG_DYNAMIC_FTRACE */
 
+static enum {
+   TRACE_SELFTEST_REGS_START,
+   TRACE_SELFTEST_REGS_FOUND,
+   TRACE_SELFTEST_REGS_NOT_FOUND,
+} trace_selftest_regs_stat;
+
+static void trace_selftest_test_regs_func(unsigned long ip,
+ unsigned long pip,
+ struct ftrace_ops *op,
+ struct pt_regs *pt_regs)
+{
+   if (pt_regs)
+   trace_selftest_regs_stat = TRACE_SELFTEST_REGS_FOUND;
+   else
+   trace_selftest_regs_stat = TRACE_SELFTEST_REGS_NOT_FOUND;
+}
+
+static struct ftrace_ops test_regs_probe = {
+   .func   = trace_selftest_test_regs_func,
+   .flags  = FTRACE_OPS_FL_RECURSION_SAFE | 
FTRACE_OPS_FL_SAVE_REGS,
+};
+
+static int
+trace_selftest_function_regs(void)
+{
+   int save_ftrace_enabled = ftrace_enabled;
+   int save_tracer_enabled = tracer_enabled;
+   char *func_name;
+   int len;
+   int ret;
+   int supported = 0;
+
+#ifdef ARCH_SUPPORTS_FTRACE_SAVE_REGS
+   supported = 1;
+#endif
+
+   /* The previous test PASSED */
+   pr_cont("PASSED\n");
+   pr_info("Testing ftrace regs%s: ",
+   !supported ? "(no arch support)" : "");
+
+   /* enable tracing, and record the filter function */
+   ftrace_enabled = 1;
+   tracer_enabled = 1;
+
+   /* Handle PPC64 '.' name */
+   func_name = "*" __stringify(DYN_FTRACE_TEST_NAME);
+   len = strlen(func_name);
+
+   ret = ftrace_set_filter(_regs_probe, func_name, len, 1);
+   /*
+* If DYNAMIC_FTRACE is not set, then we just trace all functions.
+* This test really doesn't care.
+*/
+   if (ret && ret != -ENODEV) {
+   pr_cont("*Could not set filter* ");
+   goto out;
+   }
+
+   ret = register_ftrace_function(_regs_probe);
+   /*
+* Now if the arch does not support passing regs, then this should
+* have failed.
+*/
+   if (!supported) {
+   if (!ret) {
+   pr_cont("*registered save-regs without arch support* ");
+   goto out;
+   }
+   test_regs_probe.flags |= FTRACE_OPS_FL_SAVE_REGS_IF_SUPPORTED;
+   ret = register_ftrace_function(_regs_probe);
+   }
+   if (ret) {
+   pr_cont("*could not register callback* ");
+   goto out;
+   }
+
+
+   DYN_FTRACE_TEST_NAME();
+
+   unregister_ftrace_function(_regs_probe);
+
+   ret = -1;
+
+   switch (trace_selftest_regs_stat) {
+   case TRACE_SELFTEST_REGS_START:
+   pr_cont("*callback never called* ");
+   goto out;
+
+   case TRACE_SELFTEST_REGS_FOUND:
+   if (supported)
+   break;
+   pr_cont("*callback received regs without arch support* ");
+   goto out;
+
+   case TRACE_SELFTEST_REGS_NOT_FOUND:
+   if (!supported)
+   break;
+   pr_cont("*callback received NULL regs* ");
+   goto out;
+   }
+
+   ret = 0;
+out:
+   ftrace_enabled = save_ftrace_enabled;
+   tracer_enabled = save_tracer_enabled;
+
+   return ret;
+}
+
 /*
  * Simple verification test of ftrace function tracer.
  * Enable ftrace, sleep 1/10 second, and then read the trace

[PATCH 10/19] ftrace: Only compile ftrace selftest if selftests are enabled

[Steven Rostedt]

From: Steven Rostedt 

No need to compile in the ftrace selftest helper file if selftests are
not being executed.

Signed-off-by: Steven Rostedt 
---
 kernel/trace/Makefile |2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
index b831087..8370908 100644
--- a/kernel/trace/Makefile
+++ b/kernel/trace/Makefile
@@ -5,10 +5,12 @@ ifdef CONFIG_FUNCTION_TRACER
 ORIG_CFLAGS := $(KBUILD_CFLAGS)
 KBUILD_CFLAGS = $(subst -pg,,$(ORIG_CFLAGS))
 
+ifdef CONFIG_FTRACE_SELFTEST
 # selftest needs instrumentation
 CFLAGS_trace_selftest_dynamic.o = -pg
 obj-y += trace_selftest_dynamic.o
 endif
+endif
 
 # If unlikely tracing is enabled, do not trace these files
 ifdef CONFIG_TRACING_BRANCHES
-- 
1.7.10.4




signature.asc
Description: This is a digitally signed message part

[PATCH 16/19] kprobes: Move locks into appropriate functions

[Steven Rostedt]

From: Masami Hiramatsu 

Break a big critical region into fine-grained pieces at
registering kprobe path. This helps us to solve circular
locking dependency when introducing ftrace-based kprobes.

Link: 
http://lkml.kernel.org/r/20120605102826.27845.81689.stgit@localhost.localdomain

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Ananth N Mavinakayanahalli 
Cc: "Frank Ch. Eigler" 
Cc: Andrew Morton 
Cc: Frederic Weisbecker 
Signed-off-by: Masami Hiramatsu 
Signed-off-by: Steven Rostedt 
---
 kernel/kprobes.c |   63 --
 1 file changed, 42 insertions(+), 21 deletions(-)

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 6137fe3..9e47f44 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -759,20 +759,28 @@ static __kprobes void try_to_optimize_kprobe(struct 
kprobe *p)
struct kprobe *ap;
struct optimized_kprobe *op;
 
+   /* For preparing optimization, jump_label_text_reserved() is called */
+   jump_label_lock();
+   mutex_lock(_mutex);
+
ap = alloc_aggr_kprobe(p);
if (!ap)
-   return;
+   goto out;
 
op = container_of(ap, struct optimized_kprobe, kp);
if (!arch_prepared_optinsn(>optinsn)) {
/* If failed to setup optimizing, fallback to kprobe */
arch_remove_optimized_kprobe(op);
kfree(op);
-   return;
+   goto out;
}
 
init_aggr_kprobe(ap, p);
-   optimize_kprobe(ap);
+   optimize_kprobe(ap);/* This just kicks optimizer thread */
+
+out:
+   mutex_unlock(_mutex);
+   jump_label_unlock();
 }
 
 #ifdef CONFIG_SYSCTL
@@ -1144,12 +1152,6 @@ static int __kprobes add_new_kprobe(struct kprobe *ap, 
struct kprobe *p)
if (p->post_handler && !ap->post_handler)
ap->post_handler = aggr_post_handler;
 
-   if (kprobe_disabled(ap) && !kprobe_disabled(p)) {
-   ap->flags &= ~KPROBE_FLAG_DISABLED;
-   if (!kprobes_all_disarmed)
-   /* Arm the breakpoint again. */
-   __arm_kprobe(ap);
-   }
return 0;
 }
 
@@ -1189,11 +1191,22 @@ static int __kprobes register_aggr_kprobe(struct kprobe 
*orig_p,
int ret = 0;
struct kprobe *ap = orig_p;
 
+   /* For preparing optimization, jump_label_text_reserved() is called */
+   jump_label_lock();
+   /*
+* Get online CPUs to avoid text_mutex deadlock.with stop machine,
+* which is invoked by unoptimize_kprobe() in add_new_kprobe()
+*/
+   get_online_cpus();
+   mutex_lock(_mutex);
+
if (!kprobe_aggrprobe(orig_p)) {
/* If orig_p is not an aggr_kprobe, create new aggr_kprobe. */
ap = alloc_aggr_kprobe(orig_p);
-   if (!ap)
-   return -ENOMEM;
+   if (!ap) {
+   ret = -ENOMEM;
+   goto out;
+   }
init_aggr_kprobe(ap, orig_p);
} else if (kprobe_unused(ap))
/* This probe is going to die. Rescue it */
@@ -1213,7 +1226,7 @@ static int __kprobes register_aggr_kprobe(struct kprobe 
*orig_p,
 * free aggr_probe. It will be used next time, or
 * freed by unregister_kprobe.
 */
-   return ret;
+   goto out;
 
/* Prepare optimized instructions if possible. */
prepare_optimized_kprobe(ap);
@@ -1228,7 +1241,20 @@ static int __kprobes register_aggr_kprobe(struct kprobe 
*orig_p,
 
/* Copy ap's insn slot to p */
copy_kprobe(ap, p);
-   return add_new_kprobe(ap, p);
+   ret = add_new_kprobe(ap, p);
+
+out:
+   mutex_unlock(_mutex);
+   put_online_cpus();
+   jump_label_unlock();
+
+   if (ret == 0 && kprobe_disabled(ap) && !kprobe_disabled(p)) {
+   ap->flags &= ~KPROBE_FLAG_DISABLED;
+   if (!kprobes_all_disarmed)
+   /* Arm the breakpoint again. */
+   arm_kprobe(ap);
+   }
+   return ret;
 }
 
 static int __kprobes in_kprobes_functions(unsigned long addr)
@@ -1387,10 +1413,6 @@ int __kprobes register_kprobe(struct kprobe *p)
return ret;
 
mutex_lock(_mutex);
-   jump_label_lock(); /* needed to call jump_label_text_reserved() */
-
-   get_online_cpus();  /* For avoiding text_mutex deadlock. */
-   mutex_lock(_mutex);
 
old_p = get_kprobe(p->addr);
if (old_p) {
@@ -1399,7 +1421,9 @@ int __kprobes register_kprobe(struct kprobe *p)
goto out;
}
 
+   mutex_lock(_mutex);/* Avoiding text modification */
ret = arch_prepare_kprobe(p);
+   mutex_unlock(_mutex);
if (ret)
goto out;
 
@@ -1408,15 +1432,12 @@ int __kprobes 

[PATCH 15/19] kprobes: cleanup to separate probe-able check

[Steven Rostedt]

From: Masami Hiramatsu 

Separate probe-able address checking code from
register_kprobe().

Link: 
http://lkml.kernel.org/r/20120605102820.27845.90133.stgit@localhost.localdomain

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Ananth N Mavinakayanahalli 
Cc: "Frank Ch. Eigler" 
Cc: Andrew Morton 
Cc: Frederic Weisbecker 
Signed-off-by: Masami Hiramatsu 
Signed-off-by: Steven Rostedt 
---
 kernel/kprobes.c |   82 ++
 1 file changed, 45 insertions(+), 37 deletions(-)

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 7a8a122..6137fe3 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1313,67 +1313,80 @@ static inline int check_kprobe_rereg(struct kprobe *p)
return ret;
 }
 
-int __kprobes register_kprobe(struct kprobe *p)
+static __kprobes int check_kprobe_address_safe(struct kprobe *p,
+  struct module **probed_mod)
 {
int ret = 0;
-   struct kprobe *old_p;
-   struct module *probed_mod;
-   kprobe_opcode_t *addr;
-
-   addr = kprobe_addr(p);
-   if (IS_ERR(addr))
-   return PTR_ERR(addr);
-   p->addr = addr;
-
-   ret = check_kprobe_rereg(p);
-   if (ret)
-   return ret;
 
jump_label_lock();
preempt_disable();
+
+   /* Ensure it is not in reserved area nor out of text */
if (!kernel_text_address((unsigned long) p->addr) ||
in_kprobes_functions((unsigned long) p->addr) ||
ftrace_text_reserved(p->addr, p->addr) ||
jump_label_text_reserved(p->addr, p->addr)) {
ret = -EINVAL;
-   goto cannot_probe;
+   goto out;
}
 
-   /* User can pass only KPROBE_FLAG_DISABLED to register_kprobe */
-   p->flags &= KPROBE_FLAG_DISABLED;
-
-   /*
-* Check if are we probing a module.
-*/
-   probed_mod = __module_text_address((unsigned long) p->addr);
-   if (probed_mod) {
-   /* Return -ENOENT if fail. */
-   ret = -ENOENT;
+   /* Check if are we probing a module */
+   *probed_mod = __module_text_address((unsigned long) p->addr);
+   if (*probed_mod) {
/*
 * We must hold a refcount of the probed module while updating
 * its code to prohibit unexpected unloading.
 */
-   if (unlikely(!try_module_get(probed_mod)))
-   goto cannot_probe;
+   if (unlikely(!try_module_get(*probed_mod))) {
+   ret = -ENOENT;
+   goto out;
+   }
 
/*
 * If the module freed .init.text, we couldn't insert
 * kprobes in there.
 */
-   if (within_module_init((unsigned long)p->addr, probed_mod) &&
-   probed_mod->state != MODULE_STATE_COMING) {
-   module_put(probed_mod);
-   goto cannot_probe;
+   if (within_module_init((unsigned long)p->addr, *probed_mod) &&
+   (*probed_mod)->state != MODULE_STATE_COMING) {
+   module_put(*probed_mod);
+   *probed_mod = NULL;
+   ret = -ENOENT;
}
-   /* ret will be updated by following code */
}
+out:
preempt_enable();
jump_label_unlock();
 
+   return ret;
+}
+
+int __kprobes register_kprobe(struct kprobe *p)
+{
+   int ret;
+   struct kprobe *old_p;
+   struct module *probed_mod;
+   kprobe_opcode_t *addr;
+
+   /* Adjust probe address from symbol */
+   addr = kprobe_addr(p);
+   if (IS_ERR(addr))
+   return PTR_ERR(addr);
+   p->addr = addr;
+
+   ret = check_kprobe_rereg(p);
+   if (ret)
+   return ret;
+
+   /* User can pass only KPROBE_FLAG_DISABLED to register_kprobe */
+   p->flags &= KPROBE_FLAG_DISABLED;
p->nmissed = 0;
INIT_LIST_HEAD(>list);
-   mutex_lock(_mutex);
 
+   ret = check_kprobe_address_safe(p, _mod);
+   if (ret)
+   return ret;
+
+   mutex_lock(_mutex);
jump_label_lock(); /* needed to call jump_label_text_reserved() */
 
get_online_cpus();  /* For avoiding text_mutex deadlock. */
@@ -1410,11 +1423,6 @@ out:
module_put(probed_mod);
 
return ret;
-
-cannot_probe:
-   preempt_enable();
-   jump_label_unlock();
-   return ret;
 }
 EXPORT_SYMBOL_GPL(register_kprobe);
 
-- 
1.7.10.4




signature.asc
Description: This is a digitally signed message part

[PATCH 06/19] ftrace/x86: Add save_regs for i386 function calls

[Steven Rostedt]

From: Steven Rostedt 

Add saving full regs for function tracing on i386.
The saving of regs was influenced by patches sent out by
Masami Hiramatsu.

Link: Link: http://lkml.kernel.org/r/20120711195745.379060...@goodmis.org

Reviewed-by: Masami Hiramatsu 
Signed-off-by: Steven Rostedt 
---
 arch/x86/include/asm/ftrace.h |2 --
 arch/x86/kernel/entry_32.S|   68 +
 arch/x86/kernel/ftrace.c  |4 ---
 3 files changed, 68 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index a847501..a6cae0c 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -40,10 +40,8 @@
 
 #ifdef CONFIG_DYNAMIC_FTRACE
 #define ARCH_SUPPORTS_FTRACE_OPS 1
-#ifdef CONFIG_X86_64
 #define ARCH_SUPPORTS_FTRACE_SAVE_REGS
 #endif
-#endif
 
 #ifndef __ASSEMBLY__
 extern void mcount(void);
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 5da11d1..46caa56 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -1123,6 +1123,7 @@ ftrace_call:
popl %edx
popl %ecx
popl %eax
+ftrace_ret:
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 .globl ftrace_graph_call
 ftrace_graph_call:
@@ -1134,6 +1135,73 @@ ftrace_stub:
ret
 END(ftrace_caller)
 
+ENTRY(ftrace_regs_caller)
+   pushf   /* push flags before compare (in cs location) */
+   cmpl $0, function_trace_stop
+   jne ftrace_restore_flags
+
+   /*
+* i386 does not save SS and ESP when coming from kernel.
+* Instead, to get sp, >sp is used (see ptrace.h).
+* Unfortunately, that means eflags must be at the same location
+* as the current return ip is. We move the return ip into the
+* ip location, and move flags into the return ip location.
+*/
+   pushl 4(%esp)   /* save return ip into ip slot */
+   subl $MCOUNT_INSN_SIZE, (%esp)  /* Adjust ip */
+
+   pushl $0/* Load 0 into orig_ax */
+   pushl %gs
+   pushl %fs
+   pushl %es
+   pushl %ds
+   pushl %eax
+   pushl %ebp
+   pushl %edi
+   pushl %esi
+   pushl %edx
+   pushl %ecx
+   pushl %ebx
+
+   movl 13*4(%esp), %eax   /* Get the saved flags */
+   movl %eax, 14*4(%esp)   /* Move saved flags into regs->flags location */
+   /* clobbering return ip */
+   movl $__KERNEL_CS,13*4(%esp)
+
+   movl 12*4(%esp), %eax   /* Load ip (1st parameter) */
+   movl 0x4(%ebp), %edx/* Load parent ip (2cd parameter) */
+   lea  (%esp), %ecx
+   pushl %ecx  /* Save pt_regs as 4th parameter */
+   leal function_trace_op, %ecx /* Save ftrace_pos in 3rd parameter */
+
+GLOBAL(ftrace_regs_call)
+   call ftrace_stub
+
+   addl $4, %esp   /* Skip pt_regs */
+   movl 14*4(%esp), %eax   /* Move flags back into cs */
+   movl %eax, 13*4(%esp)   /* Needed to keep addl from modifying flags */
+   movl 12*4(%esp), %eax   /* Get return ip from regs->ip */
+   addl $MCOUNT_INSN_SIZE, %eax
+   movl %eax, 14*4(%esp)   /* Put return ip back for ret */
+
+   popl %ebx
+   popl %ecx
+   popl %edx
+   popl %esi
+   popl %edi
+   popl %ebp
+   popl %eax
+   popl %ds
+   popl %es
+   popl %fs
+   popl %gs
+   addl $8, %esp   /* Skip orig_ax and ip */
+   popf/* Pop flags at end (no addl to corrupt flags) 
*/
+   jmp ftrace_ret
+
+ftrace_restore_flags:
+   popf
+   jmp  ftrace_stub
 #else /* ! CONFIG_DYNAMIC_FTRACE */
 
 ENTRY(mcount)
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index b90eb1a..1d41402 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -206,7 +206,6 @@ static int
 ftrace_modify_code(unsigned long ip, unsigned const char *old_code,
   unsigned const char *new_code);
 
-#ifdef ARCH_SUPPORTS_FTRACE_SAVE_REGS
 /*
  * Should never be called:
  *  As it is only called by __ftrace_replace_code() which is called by
@@ -221,7 +220,6 @@ int ftrace_modify_call(struct dyn_ftrace *rec, unsigned 
long old_addr,
WARN_ON(1);
return -EINVAL;
 }
-#endif
 
 int ftrace_update_ftrace_func(ftrace_func_t func)
 {
@@ -237,7 +235,6 @@ int ftrace_update_ftrace_func(ftrace_func_t func)
 
ret = ftrace_modify_code(ip, old, new);
 
-#ifdef ARCH_SUPPORTS_FTRACE_SAVE_REGS
/* Also update the regs callback function */
if (!ret) {
ip = (unsigned long)(_regs_call);
@@ -245,7 +242,6 @@ int ftrace_update_ftrace_func(ftrace_func_t func)
new = ftrace_call_replace(ip, (unsigned long)func);
ret = ftrace_modify_code(ip, old, new);
}
-#endif
 
atomic_dec(_ftrace_code);
 
-- 
1.7.10.4




signature.asc
Description: This is a digitally signed message part

[PATCH 04/19] ftrace/x86_32: Push ftrace_ops in as 3rd parameter to function tracer

[Steven Rostedt]

From: Steven Rostedt 

Add support of passing the current ftrace_ops into the 3rd parameter
of the callback to the function tracer.

Link: http://lkml.kernel.org/r/20120612225424.942411...@goodmis.org

Reviewed-by: Masami Hiramatsu 
Signed-off-by: Steven Rostedt 
---
 arch/x86/include/asm/ftrace.h |2 +-
 arch/x86/kernel/entry_32.S|1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index 783b107..b3bb1f3 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -32,7 +32,7 @@
 #define MCOUNT_ADDR((long)(mcount))
 #define MCOUNT_INSN_SIZE   5 /* sizeof mcount call */
 
-#if defined(CONFIG_DYNAMIC_FTRACE) && defined(CONFIG_X86_64)
+#ifdef CONFIG_DYNAMIC_FTRACE
 #define ARCH_SUPPORTS_FTRACE_OPS 1
 #endif
 
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 623f288..e3e17a0 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -,6 +,7 @@ ENTRY(ftrace_caller)
pushl %edx
movl 0xc(%esp), %eax
movl 0x4(%ebp), %edx
+   leal function_trace_op, %ecx
subl $MCOUNT_INSN_SIZE, %eax
 
 .globl ftrace_call
-- 
1.7.10.4




signature.asc
Description: This is a digitally signed message part

[PATCH 11/19] ftrace: Add selftest to test function trace recursion protection

[Steven Rostedt]

From: Steven Rostedt 

Add selftests to test the function tracing recursion protection actually
does work. It also tests if a ftrace_ops states it will perform its own
protection. Although, even if the ftrace_ops states it will protect itself,
the ftrace infrastructure may still provide protection if the arch does
not support all features or another ftrace_ops is registered.

Signed-off-by: Steven Rostedt 
---
 include/linux/ftrace.h|6 ++
 kernel/trace/ftrace.c |   21 +++
 kernel/trace/trace_selftest.c |  136 +
 3 files changed, 163 insertions(+)

diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 65a14e4..9962e95 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -220,6 +220,10 @@ extern void ftrace_stub(unsigned long a0, unsigned long a1,
  */
 #define register_ftrace_function(ops) ({ 0; })
 #define unregister_ftrace_function(ops) ({ 0; })
+static inline int ftrace_nr_registered_ops(void)
+{
+   return 0;
+}
 static inline void clear_ftrace_function(void) { }
 static inline void ftrace_kill(void) { }
 static inline void ftrace_stop(void) { }
@@ -275,6 +279,8 @@ extern void unregister_ftrace_function_probe_all(char 
*glob);
 
 extern int ftrace_text_reserved(void *start, void *end);
 
+extern int ftrace_nr_registered_ops(void);
+
 /*
  * The dyn_ftrace record's flags field is split into two parts.
  * the first part which is '0-FTRACE_REF_MAX' is a counter of
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index ad765b4..528d997 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -111,6 +111,27 @@ static void ftrace_ops_no_ops(unsigned long ip, unsigned 
long parent_ip);
 #define ftrace_ops_list_func ((ftrace_func_t)ftrace_ops_no_ops)
 #endif
 
+/**
+ * ftrace_nr_registered_ops - return number of ops registered
+ *
+ * Returns the number of ftrace_ops registered and tracing functions
+ */
+int ftrace_nr_registered_ops(void)
+{
+   struct ftrace_ops *ops;
+   int cnt = 0;
+
+   mutex_lock(_lock);
+
+   for (ops = ftrace_ops_list;
+ops != _list_end; ops = ops->next)
+   cnt++;
+
+   mutex_unlock(_lock);
+
+   return cnt;
+}
+
 /*
  * Traverse the ftrace_global_list, invoking all entries.  The reason that we
  * can use rcu_dereference_raw() is that elements removed from this list
diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
index 1fb6da8..86422f9 100644
--- a/kernel/trace/trace_selftest.c
+++ b/kernel/trace/trace_selftest.c
@@ -406,8 +406,141 @@ int trace_selftest_startup_dynamic_tracing(struct tracer 
*trace,
 
return ret;
 }
+
+static int trace_selftest_recursion_cnt;
+static void trace_selftest_test_recursion_func(unsigned long ip,
+  unsigned long pip,
+  struct ftrace_ops *op,
+  struct pt_regs *pt_regs)
+{
+   /*
+* This function is registered without the recursion safe flag.
+* The ftrace infrastructure should provide the recursion
+* protection. If not, this will crash the kernel!
+*/
+   trace_selftest_recursion_cnt++;
+   DYN_FTRACE_TEST_NAME();
+}
+
+static void trace_selftest_test_recursion_safe_func(unsigned long ip,
+   unsigned long pip,
+   struct ftrace_ops *op,
+   struct pt_regs *pt_regs)
+{
+   /*
+* We said we would provide our own recursion. By calling
+* this function again, we should recurse back into this function
+* and count again. But this only happens if the arch supports
+* all of ftrace features and nothing else is using the function
+* tracing utility.
+*/
+   if (trace_selftest_recursion_cnt++)
+   return;
+   DYN_FTRACE_TEST_NAME();
+}
+
+static struct ftrace_ops test_rec_probe = {
+   .func   = trace_selftest_test_recursion_func,
+};
+
+static struct ftrace_ops test_recsafe_probe = {
+   .func   = trace_selftest_test_recursion_safe_func,
+   .flags  = FTRACE_OPS_FL_RECURSION_SAFE,
+};
+
+static int
+trace_selftest_function_recursion(void)
+{
+   int save_ftrace_enabled = ftrace_enabled;
+   int save_tracer_enabled = tracer_enabled;
+   char *func_name;
+   int len;
+   int ret;
+   int cnt;
+
+   /* The previous test PASSED */
+   pr_cont("PASSED\n");
+   pr_info("Testing ftrace recursion: ");
+
+
+   /* enable tracing, and record the filter function */
+   ftrace_enabled = 1;
+   tracer_enabled = 1;
+
+   /* Handle PPC64 '.' name */
+   func_name = "*" __stringify(DYN_FTRACE_TEST_NAME);
+   len = strlen(func_name);
+
+   ret = ftrace_set_filter(_rec_probe, 

[PATCH 02/19] ftrace: Consolidate arch dependent functions with list function

[Steven Rostedt]

From: Steven Rostedt 

As the function tracer starts to get more features, the support for
theses features will spread out throughout the different architectures
over time. These features boil down to what each arch does in the
mcount trampoline (the ftrace_caller).

Currently there's two features that are not the same throughout the
archs.

 1) Support to stop function tracing before the callback
 2) passing of the ftrace ops

Both of these require placing an indirect function to support the
features if the mcount trampoline does not.

On a side note, for all architectures, when more than one callback
is registered to the function tracer, an intermediate 'list' function
is called by the mcount trampoline to iterate through the callbacks
that are registered.

Instead of making a separate function for each of these features,
and requiring several indirect calls, just use the single 'list' function
as the intermediate, to handle all cases. If an arch does not support
the 'stop function tracing' or the passing of ftrace ops, just force
it to use the list function that will handle the features required.

This makes the code cleaner and simpler and removes a lot of
 #ifdefs in the code.

Link: http://lkml.kernel.org/r/20120612225424.495625...@goodmis.org

Reviewed-by: Masami Hiramatsu 
Signed-off-by: Steven Rostedt 
---
 include/linux/ftrace.h |   13 +
 kernel/trace/ftrace.c  |   45 -
 2 files changed, 17 insertions(+), 41 deletions(-)

diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 2d59641..3651fdc 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -27,6 +27,19 @@
 #define ARCH_SUPPORTS_FTRACE_OPS 0
 #endif
 
+/*
+ * If the arch's mcount caller does not support all of ftrace's
+ * features, then it must call an indirect function that
+ * does. Or at least does enough to prevent any unwelcomed side effects.
+ */
+#if !defined(CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST) || \
+   !ARCH_SUPPORTS_FTRACE_OPS
+# define FTRACE_FORCE_LIST_FUNC 1
+#else
+# define FTRACE_FORCE_LIST_FUNC 0
+#endif
+
+
 struct module;
 struct ftrace_hash;
 
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 4f2ab93..4cbca2e 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -97,8 +97,6 @@ static struct ftrace_ops *ftrace_global_list __read_mostly = 
_list_end;
 static struct ftrace_ops *ftrace_control_list __read_mostly = _list_end;
 static struct ftrace_ops *ftrace_ops_list __read_mostly = _list_end;
 ftrace_func_t ftrace_trace_function __read_mostly = ftrace_stub;
-static ftrace_func_t __ftrace_trace_function_delay __read_mostly = ftrace_stub;
-ftrace_func_t __ftrace_trace_function __read_mostly = ftrace_stub;
 ftrace_func_t ftrace_pid_function __read_mostly = ftrace_stub;
 static struct ftrace_ops global_ops;
 static struct ftrace_ops control_ops;
@@ -162,26 +160,9 @@ static void set_ftrace_pid_function(ftrace_func_t func)
 void clear_ftrace_function(void)
 {
ftrace_trace_function = ftrace_stub;
-   __ftrace_trace_function = ftrace_stub;
-   __ftrace_trace_function_delay = ftrace_stub;
ftrace_pid_function = ftrace_stub;
 }
 
-#ifndef CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST
-/*
- * For those archs that do not test ftrace_trace_stop in their
- * mcount call site, we need to do it from C.
- */
-static void ftrace_test_stop_func(unsigned long ip, unsigned long parent_ip,
- struct ftrace_ops *op)
-{
-   if (function_trace_stop)
-   return;
-
-   __ftrace_trace_function(ip, parent_ip, op);
-}
-#endif
-
 static void control_ops_disable_all(struct ftrace_ops *ops)
 {
int cpu;
@@ -246,7 +227,7 @@ static void update_ftrace_function(void)
if (ftrace_ops_list == _list_end ||
(ftrace_ops_list->next == _list_end &&
 !(ftrace_ops_list->flags & FTRACE_OPS_FL_DYNAMIC) &&
-ARCH_SUPPORTS_FTRACE_OPS)) {
+!FTRACE_FORCE_LIST_FUNC)) {
/* Set the ftrace_ops that the arch callback uses */
if (ftrace_ops_list == _ops)
function_trace_op = ftrace_global_list;
@@ -259,18 +240,7 @@ static void update_ftrace_function(void)
func = ftrace_ops_list_func;
}
 
-#ifdef CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST
ftrace_trace_function = func;
-#else
-#ifdef CONFIG_DYNAMIC_FTRACE
-   /* do not update till all functions have been modified */
-   __ftrace_trace_function_delay = func;
-#else
-   __ftrace_trace_function = func;
-#endif
-   ftrace_trace_function =
-   (func == ftrace_stub) ? func : ftrace_test_stop_func;
-#endif
 }
 
 static void add_ftrace_ops(struct ftrace_ops **list, struct ftrace_ops *ops)
@@ -1902,16 +1872,6 @@ static void ftrace_run_update_code(int command)
 */
arch_ftrace_update_code(command);
 
-#ifndef CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST
-   /*
-* For archs 

[PATCH 03/19] ftrace: Return pt_regs to function trace callback

[Steven Rostedt]

From: Steven Rostedt 

Return as the 4th paramater to the function tracer callback the pt_regs.

Later patches that implement regs passing for the architectures will require
having the ftrace_ops set the SAVE_REGS flag, which will tell the arch
to take the time to pass a full set of pt_regs to the ftrace_ops callback
function. If the arch does not support it then it should pass NULL.

If an arch can pass full regs, then it should define:
 ARCH_SUPPORTS_FTRACE_SAVE_REGS to 1

Link: http://lkml.kernel.org/r/20120702201821.019966...@goodmis.org

Reviewed-by: Masami Hiramatsu 
Signed-off-by: Steven Rostedt 
---
 include/linux/ftrace.h|6 --
 kernel/trace/ftrace.c |   37 ++---
 kernel/trace/trace_event_perf.c   |2 +-
 kernel/trace/trace_events.c   |2 +-
 kernel/trace/trace_functions.c|7 ---
 kernel/trace/trace_irqsoff.c  |2 +-
 kernel/trace/trace_sched_wakeup.c |3 ++-
 kernel/trace/trace_selftest.c |   15 ++-
 kernel/trace/trace_stack.c|3 ++-
 9 files changed, 47 insertions(+), 30 deletions(-)

diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 3651fdc..e420288 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -54,7 +55,7 @@ ftrace_enable_sysctl(struct ctl_table *table, int write,
 struct ftrace_ops;
 
 typedef void (*ftrace_func_t)(unsigned long ip, unsigned long parent_ip,
- struct ftrace_ops *op);
+ struct ftrace_ops *op, struct pt_regs *regs);
 
 /*
  * FTRACE_OPS_FL_* bits denote the state of ftrace_ops struct and are
@@ -188,7 +189,8 @@ static inline int ftrace_function_local_disabled(struct 
ftrace_ops *ops)
return *this_cpu_ptr(ops->disabled);
 }
 
-extern void ftrace_stub(unsigned long a0, unsigned long a1, struct ftrace_ops 
*op);
+extern void ftrace_stub(unsigned long a0, unsigned long a1,
+   struct ftrace_ops *op, struct pt_regs *regs);
 
 #else /* !CONFIG_FUNCTION_TRACER */
 /*
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 4cbca2e..6ff07ad 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -103,7 +103,7 @@ static struct ftrace_ops control_ops;
 
 #if ARCH_SUPPORTS_FTRACE_OPS
 static void ftrace_ops_list_func(unsigned long ip, unsigned long parent_ip,
-struct ftrace_ops *op);
+struct ftrace_ops *op, struct pt_regs *regs);
 #else
 /* See comment below, where ftrace_ops_list_func is defined */
 static void ftrace_ops_no_ops(unsigned long ip, unsigned long parent_ip);
@@ -121,7 +121,7 @@ static void ftrace_ops_no_ops(unsigned long ip, unsigned 
long parent_ip);
  */
 static void
 ftrace_global_list_func(unsigned long ip, unsigned long parent_ip,
-   struct ftrace_ops *op)
+   struct ftrace_ops *op, struct pt_regs *regs)
 {
if (unlikely(trace_recursion_test(TRACE_GLOBAL_BIT)))
return;
@@ -129,19 +129,19 @@ ftrace_global_list_func(unsigned long ip, unsigned long 
parent_ip,
trace_recursion_set(TRACE_GLOBAL_BIT);
op = rcu_dereference_raw(ftrace_global_list); /*see above*/
while (op != _list_end) {
-   op->func(ip, parent_ip, op);
+   op->func(ip, parent_ip, op, regs);
op = rcu_dereference_raw(op->next); /*see above*/
};
trace_recursion_clear(TRACE_GLOBAL_BIT);
 }
 
 static void ftrace_pid_func(unsigned long ip, unsigned long parent_ip,
-   struct ftrace_ops *op)
+   struct ftrace_ops *op, struct pt_regs *regs)
 {
if (!test_tsk_trace_trace(current))
return;
 
-   ftrace_pid_function(ip, parent_ip, op);
+   ftrace_pid_function(ip, parent_ip, op, regs);
 }
 
 static void set_ftrace_pid_function(ftrace_func_t func)
@@ -763,7 +763,7 @@ ftrace_profile_alloc(struct ftrace_profile_stat *stat, 
unsigned long ip)
 
 static void
 function_profile_call(unsigned long ip, unsigned long parent_ip,
- struct ftrace_ops *ops)
+ struct ftrace_ops *ops, struct pt_regs *regs)
 {
struct ftrace_profile_stat *stat;
struct ftrace_profile *rec;
@@ -793,7 +793,7 @@ function_profile_call(unsigned long ip, unsigned long 
parent_ip,
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 static int profile_graph_entry(struct ftrace_graph_ent *trace)
 {
-   function_profile_call(trace->func, 0, NULL);
+   function_profile_call(trace->func, 0, NULL, NULL);
return 1;
 }
 
@@ -2771,7 +2771,7 @@ static int __init ftrace_mod_cmd_init(void)
 device_initcall(ftrace_mod_cmd_init);
 
 static void function_trace_probe_call(unsigned long ip, unsigned long 
parent_ip,
- struct ftrace_ops *op)
+   

[PATCH 01/19] ftrace: Pass ftrace_ops as third parameter to function trace callback

[Steven Rostedt]

From: Steven Rostedt 

Currently the function trace callback receives only the ip and parent_ip
of the function that it traced. It would be more powerful to also return
the ops that registered the function as well. This allows the same function
to act differently depending on what ftrace_ops registered it.

Link: http://lkml.kernel.org/r/20120612225424.267254...@goodmis.org

Reviewed-by: Masami Hiramatsu 
Signed-off-by: Steven Rostedt 
---
 arch/x86/include/asm/ftrace.h |4 ++
 arch/x86/kernel/entry_64.S|1 +
 include/linux/ftrace.h|   16 +-
 kernel/trace/ftrace.c |  101 +
 kernel/trace/trace_event_perf.c   |3 +-
 kernel/trace/trace_events.c   |3 +-
 kernel/trace/trace_functions.c|9 ++--
 kernel/trace/trace_irqsoff.c  |3 +-
 kernel/trace/trace_sched_wakeup.c |2 +-
 kernel/trace/trace_selftest.c |   15 --
 kernel/trace/trace_stack.c|2 +-
 11 files changed, 113 insertions(+), 46 deletions(-)

diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index b0767bc..783b107 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -32,6 +32,10 @@
 #define MCOUNT_ADDR((long)(mcount))
 #define MCOUNT_INSN_SIZE   5 /* sizeof mcount call */
 
+#if defined(CONFIG_DYNAMIC_FTRACE) && defined(CONFIG_X86_64)
+#define ARCH_SUPPORTS_FTRACE_OPS 1
+#endif
+
 #ifndef __ASSEMBLY__
 extern void mcount(void);
 extern atomic_t modifying_ftrace_code;
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 7d65133..2b4f94c 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -79,6 +79,7 @@ ENTRY(ftrace_caller)
 
MCOUNT_SAVE_FRAME
 
+   leaq function_trace_op, %rdx
movq 0x38(%rsp), %rdi
movq 8(%rbp), %rsi
subq $MCOUNT_INSN_SIZE, %rdi
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 55e6d63..2d59641 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -18,6 +18,15 @@
 
 #include 
 
+/*
+ * If the arch supports passing the variable contents of
+ * function_trace_op as the third parameter back from the
+ * mcount call, then the arch should define this as 1.
+ */
+#ifndef ARCH_SUPPORTS_FTRACE_OPS
+#define ARCH_SUPPORTS_FTRACE_OPS 0
+#endif
+
 struct module;
 struct ftrace_hash;
 
@@ -29,7 +38,10 @@ ftrace_enable_sysctl(struct ctl_table *table, int write,
 void __user *buffer, size_t *lenp,
 loff_t *ppos);
 
-typedef void (*ftrace_func_t)(unsigned long ip, unsigned long parent_ip);
+struct ftrace_ops;
+
+typedef void (*ftrace_func_t)(unsigned long ip, unsigned long parent_ip,
+ struct ftrace_ops *op);
 
 /*
  * FTRACE_OPS_FL_* bits denote the state of ftrace_ops struct and are
@@ -163,7 +175,7 @@ static inline int ftrace_function_local_disabled(struct 
ftrace_ops *ops)
return *this_cpu_ptr(ops->disabled);
 }
 
-extern void ftrace_stub(unsigned long a0, unsigned long a1);
+extern void ftrace_stub(unsigned long a0, unsigned long a1, struct ftrace_ops 
*op);
 
 #else /* !CONFIG_FUNCTION_TRACER */
 /*
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index b4f20fb..4f2ab93 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -64,12 +64,19 @@
 
 #define FL_GLOBAL_CONTROL_MASK (FTRACE_OPS_FL_GLOBAL | FTRACE_OPS_FL_CONTROL)
 
+static struct ftrace_ops ftrace_list_end __read_mostly = {
+   .func   = ftrace_stub,
+};
+
 /* ftrace_enabled is a method to turn ftrace on or off */
 int ftrace_enabled __read_mostly;
 static int last_ftrace_enabled;
 
 /* Quick disabling of function tracer. */
-int function_trace_stop;
+int function_trace_stop __read_mostly;
+
+/* Current function tracing op */
+struct ftrace_ops *function_trace_op __read_mostly = _list_end;
 
 /* List for set_ftrace_pid's pids. */
 LIST_HEAD(ftrace_pids);
@@ -86,10 +93,6 @@ static int ftrace_disabled __read_mostly;
 
 static DEFINE_MUTEX(ftrace_lock);
 
-static struct ftrace_ops ftrace_list_end __read_mostly = {
-   .func   = ftrace_stub,
-};
-
 static struct ftrace_ops *ftrace_global_list __read_mostly = _list_end;
 static struct ftrace_ops *ftrace_control_list __read_mostly = _list_end;
 static struct ftrace_ops *ftrace_ops_list __read_mostly = _list_end;
@@ -100,8 +103,14 @@ ftrace_func_t ftrace_pid_function __read_mostly = 
ftrace_stub;
 static struct ftrace_ops global_ops;
 static struct ftrace_ops control_ops;
 
-static void
-ftrace_ops_list_func(unsigned long ip, unsigned long parent_ip);
+#if ARCH_SUPPORTS_FTRACE_OPS
+static void ftrace_ops_list_func(unsigned long ip, unsigned long parent_ip,
+struct ftrace_ops *op);
+#else
+/* See comment below, where ftrace_ops_list_func is defined */
+static void ftrace_ops_no_ops(unsigned long ip, unsigned long parent_ip);
+#define ftrace_ops_list_func ((ftrace_func_t)ftrace_ops_no_ops)

[PATCH 05/19] ftrace/x86: Add separate function to save regs

[Steven Rostedt]

From: Steven Rostedt 

Add a way to have different functions calling different trampolines.
If a ftrace_ops wants regs saved on the return, then have only the
functions with ops registered to save regs. Functions registered by
other ops would not be affected, unless the functions overlap.

If one ftrace_ops registered functions A, B and C and another ops
registered fucntions to save regs on A, and D, then only functions
A and D would be saving regs. Function B and C would work as normal.
Although A is registered by both ops: normal and saves regs; this is fine
as saving the regs is needed to satisfy one of the ops that calls it
but the regs are ignored by the other ops function.

x86_64 implements the full regs saving, and i386 just passes a NULL
for regs to satisfy the ftrace_ops passing. Where an arch must supply
both regs and ftrace_ops parameters, even if regs is just NULL.

It is OK for an arch to pass NULL regs. All function trace users that
require regs passing must add the flag FTRACE_OPS_FL_SAVE_REGS when
registering the ftrace_ops. If the arch does not support saving regs
then the ftrace_ops will fail to register. The flag
FTRACE_OPS_FL_SAVE_REGS_IF_SUPPORTED may be set that will prevent the
ftrace_ops from failing to register. In this case, the handler may
either check if regs is not NULL or check if ARCH_SUPPORTS_FTRACE_SAVE_REGS.
If the arch supports passing regs it will set this macro and pass regs
for ops that request them. All other archs will just pass NULL.

Link: Link: http://lkml.kernel.org/r/20120711195745.107705...@goodmis.org

Cc: Alexander van Heukelum 
Reviewed-by: Masami Hiramatsu 
Signed-off-by: Steven Rostedt 
---
 arch/x86/include/asm/ftrace.h |   47 ++
 arch/x86/kernel/entry_32.S|4 +-
 arch/x86/kernel/entry_64.S|   94 +---
 arch/x86/kernel/ftrace.c  |   77 +++--
 include/linux/ftrace.h|  107 ++---
 kernel/trace/ftrace.c |   91 ---
 6 files changed, 373 insertions(+), 47 deletions(-)

diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index b3bb1f3..a847501 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -3,27 +3,33 @@
 
 #ifdef __ASSEMBLY__
 
-   .macro MCOUNT_SAVE_FRAME
-   /* taken from glibc */
-   subq $0x38, %rsp
-   movq %rax, (%rsp)
-   movq %rcx, 8(%rsp)
-   movq %rdx, 16(%rsp)
-   movq %rsi, 24(%rsp)
-   movq %rdi, 32(%rsp)
-   movq %r8, 40(%rsp)
-   movq %r9, 48(%rsp)
+   /* skip is set if the stack was already partially adjusted */
+   .macro MCOUNT_SAVE_FRAME skip=0
+/*
+ * We add enough stack to save all regs.
+ */
+   subq $(SS+8-\skip), %rsp
+   movq %rax, RAX(%rsp)
+   movq %rcx, RCX(%rsp)
+   movq %rdx, RDX(%rsp)
+   movq %rsi, RSI(%rsp)
+   movq %rdi, RDI(%rsp)
+   movq %r8, R8(%rsp)
+   movq %r9, R9(%rsp)
+/* Move RIP to its proper location */
+   movq SS+8(%rsp), %rdx
+   movq %rdx, RIP(%rsp)
.endm
 
-   .macro MCOUNT_RESTORE_FRAME
-   movq 48(%rsp), %r9
-   movq 40(%rsp), %r8
-   movq 32(%rsp), %rdi
-   movq 24(%rsp), %rsi
-   movq 16(%rsp), %rdx
-   movq 8(%rsp), %rcx
-   movq (%rsp), %rax
-   addq $0x38, %rsp
+   .macro MCOUNT_RESTORE_FRAME skip=0
+   movq R9(%rsp), %r9
+   movq R8(%rsp), %r8
+   movq RDI(%rsp), %rdi
+   movq RSI(%rsp), %rsi
+   movq RDX(%rsp), %rdx
+   movq RCX(%rsp), %rcx
+   movq RAX(%rsp), %rax
+   addq $(SS+8-\skip), %rsp
.endm
 
 #endif
@@ -34,6 +40,9 @@
 
 #ifdef CONFIG_DYNAMIC_FTRACE
 #define ARCH_SUPPORTS_FTRACE_OPS 1
+#ifdef CONFIG_X86_64
+#define ARCH_SUPPORTS_FTRACE_SAVE_REGS
+#endif
 #endif
 
 #ifndef __ASSEMBLY__
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index e3e17a0..5da11d1 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -1109,7 +1109,8 @@ ENTRY(ftrace_caller)
pushl %eax
pushl %ecx
pushl %edx
-   movl 0xc(%esp), %eax
+   pushl $0/* Pass NULL as regs pointer */
+   movl 4*4(%esp), %eax
movl 0x4(%ebp), %edx
leal function_trace_op, %ecx
subl $MCOUNT_INSN_SIZE, %eax
@@ -1118,6 +1119,7 @@ ENTRY(ftrace_caller)
 ftrace_call:
call ftrace_stub
 
+   addl $4,%esp/* skip NULL pointer */
popl %edx
popl %ecx
popl %eax
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 2b4f94c..52bda2e 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -73,21 +73,34 @@ ENTRY(mcount)
retq
 END(mcount)
 
+/* skip is set if stack has been adjusted */
+.macro ftrace_caller_setup skip=0
+   MCOUNT_SAVE_FRAME \skip
+
+   /* Load the ftrace_ops into the 3rd parameter */
+   leaq function_trace_op, 

[PATCH 19/19] kprobes/x86: ftrace based optimization for x86

[Steven Rostedt]

From: Masami Hiramatsu 

Add function tracer based kprobe optimization support
handlers on x86. This allows kprobes to use function
tracer for probing on mcount call.

Link: 
http://lkml.kernel.org/r/20120605102838.27845.26317.stgit@localhost.localdomain

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Ananth N Mavinakayanahalli 
Cc: "Frank Ch. Eigler" 
Cc: Andrew Morton 
Cc: Frederic Weisbecker 
Signed-off-by: Masami Hiramatsu 

[ Updated to new port of ftrace save regs functions ]

Signed-off-by: Steven Rostedt 
---
 arch/x86/include/asm/kprobes.h |1 +
 arch/x86/kernel/kprobes.c  |   48 
 include/linux/kprobes.h|2 +-
 kernel/kprobes.c   |2 +-
 4 files changed, 51 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/kprobes.h b/arch/x86/include/asm/kprobes.h
index 5478825..d3ddd17 100644
--- a/arch/x86/include/asm/kprobes.h
+++ b/arch/x86/include/asm/kprobes.h
@@ -27,6 +27,7 @@
 #include 
 
 #define  __ARCH_WANT_KPROBES_INSN_SLOT
+#define  ARCH_SUPPORTS_KPROBES_ON_FTRACE
 
 struct pt_regs;
 struct kprobe;
diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index e2f751e..47ae102 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/kernel/kprobes.c
@@ -1052,6 +1052,54 @@ int __kprobes longjmp_break_handler(struct kprobe *p, 
struct pt_regs *regs)
return 0;
 }
 
+#ifdef KPROBES_CAN_USE_FTRACE
+/* Ftrace callback handler for kprobes */
+void __kprobes kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
+struct ftrace_ops *ops, struct pt_regs 
*regs)
+{
+   struct kprobe *p;
+   struct kprobe_ctlblk *kcb;
+   unsigned long flags;
+
+   /* Disable irq for emulating a breakpoint and avoiding preempt */
+   local_irq_save(flags);
+
+   p = get_kprobe((kprobe_opcode_t *)ip);
+   if (unlikely(!p) || kprobe_disabled(p))
+   goto end;
+
+   kcb = get_kprobe_ctlblk();
+   if (kprobe_running()) {
+   kprobes_inc_nmissed_count(p);
+   } else {
+   regs->ip += sizeof(kprobe_opcode_t);
+
+   __this_cpu_write(current_kprobe, p);
+   kcb->kprobe_status = KPROBE_HIT_ACTIVE;
+   if (p->pre_handler)
+   p->pre_handler(p, regs);
+
+   if (unlikely(p->post_handler)) {
+   /* Emulate singlestep as if there is a 5byte nop */
+   regs->ip = ip + MCOUNT_INSN_SIZE;
+   kcb->kprobe_status = KPROBE_HIT_SSDONE;
+   p->post_handler(p, regs, 0);
+   }
+   __this_cpu_write(current_kprobe, NULL);
+   regs->ip = ip;  /* Recover for next callback */
+   }
+end:
+   local_irq_restore(flags);
+}
+
+int __kprobes arch_prepare_kprobe_ftrace(struct kprobe *p)
+{
+   p->ainsn.insn = NULL;
+   p->ainsn.boostable = -1;
+   return 0;
+}
+#endif
+
 int __init arch_init_kprobes(void)
 {
return arch_init_optprobes();
diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
index aa0d05e..23755ba 100644
--- a/include/linux/kprobes.h
+++ b/include/linux/kprobes.h
@@ -318,7 +318,7 @@ extern int proc_kprobes_optimization_handler(struct 
ctl_table *table,
 #endif /* CONFIG_OPTPROBES */
 #ifdef KPROBES_CAN_USE_FTRACE
 extern void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
- struct pt_regs *regs);
+ struct ftrace_ops *ops, struct pt_regs *regs);
 extern int arch_prepare_kprobe_ftrace(struct kprobe *p);
 #endif
 
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 69c16ef..35b4315 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -921,7 +921,7 @@ static __kprobes struct kprobe *alloc_aggr_kprobe(struct 
kprobe *p)
 
 #ifdef KPROBES_CAN_USE_FTRACE
 static struct ftrace_ops kprobe_ftrace_ops __read_mostly = {
-   .regs_func = kprobe_ftrace_handler,
+   .func = kprobe_ftrace_handler,
.flags = FTRACE_OPS_FL_SAVE_REGS,
 };
 static int kprobe_ftrace_enabled;
-- 
1.7.10.4




signature.asc
Description: This is a digitally signed message part

[PATCH 00/19] [GIT PULL][v3.6] ftrace: Allow kprobes to work with ftace

[Steven Rostedt]

Ingo,

This patch series extends ftrace function tracing utility to be
more dynamic for its users. It allows for data passing to the callback
functions, as well as reading regs as if a breakpoint were to trigger
at function entry.

The main goal of this patch series was to allow kprobes to use ftrace
as an optimized probe point when a probe is placed on an ftrace nop.
With lots of help from Masami Hiramatsu, and going through lots of
iterations, we finally came up with a good solution.

I've tested it vigorously (although, like always, there may be some
subtle bug), but I feel it is ready for inclussion for the 3.6 merge
window.

Please pull the latest tip/perf/core tree, which can be found at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
tip/perf/core

Head SHA1: aa5e57294ac5614ac395a9733d3e050eace4764e


Masami Hiramatsu (5):
  ftrace: add ftrace_set_filter_ip() for address based filter
  kprobes: cleanup to separate probe-able check
  kprobes: Move locks into appropriate functions
  kprobes: introduce ftrace based optimization
  kprobes/x86: ftrace based optimization for x86

Steven Rostedt (13):
  ftrace: Pass ftrace_ops as third parameter to function trace callback
  ftrace: Consolidate arch dependent functions with 'list' function
  ftrace: Return pt_regs to function trace callback
  ftrace/x86_32: Push ftrace_ops in as 3rd parameter to function tracer
  ftrace/x86: Add separate function to save regs
  ftrace/x86: Add save_regs for i386 function calls
  ftrace/x86: Remove function_trace_stop check from graph caller
  ftrace: Add default recursion protection for function tracing
  ftrace: Only compile ftrace selftest if selftests are enabled
  ftrace: Add selftest to test function trace recursion protection
  ftrace: Add selftest to test function save-regs support
  kprobes: Inverse taking of module_mutex with kprobe_mutex
  ftrace: Make ftrace_location() a nop on !DYNAMIC_FTRACE

Uros Bizjak (1):
  ftrace/x86_32: Simplify parameter setup for ftrace_regs_caller


 arch/x86/include/asm/ftrace.h |   49 +++---
 arch/x86/include/asm/kprobes.h|1 +
 arch/x86/kernel/entry_32.S|   75 -
 arch/x86/kernel/entry_64.S|   96 +--
 arch/x86/kernel/ftrace.c  |   73 -
 arch/x86/kernel/kprobes.c |   48 ++
 include/linux/ftrace.h|  158 --
 include/linux/kprobes.h   |   27 
 kernel/kprobes.c  |  250 
 kernel/trace/Makefile |2 +
 kernel/trace/ftrace.c |  322 -
 kernel/trace/trace.h  |2 +-
 kernel/trace/trace_event_perf.c   |3 +-
 kernel/trace/trace_events.c   |4 +-
 kernel/trace/trace_functions.c|   14 +-
 kernel/trace/trace_irqsoff.c  |5 +-
 kernel/trace/trace_sched_wakeup.c |5 +-
 kernel/trace/trace_selftest.c |  277 ++-
 kernel/trace/trace_stack.c|4 +-
 19 files changed, 1199 insertions(+), 216 deletions(-)


signature.asc
Description: This is a digitally signed message part

[PATCH 1/2] ARM: vt8500: Update vt8500-ehci driver to support device tree.

[Tony Prisk]

Signed-off-by: Tony Prisk 
---
 .../devicetree/bindings/usb/vt8500-ehci.txt|   10 ++
 drivers/usb/host/ehci-vt8500.c |9 +
 2 files changed, 19 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/vt8500-ehci.txt

diff --git a/Documentation/devicetree/bindings/usb/vt8500-ehci.txt 
b/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
new file mode 100644
index 000..74f75c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
@@ -0,0 +1,10 @@
+VIA VT8500 and Wondermedia WM8xxx SoC USB controllers.
+
+Required properties:
+ - compatible: Should be "via,vt8500-ehci" or "wm,prizm-ehci".
+
+usb: ehci@D8007100 {
+   compatible = "wm,prizm-ehci", "usb-ehci";
+   reg = <0xD8007100 0x200>;
+   interrupts = <1>;
+};
diff --git a/drivers/usb/host/ehci-vt8500.c b/drivers/usb/host/ehci-vt8500.c
index c1eda73..4ba8f0c 100644
--- a/drivers/usb/host/ehci-vt8500.c
+++ b/drivers/usb/host/ehci-vt8500.c
@@ -16,6 +16,7 @@
  *
  */
 
+#include 
 #include 
 
 static int ehci_update_device(struct usb_hcd *hcd, struct usb_device *udev)
@@ -162,6 +163,12 @@ static int vt8500_ehci_drv_remove(struct platform_device 
*pdev)
return 0;
 }
 
+static const struct of_device_id vt8500_ehci_ids[] = {
+   { .compatible = "via,vt8500-ehci", },
+   { .compatible = "wm,prizm-ehci", },
+   {}
+};
+
 static struct platform_driver vt8500_ehci_driver = {
.probe  = vt8500_ehci_drv_probe,
.remove = vt8500_ehci_drv_remove,
@@ -169,7 +176,9 @@ static struct platform_driver vt8500_ehci_driver = {
.driver = {
.name   = "vt8500-ehci",
.owner  = THIS_MODULE,
+   .of_match_table = of_match_ptr(vt8500_ehci_ids),
}
 };
 
 MODULE_ALIAS("platform:vt8500-ehci");
+MODULE_DEVICE_TABLE(of, vt8500_ehci_ids);
-- 
1.7.2.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/

[PATCHv3 2/2] ARM: vt8500: Add support for UHCI companion controller

[Tony Prisk]

Add support for a generic non-pci UHCI companion controller.
Existing board files for arch-vt8500 updated to include UHCI
support.

Signed-off-by: Tony Prisk 
---
V3:
Added the missing commits for the board files.

 arch/arm/mach-vt8500/bv07.c   |1 +
 arch/arm/mach-vt8500/devices-vt8500.c |5 +
 arch/arm/mach-vt8500/devices-wm8505.c |4 +
 arch/arm/mach-vt8500/devices.c|   11 +++
 arch/arm/mach-vt8500/devices.h|1 +
 arch/arm/mach-vt8500/wm8505_7in.c |1 +
 drivers/usb/host/Kconfig  |   12 ++-
 drivers/usb/host/uhci-hcd.c   |5 +
 drivers/usb/host/uhci-platform.c  |  157 +
 9 files changed, 195 insertions(+), 2 deletions(-)
 create mode 100644 drivers/usb/host/uhci-platform.c

diff --git a/arch/arm/mach-vt8500/bv07.c b/arch/arm/mach-vt8500/bv07.c
index a464c75..19d20d9 100644
--- a/arch/arm/mach-vt8500/bv07.c
+++ b/arch/arm/mach-vt8500/bv07.c
@@ -32,6 +32,7 @@ static struct platform_device *devices[] __initdata = {
_device_uart0,
_device_lcdc,
_device_ehci,
+   _device_uhci,
_device_ge_rops,
_device_pwm,
_device_pwmbl,
diff --git a/arch/arm/mach-vt8500/devices-vt8500.c 
b/arch/arm/mach-vt8500/devices-vt8500.c
index 19519ae..def7fe3 100644
--- a/arch/arm/mach-vt8500/devices-vt8500.c
+++ b/arch/arm/mach-vt8500/devices-vt8500.c
@@ -48,6 +48,11 @@ void __init vt8500_set_resources(void)
tmp[1] = wmt_irq_res(IRQ_EHCI);
wmt_res_add(_device_ehci, tmp, 2);
 
+   /* vt8500 uses a single IRQ for both EHCI and UHCI controllers */
+   tmp[0] = wmt_mmio_res(VT8500_UHCI_BASE, SZ_512);
+   tmp[1] = wmt_irq_res(IRQ_EHCI);
+   wmt_res_add(_device_uhci, tmp, 2);
+
tmp[0] = wmt_mmio_res(VT8500_GEGEA_BASE, SZ_256);
wmt_res_add(_device_ge_rops, tmp, 1);
 
diff --git a/arch/arm/mach-vt8500/devices-wm8505.c 
b/arch/arm/mach-vt8500/devices-wm8505.c
index db4594e..c810454 100644
--- a/arch/arm/mach-vt8500/devices-wm8505.c
+++ b/arch/arm/mach-vt8500/devices-wm8505.c
@@ -55,6 +55,10 @@ void __init wm8505_set_resources(void)
tmp[1] = wmt_irq_res(IRQ_EHCI);
wmt_res_add(_device_ehci, tmp, 2);
 
+   tmp[0] = wmt_mmio_res(WM8505_UHCI_BASE, SZ_512);
+   tmp[1] = wmt_irq_res(IRQ_UHCI);
+   wmt_res_add(_device_uhci, tmp, 2);
+
tmp[0] = wmt_mmio_res(WM8505_GEGEA_BASE, SZ_256);
wmt_res_add(_device_ge_rops, tmp, 1);
 
diff --git a/arch/arm/mach-vt8500/devices.c b/arch/arm/mach-vt8500/devices.c
index 1fcdc36..46ff82d 100644
--- a/arch/arm/mach-vt8500/devices.c
+++ b/arch/arm/mach-vt8500/devices.c
@@ -204,6 +204,17 @@ struct platform_device vt8500_device_ehci = {
},
 };
 
+static u64 uhci_dma_mask = DMA_BIT_MASK(32);
+
+struct platform_device vt8500_device_uhci = {
+   .name   = "platform-uhci",
+   .id = 0,
+   .dev= {
+   .dma_mask   = _dma_mask,
+   .coherent_dma_mask = DMA_BIT_MASK(32),
+   },
+};
+
 struct platform_device vt8500_device_ge_rops = {
.name   = "wmt_ge_rops",
.id = -1,
diff --git a/arch/arm/mach-vt8500/devices.h b/arch/arm/mach-vt8500/devices.h
index 188d4e1..0e6d9f9 100644
--- a/arch/arm/mach-vt8500/devices.h
+++ b/arch/arm/mach-vt8500/devices.h
@@ -81,6 +81,7 @@ extern struct platform_device vt8500_device_uart5;
 extern struct platform_device vt8500_device_lcdc;
 extern struct platform_device vt8500_device_wm8505_fb;
 extern struct platform_device vt8500_device_ehci;
+extern struct platform_device vt8500_device_uhci;
 extern struct platform_device vt8500_device_ge_rops;
 extern struct platform_device vt8500_device_pwm;
 extern struct platform_device vt8500_device_pwmbl;
diff --git a/arch/arm/mach-vt8500/wm8505_7in.c 
b/arch/arm/mach-vt8500/wm8505_7in.c
index cf910a9..302ae2f 100644
--- a/arch/arm/mach-vt8500/wm8505_7in.c
+++ b/arch/arm/mach-vt8500/wm8505_7in.c
@@ -31,6 +31,7 @@ static void __iomem *pmc_hiber;
 static struct platform_device *devices[] __initdata = {
_device_uart0,
_device_ehci,
+   _device_uhci,
_device_wm8505_fb,
_device_ge_rops,
_device_pwm,
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 83e58df..3d153d0 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -450,7 +450,7 @@ config USB_OHCI_LITTLE_ENDIAN
 
 config USB_UHCI_HCD
tristate "UHCI HCD (most Intel and VIA) support"
-   depends on USB && (PCI || SPARC_LEON)
+   depends on USB && (PCI || SPARC_LEON || ARCH_VT8500)
---help---
  The Universal Host Controller Interface is a standard by Intel for
  accessing the USB hardware in the PC (which is also called the USB
@@ -468,7 +468,15 @@ config USB_UHCI_HCD
 config USB_UHCI_SUPPORT_NON_PCI_HC
bool
depends on USB_UHCI_HCD
-   default y if SPARC_LEON
+   default y if (SPARC_LEON || ARCH_VT8500)
+

Re: [PATCH] dmi: Feed DMI table to /dev/random driver

[Theodore Ts'o]

On Fri, Jul 20, 2012 at 06:19:33PM -0700, Tony Luck wrote:
> On Fri, Jul 20, 2012 at 5:56 PM, Theodore Ts'o  wrote:
> > The other approach was to add some new interface that random.c would
> > call which would grab the dmi data from rand_initialize().  But that's
> > going to be a lot more complicated, so I guess we should go with the
> > simple/stupid approach.
> 
> It wouldn't be all that hard ... we'd just need to add a new entry point
> to the dmi codefor random to call (and a stub somewhere so that
> CONFIG_DMI=n kernels still build). But getting some per-platform
> data into the random pools earlier is a good thing ... it means that
> users of random data will see the benefit earlier than they do now.

Yeah, what makes it tricky is if we wanted to do things in an arch
independent way, since I assume there are architectures out there
which have something which has the same sort of information as the DMI
tables, but which would be something else.  So we'd need to have some
interface which could be defined by each architecture, and a no-op
function for architectures that didn't provide such a thing.

> So add the big fat comment so that people know not to break this
> useful (if not entirely intentional) functionality.

I agree.  Want to send a revised patch with the comment, and I'll drop
it into the random.git tree?

Thanks,

- Ted

--
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] dmi: Feed DMI table to /dev/random driver

[Tony Luck]

On Fri, Jul 20, 2012 at 5:56 PM, Theodore Ts'o  wrote:
> The other approach was to add some new interface that random.c would
> call which would grab the dmi data from rand_initialize().  But that's
> going to be a lot more complicated, so I guess we should go with the
> simple/stupid approach.

It wouldn't be all that hard ... we'd just need to add a new entry point
to the dmi codefor random to call (and a stub somewhere so that
CONFIG_DMI=n kernels still build). But getting some per-platform
data into the random pools earlier is a good thing ... it means that
users of random data will see the benefit earlier than they do now.

So add the big fat comment so that people know not to break this
useful (if not entirely intentional) functionality.

-Tony
--
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 RESEND 5/5] vhost-blk: Add vhost-blk support

[Asias He]

On 07/21/2012 04:56 AM, Anthony Liguori wrote:

"Michael S. Tsirkin"  writes:


On Thu, Jul 19, 2012 at 08:05:42AM -0500, Anthony Liguori wrote:

Of course, the million dollar question is why would using AIO in the
kernel be faster than using AIO in userspace?


Actually for me a more important question is how does it compare
with virtio-blk dataplane?


I'm not even asking for a benchmark comparision.  It's the same API
being called from a kernel thread vs. a userspace thread.  Why would
there be a 60% performance difference between the two?  That doesn't
make any sense.


Please read the commit log again. I am not saying vhost-blk v.s 
userspace implementation gives 60% improvement. I am saying the 
vhost-blk v.s original vhost-blk gives 60% improvement.



"""
This patch is based on Liu Yuan's implementation with various
improvements and bug fixes. Notably, this patch makes guest notify and
host completion processing in parallel which gives about 60% performance
improvement compared to Liu Yuan's implementation.
"""



There's got to be a better justification for putting this in the kernel
than just that we can.

I completely understand why Christoph's suggestion of submitting BIOs
directly would be faster.  There's no way to do that in userspace.


Well. With Zach and Dave's new in-kernel aio API, the aio usage in 
kernel is much simpler than in userspace. This a potential reason that 
in kernel one is better than userspace one. I am working on it right 
now. And for block based image, as suggested by Christoph, we can submit 
bio directly. This is another potential reason.


Why can't we just go further to see if we can improve the IO stack from 
guest kernel side all the way down to host kernel side. We can not do 
that if we stick to doing everything in userspace (qemu).


--
Asias


--
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] dmi: Feed DMI table to /dev/random driver

[Theodore Ts'o]

On Fri, Jul 20, 2012 at 01:15:20PM -0700, Tony Luck wrote:
> Send the entire DMI (SMBIOS) table to the /dev/random driver to
> help seed its pools.
> 
> Signed-off-by: Tony Luck 
> ---
> 
> This looks a useful addition to your /dev/random series. There are
> lots of platform specific goodies in this table (BIOS version, system
> serial number and UUID, count and version number of processors, DIMM
> slot population and serial numbers, etc.)
> 
> On the system I tested the patch on the table is 9866 bytes. Is it
> OK to dump that much into add_device_randomness() in one shot? The
> alternative is to select the 'useful' bits deeper into the routines
> that parse the entries in the table.
> 
>  drivers/firmware/dmi_scan.c | 3 +++
>  1 file changed, 3 insertions(+)

This was something I was looking at doing, but I had considered the
approach you used, and had abandoned it because dmi_walk_early() gets
called ultimately via the setup_arch() call, and the random pools only
get initialized much later in the boot process.  

The fact that you didn't crash when you tested it is simply because
we're not allocating any memory or initializing any criticla data
structures in rand_initialize().  (We used to, but not any more.)

I'm a little nervous enshrining the fact that it's OK to call the
random driver before rand_initialize is called(), but it does work
today.  If we are going to do this, we need to put a big fat comment
in front of rand_initialize() indicating that it's important that we
not depend on any data structures getting initialized by
rand_initialize() before it's safe to call add_device_randomness().

The other approach was to add some new interface that random.c would
call which would grab the dmi data from rand_initialize().  But that's
going to be a lot more complicated, so I guess we should go with the
simple/stupid approach.

- Ted
--
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: ibmveth bug?

[Benjamin Herrenschmidt]

On Fri, 2012-07-20 at 15:41 -0700, Nishanth Aravamudan wrote:
> Ping on this ... we've tripped the same issue on a different system, it
> would appear. Would appreciate if anyone can provide answers to the
> questions below.

Well, I haven't hit it but your description makes sense. Why not use
dma_alloc_coherent though ? Rather than kmalloc followed by map ?

At least on power we give you page alignment for these, so the problem
is solved magically :-) Another option is GFP + dma_map_page which is
roughly equivalent.

If you think it's a waste of space based on the queue size, then just
add an extra pointer, I wouldn't bother with a cache for something only
allocated when the driver initializes.

Cheers,
Ben.

> Thanks,
> Nish
> 
> On 15.05.2012 [10:01:41 -0700], Nishanth Aravamudan wrote:
> > Hi Santiago,
> > 
> > Are you still working on ibmveth?
> > 
> > I've found a very sporadic bug with ibmveth in some testing. PAPR
> > requires that:
> > 
> > "Validate the Buffer Descriptor of the receive queue buffer (I/O
> > addresses for entire buffer length starting at the spec- ified I/O
> > address are translated by the RTCE table, length is a multiple of 16
> > bytes, and alignment is on a 16 byte boundary) else H_Parameter."
> > 
> > but from what I can tell ibmveth.c is not enforcing this last condition:
> > 
> > adapter->rx_queue.queue_addr =
> > kmalloc(adapter->rx_queue.queue_len, GFP_KERNEL);
> > 
> > ...
> > 
> > adapter->rx_queue.queue_dma = dma_map_single(dev,
> > adapter->rx_queue.queue_addr, adapter->rx_queue.queue_len,
> > DMA_BIDIRECTIONAL);
> > 
> > ...
> > 
> > rxq_desc.fields.address = adapter->rx_queue.queue_dma;
> > 
> > ...
> > 
> > 
> > lpar_rc = ibmveth_register_logical_lan(adapter, rxq_desc,
> > mac_address);
> > netdev_err(netdev, "buffer TCE:0x%llx filter TCE:0x%llx rxq "
> > "desc:0x%llx MAC:0x%llx\n", adapter->buffer_list_dma,
> > adapter->filter_list_dma, rxq_desc.desc, mac_address);
> > 
> > And I got on one install attempt:
> > 
> > [ 39.978430] ibmveth 3004: eth0: h_register_logical_lan failed with -4
> > [ 39.978449] ibmveth 3004: eth0: buffer TCE:0x1000 filter TCE:0x1 
> > rxq desc:0x8000601200a8 MAC:0x56754de8e904
> > 
> > rxq desc, as you can see is not 16byte aligned. kmalloc() only
> > guarantees 8-byte alignment (as does gcc, I think). Initially, I thought
> > we could just overallocate the queue_addr and ALIGN() down, but then we
> > would need to save the original kmalloc pointer in a new struct member
> > per rx_queue.
> > 
> > So a couple of questions:
> > 
> > 1) Is my analysis accurate? :)
> > 
> > 2) How gross would it be to save an extra pointer for every rx_queue?
> > 
> > 3) Based upon 2), is it better to just go ahead and create our own
> > kmem_cache (which gets an alignment specified)?
> > 
> > For 3), I started coding this, but couldn't find a clean place to
> > allocate the kmem_cache itself, as the size of each object depends on
> > the run-time characteristics (afaict), but needs to be specified at
> > cache creation time. Any insight you could provide would be great!
> > 
> > Thanks,
> > Nish
> >  
> > -- 
> > Nishanth Aravamudan 
> > IBM Linux Technology Center
> 


--
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: [PATCHv3 0/6] tun zerocopy support

[David Miller]

From: "Michael S. Tsirkin" 
Date: Fri, 20 Jul 2012 22:23:03 +0300

> Same as with macvtap, I get single-percentage wins in CPU utilization
> on guest to external from this patchset, and a performance regression on
> guest to host, so more work is needed until this feature can move out of
> experimental status, but I think it's useful for some people already.
> 
> Pls review and consider for 3.6.

It doesn't improve performance in one case, and hurts performance in
another.

You'll have to give me a more compelling argument than that.  You've
just given me every reason not to include these patches in 3.6

--
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] MPILIB: Provide count_leading/trailing_zeros() based on arch functions

[David Miller]

From: David Howells 
Date: Fri, 20 Jul 2012 15:21:39 +0100

> Arnd Bergmann  wrote:
> 
>> I don't generally like to put stuff into asm-generic when it's unlikely
>> to be overridden by architectures. It would really belong into
>> include/linux, but then again we have all the other bitops in asm-generic
>> as well, so whatever...
> 
> Some arches (such as Sparc, I think) have count-leading-zero instructions.

Yes, newer sparc64 chips have leading-zero-detect, and I was pretty
sure that powerpc had something similar.  It's called count-leading-
zeros or something like that.

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

sysfs permissions on dynamic attributes (led delay_on and delay_off)

[Colin Cross]

I'm trying to use the standard ledtrig-timer.c code to handle led
blinking for notifications on an Android device, and I'm hitting some
issues with setting permissions on the dynamically created delay_on
and delay_off attributes.  For most sysfs files, we have userspace
uevent parser that watches for device add notifications and
chowns/chmods attributes.  This doesn't work for delay_on and
delay_off, because they are created later, when "timer" is written to
the trigger attribute.  There is no uevent when the new files are
created, and sysfs doesn't support inotify, so I don't see any way to
receive an event to set the permissions.  This issue exists any time
that device_create_file is called after device_add.

What is the appropriate way to get an event to set the permissions?
Add inotify support for sysfs file creation?  Send a KOBJ_CHANGE
uevent in device_create_file? Send a KOBJ_CHANGE uevent from the
driver after calling device_create_file?  Dynamically create a timer
device under /sys/class/leds/ so a new add uevent gets sent?
Promote blinking to be a core led feature instead of a trigger, so the
files are always present?
--
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 4/4] kdb: Switch to nolock variants of kmsg_dump functions

[Anton Vorontsov]

The locked variants are prone to deadlocks (suppose we got to the
debugger w/ the logbuf lock held), so let's switch to nolock
variants.

Signed-off-by: Anton Vorontsov 
---
 kernel/debug/kdb/kdb_main.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
index df17c93..1f91413 100644
--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -2072,8 +2072,8 @@ static int kdb_dmesg(int argc, const char **argv)
kdb_set(2, setargs);
}
 
-   kmsg_dump_rewind();
-   while (kmsg_dump_get_line(, 1, NULL, 0, NULL))
+   kmsg_dump_rewind_nolock();
+   while (kmsg_dump_get_line_nolock(, 1, NULL, 0, NULL))
n++;
 
if (lines < 0) {
@@ -2105,8 +2105,8 @@ static int kdb_dmesg(int argc, const char **argv)
if (skip >= n || skip < 0)
return 0;
 
-   kmsg_dump_rewind();
-   while (kmsg_dump_get_line(, 1, buf, sizeof(buf), )) {
+   kmsg_dump_rewind_nolock();
+   while (kmsg_dump_get_line_nolock(, 1, buf, sizeof(buf), )) {
if (skip) {
skip--;
continue;
-- 
1.7.10.4
--
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/4] printk: Implement some unlocked kmsg_dump functions

[Anton Vorontsov]

If used from KDB, the locked variants are prone to deadlocks (suppose we
got to the debugger w/ the logbuf lock held).

So, we have to implement a few routines that grab no logbuf lock.

Yet we don't need these functions in modules, so we don't export them.

Signed-off-by: Anton Vorontsov 
---
 include/linux/kmsg_dump.h |   16 +++
 kernel/printk.c   |   68 -
 2 files changed, 71 insertions(+), 13 deletions(-)

diff --git a/include/linux/kmsg_dump.h b/include/linux/kmsg_dump.h
index d6bd501..2e7a1e0 100644
--- a/include/linux/kmsg_dump.h
+++ b/include/linux/kmsg_dump.h
@@ -55,12 +55,17 @@ struct kmsg_dumper {
 #ifdef CONFIG_PRINTK
 void kmsg_dump(enum kmsg_dump_reason reason);
 
+bool kmsg_dump_get_line_nolock(struct kmsg_dumper *dumper, bool syslog,
+  char *line, size_t size, size_t *len);
+
 bool kmsg_dump_get_line(struct kmsg_dumper *dumper, bool syslog,
char *line, size_t size, size_t *len);
 
 bool kmsg_dump_get_buffer(struct kmsg_dumper *dumper, bool syslog,
  char *buf, size_t size, size_t *len);
 
+void kmsg_dump_rewind_nolock(struct kmsg_dumper *dumper);
+
 void kmsg_dump_rewind(struct kmsg_dumper *dumper);
 
 int kmsg_dump_register(struct kmsg_dumper *dumper);
@@ -71,6 +76,13 @@ static inline void kmsg_dump(enum kmsg_dump_reason reason)
 {
 }
 
+static inline bool kmsg_dump_get_line_nolock(struct kmsg_dumper *dumper,
+bool syslog, const char *line,
+size_t size, size_t *len)
+{
+   return false;
+}
+
 static inline bool kmsg_dump_get_line(struct kmsg_dumper *dumper, bool syslog,
const char *line, size_t size, size_t *len)
 {
@@ -83,6 +95,10 @@ static inline bool kmsg_dump_get_buffer(struct kmsg_dumper 
*dumper, bool syslog,
return false;
 }
 
+static inline void kmsg_dump_rewind_nolock(struct kmsg_dumper *dumper)
+{
+}
+
 static inline void kmsg_dump_rewind(struct kmsg_dumper *dumper)
 {
 }
diff --git a/kernel/printk.c b/kernel/printk.c
index c812967..ac4bc9e 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -2510,7 +2510,7 @@ void kmsg_dump(enum kmsg_dump_reason reason)
 }
 
 /**
- * kmsg_dump_get_line - retrieve one kmsg log line
+ * kmsg_dump_get_line_nolock - retrieve one kmsg log line (unlocked version)
  * @dumper: registered kmsg dumper
  * @syslog: include the "<4>" prefixes
  * @line: buffer to copy the line to
@@ -2525,11 +2525,12 @@ void kmsg_dump(enum kmsg_dump_reason reason)
  *
  * A return value of FALSE indicates that there are no more records to
  * read.
+ *
+ * The function is similar to kmsg_dump_get_line(), but grabs no locks.
  */
-bool kmsg_dump_get_line(struct kmsg_dumper *dumper, bool syslog,
-   char *line, size_t size, size_t *len)
+bool kmsg_dump_get_line_nolock(struct kmsg_dumper *dumper, bool syslog,
+  char *line, size_t size, size_t *len)
 {
-   unsigned long flags;
struct log *msg;
size_t l = 0;
bool ret = false;
@@ -2537,7 +2538,6 @@ bool kmsg_dump_get_line(struct kmsg_dumper *dumper, bool 
syslog,
if (!dumper->active)
goto out;
 
-   raw_spin_lock_irqsave(_lock, flags);
if (dumper->cur_seq < log_first_seq) {
/* messages are gone, move to first available one */
dumper->cur_seq = log_first_seq;
@@ -2545,10 +2545,8 @@ bool kmsg_dump_get_line(struct kmsg_dumper *dumper, bool 
syslog,
}
 
/* last entry */
-   if (dumper->cur_seq >= log_next_seq) {
-   raw_spin_unlock_irqrestore(_lock, flags);
+   if (dumper->cur_seq >= log_next_seq)
goto out;
-   }
 
msg = log_from_idx(dumper->cur_idx);
l = msg_print_text(msg, 0, syslog, line, size);
@@ -2556,12 +2554,41 @@ bool kmsg_dump_get_line(struct kmsg_dumper *dumper, 
bool syslog,
dumper->cur_idx = log_next(dumper->cur_idx);
dumper->cur_seq++;
ret = true;
-   raw_spin_unlock_irqrestore(_lock, flags);
 out:
if (len)
*len = l;
return ret;
 }
+
+/**
+ * kmsg_dump_get_line - retrieve one kmsg log line
+ * @dumper: registered kmsg dumper
+ * @syslog: include the "<4>" prefixes
+ * @line: buffer to copy the line to
+ * @size: maximum size of the buffer
+ * @len: length of line placed into buffer
+ *
+ * Start at the beginning of the kmsg buffer, with the oldest kmsg
+ * record, and copy one record into the provided buffer.
+ *
+ * Consecutive calls will return the next available record moving
+ * towards the end of the buffer with the youngest messages.
+ *
+ * A return value of FALSE indicates that there are no more records to
+ * read.
+ */
+bool kmsg_dump_get_line(struct kmsg_dumper *dumper, bool syslog,
+   char *line, size_t size, size_t *len)
+{
+   unsigned long 

[PATCH 2/4] printk: Remove kdb_syslog_data

[Anton Vorontsov]

The function is no longer needed, so remove it.

Signed-off-by: Anton Vorontsov 
---
 kernel/debug/kdb/kdb_private.h |1 -
 kernel/printk.c|   15 ---
 2 files changed, 16 deletions(-)

diff --git a/kernel/debug/kdb/kdb_private.h b/kernel/debug/kdb/kdb_private.h
index 47c4e56..392ec6a 100644
--- a/kernel/debug/kdb/kdb_private.h
+++ b/kernel/debug/kdb/kdb_private.h
@@ -205,7 +205,6 @@ extern char kdb_grep_string[];
 extern int kdb_grep_leading;
 extern int kdb_grep_trailing;
 extern char *kdb_cmds[];
-extern void kdb_syslog_data(char *syslog_data[]);
 extern unsigned long kdb_task_state_string(const char *);
 extern char kdb_task_state_char (const struct task_struct *);
 extern unsigned long kdb_task_state(const struct task_struct *p,
diff --git a/kernel/printk.c b/kernel/printk.c
index 177fa49..c812967 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -1192,21 +1192,6 @@ SYSCALL_DEFINE3(syslog, int, type, char __user *, buf, 
int, len)
return do_syslog(type, buf, len, SYSLOG_FROM_CALL);
 }
 
-#ifdef CONFIG_KGDB_KDB
-/* kdb dmesg command needs access to the syslog buffer.  do_syslog()
- * uses locks so it cannot be used during debugging.  Just tell kdb
- * where the start and end of the physical and logical logs are.  This
- * is equivalent to do_syslog(3).
- */
-void kdb_syslog_data(char *syslog_data[4])
-{
-   syslog_data[0] = log_buf;
-   syslog_data[1] = log_buf + log_buf_len;
-   syslog_data[2] = log_buf + log_first_idx;
-   syslog_data[3] = log_buf + log_next_idx;
-}
-#endif /* CONFIG_KGDB_KDB */
-
 static bool __read_mostly ignore_loglevel;
 
 static int __init ignore_loglevel_setup(char *str)
-- 
1.7.10.4

--
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 for-3.5 1/4] kdb: Revive dmesg command

[Anton Vorontsov]

dmesg command appears to be broken after the printk rework. The old logic
in kdb code makes no sense in terms of current printk/logging storage
format, and KDB simply hangs forever.

This patch revives the command by switching to kmsg_dumper iterator.

The code is now much more simpler and shorter.

Signed-off-by: Anton Vorontsov 
---
 kernel/debug/kdb/kdb_main.c |   91 ---
 1 file changed, 33 insertions(+), 58 deletions(-)

diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
index 67b847d..df17c93 100644
--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2040,8 +2041,15 @@ static int kdb_env(int argc, const char **argv)
  */
 static int kdb_dmesg(int argc, const char **argv)
 {
-   char *syslog_data[4], *start, *end, c = '\0', *p;
-   int diag, logging, logsize, lines = 0, adjust = 0, n;
+   int diag;
+   int logging;
+   int lines = 0;
+   int adjust = 0;
+   int n = 0;
+   int skip = 0;
+   struct kmsg_dumper dumper = { .active = 1 };
+   size_t len;
+   char buf[201];
 
if (argc > 2)
return KDB_ARGCOUNT;
@@ -2064,22 +2072,10 @@ static int kdb_dmesg(int argc, const char **argv)
kdb_set(2, setargs);
}
 
-   /* syslog_data[0,1] physical start, end+1.  syslog_data[2,3]
-* logical start, end+1. */
-   kdb_syslog_data(syslog_data);
-   if (syslog_data[2] == syslog_data[3])
-   return 0;
-   logsize = syslog_data[1] - syslog_data[0];
-   start = syslog_data[2];
-   end = syslog_data[3];
-#define KDB_WRAP(p) (((p - syslog_data[0]) % logsize) + syslog_data[0])
-   for (n = 0, p = start; p < end; ++p) {
-   c = *KDB_WRAP(p);
-   if (c == '\n')
-   ++n;
-   }
-   if (c != '\n')
-   ++n;
+   kmsg_dump_rewind();
+   while (kmsg_dump_get_line(, 1, NULL, 0, NULL))
+   n++;
+
if (lines < 0) {
if (adjust >= n)
kdb_printf("buffer only contains %d lines, nothing "
@@ -2087,21 +2083,11 @@ static int kdb_dmesg(int argc, const char **argv)
else if (adjust - lines >= n)
kdb_printf("buffer only contains %d lines, last %d "
   "lines printed\n", n, n - adjust);
-   if (adjust) {
-   for (; start < end && adjust; ++start) {
-   if (*KDB_WRAP(start) == '\n')
-   --adjust;
-   }
-   if (start < end)
-   ++start;
-   }
-   for (p = start; p < end && lines; ++p) {
-   if (*KDB_WRAP(p) == '\n')
-   ++lines;
-   }
-   end = p;
+   skip = adjust;
+   lines = abs(lines);
} else if (lines > 0) {
-   int skip = n - (adjust + lines);
+   skip = n - lines - adjust;
+   lines = abs(lines);
if (adjust >= n) {
kdb_printf("buffer only contains %d lines, "
   "nothing printed\n", n);
@@ -2112,35 +2098,24 @@ static int kdb_dmesg(int argc, const char **argv)
kdb_printf("buffer only contains %d lines, first "
   "%d lines printed\n", n, lines);
}
-   for (; start < end && skip; ++start) {
-   if (*KDB_WRAP(start) == '\n')
-   --skip;
-   }
-   for (p = start; p < end && lines; ++p) {
-   if (*KDB_WRAP(p) == '\n')
-   --lines;
-   }
-   end = p;
+   } else {
+   lines = n;
}
-   /* Do a line at a time (max 200 chars) to reduce protocol overhead */
-   c = '\n';
-   while (start != end) {
-   char buf[201];
-   p = buf;
-   if (KDB_FLAG(CMD_INTERRUPT))
-   return 0;
-   while (start < end && (c = *KDB_WRAP(start)) &&
-  (p - buf) < sizeof(buf)-1) {
-   ++start;
-   *p++ = c;
-   if (c == '\n')
-   break;
+
+   if (skip >= n || skip < 0)
+   return 0;
+
+   kmsg_dump_rewind();
+   while (kmsg_dump_get_line(, 1, buf, sizeof(buf), )) {
+   if (skip) {
+   skip--;
+   continue;
}
-   *p = '\0';
-   kdb_printf("%s", buf);
+   if (!lines--)
+   break;
+
+   

[PATCH 0/4] KDB: Fix dmesg command

[Anton Vorontsov]

Hi all,

The dmesg command appears to be broken after the printk rework. The old
logic in the kdb code makes no sense in terms of current printk/logging
storage format, and KDB simply hangs forever upon entering 'dmesg'
command.

The first patch revives the command by switching to kmsg_dumper iterator.
As a side-effect, the code is now much more simpler.

A few changes were needed in the printk.c: we needed unlocked variant
of the kmsg_dumper iterator, but these can surely wait for 3.6.

It's probably too late even for the first patch to go to 3.5, but
I'll try to convince otherwise. :-) Here we go:

- The current code is broken for sure, and has no hope to work at
  all. It is a regression;
- The new code works for me, and probably works for everyone else;
- If it compiles (and I urge everyone to compile-test it on your
  setup), it hardly can make things worse.

Thanks!

--
 include/linux/kmsg_dump.h  |   16 +++
 kernel/debug/kdb/kdb_main.c|   91 +++-
 kernel/debug/kdb/kdb_private.h |1 -
 kernel/printk.c|   83 +++-
 4 files changed, 104 insertions(+), 87 deletions(-)

-- 
Anton Vorontsov
Email: cbouatmai...@gmail.com
--
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/5] perf gtk/browser: Use hist_period_print functions

[Namhyung Kim]

On Fri, Jul 20, 2012 at 10:43 PM, Pekka Enberg  wrote:
> On Thu, Jul 19, 2012 at 6:42 PM, Namhyung Kim  wrote:
>> Now we can support color using pango markup with this change.
>>
>> Signed-off-by: Namhyung Kim 
>
> Can you please CC me on perf GTK patches?
>

Sorry, I'll do that in the future. :)


> [snip]
>
>> +#define HPP_COLOR_FN(_name, _field) 
>>\
>
> Where does this "hpp" naming convention come from? What does it stand for?

It's the hist_period_print as the subject said, though I'm not happy
with the name.
I'm open to a better name suggestion.

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/

[tip:x86/efi] x86, efi: Handover Protocol

[tip-bot for Matt Fleming]

Commit-ID:  9ca8f72a9297f2052d806bde176533aa69bd
Gitweb: http://git.kernel.org/tip/9ca8f72a9297f2052d806bde176533aa69bd
Author: Matt Fleming 
AuthorDate: Thu, 19 Jul 2012 10:23:48 +0100
Committer:  H. Peter Anvin 
CommitDate: Fri, 20 Jul 2012 16:18:58 -0700

x86, efi: Handover Protocol

As things currently stand, traditional EFI boot loaders and the EFI
boot stub are carrying essentially the same initialisation code
required to setup an EFI machine for booting a kernel. There's really
no need to have this code in two places and the hope is that, with
this new protocol, initialisation and booting of the kernel can be
left solely to the kernel's EFI boot stub. The responsibilities of the
boot loader then become,

   o Loading the kernel image from boot media

File system code still needs to be carried by boot loaders for the
scenario where the kernel and initrd files reside on a file system
that the EFI firmware doesn't natively understand, such as ext4, etc.

   o Providing a user interface

Boot loaders still need to display any menus/interfaces, for example
to allow the user to select from a list of kernels.

Bump the boot protocol number because we added the 'handover_offset'
field to indicate the location of the handover protocol entry point.

Cc: H. Peter Anvin 
Cc: Peter Jones 
Cc: Ingo Molnar 
Signed-off-by: Matt Fleming 
Acked-and-Tested-by: Matthew Garrett 
Link: 
http://lkml.kernel.org/r/1342689828-16815-1-git-send-email-m...@console-pimps.org
Signed-off-by: H. Peter Anvin 
---
 Documentation/x86/boot.txt |   41 
 arch/x86/boot/compressed/eboot.c   |  198 ++--
 arch/x86/boot/compressed/head_32.S |   10 ++
 arch/x86/boot/compressed/head_64.S |   10 ++
 arch/x86/boot/header.S |4 +-
 arch/x86/include/asm/bootparam.h   |1 +
 6 files changed, 185 insertions(+), 79 deletions(-)

diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index 7c3a880..c6539a4 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt
@@ -54,6 +54,9 @@ Protocol 2.10:(Kernel 2.6.31) Added a protocol for 
relaxed alignment
beyond the kernel_alignment added, new init_size and
pref_address fields.  Added extended boot loader IDs.
 
+Protocol 2.11: (Kernel 3.6) Added a field for offset of EFI handover
+   protocol entry point.
+
  MEMORY LAYOUT
 
 The traditional memory map for the kernel loader, used for Image or
@@ -189,6 +192,7 @@ Offset  Proto   NameMeaning
of struct setup_data
 0258/8 2.10+   pref_addressPreferred loading address
 0260/4 2.10+   init_size   Linear memory required during initialization
+0264/4 2.11+   handover_offset Offset of handover entry point
 
 (1) For backwards compatibility, if the setup_sects field contains 0, the
 real value is 4.
@@ -690,6 +694,16 @@ Offset/size:   0x260/4
   else
runtime_start = pref_address
 
+Field name:handover_offset
+Type:  read
+Offset/size:   0x264/4
+
+  This field is the offset from the beginning of the kernel image to
+  the EFI handover protocol entry point. Boot loaders using the EFI
+  handover protocol to boot the kernel should jump to this offset.
+
+  See EFI HANDOVER PROTOCOL below for more details.
+
 
  THE IMAGE CHECKSUM
 
@@ -1010,3 +1024,30 @@ segment; __BOOS_CS must have execute/read permission, 
and __BOOT_DS
 must have read/write permission; CS must be __BOOT_CS and DS, ES, SS
 must be __BOOT_DS; interrupt must be disabled; %esi must hold the base
 address of the struct boot_params; %ebp, %edi and %ebx must be zero.
+
+ EFI HANDOVER PROTOCOL
+
+This protocol allows boot loaders to defer initialisation to the EFI
+boot stub. The boot loader is required to load the kernel/initrd(s)
+from the boot media and jump to the EFI handover protocol entry point
+which is hdr->handover_offset bytes from the beginning of
+startup_{32,64}.
+
+The function prototype for the handover entry point looks like this,
+
+efi_main(void *handle, efi_system_table_t *table, struct boot_params *bp)
+
+'handle' is the EFI image handle passed to the boot loader by the EFI
+firmware, 'table' is the EFI system table - these are the first two
+arguments of the "handoff state" as described in section 2.3 of the
+UEFI specification. 'bp' is the boot loader-allocated boot params.
+
+The boot loader *must* fill out the following fields in bp,
+
+o hdr.code32_start
+o hdr.cmd_line_ptr
+o hdr.cmdline_size
+o hdr.ramdisk_image (if applicable)
+o hdr.ramdisk_size  (if applicable)
+
+All other fields should be zero.
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 4e85f5f..b3e0227 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -729,32 +729,68 @@ fail:
  * need to create one ourselves (usually the bootloader would create
  * one for us).
  

Re: perf with precise attribute kills all KVM based VMs

[David Ahern]

On 7/9/12 8:47 AM, Peter Zijlstra wrote:

On Mon, 2012-07-09 at 17:39 +0300, Avi Kivity wrote:

Disabling PEBS events for guests isn't pretty though..


We already have atomic MSR switching at guest entry/exit time.  So it's
not pretty in terms of not getting full profiling, but the code won't be
too hard.  Basically we just have to exclude_guest any pebs event.


OK, so ideally we'd do something like the below, except of course that
that isn't backwards compatible and will break the world :/

bugger that

---
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -336,6 +338,9 @@ int x86_setup_perfctr(struct perf_event *event)
 /* BTS is currently only allowed for user-mode. */
 if (!attr->exclude_kernel)
 return -EOPNOTSUPP;
+
+   if (!attr->exclude_guest)
+   return -EOPNOTSUPP;
 }

 hwc->config |= config;
@@ -378,6 +383,9 @@ int x86_pmu_hw_config(struct perf_event *event)
 if (event->attr.precise_ip) {
 int precise = 0;

+   if (!event->attr.exclude_guest)
+   return -EOPNOTSUPP;
+
 /* Support for constant skid */
 if (x86_pmu.pebs_active && !x86_pmu.pebs_broken) {
 precise++;



Tested-by: David Ahern 

Gleb's patch is required as well. It takes both to fix the problem. And 
my userspace patch keeps compatibility for users who currently use -e 
cycles:pp (they won't be forced to add 'H'). (lkml is slow to show it so 
I can't pull a link for reference, but it's in your email ahead of this 
one).


Be nice to get this set into stable releases as well.
--
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 with precise attribute kills all KVM based VMs

[David Ahern]

On 7/11/12 1:10 AM, Gleb Natapov wrote:

Looks like Avi is right about the overshoot. Can you test something like this?

diff --git a/arch/x86/kernel/cpu/perf_event_intel.c 
b/arch/x86/kernel/cpu/perf_event_intel.c
index 166546e..5fb371a 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -1374,8 +1374,11 @@ static struct perf_guest_switch_msr 
*intel_guest_get_msrs(int *nr)
arr[0].msr = MSR_CORE_PERF_GLOBAL_CTRL;
arr[0].host = x86_pmu.intel_ctrl & ~cpuc->intel_ctrl_guest_mask;
arr[0].guest = x86_pmu.intel_ctrl & ~cpuc->intel_ctrl_host_mask;
+   arr[1].msr = MSR_IA32_PEBS_ENABLE;
+   arr[1].host = cpuc->pebs_enabled;
+   arr[1].guest = 0;
+   *nr = 2;

-   *nr = 1;
return arr;
  }



Tested-by: David Ahern 

Peter's patch is required as well. It's the combination that fixes the 
problem.


David
--
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 RFT] net: Change niu_rbr_fill() to use unlikely() to check niu_rbr_add_page() return value

[Shuah Khan]

Change niu_rbr_fill() to use unlikely() to check niu_rbr_add_page() return
value to be consistent with the rest of the checks after niu_rbr_add_page()
calls in this file.

Signed-off-by: Shuah Khan 
---
 drivers/net/ethernet/sun/niu.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c
index 60d5c03..c2a0fe3 100644
--- a/drivers/net/ethernet/sun/niu.c
+++ b/drivers/net/ethernet/sun/niu.c
@@ -3517,7 +3517,7 @@ static int niu_rbr_fill(struct niu *np, struct 
rx_ring_info *rp, gfp_t mask)
err = 0;
while (index < (rp->rbr_table_size - blocks_per_page)) {
err = niu_rbr_add_page(np, rp, mask, index);
-   if (err)
+   if (unlikely(err))
break;
 
index += blocks_per_page;
-- 
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/

mmotm 2012-07-20-16-30 uploaded

[akpm]

The mm-of-the-moment snapshot 2012-07-20-16-30 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (3.x
or 3.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at https://github.com/mstsxfx/memcg-devel.git by Michal Hocko. 
It contains the patches which are between the "#NEXT_PATCHES_START mm" and
"#NEXT_PATCHES_END" markers, from the series file,
http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/?p=linux-mmotm.git;a=summary

To develop on top of mmotm git:

  $ git remote add mmotm git://git.cmpxchg.org/linux-mmotm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/?p=linux-mmots.git;a=summary

and use of this tree is similar to
http://git.cmpxchg.org/?p=linux-mmotm.git, described above.


This mmotm tree contains the following patches against 3.5-rc7:
(patches marked "*" will be included in linux-next)

  origin.patch
  linux-next.patch
  linux-next-git-rejects.patch
  i-need-old-gcc.patch
  arch-alpha-kernel-systblss-remove-debug-check.patch
  thermal-constify-type-argument-for-the-registration-routine.patch
  drivers-base-ddc-debork.patch
* fs-gfs2-filec-fix-32-bit-build.patch
* mm-fix-wrong-argument-of-migrate_huge_pages-in-soft_offline_huge_page.patch
* pcdp-use-early_ioremap-early_iounmap-to-access-pcdp-table.patch
* cciss-fix-incorrect-scsi-status-reporting.patch
* 
acpi_memhotplugc-fix-memory-leak-when-memory-device-is-unbound-from-the-module-acpi_memhotplug.patch
* acpi_memhotplugc-free-memory-device-if-acpi_memory_enable_device-failed.patch
* acpi_memhotplugc-remove-memory-info-from-list-before-freeing-it.patch
* 
acpi_memhotplugc-dont-allow-to-eject-the-memory-device-if-it-is-being-used.patch
* acpi_memhotplugc-bind-the-memory-device-when-the-driver-is-being-loaded.patch
* 
acpi_memhotplugc-auto-bind-the-memory-device-which-is-hotplugged-before-the-driver-is-loaded.patch
* 
arch-x86-platform-iris-irisc-register-a-platform-device-and-a-platform-driver.patch
* arch-x86-include-asm-spinlockh-fix-comment.patch
* 
arch-x86-kernel-cpu-perf_event_intel_uncoreh-make-uncore_pmu_hrtimer_interval-64-bit.patch
* mn10300-only-add-mmem-funcs-to-kbuild_cflags-if-gcc-supports-it.patch
* dma-dmaengine-lower-the-priority-of-failed-to-get-dma-channel-message.patch
* prctl-remove-redunant-assignment-of-error-to-zero.patch
  cyber2000fb-avoid-palette-corruption-at-higher-clocks.patch
* timeconstpl-remove-deprecated-defined-array.patch
* time-dont-inline-export_symbol-functions.patch
* thermal-fix-potential-out-of-bounds-memory-access.patch
* thermal-add-renesas-r-car-thermal-sensor-support.patch
* thermal-add-generic-cpufreq-cooling-implementation.patch
* hwmon-exynos4-move-thermal-sensor-driver-to-driver-thermal-directory.patch
* thermal-exynos5-add-exynos5-thermal-sensor-driver-support.patch
* thermal-exynos-register-the-tmu-sensor-with-the-kernel-thermal-layer.patch
* arm-exynos-add-thermal-sensor-driver-platform-data-support.patch
* ocfs2-use-find_last_bit.patch
* ocfs2-use-bitmap_weight.patch
* drivers-scsi-atp870uc-fix-bad-use-of-udelay.patch
* vfs-increment-iversion-when-a-file-is-truncated.patch
* fs-push-rcu_barrier-from-deactivate_locked_super-to-filesystems.patch
* fs-xattrc-getxattr-improve-handling-of-allocation-failures.patch
* fs-make-dumpable=2-require-fully-qualified-path.patch
* coredump-warn-about-unsafe-suid_dumpable-core_pattern-combo.patch
* xtensa-mm-faultc-port-oom-changes-to-do_page_fault.patch
* 

[PATCH 02/11] perf kvm: set name for VM process in guest machine

[David Ahern]

COMM events are not generated in the context of a guest machine, so the
thread name is never set for the VMM process. For example, the qemu-kvm
name applies to the process in the host machine, not the guest machine.
So, samples for guest machines are currently displayed as:

99.67% :5671  [unknown] [g] 0x81366b41

where 5671 is the pid of the VMM. With this patch the samples in the guest
machine are shown as:

18.43%  [guest/5671]  [unknown]   [g] 0x810d68b7

Signed-off-by: David Ahern 
Cc: Arnaldo Carvalho de Melo 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Frederic Weisbecker 
Cc: Peter Zijlstra 
---
 tools/perf/util/map.c |   17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index a1f4e36..8668569 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include "map.h"
+#include "thread.h"
 
 const char *map_type__name[MAP__NR_TYPES] = {
[MAP__FUNCTION] = "Functions",
@@ -585,7 +586,21 @@ int machine__init(struct machine *self, const char 
*root_dir, pid_t pid)
self->kmaps.machine = self;
self->pid   = pid;
self->root_dir  = strdup(root_dir);
-   return self->root_dir == NULL ? -ENOMEM : 0;
+   if (self->root_dir == NULL)
+   return -ENOMEM;
+
+   if (pid != HOST_KERNEL_ID) {
+   struct thread *thread = machine__findnew_thread(self, pid);
+   char comm[64];
+
+   if (thread == NULL)
+   return -ENOMEM;
+
+   snprintf(comm, sizeof(comm), "[guest/%d]", pid);
+   thread__set_comm(thread, comm);
+   }
+
+   return 0;
 }
 
 static void dsos__delete(struct list_head *self)
-- 
1.7.10.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 06/11] perf kvm: limit repetitive guestmount message to once per directory

[David Ahern]

After 7ed97ad use of the guestmount option without a subdir for *each*
VM generates an error message for each sample related to that VM. Once
per VM is enough.

Signed-off-by: David Ahern 
Cc: Arnaldo Carvalho de Melo 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Frederic Weisbecker 
Cc: Peter Zijlstra 
---
 tools/perf/util/map.c |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 16d783d..cc33486 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -8,6 +8,7 @@
 #include 
 #include "map.h"
 #include "thread.h"
+#include "strlist.h"
 
 const char *map_type__name[MAP__NR_TYPES] = {
[MAP__FUNCTION] = "Functions",
@@ -695,7 +696,15 @@ struct machine *machines__findnew(struct rb_root *self, 
pid_t pid)
(symbol_conf.guestmount)) {
sprintf(path, "%s/%d", symbol_conf.guestmount, pid);
if (access(path, R_OK)) {
-   pr_err("Can't access file %s\n", path);
+   static struct strlist *seen;
+
+   if (!seen)
+   seen = strlist__new(true, NULL);
+
+   if (!strlist__has_entry(seen, path)) {
+   pr_err("Can't access file %s\n", path);
+   strlist__add(seen, path);
+   }
machine = NULL;
goto out;
}
-- 
1.7.10.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 07/11] perf tools: dump exclude_{guest,host}, precise_ip header info too

[David Ahern]

Adds the attributes to the event line in the header dump.
From:
 event : name = cycles, type = 0, config = 0x0, config1 = 0x0,
  config2 = 0x0, excl_usr = 0, excl_kern = 0, ...
to
  event : name = cycles, type = 0, config = 0x0, config1 = 0x0,
  config2 = 0x0, excl_usr = 0, excl_kern = 0, excl_host = 0,
  excl_guest = 0, precise_ip = 0, ...

Signed-off-by: David Ahern 
Cc: Arnaldo Carvalho de Melo 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Frederic Weisbecker 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
---
 tools/perf/util/header.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 5a47aba..3a6d204 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -1212,6 +1212,12 @@ static void print_event_desc(struct perf_header *ph, int 
fd, FILE *fp)
attr.exclude_user,
attr.exclude_kernel);
 
+   fprintf(fp, ", excl_host = %d, excl_guest = %d",
+   attr.exclude_host,
+   attr.exclude_guest);
+
+   fprintf(fp, ", precise_ip = %d", attr.precise_ip);
+
if (nr)
fprintf(fp, ", id = {");
 
-- 
1.7.10.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 03/11] perf kvm: guest userspace samples should not be lumped with host uspace

[David Ahern]

e.g., perf kvm --host  --guest report -i perf.data --stdio -D
shows:

1 599127912065356 0x143b8 [0x48]: PERF_RECORD_SAMPLE(IP, 5): 5671/5676: 
0x7fdf95a061c0 period: 1 addr: 0
... chain: nr:2
.  0: ff80
.  1: fe00
 ... thread: qemu-kvm:5671
 .. dso: 

(IP, 5) means sample in guest userspace. Those samples should not be lumped
into the VMM's host thread. i.e, the report output:

56.86%  qemu-kvm  [unknown] [u] 0x7fdf95a061c0

With this patch the output emphasizes it is a guest userspace hit:

56.86%  [guest/5671]  [unknown] [u] 0x7fdf95a061c0

Looking at 3 VMs (2 64-bit, 1 32-bit) with each running a CPU bound
process (openssl speed), perf report currently shows:

  93.84%  117726   qemu-kvm  [unknown]   [u] 0x7fd7dcaea8e5

which is wrong. With this patch you get:

  31.50%   39258   [guest/18772]  [unknown]   [u] 0x7fd7dcaea8e5
  31.50%   39236   [guest/11230]  [unknown]   [u] 0x00a57340
  30.84%   39232   [guest/18395]  [unknown]   [u] 0x7f66f641e107

Signed-off-by: David Ahern 
Cc: Arnaldo Carvalho de Melo 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Frederic Weisbecker 
Cc: Peter Zijlstra 
---
 tools/perf/util/session.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 8e48559..90ee39d 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -918,7 +918,9 @@ static struct machine *
 {
const u8 cpumode = event->header.misc & PERF_RECORD_MISC_CPUMODE_MASK;
 
-   if (cpumode == PERF_RECORD_MISC_GUEST_KERNEL && perf_guest) {
+   if (perf_guest &&
+   ((cpumode == PERF_RECORD_MISC_GUEST_KERNEL) ||
+(cpumode == PERF_RECORD_MISC_GUEST_USER))) {
u32 pid;
 
if (event->header.type == PERF_RECORD_MMAP)
-- 
1.7.10.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 00/11] perf tool: assorted cleanups and bug fixes

[David Ahern]

Arnaldo:

Welcome back from vacation. Some cleanups and bug fixes for 3.6.
Patch 8 should apply to stable if Gleb's and Peter's patches
are backported as well.
 

David Ahern (11):
  perf tool: add machine id to modules debug message
  perf kvm: set name for VM process in guest machine
  perf kvm: guest userspace samples should not be lumped with host
uspace
  perf kvm: fix bug resolving guest kernel syms - v2
  perf kvm: use strtol for walking guestmount directory
  perf kvm: limit repetitive guestmount message to once per directory
  perf tools: dump exclude_{guest,host}, precise_ip header info too
  perf tool: precise mode requires exclude_guest
  perf top: error handling for counter creation should parallel
perf-record
  perf tool: give user better message if precise is not supported
  perf kvm top: limit guest kernel info message to once

 tools/perf/builtin-record.c|4 
 tools/perf/builtin-top.c   |   24 +++
 tools/perf/util/header.c   |6 ++
 tools/perf/util/map.c  |   41 ++--
 tools/perf/util/map.h  |1 +
 tools/perf/util/parse-events.c |3 +++
 tools/perf/util/session.c  |5 -
 tools/perf/util/symbol.c   |   21 +---
 8 files changed, 95 insertions(+), 10 deletions(-)

-- 
1.7.10.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 08/11] perf tool: precise mode requires exclude_guest

[David Ahern]

PEBS cannot be used with guest mode. If user adds :p modifier set
exclude_guest as well.


Signed-off-by: David Ahern 
Cc: Arnaldo Carvalho de Melo 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Frederic Weisbecker 
Cc: Peter Zijlstra 
Cc: Gleb Natapov 
Link: https://lkml.org/lkml/2012/7/9/264
---
 tools/perf/util/parse-events.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 1aa721d..f34629b 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -653,6 +653,9 @@ int parse_events_modifier(struct list_head *list, char *str)
eH = 0;
} else if (*str == 'p') {
precise++;
+   /* use of precise requires exclude_guest */
+   if (!exclude_GH)
+   eG = 1;
} else
break;
 
-- 
1.7.10.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 09/11] perf top: error handling for counter creation should parallel perf-record

[David Ahern]

5a7ed29 fixed up perf-record but not perf-top. Similar argument
holds for it -- fallback to PMU only if it does not exist and handle
invalid attributes separately.

Signed-off-by: David Ahern 
Cc: Arnaldo Carvalho de Melo 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Frederic Weisbecker 
Cc: Peter Zijlstra 
Cc: Robert Richter 
---
 tools/perf/builtin-top.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index e3cab5f..0ce665c 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -943,8 +943,10 @@ try_again:
 * based cpu-clock-tick sw counter, which
 * is always available even if no PMU support:
 */
-   if (attr->type == PERF_TYPE_HARDWARE &&
-   attr->config == PERF_COUNT_HW_CPU_CYCLES) {
+   if ((err == ENOENT || err == ENXIO)
+   && attr->type == PERF_TYPE_HARDWARE
+   && attr->config == PERF_COUNT_HW_CPU_CYCLES) {
+
if (verbose)
ui__warning("Cycles event not 
supported,\n"
"trying to fall back to 
cpu-clock-ticks\n");
-- 
1.7.10.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 11/11] perf kvm top: limit guest kernel info message to once

[David Ahern]

'perf kvm top' shows a continual flurry of:
Can't find guest [5201]'s kernel information

if it can't find the guest info and with a lot of VMs running a user
has no chance of reading them all. Limit message to once per guest.

Signed-off-by: David Ahern 
Cc: Arnaldo Carvalho de Melo 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Frederic Weisbecker 
Cc: Peter Zijlstra 
---
 tools/perf/builtin-top.c |   14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 1706dc9..6285374 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -706,8 +706,18 @@ static void perf_event__process_sample(struct perf_tool 
*tool,
int err;
 
if (!machine && perf_guest) {
-   pr_err("Can't find guest [%d]'s kernel information\n",
-   event->ip.pid);
+   static struct strlist *seen;
+   char pidstr[8];
+
+   if (!seen)
+   seen = strlist__new(true, NULL);
+
+   scnprintf(pidstr, sizeof(pidstr), "%d", event->ip.pid);
+   if (!strlist__has_entry(seen, pidstr)) {
+   pr_err("Can't find guest [%d]'s kernel information\n",
+   event->ip.pid);
+   strlist__add(seen, pidstr);
+   }
return;
}
 
-- 
1.7.10.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 10/11] perf tool: give user better message if precise is not supported

[David Ahern]

If the PEBS is not supported (e.g., a VM) and the precise modifier is
set the user is given a confusing error message:

  $ perf top -e cycles:p

  The sys_perf_event_open() syscall returned with 95 (Operation not supported).
/bin/dmesg may provide additional information.
  No CONFIG_PERF_EVENTS=y kernel support configured?

  $ perf record -e cycles:p -a -- sleep 1

  Error: sys_perf_event_open() syscall returned with 95 (Operation not
supported).  /bin/dmesg may provide additional information.

  Fatal: No hardware sampling interrupt available. No APIC? If so then you can
boot the kernel with the "lapic" boot parameter to force-enable it.

Which in no way conveys the real error. With this patch:
  $ perf top -e cycles:p
  PEBS request not supported. Try removing 'p' modifier

  $ perf record -e cycles:p -a -- sleep 1
  PEBS request not supported. Try removing 'p' modifier

Signed-off-by: David Ahern 
Cc: Arnaldo Carvalho de Melo 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Frederic Weisbecker 
Cc: Peter Zijlstra 
---
 tools/perf/builtin-record.c |4 
 tools/perf/builtin-top.c|4 
 2 files changed, 8 insertions(+)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index f5a6452..911e300 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -267,6 +267,10 @@ try_again:
ui__error("The %s event is not supported.\n",
  perf_evsel__name(pos));
exit(EXIT_FAILURE);
+   } else if ((err == ENOTSUP) && (attr->precise_ip)) {
+   ui__error("PEBS request not supported. "
+ "Try removing 'p' modifier\n");
+   exit(EXIT_FAILURE);
}
 
printf("\n");
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 0ce665c..1706dc9 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -968,6 +968,10 @@ try_again:
ui__error("Too many events are opened.\n"
"Try again after reducing the 
number of events\n");
goto out_err;
+   } else if ((err == ENOTSUP) && (attr->precise_ip)) {
+   ui__error("PEBS request not supported. "
+   "Try removing 'p' modifier\n");
+   goto out_err;
}
 
ui__error("The sys_perf_event_open() syscall "
-- 
1.7.10.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 05/11] perf kvm: use strtol for walking guestmount directory

[David Ahern]

Signed-off-by: David Ahern 
Cc: Arnaldo Carvalho de Melo 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Frederic Weisbecker 
Cc: Peter Zijlstra 
---
 tools/perf/util/symbol.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 6802ef4..968de79 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -2825,6 +2825,7 @@ int machines__create_guest_kernel_maps(struct rb_root 
*machines)
int i, items = 0;
char path[PATH_MAX];
pid_t pid;
+   char *endp;
 
if (symbol_conf.default_guest_vmlinux_name ||
symbol_conf.default_guest_modules ||
@@ -2841,7 +2842,14 @@ int machines__create_guest_kernel_maps(struct rb_root 
*machines)
/* Filter out . and .. */
continue;
}
-   pid = atoi(namelist[i]->d_name);
+   pid = (pid_t) strtol(namelist[i]->d_name, , 10);
+   if ((*endp != '\0') ||
+   (endp == namelist[i]->d_name) ||
+   (errno == ERANGE)) {
+   pr_debug("invalid directory (%s). Skipping.\n",
+namelist[i]->d_name);
+   continue;
+   }
sprintf(path, "%s/%s/proc/kallsyms",
symbol_conf.guestmount,
namelist[i]->d_name);
-- 
1.7.10.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 04/11] perf kvm: fix bug resolving guest kernel syms - v2

[David Ahern]

Guest kernel symbols are not resolved despite passing the information
needed to resolve them. e.g.,

perf kvm --guest --guestmount=/tmp/guest-mount record -a -- sleep 1
perf kvm --guest --guestmount=/tmp/guest-mount report --stdio

36.55%  [guest/11399]  [unknown] [g] 0x81600bc8
33.19%  [guest/10474]  [unknown] [g] 0xc0116e00
30.26%  [guest/11094]  [unknown] [g] 0x8100a288
43.69%  [guest/10474]  [unknown] [g] 0xc0103d90
37.38%  [guest/11399]  [unknown] [g] 0x81600bc8
12.24%  [guest/11094]  [unknown] [g] 0x810aa91d
 6.69%  [guest/11094]  [unknown] [u] 0x7fa784d721c3

which is just pathetic.

After a maddening 2 days sifting through perf minutia I found it --
id_hdr_size is not initialized for guest machines. This shows up on the
report side as random garbage for the cpu and timestamp, e.g.,

29816 7310572949125804849 0x1ac0 [0x50]: PERF_RECORD_MMAP ...

That messes up the sample sorting such that synthesized guest maps are
processed last.

With this patch you get a much more helpful report:

  12.11%  [guest/11399]  [guest.kernel.kallsyms.11399]  [g] 
irqtime_account_process_tick
  10.58%  [guest/11399]  [guest.kernel.kallsyms.11399]  [g] run_timer_softirq
   6.95%  [guest/11094]  [guest.kernel.kallsyms.11094]  [g] printk_needs_cpu
   6.50%  [guest/11094]  [guest.kernel.kallsyms.11094]  [g] do_timer
   6.45%  [guest/11399]  [guest.kernel.kallsyms.11399]  [g] idle_balance
   4.90%  [guest/11094]  [guest.kernel.kallsyms.11094]  [g] native_read_tsc
...

v2:
- changed rbtree walk to use rb_first per Namhyung's suggestion

Signed-off-by: David Ahern 
Cc: Arnaldo Carvalho de Melo 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Frederic Weisbecker 
Cc: Peter Zijlstra 
---
 tools/perf/util/map.c |   13 +
 tools/perf/util/map.h |1 +
 tools/perf/util/session.c |1 +
 3 files changed, 15 insertions(+)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 8668569..16d783d 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -729,3 +729,16 @@ char *machine__mmap_name(struct machine *self, char *bf, 
size_t size)
 
return bf;
 }
+
+void machines__set_id_hdr_size(struct rb_root *machines, u16 id_hdr_size)
+{
+   struct rb_node *node;
+   struct machine *machine;
+
+   for (node = rb_first(machines); node; node = rb_next(node)) {
+   machine = rb_entry(node, struct machine, rb_node);
+   machine->id_hdr_size = id_hdr_size;
+   }
+
+   return;
+}
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index c14c665..03a1e9b 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -151,6 +151,7 @@ struct machine *machines__add(struct rb_root *self, pid_t 
pid,
 struct machine *machines__find_host(struct rb_root *self);
 struct machine *machines__find(struct rb_root *self, pid_t pid);
 struct machine *machines__findnew(struct rb_root *self, pid_t pid);
+void machines__set_id_hdr_size(struct rb_root *self, u16 id_hdr_size);
 char *machine__mmap_name(struct machine *self, char *bf, size_t size);
 int machine__init(struct machine *self, const char *root_dir, pid_t pid);
 void machine__exit(struct machine *self);
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 90ee39d..8e4f075 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -87,6 +87,7 @@ void perf_session__update_sample_type(struct perf_session 
*self)
self->sample_id_all = perf_evlist__sample_id_all(self->evlist);
self->id_hdr_size = perf_evlist__id_hdr_size(self->evlist);
self->host_machine.id_hdr_size = self->id_hdr_size;
+   machines__set_id_hdr_size(>machines, self->id_hdr_size);
 }
 
 int perf_session__create_kernel_maps(struct perf_session *self)
-- 
1.7.10.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 01/11] perf tool: add machine id to modules debug message

[David Ahern]

Current debug message is:
Problems creating module maps, continuing anyway...

When running multiple VMs it would be nice to know which machine the
message is referring to:

$ perf kvm --guest --guestmount=/tmp/guest-mount record -av -- sleep 10
Problems creating module maps for guest 6613, continuing anyway...

Signed-off-by: David Ahern 
Cc: Arnaldo Carvalho de Melo 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Frederic Weisbecker 
Cc: Peter Zijlstra 
---
 tools/perf/util/symbol.c |   11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 90f6951..6802ef4 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -2567,8 +2567,15 @@ int machine__create_kernel_maps(struct machine *machine)
__machine__create_kernel_maps(machine, kernel) < 0)
return -1;
 
-   if (symbol_conf.use_modules && machine__create_modules(machine) < 0)
-   pr_debug("Problems creating module maps, continuing 
anyway...\n");
+   if (symbol_conf.use_modules && machine__create_modules(machine) < 0) {
+   if (machine__is_host(machine))
+   pr_debug("Problems creating module maps, "
+"continuing anyway...\n");
+   else
+   pr_debug("Problems creating module maps for guest %d, "
+"continuing anyway...\n", machine->pid);
+   }
+
/*
 * Now that we have all the maps created, just set the ->end of them:
 */
-- 
1.7.10.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/

Re: [PATCH] forcedeth: spin_unlock_irq in interrupt handler fix

[David Miller]

From: Denis Efremov 
Date: Sat, 21 Jul 2012 01:54:34 +0400

> The replacement of spin_lock_irq/spin_unlock_irq pair in interrupt
> handler by spin_lock_irqsave/spin_lock_irqrestore pair.
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Denis Efremov 

Applied, 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: linux-next: manual merge of the staging tree with the target-merge tree

[Nicholas A. Bellinger]

Hi Greg,

On Fri, 2012-07-20 at 21:42 +0300, Michael S. Tsirkin wrote:
> On Fri, Jul 20, 2012 at 11:03:58AM -0700, Greg KH wrote:
> > On Fri, Jul 20, 2012 at 10:52:58AM -0700, Nicholas A. Bellinger wrote:
> > > Hi Greg,
> > > 



> > > This was a request from MST (CC'ed) in order to have TCM_VHOST show up
> > > under the staging configuration options..
> > 
> > If you really want it to show up there, then send me a patch adding the
> > code to drivers/staging/.  Otherwise it really makes no sense.
> > 
> > > If that's really not what should be done, I'm happy to drop this part
> > > and just use CONFIG_STAGING again.
> > 
> > Why are you wanting to depend on CONFIG_STAGING in the first place?
> > What is wrong with the code that it can't be merged "properly" now?
> > Don't use CONFIG_STAGING as a "crutch" unless you really need it.
> > 
> > thanks,
> > 
> > greg k-h
> 
> It's very similar to how it was with nouveau: we are not sure
> we can commit to the userspace ABI yet.
> 
> Most importantly, it still seems not 100% clear whether this driver will
> have major userspace using it. And if not, it would be very hard to
> support a driver when recent userspace does not use it in the end.
> 
> At the moment arguments on upstream mailing list seem to be
> a bit circular: there's no module in upstream kernel so
> userspace does not want to accept the patches.
> 
> If we put enabling this driver in staging, then it works out in one of
> two ways
> - userspace starts using it then this effectively freezes the ABI and
>   we move it out of staging next release
> - no userspace uses it and we drop it completely or rework ABI
> 
> On the other hand, it is marginally better to not want code in staging
> for two reasons:
> - there are dependencies between this code and other code in
>   drivers/vhost which are easier for me to handle if it's all
>   in one place
> - a bit easier to track history if we do not move code
> 
> What do you think?
> 

After chatting with MST off-list he asked for a RFC-v4 series with one
extra change to vhost.h wrt the vhost-scsi ioctl defs.  He also said he
is OK with taking the first three patches -v4 through vhost.git and
letting staging take tcm_vhost.   Of course we'd need staging to depend
on vhost for that to work  (compile) properly..  ;)

I'd like to re-spin -v4 this evening so that he can review + ACK the
full series before leaving for holiday tomorrow, so please let me know
what you'd prefer to do here.

So that said, do you prefer having tcm_vhost moved into drivers/staging
for -v4, or should we just be using a CONFIG_STAGING tag in
drivers/vhost/ and be done with it..?

Thank you!

--nab

--
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: oops in kernel ( 3.4.x -> 3.5rc )

[nicolas prochazka]

Well done
1fd36adcd98c14d2fd97f545293c488775cb2823  :  the bug occurs   ( cf dump )
1dce27c5aa6770e9d195f2bb7db1db3d4dde5591 :  the bug not occurs

Regards,
Nicolas Prochazka.

dump  / 1fd36adcd98c14d2fd97f545293c488775cb2823
lloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
VMtap: no IPv6 routers present
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 71 not NULL!
alloc_fd: slot 121 not NULL!
alloc_fd: slot 96 not NULL!
alloc_fd: slot 100 not NULL!
alloc_fd: slot 110 not NULL!
alloc_fd: slot 121 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
brE: no IPv6 routers present
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 121 not NULL!
alloc_fd: slot 142 not NULL!
alloc_fd: slot 153 not NULL!
alloc_fd: slot 153 not NULL!
alloc_fd: slot 153 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 70 not NULL!
alloc_fd: slot 100 not NULL!
alloc_fd: slot 102 not NULL!
alloc_fd: slot 36 not NULL!
alloc_fd: slot 36 not NULL!
alloc_fd: slot 36 not NULL!
alloc_fd: slot 36 not NULL!
alloc_fd: slot 36 not NULL!
alloc_fd: slot 106 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 100 not NULL!
alloc_fd: slot 100 not NULL!
alloc_fd: slot 100 not NULL!
alloc_fd: slot 100 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 36 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 106 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 36 not NULL!
alloc_fd: slot 100 not NULL!
alloc_fd: slot 36 not NULL!
alloc_fd: slot 36 not NULL!
alloc_fd: slot 36 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 36 not NULL!
alloc_fd: slot 36 not NULL!
alloc_fd: slot 36 not NULL!
alloc_fd: slot 36 not NULL!
alloc_fd: slot 36 not NULL!
alloc_fd: slot 36 not NULL!
alloc_fd: slot 36 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 100 not NULL!
alloc_fd: slot 100 not NULL!
alloc_fd: slot 100 not NULL!
alloc_fd: slot 100 not NULL!
alloc_fd: slot 100 not NULL!
alloc_fd: slot 100 not NULL!
alloc_fd: slot 100 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 100 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 68 not NULL!
alloc_fd: slot 100 not NULL!
alloc_fd: slot 100 not NULL!
[ cut here ]
kernel BUG at fs/open.c:873!
invalid opcode:  [#1] SMP
CPU 0
Modules linked in: kvm_intel kvm

then BUG paging request as usual


2012/7/20 Thadeu Lima de Souza Cascardo :
> On Fri, Jul 20, 2012 at 10:52:40PM +0200, nicolas prochazka wrote:
>> Hello
>> the problem is occured with  :
>> - linux kernel 3.4.5i do not test with 3.4.0 / 1 / 2 / 3 / 4,
>> but i can if you want
>> - linux kernel 3.5rc6 rc7  / do not test with other rc.
>>
>> the problem is not occured with :
>> linux kernel 3.3.4 / 3.3.8
>>
>> These servers are used for :
>> - starting a lot of virtual machine with qemu-kvm ( ~ 40 )   ( lot of
>> select i think)
>> - do a lot of network tests with openvswitch
>>
>> I can test a kernel 3.4.x before and after a commit id (?) to find a 
>> regression.

gateway icmp redirect handling problem (3.0.36-3.0.23)

[Simon Roscic]

Hello,

I'm experiencing the following problem with kernel versions 3.0.36 
(down to 3.0.23):


on our network we all have one default gateway, it's 10.1.1.254, but 
there are some networks for which we have another gateway and for this 
networks the default gateway sends an icmp redirect.


lets assume my test machine has ip 10.1.20.79 netmask is 255.255.0.0 
and my default gateway is 10.1.1.254, i now ping the following ip: 
10.109.98.11, my default gateway (10.1.1.254) now sends me an icmp 
redirect to another gateway (10.1.1.1) ... and now everything works as 
expected, i get the replies from 10.109.98.11 but not for long, after 
approx. 60 (or so) seconds i only get "ping: sendmsg: Network is down".
(exact same problem with all other tcp/udp protocols, but i used ping 
for the tests because it also prints the redirect messages to the 
console)


so let's have a closer look:

not ok - kernel versions 3.0.36 down to 3.0.23:
---

test-simon:~ # ping 10.109.98.10
...
64 bytes from 10.109.98.11: icmp_seq=62 ttl=60 time=12.1 ms
64 bytes from 10.109.98.11: icmp_seq=63 ttl=60 time=11.6 ms
ping: sendmsg: Network is down
ping: sendmsg: Network is down

when looking at "ip neigh" the "ping: sendmsg: Network is down" message 
appears in the exact moment when the arp entry for the default gateway 
(10.1.1.254) gets removed from the arp cache:


ping "OK"
test-simon:~ # ip neigh
10.1.1.1 dev eth0 lladdr 00:00:0c:9f:f0:64 REACHABLE
10.1.1.254 dev eth0 lladdr 00:1a:64:8f:23:64 STALE

ping "dead"
test-simon:~ # ip neigh
10.1.1.1 dev eth0 lladdr 00:00:0c:9f:f0:64 REACHABLE

so it seems that when the default gateway is removed from the arp cache 
something goes wrong in the kernel route handling. i don't know the 
internals of the linux route handling, now i need your help, any ideas 
what's going wrong?


i did a lot of tests, the problem i described first happens with kernel 
version 3.0.23, i found in the changelog of 3.0.23 the following two 
commits:

(http://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.0.23)

commit 42ab5316ddcaa0de23e88e8a3d363c767b9ab0b3
Author: Eric Dumazet 
Date:   Fri Nov 18 15:24:32 2011 -0500
ipv4: fix redirect handling

commit bebee22bcbf0026f92141990972bd5863ef9b69c
Author: Flavio Leitner 
Date:   Mon Oct 24 02:56:38 2011 -0400
route: fix ICMP redirect validation

i then took the net/ipv4/route.c file from kernel 3.0.22 and replaced 
the version in 3.0.23 with it, this reverts the two mentioned patches 
above (if i havent overlooked something) after that the problem 
disappears.
so those two patches surely fixed some problem but for kernel versions 
3.0.23-3.0.36 they broke the gateway icmp redirect handling as described 
by me here.


i did some further tests with different kernel versions:
3.5-rc6: OK
3.4.4: OK
3.2.22: OK
3.0.1 - 3.0.22: OK
3.0.23 - 3.0.36: not OK
2.6.35.13: OK

now lets have a closer look at a kernel version which works:


this is from 3.5-rc6, but 3.4.4, 3.2.2 and 2.6.35.13 also behave 
exactly this way, 3.0.1-3.0.22 behave slightly different, see note 
below.


test-simon:~ # ping 10.109.98.11
PING 10.109.98.10 (10.109.98.11) 56(84) bytes of data.
64 bytes from 10.109.98.11: icmp_seq=1 ttl=60 time=15.2 ms
From 10.1.1.254: icmp_seq=2 Redirect Host(New nexthop: 10.1.1.1)
...

test-simon:~ # ip neigh
10.1.1.1 dev eth0 lladdr 00:00:0c:9f:f0:64 REACHABLE
10.1.1.254 dev eth0 lladdr 00:1a:64:8f:23:64 STALE

and after approx 60 or so seconds:

test-simon:~ # ip neigh
10.1.1.1 dev eth0 lladdr 00:00:0c:9f:f0:64 REACHABLE

and ping (and everything else) is as expected still working.

note:
-

on 3.0.1-3.0.22:

i see lots of icmp redirects sent from the default gateway (10.1.1.254) 
to my test machine, while running tcpdump on the default gateway 
(10.1.1.254) i see every ping packet also arriving there and also some 
icmp redirect messages going out to my test machine.
but everything works so i think my test machine is correctly talking to 
the destination using the other gateway (10.1.1.1).
i also sniffed a windows 7 client pc, it looks the same there, so 
possibly no problem, but i mention this because kernel versions 3.5-rc6, 
3.4.4, 3.2.22 and 2.6.35.13 act differently (see below).


on 3.0.23-3.0.36:

i see lots of icmp redirects sent from the default gateway (10.1.1.254) 
to my test machine, while running tcpdump on the default gateway 
(10.1.1.254) i see up to 20 ping packets arriving there and also up to 
17 icmp redirect messages going out to my test machine, after the 20th 
ping packet i dont see further ping packets arriving at the default 
gateway. so my test machine is then only talking to the other gateway 
(10.1.1.1) i think.

...
17:48:41.643952 IP 10.1.1.254 > 10.1.20.79: ICMP redirect 10.109.98.11 
to host 10.1.1.1, length 92

...
17:48:44.649008 IP 10.1.20.79 > 10.109.98.11: ICMP echo request, id 
30733, seq 20, length 64
17:48:44.649018 IP 

Re: [PATCH] Shorten constant names for EFI variable attributes

[Khalid Aziz]

On 07/20/2012 04:34 PM, H. Peter Anvin wrote:

On 07/20/2012 03:30 PM, Khalid Aziz wrote:


This patch is based upon earlier discussion at
.

You are right that EFI specification uses exactly these long names for
the constants, but does that mean kernel must also use the exact same
long constant names? I can see doing that for the sake of consistency.
At the same time, can we make the kernel code more readable and retain
compatibility with existing API by using aliases? I slightly prefer
making kernel code more readable, but I could go either way.



I think it makes the kernel code less readable, because now you not 
only need to understand the kernel code and the EFI spec, but also how 
the two maps onto each other. The fact that you then have to introduce 
aliases indicates to me that you're doing something actively broken.


-hpa

As I think more about it, existence of aliases could also potentially 
create confusion where someone adding new code to kernel chooses to use 
the long name instead. Maybe unless we can make a clean break from long 
names, it is not worth doing this and that is going to be problematic 
because of the existing usage in userspace programs.


Matthew, do you have a different point of view?

--
Khalid
khalid.a...@hp.com

--
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: ibmveth bug?

[Nishanth Aravamudan]

Ping on this ... we've tripped the same issue on a different system, it
would appear. Would appreciate if anyone can provide answers to the
questions below.

Thanks,
Nish

On 15.05.2012 [10:01:41 -0700], Nishanth Aravamudan wrote:
> Hi Santiago,
> 
> Are you still working on ibmveth?
> 
> I've found a very sporadic bug with ibmveth in some testing. PAPR
> requires that:
> 
> "Validate the Buffer Descriptor of the receive queue buffer (I/O
> addresses for entire buffer length starting at the spec- ified I/O
> address are translated by the RTCE table, length is a multiple of 16
> bytes, and alignment is on a 16 byte boundary) else H_Parameter."
> 
> but from what I can tell ibmveth.c is not enforcing this last condition:
> 
>   adapter->rx_queue.queue_addr =
>   kmalloc(adapter->rx_queue.queue_len, GFP_KERNEL);
> 
>   ...
> 
>   adapter->rx_queue.queue_dma = dma_map_single(dev,
>   adapter->rx_queue.queue_addr, adapter->rx_queue.queue_len,
>   DMA_BIDIRECTIONAL);
> 
>   ...
> 
>   rxq_desc.fields.address = adapter->rx_queue.queue_dma;
> 
>   ...
>   
> 
>   lpar_rc = ibmveth_register_logical_lan(adapter, rxq_desc,
>   mac_address);
>   netdev_err(netdev, "buffer TCE:0x%llx filter TCE:0x%llx rxq "
>   "desc:0x%llx MAC:0x%llx\n", adapter->buffer_list_dma,
>   adapter->filter_list_dma, rxq_desc.desc, mac_address);
> 
> And I got on one install attempt:
> 
> [ 39.978430] ibmveth 3004: eth0: h_register_logical_lan failed with -4
> [ 39.978449] ibmveth 3004: eth0: buffer TCE:0x1000 filter TCE:0x1 rxq 
> desc:0x8000601200a8 MAC:0x56754de8e904
> 
> rxq desc, as you can see is not 16byte aligned. kmalloc() only
> guarantees 8-byte alignment (as does gcc, I think). Initially, I thought
> we could just overallocate the queue_addr and ALIGN() down, but then we
> would need to save the original kmalloc pointer in a new struct member
> per rx_queue.
> 
> So a couple of questions:
> 
> 1) Is my analysis accurate? :)
> 
> 2) How gross would it be to save an extra pointer for every rx_queue?
> 
> 3) Based upon 2), is it better to just go ahead and create our own
> kmem_cache (which gets an alignment specified)?
> 
> For 3), I started coding this, but couldn't find a clean place to
> allocate the kmem_cache itself, as the size of each object depends on
> the run-time characteristics (afaict), but needs to be specified at
> cache creation time. Any insight you could provide would be great!
> 
> Thanks,
> Nish
>  
> -- 
> Nishanth Aravamudan 
> IBM Linux Technology Center

-- 
Nishanth Aravamudan 
IBM Linux Technology Center

--
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] Shorten constant names for EFI variable attributes

[H. Peter Anvin]

On 07/20/2012 03:30 PM, Khalid Aziz wrote:

On 07/20/2012 04:10 PM, H. Peter Anvin wrote:

On 07/20/2012 03:08 PM, Khalid Aziz wrote:

Replace very long constants for EFI variable attributes
with shorter and more convenient names. Also create an
alias for the current longer names so as to not break
compatibility with current API since these constants
are used by userspace programs. This patch depends on
patch .


I think these some from the EFI specifcation, so NAK IMO.

-hpa


This patch is based upon earlier discussion at
.

You are right that EFI specification uses exactly these long names for
the constants, but does that mean kernel must also use the exact same
long constant names? I can see doing that for the sake of consistency.
At the same time, can we make the kernel code more readable and retain
compatibility with existing API by using aliases? I slightly prefer
making kernel code more readable, but I could go either way.



I think it makes the kernel code less readable, because now you not only 
need to understand the kernel code and the EFI spec, but also how the 
two maps onto each other. The fact that you then have to introduce 
aliases indicates to me that you're doing something actively broken.


-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.



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

[tip:x86/mm] x86/tlb: Fix build warning and crash when building for !SMP

[tip-bot for Alex Shi]

Commit-ID:  7efa1c87963d23cc57ba40c07316d3e28cc75a3a
Gitweb: http://git.kernel.org/tip/7efa1c87963d23cc57ba40c07316d3e28cc75a3a
Author: Alex Shi 
AuthorDate: Fri, 20 Jul 2012 09:18:23 +0800
Committer:  H. Peter Anvin 
CommitDate: Fri, 20 Jul 2012 15:01:48 -0700

x86/tlb: Fix build warning and crash when building for !SMP

The incompatible parameter of flush_tlb_mm_range cause build warning.
Fix it by correct parameter.

Ingo Molnar found that this could also cause a user space crash.

Reported-by: Tetsuo Handa 
Reported-by: Ingo Molnar 
Signed-off-by: Alex Shi 
Link: 
http://lkml.kernel.org/r/1342747103-19765-1-git-send-email-alex@intel.com
Signed-off-by: H. Peter Anvin 
---
 arch/x86/include/asm/tlbflush.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index b5a27bd..74a4433 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -105,10 +105,10 @@ static inline void flush_tlb_range(struct vm_area_struct 
*vma,
__flush_tlb();
 }
 
-static inline void flush_tlb_mm_range(struct vm_area_struct *vma,
+static inline void flush_tlb_mm_range(struct mm_struct *mm,
   unsigned long start, unsigned long end, unsigned long vmflag)
 {
-   if (vma->vm_mm == current->active_mm)
+   if (mm == current->active_mm)
__flush_tlb();
 }
 
--
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] Shorten constant names for EFI variable attributes

[Khalid Aziz]

On 07/20/2012 04:10 PM, H. Peter Anvin wrote:

On 07/20/2012 03:08 PM, Khalid Aziz wrote:

Replace very long constants for EFI variable attributes
with shorter and more convenient names. Also create an
alias for the current longer names so as to not break
compatibility with current API since these constants
are used by userspace programs. This patch depends on
patch .


I think these some from the EFI specifcation, so NAK IMO.

-hpa

This patch is based upon earlier discussion at 
.


You are right that EFI specification uses exactly these long names for 
the constants, but does that mean kernel must also use the exact same 
long constant names? I can see doing that for the sake of consistency. 
At the same time, can we make the kernel code more readable and retain 
compatibility with existing API by using aliases? I slightly prefer 
making kernel code more readable, but I could go either way.


--

Khalid Aziz
khalid.a...@hp.com

--
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 v4 24/25] memcg/slub: shrink dead caches

[Glauber Costa]

On 07/06/2012 12:16 PM, Christoph Lameter wrote:
> On Mon, 18 Jun 2012, Glauber Costa wrote:
> 
>> In the slub allocator, when the last object of a page goes away, we
>> don't necessarily free it - there is not necessarily a test for empty
>> page in any slab_free path.
> 
> This is the same btw in SLAB which keeps objects in per cpu caches and
> keeps empty slab pages on special queues.
> 
>> This patch marks all memcg caches as dead. kmem_cache_shrink is called
>> for the ones who are not yet dead - this will force internal cache
>> reorganization, and then all references to empty pages will be removed.
> 
> You need to call this also for slab to drain the caches and free the pages
> on the empty list.
> 
Doesn't the SLAB have a time-based reaper for that?

That's why I was less concerned with the SLAB, but I can certainly call
it for both.

--
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] Shorten constant names for EFI variable attributes

[H. Peter Anvin]

On 07/20/2012 03:08 PM, Khalid Aziz wrote:

Replace very long constants for EFI variable attributes
with shorter and more convenient names. Also create an
alias for the current longer names so as to not break
compatibility with current API since these constants
are used by userspace programs. This patch depends on
patch .


I think these some from the EFI specifcation, so NAK IMO.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.



--
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] Shorten constant names for EFI variable attributes

[Khalid Aziz]

Replace very long constants for EFI variable attributes
with shorter and more convenient names. Also create an
alias for the current longer names so as to not break
compatibility with current API since these constants
are used by userspace programs. This patch depends on 
patch .


Signed-off-by: Khalid Aziz 
---
 drivers/firmware/efivars.c |   20 
 drivers/firmware/google/gsmi.c |8 ++--
 include/linux/efi.h|   35 ---
 3 files changed, 30 insertions(+), 33 deletions(-)

diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c
index d10c987..27f4fab 100644
--- a/drivers/firmware/efivars.c
+++ b/drivers/firmware/efivars.c
@@ -122,10 +122,7 @@ struct efivar_attribute {
ssize_t (*store)(struct efivar_entry *entry, const char *buf, size_t 
count);
 };
 
-#define PSTORE_EFI_ATTRIBUTES \
-   (EFI_VARIABLE_NON_VOLATILE | \
-EFI_VARIABLE_BOOTSERVICE_ACCESS | \
-EFI_VARIABLE_RUNTIME_ACCESS)
+#define PSTORE_EFI_ATTRIBUTES  (EFI_VAR_NV | EFI_VAR_BOOT | EFI_VAR_RUNTIME)
 
 #define EFIVAR_ATTR(_name, _mode, _show, _store) \
 struct efivar_attribute efivar_attr_##_name = { \
@@ -435,22 +432,21 @@ efivar_attr_read(struct efivar_entry *entry, char *buf)
if (status != EFI_SUCCESS)
return -EIO;
 
-   if (var->Attributes & EFI_VARIABLE_NON_VOLATILE)
+   if (var->Attributes & EFI_VAR_NV)
str += sprintf(str, "EFI_VARIABLE_NON_VOLATILE\n");
-   if (var->Attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS)
+   if (var->Attributes & EFI_VAR_BOOT)
str += sprintf(str, "EFI_VARIABLE_BOOTSERVICE_ACCESS\n");
-   if (var->Attributes & EFI_VARIABLE_RUNTIME_ACCESS)
+   if (var->Attributes & EFI_VAR_RUNTIME)
str += sprintf(str, "EFI_VARIABLE_RUNTIME_ACCESS\n");
-   if (var->Attributes & EFI_VARIABLE_HARDWARE_ERROR_RECORD)
+   if (var->Attributes & EFI_VAR_HW_ERR)
str += sprintf(str, "EFI_VARIABLE_HARDWARE_ERROR_RECORD\n");
-   if (var->Attributes & EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS)
+   if (var->Attributes & EFI_VAR_AUTH_WRITE)
str += sprintf(str,
"EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS\n");
-   if (var->Attributes &
-   EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS)
+   if (var->Attributes & EFI_VAR_TIMED_AUTH_WRITE)
str += sprintf(str,
"EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS\n");
-   if (var->Attributes & EFI_VARIABLE_APPEND_WRITE)
+   if (var->Attributes & EFI_VAR_APPEND)
str += sprintf(str, "EFI_VARIABLE_APPEND_WRITE\n");
return str - buf;
 }
diff --git a/drivers/firmware/google/gsmi.c b/drivers/firmware/google/gsmi.c
index 91ddf0f..3e2d6d4 100644
--- a/drivers/firmware/google/gsmi.c
+++ b/drivers/firmware/google/gsmi.c
@@ -353,9 +353,7 @@ static efi_status_t gsmi_get_variable(efi_char16_t *name,
memcpy(data, gsmi_dev.data_buf->start, *data_size);
 
/* All variables are have the following attributes */
-   *attr = EFI_VARIABLE_NON_VOLATILE |
-   EFI_VARIABLE_BOOTSERVICE_ACCESS |
-   EFI_VARIABLE_RUNTIME_ACCESS;
+   *attr = EFI_VAR_NV | EFI_VAR_BOOT | EFI_VAR_RUNTIME;
}
 
spin_unlock_irqrestore(_dev.lock, flags);
@@ -430,9 +428,7 @@ static efi_status_t gsmi_set_variable(efi_char16_t *name,
.name_ptr = gsmi_dev.name_buf->address,
.data_ptr = gsmi_dev.data_buf->address,
.data_len = (u32)data_size,
-   .attributes = EFI_VARIABLE_NON_VOLATILE |
- EFI_VARIABLE_BOOTSERVICE_ACCESS |
- EFI_VARIABLE_RUNTIME_ACCESS,
+   .attributes = EFI_VAR_NV | EFI_VAR_BOOT | EFI_VAR_RUNTIME,
};
size_t name_len = utf16_strlen(name, GSMI_BUF_SIZE / 2);
efi_status_t ret = EFI_SUCCESS;
diff --git a/include/linux/efi.h b/include/linux/efi.h
index ec45ccd..3d2a6f0 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -551,21 +551,26 @@ extern int __init efi_setup_pcdp_console(char *);
 /*
  * Variable Attributes
  */
-#define EFI_VARIABLE_NON_VOLATILE   0x0001
-#define EFI_VARIABLE_BOOTSERVICE_ACCESS 0x0002
-#define EFI_VARIABLE_RUNTIME_ACCESS 0x0004
-#define EFI_VARIABLE_HARDWARE_ERROR_RECORD 0x0008
-#define EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS 0x0010
-#define EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS 0x0020
-#define EFI_VARIABLE_APPEND_WRITE  0x0040
-
-#define EFI_VARIABLE_MASK  (EFI_VARIABLE_NON_VOLATILE | \
-   EFI_VARIABLE_BOOTSERVICE_ACCESS | \
-   EFI_VARIABLE_RUNTIME_ACCESS | \
-  

[PATCH] [RFC] [SCSI] mpt fusion: add support for 0x1000/0x0055

[Jiri Kosina]

The device identifies itself as

0d:05.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068 PCI-X 
Fusion-MPT SAS (rev 01) Subsystem: NEC Corporation SAS1068

and seems to be functionally compatible with 0x0054 PID.

The request for support of this device has been raised on mailinglists several
times in the past (see [1] [2] and more), but aparently the PCI ID never made it
to mptsas_pci_table[].

[1] http://comments.gmane.org/gmane.linux.scsi/63836
[2] http://lkml.indiana.edu/hypermail/linux/kernel/0701.2/1715.html

Signed-off-by: Jiri Kosina 
---


I guess the "Subsystem: NEC Corporation" is telling us some rebranding 
story, including the PID change ... ?



 drivers/message/fusion/lsi/mpi_cnfg.h |1 +
 drivers/message/fusion/mptsas.c   |2 ++
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/message/fusion/lsi/mpi_cnfg.h 
b/drivers/message/fusion/lsi/mpi_cnfg.h
index d9bcfba..29d54c9 100644
--- a/drivers/message/fusion/lsi/mpi_cnfg.h
+++ b/drivers/message/fusion/lsi/mpi_cnfg.h
@@ -582,6 +582,7 @@ typedef struct _MSG_CONFIG_REPLY
 #define MPI_MANUFACTPAGE_DEVID_SAS1066  (0x005E)
 #define MPI_MANUFACTPAGE_DEVID_SAS1066E (0x005A)
 #define MPI_MANUFACTPAGE_DEVID_SAS1068  (0x0054)
+#define MPI_MANUFACTPAGE_DEVID_SAS1068_2(0x0055)
 #define MPI_MANUFACTPAGE_DEVID_SAS1068E (0x0058)
 #define MPI_MANUFACTPAGE_DEVID_SAS1068_820XELP  (0x0059)
 #define MPI_MANUFACTPAGE_DEVID_SAS1078  (0x0062)
diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c
index 551262e..2475f8c 100644
--- a/drivers/message/fusion/mptsas.c
+++ b/drivers/message/fusion/mptsas.c
@@ -5370,6 +5370,8 @@ static struct pci_device_id mptsas_pci_table[] = {
PCI_ANY_ID, PCI_ANY_ID },
{ PCI_VENDOR_ID_LSI_LOGIC, MPI_MANUFACTPAGE_DEVID_SAS1068,
PCI_ANY_ID, PCI_ANY_ID },
+   { PCI_VENDOR_ID_LSI_LOGIC, MPI_MANUFACTPAGE_DEVID_SAS1068_2,
+   PCI_ANY_ID, PCI_ANY_ID },
{ PCI_VENDOR_ID_LSI_LOGIC, MPI_MANUFACTPAGE_DEVID_SAS1064E,
PCI_ANY_ID, PCI_ANY_ID },
{ PCI_VENDOR_ID_LSI_LOGIC, MPI_MANUFACTPAGE_DEVID_SAS1068E,

-- 
Jiri Kosina
SUSE Labs
--
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 13/13] UAPI: Plumb the UAPI Kbuilds into the user header installation and checking

[David Howells]

Plumb the UAPI Kbuilds into the user header installation and checking system.
As the headers are split the entries will be transferred across from the old
Kbuild files to the UAPI Kbuild files.

The changes made in this commit are:

 (1) Exported generated files (of which there are currently four) are moved to
 uapi/ directories under the appropriate generated/ directory, thus we
 get:

include/generated/uapi/linux/version.h
arch/x86/include/generated/uapi/asm/unistd_32.h
arch/x86/include/generated/uapi/asm/unistd_64.h
arch/x86/include/generated/uapi/asm/unistd_x32.h

 These paths were added to the build as -I flags in a previous patch.

 (2) scripts/Makefile.headersinst is now given the UAPI path to install from
 rather than the old path.

 It then determines the old path from that and includes that Kbuild also
 if it exists, thus permitting the headers to exist in either directory
 during the changeover.

 I also renamed the "install" variable to "installdir" as it refers to a
 directory not the install program.

 (3) scripts/headers_install.pl is altered to take a list of source file paths
 instead of just their names so that the makefile can tell it exactly
 where to find each file.

 For the moment, files can be obtained from one of four places for each
 output directory:

.../include/uapi/foo/
.../include/generated/uapi/foo/
.../include/foo/
.../include/generated/foo/

 The non-UAPI paths will be dropped later.

Signed-off-by: David Howells 
---

 Makefile|   14 +--
 arch/x86/include/asm/Kbuild |4 ---
 arch/x86/syscalls/Makefile  |2 +-
 include/linux/Kbuild|2 --
 include/uapi/asm-generic/Kbuild.asm |4 ++-
 include/uapi/linux/Kbuild   |2 ++
 scripts/Makefile.headersinst|   45 ---
 scripts/headers_install.pl  |   14 ++-
 8 files changed, 51 insertions(+), 36 deletions(-)

diff --git a/Makefile b/Makefile
index bd0763f..08d4a06 100644
--- a/Makefile
+++ b/Makefile
@@ -447,7 +447,7 @@ asm-generic:
 # Detect when mixed targets is specified, and make a second invocation
 # of make so .config is not included in this case either (for *config).
 
-version_h := include/generated/linux/version.h
+version_h := include/generated/uapi/linux/version.h
 
 no-dot-config-targets := clean mrproper distclean \
 cscope gtags TAGS tags help %docs check% coccicheck \
@@ -904,10 +904,10 @@ headers_install_all:
 
 PHONY += headers_install
 headers_install: __headers
-   $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/asm/Kbuild),, \
-   $(error Headers not exportable for the $(SRCARCH) architecture))
-   $(Q)$(MAKE) $(hdr-inst)=include
-   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/asm $(hdr-dst)
+   $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \
+ $(error Headers not exportable for the $(SRCARCH) architecture))
+   $(Q)$(MAKE) $(hdr-inst)=include/uapi
+   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst)
 
 PHONY += headers_check_all
 headers_check_all: headers_install_all
@@ -915,8 +915,8 @@ headers_check_all: headers_install_all
 
 PHONY += headers_check
 headers_check: headers_install
-   $(Q)$(MAKE) $(hdr-inst)=include HDRCHECK=1
-   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/asm $(hdr-dst) 
HDRCHECK=1
+   $(Q)$(MAKE) $(hdr-inst)=include/uapi HDRCHECK=1
+   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) 
HDRCHECK=1
 
 # ---
 # Modules
diff --git a/arch/x86/include/asm/Kbuild b/arch/x86/include/asm/Kbuild
index f9c0d3b..1595d68 100644
--- a/arch/x86/include/asm/Kbuild
+++ b/arch/x86/include/asm/Kbuild
@@ -22,7 +22,3 @@ header-y += sigcontext32.h
 header-y += ucontext.h
 header-y += vm86.h
 header-y += vsyscall.h
-
-genhdr-y += unistd_32.h
-genhdr-y += unistd_64.h
-genhdr-y += unistd_x32.h
diff --git a/arch/x86/syscalls/Makefile b/arch/x86/syscalls/Makefile
index 174b032..f325af2 100644
--- a/arch/x86/syscalls/Makefile
+++ b/arch/x86/syscalls/Makefile
@@ -1,5 +1,5 @@
 out := $(obj)/../include/generated/asm
-uapi := $(obj)/../include/generated/asm
+uapi := $(obj)/../include/generated/uapi/asm
 
 # Create output directory if not already present
 _dummy := $(shell [ -d '$(out)' ] || mkdir -p '$(out)') \
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index ecd8820d..e3481f7 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -20,8 +20,6 @@ header-y += netfilter_ipv6/
 header-y += usb/
 header-y += wimax/
 
-genhdr-y += version.h
-
 ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/asm/a.out.h \
  $(srctree)/include/asm-$(SRCARCH)/a.out.h \
  

[PATCH 12/13] UAPI: x86: Differentiate the generated UAPI and internal headers

[David Howells]

Differentiate the generated UAPI and internal headers during generation such
that the UAPI headers can be installed elsewhere.

A later patch will use this to move the UAPI headers to:

arch/x86/include/generated/uapi/asm/

to make them easier to handle.

A previous patch added a -I for this path.

Signed-off-by: David Howells 
---

 arch/x86/syscalls/Makefile |   17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/arch/x86/syscalls/Makefile b/arch/x86/syscalls/Makefile
index 3236aeb..174b032 100644
--- a/arch/x86/syscalls/Makefile
+++ b/arch/x86/syscalls/Makefile
@@ -1,7 +1,9 @@
 out := $(obj)/../include/generated/asm
+uapi := $(obj)/../include/generated/asm
 
 # Create output directory if not already present
-_dummy := $(shell [ -d '$(out)' ] || mkdir -p '$(out)')
+_dummy := $(shell [ -d '$(out)' ] || mkdir -p '$(out)') \
+ $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)')
 
 syscall32 := $(srctree)/$(src)/syscall_32.tbl
 syscall64 := $(srctree)/$(src)/syscall_64.tbl
@@ -18,7 +20,7 @@ quiet_cmd_systbl = SYSTBL  $@
   cmd_systbl = $(CONFIG_SHELL) '$(systbl)' $< $@
 
 syshdr_abi_unistd_32 := i386
-$(out)/unistd_32.h: $(syscall32) $(syshdr)
+$(uapi)/unistd_32.h: $(syscall32) $(syshdr)
$(call if_changed,syshdr)
 
 syshdr_abi_unistd_32_ia32 := i386
@@ -28,11 +30,11 @@ $(out)/unistd_32_ia32.h: $(syscall32) $(syshdr)
 
 syshdr_abi_unistd_x32 := common,x32
 syshdr_offset_unistd_x32 := __X32_SYSCALL_BIT
-$(out)/unistd_x32.h: $(syscall64) $(syshdr)
+$(uapi)/unistd_x32.h: $(syscall64) $(syshdr)
$(call if_changed,syshdr)
 
 syshdr_abi_unistd_64 := common,64
-$(out)/unistd_64.h: $(syscall64) $(syshdr)
+$(uapi)/unistd_64.h: $(syscall64) $(syshdr)
$(call if_changed,syshdr)
 
 syshdr_abi_unistd_64_x32 := x32
@@ -45,11 +47,12 @@ $(out)/syscalls_32.h: $(syscall32) $(systbl)
 $(out)/syscalls_64.h: $(syscall64) $(systbl)
$(call if_changed,systbl)
 
-syshdr-y   += unistd_32.h unistd_64.h unistd_x32.h
+uapisyshdr-y   += unistd_32.h unistd_64.h unistd_x32.h
 syshdr-y   += syscalls_32.h
 syshdr-$(CONFIG_X86_64)+= unistd_32_ia32.h unistd_64_x32.h
 syshdr-$(CONFIG_X86_64)+= syscalls_64.h
 
-targets+= $(syshdr-y)
+targets+= $(uapisyshdr-y) $(syshdr-y)
 
-all: $(addprefix $(out)/,$(targets))
+all: $(addprefix $(uapi)/,$(uapisyshdr-y))
+all: $(addprefix $(out)/,$(syshdr-y))

--
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 11/13] UAPI: Remove the objhdr-y export list

[David Howells]

Remove the objhdr-y export list as it is no longer used.  genhdr-y should be
used instead.

Signed-off-by: David Howells 
---

 Documentation/kbuild/makefiles.txt |8 
 scripts/Makefile.headersinst   |7 ++-
 2 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/Documentation/kbuild/makefiles.txt 
b/Documentation/kbuild/makefiles.txt
index ab0a984..ec9ae67 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -45,7 +45,7 @@ This document describes the Linux kernel Makefiles.
 
=== 7 Kbuild syntax for exported headers
--- 7.1 header-y
-   --- 7.2 objhdr-y
+   --- 7.2 genhdr-y
--- 7.3 destination-y
--- 7.4 generic-y
 
@@ -1282,15 +1282,15 @@ See subsequent chapter for the syntax of the Kbuild 
file.
 
Subdirectories are visited before their parent directories.
 
-   --- 7.2 objhdr-y
+   --- 7.2 genhdr-y
 
-   objhdr-y specifies generated files to be exported.
+   genhdr-y specifies generated files to be exported.
Generated files are special as they need to be looked
up in another directory when doing 'make O=...' builds.
 
Example:
#include/linux/Kbuild
-   objhdr-y += version.h
+   genhdr-y += version.h
 
--- 7.3 destination-y
 
diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index d3bae5e..463b95a 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -3,8 +3,7 @@
 #
 # header-y  - list files to be installed. They are preprocessed
 # to remove __KERNEL__ section of the file
-# objhdr-y  - Same as header-y but for generated files
-# genhdr-y  - Same as objhdr-y but in a generated/ directory
+# genhdr-y  - Same as header-y but in a generated/ directory
 #
 # ==
 
@@ -37,9 +36,8 @@ wrapper-files := $(filter $(header-y), $(generic-y))
 
 # all headers files for this dir
 header-y  := $(filter-out $(generic-y), $(header-y))
-all-files := $(header-y) $(objhdr-y) $(genhdr-y) $(wrapper-files)
+all-files := $(header-y) $(genhdr-y) $(wrapper-files)
 input-files   := $(addprefix $(srctree)/$(obj)/,$(header-y)) \
- $(addprefix $(objtree)/$(obj)/,$(objhdr-y)) \
  $(addprefix $(objtree)/$(gen)/,$(genhdr-y))
 output-files  := $(addprefix $(install)/, $(all-files))
 
@@ -56,7 +54,6 @@ quiet_cmd_install = INSTALL $(printdir) ($(words 
$(all-files))\
 file$(if $(word 2, $(all-files)),s))
   cmd_install = \
 $(PERL) $< $(srctree)/$(obj) $(install) $(SRCARCH) $(header-y); \
-$(PERL) $< $(objtree)/$(obj) $(install) $(SRCARCH) $(objhdr-y); \
 $(PERL) $< $(objtree)/$(gen) $(install) $(SRCARCH) $(genhdr-y); \
 for F in $(wrapper-files); do   \
 echo "\#include " > $(install)/$$F;\

--
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] workqueue: perform cpu down operations from low priority cpu_notifier()

[Tejun Heo]

Hello, Paul.

On Fri, Jul 20, 2012 at 02:52:07PM -0700, Paul E. McKenney wrote:
> > Fix it by using different priorities for up and down notifiers - high
> > priority for up operations and low priority for down operations.
> 
> Cool!!!
> 
> This certainly provides another data point in favor of running down
> notifiers in the opposite order from up notifiers.  ;-)

Yeah, I was thinking about that.  I don't think converting CPU
notifiers would take a lot of work in terms of both auditing and
converting.  We only have several priorities.

> This series passes light rcutorture/hotplug testing, will be testing
> it more.

Great!

-- 
tejun
--
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 10/13] UAPI: Move linux/version.h

[David Howells]

Move include/linux/version.h to the include/generated/ header directory.
A later patch will move it to include/uapi/generated/.

This allows us to get rid of the objhdr-y list.

Signed-off-by: David Howells 
---

 Makefile |   13 +++--
 include/linux/Kbuild |2 +-
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/Makefile b/Makefile
index d6f09dd..bd0763f 100644
--- a/Makefile
+++ b/Makefile
@@ -447,9 +447,11 @@ asm-generic:
 # Detect when mixed targets is specified, and make a second invocation
 # of make so .config is not included in this case either (for *config).
 
+version_h := include/generated/linux/version.h
+
 no-dot-config-targets := clean mrproper distclean \
 cscope gtags TAGS tags help %docs check% coccicheck \
-include/linux/version.h headers_% archheaders 
archscripts \
+$(version_h) headers_% archheaders archscripts \
 kernelversion %src-pkg
 
 config-targets := 0
@@ -815,7 +817,7 @@ endif
 # prepare2 creates a makefile if using a separate output directory
 prepare2: prepare3 outputmakefile asm-generic
 
-prepare1: prepare2 include/linux/version.h include/generated/utsrelease.h \
+prepare1: prepare2 $(version_h) include/generated/utsrelease.h \
include/config/auto.conf
$(cmd_crmodverdir)
 
@@ -848,7 +850,7 @@ define filechk_version.h
echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';)
 endef
 
-include/linux/version.h: $(srctree)/Makefile FORCE
+$(version_h): $(srctree)/Makefile FORCE
$(call filechk,version.h)
 
 include/generated/utsrelease.h: include/config/kernel.release FORCE
@@ -893,7 +895,7 @@ PHONY += archscripts
 archscripts:
 
 PHONY += __headers
-__headers: include/linux/version.h scripts_basic asm-generic archheaders 
archscripts FORCE
+__headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE
$(Q)$(MAKE) $(build)=scripts build_unifdef
 
 PHONY += headers_install_all
@@ -1003,8 +1005,7 @@ CLEAN_DIRS  += $(MODVERDIR)
 # Directories & files removed with 'make mrproper'
 MRPROPER_DIRS  += include/config usr/include include/generated  \
   arch/*/include/generated
-MRPROPER_FILES += .config .config.old .version .old_version \
-  include/linux/version.h   \
+MRPROPER_FILES += .config .config.old .version .old_version $(version_h) \
  Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS
 
 # clean - Delete most, but leave enough to build external modules
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index 8760be3..ecd8820d 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -20,7 +20,7 @@ header-y += netfilter_ipv6/
 header-y += usb/
 header-y += wimax/
 
-objhdr-y += version.h
+genhdr-y += version.h
 
 ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/asm/a.out.h \
  $(srctree)/include/asm-$(SRCARCH)/a.out.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/

[PATCH 09/13] UAPI: Set up uapi/asm/Kbuild.asm

[David Howells]

Set up uapi/asm/Kbuild.asm.  This requires the mandatory headers to be
dynamically detected.  The same goes for include/asm/Kbuild.asm.  The problem
is that the header files will be split or moved one at a time, but each header
file in Kbuild.asm's list applies to all arch headers of that name
simultaneously.

The dynamic detection of mandatory files can be undone later.

Signed-off-by: David Howells 
---

 include/asm-generic/Kbuild.asm  |   46 +
 include/uapi/asm-generic/Kbuild.asm |   49 +++
 2 files changed, 50 insertions(+), 45 deletions(-)
 create mode 100644 include/uapi/asm-generic/Kbuild.asm

diff --git a/include/asm-generic/Kbuild.asm b/include/asm-generic/Kbuild.asm
index c5d2e5d..d2ee86b 100644
--- a/include/asm-generic/Kbuild.asm
+++ b/include/asm-generic/Kbuild.asm
@@ -1,45 +1 @@
-ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/asm/kvm.h \
- $(srctree)/include/asm-$(SRCARCH)/kvm.h),)
-header-y  += kvm.h
-endif
-
-ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/asm/kvm_para.h \
- $(srctree)/include/asm-$(SRCARCH)/kvm_para.h),)
-header-y  += kvm_para.h
-endif
-
-ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/asm/a.out.h \
- $(srctree)/include/asm-$(SRCARCH)/a.out.h),)
-header-y += a.out.h
-endif
-
-header-y += auxvec.h
-header-y += bitsperlong.h
-header-y += byteorder.h
-header-y += errno.h
-header-y += fcntl.h
-header-y += ioctl.h
-header-y += ioctls.h
-header-y += ipcbuf.h
-header-y += mman.h
-header-y += msgbuf.h
-header-y += param.h
-header-y += poll.h
-header-y += posix_types.h
-header-y += ptrace.h
-header-y += resource.h
-header-y += sembuf.h
-header-y += setup.h
-header-y += shmbuf.h
-header-y += sigcontext.h
-header-y += siginfo.h
-header-y += signal.h
-header-y += socket.h
-header-y += sockios.h
-header-y += stat.h
-header-y += statfs.h
-header-y += swab.h
-header-y += termbits.h
-header-y += termios.h
-header-y += types.h
-header-y += unistd.h
+include include/uapi/asm-generic/Kbuild.asm
diff --git a/include/uapi/asm-generic/Kbuild.asm 
b/include/uapi/asm-generic/Kbuild.asm
new file mode 100644
index 000..9a8464d
--- /dev/null
+++ b/include/uapi/asm-generic/Kbuild.asm
@@ -0,0 +1,49 @@
+#
+# Headers that are optional in usr/include/asm/
+#
+opt-header += kvm.h
+opt-header += kvm_para.h
+opt-header += a.out.h
+
+#
+# Headers that are mandatory in usr/include/asm/
+#
+header-y += auxvec.h
+header-y += bitsperlong.h
+header-y += byteorder.h
+header-y += errno.h
+header-y += fcntl.h
+header-y += ioctl.h
+header-y += ioctls.h
+header-y += ipcbuf.h
+header-y += mman.h
+header-y += msgbuf.h
+header-y += param.h
+header-y += poll.h
+header-y += posix_types.h
+header-y += ptrace.h
+header-y += resource.h
+header-y += sembuf.h
+header-y += setup.h
+header-y += shmbuf.h
+header-y += sigcontext.h
+header-y += siginfo.h
+header-y += signal.h
+header-y += socket.h
+header-y += sockios.h
+header-y += stat.h
+header-y += statfs.h
+header-y += swab.h
+header-y += termbits.h
+header-y += termios.h
+header-y += types.h
+header-y += unistd.h
+
+header-y += $(foreach hdr,$(opt-header), \
+ $(if \
+   $(wildcard \
+   arch/$(SRCARCH)/include/uapi/asm/$(hdr) \
+   arch/$(SRCARCH)/include/asm/$(hdr) \
+   ), \
+   $(hdr) \
+   ))

--
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 08/13] UAPI: x86: Fix insn_sanity build failure after UAPI split

[David Howells]

Fix a build failure in the x86 insn_sanity program after the UAPI split.  The
problem is that insn_sanity.c #includes arch/x86/lib/insn.c - which uses the
kernel string header.  This leads to conflicts for various definitions against
the /usr/include/ headers.

linux/string.h can be replaced with the normal userspace string.h if __KERNEL__
is not specified.

  HOSTCC  arch/x86/tools/insn_sanity
In file included from /data/fs/linux-2.6-hdr/include/linux/string.h:6:0,
 from /data/fs/linux-2.6-hdr/arch/x86/lib/insn.c:21,
 from arch/x86/tools/insn_sanity.c:36:
/data/fs/linux-2.6-hdr/include/linux/types.h:14:26: error: conflicting types 
for 'fd_set'
/usr/include/sys/select.h:76:5: note: previous declaration of 'fd_set' was here
/data/fs/linux-2.6-hdr/include/linux/types.h:15:25: error: conflicting types 
for 'dev_t'
/usr/include/sys/types.h:61:17: note: previous declaration of 'dev_t' was here
/data/fs/linux-2.6-hdr/include/linux/types.h:25:26: error: conflicting types 
for 'timer_t'
/usr/include/time.h:104:19: note: previous declaration of 'timer_t' was here
/data/fs/linux-2.6-hdr/include/linux/types.h:45:26: error: conflicting types 
for 'loff_t'
/usr/include/sys/types.h:45:18: note: previous declaration of 'loff_t' was here
/data/fs/linux-2.6-hdr/include/linux/types.h:112:17: error: conflicting types 
for 'u_int64_t'
/usr/include/sys/types.h:204:1: note: previous declaration of 'u_int64_t' was 
here
/data/fs/linux-2.6-hdr/include/linux/types.h:113:17: error: conflicting types 
for 'int64_t'
/usr/include/sys/types.h:198:1: note: previous declaration of 'int64_t' was here
/data/fs/linux-2.6-hdr/include/linux/types.h:134:23: error: conflicting types 
for 'blkcnt_t'
/usr/include/sys/types.h:236:20: note: previous declaration of 'blkcnt_t' was 
here
In file included from /data/fs/linux-2.6-hdr/arch/x86/lib/insn.c:21:0,
 from arch/x86/tools/insn_sanity.c:36:
/data/fs/linux-2.6-hdr/include/linux/string.h:38:12: error: expected identifier 
or '(' before '__extension__'
/data/fs/linux-2.6-hdr/include/linux/string.h:38:12: error: expected identifier 
or '(' before ')' token
/data/fs/linux-2.6-hdr/include/linux/string.h:41:12: error: expected identifier 
or '(' before '__extension__'
/data/fs/linux-2.6-hdr/include/linux/string.h:53:15: error: expected identifier 
or '(' before '__extension__'
/data/fs/linux-2.6-hdr/include/linux/string.h:61:28: error: expected '=', ',', 
';', 'asm' or '__attribute__' before 'skip_spaces'
/data/fs/linux-2.6-hdr/include/linux/string.h:65:28: error: expected '=', ',', 
';', 'asm' or '__attribute__' before 'char'
/data/fs/linux-2.6-hdr/include/linux/string.h:83:15: error: expected identifier 
or '(' before '__extension__'
/data/fs/linux-2.6-hdr/include/linux/string.h:83:15: error: expected identifier 
or '(' before ')' token
/data/fs/linux-2.6-hdr/include/linux/string.h:86:15: error: expected identifier 
or '(' before '__extension__'
/data/fs/linux-2.6-hdr/include/linux/string.h:86:15: error: expected identifier 
or '(' before ')' token
/data/fs/linux-2.6-hdr/include/linux/string.h:89:24: error: expected identifier 
or '(' before '__extension__'
/data/fs/linux-2.6-hdr/include/linux/string.h:89:24: error: expected identifier 
or '(' before ')' token
/data/fs/linux-2.6-hdr/include/linux/string.h:92:24: error: expected identifier 
or '(' before '__extension__'
/data/fs/linux-2.6-hdr/include/linux/string.h:92:24: error: expected identifier 
or '(' before ')' token

Signed-off-by: David Howells 
---

 arch/x86/lib/insn.c |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/lib/insn.c b/arch/x86/lib/insn.c
index b1e6c4b..54fcffe 100644
--- a/arch/x86/lib/insn.c
+++ b/arch/x86/lib/insn.c
@@ -18,7 +18,11 @@
  * Copyright (C) IBM Corporation, 2002, 2004, 2009
  */
 
+#ifdef __KERNEL__
 #include 
+#else
+#include 
+#endif
 #include 
 #include 
 

--
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 07/13] UAPI: x86: Fix the test_get_len tool

[David Howells]

Fix the x86 test_get_len tool to have the right include paths in the right
order (it includes a non-exported kernel header directly), otherwise errors
like the following occur:

/data/fs/linux-2.6-hdr/include/linux/types.h:18:26: error: conflicting types 
for 'fd_set'
/usr/include/sys/select.h:78:5: note: previous declaration of 'fd_set' was here

and

/data/fs/linux-2.6-hdr/include/linux/string.h:42:12: error: expected identifier 
or '(' before '__extension__'

Signed-off-by: David Howells 
---

 arch/x86/tools/Makefile |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/tools/Makefile b/arch/x86/tools/Makefile
index 733057b..bae601f 100644
--- a/arch/x86/tools/Makefile
+++ b/arch/x86/tools/Makefile
@@ -28,7 +28,7 @@ posttest: $(obj)/test_get_len vmlinux $(obj)/insn_sanity
 hostprogs-y+= test_get_len insn_sanity
 
 # -I needed for generated C source and C source which in the kernel tree.
-HOSTCFLAGS_test_get_len.o := -Wall -I$(objtree)/arch/x86/lib/ 
-I$(srctree)/arch/x86/include/ -I$(srctree)/arch/x86/lib/ -I$(srctree)/include/
+HOSTCFLAGS_test_get_len.o := -Wall -I$(objtree)/arch/x86/lib/ 
-I$(srctree)/arch/x86/include/uapi/ -I$(srctree)/arch/x86/include/ 
-I$(srctree)/arch/x86/lib/ -I$(srctree)/include/uapi/
 
 HOSTCFLAGS_insn_sanity.o := -Wall -I$(objtree)/arch/x86/lib/ 
-I$(srctree)/arch/x86/include/ -I$(srctree)/arch/x86/lib/ -I$(srctree)/include/
 

--
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 06/13] UAPI: (Scripted) Set up UAPI Kbuild files

[David Howells]

Set up empty UAPI Kbuild files to be populated by the header splitter.

Signed-off-by: David Howells 
---

 arch/alpha/include/uapi/asm/Kbuild  |3 +++
 arch/arm/include/uapi/asm/Kbuild|3 +++
 arch/avr32/include/uapi/asm/Kbuild  |3 +++
 arch/blackfin/include/uapi/asm/Kbuild   |3 +++
 arch/c6x/include/uapi/asm/Kbuild|3 +++
 arch/cris/include/uapi/arch-v10/arch/Kbuild |1 +
 arch/cris/include/uapi/arch-v32/arch/Kbuild |1 +
 arch/cris/include/uapi/asm/Kbuild   |5 +
 arch/frv/include/uapi/asm/Kbuild|3 +++
 arch/h8300/include/uapi/asm/Kbuild  |3 +++
 arch/hexagon/include/uapi/asm/Kbuild|3 +++
 arch/ia64/include/uapi/asm/Kbuild   |3 +++
 arch/m32r/include/uapi/asm/Kbuild   |3 +++
 arch/m68k/include/uapi/asm/Kbuild   |3 +++
 arch/microblaze/include/uapi/asm/Kbuild |3 +++
 arch/mips/include/uapi/asm/Kbuild   |3 +++
 arch/mn10300/include/uapi/asm/Kbuild|3 +++
 arch/openrisc/include/uapi/asm/Kbuild   |3 +++
 arch/parisc/include/uapi/asm/Kbuild |3 +++
 arch/powerpc/include/uapi/asm/Kbuild|3 +++
 arch/s390/include/uapi/asm/Kbuild   |3 +++
 arch/score/include/uapi/asm/Kbuild  |3 +++
 arch/sh/include/uapi/asm/Kbuild |3 +++
 arch/sparc/include/uapi/asm/Kbuild  |5 +
 arch/tile/include/uapi/arch/Kbuild  |1 +
 arch/tile/include/uapi/asm/Kbuild   |3 +++
 arch/unicore32/include/uapi/asm/Kbuild  |3 +++
 arch/x86/include/uapi/asm/Kbuild|6 ++
 arch/xtensa/include/uapi/asm/Kbuild |3 +++
 include/uapi/Kbuild |   14 ++
 include/uapi/asm-generic/Kbuild |1 +
 include/uapi/drm/Kbuild |1 +
 include/uapi/linux/Kbuild   |   22 ++
 include/uapi/linux/byteorder/Kbuild |1 +
 include/uapi/linux/caif/Kbuild  |1 +
 include/uapi/linux/can/Kbuild   |1 +
 include/uapi/linux/dvb/Kbuild   |1 +
 include/uapi/linux/hdlc/Kbuild  |1 +
 include/uapi/linux/hsi/Kbuild   |1 +
 include/uapi/linux/isdn/Kbuild  |1 +
 include/uapi/linux/mmc/Kbuild   |1 +
 include/uapi/linux/netfilter/Kbuild |2 ++
 include/uapi/linux/netfilter/ipset/Kbuild   |1 +
 include/uapi/linux/netfilter_arp/Kbuild |1 +
 include/uapi/linux/netfilter_bridge/Kbuild  |1 +
 include/uapi/linux/netfilter_ipv4/Kbuild|1 +
 include/uapi/linux/netfilter_ipv6/Kbuild|1 +
 include/uapi/linux/nfsd/Kbuild  |1 +
 include/uapi/linux/raid/Kbuild  |1 +
 include/uapi/linux/spi/Kbuild   |1 +
 include/uapi/linux/sunrpc/Kbuild|1 +
 include/uapi/linux/tc_act/Kbuild|1 +
 include/uapi/linux/tc_ematch/Kbuild |1 +
 include/uapi/linux/usb/Kbuild   |1 +
 include/uapi/linux/wimax/Kbuild |1 +
 include/uapi/mtd/Kbuild |1 +
 include/uapi/rdma/Kbuild|1 +
 include/uapi/scsi/Kbuild|2 ++
 include/uapi/scsi/fc/Kbuild |1 +
 include/uapi/sound/Kbuild   |1 +
 include/uapi/video/Kbuild   |1 +
 include/uapi/xen/Kbuild |1 +
 62 files changed, 157 insertions(+)
 create mode 100644 arch/alpha/include/uapi/asm/Kbuild
 create mode 100644 arch/arm/include/uapi/asm/Kbuild
 create mode 100644 arch/avr32/include/uapi/asm/Kbuild
 create mode 100644 arch/blackfin/include/uapi/asm/Kbuild
 create mode 100644 arch/c6x/include/uapi/asm/Kbuild
 create mode 100644 arch/cris/include/uapi/arch-v10/arch/Kbuild
 create mode 100644 arch/cris/include/uapi/arch-v32/arch/Kbuild
 create mode 100644 arch/cris/include/uapi/asm/Kbuild
 create mode 100644 arch/frv/include/uapi/asm/Kbuild
 create mode 100644 arch/h8300/include/uapi/asm/Kbuild
 create mode 100644 arch/hexagon/include/uapi/asm/Kbuild
 create mode 100644 arch/ia64/include/uapi/asm/Kbuild
 create mode 100644 arch/m32r/include/uapi/asm/Kbuild
 create mode 100644 arch/m68k/include/uapi/asm/Kbuild
 create mode 100644 arch/microblaze/include/uapi/asm/Kbuild
 create mode 100644 arch/mips/include/uapi/asm/Kbuild
 create mode 100644 arch/mn10300/include/uapi/asm/Kbuild
 create mode 100644 arch/openrisc/include/uapi/asm/Kbuild
 create mode 100644 arch/parisc/include/uapi/asm/Kbuild
 create mode 100644 arch/powerpc/include/uapi/asm/Kbuild
 create mode 100644 arch/s390/include/uapi/asm/Kbuild
 create mode 100644 arch/score/include/uapi/asm/Kbuild
 create mode 100644 arch/sh/include/uapi/asm/Kbuild
 create mode 100644 arch/sparc/include/uapi/asm/Kbuild
 create mode 100644 arch/tile/include/uapi/arch/Kbuild
 create mode 

[PATCH 05/13] UAPI: Partition the header include path sets and add uapi/ header directories

[David Howells]

Partition the header include path flags into two sets, one for kernelspace
builds and one for userspace builds.

Add the following directories to build after the ordinary include directories
so that #include will pick up the UAPI header directly if the kernel header
has been moved there.

The userspace set (represented by the USERINCLUDE make variable) contains:

-I $(srctree)/arch/$(hdr-arch)/include/uapi
-I arch/$(hdr-arch)/include/generated/uapi
-I $(srctree)/include/uapi
-I include/generated/uapi
-include $(srctree)/include/linux/kconfig.h

and the kernelspace set (represented by the LINUXINCLUDE make variable)
contains:

-I $(srctree)/arch/$(hdr-arch)/include
-I arch/$(hdr-arch)/include/generated
-I $(srctree)/include
-I include  --- if not building in the source tree

plus everything in the USERINCLUDE set.

Then use USERINCLUDE in building the x86 boot code.

Signed-off-by: David Howells 
---

 Makefile  |   18 ++
 arch/cris/Makefile|4 +++-
 arch/x86/boot/Makefile|4 ++--
 arch/x86/boot/mkcpustr.c  |2 ++
 arch/x86/include/asm/cpufeature.h |2 ++
 arch/x86/kernel/cpu/mkcapflags.pl |5 -
 6 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/Makefile b/Makefile
index aa8e315..d6f09dd 100644
--- a/Makefile
+++ b/Makefile
@@ -350,12 +350,22 @@ AFLAGS_KERNEL =
 CFLAGS_GCOV= -fprofile-arcs -ftest-coverage
 
 
+# Use USERINCLUDE when you must reference the UAPI directories only.
+USERINCLUDE:= \
+   -I$(srctree)/arch/$(hdr-arch)/include/uapi \
+   -Iarch/$(hdr-arch)/include/generated/uapi \
+   -Iinclude/uapi \
+   -Iinclude/generated/uapi \
+-include $(srctree)/include/linux/kconfig.h
+
 # Use LINUXINCLUDE when you must reference the include/ directory.
 # Needed to be compatible with the O= option
-LINUXINCLUDE:= -I$(srctree)/arch/$(hdr-arch)/include \
-   -Iarch/$(hdr-arch)/include/generated -Iinclude \
-   $(if $(KBUILD_SRC), -I$(srctree)/include) \
-   -include $(srctree)/include/linux/kconfig.h
+LINUXINCLUDE:= \
+   -I$(srctree)/arch/$(hdr-arch)/include \
+   -Iarch/$(hdr-arch)/include/generated \
+   $(if $(KBUILD_SRC), -I$(srctree)/include) \
+   -Iinclude \
+   $(USERINCLUDE)
 
 KBUILD_CPPFLAGS := -D__KERNEL__
 
diff --git a/arch/cris/Makefile b/arch/cris/Makefile
index 29c2ceb..39dc7d0 100644
--- a/arch/cris/Makefile
+++ b/arch/cris/Makefile
@@ -23,7 +23,9 @@ mach-$(CONFIG_ETRAXFS) := fs
 
 ifneq ($(arch-y),)
 SARCH := arch-$(arch-y)
-inc := -Iarch/cris/include/$(SARCH)
+inc := -Iarch/cris/include/uapi/$(SARCH)
+inc += -Iarch/cris/include/$(SARCH)
+inc += -Iarch/cris/include/uapi/$(SARCH)/arch
 inc += -Iarch/cris/include/$(SARCH)/arch
 else
 SARCH :=
diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
index 5a747dd..33607c8 100644
--- a/arch/x86/boot/Makefile
+++ b/arch/x86/boot/Makefile
@@ -37,7 +37,7 @@ setup-y   += video-bios.o
 targets+= $(setup-y)
 hostprogs-y:= mkcpustr tools/build
 
-HOST_EXTRACFLAGS += -I$(srctree)/tools/include $(LINUXINCLUDE) \
+HOST_EXTRACFLAGS += -I$(srctree)/tools/include $(USERINCLUDE) \
-D__EXPORTED_HEADERS__
 
 $(obj)/cpu.o: $(obj)/cpustr.h
@@ -52,7 +52,7 @@ $(obj)/cpustr.h: $(obj)/mkcpustr FORCE
 
 # How to compile the 16-bit code.  Note we always compile for -march=i386,
 # that way we can complain to the user if the CPU is insufficient.
-KBUILD_CFLAGS  := $(LINUXINCLUDE) -g -Os -D_SETUP -D__KERNEL__ \
+KBUILD_CFLAGS  := $(USERINCLUDE) -g -Os -D_SETUP -D__KERNEL__ \
   -DDISABLE_BRANCH_PROFILING \
   -Wall -Wstrict-prototypes \
   -march=i386 -mregparm=3 \
diff --git a/arch/x86/boot/mkcpustr.c b/arch/x86/boot/mkcpustr.c
index 919257f..4579eff 100644
--- a/arch/x86/boot/mkcpustr.c
+++ b/arch/x86/boot/mkcpustr.c
@@ -15,6 +15,8 @@
 
 #include 
 
+#include "../include/asm/required-features.h"
+#include "../include/asm/cpufeature.h"
 #include "../kernel/cpu/capflags.c"
 
 int main(void)
diff --git a/arch/x86/include/asm/cpufeature.h 
b/arch/x86/include/asm/cpufeature.h
index f91e80f..c89c55d 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -4,7 +4,9 @@
 #ifndef _ASM_X86_CPUFEATURE_H
 #define _ASM_X86_CPUFEATURE_H
 
+#ifndef _ASM_X86_REQUIRED_FEATURES_H
 #include 
+#endif
 
 #define NCAPINTS   10  /* N 32-bit words worth of info */
 
diff --git a/arch/x86/kernel/cpu/mkcapflags.pl 
b/arch/x86/kernel/cpu/mkcapflags.pl
index c7b3fe2..091972e 100644
--- a/arch/x86/kernel/cpu/mkcapflags.pl
+++ b/arch/x86/kernel/cpu/mkcapflags.pl
@@ -8,7 +8,10 @@
 open(IN, "< $in\0")   or die "$0: cannot open: $in: $!\n";
 open(OUT, "> $out\0") or die "$0: 

[PATCH 02/13] UAPI: (Scripted) Remove redundant DRM UAPI header #inclusions from drivers/gpu/.

[David Howells]

Remove redundant DRM UAPI header #inclusions from drivers/gpu/.

Remove redundant #inclusions of core DRM UAPI headers (drm.h, drm_mode.h and
drm_sarea.h).  They are now #included via drmP.h and drm_crtc.h via a preceding
patch.

Without this patch and the patch to make include the UAPI headers from the core
headers, after the UAPI split, the DRM C sources cannot find these UAPI headers
because the DRM code relies on specific -I flags to make #include "..."  work
on headers in include/drm/ - but that does not work after the UAPI split without
adding more -I flags.

Signed-off-by: David Howells 
Acked-by: Dave Airlie 
---

 drivers/gpu/drm/ast/ast_drv.c   |1 -
 drivers/gpu/drm/ast/ast_fb.c|1 -
 drivers/gpu/drm/cirrus/cirrus_drv.c |1 -
 drivers/gpu/drm/cirrus/cirrus_fbdev.c   |1 -
 drivers/gpu/drm/cirrus/cirrus_main.c|1 -
 drivers/gpu/drm/cirrus/cirrus_mode.c|1 -
 drivers/gpu/drm/drm_crtc.c  |1 -
 drivers/gpu/drm/drm_modes.c |1 -
 drivers/gpu/drm/exynos/exynos_drm_buf.c |1 -
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c  |1 -
 drivers/gpu/drm/exynos/exynos_drm_drv.c |1 -
 drivers/gpu/drm/exynos/exynos_drm_drv.h |1 -
 drivers/gpu/drm/exynos/exynos_drm_gem.c |1 -
 drivers/gpu/drm/gma500/intel_gmbus.c|1 -
 drivers/gpu/drm/gma500/psb_intel_sdvo.c |1 -
 drivers/gpu/drm/i810/i810_dma.c |1 -
 drivers/gpu/drm/i810/i810_drv.c |1 -
 drivers/gpu/drm/i915/dvo.h  |1 -
 drivers/gpu/drm/i915/i915_debugfs.c |1 -
 drivers/gpu/drm/i915/i915_dma.c |1 -
 drivers/gpu/drm/i915/i915_drv.c |1 -
 drivers/gpu/drm/i915/i915_gem.c |1 -
 drivers/gpu/drm/i915/i915_gem_debug.c   |1 -
 drivers/gpu/drm/i915/i915_gem_evict.c   |1 -
 drivers/gpu/drm/i915/i915_gem_execbuffer.c  |1 -
 drivers/gpu/drm/i915/i915_gem_gtt.c |1 -
 drivers/gpu/drm/i915/i915_gem_stolen.c  |1 -
 drivers/gpu/drm/i915/i915_gem_tiling.c  |1 -
 drivers/gpu/drm/i915/i915_ioc32.c   |1 -
 drivers/gpu/drm/i915/i915_irq.c |1 -
 drivers/gpu/drm/i915/i915_suspend.c |1 -
 drivers/gpu/drm/i915/intel_bios.c   |1 -
 drivers/gpu/drm/i915/intel_crt.c|1 -
 drivers/gpu/drm/i915/intel_dp.c |1 -
 drivers/gpu/drm/i915/intel_dvo.c|1 -
 drivers/gpu/drm/i915/intel_fb.c |1 -
 drivers/gpu/drm/i915/intel_hdmi.c   |1 -
 drivers/gpu/drm/i915/intel_i2c.c|1 -
 drivers/gpu/drm/i915/intel_lvds.c   |1 -
 drivers/gpu/drm/i915/intel_overlay.c|1 -
 drivers/gpu/drm/i915/intel_ringbuffer.c |1 -
 drivers/gpu/drm/i915/intel_sdvo.c   |1 -
 drivers/gpu/drm/i915/intel_tv.c |1 -
 drivers/gpu/drm/mga/mga_dma.c   |2 --
 drivers/gpu/drm/mga/mga_drv.c   |1 -
 drivers/gpu/drm/mga/mga_ioc32.c |1 -
 drivers/gpu/drm/mga/mga_irq.c   |1 -
 drivers/gpu/drm/mga/mga_state.c |1 -
 drivers/gpu/drm/mga/mga_warp.c  |1 -
 drivers/gpu/drm/mgag200/mgag200_drv.c   |1 -
 drivers/gpu/drm/mgag200/mgag200_fb.c|1 -
 drivers/gpu/drm/mgag200/mgag200_i2c.c   |1 -
 drivers/gpu/drm/mgag200/mgag200_main.c  |1 -
 drivers/gpu/drm/mgag200/mgag200_mode.c  |1 -
 drivers/gpu/drm/nouveau/nouveau_acpi.c  |2 --
 drivers/gpu/drm/nouveau/nouveau_channel.c   |1 -
 drivers/gpu/drm/nouveau/nouveau_dma.c   |1 -
 drivers/gpu/drm/nouveau/nouveau_drv.c   |1 -
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |1 -
 drivers/gpu/drm/nouveau/nouveau_fence.c |1 -
 drivers/gpu/drm/nouveau/nouveau_gem.c   |1 -
 drivers/gpu/drm/nouveau/nouveau_ioc32.c |1 -
 drivers/gpu/drm/nouveau/nouveau_irq.c   |1 -
 drivers/gpu/drm/nouveau/nouveau_mem.c   |2 --
 drivers/gpu/drm/nouveau/nouveau_notifier.c  |1 -
 drivers/gpu/drm/nouveau/nouveau_object.c|1 -
 drivers/gpu/drm/nouveau/nouveau_prime.c |1 -
 drivers/gpu/drm/nouveau/nouveau_state.c |2 --
 drivers/gpu/drm/nouveau/nv04_cursor.c   |1 -
 drivers/gpu/drm/nouveau/nv04_display.c  |1 -
 drivers/gpu/drm/nouveau/nv04_fb.c   |1 -
 drivers/gpu/drm/nouveau/nv04_fifo.c |1 -
 drivers/gpu/drm/nouveau/nv04_graph.c|1 -
 drivers/gpu/drm/nouveau/nv04_instmem.c  |1 -
 drivers/gpu/drm/nouveau/nv04_mc.c   |1 -
 drivers/gpu/drm/nouveau/nv04_timer.c|1 -
 drivers/gpu/drm/nouveau/nv10_fb.c   |1 -
 drivers/gpu/drm/nouveau/nv10_fifo.c |1 -
 drivers/gpu/drm/nouveau/nv10_graph.c|1 -
 drivers/gpu/drm/nouveau/nv17_fifo.c |1 -
 drivers/gpu/drm/nouveau/nv20_fb.c   

[PATCH 00/13] UAPI header file split

[David Howells]

Here's the second installment of patches from step 1 of my plan below to clean
up the kernel header files and sort out the inclusion recursion problems.

Note that these patches will need regenerating if the header files they alter
change before they're applied.  However, the disintegration is scripted, so
that just takes a few minutes normally.


===
BACKGROUND ON THE RECURSION PROBLEM
===

I occasionally run into a problem where I can't write an inline function in a
header file because I need to access something from another header that
includes this one.  Due to this, I end up writing it as a #define instead.

The problems are mainly due to inline functions.  If we split some headers
(linux/sched.h being the biggest culprit) to separate the inline functions from
the data structs (e.g. task_struct) then we could reduce the problems.  Other
splits and rearrangements could help also.

Quite often it's a case of an inline function in header A wanting a struct[*]
from header B, but header B already has an inline function that wants a struct
from header A.

[*] or constant or whatever.

In the past someone tried to add a kernel-offsets file (an analogue to
asm-offsets) to deal with the problems of dealing with both linux/rcupdate.h
and linux/sched.h - each header needed to be included before the other.


=
PLANNED PROCEDURE
=

The planned steps are:

 (1) Split the Userspace API (UAPI) out of the kernel headers into its own
 header directories.

 There are two reasons for this being done first:

 (a) It reduces the size of the kernel-only headers and obviates the need
 for __KERNEL__ conditionals in the remnant kernel-only headers.

 (b) In what we have today, there are complex interdependencies between
 headers that are partly exported to user space, and we want to reduce
 those interdependencies.

 It simplifies the problem space by splitting out the user headers as
 they then only depend only on other user headers.

 This step makes it easier to follow through with the remaining steps as
 the remnant kernel headers can be split up without regard as to whether
 the UAPI will be broken.  Header files such as linux/sched.h can even
 disappear entirely if that seems convenient.

 There is another potential benefit as well: it becomes easier to track
 when the UAPI changes just from the filenames in the GIT log.

 Further, linux-...@vger.kernel.org can be put into the MAINTAINERS file
 for the uapi/ directories so that patches changing them get sent to that
 list by everyone using get_maintainer.pl.

 (2) Move stuff out of the Kernel API (KAPI) headers that can be contained in
 individual directories as it is referenced by a single file or directory
 of files.

 (3) Make coherent what can be found in commmon arch headers.  asm/system.h has
 been done now, but there's probably other stuff.

 (4) Split some headers into definitions containers and inline function
 containers to clean up recursion problems.  The main culprit is very
 likely to be linux/sched.h, I think.

 (5) I'd like to split some headers (e.g. linux/security.h) to reduce the
 conditional recompilation burden.  linux/security.h could have, for
 instance, struct security_operations split out into a header file private
 to the stuff in the security/ directory as the wrappers of its function
 pointers are now out of lined in security/security.c.

 (6) Replace the traditional anti-reinclusion guards on header files with
 three-state anti-recursion guards that abort compilation if recursive
 inclusion is encountered.

 (7) Provide a script to go through and rejig the #includes of each source file
 to have just the ones that are actually required (a lot of cut'n'pasting
 goes on, and there are quite a few unnecessary #includes out there).

 (8) Provide a make target that tests all the KAPI and UAPI headers by simply
 passing them one at a time to the compiler and attempting to compile them.

 (9) Attempt to use precompiled headers.


===
IMPLEMENTING STEP 1
===

The patches actually posted here are the manual preparation for the UAPI split
in step (1) above.  I haven't posted the patches that do the actual splitting
by email as the largest of them is in excess of 120,000 lines.  However, the
patches are available through GIT:

http://git.infradead.org/users/dhowells/linux-headers.git

The patches are to be found on the uapi-split branch.  The patches posted here
are from the base of that branch up to the uapi-prep tag; the automated split
follows thereafter to the uapi-post-split tag.

The main aims of the split are:

 (1) To simplify the kernel headers by separating the UAPI from the KAPI.

 (2) You should be able to simply copy the UAPI directories to userspace 

[PATCH 01/13] UAPI: Refer to the DRM UAPI headers with <...> and from certain headers only

[David Howells]

Only refer to the DRM UAPI headers (drm.h, drm_mode.h and drm_sarea.h) from
within drmP.h and drm_crtc.h, and use #include <...> to refer to them so that
when the UAPI split happens they can still be accessed.

Signed-off-by: David Howells 
Acked-by: Dave Airlie 
---

 include/drm/drmP.h |3 ++-
 include/drm/drm_crtc.h |1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 31ad880..850f5ce 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -72,7 +72,8 @@
 #include 
 #include 
 #include 
-#include "drm.h"
+#include 
+#include 
 
 #include 
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index bac55c2..fc820d9 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 

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

[tip:x86/cpufeature] x86, cpufeature: Add the RDSEED and ADX features

[tip-bot for H. Peter Anvin]

Commit-ID:  30d5c4546a7dae29a1aa76abdb69a78bb00136be
Gitweb: http://git.kernel.org/tip/30d5c4546a7dae29a1aa76abdb69a78bb00136be
Author: H. Peter Anvin 
AuthorDate: Fri, 20 Jul 2012 13:35:06 -0700
Committer:  H. Peter Anvin 
CommitDate: Fri, 20 Jul 2012 13:36:41 -0700

x86, cpufeature: Add the RDSEED and ADX features

Add the RDSEED and ADX features documented in section 9.1 of the Intel
Architecture Instruction Set Extensions Programming Reference,
document 319433, version 013b, available from
http://software.intel.com/en-us/avx/

The PREFETCHW bit is already supported in Linux under the name
3DNOWPREFETCH.

Signed-off-by: H. Peter Anvin 
Link: http://lkml.kernel.org/n/tip-lgr6482ufk1bvxzvc2hr8...@git.kernel.org
---
 arch/x86/include/asm/cpufeature.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/cpufeature.h 
b/arch/x86/include/asm/cpufeature.h
index f91e80f..6b7ee5f 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -207,6 +207,8 @@
 #define X86_FEATURE_ERMS   (9*32+ 9) /* Enhanced REP MOVSB/STOSB */
 #define X86_FEATURE_INVPCID(9*32+10) /* Invalidate Processor Context ID */
 #define X86_FEATURE_RTM(9*32+11) /* Restricted Transactional 
Memory */
+#define X86_FEATURE_RDSEED (9*32+18) /* The RDSEED instruction */
+#define X86_FEATURE_ADX(9*32+19) /* The ADCX and ADOX 
instructions */
 
 #if defined(__KERNEL__) && !defined(__ASSEMBLY__)
 
--
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] workqueue: perform cpu down operations from low priority cpu_notifier()

[Paul E. McKenney]

On Tue, Jul 17, 2012 at 10:12:21AM -0700, Tejun Heo wrote:
> Currently, all workqueue cpu hotplug operations run off
> CPU_PRI_WORKQUEUE which is higher than normal notifiers.  This is to
> ensure that workqueue is up and running while bringing up a CPU before
> other notifiers try to use workqueue on the CPU.
> 
> Per-cpu workqueues are supposed to remain working and bound to the CPU
> for normal CPU_DOWN_PREPARE notifiers.  This holds mostly true even
> with workqueue offlining running with higher priority because
> workqueue CPU_DOWN_PREPARE only creates a bound trustee thread which
> runs the per-cpu workqueue without concurrency management without
> explicitly detaching the existing workers.
> 
> However, if the trustee needs to create new workers, it creates
> unbound workers which may wander off to other CPUs while
> CPU_DOWN_PREPARE notifiers are in progress.  Furthermore, if the CPU
> down is cancelled, the per-CPU workqueue may end up with workers which
> aren't bound to the CPU.
> 
> While reliably reproducible with a convoluted artificial test-case
> involving scheduling and flushing CPU burning work items from CPU down
> notifiers, this isn't very likely to happen in the wild, and, even
> when it happens, the effects are likely to be hidden by the following
> successful CPU down.
> 
> Fix it by using different priorities for up and down notifiers - high
> priority for up operations and low priority for down operations.

Cool!!!

This certainly provides another data point in favor of running down
notifiers in the opposite order from up notifiers.  ;-)

This series passes light rcutorture/hotplug testing, will be testing
it more.

Thanx, Paul

> Workqueue cpu hotplug operations will soon go through further cleanup.
> 
> Signed-off-by: Tejun Heo 
> Cc: sta...@vger.kernel.org
> ---
>  include/linux/cpu.h |5 +++--
>  kernel/workqueue.c  |   38 +-
>  2 files changed, 40 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/cpu.h b/include/linux/cpu.h
> index 2e9b9eb..ce7a074 100644
> --- a/include/linux/cpu.h
> +++ b/include/linux/cpu.h
> @@ -73,8 +73,9 @@ enum {
>   /* migration should happen before other stuff but after perf */
>   CPU_PRI_PERF= 20,
>   CPU_PRI_MIGRATION   = 10,
> - /* prepare workqueues for other notifiers */
> - CPU_PRI_WORKQUEUE   = 5,
> + /* bring up workqueues before normal notifiers and down after */
> + CPU_PRI_WORKQUEUE_UP= 5,
> + CPU_PRI_WORKQUEUE_DOWN  = -5,
>  };
> 
>  #define CPU_ONLINE   0x0002 /* CPU (unsigned)v is up */
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 4fa9e35..f59b7fd 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -3644,6 +3644,41 @@ err_destroy:
>   return NOTIFY_BAD;
>  }
> 
> +/*
> + * Workqueues should be brought up before normal priority CPU notifiers.
> + * This will be registered high priority CPU notifier.
> + */
> +static int __devinit workqueue_cpu_up_callback(struct notifier_block *nfb,
> +unsigned long action,
> +void *hcpu)
> +{
> + switch (action & ~CPU_TASKS_FROZEN) {
> + case CPU_UP_PREPARE:
> + case CPU_UP_CANCELED:
> + case CPU_DOWN_FAILED:
> + case CPU_ONLINE:
> + return workqueue_cpu_callback(nfb, action, hcpu);
> + }
> + return NOTIFY_OK;
> +}
> +
> +/*
> + * Workqueues should be brought down after normal priority CPU notifiers.
> + * This will be registered as low priority CPU notifier.
> + */
> +static int __devinit workqueue_cpu_down_callback(struct notifier_block *nfb,
> +  unsigned long action,
> +  void *hcpu)
> +{
> + switch (action & ~CPU_TASKS_FROZEN) {
> + case CPU_DOWN_PREPARE:
> + case CPU_DYING:
> + case CPU_POST_DEAD:
> + return workqueue_cpu_callback(nfb, action, hcpu);
> + }
> + return NOTIFY_OK;
> +}
> +
>  #ifdef CONFIG_SMP
> 
>  struct work_for_cpu {
> @@ -3839,7 +3874,8 @@ static int __init init_workqueues(void)
>   unsigned int cpu;
>   int i;
> 
> - cpu_notifier(workqueue_cpu_callback, CPU_PRI_WORKQUEUE);
> + cpu_notifier(workqueue_cpu_up_callback, CPU_PRI_WORKQUEUE_UP);
> + cpu_notifier(workqueue_cpu_down_callback, CPU_PRI_WORKQUEUE_DOWN);
> 
>   /* initialize gcwqs */
>   for_each_gcwq_cpu(cpu) {
> -- 
> 1.7.7.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

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

[PATCH] forcedeth: spin_unlock_irq in interrupt handler fix

[Denis Efremov]

The replacement of spin_lock_irq/spin_unlock_irq pair in interrupt
handler by spin_lock_irqsave/spin_lock_irqrestore pair.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Denis Efremov 
---
 drivers/net/ethernet/nvidia/forcedeth.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/nvidia/forcedeth.c 
b/drivers/net/ethernet/nvidia/forcedeth.c
index 928913c..7e68c00 100644
--- a/drivers/net/ethernet/nvidia/forcedeth.c
+++ b/drivers/net/ethernet/nvidia/forcedeth.c
@@ -3776,7 +3776,7 @@ static irqreturn_t nv_nic_irq_other(int foo, void *data)
np->link_timeout = jiffies + LINK_TIMEOUT;
}
if (events & NVREG_IRQ_RECOVER_ERROR) {
-   spin_lock_irq(>lock);
+   spin_lock_irqsave(>lock, flags);
/* disable interrupts on the nic */
writel(NVREG_IRQ_OTHER, base + NvRegIrqMask);
pci_push(base);
@@ -3786,7 +3786,7 @@ static irqreturn_t nv_nic_irq_other(int foo, void *data)
np->recover_error = 1;
mod_timer(>nic_poll, jiffies + POLL_WAIT);
}
-   spin_unlock_irq(>lock);
+   spin_unlock_irqrestore(>lock, flags);
break;
}
if (unlikely(i > max_interrupt_work)) {
-- 
1.7.7

--
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 RFT RESEND] net: Fix Neptune ethernet driver to check dma mapping error

[Shuah Khan]

Fix Neptune ethernet driver to check dma mapping error after map_page()
interface returns.

Signed-off-by: Shuah Khan 
---
 drivers/net/ethernet/sun/niu.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c
index 8c726b7..60d5c03 100644
--- a/drivers/net/ethernet/sun/niu.c
+++ b/drivers/net/ethernet/sun/niu.c
@@ -3335,6 +3335,10 @@ static int niu_rbr_add_page(struct niu *np, struct 
rx_ring_info *rp,
 
addr = np->ops->map_page(np->device, page, 0,
 PAGE_SIZE, DMA_FROM_DEVICE);
+   if (!addr) {
+   __free_page(page);
+   return -ENOMEM;
+   }
 
niu_hash_page(rp, page, addr);
if (rp->rbr_blocks_per_page > 1)
-- 
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 RFT] net: Fix Neptune ethernet driver to check dma mapping error

[Shuah Khan]

On Fri, 2012-07-20 at 14:30 -0700, David Miller wrote:
> From: Shuah Khan 
> Date: Fri, 20 Jul 2012 15:27:59 -0600
> 
> > Request for testing, since I don't have the hardware to test.
> 
> This is not how you post a patch.
> 
> > 
> 
> When you put those "---..." there, GIT is going to eliminate everything
> afterwards from the commit mesage when I apply this.  Yet afterwards
> is what your commit message actually is.
> 
> You therefore should do things the other way around, provide the commit
> message text, then the "---..." line, then your comments you don't want
> in the final commit message.

Thanks. I had it reversed in my head for some reason. Maybe not enough
coffee :) Will resend the patch now.

-- Shuah

--
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] tty: handle NULL parameters in free_tty_struct()

[Jiri Slaby]

On 07/20/2012 11:48 AM, Alan Cox wrote:
> On Fri, 20 Jul 2012 10:06:34 +0300
> Dan Carpenter  wrote:
> 
>> We sometimes pass NULL pointers to free_tty_struct().  One example where
>> it can happen is in the error handling code in pty_common_install().
>>
>> Signed-off-by: Dan Carpenter 
> 
> Acked-by: Alan Cox 
> 
> We probably shouldn't be passing NULLs there but making
> free_tty_struct(NULL) a no-op matches the kfree and other behaviours and
> is robust.

Yes, this was unintended. Good catch, Dan.

thanks,
-- 
js
suse labs
--
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 RFT] net: Fix Neptune ethernet driver to check dma mapping error

[David Miller]

From: Shuah Khan 
Date: Fri, 20 Jul 2012 15:27:59 -0600

> Request for testing, since I don't have the hardware to test.

This is not how you post a patch.

> 

When you put those "---..." there, GIT is going to eliminate everything
afterwards from the commit mesage when I apply this.  Yet afterwards
is what your commit message actually is.

You therefore should do things the other way around, provide the commit
message text, then the "---..." line, then your comments you don't want
in the final commit message.
--
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 RFT] net: Fix Neptune ethernet driver to check dma mapping error

[Shuah Khan]

Request for testing, since I don't have the hardware to test.



Fix Neptune ethernet driver to check dma mapping error after map_page()
interface returns.

Signed-off-by: Shuah Khan 
Cc: 
---
 drivers/net/ethernet/sun/niu.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c
index 8c726b7..60d5c03 100644
--- a/drivers/net/ethernet/sun/niu.c
+++ b/drivers/net/ethernet/sun/niu.c
@@ -3335,6 +3335,10 @@ static int niu_rbr_add_page(struct niu *np, struct 
rx_ring_info *rp,
 
addr = np->ops->map_page(np->device, page, 0,
 PAGE_SIZE, DMA_FROM_DEVICE);
+   if (!addr) {
+   __free_page(page);
+   return -ENOMEM;
+   }
 
niu_hash_page(rp, page, addr);
if (rp->rbr_blocks_per_page > 1)
-- 
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][Trivial][resend] Documentation: Add newline at end-of-file to files lacking one

[Jiri Kosina]

On Fri, 20 Jul 2012, Jesper Juhl wrote:

> This patch simply adds a newline character at end-of-file to those
> files in Documentation/ that currently lack one.
> 
> This is done for a few different reasons:
> 
> A) It's rather annoying when you do "cat some_file.txt" that your
>prompt/cursor ends up at the end of the last line of output rather
>than on a new line.
> 
> B) Some tools that process files line-by-line may get confused by the
>lack of a newline on the last line.
> 
> C) The "\ No newline at end of file" line in diffs annoys me for some
>reason.
> 
> So, let's just add the missing newline once and for all.
> 
> Signed-off-by: Jesper Juhl 

Queued for 3.6, thanks Jesper.

-- 
Jiri Kosina
SUSE Labs
--
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 -next] m68k/apollo: Rename "timer" to "apollo_timer"

[Geert Uytterhoeven]

In file included from include/linux/kgdb.h:17,
 from include/linux/fb.h:8,
 from drivers/video/dnfb.c:15:
include/linux/serial_8250.h:71: error: expected identifier or ‘(’ before 
numeric constant
include/linux/serial_8250.h:72: error: expected ‘;’ before ‘struct’
make[1]: *** [drivers/video/dnfb.o] Error 1

This is caused by

#define timer (IO_BASE + timer_physaddr)

in , which conflicts with the new "timer" struct member in
.

Rename "timer" to "apollo_timer", as it's a way too generic name for a
global #define.

Signed-off-by: Geert Uytterhoeven 
--
http://kisskb.ellerman.id.au/kisskb/buildresult/6739606/
---
 arch/m68k/apollo/config.c|   16 
 arch/m68k/include/asm/apollohw.h |2 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/m68k/apollo/config.c b/arch/m68k/apollo/config.c
index 0a30406..f5565d6 100644
--- a/arch/m68k/apollo/config.c
+++ b/arch/m68k/apollo/config.c
@@ -177,8 +177,8 @@ irqreturn_t dn_timer_int(int irq, void *dev_id)
 
timer_handler(irq, dev_id);
 
-   x=*(volatile unsigned char *)(timer+3);
-   x=*(volatile unsigned char *)(timer+5);
+   x = *(volatile unsigned char *)(apollo_timer + 3);
+   x = *(volatile unsigned char *)(apollo_timer + 5);
 
return IRQ_HANDLED;
 }
@@ -186,17 +186,17 @@ irqreturn_t dn_timer_int(int irq, void *dev_id)
 void dn_sched_init(irq_handler_t timer_routine)
 {
/* program timer 1 */
-   *(volatile unsigned char *)(timer+3)=0x01;
-   *(volatile unsigned char *)(timer+1)=0x40;
-   *(volatile unsigned char *)(timer+5)=0x09;
-   *(volatile unsigned char *)(timer+7)=0xc4;
+   *(volatile unsigned char *)(apollo_timer + 3) = 0x01;
+   *(volatile unsigned char *)(apollo_timer + 1) = 0x40;
+   *(volatile unsigned char *)(apollo_timer + 5) = 0x09;
+   *(volatile unsigned char *)(apollo_timer + 7) = 0xc4;
 
/* enable IRQ of PIC B */
*(volatile unsigned char *)(pica+1)&=(~8);
 
 #if 0
-   printk("*(0x10803) %02x\n",*(volatile unsigned char *)(timer+0x3));
-   printk("*(0x10803) %02x\n",*(volatile unsigned char *)(timer+0x3));
+   printk("*(0x10803) %02x\n",*(volatile unsigned char *)(apollo_timer + 
0x3));
+   printk("*(0x10803) %02x\n",*(volatile unsigned char *)(apollo_timer + 
0x3));
 #endif
 
if (request_irq(IRQ_APOLLO, dn_timer_int, 0, "time", timer_routine))
diff --git a/arch/m68k/include/asm/apollohw.h b/arch/m68k/include/asm/apollohw.h
index bbafc91..6c19e0c 100644
--- a/arch/m68k/include/asm/apollohw.h
+++ b/arch/m68k/include/asm/apollohw.h
@@ -86,7 +86,7 @@ extern u_long timer_physaddr;
 #define cpuctrl (*(volatile unsigned int *)(IO_BASE + cpuctrl_physaddr))
 #define pica (IO_BASE + pica_physaddr)
 #define picb (IO_BASE + picb_physaddr)
-#define timer (IO_BASE + timer_physaddr)
+#define apollo_timer (IO_BASE + timer_physaddr)
 #define addr_xlat_map ((unsigned short *)(IO_BASE + 0x17000))
 
 #define isaIO2mem(x) (x) & 0x3f8)  << 7) | (((x) & 0xfc00) >> 6) | ((x) & 
0x7)) + 0x4 + IO_BASE)
-- 
1.7.0.4

--
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: linux-next: build failure after merge of the tty tree

[Geert Uytterhoeven]

Hi Alan,

On Fri, Jul 20, 2012 at 10:55 PM, Alan Cox  wrote:
>> Today's build failed because there's a new user in the MIPS tree:
>> arch/mips/cavium-octeon/serial.c
>>
>> http://kisskb.ellerman.id.au/kisskb/buildresult/6739341/
>
> The version in the tree I have registers a platform device rather than
> calling into 8250 directly. That appears to be rather better mannered
> than whatever you are building.
>
> If someone has moved from the platform device could they kindly explain
> *why* ?

commit 7c507e6fe36d8e8f67a06d1f81ddde4d8ecf739f ("MIPS: Octeon: Use
device tree to register serial ports.") in linux-next.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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] gpio: samsung: Fix off-by-one bug in gpio addresses

[Doug Anderson]

Acked-by: Doug Anderson 

---

On Fri, Jul 20, 2012 at 1:58 PM, Sean Paul  wrote:
>
> Move gpc4 to the end of the automatically processed gpio controllers so
> we don't taint the automatic offset calculation.
>
> This bug caused all controllers coming after gpc4 to map to the
> incorrect address. The result is < 0 0 0 0> would actually map to
> GPIO 0 in gpd0.
>
> Signed-off-by: Sean Paul 
> ---
>  drivers/gpio/gpio-samsung.c |   14 +++---
>  1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
> index b6453d0..e4599b4 100644
> --- a/drivers/gpio/gpio-samsung.c
> +++ b/drivers/gpio/gpio-samsung.c
> @@ -2454,12 +2454,6 @@ static struct samsung_gpio_chip exynos5_gpios_1[] = {
> },
> }, {
> .chip   = {
> -   .base   = EXYNOS5_GPC4(0),
> -   .ngpio  = EXYNOS5_GPIO_C4_NR,
> -   .label  = "GPC4",
> -   },
> -   }, {
> -   .chip   = {
> .base   = EXYNOS5_GPD0(0),
> .ngpio  = EXYNOS5_GPIO_D0_NR,
> .label  = "GPD0",
> @@ -2513,6 +2507,12 @@ static struct samsung_gpio_chip exynos5_gpios_1[] = {
> .label  = "GPY6",
> },
> }, {
> +   .chip   = {
> +   .base   = EXYNOS5_GPC4(0),
> +   .ngpio  = EXYNOS5_GPIO_C4_NR,
> +   .label  = "GPC4",
> +   },
> +   }, {
> .config = _gpio_cfgs[9],
> .irq_base = IRQ_EINT(0),
> .chip   = {
> @@ -2833,7 +2833,7 @@ static __init void exynos5_gpiolib_init(void)
> }
>
> /* need to set base address for gpc4 */
> -   exynos5_gpios_1[11].base = gpio_base1 + 0x2E0;
> +   exynos5_gpios_1[20].base = gpio_base1 + 0x2E0;
>
> /* need to set base address for gpx */
> chip = _gpios_1[21];
> --
> 1.7.7.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: oops in kernel ( 3.4.x -> 3.5rc )

[Thadeu Lima de Souza Cascardo]

On Fri, Jul 20, 2012 at 10:52:40PM +0200, nicolas prochazka wrote:
> Hello
> the problem is occured with  :
> - linux kernel 3.4.5i do not test with 3.4.0 / 1 / 2 / 3 / 4,
> but i can if you want
> - linux kernel 3.5rc6 rc7  / do not test with other rc.
> 
> the problem is not occured with :
> linux kernel 3.3.4 / 3.3.8
> 
> These servers are used for :
> - starting a lot of virtual machine with qemu-kvm ( ~ 40 )   ( lot of
> select i think)
> - do a lot of network tests with openvswitch
> 
> I can test a kernel 3.4.x before and after a commit id (?) to find a 
> regression.
> 
> Regards,
> Nicolas.
> 

Can you try this commit 1fd36adcd98c14d2fd97f545293c488775cb2823? And
the commit before it?

> 
> 2012/7/20 Thadeu Lima de Souza Cascardo :
> > On Fri, Jul 20, 2012 at 09:21:53AM -0400, Dave Jones wrote:
> >> On Fri, Jul 20, 2012 at 11:56:06AM +0200, nicolas prochazka wrote:
> >>
> >>  > [ 2384.900061] BUG: unable to handle kernel paging request at 
> >> 0001002f
> >>
> >> That '1' looks like a random bit flip. Try running memtest86.
> >>
> >
> > Looks more a 32-bit value of 1 followed by a 32-bit value of 0x2f. Most
> > likely a pointer to some other piece of a struct. However, taking a look
> > at fs/files.c code, nothing seems suspicious.
> >
> > Nicolas, it wasn't clear to me if you had problems with 3.4 too. There
> > has been some changes in fs/files.c on 3.4-rc1 in the piece of code
> > where you hit the problem.
> >
> > What does your system exercise? Any chance you are using a lot of
> > select, which has also been changed in those same patches to fs/files.c?
> >
> > Regards.
> > Cascardo.
> >
> >
> >>  > [ 2384.910010] Pid: 23838, comm: queue.sh Tainted: G  D W
> >>
> >> This wasn't the first problem either.
> >>
> >>  > [ 2397.885344] BUG: unable to handle kernel paging request at 
> >> 0001003b
> >>
> >> Looks like the same flipped bit.
> >>
> >>   Dave
> >>
> >> --
> >> 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/
> >>
> >
> 

--
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] dmi: Feed DMI table to /dev/random driver

[Matt Mackall]

On Fri, 2012-07-20 at 13:15 -0700, Tony Luck wrote:
> Send the entire DMI (SMBIOS) table to the /dev/random driver to
> help seed its pools.
> 
> Signed-off-by: Tony Luck 
> ---
> 
> This looks a useful addition to your /dev/random series. There are
> lots of platform specific goodies in this table (BIOS version, system
> serial number and UUID, count and version number of processors, DIMM
> slot population and serial numbers, etc.)
> 
> On the system I tested the patch on the table is 9866 bytes. Is it
> OK to dump that much into add_device_randomness() in one shot?

Yes, that's fine. We should also consider doing something similar with
various bus enumerations (PCI, USB, SCSI) and hotplug, we might pick up
similar goodies. Also, we should feed in the OF device tree on platforms
that use it.

-- 
Mathematics is the supreme nostalgia of our time.


--
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] gpio: samsung: Fix off-by-one bug in gpio addresses

[Sean Paul]

Move gpc4 to the end of the automatically processed gpio controllers so
we don't taint the automatic offset calculation.

This bug caused all controllers coming after gpc4 to map to the
incorrect address. The result is < 0 0 0 0> would actually map to
GPIO 0 in gpd0.

Signed-off-by: Sean Paul 
---
 drivers/gpio/gpio-samsung.c |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index b6453d0..e4599b4 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -2454,12 +2454,6 @@ static struct samsung_gpio_chip exynos5_gpios_1[] = {
},
}, {
.chip   = {
-   .base   = EXYNOS5_GPC4(0),
-   .ngpio  = EXYNOS5_GPIO_C4_NR,
-   .label  = "GPC4",
-   },
-   }, {
-   .chip   = {
.base   = EXYNOS5_GPD0(0),
.ngpio  = EXYNOS5_GPIO_D0_NR,
.label  = "GPD0",
@@ -2513,6 +2507,12 @@ static struct samsung_gpio_chip exynos5_gpios_1[] = {
.label  = "GPY6",
},
}, {
+   .chip   = {
+   .base   = EXYNOS5_GPC4(0),
+   .ngpio  = EXYNOS5_GPIO_C4_NR,
+   .label  = "GPC4",
+   },
+   }, {
.config = _gpio_cfgs[9],
.irq_base = IRQ_EINT(0),
.chip   = {
@@ -2833,7 +2833,7 @@ static __init void exynos5_gpiolib_init(void)
}
 
/* need to set base address for gpc4 */
-   exynos5_gpios_1[11].base = gpio_base1 + 0x2E0;
+   exynos5_gpios_1[20].base = gpio_base1 + 0x2E0;
 
/* need to set base address for gpx */
chip = _gpios_1[21];
-- 
1.7.7.3

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

Re: [PATCH 0/3] dyndbg: dev_dbg bugfix + 2 trivials

[Greg KH]

On Fri, Jul 20, 2012 at 04:38:58PM -0400, Jason Baron wrote:
> On Thu, Jul 19, 2012 at 01:46:19PM -0600, Jim Cromie wrote:
> > 3 patches here, 1st is bugfix, others are trivial.
> > 
> > 1- fix __dev_printk, which broke dev_dbg() prefix under 
> > CONFIG_DYNAMIC_DEBUG.
> > 
> 
> Patch looks good, and would be really nice to get into 3.5. Kay, are you
> ok with this patch? 

It's too late for 3.5, but I can take it for 3.6-rc1 and backport it to
3.5.1 if needed.

I just need you ack :)

> > 2- change dyndbg prefix interfield separator from ':' to '.'
> > 
> > for example (output from test-code, not submitted):
> > r8169 :02:00.0: r8169.rtl_init_one: set-drvdata pdev:880223041000 
> > dev:880220d6a000
> > hwmon hwmon1: k10temp.k10temp_probe.180: set-drvdata pdev:88022303d000 
> > dev:8801dfd2a000
> > 
> > This improves usability of cut -d:  for pr_debug() messages,
> > as field position is less volatile with various uses of dyndbg flags.
> > Its not perfect:
> > - dev_dbg on net-devices adds several more colons,
> >   but this doesnt vary with dyndbg flags. 
> > - dyndbg=+pfmlt still adds a field vs dyndbg==p (ie no prefix)
> > - pr_fmt() commonly adds another colon (unchanged with this patch)
> 
> As you suggest in the patch, changing the delimiter to a non-colon
> character such as ',' would resolve these cases? 
> 
> >   
> > 3- trivial var name change in lib/dynamic_debug.c
> > 
> > 
> > Please drop or apply 2,3 as you prefer.
> 
> 2,3 are nice, but as you suggest I think we want to separate them from
> patch 1, which is a bugfix for 3.5.

I agree.

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 RESEND 5/5] vhost-blk: Add vhost-blk support

[Anthony Liguori]

"Michael S. Tsirkin"  writes:

> On Thu, Jul 19, 2012 at 08:05:42AM -0500, Anthony Liguori wrote:
>> Of course, the million dollar question is why would using AIO in the
>> kernel be faster than using AIO in userspace?
>
> Actually for me a more important question is how does it compare
> with virtio-blk dataplane?

I'm not even asking for a benchmark comparision.  It's the same API
being called from a kernel thread vs. a userspace thread.  Why would
there be a 60% performance difference between the two?  That doesn't
make any sense.

There's got to be a better justification for putting this in the kernel
than just that we can.

I completely understand why Christoph's suggestion of submitting BIOs
directly would be faster.  There's no way to do that in userspace.

Regards,

Anthony Liguori

>
> -- 
> MST
--
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: oops in kernel ( 3.4.x -> 3.5rc )

[nicolas prochazka]

Hello
the problem is occured with  :
- linux kernel 3.4.5i do not test with 3.4.0 / 1 / 2 / 3 / 4,
but i can if you want
- linux kernel 3.5rc6 rc7  / do not test with other rc.

the problem is not occured with :
linux kernel 3.3.4 / 3.3.8

These servers are used for :
- starting a lot of virtual machine with qemu-kvm ( ~ 40 )   ( lot of
select i think)
- do a lot of network tests with openvswitch

I can test a kernel 3.4.x before and after a commit id (?) to find a regression.

Regards,
Nicolas.


2012/7/20 Thadeu Lima de Souza Cascardo :
> On Fri, Jul 20, 2012 at 09:21:53AM -0400, Dave Jones wrote:
>> On Fri, Jul 20, 2012 at 11:56:06AM +0200, nicolas prochazka wrote:
>>
>>  > [ 2384.900061] BUG: unable to handle kernel paging request at 
>> 0001002f
>>
>> That '1' looks like a random bit flip. Try running memtest86.
>>
>
> Looks more a 32-bit value of 1 followed by a 32-bit value of 0x2f. Most
> likely a pointer to some other piece of a struct. However, taking a look
> at fs/files.c code, nothing seems suspicious.
>
> Nicolas, it wasn't clear to me if you had problems with 3.4 too. There
> has been some changes in fs/files.c on 3.4-rc1 in the piece of code
> where you hit the problem.
>
> What does your system exercise? Any chance you are using a lot of
> select, which has also been changed in those same patches to fs/files.c?
>
> Regards.
> Cascardo.
>
>
>>  > [ 2384.910010] Pid: 23838, comm: queue.sh Tainted: G  D W
>>
>> This wasn't the first problem either.
>>
>>  > [ 2397.885344] BUG: unable to handle kernel paging request at 
>> 0001003b
>>
>> Looks like the same flipped bit.
>>
>>   Dave
>>
>> --
>> 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/
>>
>
--
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/