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=-5.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 F1203C07E9B for ; Tue, 6 Jul 2021 09:49:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CBBAC6121F for ; Tue, 6 Jul 2021 09:49:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231247AbhGFJvt (ORCPT ); Tue, 6 Jul 2021 05:51:49 -0400 Received: from mga11.intel.com ([192.55.52.93]:26474 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231159AbhGFJvr (ORCPT ); Tue, 6 Jul 2021 05:51:47 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10036"; a="206078173" X-IronPort-AV: E=Sophos;i="5.83,328,1616482800"; d="scan'208";a="206078173" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2021 02:49:08 -0700 X-IronPort-AV: E=Sophos;i="5.83,328,1616482800"; d="scan'208";a="562957823" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2021 02:49:06 -0700 Received: from andy by smile with local (Exim 4.94.2) (envelope-from ) id 1m0hhN-0098Je-19; Tue, 06 Jul 2021 12:49:01 +0300 Date: Tue, 6 Jul 2021 12:49:01 +0300 From: Andy Shevchenko To: Marco Elver Cc: Andrew Morton , Alexander Potapenko , Dmitry Vyukov , pcc@google.com, Catalin Marinas , Vincenzo Frascino , Linux Kernel Mailing List , linux-mm , kasan-dev , Andrey Ryabinin , Andrey Konovalov Subject: Re: [PATCH] kasan: fix build by including kernel.h Message-ID: References: <20210705072716.2125074-1-elver@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 05, 2021 at 11:01:44AM +0200, Marco Elver wrote: > On Mon, 5 Jul 2021 at 10:50, Andy Shevchenko wrote: > > On Mon, Jul 5, 2021 at 10:28 AM Marco Elver wrote: > > > The header relies on _RET_IP_ being defined, and had > > > been receiving that definition via inclusion of bug.h which includes > > > kernel.h. However, since f39650de687e that is no longer the case and get > > > the following build error when building CONFIG_KASAN_HW_TAGS on arm64: > > > > > > In file included from arch/arm64/mm/kasan_init.c:10: > > > ./include/linux/kasan.h: In function 'kasan_slab_free': > > > ./include/linux/kasan.h:230:39: error: '_RET_IP_' undeclared (first use in this function) > > > 230 | return __kasan_slab_free(s, object, _RET_IP_, init); > > > > > > Fix it by including kernel.h from kasan.h. > > > > ...which I would like to avoid in the long term, but for now it's > > probably the best quick fix, otherwise it will require the real split > > of _RET_IP or at least rethinking its location. > > > > Reviewed-by: Andy Shevchenko > > Thanks! > > Thanks! Should be: Reviewed-by: Andy Shevchenko > > > Fixes: f39650de687e ("kernel.h: split out panic and oops helpers") > > > > P.S. I have tested the initial patch against full build of x86_64, and > > it was long time available for different CIs/build bots, none > > complained so far. > > It only manifests on arm64 when using CONFIG_KASAN_HW_TAGS mode > (requires Arm64 MTE extensions). The other 2 modes include > in kasan.h, and that seems to include kernel.h > somewhere. The HW_TAGS mode, however, doesn't receive -next testing by > a CI system AFAIK, so this was missed because it's not yet used by > many (I'd expect that to change when CPUs with MTE are more > widespread). Got it. -- With Best Regards, Andy Shevchenko