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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070508061810.GI32602149@melbourne.sgi.com>
Date:	Tue, 8 May 2007 16:18:10 +1000
From:	David Chinner <dgc@....com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Simon Arlott <simon@...e.lp0.eu>, linux-kernel@...r.kernel.org,
	David Chinner <dgc@....com>
Subject: Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)

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 <jeremy@...p.org> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/