Re: Major 2.1.x problem index

Eric W. Biederman (ebiederm+eric@npwt.net)
19 Jun 1998 23:49:16 -0500


>>>>> "AC" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

>> - Page cache flaws: swapoff does no longer crash on sys5 memory
AC> Ok will fix

Just to be clear I wrote a patch and Stephen C Tweedie said he would
double check it and send it to Linus. But it isn't in kernel 2.1.106
He said be busy until after Usenix...

Now comments on some of the bugs:
* 2.1.10x fs unload race
invalidate inodes is moved after put_super. Thats a bug as
it uses dispose_list()

I think I know how to fix this fairly simply, we need a new function
to call just before put_super, to close any remaining inodes the
filesystem has cached. devptyfs needs this.

I sent mail to H. Peter Anvin <hpa@zytor.com> who I believe is
responsible to:
a) see if I could understand the change in 2.1.93 (where this
appeared) The moving of the super block locking puzzles me a lot.
b) to hopefully coordinate a fix for this problem.

So far he hasn't replied. And I'm not totally confident I can fix the
code right until I understand why we moved the lock super calls. If I
don't get some feed back soon I'll try anyway.

* Page cache flaws
Can't handle dirty files, swapoff can crash with sys5 memory.

This sounds a lot like the stuff I have been working with.
In respect to the "Can't handle dirty files" are you thinking in terms
of dirty pages in the page cache?

It would be neat to be able to get what I have been working on in a
basic form into the kernel before 2.3, because there are a lot neat
things that can be done with this... However with the code/feature
freeze I suspected this was a an impossibility.

The really important detail to implement to get my code ready is a
pgflush deamon like that handles all of the appropriate flushing
needed. It's half done, there are a lot of angles to look at.

If this code has an honest chance at getting into 2.1 I'll work hard
at getting a patch together that is stable and doesn't change too many
other things. In the long run there appear to a lot of things this
would simplify.

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu