> Date: Tue, 27 Jun 2023 16:27:34 -0400 > From: Theodore Preduta <t...@pta.gg> > > On 2023-06-26 20:03, Taylor R Campbell wrote: > > For a syscall, you should implement it in terms of uvm anonymous > > objects: > > Is there a preexisting way to resize a uvm_object? Or do I need to > write a function similar (but not really that similar) to uvm_vnp_setsize?
Hmm, yes, it looks like we will need a uao_setsize operation. Here's a quick hack: 1. New flag UAO_FLAG_RESIZABLE. In uao_create and others, always use a max-size u_swhash table when this flag is set, so we don't have to worry about resizing u_swslots array, rehashing u_swhash, or converting between array and hash table. Not ideal but it'll do without much effort. 2. Define uao_resize to: (a) assert UAO_FLAG_RESIZABLE is set; (b) if truncating: uao_put the parts that will be discarded, from round_page(newsize) to oldsize, with PGO_FREE; and (c) update u_pages, all under a write-lock on uobj->vmobjlock. Then .fo_write and .fo_truncate can just do uao_setsize -- or at least, .fo_truncate could do that if it existed! Currently sys_ftruncate is vnode-specific, so we'll need to introduce a new .fo_truncate fileops member like we've done for various other things recently like .fo_seek, .fo_advlock, &c.: https://mail-index.netbsd.org/source-changes-hg/2023/04/22/msg364655.html https://mail-index.netbsd.org/source-changes-hg/2023/04/22/msg364656.html https://mail-index.netbsd.org/source-changes-hg/2023/04/22/msg364657.html P.S. I wonder whether this procedure is racy -- uao_put can drop the lock; what happens if a concurrent uao_get/put swoops in while the lock is dropped? But uvm_vnp_setsize must have the same issue, since uvn_put can drop the lock too. So if there is a problem here, it'll probably be easier if the logic is essentially the same, so that it can be fixed in both of them the same way.