From: Rusty Russell <rusty@rustcorp.com.au>
To: Asias He <asias@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>
Cc: kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
target-devel@vger.kernel.org,
Stefan Hajnoczi <stefanha@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v7 3/3] tcm_vhost: Add hotplug/hotunplug support
Date: Tue, 23 Apr 2013 13:48:51 +0930 [thread overview]
Message-ID: <87li89g9qs.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20130422152226.GB23376@hj.localdomain>
Asias He <asias@redhat.com> writes:
> On Mon, Apr 22, 2013 at 04:17:04PM +0300, Michael S. Tsirkin wrote:
>> > > > > > > > + evt = kzalloc(sizeof(*evt), GFP_KERNEL);
>> > > > > > >
>> > > > > > > I think kzalloc not needed here, you init all fields.
>> > > > > >
>> > > > > > Not really! evt->event.lun[4-7] is not initialized. It needs to be 0.
>> > > > >
>> > > > > So that is 4 bytes just init them when you set rest of lun.
>> > > >
>> > > > It is not in the fast path. You can do it this way but not a must.
>> > >
>> > > I think that's a bit cleaner than relying on kzalloc to zero-initialize.
>> >
>> > I think it is a bit shorter, 4 lines saved.
>>
>> OTOH you don't have to think "what about the rest of the bytes?" then
>> hunt through the code and go "ah, it's kzalloc".
>> Looks it's a style issue but I prefer explicit initialization.
>
> It is just make none sense to argue about this. If you really want you
> can make patches to remove all the lines where use kzalloc because it is
> cleaner.
I prefer explicit initialization too, FWIW.
>> > > > > > > > +static void tcm_vhost_do_evt_work(struct vhost_scsi *vs,
>> > > > > > > > + struct tcm_vhost_evt *evt)
>> > > > > > > > +{
>> > > > > > > > + struct vhost_virtqueue *vq = &vs->vqs[VHOST_SCSI_VQ_EVT];
>> > > > > > > > + struct virtio_scsi_event *event = &evt->event;
>> > > > > > > > + struct virtio_scsi_event __user *eventp;
>> > > > > > > > + unsigned out, in;
>> > > > > > > > + int head, ret;
>> > > > > > > > +
>> > > > > > > > + if (!tcm_vhost_check_endpoint(vq))
>> > > > > > > > + return;
>> > > > > > > > +
>> > > > > > > > + mutex_lock(&vs->vs_events_lock);
>> > > > > > > > + mutex_lock(&vq->mutex);
>> > > > > > > > +again:
>> > > > > > > > + vhost_disable_notify(&vs->dev, vq);
>> > > > > > > > + head = vhost_get_vq_desc(&vs->dev, vq, vq->iov,
>> > > > > > > > + ARRAY_SIZE(vq->iov), &out, &in,
>> > > > > > > > + NULL, NULL);
>> > > > > > > > + if (head < 0) {
>> > > > > > > > + vs->vs_events_dropped = true;
>> > > > > > > > + goto out;
>> > > > > > > > + }
>> > > > > > > > + if (head == vq->num) {
>> > > > > > > > + if (vhost_enable_notify(&vs->dev, vq))
>> > > > > > > > + goto again;
>> > > > > > >
>> > > > > > > Please write loops with while() or for().
>> > > > > > > Not with goto. goto is for error handling.
>> > > > > >
>> > > > > > This makes extra indention which is more ugly.
>> > > > >
>> > > > > I don't care. No loops with goto and that's a hard rule.
>> > > >
>> > > > It is not a loop.
>> > >
>> > > If same code repeats, it's a loop.
>> >
>> > We really need here is to call vhost_get_vq_desc once. It's not a loop
>> > like other places to use while() or for() with vhost_get_vq_desc.
>>
>> Exactly. Like a mutex for example? We only need to
>> lock it once. See __mutex_lock_common - uses a for loop,
>> doesn't it?
>
> So what?
>
>> So fix this please, use while or for or even until.
>
> I do not think it is necessary.
I tend to use again: in such corner cases, where I don't expect it to
be invoked very often. A do loop looks too normal.
I do exactly the same thing in virtio-net.c, for the same case.
Would you like me to review the entire thing?
Cheers,
Rusty.
next prev parent reply other threads:[~2013-04-23 4:18 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-09 8:51 [PATCH v5 0/3] tcm_vhost hotplug Asias He
2013-04-09 8:51 ` [PATCH v5 1/3] tcm_vhost: Introduce tcm_vhost_check_feature() Asias He
2013-04-09 8:51 ` [PATCH v5 2/3] tcm_vhost: Add helper to check if endpoint is setup Asias He
2013-04-09 8:51 ` [PATCH v5 3/3] tcm_vhost: Add hotplug/hotunplug support Asias He
2013-04-12 23:10 ` [PATCH v5 0/3] tcm_vhost hotplug Nicholas A. Bellinger
2013-04-13 3:20 ` [PATCH v6 " Asias He
2013-04-13 3:20 ` [PATCH v6 1/3] tcm_vhost: Introduce tcm_vhost_check_feature() Asias He
2013-04-13 3:20 ` [PATCH v6 2/3] tcm_vhost: Add helper to check if endpoint is setup Asias He
2013-04-13 3:20 ` [PATCH v6 3/3] tcm_vhost: Add hotplug/hotunplug support Asias He
2013-04-13 3:20 ` Asias He
2013-04-14 8:53 ` [PATCH v5 0/3] tcm_vhost hotplug Michael S. Tsirkin
2013-04-17 13:17 ` Michael S. Tsirkin
2013-04-18 1:05 ` [PATCH v7 " Asias He
2013-04-18 7:36 ` Michael S. Tsirkin
2013-04-18 1:05 ` Asias He
2013-04-18 1:05 ` [PATCH v7 1/3] tcm_vhost: Introduce tcm_vhost_check_feature() Asias He
2013-04-18 7:06 ` Michael S. Tsirkin
2013-04-18 7:06 ` Michael S. Tsirkin
2013-04-18 8:25 ` Asias He
2013-04-18 7:44 ` Michael S. Tsirkin
2013-04-18 1:05 ` [PATCH v7 2/3] tcm_vhost: Add helper to check if endpoint is setup Asias He
2013-04-18 7:09 ` Michael S. Tsirkin
2013-04-18 8:32 ` Asias He
2013-04-18 7:38 ` Michael S. Tsirkin
2013-04-22 8:53 ` Asias He
2013-04-22 8:53 ` Asias He
2013-04-22 13:28 ` Michael S. Tsirkin
2013-04-22 15:00 ` Asias He
2013-04-22 16:21 ` Michael S. Tsirkin
2013-04-22 16:21 ` Michael S. Tsirkin
2013-04-18 1:05 ` Asias He
2013-04-18 1:05 ` [PATCH v7 3/3] tcm_vhost: Add hotplug/hotunplug support Asias He
2013-04-18 1:05 ` Asias He
2013-04-18 7:34 ` Michael S. Tsirkin
2013-04-18 8:59 ` Asias He
2013-04-18 8:21 ` Michael S. Tsirkin
2013-04-19 2:34 ` Asias He
2013-04-20 19:01 ` Michael S. Tsirkin
2013-04-22 9:20 ` Asias He
2013-04-22 13:17 ` Michael S. Tsirkin
2013-04-22 15:22 ` Asias He
2013-04-23 4:18 ` Rusty Russell [this message]
2013-04-23 4:45 ` Asias He
2013-04-18 1:09 ` [PATCH v5 0/3] tcm_vhost hotplug Asias He
2013-04-12 23:10 ` Nicholas A. Bellinger
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=87li89g9qs.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=asias@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=stefanha@redhat.com \
--cc=target-devel@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.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.