Project

General

Profile

Bug #12801

libdiskmgt leaks PROM device information handles like a sieve

Added by Joshua M. Clulow about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Category:
lib - userland libraries
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

In the findevs() routine, we call di_prom_init() to get a PROM device information handle. This handle is stored in the struct search_args, but does not appear to be cleaned up afterwards.

For potentially flimsy reasons, /dev/openprom allows at most 32 handles to be opened at once; a persistent process which uses libdiskmgmt without exiting can end up hanging on to a lot of these handles. While it's conceivable that /dev/openprom should be more flexible, it's assuredly not correct to leak these handles.


Related issues

Related to illumos gate - Bug #8709: teach libdiskmgt about nvme, sata, and xenClosed2017-10-07

Actions

History

#1

Updated by Joshua M. Clulow about 1 month ago

Note that if you're hitting this condition and all /dev/openprom handles are in use, prtconf -d will fail to work:

$ prtconf -d
System Configuration: i86pc
Memory size: 32658 Megabytes
System Peripherals (Software Nodes):

prtconf: di_prom_init() failed.: Resource temporarily unavailable
#2

Updated by Joshua M. Clulow about 1 month ago

  • Gerrit CR set to 708
#3

Updated by Joshua M. Clulow about 1 month ago

  • Related to Bug #8709: teach libdiskmgt about nvme, sata, and xen added
#4

Updated by Joshua M. Clulow about 1 month ago

This appears to be a regression introduced by #8709, which removed the original cleanup code.

#5

Updated by Garrett D'Amore about 1 month ago

I remember running across that limit many years ago and being confounded by it. There is no real reason for it, and it's a shame that it's set so low.

Having said that -- we should definitely fix the bug. But we could probably change the code to support a vastly larger number of cloned file handles. I expect it would be almost trivial to fix that limit.

#6

Updated by Joshua M. Clulow about 1 month ago

Yes I suspect it could just allocate the object it needs and keep it in a list with some less restrictive maximum number of handles. Found the leak, though!

Also available in: Atom PDF