Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1310356imm; Fri, 11 May 2018 14:23:23 -0700 (PDT) X-Google-Smtp-Source: AB8JxZq3xfiDySMBscjz1gikRE3MA0ZA9yiUpFmsGHhdi4B7uph6+89j80f5ZzMkSGsLihRAxiWR X-Received: by 2002:a65:520c:: with SMTP id o12-v6mr540447pgp.178.1526073803660; Fri, 11 May 2018 14:23:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526073803; cv=none; d=google.com; s=arc-20160816; b=KU8BNCmtbkuAGZyP+b3hXSYldAr8mLJZVZ+1FDAC+mKYrNLpas/ePlt80UaCkIK3s7 ce6mvLgW0IJ/jvQE9/kvWbt7VkDZXxMGHsbeqPnEBthYdv1PLgegu/BA3NzoeGlu9nl3 Vu7QKYcPvi1+Wj9eKLrSRFjnNcOhbUmxiiCvU1zTJ6ser/1S3Tniee2XY3McaM5jvBq8 ZvFjpWxkFEFBMw3I8+EWiZe9AKilmvq6toGOYIQxF/KH4zrBbJ7bqD2o/GG9ZKp6dXgR uiNHCxkfZFcVlA3NsIA9tVIfZEyLHQgSONSovoRhY8P9pyqgx8gvg10dMU1UDx6HfMU7 /ghg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=ZNgfpSmKF8W8t6N4EopdQKV+KzaPaMejZKV3AL/kizo=; b=ezInxXEsygtKEnv7RTPZWiqatSRykF/7c55QRf1+HCvVY2ou1j0PQ19ipE6eRTKeqH KsvS/diYt1YrWnMY94BRMJ3aED/njdm1qVwhDU8M41obYMY/7ffPbM+lls8VZMlS+odP FBGxoSkgSaf3UfAQaz4KUhmUZtwZ9xQfCYX3ls22wx5Z38Xjc5TH8S5IpnldT1OZ0lD2 t0h4lQqNYfZcVxLAIXjVXHwHIe8feBwv03i9lJyKgcfPCWuHIG14SkGZO9p4AOhfoRJ9 94Elc0r82UyH+RCatIEhz3eMzie8IwjCiDoJmOjm+bKLX3txAuG1Cztno23OYPrW1JK/ Lkjw== 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 y1-v6si3590436plt.316.2018.05.11.14.23.08; Fri, 11 May 2018 14:23:23 -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; 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 S1751228AbeEKVW7 convert rfc822-to-8bit (ORCPT + 99 others); Fri, 11 May 2018 17:22:59 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:48706 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750798AbeEKVW6 (ORCPT ); Fri, 11 May 2018 17:22:58 -0400 Received: from akpm3.svl.corp.google.com (unknown [104.133.9.71]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id A510F2AE3; Fri, 11 May 2018 21:22:57 +0000 (UTC) Date: Fri, 11 May 2018 14:22:56 -0700 From: Andrew Morton To: Larry Chen Cc: mfasheh@versity.com, jlbec@evilplan.org, linux-kernel@vger.kernel.org, ocfs2-devel@oss.oracle.com Subject: Re: [PATCH] ocfs2: ocfs2_inode_lock_tracker does not distinguish lock level Message-Id: <20180511142256.ecabae077ddd5fb18df29959@linux-foundation.org> In-Reply-To: <88053e38-350e-34a4-b3d8-431297dc1f90@suse.com> References: <20180510053230.17217-1-lchen@suse.com> <20180510144944.d0842b82b99a471dbbc745ad@linux-foundation.org> <88053e38-350e-34a4-b3d8-431297dc1f90@suse.com> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 11 May 2018 12:16:51 +0800 Larry Chen wrote: > > Nice changelog, but it gives no information about the severity of the > > bug: how often does it hit and what is the end-user impact. > > > > This info is needed so that I and others can decide which kernel > > version(s) need the patch, so please always include it when fixing a > > bug, thanks. > > Thanks for your review and feel sorry for not providing enough information. > > For the status quo of ocfs2, without this patch, neither a bug nor end-user > impact will be caused because the wrong logic is avoided. > > But I'm afraid this generic interface, may be called by other > developers in future and used in this situation. > > ??? a process > ocfs2_inode_lock_tracker(ex=0) > ocfs2_inode_lock_tracker(ex=1) OK, thanks. > By the way, should I resend this patch with this info included? I pasted the above into my copy of the changelog so we're good.