Page MenuHomeFreeBSD

Hwpmc log file is not cleaned after profile session is completed
AcceptedPublic

Authored by rajeeb.barman_gmail.com on Sep 9 2019, 9:17 AM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 22 2023, 9:36 PM
Unknown Object (File)
Sep 1 2023, 3:15 AM
Unknown Object (File)
Jul 27 2023, 7:31 PM
Unknown Object (File)
Jul 4 2023, 5:51 PM
Unknown Object (File)
Jun 28 2023, 4:33 AM
Unknown Object (File)
May 11 2023, 9:09 PM
Unknown Object (File)
May 9 2023, 6:47 AM
Unknown Object (File)
May 6 2023, 6:53 AM
Subscribers

Details

Reviewers
mmacy
markj
Summary

pmcstat works fine as process exits every time once it is completed.

However, if the userspace program is not closed, logfile flags is not clear even profiling is closed. flags are cleaned only when process is exited through the function call pmc_process_exit.

Flag po->po_flags is now cleaned after profile is being closed.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

hwpmc log file flag is not cleaned after profile session is completed

pmcstat works fine as process exits every time once it is completed.
However, if the userspace program is not closed, logfile flags is not clear even profiling is closed. flags are cleaned only when process is exited through the function call pmc_process_exit.
Flag po->po_flags is now cleaned after profile is being closed.

This revision is now accepted and ready to land.Nov 1 2019, 9:42 PM

I can see how this solves your problem but I think it's kind of ugly: the state updates should really happen in pmclog_close() or pmclog_deconfigure_log(), or in the worker thread. For instance, the worker thread can clear PMC_PO_SHUTDOWN as it's exiting. This would also ensure that po_flags is updated under pmc_kthread_mtx as required by the locking protocol. I will work on this and write some small test cases for the pmclog-related system calls.

I spent some more time looking at this today. This change can't be committed:

  • pmclog_close() logs an EOF message causes the logging thread to flush all pending buffers and exit. pmclog_close() returns without waiting for the flush to complete: this is necessary because the logging thread might be writing to a pipe, and we need the calling thread to go back and read from it. But, clearing PMC_PO_OWNS_LOGFILE without waiting may cause the logging thread to exit before it logs EOF, and this breaks some existing applications.
  • pmclog_close() doesn't fdrop() the log file reference, so by clearing PMC_PO_OWNS_LOGFILE the change allows unprivileged users to trigger a refcount leak.

With some care I think we can still fix the original issue:

  • Change pmclog_close() to do nothing if po_kthread is NULL, and change the logger thread to clear PMC_PO_SHUTDOWN when it is exiting.
  • Change pmclog_stop_kthread() to clear both PMC_PO_OWNS_LOGFILE and PMC_PO_INITIAL_MAPPINGS_DONE.

Then, in your application, you must first call PMC_OP_CLOSELOG to flush buffers and get EOF. Once that is done, the application must call PMC_OP_CONFIGURELOG with pm_logfd == -1. This causes pmclog_deconfigure_log() to be called.

I implemented the required kernel changes here: https://people.freebsd.org/~markj/patches/hwpmc_log_state_reset.diff
Could you please try this, along with my suggestion for your application?

I shall do it and update you the result.