From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752552AbdASM2s (ORCPT ); Thu, 19 Jan 2017 07:28:48 -0500 Received: from mga11.intel.com ([192.55.52.93]:43040 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752434AbdASM2p (ORCPT ); Thu, 19 Jan 2017 07:28:45 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,254,1477983600"; d="scan'208";a="1114957393" Date: Thu, 19 Jan 2017 14:25:33 +0200 From: Jarkko Sakkinen To: James Bottomley Cc: tpmdd-devel@lists.sourceforge.net, linux-security-module@vger.kernel.org, open list Subject: Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion Message-ID: <20170119122533.d7h5rgatpwl3qmcl@intel.com> References: <1484772489.2396.2.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1484772489.2396.2.camel@HansenPartnership.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.6.2-neo (2016-08-21) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 18, 2017 at 03:48:09PM -0500, James Bottomley wrote: > In a TPM2, sessions can be globally exhausted once there are > TPM_PT_ACTIVE_SESSION_MAX of them (even if they're all context saved). > The Strategy for handling this is to keep a global count of all the > sessions along with their creation time. Then if we see the TPM run > out of sessions (via the TPM_RC_SESSION_HANDLES) we first wait for one > to become free, but if it doesn't, we forcibly evict an existing one. > The eviction strategy waits until the current command is repeated to > evict the session which should guarantee there is an available slot. > > On the force eviction case, we make sure that the victim session is at > least SESSION_TIMEOUT old (currently 2 seconds). The wait queue for > session slots is a FIFO one, ensuring that once we run out of > sessions, everyone will get a session in a bounded time and once they > get one, they'll have SESSION_TIMEOUT to use it before it may be > subject to eviction. > > Signed-off-by: James Bottomley I didn't yet read the code properly. I'll do a more proper review once I have v4 of my patch set together. This comment is solely based on your commit message. I'm just thinking that do we need this complicated timeout stuff or could you just kick a session out in LRU fashion as we run out of them? Or one variation of what you are doing: couldn't the session that needs a session handle to do something sleep for 2 seconds and then take the oldest session? It would have essentially the same effect but no waitqueue needed. Yeah, as I said, this is just commentary based on the description. /Jarkko