Re: [PATCH] cpufreq: fix garbage kobj on errors during suspend/resume

["Bjørn Mork" <bjorn@mork.no>]

"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com> writes:

> You seem to be getting confused as to what the *actual* userspace
> expectation was, in that mail thread. The expectation was that suspend/
> resume is a kernel operation that brings back the system to the same
> state (as much as possible) at the end of resume, as it was before
> suspend. And that is a perfectly valid expectation, and it is something
> that the kernel has to try its level best to honor.

Our understanding of the thread is obviously biased by our respective
views of the matter ;-)

> And in this particular case, the specific expectation was that the sysfs
> file permissions set by the user for cpufreq files will remain as it is
> even after a suspend/resume cycle. That's it. There is _absolutely_ _no_
> talk about CPU hotplug here.

This is not a cpufreq problem.  It is a CPU problem.  You are only
complicating things by trying to solve it in cpufreq.  What about
permissions on the other CPU sysfs attributes?

> Robert _happened_ to dig this further and observe that suspend/resume
> actually does offline/online of CPUs, and thought that he should have
> also seen the associated udev events as well. But we have purposefully
> not exposed the fact that suspend/resume involves CPU hotplug.

Well, that is a bug in my opinion.  You are adding lots of kernel code
to avoid a very simple userspace configuration.  Seems very backwards.
This is mostly a documentation problem, if a problem at all.  I do note
that Robert did try the udev way before concluding that this was a
kernel bug.

> Today,
> suspend/resume uses CPU hotplug internally because we don't have any
> other better alternative. The very concept/semantic of suspend/resume
> _does_ _not_ imply CPU hotplug - it is just an implementation detail
> that userspace should not need to care about or rely on.
>
> Moreover, cpufreq is not the only subsystem that participates in suspend/
> resume and CPU hotplug. And fundamentally, regular CPU hotplug has _very_
> different semantics and guarantees than the hotplug done in suspend/resume.
> For example, if you offline CPUs normally, the cpusets associated with
> those CPUs will get destroyed, potentially in ways that _won't_ bring
> them back to the same state when you online those exact same CPUs!
> And this would have been totally unacceptable to a user innocuously
> using suspend/resume. Look at commit d35be8bab9 (CPU hotplug, cpusets,
> suspend: Don't modify cpusets during suspend/resume), for more details
> on how we fixed that problem.

Yes, I do see that point.  The special suspend/resume handling is
definitely necessary in this case.

> So, to summarize, suspend/resume should mean one simple thing to
> userspace - "the kernel will transparently (to the extent possible)
> perform suspend/resume and bring back the system during resume, to a
> state as close as possible compared to how it was before suspend".
> Any implementation challenges must be handled in the kernel (as far as
> possible), and we should avoid burdening userspace with extraneous
> events etc.

OK, I think we may have different views on how much kernel
implementation details userspace need to know :-)

That's fine, and it really was not my intention to question the way
cpufreq handled this.  It all just seemed so meaningless to me.  I now
understand that it has a meaning to you, which of course is what
matters.

I am glad I could help removing the most obvious bugs.


Bj√∏rn