29/11/12 16:40, intrigeri wrote: > Hi, > > (Coming back to this branch that apparently managed to get out of our > radar, possibly due to the lack of a ticket.) > > anonym wrote (09 Oct 2012 14:17:45 GMT) : >> - With "normal" non-PAE kernel: >> * Patterns remaining after wipe: 51K ≃ 800 KiB of memory. Also, in >> this case hugetlb_mem_wipe exits at 51% progress with the >> following error: > >> wipe_page: Cannot allocate memory >> spawn_new failed (1) > >> OTOH, since only 51K patterns remains, the progress meter seems >> to be wrong (I suppose it's just a buffer issue) and that it in >> fact dies on around 99% progress. >> * Time required for wipe: ~1 second. > > Ague told me a few weeks ago that this issue had been solved. > Indeed, it looks like it's been fixed by 64a404f2 (Do not assume page > sizes in hugetlb_mem_wipe). I could not reproduce this bug in a VM > fed with 5GB of memory and an emulated Pentium III without PAE, > but the whole process is going to fast for me to see anything useful. > > => anonym, may you please confirm the bugs you experienced are gone? > (I've merged this branch into experimental to help such tests.)
Both tests performed in the same 8 GiB-RAM VM: With PAE-kernel: 137K occurences ≃ 2.1 MiB of unwiped memory. With non-PAE-kernel: 155K occurences ≃ 2.4 MiB of unwiped memory. I didn't experience the "wipe_page: Cannot allocate memory" or "spawn_new failed (1)" errors in either test. >> Given that: > >> * current devel cleans *all* memory in the most common case (PAE >> kernel), and that it does so without taking very much more time, and >> * I'm unsure what the implications are of hugetlb_mem_wipe exiting with >> that error on a non-PAE kernel, > >> I'd rather wait with merging feature/hugetlb_mem_wipe until after Tails >> 0.14. > > Once it is confirmed the bug is gone, I would like to merge this > branch in time for 0.16 (so I'll probably update the design doc > myself, hrm). What do you think? Well, while this branch makes the wipe much faster and better looking, it's not as efficient as Tails' current parallel sdmem approach when using a PAE kernel (which usually results in 0 occurrences in my tests, if not it's just a few hundred occurences), which arguably is what most users will use. For the non-PAE kernel I believe this branch is better, though. Are we sure we want this? Cheers! _______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
