From owner-cvs-all  Tue Jul  4 23: 1:42 2000
Delivered-To: cvs-all@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 33AB737BDB3; Tue,  4 Jul 2000 23:01:34 -0700 (PDT)
	(envelope-from imp@FreeBSD.org)
Received: (from imp@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) id XAA81081;
	Tue, 4 Jul 2000 23:01:34 -0700 (PDT)
	(envelope-from imp@FreeBSD.org)
Message-Id: <200007050601.XAA81081@freefall.freebsd.org>
From: Warner Losh <imp@FreeBSD.org>
Date: Tue, 4 Jul 2000 23:01:34 -0700 (PDT)
To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: cvs commit: src/sys/kern subr_disk.c
X-FreeBSD-CVS-Branch: HEAD
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

imp         2000/07/04 23:01:34 PDT

  Modified files:
    sys/kern             subr_disk.c 
  Log:
  End two weeks of on and off debugging.  Fix the crash on the Nth
  insertion of a CF card, for random values of N > 1.  With these fixes,
  I've been able to do 100 insert/remove of the cards w/o a crash with
  lots of system activity going on that in the past would help trigger
  the crash.
  
  The problem:
  
  FreeBSD creates dev_t's on the fly as they are needed and never
  destroys them.  These dev_t's point to a struct disk that is used for
  housekeeping on the disk.  When a device goes away, the struct disk
  pointer becomes a dangling pointer.  Sometimes when the device comes
  back, the pointer will point to the new struct disk (in which case the
  insertion will work).  Other times it won't (especially if any length
  of time has passed, since it is dependent on memory returned from
  malloc).
  
  The Fix:
  
  There is one of these dev_t's that is always correct.  The
  device for the WHOLE_DISK_SLICE is always right.  It gets set at
  create_disk() time.  So, the fix is to spend a little CPU time and
  lookup the WHOLE_DISK_SLICE dev_t and use the si_disk from that in
  preference to the one that's in the device asking to do the I/O.  In
  addition, we change the test of si_disk == NULL meaning that the dev
  needed to inherit properties from the pdev to dev->si_disk !=
  pdev->si_disk.  This test is a little stronger than the previous test,
  but can sometimes be fooled into not inheriting.  However, the results
  of this fooling are that the old values will be used, which will
  generally always be the same as before.  si_drv[12] are the only
  values that are copied that might pose a problem.  They tend to change
  as the si_disk field would change, so it is a hole, but it is a small
  hole.
  
  One could correctly argue that one should replace much of this code
  with something much much better.  I would be on the pro side of that
  argument.
  
  Reviewed by: phk (who also ported the original patch to current)
  Sponsored by: Timing Solutions
  
  Revision  Changes    Path
  1.29      +28 -25    src/sys/kern/subr_disk.c



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message