[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170525053935.GA12721@dhcp22.suse.cz>
Date: Thu, 25 May 2017 07:39:35 +0200
From: Michal Hocko <mhocko@...nel.org>
To: Wei Yang <richard.weiyang@...il.com>
Cc: akpm@...ux-foundation.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm/vmalloc: a slight change of compare target in
__insert_vmap_area()
On Wed 24-05-17 23:07:30, Wei Yang wrote:
> On Wed, May 24, 2017 at 02:11:35PM +0200, Michal Hocko wrote:
> >On Wed 24-05-17 18:03:47, Wei Yang wrote:
> >> The vmap RB tree store the elements in order and no overlap between any of
> >> them. The comparison in __insert_vmap_area() is to decide which direction
> >> the search should follow and make sure the new vmap_area is not overlap
> >> with any other.
> >>
> >> Current implementation fails to do the overlap check.
> >>
> >> When first "if" is not true, it means
> >>
> >> va->va_start >= tmp_va->va_end
> >>
> >> And with the truth
> >>
> >> xxx->va_end > xxx->va_start
> >>
> >> The deduction is
> >>
> >> va->va_end > tmp_va->va_start
> >>
> >> which is the condition in second "if".
> >>
> >> This patch changes a little of the comparison in __insert_vmap_area() to
> >> make sure it forbids the overlapped vmap_area.
> >
> >Why do we care about overlapping vmap areas at this level. This is an
> >internal function and all the sanity checks should have been done by
> >that time AFAIR. Could you describe the problem which you are trying to
> >fix/address?
> >
>
> No problem it tries to fix.
I would prefer the not touch the code if there is no problem to fix.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists