On Tue, Nov 29, 2016 at 9:53 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > On Thu, Nov 24, 2016 at 10:12 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >> Introduce a new test to demonstrates a known issue with overlayfs: >> - process A opens file F for read >> - process B writes new data to file F >> - process A reads old data from file F >> >> This issue is about to be fixed with a patch set by Miklos Szeredi. > > Eryu and all, > > I wanted to ask what is the common practice for introducing tests for > know issues > that are *about* to be solved. > > What is the preferred timing for merging these sort of tests? > Is it productive to have these tests merged before a fix is merged to master? > Before a fix is queued for next? > Before a fix is available? IMO adding a test doesn't hurt, it'll just indicate that the current version is broken. It doesn't have to have any synchronization with the actual fix. > I am asking because there are several known issues for overlayfs > whose fixes are in several different states of maturity and I would like > to know how to treat the tests I write for them. > > FYI, the fix for the test in this patch (test ro/rw fd data inconsistencies) > is not queued for next yet, but I am hoping it will be. > Miklos? I think it's in good shape for 4.10. I'll try to ping Al about the VFS bits. Thanks, Miklos -- 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
