> -----Original Message----- > From: Bill Fischofer [mailto:bill.fischo...@linaro.org] > Sent: Tuesday, January 10, 2017 3:20 PM > To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell- > labs.com> > Cc: Maxim Uvarov <maxim.uva...@linaro.org>; lng-odp-forward <lng- > o...@lists.linaro.org> > Subject: Re: [lng-odp] [API-NEXT PATCHv3] linux-generic: pool: defer ring > allocation until pool creation > > On Tue, Jan 10, 2017 at 2:17 AM, Savolainen, Petri (Nokia - FI/Espoo) > <petri.savolai...@nokia-bell-labs.com> wrote: > > > > The race condition should be avoided. That can be done easily by first > doing the shm_reserve(). If that succeeds, a pool can be allocated > normally behind the lock. > > > > shm = shm_reserve(); > > > > if (shm == invalid) > > return -1; > > > > LOCK(); > > > > // Search a free pool and reserve it (like today) > > > > UNLOCK(); > > > > if (pool == NULL) { > > shm_free(shm); > > return -1; > > } > > > > pool->ring_shm = shm; > > ... > > > > > > -Petri > > There is no race condition, but I have no objection to reworking this > as described since they are equivalent. I'll post a v2 with this and > Maxim's changes.
The race is of type that the write of pool->reserved = 0 may happen only after a very long time (omitting unlock, omits the store release fence). Other observers could see that all pools are reserved, while some might be actually free, but the write has yet propagated through CPU write buffering / caches. -Petri
