[illumos-gate] 16525 TCP_MD5SIG listening socket should degrade gracefully -- Andy Fiddaman <illumos⊙fn>

is there anything that documents what is 'normal' (or i guess expected) differences from wsdiff?

If run correctly, aka you use the same version across both, then I usually see nothing with a -nd build.

oh this is a debug build..

The default version uses the git sha so that will cause stuff.

I think it may be true for a debug build too.

But when version is off, I see probably a half dozen related things.

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

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

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

and maybe it's lack of caffeine, but not sure if that was expected

(I kinda thought every elf object got those, but also not really something i've needed to pay attention to previously)

Hmm, how did you rig up the mapfile?

In general we've tried to not use the mapfiles to constrain symbol visibility.

But rather in the current kernel mapfiles we use it as a thing you can define to get the undefined symbol processing turned on.

So I think I'd want to see how it was done.

The way we do the mapfile checking today for undefined symbols basically doesn't create those sections.

i can throw it up on github.. it's not that large of a chance..

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

also seems like it makes any non-ddi stuff used by the driver more explicit which seems like it might be useful

e.g. nv_sata uses 'hz, psm_map_phys_new, prom_printf' (among others)..

github.com/illumos/illumos-gate/com…nbking:illumos-gate:sata/00-mapfile if you want to take a look (it's not squashed yet)

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).

[illumos-gate] 16511 vioif_reclaim_tx() is holding lock across calling mac_tx_update -- Dan McDonald <danmcd⊙mi>

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

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)

so may end up just abandoning splitting things up and dealing with the 21,000+ line file

the long files are so terrible lol

the mapfile approach to constrain visibility would be fine, if it's what you really wanted

but it's separate to what Robert did with Makefile.mapfiles

but symbol _versioning_ wouldn't work

(that is, you could do public: foo\nlocal: *, but you couldn't do SYMBOL_VERSION foo { } around them)

it would be silently ignored

jclulow: I don't mind the long files, I mind the files that piss off smatch

I can be irritated at more than one thing at a time haha

(their's overlap, but the ordering changes)

I feel like emacs saves you from long files

big files I have to go where M-. takes me

or... C-] in vim I think

editors that can't have two totally separate windows open in the same file make long files shit

smatch-y files I have to freak out when my 'small' build takes ages, and I don't know if it was my fault.

jclulow: oh, yes, that would be awful

I have a giant monitor that can do 6 columns of 80x87 at my current font size

If all my code is in one file, I can only use one of those columns haha

but for whatever reason, sata.c isn't a smatch offender

do you use that with one big emacs frame?

I don't use emacs at all

josh is of one of the other clans

thats unfortunate

I'm one of the vim people

Alas!

:->

I tried helix recently haha

and

but yeah, sata.c is "fine" though I don't know how, nvme.c is "incredibly toxic"

though I again don't know how

... I'm back to vim

richlowe: eh.

from an smatch perspective specifically?

yes

it might be type heavy?

it takes me 4 seconds to build sata, it takes me 1:20 to build nvme

haha wow

basically all of that is smatching it

Is this in the VM on the Gimlet?

Yes

jesus

That's a pretty fast box

all things considered

there are client parts that can burst much faster obviously but yeha

It's C, right, so you could flamegraph it haha

yeah, it needs investigation when I have some time, or someone else does

(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_)

there are parts of the tree we guard off, because smatch just... doesn't finish

so for wrapping up 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.

If you propose that because _they_ need to allocate, there is `lmalloc()`

if you propose that because it vastly simplifies things, and that's a really weird corner case: I agree

it vastly simplifies things.

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.

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..

yeah, that makes sense, and I agree.

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

and it would be simpler to just have them fail if not in the primary link map.

I feel like link maps are for people doing weird shit already?

e.g., LX brand style stuff, or other oddball auditing things

speaking of *locale(), folks might be interested in TritonDataCenter/pkgsrc-extra 51e7c8f

I think the most normal way into link map stuff is rtld_audit(3ext)

after that things get increasingly baroque (brand libs, rtld, libc)

if you just want to experiment with code running in alternate link maps, dlmopen(LM_ID_NEWLM, ...) is the way to go.

more software than I expected uses it to isolate plugins, but I'm not sure what any of it is.

(I just used github search)

So if you do use it for plugins, your alt-link-map plugins just end up using the primary map's locale?

I think what sommerfeld is trying to avoid is fundamentally a confused thing to do

though I don't think any online search has the ability to check nobody tries

so I'm still fine with it, until proven wrong

jclulow: yes.

well, they use the locale structures built by the primary map's locale code but the locale code in their libc.

richlowe: i did clean things up in sata.c a while back to get rid of all the compiler and smatch warnings...

does that make smatch markedly faster?

oh taht i don't know.. just that it used to be disabled on it before i cleaned things up

so i guess technically i made it slower :)