[illumos-gate] 17006 ZTS: left over spare-dev1 and spare-dev2 -- Toomas Soome <tsoome⊙mc>

Hello, I'm scratching my head at something to do with ioctl() and TIOCGWINSZ. I am trying to find the width of the screen. Here's the C code pastebin.com/Ejd9N8mU which does run on Linux, but not on OpenIndiana. Here's the error being produced while trying to compile the same code on OpenIndiana pastebin.com/7pPY9URi

I read through the ioctl manual pages, and Google, and haven't come across much useful information as to what is causing this issue

twobitsahead: So when I looked at the manuals that mention the winsize structure, I'd expect you to have to include termios.h.

Including that makes it work for me and is where POSIX defines it to be in POSIX 2024.

(You also don't need sys/ioctl.h).

That solved it

Thank you!

illumos.org/man/4I/termio is what I was looking at for some context.

Thanks, I was just Googling for this. I don't know how this didn't turn up / how I missed this during the search. This is the page that I have been looking for

All good, glad it's sorted.

[illumos-gate] 17016 libzfs: zpool_clear_label fixes -- Ahelenia Ziemiańska <nabijaczleweli⊙nx>

[illumos-gate] 16960 nxge: possible memory leak -- Toomas Soome <tsoome⊙mc>

Cheers, is anyone planning to meet up at FOSDEM this year? Is there an illumos table this time? Any events before/after the weekend itself (e.g. hackathons etc.)? :)

jclulow, so far testing of the new tar binary is going well. I've started a huge set that will take a few days to create the tarball and a few more to extract/verify but so far I'm not seeing any red flags.

jimklimov - there is a planned dinner on the Friday, see illumos.topicbox.com/groups/discuss…fosdem25-illumos-and-friends-dinner

but unfortunately no table/stand. It is becoming more Linux-centric each year.

thanks for the info, hope to be there (and go at all this year)

sigh.... panic[cpu1]/thread=fffffe00108e2c20: programming error: LBA out of range in cmd fffffe0bddf7b840

we do get blown up too eagerly

not sure what you're getting at

I wish I could find the time, or find a victim, to fix dev_err(..., CE_PANIC, ...) though

it pretty obviously should prepend the formatted dev to the panic string

well, in this case, we got LBA from (bad) disk label, attempted to use it and nvme did panic;)

Right, that seems like a fatal programming error?

I think

it seems like the theory is the consumer (label?) sanity checks itself?

well, the label structure was good;) just that the LBA numbers were bad.

ofc the question would be, should cmlb verify the data properly (probably it should) or should nvme error out there (and not panic?) or both:)

nvme seems written on the assumption cmlb would check

I don't claim to know whether that's a good idea, just that it seems to be what nvme thinks should happen

it seems like every command field it doesn't like we .panic on, anyway

kind of makes sense, well that is quite clear that cmlb should check.

except for the charming, `NVME_CMD_F_DONTPANIC`

which I haven't looked deeper into yet

it seems to mean "This came from userland, just fail"

nomad: Thanks!

Yes, I think most blkdev consumers are written assuming they're getting mostly valid I/O requests.

I think if we're going to panic down there, then blkdev should probably handle checking for out of range I/O on its own based on what it gets told about the size of the disk

[illumos-gate] 16964 ptrconf: potential memory corrupting cast 4 vs 1 bytes -- Toomas Soome <tsoome⊙mc>

→ BUG 17029: cmlb should check label better (New)