[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210309073110.GA3140@lst.de>
Date: Tue, 9 Mar 2021 08:31:10 +0100
From: Christoph Hellwig <hch@....de>
To: Dan Williams <dan.j.williams@...el.com>
Cc: linux-nvdimm@...ts.01.org, Christoph Hellwig <hch@....de>,
Ming Lei <ming.lei@...hat.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Hannes Reinecke <hare@...e.de>, Jens Axboe <axboe@...nel.dk>,
kernel test robot <lkp@...el.com>,
Vishal Verma <vishal.l.verma@...el.com>,
linux-kernel@...r.kernel.org, linux-block@...r.kernel.org
Subject: Re: [PATCH] libnvdimm: Let revalidate_disk() revalidate region
read-only
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?
Powered by blists - more mailing lists