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. > > > 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. 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. > 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. > 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
