Date: Mon, 21 May 2001 22:47:38 -0400 From: Alfred Perlstein <bright@rush.net> To: Greg Lehey <grog@FreeBSD.org> 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> In-Reply-To: <200105220236.f4M2alK16427@freefall.freebsd.org>; from grog@FreeBSD.org on Mon, May 21, 2001 at 07:36:47PM -0700 References: <200105220236.f4M2alK16427@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Greg Lehey <grog@FreeBSD.org> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010521224738.L17514>