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

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

Today's topics:

* tracing: Remove CONFIG_TRACE_POWER from kernel config - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1c3e243b63b568c5?hl=en
* [GIT PULL] tracing: updates - 3 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f804ac89a0890432?hl=en
* staging/dream: add missing include files/fix compilation - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/3de505808c3a3d4b?hl=en
* pm_op(): usb_dev_suspend+0x0/0x10 returns -2 on USB device 8087:0020 - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/e4e60dc919766bb9?hl=en
* VMI and kmap_atomic_pte paravirt_op - 3 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/cbbff68b38bb03f5?hl=en
* btrfs mount causes memory corruption - 5 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/aa0fcacfc605885c?hl=en
* virtio: fix out of range array access - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f13c5e638b5e9c9c?hl=en
* s2disk hang update - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/69e5c9798a1fe4e7?hl=en
* module: __rcu annotations - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/eaea14cfadf53c7d?hl=en
* microblaze: Support FRAME_POINTER for better backtrace - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/c489a8a02ead0831?hl=en
* x86-32: panic on !CX8 && XMM - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c7fe1bc8eb70e0f9?hl=en
* tcp: bugs and cleanup for 2.6.33 - 4 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/565a29ac8df16091?hl=en
* RapidIO: Add Port-Write handling for EM - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/44b44feb7ab46cc4?hl=en
* 2.6.33: Problem continues: WARNING: at arch/x86/kernel/hpet.c:404 hpet_next_
event+0x70/0x80 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5c0ce8c002c74b1e?hl=en
* linux-next: Tree for February 22 (media/video/tvp7002) - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/8e35013e16b45dc3?hl=en

==============================================================================
TOPIC: tracing: Remove CONFIG_TRACE_POWER from kernel config
http://groups.google.com/group/linux.kernel/t/1c3e243b63b568c5?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 25 2010 11:50 am
From: Steven Rostedt

From: Li Zefan <lizf@cn.fujitsu.com>

The power tracer has been converted to power trace events.

Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
LKML-Reference: <4B84D50E.4070806@cn.fujitsu.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
kernel/trace/Kconfig | 9 ---------
1 files changed, 0 insertions(+), 9 deletions(-)

diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 6c22d8a..ca2d3a8 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -330,15 +330,6 @@ config BRANCH_TRACER

Say N if unsure.

-config POWER_TRACER
- bool "Trace power consumption behavior"
- depends on X86
- select GENERIC_TRACER
- help
- This tracer helps developers to analyze and optimize the kernel's
- power management decisions, specifically the C-state and P-state
- behavior.
-
config KSYM_TRACER
bool "Trace read and write access on kernel memory locations"
depends on HAVE_HW_BREAKPOINT
--
1.6.5

--
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: [GIT PULL] tracing: updates
http://groups.google.com/group/linux.kernel/t/f804ac89a0890432?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Feb 25 2010 11:50 am
From: Steven Rostedt

Ingo,

Please pull the latest tip/tracing/core tree, which can be found at:

git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
tip/tracing/core

Jeff Mahoney (1):
tracing: Fix ftrace_event_call alignment for use with gcc 4.5

Li Zefan (1):
tracing: Remove CONFIG_TRACE_POWER from kernel config

Steven Rostedt (1):
ftrace: Remove memory barriers from NMI code when not needed

Wenji Huang (4):
tracing: Fix typo in prof_sysexit_enable()
tracing: Fix typo of info text in trace_kprobe.c
tracing: Remove unnecessary variable in print_graph_return
tracing: Simplify memory recycle of trace_define_field

== 2 of 3 ==
Date: Thurs, Feb 25 2010 11:50 am
From: Steven Rostedt

From: Wenji Huang <wenji.huang@oracle.com>

The "cpu" variable is declared at the start of the function and
also within a branch, with the exact same initialization.

Remove the local variable of the same name in the branch.

