From: Jim Fehlig <jfehlig@suse.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: Prevent vif-bridge from adding user-created tap interfaces to a bridge
Date: Fri, 28 Oct 2011 15:17:26 -0600 [thread overview]
Message-ID: <4EAB1BE6.9030501@suse.com> (raw)
In-Reply-To: <1319729714.9436.146.camel@zakaz.uk.xensource.com>
Ian Campbell wrote:
> On Thu, 2011-10-27 at 16:12 +0100, Ian Jackson wrote:
>
>> Jim Fehlig writes ("[Xen-devel] Prevent vif-bridge from adding user-created tap interfaces to a bridge"):
>>
Ok, my original post comes through now on a new thread...
>>> I received a report that vif-bridge adds any tap interface to a bridge,
>>> regardless if xen is running and who created the tap interface. E.g.
>>>
>>> # tunctl -p -t tap42
>>>
>>> will cause vif-bridge to be executed as per the following rule in
>>> xen-backend.rules
>>>
>>> SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add",
>>> RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
>>>
>> Urgh. What a mess.
>>
>>
>>> I'm not sure how to improve the rule to prevent execution of vif-setup
>>> in this case. But it seems better to handle it in vif-bridge anyhow, by
>>> not connecting the interface to a bridge if there is no corresponding
>>> info in xenstore. Something along the lines of the attached quick
>>> patch. Comments?
>>>
>> Aren't tap devices like this created by Xen's qemu ? And as such we
>> should be letting qemu run the script, and not have any hotplug
>> script called by udev.
>>
>
> We explicitly changed away from that scheme not so long ago. The issue
> is that each tap has a vif counterpart which is somewhat logically the
> same device and should be setup the same way, hence via the same
> mechanisms.
>
And qemu isn't involved when using netback.
So how to proceed? Ian C. seemed to hesitantly ACK the patch in the
other thread [1] :). The suggestion to write the info to another path
in xenstore can also be implemented, although IMO, that the path is not
accessible to the frontend would be the only benefit.
Thanks,
Jim
[1] http://lists.xensource.com/archives/html/xen-devel/2011-10/msg02016.html
next prev parent reply other threads:[~2011-10-28 21:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-25 22:34 Prevent vif-bridge from adding user-created tap interfaces to a bridge Jim Fehlig
2011-10-27 15:12 ` Ian Jackson
2011-10-27 15:35 ` Ian Campbell
2011-10-28 21:17 ` Jim Fehlig [this message]
2011-11-03 18:29 ` Jim Fehlig
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=4EAB1BE6.9030501@suse.com \
--to=jfehlig@suse.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/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.