Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <fea8677b-348a-dd67-4eac-12c547afa00d@gmx.de>
Date:   Thu, 27 Jul 2023 07:23:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Subject: Re: mm/kfence/kfence_test.c:287 test_alloc() warn: use 'gfp' here
 instead of GFP_KERNEL?
Content-Language: en-US
To:     Dan Carpenter <dan.carpenter@linaro.org>,
        oe-kbuild@lists.linux.dev, Marco Elver <elver@google.com>,
        Hyeonggon Yoo <42.hyeyoo@gmail.com>
Cc:     lkp@intel.com, oe-kbuild-all@lists.linux.dev,
        linux-kernel@vger.kernel.org
References: <9e72b7ea-9598-415d-bc55-f2f42b7fcb3b@kadam.mountain>
From:   Helge Deller <deller@gmx.de>
In-Reply-To: <9e72b7ea-9598-415d-bc55-f2f42b7fcb3b@kadam.mountain>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:GM5V8VKyGsU=;6Zmw/GchiKIohQKoDtRfZPJ/A/x
 MhL+ufBurSSyoDGbVj371Rf4t8YAfyvvLfrS1Y1CFZiMNw0eyfZb3tDV/gMlAMbAIDwf0tiMo
 rXKRMrl2mCe6OrHsH3yuwSq9AHAVN4CJ5mXHhxA5zM3ugCXsK54HGJoqR5d59UdhnQfWTHDed
 gRWJlEXeWr4Krih6k4mKk0Zy0Uj+hdx+5GGPWtVY6dveDAcbQCHwJJfYGl+cc4GQCax0z0iQA
 sFz88QWgQTekHWQuhrJd89syUoGrAhjL/Tz4sBkj74fVEx9GCRF0TiyEJfibm51Bw650KJhSJ
 qYme21NcfHv1nYmO37pIUJxEuStSzKoPcpiYjgoqHv6fWmeijjWhRbWruVQ7379JpqzJAmR0D
 0nn7JvF6U6ebHp8VshmT/4Gij92OAOMpmKIeAJNhlvaK5cTZFDydNempeg/+AHS57B+M/hNWB
 1Fow3qS+43/BBp7no08KaKeWRcFP6JNsNKLtuhHLHECej8OBjT6qrodcaKEjGz7y656GxmYGE
 CqZXHSNcQ9fQWRoPWOlWlDYEcc6MfmDjeTt/MCAczowakUflWz212jWAEub+y1YoblomlsVEE
 G9PoRL8CSvyErErVcJ3uaiahYanzJNzj1xHL5XhgXsQ9SYYmoDP6PYnGpmRCPGK9BRXFA9pbK
 yQYXdfaww62TRhrL98M0jhObL/0Qp3Gc/pjfLBdjjwr2gq8Ydlro+6NiScF0fxtrrvb4qHRwh
 tN0caya5Qw9femg4NvsEFd5mugTYD9Q9U8WaPgFZTpIPP569HZqD3gLr1t1NBDidRS10H0pkG
 zPvYG6mn0FqkQzV/bRIdisVkVEsmOmWAwV3NjhJv7+rV5yesaZIsdK3fwuBQuJnEXxBSSGUxB
 eujv9UZsHzmdfzZ478+sLV1UjmFA4EaEZYOWQN9LT7QNjeS1eww0KnoJsMn5G3730uM7utcwV
 SAHr8toM19n5uDlSzaxkQwOUYD8=
Precedence: bulk

