diff mbox series

[RFC] mm/vmalloc: make sure to traverse from the beginning when overflow occur

Message ID 20200412143803.43931-1-fishland@aliyun.com (mailing list archive)
State New, archived
Headers show
Series [RFC] mm/vmalloc: make sure to traverse from the beginning when overflow occur | expand

Commit Message

Liu Song April 12, 2020, 2:38 p.m. UTC
From: Liu Song <liu.song11@zte.com.cn>

If overflow, should ensure that "free_vmap_cache" is set to NULL,
so as to ensure that it can be traversed from the beginning.

Signed-off-by: Liu Song <liu.song11@zte.com.cn>
---
 mm/vmalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Dave Hansen April 13, 2020, 3:02 p.m. UTC | #1
On 4/12/20 7:38 AM, Liu Song wrote:
> If overflow, should ensure that "free_vmap_cache" is set to NULL,
> so as to ensure that it can be traversed from the beginning.

This changelog is a bit sparse.

Does this fix a demonstrated problem?  Or was it just discovered via
code review and assumed to help a theoretical problem?

Which tree is it against?  'free_vmap_cache' doesn't show up in Linus's
tree.
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index d8e877365f9f..2638a20d36ce 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -441,7 +441,7 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
>  	if (!free_vmap_cache ||
>  			size < cached_hole_size ||
>  			vstart < cached_vstart ||
> -			align < cached_align) {
> +			align < cached_align || purged) {
>  nocache:
>  		cached_hole_size = 0;
>  		free_vmap_cache = NULL;

Is 'purged' the right way to do this?

There is a path through the overflow code that also sets purged=0.  Does
'free_vmap_cache' *not* need to get reset in that case?

It also seems more natural to me that the code mucking with the rbtree
would be the one to reset the cache.
Liu Song April 14, 2020, 2:54 p.m. UTC | #2
>On 4/12/20 7:38 AM, Liu Song wrote:
>> If overflow, should ensure that "free_vmap_cache" is set to NULL,
>> so as to ensure that it can be traversed from the beginning.
>
>This changelog is a bit sparse.
>
>Does this fix a demonstrated problem?  Or was it just discovered via
>code review and assumed to help a theoretical problem?
>
>Which tree is it against?  'free_vmap_cache' doesn't show up in Linus's
>tree.
>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>> index d8e877365f9f..2638a20d36ce 100644
>> --- a/mm/vmalloc.c
>> +++ b/mm/vmalloc.c
>> @@ -441,7 +441,7 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
>>   if (!free_vmap_cache ||
>>     size < cached_hole_size ||
>>     vstart < cached_vstart ||
>> -   align < cached_align) {
>> +   align < cached_align || purged) {
>>  nocache:
>>    cached_hole_size = 0;
>>    free_vmap_cache = NULL;
>
>Is 'purged' the right way to do this?
>
>There is a path through the overflow code that also sets purged=0.  Does
>'free_vmap_cache' *not* need to get reset in that case?
>
>It also seems more natural to me that the code mucking with the rbtree
>would be the one to reset the cache.

Hi, 
Thanks for your reply, there is indeed a problem with this patch submission.
I neglected the cache clearing process, so I mistakenly thought that the cache
should be cleared after "purged". I will not issue such unconsidered patches
anymore, to avoid unnecessary trouble for everyone. *_^

Thanks
Uladzislau Rezki April 14, 2020, 7:02 p.m. UTC | #3
On Mon, Apr 13, 2020 at 08:02:49AM -0700, Dave Hansen wrote:
> On 4/12/20 7:38 AM, Liu Song wrote:
> > If overflow, should ensure that "free_vmap_cache" is set to NULL,
> > so as to ensure that it can be traversed from the beginning.
> 
> This changelog is a bit sparse.
> 
> Does this fix a demonstrated problem?  Or was it just discovered via
> code review and assumed to help a theoretical problem?
> 
> Which tree is it against?  'free_vmap_cache' doesn't show up in Linus's
> tree.
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index d8e877365f9f..2638a20d36ce 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -441,7 +441,7 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
> >  	if (!free_vmap_cache ||
> >  			size < cached_hole_size ||
> >  			vstart < cached_vstart ||
> > -			align < cached_align) {
> > +			align < cached_align || purged) {
> >  nocache:
> >  		cached_hole_size = 0;
> >  		free_vmap_cache = NULL;
> >
We do not have such code since 5.2 kernel or so, nor things like
cached_hole_size, free_vmap_cache and so on. It was totally reworked.

--
Vlad Rezki
diff mbox series

Patch

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index d8e877365f9f..2638a20d36ce 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -441,7 +441,7 @@  static struct vmap_area *alloc_vmap_area(unsigned long size,
 	if (!free_vmap_cache ||
 			size < cached_hole_size ||
 			vstart < cached_vstart ||
-			align < cached_align) {
+			align < cached_align || purged) {
 nocache:
 		cached_hole_size = 0;
 		free_vmap_cache = NULL;