Re: memcpy() in swsusp (was: Re: [PATCH 2/2] Fix console handling during suspend/resume)

Rafael J. Wysocki
2006-07-06T14:26:53Z

On Thursday 06 July 2006 16:19, David Brownell wrote:
>
> > > > > 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().

Well, I meant replacing the memcpy() in copy_data_pages with an open coded
copying loop. That should be enough to fix the problem.

Rafael