Re: How stable is -current?
At 10:34 AM 5/6/99 -0700, Matthew Dillon wrote: >:I'll gladly test them. I'm in the process of upgrading the lab I run to 3.1 >:and it depends heavily on NFS. Since the lab is closed during finals I won't >:be losing massive amounts of data if they go wrong. Send 'em on. :) NFS is a >:big deal to a lot of us, and we'd like to see the changes MFC'd to -stable if >:possible. > >The only major bugfixes that have not been backported from -current to >-stable in regards to NFS are the NFS/TCP fix, which is being backported >now, and a number of fixes to the VM system when dealing with mmap(), >which cannot be backported until we backport the entire -current VM system. >Also, NFS-stable will break if directories are VMIO'd due to breakage >in the reconstitution of the valid range ( but directories are not VMIO'd >in either -stable or -current yet so this will not effect us yet ). > >The mmap() breakage is unavoidable in -stable but hopefully will not cause >serious problems for people. The breakage is related to garbarge showing >up in the mmap()'d pages *after* the logical file EOF. That is, if you >have a 500 byte file and mmap() it into a 4K page, data occuring after >offset 500 may or may not be 0. This sounds like the page is not being zeroed before being reassigned for other uses. Does this present a possible security problem? Might I get a page from a terminated process that wasn't zeroed? Say perhaps a page from a vipw process or something similar? If so, this really should be addressed at least in so far as to prevent any possible exploitation (ie putting out software with bugs is one thing, but putting out software with security holes is just bad, not that we are doing this, that's what I am asking) Christopher R. Bowman c...@chrisbowman.com http://www.ChrisBowman.com/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How stable is -current?
: Ok, that's good news. I'd like to stick with -stable if I can. No :pressure, but do you have an ETA on the VM backport? I'm assuming that :something like that is "down the road," probably after 3.2? There's no ETA at the moment. I'm hoping that modifications to -current's VM system will settle down in the next couple of months and then we'll see. : Hrrrmm... ok. So what could happen due to this bug, and how would I :spot it? Meanwhile I'll keep an eye on the commits for that NFS :backport. Thanks muchly for the update. :) : :Doug Programs which expect the space in the mmap after the logical file EOF to be filled with zero will break. Very few programs make this assumption, because space in an mmap after the logical EOF is supposed to generate a segfault if accessed ( but, obviously, cannot for space past the EOF in the 'last page' that contains the last fragment of file data ). It is more a security issue then anything else. For example, if you are mapping a file fragment you may wind up being able to access (read only) fragmentary data from other files that you would normally not have access to. -Matt Matthew Dillon :-- :*** Chief Operations Officer, DALnet IRC network *** : :Nominated for quote of the year is the statement made by Representative :Dick Armey (Texas), who when asked if he were in the President's place, :would he resign, responded: : :"If I were in the President's place I would not get a chance to resign. :I would be lying in a pool of my own blood hearing Mrs. Armey standing :over me saying, 'How do I reload this damn thing?'" : To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How stable is -current?
Matthew Dillon wrote: > The only major bugfixes that have not been backported from -current to > -stable in regards to NFS are the NFS/TCP fix, which is being backported > now, and a number of fixes to the VM system when dealing with mmap(), > which cannot be backported until we backport the entire -current VM > system. Ok, that's good news. I'd like to stick with -stable if I can. No pressure, but do you have an ETA on the VM backport? I'm assuming that something like that is "down the road," probably after 3.2? > The mmap() breakage is unavoidable in -stable but hopefully will not cause > serious problems for people. The breakage is related to garbarge showing > up in the mmap()'d pages *after* the logical file EOF. That is, if you > have a 500 byte file and mmap() it into a 4K page, data occuring after > offset 500 may or may not be 0. Hrrrmm... ok. So what could happen due to this bug, and how would I spot it? Meanwhile I'll keep an eye on the commits for that NFS backport. Thanks muchly for the update. :) Doug -- *** Chief Operations Officer, DALnet IRC network *** Nominated for quote of the year is the statement made by Representative Dick Armey (Texas), who when asked if he were in the President's place, would he resign, responded: "If I were in the President's place I would not get a chance to resign. I would be lying in a pool of my own blood hearing Mrs. Armey standing over me saying, 'How do I reload this damn thing?'" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How stable is -current?
:I'll gladly test them. I'm in the process of upgrading the lab I run to 3.1 :and it depends heavily on NFS. Since the lab is closed during finals I won't :be losing massive amounts of data if they go wrong. Send 'em on. :) NFS is a :big deal to a lot of us, and we'd like to see the changes MFC'd to -stable if :possible. The only major bugfixes that have not been backported from -current to -stable in regards to NFS are the NFS/TCP fix, which is being backported now, and a number of fixes to the VM system when dealing with mmap(), which cannot be backported until we backport the entire -current VM system. Also, NFS-stable will break if directories are VMIO'd due to breakage in the reconstitution of the valid range ( but directories are not VMIO'd in either -stable or -current yet so this will not effect us yet ). The mmap() breakage is unavoidable in -stable but hopefully will not cause serious problems for people. The breakage is related to garbarge showing up in the mmap()'d pages *after* the logical file EOF. That is, if you have a 500 byte file and mmap() it into a 4K page, data occuring after offset 500 may or may not be 0. There are still various other bugs relating to deadlock situations that haven't been fixed in either release that are still being tracked down. Fewer then in prior releases, but still present. :Do you know if they have test patches for -stable as well? Thanks. I would wait until we get the NFS/TCP fix committed to -stable. It should be committed very soon now. :John Baldwin -- http://members.freedomnet.com/~jbaldwin/ -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How stable is -current?
Greg Lehey wrote: > > I know it goes through periods of instability, but assuming that I'm > > following the lists and know when not to build, could I put a 4.x > > box up and not be embarrassed? > > Yes, but that's a big assumption: "assuming everything went OK". How > do you known in advance whether you're not going to find a bug which > eats its way, termitelike, through your file systems, and one day you > look at the machine and it just falls into a heap of dust on the > floor. *Chuckle* Great visual. Of course, "odd" surprises are not completely unexpected in any freebsd branch, and of course I do plan to take appropriate measures to protect our customer's stuff. The system I'm planning to design will require read-only access from the CGI box to the rest of the world, and almost everything on the box itself will be redundant data anyway. This will be true regardless of what platform we use, so I think this is a unique opportunity to test -current in a relatively pain-free, high load environment. At the same time, I would prefer that it's not crashing regularly because it's my potatoes in the sling, so to speak if I convince them to use freebsd. > > 4. How about other "new" features, like soft updates and vinum? > > Vinum is available in -STABLE as well. It's the same code. I thought > that soft updates were also pretty stable. Ok, thanks for the info on vinum. If I'm going to make this work I need to show disk access as good or better than linux, so I'm looking for every edge. > What I'm hearing here is that you want to go to -CURRENT because of > NFS. Yes, exactly. The other factors you mentioned aren't significant to me, I'm quite familiar with traditional freebsd development cycle instability. :) INRE Jordan's comments about moving the -current NFS improvements to -stable, obviously I'd rather run -stable in a production environment, so assuming we can get a patchset together I could do some testing of that at home since I have two boxes now. My understanding from what I've read was that the changes depended on some architectural improvements in -current that couldn't (easily) be ported back, but I'm still way behind on mail, so I am probably not all up to date on that. However I can't emphasize strongly enough how much our system depends on NFS. Whether that's a good thing or not isn't for me to decide, I just work there. :) I must say though, working in an all-Sun environment it's easy to get used to how easy NFS makes things. I'm starting to feel the same way about samba since I set it up on my home network. Thanks very much to everyone for the responses, they were very helpful. If anyone else has comments or suggestions I welcome them of course. Doug -- *** Chief Operations Officer, DALnet IRC network *** Nominated for quote of the year is the statement made by Representative Dick Armey (Texas), who when asked if he were in the President's place, would he resign, responded: "If I were in the President's place I would not get a chance to resign. I would be lying in a pool of my own blood hearing Mrs. Armey standing over me saying, 'How do I reload this damn thing?'" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How stable is -current?
On 06-May-99 Jordan K. Hubbard wrote: >> 2. Our architecture is *highly* dependent on NFS. I know that the good >> work on NFS is happening in -current, which is why I'm considering it. >> How well does -current NFS mix with an almost all-Sun network? Any >> plans on MFC'ing the NFS fixes to -stable? > > Matt's submitted some patches for this which I've asked the core team > to review. Anyone else looking for -stable relative NFS patches to > test should send Matt Dillon or I some email and we'll provide you with > the diffs if you'll provide us with the testing. :) I'll gladly test them. I'm in the process of upgrading the lab I run to 3.1 and it depends heavily on NFS. Since the lab is closed during finals I won't be losing massive amounts of data if they go wrong. Send 'em on. :) NFS is a big deal to a lot of us, and we'd like to see the changes MFC'd to -stable if possible. >> 3. How good and how stable is SMP currently, and does -current offer any >> big advantages over -stable in SMP? > > I think SMP is pretty good in either branch, though Luoqi and Alan > have been working to improve it in -current lately. Do you know if they have test patches for -stable as well? Thanks. > - Jordan --- John Baldwin -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How stable is -current?
"Jordan K. Hubbard" wrote: > > > 3. How good and how stable is SMP currently, and does -current offer any > > big advantages over -stable in SMP? > > I think SMP is pretty good in either branch, though Luoqi and Alan > have been working to improve it in -current lately. 5% gain on worldstone for a recent commit. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "Proof of Trotsky's farsightedness if that _none_ of his predictions have come true yet." To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How stable is -current?
> 1. In general how stable is -current? I know it goes through periods of > instability, but assuming that I'm following the lists and know when not > to build, could I put a 4.x box up and not be embarrassed? I run my own machine off -current, have been doing so for months now, and it's hardly an idle machine given the number of release builds and other crap I run on it. It's been a less painful -current than many a -current I could think of in the past, that's for sure. :) > 2. Our architecture is *highly* dependent on NFS. I know that the good > work on NFS is happening in -current, which is why I'm considering it. > How well does -current NFS mix with an almost all-Sun network? Any > plans on MFC'ing the NFS fixes to -stable? Matt's submitted some patches for this which I've asked the core team to review. Anyone else looking for -stable relative NFS patches to test should send Matt Dillon or I some email and we'll provide you with the diffs if you'll provide us with the testing. :) > 3. How good and how stable is SMP currently, and does -current offer any > big advantages over -stable in SMP? I think SMP is pretty good in either branch, though Luoqi and Alan have been working to improve it in -current lately. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How stable is -current?
On Wednesday, 5 May 1999 at 23:59:21 -0700, Doug Barton wrote: > First off, let's assume that I'm aware of all the traditional caveats > re -current being bleeding edge, read the lists, etc. and am willing to > deal with that. Now let's assume that I am trying to convince the powers > that be at work to use freebsd for an upcoming CGI server project. Here > is a relatively precise quote from the boss, "I think what we're going > to do is set up a box with dual 500's and put linux on it because > says that their stuff > runs best on linux, I think because of the disk access or something like > that." > > So the most important things I need to know (in no particular order): > > 1. In general how stable is -current? Parts of it are excellent. > I know it goes through periods of instability, but assuming that I'm > following the lists and know when not to build, could I put a 4.x > box up and not be embarrassed? Yes, but that's a big assumption: "assuming everything went OK". How do you known in advance whether you're not going to find a bug which eats its way, termitelike, through your file systems, and one day you look at the machine and it just falls into a heap of dust on the floor. > 4. How about other "new" features, like soft updates and vinum? Vinum is available in -STABLE as well. It's the same code. I thought that soft updates were also pretty stable. > Any other words of advice would be greatly appreciated. My > experience says that a linux box won't handle the load that we're > going to put on it, so if I can come up with something that works > and outshines linux I earn points for me, and the project at the > same time. If on the other hand, it chokes, errr... that'd be > bad. :) I have a scratch box at home that is completely > blow-up-able, so putting in the time to make it work is not a > problem, I just need to know where to start. What I'm hearing here is that you want to go to -CURRENT because of NFS. That's almost a valid reason, but I'll let other ones fight it out. Or you've been scared off by Doug White badmouthing 3.1. Note that just about everything he mentioned relates to upgrading, not to the stability of the system itself. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
