297157 |
21-Mar-2016 |
bdrewery |
Stop tracking stat(2).
None of lstat(2), fstat(2), fstatat(2) were tracked either.
The other filemon implementations also do not track stat(2), nor does bmake utilize it. The act of opening a file for read should be enough to decide that a file is a dependency. There could be rare cases where just having a file would cause a dependency but it is unlikely.
MFC after: 2 weeks Also noted by: sjg Sponsored by: EMC / Isilon Storage Division
|
297156 |
21-Mar-2016 |
bdrewery |
Track filemon usage via a proc.p_filemon pointer rather than its own lists.
- proc.p_filemon is added which is protected by PROC_LOCK. This improves performance and avoids double-fork issues, taking allproc_lock while in syscalls, and walking the process tree in syscalls. A particular proc.p_filemon can only be changed to NULL or another filemon, or the filemon inherited, while the filemon->lock is held. - Filemon are reference counted. On the last reference the log will be closed. - When closing the devfs file handle, the filemon will be detached from all processes and inheritance prevented. - Disallow attaching to a process already being traced since filemon is typically intended to be used on children only. This is allowed for curproc as bmake relies on this behavior for rare cases when combining .MAKE with .META. - Detach any previously tracked process on ioctl(FILEMON_SET_PID). - Handle error from devfs_set_cdevpriv() in filemon_open(). - The global filemon lock and lists are removed. - A free list is no longer kept. Previously this list was forever-expanding and never garbage cleaned. - No longer loses track of double-forks. If the process holding the filemon handle closes it will close the log rather than wait on a daemonized process, but it will log all activity until it closes its handle. The filemon will be removed from the process and not inherited. - A separate process count is kept only as an optimization for forced detachment to avoid taking allproc_lock and walking the entire process tree. - struct filemon access is protected by sx(9) filemon->lock as it was before. - Add more comments and KASSERTS.
MFC after: 2 weeks Reviewed by: kib, mjg, markj (all on previous versions) Sponsored by: EMC / Isilon Storage Division Differential Revision: https://reviews.freebsd.org/D5520
|
287155 |
26-Aug-2015 |
bdrewery |
Fix filemon locking races.
Convert filemon_lock and struct filemon* lock to sx(9), rather than a self-rolled reader-writer lock, and hold it for the entire time needed.
At least filemon_lock_write() was not checking for active readers when it would successfully return with the write lock "held". This led to a race with reading entries from filemon_inuse as they were removed. This could be seen with QUEUE_MACRO_DEBUG enabled, causing -1 to be read as an entry rather than a valid struct filemon*.
Fixing filemon_lock_write() to check readers was insufficient to fix the races.
sx(9) was used as the lock could be held while taking proctree_lock and sleeping in fo_write.
Sponsored by: EMC / Isilon Storage Division MFC after: 2 weeks
|
255219 |
05-Sep-2013 |
pjd |
Change the cap_rights_t type from uint64_t to a structure that we can extend in the future in a backward compatible (API and ABI) way.
The cap_rights_t represents capability rights. We used to use one bit to represent one right, but we are running out of spare bits. Currently the new structure provides place for 114 rights (so 50 more than the previous cap_rights_t), but it is possible to grow the structure to hold at least 285 rights, although we can make it even larger if 285 rights won't be enough.
The structure definition looks like this:
struct cap_rights { uint64_t cr_rights[CAP_RIGHTS_VERSION + 2]; };
The initial CAP_RIGHTS_VERSION is 0.
The top two bits in the first element of the cr_rights[] array contain total number of elements in the array - 2. This means if those two bits are equal to 0, we have 2 array elements.
The top two bits in all remaining array elements should be 0. The next five bits in all array elements contain array index. Only one bit is used and bit position in this five-bits range defines array index. This means there can be at most five array elements in the future.
To define new right the CAPRIGHT() macro must be used. The macro takes two arguments - an array index and a bit to set, eg.
#define CAP_PDKILL CAPRIGHT(1, 0x0000000000000800ULL)
We still support aliases that combine few rights, but the rights have to belong to the same array element, eg:
#define CAP_LOOKUP CAPRIGHT(0, 0x0000000000000400ULL) #define CAP_FCHMOD CAPRIGHT(0, 0x0000000000002000ULL)
#define CAP_FCHMODAT (CAP_FCHMOD | CAP_LOOKUP)
There is new API to manage the new cap_rights_t structure:
cap_rights_t *cap_rights_init(cap_rights_t *rights, ...); void cap_rights_set(cap_rights_t *rights, ...); void cap_rights_clear(cap_rights_t *rights, ...); bool cap_rights_is_set(const cap_rights_t *rights, ...);
bool cap_rights_is_valid(const cap_rights_t *rights); void cap_rights_merge(cap_rights_t *dst, const cap_rights_t *src); void cap_rights_remove(cap_rights_t *dst, const cap_rights_t *src); bool cap_rights_contains(const cap_rights_t *big, const cap_rights_t *little);
Capability rights to the cap_rights_init(), cap_rights_set(), cap_rights_clear() and cap_rights_is_set() functions are provided by separating them with commas, eg:
cap_rights_t rights;
cap_rights_init(&rights, CAP_READ, CAP_WRITE, CAP_FSTAT);
There is no need to terminate the list of rights, as those functions are actually macros that take care of the termination, eg:
#define cap_rights_set(rights, ...) \ __cap_rights_set((rights), __VA_ARGS__, 0ULL) void __cap_rights_set(cap_rights_t *rights, ...);
Thanks to using one bit as an array index we can assert in those functions that there are no two rights belonging to different array elements provided together. For example this is illegal and will be detected, because CAP_LOOKUP belongs to element 0 and CAP_PDKILL to element 1:
cap_rights_init(&rights, CAP_LOOKUP | CAP_PDKILL);
Providing several rights that belongs to the same array's element this way is correct, but is not advised. It should only be used for aliases definition.
This commit also breaks compatibility with some existing Capsicum system calls, but I see no other way to do that. This should be fine as Capsicum is still experimental and this change is not going to 9.x.
Sponsored by: The FreeBSD Foundation
|