All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Marcelo Tosatti <marcelo@conectiva.com.br>
Cc: Manfred Spraul <manfred@colorfullife.com>,
	Andrea Arcangeli <andrea@suse.de>,
	lkml <linux-kernel@vger.kernel.org>
Subject: [patch] VM_IO fixes
Date: Wed, 06 Feb 2002 22:14:28 -0800	[thread overview]
Message-ID: <3C621B44.10C424B9@zip.com.au> (raw)

We've had a few bugs recently where device drivers were forgetting
to set vma->vm_flags:VM_IO in their mmap() methods.

This causes kernel deadlocks when applications which have the
relevant device mapped try to dump core (the pagefault handler
deadlocks on mmap_sem).

Failing to set VM_IO also causes kernel oopses when PTRACE_PEEKUSR
tries to read the device mapping - the region has no page structs,
but access_process_vm() acts as if it does.

This patch doesn't fix the PTRACE_PEEKUSR bug - for that we need
this patch as well as the patch Andrea, Manfred and I pieced
together - it's at http://www.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.18pre7aa2/00_get_user_pages-2
I understand that Manfred will be sending you a version of that patch.

The drivers which are forgetting to set VM_IO include a whole bunch
of fbmem drivers, one or more AGP drivers and I don't know what else.

It's simpler to make VM_IO default to `on', and to only clear it
in places where we know that it's safe to dump the memory to a
core file, and where it's safe to PTRACE_PEEKUSR it.  That's
what this patch does.  We only clear VM_IO in generic_file_mmap()
and in ncp_mmap() and in coda_file_mmap().

Any filesystem which implements its own mmap() method, and which
does not call generic_file_mmap() needs to be changed to clear
VM_IO inside its mmap function.  All in-kernel filesystems are
OK, as is XFS.  And the only breakage this can cause to out-of-kernel
filesystems is failure to include mappings in core files, and
inability to use PEEKUSR.

With this patch in place we can go through and remove the setting of
VM_IO in all the drivers which _do_ remember to set it.  But that's
a cleanup which can await 2.4.19-pre.


--- linux-2.4.18-pre8/mm/mmap.c	Mon Nov  5 21:01:12 2001
+++ linux-akpm/mm/mmap.c	Sat Feb  2 17:36:55 2002
@@ -534,6 +534,11 @@ munmap_back:
 		}
 		vma->vm_file = file;
 		get_file(file);
+		/*
+		 * Subdrivers can clear VM_IO if their mappings are
+		 * valid pages inside mem_map[]
+		 */
+		vma->vm_flags |= VM_IO;
 		error = file->f_op->mmap(file, vma);
 		if (error)
 			goto unmap_and_free_vma;
--- linux-2.4.18-pre8/mm/filemap.c	Tue Feb  5 00:33:05 2002
+++ linux-akpm/mm/filemap.c	Sat Feb  2 17:36:55 2002
@@ -2111,6 +2111,7 @@ int generic_file_mmap(struct file * file
 		return -ENOEXEC;
 	UPDATE_ATIME(inode);
 	vma->vm_ops = &generic_file_vm_ops;
+	vma->vm_flags &= ~VM_IO;
 	return 0;
 }
 
--- linux-2.4.18-pre8/fs/coda/file.c	Tue Feb  5 00:33:05 2002
+++ linux-akpm/fs/coda/file.c	Wed Feb  6 21:50:16 2002
@@ -97,6 +97,7 @@ coda_file_mmap(struct file *file, struct
 	if (!cfile->f_op || !cfile->f_op->mmap)
 		return -ENODEV;
 
+	vma->vm_flags &= ~VM_IO;
 	down(&inode->i_sem);
 	ret = cfile->f_op->mmap(cfile, vma);
 	UPDATE_ATIME(inode);
--- linux-2.4.18-pre8/fs/ncpfs/mmap.c	Mon Sep 10 09:04:53 2001
+++ linux-akpm/fs/ncpfs/mmap.c	Wed Feb  6 21:49:28 2002
@@ -119,5 +119,6 @@ int ncp_mmap(struct file *file, struct v
 	}
 
 	vma->vm_ops = &ncp_file_mmap;
+	vma->vm_flags &= ~VM_IO;
 	return 0;
 }

             reply	other threads:[~2002-02-07  6:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-07  6:14 Andrew Morton [this message]
2002-02-07  6:50 ` [patch] VM_IO fixes David S. Miller
2002-02-07 12:06 ` Roman Zippel
2002-02-07 16:34   ` Marcelo Tosatti
2002-02-07 20:51   ` Andrew Morton
2002-02-08  5:05     ` Andrew Morton
2002-02-08  5:16       ` David S. Miller
2002-02-08  5:23         ` David Mosberger
2002-02-07 21:34 ` Manfred Spraul
2002-02-07 22:19   ` Andrea Arcangeli

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=3C621B44.10C424B9@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=marcelo@conectiva.com.br \
    /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.