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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 8 Jul 2021 09:16:26 +0300 From: Amir Goldstein <amir73il@...il.com> To: Jan Kara <jack@...e.cz> Cc: Gabriel Krisman Bertazi <krisman@...labora.com>, "Darrick J. Wong" <djwong@...nel.org>, Theodore Tso <tytso@....edu>, Dave Chinner <david@...morbit.com>, Jan Kara <jack@...e.com>, David Howells <dhowells@...hat.com>, Khazhismel Kumykov <khazhy@...gle.com>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, Ext4 <linux-ext4@...r.kernel.org>, kernel@...labora.com Subject: Re: [PATCH v3 04/15] fanotify: Split superblock marks out to a new cache On Wed, Jul 7, 2021 at 11:13 PM Jan Kara <jack@...e.cz> wrote: > > On Tue 29-06-21 15:10:24, Gabriel Krisman Bertazi wrote: > > FAN_ERROR will require an error structure to be stored per mark. But, > > since FAN_ERROR doesn't apply to inode/mount marks, it should suffice to > > only expose this information for superblock marks. Therefore, wrap this > > kind of marks into a container and plumb it for the future. > > > > Signed-off-by: Gabriel Krisman Bertazi <krisman@...labora.com> > > ... > > > -static void fanotify_free_mark(struct fsnotify_mark *fsn_mark) > > +static void fanotify_free_mark(struct fsnotify_mark *mark) > > { > > - kmem_cache_free(fanotify_mark_cache, fsn_mark); > > + if (mark->flags & FSNOTIFY_MARK_FLAG_SB) { > > + struct fanotify_sb_mark *fa_mark = FANOTIFY_SB_MARK(mark); > > + > > + kmem_cache_free(fanotify_sb_mark_cache, fa_mark); > > + } else { > > + kmem_cache_free(fanotify_mark_cache, mark); > > + } > > } > > Frankly, I find using mark->flags for fanotify internal distinction of mark > type somewhat ugly. Even more so because fsnotify_put_mark() could infer > the mark type information from mark->conn->type and pass it to the freeing > function. But the passing would be somewhat non-trivial so probably we can > leave that for some other day. But the fact that FSNOTIFY_MARK_FLAG_SB is > set inside fsnotify-backend specific code is a landmine waiting just for > another backend to start supporting sb marks, not set > FSNOTIFY_MARK_FLAG_SB, and some generic code depend on checking > FSNOTIFY_MARK_FLAG_SB instead of mark->conn->type. > > So I see two sensible solutions: > > a) Just admit this is fanotify private flag, carve out some flags from > mark->flags as backend private and have FANOTIFY_MARK_FLAG_SB in that space > (e.g. look how include/linux/buffer_head.h has flags upto BH_PrivateStart, > then e.g. include/linux/jbd2.h starts its flags from BH_PrivateStart > further). > > b) Make a rule that mark connector type is also stored in mark->flags. We > have plenty of space there so why not. Then fsnotify_add_mark_locked() has > to store type into the flags. > > Pick your poison :) I find option a) more flexible for future expansion. This way fanotify could potentially allocate "normal" sb marks (e.g. if not FAN_REPORT_FID) and "private" sb marks otherwise (not that I recommend it - this was just an example) Also, it is far less fsnotify code changes: #define FSNOTIFY_MARK_FLAG_ATTACHED 0x04 +/* Backend private flags */ +#define FSNOTIFY_MARK_FLAG_PRIVATE(x) (0x100 + (x)) [...] +#define FANOTIFY_MARK_FLAG_SB FSNOTIFY_MARK_FLAG_PRIVATE(0x01) + +struct fanotify_sb_mark { + struct fsnotify_mark fsn_mark; +}; + Thanks, Amir.
Powered by blists - more mailing lists