On Tue, May 19, 2015 at 09:55:54PM -0700, Jaegeuk Kim wrote: > > Looking at a glance, it's mostly same as what I wanted. The key is to share > ci->ci_ctfm for regular file and the other dir/symlink files. > So, ext4_get_encryption_info will handle most of cases. Yeah, I noticed after sending out my changes that your patches did something really similar in that regard. "Great minds run in the same channels", as the (very) old saying goes... > In ext4_readdir, it also needs ext4_get_encryption_info? No, it not needed because when the directory is opened using opendir(3), we'll end up calling ext4_get_encryption_info() in ext4_file_open() --- yes, the name is a little misleading, but it gets used for all ext4 open(2)'s. One of the things which I've been mildly concerned about is that in the no key case, we end up calling ext4_get_encrpyion_info() over and over again, which means we end up calling request_key() over and over again as well. On the other hand, we do want to use the key as soon as it becomes available, there isn't a good way of doing a negative cache on the unavailability of the logon key that could be reliably revoked the moment the user does have the key --- and the no-key case isn't the common one, so I haven't worried too much about it. But I did want to remove it from the readdir() path, since it also means that we don't have to worry about oddities stemming from half the files being returned in encrypted form, and half the files in plaintext, because the user inserted an encryption key in the while there was an "ls" running in the background. Cheers, - Ted -- 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
