[Top] [All Lists]

re[2]: Detected potential for stack overflows, stack left: 796 bytes

To: Steve Lord <lord@xxxxxxx>, Andi Kleen <ak@xxxxxxx>
Subject: re[2]: Detected potential for stack overflows, stack left: 796 bytes
From: Greg Freemyer <freemyer@xxxxxxxxxxxxxxxxx>
Date: Thu, 22 Aug 2002 16:40:35 -0400
Cc: Eric Sandeen <sandeen@xxxxxxx>, <linux-xfs@xxxxxxxxxxx>
Organization: The NorcrossGroup
Sender: owner-linux-xfs@xxxxxxxxxxx
If the V1.2 release is going to be significantly delayed by these issues, 
    and if these issues are also in xfs v1.1 
    and the QA load is not too high, 
then maybe you could release a xfs 1.1.1 or some such and just list those 
issues in the release notes.

(I almost feel like I'm writing code with the above overly complex sentence 

I know SuSE uses the aa kernels and probably other distributions as well.  And 
of course the Redhat ISO's you have are xfs 1.1.

That likely means you have 1000s or 10s of 1000s of xfs 1.1 users that are not 
getting the benefit of the last several months of improvements.

Unfortunately, I'm one :(

I guess the real issue is that I'm just going to have to make the next step of 
working with the CVS code.  (Not today, but maybe soon.)

Greg Freemyer
Internet Engineer
Deployment and Integration Specialist
Compaq ASE - Tru64 v4, v5
Compaq Master ASE - SAN Architect
The Norcross Group

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