All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "Williams, Dan J" <dan.j.williams@intel.com>,
	"decui@microsoft.com" <decui@microsoft.com>,
	"Jiang, Dave" <dave.jiang@intel.com>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	"jthumshirn@suse.de" <jthumshirn@suse.de>,
	"mikelley@microsoft.com" <mikelley@microsoft.com>,
	"qi.fuli@fujitsu.com" <qi.fuli@fujitsu.com>
Subject: Re: [ndctl PATCH v2 4/4] ndctl, monitor: support NVDIMM_FAMILY_HYPERV
Date: Thu, 21 Mar 2019 01:54:52 +0000	[thread overview]
Message-ID: <9876fd8a491e339f2f41a47e2195d354bf0d5fb2.camel@intel.com> (raw)
In-Reply-To: <PU1P153MB01691E80896E9EAA0C8245EDBF7D0@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>


On Wed, 2019-02-20 at 05:11 +0000, Dexuan Cui wrote:
> Currently "ndctl monitor" fails for NVDIMM_FAMILY_HYPERV due to
> "no smart support".
> 
> NVDIMM_FAMILY_HYPERV doesn't use ND_CMD_SMART to get the health info.
> Instead, it uses ND_CMD_CALL, so the checking here can't apply,and it
> doesn't support threshold alarms -- actually it only supports one event:
> ND_EVENT_HEALTH_STATE.
> 
> See http://www.uefi.org/RFIC_LIST ("Virtual NVDIMM 0x1901").
> 
> Let's skip the unnecessary checking for NVDIMM_FAMILY_HYPERV, and make
> sure we only monitor the "dimm-health-state" event and ignore the others.
> 
> With the patch, when an error happens, we log it with such a message:
> 
> {"timestamp":"1550547497.431731497","pid":1571,"event":
> {"dimm-health-state":true},"dimm":{"dev":"nmem1",
> "id":"04d5-01-1701-01000000","handle":1,"phys_id":0,
> "health":{"health_state":"fatal","shutdown_count":8}}}
> 
> Here the meaningful info is:
> "health":{"health_state":"fatal","shutdown_count":8}
> 
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
> ---
>  ndctl/monitor.c | 42 +++++++++++++++++++++++++++++++++++-------
>  1 file changed, 35 insertions(+), 7 deletions(-)
> 
> diff --git a/ndctl/monitor.c b/ndctl/monitor.c
> index 43b2abe..43beb06 100644
> --- a/ndctl/monitor.c
> +++ b/ndctl/monitor.c
> @@ -265,31 +265,59 @@ static bool filter_region(struct ndctl_region *region,
>  	return true;
>  }
>  
> -static void filter_dimm(struct ndctl_dimm *dimm, struct util_filter_ctx *fctx)
> +static bool ndctl_dimm_test_and_enable_notification(struct ndctl_dimm *dimm)
>  {
> -	struct monitor_dimm *mdimm;
> -	struct monitor_filter_arg *mfa = fctx->monitor;
>  	const char *name = ndctl_dimm_get_devname(dimm);
>  
> +	/*
> +	 * Hyper-V Virtual NVDIMM doesn't use ND_CMD_SMART to get the health
> +	 * info. Instead, it uses ND_CMD_CALL, so the checking here can't
> +	 * apply, and it doesn't support threshold alarms -- actually it only
> +	 * supports one event: ND_EVENT_HEALTH_STATE.
> +	 */
> +	if (ndctl_dimm_get_cmd_family(dimm) == NVDIMM_FAMILY_HYPERV) {
> +		if (monitor.event_flags != ND_EVENT_HEALTH_STATE) {
> +			monitor.event_flags = ND_EVENT_HEALTH_STATE;
> +
> +			notice(&monitor,
> +				"%s: only dimm-health-state can be monitored\n",
> +				name);
> +		}
> +		return true;
> +	}
> +

I'm not sure about the family-specific special casing -- it leaks family
specific details into the common implementation, something that's been
avoidable thus far.

Is there any reason why the ndctl_dimm_is_cmd_supported() can't be made
to fail appropriately for anything that is not supported, by adding the
necessary functions to dimm-ops?

That way if the user enters any of the unsupported options, they will
just fail normally, and the user will be expected to provide the right
options for the environment they know they're running in.

Indeed, I think that patch 3 of this series should never be required :)

