From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754517AbZHKM4q (ORCPT ); Tue, 11 Aug 2009 08:56:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751395AbZHKM4q (ORCPT ); Tue, 11 Aug 2009 08:56:46 -0400 Received: from an-out-0708.google.com ([209.85.132.250]:43851 "EHLO an-out-0708.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750890AbZHKM4p convert rfc822-to-8bit (ORCPT ); Tue, 11 Aug 2009 08:56:45 -0400 MIME-Version: 1.0 In-Reply-To: References: <20090808034817.GA30697@suse.de> From: Kay Sievers Date: Tue, 11 Aug 2009 14:56:28 +0200 Message-ID: Subject: Re: [ofa-general] IB kernel modules and the kobject release() method To: Roland Dreier Cc: Greg KH , Bart Van Assche , OpenIB , LKML Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 10, 2009 at 22:33, Roland Dreier wrote: > >  > No, it still makes sense :) > > So what's the fix for this? The fix is not to embed any kobject/struct device into an object whose lifetime is not controlled by the kobject. The kobject should just be a pointer then, and not inlined in the same memory the object uses, which needs the kobject. The entire kobject embedding/release logic works only properly if the kobject can own/control the lifetime of the enclosing object - if not, it should just not be embedded. > If even you have trouble understanding > kobject lifetimes I don't think we have trouble understanding that, but we are hopelessly lost running after people who "optimize" the use of kobjects/struct device to save an allocation or a separate dynamic object. > and the requirement for a release function, is there > hope for anyone else? Almost all uses where kobjects/struct device are statically allocated, an object embeds more than a single kobject, or the embedded kobject does not control the lifetime of the enclosing object, is just a mis-use of kobjects. Not sure, maybe it needs a simpler API to use non-embedded kobjects, to make it easier to reach the originating object from the kobject. That might not be obvious how to do that in some cases. Kay