Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 12 Apr 2023 13:33:31 -0700
From:   Andrew Morton <akpm@linux-foundation.org>
To:     Alexander Potapenko <glider@google.com>
Cc:     urezki@gmail.com, hch@infradead.org, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org, elver@google.com, dvyukov@google.com,
        kasan-dev@googlegroups.com,
        Dipanjan Das <mail.dipanjan.das@gmail.com>
Subject: Re: [PATCH 2/2] mm: kmsan: handle alloc failures in
 kmsan_ioremap_page_range()
Message-Id: <20230412133331.e26920856ccf94edd057c1e0@linux-foundation.org>
In-Reply-To: <20230412145300.3651840-2-glider@google.com>
References: <20230412145300.3651840-1-glider@google.com>
        <20230412145300.3651840-2-glider@google.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 12 Apr 2023 16:53:00 +0200 Alexander Potapenko <glider@google.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.