All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Maninder Singh <maninder1.s@samsung.com>,
	sergey.senozhatsky@gmail.com, rostedt@goodmis.org,
	linux-kernel@vger.kernel.org, a.sahrawat@samsung.com,
	pankaj.m@samsung.com, v.narang@samsung.com
Subject: Re: [PATCH 2/2] printk: make sure to print log on console.
Date: Fri, 1 Jun 2018 18:37:38 +0900	[thread overview]
Message-ID: <20180601093738.GC1841@jagdpanzerIV> (raw)
In-Reply-To: <20180601090942.ek3j4bpbhschljrw@pathway.suse.cz>

On (06/01/18 11:09), Petr Mladek wrote:
> > [...]
> > 
> > > So I'd say that most likely the following scenarios can suffer:
> > > 
> > > - NMI comes in, sets loglevel to X, printk-s some data, restores the
> > >   loglevel back to Y
> > > - IRQ comes in [like sysrq, etc] comes in and does the same thing
> > > - software exception comes in and does the same thing [e.g. bust_spinlocks()
> > >   at arch/s390/mm/fault.c]
> 
> I forgot to say that it was a great point and analyze.

Thanks :)

> > My view is:
> > 
> > The race with another printk() (console_lock owner) is much more
> > likely than a race between two CPUs manipulating console_loglevel.
> > 
> > The proposed patch seems to be in the right direction. It is supposed
> > to fix the most likely scenario. We could block it and request full
> > solution but I wonder if it is worth it.
> > 
> > I am personally fine with this partial solution for now. We could
> > always make it better if people meet the other scenarios.
> 
> I am still fine with the partial solution. Well, I will think
> more about it before approving any patch.

Same here. I don't mind the patch and can agree with this partial
solution [may be we are missing more cases?]. Probably will need
a little bit more time.

	-ss

  reply	other threads:[~2018-06-01  9:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20180531102246epcas5p2f1cbc6ff217172e12e2f78bb88eb4a7e@epcas5p2.samsung.com>
2018-05-31 10:19 ` [PATCH 2/2] printk: make sure to print log on console Maninder Singh
2018-05-31 10:52   ` Sergey Senozhatsky
2018-05-31 12:21     ` Petr Mladek
2018-06-01  4:40       ` Sergey Senozhatsky
2018-06-01  8:42         ` Vaneet Narang
2018-06-01  9:34           ` Sergey Senozhatsky
2018-06-01  8:53         ` Petr Mladek
2018-06-01  9:09           ` Petr Mladek
2018-06-01  9:37             ` Sergey Senozhatsky [this message]
2018-06-01  9:18           ` Sergey Senozhatsky
2018-05-31 13:27   ` Petr Mladek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180601093738.GC1841@jagdpanzerIV \
    --to=sergey.senozhatsky.work@gmail.com \
    --cc=a.sahrawat@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maninder1.s@samsung.com \
    --cc=pankaj.m@samsung.com \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=v.narang@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.