Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)

2007-05-08 Thread William Lee Irwin III 
On Mon, May 07, 2007 at 10:31:32PM -0700, William Lee Irwin III wrote:
>> I think Andi's handling the mergework on those patches, but I'll check
>> in to see if I should rediff vs. -mm or what if you want them.
>> Andi, what's the verdict on those stack patches?

On Tue, May 08, 2007 at 10:59:50AM +0200, Andi Kleen wrote:
> I planned to merge them partially. Add the separate 4/8/irqstack options,
> add the vmalloc support, but not support the > 8K stacks. Haven't yet.

I respun things to incorporate some of hch's suggestions and to fix
an issue Jeremy Fitzhardinge had with CPU hotplug, and some suggestion
from someone else, too.

Basically what changed was:
( 1) drop the large stack config option patch entirely
( 2) fold the __pa() check into the vmalloc stack patch under #ifdef
( 3) rename CONFIG_VMALLOC_STACK to CONFIG_DEBUG_STACK
( 4) fold guarding CPU 0's IRQ stack into the vmalloc stack patch
( 5) make IRQ stacks unconditional instead of independently configurable
( 6) check slab_is_available() for CPU 0's bootmem vs. get_free_pages()
( 7) mark various things __cpuinit that needed to be
( 8) handle and propagate allocation errors up to __cpu_up()
( 9) redo CPU 0's IRQ stack allocation to normalize it for hotplug
(10) use a struct for IRQ stack state instead of 3 per_cpu vars

The current patch series needs the two fixup patches at the end folded
back into the patches it fixes up, but follows in its entirety as a
series of MIME attachments. I've no idea what it applies against.


-- wli
Subject: dynamically allocate IRQ stacks

Dynamically allocate IRQ stacks in order to conserve memory when using
IRQ stacks. cpu_possible_map is not now initialized in such a manner as
to provide a meaningful indication of how many CPU's might be in the
system, and features to appear in the sequel also require indirection,
so they themselves are not allocatable as per_cpu variables, but rather
only pointers to them.

Signed-off-by: William Irwin <[EMAIL PROTECTED]>


Index: stack-paranoia/arch/i386/kernel/irq.c
===
--- stack-paranoia.orig/arch/i386/kernel/irq.c	2007-04-30 14:18:25.645682879 -0700
+++ stack-paranoia/arch/i386/kernel/irq.c	2007-05-01 10:19:38.028853928 -0700
@@ -17,9 +17,11 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
+#include 
 
 DEFINE_PER_CPU(irq_cpustat_t, irq_stat) cacheline_internodealigned_in_smp;
 EXPORT_PER_CPU_SYMBOL(irq_stat);
@@ -56,8 +58,8 @@
 	u32 stack[THREAD_SIZE/sizeof(u32)];
 };
 
-static union irq_ctx *hardirq_ctx[NR_CPUS] __read_mostly;
-static union irq_ctx *softirq_ctx[NR_CPUS] __read_mostly;
+static DEFINE_PER_CPU(union irq_ctx *, hardirq_ctx);
+static DEFINE_PER_CPU(union irq_ctx *, softirq_ctx);
 #endif
 
 /*
@@ -102,7 +104,7 @@
 #ifdef CONFIG_4KSTACKS
 
 	curctx = (union irq_ctx *) current_thread_info();
-	irqctx = hardirq_ctx[smp_processor_id()];
+	irqctx = per_cpu(hardirq_ctx, smp_processor_id());
 
 	/*
 	 * this is where we switch to the IRQ stack. However, if we are
@@ -150,11 +152,24 @@
  * These should really be __section__(".bss.page_aligned") as well, but
  * gcc's 3.0 and earlier don't handle that correctly.
  */
-static char softirq_stack[NR_CPUS * THREAD_SIZE]
-		__attribute__((__aligned__(THREAD_SIZE)));
+static DEFINE_PER_CPU(char *, softirq_stack);
+static DEFINE_PER_CPU(char *, hardirq_stack);
 
