Ok, I'll just assume that Andreas' code will fix this when it gets
committed. Interestingly, valgrind doesn't print an error when compiled
with opt. I'm not quite sure how the compiler is optimizing away the
problem, but it's nice that it is.
Ali
On Tue, 2 Aug 2011 17:02:55 +0100, Andreas Hansson
<[email protected]> wrote:
In essence, yes, a fix is essentially already incorporated in the new
interfaces. This works fine with the new 4-phase semantics since the
first check (markInService happens the same time as the beginReq is
called) and the deletion of the packet is only on the actual "accept"
(endReq) on the other side, which is at least a delta cycle
(potentially longer) later.
Andreas
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Steve Reinhardt
Sent: 02 August 2011 16:58
To: gem5 Developer List
Subject: Re: [gem5-dev] Invalid read after free with caches
Good catch... unfortunately I don't see an easy answer. I believe
that
inside the markInService function, the MSHR code is looking at some
of the
snoop status bits (see
http://repo.m5sim.org/gem5/file/353abb676fa2/src/mem/cache/mshr.cc#l224),
which are set by snoopers after sendTiming() is called. Thus both
setting
the data the code is looking at and deleting the packet happens after
the
call to sendTIming() but before the return.
The only solutions I see are to either (1) change the allocation
protocol
that says the target can delete the packet or (2) somehow separate
the snoop
status bits from the packet so they can have a different lifetime.
Either
of these would be a pretty major change.
Can we find a way to incorporate a fix into Andreas's new port
interface?
Since we already have a pretty major overhaul in sight, maybe the
best
solution might be to live with this for now (assuming it empirically
isn't
causing any actual problems) and just make sure we take care of it
then.
Steve
On Tue, Aug 2, 2011 at 8:03 AM, Ali Saidi <[email protected]> wrote:
I can't really come up with a solution I like to this problem. If I
don't
delete the packet in the down stream cache and put a hack in to
delete it in
the upstream cache that seems like a hack and violates the principle
that
the recipient is responsible for the packet. I could copy the packet
in the
sending cache and feed that into the markInService function, but I
don't
like that either.
Suggestions?
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the
intended recipient, please notify the sender immediately and do not
disclose the contents to any other person, use it for any purpose, or
store or copy the information in any medium. Thank you.
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
