linux-kernel - Re: [git pull] drm fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFz0sPd2ovVCkbQKap9qcOfNsZ3rbuRhCLahZj18SvzYmQ@mail.gmail.com>
Date:	Sat, 28 Feb 2015 21:40:31 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Airlie <airlied@...ux.ie>,
	Daniel Vetter <daniel.vetter@...el.com>,
	Jani Nikula <jani.nikula@...ux.intel.com>
Cc:	DRI mailing list <dri-devel@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	intel-gfx <intel-gfx@...ts.freedesktop.org>
Subject: Re: [git pull] drm fixes

Hmm. I haven't updated the old Mac Mini I have in a *long* time, but
today I decided to try.

And it causes problems in drm.

I'm not sure how new these problems are, I think the previous kernel I
booted on this machine was 3.16. But I thought I'd better report them
as-is, because bisection on this thing takes *forever*, and it's quite
possible that you or one of the i915 guys goes "ahh, of course", so no
point in wasting time on bisection unless absolutely required.

Anyway, I have two warnings, and then had to do a work-around to avoid an oops.

Warning #1:

    ...
    fbcon: inteldrmfb (fb0) is primary device
    random: nonblocking pool is initialized
    [drm] Setting output timings on SDVOB failed
    ------------[ cut here ]------------
    WARNING: CPU: 1 PID: 15 at drivers/gpu/drm/i915/i915_gem.c:4524
i915_gem_free_object+0x22d/0x250()
    WARN_ON(obj->frontbuffer_bits)
    CPU: 1 PID: 15 Comm: kworker/u4:1 Tainted: G        W
4.0.0-rc1-00129-g6380ad5-dirty #3
    Hardware name: Apple Computer, Inc. Macmini1,1/Mac-F4208EC8, BIOS
   MM11.88Z.0055.B03.0604071521 04/07/06
    Workqueue: events_unbound async_run_entry_fn
    Call Trace:
      dump_stack+0x41/0x52
      warn_slowpath_common+0x7f/0xb0
      warn_slowpath_fmt+0x2e/0x30
      i915_gem_free_object+0x22d/0x250
      drm_gem_object_free+0x1a/0x20
      intel_user_framebuffer_destroy+0x5d/0x80
      drm_framebuffer_free+0x43/0x60
      drm_framebuffer_unreference+0x28/0x60
      drm_mode_set_config_internal+0x8e/0xc0
      restore_fbdev_mode+0xc2/0xf0
      drm_fb_helper_restore_fbdev_mode_unlocked+0x24/0x70
      drm_fb_helper_set_par+0x1d/0x40
      intel_fbdev_set_par+0x18/0x60
      fbcon_init+0x4e2/0x530
      do_bind_con_driver+0x15e/0x330
      do_take_over_console+0xd5/0x160
      do_fbcon_takeover+0x5d/0xc0
      fbcon_event_notify+0x5dd/0x760
      notifier_call_chain+0x41/0x60
      __blocking_notifier_call_chain+0x46/0x60
      blocking_notifier_call_chain+0x1a/0x20
      fb_notifier_call_chain+0x11/0x20
      register_framebuffer+0x1f2/0x2f0
      drm_fb_helper_initial_config+0x2aa/0x370
      intel_fbdev_initial_config+0x14/0x20
      async_run_entry_fn+0x31/0xd0
      process_one_work+0xee/0x2b0
      worker_thread+0x39/0x400
      kthread+0xac/0xd0
      ret_from_kernel_thread+0x21/0x30
    ---[ end trace e533d8d502f4f45e ]---
    Console: switching to colour frame buffer device 210x65
    ...

but things seemed to work despite it. The more scary warning is #2:

    ...
    dracut: Starting plymouth daemon
    usb 5-1: new full-speed USB device number 2 using uhci_hcd
    setfont (1129) used greatest stack depth: 6448 bytes left
    ------------[ cut here ]------------
    WARNING: CPU: 1 PID: 1127 at include/linux/kref.h:47
drm_framebuffer_reference+0x39/0x70()
    CPU: 1 PID: 1127 Comm: plymouthd Tainted: G        W
4.0.0-rc1-00129-g6380ad5-dirty #3
    Hardware name: Apple Computer, Inc. Macmini1,1/Mac-F4208EC8, BIOS
   MM11.88Z.0055.B03.0604071521 04/07/06
    Call Trace:
      dump_stack+0x41/0x52
      warn_slowpath_common+0x7f/0xb0
      warn_slowpath_null+0x1d/0x20
      drm_framebuffer_reference+0x39/0x70
      intel_plane_duplicate_state+0x36/0x70
      drm_plane_helper_update+0x24/0xc0
      __intel_set_mode+0x71c/0x9c0
      intel_set_mode+0x6b/0x90
      intel_get_load_detect_pipe+0x332/0x470
      intel_tv_detect+0x84/0x4e0
      drm_helper_probe_single_connector_modes_merge_bits+0x1a3/0x440
      drm_helper_probe_single_connector_modes+0x12/0x20
      drm_mode_getconnector+0x2e7/0x320
      drm_ioctl+0x1e5/0x560
      do_vfs_ioctl+0x71/0x590
      SyS_ioctl+0x92/0xa0
      syscall_call+0x7/0x7
    ---[ end trace e533d8d502f4f460 ]---
    usb 5-1: New USB device found, idVendor=05ac, idProduct=1000
    usb 5-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
    ...

which is scary because it implies some bad reference counting problem.
And in fact, that warning was followed by a NULL pointer oops, which I
worked around with this crazy patch:

    diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
    index 6b6b07f..28527ac 100644
    --- a/drivers/gpu/drm/drm_crtc.c
    +++ b/drivers/gpu/drm/drm_crtc.c
    @@ -452,7 +452,8 @@ static void drm_framebuffer_free(struct kref *kref)
            }
            mutex_unlock(&dev->mode_config.fb_lock);

    -       fb->funcs->destroy(fb);
    +       if (fb->funcs)
    +               fb->funcs->destroy(fb);
     }

     static struct drm_framebuffer *__drm_framebuffer_lookup(struct
drm_device *dev,

because "fb->funcs" was NULL. I assume it was NULL because some fb
freeing had cleared them already due to the kref going down to zero.

Any ideas? This is an ancient box with ancient user land, and not
getting a lot of testing. But it *used* to work.

                         Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/