Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2136435imu; Fri, 23 Nov 2018 05:10:56 -0800 (PST) X-Google-Smtp-Source: AJdET5cgDlW4wSec1LLL2/z69buzN3PDj8LU5F+XhTDg0jTyvlJDJsf96w5l3VklNgC187spzxw7 X-Received: by 2002:a62:3305:: with SMTP id z5mr16181750pfz.112.1542978656557; Fri, 23 Nov 2018 05:10:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542978656; cv=none; d=google.com; s=arc-20160816; b=0Tf43GTu36NYmi+wzUAtK9v76rN5jgTO0N92oVH6LAgU8ruCdZwYX9xl0rLmi/bX1u HkwrASvTAVuoj98QlmvQR/sB4CrFsvcBp7rISl114c/Jew5k5uhl49en3IB64H98eXCL Y0GAcItcZTboeeWBgSF1sGdGuzW+ZjtCk02G1ZLRKxXX0hWuSo2W9Epg63JoTBmEvBm1 1N4eBZ58pfT68rYyiELcOwOp/sNwaXklO4/jJdu+IQnpAQV86j/8bbLH2VNxuc4dujdd ciB+LekfhqgLZt5g/4BmN/iMS6f49D1A6Mm6eruQ53c56xUf9GkE6PxEC9BmWh285BYa DdXw== 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=FT/XhuNFWP5MwU3aHx8h6mjoZj2H1ig7gppKZMVvYaY=; b=mI2/Mt2sQ+Cb8LOxLOpYuJnCeERBeR4znfsQllqgpF1Mdp5ruFg+mi+U0VWCOjAlyy cOMgT+bqbzH+AIuvZiqW77zBoSrLkyYrjdn3KPAciJI9Fjjaw3mATBz35sqsTYg3kHSl YO22wrFS3H6N4ys+ezSMc8h4lGovvmh9evXgx8BiCgTFQ+QgQPE3v2LsdW7SkXxP2jht oSUU6nY9slmqptxmGXjS3wkh/QwiE0ZhOLenhtjvESbxVQhs63psrKTDfspJpMYd0Toi nP0PL6+avhS3d5lNEVYLUOQtj7/elTezchCdBenM0uJCdiflhI881K4NORuwfVdGo1Ui ZQ5g== 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 x23si43275950pgj.247.2018.11.23.05.10.40; Fri, 23 Nov 2018 05:10:56 -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 S2390915AbeKVWQ1 (ORCPT + 99 others); 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 >