[Xen-devel] Re: netback commit history

Ian Campbell
Tue, 20 Sep 2011 11:26:58 -0000

On Tue, 2011-09-20 at 12:04 +0100, Jan Beulich wrote:
> Hi Ian,
>
> with the upstream netback introduction consisting of a single big commit
> I wonder whether you could point me to where the full history of it is.

Yeah, that was a bit annoying, luckily I had the foresight to post where
the history was. http://www.gossamer-threads.com/lists/xen/devel/202139
says it is:
        git://xenbits.xen.org/people/ianc/linux-2.6.git
upstream/dom0/backend/netback-history

> I''m asking particularly in the context of us being asked to add a
safety
> check similar to the vif->netbk != NULL one at the beginning of
> xenvif_start_xmit() (also in xenvif_interrupt(), but there we have a
> similar check in place), which hadn''t been in the legacy tree
(obviously)
> nor in the original multiple-tasklets patch that I retained a copy of.

Seems to have come from bc05ada1283eb583c9789c27429af36b034c4a74 in that
history tree and was a conversion from a check for group == -1. That
commit changes from storing a group index to a group pointer so I think
it''s roughly equivalent from a validity point of view.

The original group == -1 check appears to be in the 2.6.32.x pvops
kernels at least, I expect it is also in the multiple tasklet patch
which you have as well?

>  That
> is, I''d like to understand the reasons for this check as it seems
wrong
> to me to have to do it there - I''d rather think that if an
interface got
> disabled, execution shouldn''t even reach that function anymore.

Yes, I''d think that too but I don''t really know. Maybe
Dongxiao
remembers why he added it?

> One thing I wonder about in this context is whether the
> netif_stop_queue() call from xenvif_close() shouldn''t happen
before
> xenvif_down() (not the least for reasons of symmetry with
> xenvif_open()).

I seem to recall looking at that too, it was the same in the old kernels
too and I didn''t know why so I avoided touching it (I was doing too
much
other cleanup at the time to risk it).

Ian.