linux-kernel - Re: Inline hunt results for 4.3.0-rc1

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: <1445959516.1395310.421591905.57DE155F@webmail.messagingengine.com>
Date:	Tue, 27 Oct 2015 16:25:16 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Denys Vlasenko <vda.linux@...glemail.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: Inline hunt results for 4.3.0-rc1

On Tue, Oct 27, 2015, at 16:17, Denys Vlasenko wrote:
> On Tue, Oct 27, 2015 at 3:55 PM, Hannes Frederic Sowa
> <hannes@...essinduktion.org> wrote:
> > On Tue, Oct 27, 2015, at 15:32, Denys Vlasenko wrote:
> >> I have created a set of semi-automated scripts which look for
> >> large inlines in the kernel.
> >>
> >> Recently I taught it to even generate "git format-patch" patches
> >> (unfortunately, only for inlines in *.c files, not *.h),
> >> and here are they for 4.3.0-rc1 - i.e. current Linus tree.
> >>
> >> Submitting 300+ patches separately would amount to spamming,
> >> instead I encourage people to take a look at the patches
> >> on the Web:
> >>
> >>     http://busybox.net/~vda/inline_hunt/4.3.0-rc1/
> >>     http://busybox.net/~vda/inline_hunt/4.3.0-rc1/README
> >>
> >> and in particular, at the set of most juicy patches, each of which
> >> shaves off more than 1000 bytes off its *.c module:
> >>
> >>     http://busybox.net/~vda/inline_hunt/4.3.0-rc1/patch_saves1000/
> >
> > Does gcc -finline-limit=2000 somehow has the same effect?
> 
> I'm afraid that's not a solution.

Ok, thank you.

> Any compiler-option-based fix would only work for inlines in *.c
> files, but at the same time it would replicate inlines in *.h files
> many times (once per module which calls the "auto-deinlined" inline).

Do your patches also detect functions which are in Header files with
static inline and we take their address often? Maybe dst_output(_sk)
could be an example?

Bye,
Hanes
--
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/