Date: Sat, 18 Mar 2017 05:21:50 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: Dimitry Andric <dim@FreeBSD.org>, Ian Lepore <ian@FreeBSD.org>, Gergely Czuczy <gergely.czuczy@harmless.hu>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: process killed: text file modification Message-ID: <20170318032150.GW16105@kib.kiev.ua> In-Reply-To: <YTXPR01MB0189FBB6CF664653C1162936DD390@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 17, 2017 at 09:23:00PM +0000, Rick Macklem wrote: > Dimitry Andric wrote: > >On 17 Mar 2017, at 15:19, Konstantin Belousov <kostikbel@gmail.com> wrote: > >> > >> On Fri, Mar 17, 2017 at 01:53:46PM +0000, Rick Macklem wrote: > >>> Well, I don't mind adding ncl_flush(), but it shouldn't be > >>> necessary. I actually had it in the first > >>> rendition of the patch, but took it out because it should happen > >>> on the VOP_CLOSE() if any writing to the buffer cache happened > >>> and that code hasn't changed in many years. > >> Dirty pages are flushed by writes, so if we have a set of dirty pages and > >> async vm_object_page_clean() is called on the vnode' vm_object, we get > >> a bunch of delayed-write AKA dirty buffers. This is possible even after > >> VOP_CLOSE() was done, e.g. by syncer performing regular run involving > >> vfs_msync(). > When I was talking about ncl_flush() above, I was referring to buffer cache > buffers written by a write(2) syscall, not the case of mmap'd pages. But dirty buffers can appear on the vnode queue due to dirty pages msyncing by syncer, for instance. > > >> > >> I agree that the patch would not create new dirty buffers, but it is possible > >> to get them by other means. > To write to a buffer cache block, the file would be opened by another > thread and that is what this sanity check was meant to catch. As > for dirtying pages that are mmap'd, as far as I understand it, the > NFS client has no way of knowing if this will happen more until > VOP_INACTIVE() is called on the vnode. > Syncer does not open the vnode inside the vfs_msync() operations. > To be honest, this check could easily be deleted. After all, NFS could care less if a file > is being executed (all it sees are reads and writes). Without the check, the executable > might do "interesting" things;-) > [stuff snipped] > > FWIW, Rick's patch seems to do the trick, both for my test case and lld > > itself. And even with vfs.timestamp_precision=3 on both server and > > client. > Hopefully the original reporter of the problem (Gergely ??) can test the patch as well. > I think the patch is pretty harmless, although it could be argued that setting > np->m_mtime = np->n_nattr.na_mtime (or close to that) > shouldn't happen for the case where there isn't any dirty pages found to flush. > However, once a file mmap'd we don't know when it does get modified anyhow > (as discussed above), so setting it here doesn't seem harmful to me. We do track writeability to the file, and do not allow execution if there is an active writer, be it a file descriptor opened for write, or a writeable mapping. And in reverse, if the file is executed (VV_TEXT is set), then we disallow opening the file for write. Of course, this cannot work when we execute file on one NFS client, and another client modifies the file, but then exactly this check and kill should provide some sanity. > > Thanks for testing the patch. Now, if others can test it...rick >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170318032150.GW16105>