[rfc][patch] mm: half-fix page tail zeroing on write problem

[rfc][patch] mm: half-fix page tail zeroing on write problem

[Nick Piggin]

Hi,

For no important reason, I've again looked at those zeroing patches that
Neil did a while back. I've always thought that a simple
`write(fd, NULL, size)` would cause the same sorts of problems.

Turns out it does. If you first write all 1s into a page, then do the
`write(fd, NULL, size)` at the same position, you end up with all 0s in
the page (test-case available on request).  Incredible; surely this
violates the spec?

The buffered-write fixes I've got actually fix this properly, but  they
don't look like getting merged any time soon. We could do this simple
patch which just reduces the chance of corruption from a certainty down
to a small race.

Any thoughts?

-- 
Index: linux-2.6/include/linux/pagemap.h
===================================================================
--- linux-2.6.orig/include/linux/pagemap.h	2007-02-02 13:41:21.000000000 +1100
+++ linux-2.6/include/linux/pagemap.h	2007-02-02 13:42:09.000000000 +1100
@@ -198,6 +198,9 @@ static inline int fault_in_pages_writeab
 {
 	int ret;
 
+	if (unlikely(size == 0))
+		return 0;
+
 	/*
 	 * Writing zeroes into userspace here is OK, because we know that if
 	 * the zero gets there, we'll be overwriting it.
@@ -217,19 +220,23 @@ static inline int fault_in_pages_writeab
 	return ret;
 }
 
-static inline void fault_in_pages_readable(const char __user *uaddr, int size)
+static inline int fault_in_pages_readable(const char __user *uaddr, int size)
 {
 	volatile char c;
 	int ret;
 
+	if (unlikely(size == 0))
+		return 0;
+
 	ret = __get_user(c, uaddr);
 	if (ret == 0) {
 		const char __user *end = uaddr + size - 1;
 
 		if (((unsigned long)uaddr & PAGE_MASK) !=
 				((unsigned long)end & PAGE_MASK))
-		 	__get_user(c, end);
+		 	ret = __get_user(c, end);
 	}
+	return ret;
 }
 
 #endif /* _LINUX_PAGEMAP_H */
Index: linux-2.6/mm/filemap.c
===================================================================
--- linux-2.6.orig/mm/filemap.c	2007-02-02 13:42:40.000000000 +1100
+++ linux-2.6/mm/filemap.c	2007-02-02 14:00:19.000000000 +1100
@@ -2112,7 +2112,10 @@ generic_file_buffered_write(struct kiocb
 		 * same page as we're writing to, without it being marked
 		 * up-to-date.
 		 */
-		fault_in_pages_readable(buf, bytes);
+		if (fault_in_pages_readable(buf, bytes)) {
+			status = -EFAULT;
+			break;
+		}
 
 		page = __grab_cache_page(mapping,index,&cached_page,&lru_pvec);
 		if (!page) {

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [rfc][patch] mm: half-fix page tail zeroing on write problem

[Neil Brown]

On Friday February 2, npiggin@suse.de wrote:
> Hi,
> 
> For no important reason, I've again looked at those zeroing patches that
> Neil did a while back. I've always thought that a simple
> `write(fd, NULL, size)` would cause the same sorts of problems.

Yeh, but who in their right mind would do that???
Oh, you did :-)

> 
> Turns out it does. If you first write all 1s into a page, then do the
> `write(fd, NULL, size)` at the same position, you end up with all 0s in
> the page (test-case available on request).  Incredible; surely this
> violates the spec?

Does it?
I guess filling with zeros isn't what one would expect, but you could
make a case for it being right.
  write(fd, 0, size)
writes 'size' 0s.  Cool.   Ok, bad-cool.

> 
> The buffered-write fixes I've got actually fix this properly, but  they
> don't look like getting merged any time soon. We could do this simple
> patch which just reduces the chance of corruption from a certainty down
> to a small race.
> 
> Any thoughts?

I cannot see why you make a change to fault_in_pages_writeable.  Is it
just for symmetry?
For the rest, it certainly makes sense to return an early -EFAULT if
you cannot fault in the page.

NeilBrown

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [rfc][patch] mm: half-fix page tail zeroing on write problem

[Nick Piggin]

On Fri, Feb 02, 2007 at 05:29:06PM +1100, Neil Brown wrote:
> On Friday February 2, npiggin@suse.de wrote:
> > Hi,
> > 
> > For no important reason, I've again looked at those zeroing patches that
> > Neil did a while back. I've always thought that a simple
> > `write(fd, NULL, size)` would cause the same sorts of problems.
> 
> Yeh, but who in their right mind would do that???
> Oh, you did :-)

Well that's the test-case. Obviously not many people do it, but that's
all the more reason to be careful about correct behaviour.

> I cannot see why you make a change to fault_in_pages_writeable.  Is it
> just for symmetry?

Yes.

> For the rest, it certainly makes sense to return an early -EFAULT if
> you cannot fault in the page.

I think so.

Thanks,
Nick

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>