Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1512408
| From | "Jan Beulich" <JBeulich@suse.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [Xen-devel] [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short |
| Date | 2016-10-31 09:50 +0100 |
| Message-ID | <sygs2-8q2-7@gated-at.bofh.it> (permalink) |
| References | <syg8G-8jp-27@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
>>> On 31.10.16 at 09:28, <dongli.zhang@oracle.com> wrote: >> > ref = gnttab_claim_grant_reference(&queue->gref_rx_head); >> > - BUG_ON((signed short)ref < 0); >> > + WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)ref)); > >> You really need to cast to plain (or signed) long here - casting to >> unsigned long will work only in 32-bit configurations, as otherwise >> you lose the sign of the value. > > Seems the sign of value would not be lost since casting to unsigned long will > use signed extension. Is my understanding wrong or did I miss anything? ref being of type grant_ref_t, which is a typedef of uint32_t, I can't see how the conversion to unsigned long would be using sign extension. Did you look at the generated code? (If ref was of a signed type, I don't think the original author would have found a need to cast it to signed short.) > I have verified this with both sample userspace helloworld program > and a kernel module. Are you saying you did see the warning trigger with a 64-bit kernel? I'd be very surprised, but of course I may be overlooking something. Jan
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [Xen-devel] [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short Dongli Zhang <dongli.zhang@oracle.com> - 2016-10-31 09:30 +0100 Re: [Xen-devel] [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short "Jan Beulich" <JBeulich@suse.com> - 2016-10-31 09:50 +0100
csiph-web