From owner-freebsd-security  Wed Jan 27 18:22:20 1999
Return-Path: <owner-freebsd-security@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id SAA19985
          for freebsd-security-outgoing; Wed, 27 Jan 1999 18:22:20 -0800 (PST)
          (envelope-from owner-freebsd-security@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA19979
          for <security@FreeBSD.ORG>; Wed, 27 Jan 1999 18:22:16 -0800 (PST)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id NAA20754;
	Thu, 28 Jan 1999 13:22:06 +1100
Date: Thu, 28 Jan 1999 13:22:06 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199901280222.NAA20754@godzilla.zeta.org.au>
To: bde@zeta.org.au, dgilbert@velocet.net
Subject: Re: signal handling in urandom can cause lockup
Cc: security@FreeBSD.ORG
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

>	This is very interesting.  For some time (I use FreeBSD on my
>desktop as well as for 50 odd servers) my desktop machine has been
>exhibiting a freeze that seems to coinside with intense swapping or
>writing to the disk.  This 'freeze' survived the upgrade from 2.2.7 to
>3.0.

>	Now... my take on the situation had been that IDE is just
>evil.  I have burned out 3 drives (of different brands) in as many
>months (they ranged from 1 month to 1 year old).  I have on order a 9G
>SCSI drive to become the main system and swap drive under the
>assumption that scsi drives are going to be more dependable and will
>not freeze the system.

I have no problems with IDE, and this problem has very little to do with
IDE.  It is a general problem with devices that can transfer large amounts
of data without blocking (not just with slow devices like I said before,
except faster devices tend to limit the denial of service to a second
or two).  E.g., a modern IDE drive can transfer at a rate of 12-15MB/sec.
The default interface is 16-bit PIO mode 1-4 (where the BIOS decides the
mode number).  At best, this transfers data at 8.3MB/sec and takes 100%
of the CPU to do so.  Don't connect a modern IDE drive to this interface.

>	However, it does strike me as bogus that this kind of blocking
>happens.  Maybe this type of patch should be applied to devices in
>general.

It already applies to everything that calls uiomove(), including many
cases involving filesystem i/o.  It doesn't apply to paging or certain
optimised filesystem i/o.

Bruce

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