EVL Heap

EVL Heap

[Russell Johnson]

[-- Attachment #1.1: Type: text/plain, Size: 937 bytes --]

Hello,

 

From what I understand about the EVL Heap, only EVL threads should be
accessing it in order to allocate and free memory (along with some other
operations). At the very least because those functions use an EVL mutex
behind the scenes which you definitely need to be an EVL thread to use. At
the moment, I noticed that at least in the evl_alloc_block and
evl_free_block functions in libevl, the return value of the lock/unlock
calls on the EVL heap is not checked. So technically you could have a
non-EVL thread call alloc or free and appear to work (even though the mutex
lock/unlock fails). Is it worth catching the error codes from the
lock/unlock calls in those functions and setting errno or erroring in some
way so that the user knows exactly what the problem is (mutex failed due to
not being an EVL thread)? I am assuming there was probably a reason for not
doing this, but I was just curious. 

 

Thanks,

 

Russell


[-- Attachment #1.2: Type: text/html, Size: 2555 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6759 bytes --]

Re: EVL Heap

[Philippe Gerum]

Russell Johnson <russell.johnson@kratosdefense.com> writes:

> [[S/MIME Signed Part:Undecided]]
> Hello,
>
>  
>
> From what I understand about the EVL Heap, only EVL threads should be accessing it in order to allocate and free memory (along with some
> other operations). At the very least because those functions use an EVL mutex behind the scenes which you definitely need to be an EVL
> thread to use. At the moment, I noticed that at least in the evl_alloc_block and evl_free_block functions in libevl, the return value of the
> lock/unlock calls on the EVL heap is not checked. So technically you could have a non-EVL thread call alloc or free and appear to work (even
> though the mutex lock/unlock fails). Is it worth catching the error codes from the lock/unlock calls in those functions and setting errno or
> erroring in some way so that the user knows exactly what the problem is (mutex failed due to not being an EVL thread)? I am assuming there
> was probably a reason for not doing this, but I was just curious. 
>

There was no reason aside of sloppiness. In fact, we should check
evl_lock_mutex(), we may assume unlock is going to work if locking did,
unless the situation is desperate with a rampant memory corruption at
work or a kernel bug of some sort, in which case we'd be toast anyway
(besides, unlocking happens after the allocation/deallocation has
succeeded, so returning an error code there would be confusing, and
logically wrong).

There may be another aspect to consider: should we leave
locking/unlocking to the caller instead? Originally, I thought that the
heap code would know better about fine grained locking. Now, looking at
the actual code, it looks like only a small lightweight portion of the
code escapes the locked sections, so we could leave locking to the
caller/user, which would also allow the application to define lockless
heaps.

-- 
Philippe.

RE: [External] - Re: EVL Heap

[Russell Johnson]

[-- Attachment #1: Type: text/plain, Size: 2801 bytes --]

Fair point. I do think that if the locking stays in libevl, that it should
definitely check the return of the lock call and report back to the user to
avoid silent errors and unknown behavior. I
also do see how it may make sense to just have the user handle the locking
and unlocking at the end of the day. I suppose you could support both APIs -
one that has the EVL heap handle locking and one that has the user handle
locking if you really wanted to be versatile. I am happy with either way.

Thanks,

Russell

-----Original Message-----
From: Philippe Gerum <rpm@xenomai.org> 
Sent: Friday, July 29, 2022 6:49 AM
To: Russell Johnson <russell.johnson@kratosdefense.com>
Cc: xenomai@lists.linux.dev
Subject: [External] - Re: EVL Heap

CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know the
content is safe.


Russell Johnson <russell.johnson@kratosdefense.com> writes:

> [[S/MIME Signed Part:Undecided]]
> Hello,
>
>
>
> From what I understand about the EVL Heap, only EVL threads should be 
> accessing it in order to allocate and free memory (along with some 
> other operations). At the very least because those functions use an 
> EVL mutex behind the scenes which you definitely need to be an EVL 
> thread to use. At the moment, I noticed that at least in the 
> evl_alloc_block and evl_free_block functions in libevl, the return 
> value of the lock/unlock calls on the EVL heap is not checked. So
technically you could have a non-EVL thread call alloc or free and appear to
work (even though the mutex lock/unlock fails). Is it worth catching the
error codes from the lock/unlock calls in those functions and setting errno
or erroring in some way so that the user knows exactly what the problem is
(mutex failed due to not being an EVL thread)? I am assuming there was
probably a reason for not doing this, but I was just curious.
>

There was no reason aside of sloppiness. In fact, we should check
evl_lock_mutex(), we may assume unlock is going to work if locking did,
unless the situation is desperate with a rampant memory corruption at work
or a kernel bug of some sort, in which case we'd be toast anyway (besides,
unlocking happens after the allocation/deallocation has succeeded, so
returning an error code there would be confusing, and logically wrong).

There may be another aspect to consider: should we leave locking/unlocking
to the caller instead? Originally, I thought that the heap code would know
better about fine grained locking. Now, looking at the actual code, it looks
like only a small lightweight portion of the code escapes the locked
sections, so we could leave locking to the caller/user, which would also
allow the application to define lockless heaps.

--
Philippe.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6759 bytes --]