linux-kernel - RE: [PATCH v1 1/3] remoteproc: qcom: q6v5: Send subdevice notifications before panic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 23 Sep 2022 07:03:10 +0000
From:   Peng Fan <peng.fan@....com>
To:     Gokul krishna Krishnakumar <quic_gokukris@...cinc.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>
CC:     "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
        "linux-remoteproc@...r.kernel.org" <linux-remoteproc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Trilok Soni <quic_tsoni@...cinc.com>,
        Satya Durga Srinivasu Prabhala <quic_satyap@...cinc.com>,
        Rajendra Nayak <quic_rjendra@...cinc.com>,
        Elliot Berman <quic_eberman@...cinc.com>,
        Guru Das Srinagesh <quic_gurus@...cinc.com>
Subject: RE: [PATCH v1 1/3] remoteproc: qcom: q6v5: Send subdevice
 notifications before panic

> Subject: [PATCH v1 1/3] remoteproc: qcom: q6v5: Send subdevice
> notifications before panic
> 
> Subdevice notifications after a remoteproc has crashed are useful to any
> clients that might want to preserve data pertaining to the driver after the
> remoteproc crashed. Sending subdevice notifications before triggering a
> kernel panic gives these drivers the time to do collect this information.
> 
> Change-Id: Id6e55fb038b70f54ff5854d2adff72b74b6a9570

Change-Id should be removed.

> Signed-off-by: Gokul krishna Krishnakumar <quic_gokukris@...cinc.com>
> ---
>  drivers/remoteproc/qcom_q6v5.c | 31
> +++++++++++++++++++++++++++++++  drivers/remoteproc/qcom_q6v5.h |
> 2 ++
>  2 files changed, 33 insertions(+)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5.c
> b/drivers/remoteproc/qcom_q6v5.c index 497acfb..89f5384 100644
> --- a/drivers/remoteproc/qcom_q6v5.c
> +++ b/drivers/remoteproc/qcom_q6v5.c
> @@ -15,6 +15,7 @@
>  #include <linux/soc/qcom/smem.h>
>  #include <linux/soc/qcom/smem_state.h>
>  #include <linux/remoteproc.h>
> +#include <linux/delay.h>

Seq the head file order.

>  #include "qcom_common.h"
>  #include "qcom_q6v5.h"
> 
> @@ -94,6 +95,29 @@ int qcom_q6v5_unprepare(struct qcom_q6v5
> *q6v5)  }  EXPORT_SYMBOL_GPL(qcom_q6v5_unprepare);
> 
> +static void qcom_q6v5_crash_handler_work(struct work_struct *work) {
> +	struct qcom_q6v5 *q6v5 = container_of(work, struct qcom_q6v5,
> crash_handler);
> +	struct rproc *rproc = q6v5->rproc;
> +	struct rproc_subdev *subdev;
> +
> +	mutex_lock(&rproc->lock);
> +
> +	list_for_each_entry_reverse(subdev, &rproc->subdevs, node) {
> +		if (subdev->stop)
> +			subdev->stop(subdev, true);
> +	}
> +
> +	mutex_unlock(&rproc->lock);
> +
> +	/*
> +	 * Temporary workaround until ramdump userspace application
> calls
> +	 * sync() and fclose() on attempting the dump.
> +	 */
> +	msleep(100);

I have no knowledge on your system setup, but just guess this is
not reliable.

> +	panic("Panicking, remoteproc %s crashed\n", q6v5->rproc->name); }

It is remotecore crash, why use panic to crash the Linux side?

> +
>  static irqreturn_t q6v5_wdog_interrupt(int irq, void *data)  {
>  	struct qcom_q6v5 *q6v5 = data;
> @@ -113,6 +137,9 @@ static irqreturn_t q6v5_wdog_interrupt(int irq, void
> *data)
>  		dev_err(q6v5->dev, "watchdog without message\n");
> 
>  	q6v5->running = false;
> +	if (q6v5->rproc->recovery_disabled)
> +		schedule_work(&q6v5->crash_handler);
> +
>  	rproc_report_crash(q6v5->rproc, RPROC_WATCHDOG);
> 
>  	return IRQ_HANDLED;
> @@ -134,6 +161,9 @@ static irqreturn_t q6v5_fatal_interrupt(int irq, void
> *data)
>  		dev_err(q6v5->dev, "fatal error without message\n");
> 
>  	q6v5->running = false;
> +	if (q6v5->rproc->recovery_disabled)
> +		schedule_work(&q6v5->crash_handler);
> +
>  	rproc_report_crash(q6v5->rproc, RPROC_FATAL_ERROR);
> 
>  	return IRQ_HANDLED;
> @@ -354,6 +384,7 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct
> platform_device *pdev,
>  	if (IS_ERR(q6v5->path))
>  		return dev_err_probe(&pdev->dev, PTR_ERR(q6v5->path),
>  				     "failed to acquire interconnect path\n");
> +	INIT_WORK(&q6v5->crash_handler,
> qcom_q6v5_crash_handler_work);
> 
>  	return 0;
>  }
> diff --git a/drivers/remoteproc/qcom_q6v5.h
> b/drivers/remoteproc/qcom_q6v5.h index 5a859c4..b1654be 100644
> --- a/drivers/remoteproc/qcom_q6v5.h
> +++ b/drivers/remoteproc/qcom_q6v5.h
> @@ -29,6 +29,8 @@ struct qcom_q6v5 {
>  	int handover_irq;
>  	int stop_irq;
> 
> +	struct work_struct crash_handler;
> +
>  	bool handover_issued;
> 
>  	struct completion start_done;
> --
> 2.7.4
Regards,
Peng.