Message ID | 1464228995-26657-1-git-send-email-jasowang@redhat.com |
---|---|
State | New |
Headers | show |
On 26 May 2016 at 03:16, Jason Wang <jasowang@redhat.com> wrote: > The following changes since commit 287db79df8af8e31f18e262feb5e05103a09e4d4: > > Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into staging (2016-05-24 13:06:33 +0100) > > are available in the git repository at: > > https://github.com/jasowang/qemu.git tags/net-pull-request > > for you to fetch changes up to 136796b070ddd09dd14ef73e77ae20419ba6554a: > > net/net: Add SocketReadState for reuse codes (2016-05-26 09:58:22 +0800) > > ---------------------------------------------------------------- > > Main changes: > - e1000e emulation > - convet vmxnet3 to use DMA api > Changes from V2: > - fix clang build > Changes from V1: > - fix 32bit build Hi. I'm afraid this introduces new errors in the clang sanitizer output from make check: all the check-qtest-i386 and check-qtest-x86_64 runs produce output like: /home/petmay01/linaro/qemu-for-merges/hw/pci/pcie.c:641:25: runtime error: left shift of 4092 by 20 places cannot be represented in type 'int' /home/petmay01/linaro/qemu-for-merges/hw/pci/pcie.c:642:45: runtime error: left shift of 4092 by 20 places cannot be represented in type 'int' ==14902==WARNING: Trying to symbolize code, but external symbolizer is not initialized! /home/petmay01/linaro/qemu-for-merges/include/qemu/bswap.h:120:1: runtime error: store to misaligned address 0x2b23c01e6674 for type 'uint64_t' (aka 'unsigned long'), which requires 8 byte alignment 0x2b23c01e6674: note: pointer points here 03 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ The stuff about left shifts is just the usual shift-into-sign-bit which we haven't yet sorted out what we're doing with (ie whether we can ignore them and shut up the sanitizer without silencing other interesting warnings), but we shouldn't be doing misaligned stores of 64-bit values. Apologies for the lack of any backtraces in the output, but this is almost certainly the result of trying to do le64_to_cpu() or cpu_to_le64() on a buffer which isn't necessarily aligned (usually some pointer into guest memory). Use the functions ldq_le_p() and stq_le_p() instead, which will handle a potentially misaligned pointer for you. (There are similar functions for other access widths too.) thanks -- PMM
On 05/26/2016 09:08 AM, Peter Maydell wrote: > > Apologies for the lack of any backtraces in the output, but > this is almost certainly the result of trying to do le64_to_cpu() > or cpu_to_le64() on a buffer which isn't necessarily aligned > (usually some pointer into guest memory). Use the functions > ldq_le_p() and stq_le_p() instead, which will handle a > potentially misaligned pointer for you. (There are similar > functions for other access widths too.) Since these functions are constructed by ## token pasting, it's very hard to grep .h files to see what variations-on-a-theme are actually available, nor is the documentation clear on what they all do (in-place vs. copy, pass a value vs. a pointer, ...). It might be a nice bite-sized task to beef up the documentation and at least call out ALL of the endian-conversion functions in a nice comment (to make it greppable), along with this tidbit of information on which forms are optimized but require alignment, vs. work anywhere but potentially slower.
On 26 May 2016 at 16:20, Eric Blake <eblake@redhat.com> wrote: > On 05/26/2016 09:08 AM, Peter Maydell wrote: >> >> Apologies for the lack of any backtraces in the output, but >> this is almost certainly the result of trying to do le64_to_cpu() >> or cpu_to_le64() on a buffer which isn't necessarily aligned >> (usually some pointer into guest memory). Use the functions >> ldq_le_p() and stq_le_p() instead, which will handle a >> potentially misaligned pointer for you. (There are similar >> functions for other access widths too.) > > Since these functions are constructed by ## token pasting, it's very > hard to grep .h files to see what variations-on-a-theme are actually > available, nor is the documentation clear on what they all do (in-place > vs. copy, pass a value vs. a pointer, ...). It might be a nice > bite-sized task to beef up the documentation and at least call out ALL > of the endian-conversion functions in a nice comment (to make it > greppable), along with this tidbit of information on which forms are > optimized but require alignment, vs. work anywhere but potentially slower. The documentation of the ld* functions is in bswap.h (the comment starting "the generic syntax is"), though I agree it is a bit awkward not having it greppable. There would probably be about 200 functions if you expanded out the names just in the ld*_p() family. We could probably also do a better job of marking which of these function families are recommended, and which are obsolete flavours which we have because a bunch of old code still uses them. (You can tell cpu_to_le64() and friends don't handle misalignment because they take a uint64_t, not a pointer to one.) thanks -- PMM
On 2016年05月26日 23:08, Peter Maydell wrote: > On 26 May 2016 at 03:16, Jason Wang <jasowang@redhat.com> wrote: >> The following changes since commit 287db79df8af8e31f18e262feb5e05103a09e4d4: >> >> Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into staging (2016-05-24 13:06:33 +0100) >> >> are available in the git repository at: >> >> https://github.com/jasowang/qemu.git tags/net-pull-request >> >> for you to fetch changes up to 136796b070ddd09dd14ef73e77ae20419ba6554a: >> >> net/net: Add SocketReadState for reuse codes (2016-05-26 09:58:22 +0800) >> >> ---------------------------------------------------------------- >> >> Main changes: >> - e1000e emulation >> - convet vmxnet3 to use DMA api >> Changes from V2: >> - fix clang build >> Changes from V1: >> - fix 32bit build > Hi. I'm afraid this introduces new errors in the clang sanitizer output > from make check: all the check-qtest-i386 and check-qtest-x86_64 > runs produce output like: > > /home/petmay01/linaro/qemu-for-merges/hw/pci/pcie.c:641:25: runtime > error: left shift of 4092 by 20 places cannot be > represented in type 'int' > /home/petmay01/linaro/qemu-for-merges/hw/pci/pcie.c:642:45: runtime > error: left shift of 4092 by 20 places cannot be > represented in type 'int' > ==14902==WARNING: Trying to symbolize code, but external symbolizer is > not initialized! > /home/petmay01/linaro/qemu-for-merges/include/qemu/bswap.h:120:1: > runtime error: store to misaligned address 0x2b23c01e6674 for type > 'uint64_t' (aka 'unsigned long'), which requires 8 byte alignment > 0x2b23c01e6674: note: pointer points here > 03 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 > ^ Sorry for the trouble again. Wonder the correct way to enable sanitizer, after I add "-fsanitizer=address", it produces tons of warnings and errors but don't find the above outputs. > The stuff about left shifts is just the usual shift-into-sign-bit > which we haven't yet sorted out what we're doing with (ie > whether we can ignore them and shut up the sanitizer without > silencing other interesting warnings), but we shouldn't be doing > misaligned stores of 64-bit values. I agree. > > Apologies for the lack of any backtraces in the output, but > this is almost certainly the result of trying to do le64_to_cpu() > or cpu_to_le64() on a buffer which isn't necessarily aligned > (usually some pointer into guest memory). Use the functions > ldq_le_p() and stq_le_p() instead, which will handle a > potentially misaligned pointer for you. (There are similar > functions for other access widths too.) > > thanks > -- PMM Leonid and Dmitry, please check the guest memory access as suggested above and respin the series. I will hold the pull until the new version. Thanks
On 27 May 2016 at 04:35, Jason Wang <jasowang@redhat.com> wrote: > Sorry for the trouble again. Wonder the correct way to enable sanitizer, > after I add "-fsanitizer=address", it produces tons of warnings and errors > but don't find the above outputs. I pass configure '--extra-cflags=-fsanitize=undefined' . thanks -- PMM