Page MenuHomeFreeBSD

cdev_pager_allocate(): ensure that the cdev_pager_ops ctr is called only once
ClosedPublic

Authored by kib on Tue, May 7, 1:27 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, May 14, 2:59 PM
Unknown Object (File)
Mon, May 13, 7:37 AM
Unknown Object (File)
Sun, May 12, 1:14 AM
Unknown Object (File)
Thu, May 9, 6:39 PM
Unknown Object (File)
Thu, May 9, 5:33 AM
Unknown Object (File)
Thu, May 9, 5:33 AM
Unknown Object (File)
Wed, May 8, 8:08 PM
Unknown Object (File)
Wed, May 8, 5:09 PM
Subscribers

Details

Summary

per allocated vm_object. Otherwise, since constructors are not idempotent, we e.g. leak device reference in case of non-managed pager.

PR: 278826

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kib requested review of this revision.Tue, May 7, 1:27 PM
sys/vm/device_pager.c
183

I think you want to at least use vm_object_deallocate(). Otherwise this will run afoul of the assertions in vm_object_zdtor().

208–210

object->handle has already been assigned, no?

220

Do you need to wake up sleepers here too?

kib marked 3 inline comments as done.Tue, May 7, 2:14 PM
kib added inline comments.
sys/vm/device_pager.c
183

I do not want to deallocate() it, because terminate() destroys pager. This is why I did this manually.

kib marked an inline comment as done.

Handle first batch of comments.

sys/vm/device_pager.c
183

IMO it would be cleaner to postpone initialization of object1 fields until after the lookup. Then I think object1->type = OBJT_DEAD; vm_object_deallocate(object1); is sufficient.

217

Now we have a situation where vm_pager_object_lookup() can return an object that is not fully constructed. Is that safe?

kib marked 2 inline comments as done.Tue, May 7, 2:46 PM
kib added inline comments.
sys/vm/device_pager.c
217

It should be, since dev_pager_object_list is static in device_pager.c, and all lookups there are plugged with the check for un_pager.devp.dev != NULL.

kib marked an inline comment as done.

Use vm_object_deallocate()

sys/vm/device_pager.c
121

Presumably it's possible to have object == NULL here?

kib marked an inline comment as done.Tue, May 7, 4:06 PM
kib added inline comments.
sys/vm/device_pager.c
121

I checked both in-tree callers (ttm and linux_page.c) and both seems to be fine with sleeping in the function.

kib marked an inline comment as done.

Check for object == NULL

This revision is now accepted and ready to land.Wed, May 8, 1:20 PM
sys/vm/device_pager.c
44

This isn't needed anymore.

This revision now requires review to proceed.Wed, May 8, 2:15 PM
This revision is now accepted and ready to land.Wed, May 8, 5:09 PM
sys/vm/device_pager.c
208

Defer this until we set the color?

kib marked an inline comment as done.

Use vm_object_deallocate() instead of _terminate() on cleanup path.
Defer OBJ_COLORED setting after ctr provides the color.

This revision now requires review to proceed.Wed, May 8, 5:54 PM
sys/vm/device_pager.c
168–169

Please consider reducing the scope of object1 to then clause of the if the statement, The only reason to have this assignment here is to satisfy the MPASS after the else clause. The MPASS could instead be at the end of the then clause.

kib marked an inline comment as done.

Reduce scope for object1 and color variables.
Assign OBJT_DEAD type to object before deallocating it on the path after failing ctr, since we do not want to have the device dtr called.

alc added inline comments.
sys/vm/device_pager.c
171

This initialization isn't really needed. The variable is unconditionally assigned to just a few lines below.

This revision is now accepted and ready to land.Wed, May 8, 6:47 PM
sys/vm/device_pager.c
196–197

Here's my last question: Do we need to worry about concurrent updates to size? Specifically, two concurrent updaters that are setting it to different values? We might end up in the 'then' clause in both cases, and not necessarily wind up with the larger of the values assigned to size.

kib marked an inline comment as done.Wed, May 8, 7:00 PM
kib added inline comments.
sys/vm/device_pager.c
196–197

I am not sure about historic reasons, but I might imagine that some driver relies on extending the pager size.

Is it a problem? The reassignment to the object->size are serialized with dev_pager_mtx.

sys/vm/device_pager.c
196–197

I overlooked dev_pager_mtx still being held in this case.