Dear Dan & Dmitry,
Thanks for pointing out the security vulnerability in the fix and for
your precise review. I am also agree with Dmitry's fix. I will fix the
code and resend the review request.
Regards,
Cheleswer
On 5/14/2015 9:46 PM, Gerald Thornbrugh wrote:
Hi Dan,
When Cheleswer and I
Peter,
Thank you for the explanation!
-Dmitry
On 2015-05-14 23:35, Peter Levart wrote:
>
>
> On 05/14/2015 10:11 PM, Peter Levart wrote:
>> Hi Dmitry,
>>
>> ReferenceQueue is not really a queue, but a LIFO stack. Scanner is
>> walking the stack from top (the 'head') to bottom (the last element
Please, review the jdk 9 fix for:
https://bugs.openjdk.java.net/browse/JDK-8079644
9 hotspot webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8079644-JVMTI-memstomp.1
Summary:
The cached class file structure must be deallocated instead of the
cached class file bytes.
I
On 05/14/2015 10:11 PM, Peter Levart wrote:
Hi Dmitry,
ReferenceQueue is not really a queue, but a LIFO stack. Scanner is
walking the stack from top (the 'head') to bottom (the last element
pointing to itself). When poller(s) overtake the scanner, it actually
means that the top of the stack
Hi Dmitry,
ReferenceQueue is not really a queue, but a LIFO stack. Scanner is
walking the stack from top (the 'head') to bottom (the last element
pointing to itself). When poller(s) overtake the scanner, it actually
means that the top of the stack has been eaten under scanner's feet
while try
Peter,
Could we just bail out on r == r.next?
It gives us less accurate result, but I suspect that If we restart from
head we need to flush all counters.
As far I understand queue poller removes items one by one from a queue
end so if we overtaken by queue poller we can safely assume that
we are
Hi Dan,
When Cheleswer and I discussed this fix my interpretation had a slightly
different goal:
Prior to the initial security fix any user could execute "jps" and get the user
names associated
with other user's perf data (i.e. the call to get_user_name_slow() would
succeed.). My initial
thoug
https://bugs.openjdk.java.net/browse/JDK-8080345
On Wed, May 13, 2015 at 1:08 PM, Srinivas Ramakrishna
wrote:
>
> With perm gen going away (and being replaced by metaspace) in JDK 8, it
> makes sense that the counter
> sun.gc.policy.generations should be "2", rather than "3". However, in JDK
>
On 5/14/15 3:34 AM, cheleswer sahu wrote:
Hi,
Please review the code changes for
https://bugs.openjdk.java.net/browse/JDK-8075773. I have built and
tested JDK9 with fix successfully. As I do not have an account for
OpenJDK,
David Buck will push the fix into jdk9/hs-rt/.
Web review link: http
On 13.5.2015 21:14, Martin Buchholz wrote:
David has given you an approval; feel free to ignore me!
I tried running the test against jdk9, but it timed out!
... and it did print nice messages, didn't it? ;) I managed to leave in
a piece of code I used for testing the error messages. Sorry abo
On 14.5.2015 03:57, David Holmes wrote:
On 13/05/2015 9:46 PM, Jaroslav Bachorik wrote:
On 1.5.2015 21:55, Martin Buchholz wrote:
On Thu, Apr 30, 2015 at 11:27 AM, Jaroslav Bachorik
mailto:jaroslav.bacho...@oracle.com>>
wrote:
On 30.4.2015 19:18, Martin Buchholz wrote:
Tests tha
Cheleswer,
I would recommend to simple change
ll. 222 of original code to
uid_t euid = geteuid();
if (euid != 0 && statp->st_uid != euid) {
return false;
}
-Dmitry
On 2015-05-14 12:26, cheleswer sahu wrote:
> Hi,
> Please review the code changes for
> https://bugs.openjdk.java.net/browse/JD
Hi,
Please review the code changes for
https://bugs.openjdk.java.net/browse/JDK-8075773. I have built and tested JDK9
with fix successfully. As I do not have an account for OpenJDK,
David Buck will push the fix into jdk9/hs-rt/.
Web review link: http://cr.openjdk.java.net/~dbuck/8075773/webrev.
Hi,
Please review the code changes for
https://bugs.openjdk.java.net/browse/JDK-8075773. I have built and tested JDK9
with fix successfully. As I do not have an account for OpenJDK,
David Buck will push the fix into jdk9/hs-rt/.
Web review link: http://cr.openjdk.java.net/~dbuck/8075773/webrev.
I also have some comments on Dmitry's code...
On 05/13/2015 11:52 PM, Derek White wrote:
Hi Dmitry,
Some review comments below...
On 5/12/15 1:10 PM, Dmitry Samersoff wrote:
Everybody,
Updated version:
http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.03/
Now it iterates over queue
Hi Derek,
On 05/13/2015 10:34 PM, Derek White wrote:
Hi Peter,
I don't have smoking gun evidence that your change introduces a bug,
but I have some concerns...
I did have a concern too, ...
On 5/12/15 6:05 PM, Peter Levart wrote:
Hi Dmitry,
You iterate the queue then, not the unfinalize
16 matches
Mail list logo
