linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peng Dai <dai@mclinux.com>
To: linux-kernel@vger.kernel.org
Cc: Larry Woodman <woodman@missioncriticallinux.com>,
	David Winchell <winchell@mclinux.com>
Subject: Fixing random corruption in raw IO on 2.2.x kernel with bigmem enabled
Date: Wed, 06 Dec 2000 12:28:54 -0500	[thread overview]
Message-ID: <3A2E7756.979988E8@mclinux.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]

Hi,

This patch fixes a subtle corruption when doing raw IO on the 2.2.x
kernel
with bigmem enabled. The problem was first reported by Markus Döhr while

running SAP DB on a variation of the 2.2.16 kernel with among others the

following patches installed,

> linux-2.2.16-rawio.patch
> linux-2.2.16-raw-fixup.patch
> linux-2.2.16-raw-fixup2.patch
> linux-2.2.16-bigmem.patch
> linux-2.2.16-bigmem-raw.patch
> linux-2.2.16-bigmem-dcache.patch
> linux-2.2.16-bigmem-initrd.patch

See http://marc.theaimsgroup.com/?l=linux-kernel&m=97038067229365&w=2
for the original description.

The corruption is caused by a bug in kiobuf_copy_bounce in fs/iobuf.c -
the
bigmem page containing the user data is not always copied to its
associated
bounce buffer. This would occur when an array of pages (>1) are passed
to
kiobuf_copy_bounce and a normal page happens to appear before a bigmem
page in the array, which in turn leads to the writing of uninitialized
(garbage)
pages to the raw device.

The corruption happens rather infrequently. It has been reproduced both
with
the SAP DB and without. It appears that intense paging activity
increases its
chance of occurrence.

Regards,

Peng Dai
Kernel Engineering                                          Tel:
978-446-9166 ext. 276
Mission Critical Linux Inc.                              Fax:
978-446-9470
100 Foot of John                                               Email:
dai@missioncriticallinux.com
Lowell, MA 01852


[-- Attachment #2: iobuf.c.patch --]
[-- Type: text/plain, Size: 485 bytes --]

--- linux/fs/iobuf.c.orig	Tue Nov 28 13:54:26 2000
+++ linux/fs/iobuf.c	Tue Nov 28 13:55:17 2000
@@ -213,10 +213,10 @@
 		unsigned long kin, kout;
 		int pagelen = length;
 		
-		if (bounce_page) {
-			if ((pagelen+offset) > PAGE_SIZE)
-				pagelen = PAGE_SIZE - offset;
-		
+		if ((pagelen+offset) > PAGE_SIZE)
+			pagelen = PAGE_SIZE - offset;
+
+		if (bounce_page) {		
 			if (direction == COPY_TO_BOUNCE) {
 				kin  = kmap(page, KM_READ);
 				kout = kmap(bounce_page, KM_WRITE);

             reply	other threads:[~2000-12-06 17:50 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-06 17:28 Peng Dai [this message]
2000-12-06 18:26 ` Fixing random corruption in raw IO on 2.2.x kernel with bigmem enabled Stephen C. Tweedie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A2E7756.979988E8@mclinux.com \
    --to=dai@mclinux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=winchell@mclinux.com \
    --cc=woodman@missioncriticallinux.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).