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.)
> 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?
Cheers!
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
