twitter: linux.kernel - 26 new messages in 15 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* Fix interleaving for transparent hugepages v2 - 7 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2f6b0fed89634ff4?hl=en
* staging: Use generic IGD opregion code for gma500 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/858edbd090498276?hl=en
* perf: Add support to the perf tool to specify extra values - 4 messages, 1
author
http://groups.google.com/group/linux.kernel/t/a459136e1b69ea13?hl=en
* Fix bug #13853: dereference pointer 'dev' before null check - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/190c3d1f4576d496?hl=en
* Enable writing to /proc/PID/mem. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3a49207b81bff154?hl=en
* Fix mapping->writeback_index to point to the last written page - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/d33cefbe751c0c0e?hl=en
* Squashfs tools 4.2 released - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5f3e5791152c38c4?hl=en
* perf: offcore event monitoring patches - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ceec35e032e6c8a7?hl=en
* mmotm 2011-03-02-16-52 uploaded - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/dc21ca6055f11872?hl=en
* perf script: change process_event prototype - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3707a00a72373808?hl=en
* linux-next: manual merge of the net tree with the acpi tree - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/ee0e5c6261285c48?hl=en
* linux-next: manual merge of the net tree with the net-current tree - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/b8dcf3b0965daf20?hl=en
* Staging: hv: Unify the hyperv driver abstractions - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b8e52e66e905fcc2?hl=en
* userns: remove unneeded extra argument in selinux's task_has_capability - 2
messages, 1 author
http://groups.google.com/group/linux.kernel/t/52c7d60fa75eec76?hl=en
* omap:mailbox: resolve hang issue - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/be956068beab26f6?hl=en

==============================================================================
TOPIC: Fix interleaving for transparent hugepages v2
http://groups.google.com/group/linux.kernel/t/2f6b0fed89634ff4?hl=en
==============================================================================

== 1 of 7 ==
Date: Wed, Mar 2 2011 6:20 pm
From: KAMEZAWA Hiroyuki

On Wed, 2 Mar 2011 16:45:21 -0800
Andi Kleen <andi@firstfloor.org> wrote:

> From: Andi Kleen <ak@linux.intel.com>
>
> Bugfix, independent from the rest of the series.
>
> The THP code didn't pass the correct interleaving shift to the memory
> policy code. Fix this here by adjusting for the order.
>
> v2: Use + (thanks Christoph)
> Acked-by: Andrea Arcangeli <aarcange@redhat.com>
> Reviewed-by: Christoph Lameter <cl@linux.com>
> Signed-off-by: Andi Kleen <ak@linux.intel.com>

Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>

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

== 2 of 7 ==
Date: Wed, Mar 2 2011 6:30 pm
From: KAMEZAWA Hiroyuki

On Wed, 2 Mar 2011 16:45:22 -0800
Andi Kleen <andi@firstfloor.org> wrote:

> From: Andi Kleen <ak@linux.intel.com>
>
> Currently alloc_pages_vma always uses the local node as policy node
> for the LOCAL policy. Pass this node down as an argument instead.
>
> No behaviour change from this patch, but will be needed for followons.
>
> Acked-by: Andrea Arcangeli <aarcange@redhat.com>
> Signed-off-by: Andi Kleen <ak@linux.intel.com>

Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>

== 3 of 7 ==
Date: Wed, Mar 2 2011 6:30 pm
From: KAMEZAWA Hiroyuki

On Wed, 2 Mar 2011 16:45:23 -0800
Andi Kleen <andi@firstfloor.org> wrote:

> From: Andi Kleen <ak@linux.intel.com>
>
> Add a alloc_page_vma_node that allows passing the "local" node in.
> Used in a followon patch.
>
> Acked-by: Andrea Arcangeli <aarcange@redhat.com>
> Signed-off-by: Andi Kleen <ak@linux.intel.com>

Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>

== 4 of 7 ==
Date: Wed, Mar 2 2011 6:30 pm
From: KAMEZAWA Hiroyuki

On Wed, 2 Mar 2011 16:45:24 -0800
Andi Kleen <andi@firstfloor.org> wrote:

> From: Andi Kleen <ak@linux.intel.com>
>
> This makes a difference for LOCAL policy, where the node cannot
> be determined from the policy itself, but has to be gotten
> from the original page.
>
> Acked-by: Andrea Arcangeli <aarcange@redhat.com>
> Signed-off-by: Andi Kleen <ak@linux.intel.com>

Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>

== 5 of 7 ==
Date: Wed, Mar 2 2011 6:40 pm
From: KAMEZAWA Hiroyuki

On Wed, 2 Mar 2011 16:45:25 -0800
Andi Kleen <andi@firstfloor.org> wrote:

> From: Andi Kleen <ak@linux.intel.com>
>
> Pass down the correct node for a transparent hugepage allocation.
> Most callers continue to use the current node, however the hugepaged
> daemon now uses the previous node of the first to be collapsed page
> instead. This ensures that khugepaged does not mess up local memory
> for an existing process which uses local policy.
>
> The choice of node is somewhat primitive currently: it just
> uses the node of the first page in the pmd range. An alternative
> would be to look at multiple pages and use the most popular
> node. I used the simplest variant for now which should work
> well enough for the case of all pages being on the same node.
>
> Acked-by: Andrea Arcangeli <aarcange@redhat.com>
> Signed-off-by: Andi Kleen <ak@linux.intel.com>

Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>

== 6 of 7 ==
Date: Wed, Mar 2 2011 6:50 pm
From: KAMEZAWA Hiroyuki

On Wed, 2 Mar 2011 16:45:26 -0800
Andi Kleen <andi@firstfloor.org> wrote:

> From: Andi Kleen <ak@linux.intel.com>
>
> Add a new __GFP_OTHER_NODE flag to tell the low level numa statistics
> in zone_statistics() that an allocation is on behalf of another thread.
> This way the local and remote counters can be still correct, even
> when background daemons like khugepaged are changing memory
> mappings.
>
> This only affects the accounting, but I think it's worth doing that
> right to avoid confusing users.
>
> I first tried to just pass down the right node, but this required
> a lot of changes to pass down this parameter and at least one
> addition of a 10th argument to a 9 argument function. Using
> the flag is a lot less intrusive.
>
> Open: should be also used for migration?
>
> Cc: aarcange@redhat.com
> Signed-off-by: Andi Kleen <ak@linux.intel.com>

Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>

== 7 of 7 ==
Date: Wed, Mar 2 2011 6:50 pm
From: KAMEZAWA Hiroyuki

On Wed, 2 Mar 2011 16:45:27 -0800
Andi Kleen <andi@firstfloor.org> wrote:

> From: Andi Kleen <ak@linux.intel.com>
>
> Pass GFP_OTHER_NODE for transparent hugepages NUMA allocations
> done by the hugepages daemon. This way the low level accounting
> for local versus remote pages works correctly.
>
> Contains improvements from Andrea Arcangeli
>
> Cc: aarcange@redhat.com
> Signed-off-by: Andi Kleen <ak@linux.intel.com>

Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>

==============================================================================
TOPIC: staging: Use generic IGD opregion code for gma500
http://groups.google.com/group/linux.kernel/t/858edbd090498276?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 2 2011 6:20 pm
From: Len Brown

i mean to say that 1/2 was applied to acpi-test, rather than 2/2.

This one, of course, is on top of the gma500 driver
that isn't upstream yet, so I guess greg will have
to take this patch in the staging area for staging.

thanks,
Len Brown, Intel Open Source Technology Center

==============================================================================
TOPIC: perf: Add support to the perf tool to specify extra values
http://groups.google.com/group/linux.kernel/t/a459136e1b69ea13?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Mar 2 2011 6:30 pm
From: Lin Ming

From: Andi Kleen <ak@linux.intel.com>

Change logs:
- Use ":" to specify extra value since "," was already used for multiple
events.

