[illumos-gate] 16649 SATL support for REPORT SUPPORTED OPERATION CODES -- Jason King <jason.brian.king⊙gc>

Other than open are there any syscalls that return a file descriptor?

I see open, open64 and openat

also socket, pipe, dup2, dup3, and the equivalent fcntl() calls

oh, and dup()

thanks, I was getting to dup and pipe, might have missed fcntl

on Solaris & illumos, the dup*() functions in libc actually call the fcntl system call, they don't have their own entry points to the kernel

door_create()?

paulf: there are a number of ways to pass file descriptors over ipc. AF_UNIX lets you pass SCM_RIGHTS ancillary data (see socket.h(3HEAD))

door_call() can pass descriptors as well.

(and close them in the sending process, too!)

(door_call can both send and receive descriptors; the server callback when a door is invoked can receive a descriptor, and door_return can send one and possibly close it)

I just want syscalls that return new file descriptors, at the syscall level

then yes, door_create

paulf: new in what sense? new to this process or new to the system?

sommerfeld: if I recall, paulf works on valgrind so probably new to the process

sommerfeld new to the process

and questions grittier than usual userland software

in that case you need to be aware of the descriptor-passing syscalls

because they can cause a descriptor to materialize in the process from outside.

richlowe yes this is for Valgrind, a new feature that checks that closed fds aren't being used inadvertently via a close then an open

oh, I forgot socketpair() in the list too

This feature is only a couple of days old, I don't think that we cover pipe and socketpair yet

thanks for the input, need to do the same for FreeBSD now

@paulf I don't know your background but remember the spectrum of OS interface boundaries, and whether or not they need distros:

The illumos (and Solaris) interface boundary for programs is libc & friends, NOT the kernel syscall boundary.

valgrind is special, and knows the problems

I don't know FreeBSD's official stance per se.

danmcd we need to intercept all syscalls

as far as I know the FreeBSD interface is stable

Very good!

right, I'd class valgrind with truss & dtrace in needing to know the underlying implementation, not just the stable API for programs to call

Okay, I'm clearly missing the problem, and I take it you're from-or-working-with valgrind paulf -- sorry for muddying waters.

no worry

Valgrind 3.25 should be out soon, Illumos support should be a lot better

I haven't done as much for Solaris,I tried last week and there are some issues with reading ELF .data sections

I have one issue with Helgrind I wantr to fix, not sure that I'll have time before 3.25 is out

WOW! THANK YOU VERY MUCH!

time for bed

@andyf silly question: "go away" is an acceptable answer, and I expect it to be "not really, Dan"

The new MDB enhancements for $C/::stack ==> would those be easily usable by pstack(1) ?

oh that does remind me, andyf: You were going to email me diffs I think?

Not quite yet, but we talked about it.

I think at least the noreturn function handling should also be added to pstack, and at the same time the new heuristic functions for that should be moved somewhere common so they can be used in libproc as well as kmdb.

I haven't put much thought into adding the types to pstack output yet.

richlowe - ah yes, I'll email you what I have for the aarch64 heuristic function.

which is paste.omnios.org/?74bdec407461fc7e#…bU3trGLF99y3CXLf62u4onYsenbB5bVFjmW but I'll drop it in an email

thanks