On 5/26/24 20:10, Huang, Ying wrote: >> Thank you for the pointing out. I will fix it too by introducing a new >> flag in inode or something to make LUF aware if updating the file has >> been tried so that LUF can give up and flush right away in the case. >> >> Plus, I will add another give-up at code changing the permission of vma >> to writable. > I guess that you need a framework similar as > "flush_tlb_batched_pending()" to deal with interaction with other TLB > related operations. Where "other TLB related operations" includes both things that traditionally invalidate TLBs (like going Present 1=>0) and things like fault-in that go Present 0=>1 that can result in TLB population. It's actually a really crummy problem to solve. We don't have _any_ machinery to say, "Hey, you know that PTE you wanted to install? There was something there before you and we haven't flushed it yet. Can you be a doll and do a flush before _populating_ that PTE?" To solve it generically, I suspect you'll need some kind of special non-present PTE to say: There _was_ a PTE here that wasn't flushed. Sure, you can add gunk to the VMA to track when this happens. But that'll penalize anyone populating a PTE anywhere in the VMA at least once. If there were other threads faulting in pages to the same VMA, they'll just end up doing the flush that LUF tried to avoid in the first place.
