Messages in this thread Patch in this message | | | Date | Tue, 16 Mar 1999 17:07:39 -0500 | From | Philip Gladstone <> | Subject | [PATCH] bug fix to fs/super.c for 2.0.3x and probably 2.2.x |
| |
I finally tracked this one down (after several weeks). The history is that a custom version of the redhat install wouldn't mount NFS disks, but it would always work when debugging code was included.
After some looking at the kernel, it turned out that when the mount of the install filesystem is done, the nfs_mount_options control block is aligned near the end of a page.
The code in the kernel to copy the mount options into kernel space guesses the length of the mount options as
MIN(PAGE_SIZE-1, distance to end of VMA)
I have no idea why the VMA boundary falls in the middle of my mount options (static data), but it does.
Fixing the copy_mount_options to take this case into account makes install work again.
Patch attached for 2.0.36, but I would expect it to apply to 2.0.37 and higher.
The code is the same in 2.0.36 and in recent 2.1 (so I guess it is unchanged in 2.2).
Philip -- Philip Gladstone +1 781 530 2461 Axent Technologies, Waltham, MA--- linux-old/fs/super.c Sun Nov 15 13:33:15 1998 +++ linux/fs/super.c Tue Mar 16 16:53:00 1999 @@ -807,9 +807,20 @@ i = vma->vm_end - (unsigned long) data; if (PAGE_SIZE <= (unsigned long) i) i = PAGE_SIZE-1; + else { + /* Rather short, maybe the next vma butts up against this one ... */ + vma = find_vma(current->mm, i + (unsigned long) data); + if (vma && i + (unsigned long) data >= vma->vm_start && + (vma->vm_flags & VM_READ)) { + /* It does butt up, and we can read the next memory ... */ + i = vma->vm_end - (unsigned long) data; + if (PAGE_SIZE <= (unsigned long) i) + i = PAGE_SIZE-1; + } + } if (!(page = __get_free_page(GFP_KERNEL))) { return -ENOMEM; } memcpy_fromfs((void *) page,data,i); *where = page; return 0;[unhandled content-type:application/x-pkcs7-signature] | |