kern/47114: it's too easy to misspell `mutex_owned' as `mutex_owner'

[Taylor R Campbell <campbell+netbsd%mumble.net@localhost>]

>Number:         47114
>Category:       kern
>Synopsis:       it's too easy to misspell `mutex_owned' as `mutex_owner'
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Oct 23 20:10:00 +0000 2012
>Originator:     Taylor R Campbell <campbell+netbsd%mumble.net@localhost>
>Release:        NetBSD 6.99.14
>Organization:
>Environment:
Architecture: any
Machine: any
>Description:

        mutex_owned(m) tells whether curlwp owns m.  mutex_owner(m)
        asks for some thread that recently owned m, if any.  Kasserting
        mutex_owned is sensible; kasserting mutex_owner is not.  But we
        have several kasserts of mutex_owner:

sys/arch/mips/include/pmap.h:#define        PG_MD_PVLIST_LOCKED_P(md)       
(mutex_owner((md)->pvh_lock) != 0)
sys/dev/ieee1394/fwohci.c:  KASSERT(mutex_owner(&sc->fc.fc_mtx));
sys/ufs/ufs/ufs_quota2.c:   KASSERT(mutex_owner(&dqlock));
sys/uvm/pmap/vmpagemd.h:    mutex_owner((mdpg)->mdpg_lock)

        (The first and last are not directly in kasserts, but rather in
        macros used only in kasserts.)

        These should probably all be mutex_owned, but I'm very nervous
        about touching these parts of the system which I have no way to
        test at the moment, especially since that would point blame at
        me for causing breakage if it turned out that there are locking
        issues there which changing mutex_owned to mutex_owner might
        reveal...

>How-To-Repeat:

        Advanced code analysis tools (sometimes known as `grep').

>Fix:

        Yes, please!  And maybe we should rename one or the other so
        that it is not as easy to confound the two.