linux-kernel - Re: [PATCH -v3 0/8] file notification: fsnotify a unified file notification backend

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 25 Nov 2008 21:00:51 -0500
From:	Eric Paris <eparis@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
	viro@...iv.linux.org.uk, alan@...rguk.ukuu.org.uk,
	arjan@...radead.org, hch@...radead.org, a.p.zijlstra@...llo.nl
Subject: Re: [PATCH -v3 0/8] file notification: fsnotify a unified file
 notification backend

On Tue, 2008-11-25 at 16:14 -0800, Andrew Morton wrote:
> On Tue, 25 Nov 2008 12:20:51 -0500
> Eric Paris <eparis@...hat.com> wrote:
> 
> > This series only reimplements dnotify using the new fsnotify backend.  If
> > accepted I will do the work to port inotify as well.  Currently struct inode
> > goes from:
> > 
> > #ifdef CONFIG_DNOTIFY
> >        unsigned long           i_dnotify_mask; /* Directory notify events */
> >        struct dnotify_struct   *i_dnotify; /* for directory notifications */
> > #endif
> > 
> > to:
> > #ifdef CONFIG_FSNOTIFY
> >        unsigned long           i_fsnotify_mask; /* all events this inode cares about */
> >        struct list_head        i_fsnotify_mark_entries; /* fsnotify mark entries */
> >        spinlock_t              i_fsnotify_lock; /* protect the entries list */
> > #endif
> > 
> > so the inode still grows, but the inotify fields will be dropped as well
> > resulting in a smaller struct inode.  These are all the fields fanotify will
> > want as well.
> 
> Did you consider using i_lock to protect that list?  Its mandate is "an
> innermost lock which protects fields within the inode".

I didn't really consider it. It absolutely could be used.  Currently
dnotify used the i_lock and inotify uses it's own smaller mutex.  If
people like I can try to run some perf tests between using i_lock and
this smaller lock and would gladly send a patch on top of this set to
drop the i_fsnotify_lock.

> > 29 files changed, 3100 insertions(+), 1977 deletions(-)
> 
> 	if (code > code_reviewers)
> 		fix();
> 
> but how?

patch #1 does nothing but move dnotify and inotify...
14 files changed, 1929 insertions(+), 1925 deletions(-)

So that total number seems worse than it is (but I'll agree that all of
this for no new functionality sucks.  But at least I promise a smaller
inode struct at the end!

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/