14:14:30 [illumos-gate] 16525 TCP_MD5SIG listening socket should degrade gracefully -- Andy Fiddaman 15:01:47 is there anything that documents what is 'normal' (or i guess expected) differences from wsdiff? 15:08:48 If run correctly, aka you use the same version across both, then I usually see nothing with a -nd build. 15:09:05 oh this is a debug build.. 15:09:07 The default version uses the git sha so that will cause stuff. 15:09:12 I think it may be true for a debug build too. 15:09:26 But when version is off, I see probably a half dozen related things. 15:15:33 a while back, i had talked about trying to split the rather massive sata.c into smaller bits (it's probablt #2-3 in size behind sd.c)... but as an initial step i went through and created mapfiles -- both to expose the sata 'api' (I don't think it's ever been formalized, but the things sata drivers require from the framework) as well as adding them for the sata drivers (to hopefully catch 'can't find symbol 15:15:39 X' errors during the build instead of getting a surprise at boot).. also used nm on the few closed source sata drivers to see what sata symbols they appeared to be using 15:16:29 just doing that though, it appears that now the sata modules as well as the sata drivers now get .SUNW_{syminfo,version,versym} while previously they apparently did not 15:16:49 and maybe it's lack of caffeine, but not sure if that was expected 15:17:25 (I kinda thought every elf object got those, but also not really something i've needed to pay attention to previously) 15:18:12 Hmm, how did you rig up the mapfile? 15:18:22 In general we've tried to not use the mapfiles to constrain symbol visibility. 15:18:39 But rather in the current kernel mapfiles we use it as a thing you can define to get the undefined symbol processing turned on. 15:19:04 So I think I'd want to see how it was done. 15:19:18 The way we do the mapfile checking today for undefined symbols basically doesn't create those sections. 15:29:17 i can throw it up on github.. it's not that large of a chance.. 15:31:38 i tried to model it after the few other drivers that use them.. the thought (and maybe this isn't the intention) was to have it so that when splitting sata.c into multiple files, it'd be easier to tell there's no changes in symbol visibility since it's a driver that used by other things 15:32:15 also seems like it makes any non-ddi stuff used by the driver more explicit which seems like it might be useful 15:33:27 e.g. nv_sata uses 'hz, psm_map_phys_new, prom_printf' (among others).. 15:41:25 https://github.com/illumos/illumos-gate/compare/master...jasonbking:illumos-gate:sata/00-mapfile if you want to take a look (it's not squashed yet) 16:06:18 jbk: what I use is a different version that's the same length (bugXXXXX vs basXXXXX) and there are only a handful of things different (one or two kernel files plus a couple acpi-related programs). 16:17:57 [illumos-gate] 16511 vioif_reclaim_tx() is holding lock across calling mac_tx_update -- Dan McDonald 16:32:43 the other slightly interesting to look into is a few things that weren't touched noted some differences in .rela.data, but i think it's just an ordering change because those were already using mapfiles, so wouldn't be a concern.. just may take a bit to go through all of them to confirm that 17:58:17 i've also been trying to find a way to do the split that preserves history more easily, but haven't had much luck -- all the solutions end up having to do a merge to make it work (so you see the interim commit in the history) 17:58:46 so may end up just abandoning splitting things up and dealing with the 21,000+ line file 18:31:01 the long files are so terrible lol 18:43:35 the mapfile approach to constrain visibility would be fine, if it's what you really wanted 18:43:43 but it's separate to what Robert did with Makefile.mapfiles 18:44:15 but symbol _versioning_ wouldn't work 18:44:41 (that is, you could do public: foo\nlocal: *, but you couldn't do SYMBOL_VERSION foo { } around them) 18:44:51 it would be silently ignored 19:03:57 jclulow: I don't mind the long files, I mind the files that piss off smatch 19:04:25 I can be irritated at more than one thing at a time haha 19:04:28 (their's overlap, but the ordering changes) 19:04:35 I feel like emacs saves you from long files 19:04:40 big files I have to go where M-. takes me 19:04:47 or... C-] in vim I think 19:05:03 editors that can't have two totally separate windows open in the same file make long files shit 19:05:04 smatch-y files I have to freak out when my 'small' build takes ages, and I don't know if it was my fault. 19:05:33 jclulow: oh, yes, that would be awful 19:06:10 I have a giant monitor that can do 6 columns of 80x87 at my current font size 19:06:26 If all my code is in one file, I can only use one of those columns haha 19:06:32 but for whatever reason, sata.c isn't a smatch offender 19:06:40 do you use that with one big emacs frame? 19:06:49 I don't use emacs at all 19:07:01 josh is of one of the other clans 19:07:03 thats unfortunate 19:07:07 I'm one of the vim people 19:07:13 Alas! 19:07:17 :-> 19:07:27 I tried helix recently haha 19:07:29 and 19:07:29 but yeah, sata.c is "fine" though I don't know how, nvme.c is "incredibly toxic" 19:07:32 though I again don't know how 19:07:32 ... I'm back to vim 19:07:39 richlowe: eh. 19:07:54 from an smatch perspective specifically? 19:08:01 yes 19:08:06 it might be type heavy? 19:08:14 it takes me 4 seconds to build sata, it takes me 1:20 to build nvme 19:08:18 haha wow 19:08:21 basically all of that is smatching it 19:08:28 Is this in the VM on the Gimlet? 19:08:31 Yes 19:08:33 jesus 19:08:37 That's a pretty fast box 19:08:39 all things considered 19:08:55 there are client parts that can burst much faster obviously but yeha 19:09:18 It's C, right, so you could flamegraph it haha 19:09:30 yeah, it needs investigation when I have some time, or someone else does 19:26:01 (to be clear, it's smatch's fault, and there are other toxic files. That's just the one I remember that _we still allow to run_) 19:26:08 there are parts of the tree we guard off, because smatch just... doesn't finish 19:57:03 so for wrapping up https://illumos.org/issues/15691 I think I've wrapped my brain around how libc uberdata and multiple link maps (and their respective libc instances) interact. with the change I'm proposing I think I need we need to disable setlocale(), duplocale() and newlocale() in non-primary link maps. Given that malloc() is disabled in non-primary link maps, that doesn't seem unreasonable to me. 20:10:14 If you propose that because _they_ need to allocate, there is `lmalloc()` 20:10:32 if you propose that because it vastly simplifies things, and that's a really weird corner case: I agree 20:12:56 it vastly simplifies things. 20:17:10 well, it vastly simplifies things if you can fetch the current locale from the thread base pointer because it's in `struct ulwp` instead of having to call tsdalloc() every time you want the current locale. 20:18:07 but then because struct ulwp is not link-map-specific it really means that locales have to be owned by the primary link map's libc.. 20:19:33 yeah, that makes sense, and I agree. 20:20:18 we could throw function pointers to the primary link map's setlocale/duplocale/newlocale into the uberdata, and have non-primary libc's call there but it seems like nobody would use that mechanism 20:20:29 and it would be simpler to just have them fail if not in the primary link map. 20:36:54 I feel like link maps are for people doing weird shit already? 20:37:10 e.g., LX brand style stuff, or other oddball auditing things 20:37:31 speaking of *locale(), folks might be interested in https://github.com/TritonDataCenter/pkgsrc-extra/commit/51e7c8f7e54789951d1f95c141eeeaf9502c66ba 20:38:11 I think the most normal way into link map stuff is rtld_audit(3ext) 20:39:03 after that things get increasingly baroque (brand libs, rtld, libc) 20:49:03 if you just want to experiment with code running in alternate link maps, dlmopen(LM_ID_NEWLM, ...) is the way to go. 20:56:01 more software than I expected uses it to isolate plugins, but I'm not sure what any of it is. 20:56:07 (I just used github search) 21:09:45 So if you do use it for plugins, your alt-link-map plugins just end up using the primary map's locale? 21:12:35 I think what sommerfeld is trying to avoid is fundamentally a confused thing to do 21:12:53 though I don't think any online search has the ability to check nobody tries 21:13:06 so I'm still fine with it, until proven wrong 21:13:17 jclulow: yes. 21:16:52 well, they use the locale structures built by the primary map's locale code but the locale code in their libc. 21:21:51 richlowe: i did clean things up in sata.c a while back to get rid of all the compiler and smatch warnings... 21:22:23 does that make smatch markedly faster? 21:27:09 oh taht i don't know.. just that it used to be disabled on it before i cleaned things up 21:27:17 so i guess technically i made it slower :)