kern/176167: [ipsec][lagg] using lagg and ipsec causes immediate panic
>Number: 176167
>Category: kern
>Synopsis: [ipsec][lagg] using lagg and ipsec causes immediate panic
>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 Feb 15 11:40:01 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Andrew A. Khlebutin
>Release:FreeBSD 9.1-STABLE #0 r246709
>Organization:
JSC DartIT
>Environment:
FreeBSD smfd-app-1 9.1-STABLE FreeBSD 9.1-STABLE #0 r246709: Tue Feb 12
17:39:19 YEKT 2013 root@smfd-app-1:/usr/obj/usr/src/sys/smfd-app amd64
>Description:
Using ipsec with lagg causes my server to panic. The crash is reproducible.
IPSEC (transport mode) is used to encrypt tunnel (gif) over lagg.
Turn off ipsec and there is no problem, everything is working fine.
current process= 1577 (ping)
trap number= 12
panic: page fault
cpuid = 11
KDB: stack backtrace:
#0 0x8050acd6 at kdb_backtrace+0x66
#1 0x804d441e at panic+0x1ce
#2 0x8074dea0 at trap_fatal+0x290
#3 0x8074e1d8 at trap_pfault+0x1e8
#4 0x8074e7de at trap+0x3be
#5 0x80737f7f at calltrap+0x8
#6 0x805d8db3 at ip_ipsec_output+0x173
#7 0x805da991 at ip_output+0x531
#8 0x805cb72f at in_gif_output+ox47f
#9 0x8059596f at gif_output+ox28f
#10 0x805dab59 at ip_output+ox6f9
#11 0x805dc679 at rip_output+0x229
#12 0x80540cf6 at sosend_generic+0x3f6
#13 0x805445c3 at kern_sendit+0x1a3
#14 0x8054587c at sendit+0xdc
#15 0x8054496d at sys_sendto+0x4d
#16 0x8074d780 at amd64_syscall+0x540
#17 0x80738267 at Xfast_syscall+0xf7
# ifconfig
igb0: flags=8843 metric 0 mtu 1500
options=401bb
ether c8:60:00:46:bc:5f
media: Ethernet autoselect (1000baseT )
status: active
igb1: flags=8843 metric 0 mtu 1500
options=401bb
ether c8:60:00:46:bc:5f
media: Ethernet autoselect (1000baseT )
status: active
igb2: flags=8843 metric 0 mtu 1500
options=401bb
ether c8:60:00:46:bc:5f
media: Ethernet autoselect (1000baseT )
status: active
igb3: flags=8843 metric 0 mtu 1500
options=401bb
ether c8:60:00:46:bc:5f
media: Ethernet autoselect (1000baseT )
status: active
ipfw0: flags=8801 metric 0 mtu 65536
lo0: flags=8049 metric 0 mtu 16384
options=63
inet 127.0.0.1 netmask 0xff00
lagg0: flags=8843 metric 0 mtu 1500
options=401bb
ether c8:60:00:46:bc:5f
inet x.x.x.x netmask 0xffe0 broadcast x.x.x.255
media: Ethernet autoselect
status: active
laggproto lacp lagghash l2,l3,l4
laggport: igb3 flags=1c
laggport: igb2 flags=1c
laggport: igb1 flags=1c
laggport: igb0 flags=1c
vlan2: flags=8843 metric 0 mtu 1500
options=103
ether c8:60:00:46:bc:5f
inet 192.168.253.1 netmask 0xff00 broadcast 192.168.253.255
inet 192.168.253.129 netmask 0x broadcast 192.168.253.129
media: Ethernet autoselect
status: active
vlan: 2 parent interface: lagg0
gif0: flags=8051 metric 0 mtu 1500
tunnel inet x.x.x.x --> y.y.y.y
inet 172.16.0.22 --> 172.16.0.21 netmask 0xfffc
options=1
IPSEC:
spdadd y.y.y.y x.x.x.x ipencap -P in ipsec esp/transport//require
ah/transport//require;
spdadd x.x.x.x y.y.y.y ipencap -P out ipsec esp/transport//require
ah/transport//require;
racoon.conf:
pathcertificate "/usr/local/etc/racoon/certs";
log debug;
padding {
maximum_length 20;
randomize off;
strict_checkoff;
exclusive_tail off;
}
listen {
isakmp x.x.x.x [500];
}
timer # timing options. change as needed
{
counter 5;
interval20 sec;
persend 1;
phase1 30 sec;
phase2 15 sec;
}
remote y.y.y.y {
exchange_mode aggressive, main;
doi ipsec_doi;
situation identity_only;
my_identifier asn1dn;
peers_identifier asn1dn;
verify_identifier on;
certificate_type x509 "smfd-app-1.crt" "smfd-app-1.key";
ca_type x509 "ca.crt";
ike_frag on;
lifetime time 1 hour;
proposal {
encryption_algorithm aes;
hash_algorithm sha256;
authentication_method rsasig;
dh_group 2;
}
}
sainfo anonymous {
pfs_group 2;
lifetime time 1 hour;
encryption_algorithm aes;
authentication_algorithm hmac_sha256;
compression_algorithm deflate;
}
>How-To-Repeat:
ping another end of a tunnel
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://list
Re: kern/176093: [libc] [patch] Fix resolver support for ' _' character in hostnames
The following reply was made to PR kern/176093; it has been noted by GNATS.
From: Landon Fuller
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/176093: [libc] [patch] Fix resolver support for '_'
character in hostnames
Date: Fri, 15 Feb 2013 08:39:04 -0500
A simpler test case:
#include
#include
int main (int argc, char *argv[]) {
if (argc < 2) return 1;
int ret = res_hnok(argv[1]);
printf("%d\n", ret);
}
Usage:
landonf:~> ./test-res_hnok gc._msdcs.example.org
0
landonf:~> ./test-res_hnok gc.msdcs.example.org
1
___
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/176169: system unresponsive for 1min after mounting flash read-only
>Number: 176169
>Category: kern
>Synopsis: system unresponsive for 1min after mounting flash read-only
>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 Feb 15 13:50:03 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Norbert Koch
>Release:FreeBSD 9.1
>Organization:
>Environment:
FreeBSD 9.1 RELEASE
>Description:
This problem has already been reported and fixed(?) in pfsense's bug tracking
system by adding the sysctl vfs.forcesync.
The author of the fix is Ermal Luçi ( http://redmine.pfsense.org/users/6 ).
http://redmine.pfsense.org/projects/pfsense-tools/repository/revisions/008742971cb44d8c0f81929504ab7330442c4ba4/entry/patches/RELENG_8_3/vfs_subr_mount_RO.diff
I tried this under FreeBSD 9.1 and it seems to work.
mount -ow / ; time mount -orf /
: 65s without patch
With patch time is <1s.
As I am no vfs expert I do not know what potential negative consequences
this change may have.
The original patch uses CTLFLAG_RD for forcesync. I do not see why
this should not be CTLFLAG_RW.
>How-To-Repeat:
>Fix:
diff -r 89885db951fb src/sys/kern/vfs_subr.c
--- a/src/sys/kern/vfs_subr.c Mon Feb 04 14:45:48 2013 +0100
+++ b/src/sys/kern/vfs_subr.c Fri Feb 15 14:32:09 2013 +0100
@@ -121,6 +121,11 @@
SYSCTL_ULONG(_vfs, OID_AUTO, numvnodes, CTLFLAG_RD, &numvnodes, 0,
"Number of vnodes in existence");
+static int forcesync;
+
+SYSCTL_INT(_vfs, OID_AUTO, forcesync, CTLFLAG_RW, &forcesync, 0,
+"Do full checks when switching to RO mount of FS");
+
/*
* Conversion tables for conversion from vnode types to inode formats
* and back.
@@ -2581,6 +2586,7 @@
* vnodes open for writing.
*/
if (flags & WRITECLOSE) {
+if (forcesync) {
if (vp->v_object != NULL) {
VM_OBJECT_LOCK(vp->v_object);
vm_object_page_clean(vp->v_object, 0, 0, 0);
@@ -2593,6 +2599,7 @@
MNT_VNODE_FOREACH_ALL_ABORT(mp, mvp);
return (error);
}
+}
error = VOP_GETATTR(vp, &vattr, td->td_ucred);
VI_LOCK(vp);
>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/176167: [ipsec][lagg] using lagg and ipsec causes immediate panic
Synopsis: [ipsec][lagg] using lagg and ipsec causes immediate panic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Feb 15 13:56:52 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=176167 ___ 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: bin/5296: slattach fails creating pidfile with ioctl(TIOCSCTTY): Operation not permitted
Synopsis: slattach fails creating pidfile with ioctl(TIOCSCTTY): Operation not permitted State-Changed-From-To: suspended->closed State-Changed-By: emaste State-Changed-When: Fri Feb 15 14:53:47 UTC 2013 State-Changed-Why: Time to move on; SLIP is long gone. http://www.freebsd.org/cgi/query-pr.cgi?pr=5296 ___ 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: bin/175743: [patch] Patches for kgdb(1) - improve test of arguments; update manpage
Synopsis: [patch] Patches for kgdb(1) - improve test of arguments; update manpage Responsible-Changed-From-To: freebsd-bugs->adrian Responsible-Changed-By: emaste Responsible-Changed-When: Fri Feb 15 14:58:57 UTC 2013 Responsible-Changed-Why: kgdb's -b is Adrian's addition http://www.freebsd.org/cgi/query-pr.cgi?pr=175743 ___ 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: gnu/175985: [PATCH] Improve send-pr
The following reply was made to PR gnu/175985; it has been noted by GNATS. From: Eitan Adler To: Christoph Mallon Cc: bug-followup Subject: Re: gnu/175985: [PATCH] Improve send-pr Date: Fri, 15 Feb 2013 13:25:30 -0500 On 9 February 2013 08:50, Christoph Mallon wrote: I have not yet looked at the code. >>Description: > - Do not delete lines starting with Subject:. > They are most probably part of a attached git patch. This is probably fine, but I am curious why they were removed in the past. How does GNATS actually treat the subject line? > - Recognize an empty file as a not filled out PR, too. This is fine with me. > - Allow attaching files via -- followed by file names. This is fine with me. -- Eitan Adler Source, Ports, Doc committer Bugmeister, Ports Security teams ___ 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/176179: nfs client KASSERT: panic: attempt to set TDF_SBDRY recursively
>Number: 176179 >Category: kern >Synopsis: nfs client KASSERT: panic: attempt to set TDF_SBDRY recursively >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 Feb 15 19:30:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Russell Cattelan >Release:FreeBSD-current 2/12/2013 >Organization: Digitalelves Inc >Environment: FreeBSD 10 running on vmware fusion >Description: Ran into this while doing a make buildworld. The vmserver is a os x 10.8 box and was hosting the src tree. FreeBSD 10 was using nfs client code to mount the src via a local only network link login: panic: attempt to set TDF_SBDRY recursively cpuid = 0 KDB: enter: panic [ thread pid 3747 tid 100095 ] Stopped at kdb_enter+0x3e: movq$0,kdb_why db> db> bt Tracing pid 3747 tid 100095 td 0xfe0001a8c900 kdb_enter() at kdb_enter+0x3e/frame 0xff8015464bd0 vpanic() at vpanic+0x147/frame 0xff8015464c10 kassert_panic() at kassert_panic+0x136/frame 0xff8015464c80 sigdeferstop() at sigdeferstop+0x5d/frame 0xff8015464ca0 newnfs_set_sigmask() at newnfs_set_sigmask+0x1e8/frame 0xff8015464ce0 newnfs_request() at newnfs_request+0xb0/frame 0xff8015464e10 nfscl_request() at nfscl_request+0x72/frame 0xff8015464e60 nfsrpc_write() at nfsrpc_write+0x456/frame 0xff8015465050 ncl_writerpc() at ncl_writerpc+0xe1/frame 0xff8015465190 ncl_doio() at ncl_doio+0x3f6/frame 0xff8015465230 nfs_strategy() at nfs_strategy+0x7d/frame 0xff8015465260 VOP_STRATEGY_APV() at VOP_STRATEGY_APV+0xd0/frame 0xff8015465280 bufstrategy() at bufstrategy+0x46/frame 0xff80154652c0 ncl_writebp() at ncl_writebp+0xb5/frame 0xff80154652f0 getblk() at getblk+0x3ae/frame 0xff8015465390 nfs_getcacheblk() at nfs_getcacheblk+0x58/frame 0xff80154653e0 ncl_write() at ncl_write+0x720/frame 0xff80154655a0 VOP_WRITE_APV() at VOP_WRITE_APV+0x13b/frame 0xff80154656b0 vn_write() at vn_write+0x2f0/frame 0xff8015465740 vn_io_fault() at vn_io_fault+0x22a/frame 0xff80154658c0 dofilewrite() at dofilewrite+0x85/frame 0xff8015465910 kern_writev() at kern_writev+0x48/frame 0xff8015465950 sys_write() at sys_write+0x63/frame 0xff80154659a0 amd64_syscall() at amd64_syscall+0x265/frame 0xff8015465ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff8015465ab0 --- syscall (4, FreeBSD ELF64, sys_write), rip = 0x4bcbfa, rsp = 0x7fffc748, rbp = 0x7fffc770 --- db> >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: kern/176179: [nfs] nfs client KASSERT: panic: attempt to set TDF_SBDRY recursively
Old Synopsis: nfs client KASSERT: panic: attempt to set TDF_SBDRY recursively New Synopsis: [nfs] nfs client KASSERT: panic: attempt to set TDF_SBDRY recursively Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Feb 15 21:57:04 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=176179 ___ 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"
bin/176181: rc.subr emitting warnings for non-defined xxx_enable vars, and errors/warnings not going to terminal
>Number: 176181 >Category: bin >Synopsis: rc.subr emitting warnings for non-defined xxx_enable vars, and >errors/warnings not going to terminal >Confidential: no >Severity: non-critical >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Feb 15 22:10:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Jeremy Chadwick >Release:FreeBSD 9.1-STABLE amd64 >Organization: >Environment: System: FreeBSD icarus.home.lan 9.1-STABLE FreeBSD 9.1-STABLE #0 r246644: Sun Feb 10 16:55:49 PST 2013 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64 amd64 >Description: The following discussion has taken place on freebsd-stable: http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072303.html http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072304.html http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072317.html http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072318.html http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072319.html http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072320.html There are two issues as I see them: 1. Lack of a defined xxx_enable variable in rc.conf(5) (regardless of the value) results in warn() being called. Ex: WARNING: $svnserve_enable is not set properly - see rc.conf(5). A lack of definition of xxx_enable variable should be treated as the same as xxx_enable="no" (i.e. the service is disabled) and should not emit a warning. 2. When using service(8), the warn() calls are not making it to the user's terminal -- they only end up in /var/log/messages. Looking at rc.subr(8), it appears the echo statements in err() and warn() are not making it to the user's terminal. I tried using "logger -s" and it made no difference -- it's as if some part of the rc.subr infrastructure is redirecting stdout and stderr to /dev/null way before the echo statements. >How-To-Repeat: * Install a port that uses rc.d in some way * Make sure there is no xxx_enable variable set for it in /etc/rc.conf * Run "service -e" * Check /var/log/messages >Fix: The patch provided by Alfred Bartsch does address issue #1, however I feel that (effectively) changing checkyesno() to remove the warn() is not the right solution. I believe it would be wiser to handle the situation through, for example, an "if [ -n $xxx_enable ]" test of some kind. >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/175674: commit references a PR
The following reply was made to PR kern/175674; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/175674: commit references a PR
Date: Sat, 16 Feb 2013 06:07:16 + (UTC)
Author: davidxu
Date: Sat Feb 16 06:07:07 2013
New Revision: 246872
URL: http://svnweb.freebsd.org/changeset/base/246872
Log:
Simplify code by using flag O_EXLOCK.
PR: kern/175674
Modified:
head/lib/libc/gen/sem_new.c
Modified: head/lib/libc/gen/sem_new.c
==
--- head/lib/libc/gen/sem_new.cSat Feb 16 05:22:48 2013
(r246871)
+++ head/lib/libc/gen/sem_new.cSat Feb 16 06:07:07 2013
(r246872)
@@ -198,15 +198,11 @@ _sem_open(const char *name, int flags, .
goto error;
}
- fd = _open(path, flags|O_RDWR|O_CLOEXEC, mode);
+ fd = _open(path, flags|O_RDWR|O_CLOEXEC|O_EXLOCK, mode);
if (fd == -1)
goto error;
- if (flock(fd, LOCK_EX) == -1)
+ if (_fstat(fd, &sb))
goto error;
- if (_fstat(fd, &sb)) {
- flock(fd, LOCK_UN);
- goto error;
- }
if (sb.st_size < sizeof(sem_t)) {
sem_t tmp;
@@ -214,10 +210,8 @@ _sem_open(const char *name, int flags, .
tmp._kern._has_waiters = 0;
tmp._kern._count = value;
tmp._kern._flags = USYNC_PROCESS_SHARED | SEM_NAMED;
- if (_write(fd, &tmp, sizeof(tmp)) != sizeof(tmp)) {
- flock(fd, LOCK_UN);
+ if (_write(fd, &tmp, sizeof(tmp)) != sizeof(tmp))
goto error;
- }
}
flock(fd, LOCK_UN);
sem = (sem_t *)mmap(NULL, sizeof(sem_t), PROT_READ|PROT_WRITE,
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-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"
Re: gnu/175985: [PATCH] Improve send-pr
The following reply was made to PR gnu/175985; it has been noted by GNATS. From: Christoph Mallon To: Eitan Adler Cc: bug-followup Subject: Re: gnu/175985: [PATCH] Improve send-pr Date: Sat, 16 Feb 2013 08:04:16 +0100 On 15.02.2013 19:25, Eitan Adler wrote: > On 9 February 2013 08:50, Christoph Mallon wrote: > > I have not yet looked at the code. > >>> Description: >> - Do not delete lines starting with Subject:. >> They are most probably part of a attached git patch. > > This is probably fine, but I am curious why they were removed in the > past. How does GNATS actually treat the subject line? There is no Subject line in the PR template presented to the user. After the user finishes filling out the PR template, send-pr adds a Subject line with a copy of the Synopsis. I guess, GNATS shows the Subject just like any other field. send-pr ensures, that Subject and Synopsis are the same (Have a look at some random PRs). >> - Recognize an empty file as a not filled out PR, too. > > This is fine with me. >> - Allow attaching files via -- followed by file names. > > This is fine with me. I also have another patch, which adds a dummy file after each file. GNATS does not recognize every other file. This works around the problem. The proper solution would be to correct the problem in GNATS. Christoph ___ 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"
