Re: Anonymous vnodes?

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Tue, 27 Jun 2023 16:27:34 -0400
> From: Theodore Preduta <theo%pta.gg@localhost>
> 
> 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.