Sandbox js-dispatch-table code's kFreeEntryTag

51 views
Skip to first unread message

Dan McDonald

unread,
Apr 7, 2025, 4:33:00 AM4/7/25
to v8-dev
Due to node trying to bring in more recent versions of V8, I was informed about it not building on illumos (Node calls it SmartOS but it's really applicable to all illumos distros).

After some searching and debug-by-printf, I found this line:


At first glance, this line appears to assume that pointers have all-zeroes at the top, for free use.  This is not true for illumos, which sets its heap pointers starting at:

#define USERLIMIT       ADDRESS_C(0xfffffc7fffe00000)

It gets more hard to understand, however, given that:

- It's a 16-bit mask, but used with 32-bit inputs like here:


- The 32-bit input has no mask collision with the 0xffff000000000000 definition of the next_entry_index variable.

This feels like a bug to me, and if ones pointers have the high 16 bits set to 0, it might be an undetected one.

I may be missing something, and am glad to be educated,. To my eyes, either this code did not consider getting pointers with the high-16-bits set to non-zero values, or it is plain buggy, and the kFreeEntryTag specifically in js-dispatch-table.h is mis-defined.

Jakob Kummerow

unread,
Apr 7, 2025, 4:53:00 AM4/7/25
to v8-...@googlegroups.com
On Mon, Apr 7, 2025 at 10:33 AM Dan McDonald <kebesoftwar...@gmail.com> wrote:
Due to node trying to bring in more recent versions of V8, I was informed about it not building on illumos (Node calls it SmartOS but it's really applicable to all illumos distros).

After some searching and debug-by-printf, I found this line:


At first glance, this line appears to assume that pointers have all-zeroes at the top, for free use.  This is not true for illumos, which sets its heap pointers starting at:

#define USERLIMIT       ADDRESS_C(0xfffffc7fffe00000)

It gets more hard to understand, however, given that:

- It's a 16-bit mask, but used with 32-bit inputs like here:


- The 32-bit input has no mask collision with the 0xffff000000000000 definition of the next_entry_index variable.

This feels like a bug to me,

No, that code is fine. It is entirely intentional to not have a collision between the top 16 bits in the kFreeEntryTag and the lower 32-bits payload.
 
and if ones pointers have the high 16 bits set to 0, it might be an undetected one.

I may be missing something, and am glad to be educated,. To my eyes, either this code did not consider getting pointers with the high-16-bits set to non-zero values,

Yes, that code is quite clearly written for OSs where the upper 16 bits of a 64-bit pointer are always zero.
For other OSs this will need adaptation. I don't have a specific suggestion, and am not planning to work on it. If you want to work on a patch yourself, please keep in mind to make it as non-intrusive as possible: since such OSs are officially unsupported, we wouldn't want to pay a large code complexity price for them.

Dan McDonald

unread,
Apr 7, 2025, 9:55:50 AM4/7/25
to v8-dev
On Monday, April 7, 2025 at 4:53:00 AM UTC-4 Jakob Kummerow wrote:

No, that code is fine. It is entirely intentional to not have a collision between the top 16 bits in the kFreeEntryTag and the lower 32-bits payload.

Okay.  This is good to know.
 
I may be missing something, and am glad to be educated,. To my eyes, either this code did not consider getting pointers with the high-16-bits set to non-zero values,

Yes, that code is quite clearly written for OSs where the upper 16 bits of a 64-bit pointer are always zero.

Not entirely clear to the newbie reader, which is why I was here.  :)

Is there clear documentation of what v8 expects out of a pointer?  If not, I'd be happy to help write/edit one so future newbies don't stumble into the weeds like I have.
 
For other OSs this will need adaptation. I don't have a specific suggestion, and am not planning to work on it. If you want to work on a patch yourself, please keep in mind to make it as non-intrusive as possible: since such OSs are officially unsupported, we wouldn't want to pay a large code complexity price for them.

I wouldn't mind. I might keep it in Node for starters since that how I found all this out. Before I would attempt something, however,. I would like to know V8's assumptions about pointers. If documentation exists, please point me (pun intended) at it. If no such documentation exists, or only exists in scattered form, I could assist, with the help of a full-time-V8-er, to create some.  An OS provider may their own assumptions about pointers, and knowing where they cross-purposes with V8 up front would save a lot future hassle.

Olivier Flückiger

unread,
Apr 8, 2025, 2:58:37 AM4/8/25
to v8-...@googlegroups.com
Hi Dan,

thanks for reporting the issue here. Please refer to this comment https://github.com/v8/v8/blob/main/src/sandbox/js-dispatch-table.h#L110 to understand how the JSDispatch table uses an ad-hoc compression of this particular pointer to recycle 16 of its bits for other purposes. Without digging in the code myself I cannot help you with a comprehensive list of what we assume about pointers in general.

AIX ran into the same issue. There is currently a CL in review to address it in their case: https://chromium-review.googlesource.com/c/v8/v8/+/6320599 .

Maybe you can try that one and comment if it works for illumos. If it doesn't it would be good if you can directly work with them on that CL to find a solution that works for both OSs.

Best,
*oli


--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/v8-dev/d4e7cc3f-7e7c-454a-88c9-361e91cd794bn%40googlegroups.com.

Dan McDonald

unread,
Apr 8, 2025, 10:45:55 AM4/8/25
to v8-dev
On Tuesday, April 8, 2025 at 2:58:37 AM UTC-4 *oli wrote:
Hi Dan,

thanks for reporting the issue here. Please refer to this comment https://github.com/v8/v8/blob/main/src/sandbox/js-dispatch-table.h#L110 to understand how the JSDispatch table uses an ad-hoc compression of this particular pointer to recycle 16 of its bits for other purposes. Without digging in the code myself I cannot help you with a comprehensive list of what we assume about pointers in general.

I see nothing in the ascii diagram shown here to indicate the upper 16 bits are used as a "in free list" tag.  Only here:


is the upper-16-bits even hinted at, and to a new reader, it is opaque at best. As I'll mention in the gerrit below, I have a smaller fix (in the context of Node) that focusses on this, but I do wonder if, upon turning a free-list-entry into a real pointer, the proper upper-bits get recovered.
 
AIX ran into the same issue. There is currently a CL in review to address it in their case: https://chromium-review.googlesource.com/c/v8/v8/+/6320599 .

Maybe you can try that one and comment if it works for illumos. If it doesn't it would be good if you can directly work with them on that CL to find a solution that works for both OSs.

I'm looking at it now, and will have things to say, thank you!

Dan
Reply all
Reply to author
Forward
0 new messages