terryl@tekcrl.UUCP (10/30/85)
As we left our intrepid debugger in the last episode, it was theorized
that somehow when a program was relinked, text pages from the previous running
of said program (which are remembered in case the program is run again soon
so the text pages do not have to be read in from the disk) were not being
invalidated in the cache, and the blame was given to the kernel routine rwip.
Well, folks, part of the theory was true, and part wasn't. The part that
was true was that text pages were not being invalidated in the cache. The
part that wasn't true was the bug was in the kernel routine rwip(well, almost
not true).
What happens is this: the kernel routine rwip calls another kernel
routine bmap. bmap maps a logical block in a file to a disk block, and returns
that disk block. In the case of writing a file, rwip then calls the kernel
routine-pair mfind/munhash to invalidate text pages of the file from a previous
running of the file. This is all fine and good, except for one small problem:
the way the file system works, all disk blocks of a file are composed of blocks
with a size that is determined when the file system the file resides on was
created(called the "basic block" size), except for the last block of a file
(it is composed of a block called a "fragment", which is just a "basic block"
split up into a smaller chunk). The problem is when a file is growing, that
last block that was a "fragment" must somehow become a "basic block". It is
the routine bmap that does this conversion, AND THAT IS WHERE THE BUG IS.
When a "fragment" is converted to a "basic block" by bmap, BMAP DOES NOT TRY
TO INVALIDATE THE CACHE FOR THE NEWLY CONVERTED "BASIC BLOCK".
I must admit that this is a pretty obscure bug, and probably won't
occur on systems with heavy loads, since a page that is cached still may be
allocated for another use, and when that happens the cache is invalidated,
as it should be. I don't have a fix for it (yet), but the fix should be
pretty obvious: take the cache invalidation code out of rwip and put it in
bmap, where it really belongs. Does anyone know if this is fixed in 4.3???
Terry Laskodi
of
Tektronix