From: Igor Stoppa <igor.stoppa@gmail.com> To: willy@infradead.org, keescook@chromium.org, mhocko@kernel.org, corbet@lwn.net Cc: david@fromorbit.com, rppt@linux.vnet.ibm.com, labbott@redhat.com, linux-security-module@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, Igor Stoppa <igor.stoppa@huawei.com> Subject: [PATCH 2/6] vmalloc: rename llist field in vmap_area Date: Fri, 13 Apr 2018 17:41:27 +0400 [thread overview] Message-ID: <20180413134131.4651-3-igor.stoppa@huawei.com> (raw) In-Reply-To: <20180413134131.4651-1-igor.stoppa@huawei.com> The vmap_area structure has a field of type struct llist_node, named purge_list and is used when performing lazy purge of the area. Such field is left unused during the actual utilization of the structure. This patch renames the field to a more generic "area_list", to allow for utilization outside of the purging phase. Since the purging happens after the vmap_area is dismissed, its use is mutually exclusive with any use performed while the area is allocated. Signed-off-by: Igor Stoppa <igor.stoppa@huawei.com> --- include/linux/vmalloc.h | 2 +- mm/vmalloc.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index 1e5d8c392f15..2d07dfef3cfd 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -47,7 +47,7 @@ struct vmap_area { unsigned long flags; struct rb_node rb_node; /* address sorted rbtree */ struct list_head list; /* address sorted list */ - struct llist_node purge_list; /* "lazy purge" list */ + struct llist_node area_list; /* generic list of areas */ struct vm_struct *vm; struct rcu_head rcu_head; }; diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 61a1ca22b0f6..1bb2233bb262 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -682,7 +682,7 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end) lockdep_assert_held(&vmap_purge_lock); valist = llist_del_all(&vmap_purge_list); - llist_for_each_entry(va, valist, purge_list) { + llist_for_each_entry(va, valist, area_list) { if (va->va_start < start) start = va->va_start; if (va->va_end > end) @@ -696,7 +696,7 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end) flush_tlb_kernel_range(start, end); spin_lock(&vmap_area_lock); - llist_for_each_entry_safe(va, n_va, valist, purge_list) { + llist_for_each_entry_safe(va, n_va, valist, area_list) { int nr = (va->va_end - va->va_start) >> PAGE_SHIFT; __free_vmap_area(va); @@ -743,7 +743,7 @@ static void free_vmap_area_noflush(struct vmap_area *va) &vmap_lazy_nr); /* After this point, we may free va at any time */ - llist_add(&va->purge_list, &vmap_purge_list); + llist_add(&va->area_list, &vmap_purge_list); if (unlikely(nr_lazy > lazy_max_pages())) try_purge_vmap_area_lazy(); -- 2.14.1
WARNING: multiple messages have this Message-ID (diff)
From: igor.stoppa@gmail.com (Igor Stoppa) To: linux-security-module@vger.kernel.org Subject: [PATCH 2/6] vmalloc: rename llist field in vmap_area Date: Fri, 13 Apr 2018 17:41:27 +0400 [thread overview] Message-ID: <20180413134131.4651-3-igor.stoppa@huawei.com> (raw) In-Reply-To: <20180413134131.4651-1-igor.stoppa@huawei.com> The vmap_area structure has a field of type struct llist_node, named purge_list and is used when performing lazy purge of the area. Such field is left unused during the actual utilization of the structure. This patch renames the field to a more generic "area_list", to allow for utilization outside of the purging phase. Since the purging happens after the vmap_area is dismissed, its use is mutually exclusive with any use performed while the area is allocated. Signed-off-by: Igor Stoppa <igor.stoppa@huawei.com> --- include/linux/vmalloc.h | 2 +- mm/vmalloc.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index 1e5d8c392f15..2d07dfef3cfd 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -47,7 +47,7 @@ struct vmap_area { unsigned long flags; struct rb_node rb_node; /* address sorted rbtree */ struct list_head list; /* address sorted list */ - struct llist_node purge_list; /* "lazy purge" list */ + struct llist_node area_list; /* generic list of areas */ struct vm_struct *vm; struct rcu_head rcu_head; }; diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 61a1ca22b0f6..1bb2233bb262 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -682,7 +682,7 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end) lockdep_assert_held(&vmap_purge_lock); valist = llist_del_all(&vmap_purge_list); - llist_for_each_entry(va, valist, purge_list) { + llist_for_each_entry(va, valist, area_list) { if (va->va_start < start) start = va->va_start; if (va->va_end > end) @@ -696,7 +696,7 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end) flush_tlb_kernel_range(start, end); spin_lock(&vmap_area_lock); - llist_for_each_entry_safe(va, n_va, valist, purge_list) { + llist_for_each_entry_safe(va, n_va, valist, area_list) { int nr = (va->va_end - va->va_start) >> PAGE_SHIFT; __free_vmap_area(va); @@ -743,7 +743,7 @@ static void free_vmap_area_noflush(struct vmap_area *va) &vmap_lazy_nr); /* After this point, we may free va at any time */ - llist_add(&va->purge_list, &vmap_purge_list); + llist_add(&va->area_list, &vmap_purge_list); if (unlikely(nr_lazy > lazy_max_pages())) try_purge_vmap_area_lazy(); -- 2.14.1 -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-04-13 13:41 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-13 13:41 [RFC PATCH v22 0/6] mm: security: ro protection for dynamic data Igor Stoppa 2018-04-13 13:41 ` Igor Stoppa 2018-04-13 13:41 ` [PATCH 1/6] struct page: add field for vm_struct Igor Stoppa 2018-04-13 13:41 ` Igor Stoppa 2018-04-13 13:41 ` Igor Stoppa [this message] 2018-04-13 13:41 ` [PATCH 2/6] vmalloc: rename llist field in vmap_area Igor Stoppa 2018-04-13 13:41 ` [PATCH 3/6] Protectable Memory Igor Stoppa 2018-04-13 13:41 ` Igor Stoppa 2018-04-13 13:41 ` [PATCH 4/6] Documentation for Pmalloc Igor Stoppa 2018-04-13 13:41 ` Igor Stoppa 2018-04-13 13:41 ` [PATCH 5/6] Pmalloc selftest Igor Stoppa 2018-04-13 13:41 ` Igor Stoppa 2018-04-13 13:41 ` [PATCH 6/6] lkdtm: crash on overwriting protected pmalloc var Igor Stoppa 2018-04-13 13:41 ` Igor Stoppa -- strict thread matches above, loose matches on Subject: below -- 2018-03-27 15:37 [RFC PATCH v21 0/6] mm: security: ro protection for dynamic data Igor Stoppa 2018-03-27 15:37 ` [PATCH 2/6] vmalloc: rename llist field in vmap_area Igor Stoppa 2018-03-27 15:37 ` Igor Stoppa 2018-03-27 15:37 ` Igor Stoppa 2018-03-27 1:55 [RFC PATCH v20 0/6] mm: security: ro protection for dynamic data Igor Stoppa 2018-03-27 1:55 ` [PATCH 2/6] vmalloc: rename llist field in vmap_area Igor Stoppa 2018-03-27 1:55 ` Igor Stoppa 2018-03-27 1:55 ` Igor Stoppa
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180413134131.4651-3-igor.stoppa@huawei.com \ --to=igor.stoppa@gmail.com \ --cc=corbet@lwn.net \ --cc=david@fromorbit.com \ --cc=igor.stoppa@huawei.com \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=labbott@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-security-module@vger.kernel.org \ --cc=mhocko@kernel.org \ --cc=rppt@linux.vnet.ibm.com \ --cc=willy@infradead.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.