Re: [PATCH] only irq-safe atomic ops

[Andrew Morton <akpm@zip.com.au>]

Mike Fedyk wrote:
> 
> On Sat, Feb 23, 2002 at 02:34:49PM -0800, Andrew Morton wrote:
> > Unfortunately I seem to have found a bug in existing ext2, a bug
> > in existing block_write_full_page, a probable bug in the aic7xxx
> > driver, and an oops in the aic7xxx driver.  So progress has slowed
> > down a bit :(
> 
> Are these bugs in 2.4 also?

The test case is:

- 120 megabyte filesystem, 1k blocksize ext2.  SMP.
- run `dbench 64 2>/dev/null >/dev/null', as root (dunno
  if rootness matters, but it affects ext2 allocation policy).

This really hammers the out-of-space handling.

We get a stream of `__block_prepare_write: zeroing uptodate buffer'
messages.  I added that message.  I shall work out whether there's
a bug, or if the message just gets killed.  This happens in 2.4 also.

We get a handful of `VFS: brelse: Trying to free free buffer' messages,
coming from this code:

        /* Next simple case - plain lookup or failed read of indirect block */
        if (!create || err == -EIO) {
cleanup:
                while (partial > chain) {
                        brelse(partial->bh);
                        partial--;
                }

in ext2_get_block().  This only happens in 2.5.  It happens on uniprocessor.
Possibly a bug introduced by the changed ext2 locking in 2.5.  I have not
investigated further.


With my I/O scheduling changes the SCSI driver gets all upset about
data overruns or such.  This may be my fault.  It's a 2.5 issue.

During recovery from the data overrun, the SCSI driver oopses
over manipulation of a dodgy-looking timer struct.

-