Re: Fw: Linux v2.5.54

[Andrew Morton <akpm@digeo.com>]

dada1 wrote:
> 
> >   o remove hugetlb syscalls
> 
> So finally they did it ...
> 
> But mmap(NULL, ...) is not yet supported, this is really sad.

Bill, this appears to be a matter of implementing a suitable ->get_unmapped_area()
within hugetlbfs?

> And arch/i386/Kconfig and Documentation/vm/hugetlbpage.txt still document
> the sys_alloc_hugepages()/sys_free_hugepages() syscalls.

OK.
 
> A simple program that doesnt know at all how the memory is layed out by
> kernel/glibc can not easily get some 4Mo pages in a single syscall.
> sys_alloc_hugepage() was very convenient for that.

Well.  One would expect userspace library functions to emerge.  The
glibc people take patches.

 
> Another problem :
> 
> if you mount hugetlbfs in /huge, then create a file /huge/BIG of size 4Mo,
> then use :
> 
> dd if=/huge/BIG of=/dev/null
> 
> the dd process hangs on 'D' state : the read() syscall just hang forever.
> 

erk.  Thanks.

--- 25/fs/hugetlbfs/inode.c~hugetlbfs_readpage-fix	Fri Jan  3 01:04:42 2003
+++ 25-akpm/fs/hugetlbfs/inode.c	Fri Jan  3 01:04:49 2003
@@ -79,6 +79,7 @@ static int hugetlbfs_file_mmap(struct fi
  */
 static int hugetlbfs_readpage(struct file *file, struct page * page)
 {
+	unlock_page(page);
 	return -EINVAL;
 }