lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