Re: [tip:x86/urgent] x86/vdso: Discard the __bug_table section
On Tue, Jun 24, 2014 at 11:43 AM, H. Peter Anvin wrote:
> On 06/24/2014 11:37 AM, Andy Lutomirski wrote:
>>>
>>> diff --git a/arch/x86/vdso/vdso2c.h b/arch/x86/vdso/vdso2c.h
>>> index f42e2ddc663d..94158e100f26 100644
>>> --- a/arch/x86/vdso/vdso2c.h
>>> +++ b/arch/x86/vdso/vdso2c.h
>>> @@ -99,8 +99,9 @@ static void BITSFUNC(copy_section)(struct
>>> BITSFUNC(fake_sections) *out,
>>> if (!copy)
>>> return;
>>>
>>> - if (out->count >= out->max_count)
>>> - fail("too many copied sections (max = %d)\n",
>>> out->max_count);
>>> + if (out->count > out->max_count)
>>> + fail("too many copied sections (max = %d, need = %d)\n",
>>> +out->max_count, out->count);
>>>
>>
>> I think the old test was correct: we haven't incremented count yet
>> (it's a couple lines below), so count is the zero-based index to which
>> we're writing.
>>
>> I thought of doing the need = %d thing, but I think that the output is
>> a foregone conclusion: count == max_count + 1 when this fails. A list
>> of all the section names would be more interesting, but eu-readelf -S
>> will tell is that.
>>
>
> Well, I have reproduced this failure. eu-readelf output included.
It's branch profiling. Patches coming.
>
> -hpa
>
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/urgent] x86/vdso: Discard the __bug_table section
On 06/24/2014 11:29 AM, H. Peter Anvin wrote: > > Hi Ingo, > > Could you try this with the attached patch? > Nevermind, not useful... -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/urgent] x86/vdso: Discard the __bug_table section
On 06/24/2014 11:37 AM, Andy Lutomirski wrote:
>>
>> diff --git a/arch/x86/vdso/vdso2c.h b/arch/x86/vdso/vdso2c.h
>> index f42e2ddc663d..94158e100f26 100644
>> --- a/arch/x86/vdso/vdso2c.h
>> +++ b/arch/x86/vdso/vdso2c.h
>> @@ -99,8 +99,9 @@ static void BITSFUNC(copy_section)(struct
>> BITSFUNC(fake_sections) *out,
>> if (!copy)
>> return;
>>
>> - if (out->count >= out->max_count)
>> - fail("too many copied sections (max = %d)\n",
>> out->max_count);
>> + if (out->count > out->max_count)
>> + fail("too many copied sections (max = %d, need = %d)\n",
>> +out->max_count, out->count);
>>
>
> I think the old test was correct: we haven't incremented count yet
> (it's a couple lines below), so count is the zero-based index to which
> we're writing.
>
> I thought of doing the need = %d thing, but I think that the output is
> a foregone conclusion: count == max_count + 1 when this fails. A list
> of all the section names would be more interesting, but eu-readelf -S
> will tell is that.
>
Well, I have reproduced this failure. eu-readelf output included.
-hpa
o.test/arch/x86/vdso/vdso32-int80.so.dbg
There are 27 section headers, starting at offset 0x9774:
Section Headers:
[Nr] Name Type Addr OffSize ES Flags Lk Inf Al
[ 0] NULL 00 00 00 0 0
[ 1] .hashHASH 00b4 b4 38 4 A 2 0 4
[ 2] .dynsym DYNSYM 00ec ec 90 16 A 3 1 4
[ 3] .dynstr STRTAB 017c 00017c 95 0 A 0 0 1
[ 4] .gnu.version GNU_versym 0212 000212 12 2 A 2 0 2
[ 5] .gnu.version_d GNU_verdef 0224 000224 54 0 A 3 3 4
[ 6] .dynamic DYNAMIC 0278 000278 80 8 WA 3 0 4
[ 7] .rodata PROGBITS 02f8 0002f8 000228 4 WA 0 0 4
[ 8] .fake_shstrtab PROGBITS 0520 000520 76 0 A 0 0 32
[ 9] .noteNOTE 0598 000598 60 0 A 0 0 4
[10] .eh_frame_hdrPROGBITS 05f8 0005f8 24 0 A 0 0 4
[11] .eh_framePROGBITS 061c 00061c f4 0 A 0 0 4
[12] .textPROGBITS 0710 000710 000633 0 AX 0 0 16
[13] .altinstructions PROGBITS 0d43 000d43 18 0 A 0 0 1
[14] .altinstr_replacement PROGBITS 0d5b 000d5b 06 0 AX 0 0
1
[15] .debug_info PROGBITS 000d61 004a84 00 0 1
[16] .debug_abbrevPROGBITS 0057e5 000519 00 0 1
[17] .debug_loc PROGBITS 005cfe 00064f 00 0 1
[18] .debug_aranges PROGBITS 006350 58 00 0 8
[19] .debug_rangesPROGBITS 0063a8 000208 00 0 1
[20] .debug_line PROGBITS 0065b0 00077b 00 0 1
[21] .debug_str PROGBITS 006d2b 0027f2 1 MS 0 0 1
[22] .comment PROGBITS 00951d 2c 1 MS 0 0 1
[23] .debug_frame PROGBITS 00954c 000100 00 0 4
[24] .shstrtabSTRTAB 00964c 000127 00 0 1
[25] .symtab SYMTAB 009bac 000380 16 26 48 4
[26] .strtab STRTAB 009f2c 000226 00 0 1
o.test/arch/x86/vdso/vdso32-syscall.so.dbg
There are 27 section headers, starting at offset 0x979c:
Section Headers:
[Nr] Name Type Addr OffSize ES Flags Lk Inf Al
[ 0] NULL 00 00 00 0 0
[ 1] .hashHASH 00b4 b4 38 4 A 2 0 4
[ 2] .dynsym DYNSYM 00ec ec 90 16 A 3 1 4
[ 3] .dynstr STRTAB 017c 00017c 95 0 A 0 0 1
[ 4] .gnu.version GNU_versym 0212 000212 12 2 A 2 0 2
[ 5] .gnu.version_d GNU_verdef 0224 000224 54 0 A 3 3 4
[ 6] .dynamic DYNAMIC 0278 000278 80 8 WA 3 0 4
[ 7] .rodata PROGBITS 02f8 0002f8 000220 4 WA 0 0 4
[ 8] .fake_shstrtab PROGBITS 0520 000520 76 0 A 0 0 32
[ 9] .noteNOTE 0598 000598 60 0 A 0 0 4
[10] .eh_frame_hdrPROGBITS 05f8 0005f8 24 0 A 0 0 4
[11] .eh_framePROGBITS 061c 00061c fc 0 A 0 0 4
[12] .textPROGBITS 0720 000720 000640 0 AX 0 0 16
[13] .altinstructions PROGBITS 0d60 000d60 18 0 A 0 0 1
[14] .altinstr_replacement PROGBITS 0d78 000d78 06 0 AX 0 0
1
[15] .debug_info PROGB
Re: [tip:x86/urgent] x86/vdso: Discard the __bug_table section
On Tue, Jun 24, 2014 at 11:26 AM, H. Peter Anvin wrote:
> On 06/24/2014 11:19 AM, Andy Lutomirski wrote:
One of the recent x86/urgent vdso commits causes this build failure:
Error: too many copied sections (max = 13)
>>>
>>> I can't reproduce this with your config, which suggestes a binutils
>>> issue, which is annoying. Can you tell me what version of ld you're
>>> using and send me the output of:
>>>
>>> for i in arch/x86/vdso/*.so.dbg; do echo $i; eu-readelf -S $i; done
>>
>> Ping!
>>
>> The current state of this is obviously not so good, but I don't know
>> how to proceed.
>>
>
> We used to have this kind of problems with PHDRs, where ld would guess
> how much space it would need, somehow guess wrong, and fall on its face.
>
> I think we want to actually print the number that we are trying to copy
> in addition to the maximum, and I also noticed the test looks wrong.
> Thus I would like to propose the following patch as a diagnostic:
>
> diff --git a/arch/x86/vdso/vdso2c.h b/arch/x86/vdso/vdso2c.h
> index f42e2ddc663d..94158e100f26 100644
> --- a/arch/x86/vdso/vdso2c.h
> +++ b/arch/x86/vdso/vdso2c.h
> @@ -99,8 +99,9 @@ static void BITSFUNC(copy_section)(struct
> BITSFUNC(fake_sections) *out,
> if (!copy)
> return;
>
> - if (out->count >= out->max_count)
> - fail("too many copied sections (max = %d)\n",
> out->max_count);
> + if (out->count > out->max_count)
> + fail("too many copied sections (max = %d, need = %d)\n",
> +out->max_count, out->count);
>
I think the old test was correct: we haven't incremented count yet
(it's a couple lines below), so count is the zero-based index to which
we're writing.
I thought of doing the need = %d thing, but I think that the output is
a foregone conclusion: count == max_count + 1 when this fails. A list
of all the section names would be more interesting, but eu-readelf -S
will tell is that.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/urgent] x86/vdso: Discard the __bug_table section
On 06/22/2014 01:47 AM, Ingo Molnar wrote:
>
> * tip-bot for Andy Lutomirski wrote:
>
>> Commit-ID: 5f56e7167e6d438324fcba87018255d81e201383
>> Gitweb:
>> http://git.kernel.org/tip/5f56e7167e6d438324fcba87018255d81e201383
>> Author: Andy Lutomirski
>> AuthorDate: Wed, 18 Jun 2014 15:59:46 -0700
>> Committer: H. Peter Anvin
>> CommitDate: Thu, 19 Jun 2014 15:44:51 -0700
>>
>> x86/vdso: Discard the __bug_table section
>>
>> It serves no purpose in user code.
>>
>> Signed-off-by: Andy Lutomirski
>> Link:
>> http://lkml.kernel.org/r/2a5bebff42defd8a5e81d96f7dc00f21143c80e8.1403129369.git.l...@amacapital.net
>> Signed-off-by: H. Peter Anvin
>> ---
>> arch/x86/vdso/vdso-layout.lds.S | 1 +
>> 1 file changed, 1 insertion(+)
>
> One of the recent x86/urgent vdso commits causes this build failure:
>
> Error: too many copied sections (max = 13)
> make[2]: *** [arch/x86/vdso/vdso-image-64.c] Error 1
> make[1]: *** [arch/x86/vdso] Error 2
> make: *** [arch/x86] Error 2
>
> with the attached config.
>
Hi Ingo,
Could you try this with the attached patch?
-hpa
>From e28dc3efe8a8880206e90886cc12649f87fa1848 Mon Sep 17 00:00:00 2001
From: "H. Peter Anvin"
Date: Tue, 24 Jun 2014 11:26:18 -0700
Subject: [PATCH] x86/vdso: Make vdso2c print the number of sections needed on
error
If we run out of space for section, at least make the error message
print the amount of space we need so we can actually diagnose it.
Furthermore, the test should be > instead of >= (it is okay to have
exactly the maximum number of sections.)
Signed-off-by: H. Peter Anvin
Cc: Andy Lutomirski
Link: http://lkml.kernel.org/r/20140622084754.ga15...@gmail.com
---
arch/x86/vdso/vdso2c.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/vdso/vdso2c.h b/arch/x86/vdso/vdso2c.h
index f42e2ddc663d..94158e100f26 100644
--- a/arch/x86/vdso/vdso2c.h
+++ b/arch/x86/vdso/vdso2c.h
@@ -99,8 +99,9 @@ static void BITSFUNC(copy_section)(struct BITSFUNC(fake_sections) *out,
if (!copy)
return;
- if (out->count >= out->max_count)
- fail("too many copied sections (max = %d)\n", out->max_count);
+ if (out->count > out->max_count)
+ fail("too many copied sections (max = %d, need = %d)\n",
+ out->max_count, out->count);
if (in_idx == out->in_shstrndx)
out->out_shstrndx = out->count;
--
1.9.3
Re: [tip:x86/urgent] x86/vdso: Discard the __bug_table section
On 06/24/2014 11:19 AM, Andy Lutomirski wrote:
>>>
>>> One of the recent x86/urgent vdso commits causes this build failure:
>>>
>>> Error: too many copied sections (max = 13)
>>
>> I can't reproduce this with your config, which suggestes a binutils
>> issue, which is annoying. Can you tell me what version of ld you're
>> using and send me the output of:
>>
>> for i in arch/x86/vdso/*.so.dbg; do echo $i; eu-readelf -S $i; done
>
> Ping!
>
> The current state of this is obviously not so good, but I don't know
> how to proceed.
>
We used to have this kind of problems with PHDRs, where ld would guess
how much space it would need, somehow guess wrong, and fall on its face.
I think we want to actually print the number that we are trying to copy
in addition to the maximum, and I also noticed the test looks wrong.
Thus I would like to propose the following patch as a diagnostic:
diff --git a/arch/x86/vdso/vdso2c.h b/arch/x86/vdso/vdso2c.h
index f42e2ddc663d..94158e100f26 100644
--- a/arch/x86/vdso/vdso2c.h
+++ b/arch/x86/vdso/vdso2c.h
@@ -99,8 +99,9 @@ static void BITSFUNC(copy_section)(struct
BITSFUNC(fake_sections) *out,
if (!copy)
return;
- if (out->count >= out->max_count)
- fail("too many copied sections (max = %d)\n",
out->max_count);
+ if (out->count > out->max_count)
+ fail("too many copied sections (max = %d, need = %d)\n",
+out->max_count, out->count);
if (in_idx == out->in_shstrndx)
out->out_shstrndx = out->count;
Does anyone have any objection? Andy, I presume I am correct that =>
should be > there?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/urgent] x86/vdso: Discard the __bug_table section
On Sun, Jun 22, 2014 at 9:59 AM, Andy Lutomirski wrote: > On Sun, Jun 22, 2014 at 1:47 AM, Ingo Molnar wrote: >> >> * tip-bot for Andy Lutomirski wrote: >> >>> Commit-ID: 5f56e7167e6d438324fcba87018255d81e201383 >>> Gitweb: >>> http://git.kernel.org/tip/5f56e7167e6d438324fcba87018255d81e201383 >>> Author: Andy Lutomirski >>> AuthorDate: Wed, 18 Jun 2014 15:59:46 -0700 >>> Committer: H. Peter Anvin >>> CommitDate: Thu, 19 Jun 2014 15:44:51 -0700 >>> >>> x86/vdso: Discard the __bug_table section >>> >>> It serves no purpose in user code. >>> >>> Signed-off-by: Andy Lutomirski >>> Link: >>> http://lkml.kernel.org/r/2a5bebff42defd8a5e81d96f7dc00f21143c80e8.1403129369.git.l...@amacapital.net >>> Signed-off-by: H. Peter Anvin >>> --- >>> arch/x86/vdso/vdso-layout.lds.S | 1 + >>> 1 file changed, 1 insertion(+) >> >> One of the recent x86/urgent vdso commits causes this build failure: >> >> Error: too many copied sections (max = 13) > > I can't reproduce this with your config, which suggestes a binutils > issue, which is annoying. Can you tell me what version of ld you're > using and send me the output of: > > for i in arch/x86/vdso/*.so.dbg; do echo $i; eu-readelf -S $i; done Ping! The current state of this is obviously not so good, but I don't know how to proceed. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/urgent] x86/vdso: Discard the __bug_table section
On Sun, Jun 22, 2014 at 1:47 AM, Ingo Molnar wrote: > > * tip-bot for Andy Lutomirski wrote: > >> Commit-ID: 5f56e7167e6d438324fcba87018255d81e201383 >> Gitweb: >> http://git.kernel.org/tip/5f56e7167e6d438324fcba87018255d81e201383 >> Author: Andy Lutomirski >> AuthorDate: Wed, 18 Jun 2014 15:59:46 -0700 >> Committer: H. Peter Anvin >> CommitDate: Thu, 19 Jun 2014 15:44:51 -0700 >> >> x86/vdso: Discard the __bug_table section >> >> It serves no purpose in user code. >> >> Signed-off-by: Andy Lutomirski >> Link: >> http://lkml.kernel.org/r/2a5bebff42defd8a5e81d96f7dc00f21143c80e8.1403129369.git.l...@amacapital.net >> Signed-off-by: H. Peter Anvin >> --- >> arch/x86/vdso/vdso-layout.lds.S | 1 + >> 1 file changed, 1 insertion(+) > > One of the recent x86/urgent vdso commits causes this build failure: > > Error: too many copied sections (max = 13) I can't reproduce this with your config, which suggestes a binutils issue, which is annoying. Can you tell me what version of ld you're using and send me the output of: for i in arch/x86/vdso/*.so.dbg; do echo $i; eu-readelf -S $i; done To summarize, the issue is that, in 3.16, the vvar area is accessed in a PC-relative manner from the vdso code. So we have: vdso page 1 | vdso page 2 | vvar page 1 | vvar page 2 (where the number of vdso pages can vary) The difficulty comes from the fact that a decent amount of userspace code wants the vdso to have some section headers, and linkers don't stick section headers into allocatable sections, since section headers were never intended to be memory mapped. So there's a risk that the section headers dangle off the last loadable page in the vdso, at which point they overlap the vvar area. I've seen this happen. The "solution" in tip is to move the section headers into a real allocatable area reserved for that purpose. The error you're seeing is that I didn't allocate enough space for all the allocatable section headers. This crap almost makes me want to go back to something closer to Stefani's implementation of sticking vvar before the vdso so we can safely leave non-allocatable crap dangling off the end of the vdso. I don't really want to play section header whack-a-mole. We could also just give up on space efficiency and allocate space for several extra section headers (and their associated names!). --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
