---- 在 星期五, 2020-02-14 05:28:10 Amir Goldstein <amir73il@xxxxxxxxx> 撰写 ----
> On Thu, Feb 13, 2020 at 9:12 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> >
> > On Mon, Feb 10, 2020 at 4:11 AM Chengguang Xu <cgxu519@xxxxxxxxxxxx> wrote:
> >
> > > static int ovl_mmap(struct file *file, struct vm_area_struct *vma)
> > > {
> > > struct file *realfile = file->private_data;
> > > const struct cred *old_cred;
> > > + struct inode *inode = file->f_inode;
> > > + struct ovl_copy_up_work ovl_cuw;
> > > + DEFINE_WAIT_BIT(wait, &ovl_cuw.flags, OVL_COPY_UP_PENDING);
> > > + wait_queue_head_t *wqh;
> > > int ret;
> > >
> > > + if (vma->vm_flags & MAP_SHARED &&
> > > + ovl_copy_up_shared(file_inode(file)->i_sb)) {
> > > + ovl_cuw.err = 0;
> > > + ovl_cuw.flags = 0;
> > > + ovl_cuw.dentry = file_dentry(file);
> > > + set_bit(OVL_COPY_UP_PENDING, &ovl_cuw.flags);
> > > +
> > > + wqh = bit_waitqueue(&ovl_cuw.flags, OVL_COPY_UP_PENDING);
> > > + prepare_to_wait(wqh, &wait.wq_entry, TASK_UNINTERRUPTIBLE);
> > > +
> > > + INIT_WORK(&ovl_cuw.work, ovl_copy_up_work_fn);
> > > + schedule_work(&ovl_cuw.work);
> > > +
> > > + schedule();
> > > + finish_wait(wqh, &wait.wq_entry);
> >
> > This just hides the bad lock dependency, it does not remove it.
> >
> > The solution we've come up with is arguably more complex, but it does
> > fix this properly: make overlay use its own address space operations
> > in case of a shared map.
> >
> > Amir, I lost track, do you remember what's the status of this work?
> >
>
> I'm afraid it is still standing at the side of the road where we left it...
> I haven't had any time to work on it since.
>
> The latest WIP branch is at:
> https://github.com/amir73il/linux/commits/ovl-aops-wip
>
> And summary of what it contains is at:
> https://lore.kernel.org/linux-unionfs/CAJfpegsyA4SjmtAEpkMoKsvgmW0CiEwWEAbU7v3yJztLKmC0Eg@xxxxxxxxxxxxxx/
>
> Problem is, this WIP doesn't even solve the MAP_SHARED case yet,
> but it is a big step in the direction of the design you laid out here:
> https://lore.kernel.org/linux-unionfs/CAJfpegvJU32_9_mVh7kem0s529-8Qs02fPSr4ChCC3ZJ2pRhLw@xxxxxxxxxxxxxx/
>
> Chengguang,
>
> If you are up for the task, feel free to pick up the WIP branch
> and bring it into shape for merging.
> Then we can also discuss the next steps for fixing MAP_SHARED.
Thanks for the detailed information, I'll check your branch carefully later.
>
> BTW, you did not mention why MAP_SHARED case is important
> in your workload. I'm just curious how important is it to solve it.
I haven't received any complaint about MAP_SHARED problem yet,
so it seems not important as performance/space saving in our workload.
However, if we implement overlayfs' own address space, I think we can
do further improvement for copy-up based on it. (like delay/partial copy-up)
Thanks,
Chengguang
