Re: bin/153142: [zfs] ls -l outputs `ls: ./.zfs: Operation not supported'
The following reply was made to PR bin/153142; it has been noted by GNATS. From: Jaakko Heinonen To: Hiroshi Fujishima Cc: Bruce Cran , bug-follo...@freebsd.org, tr...@freebsd.org Subject: Re: bin/153142: [zfs] ls -l outputs `ls: ./.zfs: Operation not supported' Date: Fri, 14 Jan 2011 11:00:50 +0200 Hi, On 2010-12-14, Hiroshi Fujishima wrote: > >Description: > 1. filesystem is zfs > 2. snapdir property is visible > 3. top directory of file system has .a file. > > with above condition, ls -l outputs `ls: ./.zfs: Operation not supported' > > >How-To-Repeat: > backup8y# zfs create -o mountpoint=/test -o snapdir=visible tank/test > backup8y# ls -l /test > total 0 > dr-xr-xr-x 3 root wheel 3 Dec 14 15:46 .zfs > backup8y# touch /test/.a > backup8y# ls -l /test > total 1 > -rw-r--r-- 1 root wheel 0 Dec 14 15:46 .a > ls: /test/.zfs: Operation not supported > dr-xr-xr-x 3 root wheel 3 Dec 14 15:46 .zfs ls(1) detects from the first file in the listing if the file system supports ACLs and assumes that all files on the same file system support ACLs. The ".zfs" directory is special and doesn't support ACLs. Thus ls(1) prints an error message for acl_get_link_np(3) failure. Also, if the ".zfs" directory is the first entry of a listing, ls(1) assumes that files on the same file system don't have ACLs and doesn't print '+' after mode. -- Jaakko ___ 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/153142: [zfs] ls -l outputs `ls: ./.zfs: Operation not supported'
The following reply was made to PR bin/153142; it has been noted by GNATS. From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= To: Jaakko Heinonen Cc: Hiroshi Fujishima , Bruce Cran , bug-follo...@freebsd.org Subject: Re: bin/153142: [zfs] ls -l outputs `ls: ./.zfs: Operation not supported' Date: Fri, 14 Jan 2011 10:07:02 +0100 Wiadomo=B6=E6 napisana przez Jaakko Heinonen w dniu 2011-01-14, o godz. = 10:00: > On 2010-12-14, Hiroshi Fujishima wrote: >>> Description: >> 1. filesystem is zfs >> 2. snapdir property is visible >> 3. top directory of file system has .a file. >>=20 >> with above condition, ls -l outputs `ls: ./.zfs: Operation not = supported' >>=20 >>> How-To-Repeat: >> backup8y# zfs create -o mountpoint=3D/test -o snapdir=3Dvisible = tank/test >> backup8y# ls -l /test >> total 0 >> dr-xr-xr-x 3 root wheel 3 Dec 14 15:46 .zfs >> backup8y# touch /test/.a >> backup8y# ls -l /test >> total 1 >> -rw-r--r-- 1 root wheel 0 Dec 14 15:46 .a >> ls: /test/.zfs: Operation not supported >> dr-xr-xr-x 3 root wheel 3 Dec 14 15:46 .zfs >=20 > ls(1) detects from the first file in the listing if the file system > supports ACLs and assumes that all files on the same file system = support > ACLs. The ".zfs" directory is special and doesn't support ACLs. Thus > ls(1) prints an error message for acl_get_link_np(3) failure. >=20 > Also, if the ".zfs" directory is the first entry of a listing, ls(1) > assumes that files on the same file system don't have ACLs and doesn't > print '+' after mode. I guess the easiest way to fix this would be to add "dummy" ACL support for ".zfs" directory - that is, to zfsctl_ops_root[], if I'm reading = this correctly. -- If you cut off my head, what would I say? Me and my head, or me and my = body? ___ 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/150206: [libc] [patch] nmount(2): can't switch root partition to rw using mount flags
Synopsis: [libc] [patch] nmount(2): can't switch root partition to rw using mount flags State-Changed-From-To: open->feedback State-Changed-By: jh State-Changed-When: Fri Jan 14 12:31:47 UTC 2011 State-Changed-Why: Could you try if the patch linked in the message at http://docs.freebsd.org/cgi/mid.cgi?20110114122454.GA4805 solves your problem? Responsible-Changed-From-To: freebsd-bugs->jh Responsible-Changed-By: jh Responsible-Changed-When: Fri Jan 14 12:31:47 UTC 2011 Responsible-Changed-Why: Track. http://www.freebsd.org/cgi/query-pr.cgi?pr=150206 ___ 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/100516: [atapicam] atapicam with ITE IT8212F crashes the system
Synopsis: [atapicam] atapicam with ITE IT8212F crashes the system State-Changed-From-To: open->feedback State-Changed-By: jh State-Changed-When: Fri Jan 14 13:42:26 UTC 2011 State-Changed-Why: Can you still reproduce this on a supported release? http://www.freebsd.org/cgi/query-pr.cgi?pr=100516 ___ 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/108651: [hang] option PREEMPTION causes machine hangs on TYAN 2462
Synopsis: [hang] option PREEMPTION causes machine hangs on TYAN 2462 State-Changed-From-To: open->feedback State-Changed-By: jh State-Changed-When: Fri Jan 14 13:43:43 UTC 2011 State-Changed-Why: Can you still reproduce this on a supported release? http://www.freebsd.org/cgi/query-pr.cgi?pr=108651 ___ 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/114111: [nfs] System crashes while writing on NFS-mounted share
Synopsis: [nfs] System crashes while writing on NFS-mounted share State-Changed-From-To: open->feedback State-Changed-By: jh State-Changed-When: Fri Jan 14 13:44:57 UTC 2011 State-Changed-Why: Can you still reproduce this on a supported release? http://www.freebsd.org/cgi/query-pr.cgi?pr=114111 ___ 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/35377: process gets unkillable (-9) in "ttywai" state
Synopsis: process gets unkillable (-9) in "ttywai" state State-Changed-From-To: open->feedback State-Changed-By: jh State-Changed-When: Fri Jan 14 13:45:49 UTC 2011 State-Changed-Why: Can you still reproduce this on a supported release? http://www.freebsd.org/cgi/query-pr.cgi?pr=35377 ___ 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/109809: [shutdown] CPU hits 100% when issuing the halt command (in a VM and also when running on native hardware)
Synopsis: [shutdown] CPU hits 100% when issuing the halt command (in a VM and also when running on native hardware) State-Changed-From-To: open->feedback State-Changed-By: jh State-Changed-When: Fri Jan 14 13:49:17 UTC 2011 State-Changed-Why: Can you still reproduce this on a supported release? http://www.freebsd.org/cgi/query-pr.cgi?pr=109809 ___ 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/119259: [panic] kernel panic on asus c90s laptop after first (?) power on
Synopsis: [panic] kernel panic on asus c90s laptop after first (?) power on State-Changed-From-To: open->feedback State-Changed-By: jh State-Changed-When: Fri Jan 14 13:51:07 UTC 2011 State-Changed-Why: Can you still reproduce this on a supported release? http://www.freebsd.org/cgi/query-pr.cgi?pr=119259 ___ 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/52445: [mfs] panic when mounting floppy on MFS filesystem
Synopsis: [mfs] panic when mounting floppy on MFS filesystem State-Changed-From-To: feedback->closed State-Changed-By: jh State-Changed-When: Fri Jan 14 13:53:45 UTC 2011 State-Changed-Why: Feedback timeout. http://www.freebsd.org/cgi/query-pr.cgi?pr=52445 ___ 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/101734: [ata] -CURRENT cannot see SATA drive on ASUS A8N-SLI (nForce 4)
Synopsis: [ata] -CURRENT cannot see SATA drive on ASUS A8N-SLI (nForce 4) State-Changed-From-To: feedback->closed State-Changed-By: jh State-Changed-When: Fri Jan 14 13:54:36 UTC 2011 State-Changed-Why: Feedback timeout. http://www.freebsd.org/cgi/query-pr.cgi?pr=101734 ___ 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/102784: [keyboard] system crashes when using hardware function keys
Synopsis: [keyboard] system crashes when using hardware function keys State-Changed-From-To: feedback->closed State-Changed-By: jh State-Changed-When: Fri Jan 14 13:55:05 UTC 2011 State-Changed-Why: Feedback timeout. http://www.freebsd.org/cgi/query-pr.cgi?pr=102784 ___ 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/107342: [dri] Radeon dri breaks system
Synopsis: [dri] Radeon dri breaks system State-Changed-From-To: feedback->closed State-Changed-By: jh State-Changed-When: Fri Jan 14 13:55:35 UTC 2011 State-Changed-Why: Feedback timeout. http://www.freebsd.org/cgi/query-pr.cgi?pr=107342 ___ 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/100516: [atapicam] atapicam with ITE IT8212F crashes the system
Synopsis: [atapicam] atapicam with ITE IT8212F crashes the system State-Changed-From-To: feedback->closed State-Changed-By: jh State-Changed-When: Fri Jan 14 14:12:04 UTC 2011 State-Changed-Why: Submitter can't reproduce anymore. http://www.freebsd.org/cgi/query-pr.cgi?pr=100516 ___ 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/119259: [panic] kernel panic on asus c90s laptop after first (?) power on
Synopsis: [panic] kernel panic on asus c90s laptop after first (?) power on State-Changed-From-To: feedback->closed State-Changed-By: jh State-Changed-When: Fri Jan 14 14:12:47 UTC 2011 State-Changed-Why: Submitter can't reproduce anymore. http://www.freebsd.org/cgi/query-pr.cgi?pr=119259 ___ 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/100516: [atapicam] atapicam with ITE IT8212F crashes the system
> Subject: Re: kern/100516: [atapicam] atapicam with ITE IT8212F crashes the > system > Can you still reproduce this on a supported release? Hello That motherboard doesn't work anymore, so i can't test it. Thank you. ___ 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/153993: [patch] have libpkg report which package is casuing pkgdep warnings
>Number: 153993
>Category: bin
>Synopsis: [patch] have libpkg report which package is casuing pkgdep
>warnings
>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 Jan 14 18:50:10 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Eitan Adler
>Release:
>Organization:
>Environment:
>Description:
change the line emitted from the pkg_* tools from
pkg_version: corrupted record (pkgdep line without argument), ignoring
to something like
pkg_version: corrupted record: pkgdep line without argument (in xterm-267),
ignoring
>How-To-Repeat:
>Fix:
Index: plist.c
===
--- plist.c (revision 216884)
+++ plist.c (working copy)
@@ -286,7 +286,8 @@
if (*cp == '\0') {
cp = NULL;
if (cmd == PLIST_PKGDEP) {
- warnx("corrupted record (pkgdep line without argument),
ignoring");
+ warnx("corrupted record: pkgdep line without argument (in %s),
ignoring",
+ (pkg->name == NULL) ? "???" : pkg->name);
cmd = FAIL;
}
goto bottom;
>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"
misc/153995: [patch] update ROADMAP.txt
>Number: 153995 >Category: misc >Synopsis: [patch] update ROADMAP.txt >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 Jan 14 19:30:11 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Eitan Adler >Release: >Organization: >Environment: >Description: Just some housekeeping - update ROADMAP.txt to include the latest changes. >How-To-Repeat: >Fix: Index: ROADMAP.txt === --- ROADMAP.txt (revision 217412) +++ ROADMAP.txt (working copy) @@ -47,6 +47,7 @@ stable/5/ stable/6/ stable/7/ + stable/8/ Releases: release/2.0/ (branched from head/) @@ -96,6 +97,8 @@ release/6.2.0/ release/6.3.0/ release/7.0.0/ + release/8.0.0/ + release/8.1.0/ Release Engineering / Errata branches: releng/ALPHA_2_0 (branched from head/) @@ -121,6 +124,9 @@ releng/6.2 (branched from stable/6/) releng/6.3 (branched from stable/6/) releng/7.0 (branched from stable/7/) + releng/8.0 (branched from stable/8/) + releng/8.1 (branched from stable/8/) + releng/8.2 (branched from stable/8/) Vendor layout: vendor/$vendor - roots for a given vendor import >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: misc/153995: [patch] update ROADMAP.txt
The following reply was made to PR misc/153995; it has been noted by GNATS. From: Eitan Adler To: bug-follo...@freebsd.org, li...@eitanadler.com Cc: Subject: Re: misc/153995: [patch] update ROADMAP.txt Date: Fri, 14 Jan 2011 14:37:14 -0500 I forgot about the 7.x set. IMHO I don't really think we need to keep a listing of all the branches in this file and perhaps they should just be removed (and remove the general information) Index: ROADMAP.txt === --- ROADMAP.txt(revision 217412) +++ ROADMAP.txt(working copy) @@ -47,6 +47,7 @@ stable/5/ stable/6/ stable/7/ + stable/8/ Releases: release/2.0/ (branched from head/) @@ -96,6 +97,11 @@ release/6.2.0/ release/6.3.0/ release/7.0.0/ + release/7.1.0/ + release/7.2.0/ + release/7.3.0/ + release/8.0.0/ + release/8.1.0/ Release Engineering / Errata branches: releng/ALPHA_2_0 (branched from head/) @@ -121,6 +127,13 @@ releng/6.2 (branched from stable/6/) releng/6.3 (branched from stable/6/) releng/7.0 (branched from stable/7/) + releng/7.1 (branched from stable/7/) + releng/7.2 (branched from stable/7/) + releng/7.3 (branched from stable/7/) + releng/7.4 (branched from stable/7/) + releng/8.0 (branched from stable/8/) + releng/8.1 (branched from stable/8/) + releng/8.2 (branched from stable/8/) Vendor layout: vendor/$vendor - roots for a given vendor import -- Eitan Adler ___ 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/153995: [patch] update ROADMAP.txt
The following reply was made to PR misc/153995; it has been noted by GNATS. From: Eitan Adler To: bug-follo...@freebsd.org Cc: Subject: Re: misc/153995: [patch] update ROADMAP.txt Date: Fri, 14 Jan 2011 14:39:41 -0500 Sorry, and *leave* the general information. On Fri, Jan 14, 2011 at 2:37 PM, Eitan Adler wrote: > I forgot about the 7.x set. > IMHO I don't really think we need to keep a listing of all the > branches in this file and perhaps they should just be removed (and > remove the general information) > > Index: ROADMAP.txt > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- ROADMAP.txt (revision 217412) > +++ ROADMAP.txt (working copy) > @@ -47,6 +47,7 @@ > =C2=A0 stable/5/ > =C2=A0 stable/6/ > =C2=A0 stable/7/ > + =C2=A0stable/8/ > > =C2=A0Releases: > =C2=A0 release/2.0/ =C2=A0 =C2=A0 (branched from head/) > @@ -96,6 +97,11 @@ > =C2=A0 release/6.2.0/ > =C2=A0 release/6.3.0/ > =C2=A0 release/7.0.0/ > + =C2=A0release/7.1.0/ > + =C2=A0release/7.2.0/ > + =C2=A0release/7.3.0/ > + =C2=A0release/8.0.0/ > + =C2=A0release/8.1.0/ > > =C2=A0Release Engineering / Errata branches: > =C2=A0 releng/ALPHA_2_0 (branched from head/) > @@ -121,6 +127,13 @@ > =C2=A0 releng/6.2 =C2=A0 =C2=A0 =C2=A0 (branched from stable/6/) > =C2=A0 releng/6.3 =C2=A0 =C2=A0 =C2=A0 (branched from stable/6/) > =C2=A0 releng/7.0 =C2=A0 =C2=A0 =C2=A0 (branched from stable/7/) > + =C2=A0releng/7.1 =C2=A0 =C2=A0 =C2=A0 (branched from stable/7/) > + =C2=A0releng/7.2 =C2=A0 =C2=A0 =C2=A0 (branched from stable/7/) > + =C2=A0releng/7.3 =C2=A0 =C2=A0 =C2=A0 (branched from stable/7/) > + =C2=A0releng/7.4 =C2=A0 =C2=A0 =C2=A0 (branched from stable/7/) > + =C2=A0releng/8.0 =C2=A0 =C2=A0 =C2=A0 (branched from stable/8/) > + =C2=A0releng/8.1 =C2=A0 =C2=A0 =C2=A0 (branched from stable/8/) > + =C2=A0releng/8.2 =C2=A0 =C2=A0 =C2=A0 (branched from stable/8/) > > =C2=A0Vendor layout: > =C2=A0 vendor/$vendor - roots for a given vendor import > > > -- > Eitan Adler > --=20 Eitan Adler ___ 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/153996: zfs root mount error while kernel is not located in /boot/kernel
>Number: 153996 >Category: kern >Synopsis: zfs root mount error while kernel is not located in >/boot/kernel >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jan 14 21:00:20 UTC 2011 >Closed-Date: >Last-Modified: >Originator: alexander naumochkin >Release:8.2-PRERELEASE (SNAP-20110110) i386 >Organization: >Environment: FreeBSD zombie.prio.ru 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: Tue Jan 11 01:17:21 MSK 2011 r...@zombie.prio.ru:/usr/obj/usr/src/sys/GCAM i386 >Description: If the kernel is not located in default directory (/boot/kernel), it fails to mount zfs root during startup regardless of using vfs.root.mountfrom="zfs:zroot" or /etc/fstab record. I use FreeBSD on GPT ZFS Root. [ash@zombie ~]$ gpart show => 34 156301421 ada0 GPT (75G) 34128 1 freebsd-boot (64K) 1623145728 2 freebsd-swap (1.5G) 3145890 153155565 3 freebsd-zfs (73G) => 34 156301421 ada1 GPT (75G) 34128 1 freebsd-boot (64K) 1623145728 2 freebsd-swap (1.5G) 3145890 153155565 3 freebsd-zfs (73G) [ash@zombie ~]$ gpart show -l => 34 156301421 ada0 GPT (75G) 34128 1 (null) (64K) 1623145728 2 swap0 (1.5G) 3145890 153155565 3 disk0 (73G) => 34 156301421 ada1 GPT (75G) 34128 1 (null) (64K) 1623145728 2 swap1 (1.5G) 3145890 153155565 3 disk1 (73G) [ash@zombie ~]$ zpool status pool: zroot state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 >How-To-Repeat: #cd /usr/src #make installkernel KODIR=/boot/GCAM #shutdown -r now Select 6 (loader prompt) from boot menu and enter: OK unload kernel OK load /boot/GCAM/kernel OK set module_path=/boot/GCAM OK load opensolaris OK load zfs OK boot kernel starts, detects hardware, but at "Trying to mount root from zfs:zroot" stops with "MOUNT ROOT ERROR:" Entering zfs:zroot at mountroot> prompt not helps. >Fix: Boot from LiveCD, mount zroot, rename /boot/GCAM to /boot/kernel, reboot :) >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/154006: tcp "window probe" bug on 64bit
>Number: 154006 >Category: kern >Synopsis: tcp "window probe" bug on 64bit >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 Jan 15 01:40:07 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Stefan `Sec` Zehl >Release:FreeBSD 8.1-STABLE amd64 >Organization: >Environment: System: FreeBSD ice 8.1-STABLE FreeBSD 8.1-STABLE #15: Mon Oct 25 12:20:38 CEST 2010 root@ice:/usr/obj/usr/src/sys/ICE amd64 As far as I can tell, the offending code is in all FreeBSD versions, not just 8-STABLE >Description: On amd64 the PERSIST timer does not get started (and consecquently executed) for tcp connections stalled on a 0-size receive window. This means that no single-byte probe packet is sent, so connections might hang indefinitely. This is due to a missing (long) conversion in tcp_output.c around line 562 where "adv" is calculated. After this patch, amd64 behaves the same way as i386 again. >How-To-Repeat: connect to a certain broken host which advertises window size 0 in the SYN|ACK handshake packet, but increases window size after the 3-way handshake >Fix: --- src/sys/netinet/tcp_output.c2010-09-20 17:49:17.0 +0200 +++ src/sys/netinet/tcp_output.c2011-01-14 19:30:46.0 +0100 @@ -571,7 +559,7 @@ * TCP_MAXWIN << tp->rcv_scale. */ long adv = min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) - - (tp->rcv_adv - tp->rcv_nxt); + (long) (tp->rcv_adv - tp->rcv_nxt); if (adv >= (long) (2 * tp->t_maxseg)) goto send; >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"
misc/154007: Atheros ar9287 card does not get recognized.
>Number: 154007 >Category: misc >Synopsis: Atheros ar9287 card does not get recognized. >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: Sat Jan 15 02:00:21 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Jakub Guzik >Release:8.2-RC1 >Organization: >Environment: >Description: Atheros ar9287 card does not get recognized in freebsd 8.2-RC1. >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/154006: tcp "window probe" bug on 64bit
On Sat, 15 Jan 2011, Stefan `Sec` Zehl wrote:
Description:
On amd64 the PERSIST timer does not get started (and consecquently executed)
for tcp connections stalled on a 0-size receive window. This means that no
single-byte probe packet is sent, so connections might hang indefinitely.
This is due to a missing (long) conversion in tcp_output.c around line 562
where "adv" is calculated.
After this patch, amd64 behaves the same way as i386 again.
Fix:
--- src/sys/netinet/tcp_output.c2010-09-20 17:49:17.0 +0200
+++ src/sys/netinet/tcp_output.c2011-01-14 19:30:46.0 +0100
@@ -571,7 +559,7 @@
* TCP_MAXWIN << tp->rcv_scale.
*/
long adv = min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) -
- (tp->rcv_adv - tp->rcv_nxt);
+ (long) (tp->rcv_adv - tp->rcv_nxt);
if (adv >= (long) (2 * tp->t_maxseg))
goto send;
Many other type errors are visible in this patch:
- min() takes 'unsigned int' args, but is passed 'signed long' args:
- recwin has type long. This is smaller )same size but smaller max)
than 'unsigned int' on 32-bit arches, and larger on 64-bit arches
- TCP_MAXWIN has type int (except on 16-bit arches, which are not
supported and are no longer permitted by POSIX). Then we explicitly
make its type incompatible with min() by casting to long. The 16-bit
arches don't matter, except they are responsible for many of the type
errors here. recvwin is long and TCP_WIN is cast to long since plain
int was not long enough on 16-bit arches.
Hopefully both of min()'s parameters are non-negative and <= UINT_MAX.
Then nothing bad happens when min() converts them to u_int. The result
of min() has type u_int.
- rcv_adv has type tcp_seq. Seems correct
- tcp_seq has type u_int32_t. Seems correct, except for its old spelling.
The spelling is not so old that it is u_long (to support the 16-bit arches),
but it hasn't caught up with C99 yet.
- rcv_next has type u_int32_t. Seems logically incorrect -- should be tcp_seq.
- (tp->rcv_adv - tp->rcv_nxt) has type [ the default promotion of { tcp_seq,
u_int32_t } ]. This is u_int on all supported arches. Apparently, the
value of this should always be positive, since the cast doesn't change
this on 64-bit arches. However, the cast might break this on 32-bit
arches (it breaks the value whenever it exceeds 0x8000, if that can
happen, since longs are smaller than u_int's on 32-bit arches.
- the type of the expression for the rvalue is [ the default promotion of
{ u_int, u_int } ] in the old version, and the same with the last u_int
replaced by long in the patched version. It is most natural to subtract
u_int's here, like the old version did -- everything in sight is (except
for all the type errors) a sequence number or a difference of sequence
numbers; the differences are always taken mod 2**32 and are non-negative,
but must be careful if the difference should really be negative. The
SEQ_LT() family of macros can be used to determine if differences should
be negative (this family is further towards losing 16-bitness -- it casts
to int instead of to long). Unfortunately there is no SEQ_DIFF() macro
to simplify easy cases of taking differences. I think there are scattered
casts for this as here.
So casting to long is not good. It gives another type error to analyse,
and works accidentally.
Futher analysis: without the patch:
long adv = x - y;
where x has type u_int and y had type u_int. The difference always has
type u_int; if x is sequentially less than y, then the difference should
be negative, but its type forces it to be positive. We should use
SEQ_FOO() if this is possible, or we can use delicate conversions if we
do only 2 pages of analysis per line to justify the delicacies (not too
bad if there is a macro for this).
- On 32-bit arches, long is smaller than u_int, so the assignment overflows
if the difference should have been negative. The behaviour is undefined,
but on normal 2's complement arches, it is benign and fixes up the sign
error.
- On 64-bit arches, long is larger than u_int, so the difference remains
nonnegative when it should have been negative, and is normally huge
(something like 0U - 1U = 0x). The huge value is near UINT_MAX.
LONG_MAX is much larger, so the assignment doesn't overflow and the
value remains near UINT_MAX.
With the patch:
long adv = x - (long)y;
where x has type u_int and (long)y had type long:
- On 32-bit arches, long is smaller than u_int, so (long)y may overflow;
overflow gives undefined behaviour which happens to be benign. Then
the binary promotions apply. Although I have been describing long as
being smaller than u_int on 32-bit arches, in the C type system it is
logically larger, so the binary promotions promote x t
Re: kern/154006: tcp "window probe" bug on 64bit
The following reply was made to PR kern/154006; it has been noted by GNATS.
From: Bruce Evans
To: Stefan `Sec` Zehl
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org
Subject: Re: kern/154006: tcp "window probe" bug on 64bit
Date: Sat, 15 Jan 2011 16:31:10 +1100 (EST)
On Sat, 15 Jan 2011, Stefan `Sec` Zehl wrote:
>> Description:
>
> On amd64 the PERSIST timer does not get started (and consecquently executed)
> for tcp connections stalled on a 0-size receive window. This means that no
> single-byte probe packet is sent, so connections might hang indefinitely.
>
> This is due to a missing (long) conversion in tcp_output.c around line 562
> where "adv" is calculated.
>
> After this patch, amd64 behaves the same way as i386 again.
>> Fix:
>
> --- src/sys/netinet/tcp_output.c 2010-09-20 17:49:17.0 +0200
> +++ src/sys/netinet/tcp_output.c 2011-01-14 19:30:46.0 +0100
> @@ -571,7 +559,7 @@
> * TCP_MAXWIN << tp->rcv_scale.
> */
> long adv = min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) -
> -(tp->rcv_adv - tp->rcv_nxt);
> +(long) (tp->rcv_adv - tp->rcv_nxt);
>
> if (adv >= (long) (2 * tp->t_maxseg))
> goto send;
>
Many other type errors are visible in this patch:
- min() takes 'unsigned int' args, but is passed 'signed long' args:
- recwin has type long. This is smaller )same size but smaller max)
than 'unsigned int' on 32-bit arches, and larger on 64-bit arches
- TCP_MAXWIN has type int (except on 16-bit arches, which are not
supported and are no longer permitted by POSIX). Then we explicitly
make its type incompatible with min() by casting to long. The 16-bit
arches don't matter, except they are responsible for many of the type
errors here. recvwin is long and TCP_WIN is cast to long since plain
int was not long enough on 16-bit arches.
Hopefully both of min()'s parameters are non-negative and <= UINT_MAX.
Then nothing bad happens when min() converts them to u_int. The result
of min() has type u_int.
- rcv_adv has type tcp_seq. Seems correct
- tcp_seq has type u_int32_t. Seems correct, except for its old spelling.
The spelling is not so old that it is u_long (to support the 16-bit arches),
but it hasn't caught up with C99 yet.
- rcv_next has type u_int32_t. Seems logically incorrect -- should be tcp_seq.
- (tp->rcv_adv - tp->rcv_nxt) has type [ the default promotion of { tcp_seq,
u_int32_t } ]. This is u_int on all supported arches. Apparently, the
value of this should always be positive, since the cast doesn't change
this on 64-bit arches. However, the cast might break this on 32-bit
arches (it breaks the value whenever it exceeds 0x8000, if that can
happen, since longs are smaller than u_int's on 32-bit arches.
- the type of the expression for the rvalue is [ the default promotion of
{ u_int, u_int } ] in the old version, and the same with the last u_int
replaced by long in the patched version. It is most natural to subtract
u_int's here, like the old version did -- everything in sight is (except
for all the type errors) a sequence number or a difference of sequence
numbers; the differences are always taken mod 2**32 and are non-negative,
but must be careful if the difference should really be negative. The
SEQ_LT() family of macros can be used to determine if differences should
be negative (this family is further towards losing 16-bitness -- it casts
to int instead of to long). Unfortunately there is no SEQ_DIFF() macro
to simplify easy cases of taking differences. I think there are scattered
casts for this as here.
So casting to long is not good. It gives another type error to analyse,
and works accidentally.
Futher analysis: without the patch:
long adv = x - y;
where x has type u_int and y had type u_int. The difference always has
type u_int; if x is sequentially less than y, then the difference should
be negative, but its type forces it to be positive. We should use
SEQ_FOO() if this is possible, or we can use delicate conversions if we
do only 2 pages of analysis per line to justify the delicacies (not too
bad if there is a macro for this).
- On 32-bit arches, long is smaller than u_int, so the assignment overflows
if the difference should have been negative. The behaviour is undefined,
but on normal 2's complement arches, it is benign and fixes up the sign
error.
- On 64-bit arches, long is larger than u_int, so the difference remains
nonnegative when it should have been negative, and is normally huge
(something like 0U - 1U = 0x). The huge value is near UINT_MAX.
LONG_MAX is much larger, so the assignment doesn't overflow and the
value remains near UINT_MAX.
With the patch:
Re: kern/154006: tcp "window probe" bug on 64bit
On Sat, 15 Jan 2011, Bruce Evans wrote: ... Later code in tcp_output uses bogus casts to long and larger code instead: % if (recwin < (long)(tp->rcv_adv - tp->rcv_nxt)) % recwin = (long)(tp->rcv_adv - tp->rcv_nxt); % if (recwin > (long)TCP_MAXWIN << tp->rcv_scale) % recwin = (long)TCP_MAXWIN << tp->rcv_scale; % ... % if (recwin > 0 && SEQ_GT(tp->rcv_nxt + recwin, tp->rcv_adv)) % tp->rcv_adv = tp->rcv_nxt + recwin; Note that the first statement avoids using the technically incorrect SEQ_FOO() although its internals are better (cast to int instead of long). It uses cases essentially like yours. Then further analysis ^ a cast is simpler because everything is converted to long. The second starement is similar to the first half of the broken expression. Large code using if's and else's and tests (x >= y) before subtracting y from x is much easier to get right than 1 complicated 1-statement expression like the broken one. It takes these (x >= y) tests to make code with mixed types obviously correct. But I prefer small fast code with ints for everything, since type analyis is too hard. But the casts to long are not good. Here they have no effect except to break the warning about the bad type of `recwin'. recwin has type long, so assignment to it does the same conversion as the cast, possibly with a warning about the implicit conversion if it might overflow (can overflow only on 32-bit arches). The code depends on rcv_adv being sequentially >= rcv_next with or without the cast. Otherwise, the difference is huge unsigned int, and the cast only changes this (by benign overflow) on 32-bit arches. This can be fixed by casting to int instead of long (now the cast may have an effect, and breaking the warning may be intential), or my proposed SEQ_DIFF() macros work well here: int recwin, sd; ... sd = SEQ_NONNEG_NONLARGE_DIFF(tp->rcv_adv, tp->rcv_nxt); /* * SEQ_DIFF() supports negative differences; * SEQ_NONNEG_NONGLARGE_DIFF() KASSERT()s that they don't happen and * are not too large. This name is too long. */ if (recwin < sd) recwin = sd; ... Bruce ___ 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/154006: tcp "window probe" bug on 64bit
The following reply was made to PR kern/154006; it has been noted by GNATS. From: Bruce Evans To: Bruce Evans Cc: Stefan `Sec` Zehl , freebsd-bugs@freebsd.org, freebsd-gnats-sub...@freebsd.org Subject: Re: kern/154006: tcp "window probe" bug on 64bit Date: Sat, 15 Jan 2011 17:05:02 +1100 (EST) On Sat, 15 Jan 2011, Bruce Evans wrote: > ... > Later code in tcp_output uses bogus casts to long and larger code instead: > > %if (recwin < (long)(tp->rcv_adv - tp->rcv_nxt)) > %recwin = (long)(tp->rcv_adv - tp->rcv_nxt); > %if (recwin > (long)TCP_MAXWIN << tp->rcv_scale) > %recwin = (long)TCP_MAXWIN << tp->rcv_scale; > %... > %if (recwin > 0 && SEQ_GT(tp->rcv_nxt + recwin, tp->rcv_adv)) > %tp->rcv_adv = tp->rcv_nxt + recwin; > > Note that the first statement avoids using the technically incorrect > SEQ_FOO() although its internals are better (cast to int instead of > long). It uses cases essentially like yours. Then further analysis ^ a cast > is simpler because everything is converted to long. The second starement > is similar to the first half of the broken expression. Large code using > if's and else's and tests (x >= y) before subtracting y from x is much > easier to get right than 1 complicated 1-statement expression like the > broken one. It takes these (x >= y) tests to make code with mixed types > obviously correct. But I prefer small fast code with ints for everything, > since type analyis is too hard. But the casts to long are not good. Here they have no effect except to break the warning about the bad type of `recwin'. recwin has type long, so assignment to it does the same conversion as the cast, possibly with a warning about the implicit conversion if it might overflow (can overflow only on 32-bit arches). The code depends on rcv_adv being sequentially >= rcv_next with or without the cast. Otherwise, the difference is huge unsigned int, and the cast only changes this (by benign overflow) on 32-bit arches. This can be fixed by casting to int instead of long (now the cast may have an effect, and breaking the warning may be intential), or my proposed SEQ_DIFF() macros work well here: int recwin, sd; ... sd = SEQ_NONNEG_NONLARGE_DIFF(tp->rcv_adv, tp->rcv_nxt); /* * SEQ_DIFF() supports negative differences; * SEQ_NONNEG_NONGLARGE_DIFF() KASSERT()s that they don't happen and * are not too large. This name is too long. */ if (recwin < sd) recwin = sd; ... Bruce ___ 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"
