From owner-cvs-all Mon May 21 19:47:45 2001 Delivered-To: cvs-all@freebsd.org Received: from superconductor.rush.net (superconductor.rush.net [208.9.155.8]) by hub.freebsd.org (Postfix) with ESMTP id 1175A37B422; Mon, 21 May 2001 19:47:40 -0700 (PDT) (envelope-from bright@superconductor.rush.net) Received: (from bright@localhost) by superconductor.rush.net (8.11.2/8.11.2) id f4M2ldv07614; Mon, 21 May 2001 22:47:39 -0400 (EDT) Date: Mon, 21 May 2001 22:47:38 -0400 From: Alfred Perlstein To: Greg Lehey Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/vinum vinumrequest.c Message-ID: <20010521224738.L17514@superconductor.rush.net> References: <200105220236.f4M2alK16427@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200105220236.f4M2alK16427@freefall.freebsd.org>; from grog@FreeBSD.org on Mon, May 21, 2001 at 07:36:47PM -0700 X-all-your-base: are belong to us. Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Greg Lehey [010521 22:37] wrote: > grog 2001/05/21 19:36:47 PDT > > Modified files: > sys/dev/vinum vinumrequest.c > Log: > vinumstart: If a write request is for a RAID-[45] plex or a volume > with more than one plex, the data will be accessed > multiple times. During this time, userland code could > potentially modify the buffer, thus causing data > corruption. In the case of a multi-plexed volume this > might be cosmetic, but in the case of a RAID-[45] plex it > can cause severe data corruption which only becomes > evident after a drive failure. Avoid this situation by > making a copy of the data buffer before using it. > > Note that this solution does not guarantee any particular > content of the buffer, just that it remains unchanged for > the duration of the request. Yes, taking a snapshot of the buffer by copying is a perfectly acceptable race condition. It actually should guarantee that the buffer content is consistant for the duration of the mirror'ing or parity calculation. -- -Alfred Perlstein [alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message