]> err.no Git - linux-2.6/commitdiff
[PATCH] i386: fix file_read_actor() and pipe_read() for original i386 systems
authorThomas Gleixner <tglx@linutronix.de>
Mon, 2 Apr 2007 12:25:31 +0000 (14:25 +0200)
committerLinus Torvalds <torvalds@woody.linux-foundation.org>
Mon, 2 Apr 2007 17:07:25 +0000 (10:07 -0700)
The __copy_to_user_inatomic() calls in file_read_actor() and pipe_read()
are broken on original i386 machines, where WP-works-ok == false, as
__copy_to_user_inatomic() on such systems calls functions which might
sleep and/or contain cond_resched() calls inside of a kmap_atomic()
region.

The original check for WP-works-ok was in access_ok(), but got moved
during the 2.5 series to fix a race vs. swap.

Return the number of bytes to copy in the case where we are in an atomic
region, so the non atomic code pathes in file_read_actor() and
pipe_read() are taken.

This could be optimized to avoid the kmap_atomicby moving the check for
WP-works-ok into fault_in_pages_writeable(), but this is more intrusive
and can be done later.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
arch/i386/lib/usercopy.c

index d22cfc9d656ca39317d68a1a2a0f6ec6b13bf2df..086b3726862aaee1117a909666c2a748aa58162a 100644 (file)
@@ -10,6 +10,7 @@
 #include <linux/blkdev.h>
 #include <linux/module.h>
 #include <linux/backing-dev.h>
+#include <linux/interrupt.h>
 #include <asm/uaccess.h>
 #include <asm/mmx.h>
 
@@ -719,6 +720,14 @@ unsigned long __copy_to_user_ll(void __user *to, const void *from,
 #ifndef CONFIG_X86_WP_WORKS_OK
        if (unlikely(boot_cpu_data.wp_works_ok == 0) &&
                        ((unsigned long )to) < TASK_SIZE) {
+               /*
+                * When we are in an atomic section (see
+                * mm/filemap.c:file_read_actor), return the full
+                * length to take the slow path.
+                */
+               if (in_atomic())
+                       return n;
+
                /* 
                 * CPU does not honor the WP bit when writing
                 * from supervisory mode, and due to preemption or SMP,