Re: [PATCH 0/2] shmem: fix faulting into a hole while it's punched, take 3

[Vlastimil Babka]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/