From: Gabriel Paubert <paubert@iram.es>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Nicholas Piggin <npiggin@gmail.com>,
Zhouyi Zhou <zhouzhouyi@gmail.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v2] powerpc: Fix irq_soft_mask_set() and irq_soft_mask_return() with sanitizer
Date: Thu, 1 Sep 2022 09:37:42 +0200 [thread overview]
Message-ID: <YxBhRtTuJ4Ut7wUt@lt-gp.iram.es> (raw)
In-Reply-To: <ad5ebb37-6b6f-372c-dd07-fc4cfc5f5fe5@csgroup.eu>
On Thu, Sep 01, 2022 at 05:22:32AM +0000, Christophe Leroy wrote:
>
>
> Le 01/09/2022 à 00:45, Segher Boessenkool a écrit :
> > Hi!
> >
> > On Tue, Aug 30, 2022 at 09:10:02AM +0000, Christophe Leroy wrote:
> >> Le 30/08/2022 à 11:01, Nicholas Piggin a écrit :
> >>> On Tue Aug 30, 2022 at 3:24 PM AEST, Christophe Leroy wrote:
> >>>>> This is still slightly concerning to me. Is there any guarantee that the
> >>>>> compiler would not use a different sequence for the address here?
> >>>>>
> >>>>> Maybe explicit r13 is required.
> >>>>>
> >>>>
> >>>> local_paca is defined as:
> >>>>
> >>>> register struct paca_struct *local_paca asm("r13");
> >
> > And this is in global scope, making it a global register variable.
> >
> >>>> Why would the compiler use another register ?
> >>>
> >>> Hopefully it doesn't. Is it guaranteed that it won't?
> >
> > Yes, this is guaranteed.
> >
> > For a local register variable this is guaranteed only for operands to an
> > extended inline asm; any other access to the variable does not have to
> > put it in the specified register.
> >
> > But this is a global register variable. The only thing that would make
> > this crash and burn is if *any* translation unit did not see this
> > declaration: it could then use r13 (if that was allowed by the ABI in
> > effect, heh).
> >
> >>> I'm sure Segher will be delighted with the creative asm in __do_IRQ
> >>> and call_do_irq :) *Grabs popcorn*
> >
> > All that %% is blinding, yes.
> >
> > Inline tabs are bad taste.
> >
> > Operand names instead of numbers are great for obfuscation, and nothing
> > else -- unless you have more than four or five operands, in which case
> > you have bigger problems already.
> >
> > Oh, this function is a good example of proper use of local register asm,
> > btw.
> >
> > Comments like "// Inputs" are just harmful. As is the "creative"
> > indentation here. Both harm readability and do not help understanding
> > in any other way either.
> >
> > The thing about inline asm is the smallest details change meaning of the
> > whole, it is a very harsh environment, you are programming both in C and
> > directly assembler code as well, and things have to be valid for both,
> > although on the other hand there is almost no error checking. Keeping
> > it small, simple, readable is paramount.
> >
> > The rules for using inline asm:
> >
> > 0) Do no use inline asm.
> > 1) Use extended asm, unless you know all differences with basic asm, and
> > you know you want that. And if you answer "yes I do" to the latter,
> > you answered wrong to the former.
> > 2) Do not use toplevel asm.
> > 3) Do no use inline asm.
> > 4) Do no use inline asm.
> > 5) Do no use inline asm.
> >
> > Inline asm is a very powerful escape hatch. Like all emergency exits,
> > you should not use them if you do not need them! :-)
> >
> > But, you are talking about the function calling and the frame change I
> > bet :-) Both of these are only okay because everything is back as it
> > was when this (single!) asm is done, and the state created is perfectly
> > fine (this is very dependent on exact ABI used, etc.)
> >
> > I would have used real assembler code here (in a .s file). But there
> > probably are reasons to do things this way, performance probably?
>
> We changed it to inline asm in order to ... inline it in the caller.
And there is a single caller it seems. Typically GCC inlines function
with a single call site, but it may be confused by asm statements.
>
> I also find that those operand names make it awull more difficult to
> read that traditional numbering. I really dislike that new trend.
> And same with those // comments, better use meaningfull C variable names.
Agree, but there is one thing which escapes me: why is r3 listed in the
outputs section (actually as a read write operand with the "+"
constraint modifier) but is not used after the asm which is the last
statement of function returning void?
Do I miss something?
Gabriel
next prev parent reply other threads:[~2022-09-01 7:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-23 16:39 [PATCH v2] powerpc: Fix irq_soft_mask_set() and irq_soft_mask_return() with sanitizer Christophe Leroy
2022-08-30 5:15 ` Nicholas Piggin
2022-08-30 5:24 ` Christophe Leroy
2022-08-30 9:01 ` Nicholas Piggin
2022-08-30 9:10 ` Christophe Leroy
2022-08-31 22:45 ` Segher Boessenkool
2022-09-01 5:22 ` Christophe Leroy
2022-09-01 7:37 ` Gabriel Paubert [this message]
2022-09-01 7:47 ` Christophe Leroy
2022-09-01 17:48 ` Segher Boessenkool
2022-09-01 18:07 ` Segher Boessenkool
2022-09-02 15:57 ` Peter Bergner
2022-09-02 17:10 ` Segher Boessenkool
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=YxBhRtTuJ4Ut7wUt@lt-gp.iram.es \
--to=paubert@iram.es \
--cc=christophe.leroy@csgroup.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=npiggin@gmail.com \
--cc=zhouzhouyi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).