On Friday 28 October 2005 18:19, Badari Pulavarty wrote:
> Jeff Dike wrote:

> I cut-n-pasted shmem_truncate_range() from shmem_truncate() and fixed
> few obvious things. Its very likely that, I missed whole bunch of changes.

> My touch tests so far, doesn't really verify data after freeing. I was
> thinking about writing cases. If I can use UML to do it, please send it
> to me. I would rather test with real world case :)
I would call that a _bad_ idea, at this stage.

It may be good when the patch is already really polished, IMHO, but not for 
verifying what's really wrong.

Also, you can gdb an UML running with the patch, to verify what's going on.

But I wouldn't suggest testing this with nested UMLs - using that means 
looking for trouble.

As an example, I'm attaching a test-program I wrote during my work on 
remap_file_pages - it also has a mechanism for trying memory accesses and 
catching SIGSEGV, and reporting they were / weren't got.

Not as nice as the kernel one, but it's little enough for our purposes.

There's much stuff you likely won't need, but it can be useful both as an 
example and as a starting point.

In your case, I'd write code as:

* fill many pages (enough to cover all indirections level in shmfs) with 
numbers. The first with 1, the second with 2, and so on (I'm avoiding 0 on 
purpose).

* loop over all them {
	truncate one of them

	loop over all pages to verify only that one is zero'ed (mincore() might help
	too, depending on its implementation).

	optionally, refill it (otherwise we can't check that truncating the next page
	doesn't clear this one).
}
(Possibly, truncate sets of pages, and verify only those ones are truncated).

* verify meanwhile that the tmpfs usage with statfs64() decreases.

Other suggestions?
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade