Page MenuHomeFreeBSD

Get rid of CTR(9) in linux_futex.c.
AbandonedPublic

Authored by trasz on Mar 13 2021, 7:57 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Oct 18, 12:10 AM
Unknown Object (File)
Fri, Oct 18, 12:10 AM
Unknown Object (File)
Thu, Oct 17, 11:49 PM
Unknown Object (File)
Oct 2 2024, 9:53 AM
Unknown Object (File)
Sep 24 2024, 2:25 AM
Unknown Object (File)
Sep 6 2024, 3:05 AM
Unknown Object (File)
Aug 27 2024, 11:44 PM
Unknown Object (File)
Aug 12 2024, 11:57 PM
Subscribers

Details

Reviewers
dchagin
Group Reviewers
Linux Emulation
Summary

SDT(9) makes them redundant, and they clutter the code.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 37817
Build 34706: arc lint + arc unit

Event Timeline

trasz requested review of this revision.Mar 13 2021, 7:57 PM
dchagin added a subscriber: dchagin.

Disagree, the KTR buffer can be examined in DDB what is really important.

this can be done after PI futex

This revision now requires changes to proceed.Mar 14 2021, 11:32 AM

this can be done after PI futex

Funny you mention that, I’ve just hacked together a simple implementation of LOCK_PI and UNLOCK_PI. It doesn’t handle priorities in any way, but seems good enough to make some things work. I’ll try to clean it up and put up, unless you have something better?

As for CTR - I wonder if we could perhaps generate CTR records from LINUX_SDT macros? (I also have a patch to clean those up, removing the redundant ones, but it’s on top of this one.)

this can be done after PI futex

Funny you mention that, I’ve just hacked together a simple implementation of LOCK_PI and UNLOCK_PI. It doesn’t handle priorities in any way, but seems good enough to make some things work. I’ll try to clean it up and put up, unless you have something better?

sorry, I would prefer a complete implementation with PI as there is no point in simplicity, it won't work broadly. but it's up to you.

As for CTR - I wonder if we could perhaps generate CTR records from LINUX_SDT macros? (I also have a patch to clean those up, removing the redundant ones, but it’s on top of this one.)

CTR usage is minimal so as not to poke around in it's buffer in ddb, futex and thread code only. I see no reason to use the SDT here, it can only be used to research the working code by users, imho

Also: you’re alive! \o/

yes! do you have a project plan?

this can be done after PI futex

Funny you mention that, I’ve just hacked together a simple implementation of LOCK_PI and UNLOCK_PI. It doesn’t handle priorities in any way, but seems good enough to make some things work. I’ll try to clean it up and put up, unless you have something better?

sorry, I would prefer a complete implementation with PI as there is no point in simplicity, it won't work broadly. but it's up to you.

There's some real-world software that depends on those, and providing even not entirely complete implementation seems to make them work. Anyway: I'll clean up the patches a bit, put them up for review, and then we can iterate.

As for CTR - I wonder if we could perhaps generate CTR records from LINUX_SDT macros? (I also have a patch to clean those up, removing the redundant ones, but it’s on top of this one.)

CTR usage is minimal so as not to poke around in it's buffer in ddb, futex and thread code only. I see no reason to use the SDT here, it can only be used to research the working code by users, imho

Well, the problem for me is code like this:

LIN_SDT_PROBE3(futex, futex_get0, new, uaddr, tmpf->f_refcount,
tmpf->f_key.shared);
LINUX_CTR3(sys_futex, "futex_get uaddr %p ref %d shared %d new",
uaddr, tmpf->f_refcount, tmpf->f_key.shared);
*newf = tmpf;

LIN_SDT_PROBE1(futex, futex_get0, return, 0);

That's two lines of actual code per five lines of debugging noise. I have a separate patch that gets rid of a lot of SDT - eg the entry and return probes - leaving just the actually useful ones. I'd rather not get rid of SDT altogether; DTrace is quite convenient.

What I've meant with wrapping CTR in SDT is to basically turn this:

define LIN_SDT_PROBE0(a, b, c)                 SDT_PROBE0(LINUX_DTRACE, a, b, c)

... into something like this:

#define LIN_SDT_PROBE0(a, b, c)                 SDT_PROBE0(LINUX_DTRACE, a, b, c); \
                                                LINUX_CTR0(something, here, a, b, c)

This way we would get both kinds of probes without the code duplication all around the place.

Also: you’re alive! \o/

yes! do you have a project plan?

Kind of. There's a bunch of things in progress, for example there's a patch that adds AT_EMPTY_PATH to our VFS (https://reviews.freebsd.org/D29111), and I have Linuxulator wrappers for some of these; this alone fixes a bunch of problems with Ubuntu Focal. Some newer stuff uses "abstract namespace" for unix sockets, I have a hack that makes those work in a number of cases, but I think it might be worthwhile to look into implementing those properly (ie as really abstract sockets, and not just file paths in disguise). There's a bunch of problems that I believe I have figured out, but don't have patches yet: for example Linux dbus clients cannot talk to FreeBSD dbus server, because they expect the server to use SO_PEERCRED to authenticate them, which it doesn't; the fix here would be to patch the native dbus port to make use of LOCAL_CREDS.

My main focus for the upcoming months, apart from fixing whatever needs to be fixed, is making Linuxulator work on arm64.

Also, there's https://wiki.freebsd.org/LinuxApps, and we could use that to synchronise what we're working on.