On Fri, Oct 04, 2013 at 12:33:17PM -0700, Linus Torvalds wrote: > So how do people feel about passing a "mode" value for > security_inode_getattr(), the same way we do for > security_inode_permission()? The only flag would be that MAY_NOT_BLOCK > flag that gets set for RCU lookup, and the semantics would be the same > (return -ECHILD if you need to sleep). > > Attached is a patch that adds the interface, and then makes all > security layers just do that ECHILD thing (and nobody actually sets > MAY_NOT_BLOCK yet). So it's purely preparatory. It's also > insufficient, because we'll need the same kind o fflag for the > low-level filesystem "i_op->getattr()" call, but that's an independent > issue. > > Al, any comments? Just a couple of days ago you'd been complaining about filesystems exposure to rcuwalk details and now you propose to increase the contact surface by one more method? OK... For one thing, that will definitely require lazy freeing of struct super_block itself. At the very least, you want ->i_sb->s_dev, even on default pathway. Another thing is that API is wrong for that kind of stuff - we pass vfsmount/dentry pair and we end up looking at the inode guts. Fine, but in RCU case you must cope with the possibility of dentry->d_inode going NULL under you. Which isn't all that terrible, but we need to slap ACCESS_ONCE() into each method instance (all 34 of them). IOW, it's worse than just "oh, we need to add a flag"; we'll need to pass the sodding inode separately, with dire warnings not to use dentry->d_inode. It's not impossible to do, of course, but it won't be fun... Oh, well... In any case, we need something in Documentation/filesystems describing the RCU-related rules for fs writers - exposure surface, what to avoid, etc. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
