On Mon, Jan 16, 2017 at 12:19 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > On Mon, Jan 16, 2017 at 1:00 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: >> On Sun, Jan 15, 2017 at 2:57 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >>> Factor out some common vfs bits from do_tmpfile() >>> to be used by overlayfs for concurrent copy up. >> >> I'm wondering whether the vfs helper should do everything except the >> path lookup and the open: d_alloc(), ->tmpfile() and setting >> I_LINKABLE. This will also aid in doing a ->tmpfile() for overlayfs. >> > > I started with that, but slowly trimmed it down to this minimal version. > First, mnt_want_write() can't be in there. > Then dentry * return value would be a strange deviation from other vfs_ helpers. What about lookup_one_len()? It's not called vfs_something but that's beside the point, I think. > Lastly, all the open related operations are already performed by > ovl_path_open() and I did not want to make an exception, > so I resorted to doing d_alloc in ovl_alloc_tmpfile(), which becomes > a drop-in replacement for ovl_lookup_temp() and set LINKABLE in > ovl_link_tmpfile(), which becomes a drop-in replacement for ovl_do_rename(). The logical place to set I_LINKABLE is in vfs_tmpfile(). You are arguing about overlayfs code structure, but that's mostly irrelevant when doing a new vfs interface. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
