* Why cast to "signed short" before checking the return value of gnttab_claim_grant_reference() in xen-netfront.c?
@ 2016-10-28 6:46 Dongli Zhang
2016-10-28 8:54 ` Jan Beulich
2016-10-28 9:11 ` David Vrabel
0 siblings, 2 replies; 3+ messages in thread
From: Dongli Zhang @ 2016-10-28 6:46 UTC (permalink / raw)
To: Xen-Devel
Hi,
Would anyone please help with a question on xen-netfront.c code?
In xen-netfront.c, the return value of gnttab_claim_grant_reference() is
checked with "BUG_ON((signed short)ref < 0);". Why we use signed short here
while the return value is of uint32_t?
Am I missing anything or can I send a patch to fix this issue? In
xen-blkfront.c and xen-scsifront.c "BUG_ON(gnt_list_entry->gref == -ENOSPC);"
is involved to check return value.
The guest kernel would panic after grant refs reach a very large number (when
guest is attached with large number of devices and live migrated).
Thank you very much!
Dongli Zhang
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Why cast to "signed short" before checking the return value of gnttab_claim_grant_reference() in xen-netfront.c?
2016-10-28 6:46 Why cast to "signed short" before checking the return value of gnttab_claim_grant_reference() in xen-netfront.c? Dongli Zhang
@ 2016-10-28 8:54 ` Jan Beulich
2016-10-28 9:11 ` David Vrabel
1 sibling, 0 replies; 3+ messages in thread
From: Jan Beulich @ 2016-10-28 8:54 UTC (permalink / raw)
To: Dongli Zhang; +Cc: Xen-Devel
>>> On 28.10.16 at 08:46, <dongli.zhang@oracle.com> wrote:
> Would anyone please help with a question on xen-netfront.c code?
>
> In xen-netfront.c, the return value of gnttab_claim_grant_reference() is
> checked with "BUG_ON((signed short)ref < 0);". Why we use signed short here
> while the return value is of uint32_t?
The return value is of type int. The value the return value gets stored
into is of type uint32_t.
> Am I missing anything or can I send a patch to fix this issue? In
> xen-blkfront.c and xen-scsifront.c "BUG_ON(gnt_list_entry->gref == -ENOSPC);"
> is involved to check return value.
This certainly looks wrong. Special casing -ENOSPC, otoh, isn't the
best approach either - I think you want to use IS_ERR_VALUE()
instead, perhaps together with using another intermediate
variable (or type long) to at once deal with the type mismatch
mentioned above as well as to please the compiler when using
IS_ERR_VALUE() (which casts the value to a pointer).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Why cast to "signed short" before checking the return value of gnttab_claim_grant_reference() in xen-netfront.c?
2016-10-28 6:46 Why cast to "signed short" before checking the return value of gnttab_claim_grant_reference() in xen-netfront.c? Dongli Zhang
2016-10-28 8:54 ` Jan Beulich
@ 2016-10-28 9:11 ` David Vrabel
1 sibling, 0 replies; 3+ messages in thread
From: David Vrabel @ 2016-10-28 9:11 UTC (permalink / raw)
To: Dongli Zhang, Xen-Devel
On 28/10/16 07:46, Dongli Zhang wrote:
> Hi,
>
> Would anyone please help with a question on xen-netfront.c code?
>
> In xen-netfront.c, the return value of gnttab_claim_grant_reference() is
> checked with "BUG_ON((signed short)ref < 0);". Why we use signed short here
> while the return value is of uint32_t?
That's wrong. Please just remove that BUG_ON() it isn't useful.
David
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-10-28 9:11 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-28 6:46 Why cast to "signed short" before checking the return value of gnttab_claim_grant_reference() in xen-netfront.c? Dongli Zhang
2016-10-28 8:54 ` Jan Beulich
2016-10-28 9:11 ` David Vrabel
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.