From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id AE18A1A001E for ; Fri, 2 Oct 2015 23:14:49 +1000 (AEST) Subject: Re: [PATCH v5 08/34] cxlflash: Fix to avoid CXL services during EEH To: "Matthew R. Ochs" , linux-scsi@vger.kernel.org, James Bottomley , "Nicholas A. Bellinger" , Brian King , Ian Munsie , Daniel Axtens , Andrew Donnellan , David Laight References: <1443714773-9176-1-git-send-email-mrochs@linux.vnet.ibm.com> <1443714926-15545-1-git-send-email-mrochs@linux.vnet.ibm.com> Cc: Michael Neuling , linuxppc-dev@lists.ozlabs.org, "Manoj N. Kumar" From: Tomas Henzl Message-ID: <560E8344.9040608@redhat.com> Date: Fri, 2 Oct 2015 15:14:44 +0200 MIME-Version: 1.0 In-Reply-To: <1443714926-15545-1-git-send-email-mrochs@linux.vnet.ibm.com> Content-Type: text/plain; charset=windows-1252 List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 1.10.2015 17:55, Matthew R. Ochs wrote: > During an EEH freeze event, certain CXL services should not be > called until after the hardware reset has taken place. Doing so > can result in unnecessary failures and possibly cause other ill > effects by triggering hardware accesses. This translates to a > requirement to quiesce all threads that may potentially use CXL > runtime service during this window. In particular, multiple ioctls > make use of the CXL services when acting on contexts on behalf of > the user. Thus, it is essential to 'drain' running ioctls _before_ > proceeding with handling the EEH freeze event. > > Create the ability to drain ioctls by wrapping the ioctl handler > call in a read semaphore and then implementing a small routine that > obtains the write semaphore, effectively creating a wait point for > all currently executing ioctls. > > Signed-off-by: Matthew R. Ochs > Signed-off-by: Manoj N. Kumar > Reviewed-by: Brian King > Reviewed-by: Daniel Axtens Reviewed-by: Tomas Henzl Tomas