[New-bugs-announce] [issue44240] Incorrect behavior of LOAD_ATTR due to overflow in tp_version

[Mark Shannon]

New submission from Mark Shannon <mark at hotpy.org>:

Should the tp_version overflow, and wrap around to a value previously used in the opcache for LOAD_ATTR, then LOAD_ATTR could produce the wrong value.

It will take a fair bit of contrivance and a long time to do this, but it is possible:
Run some code ~2000 times to get the version cached.
Change an attibute of the type about 4 billion times.
Rerun the original code.



Invalidating all the opcaches is going to be a huge pain, so I propose not allowing the version to overflow but partitioning the 32 bit space something like this:

Top 20 bits: Unique per-class ID, 0 and 0xFFFFF are reserved.
Low 12 bits: Per-class version.

tp_version == 0 that no version has been assigned to this class, as yet.
(tp_version & 0xFFF) == 0 means that the version tag is temporarily invalid
tp_version == 0xFFFFFFFF means that the version tag is permanently invalid

If (tp_version & 0xFFF) != 0 and tp_version != 0xFFFFFFFF, then the combined 32 bits represents a unique tag of the class's state as it does now.

Should the low bits of a class hit 0xFFF then all 32 bits are set to 0xFFFFFFFF, and we can't cache its version any more.
If a class has been changed a 1000 times, then there is unlikely to be much value in caching it anyway.

----------
components: Interpreter Core
messages: 394442
nosy: Mark.Shannon, pablogsal
priority: normal
severity: normal
stage: needs patch
status: open
title: Incorrect behavior of LOAD_ATTR  due to overflow in tp_version
type: behavior
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44240>
_______________________________________