Re: mm: shm: hang in shmem_fallocate

[Johannes Weiner]

Hi Hugh,

On Thu, Jun 26, 2014 at 10:36:20PM -0700, Hugh Dickins wrote:
> Hannes, a question for you please, I just could not make up my mind.
> In mm/truncate.c truncate_inode_pages_range(), what should be done
> with a failed clear_exceptional_entry() in the case of hole-punch?
> Is that case currently depending on the rescan loop (that I'm about
> to revert) to remove a new page, so I would need to add a retry for
> that rather like the shmem_free_swap() one?  Or is it irrelevant,
> and can stay unchanged as below?  I've veered back and forth,
> thinking first one and then the other.

I realize you have given up on changing truncate.c in the meantime,
but I'm still asking myself about the swap retry case: why retry for
swap-to-page changes, yet not for page-to-page changes?

In case faults are disabled through i_size, concurrent swapin could
still turn swap entries into pages, so I can see the need to retry.
There is no equivalent for shadow entries, though, and they can only
be turned through page faults, so no retry necessary in that case.

However, you explicitely mentioned the hole-punch case above: if that
can't guarantee the hole will be reliably cleared under concurrent
faults, I'm not sure why it would put in more effort to free it of
swap (or shadow) entries than to free it of pages.

What am I missing?
--
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/