From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: George Dunlap <George.Dunlap@citrix.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Julien Grall <julien@xen.org>,
Daniel Smith <dpsmith@apertussolutions.com>,
Xen-devel <xen-devel@lists.xenproject.org>,
"committers@xenproject.org" <committers@xenproject.org>
Subject: Re: [PATCH] Revert "evtchn: refuse EVTCHNOP_status for Xen-bound event channels"
Date: Tue, 14 May 2024 10:51:50 +0100 [thread overview]
Message-ID: <1ba4d87f-48e2-4332-bcd8-ac891cee8917@citrix.com> (raw)
In-Reply-To: <b14acc58-5d3c-46ed-a300-61f422501d4c@suse.com>
On 14/05/2024 10:25 am, Jan Beulich wrote:
> On 03.04.2024 08:16, Jan Beulich wrote:
>> On 02.04.2024 19:06, Andrew Cooper wrote:
>>> The commit makes a claim without any kind of justification.
>> Well, what does "have no business" leave open?
>>
>>> The claim is false, and the commit broke lsevtchn in dom0.
>> Or alternatively lsevtchn was doing something that was never meant to work
>> (from Xen's perspective).
>>
>>> It is also quite
>>> obvious from XSM_TARGET that it has broken device model stubdoms too.
>> Why would that be "obvious"? What business would a stubdom have to look at
>> Xen's side of an evtchn?
>>
>>> Whether to return information about a xen-owned evtchn is a matter of policy,
>>> and it's not acceptable to short circuit the XSM on the matter.
>> I can certainly accept this as one possible view point. As in so many cases
>> I'm afraid I dislike you putting it as if it was the only possible one.
>>
>> In summary: The supposed justification you claim is missing in the original
>> change is imo also missing here then: What business would any entity in the
>> system have to look at Xen's side of an event channel? Back at the time, 3
>> people agreed that it's "none".
> You've never responded to this reply of mine, or its follow-up. You also
> didn't chime in on the discussion Daniel and I were having. I consider my
> objections unaddressed, and in fact I continue to consider the change to
> be wrong. Therefore it was inappropriate for you to commit it; it needs
> reverting asap. If you're not going to do so, I will.
You tried defending breaking a utility with "well it shouldn't exist then".
You don't have a leg to stand on, and two maintainers of relevant
subsystems here just got tired of bullshit being presented in place of
any credible argument for having done the change in the way you did.
The correct response was "Sorry I broke things. Lets revert this for
now to unbreak, and I'll see about reworking it to not intentionally
subvert Xen's security mechanism".
As it stands, you're 2-1 outvoted, and wasted any sympathy I may have
had for the principle of the change based on the absurdity of your
arguments.
~Andrew
next prev parent reply other threads:[~2024-05-14 9:52 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-02 17:06 [PATCH] Revert "evtchn: refuse EVTCHNOP_status for Xen-bound event channels" Andrew Cooper
2024-04-03 6:16 ` Jan Beulich
2024-04-03 6:52 ` Jan Beulich
2024-04-03 11:50 ` Daniel P. Smith
2024-04-03 11:54 ` Jan Beulich
2024-04-03 13:31 ` Daniel P. Smith
2024-04-04 8:11 ` Jan Beulich
2024-04-03 11:10 ` Daniel P. Smith
2024-04-03 12:05 ` Jan Beulich
2024-04-03 13:27 ` Daniel P. Smith
2024-04-04 7:57 ` Jan Beulich
2024-04-05 5:59 ` Jan Beulich
2024-05-14 9:25 ` Jan Beulich
2024-05-14 9:51 ` Andrew Cooper [this message]
2024-05-14 10:03 ` Jan Beulich
2024-05-14 11:13 ` Julien Grall
2024-05-14 21:35 ` Stefano Stabellini
2024-05-15 7:33 ` Jan Beulich
2024-05-16 19:15 ` Oleksii K.
2024-05-17 7:01 ` Jan Beulich
2024-05-15 10:49 ` Kelly Choi
2024-05-15 12:59 ` George Dunlap
2024-05-16 6:41 ` Jan Beulich
2024-05-17 1:21 ` Stefano Stabellini
2024-05-17 7:04 ` Jan Beulich
2024-05-17 20:28 ` Stefano Stabellini
2024-05-21 6:17 ` Jan Beulich
2024-05-22 1:33 ` Stefano Stabellini
2024-05-17 1:22 ` Daniel P. Smith
2024-05-17 7:24 ` Jan Beulich
2024-04-03 13:35 ` Daniel P. Smith
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=1ba4d87f-48e2-4332-bcd8-ac891cee8917@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=George.Dunlap@citrix.com \
--cc=committers@xenproject.org \
--cc=dpsmith@apertussolutions.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=sstabellini@kernel.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.