From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S932255AbdAAQdP (ORCPT <rfc822;w@1wt.eu>);
        Sun, 1 Jan 2017 11:33:15 -0500
Received: from shards.monkeyblade.net ([184.105.139.130]:37960 "EHLO
        shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S932066AbdAAQdO (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Sun, 1 Jan 2017 11:33:14 -0500
Date: Sun, 01 Jan 2017 11:33:11 -0500 (EST)
Message-Id: <20170101.113311.417107391370623850.davem@davemloft.net>
To: Bart.VanAssche@sandisk.com
Cc: jejb@linux.vnet.ibm.com, hch@infradead.org, jbaron@akamai.com,
        linux-kernel@vger.kernel.org, sagi@grimberg.me,
        sathya.prakash@broadcom.com, suganath-prabu.subramani@broadcom.com,
        martin.petersen@oracle.com, hare@suse.de, linux-scsi@vger.kernel.org,
        hch@lst.de, Sreekanth.Reddy@broadcom.com, chaitra.basappa@broadcom.com,
        dledford@redhat.com
Subject: Re: [PATCH] scsi: mpt3sas: fix hang on ata passthru commands
From: David Miller <davem@davemloft.net>
In-Reply-To: <1483280506.5512.1.camel@sandisk.com>
References: <20161229080250.GA11605@infradead.org>
        <1483226343.2518.32.camel@linux.vnet.ibm.com>
        <1483280506.5512.1.camel@sandisk.com>
X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Sun, 01 Jan 2017 07:34:01 -0800 (PST)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

From: Bart Van Assche <Bart.VanAssche@sandisk.com>
Date: Sun, 1 Jan 2017 14:22:11 +0000

> My recommendation is to revert commit 18f6084a989b ("scsi: mpt3sas: Fix
> secure erase premature termination"). Since the mpt3sas driver uses the
> single-queue approach and since the SCSI core unlocks the block layer
> request queue lock before the .queuecommand callback function is called,
> multiple threads can execute that callback function (scsih_qcmd() in this
> case) simultaneously. This means that using scsi_internal_device_block()
> from inside .queuecommand to serialize SCSI command execution is wrong.

But this causes a regression for the thing being fixed by that commit.

Why don't we figure out what that semantics that commit was trying to
achieve and implement that properly?