Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2024276imu; Fri, 23 Nov 2018 03:41:51 -0800 (PST) X-Google-Smtp-Source: AFSGD/U8by/FKJ2OxPdgnsNZjH1lIn/7q6n3xD5cpYm6oVujjjJTlb2GQlv8+zlTA4aquYvb9Rva X-Received: by 2002:a63:b218:: with SMTP id x24mr13338225pge.223.1542973311540; Fri, 23 Nov 2018 03:41:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542973311; cv=none; d=google.com; s=arc-20160816; b=AF1ZNji9E0qTbIpdqAJk0dpFucRZlclkzEnQA4wuXiuYcvEHqm8nJ/HCWw0fV75783 4+4PWh0gVZAVGOl7JXNlGyXaOtHKGoDbNN1rugy8Ijpyh7TiDZlCu0tdLRGjH+uRF6pt siCnbwtBhBp4/yJ+IX8GICMgwjWQYensk+Az4FH2oSi5ZaxUxP7VpQkyALN0u/nP7u5j +AbNNebHLY4TeHxttdEJbtzzgi6NsUk6QImar77FS3GLKUwd3zeovtTU9eBmNTwQVvlD O0KOUKiNdnkKv41uRKHOLD7XVeJiH8XzsKZe1uAm5zY2aeMI8cRS0MuEo9JtCyYtFyfm 19Ug== 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=5cOgBevY78y92TKbzXILvL4ELQmQXAs6nboZpW/7jjo=; b=OnJjwscIvpBA2/DcI9mHMgxwpnnsD5OfXcSF+1xRKOSvJO/wWyUKOjmSLEAXj0aKYt MpdnbUwCbdjhGetggM+41GGUx5gvrDMWQNNMSBmtt2Qry6unZw7zfhyqop1HsM3DckgV uwtVzDm/qibiUvPnYOnghnbgNu763JtMpH0oW0Cmd2ntZ4uX2HYcdhdRYikDJ1cy4EAN jTgUKv1ONQjCACR3y4Lrbwsm+swH1FN0f310bMtq+NBw34NN8dIierNYZ4qpwfZMj1DI Zy9TB1wEovrWQdmQnNLlCMvN8Z4fxsJuMgwumRhgDGsNY2Mc8AyzvBrAfkwvdrwkjZht YmiQ== 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 x2-v6si52951152plv.413.2018.11.23.03.41.12; Fri, 23 Nov 2018 03:41:51 -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 S2388660AbeKVVVv (ORCPT + 99 others); Thu, 22 Nov 2018 16:21:51 -0500 Received: from szxga07-in.huawei.com ([45.249.212.35]:42697 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1732079AbeKVVVv (ORCPT ); Thu, 22 Nov 2018 16:21:51 -0500 Received: from DGGEMS411-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 7DC79DCC11375; Thu, 22 Nov 2018 18:42:57 +0800 (CST) Received: from [10.151.23.176] (10.151.23.176) by smtp.huawei.com (10.3.19.211) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 22 Nov 2018 18:42:52 +0800 Subject: Re: [PATCH 02/10] staging: erofs: fix race when the managed cache is enabled To: Greg Kroah-Hartman CC: , , Chao Yu , LKML , , Miao Xie References: <20181120143425.43637-1-gaoxiang25@huawei.com> <20181120143425.43637-3-gaoxiang25@huawei.com> <20181122101711.GA3189@kroah.com> From: Gao Xiang Message-ID: <55aed87f-196e-9048-6aae-db09bc497664@huawei.com> Date: Thu, 22 Nov 2018 18:42:52 +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: <20181122101711.GA3189@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:17, Greg Kroah-Hartman wrote: > Any specific reason why you are not using the refcount.h api instead of > "doing it yourself" with atomic_inc/dec()? > > I'm not rejecting this, just curious. As I explained in the previous email, Re: [PATCH 04/10] staging: erofs: fix `erofs_workgroup_{try_to_freeze, unfreeze}' we need such a function when the value is >= 0, it plays as a refcount, but when the refcount == EROFS_LOCKED_MAGIC (<0, but not 0 as refcount.h), and actually there is no need to introduce a seperate spinlock_t because we don't actually care about its performance (rarely locked). and the corresponding struct is too large for now, we need to decrease its size. Thanks, Gao Xiang > > thanks, > > greg k-h