The implementation is somewhat naive in that the list sysctl might drain sbuf while shm_dict_lock is shared-locked, but I do not see a problem with that.
Details
Details
- Reviewers
avg jhb tmunro jilles - Commits
- rS348167: Add posixshmcontrol(1), an utility to manipulate posix shared memory segments.
rS348158: Add a kern.ipc.posix_shm_list sysctl.
rS348157: Report ref count of the backing object as st_nlink for posix shm fd.
rS348156: Make pack_kinfo() available for external callers.
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 24236
Event Timeline
Comment Actions
Report refcount of the backing vm object as shm stat nlink. It is almost always equal to the number of mappings - 1.
Comment Actions
Thanks for working on this! I took it for a quick spin and have some initial feedback.
| usr.bin/posixshmcontrol/posixshmcontrol.c | ||
|---|---|---|
| 54 | Forgot to mention -p <path> for -t. Erm, why not get rid of the -p and the -z anyway? -c <path>, -t 1234 <path> | |
| 66 | Should be able to specify the mode too. | |
| 126 | Should we print the mode as eg --rwarwarwa like ipcs? Also it's a bit ugly to have the path unaligned, unlike ipcs's line up output. | |
| 161 | This loop is wrong, I'm only getting 4096 bytes out and a bogus "No error" warning. Also redirecting output to /dev/null gives me "Inappropriate ioctl for device", not sure what's happening there. | |
Comment Actions
I think it will be useful to have this. It fixes most of the drop in functionality when moving from System V shared memory to POSIX shared memory.
I mainly reviewed the userland part.
| usr.bin/posixshmcontrol/posixshmcontrol.c | ||
|---|---|---|
| 52–57 | I like the subcommand syntax but it would be more consistent with mkdir, mknod, truncate, etc. to take mode and newlen as options and allow multiple pathnames at a time. | |
| 84–85 | Should this exit with a non-zero status? | |
| 110 | This only returns shared memory objects that have names, not unlinked or SHM_ANON objects that are still open. In some way, that makes sense (comparing to ls), but objects without names still consume memory. | |
| 147–148 | %zd is not the correct formatting specifier for uint64_t on 32-bit systems. | |
| 211 | Perhaps %#o or shm_decode_mode are a bit clearer. | |
| 215 | %zd is not the correct formatting specifier for off_t on 32-bit systems. | |
| 216–219 | Perhaps we should print the nanoseconds part as well using .%09ld format? | |
| usr.bin/posixshmcontrol/posixshmcontrol.c | ||
|---|---|---|
| 110 | This was deliberate, I did considered handling them. This would require more extensive kernel changes to track such objects, which I do not want to do in the scope of this work. One of the reasons which convinced me to not consider anon handling as required is that such objects do disappear when the process owning fd is killed. In other words, they are not too persistent (unlike SysV ipc objects or named posix shm). | |
| usr.bin/posixshmcontrol/posixshmcontrol.c | ||
|---|---|---|
| 195 | I think we should show shm_uid and shm_guid too, otherwise mode is a bit meaningless in this list. I realise that you can get those with "posixshmcontrol stat", but ipcs shows OWNER and GROUP columns beside MODE. | |
Comment Actions
More reasonable unconditional locking for shm_fill_kinfo().
List owner and group for 'ls'.
For 'ls' and 'stat' add -h and -n switches; -h makes sizes human-readable, -n prints uid/gid numerically.