All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Shyti <andi.shyti@linux.intel.com>
To: Mauro Carvalho Chehab <mauro.chehab@linux.intel.com>
Cc: igt-dev@lists.freedesktop.org,
	Ch Sai Gowtham <sai.gowtham.ch@intel.com>,
	Petri Latvala <petri.latvala@intel.com>,
	Andrzej Hajda <andrzej.hajda@intel.com>
Subject: Re: [igt-dev] [PATCH i-g-t v3 6/6] lib/igt_kmod: properly handle pipewire-pulse
Date: Mon, 16 May 2022 14:49:21 +0200	[thread overview]
Message-ID: <YoJIUSEI0pkzqBku@intel.intel> (raw)
In-Reply-To: <20220506114829.2288273-7-mauro.chehab@linux.intel.com>

Hi Mauro,

> +static void pipewire_reserve_wait(int pipewire_pulse_pid)
> +{
> +	char xdg_dir[PATH_MAX];
> +	const char *homedir;
> +	struct passwd *pw;
> +	proc_t *proc_info;
> +	PROCTAB *proc;
> +
> +	igt_fork(child, 1) {
> +		igt_info("Preventing pipewire-pulse to use the audio drivers\n");
> +
> +		proc = openproc(PROC_FILLCOM | PROC_FILLSTAT | PROC_FILLARG);
> +		igt_assert(proc != NULL);
> +
> +		while ((proc_info = readproc(proc, NULL))) {
> +			if (pipewire_pulse_pid == proc_info->tid)
> +				break;
> +			freeproc(proc_info);
> +		}
> +		closeproc(proc);
> +
> +		/* Sanity check: if it can't find the process, it means it has gone */
> +		if (pipewire_pulse_pid != proc_info->tid)
> +			exit(0);
> +
> +		pw = getpwuid(proc_info->euid);
> +		homedir = pw->pw_dir;
> +		snprintf(xdg_dir, sizeof(xdg_dir), "/run/user/%d", proc_info->euid);
> +		setgid(proc_info->egid);
> +		setuid(proc_info->euid);
> +		clearenv();
> +		setenv("HOME", homedir, 1);
> +		setenv("XDG_RUNTIME_DIR",xdg_dir, 1);
> +		freeproc(proc_info);
> +
> +		exit(system("pw-reserve -n Audio0 -r"));

no exit...

> +	}

... and waitchild().

Like in patch 1 :)

