Re: [PATCH v4 09/15] fanotify: cache fsid in fsnotify_mark_connector

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

 



On Fri 04-01-19 10:38:39, Jan Kara wrote:
> On Sun 02-12-18 13:38:20, Amir Goldstein wrote:
> > @@ -268,6 +289,7 @@ static int fanotify_handle_event(struct fsnotify_group *group,
> >  	int ret = 0;
> >  	struct fanotify_event *event;
> >  	struct fsnotify_event *fsn_event;
> > +	__kernel_fsid_t __fsid, *fsid = NULL;
> >  
> >  	BUILD_BUG_ON(FAN_ACCESS != FS_ACCESS);
> >  	BUILD_BUG_ON(FAN_MODIFY != FS_MODIFY);
> > @@ -300,7 +322,10 @@ static int fanotify_handle_event(struct fsnotify_group *group,
> >  			return 0;
> >  	}
> >  
> > -	event = fanotify_alloc_event(group, inode, mask, data);
> > +	if (FAN_GROUP_FLAG(group, FAN_REPORT_FID))
> > +		fsid = fanotify_get_fsid(iter_info, &__fsid);
> > +
> > +	event = fanotify_alloc_event(group, inode, mask, data, fsid);
> 
> This looks wrong? fsid is never assigned anything != NULL? How could have
> this worked?

Sorry. I understand now. But the calling convention is somewhat unusual.
Actually, since fsid is just 8 bytes anyway, why not just return is as
value? I.e. something like:

static __kernel_fsid_t fanotify_get_fsid(struct fsnotify_iter_info*iter_info)
{
...
}

You won't save any copying on 64-bit archs and I've checked and GCC will
optimize this to a standard register return convention anyway.

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR



[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