On Mon, Aug 25, 2025 at 12:04 PM Thomas Huth <th...@redhat.com> wrote: > > On 25/08/2025 10.51, Manos Pitsidianakis wrote: > > On Mon, Aug 25, 2025 at 11:47 AM Thomas Huth <th...@redhat.com> wrote: > >> > >> On 25/08/2025 09.30, Manos Pitsidianakis wrote: > >>> On Thu, Aug 21, 2025 at 12:49 PM Thomas Huth <th...@redhat.com> wrote: > >>>> > >>>> From: Thomas Huth <th...@redhat.com> > >>>> > >>>> Currently, we have one lock that is held while a test is looking for > >>>> free ports. However, we are also using different ranges for looking > >>>> for free ports nowadays (PORTS_START is based on the PID of the process), > >>>> so instead of using only one lock, we should rather use a lock per > >>>> range instead. This should help to allow running more tests in parallel. > >>>> > >>>> While we're at it, also create the lock files without executable bit > >>>> (mode is 0o777 by default). > >>>> > >>> > >>> (Unrelated to this patch but the file itself) > >>> > >>> Hm. AF_INET supports binding to port 0 to connect to any available > >>> port (see man 7 ip). Is this not portable? > >> > >> No clue ... but in that case, we'd need to go back to only use one lock for > >> all tests that are running in parallel, so it might cause some more > >> contention? > > > > IIUC there would be no need for locking, since the kernel would return > > a free port for each process. > > That only works within a process, doesn't it? The problem here is that the > test itself does not open the port, it just first needs to figure out a free > port that will be used later. > The test then launches QEMU with that port number, which will then open this > port. Then the test connects to that port number (which it must know) to > interact with QEMU. > If QEMU is using port 0 for that, the test might not have a way to retrieve > the final port number from QEMU in all cases. > > Thomas >
Ah yeah, correct. It depends on what the test wants to do with that port. Thanks -- Manos Pitsidianakis Emulation and Virtualization Engineer at Linaro Ltd
