Re: [bigmem-patch] 4GB with Linux on IA32

Andrea Arcangeli
1999-08-17T00:10:43Z

On Mon, 16 Aug 1999, Kanoj Sarcar wrote:

>a page to remap to). Remapping in just the swap code is acceptable, but
>probably not for other cases (like rawio).

Agreed completly.

>way it is, is so that drivers don't break. I think 2.3 is the place to
>teach the kernel and drivers that all of memory is not directly mappable.

I tried to avoid this (and I am been successfully until I noticed raw-io
in 2.3.13... sigh).

In the meantime I'll take raw-io disabled if CONFIG_BIGMEM is set .

> [..] And kmalloc could also use
>bigmem pages for holding kernel data structures ...

I really don't think this will ever happen.

BTW, the previous patch I posted for disable raw-io on bigmem pages seems
that won't work correctly but it seems a bug in map_user_kiobuf:

[..]
static struct page * get_page_map(unsigned long page)
{
struct page *map;

if (MAP_NR(page) >= max_mapnr)
return 0;
if (page == ZERO_PAGE(page))
return 0;
map = mem_map + MAP_NR(page);
if (PageReserved(map))
return 0;
#ifdef CONFIG_BIGMEM
if (PageBIGMEM(map))
return 0;
#endif
return map;
}
[..]
map = get_page_map(page);
if (map) {
if (TryLockPage(map)) {
goto retry;
}
atomic_inc(&map->count);
}
spin_unlock(&mm->page_table_lock);
dprintk ("Installing page %p %p: %d\n", (void *)page, map, i);
iobuf->pagelist[i] = page;
iobuf->maplist[i] = map;
iobuf->nr_pages = ++i;

ptr += PAGE_SIZE;
[..]

If get_page_map() will return zero, then the page will be queued anyway in
the iobuf. The fact that the map is null won't be checked in brw_kiovec().
So it seems you could write to the ZERO_PAGE if you first mmap() the zero
page and then you give as buffer the userspace area where you have mapped
the zero-page... What am I missing?

Andrea