Signed-off-by: Wenji Huang <wenji.huang@oracle.com>
LKML-Reference: <1266997226-6833-3-git-send-email-wenji.huang@oracle.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
kernel/trace/trace_functions_graph.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/kernel/trace/trace_functions_graph.c b/kernel/trace/trace_functions_graph.c
index 616b135..112561d 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -855,7 +855,6 @@ print_graph_return(struct ftrace_graph_ret *trace, struct trace_seq *s,
int i;

if (data) {
- int cpu = iter->cpu;
int *depth = &(per_cpu_ptr(data->cpu_data, cpu)->depth);

/*
--
1.6.5

== 3 of 3 ==
Date: Thurs, Feb 25 2010 11:50 am
From: Steven Rostedt

From: Wenji Huang <wenji.huang@oracle.com>

Signed-off-by: Wenji Huang <wenji.huang@oracle.com>
LKML-Reference: <1266997226-6833-2-git-send-email-wenji.huang@oracle.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
kernel/trace/trace_kprobe.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index c990299..8d4bd16 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -651,12 +651,12 @@ static int create_trace_probe(int argc, char **argv)
event = strchr(group, '/') + 1;
event[-1] = '\0';
if (strlen(group) == 0) {
- pr_info("Group name is not specifiled\n");
+ pr_info("Group name is not specified\n");
return -EINVAL;
}
}
if (strlen(event) == 0) {
- pr_info("Event name is not specifiled\n");
+ pr_info("Event name is not specified\n");
return -EINVAL;
}
}
--
1.6.5

==============================================================================
TOPIC: staging/dream: add missing include files/fix compilation
http://groups.google.com/group/linux.kernel/t/3de505808c3a3d4b?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 25 2010 11:50 am
From: Pavel Machek

Hi!

> > > /home/dwalker/linux-2.6/drivers/video/msm/msm_fb.c:24: fatal error: linux/msm_mdp.h: No such file or directory
> > > compilation terminated.
> > > make[4]: *** [drivers/video/msm/msm_fb.o] Error 1
> > > make[3]: *** [drivers/video/msm] Error 2
> > > make[3]: *** Waiting for unfinished jobs....
> > > make[2]: *** [drivers/video] Error 2
> > > make[1]: *** [drivers] Error 2
> > > make: *** [sub-make] Error 2
> >
> > Yes, framebuffer has problems.
> >
> > > Even with the framebuffer off I still don't get any serial output on a
> > > plain 2.6.33-rc6 .. I'm using a config that you sent me when you first
> > > tested my -next tree .
> >
> > 2.6.33 boots here, with attached config. I'll try -next next.
>
> My -next tree hasn't changed much since you last looked at it .. I
> wouldn't bother testing it. I might take some small fixes from that tree
> to merge, but what's there is still too much of a mess to merge.

Ok, so your -next tree will not be merged for 2.6.34?

> I just pushed another tree called "working-mmc" which still needs some
> clean up but should have working mmc if you want to test that.

Do you have git url? Yes, I'd like to play.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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: pm_op(): usb_dev_suspend+0x0/0x10 returns -2 on USB device 8087:0020
http://groups.google.com/group/linux.kernel/t/e4e60dc919766bb9?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 25 2010 12:00 pm
From: Sarah Sharp

On Thu, Feb 25, 2010 at 02:36:02PM -0500, Alan Stern wrote:
> On Thu, 25 Feb 2010, Sarah Sharp wrote:
>
> > > > now, I unplug the USB DVD drive:
> > > >
> > > > Feb 25 17:35:38 tonkachi kernel: [ 276.374282] xhci_hcd 0000:02:00.0:
> > > > WARN: transfer error on endpoint
> > > > Feb 25 17:35:39 tonkachi kernel: [ 276.728151] xhci_hcd 0000:02:00.0:
> > > > WARN: transfer error on endpoint
> > > > Feb 25 17:35:39 tonkachi kernel: [ 276.728819] xhci_hcd 0000:02:00.0:
> > > > WARN: transfer error on endpoint
>
> Shouldn't there be some messages here about "USB disconnect"? This
> suggests there's something wrong with the root hub.

True. I can't tell exactly what's going on without
CONFIG_USB_XHCI_HCD_DEBUGGING. It's possible the xHCI host never
notified the driver of the disconnect, or there's a bug in the xHCI hub
emulation code.

Sarah Sharp
--
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: VMI and kmap_atomic_pte paravirt_op
http://groups.google.com/group/linux.kernel/t/cbbff68b38bb03f5?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Feb 25 2010 12:00 pm
From: Ian Campbell

Hi Alok,

How critical is the vmi_kmap_atomic_pte pv_mmu_op hook to VMI? Is it
required for correct functionality or is it simply an optimisation?

We think we may be able to do away with the Xen version of the hook and
if VMI (which is deprecated) can live without it and you agree then I'll
cook up a patch to remove it altogether.

Thanks,
Ian.

== 2 of 3 ==
Date: Thurs, Feb 25 2010 12:20 pm
From: Jeremy Fitzhardinge

On 02/25/2010 11:52 AM, Ian Campbell wrote:
> How critical is the vmi_kmap_atomic_pte pv_mmu_op hook to VMI? Is it
> required for correct functionality or is it simply an optimisation?
>

Or disable high ptes for VMI too.

J
--
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: Thurs, Feb 25 2010 12:40 pm
From: Alok Kataria

Hi Ian,

On Thu, 2010-02-25 at 11:52 -0800, Ian Campbell wrote:
> Hi Alok,
>
> How critical is the vmi_kmap_atomic_pte pv_mmu_op hook to VMI? Is it
> required for correct functionality or is it simply an optimisation?
>
> We think we may be able to do away with the Xen version of the hook and
> if VMI (which is deprecated) can live without it and you agree then I'll
> cook up a patch to remove it altogether.

As Jeremy suggests we will be fine with disabling high ptes for VMI.
Thanks for doing this.

Alok
>
> Thanks,
> Ian.
>
>

==============================================================================
TOPIC: btrfs mount causes memory corruption
http://groups.google.com/group/linux.kernel/t/aa0fcacfc605885c?hl=en
==============================================================================

== 1 of 5 ==
Date: Thurs, Feb 25 2010 12:10 pm
From: Andrew Lutomirski

Mounting btrfs corrupts memory and causes nasty crashes within a few
seconds. This seems to happen even if the mount fails (note the
unrecognized mount option). This is a regression from 2.6.32, and
I've attached an example.

--Andy

Btrfs loaded
device fsid cf4a8e080605f191-af91bbbf445c98b8 devid 2 transid 68136 /dev/dm-2
device fsid cf4a8e080605f191-af91bbbf445c98b8 devid 1 transid 68136 /dev/dm-1
device fsid cf4a8e080605f191-af91bbbf445c98b8 devid 2 transid 68136
/dev/mapper/big_2
device fsid cf4a8e080605f191-af91bbbf445c98b8 devid 1 transid 68136
/dev/mapper/big_1
device fsid cf4a8e080605f191-af91bbbf445c98b8 devid 1 transid 68136
/dev/mapper/big_1
btrfs: unrecognized mount option 'acl'
btrfs: open_ctree failed
------------[ cut here ]------------
kernel BUG at mm/slub.c:2969!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/kernel/mm/ksm/run
CPU 6
Pid: 2692, comm: bash Tainted: G W 2.6.33 #2 P6T WS PRO/System
Product Name
RIP: 0010:[<ffffffff810fbbde>] [<ffffffff810fbbde>] kfree+0x62/0xd5
RSP: 0018:ffff88019db87c68 EFLAGS: 00010246
RAX: 0040000000080000 RBX: ffff88019db87d18 RCX: ffff8801b175de20
RDX: ffffea0000000000 RSI: ffffea0003800000 RDI: ffff880100000000
RBP: ffff88019db87c88 R08: ffffffff81a57aa0 R09: ffff8801b551c240
R10: 00000002412fde13 R11: 0000000000000000 R12: ffff880100000000
R13: ffffffff811d9532 R14: 0000000000000010 R15: ffff88019db87ce8
FS: 00007fde0bce7700(0000) GS:ffff8800282c0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f041b1b4600 CR3: 00000001b776a000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process bash (pid: 2692, threadinfo ffff88019db86000, task ffff88019d928000)
Stack:
ffff8801b551c240 ffff88019db87d18 0000000000000000 ffff88019b65f164
<0> ffff88019db87ca8 ffffffff811d9532 ffff88019db87ce8 ffff8801b4b8f548
<0> ffff88019db87cc8 ffffffff811de035 ffff8801b4b8f548 ffff8801b644bba8
Call Trace:
[<ffffffff811d9532>] ebitmap_destroy+0x21/0x3c
[<ffffffff811de035>] context_destroy+0x58/0x6c
[<ffffffff811e0787>] security_compute_sid+0x26d/0x282
[<ffffffff811e0815>] security_transition_sid+0x1f/0x21
[<ffffffff811d45d9>] selinux_bprm_set_creds+0xd1/0x25f
[<ffffffff810e3510>] ? vma_link+0x88/0xb1
[<ffffffff811d4a29>] ? selinux_vm_enough_memory+0x40/0x45
[<ffffffff8120cc58>] ? spin_unlock_irqrestore+0x9/0xb
[<ffffffff8120cce0>] ? __up_write+0x42/0x47
[<ffffffff811c909d>] security_bprm_set_creds+0x13/0x15
[<ffffffff8110cc3b>] prepare_binprm+0xc3/0xf0
[<ffffffff8110d55e>] do_execve+0x150/0x2d2
[<ffffffff81010eaf>] sys_execve+0x43/0x5a
[<ffffffff8100a0ca>] stub_execve+0x6a/0xc0
Code: 83 c3 08 48 83 3b 00 eb ec 49 83 fc 10 0f 86 82 00 00 00 4c 89
e7 e8 c5 e2 ff ff 48 89 c6 48 8b 00 84 c0 78 14 66 a9 00 c0 75 04 <0f>
0b eb fe 48 89 f7 e8 ea 36 fd ff eb 5c 48 8b 4d 08 48 8b 7e
RIP [<ffffffff810fbbde>] kfree+0x62/0xd5
RSP <ffff88019db87c68>
---[ end trace 57f7151f6a5def07 ]---
--
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 5 ==
Date: Thurs, Feb 25 2010 12:30 pm
From: Josef Bacik

On Thu, Feb 25, 2010 at 03:01:08PM -0500, Andrew Lutomirski wrote:
> Mounting btrfs corrupts memory and causes nasty crashes within a few
> seconds. This seems to happen even if the mount fails (note the
> unrecognized mount option). This is a regression from 2.6.32, and
> I've attached an example.
>

And it only happens when you mount a btrfs fs? Can you show me a trace of when
you mount a btrfs fs with valid mount options? I'd like to see if we're not
cleaning up something properly or what. Thanks,

Josef
--
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 5 ==
Date: Thurs, Feb 25 2010 12:40 pm
From: Josef Bacik

On Thu, Feb 25, 2010 at 03:29:34PM -0500, Andrew Lutomirski wrote:
> On Thu, Feb 25, 2010 at 3:23 PM, Josef Bacik <josef@redhat.com> wrote:
> > On Thu, Feb 25, 2010 at 03:01:08PM -0500, Andrew Lutomirski wrote:
> >> Mounting btrfs corrupts memory and causes nasty crashes within a few
> >> seconds. �This seems to happen even if the mount fails (note the
> >> unrecognized mount option). �This is a regression from 2.6.32, and
> >> I've attached an example.
> >>
> >
> > And it only happens when you mount a btrfs fs? �Can you show me a trace of when
> > you mount a btrfs fs with valid mount options? �I'd like to see if we're not
> > cleaning up something properly or what. �Thanks,
>
> Seems OK. Or maybe I just got lucky, but it's crashed every time I
> tried to mount with 'acl' before.
>
> I even went through a couple iterations of trying to mount with
> 'xattr' and 'user_xattr', both of which failed.
>

Ok it looks like we have a problem kfree'ing the wrong stuff. we kstrdup the
options string, but then strsep screws with the pointer, so when we kfree() it,
we're not giving it the right pointer. Please try this patch, and mount with -o
acl and other such garbage to make sure it actually worked (acl isn't a valid
mount option btw). Let me know if it works. Thanks,

Josef

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 8a1ea6e..f8b4521 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -128,7 +128,7 @@ int btrfs_parse_options(struct btrfs_root *root, char *options)
{
struct btrfs_fs_info *info = root->fs_info;
substring_t args[MAX_OPT_ARGS];
- char *p, *num;
+ char *p, *num, *orig;
int intarg;
int ret = 0;

@@ -143,6 +143,7 @@ int btrfs_parse_options(struct btrfs_root *root, char *options)
if (!options)
return -ENOMEM;

+ orig = options;

while ((p = strsep(&options, ",")) != NULL) {
int token;
@@ -280,7 +281,7 @@ int btrfs_parse_options(struct btrfs_root *root, char *options)
}
}
out:
- kfree(options);
+ kfree(orig);
return ret;
}

--
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 5 ==
Date: Thurs, Feb 25 2010 12:40 pm
From: Andrew Lutomirski

On Thu, Feb 25, 2010 at 3:23 PM, Josef Bacik <josef@redhat.com> wrote:
> On Thu, Feb 25, 2010 at 03:01:08PM -0500, Andrew Lutomirski wrote:
>> Mounting btrfs corrupts memory and causes nasty crashes within a few
>> seconds. �This seems to happen even if the mount fails (note the
>> unrecognized mount option). �This is a regression from 2.6.32, and
>> I've attached an example.
>>
>
> And it only happens when you mount a btrfs fs? �Can you show me a trace of when
> you mount a btrfs fs with valid mount options? �I'd like to see if we're not
> cleaning up something properly or what. �Thanks,

Seems OK. Or maybe I just got lucky, but it's crashed every time I
tried to mount with 'acl' before.

I even went through a couple iterations of trying to mount with
'xattr' and 'user_xattr', both of which failed.

--Andy
--
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/

== 5 of 5 ==
Date: Thurs, Feb 25 2010 12:50 pm
From: Andrew Lutomirski

On Thu, Feb 25, 2010 at 3:38 PM, Josef Bacik <josef@redhat.com> wrote:
>
> Ok it looks like we have a problem kfree'ing the wrong stuff. we kstrdup the
> options string, but then strsep screws with the pointer, so when we kfree() it,
> we're not giving it the right pointer. Please try this patch, and mount with -o
> acl and other such garbage to make sure it actually worked (acl isn't a valid
> mount option btw). Let me know if it works. Thanks,
>
> Josef
>
>
> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> index 8a1ea6e..f8b4521 100644
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -128,7 +128,7 @@ int btrfs_parse_options(struct btrfs_root *root, char *options)
> {
> struct btrfs_fs_info *info = root->fs_info;
> substring_t args[MAX_OPT_ARGS];
> - char *p, *num;
> + char *p, *num, *orig;
> int intarg;
> int ret = 0;
>
> @@ -143,6 +143,7 @@ int btrfs_parse_options(struct btrfs_root *root, char *options)
> if (!options)
> return -ENOMEM;
>
> + orig = options;
>
> while ((p = strsep(&options, ",")) != NULL) {
> int token;
> @@ -280,7 +281,7 @@ int btrfs_parse_options(struct btrfs_root *root, char *options)
> }
> }
> out:
> - kfree(options);
> + kfree(orig);
> return ret;
> }
>
>

Thanks for the instant patch. I hammered on it a bit and it hasn't
crashed yet. I'll let you know if it crashes later. (The earlier
trial with xattr crashed after a couple minutes.)

In the mean time,

Tested-by: Andy Lutomirski <luto@mit.edu>

==============================================================================
TOPIC: virtio: fix out of range array access
http://groups.google.com/group/linux.kernel/t/f13c5e638b5e9c9c?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 25 2010 12:10 pm
From: Anthony Liguori

On 02/25/2010 11:13 AM, Michael S. Tsirkin wrote:
> I have observed the following error on virtio-net module unload:
>
> ------------[ cut here ]------------
> WARNING: at kernel/irq/manage.c:858 __free_irq+0xa0/0x14c()
> Hardware name: Bochs
> Trying to free already-free IRQ 0
> Modules linked in: virtio_net(-) virtio_blk virtio_pci virtio_ring
> virtio af_packet e1000 shpchp aacraid uhci_hcd ohci_hcd ehci_hcd [last
> unloaded: scsi_wait_scan]
> Pid: 1957, comm: rmmod Not tainted 2.6.33-rc8-vhost #24
> Call Trace:
> [<ffffffff8103e195>] warn_slowpath_common+0x7c/0x94
> [<ffffffff8103e204>] warn_slowpath_fmt+0x41/0x43
> [<ffffffff810a7a36>] ? __free_pages+0x5a/0x70
> [<ffffffff8107cc00>] __free_irq+0xa0/0x14c
> [<ffffffff8107cceb>] free_irq+0x3f/0x65
> [<ffffffffa0081424>] vp_del_vqs+0x81/0xb1 [virtio_pci]
> [<ffffffffa0091d29>] virtnet_remove+0xda/0x10b [virtio_net]
> [<ffffffffa0075200>] virtio_dev_remove+0x22/0x4a [virtio]
> [<ffffffff812709ee>] __device_release_driver+0x66/0xac
> [<ffffffff81270ab7>] driver_detach+0x83/0xa9
> [<ffffffff8126fc66>] bus_remove_driver+0x91/0xb4
> [<ffffffff81270fcf>] driver_unregister+0x6c/0x74
> [<ffffffffa0075418>] unregister_virtio_driver+0xe/0x10 [virtio]
> [<ffffffffa0091c4d>] fini+0x15/0x17 [virtio_net]
> [<ffffffff8106997b>] sys_delete_module+0x1c3/0x230
> [<ffffffff81007465>] ? old_ich_force_enable_hpet+0x117/0x164
> [<ffffffff813bb720>] ? do_page_fault+0x29c/0x2cc
> [<ffffffff81028e58>] sysenter_dispatch+0x7/0x27
> ---[ end trace 15e88e4c576cc62b ]---
>
> The bug is in virtio-pci: we use msix_vector as array index to get irq
> entry, but some vqs do not have a dedicated vector so this causes an out
> of bounds access. By chance, we seem to often get 0 value, which
> results in this error.
>
> Fix by verifying that vector is legal before using it as index.
>
> Signed-off-by: Michael S. Tsirkin<mst@redhat.com>
>

Acked-by: Anthony Liguori <aliguori@us.ibm.com>

Regards,

Anthony Liguori

> ---
> Shirley, Amit, with Rusty on vacation, need other reviewers. Could you
> please review the following patch and ack on list if appropriate?
>
> drivers/virtio/virtio_pci.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c
> index 28d9cf7..7127bfe 100644
> --- a/drivers/virtio/virtio_pci.c
> +++ b/drivers/virtio/virtio_pci.c
> @@ -473,7 +473,8 @@ static void vp_del_vqs(struct virtio_device *vdev)
>
> list_for_each_entry_safe(vq, n,&vdev->vqs, list) {
> info = vq->priv;
> - if (vp_dev->per_vq_vectors)
> + if (vp_dev->per_vq_vectors&&
> + info->msix_vector != VIRTIO_MSI_NO_VECTOR)
> free_irq(vp_dev->msix_entries[info->msix_vector].vector,
> vq);
> vp_del_vq(vq);
>

==============================================================================
TOPIC: s2disk hang update
http://groups.google.com/group/linux.kernel/t/69e5c9798a1fe4e7?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 25 2010 12:10 pm
From: "Rafael J. Wysocki"

On Thursday 25 February 2010, Alan Jenkins wrote:
> On 2/24/10, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Wednesday 24 February 2010, Alan Jenkins wrote:
...
>
> > - while (to_free_normal > 0 && to_free_highmem > 0) {
> > + while (to_free_normal > 0 || to_free_highmem > 0) {
>
> Yes, that seems to do it. No more hangs so far (and I can still
> reproduce the hang with too many applications if I un-apply the
> patch).

OK, great. Is this with or without the NOIO-enforcing patch?

> I did see a non-fatal allocation failure though, so I'm still not sure
> that the current implementation is strictly correct.
>
> This is without the patch to increase "to_free_normal". If I get the
> allocation failure again, should I try testing the "free 20% extra"
> patch?

Either that or try to increase SPARE_PAGES. That should actually work with
the last patch applied. :-)

Rafael
--
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: module: __rcu annotations
http://groups.google.com/group/linux.kernel/t/eaea14cfadf53c7d?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 25 2010 12:10 pm
From: "Paul E. McKenney"

On Thu, Feb 25, 2010 at 07:10:34PM +0100, Arnd Bergmann wrote:
> On Thursday 25 February 2010, Paul E. McKenney wrote:
> > >
> > > The nice thing about this is that we don't end up with the API explosion
> > > for the RCU list primitives. However, it does require that a given
> > > rcu_list_head have a single synchronization-design rule for all uses.
> > > Of course, if there were multiple rules, one could construct a check
> > > that was simply the union of all the rules, but that would miss some
> > > types of errors.
>
> What would it miss? E.g. having the module code check for
> (mutex_is_locked(&module_lock) || rcu_read_lock_held) should
> cover all cases as far as I can tell.

My concern is single data structures used in different parts of the code
with different update-side locks, perhaps also different flavors of RCU.
Some of the tree data structures in the Linux kernel can be protected by
either locking or RCU, for example.

> > > Of course, if this became a problem, there could be an argument to the
> > > ->check function that the normal list_for_each_entry_rcu() defaults to
> > > "no effect".
>
> I've also been thinking about adding a list_for_each_entry_norcu()
> macro that takes an rcu_list_head but then just performs a simple
> list_for_each_entry().

We might need to do something like this, but if we do, we need to
minimize the need to use it.

> > > Or is there a better way to handle this?
> >
> > One approach would be to use your original sparse-based approach, but
> > use an rcu_deference_const(ptr,lockdep_condition) for cases when the
> > value cannot change, for example, when the update-side lock is held.
> > This should eliminate most of the false positives, in particular,
> > eliminate the need for otherwise-useless rcu_read_lock()s -- and also
> > for the compiler constraints in the normal rcu_dereference().
>
> Right.
>
> > Your pointer-to-function idea could be a really cool way to handle the
> > tree algorithms that can be protected either by RCU or by locking.
> > The tree nodes could have the pointer to check function, and the
> > current rcu_dereference_raw() calls could be replaced by an invocation
> > of rcu_dereference_check() that calls the check function. A check
> > function for an RCU-protected tree would use "rcu_read_lock_held() ||
> > lockdep_is_held(&update_side_lock)", while a lock-protected tree would
> > just use "lockdep_is_held(&update_side_lock)".
>
> I've postponed that problem for now, and updated my series to split
> the rculist annotations from the basic __rcu pointer annotations,
> as well as to apply on top of your patches in tip/core/rcu,
> see http://git.kernel.org/?p=linux/kernel/git/arnd/playground.git;\
> a=shortlog;h=refs/heads/rcu-annotate-tip.
>
> Should we merge the simple annotations in this merge window and
> then think about rculist and trees separately?

I haven't given up on the possibility of getting the whole thing into
this merge window, but if that is not possible, it would be good to
start on the annotations. Of course, the annotations would need to be
done so that they don't rain false positives on people who are not
actively looking to see them.

Thanx, Paul
--
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: microblaze: Support FRAME_POINTER for better backtrace
http://groups.google.com/group/linux.kernel/t/c489a8a02ead0831?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 25 2010 12:20 pm
From: "Steven J. Magnani"

Add a FRAME_POINTER option and when it is enabled, use frame pointers
to walk the stack during a backtrace dump. This eliminates printout of
confusing "function calls" corresponding to stack values that look like they
might be return addresses, but aren't.

This patch is dependent upon
[PATCH] microblaze: Begin stack dump with caller of dump_stack()

I'm not certain whether the MMU compiler generates frame pointers the same
way as the noMMU compiler I am using. I'm also not sure what all the
ramifications of providing FRAME_POINTER are. It looks like tracing
functionality makes use of it. Need someone familiar with these areas
to comment on the patch.

Signed-off-by: Steven J. Magnani <steve@digidescorp.com>
---
diff -uprN a/arch/microblaze/Kconfig.debug b/arch/microblaze/Kconfig.debug
--- a/arch/microblaze/Kconfig.debug 2010-02-25 13:52:30.000000000 -0600
+++ b/arch/microblaze/Kconfig.debug 2010-02-25 13:52:49.000000000 -0600
@@ -26,4 +26,11 @@ config DEBUG_BOOTMEM
depends on DEBUG_KERNEL
bool "Debug BOOTMEM initialization"

+config FRAME_POINTER
+ bool "Use frame pointers"
+ default n
+ help
+ If you say N here, the resulting kernel will be slightly smaller and
+ faster. However, stack dumps will be much harder to interpret.
+
endmenu
diff -uprN a/arch/microblaze/kernel/traps.c b/arch/microblaze/kernel/traps.c
--- a/arch/microblaze/kernel/traps.c 2010-02-25 13:50:00.000000000 -0600
+++ b/arch/microblaze/kernel/traps.c 2010-02-25 13:51:11.000000000 -0600
@@ -8,6 +8,7 @@
* for more details.
*/

+#include <generated/autoconf.h>
#include <linux/kernel.h>
#include <linux/kallsyms.h>
#include <linux/module.h>
@@ -44,7 +45,7 @@ void show_trace(struct task_struct *task
printk(KERN_NOTICE "\n");

twitter

Thursday, February 25, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts