From owner-freebsd-net Sat Mar 18 18:21:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2917B37B5D5; Sat, 18 Mar 2000 18:21:49 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id VAA04001; Sat, 18 Mar 2000 21:21:36 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sat, 18 Mar 2000 21:21:36 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Kurakin Roman Cc: freebsd-net@FreeBSD.ORG Subject: Patch to introduce bpfdetach(), Re: BPF question (FreeBSD 40) In-Reply-To: <38D39537.867C357C@cronyx.ru> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2072806518-953432496=:3649" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-2072806518-953432496=:3649 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 18 Mar 2000, Kurakin Roman wrote: > I have question about using bpf in my KLD module driver. At attach I > call > bpfattach function. What should I call at detach? > Could some one describe to me how bpf is work (function calls, not bpf > as pf :)). I noticed the same behavior a few weeks ago when using tcpdump in wi0 and ejecting the card. This occurs if there are open bpf descriptors for the device, and ifdetach is called (freeing the ifnet structure), at the bp_bif pointer is not set to NULL. I've been running a bpf patch for the last few hours that attempts to clean this behavior up. It introduces a bpfdetach(ifp), which should be called just prior to ifdetach(ifp). If there are any open descriptors on the interface, it sets the bif pointer to NULL, and wakes up listeners. In the bpfread loop, if there are no remaining buffers on the bpf descriptor, and it sees a bp_bif of NULL, it now returns ENXIO to the caller. The remaining fd calls already appeared to have NULL checks for bp_bif, just not bpfread in its wait loop. After this, it frees the bpf_desc structure. It appears to clean up the wi0 tcpdump crash, but I haven't tested it much more than that. Needless to say, any location where ifdetach() is called (that had a matching bpfattach) should now also call bpfdetach(). I have only updated if_wi.c in my patch, as that's all I have on hand right now. Pccard drivers such as ep0 don't require the patch, as they never ifdetach(), leaving the ifnet epX around but unbound. One file attached patches src/sys/net to add the bpfdetach code (bpfdetach.diff). The other patch patches if_wi.c to call bpfdetach (if_wi.diff) Once it's adequately tested (volunteers welcome), I'll commit it to 5.0-CURRENT. > Hi, > > Kurakin Roman > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services --0-2072806518-953432496=:3649 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="bpfdetach.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: src.sys.net.diff T25seSBpbiAvZGF0YS9mYnNkLWNvbW1pdC9zcmMvc3lzL25ldDogQ1ZTDQpk aWZmIC11IC9kYXRhL2Zic2QtY29tbWl0L3NyYy9zeXMvbmV0L2JwZi5jIC4v YnBmLmMNCi0tLSAvZGF0YS9mYnNkLWNvbW1pdC9zcmMvc3lzL25ldC9icGYu YwlTYXQgTWFyIDE4IDAxOjMwOjQxIDIwMDANCisrKyAuL2JwZi5jCVNhdCBN YXIgMTggMjE6MTc6MjAgMjAwMA0KQEAgLTQ3Nyw2ICs0NzcsMTggQEANCiAJ CQlST1RBVEVfQlVGRkVSUyhkKTsNCiAJCQlicmVhazsNCiAJCX0NCisNCisJ CS8qDQorCQkgKiBObyBkYXRhIGlzIGF2YWlsYWJsZSwgY2hlY2sgdG8gc2Vl IGlmIHRoZSBicGYgZGV2aWNlDQorCQkgKiBpcyBzdGlsbCBwb2ludGVkIGF0 IGEgcmVhbCBpbnRlcmZhY2UuICBJZiBub3QsIHJldHVybg0KKwkJICogRU5Y SU8gc28gdGhhdCB0aGUgdXNlcmxhbmQgcHJvY2VzcyBrbm93cyB0byByZWJp bmQNCisJCSAqIGl0IGJlZm9yZSB1c2luZyBpdCBhZ2Fpbi4NCisJCSAqLw0K KwkJaWYgKGQtPmJkX2JpZiA9PSBOVUxMKSB7DQorCQkJc3BseChzKTsNCisJ CQlyZXR1cm4gKEVOWElPKTsNCisJCX0NCisNCiAJCWlmIChpb2ZsYWcgJiBJ T19OREVMQVkpDQogCQkJZXJyb3IgPSBFV09VTERCTE9DSzsNCiAJCWVsc2UN CkBAIC0xMjg1LDYgKzEyOTcsNjAgQEANCiANCiAJaWYgKGJvb3R2ZXJib3Nl KQ0KIAkJcHJpbnRmKCJicGY6ICVzJWQgYXR0YWNoZWRcbiIsIGlmcC0+aWZf bmFtZSwgaWZwLT5pZl91bml0KTsNCit9DQorDQorLyoNCisgKiBEZXRhY2gg YnBmIGZyb20gYW4gaW50ZXJmYWNlLiAgVGhpcyBpbnZvbHZlcyBkZXRhY2hp bmcgZWFjaCBkZXNjcmlwdG9yDQorICogYXNzb2NpYXRlZCB3aXRoIHRoZSBp bnRlcmZhY2UsIGFuZCBsZWF2aW5nIGJkX2JpZiBOVUxMLiAgTm90aWZ5IGVh Y2gNCisgKiBkZXNjcmlwdG9yIGFzIGl0J3MgZGV0YWNoZWQgc28gdGhhdCBh bnkgc2xlZXBlcnMgd2FrZSB1cCBhbmQgZ2V0DQorICogRU5YSU8uDQorICov DQordm9pZA0KK2JwZmRldGFjaChpZnApDQorCXN0cnVjdCBpZm5ldCAqaWZw Ow0KK3sNCisJc3RydWN0IGJwZl9pZgkqYnAsICpicF9wcmV2Ow0KKwlzdHJ1 Y3QgYnBmX2QJKmQ7DQorCWludAlzOw0KKw0KKwlwcmludGYoImJwZmRldGFj aDogJXMlZCBpcyBiZWluZyBkZXRhY2hlZFxuIiwgaWZwLT5pZl9uYW1lLA0K KwkgICAgaWZwLT5pZl91bml0KTsNCisNCisJLyogWFhYIGlzIHRoaXMgbmVl ZGVkPyAgSXMgaXQgcmlnaHQ/ICovDQorCXMgPSBzcGxpbXAoKTsNCisNCisJ LyogTG9jYXRlIEJQRiBpbnRlcmZhY2UgaW5mb3JtYXRpb24gKi8NCisJYnBf cHJldiA9IE5VTEw7DQorCWZvciAoYnAgPSBicGZfaWZsaXN0OyBicCAhPSBO VUxMOyBicCA9IGJwLT5iaWZfbmV4dCkgew0KKwkJaWYgKGlmcCA9PSBicC0+ YmlmX2lmcCkNCisJCQlicmVhazsNCisJCWJwX3ByZXYgPSBicDsNCisJfQ0K Kw0KKwkvKiBJbnRlcmZhY2Ugd2Fzbid0IGF0dGFjaGVkICovDQorCWlmIChi cC0+YmlmX2lmcCA9PSBOVUxMKSB7DQorCQlzcGx4KHMpOw0KKwkJcHJpbnRm KCJicGZkZXRhY2g6ICVzJWQgd2FzIG5vdCBhdHRhY2hlZFxuIiwgaWZwLT5p Zl9uYW1lLA0KKwkJICAgIGlmcC0+aWZfdW5pdCk7DQorCQlyZXR1cm47DQor CX0NCisNCisJd2hpbGUgKChkID0gYnAtPmJpZl9kbGlzdCkgIT0gTlVMTCkg ew0KKwkJYnBmX2RldGFjaGQoZCk7DQorCQlicGZfd2FrZXVwKGQpOw0KKwl9 DQorDQorCWlmIChicF9wcmV2KSB7DQorCQlicF9wcmV2LT5iaWZfbmV4dCA9 IGJwLT5iaWZfbmV4dDsNCisJfSBlbHNlIHsNCisJCWJwZl9pZmxpc3QgPSBi cC0+YmlmX25leHQ7DQorCX0NCisNCisJZnJlZShicCwgTV9CUEYpOw0KKw0K KwlzcGx4KHMpOw0KKw0KKwlwcmludGYoImJwZmRldGFjaDogJXMlZCBpcyBk ZXRhY2hlZFxuIiwgaWZwLT5pZl9uYW1lLCBpZnAtPmlmX3VuaXQpOw0KIH0N CiANCiBzdGF0aWMgdm9pZCBicGZfZHJ2aW5pdCBfX1AoKHZvaWQgKnVudXNl ZCkpOw0KZGlmZiAtdSAvZGF0YS9mYnNkLWNvbW1pdC9zcmMvc3lzL25ldC9i cGYuaCAuL2JwZi5oDQotLS0gL2RhdGEvZmJzZC1jb21taXQvc3JjL3N5cy9u ZXQvYnBmLmgJU2F0IE1hciAxOCAwMTozMDo0MiAyMDAwDQorKysgLi9icGYu aAlTYXQgTWFyIDE4IDIxOjE2OjMzIDIwMDANCkBAIC0yMzIsNiArMjMyLDgg QEANCiB2b2lkCSBicGZfdGFwIF9fUCgoc3RydWN0IGlmbmV0ICosIHVfY2hh ciAqLCB1X2ludCkpOw0KIHZvaWQJIGJwZl9tdGFwIF9fUCgoc3RydWN0IGlm bmV0ICosIHN0cnVjdCBtYnVmICopKTsNCiB2b2lkCSBicGZhdHRhY2ggX19Q KChzdHJ1Y3QgaWZuZXQgKiwgdV9pbnQsIHVfaW50KSk7DQordm9pZAkgYnBm ZGV0YWNoIF9fUCgoc3RydWN0IGlmbmV0ICopKTsNCisNCiB2b2lkCSBicGZp bHRlcmF0dGFjaCBfX1AoKGludCkpOw0KIHVfaW50CSBicGZfZmlsdGVyIF9f UCgoY29uc3Qgc3RydWN0IGJwZl9pbnNuICosIHVfY2hhciAqLCB1X2ludCwg dV9pbnQpKTsNCiAjZW5kaWYNCg== --0-2072806518-953432496=:3649 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="if_wi.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: i386.isa.if_wi.c.diff LS0tIGlmX3dpLmMJV2VkIEZlYiAgMiAxMjo1OToxMiAyMDAwDQorKysgL3Rt cC9pZl93aS5jCVNhdCBNYXIgMTggMjE6MTk6MzkgMjAwMA0KQEAgLTIxNCw2 ICsyMTQsOCBAQA0KIAl9DQogDQogCXdpX3N0b3Aoc2MpOw0KKw0KKwlicGZk ZXRhY2goaWZwKTsNCiAJaWZfZGV0YWNoKGlmcCk7DQogCWJ1c190ZWFyZG93 bl9pbnRyKGRldiwgc2MtPmlycSwgc2MtPndpX2ludHJoYW5kKTsNCiAJd2lf ZnJlZShkZXYpOw0K --0-2072806518-953432496=:3649-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message