Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp5767461imb; Fri, 8 Mar 2019 01:42:37 -0800 (PST) X-Google-Smtp-Source: APXvYqz+1lLU6yPI8WKRdOgWqGaixTm4kk1jsYc9gvWwKNaATzRMc6dXFl+2vZdVPB39WwLqxiiZ X-Received: by 2002:a17:902:2963:: with SMTP id g90mr18047100plb.182.1552038156829; Fri, 08 Mar 2019 01:42:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1552038156; cv=none; d=google.com; s=arc-20160816; b=FzGX7hqbuFnEQqvi0qndhvuxrmGK8hadjZIGWd4w03zQuevDhIr5n1ZE2Y4WBNaa1z ifhvIDccQNvQzSn8C3Ia1376luMzUBzz5w6PrjMz/t39THX2sNILqcezsycXSxj2ra4B xtwiD/ULJK1OiWTEuAcxSca86N5pinWi786utjtiJXzaWu28L4XPRllthzvf44VWKqBX Wq85xv3OtjXnQpJRWkf2F0YM/UEaNL9Ktv/vZ6VBXcniknjlYHn4gqqL8uxqPGfZQe/A qTHWwrWhv4o1ujaSFVmr2zQCw+yx6utuXevY/pFqtgFwu86TzFtyvg59GICTaKMXaHEk ANGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=+7n3PozKRRleiy9eC9dKf6a1YjEqxOv2Ornx457VjPo=; b=W6ETesl8n03KZbiZrKgpyxmUEugFqAnEXeaZARBvqHdGhqvP6QC5EiDC1ZeMItJ/qD 7RuIYMOad6xyMxv3SIF5XahMMZ4KWuDcIRucGijhx9riabpUSwRUdWPVwDjHz+gJ7oN8 h75dknBLsldtGULAyJXeSmlJmnZIyxuA8VT6MMfF8qxsP8n0QoEf4ttLIOXI7BNeJJVw H6buL/YU+ho42UI1Fy1CXPsyfZwiVjI9K9a8+EoQv+lfGAST5ivww9Gwvnk0kmI4EUJf kFYGwFtwEvvUEPLHyO5w58Jl1t5iEEECDvNxVEhJFKvHMAEK3DJmQPa3pqOOpN8apE8R dNOg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d16si6045796pgi.148.2019.03.08.01.42.20; Fri, 08 Mar 2019 01:42:36 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726351AbfCHJli (ORCPT + 99 others); Fri, 8 Mar 2019 04:41:38 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:60142 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726238AbfCHJli (ORCPT ); Fri, 8 Mar 2019 04:41:38 -0500 Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1h2C0S-0008GF-4i; Fri, 08 Mar 2019 10:41:32 +0100 Date: Fri, 8 Mar 2019 10:41:31 +0100 From: Sebastian Andrzej Siewior To: "Liu, Yongxin" Cc: "linux-kernel@vger.kernel.org" , "linux-rt-users@vger.kernel.org" , "tglx@linutronix.de" , "rostedt@goodmis.org" , "dan.j.williams@intel.com" , "pagupta@redhat.com" , "Gortmaker, Paul" , "linux-nvdimm@lists.01.org" Subject: Re: [PATCH RT] nvdimm: make lane acquirement RT aware Message-ID: <20190308094131.ge4wbsvz4p6xikdf@linutronix.de> References: <20190306095709.23138-1-yongxin.liu@windriver.com> <20190307143344.ytsnbmot5tjzjhip@linutronix.de> <597B109EC20B76429F71A8A97770610D12A52669@ALA-MBD.corp.ad.wrs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <597B109EC20B76429F71A8A97770610D12A52669@ALA-MBD.corp.ad.wrs.com> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-03-08 00:07:41 [+0000], Liu, Yongxin wrote: > The lane is critical resource which needs to be protected. One CPU can use only one > lane. If CPU number is greater than the number of total lane, the lane can be shared > among CPUs. > > In non-RT kernel, get_cpu() disable preemption by calling preempt_disable() first. > Only one thread on the same CPU can get the lane. > > In RT kernel, if we only use raw_smp_processor_id(), this doesn't protect the lane. > Thus two threads on the same CPU can get the same lane at the same time. > > In this patch, two-level lock can avoid race condition for the lane. but you still have the ndl_lock->lock which protects the resource. So in the unlikely (but possible event) that you switch CPUs after obtaining the CPU number you block on the lock. No harm is done, right? > Thanks, > Yongxin Sebastian