netdev - Re: [Xen-devel] xen-netback notify DomU to send ARP.

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] [day] [month] [year] [list]

Message-Id: <50ED9E6502000078000B4220@nat28.tlf.novell.com>
Date:	Wed, 09 Jan 2013 15:44:21 +0000
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"Jason Luan" <luanjianhai@....com>
Cc:	"Ian Campbell" <Ian.Campbell@...rix.com>,
	<xen-devel@...ts.xensource.com>, <konrad.wilk@...cle.com>,
	<netdev@...r.kernel.org>
Subject: Re: [Xen-devel] xen-netback notify DomU to send ARP.

>>> On 09.01.13 at 16:37, Jason Luan <luanjianhai@....com> wrote:
> 于 2013年01月09日 21:44, Jan Beulich 写道:
>>>>> On 09.01.13 at 13:28, jianhai luan <jianhai.luan@...cle.com> wrote:
>>>>> +	switch (event) {
>>>>> +	case NETDEV_NOTIFY_PEERS:
>>>>> +		/* Notify frontend to Send gratuitous ARP */
>>>>> +		xenbus_switch_state(be->dev, XenbusStateInitialised);
>>>>> +		xenbus_switch_state(be->dev, );
>>>> This is the sort of change that clearly isn't acceptable, as I don't
>>>> think you have ways to check _all_ existing frontends for their
>>>> compatibility with this. A connected -> connected transition
>>>> might be acceptable (that was done in the block frontend too, for
>>>> implementing dynamic resize), but will likely need to be
>>>> accompanied by a frontend side patch to handle that (which so
>>>> far should be a no-op).
>>> The latest xen net-frontent driver have handled the condition. State
>>> XenbusStateInitialised will do nothing,
>>> but change to XenbusStateConnected will trigger
>>> netdev_notify_peers(netdev) to send ARP.
>> Did you read my earlier reply carefully? You still only talk about
>> (upstream) Linux netfront, but this is not the only (possible)
>> frontend. You should not invoke state transitions that can -
>> even if only theoretically - blow up frontends. And afaict the
> I only want to notify xen-netfront. I don't know what is better way?
> To attainthegoal, i try to modify virtual interrupt, but the way is
> morecomplicated,modified and working. So, i give up the way.
> Would you like to give some suggestion about how to notify xen-netfront?
>> only thing you can safely assume frontends ought to tolerate
>> are transitions from Connected to Connected (or more
>> generally from one state to the same one, but the other
>> states aren't useful here, except maybe the Reconfigur* ones).
> Sorry for that. At the beginning the patch be applied in kernel 2.6.18 to
> fixed one issue. Only XenbusStateInitialised and XenbusStateClosed ( Not
> Reconfigure* one) don't any thing, so i choose the XenbusStateInitialised.
> Do you suggestion that i choose Reconfigure*?

I already said that I think that only a Connected->Connected
transition is to be considered here. Bringing up Reconfigur* was
just to point out that there are other states available that could
be used, but you'd first need to make sure that (a) they aren't
used for anything else and (b) frontends can reasonably be
expected to deal with (ignore) them when not originally aware
of them (as opposed to a Connected->Connected transition,
which all frontends ought to be able to deal with afaict).

Also, when you reply to earlier mails, could you - in order to make
the result readable - insert blank lines between the quoted text
and your responses, please?

Jan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html