[PATCH 3/6] perf, x86: Save/resotre LBR stack during context switch
From: "Yan, Zheng"
When the LBR call stack is enabled, it is necessary to save/restore
the stack on context switch. The solution is saving/restoring the
stack to/from task's perf event context. If task has no perf event
context, just flush the stack on context switch.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.c | 18 +++--
arch/x86/kernel/cpu/perf_event.h | 14 +++-
arch/x86/kernel/cpu/perf_event_intel.c | 13 +---
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 115 ++---
include/linux/perf_event.h | 6 +-
kernel/events/core.c | 64 +---
6 files changed, 176 insertions(+), 54 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 3361114..119687d 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1606,6 +1606,13 @@ static int x86_pmu_event_idx(struct perf_event *event)
return idx + 1;
}
+static void x86_pmu_branch_stack_sched(struct perf_event_context *ctx,
+ bool sched_in)
+{
+ if (x86_pmu.branch_stack_sched)
+ x86_pmu.branch_stack_sched(ctx, sched_in);
+}
+
static void *x86_pmu_event_context_alloc(struct perf_event_context *parent_ctx)
{
struct perf_event_context *ctx;
@@ -1614,6 +1621,9 @@ static void *x86_pmu_event_context_alloc(struct
perf_event_context *parent_ctx)
if (!ctx)
return ERR_PTR(-ENOMEM);
+ if (parent_ctx)
+ intel_pmu_lbr_init_context(ctx, parent_ctx);
+
return ctx;
}
@@ -1673,12 +1683,6 @@ static const struct attribute_group
*x86_pmu_attr_groups[] = {
NULL,
};
-static void x86_pmu_flush_branch_stack(void)
-{
- if (x86_pmu.flush_branch_stack)
- x86_pmu.flush_branch_stack();
-}
-
void perf_check_microcode(void)
{
if (x86_pmu.check_microcode)
@@ -1705,7 +1709,7 @@ static struct pmu pmu = {
.commit_txn = x86_pmu_commit_txn,
.event_idx = x86_pmu_event_idx,
- .flush_branch_stack = x86_pmu_flush_branch_stack,
+ .branch_stack_sched = x86_pmu_branch_stack_sched,
.event_context_alloc= x86_pmu_event_context_alloc,
};
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 97fc4b0..cd96109 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -369,7 +369,6 @@ struct x86_pmu {
void(*cpu_dead)(int cpu);
void(*check_microcode)(void);
- void(*flush_branch_stack)(void);
/*
* Intel Arch Perfmon v2+
@@ -399,6 +398,8 @@ struct x86_pmu {
int lbr_nr;/* hardware stack size */
u64 lbr_sel_mask; /* LBR_SELECT valid bits */
const int *lbr_sel_map; /* lbr_select mappings */
+ void(*branch_stack_sched)(struct perf_event_context *ctx,
+ bool sched_in);
/*
* Extra registers for events
@@ -414,6 +415,13 @@ struct x86_pmu {
struct x86_perf_event_context {
struct perf_event_context ctx;
+
+ u64 lbr_from[MAX_LBR_ENTRIES];
+ u64 lbr_to[MAX_LBR_ENTRIES];
+ u64 lbr_callstack_gen;
+ int lbr_callstack_users;
+ bool lbr_callstack_saved;
+
};
#define x86_add_quirk(func_) \
@@ -615,8 +623,12 @@ void intel_pmu_pebs_disable_all(void);
void intel_ds_init(void);
+void intel_pmu_lbr_init_context(struct perf_event_context *child_ctx,
+ struct perf_event_context *parent_ctx);
void intel_pmu_lbr_reset(void);
+void intel_pmu_lbr_sched(struct perf_event_context *ctx, bool sched_in);
+
void intel_pmu_lbr_enable(struct perf_event *event);
void intel_pmu_lbr_disable(struct perf_event *event);
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/arch/x86/kernel/cpu/perf_event_intel.c
index 3e59612..8a804d9 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -1803,16 +1803,11 @@ static void intel_pmu_cpu_dying(int cpu)
fini_debug_store_on_cpu(cpu);
}
-static void intel_pmu_flush_branch_stack(void)
+static void intel_pmu_branch_stack_sched(struct perf_event_context *ctx,
+bool sched_in)
{
- /*
-* Intel LBR does not tag entries with the
-* PID of the current task, then we need to
-* flush it on ctxsw
-* For now, we simply reset it
-*/
if (x86_pmu.lbr_nr)
- intel_pmu_lbr_reset();
+ intel_pmu_lbr_sched(ctx, sched_in);
}
PMU_FORMAT_ATTR(offcore_rsp, "config1:0-63");
@@ -1877,7 +1872,7 @@ static __initconst const struct x86_pmu intel_pmu = {
[PATCH 5/6] perf, x86: Use LBR call stack to get user callchain
From: "Yan, Zheng"
Try enabling the LBR call stack feature if event request recording
callchain. Try utilizing the LBR call stack to get user callchain
in case of there is no frame pointer.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.c | 126 +
arch/x86/kernel/cpu/perf_event.h | 7 ++
arch/x86/kernel/cpu/perf_event_intel.c | 20 ++---
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 3 +
include/linux/perf_event.h | 6 ++
kernel/events/core.c | 11 ++-
6 files changed, 124 insertions(+), 49 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 8ae8044..3bf2100 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -398,35 +398,46 @@ int x86_pmu_hw_config(struct perf_event *event)
if (event->attr.precise_ip > precise)
return -EOPNOTSUPP;
- /*
-* check that PEBS LBR correction does not conflict with
-* whatever the user is asking with attr->branch_sample_type
-*/
- if (event->attr.precise_ip > 1 && x86_pmu.intel_cap.pebs_format
< 2) {
- u64 *br_type = >attr.branch_sample_type;
-
- if (has_branch_stack(event)) {
- if (!precise_br_compat(event))
- return -EOPNOTSUPP;
-
- /* branch_sample_type is compatible */
-
- } else {
- /*
-* user did not specify branch_sample_type
-*
-* For PEBS fixups, we capture all
-* the branches at the priv level of the
-* event.
-*/
- *br_type = PERF_SAMPLE_BRANCH_ANY;
-
- if (!event->attr.exclude_user)
- *br_type |= PERF_SAMPLE_BRANCH_USER;
-
- if (!event->attr.exclude_kernel)
- *br_type |= PERF_SAMPLE_BRANCH_KERNEL;
- }
+ }
+ /*
+* check that PEBS LBR correction does not conflict with
+* whatever the user is asking with attr->branch_sample_type
+*/
+ if (event->attr.precise_ip > 1 && x86_pmu.intel_cap.pebs_format < 2) {
+ u64 *br_type = >attr.branch_sample_type;
+
+ if (has_branch_stack(event)) {
+ if (!precise_br_compat(event))
+ return -EOPNOTSUPP;
+
+ /* branch_sample_type is compatible */
+
+ } else {
+ /*
+* user did not specify branch_sample_type
+*
+* For PEBS fixups, we capture all
+* the branches at the priv level of the
+* event.
+*/
+ *br_type = PERF_SAMPLE_BRANCH_ANY;
+
+ if (!event->attr.exclude_user)
+ *br_type |= PERF_SAMPLE_BRANCH_USER;
+
+ if (!event->attr.exclude_kernel)
+ *br_type |= PERF_SAMPLE_BRANCH_KERNEL;
+ }
+ } else if (event->attr.sample_type & PERF_SAMPLE_CALLCHAIN) {
+ if (!has_branch_stack(event) && x86_pmu.attr_lbr_callstack) {
+ /*
+* user did not specify branch_sample_type,
+* try using the LBR call stack facility to
+* record call chains in the user space.
+*/
+ event->attr.branch_sample_type =
+ PERF_SAMPLE_BRANCH_USER |
+ PERF_SAMPLE_BRANCH_CALL_STACK;
}
}
@@ -1663,12 +1674,35 @@ static ssize_t set_attr_rdpmc(struct device *cdev,
return count;
}
+static ssize_t get_attr_lbr_callstack(struct device *cdev,
+ struct device_attribute *attr, char *buf)
+{
+ return snprintf(buf, 40, "%d\n", x86_pmu.attr_lbr_callstack);
+}
+
+static ssize_t set_attr_lbr_callstack(struct device *cdev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ unsigned long val = simple_strtoul(buf, NULL, 0);
+
+ if (x86_pmu.attr_lbr_callstack != !!val) {
+ if (val && !x86_pmu_has_lbr_callstack())
+ return -EOPNOTSUPP;
+ x86_pmu.attr_lbr_callstack = !!val;
+ }
+ return count;
+}
+
static DEVICE_ATTR(rdpmc,
[PATCH 2/6] perf, x86: Introduce x86 special perf event context
From: "Yan, Zheng"
The x86 special perf event context is named x86_perf_event_context,
We can enlarge it later to store PMU special data.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.c | 12
arch/x86/kernel/cpu/perf_event.h | 4
include/linux/perf_event.h | 5 +
kernel/events/core.c | 28 ++--
4 files changed, 39 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 08e61a6..3361114 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1606,6 +1606,17 @@ static int x86_pmu_event_idx(struct perf_event *event)
return idx + 1;
}
+static void *x86_pmu_event_context_alloc(struct perf_event_context *parent_ctx)
+{
+ struct perf_event_context *ctx;
+
+ ctx = kzalloc(sizeof(struct x86_perf_event_context), GFP_KERNEL);
+ if (!ctx)
+ return ERR_PTR(-ENOMEM);
+
+ return ctx;
+}
+
static ssize_t get_attr_rdpmc(struct device *cdev,
struct device_attribute *attr,
char *buf)
@@ -1695,6 +1706,7 @@ static struct pmu pmu = {
.event_idx = x86_pmu_event_idx,
.flush_branch_stack = x86_pmu_flush_branch_stack,
+ .event_context_alloc= x86_pmu_event_context_alloc,
};
void arch_perf_update_userpage(struct perf_event_mmap_page *userpg, u64 now)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 370df32..97fc4b0 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -412,6 +412,10 @@ struct x86_pmu {
struct perf_guest_switch_msr *(*guest_get_msrs)(int *nr);
};
+struct x86_perf_event_context {
+ struct perf_event_context ctx;
+};
+
#define x86_add_quirk(func_) \
do { \
static struct x86_pmu_quirk __quirk __initdata = { \
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 7e6a4b6..2868fcf 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -264,6 +264,11 @@ struct pmu {
* flush branch stack on context-switches (needed in cpu-wide mode)
*/
void (*flush_branch_stack) (void);
+
+ /*
+* Allocate PMU special perf event context
+*/
+ void *(*event_context_alloc)(struct perf_event_context *parent_ctx);
};
/**
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 534810d..c886018 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2721,13 +2721,20 @@ static void __perf_event_init_context(struct
perf_event_context *ctx)
}
static struct perf_event_context *
-alloc_perf_context(struct pmu *pmu, struct task_struct *task)
+alloc_perf_context(struct pmu *pmu, struct task_struct *task,
+ struct perf_event_context *parent_ctx)
{
struct perf_event_context *ctx;
- ctx = kzalloc(sizeof(struct perf_event_context), GFP_KERNEL);
- if (!ctx)
- return NULL;
+ if (pmu->event_context_alloc) {
+ ctx = pmu->event_context_alloc(parent_ctx);
+ if (IS_ERR(ctx))
+ return ctx;
+ } else {
+ ctx = kzalloc(sizeof(struct perf_event_context), GFP_KERNEL);
+ if (!ctx)
+ return ERR_PTR(-ENOMEM);
+ }
__perf_event_init_context(ctx);
if (task) {
@@ -2813,10 +2820,11 @@ retry:
++ctx->pin_count;
raw_spin_unlock_irqrestore(>lock, flags);
} else {
- ctx = alloc_perf_context(pmu, task);
- err = -ENOMEM;
- if (!ctx)
+ ctx = alloc_perf_context(pmu, task, NULL);
+ if (IS_ERR(ctx)) {
+ err = PTR_ERR(ctx);
goto errout;
+ }
err = 0;
mutex_lock(>perf_event_mutex);
@@ -7132,9 +7140,9 @@ inherit_task_group(struct perf_event *event, struct
task_struct *parent,
* child.
*/
- child_ctx = alloc_perf_context(event->pmu, child);
- if (!child_ctx)
- return -ENOMEM;
+ child_ctx = alloc_perf_context(event->pmu, child, parent_ctx);
+ if (IS_ERR(child_ctx))
+ return PTR_ERR(child_ctx);
child->perf_event_ctxp[ctxn] = child_ctx;
}
--
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/
[PATCH 0/6] perf, x86: Haswell LBR call stack support
From: "Yan, Zheng" Haswell has a new feature that utilizes the existing Last Branch Record facility to record call chains. When the feature is enabled, function call will be collected as normal, but as return instructions are executed the last captured branch record is popped from the on-chip LBR registers. The LBR call stack facility can help perf to get call chains of progam without frame pointer. The LBR call stack has following known limitations 1. Zero length calls are not filtered out by hardware 2. Exception handing such as setjmp/longjmp will have calls/returns not match 3. Pushing different return address onto the stack will have calls/returns not match The patch series depends on Andi's "perf PMU support for Haswel" patches Regards Yan, Zheng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 6/6] perf, x86: Discard zero length call entries in LBR call stack
From: "Yan, Zheng"
Zero length calls may confuse the hardware and make the recorded
call stack incorrect. Try fixing the call stack by discarding
zero length call entries.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index c6efec1..9eee5d9 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -90,7 +90,8 @@ enum {
X86_BR_ABORT= 1 << 12,/* transaction abort */
X86_BR_INTX = 1 << 13,/* in transaction */
X86_BR_NOTX = 1 << 14,/* not in transaction */
- X86_BR_CALL_STACK = 1 << 15,/* call stack */
+ X86_BR_ZERO_CALL= 1 << 15,/* zero length call */
+ X86_BR_CALL_STACK = 1 << 16,/* call stack */
};
#define X86_BR_PLM (X86_BR_USER | X86_BR_KERNEL)
@@ -107,13 +108,15 @@ enum {
X86_BR_JMP |\
X86_BR_IRQ |\
X86_BR_ABORT|\
-X86_BR_IND_CALL)
+X86_BR_IND_CALL |\
+X86_BR_ZERO_CALL)
#define X86_BR_ALL (X86_BR_PLM | X86_BR_ANY)
#define X86_BR_ANY_CALL \
(X86_BR_CALL|\
X86_BR_IND_CALL|\
+X86_BR_ZERO_CALL |\
X86_BR_SYSCALL |\
X86_BR_IRQ |\
X86_BR_INT)
@@ -636,6 +639,12 @@ static int branch_type(unsigned long from, unsigned long
to, int abort)
ret = X86_BR_INT;
break;
case 0xe8: /* call near rel */
+ insn_get_immediate();
+ if (insn.immediate1.value == 0) {
+ /* zero length call */
+ ret = X86_BR_ZERO_CALL;
+ break;
+ }
case 0x9a: /* call far absolute */
ret = X86_BR_CALL;
break;
--
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/
[PATCH 4/6] perf, core: Pass perf_sample_data to perf_callchain()
From: "Yan, Zheng"
New Intel CPU can record call chains by using existing last branch
record facility. perf_callchain_user() can make use of the call
chains recorded by hardware in case of there is no frame pointer.
Signed-off-by: Yan, Zheng
---
arch/arm/kernel/perf_event.c | 4 ++--
arch/powerpc/perf/callchain.c| 4 ++--
arch/sparc/kernel/perf_event.c | 4 ++--
arch/x86/kernel/cpu/perf_event.c | 4 ++--
include/linux/perf_event.h | 3 ++-
kernel/events/callchain.c| 8 +---
kernel/events/core.c | 2 +-
kernel/events/internal.h | 3 ++-
8 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 93971b1..7cd3eba 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -567,8 +567,8 @@ user_backtrace(struct frame_tail __user *tail,
return buftail.fp - 1;
}
-void
-perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
+void perf_callchain_user(struct perf_callchain_entry *entry,
+struct pt_regs *regs, struct perf_sample_data *data)
{
struct frame_tail __user *tail;
diff --git a/arch/powerpc/perf/callchain.c b/arch/powerpc/perf/callchain.c
index 74d1e78..b379ebc 100644
--- a/arch/powerpc/perf/callchain.c
+++ b/arch/powerpc/perf/callchain.c
@@ -482,8 +482,8 @@ static void perf_callchain_user_32(struct
perf_callchain_entry *entry,
}
}
-void
-perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
+void perf_callchain_user(struct perf_callchain_entry *entry,
+struct pt_regs *regs, struct perf_sample_data *data)
{
if (current_is_64bit())
perf_callchain_user_64(entry, regs);
diff --git a/arch/sparc/kernel/perf_event.c b/arch/sparc/kernel/perf_event.c
index 885a8af..6e9c62c 100644
--- a/arch/sparc/kernel/perf_event.c
+++ b/arch/sparc/kernel/perf_event.c
@@ -1775,8 +1775,8 @@ static void perf_callchain_user_32(struct
perf_callchain_entry *entry,
} while (entry->nr < PERF_MAX_STACK_DEPTH);
}
-void
-perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
+void perf_callchain_user(struct perf_callchain_entry *entry,
+struct pt_regs *regs, struct perf_sample_data *data)
{
perf_callchain_store(entry, regs->tpc);
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 119687d..8ae8044 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1839,8 +1839,8 @@ perf_callchain_user32(struct pt_regs *regs, struct
perf_callchain_entry *entry)
}
#endif
-void
-perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
+void perf_callchain_user(struct perf_callchain_entry *entry,
+struct pt_regs *regs, struct perf_sample_data *data)
{
struct stack_frame frame;
const void __user *fp;
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 9151bdd..803b511 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -706,7 +706,8 @@ extern void perf_event_fork(struct task_struct *tsk);
/* Callchains */
DECLARE_PER_CPU(struct perf_callchain_entry, perf_callchain_entry);
-extern void perf_callchain_user(struct perf_callchain_entry *entry, struct
pt_regs *regs);
+extern void perf_callchain_user(struct perf_callchain_entry *entry, struct
pt_regs *regs,
+ struct perf_sample_data *data);
extern void perf_callchain_kernel(struct perf_callchain_entry *entry, struct
pt_regs *regs);
static inline void perf_callchain_store(struct perf_callchain_entry *entry,
u64 ip)
diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
index c772061..bd7138a 100644
--- a/kernel/events/callchain.c
+++ b/kernel/events/callchain.c
@@ -30,7 +30,8 @@ __weak void perf_callchain_kernel(struct perf_callchain_entry
*entry,
}
__weak void perf_callchain_user(struct perf_callchain_entry *entry,
- struct pt_regs *regs)
+ struct pt_regs *regs,
+ struct perf_sample_data *data)
{
}
@@ -154,7 +155,8 @@ put_callchain_entry(int rctx)
}
struct perf_callchain_entry *
-perf_callchain(struct perf_event *event, struct pt_regs *regs)
+perf_callchain(struct perf_event *event, struct pt_regs *regs,
+ struct perf_sample_data *data)
{
int rctx;
struct perf_callchain_entry *entry;
@@ -195,7 +197,7 @@ perf_callchain(struct perf_event *event, struct pt_regs
*regs)
goto exit_put;
perf_callchain_store(entry, PERF_CONTEXT_USER);
- perf_callchain_user(entry, regs);
+ perf_callchain_user(entry, regs, data);
}
}
diff --git a/kernel/events/core.c
[PATCH 1/6] perf, x86: Basic Haswell LBR call stack support
From: "Yan, Zheng"
The new HSW call stack feature provides a facility such that
unfiltered call data will be collected as normal, but as return
instructions are executed the last captured branch record is
popped from the LBR stack. Thus, branch information relative to
leaf functions will not be captured, while preserving the call
stack information of the main line execution path.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.h | 2 +
arch/x86/kernel/cpu/perf_event_intel.c | 2 +-
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 91 ++
include/uapi/linux/perf_event.h| 3 +-
4 files changed, 74 insertions(+), 24 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index d3b3bb7..370df32 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -631,6 +631,8 @@ void intel_pmu_lbr_init_atom(void);
void intel_pmu_lbr_init_snb(void);
+void intel_pmu_lbr_init_hsw(void);
+
int intel_pmu_setup_lbr_filter(struct perf_event *event);
int p4_pmu_init(void);
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/arch/x86/kernel/cpu/perf_event_intel.c
index a734b6a..3e59612 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -2349,7 +2349,7 @@ __init int intel_pmu_init(void)
memcpy(hw_cache_event_ids, snb_hw_cache_event_ids,
sizeof(hw_cache_event_ids));
- intel_pmu_lbr_init_nhm();
+ intel_pmu_lbr_init_hsw();
x86_pmu.event_constraints = intel_hsw_event_constraints;
x86_pmu.pebs_constraints = intel_hsw_pebs_event_constraints;
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index 31fe046..99f64fe 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -31,6 +31,7 @@ enum {
#define LBR_IND_JMP_BIT6 /* do not capture indirect jumps */
#define LBR_REL_JMP_BIT7 /* do not capture relative jumps */
#define LBR_FAR_BIT8 /* do not capture far branches */
+#define LBR_CALL_STACK_BIT 9 /* enable call stack */
#define LBR_KERNEL (1 << LBR_KERNEL_BIT)
#define LBR_USER (1 << LBR_USER_BIT)
@@ -41,6 +42,7 @@ enum {
#define LBR_REL_JMP(1 << LBR_REL_JMP_BIT)
#define LBR_IND_JMP(1 << LBR_IND_JMP_BIT)
#define LBR_FAR(1 << LBR_FAR_BIT)
+#define LBR_CALL_STACK (1 << LBR_CALL_STACK_BIT)
#define LBR_PLM (LBR_KERNEL | LBR_USER)
@@ -70,24 +72,25 @@ enum {
* x86control flow changes include branches, interrupts, traps, faults
*/
enum {
- X86_BR_NONE = 0, /* unknown */
-
- X86_BR_USER = 1 << 0, /* branch target is user */
- X86_BR_KERNEL = 1 << 1, /* branch target is kernel */
-
- X86_BR_CALL = 1 << 2, /* call */
- X86_BR_RET = 1 << 3, /* return */
- X86_BR_SYSCALL = 1 << 4, /* syscall */
- X86_BR_SYSRET = 1 << 5, /* syscall return */
- X86_BR_INT = 1 << 6, /* sw interrupt */
- X86_BR_IRET = 1 << 7, /* return from interrupt */
- X86_BR_JCC = 1 << 8, /* conditional */
- X86_BR_JMP = 1 << 9, /* jump */
- X86_BR_IRQ = 1 << 10,/* hw interrupt or trap or fault */
- X86_BR_IND_CALL = 1 << 11,/* indirect calls */
- X86_BR_ABORT= 1 << 12,/* transaction abort */
- X86_BR_INTX = 1 << 13,/* in transaction */
- X86_BR_NOTX = 1 << 14,/* not in transaction */
+ X86_BR_NONE = 0, /* unknown */
+
+ X86_BR_USER = 1 << 0, /* branch target is user */
+ X86_BR_KERNEL = 1 << 1, /* branch target is kernel */
+
+ X86_BR_CALL = 1 << 2, /* call */
+ X86_BR_RET = 1 << 3, /* return */
+ X86_BR_SYSCALL = 1 << 4, /* syscall */
+ X86_BR_SYSRET = 1 << 5, /* syscall return */
+ X86_BR_INT = 1 << 6, /* sw interrupt */
+ X86_BR_IRET = 1 << 7, /* return from interrupt */
+ X86_BR_JCC = 1 << 8, /* conditional */
+ X86_BR_JMP = 1 << 9, /* jump */
+ X86_BR_IRQ = 1 << 10,/* hw interrupt or trap or fault */
+ X86_BR_IND_CALL = 1 << 11,/* indirect calls */
+ X86_BR_ABORT= 1 << 12,/* transaction abort */
+ X86_BR_INTX = 1 << 13,/* in transaction */
+ X86_BR_NOTX = 1 << 14,/* not in transaction */
+ X86_BR_CALL_STACK = 1 << 15,/* call stack */
};
#define X86_BR_PLM (X86_BR_USER | X86_BR_KERNEL)
@@ -131,7 +134,10 @@ static void __intel_pmu_lbr_enable(void)
wrmsrl(MSR_LBR_SELECT, cpuc->lbr_sel->config);
rdmsrl(MSR_IA32_DEBUGCTLMSR, debugctl);
- debugctl |= (DEBUGCTLMSR_LBR | DEBUGCTLMSR_FREEZE_LBRS_ON_PMI);
RE: [RFC PATCH v3 00/16] DMA Engine support for AM33XX
On Fri, Oct 19, 2012 at 22:16:15, Porter, Matt wrote:
> On Fri, Oct 19, 2012 at 12:02:42PM +, Bedia, Vaibhav wrote:
> > On Fri, Oct 19, 2012 at 16:45:58, Porter, Matt wrote:
> > > On Fri, Oct 19, 2012 at 10:26:20AM +, Bedia, Vaibhav wrote:
> > [...]
> > > >
> > > > I didn't see all the patches that you posted on edma-dmaengine-v3
> > > > but I do seem them on edma-dmaengine-am33xx-v3 branch.
> > >
> > > I see I referenced the wrong branch in the cover letter. Thanks for
> > > testing and noticing this. Sorry to make you hunt for the correct
> > > branch in that repo. ;)
> > >
> >
> > No problem.
> >
> > > https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v3
> > > is indeed the correct branch for those wanting to pull this in or
> > > grab some of the not-to-be-merged drivers I used for testing.
> > >
> > > > I added a couple of patches to enable earlyprintk and build the DTB
> > > > appended kernel image uImage-dtb.am335x-evm
> > > >
> > > > Here's what i see
> > > >
> > > > [...]
> > >
> > >
> > >
> > > > [0.175354] edma: probe of 4900.edma failed with error -16
> > >
> > > I missed an uninitialized pdata case in the bug fixes mentioned in
> > > the changelog and the folks previously failing the same way didn't
> > > hit the case I suspect you are hitting. Can you try this and let me
> > > know how it works?
> > >
> >
> > That doesn't help :(
>
> Ok, so I dumped my Linaro toolchain which was masking this issue that
> you got unlucky with on EVM, whereas I was lucky. Switching toolchains I
> was able to reproduce the problem. Pantelis Antoniou suggested some
> changes and the following fixes this issue for me...verified on both
> BeagleBone and EVM. Let me know if that works on your end and I'll
> incorporate some version of it in the next update.
Heh I would not have suspected the toolchain so early ;)
>
> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> index b761b7a..6ed394f 100644
> --- a/arch/arm/common/edma.c
> +++ b/arch/arm/common/edma.c
> @@ -1598,6 +1598,8 @@ static struct of_dma_filter_info edma_filter_info = {
> static int __init edma_probe(struct platform_device *pdev)
> {
> struct edma_soc_info**info = pdev->dev.platform_data;
> + struct edma_soc_info*ninfo[EDMA_MAX_CC] = {NULL, NULL};
> + struct edma_soc_infotmpinfo;
> s8 (*queue_priority_mapping)[2];
> s8 (*queue_tc_mapping)[2];
> int i, j, off, ln, found = 0;
> @@ -1614,15 +1616,13 @@ static int __init edma_probe(struct platform_device
> *pdev)
> charirq_name[10];
> struct device_node *node = pdev->dev.of_node;
> struct device *dev = >dev;
> - struct edma_soc_info*pdata;
> int ret;
>
> if (node) {
> - pdata = devm_kzalloc(dev,
> - sizeof(struct edma_soc_info),
> - GFP_KERNEL);
> - edma_of_parse_dt(dev, node, pdata);
> - info =
> + info = ninfo;
> + edma_of_parse_dt(dev, node, );
> + info[0] =
> +
> dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap);
> of_dma_controller_register(dev->of_node,
> of_dma_simple_xlate,
>
With the above diff, the kernel boots fine on the EVM.
> > Looking at the original crash log, I suspect something is not correct
> > with the irq portion, probably in the DT or the driver.
> >
> > "genirq: Flags mismatch irq 28. (edma) vs. (edma)"
> >
> > The warning below that is coming due to fail case in edma_probe not tracking
> > the request_irq status properly and but IMO that's a separate issue.
>
> It is a separate issue, indeed. My ideal goal was to avoid changing
> anything in this existing davinci dma implementation, that's why the
> error paths were unmodified. Since I'm having to rework a few more things
> I'll look at those and generate an improved version.
>
> Russ Dill also made some good simplification/cleanup suggestions for the
> of parsing on irc which I'll incorporate in the next version.
Ok, sounds good.
Regards,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] vlan: set sysfs device_type to 'vlan'
Sets the sysfs device_type to 'vlan' for udev. This makes it easier for
applications that query network information via udev to identify vlans
instead of using strrchr().
Signed-off-by: Doug Goldstein
---
Pre-patch output:
swanson ~ # udevadm info -q all -p /sys/devices/virtual/net/br0.4
P: /devices/virtual/net/br0.4
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/net/br0.4
E: INTERFACE=br0.4
E: IFINDEX=6
E: SUBSYSTEM=net
Post-patch output:
swanson ~ # udevadm info -q all -p /sys/devices/virtual/net/br0.4
P: /devices/virtual/net/br0.4
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/net/br0.4
E: DEVTYPE=vlan
E: INTERFACE=br0.4
E: IFINDEX=12
E: SUBSYSTEM=net
The intent was to match other virtual network types such as bridges.
swanson ~ # udevadm info -q all -p /sys/devices/virtual/net/br0
P: /devices/virtual/net/br0
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/net/br0
E: DEVTYPE=bridge
E: INTERFACE=br0
E: IFINDEX=5
E: SUBSYSTEM=net
---
net/8021q/vlan_dev.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 4024424..78a8744 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -531,6 +531,10 @@ static const struct header_ops vlan_header_ops = {
.parse = eth_header_parse,
};
+static struct device_type vlan_type = {
+ .name = "vlan",
+};
+
static const struct net_device_ops vlan_netdev_ops;
static int vlan_dev_init(struct net_device *dev)
@@ -579,6 +583,8 @@ static int vlan_dev_init(struct net_device *dev)
dev->netdev_ops = _netdev_ops;
+ SET_NETDEV_DEVTYPE(dev, _type);
+
if (is_vlan_dev(real_dev))
subclass = 1;
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] char_dev: pin parent kobject
On Mon, Oct 22, 2012 at 08:02:12AM +0300, Linus Torvalds wrote: > This series looks good to me, and looks to fix the issue about as > cleanly as it can. Al, holler if you have any concerns, but I'm > planning on applying it ASAP, Add my ACKed-by. And from the look of it, we'll need something similar at least in drivers/mtd/ubi in addition to evdev patch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] backlight: ili9320: add missing SPI dependency
This patch adds this missing SPI dependency and prevents the driver from buiding without SPI, because funtion of spi driver is used in this driver. So, it fixes link error as belows: drivers/video/backlight/ili9320.c:51: undefined reference to `spi_sync' Also, prompt string for CONFIG_LCD_ILI9320 is added for explicit selection. Signed-off-by: Jingoo Han Cc: Richard Purdie Cc: Ben Dooks --- Changes since v1: - commit log is modified to be more specific. drivers/video/backlight/Kconfig |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig index c101697..765a945 100644 --- a/drivers/video/backlight/Kconfig +++ b/drivers/video/backlight/Kconfig @@ -60,7 +60,8 @@ config LCD_LTV350QV The LTV350QV panel is present on all ATSTK1000 boards. config LCD_ILI9320 - tristate + tristate "ILI Technology ILI9320 controller support" + depends on SPI help If you have a panel based on the ILI9320 controller chip then say y to include a power driver for it. -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: process hangs on do_exit when oom happens
On Mon, Oct 22, 2012 at 7:46 AM, Qiang Gao wrote: > I don't know whether the process will exit finally, bug this stack lasts > for hours, which is obviously unnormal. > The situation: we use a command calld "cglimit" to fork-and-exec the worker > process,and the "cglimit" will > set some limitation on the worker with cgroup. for now,we limit the > memory,and we also use cpu cgroup,but with > no limiation,so when the worker is running, the cgroup directory looks like > following: > > /cgroup/memory/worker : this directory limit the memory > /cgroup/cpu/worker :with no limit,but worker process is in. > > for some reason(some other process we didn't consider), the worker process > invoke global oom-killer, > not cgroup-oom-killer. then the worker process hangs there. > > Actually, if we didn't set the worker process into the cpu cgroup, this will > never happens. > You said you don't use CPU limits right? can you also send in the output of /proc/sched_debug. Can you also send in your /etc/cgconfig.conf? If the OOM is not caused by cgroup memory limit and the global system is under pressure in 2.6.32, it can trigger an OOM. Also 1. Have you turned off swapping (seems like it) right? 2. Do you have a NUMA policy setup for this task? Can you also share the .config (not sure if any special patches are being used) in the version you've mentioned. Balbir -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Staging: ced1401: fix missing unlock on error in FreeCircBlock()
From: Wei Yongjun Add the missing unlock on the error handle path in function FreeCircBlock(). Signed-off-by: Wei Yongjun --- drivers/staging/ced1401/ced_ioc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/ced1401/ced_ioc.c b/drivers/staging/ced1401/ced_ioc.c index c9492ed..5813aee 100644 --- a/drivers/staging/ced1401/ced_ioc.c +++ b/drivers/staging/ced1401/ced_ioc.c @@ -1508,7 +1508,7 @@ int FreeCircBlock(DEVICE_EXTENSION * pdx, TCIRCBLOCK __user * pCB) iReturn = U14ERR_BADAREA; if (copy_to_user(pCB, , sizeof(cb))) - return -EFAULT; + iReturn = -EFAULT; mutex_unlock(>io_mutex); return iReturn; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Staging: vt6655: fix missing unlock on error in vCommandTimer()
From: Wei Yongjun
Add the missing unlock on the error handle path in function
vCommandTimer.
Signed-off-by: Wei Yongjun
---
drivers/staging/vt6655/wcmd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/vt6655/wcmd.c b/drivers/staging/vt6655/wcmd.c
index 94bd1fc..6d0b87a 100644
--- a/drivers/staging/vt6655/wcmd.c
+++ b/drivers/staging/vt6655/wcmd.c
@@ -412,6 +412,7 @@ vCommandTimer (
if (!is_channel_valid(pMgmt->uScanChannel)) {
DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO "Invalid channel
pMgmt->uScanChannel = %d \n",pMgmt->uScanChannel);
s_bCommandComplete(pDevice);
+spin_unlock_irq(>lock);
return;
}
//printk("chester-pMgmt->uScanChannel=%d,pDevice->byMaxChannel=%d\n",pMgmt->uScanChannel,pDevice->byMaxChannel);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] char_dev: pin parent kobject
This series looks good to me, and looks to fix the issue about as cleanly as it can. Al, holler if you have any concerns, but I'm planning on applying it ASAP, Linus On Mon, Oct 22, 2012 at 3:57 AM, Dmitry Torokhov wrote: > In certain cases (for example when a cdev structure is embedded into > another object whose lifetime is controlled by a separate kobject) it is > beneficial to tie lifetime of another object to the lifetime of character > device so that related object is not freed until after char_dev object is > freed. To achieve this let's pin kobject's parent when doing cdev_add() > and unpin when last reference to cdev structure is being released. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pinctrl: fix missing unlock on error in pinctrl_groups_show()
From: Wei Yongjun
Add the missing unlock on the error handle path in function
pinctrl_groups_show().
Signed-off-by: Wei Yongjun
---
drivers/pinctrl/core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 0f1ec9e..2e39c04 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1061,8 +1061,10 @@ static int pinctrl_groups_show(struct seq_file *s, void
*what)
seq_printf(s, "group: %s\n", gname);
for (i = 0; i < num_pins; i++) {
pname = pin_get_name(pctldev, pins[i]);
- if (WARN_ON(!pname))
+ if (WARN_ON(!pname)) {
+ mutex_unlock(_mutex);
return -EINVAL;
+ }
seq_printf(s, "pin %d (%s)\n", pins[i], pname);
}
seq_puts(s, "\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND][PATCH] prctl: update seccomp sections for mode 2 (BPF)
Hello Kees, On Fri, Sep 21, 2012 at 1:37 AM, Kees Cook wrote: > This adds a short summary of the arguments used for "mode 2" (BPF) > seccomp. Thanks very much. Applied. Cheers, Michael > Signed-off-by: Kees Cook > --- > man2/prctl.2 | 40 ++-- > 1 files changed, 30 insertions(+), 10 deletions(-) > > diff --git a/man2/prctl.2 b/man2/prctl.2 > index eb53aa8..a44aa32 100644 > --- a/man2/prctl.2 > +++ b/man2/prctl.2 > @@ -41,11 +41,12 @@ > .\" 2012-04 Cyrill Gorcunov, Document PR_SET_MM > .\" 2012-04-25 Michael Kerrisk, Document PR_TASK_PERF_EVENTS_DISABLE and > .\"PR_TASK_PERF_EVENTS_ENABLE > +.\" 2012-09-20 Kees Cook, update PR_SET_SECCOMP for mode 2 > .\" > .\" FIXME: Document PR_SET_TIMERSLACK and PR_GET_TIMERSLACK (new in 2.6.28) > .\"commit 6976675d94042fbd446231d1bd8b7de71a980ada > .\" > -.TH PRCTL 2 2012-04-23 "Linux" "Linux Programmer's Manual" > +.TH PRCTL 2 2012-09-20 "Linux" "Linux Programmer's Manual" > .SH NAME > prctl \- operations on a process > .SH SYNOPSIS > @@ -235,11 +236,17 @@ in the location pointed to by > .\" See http://thread.gmane.org/gmane.linux.kernel/542632 > .\" [PATCH 0 of 2] seccomp updates > .\" and...@cpushare.com > -Set the secure computing mode for the calling thread. > -In the current implementation, > +Set the secure computing mode for the calling thread, to limit > +the available syscalls. > +The seccomp mode is selected via > +.IR arg2 . > +(The seccomp constants are defined in > +.IR .) > + > +With > .IR arg2 > -must be 1. > -After the secure computing mode has been set to 1, > +set to > +.BR SECCOMP_MODE_STRICT > the only system calls that the thread is permitted to make are > .BR read (2), > .BR write (2), > @@ -249,22 +256,35 @@ and > Other system calls result in the delivery of a > .BR SIGKILL > signal. > -Secure computing mode is useful for number-crunching applications > +Strict secure computing mode is useful for number-crunching applications > that may need to execute untrusted byte code, > perhaps obtained by reading from a pipe or socket. > This operation is only available > if the kernel is configured with CONFIG_SECCOMP enabled. > + > +With > +.IR arg2 > +set to > +.BR SECCOMP_MODE_FILTER " (since Linux 3.5)" > +the system calls allowed are > +defined by a pointer passed in > +.IR arg3 > +to a Berkeley Packet Filter, which can be designed to filter > +arbitrary syscalls and syscall arguments. > +This mode is only available if the kernel is configured with > +CONFIG_SECCOMP_FILTER enabled. > + > .TP > .BR PR_GET_SECCOMP " (since Linux 2.6.23)" > Return the secure computing mode of the calling thread. > -Not very useful for the current implementation (mode equals 1), > -but may be useful for other possible future modes: > -if the caller is not in secure computing mode, this operation returns 0; > -if the caller is in secure computing mode, then the > +If the caller is not in secure computing mode, this operation returns 0; > +if the caller is in strict secure computing mode, then the > .BR prctl () > call will cause a > .B SIGKILL > signal to be sent to the process. > +If the caller is in filter mode, and this syscall is allowed by the > +seccomp filters, it returns 2. > This operation is only available > if the kernel is configured with CONFIG_SECCOMP enabled. > .TP > -- > 1.7.0.4 > > -- > Kees Cook > Chrome OS Security -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface"; http://man7.org/tlpi/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: PCI: fix missing unlock on error
From: Wei Yongjun
Add the missing unlock on the error handle path in function
nanoengine_read_config() and nanoengine_write_config().
Signed-off-by: Wei Yongjun
---
arch/arm/mach-sa1100/pci-nanoengine.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-sa1100/pci-nanoengine.c
b/arch/arm/mach-sa1100/pci-nanoengine.c
index ff02e2d..6ff07d7 100644
--- a/arch/arm/mach-sa1100/pci-nanoengine.c
+++ b/arch/arm/mach-sa1100/pci-nanoengine.c
@@ -67,8 +67,10 @@ static int nanoengine_read_config(struct pci_bus *bus,
unsigned int devfn, int w
spin_lock_irqsave(_lock, flags);
ret = nanoengine_get_pci_address(bus, devfn, where, );
- if (ret != PCIBIOS_SUCCESSFUL)
+ if (ret != PCIBIOS_SUCCESSFUL) {
+ spin_unlock_irqrestore(_lock, flags);
return ret;
+ }
v = __raw_readl(address);
spin_unlock_irqrestore(_lock, flags);
@@ -95,8 +97,10 @@ static int nanoengine_write_config(struct pci_bus *bus,
unsigned int devfn, int
spin_lock_irqsave(_lock, flags);
ret = nanoengine_get_pci_address(bus, devfn, where, );
- if (ret != PCIBIOS_SUCCESSFUL)
+ if (ret != PCIBIOS_SUCCESSFUL) {
+ spin_unlock_irqrestore(_lock, flags);
return ret;
+ }
v = __raw_readl(address);
switch (size) {
case 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] usb:musb: Dequeue urbs on device unplug
> -Original Message- > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Monday, October 15, 2012 5:49 PM > To: Virupax SADASHIVPETIMATH > Cc: ba...@ti.com; st...@rowland.harvard.edu; linux-...@vger.kernel.org; > linux-kernel@vger.kernel.org; linus.wall...@linaro.org; Rajaram REGUPATHY; > Praveena NADAHALLY > Subject: Re: [PATCH] usb:musb: Dequeue urbs on device unplug > > Hi, > > On Wed, Oct 10, 2012 at 10:06:03AM +0530, Virupax Sadashivpetimath wrote: > > Flush queued urbs on receiving device disconnect interrupt. This is > > required for successful disconnect and successive enumeration of the > > device. > > > > In a failure case khubd hangs on usb-storage thread for completion. > > Seen in the below trace. > > > > [ 1355.764526] SysRq : Show Blocked State > > [ 1355.768341] taskPC stack pid father > > [ 1355.773620] khubd D c06a1fbc 0 503 2 0x > > [ 1355.780151] [] (__schedule+0x3f0/0x8ec) from [] > > (schedule+0x58/0x70) [ 1355.788330] [] (schedule+0x58/0x70) > > from [] (schedule_timeout+0x1d8/0x31c) [ 1355.796997] > > [] (schedule_timeout+0x1d8/0x31c) from [] > > (wait_for_common+0xd8/0x180) [ 1355.806396] [] > > (wait_for_common+0xd8/0x180) from [] > > (wait_for_completion+0x20/0x24) [ 1355.815887] [] > I would like to get some Tested-bys here. Can you please add Tested-by: Thanks Virupax S -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: PCI: fix missing unlock on error
From: Wei Yongjun
Add the missing unlock on the error handle path in function
nanoengine_read_config() and nanoengine_write_config().
Signed-off-by: Wei Yongjun
---
arch/arm/mach-sa1100/pci-nanoengine.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-sa1100/pci-nanoengine.c
b/arch/arm/mach-sa1100/pci-nanoengine.c
index ff02e2d..6ff07d7 100644
--- a/arch/arm/mach-sa1100/pci-nanoengine.c
+++ b/arch/arm/mach-sa1100/pci-nanoengine.c
@@ -67,8 +67,10 @@ static int nanoengine_read_config(struct pci_bus *bus,
unsigned int devfn, int w
spin_lock_irqsave(_lock, flags);
ret = nanoengine_get_pci_address(bus, devfn, where, );
- if (ret != PCIBIOS_SUCCESSFUL)
+ if (ret != PCIBIOS_SUCCESSFUL) {
+ spin_unlock_irqrestore(_lock, flags);
return ret;
+ }
v = __raw_readl(address);
spin_unlock_irqrestore(_lock, flags);
@@ -95,8 +97,10 @@ static int nanoengine_write_config(struct pci_bus *bus,
unsigned int devfn, int
spin_lock_irqsave(_lock, flags);
ret = nanoengine_get_pci_address(bus, devfn, where, );
- if (ret != PCIBIOS_SUCCESSFUL)
+ if (ret != PCIBIOS_SUCCESSFUL) {
+ spin_unlock_irqrestore(_lock, flags);
return ret;
+ }
v = __raw_readl(address);
switch (size) {
case 1:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] TTY: hvcs: fix missing unlock on error in hvcs_initialize()
From: Wei Yongjun
Add the missing unlock on the error handling path in function
hvcs_initialize().
Signed-off-by: Wei Yongjun
---
drivers/tty/hvc/hvcs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c
index cab5c7a..744c3b8 100644
--- a/drivers/tty/hvc/hvcs.c
+++ b/drivers/tty/hvc/hvcs.c
@@ -1496,8 +1496,10 @@ static int __devinit hvcs_initialize(void)
num_ttys_to_alloc = hvcs_parm_num_devs;
hvcs_tty_driver = alloc_tty_driver(num_ttys_to_alloc);
- if (!hvcs_tty_driver)
+ if (!hvcs_tty_driver) {
+ mutex_unlock(_init_mutex);
return -ENOMEM;
+ }
if (hvcs_alloc_index_list(num_ttys_to_alloc)) {
rc = -ENOMEM;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Oct 22
Hi all, Changes since 201201019: The xtensa tree gained a conflict against Linus' tree. The wireless-next tree gained conflicts against the wireless tree. The modules tree gained a conflict against Linus' tree. The tip tree lost its conflicts and build fixes. The akpm tree lost some patches that turned up in Linus' tree. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 204 trees (counting Linus' and 26 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (6f0c058 Linux 3.7-rc2) Merging fixes/master (12250d8 Merge branch 'i2c-embedded/for-next' of git://git.pengutronix.de/git/wsa/linux) Merging kbuild-current/rc-fixes (b1e0d8b kbuild: Fix gcc -x syntax) Merging arm-current/fixes (3d6ee36 Merge branch 'late-for-linus' of git://git.linaro.org/people/rmk/linux-arm) Merging m68k-current/for-linus (8a745ee m68k: Wire up kcmp) Merging powerpc-merge/merge (83dac59 cpuidle/powerpc: Fix snooze state problem in the cpuidle design on pseries.) Merging sparc/master (43c422e apparmor: fix apparmor OOPS in audit_log_untrustedstring+0x1c/0x40) Merging net/master (db0fe0b Merge tag 'batman-adv-fix-for-davem' of git://git.open-mesh.org/linux-merge) Merging sound-current/for-linus (edb6689 ALSA: sound/isa/opti9xx/miro.c: eliminate possible double free) Merging pci-current/for-linus (0ff9514 PCI: Don't print anything while decoding is disabled) Merging wireless/master (290eddc Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211) Merging driver-core.current/driver-core-linus (ddffeb8 Linux 3.7-rc1) Merging tty.current/tty-linus (178e485 staging: dgrp: check return value of alloc_tty_driver) Merging usb.current/usb-linus (4b35f1c USB: option: add more ZTE devices) Merging staging.current/staging-linus (47c15308 Merge tag 'iio-fixes-for-3.7a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus) Merging char-misc.current/char-misc-linus (ddffeb8 Linux 3.7-rc1) Merging input-current/for-linus (0cc8d6a Merge branch 'next' into for-linus) Merging md-current/for-linus (72f36d5 md: refine reporting of resync/reshape delays.) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (c9f97a2 crypto: x86/glue_helper - fix storing of new IV in CBC encryption) Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops) Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs formatting) Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for of_parse_phandle_with_args) Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using proper "spi:" modalias prefixes.) Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, remove cast) Merging asm-generic/master (c37d615 Merge branch 'disintegrate-asm-generic' of git://git.infradead.org/users/dhowells/linux-headers into asm-generic) Merging arm/for-next (ef4e305 ARM: mm: use bitmap
Re: process hangs on do_exit when oom happens
I don't know whether the process will exit finally, bug this stack lasts for hours, which is obviously unnormal. The situation: we use a command calld "cglimit" to fork-and-exec the worker process,and the "cglimit" will set some limitation on the worker with cgroup. for now,we limit the memory,and we also use cpu cgroup,but with no limiation,so when the worker is running, the cgroup directory looks like following: /cgroup/memory/worker : this directory limit the memory /cgroup/cpu/worker :with no limit,but worker process is in. for some reason(some other process we didn't consider), the worker process invoke global oom-killer, not cgroup-oom-killer. then the worker process hangs there. Actually, if we didn't set the worker process into the cpu cgroup, this will never happens. On Sat, Oct 20, 2012 at 12:04 AM, Michal Hocko wrote: > > On Wed 17-10-12 18:23:34, gaoqiang wrote: > > I looked up nothing useful with google,so I'm here for help.. > > > > when this happens: I use memcg to limit the memory use of a > > process,and when the memcg cgroup was out of memory, > > the process was oom-killed however,it cannot really complete the > > exiting. here is the some information > > How many tasks are in the group and what kind of memory do they use? > Is it possible that you were hit by the same issue as described in > 79dfdacc memcg: make oom_lock 0 and 1 based rather than counter. > > > OS version: centos6.22.6.32.220.7.1 > > Your kernel is quite old and you should be probably asking your > distribution to help you out. There were many fixes since 2.6.32. > Are you able to reproduce the same issue with the current vanila kernel? > > > /proc/pid/stack > > --- > > > > [] __cond_resched+0x2a/0x40 > > [] unmap_vmas+0xb49/0xb70 > > [] exit_mmap+0x7e/0x140 > > [] mmput+0x58/0x110 > > [] exit_mm+0x11d/0x160 > > [] do_exit+0x1ad/0x860 > > [] do_group_exit+0x41/0xb0 > > [] get_signal_to_deliver+0x1e8/0x430 > > [] do_notify_resume+0xf4/0x8b0 > > [] int_signal+0x12/0x17 > > [] 0x > > This looks strange because this is just an exit part which shouldn't > deadlock or anything. Is this stack stable? Have you tried to take check > it more times? > > -- > 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/
[PATCH] regulator: max77686: Make max77686_enable() static.
This patch fixes a sparse warning. Since max77686_enable() is a callback,so it
should be static.
Signed-off-by: Yadwinder Singh Brar
---
drivers/regulator/max77686.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/regulator/max77686.c b/drivers/regulator/max77686.c
index 383eb9d..c9bec16 100644
--- a/drivers/regulator/max77686.c
+++ b/drivers/regulator/max77686.c
@@ -146,7 +146,7 @@ static int max77686_ldo_set_suspend_mode(struct
regulator_dev *rdev,
val);
}
-int max77686_enable(struct regulator_dev *rdev)
+static int max77686_enable(struct regulator_dev *rdev)
{
struct max77686_data *max77686 = rdev_get_drvdata(rdev);
--
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 V3] PWM: Add SPEAr PWM chip driver support
Every time you read a code, you figure out new things about it.
Sorry for these comments Now :(
On Mon, Oct 22, 2012 at 9:21 AM, Shiraz Hashim wrote:
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index acfe482..6512786 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o
> obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
> obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
> obj-$(CONFIG_PWM_TEGRA)+= pwm-tegra.o
> +obj-$(CONFIG_PWM_SPEAR)+= pwm-spear.o
I have gone through this on every version of this patch, but couldn't figure
out that you were trying to add it in alphabetical order, but you couldn't.
> diff --git a/drivers/pwm/pwm-spear.c b/drivers/pwm/pwm-spear.c
> +static int spear_pwm_probe(struct platform_device *pdev)
> +{
> + pc = devm_kzalloc(>dev, sizeof(*pc), GFP_KERNEL);
> + if (!pc) {
> + dev_err(>dev, "failed to allocate memory\n");
> + return -ENOMEM;
> + }
> +
> + pc->dev = >dev;
If you are going to send another version, then please move this
> + pc->mmio_base = devm_request_and_ioremap(>dev, r);
> + if (!pc->mmio_base)
> + return -EADDRNOTAVAIL;
> +
> + platform_set_drvdata(pdev, pc);
and this
> + pc->clk = devm_clk_get(>dev, NULL);
> + if (IS_ERR(pc->clk))
> + return PTR_ERR(pc->clk);
to this place :)
So, that we don't do these for failure cases.
> + pc->chip.dev = >dev;
> + pc->chip.ops = _pwm_ops;
> + pc->chip.base = -1;
> + pc->chip.npwm = NUM_PWM;
> +
> + if (np && of_device_is_compatible(np, "st,spear1340-pwm")) {
I have noticed it earlier, but don't know why didn't i gave a comment here?
you don't need to check for np here. It can't be NULL as you depend on
CONFIG_OF.
> + /*
> +* Following enables PWM chip, channels would still be
> +* enabled individually through their control register
> +*/
> + val = readl_relaxed(pc->mmio_base + PWMMCR);
> + val |= PWMMCR_PWM_ENABLE;
> + writel_relaxed(val, pc->mmio_base + PWMMCR);
> +
> + }
> +
> + /* only disable the clk and leave it prepared */
> + clk_disable(pc->clk);
> +
> + return 0;
> +}
> +
> +static int spear_pwm_remove(struct platform_device *pdev)
> +{
> + struct spear_pwm_chip *pc = platform_get_drvdata(pdev);
> + int i;
> +
> + for (i = 0; i < NUM_PWM; i++) {
> + struct pwm_device *pwm = >chip.pwms[i];
> +
> + if (test_bit(PWMF_ENABLED, >flags)) {
> + spear_pwm_writel(pc, i, PWMCR, 0);
> + clk_disable(pc->clk);
> + }
> + }
> +
> + /* clk was prepared in probe, hence unprepare it here */
> + clk_unprepare(pc->clk);
I believe you need to remove the chip first and then do above to
avoid any race conditions, that might occur.
> + return pwmchip_remove(>chip);
> +}
> +
After all this please add my:
Acked-by: Viresh Kumar
Sorry Shiraz for so late comments, i can understand your frustration :(
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] extcon fixes for Linux 3.7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Greg, The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mzx/extcon.git for-next Axel Lin (4): extcon: adc-jack: Fix checking return value of request_any_context_irq extcon: adc-jack: Add missing MODULE_LICENSE extcon: Fix kerneldoc for extcon_set_cable_state and extcon_set_cable_state_ extcon: max77693: Use max77693_update_reg for rmw operations Chanwoo Choi (1): extcon: MAX77693: Add platform data for MUIC device to initialize registers Devendra Naga (1): extcon-max8997: remove usage of ret in max8997_muic_handle_charger_type_detach Jenny TC (1): extcon : register for cable interest by cable name Peter Huewe (2): extcon: Unregister compat class at module unload to fix oops extcon: unregister compat link on cleanup Sachin Kamat (2): extcon: Remove duplicate inclusion of extcon.h header file extcon: Fix return value in extcon_register_interest() anish kumar (5): extcon: standard cable names definition and declaration changed extcon: optimising the check_mutually_exclusive function extcon: checkpatch warning removal extcon: driver model release call not needed extcon: trivial: kfree missed from remove path drivers/extcon/extcon-adc-jack.c | 10 ++- drivers/extcon/extcon-class.c| 143 + drivers/extcon/extcon-gpio.c |1 - drivers/extcon/extcon-max77693.c | 46 +--- drivers/extcon/extcon-max8997.c |6 +- include/linux/extcon.h |2 +- include/linux/mfd/max77693.h | 13 7 files changed, 138 insertions(+), 83 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJQhMSxAAoJEBOhurvWBoCKpYUP/2XtOkfRONMoSzdTjmE4sR+m 6Ze1rB4T6gi8NYudpcwhVJ9x/vGubJgFUEKw9seE7+j6Ryi/UxgnDdQMRpClnAg0 cbDvb6cuzNdO+VWyOh4hlVtIaQKiet2/ZCqwlliX3Gg3zB5AizYXFHwNy/iAJvfO 6xqpeFay57Z3LISxQSXJPJGv4AT6la4hZzDwUMpTJubc/WHqCkZpwDFPFsRZi7Pr +0BqLtnNZdqdzD/c5GwDo1Wp3TU1EuL+DPYjAYE5szLAhTVZ8/a6et2CUzskjXGF 8EGgfavxAYGu7O1YMlukTHQxfbJ9Gdk7d0nWCIppcQ62JB23C+1H7OX/7Mx75vzX ZlmsJQvwh8m18LmZg6X5nwTkGX+XNPjZeCh6uOnBOV+TvHET3Kj8ZY03ELSPxCGD bGFDwHucEUwd1L/eIltoHRyscg0HkRiUVTmN/HdetLihOGMgK8Kglbz3kQGuxmmu 2lCMD6Hdr6xkG4VkhHCkEPUY8fLh4Bvi8AQTP2qDmuYA5yNZFOavV2g59oLIQ3f1 9LTu014T7QuqTyY2zQYZKIVQG1sGcj2q9y0/AXbWjuZKqoWlBqRp/D9yvUcdnPxo kqwi4nv32Vnn1rzLFFxf65uDQ2L4sNGxWPo7vCGlhfYyNQoYOSd63UJfPstbFW28 JHVWg71WQPxR1mGCUGYk =9KTH -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3] PWM: Add SPEAr PWM chip driver support
Add support for PWM chips present on SPEAr platforms. These PWM
chips support 4 channel output with programmable duty cycle and
frequency.
More details on these PWM chips can be obtained from relevant
chapter of reference manual, present at following[1] location.
1. http://www.st.com/internet/mcu/product/251211.jsp
Cc: Thierry Reding
Signed-off-by: Shiraz Hashim
Signed-off-by: Viresh Kumar
Reviewed-by: Vipin Kumar
---
Changes:-
V2 --> V3:
* remove "disabled" line from pwm dt binding documentation
* remove un-necessary check on pwm chip (for NULL) in remove.
V1 --> V2:
* make proper reference to pwm and pwm chip
* take care to capitalize PWM at appropriate places
* fix compatible string to the SoC where pwm chip was introduced
* Rename the documentation file to the name of driver
* Fix cosmetic changes like names, function name alignment, paragraph
formating, comments placement and formating, etc.
* Group and associate the bit field definitions to their registers
* Fix kerneldoc for structure definition
* Use chip to name pwm device and pwm for the channel instance
* Remove init section qualifiers
* Remove ifdefs around device tree from code and add dependency on CONFIG_OF
* prepare/unprepare clock once in probe/remove and just enable/disable
at rest of the places.
* Use _relaxed for readl/writel.
* Fix pwm disable part in remove
.../devicetree/bindings/pwm/spear-pwm.txt | 18 ++
drivers/pwm/Kconfig| 11 +
drivers/pwm/Makefile |1 +
drivers/pwm/pwm-spear.c| 280
4 files changed, 310 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/spear-pwm.txt
create mode 100644 drivers/pwm/pwm-spear.c
diff --git a/Documentation/devicetree/bindings/pwm/spear-pwm.txt
b/Documentation/devicetree/bindings/pwm/spear-pwm.txt
new file mode 100644
index 000..3ac779d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/spear-pwm.txt
@@ -0,0 +1,18 @@
+== ST SPEAr SoC PWM controller ==
+
+Required properties:
+- compatible: should be one of:
+ - "st,spear320-pwm"
+ - "st,spear1340-pwm"
+- reg: physical base address and length of the controller's registers
+- #pwm-cells: number of cells used to specify PWM which is fixed to 2 on
+ SPEAr. The first cell specifies the per-chip index of the PWM to use and
+ the second cell is the period in nanoseconds.
+
+Example:
+
+pwm: pwm@a800 {
+compatible ="st,spear320-pwm";
+reg = <0xa800 0x1000>;
+#pwm-cells = <2>;
+};
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index ed81720..6e556c7 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -112,6 +112,17 @@ config PWM_SAMSUNG
To compile this driver as a module, choose M here: the module
will be called pwm-samsung.
+config PWM_SPEAR
+ tristate "STMicroelectronics SPEAr PWM support"
+ depends on PLAT_SPEAR
+ depends on OF
+ help
+ Generic PWM framework driver for the PWM controller on ST
+ SPEAr SoCs.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-spear.
+
config PWM_TEGRA
tristate "NVIDIA Tegra PWM support"
depends on ARCH_TEGRA
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index acfe482..6512786 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o
obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
obj-$(CONFIG_PWM_TEGRA)+= pwm-tegra.o
+obj-$(CONFIG_PWM_SPEAR)+= pwm-spear.o
obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
obj-$(CONFIG_PWM_TWL6030) += pwm-twl6030.o
diff --git a/drivers/pwm/pwm-spear.c b/drivers/pwm/pwm-spear.c
new file mode 100644
index 000..bb63508
--- /dev/null
+++ b/drivers/pwm/pwm-spear.c
@@ -0,0 +1,280 @@
+/*
+ * ST Microelectronics SPEAr Pulse Width Modulator driver
+ *
+ * Copyright (C) 2012 ST Microelectronics
+ * Shiraz Hashim
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define NUM_PWM4
+
+/* PWM registers and bits definitions */
+#define PWMCR 0x00/* Control Register */
+#define PWMCR_PWM_ENABLE 0x1
+#define PWMCR_PRESCALE_SHIFT 2
+#define PWMCR_MIN_PRESCALE 0x00
+#define PWMCR_MAX_PRESCALE 0x3FFF
+
+#define PWMDCR 0x04/* Duty Cycle Register */
+#define PWMDCR_MIN_DUTY0x0001
+#define
RE: [PATCH 1/1] usb: gadget: Don't attempt to dequeue requests for a disabled USB endpoint on Freescale hardware
> -Original Message- > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Saturday, October 20, 2012 1:37 AM > To: Simon Haggett > Cc: Li Yang-R58472; Felipe Balbi; Greg Kroah-Hartman; linux- > u...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux- > ker...@vger.kernel.org; Laurent Pinchart > Subject: Re: [PATCH 1/1] usb: gadget: Don't attempt to dequeue requests > for a disabled USB endpoint on Freescale hardware > > Hi, > > On Fri, Oct 19, 2012 at 06:19:26PM +0100, Simon Haggett wrote: > > Some gadget drivers may attempt to dequeue requests for an endpoint > > that has already been disabled. For example, in the UVC gadget driver, > > uvc_function_set_alt() will call usb_ep_disable() when alt setting 0 > > is selected. When the userspace application subsequently issues the > > VIDIOC_STREAMOFF ioctl, uvc_video_enable() invokes usb_ep_dequeue() to > ensure that all requests have been cancelled. > > bug is on uvc gadget, then. Laurent ? > > Also, fsl should be removed from the tree, I'm trying to persuade iMX > folks to use drivers/usb/chipidea instead. Besides the iMX usage, the driver is also being used by many Freescale PowerPC/Coldfire SoCs. I agree that it's ideal to move to a common driver. But it is a large task to make the chipidea driver works for all the hardware that fsl_udc had supported and been tested on. > > > For the Freescale High Speed Dual-Role USB controller, > > fsl_ep_dequeue() provides the implementation of usb_ep_dequeue(). If > > this is called for a disabled endpoint, a kernel oops will occur when > the ep->ep.desc field is dereferenced (by ep_index()). > > fsl_ep_disable() sets this field to NULL, as well as deleting all > > pending requests for the endpoint. > > > > This patch adds an additional check to fsl_ep_dequeue() to ensure that > > the endpoint has not already been disabled before attempting to dequeue > requests. > > > > Signed-off-by: Simon Haggett > > --- > > drivers/usb/gadget/fsl_udc_core.c |5 - > > 1 files changed, 4 insertions(+), 1 deletions(-) > > > > diff --git a/drivers/usb/gadget/fsl_udc_core.c > > b/drivers/usb/gadget/fsl_udc_core.c > > index 6ae70cb..acd513b 100644 > > --- a/drivers/usb/gadget/fsl_udc_core.c > > +++ b/drivers/usb/gadget/fsl_udc_core.c > > @@ -955,7 +955,10 @@ static int fsl_ep_dequeue(struct usb_ep *_ep, > struct usb_request *_req) > > int ep_num, stopped, ret = 0; > > u32 epctrl; > > > > - if (!_ep || !_req) > > + /* Ensure that the ep and request are valid, and the ep is not > > +* disabled > > +*/ > > + if (!_ep || !_req || !ep->ep.desc) > > return -EINVAL; > > > > spin_lock_irqsave(>udc->lock, flags); > > -- > > 1.7.4.1 > > > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] Do not change worker's running cpu in cmci_rediscover().
On 10/20/2012 01:21 AM, Luck, Tony wrote: In this case, the following BUG_ON in try_to_wake_up_local() will be triggered: BUG_ON(rq != this_rq()); Logically this looks OK - what is the test case to trigger this? I've done a moderate amount of testing of cpu online/offline while injecting corrected errors (when testing the CMCI storm patches) ... but didn't see this problem. Hi Tony, Borislav, Here is my case. I have 2 nodes, node0 and node1. node1 could be hotpluged. node0 has cpu0 ~ cpu15, node1 has cpu16 ~ cpu31. I online all the cpus on node1, and hot-remove node1 directly. When this problem is triggered, current is a work thread. For example: cpu20 is dying. current is on cpu21, it migrates itself to cpu22. Assume current is process1, and it is a work thread. cpu21cpu22 p1: cmci_rediscover() |-set_cpus_allowed_ptr() |-stop_one_cpu() |-create a work to excute migration_cpu_stop() |-wait_for_completion() |-wait_for_common() |-might_sleep() Here, p1 gives up cpu21. The work starts: migration_cpu_stop() |-migrate p1 to cpu22 On cpu22, p1 wakes up: p1: In wait_for_common() |-do_wait_for_common() |-schedule_timeout() |-schedule() |-__schedule() |-try_to_wake_up_local() |-wq_worker_sleeping() |-BUG_ON(rq != this_rq()) On cpu22, wq_worker_sleeping() uses p1's worker_pool to find a worker to go on to execute p1. But p1's worker_pool is on cpu21, and p1 is now on cpu22. So the BUG_ON(rq != this_rq()) is triggered. Thanks. :) -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [RESEND 2] Take over futex of dead task only if FUTEX_WAITERS is not set
In futex_lock_pi_atomic, we consider that if the value in the futex
variable is 0 with additional flags, then it is safe for takeover
since the owner of the futex is dead. However, when FUTEX_WAITERS is
set in the futex value, handle_futex_death calls futex_wake to wake up
one task. Hence the assumption in futex_lock_pi_atomic is not correct.
The correct assumption is that a futex may be considered safe for a
takeover if The FUTEX_OWNER_DIED bit is set, the TID bits are 0 and
the FUTEX_WAITERS bit is not set.
The race described above can be seen in the reproducer in the
following glibc bug report:
http://sourceware.org/bugzilla/show_bug.cgi?id=14076
Signed-off-by: Siddhesh Poyarekar
---
kernel/futex.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index 3717e7b..9aa2d5a 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -760,9 +760,14 @@ retry:
* case. We also do an unconditional take over, when the owner
* of the futex died.
*
+* We do not take over the futex if FUTEX_WAITERS is set because we
+* could end up waking two tasks, the current one and the one that the
+* futex death event wakes in handle_futex_death.
+*
* This is safe as we are protected by the hash bucket lock !
*/
- if (unlikely(ownerdied || !(curval & FUTEX_TID_MASK))) {
+ if (unlikely(ownerdied ||
+ !(curval & (FUTEX_TID_MASK | FUTEX_WAITERS {
/* Keep the OWNER_DIED bit */
newval = (curval & ~FUTEX_TID_MASK) | vpid;
ownerdied = 0;
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] firmware loader: misc changes
On Mon, Oct 22, 2012 at 12:14 AM, Greg Kroah-Hartman wrote: > > Yes, sorry, they are still in my queue, I was working on other fixes > for other subsystems this past week. I'll get to these tomorrow. No problem, thanks for your work, :-) Thank, -- 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/
Re: [patch for-3.7 v3] mm, mempolicy: hold task->mempolicy refcount while reading numa_maps.
(2012/10/19 18:28), David Rientjes wrote:
Looks good, but the patch is whitespace damaged so it doesn't apply. When
that's fixed:
Acked-by: David Rientjes
Sorry, I hope this one is not broken...
==
From c5849c9034abeec3f26bf30dadccd393b0c5c25e Mon Sep 17 00:00:00 2001
From: KAMEZAWA Hiroyuki
Date: Fri, 19 Oct 2012 17:00:55 +0900
Subject: [PATCH] hold task->mempolicy while numa_maps scans.
/proc//numa_maps scans vma and show mempolicy under
mmap_sem. It sometimes accesses task->mempolicy which can
be freed without mmap_sem and numa_maps can show some
garbage while scanning.
This patch tries to take reference count of task->mempolicy at reading
numa_maps before calling get_vma_policy(). By this, task->mempolicy
will not be freed until numa_maps reaches its end.
Acked-by: David Rientjes
Acked-by: KOSAKI Motohiro
Signed-off-by: KAMEZAWA Hiroyuki
V2->v3
- updated comments to be more verbose.
- removed task_lock() in numa_maps code.
V1->V2
- access task->mempolicy only once and remember it. Becase kernel/exit.c
can overwrite it.
---
fs/proc/internal.h |4
fs/proc/task_mmu.c | 49 ++---
2 files changed, 50 insertions(+), 3 deletions(-)
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index cceaab0..43973b0 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -12,6 +12,7 @@
#include
#include
struct ctl_table_header;
+struct mempolicy;
extern struct proc_dir_entry proc_root;
#ifdef CONFIG_PROC_SYSCTL
@@ -74,6 +75,9 @@ struct proc_maps_private {
#ifdef CONFIG_MMU
struct vm_area_struct *tail_vma;
#endif
+#ifdef CONFIG_NUMA
+ struct mempolicy *task_mempolicy;
+#endif
};
void proc_init_inodecache(void);
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 14df880..2371fea 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -89,11 +89,55 @@ static void pad_len_spaces(struct seq_file *m, int len)
len = 1;
seq_printf(m, "%*c", len, ' ');
}
+#ifdef CONFIG_NUMA
+/*
+ * These functions are for numa_maps but called in generic **maps seq_file
+ * ->start(), ->stop() ops.
+ *
+ * numa_maps scans all vmas under mmap_sem and checks their mempolicy.
+ * Each mempolicy object is controlled by reference counting. The problem here
+ * is how to avoid accessing dead mempolicy object.
+ *
+ * Because we're holding mmap_sem while reading seq_file, it's safe to access
+ * each vma's mempolicy, no vma objects will never drop refs to mempolicy.
+ *
+ * A task's mempolicy (task->mempolicy) has different behavior. task->mempolicy
+ * is set and replaced under mmap_sem but unrefed and cleared under
task_lock().
+ * So, without task_lock(), we cannot trust get_vma_policy() because we cannot
+ * gurantee the task never exits under us. But taking task_lock() around
+ * get_vma_plicy() causes lock order problem.
+ *
+ * To access task->mempolicy without lock, we hold a reference count of an
+ * object pointed by task->mempolicy and remember it. This will guarantee
+ * that task->mempolicy points to an alive object or NULL in numa_maps
accesses.
+ */
+static void hold_task_mempolicy(struct proc_maps_private *priv)
+{
+ struct task_struct *task = priv->task;
+
+ task_lock(task);
+ priv->task_mempolicy = task->mempolicy;
+ mpol_get(priv->task_mempolicy);
+ task_unlock(task);
+}
+static void release_task_mempolicy(struct proc_maps_private *priv)
+{
+ mpol_put(priv->task_mempolicy);
+}
+#else
+static void hold_task_mempolicy(struct proc_maps_private *priv)
+{
+}
+static void release_task_mempolicy(struct proc_maps_private *priv)
+{
+}
+#endif
static void vma_stop(struct proc_maps_private *priv, struct vm_area_struct *vma)
{
if (vma && vma != priv->tail_vma) {
struct mm_struct *mm = vma->vm_mm;
+ release_task_mempolicy(priv);
up_read(>mmap_sem);
mmput(mm);
}
@@ -132,7 +176,7 @@ static void *m_start(struct seq_file *m, loff_t *pos)
tail_vma = get_gate_vma(priv->task->mm);
priv->tail_vma = tail_vma;
-
+ hold_task_mempolicy(priv);
/* Start with last addr hint */
vma = find_vma(mm, last_addr);
if (last_addr && vma) {
@@ -159,6 +203,7 @@ out:
if (vma)
return vma;
+ release_task_mempolicy(priv);
/* End of vmas has been reached */
m->version = (tail_vma != NULL)? 0: -1UL;
up_read(>mmap_sem);
@@ -1178,11 +1223,9 @@ static int show_numa_map(struct seq_file *m, void *v,
int is_pid)
walk.private = md;
walk.mm = mm;
- task_lock(task);
pol = get_vma_policy(task, vma, vma->vm_start);
mpol_to_str(buffer, sizeof(buffer), pol, 0);
mpol_cond_put(pol);
- task_unlock(task);
seq_printf(m, "%08lx %s", vma->vm_start, buffer);
--
1.7.10.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Re: Submitting patches
On 10/21/2012 07:09 PM, Jimster480 wrote: I recently joined this list (in the last few days) as I was told I needed to join it to submit kernel changes/patches/modifications. How do I go about doing so? I made some optimizations (mostly removing un-necessary calls, etc) in the autogroup scheduler, and cpuset and another. The website that manages the list is not very informative so I hope I am doing this right. Thanks in Advance! You do not have to join this mailing list to submit patches, but you may find it helpful. We hope that what you need to know is covered in some documentation files in the kernel source tree, primarily: Documentation/SumbittingPatches Documentation/SubmittingDrivers Documentation/SubmitChecklist If you still have questions after reading those, please let us know. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] extcon : register for cable interest by cable name
On 10/17/2012 09:08 PM, Jenny TC wrote: > There are some scnearios where a driver/framework needs to register > interest for a particular cable without specifying the extcon device > name. One such scenario is charger notifications. The platform will > have charger cabel which will be bound to any extcon device. It's > not mandatory for the charger driver to know which extcon device > it should use. This patch enables the support for registering > interest for a cable just by cable name wihtout specifying the > extcon device name > > Signed-off-by: Jenny TC > --- > v1: > Initial submit > V2: > Removed the new API and modified the extcon_register_interest > API to accomodate the new requirement > > drivers/extcon/extcon-class.c | 43 > +++-- > 1 file changed, 33 insertions(+), 10 deletions(-) > Tested-by: Chanwoo Choi Applied it and This patch is tested by me on charger-manager. You can check it after some hours at extcon tree: - http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/extcon-for-next Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] Replace if statement with WARN_ON_ONCE() in cmci_rediscover().
On 10/20/2012 12:40 AM, Borislav Petkov wrote:
On Fri, Oct 19, 2012 at 01:45:27PM +0800, Tang Chen wrote:
cmci_rediscover() is only called by the CPU_POST_DEAD event handler,
which means the corresponding cpu has already dead. As a result, it
won't be accessed in the for_each_online_cpu loop.
So, we could change the if(cpu == dying) statement into a WARN_ON_ONCE().
Signed-off-by: Tang Chen
---
arch/x86/kernel/cpu/mcheck/mce_intel.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c
b/arch/x86/kernel/cpu/mcheck/mce_intel.c
index 38e49bc..481d152 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
@@ -180,8 +180,8 @@ void cmci_rediscover(int dying)
cpumask_copy(old,>cpus_allowed);
for_each_online_cpu(cpu) {
- if (cpu == dying)
- continue;
+ WARN_ON_ONCE(cpu == dying);
Ok, I don't understand that:
we want to warn that the rediscovering is happening on a dying cpu?? And
before that, we simply jumped over it and didn't do the rediscovering
there? Why should we warn at all?
Hi Borislav,
As far as I know, cmci_rediscover() is only called in
mce_cpu_callback() to handle CPU_POST_DEAD event.
2362 if (action == CPU_POST_DEAD) {
2363 /* intentionally ignoring frozen here */
2364 cmci_rediscover(cpu);
2365 }
I didn't find anywhere else using this function. So I think the cpu
should be dead already when this function is called.
I don't why before we just jumped over it. But I think if we have an
online cpu == dying here, it must be wrong. So I think we should warn
it, not just jump over it.
Thanks. :)
Huh?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Submitting patches
I recently joined this list (in the last few days) as I was told I needed to join it to submit kernel changes/patches/modifications. How do I go about doing so? I made some optimizations (mostly removing un-necessary calls, etc) in the autogroup scheduler, and cpuset and another. The website that manages the list is not very informative so I hope I am doing this right. Thanks in Advance! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the modules tree with the tree
On Sun, Oct 21, 2012 at 6:35 PM, Stephen Rothwell wrote:
> Hi Rusty,
>
> Today's linux-next merge of the modules tree got a conflict in
> kernel/module.c between commit caabe240574a ("MODSIGN: Move the magic
> string to the end of a module and eliminate the search") from Linus' tree
> and commit 0250abdeec54 ("module: add syscall to load module from fd")
> from the modules tree.
>
> I fixed it up (I think - see below) and can carry the fix as necessary
> (no action is required).
>
> I do wonder why the above change in Linus' tree seems to have bypassed
> the modules maintainer.
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc kernel/module.c
> index 6085f5e,261bf82..000
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@@ -2420,18 -2422,27 +2422,18 @@@ static inline void kmemleak_load_module
> #endif
>
> #ifdef CONFIG_MODULE_SIG
> - static int module_sig_check(struct load_info *info,
> - const void *mod, unsigned long *_len)
> + static int module_sig_check(struct load_info *info)
> {
> int err = -ENOKEY;
> - unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
> - unsigned long len = *_len;
> + const unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
> + const void *mod = info->hdr;
I got rid of "mod" when I did my merge of these changes against
Linus's tree, but I had to cast it in the memcmp, so probably best to
just keep "mod".
> - const void *p = mod, *end = mod + info->len;
> ++ unsigned long len = info->len;
>
> - /* Poor man's memmem. */
> - while ((p = memchr(p, MODULE_SIG_STRING[0], end - p))) {
> - if (p + markerlen > end)
> - break;
> -
> - if (memcmp(p, MODULE_SIG_STRING, markerlen) == 0) {
> - const void *sig = p + markerlen;
> - /* Truncate module up to signature. */
> - info->len = p - mod;
> - err = mod_verify_sig(mod, info->len,
> - sig, end - sig);
> - break;
> - }
> - p++;
> + if (len > markerlen &&
> + memcmp(mod + len - markerlen, MODULE_SIG_STRING, markerlen) == 0)
> {
> + /* We truncate the module to discard the signature */
> - *_len -= markerlen;
> - err = mod_verify_sig(mod, _len);
> ++ info->len -= markerlen;
> ++ err = mod_verify_sig(mod, >len);
> }
>
> if (!err) {
-Kees
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Quick question: Maintainers for scripts
On 10/21/2012 06:37 PM, Cong Wang wrote: > On Mon, Oct 22, 2012 at 6:35 AM, Cruz Julian Bishop > wrote: >> Hi everyone, >> >> I was just wondering - Since (last time I looked, anyway), >> /scripts/* has no maintainer, who would I send patches to? >> >> Would I just send them to the mailing list, or is there a >> sort of catch-all maintainer for things like this? >> > > linux-kbu...@vger.kernel.org That is probably the best single answer. An alternative is to run ./scripts/get_maintainer.pl -f $filename on each file in scripts. That will give you more explicit and more correct answers. -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Quick question: Maintainers for scripts
On Mon, Oct 22, 2012 at 6:35 AM, Cruz Julian Bishop wrote: > Hi everyone, > > I was just wondering - Since (last time I looked, anyway), > /scripts/* has no maintainer, who would I send patches to? > > Would I just send them to the mailing list, or is there a > sort of catch-all maintainer for things like this? > linux-kbu...@vger.kernel.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the modules tree with the tree
Hi Rusty,
Today's linux-next merge of the modules tree got a conflict in
kernel/module.c between commit caabe240574a ("MODSIGN: Move the magic
string to the end of a module and eliminate the search") from Linus' tree
and commit 0250abdeec54 ("module: add syscall to load module from fd")
from the modules tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
I do wonder why the above change in Linus' tree seems to have bypassed
the modules maintainer.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc kernel/module.c
index 6085f5e,261bf82..000
--- a/kernel/module.c
+++ b/kernel/module.c
@@@ -2420,18 -2422,27 +2422,18 @@@ static inline void kmemleak_load_module
#endif
#ifdef CONFIG_MODULE_SIG
- static int module_sig_check(struct load_info *info,
- const void *mod, unsigned long *_len)
+ static int module_sig_check(struct load_info *info)
{
int err = -ENOKEY;
- unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
- unsigned long len = *_len;
+ const unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
+ const void *mod = info->hdr;
- const void *p = mod, *end = mod + info->len;
++ unsigned long len = info->len;
- /* Poor man's memmem. */
- while ((p = memchr(p, MODULE_SIG_STRING[0], end - p))) {
- if (p + markerlen > end)
- break;
-
- if (memcmp(p, MODULE_SIG_STRING, markerlen) == 0) {
- const void *sig = p + markerlen;
- /* Truncate module up to signature. */
- info->len = p - mod;
- err = mod_verify_sig(mod, info->len,
- sig, end - sig);
- break;
- }
- p++;
+ if (len > markerlen &&
+ memcmp(mod + len - markerlen, MODULE_SIG_STRING, markerlen) == 0) {
+ /* We truncate the module to discard the signature */
- *_len -= markerlen;
- err = mod_verify_sig(mod, _len);
++ info->len -= markerlen;
++ err = mod_verify_sig(mod, >len);
}
if (!err) {
pgpxrN9hRofHV.pgp
Description: PGP signature
Re: [PATCH v3 1/2] writeback: add dirty_background_centisecs per bdi variable
On Fri, Oct 19, 2012 at 04:51:05PM +0900, Namjae Jeon wrote: > Hi Dave. > > Test Procedure: > > 1) Local USB disk WRITE speed on NFS server is ~25 MB/s > > 2) Run WRITE test(create 1 GB file) on NFS Client with default > writeback settings on NFS Server. By default > bdi->dirty_background_bytes = 0, that means no change in default > writeback behaviour > > 3) Next we change bdi->dirty_background_bytes = 25 MB (almost equal to > local USB disk write speed on NFS Server) > *** only on NFS Server - not on NFS Client *** Ok, so the results look good, but it's not really addressing what I was asking, though. A typical desktop PC has a disk that can do 100MB/s and GbE, so I was expecting a test that showed throughput close to GbE maximums at least (ie. around that 100MB/s). I have 3 year old, low end, low power hardware (atom) that hanles twice the throughput you are testing here, and most current consumer NAS devices are more powerful than this. IOWs, I think the rates you are testing at are probably too low even for the consumer NAS market to consider relevant... > -- > Multiple NFS Client test: > --- > Sorry - We could not arrange multiple PCs to verify this. > So, we tried 1 NFS Server + 2 NFS Clients using 3 target boards: > ARM Target + 512 MB RAM + ethernet - 100 Mbits/s, create 1 GB File But this really doesn't tells us anything - it's still only 100Mb/s, which we'd expect is already getting very close to line rate even with low powered client hardware. What I'm concerned about the NFS server "sweet spot" - a $10k server that exports 20TB of storage and can sustain close to a GB/s of NFS traffic over a single 10GbE link with tens to hundreds of clients. 100MB/s and 10 clients is about the minimum needed to be able to extrapolate a litle and make an informed guess of how it will scale up > > 1. what's the comparison in performance to typical NFS > > server writeback parameter tuning? i.e. dirty_background_ratio=5, > > dirty_ratio=10, dirty_expire_centiseconds=1000, > > dirty_writeback_centisecs=1? i.e. does this give change give any > > benefit over the current common practice for configuring NFS > > servers? > > Agreed, that above improvement in write speed can be achieved by > tuning above write-back parameters. > But if we change these settings, it will change write-back behavior > system wide. > On the other hand, if we change proposed per bdi setting, > bdi->dirty_background_bytes it will change write-back behavior for the > block device exported on NFS server. I already know what the difference between global vs per-bdi tuning means. What I want to know is how your results compare *numerically* to just having a tweaked global setting on a vanilla kernel. i.e. is there really any performance benefit to per-bdi configuration that cannot be gained by existing methods? > > 2. what happens when you have 10 clients all writing to the server > > at once? Or a 100? NFS servers rarely have a single writer to a > > single file at a time, so what impact does this change have on > > multiple concurrent file write performance from multiple clients > > Sorry, we could not arrange more than 2 PCs for verifying this. Really? Well, perhaps there's some tools that might be useful for you here: http://oss.sgi.com/projects/nfs/testtools/ "Weber Test load generator for NFS. Uses multiple threads, multiple sockets and multiple IP addresses to simulate loads from many machines, thus enabling testing of NFS server setups with larger client counts than can be tested with physical infrastructure (or Virtual Machine clients). Has been useful in automated NFS testing and as a pinpoint NFS load generator tool for performance development." > > 3. Following on from the multiple client test, what difference does it > > make to file fragmentation rates? Writing more frequently means > > smaller allocations and writes, and that tends to lead to higher > > fragmentation rates, especially when multiple files are being > > written concurrently. Higher fragmentation also means lower > > performance over time as fragmentation accelerates filesystem aging > > effects on performance. IOWs, it may be faster when new, but it > > will be slower 3 months down the track and that's a bad tradeoff to > > make. > > We agree that there could be bit more framentation. But as you know, > we are not changing writeback settings at NFS clients. > So, write-back behavior on NFS client will not change - IO requests > will be buffered at NFS client as per existing write-back behavior. I think you misunderstand - writeback settings on the server greatly impact the way the server writes data and therefore the way files are fragmented. It has nothing to do with client side tuning. Effectively, what you are presenting is best case numbers - empty filesystem, single client,
Re: RFC: sign the modules at install time
David Howells writes: > Rusty Russell wrote: > >> > (Side note: I hope people realize that the random key is generated >> > with a 100-year lifespan. So if you build a kernel today, you do >> > potentially have a "year-2112 problem". I'm not horribly worried, but >> > I *am* a bit worried about 32-bit time_t overflow and I hope 32-bit >> > openssl doesn't do anything odd) >> >> Yep, David's original patch had that problem; he fixed the kernel's x509 >> handling to use struct tm, not time_t, and now it Just Works. > > That's assuming that 32-bit *openssl* gets it right when generating the key. Yes, I am assuming that. What openssl did you think I ran on my 32-bit kernel? :) 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: RFC: sign the modules at install time
Linus Torvalds writes:
> On Fri, Oct 19, 2012 at 12:58 PM, Linus Torvalds
> wrote:
>>
>> Tssk. I fixed it up, and now it works-for-me(tm), but some perl person
>> probably really should try to make that sign-file and x509keyid merge.
>> My fix made the thing even slower, doing two extra "wc -c" invocations
>> since it can't do "${#..}" expansion due to the locale problem.
>
> Hmm. I haven't seen this breakage personally yet, but looking more at
> Rusty's last changes I'm pretty sure my fixes are potentially not
> sufficient.
Sorry for posting untested hack :(
Thanks for the rewrite David; modules_install here was 18.6 seconds,
became 19.1 with my broken hack, now 17.3 seconds.
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] MODSIGN: Move the magic string to the end of a module and eliminate the search
David Howells writes:
> Emit the magic string that indicates a module has a signature after the
> signature data instead of before it. This allows module_sig_check() to be
> made simpler and faster by the elimination of the search for the magic string.
> Instead we just need to do a single memcmp().
>
> This works because at the end of the signature data there is the fixed-length
> signature information block. This block then falls immediately prior to the
> magic number.
>
>>From the contents of the information block, it is trivial to calculate the
>>size
> of the signature data and thus the size of the actual module data.
Meh, I really wanted to separate the module signature locating (my
problem) from the decoding and checking (your problem).
If we're going to require such a header, we can simplify further (untested!).
BTW, I'm not convinced your use of bitfields here is portable; it may be
portable enough for Linux though.
Cheers,
Rusty.
diff --git a/include/linux/module.h b/include/linux/module.h
index 7760c6d..bfd1b2d 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -21,9 +21,6 @@
#include
#include
-/* In stripped ARM and x86-64 modules, ~ is surprisingly rare. */
-#define MODULE_SIG_STRING "~Module signature appended~\n"
-
/* Not Yet Implemented */
#define MODULE_SUPPORTED_DEVICE(name)
@@ -656,4 +653,29 @@ static inline void module_bug_finalize(const Elf_Ehdr *hdr,
static inline void module_bug_cleanup(struct module *mod) {}
#endif /* CONFIG_GENERIC_BUG */
+#ifdef CONFIG_MODULE_SIG
+#define MODULE_SIG_STRING "~Module signature appended~\n"
+
+/*
+ * Appended module signature information block.
+ *
+ * The constituents of the signature section are, in order:
+ *
+ * - Signer's name
+ * - Key identifier
+ * - Signature data
+ * - Information block
+ */
+struct module_signature {
+ enum pkey_algo algo : 8; /* Public-key crypto algorithm
*/
+ enum pkey_hash_algo hash : 8; /* Digest algorithm */
+ enum pkey_id_type id_type : 8;/* Key identifier type */
+ u8 signer_len; /* Length of signer's name */
+ u8 key_id_len; /* Length of key identifier */
+ u8 __pad[3];
+ __be32 sig_len;/* Length of signature data */
+ charmarker[sizeof(MODULE_SIG_STRING)-1];
+};
+#endif /* CONFIG_MODULE_SIG */
+
#endif /* _LINUX_MODULE_H */
diff --git a/kernel/module.c b/kernel/module.c
index 6085f5e..254d6a3 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2424,14 +2424,17 @@ static int module_sig_check(struct load_info *info,
const void *mod, unsigned long *_len)
{
int err = -ENOKEY;
- unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
+ struct module_signature sig;
unsigned long len = *_len;
- if (len > markerlen &&
- memcmp(mod + len - markerlen, MODULE_SIG_STRING, markerlen) == 0) {
- /* We truncate the module to discard the signature */
- *_len -= markerlen;
- err = mod_verify_sig(mod, _len);
+ if (len > sizeof(sig)) {
+ memcpy(, mod + len - sizeof(sig), sizeof(sig));
+
+ if (!memcmp(sig.marker, MODULE_SIG_STRING, sizeof(sig.marker)))
{
+ /* We truncate the module to discard the signature */
+ *_len -= sizeof(sig);
+ err = mod_verify_sig(mod, , _len);
+ }
}
if (!err) {
diff --git a/kernel/module_signing.c b/kernel/module_signing.c
index d492a23..db8e836 100644
--- a/kernel/module_signing.c
+++ b/kernel/module_signing.c
@@ -17,26 +17,6 @@
#include "module-internal.h"
/*
- * Module signature information block.
- *
- * The constituents of the signature section are, in order:
- *
- * - Signer's name
- * - Key identifier
- * - Signature data
- * - Information block
- */
-struct module_signature {
- enum pkey_algo algo : 8; /* Public-key crypto algorithm
*/
- enum pkey_hash_algo hash : 8; /* Digest algorithm */
- enum pkey_id_type id_type : 8;/* Key identifier type */
- u8 signer_len; /* Length of signer's name */
- u8 key_id_len; /* Length of key identifier */
- u8 __pad[3];
- __be32 sig_len;/* Length of signature data */
-};
-
-/*
* Digest the module contents.
*/
static struct public_key_signature *mod_make_digest(enum pkey_hash_algo hash,
@@ -183,10 +163,10 @@ static struct key *request_asymmetric_key(const char
*signer, size_t signer_len,
/*
* Verify the signature on a module.
*/
-int mod_verify_sig(const void *mod, unsigned long *_modlen)
+int mod_verify_sig(const void *mod,
+ const struct
[PATCH 2/2 v2] drivers: power: jz4740_battery: Use devm_request_and_ioremap
And remove all checks abvout request_mem_region and ioremap.
This is just a cleanup. Not functional changes here.
Signed-off-by: Marcos Paulo de Souza
---
drivers/power/jz4740-battery.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git a/drivers/power/jz4740-battery.c b/drivers/power/jz4740-battery.c
index 59900c6..1df7be8 100644
--- a/drivers/power/jz4740-battery.c
+++ b/drivers/power/jz4740-battery.c
@@ -272,19 +272,12 @@ static int __devinit jz_battery_probe(struct
platform_device *pdev)
return -ENOENT;
}
- jz_battery->mem = request_mem_region(jz_battery->mem->start,
- resource_size(jz_battery->mem), pdev->name);
- if (!jz_battery->mem) {
- dev_err(>dev, "Failed to request mmio memory region\n");
- return -EBUSY;
- }
+ jz_battery->base = devm_request_and_ioremap(>dev
+ , jz_battery->mem);
- jz_battery->base = ioremap_nocache(jz_battery->mem->start,
- resource_size(jz_battery->mem));
if (!jz_battery->base) {
- ret = -EBUSY;
dev_err(>dev, "Failed to ioremap mmio memory\n");
- goto err_release_mem_region;
+ return -EBUSY;
}
battery = _battery->battery;
@@ -308,7 +301,7 @@ static int __devinit jz_battery_probe(struct
platform_device *pdev)
jz_battery);
if (ret) {
dev_err(>dev, "Failed to request irq %d\n", ret);
- goto err_iounmap;
+ goto err_irq;
}
disable_irq(jz_battery->irq);
@@ -365,11 +358,8 @@ err_free_gpio:
gpio_free(jz_battery->pdata->gpio_charge);
err_free_irq:
free_irq(jz_battery->irq, jz_battery);
-err_iounmap:
+err_irq:
platform_set_drvdata(pdev, NULL);
- iounmap(jz_battery->base);
-err_release_mem_region:
- release_mem_region(jz_battery->mem->start,
resource_size(jz_battery->mem));
return ret;
}
@@ -389,9 +379,6 @@ static int __devexit jz_battery_remove(struct
platform_device *pdev)
free_irq(jz_battery->irq, jz_battery);
- iounmap(jz_battery->base);
- release_mem_region(jz_battery->mem->start,
resource_size(jz_battery->mem));
-
return 0;
}
--
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 1/2 v2] drivers: power: jz4740-battery: Use devm_kzalloc instead of kzalloc/kfree
Signed-off-by: Marcos Paulo de Souza
Acked-by: Lars-Peter Clausen
---
No changes from v1.
drivers/power/jz4740-battery.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/power/jz4740-battery.c b/drivers/power/jz4740-battery.c
index 8dbc7bf..59900c6 100644
--- a/drivers/power/jz4740-battery.c
+++ b/drivers/power/jz4740-battery.c
@@ -252,7 +252,7 @@ static int __devinit jz_battery_probe(struct
platform_device *pdev)
return -ENXIO;
}
- jz_battery = kzalloc(sizeof(*jz_battery), GFP_KERNEL);
+ jz_battery = devm_kzalloc(>dev, sizeof(*jz_battery), GFP_KERNEL);
if (!jz_battery) {
dev_err(>dev, "Failed to allocate driver structure\n");
return -ENOMEM;
@@ -262,24 +262,21 @@ static int __devinit jz_battery_probe(struct
platform_device *pdev)
jz_battery->irq = platform_get_irq(pdev, 0);
if (jz_battery->irq < 0) {
- ret = jz_battery->irq;
dev_err(>dev, "Failed to get platform irq: %d\n", ret);
- goto err_free;
+ return jz_battery->irq;
}
jz_battery->mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!jz_battery->mem) {
- ret = -ENOENT;
dev_err(>dev, "Failed to get platform mmio resource\n");
- goto err_free;
+ return -ENOENT;
}
jz_battery->mem = request_mem_region(jz_battery->mem->start,
resource_size(jz_battery->mem), pdev->name);
if (!jz_battery->mem) {
- ret = -EBUSY;
dev_err(>dev, "Failed to request mmio memory region\n");
- goto err_free;
+ return -EBUSY;
}
jz_battery->base = ioremap_nocache(jz_battery->mem->start,
@@ -373,8 +370,6 @@ err_iounmap:
iounmap(jz_battery->base);
err_release_mem_region:
release_mem_region(jz_battery->mem->start,
resource_size(jz_battery->mem));
-err_free:
- kfree(jz_battery);
return ret;
}
@@ -396,7 +391,6 @@ static int __devexit jz_battery_remove(struct
platform_device *pdev)
iounmap(jz_battery->base);
release_mem_region(jz_battery->mem->start,
resource_size(jz_battery->mem));
- kfree(jz_battery);
return 0;
}
--
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] blkcg: stop iteration early if root_rl is the only request list
__blk_queue_next_rl() finds next request list based on blkg_list
while skipping root_blkg in the list.
OTOH, root_rl is special as it may exist even without root_blkg.
Though the later part of the function handles such a case correctly,
exiting early is good for readability of the code.
Signed-off-by: Jun'ichi Nomura
Cc: Vivek Goyal
Cc: Tejun Heo
Cc: Jens Axboe
---
block/blk-cgroup.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index 54f35d1..a31e678 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -333,6 +333,9 @@ struct request_list *__blk_queue_next_rl(struct
request_list *rl,
*/
if (rl == >root_rl) {
ent = >blkg_list;
+ /* There are no more block groups, hence no request lists */
+ if (list_empty(ent))
+ return NULL;
} else {
blkg = container_of(rl, struct blkcg_gq, rl);
ent = >q_node;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2 v2] Cleanup battery driver for jz4740
Hi guys, This is the second attempt for clean of the battery driver of jz4740. Changelog: Path 1/2: Is the same, just added the Acked-by from Lars Peter-Clausen Path 2/2: use devm_request_and_ioremap, suggested by Lars Petr-Clausen The third patch about irqs sent before was droped. This will be reworked in the next patches. I hope you enjoy :) Marcos Paulo de Souza (2): drivers: power: jz4740-battery: Use devm_kzalloc instead of kzalloc/kfree drivers: power: jz4740_battery: Use devm_request_and_ioremap drivers/power/jz4740-battery.c | 35 --- 1 file changed, 8 insertions(+), 27 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] extcon: trivial: kfree missed from remove path
On 10/21/2012 01:58 PM, anish kumar wrote: > From: anish kumar > > Extcon core doesn't free the memory when we do unregister. > Kfree is added in the remove path as it was missing. > > Signed-off-by: anish kumar > --- > drivers/extcon/extcon-max77693.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) Applied, thanks. You can check it after some hours at extcon tree: - http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/extcon-for-next Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] gpio: samsung: use pr_* instead of printk
This patch uses pr_* instead of printk. Also, gpio_dbg
is replaced with pr_debug.
Signed-off-by: Jingoo Han
---
Change since v3:
- remove Linus Walleij's Reviewed-by
Change since v2:
- remove Ryan Mallon's Signed-off-by
drivers/gpio/gpio-samsung.c | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index a006f0d..5c5ccdf 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -42,12 +42,6 @@
#include
#include
-#ifndef DEBUG_GPIO
-#define gpio_dbg(x...) do { } while (0)
-#else
-#define gpio_dbg(x...) printk(KERN_DEBUG x)
-#endif
-
int samsung_gpio_setpull_updown(struct samsung_gpio_chip *chip,
unsigned int off, samsung_gpio_pull_t pull)
{
@@ -599,7 +593,7 @@ static int samsung_gpiolib_4bit_input(struct gpio_chip
*chip,
con &= ~(0xf << con_4bit_shift(offset));
__raw_writel(con, base + GPIOCON_OFF);
- gpio_dbg("%s: %p: CON now %08lx\n", __func__, base, con);
+ pr_debug("%s: %p: CON now %08lx\n", __func__, base, con);
return 0;
}
@@ -627,7 +621,7 @@ static int samsung_gpiolib_4bit_output(struct gpio_chip
*chip,
__raw_writel(con, base + GPIOCON_OFF);
__raw_writel(dat, base + GPIODAT_OFF);
- gpio_dbg("%s: %p: CON %08lx, DAT %08lx\n", __func__, base, con, dat);
+ pr_debug("%s: %p: CON %08lx, DAT %08lx\n", __func__, base, con, dat);
return 0;
}
@@ -671,7 +665,7 @@ static int samsung_gpiolib_4bit2_input(struct gpio_chip
*chip,
con &= ~(0xf << con_4bit_shift(offset));
__raw_writel(con, regcon);
- gpio_dbg("%s: %p: CON %08lx\n", __func__, base, con);
+ pr_debug("%s: %p: CON %08lx\n", __func__, base, con);
return 0;
}
@@ -706,7 +700,7 @@ static int samsung_gpiolib_4bit2_output(struct gpio_chip
*chip,
__raw_writel(con, regcon);
__raw_writel(dat, base + GPIODAT_OFF);
- gpio_dbg("%s: %p: CON %08lx, DAT %08lx\n", __func__, base, con, dat);
+ pr_debug("%s: %p: CON %08lx, DAT %08lx\n", __func__, base, con, dat);
return 0;
}
@@ -926,10 +920,10 @@ static void __init samsung_gpiolib_add(struct
samsung_gpio_chip *chip)
#ifdef CONFIG_PM
if (chip->pm != NULL) {
if (!chip->pm->save || !chip->pm->resume)
- printk(KERN_ERR "gpio: %s has missing PM functions\n",
+ pr_err("gpio: %s has missing PM functions\n",
gc->label);
} else
- printk(KERN_ERR "gpio: %s has no PM function\n", gc->label);
+ pr_err("gpio: %s has no PM function\n", gc->label);
#endif
/* gpiochip_add() prints own failure message on error. */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] gpio: samsung: use pr_* instead of printk
On Friday, October 19, 2012 7:09 PM Linus Walleij wrote > > On Wed, Oct 17, 2012 at 3:52 AM, Jingoo Han wrote: > > > This patch uses pr_* instead of printk. Also, gpio_dbg > > is replaced with pr_debug. > > > > Signed-off-by: Jingoo Han > > Reviewed-by: Linus Walleij <- NAK > > Please consult Documentation/SubmittingPatches as to the conditions that > apply when you add Reviewed-by tags. Um, you already gave the Reviewed-by to the same patch, a month ago. Anyway, I will remove Reviewed-by and send v4 patch, soon. > > Hint: it doesn't mean "I know Linus looked at this 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/
Re: pull request: wireless 2012-10-19
From: "John W. Linville" Date: Fri, 19 Oct 2012 17:14:10 -0400 > This is a batch of fixes intended for the 3.7 stream. ... > git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git > for-davem Pulled, thanks a lot John. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] drivers-core: move the calling to device_pm_remove behind the calling to bus_remove_device
On Tue, 2012-10-16 at 23:28 +0800, zhanglong wrote: > We hit an hang issue when removing a mmc device on Medfield Android phone by > sysfs interface. > > device_pm_remove will call pm_runtime_remove which would disable > runtime PM of the device. After that pm_runtime_get* or > pm_runtime_put* will be ignored. So if we disable the runtime PM > before device really be removed, drivers' _remove callback may > access HW even pm_runtime_get* fails. That is bad. > > Consider below call sequence when removing a device: > device_del => device_pm_remove > => class_intf->remove_dev(dev, class_intf) => > pm_runtime_get_sync/put_sync > => bus_remove_device => device_release_driver => > pm_runtime_get_sync/put_sync > > remove_dev might call pm_runtime_get_sync/put_sync. > Then, generic device_release_driver also calls pm_runtime_get_sync/put_sync. > Since device_del => device_pm_remove firstly, later _get_sync wouldn't really > wake up the device. > > I git log -p to find the patch which moves the calling to device_pm_remove > ahead. > It's below patch: > > commit 775b64d2b6ca37697de925f70799c710aab5849a > Author: Rafael J. Wysocki > Date: Sat Jan 12 20:40:46 2008 +0100 > > PM: Acquire device locks on suspend > > This patch reorganizes the way suspend and resume notifications are > sent to drivers. The major changes are that now the PM core acquires > every device semaphore before calling the methods, and calls to > device_add() during suspends will fail, while calls to device_del() > during suspends will block. > > It also provides a way to safely remove a suspended device with the > help of the PM core, by using the device_pm_schedule_removal() callback > introduced specifically for this purpose, and updates two drivers (msr > and cpuid) that need to use it. > > > As device_pm_schedule_removal is deleted by another patch, we need also > revert other parts of the patch, > i.e. move the calling of device_pm_remove after the calling to > bus_remove_device. > > Signed-off-by: LongX Zhang Rafael, With the patch V2, is there anything else we could improve before it can be merged into your testing tree? Thanks, Yanmin > --- > drivers/base/core.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/base/core.c b/drivers/base/core.c > index abea76c..150a415 100644 > --- a/drivers/base/core.c > +++ b/drivers/base/core.c > @@ -1180,7 +1180,6 @@ void device_del(struct device *dev) > if (dev->bus) > blocking_notifier_call_chain(>bus->p->bus_notifier, > BUS_NOTIFY_DEL_DEVICE, dev); > - device_pm_remove(dev); > dpm_sysfs_remove(dev); > if (parent) > klist_del(>p->knode_parent); > @@ -1205,6 +1204,7 @@ void device_del(struct device *dev) > device_remove_file(dev, _attr); > device_remove_attrs(dev); > bus_remove_device(dev); > + device_pm_remove(dev); > driver_deferred_probe_del(dev); > > /* Notify the platform of the removal, in case they -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix use-after-free of q->root_blkg and q->root_rl.blkg
On 10/19/12 23:53, Vivek Goyal wrote: > On Thu, Oct 18, 2012 at 02:20:53PM -0700, Tejun Heo wrote: >> Hey, Vivek. >> >> On Thu, Oct 18, 2012 at 09:31:49AM -0400, Vivek Goyal wrote: >>> Tejun, for the sake of readability, are you fine with keeping the original >>> check and original patch which I had acked. >> >> Can you please send another patch to change that? It really isn't a >> related change and I don't wanna mix the two. > > Sure. Jun'ichi, would you like to send that cleanup line in a separate patch? OK. I will send that patch. -- Jun'ichi Nomura, NEC 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/
[PATCH 1/2] char_dev: pin parent kobject
In certain cases (for example when a cdev structure is embedded into
another object whose lifetime is controlled by a separate kobject) it is
beneficial to tie lifetime of another object to the lifetime of character
device so that related object is not freed until after char_dev object is
freed. To achieve this let's pin kobject's parent when doing cdev_add()
and unpin when last reference to cdev structure is being released.
Signed-off-by: Dmitry Torokhov
---
OK, so it looks like cdev kobject's parent is unused so we can just have
users set themselves as parents of character device and have cdev_add()
pin it.
fs/char_dev.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/fs/char_dev.c b/fs/char_dev.c
index 3f152b9..afc2bb6 100644
--- a/fs/char_dev.c
+++ b/fs/char_dev.c
@@ -471,9 +471,19 @@ static int exact_lock(dev_t dev, void *data)
*/
int cdev_add(struct cdev *p, dev_t dev, unsigned count)
{
+ int error;
+
p->dev = dev;
p->count = count;
- return kobj_map(cdev_map, dev, count, NULL, exact_match, exact_lock, p);
+
+ error = kobj_map(cdev_map, dev, count, NULL,
+exact_match, exact_lock, p);
+ if (error)
+ return error;
+
+ kobject_get(p->kobj.parent);
+
+ return 0;
}
static void cdev_unmap(dev_t dev, unsigned count)
@@ -498,14 +508,20 @@ void cdev_del(struct cdev *p)
static void cdev_default_release(struct kobject *kobj)
{
struct cdev *p = container_of(kobj, struct cdev, kobj);
+ struct kobject *parent = kobj->parent;
+
cdev_purge(p);
+ kobject_put(parent);
}
static void cdev_dynamic_release(struct kobject *kobj)
{
struct cdev *p = container_of(kobj, struct cdev, kobj);
+ struct kobject *parent = kobj->parent;
+
cdev_purge(p);
kfree(p);
+ kobject_put(parent);
}
static struct kobj_type ktype_cdev_default = {
--
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/
[PATCH 2/2] Input: fix use-after-free introduced with dynamic minor changes
Commit 7f8d4cad1e4e11a45d02bd6e024cc2812963c38a made evdev, joydev and mousedev to embed struct cdev into their respective structures representing input devices. Unfortunately character device structure may outlive the parent structure unless we do not set it up as parent of character device so that it will stay pinned until character device is freed. Also, now that parent structure is pinned while character device exists we do not need to pin and unpin it every time user opens or closes it. Reported-by: Dave Jones Signed-off-by: Dmitry Torokhov --- drivers/input/evdev.c| 3 +-- drivers/input/joydev.c | 3 +-- drivers/input/mousedev.c | 3 +-- 3 files changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c index 6ae2ac4..f0f8928 100644 --- a/drivers/input/evdev.c +++ b/drivers/input/evdev.c @@ -292,7 +292,6 @@ static int evdev_release(struct inode *inode, struct file *file) kfree(client); evdev_close_device(evdev); - put_device(>dev); return 0; } @@ -331,7 +330,6 @@ static int evdev_open(struct inode *inode, struct file *file) file->private_data = client; nonseekable_open(inode, file); - get_device(>dev); return 0; err_free_client: @@ -1001,6 +999,7 @@ static int evdev_connect(struct input_handler *handler, struct input_dev *dev, goto err_free_evdev; cdev_init(>cdev, _fops); + evdev->cdev.kobj.parent = >dev.kobj; error = cdev_add(>cdev, evdev->dev.devt, 1); if (error) goto err_unregister_handle; diff --git a/drivers/input/joydev.c b/drivers/input/joydev.c index 63e5916..9c7526d 100644 --- a/drivers/input/joydev.c +++ b/drivers/input/joydev.c @@ -262,7 +262,6 @@ static int joydev_release(struct inode *inode, struct file *file) kfree(client); joydev_close_device(joydev); - put_device(>dev); return 0; } @@ -289,7 +288,6 @@ static int joydev_open(struct inode *inode, struct file *file) file->private_data = client; nonseekable_open(inode, file); - get_device(>dev); return 0; err_free_client: @@ -877,6 +875,7 @@ static int joydev_connect(struct input_handler *handler, struct input_dev *dev, goto err_free_joydev; cdev_init(>cdev, _fops); + joydev->cdev.kobj.parent = >dev.kobj; error = cdev_add(>cdev, joydev->dev.devt, 1); if (error) goto err_unregister_handle; diff --git a/drivers/input/mousedev.c b/drivers/input/mousedev.c index a1b4c37..8f02e3d 100644 --- a/drivers/input/mousedev.c +++ b/drivers/input/mousedev.c @@ -523,7 +523,6 @@ static int mousedev_release(struct inode *inode, struct file *file) kfree(client); mousedev_close_device(mousedev); - put_device(>dev); return 0; } @@ -558,7 +557,6 @@ static int mousedev_open(struct inode *inode, struct file *file) file->private_data = client; nonseekable_open(inode, file); - get_device(>dev); return 0; err_free_client: @@ -892,6 +890,7 @@ static struct mousedev *mousedev_create(struct input_dev *dev, } cdev_init(>cdev, _fops); + mousedev->cdev.kobj.parent = >dev.kobj; error = cdev_add(>cdev, mousedev->dev.devt, 1); if (error) goto err_unregister_handle; -- 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] extcon: driver model release call not needed
On 10/21/2012 01:46 PM, anish kumar wrote:
> From: anish kumar
>
> There was a case where free and list_del can be called twice
> on the same pointer.So fixed it by re-arranging the code and
> removing a function which was not needed.
>
> Signed-off-by: anish kumar
> ---
> drivers/extcon/extcon-class.c | 71
> ++---
> 1 files changed, 31 insertions(+), 40 deletions(-)
>
Applied, thanks,
But, There were some minor issue, so I fix and applied it.
[...]
> static void extcon_dev_release(struct device *dev)
> {
> - struct extcon_dev *edev = (struct extcon_dev *) dev_get_drvdata(dev);
> -
> - extcon_cleanup(edev, true);
> + struct extcon_dev *edev = dev_get_drvdata(dev);
> + kfree(edev->dev);
It is not necessary to get extcon_dev instance through dev_get_drvdata()
and only call kfree(dev) by using extcon_dev_release()'s parameter.
kfree(dev);
> }
>
> static const char *muex_name = "mutually_exclusive";
> @@ -810,7 +773,35 @@ EXPORT_SYMBOL_GPL(extcon_dev_register);
> */
> void extcon_dev_unregister(struct extcon_dev *edev)
> {
> - extcon_cleanup(edev, false);
> + mutex_lock(_dev_list_lock);
> + list_del(>entry);
> + mutex_unlock(_dev_list_lock);
> +
> + if (get_device(edev->dev) != NULL) {
I prefer minimal indentation, so I will modify as below code.
int index;
mutex_lock(_dev_list_lock);
list_del(>entry);
mutex_unlock(_dev_list_lock);
if (IS_ERR_OR_NULL(get_device(edev->dev))) {
dev_err(edev->dev, "Failed to unregister extcon_dev (%s)\n",
dev_name(edev->dev));
return;
}
if (edev->mutually_exclusive && edev->max_supported) {
for (index = 0; edev->mutually_exclusive[index];
index++)
kfree(edev->d_attrs_muex[index].attr.name);
kfree(edev->d_attrs_muex);
kfree(edev->attrs_muex);
}
[...]
Cheers,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the wireless-next tree with the wireless tree
Hi John,
Today's linux-next merge of the wireless-next tree got a conflict in
net/mac80211/mlme.c between commit 3a40414f826a ("mac80211: connect with
HT20 if HT40 is not permitted") from the wireless tree and commit
04ecd2578e71 ("mac80211: track needed RX chains for channel contexts")
from the wireless-next tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc net/mac80211/mlme.c
index 1b7eed2,469d864..000
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@@ -3104,44 -3181,43 +3183,51 @@@ static int ieee80211_prep_channel(struc
}
}
- if (ht_oper) {
+ if (ht_oper && sband->ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40) {
+ const u8 *ht_cap_ie;
+ const struct ieee80211_ht_cap *ht_cap;
+ u8 chains = 1;
+
- channel_type = NL80211_CHAN_HT20;
+ /*
+ * cfg80211 already verified that the channel itself can
+ * be used, but it didn't check that we can do the right
+ * HT type, so do that here as well. If HT40 isn't allowed
+ * on this channel, disable 40 MHz operation.
+ */
- if (sband->ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40) {
- switch (ht_oper->ht_param &
- IEEE80211_HT_PARAM_CHA_SEC_OFFSET) {
- case IEEE80211_HT_PARAM_CHA_SEC_ABOVE:
+ switch (ht_oper->ht_param & IEEE80211_HT_PARAM_CHA_SEC_OFFSET) {
+ case IEEE80211_HT_PARAM_CHA_SEC_ABOVE:
+ if (cbss->channel->flags & IEEE80211_CHAN_NO_HT40PLUS)
+ ifmgd->flags |= IEEE80211_STA_DISABLE_40MHZ;
+ else
channel_type = NL80211_CHAN_HT40PLUS;
- break;
- case IEEE80211_HT_PARAM_CHA_SEC_BELOW:
+ break;
+ case IEEE80211_HT_PARAM_CHA_SEC_BELOW:
+ if (cbss->channel->flags & IEEE80211_CHAN_NO_HT40MINUS)
+ ifmgd->flags |= IEEE80211_STA_DISABLE_40MHZ;
+ else
channel_type = NL80211_CHAN_HT40MINUS;
- break;
- }
+ break;
}
- }
- if (!ieee80211_set_channel_type(local, sdata, channel_type)) {
- /* can only fail due to HT40+/- mismatch */
- channel_type = NL80211_CHAN_HT20;
- sdata_info(sdata,
- "disabling 40 MHz due to multi-vif mismatch\n");
- ifmgd->flags |= IEEE80211_STA_DISABLE_40MHZ;
- WARN_ON(!ieee80211_set_channel_type(local, sdata,
- channel_type));
+ ht_cap_ie = cfg80211_find_ie(WLAN_EID_HT_CAPABILITY,
+cbss->information_elements,
+cbss->len_information_elements);
+ if (ht_cap_ie && ht_cap_ie[1] >= sizeof(*ht_cap)) {
+ ht_cap = (void *)(ht_cap_ie + 2);
+ chains = ieee80211_mcs_to_chains(_cap->mcs);
+ }
+ sdata->needed_rx_chains = min(chains, local->rx_chains);
+ } else {
+ sdata->needed_rx_chains = 1;
}
- local->oper_channel = cbss->channel;
- ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
+ /* will change later if needed */
+ sdata->smps_mode = IEEE80211_SMPS_OFF;
- return 0;
+ ieee80211_vif_release_channel(sdata);
+ return ieee80211_vif_use_channel(sdata, cbss->channel, channel_type,
+IEEE80211_CHANCTX_SHARED);
}
static int ieee80211_prep_connection(struct ieee80211_sub_if_data *sdata,
pgpveEWivoqdt.pgp
Description: PGP signature
[PATCH] qla3xxx: Ensure request/response queue addr writes to the registers
Before use the request and response queue addr, make sure it has wrote to the registers. Signed-off-by: Joe Jin Cc: Jitendra Kalsaria Cc: Ron Mercer --- drivers/net/ethernet/qlogic/qla3xxx.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/qlogic/qla3xxx.c b/drivers/net/ethernet/qlogic/qla3xxx.c index df09b1c..6407d0d 100644 --- a/drivers/net/ethernet/qlogic/qla3xxx.c +++ b/drivers/net/ethernet/qlogic/qla3xxx.c @@ -2525,6 +2525,13 @@ static int ql_alloc_net_req_rsp_queues(struct ql3_adapter *qdev) qdev->req_q_size = (u32) (NUM_REQ_Q_ENTRIES * sizeof(struct ob_mac_iocb_req)); + qdev->rsp_q_size = NUM_RSP_Q_ENTRIES * sizeof(struct net_rsp_iocb); + + /* The barrier is required to ensure request and response queue +* addr writes to the registers. +*/ + wmb(); + qdev->req_q_virt_addr = pci_alloc_consistent(qdev->pdev, (size_t) qdev->req_q_size, @@ -2536,8 +2543,6 @@ static int ql_alloc_net_req_rsp_queues(struct ql3_adapter *qdev) return -ENOMEM; } - qdev->rsp_q_size = NUM_RSP_Q_ENTRIES * sizeof(struct net_rsp_iocb); - qdev->rsp_q_virt_addr = pci_alloc_consistent(qdev->pdev, (size_t) qdev->rsp_q_size, -- 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/
[PATCH v2] gpiolib: Refactor gpio_export
The gpio_export function uses nested if statements and the status
variable to handle the failure cases. This makes the function logic
difficult to follow. Refactor the code to abort immediately on failure
using goto. This makes the code slightly longer, but significantly
reduces the nesting and number of split lines and makes the code easier
to read.
Signed-off-by: Ryan Mallon
---
Changes since v1:
- Return immediately if no unwinding needed
- Added pr_debug to immediate returns
- Changed unavailable (!requested || exported) to -EPERM
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 5d6c71e..d5f9742 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -702,8 +702,9 @@ int gpio_export(unsigned gpio, bool direction_may_change)
{
unsigned long flags;
struct gpio_desc*desc;
- int status = -EINVAL;
+ int status;
const char *ioname = NULL;
+ struct device *dev;
/* can't export until sysfs is available ... */
if (!gpio_class.p) {
@@ -711,59 +712,65 @@ int gpio_export(unsigned gpio, bool direction_may_change)
return -ENOENT;
}
- if (!gpio_is_valid(gpio))
- goto done;
+ if (!gpio_is_valid(gpio)) {
+ pr_debug("%s: gpio %d is not valid\n", __func__, gpio);
+ return -EINVAL;
+ }
mutex_lock(_lock);
spin_lock_irqsave(_lock, flags);
desc = _desc[gpio];
- if (test_bit(FLAG_REQUESTED, >flags)
- && !test_bit(FLAG_EXPORT, >flags)) {
- status = 0;
- if (!desc->chip->direction_input
- || !desc->chip->direction_output)
- direction_may_change = false;
+ if (!test_bit(FLAG_REQUESTED, >flags) ||
+test_bit(FLAG_EXPORT, >flags)) {
+ spin_unlock_irqrestore(_lock, flags);
+ pr_debug("%s: gpio %d unavailable (requested=%d,
exported=%d)\n",
+ __func__, gpio,
+ test_bit(FLAG_REQUESTED, >flags),
+ test_bit(FLAG_EXPORT, >flags));
+ return -EPERM;
}
+
+ if (!desc->chip->direction_input || !desc->chip->direction_output)
+ direction_may_change = false;
spin_unlock_irqrestore(_lock, flags);
if (desc->chip->names && desc->chip->names[gpio - desc->chip->base])
ioname = desc->chip->names[gpio - desc->chip->base];
- if (status == 0) {
- struct device *dev;
-
- dev = device_create(_class, desc->chip->dev, MKDEV(0, 0),
- desc, ioname ? ioname : "gpio%u", gpio);
- if (!IS_ERR(dev)) {
- status = sysfs_create_group(>kobj,
- _attr_group);
-
- if (!status && direction_may_change)
- status = device_create_file(dev,
- _attr_direction);
-
- if (!status && gpio_to_irq(gpio) >= 0
- && (direction_may_change
- || !test_bit(FLAG_IS_OUT,
- >flags)))
- status = device_create_file(dev,
- _attr_edge);
-
- if (status != 0)
- device_unregister(dev);
- } else
- status = PTR_ERR(dev);
- if (status == 0)
- set_bit(FLAG_EXPORT, >flags);
+ dev = device_create(_class, desc->chip->dev, MKDEV(0, 0),
+ desc, ioname ? ioname : "gpio%u", gpio);
+ if (IS_ERR(dev)) {
+ status = PTR_ERR(dev);
+ goto fail_unlock;
}
- mutex_unlock(_lock);
-
-done:
+ status = sysfs_create_group(>kobj, _attr_group);
if (status)
- pr_debug("%s: gpio%d status %d\n", __func__, gpio, status);
+ goto fail_unregister_device;
+
+ if (direction_may_change) {
+ status = device_create_file(dev, _attr_direction);
+ if (status)
+ goto fail_unregister_device;
+ }
+ if (gpio_to_irq(gpio) >= 0 && (direction_may_change ||
+ !test_bit(FLAG_IS_OUT, >flags))) {
+ status = device_create_file(dev, _attr_edge);
+ if (status)
+ goto fail_unregister_device;
+ }
+
+ set_bit(FLAG_EXPORT, >flags);
+ mutex_unlock(_lock);
+ return 0;
+
+fail_unregister_device:
+ device_unregister(dev);
+fail_unlock:
+
Re: [PATCH net-next] pktgen: Use ipv6_addr_any
From: Joe Perches Date: Thu, 18 Oct 2012 20:55:31 -0700 > Use the standard test for a non-zero ipv6 address. > > Signed-off-by: Joe Perches Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next,1/1] hyperv: Remove unnecessary comments in rndis_filter_receive_data()
From: Haiyang Zhang Date: Thu, 18 Oct 2012 14:00:52 -0700 > Checked with Windows networking team, there is only one RNDIS message > in each netvsc packet. > > Signed-off-by: Haiyang Zhang > Reviewed-by: K. Y. Srinivasan Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/3] lp8788-charger: fix ADC channel names
> > LP8788 IIO ADC driver and platform data have specific naming > convention > > for ADC channels. That is using prefix 'lp8788_'. > > To keep this rule, ADC channel names are changed. > > > It's a little unusual to name the consumer side of the map so > specifically. > If you want to do so it's up to you though (and it obviously has to > match) > that provided in platform_data including the default map in the iio > driver. Thanks a lot for your review. You're right. A channel name is configurable data in the platform side, so the fixed patch has been sent as below. [PATCH v2 2/3] lp8788-charger: fix ADC channel names Best Regards, Milo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ixgbe: Use is_valid_ether_addr
On Sat, 2012-10-20 at 09:22 -0700, Joe Perches wrote: > Use the normal kernel test instead of a module specific one. > > Signed-off-by: Joe Perches > --- > found when doing that larger style conversion, > might as well submit it. > > drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 2 +- > drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 27 > + > drivers/net/ethernet/intel/ixgbe/ixgbe_common.h | 1 - > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +- > drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 9 - > drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c | 2 +- > 6 files changed, 4 insertions(+), 39 deletions(-) Thanks, I will add this to the queue. signature.asc Description: This is a digitally signed message part
[PATCH v2 2/3] lp8788-charger: fix ADC channel names
Patch v2.
The name of ADC channel is configurable in the platform side.
This name is referenced in the IIO consumer driver.
To get the IIO channel, specific name in the platform data is used
as an parameter of the iio_channel_get().
Thus, lp8788_adc_id platform data are replaced with specific names.
Patch v1.
LP8788 IIO ADC driver and platform data have specific naming convention
for ADC channels. That is using prefix 'lp8788_'.
To keep this rule, ADC channel names are changed.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/power/lp8788-charger.c | 44 ++--
include/linux/mfd/lp8788.h |8
2 files changed, 10 insertions(+), 42 deletions(-)
diff --git a/drivers/power/lp8788-charger.c b/drivers/power/lp8788-charger.c
index 614e6aa..f08ed44 100644
--- a/drivers/power/lp8788-charger.c
+++ b/drivers/power/lp8788-charger.c
@@ -596,50 +596,18 @@ static void lp8788_setup_adc_channel(const char
*consumer_name,
struct lp8788_charger *pchg)
{
struct lp8788_charger_platform_data *pdata = pchg->pdata;
- struct device *dev = pchg->lp->dev;
struct iio_channel *chan;
- enum lp8788_adc_id id;
- const char *chan_name[LPADC_MAX] = {
- [LPADC_VBATT_5P5] = "vbatt-5p5",
- [LPADC_VBATT_6P0] = "vbatt-6p0",
- [LPADC_VBATT_5P0] = "vbatt-5p0",
- [LPADC_ADC1] = "adc1",
- [LPADC_ADC2] = "adc2",
- [LPADC_ADC3] = "adc3",
- [LPADC_ADC4] = "adc4",
- };
if (!pdata)
return;
- id = pdata->vbatt_adc;
- switch (id) {
- case LPADC_VBATT_5P5:
- case LPADC_VBATT_6P0:
- case LPADC_VBATT_5P0:
- chan = iio_channel_get(consumer_name, chan_name[id]);
- pchg->chan[LP8788_VBATT] = IS_ERR(chan) ? NULL : chan;
- break;
- default:
- dev_err(dev, "invalid ADC id for VBATT: %d\n", id);
- pchg->chan[LP8788_VBATT] = NULL;
- break;
- }
+ /* ADC channel for battery voltage */
+ chan = iio_channel_get(consumer_name, pdata->adc_vbatt);
+ pchg->chan[LP8788_VBATT] = IS_ERR(chan) ? NULL : chan;
- id = pdata->batt_temp_adc;
- switch (id) {
- case LPADC_ADC1:
- case LPADC_ADC2:
- case LPADC_ADC3:
- case LPADC_ADC4:
- chan = iio_channel_get(consumer_name, chan_name[id]);
- pchg->chan[LP8788_BATT_TEMP] = IS_ERR(chan) ? NULL : chan;
- break;
- default:
- dev_err(dev, "invalid ADC id for BATT_TEMP : %d\n", id);
- pchg->chan[LP8788_BATT_TEMP] = NULL;
- break;
- }
+ /* ADC channel for battery temperature */
+ chan = iio_channel_get(consumer_name, pdata->adc_batt_temp);
+ pchg->chan[LP8788_BATT_TEMP] = IS_ERR(chan) ? NULL : chan;
}
static void lp8788_release_adc_channel(struct lp8788_charger *pchg)
diff --git a/include/linux/mfd/lp8788.h b/include/linux/mfd/lp8788.h
index cec364b..2a32b16 100644
--- a/include/linux/mfd/lp8788.h
+++ b/include/linux/mfd/lp8788.h
@@ -211,16 +211,16 @@ struct lp8788_chg_param {
/*
* struct lp8788_charger_platform_data
- * @vbatt_adc : adc selection id for battery voltage
- * @batt_temp_adc : adc selection id for battery temperature
+ * @adc_vbatt : adc channel name for battery voltage
+ * @adc_batt_temp : adc channel name for battery temperature
* @max_vbatt_mv : used for calculating battery capacity
* @chg_params: initial charging parameters
* @num_chg_params: numbers of charging parameters
* @charger_event : the charger event can be reported to the platform side
*/
struct lp8788_charger_platform_data {
- enum lp8788_adc_id vbatt_adc;
- enum lp8788_adc_id batt_temp_adc;
+ const char *adc_vbatt;
+ const char *adc_batt_temp;
unsigned int max_vbatt_mv;
struct lp8788_chg_param *chg_params;
int num_chg_params;
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the wireless-next tree with the wireless tree
Hi John,
Today's linux-next merge of the wireless-next tree got a conflict in
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c between commit
3e4f319dacc6 ("brcmfmac: fix end of loop check (signedness bug)") from
the wireless tree and commit 81118d165811 ("brcmfmac: Using zero instead
of NULL") from the wireless-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
index 411dfe7,b27e245..000
--- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
@@@ -3972,8 -3972,8 +3972,8 @@@ brcmf_set_management_ie(struct brcmf_cf
u8 *iovar_ie_buf;
u8 *curr_ie_buf;
u8 *mgmt_ie_buf = NULL;
- u32 mgmt_ie_buf_len;
+ int mgmt_ie_buf_len;
- u32 *mgmt_ie_len = 0;
+ u32 *mgmt_ie_len;
u32 del_add_ie_buf_len = 0;
u32 total_ie_buf_len = 0;
u32 parsed_ie_buf_len = 0;
pgpmo2mUmzmgr.pgp
Description: PGP signature
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, 2012-10-21 at 00:19 +0200, Marcin Slusarz wrote:
> On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> > On 20.10.2012, Marcin Slusarz wrote:
> >
> > > Try this one.
> >
> > It works, now I can boot again. However, nouveau seems to be dead now.
> > The dmesg output with your patch on top of 3.7-rc1 is:
> >
> > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
> > minor 0
> > [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
> > [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> > [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50
> > [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for
> > image...
> > [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found
> > [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for image...
> > [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found
> > [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for image...
> > [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond
> > end of region [VROM] (length 24) (20120913/exfldio-210)
> > [3.704139] ACPI Error: Method parse/execution
> > failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8),
> > AE_AML_REGION_LIMIT (20120913/psparse-536)
> > [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> > [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found
> > [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for
> > image...
> > [3.724111] nouveau :01:00.0: Invalid ROM contents
> > [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found
> > [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable
> > image
> > [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create
> > 0x1001, -22
> > [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> > [3.736097] nouveau: probe of :01:00.0 failed with error -22
> > [3.740523] dracut: Starting plymouth daemon
>
> Hmm, maybe we can't fetch 3 bytes only...
Yeah, I noticed this issue myself on a machine here while backporting
the patch to another (older) kernel. I assumed (wrongly, apparently)
that there was just a bug in the older kernel's ACPI implementation that
had been fixed upstream already (I didn't see it on the same machine
with the current kernel)... So, I didn't send the patch.
I'll queue it up with a -fixes batch later today.
Sorry about the trouble,
Ben.
>
> Let's check this:
>
> ---
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> index 824eea0..8bd71aa 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> @@ -192,14 +192,16 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
> {
> struct pci_dev *pdev = nv_device(bios)->pdev;
> int ret, cnt, i;
> - u8 data[3];
> + u8 *data;
>
> if (!nouveau_acpi_rom_supported(pdev))
> return;
>
> bios->size = 0;
> - if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
> + data = kmalloc(4096, GFP_KERNEL);
> + if (data && nouveau_acpi_get_bios_chunk(data, 0, 4096) >= 3)
> bios->size = data[2] * 512;
> + kfree(data);
> if (!bios->size)
> return;
>
> ---
>
> Please attach acpidump output.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the xtensa tree with Linus' tree
Hi Stephen,
Sorry, I accidentally pushed this patch up; should be fixed the next
next time you pull.
Thanks,
-Chris
On 10/21/2012 04:40 PM, Stephen Rothwell wrote:
Hi Chris,
Today's linux-next merge of the xtensa tree got a conflict in
arch/xtensa/include/uapi/asm/unistd.h between commit 7216cabfff51
("xtensa: add missing system calls to the syscall table") from Linus'
tree and commit daff2ab722aa ("xtensa: add missing system calls to the
syscall table") from the xtensa tree.
These clearly were meant to be the same patch but the on in Linus' tree
has a later date, so I used it and can carry the fix as necessary (no
action is required).
Also, the top most commit in the xtensa tree has no signed-off-by line or
any real commit message. Please fix that up.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] fat: editions to support fat_fallocate()
Namjae Jeon writes: >> The expectation of fallocate() is just for space reservation? If it was >> just for space reservation, I'm not sure, why TV applications can't >> reserve in userland without any kernel help (I wonder who interrupts TV >> application). I feel a bit, it may be more lightweight than fallocate(), >> and more reliable than out of spec fallocate(). >> >> I'm still not sure why apps really want fallocate() on FAT. > Yes, it is for user space reservation. > >>From the application perspective it is needed to realize in advance > how much space is needed for that file write – so the requirement is > precisely that the space reserved is entirely for me and no other I/O > operation in that time should consume the space. > > Of course, as you said, space can be pre-allocated from user space by > doing expanding truncate. > Main drawbacks for reserving through USER space: > 1) If we need to allocate 1GB space -> seek (1GB) and write -> it will > ZEROUT the 1GB area (which is very time consuming) just for reserving > space. > 2) The Application must always be aware of the SEEK OFFSET - otherwise > the APPEND WRITE will never occur and file is closed/opened (Append > mode) again for writing – it will instead start writing from the end > of file which is past the reserved space. So, this will also result in > losing space in such case – if application is not keeping track of > OFFSET > 3) If suppose from user space we are doing expanding truncate of 1GB > and suppose it fails after 256MB of allocation - in that case it did > allocation of 256MB blocks - did ZEROUT for all these blocks and then > returned failure - which is not optimal for just allocation of space. > > While if we make use of FALLOCATE > 1)It allows reserving the space in advance without any delay. > 2)Since, the space is reserved in advance. So, if suppose space is > reserved for 1hour TV recording than any other application in the > background cannot cause recording to fail in case of “no free space” > left as it already pre-allocated space. Only other Applications will > close. > 3)It allows for APPEND write to continue smoothly without actually > keeping track of the file state, offset. > 4)Initially when the disk is not fragmented. It allows the > possibility to get contiguous blocks and thus reducing fragmentation > for that file. OK. Should TV recorder make sure it is reserving space with fallocate() for each open() (or first open() after mount())? What fsck is going to do? Or how to know fallocated space or corrupted space? Does this break the linux fat driver doesn't know about this fallocate()? If so, it sounds like to be easy to break existent drivers. Thanks. -- OGAWA Hirofumi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the xtensa tree with Linus' tree
Hi Chris,
Today's linux-next merge of the xtensa tree got a conflict in
arch/xtensa/include/uapi/asm/unistd.h between commit 7216cabfff51
("xtensa: add missing system calls to the syscall table") from Linus'
tree and commit daff2ab722aa ("xtensa: add missing system calls to the
syscall table") from the xtensa tree.
These clearly were meant to be the same patch but the on in Linus' tree
has a later date, so I used it and can carry the fix as necessary (no
action is required).
Also, the top most commit in the xtensa tree has no signed-off-by line or
any real commit message. Please fix that up.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp8d5670GlGR.pgp
Description: PGP signature
Re: [PATCH v4 1/7] uio: uio_pruss: replace private SRAM API with genalloc
On Thu, Oct 18, 2012 at 10:53:38AM -0400, Matt Porter wrote:
> On Fri, Oct 05, 2012 at 01:04:40PM -0400, Matt Porter wrote:
> > Remove the use of the private DaVinci SRAM API in favor
> > of genalloc. The pool to be used is provided by platform
> > data.
> >
> > Signed-off-by: Matt Porter
>
> Hans,
>
> Any additional concerns on this patch?
Not from my side. I was waiting for your discussion to calm down.
> Sekhar is holding off on applying
> parts 4,5,7 for davinci until this is accepted.
You can add my
Signed-off-by: "Hans J. Koch"
Thanks,
Hans
>
> Thanks,
> Matt
>
> > ---
> > drivers/uio/Kconfig |1 +
> > drivers/uio/uio_pruss.c | 24 +---
> > include/linux/platform_data/uio_pruss.h |3 ++-
> > 3 files changed, 20 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> > index 6f3ea9b..c48b938 100644
> > --- a/drivers/uio/Kconfig
> > +++ b/drivers/uio/Kconfig
> > @@ -97,6 +97,7 @@ config UIO_NETX
> > config UIO_PRUSS
> > tristate "Texas Instruments PRUSS driver"
> > depends on ARCH_DAVINCI_DA850
> > + select GENERIC_ALLOCATOR
> > help
> > PRUSS driver for OMAPL138/DA850/AM18XX devices
> > PRUSS driver requires user space components, examples and user space
> > diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
> > index 33a7a27..f8738de 100644
> > --- a/drivers/uio/uio_pruss.c
> > +++ b/drivers/uio/uio_pruss.c
> > @@ -25,7 +25,7 @@
> > #include
> > #include
> > #include
> > -#include
> > +#include
> >
> > #define DRV_NAME "pruss_uio"
> > #define DRV_VERSION "1.0"
> > @@ -65,10 +65,11 @@ struct uio_pruss_dev {
> > dma_addr_t sram_paddr;
> > dma_addr_t ddr_paddr;
> > void __iomem *prussio_vaddr;
> > - void *sram_vaddr;
> > + unsigned long sram_vaddr;
> > void *ddr_vaddr;
> > unsigned int hostirq_start;
> > unsigned int pintc_base;
> > + struct gen_pool *sram_pool;
> > };
> >
> > static irqreturn_t pruss_handler(int irq, struct uio_info *info)
> > @@ -106,7 +107,9 @@ static void pruss_cleanup(struct platform_device *dev,
> > gdev->ddr_paddr);
> > }
> > if (gdev->sram_vaddr)
> > - sram_free(gdev->sram_vaddr, sram_pool_sz);
> > + gen_pool_free(gdev->sram_pool,
> > + gdev->sram_vaddr,
> > + sram_pool_sz);
> > kfree(gdev->info);
> > clk_put(gdev->pruss_clk);
> > kfree(gdev);
> > @@ -152,10 +155,17 @@ static int __devinit pruss_probe(struct
> > platform_device *dev)
> > goto out_free;
> > }
> >
> > - gdev->sram_vaddr = sram_alloc(sram_pool_sz, &(gdev->sram_paddr));
> > - if (!gdev->sram_vaddr) {
> > - dev_err(>dev, "Could not allocate SRAM pool\n");
> > - goto out_free;
> > + if (pdata->sram_pool) {
> > + gdev->sram_pool = pdata->sram_pool;
> > + gdev->sram_vaddr =
> > + gen_pool_alloc(gdev->sram_pool, sram_pool_sz);
> > + if (!gdev->sram_vaddr) {
> > + dev_err(>dev, "Could not allocate SRAM pool\n");
> > + goto out_free;
> > + }
> > + gdev->sram_paddr =
> > + gen_pool_virt_to_phys(gdev->sram_pool,
> > + gdev->sram_vaddr);
> > }
> >
> > gdev->ddr_vaddr = dma_alloc_coherent(>dev, extram_pool_sz,
> > diff --git a/include/linux/platform_data/uio_pruss.h
> > b/include/linux/platform_data/uio_pruss.h
> > index f39140a..3d47d21 100644
> > --- a/include/linux/platform_data/uio_pruss.h
> > +++ b/include/linux/platform_data/uio_pruss.h
> > @@ -20,6 +20,7 @@
> >
> > /* To configure the PRUSS INTC base offset for UIO driver */
> > struct uio_pruss_pdata {
> > - u32 pintc_base;
> > + u32 pintc_base;
> > + struct gen_pool *sram_pool;
> > };
> > #endif /* _UIO_PRUSS_H_ */
> > --
> > 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/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quick question: Maintainers for scripts
Hi everyone, I was just wondering - Since (last time I looked, anyway), /scripts/* has no maintainer, who would I send patches to? Would I just send them to the mailing list, or is there a sort of catch-all maintainer for things like this? Thanks in advance, and sorry if this is already answered :) ~Cruz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: fix async request mechanism for sequential read scenarios
On Sun, Oct 14, 2012 at 6:17 PM, Konstantin Dorfman wrote: > On Thu, 11 Oct 2012 17:19:01 +0200, Per Forlin > wrote: > Hello Per, > >>I would like to start with some basic comments. >> >>1. Is this read sequential issue specific to MMC? >>2. Or is it common with all other block-drivers that gets data from >>the block layer (SCSI/SATA etc) ? >>If (#2) can the issue be addressed inside the block layer instead? >> >>BR >>Per > This issue specific to MMC, others block drivers probably not using > MMC mechanism for async request (or have more kernel threads for > processing incoming blk requests). > I think, since MMC actively fetches requests from block layer queue, > the solution has nothing to do with block layer context. > >> >>On Tue, Oct 2, 2012 at 5:39 PM, Konstantin Dorfman >> wrote: >>> The main assumption of the async request design is that the file >>> system adds block requests to the block device queue asynchronously >>> without waiting for completion (see the Rationale section of >>> https://wiki.linaro.org/WorkingGroups/Kernel/Specs >>> /StoragePerfMMC-async-req). >>> >>> We found out that in case of sequential read operations this is not >>> the case, due to the read ahead mechanism. >>Would it be possible to improve this mechanism to achieve the same result? >>Allow an outstanding read ahead request on top of the current ongoing one. >> > > I need to look on this mechanism, but from first glance such > behaviour may be result of libc/vfs/fs decisions and too complex > comparing to the patch we are talking about. One observation I have made is that if setting the mmc_req_size to half READ_AHEAD changes the way block layer adds request to the MMC queue. Extract from https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req#Unresolved_issues Forcing mmc host driver to set mmc_req_size 64k results in this behaviour. dd if=/dev/mmcblk0 of=/dev/null bs=4k count=256 [mmc_queue_thread] req d955f9b0 blocks 32 [mmc_queue_thread] req (null) blocks 0 [mmc_queue_thread] req (null) blocks 0 [mmc_queue_thread] req d955f9b0 blocks 64 [mmc_queue_thread] req (null) blocks 0 [mmc_queue_thread] req d955f8d8 blocks 128 [mmc_queue_thread] req (null) blocks 0 [mmc_queue_thread] req d955f9b0 blocks 128 [mmc_queue_thread] req d955f800 blocks 128 [mmc_queue_thread] req d955f8d8 blocks 128 [mmc_queue_thread] req d955fec0 blocks 128 [mmc_queue_thread] req d955f800 blocks 128 [mmc_queue_thread] req d955f9b0 blocks 128 [mmc_queue_thread] req d967cd30 blocks 128 This shows that the block layer can add request in a more asynchronous manner. I have not investigate that mechanism enough to say what can be done. Do you have an explanation to why the block layer behaves like this? BR Per > > > -- > Konstantin Dorfman, > QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Linux KVM tool for v3.7-rc0
On Sun, Oct 21, 2012 at 01:29:35PM +0200, richard -rw- weinberger wrote: > Every kernel developer has his own wrapper script to make qemu usable. > IMHO it's time to add such a script to the kernel tree. One observation I'll make is that for many people, what you want to do is a *lot* more than just simply create a wrapper script to fire up qemu. For me to do my testing, I want to build a kernel on the host OS, and then fire up a script which fires up xfstests and runs it with a collection of different file system mount options to do my ext4 testing. I've shared that here: git://git.kernel.org/pub/scm/fs/ext2/xfstests-bld.git where the host-side scripts are in the kvm-xfstests directory, and the guest-side scripts are in the kvm-autorun directory. I can pass in a set of fs configurations and xfstest test numbers via the command line on the host os, i.e., "kvm-xfstests -c 4k,ext4,nojournal 13,225,245,246". And then afterwards the scripts parse out the test output and summarizes so it's easy to see what passed and what failed. So the bottom line is that for me at least, starting up qemu is a very tiny part of what I need to do in order to do my testing. If you want to really encourage good testing, what would be better is to encourage more people to create standardized testing and benchmarking scripts that many kernel developers can easily run. And those are going to be complex enough that I don't think it makes sense for them to live in the kernel tree. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Git v1.8.0
The latest feature release Git v1.8.0 is now available at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: a03afc33f8f0723ad12649d79f1e8968526b4bf7 git-1.8.0.tar.gz 93c860cf4cd26d4b3e269b0903b833db1c1f0f8e git-htmldocs-1.8.0.tar.gz a6fa49be36f265e85b7252d36364d4c7f38530ea git-manpages-1.8.0.tar.gz Also the following public repositories all have a copy of the v1.8.0 tag and the master branch that the tag points at: url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Enjoy. Git v1.8.0 Release Notes Backward compatibility notes In the next major release (not *this* one), we will change the behavior of the "git push" command. When "git push [$there]" does not say what to push, we have used the traditional "matching" semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). We will use the "simple" semantics that pushes the current branch to the branch with the same name, only when the current branch is set to integrate with that remote branch. There is a user preference configuration variable "push.default" to change this, and "git push" will warn about the upcoming change until you set this variable in this release. "git branch --set-upstream" is deprecated and may be removed in a relatively distant future. "git branch [-u|--set-upstream-to]" has been introduced with a saner order of arguments. Updates since v1.7.12 - UI, Workflows & Features * A credential helper for Win32 to allow access to the keychain of the logged-in user has been added. * An initial port to HP NonStop. * A credential helper to allow access to the Gnome keyring has been added. * When "git am" sanitizes the "Subject:" line, we strip the prefix from "Re: subject" and also from a less common "re: subject", but left the even less common "RE: subject" intact. Now we strip that too. * It was tempting to say "git branch --set-upstream origin/master", but that tells Git to arrange the local branch "origin/master" to integrate with the currently checked out branch, which is highly unlikely what the user meant. The option is deprecated; use the new "--set-upstream-to" (with a short-and-sweet "-u") option instead. * "git cherry-pick" learned the "--allow-empty-message" option to allow it to replay a commit without any log message. * After "git cherry-pick -s" gave control back to the user asking help to resolve conflicts, concluding "git commit" used to need to be run with "-s" if the user wants to sign it off; now the command leaves the sign-off line in the log template. * "git daemon" learned the "--access-hook" option to allow an external command to decline service based on the client address, repository path, etc. * "git difftool --dir-diff" learned to use symbolic links to prepare a temporary copy of the working tree when available. * "git grep" learned to use a non-standard pattern type by default if a configuration variable tells it to. * Accumulated updates to "git gui" has been merged. * "git log -g" learned the "--grep-reflog=" option to limit its output to commits with a reflog message that matches the given pattern. * "git merge-base" learned the "--is-ancestor A B" option to tell if A is an ancestor of B. The result is indicated by its exit status code. * "git mergetool" now allows users to override the actual command used with the mergetool.$name.cmd configuration variable even for built-in mergetool backends. * "git rebase -i" learned the "--edit-todo" option to open an editor to edit the instruction sheet. Foreign Interface * "git svn" has been updated to work with SVN 1.7. * "git p4" learned the "--conflicts" option to specify what to do when encountering a conflict during "p4 submit". Performance, Internal Implementation, etc. * Git ships with a fall-back regexp implementation for platforms with buggy regexp library, but it was easy for people to keep using their platform regexp by mistake. A new test has been added to check this. * The "check-docs" build target has been updated and greatly simplified. * The test suite is run under MALLOC_CHECK_ when running with a glibc that supports the feature. * The documentation in the TeXinfo format was using indented output for materials meant to be examples that are better typeset in monospace. * Compatibility wrapper around some mkdir(2) implementations that reject parameters with trailing slash has been introduced. * Compatibility wrapper for systems that lack usable setitimer() has been added. *
Re: BUG: 1bbbbe7 (x86: Exclude E820_RESERVED regions...) PANIC on boot
On 10/21/12 14:06, Jacob Shin wrote: > On Sun, Oct 21, 2012 at 10:51:35AM -0700, Tom Rini wrote: >> On 10/20/12 21:18, Jacob Shin wrote: >>> On Sat, Oct 20, 2012 at 09:01:43PM -0700, Yinghai Lu wrote: On Sat, Oct 20, 2012 at 5:17 PM, Tom Rini wrote: > On 10/20/12 17:11, Shin, Jacob wrote: >> Hi could you please attach the dmesg output? Before rc2 is fine as well. >> I would like to see the E820 table. Thank you, > > dmesg is quite long so I've put it on pastebin: > http://pastebin.com/4eSPEAvB > > -- [0.00] BIOS-e820: [mem 0x00011000-0x00042fff] usable pre-calculate table size is too small, so it crashes. >>> >>> Right, >>> >>> I think just this one patch 3/6 on top of -rc2 should work: >>> >>> https://lkml.org/lkml/2012/8/29/223 >>> >>> That would be a simpler path for 3.7, >> >> It doesn't apply easily (for me) on top of 3.7-rc2 however. Happy to >> test a patch on top of 3.7-rc2 when you're able to. > > Ah, sorry, this one should apply on top of 3.7-rc2: > > https://lkml.org/lkml/2012/8/24/469 > > Could you try that? Just that single patch, not the whole patchset. That fixes it, replied with a note and Tested-by, thanks! -- Tom -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] x86: find_early_table_space based on memory ranges that are being mapped
On Fri, Aug 24, 2012 at 06:55:13PM -0500, Jacob Shin wrote: > Current logic finds enough space for direct mapping page tables from 0 > to end. Instead, we only need to find enough space to cover mr[0].start > to mr[nr_range].end -- the range that is actually being mapped by > init_memory_mapping() > > This patch also reportedly fixes suspend/resume issue reported in: > > https://lkml.org/lkml/2012/8/11/83 > > Signed-off-by: Jacob Shin This fixes a bug I see that was introduced in 1e7 Tested-by: Tom Rini -- Tom -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: BUG: 1bbbbe7 (x86: Exclude E820_RESERVED regions...) PANIC on boot
On Sun, Oct 21, 2012 at 10:51:35AM -0700, Tom Rini wrote: > On 10/20/12 21:18, Jacob Shin wrote: > > On Sat, Oct 20, 2012 at 09:01:43PM -0700, Yinghai Lu wrote: > >> On Sat, Oct 20, 2012 at 5:17 PM, Tom Rini wrote: > >>> On 10/20/12 17:11, Shin, Jacob wrote: > Hi could you please attach the dmesg output? Before rc2 is fine as well. > I would like to see the E820 table. Thank you, > >>> > >>> dmesg is quite long so I've put it on pastebin: > >>> http://pastebin.com/4eSPEAvB > >>> > >>> -- > >> > >> [0.00] BIOS-e820: [mem 0x00011000-0x00042fff] > >> usable > >> > >> pre-calculate table size is too small, so it crashes. > > > > Right, > > > > I think just this one patch 3/6 on top of -rc2 should work: > > > > https://lkml.org/lkml/2012/8/29/223 > > > > That would be a simpler path for 3.7, > > It doesn't apply easily (for me) on top of 3.7-rc2 however. Happy to > test a patch on top of 3.7-rc2 when you're able to. Ah, sorry, this one should apply on top of 3.7-rc2: https://lkml.org/lkml/2012/8/24/469 Could you try that? Just that single patch, not the whole patchset. Thanks! -Jacob > > -- > Tom > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On 21.10.2012 22:43, Artem S. Tashkinov wrote: >> Nice. Could you do that again with the patch applied I sent yo some >> hours ago? > > That patch was of no help - the system has crashed and I couldn't spot > relevant > messages. > > I've no idea what it means. The sequence of driver callbacks issued on a stream start is .open() .hw_params() .prepare() .trigger() If the ALSA part really causes this issue, the bad things happen either in any of the driver callback functions or in the core underneath. The patch I sent returns an error from the hw_params callback, and as you still see the problem, that means that the crash happens before any of the USB audio streaming really starts. Could you try and return -EINVAL from snd_usb_capture_open() please? If anyone has a better idea on how to debug this, please chime in. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
> Nice. Could you do that again with the patch applied I sent yo some > hours ago? That patch was of no help - the system has crashed and I couldn't spot relevant messages. I've no idea what it means. Artem -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Re: Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On Sun, Oct 21, 2012 at 07:49:01PM +, Artem S. Tashkinov wrote: > I ran it this way: while :; do dmesg -c; done | scat /dev/sda11 (yes, > straight to a hdd partition to eliminate a FS cache) Well, I'm no fs guy but this should still go through the buffer cache. I think the O_SYNC flag makes sure it all lands on the partition in time. Oh well, it doesn't matter. > Don't judge me harshly - I'm not a programmer. If you wrote that and you're not a programmer, it certainly looks cool, good job!. [ Btw, don't forget to free(buffer) at the end. ] Also, there was a patchset recently which added a blockconsole method to the kernel with which you can do something like that in a generic way. Back to the issue at hand: it looks like ehci_hcd is causing some list corruptions, maybe coming from the uvcvideo or whatever. I think the usb people will have a better idea. Btw, is there any particular reason you're running a 32-bit kernel? Thanks. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ACPICA: Don't leak next_walk_state in acpi_ds_call_control_method()
If acpi_ds_create_walk_state() succeeds, but the call to
ACPI_ALLOCATE_ZEROED() fails, then we'll return from the function
without properly freeing 'next_walk_state'.
Signed-off-by: Jesper Juhl
---
drivers/acpi/acpica/dsmethod.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/acpica/dsmethod.c b/drivers/acpi/acpica/dsmethod.c
index aa9a5d4..ade59a3 100644
--- a/drivers/acpi/acpica/dsmethod.c
+++ b/drivers/acpi/acpica/dsmethod.c
@@ -378,7 +378,8 @@ acpi_ds_call_control_method(struct acpi_thread_state
*thread,
*/
info = ACPI_ALLOCATE_ZEROED(sizeof(struct acpi_evaluate_info));
if (!info) {
- return_ACPI_STATUS(AE_NO_MEMORY);
+ status = AE_NO_MEMORY;
+ goto cleanup;
}
info->parameters = _walk_state->operands[0];
--
1.7.1
--
Jesper Juhlhttp://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] vfs: fix: don't increase bio_slab_max if krealloc() fails
bio.c: fix: don't increase bio_slab_max if krealloc() of bio_slabs fails
Signed-off-by: Anna Leuschner
---
fs/bio.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/bio.c b/fs/bio.c
index 9298c65..b96fc6c 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -75,6 +75,7 @@ static struct kmem_cache *bio_find_or_create_slab(unsigned
int extra_size)
unsigned int sz = sizeof(struct bio) + extra_size;
struct kmem_cache *slab = NULL;
struct bio_slab *bslab, *new_bio_slabs;
+ unsigned int new_bio_slab_max;
unsigned int i, entry = -1;
mutex_lock(_slab_lock);
@@ -97,12 +98,13 @@ static struct kmem_cache *bio_find_or_create_slab(unsigned
int extra_size)
goto out_unlock;
if (bio_slab_nr == bio_slab_max && entry == -1) {
- bio_slab_max <<= 1;
+ new_bio_slab_max = bio_slab_max << 1;
new_bio_slabs = krealloc(bio_slabs,
-bio_slab_max * sizeof(struct bio_slab),
+new_bio_slab_max * sizeof(struct
bio_slab),
GFP_KERNEL);
if (!new_bio_slabs)
goto out_unlock;
+ bio_slab_max = new_bio_slab_max;
bio_slabs = new_bio_slabs;
}
if (entry == -1)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] Prevent devices with RMRRs from being placed into SI Domain
On 10/17/2012 2:17 PM, Tom Mingarelli wrote:
This patch is to prevent devices that have RMRRs associated with them to
not be placed into the SI Domain during init. We don't put USB devices
into this category, however. This fixes the issue where the RMRR info
for devices being placed in and out of the SI Domain gets lost.
Signed-off-by: Thomas Mingarelli
Tested-by: Shuah Khan
PATCH v1: https://lkml.org/lkml/2012/6/15/204
PATCH v2: https://lkml.org/lkml/2012/9/18/354
drivers/iommu/intel-iommu.c | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff -up ./drivers/iommu/intel-iommu.c.ORIG ./drivers/iommu/intel-iommu.c
--- ./drivers/iommu/intel-iommu.c.ORIG 2012-10-16 09:34:23.148089944 -0500
+++ ./drivers/iommu/intel-iommu.c 2012-10-17 20:41:40.509642356 -0500
@@ -2320,8 +2320,38 @@ static int domain_add_dev_info(struct dm
return 0;
}
+static bool device_has_rmrr(struct pci_dev *dev)
+{
+ struct dmar_rmrr_unit *rmrr;
+ int i;
+
+ for_each_rmrr_units(rmrr) {
+ for (i = 0; i < rmrr->devices_cnt; i++) {
+ /*
+* Here we are just concerned with checking each device
+* that has an RMRR associated with it and not allow it
+* to be placed into the SI Domain during startup.
+ */
+ if (rmrr->devices[i] == dev)
+ return true;
+ }
+ }
+ return false;
+}
+
static int iommu_should_identity_map(struct pci_dev *pdev, int startup)
{
+
+ /*
+* This is where we will refuse any device that has an
+* RMRR associated with it and is not a USB device and
+* NOT allow it to be placed into the SI Domain. We don't
+* need a separate bit for this because it could be ANY device.
+*/
+ if (device_has_rmrr(pdev) &&
+ (pdev->class >> 8) != PCI_CLASS_SERIAL_USB)
+ return 0;
+
if ((iommu_identity_mapping & IDENTMAP_AZALIA) && IS_AZALIA(pdev))
return 1;
___
iommu mailing list
io...@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
.
I applied this patch to my system and booted with IOMMU pass through
mode enabled. Without the patch my system would panic or wedge. I also
applied a be2net patch I'm working on and was able to get successful
netperf runs with IOMMU pass through mode enabled.
-Craig
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sunday 21 October 2012 16:49:08 Marcin Slusarz wrote:
> On Sun, Oct 21, 2012 at 07:38:58AM -0700, Linus Torvalds wrote:
> > On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz
> >
> > wrote:
> > > This looks like ACPI bug...
> >
> > I'm shocked to hear that firmware would be fragile.
> >
> > Anyway, here's the #1 thing to keep in mind about firmware:
> >
> > - firmware is always buggy.
>
> I know. But this bug is not about broken firmware. It's about Linux kernel
> ACPI implementation, which (I think) wrongly interprets ACPI script.
The ACPI implementation is fine, it is just the fw engineers that suck. I see I
have not cc'd the linux-vger ml when replying to a previous mail. I'll paste
it below:
Since commit 9a334cd "drm/nouveau/bios: fix shadowing of ACPI ROMs larger than
64KiB" chunks are not always read in multiples of 4KiB anymore (less is
possible). That is the only obvious thing I can think of atm (besides the
kmalloc(0) bug for which Martin submitted a patch in the previous mail).
Do you still still have an Asus laptop with the same BIOS as in
https://bugzilla.kernel.org/show_bug.cgi?id=19702? (if yes, then the acpidump
from that bug still applies).
This is the ACPI _ROM method that is being called:
Method (_ROM, 2, NotSerialized) // _ROM: Read-Only Memory
{
Add (Arg0, RBUF, Local0)
ShiftLeft (Arg1, 0x03, Local1) // times 8, bytes to bits?
Name (VBUF, Buffer (Arg1) {})
OperationRegion (VROM, SystemMemory, Local0, Local1)
Field (VROM, ByteAcc, NoLock, Preserve)
{
ROMI, 65536
}
Store (ROMI, VBUF)
Return (VBUF)
}
Arg0 is the offset (0 when first reading the size), Arg1 is the number of read
bytes (3). Note the use of Local1 in OperationRegion. The meaning there is
bytes, but a multiple of the requested bytes is passed. So if we request 4096
bytes, we end up with a VROM of size 32KiB. ROMI is 65536 bits (or 8192
bytes), hence reading 4096 does not give errors. But reading only 3 bytes will
fail. Martin, I saw your second patch (https://lkml.org/lkml/2012/10/20/150)
which takes care of the first case, but it skips the case where the ROM is of
an odd size (does that even happen, something like 64KiB+1 bytes? No idea.)
Addition: Conclusion: this means that the request must have a length must be
at least 1 KiB or it will fail with the ACPI error that you have seen before.
This AML snippet suck.
Regards,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On 21.10.2012 21:49, Artem S. Tashkinov wrote: >> >> On Oct 21, 2012, Borislav Petkov wrote: >> >> On Sun, Oct 21, 2012 at 11:59:36AM +, Artem S. Tashkinov wrote: >>> http://imageshack.us/a/img685/9452/panicz.jpg >>> >>> list_del corruption. prev->next should be ... but was ... >> >> Btw, this is one of the debug options I told you to enable. >> >>> I cannot show you more as I have no serial console to use :( and the kernel >>> doesn't have enough time to push error messages to rsyslog and fsync >>> /var/log/messages >> >> I already told you how to catch that oops: boot with "pause_on_oops=600" >> on the kernel command line and photograph the screen when the first oops >> happens. This'll show us where the problem begins. > > This option didn't have any effect, or maybe it's because it's such a serious > crash > the kernel has no time to actually print an ooops/panic message. > > dmesg messages up to a crash can be seen here: > https://bugzilla.kernel.org/attachment.cgi?id=84221 Nice. Could you do that again with the patch applied I sent yo some hours ago? Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/5] rtc: omap: dt support
On 19.10.2012 11:59, Afzal Mohammed wrote:
> enhance rtc-omap driver with DT capability
>
> Signed-off-by: Afzal Mohammed
> Acked-by: Sekhar Nori
> ---
>
> v4:
> Proper devicetree documentation
>
> v2:
> Use compatible as ti,da830-rtc instead of ti,am1808-rtc
>
> Documentation/devicetree/bindings/rtc/rtc-omap.txt | 17 +
> drivers/rtc/rtc-omap.c | 18 ++
> 2 files changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/rtc-omap.txt
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> new file mode 100644
> index 000..b47aa41
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> @@ -0,0 +1,17 @@
> +TI Real Time Clock
> +
> +Required properties:
> +- compatible: "ti,da830-rtc"
> +- reg: Address range of rtc register set
> +- interrupts: rtc timer, alarm interrupts in order
> +- interrupt-parent: phandle for the interrupt controller
> +
> +Example:
> +
> +rtc@1c23000 {
> + compatible = "ti,da830-rtc";
> + reg = <0x23000 0x1000>;
> + interrupts = <19
> + 19>;
> + interrupt-parent = <>;
> +};
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index d948426..dff9ff4 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -20,6 +20,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
>
> @@ -298,6 +300,8 @@ static struct rtc_class_ops omap_rtc_ops = {
> static int omap_rtc_alarm;
> static int omap_rtc_timer;
>
> +#define OMAP_RTC_DATA_DA830_IDX 1
> +
> static struct platform_device_id omap_rtc_devtype[] = {
> {
> .name = DRIVER_NAME,
> @@ -309,12 +313,25 @@ static struct platform_device_id omap_rtc_devtype[] = {
> };
> MODULE_DEVICE_TABLE(platform, omap_rtc_devtype);
>
> +static const struct of_device_id omap_rtc_of_match[] = {
> + { .compatible = "ti,da830-rtc",
> + .data = _rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
Wouldn't it make sense to list all the compatible models here? The
advantage of a compatible list is that we can name the models
explicitly, or maybe at least "davinci-rtc". Is there any reason for
this particular name?
Daniel
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
> +
> static int __init omap_rtc_probe(struct platform_device *pdev)
> {
> struct resource *res, *mem;
> struct rtc_device *rtc;
> u8 reg, new_ctrl;
> const struct platform_device_id *id_entry;
> + const struct of_device_id *of_id;
> +
> + of_id = of_match_device(omap_rtc_of_match, >dev);
> + if (of_id)
> + pdev->id_entry = of_id->data;
>
> omap_rtc_timer = platform_get_irq(pdev, 0);
> if (omap_rtc_timer <= 0) {
> @@ -510,6 +527,7 @@ static struct platform_driver omap_rtc_driver = {
> .driver = {
> .name = DRIVER_NAME,
> .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(omap_rtc_of_match),
> },
> .id_table = omap_rtc_devtype,
> };
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Re: Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
>
> On Oct 21, 2012, Borislav Petkov wrote:
>
> On Sun, Oct 21, 2012 at 11:59:36AM +, Artem S. Tashkinov wrote:
> > http://imageshack.us/a/img685/9452/panicz.jpg
> >
> > list_del corruption. prev->next should be ... but was ...
>
> Btw, this is one of the debug options I told you to enable.
>
> > I cannot show you more as I have no serial console to use :( and the kernel
> > doesn't have enough time to push error messages to rsyslog and fsync
> > /var/log/messages
>
> I already told you how to catch that oops: boot with "pause_on_oops=600"
> on the kernel command line and photograph the screen when the first oops
> happens. This'll show us where the problem begins.
This option didn't have any effect, or maybe it's because it's such a serious
crash
the kernel has no time to actually print an ooops/panic message.
dmesg messages up to a crash can be seen here:
https://bugzilla.kernel.org/attachment.cgi?id=84221
I dumped them using this application:
$ cat scat.c
#include
#include
#include
#include
#include
#include
#include
#define O_LARGEFILE 010
#define BUFFER 4096
#define __USE_FILE_OFFSET64 1
#define __USE_LARGEFILE64 1
int main(int argc, char *argv[])
{
int fd_out;
int64_t bytes_read;
void *buffer;
if (argc!=2) {
printf("Usage is: scat destination\n");
return 1;
}
buffer = malloc(BUFFER * sizeof(char));
if (buffer == NULL) {
printf("Error: can't allocate buffers\n");
return 2;
}
memset(buffer, 0, BUFFER);
printf("Dumping to \"%s\" ... ", argv[1]);
fflush(NULL);
if ((fd_out = open64(argv[1], O_WRONLY | O_LARGEFILE | O_SYNC |
O_NOFOLLOW, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH)) == -1) {
printf("Error: destination file can't be created\n");
perror("open() ");
return 2;
}
bytes_read = 1;
while (bytes_read) {
bytes_read = fread(buffer, sizeof(char), BUFFER, stdin);
if (write(fd_out, (void *) buffer, bytes_read) != bytes_read)
{
printf("Error: can't write data to the destination
file! Possibly a target disk is full\n");
return 3;
}
}
close(fd_out);
printf(" OK\n");
return 0;
}
I ran it this way: while :; do dmesg -c; done | scat /dev/sda11 (yes, straight
to a hdd partition to eliminate a FS cache)
Don't judge me harshly - I'm not a programmer.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] uprobes: allow ignoring of probe hits
On 10/21, Rabin Vincent wrote: > > On Wed, Oct 17, 2012 at 07:35:10PM +0200, Oleg Nesterov wrote: > > > > And, to clarify, I am not arguing. Just curious. > > > > So, is this like cmov on x86? And this patch allows to not report if > > the condition is not true? Or there are other issues on arm? > > Yes, I guess this is like CMOV on x86. In the ARM instruction set most > instructions can be conditionally executed. > > In order to set the probe on a conditional instruction, we use an > undefined instruction with the same condition as the instruction we > replace. However, it is implementation defined whether an undefined > instruction with a failing condition code will trigger an undefined > instruction exception or just be executed as a NOP. So for those > processor implementations where we do get the undefined instruction > exception even for a failing condition code, we have to ignore it in > order to provide consistent behaviour. OK, I see, thanks for your explanation. 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: cryptsetup not working under 3.6 - regression from 3.4?
On 10/21/2012 02:36 PM, Tvrtko Ursulin wrote: > On 21/10/12 13:20, Zdenek Kaspar wrote: I would say you are still missing some modules. > Kernel says this: > device-mapper: table: 252:1: crypt: Error allocating crypto tfm > device-mapper: ioctl: error adding target to table It complains about aes-cbc-essiv:sha256. It can be missing CBC od SHA256, but according the message I bet you have no "cbc" block cipher mode module compiled. Can you grep your final .config for CONFIG_CRYPTO_CBC and CONFIG_CRYPTO_SHA256 a paste it here? >>> >>> I both working 3.4 and non-working 3.6 situation is the same: >>> >>> CONFIG_CRYPTO_CBC=y >>> CONFIG_CRYPTO_SHA256=m >> >> Compare please: >> grep CONFIG_CRYPTO /boot/config-3.4 >> grep CONFIG_CRYPTO /boot/config-3.6 >> >> One of the problem could be that your configuration misses something >> like: CONFIG_CRYPTO_BLKCIPHER, CONFIG_CRYPTO_MANAGER, etc.. or some of >> those could changed into modules and are not getting loaded.. > > Here it is: Hm, so it should work without problem. Can you paste full output of failing cryptsetup command (with added --debug switch) and your full kernel .config? Cryptsetup itself has regression tests which test almost all common combinations of ciphers so the problem is almost surely in some kernel part misconfiguration. Any other related messages in syslog beside two lines you posted? Thanks, Milan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET cgroup/for-3.8] cgroup_freezer: allow migration regardless of freezer state and update locking
Hello, Oleg. On Sun, Oct 21, 2012 at 09:18:53PM +0200, Oleg Nesterov wrote: > > I'm waiting for Oleg to poke some holes in the synchronization > > department but if that doesn't happen you can pull from the above > > branch. I'll pull it into cgroup/for-3.8 too. > > Just in case, I see nothing bad ;) > > But let me repeat I never understood this code in details, and I > already forget everything. Heh, if you can't spot something wrong in the freezer state memory barrier dancing, I'm happy. :) Thanks a lot for taking a look. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] cgroup: cgroup_subsys->fork() should be called after the task is added to css_set
Hello, Oleg. On Sun, Oct 21, 2012 at 09:11:41PM +0200, Oleg Nesterov wrote: > A couple of off-topic questions. With or without this patch I do not > understand cgroup_fork, > > /* >* We don't need to task_lock() current because current->cgroups >* can't be changed concurrently here. The parent obviously hasn't >* exited and called cgroup_exit(), and we are synchronized against >* cgroup migration through threadgroup_change_begin(). >*/ > child->cgroups = current->cgroups; > get_css_set(child->cgroups); > > How so? threadgroup_change_begin() is only called if CLONE_THREAD. > So in theory this copy + atomic_add looks racy... It's a bug. Revert patches to restore task_lock() are already queued in cgroup/for-3.7-fixes. > And it seems that fork() can race with cgroup iterator. post_fork > will notice use_task_css_set_links, but until then the child belongs > to the parent's css and it is not "visible" to iterator (and right > after cgroup_fork() it is not visible to do_each_thread() if > use_task_css_set_links is not set). > > For example. Suppose that the child migrates to another cgroup after > copy_process() makes it visible to the user-space. Then update_if_frozen > sets CGROUP_FROZEN (again, cgroup_iter_next do not see this child). > > Now, post_fork calls freezer_fork() and hits BUG_ON(CGROUP_FROZEN). > > But again, I do not blame this patch. I'm planning to update it to, * Clear ->cgroup to %NULL during copy_process(). A new task isn't considered to be cgroup-wise active at this point. Userland is not allowed to migrate it and none of cgroup callbacks will be called. * Do all the initialization in post_fork so that a task is only allowd to be migrated and operated on cgroup-wise after ->fork() is complete. > I am starting to think again about a big-rw-lock around copy_process. > Recently I tried to add one around dup_mmap for uprobes, but perhaps > cgroups can use it too... If some other subsystems need it, maybe just make threadgroup locking coarser? I *think* I can make cgroup work correctly without a agiant rwlock there but if someone else needs it we can definitely hitch. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] drm_kms_helper problems
Hi Mark, On Sun, 21 October 2012 Mark Hounschell wrote: > On 10/21/2012 10:58 AM, Bruno Prémont wrote: > > On Sun, 21 October 2012 Mark Hounschell wrote: > >> I have a TV that appears to not provide proper EDID info to the HDMI or DVI > >> ports of my Intel DH77DF motherboard. I received some pointers from this > >> list that pointed me in the direction of creating my own EDID file and I > >> now have a binary blob that matches what the service manual says is the > >> proper EDID info. > >> > >> But I am unable to get the drm_kms_helper module to load and use this file. > >> My relevant kernel config options are. > >> > >> CONFIG_DRM_KMS_HELPER=m > >> CONFIG_DRM_LOAD_EDID_FIRMWARE=y > >> > >> my relevant kernel command line contains: > >> > >> video=card0-HDMI-A-1:e > >> drm_kms_helper.edid_firmware=card0-HDMI-A-1:edid/lg42lb9df_hdmi1.edid > > > > The variant without card0- should be the right one. > > > > OK. Changed it. What if I had more than one video card? Two connectors from two distinct card should not get the same suffix number even if they use same technology, so it should work. (unless something was changed recently) > >> The edid file: > >> # ls -al /lib/firmware/edid/lg42lb9df_hdmi1.edid > >> -rw-r--r-- 1 root root 256 Oct 16 05:46 > >> /lib/firmware/edid/lg42lb9df_hdmi1.edid > >> > >> connector info from /sys/class/drm/ > >> > >> card0 card0-DP-1 card0-DP-2 card0-DP-3 card0-HDMI-A-1 card0-HDMI-A-2 > >> card0-HDMI-A-3 card0-VGA-1 controlD64 version > >> > > Which should I use? HDMI-A-1, HDMI-A-2, or HDMI-A-3? Why re there 3?? > > >> And I don't really understand why I have 3 entries for the one hdmi port? > >> Nor do I really understand _exactly_ how to define the connector in my > >> kernel command line or which of the 3 connectors from /sys I should be > >> using. I've tried different variants. Ie. card0-HDMI-A-1and HDMI-A-1. > >> > >> The results in the kernel log file remain: > >> > >> [1.879654] drm_kms_helper: Unknown parameter `edid' > > > > As your drm_kms_helper is built modular, did you try not putting that > > parameter on kernel cmdline but rather put it in modprobe's configuration > > for that module? (may doing the whole loading manually). > > > > I've created a /etc/modprobe.d/20-drm_kms_helper.conf with: > options drm_kms_helper edid_firmware=HDMI-A-1:edid/lg42lb9df_hdmi1.edid > and now I'm getting something different. It looks like it's trying. In fact > I actually get a screen on the TV now. It's not 1920x1080 but 1024x768 at > 60hz. As things get slightly better now, check what kernel detected: - /sys/module/drm_kms_helper/parameters/edid_firmware (should contain the path to firmware file) Make sure both the firmware and modprobe config get included in your initrd if you're using one. > [1.883124] load_module: Calling parse_args for module = drm_kms_helper > args = edid_firmware=HDMI-A-1:edid/lg42lb9df_hdmi1.edid > [1.883126] > [1.883126] parse_args: (1) Entered for drm_kms_helper > [1.883127] > [1.883127] parse_args: (2) Entered for drm_kms_helper > [1.883127] parse_args: doing = drm_kms_helper > [1.883128] parse_args: args = > edid_firmware=HDMI-A-1:edid/lg42lb9df_hdmi1.edid > F\xffc9\xfff8h\xff89\xff86\xffc0\xff80\x\x\xffd4R\xffc9\xfff8TF\xffc9\xfff88\xff89\xff86\xffc0\xffa4\x\xdF\xffc9\xfff8 > [1.883129] parse_args: num = 2 > [1.883130] parse_args: min_level = -32768 > [1.883131] parse_args: max_level = 32767 > [1.883132] > F\xffc9\xfff8h\xff89\xff86\xffc0\xff80\x\x\xffd4R\xffc9\xfff8TF\xffc9\xfff88\xff89\xff86\xffc0\xffa4\x\xdF\xffc9\xfff8, > > num=2, min_level=-32768, max_level=32767 > [1.886855] > . > . > . > [2.132749] [drm] forcing HDMI-A-1 connector ON > [2.132752] [drm] forcing HDMI-A-2 connector ON > [2.132753] [drm] forcing HDMI-A-3 connector ON > > [2.189769] [drm:edid_load] *ERROR* Requesting EDID firmware > "edid/lg42lb9df_hdmi1.edid" failed (err=-2) Interesting, kernel/udev can't find the edid file but know what file to look for... Is the edid file available at that time (initrd?)? > I get a couple of the above messages. > > > [2.388623] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, > remainder is 130 > [2.388631] Raw EDID: > [2.388635] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff That's as ago with getting edid from hardware. > > # modprobe drm_kms_helper edid_firmware=HDMI-A-1:edid/lg42lb9df_hdmi1.edid > > > > I can't seem to rm the modules already loaded to try this. There are multiple steps needed to be able to rmmod those modules: - stop DRM users (e.g. X) - disable fbcon echo 1 > /sys/class/vtcon0/bind echo 0 > /sys/class/vtcon1/bind (assuming vtcon1 is fbcon, vtcon0 is VGA console) - rmmod i915 - rmmod
Re: [PATCHSET cgroup/for-3.8] cgroup_freezer: allow migration regardless of freezer state and update locking
On 10/19, Tejun Heo wrote: > > On Fri, Oct 19, 2012 at 06:54:42PM +0200, Rafael J. Wysocki wrote: > > > git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git > > > review-cgroup_freezer-locking > > > > It seems that no one has any comments. :-) > > > > Are you going to prepare a branch for me to pull from? > > I'm waiting for Oleg to poke some holes in the synchronization > department but if that doesn't happen you can pull from the above > branch. I'll pull it into cgroup/for-3.8 too. Just in case, I see nothing bad ;) But let me repeat I never understood this code in details, and I already forget everything. 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/7] cgroup: cgroup_subsys->fork() should be called after the task is added to css_set
On 10/16, Tejun Heo wrote: > > cgroup_subsys->fork() is invoked way before the new task is added to > the css_set. Plus, it called before this task (and even its task_struct) was fully initialized. All I can say is: personally I like this patch, it also simplifies copy_process(). But I am in no position to ack it. I seem to forget everything (not too much ;) I ever knew about this code. A couple of off-topic questions. With or without this patch I do not understand cgroup_fork, /* * We don't need to task_lock() current because current->cgroups * can't be changed concurrently here. The parent obviously hasn't * exited and called cgroup_exit(), and we are synchronized against * cgroup migration through threadgroup_change_begin(). */ child->cgroups = current->cgroups; get_css_set(child->cgroups); How so? threadgroup_change_begin() is only called if CLONE_THREAD. So in theory this copy + atomic_add looks racy... And it seems that fork() can race with cgroup iterator. post_fork will notice use_task_css_set_links, but until then the child belongs to the parent's css and it is not "visible" to iterator (and right after cgroup_fork() it is not visible to do_each_thread() if use_task_css_set_links is not set). For example. Suppose that the child migrates to another cgroup after copy_process() makes it visible to the user-space. Then update_if_frozen sets CGROUP_FROZEN (again, cgroup_iter_next do not see this child). Now, post_fork calls freezer_fork() and hits BUG_ON(CGROUP_FROZEN). But again, I do not blame this patch. I am starting to think again about a big-rw-lock around copy_process. Recently I tried to add one around dup_mmap for uprobes, but perhaps cgroups can use it too... 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 9/9] ARM: add uprobes support
On Mon, Oct 15, 2012 at 06:44:50PM +0100, Dave Martin wrote: > On Mon, Oct 15, 2012 at 01:44:55PM +0200, Rabin Vincent wrote: > > Why? It currently works for ARM userspace even if the kernel is > > Thumb-2. > > My bad, I misread what was happening in the Makefile changes. > > My concern is about whether we can build the ARM and Thumb-2 kprobes > code into the same kernel. If so, no problem, but I believe this is > not a tested configuration for kprobes itself. > > If you've not already done so, it should be possible to test this > by adding CONFIG_THUMB2_KERNEL=y to your config, providing your > hardware is Thumb-2 capable. I've tested this before. With a Thumb-2 kernel, both the kprobes test (Thumb) and the uprobes test (ARM) run fine. > General question which I'm not sure I understand yet: is is possible > to combine uprobes/kprobes decode more completely? It's not obvious > to me whether the uprobes-specific decoding only relates to features > which architecturally execute differently in user mode versus > privileged mode. Some explanation somewhere could be helpful. What we change is not the decoding itself but the handling of the instructions: (1) Load and stores are executed from the xol area by user space so the instructions need to be rewritten when they touch the PC. Kprobes code rewrites the instructions directly and executes them or in some cases simulates them. (2) All other non-simulated instructions are also executed from the XOL area in userspace. Because of this, the ALU instructions which use the PC also need to be rewritten to not use the PC. Perhaps we can actually get rid of this and just execute these instruction from kernel space like it is done for uprobes. So the uprobes code is uses the decoding tables just to know if the instruction is using the PC or not, but if we make the ALU instructions execute from kernel space we could actually use the emulate_*() functions like kprobes does. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 12/37] block: fix request_queue->flags initialization
Hello, Greg. On Sun, Oct 21, 2012 at 09:25:29AM -0700, Greg Kroah-Hartman wrote: > > > commit 60ea8226cbd5c8301f9a39edc574ddabcb8150e0 upstream. > > > > > > A queue newly allocated with blk_alloc_queue_node() has only > > > QUEUE_FLAG_BYPASS set. For request-based drivers, > > > blk_init_allocated_queue() is called and q->queue_flags is overwritten > > > with QUEUE_FLAG_DEFAULT which doesn't include BYPASS even though the > > > initial bypass is still in effect. > > > > > > In blk_init_allocated_queue(), or QUEUE_FLAG_DEFAULT to q->queue_flags > > > instead of overwriting. > > [...] > > > > This is not needed, as there is no QUEUE_FLAG_BYPASS in 3.0.y. > > Odd, it doesn't break the build. And for some reason I just missed > this, does it hurt to have it applied? I don't think it will break anything as it simply changes assignment to |= to avoid overwriting existing flags. That said, any patch can break anything, so if possible it would be better to drop for 3.0.y. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] m68k updates for 3.7 (take 2)
Hi Linus,
The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
Linus Torvalds (1):
Linux 3.7-rc2
are available in the git repository at:
ra.kernel.org:/pub/scm/linux/kernel/git/geert/linux-m68k.git for-linus
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git for-linus
David Howells (1):
UAPI: (Scripted) Disintegrate arch/m68k/include/asm
Geert Uytterhoeven (3):
Merge tag 'disintegrate-m68k-20121009' of
git://git.infradead.org/users/dhowells/linux-headers into for-linus
m68k: Remove empty #ifdef/#else/#endif block
m68k: Wire up kcmp
Just the expected UAPI disintegration and the "new" kcmp syscall.
Thanks for pulling!
arch/m68k/include/asm/Kbuild |2 -
arch/m68k/include/asm/ptrace.h | 75 +-
arch/m68k/include/asm/setup.h | 82 +--
arch/m68k/include/asm/signal.h | 118 +
arch/m68k/include/asm/termios.h| 44 +---
arch/m68k/include/asm/unistd.h | 356 +---
arch/m68k/include/uapi/asm/Kbuild | 23 ++
arch/m68k/include/{ => uapi}/asm/a.out.h |0
arch/m68k/include/{ => uapi}/asm/auxvec.h |0
arch/m68k/include/{ => uapi}/asm/byteorder.h |0
arch/m68k/include/{ => uapi}/asm/cachectl.h|0
arch/m68k/include/{ => uapi}/asm/fcntl.h |0
arch/m68k/include/{ => uapi}/asm/ioctls.h |0
arch/m68k/include/{ => uapi}/asm/msgbuf.h |0
arch/m68k/include/{ => uapi}/asm/param.h |0
arch/m68k/include/{ => uapi}/asm/poll.h|0
arch/m68k/include/{ => uapi}/asm/posix_types.h |0
arch/m68k/include/uapi/asm/ptrace.h| 79 ++
arch/m68k/include/{ => uapi}/asm/sembuf.h |0
arch/m68k/include/uapi/asm/setup.h | 103 +++
arch/m68k/include/{ => uapi}/asm/shmbuf.h |0
arch/m68k/include/{ => uapi}/asm/sigcontext.h |0
arch/m68k/include/uapi/asm/signal.h| 118
arch/m68k/include/{ => uapi}/asm/socket.h |0
arch/m68k/include/{ => uapi}/asm/sockios.h |0
arch/m68k/include/{ => uapi}/asm/stat.h|0
arch/m68k/include/{ => uapi}/asm/swab.h|0
arch/m68k/include/{ => uapi}/asm/termbits.h|0
arch/m68k/include/uapi/asm/termios.h | 44 +++
arch/m68k/include/uapi/asm/unistd.h| 357
arch/m68k/kernel/syscalltable.S|1 +
31 files changed, 731 insertions(+), 671 deletions(-)
rename arch/m68k/include/{ => uapi}/asm/a.out.h (100%)
rename arch/m68k/include/{ => uapi}/asm/auxvec.h (100%)
rename arch/m68k/include/{ => uapi}/asm/byteorder.h (100%)
rename arch/m68k/include/{ => uapi}/asm/cachectl.h (100%)
rename arch/m68k/include/{ => uapi}/asm/fcntl.h (100%)
rename arch/m68k/include/{ => uapi}/asm/ioctls.h (100%)
rename arch/m68k/include/{ => uapi}/asm/msgbuf.h (100%)
rename arch/m68k/include/{ => uapi}/asm/param.h (100%)
rename arch/m68k/include/{ => uapi}/asm/poll.h (100%)
rename arch/m68k/include/{ => uapi}/asm/posix_types.h (100%)
create mode 100644 arch/m68k/include/uapi/asm/ptrace.h
rename arch/m68k/include/{ => uapi}/asm/sembuf.h (100%)
create mode 100644 arch/m68k/include/uapi/asm/setup.h
rename arch/m68k/include/{ => uapi}/asm/shmbuf.h (100%)
rename arch/m68k/include/{ => uapi}/asm/sigcontext.h (100%)
create mode 100644 arch/m68k/include/uapi/asm/signal.h
rename arch/m68k/include/{ => uapi}/asm/socket.h (100%)
rename arch/m68k/include/{ => uapi}/asm/sockios.h (100%)
rename arch/m68k/include/{ => uapi}/asm/stat.h (100%)
rename arch/m68k/include/{ => uapi}/asm/swab.h (100%)
rename arch/m68k/include/{ => uapi}/asm/termbits.h (100%)
create mode 100644 arch/m68k/include/uapi/asm/termios.h
create mode 100644 arch/m68k/include/uapi/asm/unistd.h
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/9] ARM: add uprobes support
On Wed, Oct 17, 2012 at 03:50:48PM +0100, Jon Medhurst (Tixy) wrote:
> I just been looking at the decoding changes in patch 8 and had similar
> thoughts. The patch as it stands looks rather bolted on the side and
> makes the resulting code rather messy.
I agree.
> a) uprobes is similar enough to kprobes that the existing code can be
> morphed into something that cleanly supports both, or
>
> b) the similarities aren't close enough and that we should factor out
> the similarities into a more generalised decoding base, which the
> {u,k}probe code can then build on.
>
> c) some mix of a) and b)
>
> I can't help but think of the various calls over the past year or so for
> a general ARM/Thumb instruction decoding framework (the last one only a
> few weeks ago on the linux-arm-kernel list). Perhaps b) would be a small
> step towards that.
>
> I hope to find some time to understand the uprobe patches in more
> detail, so I can try and come up with some sensible suggestions on a
> cleaner solution; because I feel that as they stand they aren't really
> suitable for inclusion in the kernel.
I contemplated sending the decoding patch with [RFC] but finally went
with [PATCH] since they mostly mean the same thing :-).
Suggestions welcome. For one thing, the creation of a fake struct
kprobe from within the uprobes and the dependency on kprobes because of
that is not very nice, we probably need a "struct probe" of some sort
perhaps.
> Rabin, what tree/commit are your patches based on? (They don't seem to
> apply cleanly to 3.6 or 3.7-rc1.) I want to apply them locally so I can
> use my favourite visualisation tool and to play with them.
The patches are based on next-20121012. The uprobes core is seeing
quite a few changes in linux-next so the series will probably not apply
on later linux-next trees.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 9/9] ARM: add uprobes support
On Mon, Oct 15, 2012 at 06:31:47PM +0100, Dave Martin wrote:
> On Sun, Oct 14, 2012 at 09:23:13PM +0200, Rabin Vincent wrote:
> > +static int uprobe_trap_handler(struct pt_regs *regs, unsigned int instr)
> > +{
> > + unsigned long flags;
> > +
> > + local_irq_save(flags);
> > + if ((instr & 0x0fff) == UPROBE_SWBP_INSN)
>
> Is the check unnecessary here? I think the same comparison will
> happen as a result of evaluating the associated undef_hook.
The check is there because this uprobe_trap_handler() is registered for
two different undefined instructions: UPROBE_SWBP_INSN (the one which is
used to insert the probe) and UPROBE_SS_INSN (the one placed in the XOL
area for simulating single-stepping).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
