Re: dcache: abstract take_name_snapshot() interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 14, 2020 at 9:19 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> On Tue, Jan 14, 2020 at 08:06:56PM +0200, Amir Goldstein wrote:
> > > // NOTE: release_dentry_name_snapshot() will be needed for both copies.
> > > clone_name_snapshot(struct name_snapshot *to, const struct name_snapshot *from)
> > > {
> > >         to->name = from->name;
> > >         if (likely(to->name.name == from->inline_name)) {
> > >                 memcpy(to->inline_name, from->inline_name,
> > >                         to->name.len);
> > >                 to->name.name = to->inline_name;
> > >         } else {
> > >                 struct external_name *p;
> > >                 p = container_of(to->name.name, struct external_name, name[0]);
> > >                 atomic_inc(&p->u.count);
> > >         }
> > > }
> > >
> > > and be done with that.  Avoids any extensions or tree-wide renamings, etc.
> >
> > I started with something like this but than in one of the early
> > revisions I needed
> > to pass some abstract reference around before cloning the name into the event,
> > but with my current patches I can get away with a simple:
> >
> > if (data_type == FANOTIFY_EVENT_NAME)
> >     clone_name_snapshot(&event->name, data);
> > else if (dentry)
> >     take_dentry_name_snapshot(&event->name, dentry);
> >
> > So that simple interface should be good enough for my needs.
>
> I really think it would be safer that way; do you want me to throw that into
> vfs.git (#work.dcache, perhaps)?  I don't have anything going on in the
> vicinity, so it's not likely to cause conflicts either way and nothing I'd
> seen posted on fsdevel seems to be likely to step into it, IIRC, so...
> Up to you.

Sure, that would be great.

Thanks,
Amir.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux