Project

General

Profile

Actions

Bug #13987

closed

libproc could use standard lists

Added by Robert Mustacchi about 2 months ago. Updated about 1 month ago.

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

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

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.

Actions #1

Updated by Robert Mustacchi about 2 months ago

  • Description updated (diff)
Actions #2

Updated by Robert Mustacchi about 1 month ago

  • Gerrit CR set to 1633
Actions #3

Updated by Electric Monk about 1 month ago

  • Status changed from New to Closed
  • % Done changed from 50 to 100

git commit 50d4d24e9f62b588d2123e06f654ecb230e4857c

commit  50d4d24e9f62b588d2123e06f654ecb230e4857c
Author: Robert Mustacchi <rm@fingolfin.org>
Date:   2021-08-17T16:03:20.000Z

    13987 libproc could use standard lists
    Reviewed by: Toomas Soome <tsoome@me.com>
    Reviewed by: Patrick Mooney <pmooney@pfmooney.com>
    Approved by: Dan McDonald <danmcd@joyent.com>

Actions

Also available in: Atom PDF