On (10/25/18 08:28), Heiko Carstens wrote:
[..]
> >             int loglevel_save = console_loglevel;
> > -           console_unblank();
> > -           oops_in_progress = 0;
> > -           /*
> > -            * OK, the message is on the console.  Now we call printk()
> > -            * without oops_in_progress set so that printk will give klogd
> > -            * a poke.  Hold onto your hats...
> > -            */
> > +
> >             console_loglevel = 15;
> > -           printk(" ");
> > +           console_unblank();
> >             console_loglevel = loglevel_save;
> > +           oops_in_progress = 0;
> > +           wake_up_klogd();
> >     }
> 
> With your patch this looks nearly like the common code variant. I did
> some code archaeology and this function is unchanged since ~17 years.
> When it was introduced it was close to identical to the x86 variant.
> All other architectures use the common code variant in the
> meantime. So if we change this I'd prefer that we switch s390 to the
> common code variant as well.

Right. I couldn't clearly understand what was so special that s390
bust_spinlock() was doing, but assumed that this `console_loglevel'
manipulation probably was somehow important to s390. Though this
console_loglevel adjustment is not 100% guaranteed to make any difference,
because of the way console_unblank() works: if it can't lock console_sem
and it sees oops_in_progress then it does nothing; it doesn't even print
logbuf messages to the consoles. If, however, console_sem is not locked,
then it does print pending logbuf messages, with temporarily verbose
console_loglevel. I concluded that this might be important to you in
one way or another.

> Right now I can't see a reason for not doing that, but I might be
> wrong of course. So, could you please provide a new version which just
> removes this variant and makes s390 use the generic one too.
> 
> We'll see if there is any fallout...

Will do! Sounds good.

        -ss

Reply via email to