linux-kernel - Re: 2.6.22-rc3-mm1 - page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070601220117.GW20632@ca-server1.us.oracle.com>
Date:	Fri, 1 Jun 2007 15:01:18 -0700
From:	Mark Fasheh <mark.fasheh@...cle.com>
To:	Nick Piggin <npiggin@...e.de>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.22-rc3-mm1 - page_mkwrite() breakage

On Thu, May 31, 2007 at 10:20:39PM -0700, Mark Fasheh wrote:
> Ok. So how about the attached patch? It's a bit different than discussed,
> but I think it's much cleaner because it preserves the current behavior of
> the callback and keeps that bit of page locking inside core code. Not tested
> as of yet, but I can run it tommorrow.

Ok - this patch seems to check out fine in testing - no more deadlocking.

Andrew, if this is ok with you I'd really like to see that fix in -mm. Ocfs2
shared write mmap will instantly deadlock without it.

>From reading Nick's description of the problem in
mm-fix-fault-vs-invalidate-race-for-linear-mappings.patch I think we're
pretty safe (as I noted before) because Ocfs2 re-checks the mapping under
lock to protect against trucate races. That's been an "unwritten"
requirement of page_mkwrite() anyway.

Speaking of requirements, attached is my sad attempt at documenting the API.
I know it might be merged into ->fault at some point, but we really ought to
have _something_ in the meantime.
	--Mark

--
Mark Fasheh
Senior Software Developer, Oracle
mark.fasheh@...cle.com


From: Mark Fasheh <mark.fasheh@...cle.com>

[PATCH] Document ->page_mkwrite() locking

There seems to be very little documentation about this callback in general.
The locking in particular is a bit tricky, so it's worth having this in
writing.

Signed-off-by: Mark Fasheh <mark.fasheh@...cle.com>

---

 Documentation/filesystems/Locking |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)

2320eadfa34199c779638edbdbb6c491df09c49b
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index 970c8ec..91ec4b4 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -512,13 +512,22 @@ prototypes:
 	void (*close)(struct vm_area_struct*);
 	struct page *(*fault)(struct vm_area_struct*, struct fault_data *);
 	struct page *(*nopage)(struct vm_area_struct*, unsigned long, int *);
+	int (*page_mkwrite)(struct vm_area_struct *, struct page *);
 
 locking rules:
-		BKL	mmap_sem
+		BKL	mmap_sem	PageLocked(page)
 open:		no	yes
 close:		no	yes
 fault:		no	yes
 nopage:		no	yes
+page_mkwrite:	no	yes		no
+
+	->page_mkwrite() is called when a previously read-only page is
+about to become writeable. The file system is responsible for
+protecting against truncate races. Once appropriate action has been
+taking to lock out truncate, the page range should be verified to be
+within i_size. The page mapping should also be checked that it is not
+NULL.
 
 ================================================================================
 			Dubious stuff
-- 
1.3.3

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/