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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 15 Sep 2021 12:39:42 -0700
From:   Stephen Boyd <swboyd@...omium.org>
To:     dikshita@...eaurora.org
Cc:     Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-media@...r.kernel.org, jim.cromie@...il.com,
        Joe Perches <joe@...ches.com>, Jason Baron <jbaron@...mai.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-media-owner@...r.kernel.org,
        Akinobu Mita <akinobu.mita@...il.com>
Subject: Re: [PATCH v5 2/3] venus: Add a debugfs file for SSR trigger

Quoting dikshita@...eaurora.org (2021-09-15 02:13:09)
> Hi Stephen,
>
> Reviving the discussion on this change as we need to pull this in.
>
> As per your suggestion, I explored the fault injection framework to
> implement this functionality.
> But I don't think that meets our requirements.
>
> We need a way to trigger subsystem restart from the client-side, it's
> not derived from the driver.

Just to confirm, this is all for debugging purposes right?

>
> while fault injection framework enables the driver to trigger an
> injection
> when a specific event occurs for eg: page allocation failure or memory
> access failure.
>
> So, IMO, we will have to use custom debugfs only.

Can you use DECLARE_FAULT_ATTR()? Or you need it to be active instead of
passive, i.e. it shouldn't wait for should_fail() to return true, but
actively trigger something on the remoteproc?

>
> Please feel free to correct me in case my understanding of the framework
> is wrong.
>

I presume the fault injection framework could get a new feature that
lets the fault be injected immediately upon writing the debugfs file.
My goal is to consolidate this sort of logic into one place and then put
it behind some config option that distros can disable so the kernel
isn't bloated with debug features that end users will never care about.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