conf/144442: [PATCH] remove unnecessary group and passwd entries for new DESTDIRS // mergemaster
>Number: 12 >Category: conf >Synopsis: [PATCH] remove unnecessary group and passwd entries for new >DESTDIRS // mergemaster >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: Wed Mar 03 08:00:12 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Garrett Cooper >Release:RELENG_8 >Organization: Cisco Systems, Inc >Environment: FreeBSD garrcoop-fbsd.cisco.com 8.0-STABLE FreeBSD 8.0-STABLE #2: Wed Feb 3 16:57:07 PST 2010 garrc...@garrcoop-fbsd.cisco.com:/usr/obj/usr/src/sys/LAPPY_X86 i386 >Description: The following patch removes all /etc/group and /etc/master.passwd entries based on MK_* variables defined when running make distribution on etc. This patch uses goals for group and master.passwd in order to not whack existing files that may have been setup after ports were installed, and thus potentially break already installed packages. mergemaster(1) is exempt from this because DESTDIR is set to somewhere off in /var/tmp/[...] and a diff is run against the running system <-> sysroot's files before it's installed in the sysroot, IFF the individual deletes the temproot between each run (or whatever the term was that mergemaster(1) uses...). >How-To-Repeat: n/a >Fix: See proposed enhancement patch. >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: conf/144442: [PATCH] remove unnecessary group and passwd entries for new DESTDIRS // mergemaster
Might help if I actually provided the patch. Heh.
Cheers,
-Garrett
Index: head/etc/Makefile
===
--- head/etc/Makefile (revision 204532)
+++ head/etc/Makefile (working copy)
@@ -148,11 +148,51 @@
PWD_MKDB_ENDIAN?=
.endif
-distribution:
+${DESTDIR}/etc/group:
+ cd ${.CURDIR}; \
+ ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 644 ${.TARGET:T} ${.TARGET}
+.if ${MK_BIND} == "no"
+ sed -i "" -e ';^bind:;d' ${.TARGET}
+.endif
+.if ${MK_GAMES} == "no"
+ sed -i "" -e ';^games:;d' ${.TARGET}
+.endif
+.if ${MK_MAIL} == "no"
+ sed -i "" -e ';^mail:;d' ${.TARGET}
+.endif
+.if ${MK_MAN} == "no"
+ sed -i "" -e ';^man:;d' ${.TARGET}
+.endif
+.if ${MK_SENDMAIL} == "no"
+ sed -i "" -e ';^mailnull:;d' -e ';^ssmsp:;d' ${.TARGET}
+.endif
+
+${DESTDIR}/etc/master.passwd:
+ cd ${.CURDIR}; \
+ ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 600 ${.TARGET:T} ${.TARGET}
+.if ${MK_BIND} == "no"
+ sed -i "" -e ';^bind:;d' ${.TARGET}
+.endif
+.if ${MK_GAMES} == "no"
+ sed -i "" -e ';^games:;d' ${.TARGET}
+.endif
+.if ${MK_MAIL} == "no"
+ sed -i "" -e ';^pop:;d' ${.TARGET}
+.endif
+.if ${MK_MAN} == "no"
+ sed -i "" -e ';^man:;d' ${.TARGET}
+.endif
+.if ${MK_SENDMAIL} == "no"
+ sed -i "" -e ';^mailnull:;d' -e ';^ssmsp:;d' ${.TARGET}
+.endif
+
+distribution:
.if !defined(DESTDIR)
@echo "set DESTDIR before running \"make ${.TARGET}\""
@false
.endif
+ ${MAKE} DESTDIR=${DESTDIR} ${DESTDIR}/etc/group
+ ${MAKE} DESTDIR=${DESTDIR} ${DESTDIR}/etc/passwd
cd ${.CURDIR}; \
${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 644 \
${BIN1} ${DESTDIR}/etc; \
@@ -160,7 +200,7 @@
${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 755 \
${BIN2} ${DESTDIR}/etc; \
${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 600 \
- master.passwd nsmb.conf opieaccess ${DESTDIR}/etc;
+ nsmb.conf opieaccess ${DESTDIR}/etc;
.if ${MK_TCSH} == "no"
sed -i "" -e 's;/bin/csh;/bin/sh;' ${DESTDIR}/etc/master.passwd
.endif
___
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: conf/144442: [PATCH] remove unnecessary group and passwd entries for new DESTDIRS // mergemaster
The following reply was made to PR conf/12; it has been noted by GNATS. From: Garrett Cooper To: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org Cc: Subject: Re: conf/12: [PATCH] remove unnecessary group and passwd entries for new DESTDIRS // mergemaster Date: Wed, 3 Mar 2010 00:53:37 -0800 --000e0cd104f43813c50480e19e36 Content-Type: text/plain; charset=ISO-8859-1 Might help if I actually provided the patch. Heh. Cheers, -Garrett --000e0cd104f43813c50480e19e36 Content-Type: text/plain; charset=US-ASCII; name="yank-group+passwd-entries.diff.txt" Content-Disposition: attachment; filename="yank-group+passwd-entries.diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g6bw443c0 SW5kZXg6IGhlYWQvZXRjL01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGhlYWQvZXRjL01ha2VmaWxl CShyZXZpc2lvbiAyMDQ1MzIpCisrKyBoZWFkL2V0Yy9NYWtlZmlsZQkod29ya2luZyBjb3B5KQpA QCAtMTQ4LDExICsxNDgsNTEgQEAKIFBXRF9NS0RCX0VORElBTj89CiAuZW5kaWYKIAotZGlzdHJp YnV0aW9uOgorJHtERVNURElSfS9ldGMvZ3JvdXA6CisJY2QgJHsuQ1VSRElSfTsgXAorCSAgICAk e0lOU1RBTEx9IC1vICR7QklOT1dOfSAtZyAke0JJTkdSUH0gLW0gNjQ0ICR7LlRBUkdFVDpUfSAk ey5UQVJHRVR9CisuaWYgJHtNS19CSU5EfSA9PSAibm8iCisJc2VkIC1pICIiIC1lICc7XmJpbmQ6 O2QnICR7LlRBUkdFVH0KKy5lbmRpZgorLmlmICR7TUtfR0FNRVN9ID09ICJubyIKKwlzZWQgLWkg IiIgLWUgJzteZ2FtZXM6O2QnICR7LlRBUkdFVH0KKy5lbmRpZgorLmlmICR7TUtfTUFJTH0gPT0g Im5vIgorCXNlZCAtaSAiIiAtZSAnO15tYWlsOjtkJyAkey5UQVJHRVR9CisuZW5kaWYKKy5pZiAk e01LX01BTn0gPT0gIm5vIgorCXNlZCAtaSAiIiAtZSAnO15tYW46O2QnICR7LlRBUkdFVH0KKy5l bmRpZgorLmlmICR7TUtfU0VORE1BSUx9ID09ICJubyIKKwlzZWQgLWkgIiIgLWUgJztebWFpbG51 bGw6O2QnIC1lICc7XnNzbXNwOjtkJyAkey5UQVJHRVR9CisuZW5kaWYKKworJHtERVNURElSfS9l dGMvbWFzdGVyLnBhc3N3ZDoKKwljZCAkey5DVVJESVJ9OyBcCisJICAgICR7SU5TVEFMTH0gLW8g JHtCSU5PV059IC1nICR7QklOR1JQfSAtbSA2MDAgJHsuVEFSR0VUOlR9ICR7LlRBUkdFVH0KKy5p ZiAke01LX0JJTkR9ID09ICJubyIKKwlzZWQgLWkgIiIgLWUgJzteYmluZDo7ZCcgJHsuVEFSR0VU fQorLmVuZGlmCisuaWYgJHtNS19HQU1FU30gPT0gIm5vIgorCXNlZCAtaSAiIiAtZSAnO15nYW1l czo7ZCcgJHsuVEFSR0VUfQorLmVuZGlmCisuaWYgJHtNS19NQUlMfSA9PSAibm8iCisJc2VkIC1p ICIiIC1lICc7XnBvcDo7ZCcgJHsuVEFSR0VUfQorLmVuZGlmCisuaWYgJHtNS19NQU59ID09ICJu byIKKwlzZWQgLWkgIiIgLWUgJztebWFuOjtkJyAkey5UQVJHRVR9CisuZW5kaWYKKy5pZiAke01L X1NFTkRNQUlMfSA9PSAibm8iCisJc2VkIC1pICIiIC1lICc7Xm1haWxudWxsOjtkJyAtZSAnO15z c21zcDo7ZCcgJHsuVEFSR0VUfQorLmVuZGlmCisKK2Rpc3RyaWJ1dGlvbjogCiAuaWYgIWRlZmlu ZWQoREVTVERJUikKIAlAZWNobyAic2V0IERFU1RESVIgYmVmb3JlIHJ1bm5pbmcgXCJtYWtlICR7 LlRBUkdFVH1cIiIKIAlAZmFsc2UKIC5lbmRpZgorCSR7TUFLRX0gREVTVERJUj0ke0RFU1RESVJ9 ICR7REVTVERJUn0vZXRjL2dyb3VwCisJJHtNQUtFfSBERVNURElSPSR7REVTVERJUn0gJHtERVNU RElSfS9ldGMvcGFzc3dkCiAJY2QgJHsuQ1VSRElSfTsgXAogCSAgICAke0lOU1RBTEx9IC1vICR7 QklOT1dOfSAtZyAke0JJTkdSUH0gLW0gNjQ0IFwKIAkJJHtCSU4xfSAke0RFU1RESVJ9L2V0Yzsg XApAQCAtMTYwLDcgKzIwMCw3IEBACiAJICAgICR7SU5TVEFMTH0gLW8gJHtCSU5PV059IC1nICR7 QklOR1JQfSAtbSA3NTUgXAogCQkke0JJTjJ9ICR7REVTVERJUn0vZXRjOyBcCiAJICAgICR7SU5T VEFMTH0gLW8gJHtCSU5PV059IC1nICR7QklOR1JQfSAtbSA2MDAgXAotCQltYXN0ZXIucGFzc3dk IG5zbWIuY29uZiBvcGllYWNjZXNzICR7REVTVERJUn0vZXRjOworCQluc21iLmNvbmYgb3BpZWFj Y2VzcyAke0RFU1RESVJ9L2V0YzsKIC5pZiAke01LX1RDU0h9ID09ICJubyIKIAlzZWQgLWkgIiIg LWUgJ3M7L2Jpbi9jc2g7L2Jpbi9zaDsnICR7REVTVERJUn0vZXRjL21hc3Rlci5wYXNzd2QKIC5l bmRpZgo= --000e0cd104f43813c50480e19e36-- ___ 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/143558: [patch] Add verbose option to pkill(1)
The following reply was made to PR bin/143558; it has been noted by GNATS.
From: Eitan Adler
To: bug-follo...@freebsd.org, eitanadlerl...@gmail.com
Cc:
Subject: Re: bin/143558: [patch] Add verbose option to pkill(1)
Date: Wed, 3 Mar 2010 13:12:59 +0200
Two updates
1) remove useless change to getopt parameters
2) pgrep -l no longer prints out extra kill information
Index: pkill.1
===
--- pkill.1(revision 203347)
+++ pkill.1(working copy)
@@ -168,9 +168,9 @@
If used in conjunction with
.Fl f ,
print the process ID and the full argument list for each matching process.
-This option can only be used with the
-.Nm pgrep
-command.
+If used in conjunction with the
+.Nm pkill
+command, it lists the signal sent as well.
.It Fl n
Select only the newest (most recently started) of the matching processes.
.It Fl o
Index: pkill.c
===
--- pkill.c(revision 203347)
+++ pkill.c(working copy)
@@ -245,8 +245,6 @@
criteria = 1;
break;
case 'l':
- if (!pgrep)
- usage();
longfmt = 1;
break;
case 'n':
@@ -528,16 +526,26 @@
/*
* Take the appropriate action for each matched process, if any.
*/
+ int didAction = 0;
for (i = 0, rv = 0, kp = plist; i < nproc; i++, kp++) {
if (PSKIP(kp))
continue;
if (selected[i]) {
+ if (longfmt && !pgrep)
+ {
+ didAction = 1;
+ printf("kill -%d %d\n",signum,kp->ki_pid);
+ }
if (inverse)
continue;
} else if (!inverse)
continue;
rv |= (*action)(kp);
}
+ if (!didAction && !pgrep && longfmt)
+ {
+ printf("No matching processes belonging to you were found\n");
+ }
exit(rv ? STATUS_MATCH : STATUS_NOMATCH);
}
@@ -550,7 +558,7 @@
if (pgrep)
ustr = "[-LSfilnovx] [-d delim]";
else
- ustr = "[-signal] [-ILfinovx]";
+ ustr = "[-signal] [-ILfilnovx]";
fprintf(stderr,
"usage: %s %s [-F pidfile] [-G gid] [-M core] [-N system]\n"
___
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/144446: [patch] db(3) fails with large block sizes
>Number: 16 >Category: bin >Synopsis: [patch] db(3) fails with large block sizes >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: Wed Mar 03 11:30:01 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Peter Jeremy >Release:FreeBSD 8.0-STABLE amd64 >Organization: Alcatel-Lucent Australia >Environment: System: FreeBSD server.vk2pj.dyndns.org 8.0-STABLE FreeBSD 8.0-STABLE #1: Wed Jan 27 06:55:10 EST 2010 r...@server.vk2pj.dyndns.org:/var/obj/usr/src/sys/server amd64 >Description: Whilst trying to port db(3) to a Solaris system, I have identified two issues with the existing hash(3) code. Firstly, when creating a new hash database, the bucket size defaults to the st_blksize of the file (hash/hash.c::init_hash()). There is no sanity checking to ensure that st_blksize is within valid limits (hash/hash.h defined MAX_BSIZE as 65536). In FreeBSD, st_blksize is currently hardwired to PAGE_SIZE in kern/vfs_vnops.c::vn_stat() so this is purely a theoretical issue on FreeBSD. Solaris exposes the blocksize from the underlying filesystem - and in the case of ZFS, this is 128KB, which exceeds MAX_BSIZE. In my case, the symptoms were that when sequentially reading the database (via DB->seq()), the returned keys were padded with 64KB of NULs. Secondly, when the bucket size is set to 64KB (MAX_BSIZE), non-trivial databases crash reporting: "HASH: Out of overflow pages. Increase page size" It's not clear what triggers this. Thirdly, whilst writing this PR, I've noticed that hash(3) states that the default hash table bucket size is 256 bytes. The actual default (as per DEF_BUCKET_SIZE in hash/hash.h) is 4096 bytes. >How-To-Repeat: First problem can't be reproduced on FreeBSD but occurs on at least Solaris and OpenSolaris with ZFS. The second problem can be reproduced by extending the db test tool (lib/libc/db/test/run.test, test20) to include a bucket size of 65536. Based on the progression of fill factor's in test20, the logical fill factors are 2735 3647 5471, however the test fails with each of these values as well as 8, 341 and 10001. All other bucket sizes appear to work successfully - which suggests there is a problem with this particular bucket size. >Fix: First patch adds check for excessive st_blksize. Note that this assumes that st_blksize is a power of 2. It might be reasonable to verify that st_blksize isn't too small but I'm not sure what the lower limit is. Index: hash/hash.c === RCS file: /usr/ncvs/src/lib/libc/db/hash/hash.c,v retrieving revision 1.21.2.2 diff -u -r1.21.2.2 hash.c --- hash/hash.c 28 Aug 2009 19:48:06 - 1.21.2.2 +++ hash/hash.c 3 Mar 2010 09:39:45 - @@ -293,6 +293,8 @@ if (stat(file, &statbuf)) return (NULL); hashp->BSIZE = statbuf.st_blksize; + if (hashp->BSIZE > MAX_BSIZE) + hashp->BSIZE = MAX_BSIZE; hashp->BSHIFT = __log2(hashp->BSIZE); } This is simply a work-around for the second problem. I'm not certain what the actual problem is bu this avoids it. Index: hash/hash.h === RCS file: /usr/ncvs/src/lib/libc/db/hash/hash.h,v retrieving revision 1.9.2.1 diff -u -r1.9.2.1 hash.h --- hash/hash.h 3 Aug 2009 08:13:06 - 1.9.2.1 +++ hash/hash.h 3 Mar 2010 09:39:45 - @@ -118,7 +118,7 @@ /* * Constants */ -#defineMAX_BSIZE 65536 /* 2^16 */ +#defineMAX_BSIZE 32768 /* 2^15 but should be 65536 */ #define MIN_BUFFERS6 #define MINHDRSIZE 512 #define DEF_BUFSIZE65536 /* 64 K */ The following updates the man page to contain the current default bucket size as per DEF_BUCKET_SIZE in hash/hash.h Index: man/hash.3 === RCS file: /usr/ncvs/src/lib/libc/db/man/hash.3,v retrieving revision 1.9.10.1 diff -u -r1.9.10.1 hash.3 --- man/hash.3 3 Aug 2009 08:13:06 - 1.9.10.1 +++ man/hash.3 3 Mar 2010 09:50:52 - @@ -78,7 +78,7 @@ element defines the .Nm -table bucket size, and is, by default, 256 bytes. +table bucket size, and is, by default, 4096 bytes. It may be preferable to increase the page size for disk-resident tables and tables with large data items. .It Va ffactor >Release-Note: >Au
kern/144447: [ZFS] sharenfs fsunshare() & fsshare_main() non functiional.
>Number: 17 >Category: kern >Synopsis: [ZFS] sharenfs fsunshare() & fsshare_main() non functiional. >Confidential: no >Severity: serious >Priority: high >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 03 13:10:04 UTC 2010 >Closed-Date: >Last-Modified: >Originator: jhell >Release:>= stable/7 r204486 Sun Feb 28 19:42:46 EST 2010 >Organization: >Environment: FreeBSD 7.3-STABLE #0 r204486 Sun Feb 28 19:42:46 EST 2010 BRANCH_OVERRIDE=STABLE >Description: After exporting some filesystems from zfs via sharenfs I decided to turn the shares back off after I was done with them on another machine. To my surprise the datasets that I had shared previously were still shared. Process: # This command adds the share through nfs in /etc/zfs/exports zfs set sharenfs='-maproot=0 disbatch' exports/svn bla bla bla after using them for a little while: # This command should turn off the nfs share and remove the line from # /etc/zfs/exports and signal mountd or whatever. zfs set sharenfs=off exports/svn Low and behold this line is never removed the share and continues even through a reboot all while sharenfs=off on the dataset. No no other datasets are shared at this time. The line in /etc/zfs/exports changes just fine when changing the options via "zfs set sharenfs". I also removed /etc/zfs/exports and repeated the process. It still continued. Also have destroyed datasets and the nfs share still exists. Can someone take a look at this ?. >How-To-Repeat: # This command adds the nfs share in /etc/zfs/exports zfs set sharenfs='-maproot=0 disbatch' exports/svn # This command should turn off the nfs share and remove the line from # /etc/zfs/exports and signal mountd or whatever. zfs set sharenfs=off exports/svn >Fix: No known fix available at the moment. It does not look like fsunshare() is being called from the little time that I actually had to debug this problem before the report. >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/144447: [zfs] sharenfs fsunshare() & fsshare_main() non functiional.
Old Synopsis: [ZFS] sharenfs fsunshare() & fsshare_main() non functiional. New Synopsis: [zfs] sharenfs fsunshare() & fsshare_main() non functiional. Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 3 13:20:45 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=17 ___ 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/89410: commit references a PR
The following reply was made to PR bin/89410; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: bin/89410: commit references a PR
Date: Wed, 3 Mar 2010 16:06:52 + (UTC)
Author: jh
Date: Wed Mar 3 16:06:43 2010
New Revision: 204637
URL: http://svn.freebsd.org/changeset/base/204637
Log:
MFC r204276:
Fix expansion of \W in prompt strings when the working directory is "/".
The prompt string was truncated after \W when the working directory was "/".
PR: bin/89410
Modified:
stable/8/bin/sh/parser.c
Directory Properties:
stable/8/bin/sh/ (props changed)
Modified: stable/8/bin/sh/parser.c
==
--- stable/8/bin/sh/parser.c Wed Mar 3 15:43:26 2010(r204636)
+++ stable/8/bin/sh/parser.c Wed Mar 3 16:06:43 2010(r204637)
@@ -1631,7 +1631,7 @@ getprompt(void *unused __unused)
case 'w':
ps[i] = '\0';
getcwd(&ps[i], PROMPTLEN - i);
- if (*fmt == 'W') {
+ if (*fmt == 'W' && ps[i + 1] != '\0') {
/* Final path component only. */
trim = 1;
for (j = i; ps[j] != '\0'; j++)
___
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"
kern/144453: bpf(4) can panic due to a race condition on descriptor destruction
>Number: 144453 >Category: kern >Synopsis: bpf(4) can panic due to a race condition on descriptor >destruction >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: Wed Mar 03 21:20:03 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Alexander Sack >Release:CURRENT, 7.2-amd64 >Organization: Niksun >Environment: SA5000PAL Intel board with 8GB of RAM, em(4) network interface card >Description: When an application polls on a particular bpf descriptor, a timeout is scheduled, bpf_timed_out() via callout_reset(). If a buffer is not available within the poll period, bpf_timed_out() is fired which will change the bpf_d state and wakeup any threads waiting for an event. When bpf_timed_out() is attempts to acquire the descriptor lock. Now if a process is in the middle of a poll/select and closes (gracefully or otherwise) when the bpf descriptor is closed, bpf_dtor() is called. This will acquire the descriptor lock and do callout_stop() if the bpf state is in BPF_WAITING (i.e. select was called and callout_reset has completed scheduling the callout). After calling callout_stop() it released the descriptor lock where now a race condition can occur. If callout_stop() can't stop bpf_timed_out() from firing (say it has already fired) then bpf_timed_out() is sitting waiting on the descriptor lock to continue. When bpf_dtor() drops the lock, bpf_timed_out() is allowed to continue. But bpf_dtor() is going to free the descriptor that bpf_timed_out() is currently changing. This can lead to panic. The patch attached addresses this situation by just doing a callout_active() and if so do a callout_drain() which will wait until bpf_timed_out() has finished. This allows bpf_dtor() to confidently free the descriptor during close operation. >How-To-Repeat: Loads of pollers on a descriptor with high load during a shutdown. >Fix: See patch attached. I tested this on my Intel machine issuing 200 tcpdump processes with zerocopy disabled and enabled (even though with zerocopy libpcap doens't poll on it) capturing 100% utilization gige traffic. No panic occured during shutdown. We also saw this using our own custom packet capture application which is where I discovered and fixed the problem. Patch attached with submission follows: ? bpf.patch Index: bpf.c === RCS file: /home/ncvs/src/sys/net/bpf.c,v retrieving revision 1.219 diff -u -r1.219 bpf.c --- bpf.c 20 Feb 2010 00:19:21 - 1.219 +++ bpf.c 3 Mar 2010 21:04:48 - @@ -614,6 +614,15 @@ mac_bpfdesc_destroy(d); #endif /* MAC */ knlist_destroy(&d->bd_sel.si_note); + /* +* If we could not stop the callout above, +* then when we release the descriptor lock, +* there is a race between when bpf_timed_out() +* finishes and descriptor tear down. Check +* for it and drain. +*/ + if (callout_active(&d->bd_callout)) + callout_drain(&d->bd_callout); bpf_freed(d); free(d, M_BPF); } >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/144453: bpf(4) can panic due to a race condition on descriptor destruction
Synopsis: bpf(4) can panic due to a race condition on descriptor destruction Responsible-Changed-From-To: freebsd-bugs->jkim Responsible-Changed-By: jkim Responsible-Changed-When: Wed Mar 3 22:29:33 UTC 2010 Responsible-Changed-Why: I will take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=144453 ___ 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/144415: [zfs] [panic] kernel panics on boot after zfs crash
Old Synopsis: kernel panics on boot New Synopsis: [zfs] [panic] kernel panics on boot after zfs crash Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 4 04:07:03 UTC 2010 Responsible-Changed-Why: Fix up synopsis and assign. http://www.freebsd.org/cgi/query-pr.cgi?pr=144415 ___ 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/144416: [panic] Kernel panic on online filesystem optimization
Old Synopsis: Kernel panic on online filesystem optimization New Synopsis: [panic] Kernel panic on online filesystem optimization Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 4 04:09:51 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=144416 ___ 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"
