On 9/28/22 04:28, Suren Baghdasaryan wrote: > On Sun, Sep 11, 2022 at 2:35 AM Vlastimil Babka <vbabka@xxxxxxx> wrote: >> >> On 9/2/22 01:26, Suren Baghdasaryan wrote: >> > >> >> >> >> Two complaints so far: >> >> - I don't like the vma_mark_locked() name. To me it says that the caller >> >> already took or is taking the lock and this function is just marking that >> >> we're holding the lock, but it's really taking a different type of lock. But >> >> this function can block, it really is taking a lock, so it should say that. >> >> >> >> This is AFAIK a new concept, not sure I'm going to have anything good either, >> >> but perhaps vma_lock_multiple()? >> > >> > I'm open to name suggestions but vma_lock_multiple() is a bit >> > confusing to me. Will wait for more suggestions. >> >> Well, it does act like a vma_write_lock(), no? So why not that name. The >> checking function for it is even called vma_assert_write_locked(). >> >> We just don't provide a single vma_write_unlock(), but a >> vma_mark_unlocked_all(), that could be instead named e.g. >> vma_write_unlock_all(). >> But it's called on a mm, so maybe e.g. mm_vma_write_unlock_all()? > > Thank you for your suggestions, Vlastimil! vma_write_lock() sounds > good to me. For vma_mark_unlocked_all() replacement, I would prefer > vma_write_unlock_all() which keeps the vma_write_XXX naming pattern to OK. > indicate that these are operating on the same locks. If the fact that > it accepts mm_struct as a parameter is an issue then maybe > vma_write_unlock_mm() ? Sounds good! >> >>
