Re: kern/145158: [boot] 8.0-RELEASE DVD hang on boot
The following reply was made to PR kern/145158; it has been noted by GNATS. From: Miah Clayton To: bug-follo...@freebsd.org, m...@ferrousmoon.com Cc: Subject: Re: kern/145158: [boot] 8.0-RELEASE DVD hang on boot Date: Thu, 8 Jul 2010 03:07:34 -0500 --002215048e77670034048adbc7cd Content-Type: text/plain; charset=ISO-8859-1 Has there been any progress on this issue? I can't reasonably install any version of FreeBSD to do the revert myself. Moreover, why hasn't the revert been done in the mainline repository? --002215048e77670034048adbc7cd Content-Type: text/html; charset=ISO-8859-1 Has there been any progress on this issue? I can't reasonably install any version of FreeBSD to do the revert myself. Moreover, why hasn't the revert been done in the mainline repository? --002215048e77670034048adbc7cd-- ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: www/148427: [patch] ru/share/sgml/header.l10n.ent: point to Russian Security page
Synopsis: [patch] ru/share/sgml/header.l10n.ent: point to Russian Security page State-Changed-From-To: open->closed State-Changed-By: maxim State-Changed-When: Thu Jul 8 09:02:19 UTC 2010 State-Changed-Why: Committed. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=148427 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: www/148427: commit references a PR
The following reply was made to PR www/148427; it has been noted by GNATS. From: dfil...@freebsd.org (dfilter service) To: bug-follo...@freebsd.org Cc: Subject: Re: www/148427: commit references a PR Date: Thu, 8 Jul 2010 09:02:04 + (UTC) maxim 2010-07-08 09:01:49 UTC FreeBSD doc repository Modified files: ru/share/sgmlheader.l10n.ent Log: o Point to the Russian translation of the FreeBSD Security Information page. PR: misc/148427 Submitted by: pluknet Revision ChangesPath 1.7 +2 -2 www/ru/share/sgml/header.l10n.ent ___ cvs-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscr...@freebsd.org" ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/148450: recent glib20 __STDC_ISO_10646__ fix causes pidgin to crash
>Number: 148450 >Category: misc >Synopsis: recent glib20 __STDC_ISO_10646__ fix causes pidgin to crash >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jul 08 11:30:03 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Kyryll A Mirnenko >Release:RELENG_8_1 >Organization: >Environment: FreeBSD notebook 8.1-RC2 FreeBSD 8.1-RC2 #7: Wed Jul 7 23:22:36 EEST 2010 r...@miryanote:/usr/src/sys/i386/compile/MY-LITE i386 >Description: I've got devel/glib20 built WITH_COLLATION_FIX=yes . The last commit to devel/glib20/Makefile adds a __STDC_ISO_10646__ definition to configure arguments for that option. The problem is pidgin (net-im/pidgin) constantly crashes if all conditions below are met: a) glib20 built WITH_COLLATION_FIX=yes b) glib20 built after that commit (so with __STDC_ISO_10646__ definition) c) pidgin is started with uk_UA.KOI8-U locale , but works well when any of three requirements above is lifted, e.g. if i reset locale to C, or if the commit is reverted (as it was before) it works well. According to the `pidgin -d` log the crash occurs somewhere during constructing the buddy list (either read from the local configuration in ~/.purple or after an account added and the server contact list is read when started from scratch with no ~/.purple existing). Also, the possible significant condition is that the buddylist contains non-latin group names (while buddy names are all latin) >How-To-Repeat: >Fix: Revert the __STDC_ISO_10646__ definition commit or unset devel/glib20 WITH_COLLATION_FIX=yes option or run an application (pidgin) with C locale >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/148050: 9.0-CURRENT panic when tcpdump ipfw0 and net.inet.ip.fw.verbose=0
Synopsis: 9.0-CURRENT panic when tcpdump ipfw0 and net.inet.ip.fw.verbose=0 State-Changed-From-To: open->patched State-Changed-By: glebius State-Changed-When: Thu Jul 8 12:35:11 UTC 2010 State-Changed-Why: Fixed in head/. Responsible-Changed-From-To: freebsd-bugs->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Thu Jul 8 12:35:11 UTC 2010 Responsible-Changed-Why: Fixed in head/. http://www.freebsd.org/cgi/query-pr.cgi?pr=148050 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: ports/148450: devel/glib20: recent glib20 __STDC_ISO_10646__ fix causes pidgin to crash
Old Synopsis: recent glib20 __STDC_ISO_10646__ fix causes pidgin to crash New Synopsis: devel/glib20: recent glib20 __STDC_ISO_10646__ fix causes pidgin to crash Responsible-Changed-From-To: freebsd-bugs->freebsd-ports Responsible-Changed-By: remko Responsible-Changed-When: Thu Jul 8 14:57:18 UTC 2010 Responsible-Changed-Why: reassign to ports http://www.freebsd.org/cgi/query-pr.cgi?pr=148450 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64
The following reply was made to PR kern/131597; it has been noted by GNATS. From: John Baldwin To: Kostik Belousov Cc: bug-follo...@freebsd.org, guilla...@morinfr.org, k...@freebsd.org, davi...@freebsd.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Date: Thu, 8 Jul 2010 11:29:50 -0400 On Friday, April 23, 2010 10:41:11 am Kostik Belousov wrote: > On Fri, Apr 23, 2010 at 10:21:41AM -0400, John Baldwin wrote: > > On Friday 23 April 2010 9:47:40 am Kostik Belousov wrote: > > > On Fri, Apr 23, 2010 at 08:43:41AM -0400, John Baldwin wrote: > > > > On Friday 23 April 2010 8:25:01 am Kostik Belousov wrote: > > > > > On Thu, Apr 22, 2010 at 04:09:34PM -0400, John Baldwin wrote: > > > > > > I tracked the sigprocmask() system calls down to the operations to > > > > > > acquire a write lock in the runtime linker. The lock was added to > > > > > > fix > > > > > > an earlier bug with throwing exceptions in multithreaded C++ apps. > > > > > > The > > > > > > relevant commit that added the lock is this: > > > > > > > > > > > >http://svn.freebsd.org/viewvc/base?view=revision&revision=178807 > > > > > > > > > > > > Are exceptions permitted during a signal handler? If not, then in > > > > > > theory we would not need to invoke sigprocmask() for this > > > > > > particular > > > > > > lock perhaps? I'm not sure how easy that would be to achieve given > > > > > > the > > > > > > hooks to allow the thread library to overload the locking routines. > > > > > > Also, this doesn't explain the lack of sigprocmask() calls under > > > > > > i386. > > > > > > FreeBSD/i386 should be using the same locking code and thus > > > > > > invoking > > > > > > sigprocmask() for each exception as well. > > > > > > > > > > Throwing an exception during asyncronous signal execution rises > > > > > undefined > > > > > behaviour, AFAIK. sigprocmask() is there to support libc_r, and > > > > > cannot > > > > > be removed as far as we need to provide FreeBSD 4.x compatibility. > > > > > > > > Hmmm. Why does libthr use sigprocmask() for its rtld locks then? Is > > > > that > > > > just a copy-paste from libc_r that can be removed now? > > > > > > Hmmm^2. It seems it is there to prevent recursive entry into rtld from > > > signal handler, that may reference yet unresolved symbol, e.g. libc > > > syscall wrapper, from PLT. So my patch is wrong. > > > > Presumably we could use a different type of lock that doesn't use > > sigprocmask() to serialize calls do dl_iterate_phdr()? I'm not sure if > > libthr would really need to overwrite the behavior of that lock or if > > a simple atomic_cmpset()-based mutex would always be fine. > During my porting of libunwind, I was told by libunwind maintainer > that they have to call dl_iterate_phdr() from signal context to > unwind, if libunwind is called from signal context. > > Apparently, glibc' dl_iterate_phdr() is not signal-safe, while our is. [Revisiting this] Do we know of any use cases where libunwind would be used from a signal handler? Could we instead simply declare it to be an unsafe API in a signal context? longjmp(3) isn't safe in a signal context and throwing exceptions in a signal handler is undefined, so declaring libunwind to similarly be unsafe may be fine. > > OTOH, I'm not sure why libthr needs to use non-standard lock hooks at > > this point as they don't seem to be markedly different from the ones > > rtld uses. > > libthr locks provide exclusion both for other kernel-executed threads > and signal handlers, while the rtld-default locks only protect against > signal handlers and thus libc_r-style threads. Oh, bah. The rtld locks do use atomic operations that are thread safe, but I missed that the 'oldsigmask' global needs to be per-thread. -- John Baldwin ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/148444: intel driver freezes system
The following reply was made to PR misc/148444; it has been noted by GNATS. From: Sergey Shavandin To: bug-follo...@freebsd.org, sers...@yahoo.com Cc: Subject: Re: misc/148444: intel driver freezes system Date: Thu, 8 Jul 2010 09:40:27 -0700 (PDT) --0-1066443832-1278607227=:18453 Content-Type: text/plain; charset=us-ascii discussion in forum: http://forums.freebsd.org/showthread.php?p=91597#post91597 --0-1066443832-1278607227=:18453 Content-Type: text/html; charset=us-ascii discussion in forum:http://forums.freebsd.org/showthread.php?p=91597#post91597";>http://forums.freebsd.org/showthread.php?p=91597#post91597 --0-1066443832-1278607227=:18453-- ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: i386/148444: [hang] intel driver freezes system with 855gm
Old Synopsis: intel driver freezes system New Synopsis: [hang] intel driver freezes system with 855gm Responsible-Changed-From-To: freebsd-bugs->freebsd-i386 Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jul 8 21:52:07 UTC 2010 Responsible-Changed-Why: This may be hardware-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=148444 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/148463: ARP cache can be poisoned or polluted with ease.
>Number: 148463 >Category: misc >Synopsis: ARP cache can be poisoned or polluted with ease. >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jul 09 06:20:03 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Paul-Andrew Joseph Miseiko >Release:8.1-PRERELEASE >Organization: >Environment: FreeBSD teardrop.ca 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #1: Wed Jul 7 22:18:16 EDT 2010 esote...@teardrop.ca:/usr/obj/usr/src/sys/TEARDROP i386 >Description: FreeBSD will add to the kernel ARP cache the source hardware address associated with the source protocol address when an ARP request packet or ARP reply packet is received and the target protocol address is the same as the interface protocol address. A malicious user could use this behavior to alter the hardware address associated with a particular protocol address. FreeBSD will accept the new hardware address associated with a particular protocol address that is known in the ARP cache. A malicious user could use this behavior to perform a denial of service against the kernel ARP cache when a FreeBSD device is bound to a large network. FreeBSD will create a kernel ARP cache entry for each ARP request packet and ARP reply packet received. >How-To-Repeat: Send an ARP request packet or ARP response packet to the physical broadcast address (or physical interface address) with the target protocol address set to a FreeBSD device and the source hardware address and source protocol address set to the desired protocol address to poison in the FreeBSD device kernel ARP cache or populate the FreeBSD kernel ARP cache with excessive entries. >Fix: #1. FreeBSD should not permit alteration of a kernel ARP cache entry if it has not made an explicit ARP request for the protocol address associated with the kernel ARP cache entry. The time-to-live for a kernel ARP cache entry might need to be shortened for this to work well in heterogeneous environments. Some of the risk involved with malicious intent to redirect a protocol address to a specific hardware address will be mitigated through this change. To perform a malicious action with this constraint would result in a race condition for when a FreeBSD device has made an ARP request to be the first to produce the expected ARP reply. In theory a malicious user might send several ARP replies in anticipation of an ARP request. The FreeBSD device could detect such behavior and log a message, remove the kernel ARP cache entry due to the suspicious circumstance, or accept the least frequency ARP reply. #2. FreeBSD should not create a kernel ARP cache entry for a protocol address it has not made an ARP request for. The risk of a remote malicious user triggering a potential denial of service against the kernel ARP cache would be eliminated through this change. Note. The suggested solution(s) above could have a sysctl option to enable them. A FreeBSD device on a trusted network would not require protection from malicious intent through the ARP protocol. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
