This patch adds DHCP snooping support to libvirt. The learning method for
IP addresses is specified by setting the "ip_learning" variable to one of
"any" [default] (existing IP learning code), "none" (static only addresses)
or "dhcp" (DHCP snooping).
Active leases are saved in a lease file and rel
David Stevens/Beaverton/IBM@IBMUS wrote on 03/22/2012 01:27:10 PM:
>
> This patch adds DHCP snooping support to libvirt. The learning method
for
> IP addresses is specified by setting the "ip_learning" variable to one
of
> "any" [default] (existing IP learning code), "none" (static only
addre
Stefan Berger/Watson/IBM wrote on 03/22/2012 12:22:20 PM:
>
> I tried it. It doesn't apply more than one IP address. The code also
> doesn't apply cleanly to the tip.
>
>Stefan
Stefan,
I did a git pull yesterday to which this patch is
applied; here is the last entry before the patch
David Stevens/Beaverton/IBM wrote on 03/22/2012 04:22:55 PM:
> From: David Stevens/Beaverton/IBM
> To: Stefan Berger/Watson/IBM
> Cc: "Daniel P. Berrange" , libvir-list@redhat.com
> Date: 03/22/2012 04:23 PM
> Subject: Re: [libvirt PATCHv6 1/1] add DHCP snooping
>
> Stefan Berger/Watson/IBM wrote
Stefan Berger/Watson/IBM wrote on 03/22/2012 03:04:53 PM:
>
> I have some concerns about the cancelation of the thread. It can
> hold the snoop lock and get cancelled while holding it. Next time
> that lock is grabbed we will get a deadlock...
>
The snoop lock is acquired in virNWFilterDHCPSno
On 03/22/2012 04:49 PM, David Stevens wrote:
> Stefan Berger/Watson/IBM wrote on 03/22/2012 03:04:53 PM:
>
>>
>> I have some concerns about the cancelation of the thread. It can
>> hold the snoop lock and get cancelled while holding it. Next time
>> that lock is grabbed we will get a deadlock...
Eric Blake wrote on 03/22/2012 03:54:31 PM:
>
> pthread_cancel() tends to imply that you are properly managing signal
> blocking across threads; we haven't used it anywhere else in libvirt,
> and I'm extremely wary of pulling it in now, as there's probably a lot
> of subtle bugs that it would ex
David Stevens/Beaverton/IBM wrote on 03/22/2012 07:26:06 PM:
> From: David Stevens/Beaverton/IBM
> To: Eric Blake
> Cc: libvir-list@redhat.com, Stefan Berger/Watson/IBM@IBMUS
> Date: 03/22/2012 07:26 PM
> Subject: Re: [libvirt] [libvirt PATCHv6 1/1] add DHCP snooping
>
> Er
Stefan Berger/Watson/IBM wrote on 03/22/2012 05:00:45 PM:
> Maybe we should go with the previous code from a while ago which was
> setting a flag for the thread to die. It caused other work-arounds
> to become necessary but at least we don't have to deal with possibly
> async. deaths of threads h
Eric Blake wrote on 03/22/2012 06:54:31 PM:
>
> On 03/22/2012 04:49 PM, David Stevens wrote:
> > Stefan Berger/Watson/IBM wrote on 03/22/2012 03:04:53 PM:
> >
> >>
> >> I have some concerns about the cancelation of the thread. It can
> >> hold the snoop lock and get cancelled while holding it
David Stevens/Beaverton/IBM wrote on 03/22/2012 08:10:44 PM:
> From: David Stevens/Beaverton/IBM
> To: Stefan Berger/Watson/IBM
> Cc: Eric Blake , libvir-list@redhat.com
> Date: 03/22/2012 08:10 PM
> Subject: Re: [libvirt] [libvirt PATCHv6 1/1] add DHCP snooping
>
> Ste
Stefan Berger/Watson/IBM wrote on 03/22/2012 05:33:41 PM:
>
> Ok.
> An idea may be that the threat has to 'find' its snoop request in a
> global list every time it processes a packet. Once it cannot find it
> anymore, it dies. Removing the request from the global list would be
> the way to termi
12 matches
Mail list logo
