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;
MIME-Version: 1.0
References: <20190507173329.17031-1-daniel.vetter@ffwll.ch> <20190508074420.GB15704@jagdpanzerIV>
In-Reply-To: <20190508074420.GB15704@jagdpanzerIV>
From:   Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed, 8 May 2019 10:25:19 +0200
Message-ID: <CAKMK7uHF_2QyYP5TB40gPQ6eG_=qk4ucij4RHnM_E=vutqWH5g@mail.gmail.com>
Subject: Re: [PATCH] RFC: x86/smp: use printk_deferred in native_smp_send_reschedule
To:     Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc:     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>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, May 8, 2019 at 9:44 AM Sergey Senozhatsky
<sergey.senozhatsky.work@gmail.com> wrote:
>
> On (05/07/19 19:33), Daniel Vetter wrote:
> [..]
> > - make the console_trylock trylock also the spinlock. This works in
> >   the limited case of the console_lock use-case, but doesn't fix the
> >   same semaphore.lock acquisition in the up() path in console_unlock,
> >   which we can't avoid with a trylock.
> >
> > - move the wake_up_process in up() out from under the semaphore.lock
> >   spinlock critical section. Again this works for the limited case of
> >   the console_lock, and does fully break the cycle for this lock.
> >   Unfortunately there's still plenty of scheduler related locks that
> >   wake_up_process needs, so the loop is still there, just with a few
> >   less locks involved.
> >
> > Hence now third attempt, trying to fix this by using printk_deferred()
> > instead of the normal printk that WARN() uses.
> > native_smp_send_reschedule is only called from scheduler related code,
> > which has to use printk_deferred due to this locking recursion, so
> > this seems consistent.
> >
> > It has the unfortunate downside that we're losing the backtrace though
> > (I didn't find a printk_deferred version of WARN, and I'm not sure
> > it's a bright idea to dump that much using printk_deferred.)
>
> I'm catching up with the emails now (was offline for almost 2 weeks),
> so I haven't seen [yet] all of the previous patches/discussions.
>
> [..]
> >  static void native_smp_send_reschedule(int cpu)
> >  {
> >       if (unlikely(cpu_is_offline(cpu))) {
> > -             WARN(1, "sched: Unexpected reschedule of offline CPU#%d!\n", cpu);
> > +             printk_deferred(KERN_WARNING
> > +                             "sched: Unexpected reschedule of offline CPU#%d!\n", cpu);
> >               return;
> >       }
> >       apic->send_IPI(cpu, RESCHEDULE_VECTOR);
>
> Hmm,
> One thing to notice here is that the CPU in question is offline-ed,
> and printk_deferred() is a per-CPU type of deferred printk(). So the
> following thing
>
>         __this_cpu_or(printk_pending, PRINTK_PENDING_OUTPUT);
>         irq_work_queue(this_cpu_ptr(&wake_up_klogd_work));
>
> might not print anything at all. In this particular case we always
> need another CPU to do console_unlock(), since this_cpu() is not
> really expected to do wake_up_klogd_work_func()->console_unlock().

Hm right, I was happy enough when Petr pointed out the printk_deferred
infrastructure that I didn't look too deeply into how it works. From a
quick loo


--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch