Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1329293 > unrolled thread

Re: [PATCH v4 0/4] Cleaning printk stuff in NMI context

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4 0/4] Cleaning printk stuff in NMI context Petr Mladek <pmladek@suse.com> - 2016-02-08 17:40 +0100

#1329293 — Re: [PATCH v4 0/4] Cleaning printk stuff in NMI context

On Thu 2016-01-21 12:30:07, Petr Mladek wrote:
> On Wed 2016-01-20 13:17:13, Andrew Morton wrote:
> > On Fri, 11 Dec 2015 14:20:48 +0100 Petr Mladek <pmladek@suse.com> wrote:
> > 
> > > this is just a quick respin of the previous version. It changes
> > > the few details as you suggested. Also it fixes the build problem
> > > on ARM as reported by Geert and Arnd.
> > > 
> > > I rather send the whole patch set because there is the renamed header.
> > > Also the extra blank space affects two patches. I hope that it will
> > > safe you some work. Please, let me know if you would prefer
> > > incremental patches.
> > > 
> > > 
> > > Changes against v3:
> > > 
> > >   + used size_t for "len" and "size"
> > > 
> > >   + replaced WARN() with pr_err()
> > > 
> > >   + renamed kernel/printk/printk.h -> internal.h
> > > 
> > >   + fixed build on ARM (undefined NMI_LOG_BUF_SHIFT)
> > 
> > So the review of the v3 patchset was ...  inconclusive.  And everyone has
> > gone quiet about v4.
> >
> > Probably because you didn't cc the V3 discussion participants when
> > sending out V4.  Big mistake, sorry, I can't check everything!
> 
> Ah, v4 was sent too fast after v3 before others reacted. It included
> rather cosmetic changes based on your (Andrew's) feedback.
> 
> 
> > But v4 is basically unaltered from v3 so can we please rev this up
> > again?  yay or nay?  Thanks.
> 
> The patch set prevents deadlocks that happen in a real life. It
> increases a chance to get a valid crash dump when NMI is involved.
> 
> It does not handle well the situation when NMI is involved and
> the crash dump could not get produced. But this is not handled
> well even now. As Peter Zijlstra writes this a usually a real
> mess when he needs to use special hacks (early_printk) anyway.
> 
> I still believe that the patch set makes sense and is acceptable
> as is.

Is anyone against getting this into the mainline for 4.6, please?

Best Regards,
Petr

[toc] | [standalone]

Back to top | Article view | linux.kernel

csiph-web