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>, Hannes Reinecke <hare@suse.de>,
Jens Axboe <axboe@kernel.dk>, kernel test robot <lkp@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?
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
WARNING: multiple messages have this Message-ID (diff)
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:31 UTC|newest]
Thread overview: 6+ 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 6:54 ` Dan Williams
2021-03-09 7:31 ` Christoph Hellwig [this message]
2021-03-09 7:31 ` Christoph Hellwig
2021-03-09 16:36 ` Dan Williams
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=ming.lei@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.