libnvdimm/region: Update is_nvdimm_sync check to handle volatile regions
diff mbox series

Message ID 20190924114327.14700-1-aneesh.kumar@linux.ibm.com
State Mainlined
Commit 4c806b897d6075bfa5067e524fb058c57ab64e7b
Headers show
Series
  • libnvdimm/region: Update is_nvdimm_sync check to handle volatile regions
Related show

Commit Message

Aneesh Kumar K.V Sept. 24, 2019, 11:43 a.m. UTC
We should consider volatile regions synchronous so that we are resilient to
OS crashes. This is needed when we have hypervisor like KVM exporting a ramdisk
as pmem dimms.

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
 drivers/nvdimm/region_devs.c | 3 +++
 1 file changed, 3 insertions(+)

Comments

Pankaj Gupta Sept. 24, 2019, 11:52 a.m. UTC | #1
> 
> We should consider volatile regions synchronous so that we are resilient to
> OS crashes. This is needed when we have hypervisor like KVM exporting a
> ramdisk
> as pmem dimms.
> 
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
>  drivers/nvdimm/region_devs.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c
> index ab91890f2486..ef423ba1a711 100644
> --- a/drivers/nvdimm/region_devs.c
> +++ b/drivers/nvdimm/region_devs.c
> @@ -1168,6 +1168,9 @@ EXPORT_SYMBOL_GPL(nvdimm_has_cache);
>  
>  bool is_nvdimm_sync(struct nd_region *nd_region)
>  {
> +	if (is_nd_volatile(&nd_region->dev))
> +		return true;
> +
>  	return is_nd_pmem(&nd_region->dev) &&
>  		!test_bit(ND_REGION_ASYNC, &nd_region->flags);
>  }
> --
> 2.21.0

Reviewed-by: Pankaj Gupta <pagupta@redhat.com>

> 
> _______________________________________________
> Linux-nvdimm mailing list
> Linux-nvdimm@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm
>
Dan Williams Sept. 24, 2019, 4:57 p.m. UTC | #2
On Tue, Sep 24, 2019 at 4:43 AM Aneesh Kumar K.V
<aneesh.kumar@linux.ibm.com> wrote:
>
> We should consider volatile regions synchronous so that we are resilient to
> OS crashes. This is needed when we have hypervisor like KVM exporting a ramdisk
> as pmem dimms.

We have a hard time understanding what agent is being referenced when
we use "we" in a patch changelog. We would prefer that we consider not
using "we" in favor of explicitly named agents, or otherwise review
the changelog to make sure that "we" is clearly discernable. We will
fix it up this time when applying, but we hope we have made it clear
how confusing liberal use of "we" can be.
Dan Williams Sept. 24, 2019, 5:12 p.m. UTC | #3
On Tue, Sep 24, 2019 at 9:57 AM Dan Williams <dan.j.williams@intel.com> wrote:
>
> On Tue, Sep 24, 2019 at 4:43 AM Aneesh Kumar K.V
> <aneesh.kumar@linux.ibm.com> wrote:
> >
> > We should consider volatile regions synchronous so that we are resilient to
> > OS crashes. This is needed when we have hypervisor like KVM exporting a ramdisk
> > as pmem dimms.
>
> We have a hard time understanding what agent is being referenced when
> we use "we" in a patch changelog. We would prefer that we consider not
> using "we" in favor of explicitly named agents, or otherwise review
> the changelog to make sure that "we" is clearly discernable. We will
> fix it up this time when applying, but we hope we have made it clear
> how confusing liberal use of "we" can be.

To be clear, I'm not strictly opposed to using "we" when it is
established which we is being referred and stays constant throughout
the description. This instance caught my eye again because the first
couple "we"s seems to be the kernel, and the last we seems to be a
user platform configuration.
Aneesh Kumar K.V Sept. 25, 2019, 3:54 a.m. UTC | #4
Hi Dan,

On 9/24/19 10:42 PM, Dan Williams wrote:
> On Tue, Sep 24, 2019 at 9:57 AM Dan Williams <dan.j.williams@intel.com> wrote:
>>
>> On Tue, Sep 24, 2019 at 4:43 AM Aneesh Kumar K.V
>> <aneesh.kumar@linux.ibm.com> wrote:
>>>
>>> We should consider volatile regions synchronous so that we are resilient to
>>> OS crashes. This is needed when we have hypervisor like KVM exporting a ramdisk
>>> as pmem dimms.
>>
>> We have a hard time understanding what agent is being referenced when
>> we use "we" in a patch changelog. We would prefer that we consider not
>> using "we" in favor of explicitly named agents, or otherwise review
>> the changelog to make sure that "we" is clearly discernable. We will
>> fix it up this time when applying, but we hope we have made it clear
>> how confusing liberal use of "we" can be.
> 
> To be clear, I'm not strictly opposed to using "we" when it is
> established which we is being referred and stays constant throughout
> the description. This instance caught my eye again because the first
> couple "we"s seems to be the kernel, and the last we seems to be a
> user platform configuration.
> 

Thanks for the feedback. I will take extra care to clearly indicate the 
component/agent next time.

Thanks for taking the patch.

-aneesh

Patch
diff mbox series

diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c
index ab91890f2486..ef423ba1a711 100644
--- a/drivers/nvdimm/region_devs.c
+++ b/drivers/nvdimm/region_devs.c
@@ -1168,6 +1168,9 @@  EXPORT_SYMBOL_GPL(nvdimm_has_cache);
 
 bool is_nvdimm_sync(struct nd_region *nd_region)
 {
+	if (is_nd_volatile(&nd_region->dev))
+		return true;
+
 	return is_nd_pmem(&nd_region->dev) &&
 		!test_bit(ND_REGION_ASYNC, &nd_region->flags);
 }