[tip:perf/core] perf stat: Introduce --repeat forever

[tip-bot for Frederik Deweerdt]

Commit-ID:  a7e191c376fad084d9f3c7ac89a1f7c47462ebc8
Gitweb: http://git.kernel.org/tip/a7e191c376fad084d9f3c7ac89a1f7c47462ebc8
Author: Frederik Deweerdt 
AuthorDate: Fri, 1 Mar 2013 13:02:27 -0500
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Fri, 15 Mar 2013 14:01:26 -0300

perf stat: Introduce --repeat forever

The following patch causes 'perf stat --repeat 0' to be interpreted as
'forever', displaying the stats for every run.

We act as if a single run was asked, and reset the stats in each
iteration. In this mode SIGINT is passed to perf to be able to stop the
loop with Ctrl+C.

Signed-off-by: Frederik Deweerdt 
Cc: Ingo Molnar 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20130301180227.ga24...@ks398093.ip-192-95-24.net
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-stat.txt |  2 +-
 tools/perf/builtin-stat.c  | 45 ++
 tools/perf/util/evsel.c|  6 +
 tools/perf/util/evsel.h|  1 +
 4 files changed, 48 insertions(+), 6 deletions(-)

diff --git a/tools/perf/Documentation/perf-stat.txt 
b/tools/perf/Documentation/perf-stat.txt
index faf4f4f..23e587a 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -52,7 +52,7 @@ OPTIONS
 
 -r::
 --repeat=::
-   repeat command and print average + stddev (max: 100)
+   repeat command and print average + stddev (max: 100). 0 means forever.
 
 -B::
 --big-num::
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 69fe6ed..021783a 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -94,6 +94,7 @@ static const char *pre_cmd
= NULL;
 static const char  *post_cmd   = NULL;
 static boolsync_run= false;
 static unsigned intinterval= 0;
+static boolforever = false;
 static struct timespec ref_time;
 static struct cpu_map  *sock_map;
 
@@ -125,6 +126,11 @@ static inline int perf_evsel__nr_cpus(struct perf_evsel 
*evsel)
return perf_evsel__cpus(evsel)->nr;
 }
 
