Re: [PATCH v1 1/2] LoongArch: Add missing headers

[Guo Ren]

On Mon, Sep 18, 2023 at 4:23 PM Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
>
> On Mon, Sep 18, 2023 at 04:05:50PM +0800, Huacai Chen wrote:
> > On Mon, Sep 18, 2023 at 2:49 PM Andy Shevchenko
> > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > > On Sat, Sep 16, 2023 at 08:05:52PM +0800, Huacai Chen wrote:
> > > > On Sat, Sep 16, 2023 at 6:27 PM Andy Shevchenko
> > > > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > > > > On Fri, Sep 15, 2023 at 08:36:24AM +0800, Huacai Chen wrote:
> > > > > > On Fri, Sep 15, 2023 at 2:53 AM Andy Shevchenko
> > > > > > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > > > > > > On Thu, Sep 14, 2023 at 11:25:22PM +0800, Huacai Chen wrote:
> > > > >
> > > > > > > > Thank you for your patch, can this patch solve the problem below?
> > > > > > > > https://lore.kernel.org/oe-kbuild-all/202309072237.9zxMv4MZ-lkp@xxxxxxxxx/T/#u
> > > > > > >
> > > > > > > Nope, this just adds missing includes.
> > > > > > > No functional change, so warnings will still be there.
> > > > > > But I think a patch should solve a problem.
> > > > >
> > > > > No, that problem is static analyser concern, not the compiler nor linker.
> > > > >
> > > > > > If we don't get a build
> > > > > > error or warning without this patch, does that mean the 'missing'
> > > > > > headers are actually included indirectly?
> > > > >
> > > > > I might be missing something, but I do not see any build error in the above message.
> > > > Hmm, then I think I will take the second patch only.
> > >
> > > Thanks, but can you shed a light why?
> > >
> > > The rule of thumb is to include the headers we are direct users of, we have not
> > > to imply any other inclusions done by others, unless it's kinda same family of
> > > headers (like types.h always includes compiler_types.h). Since in your case
> > > the const.h is included the other two are missing and it's even worse, as I
> > > understand you rely on the specific headers to be included _before_ using this
> > > one in the users.
> > I agree with you more or less, but I doubt there is another rule: no
> > break, no fix. Please see:
> >
> > https://lore.kernel.org/loongarch/20221024070105.306280-1-chenhuacai@xxxxxxxxxxx/T/#t
> >
> > Obviously static_key is used in page-flags.h and it really causes
> > build errors once before, but at last I removed the inclusion of
> > static_key.h to get that series merged.
>
> This is strange requirement to be honest. Doing like this is to move your
> responsibility and understanding of the code to be a burden of the person who
> volunteers cleaning up the header mess we have in the Linux kernel source tree.
>
> Since I'm the one who tries to fix some mess (in particular kernel.h), I am
> pretty much know what I am talking about from the experience.
>
> Cc'ing Guo. Guo, can you shed a light on the rationale of your comment in
> the above mentioned thread?

diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 5c02720c53a5..9cdef3944a75 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -9,6 +9,7 @@
 #include <linux/types.h>
 #include <linux/bug.h>
 #include <linux/mmdebug.h>
+#include <linux/static_key.h>
 #ifndef __GENERATING_BOUNDS_H
 #include <linux/mm_types.h>
 #include <generated/bounds.h>

My meaning is riscv needn't include the above header file to support
HVO, and I just tested the above modification with riscv, all passed,
so go ahead.

>
> --
> With Best Regards,
> Andy Shevchenko
>
>


-- 
Best Regards
 Guo Ren