[patch 2/2] mm, oom: fix race when specifying a thread as the oom origin
test_set_oom_score_adj() and compare_swap_oom_score_adj() are used to
specify that current should be killed first if an oom condition occurs in
between the two calls.
The usage is
short oom_score_adj = test_set_oom_score_adj(OOM_SCORE_ADJ_MAX);
...
compare_swap_oom_score_adj(OOM_SCORE_ADJ_MAX, oom_score_adj);
to store the thread's oom_score_adj, temporarily change it to the maximum
score possible, and then restore the old value if it is still the same.
This happens to still be racy, however, if the user writes
OOM_SCORE_ADJ_MAX to /proc/pid/oom_score_adj in between the two calls.
The compare_swap_oom_score_adj() will then incorrectly reset the old
value prior to the write of OOM_SCORE_ADJ_MAX.
To fix this, introduce a new oom_flags_t member in struct signal_struct
that will be used for per-thread oom killer flags. KSM and swapoff can
now use a bit in this member to specify that threads should be killed
first in oom conditions without playing around with oom_score_adj.
This also allows the correct oom_score_adj to always be shown when
reading /proc/pid/oom_score.
Signed-off-by: David Rientjes
---
include/linux/oom.h | 19 +--
include/linux/sched.h |1 +
include/linux/types.h |1 +
mm/ksm.c |7 ++-
mm/oom_kill.c | 49 +++--
mm/swapfile.c |5 ++---
6 files changed, 30 insertions(+), 52 deletions(-)
diff --git a/include/linux/oom.h b/include/linux/oom.h
--- a/include/linux/oom.h
+++ b/include/linux/oom.h
@@ -29,8 +29,23 @@ enum oom_scan_t {
OOM_SCAN_SELECT,/* always select this thread first */
};
-extern void compare_swap_oom_score_adj(short old_val, short new_val);
-extern short test_set_oom_score_adj(short new_val);
+/* Thread is the potential origin of an oom condition; kill first on oom */
+#define OOM_FLAG_ORIGIN((__force oom_flags_t)0x1)
+
+static inline void set_current_oom_origin(void)
+{
+ current->signal->oom_flags |= OOM_FLAG_ORIGIN;
+}
+
+static inline void clear_current_oom_origin(void)
+{
+ current->signal->oom_flags &= ~OOM_FLAG_ORIGIN;
+}
+
+static inline bool oom_task_origin(const struct task_struct *p)
+{
+ return !!(p->signal->oom_flags & OOM_FLAG_ORIGIN);
+}
extern unsigned long oom_badness(struct task_struct *p,
struct mem_cgroup *memcg, const nodemask_t *nodemask,
diff --git a/include/linux/sched.h b/include/linux/sched.h
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -631,6 +631,7 @@ struct signal_struct {
struct rw_semaphore group_rwsem;
#endif
+ oom_flags_t oom_flags;
short oom_score_adj;/* OOM kill score adjustment */
short oom_score_adj_min;/* OOM kill score adjustment min value.
* Only settable by CAP_SYS_RESOURCE. */
diff --git a/include/linux/types.h b/include/linux/types.h
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -156,6 +156,7 @@ typedef u32 dma_addr_t;
#endif
typedef unsigned __bitwise__ gfp_t;
typedef unsigned __bitwise__ fmode_t;
+typedef unsigned __bitwise__ oom_flags_t;
#ifdef CONFIG_PHYS_ADDR_T_64BIT
typedef u64 phys_addr_t;
diff --git a/mm/ksm.c b/mm/ksm.c
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1929,12 +1929,9 @@ static ssize_t run_store(struct kobject *kobj, struct
kobj_attribute *attr,
if (ksm_run != flags) {
ksm_run = flags;
if (flags & KSM_RUN_UNMERGE) {
- short oom_score_adj;
-
- oom_score_adj =
test_set_oom_score_adj(OOM_SCORE_ADJ_MAX);
+ set_current_oom_origin();
err = unmerge_and_remove_all_rmap_items();
- compare_swap_oom_score_adj(OOM_SCORE_ADJ_MAX,
- oom_score_adj);
+ clear_current_oom_origin();
if (err) {
ksm_run = KSM_RUN_STOP;
count = err;
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -44,48 +44,6 @@ int sysctl_oom_kill_allocating_task;
int sysctl_oom_dump_tasks = 1;
static DEFINE_SPINLOCK(zone_scan_lock);
-/*
- * compare_swap_oom_score_adj() - compare and swap current's oom_score_adj
- * @old_val: old oom_score_adj for compare
- * @new_val: new oom_score_adj for swap
- *
- * Sets the oom_score_adj value for current to @new_val iff its present value
is
- * @old_val. Usually used to reinstate a previous value to prevent racing with
- * userspacing tuning the value in the interim.
- */
-void compare_swap_oom_score_adj(short old_val, short new_val)
-{
- struct sighand_struct *sighand = current->sighand;
-
- spin_lock_irq(>siglock);
- if (current->signal->oom_score_adj == old_val)
- current->signal->oom_score_adj = new_val;
[patch 1/2] mm, oom: change type of oom_score_adj to short
The maximum oom_score_adj is 1000 and the minimum oom_score_adj is -1000,
so this range can be represented by the signed short type with no
functional change. The extra space this frees up in struct signal_struct
will be used for per-thread oom kill flags in the next patch.
Signed-off-by: David Rientjes
---
drivers/staging/android/lowmemorykiller.c | 16
fs/proc/base.c| 10 +-
include/linux/oom.h |4 ++--
include/linux/sched.h |6 +++---
include/trace/events/oom.h|4 ++--
include/trace/events/task.h |8
mm/ksm.c |2 +-
mm/oom_kill.c | 10 +-
mm/swapfile.c |2 +-
9 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/staging/android/lowmemorykiller.c
b/drivers/staging/android/lowmemorykiller.c
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -40,7 +40,7 @@
#include
static uint32_t lowmem_debug_level = 2;
-static int lowmem_adj[6] = {
+static short lowmem_adj[6] = {
0,
1,
6,
@@ -70,9 +70,9 @@ static int lowmem_shrink(struct shrinker *s, struct
shrink_control *sc)
int rem = 0;
int tasksize;
int i;
- int min_score_adj = OOM_SCORE_ADJ_MAX + 1;
+ short min_score_adj = OOM_SCORE_ADJ_MAX + 1;
int selected_tasksize = 0;
- int selected_oom_score_adj;
+ short selected_oom_score_adj;
int array_size = ARRAY_SIZE(lowmem_adj);
int other_free = global_page_state(NR_FREE_PAGES);
int other_file = global_page_state(NR_FILE_PAGES) -
@@ -90,7 +90,7 @@ static int lowmem_shrink(struct shrinker *s, struct
shrink_control *sc)
}
}
if (sc->nr_to_scan > 0)
- lowmem_print(3, "lowmem_shrink %lu, %x, ofree %d %d, ma %d\n",
+ lowmem_print(3, "lowmem_shrink %lu, %x, ofree %d %d, ma %hd\n",
sc->nr_to_scan, sc->gfp_mask, other_free,
other_file, min_score_adj);
rem = global_page_state(NR_ACTIVE_ANON) +
@@ -107,7 +107,7 @@ static int lowmem_shrink(struct shrinker *s, struct
shrink_control *sc)
rcu_read_lock();
for_each_process(tsk) {
struct task_struct *p;
- int oom_score_adj;
+ short oom_score_adj;
if (tsk->flags & PF_KTHREAD)
continue;
@@ -141,11 +141,11 @@ static int lowmem_shrink(struct shrinker *s, struct
shrink_control *sc)
selected = p;
selected_tasksize = tasksize;
selected_oom_score_adj = oom_score_adj;
- lowmem_print(2, "select %d (%s), adj %d, size %d, to kill\n",
+ lowmem_print(2, "select %d (%s), adj %hd, size %d, to kill\n",
p->pid, p->comm, oom_score_adj, tasksize);
}
if (selected) {
- lowmem_print(1, "send sigkill to %d (%s), adj %d, size %d\n",
+ lowmem_print(1, "send sigkill to %d (%s), adj %hd, size %d\n",
selected->pid, selected->comm,
selected_oom_score_adj, selected_tasksize);
lowmem_deathpending_timeout = jiffies + HZ;
@@ -176,7 +176,7 @@ static void __exit lowmem_exit(void)
}
module_param_named(cost, lowmem_shrinker.seeks, int, S_IRUGO | S_IWUSR);
-module_param_array_named(adj, lowmem_adj, int, _adj_size,
+module_param_array_named(adj, lowmem_adj, short, _adj_size,
S_IRUGO | S_IWUSR);
module_param_array_named(minfree, lowmem_minfree, uint, _minfree_size,
S_IRUGO | S_IWUSR);
diff --git a/fs/proc/base.c b/fs/proc/base.c
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -878,7 +878,7 @@ static ssize_t oom_score_adj_read(struct file *file, char
__user *buf,
{
struct task_struct *task = get_proc_task(file->f_path.dentry->d_inode);
char buffer[PROC_NUMBUF];
- int oom_score_adj = OOM_SCORE_ADJ_MIN;
+ short oom_score_adj = OOM_SCORE_ADJ_MIN;
unsigned long flags;
size_t len;
@@ -889,7 +889,7 @@ static ssize_t oom_score_adj_read(struct file *file, char
__user *buf,
unlock_task_sighand(task, );
}
put_task_struct(task);
- len = snprintf(buffer, sizeof(buffer), "%d\n", oom_score_adj);
+ len = snprintf(buffer, sizeof(buffer), "%hd\n", oom_score_adj);
return simple_read_from_buffer(buf, count, ppos, buffer, len);
}
@@ -936,15 +936,15 @@ static ssize_t oom_score_adj_write(struct file *file,
const char __user *buf,
goto err_task_lock;
}
- if (oom_score_adj < task->signal->oom_score_adj_min &&
+ if ((short)oom_score_adj < task->signal->oom_score_adj_min &&
[PATCH -next] mtip32xx: fix potential NULL pointer dereference in mtip_timeout_function()
From: Wei Yongjun
The dereference to port should be moved below the NULL test.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun
---
drivers/block/mtip32xx/mtip32xx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers/block/mtip32xx/mtip32xx.c
index adc6f36..fe16b32 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -559,7 +559,7 @@ static void mtip_timeout_function(unsigned long int data)
struct mtip_cmd *command;
int tag, cmdto_cnt = 0;
unsigned int bit, group;
- unsigned int num_command_slots = port->dd->slot_groups * 32;
+ unsigned int num_command_slots;
unsigned long to, tagaccum[SLOTBITS_IN_LONGS];
if (unlikely(!port))
@@ -572,6 +572,7 @@ static void mtip_timeout_function(unsigned long int data)
}
/* clear the tag accumulator */
memset(tagaccum, 0, SLOTBITS_IN_LONGS * sizeof(long));
+ num_command_slots = port->dd->slot_groups * 32;
for (tag = 0; tag < num_command_slots; tag++) {
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v7 0/3] Add modules to support realtek PCIE card reader
Hi Wei, On Mon, Oct 29, 2012 at 01:49:28PM +0800, wei_w...@realsil.com.cn wrote: > From: Wei WANG > > Support for Realtek PCI-Express driver-based card readers including rts5209, > rts5229 and rtl8411. All 3 patches applied now, thanks a lot. I also fixed the Kconfig entry where you forgot to select MFD_CORE. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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 3/9] cgroup: implement generic child / descendant walk macros
On Sat 03-11-12 01:38:29, Tejun Heo wrote:
> Currently, cgroup doesn't provide any generic helper for walking a
> given cgroup's children or descendants. This patch adds the following
> three macros.
>
> * cgroup_for_each_child() - walk immediate children of a cgroup.
>
> * cgroup_for_each_descendant_pre() - visit all descendants of a cgroup
> in pre-order tree traversal.
>
> * cgroup_for_each_descendant_post() - visit all descendants of a
> cgroup in post-order tree traversal.
>
> All three only require the user to hold RCU read lock during
> traversal. Verifying that each iterated cgroup is online is the
> responsibility of the user. When used with proper synchronization,
> cgroup_for_each_descendant_pre() can be used to propagate config
> updates to descendants in reliable way. See comments for details.
>
> Signed-off-by: Tejun Heo
I will convert mem_cgroup_iter to use this rather than css_get_next
after this gets into the next tree so that it can fly via Andrew.
Reviewed-by: Michal Hocko
Just a minor knit. You are talking about a config propagation while I
would consider state propagation more clear and less confusing. Config
is usually stable enough so that post_create is not necessary for
syncing (e.g. memcg.swappiness). It is a state which must be consistent
throughout the hierarchy which matters here.
Thanks!
> ---
> include/linux/cgroup.h | 82 +++
> kernel/cgroup.c| 86
> ++
> 2 files changed, 168 insertions(+)
>
> diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
> index 90c33eb..0020329 100644
> --- a/include/linux/cgroup.h
> +++ b/include/linux/cgroup.h
> @@ -534,6 +534,88 @@ static inline struct cgroup* task_cgroup(struct
> task_struct *task,
> return task_subsys_state(task, subsys_id)->cgroup;
> }
>
> +/**
> + * cgroup_for_each_child - iterate through children of a cgroup
> + * @pos: the cgroup * to use as the loop cursor
> + * @cgroup: cgroup whose children to walk
> + *
> + * Walk @cgroup's children. Must be called under rcu_read_lock(). A child
> + * cgroup which hasn't finished ->post_create() or already has finished
> + * ->pre_destroy() may show up during traversal and it's each subsystem's
> + * responsibility to verify that each @pos is alive.
> + *
> + * If a subsystem synchronizes against the parent in its ->post_create()
> + * and before starting iterating, a cgroup which finished ->post_create()
> + * is guaranteed to be visible in the future iterations.
> + */
> +#define cgroup_for_each_child(pos, cgroup) \
> + list_for_each_entry_rcu(pos, &(cgroup)->children, sibling)
> +
> +struct cgroup *cgroup_next_descendant_pre(struct cgroup *pos,
> + struct cgroup *cgroup);
> +
> +/**
> + * cgroup_for_each_descendant_pre - pre-order walk of a cgroup's descendants
> + * @pos: the cgroup * to use as the loop cursor
> + * @cgroup: cgroup whose descendants to walk
> + *
> + * Walk @cgroup's descendants. Must be called under rcu_read_lock(). A
> + * descendant cgroup which hasn't finished ->post_create() or already has
> + * finished ->pre_destroy() may show up during traversal and it's each
> + * subsystem's responsibility to verify that each @pos is alive.
> + *
> + * If a subsystem synchronizes against the parent in its ->post_create()
> + * and before starting iterating, and synchronizes against @pos on each
> + * iteration, any descendant cgroup which finished ->post_create() is
> + * guaranteed to be visible in the future iterations.
> + *
> + * In other words, the following guarantees that a descendant can't escape
> + * configuration of its ancestors.
> + *
> + * my_post_create(@cgrp)
> + * {
> + * Lock @cgrp->parent and @cgrp;
> + * Inherit config from @cgrp->parent;
> + * Unlock both.
> + * }
> + *
> + * my_update_config(@cgrp)
> + * {
> + * Lock @cgrp;
> + * Update @cgrp's config;
> + * Unlock @cgrp;
> + *
> + * cgroup_for_each_descendant_pre(@pos, @cgrp) {
> + * Lock @pos;
> + * Verify @pos is alive and inherit config from @pos->parent;
> + * Unlock @pos;
> + * }
> + * }
> + *
> + * Alternatively, a subsystem may choose to use a single global lock to
> + * synchronize ->post_create() and ->pre_destroy() against tree-walking
> + * operations.
> + */
> +#define cgroup_for_each_descendant_pre(pos, cgroup) \
> + for (pos = cgroup_next_descendant_pre(NULL, (cgroup)); (pos); \
> + pos = cgroup_next_descendant_pre((pos), (cgroup)))
> +
> +struct cgroup *cgroup_next_descendant_post(struct cgroup *pos,
> +struct cgroup *cgroup);
> +
> +/**
> + * cgroup_for_each_descendant_post - post-order walk of a cgroup's
> descendants
> + * @pos: the cgroup * to use as the loop cursor
> + * @cgroup: cgroup whose descendants to walk
> + *
> + * Similar to
Re: [BUGFIX] PM: Fix active child counting when disabled and forbidden
On Thursday, November 08, 2012 10:04:36 AM Huang Ying wrote: > On Thu, 2012-11-08 at 02:35 +0100, Rafael J. Wysocki wrote: > > On Thursday, November 08, 2012 09:15:08 AM Huang Ying wrote: > > > On Thu, 2012-11-08 at 00:09 +0100, Rafael J. Wysocki wrote: [...] > > > I think the patch can fix the issue in a better way. > > > > I'm not sure what you mean. > > I mean your patch can fix the driver-less VGA issue. And it is better > than my original patch. The following discussion is not about this > specific issue. Just about PM core logic. OK > > > Do we still need to clarify state about disabled and forbidden? When a > > > device is forbidden and the usage_count > 0, > > > > "Forbidden" always means usage_count > 0. > > Yes. > > > > is it a good idea to allow to set device state to SUSPENDED if the device > > > is disabled? > > > > No, it is not. The status should always be ACTIVE as long as usage_count > > > 0. > > However, in some cases we actually would like to change the status to > > SUSPENDED when usage_count becomes equal to 0, because that means we can > > suspend (I mean really suspend) the parents of the devices in question > > (and we want to notify the parents in those cases). > > So do you think Alan Stern's suggestion about forbidden and disabled is > the right way to go? I'm not really sure about that. My original idea was that the runtime PM status and usage counter would only matter when runtime PM of a device was enabled. That leads to problems, though, when we enable runtime PM of a device whose usage counter is greater from zero and status is SUSPENDED. Also when the device's status is ACTIVE, but its parent's child count is 0. It's not very easy to fix this at the core level, though, because we depend on the current behavior in some places. I'm thinking that perhaps pm_runtime_enable() should just WARN() if things are obviously inconsistent (although there still may be problems, for example, if the parent's child count is 2 when we enable runtime PM for its child, but that child is the only one it actually has). Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, 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/
Re: [PATCH] pwm: lpc32xx - Fix the PWM polarity
On 07/11/12 16:25, Alban Bedel wrote: > Signed-off-by: Alban Bedel > --- > drivers/pwm/pwm-lpc32xx.c |6 +- > 1 files changed, 5 insertions(+), 1 deletions(-) > > diff --git a/drivers/pwm/pwm-lpc32xx.c b/drivers/pwm/pwm-lpc32xx.c > index adb87f0..0dc278d 100644 > --- a/drivers/pwm/pwm-lpc32xx.c > +++ b/drivers/pwm/pwm-lpc32xx.c > @@ -51,7 +51,11 @@ static int lpc32xx_pwm_config(struct pwm_chip *chip, > struct pwm_device *pwm, > > c = 256 * duty_ns; > do_div(c, period_ns); > - duty_cycles = c; > + if (c == 0) > + c = 256; > + if (c > 255) > + c = 255; > + duty_cycles = 256 - c; Except for the range check (for the original c > 255), this results in: duty_cycles = 256 - c except for (c == 0) where duty_cycles = 1 which actually is duty_cycles = (256 - c) - 255 (think with the original c) i.e. nearly a polarity inversion in the case of (c == 0). Why is the case (c == 0) so special here? Maybe you can document this, if it is really intended? > > writel(PWM_ENABLE | PWM_RELOADV(period_cycles) | PWM_DUTY(duty_cycles), > lpc32xx->base + (pwm->hwpwm << 2)); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/9] cgroup_freezer: trivial cleanups
On Sat 03-11-12 01:38:30, Tejun Heo wrote:
> * Clean-up indentation and line-breaks. Drop the invalid comment
> about freezer->lock.
>
> * Make all internal functions take @freezer instead of both @cgroup
> and @freezer.
>
> Signed-off-by: Tejun Heo
Looks reasonable
Reviewed-by: Michal Hocko
> ---
> kernel/cgroup_freezer.c | 41 +++--
> 1 file changed, 19 insertions(+), 22 deletions(-)
>
> diff --git a/kernel/cgroup_freezer.c b/kernel/cgroup_freezer.c
> index bedefd9..975b3d8 100644
> --- a/kernel/cgroup_freezer.c
> +++ b/kernel/cgroup_freezer.c
> @@ -29,17 +29,15 @@ enum freezer_state {
> };
>
> struct freezer {
> - struct cgroup_subsys_state css;
> - enum freezer_state state;
> - spinlock_t lock; /* protects _writes_ to state */
> + struct cgroup_subsys_state css;
> + enum freezer_state state;
> + spinlock_t lock;
> };
>
> -static inline struct freezer *cgroup_freezer(
> - struct cgroup *cgroup)
> +static inline struct freezer *cgroup_freezer(struct cgroup *cgroup)
> {
> - return container_of(
> - cgroup_subsys_state(cgroup, freezer_subsys_id),
> - struct freezer, css);
> + return container_of(cgroup_subsys_state(cgroup, freezer_subsys_id),
> + struct freezer, css);
> }
>
> static inline struct freezer *task_freezer(struct task_struct *task)
> @@ -180,8 +178,9 @@ out:
> * migrated into or out of @cgroup, so we can't verify task states against
> * @freezer state here. See freezer_attach() for details.
> */
> -static void update_if_frozen(struct cgroup *cgroup, struct freezer *freezer)
> +static void update_if_frozen(struct freezer *freezer)
> {
> + struct cgroup *cgroup = freezer->css.cgroup;
> struct cgroup_iter it;
> struct task_struct *task;
>
> @@ -211,12 +210,11 @@ notyet:
> static int freezer_read(struct cgroup *cgroup, struct cftype *cft,
> struct seq_file *m)
> {
> - struct freezer *freezer;
> + struct freezer *freezer = cgroup_freezer(cgroup);
> enum freezer_state state;
>
> - freezer = cgroup_freezer(cgroup);
> spin_lock_irq(>lock);
> - update_if_frozen(cgroup, freezer);
> + update_if_frozen(freezer);
> state = freezer->state;
> spin_unlock_irq(>lock);
>
> @@ -225,8 +223,9 @@ static int freezer_read(struct cgroup *cgroup, struct
> cftype *cft,
> return 0;
> }
>
> -static void freeze_cgroup(struct cgroup *cgroup, struct freezer *freezer)
> +static void freeze_cgroup(struct freezer *freezer)
> {
> + struct cgroup *cgroup = freezer->css.cgroup;
> struct cgroup_iter it;
> struct task_struct *task;
>
> @@ -236,8 +235,9 @@ static void freeze_cgroup(struct cgroup *cgroup, struct
> freezer *freezer)
> cgroup_iter_end(cgroup, );
> }
>
> -static void unfreeze_cgroup(struct cgroup *cgroup, struct freezer *freezer)
> +static void unfreeze_cgroup(struct freezer *freezer)
> {
> + struct cgroup *cgroup = freezer->css.cgroup;
> struct cgroup_iter it;
> struct task_struct *task;
>
> @@ -247,11 +247,9 @@ static void unfreeze_cgroup(struct cgroup *cgroup,
> struct freezer *freezer)
> cgroup_iter_end(cgroup, );
> }
>
> -static void freezer_change_state(struct cgroup *cgroup,
> +static void freezer_change_state(struct freezer *freezer,
>enum freezer_state goal_state)
> {
> - struct freezer *freezer = cgroup_freezer(cgroup);
> -
> /* also synchronizes against task migration, see freezer_attach() */
> spin_lock_irq(>lock);
>
> @@ -260,13 +258,13 @@ static void freezer_change_state(struct cgroup *cgroup,
> if (freezer->state != CGROUP_THAWED)
> atomic_dec(_freezing_cnt);
> freezer->state = CGROUP_THAWED;
> - unfreeze_cgroup(cgroup, freezer);
> + unfreeze_cgroup(freezer);
> break;
> case CGROUP_FROZEN:
> if (freezer->state == CGROUP_THAWED)
> atomic_inc(_freezing_cnt);
> freezer->state = CGROUP_FREEZING;
> - freeze_cgroup(cgroup, freezer);
> + freeze_cgroup(freezer);
> break;
> default:
> BUG();
> @@ -275,8 +273,7 @@ static void freezer_change_state(struct cgroup *cgroup,
> spin_unlock_irq(>lock);
> }
>
> -static int freezer_write(struct cgroup *cgroup,
> - struct cftype *cft,
> +static int freezer_write(struct cgroup *cgroup, struct cftype *cft,
>const char *buffer)
> {
> enum freezer_state goal_state;
> @@ -288,7 +285,7 @@ static int freezer_write(struct cgroup *cgroup,
> else
> return -EINVAL;
>
> - freezer_change_state(cgroup, goal_state);
> + freezer_change_state(cgroup_freezer(cgroup), goal_state);
> return 0;
> }
>
[PATCH] tools: hv: Netlink source address validation allows DoS
The source code without this patch caused hypervkvpd to exit when it processed
a spoofed Netlink packet which has been sent from an untrusted local user.
Now Netlink messages with a non-zero nl_pid source address are ignored
and a warning is printed into the syslog.
Signed-off-by: Tomas Hozza
---
tools/hv/hv_kvp_daemon.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 13c2a14..c1d9102 100755
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -1486,13 +1486,19 @@ int main(void)
len = recvfrom(fd, kvp_recv_buffer, sizeof(kvp_recv_buffer), 0,
addr_p, _l);
- if (len < 0 || addr.nl_pid) {
+ if (len < 0) {
syslog(LOG_ERR, "recvfrom failed; pid:%u error:%d %s",
addr.nl_pid, errno, strerror(errno));
close(fd);
return -1;
}
+ if (addr.nl_pid) {
+ syslog(LOG_WARNING, "Received packet from untrusted
pid:%u",
+ addr.nl_pid);
+ continue;
+ }
+
incoming_msg = (struct nlmsghdr *)kvp_recv_buffer;
incoming_cn_msg = (struct cn_msg *)NLMSG_DATA(incoming_msg);
hv_msg = (struct hv_kvp_msg *)incoming_cn_msg->data;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] ARM: EXYNOS: PL330 MDMA1 fix for revision 0 of Exynos4210 SOC
On Thursday 08 November 2012 05:49:47 Kukjin Kim wrote:
> Bartlomiej Zolnierkiewicz wrote:
> >
> > > Hmm...above change and adding definition of EXYNOS_PA_S_MDMA1 address
> > > can fix the problem you commented on EXYNOS4210 Rev0 without others?...
> >
> > The problem is affecting only EXYNOS4210 Rev0 and the fix is applied only
> > for case when soc_is_exynos4210() && samsung_rev() == EXYNOS4210_REV_0,
> > or did you mean something else?
> >
> Yeah, I know. I mean just adding secure mdma1 address is enough for
> exynos4210 rev0.
>
> 8<-
> @@ -275,6 +275,9 @@ static int __init exynos_dma_init(void)
> exynos_pdma1_pdata.nr_valid_peri =
> ARRAY_SIZE(exynos4210_pdma1_peri);
> exynos_pdma1_pdata.peri_id = exynos4210_pdma1_peri;
> +
> + if (samsung_rev() == EXYNOS4210_REV_0)
> + exynos_mdma1_device.res.start = EXYNOS4_PA_S_MDMA1;
> } else if (soc_is_exynos4212() || soc_is_exynos4412()) {
> exynos_pdma0_pdata.nr_valid_peri =
> ARRAY_SIZE(exynos4212_pdma0_peri);
> diff --git a/arch/arm/mach-exynos/include/mach/map.h
> b/arch/arm/mach-exynos/include/mach/map.h
> index 8480849..0abfe78 100644
> --- a/arch/arm/mach-exynos/include/mach/map.h
> +++ b/arch/arm/mach-exynos/include/mach/map.h
> @@ -90,6 +90,7 @@
>
> #define EXYNOS4_PA_MDMA0 0x1081
> #define EXYNOS4_PA_MDMA1 0x1285
> +#define EXYNOS4_PA_S_MDMA1 0x1284
> #define EXYNOS4_PA_PDMA0 0x1268
> #define EXYNOS4_PA_PDMA1 0x1269
> #define EXYNOS5_PA_MDMA0 0x1080
> 8<
Ah, okay. Here is full simplified patch.
From: Bartlomiej Zolnierkiewicz
Subject: [PATCH v2] ARM: EXYNOS: PL330 MDMA1 fix for revision 0 of Exynos4210
SOC
Commit 8214513 ("ARM: EXYNOS: fix address for EXYNOS4 MDMA1")
changed EXYNOS specific setup of PL330 DMA engine to use 'non-secure'
mdma1 address instead of 'secure' one (from 0x1284 to 0x1285)
to fix issue with some Exynos4212 SOCs. Unfortunately it brakes
PL330 setup for revision 0 of Exynos4210 SOC (mdma1 device cannot
be found at 'non-secure' address):
[0.566245] dma-pl330 dma-pl330.2: PERIPH_ID 0x0, PCELL_ID 0x0 !
[0.566278] dma-pl330: probe of dma-pl330.2 failed with error -22
Fix it by using 'secure' mdma1 address on Exynos4210 revision 0 SOC.
Reviewed-by: Tomasz Figa
Cc: Kukjin Kim
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
arch/arm/mach-exynos/dma.c |3 +++
arch/arm/mach-exynos/include/mach/map.h |1 +
2 files changed, 4 insertions(+)
Index: b/arch/arm/mach-exynos/dma.c
===
--- a/arch/arm/mach-exynos/dma.c2012-11-07 18:20:36.561743865 +0100
+++ b/arch/arm/mach-exynos/dma.c2012-11-08 10:48:23.445067606 +0100
@@ -275,6 +275,9 @@ static int __init exynos_dma_init(void)
exynos_pdma1_pdata.nr_valid_peri =
ARRAY_SIZE(exynos4210_pdma1_peri);
exynos_pdma1_pdata.peri_id = exynos4210_pdma1_peri;
+
+ if (samsung_rev() == EXYNOS4210_REV_0)
+ exynos_mdma1_device.res.start = EXYNOS4_PA_S_MDMA1;
} else if (soc_is_exynos4212() || soc_is_exynos4412()) {
exynos_pdma0_pdata.nr_valid_peri =
ARRAY_SIZE(exynos4212_pdma0_peri);
Index: b/arch/arm/mach-exynos/include/mach/map.h
===
--- a/arch/arm/mach-exynos/include/mach/map.h 2012-11-07 18:20:44.801743862
+0100
+++ b/arch/arm/mach-exynos/include/mach/map.h 2012-11-08 10:48:40.597067605
+0100
@@ -92,6 +92,7 @@
#define EXYNOS4_PA_MDMA0 0x1081
#define EXYNOS4_PA_MDMA1 0x1285
+#define EXYNOS4_PA_S_MDMA1 0x1284
#define EXYNOS4_PA_PDMA0 0x1268
#define EXYNOS4_PA_PDMA1 0x1269
#define EXYNOS5_PA_MDMA0 0x1080
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] virtio_scsi: fix memory leak on full queue condition.
virtscsi_queuecommand was leaking memory when the virtio queue was full. Tested: Guest operates correctly even with very small queue sizes, validated we're not leaking kmalloc-192 sized allocations anymore. Signed-off-by: Eric Northup --- drivers/scsi/virtio_scsi.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c index 595af1a..dd8dc27 100644 --- a/drivers/scsi/virtio_scsi.c +++ b/drivers/scsi/virtio_scsi.c @@ -469,6 +469,8 @@ static int virtscsi_queuecommand(struct Scsi_Host *sh, struct scsi_cmnd *sc) sizeof cmd->req.cmd, sizeof cmd->resp.cmd, GFP_ATOMIC) >= 0) ret = 0; + else + mempool_free(cmd, virtscsi_cmd_pool); out: return ret; -- 1.7.7.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/9] cgroup_freezer: prepare freezer_change_state() for full hierarchy support
On Sat 03-11-12 01:38:31, Tejun Heo wrote:
> * Make freezer_change_state() take bool @freeze instead of enum
> freezer_state.
>
> * Separate out freezer_apply_state() out of freezer_change_state().
> This makes freezer_change_state() a rather silly thin wrapper. It
> will be filled with hierarchy handling later on.
>
> This patch doesn't introduce any behavior change.
>
> Signed-off-by: Tejun Heo
Makes sense
Reviewed-by: Michal Hocko
> ---
> kernel/cgroup_freezer.c | 48 ++--
> 1 file changed, 30 insertions(+), 18 deletions(-)
>
> diff --git a/kernel/cgroup_freezer.c b/kernel/cgroup_freezer.c
> index 975b3d8..2690830 100644
> --- a/kernel/cgroup_freezer.c
> +++ b/kernel/cgroup_freezer.c
> @@ -247,45 +247,57 @@ static void unfreeze_cgroup(struct freezer *freezer)
> cgroup_iter_end(cgroup, );
> }
>
> -static void freezer_change_state(struct freezer *freezer,
> - enum freezer_state goal_state)
> +/**
> + * freezer_apply_state - apply state change to a single cgroup_freezer
> + * @freezer: freezer to apply state change to
> + * @freeze: whether to freeze or unfreeze
> + */
> +static void freezer_apply_state(struct freezer *freezer, bool freeze)
> {
> /* also synchronizes against task migration, see freezer_attach() */
> - spin_lock_irq(>lock);
> + lockdep_assert_held(>lock);
>
> - switch (goal_state) {
> - case CGROUP_THAWED:
> - if (freezer->state != CGROUP_THAWED)
> - atomic_dec(_freezing_cnt);
> - freezer->state = CGROUP_THAWED;
> - unfreeze_cgroup(freezer);
> - break;
> - case CGROUP_FROZEN:
> + if (freeze) {
> if (freezer->state == CGROUP_THAWED)
> atomic_inc(_freezing_cnt);
> freezer->state = CGROUP_FREEZING;
> freeze_cgroup(freezer);
> - break;
> - default:
> - BUG();
> + } else {
> + if (freezer->state != CGROUP_THAWED)
> + atomic_dec(_freezing_cnt);
> + freezer->state = CGROUP_THAWED;
> + unfreeze_cgroup(freezer);
> }
> +}
>
> +/**
> + * freezer_change_state - change the freezing state of a cgroup_freezer
> + * @freezer: freezer of interest
> + * @freeze: whether to freeze or thaw
> + *
> + * Freeze or thaw @cgroup according to @freeze.
> + */
> +static void freezer_change_state(struct freezer *freezer, bool freeze)
> +{
> + /* update @freezer */
> + spin_lock_irq(>lock);
> + freezer_apply_state(freezer, freeze);
> spin_unlock_irq(>lock);
> }
>
> static int freezer_write(struct cgroup *cgroup, struct cftype *cft,
>const char *buffer)
> {
> - enum freezer_state goal_state;
> + bool freeze;
>
> if (strcmp(buffer, freezer_state_strs[CGROUP_THAWED]) == 0)
> - goal_state = CGROUP_THAWED;
> + freeze = false;
> else if (strcmp(buffer, freezer_state_strs[CGROUP_FROZEN]) == 0)
> - goal_state = CGROUP_FROZEN;
> + freeze = true;
> else
> return -EINVAL;
>
> - freezer_change_state(cgroup_freezer(cgroup), goal_state);
> + freezer_change_state(cgroup_freezer(cgroup), freeze);
> return 0;
> }
>
> --
> 1.7.11.7
>
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] Staging: winbond: wb35rx_s: Fixed coding style issue
On Thu, Nov 8, 2012 at 12:59 PM, Dan Carpenter wrote: > It's better to use more descriptive subjects on the patches. > > This one could probably have been broken into smaller patches > [patch 4/x] Staging: winbond: wb35rx_s: fix white space > [patch 5/x] Staging: winbond: wb35rx_s: fix comments > [patch 6/x] Staging: winbond: wb35rx_s: allow header to be included twice > > It's small enough that I don't have strong feelings about it, but > in general that's how you should do it. > Thanks Dan for your comment. I'll keep this in mind during my future work. Regards, Adil > 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] firmware loader: Fix the race FW_STATUS_DONE is followed by class_timeout
On Thu, Nov 8, 2012 at 7:14 PM, Chuansheng Liu wrote: > > There is a race as below when calling request_firmware(): > CPU1 CPU2 > write 0 > loading > mutex_lock(_lock) > ... > set_bit FW_STATUS_DONE class_timeout is coming >set_bit FW_STATUS_ABORT > complete_all > ... > mutex_unlock(_lock) > > In this time, the bit FW_STATUS_DONE and FW_STATUS_ABORT are set, > and request_firmware() will return failure due to condition in > _request_firmware_load(): > if (!buf->size || test_bit(FW_STATUS_ABORT, >status)) > retval = -ENOENT; > > But from the above scenerio, it should be a successful requesting. > So we need judge if the bit FW_STATUS_DONE is already set before > calling fw_load_abort() in timeout function. > > As Ming's proposal, we need change the timer into sched_work to > benefit from using _lock mutex also. > > Signed-off-by: liu chuansheng Acked-by: Ming Lei Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] DMA: add cpu_relax() to busy-loop in dma_sync_wait()
From: Bartlomiej Zolnierkiewicz
Subject: [PATCH] DMA: add cpu_relax() to busy-loop in dma_sync_wait()
Removal of the busy-loop from dma_sync_wait() is not a trivial
task so just add cpu_relax() to the loop for now.
Cc: Vinod Koul
Cc: Dan Williams
Cc: Tomasz Figa
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
drivers/dma/dmaengine.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: b/drivers/dma/dmaengine.c
===
--- a/drivers/dma/dmaengine.c 2012-11-07 16:12:41.776876102 +0100
+++ b/drivers/dma/dmaengine.c 2012-11-07 16:13:04.956876097 +0100
@@ -266,7 +266,10 @@ enum dma_status dma_sync_wait(struct dma
pr_err("%s: timeout!\n", __func__);
return DMA_ERROR;
}
- } while (status == DMA_IN_PROGRESS);
+ if (status != DMA_IN_PROGRESS)
+ break;
+ cpu_relax();
+ } while (1);
return status;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] async_tx: fix checking of dma_wait_for_async_tx() return value
From: Bartlomiej Zolnierkiewicz
Subject: [PATCH] async_tx: fix checking of dma_wait_for_async_tx() return value
dma_wait_for_async_tx() can also return DMA_PAUSED (which
should be considered as error).
Cc: Vinod Koul
Cc: Dan Williams
Cc: Tomasz Figa
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
crypto/async_tx/async_tx.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
Index: b/crypto/async_tx/async_tx.c
===
--- a/crypto/async_tx/async_tx.c2012-11-07 16:30:47.940875970 +0100
+++ b/crypto/async_tx/async_tx.c2012-11-07 16:31:34.75965 +0100
@@ -128,8 +128,8 @@ async_tx_channel_switch(struct dma_async
}
device->device_issue_pending(chan);
} else {
- if (dma_wait_for_async_tx(depend_tx) == DMA_ERROR)
- panic("%s: DMA_ERROR waiting for depend_tx\n",
+ if (dma_wait_for_async_tx(depend_tx) != DMA_SUCCESS)
+ panic("%s: DMA error waiting for depend_tx\n",
__func__);
tx->tx_submit(tx);
}
@@ -280,8 +280,9 @@ void async_tx_quiesce(struct dma_async_t
* we are referring to the correct operation
*/
BUG_ON(async_tx_test_ack(*tx));
- if (dma_wait_for_async_tx(*tx) == DMA_ERROR)
- panic("DMA_ERROR waiting for transaction\n");
+ if (dma_wait_for_async_tx(*tx) != DMA_SUCCESS)
+ panic("%s: DMA error waiting for transaction\n",
+ __func__);
async_tx_ack(*tx);
*tx = NULL;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] DMA: remove dma_async_memcpy_pending() macro
From: Bartlomiej Zolnierkiewicz
Subject: [PATCH 1/2] DMA: remove dma_async_memcpy_pending() macro
Just use dma_async_issue_pending() directly.
Cc: Vinod Koul
Cc: Dan Williams
Cc: Tomasz Figa
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
drivers/misc/carma/carma-fpga-program.c |2 +-
drivers/misc/carma/carma-fpga.c |2 +-
include/linux/dmaengine.h |2 --
net/ipv4/tcp.c |6 +++---
4 files changed, 5 insertions(+), 7 deletions(-)
Index: b/drivers/misc/carma/carma-fpga-program.c
===
--- a/drivers/misc/carma/carma-fpga-program.c 2012-11-07 16:00:59.680876184
+0100
+++ b/drivers/misc/carma/carma-fpga-program.c 2012-11-07 16:01:05.612876185
+0100
@@ -546,7 +546,7 @@ static noinline int fpga_program_dma(str
goto out_dma_unmap;
}
- dma_async_memcpy_issue_pending(chan);
+ dma_async_issue_pending(chan);
/* Set the total byte count */
fpga_set_byte_count(priv->regs, priv->bytes);
Index: b/drivers/misc/carma/carma-fpga.c
===
--- a/drivers/misc/carma/carma-fpga.c 2012-11-07 16:01:17.304876183 +0100
+++ b/drivers/misc/carma/carma-fpga.c 2012-11-07 16:01:23.568876183 +0100
@@ -749,7 +749,7 @@ static irqreturn_t data_irq(int irq, voi
submitted = true;
/* Start the DMA Engine */
- dma_async_memcpy_issue_pending(priv->chan);
+ dma_async_issue_pending(priv->chan);
out:
/* If no DMA was submitted, re-enable interrupts */
Index: b/include/linux/dmaengine.h
===
--- a/include/linux/dmaengine.h 2012-11-07 16:01:31.720876180 +0100
+++ b/include/linux/dmaengine.h 2012-11-07 16:01:45.072876180 +0100
@@ -902,8 +902,6 @@ static inline void dma_async_issue_pendi
chan->device->device_issue_pending(chan);
}
-#define dma_async_memcpy_issue_pending(chan) dma_async_issue_pending(chan)
-
/**
* dma_async_is_tx_complete - poll for transaction completion
* @chan: DMA channel
Index: b/net/ipv4/tcp.c
===
--- a/net/ipv4/tcp.c2012-11-07 16:01:52.496876179 +0100
+++ b/net/ipv4/tcp.c2012-11-07 16:02:13.924876175 +0100
@@ -1410,7 +1410,7 @@ static void tcp_service_net_dma(struct s
return;
last_issued = tp->ucopy.dma_cookie;
- dma_async_memcpy_issue_pending(tp->ucopy.dma_chan);
+ dma_async_issue_pending(tp->ucopy.dma_chan);
do {
if (dma_async_memcpy_complete(tp->ucopy.dma_chan,
@@ -1744,7 +1744,7 @@ int tcp_recvmsg(struct kiocb *iocb, stru
tcp_service_net_dma(sk, true);
tcp_cleanup_rbuf(sk, copied);
} else
-
dma_async_memcpy_issue_pending(tp->ucopy.dma_chan);
+ dma_async_issue_pending(tp->ucopy.dma_chan);
}
#endif
if (copied >= target) {
@@ -1837,7 +1837,7 @@ do_prequeue:
break;
}
-
dma_async_memcpy_issue_pending(tp->ucopy.dma_chan);
+ dma_async_issue_pending(tp->ucopy.dma_chan);
if ((offset + used) == skb->len)
copied_early = true;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] DMA: remove dma_async_memcpy_complete() macro
From: Bartlomiej Zolnierkiewicz
Subject: [PATCH 2/2] DMA: remove dma_async_memcpy_complete() macro
Just use dma_async_is_tx_complete() directly.
Cc: Vinod Koul
Cc: Dan Williams
Cc: Tomasz Figa
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
include/linux/dmaengine.h |5 +
net/ipv4/tcp.c|2 +-
2 files changed, 2 insertions(+), 5 deletions(-)
Index: b/include/linux/dmaengine.h
===
--- a/include/linux/dmaengine.h 2012-11-07 16:04:41.028876159 +0100
+++ b/include/linux/dmaengine.h 2012-11-07 16:05:22.004876153 +0100
@@ -927,16 +927,13 @@ static inline enum dma_status dma_async_
return status;
}
-#define dma_async_memcpy_complete(chan, cookie, last, used)\
- dma_async_is_tx_complete(chan, cookie, last, used)
-
/**
* dma_async_is_complete - test a cookie against chan state
* @cookie: transaction identifier to test status of
* @last_complete: last know completed transaction
* @last_used: last cookie value handed out
*
- * dma_async_is_complete() is used in dma_async_memcpy_complete()
+ * dma_async_is_complete() is used in dma_async_is_tx_complete()
* the test logic is separated for lightweight testing of multiple cookies
*/
static inline enum dma_status dma_async_is_complete(dma_cookie_t cookie,
Index: b/net/ipv4/tcp.c
===
--- a/net/ipv4/tcp.c2012-11-07 16:04:11.700876163 +0100
+++ b/net/ipv4/tcp.c2012-11-07 16:04:26.444876161 +0100
@@ -1413,7 +1413,7 @@ static void tcp_service_net_dma(struct s
dma_async_issue_pending(tp->ucopy.dma_chan);
do {
- if (dma_async_memcpy_complete(tp->ucopy.dma_chan,
+ if (dma_async_is_tx_complete(tp->ucopy.dma_chan,
last_issued, ,
) == DMA_SUCCESS) {
/* Safe to free early-copied skbs now */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] raid5: panic() on dma_wait_for_async_tx() error
From: Bartlomiej Zolnierkiewicz
Subject: [PATCH] raid5: panic() on dma_wait_for_async_tx() error
There is not much we can do on dma_wait_for_async_tx() error
so just panic() for now.
Cc: Neil Brown
Cc: Vinod Koul
Cc: Dan Williams
Cc: Tomasz Figa
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
drivers/md/raid5.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: b/drivers/md/raid5.c
===
--- a/drivers/md/raid5.c2012-11-07 16:25:19.480876012 +0100
+++ b/drivers/md/raid5.c2012-11-07 16:27:46.244875992 +0100
@@ -3223,7 +3223,9 @@ static void handle_stripe_expansion(stru
/* done submitting copies, wait for them to complete */
if (tx) {
async_tx_ack(tx);
- dma_wait_for_async_tx(tx);
+ if (dma_wait_for_async_tx(tx) != DMA_SUCCESS)
+ panic("%s: DMA error waiting for transaction\n",
+ __func__);
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] DMA: remove unused support for MEMSET operations
From: Bartlomiej Zolnierkiewicz Subject: [PATCH] DMA: remove unused support for MEMSET operations There have never been any real users of MEMSET operations since they have been introduced in January 2007 (commit 7405f74badf46b5d023c5d2b670b4471525f6c91 "dmaengine: refactor dmaengine around dma_async_tx_descriptor"). Therefore remove support for them for now, it can be always brought back when needed. Cc: Vinod Koul Cc: Dan Williams Cc: Tomasz Figa Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Kyungmin Park --- Documentation/crypto/async-tx-api.txt |1 arch/arm/mach-iop13xx/setup.c |3 - arch/arm/plat-iop/adma.c |2 arch/arm/plat-orion/common.c |5 - crypto/async_tx/Kconfig |4 - crypto/async_tx/Makefile |1 crypto/async_tx/async_memset.c| 88 --- drivers/dma/dmaengine.c |7 -- drivers/dma/ioat/dma.c|1 drivers/dma/ioat/dma_v3.c | 94 -- drivers/dma/iop-adma.c| 66 --- drivers/dma/mv_xor.c | 60 + drivers/dma/mv_xor.h |1 drivers/dma/ppc4xx/adma.c | 47 - include/linux/async_tx.h |4 - include/linux/dmaengine.h |5 - 16 files changed, 4 insertions(+), 385 deletions(-) Index: b/Documentation/crypto/async-tx-api.txt === --- a/Documentation/crypto/async-tx-api.txt 2012-11-07 15:00:06.208876620 +0100 +++ b/Documentation/crypto/async-tx-api.txt 2012-11-07 15:00:15.864876621 +0100 @@ -222,5 +222,4 @@ drivers/dma/: location for offload engin include/linux/async_tx.h: core header file for the async_tx api crypto/async_tx/async_tx.c: async_tx interface to dmaengine and common code crypto/async_tx/async_memcpy.c: copy offload -crypto/async_tx/async_memset.c: memory fill offload crypto/async_tx/async_xor.c: xor and xor zero sum offload Index: b/arch/arm/mach-iop13xx/setup.c === --- a/arch/arm/mach-iop13xx/setup.c 2012-11-07 15:15:11.000876512 +0100 +++ b/arch/arm/mach-iop13xx/setup.c 2012-11-07 15:15:21.068876510 +0100 @@ -469,7 +469,6 @@ void __init iop13xx_platform_init(void) dma_cap_set(DMA_MEMCPY, plat_data->cap_mask); dma_cap_set(DMA_XOR, plat_data->cap_mask); dma_cap_set(DMA_XOR_VAL, plat_data->cap_mask); - dma_cap_set(DMA_MEMSET, plat_data->cap_mask); dma_cap_set(DMA_INTERRUPT, plat_data->cap_mask); break; case IOP13XX_INIT_ADMA_1: @@ -479,7 +478,6 @@ void __init iop13xx_platform_init(void) dma_cap_set(DMA_MEMCPY, plat_data->cap_mask); dma_cap_set(DMA_XOR, plat_data->cap_mask); dma_cap_set(DMA_XOR_VAL, plat_data->cap_mask); - dma_cap_set(DMA_MEMSET, plat_data->cap_mask); dma_cap_set(DMA_INTERRUPT, plat_data->cap_mask); break; case IOP13XX_INIT_ADMA_2: @@ -489,7 +487,6 @@ void __init iop13xx_platform_init(void) dma_cap_set(DMA_MEMCPY, plat_data->cap_mask); dma_cap_set(DMA_XOR, plat_data->cap_mask); dma_cap_set(DMA_XOR_VAL, plat_data->cap_mask); - dma_cap_set(DMA_MEMSET, plat_data->cap_mask); dma_cap_set(DMA_INTERRUPT, plat_data->cap_mask); dma_cap_set(DMA_PQ, plat_data->cap_mask); dma_cap_set(DMA_PQ_VAL, plat_data->cap_mask); Index: b/arch/arm/plat-iop/adma.c === --- a/arch/arm/plat-iop/adma.c 2012-11-07 15:15:28.968876510 +0100 +++ b/arch/arm/plat-iop/adma.c 2012-11-07 15:15:44.540876510 +0100 @@ -192,12 +192,10 @@ static int __init iop3xx_adma_cap_init(v #ifdef CONFIG_ARCH_IOP32X /* the 32x AAU does not perform zero sum */ dma_cap_set(DMA_XOR, iop3xx_aau_data.cap_mask); - dma_cap_set(DMA_MEMSET, iop3xx_aau_data.cap_mask); dma_cap_set(DMA_INTERRUPT, iop3xx_aau_data.cap_mask); #else dma_cap_set(DMA_XOR, iop3xx_aau_data.cap_mask); dma_cap_set(DMA_XOR_VAL, iop3xx_aau_data.cap_mask); - dma_cap_set(DMA_MEMSET, iop3xx_aau_data.cap_mask); dma_cap_set(DMA_INTERRUPT, iop3xx_aau_data.cap_mask); #endif Index: b/arch/arm/plat-orion/common.c === --- a/arch/arm/plat-orion/common.c 2012-11-07 15:15:50.744876507 +0100 +++ b/arch/arm/plat-orion/common.c 2012-11-07 15:16:12.116876505 +0100 @@ -612,16 +612,11
[GIT PULL] s390 patches for the 3.7-rc5
Hi Linus,
please pull from the 'for-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
to receive a couple of bug fixes. I keep the fingers crossed that we now
got transparent huge pages ready for prime time.
Cornelia Huck (1):
s390: Move css limits from drivers/s390/cio/ to include/asm/.
Gerald Schaefer (2):
s390/mm: use pmd_large() instead of pmd_huge()
s390/thp: respect page protection in pmd_none() and pmd_present()
Heiko Carstens (1):
s390/sclp: fix addressing mode clobber
Sebastian Ott (2):
s390/cio: suppress 2nd path verification during resume
s390/cio: fix length calculation in idset.c
arch/s390/include/asm/cio.h |2 ++
arch/s390/include/asm/pgtable.h | 35 ++-
arch/s390/kernel/sclp.S |8 +++-
arch/s390/lib/uaccess_pt.c |2 +-
arch/s390/mm/gup.c |2 +-
drivers/s390/cio/css.h |3 ---
drivers/s390/cio/device.c |8 +---
drivers/s390/cio/idset.c|3 +--
8 files changed, 35 insertions(+), 28 deletions(-)
diff --git a/arch/s390/include/asm/cio.h b/arch/s390/include/asm/cio.h
index 55bde60..ad2b924 100644
--- a/arch/s390/include/asm/cio.h
+++ b/arch/s390/include/asm/cio.h
@@ -9,6 +9,8 @@
#define LPM_ANYPATH 0xff
#define __MAX_CSSID 0
+#define __MAX_SUBCHANNEL 65535
+#define __MAX_SSID 3
#include
diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
index dd647c9..2d3b7cb 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -506,12 +506,15 @@ static inline int pud_bad(pud_t pud)
static inline int pmd_present(pmd_t pmd)
{
- return (pmd_val(pmd) & _SEGMENT_ENTRY_ORIGIN) != 0UL;
+ unsigned long mask = _SEGMENT_ENTRY_INV | _SEGMENT_ENTRY_RO;
+ return (pmd_val(pmd) & mask) == _HPAGE_TYPE_NONE ||
+ !(pmd_val(pmd) & _SEGMENT_ENTRY_INV);
}
static inline int pmd_none(pmd_t pmd)
{
- return (pmd_val(pmd) & _SEGMENT_ENTRY_INV) != 0UL;
+ return (pmd_val(pmd) & _SEGMENT_ENTRY_INV) &&
+ !(pmd_val(pmd) & _SEGMENT_ENTRY_RO);
}
static inline int pmd_large(pmd_t pmd)
@@ -1223,6 +1226,11 @@ static inline void __pmd_idte(unsigned long address,
pmd_t *pmdp)
}
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+
+#define SEGMENT_NONE __pgprot(_HPAGE_TYPE_NONE)
+#define SEGMENT_RO __pgprot(_HPAGE_TYPE_RO)
+#define SEGMENT_RW __pgprot(_HPAGE_TYPE_RW)
+
#define __HAVE_ARCH_PGTABLE_DEPOSIT
extern void pgtable_trans_huge_deposit(struct mm_struct *mm, pgtable_t
pgtable);
@@ -1242,16 +1250,15 @@ static inline void set_pmd_at(struct mm_struct *mm,
unsigned long addr,
static inline unsigned long massage_pgprot_pmd(pgprot_t pgprot)
{
- unsigned long pgprot_pmd = 0;
-
- if (pgprot_val(pgprot) & _PAGE_INVALID) {
- if (pgprot_val(pgprot) & _PAGE_SWT)
- pgprot_pmd |= _HPAGE_TYPE_NONE;
- pgprot_pmd |= _SEGMENT_ENTRY_INV;
- }
- if (pgprot_val(pgprot) & _PAGE_RO)
- pgprot_pmd |= _SEGMENT_ENTRY_RO;
- return pgprot_pmd;
+ /*
+* pgprot is PAGE_NONE, PAGE_RO, or PAGE_RW (see __Pxxx / __Sxxx)
+* Convert to segment table entry format.
+*/
+ if (pgprot_val(pgprot) == pgprot_val(PAGE_NONE))
+ return pgprot_val(SEGMENT_NONE);
+ if (pgprot_val(pgprot) == pgprot_val(PAGE_RO))
+ return pgprot_val(SEGMENT_RO);
+ return pgprot_val(SEGMENT_RW);
}
static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
@@ -1269,7 +1276,9 @@ static inline pmd_t pmd_mkhuge(pmd_t pmd)
static inline pmd_t pmd_mkwrite(pmd_t pmd)
{
- pmd_val(pmd) &= ~_SEGMENT_ENTRY_RO;
+ /* Do not clobber _HPAGE_TYPE_NONE pages! */
+ if (!(pmd_val(pmd) & _SEGMENT_ENTRY_INV))
+ pmd_val(pmd) &= ~_SEGMENT_ENTRY_RO;
return pmd;
}
diff --git a/arch/s390/kernel/sclp.S b/arch/s390/kernel/sclp.S
index bf05389..b6506ee 100644
--- a/arch/s390/kernel/sclp.S
+++ b/arch/s390/kernel/sclp.S
@@ -44,6 +44,12 @@ _sclp_wait_int:
#endif
mvc .LoldpswS1-.LbaseS1(16,%r13),0(%r8)
mvc 0(16,%r8),0(%r9)
+#ifdef CONFIG_64BIT
+ epsw%r6,%r7 # set current addressing mode
+ nill%r6,0x1 # in new psw (31 or 64 bit mode)
+ nilh%r7,0x8000
+ stm %r6,%r7,0(%r8)
+#endif
lhi %r6,0x0200 # cr mask for ext int (cr0.54)
ltr %r2,%r2
jz .LsetctS1
@@ -87,7 +93,7 @@ _sclp_wait_int:
.long 0x0008, 0x8000+.LwaitS1 # PSW to handle ext int
#ifdef CONFIG_64BIT
.LextpswS1_64:
- .quad 0x00018000, .LwaitS1# PSW to handle ext int, 64 bit
+ .quad 0, .LwaitS1 # PSW to handle ext int, 64 bit
#endif
.LwaitpswS1:
.long 0x010a,
Re: [RFC] Second attempt at kernel secure boot support
Hi, The basis for any secure boot is a way to detect that the system has been tampered with or not. "Tamper Evidence". There are two main vectors for a system to be tampered with. Someone local to the machine and remote users who can access the machine across a network interface. (this includes the local user installing a program from a remote source) You have a fair chance of protecting via physical means (Locked rooms, Background checks on users etc.) of preventing a user with malicious intent to access the local machine. The first thing a computer does when switched on is run its first code instructions. Commonly referred to as the BIOS. It would therefore be a requirement to ensure that the BIOS cannot be tampered with via any other method apart from physically located at the machine. Once you have a base computer code that cannot be tampered with, you can trust it. >From that point on, you can use digital signatures to build the chain of trust. Normally digital signatures would examine the binary, ensure the signature matches, and then run the code contained in it. It is vital that the private key used to sign binaries cannot be found on the local machine, otherwise an malicious user could use it to sign malicious code, and therefore break the trust. The binary files therefore must be signed on a separate computer, that is trusted and protected from malicious users. There is one known use case where the normal digital signature checks will not work and this is the Hibernate file. The files were digitally checked when loaded into a previously running machine. The state of the machine was then saved to a file. The problem is how to check the hibernate file has not been tampered with in the interim. As explained above, we cannot store a private key on the local machine, so some other method for checking that the hibernate file has not been tampered with is required. I would suggest the fix for this problem is working out a way to check the signature of binary files, while in RAM, or even on a running machine. This is the format that the hibernate file is, it is basically a RAM image. When starting a hibernate image, the file would have to be scanned and digital signature checked that all the executable code in the hibernate image was sourced from correctly digitally signed binaries. In fact, this last point, if done correctly, could replace virus scanners. We would then have a system that rather than scan for viruses, it instead scans for "tampering". Remaining problems: 1) deciding who you trust, and from that, which digital signatures/certificates you trust. 2) Handling compromised or expired signatures/certificates. For 2, if the signatures are attached in each binary file, in order to distribute a new set of signatures, you would have to re-distribute all the binary files. Not a good idea due to download size. I would therefore suggest that the signatures are distributed separately from the binary files, so that you can change the signatures without having to redistribute all the binary files. Summary: 1) The BIOS code and the certificate it uses to check subsequently loaded binaries should only be changeable by a user local to the machine or not changeable at all without changing hardware. For example, on some ARM based mobile phones, the BIOS and certificate it uses are in a ROM, so not changeable at all. It then uses a multi stage boot loader, with each stage providing for a different certificate to be used to the next stage. This then permits the certificates that are used to sign the Linux kernel to be changed without having to change the certificate in the ROM. For Secure boot for Linux, the BIOS and certificate should probably be controlled by the user who controls the physical access to his machine. Then multi stage boot loaders can be used to introduce a chain to trust to trust other certificates, such as the debian or redhat or Microsoft ones, if the user chooses to trust them. With the user using their own BIOS certificate, it is very unlikely for the remote malicious user to obtain the private key and thus compromise the security of the system. 2) When "tamper" is detected, the system should revert to a stable safe state. This probably means, prevent the system booting, and present the local user with the evidence of tampering. Letting the user choose the next step. On 7 November 2012 14:55, Matthew Garrett wrote: > On Wed, Nov 07, 2012 at 09:19:35AM +0100, Olivier Galibert wrote: >> On Tue, Nov 6, 2012 at 11:47 PM, Matthew Garrett wrote: >> >> > Sure, and scripts run as root can wipe your files too. That's really not >> > what this is all about. >> >> What it is about then? What is secure boot supposed to do for the owner of >> the computer in a linux context? I've not been able to understand it >> through this discussion. > > It provides a chain of trust that allows you to ensure that a platform > boots a trusted kernel. That's a pre-requisite for implementing any kind > of
Re: [PATCH v2 2/2] therma: exynos: Supports thermal tripping
On 31 October 2012 12:17, Jonghwan Choi wrote:
> TMU urgently sends active-high signal (thermal trip) to PMU,
> and thermal tripping by hardware logic i.e PMU is performed.
> Thermal tripping means that PMU cut off the whole power of SoC
> by controlling external voltage regulator.
>
> Signed-off-by: Jonghwan Choi
> ---
> drivers/thermal/exynos_thermal.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/thermal/exynos_thermal.c
> b/drivers/thermal/exynos_thermal.c
> index 6ce6667..5672e95 100644
> --- a/drivers/thermal/exynos_thermal.c
> +++ b/drivers/thermal/exynos_thermal.c
> @@ -53,6 +53,7 @@
> #define EXYNOS_TMU_TRIM_TEMP_MASK 0xff
> #define EXYNOS_TMU_GAIN_SHIFT 8
> #define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24
> +#define EXYNOS_TMU_TRIP_EN BIT(12)
> #define EXYNOS_TMU_CORE_ON 1
> #define EXYNOS_TMU_CORE_OFF0
> #define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
> @@ -656,6 +657,9 @@ static void exynos_tmu_control(struct platform_device
> *pdev, bool on)
> if (data->soc == SOC_ARCH_EXYNOS) {
> con |= pdata->noise_cancel_mode <<
> EXYNOS_TMU_TRIP_MODE_SHIFT;
> con |= (EXYNOS_MUX_ADDR_VALUE << EXYNOS_MUX_ADDR_SHIFT);
> +
> + if (pdata->trigger_level3_en)
> + con |= EXYNOS_TMU_TRIP_EN;
Hi Jonghwan Choi,
IMO, Also you need to write 4th trigger level, Currently only 3
trigger levels are stored in register THD_TEMP_RISE.
Thanks,
Amit Daniel
> }
>
> if (on) {
> --
> 1.7.4.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] pwm: lpc32xx - Fix the PWM polarity
On Thu, 08 Nov 2012 10:51:35 +0100 Roland Stigge wrote: > On 07/11/12 16:25, Alban Bedel wrote: > > Signed-off-by: Alban Bedel > > --- > > drivers/pwm/pwm-lpc32xx.c |6 +- > > 1 files changed, 5 insertions(+), 1 deletions(-) > > > > diff --git a/drivers/pwm/pwm-lpc32xx.c b/drivers/pwm/pwm-lpc32xx.c > > index adb87f0..0dc278d 100644 > > --- a/drivers/pwm/pwm-lpc32xx.c > > +++ b/drivers/pwm/pwm-lpc32xx.c > > @@ -51,7 +51,11 @@ static int lpc32xx_pwm_config(struct pwm_chip *chip, > > struct pwm_device *pwm, > > > > c = 256 * duty_ns; > > do_div(c, period_ns); > > - duty_cycles = c; > > + if (c == 0) > > + c = 256; > > + if (c > 255) > > + c = 255; > > + duty_cycles = 256 - c; > > Except for the range check (for the original c > 255), this results in: > > duty_cycles = 256 - c > > except for (c == 0) where > > duty_cycles = 1 No it lead to duty_cycles = 0 > which actually is > > duty_cycles = (256 - c) - 255 > > (think with the original c) > > i.e. nearly a polarity inversion in the case of (c == 0). > > Why is the case (c == 0) so special here? Maybe you can document this, > if it is really intended? It is intended, the formular for duty value in the register is: duty = (256 - 256*duty_ns/period_ns) % 256 But the code avoid the modulo by clamping '256*duty_ns/period_ns' to 1-256. Perhaps something like: if (c > 255) c = 255; duty_cycles = (256 - c) % 256; would be easier to understand. Alban -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
+ Peter
Hi Stephen,
On 11/7/2012 6:25 PM, Stephen Warren wrote:
On 11/07/2012 03:19 AM, Benoit Cousson wrote:
Hi Panto,
On 11/07/2012 09:13 AM, Pantelis Antoniou wrote:
Hi Grant
On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
wrote:
[ snip ]
g.
Since we've started talking about longer term goals, and the versioning
provision seems to stand, I hope we address how much the fragment versioning
thing is similar to the way board revisions progress.
If a versioning syntax is available then one could create a single DT
file for a bunch of 'almost' similar board and board revisions.
I even think that the version issue is probably much more important for the
short term than the overlay aspect. Well at least as important. We start having
as well a bunch a panda board version with different HW setup.
Having a single board-XXX.dts that will support all these versions is probably
the best approach to avoid choosing that from the bootloader.
We need to figure out a format + mechanism compatible with the current
non-versioned format to allow filtering the nodes at runtime to keep only the
relevant one.
Something that can find the driver that will provide the proper board version
or subsystem version or whatever like that:
compatible-version = "ti,panda-version", "panda";
Then at runtime we should create only the node with the correct match between
the driver version and the string version.
/* regular panda audio routing */
sound: sound {
compatible = "ti,abe-twl6040";
ti,model = "PandaBoard";
compatible-version = "ti,panda-version", "panda";
/* Audio routing */
ti,audio-routing =
"Headset Stereophone", "HSOL",
"Headset Stereophone", "HSOR",
"Ext Spk", "HFL",
"Ext Spk", "HFR",
"Line Out", "AUXL",
"Line Out", "AUXR",
"HSMIC", "Headset Mic",
"Headset Mic", "Headset Mic Bias",
"AFML", "Line In",
"AFMR", "Line In";
};
/* Audio routing is different between PandaBoard4430 and PandaBoardES */
{
ti,model = "PandaBoardES";
compatible-version = "ti,panda-version", "panda-es";
/* Audio routing */
ti,audio-routing =
"Headset Stereophone", "HSOL",
"Headset Stereophone", "HSOR",
"Ext Spk", "HFL",
"Ext Spk", "HFR",
"Line Out", "AUXL",
"Line Out", "AUXR",
"AFML", "Line In",
"AFMR", "Line In";
};
Maybe some extra version match table can just be passed during the board
machine_init
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL,
panda_version_match_table);
Is the only difference here the content of the ti,audio-routing
property? If so, then I don't think there's any need for infra-structure
for this; the driver code already reads that property and adjusts its
behaviour based upon it.
That was just an example, and maybe not the best one. It could be any
kind of HW differences, like a different GPIO line, a different I2C
peripheral, an extra DCDC...
The point was just that you might have several version of the same node
with different attributes depending of the board revision.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: plat-versatile: move secondary CPU startup code out of .init for hotplug
Using __CPUINIT instead of __INIT puts the secondary CPU startup code into the "right" section: it will not be freed in hotplug configurations, allowing hot-add of cpus, while still getting freed in non-hotplug configs. Signed-off-by: Claudio Fontana --- arch/arm/plat-versatile/headsmp.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S index dd703ef..19fe180 100644 --- a/arch/arm/plat-versatile/headsmp.S +++ b/arch/arm/plat-versatile/headsmp.S @@ -11,7 +11,7 @@ #include #include - __INIT + __CPUINIT /* * Realview/Versatile Express specific entry point for secondary CPUs. -- 1.7.12.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 6/9] cgroup_freezer: make freezer->state mask of flags
On Sat 03-11-12 01:38:32, Tejun Heo wrote:
> freezer->state was an enum value - one of THAWED, FREEZING and FROZEN.
> As the scheduled full hierarchy support requires more than one
> freezing condition, switch it to mask of flags. If FREEZING is not
> set, it's thawed. FREEZING is set if freezing or frozen. If frozen,
> both FREEZING and FROZEN are set. Now that tasks can be attached to
> an already frozen cgroup, this also makes freezing condition checks
> more natural.
>
> This patch doesn't introduce any behavior change.
>
> Signed-off-by: Tejun Heo
I think it would be nicer to use freezer_state_flags enum rather than
unsigned int for the state. I would even expect gcc to complain about
that but it looks like -fstrict-enums is c++ specific (so long enum
safety).
Anyway
Reviewed-by: Michal Hocko
> ---
> kernel/cgroup_freezer.c | 60
> ++---
> 1 file changed, 27 insertions(+), 33 deletions(-)
>
> diff --git a/kernel/cgroup_freezer.c b/kernel/cgroup_freezer.c
> index 2690830..e76aa9f 100644
> --- a/kernel/cgroup_freezer.c
> +++ b/kernel/cgroup_freezer.c
> @@ -22,15 +22,14 @@
> #include
> #include
>
> -enum freezer_state {
> - CGROUP_THAWED = 0,
> - CGROUP_FREEZING,
> - CGROUP_FROZEN,
> +enum freezer_state_flags {
> + CGROUP_FREEZING = (1 << 1), /* this freezer is freezing */
> + CGROUP_FROZEN = (1 << 3), /* this and its descendants frozen
> */
> };
>
> struct freezer {
> struct cgroup_subsys_state css;
> - enum freezer_state state;
> + unsigned intstate;
> spinlock_t lock;
> };
>
> @@ -48,12 +47,10 @@ static inline struct freezer *task_freezer(struct
> task_struct *task)
>
> bool cgroup_freezing(struct task_struct *task)
> {
> - enum freezer_state state;
> bool ret;
>
> rcu_read_lock();
> - state = task_freezer(task)->state;
> - ret = state == CGROUP_FREEZING || state == CGROUP_FROZEN;
> + ret = task_freezer(task)->state & CGROUP_FREEZING;
> rcu_read_unlock();
>
> return ret;
> @@ -63,10 +60,13 @@ bool cgroup_freezing(struct task_struct *task)
> * cgroups_write_string() limits the size of freezer state strings to
> * CGROUP_LOCAL_BUFFER_SIZE
> */
> -static const char *freezer_state_strs[] = {
> - "THAWED",
> - "FREEZING",
> - "FROZEN",
> +static const char *freezer_state_strs(unsigned int state)
> +{
> + if (state & CGROUP_FROZEN)
> + return "FROZEN";
> + if (state & CGROUP_FREEZING)
> + return "FREEZING";
> + return "THAWED";
> };
>
> /*
> @@ -91,7 +91,6 @@ static struct cgroup_subsys_state *freezer_create(struct
> cgroup *cgroup)
> return ERR_PTR(-ENOMEM);
>
> spin_lock_init(>lock);
> - freezer->state = CGROUP_THAWED;
> return >css;
> }
>
> @@ -99,7 +98,7 @@ static void freezer_destroy(struct cgroup *cgroup)
> {
> struct freezer *freezer = cgroup_freezer(cgroup);
>
> - if (freezer->state != CGROUP_THAWED)
> + if (freezer->state & CGROUP_FREEZING)
> atomic_dec(_freezing_cnt);
> kfree(freezer);
> }
> @@ -129,15 +128,13 @@ static void freezer_attach(struct cgroup *new_cgrp,
> struct cgroup_taskset *tset)
>* Tasks in @tset are on @new_cgrp but may not conform to its
>* current state before executing the following - !frozen tasks may
>* be visible in a FROZEN cgroup and frozen tasks in a THAWED one.
> - * This means that, to determine whether to freeze, one should test
> - * whether the state equals THAWED.
>*/
> cgroup_taskset_for_each(task, new_cgrp, tset) {
> - if (freezer->state == CGROUP_THAWED) {
> + if (!(freezer->state & CGROUP_FREEZING)) {
> __thaw_task(task);
> } else {
> freeze_task(task);
> - freezer->state = CGROUP_FREEZING;
> + freezer->state &= ~CGROUP_FROZEN;
> }
> }
>
> @@ -159,11 +156,7 @@ static void freezer_fork(struct task_struct *task)
> goto out;
>
> spin_lock_irq(>lock);
> - /*
> - * @task might have been just migrated into a FROZEN cgroup. Test
> - * equality with THAWED. Read the comment in freezer_attach().
> - */
> - if (freezer->state != CGROUP_THAWED)
> + if (freezer->state & CGROUP_FREEZING)
> freeze_task(task);
> spin_unlock_irq(>lock);
> out:
> @@ -184,7 +177,8 @@ static void update_if_frozen(struct freezer *freezer)
> struct cgroup_iter it;
> struct task_struct *task;
>
> - if (freezer->state != CGROUP_FREEZING)
> + if (!(freezer->state & CGROUP_FREEZING) ||
> + (freezer->state & CGROUP_FROZEN))
> return;
>
> cgroup_iter_start(cgroup, );
> @@ -202,7 +196,7 @@ static void update_if_frozen(struct
Fix perf DSOs' map address if .text is not the first secion of vmlinux
>From 1bacfabf8369764126758bbbea1d3963ac778cce Mon Sep 17 00:00:00 2001
From: Lu Zhigang
Date: Thu, 8 Nov 2012 04:31:05 -0500
Subject: [PATCH 1/1] perf symbol: Don't assume .text section is the first
section of vmlinux
The start address derived from /proc/kallsyms in is the start address of
kernel, but not the start address of .text section of kernel. If the .text
section is not at the beginning of vmlinux, perf will mess up the sections'
address range, thus failing to resolve the kernel symbols.
Verified on TILE architecture whose kernel sections are as following.
Sections:
Idx Name Size VMA LMA File off Algn
0 .intrpt1 3fe8 fff7 0001 2**3
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .text 008485a0 fff70002 0002 0002 2**6
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .init.text00047e88 fff70087 0087 0087 2**3
...
Signed-off-by: Lu Zhigang
---
tools/perf/util/symbol-elf.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index db0cc92..7fc219b 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -645,6 +645,7 @@ int dso__load_sym(struct dso *dso, struct map *map,
Elf_Scn *sec, *sec_strndx;
Elf *elf;
int nr = 0;
+ u64 kernel_start = map->start;
dso->symtab_type = syms_ss->type;
@@ -746,6 +747,7 @@ int dso__load_sym(struct dso *dso, struct map *map,
goto new_symbol;
if (strcmp(section_name, ".text") == 0) {
+ map->start = kernel_start + shdr.sh_offset;
curr_map = map;
curr_dso = dso;
goto new_symbol;
@@ -759,7 +761,7 @@ int dso__load_sym(struct dso *dso, struct map *map,
u64 start = sym.st_value;
if (kmodule)
- start += map->start + shdr.sh_offset;
+ start += kernel_start + shdr.sh_offset;
curr_dso = dso__new(dso_name);
if (curr_dso == NULL)
--
1.7.10.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] smack: SMACK_MAGIC to include/uapi/linux/magic.h
On Tue, Nov 6, 2012 at 11:59 PM, Casey Schaufler wrote:
>
> On 11/6/2012 12:17 AM, Jarkko Sakkinen wrote:
> > SMACK_MAGIC moved to a proper place for easy user space access
> > (i.e. libsmack).
> >
> > Signed-off-by: Jarkko Sakkinen
> > ---
> > include/uapi/linux/magic.h |1 +
> > security/smack/smack.h |5 -
> > 2 files changed, 1 insertion(+), 5 deletions(-)
>
> Will security/smack/smack_lsm.c and security/smack/smackfs.c
> compile after this change?
Sorry I haven't replied earlier. Anyway, I made a sanity check.
I retried build from clean. Works. I also checked that vmlinux contains
SMACK symbols. It does.
>
> >
> > diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h
> > index e15192c..12735ad 100644
> > --- a/include/uapi/linux/magic.h
> > +++ b/include/uapi/linux/magic.h
> > @@ -11,6 +11,7 @@
> > #define DEBUGFS_MAGIC 0x64626720
> > #define SECURITYFS_MAGIC 0x73636673
> > #define SELINUX_MAGIC0xf97cff8c
> > +#define SMACK_MAGIC 0x43415d53 /* "SMAC" */
> > #define RAMFS_MAGIC 0x858458f6 /* some random number */
> > #define TMPFS_MAGIC 0x01021994
> > #define HUGETLBFS_MAGIC 0x958458f6 /* some random number */
> > diff --git a/security/smack/smack.h b/security/smack/smack.h
> > index 99b3612..8ad3095 100644
> > --- a/security/smack/smack.h
> > +++ b/security/smack/smack.h
> > @@ -149,11 +149,6 @@ struct smack_known {
> > #define SMACK_CIPSO_SOCKET 1
> >
> > /*
> > - * smackfs magic number
> > - */
> > -#define SMACK_MAGIC 0x43415d53 /* "SMAC" */
> > -
> > -/*
> > * CIPSO defaults.
> > */
> > #define SMACK_CIPSO_DOI_DEFAULT 3 /* Historical */
>
/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] virtio: Don't access index after unregister.
Virtio wants to release used indices after the corresponding
virtio device has been unregistered. However, virtio does not
hold an extra reference, giving up its last reference with
device_unregister(), making accessing dev->index afterwards
invalid.
I actually saw problems when testing my (not-yet-merged)
virtio-ccw code:
- device_add virtio-net,id=xxx
-> creates device virtio with n>0
- device_del xxx
-> deletes virtio, but calls ida_simple_remove with an
index of 0
- device_add virtio-net,id=xxx
-> tries to add virtio0, which is still in use...
So let's save the index we want to release before calling
device_unregister().
Signed-off-by: Cornelia Huck
---
drivers/virtio/virtio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index 1e8659c..809b0de 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -225,8 +225,10 @@ EXPORT_SYMBOL_GPL(register_virtio_device);
void unregister_virtio_device(struct virtio_device *dev)
{
+ int index = dev->index; /* save for after device release */
+
device_unregister(>dev);
- ida_simple_remove(_index_ida, dev->index);
+ ida_simple_remove(_index_ida, index);
}
EXPORT_SYMBOL_GPL(unregister_virtio_device);
--
1.7.12.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] pwm: lpc32xx - Fix the PWM polarity
On 08/11/12 11:33, Alban Bedel wrote: > On Thu, 08 Nov 2012 10:51:35 +0100 > Roland Stigge wrote: > >> On 07/11/12 16:25, Alban Bedel wrote: >>> Signed-off-by: Alban Bedel >>> --- >>> drivers/pwm/pwm-lpc32xx.c |6 +- >>> 1 files changed, 5 insertions(+), 1 deletions(-) >>> >>> diff --git a/drivers/pwm/pwm-lpc32xx.c b/drivers/pwm/pwm-lpc32xx.c >>> index adb87f0..0dc278d 100644 >>> --- a/drivers/pwm/pwm-lpc32xx.c >>> +++ b/drivers/pwm/pwm-lpc32xx.c >>> @@ -51,7 +51,11 @@ static int lpc32xx_pwm_config(struct pwm_chip *chip, >>> struct pwm_device *pwm, >>> >>> c = 256 * duty_ns; >>> do_div(c, period_ns); >>> - duty_cycles = c; >>> + if (c == 0) >>> + c = 256; >>> + if (c > 255) >>> + c = 255; >>> + duty_cycles = 256 - c; >> >> Except for the range check (for the original c > 255), this results in: >> >> duty_cycles = 256 - c >> >> except for (c == 0) where >> >> duty_cycles = 1 > > No it lead to duty_cycles = 0 Let's do it step by step with the above code: c == 0 >>> + if (c == 0) >>> + c = 256; c == 256 >>> + if (c > 255) >>> + c = 255; c == 255 >>> + duty_cycles = 256 - c; c == 1 See? > >> which actually is >> >> duty_cycles = (256 - c) - 255 >> >> (think with the original c) >> >> i.e. nearly a polarity inversion in the case of (c == 0). >> >> Why is the case (c == 0) so special here? Maybe you can document this, >> if it is really intended? > > It is intended, the formular for duty value in the register is: > > duty = (256 - 256*duty_ns/period_ns) % 256 Where does this modulo defined? In the Manual, there is sth. like this defined for RELOADV (tables 606+607), but not for DUTY. Maybe I missed sth. in the manual. Link or hint appreciated! Thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v4 0/7] acpi,memory-hotplug : implement framework for hot removing memory
The memory device can be removed by 2 ways: 1. send eject request by SCI 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject In the 1st case, acpi_memory_disable_device() will be called. In the 2nd case, acpi_memory_device_remove() will be called. acpi_memory_device_remove() will also be called when we unbind the memory device from the driver acpi_memhotplug or a driver initialization fails. acpi_memory_disable_device() has already implemented a code which offlines memory and releases acpi_memory_info struct . But acpi_memory_device_remove() has not implemented it yet. So the patch prepares the framework for hot removing memory and adds the framework into acpi_memory_device_remove(). The last version of this patchset is here: https://lkml.org/lkml/2012/10/26/175 Note: patch1-2 are in pm tree now. And there is a bug in patch1, so I resend them. The commit in pm tree is: patch1: 85fcb3758c10e063a2a30dfad75017097999deed patch2: d0fbb400b6f3a6191bdc5024f8733b2e2b86338f Changes from v3 to v4: 1. patch1: unlock list_lock when removing memory fails. 2. patch2: just rebase them 3. patch3-7: these patches are in -mm tree, and they conflict with this patchset, so Adrew Morton drop them from -mm tree. I rebase and merge them into this patchset. Wen Congyang (6): acpi,memory-hotplug: introduce a mutex lock to protect the list in acpi_memory_device acpi_memhotplug.c: fix memory leak when memory device is unbound from the module acpi_memhotplug acpi_memhotplug.c: free memory device if acpi_memory_enable_device() failed acpi_memhotplug.c: don't allow to eject the memory device if it is being used acpi_memhotplug.c: bind the memory device when the driver is being loaded acpi_memhotplug.c: auto bind the memory device which is hotplugged before the driver is loaded Yasuaki Ishimatsu (1): acpi,memory-hotplug : add memory offline code to acpi_memory_device_remove() drivers/acpi/acpi_memhotplug.c | 168 - 1 file changed, 133 insertions(+), 35 deletions(-) -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 2/7] acpi,memory-hotplug : add memory offline code to acpi_memory_device_remove()
From: Yasuaki Ishimatsu
The memory device can be removed by 2 ways:
1. send eject request by SCI
2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
In the 1st case, acpi_memory_disable_device() will be called.
In the 2nd case, acpi_memory_device_remove() will be called.
acpi_memory_device_remove() will also be called when we unbind the
memory device from the driver acpi_memhotplug or a driver initialization
fails.
acpi_memory_disable_device() has already implemented a code which
offlines memory and releases acpi_memory_info struct. But
acpi_memory_device_remove() has not implemented it yet.
So the patch move offlining memory and releasing acpi_memory_info struct
codes to a new function acpi_memory_remove_memory(). And it is used by both
acpi_memory_device_remove() and acpi_memory_disable_device().
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
CC: Rafael J. Wysocki
CC: Konrad Rzeszutek Wilk
Signed-off-by: Yasuaki Ishimatsu
Signed-off-by: Wen Congyang
---
The commit for pm tree is d0fbb400
drivers/acpi/acpi_memhotplug.c | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index 4c18ee3..e573e87 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -316,16 +316,11 @@ static int acpi_memory_powerdown_device(struct
acpi_memory_device *mem_device)
return 0;
}
-static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
+static int acpi_memory_remove_memory(struct acpi_memory_device *mem_device)
{
int result;
struct acpi_memory_info *info, *n;
-
- /*
-* Ask the VM to offline this memory range.
-* Note: Assume that this function returns zero on success
-*/
mutex_lock(_device->list_lock);
list_for_each_entry_safe(info, n, _device->res_list, list) {
if (info->enabled) {
@@ -335,10 +330,27 @@ static int acpi_memory_disable_device(struct
acpi_memory_device *mem_device)
return result;
}
}
+
+ list_del(>list);
kfree(info);
}
mutex_unlock(_device->list_lock);
+ return 0;
+}
+
+static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
+{
+ int result;
+
+ /*
+* Ask the VM to offline this memory range.
+* Note: Assume that this function returns zero on success
+*/
+ result = acpi_memory_remove_memory(mem_device);
+ if (result)
+ return result;
+
/* Power-off and eject the device */
result = acpi_memory_powerdown_device(mem_device);
if (result) {
@@ -489,12 +501,17 @@ static int acpi_memory_device_add(struct acpi_device
*device)
static int acpi_memory_device_remove(struct acpi_device *device, int type)
{
struct acpi_memory_device *mem_device = NULL;
-
+ int result;
if (!device || !acpi_driver_data(device))
return -EINVAL;
mem_device = acpi_driver_data(device);
+
+ result = acpi_memory_remove_memory(mem_device);
+ if (result)
+ return result;
+
kfree(mem_device);
return 0;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 3/7] acpi_memhotplug.c: fix memory leak when memory device is unbound from the module acpi_memhotplug
We allocate memory to store acpi_memory_info, so we should free it before
freeing mem_device.
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
CC: Yasuaki Ishimatsu
CC: Rafael J. Wysocki
CC: Konrad Rzeszutek Wilk
Signed-off-by: Wen Congyang
---
drivers/acpi/acpi_memhotplug.c | 31 +++
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index e573e87..5e5ac80 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -131,12 +131,22 @@ acpi_memory_get_resource(struct acpi_resource *resource,
void *context)
return AE_OK;
}
+static void
+acpi_memory_free_device_resources(struct acpi_memory_device *mem_device)
+{
+ struct acpi_memory_info *info, *n;
+
+ mutex_lock(_device->list_lock);
+ list_for_each_entry_safe(info, n, _device->res_list, list)
+ kfree(info);
+ INIT_LIST_HEAD(_device->res_list);
+ mutex_unlock(_device->list_lock);
+}
+
static int
acpi_memory_get_device_resources(struct acpi_memory_device *mem_device)
{
acpi_status status;
- struct acpi_memory_info *info, *n;
-
if (!list_empty(_device->res_list))
return 0;
@@ -144,11 +154,7 @@ acpi_memory_get_device_resources(struct acpi_memory_device
*mem_device)
status = acpi_walk_resources(mem_device->device->handle,
METHOD_NAME__CRS,
acpi_memory_get_resource, mem_device);
if (ACPI_FAILURE(status)) {
- mutex_lock(_device->list_lock);
- list_for_each_entry_safe(info, n, _device->res_list, list)
- kfree(info);
- INIT_LIST_HEAD(_device->res_list);
- mutex_unlock(_device->list_lock);
+ acpi_memory_free_device_resources(mem_device);
return -EINVAL;
}
@@ -447,6 +453,15 @@ static void acpi_memory_device_notify(acpi_handle handle,
u32 event, void *data)
return;
}
+static void acpi_memory_device_free(struct acpi_memory_device *mem_device)
+{
+ if (!mem_device)
+ return;
+
+ acpi_memory_free_device_resources(mem_device);
+ kfree(mem_device);
+}
+
static int acpi_memory_device_add(struct acpi_device *device)
{
int result;
@@ -512,7 +527,7 @@ static int acpi_memory_device_remove(struct acpi_device
*device, int type)
if (result)
return result;
- kfree(mem_device);
+ acpi_memory_device_free(mem_device);
return 0;
}
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 1/7] acpi,memory-hotplug: introduce a mutex lock to protect the list in acpi_memory_device
The memory device can be removed by 2 ways:
1. send eject request by SCI
2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
This 2 events may happen at the same time, so we may touch
acpi_memory_device.res_list at the same time. This patch
introduce a lock to protect this list.
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
CC: Yasuaki Ishimatsu
CC: Rafael J. Wysocki
CC: Konrad Rzeszutek Wilk
Signed-off-by: Wen Congyang
---
The commit in pm tree is 85fcb375
drivers/acpi/acpi_memhotplug.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index 1e90e8f..4c18ee3 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -83,7 +83,8 @@ struct acpi_memory_info {
struct acpi_memory_device {
struct acpi_device * device;
unsigned int state; /* State of the memory device */
- struct list_head res_list;
+ struct mutex list_lock;
+ struct list_head res_list; /* protected by list_lock */
};
static int acpi_hotmem_initialized;
@@ -101,19 +102,23 @@ acpi_memory_get_resource(struct acpi_resource *resource,
void *context)
(address64.resource_type != ACPI_MEMORY_RANGE))
return AE_OK;
+ mutex_lock(_device->list_lock);
list_for_each_entry(info, _device->res_list, list) {
/* Can we combine the resource range information? */
if ((info->caching == address64.info.mem.caching) &&
(info->write_protect == address64.info.mem.write_protect) &&
(info->start_addr + info->length == address64.minimum)) {
info->length += address64.address_length;
+ mutex_unlock(_device->list_lock);
return AE_OK;
}
}
new = kzalloc(sizeof(struct acpi_memory_info), GFP_KERNEL);
- if (!new)
+ if (!new) {
+ mutex_unlock(_device->list_lock);
return AE_ERROR;
+ }
INIT_LIST_HEAD(>list);
new->caching = address64.info.mem.caching;
@@ -121,6 +126,7 @@ acpi_memory_get_resource(struct acpi_resource *resource,
void *context)
new->start_addr = address64.minimum;
new->length = address64.address_length;
list_add_tail(>list, _device->res_list);
+ mutex_unlock(_device->list_lock);
return AE_OK;
}
@@ -138,9 +144,11 @@ acpi_memory_get_device_resources(struct acpi_memory_device
*mem_device)
status = acpi_walk_resources(mem_device->device->handle,
METHOD_NAME__CRS,
acpi_memory_get_resource, mem_device);
if (ACPI_FAILURE(status)) {
+ mutex_lock(_device->list_lock);
list_for_each_entry_safe(info, n, _device->res_list, list)
kfree(info);
INIT_LIST_HEAD(_device->res_list);
+ mutex_unlock(_device->list_lock);
return -EINVAL;
}
@@ -236,6 +244,7 @@ static int acpi_memory_enable_device(struct
acpi_memory_device *mem_device)
* We don't have memory-hot-add rollback function,now.
* (i.e. memory-hot-remove function)
*/
+ mutex_lock(_device->list_lock);
list_for_each_entry(info, _device->res_list, list) {
if (info->enabled) { /* just sanity check...*/
num_enabled++;
@@ -256,6 +265,7 @@ static int acpi_memory_enable_device(struct
acpi_memory_device *mem_device)
info->enabled = 1;
num_enabled++;
}
+ mutex_unlock(_device->list_lock);
if (!num_enabled) {
printk(KERN_ERR PREFIX "add_memory failed\n");
mem_device->state = MEMORY_INVALID_STATE;
@@ -316,14 +326,18 @@ static int acpi_memory_disable_device(struct
acpi_memory_device *mem_device)
* Ask the VM to offline this memory range.
* Note: Assume that this function returns zero on success
*/
+ mutex_lock(_device->list_lock);
list_for_each_entry_safe(info, n, _device->res_list, list) {
if (info->enabled) {
result = remove_memory(info->start_addr, info->length);
- if (result)
+ if (result) {
+ mutex_unlock(_device->list_lock);
return result;
+ }
}
kfree(info);
}
+ mutex_unlock(_device->list_lock);
/* Power-off and eject the device */
result = acpi_memory_powerdown_device(mem_device);
@@ -438,6 +452,7 @@ static int acpi_memory_device_add(struct acpi_device
*device)
mem_device->device = device;
[Patch v4 6/7] acpi_memhotplug.c: bind the memory device when the driver is being loaded
We had introduced acpi_hotmem_initialized to avoid strange add_memory fail
message. But the memory device may not be used by the kernel, and the
device should be bound when the driver is being loaded. Remove
acpi_hotmem_initialized to allow that the device can be bound when the
driver is being loaded.
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
CC: Yasuaki Ishimatsu
CC: Rafael J. Wysocki
CC: Konrad Rzeszutek Wilk
Signed-off-by: Wen Congyang
---
drivers/acpi/acpi_memhotplug.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index 1fb1342..8a8716f 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -88,8 +88,6 @@ struct acpi_memory_device {
struct list_head res_list; /* protected by list_lock */
};
-static int acpi_hotmem_initialized;
-
static acpi_status
acpi_memory_get_resource(struct acpi_resource *resource, void *context)
{
@@ -520,15 +518,6 @@ static int acpi_memory_device_add(struct acpi_device
*device)
printk(KERN_DEBUG "%s \n", acpi_device_name(device));
- /*
-* Early boot code has recognized memory area by EFI/E820.
-* If DSDT shows these memory devices on boot, hotplug is not necessary
-* for them. So, it just returns until completion of this driver's
-* start up.
-*/
- if (!acpi_hotmem_initialized)
- return 0;
-
if (!acpi_memory_check_device(mem_device)) {
/* call add_memory func */
result = acpi_memory_enable_device(mem_device);
@@ -644,7 +633,6 @@ static int __init acpi_memory_device_init(void)
return -ENODEV;
}
- acpi_hotmem_initialized = 1;
return 0;
}
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 4/7] acpi_memhotplug.c: free memory device if acpi_memory_enable_device() failed
If acpi_memory_enable_device() fails, acpi_memory_enable_device() will
return a non-zero value, which means we fail to bind the memory device to
this driver. So we should free memory device before
acpi_memory_device_add() returns.
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
CC: Yasuaki Ishimatsu
CC: Rafael J. Wysocki
CC: Konrad Rzeszutek Wilk
Signed-off-by: Wen Congyang
---
drivers/acpi/acpi_memhotplug.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index 5e5ac80..8914399 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -506,9 +506,11 @@ static int acpi_memory_device_add(struct acpi_device
*device)
if (!acpi_memory_check_device(mem_device)) {
/* call add_memory func */
result = acpi_memory_enable_device(mem_device);
- if (result)
+ if (result) {
printk(KERN_ERR PREFIX
"Error in acpi_memory_enable_device\n");
+ acpi_memory_device_free(mem_device);
+ }
}
return result;
}
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 5/7] acpi_memhotplug.c: don't allow to eject the memory device if it is being used
We eject the memory device even if it is in use. It is very dangerous,
and it will cause the kernel to be panicked.
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
CC: Yasuaki Ishimatsu
CC: Rafael J. Wysocki
CC: Konrad Rzeszutek Wilk
Signed-off-by: Wen Congyang
---
drivers/acpi/acpi_memhotplug.c | 46 +-
1 file changed, 36 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index 8914399..1fb1342 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -78,6 +78,7 @@ struct acpi_memory_info {
unsigned short caching; /* memory cache attribute */
unsigned short write_protect; /* memory read/write attribute */
unsigned int enabled:1;
+ unsigned int failed:1;
};
struct acpi_memory_device {
@@ -266,9 +267,23 @@ static int acpi_memory_enable_device(struct
acpi_memory_device *mem_device)
node = memory_add_physaddr_to_nid(info->start_addr);
result = add_memory(node, info->start_addr, info->length);
- if (result)
+
+ /*
+* If the memory block has been used by the kernel, add_memory()
+* returns -EEXIST. If add_memory() returns the other error, it
+* means that this memory block is not used by the kernel.
+*/
+ if (result && result != -EEXIST) {
+ info->failed = 1;
continue;
- info->enabled = 1;
+ }
+
+ if (!result)
+ info->enabled = 1;
+ /*
+* Add num_enable even if add_memory() returns -EEXIST, so the
+* device is bound to this driver.
+*/
num_enabled++;
}
mutex_unlock(_device->list_lock);
@@ -324,25 +339,36 @@ static int acpi_memory_powerdown_device(struct
acpi_memory_device *mem_device)
static int acpi_memory_remove_memory(struct acpi_memory_device *mem_device)
{
- int result;
+ int result = 0;
struct acpi_memory_info *info, *n;
mutex_lock(_device->list_lock);
list_for_each_entry_safe(info, n, _device->res_list, list) {
- if (info->enabled) {
- result = remove_memory(info->start_addr, info->length);
- if (result) {
- mutex_unlock(_device->list_lock);
- return result;
- }
+ if (info->failed)
+ /* The kernel does not use this memory block */
+ continue;
+
+ if (!info->enabled) {
+ /*
+* The kernel uses this memory block, but it may be not
+* managed by us.
+*/
+ result = -EBUSY;
+ goto out;
}
+ result = remove_memory(info->start_addr, info->length);
+ if (result)
+ goto out;
+
list_del(>list);
kfree(info);
}
+
+out:
mutex_unlock(_device->list_lock);
- return 0;
+ return result;
}
static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 7/7] acpi_memhotplug.c: auto bind the memory device which is hotplugged before the driver is loaded
If the memory device is hotplugged before the driver is loaded, the user
cannot see this device under the directory /sys/bus/acpi/devices/, and the
user cannot bind it by hand after the driver is loaded. This patch
introduces a new feature to bind such device when the driver is being
loaded.
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
CC: Yasuaki Ishimatsu
CC: Rafael J. Wysocki
CC: Konrad Rzeszutek Wilk
Signed-off-by: Wen Congyang
---
drivers/acpi/acpi_memhotplug.c | 37 -
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index 8a8716f..24bfa6e 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -52,6 +52,9 @@ MODULE_LICENSE("GPL");
#define MEMORY_POWER_ON_STATE 1
#define MEMORY_POWER_OFF_STATE 2
+static bool auto_probe;
+module_param(auto_probe, bool, S_IRUGO | S_IWUSR);
+
static int acpi_memory_device_add(struct acpi_device *device);
static int acpi_memory_device_remove(struct acpi_device *device, int type);
@@ -581,12 +584,44 @@ acpi_memory_register_notify_handler(acpi_handle handle,
u32 level, void *ctxt, void **retv)
{
acpi_status status;
-
+ struct acpi_memory_device *mem_device = NULL;
+ unsigned long long current_status;
status = is_memory_device(handle);
if (ACPI_FAILURE(status))
return AE_OK; /* continue */
+ if (auto_probe) {
+ /* Get device present/absent information from the _STA */
+ status = acpi_evaluate_integer(handle, "_STA", NULL,
+ _status);
+ if (ACPI_FAILURE(status))
+ goto install;
+
+ /*
+* Check for device status. Device should be
+* present/enabled/functioning.
+*/
+ if (!(current_status &
+ (ACPI_STA_DEVICE_PRESENT | ACPI_STA_DEVICE_ENABLED |
+ ACPI_STA_DEVICE_FUNCTIONING)))
+ goto install;
+
+ if (acpi_memory_get_device(handle, _device))
+ goto install;
+
+ /* We have bound this device while we register the driver */
+ if (mem_device->state == MEMORY_POWER_ON_STATE)
+ goto install;
+
+ ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+ "\nauto probe memory device\n"));
+
+ if (acpi_memory_enable_device(mem_device))
+ pr_err(PREFIX "Cannot enable memory device\n");
+ }
+
+install:
status = acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
acpi_memory_device_notify, NULL);
/* continue */
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 19/29] memcg: infrastructure to match an allocation to the right cache
On Tue 06-11-12 09:03:54, Michal Hocko wrote: > On Mon 05-11-12 16:28:37, Andrew Morton wrote: > > On Thu, 1 Nov 2012 16:07:35 +0400 > > Glauber Costa wrote: > > > > > +static __always_inline struct kmem_cache * > > > +memcg_kmem_get_cache(struct kmem_cache *cachep, gfp_t gfp) > > > > I still don't understand why this code uses __always_inline so much. > > AFAIU, __always_inline (resp. __attribute__((always_inline))) is the > same thing as inline if optimizations are enabled > (http://ohse.de/uwe/articles/gcc-attributes.html#func-always_inline). And this doesn't tell the whole story because there is -fearly-inlining which enabled by default and it makes a difference when optimizations are enabled so __always_inline really enforces inlining. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] DMA: remove unused support for MEMSET operations
On Thu, 08 Nov 2012 10:58:17 +0100 Bartlomiej Zolnierkiewicz wrote: > From: Bartlomiej Zolnierkiewicz > Subject: [PATCH] DMA: remove unused support for MEMSET operations > > There have never been any real users of MEMSET operations In tree users. And is it broken, if not why do you want to break it ? Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] raid5: panic() on dma_wait_for_async_tx() error
On Thu, 08 Nov 2012 11:06:29 +0100
Bartlomiej Zolnierkiewicz wrote:
> From: Bartlomiej Zolnierkiewicz
> Subject: [PATCH] raid5: panic() on dma_wait_for_async_tx() error
>
> There is not much we can do on dma_wait_for_async_tx() error
> so just panic() for now.
>
> Cc: Neil Brown
> Cc: Vinod Koul
> Cc: Dan Williams
> Cc: Tomasz Figa
> Signed-off-by: Bartlomiej Zolnierkiewicz
> Signed-off-by: Kyungmin Park
> ---
> drivers/md/raid5.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> Index: b/drivers/md/raid5.c
> ===
> --- a/drivers/md/raid5.c 2012-11-07 16:25:19.480876012 +0100
> +++ b/drivers/md/raid5.c 2012-11-07 16:27:46.244875992 +0100
> @@ -3223,7 +3223,9 @@ static void handle_stripe_expansion(stru
> /* done submitting copies, wait for them to complete */
> if (tx) {
> async_tx_ack(tx);
> - dma_wait_for_async_tx(tx);
> + if (dma_wait_for_async_tx(tx) != DMA_SUCCESS)
> + panic("%s: DMA error waiting for transaction\n",
> + __func__);
Thats a really horrible place to panic.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Second attempt at kernel secure boot support
> You have a fair chance of protecting via physical means (Locked rooms, > Background checks on users etc.) of preventing a user with malicious intent > to access the local machine. So called "secure boot" doesn't deal with any kind of physical access, which also means its useless if a device is lost and returned and you don't know if it was in the hands of a third party. > The first thing a computer does when switched on is run its first code > instructions. Commonly referred to as the BIOS. A good deal more complicated than that. However the signing in hardware and early boot up on a lot of devices already goes as far as the BIOS if the system has BIOS or EFI if it doesn't. You also have all the devices to deal with. > Normally digital signatures would examine the binary, ensure the signature > matches, and then run the code contained in it. No - it's a good deal more complicated than that too. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SR-IOV problem with Intel 82599EB (not enough MMIO resources for SR-IOV)
Hello, I installed kvm and tried to use SR-IOV virtualizaton for 82599EB(Intel XT-520 T2) dual port card with latest ixgbe driver(version:3.11.33) , kernel2.6.32-279.14.1(OS:Centos6.3) ,after configuration and reboot It seems that only first port of the card's VFs works,second port of the card's VFs didn't work I found some errors in /var/log messages: Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: not enough MMIO resources for SR-IOV Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: (unregistered net_device): Failed to enable PCI sriov: -12 How to fix it,any help would be greatly appreciated. below is the related information: Server: R710 OS: centos6.3 NIC: X520-T2(dual port) kernel: 2.6.32-279.14.1.el6.x86_64 BIOSVersion: 6.3.0(latest) BIOS:Inter VT/VT-d or SR-IOV(enabled) ixgbe:3.11.33(latest) ixgbevf:2.7.12(latest) grub config:intel_iommu=on appended /var/log/messages: Nov 8 14:56:54 12 kernel: Intel(R) 10 Gigabit PCI Express Network Driver - version 3.11.33 Nov 8 14:56:54 12 kernel: Copyright (c) 1999-2012 Intel Corporation. Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: PCI INT B -> GSI 50 (level, low) -> IRQ 50 Nov 8 14:56:54 12 kernel: ixgbe: I/O Virtualization (IOV) set to 2 Nov 8 14:56:54 12 kernel: ixgbe: :07:00.0: ixgbe_check_options: FCoE Offload feature enabled Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: (unregistered net_device): SR-IOV enabled with 2 VFs Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: FCoE offload feature is not available. Disabling FCoE offload feature Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: (PCI Express:5.0GT/s:Width x8) 68:05:ca:0c:7a:e2 Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: eth4: MAC: 2, PHY: 2, PBA No: G21371-003 Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: eth4: Enabled Features: RxQ: 1 TxQ: 1 LRO Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: eth4: IOV: VF 0 is enabled mac 0E:15:B9:26:B3:7D Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: eth4: IOV: VF 1 is enabled mac 32:69:2D:16:B9:40 Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: eth4: Intel(R) 10 Gigabit Network Connection Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: PCI INT A -> GSI 40 (level, low) -> IRQ 40 Nov 8 14:56:54 12 kernel: ixgbe: I/O Virtualization (IOV) set to 2 Nov 8 14:56:54 12 kernel: ixgbe: :07:00.1: ixgbe_check_options: FCoE Offload feature enabled Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: not enough MMIO resources for SR-IOV Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: (unregistered net_device): Failed to enable PCI sriov: -12 Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: FCoE offload feature is not available. Disabling FCoE offload feature Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: (PCI Express:5.0GT/s:Width x8) 68:05:ca:0c:7a:e3 Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: eth5: MAC: 2, PHY: 2, PBA No: G21371-003 Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: eth5: Enabled Features: RxQ: 16 TxQ: 16 FdirHash RSC Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: eth5: Intel(R) 10 Gigabit Network Connection # dmesg |grep -E 'DMA|IOMMU' ACPI: DMAR bf3b3668 001C0 (v01 DELL PE_SC3 0001 DELL 0001) DMA 0x0001 -> 0x1000 DMA320x1000 -> 0x0010 DMA zone: 56 pages used for memmap DMA zone: 102 pages reserved DMA zone: 3839 pages, LIFO batch:0 DMA32 zone: 14280 pages used for memmap DMA32 zone: 764849 pages, LIFO batch:31 Intel-IOMMU: enabled DMAR: Host address width 40 DMAR: DRHD base: 0x00fed9 flags: 0x1 IOMMU fed9: ver 1:0 cap c90780106f0462 ecap f020fe DMAR: RMRR base: 0x00bf4c8000 end: 0x00bf4d DMAR: RMRR base: 0x00bf4b1000 end: 0x00bf4b DMAR: RMRR base: 0x00bf4a1000 end: 0x00bf4a1fff DMAR: RMRR base: 0x00bf4a3000 end: 0x00bf4a3fff DMAR: RMRR base: 0x00bf4a5000 end: 0x00bf4a5fff DMAR: RMRR base: 0x00bf4a7000 end: 0x00bf4a7fff DMAR: RMRR base: 0x00bf4c end: 0x00bf4c0fff DMAR: RMRR base: 0x00bf4c2000 end: 0x00bf4c2fff DMAR: ATSR flags: 0x0 DMAR: Device scope device [:00:1a.02] not found DMAR: Device scope device [:00:1a.02] not found DMAR: Device scope device [:00:1d.02] not found DMAR: Device scope device [:00:1d.02] not found IOMMU 0xfed9: using Queued invalidation IOMMU: Setting RMRR: IOMMU: Setting identity map for device :00:1d.7 [0xbf4c2000 - 0xbf4c3000] IOMMU: Setting identity map for device :00:1a.7 [0xbf4c - 0xbf4c1000] IOMMU: Setting identity map for device :00:1d.1 [0xbf4a7000 - 0xbf4a8000] IOMMU: Setting identity map for device :00:1d.0 [0xbf4a5000 - 0xbf4a6000] IOMMU: Setting identity map for device :00:1a.1 [0xbf4a3000 - 0xbf4a4000] IOMMU: Setting identity map for device :00:1a.0 [0xbf4a1000 - 0xbf4a2000] IOMMU: Setting identity map for device :00:1a.0 [0xbf4b1000 - 0xbf4c] IOMMU: Setting identity map for device :00:1a.1 [0xbf4b1000 - 0xbf4c] IOMMU: Setting identity map for device :00:1d.0 [0xbf4b1000
Re: SR-IOV problem with Intel 82599EB (not enough MMIO resources for SR-IOV)
On 11/08/2012 03:15 AM, pkill.2012 wrote: > Hello, > > I installed kvm and tried to use SR-IOV virtualizaton for 82599EB(Intel > XT-520 T2) dual port card with latest ixgbe driver(version:3.11.33) , > kernel2.6.32-279.14.1(OS:Centos6.3) ,after configuration and reboot > It seems that only first port of the card's VFs works,second port of the > card's VFs didn't work > I found some errors in /var/log messages: > > Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: not enough MMIO resources for > SR-IOV > Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: (unregistered net_device): > Failed to enable PCI sriov: -12 > > How to fix it,any help would be greatly appreciated. > > below is the related information: > Server: R710 > OS: centos6.3 > NIC: X520-T2(dual port) > kernel: 2.6.32-279.14.1.el6.x86_64 > BIOSVersion: 6.3.0(latest) > BIOS:Inter VT/VT-d or SR-IOV(enabled) > ixgbe:3.11.33(latest) > ixgbevf:2.7.12(latest) > grub config:intel_iommu=on appended > > /var/log/messages: > Nov 8 14:56:54 12 kernel: Intel(R) 10 Gigabit PCI Express Network Driver - > version 3.11.33 > Nov 8 14:56:54 12 kernel: Copyright (c) 1999-2012 Intel Corporation. > Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: PCI INT B -> GSI 50 (level, > low) -> IRQ 50 > Nov 8 14:56:54 12 kernel: ixgbe: I/O Virtualization (IOV) set to 2 > Nov 8 14:56:54 12 kernel: ixgbe: :07:00.0: ixgbe_check_options: FCoE > Offload feature enabled > Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: (unregistered net_device): > SR-IOV enabled with 2 VFs > Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: FCoE offload feature is not > available. Disabling FCoE offload feature > Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: (PCI Express:5.0GT/s:Width x8) > 68:05:ca:0c:7a:e2 > Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: eth4: MAC: 2, PHY: 2, PBA No: > G21371-003 > Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: eth4: Enabled Features: RxQ: 1 > TxQ: 1 LRO > Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: eth4: IOV: VF 0 is enabled mac > 0E:15:B9:26:B3:7D > Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: eth4: IOV: VF 1 is enabled mac > 32:69:2D:16:B9:40 > Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: eth4: Intel(R) 10 Gigabit > Network Connection > Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: PCI INT A -> GSI 40 (level, > low) -> IRQ 40 > Nov 8 14:56:54 12 kernel: ixgbe: I/O Virtualization (IOV) set to 2 > Nov 8 14:56:54 12 kernel: ixgbe: :07:00.1: ixgbe_check_options: FCoE > Offload feature enabled > Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: not enough MMIO resources for > SR-IOV > Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: (unregistered net_device): > Failed to enable PCI sriov: -12 > Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: FCoE offload feature is not > available. Disabling FCoE offload feature > Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: (PCI Express:5.0GT/s:Width x8) > 68:05:ca:0c:7a:e3 > Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: eth5: MAC: 2, PHY: 2, PBA No: > G21371-003 > Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: eth5: Enabled Features: > RxQ: 16 TxQ: 16 FdirHash RSC > Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: eth5: Intel(R) 10 > Gigabit Network Connection > > # dmesg |grep -E 'DMA|IOMMU' > ACPI: DMAR bf3b3668 001C0 (v01 DELL PE_SC3 0001 DELL 0001) > DMA 0x0001 -> 0x1000 > DMA320x1000 -> 0x0010 > DMA zone: 56 pages used for memmap > DMA zone: 102 pages reserved > DMA zone: 3839 pages, LIFO batch:0 > DMA32 zone: 14280 pages used for memmap > DMA32 zone: 764849 pages, LIFO batch:31 > Intel-IOMMU: enabled > DMAR: Host address width 40 > DMAR: DRHD base: 0x00fed9 flags: 0x1 > IOMMU fed9: ver 1:0 cap c90780106f0462 ecap f020fe > DMAR: RMRR base: 0x00bf4c8000 end: 0x00bf4d > DMAR: RMRR base: 0x00bf4b1000 end: 0x00bf4b > DMAR: RMRR base: 0x00bf4a1000 end: 0x00bf4a1fff > DMAR: RMRR base: 0x00bf4a3000 end: 0x00bf4a3fff > DMAR: RMRR base: 0x00bf4a5000 end: 0x00bf4a5fff > DMAR: RMRR base: 0x00bf4a7000 end: 0x00bf4a7fff > DMAR: RMRR base: 0x00bf4c end: 0x00bf4c0fff > DMAR: RMRR base: 0x00bf4c2000 end: 0x00bf4c2fff > DMAR: ATSR flags: 0x0 > DMAR: Device scope device [:00:1a.02] not found > DMAR: Device scope device [:00:1a.02] not found > DMAR: Device scope device [:00:1d.02] not found > DMAR: Device scope device [:00:1d.02] not found > IOMMU 0xfed9: using Queued invalidation > IOMMU: Setting RMRR: > IOMMU: Setting identity map for device :00:1d.7 [0xbf4c2000 - 0xbf4c3000] > IOMMU: Setting identity map for device :00:1a.7 [0xbf4c - 0xbf4c1000] > IOMMU: Setting identity map for device :00:1d.1 [0xbf4a7000 - 0xbf4a8000] > IOMMU: Setting identity map for device :00:1d.0 [0xbf4a5000 - 0xbf4a6000] > IOMMU: Setting identity map for device :00:1a.1 [0xbf4a3000 - 0xbf4a4000] > IOMMU: Setting identity map for device
Re: [PATCH v2 1/2] thermal: exynos: Fix wrong bit to control tmu core
Hi
On 31 October 2012 12:17, Jonghwan Choi wrote:
> [0]bit is used to enable/disable tmu core. [1] bit is a reserved bit.
>
> Signed-off-by: Jonghwan Choi
> ---
> drivers/thermal/exynos_thermal.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/exynos_thermal.c
> b/drivers/thermal/exynos_thermal.c
> index fd03e85..6ce6667 100644
> --- a/drivers/thermal/exynos_thermal.c
> +++ b/drivers/thermal/exynos_thermal.c
> @@ -53,8 +53,8 @@
> #define EXYNOS_TMU_TRIM_TEMP_MASK 0xff
> #define EXYNOS_TMU_GAIN_SHIFT 8
> #define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24
> -#define EXYNOS_TMU_CORE_ON 3
> -#define EXYNOS_TMU_CORE_OFF2
> +#define EXYNOS_TMU_CORE_ON 1
> +#define EXYNOS_TMU_CORE_OFF0
Hi Jonghwan,
Only this much change is not sufficient. Also you need to do like below,
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index eebd4e5..4575144 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -52,9 +52,11 @@
#define EXYNOS_TMU_TRIM_TEMP_MASK 0xff
#define EXYNOS_TMU_GAIN_SHIFT 8
+#define EXYNOS_TMU_GAIN_MASK (0xF << 8)
#define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24
-#define EXYNOS_TMU_CORE_ON 3
-#define EXYNOS_TMU_CORE_OFF2
+#define EXYNOS_TMU_REF_VOLTAGE_MASK(0x1F << 24)
+#define EXYNOS_TMU_CORE_ON 1
+#define EXYNOS_TMU_CORE_OFF0
#define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
/* Exynos4210 specific registers */
@@ -85,7 +87,9 @@
#define EXYNOS_TMU_CLEAR_FALL_INT (0x111 << 16)
#define EXYNOS_MUX_ADDR_VALUE 6
#define EXYNOS_MUX_ADDR_SHIFT 20
+#define EXYNOS_MUX_ADDR_MASK (0xFF << 16)
#define EXYNOS_TMU_TRIP_MODE_SHIFT 13
+#define EXYNOS_TMU_TRIP_MODE_MASK (0x7 << 13)
#define EFUSE_MIN_VALUE 40
#define EFUSE_MAX_VALUE 100
@@ -658,10 +662,13 @@ static void exynos_tmu_control(struct
platform_device *pdev, bool on)
mutex_lock(>lock);
clk_enable(data->clk);
- con = pdata->reference_voltage << EXYNOS_TMU_REF_VOLTAGE_SHIFT |
+ con = readl(data->base + EXYNOS_TMU_REG_CONTROL);
+ con &= ~(EXYNOS_TMU_REF_VOLTAGE_MASK | EXYNOS_TMU_GAIN_MASK);
+ con |= pdata->reference_voltage << EXYNOS_TMU_REF_VOLTAGE_SHIFT |
pdata->gain << EXYNOS_TMU_GAIN_SHIFT;
if (data->soc == SOC_ARCH_EXYNOS) {
+ con &= ~(EXYNOS_TMU_TRIP_MODE_MASK | EXYNOS_MUX_ADDR_MASK);
con |= pdata->noise_cancel_mode << EXYNOS_TMU_TRIP_MODE_SHIFT;
con |= (EXYNOS_MUX_ADDR_VALUE << EXYNOS_MUX_ADDR_SHIFT);
}
Thanks,
Amit Daniel
> #define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
>
> /* Exynos4210 specific registers */
> --
> 1.7.4.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] pwm: lpc32xx - Fix the PWM polarity
On Thu, 08 Nov 2012 11:44:48 +0100 Roland Stigge wrote: > On 08/11/12 11:33, Alban Bedel wrote: > > On Thu, 08 Nov 2012 10:51:35 +0100 > > Roland Stigge wrote: > > > >> On 07/11/12 16:25, Alban Bedel wrote: > >>> Signed-off-by: Alban Bedel > >>> --- > >>> drivers/pwm/pwm-lpc32xx.c |6 +- > >>> 1 files changed, 5 insertions(+), 1 deletions(-) > >>> > >>> diff --git a/drivers/pwm/pwm-lpc32xx.c b/drivers/pwm/pwm-lpc32xx.c > >>> index adb87f0..0dc278d 100644 > >>> --- a/drivers/pwm/pwm-lpc32xx.c > >>> +++ b/drivers/pwm/pwm-lpc32xx.c > >>> @@ -51,7 +51,11 @@ static int lpc32xx_pwm_config(struct pwm_chip *chip, > >>> struct pwm_device *pwm, > >>> > >>> c = 256 * duty_ns; > >>> do_div(c, period_ns); > >>> - duty_cycles = c; > >>> + if (c == 0) > >>> + c = 256; > >>> + if (c > 255) > >>> + c = 255; > >>> + duty_cycles = 256 - c; > >> > >> Except for the range check (for the original c > 255), this results in: > >> > >>duty_cycles = 256 - c > >> > >> except for (c == 0) where > >> > >>duty_cycles = 1 > > > > No it lead to duty_cycles = 0 > > Let's do it step by step with the above code: > > c == 0 > > >>> + if (c == 0) > >>> + c = 256; > > c == 256 > > >>> + if (c > 255) > >>> + c = 255; > > c == 255 > > >>> + duty_cycles = 256 - c; > > c == 1 > > See? Right, my bad. > > > >> which actually is > >> > >>duty_cycles = (256 - c) - 255 > >> > >> (think with the original c) > >> > >> i.e. nearly a polarity inversion in the case of (c == 0). > >> > >> Why is the case (c == 0) so special here? Maybe you can document this, > >> if it is really intended? > > > > It is intended, the formular for duty value in the register is: > > > > duty = (256 - 256*duty_ns/period_ns) % 256 > > Where does this modulo defined? In the Manual, there is sth. like this > defined for RELOADV (tables 606+607), but not for DUTY. > > Maybe I missed sth. in the manual. Link or hint appreciated! The manual doesn't mention this explicitly but you can see that without the modulo when duty_ns==0 DUTY would be 256, but the register is only 8 bits wide (ie. modulo 256). I made a few test and looked at the PWM output on a scope they confirm this: DUTY HIGH LEVEL 1 99.9% 2590.0% 128 50.0% 220 10.0% 2550.1% 0 0.0% I'll resubmit the patch with the clamping in the correct order. Alban -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] raid5: panic() on dma_wait_for_async_tx() error
On Thursday 08 November 2012 12:15:26 Alan Cox wrote:
> On Thu, 08 Nov 2012 11:06:29 +0100
> Bartlomiej Zolnierkiewicz wrote:
>
> > From: Bartlomiej Zolnierkiewicz
> > Subject: [PATCH] raid5: panic() on dma_wait_for_async_tx() error
> >
> > There is not much we can do on dma_wait_for_async_tx() error
> > so just panic() for now.
> >
> > Cc: Neil Brown
> > Cc: Vinod Koul
> > Cc: Dan Williams
> > Cc: Tomasz Figa
> > Signed-off-by: Bartlomiej Zolnierkiewicz
> > Signed-off-by: Kyungmin Park
> > ---
> > drivers/md/raid5.c |4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > Index: b/drivers/md/raid5.c
> > ===
> > --- a/drivers/md/raid5.c2012-11-07 16:25:19.480876012 +0100
> > +++ b/drivers/md/raid5.c2012-11-07 16:27:46.244875992 +0100
> > @@ -3223,7 +3223,9 @@ static void handle_stripe_expansion(stru
> > /* done submitting copies, wait for them to complete */
> > if (tx) {
> > async_tx_ack(tx);
> > - dma_wait_for_async_tx(tx);
> > + if (dma_wait_for_async_tx(tx) != DMA_SUCCESS)
> > + panic("%s: DMA error waiting for transaction\n",
> > + __func__);
>
> Thats a really horrible place to panic.
Still it seems better thing to do than silently ignoring errors
and trying to continue operations with inconsistent data.
Unfortunately higher-layers don't support error conditions and
fixing them seems to be non-trivial task.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung Poland R Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] DMA: remove unused support for MEMSET operations
On Thursday 08 November 2012 12:12:31 Alan Cox wrote: > On Thu, 08 Nov 2012 10:58:17 +0100 > Bartlomiej Zolnierkiewicz wrote: > > > From: Bartlomiej Zolnierkiewicz > > Subject: [PATCH] DMA: remove unused support for MEMSET operations > > > > There have never been any real users of MEMSET operations > > In tree users. Please show me them. There were no users except self-test one (which this patch also removes), the whole memset code has been dead since its introduction in January 2007. > And is it broken, if not why do you want to break it ? Well, it is partially broken as async_memset.c doesn't even built currently in next (I've posted fix for that before noticing that the whole code can be removed). Best regards, -- Bartlomiej Zolnierkiewicz Samsung Poland R Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] DMA: remove unused support for MEMSET operations
On Thu, 08 Nov 2012 12:22:05 +0100 Bartlomiej Zolnierkiewicz wrote: > On Thursday 08 November 2012 12:12:31 Alan Cox wrote: > > On Thu, 08 Nov 2012 10:58:17 +0100 > > Bartlomiej Zolnierkiewicz wrote: > > > > > From: Bartlomiej Zolnierkiewicz > > > Subject: [PATCH] DMA: remove unused support for MEMSET operations > > > > > > There have never been any real users of MEMSET operations > > > > In tree users. > > Please show me them. Sorry ? There are potentially lots of out of tree users in both the ARM and x86 communities. > > And is it broken, if not why do you want to break it ? > > Well, it is partially broken as async_memset.c doesn't even built > currently in next (I've posted fix for that before noticing that > the whole code can be removed). Ok that does suggest it's not being used at all but it would be wise to check more widely. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pwm: lpc32xx - Fix the PWM polarity
The duty cycles value goes from 1 (99% HIGH) to 256 (0% HIGH) but it is stored modulo 256 in the register as it is only 8 bits wide. Signed-off-by: Alban Bedel --- drivers/pwm/pwm-lpc32xx.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/pwm/pwm-lpc32xx.c b/drivers/pwm/pwm-lpc32xx.c index adb87f0..2590f8d 100644 --- a/drivers/pwm/pwm-lpc32xx.c +++ b/drivers/pwm/pwm-lpc32xx.c @@ -51,7 +51,9 @@ static int lpc32xx_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm, c = 256 * duty_ns; do_div(c, period_ns); - duty_cycles = c; + if (c > 255) + c = 255; + duty_cycles = 256 - c; writel(PWM_ENABLE | PWM_RELOADV(period_cycles) | PWM_DUTY(duty_cycles), lpc32xx->base + (pwm->hwpwm << 2)); -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio: Don't access index after unregister.
On Thu, Nov 8, 2012 at 11:43 AM, Cornelia Huck wrote:
> Virtio wants to release used indices after the corresponding
> virtio device has been unregistered. However, virtio does not
> hold an extra reference, giving up its last reference with
> device_unregister(), making accessing dev->index afterwards
> invalid.
>
> I actually saw problems when testing my (not-yet-merged)
> virtio-ccw code:
>
> - device_add virtio-net,id=xxx
> -> creates device virtio with n>0
>
> - device_del xxx
> -> deletes virtio, but calls ida_simple_remove with an
>index of 0
>
> - device_add virtio-net,id=xxx
> -> tries to add virtio0, which is still in use...
>
> So let's save the index we want to release before calling
> device_unregister().
>
> Signed-off-by: Cornelia Huck
> ---
> drivers/virtio/virtio.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
> index 1e8659c..809b0de 100644
> --- a/drivers/virtio/virtio.c
> +++ b/drivers/virtio/virtio.c
> @@ -225,8 +225,10 @@ EXPORT_SYMBOL_GPL(register_virtio_device);
>
> void unregister_virtio_device(struct virtio_device *dev)
> {
> + int index = dev->index; /* save for after device release */
> +
> device_unregister(>dev);
> - ida_simple_remove(_index_ida, dev->index);
> + ida_simple_remove(_index_ida, index);
> }
> EXPORT_SYMBOL_GPL(unregister_virtio_device);
Acked-by: Sjur Brændeland
Great minds think alike! I discovered issues with this implementation
a while back and Michael suggested an identical patch:
https://lkml.org/lkml/2012/9/4/173
https://lkml.org/lkml/2012/9/7/105
The issue I ran into was that when virtio devices are created by remoteproc
the device memory might be freed when calling device_unregister(), and
the value of dev->index is then undefined. So this bug bites when
unregistering a Virtio devices from remoteproc with CONFIG_DEBUG_SLAB
enabled. However this bug is not triggered by virtio_pci as it implements a
non-standard device release-function that does not free the device memory.
Thanks,
Sjur
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mtip32xx: fix potential NULL pointer dereference in mtip_timeout_function()
On 2012-11-08 10:35, Wei Yongjun wrote: > From: Wei Yongjun > > The dereference to port should be moved below the NULL test. > > dpatch engine is used to auto generate this patch. > (https://github.com/weiyj/dpatch) Thanks, it definitely doesn't make sense to check for !port after having dereferenced it. Applied. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] pwm: New driver to support PWMs on TWL4030/6030 series of PMICs
On Thu, Nov 8, 2012 at 9:14 AM, Péter Ujfalusi wrote:
> On 11/07/2012 06:50 PM, Grazvydas Ignotas wrote:
>>> + if (pwm->hwpwm) {
>>> + /* PWM 1 */
>>> + mask = TWL4030_GPIO7_VIBRASYNC_PWM1_MASK;
>>> + bits = TWL4030_GPIO7_VIBRASYNC_PWM1_PWM1;
>>> + } else {
>>> + /* PWM 0 */
>>> + mask = TWL4030_GPIO6_PWM0_MUTE_MASK;
>>> + bits = TWL4030_GPIO6_PWM0_MUTE_PWM0;
>>> + }
>>> +
>>> + /* Save the current MUX configuration for the PWM */
>>> + twl->twl4030_pwm_mux &= ~mask;
>>> + twl->twl4030_pwm_mux |= (val & mask);
>>
>> Do we really need this mask clearing here? After probe twl4030_pwm_mux
>> should be zero, and if twl4030_pwm_request is called twice you don't
>> clear the important bits before |=, I think 'twl4030_pwm_mux = val &
>> mask' would be better here.
>
> I'm storing both PWM's state in the same variable, but in different offsets:
> PWM0: bits 2-3
> PWM1: bits 4-5
> Probably it is over engineering to clear the relevant bits in the backup
> storage, but better to be safe IMHO.
> I would leave this part as it is.
Oh, it should be good then.
--
Gražvydas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] ARM: ux500: add PRCM register base for pinctrl
From: Jonas Aaberg
This adds the PRCM register range base as a resource to
the pinctrl driver do we can break the dependency to the
PRCMU driver and handle these registers in the driver
alone.
Cc: a...@kernel.org
Signed-off-by: Jonas Aaberg
Signed-off-by: Linus Walleij
---
ARM SoC guys: this patch is better contained in the
pinctrl tree, can I have your ACK to push it through
pinctrl? Thanks.
---
arch/arm/mach-ux500/cpu-db8500.c | 2 +-
arch/arm/mach-ux500/devices-common.h | 8 +++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 87a8f9f..113d9c4 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -158,7 +158,7 @@ static void __init db8500_add_gpios(struct device *parent)
dbx500_add_gpios(parent, ARRAY_AND_SIZE(db8500_gpio_base),
IRQ_DB8500_GPIO0, );
- dbx500_add_pinctrl(parent, "pinctrl-db8500");
+ dbx500_add_pinctrl(parent, "pinctrl-db8500", U8500_PRCMU_BASE);
}
static int usb_db8500_rx_dma_cfg[] = {
diff --git a/arch/arm/mach-ux500/devices-common.h
b/arch/arm/mach-ux500/devices-common.h
index 7fbf0ba..96fa4ac 100644
--- a/arch/arm/mach-ux500/devices-common.h
+++ b/arch/arm/mach-ux500/devices-common.h
@@ -129,12 +129,18 @@ void dbx500_add_gpios(struct device *parent,
resource_size_t *base, int num,
int irq, struct nmk_gpio_platform_data *pdata);
static inline void
-dbx500_add_pinctrl(struct device *parent, const char *name)
+dbx500_add_pinctrl(struct device *parent, const char *name,
+ resource_size_t base)
{
+ struct resource res[] = {
+ DEFINE_RES_MEM(base, SZ_8K),
+ };
struct platform_device_info pdevinfo = {
.parent = parent,
.name = name,
.id = -1,
+ .res = res,
+ .num_res = ARRAY_SIZE(res),
};
platform_device_register_full();
--
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 2/2] pinctrl/nomadik: make independent of prcmu driver
From: Jonas Aaberg
Currently there are some unnecessary criss-cross
dependencies between the PRCMU driver in MFD and a lot of
other drivers, mainly because other drivers need to poke
around in the PRCM register range.
In cases like this there are actually just a few select
registers that the pinctrl driver need to read/modify/write,
and it turns out that no other driver is actually using
these registers, so there are no concurrency issues
whatsoever.
So: don't let the location of the register range complicate
things, just poke into these registers directly and skip
a layer of indirection.
Cc: Loic Pallardy
Signed-off-by: Jonas Aaberg
Signed-off-by: Linus Walleij
---
drivers/pinctrl/pinctrl-nomadik-db8500.c | 4 +--
drivers/pinctrl/pinctrl-nomadik-db8540.c | 4 +--
drivers/pinctrl/pinctrl-nomadik-stn8815.c | 4 +--
drivers/pinctrl/pinctrl-nomadik.c | 52 ++-
drivers/pinctrl/pinctrl-nomadik.h | 14 +
5 files changed, 45 insertions(+), 33 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-nomadik-db8500.c
b/drivers/pinctrl/pinctrl-nomadik-db8500.c
index 6de52e7..e73d75e 100644
--- a/drivers/pinctrl/pinctrl-nomadik-db8500.c
+++ b/drivers/pinctrl/pinctrl-nomadik-db8500.c
@@ -1230,7 +1230,7 @@ static const u16 db8500_prcm_gpiocr_regs[] = {
[PRCM_IDX_GPIOCR2] = 0x574,
};
-static const struct nmk_pinctrl_soc_data nmk_db8500_soc = {
+static struct nmk_pinctrl_soc_data nmk_db8500_soc = {
.gpio_ranges = nmk_db8500_ranges,
.gpio_num_ranges = ARRAY_SIZE(nmk_db8500_ranges),
.pins = nmk_db8500_pins,
@@ -1245,7 +1245,7 @@ static const struct nmk_pinctrl_soc_data nmk_db8500_soc =
{
};
void __devinit
-nmk_pinctrl_db8500_init(const struct nmk_pinctrl_soc_data **soc)
+nmk_pinctrl_db8500_init(struct nmk_pinctrl_soc_data **soc)
{
*soc = _db8500_soc;
}
diff --git a/drivers/pinctrl/pinctrl-nomadik-db8540.c
b/drivers/pinctrl/pinctrl-nomadik-db8540.c
index 52fc301..1276ba3 100644
--- a/drivers/pinctrl/pinctrl-nomadik-db8540.c
+++ b/drivers/pinctrl/pinctrl-nomadik-db8540.c
@@ -1240,7 +1240,7 @@ static const u16 db8540_prcm_gpiocr_regs[] = {
[PRCM_IDX_GPIOCR3] = 0x2bc,
};
-static const struct nmk_pinctrl_soc_data nmk_db8540_soc = {
+static struct nmk_pinctrl_soc_data nmk_db8540_soc = {
.gpio_ranges = nmk_db8540_ranges,
.gpio_num_ranges = ARRAY_SIZE(nmk_db8540_ranges),
.pins = nmk_db8540_pins,
@@ -1255,7 +1255,7 @@ static const struct nmk_pinctrl_soc_data nmk_db8540_soc =
{
};
void __devinit
-nmk_pinctrl_db8540_init(const struct nmk_pinctrl_soc_data **soc)
+nmk_pinctrl_db8540_init(struct nmk_pinctrl_soc_data **soc)
{
*soc = _db8540_soc;
}
diff --git a/drivers/pinctrl/pinctrl-nomadik-stn8815.c
b/drivers/pinctrl/pinctrl-nomadik-stn8815.c
index 7d432c3..ed5b144 100644
--- a/drivers/pinctrl/pinctrl-nomadik-stn8815.c
+++ b/drivers/pinctrl/pinctrl-nomadik-stn8815.c
@@ -339,7 +339,7 @@ static const struct nmk_function nmk_stn8815_functions[] = {
FUNCTION(i2cusb),
};
-static const struct nmk_pinctrl_soc_data nmk_stn8815_soc = {
+static struct nmk_pinctrl_soc_data nmk_stn8815_soc = {
.gpio_ranges = nmk_stn8815_ranges,
.gpio_num_ranges = ARRAY_SIZE(nmk_stn8815_ranges),
.pins = nmk_stn8815_pins,
@@ -351,7 +351,7 @@ static const struct nmk_pinctrl_soc_data nmk_stn8815_soc = {
};
void __devinit
-nmk_pinctrl_stn8815_init(const struct nmk_pinctrl_soc_data **soc)
+nmk_pinctrl_stn8815_init(struct nmk_pinctrl_soc_data **soc)
{
*soc = _stn8815_soc;
}
diff --git a/drivers/pinctrl/pinctrl-nomadik.c
b/drivers/pinctrl/pinctrl-nomadik.c
index 22f6937..33c614e 100644
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@ -30,20 +30,6 @@
#include
/* Since we request GPIOs from ourself */
#include
-/*
- * For the U8500 archs, use the PRCMU register interface, for the older
- * Nomadik, provide some stubs. The functions using these will only be
- * called on the U8500 series.
- */
-#ifdef CONFIG_ARCH_U8500
-#include
-#else
-static inline u32 prcmu_read(unsigned int reg) {
- return 0;
-}
-static inline void prcmu_write(unsigned int reg, u32 value) {}
-static inline void prcmu_write_masked(unsigned int reg, u32 mask, u32 value) {}
-#endif
#include
#include
@@ -85,7 +71,7 @@ struct nmk_gpio_chip {
struct nmk_pinctrl {
struct device *dev;
struct pinctrl_dev *pctl;
- const struct nmk_pinctrl_soc_data *soc;
+ struct nmk_pinctrl_soc_data *soc;
};
static struct nmk_gpio_chip *
@@ -247,6 +233,15 @@ nmk_gpio_disable_lazy_irq(struct nmk_gpio_chip *nmk_chip,
unsigned offset)
dev_dbg(nmk_chip->chip.dev, "%d: clearing interrupt mask\n", gpio);
}
+static void nmk_write_masked(void __iomem *reg, u32 mask, u32 value)
+{
+ u32 val;
+
+ val = readl(reg);
+ val = ((val & ~mask) | (value & mask));
+ writel(val, reg);
+}
+
static void
Re: [headache] 3.7.0-rc2 can't handle mutt (with 3.7G mail file) +FF (4 tabs) on a 4G memory+4 core system ?
To me this looks like an issue with swap. Can you try without swap (swapoff)? Ortwin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: PT_EXITKILL (Was: pdeath_signal)
On 11/07/2012 03:09 PM, Oleg Nesterov wrote: >> > > > > What I would IDEALLY like to have is a call, probably a ptrace >> > > > > option, >> > > > > where the parent can request: "If I am ever to terminate or be >> > > > > killed, >> > > > > then my ptraced son MUST die as well". >> > > >> > > Perhaps this makes sense... >> > > >> > > Chris, iirc you also suggested something like this? And the patch is >> > > trivial. (...) > OK. Please see the untested/uncompiled (but trivial) patch below > > - it adds PTRACE_O_EXITKILL. A better name? > > - A better numeric value? Note that the new option is not equal to > the last-ptrace-option << 1. Because currently all options have > the event, and the new one starts the eventless group. 1 << 16 > means we have the room for 8 more events. > > - it needs the convincing changelog for akpm If this isn't inherited by the ptrace child's children, a fork child can end up detached if the tracer dies before it had a chance of setting the PTRACE_O_EXITKILL on the new auto-attached child. Which sounds like another argument for PTRACE_O_INHERIT, as in: http://sourceware.org/ml/archer/2011-q1/msg00026.html (it sounds like you need to use PTRACE_SEIZE+options too to plug the race between PTRACE_ME/PTRACE_ATTACH and setting PTRACE_SETOPTIONS). (For completeness, Windows' age old equivalent, DebugSetProcessKillOnExit, it a tracer option, not tracee option, though that's not as flexible.) -- Pedro Alves -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] TPM: STMicroelectronics ST33 I2C V1.2.0
Mathias Leblanc writes: > +static int interrupts ; > +module_param(interrupts, bool, 0444); > +MODULE_PARM_DESC(interrupts, "Enable interrupts"); > + > +static int power_mgt = 1; > +module_param(power_mgt, bool, 0444); > +MODULE_PARM_DESC(power_mgt, "Power Management"); These are not bools, so why does module_param describe them as bool? Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] DMA: remove unused support for MEMSET operations
On Thursday 08 November 2012 12:31:48 Alan Cox wrote: > On Thu, 08 Nov 2012 12:22:05 +0100 > Bartlomiej Zolnierkiewicz wrote: > > > On Thursday 08 November 2012 12:12:31 Alan Cox wrote: > > > On Thu, 08 Nov 2012 10:58:17 +0100 > > > Bartlomiej Zolnierkiewicz wrote: > > > > > > > From: Bartlomiej Zolnierkiewicz > > > > Subject: [PATCH] DMA: remove unused support for MEMSET operations > > > > > > > > There have never been any real users of MEMSET operations > > > > > > In tree users. > > > > Please show me them. > > Sorry ? There are potentially lots of out of tree users in both the ARM > and x86 communities. They had almost six years to submit their code to upstream and there is potentially no problem for these _out_of_tree_ users to maintain also memset code out of tree. Best regards, -- Bartlomiej Zolnierkiewicz Samsung Poland R Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio-mmio: Fix irq parsing in command line parameter
Lee Jones writes: >> > Resorted to poaching now have we Pawel? > >> I hope you were joking! > > Yes, of course. I thought that was clearly indicated by the jovial winking > smiley. :) > > I realise it wasn't obvious soley by this exchange, but Pawel and I are > actually ol' friends. > >> Doing your work for you isn't poaching. > > This isn't related to my work, as I have no professional interest in > virtio. In this particular instance I was trying to help out by fixing bugs > uncovered by the use of randconfig, which I'm doing in my own time, as a > hobby. I guess the use my work address clouds this fact, so I apologise for > that. > > Sorry for any confusion or offence caused though Rusty. :) > > Kind regards, > Lee No offence for me. I just don't want bystanders to believe that there is some etiquette other than "best patch wins". Thanks for the clarification! Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] kfifo: round up the fifo size power of 2
On Tue, Oct 30, 2012 at 11:52:10PM -0700, Andrew Morton wrote:
> On Wed, 31 Oct 2012 07:30:33 +0100 Stefani Seibold
> wrote:
>
> > > Yes, and I guess the same to give them a 64-element one.
> > >
> > > >
> > > > If there's absolutely no prospect that the kfifo code will ever support
> > > > 100-byte fifos then I guess we should rework the API so that the caller
> > > > has to pass in log2 of the size, not the size itself. That way there
> > > > will be no surprises and no mistakes.
> > > >
> > > > That being said, the power-of-2 limitation isn't at all intrinsic to a
> > > > fifo, so we shouldn't do this. Ideally, we'd change the kfifo
> > > > implementation so it does what the caller asked it to do!
> > >
> > > I'm fine with removing the power-of-2 limitation. Stefani, what's your
> > > comment on that?
> > >
> >
> > You can't remove the power-of-2-limitation, since this would result in a
> > performance decrease (bit wise and vs. modulo operation).
>
> Probably an insignificant change in performance.
>
> It could be made much smaller by just never doing the modulus operation
> - instead do
>
> if (++index == max)
> index = 0;
>
> this does introduce one problem: it's no longer possible to distinguish
> the "full" and "empty" states by comparing the head and tail indices.
> But that is soluble.
Hi Andrew,
Yes, it is soluble. How about the following solution?
Add 2 more fields(in_off and out_off) in __kfifo structure, so that in
and out will keep increasing each time, while in_off and out_off will be
wrapped to head if goes to the end of fifo buffer.
So, we can use in and out for counting unused space, and distinguish the
"full" and "empty" state, and also, of course no need for locking.
Stefani, sorry for quite late reply. I checked all the code used kfifo_alloc
and kfifo_init. Firstly, there are a lot of users ;-)
And secondly, I did find some examples used kfifo as it supports
none-power-of-2 kfifo. Say, the one at drivers/hid/hid-logitech-dj.c:
if (kfifo_alloc(_dev->notif_fifo,
DJ_MAX_NUMBER_NOTIFICATIONS * sizeof(struct dj_report),
GFP_KERNEL)) {
which means it wants to allocate a kfifo buffer which can store
DJ_MAX_NUMBER_NOTIFICATIONS(8 here) dj_report(each 15 bytes) at once.
And DJ_MAX_NUMBER_NOTIFICATIONS * sizeof(struct dj_report) = 8 * 15.
Then current code would allocate a size of rounddown_power_of_2(120) =
64 bytes, which can hold 4 dj_report only once, which is a half of expected.
There are few more examples like this.
And, kfifo_init used a pre-allocated buffer, it would be a little strange
to ask user to pre-allocate a power of 2 size aligned buffer.
So, I guess it's would be good to support none-power-of-2 kfifo?
I know you care the performance a lot. Well, as Andrew said, it may
introduce a little insignificant drop(no modulus, few more add/dec).
Thus, do you have some benchmarks for that? I can have a test to check
if it is a insignificant change on performance or not :)
Thanks!
--yliu
>
> > Andrew is right, this is an API miss design. So it would be good to
> > rework the kfifo_init () and kfifo_alloc() to pass in log2 of the size,
> > not the size itself.
>
> The power-of-2 thing is just a restriction in the current
> implementation - it's not a good idea to cement that into the
> interface. Of course, it could later be uncemented if the
> implementation's restriction was later relaxed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs
On Thu, Nov 8, 2012 at 9:34 AM, Péter Ujfalusi wrote:
> On 11/07/2012 07:12 PM, Grazvydas Ignotas wrote:
>>> +static int twl4030_pwmled_config(struct pwm_chip *chip, struct pwm_device
>>> *pwm,
>>> + int duty_ns, int period_ns)
>>> +{
>>> + int duty_cycle = (duty_ns * TWL4030_LED_MAX) / period_ns;
>>> + u8 on_time;
>>> + u8 pwm_config[2];
>>> + int base, ret;
>>> +
>>> + if (duty_cycle >= TWL4030_LED_MAX)
>>> + on_time = TWL4030_LED_MAX;
>>> + else if (!duty_cycle)
>>> + on_time = TWL4030_LED_MAX - 1;
>>> + else
>>> + on_time = TWL4030_LED_MAX - duty_cycle;
>>> +
>>> + base = pwm->hwpwm * 2 + TWL4030_PWMA_REG;
>>> +
>>> + pwm_config[0] = on_time;
>>> + pwm_config[1] = TWL4030_LED_MAX;
>>> +
>>> + ret = twl_i2c_write(TWL4030_MODULE_LED, pwm_config, base, 2);
>>
>> Shouldn't this use TWL4030_MODULE_PWMA and TWL4030_MODULE_PWMB as
>> first argument? I can guess it works your way too, but
>> TWL4030_MODULE_PWMx would match the TRM better.
>
> I don't have strong opinion regarding to this. You mean changing from:
>
> base = pwm->hwpwm * 2 + TWL4030_PWMA_REG;
> ret = twl_i2c_write(TWL4030_MODULE_LED, pwm_config, base, 2);
>
> to:
>
> if (pwm->hwpwm)
> module = TWL4030_MODULE_PWMB;
> else
> module = TWL4030_MODULE_PWMA;
> ret = twl_i2c_write(module, pwm_config, 0, 2);
>
> But I want to note that I'm currently trying to clean up the mess around
> twl-core. In my view we have quite a bit of redundancy in there. The PWM A/B
> is for driving the LED A/B outputs. We should have only these modules for
> PWM/LED in twl-core:
> TWL_MODULE_PWM - offset for PWM0ON register in twl4030 and PWM1ON for twl6030
> TWL_MODULE_LED - offset for LEDEN register in twl4030 and LED_PWM_CTRL1
> for twl6030
>
> From here the driver can figure out what to do IMHO.
>
> There's no need to have separate TWL 'modules' for:
> TWL4030_BASEADD_PWM0
> TWL4030_BASEADD_PWM1
> TWL4030_BASEADD_PWMA
> TWL4030_BASEADD_PWMB
Well all these seem to come from TRM, no hard feelings here too but if
you are going to remove them, probably worth adding a comment.
--
Gražvydas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] ARM: ux500: add PRCM register base for pinctrl
On Thursday 08 November 2012, Linus Walleij wrote: > From: Jonas Aaberg > > This adds the PRCM register range base as a resource to > the pinctrl driver do we can break the dependency to the > PRCMU driver and handle these registers in the driver > alone. > > Cc: a...@kernel.org > Signed-off-by: Jonas Aaberg > Signed-off-by: Linus Walleij Acked-by: Arnd Bergmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: oops in _raw_spin_lock_irqsave
Hi guys, I report here a oops happened on my laptop running centos 6.3 with vanilla kernel 3.6.6. The laptop is configured like an AP running hostapd, dnsmasq, openvpn, miniupnpd. At some point I noticed all the logs of iptables going to console (usually they go in a separeted file). Looking at /var/log/messages I found the oops below. I restarted the laptop with "echo c > /proc/sysrq-trigger" so I have a dump that maybe can be useful to further investigate. Nov 8 12:14:50 pack kernel: BUG: unable to handle kernel NULL pointer dereference at 0100 Nov 8 12:14:50 pack kernel: IP: [] _raw_spin_lock_irqsave+0x8/0x30 Nov 8 12:14:50 pack kernel: PGD 71625067 PUD 71654067 PMD 0 Nov 8 12:14:50 pack kernel: Oops: 0002 [#1] SMP Nov 8 12:14:50 pack kernel: Modules linked in: bridge stp llc xt_statistic xt_LOG xt_time xt_connlimit xt_realm xt_addrtype iptable_raw xt_comment xt_recent xt_policy ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN ipt_CLUSTERIP ipt_ah nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_udplite nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_conntrack xt_connmark xt_CLASSIFY xt_tcpudp xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack iptable_mangle nfnetlink iptable_filter Nov 8 12:14:50 pack kernel: ip_tables x_tables ablk_helper cryptd crypto_wq aes_x86_64 aes_generic tun af_packet ipv6 binfmt_misc tcp_veno mousedev 8139too mii sg powernow_k8 mperf psmouse evdev k8temp 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 cryptomgr aead pcompress arc4 crypto_blkcipher ath5k ath mac80211 cfg80211 rfkill thermal video battery ac processor thermal_sys button ext4 mbcache jbd2 crc16 crypto_hash crypto_algapi crypto sdhci_pci sdhci mmc_core sr_mod cdrom sd_mod pata_acpi ata_generic i2c_piix4 ehci_hcd ohci_hcd usbcore usb_common ahci libahci libata scsi_mod radeon ttm drm_kms_helper drm firmware_class hwmon backlight i2c_algo_bit i2c_core cfbcopyarea cfbimgblt cfbfillrect unix dm_mod fbcon tileblit font bitblit softcursor fb fbdev atkbd libps2 i8042 serio Nov 8 12:14:50 pack kernel: CPU 1 Nov 8 12:14:50 pack kernel: Pid: 12038, comm: dnsmasq Not tainted 3.6.6-v2 #1 Packard Bell BV EasyNote_MX52/T12UV Nov 8 12:14:50 pack kernel: RIP: 0010:[] [] _raw_spin_lock_irqsave+0x8/0x30 Nov 8 12:14:50 pack kernel: RSP: 0018:88007b3499b0 EFLAGS: 00010096 Nov 8 12:14:50 pack kernel: RAX: 0296 RBX: 0100 RCX: dead00100100 Nov 8 12:14:50 pack kernel: RDX: 0100 RSI: 880071888060 RDI: 0100 Nov 8 12:14:50 pack kernel: RBP: 880071888060 R08: R09: 0002 Nov 8 12:14:50 pack kernel: R10: 0001 R11: 0001 R12: 880071888010 Nov 8 12:14:50 pack kernel: R13: 7fe8 R14: 880035abfc00 R15: 0040 Nov 8 12:14:50 pack kernel: FS: 7f20b2552700() GS:88007dd0() knlGS: Nov 8 12:14:50 pack kernel: CS: 0010 DS: ES: CR0: 80050033 Nov 8 12:14:50 pack kernel: CR2: 0100 CR3: 37884000 CR4: 07e0 Nov 8 12:14:50 pack kernel: DR0: DR1: DR2: Nov 8 12:14:50 pack kernel: DR3: DR6: 0ff0 DR7: 0400 Nov 8 12:14:50 pack kernel: Process dnsmasq (pid: 12038, threadinfo 88007b348000, task 880070d53b60) Nov 8 12:14:50 pack kernel: Stack: Nov 8 12:14:50 pack kernel: 8104aae9 0246 880071888050 880071888050 Nov 8 12:14:50 pack kernel: 810ec181 880071888000 810ec1dc 000f Nov 8 12:14:50 pack kernel: 000f 4000 810ec9f5 880071463464 Nov 8 12:14:50 pack kernel: Call Trace: Nov 8 12:14:50 pack kernel: [] ? remove_wait_queue+0x19/0x60 Nov 8 12:14:50 pack kernel: [] ? free_poll_entry+0x11/0x20 Nov 8 12:14:50 pack kernel: [] ? poll_freewait+0x4c/0x70 Nov 8 12:14:50 pack kernel: [] ? do_select+0x595/0x600 Nov 8 12:14:50 pack kernel: [] ? __pollwait+0x110/0x110 Nov 8 12:14:50 pack kernel: [] ? __pollwait+0x110/0x110 Nov 8 12:14:50 pack kernel: [] ? __pollwait+0x110/0x110 Nov 8 12:14:50 pack kernel: [] ? __pollwait+0x110/0x110 Nov 8 12:14:50 pack kernel: [] ? __pollwait+0x110/0x110 Nov 8 12:14:50 pack kernel: [] ? __pollwait+0x110/0x110 Nov 8 12:14:50 pack kernel: [] ?
Re: [PATCH v7 0/3] Add modules to support realtek PCIE card reade
On Thursday 08 November 2012, wwang wrote: > > 于 2012年11月08日 12:01, Alex Dubov 写道: > > Hi, > >> Do you have any comment on the MEMSTICK part in this v7 patchset? Can > >> you help to merge the patch to the kernel tree? > > > > I'm afraid that presently I don't have much time to look at the memstick > > related stuff any further. Hopefully, somebody else can step in and take a > > look at your submission. > > > > Sorry for that. > > > Hi Greg & Arnd: > > Can you help to review the MEMSTICK part in my patch and merge it to the > kernel tree? Alex is a little busy now and I can't find any other > maintainer who can take care of MEMSTICK subsystem. > I don't know anything about memstick specific questions, but I looked at the code and it seems entirely reasonable and well-written. Acked-by: Arnd Bergmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: PT_EXITKILL (Was: pdeath_signal)
Hi Amnon, On 11/08, Amnon Shiloh wrote: > > Thanks for the patch, I tried it and it works nicely! OK, thanks. I'll wait for other comments a bit and then send the patch to Andrew. > Also, I just noticed that this new option (PTRACE_O_EXITKILL) is not > safe with ptrace(PTRACE_TRACEME)+execve, because the parent may die > before even having a chance to set PTRACE_O_EXITKILL! Not safe? I guess you meant that PTRACE_O_EXITKILL can't prevent this race? Yes sure. Or the parent can die before it does PTRACE_O_EXITKILL. > However, that's easy to fix by using PTRACE_ATTACH instead. Or the child can check getppid() == saved_parent_pid after PTRACE_TRACEME. But if you switch to PTRACE_ATTACH, I'd suggest to use PTRACE_SEIZE. Note that, in particular, this allows you to specify the options at attach. As for PF_NO_SIGSTOP, I'll write another email. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/2] memcg, oom: provide more precise dump info while memcg oom happening
On 11/08/2012 02:02 AM, David Rientjes wrote:
On Wed, 7 Nov 2012, Sha Zhengju wrote:
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 0eab7d5..2df5e72 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -118,6 +118,14 @@ static const char * const mem_cgroup_events_names[] = {
"pgmajfault",
};
+static const char * const mem_cgroup_lru_names[] = {
+ "inactive_anon",
+ "active_anon",
+ "inactive_file",
+ "active_file",
+ "unevictable",
+};
+
/*
* Per memcg event counter is incremented at every pagein/pageout. With THP,
* it will be incremated by the number of pages. This counter is used for
@@ -1501,8 +1509,59 @@ static void move_unlock_mem_cgroup(struct mem_cgroup
*memcg,
spin_unlock_irqrestore(>move_lock, *flags);
}
+#define K(x) ((x)<< (PAGE_SHIFT-10))
+static void mem_cgroup_print_oom_stat(struct mem_cgroup *memcg)
+{
+ struct mem_cgroup *mi;
+ unsigned int i;
+
+ if (!memcg->use_hierarchy&& memcg != root_mem_cgroup) {
+ for (i = 0; i< MEM_CGROUP_STAT_NSTATS; i++) {
+ if (i == MEM_CGROUP_STAT_SWAP&& !do_swap_account)
+ continue;
+ printk(KERN_CONT "%s:%ldKB ", mem_cgroup_stat_names[i],
This printk isn't continuing any previous printk, so using KERN_CONT here
will require a short header to be printed first ("Memcg: "?) with
KERN_INFO before the iterations.
Yep...I think I lost it while rebasing... sorry for the stupid mistake.
+ K(mem_cgroup_read_stat(memcg, i)));
+ }
+
+ for (i = 0; i< MEM_CGROUP_EVENTS_NSTATS; i++)
+ printk(KERN_CONT "%s:%lu ", mem_cgroup_events_names[i],
+ mem_cgroup_read_events(memcg, i));
+
+ for (i = 0; i< NR_LRU_LISTS; i++)
+ printk(KERN_CONT "%s:%luKB ", mem_cgroup_lru_names[i],
+ K(mem_cgroup_nr_lru_pages(memcg, BIT(i;
+ } else {
+
Spurious newline.
Eek, is there really no way to avoid this if-conditional and just use
for_each_mem_cgroup_tree() for everything and use
mem_cgroup_iter_break(memcg, iter);
break;
for !memcg->use_hierarchy?
Now I'm shamed at my bad brain of yesterday by sending this chunk out...
Yes, the if-part code above is obviously unwanted, and the
for_each_mem_cgroup_tree
can handle hierarchy already.
+ for (i = 0; i< MEM_CGROUP_STAT_NSTATS; i++) {
+ long long val = 0;
+
+ if (i == MEM_CGROUP_STAT_SWAP&& !do_swap_account)
+ continue;
+ for_each_mem_cgroup_tree(mi, memcg)
+ val += mem_cgroup_read_stat(mi, i);
+ printk(KERN_CONT "%s:%lldKB ",
mem_cgroup_stat_names[i], K(val));
+ }
+
+ for (i = 0; i< MEM_CGROUP_EVENTS_NSTATS; i++) {
+ unsigned long long val = 0;
+
+ for_each_mem_cgroup_tree(mi, memcg)
+ val += mem_cgroup_read_events(mi, i);
+ printk(KERN_CONT "%s:%llu ",
+ mem_cgroup_events_names[i], val);
+ }
+
+ for (i = 0; i< NR_LRU_LISTS; i++) {
+ unsigned long long val = 0;
+
+ for_each_mem_cgroup_tree(mi, memcg)
+ val += mem_cgroup_nr_lru_pages(mi, BIT(i));
+ printk(KERN_CONT "%s:%lluKB ", mem_cgroup_lru_names[i],
K(val));
+ }
+ }
+ printk(KERN_CONT "\n");
+}
/**
- * mem_cgroup_print_oom_info: Called from OOM with tasklist_lock held in read
mode.
* @memcg: The memory cgroup that went over limit
* @p: Task that is going to be killed
*
@@ -1569,6 +1628,8 @@ done:
res_counter_read_u64(>kmem, RES_USAGE)>> 10,
res_counter_read_u64(>kmem, RES_LIMIT)>> 10,
res_counter_read_u64(>kmem, RES_FAILCNT));
+
+ mem_cgroup_print_oom_stat(memcg);
I think this should be folded into mem_cgroup_print_oom_info(), I don't
see a need for a new function.
}
/*
@@ -5195,14 +5256,6 @@ static int memcg_numa_stat_show(struct cgroup *cont,
struct cftype *cft,
}
#endif /* CONFIG_NUMA */
-static const char * const mem_cgroup_lru_names[] = {
- "inactive_anon",
- "active_anon",
- "inactive_file",
- "active_file",
- "unevictable",
-};
-
static inline void mem_cgroup_lru_names_not_uptodate(void)
{
BUILD_BUG_ON(ARRAY_SIZE(mem_cgroup_lru_names) != NR_LRU_LISTS);
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 7e9e911..4b8a6dd 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -421,8 +421,10 @@ static void dump_header(struct task_struct *p, gfp_t
gfp_mask, int order,
cpuset_print_task_mems_allowed(current);
Re: [PATCH 1/2] kfifo: round up the fifo size power of 2
Am Donnerstag, den 08.11.2012, 20:24 +0800 schrieb Yuanhan Liu:
> On Tue, Oct 30, 2012 at 11:52:10PM -0700, Andrew Morton wrote:
> > On Wed, 31 Oct 2012 07:30:33 +0100 Stefani Seibold
> > wrote:
> >
> > > > Yes, and I guess the same to give them a 64-element one.
> > > >
> > > > >
> > > > > If there's absolutely no prospect that the kfifo code will ever
> > > > > support
> > > > > 100-byte fifos then I guess we should rework the API so that the
> > > > > caller
> > > > > has to pass in log2 of the size, not the size itself. That way there
> > > > > will be no surprises and no mistakes.
> > > > >
> > > > > That being said, the power-of-2 limitation isn't at all intrinsic to a
> > > > > fifo, so we shouldn't do this. Ideally, we'd change the kfifo
> > > > > implementation so it does what the caller asked it to do!
> > > >
> > > > I'm fine with removing the power-of-2 limitation. Stefani, what's your
> > > > comment on that?
> > > >
> > >
> > > You can't remove the power-of-2-limitation, since this would result in a
> > > performance decrease (bit wise and vs. modulo operation).
> >
> > Probably an insignificant change in performance.
> >
> > It could be made much smaller by just never doing the modulus operation
> > - instead do
> >
> > if (++index == max)
> > index = 0;
> >
> > this does introduce one problem: it's no longer possible to distinguish
> > the "full" and "empty" states by comparing the head and tail indices.
> > But that is soluble.
>
> Hi Andrew,
>
> Yes, it is soluble. How about the following solution?
>
> Add 2 more fields(in_off and out_off) in __kfifo structure, so that in
> and out will keep increasing each time, while in_off and out_off will be
> wrapped to head if goes to the end of fifo buffer.
>
> So, we can use in and out for counting unused space, and distinguish the
> "full" and "empty" state, and also, of course no need for locking.
>
> Stefani, sorry for quite late reply. I checked all the code used kfifo_alloc
> and kfifo_init. Firstly, there are a lot of users ;-)
>
> And secondly, I did find some examples used kfifo as it supports
> none-power-of-2 kfifo. Say, the one at drivers/hid/hid-logitech-dj.c:
>if (kfifo_alloc(_dev->notif_fifo,
>DJ_MAX_NUMBER_NOTIFICATIONS * sizeof(struct dj_report),
>GFP_KERNEL)) {
>
> which means it wants to allocate a kfifo buffer which can store
> DJ_MAX_NUMBER_NOTIFICATIONS(8 here) dj_report(each 15 bytes) at once.
>
> And DJ_MAX_NUMBER_NOTIFICATIONS * sizeof(struct dj_report) = 8 * 15.
> Then current code would allocate a size of rounddown_power_of_2(120) =
> 64 bytes, which can hold 4 dj_report only once, which is a half of expected.
>
This will go away with a log API.
> There are few more examples like this.
>
> And, kfifo_init used a pre-allocated buffer, it would be a little strange
> to ask user to pre-allocate a power of 2 size aligned buffer.
>
> So, I guess it's would be good to support none-power-of-2 kfifo?
>
> I know you care the performance a lot. Well, as Andrew said, it may
> introduce a little insignificant drop(no modulus, few more add/dec).
> Thus, do you have some benchmarks for that? I can have a test to check
> if it is a insignificant change on performance or not :)
>
Dirty, Ugly, Hacky and this will produce a lot of overhead, especially
for kfifo_put and kfifo_get which are inlined code.
In the kernel world it was always a regular use case to use power-of-2
restricted API's, f.e. the slab cache.
I see no benefit for a none-power-of-2 kfifo, only drawbacks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: UAPI for new arches (was Re: [GIT PULL] User API Disintegrate: Preparatory patches)
Vineet Gupta wrote: > I'm planning to submit ARC Linux kernel port (from Synopsys) for review > on lkml and arch mailing lists. I already have a a 3.7-rc3 based kernel > (modulo the arch UAPI split). What would be the best way to get the UAPI > split done. Do you want the headers to be split in the patches that add them, or would you be happy with one patch stacked on the end to do the whole lot? The last is easiest for me to do. However, I could 'uncommit' your patches using stgit, do the headers individually and recommit them if you'd prefer. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [net-next:master 209/235] drivers/net/usb/smsc95xx.c:1134:39-50: ERROR: reference preceded by free on line 1136
Julia,
On Thu, Nov 08, 2012 at 09:08:04AM +0100, Julia Lawall wrote:
> It's a false positive because check_warn_return does a return.
Right.
> But I wonder if there is a way that we can encourage people not to
> do things like that?
Well I suspect the memory leak bug 06a221be0 tries to fix might be
due to check_warn_return() hiding the otherwise very obvious syntax
highlighted 'return' statement.
Thanks,
Fengguang
> >TO: Ming Lei
> >CC: net...@vger.kernel.org
> >
> >
> >Hi Ming,
> >
> >FYI, there are coccinelle warnings in
> >
> >tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
> >master
> >head: f1e0b5b4f1eae56a3192688177f36e2bdf0e01ac
> >commit: 06a221be022c2cc98a48e0808a4ef0dc8f0b3a34 [209/235] usbnet: smsc95xx:
> >fix memory leak in smsc95xx_suspend
> >:: branch date: 8 hours ago
> >:: commit date: 23 hours ago
> >
> >+ drivers/net/usb/smsc95xx.c:1134:39-50: ERROR: reference preceded by free
> >on line 1136
> > drivers/net/usb/smsc95xx.c:1139:8-19: ERROR: reference preceded by free on
> > line 1136
> >
> >git remote update net-next
> >git checkout 06a221be022c2cc98a48e0808a4ef0dc8f0b3a34
> >vim +1134 drivers/net/usb/smsc95xx.c
> >
> >bbd9f9ee Steve Glendinning 2012-10-26 1128
> >offset[filter/4] |= 0x00 << ((filter % 4) * 8);
> >bbd9f9ee Steve Glendinning 2012-10-26 1129
> >crc[filter/2] |= smsc_crc(dev->net->dev_addr, ETH_ALEN, filter);
> >bbd9f9ee Steve Glendinning 2012-10-26 1130
> >filter++;
> >bbd9f9ee Steve Glendinning 2012-10-26 1131 }
> >bbd9f9ee Steve Glendinning 2012-10-26 1132
> >bbd9f9ee Steve Glendinning 2012-10-26 1133 for (i = 0; i <
> >(pdata->wuff_filter_count * 4); i++) {
> >bbd9f9ee Steve Glendinning 2012-10-26 @1134 ret =
> >smsc95xx_write_reg(dev, WUFF, filter_mask[i]);
> >06a221be Ming Lei 2012-11-06 1135 if (ret
> >< 0)
> >06a221be Ming Lei 2012-11-06 @1136
> >kfree(filter_mask);
> >bbd9f9ee Steve Glendinning 2012-10-26 1137
> >check_warn_return(ret, "Error writing WUFF");
> >bbd9f9ee Steve Glendinning 2012-10-26 1138 }
> >06a221be Ming Lei 2012-11-06 1139
> >kfree(filter_mask);
> >
> >:: The code at line 1134 was first introduced by commit:
> >:: bbd9f9e smsc95xx: add wol support for more frame types
> >
> >:: TO: Steve Glendinning
> >:: CC: David S. Miller
> >
> >---
> >0-DAY kernel build testing backend Open Source Technology Center
> >Fengguang Wu, Yuanhan Liu Intel Corporation
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: PT_EXITKILL (Was: pdeath_signal)
On 11/08, Pedro Alves wrote: > > On 11/07/2012 03:09 PM, Oleg Nesterov wrote: > > > OK. Please see the untested/uncompiled (but trivial) patch below > > > > - it adds PTRACE_O_EXITKILL. A better name? > > > > - A better numeric value? Note that the new option is not equal to > > the last-ptrace-option << 1. Because currently all options have > > the event, and the new one starts the eventless group. 1 << 16 > > means we have the room for 8 more events. > > > > - it needs the convincing changelog for akpm > > > If this isn't inherited by the ptrace child's children, a fork child can > end up detached if the tracer dies before it had a chance of setting > the PTRACE_O_EXITKILL on the new auto-attached child. It is copied like the other options. > Which sounds like another argument for PTRACE_O_INHERIT, as in: > http://sourceware.org/ml/archer/2011-q1/msg00026.html The point of PTRACE_O_INHERIT would be to attach newly-created threads and children without causing an event stop and the attendant overhead. this is another thing, I guess. > (it sounds like you need to use PTRACE_SEIZE+options too to plug > the race between PTRACE_ME/PTRACE_ATTACH and > setting PTRACE_SETOPTIONS). Agreed, PTRACE_SEIZE+options is better. > (For completeness, Windows' age old equivalent, > DebugSetProcessKillOnExit, it a tracer option, not tracee option, though > that's not as flexible.) Thanks ;) Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/2] memcg, oom: provide more precise dump info while memcg oom happening
On Thu 08-11-12 20:37:45, Sha Zhengju wrote: > On 11/08/2012 02:02 AM, David Rientjes wrote: > >On Wed, 7 Nov 2012, Sha Zhengju wrote: [..] > >>+ else > >>+ show_mem(SHOW_MEM_FILTER_NODES); > >Well that's disappointing if memcg == root_mem_cgroup, we'd probably like > >to know the global memory state to determine what the problem is. > > > > I really wondering if there is any case that can pass > root_mem_cgroup down here. No it cannot because the root cgroup doesn't have any limit so we cannot trigger memcg oom killer. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] memcg, oom: provide more precise dump info while memcg oom happening
On 11/08/2012 06:17 AM, Michal Hocko wrote:
On Wed 07-11-12 16:41:36, Sha Zhengju wrote:
From: Sha Zhengju
Current, when a memcg oom is happening the oom dump messages is still global
state and provides few useful info for users. This patch prints more pointed
memcg page statistics for memcg-oom.
Signed-off-by: Sha Zhengju
Cc: Michal Hocko
Cc: KAMEZAWA Hiroyuki
Cc: David Rientjes
Cc: Andrew Morton
---
mm/memcontrol.c | 71 ---
mm/oom_kill.c |6 +++-
2 files changed, 66 insertions(+), 11 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 0eab7d5..2df5e72 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
[...]
@@ -1501,8 +1509,59 @@ static void move_unlock_mem_cgroup(struct mem_cgroup
*memcg,
spin_unlock_irqrestore(>move_lock, *flags);
}
+#define K(x) ((x)<< (PAGE_SHIFT-10))
+static void mem_cgroup_print_oom_stat(struct mem_cgroup *memcg)
+{
+ struct mem_cgroup *mi;
+ unsigned int i;
+
+ if (!memcg->use_hierarchy&& memcg != root_mem_cgroup) {
+ for (i = 0; i< MEM_CGROUP_STAT_NSTATS; i++) {
+ if (i == MEM_CGROUP_STAT_SWAP&& !do_swap_account)
+ continue;
+ printk(KERN_CONT "%s:%ldKB ", mem_cgroup_stat_names[i],
+ K(mem_cgroup_read_stat(memcg, i)));
+ }
+
+ for (i = 0; i< MEM_CGROUP_EVENTS_NSTATS; i++)
+ printk(KERN_CONT "%s:%lu ", mem_cgroup_events_names[i],
+ mem_cgroup_read_events(memcg, i));
+
+ for (i = 0; i< NR_LRU_LISTS; i++)
+ printk(KERN_CONT "%s:%luKB ", mem_cgroup_lru_names[i],
+ K(mem_cgroup_nr_lru_pages(memcg, BIT(i;
+ } else {
+
+ for (i = 0; i< MEM_CGROUP_STAT_NSTATS; i++) {
+ long long val = 0;
+
+ if (i == MEM_CGROUP_STAT_SWAP&& !do_swap_account)
+ continue;
+ for_each_mem_cgroup_tree(mi, memcg)
+ val += mem_cgroup_read_stat(mi, i);
+ printk(KERN_CONT "%s:%lldKB ",
mem_cgroup_stat_names[i], K(val));
+ }
+
+ for (i = 0; i< MEM_CGROUP_EVENTS_NSTATS; i++) {
+ unsigned long long val = 0;
+
+ for_each_mem_cgroup_tree(mi, memcg)
+ val += mem_cgroup_read_events(mi, i);
+ printk(KERN_CONT "%s:%llu ",
+ mem_cgroup_events_names[i], val);
+ }
+
+ for (i = 0; i< NR_LRU_LISTS; i++) {
+ unsigned long long val = 0;
+
+ for_each_mem_cgroup_tree(mi, memcg)
+ val += mem_cgroup_nr_lru_pages(mi, BIT(i));
+ printk(KERN_CONT "%s:%lluKB ", mem_cgroup_lru_names[i],
K(val));
+ }
+ }
This is just plain ugly. for_each_mem_cgroup_tree is use_hierarchy aware
and there is no need for if (use_hierarchy) part.
memcg != root_mem_cgroup test doesn't make much sense as well because we
call that a global oom killer ;)
Yes... bitterly did I repent the patch... The else-part of
for_each_mem_cgroup_tree
is enough for hierarchy. I'll send a update one later.
Sorry for the noise. : (
Thanks,
Sha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 7/9] cgroup_freezer: introduce CGROUP_FREEZING_[SELF|PARENT]
On Sat 03-11-12 01:38:33, Tejun Heo wrote:
> Introduce FREEZING_SELF and FREEZING_PARENT and make FREEZING OR of
> the two flags. This is to prepare for full hierarchy support.
>
> freezer_apply_date() is updated such that it can handle setting and
> clearing of both flags. The two flags are also exposed to userland
> via read-only files self_freezing and parent_freezing.
>
> Other than the added cgroupfs files, this patch doesn't introduce any
> behavior change.
OK, I can imagine that this might be useful to find the first parent
group that needs to be thawed to unfreeze the group I am interested
in. Could you also update Documentation/cgroups/freezer-subsystem.txt to
clarify the intended usage?
Minor nit. Same as mentioned in the previous patch freezer_apply_state
should get enum freezer_state_flags state parameter.
> Signed-off-by: Tejun Heo
Reviewed-by: Michal Hocko
> ---
> kernel/cgroup_freezer.c | 55
> ++---
> 1 file changed, 47 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/cgroup_freezer.c b/kernel/cgroup_freezer.c
> index e76aa9f..b8ad93c 100644
> --- a/kernel/cgroup_freezer.c
> +++ b/kernel/cgroup_freezer.c
> @@ -23,8 +23,12 @@
> #include
>
> enum freezer_state_flags {
> - CGROUP_FREEZING = (1 << 1), /* this freezer is freezing */
> + CGROUP_FREEZING_SELF= (1 << 1), /* this freezer is freezing */
> + CGROUP_FREEZING_PARENT = (1 << 2), /* the parent freezer is freezing */
> CGROUP_FROZEN = (1 << 3), /* this and its descendants frozen
> */
> +
> + /* mask for all FREEZING flags */
> + CGROUP_FREEZING = CGROUP_FREEZING_SELF | CGROUP_FREEZING_PARENT,
> };
>
> struct freezer {
> @@ -245,8 +249,13 @@ static void unfreeze_cgroup(struct freezer *freezer)
> * freezer_apply_state - apply state change to a single cgroup_freezer
> * @freezer: freezer to apply state change to
> * @freeze: whether to freeze or unfreeze
> + * @state: CGROUP_FREEZING_* flag to set or clear
> + *
> + * Set or clear @state on @cgroup according to @freeze, and perform
> + * freezing or thawing as necessary.
> */
> -static void freezer_apply_state(struct freezer *freezer, bool freeze)
> +static void freezer_apply_state(struct freezer *freezer, bool freeze,
> + unsigned int state)
> {
> /* also synchronizes against task migration, see freezer_attach() */
> lockdep_assert_held(>lock);
> @@ -254,13 +263,19 @@ static void freezer_apply_state(struct freezer
> *freezer, bool freeze)
> if (freeze) {
> if (!(freezer->state & CGROUP_FREEZING))
> atomic_inc(_freezing_cnt);
> - freezer->state |= CGROUP_FREEZING;
> + freezer->state |= state;
> freeze_cgroup(freezer);
> } else {
> - if (freezer->state & CGROUP_FREEZING)
> - atomic_dec(_freezing_cnt);
> - freezer->state &= ~(CGROUP_FREEZING | CGROUP_FROZEN);
> - unfreeze_cgroup(freezer);
> + bool was_freezing = freezer->state & CGROUP_FREEZING;
> +
> + freezer->state &= ~state;
> +
> + if (!(freezer->state & CGROUP_FREEZING)) {
> + if (was_freezing)
> + atomic_dec(_freezing_cnt);
> + freezer->state &= ~CGROUP_FROZEN;
> + unfreeze_cgroup(freezer);
> + }
> }
> }
>
> @@ -275,7 +290,7 @@ static void freezer_change_state(struct freezer *freezer,
> bool freeze)
> {
> /* update @freezer */
> spin_lock_irq(>lock);
> - freezer_apply_state(freezer, freeze);
> + freezer_apply_state(freezer, freeze, CGROUP_FREEZING_SELF);
> spin_unlock_irq(>lock);
> }
>
> @@ -295,6 +310,20 @@ static int freezer_write(struct cgroup *cgroup, struct
> cftype *cft,
> return 0;
> }
>
> +static u64 freezer_self_freezing_read(struct cgroup *cgroup, struct cftype
> *cft)
> +{
> + struct freezer *freezer = cgroup_freezer(cgroup);
> +
> + return (bool)(freezer->state & CGROUP_FREEZING_SELF);
> +}
> +
> +static u64 freezer_parent_freezing_read(struct cgroup *cgroup, struct cftype
> *cft)
> +{
> + struct freezer *freezer = cgroup_freezer(cgroup);
> +
> + return (bool)(freezer->state & CGROUP_FREEZING_PARENT);
> +}
> +
> static struct cftype files[] = {
> {
> .name = "state",
> @@ -302,6 +331,16 @@ static struct cftype files[] = {
> .read_seq_string = freezer_read,
> .write_string = freezer_write,
> },
> + {
> + .name = "self_freezing",
> + .flags = CFTYPE_NOT_ON_ROOT,
> + .read_u64 = freezer_self_freezing_read,
> + },
> + {
> + .name = "parent_freezing",
> + .flags = CFTYPE_NOT_ON_ROOT,
> + .read_u64 = freezer_parent_freezing_read,
> + },
> { } /* terminate */
> };
PF_NO_SIGSTOP (Was: PT_EXITKILL)
On 11/08, Amnon Shiloh wrote:
>
> > > What I wish is that I could request (using "prctl" or whatever):
> > > "If a non-privileged user sends me a SIGSTOP, then let it be converted
> > > into...",
> >
> > I hope we won't do this ;) But I am not going to argue if you convince
> > other people.
> >
> > To me it would be better to simply allow to catch SIGSTOP, but I hope
> > we won't do this too.
>
> I don't think anyone should seriously contemplate catching SIGSTOP -
> that would break so many applications, including mine.
>
> Now about "convincing", I have that application that really needs this
> feature, and I believe that others may be in the same predicament, which is:
>
> 1. The application is a SUID-root service, available to ordinary users.
> 2. Users who started this application are allowed at any time to signal
>or kill their instance(s) of this application.
Is this the only reason why this service keeps its original real-UID?
(see below)
> 3. It is alright for the application to be killed by SIGKILL.
> 4. The application catches and does something useful and positive with
>all other signals sent to it by the invoking user, including SIGTSTP,
>SIGTTIN and SIGTTOU.
> 5. If the application is unpreparedly stopped by SIGSTOP, which it cannot
>catch, then this may disrupt other instances of this application by
>other users (including, in my case, on other computers connected with
>the application by TCP/IP sockets).
>
> What I ask is simple and can be so easily implemented, essentially in
> "kernel/signal.c":
>
> static int check_kill_permission(int sig, struct siginfo *info,
>struct task_struct *t)
> {
> ...
> + if (sig == SIGSTOP && (t->flags & PF_NO_SIGSTOP) && !capable(CAP_KILL))
No, this is not enough. At least PF_NO_SIGSTOP should be per-process,
not per-thread. But I agree, it is simpe to implement.
So once again, no need to convince me ;) I try to never argue with
the new features, even if personally I do not really like this idea.
If someone acks your idea I will be happy to help with the patch.
And I have another idea... Not that I like it very much, but it looks
simple and maybe useful.
What if we introduce SA_NOSECURITY? So that if an application does
sa.sa_flags = SA_NOSECURITY | ...;
sigaction(SIG, , NULL);
then sys_kill/etc bypasses security checks.
This way your service can run as root and still recieve the signals
from the ordinary users. Yes, except SIGKILL/SIGSTOP.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] UAPI: perf fixes
Hi Arnaldo,
Assuming my patches should be based on your perf/core branch, could you pull
from my git tree at tag perf-uapi-20121108 into your perf/core branch?
Note the tree also contains a uapi-perf-x86-20121108 tag that has the UAPI
disintegration branch for x86 merged on top for reference.
There are six commits, three preliminary patches:
(1) A patch to export asm/svm.h, asm/vmx.h and asm/perf_regs.h to UAPI.
(2) A merge for (1) - the patch in (1) is premerged by the UAPI disintegration
for x86 also, and I'd rather not include your perf/core branch in that if
I can avoid it.
(3) A patch to export and disintegrate linux/hw_breakpoint.h. It looks like
it should perhaps have been exported already, given the __KERNEL__ markers
in it.
and then the main three patches:
(4) Use a makefile $(call ...) function in tools/Makefile to make it easier
to deal with.
(5) Fix handling of O= with a relative path when doing something like:
make tools/perf O=foo
from the top-level directory in the kernel source tree for all tools.
(6) Make perf work for x86 by adding -I flags and changing long #includes
with "../../include" in them into short type things.
David
---
The following changes since commit 8dfec403e39b7c37fd6e8813bacc01da1e1210ab:
perf tests: Removing 'optional' field (2012-11-05 14:03:59 -0300)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/perf-uapi-20121108
for you to fetch changes up to 028c2c390c71d3d37f91291ac8e827f5028f7975:
perf: Make perf build for x86 with UAPI disintegration applied (2012-11-08
11:55:58 +)
perf fixes 2012-11-08
David Howells (6):
x86: Export asm/{svm.h,vmx.h,perf_regs.h}
UAPI: Merge pre-disintegration bits for x86
UAPI: Export and disintegrate linux/hw_breakpoint.h
tools: Define a Makefile function to do subdir processing
tools: Honour the O= flag when tool build called from a higher Makefile
perf: Make perf build for x86 with UAPI disintegration applied
Makefile| 6 --
arch/x86/include/asm/Kbuild | 3 +++
include/linux/hw_breakpoint.h | 31 +--
include/uapi/linux/Kbuild | 1 +
include/uapi/linux/hw_breakpoint.h | 30 ++
tools/Makefile | 24
tools/perf/Makefile | 28 +++-
tools/perf/arch/x86/include/perf_regs.h | 2 +-
tools/perf/builtin-kvm.c| 6 +++---
tools/perf/perf.h | 16 +++-
tools/perf/tests/builtin-test.c | 2 +-
tools/perf/tests/parse-events.c | 2 +-
tools/perf/util/evsel.c | 4 ++--
tools/perf/util/evsel.h | 2 +-
tools/perf/util/header.h| 2 +-
tools/perf/util/parse-events.c | 2 +-
tools/perf/util/parse-events.h | 2 +-
tools/perf/util/pmu.h | 2 +-
tools/perf/util/session.h | 2 +-
tools/scripts/Makefile.include | 23 ---
20 files changed, 115 insertions(+), 75 deletions(-)
create mode 100644 include/uapi/linux/hw_breakpoint.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 1/5] gpiolib: fix up function prototypes etc
On Wed, Nov 7, 2012 at 6:09 AM, Viresh Kumar wrote: > On 6 November 2012 20:46, Linus Walleij >> -void gpiochip_add_pin_range(struct gpio_chip *chip, const char >> *pinctl_name, >> - unsigned int pin_base, unsigned int npins); >> -void gpiochip_remove_pin_ranges(struct gpio_chip *chip); >> -#endif >> +#ifdef CONFIG_PINCTRL > > Shouldn't this be ifndef?? Probably, fixed up in later patches... Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] gpiolib: remove duplicate pin range code
On Wed, Nov 7, 2012 at 6:14 AM, viresh kumar wrote: > On Tue, Nov 6, 2012 at 8:46 PM, Linus Walleij > wrote: >> From: Linus Walleij >> >> Commit 69e1601bca88809dc118abd1becb02c15a02ec71 >> "gpiolib: provide provision to register pin ranges" >> >> Introduced both of_gpiochip_remove_pin_range() and >> gpiochip_remove_pin_ranges(). But the contents are exactly >> the same so remove the OF one and rely on the range deletion >> in the core. >> >> Signed-off-by: Linus Walleij > > I can't believe that i did this :( Don't worry, it's impossible to get these things right. I am trying to fix it properly here and just introduce new bugs for every fix I try to make. Maybe I'll soon have something that actually doesn't break x86... Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs
On 11/08/2012 01:29 PM, Grazvydas Ignotas wrote:
>> But I want to note that I'm currently trying to clean up the mess around
>> twl-core. In my view we have quite a bit of redundancy in there. The PWM A/B
>> is for driving the LED A/B outputs. We should have only these modules for
>> PWM/LED in twl-core:
>> TWL_MODULE_PWM - offset for PWM0ON register in twl4030 and PWM1ON for twl6030
>> TWL_MODULE_LED - offset for LEDEN register in twl4030 and LED_PWM_CTRL1
>> for twl6030
>>
>> From here the driver can figure out what to do IMHO.
>>
>> There's no need to have separate TWL 'modules' for:
>> TWL4030_BASEADD_PWM0
>> TWL4030_BASEADD_PWM1
>> TWL4030_BASEADD_PWMA
>> TWL4030_BASEADD_PWMB
>
> Well all these seem to come from TRM, no hard feelings here too but if
> you are going to remove them, probably worth adding a comment.
>From the 'outside' of twl4030 we have: LEDA, LEDB, PWM0 and PWM1 pins. This is
more important from system integration point of view than what name the TRM
calls the PWM (PWMA) behind of the LEDA terminal for example.
At the end in the board file you will have to use something like this:
static struct pwm_lookup zoom_pwm_lookup[] = {
PWM_LOOKUP("twl-pwm", 0, "leds_pwm", "zoom::keypad"), /* PWM0 */
PWM_LOOKUP("twl-pwm", 1, "pwm-backlight", "backlight"), /* PWM1 */
PWM_LOOKUP("twl-pwm-led", 0, "leds_pwm", "zoom::blinking"), /* LEDA */
};
I'll add comment to both the pwm-twl and pwm-twl-led driver for clarification.
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Documentation: Fix typo within Documentations
Correct spelling typo in Documentations --- Documentation/ABI/testing/dev-kmsg | 2 +- Documentation/ABI/testing/sysfs-devices-power | 2 +- Documentation/ABI/testing/sysfs-driver-ppi | 2 +- Documentation/dma-buf-sharing.txt | 4 ++-- Documentation/fault-injection/notifier-error-inject.txt | 4 ++-- Documentation/hid/uhid.txt | 2 +- Documentation/input/alps.txt| 2 +- Documentation/kbuild/modules.txt| 2 +- Documentation/misc-devices/mei/mei-amt-version.c| 4 ++-- Documentation/video4linux/bttv/Cards| 2 +- Documentation/vm/frontswap.txt | 2 +- 11 files changed, 14 insertions(+), 14 deletions(-) diff --git a/Documentation/ABI/testing/dev-kmsg b/Documentation/ABI/testing/dev-kmsg index 7e7e07a..bb820be 100644 --- a/Documentation/ABI/testing/dev-kmsg +++ b/Documentation/ABI/testing/dev-kmsg @@ -92,7 +92,7 @@ Description: The /dev/kmsg character device node provides userspace access The flags field carries '-' by default. A 'c' indicates a fragment of a line. All following fragments are flagged with '+'. Note, that these hints about continuation lines are not - neccessarily correct, and the stream could be interleaved with + necessarily correct, and the stream could be interleaved with unrelated messages, but merging the lines in the output usually produces better human readable results. A similar logic is used internally when messages are printed to the diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power index 7fc2997..9d43e76 100644 --- a/Documentation/ABI/testing/sysfs-devices-power +++ b/Documentation/ABI/testing/sysfs-devices-power @@ -164,7 +164,7 @@ Contact:Rafael J. Wysocki Description: The /sys/devices/.../wakeup_prevent_sleep_time_ms attribute contains the total time the device has been preventing - opportunistic transitions to sleep states from occuring. + opportunistic transitions to sleep states from occurring. This attribute is read-only. If the device is not enabled to wake up the system from sleep states, this attribute is not present. diff --git a/Documentation/ABI/testing/sysfs-driver-ppi b/Documentation/ABI/testing/sysfs-driver-ppi index 97a003e..7d1435b 100644 --- a/Documentation/ABI/testing/sysfs-driver-ppi +++ b/Documentation/ABI/testing/sysfs-driver-ppi @@ -5,7 +5,7 @@ Contact:xiaoyan.zh...@intel.com Description: This folder includes the attributes related with PPI (Physical Presence Interface). Only if TPM is supported by BIOS, this - folder makes sence. The folder path can be got by command + folder makes sense. The folder path can be got by command 'find /sys/ -name 'pcrs''. For the detail information of PPI, please refer to the PPI specification from http://www.trustedcomputinggroup.org/ diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index ad86fb8..0188903 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -376,7 +376,7 @@ Being able to mmap an export dma-buf buffer object has 2 main use-cases: leaving the cpu domain and flushing caches at fault time. Note that all the dma_buf files share the same anon inode, hence the exporter needs to replace the dma_buf file stored in vma->vm_file with it's own if pte shootdown is - requred. This is because the kernel uses the underlying inode's address_space + required. This is because the kernel uses the underlying inode's address_space for vma tracking (and hence pte tracking at shootdown time with unmap_mapping_range). @@ -388,7 +388,7 @@ Being able to mmap an export dma-buf buffer object has 2 main use-cases: Exporters that shoot down mappings (for any reasons) shall not do any synchronization at fault time with outstanding device operations. Synchronization is an orthogonal issue to sharing the backing storage of a - buffer and hence should not be handled by dma-buf itself. This is explictly + buffer and hence should not be handled by dma-buf itself. This is explicitly mentioned here because many people seem to want something like this, but if different exporters handle this differently, buffer sharing can fail in interesting ways depending upong the exporter (if userspace starts depending diff --git a/Documentation/fault-injection/notifier-error-inject.txt b/Documentation/fault-injection/notifier-error-inject.txt index c83526c..09adabe 100644 ---
Re: [PATCH] gpiolib: iron out include ladder mistakes
On Tue, Nov 6, 2012 at 10:40 PM, Stephen Warren wrote: > On 11/06/2012 09:21 AM, Linus Walleij wrote: >> And we need to keep the static inlines in >> but here for the !CONFIG_GENERIC_GPIO case, and then we >> may as well throw in a few warnings like the other >> prototypes there, if someone would have the bad taste >> of compiling without GENERIC_GPIO even. > > Hmm. Is there way to avoid the duplication of the dummy implementations? > Having a prototype and a truly dummy implementation in one place, but a > WARNing/failing dummy implementation elsewhere, seems like it'll cause > issues. Yeah :-/ This is not exactly elegant and is some side effect of the split between CONFIG_GENERIC_GPIO and CONFIG_GPIOLIB, the real fix is to get rid of all GENERIC_GPIO implementations in the kernel and switch everyone over to GPIOLIB. Not that easy though :-( can't think of any nice fix. > Does this patch mean the previous series causes "git bisect" failures? Yeah once I have something that doesn't break x86 I might just squash collapse all of this into the gpioranges patch. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT] HID
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus It reverts a patch that causes regression in binding between HID devices and drivers during device unplug/replug cycle. Thanks. Jiri Kosina (1): HID: hidraw: put old deallocation mechanism in place drivers/hid/hidraw.c | 69 +++--- 1 files changed, 43 insertions(+), 26 deletions(-) -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PT_EXITKILL (Was: pdeath_signal)
On 11/08/2012 12:44 PM, Oleg Nesterov wrote: > On 11/08, Pedro Alves wrote: >> If this isn't inherited by the ptrace child's children, a fork child can >> end up detached if the tracer dies before it had a chance of setting >> the PTRACE_O_EXITKILL on the new auto-attached child. > > It is copied like the other options. Oh, you're right. I got confused - GDB has code to always set options on the fork children after PTRACE_EVENT_(V)FORK. Dunno where that came from. >> Which sounds like another argument for PTRACE_O_INHERIT, as in: >> http://sourceware.org/ml/archer/2011-q1/msg00026.html > > The point of PTRACE_O_INHERIT would be to attach newly-created threads > and > children without causing an event stop and the attendant overhead. > > this is another thing, I guess. Yes, yes. -- Pedro Alves -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 00/26] pstore, mmc: add mmc as backend for pstore
From: Dragos Tatulea These patches enable using the mmc card to store panic information. They include changes for pstore and mmc: - add block device backend for pstore - add logic in mmc for writing in panic mode A mmc host driver must implement mmc_panic_ops. This patchset contains an implementation for sdhci. v2: - Added some detailed description to some commits. Not all of them though because they are very small and self explanatory. - Added clarification on what mmc host controller drivers have to implement to support panic dumping. Adrian Hunter (26): pstore: allow for big files pstore: add flags pstore: add flush blkoops: add a block device oops / panic logger block: add panic write mmc: block: add panic write support mmc: panic write: bypass host claiming mmc: panic write: bypass request completion mmc: panic write: suppress host not claimed warnings mmc: panic write: do not msleep mmc: panic write: bypass clock gating mmc: panic write: bypass regulators mmc: panic write: trap non panic tasks mmc: panic write: bypass bus ref locking mmc: sdhci: panic write: bypass spin lock mmc: sdhci: panic write: no sleeping mmc: sdhci: panic write: call tasklets inline mmc: sdhci: panic write: no timeout timer mmc: sdhci: panic write: no runtime pm mmc: sdhci: panic write: no tuning mmc: sdhci: panic write: poll interrupts mmc: sdhci: panic write: no dma mapping mmc: sdhci: panic write: resume suspended host mmc: sdhci: panic write: abort request in progress mmc: sdhci: panic write: trap nonpanic tasks mmc: sdhci-pci: add panic write support Documentation/blockdev/00-INDEX|2 + Documentation/blockdev/blkoops.txt | 104 +++ drivers/acpi/apei/erst.c | 16 +- drivers/block/Kconfig | 13 + drivers/block/Makefile |1 + drivers/block/blkoops.c| 1569 drivers/mmc/card/Kconfig | 11 + drivers/mmc/card/block.c | 257 +- drivers/mmc/core/core.c| 61 +- drivers/mmc/core/core.h|6 +- drivers/mmc/core/host.c| 11 + drivers/mmc/core/mmc.c |4 +- drivers/mmc/core/mmc_ops.c | 10 +- drivers/mmc/core/sd.c |4 +- drivers/mmc/core/sd_ops.c |2 +- drivers/mmc/core/sdio.c|4 +- drivers/mmc/core/sdio_irq.c|4 +- drivers/mmc/core/sdio_ops.c|2 +- drivers/mmc/host/sdhci-pci.c |5 + drivers/mmc/host/sdhci.c | 441 -- drivers/mmc/host/sdhci.h | 24 + fs/pstore/inode.c | 26 +- fs/pstore/internal.h |5 +- fs/pstore/platform.c | 23 +- fs/pstore/ram.c| 15 +- include/linux/blkdev.h | 77 ++ include/linux/genhd.h |3 + include/linux/mmc/host.h | 92 +++ include/linux/mmc/sdhci.h |9 + include/linux/pstore.h | 12 +- 30 files changed, 2690 insertions(+), 123 deletions(-) create mode 100644 Documentation/blockdev/blkoops.txt create mode 100644 drivers/block/blkoops.c -- 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 v2 03/26] pstore: add flush
From: Adrian Hunter
Let the back end know when writing has finished by adding a flush method.
Signed-off-by: Adrian Hunter
Signed-off-by: Irina Tirdea
---
fs/pstore/platform.c |3 +++
include/linux/pstore.h |1 +
2 files changed, 4 insertions(+)
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index b9ab942..97ae8a9 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -114,6 +114,9 @@ static void pstore_dump(struct kmsg_dumper *dumper,
why = get_reason_str(reason);
+ if (psinfo->flush)
+ psinfo->flush(psinfo);
+
if (in_nmi()) {
is_locked = spin_trylock(>buf_lock);
if (!is_locked)
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index 27f1995..3f93b4a 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -68,6 +68,7 @@ struct pstore_info {
struct pstore_info *psi);
int (*erase)(enum pstore_type_id type, u64 id,
struct pstore_info *psi);
+ int (*flush)(struct pstore_info *psi);
void*data;
};
--
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 v2 04/26] blkoops: add a block device oops / panic logger
From: Adrian Hunter blkoops is a pstore back end to write panic / oops logs to a block device. It is initially intended for use with eMMC as an alternative to using a crash kernel. Signed-off-by: Adrian Hunter Signed-off-by: Irina Tirdea --- Documentation/blockdev/00-INDEX|2 + Documentation/blockdev/blkoops.txt | 104 +++ drivers/block/Kconfig | 10 + drivers/block/Makefile |1 + drivers/block/blkoops.c| 1569 5 files changed, 1686 insertions(+) create mode 100644 Documentation/blockdev/blkoops.txt create mode 100644 drivers/block/blkoops.c diff --git a/Documentation/blockdev/00-INDEX b/Documentation/blockdev/00-INDEX index c08df56..c45cef8 100644 --- a/Documentation/blockdev/00-INDEX +++ b/Documentation/blockdev/00-INDEX @@ -2,6 +2,8 @@ - this file README.DAC960 - info on Mylex DAC960/DAC1100 PCI RAID Controller Driver for Linux. +blkoops.txt + - info on block device oops / panic logger cciss.txt - info, major/minor #'s for Compaq's SMART Array Controllers. cpqarray.txt diff --git a/Documentation/blockdev/blkoops.txt b/Documentation/blockdev/blkoops.txt new file mode 100644 index 000..fb08664 --- /dev/null +++ b/Documentation/blockdev/blkoops.txt @@ -0,0 +1,104 @@ +Block device oops / panic logger + + +Contents: + + 1) Overview + 2) Format + 3) Parameters + 4) blkoops and pstore + 5) debugfs + +1) Overview +--- + + blkoops is a pstore back end to write panic / oops logs to a block + device. It is initially intended for use with eMMC as an alternative to + using a crash kernel. + +2) Format +- + + Data is written in chunks called nodes which are preceded by a + header. The header is always aligned to a block boundary. Nodes are + written sequentially starting at the second block. The first block + contains a special node that fulfils 2 purposes: 1) the blkoops magic + number must be present or blkoops will not attach to the block device, + and 2) erase information is recorded there. Nodes can be arbitrarily + long. + + Nodes are identified by session number, file number and part number. + A session may have up to 2^32 - 1 files each with up to 2^32 - 1 parts. + + A new session begins when blkoops attaches to a block device and ends + when it detaches or there is a reboot. A new session overwrites the + previous session. Once the media is full no more nodes are written. + +3) Parameters +- + +devname + + Canonical block device name or number + + devname may be set on the kernel command line e.g. + + blkoops.devname=/dev/mmcblk0p7 + + or by writing to sysfs e.g. + + echo /dev/mmcblk0p1 > /sys/module/blkoops/parameters/devname + + devname is NOT the name of a file system object. e.g. /dev/mmcblk0p7 + does NOT mean the block device special file mmcblk0p7 in the /dev + directory. Instead it means partition 7 of the device named mmcblk0. + For more information see name_to_dev_t comment in init/do_mounts.c + + When devname is changed, the old devname (if any) is detached from + blkoops and the new devname (if any) is attached. + + blkoops will reject a block device that does not have the blkoops magic + number written on the 1st sector. For example, to prepare + /dev/mmcblk0p7 for blkoops: + + sudo bash -c "echo -e -n '\0034\0327\0130\0350' \ + | dd count=1 conv=sync \ + > /dev/mmcblk0p7" + +dump_oops + + set to 1 to dump oopses, 0 to dump only panics (default 1) + +4) blkoops and pstore +- + + pstore creates file names from pstore type code, back end name and + pstore 64-bit id. blkoops records the pstore type code, uses back end + name "blkoops", and creates the pstore 64-bit id from session number and + file number (session << 32 | file). blkoops concatenates all parts + together and presents them as one file. + + pstore noramally reads back end data entirely into memory when mounting. + However if a blkoops file is too big it will be read from media as + needed instead. + + blkoops suppreses pstore heading lines from dumped data. + + blkoops increases pstore default kmsg_bytes to ULONG_MAX. + +5) debugfs +-- + +blkoops/type + + pstore type code to use when dumping data via blkoops/data + +blkoops/reason + + kmsg dump reason code to use when dumping data via blkoops/data + +blkoops/data + + Data written to blkoops/data is dumped to the block device + using blkoops/type. blkoops/reason must be the numberical value of + KMSG_DUMP_PANIC or (if dump_oops is 1) KMSG_DUMP_OOPS. diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig index
[PATCH v2 11/26] mmc: panic write: bypass clock gating
From: Adrian Hunter
Signed-off-by: Adrian Hunter
Signed-off-by: Irina Tirdea
---
drivers/mmc/core/core.c |5 +
drivers/mmc/core/host.c |9 +
2 files changed, 14 insertions(+)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 204a9bd..f7552af 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -956,6 +956,11 @@ void mmc_set_ungated(struct mmc_host *host)
{
unsigned long flags;
+ if (mmc_am_panic_task(host)) {
+ host->clk_gated = false;
+ return;
+ }
+
/*
* We've been given a new frequency while the clock is gated,
* so make sure we regard this as ungating it.
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index ee2e16b..6eda5a1 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -153,6 +153,12 @@ void mmc_host_clk_hold(struct mmc_host *host)
{
unsigned long flags;
+ if (mmc_am_panic_task(host)) {
+ if (host->clk_gated)
+ mmc_ungate_clock(host);
+ return;
+ }
+
/* cancel any clock gating work scheduled by mmc_host_clk_release() */
cancel_delayed_work_sync(>clk_gate_work);
mutex_lock(>clk_gate_mutex);
@@ -200,6 +206,9 @@ void mmc_host_clk_release(struct mmc_host *host)
{
unsigned long flags;
+ if (mmc_am_panic_task(host))
+ return;
+
spin_lock_irqsave(>clk_lock, flags);
host->clk_requests--;
if (mmc_host_may_gate_card(host->card) &&
--
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 v2 16/26] mmc: sdhci: panic write: no sleeping
From: Adrian Hunter
Signed-off-by: Adrian Hunter
Signed-off-by: Irina Tirdea
---
drivers/mmc/host/sdhci.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1ed78f0..827e34f 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1536,6 +1536,14 @@ static int sdhci_check_ro(struct sdhci_host *host)
#define SAMPLE_COUNT 5
+static void sdhci_msleep(struct sdhci_host *host, unsigned int ms)
+{
+ if (mmc_am_panic_task(host->mmc))
+ mdelay(ms);
+ else
+ msleep(ms);
+}
+
static int sdhci_do_get_ro(struct sdhci_host *host)
{
int i, ro_count;
@@ -1549,7 +1557,7 @@ static int sdhci_do_get_ro(struct sdhci_host *host)
if (++ro_count > SAMPLE_COUNT / 2)
return 1;
}
- msleep(30);
+ sdhci_msleep(host, 30);
}
return 0;
}
@@ -1605,6 +1613,14 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc,
int enable)
sdhci_unlock_irqrestore(host, flags);
}
+#define sdhci_usleep_range(host, min, max) \
+do { \
+ if (mmc_am_panic_task((host)->mmc)) \
+ mdelay(DIV_ROUND_UP(min, 1000));\
+ else\
+ usleep_range(min, max); \
+} while (0)
+
static int sdhci_do_3_3v_signal_voltage_switch(struct sdhci_host *host,
u16 ctrl)
{
@@ -1623,7 +1639,7 @@ static int sdhci_do_3_3v_signal_voltage_switch(struct
sdhci_host *host,
}
}
/* Wait for 5ms */
- usleep_range(5000, 5500);
+ sdhci_usleep_range(host, 5000, 5500);
/* 3.3V regulator output should be stable within 5 ms */
ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
@@ -1668,7 +1684,7 @@ static int sdhci_do_1_8v_signal_voltage_switch(struct
sdhci_host *host,
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
/* Wait for 5ms */
- usleep_range(5000, 5500);
+ sdhci_usleep_range(host, 5000, 5500);
ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
if (ctrl & SDHCI_CTRL_VDD_180) {
@@ -1676,7 +1692,7 @@ static int sdhci_do_1_8v_signal_voltage_switch(struct
sdhci_host *host,
clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
clk |= SDHCI_CLOCK_CARD_EN;
sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
- usleep_range(1000, 1500);
+ sdhci_usleep_range(host, 1000, 1500);
/*
* If DAT[3:0] level is b, then the card
@@ -1703,7 +1719,7 @@ static int sdhci_do_1_8v_signal_voltage_switch(struct
sdhci_host *host,
regulator_disable(host->vmmc);
/* Wait for 1ms as per the spec */
- usleep_range(1000, 1500);
+ sdhci_usleep_range(host, 1000, 1500);
pwr |= SDHCI_POWER_ON;
sdhci_writeb(host, pwr, SDHCI_POWER_CONTROL);
if (host->vmmc)
--
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 v2 17/26] mmc: sdhci: panic write: call tasklets inline
From: Adrian Hunter
When in panic task, we need to schedule other tasklets than normally.
Signed-off-by: Adrian Hunter
Signed-off-by: Irina Tirdea
---
drivers/mmc/host/sdhci.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 827e34f..ff72e98 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -914,6 +914,17 @@ static void sdhci_set_transfer_mode(struct sdhci_host
*host,
sdhci_writew(host, mode, SDHCI_TRANSFER_MODE);
}
+static void sdhci_tasklet_card(unsigned long param);
+static void sdhci_tasklet_finish(unsigned long param);
+
+#define sdhci_sched_tasklet(host, name)\
+{ \
+ if (mmc_am_panic_task(host->mmc)) \
+ sdhci_tasklet_##name((unsigned long)host); \
+ else\
+ tasklet_schedule(>name##_tasklet);\
+}
+
static void sdhci_finish_data(struct sdhci_host *host)
{
struct mmc_data *data;
@@ -965,7 +976,7 @@ static void sdhci_finish_data(struct sdhci_host *host)
sdhci_send_command(host, data->stop);
} else
- tasklet_schedule(>finish_tasklet);
+ sdhci_sched_tasklet(host, finish);
}
static void sdhci_send_command(struct sdhci_host *host, struct mmc_command
*cmd)
@@ -994,7 +1005,7 @@ static void sdhci_send_command(struct sdhci_host *host,
struct mmc_command *cmd)
"inhibit bit(s).\n", mmc_hostname(host->mmc));
sdhci_dumpregs(host);
cmd->error = -EIO;
- tasklet_schedule(>finish_tasklet);
+ sdhci_sched_tasklet(host, finish);
return;
}
timeout--;
@@ -1015,7 +1026,7 @@ static void sdhci_send_command(struct sdhci_host *host,
struct mmc_command *cmd)
pr_err("%s: Unsupported response type!\n",
mmc_hostname(host->mmc));
cmd->error = -EINVAL;
- tasklet_schedule(>finish_tasklet);
+ sdhci_sched_tasklet(host, finish);
return;
}
@@ -1076,7 +1087,7 @@ static void sdhci_finish_command(struct sdhci_host *host)
sdhci_finish_data(host);
if (!host->cmd->data)
- tasklet_schedule(>finish_tasklet);
+ sdhci_sched_tasklet(host, finish);
host->cmd = NULL;
}
@@ -1303,7 +1314,7 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
if (!present || host->flags & SDHCI_DEVICE_DEAD) {
host->mrq->cmd->error = -ENOMEDIUM;
- tasklet_schedule(>finish_tasklet);
+ sdhci_sched_tasklet(host, finish);
} else {
u32 present_state;
@@ -2079,7 +2090,7 @@ static void sdhci_tasklet_card(unsigned long param)
sdhci_reset(host, SDHCI_RESET_DATA);
host->mrq->cmd->error = -ENOMEDIUM;
- tasklet_schedule(>finish_tasklet);
+ sdhci_sched_tasklet(host, finish);
}
sdhci_unlock_irqrestore(host, flags);
@@ -2174,7 +2185,7 @@ static void sdhci_timeout_timer(unsigned long data)
else
host->mrq->cmd->error = -ETIMEDOUT;
- tasklet_schedule(>finish_tasklet);
+ sdhci_sched_tasklet(host, finish);
}
}
@@ -2221,7 +2232,7 @@ static void sdhci_cmd_irq(struct sdhci_host *host, u32
intmask)
host->cmd->error = -EILSEQ;
if (host->cmd->error) {
- tasklet_schedule(>finish_tasklet);
+ sdhci_sched_tasklet(host, finish);
return;
}
@@ -2429,7 +2440,7 @@ again:
sdhci_writel(host, intmask & (SDHCI_INT_CARD_INSERT |
SDHCI_INT_CARD_REMOVE), SDHCI_INT_STATUS);
intmask &= ~(SDHCI_INT_CARD_INSERT | SDHCI_INT_CARD_REMOVE);
- tasklet_schedule(>card_tasklet);
+ sdhci_sched_tasklet(host, card);
}
if (intmask & SDHCI_INT_CMD_MASK) {
@@ -3192,7 +3203,7 @@ void sdhci_remove_host(struct sdhci_host *host, int dead)
" transfer!\n", mmc_hostname(host->mmc));
host->mrq->cmd->error = -ENOMEDIUM;
- tasklet_schedule(>finish_tasklet);
+ sdhci_sched_tasklet(host, finish);
}
sdhci_unlock_irqrestore(host, flags);
--
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
[PATCH v2 22/26] mmc: sdhci: panic write: no dma mapping
From: Adrian Hunter
Implement simple dma ops to avoid usage dma mapping in panic mode.
Init & cleanup pave the way for the dma ops implemented through
pre and post functions.
Signed-off-by: Adrian Hunter
Signed-off-by: Irina Tirdea
---
drivers/mmc/host/sdhci.c | 158 -
include/linux/mmc/sdhci.h |8 +++
2 files changed, 164 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index d85e9d5..ab3f5ce 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -649,6 +649,69 @@ static void sdhci_adma_table_post(struct sdhci_host *host,
data->sg_len, direction);
}
+#ifdef CONFIG_MMC_BLOCK_PANIC_WRITE
+
+static void sdhci_panic_dma_pre(struct sdhci_host *host, struct mmc_data *data)
+{
+ struct scatterlist *sg;
+ int i, len;
+ dma_addr_t addr;
+ u8 *desc;
+
+ if (host->flags & SDHCI_USE_ADMA) {
+ if (data->sg_len != 1) {
+ WARN_ON(1);
+ host->flags &= ~SDHCI_REQ_USE_DMA;
+ return;
+ }
+ desc = host->panic_adma_desc;
+ for_each_sg(data->sg, sg, 1, i) {
+ addr = host->panic_dma_addr;
+ len = sg->length;
+ sdhci_set_adma_desc(desc, addr, len, 0x21);
+ desc += 8;
+ }
+ if (host->quirks & SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC) {
+ if (desc != host->panic_adma_desc) {
+ desc -= 8;
+ desc[0] |= 0x2;
+ }
+ } else {
+ sdhci_set_adma_desc(desc, 0, 0, 0x3);
+ }
+ sdhci_writel(host, host->panic_adma_addr, SDHCI_ADMA_ADDRESS);
+ } else {
+ sdhci_writel(host, host->panic_dma_addr, SDHCI_DMA_ADDRESS);
+ }
+
+ if (data->flags & MMC_DATA_WRITE) {
+ sg_copy_to_buffer(data->sg, data->sg_len, host->panic_buf,
+ host->panic_bufsize);
+ }
+}
+
+static void sdhci_panic_dma_post(struct sdhci_host *host, struct mmc_data
*data)
+{
+ if (data->flags & MMC_DATA_READ) {
+ sg_copy_from_buffer(data->sg, data->sg_len, host->panic_buf,
+ host->panic_bufsize);
+ }
+}
+
+#else
+
+static inline void sdhci_panic_dma_pre(struct sdhci_host *host,
+ struct mmc_data *data)
+{
+}
+
+static inline void sdhci_panic_dma_post(struct sdhci_host *host,
+ struct mmc_data *data)
+{
+}
+
+#endif
+
static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command *cmd)
{
u8 count;
@@ -810,7 +873,9 @@ static void sdhci_prepare_data(struct sdhci_host *host,
struct mmc_command *cmd)
}
if (host->flags & SDHCI_REQ_USE_DMA) {
- if (host->flags & SDHCI_USE_ADMA) {
+ if (mmc_am_panic_task(host->mmc)) {
+ sdhci_panic_dma_pre(host, data);
+ } else if (host->flags & SDHCI_USE_ADMA) {
ret = sdhci_adma_table_pre(host, data);
if (ret) {
/*
@@ -937,7 +1002,9 @@ static void sdhci_finish_data(struct sdhci_host *host)
host->data = NULL;
if (host->flags & SDHCI_REQ_USE_DMA) {
- if (host->flags & SDHCI_USE_ADMA)
+ if (mmc_am_panic_task(host->mmc))
+ sdhci_panic_dma_post(host, data);
+ else if (host->flags & SDHCI_USE_ADMA)
sdhci_adma_table_post(host, data);
else {
dma_unmap_sg(mmc_dev(host->mmc), data->sg,
@@ -2045,6 +2112,91 @@ static const struct mmc_host_ops sdhci_ops = {
#ifdef CONFIG_MMC_BLOCK_PANIC_WRITE
+/*
+ * Arbitrary maximum DMA buffer size and hence maximum request size when using
+ * DMA.
+ */
+#define SDHCI_PANIC_DMA_BUFSIZE (32 * 1024)
+
+/*
+ * We DMA at most one segment which is aligned. Plus we need an end descriptor.
+ * We allow for a 8 byte (32-bit address) descriptor size.
+ */
+#define SDHCI_PANIC_ADMA_DESC_SZ ((1 + 1) * 12)
+
+static void sdhci_panic_dma_cleanup(struct sdhci_host *host)
+{
+ if (host->panic_adma_desc) {
+ dma_free_coherent(mmc_dev(host->mmc), SDHCI_PANIC_ADMA_DESC_SZ,
+ host->panic_adma_desc, host->panic_adma_addr);
+ host->panic_adma_desc = NULL;
+ }
+
+ if (host->panic_buf) {
+ dma_free_coherent(mmc_dev(host->mmc), host->panic_bufsize,
+ host->panic_buf, host->panic_dma_addr);
+ host->panic_buf = NULL;
+ }
+}
+
+static int sdhci_panic_dma_init(struct sdhci_host *host)
+{
+ size_t size;
+
+ size
[PATCH v2 23/26] mmc: sdhci: panic write: resume suspended host
From: Adrian Hunter
Resume host when entering panic mode.
Signed-off-by: Adrian Hunter
Signed-off-by: Irina Tirdea
---
drivers/mmc/host/sdhci.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index ab3f5ce..496adc8 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2231,6 +2231,10 @@ static void sdhci_panic_begin(struct mmc_host *mmc)
{
struct sdhci_host *host = mmc_priv(mmc);
+ if (host->runtime_suspended)
+ sdhci_runtime_resume_host(host);
+ else if (mmc->ios.vdd == 0)
+ sdhci_resume_host(host);
sdhci_writel(host, 0, SDHCI_SIGNAL_ENABLE);
}
@@ -2741,10 +2745,12 @@ int sdhci_resume_host(struct sdhci_host *host)
host->ops->enable_dma(host);
}
- ret = request_irq(host->irq, sdhci_irq, IRQF_SHARED,
- mmc_hostname(host->mmc), host);
- if (ret)
- return ret;
+ if (!mmc_am_panic_task(host->mmc)) {
+ ret = request_irq(host->irq, sdhci_irq, IRQF_SHARED,
+ mmc_hostname(host->mmc), host);
+ if (ret)
+ return ret;
+ }
if ((host->mmc->pm_flags & MMC_PM_KEEP_POWER) &&
(host->quirks2 & SDHCI_QUIRK2_HOST_OFF_CARD_ON)) {
--
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 v2 24/26] mmc: sdhci: panic write: abort request in progress
From: Adrian Hunter
Signed-off-by: Adrian Hunter
Signed-off-by: Irina Tirdea
---
drivers/mmc/host/sdhci.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 496adc8..9a24417 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1351,6 +1351,11 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
sdhci_lock_irqsave(host, flags);
+ if (mmc_am_panic_task(mmc) && host->mrq) {
+ host->mrq->cmd->error = -EILSEQ;
+ sdhci_sched_tasklet(host, finish);
+ }
+
WARN_ON(host->mrq != NULL);
#ifndef SDHCI_USE_LEDS_CLASS
--
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 v2 26/26] mmc: sdhci-pci: add panic write support
From: Adrian Hunter Signed-off-by: Adrian Hunter Signed-off-by: Irina Tirdea --- drivers/mmc/host/sdhci-pci.c |5 + 1 file changed, 5 insertions(+) diff --git a/drivers/mmc/host/sdhci-pci.c b/drivers/mmc/host/sdhci-pci.c index 4bb74b0..bee9a45 100644 --- a/drivers/mmc/host/sdhci-pci.c +++ b/drivers/mmc/host/sdhci-pci.c @@ -966,6 +966,8 @@ static void sdhci_pci_hw_reset(struct sdhci_host *host) if (!gpio_is_valid(rst_n_gpio)) return; + if (mmc_panic_task_active(host->mmc)) + return; gpio_set_value_cansleep(rst_n_gpio, 0); /* For eMMC, minimum is 1us but give it 10us for good measure */ udelay(10); @@ -1278,6 +1280,9 @@ static struct sdhci_pci_slot * __devinit sdhci_pci_probe_slot( } host->mmc->pm_caps = MMC_PM_KEEP_POWER | MMC_PM_WAKE_SDIO_IRQ; +#ifdef CONFIG_MMC_BLOCK_PANIC_WRITE + slot->host->mmc->caps2 = MMC_CAP_PANIC_WRITE; +#endif ret = sdhci_add_host(host); if (ret) -- 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 v2 25/26] mmc: sdhci: panic write: trap nonpanic tasks
From: Adrian Hunter
Signed-off-by: Adrian Hunter
Signed-off-by: Irina Tirdea
---
drivers/mmc/host/sdhci.c | 47 +
include/linux/mmc/sdhci.h |1 +
2 files changed, 44 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9a24417..db12fad 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2204,8 +2204,12 @@ static void sdhci_panic_cleanup(struct mmc_host *mmc)
void sdhci_lock(struct sdhci_host *host)
{
- if (mmc_am_panic_task(host->mmc))
- return;
+ if (mmc_panic_task_active(host->mmc)) {
+ if (mmc_am_panic_task(host->mmc))
+ return;
+ while (mmc_am_nonpanic_task(host->mmc))
+ cpu_relax();
+ }
spin_lock(>lock);
}
@@ -2219,8 +2223,12 @@ void _sdhci_lock_irqsave(struct sdhci_host *host,
unsigned long *flags_ptr)
{
unsigned long flags;
- if (mmc_am_panic_task(host->mmc))
- return;
+ if (mmc_panic_task_active(host->mmc)) {
+ if (mmc_am_panic_task(host->mmc))
+ return;
+ while (mmc_am_nonpanic_task(host->mmc))
+ cpu_relax();
+ }
spin_lock_irqsave(>lock, flags);
*flags_ptr = flags;
@@ -2235,6 +2243,16 @@ void sdhci_unlock_irqrestore(struct sdhci_host *host,
unsigned long flags)
static void sdhci_panic_begin(struct mmc_host *mmc)
{
struct sdhci_host *host = mmc_priv(mmc);
+ int i;
+
+ /* Wait a bit for other users to go away */
+ for (i = 0; i < 1; i++) {
+ if (spin_trylock(>lock)) {
+ host->locked = 1;
+ break;
+ }
+ udelay(1);
+ }
if (host->runtime_suspended)
sdhci_runtime_resume_host(host);
@@ -2250,6 +2268,10 @@ static void sdhci_panic_end(struct mmc_host *mmc)
ier = sdhci_readl(host, SDHCI_INT_ENABLE);
sdhci_writel(host, ier, SDHCI_SIGNAL_ENABLE);
+ if (host->locked) {
+ host->locked = 0;
+ spin_unlock(>lock);
+ }
}
static const struct mmc_panic_ops sdhci_pops = {
@@ -2368,6 +2390,9 @@ static void sdhci_timeout_timer(unsigned long data)
host = (struct sdhci_host*)data;
+ if (mmc_am_nonpanic_task(host->mmc))
+ return;
+
sdhci_lock_irqsave(host, flags);
if (host->mrq) {
@@ -2399,6 +2424,9 @@ static void sdhci_tuning_timer(unsigned long data)
host = (struct sdhci_host *)data;
+ if (mmc_am_nonpanic_task(host->mmc))
+ return;
+
sdhci_lock_irqsave(host, flags);
host->flags |= SDHCI_NEEDS_RETUNING;
@@ -2596,6 +2624,9 @@ static irqreturn_t sdhci_irq(int irq, void *dev_id)
u32 intmask, unexpected = 0;
int cardint = 0, max_loops = 16;
+ if (mmc_am_nonpanic_task(host->mmc))
+ return IRQ_HANDLED;
+
sdhci_lock(host);
@@ -2713,6 +2744,8 @@ int sdhci_suspend_host(struct sdhci_host *host)
if (host->ops->platform_suspend)
host->ops->platform_suspend(host);
+ mmc_trap_nonpanic_tasks(host->mmc);
+
sdhci_disable_card_detection(host);
/* Disable tuning since we are suspending */
@@ -2745,6 +2778,8 @@ int sdhci_resume_host(struct sdhci_host *host)
{
int ret;
+ mmc_trap_nonpanic_tasks(host->mmc);
+
if (host->flags & (SDHCI_USE_SDMA | SDHCI_USE_ADMA)) {
if (host->ops->enable_dma)
host->ops->enable_dma(host);
@@ -2820,6 +2855,8 @@ int sdhci_runtime_suspend_host(struct sdhci_host *host)
unsigned long flags;
int ret = 0;
+ mmc_trap_nonpanic_tasks(host->mmc);
+
/* Disable tuning since we are suspending */
if (host->flags & SDHCI_USING_RETUNING_TIMER) {
del_timer_sync(>tuning_timer);
@@ -2845,6 +2882,8 @@ int sdhci_runtime_resume_host(struct sdhci_host *host)
unsigned long flags;
int ret = 0, host_flags = host->flags;
+ mmc_trap_nonpanic_tasks(host->mmc);
+
if (host_flags & (SDHCI_USE_SDMA | SDHCI_USE_ADMA)) {
if (host->ops->enable_dma)
host->ops->enable_dma(host);
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index 873e41d..13cc598 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -173,6 +173,7 @@ struct sdhci_host {
struct timer_list tuning_timer; /* Timer for tuning */
#ifdef CONFIG_MMC_BLOCK_PANIC_WRITE
+ int locked; /* panic task has the lock */
void*panic_buf; /* buffer for panic requests */
size_t panic_bufsize; /* panic buffer size */
dma_addr_t panic_dma_addr; /* panic buffer dma address
[PATCH v2 21/26] mmc: sdhci: panic write: poll interrupts
From: Adrian Hunter
We really don't want to use interrupts while doing a panic dump, so
implement polling.
The mmc panic begin/end ops have also been added for sdhci.
Signed-off-by: Adrian Hunter
Signed-off-by: Irina Tirdea
---
drivers/mmc/host/sdhci.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index e096526..d85e9d5 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -131,6 +131,8 @@ static void sdhci_clear_set_irqs(struct sdhci_host *host,
u32 clear, u32 set)
ier &= ~clear;
ier |= set;
sdhci_writel(host, ier, SDHCI_INT_ENABLE);
+ if (mmc_panic_task_active(host->mmc))
+ ier = 0;
sdhci_writel(host, ier, SDHCI_SIGNAL_ENABLE);
}
@@ -1267,6 +1269,8 @@ static int sdhci_set_power(struct sdhci_host *host,
unsigned short power)
* *
\*/
+static irqreturn_t sdhci_irq(int irq, void *dev_id);
+
static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)
{
struct sdhci_host *host;
@@ -1347,6 +1351,11 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
mmiowb();
sdhci_unlock_irqrestore(host, flags);
+
+ if (mmc_am_panic_task(host->mmc)) {
+ while (host->mrq)
+ sdhci_irq(0, host);
+ }
}
static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
@@ -2066,6 +2075,27 @@ void sdhci_unlock_irqrestore(struct sdhci_host *host,
unsigned long flags)
spin_unlock_irqrestore(>lock, flags);
}
+static void sdhci_panic_begin(struct mmc_host *mmc)
+{
+ struct sdhci_host *host = mmc_priv(mmc);
+
+ sdhci_writel(host, 0, SDHCI_SIGNAL_ENABLE);
+}
+
+static void sdhci_panic_end(struct mmc_host *mmc)
+{
+ struct sdhci_host *host = mmc_priv(mmc);
+ u32 ier;
+
+ ier = sdhci_readl(host, SDHCI_INT_ENABLE);
+ sdhci_writel(host, ier, SDHCI_SIGNAL_ENABLE);
+}
+
+static const struct mmc_panic_ops sdhci_pops = {
+ .begin = sdhci_panic_begin,
+ .end= sdhci_panic_end,
+};
+
#endif
/*\
@@ -2854,6 +2884,9 @@ int sdhci_add_host(struct sdhci_host *host)
* Set host parameters.
*/
mmc->ops = _ops;
+#ifdef CONFIG_MMC_BLOCK_PANIC_WRITE
+ mmc->pops = _pops;
+#endif
mmc->f_max = host->max_clk;
if (host->ops->get_min_clock)
mmc->f_min = host->ops->get_min_clock(host);
--
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 v2 14/26] mmc: panic write: bypass bus ref locking
From: Adrian Hunter
We want to avoid it while panic dumping.
Signed-off-by: Adrian Hunter
Signed-off-by: Irina Tirdea
---
drivers/mmc/core/core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 4fd7061..3daec19 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1418,6 +1418,11 @@ static inline void mmc_bus_get(struct mmc_host *host)
{
unsigned long flags;
+ if (mmc_am_panic_task(host)) {
+ host->bus_refs++;
+ return;
+ }
+
spin_lock_irqsave(>lock, flags);
host->bus_refs++;
spin_unlock_irqrestore(>lock, flags);
@@ -1431,6 +1436,11 @@ static inline void mmc_bus_put(struct mmc_host *host)
{
unsigned long flags;
+ if (mmc_am_panic_task(host)) {
+ host->bus_refs--;
+ return;
+ }
+
spin_lock_irqsave(>lock, flags);
host->bus_refs--;
if ((host->bus_refs == 0) && host->bus_ops)
--
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 v2 13/26] mmc: panic write: trap non panic tasks
From: Adrian Hunter
If in panic, wait for task to come into context.
Signed-off-by: Adrian Hunter
Signed-off-by: Irina Tirdea
---
drivers/mmc/core/core.c | 10 +-
drivers/mmc/core/host.c |2 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index d3caa7e..4fd7061 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -252,6 +252,7 @@ mmc_start_request(struct mmc_host *host, struct mmc_request
*mrq)
}
mmc_host_clk_hold(host);
led_trigger_event(host->led, LED_FULL);
+ mmc_trap_nonpanic_tasks(host);
host->ops->request(host, mrq);
}
@@ -344,8 +345,10 @@ static void mmc_wait_for_req_done(struct mmc_host *host,
while (1) {
/* Panic task requests must be completed in ->request() */
- if (!mmc_am_panic_task(host))
+ if (!mmc_am_panic_task(host)) {
wait_for_completion(>completion);
+ mmc_trap_nonpanic_tasks(host);
+ }
cmd = mrq->cmd;
if (!cmd->error || !cmd->retries ||
@@ -774,6 +777,8 @@ int __mmc_claim_host(struct mmc_host *host, atomic_t *abort)
if (mmc_am_panic_task(host))
return 0;
+ else
+ mmc_trap_nonpanic_tasks(host);
might_sleep();
@@ -817,6 +822,8 @@ int mmc_try_claim_host(struct mmc_host *host)
if (mmc_am_panic_task(host))
return 1;
+ else
+ mmc_trap_nonpanic_tasks(host);
spin_lock_irqsave(>lock, flags);
if (!host->claimed || host->claimer == current) {
@@ -880,6 +887,7 @@ static inline void mmc_set_ios(struct mmc_host *host)
if (ios->clock > 0)
mmc_set_ungated(host);
+ mmc_trap_nonpanic_tasks(host);
host->ops->set_ios(host, ios);
}
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 6eda5a1..b76bfc8 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -90,6 +90,8 @@ static void mmc_host_clk_gate_delayed(struct mmc_host *host)
unsigned long freq = host->ios.clock;
unsigned long flags;
+ mmc_trap_nonpanic_tasks(host);
+
if (!freq) {
pr_debug("%s: frequency set to 0 in disable function, "
"this means the clock is already disabled.\n",
--
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 v2 19/26] mmc: sdhci: panic write: no runtime pm
From: Adrian Hunter
Signed-off-by: Adrian Hunter
Signed-off-by: Irina Tirdea
---
drivers/mmc/host/sdhci.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 3653494..fcedcec 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2601,11 +2601,17 @@ EXPORT_SYMBOL_GPL(sdhci_enable_irq_wakeups);
static int sdhci_runtime_pm_get(struct sdhci_host *host)
{
+ if (mmc_am_panic_task(host->mmc))
+ return 0;
+
return pm_runtime_get_sync(host->mmc->parent);
}
static int sdhci_runtime_pm_put(struct sdhci_host *host)
{
+ if (mmc_am_panic_task(host->mmc))
+ return 0;
+
pm_runtime_mark_last_busy(host->mmc->parent);
return pm_runtime_put_autosuspend(host->mmc->parent);
}
--
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 v2 20/26] mmc: sdhci: panic write: no tuning
From: Adrian Hunter Signed-off-by: Adrian Hunter Signed-off-by: Irina Tirdea --- drivers/mmc/host/sdhci.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index fcedcec..e096526 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -1794,6 +1794,10 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode) int err = 0; bool requires_tuning_nonuhs = false; + /* Tuning may need a timer so it is not supported by the panic task */ + if (mmc_am_panic_task(mmc)) + return -EINVAL; + host = mmc_priv(mmc); sdhci_runtime_pm_get(host); -- 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/
