lkml.org 
[lkml]   [2023]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: Converting dev->mutex into dev->spinlock ?
    On Sat, Feb 4, 2023 at 12:01 PM Alan Stern <stern@rowland.harvard.edu> wrote:
    >
    > I'm sorry, but that simply is not feasible. It doesn't matter how much
    > you want to do it or feel it is needed; there is no reasonable way to do
    > it. To take just one example, what you are saying implies that when a
    > driver is probed for a device, it would not be allowed to register a
    > child device. That's a ridiculous restriction.

    Well, we've worked around that in other places by making the lockdep
    classes for different locks of the same type be different.

    So this *could* possibly be solved by lockdep being smarter about
    dev->mutex than just "disable checking entirely".

    So maybe the lock_set_novalidate_class() could be something better. It
    _is_ kind of disgusting.

    That said, maybe people tried to subclass the locks and failed, and
    that "no validation" is the best that can be done.

    But other areas *do* end up spending extra effort to separate out the
    locks (and the different uses of the locks), and I think the
    dev->mutex is one of the few cases that just gives up and says "no
    validation at all".

    The other case seems to be the md bcache code.

    Linus

    \
     
     \ /
      Last update: 2023-03-27 00:10    [W:4.698 / U:0.148 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site