Messages in this thread | | | Date | Thu, 5 Mar 2020 10:30:14 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCHv2] printk: queue wake_up_klogd irq_work only if per-CPU areas are ready |
| |
On (20/03/04 16:21), Petr Mladek wrote: [..] > > Fix printk_deferred() and do not queue per-CPU irq_work > > before per-CPU areas are initialized. > > > > [0] https://lore.kernel.org/lkml/aa0732c6-5c4e-8a8b-a1c1-75ebe3dca05b@camlintechnologies.com/ > > > > Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> > > Reported-by: Lech Perczak <l.perczak@camlintechnologies.com> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Cc: Theodore Ts'o <tytso@mit.edu> > > Cc: John Ogness <john.ogness@linutronix.de> > > Reviewed-by: Petr Mladek <pmladek@suse.com>
Thanks!
> Now, the question is whether to hurry this fix into 5.6 or if > it could wait for 5.7. > > I think that it could wait because 5.6 is not affected by > the particular printk_deferred(). This patch fixes a long-term > generic problem. But I am open for other opinions.
Good question. My 5 cents, I would _probably_ push it now. Not because it fixes any known issues on 5.6, but because we have a number of LTS kernel (4.19, 4.14, 4.9, 4.4, 3.16) that can be affected should 1b710b1b10eff9d4 be backported to those kernels. Which is quite likely, I suspect. The sooner we fix printk_deferred(), the sooner -stable/LTS picks up the fix, so that we don't have same regression reports in the future. The regression in question is pretty hard to track down, git-bisect, perhaps, is the only reasonably fast way.
-ss
| |