linux-kernel - Re: [PATCH net-next 1/5] net: ipa: head-of-line block registers are RX only

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: <95f96c77-6dce-8626-9951-124610cf4c31@linaro.org>
Date:   Tue, 30 Jun 2020 17:41:44 -0500
From:   Alex Elder <elder@...aro.org>
To:     David Miller <davem@...emloft.net>
Cc:     kuba@...nel.org, evgreen@...omium.org, subashab@...eaurora.org,
        cpratapa@...eaurora.org, bjorn.andersson@...aro.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 1/5] net: ipa: head-of-line block registers are
 RX only

On 6/30/20 2:21 PM, David Miller wrote:
> From: Alex Elder <elder@...aro.org>
> Date: Mon, 29 Jun 2020 20:09:58 -0500
> 
>> But the reason I was
>> considering it conditional on a config option is that Qualcomm
>> has a crash analysis tool that expects a BUG() call to stop the
>> system so its instant state can be captured.  I don't use this
>> tool, and I might be mistaken about what's required.
> 
> A Qualcomm debugging tool with poorly choosen expectations does not
> determine how we do things in the kernel.

Of course.  I have no problem saying "that can't be done
upstream."  But I wasn't as sure (before now) that the use
of BUG() even in this way would be a "hard no."  I won't
waste any time trying to implement it.

>> What I would *really* like to do is have a way to gracefully
>> shut down just the IPA driver when an unexpected condition occurs,
>> so I can stop everything without crashing the system.  But doing
>> that in a way that works in all cases is Hard.
> 
> Users would like their system and the IPA device to continue, even
> if in a reduced functionality manner, if possible.

Here too, I completely agree, though I might have done a poor
job of conveying that.  My intention is to recover from any
error if possible, even if it means being only partially
functional.

The only conditions I'd ever treat in this way would be those
that mean "we must not go on," basically along the lines of
what you described for BUG_ON() calls.  My point was to try
to isolate the damage done to the IPA device and driver,
rather than killing the system.

					-Alex

> Doing things to make that less likely to be possible is undesirable.