upstream/opnsense-src
1
0
Fork 0
mirror of https://github.com/opnsense/src.git synced 2026-06-10 09:11:07 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Explain why the lock-free allocation algorithm is safe in our case

Browse source 
while beeing not safe in the general case. Thanks to David Schultz
<das@freebsd.org> for help.
This commit is contained in:
Hartmut Brandt 2003-10-30 16:19:50 +00:00
parent fbbdf7c7d2
commit cc3f6cb9fd
1 changed files with 18 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
sys/dev/hatm/if_hatm_intr.c
View file

@ -91,6 +91,24 @@ static void hatm_mbuf_page_alloc(struct hatm_softc *sc, u_int group);
/*
* Free an external mbuf to a list. We use atomic functions so that
* we don't need a mutex for the list.
*
* Note that in general this algorithm is not safe when multiple readers
* and writers are present. To cite from a mail from David Schultz
* <das@freebsd.org>:
*
* It looks like this is subject to the ABA problem. For instance,
* suppose X, Y, and Z are the top things on the freelist and a
* thread attempts to make an allocation. You set buf to X and load
* buf->link (Y) into a register. Then the thread get preempted, and
* another thread allocates both X and Y, then frees X. When the
* original thread gets the CPU again, X is still on top of the
* freelist, so the atomic operation succeeds. However, the atomic
* op places Y on top of the freelist, even though Y is no longer
* free.
*
* We are, however sure that we have only one thread that ever allocates
* buffers because the only place we're call from is the interrupt handler.
* Under these circumstances the code looks safe.
*/
__inline void
hatm_ext_free(struct mbufx_free **list, struct mbufx_free *buf)