Re: Determine if driver is reentrant

From: Kasper Dupont (kasperd_at_daimi.au.dk)
Date: 05/08/05

  • Next message: Kasper Dupont: "Re: Determine if driver is reentrant" 
    Date: Sun, 08 May 2005 20:16:45 +0200

    kwendex@yahoo.com wrote:
    >
    > The kernel is 2.4, the machine is has two CPUs and I've inherited a
    > network driver and the current question is whether the driver could,
    > possibly, be reentrant in any fashion - in other words, might a thread
    > of execution enter the driver at any time while another thread is also
    > in it?

    In general kernel code must be reentrant. There is a lot
    of locks spread all over the kernel, and even they even
    come in different kinds, which are not always substitutable.

    In a few parts of the kernel code, you don't need to worry
    about locks because some higher layer handle that for you.
    In the case of networking code I don't exactly which parts
    of the code must take care of locking, my best advice is to
    look on existing code to find out where the locking happens.
    And it is probably a good idea to look on more than one of
    the existing drivers.

    >
    > My understanding of the 2.4 kernel is that it's single threaded

    That is completely wrong. Linux was always multi threaded.
    (Did you forget to read up on the historical Tanenbaum vs.
    Linus thread?)

    > - and therefore non-preemptive.

    Preemptive is something completely different. The change
    happening somewhere in 2.5 was that threads could now be
    preempted while in kernle mode. Since giving up the CPU
    without beeing preempted happens all the time, even on a
    single CPU system you have to care about preemption. Even
    more so on a multip CPU system where multilpe threads on
    different CPUs can access the same data structures without
    ever giving up the CPU.

    > One might reason, then, that any code running
    > in kernel mode (and therefore any driver) will not need to be safe for
    > reentrancy;

    To some extent that was true about the first Linux versions
    with SMP support. But a lot have happened since then. You
    don't get good performance from the coarse-grained locking
    used when Linux was first used on SMP systems. A lot has
    changed since then.

    > but I'm also unsure if it's possible for a driver to
    > explicitly set itself up to yield one thread and let another thread
    > enter it (why this would happen, I don't know; but I'm just covering my
    > bases).

    Are you familiar with the difference between drivers,
    modules and threads? (Some newbies think they are the same.)

    > I'm also vaguely aware of the concept of softirqs (I believe
    > it's a deferred procedure from an IRQ handler),

    That even confuses me. This part of the kernel has been
    changed a few times since 2.2.

    > and that code within
    > the driver could, potentially execute under this mechanism which, I
    > believe, may be ran by the softirq daemon process

    I guess you are right about that. Processing packets
    received from the network is a task I believe belongs
    in a softirq.

    > which is in user mode

    No.

    > (and potentially preemptable?).

    Probably it is, but I'm not sure. I'm pretty sure a
    softirq can be interrupted, otherwise there wouldn't
    be much point in softirqs. And I can't think of much
    reason for it not to be preemptable. 

    -- 
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.
  • Next message: Kasper Dupont: "Re: Determine if driver is reentrant"

    Relevant Pages