Messages in this thread |  | | | Subject | Re: Major 2.1.x problem index | | From | (Eric W. Biederman) | | Date | 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
|  |