Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2050584imu; Fri, 23 Nov 2018 04:04:16 -0800 (PST) X-Google-Smtp-Source: AJdET5ccPP7QYnwia3I3+nRxIcRrIkWeikBtmVkHex/M4D2bBH9WTL5P6GBfimKptJ4SYycjhomd X-Received: by 2002:a62:2f06:: with SMTP id v6mr15863396pfv.216.1542974656504; Fri, 23 Nov 2018 04:04:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542974656; cv=none; d=google.com; s=arc-20160816; b=ja5Zyzzj7qZz1Unk0r5mHhPLPyi4gdu6mdAkRYoX+a4Vu6xsdGmyfCKp/yHrbKd9Um mdFUXFM3qPN2iDsQLexRKlxqamWKZ88Dz8YebevHS6CHaAZdDPdmfGFUtNLoDxXUv70a L84tFfcymjt93inecz2qTmVpXwQf4J9YwvirAOgzSh3R15XhJDBWBmpDD4VZt1MROXHJ idCKajb3HG6fJVsVqBI6CjJUlmG+xgBn8GSwJ2IFPOPRhACkJv0yDcovcInytVkbi7Tn qQcMp2QOMLkeM1BSfNNGdqs2femUDc+80loanzeWpztH/qzipr17D1qgnxMAHs3997cO FWbA== 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=JxJfqX+GzqVCoc04nOncqtXBHGq5ExQ5Wp0MmTu2UEQ=; b=d49/0Fr5a5hOpupCxtxEN1m+nbd/sXM0eaofHhiHvsnxfUgXU3Y1Oo8mTHmDDWtMei eqD/BcjaxHL3VZ04iI8XbKqCNWI8qIjo7lohsXrPgPzCP+CPgRyoh8qpgYxWOgJbp7U2 x+L24uzKl8LxIHianebbWbdXoRe43exKXaUfX9KgGPbRHfUMruCcUC2twiON29YLjefd +dvE17edpzoPrG52MTrSyWhrJ9EMHZHq6yS1t4wijQ+ks/gHYivhUdingSySSjvZqgU5 kZJE1BGwpe8edMmPHLWkeuR6FUbXF2JAf2ES7Fuathw5gKz3YdQPmiZI1dXMeas2Qwgg 69Zg== 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 g7si13215376plb.107.2018.11.23.04.03.50; Fri, 23 Nov 2018 04:04:16 -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 S2405505AbeKVVuO (ORCPT + 99 others); Thu, 22 Nov 2018 16:50:14 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:15574 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2405477AbeKVVuO (ORCPT ); Thu, 22 Nov 2018 16:50:14 -0500 Received: from DGGEMS411-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 7DD9357664B80; Thu, 22 Nov 2018 19:11:16 +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 19:11:07 +0800 Subject: Re: [PATCH 07/10] staging: erofs: separate into init_once / always To: Greg Kroah-Hartman CC: , , Chao Yu , LKML , , Miao Xie References: <20181120143425.43637-1-gaoxiang25@huawei.com> <20181120143425.43637-8-gaoxiang25@huawei.com> <20181122102339.GG3189@kroah.com> <66b90226-5d0e-7344-5220-908aa243b014@huawei.com> <20181122110500.GC5287@kroah.com> From: Gao Xiang Message-ID: Date: Thu, 22 Nov 2018 19:11:08 +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: <20181122110500.GC5287@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 19:05, Greg Kroah-Hartman wrote: > On Thu, Nov 22, 2018 at 06:34:10PM +0800, Gao Xiang wrote: >> Hi Greg, >> >> On 2018/11/22 18:23, Greg Kroah-Hartman wrote: >>>> + >>>> + DBG_BUGON(work->nr_pages); >>>> + DBG_BUGON(work->vcnt); >>> How can these ever be triggered? I understand the need for debugging >>> code when you are writing code, but at this point it shouldn't be needed >>> anymore, right? >> >> I need to avoid some fields is not 0 when the new workgroup is created (because >> work->nr_pages and work->vcnt == 0 usually after the previous workgroup is freed). >> But that is not obvious, it is promised by the current logic. > > Then delete these lines if they can never happen :) I don't know how to observe such a race in our beta test and community users. Because if the kernel is crashed, we could collect the whole kernel dump to observe the memory and all registers, if we only have some warning, it will be not easy to get the state as early as possible. Thank, Gao Xiang > >> In order to not introduce such a issue in the future, or there are some potential >> race (work->nr_pages and work->vcnt != 0 when the previous workgroup == 0), it need >> to be noticed to developpers as early as possible. > > Then make it a real call, do not wrap it in odd macros that do not > really explain why it is "debugging only". Your code is "real" now, > make the logic real for all developers and users. > > thanks, > > greg k-h >