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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 A2E1BC432C0 for ; Tue, 26 Nov 2019 01:35:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 884822082F for ; Tue, 26 Nov 2019 01:35:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727217AbfKZBfH (ORCPT ); Mon, 25 Nov 2019 20:35:07 -0500 Received: from mga06.intel.com ([134.134.136.31]:46727 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727166AbfKZBfH (ORCPT ); Mon, 25 Nov 2019 20:35:07 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Nov 2019 17:35:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,243,1571727600"; d="scan'208";a="202561180" Received: from pl-dbox.sh.intel.com (HELO intel.com) ([10.239.13.128]) by orsmga008.jf.intel.com with ESMTP; 25 Nov 2019 17:35:03 -0800 Date: Tue, 26 Nov 2019 09:42:10 +0800 From: Philip Li To: Nick Desaulniers Cc: Dennis Zhou , Chen Rong , kbuild@lists.01.org, clang-built-linux , kbuild test robot , kbuild-all@lists.01.org, David Sterba , Chris Mason , Josef Bacik , Omar Sandoval , kernel-team@fb.com, linux-btrfs@vger.kernel.org Subject: Re: [PATCH 05/22] btrfs: add the beginning of async discard, discard workqueue Message-ID: <20191126014209.GB21240@intel.com> References: <201911220351.HPI9gxNo%lkp@intel.com> <20191125185931.GA30548@dennisz-mbp.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Mon, Nov 25, 2019 at 11:39:08AM -0800, Nick Desaulniers wrote: > On Mon, Nov 25, 2019 at 10:59 AM Dennis Zhou wrote: > > > > On Thu, Nov 21, 2019 at 08:27:43PM -0800, Nick Desaulniers wrote: > > > Hi Dennis, > > > Below is a 0day bot report from a build w/ Clang. Warning looks legit, > > > can you please take a look? > > > > > > > Ah thanks for this! Yeah that was a miss when I switched from flags -> > > an enum and didn't update the declaration properly. I'll be sending out > > a v4 as another fix for arm has some rebase conflicts. > > > > Is there a way to enable so I get these emails directly? > > + Rong, Philip > > The reports have only been sent to our mailing list where we've been > manually triaging them. The issue with enabling them globally was > that the script to reproduce the warning still doesn't mention how to > build w/ Clang. Thanks Nick for continuous caring on this. One thing we initially worry is how to avoid duplicated reports to developer, like the one that can be same as gcc's finding. We haven't found a way to effectively handle this. > > In general the reports have been high value (I ignore most reports > with -Wimplicit-function-declaration, which is the most frequent as it > shows the patch was not compile tested at all). Do we mean the report with -Wimplicit-function-declaration can be duplicated to gcc, so we can ignore them to avoid duplication to developer? > > Rong, Philip, it's been a while since we talked about this last. Is > there a general timeline of when these reports will be turned on > globally? Even if the directions to reproduce aren't quite right, For the timeline, it's not decided due to the duplication concern. We tend to look into next year after other priorities are solved for this year. > generally there's enough info in the existing bugs where authors can > rewrite their patch without even needing to rebuild with Clang (though > having correct directions to reproduce would be nice, we could wait > until someone asked for them explicitly). > > -- > Thanks, > ~Nick Desaulniers