Re: kern/163089: Duplicate free in the error return for mld_v2_encap_report in mld6.c
Synopsis: Duplicate free in the error return for mld_v2_encap_report in mld6.c State-Changed-From-To: open->patched State-Changed-By: glebius State-Changed-When: Wed Dec 7 13:37:58 UTC 2011 State-Changed-Why: Committed to head, thanks! Responsible-Changed-From-To: freebsd-bugs->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Wed Dec 7 13:37:58 UTC 2011 Responsible-Changed-Why: Committed to head, thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=163089 ___ 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/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS.
From: Jaakko Heinonen
To: Poul-Henning Kamp
Cc: Petr Salinger , bug-follo...@freebsd.org,
d...@freebsd.org, m...@freebsd.org
Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs
and procfs.
Date: Wed, 7 Dec 2011 18:08:34 +0200
Hi,
On 2011-12-06, Jaakko Heinonen wrote:
> On 2011-12-06, Poul-Henning Kamp wrote:
> > >Shouldn't sbuf_finish() then check s->s_error before appending the
> > >trailing '\0' and setting the SBUF_FINISHED flag? The problem in
> > >question wasn't caught earlier because sbuf_finish() happily finishes
> > >the buffer even if it has an error.
> >
> > I belive the code is written so that there is always reserved space
> > for the final '\0'
> >
> > sbuf_finish() should finish _any_ sbuf, and return zero only if
> > the finished buffer is fully OK.
>
> Anyway I find it inconsistent that you can successfully call
> sbuf_finish() and sbuf_data() but not for example sbuf_len() on an
> errored buffer.
After looking at some code using sbufs I think that the sbuf(9) API
change done in r222004 is problematic. Lots of code doesn't check the
return value of sbuf_finish() but they expect sbuf_len() to return the
actual length regardless of the error status after calling
sbuf_finish(). Since r222004 sbuf_len() may return -1 after
sbuf_finish().
In user space also SBUF_AUTOEXTEND buffers are affected because
malloc(3) can fail and cause the error status to be set.
Could we just remove the error check from sbuf_len()? (patch below) I
have Cc'd more people.
sbuf(9) manual page wrongly claims that sbuf_data() will return NULL if
the buffer has overflowed.
%%%
Index: sys/kern/subr_sbuf.c
===
--- sys/kern/subr_sbuf.c (revision 228153)
+++ sys/kern/subr_sbuf.c (working copy)
@@ -725,8 +725,6 @@ sbuf_len(struct sbuf *s)
KASSERT(s->s_drain_func == NULL,
("%s makes no sense on sbuf %p with drain", __func__, s));
- if (s->s_error != 0)
- return (-1);
return (s->s_len);
}
Index: share/man/man9/sbuf.9
===
--- share/man/man9/sbuf.9 (revision 228153)
+++ share/man/man9/sbuf.9 (working copy)
@@ -25,7 +25,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd January 25, 2011
+.Dd December 7, 2011
.Dt SBUF 9
.Os
.Sh NAME
@@ -462,14 +462,6 @@ function returns a non-zero value if the
drain error, and zero otherwise.
.Pp
The
-.Fn sbuf_data
-and
-.Fn sbuf_len
-functions return
-.Dv NULL
-and \-1, respectively, if the buffer overflowed.
-.Pp
-The
.Fn sbuf_copyin
function
returns \-1 if copying string from userland failed, and number of bytes
%%%
--
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: kern/73673: [if_tun] ifconfig tun0 destroy report: ifconfig: SIOCIFDESTROY: Invalid argument
The following reply was made to PR kern/73673; it has been noted by GNATS. From: David Woodhouse To: bug-follo...@freebsd.org Cc: Subject: Re: kern/73673: [if_tun] ifconfig tun0 destroy report: ifconfig: SIOCIFDESTROY: Invalid argument Date: Thu, 08 Dec 2011 02:11:59 + --=-ylIIl0FMV/Ccnsos+yT1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In vpnc-script (as used by vpnc and openconnect VPN clients), we have 'ifconfig $TUNDEV destroy' for FreeBSD and NetBSD. My testing on FreeBSD shows that this seems to hang, *not* give the -EINVAL error as described here. It hangs until the VPN program has actually closed its open file handle to the tun device. In practice, since the VPN program spawns vpnc-script to shut down the routing &c *before* closing the tun device, this deadlocks. Simply removing the 'ifconfig $TUNDEV destroy' seems to leave a stale device lying around. Running it *later* does appear to work, and cleans up the unwanted device. I note that this bug is fairly old; is 'ifconfig $TUNDEV destroy' now expected to work... and is it expected to hang in this situation? FreeBSD freebsd.infradead.org 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 --=20 dwmw2 --=-ylIIl0FMV/Ccnsos+yT1 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITvzCCBi0w ggQVoAMCAQICAwCtOTANBgkqhkiG9w0BAQUFADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwG A1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290 MB4XDTEwMDYxMjEwMDMwMFoXDTEyMDYxMTEwMDMwMFowgegxGDAWBgNVBAMTD0RhdmlkIFdvb2Ro b3VzZTEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9yZzEfMB0GCSqGSIb3DQEJARYQ ZGF2aWRAd29vZGhvdS5zZTEoMCYGCSqGSIb3DQEJARYZZGF2aWQud29vZGhvdXNlQGludGVsLmNv bTEkMCIGCSqGSIb3DQEJARYVZHdtdzJAbGludXguaW50ZWwuY29tMTcwNQYJKoZIhvcNAQkBFigx MDg3MmEwN2Y2ZDdlMWUwN2Y1NWZmMTcyYTAzYjMwMGVlYWFkMjAzMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA29OPhNvMxBMW83psWdVhZDtmJvgN+tBEp1r6MZamONsR0k81a6fDFwJz M0fEzEbV/bDG102QyX/xXC/0IpKV4acnqESC+sTHUmRwxfRKGNmR6t2iwEs2Y5kQDF31JxbCt49w AlhLMAa+e1MBZ7vO0uDmRuJpS7+ZdHboq7cdk6dyoeumGv5sl6U/SPK9rL4KzULtqQaw6Wucd6MJ irIggEHfCNqeT5a+TyuH4zKCwv9nblIGXq9wt+yqu5t/RicGaKPnXSqo/WpJAGggaO8g92mnYlVl Wu/b9bYVISwQ8LI0sEtjN1WnP5AQO2f59bdPAVk4Rn25HceOO4NvlG47LwIDAQABo4IBcTCCAW0w DAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRl IGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYI KwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYI KwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMIGOBgNVHREE gYYwgYOBE2R3bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2WBGWRhdmlkLndvb2Ro b3VzZUBpbnRlbC5jb22BFWR3bXcyQGxpbnV4LmludGVsLmNvbYEoMTA4NzJhMDdmNmQ3ZTFlMDdm NTVmZjE3MmEwM2IzMDBlZWFhZDIwMzANBgkqhkiG9w0BAQUFAAOCAgEAXm+SUO1/TSeGJK0D9pAm E9LTFkdlgbaD6HXGbS0TNUDyfLFkacc2F1JLoWcoFwcL6Rup5o/Rt4QYDBPWgF9EXFvqsc9SLrSe X6VwRj7vI40x19ThE2A1Y8DzBJ9+2MzIR6hd5n9axATCOIRhmZVjX1cRkwshEGvAn8mTYGhWttkx WhBcaAuCd9OOQqUwfxTUXiSfVumPUNrrbuvaH6MjrNjDrXdvicL26Y+AzFSJn3o8DShjjMhkUx9l qV46BpjSGIuvkHhcLkGJ3Y1YmtOX1hwT+Z+d/10WJh8ZG2FqIlJtPtqvHK5ol/KvdzMwmMBd4qFj YAO32vf7zde+jdTHNp2Mb15bJHhNdGOsZicpGue42fg3deZQFe1E2KBl9VO09fjncjt9YdhCUtxO buDnoOixY6YSJgSmGJB2Xs+TE5gps4UiiOYen+NeJkuwg5x9vmyraU061Uc0csfc/E5IoxhTX/Pc H+zXiER8aSjA/9MXQfrJM2xkY6UNKlDbCYSLKnH/O02eu7Hma6lB4wtcY8ECu7LJuFY2448Quolv SQfQLRvKauGFGUAhbPClOxObuv/fNzA+lfg8DX2y5jXDutnpvBGgsplKxoah01SZfR9zNqxodPx2 srKhujBNB+WiAZntMf0xp4e0JPMlTFxm3tbY9wuBSyTJyueO9hUkbN4wggYtMIIEFaADAgECAgMA rTkwDQYJKoZIhvcNAQEFBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0xMDA2MTIx MDAzMDBaFw0xMjA2MTExMDAzMDBaMIHoMRgwFgYDVQQDEw9EYXZpZCBXb29kaG91c2UxIjAgBgkq hkiG9w0BCQEWE2R3bXcyQGluZnJhZGVhZC5vcmcxHzAdBgkqhkiG9w0BCQEWEGRhdmlkQHdvb2Ro b3Uuc2UxKDAmBgkqhkiG9w0BCQEWGWRhdmlkLndvb2Rob3VzZUBpbnRlbC5jb20xJDAiBgkqhkiG 9w0BCQEWFWR3bXcyQGxpbnV4LmludGVsLmNvbTE3MDUGCSqGSIb3DQEJARYoMTA4NzJhMDdmNmQ3 ZTFlMDdmNTVmZjE3MmEwM2IzMDBlZWFhZDIwMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBANvTj4TbzMQTFvN6bFnVYWQ7Zib4DfrQRKda+jGWpjjbEdJPNWunwxcCczNHxMxG1f2wxtdN kMl/8Vwv9CKSleGnJ6hEgvrEx1JkcMX0ShjZkerdosBLNmOZEAxd9ScWwrePcAJYSzAGvntTAWe7 ztLg5kbiaUu/mXR26Ku3HZOncqHrphr+bJelP0jyvay+Cs1C7akGsOlrnHejCYqyIIBB3wjank+W vk8rh+MygsL/Z25SBl6vcLfsqrubf0YnBmij510qqP1qSQBoIGjvIPdpp2JVZVrv2/W2FSEsEPCy NLBLYzdVpz+QEDtn+fW3TwFZOEZ9uR3HjjuDb5RuOy8CAwEAAaOCAXEwggFtMAwGA1UdEwEB/wQC MAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBo ZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggr BgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYw JDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2Fj
Re: kern/105604: [bktr] [patch] add support for Pixelview PlayTV Pro 2 on bktr
Synopsis: [bktr] [patch] add support for Pixelview PlayTV Pro 2 on bktr State-Changed-From-To: open->feedback State-Changed-By: eadler State-Changed-When: Thu Dec 8 02:22:47 UTC 2011 State-Changed-Why: This patch fails to compile now. If you can come up with one that works against a recent verison I'll try to make sure it gets committed http://www.freebsd.org/cgi/query-pr.cgi?pr=105604 ___ 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/163117: sporadic boot-time panics on 9.0-RC2 and 9.0-RC3 w/ certain hardware
>Number: 163117 >Category: kern >Synopsis: sporadic boot-time panics on 9.0-RC2 and 9.0-RC3 w/ certain >hardware >Confidential: no >Severity: serious >Priority: high >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Dec 08 02:50:11 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Mike Andrews >Release:FreeBSD 9.0-RC3 amd64 >Organization: >Environment: System: FreeBSD brandy.fark.com 9.0-RC3 FreeBSD 9.0-RC3 #32 r228247: Sat Dec 3 18:57:23 EST 2011 mandr...@beer.int.fark.com:/usr/obj/usr/src/sys/FARK64 amd64 Supermicro X8STi-F >Description: *Sometimes* when booting 9.0-RC2 or 9.0-RC3 on *some* of my machines, I'll get one of the following two panics during multiuser startup, usually while running the /usr/local/etc/rc.d scripts. (The instruction pointer is always exactly one of these two, and they look fairly related.) If after two or three reboots it manages to not panic, the system will run perfectly stable. Some discussion here: http://www.mail-archive.com/freebsd-stable@freebsd.org/msg118075.html Console logs and kernel configs here: http://www.bit0.com/tmp/panic90rc3fark.tar.gz I've run this kernel on the following boards, all of which have em(4) NICs of varying vintage: Supermicro X8STi-F em0@pci0:1:0:0:class=0x02 card=0x10d315d9 chip=0x10d38086 rev=0x00 hdr=0x00 em1@pci0:2:0:0:class=0x02 card=0x10d315d9 chip=0x10d38086 rev=0x00 hdr=0x00 Supermicro X8SIE-F em0@pci0:3:0:0:class=0x02 card=0x040d15d9 chip=0x10d38086 rev=0x00 hdr=0x00 em1@pci0:4:0:0:class=0x02 card=0x040d15d9 chip=0x10d38086 rev=0x00 hdr=0x00 Supermicro X7SBE em0@pci0:13:0:0: class=0x02 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 em1@pci0:15:0:0: class=0x02 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 Supermicro PDSMi+ and PDSMA+ em0@pci0:13:0:0: class=0x02 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 em1@pci0:14:0:0: class=0x02 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 Intel S3000AHLX em0@pci0:4:0:0:class=0x02 card=0x348d8086 chip=0x108c8086 rev=0x03 hdr=0x00 em1@pci0:5:5:0:class=0x02 card=0x348d8086 chip=0x10768086 rev=0x05 hdr=0x00 Intel S3000AHV em0@pci0:3:0:0:class=0x02 card=0x34898086 chip=0x108c8086 rev=0x03 hdr=0x00 Supermicro X7SPA-HF em0@pci0:2:0:0:class=0x02 card=0x060a15d9 chip=0x10d38086 rev=0x00 hdr=0x00 em1@pci0:3:0:0:class=0x02 card=0x060a15d9 chip=0x10d38086 rev=0x00 hdr=0x00 ...and as far as I can tell, only the X8STi-F has the issue. All the others seem to boot up fine every time. It's just the first that randomly panics (or doesn't) on boot. Supermicro X7SLA-H with re(4) NICs works fine too - First 9.0-RC2 panic (note em0 warning before it): - em0: discard frame w/o packet header Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0x805e4fc5 stack pointer = 0x28:0xff80003299e0 frame pointer = 0x28:0xff8000329a00 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (irq256: em0:rx 0) trap number = 9 panic: general protection fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 trap_fatal() at trap_fatal+0x290 trap() at trap+0x10a calltrap() at calltrap+0x8 --- trap 0x9, rip = 0x805e4fc5, rsp = 0xff80003299e0, rbp = 0xff8000329a00 --- m_freem() at m_freem+0x25 ether_nh_input() at ether_nh_input+0x82 netisr_dispatch_src() at netisr_dispatch_src+0x20b em_rxeof() at em_rxeof+0x1ca em_msix_rx() at em_msix_rx+0x24 intr_event_execute_handlers() at intr_event_execute_handlers+0x104 ithread_loop() at ithread_loop+0xa4 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8000329d00, rbp = 0 --- Uptime: 49s Dumping 679 out of 12263 MB: - Second 9.0-RC2 panic (no em0 discard warning this time): - Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0x8063c0e4 stack pointer = 0x28:0xff8000329a00 frame pointer = 0x28:0xff8000329a40 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (irq256: em0:rx 0) trap number = 9 panic: general protection fault cpuid = 0 KDB: stack backtrace:
Re: kern/163098: commit references a PR
The following reply was made to PR kern/163098; it has been noted by GNATS. From: dfil...@freebsd.org (dfilter service) To: bug-follo...@freebsd.org Cc: Subject: Re: kern/163098: commit references a PR Date: Thu, 8 Dec 2011 03:20:52 + (UTC) Author: eadler (ports committer) Date: Thu Dec 8 03:20:38 2011 New Revision: 228343 URL: http://svn.freebsd.org/changeset/base/228343 Log: - Fix ktrace leakage if error is set PR: kern/163098 Submitted by:Loganaden Velvindron Approved by: sbruno@ MFC after: 1 month Modified: head/sys/kern/kern_ktrace.c Modified: head/sys/kern/kern_ktrace.c == --- head/sys/kern/kern_ktrace.cThu Dec 8 02:40:46 2011 (r228342) +++ head/sys/kern/kern_ktrace.cThu Dec 8 03:20:38 2011 (r228343) @@ -478,7 +478,7 @@ ktrsysret(code, error, retval) ktp = &req->ktr_data.ktr_sysret; ktp->ktr_code = code; ktp->ktr_error = error; - ktp->ktr_retval = retval; /* what about val2 ? */ + ktp->ktr_retval = ((error == 0) ? retval: 0); /* what about val2 ? */ ktr_submitrequest(curthread, req); } ___ 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"
