xfs
[Top] [All Lists]

Re: Detected potential for stack overflows, stack left: 796 bytes

To: Andi Kleen <ak@xxxxxxx>
Subject: Re: Detected potential for stack overflows, stack left: 796 bytes
From: Steve Lord <lord@xxxxxxx>
Date: 22 Aug 2002 14:12:47 -0500
Cc: Eric Sandeen <sandeen@xxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <20020822210134.A11739@wotan.suse.de>
References: <3D652F1A.3080005@Lehigh.EDU> <1030041962.8450.18.camel@stout.americas.sgi.com> <20020822205014.A9535@wotan.suse.de> <1030042219.10044.107.camel@jen.americas.sgi.com> <20020822210134.A11739@wotan.suse.de>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Thu, 2002-08-22 at 14:01, Andi Kleen wrote:
> On Thu, Aug 22, 2002 at 01:50:19PM -0500, Steve Lord wrote:
> > On Thu, 2002-08-22 at 13:50, Andi Kleen wrote:
> > > On Thu, Aug 22, 2002 at 01:46:02PM -0500, Eric Sandeen wrote:
> > > > Hi Jim - 
> > > > 
> > > > Hm, was just talking about this with Christoph.  :)
> > > > 
> > > > XFS does use a bit of stack, but the code in XFS 1.1 (which is, I think,
> > > > also in your -aa kernel) is probably much worse than what is currently
> > > > in CVS.  We're aware of the issue, and now apparently this same
> > > > stack-check code is in the 2.4.20-preX kernels - so we'll keep an eye on
> > > > it.  As far as your current situation... I guess maybe we'll have to
> > > > talk to Andrea about it, I don't know what he'll want to do about
> > > > updating XFS code in his tree.
> > > 
> > > He's waiting for XFS 1.2 for the next update.
> > 
> > And that one is a bit stalled right now. I think we have a number of
> > open issues to resolve before we call something a release again.
> 
> Could you quickly list them (just curious) ? 

Off the top of my head:

        hitting a bug in filemap.c unlocking an unlocked page, seems to
        be lvm related.

        corruption with the combination of fsx and heavy memory load
        for an fs with a blocksize less than a page - does not happen
        with the default 4K block size.

        a hang in unmount, or remount readonly - I only see this on
        my laptop after using some vpn software, but I do not think
        the vpn is related. I cannot hit it elsewhere, but something
        similar has been reported.

        the defragmenter seems to be able to go haywire and suck up
        cpu time.

        version 2 logs have some end cases to shake out - make a small
        log and pound on metadata really hard. If I make a larger log
        then I cannot hit this.

        An oops in xfs_iget - or a hang depending on who you are, seems
        to take very heavy load and a few cpus to hit.

Thats enough for now!

Steve

        
> 
> The only thing I have pending is a partial ioctl32 translation for x86-64
> (and possible ia64 too) for some XFS ioctls.
> 
> -Andi
-- 

Steve Lord                                      voice: +1-651-683-3511
Principal Engineer, Filesystem Software         email: lord@xxxxxxx


<Prev in Thread] Current Thread [Next in Thread>