-static char hardirq_stack[NR_CPUS * THREAD_SIZE]
-		__attribute__((__aligned__(THREAD_SIZE)));
+static void * __init __alloc_irqstack(int cpu)
+{
+	if (!slab_is_available())
+		return __alloc_bootmem(THREAD_SIZE, THREAD_SIZE,
+		__pa(MAX_DMA_ADDRESS));
+
+	return (void *)__get_free_pages(GFP_KERNEL,
+	ilog2(THREAD_SIZE/PAGE_SIZE));
+}
+
+static void __init alloc_irqstacks(int cpu)
+{
+	per_cpu(softirq_stack, cpu) = __alloc_irqstack(cpu);
+	per_cpu(hardirq_stack, cpu) = __alloc_irqstack(cpu);
+}
 
 /*
  * allocate per-cpu stacks for hardirq and for softirq processing
@@ -163,34 +178,36 @@
 {
 	union irq_ctx *irqctx;
 
-	if (hardirq_ctx[cpu])
+	if (per_cpu(hardirq_ctx, cpu))
 		return;
 
-	irqctx = (union irq_ctx*) &hardirq_stack[cpu*THREAD_SIZE];
+	alloc_irqstacks(cpu);
+
+	irqctx = (union irq_ctx*)per_cpu(hardirq_stack, cpu);
 	irqctx->tinfo.task  = NULL;
 	irqctx->tinfo.exec_domain   = NULL;
 	irqctx->tinfo.cpu   = cpu;
 	irqctx->tinfo.preempt_count = HARDIRQ_OFFSET;
 	irqctx->tinfo.addr_limit= MAKE_MM_SEG(0);
 
-	hardirq_ctx[cpu] = irqctx;
+	per_cpu(hardirq_ctx, cpu) = irqctx;
 
-	irqctx = (union irq_ctx*) &softirq_stack[cpu*THREAD_SIZE];
+	irqctx = (union irq_ctx*)per_cpu(softirq_stack, cpu);
 	irqctx->tinfo.task  = NULL;
 	irqctx->tinfo.exec_domain   = NULL;
 	irqctx->tinfo.cpu   = cpu;
 	irqctx->tinfo.preempt_count = 0;
 	irqctx->tinfo.addr_limit= MAKE_MM_SEG(0);
 
-	softirq_ctx[cpu] = irqctx;
+	per_cpu(softirq_ctx, cpu) = irqctx;
 
 	printk("CPU %u irqstacks, hard=%p

Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)

2007-05-08 Thread Andi Kleen 
On Mon, May 07, 2007 at 10:31:32PM -0700, William Lee Irwin III wrote:
> On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> 
> wrote:
> >> I'm using wli's 8k
> >> stack + irq stack patches with good success though.
> 
> On Mon, May 07, 2007 at 10:24:09PM -0700, Andrew Morton wrote:
> > wlis are handy.
> 
> I think Andi's handling the mergework on those patches, but I'll check
> in to see if I should rediff vs. -mm or what if you want them.
> 
> Andi, what's the verdict on those stack patches?

I planned to merge them partially. Add the separate 4/8/irqstack options,
add the vmalloc support, but not support the > 8K stacks. Haven't yet.

-Andi
-
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: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)

2007-05-08 Thread Jan Engelhardt 

On May 8 2007 16:18, David Chinner wrote:
>
>On Mon, May 07, 2007 at 10:38:24PM -0700, Jeremy Fitzhardinge wrote:
>> Andrew Morton wrote:
>> > On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> 
>> > wrote:
>> >   
>> >> I've found that XFS+lvm+4k stacks is completely unusable with current
>> >> kernels.  I get hangs/oopes after ~10mins of work.
>> >
>> > Sounds like this is new behaviour?
>> > I wonder why.  Same compiler version?
>> 
>> I've only recently started using xfs, so I couldn't say if its new
>> behaviour.  I did notice that it took a week or so for problems to set
>> in; my theory is that as the filesystem got a bit aged, its
>> datastructures got a bit more complex, and cause the kernel code to use
>> more stack.  But that's just a guess.

FWIW, I run dm-crypt+xfs on one machine, of course with 8k since that's
suse default. No issues. dm-crypt and lvm got something in common,
don't they?


Jan
-- 
-
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: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)

2007-05-07 Thread David Chinner 
On Mon, May 07, 2007 at 10:38:24PM -0700, Jeremy Fitzhardinge wrote:
> Andrew Morton wrote:
> > On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> 
> > wrote:
> >   
> >> I've found that XFS+lvm+4k stacks is completely unusable with current
> >> kernels.  I get hangs/oopes after ~10mins of work.
> >> 
> >
> > Sounds like this is new behaviour?
> >
> > I wonder why.  Same compiler version?
> 
> I've only recently started using xfs, so I couldn't say if its new
> behaviour.  I did notice that it took a week or so for problems to set
> in; my theory is that as the filesystem got a bit aged, its
> datastructures got a bit more complex, and cause the kernel code to use
> more stack.  But that's just a guess.

The worst case stack usage through XFS occurs when it has to read
metadata blocks in the writeback path when doing an allocation
transaction. This happens when walking the freespace btrees looking
for an extent matching the allocation requirements. As the fileystem
fills up, these btrees will grow and you are more likely not to have
a block inthe btree cached in memory.

So yes, this is a possible reason you hadn't seen any problems early
on.

FWIW, there's also been recent reports of both ext3 and reiser on
LVM blowing 4k stacks, so if you use LVM it probably advisable to
go back to 8k stacks

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
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: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)

2007-05-07 Thread William Lee Irwin III 
On Mon, 7 May 2007 22:31:32 -0700 William Lee Irwin III <[EMAIL PROTECTED]> 
wrote:
>> I think Andi's handling the mergework on those patches, but I'll check
>> in to see if I should rediff vs. -mm or what if you want them.
>> Andi, what's the verdict on those stack patches?

On Mon, May 07, 2007 at 10:37:38PM -0700, Andrew Morton wrote:
> Whoa. The verdict is usually "don't use so much stack".
> Do we know what has gone wrong here?
> Last week Jens said he was picking up the ancient
> md-dm-reduce-stack-usage-with-stacked-block-devices.patch, but he doesn't
> seem to have done so yet.
> XFS is frequently implicated.

Well, the culmination of those patches is a patch to use vmallocspace
to establish guard pages for stacks so overflows are immediately trapped
and the potential for silent corruption greatly reduced. That would be
where I suspect it's most relevant, as that's the focal point of the
series. The bit about unconditional IRQ stacks arose as part of review.

It started life as a set of patches intended to help with debugging
stack overflows, which is how the only tangentially-related unconditional
IRQ stacks came about: originally they were optional as a debug option
for differential diagnosis of interrupt-time overflows. For mainline, hch
suggested that they should rather be made unconditional.

The third part of the series that survived review was dynamic boot-time
allocation of IRQ stacks, which was originally motivated by the need
for indirection when remapping IRQ stacks into vmallocspace, but also
served the purpose of mitigating space overhead when using IRQ stacks
because cpu_possible_map is not set up as it should be to avoid the
allocation via per_cpu array variables' dynamic boot-time allocation
on i386 and (AFAIK) x86-64.


-- wli
-
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: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)

2007-05-07 Thread Jeremy Fitzhardinge 
Andrew Morton wrote:
> On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> 
> wrote:
>   
>> I've found that XFS+lvm+4k stacks is completely unusable with current
>> kernels.  I get hangs/oopes after ~10mins of work.
>> 
>
> Sounds like this is new behaviour?
>
> I wonder why.  Same compiler version?
>   

I've only recently started using xfs, so I couldn't say if its new
behaviour.  I did notice that it took a week or so for problems to set
in; my theory is that as the filesystem got a bit aged, its
datastructures got a bit more complex, and cause the kernel code to use
more stack.  But that's just a guess.

J
-
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: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)

2007-05-07 Thread Andrew Morton 
On Mon, 7 May 2007 22:31:32 -0700 William Lee Irwin III <[EMAIL PROTECTED]> 
wrote:

> On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> 
> wrote:
> >> I'm using wli's 8k
> >> stack + irq stack patches with good success though.
> 
> On Mon, May 07, 2007 at 10:24:09PM -0700, Andrew Morton wrote:
> > wlis are handy.
> 
> I think Andi's handling the mergework on those patches, but I'll check
> in to see if I should rediff vs. -mm or what if you want them.
> 
> Andi, what's the verdict on those stack patches?
> 

Whoa. The verdict is usually "don't use so much stack".

Do we know what has gone wrong here?

Last week Jens said he was picking up the ancient
md-dm-reduce-stack-usage-with-stacked-block-devices.patch, but he doesn't
seem to have done so yet.

XFS is frequently implicated.
-
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: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)

2007-05-07 Thread William Lee Irwin III 
On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> 
wrote:
>> I'm using wli's 8k
>> stack + irq stack patches with good success though.

On Mon, May 07, 2007 at 10:24:09PM -0700, Andrew Morton wrote:
> wlis are handy.

I think Andi's handling the mergework on those patches, but I'll check
in to see if I should rediff vs. -mm or what if you want them.

Andi, what's the verdict on those stack patches?


-- wli
-
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: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)

2007-05-07 Thread Andrew Morton 
On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> 
wrote:

> Andrew Morton wrote:
> > Please enable 8k stacks before doing any other debugging things, see if
> > that fixes it.
> 
> I've found that XFS+lvm+4k stacks is completely unusable with current
> kernels.  I get hangs/oopes after ~10mins of work.

Sounds like this is new behaviour?

I wonder why.  Same compiler version?

>  I'm using wli's 8k
> stack + irq stack patches with good success though.
> 

wlis are handy.
-
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: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)

2007-05-07 Thread Jeremy Fitzhardinge 
Andrew Morton wrote:
> Please enable 8k stacks before doing any other debugging things, see if
> that fixes it.

I've found that XFS+lvm+4k stacks is completely unusable with current
kernels.  I get hangs/oopes after ~10mins of work.  I'm using wli's 8k
stack + irq stack patches with good success though.

J
-
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: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)

2007-05-07 Thread Andrew Morton 
On Tue, 08 May 2007 00:30:31 +0100
Simon Arlott <[EMAIL PROTECTED]> wrote:

> On 08/05/07 00:23, Andrew Morton wrote:
> > On Mon, 07 May 2007 23:58:36 +0100
> > Simon Arlott <[EMAIL PROTECTED]> wrote:
> > 
> >> I've just got this under mainline too now 
> >> (0ec54aa8af5e6faa346aa55a1ad15ee6c25bb42d 2007-05-05 22:08:06):
> >>
> >> [84567.084000] BUG: scheduling while atomic: pdflush/0xeff84acf/186
> >> [84567.084000] INFO: lockdep is turned off.
> >> [84567.084000] do_IRQ: stack overflow: 440
> >> [84567.084000]  [] show_trace_log_lvl+0x1a/0x30
> >> [84567.084000]  [] show_trace+0x12/0x20
> >> [84567.084000]  [] dump_stack+0x15/0x20
> >> [84567.084000]  [] do_IRQ+0xd8/0xe0
> >> [84567.084000]  [] common_interrupt+0x2e/0x34
> >> [84567.084000]  [] printk+0x18/0x20
> >> [84567.084000]  [] debug_show_held_locks+0x23/0x30
> >> [84567.084000]  [] schedule+0x52a/0x680
> >> [84567.084000]  [] schedule_timeout+0x8a/0x90
> >> [84567.084000]  [] xlog_state_sync+0x21e/0x260
> >> [84567.084000]  [] _xfs_log_force+0x44/0x70
> >> [84567.084000]  [] xfs_alloc_search_busy+0xd2/0xe0
> >> [84567.084000]  [] xfs_alloc_get_freelist+0xe6/0x100
> >> [84567.084000]  [] xfs_alloc_split+0x1f/0x4c0
> >> [84567.084000]  [] xfs_alloc_insrec+0x35d/0x3b0
> >> [84567.084000]  [] xfs_alloc_insert+0x59/0xd0
> >> [84567.084000]  [] xfs_free_ag_extent+0x297/0x640
> >> [84567.084000]  [] xfs_alloc_fix_freelist+0x1d1/0x4c0
> >> [84567.084000]  [] xfs_alloc_vextent+0x1eb/0x4b0
> >> [84567.084000]  [] xfs_bmap_btalloc+0x3bb/0x8f0
> >> [84567.084000]  [] xfs_bmap_alloc+0x21/0x40
> >> [84567.084000]  [] xfs_bmapi+0xdbf/0x1450
> >> [84567.084000]  [] xfs_iomap_write_allocate+0x2ba/0x520
> >> [84567.084000]  [] xfs_iomap+0x45b/0x470
> >> [84567.084000]  [] xfs_bmap+0x2c/0x40
> >> [84567.084000]  [] xfs_map_blocks+0x3c/0x80
> >> [84567.084000]  [] xfs_page_state_convert+0x2f3/0x670
> >> [84567.084000]  [] xfs_vm_writepage+0x5a/0xf0
> >> [84567.084000]  [] generic_writepages+0x226/0x360
> >> [84567.084000]  [] xfs_vm_writepages+0x24/0x60
> >> [84567.084000]  [] do_writepages+0x2c/0x50
> >> [84567.084000]  [] __sync_single_inode+0x59/0x1f0
> >> [84567.084000]  [] __writeback_single_inode+0x44/0x1d0
> >> [84567.084000]  [] sync_sb_inodes+0x1c9/0x2e0
> >> [84567.084000]  [] writeback_inodes+0xce/0xe0
> >> [84567.084000]  [] wb_kupdate+0x73/0xf0
> >> [84567.084000]  [] __pdflush+0xce/0x1a0
> >> [84567.084000]  [] pdflush+0x25/0x30
> >> [84567.084000]  [] kthread+0x94/0xd0
> >> [84567.084000]  [] kernel_thread_helper+0x7/0x1c
> >> [84567.084000]  ===
> >> [84567.087000]  [] show_trace_log_lvl+0x1a/0x30
> >> [84567.087000]  [] do_IRQ: stack overflow: 328
> >> [84567.087000]  [] show_trace_log_lvl+0x1a/0x30
> >> [84567.087000]  [] show_trace+0x12/0x20
> >> [84567.087000]  [] dump_stack+0x15/0x20
> >> [84567.087000]  [] do_IRQ+0xd8/0xe0
> >> [84567.087000]  [] common_interrupt+0x2e/0x34
> >> [84567.087000]  [] printk+0x18/0x20
> >> [84567.087000]  [] print_trace_address+0x1d/0x30
> >> [84567.087000]  [] dump_trace+0x48/0xb0
> >> [84567.087000]  [] show_trace_log_lvl+0x1a/0x30
> >> [84567.087000]  [] show_trace+0x12/0x20
> >> [84567.087000]  [] dump_stack+0x15/0x20
> >> [84567.087000]  [] schedule+0x53a/0x680
> >> [84567.087000]  [] schedule_timeout+0x8a/0x90
> >> [84567.087000]  [] xlog_state_sync+0x21e/0x260
> >> [84567.087000]  [] _xfs_log_force+0x44/0x70
> >> [84567.087000]  [] xfs_alloc_search_busy+0xd2/0xe0
> >> [84567.087000]  [] xfs_alloc_get_freelist+0xe6/0x100
> >> [84567.087000]  [] xfs_alloc_split+0x1f/0x4c0
> >> [84567.087000]  [] xfs_alloc_insrec+0x35d/0x3b0
> >> [84567.087000]  [] xfs_alloc_insert+0x59/0xd0
> >> [84567.087000]  [] xfs_free_ag_extent+0x297/0x640
> >> [84567.087000]  [] xfs_alloc_fix_freelist+0x1d1/0x4c0
> >> [84567.087000]  [] xfs_alloc_vextent+0x1eb/0x4b0
> >> [84567.087000]  [] xfs_bmap_btalloc+0x3bb/0x8f0
> >> [84567.087000]  [] xfs_bmap_alloc+0x21/0x40
> >> [84567.087000]  [] xfs_bmapi+0xdbf/0x1450
> >> [84567.087000]  [] xfs_iomap_write_allocate+0x2ba/0x520
> >> [84567.087000]  [] xfs_iomap+0x45b/0x470
> >> [84567.087000]  [] xfs_bmap+0x2c/0x40
> >> [84567.087000]  [] xfs_map_blocks+0x3c/0x80
> >> [84567.087000]  [] xfs_page_state_convert+0x2f3/0x670
> >> [84567.087000]  [] xfs_vm_writepage+0x5a/0xf0
> >> [84567.087000]  [] generic_writepages+0x226/0x360
> >> [84567.087000]  [] xfs_vm_writepages+0x24/0x60
> >> [84567.087000]  [] do_writepages+0x2c/0x50
> >> [84567.087000]  [] __sync_single_inode+0x59/0x1f0
> >> [84567.087000]  [] __writeback_single_inode+0x44/0x1d0
> >> [84567.087000]  [] sync_sb_inodes+0x1c9/0x2e0
> >> [84567.087000]  [] writeback_inodes+0xce/0xe0
> >> [84567.087000]  [] wb_kupdate+0x73/0xf0
> >> [84567.087000]  [] __pdflush+0xce/0x1a0
> >> [84567.087000]  [] pdflush+0x25/0x30
> >> [84567.087000]  [] kthread+0x94/0xd0
> >> [84567.087000]  [] kernel_thread_helper+0x7/0x1c
> >> [84567.087000] BUG: unable to handle kernel paging request at virtual 
> >> address 8034
> >> [84567.087000]

Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)

2007-05-07 Thread Simon Arlott 

On 08/05/07 00:23, Andrew Morton wrote:

On Mon, 07 May 2007 23:58:36 +0100
Simon Arlott <[EMAIL PROTECTED]> wrote:


I've just got this under mainline too now 
(0ec54aa8af5e6faa346aa55a1ad15ee6c25bb42d 2007-05-05 22:08:06):

[84567.084000] BUG: scheduling while atomic: pdflush/0xeff84acf/186
[84567.084000] INFO: lockdep is turned off.
[84567.084000] do_IRQ: stack overflow: 440
[84567.084000]  [] show_trace_log_lvl+0x1a/0x30
[84567.084000]  [] show_trace+0x12/0x20
[84567.084000]  [] dump_stack+0x15/0x20
[84567.084000]  [] do_IRQ+0xd8/0xe0
[84567.084000]  [] common_interrupt+0x2e/0x34
[84567.084000]  [] printk+0x18/0x20
[84567.084000]  [] debug_show_held_locks+0x23/0x30
[84567.084000]  [] schedule+0x52a/0x680
[84567.084000]  [] schedule_timeout+0x8a/0x90
[84567.084000]  [] xlog_state_sync+0x21e/0x260
[84567.084000]  [] _xfs_log_force+0x44/0x70
[84567.084000]  [] xfs_alloc_search_busy+0xd2/0xe0
[84567.084000]  [] xfs_alloc_get_freelist+0xe6/0x100
[84567.084000]  [] xfs_alloc_split+0x1f/0x4c0
[84567.084000]  [] xfs_alloc_insrec+0x35d/0x3b0
[84567.084000]  [] xfs_alloc_insert+0x59/0xd0
[84567.084000]  [] xfs_free_ag_extent+0x297/0x640
[84567.084000]  [] xfs_alloc_fix_freelist+0x1d1/0x4c0
[84567.084000]  [] xfs_alloc_vextent+0x1eb/0x4b0
[84567.084000]  [] xfs_bmap_btalloc+0x3bb/0x8f0
[84567.084000]  [] xfs_bmap_alloc+0x21/0x40
[84567.084000]  [] xfs_bmapi+0xdbf/0x1450
[84567.084000]  [] xfs_iomap_write_allocate+0x2ba/0x520
[84567.084000]  [] xfs_iomap+0x45b/0x470
[84567.084000]  [] xfs_bmap+0x2c/0x40
[84567.084000]  [] xfs_map_blocks+0x3c/0x80
[84567.084000]  [] xfs_page_state_convert+0x2f3/0x670
[84567.084000]  [] xfs_vm_writepage+0x5a/0xf0
[84567.084000]  [] generic_writepages+0x226/0x360
[84567.084000]  [] xfs_vm_writepages+0x24/0x60
[84567.084000]  [] do_writepages+0x2c/0x50
[84567.084000]  [] __sync_single_inode+0x59/0x1f0
[84567.084000]  [] __writeback_single_inode+0x44/0x1d0
[84567.084000]  [] sync_sb_inodes+0x1c9/0x2e0
[84567.084000]  [] writeback_inodes+0xce/0xe0
[84567.084000]  [] wb_kupdate+0x73/0xf0
[84567.084000]  [] __pdflush+0xce/0x1a0
[84567.084000]  [] pdflush+0x25/0x30
[84567.084000]  [] kthread+0x94/0xd0
[84567.084000]  [] kernel_thread_helper+0x7/0x1c
[84567.084000]  ===
[84567.087000]  [] show_trace_log_lvl+0x1a/0x30
[84567.087000]  [] do_IRQ: stack overflow: 328
[84567.087000]  [] show_trace_log_lvl+0x1a/0x30
[84567.087000]  [] show_trace+0x12/0x20
[84567.087000]  [] dump_stack+0x15/0x20
[84567.087000]  [] do_IRQ+0xd8/0xe0
[84567.087000]  [] common_interrupt+0x2e/0x34
[84567.087000]  [] printk+0x18/0x20
[84567.087000]  [] print_trace_address+0x1d/0x30
[84567.087000]  [] dump_trace+0x48/0xb0
[84567.087000]  [] show_trace_log_lvl+0x1a/0x30
[84567.087000]  [] show_trace+0x12/0x20
[84567.087000]  [] dump_stack+0x15/0x20
[84567.087000]  [] schedule+0x53a/0x680
[84567.087000]  [] schedule_timeout+0x8a/0x90
[84567.087000]  [] xlog_state_sync+0x21e/0x260
[84567.087000]  [] _xfs_log_force+0x44/0x70
[84567.087000]  [] xfs_alloc_search_busy+0xd2/0xe0
[84567.087000]  [] xfs_alloc_get_freelist+0xe6/0x100
[84567.087000]  [] xfs_alloc_split+0x1f/0x4c0
[84567.087000]  [] xfs_alloc_insrec+0x35d/0x3b0
[84567.087000]  [] xfs_alloc_insert+0x59/0xd0
[84567.087000]  [] xfs_free_ag_extent+0x297/0x640
[84567.087000]  [] xfs_alloc_fix_freelist+0x1d1/0x4c0
[84567.087000]  [] xfs_alloc_vextent+0x1eb/0x4b0
[84567.087000]  [] xfs_bmap_btalloc+0x3bb/0x8f0
[84567.087000]  [] xfs_bmap_alloc+0x21/0x40
[84567.087000]  [] xfs_bmapi+0xdbf/0x1450
[84567.087000]  [] xfs_iomap_write_allocate+0x2ba/0x520
[84567.087000]  [] xfs_iomap+0x45b/0x470
[84567.087000]  [] xfs_bmap+0x2c/0x40
[84567.087000]  [] xfs_map_blocks+0x3c/0x80
[84567.087000]  [] xfs_page_state_convert+0x2f3/0x670
[84567.087000]  [] xfs_vm_writepage+0x5a/0xf0
[84567.087000]  [] generic_writepages+0x226/0x360
[84567.087000]  [] xfs_vm_writepages+0x24/0x60
[84567.087000]  [] do_writepages+0x2c/0x50
[84567.087000]  [] __sync_single_inode+0x59/0x1f0
[84567.087000]  [] __writeback_single_inode+0x44/0x1d0
[84567.087000]  [] sync_sb_inodes+0x1c9/0x2e0
[84567.087000]  [] writeback_inodes+0xce/0xe0
[84567.087000]  [] wb_kupdate+0x73/0xf0
[84567.087000]  [] __pdflush+0xce/0x1a0
[84567.087000]  [] pdflush+0x25/0x30
[84567.087000]  [] kthread+0x94/0xd0
[84567.087000]  [] kernel_thread_helper+0x7/0x1c
[84567.087000] BUG: unable to handle kernel paging request at virtual address 
8034
[84567.087000]  printing eip:
[84567.087000] b0104e36
[84567.087000] *pde = 
[84567.087000] Oops:  [#1]
[84567.087000] PREEMPT
[84567.087000] Modules linked in: drbd mt352 saa7134_dvb dvb_pll video_buf_dvb 
dvb_core
[84567.087000] CPU:0
[84567.087000] EIP:0060:[]Not tainted VLI
[84567.087000] EFLAGS: 00010046   (2.6.21-git #197)
[84567.087000] EIP is at dump_trace+0x66/0xb0
[84567.087000] eax:    ebx: b18f6fe0   ecx: b06323ec   edx: b05afc71
[84567.087000] esi: 8000   edi: 8ffd   ebp: b18f6138   esp: b18f6120
[84567.087000] ds: 007b

Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)

2007-05-07 Thread Andrew Morton 
On Mon, 07 May 2007 23:58:36 +0100
Simon Arlott <[EMAIL PROTECTED]> wrote:

> 
> I've just got this under mainline too now 
> (0ec54aa8af5e6faa346aa55a1ad15ee6c25bb42d 2007-05-05 22:08:06):
> 
> [84567.084000] BUG: scheduling while atomic: pdflush/0xeff84acf/186
> [84567.084000] INFO: lockdep is turned off.
> [84567.084000] do_IRQ: stack overflow: 440
> [84567.084000]  [] show_trace_log_lvl+0x1a/0x30
> [84567.084000]  [] show_trace+0x12/0x20
> [84567.084000]  [] dump_stack+0x15/0x20
> [84567.084000]  [] do_IRQ+0xd8/0xe0
> [84567.084000]  [] common_interrupt+0x2e/0x34
> [84567.084000]  [] printk+0x18/0x20
> [84567.084000]  [] debug_show_held_locks+0x23/0x30
> [84567.084000]  [] schedule+0x52a/0x680
> [84567.084000]  [] schedule_timeout+0x8a/0x90
> [84567.084000]  [] xlog_state_sync+0x21e/0x260
> [84567.084000]  [] _xfs_log_force+0x44/0x70
> [84567.084000]  [] xfs_alloc_search_busy+0xd2/0xe0
> [84567.084000]  [] xfs_alloc_get_freelist+0xe6/0x100
> [84567.084000]  [] xfs_alloc_split+0x1f/0x4c0
> [84567.084000]  [] xfs_alloc_insrec+0x35d/0x3b0
> [84567.084000]  [] xfs_alloc_insert+0x59/0xd0
> [84567.084000]  [] xfs_free_ag_extent+0x297/0x640
> [84567.084000]  [] xfs_alloc_fix_freelist+0x1d1/0x4c0
> [84567.084000]  [] xfs_alloc_vextent+0x1eb/0x4b0
> [84567.084000]  [] xfs_bmap_btalloc+0x3bb/0x8f0
> [84567.084000]  [] xfs_bmap_alloc+0x21/0x40
> [84567.084000]  [] xfs_bmapi+0xdbf/0x1450
> [84567.084000]  [] xfs_iomap_write_allocate+0x2ba/0x520
> [84567.084000]  [] xfs_iomap+0x45b/0x470
> [84567.084000]  [] xfs_bmap+0x2c/0x40
> [84567.084000]  [] xfs_map_blocks+0x3c/0x80
> [84567.084000]  [] xfs_page_state_convert+0x2f3/0x670
> [84567.084000]  [] xfs_vm_writepage+0x5a/0xf0
> [84567.084000]  [] generic_writepages+0x226/0x360
> [84567.084000]  [] xfs_vm_writepages+0x24/0x60
> [84567.084000]  [] do_writepages+0x2c/0x50
> [84567.084000]  [] __sync_single_inode+0x59/0x1f0
> [84567.084000]  [] __writeback_single_inode+0x44/0x1d0
> [84567.084000]  [] sync_sb_inodes+0x1c9/0x2e0
> [84567.084000]  [] writeback_inodes+0xce/0xe0
> [84567.084000]  [] wb_kupdate+0x73/0xf0
> [84567.084000]  [] __pdflush+0xce/0x1a0
> [84567.084000]  [] pdflush+0x25/0x30
> [84567.084000]  [] kthread+0x94/0xd0
> [84567.084000]  [] kernel_thread_helper+0x7/0x1c
> [84567.084000]  ===
> [84567.087000]  [] show_trace_log_lvl+0x1a/0x30
> [84567.087000]  [] do_IRQ: stack overflow: 328
> [84567.087000]  [] show_trace_log_lvl+0x1a/0x30
> [84567.087000]  [] show_trace+0x12/0x20
> [84567.087000]  [] dump_stack+0x15/0x20
> [84567.087000]  [] do_IRQ+0xd8/0xe0
> [84567.087000]  [] common_interrupt+0x2e/0x34
> [84567.087000]  [] printk+0x18/0x20
> [84567.087000]  [] print_trace_address+0x1d/0x30
> [84567.087000]  [] dump_trace+0x48/0xb0
> [84567.087000]  [] show_trace_log_lvl+0x1a/0x30
> [84567.087000]  [] show_trace+0x12/0x20
> [84567.087000]  [] dump_stack+0x15/0x20
> [84567.087000]  [] schedule+0x53a/0x680
> [84567.087000]  [] schedule_timeout+0x8a/0x90
> [84567.087000]  [] xlog_state_sync+0x21e/0x260
> [84567.087000]  [] _xfs_log_force+0x44/0x70
> [84567.087000]  [] xfs_alloc_search_busy+0xd2/0xe0
> [84567.087000]  [] xfs_alloc_get_freelist+0xe6/0x100
> [84567.087000]  [] xfs_alloc_split+0x1f/0x4c0
> [84567.087000]  [] xfs_alloc_insrec+0x35d/0x3b0
> [84567.087000]  [] xfs_alloc_insert+0x59/0xd0
> [84567.087000]  [] xfs_free_ag_extent+0x297/0x640
> [84567.087000]  [] xfs_alloc_fix_freelist+0x1d1/0x4c0
> [84567.087000]  [] xfs_alloc_vextent+0x1eb/0x4b0
> [84567.087000]  [] xfs_bmap_btalloc+0x3bb/0x8f0
> [84567.087000]  [] xfs_bmap_alloc+0x21/0x40
> [84567.087000]  [] xfs_bmapi+0xdbf/0x1450
> [84567.087000]  [] xfs_iomap_write_allocate+0x2ba/0x520
> [84567.087000]  [] xfs_iomap+0x45b/0x470
> [84567.087000]  [] xfs_bmap+0x2c/0x40
> [84567.087000]  [] xfs_map_blocks+0x3c/0x80
> [84567.087000]  [] xfs_page_state_convert+0x2f3/0x670
> [84567.087000]  [] xfs_vm_writepage+0x5a/0xf0
> [84567.087000]  [] generic_writepages+0x226/0x360
> [84567.087000]  [] xfs_vm_writepages+0x24/0x60
> [84567.087000]  [] do_writepages+0x2c/0x50
> [84567.087000]  [] __sync_single_inode+0x59/0x1f0
> [84567.087000]  [] __writeback_single_inode+0x44/0x1d0
> [84567.087000]  [] sync_sb_inodes+0x1c9/0x2e0
> [84567.087000]  [] writeback_inodes+0xce/0xe0
> [84567.087000]  [] wb_kupdate+0x73/0xf0
> [84567.087000]  [] __pdflush+0xce/0x1a0
> [84567.087000]  [] pdflush+0x25/0x30
> [84567.087000]  [] kthread+0x94/0xd0
> [84567.087000]  [] kernel_thread_helper+0x7/0x1c
> [84567.087000] BUG: unable to handle kernel paging request at virtual address 
> 8034
> [84567.087000]  printing eip:
> [84567.087000] b0104e36
> [84567.087000] *pde = 
> [84567.087000] Oops:  [#1]
> [84567.087000] PREEMPT
> [84567.087000] Modules linked in: drbd mt352 saa7134_dvb dvb_pll 
> video_buf_dvb dvb_core
> [84567.087000] CPU:0
> [84567.087000] EIP:0060:[]Not tainted VLI
> [84567.087000] EFLAGS: 00010046   (2.6.21-git #197)
> [84567.087000] EIP is at dump_trace+0x66/0xb0
> [8456

sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)

2007-05-07 Thread Simon Arlott 

On 06/05/07 21:54, Andrew Morton wrote:

On Sun, 06 May 2007 21:36:32 +0100 Simon Arlott <[EMAIL PROTECTED]> wrote:


On 05/05/07 09:49, Andrew Morton wrote:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
Not sure exactly what's going on here, but it happened with a lock held on my 
(XFS) filesystem while compiling part of the kernel because I can't do anything 
with it now.


[ 1128.122000] BUG: sleeping function called from invalid context at 
block/cfq-iosched.c:1895
[ 1128.122000] in_atomic():1, irqs_disabled():0
[ 1128.122000] INFO: lockdep is turned off.
[ 1128.122000] BUG: unable to handle kernel paging request at virtual address 
8b0c4034
[ 1128.122000]  printing eip:
[ 1128.122000] b0104e36
[ 1128.123000] *pde = 
[ 1128.123000] Oops:  [#1]
[ 1128.123000] PREEMPT
[ 1128.123000] Modules linked in: drbd mt352 saa7134_dvb dvb_pll video_buf_dvb 
dvb_core
[ 1128.123000] CPU:0
[ 1128.123000] EIP:0060:[]Not tainted VLI
[ 1128.123000] EFLAGS: 00010246   (2.6.21-git #195)
[ 1128.123000] EIP is at dump_trace+0x66/0xb0
[ 1128.123000] eax:    ebx: b18f6fd0   ecx: b06323ec   edx: b05afc71
[ 1128.123000] esi: 8b0c4000   edi: 8b0c4ffd   ebp: b18f6fd0   esp: b18f6fb8
[ 1128.123000] ds: 007b   es: 007b   fs:   gs:   ss: 0068
[ 1128.123000] Process pdflush (pid: 186, ti=b18f6000 task=eff88b10 
task.ti=b18f7000)
[ 1128.123000] Stack: b000205d  fffc b05b9937 efd1adb4 0010 
b18f6ff0 b0104f3a
[ 1128.123000]b06323ec b05b9937  b05d33e6 efd1adb4 b05d33e6 
b18f7000 b0104f62
[ 1128.123000]b05b9937 b18f700c
[ 1128.123000] Call Trace:
[ 1128.123000]  [] show_trace_log_lvl+0x1a/0x30
[ 1128.123000]  [] show_stack_log_lvl+0x8b/0xb0
[ 1128.123000]  [] show_registers+0x1c3/0x320
[ 1128.123000]  [] die+0x105/0x230
[ 1128.123000]  [] do_page_fault+0x2cf/0x5b0
[ 1128.123000]  [] error_code+0x6a/0x70
[ 1128.123000]  [] show_trace_log_lvl+0x1a/0x30
[ 1128.123000]  [] show_trace+0x12/0x20
[ 1128.123000]  ===
[ 1128.123000] Code: 18 8b 4d 08 8b 45 0c 8b 53 04 ff 51 08 8b 03 39 d8 76 06 89 c3 
39 f3 77 e4 8b 4d 08 ba 71 fc 5a b0 8b 45 0c ff 51 0c 85 c0 78 38 <8b> 76 34 85 
f6 74 31 8d 76 00 e8 bb d7 00 00 eb b3 89 eb eb af
[ 1128.123000] EIP: [] dump_trace+0x66/0xb0 SS:ESP 0068:b18f6fb8


Mess.  Someone incorrectly called the IO scheduler under a spinlock (or
similar), CFQ tried to do a dump_stack(), but the dump_stack() code
exploded.  Usually this happens when the x86_64 tree contains stacktrace
improvements, but the unwinder (at least) wasn't present in -mm1.

How come those addresses are 0xb0.., btw?  You're running a different
vm split?


I've just got this under mainline too now 
(0ec54aa8af5e6faa346aa55a1ad15ee6c25bb42d 2007-05-05 22:08:06):

[84567.084000] BUG: scheduling while atomic: pdflush/0xeff84acf/186
[84567.084000] INFO: lockdep is turned off.
[84567.084000] do_IRQ: stack overflow: 440
[84567.084000]  [] show_trace_log_lvl+0x1a/0x30
[84567.084000]  [] show_trace+0x12/0x20
[84567.084000]  [] dump_stack+0x15/0x20
[84567.084000]  [] do_IRQ+0xd8/0xe0
[84567.084000]  [] common_interrupt+0x2e/0x34
[84567.084000]  [] printk+0x18/0x20
[84567.084000]  [] debug_show_held_locks+0x23/0x30
[84567.084000]  [] schedule+0x52a/0x680
[84567.084000]  [] schedule_timeout+0x8a/0x90
[84567.084000]  [] xlog_state_sync+0x21e/0x260
[84567.084000]  [] _xfs_log_force+0x44/0x70
[84567.084000]  [] xfs_alloc_search_busy+0xd2/0xe0
[84567.084000]  [] xfs_alloc_get_freelist+0xe6/0x100
[84567.084000]  [] xfs_alloc_split+0x1f/0x4c0
[84567.084000]  [] xfs_alloc_insrec+0x35d/0x3b0
[84567.084000]  [] xfs_alloc_insert+0x59/0xd0
[84567.084000]  [] xfs_free_ag_extent+0x297/0x640
[84567.084000]  [] xfs_alloc_fix_freelist+0x1d1/0x4c0
[84567.084000]  [] xfs_alloc_vextent+0x1eb/0x4b0
[84567.084000]  [] xfs_bmap_btalloc+0x3bb/0x8f0
[84567.084000]  [] xfs_bmap_alloc+0x21/0x40
[84567.084000]  [] xfs_bmapi+0xdbf/0x1450
[84567.084000]  [] xfs_iomap_write_allocate+0x2ba/0x520
[84567.084000]  [] xfs_iomap+0x45b/0x470
[84567.084000]  [] xfs_bmap+0x2c/0x40
[84567.084000]  [] xfs_map_blocks+0x3c/0x80
[84567.084000]  [] xfs_page_state_convert+0x2f3/0x670
[84567.084000]  [] xfs_vm_writepage+0x5a/0xf0
[84567.084000]  [] generic_writepages+0x226/0x360
[84567.084000]  [] xfs_vm_writepages+0x24/0x60
[84567.084000]  [] do_writepages+0x2c/0x50
[84567.084000]  [] __sync_single_inode+0x59/0x1f0
[84567.084000]  [] __writeback_single_inode+0x44/0x1d0
[84567.084000]  [] sync_sb_inodes+0x1c9/0x2e0
[84567.084000]  [] writeback_inodes+0xce/0xe0
[84567.084000]  [] wb_kupdate+0x73/0xf0
[84567.084000]  [] __pdflush+0xce/0x1a0
[84567.084000]  [] pdflush+0x25/0x30
[84567.084000]  [] kthread+0x94/0xd0
[84567.084000]  [] kernel_thread_helper+0x7/0x1c
[84567.084000]  ===
[84567.087000]  [] show_trace_log_lvl+0x1a/0x30
[84567.087000]  [] do_IRQ: stack overflow: 328
[84567.087000]  [] show_trace_log_lvl+0x1a/0x30
[84567.087000]  [] show_trace+0x1