linux-kernel - Re: [PATCH -next 1/1] firmware: arm_scmi: Fix possible deadlock in shmem_tx

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]

Message-ID: <KL1PR01MB3510AD021B2258CB789466E3D5259@KL1PR01MB3510.apcprd01.prod.exchangelabs.com>
Date:   Thu, 13 Oct 2022 15:05:43 +0800
From:   YaxiongTian <iambestgod@...look.com>
To:     cristian.marussi@....com
Cc:     iambestgod@...com, james.quinlan@...adcom.com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, sudeep.holla@....com,
        tianyaxiong@...inos.cn
Subject: Re: [PATCH -next 1/1] firmware: arm_scmi: Fix possible deadlock in
 shmem_tx_prepare()

Hi Cristian

    There may be a problem with my qq email client,   I don't see my 
mail in the

communityI had to switch outlook email.Forgive me if you've received 
multiple emails.

 >Problem is anyway, as you said, you'll have to pick this timeout from the
 >related transport scmi_desc (even if as of now the max_rx_timeout for
 >all existent shared mem transport is the same..) and this means anyway
 >adding more complexity to the chain of calls to just to print a warn of
 >some kind in a rare error-situation from which you cannot recover anyway.

   Yes,it has add more complexity about Monitorring this time.For system
stability,the safest thing to do is to abort the transmission.But this will
lose performance due to more complexity in such unusual situation.

 >Due to other unrelated discussions, I was starting to think about
 >exposing some debug-only (Kconfig dependent) SCMI stats like timeouts, 
errors,
 >unpexpected/OoO/late_replies in order to ease the debug and monitoring
 >of the health of a running SCMI stack: maybe this could be a place where
 >to flag this FW issues without changing the spinloop above (or
 >to add the kind of timeout you mentioned but only when some sort of
 >CONFIG_SCMI_DEBUG is enabled...)...still to fully think it through, 
though.

   I think it should active report warn or err rather than user queries the
information manually.(i.e fs_debug way).Becasue in system startup\S1\S3\S4,
user can not queries this flag in Fw,they need get stuck message 
immediately.


Thanks,
Tian