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

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

Today's topics:

* markup_oops.pl: add options to improve cross-sompilation environments - 4
messages, 3 authors
http://groups.google.com/group/linux.kernel/t/a94bf88dc8c7132f?hl=en
* sched: cpuacct: Use bigger percpu counter batch values for stats counters -
1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/bfd515678506951b?hl=en
* cgroups: Clean up cgroup_pidlist_find() a bit - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/8b21c2e980405fc9?hl=en
* cgroups: Fix to return errno in a failure path - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3427ea829aa08fad?hl=en
* kgdb,clocksource: Prevent kernel hang in kernel debugger - 3 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/9346e7852bd8475c?hl=en
* RFC: make struct platform_driver.id_table const - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/213e1f267bc227c8?hl=en
* futex() on vdso makes process unkillable - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/771496d6192e598e?hl=en
* mfd: fix asic3 build - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a9ed0abbdedb8720?hl=en
* starting emacs makes lockdep warning - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/b92a5fcdc20fcbff?hl=en
* move acornfb's probe function to .devinit.text - 3 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7db9be36a46d6f4f?hl=en
* acpi_idle: Very idle Core i7 machine never enters C3 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1565d34d7e04b9c7?hl=en
* drivers/net/ariadne.c:165: error: 'set_multicast_list' undeclared here (not
in a function) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/6ca1e9867f4201ee?hl=en
* OOM-Killer kills too much with 2.6.32.2 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3f7afc452c078f22?hl=en
* x86, mce: Rename cpu_specific_poll to mce_cpu_specific_poll - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/fc4cba69013002ea?hl=en
* perf_events: improve x86 event scheduling (v6 incremental) - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/bbf8b18737c02762?hl=en
* netperf ~50% regression with 2.6.33-rc1, bisect to 1b9508f - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/39c3736e4627488a?hl=en
* : Sparc - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f43dd9e158765728?hl=en

==============================================================================
TOPIC: markup_oops.pl: add options to improve cross-sompilation environments
http://groups.google.com/group/linux.kernel/t/a94bf88dc8c7132f?hl=en
==============================================================================

== 1 of 4 ==
Date: Tues, Jan 26 2010 12:00 am
From: Américo Wang

