On Fri, Feb 8, 2019 at 10:17 PM J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Fri, Feb 08, 2019 at 10:02:43PM +0200, Amir Goldstein wrote: > > On Fri, Feb 8, 2019 at 5:51 PM J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > > > > > On Fri, Feb 08, 2019 at 04:45:46PM +0200, Amir Goldstein wrote: > > > > - check_conflicting_open() is changed to use inode_is_open_for_read() > > > > instead of checking d_count and i_count. > > > > > > Independently of the rest, I'd love to do away with those > > > d_count/i_count checks. What's inode_is_open_for_read()? > > > > > > > It would look maybe something like this: > > > > static inline bool file_is_open_for_read(const struct inode *file) > > { > > struct inode *inode = file_inode(file); > > int countself = (file->f_mode & (FMODE_READ | FMODE_WRITE)) == > > FMODE_READ) ? 1 : 0; > > > > return atomic_read(&inode->i_readcount) > countself; > > } > > > > And it would allow for acquiring F_WRLCK lease if other > > instances of inode are open O_PATH. > > A slight change of semantics that seems harmless(?) > > and will allow some flexibility. > > How did I not know about i_readcount? (Looking) I guess it would mean > adding some dependence on CONFIG_IMA, hm. > Yes, or we remove ifdef CONFIG_IMA from i_readcount. I am not sure if the concern was size of struct inode (shouldn't increase on 64bit arch) or the accounting on open/close. The impact doesn't look significant (?).. Thanks, Amir.