Multithreading and multiple processes could cause issues

[Falcosc]

How to reproduce it:

• limit CPU to 400Mhz to slow things down
• execute multiple tools which are talking to MP1 with 10 calls / second
  • ryzenAdj via lib with 10 calls / second
  • HWiNFO with 10 calls / second
  • some manually executed ryzenAdj CLI calls

Because we don't check if it is ok to clear the response register and if it is ok to write argument registers, this will lead into problems.
Normally, we don't see them because:

• some commands don't need any arguments (0% chance of issue on argument overwrite)
• some commands only check 1st argument (16.6% chance of issue on argument overwrite)
• we check the response register very fast by doing a loop without additional operations (nearly impossible that something did clear the response register before we did read it and even if something was faster than our code, if the 2nd command does return OK as well, we don't see any problem)

I could find on issue after 1000's of calls: https://github.com/FlyGoat/RyzenAdj/blob/master/lib/nb_smu_ops.c#L51

• argument register was cleared between writing it and reading it
• error messages "PCI Bus is not writable, check secure boot" was triggered
• this cannot be prevented because we already don't do additional commands between write and read

@FlyGoat what do you think about this? I would say this isn't an issue because it is very unlikely to happen. But I am still not sure if it is good to clear the response register without checking anything else. But I don't know how this low-level stuff should be handled correctly. You will know it much better than me :)
I am not sure how you should handle concurrency on register level without knowing how the other tools do it. In best-case anybody could agree to a register which shows anybody else that the component is currently busy.

It doesn't help if we implement locking like the tools from @irusanov because locking does only help if anybody uses the same lock (don't mix tools)

The commit b32ad89 from pull request #137 does already solve 99% of the issues because only transfer table is likely to be executed so often, and it is very effective. I did use this solution to test, that's why I needed to include the 3rd step "some manually executed ryzenAdj CLI calls" to trigger an issue because with our skip PSMU call solution we don't cause register overwrites anymore.

[FlyGoat]

Just tell users not to do so.
Actually we don't have any possible solution....

[Falcosc]

@sbski told about a lock on PCI config space. I'm not aware that such an extreme kind of lock is even possible. He told me that 1usmus does use this kind of lock.

I would like to know if this kind of lock could hurt something else before we use it to fix something which only very rarely occur (if at all)
I'm still not convinced that this lock is even a thing ;)