On Fri, Oct 26, 2018 at 12:15:49PM +0200, Pavel Machek wrote:
On Fri 2018-10-26 10:22:14, Greg KH wrote:
On Fri, Oct 26, 2018 at 11:05:43AM +0200, Pavel Machek wrote:
> On Mon 2018-10-22 06:20:13, Sasha Levin wrote:
> > From: Gerald Schaefer <gerald.schaefer@xxxxxxxxxx>
> >
> > [ Upstream commit 55a5542a546238354d1f209f794414168cf8c71d ]
> >
> > The resume code checks if the resume cpu is the same as the suspend cpu.
> > If not, and if it is also not possible to switch to the suspend cpu, an
> > error message should be printed and the resume process should be stopped
> > by loading a disabled wait psw.
> >
> > The current logic is broken in multiple ways, the message is never printed,
> > and the disabled wait psw never loaded because the kernel panics before that:
> > - sam31 and SIGP_SET_ARCHITECTURE to ESA mode is wrong, this will break
> > on the first 64bit instruction in sclp_early_printk().
> > - The init stack should be used, but the stack pointer is not set up correctly
> > (missing aghi %r15,-STACK_FRAME_OVERHEAD).
> > - __sclp_early_printk() checks the sclp_init_state. If it is not
> > sclp_init_state_uninitialized, it simply returns w/o printing anything.
> > In the resumed kernel however, sclp_init_state will never be uninitialized.
>
> Stable patches should fix one bug, and one bug only.
So should upstream patches, but the rule of "stable patches match
upstream identically" overrules this :)
a) There is no such rule for upstream.
I invite you to read the docs in Documentation/process/ where you'll
find gems like "Each logically independent change should be formatted as
a separate patch".
b) You should split the patch if it is important enough.
c) The "stable patches match upstream identically" rule does not
exist. Check the documentation.
The rule in question here is that every patch that goes into -stable
must be upstream. If we were to split this patch, it would create 2+
patches that do not exist upstream, thus breaking our own rules.
Anyway, given that this is an upstream issue, I'll also invite you to
have this discussion with the maintainer of the subsystem this patch
went into; you raise a valid concern which can hopefully be addressed by
that maintainer.
--
Thanks,
Sasha
