search for: vmalloc_start

Hi Richard, On 11/25/2013 04:50 PM, Richard Yao wrote: > I figured out the problem. There is zerocopy IO is being done via DMA to > a buffer allocated with valloc(). Right now, I am running a hack-fix > locally so I can get some other stuff done first. I will propose a > proper fix to the list in a few days. I've also encountered this issue on a non-QEMU simulator and have been

Hi Richard, On 11/25/2013 04:50 PM, Richard Yao wrote: > I figured out the problem. There is zerocopy IO is being done via DMA to > a buffer allocated with valloc(). Right now, I am running a hack-fix > locally so I can get some other stuff done first. I will propose a > proper fix to the list in a few days. I've also encountered this issue on a non-QEMU simulator and have been

...t; #ifdef CONFIG_UNCACHED_MAPPING @@ -376,11 +373,6 @@ void __init mem_init(void) FIXADDR_START, FIXADDR_TOP, (FIXADDR_TOP - FIXADDR_START) >> 10, -#ifdef CONFIG_HIGHMEM - PKMAP_BASE, PKMAP_BASE+LAST_PKMAP*PAGE_SIZE, - (LAST_PKMAP*PAGE_SIZE) >> 10, -#endif - (unsigned long)VMALLOC_START, VMALLOC_END, (VMALLOC_END - VMALLOC_START) >> 20,

...ers while I take the time to explore a few loose ends. That being said, I would like to investigate a couple of things before I send either this patch or some variant of it to the appropriate subsystem maintainer. First, I need to review the valloc() routines to ensure that range checking against [VMALLOC_START, VMALLOC_END) is the correct way to identify valloc() generated buffers. Second, I want to explore the feasibility of a suggestion by Alexander Graf to instead rework the zero-copy to properly handle valloc() allocated buffers. Yours truly, Richard Yao On 11/26/2013 10:16 AM, Christopher Covingto...

