Re: [GIT PULL] x86/alternatives padding

2015-03-04 Thread Borislav Petkov
On Wed, Mar 04, 2015 at 09:22:27PM +0100, Ingo Molnar wrote: > So you could have a look at the detailed section dump itself via: > >objdump -h vmlinux > > there .text will be the raw text and .alt* will be listed separately. > The 'size' tool will add up executable sections IIRC, mixing

Re: [GIT PULL] x86/alternatives padding

2015-03-04 Thread Ingo Molnar
* Borislav Petkov wrote: > On Wed, Mar 04, 2015 at 12:22:06PM +0100, Borislav Petkov wrote: > > Well, kernel image doesn't change while vmlinux shows only a very small > > .text increase of about 2K. I'm not sure yet why that happens though > > because it shouldn't be the padding. Because we

Re: [GIT PULL] x86/alternatives padding

2015-03-04 Thread Borislav Petkov
On Wed, Mar 04, 2015 at 12:22:06PM +0100, Borislav Petkov wrote: > Well, kernel image doesn't change while vmlinux shows only a very small > .text increase of about 2K. I'm not sure yet why that happens though > because it shouldn't be the padding. Because we will have to do it > anyway, this

Re: [GIT PULL] x86/alternatives padding

2015-03-04 Thread Borislav Petkov
On Wed, Mar 04, 2015 at 08:32:21AM +0100, Ingo Molnar wrote: > Just curious: did the kernel image size change before/after these > changes? I.e. was any of the existing alternative instructions using > sites coded sub-optimally, with a larger maximum instruction size > allocated than strictly

Re: [GIT PULL] x86/alternatives padding

2015-03-04 Thread Borislav Petkov
On Wed, Mar 04, 2015 at 09:22:27PM +0100, Ingo Molnar wrote: So you could have a look at the detailed section dump itself via: objdump -h vmlinux there .text will be the raw text and .alt* will be listed separately. The 'size' tool will add up executable sections IIRC, mixing these

Re: [GIT PULL] x86/alternatives padding

2015-03-04 Thread Ingo Molnar
* Borislav Petkov b...@alien8.de wrote: On Wed, Mar 04, 2015 at 12:22:06PM +0100, Borislav Petkov wrote: Well, kernel image doesn't change while vmlinux shows only a very small .text increase of about 2K. I'm not sure yet why that happens though because it shouldn't be the padding.

Re: [GIT PULL] x86/alternatives padding

2015-03-04 Thread Borislav Petkov
On Wed, Mar 04, 2015 at 12:22:06PM +0100, Borislav Petkov wrote: Well, kernel image doesn't change while vmlinux shows only a very small .text increase of about 2K. I'm not sure yet why that happens though because it shouldn't be the padding. Because we will have to do it anyway, this patchset

Re: [GIT PULL] x86/alternatives padding

2015-03-04 Thread Borislav Petkov
On Wed, Mar 04, 2015 at 08:32:21AM +0100, Ingo Molnar wrote: Just curious: did the kernel image size change before/after these changes? I.e. was any of the existing alternative instructions using sites coded sub-optimally, with a larger maximum instruction size allocated than strictly

Re: [GIT PULL] x86/alternatives padding

2015-03-03 Thread Ingo Molnar
* Borislav Petkov wrote: > Hi guys, > > so this one has been long in the making and has been passing testing > on a bunch of boxes and bitness here so maybe we should try to put it > into the wider tip mix and see what happens. If all is well, great, if > there's trouble which I haven't

[GIT PULL] x86/alternatives padding

2015-03-03 Thread Borislav Petkov
Hi guys, so this one has been long in the making and has been passing testing on a bunch of boxes and bitness here so maybe we should try to put it into the wider tip mix and see what happens. If all is well, great, if there's trouble which I haven't managed to trigger in my testing, we can

[GIT PULL] x86/alternatives padding

2015-03-03 Thread Borislav Petkov
Hi guys, so this one has been long in the making and has been passing testing on a bunch of boxes and bitness here so maybe we should try to put it into the wider tip mix and see what happens. If all is well, great, if there's trouble which I haven't managed to trigger in my testing, we can

Re: [GIT PULL] x86/alternatives padding

2015-03-03 Thread Ingo Molnar
* Borislav Petkov b...@alien8.de wrote: Hi guys, so this one has been long in the making and has been passing testing on a bunch of boxes and bitness here so maybe we should try to put it into the wider tip mix and see what happens. If all is well, great, if there's trouble which I