On Mon, 2021-09-27 at 14:34 -0700, Tony Luck wrote: > A memory controller patrol scrubber can report poison in a page > that isn't currently being used. > > Add "poison" field in the sgx_epc_page that can be set for an > sgx_epc_page. Check for it: > 1) When sanitizing dirty pages > 2) When freeing epc pages > > Poison is a new field separated from flags to avoid having to make > all updates to flags atomic, or integrate poison state changes into > some other locking scheme to protect flags. > > In both cases place the poisoned page on a list of poisoned epc pages > to make sure it will not be reallocated. > > Add debugfs files /sys/kernel/debug/sgx/poison_page_list so that system > administrators get a list of those pages that have been dropped because > of poison. So, what would a sysadmin do with that detailed information? I would decrease the granularity a bit rather add something like this for each node: /sys/devices/system/node/node[0-9]*/sgx/poisoned_size which would give the total amount of poisoned memory in bytes for that node. See the series that I've recently posted: https://lore.kernel.org/linux-sgx/20210914030422.377601-1-jarkko@xxxxxxxxxx/T/#t /Jarkko