...agetables.c +++ b/arch/x86/mm/dump_pagetables.c @@ -37,6 +37,28 @@ struct addr_marker { const char *name; }; +/* indices for address_markers; keep sync'd w/ address_markers below */ +enum address_markers_idx { + USER_SPACE_NR = 0, +#ifdef CONFIG_X86_64 + KERNEL_SPACE_NR, + LOW_KERNEL_NR, + VMALLOC_START_NR, + VMEMMAP_START_NR, + HIGH_KERNEL_NR, + MODULES_VADDR_NR, + MODULES_END_NR, +#else + KERNEL_SPACE_NR, + VMALLOC_START_NR, + VMALLOC_END_NR, +# ifdef CONFIG_HIGHMEM + PKMAP_BASE_NR, +# endif + FIXADDR_START_NR, +#endif +}; + /* Address space markers hints */ static struct addr_marker address_m...

...er, unsigned long bytes) @@ -157,20 +151,11 @@ static int xencomm_create(void *buffer, unsigned long bytes, return 0; } -/* check if memory address is within VMALLOC region */ -static int is_phys_contiguous(unsigned long addr) -{ - if (!is_kernel_addr(addr)) - return 0; - - return (addr < VMALLOC_START) || (addr >= VMALLOC_END); -} - static struct xencomm_handle *xencomm_create_inline(void *ptr) { unsigned long paddr; - BUG_ON(!is_phys_contiguous((unsigned long)ptr)); + BUG_ON(!xencomm_is_phys_contiguous((unsigned long)ptr)); paddr = (unsigned long)xencomm_pa(ptr); BUG_ON(paddr &am...

...er, unsigned long bytes) @@ -157,20 +151,11 @@ static int xencomm_create(void *buffer, unsigned long bytes, return 0; } -/* check if memory address is within VMALLOC region */ -static int is_phys_contiguous(unsigned long addr) -{ - if (!is_kernel_addr(addr)) - return 0; - - return (addr < VMALLOC_START) || (addr >= VMALLOC_END); -} - static struct xencomm_handle *xencomm_create_inline(void *ptr) { unsigned long paddr; - BUG_ON(!is_phys_contiguous((unsigned long)ptr)); + BUG_ON(!xencomm_is_phys_contiguous((unsigned long)ptr)); paddr = (unsigned long)xencomm_pa(ptr); BUG_ON(paddr &am...

...er, unsigned long bytes) @@ -157,20 +151,11 @@ static int xencomm_create(void *buffer, unsigned long bytes, return 0; } -/* check if memory address is within VMALLOC region */ -static int is_phys_contiguous(unsigned long addr) -{ - if (!is_kernel_addr(addr)) - return 0; - - return (addr < VMALLOC_START) || (addr >= VMALLOC_END); -} - static struct xencomm_handle *xencomm_create_inline(void *ptr) { unsigned long paddr; - BUG_ON(!is_phys_contiguous((unsigned long)ptr)); + BUG_ON(!xencomm_is_phys_contiguous((unsigned long)ptr)); paddr = (unsigned long)xencomm_pa(ptr); BUG_ON(paddr &am...

...er, unsigned long bytes) @@ -157,20 +151,11 @@ static int xencomm_create(void *buffer, unsigned long bytes, return 0; } -/* check if memory address is within VMALLOC region */ -static int is_phys_contiguous(unsigned long addr) -{ - if (!is_kernel_addr(addr)) - return 0; - - return (addr < VMALLOC_START) || (addr >= VMALLOC_END); -} - static struct xencomm_handle *xencomm_create_inline(void *ptr) { unsigned long paddr; - BUG_ON(!is_phys_contiguous((unsigned long)ptr)); + BUG_ON(!xencomm_is_phys_contiguous((unsigned long)ptr)); paddr = (unsigned long)xencomm_pa(ptr); BUG_ON(paddr &am...

Hi Andrew, This series of patches lays the basic ground work for the paravirtualized kernel patches coming later on. I think this lot is ready for the rough-and-tumble world of the -mm tree. The main change from the last posting is that all the page-table related patches have been moved out, and will be posted separately. Also, the off-by-one in reserving the top of address space has been

Hi Andrew, This series of patches lays the basic ground work for the paravirtualized kernel patches coming later on. I think this lot is ready for the rough-and-tumble world of the -mm tree. The main change from the last posting is that all the page-table related patches have been moved out, and will be posted separately. Also, the off-by-one in reserving the top of address space has been

...te_low; } pte_t; #endif /* !__ASSEMBLY__ */ @@ -54,6 +54,7 @@ #define PGDIR_MASK (~(PGDIR_SIZE - 1)) /* See Documentation/x86/x86_64/mm.txt for a description of the memory map. */ +#define MAX_PHYSMEM_BITS 43 #define MAXMEM _AC(__AC(1, UL) << MAX_PHYSMEM_BITS, UL) #define VMALLOC_START _AC(0xffffc90000000000, UL) #define VMALLOC_END _AC(0xffffe8ffffffffff, UL) Luis

...te_low; } pte_t; #endif /* !__ASSEMBLY__ */ @@ -54,6 +54,7 @@ #define PGDIR_MASK (~(PGDIR_SIZE - 1)) /* See Documentation/x86/x86_64/mm.txt for a description of the memory map. */ +#define MAX_PHYSMEM_BITS 43 #define MAXMEM _AC(__AC(1, UL) << MAX_PHYSMEM_BITS, UL) #define VMALLOC_START _AC(0xffffc90000000000, UL) #define VMALLOC_END _AC(0xffffe8ffffffffff, UL) Luis

Andrey, I believe that on Xen we should disable kasan, would like confirmation from someone on xen-devel though. Here's the thing though -- if true -- I'd like to do it *properly*, where *properly* means addressing a bit of architecture. A simple Kconfig slap seems rather reactive. I'd like to address a way to properly ensure we don't run into this and other similar issues in the

Andrey, I believe that on Xen we should disable kasan, would like confirmation from someone on xen-devel though. Here's the thing though -- if true -- I'd like to do it *properly*, where *properly* means addressing a bit of architecture. A simple Kconfig slap seems rather reactive. I'd like to address a way to properly ensure we don't run into this and other similar issues in the

[ REPOST: Apologies to anyone who has seen this before. It didn't make it onto any of the lists it should have. -J ] Hi Andrew, This series of patches lays the basic ground work for the paravirtualized kernel patches coming later on. I think this lot is ready for the rough-and-tumble world of the -mm tree. For the most part, these patches do nothing or very little. The patches should

[ REPOST: Apologies to anyone who has seen this before. It didn't make it onto any of the lists it should have. -J ] Hi Andrew, This series of patches lays the basic ground work for the paravirtualized kernel patches coming later on. I think this lot is ready for the rough-and-tumble world of the -mm tree. For the most part, these patches do nothing or very little. The patches should

Hi Jeremy. According to your suggestion, I recreated patches for Ingo's x86.git tree. And this patch series includes Eddie's modification. Please review and forward them. (or push back to respin.) Recently the xen-ia64 community started to make efforts to merge xen/ia64 Linux to upstream. The first step is to merge up domU portion. This patchset is preliminary for xen/ia64 domU linux

Hi Jeremy. According to your suggestion, I recreated patches for Ingo's x86.git tree. And this patch series includes Eddie's modification. Please review and forward them. (or push back to respin.) Recently the xen-ia64 community started to make efforts to merge xen/ia64 Linux to upstream. The first step is to merge up domU portion. This patchset is preliminary for xen/ia64 domU linux

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce