| Message ID | 20180313214554.28521-5-igor.stoppa@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Mar 13, 2018 at 11:45:50PM +0200, Igor Stoppa wrote: > When a page is used for virtual memory, it is often necessary to obtain > a handler to the corresponding vm_struct, which refers to the virtually > continuous area generated when invoking vmalloc. > > The struct page has a "mapping" field, which can be re-used, to store a > pointer to the parent area. > > This will avoid more expensive searches, later on. > > Signed-off-by: Igor Stoppa <igor.stoppa@huawei.com> Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com> Regardless of the fate of the rest of this patchset, this makes sense and we should have this. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 3/13/18 3:00 PM, Matthew Wilcox wrote: > On Tue, Mar 13, 2018 at 11:45:50PM +0200, Igor Stoppa wrote: >> When a page is used for virtual memory, it is often necessary to obtain >> a handler to the corresponding vm_struct, which refers to the virtually >> continuous area generated when invoking vmalloc. >> >> The struct page has a "mapping" field, which can be re-used, to store a >> pointer to the parent area. >> >> This will avoid more expensive searches, later on. >> >> Signed-off-by: Igor Stoppa <igor.stoppa@huawei.com> > Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com> Igor, do you mind sticking these tags on the files that have spent some time reviewing a revision of your patchset (like the Reviewed-by: tags I provided last revision?) Thanks, Jay -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 14/03/18 19:43, J Freyensee wrote: > On 3/13/18 3:00 PM, Matthew Wilcox wrote: [...] >>> Signed-off-by: Igor Stoppa <igor.stoppa@huawei.com> >> Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com> > > Igor, do you mind sticking these tags on the files that have spent some > time reviewing a revision of your patchset (like the Reviewed-by: tags I > provided last revision?) Apologies, that was not intentional, I forgot it. I will do it, although most of the files will now change so much that I am not sure what will survive, beside this patch, in the form that you reviewed. I suppose the Review-by tag drops, if the patch changes. -- igor -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 3/15/18 2:38 AM, Igor Stoppa wrote: > On 14/03/18 19:43, J Freyensee wrote: >> On 3/13/18 3:00 PM, Matthew Wilcox wrote: > [...] > >>>> Signed-off-by: Igor Stoppa <igor.stoppa@huawei.com> >>> Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com> >> Igor, do you mind sticking these tags on the files that have spent some >> time reviewing a revision of your patchset (like the Reviewed-by: tags I >> provided last revision?) > Apologies, that was not intentional, I forgot it. > I will do it, although most of the files will now change so much that I > am not sure what will survive, beside this patch, in the form that you > reviewed. > > I suppose the Review-by tag drops, if the patch changes. That's true, if so much of the patch changes it basically looks like something different, the Reviewed-by: would drop. Jay > > -- > igor -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h index fd1af6b9591d..c3a4825e10c0 100644 --- a/include/linux/mm_types.h +++ b/include/linux/mm_types.h @@ -84,6 +84,7 @@ struct page { void *s_mem; /* slab first object */ atomic_t compound_mapcount; /* first tail page */ /* page_deferred_list().next -- second tail page */ + struct vm_struct *area; }; /* Second double word */ diff --git a/mm/vmalloc.c b/mm/vmalloc.c index ebff729cc956..61a1ca22b0f6 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -1536,6 +1536,7 @@ static void __vunmap(const void *addr, int deallocate_pages) struct page *page = area->pages[i]; BUG_ON(!page); + page->area = NULL; __free_pages(page, 0); } @@ -1705,6 +1706,7 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask, area->nr_pages = i; goto fail; } + page->area = area; area->pages[i] = page; if (gfpflags_allow_blocking(gfp_mask|highmem_mask)) cond_resched();
When a page is used for virtual memory, it is often necessary to obtain a handler to the corresponding vm_struct, which refers to the virtually continuous area generated when invoking vmalloc. The struct page has a "mapping" field, which can be re-used, to store a pointer to the parent area. This will avoid more expensive searches, later on. Signed-off-by: Igor Stoppa <igor.stoppa@huawei.com> --- include/linux/mm_types.h | 1 + mm/vmalloc.c | 2 ++ 2 files changed, 3 insertions(+)