Hi. On 05/06/10 11:16, Maxim Levitsky wrote: > >> If the memory it writes to isn't protected, there'll be no recursive >> page fault and no problem, right? I'm imagining this page fault handler >> will only set a flag to record that the page needs to be atomically >> copied, copy the original contents to a page previously prepared for the >> purpose, remove the write protection for the page and allow the write to >> continue. That should be okay, right? > I think so, although I have no experience yet to comment on such things. > Despite that I think you might run out of 'page previously prepared for > the purpose' > However you can adopt a retrial process, like you do today in tuxonce. > Just abort suspend, and do it again. Yeah. I'm expecting that it will be reasonably predictable - at least ballpark. I guess there's only one way to find out... >>> Of course the sucky part will be how to edit the page tables. >>> You might need to write your own code to do so to be sure. >>> And this has to be arch specific. >> >> Yeah. I wondered whether the code that's already used for creating page >> tables for the atomic restore could be reused, at least in part. > This is very dangerous. > The code might work now, and tomorrow somebody will add a code that does > memory writes. > The point is that you must be sure that there are no recursive faults, > or somehow deal with them (this is probably too dangerous to even think > of) That shouldn't be too hard - after all, we're going to know what memory we're using to record the info. As long as we don't do anything silly like protecting our own data, we should be right. >>> Since userspace is frozen, you can be sure that faults can only be >>> caused by access to WO memory or kernel bugs. >> >> Userspace helpers or uswsusp shouldn't be forgotten. > This is especially bad. because a fault in userspace will mean swapping. > You won't get away with custom page fault for this. > You could assure before suspend that all relevant userspace is not > swapped, or forget about userspace, because its minor thing compared to > speed increases of full memory write. Mmm, but existing userspace helpers for TuxOnIce are carefully designed so everything is in memory before we start work, and so that nothing is done which will compromise the integrity of the image. I assume the same applies to uswsusp. I'm more concerned just to make sure that we don't forget to modify the page tables for these userspace processes (at least the TuxOnIce ones) so that any modifications to kernel memory made while in their process context are also caught. Regards, Nigel _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
