Date: Tue, 21 Mar 2017 02:40:46 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Gergely Czuczy <gergely.czuczy@harmless.hu>, Konstantin Belousov <kostikbel@gmail.com> Cc: Dimitry Andric <dim@FreeBSD.org>, Ian Lepore <ian@FreeBSD.org>, "FreeBSD Current" <freebsd-current@freebsd.org> Subject: Re: process killed: text file modification Message-ID: <YTXPR01MB01891633D0486547C3E748E3DD3D0@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <4642046a-08e6-35af-c76e-c5e306f01e62@harmless.hu> References: <5ac94b9a-7ced-9eff-d746-7dddaaeca516@harmless.hu> <1489340839.40576.82.camel@freebsd.org> <FF55DB37-4A6B-4D88-B201-B3BCA1A11E87@FreeBSD.org> <YTXPR01MB01898D49933A82170FCAB7A0DD390@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> <YTXPR01MB018944EF4248402AD421D825DD390@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> <20170317083605.GQ16105@kib.kiev.ua> <YTXPR01MB0189F7147A7C5C5F8C56B2F1DD390@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> <20170317141917.GS16105@kib.kiev.ua> <D0770019-3EEA-45D2-A751-18DF1B274F90@FreeBSD.org> <YTXPR01MB0189FBB6CF664653C1162936DD390@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> <20170318032150.GW16105@kib.kiev.ua> <YTXPR01MB0189F47B6A23C10BFE8A85E6DD3B0@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>, <4642046a-08e6-35af-c76e-c5e306f01e62@harmless.hu>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
Gergely Czuczy wrote:
[stuff snipped]
> Actually I want to test it, but you guys are so vehemently discussing
> it, I thought it would be better to do so, once you guys settled your
> analysis on the code. Also, me not having the problem occurring, I don't
> think would mean it's solved, since that would only mean, the codepath
> for my specific usecase works. There might be other things there as
> well, what I don't hit.
I hope by vehemently, you didn't find my comments as nasty. If they did
come out that way, it was not what I intended and I apologize.
> Let me know which patch should I test, and I will see to it in the next
> couple of days, when I get the time to do it.
I've attached it here again and, yes, I would agree that the results you get
from testing are just another data point and not definitive.
(I'd say this statement is true of all testing of nontrivial code.)
Thanks in advance for any testing you can do, rick
[-- Attachment #2 --]
--- fs/nfsclient/nfs_clvnops.c.text 2017-03-16 21:55:16.263393000 -0400
+++ fs/nfsclient/nfs_clvnops.c 2017-03-17 09:31:23.632814000 -0400
@@ -140,6 +140,7 @@ static vop_advlock_t nfs_advlock;
static vop_advlockasync_t nfs_advlockasync;
static vop_getacl_t nfs_getacl;
static vop_setacl_t nfs_setacl;
+static vop_set_text_t nfs_set_text;
/*
* Global vfs data structures for nfs
@@ -176,6 +177,7 @@ struct vop_vector newnfs_vnodeops = {
.vop_write = ncl_write,
.vop_getacl = nfs_getacl,
.vop_setacl = nfs_setacl,
+ .vop_set_text = nfs_set_text,
};
struct vop_vector newnfs_fifoops = {
@@ -3373,6 +3375,29 @@ nfs_setacl(struct vop_setacl_args *ap)
return (error);
}
+static int
+nfs_set_text(struct vop_set_text_args *ap)
+{
+ struct vnode *vp = ap->a_vp;
+ struct nfsnode *np;
+
+ /*
+ * If the text file has been mmap'd, the dirty pages must be flushed
+ * so that the modify time of the file will be up to date.
+ */
+ if (vp->v_object != NULL) {
+ np = VTONFS(vp);
+ VM_OBJECT_WLOCK(vp->v_object);
+ vm_object_page_clean(vp->v_object, 0, 0, OBJPC_SYNC);
+ VM_OBJECT_WUNLOCK(vp->v_object);
+ mtx_lock(&np->n_mtx);
+ np->n_mtime = np->n_vattr.na_mtime;
+ mtx_unlock(&np->n_mtx);
+ }
+ vp->v_vflag |= VV_TEXT;
+ return (0);
+}
+
/*
* Return POSIX pathconf information applicable to nfs filesystems.
*/
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTXPR01MB01891633D0486547C3E748E3DD3D0>