[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190821234945.GA31944@ziepe.ca>
Date: Wed, 21 Aug 2019 20:49:45 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Ira Weiny <ira.weiny@...el.com>
Cc: Dave Chinner <david@...morbit.com>, Jan Kara <jack@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
Dan Williams <dan.j.williams@...el.com>,
Matthew Wilcox <willy@...radead.org>,
Theodore Ts'o <tytso@....edu>,
John Hubbard <jhubbard@...dia.com>,
Michal Hocko <mhocko@...e.com>, linux-xfs@...r.kernel.org,
linux-rdma@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-nvdimm@...ts.01.org,
linux-ext4@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-)
On Wed, Aug 21, 2019 at 01:44:21PM -0700, Ira Weiny wrote:
> > The order FD's are closed during sigkill is not deterministic, so when
> > all the fputs happen during a kill'd exit we could end up blocking in
> > close(fd) as close(uverbs) will come after in the close
> > list. close(uverbs) is the thing that does the dereg_mr and releases
> > the pin.
>
> Of course, that is a different scenario which needs to be fixed in my patch
> set. Now that my servers are back up I can hopefully make progress. (Power
> was down for them yesterday).
It isn't really a different scenario, the problem is that the
filesystem fd must be closable independenly of fencing the MR to avoid
deadlock cycles. Once you resolve that the issue of the uverbs FD out
living it won't matter one bit if it is in the same process or
another.
Jason
Powered by blists - more mailing lists