From: Bjorn Helgaas <helgaas@kernel.org>
To: kernel test robot <lkp@intel.com>, kbuild-all-owner@lists.01.org
Cc: Xuesong Chen <xuesong.chen@linux.alibaba.com>,
kbuild-all@lists.01.org, linux-pci@vger.kernel.org,
Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Subject: Re: [PATCH v4 3/4] ACPI: APEI: Reserve the MCFG address for quirk ECAM implementation
Date: Mon, 1 Nov 2021 12:15:33 -0500 [thread overview]
Message-ID: <20211101171533.GA527894@bhelgaas> (raw)
In-Reply-To: <202110280656.2MEz43OU-lkp@intel.com>
[+cc linux-pci, Konstantin, since you're thinking about this area, too]
The 0-day bot seems to remove mailing lists from the recipient list,
which means reports like the one below don't become part of the public
email thread and don't get connected to the patch in patchwork. I
think this is a problem.
For example here are Xuesong's original patch, the patch in patchwork,
and the 0-day bot report:
https://lore.kernel.org/all/20211027081312.53682-1-xuesong.chen@linux.alibaba.com/
https://patchwork.kernel.org/project/linux-pci/patch/20211027081312.53682-1-xuesong.chen@linux.alibaba.com/
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org/thread/QISVC5TJIHTEMAPX7T7YXOZEDS5CBURY/
Neither the lore link nor the patchwork have any indication that the
0-day bot found a problem.
It looks like the 0-day bot sent the report to all the individual
recipients from the original patch, but it ADDED these recipients:
llvm@lists.linux.dev
kbuild-all@lists.01.org
and REMOVED these:
linux-pci@vger.kernel.org
linux-acpi@vger.kernel.org
linux-arm-kernel@lists.infradead.org
linux-kernel@vger.kernel.org
Gmail filed Xuesong's original patch and the 0-day report as spam.
That's a problem on my end, but the bigger problem is that I work from
the patchwork queue, which has no indication of the problem.
I'm sure you have a reason for removing the mailing lists. Should we
revisit that? Should I be approaching this a different way?
If a *person* responds to a patch on the list, I expect a reply-all so
the response becomes part of the thread. Why should the 0-day bot be
different?
I added linux-pci to cc, but since the 0-day report didn't go to the
list, I don't think this message will be threaded correctly on lore.
It should be part of
https://lore.kernel.org/all/20211027081035.53370-1-xuesong.chen@linux.alibaba.com/
On Thu, Oct 28, 2021 at 06:46:16AM +0800, kernel test robot wrote:
> Hi Xuesong,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on helgaas-pci/next]
> [also build test WARNING on rafael-pm/linux-next tip/x86/core arm64/for-next/core v5.15-rc7 next-20211027]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
>
> url: https://github.com/0day-ci/linux/commits/Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
> base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
> config: x86_64-randconfig-s022-20211027 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
> reproduce:
> # apt-get install sparse
> # sparse version: v0.6.4-dirty
> # https://github.com/0day-ci/linux/commit/8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
> git checkout 8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
> # save the attached .config to linux build tree
> make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/acpi/apei/
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
>
>
> sparse warnings: (new ones prefixed by >>)
> >> drivers/acpi/apei/apei-base.c:453:5: sparse: sparse: symbol 'remove_quirk_mcfg_res' was not declared. Should it be static?
> drivers/acpi/apei/apei-base.c:804:12: sparse: sparse: symbol 'arch_apei_enable_cmcff' was not declared. Should it be static?
> drivers/acpi/apei/apei-base.c:811:13: sparse: sparse: symbol 'arch_apei_report_mem_error' was not declared. Should it be static?
>
> Please review and possibly fold the followup patch.
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: kbuild-all@lists.01.org
Subject: Re: [PATCH v4 3/4] ACPI: APEI: Reserve the MCFG address for quirk ECAM implementation
Date: Mon, 01 Nov 2021 12:15:33 -0500 [thread overview]
Message-ID: <20211101171533.GA527894@bhelgaas> (raw)
In-Reply-To: <202110280656.2MEz43OU-lkp@intel.com>
[-- Attachment #1: Type: text/plain, Size: 4162 bytes --]
[+cc linux-pci, Konstantin, since you're thinking about this area, too]
The 0-day bot seems to remove mailing lists from the recipient list,
which means reports like the one below don't become part of the public
email thread and don't get connected to the patch in patchwork. I
think this is a problem.
For example here are Xuesong's original patch, the patch in patchwork,
and the 0-day bot report:
https://lore.kernel.org/all/20211027081312.53682-1-xuesong.chen(a)linux.alibaba.com/
https://patchwork.kernel.org/project/linux-pci/patch/20211027081312.53682-1-xuesong.chen(a)linux.alibaba.com/
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org/thread/QISVC5TJIHTEMAPX7T7YXOZEDS5CBURY/
Neither the lore link nor the patchwork have any indication that the
0-day bot found a problem.
It looks like the 0-day bot sent the report to all the individual
recipients from the original patch, but it ADDED these recipients:
llvm(a)lists.linux.dev
kbuild-all(a)lists.01.org
and REMOVED these:
linux-pci(a)vger.kernel.org
linux-acpi(a)vger.kernel.org
linux-arm-kernel(a)lists.infradead.org
linux-kernel(a)vger.kernel.org
Gmail filed Xuesong's original patch and the 0-day report as spam.
That's a problem on my end, but the bigger problem is that I work from
the patchwork queue, which has no indication of the problem.
I'm sure you have a reason for removing the mailing lists. Should we
revisit that? Should I be approaching this a different way?
If a *person* responds to a patch on the list, I expect a reply-all so
the response becomes part of the thread. Why should the 0-day bot be
different?
I added linux-pci to cc, but since the 0-day report didn't go to the
list, I don't think this message will be threaded correctly on lore.
It should be part of
https://lore.kernel.org/all/20211027081035.53370-1-xuesong.chen(a)linux.alibaba.com/
On Thu, Oct 28, 2021 at 06:46:16AM +0800, kernel test robot wrote:
> Hi Xuesong,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on helgaas-pci/next]
> [also build test WARNING on rafael-pm/linux-next tip/x86/core arm64/for-next/core v5.15-rc7 next-20211027]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
>
> url: https://github.com/0day-ci/linux/commits/Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
> base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
> config: x86_64-randconfig-s022-20211027 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
> reproduce:
> # apt-get install sparse
> # sparse version: v0.6.4-dirty
> # https://github.com/0day-ci/linux/commit/8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
> git checkout 8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
> # save the attached .config to linux build tree
> make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/acpi/apei/
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
>
>
> sparse warnings: (new ones prefixed by >>)
> >> drivers/acpi/apei/apei-base.c:453:5: sparse: sparse: symbol 'remove_quirk_mcfg_res' was not declared. Should it be static?
> drivers/acpi/apei/apei-base.c:804:12: sparse: sparse: symbol 'arch_apei_enable_cmcff' was not declared. Should it be static?
> drivers/acpi/apei/apei-base.c:811:13: sparse: sparse: symbol 'arch_apei_report_mem_error' was not declared. Should it be static?
>
> Please review and possibly fold the followup patch.
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
next prev parent reply other threads:[~2021-11-01 17:15 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-19 4:49 [PATCH v3 0/2] PCI MCFG consolidation and APEI resource filterin Xuesong Chen
2021-10-19 4:49 ` Xuesong Chen
2021-10-19 15:12 ` Bjorn Helgaas
2021-10-19 15:12 ` Bjorn Helgaas
2021-10-20 2:28 ` Xuesong Chen
2021-10-20 2:28 ` Xuesong Chen
2021-10-27 8:10 ` [PATCH v4 0/4] PCI MCFG consolidation and APEI resource filtering Xuesong Chen
2021-10-27 8:10 ` Xuesong Chen
2021-10-27 8:12 ` [PATCH v4 1/4] PCI: MCFG: Consolidate the separate PCI MCFG table entry list Xuesong Chen
2021-10-27 8:12 ` Xuesong Chen
2021-10-27 8:12 ` [PATCH v4 2/4] ACPI: APEI: Filter the PCI MCFG address with an arch-agnostic method Xuesong Chen
2021-10-27 8:12 ` Xuesong Chen
2021-10-27 8:13 ` [PATCH v4 3/4] ACPI: APEI: Reserve the MCFG address for quirk ECAM implementation Xuesong Chen
2021-10-27 8:13 ` Xuesong Chen
2021-10-27 22:46 ` kernel test robot
2021-10-27 22:46 ` kernel test robot
2021-10-27 22:46 ` kernel test robot
2021-11-01 17:15 ` Bjorn Helgaas [this message]
2021-11-01 17:15 ` Bjorn Helgaas
2021-11-04 2:30 ` [kbuild-all] " Rong Chen
2021-11-04 2:30 ` Rong Chen
2021-10-27 22:46 ` [RFC PATCH] ACPI: APEI: remove_quirk_mcfg_res() can be static kernel test robot
2021-10-28 4:13 ` [PATCH v4 3/4] ACPI: APEI: Reserve the MCFG address for quirk ECAM implementation kernel test robot
2021-10-29 12:38 ` kernel test robot
2021-10-27 8:13 ` [PATCH v4 4/4] PCI: MCFG: Add the MCFG entry parse log message Xuesong Chen
2021-10-27 8:13 ` Xuesong Chen
2021-11-01 2:18 ` [PATCH v4 0/4] PCI MCFG consolidation and APEI resource filtering Xuesong Chen
2021-11-01 2:18 ` Xuesong Chen
2021-11-01 9:36 ` Will Deacon
2021-11-01 9:36 ` Will Deacon
2021-11-01 12:12 ` Xuesong Chen
2021-11-01 12:12 ` Xuesong Chen
2021-11-01 12:22 ` Borislav Petkov
2021-11-01 12:22 ` Borislav Petkov
2021-11-01 13:32 ` Xuesong Chen
2021-11-01 13:32 ` Xuesong Chen
2021-11-01 13:55 ` Borislav Petkov
2021-11-01 13:55 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211101171533.GA527894@bhelgaas \
--to=helgaas@kernel.org \
--cc=kbuild-all-owner@lists.01.org \
--cc=kbuild-all@lists.01.org \
--cc=konstantin@linuxfoundation.org \
--cc=linux-pci@vger.kernel.org \
--cc=lkp@intel.com \
--cc=xuesong.chen@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.