Bug 312011 - x86_64 VDSO has grown 4KB -> 8KB
x86_64 VDSO has grown 4KB -> 8KB
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
Blocks: 765875 832407 959013
  Show dependency treegraph
Reported: 2007-09-28 19:52 EDT by Jan Kratochvil
Modified: 2013-05-02 21:30 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 765875 832407 959013 (view as bug list)
Last Closed: 2008-04-27 00:28:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Simple testcase (but check rather /proc/self/maps). (8.05 KB, text/plain)
2007-09-28 19:52 EDT, Jan Kratochvil
no flags Details

  None (edit)
Description Jan Kratochvil 2007-09-28 19:52:42 EDT
Description of problem:
on recent x86_64 kernels the kernel VDSO has grown from 4KB to 8KB and GDB
(<gdb-6.6-29.fc8) started to print:
  warning: no loadable sections found in added symbol-file system-supplied DSO
at 0x7fff00f68000
According to Roland McGrath it should be rather kept backward compatible in the
kernel itself.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. cat /proc/self/maps | grep vdso

Actual results:
7ffff43fd000-7ffff43ff000 r-xp 7ffff43fd000 00:00 0                      [vdso]

Expected results:
on upstream kernels (such as linux-2.6.22-rc4-git7.x86_64) it is:
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vdso]

Additional info:
binutils mail thread with Roland McGrath:
Fortunately it has no real functionality defect as AFAIK the VDSO decoding is
not needed on x86_64.
Comment 1 Jan Kratochvil 2007-09-28 19:52:42 EDT
Created attachment 211151 [details]
Simple testcase (but check rather /proc/self/maps).
Comment 2 Roland McGrath 2007-09-28 22:08:11 EDT
It's true that there is no good reason for today's vDSO to be as big as 4kb, and
I have sent patches upstream that make it smaller.  We could use those in
rawhide, and it may be wise since before build-id it so happened that the vDSO
image usually crept in just under 4kb and now is just over it in F8 kernels when
probably noone has before seen a multiple page x86_64 vDSO.  But, note that
there is nothing unkosher about the current vDSO image and it certainly is
likely that even the optimal vDSO layout will grow to more than 4kb in the
future.  Also, powerpc vDSOs are already more than one page and userland should
be coping with all vDSOs with robust generic code.
Comment 3 Dave Jones 2007-10-11 02:10:43 EDT
so the real answer here is "fix gdb to cope with a larger vdso" ?
Comment 4 Roland McGrath 2007-10-11 02:22:33 EDT
gdb should be fixed for the general case, certainly.
However, it's undesireable to have more than one page unless really necessary.
I have patches to change the layout that make it get smaller again, which are
likely to be taken upstream before 2.6.24.  Using such a patch in Fedora now
would be very easy on the kernel side, and take the pressure off fixing gdb if
that is in a crunch (I don't know that it is).
Comment 5 Jan Kratochvil 2007-10-11 11:16:56 EDT
(In reply to comment #3)
> so the real answer here is "fix gdb to cope with a larger vdso" ?

FYI it is currently not a direct problem for Fedora as it is workarounded in GDB
(GDB now reads from the SHDRs in the second page; the other patch floating
around would parse PHDRs) in gdb-6.6-29.fc8:
* Mon Sep 24 2007 Jan Kratochvil <jan.kratochvil@redhat.com> - 6.6-29
- Fixed the kernel VDSO loading (`warning: no loadable sections found in ...').
Comment 6 Dave Jones 2007-10-12 19:40:59 EDT
Ok, so this is a non-issue for F8 by the sounds of things. (Unless something
other than gdb cares about the larger vdso).

With less than a week before the final freeze for F8, I'm hesitant to include
stuff in the kernel which isn't absolutely critical.  By the sounds of things,
it'll shrink again in F9 anyway, making this all moot.
Comment 7 Kyle McMartin 2008-01-07 13:31:57 EST
commit c65916fe3586521932fbd1b734f39744657f2f0d
Author: Roland McGrath <roland@redhat.com>
Date:   Wed Oct 17 18:04:41 2007 +0200

    x86: vdso linker script cleanup

seems to have fixed this upstream in rawhide. Closing bug as resolved.
Comment 8 Jan Kratochvil 2008-04-27 17:49:36 EDT
On kernel-2.6.25-1.fc9.x86_64:

The VDSO data are already fully self-contained in the first 4KB..
But still the mapped range is 8KB:
7fff4ddfd000-7fff4ddff000 r-xp 7fff4ddfd000 00:00 0                      [vdso]

The second page contains some garbage.

/* vdso blob that is mapped into user space */
  vdso_start = . ;
  .vdso  : AT(ADDR(.vdso) - LOAD_OFFSET) { *(.vdso) }
  vdso_end = .;

static int __init init_vdso_vars(void)
        int npages = (vdso_end - vdso_start + PAGE_SIZE - 1) / PAGE_SIZE;

(I do not understand from the code why there are 8KB, it should be 4KB.)
Comment 9 Roland McGrath 2008-04-27 21:51:15 EDT
More lingering stupidity upstream, I sent another patch to clean out the cruft.

The posting has not hit the archive yet, but you can see it RSN at the top of

It should apply trivially to F-9 and/or rawhide 2.6.25 kernels if we care.

Note You need to log in before you can comment on or make changes to this bug.