Re: 2.6.9-rc2-mm1

[Valdis . Kletnieks]

On Thu, 16 Sep 2004 19:30:22 +0200, Arjan van de Ven said:

> I would consider it REALLY weird for a module to use detailed vmalloc
> knowledge like this. Does anyone know what they are doing?????

Here's the problematic code:

        // start off by tracking down which page within this allocation
        // we're looking at. do this by searching for the physical address
        // in our page table.
        for (i = 0; i < at->num_pages; i++)
        {
            if ((address == (unsigned long) at->page_table[i].phys_addr))
            {
                unsigned long retaddr = (unsigned long) at->page_table[i].phys_addr;

                // if we've allocated via vmalloc on a highmem system, the
                // physical address may not be accessible via PAGE_OFFSET,
                // that's ok, we have a simple linear pointer already.
                if (at->flags & NV_ALLOC_TYPE_VMALLOC)
                {
                    return (void *)((unsigned char *) at->key_mapping + (i << PAGE_SHIFT) + offset);
                }

                if (retaddr <= MAXMEM)
                {
                    return __va((retaddr + offset));
                }

                // ?? this may be a contiguous allocation, fall through
                // to below? or should I just check at->flag here?
            }
        }


It gets hung up because MAXMEM is:

#define MAXMEM                        (-__PAGE_OFFSET-__VMALLOC_RESERVE)

and in arch/i386/mm/init.c we have:

unsigned int __VMALLOC_RESERVE = 128 << 20;

but alas without an EXPORT_SYMBOL() so it's not visible to modules. The old
definition was:

#define __VMALLOC_RESERVE (128 << 20)

Change was introduced with the 'tune-vmalloc-size' patch in -rc2-mm1 that added
the boot-time 'vmalloc=' parameter.

I admit not knowing the memory manager or the NVidia well enough to know what
they *should* be doing instead.....

Attachment: pgp00000.pgp
Description: PGP signature