···849849 return error;850850 truncate_setsize(inode, newsize);851851852852+ /*853853+ * The "we can't serialise against page faults" pain gets worse.854854+ *855855+ * If the file is mapped then we have to clean the page at the old EOF856856+ * when extending the file. Extending the file can expose changes the857857+ * underlying page mapping (e.g. from beyond EOF to a hole or858858+ * unwritten), and so on the next attempt to write to that page we need859859+ * to remap it for write. i.e. we need .page_mkwrite() to be called.860860+ * Hence we need to clean the page to clean the pte and so a new write861861+ * fault will be triggered appropriately.862862+ *863863+ * If we do it before we change the inode size, then we can race with a864864+ * page fault that maps the page with exactly the same problem. If we do865865+ * it after we change the file size, then a new page fault can come in866866+ * and allocate space before we've run the rest of the truncate867867+ * transaction. That's kinda grotesque, but it's better than have data868868+ * over a hole, and so that's the lesser evil that has been chosen here.869869+ *870870+ * The real solution, however, is to have some mechanism for locking out871871+ * page faults while a truncate is in progress.872872+ */873873+ if (newsize > oldsize && mapping_mapped(VFS_I(ip)->i_mapping)) {874874+ error = filemap_write_and_wait_range(875875+ VFS_I(ip)->i_mapping,876876+ round_down(oldsize, PAGE_CACHE_SIZE),877877+ round_up(oldsize, PAGE_CACHE_SIZE) - 1);878878+ if (error)879879+ return error;880880+ }881881+852882 tp = xfs_trans_alloc(mp, XFS_TRANS_SETATTR_SIZE);853883 error = xfs_trans_reserve(tp, &M_RES(mp)->tr_itruncate, 0, 0);854884 if (error)
+38-9
fs/xfs/xfs_log_cil.c
···463463 spin_unlock(&cil->xc_push_lock);464464 goto out_skip;465465 }466466- spin_unlock(&cil->xc_push_lock);467466468467469468 /* check for a previously pushed seqeunce */470470- if (push_seq < cil->xc_ctx->sequence)469469+ if (push_seq < cil->xc_ctx->sequence) {470470+ spin_unlock(&cil->xc_push_lock);471471 goto out_skip;472472+ }473473+474474+ /*475475+ * We are now going to push this context, so add it to the committing476476+ * list before we do anything else. This ensures that anyone waiting on477477+ * this push can easily detect the difference between a "push in478478+ * progress" and "CIL is empty, nothing to do".479479+ *480480+ * IOWs, a wait loop can now check for:481481+ * the current sequence not being found on the committing list;482482+ * an empty CIL; and483483+ * an unchanged sequence number484484+ * to detect a push that had nothing to do and therefore does not need485485+ * waiting on. If the CIL is not empty, we get put on the committing486486+ * list before emptying the CIL and bumping the sequence number. Hence487487+ * an empty CIL and an unchanged sequence number means we jumped out488488+ * above after doing nothing.489489+ *490490+ * Hence the waiter will either find the commit sequence on the491491+ * committing list or the sequence number will be unchanged and the CIL492492+ * still dirty. In that latter case, the push has not yet started, and493493+ * so the waiter will have to continue trying to check the CIL494494+ * committing list until it is found. In extreme cases of delay, the495495+ * sequence may fully commit between the attempts the wait makes to wait496496+ * on the commit sequence.497497+ */498498+ list_add(&ctx->committing, &cil->xc_committing);499499+ spin_unlock(&cil->xc_push_lock);472500473501 /*474502 * pull all the log vectors off the items in the CIL, and···560532 */561533 spin_lock(&cil->xc_push_lock);562534 cil->xc_current_sequence = new_ctx->sequence;563563- list_add(&ctx->committing, &cil->xc_committing);564535 spin_unlock(&cil->xc_push_lock);565536 up_write(&cil->xc_ctx_lock);566537···882855 * Hence by the time we have got here it our sequence may not have been883856 * pushed yet. This is true if the current sequence still matches the884857 * push sequence after the above wait loop and the CIL still contains885885- * dirty objects.858858+ * dirty objects. This is guaranteed by the push code first adding the859859+ * context to the committing list before emptying the CIL.886860 *887887- * When the push occurs, it will empty the CIL and atomically increment888888- * the currect sequence past the push sequence and move it into the889889- * committing list. Of course, if the CIL is clean at the time of the890890- * push, it won't have pushed the CIL at all, so in that case we should891891- * try the push for this sequence again from the start just in case.861861+ * Hence if we don't find the context in the committing list and the862862+ * current sequence number is unchanged then the CIL contents are863863+ * significant. If the CIL is empty, if means there was nothing to push864864+ * and that means there is nothing to wait for. If the CIL is not empty,865865+ * it means we haven't yet started the push, because if it had started866866+ * we would have found the context on the committing list.892867 */893868 if (sequence == cil->xc_current_sequence &&894869 !list_empty(&cil->xc_cil)) {
+1-1
fs/xfs/xfs_rtalloc.c
···4646 * Keeps track of a current summary block, so we don't keep reading4747 * it from the buffer cache.4848 */4949-int4949+static int5050xfs_rtget_summary(5151 xfs_mount_t *mp, /* file system mount structure */5252 xfs_trans_t *tp, /* transaction pointer */