WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
77712
[JSC] Range of cache flush is not guaranteed by Linux kernel
https://bugs.webkit.org/show_bug.cgi?id=77712
Summary
[JSC] Range of cache flush is not guaranteed by Linux kernel
Hojong Han
Reported
2012-02-02 21:28:30 PST
Current MetaAllocator concept, always coalesces adjacent free spaces, doesn't meet memory management of Linux kernel. In a certain case Linux kernel doesn't regard contiguous virtual memory areas as one but two. Let's assume that mmap is called by MetaAllocator three times like below. 1. 8KB allocated from 0x41000000 to 0x41002000 by the 1st mmap call 2. 8KB allocated from 0x41004000 to 0x41006000 by the 2nd mmap call 3. 8KB allocated from 0x41002000 to 0x41004000 by the 3rd mmap call These virtual memory areas(VMAs) above are contiguous from 0x41000000 to 0x41006000, but the kernel merges only the third allocated 8KB with the first allocated 8KB although the second one is adjacent to the third. Because newly allocated VMA can be coalesced with the previously allocated and it's not allowed between previously allocated VMAs which internally have different information about annoymous pages. But current MetaAllocator is not considered on this kernel operation, thereby it just coalesces adjacent spaces when those are freed. This different mergence operation between MetaAllocator and Linux kernel finally causes the problem during cache flush. MetaAllocator hands over coalesced free space that the kernel regards it just as parts of two separated VMAs. The free space, coalesced by MetaAllocator, will be filled with JIT and cache flush will be run before the execution. At that time the flush range of the coalesced space is not guaranteed by kernel. It means inconsistency of data and instruction cache, and nobody knows what happens when this JIT code runs. The bottom line is that routines, handling this kernel operation, is necessary in MetaAllocator.
Attachments
Patch
(3.04 KB, patch)
2012-03-08 22:07 PST
,
Hojong Han
no flags
Details
Formatted Diff
Diff
Patch
(2.68 KB, patch)
2012-03-11 18:05 PDT
,
Hojong Han
no flags
Details
Formatted Diff
Diff
Patch
(2.68 KB, patch)
2012-03-11 18:56 PDT
,
Hojong Han
no flags
Details
Formatted Diff
Diff
Patch
(2.65 KB, patch)
2012-03-12 19:35 PDT
,
Hojong Han
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Hojong Han
Comment 1
2012-03-08 22:07:38 PST
Created
attachment 130982
[details]
Patch
WebKit Review Bot
Comment 2
2012-03-08 22:11:02 PST
Attachment 130982
[details]
did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/JavaScriptCore/ChangeLog', u'Source..." exit_code: 1 Source/JavaScriptCore/jit/ExecutableAllocator.h:202: Extra space before ( in function call [whitespace/parens] [4] Total errors found: 1 in 2 files If any of these errors are false positives, please file a bug against check-webkit-style.
Andy Wingo
Comment 3
2012-03-09 03:30:39 PST
Comment on
attachment 130982
[details]
Patch Is size_t the right type to use for startPage and endPage? It seems safer to use intptr_t or something. Also it seems to me that you would be better off doing uintptr_t start = reinterpret_cast<uintptr_t>(code) & ~(pageSize() - 1); and just adding pageSize() each round instead of doing the divide-and-multiply dance. Dunno. I'm not a reviewer, so please take these comments with a grain of salt.
Hojong Han
Comment 4
2012-03-09 04:14:04 PST
(In reply to
comment #3
)
> (From update of
attachment 130982
[details]
) > Is size_t the right type to use for startPage and endPage? It seems safer to use intptr_t or something. > > Also it seems to me that you would be better off doing > > uintptr_t start = reinterpret_cast<uintptr_t>(code) & ~(pageSize() - 1); > > and just adding pageSize() each round instead of doing the divide-and-multiply dance. Dunno. > > I'm not a reviewer, so please take these comments with a grain of salt.
Thank you. It's really necessary salt for me. I'm going to put it into new patch.
Geoffrey Garen
Comment 5
2012-03-09 12:48:48 PST
Phil, does this mean that munmap will eventually fail as well?
Filip Pizlo
Comment 6
2012-03-09 12:49:57 PST
(In reply to
comment #5
)
> Phil, does this mean that munmap will eventually fail as well?
Nope. We munmap one page at a time.
Hojong Han
Comment 7
2012-03-11 18:05:59 PDT
Created
attachment 131264
[details]
Patch
WebKit Review Bot
Comment 8
2012-03-11 18:07:51 PDT
Attachment 131264
[details]
did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/JavaScriptCore/ChangeLog', u'Source..." exit_code: 1 Source/JavaScriptCore/jit/ExecutableAllocator.h:202: Extra space before ( in function call [whitespace/parens] [4] Total errors found: 1 in 2 files If any of these errors are false positives, please file a bug against check-webkit-style.
Hojong Han
Comment 9
2012-03-11 18:56:28 PDT
Created
attachment 131268
[details]
Patch
WebKit Review Bot
Comment 10
2012-03-11 19:00:06 PDT
Attachment 131268
[details]
did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/JavaScriptCore/ChangeLog', u'Source..." exit_code: 1 Source/JavaScriptCore/jit/ExecutableAllocator.h:202: Extra space before ( in function call [whitespace/parens] [4] Total errors found: 1 in 2 files If any of these errors are false positives, please file a bug against check-webkit-style.
Geoffrey Garen
Comment 11
2012-03-12 11:45:54 PDT
Comment on
attachment 131268
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=131268&action=review
> Source/JavaScriptCore/jit/ExecutableAllocator.h:209 > + current = next;
You can eliminate the "next" variable if you change this line to "current += pageSize()".
> Source/JavaScriptCore/jit/ExecutableAllocator.h:211 > + } while (end >= current);
In C++, "end" traditionally means one-past-the-end. That's not the case here, so I don't think you should use the word "end". I'd suggest "currentPage" and "lastPage" for variable names.
Hojong Han
Comment 12
2012-03-12 19:35:42 PDT
Created
attachment 131496
[details]
Patch
WebKit Review Bot
Comment 13
2012-03-12 19:38:23 PDT
Attachment 131496
[details]
did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/JavaScriptCore/ChangeLog', u'Source..." exit_code: 1 Source/JavaScriptCore/jit/ExecutableAllocator.h:201: Extra space before ( in function call [whitespace/parens] [4] Total errors found: 1 in 2 files If any of these errors are false positives, please file a bug against check-webkit-style.
Hojong Han
Comment 14
2012-03-12 23:59:02 PDT
(In reply to
comment #11
)
> (From update of
attachment 131268
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=131268&action=review
> > > Source/JavaScriptCore/jit/ExecutableAllocator.h:209 > > + current = next; > > You can eliminate the "next" variable if you change this line to "current += pageSize()". > > > Source/JavaScriptCore/jit/ExecutableAllocator.h:211 > > + } while (end >= current); > > In C++, "end" traditionally means one-past-the-end. That's not the case here, so I don't think you should use the word "end". > > I'd suggest "currentPage" and "lastPage" for variable names.
Thanks for your kind comments. I reflect your advice.
Geoffrey Garen
Comment 15
2012-03-14 16:26:12 PDT
Comment on
attachment 131496
[details]
Patch r=me
WebKit Review Bot
Comment 16
2012-03-14 17:06:20 PDT
Comment on
attachment 131496
[details]
Patch Clearing flags on attachment: 131496 Committed
r110792
: <
http://trac.webkit.org/changeset/110792
>
WebKit Review Bot
Comment 17
2012-03-14 17:06:26 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug