lkml.org 
[lkml]   [2002]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: BKL removal
    Date

    > > "up" is a local variable. There is no point in protecting its
    > > allocation. If the goal is to protect data inside "up", there should
    > > probably be a subsystem-level lock for all "struct uhci_hcd"s or a
    > > lock contained inside of the structure itself. Is this the kind of
    > > example you're looking for?
    >
    > So the BKL isn't wrong here, but incorrectly used?

    The BKL, unless used unbalanced, can never cause a bug.
    It could be insufficient or superfluous, but never be really buggy in itself.

    > Is it really okay to "lock the whole kernel" because of one struct file?
    > This brings us back to spinlocks...
    >
    > You're possibly right about this one. What did Greg K-H say?

    I don't speak for Greg, but in this example it could be dropped IMO.
    The spinlock protects the critical section anyway. As a rule, if you
    do a kmalloc without GFP_ATOMIC under BKL you are doing either insufficient
    locking (you may need a semaphore) or useless locking.

    This should have been posted on linux-usb long ago.

    Regards
    Oliver

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:22    [W:0.025 / U:33.332 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site