From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758251Ab0KOUhU (ORCPT ); Mon, 15 Nov 2010 15:37:20 -0500 Received: from moutng.kundenserver.de ([212.227.126.187]:60396 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751556Ab0KOUhT (ORCPT ); Mon, 15 Nov 2010 15:37:19 -0500 Message-ID: <4CE19A08.8050606@vlnb.net> Date: Mon, 15 Nov 2010 23:37:28 +0300 From: Vladislav Bolkhovitin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Thunderbird/3.0.5 MIME-Version: 1.0 To: Dmitry Torokhov CC: Boaz Harrosh , Greg KH , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, scst-devel , James Bottomley , Andrew Morton , FUJITA Tomonori , Mike Christie , Vu Pham , Bart Van Assche , James Smart , Joe Eykholt , Andy Yan , Chetan Loke , Hannes Reinecke , Richard Sharpe , Daniel Henrique Debonzi Subject: Re: [PATCH 8/19]: SCST SYSFS interface implementation References: <20101022185437.GA9103@kroah.com> <4CD8566D.1020202@vlnb.net> <20101109002829.GA22633@kroah.com> <4CD9A9B8.70708@vlnb.net> <4CDA6CD4.3010308@panasas.com> <4CDAFE6E.7050200@vlnb.net> <4CDBBE80.40908@panasas.com> <4CDC56F9.9040601@vlnb.net> <20101112012315.GE17097@core.coreip.homeip.net> <4CDEC8D2.8080101@vlnb.net> <20101115070436.GC14442@core.coreip.homeip.net> In-Reply-To: <20101115070436.GC14442@core.coreip.homeip.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:wVJjnNFpP1IPAcLIaW1XxMOU0gl0JUrfagq7pkUvXUN Tdc4LyInB1vk7N6ATexn4uHAMP1XbfEUrvShXv1xQnt4cTuFWn W5uEDuHZ3OCe7BCJVVtSHJe/k/IvgeYtR4sOFufkx1F0VCZFgi U/2fYVVlajGnlILTnGs/+jPK9yMLMAV1FWm0aaHLb1t0eR5tX6 tZpt8OS5PlDsaVATp6A3g== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dmitry Torokhov, on 11/15/2010 10:04 AM wrote: >> 1. What to do if another SCST object is being created with the same name >> as supposed to be deleted, but not completely dead yet? > > The same rules as with files - the object disappears from the > "directories" so no new users can get it but is not destroyed till last > reference is gone. > >> >> 2. What to do if a dieing object is found on some list and reference for >> is supposed to be taken? If the object deleted from the list before it >> marked dieing, i.e. the latest internal put() done, it made additional >> problems during deleting it after the latest external put done. > > You delete the object from the list, then mark it as dead, notify users, > drop refcount. No new users will get it (as it is not on the list > anymore) and existing ones should notice that it is dead and stop using > it. Those are good in theory, but on practice, you know, devil is in the details.. >> This is because SYSFS doesn't hold references for the corresponding >> kobjects for every open file handle. It holds references only when >> show() and store() functions called. So, everything is under control and >> a malicious user can do nothing to hold a reference forever. > > Right, Tejun plugged this particular (and very annoying) attributes > behavior This behavior isn't annoying, it's GREAT, because it allows to use SYSFS simply and reliably. >, but that does not mean that this is the only way kobject's > reference might be pinned. Could you be more specific and point out on exact ways for that? From my quite deep SYSFS source code study I see such cases should not exist. Thanks, Vlad