Re: bin/179451: new installer: Install fails on raid
Old Synopsis: Install fails on raid New Synopsis: new installer: Install fails on raid Responsible-Changed-From-To: freebsd-i386-freebsd-bugs Responsible-Changed-By: remko Responsible-Changed-When: Fri Jun 28 06:39:53 UTC 2013 Responsible-Changed-Why: This is not something i386 specific, assign to the bugs pool. http://www.freebsd.org/cgi/query-pr.cgi?pr=179451 ___ 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/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly
On Mon, Jun 24, 2013 at 03:59:24AM +, lini...@freebsd.org wrote: Old Synopsis: [patch] Multicast SO_REUSEADDR handled incorrectly New Synopsis: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly Responsible-Changed-From-To: freebsd-bugs-freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jun 24 03:59:05 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=179901 ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org I don't know if this is related or a different bug, but the same mentioned commits are suspicious for us. We had been running with our own IPv6 software into the same REUSEADDR problem and changed to REUSEPORT as this is how it is done in mcastread from mcast-tools port. Don't know where we originally got the REUSEADDR from, probably a Stevens book. So far binding works with this change in our software. However we only receive packets from network and not packets from the host itself. We use multicast to notify multiple processes on multiple machines, including the machine itself. To reproduce: - use two hosts - start mcastread on each of them on an interface with shared LAN - send via mcastsend on one host - packets are received on the other host, but not with the mcastread on the same host -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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/180052: www/squid3x ports: some helpers are not built/installed
Number: 180052 Category: misc Synopsis: www/squid3x ports: some helpers are not built/installed 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 Jun 28 10:50:00 UTC 2013 Closed-Date: Last-Modified: Originator: Eugene Zheganin Release:10.x-CURRENT Organization: Vivat-Trade LLC Environment: FreeBSD taiga 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r247150M: Mon Mar 4 17:57:07 YEKT 2013 emz@taiga:/usr/obj/usr/src/sys/TAIGADBG amd64 Description: Selecting both [x] AUTH_KERB [x] AUTH_LDAP should add the kerberos_ldap_group helper to the --enable-external-acl-helpers= configure option, and the port should build/install this helper. This a reference implementation that supports SASL/GSSAPI authentication to an ldap server. It is mainly intended to connect to Active Directory or Openldap based ldap servers. Thi is a very popular helper nowadays, it has a killer feature - it supports nested LDAP groups up to given nesting level, which is crucial in Windows/AD environment, where most of groups are usually nested. How-To-Repeat: Fix: 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: ports/180052: www/squid3x ports: some helpers are not built/installed
Synopsis: www/squid3x ports: some helpers are not built/installed Responsible-Changed-From-To: freebsd-bugs-freebsd-ports-bugs Responsible-Changed-By: remko Responsible-Changed-When: Fri Jun 28 11:47:10 UTC 2013 Responsible-Changed-Why: reassign to ports team http://www.freebsd.org/cgi/query-pr.cgi?pr=180052 ___ 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/180052: www/squid3x ports: some helpers are not built/installed
Yup, my mistake. I figured out that selecting AUTH_LDAP and AUTH_SASL gives the squid_kerb_group helper (which not that obvious, but OK). ___ 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
kern/180060: ZFS kernel panic, solaris assert on dsl_prop_unregister
Number: 180060 Category: kern Synopsis: ZFS kernel panic, solaris assert on dsl_prop_unregister 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 Jun 28 15:20:00 UTC 2013 Closed-Date: Last-Modified: Originator: James TD Smith Release:9.1 Organization: Environment: FreeBSD masada.internal.mohorovi.cc 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #5 r251934: Tue Jun 18 15:41:34 BST 2013 r...@masada.internal.mohorovi.cc:/usr/obj/usr/src/sys/MASADA amd64 Description: I've had two ZFS-related kernel panics over the last few days. Both have happened since I upgraded to 9.1-RELEASE-4 on the 18th. PR 154447 has similar backtraces but was on 8.2, I can't find any other references to a similar problem. It's a mixed UFS/ZFS system, root is on UFS with a single 4-disk RAIDZ1 pool used for backups, a media library, poudriere and a few other jails. I replaced one of the disks in the pool earlier this week which had been failing for a while and have been tuning the ZFS settings based on this guide: http://icesquare.com/wordpress/how-to-improve-zfs-performance/ after I upgraded to 4Gb RAM. Jun 25 08:12:57 masada kernel: panic: solaris assert: dsl_prop_unregister(ds, atime, atime_changed_cb, zfsvfs) == 0, file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, line: 1199 Jun 25 08:12:57 masada kernel: cpuid = 0 Jun 25 08:12:57 masada kernel: KDB: stack backtrace: Jun 25 08:12:57 masada kernel: #0 0x80926c96 at kdb_backtrace+0x66 Jun 25 08:12:57 masada kernel: #1 0x808f0cae at panic+0x1ce Jun 25 08:12:57 masada kernel: #2 0x816b5647 at zfs_unregister_callbacks+0x1b7 Jun 25 08:12:57 masada kernel: #3 0x816b58c5 at zfsvfs_teardown+0x175 Jun 25 08:12:57 masada kernel: #4 0x816b5a2b at zfs_suspend_fs+0x1b Jun 25 08:12:57 masada kernel: #5 0x816aa229 at zfs_ioc_rollback+0xf9 Jun 25 08:12:57 masada kernel: #6 0x816abd46 at zfsdev_ioctl+0xe6 Jun 25 08:12:57 masada kernel: #7 0x807e077b at devfs_ioctl_f+0x7b Jun 25 08:12:57 masada kernel: #8 0x80938715 at kern_ioctl+0x115 Jun 25 08:12:57 masada kernel: #9 0x8093894d at sys_ioctl+0xfd Jun 25 08:12:57 masada kernel: #10 0x80be71d6 at amd64_syscall+0x546 Jun 28 04:08:02 masada kernel: panic: solaris assert: dsl_prop_unregister(ds, snapdir, snapdir_changed_cb, zfsvfs) == 0, file: /usr/src/sys/modules/zfs/../.. /cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, line: 1217 Jun 28 04:08:02 masada kernel: cpuid = 1 Jun 28 04:08:02 masada kernel: KDB: stack backtrace: Jun 28 04:08:02 masada kernel: #0 0x80926c96 at kdb_backtrace+0x66 Jun 28 04:08:02 masada kernel: #1 0x808f0cae at panic+0x1ce Jun 28 04:08:02 masada kernel: #2 0x816b570d at zfs_unregister_callbacks+0x27d Jun 28 04:08:02 masada kernel: #3 0x816b58c5 at zfsvfs_teardown+0x175 Jun 28 04:08:02 masada kernel: #4 0x816b5a2b at zfs_suspend_fs+0x1b Jun 28 04:08:02 masada kernel: #5 0x816aa229 at zfs_ioc_rollback+0xf9 Jun 28 04:08:02 masada kernel: #6 0x816abd46 at zfsdev_ioctl+0xe6 Jun 28 04:08:02 masada kernel: #7 0x807e077b at devfs_ioctl_f+0x7b Jun 28 04:08:02 masada kernel: #8 0x80938715 at kern_ioctl+0x115 Jun 28 04:08:02 masada kernel: #9 0x8093894d at sys_ioctl+0xfd Jun 28 04:08:02 masada kernel: #10 0x80be71d6 at amd64_syscall+0x546 How-To-Repeat: I think it's more likely to happen under heavy IO load. This machine has rsnaphot backups scheduled to run every 4 hours, both of the crashes have occurred shortly after a backup began. It was also building packages with poudriere at the same time in both instances. Fix: 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/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 j...@freebsd.org To: bug-follo...@freebsd.org, guilla...@morinfr.org Cc: k...@freebsd.org, thera...@freebsd.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Date: Fri, 28 Jun 2013 08:47:55 -0400 Looking at this again, the patch committed in 178807 is just wrong and should be reverted. There is no state in rtld that needs to be protected via a write lock. GCC is too lazy to use their own locking to protect shared state between threads and wants the runtime linker to enforce this. Their justification that glibc doesn't allow concurrent execution of this isn't a valid excuse. For an API like this that just walks a list and invokes a callback, if the callback manipulates shared state owned by the caller, the caller should be responsible for sychronizing access to it, not rtld! Instead I think we should apply the patch in the original GCC bug to our in- tree GCC and to our GCC ports. This should remove the sigprocmask calls and not penalize other users of dl_iterate_phdr() for GCC's poor behavior. -- 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: 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: Konstantin Belousov kostik...@gmail.com To: John Baldwin j...@freebsd.org Cc: bug-follo...@freebsd.org, guilla...@morinfr.org, thera...@freebsd.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Date: Fri, 28 Jun 2013 20:17:21 +0300 --hhtCH1hro9pJkPIH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 28, 2013 at 08:47:55AM -0400, John Baldwin wrote: Looking at this again, the patch committed in 178807 is just wrong and sh= ould=20 be reverted. There is no state in rtld that needs to be protected via a = write=20 lock. GCC is too lazy to use their own locking to protect shared state= =20 between threads and wants the runtime linker to enforce this. Their=20 justification that glibc doesn't allow concurrent execution of this isn't= a=20 valid excuse. For an API like this that just walks a list and invokes a= =20 callback, if the callback manipulates shared state owned by the caller, t= he=20 caller should be responsible for sychronizing access to it, not rtld! =20 Instead I think we should apply the patch in the original GCC bug to our = in- tree GCC and to our GCC ports. This should remove the sigprocmask calls = and not penalize other users of dl_iterate_phdr() for GCC's poor behavior. In other words, we should become knowingly incompatible with the stock GCC and with other consumers of dl_iterate_phdr(), like libunwind ? E.g. libunwind ability to unwind from the signal handler relies on this behaviour. --hhtCH1hro9pJkPIH Content-Type: application/pgp-signature -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRzcUgAAoJEJDCuSvBvK1BBuwQAIWoFrFkw9Op7RybuuAw9K5h f49+JDpcscYrQcF8KSYWiUdV3ZcoBnubqKpT+6vWm5MQ4PwUCEv3ouKAhD/oe4n+ oJg3pQz+mFicI7s0Wr3rJFyf0vO5wcHnxDOq7XdjHIPlGqTZcnOjubdCJ42xpZkT 7004JA8B8WHitjh+9qJGQWOUDfBzUWDE3WwieqpYnKricnFhJh8/6gTg6abbZGkE 6szxxKdPMUHJ28X54HU1DV9A2TJgfjLsGIzneQtfpOp7TTIyTKfn2hFHp5eLhWB/ voH0HAegdg7ew3MaCl2fnGKb6UR0h3yShowp3KfH1LozmZNDw6C/6VSKwy55aSYY GaVXlWEhniim7NaRgP2okdMPEz07pUt3KoIN5mQGrlvgusTUa7YXcrwCm97l72dT EqjgffvFUPmmHP38jhgf/wkI1aQ6tY7eSqSLDM+MMBX6TnPKx4EAr3H/tc79idEx O89zUHFJPuI7YY563O+dR0Bm09kIDPVNb3hTG09JF2KCxY3QYlje8Iu5ndKOLCi+ HvFwnTLpDEFEd22oNWdSeNUq97Rr2mAMSv5dk9A+a8mtsRbzPSeuylIKSEEKquDu USJ2ZyISoTnZbb6Iz6SYkZRn8vOBRUfBbpPRcAJh2FkBTegl7JE7dS3tM7C26uzf MxGTc8YbAXTWA1XFxyZR =hwdp -END PGP SIGNATURE- --hhtCH1hro9pJkPIH-- ___ 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: Konstantin Belousov kostik...@gmail.com To: John Baldwin j...@freebsd.org Cc: bug-follo...@freebsd.org, guilla...@morinfr.org, thera...@freebsd.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Date: Fri, 28 Jun 2013 20:45:38 +0300 --8C4Pdt+UNHoLxtm5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 28, 2013 at 01:38:39PM -0400, John Baldwin wrote: On Friday, June 28, 2013 1:17:21 pm Konstantin Belousov wrote: On Fri, Jun 28, 2013 at 08:47:55AM -0400, John Baldwin wrote: Looking at this again, the patch committed in 178807 is just wrong an= d should=20 be reverted. There is no state in rtld that needs to be protected vi= a a write=20 lock. GCC is too lazy to use their own locking to protect shared sta= te=20 between threads and wants the runtime linker to enforce this. Their= =20 justification that glibc doesn't allow concurrent execution of this i= sn't a=20 valid excuse. For an API like this that just walks a list and invoke= s a=20 callback, if the callback manipulates shared state owned by the calle= r, the=20 caller should be responsible for sychronizing access to it, not rtld! =20 Instead I think we should apply the patch in the original GCC bug to = our in- tree GCC and to our GCC ports. This should remove the sigprocmask ca= lls and not penalize other users of dl_iterate_phdr() for GCC's poor behavior. =20 In other words, we should become knowingly incompatible with the stock GCC and with other consumers of dl_iterate_phdr(), like libunwind ? E.g. libunwind ability to unwind from the signal handler relies on this behaviour. =20 Does libunwind depend on rtld single-threading to lock state shared with other threads? If it does it should manage that itself. If GCC and/or libunwind want to share arbitrary state between threads, or protect state from being accessed by a signal handler, then GCC and/or libunwind should manage that. rtld can't possibly (and shouldn't) know the rules about how that state that is private to GCC/libunwind is managed. libunwind depends on the dl_iterate_phdr() signal-safety. =20 What if you had a consumer of this that wanted to access the state outside of the callback? Then it already has to manage all the locking itself to be safe anyway. =20 Put another way, requiring dl_iterate_phdr() to providing locking for con= sumers would be equivalent to code assuming that C++'s for_each() template in algorithm provided locking to callers. That is entirely upside-down. I think I should revive the fast sigprocmask patch. --8C4Pdt+UNHoLxtm5 Content-Type: application/pgp-signature -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRzcvBAAoJEJDCuSvBvK1B9UgP/jne8523ys+JZDGUn9izYhJk LlT5LSSARhTcbREEsIevB5VQt2pbDtKsca/fCtLmaasPN5cb8XgLeyy1J3caB742 LdrXLcczv8PvSJM0D7EDTH6ktGrmAl0i9cHb8sLqHuPAD7/ZNBJRfJXWdRe4Rs3r /A78kqAdyGlJAupQ+2ocbtsIOg8F1G3L3b7iZ+gA7+txErCv5th6H3+lXalpF+8X 40FDUvpoU9roOesa9vKcQLFWcBMedLkVmTujmHrvFfMuz6zXu+0Anje5Zc0LPOSu hst4vYimFxn/VXQuU5qmGKhhz0o0jtwJzdF836aJotx2tsQWuBLWZiKSBffKQFeB D6aK0GlMlK/i6LQD+LeJbjB+k0/jxgK6ZtdetUPnPCUjeHE5IKDrm1Z0yMzMC/20 H5AQ3WdFR7Jvu11ZK6jp2aqX6BDUTTwW85c1Y/k2n5+I48vD1EDXRDO73aQkHyM8 0EU5kCPS1CRbXsf4XeGlye/YhJBNS7Hp/tdNSjhSjHckA78xLUsoKeo6LfCmFtG6 GT8oDSmyugQl6QwCNzNp9bjKJ3wSI1TZjBr8GNQI/kXZJpaJkFb6mzLLLhUbjtt/ XHrA2gaJDE9eTlOohoBO8zJ8bXe1ykK/YuduXdsAfpqKH4KckkEqUiA1ptrMV7C6 9olJnLJJMrgbMjv955u6 =/5H4 -END PGP SIGNATURE- --8C4Pdt+UNHoLxtm5-- ___ 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/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly
On Fri, Jun 28, 2013 at 12:15:14PM +0200, Bernd Walter wrote: On Mon, Jun 24, 2013 at 03:59:24AM +, lini...@freebsd.org wrote: Old Synopsis: [patch] Multicast SO_REUSEADDR handled incorrectly New Synopsis: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly Responsible-Changed-From-To: freebsd-bugs-freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jun 24 03:59:05 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=179901 ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org I don't know if this is related or a different bug, but the same mentioned commits are suspicious for us. We had been running with our own IPv6 software into the same REUSEADDR problem and changed to REUSEPORT as this is how it is done in mcastread from mcast-tools port. Don't know where we originally got the REUSEADDR from, probably a Stevens book. So far binding works with this change in our software. However we only receive packets from network and not packets from the host itself. We use multicast to notify multiple processes on multiple machines, including the machine itself. To reproduce: - use two hosts - start mcastread on each of them on an interface with shared LAN - send via mcastsend on one host - packets are received on the other host, but not with the mcastread on the same host It is unrelated, but I have found the cause for it and filed kern/180065 together with a working patch. The reason is that the packets have no valid checksums when processed in ip6_input because of delayed checksum changes. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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
kern/180065: Multicast loopback to own host broken
Number: 180065
Category: kern
Synopsis: Multicast loopback to own host broken
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 Jun 28 18:50:00 UTC 2013
Closed-Date:
Last-Modified:
Originator: Bernd Walter
Release:9.1-STABLE
Organization:
Environment:
Description:
Using IPv6 multicast it is impossible to receive packets on the same host.
Problem is that the packet checksums are not calculated yet when the packet is
handed over to if_simloop() and get dropped later in udp6_input().
The fix handles the problem with IPv6, but it wasn't verified if IPv4 code has
a similar bug.
How-To-Repeat:
send packet via mcastsend from mcast-tools port and try to receive the packet
with mcread on the same host.
Another host can receive the packet, but no process on the same host.
Fix:
Index: netinet6/ip6_output.c
===
--- netinet6/ip6_output.c (revision 251406)
+++ netinet6/ip6_output.c (working copy)
@@ -749,6 +749,13 @@
}
if ((im6o == NULL in6_mcast_loop) ||
(im6o im6o-im6o_multicast_loop)) {
+
+ if (m-m_pkthdr.csum_flags CSUM_DELAY_DATA_IPV6) {
+ plen = m-m_pkthdr.len - sizeof(*ip6);
+ in6_delayed_cksum(m, plen, sizeof(struct ip6_hdr));
+ m-m_pkthdr.csum_flags = ~CSUM_DELAY_DATA_IPV6;
+ }
+
/*
* Loop back multicast datagram if not expressly
* forbidden to do so, even if we have not joined
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
kern/180067: Multicast support within jails
Number: 180067
Category: kern
Synopsis: Multicast support within jails
Confidential: no
Severity: non-critical
Priority: low
Responsible:freebsd-bugs
State: open
Quarter:
Keywords:
Date-Required:
Class: change-request
Submitter-Id: current-users
Arrival-Date: Fri Jun 28 19:00:00 UTC 2013
Closed-Date:
Last-Modified:
Originator: Bernd Walter
Release:9.1-STABLE
Organization:
Environment:
Description:
To have multicast support in Jails it is required to allow group addresses to
be configured for the jail.
In reality this is impossible as multicast groups are not always a local
decision.
It also disallows joining the same multicast group within multiple jails.
The tiny patch allows IPv6 multicast adresses to be used within jails without
special configuration.
It is used in production since more than one year, but considered more as an
example than a complete patch.
A similar check should also be done for IPv4 and maybe placed under a sysctl or
jail option which is disabled by default.
This change was worked out together with Aron Schlesinger a...@paefchen.net.
How-To-Repeat:
Fix:
Index: kern/kern_jail.c
===
--- kern/kern_jail.c(revision 251406)
+++ kern/kern_jail.c(working copy)
@@ -3282,6 +3282,9 @@
{
int i, a, z, d;
+ if (IN6_IS_ADDR_MULTICAST(ia6))
+ return (0);
+
/*
* Check the primary IP.
*/
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/180060: [zfs] [panic] ZFS kernel panic, solaris assert on dsl_prop_unregister
Old Synopsis: ZFS kernel panic, solaris assert on dsl_prop_unregister New Synopsis: [zfs] [panic] ZFS kernel panic, solaris assert on dsl_prop_unregister Responsible-Changed-From-To: freebsd-bugs-freebsd-zfs-devel Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jun 28 19:57:40 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=180060 ___ 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/180065: [netinet6] [patch] Multicast loopback to own host broken
Old Synopsis: Multicast loopback to own host broken New Synopsis: [netinet6] [patch] Multicast loopback to own host broken Responsible-Changed-From-To: freebsd-bugs-freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jun 28 19:59:39 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=180065 ___ 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/180067: [jail] [patch] fix multicast support within jails
Old Synopsis: Multicast support within jails New Synopsis: [jail] [patch] fix multicast support within jails Responsible-Changed-From-To: freebsd-bugs-freebsd-jail Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jun 28 20:00:04 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=180067 ___ 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
conf/180078: [PATCH] make /etc and /var writable on CD media
Number: 180078
Category: conf
Synopsis: [PATCH] make /etc and /var writable on CD media
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: Sat Jun 29 03:20:00 UTC 2013
Closed-Date:
Last-Modified:
Originator: Garrett Cooper
Release:10-CURRENT
Organization:
EMC Isilon
Environment:
FreeBSD fuji-current.local 10.0-CURRENT FreeBSD 10.0-CURRENT #3
r+b278358-dirty: Sun Jun 9 16:05:39 PDT 2013
root@fuji-current.local:/usr/obj/usr/src/sys/FUJI-NOCOMPAT i386
Description:
The attached patch makes /etc/ and /var/ writable via /etc/rc.initdiskless
which allows me to use /etc and /var as volatile filesystems [until reboot],
accomplishing some of the following basic tasks:
- Starting the hostid service (needed for doing things with ZFS).
- Starting sshd (otherwise it can't write out keys to /etc/ssh/ .
- Setting passwords / adding custom users.
- Start dhclient (dhclient requires write access to /etc/resolv.conf and
/var/run/{interface}.leases
Etc.
How-To-Repeat:
Fix:
Patch attached with submission follows:
diff --git a/release/amd64/mkisoimages.sh b/release/amd64/mkisoimages.sh
index e4093d7..6ae3713 100644
--- a/release/amd64/mkisoimages.sh
+++ b/release/amd64/mkisoimages.sh
@@ -40,6 +40,15 @@ LABEL=`echo $1 | tr '[:lower:]' '[:upper:]'`; shift
NAME=$1; shift
publisher=The FreeBSD Project. http://www.FreeBSD.org/;
+dirs=etc var
+for d in $dirs; do
+ mkdir -p $1/conf/base/$d/
+ echo 30720 $1/conf/base/$d/md_size
+ tar cf - -C $1/$d/ . | tar xpvf - -C $1/conf/base/$d/
+done
+: $1/etc/diskless
echo /dev/iso9660/$LABEL / cd9660 ro 0 0 $1/etc/fstab
makefs -t cd9660 $bootable -o rockridge -o label=$LABEL -o
publisher=$publisher $NAME $*
+chflags -R 0 $1/conf
+rm -Rf $1/conf
rm $1/etc/fstab
diff --git a/release/i386/mkisoimages.sh b/release/i386/mkisoimages.sh
index e4093d7..6ae3713 100644
--- a/release/i386/mkisoimages.sh
+++ b/release/i386/mkisoimages.sh
@@ -40,6 +40,15 @@ LABEL=`echo $1 | tr '[:lower:]' '[:upper:]'`; shift
NAME=$1; shift
publisher=The FreeBSD Project. http://www.FreeBSD.org/;
+dirs=etc var
+for d in $dirs; do
+ mkdir -p $1/conf/base/$d/
+ echo 30720 $1/conf/base/$d/md_size
+ tar cf - -C $1/$d/ . | tar xpvf - -C $1/conf/base/$d/
+done
+: $1/etc/diskless
echo /dev/iso9660/$LABEL / cd9660 ro 0 0 $1/etc/fstab
makefs -t cd9660 $bootable -o rockridge -o label=$LABEL -o
publisher=$publisher $NAME $*
+chflags -R 0 $1/conf
+rm -Rf $1/conf
rm $1/etc/fstab
diff --git a/release/ia64/mkisoimages.sh b/release/ia64/mkisoimages.sh
index b5cec32..7d8c27a 100644
--- a/release/ia64/mkisoimages.sh
+++ b/release/ia64/mkisoimages.sh
@@ -76,8 +76,17 @@ else
fi
publisher=The FreeBSD Project. http://www.FreeBSD.org/;
+dirs=etc var
+for d in $dirs; do
+ mkdir -p $1/conf/base/$d/
+ echo 30720 $1/conf/base/$d/md_size
+ tar cf - -C $1/$d/ . | tar xpvf - -C $1/conf/base/$d/
+done
+: $1/etc/diskless
echo /dev/iso9660/$LABEL / cd9660 ro 0 0 $BASE/etc/fstab
makefs -t cd9660 $BOOTOPTS -o rockridge -o label=$LABEL -o
publisher=$publisher $NAME $BASE $*
+chflags -R 0 $1/conf
+rm -Rf $1/conf
rm $BASE/etc/fstab
rm -f $EFIPART
exit 0
diff --git a/release/pc98/mkisoimages.sh b/release/pc98/mkisoimages.sh
index 5a19b4d..803f936 100644
--- a/release/pc98/mkisoimages.sh
+++ b/release/pc98/mkisoimages.sh
@@ -40,6 +40,15 @@ LABEL=`echo $1 | tr '[:lower:]' '[:upper:]'`; shift
NAME=$1; shift
publisher=The FreeBSD Project. http://www.FreeBSD.org/;
+dirs=etc var
+for d in $dirs; do
+ mkdir -p $1/conf/base/$d/
+ echo 30720 $1/conf/base/$d/md_size
+ tar cf - -C $1/$d/ . | tar xpvf - -C $1/conf/base/$d/
+done
+: $1/etc/diskless
echo /dev/iso9660/$LABEL / cd9660 ro 0 0 $1/etc/fstab
makefs -t cd9660 $bootable -o rockridge -o label=$LABEL -o
publisher=$publisher $NAME $*
+chflags -R 0 $1/conf
+rm -Rf $1/conf
rm $1/etc/fstab
diff --git a/release/powerpc/mkisoimages.sh b/release/powerpc/mkisoimages.sh
index 7ba4649..0117ca6 100644
--- a/release/powerpc/mkisoimages.sh
+++ b/release/powerpc/mkisoimages.sh
@@ -62,8 +62,17 @@ LABEL=`echo $1 | tr '[:lower:]' '[:upper:]'`; shift
NAME=$1; shift
publisher=The FreeBSD Project. http://www.FreeBSD.org/;
+dirs=etc var
+for d in $dirs; do
+ mkdir -p $1/conf/base/$d/
+ echo 30720 $1/conf/base/$d/md_size
+ tar cf - -C $1/$d/ . | tar xpvf - -C $1/conf/base/$d/
+done
+: $1/etc/diskless
echo /dev/iso9660/$LABEL / cd9660 ro 0 0 $1/etc/fstab
makefs -t cd9660 $bootable -o rockridge -o label=$LABEL -o
publisher=$publisher $NAME $*
+chflags -R 0 $1/conf
+rm -Rf $1/conf
rm $1/etc/fstab
rm /tmp/hfs-boot-block
rm -rf $1/ppc
diff --git a/release/sparc64/mkisoimages.sh b/release/sparc64/mkisoimages.sh
index 82cadab..c2f9fc4 100644
---
Re: conf/180078: [PATCH] make /etc and /var writable on CD media
Synopsis: [PATCH] make /etc and /var writable on CD media Responsible-Changed-From-To: freebsd-bugs-re Responsible-Changed-By: gjb Responsible-Changed-When: Sat Jun 29 03:30:15 UTC 2013 Responsible-Changed-Why: re@ territory. http://www.freebsd.org/cgi/query-pr.cgi?pr=180078 ___ 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
