On Mon, Sep 14, 2026, Sohil Mehta wrote: > > Yes, this could be a matter of taste as taking and going to maintain the > > code. But as a reader looking at this, the logic was not that easy to > > capture at a high level. > > > > At first look, I found it a bit hard to follow as well. But instead of > splitting out the logic into 4 static functions (which have limited > value to the rest of the file), how about we add a high level comment on > top of the function?
This is a great idea! > I'll let Sean comment whether he prefers to change anything here or > leave it as-is. > > Note, some function names in the proposed diff could be misleading. For > example, is_user_mode() checks the IMPLICIT flag in addition to the CPL > which feels odd. And, is_lass_enforced() seems like a generic LASS check > but in reality it only covers the supervisor data rule. Yeah, this is my thinking as well. In most cases, I would agree that we should make the high-level concept as easy to follow as possible. But helpers like these, and even is_user_address() vs. is_supervisor_address(), highlight why I think we should keep the more open-coded version in this particular case. IMO, the control flow isn't hard to follow because of poor coding/design, it's hard to follow because the actual behavior of the CPU is complex and subtle. So for me, this is more of a feature, not a bug. I.e. I *want* to force readers to slow down a bit, because while the basic gist is indeed very straightforward, I think the resulting code is actively misleading if we bury the complexity and subtlety in helpers. That said, I love Sohil's idea of adding a function comment. Someting along the lines of "The basic flow is this: <example>, but the actual behavior is far more subtle due to many exceptions and edge cases".
