Re: Confusing problem involving uint64_t bitops

  • From: Rafal Gwizdala <rafal.gwizdala@xxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Sat, 7 Feb 2015 17:09:05 +0100

hi, just out of curiosity tried to run this code but in my case there's a
different error
bad argument #1 to 'band' (number expected, got cdata)
btw, what's the use case for running lua in kernel?


On Sat, Feb 7, 2015 at 11:17 AM, Luke Gorrie <luke@xxxxxxxx> wrote:

> Howdy,
> Just wanted to report a mysterious issue that we are seeing with LuaJIT
> v2.1 version 392b6c9 (from May) but not with v2.1 HEAD today. I am not sure
> if this is a bug that was fixed in LuaJIT, or a bug in the code I am
> posting, or a bug elsewhere e.g. heap corruption making something weird
> happen. Looking at the commit log it is not obvious that this is due to any
> bug that was fixed.
> The problem is that this error:
> Invalid DMA address: 0x50035348b380
> core/memory.lua:95: DMA address tag check failed
> is reported by this function:
> local uint64_t = ffi.typeof("uint64_t")
> function virtual_to_physical (virt_addr)
>    local u64 = ffi.cast(uint64_t, virt_addr)
>    if, 0x500000000000ULL) ~= 0x500000000000ULL then
>       print("Invalid DMA address: 0x"..bit.tohex(u64,12))
>       error("DMA address tag check failed")
>    end
>    return bit.bxor(u64, 0x500000000000ULL)
> end
> and to me it seems like this should not be possible for the value we see
> in the error printout.
> This happens only under certain configurations within a larger
> application. (Some configurations never have the problem, other
> configurations always have the problem.) So far we have not been able to
> reproduce this with a smaller test case that I could post.
> (The code is checking and stripping tag bits from a pointer that has a
> physical memory address encoded into its virtual memory address.)
> Thoughts welcome. It is no problem to upgrade to the latest v2.1 but I
> don't know if that is actually "the fix" or not.
> -Luke

Other related posts: