tsoome: About illumos.org/issues/18334 . How to catch this smatch errors? When I compileв illumos, I didn't see those errors.

→ BUG 18334: stmf_sbd: string too large for strcpy() (In Progress) | code.illumos.org/c/illumos-gate/+/4949

thats newer smatch.

tsoome: So it needs to change Makefile before?

I can't push it yet there are still bunch of errors it does discover:)

no, not makefile, the smatch itself is updated...

but it is not yet on gate.

github.com/tsoome/illumos-gate/tree/smatch_update_labels is current WIP branch

18334 will receive a small addition soon, need to verify it and then will update gerrit.

tsoome: Could you give more information how to enable smatch for smtf/stmf_sbd? I would also run it and check.

it is enabled by default, but if you want to check with my current update, grab the github.com/tsoome/illumos-gate/tree/smatch_update_labels and run make install in usr/src/tools/smatch, then you can switch to branch with your changes and run make manually

tsoome: Sorry, I didn't get. You wrote "thats newer smatch". Does it mean that stmf is not checked by smatch?

it is, but the smatch on gate is older than I have.

so it does detect less problems...

tsoome: what version are you upgrading to?

wondering if it includes error27/smatch 91b751f

→ GitHub commit 91b751f: flow: set prev_stream (committed)

because that might knock some time of the build, IIRC maybe 30s?

I think, I have last commit as commit e9cc34fddeaf6e740cb761bf59d4615be6852652 Date: Wed Apr 22 12:30:33 2026 +0300 - from github.com/error27/smatch.git. I havent had time to check latest for awhile.

I have it + updates to smatch to track kmem_alloc and friends and almost all cleanups so far in github.com/tsoome/illumos-gate/tree/smatch_update_labels - however, as usual, some of the cleanups can be improved... but also, this newer smatch has bug about detecting double free I havent been able to diagnose properly - so it is not something we want to push immediately even as it does pretty good job in other areas.

[illumos-gate] 18314 vmc_space_unmap() iterates the held-pages list with the wrong object -- Andy Fiddaman <illumos⊙fn>

Hi i'm looking to set up a demonstration of illumos or a variant for an internal team. My ask is what's the general familiarty bias for the most popular "distribution" of illumos.

if you want to 'get the gist' on most actively developed illumos distributions, take a look at 'Stephen's Machine Room' illumos playlist on yt

he covers OI, omnios, tribblix and some smartOS

Copy that. Thanks.

Some of those videos have some fantastic dates on them. Kind of threw me off for a second with that playlist.

yeah, they are old-ish, but the information is, for the most part, still relevant today, afaict

unfortunately, nor that much of a illumos content out there, which is a shame, imho

I get that it's a niche, and I'm not just trying to jump to my own famliarity bias. I'll probably go back and listen to the Oxide and Friends podcast episode as well

jbk: Sorry to be such a pest. I'm getting a lot of pressure to get the new fileserver online and in service. Any projections on ICE driver availability?

[illumos-gate] 18301 zfs panic "decompression failed" with gzip compression and low memory -- Matthew Ahrens <matt⊙mo>

nomad: i'm working on it... that's the best I can say...

this thing is so fucking overengineered, it could be working today, or it could be another two months of working through code

i'm sorry but you really should have chosen a different NIC

i'm working my ass off trying to get it working, but even that doesn't seem to be enough

(I actually hope it's the last NIC intel produces, because there's no way I'm writing a driver for the next one)

I wish we'd had a different NIC as well but the only alternative we were offered is one danmcd said to avoid so we went with this one. <sigh>

IIRC the alternative was something that would never be supported. I think it was from broadcom but I could easily be misremembering.

ENOMAD it was Broadcom.