00:53:02 thanks for the answers, lactose & danmcd_ 00:54:37 obscure question of the afternoon: i've been looking at /proc//* files today for reasons and i notice that in usr/src/uts/common/fs/proc/prsubr.c we ASSERT(AS_WRITE_HELD(as)) for a lot of things that *seem* to only need to read things from the as. prpdsize() feels like a particularly good example. does anyone see an obvious reason we should *need* exclusive access, or is this maybe just a bit 00:54:43 excessive out of caution? 00:55:54 as they are they date all the way back to trusty OpenSolaris Launch so... beyond the horizon of time for me :) 00:59:30 Just from a quick scan, it can cause side effects. 01:00:09 Though that may just be history for how it's dealing with the impl of pr_getprot() and others. 01:01:59 So I'm not exactly sure, but definitely some of the bits in prpdread() make me ask questions. 01:02:20 Writers do starve readers, so you would think that that would give it a consistent enough snapshot while walking if it just had a reader lock. 01:03:26 The block comment about the transient nature of page_exists() in prpdread above the next check is definitely suggestive of stuff going on. 01:03:29 But I'm not personally sure. 01:04:35 oh, interesting, that's one i hadn't noticed 01:04:43 some to think about 04:06:05 iximeow: I might've linked two more recent procfs fixes as related to your newly filed bug... maybe I shouldn't have. Feel free to remove them if it's too intrusive. Some of what you and rmustacc are discussing does indeed go WAY back. 04:06:33 uggh. s/might've/did/g for the above. 04:20:44 danmcd: seems good to me - i wouldn't have seen those otherwise. honestly i was/am pretty focused on the `/{x,}map` stuff but there's a lot in prsubr.c and i assume it supports other procfs paths too 04:25:23 There's some mess in there that did get better. pmooney did some work in there as well. 16:26:33 wow, so many guys on line, like a big famaly, an illumos famaly <3 (y) 20:15:19 [illumos-gate] 17319 want define for in-band PD disable support bit in PCIe slot capabilities 2 -- Dan Cross