Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tests: cover more Diag-related code #524

Open
matttbe opened this issue Oct 17, 2024 · 4 comments
Open

tests: cover more Diag-related code #524

matttbe opened this issue Oct 17, 2024 · 4 comments
Assignees

Comments

@matttbe
Copy link
Member

matttbe commented Oct 17, 2024

There are some improvements that can be done on the tests side to cover more code in some areas (code coverage), e.g. the Diag part:

  • subflow_get_info_size() from diag.c is not covered
  • mptcp_diag_dump_one() from mptcp_diag.c is not covered
@geliangtang
Copy link
Member

geliangtang commented Nov 7, 2024

Hi Matt, I assigned this issue to myself since my colleague Gang Yan in my group is looking at it.

@geliangtang geliangtang self-assigned this Nov 7, 2024
@matttbe
Copy link
Member Author

matttbe commented Nov 7, 2024

Thanks! A good task to get familiar with the code and the test suite.

Please note that subflow_get_info_size() might move out of net/mptcp with this patch, but if it is easy, it still makes sense to have a test covering this part.

MPTCPimporter pushed a commit that referenced this issue Jan 17, 2025
Through code coverage analysis, it has been identified that the
'mptcp_diag_dump_one' function lacks test coverage on the testing front.

This patch introduces a function in mptcp_sockopt.c, which is built upon
the 'inet_diag' module, and integrates it into the 'mptcp_sockopt.sh' to
execute the 'mptcp_diag_dump_one' function when server bound a socket.

Closes: #524
Signed-off-by: Gang Yan <[email protected]>
Message-Id: <[email protected]>
@matttbe matttbe moved this to In Progress in MPTCP Upstream: Next (6.15) Jan 24, 2025
@Dwyane-Yan
Copy link

Hi Matt, recently I've been trying to accept and parse messages from kernel, but I've encountered quite a few issues. For instance, when I call recvmsg, I get an 'NLMSG_ERROR' which is 'No such file or directory'. When I change '.nlmsg_flags' to 'NLM_F_REQUEST | NLM_F_DUMP', the error doesn't occur, but this results in the kernel not calling the '.dump_one' interface. Do you have any suggestions? Or do you have any experience with overriding the dump_one method in other modules?

@matttbe
Copy link
Member Author

matttbe commented Feb 7, 2025

@Dwyane-Yan no sorry, I'm not sure what is needed here.

My understanding is that dump_one could be used to display info about a specific MPTCP connection by giving the token. Maybe pm_nl_ctl and/org ss can be extended to display info about a specific connection?

Also, because the kernel code is not covered by our test suite, it is possible it doesn't work as expected, and also need to be modified.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: In Progress
Development

No branches or pull requests

3 participants