ETA for ZFS v. 13 Merge From HEAD ?
Hi Pawel, Coming back to the subject, when do you think we might have a merge of r185029 (import of ZFS version 13) from head back into -stable ? Is there anything we can help with to speed up the process (e.g. testing) ? PS: ZFS-FUSE on Linux has also reached v 13... Thank you, Adrian Penisoara ROFUG / EnterpriseBSD --- Date: Wed, 26 Nov 2008 10:52:41 +0100 From: Pawel Jakub Dawidek Subject: Re: svn commit: r185029 - in head: cddl/compat/opensolaris/include cddl/compat/opensolaris/misc cddl/contrib/opensolaris/cmd/zdb cddl/contrib/opensolaris/cmd/zfs cddl/contrib/opensolaris/cmd/zinject cd... To: Attila Nagy Cc: svn-src-h...@freebsd.org, svn-src-...@freebsd.org, src-committ...@freebsd.org Message-ID: <20081126095241.ga3...@garage.freebsd.pl> Content-Type: text/plain; charset="us-ascii" On Wed, Nov 26, 2008 at 10:15:58AM +0100, Attila Nagy wrote: > Hello, > > Pawel Jakub Dawidek wrote: > >Author: pjd > >Date: Mon Nov 17 20:49:29 2008 > >New Revision: 185029 > >URL: http://svn.freebsd.org/changeset/base/185029 > > > >Log: > > Update ZFS from version 6 to 13 and bring some FreeBSD-specific changes. > > > This, and other changes stabilized ZFS by a great level in HEAD. > Do you plan to MFC these to 7-STABLE? Yes, but ETA yet. -- Pawel Jakub Dawidek http://www.wheel.pl p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Bug in tcp wrappers?
Hi Chris,
On Fri, 13 Mar 2009, Chris St Denis wrote:
I think I've found a bug in libwrap/tcpwrappers.
I think so too :) See below.
Before filing an actual bug report I want to get some feedback here
first.
A hosts.allow file with ~1000 ips on a single line (Haven't experimented with
other quantities yet), causes network daemons that use libwrap stop accepting
incoming network connections and use 100% cpu on an incoming connection.
This problem appeared because sshguard placed a large number of IPs in my
hosts.allow file triggering this bug.
I've left the affected daemons for a long period of time (once about 8 hours)
and they don't seem to come back, so I think this is more than just it taking
a while to loop through a 1000 item array of IPs
The production system that was affected is FreeBSD 7.0-32bit
Test system is FreeBSD 7.1-32bit
Example hosts.allow file (IPs are randomly generated for purposes of example)
sshd : 112.110.123.63 113.11.2.126 113.11.8.6 113.19.19.22
113.197.48.68 116.48.108.244 116.48.11.19 : deny
ALL : ALL : allow
top output of affected system. sshd wcpu slowly crawls up to 100% over about
30 seconds or so.
crash# top
last pid: 692; load averages: 0.08, 0.04,0.04
up
0+00:12:13 15:42:30
24 processes: 2 running, 22 sleeping
CPU: 49.7% user, 0.0% nice, 0.2% system, 0.2% interrupt, 49.9% idle
Mem: 9304K Active, 6004K Inact, 21M Wired, 32K Cache, 10M Buf, 947M Free
Swap: 1995M Total, 1995M Free
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU
COMMAND
691 root1 1030 5760K 3660K CPU1 1 0:04 33.98% sshd
672 root1 40 8436K 3888K sbwait 1 0:00 0.00% sshd
677 cstdenis1 200 4460K 2288K pause 0 0:00 0.00% csh
682 root1 200 5484K 2632K pause 0 0:00 0.00% csh
675 cstdenis1 440 8436K 3896K select 0 0:00 0.00% sshd
A backtrace shows
crash# gdb /usr/sbin/sshd 691
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-marcel-freebsd"...
Attaching to program: /usr/sbin/sshd, process 691
Reading symbols from /usr/lib/libssh.so.4...done.
Loaded symbols for /usr/lib/libssh.so.4
Reading symbols from /lib/libutil.so.7...done.
Loaded symbols for /lib/libutil.so.7
Reading symbols from /lib/libz.so.4...done.
Loaded symbols for /lib/libz.so.4
Reading symbols from /usr/lib/libwrap.so.5...done.
Loaded symbols for /usr/lib/libwrap.so.5
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
0x28373225 in fgets (buf=0xbfbfe67b "", n=1, fp=0x283b8040) at
/usr/src/lib/libc/stdio/fgets.c:56
56 {
(gdb) bt
#0 0x28373225 in fgets (buf=0xbfbfe67b "", n=1, fp=0x283b8040) at
/usr/src/lib/libc/stdio/fgets.c:56
#1 0x281124ee in xgets (ptr=0xbfbfe67b "", len=1, fp=0x283b8040) at
/usr/src/lib/libwrap/../../contrib/tcp_wrappers/misc.c:38
#2 0x28111410 in table_match (table=0x28112c5c "/etc/hosts.allow",
request=0xbfbfeb14)
at
/usr/src/lib/libwrap/../../contrib/tcp_wrappers/hosts_access.c:162
#3 0x28111540 in hosts_access (request=0xbfbfeb14) at
/usr/src/lib/libwrap/../../contrib/tcp_wrappers/hosts_access.c:132
#4 0x08052b39 in main (ac=2, av=0xbfbfeecc) at
/usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:1843
(gdb) bt
#0 0x28373225 in fgets (buf=0xbfbfe67b "", n=1, fp=0x283b8040) at
/usr/src/lib/libc/stdio/fgets.c:56
#1 0x281124ee in xgets (ptr=0xbfbfe67b "", len=1, fp=0x283b8040) at
/usr/src/lib/libwrap/../../contrib/tcp_wrappers/misc.c:38
#2 0x28111410 in table_match (table=0x28112c5c "/etc/hosts.allow",
request=0xbfbfeb14)
at
/usr/src/lib/libwrap/../../contrib/tcp_wrappers/hosts_access.c:162
#3 0x28111540 in hosts_access (request=0xbfbfeb14) at
/usr/src/lib/libwrap/../../contrib/tcp_wrappers/hosts_access.c:132
#4 0x08052b39 in main (ac=2, av=0xbfbfeecc) at
/usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:1843
(gdb) q
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program: /usr/sbin/sshd, process 691
A few questions
1. Is this a known issue of any sort? I've done some searching on it, but
haven't found anything of interest.
2. Should this be reported to FreeBSD bug tracker, or to libwrap (or both)?
Basically, is FreeBSD's libwrap (more or less) in sync with the main one, or
is it completely separate?
When given an input line of more than 2k bytes, libwrap ends up in an
infinite loop in xgets(), calling fgets() with a read length of one.
As fgets() reads the length minus one characters, it will keep
"reading"
Re: Bug in tcp wrappers?
On Sun, 15 Mar 2009, Mikko Työläjärvi wrote: The real fix involves rewriting chunks of the libwrap code, or finding a version where someone has already done so. It doesn't seem like it should be too bad. xgets is only called in three places. It would be easy enough to replace it with something like glibc's getline(3), that uses realloc to size a buffer appropriately. If nobody else feels like doing this, maybe I will. -- Nate Eldredge neldre...@math.ucsd.edu___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Bug in tcp wrappers?
On Sun, 15 Mar 2009, Nate Eldredge wrote: On Sun, 15 Mar 2009, Mikko Työläjärvi wrote: The real fix involves rewriting chunks of the libwrap code, or finding a version where someone has already done so. It doesn't seem like it should be too bad. xgets is only called in three places. It would be easy enough to replace it with something like glibc's getline(3), that uses realloc to size a buffer appropriately. Yes, it should be pretty straightforward. I just noticed that openbsd applied a (better) variant of my patch for the infinite loop problem in 2003. They didn't address the "line too long" problem, though. If nobody else feels like doing this, maybe I will. And if you don't, I just might :) /Mikko___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ETA for ZFS v. 13 Merge From HEAD ?
Hi Adrian, I am not sure, but I didnt think ZFS 13 was ever going to be merged into 7-stable. I thought the kernel memory requirements were to great (just going back in my memory on that one). Also, I think there are still a few bugs left with the zil being enabled (and/or prefetch) causing lockups on machine with a lot of IO. I know I have hit that bug a few times on my machine when using various torrent clients when they want to preallocate large amounts of diskspace. I personally cant wait until a later version of ZFS is imported that supports encryption. I can finally say good-bye to our GEOM ELI USB drives for backups!! Never the less, I am quite thankfull to thoes involved in porting V13 to FreeBSD. Its a wonderfull improvement and my FS of choice when installing on new machines (especially zfs boot) Best regards, Peg - Original Message - From: "Adrian Penisoara" To: "Pawel Jakub Dawidek" Cc: ; Sent: Sunday, March 15, 2009 7:09 PM Subject: ETA for ZFS v. 13 Merge From HEAD ? Hi Pawel, Coming back to the subject, when do you think we might have a merge of r185029 (import of ZFS version 13) from head back into -stable ? Is there anything we can help with to speed up the process (e.g. testing) ? PS: ZFS-FUSE on Linux has also reached v 13... Thank you, Adrian Penisoara ROFUG / EnterpriseBSD --- Date: Wed, 26 Nov 2008 10:52:41 +0100 From: Pawel Jakub Dawidek Subject: Re: svn commit: r185029 - in head: cddl/compat/opensolaris/include cddl/compat/opensolaris/misc cddl/contrib/opensolaris/cmd/zdb cddl/contrib/opensolaris/cmd/zfs cddl/contrib/opensolaris/cmd/zinject cd... To: Attila Nagy Cc: svn-src-h...@freebsd.org, svn-src-...@freebsd.org, src-committ...@freebsd.org Message-ID: <20081126095241.ga3...@garage.freebsd.pl> Content-Type: text/plain; charset="us-ascii" On Wed, Nov 26, 2008 at 10:15:58AM +0100, Attila Nagy wrote: Hello, Pawel Jakub Dawidek wrote: >Author: pjd >Date: Mon Nov 17 20:49:29 2008 >New Revision: 185029 >URL: http://svn.freebsd.org/changeset/base/185029 > >Log: > Update ZFS from version 6 to 13 and bring some FreeBSD-specific changes. > This, and other changes stabilized ZFS by a great level in HEAD. Do you plan to MFC these to 7-STABLE? Yes, but ETA yet. -- Pawel Jakub Dawidek http://www.wheel.pl p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
