Re: PROBLEM: CONFIG_DEFAULT_MESSAGE_LOGLEVEL option seems not to work
On 03/15/13 14:56, Manolo Díaz wrote: > Hi, > > It seems that the kernel loglevel is set to 7 ignoring the > CONFIG_DEFAULT_MESSAGE_LOGLEVEL option (set to 4 in my config file) > > The /proc/sys/kernel/printk output is > > 7 4 1 7 > > Passing the boot parameter "loglevel=4" or echoing "4 4 1 7" > to /proc/sys/kernel/printk solves my problem and then this proc file > contains > > 4 4 1 7 > > as expected. > > kernel version: > Linux version 3.8.3 (root@alcyone) (gcc version 4.7.2 (Debian 4.7.2-5) > ) #2 SMP Fri Mar 15 08:23:50 CET 2013 > > config file is gziped and attached. Hi, CONFIG_DEFAULT_MESSAGE_LOGLEVEL modifies the second field (value) in /proc/sys/kernel/printk, not the first value. OTOH, the "loglevel" kernel parameter modifies the first value in that /proc file, not the second value. Does that clarify/help? -- ~Randy -- 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] arc: remove #ifdef-ed out include of dead header
On Friday 15 March 2013 09:46 PM, Paul Bolle wrote: > There's no (Kconfig) macro CONFIG_BLOCK_DEV_RAM. (CONFIG_BLK_DEV_RAM > does exist though.) But linux/blk.h got killed in 2005 anyway (in a > patch titled "kill blk.h"), so these three lines can be removed. > > Signed-off-by: Paul Bolle Applied to next. P.S. The msg to linux-snps-arc would have bounced back since the list couldn't be created - I have a patch to be sent to Linus to remove that. Thx, -Vineet -- 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 RESEND] gpio: samsung: Add terminating entry for exynos_pinctrl_ids
The of_device_id table is supposed to be zero-terminated.
Signed-off-by: Axel Lin
Acked-by: Grant Likely
---
This patch was sent on https://lkml.org/lkml/2012/12/9/135
Re-generate the patch against linux-next and resend.
drivers/gpio/gpio-samsung.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index 99e0fa4..b22ca79 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -3030,6 +3030,7 @@ static __init int samsung_gpiolib_init(void)
{ .compatible = "samsung,exynos4x12-pinctrl", },
{ .compatible = "samsung,exynos5250-pinctrl", },
{ .compatible = "samsung,exynos5440-pinctrl", },
+ { }
};
for_each_matching_node(pctrl_np, exynos_pinctrl_ids)
if (pctrl_np && of_device_is_available(pctrl_np))
--
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 net-next] drivers:net: dma_alloc_coherent: use __GFP_ZERO instead of memset(, 0)
On Fri, 2013-03-15 at 22:51 +, Abodunrin, Akeem G wrote: > -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On > Behalf Of Joe Perches [] > Reduce the number of calls required to alloc a zeroed block of memory. [] > diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c > b/drivers/net/ethernet/intel/igbvf/netdev.c [] > @@ -488,7 +487,6 @@ int igbvf_setup_rx_resources(struct igbvf_adapter > *adapter, > > rx_ring->desc = dma_alloc_coherent(>dev, rx_ring->size, > _ring->dma, GFP_KERNEL); > - > if (!rx_ring->desc) > goto err; > > Hi Joe, Hello Akeem. > Your changes did not seem to make it to igbvf/netdev.c - I think > instead of removing an extra line added for code clarity, you > want to add: > "tx_ring->desc = dma_alloc_coherent(>dev, tx_ring->size, > _ring->dma, GFP_KERNEL| > __GFP_ZERO);" Not really, there's no memset here so this bit is just a whitespace neatening. -- 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: [ 11/21] hwmon: (sht15) Check return value of regulator_enable()
On Tue, 2013-03-12 at 15:44 -0700, Greg Kroah-Hartman wrote:
> 3.0-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Mark Brown
>
> commit 3e78080f81481aa8340374d5a37ae033c1cf4272 upstream.
>
> Not having power is a pretty serious error so check that we are able to
> enable the supply and error out if we can't.
>
> Signed-off-by: Mark Brown
> Signed-off-by: Guenter Roeck
> ---
> drivers/hwmon/sht15.c |8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> --- a/drivers/hwmon/sht15.c
> +++ b/drivers/hwmon/sht15.c
> @@ -926,7 +926,13 @@ static int __devinit sht15_probe(struct
> if (voltage)
> data->supply_uV = voltage;
>
> - regulator_enable(data->reg);
> + ret = regulator_enable(data->reg);
> + if (ret != 0) {
> + dev_err(>dev,
> + "failed to enable regulator: %d\n", ret);
> + return ret;
> + }
> +
> /*
>* Setup a notifier block to update this if another device
>* causes the voltage to change
Since this has now been released, I think you need this follow-up fix in
3.0.y and 3.4.y:
---
From: Ben Hutchings
Subject: hwmon: sht15: Fix memory leak if regulator_enable() fails
Date: Sat, 16 Mar 2013 04:11:01 +
Commit 3e78080f8148 ('hwmon: (sht15) Check return value of
regulator_enable()') depends on the use of devm_kmalloc() for automatic
resource cleanup in the failure cases, which was introduced in 3.7. In
older stable branches, explicit cleanup is needed.
Signed-off-by: Ben Hutchings
---
--- a/drivers/hwmon/sht15.c
+++ b/drivers/hwmon/sht15.c
@@ -930,7 +930,7 @@
if (ret != 0) {
dev_err(>dev,
"failed to enable regulator: %d\n", ret);
- return ret;
+ goto err_free_data;
}
/*
--
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] pm: print the name of failed suspend function for platform device
A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Sat, Mar 16, 2013 at 01:22:31AM +, Liu, Chuansheng wrote: > Hello Greg, > > Double checked, there is no your response before. > Can you consider it again? Thanks. Consider what? I get about 250 patches a _week_, I honestly do not remember your specific patch, nor do I have it anywhere in front of me. > Since we have printed the failure info, why not enhance it a bit:) > > Example without this patch: > pm_op(): platform_pm_suspend+0x0/0x50 returns -11 > PM: Device power.0 failed to suspend: error -11 > > And with this patch: > platform_pm_suspend(): power_suspend+0x0/0x30 returns -11 > pm_op(): platform_pm_suspend+0x0/0x80 returns -11 > PM: Device power.0 failed to suspend: error -11 Ok, fine, get the PM maintainer to accept the patch then, resend it, cc: the proper people and it will be considered. If I hate it, I'll tell you. 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/
[for-next][PATCH 6/9] tracing: Fix comment about prefix in arch_syscall_match_sym_name()
From: "zhangwei(Jovi)" ppc64 has its own syscall prefix like ".SyS" or ".sys". Make the comment in arch_syscall_match_sym_name() more understandable. Link: http://lkml.kernel.org/r/513d842f.40...@huawei.com Signed-off-by: zhangwei(Jovi) Signed-off-by: Steven Rostedt --- kernel/trace/trace_syscalls.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c index 68f3f34..8f2ac73 100644 --- a/kernel/trace/trace_syscalls.c +++ b/kernel/trace/trace_syscalls.c @@ -37,7 +37,7 @@ static inline bool arch_syscall_match_sym_name(const char *sym, const char *name /* * Only compare after the "sys" prefix. Archs that use * syscall wrappers may have syscalls symbols aliases prefixed -* with "SyS" instead of "sys", leading to an unwanted +* with ".SyS" or ".sys" instead of "sys", leading to an unwanted * mismatch. */ return !strcmp(sym + 3, name + 3); -- 1.7.10.4 signature.asc Description: This is a digitally signed message part
[for-next][PATCH 3/9] tracing: Use TRACE_MAX_PRINT instead of constant
From: "zhangwei(Jovi)"
TRACE_MAX_PRINT macro is defined, but is not used.
Link: http://lkml.kernel.org/r/513d8421.4070...@huawei.com
Signed-off-by: zhangwei(Jovi)
Signed-off-by: Steven Rostedt
---
kernel/trace/trace.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index bba1ba9..8486256 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -5978,8 +5978,8 @@ void
trace_printk_seq(struct trace_seq *s)
{
/* Probably should print a warning here. */
- if (s->len >= 1000)
- s->len = 1000;
+ if (s->len >= TRACE_MAX_PRINT)
+ s->len = TRACE_MAX_PRINT;
/* should be zero ended, but we are paranoid. */
s->buffer[s->len] = 0;
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
[for-next][PATCH 2/9] tracing: Use pr_warn_once instead of open coded implementation
From: "zhangwei(Jovi)"
Use pr_warn_once, instead of making an open coded implementation.
Link: http://lkml.kernel.org/r/513d8419.20...@huawei.com
Signed-off-by: zhangwei(Jovi)
Signed-off-by: Steven Rostedt
---
kernel/trace/trace.c |9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 7f0e7fa..bba1ba9 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -5205,8 +5205,6 @@ static inline int register_snapshot_cmd(void) { return 0;
}
struct dentry *tracing_init_dentry_tr(struct trace_array *tr)
{
- static int once;
-
if (tr->dir)
return tr->dir;
@@ -5216,11 +5214,8 @@ struct dentry *tracing_init_dentry_tr(struct trace_array
*tr)
if (tr->flags & TRACE_ARRAY_FL_GLOBAL)
tr->dir = debugfs_create_dir("tracing", NULL);
- if (!tr->dir && !once) {
- once = 1;
- pr_warning("Could not create debugfs directory 'tracing'\n");
- return NULL;
- }
+ if (!tr->dir)
+ pr_warn_once("Could not create debugfs directory 'tracing'\n");
return tr->dir;
}
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
[for-next][PATCH 4/9] tracing: Move find_event_field() into trace_events.c
From: "zhangwei(Jovi)"
By moving find_event_field() and trace_find_field() into trace_events.c,
the ftrace_common_fields list and trace_get_fields() can become local to
the trace_events.c file.
find_event_field() is renamed to trace_find_event_field() to conform to
the tracing global function names.
Link: http://lkml.kernel.org/r/513d8426.9070...@huawei.com
Signed-off-by: zhangwei(Jovi)
[ rostedt: Modified trace_find_field() to trace_find_event_field() ]
Signed-off-by: Steven Rostedt
---
kernel/trace/trace.h |6 ++
kernel/trace/trace_events.c| 31 +--
kernel/trace/trace_events_filter.c | 29 +
3 files changed, 32 insertions(+), 34 deletions(-)
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 5cc5236..9e01458 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -995,8 +995,6 @@ struct filter_pred {
unsigned short right;
};
-extern struct list_head ftrace_common_fields;
-
extern enum regex_type
filter_parse_regex(char *buff, int len, char **search, int *not);
extern void print_event_filter(struct ftrace_event_call *call,
@@ -1009,8 +1007,8 @@ extern void print_subsystem_event_filter(struct
event_subsystem *system,
struct trace_seq *s);
extern int filter_assign_type(const char *type);
-struct list_head *
-trace_get_fields(struct ftrace_event_call *event_call);
+struct ftrace_event_field *
+trace_find_event_field(struct ftrace_event_call *call, char *name);
static inline int
filter_check_discard(struct ftrace_event_call *call, void *rec,
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index c636523..ba523d7 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -34,7 +34,7 @@ char event_storage[EVENT_STORAGE_SIZE];
EXPORT_SYMBOL_GPL(event_storage);
LIST_HEAD(ftrace_events);
-LIST_HEAD(ftrace_common_fields);
+static LIST_HEAD(ftrace_common_fields);
#define GFP_TRACE (GFP_KERNEL | __GFP_ZERO)
@@ -54,7 +54,7 @@ static struct kmem_cache *file_cachep;
#define while_for_each_event_file()\
}
-struct list_head *
+static struct list_head *
trace_get_fields(struct ftrace_event_call *event_call)
{
if (!event_call->class->get_fields)
@@ -62,6 +62,33 @@ trace_get_fields(struct ftrace_event_call *event_call)
return event_call->class->get_fields(event_call);
}
+static struct ftrace_event_field *
+__find_event_field(struct list_head *head, char *name)
+{
+ struct ftrace_event_field *field;
+
+ list_for_each_entry(field, head, link) {
+ if (!strcmp(field->name, name))
+ return field;
+ }
+
+ return NULL;
+}
+
+struct ftrace_event_field *
+trace_find_event_field(struct ftrace_event_call *call, char *name)
+{
+ struct ftrace_event_field *field;
+ struct list_head *head;
+
+ field = __find_event_field(_common_fields, name);
+ if (field)
+ return field;
+
+ head = trace_get_fields(call);
+ return __find_event_field(head, name);
+}
+
static int __trace_define_field(struct list_head *head, const char *type,
const char *name, int offset, int size,
int is_signed, int filter_type)
diff --git a/kernel/trace/trace_events_filter.c
b/kernel/trace/trace_events_filter.c
index 2a22a17..a636117 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -658,33 +658,6 @@ void print_subsystem_event_filter(struct event_subsystem
*system,
mutex_unlock(_mutex);
}
-static struct ftrace_event_field *
-__find_event_field(struct list_head *head, char *name)
-{
- struct ftrace_event_field *field;
-
- list_for_each_entry(field, head, link) {
- if (!strcmp(field->name, name))
- return field;
- }
-
- return NULL;
-}
-
-static struct ftrace_event_field *
-find_event_field(struct ftrace_event_call *call, char *name)
-{
- struct ftrace_event_field *field;
- struct list_head *head;
-
- field = __find_event_field(_common_fields, name);
- if (field)
- return field;
-
- head = trace_get_fields(call);
- return __find_event_field(head, name);
-}
-
static int __alloc_pred_stack(struct pred_stack *stack, int n_preds)
{
stack->preds = kcalloc(n_preds + 1, sizeof(*stack->preds), GFP_KERNEL);
@@ -1337,7 +1310,7 @@ static struct filter_pred *create_pred(struct
filter_parse_state *ps,
return NULL;
}
- field = find_event_field(call, operand1);
+ field = trace_find_event_field(call, operand1);
if (!field) {
parse_error(ps, FILT_ERR_FIELD_NOT_FOUND, 0);
return NULL;
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
[for-next][PATCH 5/9] tracing: Convert trace_destroy_fields() to static
From: "zhangwei(Jovi)"
trace_destroy_fields() is not used outside of the file. It can be
a static function.
Link: http://lkml.kernel.org/r/513d842a.2000...@huawei.com
Signed-off-by: zhangwei(Jovi)
Signed-off-by: Steven Rostedt
---
kernel/trace/trace_events.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index ba523d7..a71cdc3 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -158,7 +158,7 @@ static int trace_define_common_fields(void)
return ret;
}
-void trace_destroy_fields(struct ftrace_event_call *call)
+static void trace_destroy_fields(struct ftrace_event_call *call)
{
struct ftrace_event_field *field, *next;
struct list_head *head;
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
[for-next][PATCH 7/9] tracing: Rename trace_event_mutex to trace_event_sem
From: "zhangwei(Jovi)"
trace_event_mutex is an rw semaphore now, not a mutex, change the name.
Link: http://lkml.kernel.org/r/513d843b.40...@huawei.com
Signed-off-by: zhangwei(Jovi)
[ Forward ported to my new code ]
Signed-off-by: Steven Rostedt
---
kernel/trace/trace_events.c | 22 +++---
kernel/trace/trace_output.c | 16
kernel/trace/trace_output.h |2 +-
3 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index a71cdc3..53582e9 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -1584,7 +1584,7 @@ int trace_add_event_call(struct ftrace_event_call *call)
}
/*
- * Must be called under locking both of event_mutex and trace_event_mutex.
+ * Must be called under locking both of event_mutex and trace_event_sem.
*/
static void __trace_remove_event_call(struct ftrace_event_call *call)
{
@@ -1597,9 +1597,9 @@ static void __trace_remove_event_call(struct
ftrace_event_call *call)
void trace_remove_event_call(struct ftrace_event_call *call)
{
mutex_lock(_mutex);
- down_write(_event_mutex);
+ down_write(_event_sem);
__trace_remove_event_call(call);
- up_write(_event_mutex);
+ up_write(_event_sem);
mutex_unlock(_mutex);
}
@@ -1707,7 +1707,7 @@ static void trace_module_remove_events(struct module *mod)
struct ftrace_event_call *call, *p;
bool clear_trace = false;
- down_write(_event_mutex);
+ down_write(_event_sem);
list_for_each_entry_safe(call, p, _events, list) {
if (call->mod == mod) {
if (call->flags & TRACE_EVENT_FL_WAS_ENABLED)
@@ -1725,7 +1725,7 @@ static void trace_module_remove_events(struct module *mod)
list_del(_ops->list);
kfree(file_ops);
}
- up_write(_event_mutex);
+ up_write(_event_sem);
/*
* It is safest to reset the ring buffer if the module being unloaded
@@ -2262,9 +2262,9 @@ int event_trace_add_tracer(struct dentry *parent, struct
trace_array *tr)
if (ret)
goto out_unlock;
- down_write(_event_mutex);
+ down_write(_event_sem);
__trace_add_event_dirs(tr);
- up_write(_event_mutex);
+ up_write(_event_sem);
out_unlock:
mutex_unlock(_mutex);
@@ -2287,9 +2287,9 @@ early_event_add_tracer(struct dentry *parent, struct
trace_array *tr)
if (ret)
goto out_unlock;
- down_write(_event_mutex);
+ down_write(_event_sem);
__trace_early_add_event_dirs(tr);
- up_write(_event_mutex);
+ up_write(_event_sem);
out_unlock:
mutex_unlock(_mutex);
@@ -2304,10 +2304,10 @@ int event_trace_del_tracer(struct trace_array *tr)
mutex_lock(_mutex);
- down_write(_event_mutex);
+ down_write(_event_sem);
__trace_remove_event_dirs(tr);
debugfs_remove_recursive(tr->event_dir);
- up_write(_event_mutex);
+ up_write(_event_sem);
tr->event_dir = NULL;
diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index 19f48e7..f475b2a 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -14,7 +14,7 @@
/* must be a power of 2 */
#define EVENT_HASHSIZE 128
-DECLARE_RWSEM(trace_event_mutex);
+DECLARE_RWSEM(trace_event_sem);
static struct hlist_head event_hash[EVENT_HASHSIZE] __read_mostly;
@@ -826,12 +826,12 @@ static int trace_search_list(struct list_head **list)
void trace_event_read_lock(void)
{
- down_read(_event_mutex);
+ down_read(_event_sem);
}
void trace_event_read_unlock(void)
{
- up_read(_event_mutex);
+ up_read(_event_sem);
}
/**
@@ -854,7 +854,7 @@ int register_ftrace_event(struct trace_event *event)
unsigned key;
int ret = 0;
- down_write(_event_mutex);
+ down_write(_event_sem);
if (WARN_ON(!event))
goto out;
@@ -909,14 +909,14 @@ int register_ftrace_event(struct trace_event *event)
ret = event->type;
out:
- up_write(_event_mutex);
+ up_write(_event_sem);
return ret;
}
EXPORT_SYMBOL_GPL(register_ftrace_event);
/*
- * Used by module code with the trace_event_mutex held for write.
+ * Used by module code with the trace_event_sem held for write.
*/
int __unregister_ftrace_event(struct trace_event *event)
{
@@ -931,9 +931,9 @@ int __unregister_ftrace_event(struct trace_event *event)
*/
int unregister_ftrace_event(struct trace_event *event)
{
- down_write(_event_mutex);
+ down_write(_event_sem);
__unregister_ftrace_event(event);
- up_write(_event_mutex);
+ up_write(_event_sem);
return 0;
}
diff --git a/kernel/trace/trace_output.h b/kernel/trace/trace_output.h
index af77870..127a9d8 100644
--- a/kernel/trace/trace_output.h
+++ b/kernel/trace/trace_output.h
@@
[for-next][PATCH 9/9] tracing: Update debugfs README file
From: "Steven Rostedt (Red Hat)"
Update the README file in debugfs/tracing to something more useful.
What's currently in the file is very old and what it shows doesn't
have much use. Heck, it tells you how to mount debugfs! But to read
this file you would have already needed to mount it.
Replace the file with current up-to-date information. It's rather
limited, but what do you expect from a pseudo README file.
Signed-off-by: Steven Rostedt
---
kernel/trace/trace.c | 89 ++
1 file changed, 75 insertions(+), 14 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 3dc7999..83ad596 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3300,20 +3300,81 @@ static const struct file_operations tracing_iter_fops =
{
static const char readme_msg[] =
"tracing mini-HOWTO:\n\n"
- "# mount -t debugfs nodev /sys/kernel/debug\n\n"
- "# cat /sys/kernel/debug/tracing/available_tracers\n"
- "wakeup wakeup_rt preemptirqsoff preemptoff irqsoff function nop\n\n"
- "# cat /sys/kernel/debug/tracing/current_tracer\n"
- "nop\n"
- "# echo wakeup > /sys/kernel/debug/tracing/current_tracer\n"
- "# cat /sys/kernel/debug/tracing/current_tracer\n"
- "wakeup\n"
- "# cat /sys/kernel/debug/tracing/trace_options\n"
- "noprint-parent nosym-offset nosym-addr noverbose\n"
- "# echo print-parent > /sys/kernel/debug/tracing/trace_options\n"
- "# echo 1 > /sys/kernel/debug/tracing/tracing_on\n"
- "# cat /sys/kernel/debug/tracing/trace > /tmp/trace.txt\n"
- "# echo 0 > /sys/kernel/debug/tracing/tracing_on\n"
+ "# echo 0 > tracing_on : quick way to disable tracing\n"
+ "# echo 1 > tracing_on : quick way to re-enable tracing\n\n"
+ " Important files:\n"
+ " trace\t\t\t- The static contents of the buffer\n"
+ "\t\t\t To clear the buffer write into this file: echo > trace\n"
+ " trace_pipe\t\t- A consuming read to see the contents of the buffer\n"
+ " current_tracer\t- function and latency tracers\n"
+ " available_tracers\t- list of configured tracers for current_tracer\n"
+ " buffer_size_kb\t- view and modify size of per cpu buffer\n"
+ " buffer_total_size_kb - view total size of all cpu buffers\n\n"
+ " trace_clock\t\t-change the clock used to order events\n"
+ " local: Per cpu clock but may not be synced across CPUS\n"
+ " global: Synced across CPUs but slows tracing down.\n"
+ " counter: Not a clock, but just an increment\n"
+ " uptime: Jiffy counter from time of boot\n"
+ "perf: Same clock that perf events use\n"
+#ifdef CONFIG_X86_64
+ " x86-tsc: TSC cycle counter\n"
+#endif
+ "\n trace_marker\t\t- Writes into this file writes into the kernel
buffer\n"
+ " tracing_cpumask\t- Limit which CPUs to trace\n"
+ " instances\t\t- Make sub-buffers with: mkdir instances/foo\n"
+ "\t\t\t Remove sub-buffer with rmdir\n"
+ " trace_options\t\t- Set format or modify how tracing happens\n"
+ "\t\t\t Disable an option by adding a suffix 'no' to the option name\n"
+#ifdef CONFIG_DYNAMIC_FTRACE
+ "\n available_filter_functions - list of functions that can be
filtered on\n"
+ " set_ftrace_filter\t- echo function name in here to only trace these
functions\n"
+ "accepts: func_full_name, *func_end, func_begin*,
*func_middle*\n"
+ "modules: Can select a group via module\n"
+ " Format: :mod:\n"
+ " example: echo :mod:ext3 > set_ftrace_filter\n"
+ "triggers: a command to perform when function is hit\n"
+ " Format: :[:count]\n"
+ " trigger: traceon, traceoff\n"
+ " enable_event::\n"
+ " disable_event::\n"
+#ifdef CONFIG_STACKTRACE
+ " stacktrace\n"
+#endif
+#ifdef CONFIG_TRACER_SNAPSHOT
+ " snapshot\n"
+#endif
+ " example: echo do_fault:traceoff > set_ftrace_filter\n"
+ " echo do_trap:traceoff:3 > set_ftrace_filter\n"
+ " The first one will disable tracing everytime do_fault is
hit\n"
+ " The second will disable tracing at most 3 times whne
do_trap is hit\n"
+ " To remove trigger without count:\n"
+ " echo '!: > set_ftrace_filter\n"
+ " To remove trigger with a count:\n"
+ " echo '!::0 > set_ftrace_filter\n"
+ " set_ftrace_notrace\t- echo function name in here to never trace.\n"
+ "accepts: func_full_name, *func_end, func_begin*,
*func_middle*\n"
+ "modules: Can select a group via module command :mod:\n"
+ "Does not accept
Re: udelay function delays the wrong time interval in multiprocessor system, if ARCH_HAS_READ_CURRENT_TIMER is not defined and on current timer is used.
On Sat, Mar 16, 2013 at 2:14 AM, Russell King - ARM Linux wrote: > We don't support different CPUs running at different frequencies with > the delay loop. Sorry. Does it means that a timer-based delay implementation must be used to get an accurate delay in SMP. I think it should print a warning message if the CPU delay loop is used in SMP. In my system, the wrong delay interval fluctuated with CPU frequencies caused a control problem. -- 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/
[for-next][PATCH 8/9] tracing: Fix ftrace_dump()
From: "Steven Rostedt (Red Hat)"
ftrace_dump() had a lot of issues. What ftrace_dump() does, is when
ftrace_dump_on_oops is set (via a kernel parameter or sysctl), it
will dump out the ftrace buffers to the console when either a oops,
panic, or a sysrq-z occurs.
This was written a long time ago when ftrace was fragile to recursion.
But it wasn't written well even for that.
There's a possible deadlock that can occur if a ftrace_dump() is happening
and an NMI triggers another dump. This is because it grabs a lock
before checking if the dump ran.
It also totally disables ftrace, and tracing for no good reasons.
As the ring_buffer now checks if it is read via a oops or NMI, where
there's a chance that the buffer gets corrupted, it will disable
itself. No need to have ftrace_dump() do the same.
ftrace_dump() is now cleaned up where it uses an atomic counter to
make sure only one dump happens at a time. A simple atomic_inc_return()
is enough that is needed for both other CPUs and NMIs. No need for
a spinlock, as if one CPU is running the dump, no other CPU needs
to do it too.
The tracing_on variable is turned off and not turned on. The original
code did this, but it wasn't pretty. By just disabling this variable
we get the result of not seeing traces that happen between crashes.
For sysrq-z, it doesn't get turned on, but the user can always write
a '1' to the tracing_on file. If they are using sysrq-z, then they should
know about tracing_on.
The new code is much easier to read and less error prone. No more
deadlock possibility when an NMI triggers here.
Reported-by: zhangwei(Jovi)
Cc: sta...@vger.kernel.org
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Frederic Weisbecker
Signed-off-by: Steven Rostedt
---
kernel/trace/trace.c | 62 +
kernel/trace/trace_selftest.c |9 +++---
2 files changed, 31 insertions(+), 40 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 8486256..3dc7999 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -5997,36 +5997,32 @@ void trace_init_global_iter(struct trace_iterator *iter)
iter->trace_buffer = _trace.trace_buffer;
}
-static void
-__ftrace_dump(bool disable_tracing, enum ftrace_dump_mode oops_dump_mode)
+void ftrace_dump(enum ftrace_dump_mode oops_dump_mode)
{
- static arch_spinlock_t ftrace_dump_lock =
- (arch_spinlock_t)__ARCH_SPIN_LOCK_UNLOCKED;
/* use static because iter can be a bit big for the stack */
static struct trace_iterator iter;
+ static atomic_t dump_running;
unsigned int old_userobj;
- static int dump_ran;
unsigned long flags;
int cnt = 0, cpu;
- /* only one dump */
- local_irq_save(flags);
- arch_spin_lock(_dump_lock);
- if (dump_ran)
- goto out;
-
- dump_ran = 1;
+ /* Only allow one dump user at a time. */
+ if (atomic_inc_return(_running) != 1) {
+ atomic_dec(_running);
+ return;
+ }
+ /*
+* Always turn off tracing when we dump.
+* We don't need to show trace output of what happens
+* between multiple crashes.
+*
+* If the user does a sysrq-z, then they can re-enable
+* tracing with echo 1 > tracing_on.
+*/
tracing_off();
- /* Did function tracer already get disabled? */
- if (ftrace_is_dead()) {
- printk("# WARNING: FUNCTION TRACING IS CORRUPTED\n");
- printk("# MAY BE MISSING FUNCTION EVENTS\n");
- }
-
- if (disable_tracing)
- ftrace_kill();
+ local_irq_save(flags);
/* Simulate the iterator */
trace_init_global_iter();
@@ -6056,6 +6052,12 @@ __ftrace_dump(bool disable_tracing, enum
ftrace_dump_mode oops_dump_mode)
printk(KERN_TRACE "Dumping ftrace buffer:\n");
+ /* Did function tracer already get disabled? */
+ if (ftrace_is_dead()) {
+ printk("# WARNING: FUNCTION TRACING IS CORRUPTED\n");
+ printk("# MAY BE MISSING FUNCTION EVENTS\n");
+ }
+
/*
* We need to stop all tracing on all CPUS to read the
* the next buffer. This is a bit expensive, but is
@@ -6095,26 +6097,14 @@ __ftrace_dump(bool disable_tracing, enum
ftrace_dump_mode oops_dump_mode)
printk(KERN_TRACE "-\n");
out_enable:
- /* Re-enable tracing if requested */
- if (!disable_tracing) {
- trace_flags |= old_userobj;
+ trace_flags |= old_userobj;
- for_each_tracing_cpu(cpu) {
- atomic_dec(_cpu_ptr(iter.trace_buffer->data,
cpu)->disabled);
- }
- tracing_on();
+ for_each_tracing_cpu(cpu) {
+ atomic_dec(_cpu_ptr(iter.trace_buffer->data,
cpu)->disabled);
}
-
- out:
-
[for-next][PATCH 1/9] ring-buffer: Add ring buffer startup selftest
From: "Steven Rostedt (Red Hat)"
When testing my large changes to the ftrace system, there was
a bug that looked like the ring buffer was dropping events.
I wrote up a quick integrity checker of the ring buffer to
see if it was.
Although the bug ended up being something stupid I did in ftrace,
and had nothing to do with the ring buffer, I figured if I spent
the time to write up this test, I might as well include it in the
kernel.
I cleaned it up a bit, as the original version was rather ugly.
Not saying this version is pretty, but it's a beauty queen
compared to what I original wrote.
To enable the start up test, set CONFIG_RING_BUFFER_STARTUP_TEST.
Note, it runs for 10 seconds, so it will slow your boot time
by at least 10 more seconds.
What it does is documented in both the comments and the Kconfig
help.
Signed-off-by: Steven Rostedt
---
kernel/trace/Kconfig | 23
kernel/trace/ring_buffer.c | 319
2 files changed, 342 insertions(+)
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index f78eab2..0b5ecf5 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -565,6 +565,29 @@ config RING_BUFFER_BENCHMARK
If unsure, say N.
+config RING_BUFFER_STARTUP_TEST
+ bool "Ring buffer startup self test"
+ depends on RING_BUFFER
+ help
+ Run a simple self test on the ring buffer on boot up. Late in the
+kernel boot sequence, the test will start that kicks off
+a thread per cpu. Each thread will write various size events
+into the ring buffer. Another thread is created to send IPIs
+to each of the threads, where the IPI handler will also write
+to the ring buffer, to test/stress the nesting ability.
+If any anomalies are discovered, a warning will be displayed
+and all ring buffers will be disabled.
+
+The test runs for 10 seconds. This will slow your boot time
+by at least 10 more seconds.
+
+At the end of the test, statics and more checks are done.
+It will output the stats of each per cpu buffer. What
+was written, the sizes, what was read, what was lost, and
+other similar details.
+
+If unsure, say N
+
endif # FTRACE
endif # TRACING_SUPPORT
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index d1c85c5..e5472f7 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -12,10 +12,12 @@
#include
#include
#include
+#include /* for self test */
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -4634,3 +4636,320 @@ static int rb_cpu_notify(struct notifier_block *self,
return NOTIFY_OK;
}
#endif
+
+#ifdef CONFIG_RING_BUFFER_STARTUP_TEST
+/*
+ * This is a basic integrity check of the ring buffer.
+ * Late in the boot cycle this test will run when configured in.
+ * It will kick off a thread per CPU that will go into a loop
+ * writing to the per cpu ring buffer various sizes of data.
+ * Some of the data will be large items, some small.
+ *
+ * Another thread is created that goes into a spin, sending out
+ * IPIs to the other CPUs to also write into the ring buffer.
+ * this is to test the nesting ability of the buffer.
+ *
+ * Basic stats are recorded and reported. If something in the
+ * ring buffer should happen that's not expected, a big warning
+ * is displayed and all ring buffers are disabled.
+ */
+static struct task_struct *rb_threads[NR_CPUS] __initdata;
+
+struct rb_test_data {
+ struct ring_buffer *buffer;
+ unsigned long events;
+ unsigned long bytes_written;
+ unsigned long bytes_alloc;
+ unsigned long bytes_dropped;
+ unsigned long events_nested;
+ unsigned long bytes_written_nested;
+ unsigned long bytes_alloc_nested;
+ unsigned long bytes_dropped_nested;
+ int min_size_nested;
+ int max_size_nested;
+ int max_size;
+ int min_size;
+ int cpu;
+ int cnt;
+};
+
+static struct rb_test_data rb_data[NR_CPUS] __initdata;
+
+/* 1 meg per cpu */
+#define RB_TEST_BUFFER_SIZE1048576
+
+static char rb_string[] __initdata =
+ "abcdefghijklmnopqrstuvwxyz1234567890!@#$%^&*()?+\\"
+ "?+|:';\",.<>/?abcdefghijklmnopqrstuvwxyz1234567890"
+ "!@#$%^&*()?+\\?+|:';\",.<>/?abcdefghijklmnopqrstuv";
+
+static bool rb_test_started __initdata;
+
+struct rb_item {
+ int size;
+ char str[];
+};
+
+static __init int rb_write_something(struct rb_test_data *data, bool nested)
+{
+ struct ring_buffer_event *event;
+ struct rb_item *item;
+ bool started;
+ int event_len;
+ int size;
+ int len;
+ int cnt;
+
+ /* Have nested writes
[for-next][PATCH 0/9] tracing: ring-buffer selftest, cleanups, ftrace_dump() fix and document
One more linux-next patch series. The first patch is a ring buffer boot time selftest. A bug in my development code looked like the ring buffer was dropping events, and I wrote a test to make sure that wasn't the case. The bug ended up being a stupid mistake in my development code, but the ring buffer test seemed like a good idea to include in the kernel as an option. Next is a series of clean ups by Jovi. Jovi also pointed out issues with ftrace_dump(). It's been on my todo list to clean up ftrace_dump() for a long time, and finally decided to do so. It wasn't hard and was quick to do. There was a long standing bug where an NMI triggering a dump while another dump was happening could cause a deadlock. I marked that patch for stable, but since its really just a debugging tool and I don't recall ever hitting the deadlock (I might have), I decided it can wait for 3.10 and I'll do the backports when I get the "Failed to apply" messages from Greg Kroah-Hartman's stable scripts. Last patch brings the README file in debugfs/tracing/ up to date with more useful information. Enjoy! -- Steve Steven Rostedt (Red Hat) (3): ring-buffer: Add ring buffer startup selftest tracing: Fix ftrace_dump() tracing: Update debugfs README file zhangwei(Jovi) (6): tracing: Use pr_warn_once instead of open coded implementation tracing: Use TRACE_MAX_PRINT instead of constant tracing: Move find_event_field() into trace_events.c tracing: Convert trace_destroy_fields() to static tracing: Fix comment about prefix in arch_syscall_match_sym_name() tracing: Rename trace_event_mutex to trace_event_sem kernel/trace/Kconfig | 23 +++ kernel/trace/ring_buffer.c | 319 kernel/trace/trace.c | 164 +++--- kernel/trace/trace.h |6 +- kernel/trace/trace_events.c| 55 +-- kernel/trace/trace_events_filter.c | 29 +--- kernel/trace/trace_output.c| 16 +- kernel/trace/trace_output.h|2 +- kernel/trace/trace_selftest.c |9 +- kernel/trace/trace_syscalls.c |2 +- 10 files changed, 506 insertions(+), 119 deletions(-) signature.asc Description: This is a digitally signed message part
Re: New MFD tree for linux-next
Hi Samuel, On Fri, 15 Mar 2013 17:46:25 +0100 Samuel Ortiz wrote: > > On Thu, Mar 14, 2013 at 01:02:01AM +0100, Samuel Ortiz wrote: > > > > I am moving the MFD development from mfd-2.6.git/for-next to a new mfd-next > > tree: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-next.git > > > > Could you please point linux-next at it ? Many thanks in advance. Done. I assume that you are still using the for-next branch? > I'm also carrying MFD fixes through the mfd-fixes tree: > > git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-fixes.git > > Could you please also add it to linux-next ? What branch should I use of that? BTW, those two trees look very similar (in fact "diff -u <(git ls-remote mfd) <(git ls-remote mfd-fixes)" only shows a couple of differences in all the refs). You do realise that I can use 2 different branches of one tree, right (as can others)? -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpRBlNLy1uP2.pgp Description: PGP signature
Re: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare
On Sat, 2013-03-16 at 01:09 +0800, Russell King - ARM Linux wrote: > On Tue, Mar 12, 2013 at 10:40:04PM -0700, Bill Huang wrote: > > That will be too bad, it looks like we deadlock in the mechanism, we > > cannot change existing drivers behavior (that means some call > > clk_disable/enable directly, some are not), and we cannot hook notifier > > in clk_disable/enable either, that means there seems no any chance to > > get what we want, any idea? > > Look, the whole point is: > > - Drivers can call clk_enable/clk_disable from their atomic regions to > control the clock. Drivers which do this also call clk_prepare/ > clk_unprepare from a schedulable context to perform any operations > necessary to allow the clock to be used. > > - Drivers which only ever control the clock from a schedulable context > *can* use clk_prepare_enable()/clk_disable_unprepare() to control > their clock, which simplifies the coding in the driver. > > The whole point here is to cater for what is found on different SoCs and > not need to keep rewriting the drivers between different SoCs. > > So, the idea is that: > > - clk_prepare() does whatever is needed to prepare a clock for use which > may require waiting for the clock to be in a state which it can be > enabled. In other words, if there is a PLL, the PLL is setup and > we wait for it to report that it has locked. > > - clk_enable() is about turning the clock output on so that the device > receives the clock. > > Now, in the case of a PLL directly feeding a device, it's entirely possible > that clk_prepare() ends up providing the clock signal to the device, and > clk_enable() does absolutely nothing. > > Or, if the clock has a gate on it, it's entirely possible that clk_prepare() > does nothing, and clk_enable() unmasks the gate to allow the clock to be > provided to the device - which can happen from atomic contexts. > > The whole point about the separation of these two functions is that device > driver writers _can_ code their drivers for both situations and not care > about how the SoC implements the clocking at all. > > Why did we end up with this split in the first place? Because we ran into > the problem that some SoCs required a sleeping clk_enable() and others > didn't, and the whole thing was turning into an incompatible mess. > > So, please. Realise that clk_prepare() and clk_enable() are the _official_ > APIs, and that clk_prepare_enable() is merely a helper function for drivers > to allow them to automate the calling of those two functions in succession > with _no_ _further_ _processing_ at all. > > So, if your hooks need to be callable from schedulable contexts, then you > need to put them inside clk_prepare(). If your hooks are callable from > atomic contexts, then they can go into clk_enable(). But what you can > not do is put them into clk_prepare_enable(). Thanks a lot for good point. -- 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 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare
On Fri, 2013-03-15 at 20:33 +0800, Ulf Hansson wrote: > I guess you did not fully got what I meant with "dvfs clock type". It > will not affect the clock API. But instead the dvfs is handled by > implementing a specific clk hw type. So the same thing is accomplished > as with clk notifiers, no changes should be needed to device drivers. > > The difference is only that no notifiers will be needed, and all the > dvfs stuff will be handled in the clk hw instead. It will mean that we > will bundle dvfs stuff into the clock drivers, instead of separating > the code outside the clock drivers. But, on the other hand no > notifiers will be needed. > Oh yes I misunderstand your origin point, but my thought is using existing devfreq framework as frequency/voltage policy driver instead of creating another one in clock driver and that's why I think we need the notifier work. By the way, some centralized DVFS implementation like Tegra's VDD_CORE rail has association with tens of clocks which will need to be taken care specially if we're doing those in clock driver I think. > Kind regards > Ulf Hansson -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] backlight: ep93xx_bl: fix section mismatch
On 16/03/13 12:03, H Hartley Sweeten wrote:
> Remove the __init tag from ep93xxbl_probe() to fix the section
> mismatch warning.
>
> Signed-off-by: H Hartley Sweeten
> Cc: Ryan Mallon
> Cc: Richard Purdie
> Cc: Florian Tobias Schandinat
There is a patch for this already queued in Andrew Morton's tree.
~Ryan
> ---
> drivers/video/backlight/ep93xx_bl.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/video/backlight/ep93xx_bl.c
> b/drivers/video/backlight/ep93xx_bl.c
> index ef3e21e..17b8abb 100644
> --- a/drivers/video/backlight/ep93xx_bl.c
> +++ b/drivers/video/backlight/ep93xx_bl.c
> @@ -60,7 +60,7 @@ static const struct backlight_ops ep93xxbl_ops = {
> .get_brightness = ep93xxbl_get_brightness,
> };
>
> -static int __init ep93xxbl_probe(struct platform_device *dev)
> +static int ep93xxbl_probe(struct platform_device *dev)
> {
> struct ep93xxbl *ep93xxbl;
> struct backlight_device *bl;
> @@ -145,7 +145,6 @@ static struct platform_driver ep93xxbl_driver = {
> .suspend= ep93xxbl_suspend,
> .resume = ep93xxbl_resume,
> };
> -
> module_platform_driver(ep93xxbl_driver);
>
> MODULE_DESCRIPTION("EP93xx Backlight Driver");
--
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] KVM: MMU: fast invalid all mmio sptes
On Fri, 15 Mar 2013 23:29:53 +0800
Xiao Guangrong wrote:
> +/*
> + * The caller should protect concurrent access on
> + * kvm->arch.mmio_invalid_gen. Currently, it is used by
> + * kvm_arch_commit_memory_region and protected by kvm->slots_lock.
> + */
> +void kvm_mmu_invalid_mmio_spte(struct kvm *kvm)
kvm_mmu_invalidate_mmio_sptes() may be a better name.
Thanks,
Takuya
> +{
> + /* Ensure update memslot has been completed. */
> + smp_mb();
> +
> + trace_kvm_mmu_invalid_mmio_spte(kvm);
> +
> + /*
> + * The very rare case: if the generation-number is round,
> + * zap all shadow pages.
> + */
> + if (unlikely(kvm->arch.mmio_invalid_gen++ == MAX_GEN)) {
> + kvm->arch.mmio_invalid_gen = 0;
> + return kvm_mmu_zap_all(kvm);
> + }
> +}
> +
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 2/2] net: reset transport header if it was not set before transmission
On Fri, 2013-03-15 at 15:41 +0800, Jason Wang wrote: > Some drivers depends on transport_header to do packet transmission, but it was > unset in some cases (one example is macvtap driver which build skbs from > userspace and generate CHECKSUM_NONE packets). The driver may crash in those > cases since the transport_header was not valid. The problem becomes more > obvious > since commit fda55eca5a33f33ffcd4192c6b2d75179714a52c (net: introduce > skb_transport_header_was_set()) since it initializes transport_header to ~0U. > > So before passing the skb to driver, this patch reset the transport_header if > it > was not set to avoid such crash such as: > > hp-z800-04.qe.lab.eng.nay.redhat.com login: BUG: unable to handle kernel > paging > request at 8805166f760c > IP: [] ixgbe_xmit_frame_ring+0x220/0x5e0 [ixgbe] > PGD 1ece067 PUD 0 > Oops: [#1] SMP > Modules linked in: vhost_net tun nfsv3 nfs_acl nfsv4 auth_rpcgss nfs fscache > lockd autofs4 sunrpc openvswitch ipv6 iTCO_wdt iTCO_vendor_support hp_wmi > sparse_keymap rfkill acpi_cpufreq freq_table mperf coretemp kvm_intel kvm > crc32c_intel ghash_clmulni_intel microcode serio_raw pcspkr sg lpc_ich > mfd_core > tg3 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq > snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc i7core_edac > edac_core ixgbe dca ptp pps_core mdio ext4(F) mbcache(F) jbd2(F) sd_mod(F) > crc_t10dif(F) sr_mod(F) cdrom(F) firewire_ohci(F) firewire_core(F) > crc_itu_t(F) > aesni_intel(F) ablk_helper(F) cryptd(F) lrw(F) aes_x86_64(F) xts(F) > gf128mul(F) > floppy(F) mptsas(F) mptscsih(F) mptbase(F) scsi_transport_sas(F) ahci(F) > libahci(F) nouveau(F) ttm(F) drm_kms_helper(F) drm(F) i2c_algo_bit(F) > i2c_core(F) mxm_wmi(F) video(F) wmi(F) dm_mirror(F) dm_region_hash(F) > dm_log(F) > dm_mod(F) [last unloaded: tun] > CPU 6 > Pid: 17337, comm: vhost-17317 Tainted: GF3.9.0-rc1+ #7 > Hewlett-Packard HP Z800 Workstation/0AECh > RIP: 0010:[] [] > ixgbe_xmit_frame_ring+0x220/0x5e0 [ixgbe] > RSP: 0018:880222cddb18 EFLAGS: 00010286 > RAX: RBX: 880416b4b000 RCX: 8805166f75ff > RDX: 0008 RSI: 8804166f760e RDI: 0007 > RBP: 880222cddb68 R08: 0008 R09: > R10: R11: R12: c90009dce120 > R13: 880416b4b300 R14: R15: 8804118f0800 > FS: () GS:88042fc4() knlGS: > CS: 0010 DS: ES: CR0: 8005003b > CR2: 8805166f760c CR3: 00041e98c000 CR4: 27e0 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0400 > Process vhost-17317 (pid: 17337, threadinfo 880222cdc000, task > 8802211d4040) > Stack: > 0180 880222cddbb7 0180 > 880222cddb48 88040d5dd1c0 8804118f 0036 > 8804118f 8804165d7a9c 880222cddb88 a035a9d3 > Call Trace: > [] ixgbe_xmit_frame+0x43/0x90 [ixgbe] > [] dev_hard_start_xmit+0x12a/0x570 > [] sch_direct_xmit+0xfa/0x1d0 > [] dev_queue_xmit+0x198/0x4c0 > [] macvlan_start_xmit+0x6a/0x170 > [] macvtap_get_user+0x404/0x4e0 > [] macvtap_sendmsg+0x2b/0x30 > [] handle_tx+0x34a/0x680 [vhost_net] > [] handle_tx_kick+0x15/0x20 [vhost_net] > [] vhost_worker+0x10c/0x1c0 [vhost_net] > [] ? vhost_attach_cgroups_work+0x30/0x30 [vhost_net] > [] ? vhost_attach_cgroups_work+0x30/0x30 [vhost_net] > [] kthread+0xce/0xe0 > [] ? kthread_freezable_should_stop+0x70/0x70 > [] ret_from_fork+0x7c/0xb0 > [] ? kthread_freezable_should_stop+0x70/0x70 > Code: 34 31 0f 84 d3 01 00 00 66 83 fa 08 0f 85 b9 00 00 00 80 7e 09 06 0f 85 > af > 00 00 00 8b 80 cc 00 00 00 48 01 c1 0f 84 a0 00 00 00 <0f> b6 41 0d a8 01 0f > 85 > 94 00 00 00 a8 02 75 0a 41 3a 7d 5c 0f > RIP [] ixgbe_xmit_frame_ring+0x220/0x5e0 [ixgbe] > RSP > CR2: 8805166f760c > > Cc: Eric Dumazet > Signed-off-by: Jason Wang > --- > net/core/dev.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/net/core/dev.c b/net/core/dev.c > index 480114d..db315a1 100644 > --- a/net/core/dev.c > +++ b/net/core/dev.c > @@ -2525,6 +2525,9 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct > net_device *dev, > } > } > > + if (!skb_transport_header_was_set(skb)) > + skb_reset_transport_header(skb); > + > if (!list_empty(_all)) > dev_queue_xmit_nit(skb, dev); > Hmm... This really looks strange. Any way we can avoid adding this to fast path, for people not using macvtap and ixgbe ? -- 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
Re: [PATCH] USB: EHCI: fix for leaking isochronous data
On 14.03.2013 22:33, Alan Stern wrote: Maybe a better way to go about this is, instead of printing out every allocation and deallocation, to keep a running counter. You could have the driver print out the value of this counter every minute or so. Any time the device isn't in use, the counter should be 0. I implemented the counter. The max value is sampled at the beginning of end_free_itds(), the current counter value is sampled at the end of this function. Counter values w/o a max number are from the error path in itd_urb_transaction(). The number of allocated iTDs can grow to higher values (why?), but normally the iTDs are freed during normal operation. Due to some reason the number of iTDs suddenly increases until coherent pool exhaustion. There is no permanent memory leak, all iTDs are released when the user application ends. But imho several thousands of iTDs cannot be the intended behavior... Soeren Mar 16 01:12:52 guruvdr kernel: itd_counter:42 (max:174) Mar 16 01:12:52 guruvdr kernel: itd_counter:0 (max:174) Mar 16 01:13:13 guruvdr kernel: itd_counter:42 (max:174) Mar 16 01:13:13 guruvdr kernel: itd_counter:0 (max:174) Mar 16 01:13:34 guruvdr kernel: itd_counter:87 (max:174) Mar 16 01:13:34 guruvdr kernel: itd_counter:0 (max:174) Mar 16 01:13:55 guruvdr kernel: itd_counter:42 (max:426) Mar 16 01:13:55 guruvdr kernel: itd_counter:0 (max:426) Mar 16 01:15:14 guruvdr kernel: itd_counter:249 (max:1441) Mar 16 01:15:14 guruvdr kernel: itd_counter:0 (max:1441) [...] Mar 16 02:03:33 guruvdr kernel: itd_counter:0 (max:1441) Mar 16 02:04:15 guruvdr kernel: itd_counter:150 (max:1441) Mar 16 02:04:15 guruvdr kernel: itd_counter:0 (max:1441) Mar 16 02:04:36 guruvdr kernel: itd_counter:42 (max:1441) Mar 16 02:04:36 guruvdr kernel: itd_counter:0 (max:1441) Mar 16 02:04:57 guruvdr kernel: itd_counter:42 (max:1441) Mar 16 02:04:57 guruvdr kernel: itd_counter:0 (max:1441) Mar 16 02:05:18 guruvdr kernel: itd_counter:42 (max:1441) Mar 16 02:05:18 guruvdr kernel: itd_counter:0 (max:1441) Mar 16 02:05:39 guruvdr kernel: itd_counter:42 (max:1441) Mar 16 02:05:39 guruvdr kernel: itd_counter:0 (max:1441) Mar 16 02:06:43 guruvdr kernel: itd_counter:254 (max:1441) Mar 16 02:07:44 guruvdr kernel: itd_counter:968 (max:1469) Mar 16 02:08:04 guruvdr kernel: itd_counter:1192 (max:1469) Mar 16 02:08:46 guruvdr kernel: itd_counter:1812 (max:1854) Mar 16 02:09:07 guruvdr kernel: itd_counter:2117 (max:2159) Mar 16 02:09:28 guruvdr kernel: itd_counter:2482 (max:2524) Mar 16 02:09:49 guruvdr kernel: itd_counter:2791 (max:2833) Mar 16 02:10:10 guruvdr kernel: itd_counter:3088 (max:3409) Mar 16 02:10:31 guruvdr kernel: itd_counter:3402 (max:3444) Mar 16 02:10:52 guruvdr kernel: itd_counter:3689 (max:3731) Mar 16 02:11:13 guruvdr kernel: itd_counter:3950 (max:4073) Mar 16 02:11:34 guruvdr kernel: itd_counter:4264 (max:4306) Mar 16 02:11:55 guruvdr kernel: itd_counter:4525 (max:4567) Mar 16 02:12:16 guruvdr kernel: itd_counter:4803 (max:4845) Mar 16 02:12:37 guruvdr kernel: itd_counter:5028 (max:5070) Mar 16 02:13:19 guruvdr kernel: itd_counter:5549 (max:5843) Mar 16 02:13:40 guruvdr kernel: itd_counter:5836 (max:5878) Mar 16 02:14:01 guruvdr kernel: itd_counter:6133 (max:6238) Mar 16 02:14:06 guruvdr kernel: ERROR: 1024 KiB atomic DMA coherent pool is too small! Mar 16 02:14:06 guruvdr kernel: Please increase it with coherent_pool= kernel parameter! Mar 16 02:14:06 guruvdr kernel: itd_counter:6275 Mar 16 02:14:06 guruvdr kernel: orion-ehci orion-ehci.0: can't init itds Mar 16 02:14:06 guruvdr kernel: itd_counter:6275 Mar 16 02:14:06 guruvdr kernel: orion-ehci orion-ehci.0: can't init itds Mar 16 02:14:06 guruvdr kernel: itd_counter:6275 Mar 16 02:14:06 guruvdr kernel: orion-ehci orion-ehci.0: can't init itds Mar 16 02:14:06 guruvdr kernel: itd_counter:6275 Mar 16 02:14:06 guruvdr kernel: orion-ehci orion-ehci.0: can't init itds Mar 16 02:14:07 guruvdr kernel: itd_counter:6275 Mar 16 02:14:07 guruvdr kernel: orion-ehci orion-ehci.0: can't init itds Mar 16 02:14:07 guruvdr kernel: itd_counter:6275 Mar 16 02:14:07 guruvdr kernel: orion-ehci orion-ehci.0: can't init itds Mar 16 02:14:07 guruvdr kernel: itd_counter:6275 Mar 16 02:14:07 guruvdr kernel: orion-ehci orion-ehci.0: can't init itds Mar 16 02:14:07 guruvdr kernel: itd_counter:6275 Mar 16 02:14:07 guruvdr kernel: orion-ehci orion-ehci.0: can't init itds Mar 16 02:14:08 guruvdr kernel: itd_counter:6275 Mar 16 02:14:08 guruvdr kernel: orion-ehci orion-ehci.0: can't init itds Mar 16 02:14:08 guruvdr kernel: itd_counter:78 (max:6275) Mar 16 02:14:22 guruvdr kernel: itd_counter:0 (max:6275) -- 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: [ 04/21] target/pscsi: Fix page increment
On Tue, 2013-03-12 at 15:44 -0700, Greg Kroah-Hartman wrote:
> 3.0-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Asias He
>
> commit 472b72f2db7831d7dbe22ffdff4adee3bd49b05d upstream.
>
> The page++ is wrong. It makes bio_add_pc_page() pointing to a wrong page
> address if the 'while (len > 0 && data_len > 0) { ... }' loop is
> executed more than one once.
>
> Signed-off-by: Asias He
> Signed-off-by: Nicholas Bellinger
> Signed-off-by: Greg Kroah-Hartman
>
> ---
> drivers/target/target_core_pscsi.c |1 -
> 1 file changed, 1 deletion(-)
>
> --- a/drivers/target/target_core_pscsi.c
> +++ b/drivers/target/target_core_pscsi.c
> @@ -1210,7 +1210,6 @@ static int __pscsi_map_task_SG(
> bio = NULL;
> }
>
> - page++;
> len -= bytes;
> data_len -= bytes;
> off = 0;
So in case a fragment crosses a page boundary, we wrap around to the
beginning of the same page? That doesn't look right.
Ben.
--
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 1/5] Revert "KVM: x86: Optimize mmio spte zapping when, creating/moving memslot"
On Fri, 15 Mar 2013 23:26:59 +0800
Xiao Guangrong wrote:
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index d3c4787..61a5bb6 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -6991,7 +6991,7 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
>* mmio sptes.
>*/
> if ((change == KVM_MR_CREATE) || (change == KVM_MR_MOVE)) {
> - kvm_mmu_zap_mmio_sptes(kvm);
>
???
+ kvm_mmu_zap_all()
Takuya
--
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/5] KVM: MMU: fast invalid all mmio sptes
Still reading, but sounds great if this works! I did not like the idea of mmio-rmap based approach so much, but this would be really/perfectly scalable. Thanks, Takuya On Fri, 15 Mar 2013 23:26:16 +0800 Xiao Guangrong wrote: > The current way is holding hot mmu-lock and walking all shadow pages, this > is not scale. This patchset tries to introduce a very simple and scale way > to fast invalid all mmio sptes - it need not walk any shadow pages and hold > any locks. > > The idea is simple: > KVM maintains a global mmio invalid generation-number which is stored in > kvm->arch.mmio_invalid_gen and every mmio spte stores the current global > generation-number into his available bits when it is created. > > When KVM need zap all mmio sptes, it just simply increase the global > generation-number. When guests do mmio access, KVM intercepts a MMIO #PF > then it walks the shadow page table and get the mmio spte. If the > generation-number on the spte does not equal the global generation-number, > it will go to the normal #PF handler to update the mmio spte. > > Since 19 bits are used to store generation-number on mmio spte, the > generation-number can be round after 33554432 times. It is large enough > for nearly all most cases, but making the code be more strong, we zap all > shadow pages when the number is round. > > Note: after my patchset that fast zap all shadow pages, kvm_mmu_zap_all is > not a problem any more. The scalability is the same as zap mmio shadow page > > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Takuya Yoshikawa -- 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/1] mfd: palmas: Add power off control
On Sat, 2013-03-16 at 01:22 +0800, Stephen Warren wrote: > On 03/14/2013 11:51 PM, Bill Huang wrote: > > On Fri, 2013-03-15 at 13:19 +0800, Stephen Warren wrote: > >> On 03/14/2013 04:58 AM, Bill Huang wrote: > >>> Hook up "pm_power_off" to palmas power off routine if there is DT > >>> property "ti,system-power-controller" defined, so platform which is > >>> powered by this regulator can be powered off properly. > >> > >>> diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c > >> > >>> + pdata->pm_off = of_property_read_bool(node, > >>> + "ti,system-power-controller"); > >> > >> You would need to add that property to the DT binding documentation for > >> this device. > > > > Does it work that some time later Laxmain helps to add it when he > > submits his pmic bindings for Palmas? > > I'll note that Ian Lartey and Graeme Gregory actually seem to be the > people defining the PMIC bindings for Palmas. See: > > http://comments.gmane.org/gmane.linux.documentation/9948 > > Or is Laxman planning to send some updates to that? > > But irrespective of that no, I don't think that influences this at all; > if you introduce driver support for new DT content, then either that DT > content should already be documented in the binding, or this patch > should add it to the documentation. Thanks, here I just need to add a property into the DT bindings but currently there is no any Palmas binding document exist so that means I have to hold off the patch. -- 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 v2 1/1] clk: Add notifier support in clk_prepare/clk_unprepare
On Sat, 2013-03-16 at 03:51 +0800, Stephen Warren wrote:
> On 03/15/2013 11:45 AM, Russell King - ARM Linux wrote:
> > On Thu, Mar 14, 2013 at 02:31:04AM -0700, Bill Huang wrote:
> >> Add the below two notifier events so drivers which are interested in
> >> knowing the clock status can act accordingly. This is extremely useful
> >> in some of the DVFS (Dynamic Voltage Frequency Scaling) design.
> >>
> >> CLK_PREPARED
> >> CLK_UNPREPARED
> >>
> >> Signed-off-by: Bill Huang
> >> ---
> >> drivers/clk/clk.c |3 +++
> >> include/linux/clk.h |2 ++
> >> 2 files changed, 5 insertions(+)
> >>
> >> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> >> index ed87b24..3292cec 100644
> >> --- a/drivers/clk/clk.c
> >> +++ b/drivers/clk/clk.c
> >> @@ -550,6 +550,7 @@ void clk_unprepare(struct clk *clk)
> >> {
> >>mutex_lock(_lock);
> >>__clk_unprepare(clk);
> >> + __clk_notify(clk, CLK_UNPREPARED, clk->rate, clk->rate);
> >>mutex_unlock(_lock);
> >> }
> >> EXPORT_SYMBOL_GPL(clk_unprepare);
> >> @@ -598,6 +599,8 @@ int clk_prepare(struct clk *clk)
> >>
> >>mutex_lock(_lock);
> >>ret = __clk_prepare(clk);
> >> + if (!ret)
> >> + __clk_notify(clk, CLK_PREPARED, clk->rate, clk->rate);
> >
> > So, on prepare, we notify after we've prepared the clock. On unprepare,
> > we notify after the clock has been shut down. Are you sure that's the
> > correct ordering? Would it not be better to view it in a stack-like
> > fashion, iow:
>
> > get
> > prepare
> > notify-prepare
> > enable
> > disable
> > notify-unprepare
> > unprepare
> > put
>
> Yes, these should be stacked/nested better for consistency.
>
> But for DVFS, the voltage needs to be raised before the prepare body is
> run, so that if clk_prepare actually enables the clock, the voltage is
> already at the safe level required by that clock. Similarly, for
> unprepare, you can only lower the voltage after having turned off the
> clock, which is guaranteed after the unprepare body. So, I think you
> want to move the notifier for prepare in the code above (and rename it
> to pre/before_prepare?), rather than the notifier for unprepare.
Oh yes I should raised notify before prepare body is run.
>
> In order to cover more cases, you might have both
> {pre,post}_{un,}prepare notifiers, although I'm not sure when you'd use
> the other two options.
Right, maybe {pre,post}_{un,}prepare will be useful.
>
> >> diff --git a/include/linux/clk.h b/include/linux/clk.h
>
> >> +#define CLK_PREPARED BIT(3)
> >> +#define CLK_UNPREPAREDBIT(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: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare
On Sat, 2013-03-16 at 03:38 +0800, Stephen Warren wrote: > On 03/15/2013 06:33 AM, Ulf Hansson wrote: > > On 15 March 2013 13:06, Bill Huang wrote: > >> On Fri, 2013-03-15 at 18:08 +0800, Ulf Hansson wrote: > ... > >>> Some prerequisites; I think am in favor of using the clk API to > >>> trigger DVFS changes and then I agree on that clk_prepare|unprepare > >>> needs to be possible to track from a DVFS perspective. clk_set_rate is > >>> not enough. > >>> > >>> So if we decide to do the above (using the clk API to trigger DVFS > >>> changes), I believe we should discuss two possible solutions; > >>> - clk notifiers or.. > >>> - dvfs clock type. > >>> > >>> I am trying to make up my mind of what I think is the best solution. > >>> Have you considered "dvfs clock type"? > >>> I put some comments about this for "[PATCH 2/5] clk: notifier handler > >>> for dynamic voltage scaling" recently as well. > >>> > >>> What could the advantages/disadvantages be between the two options? > >> > >> I personally prefer clk notifiers since that's easy and all the existing > >> device drivers don't need to be modified, a new clock or API might be > >> more thoroughly considered (and hence maybe more graceful) but that > >> means we need more time to cook and many drivers need to plug into that > >> API when it comes out, a lot of test/verification or maybe chaos > >> follows, I'm not sure will that be a little overkill. > > > > I guess you did not fully got what I meant with "dvfs clock type". It > > will not affect the clock API. But instead the dvfs is handled by > > implementing a specific clk hw type. So the same thing is accomplished > > as with clk notifiers, no changes should be needed to device drivers. > > > > The difference is only that no notifiers will be needed, and all the > > dvfs stuff will be handled in the clk hw instead. It will mean that we > > will bundle dvfs stuff into the clock drivers, instead of separating > > the code outside the clock drivers. But, on the other hand no > > notifiers will be needed. > > The advantage here is that I assume that a notifier would continually > have to check whether the clock being modified was one that the DVFS > notifier cared about. By integrating the CVFS logic into the clk_hw Actually, we can register notifier only on clocks that DVFS care about. -- 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] pm: print the name of failed suspend function for platform device
Hello Greg, Double checked, there is no your response before. Can you consider it again? Thanks. Since we have printed the failure info, why not enhance it a bit:) Example without this patch: pm_op(): platform_pm_suspend+0x0/0x50 returns -11 PM: Device power.0 failed to suspend: error -11 And with this patch: platform_pm_suspend(): power_suspend+0x0/0x30 returns -11 pm_op(): platform_pm_suspend+0x0/0x80 returns -11 PM: Device power.0 failed to suspend: error -11 > -Original Message- > From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] > Sent: Saturday, March 16, 2013 3:20 AM > To: Liu, Chuansheng > Cc: Li, Fei; r...@sisk.pl; a...@linux-foundation.org; > linux-kernel@vger.kernel.org; ldewan...@nvidia.com > Subject: Re: [PATCH] pm: print the name of failed suspend function for > platform > device > > On Mon, Mar 11, 2013 at 01:41:28AM +, Liu, Chuansheng wrote: > > Hi Greg, > > > > I just noticed some other cases need the more log also. > > https://lkml.org/lkml/2013/3/8/71 > > > > Could you consider the below patch, thanks? > > Didn't I already consider it and respond? -- 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/
ptracing a task from core_pattern pipe
Hi, I was writing an application to ptrace a process which is dumping core from inside the pipe application for core_pattern. So for example you make core pattern equal to something like "|/bin/corepipe_app" then the kernel runs that app prior to actually killing the process that failed. Before the pipe application runs it puts SIGKILL on the pending signal list for the failed application. However the application can't run. This commit, 9899d11f654474d2d54ea52ceaa2a1f4db3abd68 seems to put a damper on ptracing the application at this point. So I wanted to see what you think of all this.. Can we add an exception to this which would allow operations on a task which is dumping core, but still has SIGKILL pending. The other way would be to not add SIGKILL till after the pipe app runs. As of right now I can PTRACE_ATTACH, but the operations all fail with -ESRCH . Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] driver-core: remove the duplicate assignment of kobj->parent in device_add
[resend it for sytax error in Message-ID] Sorry all. I just found there is a syntax error of Message-ID in the mail sent from my mutt. So all my reply maybe rejected by the mail server. Hope this time the mail can be accepted by the mail server. Sorry for the noise again. On Thu, Mar 07, 2013 at 11:22:44PM +0800, Wei Yang wrote: On Thu, Mar 07, 2013 at 03:49:12PM +0100, Bjørn Mork wrote: >[ not stripping any quoting to restore context for linux-kernel] > >Wei Yang writes: >> On Thu, Mar 07, 2013 at 12:33:19PM +0100, Bjørn Mork wrote: >>>Wei Yang writes: >>> kobject_add() will setup the kobject parent correctly. This patch removes the redundant code. Signed-off-by: Wei Yang Reviewed-by: Ram Pai Reviewed-by: Gavin Shan --- drivers/base/core.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index 369ae4e..6b0a859 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -1024,8 +1024,6 @@ int device_add(struct device *dev) parent = get_device(dev->parent); kobj = get_device_parent(dev, parent); - if (kobj) - dev->kobj.parent = kobj; /* use parent numa_node */ if (parent) @@ -1033,7 +1031,7 @@ int device_add(struct device *dev) /* first, register with generic layer. */ /* we require the name to be set before, and pass NULL */ - error = kobject_add(>kobj, dev->kobj.parent, NULL); + error = kobject_add(>kobj, kobj, NULL); if (error) goto Error; >>> >>> >>>You've submitted this exact same patch before and Greg asked a couple of >>>questions about it: https://lkml.org/lkml/2013/1/25/599 >>> >>>If this is a resubmission, then it would sure be nice if that was clear >>>from the subject and on. And I believe any previously asked questions >>>should be answered in some way. I see that you have responded to one of >>>them by moving part of the commit message to the cover letter, but still >>>without any answer to the question. >>> >>>To me this looks like you completely ignored Greg's review questions. Is >>>that so? >> >> Bjør, >> >> Thanks for your response. >> >> In my mail box, I just see one mail from Greg and replied. Below is my screen >> in my mutt. You see I replied and wait for the further comment for several >> days and send out another reply on Feb 02. Well not receive further comment. >> >> 976 Jan 23 Wei Yang( 37) [PATCH] driver-core: remove the >> duplicate assignment of kobj->parent in device_add >> 977 r Jan 25 Greg KH ( 17) `-> >> 978 r Jan 28 Wei Yang( 43) `-> >> 979 Feb 02 Wei Yang( 52) `-> >> >> Hmm... I am confused with this, maybe my mail box get some problem. >> Could you see this mail? Or if someone could see this mail, would you please >> reply so that I will be sure that I have really sent it out . >> >> BTW, no one see my reply? I looked in the url you mentioned, really not see >> my >> reply. I am sorry for that. > >I cannot answer where your reply may have gone. I do however note that >this reply to me went to every address on the CC list *except* >linux-kernel@vger.kernel.org. Why? That would make it appear as you >never answered me to 99.97% of the linux-kernel readers... I am not sure. Maybe this is my mistake. Thanks for pointing out. > >Anyway, the main point is really not whether your mail went anywhere or >not. If this was indeed an intentional resend, then I do expect it to >say so and to contain information about how previous review comments >were resolved. Most people would not rememeber your answer even it was >sent to the mailing list. > Thank you. Hmm, last time Greg asked some question about how my patch works and why I want to do this change. Since the mail was lost, we didn't continue the discussion. The last reply, which is not sent out, is attached below. So that we can continue the discussion and get more feedback. Hope this time the mail will not be lost. Greg, Thanks for your reply. My explanation below. On Fri, Jan 25, 2013 at 12:32:56PM -0800, Greg KH wrote: >On Wed, Jan 23, 2013 at 01:58:30PM +0800, Wei Yang wrote: >> kobject_add() will setup the kobject parent correctly. > >How so? The assignment of kobj->parent happens in kobject_add_varg, which is called by kobject_add. > >> This patch removes the redundant code. > >I don't know, how is it redundant? What is this causing? Is it somehow >slowing things down? I thought the assignment of kobj->parent happens twice. The first time is in the device_add, and the second time is in kobject_add/kobject_add_varg. This patch tried to remove the first time of assignment. I guess this will not have big impact on the performance, this is just a code refine. > >> Tested
[PATCH 2/3] video: ep93xx-fb.c: fix section mismatch and use module_platform_driver
Remove the __init tags from the ep93xxfb_calc_fbsize() and
ep93xxfb_alloc_videomem() functions to fix the section mismatch
warnings.
Use module_platform_driver() to remove the init/exit boilerplate.
Signed-off-by: H Hartley Sweeten
Cc: Ryan Mallon
Cc: Florian Tobias Schandinat
---
drivers/video/ep93xx-fb.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/video/ep93xx-fb.c b/drivers/video/ep93xx-fb.c
index e06cd5d..ee1ee54 100644
--- a/drivers/video/ep93xx-fb.c
+++ b/drivers/video/ep93xx-fb.c
@@ -419,7 +419,7 @@ static struct fb_ops ep93xxfb_ops = {
.fb_mmap= ep93xxfb_mmap,
};
-static int __init ep93xxfb_calc_fbsize(struct ep93xxfb_mach_info *mach_info)
+static int ep93xxfb_calc_fbsize(struct ep93xxfb_mach_info *mach_info)
{
int i, fb_size = 0;
@@ -441,7 +441,7 @@ static int __init ep93xxfb_calc_fbsize(struct
ep93xxfb_mach_info *mach_info)
return fb_size;
}
-static int __init ep93xxfb_alloc_videomem(struct fb_info *info)
+static int ep93xxfb_alloc_videomem(struct fb_info *info)
{
struct ep93xx_fbi *fbi = info->par;
char __iomem *virt_addr;
@@ -627,19 +627,7 @@ static struct platform_driver ep93xxfb_driver = {
.owner = THIS_MODULE,
},
};
-
-static int ep93xxfb_init(void)
-{
- return platform_driver_register(_driver);
-}
-
-static void __exit ep93xxfb_exit(void)
-{
- platform_driver_unregister(_driver);
-}
-
-module_init(ep93xxfb_init);
-module_exit(ep93xxfb_exit);
+module_platform_driver(ep93xxfb_driver);
MODULE_DESCRIPTION("EP93XX Framebuffer Driver");
MODULE_ALIAS("platform:ep93xx-fb");
--
1.8.1.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: Corrupt packets with ath5k
On 02/21/2013 01:29 AM, JA Magallón wrote: On 02/20/2013 08:58 PM, JA Magallón wrote: Hi all... I have a strange problem with latest kernels. When I update my netbook I get many "Installation failed, bad rpms:" mesages. First I thougt that the oldie cheap ssd was failing (it is an Aspire AOA110). But the updates work always fine when plugged to ethernet. Now i tried to copy a couple RPMS via ssh over wifi and got: mplayer-1.1-11.r35916.1.mga3.tainted.i586.rpm 100% 2192KB 2.1MB/s 00:00 Received disconnect from 192.168.1.51: 2: Packet corrupt lost connection Hardware/driver are these: 03:00.0 Ethernet controller: Atheros Communications Inc. AR242x / AR542x Wireless Network Adapter (PCI-Express) (rev 01) Subsystem: Foxconn International, Inc. Device e008 Kernel driver in use: ath5k Ist that hardware failing ? Is driver failing ? Other laptop/androids update fine with the router via wifi. Any idea ? I currently have 3.8.0, distro build. I tried with 3.7.1 and everything works fine. Possible clues: - 3.7.1: works fine - warm boot in 3.8.0: transfer stalls and scp looks hanged, speed drops to zero, but no error message - cold boot in 3.8.0: transfer stops with Packet corrupt error or sometimes stalls.. I have found these: http://blog.gmane.org/gmane.linux.drivers.ath5k.devel https://bugzilla.kernel.org/show_bug.cgi?id=55211 Any plans to include fix in 3.8.4 ? -- J.A. Magallon \ Winter is coming... -- 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 0/3] cleanup some arm/ep93xx drivers
Fix a couple section mismatch warnings and convert two of the ep93xx drivers to use module_platform_driver. H Hartley Sweeten (3): backlight: ep93xx_bl: fix section mismatch video: ep93xx-fb.c: fix section mismatch and use module_platform_driver misc: ep93xx_pwm.c: fix section mismatch and use module_platform_driver drivers/misc/ep93xx_pwm.c | 21 + drivers/video/backlight/ep93xx_bl.c | 3 +-- drivers/video/ep93xx-fb.c | 18 +++--- 3 files changed, 9 insertions(+), 33 deletions(-) -- 1.8.1.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/3] misc: ep93xx_pwm.c: fix section mismatch and use module_platform_driver
Remove the __init tags from the ep93xx_pwm_probe() and
ep93xx_pwm_remove() functions to fix the section mismatch
warnings.
Use module_platform_driver() to remove the init/exit boilerplate.
Signed-off-by: H Hartley Sweeten
Cc: Ryan Mallon
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
---
drivers/misc/ep93xx_pwm.c | 21 +
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/misc/ep93xx_pwm.c b/drivers/misc/ep93xx_pwm.c
index 16d7179..4a674f6 100644
--- a/drivers/misc/ep93xx_pwm.c
+++ b/drivers/misc/ep93xx_pwm.c
@@ -269,7 +269,7 @@ static const struct attribute_group ep93xx_pwm_sysfs_files
= {
.attrs = ep93xx_pwm_attrs,
};
-static int __init ep93xx_pwm_probe(struct platform_device *pdev)
+static int ep93xx_pwm_probe(struct platform_device *pdev)
{
struct ep93xx_pwm *pwm;
struct resource *res;
@@ -339,7 +339,7 @@ fail_no_mem:
return err;
}
-static int __exit ep93xx_pwm_remove(struct platform_device *pdev)
+static int ep93xx_pwm_remove(struct platform_device *pdev)
{
struct ep93xx_pwm *pwm = platform_get_drvdata(pdev);
struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -362,21 +362,10 @@ static struct platform_driver ep93xx_pwm_driver = {
.name = "ep93xx-pwm",
.owner = THIS_MODULE,
},
- .remove = __exit_p(ep93xx_pwm_remove),
+ .probe = ep93xx_pwm_probe,
+ .remove = ep93xx_pwm_remove,
};
-
-static int __init ep93xx_pwm_init(void)
-{
- return platform_driver_probe(_pwm_driver, ep93xx_pwm_probe);
-}
-
-static void __exit ep93xx_pwm_exit(void)
-{
- platform_driver_unregister(_pwm_driver);
-}
-
-module_init(ep93xx_pwm_init);
-module_exit(ep93xx_pwm_exit);
+module_platform_driver(ep93xx_pwm_driver);
MODULE_AUTHOR("Matthieu Crapet , "
"H Hartley Sweeten ");
--
1.8.1.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 1/3] backlight: ep93xx_bl: fix section mismatch
Remove the __init tag from ep93xxbl_probe() to fix the section
mismatch warning.
Signed-off-by: H Hartley Sweeten
Cc: Ryan Mallon
Cc: Richard Purdie
Cc: Florian Tobias Schandinat
---
drivers/video/backlight/ep93xx_bl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/backlight/ep93xx_bl.c
b/drivers/video/backlight/ep93xx_bl.c
index ef3e21e..17b8abb 100644
--- a/drivers/video/backlight/ep93xx_bl.c
+++ b/drivers/video/backlight/ep93xx_bl.c
@@ -60,7 +60,7 @@ static const struct backlight_ops ep93xxbl_ops = {
.get_brightness = ep93xxbl_get_brightness,
};
-static int __init ep93xxbl_probe(struct platform_device *dev)
+static int ep93xxbl_probe(struct platform_device *dev)
{
struct ep93xxbl *ep93xxbl;
struct backlight_device *bl;
@@ -145,7 +145,6 @@ static struct platform_driver ep93xxbl_driver = {
.suspend= ep93xxbl_suspend,
.resume = ep93xxbl_resume,
};
-
module_platform_driver(ep93xxbl_driver);
MODULE_DESCRIPTION("EP93xx Backlight Driver");
--
1.8.1.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.0] perf,x86: fix kernel crash with PEBS/BTS after suspend/resume
This patch fixes a kernel crash when using precise sampling (PEBS)
after a suspend/resume. Turns out the CPU notifier code is not invoked
on CPU0 (BP). Therefore, the DS_AREA (used by PEBS) is not restored properly
by the kernel and keeps it power-on/resume value of 0 causing any PEBS
measurement to crash when running on CPU0.
The workaround is to add a hook in the actual resume code to restore
the DS Area MSR value. It is invoked for all CPUS. So for all but CPU0,
the DS_AREA will be restored twice but this is harmless.
Upstream commit id: 1d9d8639c063caf6efc2447f5f26aa637f844ff6
Reported-by: Linus Torvalds
Signed-off-by: Stephane Eranian
Signed-off-by: Linus Torvalds
Signed-off-by: Shuah Khan
CC: sta...@vger.kernel.org 3.0
---
arch/x86/kernel/cpu/perf_event_intel_ds.c |8
arch/x86/power/cpu.c |2 ++
include/linux/perf_event.h|2 ++
3 files changed, 12 insertions(+)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index d812fe2..cf82ee5 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -754,6 +754,14 @@ static void intel_ds_init(void)
}
}
+void perf_restore_debug_store(void)
+{
+ if (!x86_pmu.bts && !x86_pmu.pebs)
+ return;
+
+ init_debug_store_on_cpu(smp_processor_id());
+}
+
#else /* CONFIG_CPU_SUP_INTEL */
static void reserve_ds_buffers(void)
diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
index 87bb35e..0ea8bd2 100644
--- a/arch/x86/power/cpu.c
+++ b/arch/x86/power/cpu.c
@@ -10,6 +10,7 @@
#include
#include
+#include
#include
#include
@@ -224,6 +225,7 @@ static void __restore_processor_state(struct saved_context
*ctxt)
do_fpu_end();
mtrr_bp_restore();
+ perf_restore_debug_store();
}
/* Needed by apm.c */
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index effadd6..038ad4a 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1153,6 +1153,7 @@ extern void perf_swevent_put_recursion_context(int rctx);
extern void perf_event_enable(struct perf_event *event);
extern void perf_event_disable(struct perf_event *event);
extern void perf_event_task_tick(void);
+extern void perf_restore_debug_store(void);
#else
static inline void
perf_event_task_sched_in(struct task_struct *task) { }
@@ -1187,6 +1188,7 @@ static inline void perf_swevent_put_recursion_context(int
rctx) { }
static inline void perf_event_enable(struct perf_event *event) { }
static inline void perf_event_disable(struct perf_event *event)
{ }
static inline void perf_event_task_tick(void) { }
+static inline void perf_restore_debug_store(void) { }
#endif
#define perf_output_put(handle, x) perf_output_copy((handle), &(x), sizeof(x))
--
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] perf,x86: fix kernel crash with PEBS/BTS after suspend/resume
On Fri, Mar 15, 2013 at 2:56 PM, Stephane Eranian wrote: > On Fri, Mar 15, 2013 at 9:53 PM, Shuah Khan wrote: >> On Fri, Mar 15, 2013 at 2:31 PM, Greg KH wrote: >>> On Fri, Mar 15, 2013 at 02:26:07PM +0100, Stephane Eranian wrote: This patch fixes a kernel crash when using precise sampling (PEBS) after a suspend/resume. Turns out the CPU notifier code is not invoked on CPU0 (BP). Therefore, the DS_AREA (used by PEBS) is not restored properly by the kernel and keeps it power-on/resume value of 0 causing any PEBS measurement to crash when running on CPU0. The workaround is to add a hook in the actual resume code to restore the DS Area MSR value. It is invoked for all CPUS. So for all but CPU0, the DS_AREA will be restored twice but this is harmless. Reported-by: Linus Torvalds Signed-off-by: Stephane Eranian --- >>> >>> Is this needed for the 3.8 or older kernels as well? >>> >>> thanks, >>> >>> greg k-h >> >> Just about to ask the same question. Patch applies to 3.8, 3.4, 3.2 >> and 3.5. But needs some massaging for 3.0. I have the kernels built, >> haven't started testing yet. >> > Testing the patch is easy: > > # echo mem >/sys/power/state > Then press the power button again, when you get control again, type: > > $ taskset -c 0 perf record -e cycles:pp my_test_program > > Note that this problem impacts only Intel processors after Core 2 > (PEBS enabled). Thanks. Reproduced the problem on 3.8.3, 3.4.36, and 3.0.69. Tested the patch on 3.4 and 3.8 and the problem is fixed. I had to re-cut the patch for 3.0. Sending it to stable tagged for 3.0 Thanks, -- 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 1/6] serial: 8250_dw: add support for clk api
El 15/03/13 21:29, Russell King - ARM Linux escribió:
> On Fri, Mar 15, 2013 at 09:15:11PM -0300, Emilio López wrote:
>> Hello Russell,
>>
>> El 15/03/13 19:39, Russell King - ARM Linux escribió:
>>> On Fri, Mar 15, 2013 at 09:06:23PM +0100, Maxime Ripard wrote:
+ /* clock got configured through clk api, all done */
+ if (p->uartclk)
>>>
>>> if (IS_ERR(p->uartclk))
>>>
>>
>> Isn't IS_ERR for pointers? p->uartclk is an unsigned int
>
> Right, sorry, ignore that.
>
+ return 0;
+
+ /* try to find out clock frequency from DT as fallback */
if (of_property_read_u32(np, "clock-frequency", )) {
- dev_err(p->dev, "no clock-frequency property set\n");
+ dev_err(p->dev, "clk or clock-frequency not defined\n");
return -EINVAL;
}
p->uartclk = val;
@@ -294,9 +301,21 @@ static int dw8250_probe(struct platform_device *pdev)
if (!uart.port.membase)
return -ENOMEM;
+ data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->clk = devm_clk_get(>dev, NULL);
+ if (IS_ERR(data->clk))
+ data->clk = NULL;
+ else
+ clk_prepare_enable(data->clk);
>>>
>>> if (!IS_ERR(data->clk))
>>> clk_prepare_enable(data->clk);
>>>
>>
>> See below
>>
+
uart.port.iotype = UPIO_MEM;
uart.port.serial_in = dw8250_serial_in;
uart.port.serial_out = dw8250_serial_out;
+ uart.port.private_data = data;
+ uart.port.uartclk = clk_get_rate(data->clk);
>>>
>>> What if data->clk is invalid?
>>>
>>> if (!IS_ERR(data->clk)
>>> uart.port.uartclk = clk_get_rate(data->clk);
>>>
>>
>> I'm not sure if it is coincidental or the way it is supposed to be, but
>> when using the common clock framework, if you pass a NULL to
>> clk_get_rate, the function explicitly checks for it and returns 0. I
>> relied on that behaviour when implementing this; see the if..else block
>> above. Is this not always the case on other clock drivers?
>
> That's something that the common clock framework decided to do. It's
> not a defined part of the API though, so drivers shouldn't rely on
> this behaviour meaning anything special.
Ok then, I'll rework the error checking on the clock calls and get a new
patch sent. Thanks for the clarification.
Emilio
--
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: PATCH 2/2] iio: adc: exynos_adc: Handle timeout and race conditions
On Fri, Mar 15, 2013 at 2:53 PM, Lars-Peter Clausen wrote: > What exactly is the spinlock protecting against here? Concurrent runs of > exynos_adc_isr? This is probably not issue in the first place. > > What you want to protect against is that completion is completed between the > call to INIT_COMPLETION() and the start of a new conversion. So the sections > that need to be under the spinlock are the complete call here and the point > from INIT_COMPLETION until the transfer is started in exynos_read_raw(). Make > sure to use spin_lock_irq there. ...and at that point I _think_ you won't also need the mutex. A reasonable way to test to see if you've got this all correct would be to: * Start two processes that are reading from different ADCs that will report very different values (maybe add a device tree node for adc1 or adc7 and use those since they're not really connected to thermistors?). * Have your two processes read as fast as they can. This could just be "while true; do cat /sys/class/hwmon/hwmon0/device/temp1_input; done" * Decrease your timeout and maybe(?) sprinkle some random udelays in the irq handler so that the timeouts happen sometimes but not others. * Periodically cancel one of the readers with Ctrl-C If all is working well then you should always get back the right value from the right reader (and get no crashes). -Doug -- 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/6] serial: 8250_dw: add support for clk api
On Fri, Mar 15, 2013 at 09:15:11PM -0300, Emilio López wrote:
> Hello Russell,
>
> El 15/03/13 19:39, Russell King - ARM Linux escribió:
> > On Fri, Mar 15, 2013 at 09:06:23PM +0100, Maxime Ripard wrote:
> >> + /* clock got configured through clk api, all done */
> >> + if (p->uartclk)
> >
> > if (IS_ERR(p->uartclk))
> >
>
> Isn't IS_ERR for pointers? p->uartclk is an unsigned int
Right, sorry, ignore that.
> >> + return 0;
> >> +
> >> + /* try to find out clock frequency from DT as fallback */
> >>if (of_property_read_u32(np, "clock-frequency", )) {
> >> - dev_err(p->dev, "no clock-frequency property set\n");
> >> + dev_err(p->dev, "clk or clock-frequency not defined\n");
> >>return -EINVAL;
> >>}
> >>p->uartclk = val;
> >> @@ -294,9 +301,21 @@ static int dw8250_probe(struct platform_device *pdev)
> >>if (!uart.port.membase)
> >>return -ENOMEM;
> >>
> >> + data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
> >> + if (!data)
> >> + return -ENOMEM;
> >> +
> >> + data->clk = devm_clk_get(>dev, NULL);
> >> + if (IS_ERR(data->clk))
> >> + data->clk = NULL;
> >> + else
> >> + clk_prepare_enable(data->clk);
> >
> > if (!IS_ERR(data->clk))
> > clk_prepare_enable(data->clk);
> >
>
> See below
>
> >> +
> >>uart.port.iotype = UPIO_MEM;
> >>uart.port.serial_in = dw8250_serial_in;
> >>uart.port.serial_out = dw8250_serial_out;
> >> + uart.port.private_data = data;
> >> + uart.port.uartclk = clk_get_rate(data->clk);
> >
> > What if data->clk is invalid?
> >
> > if (!IS_ERR(data->clk)
> > uart.port.uartclk = clk_get_rate(data->clk);
> >
>
> I'm not sure if it is coincidental or the way it is supposed to be, but
> when using the common clock framework, if you pass a NULL to
> clk_get_rate, the function explicitly checks for it and returns 0. I
> relied on that behaviour when implementing this; see the if..else block
> above. Is this not always the case on other clock drivers?
That's something that the common clock framework decided to do. It's
not a defined part of the API though, so drivers shouldn't rely on
this behaviour meaning anything special.
--
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/6] serial: 8250_dw: add support for clk api
Hello Russell,
El 15/03/13 19:39, Russell King - ARM Linux escribió:
> On Fri, Mar 15, 2013 at 09:06:23PM +0100, Maxime Ripard wrote:
>> +/* clock got configured through clk api, all done */
>> +if (p->uartclk)
>
> if (IS_ERR(p->uartclk))
>
Isn't IS_ERR for pointers? p->uartclk is an unsigned int
>> +return 0;
>> +
>> +/* try to find out clock frequency from DT as fallback */
>> if (of_property_read_u32(np, "clock-frequency", )) {
>> -dev_err(p->dev, "no clock-frequency property set\n");
>> +dev_err(p->dev, "clk or clock-frequency not defined\n");
>> return -EINVAL;
>> }
>> p->uartclk = val;
>> @@ -294,9 +301,21 @@ static int dw8250_probe(struct platform_device *pdev)
>> if (!uart.port.membase)
>> return -ENOMEM;
>>
>> +data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
>> +if (!data)
>> +return -ENOMEM;
>> +
>> +data->clk = devm_clk_get(>dev, NULL);
>> +if (IS_ERR(data->clk))
>> +data->clk = NULL;
>> +else
>> +clk_prepare_enable(data->clk);
>
> if (!IS_ERR(data->clk))
> clk_prepare_enable(data->clk);
>
See below
>> +
>> uart.port.iotype = UPIO_MEM;
>> uart.port.serial_in = dw8250_serial_in;
>> uart.port.serial_out = dw8250_serial_out;
>> +uart.port.private_data = data;
>> +uart.port.uartclk = clk_get_rate(data->clk);
>
> What if data->clk is invalid?
>
> if (!IS_ERR(data->clk)
> uart.port.uartclk = clk_get_rate(data->clk);
>
I'm not sure if it is coincidental or the way it is supposed to be, but
when using the common clock framework, if you pass a NULL to
clk_get_rate, the function explicitly checks for it and returns 0. I
relied on that behaviour when implementing this; see the if..else block
above. Is this not always the case on other clock drivers?
>>
>> dw8250_setup_port();
>>
>> @@ -312,12 +331,6 @@ static int dw8250_probe(struct platform_device *pdev)
>> return -ENODEV;
>> }
>>
>> -data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
>> -if (!data)
>> -return -ENOMEM;
>> -
>> -uart.port.private_data = data;
>> -
>> data->line = serial8250_register_8250_port();
>> if (data->line < 0)
>> return data->line;
>> @@ -333,6 +346,8 @@ static int dw8250_remove(struct platform_device *pdev)
>>
>> serial8250_unregister_port(data->line);
>>
>
> if (!IS_ERR(data->clk)
>
I just double checked and clk_enable/disable, clk_prepare/unprepare also
ignore NULLs passed to them on the CCF.
>> +clk_disable_unprepare(data->clk);
>> +
>> return 0;
>> }
>>
>> --
>> 1.7.10.4
Thanks for the review,
Emilio
--
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: [Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer
On Fri, Mar 15, 2013 at 10:06:19PM +, Chris Wilson wrote: > On Fri, Mar 15, 2013 at 09:36:07AM -0700, Ben Widawsky wrote: > > On Fri, Mar 15, 2013 at 08:24:03AM +, Chris Wilson wrote: > > > That's what I thought too. Looking at the stack trace, the empirical > > > evidence is that we need the check. > > > -Chris > > > > I think we need to investigate the issue more then, or put a BUG_ON() in > > the drm code and run it through trinity. We have other places where arg > > can't/shouldn't be NULL and we don't check. > > Actually we are both wrong. drm_ioctl() does not validate that the > user struct matches the expected size, just ensures that if that user > cmd specifies that the arg is to be used that it only up to the known > size is copied. > > A hostile userspace can bludgen a NULL pointer through drm_ioctl() into > the driver->ioctl->func(). > > > + if (args == NULL) > > > + return -EINVAL; > > > + I must be failing to see the obvious, but I'm still not getting how args can ever be NULL. kdata which is passed to us as "data" and cast to "args' is either always some stack variable, or some kmalloc'd memory. I see how the arguments themselves can be crap which is really only when user size != drv_size. So tell me, which case can result in a NULL arg? 1. user size == drv_size // better not be this one 2. user size < driver size 3. user size > driver size It seems to me we still must [simply] be missing something in our parameter validation. > > If we used driver->ioctl->cmd instead of the user supplied cmd, we would > have a whole other can of worms to deal with (as we suddenly get a > struct of zeroes). However, those worms should already be treated as > invalid. Choose your poison. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre -- Ben Widawsky, Intel Open Source 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/
[PATCH] mm: Make snapshotting pages for stable writes a per-bio operation
Walking a bio's page mappings has proved problematic, so create a new bio flag
to indicate that a bio's data needs to be snapshotted in order to guarantee
stable pages during writeback. Next, for the one user (ext3/jbd) of
snapshotting, hook all the places where writes can be initiated without
PG_writeback set, and set BIO_SNAP_STABLE there. We must also flag journal
"metadata" bios for stable writeout if data=journal, since file data is written
through the journal. Finally, the MS_SNAP_STABLE mount flag (only used by
ext3) is now superfluous, so get rid of it.
Signed-off-by: Darrick J. Wong
[darrick.w...@oracle.com: Fold in a couple of small cleanups from akpm]
Signed-off-by: Andrew Morton
---
fs/buffer.c |9 -
fs/ext3/super.c |3 ++-
fs/jbd/commit.c | 28 +---
include/linux/blk_types.h |3 ++-
include/linux/buffer_head.h |1 +
include/linux/jbd.h |1 +
include/uapi/linux/fs.h |1 -
mm/bounce.c | 21 +
mm/page-writeback.c |4
9 files changed, 40 insertions(+), 31 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index b4dcb34..71578d6 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -2949,7 +2949,7 @@ static void guard_bh_eod(int rw, struct bio *bio, struct
buffer_head *bh)
}
}
-int submit_bh(int rw, struct buffer_head * bh)
+int _submit_bh(int rw, struct buffer_head *bh, unsigned long bio_flags)
{
struct bio *bio;
int ret = 0;
@@ -2984,6 +2984,7 @@ int submit_bh(int rw, struct buffer_head * bh)
bio->bi_end_io = end_bio_bh_io_sync;
bio->bi_private = bh;
+ bio->bi_flags |= bio_flags;
/* Take care of bh's that straddle the end of the device */
guard_bh_eod(rw, bio, bh);
@@ -2997,6 +2998,12 @@ int submit_bh(int rw, struct buffer_head * bh)
bio_put(bio);
return ret;
}
+EXPORT_SYMBOL_GPL(_submit_bh);
+
+int submit_bh(int rw, struct buffer_head *bh)
+{
+ return _submit_bh(rw, bh, 0);
+}
EXPORT_SYMBOL(submit_bh);
/**
diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index 1d6e2ed..e845b6de 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -2063,11 +2063,12 @@ static int ext3_fill_super (struct super_block *sb,
void *data, int silent)
ext3_mark_recovery_complete(sb, es);
ext3_msg(sb, KERN_INFO, "recovery complete");
}
+ if (test_opt(sb, DATA_FLAGS) == EXT3_MOUNT_JOURNAL_DATA)
+ EXT3_SB(sb)->s_journal->j_flags |= JFS_JOURNALS_DATA;
ext3_msg(sb, KERN_INFO, "mounted filesystem with %s data mode",
test_opt(sb,DATA_FLAGS) == EXT3_MOUNT_JOURNAL_DATA ? "journal":
test_opt(sb,DATA_FLAGS) == EXT3_MOUNT_ORDERED_DATA ? "ordered":
"writeback");
- sb->s_flags |= MS_SNAP_STABLE;
return 0;
diff --git a/fs/jbd/commit.c b/fs/jbd/commit.c
index 86b39b1..37a60dd 100644
--- a/fs/jbd/commit.c
+++ b/fs/jbd/commit.c
@@ -162,8 +162,17 @@ static void journal_do_submit_data(struct buffer_head
**wbuf, int bufs,
for (i = 0; i < bufs; i++) {
wbuf[i]->b_end_io = end_buffer_write_sync;
- /* We use-up our safety reference in submit_bh() */
- submit_bh(write_op, wbuf[i]);
+ /*
+* Here we write back pagecache data that may be mmaped. Since
+* we cannot afford to clean the page and set PageWriteback
+* here due to lock ordering (page lock ranks above transaction
+* start), the data can change while IO is in flight. Tell the
+* block layer it should bounce the bio pages if stable data
+* during write is required.
+*
+* We use up our safety reference in submit_bh().
+*/
+ _submit_bh(write_op, wbuf[i], 1 << BIO_SNAP_STABLE);
}
}
@@ -663,11 +672,24 @@ void journal_commit_transaction(journal_t *journal)
start_journal_io:
for (i = 0; i < bufs; i++) {
struct buffer_head *bh = wbuf[i];
+ unsigned long bio_flags = 0;
lock_buffer(bh);
clear_buffer_dirty(bh);
set_buffer_uptodate(bh);
bh->b_end_io = journal_end_buffer_io_sync;
- submit_bh(write_op, bh);
+ /*
+* In data=journal mode, here we can end up
+* writing pagecache data that might be
+* mmapped. Since we can't afford to clean the
+* page and set PageWriteback (see the comment
+* near the other use of _submit_bh()), the
+
RE: [PATCH net-next] drivers:net: dma_alloc_coherent: use __GFP_ZERO instead of memset(, 0)
-Original Message- From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On Behalf Of Joe Perches Sent: Friday, March 15, 2013 10:24 AM To: net...@vger.kernel.org Cc: linux-kernel@vger.kernel.org; e1000-de...@lists.sourceforge.net; linux-wirel...@vger.kernel.org; b43-...@lists.infradead.org; us...@rt2x00.serialmonkey.com Subject: [PATCH net-next] drivers:net: dma_alloc_coherent: use __GFP_ZERO instead of memset(, 0) Reduce the number of calls required to alloc a zeroed block of memory. Trivially reduces overall object size. Other changes around these removals o Neaten call argument alignment o Remove an unnecessary OOM message after dma_alloc_coherent failure o Remove unnecessary gfp_t stack variable Signed-off-by: Joe Perches --- drivers/net/ethernet/aeroflex/greth.c | 8 ++-- drivers/net/ethernet/broadcom/bcm63xx_enet.c | 8 drivers/net/ethernet/broadcom/bnx2.c | 5 ++--- drivers/net/ethernet/broadcom/bnx2x/bnx2x.h| 9 +++-- drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h| 14 ++--- drivers/net/ethernet/broadcom/tg3.c| 11 +++ drivers/net/ethernet/brocade/bna/bnad.c| 5 ++--- drivers/net/ethernet/emulex/benet/be_main.c| 14 ++--- drivers/net/ethernet/faraday/ftgmac100.c | 5 ++--- drivers/net/ethernet/faraday/ftmac100.c| 8 drivers/net/ethernet/ibm/emac/mal.c| 3 +-- drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 6 ++ drivers/net/ethernet/intel/igbvf/netdev.c | 2 -- snip... diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c index d60cd43..bea46bb 100644 --- a/drivers/net/ethernet/intel/igbvf/netdev.c +++ b/drivers/net/ethernet/intel/igbvf/netdev.c @@ -447,7 +447,6 @@ int igbvf_setup_tx_resources(struct igbvf_adapter *adapter, tx_ring->desc = dma_alloc_coherent(>dev, tx_ring->size, _ring->dma, GFP_KERNEL); - if (!tx_ring->desc) goto err; @@ -488,7 +487,6 @@ int igbvf_setup_rx_resources(struct igbvf_adapter *adapter, rx_ring->desc = dma_alloc_coherent(>dev, rx_ring->size, _ring->dma, GFP_KERNEL); - if (!rx_ring->desc) goto err; Hi Joe, Your changes did not seem to make it to igbvf/netdev.c - I think instead of removing an extra line added for code clarity, you want to add: "tx_ring->desc = dma_alloc_coherent(>dev, tx_ring->size, _ring->dma, GFP_KERNEL| __GFP_ZERO);" Regards, Akeem Abodunrin -- 1.8.1.2.459.gbcd45b4.dirty -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
compat-drivers based on v3.8.3
Greg has blessed Linux v3.8.3 so we get to backport drivers for this
release for usage on older kernels through compat-drivers, you can
either visit the v3.8.3 release page [0] or the temporary release page
[1]. This release has been test compiled against vanilla Linux kernel
releases v2.6.24 - v3.7. Below I provide the ChangeLog for this
release for the changes made to compat and compat-drivers, for the
full ChangeLog that includes Linux kernel changes you can refer to the
upstream full ChangeLog [2].
We have 5 type of releases based on v3.8.3, there is a vanilla release
and then 4 releases which incorporate additional patches from sources
on their way to get upstream to the Linux kernel. The additional
releases are designed to ensure we prioritize Linux upstream
development but at the same time allow OEMs / users / mothers to get
releases with additional patches vendors deem important for
functionality, we simply categorize where those patches are on their
way upstream to the Linux kernel. For more information on this see the
additional-patches documentation on the backports wiki [3].
Thanks to everyone who has contributed to this release!
[0] https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.8.3/
[1] http://drvbp1.linux-foundation.org/~mcgrof/rel-html/compat-drivers/
[2]
https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.8.3/ChangeLog-3.8.3-2
[3]
https://backports.wiki.kernel.org/index.php/Documentation/compat-drivers/additional-patches
ChangeLog for compat-drivers-v3.8.3-2 based on linux-3.8.3
This is the ChangeLog for the Linux kernel project compat-drivers.
It provides a backport of a few Linux kernel subsystems down to
older kernels:
* 802.11
* Bluetooth
* Ethernet
* DRM
For more details refer to the home pages:
https://backports.wiki.kernel.org
The compat-drivers project consists of code from three projects:
* The Linux kernel: linux-stable.git
* Compat-wirelesS: compat-drivers.git
* Compat: compat.git
The compat-drivers stable releases incorporates code from from
each of these git trees for the respective upstream Linux kernel
stable release. A branch called linux-3.x.y exists for each
stable release. Below we provide the ChangeLog of changes from
the previous branched release to the new branched release.
Release: linux-3.8
Updates from the compat.git project:
git shortlog linux-3.7.y..linux-3.8.y
Felix Fietkau (1):
compat: fix compile errors when assembly is built into modules
Hauke Mehrtens (21):
compat: update list of kernel headers
compat: add USB_SUBCLASS_VENDOR_SPEC
compat: make compat load without CONFIG_CPU_FREQ
compat: add eth_zero_addr()
compat: add kref_get_unless_zero()
compat: move config_enabled to compat-3.4.h
compat: fix compiler warning in nla_get_s64()
compat: export platform_device_register_data()
compat: fix warning of missing struct netdev_queue
compat: add missing return value to netif_set_real_num_tx_queues
compat: add simple_write_to_buffer
compat: add ETHTOOL_FWVERS_LEN
compat: fix warning in usb_autopm_get_interface_no_{resume,suspend}
compat: do not access default_ethtool_ops
compat: ckmake: make return code 2 is error
compat: ckmake: remove lots of warning spam for the log
compat: ckmake: do not start all build at the same time
compat: add efi_enabled()
compat: netdev_set_default_ethtool_ops() is not in kernel 3.7.5
compat: check if efi_enabled() was already backported
compat: deactivate netdev_set_default_ethtool_ops() for some 3.7 kernels
Johannes Berg (1):
compat: backport unsigned netlink attribute accessors
Luis R. Rodriguez (42):
compat: fix libc dependency on bin/get-compat-kernels
compat: fix typo in bin/get-compat-kernels
compat: run ckmake with num cpu threads
compat: fix get-compat-kernels for libc issue again
compat: change count to 4 for glibc kernel fix
compat: add gpio header for kernels older than 2.6.24
compat: backport ethtool_rxfh_indir_default()
compat: backport ethtool to mii advertisment conversion helpers
compat: backport BQL helpers
compat: define NETIF_F_RXCSUM
compat: fix addition of NETIF_F_RXCSUM
compat: backport PCI MSI-X entry definitions
compat: backport alloc_etherdev_mqs()
compat: backport definition of PCI_MSIX_ENTRY_CTRL_MASKBIT
compat: backport PTR_RET()
compat: backport netif_set_real_num_tx_queues()
compat: backport netif_set_real_num_rx_queues()
compat: rename MDIO exported symbols
compat: backplane mode negotiation ethtool definitions
compat: backport napi_gro_receive()
compat: generate CONFIG_COMPAT_KERNEL_3_8
compat: backport
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On Tue, Mar 12, 2013 at 4:20 PM, Bjorn Helgaas wrote: > On Sat, Mar 9, 2013 at 2:20 AM, Chris Clayton > wrote: >> On 03/08/13 22:57, Bjorn Helgaas wrote: >>> Thanks. I opened this bug report: >>> https://bugzilla.kernel.org/show_bug.cgi?id=54981 to keep track of >>> your logs. Hi Chris, The current Linux acpiphp driver doesn't do anything unless it finds devices with _EJ0 or _RMV methods, and your DSDT has neither. But I think that implementation is incorrect because I'm not convinced that those methods are required in order to do hotplug via ACPI. For example, your DSDT *does* have an _L01 method that does notifications to the root ports. I suspect that hotplug events on your box generate an SCI that invokes that method. Linux basically ignores the resulting notify events, and I suspect that hotplug works on Windows because it is paying attention to them. Can you build a kernel with CONFIG_ACPI_DEBUG=y, do the following, and attach all the output to the bugzilla? 1) Boot with empty ExpressCard slot (without using "pcie_ports=native") 2) # echo 0x00010004 > /sys/module/acpi/parameters/debug_layer 3) # echo 0x0804 > /sys/module/acpi/parameters/debug_level 4) # lspci -vv 5) # setpci -s 1c.3 0x42.w 6) # setpci -s 1c.3 0x5a.w 7) # setpci -s 1c.3 0xd8.l 8) Insert ExpressCard 9) # setpci -s 1c.3 0x5a.w 10) # dmesg Here's what I think we'll see: - Slot Implemented (bit 8 of XCAP at 0x42) set, indicating a slot is implemented below this root port - Hot Plug SCI Enable (bit 30 of MPC at 0xd8) set, indicating that the root port should generate an SCI whenever a hotplug event is detected - Presence Detect State (bit 6 of SLTSTS at 0x5a) change from 0 with the slot empty to 1 with the slot occupied - pciehp doing nothing (since _OSC didn't grant the OS permission to use PCIe native hotplug) - dmesg indication of the SCI, leading to a Bus Check notification to \_SB.PCI0.RP04, which is the 1c.3 root port leading to the ExpressCard slot A Bus Check notification means we're supposed to re-enumerate starting at that device. If we *did* re-enumerate, we would find the new ExpressCard. Thanks, Bjorn -- 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/6] serial: 8250_dw: add support for clk api
On Fri, Mar 15, 2013 at 09:06:23PM +0100, Maxime Ripard wrote:
> + /* clock got configured through clk api, all done */
> + if (p->uartclk)
if (IS_ERR(p->uartclk))
> + return 0;
> +
> + /* try to find out clock frequency from DT as fallback */
> if (of_property_read_u32(np, "clock-frequency", )) {
> - dev_err(p->dev, "no clock-frequency property set\n");
> + dev_err(p->dev, "clk or clock-frequency not defined\n");
> return -EINVAL;
> }
> p->uartclk = val;
> @@ -294,9 +301,21 @@ static int dw8250_probe(struct platform_device *pdev)
> if (!uart.port.membase)
> return -ENOMEM;
>
> + data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + data->clk = devm_clk_get(>dev, NULL);
> + if (IS_ERR(data->clk))
> + data->clk = NULL;
> + else
> + clk_prepare_enable(data->clk);
if (!IS_ERR(data->clk))
clk_prepare_enable(data->clk);
> +
> uart.port.iotype = UPIO_MEM;
> uart.port.serial_in = dw8250_serial_in;
> uart.port.serial_out = dw8250_serial_out;
> + uart.port.private_data = data;
> + uart.port.uartclk = clk_get_rate(data->clk);
What if data->clk is invalid?
if (!IS_ERR(data->clk)
uart.port.uartclk = clk_get_rate(data->clk);
>
> dw8250_setup_port();
>
> @@ -312,12 +331,6 @@ static int dw8250_probe(struct platform_device *pdev)
> return -ENODEV;
> }
>
> - data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
> - if (!data)
> - return -ENOMEM;
> -
> - uart.port.private_data = data;
> -
> data->line = serial8250_register_8250_port();
> if (data->line < 0)
> return data->line;
> @@ -333,6 +346,8 @@ static int dw8250_remove(struct platform_device *pdev)
>
> serial8250_unregister_port(data->line);
>
if (!IS_ERR(data->clk)
> + clk_disable_unprepare(data->clk);
> +
> return 0;
> }
>
> --
> 1.7.10.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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] Trivial: Fix typo in arch/arm/mach-mvebu/irq-armada-370-xp.c
Signed-off-by: Marek Belisko
---
arch/arm/mach-mvebu/irq-armada-370-xp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/irq-armada-370-xp.c
b/arch/arm/mach-mvebu/irq-armada-370-xp.c
index 274ff58..d8dbcc1 100644
--- a/arch/arm/mach-mvebu/irq-armada-370-xp.c
+++ b/arch/arm/mach-mvebu/irq-armada-370-xp.c
@@ -55,7 +55,7 @@ static struct irq_domain *armada_370_xp_mpic_domain;
/*
* In SMP mode:
* For shared global interrupts, mask/unmask global enable bit
- * For CPU interrtups, mask/unmask the calling CPU's bit
+ * For CPU interrupts, mask/unmask the calling CPU's bit
*/
static void armada_370_xp_irq_mask(struct irq_data *d)
{
--
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/
Re: [PATCH] video: ep93xx_fb: include for devm_ioremap()
On 16/03/13 09:20, H Hartley Sweeten wrote: > commit be867814 "drivers/video/ep93xx-fb.c: use devm_ functions" > > Introduced a build error: > > drivers/video/ep93xx-fb.c: In function 'ep93xxfb_probe': > drivers/video/ep93xx-fb.c:532: error: implicit declaration of function > 'devm_ioremap' > drivers/video/ep93xx-fb.c:533: warning: assignment makes pointer from integer > without a cast > > Include to pickup the declaration of 'devm_ioremap'. > > Signed-off-by: H Hartley Sweeten > Cc: > Cc: Florian Tobias Schandinat > Cc: Ryan Mallon > Cc: Damien Cassou Acked-by: Ryan Mallon > --- > drivers/video/ep93xx-fb.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/video/ep93xx-fb.c b/drivers/video/ep93xx-fb.c > index 3f2519d..e06cd5d 100644 > --- a/drivers/video/ep93xx-fb.c > +++ b/drivers/video/ep93xx-fb.c > @@ -23,6 +23,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/
[PATCH] video: ep93xx_fb: include for devm_ioremap()
commit be867814 "drivers/video/ep93xx-fb.c: use devm_ functions" Introduced a build error: drivers/video/ep93xx-fb.c: In function 'ep93xxfb_probe': drivers/video/ep93xx-fb.c:532: error: implicit declaration of function 'devm_ioremap' drivers/video/ep93xx-fb.c:533: warning: assignment makes pointer from integer without a cast Include to pickup the declaration of 'devm_ioremap'. Signed-off-by: H Hartley Sweeten Cc: Cc: Florian Tobias Schandinat Cc: Ryan Mallon Cc: Damien Cassou --- drivers/video/ep93xx-fb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/ep93xx-fb.c b/drivers/video/ep93xx-fb.c index 3f2519d..e06cd5d 100644 --- a/drivers/video/ep93xx-fb.c +++ b/drivers/video/ep93xx-fb.c @@ -23,6 +23,7 @@ #include #include #include +#include #include -- 1.8.1.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: [GIT PULL] at91: cleanup + soc for 3.10 #1
On Friday 15 March 2013, Nicolas Ferre wrote: > This is a pull-request targeted to do some cleanup in AT91 Kconfig > and board-dt-xxx.c files. It will prepare the coming introduction of > our SAMA5D3 family (Atmel new Cortex-A5) that we will stack on top > of these modifications soon. > Pulled into next/cleanup branch Arnd -- 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] x86: remove the x32 syscall bitmask from syscall_get_nr()
On Fri, Mar 15, 2013 at 2:56 PM, H. Peter Anvin wrote: > On 03/15/2013 02:15 PM, Paul Moore wrote: >> On Tuesday, February 26, 2013 03:58:23 PM Paul Moore wrote: >>> On Friday, February 15, 2013 12:21:43 PM Paul Moore wrote: Commit fca460f95e928bae373daa8295877b6905bc62b8 simplified the x32 implementation by creating a syscall bitmask, equal to 0x4000, that could be applied to x32 syscalls such that the masked syscall number would be the same as a x86_64 syscall. While that patch was a nice way to simplify the code, it went a bit too far by adding the mask to syscall_get_nr(); returning the masked syscall numbers can cause confusion with callers that expect syscall numbers matching the x32 ABI, e.g. unmasked syscall numbers. This patch fixes this by simply removing the mask from syscall_get_nr() while preserving the other changes from the original commit. While there are several syscall_get_nr() callers in the kernel, most simply check that the syscall number is greater than zero, in this case this patch will have no effect. Of those remaining callers, they appear to be few, seccomp and ftrace, and from my testing of seccomp without this patch the original commit definitely breaks things; the seccomp filter does not correctly filter the syscalls due to the difference in syscall numbers in the BPF filter and the value from syscall_get_nr(). Applying this patch restores the seccomp BPF filter functionality on x32. I've tested this patch with the seccomp BPF filters as well as ftrace and everything looks reasonable to me; needless to say general usage seemed fine as well. >>> >>> I just wanted to check and see where things stood with this patch. I'm not >>> overly concerned about how this problem is solved, just that it is solved. >>> If someone else has a better approach that is fine with me; I'll even make >>> the offer to do additional testing if needed. >> >> Anyone? The seccomp filter bits are completely broken on x32 and I'd like to >> get this fixed, if not with this patch then something else - I'm more than >> happy to test/verify/etc whatever solution is deemed best ... >> > > Seems good to me -- H.J., do you seen any problem with this? > It looks OK to me. -- H.J. -- 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: [GIT PULL] at91: framebuffer enhancements for 3.10
On Friday 15 March 2013, Nicolas Ferre wrote: > Arnd, Olof, > > Following our conversation about these framebuffer patches for > Atmel LCD driver, here are the remaining three patches that can be > pushed for 3.10. As suggested by Arnd, I have kept them on top of last > commit concerning this topic that have already been merged in arm-soc 3.9 > fixes branch. > Thanks a lot for taking care of these modifications. I think it's reasonable to take the patches through the arm-soc tree here, because you did not manage to get any feedback on them from Florian and he also didn't pull them into his framebuffer tree. However, if you are bypassing a maintainer, you should not do that silently, and you should note that I don't have any intention of taking all framebuffer patches in the future. I've taken Florian and the linux-fbdev list on Cc. If there are any objections to me taking these through the arm-soc tree, please let us know and we can revert them to find a better way. I have applied them to the next/drivers branch in the arm-soc tree now. Arnd > The following changes since commit 67cf9c0a00bd88443adb7d6c3efa8b18d03f97c5: > > ARM: at91: fix LCD-wiring mode (2013-03-13 11:05:04 +0100) > > are available in the git repository at: > > git://github.com/at91linux/linux-at91.git tags/at91-driversLCD > > for you to fetch changes up to bbd44f6bd9d1aa735b180b29b5719d63a8e87b55: > > ARM: at91/avr32/atmel_lcdfb: add platform device-id table (2013-03-13 > 11:05:12 +0100) > > > Some Atmel framebuffer driver enhancements with modification > of configuration data in ARM/AT91 and AVR32/AP7 trees. > A merge of these modifications seems easier through arm-soc > git tree nowadays. > > > Johan Hovold (3): > ARM: at91/avr32/atmel_lcdfb: add bus-clock entry > atmel_lcdfb: move lcdcon2 register access to compute_hozval > ARM: at91/avr32/atmel_lcdfb: add platform device-id table > > arch/arm/mach-at91/at91sam9261.c | 2 + > arch/arm/mach-at91/at91sam9261_devices.c | 6 +- > arch/arm/mach-at91/at91sam9263.c | 1 + > arch/arm/mach-at91/at91sam9263_devices.c | 2 +- > arch/arm/mach-at91/at91sam9g45.c | 2 + > arch/arm/mach-at91/at91sam9g45_devices.c | 6 +- > arch/arm/mach-at91/at91sam9rl.c | 1 + > arch/arm/mach-at91/at91sam9rl_devices.c | 2 +- > arch/avr32/mach-at32ap/at32ap700x.c | 6 +- > drivers/video/atmel_lcdfb.c | 120 > +++ > include/video/atmel_lcdc.h | 4 +- > 11 files changed, 117 insertions(+), 35 deletions(-) > -- 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] staging: android: lowmemorykiller: well-marked debug print
On Fri, 15 Mar 2013, Greg Kroah-Hartman wrote: > > Add "lmk:" prefix to the debug print so it's easier to analyse LMK's > > debug output: > > dmesg | grep lmk > > Ick, no, please use the proper interface for this (i.e. pr_fmt). > And I'm sure that mysterious new "lmk:" messages appearing in the kernel log will be understood by about 0.1% of people. -- 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: [Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer
On Fri, Mar 15, 2013 at 09:36:07AM -0700, Ben Widawsky wrote: > On Fri, Mar 15, 2013 at 08:24:03AM +, Chris Wilson wrote: > > That's what I thought too. Looking at the stack trace, the empirical > > evidence is that we need the check. > > -Chris > > I think we need to investigate the issue more then, or put a BUG_ON() in > the drm code and run it through trinity. We have other places where arg > can't/shouldn't be NULL and we don't check. Actually we are both wrong. drm_ioctl() does not validate that the user struct matches the expected size, just ensures that if that user cmd specifies that the arg is to be used that it only up to the known size is copied. A hostile userspace can bludgen a NULL pointer through drm_ioctl() into the driver->ioctl->func(). If we used driver->ioctl->cmd instead of the user supplied cmd, we would have a whole other can of worms to deal with (as we suddenly get a struct of zeroes). However, those worms should already be treated as invalid. Choose your poison. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- 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: [GIT PULL] clocksource cleanup for 3.10
On Monday 11 March 2013, Rob Herring wrote: > Please pull. This improves the clocksource init to avoid double matching > to the DT device node. The clocksource init function changes are needed > for any other clocksource conversions to CLKSRC_OF, so we need to make > sure any other conversions use this branch (It happens to silently work > without warnings, but there would be a mismatch in function ptrs). I'm > including the twd_smp timer support for CLKSRC_OF here because of the > dependency on this change. > Pulled into next/cleanup branch, thanks! Arnd -- 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] x86: remove the x32 syscall bitmask from syscall_get_nr()
On 03/15/2013 02:15 PM, Paul Moore wrote:
> On Tuesday, February 26, 2013 03:58:23 PM Paul Moore wrote:
>> On Friday, February 15, 2013 12:21:43 PM Paul Moore wrote:
>>> Commit fca460f95e928bae373daa8295877b6905bc62b8 simplified the x32
>>> implementation by creating a syscall bitmask, equal to 0x4000, that
>>> could be applied to x32 syscalls such that the masked syscall number
>>> would be the same as a x86_64 syscall. While that patch was a nice
>>> way to simplify the code, it went a bit too far by adding the mask to
>>> syscall_get_nr(); returning the masked syscall numbers can cause
>>> confusion with callers that expect syscall numbers matching the x32
>>> ABI, e.g. unmasked syscall numbers.
>>>
>>> This patch fixes this by simply removing the mask from syscall_get_nr()
>>> while preserving the other changes from the original commit. While
>>> there are several syscall_get_nr() callers in the kernel, most simply
>>> check that the syscall number is greater than zero, in this case this
>>> patch will have no effect. Of those remaining callers, they appear
>>> to be few, seccomp and ftrace, and from my testing of seccomp without
>>> this patch the original commit definitely breaks things; the seccomp
>>> filter does not correctly filter the syscalls due to the difference in
>>> syscall numbers in the BPF filter and the value from syscall_get_nr().
>>> Applying this patch restores the seccomp BPF filter functionality on
>>> x32.
>>>
>>> I've tested this patch with the seccomp BPF filters as well as ftrace
>>> and everything looks reasonable to me; needless to say general usage
>>> seemed fine as well.
>>
>> I just wanted to check and see where things stood with this patch. I'm not
>> overly concerned about how this problem is solved, just that it is solved.
>> If someone else has a better approach that is fine with me; I'll even make
>> the offer to do additional testing if needed.
>
> Anyone? The seccomp filter bits are completely broken on x32 and I'd like to
> get this fixed, if not with this patch then something else - I'm more than
> happy to test/verify/etc whatever solution is deemed best ...
>
Seems good to me -- H.J., do you seen any problem with this?
-hpa
>>> Signed-off-by: Paul Moore
>>> Cc: sta...@vger.kernel.org
>>> Cc: Will Drewry
>>> Cc: H. Peter Anvin
>>> ---
>>>
>>> arch/x86/include/asm/syscall.h |4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/x86/include/asm/syscall.h
>>> b/arch/x86/include/asm/syscall.h index 1ace47b..2e188d6 100644
>>> --- a/arch/x86/include/asm/syscall.h
>>> +++ b/arch/x86/include/asm/syscall.h
>>> @@ -29,13 +29,13 @@ extern const unsigned long sys_call_table[];
>>>
>>> */
>>>
>>> static inline int syscall_get_nr(struct task_struct *task, struct pt_regs
>>>
>>> *regs) {
>>> - return regs->orig_ax & __SYSCALL_MASK;
>>> + return regs->orig_ax;
>>>
>>> }
>>>
>>> static inline void syscall_rollback(struct task_struct *task,
>>>
>>> struct pt_regs *regs)
>>>
>>> {
>>>
>>> - regs->ax = regs->orig_ax & __SYSCALL_MASK;
>>> + regs->ax = regs->orig_ax;
>>>
>>> }
>>>
>>> static inline long syscall_get_error(struct task_struct *task,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] leds: move LED trigger drivers into new subdirectory
On Wed, Feb 20, 2013 at 1:29 AM, Kim, Milo wrote: >> For this kind of patches you should really use the "-M" flag of "git >> format-patch" to activate rename detection. The patch becomes much >> more >> readable. For example, the diffstat for this one using -M is: > > Thanks for useful tip! > Instead put -M every time run format-patch, run this command should be helpful: git config --global diff.renames true Thanks Arnd Bergmann and Stephen Warren -Bryan -- 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/
Kernel 3.7.9 rcu_sched detected stalls on CPUs/tasks:
Hi, I'm running a new DELL PER420 with 2x Intel Xeon E5-2440 2,40 Ghz and 16GB of RAM with Kernel 3.7.9 and Linux vserver patch vs2.3.5.6 from http://linux-vserver.org. Uptime was about 14 days, 8 hours. Today evening the system has become not responsive and the netconsole got me the following log entries. I had to hard reset the machine to got it to work again. There was no output on the screen, too. Logs entries I got: 2013-03-15 19:34:01 [1239160.944985] INFO: rcu_sched detected stalls on CPUs/tasks: 2013-03-15 19:34:01 2013-03-15 19:34:01 [1239160.951430] 0: (2 GPs behind) idle=d99/141/0 drain=0 . timer not pending 2013-03-15 19:34:01 [1239160.960413] 2013-03-15 19:34:01 (detected by 6, t=6003 jiffies) 2013-03-15 19:34:01 [1239160.965429] Pid: 0, comm: swapper/6 Not tainted 3.7.9-vs2.3.5.6-rol-em64t-tg3+sdfix #3 2013-03-15 19:34:01 [1239160.974516] Call Trace: 2013-03-15 19:34:01 [1239160.977470] 2013-03-15 19:34:01 [] rcu_pending+0x535/0x550 2013-03-15 19:34:01 [1239160.984439] [] rcu_check_callbacks+0xe2/0x180 2013-03-15 19:34:01 [1239160.991373] [] update_process_times+0x48/0x90 2013-03-15 19:34:01 [1239160.998307] [] tick_sched_timer+0x83/0xd0 2013-03-15 19:34:01 [1239161.004844] [] __run_hrtimer+0x79/0x1d0 2013-03-15 19:34:01 [1239161.011195] [] ? tick_nohz_handler+0xf0/0xf0 2013-03-15 19:34:01 [1239161.019993] [] hrtimer_interrupt+0xf7/0x230 2013-03-15 19:34:01 [1239161.026732] [] smp_apic_timer_interrupt+0x69/0x99 2013-03-15 19:34:01 [1239161.034053] [] apic_timer_interrupt+0x6a/0x70 2013-03-15 19:34:01 [1239161.040985] 2013-03-15 19:34:01 [] ? __hrtimer_start_range_ns+0x1b7/0x400 2013-03-15 19:34:01 [1239161.049435] [] ? intel_idle+0xed/0x150 2013-03-15 19:34:01 [1239161.055687] [] ? intel_idle+0xce/0x150 2013-03-15 19:34:01 [1239161.061940] [] cpuidle_enter+0x19/0x20 2013-03-15 19:34:01 [1239161.068192] [] cpuidle_idle_call+0xa2/0x1b0 2013-03-15 19:34:01 [1239161.074924] [] cpu_idle+0xaf/0x120 2013-03-15 19:34:01 [1239161.080791] [] start_secondary+0x1d4/0x1db 2013-03-15 19:33:58 kernel: [1239160.944985] INFO: rcu_sched detected stalls on CPUs/tasks: 2013-03-15 19:33:58 kernel: [1239160.951430] 0: (2 GPs behind) idle=d99/141/0 drain=0 . timer not pending 2013-03-15 19:33:58 kernel: [1239160.960413] (detected by 6, t=6003 jiffies) 2013-03-15 19:33:58 kernel: [1239160.965429] Pid: 0, comm: swapper/6 Not tainted 3.7.9-vs2.3.5.6-rol-em64t-tg3+sdfix #3 2013-03-15 19:33:58 kernel: [1239160.974516] Call Trace: 2013-03-15 19:33:58 kernel: [1239160.977470] [] rcu_pending+0x535/0x550 2013-03-15 19:33:58 kernel: [1239160.984439] [] rcu_check_callbacks+0xe2/0x180 2013-03-15 19:33:58 kernel: [1239160.991373] [] update_process_times+0x48/0x90 2013-03-15 19:33:58 kernel: [1239160.998307] [] tick_sched_timer+0x83/0xd0 2013-03-15 19:33:58 kernel: [1239161.004844] [] __run_hrtimer+0x79/0x1d0 2013-03-15 19:33:58 kernel: [1239161.011195] [] ? tick_nohz_handler+0xf0/0xf0 2013-03-15 19:33:58 kernel: [1239161.019993] [] hrtimer_interrupt+0xf7/0x230 2013-03-15 19:33:58 kernel: [1239161.026732] [] smp_apic_timer_interrupt+0x69/0x99 2013-03-15 19:33:58 kernel: [1239161.034053] [] apic_timer_interrupt+0x6a/0x70 2013-03-15 19:37:01 [1239340.713569] INFO: rcu_sched detected stalls on CPUs/tasks: 2013-03-15 19:37:01 2013-03-15 19:37:01 [1239340.719931] 0: (2 GPs behind) idle=d99/141/0 drain=0 . timer not pending 2013-03-15 19:37:01 [1239340.728915] 2013-03-15 19:37:01 (detected by 6, t=24008 jiffies) 2013-03-15 19:37:01 [1239340.734016] Pid: 0, comm: swapper/6 Not tainted 3.7.9-vs2.3.5.6-rol-em64t-tg3+sdfix #3 2013-03-15 19:37:01 [1239340.743103] Call Trace: 2013-03-15 19:37:01 [1239340.746057] 2013-03-15 19:37:01 [] rcu_pending+0x535/0x550 2013-03-15 19:37:01 [1239340.753023] [] rcu_check_callbacks+0xe2/0x180 2013-03-15 19:37:01 [1239340.759956] [] update_process_times+0x48/0x90 2013-03-15 19:37:01 [1239340.766888] [] tick_sched_timer+0x83/0xd0 2013-03-15 19:37:01 [1239340.773431] [] __run_hrtimer+0x79/0x1d0 2013-03-15 19:37:01 [1239340.779781] [] ? tick_nohz_handler+0xf0/0xf0 2013-03-15 19:37:01 [1239340.786615] [] hrtimer_interrupt+0xf7/0x230 2013-03-15 19:37:01 [1239340.793353] [] smp_apic_timer_interrupt+0x69/0x99 2013-03-15 19:37:01 [1239340.800673] [] apic_timer_interrupt+0x6a/0x70 2013-03-15 19:37:01 [1239340.807604] 2013-03-15 19:37:01 [] ? __hrtimer_start_range_ns+0x1b7/0x400 2013-03-15 19:37:01 [1239340.816045] [] ? intel_idle+0xed/0x150 2013-03-15 19:37:01 [1239340.822297] [] ? intel_idle+0xce/0x150 2013-03-15 19:37:01 [1239340.828550] [] cpuidle_enter+0x19/0x20 2013-03-15 19:37:01 [1239340.834801] [] cpuidle_idle_call+0xa2/0x1b0 2013-03-15 19:37:01 [1239340.841539] [] cpu_idle+0xaf/0x120 2013-03-15 19:37:01 [1239340.847397] [] start_secondary+0x1d4/0x1db 2013-03-15 19:37:03 [1239342.520795] INFO: task jbd2/sda2-8:416 blocked for more than 120
Re: [RFC: PATCH 2/2] iio: adc: exynos_adc: Handle timeout and race conditions
On 03/15/2013 05:26 PM, Naveen Krishna Chatradhi wrote:
> This patch does the following
> 1. Handle the return values of wait_for_completion_interruptible_timeout
> 2. Add spin locks to avoid race conditions during ISR.
>
> Signed-off-by: Naveen Krishna Chatradhi
> Cc: Doug Anderson
> Cc: Lars-Peter Clausen
> ---
> Discussion thread for this patch can be found at
> http://www.gossamer-threads.com/lists/linux/kernel/1693284?page=last
>
> I've not seen any reference to spin lock usage in IIO.
> Kindly, suggest me if there is a better way to avoid the race.
>
> Thanks,
> Naveen
> drivers/iio/adc/exynos_adc.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
> index ed6fdd7..4de28ae 100644
> --- a/drivers/iio/adc/exynos_adc.c
> +++ b/drivers/iio/adc/exynos_adc.c
> @@ -91,6 +91,7 @@ struct exynos_adc {
>
> struct completion completion;
>
> + spinlock_t reg_lock;
> u32 value;
> unsigned intversion;
> };
> @@ -117,7 +118,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
> long mask)
> {
> struct exynos_adc *info = iio_priv(indio_dev);
> - unsigned long timeout;
> + long timeout;
> u32 con1, con2;
>
> if (mask != IIO_CHAN_INFO_RAW)
> @@ -143,15 +144,19 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
> ADC_V1_CON(info->regs));
> }
>
> + INIT_COMPLETION(info->completion);
> +
This needs to happen before you start the transfer.
> timeout = wait_for_completion_interruptible_timeout
> (>completion, EXYNOS_ADC_TIMEOUT);
> +
> *val = info->value;
>
> mutex_unlock(_dev->mlock);
>
> if (timeout == 0)
> return -ETIMEDOUT;
> -
> + else if (timeout < 0)
> + return timeout;
> return IIO_VAL_INT;
> }
>
> @@ -159,6 +164,8 @@ static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
> {
> struct exynos_adc *info = (struct exynos_adc *)dev_id;
>
> + spin_lock(>reg_lock);
> +
> /* Read value */
> info->value = readl(ADC_V1_DATX(info->regs)) &
> ADC_DATX_MASK;
> @@ -170,6 +177,8 @@ static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
>
> complete(>completion);
>
> + spin_unlock(>reg_lock);
> +
What exactly is the spinlock protecting against here? Concurrent runs of
exynos_adc_isr? This is probably not issue in the first place.
What you want to protect against is that completion is completed between the
call to INIT_COMPLETION() and the start of a new conversion. So the sections
that need to be under the spinlock are the complete call here and the point
from INIT_COMPLETION until the transfer is started in exynos_read_raw(). Make
sure to use spin_lock_irq there.
> return IRQ_HANDLED;
> }
>
> @@ -327,6 +336,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
> else
> indio_dev->num_channels = MAX_ADC_V2_CHANNELS;
>
> + spin_lock_init(>reg_lock);
> ret = iio_device_register(indio_dev);
> if (ret)
> goto err_irq;
--
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/
Fwd: [PATCH] cifs: Rename cERROR and cFYI to cifs_dbg
On Fri, Mar 15, 2013 at 2:01 PM, Jeff Layton wrote: > > On Thu, 14 Mar 2013 12:24:37 -0700 > Joe Perches wrote: > > > It's not obvious from reading the macro names that these macros > > are for debugging. Convert the names to a single more typical > > kernel style cifs_dbg macro. > > > > cERROR(1, ...) -> cifs_dbg(VFS, ...) > > cFYI(1, ...) -> cifs_dbg(FYI, ...) > > cFYI(DBG2, ...) -> cifs_dbg(NOISY, ...) > > > > Move the terminating format newline from the macro to the call site. > > > > Add CONFIG_CIFS_DEBUG function cifs_vfs_err to emit the > > "CIFS VFS: " prefix for VFS messages. > > > > Size is reduced ~ 1% when CONFIG_CIFS_DEBUG is set (default y) > > > > $ size fs/cifs/cifs.ko* > >textdata bss dec hex filename > > 265245 2525 132 267902 4167e fs/cifs/cifs.ko.new > > 2683592525 132 271016 422a8 fs/cifs/cifs.ko.old > > > > (my apologies -- my MUA has a mind of its own sometimes) > > This all looks like good stuff. I am a bit concerned about mashing all > of these cleanups into the same patch though. > > > Other miscellaneous changes around these conversions: > > > > o Miscellaneous typo fixes > > o Add terminating \n's to almost all formats and remove them > > from the macros to be more kernel style like. A few formats > > previously had defective \n's > > o Remove unnecessary OOM messages as kmalloc() calls dump_stack > > o Coalesce formats to make grep easier, > > added missing spaces when coalescing formats > > o Use %s, __func__ instead of embedded function name > > o Removed unnecessary "cifs: " prefixes > > > o Convert kzalloc with multiply to kcalloc > ^^^ > Things like this really ought to be a separate patch, even though it is > a trivial change. That's a minor nit though... > > > o Remove unused cifswarn macro > > > > I think we ought to go ahead and take this for 3.10. I do have some > minor concern about having to deal with backports of later patches to > kernels that don't have these changes, but hey, that's the price of > dealing with old kernels. > > The sooner Steve merges this into his for-next tree, the better. This > bound to give us all sorts of merge conflicts for the 3.10 window, so > we want to make sure that people know what to base their work on. I would like to merge the three we have (one still has to be put in for-next - the one from Jeff) for for-next in the next three or fouir days - but I can create another temporary branch for the ones for 3.10 - but ... I would like to simplify things by merging the other cleanup patches we already have first. I agree that we are going to have to let people know to rebase everything for cifs for 3.10 on this big cleanup patch. -- Thanks, Steve -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] RFC: mmc: dw_mmc: Don't clear errors we aren't handling
Although there are no known cases of this being a problem (and it may
be technically impossible for the hardware to report more errors once
already in the error state), it seems unwise for us to be clearing
error interrupts that we didn't actually read.
Signed-off-by: Doug Anderson
---
drivers/mmc/host/dw_mmc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 9834221..84ae704 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1583,7 +1583,8 @@ static irqreturn_t dw_mci_interrupt(int irq, void *dev_id)
break;
if (pending & DW_MCI_CMD_ERROR_FLAGS) {
- mci_writel(host, RINTSTS, DW_MCI_CMD_ERROR_FLAGS);
+ mci_writel(host, RINTSTS,
+ pending & DW_MCI_CMD_ERROR_FLAGS);
host->cmd_status = pending;
smp_wmb();
set_bit(EVENT_CMD_COMPLETE, >pending_events);
@@ -1591,7 +1592,8 @@ static irqreturn_t dw_mci_interrupt(int irq, void *dev_id)
if (pending & DW_MCI_DATA_ERROR_FLAGS) {
/* if there is an error report DATA_ERROR */
- mci_writel(host, RINTSTS, DW_MCI_DATA_ERROR_FLAGS);
+ mci_writel(host, RINTSTS,
+ pending & DW_MCI_DATA_ERROR_FLAGS);
host->data_status = pending;
smp_wmb();
set_bit(EVENT_DATA_ERROR, >pending_events);
--
1.8.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: cdc-acm: fix error handling in acm_probe()
acm_probe() ignores errors in tty_port_register_device()
and leaves intfdata pointing to freed memory on alloc_fail7
error path. The patch fixes the both issues.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/usb/class/cdc-acm.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 8ac25ad..c125b61 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -977,6 +977,8 @@ static int acm_probe(struct usb_interface *intf,
int num_rx_buf;
int i;
int combined_interfaces = 0;
+ struct device *tty_dev;
+ int rv = -ENOMEM;
/* normal quirks */
quirks = (unsigned long)id->driver_info;
@@ -1339,11 +1341,24 @@ skip_countries:
usb_set_intfdata(data_interface, acm);
usb_get_intf(control_interface);
- tty_port_register_device(>port, acm_tty_driver, minor,
+ tty_dev = tty_port_register_device(>port, acm_tty_driver, minor,
_interface->dev);
+ if (IS_ERR(tty_dev)) {
+ rv = PTR_ERR(tty_dev);
+ goto alloc_fail8;
+ }
return 0;
+alloc_fail8:
+ if (acm->country_codes) {
+ device_remove_file(>control->dev,
+ _attr_wCountryCodes);
+ device_remove_file(>control->dev,
+ _attr_iCountryCodeRelDate);
+ }
+ device_remove_file(>control->dev, _attr_bmCapabilities);
alloc_fail7:
+ usb_set_intfdata(intf, NULL);
for (i = 0; i < ACM_NW; i++)
usb_free_urb(acm->wb[i].urb);
alloc_fail6:
@@ -1359,7 +1374,7 @@ alloc_fail2:
acm_release_minor(acm);
kfree(acm);
alloc_fail:
- return -ENOMEM;
+ return rv;
}
static void stop_data_traffic(struct acm *acm)
--
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/
[PATCH] RFC: mmc: dw_mmc: Always go to STATE_DATA_BUSY from STATE_DATA_ERROR
On a flaky piece of hardware that seems good at generating CRC errors, we have found that often times the CRC errors don't get reported properly when using CONFIG_MMC_DW_IDMAC (they get reported OK when using pio). The flow that happens is: 1. dw_mci_interrupt() fires and status=80b8, pending=8088 so that we hit (pending & DW_MCI_DATA_ERROR_FLAGS). We store 8088 in data_status and set EVENT_DATA_ERROR in host->pending_events 2. We schedule the tasklet and it runs. 3. We're in STATE_SENDING_DATA in the tasklet and see EVENT_DATA_ERROR so we dw_mci_stop_dma(). 4. dw_mci_stop_dma() calls dw_mci_idmac_stop_dma() and dw_mci_dma_cleanup(). These stop dma but _don't_ set EVENT_XFER_COMPLETE (since we're host->using_dma). 5. data->stop is NULL so we don't send a stop command. 6. We move onto STATE_DATA_ERROR and loop again in the tasklet. 7. We hit STATE_DATA_ERROR but the transfer isn't done, so the tasklet stops. We never seem to get any additional DMA interrupts that cause EVENT_XFER_COMPLETE and restart the tasklet so we just hang. That doesn't seem surprising given that we've stopped DMA. We did put a print at the end of dw_mci_interrupt() to show the result of the "mci_readl(host, IDSTS)" and saw 0xa000 in the case of the above CRC error. A proposed fix for this is to ignore (but still clear) the EVENT_XFER_COMPLETE in STATE_DATA_ERROR in the tasklet. Reported-by: Bing Zhao Signed-off-by: Doug Anderson --- drivers/mmc/host/dw_mmc.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index 9834221..696b3bb 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -1137,10 +1137,7 @@ static void dw_mci_tasklet_func(unsigned long priv) goto unlock; case STATE_DATA_ERROR: - if (!test_and_clear_bit(EVENT_XFER_COMPLETE, - >pending_events)) - break; - + clear_bit(EVENT_XFER_COMPLETE, >pending_events); state = STATE_DATA_BUSY; break; } -- 1.8.1.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] tty/serial: Fix uninitialized variable warning
On Fri, Mar 15, 2013 at 8:30 PM, Greg Kroah-Hartman wrote: > On Mon, Mar 04, 2013 at 09:35:07AM +0800, Grant Likely wrote: >> drivers/tty/serial/8250/8250.c: In function 'serial_unlink_irq_chain': >> drivers/tty/serial/8250/8250.c:1676:19: warning: 'i' may be used >> uninitialized in this function >> >> There isn't an actual bug here since the function tests the condition >> that would cause i to be uninitialized before dereferencing i. However, >> at least some versions of GCC complain as shown above. (in my case, >> powerpc gcc 2.5.2). Initializing i to NULL makes it clear to GCC and the >> casual code reviewer that i will not be dereferenced to a random >> address. >> >> Signed-off-by: Grant Likely >> Cc: Greg Kroah-Hartman >> --- >> Greg, some may argue that this is a tool problem, not a kernel problem, >> but it is useful to me. If anyone objects I'm not going to spend any >> time championing for this patch. > > Upgrade your tools to ones that work properly :) FWIW, it's still a toolchain that a lot of people use for embedded powerpc development. g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/50] staging: omap-thermal: make a omap_bandgap_power with only one exit point
On Fri, Mar 15, 2013 at 08:59:57AM -0400, Eduardo Valentin wrote: > Change the way the omap_bandgap_power is written so that it has only > one exit entry (Documentation/CodingStyle). > It's only if there is an unlock or something that you should do this. Otherwise the pointless bunny hop is misleading and annoying. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regmap: Remove __attribute__ ((packed))
On Fri, Mar 15, 2013 at 04:53:51PM +, Mark Brown wrote: > On Fri, Mar 15, 2013 at 11:16:02AM +, Dimitris Papastamos wrote: > > > On my system there was no benefit of using it, it just happens > > that the struct is aligned properly and needs no padding. > > OK, so which system was that and is it not possible that other systems > will get something useful from this? Well I guess it has to do with the gcc cross compiler version that I've got and the actual data layout of the linking rbtree node. The data seems to be aligned on a 4-byte boundary anyhow and that should be ok for many systems. Thanks, Dimitris -- 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 -next] char/tpm/tpm_i2c_stm_st33: remove duplicated include from tpm_i2c_stm_st33.c
On Mon, Mar 11, 2013 at 9:20 AM, Wei Yongjun wrote: > From: Wei Yongjun > > Remove duplicated include. HI Wei, thanks for the patch. I've already staged the same patch for inclusion in the next pull request for TPM drivers here: https://github.com/shpedoikal/linux/commit/6c09a9f5fcb3955afbae2e5a279c5d23481aab77 Thanks, Kent > Signed-off-by: Wei Yongjun > --- > drivers/char/tpm/tpm_i2c_stm_st33.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/char/tpm/tpm_i2c_stm_st33.c > b/drivers/char/tpm/tpm_i2c_stm_st33.c > index 1f5f71e..4e42c62 100644 > --- a/drivers/char/tpm/tpm_i2c_stm_st33.c > +++ b/drivers/char/tpm/tpm_i2c_stm_st33.c > @@ -36,7 +36,6 @@ > #include > #include > #include > -#include > #include > #include > #include > @@ -50,7 +49,6 @@ > #include > #include > #include > -#include > > #include "tpm.h" > #include "tpm_i2c_stm_st33.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/ -- 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: ipc/testmsg GPF.
On Tue, Mar 12, 2013 at 03:02:36PM -0700, Andrew Morton wrote:
> On Mon, 11 Mar 2013 15:03:22 -0400 Peter Hurley
> wrote:
>
> > On Mon, 2013-03-11 at 14:26 -0400, Dave Jones wrote:
> > > > > {
> > >
> > > I just hit this again on rc2 which looks like it has the fixes that
> > > Peter mentions above. This time rdi was 6b6b6b6b6b6b6b7b
> > >
> > > Dave
> >
> > Sorry, Dave. The fix must be in the other 8 patches that Andrew didn't
> > want to apply. I run trinity 10 or more times a day and can't get this
> > to trigger with the whole series.
>
> Are you able to reproduce the bug with current mainline?
So with Peters 40-odd patches, I've not been able to reproduce this
after beating on it for a few days. So the fix is in there somewhere.
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/
RE: [PATCH v11 1/3] tracing: Add DEFINE_EVENT_FN() macro
> You still need to add: > > From: Steven Rostedt > > Otherwise you get the authorship of this patch. My apologies. I resend my patch 1/3 by adding it shortly. Seiji > -Original Message- > From: Steven Rostedt [mailto:rost...@goodmis.org] > Sent: Friday, March 15, 2013 5:10 PM > To: Seiji Aguchi > Cc: H. Peter Anvin (h...@zytor.com); x...@kernel.org; > linux-kernel@vger.kernel.org; Thomas Gleixner (t...@linutronix.de); > 'mi...@elte.hu' (mi...@elte.hu); Borislav Petkov (b...@alien8.de); Satoru > Moriya (smor...@redhat.com); dle- > deve...@lists.sourceforge.net; linux-e...@vger.kernel.org; Luck, Tony > (tony.l...@intel.com); Paul E. McKenney > (paul...@us.ibm.com) > Subject: Re: [PATCH v11 1/3] tracing: Add DEFINE_EVENT_FN() macro > > You still need to add: > > From: Steven Rostedt > > Otherwise you get the authorship of this patch. > > -- Steve > > > On Fri, 2013-03-15 at 20:35 +, Seiji Aguchi wrote: > > Each TRACE_EVENT() adds several helper functions. If two or more trace > > events share the same structure and print format, they can also share > > most of these helper functions and save a lot of space from duplicate > > code. This is why the > > DECLARE_EVENT_CLASS() and DEFINE_EVENT() were created. > > > > Some events require a trigger to be called at registering and > > unregistering of the event and to do so they use TRACE_EVENT_FN(). > > > > If multiple events require a trigger, they currently have no choice > > but to use > > TRACE_EVENT_FN() as there's no DEFINE_EVENT_FN() available. This > > unfortunately causes a lot of wasted duplicate code created. > > > > By adding a DEFINE_EVENT_FN(), these events can still use a > > DECLARE_EVENT_CLASS() and then define their own triggers. > > > > Signed-off-by: Steven Rostedt > > Signed-off-by: Seiji Aguchi > > --- > > include/linux/tracepoint.h |2 ++ > > include/trace/define_trace.h |5 + > > include/trace/ftrace.h |4 > > 3 files changed, 11 insertions(+), 0 deletions(-) > > > > diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h > > index 2f322c3..9bf59e5 100644 > > --- a/include/linux/tracepoint.h > > +++ b/include/linux/tracepoint.h > > @@ -378,6 +378,8 @@ static inline void > > tracepoint_synchronize_unregister(void) > > #define DECLARE_EVENT_CLASS(name, proto, args, tstruct, assign, print) > > #define DEFINE_EVENT(template, name, proto, args) \ > > DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) > > +#define DEFINE_EVENT_FN(template, name, proto, args, reg, unreg)\ > > + DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) > > #define DEFINE_EVENT_PRINT(template, name, proto, args, print) \ > > DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) > > #define DEFINE_EVENT_CONDITION(template, name, proto, \ > > diff --git a/include/trace/define_trace.h > > b/include/trace/define_trace.h index 1905ca8..02e1003 100644 > > --- a/include/trace/define_trace.h > > +++ b/include/trace/define_trace.h > > @@ -44,6 +44,10 @@ > > #define DEFINE_EVENT(template, name, proto, args) \ > > DEFINE_TRACE(name) > > > > +#undef DEFINE_EVENT_FN > > +#define DEFINE_EVENT_FN(template, name, proto, args, reg, unreg) \ > > + DEFINE_TRACE_FN(name, reg, unreg) > > + > > #undef DEFINE_EVENT_PRINT > > #define DEFINE_EVENT_PRINT(template, name, proto, args, print) \ > > DEFINE_TRACE(name) > > @@ -91,6 +95,7 @@ > > #undef TRACE_EVENT_CONDITION > > #undef DECLARE_EVENT_CLASS > > #undef DEFINE_EVENT > > +#undef DEFINE_EVENT_FN > > #undef DEFINE_EVENT_PRINT > > #undef DEFINE_EVENT_CONDITION > > #undef TRACE_HEADER_MULTI_READ > > diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h index > > 40dc5e8..7bab676 100644 > > --- a/include/trace/ftrace.h > > +++ b/include/trace/ftrace.h > > @@ -71,6 +71,10 @@ > > static struct ftrace_event_call __used \ > > __attribute__((__aligned__(4))) event_##name > > > > +#undef DEFINE_EVENT_FN > > +#define DEFINE_EVENT_FN(template, name, proto, args, reg, unreg) \ > > + DEFINE_EVENT(template, name, PARAMS(proto), PARAMS(args)) > > + > > #undef DEFINE_EVENT_PRINT > > #define DEFINE_EVENT_PRINT(template, name, proto, args, print) \ > > DEFINE_EVENT(template, name, PARAMS(proto), PARAMS(args)) > > -- 1.7.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/
[Resend][PATCH v11 1/3] tracing: Add DEFINE_EVENT_FN() macro
From: Steven Rostedt Each TRACE_EVENT() adds several helper functions. If two or more trace events share the same structure and print format, they can also share most of these helper functions and save a lot of space from duplicate code. This is why the DECLARE_EVENT_CLASS() and DEFINE_EVENT() were created. Some events require a trigger to be called at registering and unregistering of the event and to do so they use TRACE_EVENT_FN(). If multiple events require a trigger, they currently have no choice but to use TRACE_EVENT_FN() as there's no DEFINE_EVENT_FN() available. This unfortunately causes a lot of wasted duplicate code created. By adding a DEFINE_EVENT_FN(), these events can still use a DECLARE_EVENT_CLASS() and then define their own triggers. Signed-off-by: Steven Rostedt Signed-off-by: Seiji Aguchi --- include/linux/tracepoint.h |2 ++ include/trace/define_trace.h |5 + include/trace/ftrace.h |4 3 files changed, 11 insertions(+), 0 deletions(-) diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h index 2f322c3..9bf59e5 100644 --- a/include/linux/tracepoint.h +++ b/include/linux/tracepoint.h @@ -378,6 +378,8 @@ static inline void tracepoint_synchronize_unregister(void) #define DECLARE_EVENT_CLASS(name, proto, args, tstruct, assign, print) #define DEFINE_EVENT(template, name, proto, args) \ DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) +#define DEFINE_EVENT_FN(template, name, proto, args, reg, unreg)\ + DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) #define DEFINE_EVENT_PRINT(template, name, proto, args, print) \ DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) #define DEFINE_EVENT_CONDITION(template, name, proto, \ diff --git a/include/trace/define_trace.h b/include/trace/define_trace.h index 1905ca8..02e1003 100644 --- a/include/trace/define_trace.h +++ b/include/trace/define_trace.h @@ -44,6 +44,10 @@ #define DEFINE_EVENT(template, name, proto, args) \ DEFINE_TRACE(name) +#undef DEFINE_EVENT_FN +#define DEFINE_EVENT_FN(template, name, proto, args, reg, unreg) \ + DEFINE_TRACE_FN(name, reg, unreg) + #undef DEFINE_EVENT_PRINT #define DEFINE_EVENT_PRINT(template, name, proto, args, print) \ DEFINE_TRACE(name) @@ -91,6 +95,7 @@ #undef TRACE_EVENT_CONDITION #undef DECLARE_EVENT_CLASS #undef DEFINE_EVENT +#undef DEFINE_EVENT_FN #undef DEFINE_EVENT_PRINT #undef DEFINE_EVENT_CONDITION #undef TRACE_HEADER_MULTI_READ diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h index 40dc5e8..7bab676 100644 --- a/include/trace/ftrace.h +++ b/include/trace/ftrace.h @@ -71,6 +71,10 @@ static struct ftrace_event_call __used \ __attribute__((__aligned__(4))) event_##name +#undef DEFINE_EVENT_FN +#define DEFINE_EVENT_FN(template, name, proto, args, reg, unreg) \ + DEFINE_EVENT(template, name, PARAMS(proto), PARAMS(args)) + #undef DEFINE_EVENT_PRINT #define DEFINE_EVENT_PRINT(template, name, proto, args, print) \ DEFINE_EVENT(template, name, PARAMS(proto), PARAMS(args)) -- 1.7.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] acpi: remove length check for large registers
On Fri, Mar 15, 2013 at 08:50:45PM +, Moore, Robert wrote: > Can you explain in a bit more detail what brings this up? > > I'm aware of the limitation of the generic address structure, but we are > forced by the (current) ACPI specification to use it if it is present for a > given register. A system with a GPE block bit_width of 256 triggers it. In this case, the length check can never succeed. Thanks, Linn -- 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] x86: remove the x32 syscall bitmask from syscall_get_nr()
On Tuesday, February 26, 2013 03:58:23 PM Paul Moore wrote:
> On Friday, February 15, 2013 12:21:43 PM Paul Moore wrote:
> > Commit fca460f95e928bae373daa8295877b6905bc62b8 simplified the x32
> > implementation by creating a syscall bitmask, equal to 0x4000, that
> > could be applied to x32 syscalls such that the masked syscall number
> > would be the same as a x86_64 syscall. While that patch was a nice
> > way to simplify the code, it went a bit too far by adding the mask to
> > syscall_get_nr(); returning the masked syscall numbers can cause
> > confusion with callers that expect syscall numbers matching the x32
> > ABI, e.g. unmasked syscall numbers.
> >
> > This patch fixes this by simply removing the mask from syscall_get_nr()
> > while preserving the other changes from the original commit. While
> > there are several syscall_get_nr() callers in the kernel, most simply
> > check that the syscall number is greater than zero, in this case this
> > patch will have no effect. Of those remaining callers, they appear
> > to be few, seccomp and ftrace, and from my testing of seccomp without
> > this patch the original commit definitely breaks things; the seccomp
> > filter does not correctly filter the syscalls due to the difference in
> > syscall numbers in the BPF filter and the value from syscall_get_nr().
> > Applying this patch restores the seccomp BPF filter functionality on
> > x32.
> >
> > I've tested this patch with the seccomp BPF filters as well as ftrace
> > and everything looks reasonable to me; needless to say general usage
> > seemed fine as well.
>
> I just wanted to check and see where things stood with this patch. I'm not
> overly concerned about how this problem is solved, just that it is solved.
> If someone else has a better approach that is fine with me; I'll even make
> the offer to do additional testing if needed.
Anyone? The seccomp filter bits are completely broken on x32 and I'd like to
get this fixed, if not with this patch then something else - I'm more than
happy to test/verify/etc whatever solution is deemed best ...
> > Signed-off-by: Paul Moore
> > Cc: sta...@vger.kernel.org
> > Cc: Will Drewry
> > Cc: H. Peter Anvin
> > ---
> >
> > arch/x86/include/asm/syscall.h |4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/syscall.h
> > b/arch/x86/include/asm/syscall.h index 1ace47b..2e188d6 100644
> > --- a/arch/x86/include/asm/syscall.h
> > +++ b/arch/x86/include/asm/syscall.h
> > @@ -29,13 +29,13 @@ extern const unsigned long sys_call_table[];
> >
> > */
> >
> > static inline int syscall_get_nr(struct task_struct *task, struct pt_regs
> >
> > *regs) {
> > - return regs->orig_ax & __SYSCALL_MASK;
> > + return regs->orig_ax;
> >
> > }
> >
> > static inline void syscall_rollback(struct task_struct *task,
> >
> > struct pt_regs *regs)
> >
> > {
> >
> > - regs->ax = regs->orig_ax & __SYSCALL_MASK;
> > + regs->ax = regs->orig_ax;
> >
> > }
> >
> > static inline long syscall_get_error(struct task_struct *task,
--
paul moore
security and virtualization @ redhat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] capability: Create a new capability CAP_SIGNED
On 3/15/2013 1:35 PM, Vivek Goyal wrote:
> Create a new capability CAP_SIGNED which can be given to signed executables.
This would drive anyone who is trying to use
capabilities as the privilege mechanism it is
intended to be absolutely crazy.
Capabilities aren't just random attribute bits. They
indicate that a task has permission to violate a
system policy (e.g. change the mode bits of a file
the user doesn't own). Think about how this will
interact with programs using file based capabilities.
>
> Signed-off-by: Vivek Goyal
> ---
> include/uapi/linux/capability.h | 12 +++-
> kernel/cred.c |7 +++
> security/commoncap.c|2 ++
> 3 files changed, 20 insertions(+), 1 deletions(-)
>
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index ba478fa..1bbe671 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -343,7 +343,17 @@ struct vfs_cap_data {
>
> #define CAP_BLOCK_SUSPEND36
>
> -#define CAP_LAST_CAP CAP_BLOCK_SUSPEND
> +/*
> + * Allow certain kernel services with secureboot enabled. One of such
> + * service is sys_kexec() which can be invoked by process only if it
> + * has CAP_SIGNED capability (with secureboot enabled).
> + *
> + * This capability is given by kernel automatically if executable
> + * file is validly signed.
> + */
> +#define CAP_SIGNED37
> +
> +#define CAP_LAST_CAP CAP_SIGNED
>
> #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>
> diff --git a/kernel/cred.c b/kernel/cred.c
> index e0573a4..f554d1b 100644
> --- a/kernel/cred.c
> +++ b/kernel/cred.c
> @@ -555,6 +555,12 @@ void revert_creds(const struct cred *old)
> }
> EXPORT_SYMBOL(revert_creds);
>
> +static void remove_cap_signed_init_cred(void)
> +{
> + cap_lower((_cred)->cap_bset, CAP_SIGNED);
> + cap_lower((_cred)->cap_permitted, CAP_SIGNED);
> +}
> +
> /*
> * initialise the credentials stuff
> */
> @@ -563,6 +569,7 @@ void __init cred_init(void)
> /* allocate a slab in which we can store credentials */
> cred_jar = kmem_cache_create("cred_jar", sizeof(struct cred),
>0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
> + remove_cap_signed_init_cred();
> }
>
> /**
> diff --git a/security/commoncap.c b/security/commoncap.c
> index c44b6fe..4190eb9 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -272,6 +272,8 @@ int cap_capset(struct cred *new,
> new->cap_effective = *effective;
> new->cap_inheritable = *inheritable;
> new->cap_permitted = *permitted;
> + if (cap_raised(old->cap_effective, CAP_SIGNED))
> + cap_raise(new->cap_effective, CAP_SIGNED);
> return 0;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v11 1/3] tracing: Add DEFINE_EVENT_FN() macro
You still need to add: From: Steven Rostedt Otherwise you get the authorship of this patch. -- Steve On Fri, 2013-03-15 at 20:35 +, Seiji Aguchi wrote: > Each TRACE_EVENT() adds several helper functions. If two or more trace events > share the same structure and print format, they can also share most of these > helper functions and save a lot of space from duplicate code. This is why the > DECLARE_EVENT_CLASS() and DEFINE_EVENT() were created. > > Some events require a trigger to be called at registering and unregistering of > the event and to do so they use TRACE_EVENT_FN(). > > If multiple events require a trigger, they currently have no choice but to use > TRACE_EVENT_FN() as there's no DEFINE_EVENT_FN() available. This unfortunately > causes a lot of wasted duplicate code created. > > By adding a DEFINE_EVENT_FN(), these events can still use a > DECLARE_EVENT_CLASS() and then define their own triggers. > > Signed-off-by: Steven Rostedt > Signed-off-by: Seiji Aguchi > --- > include/linux/tracepoint.h |2 ++ > include/trace/define_trace.h |5 + > include/trace/ftrace.h |4 > 3 files changed, 11 insertions(+), 0 deletions(-) > > diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h > index 2f322c3..9bf59e5 100644 > --- a/include/linux/tracepoint.h > +++ b/include/linux/tracepoint.h > @@ -378,6 +378,8 @@ static inline void tracepoint_synchronize_unregister(void) > #define DECLARE_EVENT_CLASS(name, proto, args, tstruct, assign, print) > #define DEFINE_EVENT(template, name, proto, args)\ > DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) > +#define DEFINE_EVENT_FN(template, name, proto, args, reg, unreg)\ > + DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) > #define DEFINE_EVENT_PRINT(template, name, proto, args, print) \ > DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) > #define DEFINE_EVENT_CONDITION(template, name, proto,\ > diff --git a/include/trace/define_trace.h b/include/trace/define_trace.h > index 1905ca8..02e1003 100644 > --- a/include/trace/define_trace.h > +++ b/include/trace/define_trace.h > @@ -44,6 +44,10 @@ > #define DEFINE_EVENT(template, name, proto, args) \ > DEFINE_TRACE(name) > > +#undef DEFINE_EVENT_FN > +#define DEFINE_EVENT_FN(template, name, proto, args, reg, unreg) \ > + DEFINE_TRACE_FN(name, reg, unreg) > + > #undef DEFINE_EVENT_PRINT > #define DEFINE_EVENT_PRINT(template, name, proto, args, print) \ > DEFINE_TRACE(name) > @@ -91,6 +95,7 @@ > #undef TRACE_EVENT_CONDITION > #undef DECLARE_EVENT_CLASS > #undef DEFINE_EVENT > +#undef DEFINE_EVENT_FN > #undef DEFINE_EVENT_PRINT > #undef DEFINE_EVENT_CONDITION > #undef TRACE_HEADER_MULTI_READ > diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h > index 40dc5e8..7bab676 100644 > --- a/include/trace/ftrace.h > +++ b/include/trace/ftrace.h > @@ -71,6 +71,10 @@ > static struct ftrace_event_call __used \ > __attribute__((__aligned__(4))) event_##name > > +#undef DEFINE_EVENT_FN > +#define DEFINE_EVENT_FN(template, name, proto, args, reg, unreg) \ > + DEFINE_EVENT(template, name, PARAMS(proto), PARAMS(args)) > + > #undef DEFINE_EVENT_PRINT > #define DEFINE_EVENT_PRINT(template, name, proto, args, print) \ > DEFINE_EVENT(template, name, PARAMS(proto), PARAMS(args)) > -- 1.7.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 07/50] staging: omap-thermal: introduce RMW_BITS macro
On Fri, Mar 15, 2013 at 08:59:55AM -0400, Eduardo Valentin wrote:
> This patch introduce a macro to read, update, write bitfields.
> It will be specific to bandgap data structures.
>
> Signed-off-by: Eduardo Valentin
> ---
> drivers/staging/omap-thermal/omap-bandgap.c | 178
> +++
> 1 files changed, 46 insertions(+), 132 deletions(-)
>
> diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
> b/drivers/staging/omap-thermal/omap-bandgap.c
> index 9f2d7cc..1c1b905 100644
> --- a/drivers/staging/omap-thermal/omap-bandgap.c
> +++ b/drivers/staging/omap-thermal/omap-bandgap.c
> @@ -52,25 +52,29 @@ static void omap_bandgap_writel(struct omap_bandgap
> *bg_ptr, u32 val, u32 reg)
> writel(val, bg_ptr->base + reg);
> }
>
> +/* update bits, value will be shifted */
> +#define RMW_BITS(bg_ptr, id, reg, mask, val) \
> +do { \
> + struct temp_sensor_registers *t;\
> + u32 r; \
> + \
> + t = bg_ptr->conf->sensors[(id)].registers; \
> + r = omap_bandgap_readl(bg_ptr, t->reg); \
> + r &= ~t->mask; \
> + r |= (val) << __ffs(t->mask); \
> + omap_bandgap_writel(bg_ptr, r, t->reg); \
> +} while (0)
> +
> static int omap_bandgap_power(struct omap_bandgap *bg_ptr, bool on)
> {
> - struct temp_sensor_registers *tsr;
> int i;
> - u32 ctrl;
>
> if (!OMAP_BANDGAP_HAS(bg_ptr, POWER_SWITCH))
> return 0;
>
> - for (i = 0; i < bg_ptr->conf->sensor_count; i++) {
> - tsr = bg_ptr->conf->sensors[i].registers;
> - ctrl = omap_bandgap_readl(bg_ptr, tsr->temp_sensor_ctrl);
> - ctrl &= ~tsr->bgap_tempsoff_mask;
> + for (i = 0; i < bg_ptr->conf->sensor_count; i++)
> /* active on 0 */
> - ctrl |= !on << __ffs(tsr->bgap_tempsoff_mask);
> -
> - /* write BGAP_TEMPSOFF should be reset to 0 */
> - omap_bandgap_writel(bg_ptr, ctrl, tsr->temp_sensor_ctrl);
> - }
> + RMW_BITS(bg_ptr, i, temp_sensor_ctrl, bgap_tempsoff_mask, !on);
>
> return 0;
> }
> @@ -78,15 +82,13 @@ static int omap_bandgap_power(struct omap_bandgap
> *bg_ptr, bool on)
> static u32 omap_bandgap_read_temp(struct omap_bandgap *bg_ptr, int id)
> {
This patch is fine and it makes it cleaner than before.
But that said, I don't care for the RMW_BITS() very much as a long
term thing. If we just used pointers instead of passing the offset
into the bg_ptr->conf->sensors[] array then everything would be a
lot cleaner.
In other words, instead of this:
static u32 omap_bandgap_read_temp(struct omap_bandgap *bg_ptr, int id)
We would have:
static u32 omap_bandgap_read_temp(struct omap_bandgap *bg_ptr,
struct temp_sensor_registers *tsr)
If you have the pointer then it's easy write RMW_BITS() as a
function.
static void rmw_bits(struct omap_bandgap *bg_ptr, u32 reg, u32 mask, u32 val)
{
u32 r;
r = omap_bandgap_readl(bg_ptr, reg);
r &= ~mask;
r |= val << __ffs(mask);
omap_bandgap_writel(bg_ptr, r, reg);
}
It's called like:
rmw_bits(bg_ptr, tsr->bgap_mask_ctrl, tsr->mask_freeze_mask, 1);
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] leds: leds-pwm: Defer led_pwm_set() if PWM can sleep
On Fri, Mar 15, 2013 at 1:09 PM, Florian Vaussard wrote: > Hi, > > > On 03/15/2013 07:59 PM, Thierry Reding wrote: >>> >>> >>> Hi Florian and Thierry, >>> >>> Sorry, guys. My bad! I'm using GMAIL filtering my emails. This email >>> goes into my arm-linux mail list archive and I totally missed it. >>> >>> I can merge this patch into my for-next branch, but it will be in 3.10 >>> not 3.9-rcX. >>> >>> Or Thierry, can you merge that to 3.9-rcX through your tree with my Ack? >> >> >> I think 3.10 would be fine. We missed the merge window on this one and >> it isn't really a fix so it's a bit late for 3.9 now. >> >> If Florian really absolutely needs this it can probably be done, but if >> he can wait another few weeks it's certainly worth taking it through >> linux-next for a while just to be safe. >> > > I agree, another few weeks is not a problem :) Bryan, I let you merge this, > ok? > Cool, I merged it into my for-next branch and it will be in linux-next soon. Thanks, -Bryan -- 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/5] net: Add davicom wemac ethernet driver found on Allwinner A10 SoC's
Le 15/03/2013 21:50, Maxime Ripard a écrit : > From: Stefan Roese > > The Allwinner A10 has an ethernet controller that is advertised as > coming from Davicom. > > The exact feature set of this controller is unknown, since there is no > public documentation for this IP, and this driver is mostly the one > published by Allwinner that has been heavily cleaned up. > > Signed-off-by: Stefan Roese > Signed-off-by: Maxime Ripard > --- > .../devicetree/bindings/net/davicom-wemac.txt | 20 + > drivers/net/ethernet/Makefile |2 +- > drivers/net/ethernet/davicom/Kconfig | 31 + > drivers/net/ethernet/davicom/Makefile |1 + > drivers/net/ethernet/davicom/wemac.c | 1033 > > drivers/net/ethernet/davicom/wemac.h | 130 +++ > 6 files changed, 1216 insertions(+), 1 deletion(-) > create mode 100644 Documentation/devicetree/bindings/net/davicom-wemac.txt > create mode 100644 drivers/net/ethernet/davicom/wemac.c > create mode 100644 drivers/net/ethernet/davicom/wemac.h > > diff --git a/Documentation/devicetree/bindings/net/davicom-wemac.txt > b/Documentation/devicetree/bindings/net/davicom-wemac.txt > new file mode 100644 > index 000..516cf31 > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/davicom-wemac.txt > @@ -0,0 +1,20 @@ > +* Marvell Armada 370 / Armada XP Ethernet Controller (NETA) > + > +Required properties: > +- compatible: should be "marvell,armada-370-neta". It looks like I've been a bit too quick to send this one... I'll change in v2, obviously. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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 4/6] ARM: sunxi: dt: Add uart3 dt node
Hello.
On 03/15/2013 11:06 PM, Maxime Ripard wrote:
Both A10 and A13 Allwinner SoCs have a Synopsys APB uart3 device
available, so add it to the sunxi.dtsi file
Signed-off-by: Maxime Ripard
Acked-by: Emilio López
---
arch/arm/boot/dts/sunxi.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sunxi.dtsi b/arch/arm/boot/dts/sunxi.dtsi
index 4f78ef7..324da45 100644
--- a/arch/arm/boot/dts/sunxi.dtsi
+++ b/arch/arm/boot/dts/sunxi.dtsi
@@ -68,5 +68,15 @@
clocks = <>;
status = "disabled";
};
+
+ uart3: uart@01c28c00 {
IIRC, historically, the property name should be "serial", not "uart".
WBR, Sergei
--
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] perf,x86: fix kernel crash with PEBS/BTS after suspend/resume
On Fri, Mar 15, 2013 at 09:49:00PM +0100, Stephane Eranian wrote: > On Fri, Mar 15, 2013 at 9:31 PM, Greg KH wrote: > > > > On Fri, Mar 15, 2013 at 02:26:07PM +0100, Stephane Eranian wrote: > > > > > > This patch fixes a kernel crash when using precise sampling (PEBS) > > > after a suspend/resume. Turns out the CPU notifier code is not invoked > > > on CPU0 (BP). Therefore, the DS_AREA (used by PEBS) is not restored > > > properly > > > by the kernel and keeps it power-on/resume value of 0 causing any PEBS > > > measurement to crash when running on CPU0. > > > > > > The workaround is to add a hook in the actual resume code to restore > > > the DS Area MSR value. It is invoked for all CPUS. So for all but CPU0, > > > the DS_AREA will be restored twice but this is harmless. > > > > > > Reported-by: Linus Torvalds > > > Signed-off-by: Stephane Eranian > > > --- > > > > Is this needed for the 3.8 or older kernels as well? > > > I suspect so. If CPU0 is not covered by the cpu notifiers > then yes, the patch is needed. Ok, thanks, I've queued it up now there. 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] perf,x86: fix kernel crash with PEBS/BTS after suspend/resume
On Fri, Mar 15, 2013 at 9:53 PM, Shuah Khan wrote: > On Fri, Mar 15, 2013 at 2:31 PM, Greg KH wrote: >> On Fri, Mar 15, 2013 at 02:26:07PM +0100, Stephane Eranian wrote: >>> >>> This patch fixes a kernel crash when using precise sampling (PEBS) >>> after a suspend/resume. Turns out the CPU notifier code is not invoked >>> on CPU0 (BP). Therefore, the DS_AREA (used by PEBS) is not restored properly >>> by the kernel and keeps it power-on/resume value of 0 causing any PEBS >>> measurement to crash when running on CPU0. >>> >>> The workaround is to add a hook in the actual resume code to restore >>> the DS Area MSR value. It is invoked for all CPUS. So for all but CPU0, >>> the DS_AREA will be restored twice but this is harmless. >>> >>> Reported-by: Linus Torvalds >>> Signed-off-by: Stephane Eranian >>> --- >> >> Is this needed for the 3.8 or older kernels as well? >> >> thanks, >> >> greg k-h > > Just about to ask the same question. Patch applies to 3.8, 3.4, 3.2 > and 3.5. But needs some massaging for 3.0. I have the kernels built, > haven't started testing yet. > Testing the patch is easy: # echo mem >/sys/power/state Then press the power button again, when you get control again, type: $ taskset -c 0 perf record -e cycles:pp my_test_program Note that this problem impacts only Intel processors after Core 2 (PEBS enabled). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: document the "GPIO mode" pitfall
On 03/15/2013 05:07 AM, Linus Walleij wrote:
> From: Linus Walleij
>
> Recently as adoption of the pinctrl framework is reaching
> niches where the pins are reconfigured during system sleep
> and datasheets often talk about something called "GPIO mode",
> some engineers become confused by this, thinking that since
> it is named "GPIO (something something)" it must be modeled
> in the kernel using .
> +static struct pinctrl_map __initdata pinmap[] = {
> +PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_DEFAULT", "pinctrl-foo",
Extra trailing " after PINCTRL_STATE_DEFAULT there.
Otherwise, this sounds plausible, so,
Reviewed-by: Stephen Warren
--
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] perf,x86: fix kernel crash with PEBS/BTS after suspend/resume
On Fri, Mar 15, 2013 at 2:31 PM, Greg KH wrote: > On Fri, Mar 15, 2013 at 02:26:07PM +0100, Stephane Eranian wrote: >> >> This patch fixes a kernel crash when using precise sampling (PEBS) >> after a suspend/resume. Turns out the CPU notifier code is not invoked >> on CPU0 (BP). Therefore, the DS_AREA (used by PEBS) is not restored properly >> by the kernel and keeps it power-on/resume value of 0 causing any PEBS >> measurement to crash when running on CPU0. >> >> The workaround is to add a hook in the actual resume code to restore >> the DS Area MSR value. It is invoked for all CPUS. So for all but CPU0, >> the DS_AREA will be restored twice but this is harmless. >> >> Reported-by: Linus Torvalds >> Signed-off-by: Stephane Eranian >> --- > > Is this needed for the 3.8 or older kernels as well? > > thanks, > > greg k-h Just about to ask the same question. Patch applies to 3.8, 3.4, 3.2 and 3.5. But needs some massaging for 3.0. I have the kernels built, haven't started testing yet. -- 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/
[PATCH 2/5] ARM: sunxi: Add wemac to sun4i dtsi
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun4i-a10.dtsi |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index 03d2b53..f3c2158 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -47,5 +47,12 @@
allwinner,pull = <0>;
};
};
+
+ wemac: ethernet@01c0b000 {
+ compatible = "davicom,wemac";
+ reg = <0x01c0b000 0x1000>;
+ interrupts = <55>;
+ status = "disabled";
+ };
};
};
--
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/5] ARM: sun4i: Add muxing options for the ethernet controller
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun4i-a10.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index f3c2158..fc4ce45 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -46,6 +46,17 @@
allwinner,drive = <0>;
allwinner,pull = <0>;
};
+
+ wemac_pins_a: wemac0@0 {
+ allwinner,pins = "PA0", "PA1", "PA2",
+ "PA3", "PA4", "PA5", "PA6",
+ "PA7", "PA8", "PA9", "PA10",
+ "PA11", "PA12", "PA13", "PA14",
+ "PA15", "PA16";
+ allwinner,function = "wemac";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
};
wemac: ethernet@01c0b000 {
--
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 1/5] net: Add davicom wemac ethernet driver found on Allwinner A10 SoC's
From: Stefan Roese
The Allwinner A10 has an ethernet controller that is advertised as
coming from Davicom.
The exact feature set of this controller is unknown, since there is no
public documentation for this IP, and this driver is mostly the one
published by Allwinner that has been heavily cleaned up.
Signed-off-by: Stefan Roese
Signed-off-by: Maxime Ripard
---
.../devicetree/bindings/net/davicom-wemac.txt | 20 +
drivers/net/ethernet/Makefile |2 +-
drivers/net/ethernet/davicom/Kconfig | 31 +
drivers/net/ethernet/davicom/Makefile |1 +
drivers/net/ethernet/davicom/wemac.c | 1033
drivers/net/ethernet/davicom/wemac.h | 130 +++
6 files changed, 1216 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/net/davicom-wemac.txt
create mode 100644 drivers/net/ethernet/davicom/wemac.c
create mode 100644 drivers/net/ethernet/davicom/wemac.h
diff --git a/Documentation/devicetree/bindings/net/davicom-wemac.txt
b/Documentation/devicetree/bindings/net/davicom-wemac.txt
new file mode 100644
index 000..516cf31
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/davicom-wemac.txt
@@ -0,0 +1,20 @@
+* Marvell Armada 370 / Armada XP Ethernet Controller (NETA)
+
+Required properties:
+- compatible: should be "marvell,armada-370-neta".
+- reg: address and length of the register set for the device.
+- interrupts: interrupt for the device
+
+Optional properties:
+- allwinner,power-gpios: gpio pointer if the phy needs to be
+ enabled through a GPIO.
+- (local-)mac-address: mac address to be used by this driver
+
+Example:
+
+wemac: ethernet@01c0b000 {
+ compatible = "davicom,wemac";
+ reg = <0x01c0b000 0x1000>;
+ interrupts = <55>;
+ allwinner,power-gpios = < 7 19 0>;
+};
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 8268d85..5871143 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_NET_CALXEDA_XGMAC) += calxeda/
obj-$(CONFIG_NET_VENDOR_CHELSIO) += chelsio/
obj-$(CONFIG_NET_VENDOR_CIRRUS) += cirrus/
obj-$(CONFIG_NET_VENDOR_CISCO) += cisco/
-obj-$(CONFIG_DM9000) += davicom/
+obj-$(CONFIG_NET_VENDOR_DAVICOM) += davicom/
obj-$(CONFIG_DNET) += dnet.o
obj-$(CONFIG_NET_VENDOR_DEC) += dec/
obj-$(CONFIG_NET_VENDOR_DLINK) += dlink/
diff --git a/drivers/net/ethernet/davicom/Kconfig
b/drivers/net/ethernet/davicom/Kconfig
index 9745fe5..0185e62 100644
--- a/drivers/net/ethernet/davicom/Kconfig
+++ b/drivers/net/ethernet/davicom/Kconfig
@@ -2,6 +2,23 @@
# Davicom device configuration
#
+config NET_VENDOR_DAVICOM
+ bool "Davicom devices"
+ default y
+ depends on ARM || BLACKFIN || MIPS || COLDFIRE
+ ---help---
+ If you have a network (Ethernet) card belonging to this
+ class, say Y and read the Ethernet-HOWTO, available from
+ .
+
+ Note that the answer to this question doesn't directly
+ affect the kernel: saying N will just cause the configurator
+ to skip all the questions about Davicom cards. If you say Y,
+ you will be asked for your specific card in the following
+ questions.
+
+if NET_VENDOR_DAVICOM
+
config DM9000
tristate "DM9000 support"
depends on ARM || BLACKFIN || MIPS || COLDFIRE
@@ -22,3 +39,17 @@ config DM9000_FORCE_SIMPLE_PHY_POLL
bit to determine if the link is up or down instead of the more
costly MII PHY reads. Note, this will not work if the chip is
operating with an external PHY.
+
+config WEMAC
+tristate "WEMAC support"
+ depends on OF
+ select CRC32
+ select NET_CORE
+ select MII
+---help---
+ Support for Davicom WEMAC ethernet driver.
+
+ To compile this driver as a module, choose M here. The module
+ will be called wemac.
+
+endif # NET_VENDOR_DAVICOM
diff --git a/drivers/net/ethernet/davicom/Makefile
b/drivers/net/ethernet/davicom/Makefile
index 74b31f0..803297e 100644
--- a/drivers/net/ethernet/davicom/Makefile
+++ b/drivers/net/ethernet/davicom/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_DM9000) += dm9000.o
+obj-$(CONFIG_WEMAC) += wemac.o
diff --git a/drivers/net/ethernet/davicom/wemac.c
b/drivers/net/ethernet/davicom/wemac.c
new file mode 100644
index 000..8468baf
--- /dev/null
+++ b/drivers/net/ethernet/davicom/wemac.c
@@ -0,0 +1,1033 @@
+/*
+ * Allwinner WEMAC Fast Ethernet driver for Linux.
+ *
+ * Copyright 2012 Stefan Roese
+ * Copyright 2013 Maxime Ripard
+ *
+ * Based on the Linux driver provided by Allwinner:
+ * Copyright (C) 1997 Sten Wang
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
Re: Serial port initialization broken on Armada 370/XP due to "serial: 8250_dw: Don't use UPF_FIXED_TYPE"
On Fri, Mar 15, 2013 at 04:32:51PM -0400, Jason Cooper wrote:
> On Fri, Mar 15, 2013 at 01:24:52PM -0700, Greg Kroah-Hartman wrote:
> > On Thu, Feb 28, 2013 at 02:34:21PM +0200, Heikki Krogerus wrote:
> > > Hi,
> > >
> > > On Thu, Feb 28, 2013 at 12:42:06PM +0100, Gregory CLEMENT wrote:
> > > > >> Would you agree with this kind of patch to fix the issue?
> > > > >>
> > > > >> diff --git a/drivers/tty/serial/8250/8250.c
> > > > >> b/drivers/tty/serial/8250/8250.c
> > > > >> index e2ac25a..0b284c6 100644
> > > > >> --- a/drivers/tty/serial/8250/8250.c
> > > > >> +++ b/drivers/tty/serial/8250/8250.c
> > > > >> @@ -1119,7 +1119,7 @@ static void autoconfig(struct uart_8250_port
> > > > >> *up, unsigned int probeflags)
> > > > >> serial_out(up, UART_LCR, 0);
> > > > >>
> > > > >> serial_out(up, UART_FCR, UART_FCR_ENABLE_FIFO);
> > > > >> - scratch = serial_in(up, UART_IIR) >> 6;
> > > > >> + scratch = (serial_in(up, UART_IIR) & 0xFF) >> 6;
> > > > >>
> > > > >> switch (scratch) {
> > > > >> case 0:
> > > > >
> > > > > Instead, can you test if it's enough for you to set the reg-io-width
> > > > > to 1 instead of 4:
> > > >
> > > > Yes indeed it worked and it seems to be the correct description of my
> > > > hardware. So I will fix the dtsi file.
> > > >
> > > > However isn't buggy to use a function as it returned a char whereas
> > > > it returns an int?
> > >
> > > Yes, the driver should probable be cleaned.
> > >
> > > It seems to be happening in quite a few places in 8250.c.
> > > autoconfig_16550a() has pretty much identical code in it, where
> > > UART_IIR is read to unsigned char and shifted without a mask.
> >
> > Can someone send me the correct fix here, if they want it included in
> > 3.9-final?
>
> The fix is in arm-soc/fixes slated for merging into 3.9:
Nice, I like it when I don't have to do anything
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] acpi: remove length check for large registers
Linn,
Can you explain in a bit more detail what brings this up?
I'm aware of the limitation of the generic address structure, but we are forced
by the (current) ACPI specification to use it if it is present for a given
register.
Thanks,
Bob
> -Original Message-
> From: Linn Crosetto [mailto:l...@hp.com]
> Sent: Friday, March 15, 2013 12:56 PM
> To: r...@sisk.pl; Moore, Robert; ming.m@intel.com; Zheng, Lv; linux-
> a...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Linn Crosetto
> Subject: [PATCH] acpi: remove length check for large registers
>
> The legacy bit width field in the Generic Address Structure is 1 byte,
> limiting the reportable register width to 255 bits. Larger registers will
> cause a length mismatch warning to be printed in acpi_tb_validate_fadt().
>
> To avoid the warning, disable the length mismatch check for registers
> larger than 255 bits.
>
> Signed-off-by: Linn Crosetto
> ---
> drivers/acpi/acpica/tbfadt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c
> index 74181bf..e87abcd 100644
> --- a/drivers/acpi/acpica/tbfadt.c
> +++ b/drivers/acpi/acpica/tbfadt.c
> @@ -561,6 +561,7 @@ static void acpi_tb_validate_fadt(void)
>* legacy length field and the corresponding 64-bit X length
> field.
>*/
> if (address64->address &&
> + ACPI_MUL_8(length) <= ACPI_UINT8_MAX &&
> (address64->bit_width != ACPI_MUL_8(length))) {
> ACPI_BIOS_WARNING((AE_INFO,
> "32/64X length mismatch in FADT/%s:
> %u/%u",
> --
> 1.7.11.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] ARM: hackberry: dt: Add Ethernet controller to the Hackberry device tree
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun4i-a10-hackberry.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10-hackberry.dts
b/arch/arm/boot/dts/sun4i-a10-hackberry.dts
index f84549a..3808c1a 100644
--- a/arch/arm/boot/dts/sun4i-a10-hackberry.dts
+++ b/arch/arm/boot/dts/sun4i-a10-hackberry.dts
@@ -23,8 +23,27 @@
};
soc {
+ pio: pinctrl@01c20800 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_hogs>;
+
+ hackberry_hogs: hogs@0 {
+ allwinner,pins = "PH19";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+ };
+
uart0: uart@01c28000 {
status = "okay";
};
+
+ wemac: ethernet@01c0b000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_a>;
+ status = "ok";
+ allwinner,power-gpios = < 7 19 0>;
+ };
};
};
--
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 4/5] ARM: cubieboard: Enable ethernet (WEMAC) support in dts
From: Stefan Roese
Signed-off-by: Stefan Roese
---
arch/arm/boot/dts/sun4i-a10-cubieboard.dts |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
index 88e2dc1..7a3872d 100644
--- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
+++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
@@ -43,6 +43,12 @@
uart1: uart@01c28400 {
status = "okay";
};
+
+ wemac: ethernet@01c0b000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_a>;
+ status = "okay";
+ };
};
leds {
--
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/
Re: [PATCH] perf,x86: fix kernel crash with PEBS/BTS after suspend/resume
On Fri, 15 Mar 2013, Linus Torvalds wrote: > On Fri, Mar 15, 2013 at 6:26 AM, Stephane Eranian wrote: > > > > This patch fixes a kernel crash when using precise sampling (PEBS) > > after a suspend/resume. > > Yup, works. Applied. > > Can we please get rid of the crazy CPU notifier crap from the perf > code, and do this like we do most other wrmsr's etc? Doing > > git grep "case CPU_" arch/x86/kernel/cpu > > shows that the perf layer seems to be full of this kind of BS. This is > all CPU state, it should be initialized by the regular CPU > initialization code, not hooked up with some random callbacks. It's on my list -- 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] perf,x86: fix kernel crash with PEBS/BTS after suspend/resume
On Fri, Mar 15, 2013 at 9:31 PM, Greg KH wrote: > > On Fri, Mar 15, 2013 at 02:26:07PM +0100, Stephane Eranian wrote: > > > > This patch fixes a kernel crash when using precise sampling (PEBS) > > after a suspend/resume. Turns out the CPU notifier code is not invoked > > on CPU0 (BP). Therefore, the DS_AREA (used by PEBS) is not restored properly > > by the kernel and keeps it power-on/resume value of 0 causing any PEBS > > measurement to crash when running on CPU0. > > > > The workaround is to add a hook in the actual resume code to restore > > the DS Area MSR value. It is invoked for all CPUS. So for all but CPU0, > > the DS_AREA will be restored twice but this is harmless. > > > > Reported-by: Linus Torvalds > > Signed-off-by: Stephane Eranian > > --- > > Is this needed for the 3.8 or older kernels as well? > I suspect so. If CPU0 is not covered by the cpu notifiers then yes, the patch is needed. > > 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 RFC 1/3] seccomp: add generic code for jitted seccomp filters.
On Fri, 2013-03-15 at 11:45 -0700, Kees Cook wrote: > On Fri, Mar 15, 2013 at 11:28 AM, Nicolas Schichan > wrote: > > diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h > > index 6f19cfd..af27494 100644 > > --- a/include/linux/seccomp.h > > +++ b/include/linux/seccomp.h > > @@ -6,6 +6,7 @@ > > #ifdef CONFIG_SECCOMP > > > > #include > > +#include > > #include > > > > struct seccomp_filter; > > @@ -47,6 +48,44 @@ static inline int seccomp_mode(struct seccomp *s) > > return s->mode; > > } > > > > +/** > > + * struct seccomp_filter - container for seccomp BPF programs > > + * > > + * @usage: reference count to manage the object lifetime. > > + * get/put helpers should be used when accessing an instance > > + * outside of a lifetime-guarded section. In general, this > > + * is only needed for handling filters shared across tasks. > > + * @prev: points to a previously installed, or inherited, filter > > + * @len: the number of instructions in the program > > + * @insns: the BPF program instructions to evaluate > > This should be updated to include the new bpf_func field. > > Regardless, it'd be better to not expose this structure to userspace. This is fine include/uapi/linux/seccomp.h is exposed to userspace include/linux/seccomp.h is kernel internal -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cifs: Rename cERROR and cFYI to cifs_dbg
On Fri, 2013-03-15 at 15:16 -0500, Steve French wrote: > I would like to merge the three we have (one still has to be put in > for-next - the one from Jeff) for for-next in the next three or fouir > days - but I can create another temporary branch for the ones for 3.10 > - but ... I would like to simplify things by merging the other cleanup > patches we already have first. I agree that we are going to have to > let people know to rebase everything for cifs for 3.10 on this big > cleanup patch. Another possibility is to extend the cifs_dbg(type, fmt. ...) types from VFS, FYI, NOISY so that the messages could be filtered/classified better. Also, perhaps it'd be better to use pr_debug instead of KERN_ERR for the VFS messages. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] integrity: Identify asymmetric digital signature using new type
Currently there seem to be two types of digital signatures. Old one and
that is RSA and new one which is being called asymmetric. Right now they
both fall in the categorty of EVM_IMA_XATTR_DIGSIG and one differentiates
between two using signature version. Version 1 is old type and version 2
is new type.
How about asymmetric signature using a new type say
EVM_IMA_XATTR_DIGSIG_ASYMMETRIC. And version numbering can be used for
structure variation with-in signature type.
This can allow to export signature type to other subsystems. And these
subsystems will call into ima/integrity for verification only if signature
are of certain type.
Signed-off-by: Vivek Goyal
---
security/integrity/digsig.c | 11 +++
security/integrity/evm/evm_main.c |4 +++-
security/integrity/ima/ima_appraise.c |7 +--
security/integrity/integrity.h| 14 +-
4 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index 0b759e1..268c4cc 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -27,7 +27,8 @@ static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
"_ima",
};
-int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,
+int integrity_digsig_verify(enum evm_ima_xattr_type sig_type,
+ const unsigned int id, const char *sig, int siglen,
const char *digest, int digestlen)
{
if (id >= INTEGRITY_KEYRING_MAX)
@@ -44,13 +45,15 @@ int integrity_digsig_verify(const unsigned int id, const
char *sig, int siglen,
}
}
- switch (sig[0]) {
- case 1:
+ switch (sig_type) {
+ case EVM_IMA_XATTR_DIGSIG:
return digsig_verify(keyring[id], sig, siglen,
digest, digestlen);
- case 2:
+ case EVM_IMA_XATTR_DIGSIG_ASYMMETRIC:
return asymmetric_verify(keyring[id], sig, siglen,
digest, digestlen);
+ default:
+ break;
}
return -EOPNOTSUPP;
diff --git a/security/integrity/evm/evm_main.c
b/security/integrity/evm/evm_main.c
index cdbde17..cf798cb 100644
--- a/security/integrity/evm/evm_main.c
+++ b/security/integrity/evm/evm_main.c
@@ -134,11 +134,13 @@ static enum integrity_status evm_verify_hmac(struct
dentry *dentry,
rc = -EINVAL;
break;
case EVM_IMA_XATTR_DIGSIG:
+ case EVM_IMA_XATTR_DIGSIG_ASYMMETRIC:
rc = evm_calc_hash(dentry, xattr_name, xattr_value,
xattr_value_len, calc.digest);
if (rc)
break;
- rc = integrity_digsig_verify(INTEGRITY_KEYRING_EVM,
+ rc = integrity_digsig_verify(xattr_data->type,
+ INTEGRITY_KEYRING_EVM,
xattr_data->digest, xattr_len,
calc.digest, sizeof(calc.digest));
if (!rc) {
diff --git a/security/integrity/ima/ima_appraise.c
b/security/integrity/ima/ima_appraise.c
index 2d4beca..9bc0723 100644
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -169,8 +169,10 @@ int ima_appraise_measurement(int func, struct
integrity_iint_cache *iint,
status = INTEGRITY_PASS;
break;
case EVM_IMA_XATTR_DIGSIG:
+ case EVM_IMA_XATTR_DIGSIG_ASYMMETRIC:
iint->flags |= IMA_DIGSIG;
- rc = integrity_digsig_verify(INTEGRITY_KEYRING_IMA,
+ rc = integrity_digsig_verify(xattr_value->type,
+INTEGRITY_KEYRING_IMA,
xattr_value->digest, rc - 1,
iint->ima_xattr.digest,
IMA_DIGEST_SIZE);
@@ -193,7 +195,8 @@ out:
if (status != INTEGRITY_PASS) {
if ((ima_appraise & IMA_APPRAISE_FIX) &&
(!xattr_value ||
-xattr_value->type != EVM_IMA_XATTR_DIGSIG)) {
+(xattr_value->type != EVM_IMA_XATTR_DIGSIG &&
+ xattr_value->type != EVM_IMA_XATTR_DIGSIG_ASYMMETRIC))) {
if (!ima_fix_xattr(dentry, iint))
status = INTEGRITY_PASS;
}
diff --git a/security/integrity/integrity.h b/security/integrity/integrity.h
index 84c37c4..8392d18 100644
--- a/security/integrity/integrity.h
+++ b/security/integrity/integrity.h
@@ -50,12 +50,6 @@
#define IMA_APPRAISED_SUBMASK (IMA_FILE_APPRAISED | IMA_MMAP_APPRAISED | \
IMA_BPRM_APPRAISED | IMA_MODULE_APPRAISED)
-enum evm_ima_xattr_type {
- IMA_XATTR_DIGEST = 0x01,
-
[PATCH v11 1/3] tracing: Add DEFINE_EVENT_FN() macro
Each TRACE_EVENT() adds several helper functions. If two or more trace events share the same structure and print format, they can also share most of these helper functions and save a lot of space from duplicate code. This is why the DECLARE_EVENT_CLASS() and DEFINE_EVENT() were created. Some events require a trigger to be called at registering and unregistering of the event and to do so they use TRACE_EVENT_FN(). If multiple events require a trigger, they currently have no choice but to use TRACE_EVENT_FN() as there's no DEFINE_EVENT_FN() available. This unfortunately causes a lot of wasted duplicate code created. By adding a DEFINE_EVENT_FN(), these events can still use a DECLARE_EVENT_CLASS() and then define their own triggers. Signed-off-by: Steven Rostedt Signed-off-by: Seiji Aguchi --- include/linux/tracepoint.h |2 ++ include/trace/define_trace.h |5 + include/trace/ftrace.h |4 3 files changed, 11 insertions(+), 0 deletions(-) diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h index 2f322c3..9bf59e5 100644 --- a/include/linux/tracepoint.h +++ b/include/linux/tracepoint.h @@ -378,6 +378,8 @@ static inline void tracepoint_synchronize_unregister(void) #define DECLARE_EVENT_CLASS(name, proto, args, tstruct, assign, print) #define DEFINE_EVENT(template, name, proto, args) \ DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) +#define DEFINE_EVENT_FN(template, name, proto, args, reg, unreg)\ + DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) #define DEFINE_EVENT_PRINT(template, name, proto, args, print) \ DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) #define DEFINE_EVENT_CONDITION(template, name, proto, \ diff --git a/include/trace/define_trace.h b/include/trace/define_trace.h index 1905ca8..02e1003 100644 --- a/include/trace/define_trace.h +++ b/include/trace/define_trace.h @@ -44,6 +44,10 @@ #define DEFINE_EVENT(template, name, proto, args) \ DEFINE_TRACE(name) +#undef DEFINE_EVENT_FN +#define DEFINE_EVENT_FN(template, name, proto, args, reg, unreg) \ + DEFINE_TRACE_FN(name, reg, unreg) + #undef DEFINE_EVENT_PRINT #define DEFINE_EVENT_PRINT(template, name, proto, args, print) \ DEFINE_TRACE(name) @@ -91,6 +95,7 @@ #undef TRACE_EVENT_CONDITION #undef DECLARE_EVENT_CLASS #undef DEFINE_EVENT +#undef DEFINE_EVENT_FN #undef DEFINE_EVENT_PRINT #undef DEFINE_EVENT_CONDITION #undef TRACE_HEADER_MULTI_READ diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h index 40dc5e8..7bab676 100644 --- a/include/trace/ftrace.h +++ b/include/trace/ftrace.h @@ -71,6 +71,10 @@ static struct ftrace_event_call __used \ __attribute__((__aligned__(4))) event_##name +#undef DEFINE_EVENT_FN +#define DEFINE_EVENT_FN(template, name, proto, args, reg, unreg) \ + DEFINE_EVENT(template, name, PARAMS(proto), PARAMS(args)) + #undef DEFINE_EVENT_PRINT #define DEFINE_EVENT_PRINT(template, name, proto, args, print) \ DEFINE_EVENT(template, name, PARAMS(proto), PARAMS(args)) -- 1.7.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 v11 0/3]trace,x86: irq vector tracepoint support
Change log
v10 -> v11
- Rebase to 3.9-rc2
- Add a modification for hyperv_callback vector. (patch 2/3)
- Change a way to switch idt to check the table in use instead of
saving/restoring it,
because saving/restoring functions will break if we have to add another one.
(patch 2/3)
v9 -> v10
- Add an explanation the reason why tracepoints has to place inside irq
enter/exit handling. (patch 3/3)
v8 -> v9
- Rebase to 3.8-rc6
- Add Steven's email address at the top of the message and
move my signed-off-by below Steven's one because it is
originally created by Steven. (patch 1/3)
- Introduce a irq_vector_mutex to avoid a race at registering/unregistering
time. (patch 2/3)
- Use a per_cpu data to orig_idt_descr because IDT descritor is needed to each
cpu
and the appropriate data type is per_cpu data. It is suggested by Steven.
(patch 2/3)
v7 -> v8
- Rebase to 3.8-rc4
- Add a patch 1 introducing DEFINE_EVENT_FN() macro.
- Rename original patches 1 and 2 to 2 and 3.
- Change a definition of tracepoint to use DEFINE_EVENT_FN(). (patch 2)
- Change alloc_intr_gate() to use do{}while(0) to avoid a warning
of checkpatch.pl. (patch 2)
- Move entering_irq()/exiting_irq() to arch/x86/include/asm/apic.h (patch 3)
v6 -> v7
- Divide into two patches to make a code review easier.
Summery of each patch is as follows.
- Patch 1/2
- Add an irq_vector tracing infrastructure.
- Create idt_table for tracing. It is refactored to avoid duplicating
existing logic.
- Duplicate new irq handlers inserted tracepoints.
- Patch 2/2
- Share a common logic among irq handlers to make them
manageable and readable.
v5 -> v6
- Rebased to 3.7
v4 -> v5
- Rebased to 3.6.0
- Introduce a logic switching IDT at enabling/disabling TP time
so that a time penalty makes a zero when tracepoints are disabled.
This IDT is created only when CONFIG_TRACEPOINTS is enabled.
- Remove arch_irq_vector_entry/exit and add followings again
so that we can add each tracepoint in a generic way.
- error_apic_vector
- thermal_apic_vector
- threshold_apic_vector
- spurious_apic_vector
- x86_platform_ipi_vector
- Drop nmi tracepoints to begin with apic interrupts and discuss a logic
switching
IDT first.
- Move irq_vectors.h in the directory of arch/x86/include/asm/trace because
I'm not sure if a logic switching IDT is sharable with other architectures.
v3 -> v4
- Add a latency measurement of each tracepoint
- Rebased to 3.6-rc6
v2 -> v3
- Remove an invalidate_tlb_vector event because it was replaced by a call
function vector
in a following commit.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=52aec3308db85f4e9f5c8b9f5dc4fbd0138c6fa4
v1 -> v2
- Modify variable name from irq to vector.
- Merge arch-specific tracepoints below to an arch_irq_vector_entry/exit.
- error_apic_vector
- thermal_apic_vector
- threshold_apic_vector
- spurious_apic_vector
- x86_platform_ipi_vector
[Purpose of this patch]
As Vaibhav explained in the thread below, tracepoints for irq vectors are
useful.
http://www.spinics.net/lists/mm-commits/msg85707.html
The current interrupt traces from irq_handler_entry and irq_handler_exit
provide when an interrupt is handled.
They provide good data about when the system has switched to kernel space and
how it affects the currently running processes.
There are some IRQ vectors which trigger the system into kernel space, which
are not handled in generic IRQ handlers.
Tracing such events gives us the information about IRQ interaction with other
system events.
The trace also tells where the system is spending its time. We want to know
which cores are handling interrupts and
how they are affecting other processes in the system. Also, the trace provides
information about when the cores are
idle and which interrupts are changing that state.
On the other hand, my usecase is tracing just local timer event and getting a
value of instruction pointer.
I suggested to add an argument local timer event to get instruction pointer
before.
But there is another way to get it with external module like systemtap.
So, I don't need to add any argument to irq vector tracepoints now.
[Patch Description]
Vaibhav's patch shared a trace point ,irq_vector_entry/irq_vector_exit, in all
events.
But there is an above use case to trace specific irq_vector rather than tracing
all events.
In this case, we are concerned about overhead due to unwanted events.
This patch adds following tracepoints instead of introducing
irq_vector_entry/exit.
so that we can enable them independently.
- local_timer_vector
- reschedule_vector
- call_function_vector
- call_function_single_vector
- irq_work_entry_vector
- error_apic_vector
- thermal_apic_vector
- threshold_apic_vector
- spurious_apic_vector
- x86_platform_ipi_vector
Please see descriptions
