[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51B6C3CD1F10FB47A5702881E0E230A74A0ECAE1@ORSMSX104.amr.corp.intel.com>
Date: Thu, 11 Dec 2014 21:55:38 +0000
From: "Strasser, Kevin" <kevin.strasser@...el.com>
To: Mark Brown <broonie@...nel.org>
CC: "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
Liam Girdwood <lgirdwood@...il.com>,
"Koul, Vinod" <vinod.koul@...el.com>,
"Lin, Mengdong" <mengdong.lin@...el.com>,
"Fang, Yang A" <yang.a.fang@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] ASoC: Intel: fix possible acpi enumeration panic
> -----Original Message-----
> From: Mark Brown [mailto:broonie@...nel.org]
> Sent: Thursday, December 11, 2014 5:20 AM>
> On Wed, Dec 10, 2014 at 11:21:57PM -0800, Kevin Strasser wrote:
>
> > A crash can occur on some platforms where adsp is enumerated but codec
> > is not matched. Check that the codec_id string is valid before
> > attempting to match.
>
> > - for (mach = machines; mach->codec_id; mach++)
> > + for (mach = machines; mach->codec_id[0]; mach++)
>
> This changes the check from verifying if a codec_id is present to verifying if
> the first character in the codec_id is non-NULL. That doesn't seem obviously
> safer and the tables of machines seem to be terminated by having an entry
> with all fields set to zero (which is a common idiom in Linux) which would
> now crash with this change.
In this case mach->codec_id is non-NULL, even for the terminating element, because it
is defined to be a fixed width. So we have to take a look at the first character to see if it
has been initialized.
-Kevin
--
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