Project

General

Profile

Bug #13987

Updated by Robert Mustacchi 3 months ago

libproc has its own implementation of a doubly-linked list and even has macros for the common @list_next()@ and @list_prev()@ names. While working on #13925 I wanted to be able to share some improvements to the string tab generation between both the kernel and libproc so gcore and the kernel had the same implementation, which was going to involve the list_t. As such, I decided to try and clean things up so we no longer have a bespoke implementation and use the common one. 

 Because the list walking logic was involved in the libproc dmod, I made a more common list dmod and made sure that it would generally be loaded in userland as a bunch of things emed the list_t but don't always have a way of making sure a dmod is loaded (which is currently the only thing in libcmdutils). As this is generally hidden in its own .o (something to change at some point), I ended up going and just forcing this to load whenever libc loads. 

 To test this, I've gone through and focused on the three things we used lists for: 

 1. File list tracking 
 2. core lwp tracking 
 3. fd tracking 

 For fd tracking, I used @pfiles@ against 32-bit and 64-bit cores and live processes and made sure that all the file information didn't change. I made sure to use processes and cores that had socket information and made sure that all of the socket IP address, door links, etc. were all here in both. 

 For lwp tracking, I generally used @pflags@ as a way to visualize this and bits of mdb. Here I verified that output didn't change across 32-bit and 64-bit cores and processes. I also grabbed a linux core and verified that we still see the thread in it as well. I tested against both single-threaded and multi-threaded processes, including processes with gaps in their thread id space due to doors. 

 File iteration is the    most interesting one and the one I did the most testing against so far. Here I've done the following 
 * Loaded up mdb on 32/64-bit cores/processes and verified that @::nm@ was exactly the same (no sorting) 
 * Compared pldd, pmap, and pmap -x on 32-/64-bit processes ad cores. 
 * Used mdb tab completion (recorded via script) to get a dump of ctf types (e.g. @::print@ then tab) and verified that those didn't change. 

 I looked for memory leaks from commands like @pfiles@ and @pflags@. I found existing problems in #13988 and #13989, but did not introduce new ones.

Back