From: "Sudip Mukherjee" <sudip.mukherjee@codethink.co.uk>
To: "Paoloni, Gabriele" <gabriele.paoloni@intel.com>,
Lukas Bulwahn <lukas.bulwahn@gmail.com>
Cc: "linux-safety@lists.elisa.tech" <linux-safety@lists.elisa.tech>
Subject: Re: [linux-safety] [RFC PATCH 2/2] bust_spinlocks: do not decrement oops_in_progress unconditionally
Date: Wed, 14 Oct 2020 16:29:24 +0100 [thread overview]
Message-ID: <0abe6838-f04b-58dc-df0c-dfb97a9272f0@codethink.co.uk> (raw)
In-Reply-To: <MN2PR11MB4158AB45198CAE0BD2EBFA0188050@MN2PR11MB4158.namprd11.prod.outlook.com>
Hi Gab,
On 14/10/2020 13:05, Paoloni, Gabriele wrote:
> Hi Lukas
>
>> -----Original Message-----
>> From: Lukas Bulwahn <lukas.bulwahn@gmail.com>
>> Sent: Wednesday, October 14, 2020 7:53 AM
>> To: Paoloni, Gabriele <gabriele.paoloni@intel.com>
>> Cc: linux-safety@lists.elisa.tech
>> Subject: Re: [linux-safety] [RFC PATCH 2/2] bust_spinlocks: do not
>> decrement oops_in_progress unconditionally
>>
<snip>
>>
>> But maybe I did even get the intent of this patch in the first place...
>
> What I meant is the following scenario:
> Let's assume oops_in_progress = 0, then we have
>
> func_a()
> {
> bust_spinlocks(0);
> }
>
> In this case after the call, with the current implementation oops_in_progress = -1; that is not acceptable...
>
I am not able to see how this can happen. I think all calls of
bust_spinlocks(0) is always after bust_spinlocks(1) has been done. Do
you have any particular usecase or any codepath which can make this
happen? Like, if 'x' happens then bust_spinlocks(0) will called without
a preceding call to bust_spinlocks(1)..
--
Regards
Sudip
next prev parent reply other threads:[~2020-10-14 15:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-13 9:49 [RFC PATCH 0/2] improve bust_spinlocks dependability Paoloni, Gabriele
2020-10-13 9:49 ` [RFC PATCH 1/2] bust_spinlocks: add kernel-doc format doc Paoloni, Gabriele
2020-10-14 6:02 ` [linux-safety] " Lukas Bulwahn
2020-10-14 12:20 ` Paoloni, Gabriele
2020-10-13 9:49 ` [RFC PATCH 2/2] bust_spinlocks: do not decrement oops_in_progress unconditionally Paoloni, Gabriele
2020-10-14 5:53 ` [linux-safety] " Lukas Bulwahn
2020-10-14 12:05 ` Paoloni, Gabriele
2020-10-14 15:29 ` Sudip Mukherjee [this message]
2020-10-15 6:44 ` Lukas Bulwahn
[not found] ` <163D8465C352C96E.25724@lists.elisa.tech>
2020-10-13 11:57 ` [linux-safety] [RFC PATCH 1/2] bust_spinlocks: add kernel-doc format doc Paoloni, Gabriele
[not found] ` <163D8465D1668B95.25724@lists.elisa.tech>
2020-10-13 11:58 ` [linux-safety] [RFC PATCH 2/2] bust_spinlocks: do not decrement oops_in_progress unconditionally Paoloni, Gabriele
2020-10-13 13:07 ` [ELISA Safety Architecture WG] " I33399_YAMAGUCHI
2020-10-13 13:39 ` Paoloni, Gabriele
2020-10-14 6:04 ` [linux-safety] [RFC PATCH 0/2] improve bust_spinlocks dependability Lukas Bulwahn
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=0abe6838-f04b-58dc-df0c-dfb97a9272f0@codethink.co.uk \
--to=sudip.mukherjee@codethink.co.uk \
--cc=gabriele.paoloni@intel.com \
--cc=linux-safety@lists.elisa.tech \
--cc=lukas.bulwahn@gmail.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.