Race Condition Leading to Panic on call to entry()

[posborne]

I am using lru_time_cache on an embedded Linux system with somewhat limited CPU resources which may exacerbate the problem, but reviewing the code the problem seems to be there regardless.

Here's the code for entry() at present:

    /// Gets the given key's corresponding entry in the map for in-place manipulation.
    pub fn entry(&mut self, key: Key) -> Entry<'_, Key, Value> {
        // We need to do it the ugly way below due to this issue:
        // https://github.com/rust-lang/rfcs/issues/811
        // match self.get_mut(&key) {
        //     Some(value) => Entry::Occupied(OccupiedEntry{value: value}),
        //     None => Entry::Vacant(VacantEntry{key: key, cache: self}),
        // }
        if self.contains_key(&key) {
            Entry::Occupied(OccupiedEntry {
                value: self.get_mut(&key).expect("key not found"),
            })
        } else {
            Entry::Vacant(VacantEntry { key, cache: self })
        }
    }

On a device running code making use of entry() I got a crash report of a crash due to a panic with message "key not found" from a call to entry() on the lru_time_cache for this code.

It seems possible that it could very well be the case that the contains_key could see an unexpired key when it is executed but that when we execute get_mut the new Instant would see that key as expired leading to a crash. The code is incorrect and has a race condition not involving concurrency.

I will try to get the core dump from this crash and update with more insights if applicable. The logic here could be valid if the operations were made into pure functions taking the Instant in rather than fetching it from the system at many different execution locations.