Received-SPF: pass (google.com: domain of linux-kernel+bounces-60358-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Sat, 10 Feb 2024 17:59:52 +0800
From: kernel test robot <lkp@intel.com>
To: Oscar Salvador <osalvador@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
	Linux Memory Management List <linux-mm@kvack.org>,
	linux-kernel@vger.kernel.org, Michal Hocko <mhocko@suse.com>,
	Vlastimil Babka <vbabka@suse.cz>, Marco Elver <elver@google.com>,
	Andrey Konovalov <andreyknvl@gmail.com>,
	Alexander Potapenko <glider@google.com>,
	Oscar Salvador <osalvador@suse.de>
Subject: Re: [PATCH v7 1/4] lib/stackdepot: Move stack_record struct
 definition into the header
Message-ID: <202402101724.VBz4JA0y-lkp@intel.com>
References: <20240208234539.19113-2-osalvador@suse.de>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240208234539.19113-2-osalvador@suse.de>

Hi Oscar,

kernel test robot noticed the following build errors:

[auto build test ERROR on akpm-mm/mm-nonmm-unstable]
[also build test ERROR on linus/master v6.8-rc3]
[cannot apply to akpm-mm/mm-everything next-20240209]
[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#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Oscar-Salvador/lib-stackdepot-Move-stack_record-struct-definition-into-the-header/20240209-074611
base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-nonmm-unstable
patch link:    https://lore.kernel.org/r/20240208234539.19113-2-osalvador%40suse.de
patch subject: [PATCH v7 1/4] lib/stackdepot: Move stack_record struct definition into the header
config: mips-xway_defconfig (https://download.01.org/0day-ci/archive/20240210/202402101724.VBz4JA0y-lkp@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project ac0577177f053ba7e7016e1b7e44cf5932d00b03)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240210/202402101724.VBz4JA0y-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202402101724.VBz4JA0y-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from arch/mips/kernel/asm-offsets.c:15:
   In file included from include/linux/mm.h:22:
   In file included from include/linux/page_ext.h:7:
>> include/linux/stackdepot.h:59:25: error: use of undeclared identifier 'CONFIG_STACKDEPOT_MAX_FRAMES'
      59 |                 unsigned long entries[CONFIG_STACKDEPOT_MAX_FRAMES];    /* Frames */
         |                                       ^
   1 error generated.
   make[3]: *** [scripts/Makefile.build:116: arch/mips/kernel/asm-offsets.s] Error 1
   make[3]: Target 'prepare' not remade because of errors.
   make[2]: *** [Makefile:1191: prepare0] Error 2
   make[2]: Target 'prepare' not remade because of errors.
   make[1]: *** [Makefile:240: __sub-make] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [Makefile:240: __sub-make] Error 2
   make: Target 'prepare' not remade because of errors.


vim +/CONFIG_STACKDEPOT_MAX_FRAMES +59 include/linux/stackdepot.h

    51	
    52	struct stack_record {
    53		struct list_head hash_list;	/* Links in the hash table */
    54		u32 hash;			/* Hash in hash table */
    55		u32 size;			/* Number of stored frames */
    56		union handle_parts handle;	/* Constant after initialization */
    57		refcount_t count;
    58		union {
  > 59			unsigned long entries[CONFIG_STACKDEPOT_MAX_FRAMES];	/* Frames */
    60			struct {
    61				/*
    62				 * An important invariant of the implementation is to
    63				 * only place a stack record onto the freelist iff its
    64				 * refcount is zero. Because stack records with a zero
    65				 * refcount are never considered as valid, it is safe to
    66				 * union @entries and freelist management state below.
    67				 * Conversely, as soon as an entry is off the freelist
    68				 * and its refcount becomes non-zero, the below must not
    69				 * be accessed until being placed back on the freelist.
    70				 */
    71				struct list_head free_list;	/* Links in the freelist */
    72				unsigned long rcu_state;	/* RCU cookie */
    73			};
    74		};
    75	};
    76	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki