linux-kernel - Re: [PATCH v9 21/27] gunyah: vm_mgr: Add framework to add VM Functions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230203175616.GD332@quicinc.com>
Date:   Fri, 3 Feb 2023 23:26:16 +0530
From:   Srivatsa Vaddagiri <quic_svaddagi@...cinc.com>
To:     Elliot Berman <quic_eberman@...cinc.com>
CC:     Bjorn Andersson <quic_bjorande@...cinc.com>,
        Alex Elder <elder@...aro.org>,
        Murali Nalajala <quic_mnalajal@...cinc.com>,
        "Jonathan Corbet" <corbet@....net>,
        Trilok Soni <quic_tsoni@...cinc.com>,
        "Carl van Schaik" <quic_cvanscha@...cinc.com>,
        Prakruthi Deepak Heragu <quic_pheragu@...cinc.com>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob Herring <robh+dt@...nel.org>,
        "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
        Bagas Sanjaya <bagasdotme@...il.com>,
        Catalin Marinas <catalin.marinas@....com>,
        "Will Deacon" <will@...nel.org>, Marc Zyngier <maz@...nel.org>,
        Jassi Brar <jassisinghbrar@...il.com>,
        Sudeep Holla <sudeep.holla@....com>,
        <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-doc@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v9 21/27] gunyah: vm_mgr: Add framework to add VM
 Functions

* Srivatsa Vaddagiri <quic_svaddagi@...cinc.com> [2023-02-03 15:07:14]:

> * Elliot Berman <quic_eberman@...cinc.com> [2023-01-20 14:46:20]:
> 
> > +static struct gunyah_vm_function_driver *__find_function(const char name[GUNYAH_FUNCTION_NAME_SIZE])
> > +	__must_hold(functions_lock)
> > +{
> > +	struct gunyah_vm_function_driver *iter, *drv = NULL;
> > +
> > +	list_for_each_entry(iter, &functions, list) {
> > +		if (!strncmp(iter->name, name, GUNYAH_FUNCTION_NAME_SIZE)) {
> > +			drv = iter;
> > +			break;
> > +		}
> > +	}
> 
> Not sure how much of a hot path this is going to sit in. I can imagine VM boot
> to be in fast path for some cases (VMs spawned on usecase boundaries - I think
> some VMs like in Amazon firecracker boot in fraction of a second). This
> indirection could cost that a bit (linear search + strcmp for the right
> function). IMHO a direct interface (ex: ADD_IOEVENTFD) will be more efficient.

At the minimum, I think you can make iter->name an enum, which will make the
search faster.

-vatsa