Date: Mon, 6 Feb 95 10:37:26 MST From: terry@cs.weber.edu (Terry Lambert) To: jmb@kryten.atinc.com (Jonathan M. Bresler) Cc: hackers@FreeBSD.org Subject: Re: MIT SHM X11 extensions? (fwd) Message-ID: <9502061737.AA05786@cs.weber.edu> In-Reply-To: <Pine.3.89.9502061021.F3332-0100000@kryten.atinc.com> from "Jonathan M. Bresler" at Feb 6, 95 10:59:11 am
next in thread | previous in thread | raw e-mail | index | archive | help
> i need a person better versed in the kernel than myself to look > at this explaination of why you dont want to 'cp' a running kernel. > > Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. > | 2341 Jeff Davis Hwy > play go. | Arlington, VA 22202 > ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 > > ---------- Forwarded message ---------- > Date: Sun, 5 Feb 1995 15:26:20 -0500 (EST) > From: Jonathan M. Bresler <jmb@kryten.atinc.com> > To: David O'Byrne <dave@odyssey.ucc.ie> > Subject: Re: MIT SHM X11 extensions? > > On Sun, 5 Feb 1995, David O'Byrne wrote: > > > > > > mv /386bsd /386bsd.alt <--- DO NOT USE 'cp' > > > > Hi Jonathan, sorry to pick you up an a small point on your recent post > > to the list. But why is it important to use mv ? What goes wrong of I > > use cp to back up the old kernel ? > > mv breaks the connection between the pathname "/386bsd" and the > kernel process in memory. cp does not. most of the time this doesnt > matter. but if the kernel (virtual memory system) decides to get kernel > pages from disk or swap, after you put the new kernel into "/" and before > the reboot (of course ;), then the memory image gets hammered. best you > can hope for is a panic. worst, it just starts doing gawd-knows what > with your system. > > think of it as arbitrary opcodes inserted into the kernel (unless > you have the good forturn that the pages in both kernels are identical) > > dont ask where in the kernel/vm system this takes place. i have > not dug into it. but that's what i understand to be the problem. This *should* be a bogus claim. I let it slide when it was implied by the warning in the previous message because I believe in voodoo, like typing sync three times, etc. I have seen kernels that do a buffer flush on consecutive syncs, so I do them, assuming the worst: the first sync will schedule the buffers for write and the subsequent sync will cause the buffers scheduled for write to be written. Larry McVoy recently added something similar to Linux to flush pages, although he added two system calls rathe than overloading sync. The third sync is because of "I tell you three times", which might be traceable to the John Brunner novel "Stand on Zanzibar" for those into computer trivia. === In reality, I don't believe the kernel itself is paging at all (not that it wouldn't be nice if it could). This particular voodoo of moving a file instead of copying it, then copying on top of the former image comes from an old VM design problem that (in Xenix) resulted in the message "text file busy". If the kernel is not being used as a swap store, this does not apply to the kernel, period. === The expected problem is that the image is being used as a swap store, and that the initial MACH VM system Jolitz started with didn't disallow writes to an active image. Since the kernel doesn't use its file as swap store, this should be purely voodoo and nothing else. The current VM system returns ETXTBUSY and disallows the operation, which kinda-sorta-partially hides the problem most of the time. In point of fact, returning ETXTBUSY is bogus in any case, since it is possible to force the entire image to swap when a write reference occurs and let the image be written to the writers hearts content. This would probably be the best fix, since then ETXTBUSY becomes a kernel internal error that a user never has to deal with. It does mean you could get ENOMEM if memory + swap were exhausted and you tried to overwrite a running image. In point of fact, this should be forced as a precondition of images loaded over NFS and other "remote" file systems via a flag on the file system type. The reason for this is that the vnode is flagged with a flag VEXEC when it is being used as a swap store, but NFS can not propagate this flag to the server because the protocol is stateless and there's nowhere to hang the flag. There is also no distinction between "open" and "open for exec" needed to make the distinction, even if you did have some place to hang the flag. That means that if system B is running an image via NFS from system A's disk, and using the image as swap store, someone on system A can rewrite the image and crash the program on system B. Action at a distance! This is totally bogus. Copying the image to local swap is also more efficient, since (1) it is faster, (2) it reduces network traffic, and (3) it is faster to read a page from a swap area than it is to follow a vnode reference down to get the page from a file system. But this is not what BSDI, NetBSD, and FreeBSD do. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9502061737.AA05786>