* Re: IPv6 path MTU discovery broken
From: Hannes Frederic Sowa @ 2013-10-06 12:44 UTC (permalink / raw)
To: Steinar H. Gunderson; +Cc: netdev, edumazet
In-Reply-To: <20131006120612.GA27852@sesse.net>
On Sun, Oct 06, 2013 at 02:06:12PM +0200, Steinar H. Gunderson wrote:
> On Sat, Sep 28, 2013 at 10:33:18PM +0200, Hannes Frederic Sowa wrote:
> >> So the “packet too big” packets really look like they're being ignored.
> >> However, they _do_ reach the kernel somehow, since Icmp6InPktTooBigs
> >> seems to increase.
> >>
> >> Could this be related somehow to the packets coming from 2001:67c:29f4::31,
> >> while the default route is to a link-local address? (An RPF issue?) This used
> >> to work (although it was often flaky for me) in 3.10 and before. I can't
> >> easily bisect, though, as I don't boot this machine too often.
> > This looks like a bug and should definitely get fixed. There should be
> > no RPF issue. May I have a look at your /proc/net/ipv6_route?
>
> It started again, so now I could capture what you asked for:
Thanks!
Do you know which remote IP address is part in the failing communication? Same
as above?
Greetings,
Hannes
^ permalink raw reply
* Re: IPv6 path MTU discovery broken
From: Steinar H. Gunderson @ 2013-10-06 12:48 UTC (permalink / raw)
To: netdev, edumazet
In-Reply-To: <20131006124403.GA9295@order.stressinduktion.org>
On Sun, Oct 06, 2013 at 02:44:03PM +0200, Hannes Frederic Sowa wrote:
> Do you know which remote IP address is part in the failing communication? Same
> as above?
It's in 2001:67c:a4:3::/64 or 2001:67c:a4:1::/64. Unsure which, because now
I rebooted the client for a different reason (giving it a different privacy
address and possibly subnet), and now it's unreproducible again...
/* Steinar */
--
Homepage: http://www.sesse.net/
^ permalink raw reply
* [PATCH net] net/mlx4_en: Fix pages never dma unmapped on rx
From: Amir Vadai @ 2013-10-06 12:57 UTC (permalink / raw)
To: netdev; +Cc: Amir Vadai, Or Gerlitz, Eugenia Emantayev, Eric Dumazet
This patch fixes a bug introduced by commit 51151a16 (mlx4: allow
order-0 memory allocations in RX path).
dma_unmap_page never reached because condition to detect last fragment
in page is wrong. offset+frag_stride can't be greater than size, need to
make sure no additional frag will fit in page => compare offset +
frag_stride + next_frag_size instead.
next_frag_size could be next frag in the same skb, or the first frag in
the next.
CC: Eric Dumazet <edumazet@google.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index dec455c..44d8865 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -131,8 +131,11 @@ static void mlx4_en_free_frag(struct mlx4_en_priv *priv,
int i)
{
const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i];
+ u16 next_frag_end = frags[i].offset + frag_info->frag_stride;
- if (frags[i].offset + frag_info->frag_stride > frags[i].size)
+ next_frag_end += frags[(i + 1) % priv->num_frags].size;
+
+ if (next_frag_end > frags[i].size)
dma_unmap_page(priv->ddev, frags[i].dma, frags[i].size,
PCI_DMA_FROMDEVICE);
--
1.8.3.4
^ permalink raw reply related
* Re: [PATCH net] net/mlx4_en: Fix pages never dma unmapped on rx
From: Eric Dumazet @ 2013-10-06 14:22 UTC (permalink / raw)
To: Amir Vadai; +Cc: netdev, Or Gerlitz, Eugenia Emantayev, Eric Dumazet
In-Reply-To: <1381064240-12902-1-git-send-email-amirv@mellanox.com>
On Sun, 2013-10-06 at 14:57 +0200, Amir Vadai wrote:
> This patch fixes a bug introduced by commit 51151a16 (mlx4: allow
> order-0 memory allocations in RX path).
>
> dma_unmap_page never reached because condition to detect last fragment
> in page is wrong. offset+frag_stride can't be greater than size, need to
> make sure no additional frag will fit in page => compare offset +
> frag_stride + next_frag_size instead.
> next_frag_size could be next frag in the same skb, or the first frag in
> the next.
>
> CC: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Amir Vadai <amirv@mellanox.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> index dec455c..44d8865 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> @@ -131,8 +131,11 @@ static void mlx4_en_free_frag(struct mlx4_en_priv *priv,
> int i)
> {
> const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i];
> + u16 next_frag_end = frags[i].offset + frag_info->frag_stride;
>
Hmm, could you make this an u32 ?
frags[i].offset and frags[i].size are u32
Maybe some folks want to use PAGE_SIZE=65536 or whatever high order
allocs
> - if (frags[i].offset + frag_info->frag_stride > frags[i].size)
> + next_frag_end += frags[(i + 1) % priv->num_frags].size;
> +
> + if (next_frag_end > frags[i].size)
> dma_unmap_page(priv->ddev, frags[i].dma, frags[i].size,
> PCI_DMA_FROMDEVICE);
>
Not sure I understand how this can work. How was this tested ?
frags[i + 1].size is the size of the page containing next fragment,
so now test should _always_ trigger.
(We could rename @size to @page_size to avoid confusion)
I think you meant to add the size of the next fragment ?
What about following instead (I also removed the divide operation)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index dec455c..22444de 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -131,10 +131,17 @@ static void mlx4_en_free_frag(struct mlx4_en_priv *priv,
int i)
{
const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i];
+ u32 next_frag_end = frags[i].offset + frag_info->frag_stride;
- if (frags[i].offset + frag_info->frag_stride > frags[i].size)
+ frag_info++;
+ if (i + 1 == priv->num_frags)
+ frag_info = &priv->frag_info[0];
+
+ next_frag_end += frag_info->frag_stride;
+
+ if (next_frag_end > frags[i].size)
dma_unmap_page(priv->ddev, frags[i].dma, frags[i].size,
- PCI_DMA_FROMDEVICE);
+ PCI_DMA_FROMDEVICE);
if (frags[i].page)
put_page(frags[i].page);
^ permalink raw reply related
* Re: [PATCH] Fix the upper MTU limit in ipv6 GRE tunnel
From: Oussama Ghorbel @ 2013-10-06 14:42 UTC (permalink / raw)
To: Oussama Ghorbel, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <20131005140636.GA25076@order.stressinduktion.org>
On Sat, Oct 5, 2013 at 3:06 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Fri, Oct 04, 2013 at 10:52:13AM +0100, Oussama Ghorbel wrote:
>> Unlike ipv4, the struct member hlen holds the length of the GRE and ipv6
>> headers. This length is also counted in dev->hard_header_len.
>> Perhaps, it's more clean to modify the hlen to count only the GRE header
>> without ipv6 header as the variable name suggest, but the simple way to fix
>> this without regression risk is simply modify the calculation of the limit
>> in ip6gre_tunnel_change_mtu function.
>> Verified in kernel version v3.11.
>>
>> Signed-off-by: Oussama Ghorbel <ou.ghorbel@gmail.com>
>> ---
>> net/ipv6/ip6_gre.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
>> index 90747f1..41487ab 100644
>> --- a/net/ipv6/ip6_gre.c
>> +++ b/net/ipv6/ip6_gre.c
>> @@ -1175,9 +1175,8 @@ done:
>>
>> static int ip6gre_tunnel_change_mtu(struct net_device *dev, int new_mtu)
>> {
>> - struct ip6_tnl *tunnel = netdev_priv(dev);
>> if (new_mtu < 68 ||
>> - new_mtu > 0xFFF8 - dev->hard_header_len - tunnel->hlen)
>> + new_mtu > 0xFFF8 - dev->hard_header_len)
>> return -EINVAL;
>> dev->mtu = new_mtu;
>> return 0;
>
> Hmmm...
>
> dev->hard_header_len is initialized to LL_MAX_HEADER + sizeof(struct ipv6hdr)
> + 4 but won't include the additional head space needed for GRE_SEQ, GRE_KEY
> etc. if at time of tunnel creation the routing table did not had a good guess
> for the outgoing device.
>
This hard_header_len initialization that you have shown above is taken
from ip6gre_tunnel_setup, however this same variable seems to be
reinitialized in ip6gre_tnl_link_config() which are called from
ip6gre_newlink()
The initialization in ip6gre_tnl_link_config is done as the following:
static void ip6gre_tnl_link_config(struct ip6_tnl *t, int set_mtu)
{
...
int addend = sizeof(struct ipv6hdr) + 4;
...
/* Precalculate GRE options length */
if (t->parms.o_flags&(GRE_CSUM|GRE_KEY|GRE_SEQ)) {
if (t->parms.o_flags&GRE_CSUM)
addend += 4;
if (t->parms.o_flags&GRE_KEY)
addend += 4;
if (t->parms.o_flags&GRE_SEQ)
addend += 4;
}
...
dev->hard_header_len = rt->dst.dev->hard_header_len + addend;
...
t->hlen = addend;
..
}
Unless they are other reasons, the hard_header_len is taken into
account the GRE_KEY, GRE_SEQ ..
> To make this correct we would have to refactor the usage of the variables a
> bit as is done in ipv4/ip_tunnel.c. The safest thing would be to leave this
> check as-is currently although we exclude some allowed mtus.
>
> Perhaps you want to take a look how to achieve that? ;)
>
Why not, consistency is good ...
> Greetings,
>
> Hannes
>
Thanks,
Oussama
^ permalink raw reply
* Re: [PATCH] usbnet: smsc95xx: Add device tree input for MAC address
From: Ming Lei @ 2013-10-06 15:05 UTC (permalink / raw)
To: Dan Murphy
Cc: Steve Glendinning, Network Development, Linux Kernel Mailing List,
linux-usb, mugunthanvnm
In-Reply-To: <1380911156-14112-1-git-send-email-dmurphy@ti.com>
On Sat, Oct 5, 2013 at 2:25 AM, Dan Murphy <dmurphy@ti.com> wrote:
> If the smsc95xx does not have a valid MAC address stored within
> the eeprom then a random number is generated. The MAC can also
> be set by uBoot but the smsc95xx does not have a way to read this.
>
> Create the binding for the smsc95xx so that uBoot can set the MAC
> and the code can retrieve the MAC from the modified DTB file.
Suppose there are two smsc95xx usbnet devices connected to usb bus, and
one is built-in, another is hotplug device, can your patch handle the situation
correctly?
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
> Documentation/devicetree/bindings/net/smsc95xx.txt | 17 ++++++++++++++
> drivers/net/usb/smsc95xx.c | 24 ++++++++++++++++++++
> 2 files changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/smsc95xx.txt
>
> diff --git a/Documentation/devicetree/bindings/net/smsc95xx.txt b/Documentation/devicetree/bindings/net/smsc95xx.txt
> new file mode 100644
> index 0000000..4c37280
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/smsc95xx.txt
> @@ -0,0 +1,17 @@
> +* Smart Mixed-Signal Connectivity (SMSC) 95xx Controller
> +
> +Required properties:
> +None
> +
> +Optional properties:
> +- mac-address - Read the mac address that was stored by uBoot
> +- local-address - Read the mac address that was stored by uBoot
> +- address - Read the mac address that was stored by uBoot
> +
> +Examples:
> +
> +smsc0: smsc95xx@0 {
> + /* Filled in by U-Boot */
> + mac-address = [ 00 00 00 00 00 00 ];
> +};
> +
> diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
> index 3f38ba8..baee0bd 100644
> --- a/drivers/net/usb/smsc95xx.c
> +++ b/drivers/net/usb/smsc95xx.c
> @@ -31,6 +31,9 @@
> #include <linux/crc32.h>
> #include <linux/usb/usbnet.h>
> #include <linux/slab.h>
> +#include <linux/of.h>
> +#include <linux/of_net.h>
> +
> #include "smsc95xx.h"
>
> #define SMSC_CHIPNAME "smsc95xx"
> @@ -62,6 +65,8 @@
> #define SUSPEND_ALLMODES (SUSPEND_SUSPEND0 | SUSPEND_SUSPEND1 | \
> SUSPEND_SUSPEND2 | SUSPEND_SUSPEND3)
>
> +#define SMSC95XX_OF_NAME "/smsc95xx@"
> +
> struct smsc95xx_priv {
> u32 mac_cr;
> u32 hash_hi;
> @@ -767,6 +772,25 @@ static int smsc95xx_ioctl(struct net_device *netdev, struct ifreq *rq, int cmd)
>
> static void smsc95xx_init_mac_address(struct usbnet *dev)
> {
> +
> +#ifdef CONFIG_OF
> + struct device_node *ap;
> + const char *mac = NULL;
> + char *of_name = SMSC95XX_OF_NAME;
> +
> + sprintf(of_name, "%s%i", SMSC95XX_OF_NAME, dev->udev->dev.id);
> + ap = of_find_node_by_path(of_name);
> + if (ap) {
> + mac = of_get_mac_address(ap);
> + if (is_valid_ether_addr(mac)) {
> + /* Device tree has a mac for this so use that */
> + memcpy(dev->net->dev_addr, mac, ETH_ALEN);
> + netif_dbg(dev, ifup, dev->net, "MAC address read from DTB\n");
> + return;
> + }
> + }
> +#endif
> +
> /* try reading mac address from EEPROM */
> if (smsc95xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
> dev->net->dev_addr) == 0) {
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: Fix pages never dma unmapped on rx
From: Amir Vadai @ 2013-10-06 15:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Or Gerlitz, Eugenia Emantayev, Eric Dumazet
In-Reply-To: <1381069372.3564.68.camel@edumazet-glaptop.roam.corp.google.com>
On 06/10/2013 17:22, Eric Dumazet wrote:
> On Sun, 2013-10-06 at 14:57 +0200, Amir Vadai wrote:
>> This patch fixes a bug introduced by commit 51151a16 (mlx4: allow
>> order-0 memory allocations in RX path).
>>
>> dma_unmap_page never reached because condition to detect last fragment
>> in page is wrong. offset+frag_stride can't be greater than size, need to
>> make sure no additional frag will fit in page => compare offset +
>> frag_stride + next_frag_size instead.
>> next_frag_size could be next frag in the same skb, or the first frag in
>> the next.
>>
>> CC: Eric Dumazet <edumazet@google.com>
>> Signed-off-by: Amir Vadai <amirv@mellanox.com>
>> ---
>> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
>> index dec455c..44d8865 100644
>> --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
>> +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
>> @@ -131,8 +131,11 @@ static void mlx4_en_free_frag(struct mlx4_en_priv *priv,
>> int i)
>> {
>> const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i];
>> + u16 next_frag_end = frags[i].offset + frag_info->frag_stride;
>>
>
> Hmm, could you make this an u32 ?
>
> frags[i].offset and frags[i].size are u32
>
> Maybe some folks want to use PAGE_SIZE=65536 or whatever high order
> allocs
>
>
>> - if (frags[i].offset + frag_info->frag_stride > frags[i].size)
>> + next_frag_end += frags[(i + 1) % priv->num_frags].size;
>> +
>> + if (next_frag_end > frags[i].size)
>> dma_unmap_page(priv->ddev, frags[i].dma, frags[i].size,
>> PCI_DMA_FROMDEVICE);
>>
>
> Not sure I understand how this can work. How was this tested ?
>
> frags[i + 1].size is the size of the page containing next fragment,
> so now test should _always_ trigger.
>
> (We could rename @size to @page_size to avoid confusion)
>
> I think you meant to add the size of the next fragment ?
>
> What about following instead (I also removed the divide operation)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> index dec455c..22444de 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> @@ -131,10 +131,17 @@ static void mlx4_en_free_frag(struct mlx4_en_priv *priv,
> int i)
> {
> const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i];
> + u32 next_frag_end = frags[i].offset + frag_info->frag_stride;
>
> - if (frags[i].offset + frag_info->frag_stride > frags[i].size)
> + frag_info++;
> + if (i + 1 == priv->num_frags)
> + frag_info = &priv->frag_info[0];
> +
> + next_frag_end += frag_info->frag_stride;
> +
> + if (next_frag_end > frags[i].size)
> dma_unmap_page(priv->ddev, frags[i].dma, frags[i].size,
> - PCI_DMA_FROMDEVICE);
> + PCI_DMA_FROMDEVICE);
>
> if (frags[i].page)
> put_page(frags[i].page);
>
>
It looks good.
Will also change it into a small patchset with a new patch to rename
@size to @page_size and @offset to @page_offset.
I Will send it after I finish testing.
(Previously I had the typo added just after I removed the prints I used
while testing).
Thanks,
Amir
^ permalink raw reply
* Re: [PATCH] Fix the upper MTU limit in ipv6 GRE tunnel
From: Hannes Frederic Sowa @ 2013-10-06 15:13 UTC (permalink / raw)
To: Oussama Ghorbel
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <CABfLueFYZkzpEpDJ7YcHJaXfm-=QcgnL3-Es8gybea2cAacQQw@mail.gmail.com>
On Sun, Oct 06, 2013 at 03:42:15PM +0100, Oussama Ghorbel wrote:
> The initialization in ip6gre_tnl_link_config is done as the following:
> static void ip6gre_tnl_link_config(struct ip6_tnl *t, int set_mtu)
> {
> ...
> int addend = sizeof(struct ipv6hdr) + 4;
> ...
> /* Precalculate GRE options length */
> if (t->parms.o_flags&(GRE_CSUM|GRE_KEY|GRE_SEQ)) {
> if (t->parms.o_flags&GRE_CSUM)
> addend += 4;
> if (t->parms.o_flags&GRE_KEY)
> addend += 4;
> if (t->parms.o_flags&GRE_SEQ)
> addend += 4;
> }
> ...
> dev->hard_header_len = rt->dst.dev->hard_header_len + addend;
> ...
> t->hlen = addend;
> ..
> }
>
> Unless they are other reasons, the hard_header_len is taken into
> account the GRE_KEY, GRE_SEQ ..
But only if a new route is found. The hard_header_len reinitialization is
guarded by a (rt == NULL). We may have not found one on boot up.
> > To make this correct we would have to refactor the usage of the variables a
> > bit as is done in ipv4/ip_tunnel.c. The safest thing would be to leave this
> > check as-is currently although we exclude some allowed mtus.
> >
> > Perhaps you want to take a look how to achieve that? ;)
> >
> Why not, consistency is good ...
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH] Fix the upper MTU limit in ipv6 GRE tunnel
From: Oussama Ghorbel @ 2013-10-06 15:36 UTC (permalink / raw)
To: Oussama Ghorbel, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <20131006151351.GB9295@order.stressinduktion.org>
On Sun, Oct 6, 2013 at 4:13 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Sun, Oct 06, 2013 at 03:42:15PM +0100, Oussama Ghorbel wrote:
>> The initialization in ip6gre_tnl_link_config is done as the following:
>> static void ip6gre_tnl_link_config(struct ip6_tnl *t, int set_mtu)
>> {
>> ...
>> int addend = sizeof(struct ipv6hdr) + 4;
>> ...
>> /* Precalculate GRE options length */
>> if (t->parms.o_flags&(GRE_CSUM|GRE_KEY|GRE_SEQ)) {
>> if (t->parms.o_flags&GRE_CSUM)
>> addend += 4;
>> if (t->parms.o_flags&GRE_KEY)
>> addend += 4;
>> if (t->parms.o_flags&GRE_SEQ)
>> addend += 4;
>> }
>> ...
>> dev->hard_header_len = rt->dst.dev->hard_header_len + addend;
>> ...
>> t->hlen = addend;
>> ..
>> }
>>
>> Unless they are other reasons, the hard_header_len is taken into
>> account the GRE_KEY, GRE_SEQ ..
>
> But only if a new route is found. The hard_header_len reinitialization is
> guarded by a (rt == NULL). We may have not found one on boot up.
>
In that case the function will make a return and hlen will be zero.
Subtracting hlen in ip6gre_tunnel_change_mtu has no effect ...
>> > To make this correct we would have to refactor the usage of the variables a
>> > bit as is done in ipv4/ip_tunnel.c. The safest thing would be to leave this
>> > check as-is currently although we exclude some allowed mtus.
>> >
>> > Perhaps you want to take a look how to achieve that? ;)
>> >
>> Why not, consistency is good ...
>
> Thanks,
>
> Hannes
>
Thanks,
Oussama
^ permalink raw reply
* Re: [PATCH] Fix the upper MTU limit in ipv6 GRE tunnel
From: Hannes Frederic Sowa @ 2013-10-06 16:19 UTC (permalink / raw)
To: Oussama Ghorbel
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <CABfLueGefWM6m6h44yAMBo7=BMUcA=OvcFVYka06QvsxXUAJtw@mail.gmail.com>
On Sun, Oct 06, 2013 at 04:36:56PM +0100, Oussama Ghorbel wrote:
> On Sun, Oct 6, 2013 at 4:13 PM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
> > On Sun, Oct 06, 2013 at 03:42:15PM +0100, Oussama Ghorbel wrote:
> >> The initialization in ip6gre_tnl_link_config is done as the following:
> >> static void ip6gre_tnl_link_config(struct ip6_tnl *t, int set_mtu)
> >> {
> >> ...
> >> int addend = sizeof(struct ipv6hdr) + 4;
> >> ...
> >> /* Precalculate GRE options length */
> >> if (t->parms.o_flags&(GRE_CSUM|GRE_KEY|GRE_SEQ)) {
> >> if (t->parms.o_flags&GRE_CSUM)
> >> addend += 4;
> >> if (t->parms.o_flags&GRE_KEY)
> >> addend += 4;
> >> if (t->parms.o_flags&GRE_SEQ)
> >> addend += 4;
> >> }
> >> ...
> >> dev->hard_header_len = rt->dst.dev->hard_header_len + addend;
> >> ...
> >> t->hlen = addend;
> >> ..
> >> }
> >>
> >> Unless they are other reasons, the hard_header_len is taken into
> >> account the GRE_KEY, GRE_SEQ ..
> >
> > But only if a new route is found. The hard_header_len reinitialization is
> > guarded by a (rt == NULL). We may have not found one on boot up.
> >
> In that case the function will make a return and hlen will be zero.
> Subtracting hlen in ip6gre_tunnel_change_mtu has no effect ...
Oh yes, somehow I missed that.
We depend on t->hlen when pushing the gre header onto the skb. t->hlen == 0
should never be the case because we assume t->hlen > sizeof(struct ipv6_hdr).
^ permalink raw reply
* Re: [PATCH] net: secure_seq: Move net_secret_init() definition into CONFIG_IPV6 if block
From: Fabio Estevam @ 2013-10-06 16:29 UTC (permalink / raw)
To: Olof Johansson
Cc: David Miller, edumazet, hannes, Network Development,
Fabio Estevam
In-Reply-To: <CAOesGMi6LuP7uVJnHOgpG2RK2Q0R3bJ4kG1ZY3=b-W3k0YhnBg@mail.gmail.com>
Hi Olof,
On Sun, Oct 6, 2013 at 2:25 AM, Olof Johansson <olof@lixom.net> wrote:
> You get it if you have CONFIG_NET enabled, but CONFIG_INET off. We
> seem to have a few defconfigs on arm that has that setting, likely
> because they lack native network interfaces but need local unix
> sockets. Or whatever. But that's how you hit it.
>
> Steps to reproduce, even with ARCH=sparc:
>
> make allnoconfig
> edit .config, set CONFIG_NET=y
> yes "" | make oldconfig
> make
Yes, I fixed the commit log and patch in v2.
Regards,
Fabio Estevam
^ permalink raw reply
* Re: [PATCH v4 net-next] fix unsafe set_memory_rw from softirq
From: Eric Dumazet @ 2013-10-06 16:56 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Daniel Borkmann, Eric Dumazet, Heiko Carstens,
linux-arm-kernel, linuxppc-dev, linux-s390, netdev
In-Reply-To: <1380870846-3357-1-git-send-email-ast@plumgrid.com>
On Fri, 2013-10-04 at 00:14 -0700, Alexei Starovoitov wrote:
> on x86 system with net.core.bpf_jit_enable = 1
> cannot reuse jited filter memory, since it's readonly,
> so use original bpf insns memory to hold work_struct
>
> defer kfree of sk_filter until jit completed freeing
>
> tested on x86_64 and i386
>
> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net-next] net: Separate the close_list and the unreg_list
From: Francesco Ruggeri @ 2013-10-06 17:13 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev
>
> Can you verify this incremental change fixes it for you?
>
Sure, I will.
Thanks,
Francesco
^ permalink raw reply
* Re: [PATCH] usbnet: smsc95xx: Add device tree input for MAC address
From: Dan Murphy @ 2013-10-06 17:31 UTC (permalink / raw)
To: Ming Lei
Cc: Steve Glendinning, Network Development, Linux Kernel Mailing List,
linux-usb, mugunthanvnm-l0cyMroinI0
In-Reply-To: <CACVXFVOVMvP=3y9h2Jrqn2sBQdKOZtrhQDAFYkdHKXFgQj=d0Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 10/06/2013 10:05 AM, Ming Lei wrote:
> On Sat, Oct 5, 2013 at 2:25 AM, Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org> wrote:
>> If the smsc95xx does not have a valid MAC address stored within
>> the eeprom then a random number is generated. The MAC can also
>> be set by uBoot but the smsc95xx does not have a way to read this.
>>
>> Create the binding for the smsc95xx so that uBoot can set the MAC
>> and the code can retrieve the MAC from the modified DTB file.
> Suppose there are two smsc95xx usbnet devices connected to usb bus, and
> one is built-in, another is hotplug device, can your patch handle the situation
> correctly?
Look at this line in the patch below
sprintf(of_name, "%s%i", SMSC95XX_OF_NAME, dev->udev->dev.id);
I am appending the dev ID of the device to the of_name here. As long as init_mac_address is called, the dev.id and the uBoot
entry match then yes.
>> Signed-off-by: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/net/smsc95xx.txt | 17 ++++++++++++++
>> drivers/net/usb/smsc95xx.c | 24 ++++++++++++++++++++
>> 2 files changed, 41 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/smsc95xx.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/smsc95xx.txt b/Documentation/devicetree/bindings/net/smsc95xx.txt
>> new file mode 100644
>> index 0000000..4c37280
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/smsc95xx.txt
>> @@ -0,0 +1,17 @@
>> +* Smart Mixed-Signal Connectivity (SMSC) 95xx Controller
>> +
>> +Required properties:
>> +None
>> +
>> +Optional properties:
>> +- mac-address - Read the mac address that was stored by uBoot
>> +- local-address - Read the mac address that was stored by uBoot
>> +- address - Read the mac address that was stored by uBoot
>> +
>> +Examples:
>> +
>> +smsc0: smsc95xx@0 {
>> + /* Filled in by U-Boot */
>> + mac-address = [ 00 00 00 00 00 00 ];
>> +};
>> +
>> diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
>> index 3f38ba8..baee0bd 100644
>> --- a/drivers/net/usb/smsc95xx.c
>> +++ b/drivers/net/usb/smsc95xx.c
>> @@ -31,6 +31,9 @@
>> #include <linux/crc32.h>
>> #include <linux/usb/usbnet.h>
>> #include <linux/slab.h>
>> +#include <linux/of.h>
>> +#include <linux/of_net.h>
>> +
>> #include "smsc95xx.h"
>>
>> #define SMSC_CHIPNAME "smsc95xx"
>> @@ -62,6 +65,8 @@
>> #define SUSPEND_ALLMODES (SUSPEND_SUSPEND0 | SUSPEND_SUSPEND1 | \
>> SUSPEND_SUSPEND2 | SUSPEND_SUSPEND3)
>>
>> +#define SMSC95XX_OF_NAME "/smsc95xx@"
>> +
>> struct smsc95xx_priv {
>> u32 mac_cr;
>> u32 hash_hi;
>> @@ -767,6 +772,25 @@ static int smsc95xx_ioctl(struct net_device *netdev, struct ifreq *rq, int cmd)
>>
>> static void smsc95xx_init_mac_address(struct usbnet *dev)
>> {
>> +
>> +#ifdef CONFIG_OF
>> + struct device_node *ap;
>> + const char *mac = NULL;
>> + char *of_name = SMSC95XX_OF_NAME;
>> +
>> + sprintf(of_name, "%s%i", SMSC95XX_OF_NAME, dev->udev->dev.id);
>> + ap = of_find_node_by_path(of_name);
>> + if (ap) {
>> + mac = of_get_mac_address(ap);
>> + if (is_valid_ether_addr(mac)) {
>> + /* Device tree has a mac for this so use that */
>> + memcpy(dev->net->dev_addr, mac, ETH_ALEN);
>> + netif_dbg(dev, ifup, dev->net, "MAC address read from DTB\n");
>> + return;
>> + }
>> + }
>> +#endif
>> +
>> /* try reading mac address from EEPROM */
>> if (smsc95xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
>> dev->net->dev_addr) == 0) {
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
> Thanks,
--
------------------
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] tun: don't look at current when non-blocking
From: Michael S. Tsirkin @ 2013-10-06 18:25 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: David S. Miller, Jason Wang, Eric Dumazet, Pavel Emelyanov
We play with a wait queue even if socket is
non blocking. This is an obvious waste.
Besides, it will prevent calling the non blocking
variant when current is not valid.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
drivers/net/tun.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 807815f..7cb105c 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1293,7 +1293,8 @@ static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
if (unlikely(!noblock))
add_wait_queue(&tfile->wq.wait, &wait);
while (len) {
- current->state = TASK_INTERRUPTIBLE;
+ if (unlikely(!noblock))
+ current->state = TASK_INTERRUPTIBLE;
/* Read frames from the queue */
if (!(skb = skb_dequeue(&tfile->socket.sk->sk_receive_queue))) {
@@ -1320,9 +1321,10 @@ static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
break;
}
- current->state = TASK_RUNNING;
- if (unlikely(!noblock))
+ if (unlikely(!noblock)) {
+ current->state = TASK_RUNNING;
remove_wait_queue(&tfile->wq.wait, &wait);
+ }
return ret;
}
--
MST
^ permalink raw reply related
* [PATCH] static_key: WARN on usage before jump_label_init was called
From: Hannes Frederic Sowa @ 2013-10-06 18:29 UTC (permalink / raw)
To: Steven Rostedt, netdev, linux-kernel, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Jason Baron, Peter Zijlstra,
Eric Dumazet, andi @ firstfloor. org David S. Miller, x86
In-Reply-To: <20131006001247.GB25076@order.stressinduktion.org>
On Sun, Oct 06, 2013 at 02:12:47AM +0200, Hannes Frederic Sowa wrote:
> On Sat, Oct 05, 2013 at 08:05:58PM -0400, Steven Rostedt wrote:
> > > if (type == JUMP_LABEL_ENABLE) {
> > > - /*
> > > - * We are enabling this jump label. If it is not a nop
> > > - * then something must have gone wrong.
> > > - */
> > > - if (unlikely(memcmp((void *)entry->code, ideal_nop, 5) != 0))
> > > - bug_at((void *)entry->code, __LINE__);
> > > + if (init) {
> > > + /*
> > > + * Jump label is enabled for the first time.
> > > + * So we expect a default_nop...
> > > + */
> > > + if (unlikely(memcmp((void *)entry->code, default_nop, 5)
> > > + != 0))
> > > + bug_at((void *)entry->code, __LINE__);
> > > + } else {
> > > + /*
> > > + * ...otherwise expect an ideal_nop. Otherwise
> > > + * something went horribly wrong.
> > > + */
> > > + if (unlikely(memcmp((void *)entry->code, ideal_nop, 5)
> > > + != 0))
> > > + bug_at((void *)entry->code, __LINE__);
> > > + }
> >
> > I don't know if I like this change. This is similar to a bug we had
> > with the Xen folks, where they didn't realize that jump labels are not
> > suppose to be used (or set) before jump_label_init() is called.
> >
> > I'll have to take a deeper look at this on Monday.
>
> Yes, I understand and saw the commit to call jump_label_init
> earlier. Maybe the default could be to insert illegal instructions by
> default if we try to replace them with nops or branches afterwards anyway.
This would not help, but maybe someting like this patch. Andi Kleen
also recently posted something similar, I cleaned it up a bit.
[PATCH] static_key: WARN on usage before jump_label_init was called
Based on a patch from Andi Kleen.
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
include/linux/jump_label.h | 11 +++++++++++
include/linux/jump_label_ratelimit.h | 2 ++
kernel/jump_label.c | 5 +++++
lib/Makefile | 2 +-
lib/jump_label_initialized.c | 6 ++++++
5 files changed, 25 insertions(+), 1 deletion(-)
create mode 100644 lib/jump_label_initialized.c
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index a507907..ed3a4bd 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -48,6 +48,14 @@
#include <linux/types.h>
#include <linux/compiler.h>
+#include <linux/bug.h>
+
+extern bool static_key_initialized;
+
+#define STATIC_KEY_CHECK_USE() do { \
+ WARN(!static_key_initialized, "%s used before call to jump_label_init", \
+ __func__); \
+} while (0)
#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
@@ -128,6 +136,7 @@ struct static_key {
static __always_inline void jump_label_init(void)
{
+ static_key_initialized = true;
}
static __always_inline bool static_key_false(struct static_key *key)
@@ -146,11 +155,13 @@ static __always_inline bool static_key_true(struct static_key *key)
static inline void static_key_slow_inc(struct static_key *key)
{
+ STATIC_KEY_CHECK_USE();
atomic_inc(&key->enabled);
}
static inline void static_key_slow_dec(struct static_key *key)
{
+ STATIC_KEY_CHECK_USE();
atomic_dec(&key->enabled);
}
diff --git a/include/linux/jump_label_ratelimit.h b/include/linux/jump_label_ratelimit.h
index 1137883..089f70f 100644
--- a/include/linux/jump_label_ratelimit.h
+++ b/include/linux/jump_label_ratelimit.h
@@ -23,12 +23,14 @@ struct static_key_deferred {
};
static inline void static_key_slow_dec_deferred(struct static_key_deferred *key)
{
+ STATIC_KEY_CHECK_USE();
static_key_slow_dec(&key->key);
}
static inline void
jump_label_rate_limit(struct static_key_deferred *key,
unsigned long rl)
{
+ STATIC_KEY_CHECK_USE();
}
#endif /* HAVE_JUMP_LABEL */
#endif /* _LINUX_JUMP_LABEL_RATELIMIT_H */
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 297a924..9019f15 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -58,6 +58,7 @@ static void jump_label_update(struct static_key *key, int enable);
void static_key_slow_inc(struct static_key *key)
{
+ STATIC_KEY_CHECK_USE();
if (atomic_inc_not_zero(&key->enabled))
return;
@@ -103,12 +104,14 @@ static void jump_label_update_timeout(struct work_struct *work)
void static_key_slow_dec(struct static_key *key)
{
+ STATIC_KEY_CHECK_USE();
__static_key_slow_dec(key, 0, NULL);
}
EXPORT_SYMBOL_GPL(static_key_slow_dec);
void static_key_slow_dec_deferred(struct static_key_deferred *key)
{
+ STATIC_KEY_CHECK_USE();
__static_key_slow_dec(&key->key, key->timeout, &key->work);
}
EXPORT_SYMBOL_GPL(static_key_slow_dec_deferred);
@@ -116,6 +119,7 @@ EXPORT_SYMBOL_GPL(static_key_slow_dec_deferred);
void jump_label_rate_limit(struct static_key_deferred *key,
unsigned long rl)
{
+ STATIC_KEY_CHECK_USE();
key->timeout = rl;
INIT_DELAYED_WORK(&key->work, jump_label_update_timeout);
}
@@ -212,6 +216,7 @@ void __init jump_label_init(void)
key->next = NULL;
#endif
}
+ static_key_initialized = true;
jump_label_unlock();
}
diff --git a/lib/Makefile b/lib/Makefile
index f3bb2cb..7f48ddc 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -26,7 +26,7 @@ obj-y += bcd.o div64.o sort.o parser.o halfmd4.o debug_locks.o random32.o \
bust_spinlocks.o hexdump.o kasprintf.o bitmap.o scatterlist.o \
gcd.o lcm.o list_sort.o uuid.o flex_array.o iovec.o clz_ctz.o \
bsearch.o find_last_bit.o find_next_bit.o llist.o memweight.o kfifo.o \
- percpu_ida.o
+ percpu_ida.o jump_label_initialized.o
obj-y += string_helpers.o
obj-$(CONFIG_TEST_STRING_HELPERS) += test-string_helpers.o
obj-y += kstrtox.o
diff --git a/lib/jump_label_initialized.c b/lib/jump_label_initialized.c
new file mode 100644
index 0000000..a668a40
--- /dev/null
+++ b/lib/jump_label_initialized.c
@@ -0,0 +1,6 @@
+#include <linux/types.h>
+#include <linux/cache.h>
+
+bool static_key_initialized __read_mostly = false;
+EXPORT_SYMBOL_GPL(static_key_initialized);
+
--
1.8.3.1
^ permalink raw reply related
* CONTACT FEDEX EXPRESS COURIER SERVICE FOR YOUR PACKAGE
From: 019 @ 2013-10-06 18:52 UTC (permalink / raw)
To: Recipients
Dear Friend,
I cashed your shell oil company's compensation check of $1.5Million USD which has been with me for a very long time to avoid expiration,contact fedex Courier service with the below info for your fund consignment delivery,Note that security and insurance fees has been paid,all you will pay them is their delivery fees 150 USD only,
Director:Dr.Dennis Meijs,
E-mail ( fedexcourierserviii@yahoo.fr )
Tel: +9178-3835-5947
Please make sure you send this needed info to the Director Dr.Dennis Meijs
with the E-mail given to you to avoid wrong delivery of your consignment
Full Name.....................
Country...............
Home address.................
Home & Mobile phone numbers......
Your picture..........
Call Dr Dennis Meijs on phone Tel:+9178-3835-5947 as soon as you send email to him because your call would facilitate the immediate attention to you due to his tight delivery schedule.
I waiting for your urgent response
Remain blessed
Best Regards.
Barrister.Don Philip
^ permalink raw reply
* Re: [PATCH] Fix the upper MTU limit in ipv6 GRE tunnel
From: Oussama Ghorbel @ 2013-10-06 19:18 UTC (permalink / raw)
To: Oussama Ghorbel, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <20131006161910.GC9295@order.stressinduktion.org>
Yes, to summarize, the idea of this patch was to fix the incoherence
in the condition of ip6gre_tunnel_change_mtu function
if (new_mtu < 68 ||
new_mtu > 0xFFF8 - dev->hard_header_len - tunnel->hlen)
>From the ip6gre_tnl_link_config function we can see that:
The variable addend is equal the ipv6 header + gre header (including
the gre options)
On the other hand hard_header_len equal to the header of the lower
layer + addend.
So the quantity - (dev->hard_header_len + tunnel->hlen) equals - (eth
header + ipv6 header + gre header + ipv6 header + gre header) which by
no means this would represent anything! (I've just taken ipv6 over
ethernet as example)
As we have seen there is another approach to fix this issue is to
re-factor the hlen to hold only the length of gre as it's done for
ipv4 gre, however the solution provided in the patch seems to be
regression risk-less.
Although the value hold by hlen is not coherent with the variable name
nor with ipv4, I think there is an advantage of the current approach
of ipv6 hlen over ipv4 hlen, because we save the calculation of ipv6
header each time. Ex:
In ipv4 gre and in the function ipgre_header:
iph = (struct iphdr *)skb_push(skb, t->hlen + sizeof(*iph));
In ipv6 and in the function ip6gre_header
ipv6h = (struct ipv6hdr *)skb_push(skb, t->hlen);
Thanks,
Oussama
On Sun, Oct 6, 2013 at 5:19 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Sun, Oct 06, 2013 at 04:36:56PM +0100, Oussama Ghorbel wrote:
>> On Sun, Oct 6, 2013 at 4:13 PM, Hannes Frederic Sowa
>> <hannes@stressinduktion.org> wrote:
>> > On Sun, Oct 06, 2013 at 03:42:15PM +0100, Oussama Ghorbel wrote:
>> >> The initialization in ip6gre_tnl_link_config is done as the following:
>> >> static void ip6gre_tnl_link_config(struct ip6_tnl *t, int set_mtu)
>> >> {
>> >> ...
>> >> int addend = sizeof(struct ipv6hdr) + 4;
>> >> ...
>> >> /* Precalculate GRE options length */
>> >> if (t->parms.o_flags&(GRE_CSUM|GRE_KEY|GRE_SEQ)) {
>> >> if (t->parms.o_flags&GRE_CSUM)
>> >> addend += 4;
>> >> if (t->parms.o_flags&GRE_KEY)
>> >> addend += 4;
>> >> if (t->parms.o_flags&GRE_SEQ)
>> >> addend += 4;
>> >> }
>> >> ...
>> >> dev->hard_header_len = rt->dst.dev->hard_header_len + addend;
>> >> ...
>> >> t->hlen = addend;
>> >> ..
>> >> }
>> >>
>> >> Unless they are other reasons, the hard_header_len is taken into
>> >> account the GRE_KEY, GRE_SEQ ..
>> >
>> > But only if a new route is found. The hard_header_len reinitialization is
>> > guarded by a (rt == NULL). We may have not found one on boot up.
>> >
>> In that case the function will make a return and hlen will be zero.
>> Subtracting hlen in ip6gre_tunnel_change_mtu has no effect ...
>
> Oh yes, somehow I missed that.
>
> We depend on t->hlen when pushing the gre header onto the skb. t->hlen == 0
> should never be the case because we assume t->hlen > sizeof(struct ipv6_hdr).
>
^ permalink raw reply
* VERY URGENT..!
From: Mr. M. Barlow @ 2013-10-06 20:30 UTC (permalink / raw)
To: Recipients
Hello, I am Mr. M. Barlow from Paris, France. I have been advised to contact you regarding my business investment in your country. For urgent response and more details, kindly get back to me via this E-mail: bc82022@gmail.com or Telephone number below. Thank you as I wait for your response.
Mr. M. Barlow.
+33-753-194-496
Sent from Orange Wireless BlackBerry Smartphone, France.
^ permalink raw reply
* Re: [PATCH 0/4] connector fixes
From: Рустафа Джамурахметов @ 2013-10-06 20:46 UTC (permalink / raw)
To: David Miller, minipli@googlemail.com; +Cc: netdev@vger.kernel.org
In-Reply-To: <20131002.160430.1701387005902696709.davem@davemloft.net>
03.10.2013, 00:04, "David Miller" <davem@davemloft.net>:
> From: Mathias Krause <minipli@googlemail.com>
> Date: Mon, 30 Sep 2013 22:03:05 +0200
>
>> This series fixes a few netlink related issues of the connector interface.
>>
>> The first two patches are bug fixes. The last two are cleanups.
>>
>> Please apply!
>
> Series applied and first two patches queued up for -stable, thanks.
Thank you.
^ permalink raw reply
* [PATCH] net: af802154: Fix wrong structure declaration
From: Guenter Roeck @ 2013-10-06 21:44 UTC (permalink / raw)
To: Alexander Smirnov, Dmitry Eremin-Solenikov
Cc: David S. Miller, netdev, linux-zigbee-devel, Guenter Roeck
net_devce doesn't exist.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
net/ieee802154/af802154.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ieee802154/af802154.h b/net/ieee802154/af802154.h
index b1ec525..62f5f63 100644
--- a/net/ieee802154/af802154.h
+++ b/net/ieee802154/af802154.h
@@ -25,7 +25,7 @@
#define AF802154_H
struct sk_buff;
-struct net_devce;
+struct net_device;
extern struct proto ieee802154_raw_prot;
extern struct proto ieee802154_dgram_prot;
void ieee802154_raw_deliver(struct net_device *dev, struct sk_buff *skb);
--
1.7.9.7
^ permalink raw reply related
* Re: [PATCH] net: af802154: Fix wrong structure declaration
From: Joe Perches @ 2013-10-06 22:20 UTC (permalink / raw)
To: Guenter Roeck
Cc: Dmitry, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
David S. Miller
In-Reply-To: <1381095841-15031-1-git-send-email-linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
On Sun, 2013-10-06 at 14:44 -0700, Guenter Roeck wrote:
> net_devce doesn't exist.
[]
> diff --git a/net/ieee802154/af802154.h b/net/ieee802154/af802154.h
[]
> @@ -25,7 +25,7 @@
> #define AF802154_H
>
> struct sk_buff;
> -struct net_devce;
> +struct net_device;
That argues more for deletion than correction.
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
^ permalink raw reply
* Re: [PATCH] net: af802154: Fix wrong structure declaration
From: Guenter Roeck @ 2013-10-06 23:18 UTC (permalink / raw)
To: Joe Perches
Cc: Alexander Smirnov, Dmitry Eremin-Solenikov, David S. Miller,
netdev, linux-zigbee-devel
In-Reply-To: <1381098047.2081.169.camel@joe-AO722>
On 10/06/2013 03:20 PM, Joe Perches wrote:
> On Sun, 2013-10-06 at 14:44 -0700, Guenter Roeck wrote:
>> net_devce doesn't exist.
> []
>> diff --git a/net/ieee802154/af802154.h b/net/ieee802154/af802154.h
> []
>> @@ -25,7 +25,7 @@
>> #define AF802154_H
>>
>> struct sk_buff;
>> -struct net_devce;
>> +struct net_device;
>
> That argues more for deletion than correction.
>
I thought the idea was to ensure that every structure is declared.
In this case it appears that the structure happens to be declared
in other include files, so we are lucky. On the other side, if so,
"struct proto", "struct net" and "struct ieee802154_addr" should
probably be declared as well ...
Ultimately, I don't really care one way or another. I just happened
to stumble over it. Fine with me to remove it. Maybe the maintainers
should decide what if anything to do.
Guenter
^ permalink raw reply
* Re: [PATCH net-next] xen-netback: fix xenvif_count_skb_slots()
From: Matt Wilson @ 2013-10-07 0:06 UTC (permalink / raw)
To: Paul Durrant
Cc: xen-devel, netdev, Xi Xiong, Matt Wilson, Annie Li, Wei Liu,
Ian Campbell, Simon Graham
In-Reply-To: <1380903983-27429-1-git-send-email-paul.durrant@citrix.com>
On Fri, Oct 04, 2013 at 05:26:23PM +0100, Paul Durrant wrote:
> Commit 4f0581d25827d5e864bcf07b05d73d0d12a20a5c introduced an error into
> xenvif_count_skb_slots() for skbs with a linear area spanning a page
> boundary. The alignment of skb->data needs to be taken into account, not
> just the head length. This patch fixes the issue by dry-running the code
> from xenvif_gop_skb() (and adjusting the comment above the function to note
> that).
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Cc: Xi Xiong <xixiong@amazon.com>
> Cc: Matt Wilson <msw@amazon.com>
> Cc: Annie Li <annie.li@oracle.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
Paul, can you reconcile this change with the one made by Simon in cs
8f985b4f7a5394c8f8725a5109451a541ddb9eea?
--msw
> ---
> drivers/net/xen-netback/netback.c | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index d0b0feb..6f680f4 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -223,15 +223,28 @@ static bool start_new_rx_buffer(int offset, unsigned long size, int head)
> /*
> * Figure out how many ring slots we're going to need to send @skb to
> * the guest. This function is essentially a dry run of
> - * xenvif_gop_frag_copy.
> + * xenvif_gop_skb.
> */
> unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
> {
> + unsigned char *data;
> unsigned int count;
> int i, copy_off;
> struct skb_cb_overlay *sco;
>
> - count = DIV_ROUND_UP(skb_headlen(skb), PAGE_SIZE);
> + count = 0;
> +
> + data = skb->data;
> + while (data < skb_tail_pointer(skb)) {
> + unsigned int offset = offset_in_page(data);
> + unsigned int len = PAGE_SIZE - offset;
> +
> + if (data + len > skb_tail_pointer(skb))
> + len = skb_tail_pointer(skb) - data;
> +
> + count++;
> + data += len;
> + }
>
> copy_off = skb_headlen(skb) % PAGE_SIZE;
>
^ permalink raw reply
* Re: [PATCH net-next] xen-netback: fix xenvif_count_skb_slots()
From: Matt Wilson @ 2013-10-07 0:07 UTC (permalink / raw)
To: Paul Durrant
Cc: xen-devel, netdev, Xi Xiong, Matt Wilson, Annie Li, Wei Liu,
Ian Campbell, Simon Graham
In-Reply-To: <20131007000652.GA5970@u109add4315675089e695.ant.amazon.com>
On Sun, Oct 06, 2013 at 05:06:52PM -0700, Matt Wilson wrote:
> On Fri, Oct 04, 2013 at 05:26:23PM +0100, Paul Durrant wrote:
> > Commit 4f0581d25827d5e864bcf07b05d73d0d12a20a5c introduced an error into
> > xenvif_count_skb_slots() for skbs with a linear area spanning a page
> > boundary. The alignment of skb->data needs to be taken into account, not
> > just the head length. This patch fixes the issue by dry-running the code
> > from xenvif_gop_skb() (and adjusting the comment above the function to note
> > that).
> >
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > Cc: Xi Xiong <xixiong@amazon.com>
> > Cc: Matt Wilson <msw@amazon.com>
> > Cc: Annie Li <annie.li@oracle.com>
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > Cc: Ian Campbell <Ian.Campbell@citrix.com>
>
> Paul, can you reconcile this change with the one made by Simon in cs
> 8f985b4f7a5394c8f8725a5109451a541ddb9eea?
Correction: e26b203ede31fffd52571a5ba607a26c79dc5c0d
> --msw
>
> > ---
> > drivers/net/xen-netback/netback.c | 17 +++++++++++++++--
> > 1 file changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> > index d0b0feb..6f680f4 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -223,15 +223,28 @@ static bool start_new_rx_buffer(int offset, unsigned long size, int head)
> > /*
> > * Figure out how many ring slots we're going to need to send @skb to
> > * the guest. This function is essentially a dry run of
> > - * xenvif_gop_frag_copy.
> > + * xenvif_gop_skb.
> > */
> > unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
> > {
> > + unsigned char *data;
> > unsigned int count;
> > int i, copy_off;
> > struct skb_cb_overlay *sco;
> >
> > - count = DIV_ROUND_UP(skb_headlen(skb), PAGE_SIZE);
> > + count = 0;
> > +
> > + data = skb->data;
> > + while (data < skb_tail_pointer(skb)) {
> > + unsigned int offset = offset_in_page(data);
> > + unsigned int len = PAGE_SIZE - offset;
> > +
> > + if (data + len > skb_tail_pointer(skb))
> > + len = skb_tail_pointer(skb) - data;
> > +
> > + count++;
> > + data += len;
> > + }
> >
> > copy_off = skb_headlen(skb) % PAGE_SIZE;
> >
^ 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