On 3/23/22 1:04 AM, Matthew Wilcox wrote:
> On Mon, Mar 21, 2022 at 03:30:52PM +0000, David Howells wrote:
>> Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
>>
>>> Absolutely; just use xa_lock() to protect both setting & testing the
>>> flag.
>>
>> How should Jeffle deal with xarray dropping the lock internally in order to do
>> an allocation and then taking it again (actually in patch 5)?
>
> There are a number of ways to handle this. I'll outline two; others
> are surely possible.
Thanks.
>
> option 1:
>
> add side:
>
> xa_lock();
> if (!DEAD)
> xa_store(GFP_KERNEL);
> if (DEAD)
> xa_erase();
> xa_unlock();
>
> destroy side:
>
> xa_lock();
> set DEAD;
> xa_for_each()
> xa_erase();
> xa_unlock();
>
> That has the problem (?) that it might be temporarily possible to see
> a newly-added entry in a DEAD array.
I think this problem doesn't matter in our scenario.
>
> If that is a problem, you can use xa_reserve() on the add side, followed
> by overwriting it or removing it, depending on the state of the DEAD flag.
Right. Then even the normal path (when memory allocation succeeds) needs
to call xa_reserve() once.
>
> If you really want to, you can decompose the add side so that you always
> check the DEAD flag before doing the store, ie:
>
> do {
> xas_lock();
> if (DEAD)
> xas_set_error(-EINVAL);
> else
> xas_store();
> xas_unlock();
> } while (xas_nomem(GFP_KERNEL));
This way is more cleaner from the locking semantics, with the cost of
code duplication. However, after decomposing the __xa_alloc(), we can
also reuse the xas when setting CACHEFILES_REQ_NEW mark.
```
+ xa_lock(xa);
+ ret = __xa_alloc(xa, &id, req, xa_limit_32b, GFP_KERNEL);
+ if (!ret)
+ __xa_set_mark(xa, id, CACHEFILES_REQ_NEW);
+ xa_unlock(xa);
```
So far personally I prefer the decomposing way in our scenario.
--
Thanks,
Jeffle
--
Linux-cachefs mailing list
Linux-cachefs@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-cachefs