On 7/27/23 06:51, Dan Carpenter wrote:
> Hi Helge,
>
> FYI, the error/warning was bisected to this commit, please ignore it if =
it's irrelevant.
>
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.g=
it master
> head:   18b44bc5a67275641fb26f2c54ba7eef80ac5950
> commit: adf8e96a7ea670d45b5de7594acc67e8f4787ae6 parisc: Enable LOCKDEP =
support
> config: parisc-randconfig-m041-20230726 (https://download.01.org/0day-ci=
/archive/20230727/202307270305.L19EfaJD-lkp@intel.com/config)
> compiler: hppa-linux-gcc (GCC) 12.3.0
> reproduce: (https://download.01.org/0day-ci/archive/20230727/20230727030=
5.L19EfaJD-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new ver=
sion of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> | Closes: https://lore.kernel.org/r/202307270305.L19EfaJD-lkp@intel.com/
>
> smatch warnings:
> mm/kfence/kfence_test.c:287 test_alloc() warn: use 'gfp' here instead of=
 GFP_KERNEL?
>
> (Just included these for the LOLs)
> mm/kfence/kfence_test.c:395 test_double_free() error: double free of 'ex=
pect.addr'
> mm/kfence/kfence_test.c:671 test_memcache_typesafe_by_rcu() error: deref=
erencing freed memory 'expect.addr'
>
> vim +/gfp +287 mm/kfence/kfence_test.c
>
> bc8fbc5f305aec Marco Elver     2021-02-25  243  static void *test_alloc(=
struct kunit *test, size_t size, gfp_t gfp, enum allocation_policy policy)
> bc8fbc5f305aec Marco Elver     2021-02-25  244  {
> bc8fbc5f305aec Marco Elver     2021-02-25  245  	void *alloc;
> bc8fbc5f305aec Marco Elver     2021-02-25  246  	unsigned long timeout, =
resched_after;
> bc8fbc5f305aec Marco Elver     2021-02-25  247  	const char *policy_name=
;
> bc8fbc5f305aec Marco Elver     2021-02-25  248
> bc8fbc5f305aec Marco Elver     2021-02-25  249  	switch (policy) {
> bc8fbc5f305aec Marco Elver     2021-02-25  250  	case ALLOCATE_ANY:
> bc8fbc5f305aec Marco Elver     2021-02-25  251  		policy_name =3D "any";
> bc8fbc5f305aec Marco Elver     2021-02-25  252  		break;
> bc8fbc5f305aec Marco Elver     2021-02-25  253  	case ALLOCATE_LEFT:
> bc8fbc5f305aec Marco Elver     2021-02-25  254  		policy_name =3D "left"=
;
> bc8fbc5f305aec Marco Elver     2021-02-25  255  		break;
> bc8fbc5f305aec Marco Elver     2021-02-25  256  	case ALLOCATE_RIGHT:
> bc8fbc5f305aec Marco Elver     2021-02-25  257  		policy_name =3D "right=
";
> bc8fbc5f305aec Marco Elver     2021-02-25  258  		break;
> bc8fbc5f305aec Marco Elver     2021-02-25  259  	case ALLOCATE_NONE:
> bc8fbc5f305aec Marco Elver     2021-02-25  260  		policy_name =3D "none"=
;
> bc8fbc5f305aec Marco Elver     2021-02-25  261  		break;
> bc8fbc5f305aec Marco Elver     2021-02-25  262  	}
> bc8fbc5f305aec Marco Elver     2021-02-25  263
> bc8fbc5f305aec Marco Elver     2021-02-25  264  	kunit_info(test, "%s: s=
ize=3D%zu, gfp=3D%x, policy=3D%s, cache=3D%i\n", __func__, size, gfp,
> bc8fbc5f305aec Marco Elver     2021-02-25  265  		   policy_name, !!test=
_cache);
> bc8fbc5f305aec Marco Elver     2021-02-25  266
> bc8fbc5f305aec Marco Elver     2021-02-25  267  	/*
> bc8fbc5f305aec Marco Elver     2021-02-25  268  	 * 100x the sample inte=
rval should be more than enough to ensure we get
> bc8fbc5f305aec Marco Elver     2021-02-25  269  	 * a KFENCE allocation =
eventually.
> bc8fbc5f305aec Marco Elver     2021-02-25  270  	 */
> 8913c610014823 Peng Liu        2022-02-11  271  	timeout =3D jiffies + m=
secs_to_jiffies(100 * kfence_sample_interval);
> bc8fbc5f305aec Marco Elver     2021-02-25  272  	/*
> bc8fbc5f305aec Marco Elver     2021-02-25  273  	 * Especially for non-p=
reemption kernels, ensure the allocation-gate
> bc8fbc5f305aec Marco Elver     2021-02-25  274  	 * timer can catch up: =
after @resched_after, every failed allocation
> bc8fbc5f305aec Marco Elver     2021-02-25  275  	 * attempt yields, to e=
nsure the allocation-gate timer is scheduled.
> bc8fbc5f305aec Marco Elver     2021-02-25  276  	 */
> 8913c610014823 Peng Liu        2022-02-11  277  	resched_after =3D jiffi=
es + msecs_to_jiffies(kfence_sample_interval);
> bc8fbc5f305aec Marco Elver     2021-02-25  278  	do {
> bc8fbc5f305aec Marco Elver     2021-02-25  279  		if (test_cache)
> bc8fbc5f305aec Marco Elver     2021-02-25  280  			alloc =3D kmem_cache_=
alloc(test_cache, gfp);
> bc8fbc5f305aec Marco Elver     2021-02-25  281  		else
> bc8fbc5f305aec Marco Elver     2021-02-25  282  			alloc =3D kmalloc(siz=
e, gfp);
>                                                                         =
                       ^^^
>
> bc8fbc5f305aec Marco Elver     2021-02-25  283
> bc8fbc5f305aec Marco Elver     2021-02-25  284  		if (is_kfence_address(=
alloc)) {
> 8dae0cfed57357 Vlastimil Babka 2021-11-03  285  			struct slab *slab =3D=
 virt_to_slab(alloc);
> 588c7fa022d7b2 Hyeonggon Yoo   2021-06-28  286  			struct kmem_cache *s =
=3D test_cache ?:
> 588c7fa022d7b2 Hyeonggon Yoo   2021-06-28 @287  					kmalloc_caches[kmal=
loc_type(GFP_KERNEL)][__kmalloc_index(size, false)];
>                                                                         =
                                             ^^^^^^^^^^
> I feel like using gfp might be correct but I'm not sure?  This code
> is from prior to this commit.  Let's add Marco to the CC.

Since this is a test program, I assume that "GFP_KERNEL" is used intention=
ally
instead of "gfp" here to check if the "kmalloc(size, gfp)" above gets the =
right kmalloc_caches[].
If so, is there a way to silence the smatch warning ("mm/kfence/kfence_tes=
t.c:287 test_alloc() warn: use 'gfp' here instead of GFP_KERNEL?") ?
But I'm not sure either, so adding Hyeonggon to the CC too...

Helge