> This series seems like a valid approach to me if we still want to > respect the locking. And I am leaning to that it is good enough. I think pragmatism is OK here: The users who want this feature simply want to reboot their system, mostly development systems. They can't reboot otherwise. Except for the HW switch they are currently using anyhow. The panic fault-injector can create an inconsistent situation on the I2C bus when you want to reboot after an OOPS while a transfer was in progress. However, if rebooting in such scenarios is critical for you, you a) shouldn't reboot via I2C, and/or b) should have a watchdog in place. We can't guarantee to always fix this sitution. At best, we could just try to be better for some cases. However, this would mean having a backdoor to skip the locking scheme which doesn't sound right. Maybe just accepting the deadlock is not too bad because it will reliably point out a design flaw of the system (hopefully during the development stage)? Final call for other thoughts/comments. PS: I am still interested in the use of in_atomic() here. I wonder if it is correct. If a change is needed, it should probably be a seperate series, though.
Attachment:
signature.asc
Description: PGP signature
