From owner-freebsd-fs Wed Jun 6 2:41:36 2001 Delivered-To: freebsd-fs@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id ACD1237B405; Wed, 6 Jun 2001 02:40:45 -0700 (PDT) (envelope-from bp@butya.kz) Received: by relay.butya.kz (Postfix, from userid 1000) id 7A72628B1B; Wed, 6 Jun 2001 16:40:41 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 552612883F; Wed, 6 Jun 2001 16:40:41 +0700 (ALMST) Date: Wed, 6 Jun 2001 16:40:41 +0700 (ALMST) From: Boris Popov To: stable@freebsd.org Cc: fs@freebsd.org Subject: CFR: Fixes for nullfs in -stable Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-248198860-991820441=:61571" 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-248198860-991820441=:61571 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I've mostly merged improvements done to nullfs in the -current to RELENG_4 branch. Operations on mmaped files were fixed before and this patch focused on the proper vnode locking. Unfortunately, this code require changes in the layout of vnode structure. It is possible to not break binary compatibility by changing behavior of vop_sharedlock() function and using v_vnlock field as this is done in -current. This requires changes only to nfs code by including lock structure in the nfsnode structure (in the original code it was allocated separately for each nfsnode). Size and layout of vnode structure left unchanged. I hope this will not break any 3rd party file system because all new fs'es should use vop_std*lock() VOPs or roll their own. Patch against recent RELENG_4 is attached. And if there is no serious objections I'm plan to commit it on the next week. -- Boris Popov http://www.butya.kz/~bp/ --0-248198860-991820441=:61571 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="nullfs4.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="nullfs4.diff" SW5kZXg6IGtlcm4vdmZzX2RlZmF1bHQuYw0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9rZXJuL3Zmc19k ZWZhdWx0LmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjI4LjIuMQ0KZGlm ZiAtdSAtcjEuMjguMi4xIHZmc19kZWZhdWx0LmMNCi0tLSBrZXJuL3Zmc19k ZWZhdWx0LmMJMjAwMS8wNS8xOCAwOTo1ODo0MwkxLjI4LjIuMQ0KKysrIGtl cm4vdmZzX2RlZmF1bHQuYwkyMDAxLzA2LzA2IDA4OjUzOjQ5DQpAQCAtMzYw LDE0ICszNjAsMTMgQEANCiAJICogdG8gYmUgaGFuZGxlZCBpbiBpbnRlcm1l ZGlhdGUgbGF5ZXJzLg0KIAkgKi8NCiAJc3RydWN0IHZub2RlICp2cCA9IGFw LT5hX3ZwOw0KKwlzdHJ1Y3QgbG9jayAqbCA9IChzdHJ1Y3QgbG9jayAqKXZw LT52X2RhdGE7DQogCWludCB2bmZsYWdzLCBmbGFncyA9IGFwLT5hX2ZsYWdz Ow0KIA0KLQlpZiAodnAtPnZfdm5sb2NrID09IE5VTEwpIHsNCi0JCWlmICgo ZmxhZ3MgJiBMS19UWVBFX01BU0spID09IExLX0RSQUlOKQ0KLQkJCXJldHVy biAoMCk7DQotCQlNQUxMT0ModnAtPnZfdm5sb2NrLCBzdHJ1Y3QgbG9jayAq LCBzaXplb2Yoc3RydWN0IGxvY2spLA0KLQkJICAgIE1fVk5PREUsIE1fV0FJ VE9LKTsNCi0JCWxvY2tpbml0KHZwLT52X3ZubG9jaywgUFZGUywgInZubG9j ayIsIDAsIExLX05PUEFVU0UpOw0KKwlpZiAobCA9PSBOVUxMKSB7DQorCQlp ZiAoYXAtPmFfZmxhZ3MgJiBMS19JTlRFUkxPQ0spDQorCQkJc2ltcGxlX3Vu bG9jaygmYXAtPmFfdnAtPnZfaW50ZXJsb2NrKTsNCisJCXJldHVybiAwOw0K IAl9DQogCXN3aXRjaCAoZmxhZ3MgJiBMS19UWVBFX01BU0spIHsNCiAJY2Fz ZSBMS19EUkFJTjoNCkBAIC0zOTYsOSArMzk1LDkgQEANCiAJaWYgKGZsYWdz ICYgTEtfSU5URVJMT0NLKQ0KIAkJdm5mbGFncyB8PSBMS19JTlRFUkxPQ0s7 DQogI2lmbmRlZglERUJVR19MT0NLUw0KLQlyZXR1cm4gKGxvY2ttZ3IodnAt PnZfdm5sb2NrLCB2bmZsYWdzLCAmdnAtPnZfaW50ZXJsb2NrLCBhcC0+YV9w KSk7DQorCXJldHVybiAobG9ja21ncihsLCB2bmZsYWdzLCAmdnAtPnZfaW50 ZXJsb2NrLCBhcC0+YV9wKSk7DQogI2Vsc2UNCi0JcmV0dXJuIChkZWJ1Z2xv Y2ttZ3IodnAtPnZfdm5sb2NrLCB2bmZsYWdzLCAmdnAtPnZfaW50ZXJsb2Nr LCBhcC0+YV9wLA0KKwlyZXR1cm4gKGRlYnVnbG9ja21ncihsLCB2bmZsYWdz LCAmdnAtPnZfaW50ZXJsb2NrLCBhcC0+YV9wLA0KIAkgICAgInZvcF9zaGFy ZWRsb2NrIiwgdnAtPmZpbGVuYW1lLCB2cC0+bGluZSkpOw0KICNlbmRpZg0K IH0NCkBAIC00MzUsMTMgKzQzNCw2IEBADQogCXN0cnVjdCB2bm9kZSAqdnAg PSBhcC0+YV92cDsNCiAJaW50IHZuZmxhZ3MsIGZsYWdzID0gYXAtPmFfZmxh Z3M7DQogDQotCWlmICh2cC0+dl92bmxvY2sgPT0gTlVMTCkgew0KLQkJaWYg KChmbGFncyAmIExLX1RZUEVfTUFTSykgPT0gTEtfRFJBSU4pDQotCQkJcmV0 dXJuICgwKTsNCi0JCU1BTExPQyh2cC0+dl92bmxvY2ssIHN0cnVjdCBsb2Nr ICosIHNpemVvZihzdHJ1Y3QgbG9jayksDQotCQkgICAgTV9WTk9ERSwgTV9X QUlUT0spOw0KLQkJbG9ja2luaXQodnAtPnZfdm5sb2NrLCBQVkZTLCAidm5s b2NrIiwgMCwgTEtfTk9QQVVTRSk7DQotCX0NCiAJc3dpdGNoIChmbGFncyAm IExLX1RZUEVfTUFTSykgew0KIAljYXNlIExLX0RSQUlOOg0KIAkJdm5mbGFn cyA9IExLX0RSQUlOOw0KQEAgLTQ4NSwxMyArNDc3LDkgQEANCiB7DQogCXN0 cnVjdCB2bm9kZSAqdnAgPSBhcC0+YV92cDsNCiANCi0JaWYgKHZwLT52X3Zu bG9jayA9PSBOVUxMKSB7DQotCQlpZiAoYXAtPmFfZmxhZ3MgJiBMS19JTlRF UkxPQ0spDQotCQkJc2ltcGxlX3VubG9jaygmYXAtPmFfdnAtPnZfaW50ZXJs b2NrKTsNCi0JCXJldHVybiAoMCk7DQotCX0NCi0JcmV0dXJuIChsb2NrbWdy KHZwLT52X3ZubG9jaywgTEtfUkVMRUFTRSB8IGFwLT5hX2ZsYWdzLA0KLQkJ JmFwLT5hX3ZwLT52X2ludGVybG9jaywgYXAtPmFfcCkpOw0KKwlpZiAoYXAt PmFfZmxhZ3MgJiBMS19JTlRFUkxPQ0spDQorCQlzaW1wbGVfdW5sb2NrKCZ2 cC0+dl9pbnRlcmxvY2spOw0KKwlyZXR1cm4gKDApOw0KIH0NCiANCiAvKg0K QEAgLTUwNSwxMCArNDkzLDExIEBADQogCX0gKi8gKmFwOw0KIHsNCiAJc3Ry dWN0IHZub2RlICp2cCA9IGFwLT5hX3ZwOw0KKwlzdHJ1Y3QgbG9jayAqbCA9 IChzdHJ1Y3QgbG9jayAqKXZwLT52X2RhdGE7DQogDQotCWlmICh2cC0+dl92 bmxvY2sgPT0gTlVMTCkNCisJaWYgKGwgPT0gTlVMTCkNCiAJCXJldHVybiAo MCk7DQotCXJldHVybiAobG9ja3N0YXR1cyh2cC0+dl92bmxvY2ssIGFwLT5h X3ApKTsNCisJcmV0dXJuIChsb2Nrc3RhdHVzKGwsIGFwLT5hX3ApKTsNCiB9 DQogDQogaW50DQpJbmRleDoga2Vybi92ZnNfc3Vici5jDQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL2tl cm4vdmZzX3N1YnIuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjQ5LjIu OA0KZGlmZiAtdSAtcjEuMjQ5LjIuOCB2ZnNfc3Vici5jDQotLS0ga2Vybi92 ZnNfc3Vici5jCTIwMDEvMDUvMTggMDk6NTg6NDMJMS4yNDkuMi44DQorKysg a2Vybi92ZnNfc3Vici5jCTIwMDEvMDYvMDYgMDg6NTM6NDkNCkBAIC0xNzA3 LDEwICsxNzA3LDcgQEANCiAJfQ0KIA0KIAljYWNoZV9wdXJnZSh2cCk7DQot CWlmICh2cC0+dl92bmxvY2spIHsNCi0JCUZSRUUodnAtPnZfdm5sb2NrLCBN X1ZOT0RFKTsNCi0JCXZwLT52X3ZubG9jayA9IE5VTEw7DQotCX0NCisJdnAt PnZfdm5sb2NrID0gTlVMTDsNCiANCiAJaWYgKFZTSE9VTERGUkVFKHZwKSkN CiAJCXZmcmVlKHZwKTsNCkluZGV4OiBuZnMvbmZzX25vZGUuYw0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5 cy9uZnMvbmZzX25vZGUuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMzYu Mi4xDQpkaWZmIC11IC1yMS4zNi4yLjEgbmZzX25vZGUuYw0KLS0tIG5mcy9u ZnNfbm9kZS5jCTIwMDEvMDMvMjEgMTA6NTA6NTkJMS4zNi4yLjENCisrKyBu ZnMvbmZzX25vZGUuYwkyMDAxLzA2LzA2IDA4OjUzOjQ5DQpAQCAtMTc1LDYg KzE3NSw3IEBADQogCWJjb3B5KChjYWRkcl90KWZocCwgKGNhZGRyX3QpbnAt Pm5fZmhwLCBmaHNpemUpOw0KIAlucC0+bl9maHNpemUgPSBmaHNpemU7DQog CWxvY2tpbml0KCZucC0+bl9yc2xvY2ssIFBWRlMgfCByc2ZsYWdzLCAibmZy c2xrIiwgMCwgTEtfTk9QQVVTRSk7DQorCWxvY2tpbml0KCZucC0+bl9sb2Nr LCBQVkZTLCAibmZzbmxrIiwgMCwgTEtfTk9QQVVTRSk7DQogCSpucHAgPSBu cDsNCiANCiAJaWYgKG5mc19ub2RlX2hhc2hfbG9jayA8IDApDQpJbmRleDog bmZzL25mc192bm9wcy5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1Mg ZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL25mcy9uZnNfdm5vcHMuYyx2DQpy ZXRyaWV2aW5nIHJldmlzaW9uIDEuMTUwLjIuMg0KZGlmZiAtdSAtcjEuMTUw LjIuMiBuZnNfdm5vcHMuYw0KLS0tIG5mcy9uZnNfdm5vcHMuYwkyMDAxLzAz LzAyIDE2OjQ1OjEyCTEuMTUwLjIuMg0KKysrIG5mcy9uZnNfdm5vcHMuYwky MDAxLzA2LzA2IDA4OjUzOjQ5DQpAQCAtMTQ5LDYgKzE0OSw3IEBADQogCXsg JnZvcF9nZXRwYWdlc19kZXNjLAkJKHZvcF90ICopIG5mc19nZXRwYWdlcyB9 LA0KIAl7ICZ2b3BfcHV0cGFnZXNfZGVzYywJCSh2b3BfdCAqKSBuZnNfcHV0 cGFnZXMgfSwNCiAJeyAmdm9wX2luYWN0aXZlX2Rlc2MsCQkodm9wX3QgKikg bmZzX2luYWN0aXZlIH0sDQorCXsgJnZvcF9pc2xvY2tlZF9kZXNjLAkJKHZv cF90ICopIHZvcF9zdGRpc2xvY2tlZCB9LA0KIAl7ICZ2b3BfbGVhc2VfZGVz YywJCSh2b3BfdCAqKSB2b3BfbnVsbCB9LA0KIAl7ICZ2b3BfbGlua19kZXNj LAkJKHZvcF90ICopIG5mc19saW5rIH0sDQogCXsgJnZvcF9sb2NrX2Rlc2Ms CQkodm9wX3QgKikgdm9wX3NoYXJlZGxvY2sgfSwNCkBAIC0xNjksNiArMTcw LDcgQEANCiAJeyAmdm9wX3NldGF0dHJfZGVzYywJCSh2b3BfdCAqKSBuZnNf c2V0YXR0ciB9LA0KIAl7ICZ2b3Bfc3RyYXRlZ3lfZGVzYywJCSh2b3BfdCAq KSBuZnNfc3RyYXRlZ3kgfSwNCiAJeyAmdm9wX3N5bWxpbmtfZGVzYywJCSh2 b3BfdCAqKSBuZnNfc3ltbGluayB9LA0KKwl7ICZ2b3BfdW5sb2NrX2Rlc2Ms CQkodm9wX3QgKikgdm9wX3N0ZHVubG9jayB9LA0KIAl7ICZ2b3Bfd3JpdGVf ZGVzYywJCSh2b3BfdCAqKSBuZnNfd3JpdGUgfSwNCiAJeyBOVUxMLCBOVUxM IH0NCiB9Ow0KQEAgLTE4NywxMSArMTg5LDEzIEBADQogCXsgJnZvcF9mc3lu Y19kZXNjLAkJKHZvcF90ICopIG5mc19mc3luYyB9LA0KIAl7ICZ2b3BfZ2V0 YXR0cl9kZXNjLAkJKHZvcF90ICopIG5mc19nZXRhdHRyIH0sDQogCXsgJnZv cF9pbmFjdGl2ZV9kZXNjLAkJKHZvcF90ICopIG5mc19pbmFjdGl2ZSB9LA0K Kwl7ICZ2b3BfaXNsb2NrZWRfZGVzYywJCSh2b3BfdCAqKSB2b3Bfc3RkaXNs b2NrZWQgfSwNCiAJeyAmdm9wX2xvY2tfZGVzYywJCSh2b3BfdCAqKSB2b3Bf c2hhcmVkbG9jayB9LA0KIAl7ICZ2b3BfcHJpbnRfZGVzYywJCSh2b3BfdCAq KSBuZnNfcHJpbnQgfSwNCiAJeyAmdm9wX3JlYWRfZGVzYywJCSh2b3BfdCAq KSBuZnNzcGVjX3JlYWQgfSwNCiAJeyAmdm9wX3JlY2xhaW1fZGVzYywJCSh2 b3BfdCAqKSBuZnNfcmVjbGFpbSB9LA0KIAl7ICZ2b3Bfc2V0YXR0cl9kZXNj LAkJKHZvcF90ICopIG5mc19zZXRhdHRyIH0sDQorCXsgJnZvcF91bmxvY2tf ZGVzYywJCSh2b3BfdCAqKSB2b3Bfc3RkdW5sb2NrIH0sDQogCXsgJnZvcF93 cml0ZV9kZXNjLAkJKHZvcF90ICopIG5mc3NwZWNfd3JpdGUgfSwNCiAJeyBO VUxMLCBOVUxMIH0NCiB9Ow0KQEAgLTIwNywxMSArMjExLDEzIEBADQogCXsg JnZvcF9mc3luY19kZXNjLAkJKHZvcF90ICopIG5mc19mc3luYyB9LA0KIAl7 ICZ2b3BfZ2V0YXR0cl9kZXNjLAkJKHZvcF90ICopIG5mc19nZXRhdHRyIH0s DQogCXsgJnZvcF9pbmFjdGl2ZV9kZXNjLAkJKHZvcF90ICopIG5mc19pbmFj dGl2ZSB9LA0KKwl7ICZ2b3BfaXNsb2NrZWRfZGVzYywJCSh2b3BfdCAqKSB2 b3Bfc3RkaXNsb2NrZWQgfSwNCiAJeyAmdm9wX2xvY2tfZGVzYywJCSh2b3Bf dCAqKSB2b3Bfc2hhcmVkbG9jayB9LA0KIAl7ICZ2b3BfcHJpbnRfZGVzYywJ CSh2b3BfdCAqKSBuZnNfcHJpbnQgfSwNCiAJeyAmdm9wX3JlYWRfZGVzYywJ CSh2b3BfdCAqKSBuZnNmaWZvX3JlYWQgfSwNCiAJeyAmdm9wX3JlY2xhaW1f ZGVzYywJCSh2b3BfdCAqKSBuZnNfcmVjbGFpbSB9LA0KIAl7ICZ2b3Bfc2V0 YXR0cl9kZXNjLAkJKHZvcF90ICopIG5mc19zZXRhdHRyIH0sDQorCXsgJnZv cF91bmxvY2tfZGVzYywJCSh2b3BfdCAqKSB2b3Bfc3RkdW5sb2NrIH0sDQog CXsgJnZvcF93cml0ZV9kZXNjLAkJKHZvcF90ICopIG5mc2ZpZm9fd3JpdGUg fSwNCiAJeyBOVUxMLCBOVUxMIH0NCiB9Ow0KSW5kZXg6IG5mcy9uZnNub2Rl LmgNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9u Y3ZzL3NyYy9zeXMvbmZzL25mc25vZGUuaCx2DQpyZXRyaWV2aW5nIHJldmlz aW9uIDEuMzINCmRpZmYgLXUgLXIxLjMyIG5mc25vZGUuaA0KLS0tIG5mcy9u ZnNub2RlLmgJMTk5OS8xMi8yOSAwNDo1NDo1NQkxLjMyDQorKysgbmZzL25m c25vZGUuaAkyMDAxLzA2LzA2IDA4OjUzOjQ5DQpAQCAtODYsNiArODYsNyBA QA0KICAqICAgICBiZSB3ZWxsIGFsaWduZWQgYW5kLCB0aGVyZWZvcmUsIHRp Z2h0bHkgcGFja2VkLg0KICAqLw0KIHN0cnVjdCBuZnNub2RlIHsNCisJc3Ry dWN0IGxvY2sJCW5fbG9jazsNCiAJTElTVF9FTlRSWShuZnNub2RlKQluX2hh c2g7CQkvKiBIYXNoIGNoYWluICovDQogCUNJUkNMRVFfRU5UUlkobmZzbm9k ZSkJbl90aW1lcjsJLyogTnFuZnMgdGltZXIgY2hhaW4gKi8NCiAJdV9xdWFk X3QJCW5fc2l6ZTsJCS8qIEN1cnJlbnQgc2l6ZSBvZiBmaWxlICovDQpJbmRl eDogbWlzY2ZzL251bGxmcy9udWxsLmgNCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMvbWlzY2ZzL251bGxm cy9BdHRpYy9udWxsLmgsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjExLjIu Mg0KZGlmZiAtdSAtcjEuMTEuMi4yIG51bGwuaA0KLS0tIG1pc2Nmcy9udWxs ZnMvbnVsbC5oCTIwMDAvMTAvMjUgMDQ6MjY6MzAJMS4xMS4yLjINCisrKyBt aXNjZnMvbnVsbGZzL251bGwuaAkyMDAxLzA2LzA2IDA4OjUzOjQ5DQpAQCAt NTIsNiArNTIsOCBAQA0KICAqIEEgY2FjaGUgb2Ygdm5vZGUgcmVmZXJlbmNl cw0KICAqLw0KIHN0cnVjdCBudWxsX25vZGUgew0KKwlzdHJ1Y3QgbG9jawkJ bnVsbF9sb2NrOwkvKiBMb2NrIGZvciB0aGlzIHZub2RlLiBNQkYgKi8NCisJ c3RydWN0IGxvY2sJCSpudWxsX3ZubG9jazsJLyogbG9jayBvZiBsb3dlciB2 bm9kZSBpbiB0aGUgc3RhY2sgKi8NCiAJTElTVF9FTlRSWShudWxsX25vZGUp CW51bGxfaGFzaDsJLyogSGFzaCBsaXN0ICovDQogCXN0cnVjdCB2bm9kZQkg ICAgICAgICpudWxsX2xvd2VydnA7CS8qIFZSRUZlZCBvbmNlICovDQogCXN0 cnVjdCB2bm9kZQkJKm51bGxfdm5vZGU7CS8qIEJhY2sgcG9pbnRlciAqLw0K SW5kZXg6IG1pc2Nmcy9udWxsZnMvbnVsbF9zdWJyLmMNCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMvbWlz Y2ZzL251bGxmcy9BdHRpYy9udWxsX3N1YnIuYyx2DQpyZXRyaWV2aW5nIHJl dmlzaW9uIDEuMjEuMi4zDQpkaWZmIC11IC1yMS4yMS4yLjMgbnVsbF9zdWJy LmMNCi0tLSBtaXNjZnMvbnVsbGZzL251bGxfc3Vici5jCTIwMDEvMDUvMzAg MDk6NDc6MDIJMS4yMS4yLjMNCisrKyBtaXNjZnMvbnVsbGZzL251bGxfc3Vi ci5jCTIwMDEvMDYvMDYgMDg6NTM6NDkNCkBAIC0xMzAsMTAgKzEzMCwxMSBA QA0KIAkJCSAqIHN0dWZmLCBidXQgd2UgZG9uJ3Qgd2FudCB0byBsb2NrDQog CQkJICogdGhlIGxvd2VyIG5vZGUuDQogCQkJICovDQotCQkJaWYgKHZnZXQo dnAsIDAsIHApKSB7DQorCQkJaWYgKHZnZXQodnAsIExLX0VYQ0xVU0lWRSB8 IExLX0NBTlJFQ1VSU0UsIHApKSB7DQogCQkJCXByaW50ZiAoIm51bGxfbm9k ZV9maW5kOiB2Z2V0IGZhaWxlZC5cbiIpOw0KIAkJCQlnb3RvIGxvb3A7DQot CQkJfTsNCisJCQl9DQorCQkJVk9QX1VOTE9DSyhsb3dlcnZwLCAwLCBwKTsN CiAJCQlyZXR1cm4gKHZwKTsNCiAJCX0NCiAJfQ0KQEAgLTE3Niw2ICsxNzcs NyBAQA0KIAl2cCA9ICp2cHA7DQogDQogCXZwLT52X3R5cGUgPSBsb3dlcnZw LT52X3R5cGU7DQorCWxvY2tpbml0KCZ4cC0+bnVsbF9sb2NrLCBQSU5PRCwg Im51bGxub2RlIiwgMCwgTEtfQ0FOUkVDVVJTRSk7DQogCXhwLT5udWxsX3Zu b2RlID0gdnA7DQogCXZwLT52X2RhdGEgPSB4cDsNCiAJeHAtPm51bGxfbG93 ZXJ2cCA9IGxvd2VydnA7DQpAQCAtMTkyLDkgKzE5NCwyNCBAQA0KIAkJdnJl bGUodnApOw0KIAkJKnZwcCA9IG90aGVydnA7DQogCQlyZXR1cm4gMDsNCi0J fTsNCi0JVlJFRihsb3dlcnZwKTsgICAvKiBFeHRyYSBWUkVGIHdpbGwgYmUg dnJlbGUnZCBpbiBudWxsX25vZGVfY3JlYXRlICovDQorCX0NCisNCisJLyoN CisJICogRnJvbSBOZXRCU0Q6DQorCSAqIE5vdyBsb2NrIHRoZSBuZXcgbm9k ZS4gV2UgcmVseSBvbiB0aGUgZmFjdCB0aGF0IHdlIHdlcmUgcGFzc2VkDQor CSAqIGEgbG9ja2VkIHZub2RlLiBJZiB0aGUgbG93ZXIgbm9kZSBpcyBleHBv cnRpbmcgYSBzdHJ1Y3QgbG9jaw0KKwkgKiAodl92bmxvY2sgIT0gTlVMTCkg dGhlbiB3ZSBqdXN0IHNldCB0aGUgdXBwZXIgdl92bmxvY2sgdG8gdGhlDQor CSAqIGxvd2VyIG9uZSwgYW5kIGJvdGggYXJlIG5vdyBsb2NrZWQuIElmIHRo ZSBsb3dlciBub2RlIGlzIGV4cG9ydGluZw0KKwkgKiBOVUxMLCB0aGVuIHdl IGNvcHkgdGhhdCB1cCBhbmQgbWFudWFsbHkgbG9jayB0aGUgbmV3IHZub2Rl Lg0KKwkgKi8NCisNCiAJbG9ja21ncigmbnVsbF9oYXNobG9jaywgTEtfRVhD TFVTSVZFLCBOVUxMLCBwKTsNCisJdnAtPnZfdm5sb2NrID0gbG93ZXJ2cC0+ dl92bmxvY2s7DQorCWVycm9yID0gVk9QX0xPQ0sodnAsIExLX0VYQ0xVU0lW RSB8IExLX1RISVNMQVlFUiwgcCk7DQorCWlmIChlcnJvcikNCisJCXBhbmlj KCJudWxsX25vZGVfYWxsb2M6IGNhbid0IGxvY2sgbmV3IHZub2RlXG4iKTsN CisNCisJVlJFRihsb3dlcnZwKTsNCiAJaGQgPSBOVUxMX05IQVNIKGxvd2Vy dnApOw0KIAlMSVNUX0lOU0VSVF9IRUFEKGhkLCB4cCwgbnVsbF9oYXNoKTsN CiAJbG9ja21ncigmbnVsbF9oYXNobG9jaywgTEtfUkVMRUFTRSwgTlVMTCwg cCk7DQpAQCAtMjIxLDEwICsyMzgsMTAgQEANCiAJCSAqIG51bGxfbm9kZV9m aW5kIGhhcyB0YWtlbiBhbm90aGVyIHJlZmVyZW5jZQ0KIAkJICogdG8gdGhl IGFsaWFzIHZub2RlLg0KIAkJICovDQorCQl2cmVsZShsb3dlcnZwKTsNCiAj aWZkZWYgTlVMTEZTX0RFQlVHDQogCQl2cHJpbnQoIm51bGxfbm9kZV9jcmVh dGU6IGV4aXN0cyIsIGFsaWFzdnApOw0KICNlbmRpZg0KLQkJLyogVlJFRihh bGlhc3ZwKTsgLS0tIGRvbmUgaW4gbnVsbF9ub2RlX2ZpbmQgKi8NCiAJfSBl bHNlIHsNCiAJCWludCBlcnJvcjsNCiANCkBAIC0yNDQsOCArMjYxLDYgQEAN CiAJCSAqIGFsaWFzdnAgaXMgYWxyZWFkeSBWUkVGJ2QgYnkgZ2V0bmV3dm5v ZGUoKQ0KIAkJICovDQogCX0NCi0NCi0JdnJlbGUobG93ZXJ2cCk7DQogDQog I2lmZGVmIERJQUdOT1NUSUMNCiAJaWYgKGxvd2VydnAtPnZfdXNlY291bnQg PCAxKSB7DQpJbmRleDogbWlzY2ZzL251bGxmcy9udWxsX3Zub3BzLmMNCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3Ny Yy9zeXMvbWlzY2ZzL251bGxmcy9BdHRpYy9udWxsX3Zub3BzLmMsdg0KcmV0 cmlldmluZyByZXZpc2lvbiAxLjM4LjIuNA0KZGlmZiAtdSAtcjEuMzguMi40 IG51bGxfdm5vcHMuYw0KLS0tIG1pc2Nmcy9udWxsZnMvbnVsbF92bm9wcy5j CTIwMDEvMDUvMzAgMDk6NDc6MDIJMS4zOC4yLjQNCisrKyBtaXNjZnMvbnVs bGZzL251bGxfdm5vcHMuYwkyMDAxLzA2LzA2IDA4OjUzOjQ5DQpAQCAtMTk1 LDYgKzE5NSw3IEBADQogc3RhdGljIGludAludWxsX2dldGF0dHIoc3RydWN0 IHZvcF9nZXRhdHRyX2FyZ3MgKmFwKTsNCiBzdGF0aWMgaW50CW51bGxfZ2V0 dm9iamVjdChzdHJ1Y3Qgdm9wX2dldHZvYmplY3RfYXJncyAqYXApOw0KIHN0 YXRpYyBpbnQJbnVsbF9pbmFjdGl2ZShzdHJ1Y3Qgdm9wX2luYWN0aXZlX2Fy Z3MgKmFwKTsNCitzdGF0aWMgaW50CW51bGxfaXNsb2NrZWQoc3RydWN0IHZv cF9pc2xvY2tlZF9hcmdzICphcCk7DQogc3RhdGljIGludAludWxsX2xvY2so c3RydWN0IHZvcF9sb2NrX2FyZ3MgKmFwKTsNCiBzdGF0aWMgaW50CW51bGxf bG9va3VwKHN0cnVjdCB2b3BfbG9va3VwX2FyZ3MgKmFwKTsNCiBzdGF0aWMg aW50CW51bGxfb3BlbihzdHJ1Y3Qgdm9wX29wZW5fYXJncyAqYXApOw0KQEAg LTM1OSw0NCArMzYwLDQzIEBADQogCX0gKi8gKmFwOw0KIHsNCiAJc3RydWN0 IGNvbXBvbmVudG5hbWUgKmNucCA9IGFwLT5hX2NucDsNCisJc3RydWN0IHZu b2RlICpkdnAgPSBhcC0+YV9kdnA7DQogCXN0cnVjdCBwcm9jICpwID0gY25w LT5jbl9wcm9jOw0KIAlpbnQgZmxhZ3MgPSBjbnAtPmNuX2ZsYWdzOw0KLQlz dHJ1Y3Qgdm9wX2xvY2tfYXJncyBsb2NrYXJnczsNCi0Jc3RydWN0IHZvcF91 bmxvY2tfYXJncyB1bmxvY2thcmdzOw0KLQlzdHJ1Y3Qgdm5vZGUgKmR2cCwg KnZwOw0KKwlzdHJ1Y3Qgdm5vZGUgKnZwLCAqbGR2cCwgKmx2cDsNCiAJaW50 IGVycm9yOw0KIA0KLQlpZiAoKGZsYWdzICYgSVNMQVNUQ04pICYmIChhcC0+ YV9kdnAtPnZfbW91bnQtPm1udF9mbGFnICYgTU5UX1JET05MWSkgJiYNCisJ aWYgKChmbGFncyAmIElTTEFTVENOKSAmJiAoZHZwLT52X21vdW50LT5tbnRf ZmxhZyAmIE1OVF9SRE9OTFkpICYmDQogCSAgICAoY25wLT5jbl9uYW1laW9w ID09IERFTEVURSB8fCBjbnAtPmNuX25hbWVpb3AgPT0gUkVOQU1FKSkNCiAJ CXJldHVybiAoRVJPRlMpOw0KLQllcnJvciA9IG51bGxfYnlwYXNzKChzdHJ1 Y3Qgdm9wX2dlbmVyaWNfYXJncyAqKWFwKTsNCisJLyoNCisJICogQWx0aG91 Z2ggaXQgaXMgcG9zc2libGUgdG8gY2FsbCBudWxsX2J5cGFzcygpLCB3ZSds bCBkbw0KKwkgKiBhIGRpcmVjdCBjYWxsIHRvIHJlZHVjZSBvdmVyaGVhZA0K KwkgKi8NCisJbGR2cCA9IE5VTExWUFRPTE9XRVJWUChkdnApOw0KKwl2cCA9 IGx2cCA9IE5VTEw7DQorCWVycm9yID0gVk9QX0xPT0tVUChsZHZwLCAmbHZw LCBjbnApOw0KIAlpZiAoZXJyb3IgPT0gRUpVU1RSRVRVUk4gJiYgKGZsYWdz ICYgSVNMQVNUQ04pICYmDQotCSAgICAoYXAtPmFfZHZwLT52X21vdW50LT5t bnRfZmxhZyAmIE1OVF9SRE9OTFkpICYmDQorCSAgICAoZHZwLT52X21vdW50 LT5tbnRfZmxhZyAmIE1OVF9SRE9OTFkpICYmDQogCSAgICAoY25wLT5jbl9u YW1laW9wID09IENSRUFURSB8fCBjbnAtPmNuX25hbWVpb3AgPT0gUkVOQU1F KSkNCiAJCWVycm9yID0gRVJPRlM7DQorDQogCS8qDQotCSAqIFdlIG11c3Qg ZG8gdGhlIHNhbWUgbG9ja2luZyBhbmQgdW5sb2NraW5nIGF0IHRoaXMgbGF5 ZXIgYXMgDQotCSAqIGlzIGRvbmUgaW4gdGhlIGxheWVycyBiZWxvdyB1cy4g V2UgY291bGQgZmlndXJlIHRoaXMgb3V0IA0KLQkgKiBiYXNlZCBvbiB0aGUg ZXJyb3IgcmV0dXJuIGFuZCB0aGUgTEFTVENOLCBMT0NLUEFSRU5ULCBhbmQN Ci0JICogTE9DS0xFQUYgZmxhZ3MuIEhvd2V2ZXIsIGl0IGlzIG1vcmUgZXhw aWRpZW50IHRvIGp1c3QgZmluZCANCi0JICogb3V0IHRoZSBzdGF0ZSBvZiB0 aGUgbG93ZXIgbGV2ZWwgdm5vZGVzIGFuZCBzZXQgb3VycyB0byB0aGUNCi0J ICogc2FtZSBzdGF0ZS4NCisJICogUmVseSBvbmx5IG9uIHRoZSBQRElSVU5M T0NLIGZsYWcgd2hpY2ggc2hvdWxkIGJlIGNhcmVmdWxseQ0KKwkgKiB0cmFj a2VkIGJ5IHVuZGVybHlpbmcgZmlsZXN5c3RlbS4NCiAJICovDQotCWR2cCA9 IGFwLT5hX2R2cDsNCi0JdnAgPSAqYXAtPmFfdnBwOw0KLQlpZiAoZHZwID09 IHZwKQ0KLQkJcmV0dXJuIChlcnJvcik7DQotCWlmICghVk9QX0lTTE9DS0VE KGR2cCwgTlVMTCkpIHsNCi0JCXVubG9ja2FyZ3MuYV92cCA9IGR2cDsNCi0J CXVubG9ja2FyZ3MuYV9mbGFncyA9IDA7DQotCQl1bmxvY2thcmdzLmFfcCA9 IHA7DQotCQl2b3Bfbm91bmxvY2soJnVubG9ja2FyZ3MpOw0KLQl9DQotCWlm ICh2cCAhPSBOVUxMVlAgJiYgVk9QX0lTTE9DS0VEKHZwLCBOVUxMKSkgew0K LQkJbG9ja2FyZ3MuYV92cCA9IHZwOw0KLQkJbG9ja2FyZ3MuYV9mbGFncyA9 IExLX1NIQVJFRDsNCi0JCWxvY2thcmdzLmFfcCA9IHA7DQotCQl2b3Bfbm9s b2NrKCZsb2NrYXJncyk7DQorCWlmIChjbnAtPmNuX2ZsYWdzICYgUERJUlVO TE9DSykNCisJCVZPUF9VTkxPQ0soZHZwLCBMS19USElTTEFZRVIsIHApOw0K KwlpZiAoKGVycm9yID09IDAgfHwgZXJyb3IgPT0gRUpVU1RSRVRVUk4pICYm IGx2cCAhPSBOVUxMKSB7DQorCQlpZiAobGR2cCA9PSBsdnApIHsNCisJCQkq YXAtPmFfdnBwID0gZHZwOw0KKwkJCVZSRUYoZHZwKTsNCisJCQl2cmVsZShs dnApOw0KKwkJfSBlbHNlIHsNCisJCQllcnJvciA9IG51bGxfbm9kZV9jcmVh dGUoZHZwLT52X21vdW50LCBsdnAsICZ2cCk7DQorCQkJaWYgKGVycm9yID09 IDApDQorCQkJCSphcC0+YV92cHAgPSB2cDsNCisJCX0NCiAJfQ0KIAlyZXR1 cm4gKGVycm9yKTsNCiB9DQpAQCAtNDY0LDYgKzQ2NCw4IEBADQogDQogCWlm ICgoZXJyb3IgPSBudWxsX2J5cGFzcygoc3RydWN0IHZvcF9nZW5lcmljX2Fy Z3MgKilhcCkpICE9IDApDQogCQlyZXR1cm4gKGVycm9yKTsNCisNCisJYXAt PmFfdmFwLT52YV9mc2lkID0gYXAtPmFfdnAtPnZfbW91bnQtPm1udF9zdGF0 LmZfZnNpZC52YWxbMF07DQogCXJldHVybiAoMCk7DQogfQ0KIA0KQEAgLTU3 NSwxMiArNTc3LDY0IEBADQogCQlzdHJ1Y3QgcHJvYyAqYV9wOw0KIAl9ICov ICphcDsNCiB7DQorCXN0cnVjdCB2bm9kZSAqdnAgPSBhcC0+YV92cDsNCisJ aW50IGZsYWdzID0gYXAtPmFfZmxhZ3M7DQorCXN0cnVjdCBwcm9jICpwID0g YXAtPmFfcDsNCisJc3RydWN0IG51bGxfbm9kZSAqbnAgPSBWVE9OVUxMKHZw KTsNCisJc3RydWN0IHZub2RlICpsdnA7DQorCWludCBlcnJvcjsNCiANCi0J dm9wX25vbG9jayhhcCk7DQotCWlmICgoYXAtPmFfZmxhZ3MgJiBMS19UWVBF X01BU0spID09IExLX0RSQUlOKQ0KLQkJcmV0dXJuICgwKTsNCi0JYXAtPmFf ZmxhZ3MgJj0gfkxLX0lOVEVSTE9DSzsNCi0JcmV0dXJuIChudWxsX2J5cGFz cygoc3RydWN0IHZvcF9nZW5lcmljX2FyZ3MgKilhcCkpOw0KKwlpZiAoZmxh Z3MgJiBMS19USElTTEFZRVIpIHsNCisJCWlmICh2cC0+dl92bmxvY2sgIT0g TlVMTCkNCisJCQlyZXR1cm4gMDsJLyogbG9jayBpcyBzaGFyZWQgYWNyb3Nz IGxheWVycyAqLw0KKwkJZXJyb3IgPSBsb2NrbWdyKCZucC0+bnVsbF9sb2Nr LCBmbGFncyAmIH5MS19USElTTEFZRVIsDQorCQkgICAgJnZwLT52X2ludGVy bG9jaywgcCk7DQorCQlyZXR1cm4gKGVycm9yKTsNCisJfQ0KKw0KKwlpZiAo dnAtPnZfdm5sb2NrICE9IE5VTEwpIHsNCisJCS8qDQorCQkgKiBUaGUgbG93 ZXIgbGV2ZWwgaGFzIGV4cG9ydGVkIGEgc3RydWN0IGxvY2sgdG8gdXMuIFVz ZQ0KKwkJICogaXQgc28gdGhhdCBhbGwgdm5vZGVzIGluIHRoZSBzdGFjayBs b2NrIGFuZCB1bmxvY2sNCisJCSAqIHNpbXVsdGFuZW91c2x5LiBOb3RlOiB3 ZSBkb24ndCBEUkFJTiB0aGUgbG9jayBhcyBEUkFJTg0KKwkJICogZGVjb21t aXNzaW9ucyB0aGUgbG9jayAtIGp1c3QgYmVjYXVzZSBvdXIgdm5vZGUgaXMN CisJCSAqIGdvaW5nIGF3YXkgZG9lc24ndCBtZWFuIHRoZSBzdHJ1Y3QgbG9j ayBiZWxvdyB1cyBpcy4NCisJCSAqIExLX0VYQ0xVU0lWRSBpcyBmaW5lLg0K KwkJICovDQorCQlpZiAoKGZsYWdzICYgTEtfVFlQRV9NQVNLKSA9PSBMS19E UkFJTikgew0KKwkJCU5VTExGU0RFQlVHKCJudWxsX2xvY2s6IGF2b2lkaW5n IExLX0RSQUlOXG4iKTsNCisJCQlyZXR1cm4obG9ja21ncih2cC0+dl92bmxv Y2ssDQorCQkJCShmbGFncyAmIH5MS19UWVBFX01BU0spIHwgTEtfRVhDTFVT SVZFLA0KKwkJCQkmdnAtPnZfaW50ZXJsb2NrLCBwKSk7DQorCQl9DQorCQly ZXR1cm4obG9ja21ncih2cC0+dl92bmxvY2ssIGZsYWdzLCAmdnAtPnZfaW50 ZXJsb2NrLCBwKSk7DQorCX0NCisJLyoNCisJICogVG8gcHJldmVudCByYWNl IGNvbmRpdGlvbnMgaW52b2x2aW5nIGRvaW5nIGEgbG9va3VwDQorCSAqIG9u ICIuLiIsIHdlIGhhdmUgdG8gbG9jayB0aGUgbG93ZXIgbm9kZSwgdGhlbiBs b2NrIG91cg0KKwkgKiBub2RlLiBNb3N0IG9mIHRoZSB0aW1lIGl0IHdvbid0 IG1hdHRlciB0aGF0IHdlIGxvY2sgb3VyDQorCSAqIG5vZGUgKGFzIGFueSBs b2NraW5nIHdvdWxkIG5lZWQgdGhlIGxvd2VyIG9uZSBsb2NrZWQNCisJICog Zmlyc3QpLiBCdXQgd2UgY2FuIExLX0RSQUlOIHRoZSB1cHBlciBsb2NrIGFz IGEgc3RlcA0KKwkgKiB0b3dhcmRzIGRlY29taXNzaW9uaW5nIGl0Lg0KKwkg Ki8NCisJbHZwID0gTlVMTFZQVE9MT1dFUlZQKHZwKTsNCisJaWYgKGx2cCA9 PSBOVUxMKQ0KKwkJcmV0dXJuIChsb2NrbWdyKCZucC0+bnVsbF9sb2NrLCBm bGFncywgJnZwLT52X2ludGVybG9jaywgcCkpOw0KKwlpZiAoZmxhZ3MgJiBM S19JTlRFUkxPQ0spIHsNCisJCVZJX1VOTE9DSyh2cCk7DQorCQlmbGFncyAm PSB+TEtfSU5URVJMT0NLOw0KKwl9DQorCWlmICgoZmxhZ3MgJiBMS19UWVBF X01BU0spID09IExLX0RSQUlOKSB7DQorCQllcnJvciA9IFZPUF9MT0NLKGx2 cCwNCisJCQkoZmxhZ3MgJiB+TEtfVFlQRV9NQVNLKSB8IExLX0VYQ0xVU0lW RSwgcCk7DQorCX0gZWxzZQ0KKwkJZXJyb3IgPSBWT1BfTE9DSyhsdnAsIGZs YWdzLCBwKTsNCisJaWYgKGVycm9yKQ0KKwkJcmV0dXJuIChlcnJvcik7DQor CWVycm9yID0gbG9ja21ncigmbnAtPm51bGxfbG9jaywgZmxhZ3MsICZ2cC0+ dl9pbnRlcmxvY2ssIHApOw0KKwlpZiAoZXJyb3IpDQorCQlWT1BfVU5MT0NL KGx2cCwgMCwgcCk7DQorCXJldHVybiAoZXJyb3IpOw0KIH0NCiANCiAvKg0K QEAgLTU5NiwxMiArNjUwLDU2IEBADQogCQlzdHJ1Y3QgcHJvYyAqYV9wOw0K IAl9ICovICphcDsNCiB7DQotCXZvcF9ub3VubG9jayhhcCk7DQotCWFwLT5h X2ZsYWdzICY9IH5MS19JTlRFUkxPQ0s7DQotCXJldHVybiAobnVsbF9ieXBh c3MoKHN0cnVjdCB2b3BfZ2VuZXJpY19hcmdzICopYXApKTsNCisJc3RydWN0 IHZub2RlICp2cCA9IGFwLT5hX3ZwOw0KKwlpbnQgZmxhZ3MgPSBhcC0+YV9m bGFnczsNCisJc3RydWN0IHByb2MgKnAgPSBhcC0+YV9wOw0KKwlzdHJ1Y3Qg bnVsbF9ub2RlICpucCA9IFZUT05VTEwodnApOw0KKwlzdHJ1Y3Qgdm5vZGUg Kmx2cDsNCisNCisJaWYgKHZwLT52X3ZubG9jayAhPSBOVUxMKSB7DQorCQlp ZiAoZmxhZ3MgJiBMS19USElTTEFZRVIpDQorCQkJcmV0dXJuIDA7CS8qIHRo ZSBsb2NrIGlzIHNoYXJlZCBhY3Jvc3MgbGF5ZXJzICovDQorCQlmbGFncyAm PSB+TEtfVEhJU0xBWUVSOw0KKwkJcmV0dXJuIChsb2NrbWdyKHZwLT52X3Zu bG9jaywgZmxhZ3MgfCBMS19SRUxFQVNFLA0KKwkJCSZ2cC0+dl9pbnRlcmxv Y2ssIHApKTsNCisJfQ0KKwlsdnAgPSBOVUxMVlBUT0xPV0VSVlAodnApOw0K KwlpZiAobHZwID09IE5VTEwpDQorCQlyZXR1cm4gKGxvY2ttZ3IoJm5wLT5u dWxsX2xvY2ssIGZsYWdzIHwgTEtfUkVMRUFTRSwgJnZwLT52X2ludGVybG9j aywgcCkpOw0KKwlpZiAoKGZsYWdzICYgTEtfVEhJU0xBWUVSKSA9PSAwKSB7 DQorCQlpZiAoZmxhZ3MgJiBMS19JTlRFUkxPQ0spIHsNCisJCQlWSV9VTkxP Q0sodnApOw0KKwkJCWZsYWdzICY9IH5MS19JTlRFUkxPQ0s7DQorCQl9DQor CQlWT1BfVU5MT0NLKGx2cCwgZmxhZ3MsIHApOw0KKwl9IGVsc2UNCisJCWZs YWdzICY9IH5MS19USElTTEFZRVI7DQorCWFwLT5hX2ZsYWdzID0gZmxhZ3M7 DQorCXJldHVybiAobG9ja21ncigmbnAtPm51bGxfbG9jaywgZmxhZ3MgfCBM S19SRUxFQVNFLCAmdnAtPnZfaW50ZXJsb2NrLCBwKSk7DQogfQ0KIA0KIHN0 YXRpYyBpbnQNCitudWxsX2lzbG9ja2VkKGFwKQ0KKwlzdHJ1Y3Qgdm9wX2lz bG9ja2VkX2FyZ3MgLyogew0KKwkJc3RydWN0IHZub2RlICphX3ZwOw0KKwkJ c3RydWN0IHByb2MgKmFfcDsNCisJfSAqLyAqYXA7DQorew0KKwlzdHJ1Y3Qg dm5vZGUgKnZwID0gYXAtPmFfdnA7DQorCXN0cnVjdCBwcm9jICpwID0gYXAt PmFfcDsNCisNCisJaWYgKHZwLT52X3ZubG9jayAhPSBOVUxMKQ0KKwkJcmV0 dXJuIChsb2Nrc3RhdHVzKHZwLT52X3ZubG9jaywgcCkpOw0KKwlyZXR1cm4g KGxvY2tzdGF0dXMoJlZUT05VTEwodnApLT5udWxsX2xvY2ssIHApKTsNCit9 DQorDQorDQorLyoNCisgKiBUaGVyZSBpcyBubyB3YXkgdG8gdGVsbCB0aGF0 IHNvbWVvbmUgaXNzdWVkIHJlbW92ZS9ybWRpciBvcGVyYXRpb24NCisgKiBv biB0aGUgdW5kZXJseWluZyBmaWxlc3lzdGVtLiBGb3Igbm93IHdlIGp1c3Qg aGF2ZSB0byByZWxlYXNlIGxvd2V2cnANCisgKiBhcyBzb29uIGFzIHBvc3Np YmxlLg0KKyAqLw0KK3N0YXRpYyBpbnQNCiBudWxsX2luYWN0aXZlKGFwKQ0K IAlzdHJ1Y3Qgdm9wX2luYWN0aXZlX2FyZ3MgLyogew0KIAkJc3RydWN0IHZu b2RlICphX3ZwOw0KQEAgLTYwOSwyNyArNzA3LDM0IEBADQogCX0gKi8gKmFw Ow0KIHsNCiAJc3RydWN0IHZub2RlICp2cCA9IGFwLT5hX3ZwOw0KKwlzdHJ1 Y3QgcHJvYyAqcCA9IGFwLT5hX3A7DQogCXN0cnVjdCBudWxsX25vZGUgKnhw ID0gVlRPTlVMTCh2cCk7DQogCXN0cnVjdCB2bm9kZSAqbG93ZXJ2cCA9IHhw LT5udWxsX2xvd2VydnA7DQorDQorCWxvY2ttZ3IoJm51bGxfaGFzaGxvY2ss IExLX0VYQ0xVU0lWRSwgTlVMTCwgcCk7DQorCUxJU1RfUkVNT1ZFKHhwLCBu dWxsX2hhc2gpOw0KKwlsb2NrbWdyKCZudWxsX2hhc2hsb2NrLCBMS19SRUxF QVNFLCBOVUxMLCBwKTsNCisNCisJeHAtPm51bGxfbG93ZXJ2cCA9IE5VTExW UDsNCisJaWYgKHZwLT52X3ZubG9jayAhPSBOVUxMKSB7DQorCQl2cC0+dl92 bmxvY2sgPSAmeHAtPm51bGxfbG9jazsJLyogd2Ugbm8gbG9uZ2VyIHNoYXJl IHRoZSBsb2NrICovDQorCX0gZWxzZQ0KKwkJVk9QX1VOTE9DSyh2cCwgTEtf VEhJU0xBWUVSLCBwKTsNCisNCisJdnB1dChsb3dlcnZwKTsNCiAJLyoNCi0J ICogRG8gbm90aGluZyAoYW5kIF9kb24ndF8gYnlwYXNzKS4NCi0JICogV2Fp dCB0byB2cmVsZSBsb3dlcnZwIHVudGlsIHJlY2xhaW0sDQotCSAqIHNvIHRo YXQgdW50aWwgdGhlbiBvdXIgbnVsbF9ub2RlIGlzIGluIHRoZQ0KLQkgKiBj YWNoZSBhbmQgcmV1c2FibGUuDQotCSAqIFdlIHN0aWxsIGhhdmUgdG8gdGVs bCB0aGUgbG93ZXIgbGF5ZXIgdGhlIHZub2RlDQotCSAqIGlzIG5vdyBpbmFj dGl2ZSB0aG91Z2guDQotCSAqDQotCSAqIE5FRURTV09SSzogU29tZWRheSwg Y29uc2lkZXIgaW5hY3RpdmUnaW5nDQotCSAqIHRoZSBsb3dlcnZwIGFuZCB0 aGVuIHRyeWluZyB0byByZWFjdGl2YXRlIGl0DQotCSAqIHdpdGggY2FwYWJp bGl0aWVzICh2X2lkKQ0KLQkgKiBsaWtlIHRoZXkgZG8gaW4gdGhlIG5hbWUg bG9va3VwIGNhY2hlIGNvZGUuDQotCSAqIFRoYXQncyB0b28gbXVjaCB3b3Jr IGZvciBub3cuDQorCSAqIE5vdyBpdCBpcyBzYWZlIHRvIGRyb3AgcmVmZXJl bmNlcyB0byB0aGUgbG93ZXIgdm5vZGUuDQorCSAqIFZPUF9JTkFDVElWRSgp IHdpbGwgYmUgY2FsbGVkIGJ5IHZyZWxlKCkgaWYgbmVjZXNzYXJ5Lg0KIAkg Ki8NCi0JVk9QX0lOQUNUSVZFKGxvd2VydnAsIGFwLT5hX3ApOw0KLQlWT1Bf VU5MT0NLKGFwLT5hX3ZwLCAwLCBhcC0+YV9wKTsNCisJdnJlbGUgKGxvd2Vy dnApOw0KKw0KIAlyZXR1cm4gKDApOw0KIH0NCiANCisvKg0KKyAqIFdlIGNh biBmcmVlIG1lbW9yeSBpbiBudWxsX2luYWN0aXZlLCBidXQgd2UgZG8gdGhp cw0KKyAqIGhlcmUuIChQb3NzaWJsZSB0byBndWFyZCB2cC0+dl9kYXRhIHRv IHBvaW50IHNvbWV3aGVyZSkNCisgKi8NCiBzdGF0aWMgaW50DQogbnVsbF9y ZWNsYWltKGFwKQ0KIAlzdHJ1Y3Qgdm9wX3JlY2xhaW1fYXJncyAvKiB7DQpA QCAtNjM4LDIyICs3NDMsMTEgQEANCiAJfSAqLyAqYXA7DQogew0KIAlzdHJ1 Y3Qgdm5vZGUgKnZwID0gYXAtPmFfdnA7DQotCXN0cnVjdCBwcm9jICpwID0g YXAtPmFfcDsNCi0Jc3RydWN0IG51bGxfbm9kZSAqeHAgPSBWVE9OVUxMKHZw KTsNCi0Jc3RydWN0IHZub2RlICpsb3dlcnZwID0geHAtPm51bGxfbG93ZXJ2 cDsNCisJdm9pZCAqdmRhdGEgPSB2cC0+dl9kYXRhOw0KIA0KLQkvKg0KLQkg KiBOb3RlOiBpbiB2b3BfcmVjbGFpbSwgdnAtPnZfb3AgPT0gZGVhZF92bm9k ZW9wX3AsDQotCSAqIHNvIHdlIGNhbid0IGNhbGwgVk9QcyBvbiBvdXJzZWxm Lg0KLQkgKi8NCi0JLyogQWZ0ZXIgdGhpcyBhc3NpZ25tZW50LCB0aGlzIG5v ZGUgd2lsbCBub3QgYmUgcmUtdXNlZC4gKi8NCi0JeHAtPm51bGxfbG93ZXJ2 cCA9IE5VTExWUDsNCi0JbG9ja21ncigmbnVsbF9oYXNobG9jaywgTEtfRVhD TFVTSVZFLCBOVUxMLCBwKTsNCi0JTElTVF9SRU1PVkUoeHAsIG51bGxfaGFz aCk7DQotCWxvY2ttZ3IoJm51bGxfaGFzaGxvY2ssIExLX1JFTEVBU0UsIE5V TEwsIHApOw0KIAl2cC0+dl9kYXRhID0gTlVMTDsNCi0JRlJFRSh4cCwgTV9O VUxMRlNOT0RFKTsNCi0JdnJlbGUgKGxvd2VydnApOw0KKwlGUkVFKHZkYXRh LCBNX05VTExGU05PREUpOw0KKw0KIAlyZXR1cm4gKDApOw0KIH0NCiANCkBA IC03MzMsNiArODI3LDcgQEANCiAJeyAmdm9wX2dldGF0dHJfZGVzYywJCSh2 b3BfdCAqKSBudWxsX2dldGF0dHIgfSwNCiAJeyAmdm9wX2dldHZvYmplY3Rf ZGVzYywJCSh2b3BfdCAqKSBudWxsX2dldHZvYmplY3QgfSwNCiAJeyAmdm9w X2luYWN0aXZlX2Rlc2MsCQkodm9wX3QgKikgbnVsbF9pbmFjdGl2ZSB9LA0K Kwl7ICZ2b3BfaXNsb2NrZWRfZGVzYywJCSh2b3BfdCAqKSBudWxsX2lzbG9j a2VkIH0sDQogCXsgJnZvcF9sb2NrX2Rlc2MsCQkodm9wX3QgKikgbnVsbF9s b2NrIH0sDQogCXsgJnZvcF9sb29rdXBfZGVzYywJCSh2b3BfdCAqKSBudWxs X2xvb2t1cCB9LA0KIAl7ICZ2b3Bfb3Blbl9kZXNjLAkJKHZvcF90ICopIG51 bGxfb3BlbiB9LA0KSW5kZXg6IHN5cy9sb2NrLmgNCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMvc3lzL2xv Y2suaCx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTcuMi4xDQpkaWZmIC11 IC1yMS4xNy4yLjEgbG9jay5oDQotLS0gc3lzL2xvY2suaAkyMDAwLzA5LzMw IDAyOjQ5OjM3CTEuMTcuMi4xDQorKysgc3lzL2xvY2suaAkyMDAxLzA2LzA2 IDA4OjUzOjQ5DQpAQCAtMTQxLDYgKzE0MSw3IEBADQogCQkJCSAgIGdldHRp bmcgbGtfaW50ZXJsb2NrICovDQogI2RlZmluZSBMS19SRVRSWQkweDAwMDIw MDAwIC8qIHZuX2xvY2s6IHJldHJ5IHVudGlsIGxvY2tlZCAqLw0KICNkZWZp bmUJTEtfTk9PQkoJMHgwMDA0MDAwMCAvKiB2Z2V0OiBkb24ndCBjcmVhdGUg b2JqZWN0ICovDQorI2RlZmluZQlMS19USElTTEFZRVIJMHgwMDA4MDAwMCAv KiB2bl9sb2NrOiBsb2NrL3VubG9jayBvbmx5IGN1cnJlbnQgbGF5ZXIgKi8N CiANCiAvKg0KICAqIEludGVybmFsIHN0YXRlIGZsYWdzIGNvcnJlc3BvbmRp bmcgdG8gbGtfc2hhcmVjb3VudCwgYW5kIGxrX3dhaXRjb3VudA0K --0-248198860-991820441=:61571-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Jun 6 9: 6:37 2001 Delivered-To: freebsd-fs@freebsd.org Received: from tx.citynet.net (tx.citynet.net [208.154.179.12]) by hub.freebsd.org (Postfix) with ESMTP id 4F12A37B406 for ; Wed, 6 Jun 2001 09:06:35 -0700 (PDT) (envelope-from jasonf@citynet.net) Received: from cleisthenes (63-145-134-196.citynet.net [63.145.134.196]) by tx.citynet.net (8.11.3/8.11.3=Outbound) with SMTP id f56G67A06949 for ; Wed, 6 Jun 2001 12:06:08 -0400 Message-ID: <002901c0eea2$d123c970$c486913f@cleisthenes> From: "Jason Francis" To: Subject: UFS fragmentation Date: Wed, 6 Jun 2001 12:07:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 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 I understand that UFS (FFS) is, by design, resistant to fragmentation. I would like to know exactly how this is accomplished. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Jun 6 10: 9:29 2001 Delivered-To: freebsd-fs@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-243.dsl.lsan03.pacbell.net [64.165.226.243]) by hub.freebsd.org (Postfix) with ESMTP id 24C7B37B401 for ; Wed, 6 Jun 2001 10:09:27 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id D4423671A4; Wed, 6 Jun 2001 10:09:26 -0700 (PDT) Date: Wed, 6 Jun 2001 10:09:26 -0700 From: Kris Kennaway To: Jason Francis Cc: freebsd-fs@FreeBSD.ORG Subject: Re: UFS fragmentation Message-ID: <20010606100926.C73917@xor.obsecurity.org> References: <002901c0eea2$d123c970$c486913f@cleisthenes> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="O5XBE6gyVG5Rl6Rj" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002901c0eea2$d123c970$c486913f@cleisthenes>; from jasonf@citynet.net on Wed, Jun 06, 2001 at 12:07:41PM -0400 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 --O5XBE6gyVG5Rl6Rj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jun 06, 2001 at 12:07:41PM -0400, Jason Francis wrote: > I understand that UFS (FFS) is, by design, resistant to fragmentation. I > would like to know exactly how this is accomplished. It's probably explained in _The Design & Implementation of the 4.4BSD Operating System_ Kris --O5XBE6gyVG5Rl6Rj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7HmPGWry0BWjoQKURAkmnAKDCu5cLm/6LsQxUpXEk5EjBka5JrACfW51o LsK/ipUKIaN/lTegEZwmo3Y= =vNK6 -----END PGP SIGNATURE----- --O5XBE6gyVG5Rl6Rj-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Jun 6 16:44:41 2001 Delivered-To: freebsd-fs@freebsd.org Received: from pericles.IPAustralia.gov.au (pericles.IPAustralia.gov.au [202.14.186.30]) by hub.freebsd.org (Postfix) with ESMTP id 0E72737B403; Wed, 6 Jun 2001 16:44:32 -0700 (PDT) (envelope-from carl@xena.ipaustralia.gov.au) Received: (from smap@localhost) by pericles.IPAustralia.gov.au (8.11.3/8.11.1) id f56NiKP70905; Thu, 7 Jun 2001 09:44:20 +1000 (EST) (envelope-from carl@xena.ipaustralia.gov.au) Received: from newton.aipo.gov.au(10.0.100.18) by pericles.IPAustralia.gov.au via smap (V2.1) id xma070890; Thu, 7 Jun 01 09:44:08 +1000 Received: from localhost (carl@localhost) by newton.aipo.gov.au (8.11.3/8.11.0) with ESMTP id f56Ni6567271; Thu, 7 Jun 2001 09:44:08 +1000 (EST) (envelope-from carl@xena.ipaustralia.gov.au) X-Authentication-Warning: newton.aipo.gov.au: carl owned process doing -bs Date: Thu, 7 Jun 2001 09:44:06 +1000 (EST) From: Carl Makin X-X-Sender: To: Boris Popov Cc: , Subject: Re: CFR: Fixes for nullfs in -stable In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Hi Boris, On Wed, 6 Jun 2001, Boris Popov wrote: > I've mostly merged improvements done to nullfs in the -current to > RELENG_4 branch. Operations on mmaped files were fixed before and this > patch focused on the proper vnode locking. Is "nullfs" used by mount_null? If so, how far do these patches go towards making mount_null usable? (I'm not aware of the status of nullfs in current). Carl. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Jun 7 0:38:25 2001 Delivered-To: freebsd-fs@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 87B2237B401; Thu, 7 Jun 2001 00:38:19 -0700 (PDT) (envelope-from bp@butya.kz) Received: by relay.butya.kz (Postfix, from userid 1000) id B92142862D; Thu, 7 Jun 2001 14:38:12 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 8D49C285E2; Thu, 7 Jun 2001 14:38:12 +0700 (ALMST) Date: Thu, 7 Jun 2001 14:38:12 +0700 (ALMST) From: Boris Popov To: Carl Makin Cc: stable@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: CFR: Fixes for nullfs in -stable In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Thu, 7 Jun 2001, Carl Makin wrote: > Is "nullfs" used by mount_null? If so, how far do these patches go > towards making mount_null usable? (I'm not aware of the status of nullfs > in current). Yes, mount_null command mounts nullfs. With these patches 'make world' completes successfully on the nullfs /usr mount. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Jun 7 14: 3:16 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by hub.freebsd.org (Postfix) with ESMTP id 33CEB37B401; Thu, 7 Jun 2001 14:03:08 -0700 (PDT) (envelope-from pwd@apple.com) Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id OAA27219; Thu, 7 Jun 2001 14:03:07 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 7 Jun 2001 14:03:07 -0700 Received: from thunder (thunder.apple.com [17.202.40.76]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id f57L37l26327; Thu, 7 Jun 2001 14:03:07 -0700 (PDT) Message-Id: <200106072103.f57L37l26327@scv2.apple.com> Date: Thu, 7 Jun 2001 14:03:06 -0700 Content-Type: text/plain; format=flowed; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v388) From: "Patrick W. Penzias Dirks" To: FreeBSD-FS@freebsd.org, FreeBSD-Arch@freebsd.org X-Mailer: Apple Mail (2.388) Content-Transfer-Encoding: 7bit Subject: Support for pivot_root-like system call? 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 Hi, I'm the filesystems tech lead in Apple's Mac OS X Core OS group. Prompted by the needs of, among others, virus protection software developers who want to be able to mount "on" the root directory to intercept ALL filesystem calls in the system, I'm contemplating implementation of a new system call in Mac OS X to do something like Linux's pivot_root system call: int pivot_root(const char *new_root, const char *put_old); (which basically installs "new_root" as the new "/" [root_vnode] in the system and transfers the current root directory to the pathname specified my "put_old") I'm not up on the latest discussions in the Linux world around this functionality (which I gather is pretty recent) and the Linux man page for pivot_root is deliberately vague about defining details of its semantics. There's no explicit guarantee that existing process's root vnode or current directory will or will not get switched, for instance. I thought some options might be appropriate to specify that kind of detail and I'm currently thinking of implementing a new switch_root(2): int switch_root(const char *new_root, const char *put_old, unsigned long flags); with the same basic functionality as pivot_root, and options to either insist on updating root and/or current directory for existing processes, possibly excluding system processes, for instance. I want to avoid implementing something that might for some reason clash horribly with either present FreeBSD designs or planned future developments. Any comments would be most welcome. Thanks in advance, -Pat Dirks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jun 8 2:10:44 2001 Delivered-To: freebsd-fs@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id A4ADB37B401; Fri, 8 Jun 2001 02:10:40 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.138.245.Dial1.SanJose1.Level3.net [209.245.138.245]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id CAA29987; Fri, 8 Jun 2001 02:10:38 -0700 (PDT) Message-ID: <3B2096AB.309B2D14@mindspring.com> Date: Fri, 08 Jun 2001 02:11:07 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Patrick W. Penzias Dirks" Cc: FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: Support for pivot_root-like system call? References: <200106072103.f57L37l26327@scv2.apple.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 "Patrick W. Penzias Dirks" wrote: > > Hi, > > I'm the filesystems tech lead in Apple's Mac OS X Core OS group. > Prompted by the needs of, among others, virus protection software > developers who want to be able to mount "on" the root directory to > intercept ALL filesystem calls in the system, I'm contemplating > implementation of a new system call in Mac OS X to do something like > Linux's pivot_root system call: > > int pivot_root(const char *new_root, const char *put_old); > > (which basically installs "new_root" as the new "/" [root_vnode] in > the system and transfers the current root directory to the pathname > specified my "put_old") It doesn't work in FreeBSD proper because of cache coherency bugs that have been around since 1995, but: mount -t nullfs / /put_old # or wherever mount -t / Would do what you want, I think. Really, the BSD way of doing this is to stack an FS with the feature you want on top of the one without the feature in it. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jun 8 5:27: 0 2001 Delivered-To: freebsd-fs@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by hub.freebsd.org (Postfix) with ESMTP id 5A88237B406; Fri, 8 Jun 2001 05:26:56 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id OAA63023; Fri, 8 Jun 2001 14:26:53 +0200 (CEST) (envelope-from assar) To: "Patrick W. Penzias Dirks" Cc: FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: Support for pivot_root-like system call? References: <200106072103.f57L37l26327@scv2.apple.com> From: Assar Westerlund Date: 08 Jun 2001 14:26:53 +0200 In-Reply-To: "Patrick W. Penzias Dirks"'s message of "Thu, 7 Jun 2001 14:03:06 -0700" Message-ID: <5lelsvtawi.fsf@assaris.sics.se> Lines: 16 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 "Patrick W. Penzias Dirks" writes: > I'm the filesystems tech lead in Apple's Mac OS X Core OS group. > Prompted by the needs of, among others, virus protection software > developers who want to be able to mount "on" the root directory to > intercept ALL filesystem calls in the system, I'm contemplating > implementation of a new system call in Mac OS X to do something like > Linux's pivot_root system call: > > int pivot_root(const char *new_root, const char *put_old); Could you explain to me/us how you would implement virus protection software (or something similiar), based on pivot_root? Is there any such stuff for linux that uses pivot_root? /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jun 8 6: 9:31 2001 Delivered-To: freebsd-fs@freebsd.org Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by hub.freebsd.org (Postfix) with ESMTP id 4D53D37B407; Fri, 8 Jun 2001 06:09:27 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 158M1s-000Jde-0W; Fri, 8 Jun 2001 14:10:20 +0100 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f58D8A724309; Fri, 8 Jun 2001 14:08:10 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Fri, 8 Jun 2001 14:08:10 +0100 (BST) From: Doug Rabson To: Assar Westerlund Cc: "Patrick W. Penzias Dirks" , , Subject: Re: Support for pivot_root-like system call? In-Reply-To: <5lelsvtawi.fsf@assaris.sics.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On 8 Jun 2001, Assar Westerlund wrote: > "Patrick W. Penzias Dirks" writes: > > I'm the filesystems tech lead in Apple's Mac OS X Core OS group. > > Prompted by the needs of, among others, virus protection software > > developers who want to be able to mount "on" the root directory to > > intercept ALL filesystem calls in the system, I'm contemplating > > implementation of a new system call in Mac OS X to do something like > > Linux's pivot_root system call: > > > > int pivot_root(const char *new_root, const char *put_old); > > Could you explain to me/us how you would implement virus protection > software (or something similiar), based on pivot_root? > > Is there any such stuff for linux that uses pivot_root? Musing about virus protection (not particularly about pivot_root), I guess the best way to intercept all attempts to manipulate files on a given fs would be to make the virus checker a stackable VFS layer. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jun 8 8:30:25 2001 Delivered-To: freebsd-fs@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 4EE7F37B40C; Fri, 8 Jun 2001 08:30:12 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f58FUBM58954; Fri, 8 Jun 2001 08:30:12 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id D7AF1380C; Fri, 8 Jun 2001 08:30:11 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: tlambert2@mindspring.com Cc: "Patrick W. Penzias Dirks" , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: Support for pivot_root-like system call? In-Reply-To: <3B2096AB.309B2D14@mindspring.com> Date: Fri, 08 Jun 2001 08:30:11 -0700 From: Peter Wemm Message-Id: <20010608153011.D7AF1380C@overcee.netplex.com.au> 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 Terry Lambert wrote: > "Patrick W. Penzias Dirks" wrote: > > > > Hi, > > > > I'm the filesystems tech lead in Apple's Mac OS X Core OS group. > > Prompted by the needs of, among others, virus protection software > > developers who want to be able to mount "on" the root directory to > > intercept ALL filesystem calls in the system, I'm contemplating > > implementation of a new system call in Mac OS X to do something like > > Linux's pivot_root system call: > > > > int pivot_root(const char *new_root, const char *put_old); > > > > (which basically installs "new_root" as the new "/" [root_vnode] in > > the system and transfers the current root directory to the pathname > > specified my "put_old") > > It doesn't work in FreeBSD proper because of cache coherency > bugs that have been around since 1995, but: > > mount -t nullfs / /put_old # or wherever > mount -t / > > Would do what you want, I think. Terry, the 'cache coherency' bugs have been fixed in -current for ~8 months now (September 2000). The infrastructure changes for this are subject to a call-for-review right now for a merge to 4.x. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jun 8 9:44: 7 2001 Delivered-To: freebsd-fs@freebsd.org Received: from phoenix.volant.org (dickson.phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id 2C3E637B403; Fri, 8 Jun 2001 09:44:02 -0700 (PDT) (envelope-from patl@Phoenix.Volant.ORG) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with esmtp (Exim 1.92 #8) id 158PMf-00040I-00; Fri, 8 Jun 2001 09:44:01 -0700 Received: from localhost (localhost [127.0.0.1]) by asimov.phoenix.volant.org (8.9.3+Sun/8.9.3) with SMTP id JAA10571; Fri, 8 Jun 2001 09:43:56 -0700 (PDT) From: patl@Phoenix.Volant.ORG Date: Fri, 8 Jun 2001 09:43:56 -0700 (PDT) Reply-To: patl@Phoenix.Volant.ORG Subject: Re: nullfs fixes [Was: Support for pivot_root-like system call?] To: Peter Wemm Cc: FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG In-Reply-To: <20010608153011.D7AF1380C@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 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 On 8-Jun-01 at 08:30, Peter Wemm (peter@wemm.org) wrote: > Terry, the 'cache coherency' bugs have been fixed in -current for ~8 > months now (September 2000). The infrastructure changes for this are > subject to a call-for-review right now for a merge to 4.x. This is -VERY- good news. I just have two questions: 1. Which currently broken filesystems in STABLE become usable with these fixes? 2. Do you have any wild-assed guess as to how long the approval and MFC are likely to take? (I.e., When might it be available in -STABLE) (I chose the word 'guess' carefully - I know better than to rely on any such prediction. Nevertheless, a ballpark estimate would help me decide whether to consider delaying a project I'm starting until those fixes are in.) Thanks, -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jun 8 10: 1:56 2001 Delivered-To: freebsd-fs@freebsd.org Received: from superconductor.rush.net (superconductor.rush.net [208.9.155.8]) by hub.freebsd.org (Postfix) with ESMTP id 2B29537B401; Fri, 8 Jun 2001 10:01:51 -0700 (PDT) (envelope-from bright@superconductor.rush.net) Received: (from bright@localhost) by superconductor.rush.net (8.11.2/8.11.2) id f58H1Ui14469; Fri, 8 Jun 2001 13:01:30 -0400 (EDT) Date: Fri, 8 Jun 2001 13:01:28 -0400 From: Alfred Perlstein To: Peter Wemm Cc: tlambert2@mindspring.com, "Patrick W. Penzias Dirks" , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: Support for pivot_root-like system call? Message-ID: <20010608130128.E1832@superconductor.rush.net> References: <3B2096AB.309B2D14@mindspring.com> <20010608153011.D7AF1380C@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20010608153011.D7AF1380C@overcee.netplex.com.au>; from peter@wemm.org on Fri, Jun 08, 2001 at 08:30:11AM -0700 X-all-your-base: are belong to us. 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 * Peter Wemm [010608 11:30] wrote: > Terry Lambert wrote: > > "Patrick W. Penzias Dirks" wrote: > > > > > > Hi, > > > > > > I'm the filesystems tech lead in Apple's Mac OS X Core OS group. > > > Prompted by the needs of, among others, virus protection software > > > developers who want to be able to mount "on" the root directory to > > > intercept ALL filesystem calls in the system, I'm contemplating > > > implementation of a new system call in Mac OS X to do something like > > > Linux's pivot_root system call: > > > > > > int pivot_root(const char *new_root, const char *put_old); > > > > > > (which basically installs "new_root" as the new "/" [root_vnode] in > > > the system and transfers the current root directory to the pathname > > > specified my "put_old") > > > > It doesn't work in FreeBSD proper because of cache coherency > > bugs that have been around since 1995, but: > > > > mount -t nullfs / /put_old # or wherever > > mount -t / > > > > Would do what you want, I think. > > Terry, the 'cache coherency' bugs have been fixed in -current for ~8 > months now (September 2000). The infrastructure changes for this are > subject to a call-for-review right now for a merge to 4.x. The cache coherency bugs are not fixed for all cases, being able to ask the underlying filesystem for the vm_object does not solve the problem. What if i have a stacking layer where each page alternates between two files that i'm stacked on top of? Passing the vm_object back doesn't work for this. Unless something else has been done. -Alfred Perlstein [alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jun 8 10:10:19 2001 Delivered-To: freebsd-fs@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 7544D37B405; Fri, 8 Jun 2001 10:10:14 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f58H9vm88303; Fri, 8 Jun 2001 10:09:57 -0700 (PDT) (envelope-from dillon) Date: Fri, 8 Jun 2001 10:09:57 -0700 (PDT) From: Matt Dillon Message-Id: <200106081709.f58H9vm88303@earth.backplane.com> To: Boris Popov Cc: Carl Makin , stable@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: CFR: Fixes for nullfs in -stable References: 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 :On Thu, 7 Jun 2001, Carl Makin wrote: : :> Is "nullfs" used by mount_null? If so, how far do these patches go :> towards making mount_null usable? (I'm not aware of the status of nullfs :> in current). : : Yes, mount_null command mounts nullfs. With these patches 'make :world' completes successfully on the nullfs /usr mount. : :-- :Boris Popov :http://www.butya.kz/~bp/ Hey, great! I'm glad someone finally got nullfs fixed! In regards to MFCing it to stable, I don't see any roadblocks. The vop_sharedlock junk is only used by NFS as far as I know. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jun 8 11:41:46 2001 Delivered-To: freebsd-fs@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 5ACA237B405 for ; Fri, 8 Jun 2001 11:41:37 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f58IfUg37583 for fs@FreeBSD.org; Fri, 8 Jun 2001 21:41:30 +0300 (EEST) (envelope-from ru) Date: Fri, 8 Jun 2001 21:41:29 +0300 From: Ruslan Ermilov To: fs@FreeBSD.org Subject: Audio CDFS Message-ID: <20010608214129.E35281@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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 Hi! Someone please remind me what is the status of the Audio CDFS (sound tracks -> files) filesystem, and where can I download it? Thanks, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jun 8 14:27:40 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by hub.freebsd.org (Postfix) with ESMTP id B65BB37B405; Fri, 8 Jun 2001 14:27:33 -0700 (PDT) (envelope-from pwd@apple.com) Received: from apple.con (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id OAA05909; Fri, 8 Jun 2001 14:27:32 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by apple.con (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 8 Jun 2001 14:25:46 +0100 Received: from thunder (thunder.apple.com [17.202.40.76]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id OAA23988; Fri, 8 Jun 2001 14:27:05 -0700 (PDT) Message-Id: <200106082127.OAA23988@scv1.apple.com> Date: Fri, 8 Jun 2001 14:27:04 -0700 From: Pat Dirks Content-Type: text/plain; format=flowed; charset=us-ascii Subject: Re: Support for pivot_root-like system call? Cc: FreeBSD-Arch@freebsd.org, FreeBSD-FS@freebsd.org To: tlambert2@mindspring.com X-Mailer: Apple Mail (2.388) In-Reply-To: <3B2096AB.309B2D14@mindspring.com> Mime-Version: 1.0 (Apple Message framework v388) Content-Transfer-Encoding: 7bit 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 On Friday, June 8, 2001, at 02:11 AM, Terry Lambert wrote: >> Prompted by the needs of, among others, virus protection software >> developers who want to be able to mount "on" the root directory to >> intercept ALL filesystem calls in the system, I'm contemplating >> implementation of a new system call in Mac OS X to do something like >> Linux's pivot_root system call: >> >> int pivot_root(const char *new_root, const char *put_old); >> >> (which basically installs "new_root" as the new "/" [root_vnode] in >> the system and transfers the current root directory to the pathname >> specified my "put_old") > > It doesn't work in FreeBSD proper because of cache coherency > bugs that have been around since 1995, but: > > mount -t nullfs / /put_old # or wherever > mount -t / > > Would do what you want, I think. True, that is the exact effect, except that it leaves the old root accessible only through a nullfs layer, which is unnecessarily ineffcient. > Really, the BSD way of doing this is to stack an FS with the > feature you want on top of the one without the feature in it. Oh, I know. The reason the developers are interested in this is for exactly that reason - in order to supplant "/" with a mount of their own so that they can layer their virus protection checks on the ordinary filesystem. They'd like to be able to implement a layered fileystem that'll cover the entire filesystem tree and which checks on various operations to make sure no viruses are being handled. Their antivirusfs_open code would, for instance, scan the underlying file before returning to the caller, forcing an error if a virus was detected. There are, I suppose, two aspects of pivot_root that are appealing: it provides a clean way to supplant all references to the existing 'rootvnode', not just in the kernel globals but in all running processes, and, in addition, it allows an atomic reorganization of the mount structure that can't be done with exactly the same effect in two separate operations because the old root will be inaccessible after the mounting of the new root. I see I missed a crucial bit in the checkdirs() code that's invoked after a mount where 'rootvnode' is automatically updated if something's mounted on "/". Considering that the main initial use for this call would actually be for the first reason above (merely supplanting "/"), not the second reason (moving where the current "/" appears) I think it'll be sufficient to adopt a bit more of the FreeBSD mount code to call checkdirs() after mount to update the existing processes in the system along with 'rootvnode'. If we find a call for pivot_root's more exotic restructuring functionality, we'll revisit the issue of implementing a new system call. Thanks for everyone's coments! -Pat Dirks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jun 8 19: 2:46 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mass.dis.org (fumerola-laptop.corp.yahoo.com [216.145.60.111]) by hub.freebsd.org (Postfix) with ESMTP id AB5F537B401; Fri, 8 Jun 2001 19:02:41 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.3/8.11.3) with ESMTP id f592Cjb02166; Fri, 8 Jun 2001 19:12:45 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200106090212.f592Cjb02166@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Pat Dirks Cc: FreeBSD-Arch@freebsd.org, FreeBSD-FS@freebsd.org Subject: Re: Support for pivot_root-like system call? In-reply-to: Your message of "Fri, 08 Jun 2001 14:27:04 PDT." <200106082127.OAA23988@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Jun 2001 19:12:45 -0700 From: Mike Smith 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 Just a couple of observations about this approach: - If you only replace the / mount, you only protect /. If an application traverses off / onto another filesystem during a lookup, the eventuating vnode is going to get the vfsops pointer for the filesystem handling the FS the lookup terminates on, circumventing the protection. A better approach will probably be to implement a 'mount template', where an FS can register a hook which allows it to decide whether if wants to be automagically layered over another FS being mounted, something like an automatic version of Terry's union mount. - There's an ugly tradeoff between kernel footprint and performance here. You want the checker in kernel space to avoid context switching and piping all your I/O to/from userspace, but if you're doing dictionary searches, that's stuff that is going to be sitting permanently mapped. 8( Hope this helps; thanks for raising the issue, it's an interesting one. 8) Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jun 8 19:30:20 2001 Delivered-To: freebsd-fs@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id B071537B405; Fri, 8 Jun 2001 19:30:13 -0700 (PDT) (envelope-from bp@butya.kz) Received: by relay.butya.kz (Postfix, from userid 1000) id 6720029020; Sat, 9 Jun 2001 09:29:55 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 5A91B28FF6; Sat, 9 Jun 2001 09:29:55 +0700 (ALMST) Date: Sat, 9 Jun 2001 09:29:55 +0700 (ALMST) From: Boris Popov To: Alfred Perlstein Cc: Peter Wemm , tlambert2@mindspring.com, "Patrick W. Penzias Dirks" , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: Support for pivot_root-like system call? In-Reply-To: <20010608130128.E1832@superconductor.rush.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Fri, 8 Jun 2001, Alfred Perlstein wrote: > The cache coherency bugs are not fixed for all cases, being able to > ask the underlying filesystem for the vm_object does not solve the > problem. > > What if i have a stacking layer where each page alternates > between two files that i'm stacked on top of? This is a case of "fan-out" stacking and such filesystems are much more complex than fan-in ones. VOP_*VOBJECT() were specifically designed for fan-in type of stacking. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Jun 9 4:46:34 2001 Delivered-To: freebsd-fs@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id D62EB37B403; Sat, 9 Jun 2001 04:46:25 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f59BkCB92124; Sat, 9 Jun 2001 14:46:12 +0300 (EEST) (envelope-from ru) Date: Sat, 9 Jun 2001 14:46:12 +0300 From: Ruslan Ermilov To: "Alexey V. Neyman" Cc: Poul-Henning Kamp , fs@FreeBSD.org Subject: Re: man VOP_ACCESS(9), suser(9) Message-ID: <20010609144612.H87114@sunbay.com> References: <20010609152520.Q2476-100000@srv2.any> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010609152520.Q2476-100000@srv2.any>; from avn@any.ru on Sat, Jun 09, 2001 at 03:27:33PM +0400 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 On Sat, Jun 09, 2001 at 03:27:33PM +0400, Alexey V. Neyman wrote: > Hello there! > > >From pseudo-code in VOP_ACCESS(9): > /* Otherwise, user id 0 always gets access. */ > if (cred->cr_uid == 0) > return 0; > > Shouldn't this check be changed to suser() or suser_xxx() to check against > super-user privileges? > Yes, much probably. Actually, the code in -CURRENT uses vaccess() from the vfs_subr.c, and the latter uses suser_xxx(), but the VOP_ACCESS(9)'s PSEUDOCODE section of manpage hasn't (yet?) been updated. The code in -STABLE really uses cr_uid == 0 (see ufs_vnops.c), and this probably should be fixed. Over to VFS geeks. :-) Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Jun 9 9:51:54 2001 Delivered-To: freebsd-fs@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id B258537B401; Sat, 9 Jun 2001 09:51:50 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f59GpgF07875; Sat, 9 Jun 2001 09:51:42 -0700 (PDT) (envelope-from dillon) Date: Sat, 9 Jun 2001 09:51:42 -0700 (PDT) From: Matt Dillon Message-Id: <200106091651.f59GpgF07875@earth.backplane.com> To: Alfred Perlstein Cc: Peter Wemm , tlambert2@mindspring.com, "Patrick W. Penzias Dirks" , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: Support for pivot_root-like system call? References: <3B2096AB.309B2D14@mindspring.com> <20010608153011.D7AF1380C@overcee.netplex.com.au> <20010608130128.E1832@superconductor.rush.net> 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 :The cache coherency bugs are not fixed for all cases, being able to :ask the underlying filesystem for the vm_object does not solve the :problem. : :What if i have a stacking layer where each page alternates :between two files that i'm stacked on top of? : :Passing the vm_object back doesn't work for this. Unless something :else has been done. : :-Alfred Perlstein [alfred@freebsd.org] Well, I suppose a vm_map would solve this, though for the specific alternating case (or a RAID configuration of some sort) it would be really expensive to do with a vm_map. We would need some kind of synthesized translation capability in the vm_map to make it efficient. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Jun 9 10:14:37 2001 Delivered-To: freebsd-fs@freebsd.org Received: from johnson.mail.mindspring.net (johnson.mail.mindspring.net [207.69.200.177]) by hub.freebsd.org (Postfix) with ESMTP id 8B7D037B401; Sat, 9 Jun 2001 10:14:29 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.133.57.Dial1.SanJose1.Level3.net [209.245.133.57]) by johnson.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA10093; Sat, 9 Jun 2001 13:14:20 -0400 (EDT) Message-ID: <3B225989.6E2110@mindspring.com> Date: Sat, 09 Jun 2001 10:14:49 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: "Patrick W. Penzias Dirks" , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: Support for pivot_root-like system call? References: <20010608153011.D7AF1380C@overcee.netplex.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Peter Wemm wrote: > Terry, the 'cache coherency' bugs have been fixed in -current for ~8 > months now (September 2000). The infrastructure changes for this are > subject to a call-for-review right now for a merge to 4.x. Peter, the 'cache coherency' bugs have only been fixed for the trivial case where the pages at the top are identical to the pages at the bottom of a vnode stack. In the case of a transforming stack, the "final VP" that should be returned is actually an intermediate VP, and you need to take a write fault in the putpages in order to do the correct layer boundary transition. As a simple case, consider an FS that at the top presents one page, but at the bottom presents two pages from which that one page is derived. This could be a cryptographic FS, or it could be an FS that converts from ISO-8859-1 to ISO-10646, etc.. The point is that the page contents will undergo a transformation. The problem is the same as the explicit cache coherency code that resolved the getpages/putpages in one layer by calling the read/write function in the underlying layer in the historical "nullfs" workaround, which was a kludge. When FreeBSD moved to a unified VM and buffer cache, it erroneously removed the "hint points" at which an explicit coherency call would occur to synchronize the VM and buffer cache views of an object. This is precisely the code that is needed to synchronize a vm_object_t with the backing vm_object_t after a transformation. What FreeBSD has now will work for about 1/4 of the proposed uses of stacking FS layers. It will _NOT_ work for most of the interesting uses of a stacking architecture, which involve MUX'es (e.g. "translucent FS" for "writing" to a CDROM) or for "proxy FS" for debugging your FS code in user space, etc. -- I have around 16 examples where the current code still fails. Really, you want to define the actual device I/O in terms of a "disk block FS". The thing that most people apparent fail to "get" is that there is a significant difference between a stacking layer and a local media FS. A local media FS has to interact with the VM system (or buffer cache, or whatever). We need to couch UFS in terms of talking to a local media FS on top of which it is stacked. Unfortunately, it seems that most people are unwilling to actually email John Heidemann, the architect of the stacking code in 4.4BSD (and therefore FreeBSD). Frankly, it really pisses me off that this stuff doesn't work in FreeBSD. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Jun 9 10:34:37 2001 Delivered-To: freebsd-fs@freebsd.org Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by hub.freebsd.org (Postfix) with ESMTP id A8E4037B403; Sat, 9 Jun 2001 10:34:24 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.133.57.Dial1.SanJose1.Level3.net [209.245.133.57]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA21819; Sat, 9 Jun 2001 13:34:13 -0400 (EDT) Message-ID: <3B225E32.484672C@mindspring.com> Date: Sat, 09 Jun 2001 10:34:42 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: patl@Phoenix.Volant.ORG Cc: Peter Wemm , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: nullfs fixes [Was: Support for pivot_root-like system call?] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 patl@Phoenix.Volant.ORG wrote: > > On 8-Jun-01 at 08:30, Peter Wemm (peter@wemm.org) wrote: > > Terry, the 'cache coherency' bugs have been fixed in > > -current for ~8 months now (September 2000). The > > infrastructure changes for this are subject to a > > call-for-review right now for a merge to 4.x. > > This is -VERY- good news. I just have two questions: > > 1. Which currently broken filesystems in STABLE become usable with > these fixes? The fix is _my_ design. It permits the code to get the backing object for a vm_object_t, instead of an alias. I first proposed this design in 1995, as _part_ of a total fix (in other words, it will not fix the entire problem space). In answer to your question, the FS's which become usable are the ones for which the final VP is the local media file system, and for which there are no transformations in the FS's layered on top of it. This will work for nullfs (obviously), unionfs (assuming that the using is on a per file basis, or, minimally, at a page granularity, for interleaved FS's, and similar FS's. It will also work for adjunct metadata FS's, where the memtadata is stored seperately, such as my "quotafs", which allows "UFS quotas" to be applied to any FS on which you stack them. It will _NOT_ work for cryptographic FS's, where the number of pages or the page boundaries change witing a file, compressing FS's, FS's with different block sizes (such as a DVDROM FS, which need to deal with 1024 byte sectors for an ISO 9660 FS, along with raw CD tracks), etc.. It will _NOT_ deal with paging issues from a 1024b block size FAT opr VFAT or VFAT32 FS, when aligned at a 512b boundary (the most common case, when such an FS occurs immediately after the MBR and partition table), and it will not work for more interesting FS's which do namespace folding or support things like ISO-8859-1 to ISO-10646 namespace translation on directories (an obvious use for stacking FS layers, to provide compatability). Similarly, binary compatability between, e.g. UFS on a little endian vs. a big endian FS, implemented in a stacking layer, will not work, for systems where the atomic types are inequal (c.v. the recent time_t discussion). In other words, the code will work in about 1/4 of the cases... which, however you look at it, is a hell of a lot better than 0 of the cases, and _does_ represent forward progress. It's just not the panacea that Peter makes it out to be. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Jun 9 10:39:24 2001 Delivered-To: freebsd-fs@freebsd.org Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by hub.freebsd.org (Postfix) with ESMTP id 90F4B37B401; Sat, 9 Jun 2001 10:39:17 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.133.57.Dial1.SanJose1.Level3.net [209.245.133.57]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA31006; Sat, 9 Jun 2001 13:38:54 -0400 (EDT) Message-ID: <3B225F4C.CEE4E28C@mindspring.com> Date: Sat, 09 Jun 2001 10:39:24 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Boris Popov Cc: Alfred Perlstein , Peter Wemm , "Patrick W. Penzias Dirks" , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: Support for pivot_root-like system call? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Boris Popov wrote: > > On Fri, 8 Jun 2001, Alfred Perlstein wrote: > > > The cache coherency bugs are not fixed for all cases, being able to > > ask the underlying filesystem for the vm_object does not solve the > > problem. > > > > What if i have a stacking layer where each page alternates > > between two files that i'm stacked on top of? > > This is a case of "fan-out" stacking and such filesystems are much > more complex than fan-in ones. VOP_*VOBJECT() were specifically designed > for fan-in type of stacking. Wrong. Read the FICUS papers. Support for a "translucent" FS was one of the intial goals, as was HSM. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Jun 9 11: 1:15 2001 Delivered-To: freebsd-fs@freebsd.org Received: from phoenix.volant.org (dickson.phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id A9AF737B401; Sat, 9 Jun 2001 11:01:08 -0700 (PDT) (envelope-from patl@Phoenix.Volant.ORG) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with esmtp (Exim 1.92 #8) id 158n2p-0006YQ-00; Sat, 9 Jun 2001 11:01:07 -0700 Received: from localhost (localhost [127.0.0.1]) by asimov.phoenix.volant.org (8.9.3+Sun/8.9.3) with SMTP id LAA10723; Sat, 9 Jun 2001 11:01:03 -0700 (PDT) From: patl@Phoenix.Volant.ORG Date: Sat, 9 Jun 2001 11:01:02 -0700 (PDT) Reply-To: patl@Phoenix.Volant.ORG Subject: Re: nullfs fixes [Was: Support for pivot_root-like system call?] To: tlambert2@mindspring.com Cc: Peter Wemm , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG In-Reply-To: <3B225E32.484672C@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 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 On 9-Jun-01 at 10:34, Terry Lambert (tlambert2@mindspring.com) wrote: > patl@Phoenix.Volant.ORG wrote: > > > > On 8-Jun-01 at 08:30, Peter Wemm (peter@wemm.org) wrote: > > > Terry, the 'cache coherency' bugs have been fixed in > > > -current for ~8 months now (September 2000). The > > > infrastructure changes for this are subject to a > > > call-for-review right now for a merge to 4.x. > > > > This is -VERY- good news. I just have two questions: > > > > 1. Which currently broken filesystems in STABLE become usable with > > these fixes? > > The fix is _my_ design. It permits the code to get the > backing object for a vm_object_t, instead of an alias. > > ... > > In answer to your question, the FS's which become usable > are the ones for which the final VP is the local media > file system, and for which there are no transformations > in the FS's layered on top of it. > > ... > > In other words, the code will work in about 1/4 of the > cases... which, however you look at it, is a hell of a > lot better than 0 of the cases, and _does_ represent > forward progress. It's just not the panacea that Peter > makes it out to be. Hmm. I would like to see a complete fix, some of the possibilities are quite interesting. BUT it sounds like this is enough to take care of my immediate need; which is for a way to setup jails with a read-only shared base filesystem (holding the system files and installed ports/packages), overlayed with a writeable per-jail tree with configuration and jail-specific data files. And to have the per-jail trees -really- be separate directories within a shared partition on the host system so that I don't have to worry about partition allocation issues. Aside from the obvious virtual hosting application, I see this setup as being quite useful for port maintainers as a tool for making it easier to determine exactly which files and directories are created or modified during an install. (Make a jail filesystem and install all the dependancies in it. Make the port. Overlay an empty directory over the jail fs. Make install. Examine the overlayed fs from outside the jail. Any files in it must have been edited or created by the install. Checking directories is slightly more work but still pretty easy.) -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Jun 9 11:17:32 2001 Delivered-To: freebsd-fs@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id D9B3B37B401; Sat, 9 Jun 2001 11:17:25 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f59IHO108472; Sat, 9 Jun 2001 11:17:24 -0700 (PDT) (envelope-from dillon) Date: Sat, 9 Jun 2001 11:17:24 -0700 (PDT) From: Matt Dillon Message-Id: <200106091817.f59IHO108472@earth.backplane.com> To: Terry Lambert Cc: patl@Phoenix.Volant.ORG, Peter Wemm , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: nullfs fixes [Was: Support for pivot_root-like system call?] References: <3B225E32.484672C@mindspring.com> 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 :It will _NOT_ work for cryptographic FS's, where the number :of pages or the page boundaries change witing a file, :compressing FS's, FS's with different block sizes (such as :... :-- Terry Woa... sure it will! The VM Object is representing the clear text file, not the actual underlying crypted file. So it should work just fine. Also, in the filespace the physical sector size is irrelevant. Take the VN (now MD) device for example. If you use a file for backing store the sector size from the point of view of the MD device can be 512 bytes no matter what the actual sector size of the filesystem backing the file is. But if you use, say, swap for backing store the sector size from the point of view of the MD device is one page (4K on IA32), period end of story. Also, even in UFS the physical topology of a file varies... a file might be partially represented by a fragment (e.g. 1K) as well as a full file block (8K) in the physical topology. But the VM Object representing the file doesn't know and doesn't care. So VM Objects for files are 100% independant of the topology of the filesystem backing those files. This means that the fixed NULLFS should work just dandy for any filesystem. It may not be able to overload devices transparently, but it should definitely be able to overload a filesystem. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Jun 9 12:36:40 2001 Delivered-To: freebsd-fs@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 36A9C37B401; Sat, 9 Jun 2001 12:36:31 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f59JaVM65605; Sat, 9 Jun 2001 12:36:31 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id E5EE9380C; Sat, 9 Jun 2001 12:36:30 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: tlambert2@mindspring.com Cc: "Patrick W. Penzias Dirks" , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: Support for pivot_root-like system call? In-Reply-To: <3B225989.6E2110@mindspring.com> Date: Sat, 09 Jun 2001 12:36:30 -0700 From: Peter Wemm Message-Id: <20010609193630.E5EE9380C@overcee.netplex.com.au> 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 Terry Lambert wrote: > Peter Wemm wrote: > > Terry, the 'cache coherency' bugs have been fixed in -current for ~8 > > months now (September 2000). The infrastructure changes for this are > > subject to a call-for-review right now for a merge to 4.x. > > Peter, the 'cache coherency' bugs have only been fixed for > the trivial case where the pages at the top are identical > to the pages at the bottom of a vnode stack. Which is exactly what we're talking about - the trivial one-to-one mapping. See the example that you previously posted, but so thoughtfully removed: > > It doesn't work in FreeBSD proper because of cache coherency > > bugs that have been around since 1995, but: > > > > mount -t nullfs / /put_old # or wherever > > mount -t / > > > > Would do what you want, I think. There are no cache coherency bugs in this situation, which is all we were talking about to start with. You were the one that went off on a tangent on one-to-many mappings, but that is not related to the question at hand. (pivot_root(), remmeber...) Yes, you are absolutely correct about getpages/putpages etc being the real fix that enables all the good stuff, but that wasn't the issue at hand. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Jun 9 15: 1:53 2001 Delivered-To: freebsd-fs@freebsd.org Received: from superconductor.rush.net (superconductor.rush.net [208.9.155.8]) by hub.freebsd.org (Postfix) with ESMTP id C7FC437B401; Sat, 9 Jun 2001 15:01:46 -0700 (PDT) (envelope-from bright@superconductor.rush.net) Received: (from bright@localhost) by superconductor.rush.net (8.11.2/8.11.2) id f59M1ES03896; Sat, 9 Jun 2001 18:01:14 -0400 (EDT) Date: Sat, 9 Jun 2001 18:01:12 -0400 From: Alfred Perlstein To: Matt Dillon Cc: Peter Wemm , tlambert2@mindspring.com, "Patrick W. Penzias Dirks" , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: Support for pivot_root-like system call? Message-ID: <20010609180111.M1832@superconductor.rush.net> References: <3B2096AB.309B2D14@mindspring.com> <20010608153011.D7AF1380C@overcee.netplex.com.au> <20010608130128.E1832@superconductor.rush.net> <200106091651.f59GpgF07875@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200106091651.f59GpgF07875@earth.backplane.com>; from dillon@earth.backplane.com on Sat, Jun 09, 2001 at 09:51:42AM -0700 X-all-your-base: are belong to us. 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 * Matt Dillon [010609 12:51] wrote: > > :The cache coherency bugs are not fixed for all cases, being able to > :ask the underlying filesystem for the vm_object does not solve the > :problem. > : > :What if i have a stacking layer where each page alternates > :between two files that i'm stacked on top of? > : > :Passing the vm_object back doesn't work for this. Unless something > :else has been done. > : > :-Alfred Perlstein [alfred@freebsd.org] > > Well, I suppose a vm_map would solve this, though for the specific > alternating case (or a RAID configuration of some sort) it would be > really expensive to do with a vm_map. We would need some kind of > synthesized translation capability in the vm_map to make it efficient. I think the proper method would be to use GET/PUTPAGES, where a GETPAGES would require a subsequent PUT/UNLOCKPAGES. The problem is that a bunch of code digs into the backing data of the vm and vfs structures without bothering to query the vm/vfs and ask if it's ok (besideds respecting locks, and even that's not always true). -- -Alfred Perlstein [alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message