On 07/18/2014 01:34 AM, Hugh Dickins wrote: > On Thu, 17 Jul 2014, Vlastimil Babka wrote: >> On 07/15/2014 12:28 PM, Hugh Dickins wrote: >> > In the end I decided that we had better look at it as two problems, >> > the trinity faulting starvation, and the indefinite punching loop, >> > so 1/2 and 2/2 present both solutions: belt and braces. >> >> I tested that with my reproducer and it was OK, but as I already said, it's >> not trinity so I didn't observe the new problems in the first place. > > Yes, but thanks for doing so anyway. Now also tested vanilla 3.2.61, also OK. >> >> > Which may be the best for fixing, but the worst for ease of backporting. >> > Vlastimil, I have prepared (and lightly tested) a 3.2.61-based version >> > of the combination of f00cdc6df7d7 and 1/2 and 2/2 (basically, I moved >> > vmtruncate_range from mm/truncate.c to mm/shmem.c, since nothing but >> > shmem ever implemented the truncate_range method). It should give a >> >> I don't know how much stable kernel updates are supposed to care about >> out-of-tree modules, > > I suggest that stable kernel updates do not need to care about > out-of-tree modules: for so long as they are out of tree, they have > to look after their own compatibility from one version to another. > I have no desire to break them gratuitously, but it's not for me > to spend more time accommodating them. Fair enough. > Now, SLES and RHEL and other distros may have different priorities > from that: if they distribute additional filesystems, which happen to > support the ->truncate_range() method, or work with partners who supply > such filesystems, then they may want to rework the shmem-specific > vmtruncate_range() to allow for those - that's up to them. Sure, it wasn't my intention to raise any enterprise kernel specific concerns here. >> but doesn't the change mean that an out-of-tree FS >> supporting truncate_range (if such thing exists) would effectively stop >> supporting madvise(MADV_REMOVE) after this change? > > Yes, it would need to be reworked a little for them: I've not thought > through what more would need to be done. But it seems odd to me that > an out-of-tree driver would support it, when it got no take up at all > from in-tree filesystems, even from those which went on to support > hole-punching in fallocate() (until the tmpfs series brought them in). > > Or perhaps MADV_REMOVE-support is their secret sauce :-? In that case > I would expect them to support FALLOC_FL_PUNCH_HOLE already, and prefer > a backport of v3.5's merging of the madvise and fallocate routes. > >> But hey it's still madvise so maybe we don't need to care. > > That's an argument I would not use, not in Linus's kernel anyway: > users may have come to rely upon the behaviour of madvise(MADV_REMOVE): > never mind that it says "advise", I would not be happy to break them. Right. >> And I suppose kernels where >> FALLOC_FL_PUNCH_HOLE is supported, can be backported normally. > > Yes. > > Hugh > -- 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
