public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@novell.com>
To: Andrew Morton <akpm@osdl.org>, Hugh Dickins <hugh@veritas.com>
Cc: linux-kernel@vger.kernel.org
Subject: mlock hanging on non-ram with VM_IO set
Date: Tue, 16 Nov 2004 18:33:52 +0100	[thread overview]
Message-ID: <20041116173352.GL4758@dualathlon.random> (raw)

I've got a report of mlock deadlocking on non-ram mappings (precisely on
a mmap of /dev/mem outside the mem_map array range)

I believe this should fix it (I verified the mlock is the only one
passing down pages == NULL, and infact mlock is the only one hanging on
VM_IO vmas since the pfn isn't valid and handle_mm_fault sure can't
istantiate a valid pfn there since the ptes are filled synchronously at
mmap time), comments? (I don't see any reason why mlock should be
allowed to trigger page faults on VM_IO regions)

This is not a bad bug, mlock is privilegied, and /dev/mem is privilegied
too, and mlock makes no sense on a non-ram mappings (noop), but I guess
it's ok to add it mostly for things like mlockall that would otherwise
deadlock the box and I guess it's nicer if they work transparently, no
matter what mappings are in the task.

btw, mlock traps the error and ignores it as it should.

this is untested but I guess it should fix it (and it applied cleanly to
kernel CVS).

Signed-off-by: Andrea Arcangeli <andrea@novell.com>

--- sles/mm/memory.c.~1~	2004-11-12 12:30:25.000000000 +0100
+++ sles/mm/memory.c	2004-11-16 17:58:02.752131952 +0100
@@ -753,7 +753,7 @@ int get_user_pages(struct task_struct *t
 			continue;
 		}
 
-		if (!vma || (pages && (vma->vm_flags & VM_IO))
+		if (!vma || (vma->vm_flags & VM_IO)
 				|| !(flags & vma->vm_flags))
 			return i ? : -EFAULT;
 

                 reply	other threads:[~2004-11-16 17:33 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20041116173352.GL4758@dualathlon.random \
    --to=andrea@novell.com \
    --cc=akpm@osdl.org \
    --cc=hugh@veritas.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox