Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 6 Nov 2020 14:48:11 -0800
From:   Andrew Morton <akpm@linux-foundation.org>
To:     =?ISO-8859-1?Q? "Christian_K=F6nig" ?= 
        <ckoenig.leichtzumerken@gmail.com>
Cc:     linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        linaro-mm-sig@lists.linaro.org, dri-devel@lists.freedesktop.org,
        linux-media@vger.kernel.org
Subject: Re: [PATCH 1/2] mm: mmap: fix fput in error path v2
Message-Id: <20201106144811.cf228ca9278ec78887d42960@linux-foundation.org>
In-Reply-To: <20201106114806.46015-2-christian.koenig@amd.com>
References: <20201106114806.46015-1-christian.koenig@amd.com>
        <20201106114806.46015-2-christian.koenig@amd.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri,  6 Nov 2020 12:48:05 +0100 "Christian K=F6nig" <ckoenig.leichtzumer=
ken@gmail.com> wrote:

> Patch "495c10cc1c0c CHROMIUM: dma-buf: restore args..."
> adds a workaround for a bug in mmap_region.
>=20
> As the comment states ->mmap() callback can change
> vma->vm_file and so we might call fput() on the wrong file.
>=20
> Revert the workaround and proper fix this in mmap_region.
>=20

Seems correct, best I can tell.  Presumably all ->mmap() instances will
correctly fput() to original file* if they're rewriting vma->vm_file.