11:09 a.m.
It shouldn't matter in this case, since the only behavior change is to
invalidate all. The lookup will still fail, and the write lock will be
taken, and the chunk reloaded. So, I think it's still safe.
Aside from that, there are places (the UP calls, for example) that clear
these bits with no lock at all. The bits aren't intended to be
protected by the lock.
Daniel
On 6/25/19 8:33 AM, Rungta, Vandana wrote:
For the following scenario:
Starting state for mde_flags -> TRUST_CONTENT and TRUST_DIR_CHUNKS
Thread 2 waiting for a READ LOCK
Thread 1 has a WRITE LOCK - results in clearing the TRUST_CONTENT flag and releases the
lock
Thread 2 acquires the READ LOCK -- TRUST_CONTENT is clear, but this thread assumes that
TRUST_CONTENT is true (state before it waiting on the locks).
Is the rest of the mdcache_readdir_chunked code still safe to continue? Can the result
from mdcache_avl_lookup_ck be depended on?
Thanks,
Vandana
On 6/24/19, 5:50 AM, "Daniel Gryniewicz" <dang(a)redhat.com> wrote:
It should be safe. Testing the flags is atomic, so that part is safe,
and the worst that happens is we invalidate twice, so it's still correct.
Daniel
On 6/20/19 11:46 AM, Rungta, Vandana wrote:
>
> A separate but related question:
> In mdcache_readdir_chunked towards the beginning where mde_flags are tested for
MDCACHE_TRUST_CONTENT | MDCACHE_TRUST_DIR_CHUNKS, the test is done outside the lock. It
is possible that the flags indicate that the directory content can be trusted and while
waiting for a READ_LOCK, the thread holding the WRITE_LOCK can invalidate the content. Do
the flags need to be checked after obtaining the lock and when upgrading the lock from
read to write?