linux-kernel - Re: [REGRESSION] Recent change to kernel spikes out ccache/distcc

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, 7 Jan 2009 12:31:38 +0100
From:	Sam Ravnborg <sam@...nborg.org>
To:	Jan Beulich <jbeulich@...ell.com>
Cc:	Theodore Tso <tytso@....edu>, ccache@...ts.samba.org,
	linux-kernel@...r.kernel.org
Subject: Re: [REGRESSION] Recent change to kernel spikes out ccache/distcc

On Wed, Jan 07, 2009 at 08:50:56AM +0000, Jan Beulich wrote:
> >>> Theodore Tso <tytso@....edu> 06.01.09 18:33 >>>
> >On Tue, Jan 06, 2009 at 03:29:35PM +0000, Jan Beulich wrote:
> >> >>> "Theodore Ts'o" <tytso@....edu> 06.01.09 16:15 >>>
> >> >In the short term, though, it would be nice if we could get back a
> >> >simple way of making a kernel  object file using just cc, so that ccache
> >> >and distcc could be functional again.   Does that seem reasonable?
> >> 
> >> Making the new logic dependent on a config option would seem reasonable
> >> to me - of course at the expense of the respective Makefile becoming
> >> even less readable.
> >
> >Too late.  :-) It's pretty unreadable already.... as a result, I'm not
> >at all confident that I could make such a patch.  Is this something
> >you could perhaps whip up?  I'd really appreicate it, as it would
> >seriously speed up by kernel development efforts.
> 
> Yes, I think I could (and in fact I already put it on my to-do list), but I can't
> give a good prediction on when I'd be able to get to it.

We only see the ccache/distcc issue if we have MODVERSIONS
enabled.
So if we introduce a CONFIG option to disable strip of modules
then we will have the double amount of configuration
possibilities.

Today we have with or without MODVERSION.
If we make the stripping configurable then we will have
in addition two different configurations.

The reason to do the .c -> .s -> .o step is to make the
__crc_ symbols local so we can strip them off.

What is the gain/pain ratio here?
Would it be a possibility to drop stripping off the
crc symbols and go back to the ld method that
is more ccache friendly?

We would still benefir from all the other stripping done - no?

	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/