All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geliang Tang <geliang@kernel.org>
To: Matthieu Baerts <matttbe@kernel.org>, mptcp@lists.linux.dev
Cc: Geliang Tang <tanggeliang@kylinos.cn>
Subject: Re: [PATCH mptcp-net v2 2/3] selftests: mptcp: close IPC descriptor on server side
Date: Thu, 04 Sep 2025 16:26:13 +0800	[thread overview]
Message-ID: <ea8ac8aff352d819b9caa0abee2ae272991bd2ff.camel@kernel.org> (raw)
In-Reply-To: <d512f8fc-a0ac-4c23-9a13-0b5c4e1ed20f@kernel.org>

Hi Matt,

On Wed, 2025-09-03 at 13:57 +0200, Matthieu Baerts wrote:
> Hi Geliang,
> 
> On 03/09/2025 06:08, Geliang Tang wrote:
> > From: Geliang Tang <tanggeliang@kylinos.cn>
> > 
> > The client-side function 'connect_one_server()' correctly closes
> > the IPC
> > descriptor (a pipe or UNIX socket) after use. However, the server-
> > side
> > functions 'process_one_client()' in both 'mptcp_sockopt.c' and
> > 'mptcp_inq.c'
> > were missing the corresponding 'close()' call for their IPC
> > descriptors.
> > 
> > This omission could lead to resource leaks (file descriptors) in
> > the test
> > server processes over time.
> > 
> > This patch adds the missing 'close(pipefd)' and 'close(unixfd)'
> > calls in the
> > server-side code, ensuring symmetric and correct resource cleanup.
> 
> I don't know if we need such patch. I mean: yes, that's better to
> close
> such FD before closing the application, but then:
> 
> - it is strange to close it in the middle of a function
> (process_one_client()), and not where it has been created (main())
> 

Yes, close it in main() is much better. I added close(pipefds[1]) after
calling server(pipefds[1]) in the new version instead of adding
close(pipefd) in process_one_client().

> - if I'm not mistaken, unixfds[0] / pipefds[0] are not closed in the
> server process.

Yes, indeed. close(pipefds[0]) is missing in the server process too.

> So if you really want to fix that, I think it would be better to
> close
> all these unix FD in the 'main()' function, no?

I also moved 'close(pipefd)' from connect_one_server() to main(), just
after calling client(pipefds[0]). And here's the new version:

        e1 = pipe(pipefds);
        if (e1 < 0)
                die_perror("pipe");

        s = xfork();
        if (s == 0) {
                close(pipefds[0]);
                ret = server(pipefds[1]);
                close(pipefds[1]);
                return ret;
        }

        close(pipefds[1]);

        /* wait until server bound a socket */
        e1 = read(pipefds[0], &e1, 4); 
        assert(e1 == 4); 

        c = xfork();
        if (c == 0) {
                ret = client(pipefds[0]);
                close(pipefds[0]);
                return ret;
        }

        close(pipefds[0]);

Is this better?

Thanks,
-Geliang

> 
> Cheers,
> Matt

  parent reply	other threads:[~2025-09-04  8:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-03  4:08 [PATCH mptcp-net v2 0/3] misc fixes for sockopt selftests Geliang Tang
2025-09-03  4:08 ` [PATCH mptcp-net v2 1/3] selftests: mptcp: close server file descriptor Geliang Tang
2025-09-03  4:08 ` [PATCH mptcp-net v2 2/3] selftests: mptcp: close IPC descriptor on server side Geliang Tang
2025-09-03 11:57   ` Matthieu Baerts
2025-09-03 14:48     ` Matthieu Baerts
2025-09-04  8:26     ` Geliang Tang [this message]
2025-09-10 17:00       ` Matthieu Baerts
2025-09-11  9:13         ` Geliang Tang
2025-09-11  9:43           ` Matthieu Baerts
2025-09-03  4:08 ` [PATCH mptcp-net v2 3/3] selftests: mptcp: sockopt: fix error messages Geliang Tang
2025-09-03 15:25   ` Matthieu Baerts
2025-09-03  6:10 ` [PATCH mptcp-net v2 0/3] misc fixes for sockopt selftests MPTCP CI

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ea8ac8aff352d819b9caa0abee2ae272991bd2ff.camel@kernel.org \
    --to=geliang@kernel.org \
    --cc=matttbe@kernel.org \
    --cc=mptcp@lists.linux.dev \
    --cc=tanggeliang@kylinos.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.