* Re: 82571EB: Detected Hardware Unit Hang
From: Mary Mcgrath @ 2012-11-27 2:06 UTC (permalink / raw)
To: Joe Jin; +Cc: netdev, e1000-devel, linux-kernel
In-Reply-To: <50B41077.3080009@oracle.com>
Joe
Thank you for working this.
I would love to find out how they expect a customer to make the modification
To "word 0x1A, and see if the 8th bit is 0 or 1, and to change to 0."
I have in turn asked the ct for the lspci command on eth3, maybe the incorrect setting is upstream.
Again, thank you.
Regards
Mary
-----Original Message-----
From: Joe Jin
Sent: Monday, November 26, 2012 8:00 PM
To: Fujinaka, Todd
Cc: Dave, Tushar N; netdev@vger.kernel.org; e1000-devel@lists.sf.net; linux-kernel@vger.kernel.org; Mary Mcgrath
Subject: Re: [E1000-devel] 82571EB: Detected Hardware Unit Hang
On 11/27/12 00:23, Fujinaka, Todd wrote:
> If you look at the previous section, DevCap, you'll see that it's
> correctly advertising 256 bytes but the system is negotiating 128 for
> the link to the Ethernet controller. Things on the "other" side of the
> link are controlled outside of the e1000 driver.
>
> Tushar's first suggestion was to check the PCIe payload settings in
> the entire chain. Have you done that? Mismatches will cause hangs.
Hi Todd,
So far I had to know how to modify the maxpayload size, since BIOS have not entry to change this, so I had to use ethtool, now I need to get the offset of MaxPayload size in eeprom, I ever tried to find from Intel online document but failed, any idea?
Thanks in advance,
Joe
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH net-next v2] net: clean up locking in inet_frag_find()
From: Cong Wang @ 2012-11-27 3:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Patrick McHardy, Pablo Neira Ayuso, David S. Miller
In-Reply-To: <1353942751.30446.1769.camel@edumazet-glaptop>
On Mon, 2012-11-26 at 07:12 -0800, Eric Dumazet wrote:
> On Mon, 2012-11-26 at 15:26 +0800, Cong Wang wrote:
> > It is weird to take the read lock outside of inet_frag_find()
> > but release it inside... This can be improved by refactoring
> > the code, that is, introducing inet{4,6}_frag_find() which call
> > the their own hash function, inet{4,6}_hash_frag(), hiding the
> > details from their callers.
> >
> > Cc: Eric Dumazet <eric.dumazet@gmail.com>
> > Cc: Patrick McHardy <kaber@trash.net>
> > Cc: Pablo Neira Ayuso <pablo@netfilter.org>
> > Cc: David S. Miller <davem@davemloft.net>
> > Signed-off-by: Cong Wang <amwang@redhat.com>
> >
> > ---
> > include/net/inet_frag.h | 17 +++++-
> > include/net/ipv6.h | 3 -
> > net/ipv4/inet_fragment.c | 82 +++++++++++++++++++++++++++++--
> > net/ipv4/ip_fragment.c | 16 +-----
> > net/ipv6/netfilter/nf_conntrack_reasm.c | 7 +--
> > net/ipv6/reassembly.c | 34 +------------
> > 6 files changed, 97 insertions(+), 62 deletions(-)
>
>
> Not clear to me its a win, as it adds 35 LOC. Nobody really complained
> of this locking schem in the past.
Yeah, seems every people here is able to read any ugly code, except
me. :-)
>
> Also Jesper is working on this stuff, so you dont really ease its work.
>
>
I will rebase his tree for him, no worry, handling conflicts is part of
my life everyday (I am a heavy `git rebase -i` user).
^ permalink raw reply
* Re: Fwd: Re: [PATCH] net: ipv6: change %8s to %s for rt->dst.dev->name in seq_printf of rt6_info_route
From: Shan Wei @ 2012-11-27 3:17 UTC (permalink / raw)
To: Chen Gang; +Cc: Eric Dumazet, David Miller, netdev
In-Reply-To: <50AEEF08.4000707@asianux.com>
Chen Gang said, at 2012/11/23 11:35:
> 2) about %*s:
> since kernel is an open system, IFNAMSIZ is belong to OS API level for outside
> it has effect both on individual kernel modules and user mode system call
> we need obey this rule, and %8s is not match this rule.
> so %8s is not suitable. (and now we have to choose %16s or %s).
Your patch will change the format of /proc/net/ipv6_route.
Why we need to keep be consistent with user mode?
However user operates device name, no effect on the showing of /proc/net/ipv6_route.
>
> for the format of information which seq_printf output:
> it is not belong to OS API level for outside (at least, for current case, it is true).
> so we need not keep 'compatible' of it, so %16s is not necessary.
Can you explain If we don't change to %s, what will happen?
>
> for keeping source code simple and clearly:
> %s is better than %16s.
>
> so for result, we should choose %s only (neither %16s nor %8s).
^ permalink raw reply
* Re: Fwd: Re: [PATCH] net: ipv6: change %8s to %s for rt->dst.dev->name in seq_printf of rt6_info_route
From: Chen Gang @ 2012-11-27 4:18 UTC (permalink / raw)
To: Shan Wei; +Cc: Eric Dumazet, David Miller, netdev
In-Reply-To: <50B430B5.1080700@gmail.com>
于 2012年11月27日 11:17, Shan Wei 写道:
> Chen Gang said, at 2012/11/23 11:35:
>> 2) about %*s:
>> since kernel is an open system, IFNAMSIZ is belong to OS API level for outside
>> it has effect both on individual kernel modules and user mode system call
>> we need obey this rule, and %8s is not match this rule.
>> so %8s is not suitable. (and now we have to choose %16s or %s).
>
> Your patch will change the format of /proc/net/ipv6_route.
Yes, it will be changed.
although it belongs to "User Experience", it is not belong to os api level.
for os api level: we must commit them not be changed (they are testament)
for User Experience: we can change it, but maybe users feel 'not good'.
> Why we need to keep be consistent with user mode?
it is for "keep source code simple and clear"
when others see the %8s, easy to make them miss understanding (not quite clear)
so better to change it to %s.
> However user operates device name, no effect on the showing of /proc/net/ipv6_route.
now, no effect.
all together:
since we are not user interactive program,
"keeping source code simple and clear" is more important than "User Experience"
>
>>
>> for the format of information which seq_printf output:
>> it is not belong to OS API level for outside (at least, for current case, it is true).
>> so we need not keep 'compatible' of it, so %16s is not necessary.
>
> Can you explain If we don't change to %s, what will happen?
>
for outside, nothing will happen.
so it is not for correctness, it is only for "keep source code simple and clear".
>>
>> for keeping source code simple and clearly:
>> %s is better than %16s.
>>
>> so for result, we should choose %s only (neither %16s nor %8s).
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: Fwd: Re: [PATCH] net: ipv6: change %8s to %s for rt->dst.dev->name in seq_printf of rt6_info_route
From: Chen Gang @ 2012-11-27 4:45 UTC (permalink / raw)
To: Shan Wei; +Cc: Eric Dumazet, David Miller, netdev
In-Reply-To: <50B43F12.1090709@asianux.com>
于 2012年11月27日 12:18, Chen Gang 写道:
> 于 2012年11月27日 11:17, Shan Wei 写道:
>> > Chen Gang said, at 2012/11/23 11:35:
>>> >> 2) about %*s:
>>> >> since kernel is an open system, IFNAMSIZ is belong to OS API level for outside
>>> >> it has effect both on individual kernel modules and user mode system call
>>> >> we need obey this rule, and %8s is not match this rule.
>>> >> so %8s is not suitable. (and now we have to choose %16s or %s).
>> >
>> > Your patch will change the format of /proc/net/ipv6_route.
> Yes, it will be changed.
> although it belongs to "User Experience", it is not belong to os api level.
> for os api level: we must commit them not be changed (they are testament)
> for User Experience: we can change it, but maybe users feel 'not good'.
>
I think (only for my thought, maybe not correct):
for user input through /proc/* are all for os api level, not for "User Experience".
for most of outputs to user through /proc/*, are "User Experience".
>> > Why we need to keep be consistent with user mode?
> it is for "keep source code simple and clear"
> when others see the %8s, easy to make them miss understanding (not quite clear)
> so better to change it to %s.
>
>
>> > However user operates device name, no effect on the showing of /proc/net/ipv6_route.
> now, no effect.
>
>
> all together:
> since we are not user interactive program,
> "keeping source code simple and clear" is more important than "User Experience"
>
>
>> >
>>> >>
>>> >> for the format of information which seq_printf output:
>>> >> it is not belong to OS API level for outside (at least, for current case, it is true).
>>> >> so we need not keep 'compatible' of it, so %16s is not necessary.
>> >
>> > Can you explain If we don't change to %s, what will happen?
>> >
> for outside, nothing will happen.
>
> so it is not for correctness, it is only for "keep source code simple and clear".
>
>>> >>
>>> >> for keeping source code simple and clearly:
>>> >> %s is better than %16s.
>>> >>
>>> >> so for result, we should choose %s only (neither %16s nor %8s).
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe netdev" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >
>> >
>
> -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send
> the line "unsubscribe netdev" in the body of a message to
> majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
>
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: Fwd: Re: [PATCH] net: ipv6: change %8s to %s for rt->dst.dev->name in seq_printf of rt6_info_route
From: Shan Wei @ 2012-11-27 4:56 UTC (permalink / raw)
To: Chen Gang; +Cc: Eric Dumazet, David Miller, netdev
In-Reply-To: <50B43F12.1090709@asianux.com>
Chen Gang said, at 2012/11/27 12:18:
>>
>>>
>>> for the format of information which seq_printf output:
>>> it is not belong to OS API level for outside (at least, for current case, it is true).
>>> so we need not keep 'compatible' of it, so %16s is not necessary.
>>
>> Can you explain If we don't change to %s, what will happen?
>>
>
> for outside, nothing will happen.
>
> so it is not for correctness, it is only for "keep source code simple and clear".
So, it's a clean-up type patch which is just for developer,
but with the change of /proc interface which is for user.
user is first, so let us end this thread unless you have necessary reasons to do it.
Thanks
Shan Wei
^ permalink raw reply
* Re: Fwd: Re: [PATCH] net: ipv6: change %8s to %s for rt->dst.dev->name in seq_printf of rt6_info_route
From: Chen Gang @ 2012-11-27 5:35 UTC (permalink / raw)
To: Shan Wei; +Cc: Eric Dumazet, David Miller, netdev
In-Reply-To: <50B447F3.2090806@gmail.com>
于 2012年11月27日 12:56, Shan Wei 写道:
> Chen Gang said, at 2012/11/27 12:18:
>>>
>>>>
>>>> for the format of information which seq_printf output:
>>>> it is not belong to OS API level for outside (at least, for current case, it is true).
>>>> so we need not keep 'compatible' of it, so %16s is not necessary.
>>>
>>> Can you explain If we don't change to %s, what will happen?
>>>
>>
>> for outside, nothing will happen.
>>
>> so it is not for correctness, it is only for "keep source code simple and clear".
>
> So, it's a clean-up type patch which is just for developer,
> but with the change of /proc interface which is for user.
> user is first, so let us end this thread unless you have necessary reasons to do it.
>
1) it is not change the /proc interface.
a) both %8s and %s do not change the output interface format (including contents, topology, separator mark, space redundancy).
b) it is belong to 'User Experience', not belong to os api.
c) do you agree with what I say above ?
2) I think:
one of the differences between system service and user interactive program are:
for system service (including kernel): "clean-up" is more important than "UE".
for user interactive program: "UE" is more important than "Clean-up".
maybe, it is for ideal world (or maybe it is only in theory).
(also maybe what I said above is incorrect)
3) so all together:
I can understand if it is not integrated into main branch.
it will be better to continue discussing it in ideal world (or in theory), I think it is valuable for learning with each other.
:-)
thanks.
gchen.
> Thanks
> Shan Wei
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: Fwd: Re: [PATCH] net: ipv6: change %8s to %s for rt->dst.dev->name in seq_printf of rt6_info_route
From: Chen Gang @ 2012-11-27 5:40 UTC (permalink / raw)
To: Shan Wei; +Cc: Eric Dumazet, David Miller, netdev
In-Reply-To: <50B44563.8060905@asianux.com>
> I think (only for my thought, maybe not correct):
> for user input through /proc/* are all for os api level, not for "User Experience".
> for most of outputs to user through /proc/*, are "User Experience".
>
and now I think what I said above is incorrect.
and now, I think:
A) both input and output through /proc/* are for os api level.
B) but both %8s and %s do not change the output interface format (including contents, topology, separator mark, space redundancy).
C) so it is belong to 'User Experience', not belong to os api.
welcome any another members to giving suggestions and completions.
thanks.
:-)
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* linux-next: manual merge of the drop-experimental tree with the net-next tree
From: Stephen Rothwell @ 2012-11-27 5:45 UTC (permalink / raw)
To: Kees Cook; +Cc: linux-next, linux-kernel, Ben Hutchings, David Miller, netdev
[-- Attachment #1: Type: text/plain, Size: 561 bytes --]
Hi Kees,
Today's linux-next merge of the drop-experimental tree got a conflict in
net/dsa/Kconfig between commit b3422a314c27 ("dsa: Hide core config
options; make drivers select what they need") from the net-next tree and
commit b8e8d99e4ee8 ("net/dsa: remove depends on CONFIG_EXPERIMENTAL")
from the drop-experimental tree.
I fixed it up (using the net-next version as that removed
CONFIG_EXPERIMENTAL as well) and can carry the fix as necessary (no
action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] vhost: fix length for cross region descriptor
From: Jason Wang @ 2012-11-27 5:47 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, David Miller, linux-kernel
In-Reply-To: <20121126155727.GA21716@redhat.com>
On 11/26/2012 11:57 PM, Michael S. Tsirkin wrote:
> If a single descriptor crosses a region, the
> second chunk length should be decremented
> by size translated so far, instead it includes
> the full descriptor length.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/vhost/vhost.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index ef8f598..5a3d0f1 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -1049,7 +1049,7 @@ static int translate_desc(struct vhost_dev *dev, u64 addr, u32 len,
> }
> _iov = iov + ret;
> size = reg->memory_size - addr + reg->guest_phys_addr;
> - _iov->iov_len = min((u64)len, size);
> + _iov->iov_len = min((u64)len - s, size);
> _iov->iov_base = (void __user *)(unsigned long)
> (reg->userspace_addr + addr - reg->guest_phys_addr);
> s += size;
Acked-by: Jason Wang <jasowang@redhat.com>
^ permalink raw reply
* Re: Fwd: Re: [PATCH] net: ipv6: change %8s to %s for rt->dst.dev->name in seq_printf of rt6_info_route
From: Chen Gang @ 2012-11-27 5:52 UTC (permalink / raw)
To: Shan Wei; +Cc: Eric Dumazet, David Miller, netdev
In-Reply-To: <50B45265.9070303@asianux.com>
于 2012年11月27日 13:40, Chen Gang 写道:
>
> and now, I think:
> A) both input and output through /proc/* are for os api level.
> B) but both %8s and %s do not change the output interface format (including contents, topology, separator mark, space redundancy).
> C) so it is belong to 'User Experience', not belong to os api.
>
> welcome any another members to giving suggestions and completions.
>
> thanks.
>
> :-)
>
completion: 8 right alignment is not belong to interface format.
if it was belong to interface format,
it would cause correctness issue (the name len may be larger than 8).
so if "8 right alignment" is belong to os api, it means the api is not correct, need change.
:-)
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: performance regression on HiperSockets depending on MTU size
From: Cong Wang @ 2012-11-27 6:21 UTC (permalink / raw)
To: netdev
In-Reply-To: <1353946351.30446.1779.camel@edumazet-glaptop>
On Mon, 26 Nov 2012 at 16:12 GMT, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Hi Frank, thanks for this report.
>
> You could tweak tcp_limit_output_bytes, but IMO the root of the problem
> is in the driver itself.
>
> For example, I had to change mlx4 driver for the same problem : Make
> sure a TX packet can be "TX completed" in a short amount of time.
>
> In the case of mlx4, the wait time was 128 us, but I suspect on your
> case its more like an infinite time or several ms.
>
> The driver is delaying the free of TX skb by a fixed amount of time,
> or relies on following transmits to perform the TX completion
>
Eric,
Do you have a full list of such commits? I am trying to backport TSQ
to 2.6.32, and of course I don't want to miss these commits either.
Thanks!
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the infiniband tree
From: Or Gerlitz @ 2012-11-27 6:43 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev, linux-next, linux-kernel, Roland Dreier,
linux-rdma, Ben Hutchings, Amir Vadai
In-Reply-To: <20121127114751.6961da02245ed6851190aca2@canb.auug.org.au>
On 27/11/2012 02:47, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/mellanox/mlx4/en_rx.c between commit 08ff32352d6f
> ("mlx4: 64-byte CQE/EQE support") from the infiniband tree and commit
> f1d29a3fa68b ("mlx4_en: Remove remnants of LRO support") from the
> net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
Acked-by: Or Geritz <ogerlitz@mellanox.com>
^ permalink raw reply
* Re: [net-next RFC] pktgen: don't wait for the device who doesn't free skb immediately after sent
From: Jason Wang @ 2012-11-27 6:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: mst, netdev, linux-kernel, virtualization, davem
In-Reply-To: <20121126093728.0a10f97f@nehalam.linuxnetplumber.net>
On 11/27/2012 01:37 AM, Stephen Hemminger wrote:
> On Mon, 26 Nov 2012 15:56:52 +0800
> Jason Wang <jasowang@redhat.com> wrote:
>
>> Some deivces do not free the old tx skbs immediately after it has been sent
>> (usually in tx interrupt). One such example is virtio-net which optimizes for
>> virt and only free the possible old tx skbs during the next packet sending. This
>> would lead the pktgen to wait forever in the refcount of the skb if no other
>> pakcet will be sent afterwards.
>>
>> Solving this issue by introducing a new flag IFF_TX_SKB_FREE_DELAY which could
>> notify the pktgen that the device does not free skb immediately after it has
>> been sent and let it not to wait for the refcount to be one.
>>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
> Another alternative would be using skb_orphan() and skb->destructor.
> There are other cases where skb's are not freed right away.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Stephen:
Do you mean registering a skb->destructor for pktgen then set and check
bits in skb->tx_flag?
^ permalink raw reply
* Re: performance regression on HiperSockets depending on MTU size
From: Eric Dumazet @ 2012-11-27 6:46 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev
In-Reply-To: <k91m5l$77a$1@ger.gmane.org>
On Tue, 2012-11-27 at 06:21 +0000, Cong Wang wrote:
> Eric,
>
> Do you have a full list of such commits? I am trying to backport TSQ
> to 2.6.32, and of course I don't want to miss these commits either.
I dont think there are other known issues.
mlx4 had a 'problem' because only recently we removed the skb_orphan()
call it used to do in its start_xmit() function.
I remember David had to revert BQL on NIU driver, but NIU does the
skb_orphan() call as well so TSQ is basically disabled.
^ permalink raw reply
* Re: private netdev flags into UAPI?
From: Or Gerlitz @ 2012-11-27 6:51 UTC (permalink / raw)
To: David Howells; +Cc: Or Gerlitz, netdev
In-Reply-To: <990.1353981789@warthog.procyon.org.uk>
On 27/11/2012 04:03, David Howells wrote:
> Or Gerlitz <or.gerlitz@gmail.com> wrote:
>
>> On Mon, Nov 26, 2012 at 11:22 AM, David Howells <dhowells@redhat.com> wrote:
>>> They were exposed to userspace already
>> So the script carries the bug into a new directory... why? AFAIK,
>> intentionally there's no way to read private flags from user space, so
>> what's the point in defining them there?
> How should the script know what's private and what's not? By the
> encapsulation of code inside __KERNEL__ blocks. In their absence, everything
> is assumed to be public - given it is already part of the UAPI. I don't know
> that the code is private rather than the comment is wrong.
>
>
makes sense, but I have pointed on a bug in the final result, so this
way or another, the fact that the bug
existed before doesn't mean we should carry it over.
Or.
^ permalink raw reply
* Re: [net-next 06/10] ixgbe: eliminate Smatch warnings in ixgbe_debugfs.c
From: Dan Carpenter @ 2012-11-27 7:18 UTC (permalink / raw)
To: Hay, Joshua A
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com, sassmann@redhat.com
In-Reply-To: <4329753313F5A742A09953EE6CC1B3CE28C7D984@ORSMSX108.amr.corp.intel.com>
On Tue, Nov 27, 2012 at 01:06:17AM +0000, Hay, Joshua A wrote:
> The return value will be changed to len to preserve error codes returned from simple_write_to_buffer.
>
> However, changing the logic preceding this return breaks these functions. If simple_write_to_buffer returns a positive value, other actions are performed with this value. With this patch, the function will return immediately with that value instead. This will effectively break the ixgbe_debugfs write operations.
>
> So ultimately, the change should be:
> > + len = simple_write_to_buffer(ixgbe_dbg_reg_ops_buf,
> > + sizeof(ixgbe_dbg_reg_ops_buf)-1,
> > + ppos,
> > + buffer,
> > + count);
> > + if (len < 0)
> > + return -EFAULT;
>
> if (len < 0)
> return len;
>
Yes. Sorry, I wasn't reading carefully before. That looks fine.
regards,
dan carpenter
^ permalink raw reply
* pull-request: can-next 2012-11-27
From: Marc Kleine-Budde @ 2012-11-27 8:57 UTC (permalink / raw)
To: netdev; +Cc: linux-can@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 2876 bytes --]
Hello David,
this is pull request is for net-next. Contains a patch by Andreas
Larsson, which enables the sja1000 of driver to work under sparc.
AnilKumar Ch contributed a patch to improve the c_can support under
omap, Olivier Sobrie's patch brings support for the CAN/USB dongles
from Kvaser. In a bunch of patches by me missing MODULE_ALIAS and/or
MODULE_DEVICE_TABLE entries were added to the CAN drivers.
regards,
Marc
---
The following changes since commit 03f52a0a554210d5049eeed9f1bb29047dc807cb:
ip6mr: Add sizeof verification to MRT6_ASSERT and MT6_PIM (2012-11-26 17:35:58 -0500)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can-next.git for-davem
for you to fetch changes up to fc8f40b10e58f37ec07e7b0cf85d19e899bdf23f:
can: mpc5xxx_can: add MODULE_DEVICE_TABLE (2012-11-27 09:49:36 +0100)
----------------------------------------------------------------
Andreas Larsson (1):
can: sja1000: Make sja1000_of_platform selectable and compilable on SPARC
AnilKumar Ch (1):
can: c_can: Add d_can raminit support
Marc Kleine-Budde (8):
can: bfin_can: add MODULE_ALIAS
can: ti_hecc: add MODULE_ALIAS
can: sja1000_platform: add MODULE_ALIAS
can: cc770_platform: add MODULE_ALIAS and MODULE_DEVICE_TABLE
can: flexcan: add MODULE_DEVICE_TABLE
can: at91_can: add MODULE_DEVICE_TABLE
can: c_can_platform: add MODULE_DEVICE_TABLE
can: mpc5xxx_can: add MODULE_DEVICE_TABLE
Olivier Sobrie (1):
can: kvaser_usb: Add support for Kvaser CAN/USB devices
drivers/net/can/at91_can.c | 1 +
drivers/net/can/bfin_can.c | 1 +
drivers/net/can/c_can/c_can.c | 12 +
drivers/net/can/c_can/c_can.h | 3 +
drivers/net/can/c_can/c_can_platform.c | 30 +-
drivers/net/can/cc770/cc770_platform.c | 2 +
drivers/net/can/flexcan.c | 2 +
drivers/net/can/mscan/mpc5xxx_can.c | 1 +
drivers/net/can/sja1000/Kconfig | 2 +-
drivers/net/can/sja1000/sja1000_of_platform.c | 6 +-
drivers/net/can/sja1000/sja1000_platform.c | 1 +
drivers/net/can/ti_hecc.c | 1 +
drivers/net/can/usb/Kconfig | 29 +
drivers/net/can/usb/Makefile | 1 +
drivers/net/can/usb/kvaser_usb.c | 1627 +++++++++++++++++++++++++
15 files changed, 1715 insertions(+), 4 deletions(-)
create mode 100644 drivers/net/can/usb/kvaser_usb.c
--
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
* Re: [RFC net-next PATCH V1 7/9] net: frag queue locking per hash bucket
From: Jesper Dangaard Brouer @ 2012-11-27 9:07 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S. Miller, Florian Westphal, netdev, Pablo Neira Ayuso,
Thomas Graf, Cong Wang, Patrick McHardy, Paul E. McKenney,
Herbert Xu
In-Reply-To: <20121123130836.18764.9297.stgit@dragon>
On Fri, 2012-11-23 at 14:08 +0100, Jesper Dangaard Brouer wrote:
> DO NOT apply - patch not finished, can cause on OOPS/PANIC during hash rebuild
Think I have fixed this issue. And its even fixed in this patch, as the
oops occurred, when testing, with a slightly older version of this
patch.
> This patch implements per hash bucket locking for the frag queue
> hash. This removes two write locks, and the only remaining write
> lock is for protecting hash rebuild. This essentially reduce the
> readers-writer lock to a rebuild lock.
[... cut ...]
> diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
> index 1620a21..447423f 100644
> --- a/net/ipv4/inet_fragment.c
> +++ b/net/ipv4/inet_fragment.c
[...]
> @@ -102,9 +112,17 @@ EXPORT_SYMBOL(inet_frags_exit_net);
>
> static inline void fq_unlink(struct inet_frag_queue *fq, struct inet_frags *f)
> {
> - write_lock(&f->lock);
> + struct inet_frag_bucket *hb;
> + unsigned int hash;
> +
> + read_lock(&f->lock);
> + hash = f->hashfn(fq);
> + hb = &f->hash[hash];
Before the read_lock, were _here_ below then hash calc. Which is wrong,
and caused the oops, as the hash result can change, when rnd is changed,
during hash rebuild.
> +
> + spin_lock_bh(&hb->chain_lock);
> hlist_del(&fq->list);
> - write_unlock(&f->lock);
> + spin_unlock_bh(&hb->chain_lock);
> + read_unlock(&f->lock);
> inet_frag_lru_del(fq);
> }
[... cut ...]
^ permalink raw reply
* TCP and reordering
From: Saku Ytti @ 2012-11-27 9:32 UTC (permalink / raw)
To: netdev
Today due to fast retransmit performance on links which cause
reordering is appalling.
Is it too esoteric situation to handle gracefully? Couldn't we
maintain 'reorder' counter in socket, which is increment when we get
two copies of same packet after duplicate ack, if this counter is
sufficiently high in relation to packet loss, we could start delaying
duplicate acks as we'd expect to receive the sequence very soon.
--
++ytti
^ permalink raw reply
* Re: BQL support in gianfar causes network hickup
From: Keitel, Tino (ALC NetworX GmbH) @ 2012-11-27 9:36 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tino Keitel, Paul Gortmaker, netdev@vger.kernel.org
In-Reply-To: <1353950255.7553.6.camel@edumazet-glaptop>
On Mo, 2012-11-26 at 09:17 -0800, Eric Dumazet wrote:
> On Mon, 2012-11-26 at 18:08 +0100, Keitel, Tino (ALC NetworX GmbH)
> wrote:
> > On Mo, 2012-11-26 at 08:34 -0800, Eric Dumazet wrote:
> > > On Mon, 2012-11-26 at 11:01 +0100, Tino Keitel wrote:
> > > > On Sat, Nov 24, 2012 at 15:43:36 -0800, Eric Dumazet wrote:
> > > >
> > > > [...]
> > > >
> > > > > Hmm, I wonder if BQL makes a particular bug showing more often.
> > > > >
> > > > > I see gianfar uses a very small watchdog_timeo of 1 second, while many
> > > > > drivers use 5 seconds.
> > > > >
> > > > > What happens if you change this to 5 seconds ?
> > > >
> > > > I still got the trace and a failing ptp client.
> > > >
> > >
> > > Thanks. Is this bug easy to trigger ?
> > >
> > > I suspect a core issue and a race, likely to happen on your (non x86)
> > > hardware
> > >
> > > Could you add the following debugging patch ?
> >
> > No visible difference:
>
> OK it seems you trigger the problem fast !
>
> Please try the following as well :
Hi,
yes, it can be triggered within 2 minutes.
The patch makes no difference:
NETDEV WATCHDOG: eth1 (fsl-gianfar): transmit queue 0 timed out
------------[ cut here ]------------
WARNING:
at /home/keitelt1/src/git/linux-stable/net/sched/sch_generic.c:255
Modules linked in:
NIP: c02448e0 LR: c02448e0 CTR: c01c19b8
REGS: c7ffbe40 TRAP: 0700 Not tainted (3.7.0-rc6-dirty)
MSR: 00029032 <EE,ME,IR,DR,RI> CR: 22002044 XER: 20000000
TASK = c03dd370[0] 'swapper' THREAD: c03fe000
GPR00: c02448e0 c7ffbef0 c03dd370 0000003f 00000001 c001aea8 00000000
00000001
GPR08: 00000001 c03e0000 00000000 0000009d 22002084 1008eb5c 07ffb000
ffffffff
GPR16: 00000004 c0362c7c c03dfbf8 00200000 c0411ed0 c0411cd0 c0411ad0
ffffffff
GPR24: 00000000 c749e1d8 00000004 c783c330 c0400000 c03e0000 c749e000
00000000
NIP [c02448e0] dev_watchdog+0x288/0x298
LR [c02448e0] dev_watchdog+0x288/0x298
Call Trace:
[c7ffbef0] [c02448e0] dev_watchdog+0x288/0x298 (unreliable)
[c7ffbf20] [c00267f8] call_timer_fn+0x6c/0xd8
[c7ffbf50] [c00269e4] run_timer_softirq+0x180/0x1f8
[c7ffbfa0] [c0021144] __do_softirq+0xc4/0x160
[c7ffbff0] [c000d0b8] call_do_softirq+0x14/0x24
[c03ffe90] [c00058e8] do_softirq+0x8c/0xb8
[c03ffeb0] [c0021358] irq_exit+0x98/0xb4
[c03ffec0] [c0009fb0] timer_interrupt+0x158/0x170
[c03ffee0] [c000f02c] ret_from_except+0x0/0x14
--- Exception: 901 at cpu_idle+0x94/0x100
LR = cpu_idle+0x94/0x100
[c03fffa0] [c00088ec] cpu_idle+0x5c/0x100 (unreliable)
[c03fffc0] [c03b37b0] start_kernel+0x2dc/0x2f0
[c03ffff0] [00003438] 0x3438
Instruction dump:
7d2903a6 4e800421 80fe01fc 4bffff74 7fc3f378 4bfecb7d 7fc4f378 7fe6fb78
7c651b78 3c60c038 38637280 48090e69 <0fe00000> 39200001 993cc7c9
4bffffb8
---[ end trace 26a9da9c2717d65b ]---
Regards,
Tino
^ permalink raw reply
* [PATCH 1/2] ewrk3: silence GCC warning
From: Paul Bolle @ 2012-11-27 9:47 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, richard -rw- weinberger
Building ewrk3.o triggers this GCC warning:
drivers/net/ethernet/dec/ewrk3.c: In function '__check_irq':
drivers/net/ethernet/dec/ewrk3.c:1915:1: warning: return from incompatible pointer type [enabled by default]
This can be trivially fixed by changing the 'irq' parameter from int to
byte (which is an alias for unsigned char for module parameters).
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
Only compile tested.
drivers/net/ethernet/dec/ewrk3.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/dec/ewrk3.c b/drivers/net/ethernet/dec/ewrk3.c
index 17ae8c6..2ee1c47 100644
--- a/drivers/net/ethernet/dec/ewrk3.c
+++ b/drivers/net/ethernet/dec/ewrk3.c
@@ -1912,7 +1912,7 @@ static int io[MAX_NUM_EWRK3S+1] = { 0x300, 0, };
/* '21' below should really be 'MAX_NUM_EWRK3S' */
module_param_array(io, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_array(irq, byte, NULL, 0);
MODULE_PARM_DESC(io, "EtherWORKS 3 I/O base address(es)");
MODULE_PARM_DESC(irq, "EtherWORKS 3 IRQ number(s)");
--
1.7.7.6
^ permalink raw reply related
* [PATCH 2/2] ewrk3: remove outdated comment
From: Paul Bolle @ 2012-11-27 9:48 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, richard -rw- weinberger
Remove an outdated comment, that should have been removed in the
patch named "MODULE_PARM conversions" from early 2005.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
drivers/net/ethernet/dec/ewrk3.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/dec/ewrk3.c b/drivers/net/ethernet/dec/ewrk3.c
index 2ee1c47..9f992b9 100644
--- a/drivers/net/ethernet/dec/ewrk3.c
+++ b/drivers/net/ethernet/dec/ewrk3.c
@@ -1910,7 +1910,6 @@ static struct net_device *ewrk3_devs[MAX_NUM_EWRK3S];
static int ndevs;
static int io[MAX_NUM_EWRK3S+1] = { 0x300, 0, };
-/* '21' below should really be 'MAX_NUM_EWRK3S' */
module_param_array(io, int, NULL, 0);
module_param_array(irq, byte, NULL, 0);
MODULE_PARM_DESC(io, "EtherWORKS 3 I/O base address(es)");
--
1.7.7.6
^ permalink raw reply related
* [RFC PATCH 1/2] bridge: export port_no and port_id via IFA_INFO_DATA
From: Cong Wang @ 2012-11-27 9:49 UTC (permalink / raw)
To: netdev
Cc: Cong Wang, bridge, Herbert Xu, Jesper Dangaard Brouer,
Thomas Graf, Stephen Hemminger, David S. Miller
Based on net-next.
This patch exports port->port_no port->port_id in the end of IFA_INFO_DATA.
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Thomas Graf <tgraf@suug.ch>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
include/uapi/linux/if_link.h | 2 ++
net/bridge/br_netlink.c | 8 +++++++-
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index bb58aeb..9cd91a9 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -218,6 +218,8 @@ enum {
IFLA_BRPORT_MODE, /* mode (hairpin) */
IFLA_BRPORT_GUARD, /* bpdu guard */
IFLA_BRPORT_PROTECT, /* root port protection */
+ IFLA_BRPORT_NO, /* port no */
+ IFLA_BRPORT_ID, /* port id */
__IFLA_BRPORT_MAX
};
#define IFLA_BRPORT_MAX (__IFLA_BRPORT_MAX - 1)
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 65429b9..7b7414e 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -28,6 +28,8 @@ static inline size_t br_port_info_size(void)
+ nla_total_size(1) /* IFLA_BRPORT_MODE */
+ nla_total_size(1) /* IFLA_BRPORT_GUARD */
+ nla_total_size(1) /* IFLA_BRPORT_PROTECT */
+ + nla_total_size(2) /* IFLA_BRPORT_NO */
+ + nla_total_size(2) /* IFLA_BRPORT_ID */
+ 0;
}
@@ -53,7 +55,9 @@ static int br_port_fill_attrs(struct sk_buff *skb,
nla_put_u32(skb, IFLA_BRPORT_COST, p->path_cost) ||
nla_put_u8(skb, IFLA_BRPORT_MODE, mode) ||
nla_put_u8(skb, IFLA_BRPORT_GUARD, !!(p->flags & BR_BPDU_GUARD)) ||
- nla_put_u8(skb, IFLA_BRPORT_PROTECT, !!(p->flags & BR_ROOT_BLOCK)))
+ nla_put_u8(skb, IFLA_BRPORT_PROTECT, !!(p->flags & BR_ROOT_BLOCK)) ||
+ nla_put_u16(skb, IFLA_BRPORT_NO, p->port_no) ||
+ nla_put_u16(skb, IFLA_BRPORT_ID, p->port_id))
return -EMSGSIZE;
return 0;
@@ -168,6 +172,8 @@ static const struct nla_policy ifla_brport_policy[IFLA_BRPORT_MAX + 1] = {
[IFLA_BRPORT_MODE] = { .type = NLA_U8 },
[IFLA_BRPORT_GUARD] = { .type = NLA_U8 },
[IFLA_BRPORT_PROTECT] = { .type = NLA_U8 },
+ [IFLA_BRPORT_NO] = { .type = NLA_U16 },
+ [IFLA_BRPORT_ID] = { .type = NLA_U16 },
};
/* Change the state of the port and notify spanning tree */
--
1.7.7.6
^ permalink raw reply related
* [RFC PATCH 2/2] bridge: export multicast database via netlink
From: Cong Wang @ 2012-11-27 9:49 UTC (permalink / raw)
To: netdev
Cc: bridge, Cong Wang, Herbert Xu, Stephen Hemminger, David S. Miller,
Thomas Graf, Jesper Dangaard Brouer
In-Reply-To: <1354009785-20014-1-git-send-email-amwang@redhat.com>
Based on net-next.
Warning: this patch is still a draft! :)
This patch exports bridge multicast database via netlink
message type RTM_GETMDB. Similar to fdb, but currently bridge-specific.
We may need to support modify multicast database too (RTM_{ADD,DEL}MDB).
So, the questions are:
1) Is this design okay?
2) Do we need to make it generic like fdb?
3) Do we need to support RTM_{ADD,DEL}MDB?
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Thomas Graf <tgraf@suug.ch>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
include/uapi/linux/if_bridge.h | 37 +++++++++
include/uapi/linux/rtnetlink.h | 3 +
net/bridge/Makefile | 2 +-
net/bridge/br_mdb.c | 174 ++++++++++++++++++++++++++++++++++++++++
net/bridge/br_multicast.c | 1 +
net/bridge/br_private.h | 1 +
6 files changed, 217 insertions(+), 1 deletions(-)
create mode 100644 net/bridge/br_mdb.c
diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
index b388579..f5655ea 100644
--- a/include/uapi/linux/if_bridge.h
+++ b/include/uapi/linux/if_bridge.h
@@ -116,4 +116,41 @@ enum {
__IFLA_BRIDGE_MAX,
};
#define IFLA_BRIDGE_MAX (__IFLA_BRIDGE_MAX - 1)
+
+/* Bridge multicast database attributes
+ * [MDBA_MDB] = {
+ * [MDBA_MCADDR]
+ * [MDBA_BRPORT] = {
+ * [MDBA_BRPORT_NO]
+ * }
+ * }
+ * [MDBA_ROUTER] = {
+ * [MDBA_BRPORT] = {
+ * [MDBA_BRPORT_NO]
+ * }
+ * }
+ */
+enum {
+ MDBA_UNSPEC,
+ MDBA_MDB,
+ MDBA_ROUTER,
+ __MDBA_MAX,
+};
+#define MDBA_MAX (__MDBA_MAX - 1)
+
+enum {
+ MDBA_MDB_UNSPEC,
+ MDBA_MDB_MCADDR,
+ MDBA_MDB_BRPORT,
+ __MDBA_MDB_MAX,
+};
+#define MDBA_MDB_MAX (__MDBA_MDB_MAX - 1)
+
+enum {
+ MDBA_BRPORT_UNSPEC,
+ MDBA_BRPORT_NO,
+ __MDBA_BRPORT_MAX,
+};
+#define MDBA_BRPORT_MAX (__MDBA_BRPORT_MAX - 1)
+
#endif /* _UAPI_LINUX_IF_BRIDGE_H */
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index 3dee071..0df623f 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -125,6 +125,9 @@ enum {
RTM_GETNETCONF = 82,
#define RTM_GETNETCONF RTM_GETNETCONF
+ RTM_GETMDB = 86,
+#define RTM_GETMDB RTM_GETMDB
+
__RTM_MAX,
#define RTM_MAX (((__RTM_MAX + 3) & ~3) - 1)
};
diff --git a/net/bridge/Makefile b/net/bridge/Makefile
index d0359ea..e859098 100644
--- a/net/bridge/Makefile
+++ b/net/bridge/Makefile
@@ -12,6 +12,6 @@ bridge-$(CONFIG_SYSFS) += br_sysfs_if.o br_sysfs_br.o
bridge-$(CONFIG_BRIDGE_NETFILTER) += br_netfilter.o
-bridge-$(CONFIG_BRIDGE_IGMP_SNOOPING) += br_multicast.o
+bridge-$(CONFIG_BRIDGE_IGMP_SNOOPING) += br_multicast.o br_mdb.o
obj-$(CONFIG_BRIDGE_NF_EBTABLES) += netfilter/
diff --git a/net/bridge/br_mdb.c b/net/bridge/br_mdb.c
new file mode 100644
index 0000000..dc73091
--- /dev/null
+++ b/net/bridge/br_mdb.c
@@ -0,0 +1,174 @@
+#include <linux/err.h>
+#include <linux/if_ether.h>
+#include <linux/igmp.h>
+#include <linux/kernel.h>
+#include <linux/netdevice.h>
+#include <linux/rculist.h>
+#include <linux/skbuff.h>
+#include <linux/slab.h>
+#include <net/ip.h>
+#if IS_ENABLED(CONFIG_IPV6)
+#include <net/ipv6.h>
+#include <net/mld.h>
+#include <net/addrconf.h>
+#include <net/ip6_checksum.h>
+#endif
+
+#include "br_private.h"
+
+struct br_port_msg {
+ int ifindex;
+};
+
+static int br_rports_fill_info(struct sk_buff *skb, struct netlink_callback *cb,
+ u32 seq, struct net_device *dev)
+{
+ struct net_bridge *br = netdev_priv(dev);
+ struct net_bridge_port *p;
+ struct hlist_node *n;
+ struct nlattr *nest, *nest2;
+
+ if (!br->multicast_router || hlist_empty(&br->router_list)) {
+ printk(KERN_INFO "no router on bridge\n");
+ return 0;
+ }
+
+ nest = nla_nest_start(skb, MDBA_ROUTER);
+ if (nest == NULL)
+ return -EMSGSIZE;
+ nest2 = nla_nest_start(skb, MDBA_MDB_BRPORT);
+ if (nest2 == NULL)
+ goto fail;
+
+ hlist_for_each_entry_rcu(p, n, &br->router_list, rlist) {
+ if (p && nla_put_u16(skb, MDBA_BRPORT_NO, p->port_no)) {
+ nla_nest_cancel(skb, nest2);
+ goto fail;
+ }
+ }
+
+ nla_nest_end(skb, nest2);
+ nla_nest_end(skb, nest);
+ return 0;
+fail:
+ nla_nest_cancel(skb, nest);
+ return -EMSGSIZE;
+}
+
+static int br_mdb_fill_info(struct sk_buff *skb, struct netlink_callback *cb,
+ u32 seq, struct net_device *dev)
+{
+ struct net_bridge *br = netdev_priv(dev);
+ struct net_bridge_mdb_htable *mdb;
+ struct nlattr *nest, *nest2;
+ unsigned int i;
+
+ if (br->multicast_disabled) {
+ printk(KERN_INFO "multicast is disabled on bridge\n");
+ return 0;
+ }
+
+ mdb = rcu_dereference(br->mdb);
+ if (!mdb) {
+ printk(KERN_INFO "no mdb on bridge\n");
+ return 0;
+ }
+
+ nest = nla_nest_start(skb, MDBA_MDB);
+ if (nest == NULL)
+ return -EMSGSIZE;
+
+ for (i = 0; i < mdb->max; i++) {
+ struct hlist_node *h;
+ struct net_bridge_mdb_entry *mp;
+ struct net_bridge_port_group *p, **pp;
+ struct net_bridge_port *port;
+
+ hlist_for_each_entry_rcu(mp, h, &mdb->mhash[i], hlist[mdb->ver]) {
+ if (nla_put_be32(skb, MDBA_MDB_MCADDR, mp->addr.u.ip4))
+ goto fail;
+
+ nest2 = nla_nest_start(skb, MDBA_MDB_BRPORT);
+ if (nest2 == NULL)
+ goto fail;
+
+ for (pp = &mp->ports;
+ (p = rcu_dereference(*pp)) != NULL;
+ pp = &p->next) {
+ port = p->port;
+ if (port) {
+ printk(KERN_INFO "port %u, mcaddr: %pI4\n", port->port_no, &mp->addr.u.ip4);
+ if (nla_put_u16(skb, MDBA_BRPORT_NO, port->port_no)) {
+ goto fail;
+ }
+ }
+ }
+
+ nla_nest_end(skb, nest2);
+ }
+ }
+
+ nla_nest_end(skb, nest);
+ return 0;
+fail:
+ nla_nest_cancel(skb, nest);
+ return -EMSGSIZE;
+}
+
+static int br_mdb_dump(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ struct net_device *dev;
+ struct net *net = sock_net(skb->sk);
+ struct nlmsghdr *nlh;
+ u32 seq = cb->nlh->nlmsg_seq;
+ int idx = 0, s_idx;
+
+ s_idx = cb->args[0];
+
+ rcu_read_lock();
+ cb->seq = net->dev_base_seq;
+
+ for_each_netdev_rcu(net, dev) {
+ if (dev->priv_flags & IFF_EBRIDGE) {
+ struct br_port_msg *bpm;
+
+ if (idx < s_idx)
+ goto cont;
+
+ nlh = nlmsg_put(skb, NETLINK_CB(cb->skb).portid,
+ seq, RTM_GETMDB,
+ sizeof(*bpm), NLM_F_MULTI);
+ if (nlh == NULL)
+ break;
+
+ bpm = nlmsg_data(nlh);
+ bpm->ifindex = dev->ifindex;
+ if (br_mdb_fill_info(skb, cb, seq, dev) < 0) {
+ printk(KERN_INFO "br_mdb_fill_info failed\n");
+ goto fail;
+ }
+ if (br_rports_fill_info(skb, cb, seq, dev) < 0) {
+ printk(KERN_INFO "br_rports_fill_info failed\n");
+ goto fail;
+ }
+
+ nlmsg_end(skb, nlh);
+cont:
+ idx++;
+ }
+ }
+
+ rcu_read_unlock();
+ cb->args[0] = idx;
+ return skb->len;
+
+fail:
+ rcu_read_unlock();
+ nlmsg_cancel(skb, nlh);
+ return skb->len;
+}
+
+void br_mdb_init(void)
+{
+ rtnl_register(PF_BRIDGE, RTM_GETMDB, NULL, br_mdb_dump, NULL);
+}
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 2417434..be69cd4 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1584,6 +1584,7 @@ void br_multicast_init(struct net_bridge *br)
br_multicast_querier_expired, (unsigned long)br);
setup_timer(&br->multicast_query_timer, br_multicast_query_expired,
(unsigned long)br);
+ br_mdb_init();
}
void br_multicast_open(struct net_bridge *br)
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index eb9cd42..bf0f6d5 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -432,6 +432,7 @@ extern int br_multicast_set_port_router(struct net_bridge_port *p,
extern int br_multicast_toggle(struct net_bridge *br, unsigned long val);
extern int br_multicast_set_querier(struct net_bridge *br, unsigned long val);
extern int br_multicast_set_hash_max(struct net_bridge *br, unsigned long val);
+extern void br_mdb_init(void);
static inline bool br_multicast_is_router(struct net_bridge *br)
{
--
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