Message ID | 20230328095807.7014-3-songmuchun@bytedance.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | Simplify kfence code | expand |
On Tue, 28 Mar 2023 at 11:58, 'Muchun Song' via kasan-dev <kasan-dev@googlegroups.com> wrote: > > Check kfence pool size at building time to expose problem ASAP. > > Signed-off-by: Muchun Song <songmuchun@bytedance.com> > --- > mm/kfence/core.c | 7 +++---- > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/mm/kfence/core.c b/mm/kfence/core.c > index de62a84d4830..6781af1dfa66 100644 > --- a/mm/kfence/core.c > +++ b/mm/kfence/core.c > @@ -841,10 +841,9 @@ static int kfence_init_late(void) > return -ENOMEM; > __kfence_pool = page_to_virt(pages); > #else > - if (nr_pages > MAX_ORDER_NR_PAGES) { > - pr_warn("KFENCE_NUM_OBJECTS too large for buddy allocator\n"); > - return -EINVAL; > - } > + BUILD_BUG_ON_MSG(get_order(KFENCE_POOL_SIZE) > MAX_ORDER, > + "CONFIG_KFENCE_NUM_OBJECTS is too large for buddy allocator"); > + It's perfectly valid to want to use KFENCE with a very large pool that is initialized on boot, and simply sacrifice the ability to initialize late. Nack.
> On Mar 28, 2023, at 18:14, Marco Elver <elver@google.com> wrote: > > On Tue, 28 Mar 2023 at 11:58, 'Muchun Song' via kasan-dev > <kasan-dev@googlegroups.com> wrote: >> >> Check kfence pool size at building time to expose problem ASAP. >> >> Signed-off-by: Muchun Song <songmuchun@bytedance.com> >> --- >> mm/kfence/core.c | 7 +++---- >> 1 file changed, 3 insertions(+), 4 deletions(-) >> >> diff --git a/mm/kfence/core.c b/mm/kfence/core.c >> index de62a84d4830..6781af1dfa66 100644 >> --- a/mm/kfence/core.c >> +++ b/mm/kfence/core.c >> @@ -841,10 +841,9 @@ static int kfence_init_late(void) >> return -ENOMEM; >> __kfence_pool = page_to_virt(pages); >> #else >> - if (nr_pages > MAX_ORDER_NR_PAGES) { >> - pr_warn("KFENCE_NUM_OBJECTS too large for buddy allocator\n"); >> - return -EINVAL; >> - } >> + BUILD_BUG_ON_MSG(get_order(KFENCE_POOL_SIZE) > MAX_ORDER, >> + "CONFIG_KFENCE_NUM_OBJECTS is too large for buddy allocator"); >> + > > It's perfectly valid to want to use KFENCE with a very large pool that > is initialized on boot, and simply sacrifice the ability to initialize > late. You are right. I didn’t realize this. Thanks > > Nack.
diff --git a/mm/kfence/core.c b/mm/kfence/core.c index de62a84d4830..6781af1dfa66 100644 --- a/mm/kfence/core.c +++ b/mm/kfence/core.c @@ -841,10 +841,9 @@ static int kfence_init_late(void) return -ENOMEM; __kfence_pool = page_to_virt(pages); #else - if (nr_pages > MAX_ORDER_NR_PAGES) { - pr_warn("KFENCE_NUM_OBJECTS too large for buddy allocator\n"); - return -EINVAL; - } + BUILD_BUG_ON_MSG(get_order(KFENCE_POOL_SIZE) > MAX_ORDER, + "CONFIG_KFENCE_NUM_OBJECTS is too large for buddy allocator"); + __kfence_pool = alloc_pages_exact(KFENCE_POOL_SIZE, GFP_KERNEL); if (!__kfence_pool) return -ENOMEM;
Check kfence pool size at building time to expose problem ASAP. Signed-off-by: Muchun Song <songmuchun@bytedance.com> --- mm/kfence/core.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)