Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1983136imu; Fri, 23 Nov 2018 03:06:49 -0800 (PST) X-Google-Smtp-Source: AJdET5cE3wxDXvezypnfHlr0TZWlIzCOrV2eV9ZKEdqUZp/igJ7XHRg0FYfz8uo/WsZndvLqsgJ1 X-Received: by 2002:a62:3101:: with SMTP id x1-v6mr15881539pfx.204.1542971209099; Fri, 23 Nov 2018 03:06:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542971209; cv=none; d=google.com; s=arc-20160816; b=ygpcktm4O3o2ri4tf2/kojpmKIb8f8n+YEt8vam/SRj7QpX/yVzxCrz4PeWM0jCAIf bnRnMBFmH4fHTaK6BDJoGwJsQrMp+JZQ9Ba2LipxIJ9YJei6/8ZfOVJw6U2Z0NvObYF4 oi3hqRBRnSbl3Wi4aoG1bdl+gyl0IHkY8VZPdSeMS28Rz4aVGMOj8GEW0+5R+sbOiSck zezOCovpKTVcNWT7iUxZkQb91ZrgMFAB9UhubhgpAl+ZmSxNmCMaDa/17IGNQ5Q8TLa0 YcwohOzNY0B3g7KDjM+V9tiqR3VUaS38ou5jmPsiTlniJzD+vYSjhPcSGl5wfR/OsXAV nfgw== 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:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=2eMdQPzjqVb8fRKzRizgPXxWP/4O2VWTSlfg4CJTlMs=; b=klYA/6ZeI14zh5Jy/XYU5WdNtx7OMfwDkYpzQr8qg7tsTVfbJJD+V6yNW0jVe4HdbK 3DspSh6qBJVxInw3XR9jeBaQ/1Gx69CG2rjPwCwHu0u+QdBQlOhYS4oYv+/AHbclRrwz TyTj9sqhXMYzCi1ldbf98YemR12u2X2OtK05+XoDa6TAL925CMaCaFcXgX6pGmLAiWOV 1g8xu6RwhJexxq3hZBRFskBD/aeUmbT0XxUlxYg7VPAsYTHbt2ATESJWwASu+ty8JYds Vbo7xGr29OnLS9WBOgBrdIt0tgeVx5ktfTl7mCTR2GhJ0s26D1245wQb9YbGYWzkPRVL W+JQ== 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 j34si50429554pgj.557.2018.11.23.03.06.32; Fri, 23 Nov 2018 03:06:49 -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 S2394369AbeKVVIc (ORCPT + 99 others); Thu, 22 Nov 2018 16:08:32 -0500 Received: from szxga06-in.huawei.com ([45.249.212.32]:38677 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2388128AbeKVVIc (ORCPT ); Thu, 22 Nov 2018 16:08:32 -0500 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 9E3E5A4B3FC57; Thu, 22 Nov 2018 18:29:40 +0800 (CST) Received: from [10.151.23.176] (10.151.23.176) by smtp.huawei.com (10.3.19.205) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 22 Nov 2018 18:29:34 +0800 Subject: Re: [PATCH 04/10] staging: erofs: fix `erofs_workgroup_{try_to_freeze, unfreeze}' To: Greg Kroah-Hartman CC: , , Chao Yu , LKML , , Miao Xie References: <20181120143425.43637-1-gaoxiang25@huawei.com> <20181120143425.43637-5-gaoxiang25@huawei.com> <20181122102155.GE3189@kroah.com> From: Gao Xiang Message-ID: Date: Thu, 22 Nov 2018 18:29:34 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20181122102155.GE3189@kroah.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.151.23.176] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Greg, On 2018/11/22 18:21, Greg Kroah-Hartman wrote: > On Tue, Nov 20, 2018 at 10:34:19PM +0800, Gao Xiang wrote: >> There are two minor issues in the current freeze interface: >> >> 1) Freeze interfaces have not related with CONFIG_DEBUG_SPINLOCK, >> therefore fix the incorrect conditions; >> >> 2) For SMP platforms, it should also disable preemption before >> doing atomic_cmpxchg in case that some high priority tasks >> preempt between atomic_cmpxchg and disable_preempt, then spin >> on the locked refcount later. > > spinning on a refcount implies that you are trying to do your own type > of locking. Why not use the in-kernel locking api instead? It will > always do better than trying to do your own logic as the developers > there know locking across all types of cpus better than filesystem > developers :) It is because refcount also plays a role as a spinlock on a specific value (== EROFS_LOCKED_MAGIC), no need to introduce such a value since the spin window is small. Thanks, Gao Xiang > > thanks, > > greg k-h >