Home
last modified time | relevance | path

Searched refs:front (Results 1 – 4 of 4) sorted by relevance

/xnu-12377.41.6/bsd/miscfs/devfs/
H A DREADME27 multiple places), a front layer is created that contains a tree of 'front'
33 The front and back nodes are identical in type, but the back nodes
41 To start with there is a 1:1 relationship between the front nodes
42 and the backing nodes, however once the front plane has been created
47 There is a "devnode" struct associated with each front note also.
49 by their associated backing node, so that multiple front nodes that
62 in the 'backing' node for that object. Once you have erased 'front'
83 the user from removing a front node from the directory front node.
84 (except permissions of course). This is because the front directory
85 nodes keep their own records as to which front nodes are members
[all …]
/xnu-12377.41.6/osfmk/vm/
H A Dvm_kern.c2895 uint32_t front) in kmem_init_front_head() argument
2897 LIST_INIT(&ks->ks_allfree_head[front]); in kmem_init_front_head()
2898 LIST_INIT(&ks->ks_partial_head[front]); in kmem_init_front_head()
2899 LIST_INIT(&ks->ks_full_head[front]); in kmem_init_front_head()
3334 uint32_t front) in kmem_get_new_chunk() argument
3425 LIST_INSERT_HEAD(&sizeclass->ks_partial_head[front], start, km_link); in kmem_get_new_chunk()
3490 uint32_t front) in kmem_init_free_chunk() argument
3513 LIST_INSERT_HEAD(&sizeclass->ks_allfree_head[front], meta, km_link); in kmem_init_free_chunk()
3520 uint32_t front) in kmem_get_free_chunk_from_list() argument
3529 meta = LIST_FIRST(&sizeclass->ks_allfree_head[front]); in kmem_get_free_chunk_from_list()
[all …]
/xnu-12377.41.6/doc/arm/
H A Dapple_speculative_hardening.md95 of the submap fronts on each boot, though which particular front is
104 whether it uses the left or right front depends on its per-boot random type
114 front on both the architectural and speculative path. By isolating accesses to
227 into a submap front still allows it to provide a host of probabilistic isolation
237 other locations within the same submap front, a gadget allocated in one zone can
239 happen to be randomly bound to the same submap front.
280 locations on the same front, and so unless one of the zones containing a gadget
281 is allocated to the same front as the target object, the attack fails. While the
326 submap front as the target object and thus can be exploited deterministically.
354 limits the effective reach of such bugs to only the submap or submap front which
[all …]
/xnu-12377.41.6/doc/allocators/
H A Dguard-objects.md264 allocation front. However, attackers still have to contend with the uniform