mem: Unify delayed packet deletion

This patch unifies how we deal with delayed packet deletion, where the
receiving slave is responsible for deleting the packet, but the
sending agent (e.g. a cache) is still relying on the pointer until the
call to sendTimingReq completes. Previously we used a mix of a
deletion vector and a construct using unique_ptr. With this patch we
ensure all slaves use the latter approach.

1 files changed, 2 insertions, 10 deletions

diff --git a/src/mem/tport.cc b/src/mem/tport.cc
index aa783ada0..9f9403a22 100644
--- a/src/mem/tport.cc
+++ b/src/mem/tport.cc
@@ -62,12 +62,6 @@ SimpleTimingPort::recvFunctional(PacketPtr pkt)
 bool
 SimpleTimingPort::recvTimingReq(PacketPtr pkt)
 {
-    /// @todo temporary hack to deal with memory corruption issue until
-    /// 4-phase transactions are complete. Remove me later
-    for (int x = 0; x < pendingDelete.size(); x++)
-        delete pendingDelete[x];
-    pendingDelete.clear();
-
     // the SimpleTimingPort should not be used anywhere where there is
     // a need to deal with inhibited packets
     if (pkt->memInhibitAsserted())
@@ -82,10 +76,8 @@ SimpleTimingPort::recvTimingReq(PacketPtr pkt)
         assert(pkt->isResponse());
         schedTimingResp(pkt, curTick() + latency);
     } else {
-        /// @todo nominally we should just delete the packet here.
-        /// Until 4-phase stuff we can't because the sending
-        /// cache is still relying on it
-        pendingDelete.push_back(pkt);
+        // queue the packet for deletion
+        pendingDelete.reset(pkt);
     }
 
     return true;