From d9ff3745d01e30f3addbb51e391b8b5d456d07a4 Mon Sep 17 00:00:00 2001
From: llzmb <46303940+llzmb@users.noreply.github.com>
Date: Tue, 23 Nov 2021 18:58:36 +0100
Subject: [PATCH] Edit "README.persistent_mode.md"

---
 instrumentation/README.persistent_mode.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/instrumentation/README.persistent_mode.md b/instrumentation/README.persistent_mode.md
index efe64a37..e9d2a523 100644
--- a/instrumentation/README.persistent_mode.md
+++ b/instrumentation/README.persistent_mode.md
@@ -155,14 +155,14 @@ and going much higher increases the likelihood of hiccups without giving you any
 real performance benefits.
 
 A more detailed template is shown in
-[utils/persistent_mode](../utils/persistent_mode). Similarly to the previous
-mode, the feature works only with afl-clang-fast; `#ifdef` guards can be used to
-suppress it when using other compilers.
+[utils/persistent_mode](../utils/persistent_mode). Similarly to the deferred
+initialization, the feature works only with afl-clang-fast; `#ifdef` guards can
+be used to suppress it when using other compilers.
 
-Note that as with the previous mode, the feature is easy to misuse; if you do
-not fully reset the critical state, you may end up with false positives or waste
-a whole lot of CPU power doing nothing useful at all. Be particularly wary of
-memory leaks and of the state of file descriptors.
+Note that as with the deferred initialization, the feature is easy to misuse; if
+you do not fully reset the critical state, you may end up with false positives
+or waste a whole lot of CPU power doing nothing useful at all. Be particularly
+wary of memory leaks and of the state of file descriptors.
 
 PS. Because there are task switches still involved, the mode isn't as fast as
 "pure" in-process fuzzing offered, say, by LLVM's LibFuzzer; but it is a lot