Re: Mystery panic, FreeBSD 7.2-PRE
On Thu, Dec 22, 2011 at 04:04:48PM -0700, Charlie Martin wrote: We've got another mystery panic in 7.2-PRE. Upgrading is not an option; however, if this is familiar to anyone, backporting a patch would be. The stack trace is: db_trace_self_wrapper() at 0x8019120a = db_trace_self_wrapper+0x2a^M panic() at 0x80308797 = panic+0x187^M devfs_populate_loop() at 0x802a45c8 = devfs_populate_loop+0x548^M devfs_populate() at 0x802a46ab = devfs_populate+0x3b^M devfs_lookup() at 0x802a7824 = devfs_lookup+0x264^M VOP_LOO[24165][irq261: plx0] DEBUG (hasc_sv_rcv_cb): rcvd hrtbt ts 24051, 7/9, rc 0^M KUP_APV() at 0x804d5995 = VOP_LOOKUP_APV+0x95^M lookup() at 0x80384a3e = lookup+0x4ce^M namei() at 0x80385768 = namei+0x2c8^M vn_open_cred() at 0x8039b283 = vn_open_cred+0x1b3^M kern_open() at 0x8039a4a0 = kern_open+0x110^M syscall() at 0x804b0e3c = syscall+0x1ec^M Xfast_syscall() at 0x80494ecb = Xfast_syscall+0xab^M --- syscall (5, FreeBSD ELF64, open), rip = 0x800e022fc, rsp = 0x7fbfa128, rbp = 0x801002240 ---^M KDB: enter: panic^M It is impossible to diagnose the real cause of the panic from the backtrace above. 99.99% of the issues causing that backtrace are problems in the specific drivers, which failed to dev_ref() the newly created cdev, e.g. in the clone handler. My interest in the issue is limited to the slightest possibility that the bug is not yet fixed in HEAD or 9/8. Usual suspects are tty, which were completely rototiled in 8. pgpGbzHKAjHSb.pgp Description: PGP signature
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 23/12/2011 02:56, Garrett Cooper wrote: On Dec 22, 2011, at 3:58 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: On Fri, Dec 23, 2011 at 12:44:14AM +0100, O. Hartmann wrote: On 12/21/11 19:41, Alexander Leidinger wrote: Hi, while the discussion continued here, some work started at some other place. Now... in case someone here is willing to help instead of talking, feel free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what can be improved. The page is far from perfect and needs some additional people which are willing to improve it. This is only part of the problem. A tuning page in the wiki - which could be referenced from the benchmark page - would be great too. Any volunteers? A first step would be to take he tuning-man-page and wikify it. Other tuning sources are welcome too. Every FreeBSD dev with a wiki account can hand out write access to the wiki. The benchmark page gives contributor-access. If someone wants write access create a FirstnameLastname account and ask here for contributor-access. Don't worry if you think your english is not good enough, even some one-word notes can help (and _my_ english got already corrected by other people on the benchmark page). Bye, Alexander. Nice to see movement ;-) But there seems something unclear: man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in /etc/make.conf. The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf. What's right and what's wrong now? I can say with certainty that this value belongs in /etc/make.conf (on RELENG_8 and earlier at least). src/share/mk/bsd.own.mk has no framework for MK_MALLOC_PRODUCTION, so, this is definitely a make.conf variable. Take the advice in tuning(7) with a grain of salt because a number of suggestions are really outdated. I know because I filed a PR last night after I saw how out of synch some of the defaults it claimed were with reality on 9.x+. And I know other suggestions in the manpage are dated as well ;/. There is a wiki page http://wiki.freebsd.org/SystemTuning which is currently more or less tuning(7) with some annotations, the idea being to sort out whats outdated/invalid with an aim of rewriting tuning(7) to be more accurate and useful. I'll grab any info in your pr thats not up there already to keep it updated if thats ok. Vince Thanks, -Garrett___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Thursday, December 22, 2011 6:58:46 pm Jeremy Chadwick wrote: On Fri, Dec 23, 2011 at 12:44:14AM +0100, O. Hartmann wrote: On 12/21/11 19:41, Alexander Leidinger wrote: Hi, while the discussion continued here, some work started at some other place. Now... in case someone here is willing to help instead of talking, feel free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what can be improved. The page is far from perfect and needs some additional people which are willing to improve it. This is only part of the problem. A tuning page in the wiki - which could be referenced from the benchmark page - would be great too. Any volunteers? A first step would be to take he tuning-man-page and wikify it. Other tuning sources are welcome too. Every FreeBSD dev with a wiki account can hand out write access to the wiki. The benchmark page gives contributor-access. If someone wants write access create a FirstnameLastname account and ask here for contributor-access. Don't worry if you think your english is not good enough, even some one- word notes can help (and _my_ english got already corrected by other people on the benchmark page). Bye, Alexander. Nice to see movement ;-) But there seems something unclear: man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in /etc/make.conf. The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf. What's right and what's wrong now? I can say with certainty that this value belongs in /etc/make.conf (on RELENG_8 and earlier at least). src/share/mk/bsd.own.mk has no framework for MK_MALLOC_PRODUCTION, so, this is definitely a make.conf variable. Eh, normal make variables can go in src.conf as well. They do not have to be listed in bsd.own.mk. World builds include /etc/src.conf whereas every make invocation includes /etc/make.conf via sys.mk. The only reason to use /etc/src.conf is to have a place to put variables only affect make buildworld / buildkernel but do not affect other make invocations. Also, MALLOC_PRODUCTION is generally enabled in a stable branch as part of making the stable branch, there should be no need to set it manually in a stable branch. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Fri, Dec 23, 2011 at 10:00:05AM -0500, John Baldwin wrote:
On Thursday, December 22, 2011 6:58:46 pm Jeremy Chadwick wrote:
On Fri, Dec 23, 2011 at 12:44:14AM +0100, O. Hartmann wrote:
On 12/21/11 19:41, Alexander Leidinger wrote:
Hi,
while the discussion continued here, some work started at some other
place. Now... in case someone here is willing to help instead of talking,
feel
free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what
can
be improved. The page is far from perfect and needs some additional people
which are willing to improve it.
This is only part of the problem. A tuning page in the wiki - which
could be referenced from the benchmark page - would be great too. Any
volunteers? A first step would be to take he tuning-man-page and wikify it.
Other tuning sources are welcome too.
Every FreeBSD dev with a wiki account can hand out write access to the
wiki. The benchmark page gives contributor-access. If someone wants write
access create a FirstnameLastname account and ask here for contributor-access.
Don't worry if you think your english is not good enough, even some one-
word notes can help (and _my_ english got already corrected by other people
on
the benchmark page).
Bye,
Alexander.
Nice to see movement ;-)
But there seems something unclear:
man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in
/etc/make.conf.
The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf.
What's right and what's wrong now?
I can say with certainty that this value belongs in /etc/make.conf
(on RELENG_8 and earlier at least).
src/share/mk/bsd.own.mk has no framework for MK_MALLOC_PRODUCTION,
so, this is definitely a make.conf variable.
Eh, normal make variables can go in src.conf as well. They do not have
to be listed in bsd.own.mk. World builds include /etc/src.conf whereas
every make invocation includes /etc/make.conf via sys.mk. The only reason
to use /etc/src.conf is to have a place to put variables only affect
make buildworld / buildkernel but do not affect other make invocations.
I was always under the impression src.conf(5) variables had to be
manually added to bsd.own.mk and similar bits (e.g.
src/tools/build/options/WITH_xxx which is what's used to create the
src.conf(5) man page), but upon your comment and manual investigation on
my part, I found you're indeed right. Taken from bsd.own.mk:
107 .if !defined(_WITHOUT_SRCCONF)
108 SRCCONF?= /etc/src.conf
109 .if exists(${SRCCONF})
110 .include ${SRCCONF}
111 .endif
112 .endif
As long as third-party software doesn't depend on MALLOC_PRODUCTION for
something (I don't know why something would, but who knows; maybe
there's a third-party malloc implementation which might?), then putting
it in src.conf would be fine (src/lib/libc/stdlib files reference it).
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FLAME - security advisories on the 23rd ? uncool idea is uncool
Hey up list, Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? I mean, couldn't this have waited and remained undisclosed until monday ? I for one do *NOT* relish the idea of updating 50+ boxes this evening and tomorrow ! Not to mention a whole lot of merchants and banks have toggled IT Freeze a few weeks ago, to ensure xmas shopping doesn't get disturbed by production changes. Seriously, this is just irritating. /flame ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On Friday, December 23, 2011 11:07:56 am Damien Fleuriot wrote: Hey up list, Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? I mean, couldn't this have waited and remained undisclosed until monday ? I for one do *NOT* relish the idea of updating 50+ boxes this evening and tomorrow ! Not to mention a whole lot of merchants and banks have toggled IT Freeze a few weeks ago, to ensure xmas shopping doesn't get disturbed by production changes. Seriously, this is just irritating. From an e-mail sent to security@ from the security officer: quote Hi all, No, the Grinch didn't steal the FreeBSD security officer GPG key, and your eyes aren't deceiving you: We really did just send out 5 security advisories. The timing, to put it bluntly, sucks. We normally aim to release advisories on Wednesdays in order to maximize the number of system administrators who will be at work already; and we try very hard to avoid issuing advisories any time close to holidays for the same reason. The start of the Christmas weekend -- in some parts of the world it's already Saturday -- is absolutely not when we want to be releasing security advisories. Unfortunately my hand was forced: One of the issues (FreeBSD-SA-11:08.telnetd) is a remote root vulnerability which is being actively exploited in the wild; bugs really don't come any worse than this. On the positive side, most people have moved past telnet and on to SSH by now; but this is still not an issue we could postpone until a more convenient time. While I'm writing, a note to freebsd-update users: FreeBSD-SA-11:07.chroot has a rather messy fix involving adding a new interface to libc; this has the awkward side effect of causing the sizes of some symbols (aka. functions) in libc to change, resulting in cascading changes into many binaries. The long list of updated files is irritating, but isn't a sign that anything in freebsd-update went wrong. /quote -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On 12/23/11 5:39 PM, John Baldwin wrote: On Friday, December 23, 2011 11:07:56 am Damien Fleuriot wrote: Hey up list, Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? I mean, couldn't this have waited and remained undisclosed until monday ? I for one do *NOT* relish the idea of updating 50+ boxes this evening and tomorrow ! Not to mention a whole lot of merchants and banks have toggled IT Freeze a few weeks ago, to ensure xmas shopping doesn't get disturbed by production changes. Seriously, this is just irritating. From an e-mail sent to security@ from the security officer: quote Hi all, No, the Grinch didn't steal the FreeBSD security officer GPG key, and your eyes aren't deceiving you: We really did just send out 5 security advisories. The timing, to put it bluntly, sucks. We normally aim to release advisories on Wednesdays in order to maximize the number of system administrators who will be at work already; and we try very hard to avoid issuing advisories any time close to holidays for the same reason. The start of the Christmas weekend -- in some parts of the world it's already Saturday -- is absolutely not when we want to be releasing security advisories. Unfortunately my hand was forced: One of the issues (FreeBSD-SA-11:08.telnetd) is a remote root vulnerability which is being actively exploited in the wild; bugs really don't come any worse than this. On the positive side, most people have moved past telnet and on to SSH by now; but this is still not an issue we could postpone until a more convenient time. While I'm writing, a note to freebsd-update users: FreeBSD-SA-11:07.chroot has a rather messy fix involving adding a new interface to libc; this has the awkward side effect of causing the sizes of some symbols (aka. functions) in libc to change, resulting in cascading changes into many binaries. The long list of updated files is irritating, but isn't a sign that anything in freebsd-update went wrong. /quote At least they're aware the timing sucks completely and feel as sorry as us. Ty John. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
So don't update until Monday? The outcome will be the same :) Damien Fleuriot wrote: Hey up list, Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? I mean, couldn't this have waited and remained undisclosed until monday ? I for one do *NOT* relish the idea of updating 50+ boxes this evening and tomorrow ! Not to mention a whole lot of merchants and banks have toggled IT Freeze a few weeks ago, to ensure xmas shopping doesn't get disturbed by production changes. Seriously, this is just irritating. /flame ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
My point (which may or may not be valid) was that if the vulnerabilities remained *undisclosed*, they would have a much lower chance of being exploited. On 12/23/11 5:47 PM, Joe Holden wrote: So don't update until Monday? The outcome will be the same :) Damien Fleuriot wrote: Hey up list, Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? I mean, couldn't this have waited and remained undisclosed until monday ? I for one do *NOT* relish the idea of updating 50+ boxes this evening and tomorrow ! Not to mention a whole lot of merchants and banks have toggled IT Freeze a few weeks ago, to ensure xmas shopping doesn't get disturbed by production changes. Seriously, this is just irritating. /flame ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
The serious one (telnetd) is already being exploited in the wild, and if you're running telnetd anyway then you can always switch to ssh or acl the port, either way it is a relative non-issue to ignore the update for now... Damien Fleuriot wrote: My point (which may or may not be valid) was that if the vulnerabilities remained *undisclosed*, they would have a much lower chance of being exploited. On 12/23/11 5:47 PM, Joe Holden wrote: So don't update until Monday? The outcome will be the same :) Damien Fleuriot wrote: Hey up list, Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? I mean, couldn't this have waited and remained undisclosed until monday ? I for one do *NOT* relish the idea of updating 50+ boxes this evening and tomorrow ! Not to mention a whole lot of merchants and banks have toggled IT Freeze a few weeks ago, to ensure xmas shopping doesn't get disturbed by production changes. Seriously, this is just irritating. /flame ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On 12/23/11 5:50 PM, Stephen Montgomery-Smith wrote: On 12/23/2011 10:07 AM, Damien Fleuriot wrote: Hey up list, Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? After receiving the fifth security advisory in a few moments, you will get a Christmas message from the Security Advisory team, which will both apologize and explain why these untimely advisories came today. http://lists.freebsd.org/pipermail/freebsd-security-notifications/2011-December/thread.html Indeed, just read the one John copied. Still sucks, but at least they're aware and apologetic about how the timing completely blows. Happy xmas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On 12/23/2011 11:07 AM, Damien Fleuriot wrote: Hey up list, Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? The Security Officer explained it was because one of them was being actively exploited. http://lists.freebsd.org/pipermail/freebsd-security-notifications/2011-December/000165.html Also, the chroot issue has been public for some time along with sample exploits. Same with BIND which was fixed some time ago. Judgment call, and I think they made the right call at least from my perspective. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On 12/23/11 5:54 PM, Bas Smeelen wrote: Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? What's the impact for your boxes? Only the BIND exploit concerns me, means that *potentially* servers for my projects might be unable to run DNS resolution anymore - prod problems. I don't think we'll be getting trouble though so I'm postponing the update until next week. I mean, couldn't this have waited and remained undisclosed until monday ? Best time to exploit is Christmas/holidays I for one do *NOT* relish the idea of updating 50+ boxes this evening and tomorrow ! updating 30 boxes right now Not to mention a whole lot of merchants and banks have toggled IT Freeze a few weeks ago, to ensure xmas shopping doesn't get disturbed by production changes. Seriously, this is just irritating. If you don't use telnet, ftpd, dns, pam, then it's not a big problem merry Christmas Disclaimer: http://www.ose.nl/email ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
Some people (like me) already knew about the vulnerabilities. And others are already exploiting some of these vulnerabilities. Thanks, Shawn Webb On Fri, Dec 23, 2011 at 9:50 AM, Damien Fleuriot m...@my.gd wrote: My point (which may or may not be valid) was that if the vulnerabilities remained *undisclosed*, they would have a much lower chance of being exploited. On 12/23/11 5:47 PM, Joe Holden wrote: So don't update until Monday? The outcome will be the same :) Damien Fleuriot wrote: Hey up list, Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? I mean, couldn't this have waited and remained undisclosed until monday ? I for one do *NOT* relish the idea of updating 50+ boxes this evening and tomorrow ! Not to mention a whole lot of merchants and banks have toggled IT Freeze a few weeks ago, to ensure xmas shopping doesn't get disturbed by production changes. Seriously, this is just irritating. /flame ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? What's the impact for your boxes? I mean, couldn't this have waited and remained undisclosed until monday ? Best time to exploit is Christmas/holidays I for one do *NOT* relish the idea of updating 50+ boxes this evening and tomorrow ! updating 30 boxes right now Not to mention a whole lot of merchants and banks have toggled IT Freeze a few weeks ago, to ensure xmas shopping doesn't get disturbed by production changes. Seriously, this is just irritating. If you don't use telnet, ftpd, dns, pam, then it's not a big problem merry Christmas Disclaimer: http://www.ose.nl/email ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
I happen to APPLAUD the FreeBSD Security team for doing this. I WANT security fixes out as soon as reasonably possible. You're NOT telling the bad guys anything they don't already know, but you ARE making it possible for the good guys to raise shields. A remote root problem is about as bad as it gets. -- Karl Denninger /The Market Ticker/ On 12/23/2011 10:39 AM, John Baldwin wrote: On Friday, December 23, 2011 11:07:56 am Damien Fleuriot wrote: Hey up list, Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? I mean, couldn't this have waited and remained undisclosed until monday ? I for one do *NOT* relish the idea of updating 50+ boxes this evening and tomorrow ! Not to mention a whole lot of merchants and banks have toggled IT Freeze a few weeks ago, to ensure xmas shopping doesn't get disturbed by production changes. Seriously, this is just irritating. From an e-mail sent to security@ from the security officer: quote Hi all, No, the Grinch didn't steal the FreeBSD security officer GPG key, and your eyes aren't deceiving you: We really did just send out 5 security advisories. The timing, to put it bluntly, sucks. We normally aim to release advisories on Wednesdays in order to maximize the number of system administrators who will be at work already; and we try very hard to avoid issuing advisories any time close to holidays for the same reason. The start of the Christmas weekend -- in some parts of the world it's already Saturday -- is absolutely not when we want to be releasing security advisories. Unfortunately my hand was forced: One of the issues (FreeBSD-SA-11:08.telnetd) is a remote root vulnerability which is being actively exploited in the wild; bugs really don't come any worse than this. On the positive side, most people have moved past telnet and on to SSH by now; but this is still not an issue we could postpone until a more convenient time. While I'm writing, a note to freebsd-update users: FreeBSD-SA-11:07.chroot has a rather messy fix involving adding a new interface to libc; this has the awkward side effect of causing the sizes of some symbols (aka. functions) in libc to change, resulting in cascading changes into many binaries. The long list of updated files is irritating, but isn't a sign that anything in freebsd-update went wrong. /quote ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On 12/23/2011 10:07 AM, Damien Fleuriot wrote: Hey up list, Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? After receiving the fifth security advisory in a few moments, you will get a Christmas message from the Security Advisory team, which will both apologize and explain why these untimely advisories came today. http://lists.freebsd.org/pipermail/freebsd-security-notifications/2011-December/thread.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On Fri, Dec 23, 2011 at 11:39 AM, John Baldwin j...@freebsd.org wrote: On Friday, December 23, 2011 11:07:56 am Damien Fleuriot wrote: Hey up list, Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? I mean, couldn't this have waited and remained undisclosed until monday ? I for one do *NOT* relish the idea of updating 50+ boxes this evening and tomorrow ! Not to mention a whole lot of merchants and banks have toggled IT Freeze a few weeks ago, to ensure xmas shopping doesn't get disturbed by production changes. Seriously, this is just irritating. From an e-mail sent to security@ from the security officer: quote Hi all, No, the Grinch didn't steal the FreeBSD security officer GPG key, and your eyes aren't deceiving you: We really did just send out 5 security advisories. The timing, to put it bluntly, sucks. We normally aim to release advisories on Wednesdays in order to maximize the number of system administrators who will be at work already; and we try very hard to avoid issuing advisories any time close to holidays for the same reason. The start of the Christmas weekend -- in some parts of the world it's already Saturday -- is absolutely not when we want to be releasing security advisories. Unfortunately my hand was forced: One of the issues (FreeBSD-SA-11:08.telnetd) is a remote root vulnerability which is being actively exploited in the wild; bugs really don't come any worse than this. On the positive side, most people have moved past telnet and on to SSH by now; but this is still not an issue we could postpone until a more convenient time. While I'm writing, a note to freebsd-update users: FreeBSD-SA-11:07.chroot has a rather messy fix involving adding a new interface to libc; this has the awkward side effect of causing the sizes of some symbols (aka. functions) in libc to change, resulting in cascading changes into many binaries. The long list of updated files is irritating, but isn't a sign that anything in freebsd-update went wrong. /quote -- John Baldwin These vulnerabilities are known many days before in other distributions . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Mystery panic, FreeBSD 7.2-PRE
Thanks, jeremy! On 12/22/2011 05:07 PM, Jeremy Chadwick wrote: On Thu, Dec 22, 2011 at 04:04:48PM -0700, Charlie Martin wrote: We've got another mystery panic in 7.2-PRE. Upgrading is not an option; however, if this is familiar to anyone, backporting a patch would be. The stack trace is: db_trace_self_wrapper() at 0x8019120a = db_trace_self_wrapper+0x2a^M panic() at 0x80308797 = panic+0x187^M devfs_populate_loop() at 0x802a45c8 = devfs_populate_loop+0x548^M devfs_populate() at 0x802a46ab = devfs_populate+0x3b^M devfs_lookup() at 0x802a7824 = devfs_lookup+0x264^M VOP_LOO[24165][irq261: plx0] DEBUG (hasc_sv_rcv_cb): rcvd hrtbt ts 24051, 7/9, rc 0^M KUP_APV() at 0x804d5995 = VOP_LOOKUP_APV+0x95^M lookup() at 0x80384a3e = lookup+0x4ce^M namei() at 0x80385768 = namei+0x2c8^M vn_open_cred() at 0x8039b283 = vn_open_cred+0x1b3^M kern_open() at 0x8039a4a0 = kern_open+0x110^M syscall() at 0x804b0e3c = syscall+0x1ec^M Xfast_syscall() at 0x80494ecb = Xfast_syscall+0xab^M --- syscall (5, FreeBSD ELF64, open), rip = 0x800e022fc, rsp = 0x7fbfa128, rbp = 0x801002240 ---^M KDB: enter: panic^M devfs(5) has been massively worked on in RELENG_8 and newer. You should go through the below commits and see if you can find one that references a PR with a similar backtrace, or mentions things like devfs_lookup(). http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/devfs/ Also, be aware that the above stack trace is interspersed. Ultimately you get to clean up the output yourself. This is a long-standing problem with FreeBSD which can be helped but only slightly/barely by using options PRINTF_BUFR_SIZE=256 in your kernel configuration (the default configs have a value of 128. Do not increase the value too high, there are concerns about it causing major issues; I can dig up the post that says that, but I'd rather not). It *will not* solve the problem of interspersed output entirely. There still is no fix for this problem... :-( What I'm referring to: devfs_lookup() at 0x802a7824 = devfs_lookup+0x264^M VOP_LOO[24165][irq261: plx0] DEBUG (hasc_sv_rcv_cb): rcvd hrtbt ts 24051, 7/9, rc 0^M lookup() at 0x80384a3e = lookup+0x4ce^M This should actually read (I think): devfs_lookup() at 0x802a7824 = devfs_lookup+0x264^M VOP_LOOKUP_APV() at 0x804d5995 = VOP_LOOKUP_APV+0x95^M [24165][irq261: plx0] DEBUG (hasc_sv_rcv_cb): rcvd hrtbt ts 24051, 7/9, rc 0^M -- Charles R. (Charlie) Martin Senior Software Engineer SGI logo 1900 Pike Road Longmont, CO 80501 Phone: 303-532-0209 E-Mail: crmar...@sgi.com mailto:crmar...@sgi.com Website: www.sgi.com http://www.sgi.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On 12/23/2011 10:56 AM, Mike Tancsa wrote: Also, the chroot issue has been public for some time along with sample exploits. Same with BIND which was fixed some time ago. Judgment call, and I think they made the right call at least from my perspective. It is this chroot issue that bothers me. From my reading of the ftpd man page, if I have anonymous ftp to my server, it seems that I am using chroot with ftpd, and there is no way to stop this happening. Am I correct, or have I missed something? (I am hoping I missed something.) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Goo lists to subscribe to hear quickly about vulns ? ( was: Re: FLAME - security advisories on the 23rd ? uncool idea is uncool)
On topic, where do you guys subscribe to know of these vulns ahead of their release on the ML ? I'm subscribed to the BIND ML but I don't recall seeing an advisory there ahead of today. On 12/23/11 6:03 PM, Shawn Webb wrote: Some people (like me) already knew about the vulnerabilities. And others are already exploiting some of these vulnerabilities. Thanks, Shawn Webb On Fri, Dec 23, 2011 at 9:50 AM, Damien Fleuriot m...@my.gd wrote: My point (which may or may not be valid) was that if the vulnerabilities remained *undisclosed*, they would have a much lower chance of being exploited. On 12/23/11 5:47 PM, Joe Holden wrote: So don't update until Monday? The outcome will be the same :) Damien Fleuriot wrote: Hey up list, Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? I mean, couldn't this have waited and remained undisclosed until monday ? I for one do *NOT* relish the idea of updating 50+ boxes this evening and tomorrow ! Not to mention a whole lot of merchants and banks have toggled IT Freeze a few weeks ago, to ensure xmas shopping doesn't get disturbed by production changes. Seriously, this is just irritating. /flame ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 12/23/11 16:24, Jeremy Chadwick wrote:
On Fri, Dec 23, 2011 at 10:00:05AM -0500, John Baldwin wrote:
On Thursday, December 22, 2011 6:58:46 pm Jeremy Chadwick wrote:
On Fri, Dec 23, 2011 at 12:44:14AM +0100, O. Hartmann wrote:
On 12/21/11 19:41, Alexander Leidinger wrote:
Hi,
while the discussion continued here, some work started at some other
place. Now... in case someone here is willing to help instead of talking,
feel
free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what
can
be improved. The page is far from perfect and needs some additional people
which are willing to improve it.
This is only part of the problem. A tuning page in the wiki - which
could be referenced from the benchmark page - would be great too. Any
volunteers? A first step would be to take he tuning-man-page and wikify it.
Other tuning sources are welcome too.
Every FreeBSD dev with a wiki account can hand out write access to the
wiki. The benchmark page gives contributor-access. If someone wants write
access create a FirstnameLastname account and ask here for
contributor-access.
Don't worry if you think your english is not good enough, even some one-
word notes can help (and _my_ english got already corrected by other people
on
the benchmark page).
Bye,
Alexander.
Nice to see movement ;-)
But there seems something unclear:
man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in
/etc/make.conf.
The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf.
What's right and what's wrong now?
I can say with certainty that this value belongs in /etc/make.conf
(on RELENG_8 and earlier at least).
src/share/mk/bsd.own.mk has no framework for MK_MALLOC_PRODUCTION,
so, this is definitely a make.conf variable.
Eh, normal make variables can go in src.conf as well. They do not have
to be listed in bsd.own.mk. World builds include /etc/src.conf whereas
every make invocation includes /etc/make.conf via sys.mk. The only reason
to use /etc/src.conf is to have a place to put variables only affect
make buildworld / buildkernel but do not affect other make invocations.
I was always under the impression src.conf(5) variables had to be
manually added to bsd.own.mk and similar bits (e.g.
src/tools/build/options/WITH_xxx which is what's used to create the
src.conf(5) man page), but upon your comment and manual investigation on
my part, I found you're indeed right. Taken from bsd.own.mk:
107 .if !defined(_WITHOUT_SRCCONF)
108 SRCCONF?= /etc/src.conf
109 .if exists(${SRCCONF})
110 .include ${SRCCONF}
111 .endif
112 .endif
As long as third-party software doesn't depend on MALLOC_PRODUCTION for
something (I don't know why something would, but who knows; maybe
there's a third-party malloc implementation which might?), then putting
it in src.conf would be fine (src/lib/libc/stdlib files reference it).
Then the manpage should reflect this. man src.conf does not show up
MALLOC_PRODUCTIOn, but man make.conf does. If the latter is right, then
it should be worth mentioned that make.conf is incorporating src.conf.
Just a suggestion.
Regards,
Oliver
signature.asc
Description: OpenPGP digital signature
Re: Goo lists to subscribe to hear quickly about vulns ? ( was: Re: FLAME - security advisories on the 23rd ? uncool idea is uncool)
I usually hear about them from other people. I also subscribe to the full-disclosure mailinglist. On Fri, Dec 23, 2011 at 10:25 AM, Damien Fleuriot m...@my.gd wrote: On topic, where do you guys subscribe to know of these vulns ahead of their release on the ML ? I'm subscribed to the BIND ML but I don't recall seeing an advisory there ahead of today. On 12/23/11 6:03 PM, Shawn Webb wrote: Some people (like me) already knew about the vulnerabilities. And others are already exploiting some of these vulnerabilities. Thanks, Shawn Webb On Fri, Dec 23, 2011 at 9:50 AM, Damien Fleuriot m...@my.gd wrote: My point (which may or may not be valid) was that if the vulnerabilities remained *undisclosed*, they would have a much lower chance of being exploited. On 12/23/11 5:47 PM, Joe Holden wrote: So don't update until Monday? The outcome will be the same :) Damien Fleuriot wrote: Hey up list, Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? I mean, couldn't this have waited and remained undisclosed until monday ? I for one do *NOT* relish the idea of updating 50+ boxes this evening and tomorrow ! Not to mention a whole lot of merchants and banks have toggled IT Freeze a few weeks ago, to ensure xmas shopping doesn't get disturbed by production changes. Seriously, this is just irritating. /flame ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
These vulnerabilities are known many days before in other distributions . Thank you very much . Mehmet Erol Sanliturk you're right, these were discussed on the mailinglists also _but_ FreeBSD is not a distribution It is *a complete operating system* Happy holidays Disclaimer: http://www.ose.nl/email ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On Fri, Dec 23, 2011 at 7:25 PM, Stephen Montgomery-Smith step...@missouri.edu wrote: On 12/23/2011 10:56 AM, Mike Tancsa wrote: Also, the chroot issue has been public for some time along with sample exploits. Same with BIND which was fixed some time ago. Judgment call, and I think they made the right call at least from my perspective. It is this chroot issue that bothers me. From my reading of the ftpd man page, if I have anonymous ftp to my server, it seems that I am using chroot with ftpd, and there is no way to stop this happening. Am I correct, or have I missed something? (I am hoping I missed something.) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org To sum up this mess. Are all cvs mirror servers updated regarding this changes ? Also, I see that FreeBSD 9.0-RELEASE is included. Has it been released ? Regards-- George Kontostanos Aicom telecoms ltd http://www.barebsd.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/23/11 11:53, Karl Denninger wrote: I happen to APPLAUD the FreeBSD Security team for doing this. I WANT security fixes out as soon as reasonably possible. You're NOT telling the bad guys anything they don't already know, but you ARE making it possible for the good guys to raise shields. A remote root problem is about as bad as it gets. +1 Even if the timing is less than optimal, having the necessary information out there offers the opportunity for each organization to make an *informed choice* as to which vulnerabilities might be present in their deployments, which are of highest priority and what resourcing decision are appropriate in their specific context. The FreeBSD Security folk are not saying you must do this today; they *can't* make that call on our behalf - it is entirely an organizational decision based on our assessment(s) of our risk and exposure, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk70vFkACgkQQv9rrgRC1JJ1YgCdELKoI5JH8FaIjrlHm/Fco3y1 3s8AoJHarM0WhuCf0edFUWQpfkFF4g+S =Z4M2 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Goo lists to subscribe to hear quickly about vulns ? ( was: Re: FLAME - security advisories on the 23rd ? uncool idea is uncool)
On topic, where do you guys subscribe to know of these vulns ahead of their release on the ML ? security, stable and questions it has been discussed here and there Disclaimer: http://www.ose.nl/email ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On 12/23/2011 12:25 PM, Stephen Montgomery-Smith wrote: It is this chroot issue that bothers me. From my reading of the ftpd man page, if I have anonymous ftp to my server, it seems that I am using chroot with ftpd, and there is no way to stop this happening. Am I correct, or have I missed something? (I am hoping I missed something.) Depends what they can write to and upload. The thread starts here http://lists.freebsd.org/pipermail/freebsd-security/2011-November/006085.html that discusses it in more detail ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Goo lists to subscribe to hear quickly about vulns ? ( was: Re: FLAME - security advisories on the 23rd ? uncool idea is uncool)
On 23/12/2011 17:25, Damien Fleuriot wrote: I'm subscribed to the BIND ML but I don't recall seeing an advisory there ahead of today. The BIND vulnerability was discussed on bind-users last month, and updates were pushed to the ports and RELENG_7 and RELENG_8 pretty much straight away. RELENG_9 was patched slightly later. ISC's advisory is here: https://www.isc.org/software/bind/advisories/cve-2011-4313 Was also discussed on freebsd-questions@... around the same timeframe. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On Dec 23, 2011, at 11:25 AM, Stephen Montgomery-Smith wrote: On 12/23/2011 10:56 AM, Mike Tancsa wrote: Also, the chroot issue has been public for some time along with sample exploits. Same with BIND which was fixed some time ago. Judgment call, and I think they made the right call at least from my perspective. It is this chroot issue that bothers me. From my reading of the ftpd man page, if I have anonymous ftp to my server, it seems that I am using chroot with ftpd, and there is no way to stop this happening. Am I correct, or have I missed something? (I am hoping I missed something.) I think that to exploit the ftpd chroot issue, the attacker must have the ability to create an /etc/nsswitch.conf (if it doesn't already exist), and then requires installing a malicious shared library file in the chroot /lib, /usr/lib, or /usr/local/lib directory. Local users who have chroot configured on their home directory for FTP access could probably exploit this. If your anonymous FTP directories are setup correctly, in particular so that anonymous users have no write access, and if local users can't corrupt that configuration (such as by changing owners or permissions of directories in the anonymous chroot area), then I wouldn't expect this to be exploitable. Still, I would install the update as soon as possible… Guy This message has been scanned by ComplianceSafe, powered by Palisade's PacketSure. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On Fri, Dec 23, 2011 at 7:55 PM, Mike Tancsa m...@sentex.net wrote: On 12/23/2011 12:25 PM, Stephen Montgomery-Smith wrote: It is this chroot issue that bothers me. From my reading of the ftpd man page, if I have anonymous ftp to my server, it seems that I am using chroot with ftpd, and there is no way to stop this happening. Am I correct, or have I missed something? (I am hoping I missed something.) Depends what they can write to and upload. The thread starts here http://lists.freebsd.org/pipermail/freebsd-security/2011-November/006085.html that discusses it in more detail ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org Are all cvs mirror servers updated regarding these changes ? ANYBODY -- George Kontostanos Aicom telecoms ltd http://www.barebsd.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On 23/12/2011 18:05, George Kontostanos wrote: Are all cvs mirror servers updated regarding these changes ? ANYBODY Should have by now. Commits usually take about an hour to propagate to the official cvsup servers. Easy enough to tell though -- the advisories have all the version numbers in, and you'ld only need to check a file or two from each of them to be reasonably sure you'ld got all the updates. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On Fri, Dec 23, 2011 at 8:40 PM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 23/12/2011 18:05, George Kontostanos wrote: Are all cvs mirror servers updated regarding these changes ? ANYBODY Should have by now. Commits usually take about an hour to propagate to the official cvsup servers. Easy enough to tell though -- the advisories have all the version numbers in, and you'ld only need to check a file or two from each of them to be reasonably sure you'ld got all the updates. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW Thanks for the info Matthew. I think though that it is best for all to first make sure that the servers all updated before sending out all those security advisories. Regards -- George Kontostanos Aicom telecoms ltd http://www.barebsd.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
Quoting Mike Tancsa m...@sentex.net: On 12/23/2011 11:07 AM, Damien Fleuriot wrote: Hey up list, Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? The Security Officer explained it was because one of them was being actively exploited. http://lists.freebsd.org/pipermail/freebsd-security-notifications/2011-December/000165.html Also, the chroot issue has been public for some time along with sample exploits. Same with BIND which was fixed some time ago. Judgment call, and I think they made the right call at least from my perspective. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org To think a security threat could be rendered less serious based on the date of its announcement is rather provincial. You're damn right they made the right call. This message was sent using IMP, the Internet Messaging Program. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On Fri, Dec 23, 2011 at 06:30:59PM +0100, Bas Smeelen wrote: These vulnerabilities are known many days before in other distributions . Thank you very much . Mehmet Erol Sanliturk you're right, these were discussed on the mailinglists also _but_ FreeBSD is not a distribution It is *a complete operating system* Happy holidays And the D in BSD is for? ;-) pgpEZ416UIDD8.pgp Description: PGP signature
Re: SCHED_ULE should not be the default
On Thu, Dec 22, 2011 at 04:23:29PM -0800, Adrian Chadd wrote: On 22 December 2011 11:47, Steve Kargl s...@troutmask.apl.washington.edu wrote: There is the additional observation in one of my 2008 emails (URLs have been posted) that if you have N+1 cpu-bound jobs with, say, job0 and job1 ping-ponging on cpu0 (due to ULE's cpu-affinity feature) and if I kill job2 running on cpu1, then neither job0 nor job1 will migrate to cpu1. ?So, one now has N cpu-bound jobs running on N-1 cpus. .. and this sounds like a pretty serious regression. Have you ever filed a PR for it? Ah, so goods news! I cannot reproduce this problem that I saw 3+ years ago on the 4-cpu node, which is currently running a ULE kernel. When I killed the (N+1)th job, the N remaining jobs are spread across the N cpus. One difference between the 2008 tests and today tests is the number of available cpus. In 2008, I ran the tests on a node with 8 cpus, while today's test used only a node with only 4 cpus. If this behavior is a scaling issue, I can't currently test it. But, today's tests are certainly encouraging. -- Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On Fri, Dec 23, 2011 at 9:06 PM, Lars Engels lars.eng...@0x20.net wrote: On Fri, Dec 23, 2011 at 06:30:59PM +0100, Bas Smeelen wrote: These vulnerabilities are known many days before in other distributions . Thank you very much . Mehmet Erol Sanliturk you're right, these were discussed on the mailinglists also _but_ FreeBSD is not a distribution It is *a complete operating system* Happy holidays And the D in BSD is for? ;-) So, are we done for today with the security advisories ? I hate to start rebuilding world kernel again. -- George Kontostanos Aicom telecoms ltd http://www.barebsd.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On Fri, Dec 23, 2011 at 2:06 PM, Lars Engels lars.eng...@0x20.net wrote: On Fri, Dec 23, 2011 at 06:30:59PM +0100, Bas Smeelen wrote: These vulnerabilities are known many days before in other distributions . Thank you very much . Mehmet Erol Sanliturk you're right, these were discussed on the mailinglists also _but_ FreeBSD is not a distribution It is *a complete operating system* Happy holidays And the D in BSD is for? ;-) diethylamide ? -- Eitan Adler ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On 2011-Dec-23 20:06:10 +0100, Lars Engels lars.eng...@0x20.net wrote: On Fri, Dec 23, 2011 at 06:30:59PM +0100, Bas Smeelen wrote: _but_ FreeBSD is not a distribution It is *a complete operating system* Happy holidays And the D in BSD is for? ;-) FreeBSD is a complete operating system _derived_from_ the Berkeley Software Distribution that used to be available from the now-defunct UCB CSRG. The BSD in FreeBSD acknowledges its roots. And on-topic - yes, the timing sucks (especially since I'm one of the people reading this on the Saturday commencing a long holiday period) but I think the SO made the right call. Hopefully, this was all that was holding up 9.0-RELEASE and RE will be giving us a more welcome Xmas present. -- Peter Jeremy pgpJ5YZU425S5.pgp Description: PGP signature
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Fri, Dec 23, 2011 at 2:38 AM, Vincent Hoffman vi...@unsane.co.uk wrote: On 23/12/2011 02:56, Garrett Cooper wrote: On Dec 22, 2011, at 3:58 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: On Fri, Dec 23, 2011 at 12:44:14AM +0100, O. Hartmann wrote: On 12/21/11 19:41, Alexander Leidinger wrote: Hi, while the discussion continued here, some work started at some other place. Now... in case someone here is willing to help instead of talking, feel free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what can be improved. The page is far from perfect and needs some additional people which are willing to improve it. This is only part of the problem. A tuning page in the wiki - which could be referenced from the benchmark page - would be great too. Any volunteers? A first step would be to take he tuning-man-page and wikify it. Other tuning sources are welcome too. Every FreeBSD dev with a wiki account can hand out write access to the wiki. The benchmark page gives contributor-access. If someone wants write access create a FirstnameLastname account and ask here for contributor-access. Don't worry if you think your english is not good enough, even some one-word notes can help (and _my_ english got already corrected by other people on the benchmark page). Bye, Alexander. Nice to see movement ;-) But there seems something unclear: man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in /etc/make.conf. The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf. What's right and what's wrong now? I can say with certainty that this value belongs in /etc/make.conf (on RELENG_8 and earlier at least). src/share/mk/bsd.own.mk has no framework for MK_MALLOC_PRODUCTION, so, this is definitely a make.conf variable. Take the advice in tuning(7) with a grain of salt because a number of suggestions are really outdated. I know because I filed a PR last night after I saw how out of synch some of the defaults it claimed were with reality on 9.x+. And I know other suggestions in the manpage are dated as well ;/. There is a wiki page http://wiki.freebsd.org/SystemTuning which is currently more or less tuning(7) with some annotations, the idea being to sort out whats outdated/invalid with an aim of rewriting tuning(7) to be more accurate and useful. I'll grab any info in your pr thats not up there already to keep it updated if thats ok. Sure. Please take my suggestions (apart from the networking sysctls) with a grain of salt as I didn't look at the sourcecode for the filesystem ones (I was going off the top of my head and other emails I had seen passed around). I'll update the tuning 'wiki' with mention of the new networking defaults. If we want to make this manpage 'timeless', should we remove mention of defaults and go off basic guidelines (if you set this higher, you'll get better performance in scenario, X.Y.Z, etc)? Thanks! -Garrett ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On Fri, Dec 23, 2011 at 08:55:35PM +0200, George Kontostanos wrote: On Fri, Dec 23, 2011 at 8:40 PM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 23/12/2011 18:05, George Kontostanos wrote: Are all cvs mirror servers updated regarding these changes ? ANYBODY Should have by now. ?Commits usually take about an hour to propagate to the official cvsup servers. Easy enough to tell though -- the advisories have all the version numbers in, and you'ld only need to check a file or two from each of them to be reasonably sure you'ld got all the updates. ? ? ? ?Cheers, ? ? ? ?Matthew -- Dr Matthew J Seaman MA, D.Phil. ? ? ? ? ? ? ? ? ? 7 Priory Courtyard ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey ? ? Ramsgate JID: matt...@infracaninophile.co.uk ? ? ? ? ? ? ? Kent, CT11 9PW Thanks for the info Matthew. I think though that it is best for all to first make sure that the servers all updated before sending out all those security advisories. I don't believe they're monitored like that. If you want the updates quickly, download the files referenced in the advisories. My build was done before my local cvsup server picked up the changes. Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On Fri, Dec 23, 2011 at 10:48 PM, Gary Palmer gpal...@freebsd.org wrote: On Fri, Dec 23, 2011 at 08:55:35PM +0200, George Kontostanos wrote: On Fri, Dec 23, 2011 at 8:40 PM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 23/12/2011 18:05, George Kontostanos wrote: Are all cvs mirror servers updated regarding these changes ? ANYBODY Should have by now. ?Commits usually take about an hour to propagate to the official cvsup servers. Easy enough to tell though -- the advisories have all the version numbers in, and you'ld only need to check a file or two from each of them to be reasonably sure you'ld got all the updates. ? ? ? ?Cheers, ? ? ? ?Matthew -- Dr Matthew J Seaman MA, D.Phil. ? ? ? ? ? ? ? ? ? 7 Priory Courtyard ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey ? ? Ramsgate JID: matt...@infracaninophile.co.uk ? ? ? ? ? ? ? Kent, CT11 9PW Thanks for the info Matthew. I think though that it is best for all to first make sure that the servers all updated before sending out all those security advisories. I don't believe they're monitored like that. If you want the updates quickly, download the files referenced in the advisories. My build was done before my local cvsup server picked up the changes. Gary Yes, that's easy if you dealing with one server. But it is very different when you have to apply those patches to 20 different servers that are in different locations. Having a local cvsup server doing this job tends to make updating easier. In any case, and IMHO this was not the proper time for this kind of advisories considering the fact that many companies are in a freeze period. Cheers -- George Kontostanos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
As others have mentioned, you don't _have_ to patch this weekend. All of the vulnerabilities have been [semi-]public knowledge for at least a week. What's the harm in waiting till next week? Just pretend like the patches came in on Tuesday. I, for one, am grateful that FreeBSD has provided patches. It allows people who do have the time/ability to patch this weekend to do just that. If you don't want to, then don't. Simple as that. Thanks, Shawn On Fri, Dec 23, 2011 at 2:40 PM, George Kontostanos gkontos.m...@gmail.com wrote: On Fri, Dec 23, 2011 at 10:48 PM, Gary Palmer gpal...@freebsd.org wrote: On Fri, Dec 23, 2011 at 08:55:35PM +0200, George Kontostanos wrote: On Fri, Dec 23, 2011 at 8:40 PM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 23/12/2011 18:05, George Kontostanos wrote: Are all cvs mirror servers updated regarding these changes ? ANYBODY Should have by now. ?Commits usually take about an hour to propagate to the official cvsup servers. Easy enough to tell though -- the advisories have all the version numbers in, and you'ld only need to check a file or two from each of them to be reasonably sure you'ld got all the updates. ? ? ? ?Cheers, ? ? ? ?Matthew -- Dr Matthew J Seaman MA, D.Phil. ? ? ? ? ? ? ? ? ? 7 Priory Courtyard ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey ? ? Ramsgate JID: matt...@infracaninophile.co.uk ? ? ? ? ? ? ? Kent, CT11 9PW Thanks for the info Matthew. I think though that it is best for all to first make sure that the servers all updated before sending out all those security advisories. I don't believe they're monitored like that. If you want the updates quickly, download the files referenced in the advisories. My build was done before my local cvsup server picked up the changes. Gary Yes, that's easy if you dealing with one server. But it is very different when you have to apply those patches to 20 different servers that are in different locations. Having a local cvsup server doing this job tends to make updating easier. In any case, and IMHO this was not the proper time for this kind of advisories considering the fact that many companies are in a freeze period. Cheers -- George Kontostanos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On Fri, Dec 23, 2011 at 11:45 PM, Shawn Webb latt...@gmail.com wrote: As others have mentioned, you don't _have_ to patch this weekend. All of the vulnerabilities have been [semi-]public knowledge for at least a week. What's the harm in waiting till next week? Just pretend like the patches came in on Tuesday. I, for one, am grateful that FreeBSD has provided patches. It allows people who do have the time/ability to patch this weekend to do just that. If you don't want to, then don't. Simple as that. Thanks, Shawn I wish it was that simple. It is very different to be aware of a possible vulnerability from getting an official security advisory. Unfortunately sometimes, the decision to patch or not to patch, comes from people who decide based upon bureaucracy. I am certainly thankful to the FreeBSD security team for identifying and providing patches. However, when you start receiving emails about security advisories every 5 minutes, you tend to wonder when will they stop :) Regards and happy holidays George ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On 2011-Dec-23 23:40:10 +0200, George Kontostanos gkontos.m...@gmail.com wrote: In any case, and IMHO this was not the proper time for this kind of advisories considering the fact that many companies are in a freeze period. My honeypot logs suggest that the black hats aren't taking a holiday. As Colin posted, the SO had to decide between two unpalatable options and, IMHO, he made the correct decision. The details and fixes are now available - it's up to you to weigh up the risks of patching vs the risks of not patching. -- Peter Jeremy pgpwPaYsswqdf.pgp Description: PGP signature
PRINTF_BUFR_SIZE=4096?
In the course of looking at Jeremy's reponse to my query about a mystery panic, I noted his recommendation that PRINTF_BUFR_SIZE be set to 256. Ever-obedient, I went to set the value, and discovered instead that the conf file already has it set to 4096. As he says below, there are concerns about setting the value too high causing major issues. I being Christmas and all I hate to ask Jeremy to dig up the post he mentioned, but wonder if anyone can clue me in on what the major issues might be? Thanks, and regards Charlie Martin On 12/22/2011 05:07 PM, Jeremy Chadwick wrote: Also, be aware that the above stack trace is interspersed. Ultimately you get to clean up the output yourself. This is a long-standing problem with FreeBSD which can be helped but only slightly/barely by using options PRINTF_BUFR_SIZE=256 in your kernel configuration (the default configs have a value of 128. Do not increase the value too high, there are concerns about it causing major issues; I can dig up the post that says that, but I'd rather not). -- Charles R. (Charlie) Martin Senior Software Engineer SGI logo 1900 Pike Road Longmont, CO 80501 Phone: 303-532-0209 E-Mail: crmar...@sgi.com mailto:crmar...@sgi.com Website: www.sgi.com http://www.sgi.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: PRINTF_BUFR_SIZE=4096?
on 24/12/2011 00:21 Charlie Martin said the following: In the course of looking at Jeremy's reponse to my query about a mystery panic, I noted his recommendation that PRINTF_BUFR_SIZE be set to 256. Ever-obedient, I went to set the value, and discovered instead that the conf file already has it set to 4096. As he says below, there are concerns about setting the value too high causing major issues. I being Christmas and all I hate to ask Jeremy to dig up the post he mentioned, but wonder if anyone can clue me in on what the major issues might be? Stack overflow. Thanks, and regards Charlie Martin On 12/22/2011 05:07 PM, Jeremy Chadwick wrote: Also, be aware that the above stack trace is interspersed. Ultimately you get to clean up the output yourself. This is a long-standing problem with FreeBSD which can be helped but only slightly/barely by using options PRINTF_BUFR_SIZE=256 in your kernel configuration (the default configs have a value of 128. Do not increase the value too high, there are concerns about it causing major issues; I can dig up the post that says that, but I'd rather not). -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On Sat, Dec 24, 2011 at 12:02 AM, Peter Jeremy peterjer...@acm.org wrote: On 2011-Dec-23 23:40:10 +0200, George Kontostanos gkontos.m...@gmail.com wrote: In any case, and IMHO this was not the proper time for this kind of advisories considering the fact that many companies are in a freeze period. My honeypot logs suggest that the black hats aren't taking a holiday. As Colin posted, the SO had to decide between two unpalatable options and, IMHO, he made the correct decision. The details and fixes are now available - it's up to you to weigh up the risks of patching vs the risks of not patching. -- Peter Jeremy If a security advisory is announced, you have to patch, period! Happy holidays to all. Black hats too :) -- George ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: SCHED_ULE should not be the default
On 23 December 2011 11:11, Steve Kargl s...@troutmask.apl.washington.edu wrote: Ah, so goods news! I cannot reproduce this problem that I saw 3+ years ago on the 4-cpu node, which is currently running a ULE kernel. When I killed the (N+1)th job, the N remaining jobs are spread across the N cpus. Ah, good. One difference between the 2008 tests and today tests is the number of available cpus. In 2008, I ran the tests on a node with 8 cpus, while today's test used only a node with only 4 cpus. If this behavior is a scaling issue, I can't currently test it. But, today's tests are certainly encouraging. Do you not have access to anything with 8 CPUs in it? It'd be nice to get clarification that this indeed was fixed. Does ULE care (much) if the nodes are hyperthreading or real cores? Would that play a part in what it tries to schedule/spread? Adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: PRINTF_BUFR_SIZE=4096?
On Fri, Dec 23, 2011 at 03:21:06PM -0700, Charlie Martin wrote: In the course of looking at Jeremy's reponse to my query about a mystery panic, I noted his recommendation that PRINTF_BUFR_SIZE be set to 256. Ever-obedient, I went to set the value, and discovered instead that the conf file already has it set to 4096. As he says below, there are concerns about setting the value too high causing major issues. I being Christmas and all I hate to ask Jeremy to dig up the post he mentioned, but wonder if anyone can clue me in on what the major issues might be? As Andriy pointed out, potential stack overflow is the concern. The buffer size defined in the config file is allocated on the stack (e.g. char buf[4096]). The concern was mentioned by Kris Kenneway (and this is the post I eluded to): http://lists.freebsd.org/pipermail/freebsd-current/2008-February/083454.html When I was doing FreeBSD stuff as part of the Project, I added this to my Commonly Reported Issues wiki page since it comes up quite often. Search for BUFR. http://wiki.freebsd.org/BugBusting/Commonly_reported_issues John Baldwin also chimed in with some insights a few years later: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2010-06/msg00545.html http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2010-06/msg00632.html I had a conversation with John (I thought publicly but I can't find it; it's probably in my mail archives though) about this, as he has some ideas on how to solve it but he would need the time to work on it. I'll point out, however, that ddb(4) and dtrace debug (I think for debugging dtrace itself, not sure) kernel bits both use this same methodology (allocated buffer on the stack). See DDB_BUFR_SIZE and DTRACE_DEBUG_BUFR_SIZE. Linux solved this problem in a roundabout way, by implementing a ring buffer for klogd (kernel logging daemon). The below document looks daunting given its length and diagrams, but it's actually quite clever (well I thought so anyway): http://www.mjmwired.net/kernel/Documentation/trace/ring-buffer-design.txt Other info: http://www.makelinux.net/ldd3/chp-4-sect-2 On 12/22/2011 05:07 PM, Jeremy Chadwick wrote: Also, be aware that the above stack trace is interspersed. Ultimately you get to clean up the output yourself. This is a long-standing problem with FreeBSD which can be helped but only slightly/barely by using options PRINTF_BUFR_SIZE=256 in your kernel configuration (the default configs have a value of 128. Do not increase the value too high, there are concerns about it causing major issues; I can dig up the post that says that, but I'd rather not). -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: PRINTF_BUFR_SIZE=4096?
Thanks, Jeremy, I really was trying to keep you from needing to dig this out. This is inherited code with some very peculiar intermittent panics, so you can imagine that I would be interested in specifics of the odd behavior. Sadly, I don't think we're seeing any stack overflows. On 12/23/2011 03:54 PM, Jeremy Chadwick wrote: On Fri, Dec 23, 2011 at 03:21:06PM -0700, Charlie Martin wrote: When I was doing FreeBSD stuff as part of the Project, I added this to my Commonly Reported Issues wiki page since it comes up quite often. Search for BUFR. http://wiki.freebsd.org/BugBusting/Commonly_reported_issues I will note that all the Commonly reported page says is set the value to 256 and point to three examples of people seeing garbled output. -- Charles R. (Charlie) Martin Senior Software Engineer SGI logo 1900 Pike Road Longmont, CO 80501 Phone: 303-532-0209 E-Mail: crmar...@sgi.com mailto:crmar...@sgi.com Website: www.sgi.com http://www.sgi.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: SCHED_ULE should not be the default
on 24/12/2011 00:49 Adrian Chadd said the following: Does ULE care (much) if the nodes are hyperthreading or real cores? Would that play a part in what it tries to schedule/spread? An answer to this part from the theory. ULE does care about physical topology of the (logical) CPUs. So, for example, four cores are not the same as two core with two hw threads from ULE's perspective. Still, ULE tries to eliminate any imbalances between the CPU groups starting from the top level (e.g. CPU packages in a multi-socket system) and all the way down to the individual (logical) CPUs. Thus, given enough load (L = N) there should not be an idle CPU in the system whatever the topology. Modulo bugs, of course, as always. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: SCHED_ULE should not be the default
On Fri, Dec 23, 2011 at 02:49:51PM -0800, Adrian Chadd wrote: On 23 December 2011 11:11, Steve Kargl s...@troutmask.apl.washington.edu wrote: One difference between the 2008 tests and today tests is the number of available cpus. ?In 2008, I ran the tests on a node with 8 cpus, while today's test used only a node with only 4 cpus. ?If this behavior is a scaling issue, I can't currently test it. ?But, today's tests are certainly encouraging. Do you not have access to anything with 8 CPUs in it? It'd be nice to get clarification that this indeed was fixed. I have a few nodes with 8 cpus, but those are running 4BSD kernels. I try to keep my kernel and world sync, and by extension the kernel/world on each node is in sync with all other nodes. So, while I took the 4 cpu node off-line and updated it, at the moment I can't take another node off-line unless I do an update across the entire cluster. The update is planned for next year. Does ULE care (much) if the nodes are hyperthreading or real cores? Would that play a part in what it tries to schedule/spread? I only have opteron processors in the cluster, if you're referring to Intel's hypertheading technology, I can't look into ULE's behavior with HTT. -- Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: PRINTF_BUFR_SIZE=4096?
On Fri, Dec 23, 2011 at 04:02:26PM -0700, Charlie Martin wrote: Thanks, Jeremy, I really was trying to keep you from needing to dig this out. This is inherited code with some very peculiar intermittent panics, so you can imagine that I would be interested in specifics of the odd behavior. Sadly, I don't think we're seeing any stack overflows. I say this politely, not condescendingly: your last statement indicates you don't quite understand the nature of what having a large-ish stack-based buffer could do to the kernel. This is not userland. I'm pretty sure the issues you're seeing (the devfs stuff) is fixed or improved in RELENG_8, but I say that without being able to point you to a specific commit. My reasoning is that there has been a *ton* of improvements in devfs in RELENG_8 onward, and these will almost certainly not be backported to RELENG_7. You are very, *very* adamant about stating we cannot upgrade, and it is my opinion that as long as you don't upgrade, you're going to be stuck with these kind of bugs. Therefore, it would be worth your time to put forth efforts in testing RELENG_8 (not 8.2-RELEASE please; seriously, go with 8.2-STABLE (RELENG_8), just trust me on this) in a test environment and see how things go for you. I think you will be pleased with the results. You'll also get much more attentive/better support from the community/developers since RELENG_8 is supported, while RELENG_7 (especially -PRERELEASE) is losing more and more attention. It's Security EOL ends sometime early next year, and I hope you're aware of that fact as well. What I'm getting at here, without getting political: you need to start considering developing resources to help with upgrading. But for sake of example, we have a FreeBSD RELENG_6 box (6.4-STABLE) in our cluster that has actively been up for 385 days (went down a year ago because of co-lo maintenance I was doing on power conduits). If this machine suddenly panic'd, would I report the bug to -stable and so on? No. I would suck it up. On 12/23/2011 03:54 PM, Jeremy Chadwick wrote: On Fri, Dec 23, 2011 at 03:21:06PM -0700, Charlie Martin wrote: When I was doing FreeBSD stuff as part of the Project, I added this to my Commonly Reported Issues wiki page since it comes up quite often. Search for BUFR. http://wiki.freebsd.org/BugBusting/Commonly_reported_issues I will note that all the Commonly reported page says is set the value to 256 and point to three examples of people seeing garbled output. There's some history here for why that is kind of. I'll try to explain: For many years, PRINT_BUFR_SIZE was not defined in any of the default kernel configs. It was mentioned in /sys/conf/NOTES, but did not ship in GENERIC, etc.. Then after more and more people (since the FreeBSD 6.x days) began reporting interspersed kernel output, more and more developers started finding it annoying too (both the reports and the problem itself; let me tell you, it makes using ddb to debug a kernel crash in real-time), the option was added to the default kernels since it *does* improve things a little bit (better than nothing). The value 256 is something *I personally* chose, because 128 was simply not improving things enough on our systems. 256 made a bigger difference. The reason it still remains as 128 in the stock kernel configs is due to the issue I mentioned in my previous post, re: developers having justified concerns over the implications of increasing this value too high. I want readers of this thread to understand something: my previous paragraph should not elude to the higher the value, the better off you are. I have not actually *looked* at the code to see how it works. I tend to trust folks who know more about the implications (especially in kernel space) of large static buffers, but even in userland I understand the difference and implications of doing char buf[65536]; rather than char *buf = calloc(1, 65536);. TL;DR -- Don't just go increasing this value to something gigantic in hopes that the larger value means you can solve the problem. It won't solve the problem entirely. For now, *knowing* about interspersed output is enough. I'll also point out that Solaris 10 (not sure about OpenIndiana) also has this problem (we see it at work on occasion), so FreeBSD isn't alone. P.S. -- No one on this list should *ever* feel obliged to cut me some slack because of holidays. For example, for the past 10 years I have worked on every single US holiday including Christmas. I consider them just like any other day. Maybe it's because I'm not married, don't have kids, don't have a tree, etc. instead preferring to stick with relying on nostalgia/old memories of childhood Christmases and stuff like that. That's just how I am. :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 23/12/2011 20:23, Garrett Cooper wrote: On Fri, Dec 23, 2011 at 2:38 AM, Vincent Hoffman vi...@unsane.co.uk wrote: On 23/12/2011 02:56, Garrett Cooper wrote: snip There is a wiki page http://wiki.freebsd.org/SystemTuning which is currently more or less tuning(7) with some annotations, the idea being to sort out whats outdated/invalid with an aim of rewriting tuning(7) to be more accurate and useful. I'll grab any info in your pr thats not up there already to keep it updated if thats ok. Sure. Please take my suggestions (apart from the networking sysctls) with a grain of salt as I didn't look at the sourcecode for the filesystem ones (I was going off the top of my head and other emails I had seen passed around). I'll update the tuning 'wiki' with mention of the new networking defaults. If we want to make this manpage 'timeless', should we remove mention of defaults and go off basic guidelines (if you set this higher, you'll get better performance in scenario, X.Y.Z, etc)? Thanks! -Garrett Good point, for tuning the defaults are probably not so important as they are likely to change at some point (as the current man page will attest) so maybe its less important to document them. Happy Christmas (or holiday of your choice ;) to you all and I hope everyone has a good new year. Vince ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