Add support to the perf tool to specify extra values for raw events and
pass them to the kernel.
The new format is -e rXXXX[:YYYY]

Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
---
tools/perf/builtin-report.c | 7 ++++---
tools/perf/util/parse-events.c | 24 +++++++++++++++++++-----
tools/perf/util/parse-events.h | 2 +-
tools/perf/util/ui/browsers/hists.c | 3 ++-
4 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index dddcc7e..724f65b 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -201,7 +201,8 @@ static int process_read_event(union perf_event *event,
attr = perf_header__find_attr(event->read.id, &session->header);

if (show_threads) {
- const char *name = attr ? __event_name(attr->type, attr->config)
+ const char *name = attr ? __event_name(attr->type, attr->config,
+ 0)
: "unknown";
perf_read_values_add_value(&show_threads_values,
event->read.pid, event->read.tid,
@@ -211,7 +212,7 @@ static int process_read_event(union perf_event *event,
}

dump_printf(": %d %d %s %" PRIu64 "\n", event->read.pid, event->read.tid,
- attr ? __event_name(attr->type, attr->config) : "FAIL",
+ attr ? __event_name(attr->type, attr->config, 0) : "FAIL",
event->read.value);

return 0;
@@ -291,7 +292,7 @@ static int hists__tty_browse_tree(struct rb_root *tree, const char *help)
const char *evname = NULL;

if (rb_first(&hists->entries) != rb_last(&hists->entries))
- evname = __event_name(hists->type, hists->config);
+ evname = __event_name(hists->type, hists->config, 0);

hists__fprintf_nr_sample_events(hists, evname, stdout);
hists__fprintf(hists, NULL, false, stdout);
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 54a7e26..7838dfb 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -271,15 +271,18 @@ const char *event_name(struct perf_evsel *evsel)
if (evsel->name)
return evsel->name;

- return __event_name(type, config);
+ return __event_name(type, config, evsel->attr.config1);
}

-const char *__event_name(int type, u64 config)
+const char *__event_name(int type, u64 config, u64 extra)
{
static char buf[32];
+ int n;

if (type == PERF_TYPE_RAW) {
- sprintf(buf, "raw 0x%" PRIx64, config);
+ n = sprintf(buf, "raw 0x%" PRIx64, config);
+ if (extra)
+ sprintf(buf + n, ":%#" PRIx64, extra);
return buf;
}

@@ -666,9 +669,20 @@ parse_raw_event(const char **strp, struct perf_event_attr *attr)
return EVT_FAILED;
n = hex2u64(str + 1, &config);
if (n > 0) {
- *strp = str + n + 1;
+ str += n + 1;
+ *strp = str;
attr->type = PERF_TYPE_RAW;
attr->config = config;
+
+ if (*str++ == ':') {
+ n = hex2u64(str + 1, &config);
+ if (n > 0) {
+ attr->config1 = config;
+ str += n + 1;
+ *strp = str;
+ }
+ }
+
return EVT_HANDLED;
}
return EVT_FAILED;
@@ -1035,7 +1049,7 @@ void print_events(const char *event_glob)

printf("\n");
printf(" %-42s [%s]\n",
- "rNNN (see 'perf list --help' on how to encode it)",
+ "rNNN[:EEE] (see 'perf list --help' on how to encode it)",
event_type_descriptors[PERF_TYPE_RAW]);
printf("\n");

diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
index 212f88e..0fe700c 100644
--- a/tools/perf/util/parse-events.h
+++ b/tools/perf/util/parse-events.h
@@ -21,7 +21,7 @@ extern struct tracepoint_path *tracepoint_id_to_path(u64 config);
extern bool have_tracepoints(struct list_head *evlist);

const char *event_name(struct perf_evsel *event);
-extern const char *__event_name(int type, u64 config);
+extern const char *__event_name(int type, u64 config, u64 extra);

extern int parse_events(const struct option *opt, const char *str, int unset);
extern int parse_filter(const struct option *opt, const char *str, int unset);
diff --git a/tools/perf/util/ui/browsers/hists.c b/tools/perf/util/ui/browsers/hists.c
index 497b3c4..f780bc7 100644
--- a/tools/perf/util/ui/browsers/hists.c
+++ b/tools/perf/util/ui/browsers/hists.c
@@ -984,7 +984,8 @@ int hists__tui_browse_tree(struct rb_root *self, const char *help, int evidx)

while (nd) {
struct hists *hists = rb_entry(nd, struct hists, rb_node);
- const char *ev_name = __event_name(hists->type, hists->config);
+ const char *ev_name = __event_name(hists->type, hists->config,
+ 0);

key = hists__browse(hists, help, ev_name, evidx);
switch (key) {
--
1.7.3

== 2 of 4 ==
Date: Wed, Mar 2 2011 6:30 pm
From: Lin Ming

No need to do percore allocations if HT is not capable

Signed-off-by: Lin Ming <ming.m.lin@intel.com>
---
arch/x86/kernel/cpu/perf_event_intel.c | 23 +++++++++++++++++------
1 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel.c b/arch/x86/kernel/cpu/perf_event_intel.c
index aaac4a9..4bee70a 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -1201,10 +1201,18 @@ static __initconst const struct x86_pmu core_pmu = {
.event_constraints = intel_core_event_constraints,
};

+static bool ht_capable(void)
+{
+ return boot_cpu_has(X86_FEATURE_HT) && smp_num_siblings > 1;
+}
+
static int intel_pmu_cpu_prepare(int cpu)
{
struct cpu_hw_events *cpuc = &per_cpu(cpu_hw_events, cpu);

+ if (!ht_capable())
+ return NOTIFY_OK;
+
cpuc->per_core = kzalloc_node(sizeof(struct intel_percore),
GFP_KERNEL, cpu_to_node(cpu));
if (!cpuc->per_core)
@@ -1221,6 +1229,15 @@ static void intel_pmu_cpu_starting(int cpu)
int core_id = topology_core_id(cpu);
int i;

+ init_debug_store_on_cpu(cpu);
+ /*
+ * Deal with CPUs that don't clear their LBRs on power-up.
+ */
+ intel_pmu_lbr_reset();
+
+ if (!ht_capable())
+ return;
+
for_each_cpu(i, topology_thread_cpumask(cpu)) {
struct intel_percore *pc = per_cpu(cpu_hw_events, i).per_core;

@@ -1233,12 +1250,6 @@ static void intel_pmu_cpu_starting(int cpu)

cpuc->per_core->core_id = core_id;
cpuc->per_core->refcnt++;
-
- init_debug_store_on_cpu(cpu);
- /*
- * Deal with CPUs that don't clear their LBRs on power-up.
- */
- intel_pmu_lbr_reset();
}

static void intel_pmu_cpu_dying(int cpu)
--
1.7.3

== 3 of 4 ==
Date: Wed, Mar 2 2011 6:30 pm
From: Lin Ming

From: Andi Kleen <ak@linux.intel.com>

Change logs against Andi's original version:
- Extends perf_event_attr:config to config{,1,2} (Peter Zijlstra)
- Fixed a major event scheduling issue. There cannot be a ref++ on an
event that has already done ref++ once and without calling
put_constraint() in between. (Stephane Eranian)
- Use thread_cpumask for percore allocation. (Lin Ming)
- Use MSR names in the extra reg lists. (Lin Ming)
- Remove redundant "c = NULL" in intel_percore_constraints
- Fix comment of perf_event_attr::config1

Intel Nehalem/Westmere have a special OFFCORE_RESPONSE event
that can be used to monitor any offcore accesses from a core.
This is a very useful event for various tunings, and it's
also needed to implement the generic LLC-* events correctly.

Unfortunately this event requires programming a mask in a separate
register. And worse this separate register is per core, not per
CPU thread.

This patch adds:
- Teaches perf_events that OFFCORE_RESPONSE needs extra parameters.
The extra parameters are passed by user space in the
perf_event_attr::config1 field.
- Add support to the Intel perf_event core to schedule per
core resources. This adds fairly generic infrastructure that
can be also used for other per core resources.
The basic code has is patterned after the similar AMD northbridge
constraints code.

Thanks to Stephane Eranian who pointed out some problems
in the original version and suggested improvements.

Cc: eranian@google.com
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
---
arch/x86/include/asm/msr-index.h | 3 +
arch/x86/kernel/cpu/perf_event.c | 64 ++++++++++
arch/x86/kernel/cpu/perf_event_intel.c | 200 ++++++++++++++++++++++++++++++++
include/linux/perf_event.h | 13 ++-
4 files changed, 278 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 4d0dfa0..d25e74c 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -47,6 +47,9 @@
#define MSR_IA32_MCG_STATUS 0x0000017a
#define MSR_IA32_MCG_CTL 0x0000017b

+#define MSR_OFFCORE_RSP_0 0x000001a6
+#define MSR_OFFCORE_RSP_1 0x000001a7
+
#define MSR_IA32_PEBS_ENABLE 0x000003f1
#define MSR_IA32_DS_AREA 0x00000600
#define MSR_IA32_PERF_CAPABILITIES 0x00000345
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index ea03c72..ec6a6db 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -93,6 +93,8 @@ struct amd_nb {
struct event_constraint event_constraints[X86_PMC_IDX_MAX];
};

+struct intel_percore;
+
#define MAX_LBR_ENTRIES 16

struct cpu_hw_events {
@@ -128,6 +130,13 @@ struct cpu_hw_events {
struct perf_branch_entry lbr_entries[MAX_LBR_ENTRIES];

/*
+ * Intel percore register state.
+ * Coordinate shared resources between HT threads.
+ */
+ int percore_used; /* Used by this CPU? */
+ struct intel_percore *per_core;
+
+ /*
* AMD specific bits
*/
struct amd_nb *amd_nb;
@@ -177,6 +186,28 @@ struct cpu_hw_events {
#define for_each_event_constraint(e, c) \
for ((e) = (c); (e)->weight; (e)++)

+/*
+ * Extra registers for specific events.
+ * Some events need large masks and require external MSRs.
+ * Define a mapping to these extra registers.
+ */
+struct extra_reg {
+ unsigned int event;
+ unsigned int msr;
+ u64 config_mask;
+ u64 valid_mask;
+};
+
+#define EVENT_EXTRA_REG(e, ms, m, vm) { \
+ .event = (e), \
+ .msr = (ms), \
+ .config_mask = (m), \
+ .valid_mask = (vm), \
+ }
+#define INTEL_EVENT_EXTRA_REG(event, msr, vm) \
+ EVENT_EXTRA_REG(event, msr, ARCH_PERFMON_EVENTSEL_EVENT, vm)
+#define EVENT_EXTRA_END EVENT_EXTRA_REG(0, 0, 0, 0)
+
union perf_capabilities {
struct {
u64 lbr_format : 6;
@@ -221,6 +252,7 @@ struct x86_pmu {
void (*put_event_constraints)(struct cpu_hw_events *cpuc,
struct perf_event *event);
struct event_constraint *event_constraints;
+ struct event_constraint *percore_constraints;
void (*quirks)(void);
int perfctr_second_write;

@@ -249,6 +281,11 @@ struct x86_pmu {
*/
unsigned long lbr_tos, lbr_from, lbr_to; /* MSR base regs */
int lbr_nr; /* hardware stack size */
+
+ /*
+ * Extra registers for events
+ */
+ struct extra_reg *extra_regs;
};

static struct x86_pmu x86_pmu __read_mostly;
@@ -341,6 +378,31 @@ static inline unsigned int x86_pmu_event_addr(int index)
return x86_pmu.perfctr + x86_pmu_addr_offset(index);
}

+/*
+ * Find and validate any extra registers to set up.
+ */
+static int x86_pmu_extra_regs(u64 config, struct perf_event *event)
+{
+ struct extra_reg *er;
+
+ event->hw.extra_reg = 0;
+ event->hw.extra_config = 0;
+
+ if (!x86_pmu.extra_regs)
+ return 0;
+
+ for (er = x86_pmu.extra_regs; er->msr; er++) {
+ if (er->event != (config & er->config_mask))
+ continue;
+ if (event->attr.config1 & ~er->valid_mask)
+ return -EINVAL;
+ event->hw.extra_reg = er->msr;
+ event->hw.extra_config = event->attr.config1;
+ break;
+ }
+ return 0;
+}
+
static atomic_t active_events;
static DEFINE_MUTEX(pmc_reserve_mutex);

@@ -665,6 +727,8 @@ static void x86_pmu_disable(struct pmu *pmu)
static inline void __x86_pmu_enable_event(struct hw_perf_event *hwc,
u64 enable_mask)
{
+ if (hwc->extra_reg)
+ wrmsrl(hwc->extra_reg, hwc->extra_config);
wrmsrl(hwc->config_base, hwc->config | enable_mask);
}

diff --git a/arch/x86/kernel/cpu/perf_event_intel.c b/arch/x86/kernel/cpu/perf_event_intel.c
index ba8aad1..af0c6a2 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -1,5 +1,27 @@
#ifdef CONFIG_CPU_SUP_INTEL

+#define MAX_EXTRA_REGS 2
+
+/*
+ * Per register state.
+ */
+struct er_account {
+ int ref; /* reference count */
+ unsigned int extra_reg; /* extra MSR number */
+ u64 extra_config; /* extra MSR config */
+};
+
+/*
+ * Per core state
+ * This used to coordinate shared registers for HT threads.
+ */
+struct intel_percore {
+ raw_spinlock_t lock; /* protect structure */
+ struct er_account regs[MAX_EXTRA_REGS];
+ int refcnt; /* number of threads */
+ unsigned core_id;
+};
+
/*
* Intel PerfMon, used on Core and later.
*/
@@ -64,6 +86,18 @@ static struct event_constraint intel_nehalem_event_constraints[] =
EVENT_CONSTRAINT_END
};

+static struct extra_reg intel_nehalem_extra_regs[] =
+{
+ INTEL_EVENT_EXTRA_REG(0xb7, MSR_OFFCORE_RSP_0, 0xffff),
+ EVENT_EXTRA_END
+};
+
+static struct event_constraint intel_nehalem_percore_constraints[] =
+{
+ INTEL_EVENT_CONSTRAINT(0xb7, 0),
+ EVENT_CONSTRAINT_END
+};
+
static struct event_constraint intel_westmere_event_constraints[] =
{
FIXED_EVENT_CONSTRAINT(0x00c0, 0), /* INST_RETIRED.ANY */
@@ -89,6 +123,20 @@ static struct event_constraint intel_snb_event_constraints[] =
EVENT_CONSTRAINT_END
};

+static struct extra_reg intel_westmere_extra_regs[] =
+{
+ INTEL_EVENT_EXTRA_REG(0xb7, MSR_OFFCORE_RSP_0, 0xffff),
+ INTEL_EVENT_EXTRA_REG(0xbb, MSR_OFFCORE_RSP_1, 0xffff),
+ EVENT_EXTRA_END
+};
+
+static struct event_constraint intel_westmere_percore_constraints[] =
+{
+ INTEL_EVENT_CONSTRAINT(0xb7, 0),
+ INTEL_EVENT_CONSTRAINT(0xbb, 0),
+ EVENT_CONSTRAINT_END
+};
+
static struct event_constraint intel_gen_event_constraints[] =
{
FIXED_EVENT_CONSTRAINT(0x00c0, 0), /* INST_RETIRED.ANY */
@@ -907,6 +955,67 @@ intel_bts_constraints(struct perf_event *event)
}

static struct event_constraint *
+intel_percore_constraints(struct cpu_hw_events *cpuc, struct perf_event *event)
+{
+ struct hw_perf_event *hwc = &event->hw;
+ unsigned int e = hwc->config & ARCH_PERFMON_EVENTSEL_EVENT;
+ struct event_constraint *c;
+ struct intel_percore *pc;
+ struct er_account *era;
+ int i;
+ int free_slot;
+ int found;
+
+ if (!x86_pmu.percore_constraints || hwc->extra_alloc)
+ return NULL;
+
+ for (c = x86_pmu.percore_constraints; c->cmask; c++) {
+ if (e != c->code)
+ continue;
+
+ /*
+ * Allocate resource per core.
+ */
+ pc = cpuc->per_core;
+ if (!pc)
+ break;
+ c = &emptyconstraint;
+ raw_spin_lock(&pc->lock);
+ free_slot = -1;
+ found = 0;
+ for (i = 0; i < MAX_EXTRA_REGS; i++) {
+ era = &pc->regs[i];
+ if (era->ref > 0 && hwc->extra_reg == era->extra_reg) {
+ /* Allow sharing same config */
+ if (hwc->extra_config == era->extra_config) {
+ era->ref++;
+ cpuc->percore_used = 1;
+ hwc->extra_alloc = 1;
+ c = NULL;
+ }
+ /* else conflict */
+ found = 1;
+ break;
+ } else if (era->ref == 0 && free_slot == -1)
+ free_slot = i;
+ }
+ if (!found && free_slot != -1) {
+ era = &pc->regs[free_slot];
+ era->ref = 1;
+ era->extra_reg = hwc->extra_reg;
+ era->extra_config = hwc->extra_config;
+ cpuc->percore_used = 1;
+ hwc->extra_alloc = 1;
+ c = NULL;
+ }
+ raw_spin_unlock(&pc->lock);
+ return c;
+ }
+
+ return NULL;
+}
+
+static struct event_constraint *
intel_get_event_constraints(struct cpu_hw_events *cpuc, struct perf_event *event)
{
struct event_constraint *c;
@@ -919,9 +1028,51 @@ intel_get_event_constraints(struct cpu_hw_events *cpuc, struct perf_event *event
if (c)
return c;

+ c = intel_percore_constraints(cpuc, event);
+ if (c)
+ return c;
+
return x86_get_event_constraints(cpuc, event);
}

+static void intel_put_event_constraints(struct cpu_hw_events *cpuc,
+ struct perf_event *event)
+{
+ struct extra_reg *er;
+ struct intel_percore *pc;
+ struct er_account *era;
+ struct hw_perf_event *hwc = &event->hw;
+ int i, allref;
+
+ if (!cpuc->percore_used)
+ return;
+
+ for (er = x86_pmu.extra_regs; er->msr; er++) {
+ if (er->event != (hwc->config & er->config_mask))
+ continue;
+
+ pc = cpuc->per_core;
+ raw_spin_lock(&pc->lock);
+ for (i = 0; i < MAX_EXTRA_REGS; i++) {
+ era = &pc->regs[i];
+ if (era->ref > 0 &&
+ era->extra_config == hwc->extra_config &&
+ era->extra_reg == er->msr) {
+ era->ref--;
+ hwc->extra_alloc = 0;
+ break;
+ }
+ }
+ allref = 0;
+ for (i = 0; i < MAX_EXTRA_REGS; i++)
+ allref += pc->regs[i].ref;
+ if (allref == 0)
+ cpuc->percore_used = 0;
+ raw_spin_unlock(&pc->lock);
+ break;
+ }
+}
+
static int intel_pmu_hw_config(struct perf_event *event)
{
int ret = x86_pmu_hw_config(event);
@@ -993,11 +1144,43 @@ static __initconst const struct x86_pmu core_pmu = {
*/
.max_period = (1ULL << 31) - 1,
.get_event_constraints = intel_get_event_constraints,
+ .put_event_constraints = intel_put_event_constraints,
.event_constraints = intel_core_event_constraints,
};

+static int intel_pmu_cpu_prepare(int cpu)
+{
+ struct cpu_hw_events *cpuc = &per_cpu(cpu_hw_events, cpu);
+
+ cpuc->per_core = kzalloc_node(sizeof(struct intel_percore),
+ GFP_KERNEL, cpu_to_node(cpu));
+ if (!cpuc->per_core)
+ return NOTIFY_BAD;
+
+ raw_spin_lock_init(&cpuc->per_core->lock);
+ cpuc->per_core->core_id = -1;
+ return NOTIFY_OK;
+}
+
static void intel_pmu_cpu_starting(int cpu)
{
+ struct cpu_hw_events *cpuc = &per_cpu(cpu_hw_events, cpu);
+ int core_id = topology_core_id(cpu);
+ int i;
+
+ for_each_cpu(i, topology_thread_cpumask(cpu)) {
+ struct intel_percore *pc = per_cpu(cpu_hw_events, i).per_core;
+
+ if (pc && pc->core_id == core_id) {
+ kfree(cpuc->per_core);
+ cpuc->per_core = pc;
+ break;
+ }
+ }
+
+ cpuc->per_core->core_id = core_id;
+ cpuc->per_core->refcnt++;
+
init_debug_store_on_cpu(cpu);
/*
* Deal with CPUs that don't clear their LBRs on power-up.
@@ -1007,6 +1190,15 @@ static void intel_pmu_cpu_starting(int cpu)

static void intel_pmu_cpu_dying(int cpu)
{
+ struct cpu_hw_events *cpuc = &per_cpu(cpu_hw_events, cpu);
+ struct intel_percore *pc = cpuc->per_core;
+
+ if (pc) {
+ if (pc->core_id == -1 || --pc->refcnt == 0)
+ kfree(pc);
+ cpuc->per_core = NULL;
+ }
+
fini_debug_store_on_cpu(cpu);
}

@@ -1031,7 +1223,9 @@ static __initconst const struct x86_pmu intel_pmu = {
*/
.max_period = (1ULL << 31) - 1,
.get_event_constraints = intel_get_event_constraints,
+ .put_event_constraints = intel_put_event_constraints,

+ .cpu_prepare = intel_pmu_cpu_prepare,
.cpu_starting = intel_pmu_cpu_starting,
.cpu_dying = intel_pmu_cpu_dying,
};
@@ -1149,7 +1343,10 @@ static __init int intel_pmu_init(void)
intel_pmu_lbr_init_nhm();

x86_pmu.event_constraints = intel_nehalem_event_constraints;
+ x86_pmu.percore_constraints =
+ intel_nehalem_percore_constraints;
x86_pmu.enable_all = intel_pmu_nhm_enable_all;
+ x86_pmu.extra_regs = intel_nehalem_extra_regs;
pr_cont("Nehalem events, ");
break;

@@ -1171,7 +1368,10 @@ static __init int intel_pmu_init(void)
intel_pmu_lbr_init_nhm();

x86_pmu.event_constraints = intel_westmere_event_constraints;
+ x86_pmu.percore_constraints =
+ intel_westmere_percore_constraints;
x86_pmu.enable_all = intel_pmu_nhm_enable_all;
+ x86_pmu.extra_regs = intel_westmere_extra_regs;
pr_cont("Westmere events, ");
break;

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 8ceb5a6..614615b 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -225,8 +225,14 @@ struct perf_event_attr {
};

__u32 bp_type;
- __u64 bp_addr;
- __u64 bp_len;
+ union {
+ __u64 bp_addr;
+ __u64 config1; /* extension of config */
+ };
+ union {
+ __u64 bp_len;
+ __u64 config2; /* extension of config1 */
+ };
};

/*
@@ -541,6 +547,9 @@ struct hw_perf_event {
unsigned long event_base;
int idx;
int last_cpu;
+ unsigned int extra_reg;
+ u64 extra_config;
+ int extra_alloc;
};
struct { /* software */
struct hrtimer hrtimer;
--
1.7.3

== 4 of 4 ==
Date: Wed, Mar 2 2011 6:30 pm
From: Lin Ming

From: Andi Kleen <ak@linux.intel.com>

The generic perf LLC-* events do count the L2 caches, not the real
L3 LLC on Intel Nehalem and Westmere. This lead to quite some confusion.

Fixing this properly requires use of the special OFFCORE_RESPONSE
events which need a separate mask register. This has been implemented
in a earlier patch.

Now use this infrastructure to set correct events for the LLC-*
on Nehalem and Westmere

Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
---
arch/x86/kernel/cpu/perf_event.c | 15 ++++--
arch/x86/kernel/cpu/perf_event_intel.c | 81 +++++++++++++++++++++++++++-----
2 files changed, 79 insertions(+), 17 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index ec6a6db..4d6ce5d 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -310,6 +310,10 @@ static u64 __read_mostly hw_cache_event_ids
[PERF_COUNT_HW_CACHE_MAX]
[PERF_COUNT_HW_CACHE_OP_MAX]
[PERF_COUNT_HW_CACHE_RESULT_MAX];
+static u64 __read_mostly hw_cache_extra_regs
+ [PERF_COUNT_HW_CACHE_MAX]
+ [PERF_COUNT_HW_CACHE_OP_MAX]
+ [PERF_COUNT_HW_CACHE_RESULT_MAX];

/*
* Propagate event elapsed time into the generic event.
@@ -524,8 +528,9 @@ static inline int x86_pmu_initialized(void)
}

static inline int
-set_ext_hw_attr(struct hw_perf_event *hwc, struct perf_event_attr *attr)
+set_ext_hw_attr(struct hw_perf_event *hwc, struct perf_event *event)
{
+ struct perf_event_attr *attr = &event->attr;
unsigned int cache_type, cache_op, cache_result;
u64 config, val;

@@ -552,8 +557,8 @@ set_ext_hw_attr(struct hw_perf_event *hwc, struct perf_event_attr *attr)
return -EINVAL;

hwc->config |= val;
-
- return 0;
+ attr->config1 = hw_cache_extra_regs[cache_type][cache_op][cache_result];
+ return x86_pmu_extra_regs(val, event);
}

static int x86_setup_perfctr(struct perf_event *event)
@@ -578,10 +583,10 @@ static int x86_setup_perfctr(struct perf_event *event)
}

if (attr->type == PERF_TYPE_RAW)
- return 0;
+ return x86_pmu_extra_regs(event->attr.config, event);

if (attr->type == PERF_TYPE_HW_CACHE)
- return set_ext_hw_attr(hwc, attr);
+ return set_ext_hw_attr(hwc, event);

if (attr->config >= x86_pmu.max_events)
return -EINVAL;
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c b/arch/x86/kernel/cpu/perf_event_intel.c
index af0c6a2..aaac4a9 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -285,16 +285,26 @@ static __initconst const u64 westmere_hw_cache_event_ids
},
[ C(LL ) ] = {
[ C(OP_READ) ] = {
- [ C(RESULT_ACCESS) ] = 0x0324, /* L2_RQSTS.LOADS */
- [ C(RESULT_MISS) ] = 0x0224, /* L2_RQSTS.LD_MISS */
+ /* OFFCORE_RESPONSE_0.ANY_DATA.LOCAL_CACHE */
+ [ C(RESULT_ACCESS) ] = 0x01b7,
+ /* OFFCORE_RESPONSE_1.ANY_DATA.ANY_LLC_MISS */
+ [ C(RESULT_MISS) ] = 0x01bb,
},
+ /*
+ * Use RFO, not WRITEBACK, because a write miss would typically occur
+ * on RFO.
+ */
[ C(OP_WRITE) ] = {
- [ C(RESULT_ACCESS) ] = 0x0c24, /* L2_RQSTS.RFOS */
- [ C(RESULT_MISS) ] = 0x0824, /* L2_RQSTS.RFO_MISS */
+ /* OFFCORE_RESPONSE_1.ANY_RFO.LOCAL_CACHE */
+ [ C(RESULT_ACCESS) ] = 0x01bb,
+ /* OFFCORE_RESPONSE_0.ANY_RFO.ANY_LLC_MISS */
+ [ C(RESULT_MISS) ] = 0x01b7,
},
[ C(OP_PREFETCH) ] = {
- [ C(RESULT_ACCESS) ] = 0x4f2e, /* LLC Reference */
- [ C(RESULT_MISS) ] = 0x412e, /* LLC Misses */
+ /* OFFCORE_RESPONSE_0.PREFETCH.LOCAL_CACHE */
+ [ C(RESULT_ACCESS) ] = 0x01b7,
+ /* OFFCORE_RESPONSE_1.PREFETCH.ANY_LLC_MISS */
+ [ C(RESULT_MISS) ] = 0x01bb,
},
},
[ C(DTLB) ] = {
@@ -341,6 +351,39 @@ static __initconst const u64 westmere_hw_cache_event_ids
},
};

+/*
+ * OFFCORE_RESPONSE MSR bits (subset), See IA32 SDM Vol 3 30.6.1.3
+ */
+
+#define DMND_DATA_RD (1 << 0)
+#define DMND_RFO (1 << 1)
+#define DMND_WB (1 << 3)
+#define PF_DATA_RD (1 << 4)
+#define PF_DATA_RFO (1 << 5)
+#define RESP_UNCORE_HIT (1 << 8)
+#define RESP_MISS (0xf600) /* non uncore hit */
+
+static __initconst const u64 nehalem_hw_cache_extra_regs
+ [PERF_COUNT_HW_CACHE_MAX]
+ [PERF_COUNT_HW_CACHE_OP_MAX]
+ [PERF_COUNT_HW_CACHE_RESULT_MAX] =
+{
+ [ C(LL ) ] = {
+ [ C(OP_READ) ] = {
+ [ C(RESULT_ACCESS) ] = DMND_DATA_RD|RESP_UNCORE_HIT,
+ [ C(RESULT_MISS) ] = DMND_DATA_RD|RESP_MISS,
+ },
+ [ C(OP_WRITE) ] = {
+ [ C(RESULT_ACCESS) ] = DMND_RFO|DMND_WB|RESP_UNCORE_HIT,
+ [ C(RESULT_MISS) ] = DMND_RFO|DMND_WB|RESP_MISS,
+ },
+ [ C(OP_PREFETCH) ] = {
+ [ C(RESULT_ACCESS) ] = PF_DATA_RD|PF_DATA_RFO|RESP_UNCORE_HIT,
+ [ C(RESULT_MISS) ] = PF_DATA_RD|PF_DATA_RFO|RESP_MISS,
+ },
+ }
+};
+
static __initconst const u64 nehalem_hw_cache_event_ids
[PERF_COUNT_HW_CACHE_MAX]
[PERF_COUNT_HW_CACHE_OP_MAX]
@@ -376,16 +419,26 @@ static __initconst const u64 nehalem_hw_cache_event_ids
},
[ C(LL ) ] = {
[ C(OP_READ) ] = {
- [ C(RESULT_ACCESS) ] = 0x0324, /* L2_RQSTS.LOADS */
- [ C(RESULT_MISS) ] = 0x0224, /* L2_RQSTS.LD_MISS */
+ /* OFFCORE_RESPONSE.ANY_DATA.LOCAL_CACHE */
+ [ C(RESULT_ACCESS) ] = 0x01b7,
+ /* OFFCORE_RESPONSE.ANY_DATA.ANY_LLC_MISS */
+ [ C(RESULT_MISS) ] = 0x01b7,
},
+ /*
+ * Use RFO, not WRITEBACK, because a write miss would typically occur
+ * on RFO.
+ */
[ C(OP_WRITE) ] = {
- [ C(RESULT_ACCESS) ] = 0x0c24, /* L2_RQSTS.RFOS */
- [ C(RESULT_MISS) ] = 0x0824, /* L2_RQSTS.RFO_MISS */
+ /* OFFCORE_RESPONSE.ANY_RFO.LOCAL_CACHE */
+ [ C(RESULT_ACCESS) ] = 0x01b7,
+ /* OFFCORE_RESPONSE.ANY_RFO.ANY_LLC_MISS */
+ [ C(RESULT_MISS) ] = 0x01b7,
},
[ C(OP_PREFETCH) ] = {
- [ C(RESULT_ACCESS) ] = 0x4f2e, /* LLC Reference */
- [ C(RESULT_MISS) ] = 0x412e, /* LLC Misses */
+ /* OFFCORE_RESPONSE.PREFETCH.LOCAL_CACHE */
+ [ C(RESULT_ACCESS) ] = 0x01b7,
+ /* OFFCORE_RESPONSE.PREFETCH.ANY_LLC_MISS */
+ [ C(RESULT_MISS) ] = 0x01b7,
},
},
[ C(DTLB) ] = {
@@ -1339,6 +1392,8 @@ static __init int intel_pmu_init(void)
case 46: /* 45 nm nehalem-ex, "Beckton" */
memcpy(hw_cache_event_ids, nehalem_hw_cache_event_ids,
sizeof(hw_cache_event_ids));
+ memcpy(hw_cache_extra_regs, nehalem_hw_cache_extra_regs,
+ sizeof(hw_cache_extra_regs));

intel_pmu_lbr_init_nhm();

@@ -1364,6 +1419,8 @@ static __init int intel_pmu_init(void)
case 44: /* 32 nm nehalem, "Gulftown" */
memcpy(hw_cache_event_ids, westmere_hw_cache_event_ids,
sizeof(hw_cache_event_ids));
+ memcpy(hw_cache_extra_regs, nehalem_hw_cache_extra_regs,
+ sizeof(hw_cache_extra_regs));

intel_pmu_lbr_init_nhm();

--
1.7.3

==============================================================================
TOPIC: Fix bug #13853: dereference pointer 'dev' before null check
http://groups.google.com/group/linux.kernel/t/190c3d1f4576d496?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Mar 2 2011 6:30 pm
From: Jinqiu

This patch fixes bug #13853 .This still exists in latest version.
'dev' is dereferenced before testing for NULL.

Signed-off-by: Jinqiu Yang<crindy646@gmail.com>
--- a/drivers/net/ariadne.c
+++ b/drivers/net/ariadne.c
@@ -420,7 +420,7 @@ static inline void ariadne_reset(struct
static irqreturn_t ariadne_interrupt(int irq, void *data)
{
struct net_device *dev = (struct net_device *) data;
- volatile struct Am79C960 *lance = (struct Am79C960*)dev->base_addr;
+ volatile struct Am79C960 *lance;
struct ariadne_private *priv;
int csr0, boguscnt;
int handled = 0;
@@ -429,6 +429, 7 @@ static irqreturn_t ariadne_interrupt(int
printk(KERN_WARNING "ariadne_interrupt(): irq for unknown device.\n");
return IRQ_NONE;
}
+ lance = (struct Am79C960 *)dev->base_addr;

lance->RAP = CSR0; /* PCnet-ISA Controller Status */

== 2 of 2 ==
Date: Wed, Mar 2 2011 6:50 pm
From: Li Zefan

So you've been told to read Documentation/SubmittingPatches
and Documentation/email-clients.txt, but there are still quite
a few problems in your patch..

Don't ever mention "bug #13853", because this number makes no sense
for everyone except you. A proper subject may be:

[PATCH] ariadne: fix possible null dereference.

And please send your patches to proper maintainers and mailing list,
David Miller and netdev@vger.kernel.org in particular.

Jinqiu wrote:
> This patch fixes bug #13853 .This still exists in latest version.

Of course it exists, otherwise your patch won't be applied, so just
remove this line from your changelog.

> 'dev' is dereferenced before testing for NULL.
>
> Signed-off-by: Jinqiu Yang<crindy646@gmail.com>
> --- a/drivers/net/ariadne.c
> +++ b/drivers/net/ariadne.c
> @@ -420,7 +420,7 @@ static inline void ariadne_reset(struct
> static irqreturn_t ariadne_interrupt(int irq, void *data)
> {
> struct net_device *dev = (struct net_device *) data;
> - volatile struct Am79C960 *lance = (struct Am79C960*)dev->base_addr;
> + volatile struct Am79C960 *lance;

You still haven't fix your email client. You should notice the tabs have
been turned into spaces.

Please make sure you fix this (and other issues) before sending out the
patch again.

> struct ariadne_private *priv;
> int csr0, boguscnt;
> int handled = 0;
> @@ -429,6 +429, 7 @@ static irqreturn_t ariadne_interrupt(int
> printk(KERN_WARNING "ariadne_interrupt(): irq for unknown device.\n");
> return IRQ_NONE;
> }
> + lance = (struct Am79C960 *)dev->base_addr;
>
> lance->RAP = CSR0; /* PCnet-ISA Controller Status */
>
>
>
>
> --
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Enable writing to /proc/PID/mem.
http://groups.google.com/group/linux.kernel/t/3a49207b81bff154?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 2 2011 6:30 pm
From: KOSAKI Motohiro

> For a long time /proc/PID/mem has provided a read-only interface, at least since
> 2.4.0. However, a write capability has existed "forever" in tree via the
> function mem_write, disabled with an #ifdef along with the comment "this is a
> security hazard". Charles Wright, back in 2006, gave some history on the
> subject:
>
> http://lkml.org/lkml/2006/3/10/224
>
> Later, in commit 638fa202c, Roland McGrath updated mem_write to call
> check_mem_permission which ensures an identical security policy for
> /proc/PID/mem as for ptrace(). IOW, the proc interface provides a simpler, more
> efficient, but otherwise equivalent mechanism for probing a processes memory as
> available via ptrace.
>
> There is no longer a security hazard and the world can safely use read/write
> instead of ptrace PEEK/POKE's. Remove the #ifdef.
>
> Signed-off-by: Stephen Wilson <wilsons@start.ca>

I haven't found any problem in this patch. But, I really believe we need
to understand why it was marked "security hazard". Al, I guess you know it,
right? So, can you please talk us your mention?

==============================================================================
TOPIC: Fix mapping->writeback_index to point to the last written page
http://groups.google.com/group/linux.kernel/t/d33cefbe751c0c0e?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 2 2011 6:30 pm
From: "Jun'ichi Nomura"

Hi Jan,

thank you for the comments.

On 03/03/11 07:18, Jan Kara wrote:
> On Fri 25-02-11 16:55:19, Jun'ichi Nomura wrote:
>> I think it's intended for sequential writer.
> Not exactly. The code is meant so that background writeback gets to
> writing the end of a file which gets continuously dirtied (if we always
> started at the beginning, nr_to_write could always get to 0 before we reach
> end of the file).

Ah, ok. Thanks.
My patch doesn't break the above goal.

>> Otherwise, the last written page was left dirty until the writeback
>> wraps around.
>>
>> I.e. if the sequential dirtier has written on pagecache as '*'s below:
>>
>> |*******|*******|****---|-------|-------| ( |---| is a page )
>>
>> then, writeback happens:
>>
>> |-------|-------|-------|-------|-------|
>>
>> and the dirtier continues:
>>
>> |-------|-------|----***|*******|*****--|
>> A B
>>
>> Next writeback should start from page A, not B.
> Yes, this is downside of our current scheme. Have you actually observed
> it in practice or is it mostly a theoretic concern?

Half practical, half theoretic.
It has been observed with a real application, which uses a big ring file.

I took a trace with a test program for example:

[1st writeback session]
...
flush-8:0-2743 4571: block_bio_queue: 8,0 W 94898514 + 8
flush-8:0-2743 4571: block_bio_queue: 8,0 W 94898522 + 8
flush-8:0-2743 4571: block_bio_queue: 8,0 W 94898530 + 8
flush-8:0-2743 4571: block_bio_queue: 8,0 W 94898538 + 8
flush-8:0-2743 4571: block_bio_queue: 8,0 W 94898546 + 8
kworker/0:1-11 4571: block_rq_issue: 8,0 W 0 () 94898514 + 40
>> flush-8:0-2743 4571: block_bio_queue: 8,0 W 94898554 + 8
>> flush-8:0-2743 4571: block_rq_issue: 8,0 W 0 () 94898554 + 8

[2nd writeback session after 35sec]
flush-8:0-2743 4606: block_bio_queue: 8,0 W 94898562 + 8
flush-8:0-2743 4606: block_bio_queue: 8,0 W 94898570 + 8
flush-8:0-2743 4606: block_bio_queue: 8,0 W 94898578 + 8
...
kworker/0:1-11 4606: block_rq_issue: 8,0 W 0 () 94898562 + 640
kworker/0:1-11 4606: block_rq_issue: 8,0 W 0 () 94899202 + 72
...
flush-8:0-2743 4606: block_bio_queue: 8,0 W 94899962 + 8
flush-8:0-2743 4606: block_bio_queue: 8,0 W 94899970 + 8
flush-8:0-2743 4606: block_bio_queue: 8,0 W 94899978 + 8
flush-8:0-2743 4606: block_bio_queue: 8,0 W 94899986 + 8
flush-8:0-2743 4606: block_bio_queue: 8,0 W 94899994 + 8
kworker/0:1-11 4606: block_rq_issue: 8,0 W 0 () 94899962 + 40
>> flush-8:0-2743 4606: block_bio_queue: 8,0 W 94898554 + 8
>> flush-8:0-2743 4606: block_rq_issue: 8,0 W 0 () 94898554 + 8

The 1st writeback ended at block 94898562. (94898554+8)
The 2nd writeback started there.
However, since the last page at the 1st writeback was just redirtied,
the 2nd writeback looped back to block 94898554 after sequentially
submitting blocks from 94898562 to 94900001.

1 extra seek which could be avoided.
I haven't seen fatal problem with the latest kernel, though.

With older kernels (before 2.6.29, without commit 31a12666),
kupdate leaves the dirty pages like spots until the application wraps
around the ring. (It could take hours to days.)
That led me to this code.

> But as I'm thinking about it, it wouldn't harm our original aim to do
> what you propose and it can help this relatively common case. So I think
> it's a good idea. Fengguang, what do you think?

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

==============================================================================
TOPIC: Squashfs tools 4.2 released
http://groups.google.com/group/linux.kernel/t/5f3e5791152c38c4?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 2 2011 6:30 pm
From: Phillip Lougher

Hi,

I'm pleased to announce the release of Squashfs tools 4.2. This release
adds support for XZ compression, and filesystem support for compression
specific options (needed for XZ -dict-size and -Xbcj options). There's
also the usual minor extra features and bug fixes.

The release can be downloaded from http://sourceforge.net/projects/squashfs.

1. Filesystem improvements:

1.1 Added XZ compression.
1.2 Added compression options support

2. Miscellaneous improvements/bug fixes.

2.1 Add missing NO_XATTR filesystem flag to indicate no-xattrs
option was specified and no xattrs should be stored when
appending.
2.2 Add suppport in Unquashfs -stat option for displaying
NO_XATTR flag.
2.3 Remove checkdata entry from Unsquashfs -stat option if a 4.0
filesystem - checkdata is no longer supported.
2.4 Fix appending bug when appending to an empty filesystem - this
would be incorrectly treated as an error.
2.5 Use glibc sys/xattr.h include rather than using attr/xattr.h
which isn't present by default on some distributions.
2.6 Unsquashfs, fix block calculation error with regular files when
file size is between 2^32-block_size+1 and 2^32-1.
2.7 Unsquashfs, fix sparse file writing when holes are larger than
2^31-1.
2.8 Add external CFLAGS and LDFLAGS support to Makefile, and allow
build options to be specified on command line. Also don't
over-write passed in CFLAGS definition.

Phillip

==============================================================================
TOPIC: perf: offcore event monitoring patches
http://groups.google.com/group/linux.kernel/t/ceec35e032e6c8a7?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 2 2011 6:30 pm
From: Lin Ming

Hi,

v2 -> v3:
- Remove redundant "c = NULL" in intel_percore_constraints
- Fix comment of perf_event_attr::config1

v2:
Here is the updated offcore patches. I merged small changes and fixes
into the first patch, see the change logs.

Peter,
The event scheduling issue was fixed, could you please consider merging
this series?

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

==============================================================================
TOPIC: mmotm 2011-03-02-16-52 uploaded
http://groups.google.com/group/linux.kernel/t/dc21ca6055f11872?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 2 2011 6:40 pm
From: Stephen Rothwell

Hi Andrew,

On Wed, 2 Mar 2011 18:17:11 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> What's in the 8000 lines?

Just the localversion-next file and the stuff in the "Next" directory ...
meta information about the linux-next tree.

> Didn't understand that - why is git-am unhappy? Your sentence was
> truncated.

It didn't recognise the patch format since it wants an email-like patch
(with a From line to show the author).

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

==============================================================================
TOPIC: perf script: change process_event prototype
http://groups.google.com/group/linux.kernel/t/3707a00a72373808?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 2 2011 6:50 pm
From: Frederic Weisbecker

On Wed, Mar 02, 2011 at 10:29:18AM -0700, David Ahern wrote:
> Prepare for handling of samples for any event type.
>
> Signed-off-by: David Ahern <daahern@cisco.com>
> ---
> tools/perf/builtin-script.c | 40 +++++++++++--------
> .../util/scripting-engines/trace-event-python.c | 20 ++++++++-

What about Perl?

> tools/perf/util/trace-event-scripting.c | 8 +--
> tools/perf/util/trace-event.h | 6 ++-
> 4 files changed, 47 insertions(+), 27 deletions(-)
>
> diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
> index 5f40df6..0bee150 100644
> --- a/tools/perf/builtin-script.c
> +++ b/tools/perf/builtin-script.c
> @@ -20,6 +20,27 @@ static u64 last_timestamp;
> static u64 nr_unordered;
> extern const struct option record_options[];
>
> +static void process_event(union perf_event *event,
> + struct perf_sample *sample,
> + struct perf_session *session)
> +{
> + struct thread *thread = perf_session__findnew(session, event->ip.pid);
> +
> + if (thread == NULL) {
> + pr_debug("problem processing %d event, skipping it.\n",
> + event->header.type);
> + return;
> + }

Seems the thread is needed by any endpoints. It would be better to resolve
it from process_sample_event and pass it to the process_event() handler.

> +
> + /*
> + * FIXME: better resolve from pid from the struct trace_entry
> + * field, although it should be the same than this perf
> + * event pid
> + */
> + print_event(sample->cpu, sample->raw_data, sample->raw_size,
> + sample->time, thread->comm);
> +}
[...]
> diff --git a/tools/perf/util/scripting-engines/trace-event-python.c b/tools/perf/util/scripting-engines/trace-event-python.c
> index 2040b85..5b03fb6 100644
> --- a/tools/perf/util/scripting-engines/trace-event-python.c
> +++ b/tools/perf/util/scripting-engines/trace-event-python.c
> @@ -204,9 +204,9 @@ static inline struct event *find_cache_event(int type)
> return event;
> }
>
> -static void python_process_event(int cpu, void *data,
> - int size __unused,
> - unsigned long long nsecs, char *comm)
> +static void python_process_event(union perf_event *pevent,
> + struct perf_sample *sample,
> + struct perf_session *session)
> {
> PyObject *handler, *retval, *context, *t, *obj, *dict = NULL;
> static char handler_name[256];
> @@ -218,6 +218,20 @@ static void python_process_event(int cpu, void *data,
> int type;
> int pid;

Please avoid such blank line in the middle of local vars declaration.

> + int cpu = sample->cpu;
> + void *data = sample->raw_data;
> + unsigned long long nsecs = sample->time;
> + char *comm;
> + struct thread *thread;
> +
> + thread = perf_session__findnew(session, pevent->ip.pid);
> + if (thread == NULL) {
> + pr_debug("problem processing %d event, skipping it.\n",
> + pevent->header.type);
> + return;
> + }
> + comm = thread->comm;
> +
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: linux-next: manual merge of the net tree with the acpi tree
http://groups.google.com/group/linux.kernel/t/ee0e5c6261285c48?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 2 2011 6:50 pm
From: Stephen Rothwell

Hi all,

Today's linux-next merge of the net tree got a conflict in lib/Makefile
between commit 248852b614cb7713552188a9c2552ba774945733 ("lib, Add
lock-less NULL terminated single list") from the acpi tree and commitc
39649c331c70952700f99832b03f87e9d7f5b4b ("lib: cpu_rmap: CPU affinity
reverse-mapping") from the net tree.

Just overlapping additions. I fixed it up (see below) and can carry the
fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au

diff --cc lib/Makefile
index 7cb0608,b73ba01..0000000
--- a/lib/Makefile
+++ b/lib/Makefile
@@@ -110,8 -110,8 +110,10 @@@ obj-$(CONFIG_ATOMIC64_SELFTEST) += atom

obj-$(CONFIG_AVERAGE) += average.o

+obj-$(CONFIG_LLIST) += llist.o
+
+ obj-$(CONFIG_CPU_RMAP) += cpu_rmap.o
+
hostprogs-y := gen_crc32table
clean-files := crc32table.h

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

==============================================================================
TOPIC: linux-next: manual merge of the net tree with the net-current tree
http://groups.google.com/group/linux.kernel/t/b8dcf3b0965daf20?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 2 2011 6:50 pm
From: Stephen Rothwell

Hi all,

Today's linux-next merge of the net tree got a conflict in
drivers/net/bnx2x/bnx2x.h between commit
b746f7e52fe33ce66ea0cf6127838eff507839ff ("bnx2x: update driver version
to 1.62.00-6") from the net-current tree and commit
6b28ff3be829a851378551245fd6b3f9bf93b0ad ("bnx2x: Update bnx2x version to
1.62.11-0") from the net tree.

Obvious, really :-) I used the version from the net tree.

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

==============================================================================
TOPIC: Staging: hv: Unify the hyperv driver abstractions
http://groups.google.com/group/linux.kernel/t/b8e52e66e905fcc2?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 2 2011 7:00 pm
From: KY Srinivasan

> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Wednesday, March 02, 2011 12:41 AM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org; Haiyang Zhang; Hank
> Janssen
> Subject: Re: [PATCH 4/6] Staging: hv: Unify the hyperv driver abstractions
>
> On Wed, Mar 02, 2011 at 01:43:13AM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:greg@kroah.com]
> > > Sent: Monday, February 28, 2011 9:53 PM
> > > To: KY Srinivasan
> > > Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> > > devel@linuxdriverproject.org; virtualization@lists.osdl.org; Haiyang Zhang;
> Hank
> > > Janssen
> > > Subject: Re: [PATCH 4/6] Staging: hv: Unify the hyperv driver abstractions
> > >
> > > On Fri, Feb 25, 2011 at 06:07:03PM -0800, K. Y. Srinivasan wrote:
> > > > This patch combines the two driver abstractions into
> > > > a single driver abstraction.
> > >
> > > Ah, how sweet. Unfortunatly you don't say "how" you did this.
> > >
> > > Nor do you describe _what_ those two driver abstractions were. Are we
> > > talking i2c and usb abstractions? gpio and spi? Driver core and
> > > platform? We want to know exactly what is going on here.
> >
> > My mistake; I will have a more descriptive comment.
> >
> > >
> > > Think of writing something that when you look back, in 3 years, while
> > > staring at a Linux hyperv driver originally written for the 2.6.9
> > > kernel, that somehow never got forward ported and you are tasked with
> > > doing this, that you can just do a simple 'git log drivers/staging/hv/'
> > > and instantly know just from the changelog comments exactly what you
> > > need to do to your driver to clean it up and properly get it to work on
> > > the new 8.2.2 kernel release.
> > >
> > > This changelog entry, would require you to go and dig through the guts
> > > of the patch itself, trying to figure out what abstractions you are
> > > talking about, and exactly how they were combined, all the while
> > > wondering _why_ they were combined.
> > >
> > > Please, think of your future self, you will thank him in the years to
> > > come by doing this properly. Not to mention making other's lives easier
> > > if you happen to have escaped this dire task by then.
> > >
> > > Oh, you have an extra space up there in the subject, please fix it next
> > > time.
> > >
> > > > -int blk_vsc_initialize(struct hv_driver *driver)
> > > > +int blk_vsc_initialize(struct driver_context *driver)
> > >
> > > "struct driver_context"? Oh please no.
> >
> > Greg; this is the patch that consolidates the state in struct hv_driver into
> > struct driver_context. In the spirit of doing one thing in a patch;
> > other relevant changes are made in:
> > Patch[5/6]: Changes the name driver_context to hyperv_driver
> > Patch[6/6]: Cleanup all variable names that refer to struct hyperv_driver.
>
> Yes, but on its own, this patch is wrong, that is not a valid name, even
> if it is a "temporary" name.

Greg, the temporary name happens to be the name currently in use in the
code - this is not the name I introduced. Think of this as the surviving
data structure after the hv_driver state is consolidated into
(the existing) driver_context data structure. I did this in the spirit of
doing one thing at a time. If I am going to be
picking a more appropriate name for the consolidated data structure; I
might as well pick the final name that we want this unified driver abstraction
to be called.

>
> > > I realize that you are hopefully going to later rename this to something
> > > else, but remember, a few patches back you thought that the "ctx" name
> > > wasn't nice. And here you go resuscitating it from the graveyard of
> > > pointy bits.
> >
> > As I noted in a different email, may be the granularity I chose in breaking up
> > these patches is causing all this confusion.
>
> Yes, as I think you need to go much finer as you were doing more than
> one thing in these patches, and not describing them properly at all.
>
> Please try to redo them in a simpler manner, probably breaking it into
> more steps, so we can properly review them.

Based on your comments on intermediate names, would you recommend that
as part of consolidating the driver abstractions, I also rename this combined
state.

Regards,

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

==============================================================================
TOPIC: userns: remove unneeded extra argument in selinux's task_has_capability
http://groups.google.com/group/linux.kernel/t/52c7d60fa75eec76?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Mar 2 2011 7:00 pm
From: "Serge E. Hallyn"

The user_namespace argument is not used by task_has_capability, so get
rid of it. Note that it was spuriously added by the user namespace
patchset, so we're just cleaning up our own mess.

Signed-off-by: Serge E. Hallyn <serge.hallyn@canonical.com>
---
security/selinux/hooks.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)

Index: linux-2.6/security/selinux/hooks.c
===================================================================
--- linux-2.6.orig/security/selinux/hooks.c 2011-03-03 01:47:01.113745084 +0000
+++ linux-2.6/security/selinux/hooks.c 2011-03-03 01:47:48.017090039 +0000
@@ -1419,7 +1419,6 @@
/* Check whether a task is allowed to use a capability. */
static int task_has_capability(struct task_struct *tsk,
const struct cred *cred,
- struct user_namespace *ns,
int cap, int audit)
{
struct common_audit_data ad;
@@ -1856,7 +1855,7 @@
if (rc)
return rc;

- return task_has_capability(tsk, cred, ns, cap, audit);
+ return task_has_capability(tsk, cred, cap, audit);
}

static int selinux_quotactl(int cmds, int type, int id, struct super_block *sb)
@@ -2886,8 +2885,8 @@

case KDSKBENT:
case KDSKBSENT:
- error = task_has_capability(current, cred, &init_user_ns,
- CAP_SYS_TTY_CONFIG, SECURITY_CAP_AUDIT);
+ error = task_has_capability(current, cred, CAP_SYS_TTY_CONFIG,
+ SECURITY_CAP_AUDIT);
break;

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

== 2 of 2 ==
Date: Wed, Mar 2 2011 7:00 pm
From: "Serge E. Hallyn"

so we can let type safety keep things sane, and as a bonus we can
remove the declaration of init_user_ns in capability.h.

---
include/linux/capability.h | 34 +++-----------------------
kernel/capability.c | 57 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 61 insertions(+), 30 deletions(-)

Index: linux-2.6/include/linux/capability.h
===================================================================
--- linux-2.6.orig/include/linux/capability.h 2011-03-03 02:17:17.533467959 +0000
+++ linux-2.6/include/linux/capability.h 2011-03-03 02:26:56.524786760 +0000
@@ -371,8 +371,6 @@
struct dentry;
struct user_namespace;

-extern struct user_namespace init_user_ns;
-
struct user_namespace *current_user_ns(void);

extern const kernel_cap_t __cap_empty_set;
@@ -541,34 +539,10 @@
cap_intersect(permitted, __cap_nfsd_set));
}

-/**
- * has_capability - Determine if a task has a superior capability available
- * @t: The task in question
- * @cap: The capability to be tested for
- *
- * Return true if the specified task has the given superior capability
- * currently in effect, false if not.
- *
- * Note that this does not set PF_SUPERPRIV on the task.
- */
-#define has_capability(t, cap) (security_real_capable((t), &init_user_ns, (cap)) == 0)
-
-#define has_ns_capability(t, ns, cap) (security_real_capable((t), (ns), (cap)) == 0)
-
-/**
- * has_capability_noaudit - Determine if a task has a superior capability available (unaudited)
- * @t: The task in question
- * @cap: The capability to be tested for
- *
- * Return true if the specified task has the given superior capability
- * currently in effect, false if not, but don't write an audit message for the
- * check.
- *
- * Note that this does not set PF_SUPERPRIV on the task.
- */
-#define has_capability_noaudit(t, cap) \
- (security_real_capable_noaudit((t), &init_user_ns, (cap)) == 0)
-
+extern bool has_capability(struct task_struct *t, int cap);
+extern bool has_ns_capability(struct task_struct *t,
+ struct user_namespace *ns, int cap);
+extern bool has_capability_noaudit(struct task_struct *t, int cap);
extern bool capable(int cap);
extern bool ns_capable(struct user_namespace *ns, int cap);
extern bool task_ns_capable(struct task_struct *t, int cap);
Index: linux-2.6/kernel/capability.c
===================================================================
--- linux-2.6.orig/kernel/capability.c 2011-03-03 02:17:17.523467247 +0000
+++ linux-2.6/kernel/capability.c 2011-03-03 02:52:11.652778780 +0000
@@ -291,6 +291,60 @@
}

/**
+ * has_capability - Does a task have a capability in init_user_ns
+ * @t: The task in question
+ * @cap: The capability to be tested for
+ *
+ * Return true if the specified task has the given superior capability
+ * currently in effect to the initial user namespace, false if not.
+ *
+ * Note that this does not set PF_SUPERPRIV on the task.
+ */
+bool has_capability(struct task_struct *t, int cap)
+{
+ int ret = security_real_capable(t, &init_user_ns, cap);
+
+ return (ret == 0);
+}
+
+/**
+ * has_capability - Does a task have a capability in a specific user ns
+ * @t: The task in question
+ * @ns: target user namespace
+ * @cap: The capability to be tested for
+ *
+ * Return true if the specified task has the given superior capability
+ * currently in effect to the specified user namespace, false if not.
+ *
+ * Note that this does not set PF_SUPERPRIV on the task.
+ */
+bool has_ns_capability(struct task_struct *t,
+ struct user_namespace *ns, int cap)
+{
+ int ret = security_real_capable(t, ns, cap);
+
+ return (ret == 0);
+}
+
+/**
+ * has_capability_noaudit - Does a task have a capability (unaudited)
+ * @t: The task in question
+ * @cap: The capability to be tested for
+ *
+ * Return true if the specified task has the given superior capability
+ * currently in effect to init_user_ns, false if not. Don't write an
+ * audit message for the check.
+ *
+ * Note that this does not set PF_SUPERPRIV on the task.
+ */
+bool has_capability_noaudit(struct task_struct *t, int cap)
+{
+ int ret = security_real_capable_noaudit(t, &init_user_ns, cap);
+
+ return (ret == 0);
+}
+
+/**
* capable - Determine if the current task has a superior capability in effect
* @cap: The capability to be tested for
*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: omap:mailbox: resolve hang issue
http://groups.google.com/group/linux.kernel/t/be956068beab26f6?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 2 2011 7:00 pm
From: "Guzman Lugo, Fernando"

On Wed, Mar 2, 2011 at 7:44 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Armando Uribe <x0095078@ti.com> [110302 13:54]:
>> From: Hari Kanigeri <h-kanigeri2@ti.com>
>>
>> omap4 interrupt disable bits is different. On rx kfifo full, the mbox rx
>> interrupts wasn't getting disabled, and this is causing the rcm stress tests
>> to hang.
>>
>> Signed-off-by: Hari Kanigeri <h-kanigeri2@ti.com>
>> Signed-off-by: Armando Uribe <x0095078@ti.com>
>> Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
>
> Should we merge this as a fix for the 2.6.38 still?

yeah, if it can still be merged in 2.6.38 because it is a fix it would be great.

Regards,
Fernando.

>
> Tony
>
>> ---
>> �arch/arm/mach-omap2/mailbox.c | � 10 ++++++----
>> �1 files changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
>> index 394413d..011ca50 100644
>> --- a/arch/arm/mach-omap2/mailbox.c
>> +++ b/arch/arm/mach-omap2/mailbox.c
>> @@ -193,10 +193,12 @@ static void omap2_mbox_disable_irq(struct omap_mbox *mbox,
>> � � � � � � � omap_mbox_type_t irq)
>> �{
>> � � � struct omap_mbox2_priv *p = mbox->priv;
>> - � � u32 l, bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit;
>> - � � l = mbox_read_reg(p->irqdisable);
>> - � � l &= ~bit;
>> - � � mbox_write_reg(l, p->irqdisable);
>> + � � u32 bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit;
>> +
>> + � � if (!cpu_is_omap44xx())
>> + � � � � � � bit = mbox_read_reg(p->irqdisable) & ~bit;
>> +
>> + � � mbox_write_reg(bit, p->irqdisable);
>> �}
>>
>> �static void omap2_mbox_ack_irq(struct omap_mbox *mbox,
>> --
>> 1.7.0.4
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Wednesday, March 2, 2011

linux.kernel - 26 new messages in 15 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts