[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210501211940.GA11658@lespinasse.org>
Date: Sat, 1 May 2021 14:19:40 -0700
From: Michel Lespinasse <michel@...pinasse.org>
To: Theodore Ts'o <tytso@....edu>
Cc: Michel Lespinasse <michel@...pinasse.org>,
Linux-MM <linux-mm@...ck.org>,
Linux-Kernel <linux-kernel@...r.kernel.org>,
Laurent Dufour <ldufour@...ux.ibm.com>,
Peter Zijlstra <peterz@...radead.org>,
Michal Hocko <mhocko@...e.com>,
Matthew Wilcox <willy@...radead.org>,
Rik van Riel <riel@...riel.com>,
Paul McKenney <paulmck@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Suren Baghdasaryan <surenb@...gle.com>,
Joel Fernandes <joelaf@...gle.com>,
Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH 00/29] Speculative page faults (anon vmas only)
Hi Ted,
On Sat, May 01, 2021 at 03:56:23PM -0400, Theodore Ts'o wrote:
> I tried running xfstests against the spf branch, and I've noticed it's
> causing regression for generic/619. It's failing due to a umount
> failure due to a busy mount point:
>
> QA output created by 619
> umount: /vdc: target is busy.
>
> I haven't had a chance to investigate, but I thought I should let you know.
Thanks for the report. I think the issue is likely caused by commit
06adfeb8150d "mm: rcu safe vma->vm_file freeing", which will defer
fput on mapped files for one rcu grace period. I expect adding
synchronize_rcu to the proper place (I'm not sure exactly where though)
when unmounting file systems would be a workable fix.
Note though - at this point I am only submitting the anon part of the
patchset for inclusion. That is, the v5.12-spf-anon branch, rather
than the v5.12-spf branch which has the additional / less mature
changes for file mapped vma faults.
--
Michel "walken" Lespinasse
Powered by blists - more mailing lists