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]
Message-ID: <20130108193918.GA12615@merkur.ravnborg.org>
Date:	Tue, 8 Jan 2013 20:39:18 +0100
From:	Sam Ravnborg <sam@...nborg.org>
To:	Jonathan Kliegman <kliegs@...omium.org>
Cc:	linux-kernel@...r.kernel.org, Michal Marek <mmarek@...e.cz>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Tony Lindgren <tony@...mide.com>, linux-kbuild@...r.kernel.org
Subject: Re: [PATCH] modpost: Add flag -f for making section mismatches
	fatal

On Tue, Jan 08, 2013 at 02:38:10PM -0500, Jonathan Kliegman wrote:
> On Tue, Jan 8, 2013 at 2:16 PM, Sam Ravnborg <sam@...nborg.org> wrote:
> > On Sun, Jan 06, 2013 at 03:22:39PM -0500, Jonathan Kliegman wrote:
> >> On Sun, Jan 6, 2013 at 4:36 AM, Sam Ravnborg <sam@...nborg.org> wrote:
> >> > Hi Jonathan.
> >> >
> >> >> The section mismatch warning can be easy to miss during the kernel build
> >> >> process.  Allow it to be marked as fatal to be easily caught and prevent
> >> >> bugs from slipping in.
> >> >>
> >> >> Signed-off-by: Jonathan Kliegman <kliegs@...omium.org>
> >> >
> >> > Another way to make them much more visible would be to make
> >> > the warnings always be verbose.
> >>
> >> I'd like to keep the option for a hard fail if a mismatch is detected.
> >>  This way automated build systems will detect the failed build and can
> >> reject a chan
> >>
> >> > In other words drop support for the "-S" options used below:
> >> >>   $(if $(CONFIG_DEBUG_SECTION_MISMATCH),,-S)
> >> >
> >> > Previously the dev* stuff caused a lot of warnings, but
> >> > since we have HOTPLUG always enabled this is a non-issue.
> >> > So I think that this is a good time to enable the verboce
> >> > warnings.
> >> I can submit a second patch for this if you'd like, but I'm not
> >> familiar with all the previous decisions in this area.  If I
> >> understand correctly we'll still need the config option as it also
> >> changes compiler flags for inlining.
> >
> > Correct.
> > We need one config option that allows us to debug section mismatchs.
> > This options adds another gcc option as you also points out.
> > And this is the one that already exist.
> >
> > And then you suggest to add another options which makes section
> > mismatch warnings fatal.
> > This sounds like a good idea but reverse the logic.
> > Something like:
> >
> >    CONFIG_SECTION_MISMATCH_WARN
> >         bool "Section mismatch warnings produced by modpost are non-fatal"
> >         default y
> >         help
> >           bla bla
> >
> > Because then you do not cause section mismatch to be fatal for allyesconfig and
> > allmodconfig builds. We really do not want to go there yet (I think).
> > I must admit I do not know how many section mismatch warnigns that are lingering
> > for the different architectures.
> > If the number is sufficiently low then we could consider go for fatal as default.
> >
> >
> > And it would be good to have first patch that makes section mismatch warnings verbose,
> > independent on any config options.
> >
> > This patch would have to do something like:
> > - Makes it possible to set CONFIG_DEBUG_SECTION_MISMATCH using menuconfig (I recall there are
> >   a dependency that avoids this today)
> > - Drop support for the -S options and drop the bits that set it
> > - Drop the reference to CONFIG_DEBUG_SECTION_MISMATCH in modpost error message
> >
> > I would be happy if you could do this and test it.
> Ok - I understand what you mean now.  I'll put this together as a two
> patch sequence then and upload it later this week.  Should I start a
> new thread with that since its adding a new patch?  Or just respond
> here with it?
Start a new thread.

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