lisa/android_kernel_xiaomi_sm8350
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
ec155afa82
android_kernel_xiaomi_sm8350/arch/x86/vdso/vdso.S

23 lines
444 B
ArmAsm
Raw Normal View History

x86-64, vdso: Do not allocate memory for the vDSO We can map the vDSO straight from kernel data, saving a few page allocations. As an added bonus, the deleted code contained a memory leak. Signed-off-by: Andy Lutomirski <luto@mit.edu> Link: http://lkml.kernel.org/r/2c4ed5c2c2e93603790229e0c3403ae506ccc0cb.1311277573.git.luto@mit.edu Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2011-07-21 15:47:10 -04:00
#include <asm/page_types.h>
#include <linux/linkage.h>
x86_64 vDSO: use initdata The 64-bit vDSO image is in a special ".vdso" section for no reason I can determine. Furthermore, the location of the vdso_end symbol includes some wrongly-calculated padding space in the image, which is then (correctly) rounded to page size, resulting in an extra page of zeros in the image mapped in to user processes. This changes it to put the vdso.so image into normal initdata as we have always done for the 32-bit vDSO images. The extra padding is gone, so the user VMA is one page instead of two. The image that was already copied around at boot time is now in initdata, so we recover that wasted space after boot. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-27 21:45:38 -04:00
#include <linux/init.h>
x86-64, vdso: Do not allocate memory for the vDSO We can map the vDSO straight from kernel data, saving a few page allocations. As an added bonus, the deleted code contained a memory leak. Signed-off-by: Andy Lutomirski <luto@mit.edu> Link: http://lkml.kernel.org/r/2c4ed5c2c2e93603790229e0c3403ae506ccc0cb.1311277573.git.luto@mit.edu Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2011-07-21 15:47:10 -04:00
__PAGE_ALIGNED_DATA
x86_64 vDSO: use initdata The 64-bit vDSO image is in a special ".vdso" section for no reason I can determine. Furthermore, the location of the vdso_end symbol includes some wrongly-calculated padding space in the image, which is then (correctly) rounded to page size, resulting in an extra page of zeros in the image mapped in to user processes. This changes it to put the vdso.so image into normal initdata as we have always done for the 32-bit vDSO images. The extra padding is gone, so the user VMA is one page instead of two. The image that was already copied around at boot time is now in initdata, so we recover that wasted space after boot. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-27 21:45:38 -04:00
.globl vdso_start, vdso_end
x86-64, vdso: Do not allocate memory for the vDSO We can map the vDSO straight from kernel data, saving a few page allocations. As an added bonus, the deleted code contained a memory leak. Signed-off-by: Andy Lutomirski <luto@mit.edu> Link: http://lkml.kernel.org/r/2c4ed5c2c2e93603790229e0c3403ae506ccc0cb.1311277573.git.luto@mit.edu Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2011-07-21 15:47:10 -04:00
.align PAGE_SIZE
x86_64 vDSO: use initdata The 64-bit vDSO image is in a special ".vdso" section for no reason I can determine. Furthermore, the location of the vdso_end symbol includes some wrongly-calculated padding space in the image, which is then (correctly) rounded to page size, resulting in an extra page of zeros in the image mapped in to user processes. This changes it to put the vdso.so image into normal initdata as we have always done for the 32-bit vDSO images. The extra padding is gone, so the user VMA is one page instead of two. The image that was already copied around at boot time is now in initdata, so we recover that wasted space after boot. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-27 21:45:38 -04:00
vdso_start:
x86_64: move vdso Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2007-10-11 05:17:10 -04:00
.incbin "arch/x86/vdso/vdso.so"
x86_64 vDSO: use initdata The 64-bit vDSO image is in a special ".vdso" section for no reason I can determine. Furthermore, the location of the vdso_end symbol includes some wrongly-calculated padding space in the image, which is then (correctly) rounded to page size, resulting in an extra page of zeros in the image mapped in to user processes. This changes it to put the vdso.so image into normal initdata as we have always done for the 32-bit vDSO images. The extra padding is gone, so the user VMA is one page instead of two. The image that was already copied around at boot time is now in initdata, so we recover that wasted space after boot. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-27 21:45:38 -04:00
vdso_end:
x86-64: Pad vDSO to a page boundary This avoids an information leak to userspace. Signed-off-by: Andy Lutomirski <luto@mit.edu> Link: http://lkml.kernel.org/r/a63380a3c58a0506a2f5a18ba1b12dbde1f25e58.1312378163.git.luto@mit.edu Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-08-03 09:31:49 -04:00
.align PAGE_SIZE /* extra data here leaks to userspace. */
x86_64 vDSO: use initdata The 64-bit vDSO image is in a special ".vdso" section for no reason I can determine. Furthermore, the location of the vdso_end symbol includes some wrongly-calculated padding space in the image, which is then (correctly) rounded to page size, resulting in an extra page of zeros in the image mapped in to user processes. This changes it to put the vdso.so image into normal initdata as we have always done for the 32-bit vDSO images. The extra padding is gone, so the user VMA is one page instead of two. The image that was already copied around at boot time is now in initdata, so we recover that wasted space after boot. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-27 21:45:38 -04:00
x86-64, vdso: Do not allocate memory for the vDSO We can map the vDSO straight from kernel data, saving a few page allocations. As an added bonus, the deleted code contained a memory leak. Signed-off-by: Andy Lutomirski <luto@mit.edu> Link: http://lkml.kernel.org/r/2c4ed5c2c2e93603790229e0c3403ae506ccc0cb.1311277573.git.luto@mit.edu Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2011-07-21 15:47:10 -04:00
.previous
.globl vdso_pages
.bss
.align 8
.type vdso_pages, @object
vdso_pages:
.zero (vdso_end - vdso_start + PAGE_SIZE - 1) / PAGE_SIZE * 8
.size vdso_pages, .-vdso_pages
Reference in New Issue Copy Permalink