From: Jan Beulich <jbeulich@suse.com>
To: Oleksii <oleksii.kurochko@gmail.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Gianluca Guida" <gianluca@rivosinc.com>,
"Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 4/4] xen/x86: switch x86 to use generic implemetation of bug.h
Date: Tue, 28 Feb 2023 17:36:08 +0100 [thread overview]
Message-ID: <89b27c44-5287-ab31-1fa2-46b9762da272@suse.com> (raw)
In-Reply-To: <48e16f406cd85fea531c736f1f213038f8282613.camel@gmail.com>
On 28.02.2023 17:28, Oleksii wrote:
> On Mon, 2023-02-27 at 15:46 +0100, Jan Beulich wrote:
>> On 24.02.2023 12:31, Oleksii Kurochko wrote:
>>> --- a/xen/arch/x86/include/asm/debugger.h
>>> +++ b/xen/arch/x86/include/asm/debugger.h
>>> @@ -14,9 +14,9 @@
>>>
>>> /* Returns true if GDB handled the trap, or it is surviveable. */
>>> static inline bool debugger_trap_fatal(
>>> - unsigned int vector, struct cpu_user_regs *regs)
>>> + unsigned int vector, const struct cpu_user_regs *regs)
>>> {
>>> - int rc = __trap_to_gdb(regs, vector);
>>> + int rc = __trap_to_gdb((struct cpu_user_regs *)regs, vector);
>>
>> I view casts in general as risky and hence preferable to avoid.
>> Casting
>> away const-ness is particularly problematic. I guess the least bad
>> option is to drop const from the do_bug_frame()'s parameter again in
>> patch 1. However, for a fatal trap (assuming that really _is_ fatal,
>> i.e. execution cannot continue), not allowing register state to be
>> altered makes kind of sense. So I wonder whether we couldn't push the
>> casting into the gdbstub functions. But quite likely that's going to
>> be too intrusive for re-work like you do here.
> I am not sure that casting inside the gdbstub functions will help as
> do_bug_frame() calls debugger_trap_fatal() which has define regs
> without const. So it will still be compile issue as in do_bug_frame()
> regs are declared as const.
Well, the idea was of course to propagate const further down, to cast
it away only in restricted cases. But ...
> So it looks like the best one issue now will be drop const from the
> do_bug_frame()...
... looks like we're in agreement then about this being the better
route for the time being.
Jan
prev parent reply other threads:[~2023-02-28 16:36 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-24 11:31 [PATCH v3 0/4] introduce generic implementation of macros from bug.h Oleksii Kurochko
2023-02-24 11:31 ` [PATCH v3 1/4] xen: introduce CONFIG_GENERIC_BUG_FRAME Oleksii Kurochko
2023-02-25 16:42 ` Julien Grall
2023-02-27 9:48 ` Jan Beulich
2023-02-28 17:21 ` Oleksii
2023-02-28 18:01 ` Julien Grall
2023-02-28 20:24 ` Oleksii
2023-02-27 14:23 ` Jan Beulich
2023-02-28 10:30 ` Oleksii
2023-02-28 10:42 ` Jan Beulich
2023-02-24 11:31 ` [PATCH v3 2/4] xen: change <asm/bug.h> to <xen/bug.h> Oleksii Kurochko
2023-02-25 16:47 ` Julien Grall
2023-02-28 12:38 ` Oleksii
2023-02-28 14:04 ` Julien Grall
2023-02-28 13:07 ` Oleksii
2023-02-28 13:30 ` Jan Beulich
2023-02-28 16:00 ` Oleksii
2023-02-27 14:29 ` Jan Beulich
2023-02-28 13:14 ` Oleksii
2023-02-24 11:31 ` [PATCH v3 3/4] xen/arm: switch ARM to use generic implementation of bug.h Oleksii Kurochko
2023-02-25 16:49 ` Julien Grall
2023-02-25 17:05 ` Julien Grall
2023-02-28 17:21 ` Oleksii
2023-02-28 17:57 ` Julien Grall
2023-03-01 12:31 ` Oleksii
2023-03-01 13:58 ` Julien Grall
2023-03-01 15:16 ` Oleksii
2023-03-01 15:21 ` Julien Grall
2023-03-01 15:28 ` Oleksii
2023-03-01 15:58 ` Oleksii
2023-02-28 15:09 ` Oleksii
2023-02-28 17:48 ` Julien Grall
2023-03-01 8:58 ` Oleksii
2023-03-01 9:31 ` Julien Grall
2023-03-01 12:33 ` Oleksii
2023-02-24 11:31 ` [PATCH v3 4/4] xen/x86: switch x86 to use generic implemetation " Oleksii Kurochko
2023-02-27 14:46 ` Jan Beulich
2023-02-28 16:28 ` Oleksii
2023-02-28 16:36 ` Jan Beulich [this message]
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=89b27c44-5287-ab31-1fa2-46b9762da272@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=gianluca@rivosinc.com \
--cc=oleksii.kurochko@gmail.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/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.