Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 8 May 2019 17:24:31 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To:     Daniel Vetter <daniel.vetter@ffwll.ch>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
        Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
        Daniel Vetter <daniel.vetter@intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Will Deacon <will.deacon@arm.com>,
        Petr Mladek <pmladek@suse.com>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        John Ogness <john.ogness@linutronix.de>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Nicolai Stange <nstange@suse.de>,
        Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] RFC: x86/smp: use printk_deferred in
 native_smp_send_reschedule
Message-ID: <20190508082431.GA21654@jagdpanzerIV>
References: <20190507173329.17031-1-daniel.vetter@ffwll.ch>
 <20190508074420.GB15704@jagdpanzerIV>
 <20190508075302.GC15704@jagdpanzerIV>
 <CAKMK7uFeRmSGkqFj-xmdebwKok9+z1pyDZWUMNXfzTT4H2=-fA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKMK7uFeRmSGkqFj-xmdebwKok9+z1pyDZWUMNXfzTT4H2=-fA@mail.gmail.com>
User-Agent: Mutt/1.11.4 (2019-03-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On (05/08/19 10:06), Daniel Vetter wrote:
[..]
> > Any printk-related patch in this area will make PeterZ really-really
> > angry :)
> 
> Hm any more context for someone with no clue about this? Just that the
> dependencies are already terribly complex and it's not going to get
> better, or something more specific?

The main problem is that it's a deferred error-reporting, so such
a report has chances to never be reported. It's not like 'normal'
printk() is always guaranteed to immediately start printing; sometimes
it will, sometimes it won't, and sometimes it never will, for instance
when console_sem was locked by offline-ed CPU.

An example of PeterZ's opinion on printk_deferred()
/* message ID: 20181122101606.GP2131@hirez.programming.kicks-ass.net */

  | No, printk_deferred() is a disease, it needs to be eradicated, not
  | spread around.

> > printk_deferred(), just like prinkt_safe(), depends on IRQ work;
> > printk_safe(), however, can redirect multiple lines, unlike
> > printk_deferred(). So if you want to keep the backtrace, you may
> > do something like
> >
> >         if (unlikely(cpu_is_offline(cpu))) {
> >                 printk_safe_enter(...);
> >                 WARN(1, "sched: Unexpected reschedule of offline CPU#%d!\n",
> >                          cpu);
> >                 printk_safe_exit(...);
> >                 return;
> >         }
> >
> > I think, in this case John's reworked-printk can do better than
> > printk_safe/printk_deferred.
> 
> Hm I think this is what Petr was suggesting, but somehow I didn't find
> the printk_safe_* functions and didn't connect the dots.

These are in kernel/printk/printk_safe.c as of now.

> Needs the _irqsave variants I guess, I'll respin a v2 of this.

Let's wait a bit before respin.

	-ss