* Re: [PATCH net-next] etherdevice: Optimize compare_ether_addr/ether_addr_equal
From: David Miller @ 2013-08-31 22:27 UTC (permalink / raw)
To: joe; +Cc: eric.dumazet, netdev
In-Reply-To: <1377939256.2054.11.camel@joe-AO722>
From: Joe Perches <joe@perches.com>
Date: Sat, 31 Aug 2013 01:54:16 -0700
> When CONFIG_HAS_EFFICIENT_UNALIGNED_ACCESS is set,
> optimize compare_ether_addr a little by removing an
> xor and or by using a u32 and u16 comparison
> instead of 3 separate u16 comparisons.
>
> Make the ether_addr_equal_64bits code a bit simpler
> by adding a test for CONFIG_64BIT and calling
> ether_addr_equal otherwise.
>
> This also slightly improves ether_addr_equal_64bits
> by removing the zap_last_2bytes shifts in the !64bit
> case.
>
> Signed-off-by: Joe Perches <joe@perches.com>
You'll need to update Documantion/unaligned-memory-access.txt as well
because it uses this funcation as a "real life" example.
^ permalink raw reply
* Re: [PATCH net-next 2/2] qdisc: fix build with !CONFIG_NET_SCHED
From: David Miller @ 2013-08-31 22:10 UTC (permalink / raw)
To: stephen; +Cc: netdev
In-Reply-To: <20130831101533.6cb8e452@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Sat, 31 Aug 2013 10:15:33 -0700
> Multiqueue scheduler refers to default_qdisc_ops; therefore the
> variable definition needs to be moved to handle case where net
> scheduler API is not available.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/2] qdisc: make args to qdisc_create_default const
From: David Miller @ 2013-08-31 22:10 UTC (permalink / raw)
To: stephen; +Cc: netdev
In-Reply-To: <20130831101550.1f7582e4@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Sat, 31 Aug 2013 10:15:50 -0700
> Fixes warnings introduced by the qdisc default patch.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied.
^ permalink raw reply
* Re: [PATCH][v3.2.y] inetpeer: Invalidate the inetpeer tree along with the routing cache
From: Ben Hutchings @ 2013-08-31 22:04 UTC (permalink / raw)
To: David S. Miller
Cc: netdev@vger.kernel.org, stable, LKML, Joseph Salisbury,
Steffen Klassert, Eric Dumazet
In-Reply-To: <5213A8BB.5070309@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]
On Tue, 2013-08-20 at 13:34 -0400, Joseph Salisbury wrote:
> Hello,
>
> Please consider including mainline commit 5faa5df in the next v3.2.y
> release. It was included in the mainline tree as of v3.3-rc7. It has
> been tested and confirmed to resolve
> http://bugs.launchpad.net/bugs/1205741 .
>
>
> commit 5faa5df1fa2024bd750089ff21dcc4191798263d
> Author: Steffen Klassert <steffen.klassert@secunet.com>
> Date: Tue Mar 6 21:20:26 2012 +0000
>
> inetpeer: Invalidate the inetpeer tree along with the routing cache
>
>
> Also note that commit 5faa5df introduced a race condition that is fixed
> by mainline commit 55432d2, so that commit would also be required:
>
> commit 55432d2b543a4b6dfae54f5c432a566877a85d90
> Author: Eric Dumazet <edumazet@google.com>
> Date: Tue Jun 5 03:00:18 2012 +0000
>
> inetpeer: fix a race in inetpeer_gc_worker()
David, could you ack/nak these for 3.2 (maybe 3.0 as well?).
Ben.
--
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH] rtl8187: fix use after free on failure path in rtl8187_init_urbs()
From: Alexey Khoroshilov @ 2013-08-31 21:18 UTC (permalink / raw)
To: Herton Ronaldo Krzesinski, Hin-Tak Leung, Larry Finger
Cc: Alexey Khoroshilov, John W. Linville, linux-wireless, netdev,
linux-kernel, ldv-project
In case of __dev_alloc_skb() failure rtl8187_init_urbs()
calls usb_free_urb(entry) where 'entry' can points to urb
allocated at the previous iteration. That means refcnt will be
decremented incorrectly and the urb can be used after memory
deallocation.
The patch fixes the issue and implements error handling of init_urbs
in rtl8187_start().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
---
drivers/net/wireless/rtl818x/rtl8187/dev.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8187/dev.c b/drivers/net/wireless/rtl818x/rtl8187/dev.c
index f49220e..e83d53c 100644
--- a/drivers/net/wireless/rtl818x/rtl8187/dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187/dev.c
@@ -438,17 +438,16 @@ static int rtl8187_init_urbs(struct ieee80211_hw *dev)
skb_queue_tail(&priv->rx_queue, skb);
usb_anchor_urb(entry, &priv->anchored);
ret = usb_submit_urb(entry, GFP_KERNEL);
+ usb_free_urb(entry);
if (ret) {
skb_unlink(skb, &priv->rx_queue);
usb_unanchor_urb(entry);
goto err;
}
- usb_free_urb(entry);
}
return ret;
err:
- usb_free_urb(entry);
kfree_skb(skb);
usb_kill_anchored_urbs(&priv->anchored);
return ret;
@@ -956,8 +955,12 @@ static int rtl8187_start(struct ieee80211_hw *dev)
(RETRY_COUNT << 8 /* short retry limit */) |
(RETRY_COUNT << 0 /* long retry limit */) |
(7 << 21 /* MAX TX DMA */));
- rtl8187_init_urbs(dev);
- rtl8187b_init_status_urb(dev);
+ ret = rtl8187_init_urbs(dev);
+ if (ret)
+ goto rtl8187_start_exit;
+ ret = rtl8187b_init_status_urb(dev);
+ if (ret)
+ usb_kill_anchored_urbs(&priv->anchored);
goto rtl8187_start_exit;
}
@@ -966,7 +969,9 @@ static int rtl8187_start(struct ieee80211_hw *dev)
rtl818x_iowrite32(priv, &priv->map->MAR[0], ~0);
rtl818x_iowrite32(priv, &priv->map->MAR[1], ~0);
- rtl8187_init_urbs(dev);
+ ret = rtl8187_init_urbs(dev);
+ if (ret)
+ goto rtl8187_start_exit;
reg = RTL818X_RX_CONF_ONLYERLPKT |
RTL818X_RX_CONF_RX_AUTORESETPHY |
--
1.8.1.2
^ permalink raw reply related
* Re: 1f324e3 ipv6: Don't depend on per socket memory for neighbour discovery messages
From: Fabio Estevam @ 2013-08-31 21:05 UTC (permalink / raw)
To: Stephen Warren
Cc: Thomas Graf, Eric Dumazet, Hannes Frederic Sowa, David S. Miller,
linux-next@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <5220F691.4020808@wwwdotorg.org>
Hi Stephen,
On Fri, Aug 30, 2013 at 4:46 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> Commit 1f324e3 "ipv6: Don't depend on per socket memory for neighbour
> discovery messages" appears to cause issues for me. If I run
This commit has been reverted in 'net' tree:
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=25ad6117e73656071b38fd19fa67ae325471c758
^ permalink raw reply
* Re: [PATCH net-next] etherdevice: Optimize compare_ether_addr/ether_addr_equal
From: Joe Perches @ 2013-08-31 20:58 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Eric Dumazet, netdev
In-Reply-To: <20130831094308.5a629f5a@nehalam.linuxnetplumber.net>
On Sat, 2013-08-31 at 09:43 -0700, Stephen Hemminger wrote:
> On Sat, 31 Aug 2013 01:54:16 -0700
> Joe Perches <joe@perches.com> wrote:
>
> > When CONFIG_HAS_EFFICIENT_UNALIGNED_ACCESS is set,
> > optimize compare_ether_addr a little by removing an
> > xor and or by using a u32 and u16 comparison
> > instead of 3 separate u16 comparisons.
> >
> > Make the ether_addr_equal_64bits code a bit simpler
> > by adding a test for CONFIG_64BIT and calling
> > ether_addr_equal otherwise.
> >
> > This also slightly improves ether_addr_equal_64bits
> > by removing the zap_last_2bytes shifts in the !64bit
> > case.
> >
> > Signed-off-by: Joe Perches <joe@perches.com>
> > ---
> > include/linux/etherdevice.h | 17 ++++++++++-------
> > 1 file changed, 10 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
> > index c623861..2514d17 100644
> > --- a/include/linux/etherdevice.h
> > +++ b/include/linux/etherdevice.h
> > @@ -208,11 +208,19 @@ static inline void eth_hw_addr_random(struct net_device *dev)
> > */
> > static inline unsigned compare_ether_addr(const u8 *addr1, const u8 *addr2)
> > {
> > +#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
> > + u32 fold = ((*(const u32 *)addr1) ^ (*(const u32 *)addr2));
> > + fold |= ((*(const u16 *)(addr1 + 4)) ^ (*(const u16 *)(addr2 + 4)));
> > +
> > + BUILD_BUG_ON(ETH_ALEN != 6);
> > + return fold != 0;
> > +#else
> > const u16 *a = (const u16 *) addr1;
> > const u16 *b = (const u16 *) addr2;
> >
> > BUILD_BUG_ON(ETH_ALEN != 6);
> > return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) != 0;
> > +#endif
> > }
> >
>
> If you really want to be efficient do it as one 64 bit mask and compare.
Nope.
That's what ether_addr_equal_64bits does
when it's known that a 64 bit test can be done.
Otherwise, there's no guarantee that 64 bits
are available to be read from 48 bits of data.
^ permalink raw reply
* Re: [PATCH net-next] etherdevice: Optimize compare_ether_addr/ether_addr_equal
From: Sergei Shtylyov @ 2013-08-31 19:41 UTC (permalink / raw)
To: Joe Perches; +Cc: David Miller, Eric Dumazet, netdev
In-Reply-To: <1377939256.2054.11.camel@joe-AO722>
Hello.
On 08/31/2013 12:54 PM, Joe Perches wrote:
> When CONFIG_HAS_EFFICIENT_UNALIGNED_ACCESS is set,
> optimize compare_ether_addr a little by removing an
> xor and or by using a u32 and u16 comparison
> instead of 3 separate u16 comparisons.
> Make the ether_addr_equal_64bits code a bit simpler
> by adding a test for CONFIG_64BIT and calling
> ether_addr_equal otherwise.
> This also slightly improves ether_addr_equal_64bits
> by removing the zap_last_2bytes shifts in the !64bit
> case.
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> include/linux/etherdevice.h | 17 ++++++++++-------
> 1 file changed, 10 insertions(+), 7 deletions(-)
> diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
> index c623861..2514d17 100644
> --- a/include/linux/etherdevice.h
> +++ b/include/linux/etherdevice.h
> @@ -208,11 +208,19 @@ static inline void eth_hw_addr_random(struct net_device *dev)
> */
> static inline unsigned compare_ether_addr(const u8 *addr1, const u8 *addr2)
> {
> +#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
> + u32 fold = ((*(const u32 *)addr1) ^ (*(const u32 *)addr2));
Could you keep the same style as before and insert empty line after
declaration?
> + fold |= ((*(const u16 *)(addr1 + 4)) ^ (*(const u16 *)(addr2 + 4)));
> +
> + BUILD_BUG_ON(ETH_ALEN != 6);
> + return fold != 0;
> +#else
> const u16 *a = (const u16 *) addr1;
> const u16 *b = (const u16 *) addr2;
>
> BUILD_BUG_ON(ETH_ALEN != 6);
> return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) != 0;
> +#endif
> }
>
> /**
WBR, Sergei
^ permalink raw reply
* Re: ipv4: warnings on sk_wmem_queued
From: dormando @ 2013-08-31 19:38 UTC (permalink / raw)
To: Eric Wong; +Cc: netdev, linux-kernel
In-Reply-To: <20130830195638.GA27393@dcvr.yhbt.net>
> I noticed these warnings on stock 3.10.9 running stress tests on
> cmogstored.git (git://bogomips.org/cmogstored.git) doing standard
> HTTP server stuff between lo and tmpfs:
>
[...]
> I was going to reboot into 3.10.10 before I looked at dmesg. These
> warnings happened after ~8 hours of stress tests, and those stress tests
> are still running.
I had a kernel panic this morning on a production machine, also running
3.10.9. I only got a small part of the end of the trace, but it matches:
> Aug 30 06:03:54 localhost kernel: [<ffffffff813c0073>] ip_queue_xmit+0x153/0x3c0
> Aug 30 06:03:54 localhost kernel: [<ffffffff813d6c25>] tcp_transmit_skb+0x3c5/0x820
> Aug 30 06:03:54 localhost kernel: [<ffffffff813d72c1>] tcp_write_xmit+0x191/0xaa0
> Aug 30 06:03:54 localhost kernel: [<ffffffff8138434c>] ? __kmalloc_reserve.isra.49+0x3c/0xa0
> Aug 30 06:03:54 localhost kernel: [<ffffffff813d7c42>] __tcp_push_pending_frames+0x32/0xa0
> Aug 30 06:03:54 localhost kernel: [<ffffffff813d8a8f>] tcp_send_fin+0x6f/0x190
> Aug 30 06:03:54 localhost kernel: [<ffffffff813cc508>] tcp_close+0x378/0x410
> Aug 30 06:03:54 localhost kernel: [<ffffffff813efe5a>] inet_release+0x5a/0xa0
> Aug 30 06:03:54 localhost kernel: [<ffffffff8137a218>] sock_release+0x28/0x90
> Aug 30 06:03:54 localhost kernel: [<ffffffff8137a5c2>] sock_close+0x12/0x20
> Aug 30 06:03:54 localhost kernel: [<ffffffff81123def>] __fput+0xaf/0x240
> Aug 30 06:03:54 localhost kernel: [<ffffffff8112403e>] ____fput+0xe/0x10
> Aug 30 06:03:54 localhost kernel: [<ffffffff81054d47>] task_work_run+0xa7/0xe0
> Aug 30 06:03:54 localhost kernel: [<ffffffff8100209c>] do_notify_resume+0x9c/0xb0
> Aug 30 06:03:54 localhost kernel: [<ffffffff81430788>] int_signal+0x12/0x17
... from there to here...
Then:
RIP [<ffffffff8113c42a> kmem_cache_alloc+0x5a/0x130
RSP <ffff881fffca3958>
---[ end trace 6ab931f3db28b31e ]---
Kernel panic - not syncing: Fatal exception in interrupt
Machine was running for a few days before panic'ing. I don't see anything
in 3.10.10 that would've affected this.
Thanks!
(also: hi Eric!)
^ permalink raw reply
* Re: [PATCH 15/31] net: netx-eth: use dev_get_platdata()
From: Sergei Shtylyov @ 2013-08-31 18:17 UTC (permalink / raw)
To: Jingoo Han; +Cc: 'David S. Miller', netdev
In-Reply-To: <003f01cea53d$b88030c0$29809240$%han@samsung.com>
Hello.
On 08/30/2013 08:59 AM, Jingoo Han wrote:
> Use the wrapper function for retrieving the platform data instead of
> accessing dev->platform_data directly. This is a cosmetic change
> to make the code simpler and enhance the readability.
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> ---
> drivers/net/ethernet/netx-eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> diff --git a/drivers/net/ethernet/netx-eth.c b/drivers/net/ethernet/netx-eth.c
> index dc2c6f5..235fd51 100644
> --- a/drivers/net/ethernet/netx-eth.c
> +++ b/drivers/net/ethernet/netx-eth.c
> @@ -390,7 +390,7 @@ static int netx_eth_drv_probe(struct platform_device *pdev)
>
> priv = netdev_priv(ndev);
>
> - pdata = (struct netxeth_platform_data *)pdev->dev.platform_data;
> + pdata = (struct netxeth_platform_data *)dev_get_platdata(&pdev->dev);
Cast from 'void *' is not needed. This is a material of another patch, of
course...
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 01/31] net: ax88796: use dev_get_platdata()
From: Sergei Shtylyov @ 2013-08-31 18:14 UTC (permalink / raw)
To: Jingoo Han; +Cc: 'David S. Miller', netdev
In-Reply-To: <003101cea53b$9fc95b30$df5c1190$%han@samsung.com>
Hello.
On 08/30/2013 08:44 AM, Jingoo Han wrote:
> Use the wrapper function for retrieving the platform data instead of
> accessing dev->platform_data directly. This is a cosmetic change
> to make the code simpler and enhance the readability.
This hardly achieves either...
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> ---
> drivers/net/ethernet/8390/ax88796.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> diff --git a/drivers/net/ethernet/8390/ax88796.c b/drivers/net/ethernet/8390/ax88796.c
> index b7232a9..f92f001 100644
> --- a/drivers/net/ethernet/8390/ax88796.c
> +++ b/drivers/net/ethernet/8390/ax88796.c
> @@ -840,7 +840,7 @@ static int ax_probe(struct platform_device *pdev)
> ei_local = netdev_priv(dev);
> ax = to_ax_dev(dev);
>
> - ax->plat = pdev->dev.platform_data;
> + ax->plat = dev_get_platdata(&pdev->dev);
> platform_set_drvdata(pdev, dev);
>
> ei_local->rxcr_base = ax->plat->rcr_val;
WBR, Sergei
^ permalink raw reply
* Re: [iproute2] macvlan: fix typo in macvlan_print_opt()
From: Stephen Hemminger @ 2013-08-31 17:32 UTC (permalink / raw)
To: Lutz Jaenicke; +Cc: netdev
In-Reply-To: <1377762628-28843-1-git-send-email-ljaenicke@innominate.com>
On Thu, 29 Aug 2013 09:50:28 +0200
Lutz Jaenicke <ljaenicke@innominate.com> wrote:
> The mode information is contained in IFLA_MACVLAN_MODE instead
> of IFLA_VLAN_ID (both evaluating to "1" in their enums).
>
> Signed-off-by: Lutz Jaenicke <ljaenicke@innominate.com>
Thanks applied.
^ permalink raw reply
* Re: [PATCH] iproute2: ip-route.8.in: minor fixes
From: Stephen Hemminger @ 2013-08-31 17:31 UTC (permalink / raw)
To: Richard Godbee; +Cc: netdev
In-Reply-To: <1377484819-23743-2-git-send-email-richard@godbee.net>
On Sun, 25 Aug 2013 22:40:19 -0400
Richard Godbee <richard@godbee.net> wrote:
> In SYNOPSIS section:
>
> - Add 'reordering'
> - Add missing '[' before 'quickack'
>
> Signed-off-by: Richard Godbee <richard@godbee.net>
All applied, thanks
^ permalink raw reply
* Re: [PATCH net-next v12 06/11] vxlan: add ipv6 support
From: Stephen Hemminger @ 2013-08-31 17:27 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, David S. Miller, David Stevens
In-Reply-To: <1377927878-23975-7-git-send-email-amwang@redhat.com>
On Sat, 31 Aug 2013 13:44:33 +0800
Cong Wang <amwang@redhat.com> wrote:
> +#if IS_ENABLED(CONFIG_IPV6)
> + } else {
> + ipv6_stub->ipv6_sock_mc_join(sk, ifindex,
> + &ip->sin6.sin6_addr);
> +#endif
This isn't safe against IPv6 module getting unloaded. You either
have to figure out a reference count method, or disable IPv6
module unload.
Since it can only be forced unload anyway, I still argue
it should just be disabled (by removing the module exit hook
and code).
^ permalink raw reply
* [BUG] missing rcu_derefernce of txq->qdisc
From: Stephen Hemminger @ 2013-08-31 17:23 UTC (permalink / raw)
To: David Miller, Joe Perches; +Cc: netdev
Way back in 2008, this commit added rcu_assign_pointer for the dev_queue->qdisc.
But we aren't using rcu_dereference to fetch the pointer, here and a couple
of other places. This is probably harmless, but could cause issues when compiler
decides to optimizations because of missing barrier.
static inline void netif_schedule_queue(struct netdev_queue *txq)
{
if (!(txq->state & QUEUE_STATE_ANY_XOFF))
__netif_schedule(txq->qdisc);
}
Adding the needed rcu_dereference creates other problems because the the
struct Qdisc needs to be fully known, net/sch_generic.h has to be included
from netdevice.h which creates other build problems.
A good way to see all the fallout is to put needed __rcu annotation
on netdev_tx_queue qdisc and use sparse.
I don't have time or patience to deal with it right now, maybe someone
else could have a go at it.
^ permalink raw reply
* [PATCH net-next 1/2] qdisc: make args to qdisc_create_default const
From: Stephen Hemminger @ 2013-08-31 17:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Fixes warnings introduced by the qdisc default patch.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/include/net/sch_generic.h 2013-08-31 09:40:20.933206054 -0700
+++ b/include/net/sch_generic.h 2013-08-31 09:50:18.309178508 -0700
@@ -370,9 +370,9 @@ void qdisc_reset(struct Qdisc *qdisc);
void qdisc_destroy(struct Qdisc *qdisc);
void qdisc_tree_decrease_qlen(struct Qdisc *qdisc, unsigned int n);
struct Qdisc *qdisc_alloc(struct netdev_queue *dev_queue,
- struct Qdisc_ops *ops);
+ const struct Qdisc_ops *ops);
struct Qdisc *qdisc_create_dflt(struct netdev_queue *dev_queue,
- struct Qdisc_ops *ops, u32 parentid);
+ const struct Qdisc_ops *ops, u32 parentid);
void __qdisc_calculate_pkt_len(struct sk_buff *skb,
const struct qdisc_size_table *stab);
void tcf_destroy(struct tcf_proto *tp);
--- a/net/sched/sch_generic.c 2013-08-31 09:40:20.949205839 -0700
+++ b/net/sched/sch_generic.c 2013-08-31 09:50:18.313178455 -0700
@@ -534,7 +534,7 @@ struct Qdisc_ops pfifo_fast_ops __read_m
static struct lock_class_key qdisc_tx_busylock;
struct Qdisc *qdisc_alloc(struct netdev_queue *dev_queue,
- struct Qdisc_ops *ops)
+ const struct Qdisc_ops *ops)
{
void *p;
struct Qdisc *sch;
@@ -578,7 +578,8 @@ errout:
}
struct Qdisc *qdisc_create_dflt(struct netdev_queue *dev_queue,
- struct Qdisc_ops *ops, unsigned int parentid)
+ const struct Qdisc_ops *ops,
+ unsigned int parentid)
{
struct Qdisc *sch;
^ permalink raw reply
* Re: [PATCH net-next 2/2] qdisc: fix build with !CONFIG_NET_SCHED
From: Stephen Hemminger @ 2013-08-31 17:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20130831100442.60c99dc8@nehalam.linuxnetplumber.net>
Multiqueue scheduler refers to default_qdisc_ops; therefore the
variable definition needs to be moved to handle case where net
scheduler API is not available.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/net/sched/sch_api.c 2013-08-31 09:40:20.949205839 -0700
+++ b/net/sched/sch_api.c 2013-08-31 10:01:45.811672724 -0700
@@ -131,11 +131,6 @@ static DEFINE_RWLOCK(qdisc_mod_lock);
************************************************/
-/* Qdisc to use by default */
-
-const struct Qdisc_ops *default_qdisc_ops = &pfifo_fast_ops;
-EXPORT_SYMBOL(default_qdisc_ops);
-
/* The list of all installed queueing disciplines. */
static struct Qdisc_ops *qdisc_base;
--- a/net/sched/sch_generic.c 2013-08-31 09:50:18.313178455 -0700
+++ b/net/sched/sch_generic.c 2013-08-31 10:02:10.699323182 -0700
@@ -30,6 +30,10 @@
#include <net/pkt_sched.h>
#include <net/dst.h>
+/* Qdisc to use by default */
+const struct Qdisc_ops *default_qdisc_ops = &pfifo_fast_ops;
+EXPORT_SYMBOL(default_qdisc_ops);
+
/* Main transmission queue. */
/* Modifications to data participating in scheduling must be protected with
^ permalink raw reply
* Re: [E1000-devel] [PATCH] i40e: Fix 32 bit shift compilation warnings
From: Stephen Hemminger @ 2013-08-31 16:45 UTC (permalink / raw)
To: Joe Perches
Cc: Jeff Kirsher, e1000-devel, Bruce Allan, Jesse Brandeburg,
linux-kernel, John Ronciak, netdev
In-Reply-To: <1377913655.2070.45.camel@joe-AO722>
On Fri, 30 Aug 2013 18:47:35 -0700
Joe Perches <joe@perches.com> wrote:
> When dma_addr_t is a 32 bit value, >> 32 emits compiler warnings
> Use ((addr>>16) >>16) to avoid this.
>
> I presume the macro should actually use the kernel.h
> macro upper_32_bits() eventually.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_hmc.h | 2 +-
> drivers/net/ethernet/intel/i40e/i40e_type.h | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_hmc.h b/drivers/net/ethernet/intel/i40e/i40e_hmc.h
> index 745fb355..2f1b72f 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_hmc.h
> +++ b/drivers/net/ethernet/intel/i40e/i40e_hmc.h
> @@ -123,7 +123,7 @@ struct i40e_hmc_info {
> #define I40E_SET_PF_SD_ENTRY(hw, pa, sd_index, type) \
> { \
> u32 val1, val2, val3; \
> - val1 = (u32)((pa) >> sizeof(u32) * 8); \
> + val1 = (u32)(I40E_HI_DWORD(pa)); \
> val2 = (u32)(pa) | (I40E_HMC_MAX_BP_COUNT << \
> I40E_PFHMC_SDDATALOW_PMSDBPCOUNT_SHIFT) | \
> ((((type) == I40E_SD_TYPE_PAGED) ? 0 : 1) << \
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_type.h b/drivers/net/ethernet/intel/i40e/i40e_type.h
> index 36e35cc..4263cf7 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_type.h
> +++ b/drivers/net/ethernet/intel/i40e/i40e_type.h
> @@ -78,8 +78,8 @@ typedef void (*I40E_ADMINQ_CALLBACK)(struct i40e_hw *, struct i40e_aq_desc *);
> #define I40E_ETH_LENGTH_OF_ADDRESS 6
>
> /* Data type manipulation macros. */
> -#define I40E_HI_DWORD(x) ((u32)(((x)>>32)&0xFFFFFFFF))
> -#define I40E_LO_DWORD(x) ((u32)((x)&0xFFFFFFFF))
> +#define I40E_HI_DWORD(x) ((u32)((((x) >> 16) >> 16) & 0xFFFFFFFF))
> +#define I40E_LO_DWORD(x) ((u32)((x) & 0xFFFFFFFF))
>
> #define I40E_HI_WORD(x) ((u16)(((x)>>16)&0xFFFF))
> #define I40E_DESC_UNUSED(R) \
After seeing this before in other drivers, a standard set of macros
was added called upper_32bits and lower_32bits. These should be used instead
of masking.
^ permalink raw reply
* Re: [PATCH net-next] etherdevice: Optimize compare_ether_addr/ether_addr_equal
From: Stephen Hemminger @ 2013-08-31 16:43 UTC (permalink / raw)
To: Joe Perches; +Cc: David Miller, Eric Dumazet, netdev
In-Reply-To: <1377939256.2054.11.camel@joe-AO722>
On Sat, 31 Aug 2013 01:54:16 -0700
Joe Perches <joe@perches.com> wrote:
> When CONFIG_HAS_EFFICIENT_UNALIGNED_ACCESS is set,
> optimize compare_ether_addr a little by removing an
> xor and or by using a u32 and u16 comparison
> instead of 3 separate u16 comparisons.
>
> Make the ether_addr_equal_64bits code a bit simpler
> by adding a test for CONFIG_64BIT and calling
> ether_addr_equal otherwise.
>
> This also slightly improves ether_addr_equal_64bits
> by removing the zap_last_2bytes shifts in the !64bit
> case.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> include/linux/etherdevice.h | 17 ++++++++++-------
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
> index c623861..2514d17 100644
> --- a/include/linux/etherdevice.h
> +++ b/include/linux/etherdevice.h
> @@ -208,11 +208,19 @@ static inline void eth_hw_addr_random(struct net_device *dev)
> */
> static inline unsigned compare_ether_addr(const u8 *addr1, const u8 *addr2)
> {
> +#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
> + u32 fold = ((*(const u32 *)addr1) ^ (*(const u32 *)addr2));
> + fold |= ((*(const u16 *)(addr1 + 4)) ^ (*(const u16 *)(addr2 + 4)));
> +
> + BUILD_BUG_ON(ETH_ALEN != 6);
> + return fold != 0;
> +#else
> const u16 *a = (const u16 *) addr1;
> const u16 *b = (const u16 *) addr2;
>
> BUILD_BUG_ON(ETH_ALEN != 6);
> return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) != 0;
> +#endif
> }
>
If you really want to be efficient do it as one 64 bit mask and compare.
^ permalink raw reply
* Re: [PATCH 0/7] Drop support for Renesys H8/300 architecture
From: Guenter Roeck @ 2013-08-31 13:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Yoshinori Sato, Linus Torvalds, Wim Van Sebroeck,
Linux Kernel Mailing List, IDE-ML, Network Development,
Linux Watchdog Mailing List, David S. Miller, Al Viro, Eric Paris,
Greg Kroah-Hartman, Jiang Liu, David Howells, Thomas Gleixner,
Stephen Rothwell
In-Reply-To: <CAMuHMdW6KcHbpR_KzbTg9V_FJ8XvQAWQOB-2jXQxG5fo1wWg1A@mail.gmail.com>
On 08/30/2013 11:44 PM, Geert Uytterhoeven wrote:
> On Fri, Aug 30, 2013 at 9:37 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>> On Fri, Aug 30, 2013 at 12:14:20PM -0700, Linus Torvalds wrote:
>>> On Fri, Aug 30, 2013 at 12:11 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>
>>>> I would not mind if Linus would agree to pull it right away for 3.12,
>>>> but that seems to be a bit on the fast side.
>>>
>>> I'm ok with code deletion patches, I don't think that would be a
>>> problem. I didn't check them, but I assume this is all literally just
>>> removing code that is conditional on h8/300 config options?
>>>
>> Yes.
>>
>> I found a couple more since I sent the series, but nothing significant.
>>
>> What is your preference - keep it until 3.13, or prepare it now and send you
>> a pull request for 3.12 ?
>
> It would be nice to check with Sato-san, who wanted to attend Kernel
> Summit as a hobbyist architecture maintainer, and see what are his plans
> and opinions.
>
Yes, of course. My bad that my send script dropped him of all people from the
original e-mail :(. I fixed that in version 2.
Guenter
^ permalink raw reply
* Re: [-next] openvswitch BUILD_BUG_ON failed
From: Geert Uytterhoeven @ 2013-08-31 12:11 UTC (permalink / raw)
To: Jesse Gross
Cc: David Miller, Andy Zhou, dev@openvswitch.org, netdev,
Linux Kernel Mailing List, Linux-Next
In-Reply-To: <CAEP_g=-XxgK9HVxvcaW3RS2zfa+77pB4cqfLFC0rcV7QJc+2BQ@mail.gmail.com>
On Fri, Aug 30, 2013 at 3:11 AM, Jesse Gross <jesse@nicira.com> wrote:
> On Thu, Aug 29, 2013 at 3:10 PM, David Miller <davem@davemloft.net> wrote:
>> From: Jesse Gross <jesse@nicira.com>
>> Date: Thu, 29 Aug 2013 14:42:22 -0700
>>
>>> On Thu, Aug 29, 2013 at 2:21 PM, Geert Uytterhoeven
>>> <geert@linux-m68k.org> wrote:
>>>> However, I have some doubts about other alignment "enforcements":
>>>>
>>>> "__aligned(__alignof__(long))" makes the whole struct aligned to the
>>>> alignment rule for "long":
>>>> 1. This is only 2 bytes on m68k, i.e. != sizeof(long).
>>>> 2. This is 4 bytes on many 32-bit platforms, which may be less than the
>>>> default alignment for "__be64" (cfr. some members of struct
>>>> ovs_key_ipv4_tunnel), so this may make those 64-bit members unaligned.
>>>
>>> Do any of those 32-bit architectures actually care about alignment of
>>> 64 bit values? On 32-bit x86, a long is 32 bits but the alignment
>>> requirement of __be64 is also 32 bit.
>>
>> All except x86-32 do, it is in fact the odd man out with respect to this
>> issue.
>
> Thanks, good to know.
>
> Andy, do you want to modify your patch to just drop the alignment
> specification as Geert suggested (but definitely keep the new build
> assert that you added)? It's probably better to just send the patch to
> netdev (against net-next) as well since you'll likely get better
> comments there and we can fix this faster if you cut out the
> middleman.
Why do you want to keep the build asserts?
Is this in-memory structure also transfered as-is over the network?
If yes, you definitely want the padding.
Nevertheless, as the struct contains u32 and even __be64 members, the
size of the struct will always be a multiple of the alignment unit for
64-bit quantities (and thus also for long), as per the C standard.
Hence the check
BUILD_BUG_ON(sizeof(struct sw_flow_key) % __alignof__(long));
will only catch bad compiler bugs or people adding __packed to the struct.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Realtek r8168 hangs when sending data at full speed on a gigabit link
From: Frédéric Leroy @ 2013-08-31 10:15 UTC (permalink / raw)
To: netdev; +Cc: Realtek linux nic maintainers, Francois Romieu
Hello,
My network card hangs when I send data at full speed on a gigabit link.
This is a realtek :
[fredo:~/work/r8169] $ lspci | grep Realtek
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 09)
[fredo:~/work/r8169] $ dmesg | grep r8169
[ 1.732159] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 1.732376] r8169 0000:02:00.0: irq 89 for MSI/MSI-X
[ 1.732635] r8169 0000:02:00.0 eth0: RTL8168f/8111f at
0xffffc9000066a000, 60:a4:4c:5a:db:cf, XID 08000800 IRQ 89
[ 1.732639] r8169 0000:02:00.0 eth0: jumbo features [frames:
9200 bytes, tx checksumming: ko]
[ 8.400499] r8169 0000:02:00.0 eth0: link down
[ 8.400520] r8169 0000:02:00.0 eth0: link down
[ 11.218946] r8169 0000:02:00.0 eth0: link up
I tried several kernel, up to 3.11.0-rc7+ and found that 3.1.0 works,
but bisecting the kernel gives me random result, depending on my "bad"
start point :
262eb9b2237ecee047451a636e799ea1572b685a cfg80211: split
wext compatibility to separate header
7af40ad909e3e92a1cbb728999c427d2fa3b381d igb: push data
into first igb_tx_buffer sooner to reduce stack usage
f53b170f465d52546c33faa962c3d2609a6bf5b3 brcm80211:
removed unused functions
The only clue I have is the IO_PAGE_FAULT in the kernel logs :
Aug 26 09:46:17 devel kernel: [ 0.000000] Linux version
3.8.0-29-generic (buildd@roseapple) (gcc version 4.7.3 (Ubuntu/Linaro
4.7.3-1ubuntu1) ) #42-Ubuntu SMP Tue Aug 13 19:40:39 UTC 2013 (Ubuntu
3.8.0-29.42-generic 3.8.13.5)
Aug 26 09:49:13 devel kernel: [ 184.973716] AMD-Vi: Event
logged [IO_PAGE_FAULT device=02:00.0 domain=0x0015
address=0x0000000000003000 flags=0x0050]
Aug 26 09:49:43 devel kernel: [ 214.970724] ------------[ cut
here ]------------
Aug 26 09:49:43 devel kernel: [ 214.970731] WARNING: at
/build/buildd/linux-3.8.0/net/sched/sch_generic.c:254
dev_watchdog+0x242/0x250()
Aug 26 09:49:43 devel kernel: [ 214.970732] Hardware name: To
be filled by O.E.M.
Aug 26 09:49:43 devel kernel: [ 214.970733] NETDEV WATCHDOG:
eth0 (r8169): transmit queue 0 timed out
Aug 26 09:49:43 devel kernel: [ 214.970734] Modules linked in:
nls_iso8859_1(F) usb_storage(F) arc4(F) md4(F) nls_utf8 cifs(F)
fscache(F) pci_stub vboxpci(OF) vboxnetadp(OF) vboxnetflt(OF)
vboxdrv(OF) rfcomm parport_pc(F) ppdev(F) bnep bluetooth binfmt_misc(F)
e4000 snd_hda_codec_hdmi rtl2832 ext2(F) dvb_usb_rtl28xxu rtl2830
dvb_usb_v2 dvb_core rc_core usblp kvm_amd eeepc_wmi joydev(F) asus_wmi
kvm sparse_keymap video(F) mxm_wmi ghash_clmulni_intel(F) aesni_intel(F)
aes_x86_64(F) xts(F) lrw(F) gf128mul(F) snd_hda_codec_realtek
ablk_helper(F) cryptd(F) microcode(F) snd_hda_intel snd_seq_midi(F)
radeon snd_hda_codec snd_seq_midi_event(F) snd_hwdep(F) snd_pcm(F)
snd_rawmidi(F) fam15h_power serio_raw(F) sp5100_tco snd_page_alloc(F)
snd_seq(F) snd_seq_device(F) k10temp ttm i2c_piix4 edac_core
snd_timer(F) edac_mce_amd drm_kms_helper drm snd(F) i2c_algo_bit wmi
soundcore(F) mac_hid lp(F) parport(F) hid_logitech_dj hid_generic usbhid
hid skge r8169 ahci(F) libahci(F)
Aug 26 09:49:43 devel kernel: [ 214.970774] Pid: 0, comm:
swapper/4 Tainted: GF O 3.8.0-29-generic #42-Ubuntu
Aug 26 09:49:43 devel kernel: [ 214.970776] Call Trace:
Aug 26 09:49:43 devel kernel: [ 214.970777] <IRQ>
[<ffffffff810589bf>] warn_slowpath_common+0x7f/0xc0
Aug 26 09:49:43 devel kernel: [ 214.970782]
[<ffffffff81058abc>] warn_slowpath_fmt+0x4c/0x50
Aug 26 09:49:43 devel kernel: [ 214.970785]
[<ffffffff81074e84>] ? insert_work+0x94/0xb0
Aug 26 09:49:43 devel kernel: [ 214.970789]
[<ffffffff815e8922>] dev_watchdog+0x242/0x250
Aug 26 09:49:43 devel kernel: [ 214.970791]
[<ffffffff815e86e0>] ? dev_graft_qdisc+0x90/0x90
Aug 26 09:49:43 devel kernel: [ 214.970793]
[<ffffffff810682a6>] call_timer_fn+0x36/0x110
Aug 26 09:49:43 devel kernel: [ 214.970795]
[<ffffffff815e86e0>] ? dev_graft_qdisc+0x90/0x90
Aug 26 09:49:43 devel kernel: [ 214.970797]
[<ffffffff81069ed6>] run_timer_softirq+0x1f6/0x2a0
Aug 26 09:49:43 devel kernel: [ 214.970800]
[<ffffffff8106110f>] __do_softirq+0xcf/0x200
Aug 26 09:49:43 devel kernel: [ 214.970803]
[<ffffffff81574150>] ? centrino_target+0x370/0x370
Aug 26 09:49:43 devel kernel: [ 214.970805]
[<ffffffff816d6a9c>] call_softirq+0x1c/0x30
Aug 26 09:49:43 devel kernel: [ 214.970808]
[<ffffffff81016555>] do_softirq+0x75/0xb0
Aug 26 09:49:43 devel kernel: [ 214.970810]
[<ffffffff810613a5>] irq_exit+0xa5/0xb0
Aug 26 09:49:43 devel kernel: [ 214.970812]
[<ffffffff816d741e>] smp_apic_timer_interrupt+0x6e/0x99
Aug 26 09:49:43 devel kernel: [ 214.970814]
[<ffffffff816d635d>] apic_timer_interrupt+0x6d/0x80
Aug 26 09:49:43 devel kernel: [ 214.970815] <EOI>
[<ffffffff81091a4d>] ? sched_clock_cpu+0xbd/0x110
Aug 26 09:49:43 devel kernel: [ 214.970819]
[<ffffffff81574b98>] ? cpuidle_wrap_enter+0x58/0xa0
Aug 26 09:49:43 devel kernel: [ 214.970821]
[<ffffffff81574bf0>] cpuidle_enter_tk+0x10/0x20
Aug 26 09:49:43 devel kernel: [ 214.970823]
[<ffffffff815747e5>] cpuidle_idle_call+0xa5/0x260
Aug 26 09:49:43 devel kernel: [ 214.970826]
[<ffffffff8101d5af>] cpu_idle+0xaf/0x120
Aug 26 09:49:43 devel kernel: [ 214.970828]
[<ffffffff816b6a83>] start_secondary+0x1e0/0x1e5
Aug 26 09:49:43 devel kernel: [ 214.970830] ---[ end trace
9135f3ab0912c9e0 ]---
Aug 26 09:49:43 devel kernel: [ 214.977428] r8169 0000:02:00.0
eth0: link up
For triggering the bug, I use iperf, which either works, or hangs almost
immediately
with multiple threads :
iperf -c myiperfserver -P 3 -t 60
Could you help me to fix this ?
Best regards,
--
Frederic Leroy
^ permalink raw reply
* Re: [PATCH net-next] tcp: Change return value of tcp_rcv_established()
From: Daniel Borkmann @ 2013-08-31 9:28 UTC (permalink / raw)
To: Vijay Subramanian; +Cc: netdev, davem, eric.dumazet
In-Reply-To: <1377842617-663-1-git-send-email-subramanian.vijay@gmail.com>
On 08/30/2013 08:03 AM, Vijay Subramanian wrote:
> tcp_rcv_established() returns only one value namely 0. We change the return
> value to void (as suggested by David Miller).
>
> After commit 0c24604b (tcp: implement RFC 5961 4.2), we no longer send RSTs in
> response to SYNs. We can remove the check and processing on the return value of
> tcp_rcv_established().
>
> We also fix jtcp_rcv_established() in tcp_probe.c to match that of
> tcp_rcv_established().
>
> Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
> ---
> Changes: Earlier patch titled "tcp: Remove needless check of return value"
> fixed only the second issue above.
>
[...]
>
> csum_error:
> TCP_INC_STATS_BH(sock_net(sk), TCP_MIB_CSUMERRORS);
> @@ -5260,7 +5260,7 @@ csum_error:
>
> discard:
> __kfree_skb(skb);
> - return 0;
> + return;
> }
> EXPORT_SYMBOL(tcp_rcv_established);
You can remove this return here in discard case.
[...]
> diff --git a/net/ipv4/tcp_probe.c b/net/ipv4/tcp_probe.c
> index 622a437..8b10379 100644
> --- a/net/ipv4/tcp_probe.c
> +++ b/net/ipv4/tcp_probe.c
> @@ -122,7 +122,7 @@ static inline int tcp_probe_avail(void)
> * Hook inserted to be called before each receive packet.
> * Note: arguments must match tcp_rcv_established()!
> */
> -static int jtcp_rcv_established(struct sock *sk, struct sk_buff *skb,
> +static void jtcp_rcv_established(struct sock *sk, struct sk_buff *skb,
> const struct tcphdr *th, unsigned int len)
Also, you should align the second line here to match opening '('.
> {
> const struct tcp_sock *tp = tcp_sk(sk);
> @@ -172,7 +172,7 @@ static int jtcp_rcv_established(struct sock *sk, struct sk_buff *skb,
> }
>
> jprobe_return();
> - return 0;
> + return;
This return can then be removed if it's void anyway.
> }
>
[...]
^ permalink raw reply
* [PATCH net-next] etherdevice: Optimize compare_ether_addr/ether_addr_equal
From: Joe Perches @ 2013-08-31 8:54 UTC (permalink / raw)
To: David Miller; +Cc: Eric Dumazet, netdev
When CONFIG_HAS_EFFICIENT_UNALIGNED_ACCESS is set,
optimize compare_ether_addr a little by removing an
xor and or by using a u32 and u16 comparison
instead of 3 separate u16 comparisons.
Make the ether_addr_equal_64bits code a bit simpler
by adding a test for CONFIG_64BIT and calling
ether_addr_equal otherwise.
This also slightly improves ether_addr_equal_64bits
by removing the zap_last_2bytes shifts in the !64bit
case.
Signed-off-by: Joe Perches <joe@perches.com>
---
include/linux/etherdevice.h | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
index c623861..2514d17 100644
--- a/include/linux/etherdevice.h
+++ b/include/linux/etherdevice.h
@@ -208,11 +208,19 @@ static inline void eth_hw_addr_random(struct net_device *dev)
*/
static inline unsigned compare_ether_addr(const u8 *addr1, const u8 *addr2)
{
+#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
+ u32 fold = ((*(const u32 *)addr1) ^ (*(const u32 *)addr2));
+ fold |= ((*(const u16 *)(addr1 + 4)) ^ (*(const u16 *)(addr2 + 4)));
+
+ BUILD_BUG_ON(ETH_ALEN != 6);
+ return fold != 0;
+#else
const u16 *a = (const u16 *) addr1;
const u16 *b = (const u16 *) addr2;
BUILD_BUG_ON(ETH_ALEN != 6);
return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) != 0;
+#endif
}
/**
@@ -253,16 +261,11 @@ static inline unsigned long zap_last_2bytes(unsigned long value)
static inline bool ether_addr_equal_64bits(const u8 addr1[6+2],
const u8 addr2[6+2])
{
-#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
+#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) && defined(CONFIG_64BIT)
unsigned long fold = ((*(unsigned long *)addr1) ^
(*(unsigned long *)addr2));
- if (sizeof(fold) == 8)
- return zap_last_2bytes(fold) == 0;
-
- fold |= zap_last_2bytes((*(unsigned long *)(addr1 + 4)) ^
- (*(unsigned long *)(addr2 + 4)));
- return fold == 0;
+ return zap_last_2bytes(fold) == 0;
#else
return ether_addr_equal(addr1, addr2);
#endif
^ permalink raw reply related
* Re: Fwd: RFC 6980 on Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery
From: Fernando Gont @ 2013-08-31 5:22 UTC (permalink / raw)
To: Loganaden Velvindron, netdev
In-Reply-To: <20130815102507.GA24122@order.stressinduktion.org>
On 08/15/2013 07:25 AM, Hannes Frederic Sowa wrote:
>
>> 3) What will/could break with this diff in a production environment ?
>
> RA messages could get fragmented if a speaker puts lots of options in it. I
> hope all RA speakers already spread the options over multiple RAs, but I don't
> know. In case the RA is fragmented it will now be dropped silently.
My understanding is that some implementations were already dropping
fragmented RAs... so you better avoid fragmentation. Put another way:
you're already in trouble if you rely on fragmented ND messages.
Cheers,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
^ permalink raw reply
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