Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1652351 > unrolled thread

[PATCH] xen: don't print error message in case of missing Xenstore entry

Started byJuergen Gross <jgross@suse.com>
First post2017-05-29 11:20 +0200
Last post2017-05-30 19:20 +0200
Articles 5 — 2 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH] xen: don't print error message in case of missing Xenstore entry Juergen Gross <jgross@suse.com> - 2017-05-29 11:20 +0200
    Re: [PATCH] xen: don't print error message in case of missing  Xenstore entry Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-05-30 15:30 +0200
      Re: [PATCH] xen: don't print error message in case of missing  Xenstore entry Juergen Gross <jgross@suse.com> - 2017-05-30 17:10 +0200
        Re: [PATCH] xen: don't print error message in case of missing  Xenstore entry Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-05-30 19:10 +0200
          Re: [PATCH] xen: don't print error message in case of missing  Xenstore entry Juergen Gross <jgross@suse.com> - 2017-05-30 19:20 +0200

#1652351 — [PATCH] xen: don't print error message in case of missing Xenstore entry

FromJuergen Gross <jgross@suse.com>
Date2017-05-29 11:20 +0200
Subject[PATCH] xen: don't print error message in case of missing Xenstore entry
Message-ID<tMp0g-6bg-65@gated-at.bofh.it>
When registering for the Xenstore watch of the node control/sysrq the
handler will be called at once. Don't issue an error message if the
Xenstore node isn't there, as it will be created only when an event
is being triggered.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 drivers/xen/manage.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index c1ec8ee80924..7ddd0803da23 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -277,8 +277,11 @@ static void sysrq_handler(struct xenbus_watch *watch, const char *path,
 	err = xenbus_transaction_start(&xbt);
 	if (err)
 		return;
-	if (xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key) < 0) {
-		pr_err("Unable to read sysrq code in control/sysrq\n");
+	err = xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key);
+	if (err < 0) {
+		if (err != -ENOENT)
+			pr_err("Error %d reading sysrq code in control/sysrq\n",
+			       err);
 		xenbus_transaction_end(xbt, 1);
 		return;
 	}
-- 
2.12.3

[toc] | [next] | [standalone]

#1653230 — Re: [PATCH] xen: don't print error message in case of missing Xenstore entry

FromBoris Ostrovsky <boris.ostrovsky@oracle.com>
Date2017-05-30 15:30 +0200
SubjectRe: [PATCH] xen: don't print error message in case of missing Xenstore entry
Message-ID<tMPnI-7TL-9@gated-at.bofh.it>
In reply to#1652351
On 05/29/2017 05:13 AM, Juergen Gross wrote:
> When registering for the Xenstore watch of the node control/sysrq the
> handler will be called at once. Don't issue an error message if the
> Xenstore node isn't there, as it will be created only when an event
> is being triggered.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  drivers/xen/manage.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
> index c1ec8ee80924..7ddd0803da23 100644
> --- a/drivers/xen/manage.c
> +++ b/drivers/xen/manage.c
> @@ -277,8 +277,11 @@ static void sysrq_handler(struct xenbus_watch *watch, const char *path,
>  	err = xenbus_transaction_start(&xbt);
>  	if (err)
>  		return;
> -	if (xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key) < 0) {
> -		pr_err("Unable to read sysrq code in control/sysrq\n");
> +	err = xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key);
> +	if (err < 0) {
> +		if (err != -ENOENT)

Can we distinguish initialization invocation from actual watch firing?
E.g. '|| (system_state >= SYSTEM_RUNNING)'?

-boris

> +			pr_err("Error %d reading sysrq code in control/sysrq\n",
> +			       err);
>  		xenbus_transaction_end(xbt, 1);
>  		return;
>  	}

[toc] | [prev] | [next] | [standalone]

#1653298 — Re: [PATCH] xen: don't print error message in case of missing Xenstore entry

FromJuergen Gross <jgross@suse.com>
Date2017-05-30 17:10 +0200
SubjectRe: [PATCH] xen: don't print error message in case of missing Xenstore entry
Message-ID<tMQWt-wG-13@gated-at.bofh.it>
In reply to#1653230
On 30/05/17 15:25, Boris Ostrovsky wrote:
> On 05/29/2017 05:13 AM, Juergen Gross wrote:
>> When registering for the Xenstore watch of the node control/sysrq the
>> handler will be called at once. Don't issue an error message if the
>> Xenstore node isn't there, as it will be created only when an event
>> is being triggered.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>>  drivers/xen/manage.c | 7 +++++--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
>> index c1ec8ee80924..7ddd0803da23 100644
>> --- a/drivers/xen/manage.c
>> +++ b/drivers/xen/manage.c
>> @@ -277,8 +277,11 @@ static void sysrq_handler(struct xenbus_watch *watch, const char *path,
>>  	err = xenbus_transaction_start(&xbt);
>>  	if (err)
>>  		return;
>> -	if (xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key) < 0) {
>> -		pr_err("Unable to read sysrq code in control/sysrq\n");
>> +	err = xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key);
>> +	if (err < 0) {
>> +		if (err != -ENOENT)
> 
> Can we distinguish initialization invocation from actual watch firing?
> E.g. '|| (system_state >= SYSTEM_RUNNING)'?

The watch will fire again after suspend/resume (e.g. live migration).


Juergen

> 
> -boris
> 
>> +			pr_err("Error %d reading sysrq code in control/sysrq\n",
>> +			       err);
>>  		xenbus_transaction_end(xbt, 1);
>>  		return;
>>  	}
> 
>

