* Re: request to queue patches for stable
From: David Miller @ 2012-12-14 20:38 UTC (permalink / raw)
To: caiqian; +Cc: netdev
In-Reply-To: <1907800187.6214689.1355191395335.JavaMail.root@redhat.com>
From: CAI Qian <caiqian@redhat.com>
Date: Mon, 10 Dec 2012 21:03:15 -0500 (EST)
>
>
> ----- Original Message -----
>> From: "David Miller" <davem@davemloft.net>
>> To: caiqian@redhat.com
>> Cc: greg@kroah.com, stable@vger.kernel.org, mbizon@freebox.fr, ja@ssi.bg
>> Sent: Friday, December 7, 2012 11:23:21 AM
>> Subject: Re: [PATCH] ipv4: do not cache looped multicasts
>>
>> From: CAI Qian <caiqian@redhat.com>
>> Date: Thu, 6 Dec 2012 21:56:35 -0500 (EST)
>>
>> > OK, I have a few network patches in the queue that looks applicable
>> > to
>> > the stable as well. I think I'll send them out here too to seek
>> > their
>> > ACKs. David, please let me know if I should stop doing this.
>>
>> Please stop doing this.
>>
>> If you want networking patches to reach stable, first
>> consult:
>>
>> http://patchwork.ozlabs.org/bundle/davem/stable/
>>
>> to see if the patch you want isn't queued up already.
>>
>> If it is not, ask me to queue it up on netdev@vger.kernel.org
>>
>> But note that I like to let networking patches "cook" upstream
>> in Linus's tree for a certain amount of time before I submit
>> them to -stable. There can be up to even a week or two.
> Dave, the following patches looks applicable for the stable
> releases. Please queue them up if you agree.
>
> 0e376bd0b791ac6ac6bdb051492df0769c840848 (for 3.0.x, 3.4.x and 3.6.x)
> e196c0e579902f42cf72414461fb034e5a1ffbf7 (for 3.0.x, 3.4.x and 3.6.x)
> 6e51fe7572590d8d86e93b547fab6693d305fd0d (for 3.0.x, 3.4.x and 3.6.x)
> e1a676424c290b1c8d757e3860170ac7ecd89af4 (for 3.6.x)
> 636174219b52b5a8bc51bc23bbcba97cd30a65e3 (for 3.6.x)
What is the point of my publishing the pending networking -stable
queue if you're not even going to check it? Those last two patches
were already queued up.
Furthermore, it is erroneous to suggest the -ENOMEM SCTP fix without
the memory leak fix that happens in the commit right before it.
I've queued things up appropriately, but I really don't appreciate
how you've handled this at all. It makes a lot more work for me than
necessary.
^ permalink raw reply
* Re: [PATCH] tuntap: fix ambigious multiqueue API
From: Paul Moore @ 2012-12-14 21:21 UTC (permalink / raw)
To: Jason Wang; +Cc: mst, davem, netdev, linux-kernel, mprivozn, wkevils
In-Reply-To: <1355478810-10144-1-git-send-email-jasowang@redhat.com>
On Friday, December 14, 2012 05:53:30 PM Jason Wang wrote:
> The current multiqueue API is ambigious which may confuse both user and LSM
> to do things correctly:
>
> - Both TUNSETIFF and TUNSETQUEUE could be used to create the queues of a
> tuntap device.
> - TUNSETQUEUE were used to disable and enable a specific queue of the
> device. But since the state of tuntap were completely removed from the
> queue, it could be used to attach to another device (there's no such kind
> of requirement currently, and it needs new kind of LSM policy.
> - TUNSETQUEUE could be used to attach to a persistent device without any
> queues. This kind of attching bypass the necessary checking during
> TUNSETIFF and may lead unexpected result.
>
> So this patch tries to make a cleaner and simpler API by:
>
> - Only allow TUNSETIFF to create queues.
> - TUNSETQUEUE could be only used to disable and enabled the queues of a
> device, and the state of the tuntap device were not detachd from the queues
> when it was disabled, so TUNSETQUEUE could be only used after TUNSETIFF and
> with the same device.
>
> This is done by introducing a list which keeps track of all queues which
> were disabled. The queue would be moved between this list and tfiles[]
> array when it was enabled/disabled. A pointer of the tun_struct were also
> introdued to track the device it belongs to when it was disabled.
>
> After the change, the isolation between management and application could be
> done through: TUNSETIFF were only called by management software and
> TUNSETQUEUE were only called by application.For LSM/SELinux, the things
> left is to do proper check during tun_set_queue() if needed.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Let me digest these changes and I'll respin the LSM/SELinux multiqueue fixes
and send them back out for re-discussion/review.
--
paul moore
security and virtualization @ redhat
^ permalink raw reply
* Re: [Netperf PATCH] output remote_send_size in TCP_MAERTS result
From: Rick Jones @ 2012-12-14 21:27 UTC (permalink / raw)
To: Amos Kong; +Cc: netdev
In-Reply-To: <1355482148-31407-1-git-send-email-akong@redhat.com>
On 12/14/2012 02:49 AM, Amos Kong wrote:
> When I executed TCP_MAERTS by following command line:
> netperf-2.6.0 -H 192.168.58.23 -l 10 -C -t TCP_MAERTS -- -m 512,1024
> The outputed send size is '512'.
>
> When I executed TCP_MAERTS by following command line:
> netperf-2.6.0 -H 192.168.58.23 -l 10 -t TCP_MAERTS -- -m 512,1024
> The outputed send size is '1024'.
>
> In TCP_MAERTS test, we should output the remote send size '1024',
> this patch fixed this issue.
Hi Amos -
While I suspect at least a few folks on the netdev list are interested
in "things netperf," netperf is not maintained via the netdev list.
There are two lists hosted on netperf.org which pertain to "things
netperf." The first is netperf-talk which is geared towards users. The
second netperf-dev which is geared towards those developing netperf.
No need to re-post there this time (though feel free to for the
archives), I've gone ahead and applied the fix to the netperf top-of-trunk.
happy benchmarking,
rick jones
^ permalink raw reply
* Re: [PATCH] Fix comment for packets without data
From: Rick Jones @ 2012-12-14 21:28 UTC (permalink / raw)
To: Florent Fourcot; +Cc: pablo, yoshfuji, netdev, netfilter-devel
In-Reply-To: <1355482413-18629-1-git-send-email-florent.fourcot@enst-bretagne.fr>
On 12/14/2012 02:53 AM, Florent Fourcot wrote:
> Remove ambiguity of double negation
>
> Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
> ---
> net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c b/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c
> index 00ee17c..137e245 100644
> --- a/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c
> +++ b/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c
> @@ -81,8 +81,8 @@ static int ipv6_get_l4proto(const struct sk_buff *skb, unsigned int nhoff,
> }
> protoff = ipv6_skip_exthdr(skb, extoff, &nexthdr, &frag_off);
> /*
> - * (protoff == skb->len) mean that the packet doesn't have no data
> - * except of IPv6 & ext headers. but it's tracked anyway. - YK
> + * (protoff == skb->len) means the packet has not data, just
> + * IPv6 and possibly extensions headers, but it is tracked anyway
> */
> if (protoff < 0 || (frag_off & htons(~0x7)) != 0) {
> pr_debug("ip6_conntrack_core: can't find proto in pkt\n");
>
Acked-by: Rick Jones <rick.jones2@hp.com>
rick
^ permalink raw reply
* pull-request: can 2012-12-14
From: Marc Kleine-Budde @ 2012-12-14 21:33 UTC (permalink / raw)
To: netdev; +Cc: linux-can, sfr, davem
Hello David,
here's a patch for net for the v3.8 release cycle. Randy Dunlap found a
compilation problem of the sja1000_of_platform driver on X86_32. A patch by me
fixes the problem.
regards, Marc
---
The following changes since commit 17bc14b767cf0692420c43dbe5310ae98a5a7836:
Revert "sched: Update_cfs_shares at period edge" (2012-12-14 07:20:43 -0800)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can.git fixes-for-3.8
for you to fetch changes up to 27d5155f676598e461d9038eadf77bfebce48f30:
can: sja1000: fix compilation on x86 (2012-12-14 22:07:10 +0100)
----------------------------------------------------------------
Marc Kleine-Budde (1):
can: sja1000: fix compilation on x86
drivers/net/can/sja1000/sja1000_of_platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* [PATCH] can: sja1000: fix compilation on x86
From: Marc Kleine-Budde @ 2012-12-14 21:33 UTC (permalink / raw)
To: netdev; +Cc: linux-can, sfr, davem, Marc Kleine-Budde, Andreas Larsson
In-Reply-To: <1355520824-23175-1-git-send-email-mkl@pengutronix.de>
Since commit:
04df251 can: sja1000: Make sja1000_of_platform selectable and compilable on SPARC
the driver can be activated on non powerpc platform like x86 or sparc. Without
this patch the driver fails to compile on platform that don't define NO_IRQ,
like x86.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/sja1000/sja1000_of_platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/sja1000/sja1000_of_platform.c b/drivers/net/can/sja1000/sja1000_of_platform.c
index 0f59170..38d37c8 100644
--- a/drivers/net/can/sja1000/sja1000_of_platform.c
+++ b/drivers/net/can/sja1000/sja1000_of_platform.c
@@ -121,7 +121,7 @@ static int sja1000_ofp_probe(struct platform_device *ofdev)
}
irq = irq_of_parse_and_map(np, 0);
- if (irq == NO_IRQ) {
+ if (irq <= 0) {
dev_err(&ofdev->dev, "no irq found\n");
err = -ENODEV;
goto exit_unmap_mem;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] can: sja1000: fix compilation on x86
From: David Miller @ 2012-12-14 21:37 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, sfr, andreas
In-Reply-To: <1355520824-23175-2-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Fri, 14 Dec 2012 22:33:44 +0100
> @@ -121,7 +121,7 @@ static int sja1000_ofp_probe(struct platform_device *ofdev)
> }
>
> irq = irq_of_parse_and_map(np, 0);
> - if (irq == NO_IRQ) {
> + if (irq <= 0) {
> dev_err(&ofdev->dev, "no irq found\n");
> err = -ENODEV;
> goto exit_unmap_mem;
I don't see anything existing which says this is the proper
transformation.
There is no consistency at all for the tests of the return
value of irq_of_parse_and_map().
And if anything testing against zero is the correct thing to
do, universally.
I'm not applying this or pulling from your tree, sorry.
^ permalink raw reply
* Re: [PATCH net] sctp: jsctp_sf_eat_sack: fix kernel NULL ptr dereference
From: Daniel Borkmann @ 2012-12-14 21:49 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: David Miller, netdev
In-Reply-To: <50CB5A91.90404@redhat.com>
On Fri, Dec 14, 2012 at 5:57 PM, Daniel Borkmann <dborkman@redhat.com> wrote:
> On 12/14/2012 04:12 PM, Vlad Yasevich wrote:
>> On 12/14/2012 09:27 AM, Daniel Borkmann wrote:
>>>
>>> During debugging a sctp problem, I hit a kernel NULL pointer
>>> dereference in the jprobes callback jsctp_sf_eat_sack(). This
>>> small patch fixes the panic.
>>>
>>> Cc: Vlad Yasevich <vyasevich@gmail.com>
>>> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
>>> ---
>>> net/sctp/probe.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/net/sctp/probe.c b/net/sctp/probe.c
>>> index bc6cd75..0a4e9d6 100644
>>> --- a/net/sctp/probe.c
>>> +++ b/net/sctp/probe.c
>>> @@ -134,7 +134,7 @@ sctp_disposition_t jsctp_sf_eat_sack(const struct
>>> sctp_endpoint *ep,
>>>
>>> sp = asoc->peer.primary_path;
>>>
>>> - if ((full || sp->cwnd != lcwnd) &&
>>> + if (sp && (full || sp->cwnd != lcwnd) &&
>>> (!port || asoc->peer.port == port ||
>>> ep->base.bind_addr.port == port)) {
>>> lcwnd = sp->cwnd;
>>
>> Sorry, but this patch isn't making much sense. @sp points to the primary
>> path of the association and that can not be null if we receiving
>> SACKs on this association.
>>
>> sctp_sf_eat_sack_6_2(), which we are probing, is only called while the
>> association is valid and all the transports still exist. It is also called
>> under lock, so the transports can not go away while processing of the SACK.
>> So unless there is some kind of jprobe issue, the pointer
>> you are looking at should always be valid.
>
> Okay, I'll dig a bit deeper into that over the weekend.
That's just for the record, I'll do further tests / debugging tomorrow ...
I compiled the net kernel with kprobes selftest / sanity test
(kernel/test_kprobes.c) and it passed:
[ 2.978082] Kprobe smoke test started
[ 3.034014] Kprobe smoke test passed successfully
There, also jprobes are tested.
^ permalink raw reply
* Re: [PATCH] sctp: Change defaults on cookie hmac selection
From: Linus Torvalds @ 2012-12-14 21:56 UTC (permalink / raw)
To: Neil Horman; +Cc: Network Development, David Miller, Vlad Yasevich, linux-sctp
In-Reply-To: <1355511060-27320-1-git-send-email-nhorman@tuxdriver.com>
On Fri, Dec 14, 2012 at 10:51 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
>
> Tested by myself (allbeit fairly quickly). All configuration combinations seems
> to work soundly.
Ok, looks good, but I suspect we should also re-introduce the "none"
choice we used to have.
No?
Linus
^ permalink raw reply
* Re: [PATCH 00/11] Add basic VLAN support to bridges
From: Jamal Hadi Salim @ 2012-12-14 21:59 UTC (permalink / raw)
To: vyasevic
Cc: Stephen Hemminger, David Miller, or.gerlitz, netdev, mst,
john.r.fastabend
In-Reply-To: <50CB58EB.9050302@redhat.com>
On 12-12-14 11:50 AM, Vlad Yasevich wrote:
>
> Interesting. But, but how complex would be be to configure a vlan
> filter for say 10 different vlans,
Shouldnt be hard. At the simple level you need one rule per VLAN.
I am assuming only one vm per vlan and that you can key on something
in the header.
> each one of them only permitted
> to be forwarded to their respective VM.
Again assuming something in the header is going to say "this packet
is allowed to go to this VM", a MAC address, an IP src/destination
etc, correct?
Oh, and Vlan tags should
> be stripped when they are being forwarded.
Assuming they are not already stripped at vnetx,
you could write a very simple action (probably one page of code) to
strip vlans and do everything at br0;
Your filter finds them at br0, your action strips them and pipes to
another action that redirects to the correct device. i.e in unix speak:
filter at br0 for VMx | strip vlan tag | redirect to vnetx
At the very minimal you need to identify those packets and that depends
where you want to deploy the policy.
If you deploy at the br device, you will see the raw packet i.e the vlan
header wont be stripped.
i.e youd have to enter some u32 rule with protocol "protocol 802.1q"
If you deploy at each vnetx device assuming it is a vlan device, you
wont see the vlan headers and you'll have to key on something else on
the header "protocol ip"
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] can: sja1000: fix compilation on x86
From: Marc Kleine-Budde @ 2012-12-14 22:17 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-can, sfr, andreas
In-Reply-To: <20121214.163758.465958297963655994.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]
On 12/14/2012 10:37 PM, David Miller wrote:
> From: Marc Kleine-Budde <mkl@pengutronix.de>
> Date: Fri, 14 Dec 2012 22:33:44 +0100
>
>> @@ -121,7 +121,7 @@ static int sja1000_ofp_probe(struct platform_device *ofdev)
>> }
>>
>> irq = irq_of_parse_and_map(np, 0);
>> - if (irq == NO_IRQ) {
>> + if (irq <= 0) {
>> dev_err(&ofdev->dev, "no irq found\n");
>> err = -ENODEV;
>> goto exit_unmap_mem;
>
> I don't see anything existing which says this is the proper
> transformation.
>
> There is no consistency at all for the tests of the return
> value of irq_of_parse_and_map().
Right. And the current status of NO_IRQ doesn't help much.
> And if anything testing against zero is the correct thing to
> do, universally.
I've looked at the implementation of irq_of_parse_and_map() (both the
generic and sparc one), they both return 0 on failure. Because there are
some arch that define NO_IRQ being not 0, sparc (0xffffffff) and arm
(-1), I though testing against <= 0 would be a good idea.
> I'm not applying this or pulling from your tree, sorry.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]
^ permalink raw reply
* [PATCH v2] can: sja1000: fix compilation on x86
From: Marc Kleine-Budde @ 2012-12-14 22:25 UTC (permalink / raw)
To: netdev; +Cc: linux-can, rdunlap, davem, Marc Kleine-Budde, Andreas Larsson
Since commit:
04df251 can: sja1000: Make sja1000_of_platform selectable and compilable on SPARC
the driver can be activated on non powerpc platform like x86 or sparc. Without
this patch the driver fails to compile on platform that don't define NO_IRQ,
like x86.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
Hello David,
here's v2 of the patch.
Changes since v1:
* check if irq equals 0 (don't test for <= 0)
regards,
Marc
---
The following changes since commit 17bc14b767cf0692420c43dbe5310ae98a5a7836:
Revert "sched: Update_cfs_shares at period edge" (2012-12-14 07:20:43 -0800)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can.git fixes-for-3.8
for you to fetch changes up to b9b325a81c77adc5d735b70a6fce6fb6d1317476:
can: sja1000: fix compilation on x86 (2012-12-14 23:17:24 +0100)
----------------------------------------------------------------
Marc Kleine-Budde (1):
can: sja1000: fix compilation on x86
drivers/net/can/sja1000/sja1000_of_platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/sja1000/sja1000_of_platform.c b/drivers/net/can/sja1000/sja1000_of_platform.c
index 0f59170..6433b81 100644
--- a/drivers/net/can/sja1000/sja1000_of_platform.c
+++ b/drivers/net/can/sja1000/sja1000_of_platform.c
@@ -121,7 +121,7 @@ static int sja1000_ofp_probe(struct platform_device *ofdev)
}
irq = irq_of_parse_and_map(np, 0);
- if (irq == NO_IRQ) {
+ if (irq == 0) {
dev_err(&ofdev->dev, "no irq found\n");
err = -ENODEV;
goto exit_unmap_mem;
--
1.7.10.4
^ permalink raw reply related
* [PATCH] i2400m: add Intel 6150 device IDs
From: Dan Williams @ 2012-12-14 23:10 UTC (permalink / raw)
To: netdev; +Cc: inaky.perez-gonzalez
Add device IDs for WiMAX function of Intel 6150 cards.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Cc: stable@vger.kernel.org
---
diff --git a/drivers/net/wimax/i2400m/i2400m-usb.h b/drivers/net/wimax/i2400m/i2400m-usb.h
index 6650fde..9f1e947 100644
--- a/drivers/net/wimax/i2400m/i2400m-usb.h
+++ b/drivers/net/wimax/i2400m/i2400m-usb.h
@@ -152,6 +152,9 @@ enum {
/* Device IDs */
USB_DEVICE_ID_I6050 = 0x0186,
USB_DEVICE_ID_I6050_2 = 0x0188,
+ USB_DEVICE_ID_I6150 = 0x07d6,
+ USB_DEVICE_ID_I6150_2 = 0x07d7,
+ USB_DEVICE_ID_I6150_3 = 0x07d9,
USB_DEVICE_ID_I6250 = 0x0187,
};
diff --git a/drivers/net/wimax/i2400m/usb.c b/drivers/net/wimax/i2400m/usb.c
index 713d033..080f363 100644
--- a/drivers/net/wimax/i2400m/usb.c
+++ b/drivers/net/wimax/i2400m/usb.c
@@ -510,6 +510,9 @@ int i2400mu_probe(struct usb_interface *iface,
switch (id->idProduct) {
case USB_DEVICE_ID_I6050:
case USB_DEVICE_ID_I6050_2:
+ case USB_DEVICE_ID_I6150:
+ case USB_DEVICE_ID_I6150_2:
+ case USB_DEVICE_ID_I6150_3:
case USB_DEVICE_ID_I6250:
i2400mu->i6050 = 1;
break;
@@ -759,6 +762,9 @@ static
struct usb_device_id i2400mu_id_table[] = {
{ USB_DEVICE(0x8086, USB_DEVICE_ID_I6050) },
{ USB_DEVICE(0x8086, USB_DEVICE_ID_I6050_2) },
+ { USB_DEVICE(0x8087, USB_DEVICE_ID_I6150) },
+ { USB_DEVICE(0x8087, USB_DEVICE_ID_I6150_2) },
+ { USB_DEVICE(0x8087, USB_DEVICE_ID_I6150_3) },
{ USB_DEVICE(0x8086, USB_DEVICE_ID_I6250) },
{ USB_DEVICE(0x8086, 0x0181) },
{ USB_DEVICE(0x8086, 0x1403) },
^ permalink raw reply related
* Re: net/usb device additions for -stable
From: David Miller @ 2012-12-14 23:12 UTC (permalink / raw)
To: bjorn
Cc: netdev, jspurohit, valdis.kletnieks, jan.ceuleers, olof.ermis,
tommy7765
In-Reply-To: <877gppuu5l.fsf@nemi.mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Tue, 13 Nov 2012 21:25:58 +0100
> I looked quickly through the list of added devices in the range
> v3.6..net/master and tried to cherry-pick them into the current 3.0,
> 3.2, 3.4 and 3.6 stable trees. There weren't really that many. The
> result was:
>
> # for stable-3.6:
> af1b85e usb/ipheth: Add iPhone 5 support
> c6846ee net: qmi_wwan: adding more ZTE devices
> bbc8d92 net: cdc_ncm: add Huawei devices
>
> # for stable-3.4:
> af1b85e usb/ipheth: Add iPhone 5 support
>
> # for stable-3.2:
> af1b85e usb/ipheth: Add iPhone 5 support
>
> # for stable-3.0:
> af1b85e usb/ipheth: Add iPhone 5 support
The iPhone 5 change applied cleanly in all cases so I added that one.
The others did not.
Could you respin them for me and I'll queue them up for the next batch
I send out?
Thanks.
^ permalink raw reply
* Re: [PATCH] sctp: Change defaults on cookie hmac selection
From: Neil Horman @ 2012-12-15 0:38 UTC (permalink / raw)
To: Linus Torvalds
Cc: Network Development, David Miller, Vlad Yasevich, linux-sctp
In-Reply-To: <CA+55aFyT5b9GmGX0kzMPQG795uojiiWjWxUBBG_-m9bfrThU=Q@mail.gmail.com>
On Fri, Dec 14, 2012 at 01:56:15PM -0800, Linus Torvalds wrote:
> On Fri, Dec 14, 2012 at 10:51 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
> >
> > Tested by myself (allbeit fairly quickly). All configuration combinations seems
> > to work soundly.
>
> Ok, looks good, but I suspect we should also re-introduce the "none"
> choice we used to have.
>
> No?
>
No need, I think. Since its a user configurable choice now, the user can just
set the selector to "None" in proc, and none will be used.
Neil
^ permalink raw reply
* Re: [PATCH] sctp: Change defaults on cookie hmac selection
From: Linus Torvalds @ 2012-12-15 0:44 UTC (permalink / raw)
To: Neil Horman; +Cc: Network Development, David Miller, Vlad Yasevich, linux-sctp
In-Reply-To: <20121215003844.GA10508@neilslaptop.think-freely.org>
On Fri, Dec 14, 2012 at 4:38 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>
> No need, I think. Since its a user configurable choice now, the user can just
> set the selector to "None" in proc, and none will be used.
Well, by the same logic, there's no point to defaulting to MD5 either,
since the user could just put MD5 in the there.
The point is, if you're asking for a default, you should include the
actual choices, and not limit it to some random subset of choices. No?
Linus
^ permalink raw reply
* RE: Launch Time Support
From: Vick, Matthew @ 2012-12-15 0:45 UTC (permalink / raw)
To: Ulf Samuelsson, netdev@vger.kernel.org
In-Reply-To: <50C9298C.1080600@emagii.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Ulf Samuelsson
> Sent: Wednesday, December 12, 2012 5:04 PM
> To: netdev@vger.kernel.org
> Subject: RFC: Launch Time Support
>
> Hi, I am looking for some feedback on how to implement launchtime in
> the kernel.
>
> I.E: You define WHEN you want to send a packet, and the driver will
> store the packet in a buffer and will send it out on the net when the
> internal timestamp counter in the network controller reaches the
> specified "launch time".
>
> Some Ethernet controllers like the new Intel i210 support "launch
> time",
>
> Support for launch time is desirable for any isochronous connection,
> but I am currently interested in the NTP protocol to improve the
> timing.
>
> Proposed Changes to the Kernel
> ===========================================================
> The launchtime support will be dependent on CONFIG_NET_LAUNCHTIME If
> this is not set, then the kernel functionality is not changed.
>
> My current idea is to add a new bit to the "flags" field of
> "socket.c:sendto"
> #define MSG_LAUNCHTIME 0x?????
>
> struct msghdr gets an additional launchtime field.
>
> sendto will check if the flags parameter contains MSG_LAUNCHTIME.
> If it does, then the first 64 bit longword of the packet (buff)
> contains the launchtime.
> The launchtime from the buffer is copied to the msghdr.launchtime
> field, and the first 64 bits of the packet is then shaved off, before
> the address is written to the msghdr.
>
> Each network controller supporting launchtime needs to have an
> alternative call to "send packet with launchtime" . This call adds the
> launchtime parameter.
> If launchtime is supported the exported "ops" includes the new call.
>
> The UDP/IP packet send will check the MSG_LAUNCHTIME and if set, it
> will check if the "send packet with launchtime" call is available for
> the driver and if so call it, otherwise it will call the normal send
> packet and thus ignore the launchtime.
>
> Before launchtime is used, the application should send an ioctl to the
> driver, making sure that launchtime is configured, and only if the
> driver ACKs , the application will use launchtime.
>
> (Possibly the "ops" field for "send packet with launchtime" should be
> NULL until that ioctl is complete. Comments?)
>
> To me, this seems to be transparent for all other network stacks so
> protocols and drivers not supporting launchtime should still work.
>
> As far as I know, drivers do not support launch time today.
> The Intel igb driver does not in the latest version on the intel web
> site, There are some defines headers in the latest version defining
> the registers but so far, the code is not using it.
>
> There is the linux_igb_avb project on sourceforge which allows use of
> launch time for user space applications, but not as part of the kernel.
>
> Maybe there is more work done somewhere else, but i am not aware of
> this, so any links to such work is appreciated.
>
> There are some FPGA based PCIe boards that support launchtime (Endace
> DAG) using proprietary APIs.
> Talked to some vendors providing TCP/IP offload engines for FPGA and
> they do not support launchtime and liuke Endace use proprietary APIs so
> they are only useable by custom programs. Normal networking interfaces
> are not supported.
>
> Comment on above is appreciated.
>
> BACKGROUND
> For those that do not know how the NTP protocol works:
> ===================================================
> The client sends an UDP packet to the NTP server using port 123 The NTP
> client reads the current systime and puts that in the outgoing packet.
> There is a delay between the time the systime is read, and the time the
> packet actually leaves the Ethernet controller adding jitter to the NTP
> algorithm.
>
> When the server receives the packet, it can be timestamped in H/W and a
> CMSG is then created by the network stack containing that timestamp for
> use by the server NTP daemon.
>
> The server generates a reply, which needs to include the client
> transmit time, the servers receive time, and the servers transmit time.
> Again, the transmit time needs to be written into the NTP packet, and
> then it needs to be processed through the network stack before it is
> leaving the ethernet controller causing more jitter.
>
> If launch time is supported, then the client NTP daemon would simply
> read the systime, add a constant delay to create the transmit
> timestamp.
> The delay needs to be sufficiently large to ensure that all processing
> is done,
>
> The server will do something similar adding a constant to the server
> receive timestamp to create the server transmit timestamp.
> If both the client and the server uses H/W timestamping and launch
> time, then the the jitter ideally is reduced to zero.
>
> TRANSMIT TIMESTAMPING
> ========================
> Support for TX timestamps in H/W is not really useful, since you need
> to provide the TX timestamp in the packet you measure on, so when you
> know the timestamp it is too late. Server to server NTP connections
> support sending that timestamp in a new packet, but there is no such
> support in client server communication.
>
> The i210 supports putting the timestamp inside the packet as it leaves
> the Ethernet controller, but that means that you screw up the UDP
> checksum, so the packet will be rejected by the receiving NTP daemon.
> In addition, the i210 timestamp measures seconds and nanoseconds which
> is incompatible with the NTP timestamp which uses seconds and a 32 bit
> fraction of a second so that does not work either.
>
> Best Regards
> Ulf Samuelsson
> eMagii.
Ulf,
I have been looking into adding launch time support as part of enabling some of the I210 functionality you have described (such as in linux_igb_avb on SourceForge) upstream--less focused on NTP and more focused on AVB, but launch time will be necessary for both. If you would like, please feel free to contact me and I would love to work with you on this.
Reading your proposal, I'm a little confused by which systime you're referring to. Do you mean on the host or on the NIC? In the case of hardware timestamping today, in igb we set the SYSTIM registers to the current system time, but that doesn't mean that the host clock and the NIC clock stay synced. You would either need a mechanism such as PPS (which igb does not implement today) to sync the host clock to the NIC clock or have the NTP daemon account for the discrepancy. Off the top of my head, I want to say modern PTP daemons (such as ptp4l) account for the discrepancy in the daemon.
Cheers,
Matthew
Matthew Vick
Linux Development
LAN Access Division
Intel Corporation
^ permalink raw reply
* Re: [PATCH] sctp: Change defaults on cookie hmac selection
From: Neil Horman @ 2012-12-15 1:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: Network Development, David Miller, Vlad Yasevich, linux-sctp
In-Reply-To: <CA+55aFw-D2J-S8gH0PxO52nDeK31KHxum2gfT8RrzRoNF93yrg@mail.gmail.com>
On Fri, Dec 14, 2012 at 04:44:56PM -0800, Linus Torvalds wrote:
> On Fri, Dec 14, 2012 at 4:38 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> >
> > No need, I think. Since its a user configurable choice now, the user can just
> > set the selector to "None" in proc, and none will be used.
>
> Well, by the same logic, there's no point to defaulting to MD5 either,
> since the user could just put MD5 in the there.
>
> The point is, if you're asking for a default, you should include the
> actual choices, and not limit it to some random subset of choices. No?
>
> Linus
>
Ok, Thats a fair point, I can add a option to choose the "None" option as the
deafult. Dave, do you want a delta patch, or a new version?
Neil
^ permalink raw reply
* Re: [PATCH] sctp: Change defaults on cookie hmac selection
From: David Miller @ 2012-12-15 1:14 UTC (permalink / raw)
To: nhorman; +Cc: torvalds, netdev, vyasevich, linux-sctp
In-Reply-To: <20121215011229.GD10508@neilslaptop.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Fri, 14 Dec 2012 20:12:29 -0500
> On Fri, Dec 14, 2012 at 04:44:56PM -0800, Linus Torvalds wrote:
>> On Fri, Dec 14, 2012 at 4:38 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> >
>> > No need, I think. Since its a user configurable choice now, the user can just
>> > set the selector to "None" in proc, and none will be used.
>>
>> Well, by the same logic, there's no point to defaulting to MD5 either,
>> since the user could just put MD5 in the there.
>>
>> The point is, if you're asking for a default, you should include the
>> actual choices, and not limit it to some random subset of choices. No?
>>
>> Linus
>>
> Ok, Thats a fair point, I can add a option to choose the "None" option as the
> deafult. Dave, do you want a delta patch, or a new version?
New version please.
^ permalink raw reply
* [PATCH v2] sctp: Change defaults on cookie hmac selection
From: Neil Horman @ 2012-12-15 1:22 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, David Miller, Linus Torvalds, Vlad Yasevich,
linux-sctp
In-Reply-To: <1355511060-27320-1-git-send-email-nhorman@tuxdriver.com>
Recently I posted commit 3c68198e75 which made selection of the cookie hmac
algorithm selectable. This is all well and good, but Linus noted that it
changes the default config:
http://marc.info/?l=linux-netdev&m=135536629004808&w=2
I've modified the sctp Kconfig file to reflect the recommended way of making
this choice, using the thermal driver example specified, and brought the
defaults back into line with the way they were prior to my origional patch
Also, on Linus' suggestion, re-adding ability to select default 'none' hmac
algorithm, so we don't needlessly bloat the kernel by forcing a non-none
default. This also led me to note that we won't honor the default none
condition properly because of how sctp_net_init is encoded. Fix that up as
well.
Tested by myself (allbeit fairly quickly). All configuration combinations seems
to work soundly.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: David Miller <davem@davemloft.net>
CC: Linus Torvalds <torvalds@linux-foundation.org>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: linux-sctp@vger.kernel.org
---
net/sctp/Kconfig | 27 +++++++++++++++++++++++++--
net/sctp/protocol.c | 4 ++--
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/net/sctp/Kconfig b/net/sctp/Kconfig
index a9edd2e..c262106 100644
--- a/net/sctp/Kconfig
+++ b/net/sctp/Kconfig
@@ -66,12 +66,36 @@ config SCTP_DBG_OBJCNT
'cat /proc/net/sctp/sctp_dbg_objcnt'
If unsure, say N
+choice
+ prompt "Default SCTP cookie HMAC encoding"
+ default SCTP_COOKIE_HMAC_MD5
+ help
+ This option sets the default sctp cookie hmac algorithm
+ when in doubt select 'md5'
+
+config SCTP_DEFAULT_COOKIE_HMAC_MD5
+ bool "Enable optional MD5 hmac cookie generation"
+ help
+ Enable optional MD5 hmac based SCTP cookie generation
+ select SCTP_COOKIE_HMAC_MD5
+
+config SCTP_DEFAULT_COOKIE_HMAC_SHA1
+ bool "Enable optional SHA1 hmac cookie generation"
+ help
+ Enable optional SHA1 hmac based SCTP cookie generation
+ select SCTP_COOKIE_HMAC_SHA1
+
+config SCTP_DEFAULT_COOKIE_HMAC_NONE
+ bool "Use no hmac alg in SCTP cookie generation"
+ help
+ Use no hmac algorithm in SCTP cookie generation
+
+endchoice
config SCTP_COOKIE_HMAC_MD5
bool "Enable optional MD5 hmac cookie generation"
help
Enable optional MD5 hmac based SCTP cookie generation
- default y
select CRYPTO_HMAC if SCTP_COOKIE_HMAC_MD5
select CRYPTO_MD5 if SCTP_COOKIE_HMAC_MD5
@@ -79,7 +103,6 @@ config SCTP_COOKIE_HMAC_SHA1
bool "Enable optional SHA1 hmac cookie generation"
help
Enable optional SHA1 hmac based SCTP cookie generation
- default y
select CRYPTO_HMAC if SCTP_COOKIE_HMAC_SHA1
select CRYPTO_SHA1 if SCTP_COOKIE_HMAC_SHA1
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index 2c7785b..f898b1c 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -1191,9 +1191,9 @@ static int __net_init sctp_net_init(struct net *net)
net->sctp.cookie_preserve_enable = 1;
/* Default sctp sockets to use md5 as their hmac alg */
-#if defined (CONFIG_CRYPTO_MD5)
+#if defined (CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5)
net->sctp.sctp_hmac_alg = "md5";
-#elif defined (CONFIG_CRYPTO_SHA1)
+#elif defined (CONFIG_SCTP_DEFAULT_COOKIE_HMAC_SHA1)
net->sctp.sctp_hmac_alg = "sha1";
#else
net->sctp.sctp_hmac_alg = NULL;
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH] xfrm: do not check x->km.state
From: RongQing Li @ 2012-12-15 1:36 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, netdev
In-Reply-To: <20121214114545.GI18940@secunet.com>
2012/12/14 Steffen Klassert <steffen.klassert@secunet.com>:
>> 1. remove this check in xfrm_state_check_expire, and add a check in
>> xfrm_output_one
>>
>
> I think the first option ist the better one. It removes a superfluous
> check and we get some more statistics.
I see, thanks
-Roy
^ permalink raw reply
* Re: [RFC PATCH] xfrm: avoid to send/receive the exceeding hard lifetime data
From: RongQing Li @ 2012-12-15 1:36 UTC (permalink / raw)
To: Steffen Klassert; +Cc: netdev
In-Reply-To: <20121214113945.GH18940@secunet.com>
2012/12/14 Steffen Klassert <steffen.klassert@secunet.com>:
> On Fri, Dec 14, 2012 at 02:58:03PM +0800, RongQing Li wrote:
>>
>> Yes, RFC does not say how to handle this packet.
>>
>> But when I do a IPsec compliance test with IxANVL, the test case 5.3/5.11,
>> which reports a error because it expects this packet should be dropped, but not.
>>
>>
>> I do not know if it is bug, or if it is valuable to fix it?
>>
>
> As long as the RFC does not state anything else, we ar ok in the
> synchronous code path. But we need a fix for the asynchronous
> code path.
>
Thanks.
-Roy
^ permalink raw reply
* [Patch] iproute2: distinguish permanent and temporary mdb entries
From: Cong Wang @ 2012-12-15 8:09 UTC (permalink / raw)
To: netdev; +Cc: bridge, Stephen Hemminger, Cong Wang
In-Reply-To: <1355558992-32285-1-git-send-email-amwang@redhat.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
diff --git a/bridge/mdb.c b/bridge/mdb.c
index 121ce9c..6217c5f 100644
--- a/bridge/mdb.c
+++ b/bridge/mdb.c
@@ -28,7 +28,7 @@ int filter_index;
static void usage(void)
{
- fprintf(stderr, "Usage: bridge mdb { add | del } dev DEV port PORT grp GROUP\n");
+ fprintf(stderr, "Usage: bridge mdb { add | del } dev DEV port PORT grp GROUP [permanent | temp]\n");
fprintf(stderr, " bridge mdb {show} [ dev DEV ]\n");
exit(-1);
}
@@ -53,13 +53,15 @@ static void print_mdb_entry(FILE *f, int ifindex, struct br_mdb_entry *e)
SPRINT_BUF(abuf);
if (e->addr.proto == htons(ETH_P_IP))
- fprintf(f, "bridge %s port %s group %s\n", ll_index_to_name(ifindex),
+ fprintf(f, "bridge %s port %s group %s %s\n", ll_index_to_name(ifindex),
ll_index_to_name(e->ifindex),
- inet_ntop(AF_INET, &e->addr.u.ip4, abuf, sizeof(abuf)));
+ inet_ntop(AF_INET, &e->addr.u.ip4, abuf, sizeof(abuf)),
+ (e->state & MDB_PERMANENT) ? "permanent" : "temp");
else
- fprintf(f, "bridge %s port %s group %s\n", ll_index_to_name(ifindex),
+ fprintf(f, "bridge %s port %s group %s %s\n", ll_index_to_name(ifindex),
ll_index_to_name(e->ifindex),
- inet_ntop(AF_INET6, &e->addr.u.ip6, abuf, sizeof(abuf)));
+ inet_ntop(AF_INET6, &e->addr.u.ip6, abuf, sizeof(abuf)),
+ (e->state & MDB_PERMANENT) ? "permanent" : "temp");
}
static void br_print_mdb_entry(FILE *f, int ifindex, struct rtattr *attr)
@@ -179,11 +181,15 @@ static int mdb_modify(int cmd, int flags, int argc, char **argv)
} else if (strcmp(*argv, "grp") == 0) {
NEXT_ARG();
grp = *argv;
+ } else if (strcmp(*argv, "port") == 0) {
+ NEXT_ARG();
+ p = *argv;
+ } else if (strcmp(*argv, "permanent") == 0) {
+ if (cmd == RTM_NEWMDB)
+ entry.state |= MDB_PERMANENT;
+ } else if (strcmp(*argv, "temp") == 0) {
+ ;/* nothing */
} else {
- if (strcmp(*argv, "port") == 0) {
- NEXT_ARG();
- p = *argv;
- }
if (matches(*argv, "help") == 0)
usage();
}
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index b3b6a67..aac8b8c 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -163,6 +163,9 @@ struct br_port_msg {
struct br_mdb_entry {
__u32 ifindex;
+#define MDB_TEMPORARY 0
+#define MDB_PERMANENT 1
+ __u8 state;
struct {
union {
__be32 ip4;
^ permalink raw reply related
* [PATCH 1/2] bridge: update selinux perm table for RTM_NEWMDB and RTM_DELMDB
From: Cong Wang @ 2012-12-15 8:09 UTC (permalink / raw)
To: netdev; +Cc: bridge, Cong Wang, Herbert Xu, Stephen Hemminger, David S. Miller
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
security/selinux/nlmsgtab.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/security/selinux/nlmsgtab.c b/security/selinux/nlmsgtab.c
index 370a646..855e464 100644
--- a/security/selinux/nlmsgtab.c
+++ b/security/selinux/nlmsgtab.c
@@ -69,6 +69,8 @@ static struct nlmsg_perm nlmsg_route_perms[] =
{ RTM_SETDCB, NETLINK_ROUTE_SOCKET__NLMSG_WRITE },
{ RTM_NEWNETCONF, NETLINK_ROUTE_SOCKET__NLMSG_WRITE },
{ RTM_GETNETCONF, NETLINK_ROUTE_SOCKET__NLMSG_READ },
+ { RTM_NEWMDB, NETLINK_ROUTE_SOCKET__NLMSG_WRITE },
+ { RTM_DELMDB, NETLINK_ROUTE_SOCKET__NLMSG_WRITE },
{ RTM_GETMDB, NETLINK_ROUTE_SOCKET__NLMSG_READ },
};
--
1.7.7.6
^ permalink raw reply related
* [PATCH 2/2] bridge: add flags to distinguish permanent mdb entires
From: Cong Wang @ 2012-12-15 8:09 UTC (permalink / raw)
To: netdev; +Cc: bridge, Cong Wang, Herbert Xu, Stephen Hemminger, David S. Miller
In-Reply-To: <1355558992-32285-1-git-send-email-amwang@redhat.com>
This patch adds a flag to each mdb entry, so that we can distinguish
permanent entries with temporary entries.
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
include/uapi/linux/if_bridge.h | 3 +++
net/bridge/br_mdb.c | 9 ++++++---
net/bridge/br_multicast.c | 8 +++++---
net/bridge/br_private.h | 4 +++-
4 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
index afbb18a..5db2975 100644
--- a/include/uapi/linux/if_bridge.h
+++ b/include/uapi/linux/if_bridge.h
@@ -163,6 +163,9 @@ struct br_port_msg {
struct br_mdb_entry {
__u32 ifindex;
+#define MDB_TEMPORARY 0
+#define MDB_PERMANENT 1
+ __u8 state;
struct {
union {
__be32 ip4;
diff --git a/net/bridge/br_mdb.c b/net/bridge/br_mdb.c
index 6f0a2ee..9cf5d2b 100644
--- a/net/bridge/br_mdb.c
+++ b/net/bridge/br_mdb.c
@@ -83,6 +83,7 @@ static int br_mdb_fill_info(struct sk_buff *skb, struct netlink_callback *cb,
if (port) {
struct br_mdb_entry e;
e.ifindex = port->dev->ifindex;
+ e.state = p->state;
e.addr.u.ip4 = p->addr.u.ip4;
#if IS_ENABLED(CONFIG_IPV6)
e.addr.u.ip6 = p->addr.u.ip6;
@@ -253,6 +254,8 @@ static bool is_valid_mdb_entry(struct br_mdb_entry *entry)
#endif
} else
return false;
+ if (entry->state != MDB_PERMANENT && entry->state != MDB_TEMPORARY)
+ return false;
return true;
}
@@ -310,7 +313,7 @@ static int br_mdb_parse(struct sk_buff *skb, struct nlmsghdr *nlh,
}
static int br_mdb_add_group(struct net_bridge *br, struct net_bridge_port *port,
- struct br_ip *group)
+ struct br_ip *group, unsigned char state)
{
struct net_bridge_mdb_entry *mp;
struct net_bridge_port_group *p;
@@ -336,7 +339,7 @@ static int br_mdb_add_group(struct net_bridge *br, struct net_bridge_port *port,
break;
}
- p = br_multicast_new_port_group(port, group, *pp);
+ p = br_multicast_new_port_group(port, group, *pp, state);
if (unlikely(!p))
return -ENOMEM;
rcu_assign_pointer(*pp, p);
@@ -373,7 +376,7 @@ static int __br_mdb_add(struct net *net, struct net_bridge *br,
#endif
spin_lock_bh(&br->multicast_lock);
- ret = br_mdb_add_group(br, p, &ip);
+ ret = br_mdb_add_group(br, p, &ip, entry->state);
spin_unlock_bh(&br->multicast_lock);
return ret;
}
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 2561af9..dce9def 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -279,7 +279,7 @@ static void br_multicast_port_group_expired(unsigned long data)
spin_lock(&br->multicast_lock);
if (!netif_running(br->dev) || timer_pending(&pg->timer) ||
- hlist_unhashed(&pg->mglist))
+ hlist_unhashed(&pg->mglist) || pg->state & MDB_PERMANENT)
goto out;
br_multicast_del_pg(br, pg);
@@ -622,7 +622,8 @@ out:
struct net_bridge_port_group *br_multicast_new_port_group(
struct net_bridge_port *port,
struct br_ip *group,
- struct net_bridge_port_group __rcu *next)
+ struct net_bridge_port_group __rcu *next,
+ unsigned char state)
{
struct net_bridge_port_group *p;
@@ -632,6 +633,7 @@ struct net_bridge_port_group *br_multicast_new_port_group(
p->addr = *group;
p->port = port;
+ p->state = state;
rcu_assign_pointer(p->next, next);
hlist_add_head(&p->mglist, &port->mglist);
setup_timer(&p->timer, br_multicast_port_group_expired,
@@ -674,7 +676,7 @@ static int br_multicast_add_group(struct net_bridge *br,
break;
}
- p = br_multicast_new_port_group(port, group, *pp);
+ p = br_multicast_new_port_group(port, group, *pp, MDB_TEMPORARY);
if (unlikely(!p))
goto err;
rcu_assign_pointer(*pp, p);
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index f21a739..49b85af4 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -83,6 +83,7 @@ struct net_bridge_port_group {
struct rcu_head rcu;
struct timer_list timer;
struct br_ip addr;
+ unsigned char state;
};
struct net_bridge_mdb_entry
@@ -443,7 +444,8 @@ extern void br_multicast_free_pg(struct rcu_head *head);
extern struct net_bridge_port_group *br_multicast_new_port_group(
struct net_bridge_port *port,
struct br_ip *group,
- struct net_bridge_port_group *next);
+ struct net_bridge_port_group *next,
+ unsigned char state);
extern void br_mdb_init(void);
extern void br_mdb_notify(struct net_device *dev, struct net_bridge_port *port,
struct br_ip *group, int type);
--
1.7.7.6
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox