[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20230412133331.e26920856ccf94edd057c1e0@linux-foundation.org>
Date: Wed, 12 Apr 2023 13:33:31 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Alexander Potapenko <glider@...gle.com>
Cc: urezki@...il.com, hch@...radead.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, elver@...gle.com, dvyukov@...gle.com,
kasan-dev@...glegroups.com,
Dipanjan Das <mail.dipanjan.das@...il.com>
Subject: Re: [PATCH 2/2] mm: kmsan: handle alloc failures in
kmsan_ioremap_page_range()
On Wed, 12 Apr 2023 16:53:00 +0200 Alexander Potapenko <glider@...gle.com> wrote:
> Similarly to kmsan_vmap_pages_range_noflush(),
> kmsan_ioremap_page_range() must also properly handle allocation/mapping
> failures. In the case of such, it must clean up the already created
> metadata mappings and return an error code, so that the failure can be
> propagated to ioremap_page_range().
Unlike [1/2], this changelog doesn't describe the user-visible effects.
A bit of clicking takes me to
: kmsan's allocation of shadow or origin memory in
: kmsan_vmap_pages_range_noflush() fails silently due to fault injection
: (FI). KMSAN sort of "swallows" the allocation failure, and moves on.
: When either of them is later accessed while updating the metadata,
: there are no checks to test the validity of the respective pointers,
: which results in a page fault.
So I'll add that to the changelog and shall add cc:stable to both patches.
Powered by blists - more mailing lists