[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 2/2] xen/common: Use enhanced ASSERT_ALLOC_CONTEXT in xmalloc()


  • To: Henry Wang <Henry.Wang@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 6 May 2022 14:27:44 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4dyWkB4aRxEjKwy9UllWtQ8l0p1Mlsa1ZfrvkuDi0Ag=; b=OszG/VNJqrYXCH0Ee91tnXkfCIwa/VEUUpX2Mz/XGv2ifnTVNLBQy+8JNf5OC6isc/AmDRc1h7iPncu4UCXN93LK2HznDhZLb9tjcrNo0DwFIdGzUPG3sH51fKz+NScvYKaSr+9SbCKsDL80XxUBkpcaewJ/ERTKp5iSmT4PMw2Zd+XomfaZwC72XHN14dGtCov9K8WVDeiItffYJjdoIBPlX3pz+iR98wGvHBJeBgCLe6y6kDlRHUn7rokKSR3c+rcP/XTX30UQ2pCFykPtc2+mbaX/5yqvMYfLqRRY4s+F4RXVameMwip/Zocip4BYnL1RfyoF2ZY2/mpcK8MEaA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kJ7b/dH2oQdIGd30uIUddeoKXCi9x6jkUZm71XKsYvqvTktcuIdE4174esXHUn2pEK0DrXQANS4sUsUsTJbJTHfPJ4IcNMbTl2X+c5ekumQXZCsZPb6y7BUodHOxplBHZe8+bp4XiJ5IBcFxnaVYn9exhYEW3YhH5FLgnULF63h/CkVVS9UT93JLuF5d06anjF/ZMCf/cD210LbfB5OzhGmJYyOgxrNm8+EC3NZBu28G7AHCGTPv/l60Z4kGRqLUTkoRX7N+a86Njh59YtkY03KurPkt1DShi2j4PhX3+U+vp6LN9/xs+G3JM1A8d36BinKNEZ5C5oxXbTYdVi1ShA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Wei Chen <Wei.Chen@xxxxxxx>, Julien Grall <jgrall@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 06 May 2022 12:28:02 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 06.05.2022 14:03, Henry Wang wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@xxxxxxxx>
>> Sent: Friday, May 6, 2022 6:33 PM
>>
>> On 06.05.2022 07:52, Henry Wang wrote:
>>> --- a/xen/common/xmalloc_tlsf.c
>>> +++ b/xen/common/xmalloc_tlsf.c
>>> @@ -594,7 +594,7 @@ void *_xmalloc(unsigned long size, unsigned long
>> align)
>>>  {
>>>      void *p = NULL;
>>>
>>> -    ASSERT(!in_irq());
>>> +    ASSERT_ALLOC_CONTEXT();
>>
>> For one - what about xfree()?
> 
> Oh you are definitely correct, thanks for pointing this out. I will
> definitely change the assertion in xfree() as well in v3.
> 
>>
>> And then did you consider taking the opportunity and moving both to
>> the respective pool alloc functions, thus giving even better coverage?
> 
> Yeah I would love to. But sorry about the question (just for learning):
> I assume you are talking about code coverage, could you please kindly
> add a little bit more detail to help me understand why adding the same
> ASSERT_ALLOC_CONTEXT would help to a better coverage? Since...
> 
>> Granted there's one downside to moving it to xmem_pool_alloc(): Then
>> the early zero-size and error returns won't be covered, so maybe we
>> actually want checks in both places. 
> 
> ...after reading these I have a feeling that we need to add the same
> ASSERT_ALLOC_CONTEXT in the beginning of the xmem_pool_alloc,
> xmalloc_whole_pages, and xmem_pool_free,

xmem_pool_{alloc,free}() are what my comment was about. And "coverage"
was meant as "if the assertions were there, more [potential] call sites
would be covered". xmalloc_whole_pages(), as you ...

> while keeping
> ASSERT_ALLOC_CONTEXT in _xmalloc. I think xmem_pool_alloc and
> xmalloc_whole_pages are only called in _xmalloc and xmem_pool_free
> is only called in xfree. Adding the same assertion in these three functions
> is duplication of code?

... validly note, is of no interest in this regard, as it's (1) a static
helper and (2) would hit the checks in page_alloc.c.
xmem_pool_{alloc,free}() otoh are non-static functions, so we will want
to care about not only existing callers, but also potential future ones.

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.