lkml.org 
[lkml]   [2000]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Locking Between User Context and Soft IRQs in 2.4.0
    Andi Kleen wrote:
    >
    > On Sat, Nov 04, 2000 at 04:45:33AM -0500, Jeff Garzik wrote:
    > >
    > > > * What about dev->open and dev->stop ?
    > >
    > > Sleep all you want, we'll leave the light on for ya.
    >
    > ... but make sure you have no module unload races (or at least not too
    > huge holes, some are probably unavoidable with the current network
    > driver interface, e.g. without moving module count management a bit up).
    > This means you should do MOD_INC_USE_COUNT very early at least to
    > minimize the windows (and DEC_USE_COUNT very late)

    Can you provide a trace of a race or deadlock? I do not see where there
    are races in the current 2.4.x code.


    > > dev->do_ioctl:
    > > Locking: Inside rtnl_lock() semaphore.
    > > Sleeping: OK
    >
    > Just make sure you lock against your interrupt and xmit threads.

    But of course :) My doc only covered locks external to the driver.


    > > Locking: Inside dev->xmit_lock spinlock.
    > > Sleeping: NO[1]
    > >
    > >
    > > NOTE [1]: On principle, you should not sleep when a spinlock is held.
    > > However, since this spinlock is per-net-device, we only block ourselves
    > > if we sleep, so the effect is mitigated.
    >
    > Sounds like dangerous advice.

    Probably... I changed the doc "just say no" :)

    Jeff


    --
    Jeff Garzik | Dinner is ready when
    Building 1024 | the smoke alarm goes off.
    MandrakeSoft | -/usr/games/fortune
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:45    [W:3.903 / U:0.184 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site