From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 128F9C43441 for ; Thu, 22 Nov 2018 11:37:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8FC7D20672 for ; Thu, 22 Nov 2018 11:37:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8FC7D20672 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390927AbeKVWQ1 (ORCPT ); Thu, 22 Nov 2018 17:16:27 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:15575 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2390867AbeKVWQ1 (ORCPT ); Thu, 22 Nov 2018 17:16:27 -0500 Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 85DDC6127E7B6; Thu, 22 Nov 2018 19:37:23 +0800 (CST) Received: from [10.151.23.176] (10.151.23.176) by smtp.huawei.com (10.3.19.214) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 22 Nov 2018 19:37:15 +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> <20181122112645.GA7527@kroah.com> From: Gao Xiang Message-ID: <4a501e48-e2a9-45ea-554b-8dc1163721fb@huawei.com> Date: Thu, 22 Nov 2018 19:37:17 +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: <20181122112645.GA7527@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:26, Greg Kroah-Hartman wrote: > On Thu, Nov 22, 2018 at 07:11:08PM +0800, Gao Xiang wrote: >> 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. > > /* > * Let developers know something went really wrong with their > * initialization code > */ > if (!work->nr_pages) { > pr_err("nr_pages == NULL!"); > WARN_ON(1); > } > if (!work->vcnt) { > pr_err("vcnt == NULL!"); > WARN_ON(1); > } > > or something like that. > > Don't make people rebuild your code with different options for > debugging. That will never work in the 'real world' when people start > using the code. You need to have things enabled for people all the > time, which is why we have dynamic debugging in the kernel now, and not > a zillion different "DRIVER_DEBUG" build options anymore. > >> 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. > > When the kernel crashes, geting a dump is hard on almost all hardware. > It is only rare systems that you can get a kernel dump. This piece of code is already used in our hisilicon beta test, all memorydump, registers, stack can be collected. Apart from that, I observed many f2fs bugs are observed in this way and many erofs bugs are collected in that way...sigh... Thanks, Gao Xiang > > thanks, > > greg k-h >