From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-f196.google.com ([209.85.210.196]:46704 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731722AbeLUKfg (ORCPT ); Fri, 21 Dec 2018 05:35:36 -0500 Received: by mail-pf1-f196.google.com with SMTP id c73so2408479pfe.13 for ; Fri, 21 Dec 2018 02:35:36 -0800 (PST) Date: Fri, 21 Dec 2018 13:35:30 +0300 From: "Kirill A. Shutemov" To: Richard Weinberger Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, hsiangkao@mail.ru, kirill.shutemov@linux.intel.com, stable@vger.kernel.org, zhangjun Subject: Re: [PATCH] ubifs: Get/put page when changing PG_private Message-ID: <20181221103530.zahcs4gm5mlknhug@kshutemo-mobl1> References: <20181215150130.19381-1-richard@nod.at> <386368225.TvJUPtmGVW@blindfold> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <386368225.TvJUPtmGVW@blindfold> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Dec 21, 2018 at 09:56:25AM +0100, Richard Weinberger wrote: > Am Samstag, 15. Dezember 2018, 16:01:30 CET schrieb Richard Weinberger: > > The page migration code assumes that a page with PG_private > > set has its page count elevated by 1. > > UBIFS never did this and therefore the migration code was unable > > to migrate some pages owned by UBIFS. > > The lead to situations where the CMA memory allocator failed to > > allocate memory. > > > > Fix this by using get/put_page when changing PG_private. > > > > Cc: > > Cc: zhangjun > > Fixes: 4ac1c17b2044 ("UBIFS: Implement ->migratepage()") > > Reported-by: zhangjun > > Signed-off-by: Richard Weinberger > > FYI, on the XFS side a similar change caused a regression. > https://marc.info/?l=linux-fsdevel&m=154530861202448&w=2 > > Until this regression is not fully understood, including the implications > for UBIFS, I'll not merge this patch. This looks like a reasonable resolution to me: http://lkml.kernel.org/r/20181221093919.GA2337@lst.de But let's wait the inclusion (or objection). -- Kirill A. Shutemov