Re: klists and struct device semaphores

From: Patrick Mochel (mochel_at_digitalimplant.org)
Date: 03/29/05

  • Next message: Horst von Brand: "2.6.12-rc1 from bk today: Build failure on i386" 
    Date:	Tue, 29 Mar 2005 08:38:11 -0800 (PST)
To: Alan Stern <stern@rowland.harvard.edu>

    On Mon, 28 Mar 2005, Alan Stern wrote:

    > On Mon, 28 Mar 2005, Patrick Mochel wrote:

    > > Do you have suggestions about an alternative (with code)?
    >
    > Here's something a little better than pseudocode but not as good as a
    > patch... :-)

    > To fill the first field in correctly requires that klist creation use a
    > macro; the details are unimportant. What is important is that during
    > klist_node_init you add:

    In principle, you're right. Kind of. We need to tie the "usage" reference
    count of the klist_node to the containing objects' "lifetime" count. But,
    there is no need to confuscate the klist code to do it. At least not at
    this point.

    The subsystems that use the code must be sure to appropriately manage the
    lifetime rules of the containing objects. That is true no matter what.
    When they add a node, they should increment the reference count of the
    containing object and decrement when the node is removed. If practice
    shows that there is more that can be rolled into the model, then we can
    revisit it later.

    [ Sidebar: Perhaps we can add a callback parameter to klist_remove() to
    call when the node has been removed, instead of the struct completion. ]

            Pat
    -
    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/

  • Next message: Horst von Brand: "2.6.12-rc1 from bk today: Build failure on i386"

    Relevant Pages

    • Re: [patch 08/28] Input: prepare to sysfs integration
      ... > in the handlers, too, which means they have to share the lifetime rules ... I wanted to get basic sysfs support in and then work on locking... ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: "deadlock" between smc91x driver and link_watch
      ... without locks now. ... I introduced the smc_phy_configure_wqwrapper for the workqueue call ... * reference and then do the configuration. ... 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/ ...
      (Linux-Kernel)
    • Freeing skbuff (was: Re: Sending built-by-hand packet and kernel panic.)
      ... Thanks a lot for pointing out these problems. ... As far as my investigations ... >case it is wrong to reference them via sk. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • BUG in writeback_inodes()?
      ... Have a look at this 2 call chains: ... __put_superreturns 0 then no super block was deleted from the list ... The last reference will be dropped in point Z. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: "deadlock" between smc91x driver and link_watch
      ... On Wed, 2004-11-24 at 01:46 -0800, Andrew Morton wrote: ... > may still be a tiny bit racy against module unload. ... * reference and then do the configuration. ... 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/ ...
      (Linux-Kernel)