From owner-freebsd-fs Wed May 15 13: 7:15 2002 Delivered-To: freebsd-fs@freebsd.org Received: from viola.sinor.ru (viola.sinor.ru [217.70.106.9]) by hub.freebsd.org (Postfix) with ESMTP id 0B0EC37B405 for ; Wed, 15 May 2002 13:07:09 -0700 (PDT) Received: from tlg5-ppp85.sibnet.ru (tlg5-ppp85.sibnet.ru [217.70.98.216]) by viola.sinor.ru (8.9.3/8.9.3) with ESMTP id DAA27597; Thu, 16 May 2002 03:06:40 +0700 Date: Thu, 16 May 2002 03:06:57 +0700 (NOVST) From: "Semen A. Ustimenko" X-X-Sender: semenu@def.the.net To: Boris Popov Cc: freebsd-fs@FreeBSD.org, "Flood, Jim" Subject: Re: NULLFS-related possible deadlock + fix proposal In-Reply-To: Message-ID: <20020516023242.L1992-200000@def.the.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1247632081-1021493217=:1992" Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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-1247632081-1021493217=:1992 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi! On Mon, 13 May 2002, Boris Popov wrote: > On Sat, 11 May 2002, Semen A. Ustimenko wrote: > > > DEADLOCK... > > Indeed, weird situation. Nice analysis, btw :) > It would be weird, if it didn't happen in practice :) Thanks are going to Jim, not me... If you like, i can provide a small patch to help you simulate the problem, but it's kind of hack as NULLFS looks seriously broken in -current. > > Make vn_lock() in vrele() lock vnode only LK_THISLAYER. Obviously, the > > NULLFS and other stacking FSes will have to deal with this in their > > VOP_INACTIVE() handlers. This changes won't touch real FSes as they ignore > > the LK_THISLAYER, don't they? > > Yes, you're correct in that LK_THISLAYER currently used only by > "stacked" filesystem(s) and it used exactly for such situations to avoid > deadlocks. The proposed solution may even work without any additional > code because null_inactive() performs its own management on the lower > vnode locking. > Looks like we can't do this that easily, because VOP_INACTIVE is called from different places. Most noticeable from vput(), and it's obvious that vput() caller is responsible for vnode lock... Any ideas? BYe! --0-1247632081-1021493217=:1992 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="nullfs-deadlock.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20020516030657.Q1992@def.the.net> Content-Description: Content-Disposition: attachment; filename="nullfs-deadlock.patch" SW5kZXg6IG51bGxfdm5vcHMuYw0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K UkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9mcy9udWxsZnMvbnVsbF92 bm9wcy5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS41MQ0KZGlmZiAtYyAt cjEuNTEgbnVsbF92bm9wcy5jDQoqKiogbnVsbF92bm9wcy5jCTE4IE1hciAy MDAyIDA1OjM5OjA0IC0wMDAwCTEuNTENCi0tLSBudWxsX3Zub3BzLmMJMTUg TWF5IDIwMDIgMTk6NDE6MjYgLTAwMDANCioqKioqKioqKioqKioqKg0KKioq IDQwNSw0MTAgKioqKg0KLS0tIDQwNSw0MjUgLS0tLQ0KICAJCQkJKmFwLT5h X3ZwcCA9IHZwOw0KICAJCX0NCiAgCX0NCisgDQorIAlwcmludGYoIm51bGxf bG9va3VwICUqcyBlcnJvciAlZFxuIiwgKGludCljbnAtPmNuX25hbWVsZW4s IGNucC0+Y25fbmFtZXB0ciwgZXJyb3IpOw0KKyAJaWYgKGVycm9yID09IDAg JiYNCisgCSAgICBjbnAtPmNuX25hbWVsZW4gPT0gNyAmJiAhc3RybmNtcCgi Zm9vZmlsZSIsIGNucC0+Y25fbmFtZXB0ciwgNykpIHsNCisgCQlpbnQgaTsN CisgDQorIAkJcHJpbnRmKCJEZWxheS4uLiIpOw0KKyAJCWZvciAoaT01OyBp OyBpLS0pIHsNCisgCQkJcHJpbnRmKCIgJWQiLCBpKTsNCisgCQkJdHNsZWVw KGNucCwgUFBBVVNFLCAibnVsbGJ1ZyIsIGh6KTsNCisgCQl9DQorIAkJcHJp bnRmKCJcbiIpOw0KKyAJfSBlbHNlDQorIAkJcHJpbnRmKCJObyBkZWxheVxu Iik7DQorIA0KICAJcmV0dXJuIChlcnJvcik7DQogIH0NCiAgDQoqKioqKioq KioqKioqKioNCioqKiA3MTIsNzE3ICoqKioNCi0tLSA3MjcsNzM0IC0tLS0N CiAgew0KICAJc3RydWN0IHZub2RlICp2cCA9IGFwLT5hX3ZwOw0KICANCisg CVZPUF9VTkxPQ0sodnAsIDAsIGFwLT5hX3RkKTsNCisgDQogIAkvKg0KICAJ ICogSWYgdGhpcyBpcyB0aGUgbGFzdCByZWZlcmVuY2UsIHRoZW4gZnJlZSB1 cCB0aGUgdm5vZGUNCiAgCSAqIHNvIGFzIG5vdCB0byB0aWUgdXAgdGhlIGxv d2VyIHZub2Rlcy4NCioqKioqKioqKioqKioqKg0KKioqIDc0Miw3NTkgKioq Kg0KICAJTElTVF9SRU1PVkUoeHAsIG51bGxfaGFzaCk7DQogIAlsb2NrbWdy KCZudWxsX2hhc2hsb2NrLCBMS19SRUxFQVNFLCBOVUxMLCB0ZCk7DQogIA0K LSAJeHAtPm51bGxfbG93ZXJ2cCA9IE5VTExWUDsNCi0gCWlmICh2cC0+dl92 bmxvY2sgIT0gTlVMTCkgew0KLSAJCXZwLT52X3ZubG9jayA9ICZ2cC0+dl9s b2NrOyAgLyogd2Ugbm8gbG9uZ2VyIHNoYXJlIHRoZSBsb2NrICovDQotIAl9 IGVsc2UNCi0gCQlWT1BfVU5MT0NLKHZwLCBMS19USElTTEFZRVIsIHRkKTsN Ci0gDQogIAkvKg0KICAJICogTm93IGl0IGlzIHNhZmUgdG8gZHJvcCByZWZl cmVuY2VzIHRvIHRoZSBsb3dlciB2bm9kZS4NCiAgCSAqIFZPUF9JTkFDVElW RSgpIHdpbGwgYmUgY2FsbGVkIGJ5IHZyZWxlKCkgaWYgbmVjZXNzYXJ5Lg0K ICAJICovDQohIAl2cHV0KGxvd2VydnApOw0KISAJdnJlbGUgKGxvd2VydnAp Ow0KICANCiAgCXZkYXRhID0gdnAtPnZfZGF0YTsNCiAgCXZwLT52X2RhdGEg PSBOVUxMOw0KLS0tIDc1OSw3NzAgLS0tLQ0KICAJTElTVF9SRU1PVkUoeHAs IG51bGxfaGFzaCk7DQogIAlsb2NrbWdyKCZudWxsX2hhc2hsb2NrLCBMS19S RUxFQVNFLCBOVUxMLCB0ZCk7DQogIA0KICAJLyoNCiAgCSAqIE5vdyBpdCBp cyBzYWZlIHRvIGRyb3AgcmVmZXJlbmNlcyB0byB0aGUgbG93ZXIgdm5vZGUu DQogIAkgKiBWT1BfSU5BQ1RJVkUoKSB3aWxsIGJlIGNhbGxlZCBieSB2cmVs ZSgpIGlmIG5lY2Vzc2FyeS4NCiAgCSAqLw0KISAJdnJlbGUobG93ZXJ2cCk7 DQohIAl2cmVsZShsb3dlcnZwKTsNCiAgDQogIAl2ZGF0YSA9IHZwLT52X2Rh dGE7DQogIAl2cC0+dl9kYXRhID0gTlVMTDsNCg== --0-1247632081-1021493217=:1992-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message