Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1566237pxb; Thu, 28 Jan 2021 22:10:29 -0800 (PST) X-Google-Smtp-Source: ABdhPJxI0p3MJXVYY54mF2GgG+i3KgrKg8YgxL0VctZYAL12lGwme348d/u+vbw9ihLQU4k4NMu6 X-Received: by 2002:a17:906:178d:: with SMTP id t13mr2931239eje.455.1611900629497; Thu, 28 Jan 2021 22:10:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611900629; cv=none; d=google.com; s=arc-20160816; b=SbPiKNc3FHmcvledmqutKK2pgJXlJsMgWw8ZhH9q6SpbxSmR3IdtIYXVJ7GpV5NRZ2 hBgJ2V791rBJlyjDhmhYq5EICEvLqhcUDcRSgg/MZopkPhjvDkLDyNmWsnep4nA27N04 J69qlhxnO5vvisJ156UkC4VXQu3xBCGGMaWwLHvcA5TLKfOUTuOZHCE1IQ7sSyRql7rM DcEDFFaLMW8HoT6ifGDpALDtW9/6+bfKpFuT9AUhJgDPLp4a1IefaYiQVlGrAIifdOTc DKNMwQ+1FnpGEY8Kgk/e7/ir44+TF66yw89CFw6BFsDoBmo/15UTf2RgXQEdwtITMZqp 6AHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:message-id:references:in-reply-to :subject:cc:to:from:date:content-transfer-encoding:mime-version :sender:dkim-signature; bh=0rkQubtuEtIqttDY1T0ryEW5Vzh9FrLlo5uy520HbSI=; b=HU3I6InBSiTsJnd32rWMc6RclPnlkKmAlMLb+IHKX9PvJyh4nfItN5sXJPWZJuSh7k nkWOXz/mohtiFz/MhZe+KKsmTzRHZnXZqUJdr/gD/Bg7JpcbJMcveo5Ne6symanEzP/0 un0AspxAPt7733DHqKlfnSCa5X+qOdYrwXQqATeQ9EYwgRProrx3aYLQsTcWA8k0y7fJ 0vmlCtjo/+Uso/FteFFlCtyW+Djund1h0oynlS7HWCIlIJVgRphPLvtK2cTnRtFZeM5j jM5CX0DVHf5H3ssimP+ELcWdUpcTP2+l93558qUw5iCkyAMw8iKnmqmUESnmibCUL5PK 0EAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mg.codeaurora.org header.s=smtp header.b=b1TKLdvD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ca6si4550270edb.409.2021.01.28.22.10.04; Thu, 28 Jan 2021 22:10:29 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@mg.codeaurora.org header.s=smtp header.b=b1TKLdvD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231886AbhA2GHX (ORCPT + 99 others); Fri, 29 Jan 2021 01:07:23 -0500 Received: from m42-8.mailgun.net ([69.72.42.8]:15408 "EHLO m42-8.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230121AbhA2GHQ (ORCPT ); Fri, 29 Jan 2021 01:07:16 -0500 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1611900412; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=0rkQubtuEtIqttDY1T0ryEW5Vzh9FrLlo5uy520HbSI=; b=b1TKLdvD5FtB7sD6usKlbVdmUvNVxfV10n5IJlkh8E8SIxkbW4AfT61LThvwlW8ek/dHJZmy sqWj1rT26z3sBr9gpFiqlFvphiQ1zXcTMw0KYDmgjgTR7CCFpTYM4bKInz6/JcxDhubtkoiN /4Y4AvSvUw3lN0XQ1RTQpGD8bRo= X-Mailgun-Sending-Ip: 69.72.42.8 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n01.prod.us-west-2.postgun.com with SMTP id 6013a5db262adddd45c31330 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Fri, 29 Jan 2021 06:06:19 GMT Sender: cang=codeaurora.org@mg.codeaurora.org Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 19798C43465; Fri, 29 Jan 2021 06:06:19 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=ALL_TRUSTED,BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cang) by smtp.codeaurora.org (Postfix) with ESMTPSA id 412E8C433CA; Fri, 29 Jan 2021 06:06:18 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 29 Jan 2021 14:06:18 +0800 From: Can Guo To: Bart Van Assche Cc: jaegeuk@kernel.org, asutoshd@codeaurora.org, nguyenb@codeaurora.org, hongwus@codeaurora.org, linux-scsi@vger.kernel.org, kernel-team@android.com, Alim Akhtar , Avri Altman , "James E.J. Bottomley" , "Martin K. Petersen" , Stanley Chu , Bean Huo , open list Subject: Re: [PATCH v3 2/3] scsi: ufs: Fix a race condition btw task management request send and compl In-Reply-To: <73362ca9-93be-c38f-a881-4b7cf690fbc1@acm.org> References: <1611807365-35513-1-git-send-email-cang@codeaurora.org> <1611807365-35513-3-git-send-email-cang@codeaurora.org> <73362ca9-93be-c38f-a881-4b7cf690fbc1@acm.org> Message-ID: <5f77542d66732003f0154a4e8a6ae13b@codeaurora.org> X-Sender: cang@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-01-29 11:20, Bart Van Assche wrote: > On 1/27/21 8:16 PM, Can Guo wrote: >> ufshcd_compl_tm() looks for all 0 bits in the >> REG_UTP_TASK_REQ_DOOR_BELL >> and call complete() for each req who has the req->end_io_data set. >> There >> can be a race condition btw tmc send/compl, because the >> req->end_io_data is >> set, in __ufshcd_issue_tm_cmd(), without host lock protection, so it >> is >> possible that when ufshcd_compl_tm() checks the req->end_io_data, it >> is set >> but the corresponding tag has not been set in >> REG_UTP_TASK_REQ_DOOR_BELL. >> Thus, ufshcd_tmc_handler() may wrongly complete TMRs which have not >> been >> sent out. Fix it by protecting req->end_io_data with host lock, and >> let >> ufshcd_compl_tm() only handle those tm cmds which have been completed >> instead of looking for 0 bits in the REG_UTP_TASK_REQ_DOOR_BELL. > > I don't know any other block driver that needs locking to protect races > between submission and completion context. Can the block layer timeout > mechanism be used instead of the mechanism introduced by this patch, > e.g. by using blk_execute_rq_nowait() to submit requests? That would > allow to reuse the existing mechanism in the block layer core to handle > races between request completion and timeout handling. This patch is not introducing any new mechanism, it is fixing the usage of completion (req->end_io_data = c) introduced by commit 69a6c269c097 ("scsi: ufs: Use blk_{get,put}_request() to allocate and free TMFs"). If you have better idea to get it fixed once for all, we are glad to take your change to get it fixed asap. Regards, Can Guo. > > Thanks, > > Bart.