From: Kevin Strasser <kevin.strasser@linux.intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: "Strasser, Kevin" <kevin.strasser@intel.com>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"Koul, Vinod" <vinod.koul@intel.com>,
"Lin, Mengdong" <mengdong.lin@intel.com>,
Liam Girdwood <lgirdwood@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Fang, Yang A" <yang.a.fang@intel.com>
Subject: Re: [alsa-devel] [PATCH] ASoC: Intel: fix possible acpi enumeration panic
Date: Mon, 15 Dec 2014 15:22:56 -0800 [thread overview]
Message-ID: <20141215232256.GC27822@H87M> (raw)
In-Reply-To: <20141215170645.GH11764@sirena.org.uk>
On Mon, Dec 15, 2014 at 05:06:45PM +0000, Mark Brown wrote:
> Please fix your mailer to word wrap comfortably under 80 colums so that your
> mails are easily legible.
Understood
> > > 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.
>
> That's a really unusual and (as you've seen) error prone idiom - is it not
> better to fix the struct to use the more common idiom?
That seems like a good idea to me. I'll prepare a new patch to change the
sst_machines definition so that codec_id gets initialized to NULL.
-Kevin
next prev parent reply other threads:[~2014-12-15 23:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-11 7:21 [PATCH] ASoC: Intel: fix possible acpi enumeration panic Kevin Strasser
2014-12-11 13:20 ` Mark Brown
2014-12-11 21:55 ` Strasser, Kevin
2014-12-15 17:06 ` Mark Brown
2014-12-15 17:06 ` Mark Brown
2014-12-15 23:22 ` Kevin Strasser [this message]
2014-12-16 0:15 ` [PATCH v2] " Kevin Strasser
2014-12-16 11:52 ` Mark Brown
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=20141215232256.GC27822@H87M \
--to=kevin.strasser@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=kevin.strasser@intel.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mengdong.lin@intel.com \
--cc=vinod.koul@intel.com \
--cc=yang.a.fang@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.