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  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]
Date:	Mon, 05 Jan 2015 19:16:49 +0100
From:	Takashi Iwai <tiwai@...e.de>
To:	Alex Deucher <alexdeucher@...il.com>
Cc:	David Airlie <airlied@...ux.ie>,
	Alex Deucher <alexander.deucher@....com>,
	Christian Koenig <christian.koenig@....com>,
	Maling list - DRI developers 
	<dri-devel@...ts.freedesktop.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] drm/radeon: Fix kernel panic with HDMI w/o SAD

At Mon, 5 Jan 2015 12:48:05 -0500,
Alex Deucher wrote:
> 
> On Mon, Jan 5, 2015 at 12:23 PM, Takashi Iwai <tiwai@...e.de> wrote:
> > At Mon, 5 Jan 2015 12:07:52 -0500,
> > Alex Deucher wrote:
> >>
> >> On Sat, Jan 3, 2015 at 5:09 AM, Takashi Iwai <tiwai@...e.de> wrote:
> >> > A BUG_ON() call in dce3_2_afmt_write_sad_regs() is triggered when a
> >> > HDMI monitor without audio is plugged:
> >>
> >> I have a slightly different fix already queued up:
> >> http://lists.freedesktop.org/archives/dri-devel/2014-December/073672.html
> >
> > Oh, that's identical with my v1 patch :)  But, with that fix, an error
> > message will be shown at each time you plug such a monitor, right?
> > This doesn't look right, so I revised the patch.
> 
> Yes, but if the monitor claims to support audio, it should supply
> SADs.  If it doesn't, the driver has no way of knowing what type of
> audio the monitor supports.

IMO, we may assume that the monitor has no audio at all if sad_count =
0.  Or are there any monitors that do support audio even without
SAD...?

> I'm fine with removing the error message
> or making it debug only however.

If sad_count = 0 is an invalid state that shouldn't happen, then
printing an error is correct behavior.  So, the question comes to the
point whether sad_count = 0 is a sane value or not.

> > Also, can we skip the register write completely?  I thought of a case
> > like we replug a monitor from the one with audio to another without
> > audio...
> 
> Changing the monitor will generally trigger a full probe and modeset
> again anyway.  The register writes are just there to pass the audio
> information supported by the monitor along to the audio driver.

OK, thanks for clarification.


In anyway, I still think we should kill BUG_ON() there.  But this can
be a separate patch, of course.


Takashi

> 
> Alex
> 
> >
> >
> > thanks,
> >
> > Takashi
> >
> >>
> >> Alex
> >>
> >> >
> >> >  kernel BUG at ../drivers/gpu/drm/radeon/dce3_1_afmt.c:110!
> >> >  invalid opcode: 0000 [#1] PREEMPT SMP
> >> >  CPU: 2 PID: 967 Comm: Xorg Tainted: PO  3.16.7-7-desktop #1
> >> >  Hardware name: System manufacturer System Product Name/M4A77T, BIOS 2401    05/18/2011
> >> >  task: ffff8800cea86350 ti: ffff8800c1880000 task.ti: ffff8800c1880000
> >> >  RIP: 0010:[<ffffffffa0126c50>] dce3_1_hdmi_setmode+0x570/0x5a0 [radeon]
> >> >  Call Trace:
> >> >   [<ffffffffa00a6936>] drm_crtc_helper_set_mode+0x346/0x520 [drm_kms_helper]
> >> >   [<ffffffffa00a7678>] drm_crtc_helper_set_config+0x8a8/0xad0 [drm_kms_helper]
> >> >   [<ffffffffa00ede3f>] radeon_crtc_set_config+0x3f/0x110 [radeon]
> >> >   [<ffffffffa001edc1>] drm_mode_set_config_internal+0x61/0xe0 [drm]
> >> >   [<ffffffffa00a9a6b>] restore_fbdev_mode+0xab/0xd0 [drm_kms_helper]
> >> >   [<ffffffffa00a9aae>] drm_fb_helper_restore_fbdev_mode_unlocked+0x1e/0x30 [drm_kms_helper]
> >> >   [<ffffffffa00ab642>] drm_fb_helper_set_par+0x22/0x60 [drm_kms_helper]
> >> >   [<ffffffffa00ab5cb>] drm_fb_helper_hotplug_event+0x8b/0xe0 [drm_kms_helper]
> >> >   [<ffffffffa00ab65a>] drm_fb_helper_set_par+0x3a/0x60 [drm_kms_helper]
> >> >   [<ffffffff813818ce>] fb_set_var+0x15e/0x3b0
> >> >   [<ffffffff81378d0b>] fbcon_blank+0x1cb/0x2b0
> >> >   [<ffffffff813f2a31>] do_unblank_screen+0xa1/0x1b0
> >> >   [<ffffffff813e8fd3>] complete_change_console+0x53/0xe0
> >> >   [<ffffffff813e9fa9>] vt_ioctl+0xf49/0x10d0
> >> >   [<ffffffff813ddfdc>] tty_ioctl+0x26c/0xb70
> >> >   [<ffffffff811cad17>] do_vfs_ioctl+0x2e7/0x4c0
> >> >   [<ffffffff811caf71>] SyS_ioctl+0x81/0xa0
> >> >   [<ffffffff81622a2d>] system_call_fastpath+0x1a/0x1f
> >> >   [<00007f2fae8c6397>] 0x7f2fae8c6396
> >> >
> >> > Actually the BUG_ON() check is wrong, since sads may be NULL when
> >> > sad_count is zero.  This patch removes the BUG_ON() and adds the
> >> > proper NULL initialization of sads.
> >> >
> >> > Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=911356
> >> > Cc: <stable@...r.kernel.org>
> >> > Signed-off-by: Takashi Iwai <tiwai@...e.de>
> >> > ---
> >> >  drivers/gpu/drm/radeon/dce3_1_afmt.c | 3 +--
> >> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c b/drivers/gpu/drm/radeon/dce3_1_afmt.c
> >> > index 2fe8cfc966d9..7ca23f45829e 100644
> >> > --- a/drivers/gpu/drm/radeon/dce3_1_afmt.c
> >> > +++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c
> >> > @@ -72,7 +72,7 @@ static void dce3_2_afmt_write_sad_regs(struct drm_encoder *encoder)
> >> >         struct radeon_device *rdev = encoder->dev->dev_private;
> >> >         struct drm_connector *connector;
> >> >         struct radeon_connector *radeon_connector = NULL;
> >> > -       struct cea_sad *sads;
> >> > +       struct cea_sad *sads = NULL;
> >> >         int i, sad_count;
> >> >
> >> >         static const u16 eld_reg_to_type[][2] = {
> >> > @@ -107,7 +107,6 @@ static void dce3_2_afmt_write_sad_regs(struct drm_encoder *encoder)
> >> >                 DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> >> >                 return;
> >> >         }
> >> > -       BUG_ON(!sads);
> >> >
> >> >         for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
> >> >                 u32 value = 0;
> >> > --
> >> > 2.2.0
> >> >
> >> > _______________________________________________
> >> > dri-devel mailing list
> >> > dri-devel@...ts.freedesktop.org
> >> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >>
> 
--
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/

Powered by blists - more mailing lists