Received: by 10.192.165.148 with SMTP id m20csp4038020imm; Tue, 8 May 2018 01:41:03 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqHUbuxmiHfBWRMPu75MN+IXC+FTVuwUXoyHpoaUviO4kZ8k4ALUtvhH5De8fNHlkpQD7mH X-Received: by 2002:a63:a50a:: with SMTP id n10-v6mr32497732pgf.141.1525768863918; Tue, 08 May 2018 01:41:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525768863; cv=none; d=google.com; s=arc-20160816; b=TFsflUEILAuIZ0rXbXxaL2ZajTFUwGludDQmUUwO++wClbCsqt6mhklkKinKHrGm9C MfKmvhM1jjwQ5kJx3LLDYK281Ku/tjhfZhHeNTXpsG4ddNZizCmc7z89nfWGht2Vv6d0 gVVtXFjJJmsm3JY7Inw3aldYnDbNESXx+e5a4eHYoJDBlafUtUfCBj56NXlSzFkQ3S7a zdI734Ur12UowJ3ikONzk+l0QFw1hRSV2Ft8XKIfKvTuhaRPh3Tupii8OD3dSF1YTT45 Ijqt8KKPIigYj+XjoYcaEb4VrVxe3jj8gGMk5sQqgl9wH+/m27akBSe5c0YVO86ycmFf NGZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=er6wkJt1CKweE2WzjvZtSaEP4MxmOq7j8egRYbmI1JY=; b=iZT6QSWilWQYT1JypgwnDcX94Iom/CRhb5t50MeOAXMRbnJm8/r+TIsInUPz2RR3E2 1eMfn/MRTjURhzfkQOyoM3XD33aSH9GuLst7Qj62/it01qDXgjjbnMaYhh5puYWlOGvT sjwL8+CDB5omKubjGKzv0P64cgcgbBZfh0IX5/Etc2bJF09l4PpnGPP3pqwf4tsyhahY MHiIT68j+XcZxY4pnBSh1tsHbmLUq4/1LJlaXsErE6eyKOS+4C02Ed0gJoFfu3NaGjnw rKMJTJ5H1XRBh3RhMrWn8rgjsnjYwAU4MH5D9/Wp/QCL6yKflKMraDblNYJpXKFHuUPV e8iQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OAcKYoZR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w65si23988075pfa.18.2018.05.08.01.40.49; Tue, 08 May 2018 01:41:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OAcKYoZR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933313AbeEHIkC (ORCPT + 99 others); Tue, 8 May 2018 04:40:02 -0400 Received: from mail-pl0-f48.google.com ([209.85.160.48]:39720 "EHLO mail-pl0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932540AbeEHIj7 (ORCPT ); Tue, 8 May 2018 04:39:59 -0400 Received: by mail-pl0-f48.google.com with SMTP id q18-v6so1810017plr.6; Tue, 08 May 2018 01:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=er6wkJt1CKweE2WzjvZtSaEP4MxmOq7j8egRYbmI1JY=; b=OAcKYoZRDv0aN/LBiTvlgvnyWZjsWCsFmDaaemUwPAZg/RhO3nJMR4GLKYQ5VO+aD5 DbyJnFKzOYRyiuNeSMG34/ma6paibkZ/fplZ4JJURdXjjvDdWYdgLwGcOqMmV6qCqkLu jlv8BHCXaDBvDboqQheaSoeQs+km9NCFo6s1DCzqIqf5lIifLUqPlpezTsmooOJ0Pis6 NXH9L6Wqlsqg0Qv0kYiXN4eaKb+wlZKM4tSbNkRiwuxqD50T1nASsFRRvlRBla5j1YwU l6j7VMd4XH/i4vkOKb88w1k3EwYYidpJU9KAimKHjwK690xgZ0JtXQtM5PG45/4HzVAM fyHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=er6wkJt1CKweE2WzjvZtSaEP4MxmOq7j8egRYbmI1JY=; b=tqeNC7LjB74VuDe7nLdyd9ZaeHIhSs3ohJAvMlOynEAs9ArQuu92lgajEaFRQblr3V rAalVCE1IzbcwwfOFH4fk7En6rVQbjZvRLvnNPKFjlQCF4qmoPNLXvNLqj7Y2djlau8F LFCRNWLRCjA7CQlSqzPna2SmuTT5gK7mjb+TwZa3Vr7qwNRN9hv+M+Z3ZOVTPzyJKcK1 U1pfsVJJGHx8i3+KhhQCoUO/a9RGgPpYpXAeqXTABwdgaPSu0Wak9K8IQZU8lde3P+R/ Vr2mvW+B9IFnrNt9o+0+EImqP+gKHGz4Dwc9pf0Qk/9F25axQxplh07lmxNO0HXFl5Kt qn6w== X-Gm-Message-State: ALQs6tCSPGLFwequnjxED6bK3k7uQwP9KPstRxjevhJoBn6pIZdfHNK/ Vw14IKi/A0b/zu+WShqckKaOBSpM X-Received: by 2002:a17:902:229:: with SMTP id 38-v6mr15003691plc.384.1525768798913; Tue, 08 May 2018 01:39:58 -0700 (PDT) Received: from ?IPv6:2402:f000:1:1501:200:5efe:166.111.70.9? ([2402:f000:1:1501:200:5efe:a66f:4609]) by smtp.gmail.com with ESMTPSA id h65sm56255473pfj.54.2018.05.08.01.39.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 May 2018 01:39:58 -0700 (PDT) Subject: Re: [usb-storage] [PATCH] usb: storage: Fix a possible data race in uas_queuecommand_lck To: Oliver Neukum , stern@rowland.harvard.edu, gregkh@linuxfoundation.org Cc: linux-usb@vger.kernel.org, linux-scsi@vger.kernel.org, usb-storage@lists.one-eyed-alien.net, linux-kernel@vger.kernel.org References: <20180508074743.13622-1-baijiaju1990@gmail.com> <1525768070.24345.8.camel@suse.com> From: Jia-Ju Bai Message-ID: <37706c9a-8b12-8440-29fd-34342e47a68e@gmail.com> Date: Tue, 8 May 2018 16:39:50 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <1525768070.24345.8.camel@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018/5/8 16:27, Oliver Neukum wrote: > Am Dienstag, den 08.05.2018, 15:47 +0800 schrieb Jia-Ju Bai: >> The write operations to "cmnd->result" and "cmnd->scsi_done" >> are protected by the lock on line 642-643, but the write operations >> to these data on line 634-635 are not protected by the lock. >> Thus, there may exist a data race for "cmnd->result" >> and "cmnd->scsi_done". > No, > > the write operations need no lock. The low level driver at this point > owns the command. We cannot race with abort() for a command within > queuecommand(). We take the lock where we take it to protect > dev->resetting. > > I don't see why the scope of the lock would need to be enlarged. Okay, thanks for your reply and explanation. Best wishes, Jia-Ju Bai