> > > > I have seen that before: Atomic snapshot used fpu copy in some wrong > > > > variants. Symptom was exactly that -- elevated preempt count -- > > > > because fpu copy routine elevated it, then copied the task struct. > > > > > > > > But I thought we solved that problem...? > > > > > > We did. We don't use memcpy for precisely that reason. 3DNOW memcpy was one > > > of the problem children. This would be a different creature though, > > > wouldn't it? > > > > Hmm. Aparently we had a parting of ways on this at some point. Memcpy is being > > used by swsusp, and it has been used since before 2.6.12-rc1. (This is when > > doing the atomic copy, not resuming). And it could well be that's when this bug appeared. It's on an Athlon, so that theory checks out as well as possible short of a patch. > Do you mean the one in copy_data_pages()? Indeed, that may be a problem if > the MMU-based memcpy is used. > > Pavel, should we fix this? Of course it needs fixing ... it's a bug, also a regression. My question is where to fix... swsusp_arch_resume() seems most correct, albeit messy. There's unfortunately no exact parallel on the resume side to where the bug was inserted. Those of us who avoid hacking asm code might prefer restore_processor_state(). - Dave
