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

[Hugh Dickins <hughd@google.com>]

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>