use cycle detection when parsing the prink log_buf
    
    Resolves: bz2069200
    Upstream: github.com/makedumpfile/makedumpfile.git
    Conflicts: None
    
    commit 68d120b30af5e930afafed81e79712af3c1a278c
    Author: Philipp Rudo <prudo@redhat.com>
    Date:   Mon Mar 14 17:04:31 2022 +0100
    
        [PATCH v2 3/3] use cycle detection when parsing the prink log_buf
    
        The old printk mechanism (> v3.5.0 and < v5.10.0) had a fixed size
        buffer (log_buf) that contains all messages. The location for the next
        message is stored in log_next_idx. In case the log_buf runs full
        log_next_idx wraps around and starts overwriting old messages at the
        beginning of the buffer. The wraparound is denoted by a message with
        msg->len == 0.
    
        Following the behavior described above blindly in makedumpfile is
        dangerous as e.g. a memory corruption could overwrite (parts of) the
        log_buf. If the corruption adds a message with msg->len == 0 this leads
        to an endless loop when dumping the dmesg with makedumpfile appending
        the messages up to the corruption over and over again to the output file
        until file system is full. Fix this by using cycle detection and aboard
        once one is detected.
    
        While at it also verify that the index is within the log_buf and thus
        guard against corruptions with msg->len != 0.
    
        Reported-by: Audra Mitchell <aubaker@redhat.com>
        Suggested-by: Dave Wysochanski <dwysocha@redhat.com>
        Signed-off-by: Philipp Rudo <prudo@redhat.com>
        Reviewed-and-tested-by: Dave Wysochanski <dwysocha@redhat.com>
    
    Signed-off-by: Philipp Rudo <prudo@redhat.com>