[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7cc6a46c50c2008bfb968c5e48af5a49@suse.de>
Date: Thu, 13 Jun 2019 11:33:02 +0200
From: Roman Penyaev <rpenyaev@...e.de>
To: Anshuman Khandual <anshuman.khandual@....com>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Rick Edgecombe <rick.p.edgecombe@...el.com>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Mike Rapoport <rppt@...ux.ibm.com>,
Roman Gushchin <guro@...com>, Michal Hocko <mhocko@...e.com>,
"Uladzislau Rezki (Sony)" <urezki@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] mm/vmalloc: Check absolute error return from
vmap_[p4d|pud|pmd|pte]_range()
On 2019-06-13 10:12, Anshuman Khandual wrote:
> vmap_pte_range() returns an -EBUSY when it encounters a non-empty PTE.
> But
> currently vmap_pmd_range() unifies both -EBUSY and -ENOMEM return code
> as
> -ENOMEM and send it up the call chain which is wrong. Interestingly
> enough
> vmap_page_range_noflush() tests for the absolute error return value
> from
> vmap_p4d_range() but it does not help because -EBUSY has been merged
> with
> -ENOMEM. So all it can return is -ENOMEM. Fix this by testing for
> absolute
> error return from vmap_pmd_range() all the way up to vmap_p4d_range().
I could not find any real external caller of vmap API who really cares
about the errno, and frankly why they should? This is allocation path,
allocation failed - game over. When you step on -EBUSY case something
has gone completely wrong in your kernel, you get a big warning in
your dmesg and it is already does not matter what errno you get.
--
Roman
Powered by blists - more mailing lists