From: Christoph Hellwig <hch@lst.de>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-nvdimm@lists.01.org, Christoph Hellwig <hch@lst.de>,
Ming Lei <ming.lei@redhat.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Hannes Reinecke <hare@suse.de>, Jens Axboe <axboe@kernel.dk>,
kernel test robot <lkp@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org
Subject: Re: [PATCH] libnvdimm: Let revalidate_disk() revalidate region read-only
Date: Tue, 9 Mar 2021 08:31:10 +0100 [thread overview]
Message-ID: <20210309073110.GA3140@lst.de> (raw)
In-Reply-To: <161527286194.446794.5215036039655765042.stgit@dwillia2-desk3.amr.corp.intel.com>
On Mon, Mar 08, 2021 at 10:54:22PM -0800, Dan Williams wrote:
> Previous kernels allowed the BLKROSET to override the disk's read-only
> status. With that situation fixed the pmem driver needs to rely on
> revalidate_disk() to clear the disk read-only status after the host
> region has been marked read-write.
>
> Recall that when libnvdimm determines that the persistent memory has
> lost persistence (for example lack of energy to flush from DRAM to FLASH
> on an NVDIMM-N device) it marks the region read-only, but that state can
> be overridden by the user via:
>
> echo 0 > /sys/bus/nd/devices/regionX/read_only
>
> ...to date there is no notification that the region has restored
> persistence, so the user override is the only recovery.
I've just resent my series to kill of ->revalidate_disk for good, so this
obvious makes me a little unhappy. Given that ->revalidate_disk
only ends up beeing called from the same path that ->open is called,
why can't you just hook this up from the open method?
Also any reason the sysfs attribute can't just directly propagate the
information to the disk?
next prev parent reply other threads:[~2021-03-09 7:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-09 6:54 [PATCH] libnvdimm: Let revalidate_disk() revalidate region read-only Dan Williams
2021-03-09 7:31 ` Christoph Hellwig [this message]
2021-03-09 16:36 ` Dan Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210309073110.GA3140@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=dan.j.williams@intel.com \
--cc=hare@suse.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=lkp@intel.com \
--cc=martin.petersen@oracle.com \
--cc=ming.lei@redhat.com \
--cc=vishal.l.verma@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).