linux-kernel - Re: [rfc] the kernel workflow & trivial "global -> static" patches (was: Re: [2.6 patch] make sched_feat

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:	Tue, 6 May 2008 00:45:21 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	mingo@...e.hu, a.p.zijlstra@...llo.nl,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	sam@...nborg.org, viro@....linux.org.uk, hpa@...or.com,
	Andy Whitcroft <apw@...dowen.org>
Subject: Re: [rfc] the kernel workflow & trivial "global -> static" patches
	(was: Re: [2.6 patch] make sched_feat_{names,open} static)

On Mon, May 05, 2008 at 02:26:04PM -0700, Andrew Morton wrote:
> On Tue, 6 May 2008 00:07:12 +0300
> Adrian Bunk <bunk@...nel.org> wrote:
> 
> > On Mon, May 05, 2008 at 01:42:52PM -0700, Andrew Morton wrote:
> > > On Mon, 5 May 2008 22:19:06 +0200
> > > Ingo Molnar <mingo@...e.hu> wrote:
> > > 
> > > > Firstly, the practical problem: today "make namespacecheck" emits way 
> > > > too many false positives even on an allyesconfig build
> > > 
> > > We don't actually care about what comes out of `make namespacecheck'.  We
> > > care about the _difference_ in its output when a patch is applied.
> > > 
> > > So a script which reports on what changes a particular patch has upon
> > > namespacecheck output might be the way to go.  If it is fast enough then it
> > > can be run on a per-patch basis alongside checkpatch.
> > 
> > "make namespacecheck" works on the binary objects.
> > 
> > - touching header files can result in a complete rebuild
> > - if a patch alters which objects get built you should start with
> >   a clean object dir
> > 
> > The question is therefore basically whether a complete rebuild of an
> > all*config kernel is fast enough for you...
> > 
> 
> That would be quite a bother.
> 
> I do think that we should aim to get these things fixed _before_ the
> offending patches get into mainline.  It's dopey to append a sprinkle of
> fixups against any particular patch after it has hit mainline when we have
> the tools to fix those things up beforehand.
> 
> And it'd help to educate submitters to check their own stuff.  So when
> these post-facto fixups are prepared then it is good to rub people's
> noses^W^W^Wgently remind submitters about the problems in their work.
> Probably you are already doing this.
> 
> Actually, we could perhaps do a lot of this at the checkpatch level?  If
> checkpatch sees a global symbol being added and the same patch does not add
> references to that symbol from a different file then whine.  Obviously this
> will generate false positives but that's OK.

Not sure what is possible at the checkpatch level.

Adding -Wmissing-prototypes to the CFLAGS (which was my original 
motivation for doing these patches) would help much, but it's still a 
long road until I can propose it without being lynched for the warnings 
it still generates...

Or teach people to use sparse?

After all, this thread erupted on a patch against kernel/sched.c
that fixes something sparse also warns about.

I just tried running sparse against this file - looks scary...

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

--
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/