On Mon, Jan 22, 2018 at 7:39 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > Hi, > > Please find attached V10 of the metadata only copy up patches. I think > I have taken care of review comments and I will start writing automated > test cases now. > > One thing which concerns me about these patches is the fact that during > file open d_real() will return lower inode which actually contains file > data and that inode will be installed in f->f_inode. So while f->f_inode > is perfectly fine for data operations, it is not fine for metadata > operations. Because metadata has been copied up and is represented by > a different inode. > > I am concerned that this is a subtle behavior change and especially > security modules might be surprised by it. I will spend now more time > looking at what security modules are doing with f->f_inode. Thoughts? This is exactly the same situation where there is an r/o open and copy-up later. Except this makes it more widespread. So I don't think any new issues are introduced (doesn't mean there aren't any old ones). The only risk I see with this feature is exactly the fact that the ro/rw inconsistency can happen more often, which might break more cases. I'd really like to work on getting rid of this issue. Hopefully next cycle... Thanks, Miklos > -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
