Messages in this thread | | | Date | Fri, 3 Feb 2017 10:57:57 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCHv7 5/8] printk: report lost messages in printk safe/nmi contexts |
| |
On (02/02/17 09:34), Steven Rostedt wrote: > On Thu, 2 Feb 2017 11:02:57 +0900 > Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote: > > > On (02/01/17 11:37), Steven Rostedt wrote: > > > This looks fine, but I'm curious if you tested it. That is, added a > > > bunch of printks to overflow the buffer. IIRC, I did it to the original > > > nmi code. If you haven't you may want to just to make sure it works. I > > > can also test it too if I get some time. > > > > Hello Steven, > > > > yes, I have tested it on my x86 box. > > > > Please note how you tested it in your change log. It's not really a > requirement, and you don't really have to do it. But it helps people > have warm fuzzies about the code. I'm trying to do this in the future > in my own work too.
well. sure, no objections, but in this particular case it's hardly possible to hit all of those problems within a reasonable time. so what I did was just a bunch of dirty hacks to provoke the problems. something like this
extern int XXX;
vprintk_emit() { spin_lock(&logbuf_lock);
// // in various places // if (XXX == 1) { WARN_ON(1); }
spin_unlock(&logbuf_lock); }
and I set/clear that XXX from one of sysfs attrs... yeah, I know... but it does what I want. so I'm not really sure I want to note this in the change log. am I wrong?
-ss
| |