mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	David Herrmann <dh.herrmann@gmail.com>
Subject: Re: Atomicity in KMS panic notifier
Date: Mon, 05 May 2014 16:48:55 +0200	[thread overview]
Message-ID: <s5hd2fsffhk.wl%tiwai@suse.de> (raw)
In-Reply-To: <CAKMK7uHcYvuViEeyxLc75+kMVPPaKMr8svJQysk124--cjGL+g@mail.gmail.com>

At Mon, 5 May 2014 16:29:37 +0200,
Daniel Vetter wrote:
> 
> On Mon, May 5, 2014 at 3:02 PM, Takashi Iwai <tiwai@suse.de> wrote:
> > Hi,
> >
> > while debugging a few reported bugs, I noticed that
> > drm_fb_helper_force_kernel_mode() that is called in the KMS panic
> > notifier isn't really atomic-safe.  It invokes crtc's set_config(),
> > and all implementations seem to involve with page allocations (kmalloc
> > with GFP_KERNEL, via some ttm ops, etc).  I've actually seen the Oops
> > with cirrus KMS during panic due to this.
> >
> > Does anyone have an idea to fix this?  I thought of re-using
> > drm_fb_helper_debug_enter(), but this won't work with many drivers
> > that don't have crtc->mode_set_base_atomic(), either (yeah, this is
> > another bug).
> 
> David Herrmann has a long-term plan to address this, using a much more
> minimal panic console (so that we can avoid all the fbcon madness) and
> adding a new driver callback to deliver a pointer to whatever
> framebuffers are currently displayed. If it's possible to obtain such
> a pointer in atomic contexts. Then we'd rip out all the existing panic
> notifier and handler stuff in fbcon. We'd also need to disable the
> panic notifier fbcon registers itself (since that ends up calling down
> into our ->set_par which again ends up in ->set_config).
> 
> That should leave us with some very minimal panic code to audit.
> 
> Imo trying to fix the current mess and making ->set_config work in
> atomic contexts is pointless. drm_can_sleep is trying to make that
> possible in some ways, and it's horrible since using it means
> busy-loops in atomic contexts outside of panic handlers won't get
> reported any more. Also the interactions with the console_lock (which
> due to some bonghits is protecting almost everything in fbcon/fbdev
> nowadays) would also be almost completely removed.
> 
> Unfortunately doing all this is a lot of work.

OK, thanks for clarification!

The current problem I see is that the rest of panic notifier chain
won't be called once when we hit the problem in KMS notifier.  So,
this bug in KMS influences on the rest panic behavior.

Maybe a hackish solution would be to keep KMS notifier at the end of
notifier chain so that it crashes at last.  I don't like this either,
but...


Takashi

  reply	other threads:[~2014-05-05 14:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-05 13:02 Takashi Iwai
2014-05-05 14:29 ` Daniel Vetter
2014-05-05 14:48   ` Takashi Iwai [this message]
2014-05-05 14:52     ` Daniel Vetter
2014-05-05 15:04       ` Takashi Iwai
2014-05-06 13:27       ` Takashi Iwai
2014-05-06 13:32         ` David Herrmann
2014-05-06 13:38           ` Takashi Iwai
2014-05-06 13:53             ` David Herrmann
2014-05-06 14:07               ` Takashi Iwai
2014-05-07 16:15   ` One Thousand Gnomes

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=s5hd2fsffhk.wl%tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=daniel@ffwll.ch \
    --cc=dh.herrmann@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®