I've attached a very simple patch for a bug in find_candidate(). The
problem was that as part of deciding whether a given buffer is a good
candidate, can_reclaim() checks whether the buffer is dirty, and if so
called refile_buffer() to place it on the dirty queue. This has two
undesirable side effects: since find_candidate() hasn't cached the next
buffer pointer, it nows searchs the dirty buffer list, where it's very
unlikely to find a reclaimable buffer.
More seriously, if the added dirty buffer passes the limit to start
bdflush, the resulting blockage will redo all of the queues, and may
allow other tasks to claim (or even free) a previously chosen buffer in
the candidate[] array. This is the likely cause of the oopses reported
in refill_freelist().
I think refill_freelist() needs some further work, but this should clear
up some of the problems with the current code. The patch is against
2.0.30.
Regards,
Bill
--------------69418CA8415FC1759C9B2608
Content-Type: text/plain; charset=us-ascii; name="buffer_rf-patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="buffer_rf-patch"
--- fs/buffer.c.old Sun Apr 27 15:54:43 1997
+++ fs/buffer.c Tue Jul 1 13:38:26 1997
@@ -546,7 +546,7 @@
if (mem_map[MAP_NR((unsigned long) bh->b_data)].count != 1 ||
buffer_dirty(bh)) {
- refile_buffer(bh);
+ /* WSH: don't attempt to refile here! */
return 0;
}
--------------69418CA8415FC1759C9B2608--