linux.git/fs/compat.c, branch v2.6.12 Linux kernel source tree [PATCH] NFS4: Don't use __user with compat_uptr_t 2005-04-27T22:39:03+00:00 David Howells dhowells@redhat.com 2005-04-27T22:39:03+00:00 5fc3e624ad7278604628c598e92aa77c67064166 The attached patch removes __user from compat_uptr_t types in the NFS4 mount 32-bit->64-bit compatibility structures. Signed-Off-By: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
The attached patch removes __user from compat_uptr_t types in the NFS4 mount
32-bit->64-bit compatibility structures.

Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] Add 32-bit compatibility for NFSv4 mount 2005-04-18T17:54:51+00:00 David Howells dhowells@redhat.com 2005-04-18T17:54:51+00:00 9a9947bf7a3a14d2107cb9a27279fc8f463370a9 This adds 32-bit compatibility for mounting an NFSv4 mount on a 64-bit kernel (such as happens with PPC64). The problem is that the mount data for the NFS4 mount process includes auxilliary data pointers, probably because the NFS4 mount data may conceivably exceed PAGE_SIZE in size - thus breaking against the hard limit imposed by sys_mount(). Signed-Off-By: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
This adds 32-bit compatibility for mounting an NFSv4 mount on a 64-bit
kernel (such as happens with PPC64). 

The problem is that the mount data for the NFS4 mount process includes
auxilliary data pointers, probably because the NFS4 mount data may
conceivably exceed PAGE_SIZE in size - thus breaking against the hard
limit imposed by sys_mount(). 

Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Linux-2.6.12-rc2 2005-04-16T22:20:36+00:00 Linus Torvalds torvalds@ppc970.osdl.org 2005-04-16T22:20:36+00:00 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip! 
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!