linux-kernel - Re: [PATCH 2/2] x86: intel-mid: sfi_handle_*_dev() should check for pdata error code

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:	Wed, 15 Jan 2014 09:39:52 -0800
From:	David Cohen <david.a.cohen@...ux.intel.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
	x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] x86: intel-mid: sfi_handle_*_dev() should check for
 pdata error code

On Wed, Jan 15, 2014 at 07:58:37AM +0100, Ingo Molnar wrote:
> 
> * David Cohen <david.a.cohen@...ux.intel.com> wrote:
> 
> > Hi Ingo,
> > 
> > On Fri, Dec 20, 2013 at 09:49:53AM +0100, Ingo Molnar wrote:
> > > 
> > > * David Cohen <david.a.cohen@...ux.intel.com> wrote:
> > > 
> > > > Prevent sfi_handle_*_dev() to register device in case
> > > > intel_mid_sfi_get_pdata() failed to execute.
> > > > 
> > > > Since 'NULL' is a valid return value, this patch makes
> > > > sfi_handle_*_dev() functions to use IS_ERR() to validate returned pdata.
> > > 
> > > Is this bug triggering in practice? If not then please say so in the 
> > > changelog. If yes then is this patch desired for v3.13 merging and 
> > > also please fix the changelog to conform to the standard changelog 
> > > style:
> > > 
> > >  - first describe the symptoms of the bug - how does a user notice?
> > > 
> > >  - then describe how the code behaves today and how that is causing
> > >    the bug
> > > 
> > >  - and then only describe how it's fixed.
> > > 
> > > The first item is the most important one - while developers 
> > > (naturally) tend to concentrate on the least important point, the last 
> > > one.
> > 
> > Thanks for the feedback :)
> > This new patch set was done in reply to your comment:
> > https://lkml.org/lkml/2013/12/20/517
> 
> Hm, in what way does the new changelog address my first request:
> 
> > >  - first describe the symptoms of the bug - how does a user notice?
> 
> They are all phrased as bug fixes, yet _none_ of the three changelogs 
> appears to describe specific symptoms on specific systems - they all 
> seem to talk in the abstract, with no specific connection to reality.
> 
> That really makes it harder for patches to get into the (way too 
> narrow) attention span of maintainersm, while phrasing it like this:
> 
>  'If an Intel-MID system boots in a specific SFI environment then it 
>   will hang on bootup without this fix.'
> 
> or:
> 
>  'Existing Intel-MID hardware will run faster with this patch.'
> 
> will certainly wake up maintainers like a good coffee in the morning.
> 
> If a patch is a cleanup with no known bug fix effects then say so in 
> the title and the changelog.

Fair enough.
These patches are fixing a potential bug that exists in current kernel,
but I triggered with patches in my development tree that depends on
this one to be refactored first:
https://patchwork.kernel.org/patch/3109791/

I tried to describe the potential bug, but it lacks the real use case as
you pointed out. I'll resend the patches in a way to trigger and
describe the situation without dependiing on non-upstreamed patches yet.
And I'll hurry up to publish my intel mid devel tree as well.

I hope the new patch set tastes like good morning Brazilian coffee :)

Br, David Cohen

> 
> Thanks,
> 
> 	Ingo
--
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/