All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: "H. Peter Anvin" <hpa@transmeta.com>
Cc: alan@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: NFSv3 and linux-2.4.10-ac3 => oops
Date: 02 Oct 2001 11:40:34 +0200	[thread overview]
Message-ID: <shszo7a4bxp.fsf@charged.uio.no> (raw)
In-Reply-To: <200110012340.QAA02719@sw170.transmeta.com>
In-Reply-To: "H. Peter Anvin"'s message of "Mon, 1 Oct 2001 16:40:05 -0700"

>>>>> " " == H Peter Anvin <hpa@transmeta.com> writes:

     > Hello everyone, I have a reproducible (and rather quick) oops
     > on a system running linux-2.4.10-ac3, which seems to be NFS
     > (v3) related; although ksymoops core dumps when I try to use
     > it, I have manually decoded the dump to indicate that it
     > happens in rwsem_down_read_failed called from nfs_file_wite.
     > Rather than posting too much here, I have put as much
     > information as I have been able to gather at:

     > ftp://ftp.zytor.com/pub/hpa/oops/

I'm trying to look at this, but it seems a hopeless mess: there are no
calls to any read/write semaphore routines in the NFS code.

AFAICS the second stack return point corresponds to the call to
generic_file_write() in nfs_file_write(), so I'd guess that the Oops
is actually happening somewhere there...

Hmm... Looking at the code in generic_file_write(), I see that Alan
hasn't merged in the kmap() stuff in generic_file_write()from
Linus. At the same time, the nfs_prepare_write() seems to have been
synced with Linus, and so the kmap() that used to be there has
disappeared.

As  your  config  indicates  that  you  *are*  using CONFIG_HIGHMEM4G,
perhaps one ought to start with a patch that fixes the obvious bug (in
the hope that it'll at least clean up the next Oops)...

Cheers,
  Trond

--- linux-2.4.10-hpa/fs/nfs/file.c.orig	Sun Sep 23 18:48:01 2001
+++ linux-2.4.10-hpa/fs/nfs/file.c	Tue Oct  2 11:33:43 2001
@@ -155,7 +155,12 @@
  */
 static int nfs_prepare_write(struct file *file, struct page *page, unsigned offset, unsigned to)
 {
-	return nfs_flush_incompatible(file, page);
+	int status;
+	kmap(page);
+	status = nfs_flush_incompatible(file, page);
+	if (status)
+		kunmap(page);
+	return status;
 }
 
 static int nfs_commit_write(struct file *file, struct page *page, unsigned offset, unsigned to)

  reply	other threads:[~2001-10-02  9:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-01 23:40 NFSv3 and linux-2.4.10-ac3 => oops H. Peter Anvin
2001-10-02  9:40 ` Trond Myklebust [this message]
2001-10-02 11:32   ` Matt Bernstein
2001-10-02 12:03     ` Trond Myklebust
2001-10-02 13:49       ` Alan Cox
2001-10-02 14:03         ` Trond Myklebust
2001-10-02 13:47     ` Alan Cox
2001-10-02 14:02       ` Matt Bernstein

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=shszo7a4bxp.fsf@charged.uio.no \
    --to=trond.myklebust@fys.uio.no \
    --cc=alan@kernel.org \
    --cc=hpa@transmeta.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.