在 2023/3/28 22:12, David Howells 写道:
Jia Zhu <zhujia.zj@xxxxxxxxxxxxx> wrote:
+ struct cachefiles_object *object =
+ ((struct cachefiles_ondemand_info *)work)->object;
container_of().
Thanks, will revise it.
+ continue;
+ } else if (cachefiles_ondemand_object_is_reopening(object)) {
The "else" is unnecessary.
Will remove it.
+static void ondemand_object_worker(struct work_struct *work)
+{
+ struct cachefiles_object *object =
+ ((struct cachefiles_ondemand_info *)work)->object;
+
+ cachefiles_ondemand_init_object(object);
+}
I can't help but feel there's some missing exclusion/locking.
It's indeed kind of complicated here since the async operation.
Thus we paid much attention to catching the race scenarios during coding
and reviewing.
Here are several corner case have been considered:
1. Don't repeatedly push the @work of same object into workqueue:
Use <reopening> state to represent this object. Once the object is
set to <reopening> atomicly, which means the work has been pushed to
workqueue. And other concurrent threads will not pick the <reopening>
object to workqueue.
2. Don't repeatedly set <reopening> state for the same object:
Hold the xa_lock during searching reqs and setting it to <reopening>.
Once object is set to <reopening>, the same object will be skipped.
3. etc.
Would you mind providing more hints for this issue?
This feels like
it really ought to be driven from the fscache object state machine.
It's a great idea. But the problem is if we add a new state to indicate
this reopening status and use fscache state machine to drive the cookie
to do reopen(), thus reopen() (in fscache module) ought to invoke
cachefiles_ondemand_init_object() (in cachefile module) to require user
daemon to open the backend file.
But it seems that fscache module should not depend on cachefiles module.
--
Linux-cachefs mailing list
Linux-cachefs@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-cachefs