+static void perf_evsel__reset_stat_priv(struct perf_evsel *evsel)
+{
+   memset(evsel->priv, 0, sizeof(struct perf_stat));
+}
+
 static int perf_evsel__alloc_stat_priv(struct perf_evsel *evsel)
 {
evsel->priv = zalloc(sizeof(struct perf_stat));
@@ -173,6 +179,22 @@ static struct stats runtime_itlb_cache_stats[MAX_NR_CPUS];
 static struct stats runtime_dtlb_cache_stats[MAX_NR_CPUS];
 static struct stats walltime_nsecs_stats;
 
+static void reset_stats(void)
+{
+   memset(runtime_nsecs_stats, 0, sizeof(runtime_nsecs_stats));
+   memset(runtime_cycles_stats, 0, sizeof(runtime_cycles_stats));
+   memset(runtime_stalled_cycles_front_stats, 0, 
sizeof(runtime_stalled_cycles_front_stats));
+   memset(runtime_stalled_cycles_back_stats, 0, 
sizeof(runtime_stalled_cycles_back_stats));
+   memset(runtime_branches_stats, 0, sizeof(runtime_branches_stats));
+   memset(runtime_cacherefs_stats, 0, sizeof(runtime_cacherefs_stats));
+   memset(runtime_l1_dcache_stats, 0, sizeof(runtime_l1_dcache_stats));
+   memset(runtime_l1_icache_stats, 0, sizeof(runtime_l1_icache_stats));
+   memset(runtime_ll_cache_stats, 0, sizeof(runtime_ll_cache_stats));
+   memset(runtime_itlb_cache_stats, 0, sizeof(runtime_itlb_cache_stats));
+   memset(runtime_dtlb_cache_stats, 0, sizeof(runtime_dtlb_cache_stats));
+   memset(_nsecs_stats, 0, sizeof(walltime_nsecs_stats));
+}
+
 static int create_perf_stat_counter(struct perf_evsel *evsel)
 {
struct perf_event_attr *attr = >attr;
@@ -1252,7 +1274,7 @@ int cmd_stat(int argc, const char **argv, const char 
*prefix __maybe_unused)
OPT_INCR('v', "verbose", ,
"be more verbose (show counter open errors, etc)"),
OPT_INTEGER('r', "repeat", _count,
-   "repeat command and print average + stddev (max: 100)"),
+   "repeat command and print average + stddev (max: 100, 
forever: 0)"),
OPT_BOOLEAN('n', "null", _run,
"null run - dont start any counters"),
OPT_INCR('d', "detailed", _run,
@@ -1355,8 +1377,12 @@ int cmd_stat(int argc, const char **argv, const char 
*prefix __maybe_unused)
 
if (!argc && !perf_target__has_task())
usage_with_options(stat_usage, options);
-   if (run_count <= 0)
+   if (run_count < 0) {
usage_with_options(stat_usage, options);
+   } else if (run_count == 0) {
+   forever = true;
+   run_count = 1;
+   }
 
/* no_aggr, cgroup are for system-wide only */
if ((no_aggr || nr_cgroups) 

[tip:perf/core] perf stat: Introduce --repeat forever

[tip-bot for Frederik Deweerdt]

Commit-ID:  a7e191c376fad084d9f3c7ac89a1f7c47462ebc8
Gitweb: http://git.kernel.org/tip/a7e191c376fad084d9f3c7ac89a1f7c47462ebc8
Author: Frederik Deweerdt frederik.dewee...@xprog.eu
AuthorDate: Fri, 1 Mar 2013 13:02:27 -0500
Committer:  Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Fri, 15 Mar 2013 14:01:26 -0300

perf stat: Introduce --repeat forever

The following patch causes 'perf stat --repeat 0' to be interpreted as
'forever', displaying the stats for every run.

We act as if a single run was asked, and reset the stats in each
iteration. In this mode SIGINT is passed to perf to be able to stop the
loop with Ctrl+C.

Signed-off-by: Frederik Deweerdt frederik.dewee...@gmail.com
Cc: Ingo Molnar mi...@redhat.com
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Link: http://lkml.kernel.org/r/20130301180227.ga24...@ks398093.ip-192-95-24.net
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
 tools/perf/Documentation/perf-stat.txt |  2 +-
 tools/perf/builtin-stat.c  | 45 ++
 tools/perf/util/evsel.c|  6 +
 tools/perf/util/evsel.h|  1 +
 4 files changed, 48 insertions(+), 6 deletions(-)

diff --git a/tools/perf/Documentation/perf-stat.txt 
b/tools/perf/Documentation/perf-stat.txt
index faf4f4f..23e587a 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -52,7 +52,7 @@ OPTIONS
 
 -r::
 --repeat=n::
-   repeat command and print average + stddev (max: 100)
+   repeat command and print average + stddev (max: 100). 0 means forever.
 
 -B::
 --big-num::
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 69fe6ed..021783a 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -94,6 +94,7 @@ static const char *pre_cmd
= NULL;
 static const char  *post_cmd   = NULL;
 static boolsync_run= false;
 static unsigned intinterval= 0;
+static boolforever = false;
 static struct timespec ref_time;
 static struct cpu_map  *sock_map;
 
@@ -125,6 +126,11 @@ static inline int perf_evsel__nr_cpus(struct perf_evsel 
*evsel)
return perf_evsel__cpus(evsel)-nr;
 }
 
+static void perf_evsel__reset_stat_priv(struct perf_evsel *evsel)
+{
+   memset(evsel-priv, 0, sizeof(struct perf_stat));
+}
+
 static int perf_evsel__alloc_stat_priv(struct perf_evsel *evsel)
 {
evsel-priv = zalloc(sizeof(struct perf_stat));
@@ -173,6 +179,22 @@ static struct stats runtime_itlb_cache_stats[MAX_NR_CPUS];
 static struct stats runtime_dtlb_cache_stats[MAX_NR_CPUS];
 static struct stats walltime_nsecs_stats;
 
+static void reset_stats(void)
+{
+   memset(runtime_nsecs_stats, 0, sizeof(runtime_nsecs_stats));
+   memset(runtime_cycles_stats, 0, sizeof(runtime_cycles_stats));
+   memset(runtime_stalled_cycles_front_stats, 0, 
sizeof(runtime_stalled_cycles_front_stats));
+   memset(runtime_stalled_cycles_back_stats, 0, 
sizeof(runtime_stalled_cycles_back_stats));
+   memset(runtime_branches_stats, 0, sizeof(runtime_branches_stats));
+   memset(runtime_cacherefs_stats, 0, sizeof(runtime_cacherefs_stats));
+   memset(runtime_l1_dcache_stats, 0, sizeof(runtime_l1_dcache_stats));
+   memset(runtime_l1_icache_stats, 0, sizeof(runtime_l1_icache_stats));
+   memset(runtime_ll_cache_stats, 0, sizeof(runtime_ll_cache_stats));
+   memset(runtime_itlb_cache_stats, 0, sizeof(runtime_itlb_cache_stats));
+   memset(runtime_dtlb_cache_stats, 0, sizeof(runtime_dtlb_cache_stats));
+   memset(walltime_nsecs_stats, 0, sizeof(walltime_nsecs_stats));
+}
+
 static int create_perf_stat_counter(struct perf_evsel *evsel)
 {
struct perf_event_attr *attr = evsel-attr;
@@ -1252,7 +1274,7 @@ int cmd_stat(int argc, const char **argv, const char 
*prefix __maybe_unused)
OPT_INCR('v', verbose, verbose,
be more verbose (show counter open errors, etc)),
OPT_INTEGER('r', repeat, run_count,
-   repeat command and print average + stddev (max: 100)),
+   repeat command and print average + stddev (max: 100, 
forever: 0)),
OPT_BOOLEAN('n', null, null_run,
null run - dont start any counters),
OPT_INCR('d', detailed, detailed_run,
@@ -1355,8 +1377,12 @@ int cmd_stat(int argc, const char **argv, const char 
*prefix __maybe_unused)
 
if (!argc  !perf_target__has_task(target))
usage_with_options(stat_usage, options);
-   if (run_count = 0)
+   if (run_count  0) {
usage_with_options(stat_usage, options);
+   } else if (run_count == 0) {
+   forever = true;
+   run_count = 1;
+   }
 
/* no_aggr, cgroup are for system

[patch v2] perf stat: --repeat forever

[Frederik Deweerdt]

Hi,

[This is based on git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux 
perf/core]

The following patch causes 'perf stat --repeat 0' to be interpreted as
'forever', displaying the stats for every run.

We act as if a single run was asked, and reset the stats in each
iteration. In this mode SIGINT is passed to perf to be able to stop the
loop with Ctrl+C.

Regards,
Frederik


Signed-off-by: Frederik Deweerdt 

diff --git a/tools/perf/Documentation/perf-stat.txt 
b/tools/perf/Documentation/perf-stat.txt
index faf4f4f..23e587a 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -52,7 +52,7 @@ OPTIONS
 
 -r::
 --repeat=::
-   repeat command and print average + stddev (max: 100)
+   repeat command and print average + stddev (max: 100). 0 means forever.
 
 -B::
 --big-num::
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 9984876..f59ab78 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -94,6 +94,7 @@ static const char *pre_cmd
= NULL;
 static const char  *post_cmd   = NULL;
 static boolsync_run= false;
 static unsigned intinterval= 0;
+static boolforever = false;
 static struct timespec ref_time;
 static struct cpu_map  *sock_map;
 
@@ -125,6 +126,11 @@ static inline int perf_evsel__nr_cpus(struct perf_evsel 
*evsel)
return perf_evsel__cpus(evsel)->nr;
 }
 
+static void perf_evsel__reset_stat_priv(struct perf_evsel *evsel)
+{
+   memset(evsel->priv, 0, sizeof(struct perf_stat));
+}
+
 static int perf_evsel__alloc_stat_priv(struct perf_evsel *evsel)
 {
evsel->priv = zalloc(sizeof(struct perf_stat));
@@ -173,6 +179,22 @@ static struct stats runtime_itlb_cache_stats[MAX_NR_CPUS];
 static struct stats runtime_dtlb_cache_stats[MAX_NR_CPUS];
 static struct stats walltime_nsecs_stats;
 
+static void reset_stats(void)
+{
+   memset(runtime_nsecs_stats, 0, sizeof(runtime_nsecs_stats));
+   memset(runtime_cycles_stats, 0, sizeof(runtime_cycles_stats));
+   memset(runtime_stalled_cycles_front_stats, 0, 
sizeof(runtime_stalled_cycles_front_stats));
+   memset(runtime_stalled_cycles_back_stats, 0, 
sizeof(runtime_stalled_cycles_back_stats));
+   memset(runtime_branches_stats, 0, sizeof(runtime_branches_stats));
+   memset(runtime_cacherefs_stats, 0, sizeof(runtime_cacherefs_stats));
+   memset(runtime_l1_dcache_stats, 0, sizeof(runtime_l1_dcache_stats));
+   memset(runtime_l1_icache_stats, 0, sizeof(runtime_l1_icache_stats));
+   memset(runtime_ll_cache_stats, 0, sizeof(runtime_ll_cache_stats));
+   memset(runtime_itlb_cache_stats, 0, sizeof(runtime_itlb_cache_stats));
+   memset(runtime_dtlb_cache_stats, 0, sizeof(runtime_dtlb_cache_stats));
+   memset(_nsecs_stats, 0, sizeof(walltime_nsecs_stats));
+}
+
 static int create_perf_stat_counter(struct perf_evsel *evsel)
 {
struct perf_event_attr *attr = >attr;
@@ -1296,7 +1318,7 @@ int cmd_stat(int argc, const char **argv, const char 
*prefix __maybe_unused)
OPT_INCR('v', "verbose", ,
"be more verbose (show counter open errors, etc)"),
OPT_INTEGER('r', "repeat", _count,
-   "repeat command and print average + stddev (max: 100)"),
+   "repeat command and print average + stddev (max: 100, 
forever: 0)"),
OPT_BOOLEAN('n', "null", _run,
"null run - dont start any counters"),
OPT_INCR('d', "detailed", _run,
@@ -1399,8 +1421,12 @@ int cmd_stat(int argc, const char **argv, const char 
*prefix __maybe_unused)
 
if (!argc && !perf_target__has_task())
usage_with_options(stat_usage, options);
-   if (run_count <= 0)
+   if (run_count < 0) {
usage_with_options(stat_usage, options);
+   } else if (run_count == 0) {
+   forever = true;
+   run_count = 1;
+   }
 
/* no_aggr, cgroup are for system-wide only */
if ((no_aggr || nr_cgroups) && !perf_target__has_cpu()) {
@@ -1457,21 +1483,30 @@ int cmd_stat(int argc, const char **argv, const char 
*prefix __maybe_unused)
 * task, but being ignored by perf stat itself:
 */
atexit(sig_atexit);
-   signal(SIGINT,  skip_signal);
+   if (!forever)
+   signal(SIGINT,  skip_signal);
signal(SIGCHLD, skip_signal);
signal(SIGALRM, skip_signal);
signal(SIGABRT, skip_signal);
 
status = 0;
-   for (run_idx = 0; run_idx < run_count; run_idx++) {
+   for (run_idx = 0; forever || run_idx < run_count; run_idx++) {
if (run_count != 1 && verbose

[patch v2] perf stat: --repeat forever

[Frederik Deweerdt]

Hi,

[This is based on git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux 
perf/core]

The following patch causes 'perf stat --repeat 0' to be interpreted as
'forever', displaying the stats for every run.

We act as if a single run was asked, and reset the stats in each
iteration. In this mode SIGINT is passed to perf to be able to stop the
loop with Ctrl+C.

Regards,
Frederik


Signed-off-by: Frederik Deweerdt frederik.dewee...@gmail.com

diff --git a/tools/perf/Documentation/perf-stat.txt 
b/tools/perf/Documentation/perf-stat.txt
index faf4f4f..23e587a 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -52,7 +52,7 @@ OPTIONS
 
 -r::
 --repeat=n::
-   repeat command and print average + stddev (max: 100)
+   repeat command and print average + stddev (max: 100). 0 means forever.
 
 -B::
 --big-num::
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 9984876..f59ab78 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -94,6 +94,7 @@ static const char *pre_cmd
= NULL;
 static const char  *post_cmd   = NULL;
 static boolsync_run= false;
 static unsigned intinterval= 0;
+static boolforever = false;
 static struct timespec ref_time;
 static struct cpu_map  *sock_map;
 
@@ -125,6 +126,11 @@ static inline int perf_evsel__nr_cpus(struct perf_evsel 
*evsel)
return perf_evsel__cpus(evsel)-nr;
 }
 
+static void perf_evsel__reset_stat_priv(struct perf_evsel *evsel)
+{
+   memset(evsel-priv, 0, sizeof(struct perf_stat));
+}
+
 static int perf_evsel__alloc_stat_priv(struct perf_evsel *evsel)
 {
evsel-priv = zalloc(sizeof(struct perf_stat));
@@ -173,6 +179,22 @@ static struct stats runtime_itlb_cache_stats[MAX_NR_CPUS];
 static struct stats runtime_dtlb_cache_stats[MAX_NR_CPUS];
 static struct stats walltime_nsecs_stats;
 
+static void reset_stats(void)
+{
+   memset(runtime_nsecs_stats, 0, sizeof(runtime_nsecs_stats));
+   memset(runtime_cycles_stats, 0, sizeof(runtime_cycles_stats));
+   memset(runtime_stalled_cycles_front_stats, 0, 
sizeof(runtime_stalled_cycles_front_stats));
+   memset(runtime_stalled_cycles_back_stats, 0, 
sizeof(runtime_stalled_cycles_back_stats));
+   memset(runtime_branches_stats, 0, sizeof(runtime_branches_stats));
+   memset(runtime_cacherefs_stats, 0, sizeof(runtime_cacherefs_stats));
+   memset(runtime_l1_dcache_stats, 0, sizeof(runtime_l1_dcache_stats));
+   memset(runtime_l1_icache_stats, 0, sizeof(runtime_l1_icache_stats));
+   memset(runtime_ll_cache_stats, 0, sizeof(runtime_ll_cache_stats));
+   memset(runtime_itlb_cache_stats, 0, sizeof(runtime_itlb_cache_stats));
+   memset(runtime_dtlb_cache_stats, 0, sizeof(runtime_dtlb_cache_stats));
+   memset(walltime_nsecs_stats, 0, sizeof(walltime_nsecs_stats));
+}
+
 static int create_perf_stat_counter(struct perf_evsel *evsel)
 {
struct perf_event_attr *attr = evsel-attr;
@@ -1296,7 +1318,7 @@ int cmd_stat(int argc, const char **argv, const char 
*prefix __maybe_unused)
OPT_INCR('v', verbose, verbose,
be more verbose (show counter open errors, etc)),
OPT_INTEGER('r', repeat, run_count,
-   repeat command and print average + stddev (max: 100)),
+   repeat command and print average + stddev (max: 100, 
forever: 0)),
OPT_BOOLEAN('n', null, null_run,
null run - dont start any counters),
OPT_INCR('d', detailed, detailed_run,
@@ -1399,8 +1421,12 @@ int cmd_stat(int argc, const char **argv, const char 
*prefix __maybe_unused)
 
if (!argc  !perf_target__has_task(target))
usage_with_options(stat_usage, options);
-   if (run_count = 0)
+   if (run_count  0) {
usage_with_options(stat_usage, options);
+   } else if (run_count == 0) {
+   forever = true;
+   run_count = 1;
+   }
 
/* no_aggr, cgroup are for system-wide only */
if ((no_aggr || nr_cgroups)  !perf_target__has_cpu(target)) {
@@ -1457,21 +1483,30 @@ int cmd_stat(int argc, const char **argv, const char 
*prefix __maybe_unused)
 * task, but being ignored by perf stat itself:
 */
atexit(sig_atexit);
-   signal(SIGINT,  skip_signal);
+   if (!forever)
+   signal(SIGINT,  skip_signal);
signal(SIGCHLD, skip_signal);
signal(SIGALRM, skip_signal);
signal(SIGABRT, skip_signal);
 
status = 0;
-   for (run_idx = 0; run_idx  run_count; run_idx++) {
+   for (run_idx = 0; forever || run_idx  run_count; run_idx++) {
if (run_count != 1  verbose)
fprintf(output, [ perf stat: executing run #%d ... 
]\n

Re: [patch] perf stat: --repeat forever

[Frederik Deweerdt]

Hi Arnaldo,

On Mon, Feb 18, 2013 at 12:04:44PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Feb 15, 2013 at 05:28:49PM -0500, Frederik Deweerdt escreveu:
> > Hi,
> > 
> > The following patch causes 'perf stat --repeat 0' to be interpreted as
> > 'forever', displaying the stats for every run.
> > 
> > We act as if a single run was asked, and reset the stats in each
> > iteration. In this mode SIGINT is passed to perf to be able to stop the
> > loop with Ctrl+C.
> 
> It is not applying to my perf/core branch, please take a look at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux
> 
> branch perf/core
> 
Noted, I'll base the next version based on this branch.

> Also please consider removing the need to specify 0, i.e. I think this
> is possible and shorter:
> 
> # perf stat -a --repeat sleep 1

I'm unsure how to achieve that. I've looked at the different OPT_*
defines, but I can't find one that would do the job. Any pointers?

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

Re: [patch] perf stat: --repeat forever

[Frederik Deweerdt]

Hi Arnaldo,

On Mon, Feb 18, 2013 at 12:04:44PM -0300, Arnaldo Carvalho de Melo wrote:
 Em Fri, Feb 15, 2013 at 05:28:49PM -0500, Frederik Deweerdt escreveu:
  Hi,
  
  The following patch causes 'perf stat --repeat 0' to be interpreted as
  'forever', displaying the stats for every run.
  
  We act as if a single run was asked, and reset the stats in each
  iteration. In this mode SIGINT is passed to perf to be able to stop the
  loop with Ctrl+C.
 
 It is not applying to my perf/core branch, please take a look at:
 
 git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux
 
 branch perf/core
 
Noted, I'll base the next version based on this branch.

 Also please consider removing the need to specify 0, i.e. I think this
 is possible and shorter:
 
 # perf stat -a --repeat sleep 1

I'm unsure how to achieve that. I've looked at the different OPT_*
defines, but I can't find one that would do the job. Any pointers?

Thanks,
Frederik
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] perf stat: --repeat forever

[Frederik Deweerdt]

Hi,

The following patch causes 'perf stat --repeat 0' to be interpreted as
'forever', displaying the stats for every run.

We act as if a single run was asked, and reset the stats in each
iteration. In this mode SIGINT is passed to perf to be able to stop the
loop with Ctrl+C.

Regards,
Frederik


Signed-off-by: Frederik Deweerdt 

diff --git a/tools/perf/Documentation/perf-stat.txt 
b/tools/perf/Documentation/perf-stat.txt
index cf0c310..784976a 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -52,7 +52,7 @@ OPTIONS
 
 -r::
 --repeat=::
-   repeat command and print average + stddev (max: 100)
+   repeat command and print average + stddev (max: 100). 0 means forever.
 
 -B::
 --big-num::
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index c247fac..b02b3a9 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -87,6 +87,7 @@ static FILE   *output 
= NULL;
 static const char  *pre_cmd= NULL;
 static const char  *post_cmd   = NULL;
 static boolsync_run= false;
+static boolforever = false;
 
 static volatile int done = 0;
 
@@ -94,6 +95,11 @@ struct perf_stat {
struct stats  res_stats[3];
 };
 
+static void perf_evsel__reset_stat_priv(struct perf_evsel *evsel)
+{
+   memset(evsel->priv, 0, sizeof(struct perf_stat));
+}
+
 static int perf_evsel__alloc_stat_priv(struct perf_evsel *evsel)
 {
evsel->priv = zalloc(sizeof(struct perf_stat));
@@ -129,6 +135,22 @@ static struct stats runtime_itlb_cache_stats[MAX_NR_CPUS];
 static struct stats runtime_dtlb_cache_stats[MAX_NR_CPUS];
 static struct stats walltime_nsecs_stats;
 
+static void reset_stats(void)
+{
+   memset(runtime_nsecs_stats, 0, sizeof(runtime_nsecs_stats));
+   memset(runtime_cycles_stats, 0, sizeof(runtime_cycles_stats));
+   memset(runtime_stalled_cycles_front_stats, 0, 
sizeof(runtime_stalled_cycles_front_stats));
+   memset(runtime_stalled_cycles_back_stats, 0, 
sizeof(runtime_stalled_cycles_back_stats));
+   memset(runtime_branches_stats, 0, sizeof(runtime_branches_stats));
+   memset(runtime_cacherefs_stats, 0, sizeof(runtime_cacherefs_stats));
+   memset(runtime_l1_dcache_stats, 0, sizeof(runtime_l1_dcache_stats));
+   memset(runtime_l1_icache_stats, 0, sizeof(runtime_l1_icache_stats));
+   memset(runtime_ll_cache_stats, 0, sizeof(runtime_ll_cache_stats));
+   memset(runtime_itlb_cache_stats, 0, sizeof(runtime_itlb_cache_stats));
+   memset(runtime_dtlb_cache_stats, 0, sizeof(runtime_dtlb_cache_stats));
+   memset(_nsecs_stats, 0, sizeof(walltime_nsecs_stats));
+}
+
 static int create_perf_stat_counter(struct perf_evsel *evsel)
 {
struct perf_event_attr *attr = >attr;
@@ -1120,7 +1142,7 @@ int cmd_stat(int argc, const char **argv, const char 
*prefix __maybe_unused)
OPT_INCR('v', "verbose", ,
"be more verbose (show counter open errors, etc)"),
OPT_INTEGER('r', "repeat", _count,
-   "repeat command and print average + stddev (max: 100)"),
+   "repeat command and print average + stddev (max: 100, 
forever: 0)"),
OPT_BOOLEAN('n', "null", _run,
"null run - dont start any counters"),
OPT_INCR('d', "detailed", _run,
@@ -1220,8 +1242,12 @@ int cmd_stat(int argc, const char **argv, const char 
*prefix __maybe_unused)
 
if (!argc && !perf_target__has_task())
usage_with_options(stat_usage, options);
-   if (run_count <= 0)
+   if (run_count < 0) {
usage_with_options(stat_usage, options);
+   } else if (run_count == 0) {
+   forever = true;
+   run_count = 1;
+   }
 
/* no_aggr, cgroup are for system-wide only */
if ((no_aggr || nr_cgroups) && !perf_target__has_cpu()) {
@@ -1259,21 +1285,31 @@ int cmd_stat(int argc, const char **argv, const char 
*prefix __maybe_unused)
 * task, but being ignored by perf stat itself:
 */
atexit(sig_atexit);
-   signal(SIGINT,  skip_signal);
+   if (!forever)
+   signal(SIGINT,  skip_signal);
signal(SIGALRM, skip_signal);
signal(SIGABRT, skip_signal);
 
status = 0;
-   for (run_idx = 0; run_idx < run_count; run_idx++) {
+   for (run_idx = 0; forever || run_idx < run_count; run_idx++) {
if (run_count != 1 && verbose)
fprintf(output, "[ perf stat: executing run #%d ... 
]\n",
-   run_idx + 1);
+   run_idx + 1);
 
 

[patch] perf stat: --repeat forever

[Frederik Deweerdt]

Hi,

The following patch causes 'perf stat --repeat 0' to be interpreted as
'forever', displaying the stats for every run.

We act as if a single run was asked, and reset the stats in each
iteration. In this mode SIGINT is passed to perf to be able to stop the
loop with Ctrl+C.

Regards,
Frederik


Signed-off-by: Frederik Deweerdt frederik.dewee...@gmail.com

diff --git a/tools/perf/Documentation/perf-stat.txt 
b/tools/perf/Documentation/perf-stat.txt
index cf0c310..784976a 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -52,7 +52,7 @@ OPTIONS
 
 -r::
 --repeat=n::
-   repeat command and print average + stddev (max: 100)
+   repeat command and print average + stddev (max: 100). 0 means forever.
 
 -B::
 --big-num::
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index c247fac..b02b3a9 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -87,6 +87,7 @@ static FILE   *output 
= NULL;
 static const char  *pre_cmd= NULL;
 static const char  *post_cmd   = NULL;
 static boolsync_run= false;
+static boolforever = false;
 
 static volatile int done = 0;
 
@@ -94,6 +95,11 @@ struct perf_stat {
struct stats  res_stats[3];
 };
 
+static void perf_evsel__reset_stat_priv(struct perf_evsel *evsel)
+{
+   memset(evsel-priv, 0, sizeof(struct perf_stat));
+}
+
 static int perf_evsel__alloc_stat_priv(struct perf_evsel *evsel)
 {
evsel-priv = zalloc(sizeof(struct perf_stat));
@@ -129,6 +135,22 @@ static struct stats runtime_itlb_cache_stats[MAX_NR_CPUS];
 static struct stats runtime_dtlb_cache_stats[MAX_NR_CPUS];
 static struct stats walltime_nsecs_stats;
 
+static void reset_stats(void)
+{
+   memset(runtime_nsecs_stats, 0, sizeof(runtime_nsecs_stats));
+   memset(runtime_cycles_stats, 0, sizeof(runtime_cycles_stats));
+   memset(runtime_stalled_cycles_front_stats, 0, 
sizeof(runtime_stalled_cycles_front_stats));
+   memset(runtime_stalled_cycles_back_stats, 0, 
sizeof(runtime_stalled_cycles_back_stats));
+   memset(runtime_branches_stats, 0, sizeof(runtime_branches_stats));
+   memset(runtime_cacherefs_stats, 0, sizeof(runtime_cacherefs_stats));
+   memset(runtime_l1_dcache_stats, 0, sizeof(runtime_l1_dcache_stats));
+   memset(runtime_l1_icache_stats, 0, sizeof(runtime_l1_icache_stats));
+   memset(runtime_ll_cache_stats, 0, sizeof(runtime_ll_cache_stats));
+   memset(runtime_itlb_cache_stats, 0, sizeof(runtime_itlb_cache_stats));
+   memset(runtime_dtlb_cache_stats, 0, sizeof(runtime_dtlb_cache_stats));
+   memset(walltime_nsecs_stats, 0, sizeof(walltime_nsecs_stats));
+}
+
 static int create_perf_stat_counter(struct perf_evsel *evsel)
 {
struct perf_event_attr *attr = evsel-attr;
@@ -1120,7 +1142,7 @@ int cmd_stat(int argc, const char **argv, const char 
*prefix __maybe_unused)
OPT_INCR('v', verbose, verbose,
be more verbose (show counter open errors, etc)),
OPT_INTEGER('r', repeat, run_count,
-   repeat command and print average + stddev (max: 100)),
+   repeat command and print average + stddev (max: 100, 
forever: 0)),
OPT_BOOLEAN('n', null, null_run,
null run - dont start any counters),
OPT_INCR('d', detailed, detailed_run,
@@ -1220,8 +1242,12 @@ int cmd_stat(int argc, const char **argv, const char 
*prefix __maybe_unused)
 
if (!argc  !perf_target__has_task(target))
usage_with_options(stat_usage, options);
-   if (run_count = 0)
+   if (run_count  0) {
usage_with_options(stat_usage, options);
+   } else if (run_count == 0) {
+   forever = true;
+   run_count = 1;
+   }
 
/* no_aggr, cgroup are for system-wide only */
if ((no_aggr || nr_cgroups)  !perf_target__has_cpu(target)) {
@@ -1259,21 +1285,31 @@ int cmd_stat(int argc, const char **argv, const char 
*prefix __maybe_unused)
 * task, but being ignored by perf stat itself:
 */
atexit(sig_atexit);
-   signal(SIGINT,  skip_signal);
+   if (!forever)
+   signal(SIGINT,  skip_signal);
signal(SIGALRM, skip_signal);
signal(SIGABRT, skip_signal);
 
status = 0;
-   for (run_idx = 0; run_idx  run_count; run_idx++) {
+   for (run_idx = 0; forever || run_idx  run_count; run_idx++) {
if (run_count != 1  verbose)
fprintf(output, [ perf stat: executing run #%d ... 
]\n,
-   run_idx + 1);
+   run_idx + 1);
 
status = run_perf_stat(argc, argv);
+   if (forever  status != -1

[tip:perf/core] perf annotate browser: Fix segfault when drawing out-of-bounds jumps

[tip-bot for Frederik Deweerdt]

Commit-ID:  865c66c4183aab1d12522ca3ad3a3339d2437e5c
Gitweb: http://git.kernel.org/tip/865c66c4183aab1d12522ca3ad3a3339d2437e5c
Author: Frederik Deweerdt 
AuthorDate: Mon, 14 Jan 2013 14:47:17 -0500
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 24 Jan 2013 16:40:36 -0300

perf annotate browser: Fix segfault when drawing out-of-bounds jumps

Factorize jump sanity checks from mark_jump_targets() and
draw_current_jump() in an is_valid_jump() function.

This fixes a segfault when moving the cursor over an invalid jump.

Signed-off-by: Frederik Deweerdt 
Cc: Namhyung Kim 
Link: http://lkml.kernel.org/r/20130114194716.ga4...@ks398093.ip-192-95-24.net
[ committer note: Make it a disasm_line method ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/ui/browsers/annotate.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/tools/perf/ui/browsers/annotate.c 
b/tools/perf/ui/browsers/annotate.c
index 5dab3ca..2fc7f04 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -182,6 +182,16 @@ static void annotate_browser__write(struct ui_browser 
*browser, void *entry, int
ab->selection = dl;
 }
 
+static bool disasm_line__is_valid_jump(struct disasm_line *dl, struct symbol 
*sym)
+{
+   if (!dl || !dl->ins || !ins__is_jump(dl->ins)
+   || !disasm_line__has_offset(dl)
+   || dl->ops.target.offset >= symbol__size(sym))
+   return false;
+
+   return true;
+}
+
 static void annotate_browser__draw_current_jump(struct ui_browser *browser)
 {
struct annotate_browser *ab = container_of(browser, struct 
annotate_browser, b);
@@ -195,8 +205,7 @@ static void annotate_browser__draw_current_jump(struct 
ui_browser *browser)
if (strstr(sym->name, "@plt"))
return;
 
-   if (!cursor || !cursor->ins || !ins__is_jump(cursor->ins) ||
-   !disasm_line__has_offset(cursor))
+   if (!disasm_line__is_valid_jump(cursor, sym))
return;
 
target = ab->offsets[cursor->ops.target.offset];
@@ -788,17 +797,9 @@ static void annotate_browser__mark_jump_targets(struct 
annotate_browser *browser
struct disasm_line *dl = browser->offsets[offset], *dlt;
struct browser_disasm_line *bdlt;
 
-   if (!dl || !dl->ins || !ins__is_jump(dl->ins) ||
-   !disasm_line__has_offset(dl))
+   if (!disasm_line__is_valid_jump(dl, sym))
continue;
 
-   if (dl->ops.target.offset >= size) {
-   ui__error("jump to after symbol!\n"
- "size: %zx, jump target: %" PRIx64,
- size, dl->ops.target.offset);
-   continue;
-   }
-
dlt = browser->offsets[dl->ops.target.offset];
/*
 * FIXME: Oops, no jump target? Buggy disassembler? Or do we
@@ -921,7 +922,7 @@ out_free_offsets:
 
 #define ANNOTATE_CFG(n) \
{ .name = #n, .value = _browser__opts.n, }
-   
+
 /*
  * Keep the entries sorted, they are bsearch'ed
  */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf annotate browser: Fix segfault when drawing out-of-bounds jumps

[tip-bot for Frederik Deweerdt]

Commit-ID:  865c66c4183aab1d12522ca3ad3a3339d2437e5c
Gitweb: http://git.kernel.org/tip/865c66c4183aab1d12522ca3ad3a3339d2437e5c
Author: Frederik Deweerdt frederik.dewee...@xprog.eu
AuthorDate: Mon, 14 Jan 2013 14:47:17 -0500
Committer:  Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Thu, 24 Jan 2013 16:40:36 -0300

perf annotate browser: Fix segfault when drawing out-of-bounds jumps

Factorize jump sanity checks from mark_jump_targets() and
draw_current_jump() in an is_valid_jump() function.

This fixes a segfault when moving the cursor over an invalid jump.

Signed-off-by: Frederik Deweerdt frederik.dewee...@xprog.eu
Cc: Namhyung Kim namhy...@kernel.org
Link: http://lkml.kernel.org/r/20130114194716.ga4...@ks398093.ip-192-95-24.net
[ committer note: Make it a disasm_line method ]
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
 tools/perf/ui/browsers/annotate.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/tools/perf/ui/browsers/annotate.c 
b/tools/perf/ui/browsers/annotate.c
index 5dab3ca..2fc7f04 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -182,6 +182,16 @@ static void annotate_browser__write(struct ui_browser 
*browser, void *entry, int
ab-selection = dl;
 }
 
+static bool disasm_line__is_valid_jump(struct disasm_line *dl, struct symbol 
*sym)
+{
+   if (!dl || !dl-ins || !ins__is_jump(dl-ins)
+   || !disasm_line__has_offset(dl)
+   || dl-ops.target.offset = symbol__size(sym))
+   return false;
+
+   return true;
+}
+
 static void annotate_browser__draw_current_jump(struct ui_browser *browser)
 {
struct annotate_browser *ab = container_of(browser, struct 
annotate_browser, b);
@@ -195,8 +205,7 @@ static void annotate_browser__draw_current_jump(struct 
ui_browser *browser)
if (strstr(sym-name, @plt))
return;
 
-   if (!cursor || !cursor-ins || !ins__is_jump(cursor-ins) ||
-   !disasm_line__has_offset(cursor))
+   if (!disasm_line__is_valid_jump(cursor, sym))
return;
 
target = ab-offsets[cursor-ops.target.offset];
@@ -788,17 +797,9 @@ static void annotate_browser__mark_jump_targets(struct 
annotate_browser *browser
struct disasm_line *dl = browser-offsets[offset], *dlt;
struct browser_disasm_line *bdlt;
 
-   if (!dl || !dl-ins || !ins__is_jump(dl-ins) ||
-   !disasm_line__has_offset(dl))
+   if (!disasm_line__is_valid_jump(dl, sym))
continue;
 
-   if (dl-ops.target.offset = size) {
-   ui__error(jump to after symbol!\n
- size: %zx, jump target: % PRIx64,
- size, dl-ops.target.offset);
-   continue;
-   }
-
dlt = browser-offsets[dl-ops.target.offset];
/*
 * FIXME: Oops, no jump target? Buggy disassembler? Or do we
@@ -921,7 +922,7 @@ out_free_offsets:
 
 #define ANNOTATE_CFG(n) \
{ .name = #n, .value = annotate_browser__opts.n, }
-   
+
 /*
  * Keep the entries sorted, they are bsearch'ed
  */
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] perf: tui: Fix segfault when drawing out-of-bounds jumps

[Frederik Deweerdt]

On Mon, Jan 14, 2013 at 10:44:16AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jan 11, 2013 at 07:00:43PM -0500, Frederik Deweerdt escreveu:
> > Hi,
> > 
> > When perf.data contains out-of-symbol jumps,
> > annotate_browser__mark_jump_targets() correctly avoids marking
> > out-of-symbol jump targets. However, when moving the cursor on one of
> > said jumps, annotate_browser__draw_current_jump() will end up with a
> > bogus 'target' pointer, causing a bogus memory access when dereferencing
> > 'bcursor' or 'btarget'
> > 
> > The following patch performs the same check as mark_jump_targets()
> > in order to avoid drawing the bogus jump.
> 
> Thanks, I'll apply this one later today and introduce a
> disasm_line__is_valid_jump(cursor) routine to be used in both mark and
> draw routines, if you don't do it first :-)

I thought of that, but the code currently displays an error message in
the mark_jump_targets() case:

if (dl->ops.target.offset >= size) {
ui__error("jump to after symbol!\n"
  "size: %zx, jump target: %" PRIx64,
  size, dl->ops.target.offset);
continue;
}

That said, the message is kind of useless and annoying (happens well
over a dozen of times) in the case I hit it (annotate __strstr_sse42).

How about the following:

Factorize jump sanity checks from mark_jump_targets() and
draw_current_jump() in an is_valid_jump() function.

This fixes a segfaut when moving the cursor over an invalid jump.

Signed-off-by: Frederik Deweerdt 

diff --git a/tools/perf/ui/browsers/annotate.c 
b/tools/perf/ui/browsers/annotate.c
index 5dab3ca..43ae4f6 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -182,6 +182,16 @@ static void annotate_browser__write(struct ui_browser 
*browser, void *entry, int
ab->selection = dl;
 }
 
+static bool annotate_browser__is_valid_jump(struct symbol *sym, struct 
disasm_line *dl)
+{
+   if (!dl || !dl->ins || !ins__is_jump(dl->ins)
+   || !disasm_line__has_offset(dl)
+   || dl->ops.target.offset >= symbol__size(sym))
+   return false;
+
+   return true;
+}
+
 static void annotate_browser__draw_current_jump(struct ui_browser *browser)
 {
struct annotate_browser *ab = container_of(browser, struct 
annotate_browser, b);
@@ -195,8 +205,7 @@ static void annotate_browser__draw_current_jump(struct 
ui_browser *browser)
if (strstr(sym->name, "@plt"))
return;
 
-   if (!cursor || !cursor->ins || !ins__is_jump(cursor->ins) ||
-   !disasm_line__has_offset(cursor))
+   if (!annotate_browser__is_valid_jump(sym, cursor))
return;
 
target = ab->offsets[cursor->ops.target.offset];
@@ -788,17 +797,9 @@ static void annotate_browser__mark_jump_targets(struct 
annotate_browser *browser
struct disasm_line *dl = browser->offsets[offset], *dlt;
struct browser_disasm_line *bdlt;
 
-   if (!dl || !dl->ins || !ins__is_jump(dl->ins) ||
-   !disasm_line__has_offset(dl))
+   if (!annotate_browser__is_valid_jump(sym, dl))
continue;
 
-   if (dl->ops.target.offset >= size) {
-   ui__error("jump to after symbol!\n"
- "size: %zx, jump target: %" PRIx64,
- size, dl->ops.target.offset);
-   continue;
-   }
-
dlt = browser->offsets[dl->ops.target.offset];
/*
 * FIXME: Oops, no jump target? Buggy disassembler? Or do we
@@ -921,7 +922,7 @@ out_free_offsets:
 
 #define ANNOTATE_CFG(n) \
{ .name = #n, .value = _browser__opts.n, }
-   
+
 /*
  * Keep the entries sorted, they are bsearch'ed
  */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] perf: tui: Fix segfault when drawing out-of-bounds jumps

[Frederik Deweerdt]

On Mon, Jan 14, 2013 at 10:44:16AM -0300, Arnaldo Carvalho de Melo wrote:
 Em Fri, Jan 11, 2013 at 07:00:43PM -0500, Frederik Deweerdt escreveu:
  Hi,
  
  When perf.data contains out-of-symbol jumps,
  annotate_browser__mark_jump_targets() correctly avoids marking
  out-of-symbol jump targets. However, when moving the cursor on one of
  said jumps, annotate_browser__draw_current_jump() will end up with a
  bogus 'target' pointer, causing a bogus memory access when dereferencing
  'bcursor' or 'btarget'
  
  The following patch performs the same check as mark_jump_targets()
  in order to avoid drawing the bogus jump.
 
 Thanks, I'll apply this one later today and introduce a
 disasm_line__is_valid_jump(cursor) routine to be used in both mark and
 draw routines, if you don't do it first :-)

I thought of that, but the code currently displays an error message in
the mark_jump_targets() case:

if (dl-ops.target.offset = size) {
ui__error(jump to after symbol!\n
  size: %zx, jump target: % PRIx64,
  size, dl-ops.target.offset);
continue;
}

That said, the message is kind of useless and annoying (happens well
over a dozen of times) in the case I hit it (annotate __strstr_sse42).

How about the following:

Factorize jump sanity checks from mark_jump_targets() and
draw_current_jump() in an is_valid_jump() function.

This fixes a segfaut when moving the cursor over an invalid jump.

Signed-off-by: Frederik Deweerdt frederik.dewee...@xprog.eu

diff --git a/tools/perf/ui/browsers/annotate.c 
b/tools/perf/ui/browsers/annotate.c
index 5dab3ca..43ae4f6 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -182,6 +182,16 @@ static void annotate_browser__write(struct ui_browser 
*browser, void *entry, int
ab-selection = dl;
 }
 
+static bool annotate_browser__is_valid_jump(struct symbol *sym, struct 
disasm_line *dl)
+{
+   if (!dl || !dl-ins || !ins__is_jump(dl-ins)
+   || !disasm_line__has_offset(dl)
+   || dl-ops.target.offset = symbol__size(sym))
+   return false;
+
+   return true;
+}
+
 static void annotate_browser__draw_current_jump(struct ui_browser *browser)
 {
struct annotate_browser *ab = container_of(browser, struct 
annotate_browser, b);
@@ -195,8 +205,7 @@ static void annotate_browser__draw_current_jump(struct 
ui_browser *browser)
if (strstr(sym-name, @plt))
return;
 
-   if (!cursor || !cursor-ins || !ins__is_jump(cursor-ins) ||
-   !disasm_line__has_offset(cursor))
+   if (!annotate_browser__is_valid_jump(sym, cursor))
return;
 
target = ab-offsets[cursor-ops.target.offset];
@@ -788,17 +797,9 @@ static void annotate_browser__mark_jump_targets(struct 
annotate_browser *browser
struct disasm_line *dl = browser-offsets[offset], *dlt;
struct browser_disasm_line *bdlt;
 
-   if (!dl || !dl-ins || !ins__is_jump(dl-ins) ||
-   !disasm_line__has_offset(dl))
+   if (!annotate_browser__is_valid_jump(sym, dl))
continue;
 
-   if (dl-ops.target.offset = size) {
-   ui__error(jump to after symbol!\n
- size: %zx, jump target: % PRIx64,
- size, dl-ops.target.offset);
-   continue;
-   }
-
dlt = browser-offsets[dl-ops.target.offset];
/*
 * FIXME: Oops, no jump target? Buggy disassembler? Or do we
@@ -921,7 +922,7 @@ out_free_offsets:
 
 #define ANNOTATE_CFG(n) \
{ .name = #n, .value = annotate_browser__opts.n, }
-   
+
 /*
  * Keep the entries sorted, they are bsearch'ed
  */
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] perf: tui: Fix segfault when drawing out-of-bounds jumps

[Frederik Deweerdt]

Hi,

When perf.data contains out-of-symbol jumps,
annotate_browser__mark_jump_targets() correctly avoids marking
out-of-symbol jump targets. However, when moving the cursor on one of
said jumps, annotate_browser__draw_current_jump() will end up with a
bogus 'target' pointer, causing a bogus memory access when dereferencing
'bcursor' or 'btarget'

The following patch performs the same check as mark_jump_targets()
in order to avoid drawing the bogus jump.

Regards,
Frederik

Signed-off-by: Frederik Deweerdt 

diff --git a/tools/perf/ui/browsers/annotate.c 
b/tools/perf/ui/browsers/annotate.c
index 5dab3ca..8b84246 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -195,8 +195,9 @@ static void annotate_browser__draw_current_jump(struct 
ui_browser *browser)
if (strstr(sym->name, "@plt"))
return;
 
-   if (!cursor || !cursor->ins || !ins__is_jump(cursor->ins) ||
-   !disasm_line__has_offset(cursor))
+   if (!cursor || !cursor->ins || !ins__is_jump(cursor->ins)
+   || !disasm_line__has_offset(cursor)
+   || cursor->ops.target.offset >= symbol__size(sym))
return;
 
target = ab->offsets[cursor->ops.target.offset];
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf: tui: Fix segfault when drawing out-of-bounds jumps

[Frederik Deweerdt]

Hi,

When perf.data contains out-of-symbol jumps,
annotate_browser__mark_jump_targets() correctly avoids marking
out-of-symbol jump targets. However, when moving the cursor on one of
said jumps, annotate_browser__draw_current_jump() will end up with a
bogus 'target' pointer, causing a bogus memory access when dereferencing
'bcursor' or 'btarget'

The following patch performs the same check as mark_jump_targets()
in order to avoid drawing the bogus jump.

Regards,
Frederik

Signed-off-by: Frederik Deweerdt frederik.dewee...@xprog.eu

diff --git a/tools/perf/ui/browsers/annotate.c 
b/tools/perf/ui/browsers/annotate.c
index 5dab3ca..8b84246 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -195,8 +195,9 @@ static void annotate_browser__draw_current_jump(struct 
ui_browser *browser)
if (strstr(sym-name, @plt))
return;
 
-   if (!cursor || !cursor-ins || !ins__is_jump(cursor-ins) ||
-   !disasm_line__has_offset(cursor))
+   if (!cursor || !cursor-ins || !ins__is_jump(cursor-ins)
+   || !disasm_line__has_offset(cursor)
+   || cursor-ops.target.offset = symbol__size(sym))
return;
 
target = ab-offsets[cursor-ops.target.offset];
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: Hyperthreading performance oddities

[Frederik Deweerdt]

Hello Henk,

On Fri, Feb 22, 2008 at 10:36:01AM +0100, belcampo wrote:
> Kernel 2.6.22.9 smp hyperthreading
> BENCHMARKs: VC: 334.042s VO:   0.053s A:   0.000s Sys:   4.049s =  338.143s
> Kernel 2.6.22.9 nonsmp/hyperthreading
> BENCHMARKs: VC: 262.008s VO:   0.031s A:   0.000s Sys:   3.528s =  265.567s
> with 2.6.17 kernel smp/hyperthreading pentium-pro as CPU
> BENCHMARKs: VC: 245.175s VO:   0.050s A:   0.000s Sys:   2.479s =  247.704s
> with 2.6.17 kernel smp/hyperthreading pentium4 optimized kernel
> BENCHMARKs: VC: 227.992s VO:   0.051s A:   0.000s Sys:   2.551s =  230.594s
I'm not familiar with mplayer benchmarks, what do they actually
measure?

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

Re: Hyperthreading performance oddities

[Frederik Deweerdt]

Hello Henk,

On Fri, Feb 22, 2008 at 10:36:01AM +0100, belcampo wrote:
 Kernel 2.6.22.9 smp hyperthreading
 BENCHMARKs: VC: 334.042s VO:   0.053s A:   0.000s Sys:   4.049s =  338.143s
 Kernel 2.6.22.9 nonsmp/hyperthreading
 BENCHMARKs: VC: 262.008s VO:   0.031s A:   0.000s Sys:   3.528s =  265.567s
 with 2.6.17 kernel smp/hyperthreading pentium-pro as CPU
 BENCHMARKs: VC: 245.175s VO:   0.050s A:   0.000s Sys:   2.479s =  247.704s
 with 2.6.17 kernel smp/hyperthreading pentium4 optimized kernel
 BENCHMARKs: VC: 227.992s VO:   0.051s A:   0.000s Sys:   2.551s =  230.594s
I'm not familiar with mplayer benchmarks, what do they actually
measure?

Regards,
Frederik
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] rfcomm

[Frederik Deweerdt]

Hello Alon,

On Mon, Feb 11, 2008 at 05:57:54PM +0200, Alon Bar-Lev wrote:
[...]
> Feb 11 17:46:05 alon1 BUG: unable to handle kernel NULL pointer dereference 
> at virtual address 0008
> Feb 11 17:46:05 alon1 printing eip: c01b2da6 *pde =  
> Feb 11 17:46:05 alon1 Oops:  [#1] PREEMPT 
> Feb 11 17:46:05 alon1 Modules linked in: aes_generic crypto_algapi 
> ieee80211_crypt_ccmp ppp_deflate zlib_deflate zlib_inflate bsd_comp ppp_async 
> thinkpad_acpi hwmon nvram vmnet(P) vmmon(P) tun radeon drm autofs4 ipv6 
> nf_nat_irc nf_nat_ftp nf_conntrack_irc nf_conntrack_ftp ipt_MASQUERADE 
> iptable_nat nf_nat ipt_REJECT xt_tcpudp ipt_LOG xt_limit xt_state 
> nf_conntrack_ipv4 nf_conntrack iptable_filter ip_tables x_tables rfcomm l2cap 
> snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event 
> snd_seq snd_seq_device ppp_generic slhc ioatdma dca cfq_iosched 
> cpufreq_powersave cpufreq_ondemand cpufreq_conservative acpi_cpufreq 
> freq_table uinput fan af_packet nls_cp1255 nls_iso8859_1 nls_utf8 nls_base 
> hci_usb bluetooth pcmcia snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm ipw2200 
> nsc_ircc snd_timer irda ieee80211 snd psmouse yenta_socket ehci_hcd pcspkr 
> ieee80211_crypt e1000 rsrc_nonstatic uhci_hcd soundcore i2c_i801 intel_agp 
> crc_ccitt thermal sr_mod pcmcia_core snd_page_alloc battery rtc 
> firmware_class agpgart ac processor cdrom sg button unix usbcore evdev ext3 
> jbd ext2 mbcache loop ata_piix libata sd_mod scsi_mod
> Feb 11 17:46:05 alon1 
> Feb 11 17:46:05 alon1 Pid: 4, comm: events/0 Tainted: P
> (2.6.24-gentoo-r1 #1)
> Feb 11 17:46:05 alon1 EIP: 0060:[] EFLAGS: 00010286 CPU: 0
> Feb 11 17:46:05 alon1 EIP is at sysfs_get_dentry+0x26/0x80
> Feb 11 17:46:05 alon1 EAX:  EBX:  ECX:  EDX: ebf21000
> Feb 11 17:46:05 alon1 ESI: eab4e880 EDI: f713bb40 EBP: f713bb40 ESP: f7c49f00
> Feb 11 17:46:05 alon1 DS: 007b ES: 007b FS:  GS:  SS: 0068
> Feb 11 17:46:05 alon1 Process events/0 (pid: 4, ti=f7c48000 task=f7c3efc0 
> task.ti=f7c48000)
> Feb 11 17:46:05 alon1 Stack: f7c97120 f7135a68 f7e71e10 c01b303d  
>  fffe c030ba9c 
> Feb 11 17:46:05 alon1 f7c97120 f7135a68 f2fefb40 f7c97120 f7135a68 f2fefb40 
> c030ba8e c01ce1fb 
> Feb 11 17:46:05 alon1 f75f1b00 c030ba8e f2fefb40 f75f1b00 f75f1b00  
> f7135a00  
> Feb 11 17:46:05 alon1 Call Trace:
> Feb 11 17:46:05 alon1 [] sysfs_move_dir+0x3d/0x1f0
> Feb 11 17:46:05 alon1 [] kobject_move+0x9b/0x120
> Feb 11 17:46:05 alon1 [] device_move+0x51/0x110
> Feb 11 17:46:05 alon1 [] del_conn+0x0/0x40 [bluetooth]
> Feb 11 17:46:05 alon1 [] del_conn+0x10/0x40 [bluetooth]
> Feb 11 17:46:05 alon1 [] run_workqueue+0x81/0x140
> Feb 11 17:46:05 alon1 [] schedule+0x168/0x2e0
> Feb 11 17:46:05 alon1 [] autoremove_wake_function+0x0/0x50
> Feb 11 17:46:05 alon1 [] worker_thread+0x9b/0xf0
> Feb 11 17:46:05 alon1 [] autoremove_wake_function+0x0/0x50
> Feb 11 17:46:05 alon1 [] worker_thread+0x0/0xf0
> Feb 11 17:46:05 alon1 [] kthread+0x42/0x70
> Feb 11 17:46:05 alon1 [] kthread+0x0/0x70
> Feb 11 17:46:05 alon1 [] kernel_thread_helper+0x7/0x18
> Feb 11 17:46:05 alon1 ===
> Feb 11 17:46:05 alon1 Code: 26 00 00 00 00 57 89 c7 a1 50 1b 3a c0 56 53 8b 
> 70 38 85 f6 74 08 8b 0e 85 c9 74 58 ff 06 8b 56 50 39 fa 74 47 89 fb eb 02 89 
> c3 <8b> 43 08 39 c2 75 f7 8b 46 08 83 c0 68 e8 98 e7 10 00 8b 43 10 
> Feb 11 17:46:05 alon1 EIP: [] sysfs_get_dentry+0x26/0x80 SS:ESP 
> 0068:f7c49f00

If your compiler doesn't produce a code too different from mine, it
looks like cur in sysfs_get_dentry()...

while (cur->s_parent != dentry->d_fsdata)
cur = cur->s_parent;

... got NULL and dereferenced. Could you try the following (merely
tested by booting) patch? While not a fix, it could help pointing to
the right direction.

Regards,
Frederik


diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 4948d9b..90cdf0d 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -106,8 +106,11 @@ struct dentry *sysfs_get_dentry(struct sysfs_dirent *sd)
 
/* find the first ancestor which hasn't been looked up */
cur = sd;
-   while (cur->s_parent != dentry->d_fsdata)
+   while (cur->s_parent != dentry->d_fsdata) {
cur = cur->s_parent;
+   if (!cur)
+   return ERR_PTR(-ENOENT);
+   }
 
/* look it up */
parent = dentry;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] rfcomm

[Frederik Deweerdt]

Hello Alon,

On Mon, Feb 11, 2008 at 05:57:54PM +0200, Alon Bar-Lev wrote:
[...]
 Feb 11 17:46:05 alon1 BUG: unable to handle kernel NULL pointer dereference 
 at virtual address 0008
 Feb 11 17:46:05 alon1 printing eip: c01b2da6 *pde =  
 Feb 11 17:46:05 alon1 Oops:  [#1] PREEMPT 
 Feb 11 17:46:05 alon1 Modules linked in: aes_generic crypto_algapi 
 ieee80211_crypt_ccmp ppp_deflate zlib_deflate zlib_inflate bsd_comp ppp_async 
 thinkpad_acpi hwmon nvram vmnet(P) vmmon(P) tun radeon drm autofs4 ipv6 
 nf_nat_irc nf_nat_ftp nf_conntrack_irc nf_conntrack_ftp ipt_MASQUERADE 
 iptable_nat nf_nat ipt_REJECT xt_tcpudp ipt_LOG xt_limit xt_state 
 nf_conntrack_ipv4 nf_conntrack iptable_filter ip_tables x_tables rfcomm l2cap 
 snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event 
 snd_seq snd_seq_device ppp_generic slhc ioatdma dca cfq_iosched 
 cpufreq_powersave cpufreq_ondemand cpufreq_conservative acpi_cpufreq 
 freq_table uinput fan af_packet nls_cp1255 nls_iso8859_1 nls_utf8 nls_base 
 hci_usb bluetooth pcmcia snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm ipw2200 
 nsc_ircc snd_timer irda ieee80211 snd psmouse yenta_socket ehci_hcd pcspkr 
 ieee80211_crypt e1000 rsrc_nonstatic uhci_hcd soundcore i2c_i801 intel_agp 
 crc_ccitt thermal sr_mod pcmcia_core snd_page_alloc battery rtc 
 firmware_class agpgart ac processor cdrom sg button unix usbcore evdev ext3 
 jbd ext2 mbcache loop ata_piix libata sd_mod scsi_mod
 Feb 11 17:46:05 alon1 
 Feb 11 17:46:05 alon1 Pid: 4, comm: events/0 Tainted: P
 (2.6.24-gentoo-r1 #1)
 Feb 11 17:46:05 alon1 EIP: 0060:[c01b2da6] EFLAGS: 00010286 CPU: 0
 Feb 11 17:46:05 alon1 EIP is at sysfs_get_dentry+0x26/0x80
 Feb 11 17:46:05 alon1 EAX:  EBX:  ECX:  EDX: ebf21000
 Feb 11 17:46:05 alon1 ESI: eab4e880 EDI: f713bb40 EBP: f713bb40 ESP: f7c49f00
 Feb 11 17:46:05 alon1 DS: 007b ES: 007b FS:  GS:  SS: 0068
 Feb 11 17:46:05 alon1 Process events/0 (pid: 4, ti=f7c48000 task=f7c3efc0 
 task.ti=f7c48000)
 Feb 11 17:46:05 alon1 Stack: f7c97120 f7135a68 f7e71e10 c01b303d  
  fffe c030ba9c 
 Feb 11 17:46:05 alon1 f7c97120 f7135a68 f2fefb40 f7c97120 f7135a68 f2fefb40 
 c030ba8e c01ce1fb 
 Feb 11 17:46:05 alon1 f75f1b00 c030ba8e f2fefb40 f75f1b00 f75f1b00  
 f7135a00  
 Feb 11 17:46:05 alon1 Call Trace:
 Feb 11 17:46:05 alon1 [c01b303d] sysfs_move_dir+0x3d/0x1f0
 Feb 11 17:46:05 alon1 [c01ce1fb] kobject_move+0x9b/0x120
 Feb 11 17:46:05 alon1 [c0241701] device_move+0x51/0x110
 Feb 11 17:46:05 alon1 [f9a8adb0] del_conn+0x0/0x40 [bluetooth]
 Feb 11 17:46:05 alon1 [f9a8adc0] del_conn+0x10/0x40 [bluetooth]
 Feb 11 17:46:05 alon1 [c012c1a1] run_workqueue+0x81/0x140
 Feb 11 17:46:05 alon1 [c02c0c78] schedule+0x168/0x2e0
 Feb 11 17:46:05 alon1 [c012fc70] autoremove_wake_function+0x0/0x50
 Feb 11 17:46:05 alon1 [c012c9cb] worker_thread+0x9b/0xf0
 Feb 11 17:46:05 alon1 [c012fc70] autoremove_wake_function+0x0/0x50
 Feb 11 17:46:05 alon1 [c012c930] worker_thread+0x0/0xf0
 Feb 11 17:46:05 alon1 [c012f962] kthread+0x42/0x70
 Feb 11 17:46:05 alon1 [c012f920] kthread+0x0/0x70
 Feb 11 17:46:05 alon1 [c0104c2f] kernel_thread_helper+0x7/0x18
 Feb 11 17:46:05 alon1 ===
 Feb 11 17:46:05 alon1 Code: 26 00 00 00 00 57 89 c7 a1 50 1b 3a c0 56 53 8b 
 70 38 85 f6 74 08 8b 0e 85 c9 74 58 ff 06 8b 56 50 39 fa 74 47 89 fb eb 02 89 
 c3 8b 43 08 39 c2 75 f7 8b 46 08 83 c0 68 e8 98 e7 10 00 8b 43 10 
 Feb 11 17:46:05 alon1 EIP: [c01b2da6] sysfs_get_dentry+0x26/0x80 SS:ESP 
 0068:f7c49f00

If your compiler doesn't produce a code too different from mine, it
looks like cur in sysfs_get_dentry()...

while (cur-s_parent != dentry-d_fsdata)
cur = cur-s_parent;

... got NULL and dereferenced. Could you try the following (merely
tested by booting) patch? While not a fix, it could help pointing to
the right direction.

Regards,
Frederik


diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 4948d9b..90cdf0d 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -106,8 +106,11 @@ struct dentry *sysfs_get_dentry(struct sysfs_dirent *sd)
 
/* find the first ancestor which hasn't been looked up */
cur = sd;
-   while (cur-s_parent != dentry-d_fsdata)
+   while (cur-s_parent != dentry-d_fsdata) {
cur = cur-s_parent;
+   if (!cur)
+   return ERR_PTR(-ENOENT);
+   }
 
/* look it up */
parent = dentry;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch] crypto test build failure

[Frederik Deweerdt]

Hello Herbert,

Building latest git fails with the following error:
ERROR: "crypto_alloc_ablkcipher" [crypto/tcrypt.ko] undefined!
This appears to happen because CONFIG_CRYPTO_TEST is set while
CONFIG_CRYPTO_BLKCIPHER is not.
The following patch fixes the problem for me.

Regards,
Frederik

Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>

diff --git a/crypto/Kconfig b/crypto/Kconfig
index c3166a1..d0287ce 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -567,6 +567,7 @@ config CRYPTO_TEST
depends on m
select CRYPTO_ALGAPI
select CRYPTO_AEAD
+   select CRYPTO_BLKCIPHER
help
  Quick & dirty crypto test module.
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch] crypto test build failure

[Frederik Deweerdt]

Hello Herbert,

Building latest git fails with the following error:
ERROR: crypto_alloc_ablkcipher [crypto/tcrypt.ko] undefined!
This appears to happen because CONFIG_CRYPTO_TEST is set while
CONFIG_CRYPTO_BLKCIPHER is not.
The following patch fixes the problem for me.

Regards,
Frederik

Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]

diff --git a/crypto/Kconfig b/crypto/Kconfig
index c3166a1..d0287ce 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -567,6 +567,7 @@ config CRYPTO_TEST
depends on m
select CRYPTO_ALGAPI
select CRYPTO_AEAD
+   select CRYPTO_BLKCIPHER
help
  Quick  dirty crypto test module.
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[trivial patch] scsi/ultrastor: clean up inline asm warnings

[Frederik Deweerdt]

Hi,

Compiling latest mainline with gcc 4.2.1 spews the following warnings:

drivers/scsi/ultrastor.c: In function 'find_and_clear_bit_16':
drivers/scsi/ultrastor.c:303: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c:302: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c: At top level:
drivers/scsi/ultrastor.c:1202: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c:1202: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c: In function 'ultrastor_queuecommand':
drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c:302: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c:302: warning: matching constraint does not allow a 
register

The following patch fixes it by using the '+' operator on the (*field)
operand, marking it as read-write to gcc. I diffed the two resulting .s,
and gcc produced the same code. This was tested with gcc 4.2.1 and gcc 3.4.3

$ diff -u drivers/scsi/ultrastor.s{_,}
--- drivers/scsi/ultrastor.s_   2008-01-16 16:40:01.0 +0100
+++ drivers/scsi/ultrastor.s2008-01-16 16:40:19.0 +0100
@@ -1457,7 +1457,7 @@
je  .L268   #,
 #APP
xorl %ebp,%ebp  # mscp_index
-0: bsfw config+20,%bp  # config.mscp_free, mscp_index
+   0: bsfw config+20,%bp   # config.mscp_free, mscp_index
btr %ebp,config+20  # mscp_index, config.mscp_free
jnc 0b
 #NO_APP
@@ -1726,9 +1726,9 @@
callpanic   #
.size   ultrastor_queuecommand, .-ultrastor_queuecommand
.section.modinfo,"a",@progbits
-   .type   __mod_license1184, @object
-   .size   __mod_license1184, 12
-__mod_license1184:
+   .type   __mod_license1191, @object
+   .size   __mod_license1191, 12
+__mod_license1191:
.string "license=GPL"
.section.rodata.str1.1
 .LC27:


Regards,
Frederik

Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>

diff --git a/drivers/scsi/ultrastor.c b/drivers/scsi/ultrastor.c
index 6d1f0ed..93c5a67 100644
--- a/drivers/scsi/ultrastor.c
+++ b/drivers/scsi/ultrastor.c
@@ -298,9 +298,16 @@ static inline int find_and_clear_bit_16(unsigned long 
*field)
 {
   int rv;
 
-  if (*field == 0) panic("No free mscp");
-  asm("xorl %0,%0\n0:\tbsfw %1,%w0\n\tbtr %0,%1\n\tjnc 0b"
-  : "=" (rv), "=m" (*field) : "1" (*field));
+  if (*field == 0)
+panic("No free mscp");
+
+  asm volatile (
+   "xorl %0,%0\n\t"
+   "0: bsfw %1,%w0\n\t"
+   "btr %0,%1\n\t"
+   "jnc 0b"
+   : "=" (rv), "=m" (*field) :);
+
   return rv;
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[trivial patch] scsi/ultrastor: clean up inline asm warnings

[Frederik Deweerdt]

Hi,

Compiling latest mainline with gcc 4.2.1 spews the following warnings:

drivers/scsi/ultrastor.c: In function 'find_and_clear_bit_16':
drivers/scsi/ultrastor.c:303: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c:302: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c: At top level:
drivers/scsi/ultrastor.c:1202: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c:1202: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c: In function 'ultrastor_queuecommand':
drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c:302: warning: matching constraint does not allow a 
register
drivers/scsi/ultrastor.c:302: warning: matching constraint does not allow a 
register

The following patch fixes it by using the '+' operator on the (*field)
operand, marking it as read-write to gcc. I diffed the two resulting .s,
and gcc produced the same code. This was tested with gcc 4.2.1 and gcc 3.4.3

$ diff -u drivers/scsi/ultrastor.s{_,}
--- drivers/scsi/ultrastor.s_   2008-01-16 16:40:01.0 +0100
+++ drivers/scsi/ultrastor.s2008-01-16 16:40:19.0 +0100
@@ -1457,7 +1457,7 @@
je  .L268   #,
 #APP
xorl %ebp,%ebp  # mscp_index
-0: bsfw config+20,%bp  # config.mscp_free, mscp_index
+   0: bsfw config+20,%bp   # config.mscp_free, mscp_index
btr %ebp,config+20  # mscp_index, config.mscp_free
jnc 0b
 #NO_APP
@@ -1726,9 +1726,9 @@
callpanic   #
.size   ultrastor_queuecommand, .-ultrastor_queuecommand
.section.modinfo,a,@progbits
-   .type   __mod_license1184, @object
-   .size   __mod_license1184, 12
-__mod_license1184:
+   .type   __mod_license1191, @object
+   .size   __mod_license1191, 12
+__mod_license1191:
.string license=GPL
.section.rodata.str1.1
 .LC27:


Regards,
Frederik

Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]

diff --git a/drivers/scsi/ultrastor.c b/drivers/scsi/ultrastor.c
index 6d1f0ed..93c5a67 100644
--- a/drivers/scsi/ultrastor.c
+++ b/drivers/scsi/ultrastor.c
@@ -298,9 +298,16 @@ static inline int find_and_clear_bit_16(unsigned long 
*field)
 {
   int rv;
 
-  if (*field == 0) panic(No free mscp);
-  asm(xorl %0,%0\n0:\tbsfw %1,%w0\n\tbtr %0,%1\n\tjnc 0b
-  : =r (rv), =m (*field) : 1 (*field));
+  if (*field == 0)
+panic(No free mscp);
+
+  asm volatile (
+   xorl %0,%0\n\t
+   0: bsfw %1,%w0\n\t
+   btr %0,%1\n\t
+   jnc 0b
+   : =r (rv), =m (*field) :);
+
   return rv;
 }
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: strace, accept(), ERESTARTSYS and EINTR

[Frederik Deweerdt]

On Fri, Jan 04, 2008 at 09:01:38PM +, Phil Endecott wrote:
> Dear Experts,
> 
> I have some code like this:
> 
> struct sockaddr_in client_addr;
> socklen_t client_size=sizeof(client_addr);
> int connfd = accept(fd,(struct sockaddr*)(_addr),_size);
> if (connfd==-1) {
>   // [1]
>   .report error and terminate..
Replacing the (connfd == -1) check with (connfd < 0),
could you try printf'ing connfd and errno here?
Just to confirm strace's output.
> }
> int rc = fcntl(connfd,F_SETFD,FD_CLOEXEC);
> 
Regards,
Frederik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: strace, accept(), ERESTARTSYS and EINTR

[Frederik Deweerdt]

On Fri, Jan 04, 2008 at 09:01:38PM +, Phil Endecott wrote:
 Dear Experts,
 
 I have some code like this:
 
 struct sockaddr_in client_addr;
 socklen_t client_size=sizeof(client_addr);
 int connfd = accept(fd,(struct sockaddr*)(client_addr),client_size);
 if (connfd==-1) {
   // [1]
   .report error and terminate..
Replacing the (connfd == -1) check with (connfd  0),
could you try printf'ing connfd and errno here?
Just to confirm strace's output.
 }
 int rc = fcntl(connfd,F_SETFD,FD_CLOEXEC);
 
Regards,
Frederik
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv2 2/4] x86 support for sys_indirect

[Frederik Deweerdt]

Hello Ulrich,
On Thu, Nov 15, 2007 at 01:22:31PM -0500, Ulrich Drepper wrote:
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index ee800e7..e4e8a22 100644
> --- /dev/null 2007-09-23 16:36:38.465394704 -0700
> +++ b/include/asm-x86/indirect_32.h   2007-11-15 09:52:47.0 -0800
[...]
> +#define INDIRECT_SYSCALL(regs) (regs)->eax 
^
> +
> +#define CALL_INDIRECT(regs) \
> +  ({ extern long (*sys_call_table[]) (__u32, __u32, __u32, __u32, __u32, 
> __u32); \
> + sys_call_table[INDIRECT_SYSCALL(regs)->eax] ((regs)->ebx, (regs)->ecx, \
 ^-> I take it that ->eax is 
wrong here? 
> +   (regs)->edx, (regs)->esi, \
> +   (regs)->edi, (regs)->ebp); \
> + })
> +
> +#endif

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

Re: [PATCHv2 2/4] x86x86-64 support for sys_indirect

[Frederik Deweerdt]

Hello Ulrich,
On Thu, Nov 15, 2007 at 01:22:31PM -0500, Ulrich Drepper wrote:
 diff --git a/include/linux/sched.h b/include/linux/sched.h
 index ee800e7..e4e8a22 100644
 --- /dev/null 2007-09-23 16:36:38.465394704 -0700
 +++ b/include/asm-x86/indirect_32.h   2007-11-15 09:52:47.0 -0800
[...]
 +#define INDIRECT_SYSCALL(regs) (regs)-eax 
^
 +
 +#define CALL_INDIRECT(regs) \
 +  ({ extern long (*sys_call_table[]) (__u32, __u32, __u32, __u32, __u32, 
 __u32); \
 + sys_call_table[INDIRECT_SYSCALL(regs)-eax] ((regs)-ebx, (regs)-ecx, \
 ^- I take it that -eax is 
wrong here? 
 +   (regs)-edx, (regs)-esi, \
 +   (regs)-edi, (regs)-ebp); \
 + })
 +
 +#endif

Regards,
Frederik
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] fix getblk_slow "integer constant is too large" warning

[Frederik Deweerdt]

On Tue, Nov 06, 2007 at 02:33:53AM -0800, [EMAIL PROTECTED] wrote:
> The mm snapshot broken-out-2007-11-06-02-32.tar.gz has been uploaded to
> 
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-11-06-02-32.tar.gz
> 
> It contains the following patches against 2.6.24-rc1:
> 
[...]
> getblk-handle-2tb-devices.patch
[...]
0x is unsigned long long on 32 bits
fs/buffer.c: In function '__getblk_slow':
fs/buffer.c:1126: warning: integer constant is too large for 'unsigned long' 
type

Regards,
Frederik

Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>


diff --git a/fs/buffer.c b/fs/buffer.c
index ca713df..795fe86 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1123,7 +1123,7 @@ __getblk_slow(struct block_device *bdev, sector_t block, 
int size)
 
 #if (BITS_PER_LONG == 32) && defined(CONFIG_LBD)
if ((block >> (PAGE_CACHE_SHIFT - bdev->bd_inode->i_blkbits)) &
-   0xUL) {
+   0xULL) {
/*
 * We'll fail because the block is outside the range
 * which a 32-bit pagecache index can address
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] fix getblk_slow integer constant is too large warning

[Frederik Deweerdt]

On Tue, Nov 06, 2007 at 02:33:53AM -0800, [EMAIL PROTECTED] wrote:
 The mm snapshot broken-out-2007-11-06-02-32.tar.gz has been uploaded to
 

 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-11-06-02-32.tar.gz
 
 It contains the following patches against 2.6.24-rc1:
 
[...]
 getblk-handle-2tb-devices.patch
[...]
0x is unsigned long long on 32 bits
fs/buffer.c: In function '__getblk_slow':
fs/buffer.c:1126: warning: integer constant is too large for 'unsigned long' 
type

Regards,
Frederik

Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]


diff --git a/fs/buffer.c b/fs/buffer.c
index ca713df..795fe86 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1123,7 +1123,7 @@ __getblk_slow(struct block_device *bdev, sector_t block, 
int size)
 
 #if (BITS_PER_LONG == 32)  defined(CONFIG_LBD)
if ((block  (PAGE_CACHE_SHIFT - bdev-bd_inode-i_blkbits)) 
-   0xUL) {
+   0xULL) {
/*
 * We'll fail because the block is outside the range
 * which a 32-bit pagecache index can address
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel NULL pointer dereference in check_spread+0x0/0x26

[Frederik Deweerdt]

On Fri, Oct 12, 2007 at 05:31:32PM +0200, Jan Blunck wrote:
> On Fri, Oct 12, Frederik Deweerdt wrote:
> 
> > On Fri, Oct 12, 2007 at 02:40:54PM +0200, Jan Blunck wrote:
> > > This is with 2.6.23-mm1 and allmodconfig.
> > This generates a .config with CONFIG_SCHED_DEBUG=y and
> > CONFIG_FAIR_GROUP_SCHED=n (The latter causes parent_entity to return
> > NULL).
> > Does setting CONFIG_FAIR_GROUP_SCHED=y help?
> 
> No, CONFIG_FAIR_GROUP_SCHED=y was set. Or did you mean 
> CONFIG_FAIR_CGROUP_SCHED?
He no, I misread the code, sorry for the noise.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel NULL pointer dereference in check_spread+0x0/0x26

[Frederik Deweerdt]

On Fri, Oct 12, 2007 at 02:40:54PM +0200, Jan Blunck wrote:
> This is with 2.6.23-mm1 and allmodconfig.
This generates a .config with CONFIG_SCHED_DEBUG=y and
CONFIG_FAIR_GROUP_SCHED=n (The latter causes parent_entity to return
NULL).
Does setting CONFIG_FAIR_GROUP_SCHED=y help?

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

Re: kernel NULL pointer dereference in check_spread+0x0/0x26

[Frederik Deweerdt]

On Fri, Oct 12, 2007 at 05:31:32PM +0200, Jan Blunck wrote:
 On Fri, Oct 12, Frederik Deweerdt wrote:
 
  On Fri, Oct 12, 2007 at 02:40:54PM +0200, Jan Blunck wrote:
   This is with 2.6.23-mm1 and allmodconfig.
  This generates a .config with CONFIG_SCHED_DEBUG=y and
  CONFIG_FAIR_GROUP_SCHED=n (The latter causes parent_entity to return
  NULL).
  Does setting CONFIG_FAIR_GROUP_SCHED=y help?
 
 No, CONFIG_FAIR_GROUP_SCHED=y was set. Or did you mean 
 CONFIG_FAIR_CGROUP_SCHED?
He no, I misread the code, sorry for the noise.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel NULL pointer dereference in check_spread+0x0/0x26

[Frederik Deweerdt]

On Fri, Oct 12, 2007 at 02:40:54PM +0200, Jan Blunck wrote:
 This is with 2.6.23-mm1 and allmodconfig.
This generates a .config with CONFIG_SCHED_DEBUG=y and
CONFIG_FAIR_GROUP_SCHED=n (The latter causes parent_entity to return
NULL).
Does setting CONFIG_FAIR_GROUP_SCHED=y help?

Regards,
Frederik
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix lguest page-pinning logic ("lguest: bad stack page 0xc057a000")

[Frederik Deweerdt]

On Tue, Aug 28, 2007 at 02:09:59AM +1000, Rusty Russell wrote:
> If the stack pointer is 0xc057a000, then the first stack page is at
> 0xc0579000 (the stack pointer is decremented before use).  Not
> calculating this correctly caused guests with CONFIG_DEBUG_PAGEALLOC=y
> to be killed with a "bad stack page" message: the initial kernel stack
> was just preceeding the .smp_locks section which
> CONFIG_DEBUG_PAGEALLOC marks read-only when freeing.
> 
Hello Rusty,

I just could try the patch, sorry for the delay. Albeit it allows to
progress a little further in the boot process, lguest seems to like that
"section that was just freed" :)

Please note that:
- It could progress to "Freeing SMP alternatives: 13k freed", which is new.
  Indeed, your patch made the Host to pin 0xc04d3000, which is the
  good page.
- 0xc04d4000 is the __smp_locks section:
 $ objdump -h vmlinux
 [...]
 20 .data.init_task 1000  c04d3000  004d3000  003d4000  2**2
  CONTENTS, ALLOC, LOAD, DATA
 21 .smp_locks36c8  c04d4000  004d4000  003d5000  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
 [...]

[0.128503] SMP alternatives: switching to UP code
[0.132846] Freeing SMP alternatives: 13k freed
[0.135177] BUG: unable to handle kernel paging request at virtual address 
c04d4000
[0.135417]  printing eip:
[0.135505] c01051df
[0.135564] *pde = 5067
[0.135645] *pte = 004d4000
[0.135756] Oops:  [#1]
[0.135825] PREEMPT SMP DEBUG_PAGEALLOC
[0.136039] Modules linked in:
[0.136205] CPU:0
[0.136206] EIP:0061:[]Not tainted VLI
[0.136207] EFLAGS: 00010097   (2.6.23-rc3 #5)
[0.136665] EIP is at dump_trace+0x5f/0x97
[0.136738] eax: c0614954   ebx: c04d3ffc   ecx: c0497b00   edx: c04ef641
[0.136883] esi: c04d3000   edi: c04d3ffd   ebp: c04d3da0   esp: c04d3d90
[0.137058] ds: 0069   es: 0069   fs: 00d8  gs:   ss: 0069
[0.137235] Process swapper (pid: 0, ti=c04d3000 task=c04953e0 
task.ti=c04d3000)
[0.137447] Stack: c0109d95 c0614954 c04953e0  c04d3db4 c010a1f1 
c0497b00 c0614954
[0.137831]c0614954 c04d3dc4 c0140921 c0144252 c04959c8 c04d3dec 
c014272f c02eccf5
[0.138119]c04959c8 c0614938 c04d3dec 0001 c04959c8 c0614938 
c04953e0 c04d3e4c
[0.138497] Call Trace:
[0.138603]  [] show_trace_log_lvl+0x1a/0x2f
[0.138798]  [] show_stack_log_lvl+0x9b/0xa3
[0.138942]  [] show_registers+0x1d8/0x30d
[0.139120]  [] die+0x127/0x20a
[0.139272]  [] do_page_fault+0x512/0x5e6
[0.139470]  [] error_code+0x72/0x78
[0.139678]  [] save_stack_trace+0x23/0x3e
[0.139869]  [] save_trace+0x3a/0x8e
[0.140049]  [] mark_lock+0x7b/0x471
[0.140223]  [] __lock_acquire+0x51a/0xc99
[0.140374]  [] lock_acquire+0x91/0xb5
[0.140546]  [] _spin_lock_irq+0x47/0x71
[0.140693]  [] alloc_pid+0x1ce/0x22f
[0.140867]  [] do_fork+0x15/0x1bf
[0.141011]  [] kernel_thread+0x88/0x90
[0.141170]  [] rest_init+0x14/0x63
[0.141345]  [] start_kernel+0x317/0x31f
[0.141565]  [] lguest_init+0x2af/0x2d5
[0.141736] BUG: unable to handle kernel paging request at virtual address 
c04d4000
[0.142195]  printing eip:
[0.142259] c01051df
[0.142335] *pde = 5067
[0.142418] *pte = 004d4000
[0.142501] Oops:  [#2]
[0.142581] PREEMPT SMP DEBUG_PAGEALLOC
[0.142775] Modules linked in:
[0.142929] CPU:0
[0.142930] EIP:0061:[]Not tainted VLI
[0.142931] EFLAGS: 00010097   (2.6.23-rc3 #5)
[0.143296] EIP is at dump_trace+0x5f/0x97
[0.143409] eax: c0430e58   ebx: c04d3ffc   ecx: c0497058   edx: 
[0.143611] esi: c04d3000   edi: c04d3ffd   ebp: c04d3c1c   esp: c04d3c0c
[0.143800] ds: 007b   es: 007b   fs: 00d8  gs:   ss: 0069
[0.143988] Process swapper (pid: 0, ti=c04d3000 task=c04953e0 
task.ti=c04d3000)
[0.144213] Stack: 34373331 c0430e58 0018  c04d3c30 c0105231 
c0497058 c0430e58
[0.144634]c04d3df3 c04d3c54 c01052e1 c0430e58 c0430e58 c04d3d58 
c04d3d90 
[0.145055]002b c04d3d58 c04d3cc0 c01054c1 c0430e58 0010 
c0495614 
[0.145439] Call Trace:
[0.145511]  [] show_trace_log_lvl+0x1a/0x2f
[0.145607]  [] show_stack_log_lvl+0x9b/0xa3
[0.145723]  [] show_registers+0x1d8/0x30d
[0.145849]  [] die+0x127/0x20a
[0.145980]  [] do_page_fault+0x512/0x5e6
[0.146125]  [] error_code+0x72/0x78
[0.146281]  [] show_trace_log_lvl+0x1a/0x2f
[0.146423]  [] show_stack_log_lvl+0x9b/0xa3
[0.146587]  [] show_registers+0x1d8/0x30d
[0.146746]  [] die+0x127/0x20a
[0.146895]  [] do_page_fault+0x512/0x5e6
[0.147061]  [] error_code+0x72/0x78
[0.147213]  [] save_stack_trace+0x23/0x3e
[0.147361]  [] save_trace+0x3a/0x8e
[0.147531]  [] mark_lock+0x7b/0x471
[0.147681]  [] __lock_acquire+0x51a/0xc99
[0.147839]  [] lock_acquire+0x91/0xb5
[0.147987]  [] _spin_lock_irq+0x47/0x71
[0.148136]  [] 

Re: [PATCH] Fix lguest page-pinning logic (lguest: bad stack page 0xc057a000)

[Frederik Deweerdt]

On Tue, Aug 28, 2007 at 02:09:59AM +1000, Rusty Russell wrote:
 If the stack pointer is 0xc057a000, then the first stack page is at
 0xc0579000 (the stack pointer is decremented before use).  Not
 calculating this correctly caused guests with CONFIG_DEBUG_PAGEALLOC=y
 to be killed with a bad stack page message: the initial kernel stack
 was just preceeding the .smp_locks section which
 CONFIG_DEBUG_PAGEALLOC marks read-only when freeing.
 
Hello Rusty,

I just could try the patch, sorry for the delay. Albeit it allows to
progress a little further in the boot process, lguest seems to like that
section that was just freed :)

Please note that:
- It could progress to Freeing SMP alternatives: 13k freed, which is new.
  Indeed, your patch made the Host to pin 0xc04d3000, which is the
  good page.
- 0xc04d4000 is the __smp_locks section:
 $ objdump -h vmlinux
 [...]
 20 .data.init_task 1000  c04d3000  004d3000  003d4000  2**2
  CONTENTS, ALLOC, LOAD, DATA
 21 .smp_locks36c8  c04d4000  004d4000  003d5000  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
 [...]

[0.128503] SMP alternatives: switching to UP code
[0.132846] Freeing SMP alternatives: 13k freed
[0.135177] BUG: unable to handle kernel paging request at virtual address 
c04d4000
[0.135417]  printing eip:
[0.135505] c01051df
[0.135564] *pde = 5067
[0.135645] *pte = 004d4000
[0.135756] Oops:  [#1]
[0.135825] PREEMPT SMP DEBUG_PAGEALLOC
[0.136039] Modules linked in:
[0.136205] CPU:0
[0.136206] EIP:0061:[c01051df]Not tainted VLI
[0.136207] EFLAGS: 00010097   (2.6.23-rc3 #5)
[0.136665] EIP is at dump_trace+0x5f/0x97
[0.136738] eax: c0614954   ebx: c04d3ffc   ecx: c0497b00   edx: c04ef641
[0.136883] esi: c04d3000   edi: c04d3ffd   ebp: c04d3da0   esp: c04d3d90
[0.137058] ds: 0069   es: 0069   fs: 00d8  gs:   ss: 0069
[0.137235] Process swapper (pid: 0, ti=c04d3000 task=c04953e0 
task.ti=c04d3000)
[0.137447] Stack: c0109d95 c0614954 c04953e0  c04d3db4 c010a1f1 
c0497b00 c0614954
[0.137831]c0614954 c04d3dc4 c0140921 c0144252 c04959c8 c04d3dec 
c014272f c02eccf5
[0.138119]c04959c8 c0614938 c04d3dec 0001 c04959c8 c0614938 
c04953e0 c04d3e4c
[0.138497] Call Trace:
[0.138603]  [c0105231] show_trace_log_lvl+0x1a/0x2f
[0.138798]  [c01052e1] show_stack_log_lvl+0x9b/0xa3
[0.138942]  [c01054c1] show_registers+0x1d8/0x30d
[0.139120]  [c010571d] die+0x127/0x20a
[0.139272]  [c011c470] do_page_fault+0x512/0x5e6
[0.139470]  [c038ec02] error_code+0x72/0x78
[0.139678]  [c010a1f1] save_stack_trace+0x23/0x3e
[0.139869]  [c0140921] save_trace+0x3a/0x8e
[0.140049]  [c014272f] mark_lock+0x7b/0x471
[0.140223]  [c01436fc] __lock_acquire+0x51a/0xc99
[0.140374]  [c0143f0c] lock_acquire+0x91/0xb5
[0.140546]  [c038e491] _spin_lock_irq+0x47/0x71
[0.140693]  [c01354c9] alloc_pid+0x1ce/0x22f
[0.140867]  [c0125ce5] do_fork+0x15/0x1bf
[0.141011]  [c0102339] kernel_thread+0x88/0x90
[0.141170]  [c038b2b8] rest_init+0x14/0x63
[0.141345]  [c04d895e] start_kernel+0x317/0x31f
[0.141565]  [c04ef641] lguest_init+0x2af/0x2d5
[0.141736] BUG: unable to handle kernel paging request at virtual address 
c04d4000
[0.142195]  printing eip:
[0.142259] c01051df
[0.142335] *pde = 5067
[0.142418] *pte = 004d4000
[0.142501] Oops:  [#2]
[0.142581] PREEMPT SMP DEBUG_PAGEALLOC
[0.142775] Modules linked in:
[0.142929] CPU:0
[0.142930] EIP:0061:[c01051df]Not tainted VLI
[0.142931] EFLAGS: 00010097   (2.6.23-rc3 #5)
[0.143296] EIP is at dump_trace+0x5f/0x97
[0.143409] eax: c0430e58   ebx: c04d3ffc   ecx: c0497058   edx: 
[0.143611] esi: c04d3000   edi: c04d3ffd   ebp: c04d3c1c   esp: c04d3c0c
[0.143800] ds: 007b   es: 007b   fs: 00d8  gs:   ss: 0069
[0.143988] Process swapper (pid: 0, ti=c04d3000 task=c04953e0 
task.ti=c04d3000)
[0.144213] Stack: 34373331 c0430e58 0018  c04d3c30 c0105231 
c0497058 c0430e58
[0.144634]c04d3df3 c04d3c54 c01052e1 c0430e58 c0430e58 c04d3d58 
c04d3d90 
[0.145055]002b c04d3d58 c04d3cc0 c01054c1 c0430e58 0010 
c0495614 
[0.145439] Call Trace:
[0.145511]  [c0105231] show_trace_log_lvl+0x1a/0x2f
[0.145607]  [c01052e1] show_stack_log_lvl+0x9b/0xa3
[0.145723]  [c01054c1] show_registers+0x1d8/0x30d
[0.145849]  [c010571d] die+0x127/0x20a
[0.145980]  [c011c470] do_page_fault+0x512/0x5e6
[0.146125]  [c038ec02] error_code+0x72/0x78
[0.146281]  [c0105231] show_trace_log_lvl+0x1a/0x2f
[0.146423]  [c01052e1] show_stack_log_lvl+0x9b/0xa3
[0.146587]  [c01054c1] show_registers+0x1d8/0x30d
[0.146746]  [c010571d] die+0x127/0x20a
[0.146895]  [c011c470] do_page_fault+0x512/0x5e6
[0.147061]  [c038ec02] error_code+0x72/0x78
[0.147213]  [c010a1f1] 

Re: [-mm patch] enforce noreplace-smp in alternative_instructions()

[Frederik Deweerdt]

On Sat, Aug 25, 2007 at 02:23:24PM +0200, Frederik Deweerdt wrote:
> On Sat, Aug 25, 2007 at 10:07:29PM +1000, Rusty Russell wrote:
> > Do you need noreplace-smp even on 2.6.23-rc3,
> > or only 2.6.23-rc3-mm1?
> I'll try ASAP.
> 
Ok, tested: I need noreplace-smp + patch to make it work on mainline too.

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

Re: [-mm patch] enforce noreplace-smp in alternative_instructions()

[Frederik Deweerdt]

On Sat, Aug 25, 2007 at 10:07:29PM +1000, Rusty Russell wrote:
> On Fri, 2007-08-24 at 10:22 +0200, Frederik Deweerdt wrote:
> > [Added Gerd Hoffman and Rusty Russel to cc]
> > On Thu, Aug 23, 2007 at 11:46:52PM -0700, Jeremy Fitzhardinge wrote:
> > > Frederik Deweerdt wrote:
> > > > That means that even when you specify noreplace_smp, some replacing
> > > > takes place anyway. One of the consequences, besides noreplace_smp not
> > > > working as expected, is that lguest crashes when you feed it an SMP 
> > > > kernel
> > > > (I suspect that you can not replace alternatives for smp _and_ 
> > > > paravirt).
> > > >   
> > > 
> > > No, that should be fine.  Why does lguest crash?
> > It dies with:
> > [0.131000] SMP alternatives: switching to UP code
> > lguest: bad stack page 0xc057a000
Hello Rusty,
> 
> How odd!  This means that the guest set the kernel to a stack which it
> hadn't mapped writable (or perhaps not mapped at all).  I always run SMP

I had time to investigate this a little further, it appears that in fact
0xc057a000 is the beginning of the __smp_locks section.

The crash responsible function call is in alternative_instructions():
free_init_pages("SMP alternatives",
(unsigned long)__smp_locks,
(unsigned long)__smp_locks_end);

Ie, if I comment this out, I can boot lguest without passing
noreplace_smp.

BTW, to make things clear: the patch I sent does _not_ fix the
lguest/alternatives problem. It just makes noreplace_smp functional
again and hence allows working around the lguest/alternatives bug.

> kernels, and that seems a very strange side effect of a patching
> problem...
> 
> Nonetheless, I did have a previous problem with a bug in the patching
> code which didn't show up native and did show up under lguest.
> 
> Can you send your config? 
Here it is:
http://fdeweerdt.free.fr/lguest_smp/dot_config

> Do you need noreplace-smp even on 2.6.23-rc3,
> or only 2.6.23-rc3-mm1?
I'll try ASAP.

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

Re: [-mm patch] enforce noreplace-smp in alternative_instructions()

[Frederik Deweerdt]

On Sat, Aug 25, 2007 at 10:07:29PM +1000, Rusty Russell wrote:
 On Fri, 2007-08-24 at 10:22 +0200, Frederik Deweerdt wrote:
  [Added Gerd Hoffman and Rusty Russel to cc]
  On Thu, Aug 23, 2007 at 11:46:52PM -0700, Jeremy Fitzhardinge wrote:
   Frederik Deweerdt wrote:
That means that even when you specify noreplace_smp, some replacing
takes place anyway. One of the consequences, besides noreplace_smp not
working as expected, is that lguest crashes when you feed it an SMP 
kernel
(I suspect that you can not replace alternatives for smp _and_ 
paravirt).
  
   
   No, that should be fine.  Why does lguest crash?
  It dies with:
  [0.131000] SMP alternatives: switching to UP code
  lguest: bad stack page 0xc057a000
Hello Rusty,
 
 How odd!  This means that the guest set the kernel to a stack which it
 hadn't mapped writable (or perhaps not mapped at all).  I always run SMP

I had time to investigate this a little further, it appears that in fact
0xc057a000 is the beginning of the __smp_locks section.

The crash responsible function call is in alternative_instructions():
free_init_pages(SMP alternatives,
(unsigned long)__smp_locks,
(unsigned long)__smp_locks_end);

Ie, if I comment this out, I can boot lguest without passing
noreplace_smp.

BTW, to make things clear: the patch I sent does _not_ fix the
lguest/alternatives problem. It just makes noreplace_smp functional
again and hence allows working around the lguest/alternatives bug.

 kernels, and that seems a very strange side effect of a patching
 problem...
 
 Nonetheless, I did have a previous problem with a bug in the patching
 code which didn't show up native and did show up under lguest.
 
 Can you send your config? 
Here it is:
http://fdeweerdt.free.fr/lguest_smp/dot_config

 Do you need noreplace-smp even on 2.6.23-rc3,
 or only 2.6.23-rc3-mm1?
I'll try ASAP.

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

Re: [-mm patch] enforce noreplace-smp in alternative_instructions()

[Frederik Deweerdt]

On Sat, Aug 25, 2007 at 02:23:24PM +0200, Frederik Deweerdt wrote:
 On Sat, Aug 25, 2007 at 10:07:29PM +1000, Rusty Russell wrote:
  Do you need noreplace-smp even on 2.6.23-rc3,
  or only 2.6.23-rc3-mm1?
 I'll try ASAP.
 
Ok, tested: I need noreplace-smp + patch to make it work on mainline too.

Regards,
Frederik
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] enforce noreplace-smp in alternative_instructions()

[Frederik Deweerdt]

[Added Gerd Hoffman and Rusty Russel to cc]
On Thu, Aug 23, 2007 at 11:46:52PM -0700, Jeremy Fitzhardinge wrote:
> Frederik Deweerdt wrote:
> > That means that even when you specify noreplace_smp, some replacing
> > takes place anyway. One of the consequences, besides noreplace_smp not
> > working as expected, is that lguest crashes when you feed it an SMP kernel
> > (I suspect that you can not replace alternatives for smp _and_ paravirt).
> >   
> 
> No, that should be fine.  Why does lguest crash?
It dies with:
[0.131000] SMP alternatives: switching to UP code
lguest: bad stack page 0xc057a000

I added a dump_stack on the Host, which gives:
[124320.090946]  [] dump_trace+0x65/0x1de
[124320.090956]  [] show_trace_log_lvl+0x1a/0x2f
[124320.090970]  [] show_trace+0x12/0x14
[124320.090975]  [] dump_stack+0x16/0x18
[124320.090980]  [] pin_page+0x5f/0xa3 [lg]
[124320.090993]  [] pin_stack_pages+0x3a/0x4a [lg]
[124320.091004]  [] guest_pagetable_clear_all+0x12/0x15 [lg]
[124320.091013]  [] do_hcall+0xb1/0x1cb [lg]
[124320.091021]  [] do_hypercalls+0x28a/0x2a0 [lg]
[124320.091029]  [] run_guest+0x24/0x492 [lg]
[124320.091037]  [] read+0x83/0x8f [lg]
[124320.091048]  [] vfs_read+0x8e/0x117
[124320.091054]  [] sys_read+0x3d/0x61
[124320.091059]  [] sysenter_past_esp+0x6b/0xb5
[124320.091065]  [] 0xe410
[124320.091069]  ===

Now, the "SMP alternatives: switching to UP code" message made me wonder
if it had anything to do with the alternatives, so I tried disabling
the switch by passing noreplace_smp...
... But the message was displayes anyway (and the smp_locks section
freed), because the check my patch adds is not made.
With the patch, I can boot lguest with an SMP kernel if I pass
noreplace_smp.
> 
> > I agree, but I don't think it is doable (alt_smp_once comes to mind). I'll
> > double check however.
> 
> Hm.  Is alt_smp_once useful?

I can't figure what the use case is, debugging set aside,
but there are places (eg xen, __cpu_die) in the kernel calling
alternatives_smp_switch(1) at runtime.  Passing smp-alt-once will prevent
the switch.

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

Re: [-mm patch] enforce noreplace-smp in alternative_instructions()

[Frederik Deweerdt]

On Thu, Aug 23, 2007 at 04:16:17PM -0700, Jeremy Fitzhardinge wrote:
> Frederik Deweerdt wrote:
> > On Wed, Aug 22, 2007 at 02:06:48AM -0700, Andrew Morton wrote:
> >   
> >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
> >>
> >> 
> > Hi Jeremy,
> >
> > arch/i386/kernel/alternative.c:alternative_instructions() doesn't
> > check for noreplace-smp before setting capability bits and freeing the
> > __smp_locks section.
> >
> > Every call to alternatives_smp_unlock() checks for noreplace-smp
> > beforehand, so remove the check from there.
> >
> > Boot tested on i386 with UP+noreplace-smp (lguest) and SMP (real hardware)
> >   
> 
> Does this fix a real problem?  Or is there just some redundancy? 
It does, see the mail to Andrew.
> Wouldn't it be better to put the noreplace_smp test in one place?
I agree, but I don't think it is doable (alt_smp_once comes to mind). I'll
double check however.

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

Re: [-mm patch] enforce noreplace-smp in alternative_instructions()

[Frederik Deweerdt]

On Thu, Aug 23, 2007 at 02:50:38PM -0700, Andrew Morton wrote:
> On Wed, 22 Aug 2007 22:25:51 +0200
> Frederik Deweerdt <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, Aug 22, 2007 at 02:06:48AM -0700, Andrew Morton wrote:
> > > 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
> > > 
> > Hi Jeremy,
> > 
> > arch/i386/kernel/alternative.c:alternative_instructions() doesn't
> > check for noreplace-smp before setting capability bits and freeing the
> > __smp_locks section.
> 
> umm, so?  What happens then?  What bug is being fixed here, and what are
> its consequences?
That means that even when you specify noreplace_smp, some replacing
takes place anyway. One of the consequences, besides noreplace_smp not
working as expected, is that lguest crashes when you feed it an SMP kernel
(I suspect that you can not replace alternatives for smp _and_ paravirt).
> 
> > Every call to alternatives_smp_unlock() checks for noreplace-smp
> > beforehand, so remove the check from there.
> > 
> > Boot tested on i386 with UP+noreplace-smp (lguest) and SMP (real hardware)
> > 
> > Regards,
> > Frederik
> > 
> > Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>
> > 
> > diff --git a/arch/i386/kernel/alternative.c b/arch/i386/kernel/alternative.c
> > index 9f4ac8b..7c5af80 100644
> > --- a/arch/i386/kernel/alternative.c
> > +++ b/arch/i386/kernel/alternative.c
> > @@ -221,9 +221,6 @@ static void alternatives_smp_unlock(u8 **start, u8 
> > **end, u8 *text, u8 *text_end
> > u8 **ptr;
> > char insn[1];
> >  
> > -   if (noreplace_smp)
> > -   return;
> > -
> > add_nops(insn, 1);
> > for (ptr = start; ptr < end; ptr++) {
> > if (*ptr < text)
> > @@ -406,7 +403,7 @@ void __init alternative_instructions(void)
> >  #endif
> >  
> >  #ifdef CONFIG_SMP
> > -   if (smp_alt_once) {
> > +   if (smp_alt_once && !noreplace_smp) {
> > if (1 == num_possible_cpus()) {
> > printk(KERN_INFO "SMP alternatives: switching to UP 
> > code\n");
> > set_bit(X86_FEATURE_UP, boot_cpu_data.x86_capability);
> 
> You refer to rc3-mm1 and this is described as a "-mm patch" but it seems to
> also be applicable to mainline?
> 
Hmm yes, my bad.

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

Re: [-mm patch] enforce noreplace-smp in alternative_instructions()

[Frederik Deweerdt]

On Thu, Aug 23, 2007 at 02:50:38PM -0700, Andrew Morton wrote:
 On Wed, 22 Aug 2007 22:25:51 +0200
 Frederik Deweerdt [EMAIL PROTECTED] wrote:
 
  On Wed, Aug 22, 2007 at 02:06:48AM -0700, Andrew Morton wrote:
   
   ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
   
  Hi Jeremy,
  
  arch/i386/kernel/alternative.c:alternative_instructions() doesn't
  check for noreplace-smp before setting capability bits and freeing the
  __smp_locks section.
 
 umm, so?  What happens then?  What bug is being fixed here, and what are
 its consequences?
That means that even when you specify noreplace_smp, some replacing
takes place anyway. One of the consequences, besides noreplace_smp not
working as expected, is that lguest crashes when you feed it an SMP kernel
(I suspect that you can not replace alternatives for smp _and_ paravirt).
 
  Every call to alternatives_smp_unlock() checks for noreplace-smp
  beforehand, so remove the check from there.
  
  Boot tested on i386 with UP+noreplace-smp (lguest) and SMP (real hardware)
  
  Regards,
  Frederik
  
  Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]
  
  diff --git a/arch/i386/kernel/alternative.c b/arch/i386/kernel/alternative.c
  index 9f4ac8b..7c5af80 100644
  --- a/arch/i386/kernel/alternative.c
  +++ b/arch/i386/kernel/alternative.c
  @@ -221,9 +221,6 @@ static void alternatives_smp_unlock(u8 **start, u8 
  **end, u8 *text, u8 *text_end
  u8 **ptr;
  char insn[1];
   
  -   if (noreplace_smp)
  -   return;
  -
  add_nops(insn, 1);
  for (ptr = start; ptr  end; ptr++) {
  if (*ptr  text)
  @@ -406,7 +403,7 @@ void __init alternative_instructions(void)
   #endif
   
   #ifdef CONFIG_SMP
  -   if (smp_alt_once) {
  +   if (smp_alt_once  !noreplace_smp) {
  if (1 == num_possible_cpus()) {
  printk(KERN_INFO SMP alternatives: switching to UP 
  code\n);
  set_bit(X86_FEATURE_UP, boot_cpu_data.x86_capability);
 
 You refer to rc3-mm1 and this is described as a -mm patch but it seems to
 also be applicable to mainline?
 
Hmm yes, my bad.

Regards,
Frederik
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] enforce noreplace-smp in alternative_instructions()

[Frederik Deweerdt]

On Thu, Aug 23, 2007 at 04:16:17PM -0700, Jeremy Fitzhardinge wrote:
 Frederik Deweerdt wrote:
  On Wed, Aug 22, 2007 at 02:06:48AM -0700, Andrew Morton wrote:

  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
 
  
  Hi Jeremy,
 
  arch/i386/kernel/alternative.c:alternative_instructions() doesn't
  check for noreplace-smp before setting capability bits and freeing the
  __smp_locks section.
 
  Every call to alternatives_smp_unlock() checks for noreplace-smp
  beforehand, so remove the check from there.
 
  Boot tested on i386 with UP+noreplace-smp (lguest) and SMP (real hardware)

 
 Does this fix a real problem?  Or is there just some redundancy? 
It does, see the mail to Andrew.
 Wouldn't it be better to put the noreplace_smp test in one place?
I agree, but I don't think it is doable (alt_smp_once comes to mind). I'll
double check however.

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

Re: [-mm patch] enforce noreplace-smp in alternative_instructions()

[Frederik Deweerdt]

[Added Gerd Hoffman and Rusty Russel to cc]
On Thu, Aug 23, 2007 at 11:46:52PM -0700, Jeremy Fitzhardinge wrote:
 Frederik Deweerdt wrote:
  That means that even when you specify noreplace_smp, some replacing
  takes place anyway. One of the consequences, besides noreplace_smp not
  working as expected, is that lguest crashes when you feed it an SMP kernel
  (I suspect that you can not replace alternatives for smp _and_ paravirt).

 
 No, that should be fine.  Why does lguest crash?
It dies with:
[0.131000] SMP alternatives: switching to UP code
lguest: bad stack page 0xc057a000

I added a dump_stack on the Host, which gives:
[124320.090946]  [c01052f8] dump_trace+0x65/0x1de
[124320.090956]  [c010548b] show_trace_log_lvl+0x1a/0x2f
[124320.090970]  [c0105ea4] show_trace+0x12/0x14
[124320.090975]  [c0105fcd] dump_stack+0x16/0x18
[124320.090980]  [f888032c] pin_page+0x5f/0xa3 [lg]
[124320.090993]  [f8880654] pin_stack_pages+0x3a/0x4a [lg]
[124320.091004]  [f888007e] guest_pagetable_clear_all+0x12/0x15 [lg]
[124320.091013]  [f887f81a] do_hcall+0xb1/0x1cb [lg]
[124320.091021]  [f887fbbe] do_hypercalls+0x28a/0x2a0 [lg]
[124320.091029]  [f887f2a2] run_guest+0x24/0x492 [lg]
[124320.091037]  [f8881b48] read+0x83/0x8f [lg]
[124320.091048]  [c0175a77] vfs_read+0x8e/0x117
[124320.091054]  [c0175e99] sys_read+0x3d/0x61
[124320.091059]  [c0104166] sysenter_past_esp+0x6b/0xb5
[124320.091065]  [e410] 0xe410
[124320.091069]  ===

Now, the SMP alternatives: switching to UP code message made me wonder
if it had anything to do with the alternatives, so I tried disabling
the switch by passing noreplace_smp...
... But the message was displayes anyway (and the smp_locks section
freed), because the check my patch adds is not made.
With the patch, I can boot lguest with an SMP kernel if I pass
noreplace_smp.
 
  I agree, but I don't think it is doable (alt_smp_once comes to mind). I'll
  double check however.
 
 Hm.  Is alt_smp_once useful?

I can't figure what the use case is, debugging set aside,
but there are places (eg xen, __cpu_die) in the kernel calling
alternatives_smp_switch(1) at runtime.  Passing smp-alt-once will prevent
the switch.

Regards,
Frederik
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: Server crashes unexpectedly

[Frederik Deweerdt]

On Thu, Aug 23, 2007 at 01:15:12PM +0200, Laurent CARON wrote:
> Hi,
> 
> One of my server crashes randomly.
> 
> I suspect a filesystem corruption.
What makes you think so?  I'd check the memory with memtest.

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

Re: PROBLEM: Server crashes unexpectedly

[Frederik Deweerdt]

On Thu, Aug 23, 2007 at 01:15:12PM +0200, Laurent CARON wrote:
 Hi,
 
 One of my server crashes randomly.
 
 I suspect a filesystem corruption.
What makes you think so?  I'd check the memory with memtest.

Regards,
Frederik
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc3-mm1: locking boot-time self-test failure

[Frederik Deweerdt]

On Wed, Aug 22, 2007 at 07:26:39PM +0200, Mariusz Kozlowski wrote:
>   Got that on my laptop:
> 
[...]
> -
> BUG:   6 unexpected failures (out of 218) - debugging disabled! |
> -

Hi Mariusz,

FWIW, reverting softlockup-use-cpu_clock-instead-of-sched_clock.patch
fixes the problem here.

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

[-mm patch] enforce noreplace-smp in alternative_instructions()

[Frederik Deweerdt]

On Wed, Aug 22, 2007 at 02:06:48AM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
> 
Hi Jeremy,

arch/i386/kernel/alternative.c:alternative_instructions() doesn't
check for noreplace-smp before setting capability bits and freeing the
__smp_locks section.

Every call to alternatives_smp_unlock() checks for noreplace-smp
beforehand, so remove the check from there.

Boot tested on i386 with UP+noreplace-smp (lguest) and SMP (real hardware)

Regards,
Frederik

Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>

diff --git a/arch/i386/kernel/alternative.c b/arch/i386/kernel/alternative.c
index 9f4ac8b..7c5af80 100644
--- a/arch/i386/kernel/alternative.c
+++ b/arch/i386/kernel/alternative.c
@@ -221,9 +221,6 @@ static void alternatives_smp_unlock(u8 **start, u8 **end, 
u8 *text, u8 *text_end
u8 **ptr;
char insn[1];
 
-   if (noreplace_smp)
-   return;
-
add_nops(insn, 1);
for (ptr = start; ptr < end; ptr++) {
if (*ptr < text)
@@ -406,7 +403,7 @@ void __init alternative_instructions(void)
 #endif
 
 #ifdef CONFIG_SMP
-   if (smp_alt_once) {
+   if (smp_alt_once && !noreplace_smp) {
if (1 == num_possible_cpus()) {
printk(KERN_INFO "SMP alternatives: switching to UP 
code\n");
set_bit(X86_FEATURE_UP, boot_cpu_data.x86_capability);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] enforce noreplace-smp in alternative_instructions()

[Frederik Deweerdt]

On Wed, Aug 22, 2007 at 02:06:48AM -0700, Andrew Morton wrote:
 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
 
Hi Jeremy,

arch/i386/kernel/alternative.c:alternative_instructions() doesn't
check for noreplace-smp before setting capability bits and freeing the
__smp_locks section.

Every call to alternatives_smp_unlock() checks for noreplace-smp
beforehand, so remove the check from there.

Boot tested on i386 with UP+noreplace-smp (lguest) and SMP (real hardware)

Regards,
Frederik

Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]

diff --git a/arch/i386/kernel/alternative.c b/arch/i386/kernel/alternative.c
index 9f4ac8b..7c5af80 100644
--- a/arch/i386/kernel/alternative.c
+++ b/arch/i386/kernel/alternative.c
@@ -221,9 +221,6 @@ static void alternatives_smp_unlock(u8 **start, u8 **end, 
u8 *text, u8 *text_end
u8 **ptr;
char insn[1];
 
-   if (noreplace_smp)
-   return;
-
add_nops(insn, 1);
for (ptr = start; ptr  end; ptr++) {
if (*ptr  text)
@@ -406,7 +403,7 @@ void __init alternative_instructions(void)
 #endif
 
 #ifdef CONFIG_SMP
-   if (smp_alt_once) {
+   if (smp_alt_once  !noreplace_smp) {
if (1 == num_possible_cpus()) {
printk(KERN_INFO SMP alternatives: switching to UP 
code\n);
set_bit(X86_FEATURE_UP, boot_cpu_data.x86_capability);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc3-mm1: locking boot-time self-test failure

[Frederik Deweerdt]

On Wed, Aug 22, 2007 at 07:26:39PM +0200, Mariusz Kozlowski wrote:
   Got that on my laptop:
 
[...]
 -
 BUG:   6 unexpected failures (out of 218) - debugging disabled! |
 -

Hi Mariusz,

FWIW, reverting softlockup-use-cpu_clock-instead-of-sched_clock.patch
fixes the problem here.

Regards,
Frederik
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Serial buffer memory leak

[Frederik Deweerdt]

On Wed, Aug 08, 2007 at 02:45:32PM +0100, Alan Cox wrote:
> > I'm not familiar enough with the tty code to decide what the proper fix 
> > should 
> > be. I'll try to write a patch if someone could point me in the right 
> > direction.
> 
> Something like this perhaps ?
> 
[]
> - *   flush all the buffers containing receive data
> + *   flush all the buffers containing receive data. Caller must
> + *   hold the buffer lock and must have ensured no parallel flush to
> + *   ldisc is running.
>   *
>   *   Locking: none
 
>   */
Isn't the comment a bit misleading here? The caller must hold tty->buf.lock.

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

Re: Serial buffer memory leak

[Frederik Deweerdt]

On Wed, Aug 08, 2007 at 02:45:32PM +0100, Alan Cox wrote:
  I'm not familiar enough with the tty code to decide what the proper fix 
  should 
  be. I'll try to write a patch if someone could point me in the right 
  direction.
 
 Something like this perhaps ?
 
[]
 - *   flush all the buffers containing receive data
 + *   flush all the buffers containing receive data. Caller must
 + *   hold the buffer lock and must have ensured no parallel flush to
 + *   ldisc is running.
   *
   *   Locking: none
 
   */
Isn't the comment a bit misleading here? The caller must hold tty-buf.lock.

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

[-mm patch] xtensa console.c: remove duplicate #include

[Frederik Deweerdt]

On Wed, Jul 25, 2007 at 04:03:04AM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc1/2.6.23-rc1-mm1/
> 
Hi,

This patch removes one of the two linux/console.h included in
arch/xtensa/platform-iss/console.c

Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>

diff --git a/arch/xtensa/platform-iss/console.c 
b/arch/xtensa/platform-iss/console.c
index 2f4f20f..854677d 100644
--- a/arch/xtensa/platform-iss/console.c
+++ b/arch/xtensa/platform-iss/console.c
@@ -20,7 +20,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] xtensa console.c: remove duplicate #include

[Frederik Deweerdt]

On Wed, Jul 25, 2007 at 04:03:04AM -0700, Andrew Morton wrote:
 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc1/2.6.23-rc1-mm1/
 
Hi,

This patch removes one of the two linux/console.h included in
arch/xtensa/platform-iss/console.c

Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]

diff --git a/arch/xtensa/platform-iss/console.c 
b/arch/xtensa/platform-iss/console.c
index 2f4f20f..854677d 100644
--- a/arch/xtensa/platform-iss/console.c
+++ b/arch/xtensa/platform-iss/console.c
@@ -20,7 +20,6 @@
 #include linux/param.h
 #include linux/serial.h
 #include linux/serialP.h
-#include linux/console.h
 
 #include asm/uaccess.h
 #include asm/irq.h
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: v2.6.23-rc1-rt0

[Frederik Deweerdt]

On Tue, Jul 24, 2007 at 02:12:27PM +0200, Ingo Molnar wrote:
> i've released the v2.6.23-rc1-rt0 kernel, which can be downloaded from 
> the usual place:
>  
>http://redhat.com/~mingo/realtime-preempt/
Hi Ingo,

  CC  kernel/latency_hist.o
  kernel/latency_hist.c: In function 'u64_div':
  kernel/latency_hist.c:54: error: implicit declaration of function 'do_div'
  make[1]: *** [kernel/latency_hist.o] Error 1
  make: *** [kernel] Error 2

This was needed to compile rt0 with LATENCY_TRACE on i386:

Add asm/div64.h header to define do_div()

Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>

--- kernel/latency_hist..ori2007-07-24 16:04:20.0 +0200
+++ kernel/latency_hist.c   2007-07-24 16:04:50.0 +0200
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 typedef struct hist_data_struct {
atomic_t hist_mode; /* 0 log, 1 don't log */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: v2.6.23-rc1-rt0

[Frederik Deweerdt]

On Tue, Jul 24, 2007 at 02:12:27PM +0200, Ingo Molnar wrote:
 i've released the v2.6.23-rc1-rt0 kernel, which can be downloaded from 
 the usual place:
  
http://redhat.com/~mingo/realtime-preempt/
Hi Ingo,

  CC  kernel/latency_hist.o
  kernel/latency_hist.c: In function 'u64_div':
  kernel/latency_hist.c:54: error: implicit declaration of function 'do_div'
  make[1]: *** [kernel/latency_hist.o] Error 1
  make: *** [kernel] Error 2

This was needed to compile rt0 with LATENCY_TRACE on i386:

Add asm/div64.h header to define do_div()

Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]

--- kernel/latency_hist..ori2007-07-24 16:04:20.0 +0200
+++ kernel/latency_hist.c   2007-07-24 16:04:50.0 +0200
@@ -15,6 +15,7 @@
 #include linux/percpu.h
 #include linux/latency_hist.h
 #include asm/atomic.h
+#include asm/div64.h
 
 typedef struct hist_data_struct {
atomic_t hist_mode; /* 0 log, 1 don't log */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch] drivers/scsi/scsi_sysfs.c:718: warning: unused variable `rq'

[Frederik Deweerdt]

Hi James,

A compile of the latest git on arm triggers the following warning:
  CC [M]  drivers/scsi/scsi_sysfs.o
  drivers/scsi/scsi_sysfs.c: In function `scsi_sysfs_add_sdev':
  drivers/scsi/scsi_sysfs.c:718: warning: unused variable `rq'

The following patch kills the intermediary variable.

Regards,
Frederik

Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>

diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 34cdce6..9e5cc4f 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -715,7 +715,6 @@ static int attr_add(struct device *dev, struct 
device_attribute *attr)
 int scsi_sysfs_add_sdev(struct scsi_device *sdev)
 {
int error, i;
-   struct request_queue *rq = sdev->request_queue;
 
if ((error = scsi_device_set_state(sdev, SDEV_RUNNING)) != 0)
return error;
@@ -736,7 +735,8 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
 * released by the sdev_class .release */
get_device(>sdev_gendev);
 
-   error = bsg_register_queue(rq, >sdev_gendev, NULL);
+   error = bsg_register_queue(sdev->request_queue,
+  >sdev_gendev, NULL);
 
if (error)
sdev_printk(KERN_INFO, sdev,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch] drivers/scsi/scsi_sysfs.c:718: warning: unused variable `rq'

[Frederik Deweerdt]

Hi James,

A compile of the latest git on arm triggers the following warning:
  CC [M]  drivers/scsi/scsi_sysfs.o
  drivers/scsi/scsi_sysfs.c: In function `scsi_sysfs_add_sdev':
  drivers/scsi/scsi_sysfs.c:718: warning: unused variable `rq'

The following patch kills the intermediary variable.

Regards,
Frederik

Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]

diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 34cdce6..9e5cc4f 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -715,7 +715,6 @@ static int attr_add(struct device *dev, struct 
device_attribute *attr)
 int scsi_sysfs_add_sdev(struct scsi_device *sdev)
 {
int error, i;
-   struct request_queue *rq = sdev-request_queue;
 
if ((error = scsi_device_set_state(sdev, SDEV_RUNNING)) != 0)
return error;
@@ -736,7 +735,8 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
 * released by the sdev_class .release */
get_device(sdev-sdev_gendev);
 
-   error = bsg_register_queue(rq, sdev-sdev_gendev, NULL);
+   error = bsg_register_queue(sdev-request_queue,
+  sdev-sdev_gendev, NULL);
 
if (error)
sdev_printk(KERN_INFO, sdev,
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Use descriptor's functions instead of inline assembly

[Frederik Deweerdt]

On Fri, Jul 20, 2007 at 10:56:01AM -0300, Glauber de Oliveira Costa wrote:
> This patch provides a new set of functions for managing the descriptor
> tables that can be used instead of putting the raw assembly in .c files.
> 
> Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
> 
> - asm volatile ("str %0"  : "=m" (ctxt->tr));
> + store_gdt((struct desc_ptr *)>gdt_limit);
> + store_idt((struct desc_ptr *)>idt_limit);
> + ctxt->tr = store_tr();
>  
Would'nt a store_tr(>tr) be more homogeneous here?

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

Re: [PATCH] Use descriptor's functions instead of inline assembly

[Frederik Deweerdt]

On Fri, Jul 20, 2007 at 10:56:01AM -0300, Glauber de Oliveira Costa wrote:
 This patch provides a new set of functions for managing the descriptor
 tables that can be used instead of putting the raw assembly in .c files.
 
 Signed-off-by: Glauber de Oliveira Costa [EMAIL PROTECTED]
 
 - asm volatile (str %0  : =m (ctxt-tr));
 + store_gdt((struct desc_ptr *)ctxt-gdt_limit);
 + store_idt((struct desc_ptr *)ctxt-idt_limit);
 + ctxt-tr = store_tr();
  
Would'nt a store_tr(ctxt-tr) be more homogeneous here?

Regards,
Frederik
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i386 CPA fix - do not free reserved pages

[Frederik Deweerdt]

On Tue, Jul 03, 2007 at 01:33:24PM -0400, Mathieu Desnoyers wrote:
> Right, there is a test missing, can you try this fix on top of my
> x86_64 mm cpa cache flush fix ?
No warning with both patches applied, thanks Mathieu.

Frederik
> 
> 
> i386 CPA fix - do not free reserved pages
> 
> We have to use the same conditions found in change_page_attr in
> global_tlb_flush regarding the conditions that leads to free the page.
> 
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> ---
>  arch/i386/mm/pageattr.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-2.6-lttng/arch/i386/mm/pageattr.c
> ===
> --- linux-2.6-lttng.orig/arch/i386/mm/pageattr.c  2007-07-03 
> 13:25:48.0 -0400
> +++ linux-2.6-lttng/arch/i386/mm/pageattr.c   2007-07-03 13:28:34.0 
> -0400
> @@ -247,7 +247,7 @@
>   list_for_each_entry_safe(pg, next, , lru) {
>   clear_bit(PG_arch_1, >flags);
>   list_del(>lru);
> - if (page_private(pg) != 0)
> + if (PageReserved(pg) || !cpu_has_pse || page_private(pg) != 0)
>   continue;
>   ClearPagePrivate(pg);
>   __free_page(pg);
> 
> 
> * Frederik Deweerdt ([EMAIL PROTECTED]) wrote:
> > On Tue, Jul 03, 2007 at 11:37:47AM -0400, Mathieu Desnoyers wrote:
> > > Hi Alan,
> > > 
> > > I already sent a fix to Andrew and Andi for this (hrm, forget to CC
> > > lkml on the original message):
> > > 
> > > 
> > > x86_64 mm cpa cache flush fix
> > > 
> > > X86_64 and i386 cpa cache flush fix:
> > > 
> > > list_del the deferred list entries to poison their pointers.
> > > clear the flag for every page put in the list.
> > > 
> > Hi Mathieu,
> > 
> > I've tried the patch on rc6-mm1, but it doesn't seem to fix the
> > problem. From what I understood, the bad_page() is called on PG_reserved
> > being set (flags:0x0400), not the lru pointer being not NULL or
> > PG_arch_1 being set.
> > 
> > Regards,
> > Frederik
> > 
> > > Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> > > CC: Andi Kleen <[EMAIL PROTECTED]>
> > [...]
> > >   flush_map();
> > >   list_for_each_entry_safe(pg, next, , lru) {
> > > + clear_bit(PG_arch_1, >flags);
> > > + list_del(>lru);
> > >   if (page_private(pg) != 0)
> > >   continue;
> > >   ClearPagePrivate(pg);
> > > - clear_bit(PG_arch_1, >flags);
> > >   __free_page(pg);
> > >   }
> > >  }
> > [...]
> > > * Alan Cox ([EMAIL PROTECTED]) wrote:
> > > > X86 32bit with lots of debug turned on I get this:
> > [...]
> > > > Bad page state in process 'swapper'
> > > > page:c1c0 flags:0x0400 mapping: mapcount:0 count:0
> > > > Trying to fix it up, but a reboot is needed
> > > > Backtrace:
> > > >  [] bad_page+0x6c/0x100
> > > >  [] free_hot_cold_page+0x5d/0x140
> > > >  [] global_flush_tlb+0x112/0x130
> > > >  [] init_post+0xd/0xe0
> > > >  [] kernel_init+0x216/0x220
> > > >  [] schedule_tail+0x0/0xe0
> > > >  [] kernel_init+0x0/0x220
> > > >  [] kernel_init+0x0/0x220
> > > >  [] kernel_thread_helper+0x7/0x10
> > > >  ===
> > > > Hexdump:
> > > > 000: 00 06 00 00 01 00 00 00 ff ff ff ff 0f 00 00 00
> > > > 010: 00 00 00 00 00 00 00 00 78 00 00 c1 b8 00 00 c1
> > > > 020: 00 06 00 00 01 00 00 00 ff ff ff ff a7 03 00 00
> > > > 030: 00 00 00 00 00 00 00 00 98 00 00 c1 d8 00 00 c1
> > > > 040: 00 04 00 00 00 00 00 00 ff ff ff ff 00 00 00 00
> > > > 050: 00 00 00 00 00 00 00 00 b8 00 00 c1 f8 00 00 c1
> > > > 060: 00 06 00 00 01 00 00 00 ff ff ff ff 00 04 00 00
> > > > 070: 00 00 00 00 00 00 00 00 d8 00 00 c1 18 01 00 c1
> > > > 080: 00 06 00 00 01 00 00 00 ff ff ff ff 9c 03 00 00
> > > > 090: 00 00 00 00 00 00 00 00 f8 00 00 c1 38 01 00 c1
> > > > 0a0: 00 06 00 00 01 00 00 00 ff ff ff ff 00 04 00 00
> > > > 0b0: 00 00 00 00 00 00 00 00 18 01 00 c1 58 01 00 c1
> > > > -
> > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" 
> > > > in
> > > > the body of a message to [EMAIL PROTECTED]
> > > > More majordomo info a

Re: 2.6.22-rc6-mm1 bad_page events.

[Frederik Deweerdt]

On Tue, Jul 03, 2007 at 11:37:47AM -0400, Mathieu Desnoyers wrote:
> Hi Alan,
> 
> I already sent a fix to Andrew and Andi for this (hrm, forget to CC
> lkml on the original message):
> 
> 
> x86_64 mm cpa cache flush fix
> 
> X86_64 and i386 cpa cache flush fix:
> 
> list_del the deferred list entries to poison their pointers.
> clear the flag for every page put in the list.
> 
Hi Mathieu,

I've tried the patch on rc6-mm1, but it doesn't seem to fix the
problem. From what I understood, the bad_page() is called on PG_reserved
being set (flags:0x0400), not the lru pointer being not NULL or
PG_arch_1 being set.

Regards,
Frederik

> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> CC: Andi Kleen <[EMAIL PROTECTED]>
[...]
>   flush_map();
>   list_for_each_entry_safe(pg, next, , lru) {
> + clear_bit(PG_arch_1, >flags);
> + list_del(>lru);
>   if (page_private(pg) != 0)
>   continue;
>   ClearPagePrivate(pg);
> - clear_bit(PG_arch_1, >flags);
>   __free_page(pg);
>   }
>  }
[...]
> * Alan Cox ([EMAIL PROTECTED]) wrote:
> > X86 32bit with lots of debug turned on I get this:
[...]
> > Bad page state in process 'swapper'
> > page:c1c0 flags:0x0400 mapping: mapcount:0 count:0
> > Trying to fix it up, but a reboot is needed
> > Backtrace:
> >  [] bad_page+0x6c/0x100
> >  [] free_hot_cold_page+0x5d/0x140
> >  [] global_flush_tlb+0x112/0x130
> >  [] init_post+0xd/0xe0
> >  [] kernel_init+0x216/0x220
> >  [] schedule_tail+0x0/0xe0
> >  [] kernel_init+0x0/0x220
> >  [] kernel_init+0x0/0x220
> >  [] kernel_thread_helper+0x7/0x10
> >  ===
> > Hexdump:
> > 000: 00 06 00 00 01 00 00 00 ff ff ff ff 0f 00 00 00
> > 010: 00 00 00 00 00 00 00 00 78 00 00 c1 b8 00 00 c1
> > 020: 00 06 00 00 01 00 00 00 ff ff ff ff a7 03 00 00
> > 030: 00 00 00 00 00 00 00 00 98 00 00 c1 d8 00 00 c1
> > 040: 00 04 00 00 00 00 00 00 ff ff ff ff 00 00 00 00
> > 050: 00 00 00 00 00 00 00 00 b8 00 00 c1 f8 00 00 c1
> > 060: 00 06 00 00 01 00 00 00 ff ff ff ff 00 04 00 00
> > 070: 00 00 00 00 00 00 00 00 d8 00 00 c1 18 01 00 c1
> > 080: 00 06 00 00 01 00 00 00 ff ff ff ff 9c 03 00 00
> > 090: 00 00 00 00 00 00 00 00 f8 00 00 c1 38 01 00 c1
> > 0a0: 00 06 00 00 01 00 00 00 ff ff ff ff 00 04 00 00
> > 0b0: 00 00 00 00 00 00 00 00 18 01 00 c1 58 01 00 c1
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> 
> -- 
> Mathieu Desnoyers
> Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.22-rc6-mm1 bad_page events.

[Frederik Deweerdt]

On Tue, Jul 03, 2007 at 11:37:47AM -0400, Mathieu Desnoyers wrote:
 Hi Alan,
 
 I already sent a fix to Andrew and Andi for this (hrm, forget to CC
 lkml on the original message):
 
 
 x86_64 mm cpa cache flush fix
 
 X86_64 and i386 cpa cache flush fix:
 
 list_del the deferred list entries to poison their pointers.
 clear the flag for every page put in the list.
 
Hi Mathieu,

I've tried the patch on rc6-mm1, but it doesn't seem to fix the
problem. From what I understood, the bad_page() is called on PG_reserved
being set (flags:0x0400), not the lru pointer being not NULL or
PG_arch_1 being set.

Regards,
Frederik

 Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED]
 CC: Andi Kleen [EMAIL PROTECTED]
[...]
   flush_map(l);
   list_for_each_entry_safe(pg, next, l, lru) {
 + clear_bit(PG_arch_1, pg-flags);
 + list_del(pg-lru);
   if (page_private(pg) != 0)
   continue;
   ClearPagePrivate(pg);
 - clear_bit(PG_arch_1, pg-flags);
   __free_page(pg);
   }
  }
[...]
 * Alan Cox ([EMAIL PROTECTED]) wrote:
  X86 32bit with lots of debug turned on I get this:
[...]
  Bad page state in process 'swapper'
  page:c1c0 flags:0x0400 mapping: mapcount:0 count:0
  Trying to fix it up, but a reboot is needed
  Backtrace:
   [c024589c] bad_page+0x6c/0x100
   [c024648d] free_hot_cold_page+0x5d/0x140
   [c02116c2] global_flush_tlb+0x112/0x130
   [c020102d] init_post+0xd/0xe0
   [c047c876] kernel_init+0x216/0x220
   [c0214c50] schedule_tail+0x0/0xe0
   [c047c660] kernel_init+0x0/0x220
   [c047c660] kernel_init+0x0/0x220
   [c0204227] kernel_thread_helper+0x7/0x10
   ===
  Hexdump:
  000: 00 06 00 00 01 00 00 00 ff ff ff ff 0f 00 00 00
  010: 00 00 00 00 00 00 00 00 78 00 00 c1 b8 00 00 c1
  020: 00 06 00 00 01 00 00 00 ff ff ff ff a7 03 00 00
  030: 00 00 00 00 00 00 00 00 98 00 00 c1 d8 00 00 c1
  040: 00 04 00 00 00 00 00 00 ff ff ff ff 00 00 00 00
  050: 00 00 00 00 00 00 00 00 b8 00 00 c1 f8 00 00 c1
  060: 00 06 00 00 01 00 00 00 ff ff ff ff 00 04 00 00
  070: 00 00 00 00 00 00 00 00 d8 00 00 c1 18 01 00 c1
  080: 00 06 00 00 01 00 00 00 ff ff ff ff 9c 03 00 00
  090: 00 00 00 00 00 00 00 00 f8 00 00 c1 38 01 00 c1
  0a0: 00 06 00 00 01 00 00 00 ff ff ff ff 00 04 00 00
  0b0: 00 00 00 00 00 00 00 00 18 01 00 c1 58 01 00 c1
  -
  To unsubscribe from this list: send the line unsubscribe linux-kernel in
  the body of a message to [EMAIL PROTECTED]
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
  Please read the FAQ at  http://www.tux.org/lkml/
  
 
 -- 
 Mathieu Desnoyers
 Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
 OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i386 CPA fix - do not free reserved pages

[Frederik Deweerdt]

On Tue, Jul 03, 2007 at 01:33:24PM -0400, Mathieu Desnoyers wrote:
 Right, there is a test missing, can you try this fix on top of my
 x86_64 mm cpa cache flush fix ?
No warning with both patches applied, thanks Mathieu.

Frederik
 
 
 i386 CPA fix - do not free reserved pages
 
 We have to use the same conditions found in change_page_attr in
 global_tlb_flush regarding the conditions that leads to free the page.
 
 Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED]
 ---
  arch/i386/mm/pageattr.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 Index: linux-2.6-lttng/arch/i386/mm/pageattr.c
 ===
 --- linux-2.6-lttng.orig/arch/i386/mm/pageattr.c  2007-07-03 
 13:25:48.0 -0400
 +++ linux-2.6-lttng/arch/i386/mm/pageattr.c   2007-07-03 13:28:34.0 
 -0400
 @@ -247,7 +247,7 @@
   list_for_each_entry_safe(pg, next, l, lru) {
   clear_bit(PG_arch_1, pg-flags);
   list_del(pg-lru);
 - if (page_private(pg) != 0)
 + if (PageReserved(pg) || !cpu_has_pse || page_private(pg) != 0)
   continue;
   ClearPagePrivate(pg);
   __free_page(pg);
 
 
 * Frederik Deweerdt ([EMAIL PROTECTED]) wrote:
  On Tue, Jul 03, 2007 at 11:37:47AM -0400, Mathieu Desnoyers wrote:
   Hi Alan,
   
   I already sent a fix to Andrew and Andi for this (hrm, forget to CC
   lkml on the original message):
   
   
   x86_64 mm cpa cache flush fix
   
   X86_64 and i386 cpa cache flush fix:
   
   list_del the deferred list entries to poison their pointers.
   clear the flag for every page put in the list.
   
  Hi Mathieu,
  
  I've tried the patch on rc6-mm1, but it doesn't seem to fix the
  problem. From what I understood, the bad_page() is called on PG_reserved
  being set (flags:0x0400), not the lru pointer being not NULL or
  PG_arch_1 being set.
  
  Regards,
  Frederik
  
   Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED]
   CC: Andi Kleen [EMAIL PROTECTED]
  [...]
 flush_map(l);
 list_for_each_entry_safe(pg, next, l, lru) {
   + clear_bit(PG_arch_1, pg-flags);
   + list_del(pg-lru);
 if (page_private(pg) != 0)
 continue;
 ClearPagePrivate(pg);
   - clear_bit(PG_arch_1, pg-flags);
 __free_page(pg);
 }
}
  [...]
   * Alan Cox ([EMAIL PROTECTED]) wrote:
X86 32bit with lots of debug turned on I get this:
  [...]
Bad page state in process 'swapper'
page:c1c0 flags:0x0400 mapping: mapcount:0 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
 [c024589c] bad_page+0x6c/0x100
 [c024648d] free_hot_cold_page+0x5d/0x140
 [c02116c2] global_flush_tlb+0x112/0x130
 [c020102d] init_post+0xd/0xe0
 [c047c876] kernel_init+0x216/0x220
 [c0214c50] schedule_tail+0x0/0xe0
 [c047c660] kernel_init+0x0/0x220
 [c047c660] kernel_init+0x0/0x220
 [c0204227] kernel_thread_helper+0x7/0x10
 ===
Hexdump:
000: 00 06 00 00 01 00 00 00 ff ff ff ff 0f 00 00 00
010: 00 00 00 00 00 00 00 00 78 00 00 c1 b8 00 00 c1
020: 00 06 00 00 01 00 00 00 ff ff ff ff a7 03 00 00
030: 00 00 00 00 00 00 00 00 98 00 00 c1 d8 00 00 c1
040: 00 04 00 00 00 00 00 00 ff ff ff ff 00 00 00 00
050: 00 00 00 00 00 00 00 00 b8 00 00 c1 f8 00 00 c1
060: 00 06 00 00 01 00 00 00 ff ff ff ff 00 04 00 00
070: 00 00 00 00 00 00 00 00 d8 00 00 c1 18 01 00 c1
080: 00 06 00 00 01 00 00 00 ff ff ff ff 9c 03 00 00
090: 00 00 00 00 00 00 00 00 f8 00 00 c1 38 01 00 c1
0a0: 00 06 00 00 01 00 00 00 ff ff ff ff 00 04 00 00
0b0: 00 00 00 00 00 00 00 00 18 01 00 c1 58 01 00 c1
-
To unsubscribe from this list: send the line unsubscribe linux-kernel 
in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

   
   -- 
   Mathieu Desnoyers
   Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
   OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 
   9A68
   -
   To unsubscribe from this list: send the line unsubscribe linux-kernel in
   the body of a message to [EMAIL PROTECTED]
   More majordomo info at  http://vger.kernel.org/majordomo-info.html
   Please read the FAQ at  http://www.tux.org/lkml/
   
  
 
 -- 
 Mathieu Desnoyers
 Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
 OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 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 [EMAIL

Re: [-mm patch] make csum_and_copy_from_user arch independent

[Frederik Deweerdt]

On Fri, May 11, 2007 at 02:14:43AM -0700, David Miller wrote:
> From: Frederik Deweerdt <[EMAIL PROTECTED]>
> Date: Fri, 11 May 2007 10:27:38 +0200
> 
> > ERROR: "csum_partial_copy_from_user" [net/rxrpc/af-rxrpc.ko] undefined!
> > 
> > Linking on ARM fails because albeit a generic csum_and_copy_from_user()
> > function is provided in the case ! _HAVE_ARCH_COPY_AND_CSUM_FROM_USER, the
> > generic function uses csum_partial_copy_from_user() which is i386 only.
> 
> On what planet is csum_partial_copy_from_user() i386 only?
> Every single platform provides that function.
Er, my bad, I've changed my cscope bindings and I saw no results except
i386.
> The issue more-so appears to be that ARM simply fails to
> export the symbol to modules like the other platforms do.
Indeed, here's the fix.

Thanks,
Frederik

Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>

diff --git a/arch/arm/kernel/armksyms.c b/arch/arm/kernel/armksyms.c
index 4779f47..9179e82 100644
--- a/arch/arm/kernel/armksyms.c
+++ b/arch/arm/kernel/armksyms.c
@@ -76,6 +76,7 @@ EXPORT_SYMBOL(__const_udelay);
 
/* networking */
 EXPORT_SYMBOL(csum_partial);
+EXPORT_SYMBOL(csum_partial_copy_from_user);
 EXPORT_SYMBOL(csum_partial_copy_nocheck);
 EXPORT_SYMBOL(__csum_ipv6_magic);
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] make csum_and_copy_from_user arch independent (was Re: 2.6.21-mm2)

[Frederik Deweerdt]

On Wed, May 09, 2007 at 01:23:22AM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm2/
> 

ERROR: "csum_partial_copy_from_user" [net/rxrpc/af-rxrpc.ko] undefined!

Linking on ARM fails because albeit a generic csum_and_copy_from_user()
function is provided in the case ! _HAVE_ARCH_COPY_AND_CSUM_FROM_USER, the
generic function uses csum_partial_copy_from_user() which is i386 only.

The following patch uses copy_from_user() followed by csum_partial()
to make the function platform independent.

Regards,
Frederik

Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>

diff --git a/include/net/checksum.h b/include/net/checksum.h
index 1242461..2eebb95 100644
--- a/include/net/checksum.h
+++ b/include/net/checksum.h
@@ -30,13 +30,16 @@ static inline
 __wsum csum_and_copy_from_user (const void __user *src, void *dst,
  int len, __wsum sum, int *err_ptr)
 {
-   if (access_ok(VERIFY_READ, src, len))
-   return csum_partial_copy_from_user(src, dst, len, sum, err_ptr);
+   if (access_ok(VERIFY_READ, src, len)) {
+   if (copy_from_user(dst, src, len))
+   return -EFAULT;
+   return csum_partial(dst, len, sum);
+   }
 
if (len)
*err_ptr = -EFAULT;
 
-   return sum;
+   return (__force __wsum)-1; /* invalid checksum */
 }
 #endif
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] make csum_and_copy_from_user arch independent (was Re: 2.6.21-mm2)

[Frederik Deweerdt]

On Wed, May 09, 2007 at 01:23:22AM -0700, Andrew Morton wrote:
 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm2/
 

ERROR: csum_partial_copy_from_user [net/rxrpc/af-rxrpc.ko] undefined!

Linking on ARM fails because albeit a generic csum_and_copy_from_user()
function is provided in the case ! _HAVE_ARCH_COPY_AND_CSUM_FROM_USER, the
generic function uses csum_partial_copy_from_user() which is i386 only.

The following patch uses copy_from_user() followed by csum_partial()
to make the function platform independent.

Regards,
Frederik

Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]

diff --git a/include/net/checksum.h b/include/net/checksum.h
index 1242461..2eebb95 100644
--- a/include/net/checksum.h
+++ b/include/net/checksum.h
@@ -30,13 +30,16 @@ static inline
 __wsum csum_and_copy_from_user (const void __user *src, void *dst,
  int len, __wsum sum, int *err_ptr)
 {
-   if (access_ok(VERIFY_READ, src, len))
-   return csum_partial_copy_from_user(src, dst, len, sum, err_ptr);
+   if (access_ok(VERIFY_READ, src, len)) {
+   if (copy_from_user(dst, src, len))
+   return -EFAULT;
+   return csum_partial(dst, len, sum);
+   }
 
if (len)
*err_ptr = -EFAULT;
 
-   return sum;
+   return (__force __wsum)-1; /* invalid checksum */
 }
 #endif
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] make csum_and_copy_from_user arch independent

[Frederik Deweerdt]

On Fri, May 11, 2007 at 02:14:43AM -0700, David Miller wrote:
 From: Frederik Deweerdt [EMAIL PROTECTED]
 Date: Fri, 11 May 2007 10:27:38 +0200
 
  ERROR: csum_partial_copy_from_user [net/rxrpc/af-rxrpc.ko] undefined!
  
  Linking on ARM fails because albeit a generic csum_and_copy_from_user()
  function is provided in the case ! _HAVE_ARCH_COPY_AND_CSUM_FROM_USER, the
  generic function uses csum_partial_copy_from_user() which is i386 only.
 
 On what planet is csum_partial_copy_from_user() i386 only?
 Every single platform provides that function.
Er, my bad, I've changed my cscope bindings and I saw no results except
i386.
 The issue more-so appears to be that ARM simply fails to
 export the symbol to modules like the other platforms do.
Indeed, here's the fix.

Thanks,
Frederik

Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]

diff --git a/arch/arm/kernel/armksyms.c b/arch/arm/kernel/armksyms.c
index 4779f47..9179e82 100644
--- a/arch/arm/kernel/armksyms.c
+++ b/arch/arm/kernel/armksyms.c
@@ -76,6 +76,7 @@ EXPORT_SYMBOL(__const_udelay);
 
/* networking */
 EXPORT_SYMBOL(csum_partial);
+EXPORT_SYMBOL(csum_partial_copy_from_user);
 EXPORT_SYMBOL(csum_partial_copy_nocheck);
 EXPORT_SYMBOL(__csum_ipv6_magic);
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ixp4xx compile error (was Re: 2.6.21-mm2)

[Frederik Deweerdt]

On Thu, May 10, 2007 at 02:21:29PM +0200, Frederik Deweerdt wrote:
> On Wed, May 09, 2007 at 01:23:22AM -0700, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm2/
> > 
> Hi all,
> 
> I've got this compile error while building arm ipx4xx:
> 
>   CC [M]  drivers/input/misc/ixp4xx-beeper.o
> drivers/input/misc/ixp4xx-beeper.c: In function 'ixp4xx_spkr_event':
> drivers/input/misc/ixp4xx-beeper.c:54: error: 'input_dev' undeclared (first 
> use in this function)
> drivers/input/misc/ixp4xx-beeper.c:54: error: (Each undeclared identifier is 
> reported only once
> drivers/input/misc/ixp4xx-beeper.c:54: error: for each function it appears 
> in.)
> make[3]: *** [drivers/input/misc/ixp4xx-beeper.o] Error 1
> make[2]: *** [drivers/input/misc] Error 2
> make[1]: *** [drivers/input] Error 2
> make: *** [drivers] Error 2
> 
> Following patch fixes the problem.

Err, got it backwards. Here's the correct fix:

Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>

--- drivers/input/misc/ixp4xx-beeper.c.ori  2007-05-10 07:59:56.0 
+0200
+++ drivers/input/misc/ixp4xx-beeper.c  2007-05-10 08:00:53.0 +0200
@@ -51,7 +51,7 @@
 
 static int ixp4xx_spkr_event(struct input_dev *dev, unsigned int type, 
unsigned int code, int value)
 {
-   unsigned int pin = (unsigned int) input_get_drvdata(input_dev);
+   unsigned int pin = (unsigned int) input_get_drvdata(dev);
unsigned int count = 0;
 
if (type != EV_SND)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ixp4xx compile error (was Re: 2.6.21-mm2)

[Frederik Deweerdt]

On Wed, May 09, 2007 at 01:23:22AM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm2/
> 
Hi all,

I've got this compile error while building arm ipx4xx:

  CC [M]  drivers/input/misc/ixp4xx-beeper.o
drivers/input/misc/ixp4xx-beeper.c: In function 'ixp4xx_spkr_event':
drivers/input/misc/ixp4xx-beeper.c:54: error: 'input_dev' undeclared (first use 
in this function)
drivers/input/misc/ixp4xx-beeper.c:54: error: (Each undeclared identifier is 
reported only once
drivers/input/misc/ixp4xx-beeper.c:54: error: for each function it appears in.)
make[3]: *** [drivers/input/misc/ixp4xx-beeper.o] Error 1
make[2]: *** [drivers/input/misc] Error 2
make[1]: *** [drivers/input] Error 2
make: *** [drivers] Error 2

Following patch fixes the problem.

Regards,
Frederik

Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>

--- a/drivers/input/misc/ixp4xx-beeper.c2007-05-10 08:00:53.0 
+0200
+++ b/drivers/input/misc/ixp4xx-beeper.c.ori2007-05-10 07:59:56.0 
+0200
@@ -51,7 +51,7 @@
 
 static int ixp4xx_spkr_event(struct input_dev *dev, unsigned int type, 
unsigned int code, int value)
 {
-   unsigned int pin = (unsigned int) input_get_drvdata(dev);
+   unsigned int pin = (unsigned int) input_get_drvdata(input_dev);
unsigned int count = 0;
 
if (type != EV_SND)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ixp4xx compile error (was Re: 2.6.21-mm2)

[Frederik Deweerdt]

On Wed, May 09, 2007 at 01:23:22AM -0700, Andrew Morton wrote:
 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm2/
 
Hi all,

I've got this compile error while building arm ipx4xx:

  CC [M]  drivers/input/misc/ixp4xx-beeper.o
drivers/input/misc/ixp4xx-beeper.c: In function 'ixp4xx_spkr_event':
drivers/input/misc/ixp4xx-beeper.c:54: error: 'input_dev' undeclared (first use 
in this function)
drivers/input/misc/ixp4xx-beeper.c:54: error: (Each undeclared identifier is 
reported only once
drivers/input/misc/ixp4xx-beeper.c:54: error: for each function it appears in.)
make[3]: *** [drivers/input/misc/ixp4xx-beeper.o] Error 1
make[2]: *** [drivers/input/misc] Error 2
make[1]: *** [drivers/input] Error 2
make: *** [drivers] Error 2

Following patch fixes the problem.

Regards,
Frederik

Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]

--- a/drivers/input/misc/ixp4xx-beeper.c2007-05-10 08:00:53.0 
+0200
+++ b/drivers/input/misc/ixp4xx-beeper.c.ori2007-05-10 07:59:56.0 
+0200
@@ -51,7 +51,7 @@
 
 static int ixp4xx_spkr_event(struct input_dev *dev, unsigned int type, 
unsigned int code, int value)
 {
-   unsigned int pin = (unsigned int) input_get_drvdata(dev);
+   unsigned int pin = (unsigned int) input_get_drvdata(input_dev);
unsigned int count = 0;
 
if (type != EV_SND)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ixp4xx compile error (was Re: 2.6.21-mm2)

[Frederik Deweerdt]

On Thu, May 10, 2007 at 02:21:29PM +0200, Frederik Deweerdt wrote:
 On Wed, May 09, 2007 at 01:23:22AM -0700, Andrew Morton wrote:
  
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm2/
  
 Hi all,
 
 I've got this compile error while building arm ipx4xx:
 
   CC [M]  drivers/input/misc/ixp4xx-beeper.o
 drivers/input/misc/ixp4xx-beeper.c: In function 'ixp4xx_spkr_event':
 drivers/input/misc/ixp4xx-beeper.c:54: error: 'input_dev' undeclared (first 
 use in this function)
 drivers/input/misc/ixp4xx-beeper.c:54: error: (Each undeclared identifier is 
 reported only once
 drivers/input/misc/ixp4xx-beeper.c:54: error: for each function it appears 
 in.)
 make[3]: *** [drivers/input/misc/ixp4xx-beeper.o] Error 1
 make[2]: *** [drivers/input/misc] Error 2
 make[1]: *** [drivers/input] Error 2
 make: *** [drivers] Error 2
 
 Following patch fixes the problem.

Err, got it backwards. Here's the correct fix:

Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]

--- drivers/input/misc/ixp4xx-beeper.c.ori  2007-05-10 07:59:56.0 
+0200
+++ drivers/input/misc/ixp4xx-beeper.c  2007-05-10 08:00:53.0 +0200
@@ -51,7 +51,7 @@
 
 static int ixp4xx_spkr_event(struct input_dev *dev, unsigned int type, 
unsigned int code, int value)
 {
-   unsigned int pin = (unsigned int) input_get_drvdata(input_dev);
+   unsigned int pin = (unsigned int) input_get_drvdata(dev);
unsigned int count = 0;
 
if (type != EV_SND)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kmem_cache_init failure (was Re: 2.6.21-mm1)

[Frederik Deweerdt]

On Wed, May 09, 2007 at 02:26:08PM +0200, Frederik Deweerdt wrote:
> On Wed, May 09, 2007 at 11:00:46AM +0200, Andi Kleen wrote:
> > On Wed, May 09, 2007 at 09:40:24AM +0200, Jan Beulich wrote:
> > > >I've bisected it down to the x86_64-mm-cpa-kerneltext.patch and the 
> > > >
> > > >+   if (!pte_present(*kpte))
> > > >+   return 0;
> > > 
> > > I the most recent version of the patch I sent to Andi this line is gone 
> > > (again),
> > > as I realized it was wrong on i386 (namely for DEBUG_PAGEALLOC) and its
> > > respective variant was superfluous on x86-64.
> > 
> > Yes the version of the patch that went into Linus' tree doesn't have it.
> > Does the problem happen with mainline gitLATEST too?
> Andi,
> 
> Latest git is OK with qemu, I'll test it on a real machine tonight.
It boots fine on a real PC too. Thanks!

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

Re: kmem_cache_init failure (was Re: 2.6.21-mm1)

[Frederik Deweerdt]

On Wed, May 09, 2007 at 11:00:46AM +0200, Andi Kleen wrote:
> On Wed, May 09, 2007 at 09:40:24AM +0200, Jan Beulich wrote:
> > >I've bisected it down to the x86_64-mm-cpa-kerneltext.patch and the 
> > >
> > >+   if (!pte_present(*kpte))
> > >+   return 0;
> > 
> > I the most recent version of the patch I sent to Andi this line is gone 
> > (again),
> > as I realized it was wrong on i386 (namely for DEBUG_PAGEALLOC) and its
> > respective variant was superfluous on x86-64.
> 
> Yes the version of the patch that went into Linus' tree doesn't have it.
> Does the problem happen with mainline gitLATEST too?
Andi,

Latest git is OK with qemu, I'll test it on a real machine tonight.

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

Re: kmem_cache_init failure (was Re: 2.6.21-mm1)

[Frederik Deweerdt]

On Wed, May 09, 2007 at 11:00:46AM +0200, Andi Kleen wrote:
 On Wed, May 09, 2007 at 09:40:24AM +0200, Jan Beulich wrote:
  I've bisected it down to the x86_64-mm-cpa-kerneltext.patch and the 
  
  +   if (!pte_present(*kpte))
  +   return 0;
  
  I the most recent version of the patch I sent to Andi this line is gone 
  (again),
  as I realized it was wrong on i386 (namely for DEBUG_PAGEALLOC) and its
  respective variant was superfluous on x86-64.
 
 Yes the version of the patch that went into Linus' tree doesn't have it.
 Does the problem happen with mainline gitLATEST too?
Andi,

Latest git is OK with qemu, I'll test it on a real machine tonight.

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

Re: kmem_cache_init failure (was Re: 2.6.21-mm1)

[Frederik Deweerdt]

On Wed, May 09, 2007 at 02:26:08PM +0200, Frederik Deweerdt wrote:
 On Wed, May 09, 2007 at 11:00:46AM +0200, Andi Kleen wrote:
  On Wed, May 09, 2007 at 09:40:24AM +0200, Jan Beulich wrote:
   I've bisected it down to the x86_64-mm-cpa-kerneltext.patch and the 
   
   +   if (!pte_present(*kpte))
   +   return 0;
   
   I the most recent version of the patch I sent to Andi this line is gone 
   (again),
   as I realized it was wrong on i386 (namely for DEBUG_PAGEALLOC) and its
   respective variant was superfluous on x86-64.
  
  Yes the version of the patch that went into Linus' tree doesn't have it.
  Does the problem happen with mainline gitLATEST too?
 Andi,
 
 Latest git is OK with qemu, I'll test it on a real machine tonight.
It boots fine on a real PC too. Thanks!

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

Re: kmem_cache_init failure (was Re: 2.6.21-mm1)

[Frederik Deweerdt]

On Wed, May 09, 2007 at 12:12:29AM +0200, Andi Kleen wrote:
> On Tue, May 08, 2007 at 07:22:33PM +0200, Frederik Deweerdt wrote:
> > On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
> > > 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
> > > 
> > Hi all,
> > 
> > My computer fails early at boot with a stack along the lines of:
> 
> Do you have a full oops (.jpg or serial)? 
Yup, I've uploaded the .jpg at http://fdeweerdt.free.fr/kmem_prob/
The faulty address is missing from the shot, but it's %edi+0xc

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

kmem_cache_init failure (was Re: 2.6.21-mm1)

[Frederik Deweerdt]

On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
> 
Hi all,

My computer fails early at boot with a stack along the lines of:

kmem_cache_zalloc
kmem_cache_create
kmem_cache_init
start_kernel

eip is at cache_calloc_refill+0x3e1 which is the 
slabp->colouroff = colouroff; in alloc_slabmgmt()

I've bisected it down to the x86_64-mm-cpa-kerneltext.patch and the 

+   if (!pte_present(*kpte))
+   return 0;

part in particular. Dotconfig and cpuinfo are available at
http://fdeweerdt.free.fr/kmem_prob/.  Any ideas?

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

kmem_cache_init failure (was Re: 2.6.21-mm1)

[Frederik Deweerdt]

On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
 
Hi all,

My computer fails early at boot with a stack along the lines of:

kmem_cache_zalloc
kmem_cache_create
kmem_cache_init
start_kernel

eip is at cache_calloc_refill+0x3e1 which is the 
slabp-colouroff = colouroff; in alloc_slabmgmt()

I've bisected it down to the x86_64-mm-cpa-kerneltext.patch and the 

+   if (!pte_present(*kpte))
+   return 0;

part in particular. Dotconfig and cpuinfo are available at
http://fdeweerdt.free.fr/kmem_prob/.  Any ideas?

Regards,
Frederik
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kmem_cache_init failure (was Re: 2.6.21-mm1)

[Frederik Deweerdt]

On Wed, May 09, 2007 at 12:12:29AM +0200, Andi Kleen wrote:
 On Tue, May 08, 2007 at 07:22:33PM +0200, Frederik Deweerdt wrote:
  On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
   
   ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
   
  Hi all,
  
  My computer fails early at boot with a stack along the lines of:
 
 Do you have a full oops (.jpg or serial)? 
Yup, I've uploaded the .jpg at http://fdeweerdt.free.fr/kmem_prob/
The faulty address is missing from the shot, but it's %edi+0xc

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

Re: Strange soft lockup detected message (looks like spin_lock bug in pcnet32)

[Frederik Deweerdt]

On Mon, May 07, 2007 at 10:08:07AM -0400, Lennart Sorensen wrote:
> On Fri, May 04, 2007 at 03:02:36PM -0400, Lennart Sorensen wrote:
> > Well I don't know, but something is going wrong and causing the soft
> > lock up.  I must admit I am surprised if an interrupt can occour while
> > handling an interrupt, but then again maybe that is supposed to be
> > allowed.
> 
> I tried building a kernel where the only change was enabling the spin
> lock debugging.  It doesn't fail, while without spin lock debugging it
> seemed to fail very frequently.  Darn!  I hate when debugging makes hides
> the problem.
Can you try running on another Geode LX system, just to rule out a
hardware problem on you board?

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

Re: Strange soft lockup detected message (looks like spin_lock bug in pcnet32)

[Frederik Deweerdt]

On Mon, May 07, 2007 at 10:08:07AM -0400, Lennart Sorensen wrote:
 On Fri, May 04, 2007 at 03:02:36PM -0400, Lennart Sorensen wrote:
  Well I don't know, but something is going wrong and causing the soft
  lock up.  I must admit I am surprised if an interrupt can occour while
  handling an interrupt, but then again maybe that is supposed to be
  allowed.
 
 I tried building a kernel where the only change was enabling the spin
 lock debugging.  It doesn't fail, while without spin lock debugging it
 seemed to fail very frequently.  Darn!  I hate when debugging makes hides
 the problem.
Can you try running on another Geode LX system, just to rule out a
hardware problem on you board?

Regards,
Frederik
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] get_unmapped_area: remove now unused ret variable (was Re: 2.6.21-mm1)

[Frederik Deweerdt]

On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
> 

mm/mmap.c:1393: warning: unused variable 'ret'

The get_unmapped_area-doesnt-need-hugetlbfs-hacks-anymore.patch and
get_unmapped_area-handles-map_fixed-in-generic-code.patch rendered the ret
variable useless.

Regards,
Frederik

Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>

diff --git a/mm/mmap.c b/mm/mmap.c
index b0f6eb8..fabf7f4 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1390,7 +1390,6 @@ unsigned long
 get_unmapped_area(struct file *file, unsigned long addr, unsigned long len,
unsigned long pgoff, unsigned long flags)
 {
-   unsigned long ret;
unsigned long (*get_area)(struct file *, unsigned long,
  unsigned long, unsigned long, unsigned long);
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] get_unmapped_area: remove now unused ret variable (was Re: 2.6.21-mm1)

[Frederik Deweerdt]

On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
 

mm/mmap.c:1393: warning: unused variable 'ret'

The get_unmapped_area-doesnt-need-hugetlbfs-hacks-anymore.patch and
get_unmapped_area-handles-map_fixed-in-generic-code.patch rendered the ret
variable useless.

Regards,
Frederik

Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]

diff --git a/mm/mmap.c b/mm/mmap.c
index b0f6eb8..fabf7f4 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1390,7 +1390,6 @@ unsigned long
 get_unmapped_area(struct file *file, unsigned long addr, unsigned long len,
unsigned long pgoff, unsigned long flags)
 {
-   unsigned long ret;
unsigned long (*get_area)(struct file *, unsigned long,
  unsigned long, unsigned long, unsigned long);
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] do_revoke error handling (was Re: 2.6.21-mm1)

[Frederik Deweerdt]

On Sun, May 06, 2007 at 12:23:15AM +0300, Pekka J Enberg wrote:
> On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
> > > 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
> > > 
> > fs/revoke.c: In function 'do_revoke':
> > fs/revoke.c:563: warning: 'details.fset' may be used uninitialized in this 
> > function
> > fs/revoke.c:563: warning: 'details.restore_start' may be used uninitialized 
> > in this function
> 
> On Sat, 5 May 2007, Frederik Deweerdt wrote:
> > It seems that we should goto 'out_free_table' if an error happens in
> > the mainloop. Otherwise 'details' is passed to restore_files() without
> > being initialized.
> 
> Good catch. The patch is wrong, though. Wwe must restore the file 
> descriptors in case revoke fails; otherwise we'll leave non-revoked files 
> hanging. The proper fix is to move initialization before the 
> do_each_thread() bit. Care to make a new patch, Frederik?
>
OK, thanks for the explanation. Here it is.
Frederik

Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>

diff --git a/fs/revoke.c b/fs/revoke.c
index 1f2e3ef..86a2842 100644
--- a/fs/revoke.c
+++ b/fs/revoke.c
@@ -597,6 +597,9 @@ static int do_revoke(struct inode *inode, struct file 
*to_exclude)
goto retry;
}
 
+   details.fset = fset;
+   details.restore_start = 0;
+
/*
 * First revoke the descriptors. After we are done, no one can start
 * new operations on them.
@@ -625,9 +628,6 @@ static int do_revoke(struct inode *inode, struct file 
*to_exclude)
if (err)
goto out_restore;
 
-   details.fset = fset;
-   details.restore_start = 0;
-
/*
 * Now, revoke the files for good.
 */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] do_revoke error handling (was Re: 2.6.21-mm1)

[Frederik Deweerdt]

On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
> 
fs/revoke.c: In function 'do_revoke':
fs/revoke.c:563: warning: 'details.fset' may be used uninitialized in this 
function
fs/revoke.c:563: warning: 'details.restore_start' may be used uninitialized in 
this function

It seems that we should goto 'out_free_table' if an error happens in
the mainloop. Otherwise 'details' is passed to restore_files() without
being initialized.

Regards,
Frederik

Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>
diff --git a/fs/revoke.c b/fs/revoke.c
index 1f2e3ef..6ab5223 100644
--- a/fs/revoke.c
+++ b/fs/revoke.c
@@ -611,7 +611,7 @@ static int do_revoke(struct inode *inode, struct file 
*to_exclude)
read_unlock(_lock);
 
if (err)
-   goto out_restore;
+   goto out_free_table;
 
/*
 * Take down shared memory mappings.
@@ -623,7 +623,7 @@ static int do_revoke(struct inode *inode, struct file 
*to_exclude)
 */
err = revoke_break_cow(fset, inode, to_exclude);
if (err)
-   goto out_restore;
+   goto out_free_table;
 
details.fset = fset;
details.restore_start = 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] mutex.h bogus __must_check (was Re: 2.6.21-mm1)

[Frederik Deweerdt]

On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
> 
__must_check was added to mutex_lock_nested() which returns void. This
causes the following warnings:
include/linux/mutex.h:128: warning: 'warn_unused_result' attribute ignored

This was introduced by
broken-out/mutex_lock_interruptible-add-__must_check.patch

Regards,
Frederik

Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>

diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 616500e..85e4225 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -124,8 +124,8 @@ extern void fastcall mutex_lock(struct mutex *lock);
 extern int fastcall mutex_lock_interruptible(struct mutex *lock);
 
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
-extern void __must_check mutex_lock_nested(struct mutex *lock,
-   unsigned int subclass);
+extern void mutex_lock_nested(struct mutex *lock,
+ unsigned int subclass);
 extern int __must_check mutex_lock_interruptible_nested(struct mutex *lock,
unsigned int subclass);
 #else
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] mutex.h bogus __must_check (was Re: 2.6.21-mm1)

[Frederik Deweerdt]

On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
 
__must_check was added to mutex_lock_nested() which returns void. This
causes the following warnings:
include/linux/mutex.h:128: warning: 'warn_unused_result' attribute ignored

This was introduced by
broken-out/mutex_lock_interruptible-add-__must_check.patch

Regards,
Frederik

Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]

diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 616500e..85e4225 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -124,8 +124,8 @@ extern void fastcall mutex_lock(struct mutex *lock);
 extern int fastcall mutex_lock_interruptible(struct mutex *lock);
 
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
-extern void __must_check mutex_lock_nested(struct mutex *lock,
-   unsigned int subclass);
+extern void mutex_lock_nested(struct mutex *lock,
+ unsigned int subclass);
 extern int __must_check mutex_lock_interruptible_nested(struct mutex *lock,
unsigned int subclass);
 #else
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] do_revoke error handling (was Re: 2.6.21-mm1)

[Frederik Deweerdt]

On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
 
fs/revoke.c: In function 'do_revoke':
fs/revoke.c:563: warning: 'details.fset' may be used uninitialized in this 
function
fs/revoke.c:563: warning: 'details.restore_start' may be used uninitialized in 
this function

It seems that we should goto 'out_free_table' if an error happens in
the mainloop. Otherwise 'details' is passed to restore_files() without
being initialized.

Regards,
Frederik

Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]
diff --git a/fs/revoke.c b/fs/revoke.c
index 1f2e3ef..6ab5223 100644
--- a/fs/revoke.c
+++ b/fs/revoke.c
@@ -611,7 +611,7 @@ static int do_revoke(struct inode *inode, struct file 
*to_exclude)
read_unlock(tasklist_lock);
 
if (err)
-   goto out_restore;
+   goto out_free_table;
 
/*
 * Take down shared memory mappings.
@@ -623,7 +623,7 @@ static int do_revoke(struct inode *inode, struct file 
*to_exclude)
 */
err = revoke_break_cow(fset, inode, to_exclude);
if (err)
-   goto out_restore;
+   goto out_free_table;
 
details.fset = fset;
details.restore_start = 0;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] do_revoke error handling (was Re: 2.6.21-mm1)

[Frederik Deweerdt]

On Sun, May 06, 2007 at 12:23:15AM +0300, Pekka J Enberg wrote:
 On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
   
   ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
   
  fs/revoke.c: In function 'do_revoke':
  fs/revoke.c:563: warning: 'details.fset' may be used uninitialized in this 
  function
  fs/revoke.c:563: warning: 'details.restore_start' may be used uninitialized 
  in this function
 
 On Sat, 5 May 2007, Frederik Deweerdt wrote:
  It seems that we should goto 'out_free_table' if an error happens in
  the mainloop. Otherwise 'details' is passed to restore_files() without
  being initialized.
 
 Good catch. The patch is wrong, though. Wwe must restore the file 
 descriptors in case revoke fails; otherwise we'll leave non-revoked files 
 hanging. The proper fix is to move initialization before the 
 do_each_thread() bit. Care to make a new patch, Frederik?

OK, thanks for the explanation. Here it is.
Frederik

Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]

diff --git a/fs/revoke.c b/fs/revoke.c
index 1f2e3ef..86a2842 100644
--- a/fs/revoke.c
+++ b/fs/revoke.c
@@ -597,6 +597,9 @@ static int do_revoke(struct inode *inode, struct file 
*to_exclude)
goto retry;
}
 
+   details.fset = fset;
+   details.restore_start = 0;
+
/*
 * First revoke the descriptors. After we are done, no one can start
 * new operations on them.
@@ -625,9 +628,6 @@ static int do_revoke(struct inode *inode, struct file 
*to_exclude)
if (err)
goto out_restore;
 
-   details.fset = fset;
-   details.restore_start = 0;
-
/*
 * Now, revoke the files for good.
 */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Strange soft lockup detected message (looks like spin_lock bug in pcnet32)

[Frederik Deweerdt]

On Fri, May 04, 2007 at 11:19:34AM -0400, Lennart Sorensen wrote:
> On Fri, May 04, 2007 at 04:33:26PM +0200, Frederik Deweerdt wrote:
> > On Fri, May 04, 2007 at 10:10:24AM -0400, Lennart Sorensen wrote:
> > > On Thu, May 03, 2007 at 04:31:43PM -0400, Lennart Sorensen wrote:
> > [...]
> > > Should line 2563 be a spin_lock_irqsave instead along with the
> > > appropriate unluck later?
> > IIRC, when you enable lockdep, it will complain about spinlocks used in
> > an invalid context.
> 
> What is lockdep and how do I enable it?
For the "what" part, see Documentation/lockdep-design.txt. You'll enable
it by with SPINLOCK_DEBUG, indeed.
> 
> I enabled SPINLOCK_DEBUG and am going to try that kernel now (except it
> hit the bug before I could even log in and install the kernel this time,
> so another reboot first).
> 
> --
> Len Sorensen
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Strange soft lockup detected message (looks like spin_lock bug in pcnet32)

[Frederik Deweerdt]

On Fri, May 04, 2007 at 10:10:24AM -0400, Lennart Sorensen wrote:
> On Thu, May 03, 2007 at 04:31:43PM -0400, Lennart Sorensen wrote:
[...]
> Should line 2563 be a spin_lock_irqsave instead along with the
> appropriate unluck later?
IIRC, when you enable lockdep, it will complain about spinlocks used in
an invalid context.

Regards,
Frederik
> 
> --
> Len Sorensen
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Strange soft lockup detected message (looks like spin_lock bug in pcnet32)

[Frederik Deweerdt]

On Fri, May 04, 2007 at 10:10:24AM -0400, Lennart Sorensen wrote:
 On Thu, May 03, 2007 at 04:31:43PM -0400, Lennart Sorensen wrote:
[...]
 Should line 2563 be a spin_lock_irqsave instead along with the
 appropriate unluck later?
IIRC, when you enable lockdep, it will complain about spinlocks used in
an invalid context.

Regards,
Frederik
 
 --
 Len Sorensen
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Strange soft lockup detected message (looks like spin_lock bug in pcnet32)

[Frederik Deweerdt]

On Fri, May 04, 2007 at 11:19:34AM -0400, Lennart Sorensen wrote:
 On Fri, May 04, 2007 at 04:33:26PM +0200, Frederik Deweerdt wrote:
  On Fri, May 04, 2007 at 10:10:24AM -0400, Lennart Sorensen wrote:
   On Thu, May 03, 2007 at 04:31:43PM -0400, Lennart Sorensen wrote:
  [...]
   Should line 2563 be a spin_lock_irqsave instead along with the
   appropriate unluck later?
  IIRC, when you enable lockdep, it will complain about spinlocks used in
  an invalid context.
 
 What is lockdep and how do I enable it?
For the what part, see Documentation/lockdep-design.txt. You'll enable
it by with SPINLOCK_DEBUG, indeed.
 
 I enabled SPINLOCK_DEBUG and am going to try that kernel now (except it
 hit the bug before I could even log in and install the kernel this time,
 so another reboot first).
 
 --
 Len Sorensen
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.21 - something wrong with dmesg.

[Frederik Deweerdt]

On Thu, Apr 26, 2007 at 05:44:40PM +0530, Sunil Naidu wrote:
> Hello,
> 
> I did compile the kernel, boots good ;-) BTW, does anyone (on P-III)
> facing a memory check skip or sort of? Not getting RAM info in the
> dmesg.  Unable to get dmseg from the start of the gcc check! Any clue?
> Here is the dmesg I get on my box:
Don't you need to increase CONFIG_LOG_BUF_SHIFT ?
Regards,
Frederik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.21 - something wrong with dmesg.

[Frederik Deweerdt]

On Thu, Apr 26, 2007 at 05:44:40PM +0530, Sunil Naidu wrote:
 Hello,
 
 I did compile the kernel, boots good ;-) BTW, does anyone (on P-III)
 facing a memory check skip or sort of? Not getting RAM info in the
 dmesg.  Unable to get dmseg from the start of the gcc check! Any clue?
 Here is the dmesg I get on my box:
Don't you need to increase CONFIG_LOG_BUF_SHIFT ?
Regards,
Frederik
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] pcm_native: lockdep warning when launching jack

[Frederik Deweerdt]

On Mon, Apr 02, 2007 at 10:47:45PM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm4/
> 
Hi,

When launching "jackd -d alsa", lockdep issues the following warning:
[39701.405086] =
[39701.405093] [ INFO: possible recursive locking detected ]
[39701.405107] 2.6.21-rc5-mm4 #2
[39701.405109] -
[39701.405112] jackd/17366 is trying to acquire lock:
[39701.405114]  (>self_group.lock){}, at: [] 
snd_pcm_action_group+0x90/0x240
[39701.405131]
[39701.405131] but task is already holding lock:
[39701.405134]  (>self_group.lock){}, at: [] 
snd_pcm_action_lock_irq+0x3f/0xb0
[39701.405141]
[39701.405142] other info that might help us debug this:
[39701.405145] 3 locks held by jackd/17366:
[39701.405147]  #0:  (snd_pcm_link_rwlock){}, at: [] 
snd_pcm_action_lock_irq+0x27/0xb0
[39701.405155]  #1:  (>group->lock){}, at: [] 
snd_pcm_action_lock_irq+0x38/0xb0
[39701.405163]  #2:  (>self_group.lock){}, at: [] 
snd_pcm_action_lock_irq+0x3f/0xb0
[39701.405171]
[39701.405171] stack backtrace:
[39701.405174]  [] show_trace_log_lvl+0x1a/0x30
[39701.405179]  [] show_trace+0x12/0x20
[39701.405183]  [] dump_stack+0x16/0x20
[39701.405187]  [] __lock_acquire+0xbd0/0x1040
[39701.405193]  [] lock_acquire+0x70/0x90
[39701.405197]  [] _spin_lock+0x36/0x50
[39701.405203]  [] snd_pcm_action_group+0x90/0x240
[39701.405207]  [] snd_pcm_action_lock_irq+0x53/0xb0
[39701.405211]  [] snd_pcm_common_ioctl1+0x35f/0xfb0
[39701.405215]  [] snd_pcm_playback_ioctl1+0x34/0x420
[39701.405219]  [] snd_pcm_playback_ioctl+0x43/0x50
[39701.405223]  [] do_ioctl+0x28/0x80
[39701.405229]  [] vfs_ioctl+0x57/0x290
[39701.405233]  [] sys_ioctl+0x39/0x60
[39701.405237]  [] sysenter_past_esp+0x5d/0x99
[39701.405240]  ===

The attached lockdep annotation silences the warning.
Regards,
Frederik

Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>

--- 2.6.21-rc5-mm3/sound/core/pcm_native.c  2007-03-30 21:41:18.0 
+0200
+++ 2.6.21-rc5-mm4/sound/core/pcm_native.c  2007-04-05 15:01:19.0 
+0200
@@ -718,7 +718,8 @@ static int snd_pcm_action_group(struct a
 
snd_pcm_group_for_each_entry(s, substream) {
if (do_lock && s != substream)
-   spin_lock(>self_group.lock);
+   spin_lock_nested(>self_group.lock,
+SINGLE_DEPTH_NESTING);
res = ops->pre_action(s, state);
if (res < 0)
goto _unlock;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] pcm_native: lockdep warning when launching jack

[Frederik Deweerdt]

On Mon, Apr 02, 2007 at 10:47:45PM -0700, Andrew Morton wrote:
 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm4/
 
Hi,

When launching jackd -d alsa, lockdep issues the following warning:
[39701.405086] =
[39701.405093] [ INFO: possible recursive locking detected ]
[39701.405107] 2.6.21-rc5-mm4 #2
[39701.405109] -
[39701.405112] jackd/17366 is trying to acquire lock:
[39701.405114]  (substream-self_group.lock){}, at: [c034d3c0] 
snd_pcm_action_group+0x90/0x240
[39701.405131]
[39701.405131] but task is already holding lock:
[39701.405134]  (substream-self_group.lock){}, at: [c034d63f] 
snd_pcm_action_lock_irq+0x3f/0xb0
[39701.405141]
[39701.405142] other info that might help us debug this:
[39701.405145] 3 locks held by jackd/17366:
[39701.405147]  #0:  (snd_pcm_link_rwlock){}, at: [c034d627] 
snd_pcm_action_lock_irq+0x27/0xb0
[39701.405155]  #1:  (substream-group-lock){}, at: [c034d638] 
snd_pcm_action_lock_irq+0x38/0xb0
[39701.405163]  #2:  (substream-self_group.lock){}, at: [c034d63f] 
snd_pcm_action_lock_irq+0x3f/0xb0
[39701.405171]
[39701.405171] stack backtrace:
[39701.405174]  [c0103b8a] show_trace_log_lvl+0x1a/0x30
[39701.405179]  [c0104912] show_trace+0x12/0x20
[39701.405183]  [c01049c6] dump_stack+0x16/0x20
[39701.405187]  [c013b980] __lock_acquire+0xbd0/0x1040
[39701.405193]  [c013be60] lock_acquire+0x70/0x90
[39701.405197]  [c0407846] _spin_lock+0x36/0x50
[39701.405203]  [c034d3c0] snd_pcm_action_group+0x90/0x240
[39701.405207]  [c034d653] snd_pcm_action_lock_irq+0x53/0xb0
[39701.405211]  [c035046f] snd_pcm_common_ioctl1+0x35f/0xfb0
[39701.405215]  [c0351544] snd_pcm_playback_ioctl1+0x34/0x420
[39701.405219]  [c03519f3] snd_pcm_playback_ioctl+0x43/0x50
[39701.405223]  [c017ecc8] do_ioctl+0x28/0x80
[39701.405229]  [c017ed77] vfs_ioctl+0x57/0x290
[39701.405233]  [c017efe9] sys_ioctl+0x39/0x60
[39701.405237]  [c0102bf4] sysenter_past_esp+0x5d/0x99
[39701.405240]  ===

The attached lockdep annotation silences the warning.
Regards,
Frederik

Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]

--- 2.6.21-rc5-mm3/sound/core/pcm_native.c  2007-03-30 21:41:18.0 
+0200
+++ 2.6.21-rc5-mm4/sound/core/pcm_native.c  2007-04-05 15:01:19.0 
+0200
@@ -718,7 +718,8 @@ static int snd_pcm_action_group(struct a
 
snd_pcm_group_for_each_entry(s, substream) {
if (do_lock  s != substream)
-   spin_lock(s-self_group.lock);
+   spin_lock_nested(s-self_group.lock,
+SINGLE_DEPTH_NESTING);
res = ops-pre_action(s, state);
if (res  0)
goto _unlock;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ipw2200: can't load firmware (was Re: 2.6.21-rc3-mm1)

[Frederik Deweerdt]

On Fri, Mar 09, 2007 at 11:40:43AM +, Frederik Deweerdt wrote:
> On Wed, Mar 07, 2007 at 08:18:39PM -0800, Andrew Morton wrote:
> > - The wireless changes in here need a lot of testers, please.  It is major
> >   rework.
> [...]
> >   I was able to get ipw2200 working after some fumbling,
> Any details on the symptoms? I'm unable to boot rc3-mm2, and it hangs
> right after printing the ipw2200 driver message. I'll investigate that
> this week-end.
Sorry for the delay, I could give it a try today. It appears
that it doesn't hang, it just spends a lot of time in
ipw_init:pci_register_driver, due to a firmware loading failure

[   12.296637] RAMDISK driver initialized: 16 RAM disks of 32000K size 1024 
blocksize
[   12.322581] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 
1.2.0kdmprq
[   12.348822] ipw2200: Copyright(c) 2003-2006 Intel Corporation
[   12.366936] PCI: Found IRQ 10 for device :03:03.0
[   12.376280] PCI: Sharing IRQ 10 with :00:1d.1
[   12.385729] PCI: Sharing IRQ 10 with :00:1e.3
[   12.395134] PCI: Sharing IRQ 10 with :00:1f.2
[   12.404385] ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection
[   72.391870] ipw2200: ipw2200-bss.fw request_firmware failed: Reason -2
[   72.400563] ipw2200: Unable to load firmware: -2
[   72.408956] ipw2200: failed to register network device
[   72.417178] ipw2200: probe of :03:03.0 failed with error -5

(Booted with acpi=off due to some framebuffer problems mangling the
console output, but the problem persists even without that kernel
parameter)

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

ipw2200: can't load firmware (was Re: 2.6.21-rc3-mm1)

[Frederik Deweerdt]

On Fri, Mar 09, 2007 at 11:40:43AM +, Frederik Deweerdt wrote:
 On Wed, Mar 07, 2007 at 08:18:39PM -0800, Andrew Morton wrote:
  - The wireless changes in here need a lot of testers, please.  It is major
rework.
 [...]
I was able to get ipw2200 working after some fumbling,
 Any details on the symptoms? I'm unable to boot rc3-mm2, and it hangs
 right after printing the ipw2200 driver message. I'll investigate that
 this week-end.
Sorry for the delay, I could give it a try today. It appears
that it doesn't hang, it just spends a lot of time in
ipw_init:pci_register_driver, due to a firmware loading failure

[   12.296637] RAMDISK driver initialized: 16 RAM disks of 32000K size 1024 
blocksize
[   12.322581] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 
1.2.0kdmprq
[   12.348822] ipw2200: Copyright(c) 2003-2006 Intel Corporation
[   12.366936] PCI: Found IRQ 10 for device :03:03.0
[   12.376280] PCI: Sharing IRQ 10 with :00:1d.1
[   12.385729] PCI: Sharing IRQ 10 with :00:1e.3
[   12.395134] PCI: Sharing IRQ 10 with :00:1f.2
[   12.404385] ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection
[   72.391870] ipw2200: ipw2200-bss.fw request_firmware failed: Reason -2
[   72.400563] ipw2200: Unable to load firmware: -2
[   72.408956] ipw2200: failed to register network device
[   72.417178] ipw2200: probe of :03:03.0 failed with error -5

(Booted with acpi=off due to some framebuffer problems mangling the
console output, but the problem persists even without that kernel
parameter)

Regards,
Frederik
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/