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