[toc] | [prev] | [next] | [standalone]

#1653405 — Re: [PATCH] xen: don't print error message in case of missing Xenstore entry

FromBoris Ostrovsky <boris.ostrovsky@oracle.com>
Date2017-05-30 19:10 +0200
SubjectRe: [PATCH] xen: don't print error message in case of missing Xenstore entry
Message-ID<tMSOC-1GK-15@gated-at.bofh.it>
In reply to#1653298
On 05/30/2017 11:03 AM, Juergen Gross wrote:
> On 30/05/17 15:25, Boris Ostrovsky wrote:
>> On 05/29/2017 05:13 AM, Juergen Gross wrote:
>>> When registering for the Xenstore watch of the node control/sysrq the
>>> handler will be called at once. Don't issue an error message if the
>>> Xenstore node isn't there, as it will be created only when an event
>>> is being triggered.
>>>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>> ---
>>>  drivers/xen/manage.c | 7 +++++--
>>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
>>> index c1ec8ee80924..7ddd0803da23 100644
>>> --- a/drivers/xen/manage.c
>>> +++ b/drivers/xen/manage.c
>>> @@ -277,8 +277,11 @@ static void sysrq_handler(struct xenbus_watch *watch, const char *path,
>>>  	err = xenbus_transaction_start(&xbt);
>>>  	if (err)
>>>  		return;
>>> -	if (xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key) < 0) {
>>> -		pr_err("Unable to read sysrq code in control/sysrq\n");
>>> +	err = xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key);
>>> +	if (err < 0) {
>>> +		if (err != -ENOENT)
>> Can we distinguish initialization invocation from actual watch firing?
>> E.g. '|| (system_state >= SYSTEM_RUNNING)'?
> The watch will fire again after suspend/resume (e.g. live migration).


That's unfortunate. (And system_state check would also not be a good
solution btw since the watch might be processed by the watch thread
after we enter SYSTEM_RUNNING).

Can you add a comment explaining why we are ignoring ENOENT?

-boris



>
>
> Juergen
>
>> -boris
>>
>>> +			pr_err("Error %d reading sysrq code in control/sysrq\n",
>>> +			       err);
>>>  		xenbus_transaction_end(xbt, 1);
>>>  		return;
>>>  	}
>>

[toc] | [prev] | [next] | [standalone]

#1653416 — Re: [PATCH] xen: don't print error message in case of missing Xenstore entry

FromJuergen Gross <jgross@suse.com>
Date2017-05-30 19:20 +0200
SubjectRe: [PATCH] xen: don't print error message in case of missing Xenstore entry
Message-ID<tMSYi-1K4-11@gated-at.bofh.it>
In reply to#1653405
On 30/05/17 19:08, Boris Ostrovsky wrote:
> On 05/30/2017 11:03 AM, Juergen Gross wrote:
>> On 30/05/17 15:25, Boris Ostrovsky wrote:
>>> On 05/29/2017 05:13 AM, Juergen Gross wrote:
>>>> When registering for the Xenstore watch of the node control/sysrq the
>>>> handler will be called at once. Don't issue an error message if the
>>>> Xenstore node isn't there, as it will be created only when an event
>>>> is being triggered.
>>>>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>> ---
>>>>  drivers/xen/manage.c | 7 +++++--
>>>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
>>>> index c1ec8ee80924..7ddd0803da23 100644
>>>> --- a/drivers/xen/manage.c
>>>> +++ b/drivers/xen/manage.c
>>>> @@ -277,8 +277,11 @@ static void sysrq_handler(struct xenbus_watch *watch, const char *path,
>>>>  	err = xenbus_transaction_start(&xbt);
>>>>  	if (err)
>>>>  		return;
>>>> -	if (xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key) < 0) {
>>>> -		pr_err("Unable to read sysrq code in control/sysrq\n");
>>>> +	err = xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key);
>>>> +	if (err < 0) {
>>>> +		if (err != -ENOENT)
>>> Can we distinguish initialization invocation from actual watch firing?
>>> E.g. '|| (system_state >= SYSTEM_RUNNING)'?
>> The watch will fire again after suspend/resume (e.g. live migration).
> 
> 
> That's unfortunate. (And system_state check would also not be a good
> solution btw since the watch might be processed by the watch thread
> after we enter SYSTEM_RUNNING).
> 
> Can you add a comment explaining why we are ignoring ENOENT?

Sure.


Juergen

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web