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?
R
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 bit.band(u64, 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:
