* [RFC PATCH 0/2] improve bust_spinlocks dependability @ 2020-10-13 9:49 Paoloni, Gabriele 2020-10-13 9:49 ` [RFC PATCH 1/2] bust_spinlocks: add kernel-doc format doc Paoloni, Gabriele ` (4 more replies) 0 siblings, 5 replies; 14+ messages in thread From: Paoloni, Gabriele @ 2020-10-13 9:49 UTC (permalink / raw) To: linux-safety; +Cc: gabriele.paoloni This patchset provides a kernel-doc documentation format for bust_spinlocks() and fixes a weakness where the global variable oops_in_progress gets unconditionally decremented Gabriele Paoloni (2): bust_spinlocks: add kernel-doc format doc bust_spinlocks: do not decrement oops_in_progress unconditionally lib/bust_spinlocks.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) -- 2.25.1 --------------------------------------------------------------------- INTEL CORPORATION ITALIA S.p.A. con unico socio Sede: Milanofiori Palazzo E 4 CAP 20094 Assago (MI) Capitale Sociale Euro 104.000,00 interamente versato Partita I.V.A. e Codice Fiscale 04236760155 Repertorio Economico Amministrativo n. 997124 Registro delle Imprese di Milano nr. 183983/5281/33 Soggetta ad attivita' di direzione e coordinamento di INTEL CORPORATION, USA This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ^ permalink raw reply [flat|nested] 14+ messages in thread
* [RFC PATCH 1/2] bust_spinlocks: add kernel-doc format doc 2020-10-13 9:49 [RFC PATCH 0/2] improve bust_spinlocks dependability Paoloni, Gabriele @ 2020-10-13 9:49 ` Paoloni, Gabriele 2020-10-14 6:02 ` [linux-safety] " Lukas Bulwahn 2020-10-13 9:49 ` [RFC PATCH 2/2] bust_spinlocks: do not decrement oops_in_progress unconditionally Paoloni, Gabriele ` (3 subsequent siblings) 4 siblings, 1 reply; 14+ messages in thread From: Paoloni, Gabriele @ 2020-10-13 9:49 UTC (permalink / raw) To: linux-safety; +Cc: gabriele.paoloni In the ELISA Linux Foundation project we are trying to improve the functions' documentation to make it more suitable to derive functions' specs and write unit tests. This is needed to make Linux more usable in functional safety systems. So I am adding a proper kernel-doc format for bust_spinlocks. Signed-off-by: Gabriele Paoloni <gabriele.paoloni@intel.com> --- With respect to this patch I have a question on how to set the function context; i.e. I don't know if it can be executed in any context or if it has limitations. --- lib/bust_spinlocks.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/lib/bust_spinlocks.c b/lib/bust_spinlocks.c index 8be59f84eaea..594b270161d9 100644 --- a/lib/bust_spinlocks.c +++ b/lib/bust_spinlocks.c @@ -5,8 +5,6 @@ * Provides a minimal bust_spinlocks for architectures which don't * have one of their own. * - * bust_spinlocks() clears any spinlocks which would prevent oops, die(), BUG() - * and panic() information from reaching the user. */ #include <linux/kernel.h> @@ -17,6 +15,15 @@ #include <linux/vt_kern.h> #include <linux/console.h> +/** + * bust_spinlocks - increases or decreases oops_in_progress. + * if oops_in_progress != 0 spinlocks which would prevent + * oops, die(), BUG() and panic() information from reaching + * the user are busted. + * @yes: input flag; if zero decreases oops_in_progress, + * otherwise increases it. + * + */ void bust_spinlocks(int yes) { if (yes) { -- 2.25.1 --------------------------------------------------------------------- INTEL CORPORATION ITALIA S.p.A. con unico socio Sede: Milanofiori Palazzo E 4 CAP 20094 Assago (MI) Capitale Sociale Euro 104.000,00 interamente versato Partita I.V.A. e Codice Fiscale 04236760155 Repertorio Economico Amministrativo n. 997124 Registro delle Imprese di Milano nr. 183983/5281/33 Soggetta ad attivita' di direzione e coordinamento di INTEL CORPORATION, USA This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [linux-safety] [RFC PATCH 1/2] bust_spinlocks: add kernel-doc format doc 2020-10-13 9:49 ` [RFC PATCH 1/2] bust_spinlocks: add kernel-doc format doc Paoloni, Gabriele @ 2020-10-14 6:02 ` Lukas Bulwahn 2020-10-14 12:20 ` Paoloni, Gabriele 0 siblings, 1 reply; 14+ messages in thread From: Lukas Bulwahn @ 2020-10-14 6:02 UTC (permalink / raw) To: Paoloni, Gabriele; +Cc: linux-safety On Tue, 13 Oct 2020, Paoloni, Gabriele wrote: > In the ELISA Linux Foundation project we are trying to > improve the functions' documentation to make it more suitable > to derive functions' specs and write unit tests. This is needed > to make Linux more usable in functional safety systems. This motivation is very personal but I think it is inappropriate for a commit message. How about: Explain the special purpose of bust_spinlocks(). > So I am adding a proper kernel-doc format for bust_spinlocks. > > Signed-off-by: Gabriele Paoloni <gabriele.paoloni@intel.com> > --- > With respect to this patch I have a question on how to set > the function context; i.e. I don't know if it can be executed > in any context or if it has limitations. > --- > lib/bust_spinlocks.c | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/lib/bust_spinlocks.c b/lib/bust_spinlocks.c > index 8be59f84eaea..594b270161d9 100644 > --- a/lib/bust_spinlocks.c > +++ b/lib/bust_spinlocks.c > @@ -5,8 +5,6 @@ > * Provides a minimal bust_spinlocks for architectures which don't > * have one of their own. > * > - * bust_spinlocks() clears any spinlocks which would prevent oops, die(), BUG() > - * and panic() information from reaching the user. This description reads slightly nicer than the new one below. > */ > > #include <linux/kernel.h> > @@ -17,6 +15,15 @@ > #include <linux/vt_kern.h> > #include <linux/console.h> > > +/** > + * bust_spinlocks - increases or decreases oops_in_progress. > + * if oops_in_progress != 0 spinlocks which would prevent Do not explain the implementation, explain the intent. > + * oops, die(), BUG() and panic() information from reaching > + * the user are busted. > + * @yes: input flag; if zero decreases oops_in_progress, > + * otherwise increases it. I think the argument name 'yes' is terrible, and the documentation adds nothing to resolve the existing terror. What is the semantics of this argument? In which cases should I pass 0 as argument and which cases not? If it is not possible to explain that here, let us not do it and then document other functions instead. > + * > + */ > void bust_spinlocks(int yes) > { > if (yes) { > -- > 2.25.1 > > --------------------------------------------------------------------- > INTEL CORPORATION ITALIA S.p.A. con unico socio > Sede: Milanofiori Palazzo E 4 > CAP 20094 Assago (MI) > Capitale Sociale Euro 104.000,00 interamente versato > Partita I.V.A. e Codice Fiscale 04236760155 > Repertorio Economico Amministrativo n. 997124 > Registro delle Imprese di Milano nr. 183983/5281/33 > Soggetta ad attivita' di direzione e coordinamento di > INTEL CORPORATION, USA > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > > > > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [linux-safety] [RFC PATCH 1/2] bust_spinlocks: add kernel-doc format doc 2020-10-14 6:02 ` [linux-safety] " Lukas Bulwahn @ 2020-10-14 12:20 ` Paoloni, Gabriele 0 siblings, 0 replies; 14+ messages in thread From: Paoloni, Gabriele @ 2020-10-14 12:20 UTC (permalink / raw) To: Lukas Bulwahn; +Cc: linux-safety Hi Lukas > -----Original Message----- > From: linux-safety@lists.elisa.tech <linux-safety@lists.elisa.tech> On Behalf > Of Lukas Bulwahn > Sent: Wednesday, October 14, 2020 8:03 AM > To: Paoloni, Gabriele <gabriele.paoloni@intel.com> > Cc: linux-safety@lists.elisa.tech > Subject: Re: [linux-safety] [RFC PATCH 1/2] bust_spinlocks: add kernel-doc > format doc > > > > On Tue, 13 Oct 2020, Paoloni, Gabriele wrote: > > > In the ELISA Linux Foundation project we are trying to > > improve the functions' documentation to make it more suitable > > to derive functions' specs and write unit tests. This is needed > > to make Linux more usable in functional safety systems. > > This motivation is very personal but I think it is inappropriate for a > commit message. You are right. I'll move this into the cover-letter > > How about: > > Explain the special purpose of bust_spinlocks(). Maybe I will just say: 'bust_spinlocks() is missing a kernel-doc format and is used quite extensively in the fault handling paths of different HW architectures; hence this patch tries to provide a more suitable kernel-doc specification for this function ' > > > > So I am adding a proper kernel-doc format for bust_spinlocks. > > > > Signed-off-by: Gabriele Paoloni <gabriele.paoloni@intel.com> > > --- > > With respect to this patch I have a question on how to set > > the function context; i.e. I don't know if it can be executed > > in any context or if it has limitations. > > --- > > lib/bust_spinlocks.c | 11 +++++++++-- > > 1 file changed, 9 insertions(+), 2 deletions(-) > > > > diff --git a/lib/bust_spinlocks.c b/lib/bust_spinlocks.c > > index 8be59f84eaea..594b270161d9 100644 > > --- a/lib/bust_spinlocks.c > > +++ b/lib/bust_spinlocks.c > > @@ -5,8 +5,6 @@ > > * Provides a minimal bust_spinlocks for architectures which don't > > * have one of their own. > > * > > - * bust_spinlocks() clears any spinlocks which would prevent oops, die(), > BUG() > > - * and panic() information from reaching the user. > > This description reads slightly nicer than the new one below. Right but this is the effect of oops_in_progress being = 1 > > > */ > > > > #include <linux/kernel.h> > > @@ -17,6 +15,15 @@ > > #include <linux/vt_kern.h> > > #include <linux/console.h> > > > > +/** > > + * bust_spinlocks - increases or decreases oops_in_progress. > > + * if oops_in_progress != 0 spinlocks which would prevent > > Do not explain the implementation, explain the intent. If I had to derive unit tests from this doc I think I need to explain the main goal of this function (i.e. increasing/decreasing bust_spinlocks)...? > > > + * oops, die(), BUG() and panic() information from reaching > > + * the user are busted. > > + * @yes: input flag; if zero decreases oops_in_progress, > > + * otherwise increases it. > > I think the argument name 'yes' is terrible, and the documentation adds > nothing to resolve the existing terror. Yes it is ugly but I wanted to avoid too many cosmetics.... > > What is the semantics of this argument? > > In which cases should I pass 0 as argument and which cases not? Looking at the code you should pass 1 if you are in the middle of oops(), die(), bug() and you want to make sure your debug messages to be printed, you pass 0 once you have finished printing your msgs. Thanks Gab > > If it is not possible to explain that here, let us not do it and then > document other functions instead. > > > + * > > + */ > > void bust_spinlocks(int yes) > > { > > if (yes) { > > -- > > 2.25.1 > > > > --------------------------------------------------------------------- > > INTEL CORPORATION ITALIA S.p.A. con unico socio > > Sede: Milanofiori Palazzo E 4 > > CAP 20094 Assago (MI) > > Capitale Sociale Euro 104.000,00 interamente versato > > Partita I.V.A. e Codice Fiscale 04236760155 > > Repertorio Economico Amministrativo n. 997124 > > Registro delle Imprese di Milano nr. 183983/5281/33 > > Soggetta ad attivita' di direzione e coordinamento di > > INTEL CORPORATION, USA > > > > This e-mail and any attachments may contain confidential material for > > the sole use of the intended recipient(s). Any review or distribution > > by others is strictly prohibited. If you are not the intended > > recipient, please contact the sender and delete all copies. > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- INTEL CORPORATION ITALIA S.p.A. con unico socio Sede: Milanofiori Palazzo E 4 CAP 20094 Assago (MI) Capitale Sociale Euro 104.000,00 interamente versato Partita I.V.A. e Codice Fiscale 04236760155 Repertorio Economico Amministrativo n. 997124 Registro delle Imprese di Milano nr. 183983/5281/33 Soggetta ad attivita' di direzione e coordinamento di INTEL CORPORATION, USA This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ^ permalink raw reply [flat|nested] 14+ messages in thread
* [RFC PATCH 2/2] bust_spinlocks: do not decrement oops_in_progress unconditionally 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-13 9:49 ` Paoloni, Gabriele 2020-10-14 5:53 ` [linux-safety] " Lukas Bulwahn [not found] ` <163D8465C352C96E.25724@lists.elisa.tech> ` (2 subsequent siblings) 4 siblings, 1 reply; 14+ messages in thread From: Paoloni, Gabriele @ 2020-10-13 9:49 UTC (permalink / raw) To: linux-safety; +Cc: gabriele.paoloni In the current implementation if the input flag is 0 oops_in_progress is unconditionally decremented, thus allowing to become a negative number. Since right now oops_in_progress is a global variable used in the kernel as a conditional flag to check if oops, panic(), BUG() or die() is in progress the current unconditional decrement may lead to unexpected behavior in the Kernel paths conditionally executing over this flag. This patch only decrement oops_in_progress if it is non zero Signed-off-by: Gabriele Paoloni <gabriele.paoloni@intel.com> --- lib/bust_spinlocks.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/lib/bust_spinlocks.c b/lib/bust_spinlocks.c index 594b270161d9..842633ac9130 100644 --- a/lib/bust_spinlocks.c +++ b/lib/bust_spinlocks.c @@ -23,6 +23,9 @@ * @yes: input flag; if zero decreases oops_in_progress, * otherwise increases it. * + * Note: if oops_in_progress is already 0 it will not + * be decreased + * */ void bust_spinlocks(int yes) { @@ -33,7 +36,9 @@ void bust_spinlocks(int yes) unblank_screen(); #endif console_unblank(); - if (--oops_in_progress == 0) + if (oops_in_progress) + oops_in_progress--; + if (!oops_in_progress) wake_up_klogd(); } } -- 2.25.1 --------------------------------------------------------------------- INTEL CORPORATION ITALIA S.p.A. con unico socio Sede: Milanofiori Palazzo E 4 CAP 20094 Assago (MI) Capitale Sociale Euro 104.000,00 interamente versato Partita I.V.A. e Codice Fiscale 04236760155 Repertorio Economico Amministrativo n. 997124 Registro delle Imprese di Milano nr. 183983/5281/33 Soggetta ad attivita' di direzione e coordinamento di INTEL CORPORATION, USA This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [linux-safety] [RFC PATCH 2/2] bust_spinlocks: do not decrement oops_in_progress unconditionally 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 ` Lukas Bulwahn 2020-10-14 12:05 ` Paoloni, Gabriele 0 siblings, 1 reply; 14+ messages in thread From: Lukas Bulwahn @ 2020-10-14 5:53 UTC (permalink / raw) To: Paoloni, Gabriele; +Cc: linux-safety On Tue, 13 Oct 2020, Paoloni, Gabriele wrote: > In the current implementation if the input flag is 0 > oops_in_progress is unconditionally decremented, thus allowing > to become a negative number. Since right now oops_in_progress > is a global variable used in the kernel as a conditional flag > to check if oops, panic(), BUG() or die() is in progress the > current unconditional decrement may lead to unexpected behavior > in the Kernel paths conditionally executing over this flag. > > This patch only decrement oops_in_progress if it is non zero > > Signed-off-by: Gabriele Paoloni <gabriele.paoloni@intel.com> > --- > lib/bust_spinlocks.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/lib/bust_spinlocks.c b/lib/bust_spinlocks.c > index 594b270161d9..842633ac9130 100644 > --- a/lib/bust_spinlocks.c > +++ b/lib/bust_spinlocks.c > @@ -23,6 +23,9 @@ > * @yes: input flag; if zero decreases oops_in_progress, > * otherwise increases it. > * > + * Note: if oops_in_progress is already 0 it will not > + * be decreased > + * > */ > void bust_spinlocks(int yes) > { > @@ -33,7 +36,9 @@ void bust_spinlocks(int yes) > unblank_screen(); > #endif > console_unblank(); > - if (--oops_in_progress == 0) > + if (oops_in_progress) > + oops_in_progress--; > + if (!oops_in_progress) > wake_up_klogd(); I did not get the original motivation stated above. But I believe you meant: 'I think there is race condition here (before this patch).' So do something in this patch: 'And now the race condition is gone?' I think: 'The could be a race condition before, and probably the race condition is still there after this patch.' But maybe I did even get the intent of this patch in the first place... Lukas ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [linux-safety] [RFC PATCH 2/2] bust_spinlocks: do not decrement oops_in_progress unconditionally 2020-10-14 5:53 ` [linux-safety] " Lukas Bulwahn @ 2020-10-14 12:05 ` Paoloni, Gabriele 2020-10-14 15:29 ` Sudip Mukherjee 2020-10-15 6:44 ` Lukas Bulwahn 0 siblings, 2 replies; 14+ messages in thread From: Paoloni, Gabriele @ 2020-10-14 12:05 UTC (permalink / raw) To: Lukas Bulwahn; +Cc: linux-safety 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 > > > > On Tue, 13 Oct 2020, Paoloni, Gabriele wrote: > > > In the current implementation if the input flag is 0 > > oops_in_progress is unconditionally decremented, thus allowing > > to become a negative number. Since right now oops_in_progress > > is a global variable used in the kernel as a conditional flag > > to check if oops, panic(), BUG() or die() is in progress the > > current unconditional decrement may lead to unexpected behavior > > in the Kernel paths conditionally executing over this flag. > > > > This patch only decrement oops_in_progress if it is non zero > > > > Signed-off-by: Gabriele Paoloni <gabriele.paoloni@intel.com> > > --- > > lib/bust_spinlocks.c | 7 ++++++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/lib/bust_spinlocks.c b/lib/bust_spinlocks.c > > index 594b270161d9..842633ac9130 100644 > > --- a/lib/bust_spinlocks.c > > +++ b/lib/bust_spinlocks.c > > @@ -23,6 +23,9 @@ > > * @yes: input flag; if zero decreases oops_in_progress, > > * otherwise increases it. > > * > > + * Note: if oops_in_progress is already 0 it will not > > + * be decreased > > + * > > */ > > void bust_spinlocks(int yes) > > { > > @@ -33,7 +36,9 @@ void bust_spinlocks(int yes) > > unblank_screen(); > > #endif > > console_unblank(); > > - if (--oops_in_progress == 0) > > + if (oops_in_progress) > > + oops_in_progress--; > > + if (!oops_in_progress) > > wake_up_klogd(); > > I did not get the original motivation stated above. > > But I believe you meant: > > 'I think there is race condition here (before this patch).' > > So do something in this patch: 'And now the race condition is gone?' > > > I think: > > 'The could be a race condition before, and probably the race condition is > still there after this patch.' > > 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... Thanks Gab > > Lukas --------------------------------------------------------------------- INTEL CORPORATION ITALIA S.p.A. con unico socio Sede: Milanofiori Palazzo E 4 CAP 20094 Assago (MI) Capitale Sociale Euro 104.000,00 interamente versato Partita I.V.A. e Codice Fiscale 04236760155 Repertorio Economico Amministrativo n. 997124 Registro delle Imprese di Milano nr. 183983/5281/33 Soggetta ad attivita' di direzione e coordinamento di INTEL CORPORATION, USA This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [linux-safety] [RFC PATCH 2/2] bust_spinlocks: do not decrement oops_in_progress unconditionally 2020-10-14 12:05 ` Paoloni, Gabriele @ 2020-10-14 15:29 ` Sudip Mukherjee 2020-10-15 6:44 ` Lukas Bulwahn 1 sibling, 0 replies; 14+ messages in thread From: Sudip Mukherjee @ 2020-10-14 15:29 UTC (permalink / raw) To: Paoloni, Gabriele, Lukas Bulwahn; +Cc: linux-safety 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [linux-safety] [RFC PATCH 2/2] bust_spinlocks: do not decrement oops_in_progress unconditionally 2020-10-14 12:05 ` Paoloni, Gabriele 2020-10-14 15:29 ` Sudip Mukherjee @ 2020-10-15 6:44 ` Lukas Bulwahn 1 sibling, 0 replies; 14+ messages in thread From: Lukas Bulwahn @ 2020-10-15 6:44 UTC (permalink / raw) To: Paoloni, Gabriele; +Cc: linux-safety On Wed, Oct 14, 2020 at 2:05 PM Paoloni, Gabriele <gabriele.paoloni@intel.com> 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 > > > > > > > > On Tue, 13 Oct 2020, Paoloni, Gabriele wrote: > > > > > In the current implementation if the input flag is 0 > > > oops_in_progress is unconditionally decremented, thus allowing > > > to become a negative number. Since right now oops_in_progress > > > is a global variable used in the kernel as a conditional flag > > > to check if oops, panic(), BUG() or die() is in progress the > > > current unconditional decrement may lead to unexpected behavior > > > in the Kernel paths conditionally executing over this flag. > > > > > > This patch only decrement oops_in_progress if it is non zero > > > > > > Signed-off-by: Gabriele Paoloni <gabriele.paoloni@intel.com> > > > --- > > > lib/bust_spinlocks.c | 7 ++++++- > > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > > > diff --git a/lib/bust_spinlocks.c b/lib/bust_spinlocks.c > > > index 594b270161d9..842633ac9130 100644 > > > --- a/lib/bust_spinlocks.c > > > +++ b/lib/bust_spinlocks.c > > > @@ -23,6 +23,9 @@ > > > * @yes: input flag; if zero decreases oops_in_progress, > > > * otherwise increases it. > > > * > > > + * Note: if oops_in_progress is already 0 it will not > > > + * be decreased > > > + * > > > */ > > > void bust_spinlocks(int yes) > > > { > > > @@ -33,7 +36,9 @@ void bust_spinlocks(int yes) > > > unblank_screen(); > > > #endif > > > console_unblank(); > > > - if (--oops_in_progress == 0) > > > + if (oops_in_progress) > > > + oops_in_progress--; > > > + if (!oops_in_progress) > > > wake_up_klogd(); > > > > I did not get the original motivation stated above. > > > > But I believe you meant: > > > > 'I think there is race condition here (before this patch).' > > > > So do something in this patch: 'And now the race condition is gone?' > > > > > > I think: > > > > 'The could be a race condition before, and probably the race condition is > > still there after this patch.' > > > > 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... > Okay, but that is just the contract of this bust_spinlocks() function, right? As you wrote every caller must call bust_spinlocks(1) and ONLY then when they are done bust_spinlocks(0) [if the machine has not halted...]. Maybe if the functions would be bust_spinlocks_{en,dis}able() or bust_spinlocks_{start,stop}() the contract is more clear. But in the end, there are only a few users as far as see, in fault, panic, etc. Of course, if you call bust_spinlocks_stop() before start() bad things happen... use a static analyzer/model checker to see that that pattern never appears :) As I said, the patch looks good; I am looking forward to the feedback. Lukas ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <163D8465C352C96E.25724@lists.elisa.tech>]
* Re: [linux-safety] [RFC PATCH 1/2] bust_spinlocks: add kernel-doc format doc [not found] ` <163D8465C352C96E.25724@lists.elisa.tech> @ 2020-10-13 11:57 ` Paoloni, Gabriele 0 siblings, 0 replies; 14+ messages in thread From: Paoloni, Gabriele @ 2020-10-13 11:57 UTC (permalink / raw) To: Paoloni, Gabriele, linux-safety; +Cc: safety-architecture +CC safety arch mailing list > -----Original Message----- > From: linux-safety@lists.elisa.tech <linux-safety@lists.elisa.tech> On Behalf > Of Paoloni, Gabriele > Sent: Tuesday, October 13, 2020 11:50 AM > To: linux-safety@lists.elisa.tech > Cc: Paoloni, Gabriele <gabriele.paoloni@intel.com> > Subject: [linux-safety] [RFC PATCH 1/2] bust_spinlocks: add kernel-doc > format doc > > In the ELISA Linux Foundation project we are trying to > improve the functions' documentation to make it more suitable > to derive functions' specs and write unit tests. This is needed > to make Linux more usable in functional safety systems. > So I am adding a proper kernel-doc format for bust_spinlocks. > > Signed-off-by: Gabriele Paoloni <gabriele.paoloni@intel.com> > --- > With respect to this patch I have a question on how to set > the function context; i.e. I don't know if it can be executed > in any context or if it has limitations. > --- > lib/bust_spinlocks.c | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/lib/bust_spinlocks.c b/lib/bust_spinlocks.c > index 8be59f84eaea..594b270161d9 100644 > --- a/lib/bust_spinlocks.c > +++ b/lib/bust_spinlocks.c > @@ -5,8 +5,6 @@ > * Provides a minimal bust_spinlocks for architectures which don't > * have one of their own. > * > - * bust_spinlocks() clears any spinlocks which would prevent oops, die(), > BUG() > - * and panic() information from reaching the user. > */ > > #include <linux/kernel.h> > @@ -17,6 +15,15 @@ > #include <linux/vt_kern.h> > #include <linux/console.h> > > +/** > + * bust_spinlocks - increases or decreases oops_in_progress. > + * if oops_in_progress != 0 spinlocks which would prevent > + * oops, die(), BUG() and panic() information from reaching > + * the user are busted. > + * @yes: input flag; if zero decreases oops_in_progress, > + * otherwise increases it. > + * > + */ > void bust_spinlocks(int yes) > { > if (yes) { > -- > 2.25.1 > > --------------------------------------------------------------------- > INTEL CORPORATION ITALIA S.p.A. con unico socio > Sede: Milanofiori Palazzo E 4 > CAP 20094 Assago (MI) > Capitale Sociale Euro 104.000,00 interamente versato > Partita I.V.A. e Codice Fiscale 04236760155 > Repertorio Economico Amministrativo n. 997124 > Registro delle Imprese di Milano nr. 183983/5281/33 > Soggetta ad attivita' di direzione e coordinamento di > INTEL CORPORATION, USA > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > > > --------------------------------------------------------------------- INTEL CORPORATION ITALIA S.p.A. con unico socio Sede: Milanofiori Palazzo E 4 CAP 20094 Assago (MI) Capitale Sociale Euro 104.000,00 interamente versato Partita I.V.A. e Codice Fiscale 04236760155 Repertorio Economico Amministrativo n. 997124 Registro delle Imprese di Milano nr. 183983/5281/33 Soggetta ad attivita' di direzione e coordinamento di INTEL CORPORATION, USA This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <163D8465D1668B95.25724@lists.elisa.tech>]
* Re: [linux-safety] [RFC PATCH 2/2] bust_spinlocks: do not decrement oops_in_progress unconditionally [not found] ` <163D8465D1668B95.25724@lists.elisa.tech> @ 2020-10-13 11:58 ` Paoloni, Gabriele 2020-10-13 13:07 ` [ELISA Safety Architecture WG] " I33399_YAMAGUCHI 0 siblings, 1 reply; 14+ messages in thread From: Paoloni, Gabriele @ 2020-10-13 11:58 UTC (permalink / raw) To: Paoloni, Gabriele, linux-safety; +Cc: safety-architecture +CC safety arch mailing list > -----Original Message----- > From: linux-safety@lists.elisa.tech <linux-safety@lists.elisa.tech> On Behalf > Of Paoloni, Gabriele > Sent: Tuesday, October 13, 2020 11:50 AM > To: linux-safety@lists.elisa.tech > Cc: Paoloni, Gabriele <gabriele.paoloni@intel.com> > Subject: [linux-safety] [RFC PATCH 2/2] bust_spinlocks: do not decrement > oops_in_progress unconditionally > > In the current implementation if the input flag is 0 > oops_in_progress is unconditionally decremented, thus allowing > to become a negative number. Since right now oops_in_progress > is a global variable used in the kernel as a conditional flag > to check if oops, panic(), BUG() or die() is in progress the > current unconditional decrement may lead to unexpected behavior > in the Kernel paths conditionally executing over this flag. > > This patch only decrement oops_in_progress if it is non zero > > Signed-off-by: Gabriele Paoloni <gabriele.paoloni@intel.com> > --- > lib/bust_spinlocks.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/lib/bust_spinlocks.c b/lib/bust_spinlocks.c > index 594b270161d9..842633ac9130 100644 > --- a/lib/bust_spinlocks.c > +++ b/lib/bust_spinlocks.c > @@ -23,6 +23,9 @@ > * @yes: input flag; if zero decreases oops_in_progress, > * otherwise increases it. > * > + * Note: if oops_in_progress is already 0 it will not > + * be decreased > + * > */ > void bust_spinlocks(int yes) > { > @@ -33,7 +36,9 @@ void bust_spinlocks(int yes) > unblank_screen(); > #endif > console_unblank(); > - if (--oops_in_progress == 0) > + if (oops_in_progress) > + oops_in_progress--; > + if (!oops_in_progress) > wake_up_klogd(); > } > } > -- > 2.25.1 > > --------------------------------------------------------------------- > INTEL CORPORATION ITALIA S.p.A. con unico socio > Sede: Milanofiori Palazzo E 4 > CAP 20094 Assago (MI) > Capitale Sociale Euro 104.000,00 interamente versato > Partita I.V.A. e Codice Fiscale 04236760155 > Repertorio Economico Amministrativo n. 997124 > Registro delle Imprese di Milano nr. 183983/5281/33 > Soggetta ad attivita' di direzione e coordinamento di > INTEL CORPORATION, USA > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > > > --------------------------------------------------------------------- INTEL CORPORATION ITALIA S.p.A. con unico socio Sede: Milanofiori Palazzo E 4 CAP 20094 Assago (MI) Capitale Sociale Euro 104.000,00 interamente versato Partita I.V.A. e Codice Fiscale 04236760155 Repertorio Economico Amministrativo n. 997124 Registro delle Imprese di Milano nr. 183983/5281/33 Soggetta ad attivita' di direzione e coordinamento di INTEL CORPORATION, USA This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ELISA Safety Architecture WG] [linux-safety] [RFC PATCH 2/2] bust_spinlocks: do not decrement oops_in_progress unconditionally 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 ` I33399_YAMAGUCHI 2020-10-13 13:39 ` Paoloni, Gabriele 0 siblings, 1 reply; 14+ messages in thread From: I33399_YAMAGUCHI @ 2020-10-13 13:07 UTC (permalink / raw) To: gabriele.paoloni, linux-safety; +Cc: safety-architecture Hi Gab I think so, this patch is good. If you agree to my opinion, please more improve. In a very rare case, the oops_in_progress could be a negative value. Because this decrement/increment is a read-modified statement. On the other hand, shouldn't take exclusions such as spin lock with this function. if (!oops_in_progress) change to if (oops_in_progress <= 0) How about? Best, /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Doctor of Informatics, Specialist Software Fundamental Technology Group Application Development Department Connected & Sharing Solutions Division AISIN AW CO.,LTD. YAMAGUCHI Naoto E-mail: i33399_YAMAGUCHI@aisin-aw.co.jp /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -----Original Message----- From: safety-architecture@lists.elisa.tech <safety-architecture@lists.elisa.tech> On Behalf Of Paoloni, Gabriele Sent: Tuesday, October 13, 2020 8:58 PM To: Paoloni, Gabriele <gabriele.paoloni@intel.com>; linux-safety@lists.elisa.tech Cc: safety-architecture@lists.elisa.tech Subject: Re: [ELISA Safety Architecture WG] [linux-safety] [RFC PATCH 2/2] bust_spinlocks: do not decrement oops_in_progress unconditionally +CC safety arch mailing list > -----Original Message----- > From: linux-safety@lists.elisa.tech <linux-safety@lists.elisa.tech> On > Behalf Of Paoloni, Gabriele > Sent: Tuesday, October 13, 2020 11:50 AM > To: linux-safety@lists.elisa.tech > Cc: Paoloni, Gabriele <gabriele.paoloni@intel.com> > Subject: [linux-safety] [RFC PATCH 2/2] bust_spinlocks: do not > decrement oops_in_progress unconditionally > > In the current implementation if the input flag is 0 oops_in_progress > is unconditionally decremented, thus allowing to become a negative > number. Since right now oops_in_progress is a global variable used in > the kernel as a conditional flag to check if oops, panic(), BUG() or > die() is in progress the current unconditional decrement may lead to > unexpected behavior in the Kernel paths conditionally executing over > this flag. > > This patch only decrement oops_in_progress if it is non zero > > Signed-off-by: Gabriele Paoloni <gabriele.paoloni@intel.com> > --- > lib/bust_spinlocks.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/lib/bust_spinlocks.c b/lib/bust_spinlocks.c index > 594b270161d9..842633ac9130 100644 > --- a/lib/bust_spinlocks.c > +++ b/lib/bust_spinlocks.c > @@ -23,6 +23,9 @@ > * @yes: input flag; if zero decreases oops_in_progress, > * otherwise increases it. > * > + * Note: if oops_in_progress is already 0 it will not > + * be decreased > + * > */ > void bust_spinlocks(int yes) > { > @@ -33,7 +36,9 @@ void bust_spinlocks(int yes) > unblank_screen(); > #endif > console_unblank(); > - if (--oops_in_progress == 0) > + if (oops_in_progress) > + oops_in_progress--; > + if (!oops_in_progress) > wake_up_klogd(); > } > } > -- > 2.25.1 > > --------------------------------------------------------------------- > INTEL CORPORATION ITALIA S.p.A. con unico socio > Sede: Milanofiori Palazzo E 4 > CAP 20094 Assago (MI) > Capitale Sociale Euro 104.000,00 interamente versato Partita I.V.A. e > Codice Fiscale 04236760155 Repertorio Economico Amministrativo n. > 997124 Registro delle Imprese di Milano nr. 183983/5281/33 Soggetta ad > attivita' di direzione e coordinamento di INTEL CORPORATION, USA > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > > > --------------------------------------------------------------------- INTEL CORPORATION ITALIA S.p.A. con unico socio Sede: Milanofiori Palazzo E 4 CAP 20094 Assago (MI) Capitale Sociale Euro 104.000,00 interamente versato Partita I.V.A. e Codice Fiscale 04236760155 Repertorio Economico Amministrativo n. 997124 Registro delle Imprese di Milano nr. 183983/5281/33 Soggetta ad attivita' di direzione e coordinamento di INTEL CORPORATION, USA This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ELISA Safety Architecture WG] [linux-safety] [RFC PATCH 2/2] bust_spinlocks: do not decrement oops_in_progress unconditionally 2020-10-13 13:07 ` [ELISA Safety Architecture WG] " I33399_YAMAGUCHI @ 2020-10-13 13:39 ` Paoloni, Gabriele 0 siblings, 0 replies; 14+ messages in thread From: Paoloni, Gabriele @ 2020-10-13 13:39 UTC (permalink / raw) To: i33399_yamaguchi, linux-safety; +Cc: safety-architecture > -----Original Message----- > From: safety-architecture@lists.elisa.tech <safety- > architecture@lists.elisa.tech> On Behalf Of i33399_yamaguchi@aisin- > aw.co.jp > Sent: Tuesday, October 13, 2020 3:07 PM > To: Paoloni, Gabriele <gabriele.paoloni@intel.com>; linux- > safety@lists.elisa.tech > Cc: safety-architecture@lists.elisa.tech > Subject: Re: [ELISA Safety Architecture WG] [linux-safety] [RFC PATCH 2/2] > bust_spinlocks: do not decrement oops_in_progress unconditionally > > Hi Gab > > I think so, this patch is good. > If you agree to my opinion, please more improve. > In a very rare case, the oops_in_progress could be a negative value. Because > this decrement/increment is a read-modified statement. On the other hand, > shouldn't take exclusions such as spin lock with this function. > > if (!oops_in_progress) > change to > if (oops_in_progress <= 0) > > How about? Mmmmm what you are proposing is right, I was just wondering if it is needed.... Looking in the Kernel source code I am seeing that oops_in_progress is always set to 1 or 0 except in https://elixir.bootlin.com/linux/latest/source/kernel/debug/kdb/kdb_io.c#L578. Here oops_in_progress is incremented and then decremented right after... actually I am wondering if in this file we should call bust_spinlocks() instead of directly incrementing/decremeting the variable.... Thanks Gab > > Best, > /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > Doctor of Informatics, Specialist > Software Fundamental Technology Group > Application Development Department > Connected & Sharing Solutions Division > AISIN AW CO.,LTD. > YAMAGUCHI Naoto > E-mail: i33399_YAMAGUCHI@aisin-aw.co.jp > /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > -----Original Message----- > From: safety-architecture@lists.elisa.tech <safety- > architecture@lists.elisa.tech> On Behalf Of Paoloni, Gabriele > Sent: Tuesday, October 13, 2020 8:58 PM > To: Paoloni, Gabriele <gabriele.paoloni@intel.com>; linux- > safety@lists.elisa.tech > Cc: safety-architecture@lists.elisa.tech > Subject: Re: [ELISA Safety Architecture WG] [linux-safety] [RFC PATCH 2/2] > bust_spinlocks: do not decrement oops_in_progress unconditionally > > +CC safety arch mailing list > > > -----Original Message----- > > From: linux-safety@lists.elisa.tech <linux-safety@lists.elisa.tech> On > > Behalf Of Paoloni, Gabriele > > Sent: Tuesday, October 13, 2020 11:50 AM > > To: linux-safety@lists.elisa.tech > > Cc: Paoloni, Gabriele <gabriele.paoloni@intel.com> > > Subject: [linux-safety] [RFC PATCH 2/2] bust_spinlocks: do not > > decrement oops_in_progress unconditionally > > > > In the current implementation if the input flag is 0 oops_in_progress > > is unconditionally decremented, thus allowing to become a negative > > number. Since right now oops_in_progress is a global variable used in > > the kernel as a conditional flag to check if oops, panic(), BUG() or > > die() is in progress the current unconditional decrement may lead to > > unexpected behavior in the Kernel paths conditionally executing over > > this flag. > > > > This patch only decrement oops_in_progress if it is non zero > > > > Signed-off-by: Gabriele Paoloni <gabriele.paoloni@intel.com> > > --- > > lib/bust_spinlocks.c | 7 ++++++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/lib/bust_spinlocks.c b/lib/bust_spinlocks.c index > > 594b270161d9..842633ac9130 100644 > > --- a/lib/bust_spinlocks.c > > +++ b/lib/bust_spinlocks.c > > @@ -23,6 +23,9 @@ > > * @yes: input flag; if zero decreases oops_in_progress, > > * otherwise increases it. > > * > > + * Note: if oops_in_progress is already 0 it will not > > + * be decreased > > + * > > */ > > void bust_spinlocks(int yes) > > { > > @@ -33,7 +36,9 @@ void bust_spinlocks(int yes) > > unblank_screen(); > > #endif > > console_unblank(); > > - if (--oops_in_progress == 0) > > + if (oops_in_progress) > > + oops_in_progress--; > > + if (!oops_in_progress) > > wake_up_klogd(); > > } > > } > > -- > > 2.25.1 > > > > --------------------------------------------------------------------- > > INTEL CORPORATION ITALIA S.p.A. con unico socio > > Sede: Milanofiori Palazzo E 4 > > CAP 20094 Assago (MI) > > Capitale Sociale Euro 104.000,00 interamente versato Partita I.V.A. e > > Codice Fiscale 04236760155 Repertorio Economico Amministrativo n. > > 997124 Registro delle Imprese di Milano nr. 183983/5281/33 Soggetta ad > > attivita' di direzione e coordinamento di INTEL CORPORATION, USA > > > > This e-mail and any attachments may contain confidential material for > > the sole use of the intended recipient(s). Any review or distribution > > by others is strictly prohibited. If you are not the intended > > recipient, please contact the sender and delete all copies. > > > > > > > > > > > > --------------------------------------------------------------------- > INTEL CORPORATION ITALIA S.p.A. con unico socio > Sede: Milanofiori Palazzo E 4 > CAP 20094 Assago (MI) > Capitale Sociale Euro 104.000,00 interamente versato Partita I.V.A. e Codice > Fiscale 04236760155 Repertorio Economico Amministrativo n. 997124 Registro > delle Imprese di Milano nr. 183983/5281/33 Soggetta ad attivita' di direzione e > coordinamento di INTEL CORPORATION, USA > > This e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). Any review or distribution by others is > strictly prohibited. If you are not the intended recipient, please contact the > sender and delete all copies. > > > > > > > > > > --------------------------------------------------------------------- INTEL CORPORATION ITALIA S.p.A. con unico socio Sede: Milanofiori Palazzo E 4 CAP 20094 Assago (MI) Capitale Sociale Euro 104.000,00 interamente versato Partita I.V.A. e Codice Fiscale 04236760155 Repertorio Economico Amministrativo n. 997124 Registro delle Imprese di Milano nr. 183983/5281/33 Soggetta ad attivita' di direzione e coordinamento di INTEL CORPORATION, USA This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [linux-safety] [RFC PATCH 0/2] improve bust_spinlocks dependability 2020-10-13 9:49 [RFC PATCH 0/2] improve bust_spinlocks dependability Paoloni, Gabriele ` (3 preceding siblings ...) [not found] ` <163D8465D1668B95.25724@lists.elisa.tech> @ 2020-10-14 6:04 ` Lukas Bulwahn 4 siblings, 0 replies; 14+ messages in thread From: Lukas Bulwahn @ 2020-10-14 6:04 UTC (permalink / raw) To: Paoloni, Gabriele; +Cc: linux-safety On Tue, 13 Oct 2020, Paoloni, Gabriele wrote: > This patchset provides a kernel-doc documentation format > for bust_spinlocks() and fixes a weakness where the global > variable oops_in_progress gets unconditionally decremented > > Gabriele Paoloni (2): > bust_spinlocks: add kernel-doc format doc > bust_spinlocks: do not decrement oops_in_progress unconditionally > > lib/bust_spinlocks.c | 18 +++++++++++++++--- > 1 file changed, 15 insertions(+), 3 deletions(-) > Patchset looks good to me! I would love to see the feedback you get. Lukas > -- > 2.25.1 > > --------------------------------------------------------------------- > INTEL CORPORATION ITALIA S.p.A. con unico socio > Sede: Milanofiori Palazzo E 4 > CAP 20094 Assago (MI) > Capitale Sociale Euro 104.000,00 interamente versato > Partita I.V.A. e Codice Fiscale 04236760155 > Repertorio Economico Amministrativo n. 997124 > Registro delle Imprese di Milano nr. 183983/5281/33 > Soggetta ad attivita' di direzione e coordinamento di > INTEL CORPORATION, USA > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > > > > > ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-10-15 6:44 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.