On Tue, Jan 26, 2010 at 3:38 PM, Hui Zhu <hui.zhu@windriver.com> wrote:
> Américo Wang:
>>
>> On Tue, Jan 26, 2010 at 11:11 AM, Hui Zhu <hui.zhu@windriver.com> wrote:
>>>
>>> Sorry guys, the prev mail still have some format trouble. I send a new
>>> mail
>>> for it.
>>> +}
>>> +
>>> +if ($vmlinux_name ne "") {
>>> + $vmlinux_name = $ARGV[$#ARGV];
>>> +}
>>
>> Why not using the Perl module 'Getopt' to do this?
>>
> Hi Américo,
>
> Thanks for remind me about it. The following patch use Getopt.
>
> The markup_oops.pl have 3 troubles to support cross-compiler environment:
> 1. It use objdump directly.
> 2. It use modinfo to get the message of module.
> 3. It use hex function that cannot support 64-bit number in 32-bit arch.
>
> This patch add 3 options to markup_oops.pl:
> 1. -c CROSS_COMPILE Specify the prefix used for toolchain.
> 2. -m MODULE_DIRNAME Specify the module directory name.
> 3. Change hex function to Math::BigInt->from_hex.
>
> After this patch, parse the x8664 oops in x86, we can:
> cat amd64m | perl ~/kernel/tmp/m.pl -c /home/teawater/kernel/bin/x8664- -m
> ./e.ko vmlinux
>
> Thanks,
> Hui
>
> Signed-off-by: Hui Zhu <teawater@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Arjan van de Ven <arjan@linux.intel.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: ozan@pardus.org.tr
> Cc: Matthew Wilcox <willy@linux.intel.com>
>
> ---
> scripts/markup_oops.pl | 45 +++++++++++++++++++++++++++++++++++----------
> 1 file changed, 35 insertions(+), 10 deletions(-)
>
> --- a/scripts/markup_oops.pl
> +++ b/scripts/markup_oops.pl
> @@ -2,6 +2,7 @@
>
> use File::Basename;
> use Math::BigInt;
> +use Getopt::Long;
>
> # Copyright 2008, Intel Corporation
> #
> @@ -15,7 +16,17 @@ use Math::BigInt;
> # Arjan van de Ven <arjan@linux.intel.com>
>
>
> -my $vmlinux_name = $ARGV[0];
> +my $cross_compile = "";
> +my $vmlinux_name = "";
> +my $modulefile = "";
> +
> +# Get options
> +Getopt::Long::GetOptions(
> + 'cross_compile|c=s' => \$cross_compile,

Please make it "cross-compile", because underline is not common
in command line, so "--cross_compile" is worse than "--cross-compile".

> + 'modulefile|m=s' => \$modulefile,

"module" should be enough to express the meaning, I think.

> + 'help|h' => \&usage,
> +);
> +my $vmlinux_name = $ARGV[$#ARGV];
> if (!defined($vmlinux_name)) {
> my $kerver = `uname -r`;
> chomp($kerver);
> @@ -23,6 +34,7 @@ if (!defined($vmlinux_name)) {
> print "No vmlinux specified, assuming $vmlinux_name\n";
> }
> my $filename = $vmlinux_name;
> +

Adding this empty line probably is not what you really want.

> #
> # Step 1: Parse the oops to find the EIP value
> #

{snip}

>
> +sub usage {
> + print <<EOT;
> +Usage:
> + dmesg | perl $0 [OPTION] [VMLINUX]
> +
> +OPTION:
> + -c, -cross_compile CROSS_COMPILE Specify the prefix used for
> toolchain.
> + -m, -modulefile MODULE_DIRNAME Specify the module directory name.
> + -h, -help Help.
> +EOT
> + exit;
> +}
> +

GNU style is preferred here, please use "--foo" instead of "-foo".

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

== 2 of 4 ==
Date: Tues, Jan 26 2010 1:10 am
From: Hui Zhu

Hi Américo,

Thanks for your mail.

Américo Wang:
>
>
> "module" should be enough to express the meaning, I think.
>
>
>> + 'help|h' => \&usage,
>> +);
>> +my $vmlinux_name = $ARGV[$#ARGV];
>> if (!defined($vmlinux_name)) {
>> my $kerver = `uname -r`;
>> chomp($kerver);
>> @@ -23,6 +34,7 @@ if (!defined($vmlinux_name)) {
>> print "No vmlinux specified, assuming $vmlinux_name\n";
>> }
>> my $filename = $vmlinux_name;
>> +
>
>
> Adding this empty line probably is not what you really want.
>
>> #
>> # Step 1: Parse the oops to find the EIP value
>> #
>
> {snip}
>

About this part, the code before "Parse the oops to find the EIP value" is for "Get options".
I change this part to:
my $filename = $vmlinux_name;
-#
-# Step 1: Parse the oops to find the EIP value
-#
+
+# Parse the oops to find the EIP value

What do you think about it?

And I changed the other part according to your mail.

Best regards,
Hui

The markup_oops.pl have 3 troubles to support cross-compiler environment:
1. It use objdump directly.
2. It use modinfo to get the message of module.
3. It use hex function that cannot support 64-bit number in 32-bit arch.

This patch add 3 options to markup_oops.pl:
1. -c CROSS_COMPILE Specify the prefix used for toolchain.
2. -m MODULE_DIRNAME Specify the module directory name.
3. Change hex function to Math::BigInt->from_hex.

After this patch, parse the x8664 oops in x86, we can:
cat amd64m | perl ~/kernel/tmp/m.pl -c /home/teawater/kernel/bin/x8664- -m ./e.ko vmlinux

Thanks,
Hui

Signed-off-by: Hui Zhu <teawater@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: ozan@pardus.org.tr
Cc: Matthew Wilcox <willy@linux.intel.com>

---
scripts/markup_oops.pl | 49 ++++++++++++++++++++++++++++++++++++-------------
1 file changed, 36 insertions(+), 13 deletions(-)

--- a/scripts/markup_oops.pl
+++ b/scripts/markup_oops.pl
@@ -2,6 +2,7 @@

use File::Basename;
use Math::BigInt;
+use Getopt::Long;

# Copyright 2008, Intel Corporation
#
@@ -15,7 +16,17 @@ use Math::BigInt;
# Arjan van de Ven <arjan@linux.intel.com>

-my $vmlinux_name = $ARGV[0];
+my $cross_compile = "";
+my $vmlinux_name = "";
+my $modulefile = "";
+
+# Get options
+Getopt::Long::GetOptions(
+ 'cross-compile|c=s' => \$cross_compile,
+ 'module|m=s' => \$modulefile,
+ 'help|h' => \&usage,
+);
+my $vmlinux_name = $ARGV[$#ARGV];
if (!defined($vmlinux_name)) {
my $kerver = `uname -r`;
chomp($kerver);
@@ -23,9 +34,8 @@ if (!defined($vmlinux_name)) {
print "No vmlinux specified, assuming $vmlinux_name\n";
}
my $filename = $vmlinux_name;
-#
-# Step 1: Parse the oops to find the EIP value
-#
+
+# Parse the oops to find the EIP value

my $target = "0";
my $function;
@@ -177,26 +187,26 @@ my $decodestart = Math::BigInt->from_hex
my $decodestop = Math::BigInt->from_hex("0x$target") + 8192;
if ($target eq "0") {
print "No oops found!\n";
- print "Usage: \n";
- print " dmesg | perl scripts/markup_oops.pl vmlinux\n";
- exit;
+ usage();
}

# if it's a module, we need to find the .ko file and calculate a load offset
if ($module ne "") {
- my $modulefile = `modinfo $module | grep '^filename:' | awk '{ print \$2 }'`;
- chomp($modulefile);
+ if ($modulefile eq "") {
+ my $modulefile = `modinfo $module | grep '^filename:' | awk '{ print \$2 }'`;
+ chomp($modulefile);
+ }
$filename = $modulefile;
if ($filename eq "") {
print "Module .ko file for $module not found. Aborting\n";
exit;
}
# ok so we found the module, now we need to calculate the vma offset
- open(FILE, "objdump -dS $filename |") || die "Cannot start objdump";
+ open(FILE, $cross_compile."objdump -dS $filename |") || die "Cannot start objdump";
while (<FILE>) {
if ($_ =~ /^([0-9a-f]+) \<$function\>\:/) {
my $fu = $1;
- $vmaoffset = hex($target) - hex($fu) - hex($func_offset);
+ $vmaoffset = Math::BigInt->from_hex("0x$target") - Math::BigInt->from_hex("0x$fu") - Math::BigInt->from_hex("0x$func_offset");
}
}
close(FILE);
@@ -212,7 +222,7 @@ sub InRange {
my ($address, $target) = @_;
my $ad = "0x".$address;
my $ta = "0x".$target;
- my $delta = hex($ad) - hex($ta);
+ my $delta = Math::BigInt->from_hex($ad) - Math::BigInt->from_hex($ta);

if (($delta > -4096) && ($delta < 4096)) {
return 1;
@@ -225,7 +235,7 @@ sub InRange {
# first, parse the input into the lines array, but to keep size down,
# we only do this for 4Kb around the sweet spot

-open(FILE, "objdump -dS --adjust-vma=$vmaoffset --start-address=$decodestart --stop-address=$decodestop $filename |") || die "Cannot start objdump";
+open(FILE, $cross_compile."objdump -dS --adjust-vma=$vmaoffset --start-address=$decodestart --stop-address=$decodestop $filename |") || die "Cannot start objdump";

while (<FILE>) {
my $line = $_;
@@ -344,3 +354,16 @@ while ($i < $finish) {
$i = $i +1;
}

+sub usage {
+ print <<EOT;
+Usage:
+ dmesg | perl $0 [OPTION] [VMLINUX]
+
+OPTION:
+ -c, --cross-compile CROSS_COMPILE Specify the prefix used for toolchain.
+ -m, --module MODULE_DIRNAME Specify the module directory name.
+ -h, --help Help.
+EOT
+ exit;
+}
+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 3 of 4 ==
Date: Tues, Jan 26 2010 1:20 am
From: Américo Wang

On Tue, Jan 26, 2010 at 5:13 PM, Hui Zhu <hui.zhu@windriver.com> wrote:
>
> What do you think about it?
>
> And I changed the other part according to your mail.

It looks fine for me now, I assume you already tested it.

>
> Best regards,
> Hui
>
> The markup_oops.pl have 3 troubles to support cross-compiler environment:
> 1. It use objdump directly.
> 2. It use modinfo to get the message of module.
> 3. It use hex function that cannot support 64-bit number in 32-bit arch.
>
> This patch add 3 options to markup_oops.pl:
> 1. -c CROSS_COMPILE Specify the prefix used for toolchain.
> 2. -m MODULE_DIRNAME Specify the module directory name.
> 3. Change hex function to Math::BigInt->from_hex.
>
> After this patch, parse the x8664 oops in x86, we can:
> cat amd64m | perl ~/kernel/tmp/m.pl -c /home/teawater/kernel/bin/x8664- -m
> ./e.ko vmlinux
>
> Thanks,
> Hui
>
> Signed-off-by: Hui Zhu <teawater@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Arjan van de Ven <arjan@linux.intel.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: ozan@pardus.org.tr
> Cc: Matthew Wilcox <willy@linux.intel.com>
>

Acked-by: WANG Cong <xiyou.wangcong@gmail.com>

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

== 4 of 4 ==
Date: Tues, Jan 26 2010 1:30 am
From: Hui Zhu

Hi Américo,

On Tue, Jan 26, 2010 at 17:15, Américo Wang <xiyou.wangcong@gmail.com> wrote:
> On Tue, Jan 26, 2010 at 5:13 PM, Hui Zhu <hui.zhu@windriver.com> wrote:
>>
>> What do you think about it?
>>
>> And I changed the other part according to your mail.
>
>
> It looks fine for me now, I assume you already tested it.

It was tested. :)

>
>
>>
>> Best regards,
>> Hui
>>
>> The markup_oops.pl have 3 troubles to support cross-compiler environment:
>> 1. It use objdump directly.
>> 2. It use modinfo to get the message of module.
>> 3. It use hex function that cannot support 64-bit number in 32-bit arch.
>>
>> This patch add 3 options to markup_oops.pl:
>> 1. -c CROSS_COMPILE Specify the prefix used for toolchain.
>> 2. -m MODULE_DIRNAME Specify the module directory name.
>> 3. Change hex function to Math::BigInt->from_hex.
>>
>> After this patch, parse the x8664 oops in x86, we can:
>> cat amd64m | perl ~/kernel/tmp/m.pl -c /home/teawater/kernel/bin/x8664- -m
>> ./e.ko vmlinux
>>
>> Thanks,
>> Hui
>>
>> Signed-off-by: Hui Zhu <teawater@gmail.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: Arjan van de Ven <arjan@linux.intel.com>
>> Cc: Sam Ravnborg <sam@ravnborg.org>
>> Cc: ozan@pardus.org.tr
>> Cc: Matthew Wilcox <willy@linux.intel.com>
>>
>
> Acked-by: WANG Cong <xiyou.wangcong@gmail.com>
>

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

==============================================================================
TOPIC: sched: cpuacct: Use bigger percpu counter batch values for stats
counters
http://groups.google.com/group/linux.kernel/t/bfd515678506951b?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 12:20 am
From: Anton Blanchard

Hi Andrew,

> > I guess a lot of the changelog and comments are in the email history,
>
> Not a very useful location for it!

Good point, I'll work on a useful comment.

> > Why does it look quite wrong to you?
>
> Because it computes the correct value and then if it's larger than
> INT_MAX, it inexplicably assigns INT_MAX to it, giving a wrong result!
>
> Does that code actually work, btw? percpu_counter_batch has type `int'
> and cputime_one_jiffy has type `int' so their product has type `int'.
> So by the time min_t performs its comparison, the upper 32 bits of the
> product are already lost.

On ppc64, s390 and ia64 cputime_one_jiffy is 64bit and I want to prevent us
creating too large a batch value:

void __percpu_counter_add(struct percpu_counter *fbc, s64 amount, s32 batch)

If we pass in something bigger than INT_MAX we could end up with 0 after
truncation which will turn the percpu counter into a single spinlock global
counter.

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

==============================================================================
TOPIC: cgroups: Clean up cgroup_pidlist_find() a bit
http://groups.google.com/group/linux.kernel/t/8b21c2e980405fc9?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 12:20 am
From: Li Zefan

Don't Call get_pid_ns() before we locate/alloc the ns.

Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
---
cgroup.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)

--- a/kernel/cgroup.c.orig 2010-01-26 14:24:29.000000000 +0800
+++ a/kernel/cgroup.c 2010-01-26 14:24:44.000000000 +0800
@@ -2643,7 +2643,8 @@ static struct cgroup_pidlist *cgroup_pid
{
struct cgroup_pidlist *l;
/* don't need task_nsproxy() if we're looking at ourself */
- struct pid_namespace *ns = get_pid_ns(current->nsproxy->pid_ns);
+ struct pid_namespace *ns = current->nsproxy->pid_ns;
+
/*
* We can't drop the pidlist_mutex before taking the l->mutex in case
* the last ref-holder is trying to remove l from the list at the same
@@ -2653,8 +2654,6 @@ static struct cgroup_pidlist *cgroup_pid
mutex_lock(&cgrp->pidlist_mutex);
list_for_each_entry(l, &cgrp->pidlists, links) {
if (l->key.type == type && l->key.ns == ns) {
- /* found a matching list - drop the extra refcount */
- put_pid_ns(ns);
/* make sure l doesn't vanish out from under us */
down_write(&l->mutex);
mutex_unlock(&cgrp->pidlist_mutex);
@@ -2665,13 +2664,12 @@ static struct cgroup_pidlist *cgroup_pid
l = kmalloc(sizeof(struct cgroup_pidlist), GFP_KERNEL);
if (!l) {
mutex_unlock(&cgrp->pidlist_mutex);
- put_pid_ns(ns);
return l;
}
init_rwsem(&l->mutex);
down_write(&l->mutex);
l->key.type = type;
- l->key.ns = ns;
+ l->key.ns = get_pid_ns(ns);
l->use_count = 0; /* don't increment here */
l->list = NULL;
l->owner = cgrp;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: cgroups: Fix to return errno in a failure path
http://groups.google.com/group/linux.kernel/t/3427ea829aa08fad?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 12:20 am
From: Li Zefan

In cgroup_create(), if alloc_css_id() returns failure, the errno
is not propagated to userspace, so mkdir will fail silently.

To trigger this bug, we mount blkio (or memory subsystem), and
create more then 65534 cgroups. (The number of cgroups is limited
to 65535 if a subsystem has use_id == 1)

# mount -t cgroup -o blkio xxx /mnt
# for ((i = 0; i < 65534; i++)); do mkdir /mnt/$i; done
# mkdir /mnt/65534
(should return ENOSPC)
#

Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
---
cgroup.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

--- a/kernel/cgroup.c.orig 2010-01-19 16:37:37.000000000 +0800
+++ a/kernel/cgroup.c 2010-01-19 16:39:07.000000000 +0800
@@ -3279,14 +3279,17 @@ static long cgroup_create(struct cgroup

for_each_subsys(root, ss) {
struct cgroup_subsys_state *css = ss->create(ss, cgrp);
+
if (IS_ERR(css)) {
err = PTR_ERR(css);
goto err_destroy;
}
init_cgroup_css(css, ss, cgrp);
- if (ss->use_id)
- if (alloc_css_id(ss, parent, cgrp))
+ if (ss->use_id) {
+ err = alloc_css_id(ss, parent, cgrp);
+ if (err)
goto err_destroy;
+ }
/* At error, ->destroy() callback has to free assigned ID. */
}

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

==============================================================================
TOPIC: kgdb,clocksource: Prevent kernel hang in kernel debugger
http://groups.google.com/group/linux.kernel/t/9346e7852bd8475c?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Jan 26 2010 12:30 am
From: Martin Schwidefsky

On Mon, 25 Jan 2010 22:26:39 -0600
Jason Wessel <jason.wessel@windriver.com> wrote:

> This is a regression fix against: 0f8e8ef7c204988246da5a42d576b7fa5277a8e4
>
> Spin locks were added to the clocksource_resume_watchdog() which cause
> the kernel debugger to deadlock on an SMP system frequently.
>
> The kernel debugger can try for the lock, but if it fails it should
> continue to touch the clocksource watchdog anyway, else it will trip
> if the general kernel execution has been paused for too long.
>
> This introduces an possible race condition where the kernel debugger
> might not process the list correctly if a clocksource is being added
> or removed at the time of this call. This race is sufficiently rare vs
> having the kernel debugger hang the kernel
>
> CC: Thomas Gleixner <tglx@linutronix.de>
> CC: Martin Schwidefsky <schwidefsky@de.ibm.com>
> CC: John Stultz <johnstul@us.ibm.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: Magnus Damm <damm@igel.co.jp>
> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>

The first question I would ask is why does the kernel deadlock? Can we
have a backchain of a deadlock please?

Hmm, there are all kinds of races if the watchdog code gets interrupted
by the kernel debugger. Wouldn't it be better to just disable the
watchdog while the kernel debugger is active?

--
blue skies,
Martin.

"Reality continues to ruin my life." - Calvin.

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

== 2 of 3 ==
Date: Tues, Jan 26 2010 12:50 am
From: Thomas Gleixner

On Mon, 25 Jan 2010, Jason Wessel wrote:
> This is a regression fix against: 0f8e8ef7c204988246da5a42d576b7fa5277a8e4
>
> Spin locks were added to the clocksource_resume_watchdog() which cause
> the kernel debugger to deadlock on an SMP system frequently.
>
> The kernel debugger can try for the lock, but if it fails it should
> continue to touch the clocksource watchdog anyway, else it will trip
> if the general kernel execution has been paused for too long.
>
> This introduces an possible race condition where the kernel debugger
> might not process the list correctly if a clocksource is being added
> or removed at the time of this call. This race is sufficiently rare vs
> having the kernel debugger hang the kernel

I'm not really excited happy about adding a race condition :)

If you stop the kernel in the middle of the watchdog code
(i.e. watchdog_lock is held) then clocksource_reset_watchdog() is not
really a guarantee to keep the TSC alive.

> void clocksource_touch_watchdog(void)
> {
> - clocksource_resume_watchdog();
> + unsigned long flags;
> +
> + int got_lock = spin_trylock_irqsave(&watchdog_lock, flags);

So I prefer

if (!spin_trylock_irqsave(&watchdog_lock, flags))
return;

If that results in TSC being marked unstable then that is way better
than having a race which might even crash or lock the machine when the
stop happened in the middle of a list_add().

Thanks,

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

== 3 of 3 ==
Date: Tues, Jan 26 2010 1:00 am
From: Thomas Gleixner

On Tue, 26 Jan 2010, Martin Schwidefsky wrote:
> On Mon, 25 Jan 2010 22:26:39 -0600
> Jason Wessel <jason.wessel@windriver.com> wrote:
>
> > This is a regression fix against: 0f8e8ef7c204988246da5a42d576b7fa5277a8e4
> >
> > Spin locks were added to the clocksource_resume_watchdog() which cause
> > the kernel debugger to deadlock on an SMP system frequently.
> >
> > The kernel debugger can try for the lock, but if it fails it should
> > continue to touch the clocksource watchdog anyway, else it will trip
> > if the general kernel execution has been paused for too long.
> >
> > This introduces an possible race condition where the kernel debugger
> > might not process the list correctly if a clocksource is being added
> > or removed at the time of this call. This race is sufficiently rare vs
> > having the kernel debugger hang the kernel
> >
> > CC: Thomas Gleixner <tglx@linutronix.de>
> > CC: Martin Schwidefsky <schwidefsky@de.ibm.com>
> > CC: John Stultz <johnstul@us.ibm.com>
> > CC: Andrew Morton <akpm@linux-foundation.org>
> > CC: Magnus Damm <damm@igel.co.jp>
> > Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
>
> The first question I would ask is why does the kernel deadlock? Can we
> have a backchain of a deadlock please?

The problem arises when the kernel is stopped inside the watchdog code
with watchdog_lock held. When kgdb restarts execution then it touches
the watchdog to avoid that TSC gets marked unstable.

> Hmm, there are all kinds of races if the watchdog code gets interrupted
> by the kernel debugger. Wouldn't it be better to just disable the
> watchdog while the kernel debugger is active?

No, we can keep it and in most cases it clocksource_touch_watchdog()
helps to keep TSC alive. A simple "if (!trylock) return;" should solve
the deadlock problem for kgdb without opening a can of worms.

Thanks,

==============================================================================
TOPIC: RFC: make struct platform_driver.id_table const
http://groups.google.com/group/linux.kernel/t/213e1f267bc227c8?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 26 2010 12:40 am
From: Uwe Kleine-König

Greg,

On Tue, Jan 26, 2010 at 02:01:15PM +0800, Eric Miao wrote:
> I seems to remember a similar patch sent to GregKH weeks ago and
> should be sitting somewhere but this one looks to be more complete.
Yes, it's
gregkh-2.6/gregkh-05-driver-core/driver-core-make-platform_device_id-table-const.patch

Below you can find the current state with all Acks it has got until now.
(Eric: I considered your mail as Ack, too. OK?)
As I don't know how to change the log message with an incremental patch
you have to tell me if you prefer this way.

Best regards
Uwe

From edd67c67746c4eb47e13ef3b9ced3c02243d8de7 Mon Sep 17 00:00:00 2001
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date: Fri, 22 Jan 2010 17:59:46 +0100
Subject: [PATCH] make struct platform_driver.id_table const
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This fixes a warning on several pxa based machines:

arch/arm/mach-pxa/ssp.c:475: warning: initialization discards qualifiers from pointer target type

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Vikram Dhillon <dhillonv10@gmail.com>
Acked-by: Eric Miao <eric.y.miao@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/base/platform.c | 2 +-
include/linux/platform_device.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 58efaf2..962246c 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -578,7 +578,7 @@ static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
}

static const struct platform_device_id *platform_match_id(
- struct platform_device_id *id,
+ const struct platform_device_id *id,
struct platform_device *pdev)
{
while (id->name[0]) {
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 71ff887..3a6201e 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -21,7 +21,7 @@ struct platform_device {
u32 num_resources;
struct resource * resource;

- struct platform_device_id *id_entry;
+ const struct platform_device_id *id_entry;

/* arch specific additions */
struct pdev_archdata archdata;
@@ -62,7 +62,7 @@ struct platform_driver {
int (*suspend)(struct platform_device *, pm_message_t state);
int (*resume)(struct platform_device *);
struct device_driver driver;
- struct platform_device_id *id_table;
+ const struct platform_device_id *id_table;
};

extern int platform_driver_register(struct platform_driver *);
--
1.6.6

--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Tues, Jan 26 2010 1:00 am
From: Eric Miao

2010/1/26 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> Greg,
>
> On Tue, Jan 26, 2010 at 02:01:15PM +0800, Eric Miao wrote:
>> I seems to remember a similar patch sent to GregKH weeks ago and
>> should be sitting somewhere but this one looks to be more complete.
> Yes, it's
> gregkh-2.6/gregkh-05-driver-core/driver-core-make-platform_device_id-table-const.patch
>
> Below you can find the current state with all Acks it has got until now.
> (Eric: I considered your mail as Ack, too. OK?)

OK.

> As I don't know how to change the log message with an incremental patch
> you have to tell me if you prefer this way.

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

==============================================================================
TOPIC: futex() on vdso makes process unkillable
http://groups.google.com/group/linux.kernel/t/771496d6192e598e?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 12:40 am
From: Thomas Gleixner

On Tue, 26 Jan 2010, KOSAKI Motohiro wrote:
> > Peter Zijlstra wrote:
> > I like the creating-a-real-file solution. However, for now (and for
> > stable), I think Kosaki's suggestion of EINVAL or EFAULT is a good
> > stop-gap. EINVAL might play the best with existing glibc implementations.
>
> May I confirm your mention?
>
> If we can accept EFAULT, we don't need any change. my previous futex patch
> already did. because 1) VDSO is alwasys read-only mapped 2) write mode
> get_user_pages_fast() against read-only pte/vma return EFAULT.
>
> Current linus and stable tree don't cause Mark's original problem. instead, just
> return EFAULT. (Well, I'm sorry. my previous mail was unclear. I wrote v2.6.31 test
> result)
>
> If you can't accept EFAULT, we need to add vdso specific logic into get_futex_key().

EFAULT is perfectly fine. No need for any special tricks.

Thanks,

tglx

==============================================================================
TOPIC: mfd: fix asic3 build
http://groups.google.com/group/linux.kernel/t/a9ed0abbdedb8720?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 12:50 am
From: Samuel Ortiz

Hi Dmitry,

On Sun, Jan 24, 2010 at 12:20:20AM +0300, Dmitry Artamonow wrote:
> Commit 64e8867ba8 (mfd: tmio_mmc hardware abstraction for CNF area)
> missed to update Makefile rule for asic3, which leads to following
> error during linking:
> LD .tmp_vmlinux1
> drivers/built-in.o: In function `asic3_mmc_clk_div':
> ledtrig-backlight.c:(.text+0x3de28): undefined reference to `tmio_core_mmc_clk_div'
> drivers/built-in.o: In function `asic3_mmc_pwr':
> ledtrig-backlight.c:(.text+0x3de50): undefined reference to `tmio_core_mmc_pwr'
> drivers/built-in.o: In function `asic3_mmc_enable':
> ledtrig-backlight.c:(.text+0x3e154): undefined reference to `tmio_core_mmc_enable'
> make: *** [.tmp_vmlinux1] Error 1
Thanks a lot, patch applied. I will ask Linus to pull it in a couple days or
so.

Cheers,
Samuel.

> Signed-off-by: Dmitry Artamonow <mad_soft@inbox.ru>
> ---
> This is a patch for regression introduced in -rc5 (-rc4 was ok)
> Error above is from building kernel 2.6.33-rc5 with magician_defconfig.
> Sorry if this already been reported/fixed.
>
> drivers/mfd/Makefile | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 8f0d184..97134c5 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -3,7 +3,7 @@
> #
>
> obj-$(CONFIG_MFD_SM501) += sm501.o
> -obj-$(CONFIG_MFD_ASIC3) += asic3.o
> +obj-$(CONFIG_MFD_ASIC3) += asic3.o tmio_core.o
> obj-$(CONFIG_MFD_SH_MOBILE_SDHI) += sh_mobile_sdhi.o
>
> obj-$(CONFIG_HTC_EGPIO) += htc-egpio.o
> --
> 1.6.6
>

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

==============================================================================
TOPIC: starting emacs makes lockdep warning
http://groups.google.com/group/linux.kernel/t/b92a5fcdc20fcbff?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 26 2010 12:50 am
From: Américo Wang

On Tue, Jan 26, 2010 at 3:45 PM, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
> Hi
>
>> On Tue, Jan 26, 2010 at 02:01:12PM +0800, Am??rico Wang wrote:
>>
>> > I agree, it seems that patch is useless, since we already
>> > do lock_kernel() before calling __f_setown()...
>>
>> What's to prevent pid from being freed under us? BKL won't...
>
> I don't understand this issue at all. so, this is stupid dumb question.
> Why can't we write following code?
>
>
> enum pid_type type;
> struct pid *pid;
> if (!waitqueue_active(&tty->read_wait))
> tty->minimum_to_wake = 1;
> spin_lock_irqsave(&tty->ctrl_lock, flags);
> if (tty->pgrp) {
> pid = tty->pgrp;
> type = PIDTYPE_PGID;
> } else {
> pid = task_pid(current);
> type = PIDTYPE_PID;
> }
> get_pid(pid) // insert here
> spin_unlock_irqrestore(&tty->ctrl_lock, flags);
> retval = __f_setown(filp, pid, type, 0);
> put_pid(pid) // insert here
>

Yeah, this seems reasonable for me, but not sure if this is the best fix.

== 2 of 2 ==
Date: Tues, Jan 26 2010 1:20 am
From: ebiederm@xmission.com (Eric W. Biederman)

Américo Wang <xiyou.wangcong@gmail.com> writes:

> On Tue, Jan 26, 2010 at 3:45 PM, KOSAKI Motohiro
> <kosaki.motohiro@jp.fujitsu.com> wrote:
>> Hi
>>
>>> On Tue, Jan 26, 2010 at 02:01:12PM +0800, Am??rico Wang wrote:
>>>
>>> > I agree, it seems that patch is useless, since we already
>>> > do lock_kernel() before calling __f_setown()...
>>>
>>> What's to prevent pid from being freed under us? BKL won't...
>>
>> I don't understand this issue at all. so, this is stupid dumb question.
>> Why can't we write following code?
>>
>>
>> enum pid_type type;
>> struct pid *pid;
>> if (!waitqueue_active(&tty->read_wait))
>> tty->minimum_to_wake = 1;
>> spin_lock_irqsave(&tty->ctrl_lock, flags);
>> if (tty->pgrp) {
>> pid = tty->pgrp;
>> type = PIDTYPE_PGID;
>> } else {
>> pid = task_pid(current);
>> type = PIDTYPE_PID;
>> }
>> get_pid(pid) // insert here
>> spin_unlock_irqrestore(&tty->ctrl_lock, flags);
>> retval = __f_setown(filp, pid, type, 0);
>> put_pid(pid) // insert here
>>
>
> Yeah, this seems reasonable for me, but not sure if this is the best fix.

That or tweak __f_setown to use irqsave/irqrestore variants for it's
locks, __f_setown is already atomic. I prefer that direction because the
code is just a little simpler.

Eric

==============================================================================
TOPIC: move acornfb's probe function to .devinit.text
http://groups.google.com/group/linux.kernel/t/7db9be36a46d6f4f?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Jan 26 2010 12:50 am
From: Uwe Kleine-König

On Sun, Jan 24, 2010 at 01:25:58 +0200, Alexey Dobriyan wrote:
> gods, can you just send one patch for all framebuffer drivers?
Well, I thought one logical change per changeset is the favourite way to
go. And as the people Cc:d are different I think most people prefer it
this way.

On Sun, Jan 24, 2010 at 01:28:13AM +0200, Alexey Dobriyan wrote:
> On Sat, Jan 23, 2010 at 09:35:09PM +0100, Uwe Kleine-König wrote:
> > -static int __init acornfb_probe(struct platform_device *dev)
> > +static int __devinit acornfb_probe(struct platform_device *dev)
>
> Even more, if this function is marked __devinit, some other functions
> can very well be marked __devinit, can you do this?
Probably, the big pro after my patch is that modpost can warn about
this. Actually this applies to all (initially) over 50 patches in this
series. If you take my patches, squash them together and fix all called
functions, I'm happy, too.

If you don't I might come back to this and do it myself.

Best regards
Uwe

== 2 of 3 ==
Date: Tues, Jan 26 2010 12:50 am
From: Uwe Kleine-König

Hello,

On Mon, Jan 25, 2010 at 06:09:01AM +0900, OGAWA Hirofumi wrote:
> Uwe Kleine-König <u.kleine-koenig@pengutronix.de> writes:
>
> > +int platform_driver_register(struct platform_driver *drv)
> > +{
> > + int ret = __platform_driver_register(drv);
> > +
> > +#if defined(CONFIG_HOTPLUG)
> > + /*
> > + * drivers that are registered by platform_driver_register
> > + * should not have their probe function in .init.text. The
> > + * reason is that a probe can happen after .init.text is
> > + * discarded which then results in an oops. The alternatives
> > + * are using .devinit.text for the probe function or "register"
> > + * with platform_driver_probe.
> > + */
> > + if (drv->probe && kernel_init_text_address((unsigned long)drv->probe))
> > + pr_warning("oops-warning: probe function of platform driver %s"
> > + " lives in .init.text\n", drv->driver.name);
> > +#else
> > + /*
> > + * without HOTPLUG probe functions can be discarded after the driver is
> > + * loaded.
> > + * There is a little chance for false positives, namely if the driver is
> > + * registered after the .init sections are discarded.
> > + */
> > + if (drv->probe && !kernel_init_text_address((unsigned long)drv->probe))
> > + pr_info("probably the probe function of platform driver %s can"
> > + " be moved to .init.text\n", drv->driver.name);
> > +

twitter

Tuesday, January 26, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts