[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YkPtcJdP4s0m17hY@infradead.org>
Date: Tue, 29 Mar 2022 22:41:04 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Dan Williams <dan.j.williams@...el.com>
Cc: Shiyang Ruan <ruansy.fnst@...itsu.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-xfs <linux-xfs@...r.kernel.org>,
Linux NVDIMM <nvdimm@...ts.linux.dev>,
Linux MM <linux-mm@...ck.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
"Darrick J. Wong" <djwong@...nel.org>, david <david@...morbit.com>,
Christoph Hellwig <hch@...radead.org>,
Jane Chu <jane.chu@...cle.com>
Subject: Re: [PATCH v11 1/8] dax: Introduce holder for dax_device
On Fri, Mar 11, 2022 at 03:35:13PM -0800, Dan Williams wrote:
> > + if (!dax_dev->holder_ops) {
> > + rc = -EOPNOTSUPP;
>
> I think it is ok to return success (0) for this case. All the caller
> of dax_holder_notify_failure() wants to know is if the notification
> was successfully delivered to the holder. If there is no holder
> present then there is nothing to report. This is minor enough for me
> to fix up locally if nothing else needs to be changed.
The caller needs to know there are no holder ops to fall back to
different path.
> Isn't this another failure scenario? If kill_dax() is called while a
> holder is still holding the dax_device that seems to be another
> ->notify_failure scenario to tell the holder that the device is going
> away and the holder has not released the device yet.
Yes.
Powered by blists - more mailing lists