> +}
> +
> +static int pipewire_pw_reserve_pid = 0;
> +
> +/* Maximum time waiting for pw-reserve to start running */
> +#define PIPEWIRE_RESERVE_MAX_TIME 1000 /* milisseconds */
> +
> +int pipewire_pulse_start_reserve(int pipewire_pulse_pid)
> +{
> +	bool is_pw_reserve_running = false;
> +	proc_t *proc_info;
> +	int attempts = 0;
> +	PROCTAB *proc;
> +
> +	if (!pipewire_pulse_pid)
> +		return 0;
> +
> +	pipewire_reserve_wait(pipewire_pulse_pid);
> +
> +	/*
> +	 * Note: using pw-reserve to stop using audio only works with
> +	 * pipewire version 0.3.50 or upper.
> +	 */
> +	for (attempts = 0; attempts < PIPEWIRE_RESERVE_MAX_TIME; attempts++) {
> +		usleep(1000);
> +		proc = openproc(PROC_FILLCOM | PROC_FILLSTAT | PROC_FILLARG);
> +		igt_assert(proc != NULL);
> +
> +		while ((proc_info = readproc(proc, NULL))) {
> +			if (!strcmp(proc_info->cmd, "pw-reserve")) {
> +				is_pw_reserve_running = true;
> +				pipewire_pw_reserve_pid = proc_info->tid;
> +				freeproc(proc_info);
> +				break;
> +			}
> +			freeproc(proc_info);
> +		}
> +		closeproc(proc);
> +		if (is_pw_reserve_running)
> +			break;
> +	}
> +	if (!is_pw_reserve_running) {
> +		igt_warn("Failed to remove audio drivers from pipewire\n");
> +		return 1;
> +	}
> +	/* Let's grant some time for pw_reserve to notify pipewire via D-BUS */
> +	usleep(50000);
> +
> +	/*
> +	 * pw-reserve is running, and should have stopped using the audio
> +	 * drivers. We can now remove the driver.
> +	 */
> +
> +	return 0;
> +}
> +
> +void pipewire_pulse_stop_reserve(int pipewire_pulse_pid)
> +{
> +	if (!pipewire_pulse_pid)
> +		return;
> +
> +	igt_killchildren(SIGTERM);

why do we need the sigterm? I guess here you need to modify
kill_children so that it kills with a signal. Otherwise this
SIGTERM is useless.

>  /**
>   * __igt_lsof_audio_and_kill_proc() - check if a given process is using an
>   *	audio device. If so, stop or prevent them to use such devices.
>   *
>   * @proc_info: process struct, as returned by readproc()
>   * @proc_path: path of the process under procfs
> + * @pipewire_pulse_pid: PID of pipewire-pulse process
>   *
>   * No processes can be using an audio device by the time it gets removed.
>   * This function checks if a process is using an audio device from /dev/snd.
> @@ -1448,10 +1550,15 @@ static void pulseaudio_unload_module(proc_t *proc_info)
>   * 	- if the process is pulseaudio, it can't be killed, as systemd will
>   * 	  respawn it. So, instead, send a request for it to stop bind the
>   * 	  audio devices.
> + *	- if the process is pipewire-pulse, it can't be killed, as systemd will
> + *	  respawn it. So, instead, the caller should call pw-reserve, remove
> + *	  the kernel driver and then stop pw-reserve. On such case, this
> + *	  function returns the PID of pipewire-pulse, but won't touch it.
>   * If the check fails, it means that the process can simply be killed.
>   */
>  static int
> -__igt_lsof_audio_and_kill_proc(proc_t *proc_info, char *proc_path)
> +__igt_lsof_audio_and_kill_proc(proc_t *proc_info, char *proc_path,
> +			       int *pipewire_pulse_pid)

Still I think that this is becoming messy. We are carrying this
pipewire_pulse_pid from function to function with a possible
value of '0'.

Anyway, I will not insist on this.

[...]

> +void igt_killchildren(int signal)
> +{
> +	igt_info("Timed out waiting for children\n");
> +
> +	kill_children();
> +}

As I said before, we don't really need for int signal. And I
think this should in a different patch as this is a change in
igt_core?

Andi

  reply	other threads:[~2022-05-16 12:49 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-06 11:48 [igt-dev] [PATCH i-g-t v3 0/6] Improve logic to work with audio dependency on DRM driver Mauro Carvalho Chehab
2022-05-06 11:48 ` [igt-dev] [PATCH i-g-t v3 1/6] tests/core_hotunplug: properly finish processes using audio devices Mauro Carvalho Chehab
2022-05-11 17:03   ` Lucas De Marchi
2022-05-12  6:49     ` Mauro Carvalho Chehab
2022-05-16  7:24       ` Lucas De Marchi
2022-05-16  8:04         ` Mauro Carvalho Chehab
2022-05-16 12:31   ` Andi Shyti
2022-05-06 11:48 ` [igt-dev] [PATCH i-g-t v3 2/6] lib/igt_kmod: always fill who when unloading audio driver Mauro Carvalho Chehab
2022-05-06 11:48 ` [igt-dev] [PATCH i-g-t v3 3/6] lib/igt_kmod: improve audio unbind logic Mauro Carvalho Chehab
2022-05-11 17:09   ` Lucas De Marchi
2022-05-16  6:55     ` Mauro Carvalho Chehab
2022-05-16 12:30   ` Andi Shyti
2022-05-16 13:23     ` Mauro Carvalho Chehab
2022-05-06 11:48 ` [igt-dev] [PATCH i-g-t v3 4/6] core_hotunplug: fix " Mauro Carvalho Chehab
2022-05-06 11:48 ` [igt-dev] [PATCH i-g-t v3 5/6] lib/igt_kmod: make it less pedantic with audio driver removal Mauro Carvalho Chehab
2022-05-06 11:48 ` [igt-dev] [PATCH i-g-t v3 6/6] lib/igt_kmod: properly handle pipewire-pulse Mauro Carvalho Chehab
2022-05-16 12:49   ` Andi Shyti [this message]
2022-05-16 13:35     ` Mauro Carvalho Chehab
2022-05-16 16:51       ` Mauro Carvalho Chehab
2022-05-06 12:10 ` [igt-dev] ✓ Fi.CI.BAT: success for Improve logic to work with audio dependency on DRM driver Patchwork
2022-05-06 14:23 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork

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=YoJIUSEI0pkzqBku@intel.intel \
    --to=andi.shyti@linux.intel.com \
    --cc=andrzej.hajda@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=mauro.chehab@linux.intel.com \
    --cc=petri.latvala@intel.com \
    --cc=sai.gowtham.ch@intel.com \
    /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.