linux-kernel - Re: [PATCH 2/2] arch/x86: Fix sparse warning symbol not declared

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] [day] [month] [year] [list]

Message-Id: <1487665152.3502698.887669128.7FFD96E7@webmail.messagingengine.com>
Date:   Tue, 21 Feb 2017 19:19:12 +1100
From:   Tobin Harding <me@...in.cc>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org
Subject: Re: [PATCH 2/2] arch/x86: Fix sparse warning symbol not declared

On Tue, Feb 14, 2017, at 08:24 AM, Thomas Gleixner wrote:
> On Tue, 14 Feb 2017, Tobin Harding wrote:
> > On Sun, Feb 12, 2017 at 12:06:47PM +0100, Thomas Gleixner wrote:
> > > The proper solution is to have a local include file 'purgatory.h' and put
> > > the declaration there. Include it in both files even if that's not required
> > > for the ASM file. But that documents, that the function is used outside of
> > > purgatory.c
> > 
> > Blindly following instructions led to the bone headed patch I
> > submitted yesterday (without building). Is there some way to include a
> > C header in an ASM file that I do not know about?
> 
> Yes, you have to guard the function declaration with
> 
> #ifndef __ASSEMBLY__
> 
> I did not think about that when I suggested this. Brainslip :)
> 
> So yes, it's kinda pointless, but it still has documentatory value and
> keeps the sparse build clean.
> 
> > Thanks for patiently pointing out how to write a commit log. May I
> > please bother you with another small etiquette question. Should I
> > have replayed to you as I have done so or should I have re-sent another
> > patch (v3) with the mistakes fixed (and stated in the log that I did
> > not know how to implement the suggestions).
> 
> All good. Either way works as long as you notice your own mistakes. It's
> also fine to tell me that I suggested nonsense. :)
> 

It has been pointed out to me that I could have approached the dev
process of this patch better. In the name of learning the correct method
I am now replying to your comments Thomas. Thanks for being patient, if
you could please slap me if I slip I should be able to blossom into a
decent contributor.

After sending an incorrect version (v3) with the __ASSEMBLY__
preprocessor guard in the wrong place, I re-sent v4 with what I believe
is all of your comments implemented and functioning.

Thanks for taking the time to review my annoying multi-version almost
trivial patch series.

thanks,
Tobin.