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
