linux-kernel - Re: [PATCH v12] i2c: virtio: add a virtio i2c frontend driver

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: <20210705043841.zujwo672nfdndpg2@vireshk-i7>
Date:   Mon, 5 Jul 2021 10:08:41 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Jie Deng <jie.deng@...el.com>
Cc:     linux-i2c@...r.kernel.org,
        virtualization@...ts.linux-foundation.org,
        linux-kernel@...r.kernel.org, wsa@...nel.org,
        wsa+renesas@...g-engineering.com, mst@...hat.com, arnd@...db.de,
        jasowang@...hat.com, andriy.shevchenko@...ux.intel.com,
        yu1.wang@...el.com, shuo.a.liu@...el.com, conghui.chen@...el.com,
        stefanha@...hat.com
Subject: Re: [PATCH v12] i2c: virtio: add a virtio i2c frontend driver

On 05-07-21, 11:45, Jie Deng wrote:
> On 2021/7/5 10:40, Viresh Kumar wrote:
> > On 02-07-21, 16:46, Jie Deng wrote:
> > The right way of doing this is is making this function return - Error on failure
> > and 0 on success. There is no point returning number of successful additions
> > here.
> 
> 
> We need the number for virtio_i2c_complete_reqs to do cleanup. We don't have
> to
> 
> do cleanup "num" times every time. Just do it as needed.

If you do full cleanup here, then you won't required that at the caller site.

> > Moreover, on failures this needs to clean up (free the dmabufs) itself, just
> > like you did i2c_put_dma_safe_msg_buf() at the end. The caller shouldn't be
> > required to handle the error cases by freeing up resources.
> 
> 
> This function will return the number of requests being successfully prepared
> and make sure
> 
> resources of the failed request being freed. And virtio_i2c_complete_reqs
> will free the
> 
> resources of those successful request.

It just looks cleaner to give such responsibility to each and every function,
i.e. if they fail, they should clean stuff up instead of the caller. That's the
normal philosophy you will find across kernel in most of the cases.
 
> > > +static int virtio_i2c_complete_reqs(struct virtqueue *vq,
> > > +				    struct virtio_i2c_req *reqs,
> > > +				    struct i2c_msg *msgs, int nr,
> > > +				    bool fail)
> > > +{
> > > +	struct virtio_i2c_req *req;
> > > +	bool failed = fail;
> > > +	unsigned int len;
> > > +	int i, j = 0;
> > > +
> > > +	for (i = 0; i < nr; i++) {
> > > +		/* Detach the ith request from the vq */
> > > +		req = virtqueue_get_buf(vq, &len);
> > > +
> > > +		/*
> > > +		 * Condition (req && req == &reqs[i]) should always meet since
> > > +		 * we have total nr requests in the vq.
> > > +		 */
> > > +		if (!failed && (WARN_ON(!(req && req == &reqs[i])) ||
> > > +		    (req->in_hdr.status != VIRTIO_I2C_MSG_OK)))
> > What about writing this as:
> > 
> > 		if (!failed && (WARN_ON(req != &reqs[i]) ||
> > 		    (req->in_hdr.status != VIRTIO_I2C_MSG_OK)))
> > 
> > We don't need to check req here since if req is NULL, we will not do req->in_hdr
> > at all.
> 
> 
> It's right here just because the &reqs[i] will never be NULL in our case.
> But if you see
> 
> "virtio_i2c_complete_reqs" as an independent function, you need to check the
> 
> req. From the perspective of the callee, you can't ask the caller always
> give you
> 
> the non-NULL parameters.

We need to keep this driver optimized in its current form. If you see your own
argument here, then why don't you test vq or msgs for a valid pointer ? And even
reqs.

If we know for certain that this will never happen, then it should be optimized.
But if you see a case where reqs[i] can be NULL here, then it would be fine.

> And some tools may give warnings.

I don't see why a tool will raise an error here and if it does, then the tool is
buggy and not the driver. And we don't need to take care of that.

-- 
viresh