Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= <mans@mansr.com>
To:     Matthew Wilcox <willy@infradead.org>
Cc:     linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: fix insert_pfn() return value
References: <20181127144351.9137-1-mans@mansr.com>
        <20181127150852.GA10377@bombadil.infradead.org>
Date:   Tue, 27 Nov 2018 15:20:24 +0000
In-Reply-To: <20181127150852.GA10377@bombadil.infradead.org> (Matthew Wilcox's
        message of "Tue, 27 Nov 2018 07:08:52 -0800")
Message-ID: <yw1x8t1elf7r.fsf@mansr.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Matthew Wilcox <willy@infradead.org> writes:

> On Tue, Nov 27, 2018 at 02:43:51PM +0000, Mans Rullgard wrote:
>> Commit 9b5a8e00d479 ("mm: convert insert_pfn() to vm_fault_t") accidentally
>> made insert_pfn() always return an error.  Fix this.
>
> Umm.  VM_FAULT_NOPAGE is not an error.  It's saying "I inserted the PFN,
> there's no struct page for the core VM to do anything with".  Which is
> the correct response from a device driver which has called insert_pfn().
>
> Could you explain a bit more what led you to think there's a problem here?

Apparently some (not in mainline) driver code had been hastily converted
to the vm_fault_t codes, and that is where the error is.  Sorry for the
noise.  Please disregard this.

(The quickest way to get the correct answer is still to send a bad
patch.)

> Also, rather rude of you not to cc the patch author when you claim to
> be fixing a bug in their patch.

Sorry about that.  Blame the get-maintainers script.

-- 
M?ns Rullg?rd