[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/6] xsm: refactor xsm_ops handling
- To: Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 18 Jun 2021 12:26:04 -0400
- Arc-authentication-results: i=1; mx.zohomail.com; dkim=pass header.i=apertussolutions.com; spf=pass smtp.mailfrom=dpsmith@xxxxxxxxxxxxxxxxxxxx; dmarc=pass header.from=<dpsmith@xxxxxxxxxxxxxxxxxxxx>
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1624033568; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=JEcFlCIYiQ9K1LpfSywvu/l9GKUmomfwRNSk+UmgtM4=; b=A4jrXjHtU7NhfFmlVwx2BvsovT10ZIvMgpAibgmwh8tqCz95lkrAxNThRolWuY2qfeYAEcM8T7OUNNB8YzZjaFbUOKCeXbuxLgXkTuPJeoqKj3PbndcNYCbsA63ksqUk7sF4p8p25cdppsHkOPZgBgUQKmPG7+AXpAJaIKiHGEo=
- Arc-seal: i=1; a=rsa-sha256; t=1624033568; cv=none; d=zohomail.com; s=zohoarc; b=kXnR/sGZffRZiaozBMT4wEAGaR8WcbChg3EQD2vpRi2C16XSGIwNNIMXq/BNXHNFW8h9IzJQbr3fuZaLXfQnG/vKTCOTNOULA47LqIt81dtHLpfnyydDfqDB9dzwYrpqD7A7vOfz7WimlFI3Tuj5RiC8A9GBBv8M+8gYxx98YOA=
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Tamas K Lengyel <tamas@xxxxxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx>, Petre Pircalabu <ppircalabu@xxxxxxxxxxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>, Paul Durrant <paul@xxxxxxx>, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, persaur@xxxxxxxxx, christopher.w.clark@xxxxxxxxx, adam.schwalm@xxxxxxxxxx, scott.davis@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Fri, 18 Jun 2021 16:26:27 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 6/18/21 7:44 AM, Jan Beulich wrote:
> On 18.06.2021 13:34, Andrew Cooper wrote:
>> On 18/06/2021 00:39, Daniel P. Smith wrote:
>>> @@ -197,16 +204,21 @@ bool __init has_xsm_magic(paddr_t start)
>>>
>>> int __init register_xsm(struct xsm_operations *ops)
>>> {
>>> - if ( verify(ops) )
>>> + if ( xsm_ops_registered != XSM_OPS_UNREGISTERED )
>>> + return -EAGAIN;
>>
>> I know you moved this around the function, but it really isn't -EAGAIN
>> material any more. It's "too late - nope".
>>
>> -EEXIST is probably best for "I'm never going to tolerate another call".
>>
>>> +
>>> + if ( !ops )
>>> {
>>> - printk(XENLOG_ERR "Could not verify xsm_operations structure\n");
>>> + xsm_ops_registered = XSM_OPS_REG_FAILED;
>>> + printk(XENLOG_ERR "Invalid xsm_operations structure registered\n");
>>> return -EINVAL;
>>
>> Honestly, I'd be half tempted to declare register_xsm() with
>> __nonnull(0) and let the compiler reject any attempt to pass a NULL ops
>> pointer.
>>
>> Both callers pass a pointer to a static singleton objects.
>
> Why check at all when the source of the arguments is all internal?
> We don't check pointers to be non-NULL elsewhere, with a few odd
> exceptions (which imo should all be dropped).
In verify(ops) there was a check on ops for NULL, I pulled that check up
into here as I removed verify(). Based on Andy's comment, this function
is looking like it is on the chopping block as well.
v/r,
dps
|