Panic: munhash

[Rick Adams]

>From mccallum at opus.ARPA Wed Dec 21 15:14:15 1983
Date: 20 Dec 83 6:38:33-PST (Tue)
From: seismo!hplabs!hao!cires!nbires!opus!mccallum at ucb-vax
Subject: Re: panic: munhash (4.2BSD crash)

The bug fix for the panic: munhash in 4.2/4.1c has been posted.
The posted fix did not explain under what conditions the panic occurs.
The problem shows up when you have a LARGE file system and use a debugger
on program that resides in the part of the file system that makes the block
number field use all 20 bits.  The fix is as follows:


   Path: opus!nbires!cires!hao!hplabs!sri-unix!RWS at mit-xx
   From: RWS%mit-xx at sri-unix.UUCP
   Newsgroups: net.unix-wizards
   Subject: sundry 4.2 bugs
   Message-ID: <13280 at sri-arpa.UUCP>
   Date: Wed, 2-Nov-83 15:15:00 MST
   Article-I.D.: sri-arpa.13280
   Posted: Wed Nov  2 15:15:00 1983
   Date-Received: Thu, 3-Nov-83 18:47:16 MST
   Lines: 64

   Despite claims to the contrary, the block number sign extension problem still
   exists.  Berkeley put in a fix that should have worked, but a C compiler bug
   apparently keeps it from working.  In /sys/sys/vm_mem.c in memall() the code
         swapdev : mount[c->c_mdev].m_dev, (daddr_t)(u_long)c->c_blkno
   should be changed to
         swapdev : mount[c->c_mdev].m_dev, c->c_blkno
   and in /sys/vax/vm_machdep.c in chgprot() the code
             munhash(mount[c->c_mdev].m_dev, (daddr_t)(u_long)c->c_blkno);
   should be changed to
             munhash(mount[c->c_mdev].m_dev, c->c_blkno);
   because the C compiler apparently incorrectly folds the (daddr_t) and (u_long)
   together and sign extends anyway.  Simply taking out the (daddr_t)(u_long)
   works, although lint will probably complain about it.