question on symbol exports

It appears that in 2.6.9 the ppc64 version of flush_tlb_page() depends 
on two symbols which are not currently exported: the function 
__flush_tlb_pending(), and the per-cpu variable ppc64_tlb_batch.

Is there any particular reason why modules should not be allowed to 
flush the tlb, or is this an oversight?

Chris

On Mon, 2005-01-31 at 18:15 -0600, Chris Friesen wrote:

It appears that in 2.6.9 the ppc64 version of flush_tlb_page() depends 
on two symbols which are not currently exported: the function 
__flush_tlb_pending(), and the per-cpu variable ppc64_tlb_batch.

Is there any particular reason why modules should not be allowed to 
flush the tlb, or is this an oversight?

can you point at the url to your module source? I suspect modules doing
tlb flushes is the wrong thing, but without seeing the source it's hard
to tell.

Arjan van de Ven wrote:

On Mon, 2005-01-31 at 18:15 -0600, Chris Friesen wrote:

quoted

Is there any particular reason why modules should not be allowed to 
flush the tlb, or is this an oversight?

can you point at the url to your module source? I suspect modules doing
tlb flushes is the wrong thing, but without seeing the source it's hard
to tell.

I've included the relevent code at the bottom.  The module will be 
released under the GPL.

I've got a module that I'm porting forward from 2.4.  The basic idea is 
that we want to be able to track pages dirtied by an application.  The 
system has no swap, so we use the dirty bit to get this information.  On 
demand we walk the page tables belonging to the process, store the 
addresses of any dirty ones, flush the tlb, and mark them clean.

I (obviously) don't have a good understanding of how the tlb interacts 
with the software page tables.  If we don't need to flush the tlb I'd 
love to hear it.  If there's an easier way than walking the tables 
manually please let me know.

If it matters, some of the dirty pages may be code (it's used by an 
emulator for a system that can handle on-the-fly binary patching).

Thanks,

Chris







Note: this code is run while holding &mm->mmap_sem and &mm->page_table_lock.

	/* scan through the entire address space given */
	dirty_count = 0;
	for(addr=start&PAGE_MASK; addr<=end; addr+=PAGE_SIZE) {
		pgd_t *pgd;
		pmd_t *pmd;
		pte_t *ptep, pte;
		
		/* Page table walking code stolen from follow_page() except
		 * that this version does not support huge tlbs.
		 */
		pgd = pgd_offset(mm, addr);
		if (pgd_none(*pgd) || unlikely(pgd_bad(*pgd)))
			continue;

		pmd = pmd_offset(pgd, addr);
		if (pmd_none(*pmd))
			continue;
		if (unlikely(pmd_bad(*pmd)))
			continue;

		ptep = pte_offset_map(pmd, addr);
		if (!ptep)
			continue;

		pte = *ptep;
		pte_unmap(ptep);
		if (!pte_present(pte))
			continue;

		if (!pte_dirty(pte))
			continue;

		if (!pte_read(pte))
			continue;

		/* We have a user readable dirty page.  Count it.*/
		dirty_count++;

		if (dirty_count > entries) {
			continue;
		} else {
			__put_user(addr, buf);
			buf++;
		}

		flush_tlb_page(find_vma(mm,addr), addr);
		pte = pte_mkclean(pte);
	}

On Tue, 2005-02-01 at 09:37 -0600, Chris Friesen wrote:

Arjan van de Ven wrote:

quoted

On Mon, 2005-01-31 at 18:15 -0600, Chris Friesen wrote:

quoted

quoted

Is there any particular reason why modules should not be allowed to 
flush the tlb, or is this an oversight?

can you point at the url to your module source? I suspect modules doing
tlb flushes is the wrong thing, but without seeing the source it's hard
to tell.

I've included the relevent code at the bottom.  The module will be 
released under the GPL.

I've got a module that I'm porting forward from 2.4.  The basic idea is 
that we want to be able to track pages dirtied by an application.  The 
system has no swap, so we use the dirty bit to get this information.  On 
demand we walk the page tables belonging to the process, store the 
addresses of any dirty ones, flush the tlb, and mark them clean.

afaik one doesn't need to do a tlb flush in code that clears the dirty
bit, as long as you use the proper vm functions to do so. 
(if those need a tlb flush, those are supposed to do that for you
afaik).

Also note that your code isn't dealing with 4 level pagetables.... And
pagetable walking in drivers is basically almost always a mistake and a
sign that something is wrong.

Arjan van de Ven wrote:

On Tue, 2005-02-01 at 09:37 -0600, Chris Friesen wrote:

quoted

I've got a module that I'm porting forward from 2.4.  The basic idea is 
that we want to be able to track pages dirtied by an application.  The 
system has no swap, so we use the dirty bit to get this information.  On 
demand we walk the page tables belonging to the process, store the 
addresses of any dirty ones, flush the tlb, and mark them clean.

afaik one doesn't need to do a tlb flush in code that clears the dirty
bit, as long as you use the proper vm functions to do so. 
(if those need a tlb flush, those are supposed to do that for you
afaik).

I've been in contact with one of the developers of the code.  The reason 
we flush the tlb is so that on the next write the cpu has to fault it in 
and set the dirty bit.  Does that make sense?  I should try 
experimenting.....

Also note that your code isn't dealing with 4 level pagetables.... 

2.6.9 doesn't have 4 level pagetables.  We'll have to port it forward 
when we eventually upgrade.

 > And

pagetable walking in drivers is basically almost always a mistake and a
sign that something is wrong.

I'd rather not be doing it, but there's no nice generic va_to_pte() 
function.  There have been patches, and ppc has one, but as a whole I 
don't know of any nice way to do this.

Chris