>  	if (!ndctl_dimm_is_cmd_supported(dimm, ND_CMD_SMART)) {
>  		err(&monitor, "%s: no smart support\n", name);
> -		return;
> +		return false;
>  	}
>  	if (!ndctl_dimm_is_cmd_supported(dimm, ND_CMD_SMART_THRESHOLD)) {
>  		err(&monitor, "%s: no smart threshold support\n", name);
> -		return;
> +		return false;
>  	}
>  
>  	if (!ndctl_dimm_is_flag_supported(dimm, ND_SMART_ALARM_VALID)) {
>  		err(&monitor, "%s: smart alarm invalid\n", name);
> -		return;
> +		return false;
>  	}
>  
>  	if (enable_dimm_supported_threshold_alarms(dimm)) {
>  		err(&monitor, "%s: enable supported threshold alarms failed\n", name);
> -		return;
> +		return false;
>  	}
>  
> +	return true;
> +}
> +
> +static void filter_dimm(struct ndctl_dimm *dimm, struct util_filter_ctx *fctx)
> +{
> +	struct monitor_dimm *mdimm;
> +	struct monitor_filter_arg *mfa = fctx->monitor;
> +	const char *name = ndctl_dimm_get_devname(dimm);
> +
> +
> +	if (!ndctl_dimm_test_and_enable_notification(dimm))
> +		return;
> +
>  	mdimm = calloc(1, sizeof(struct monitor_dimm));
>  	if (!mdimm) {
>  		err(&monitor, "%s: calloc for monitor dimm failed\n", name);

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

  parent reply	other threads:[~2019-03-21  1:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-20  5:11 [ndctl PATCH v2 4/4] ndctl, monitor: support NVDIMM_FAMILY_HYPERV Dexuan Cui
2019-02-21  8:40 ` qi.fuli
     [not found]   ` <OSBPR01MB50009900A5FE2E8588AA6367F77E0-zhdMvvdcU0ZckHoPmfvix3colHNk5qUtvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2019-02-21 18:30     ` Dexuan Cui
2019-02-25  4:48       ` qi.fuli
     [not found]         ` <OSAPR01MB4993163079F35EEF06DFBB44F77A0-OxqQCv4d1nTzcNm8D4NKs3colHNk5qUtvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2019-02-25  5:16           ` Dexuan Cui
2019-03-21  1:54 ` Verma, Vishal L [this message]
     [not found]   ` <9876fd8a491e339f2f41a47e2195d354bf0d5fb2.camel-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2019-03-22  2:08     ` Dexuan Cui
2019-03-22  3:31       ` Dan Williams
     [not found]       ` <PU1P153MB0169CA436F52268DD2BEF745BF430-7hHSCQUTt08p9lVGRpUb+2HfQuWdHs3hiGd9ebBGJoev3QGu/rdwKA@public.gmane.org>
2019-03-22  4:05         ` Dexuan Cui
2019-03-22  4:13           ` Dan Williams
     [not found]             ` <CAPcyv4hVZLW2OSMZ9NqqsQWMg7vxyS9J1ekDZW8G44cmD9_YCw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-03-22  5:09               ` Dexuan Cui
2019-03-22  5:36                 ` Dan Williams
     [not found]                   ` <CAPcyv4hM_DTcMJdWhWbtPFfVH_V-kYxXSSCg=MQZLoxVka=Mng-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-03-22  6:03                     ` Dexuan Cui
2019-03-22  6:11                       ` Dan Williams
     [not found]                         ` <CAPcyv4h4tAydacTbmZRKy7hmTqWTM22r6hD+Ucm_f3H2tQUm3g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-03-22 17:55                           ` Dexuan Cui
2019-03-22 18:03                             ` Dan Williams
     [not found]                               ` <CAPcyv4gMexBmWduqR8G=1H3gKkxbqfBADOLG595nVRipAxVukA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-03-22 18:09                                 ` Dexuan Cui
2019-03-22 18:28                             ` Verma, Vishal L
     [not found]                               ` <837eed30b0da59f91e5114aad97e919068a077e8.camel-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2019-03-23  4:24                                 ` Dexuan Cui

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=9876fd8a491e339f2f41a47e2195d354bf0d5fb2.camel@intel.com \
    --to=vishal.l.verma@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=decui@microsoft.com \
    --cc=jthumshirn@suse.de \
    --cc=linux-nvdimm@lists.01.org \
    --cc=mikelley@microsoft.com \
    --cc=qi.fuli@fujitsu.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.