From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:41082 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728477AbeIQWOg (ORCPT ); Mon, 17 Sep 2018 18:14:36 -0400 Date: Mon, 17 Sep 2018 18:46:23 +0200 From: Jan Kara To: Richard Guy Briggs Cc: Jan Kara , Paul Moore , Al Viro , linux-audit@redhat.com, linux-fsdevel@vger.kernel.org, Amir Goldstein Subject: Re: [PATCH 09/11] audit: Allocate fsnotify mark independently of chunk Message-ID: <20180917164623.GC10257@quack2.suse.cz> References: <20180904160632.21210-1-jack@suse.cz> <20180904160632.21210-10-jack@suse.cz> <20180914140909.4q77jy2nuqes2azt@madcap2.tricolour.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180914140909.4q77jy2nuqes2azt@madcap2.tricolour.ca> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri 14-09-18 10:09:09, Richard Guy Briggs wrote: > On 2018-09-04 18:06, Jan Kara wrote: > > Allocate fsnotify mark independently instead of embedding it inside > > chunk. This will allow us to just replace chunk attached to mark when > > growing / shrinking chunk instead of replacing mark attached to inode > > which is a more complex operation. > > > > Signed-off-by: Jan Kara > > --- ... > > +static struct audit_chunk *mark_chunk(struct fsnotify_mark *mark) > > +{ > > + return audit_mark(mark)->chunk; > > +} > > + > > static void audit_tree_destroy_watch(struct fsnotify_mark *entry) > > { > > - struct audit_chunk *chunk = container_of(entry, struct audit_chunk, mark); > > + struct audit_chunk *chunk = mark_chunk(entry); > > audit_mark_put_chunk(chunk); > > + kmem_cache_free(audit_tree_mark_cachep, audit_mark(entry)); > > +} > > + > > +static struct fsnotify_mark *alloc_mark(void) > > +{ > > + struct audit_tree_mark *mark; > > Would it make sense to call this local variable "amark" to indicate it > isn't a struct fsnotify_mark, but in fact an audit helper variant? > > > + > > + mark = kmem_cache_zalloc(audit_tree_mark_cachep, GFP_KERNEL); > > + if (!mark) > > + return NULL; > > + fsnotify_init_mark(&mark->mark, audit_tree_group); > > + mark->mark.mask = FS_IN_IGNORED; > > + return &mark->mark; > > There are no other places where it is used in this patch to name a > variable, but this one I found a bit confusing to follow the > "mark->mark" Yeah, makes sense. I can do the change. Honza -- Jan Kara SUSE Labs, CR