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]
Date:	Fri, 07 Feb 2014 09:20:57 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	Luis Henriques <luis.henriques@...onical.com>,
	Levente Kurusa <levex@...ux.com>
CC:	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	kernel-team@...ts.ubuntu.com, Anssi Hannula <anssi.hannula@....fi>,
	Takashi Iwai <tiwai@...e.de>,
	Stephen Warren <swarren@...dia.com>
Subject: Re: [PATCH 3.11 229/233] ALSA: hda - hdmi: introduce patch_nvhdmi()

On 02/07/2014 07:36 AM, Luis Henriques wrote:
> On Fri, Feb 07, 2014 at 12:58:47PM +0100, Levente Kurusa wrote:
>> Hi,
>>
>> On 02/07/2014 12:47 PM, Luis Henriques wrote:
>>> 3.11.10.4 -stable review patch.  If anyone has any objections, please let me know.
>>>  [...]
>>>  
>>> +static int patch_nvhdmi(struct hda_codec *codec)
>>> +{
>>> +	struct hdmi_spec *spec;
>>> +	int err;
>>> +
>>> +	err = patch_generic_hdmi(codec);
>>> +	if (err)
>>> +		return err;
>>> +
>>> +	spec = codec->spec;
>>> +
>>> +	return 0;
>>> +}
>>> [...]
>>
>> Is it just me or is it that the 'spec' variable has no use?
> 
> This does seem a little bit odd indeed.  I've picked the backport provided
> by Stephen, which has been queued for the 3.10 and 3.12 stable kernels as
> well.  The original patch actually modifies the ops field in the hdmi_spec
> struct, however this field doesn't exist in this kernel version.
> 
> Stephen, could you please comment?  Since this is just a partial backport
> of 611885bc963a ("ALSA: hda - hdmi: Disallow unsupported 2ch remapping on
> NVIDIA codecs"), I'm assuming this is correct -- although the spec
> variable could have been dropped.

The very next patch of mine to this file (in other stable releases)
makes use of the spec variable. I kept the addition of the spec variable
in this patch, even though it isn't used until the next patch, so that
it stayed as part of the backport of this patch which originally added
it, rather than moving it to the other patch I backported, and hence
mixing up multiple upstream patches in the same backported patch.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