Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S942294AbcJFQW5 (ORCPT ); Thu, 6 Oct 2016 12:22:57 -0400 Received: from quartz.orcorp.ca ([184.70.90.242]:59796 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752677AbcJFQWu (ORCPT ); Thu, 6 Oct 2016 12:22:50 -0400 Date: Thu, 6 Oct 2016 10:22:45 -0600 From: Jason Gunthorpe To: Jarkko Sakkinen Cc: "Winkler, Tomas" , "tpmdd-devel@lists.sourceforge.net" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] tpm: don't destroy chip device prematurely Message-ID: <20161006162245.GF1224@obsidianresearch.com> References: <20161002101755.GA25844@intel.com> <20161002102455.GA27464@intel.com> <20161002212126.GA25872@obsidianresearch.com> <5B8DA87D05A7694D9FA63FD143655C1B542F466B@hasmsx108.ger.corp.intel.com> <20161003124836.GE9990@intel.com> <20161004051946.GA10572@intel.com> <20161004164738.GA17149@obsidianresearch.com> <20161005100234.GA20851@intel.com> <20161005162741.GA18636@obsidianresearch.com> <20161006112357.GA10533@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161006112357.GA10533@intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Broken-Reverse-DNS: no host name found for IP address 10.0.0.151 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 800 Lines: 19 On Thu, Oct 06, 2016 at 02:23:57PM +0300, Jarkko Sakkinen wrote: > I think that they should be fenced then for the sake of consistency. > I do not see why sysfs code is privileged not to do fencing while other > peers have to do it. Certainly the locking could be changed, but it would be nice to have a reason other than aesthetics. sysfs is not unique, we also do not grab the rwlock lock during any commands executed as part of probe. There are basically two locking regimes - stuff that is proven to by synchronous with probe/remove (sysfs, probe cmds) and everything else (kapi, cdev) Further, the current sysfs implementation is nice and sane: the file accesses cannot fail with ENODEV. That is a useful concrete property and I don't think we should change it without a good reason. Jason