* RE: [PATCH] ath6kl: sdio: fix system panic when doing wifi stress test
From: Hui Liu @ 2013-11-29 6:02 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-arm-kernel@lists.infradead.org, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, ath6kl-devel@qca.qualcomm.com
In-Reply-To: <87k3fvjvjg.fsf@kamboji.qca.qualcomm.com>
> -----Original Message-----
> From: Kalle Valo [mailto:kvalo@qca.qualcomm.com]
> Sent: Tuesday, November 26, 2013 6:40 PM
> To: Liu Hui-R64343
> Cc: linux-arm-kernel@lists.infradead.org; linville@tuxdriver.com; linux-
> wireless@vger.kernel.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; ath6kl-devel@qca.qualcomm.com
> Subject: Re: [PATCH] ath6kl: sdio: fix system panic when doing wifi
> stress test
>
> Hi Jason,
>
> Jason Liu <r64343@freescale.com> writes:
>
> > When did the wifi iperf test, meet one following kernel panic:
> > command: iperf -c $TARGET_IP -i 5 -t 50 -w 1M
> >
> > Unable to handle kernel paging request at virtual address 1a480000 pgd
> > = 80004000 [1a480000] *pgd=00000000 Internal error: Oops: 805 [#1] SMP
> > ARM
>
> [...]
>
> > The kernel panic is caused by the sg_buf is not set correctly with the
> > following code when compiled with Yocto GCC 4.8.1:
> >
> > drivers/net/wireless/ath/ath6kl/hif.h:
> > struct hif_scatter_req {
> > struct list_head list;
> > /* address for the read/write operation */
> > u32 addr;
> > ...
> >
> > /* bounce buffer for upper layers to copy to/from */
> > u8 *virt_dma_buf;
> >
> > struct hif_scatter_item scat_list[1];
> >
> > u32 scat_q_depth;
> > };
> >
> > (Note: the scat_req.scat_list[] will dynamiclly grow with run-time)
>
> There's actually a major bug right there, scat_list can corrupt
> scat_q_depth.
>
> > The GCC 4.8.1 compiler will not do the for-loop till scat_entries,
> > instead, it only run one round loop. This may be caused by that the
> > GCC 4.8.1 thought that the scat_list only have one item and then no
> > need to do full iteration, but this is simply wrong by looking at the
> > assebly code. This will cause the sg buffer not get set when
> scat_entries > 1 and thus lead to kernel panic.
> >
> > This patch is a workaround to the GCC 4.8.1 complier issue by passing
> > the entry address of the scat_req->scat_list to the for-loop and
> > interate it, then, GCC 4.8.1 will do the full for-loop correctly.
> > (Note: This issue not observed with GCC 4.7.2, only found on the GCC
> > 4.8.1)
> >
> > This patch does not change any function logic and no any performance
> downgrade.
>
> [...]
>
> > + scat_list = &scat_req->scat_list[0];
> > +
> > /* assemble SG list */
> > - for (i = 0; i < scat_req->scat_entries; i++, sg++) {
> > + for (i = 0; i < scat_req->scat_entries; i++, sg++, scat_list++) {
> > ath6kl_dbg(ATH6KL_DBG_SCATTER, "%d: addr:0x%p, len:%d\n",
> > - i, scat_req->scat_list[i].buf,
> > - scat_req->scat_list[i].len);
> > + i, scat_list->buf, scat_list->len);
> >
> > - sg_set_buf(sg, scat_req->scat_list[i].buf,
> > - scat_req->scat_list[i].len);
> > + sg_set_buf(sg, scat_list->buf, scat_list->len);
> > }
>
> Working around the problem by adding a temporary variable makes me a bit
> worried, I would rather fix the root cause. Is the root cause by that we
> define the field with scat_list[1]?
Yes, this is what I assumed.
>
> Does the patch below help? It would also fix the corruption with
> scat_q_depth. Please note that I have only compile tested it. And I might
> have also missed something important, so please review it carefully.
Yes, Firstly, I have looked at the asm code and the compiler(gcc 4.8.1) works correctly after applying
the following patch. Secondly, I have tested the patch with compiler(gcc 4.8.1) on the real HW, and it
works fine too. Without the patch, the kernel crash will happen 100%.
Thus, for the patch:
Acked-by: Jason Liu <r64343@freescale.com>
Tested-by: Jason Liu <r64343@freescale.com>
Jason Liu
>
> --- a/drivers/net/wireless/ath/ath6kl/hif.h
> +++ b/drivers/net/wireless/ath/ath6kl/hif.h
> @@ -197,9 +197,9 @@ struct hif_scatter_req {
> /* bounce buffer for upper layers to copy to/from */
> u8 *virt_dma_buf;
>
> - struct hif_scatter_item scat_list[1];
> -
> u32 scat_q_depth;
> +
> + struct hif_scatter_item scat_list[0];
> };
>
> struct ath6kl_irq_proc_registers {
> diff --git a/drivers/net/wireless/ath/ath6kl/sdio.c
> b/drivers/net/wireless/ath/ath6kl/sdio.c
> index 7126bdd..6bf15a3 100644
> --- a/drivers/net/wireless/ath/ath6kl/sdio.c
> +++ b/drivers/net/wireless/ath/ath6kl/sdio.c
> @@ -348,7 +348,7 @@ static int ath6kl_sdio_alloc_prep_scat_req(struct
> ath6kl_sdio *ar_sdio,
> int i, scat_req_sz, scat_list_sz, size;
> u8 *virt_buf;
>
> - scat_list_sz = (n_scat_entry - 1) * sizeof(struct hif_scatter_item);
> + scat_list_sz = n_scat_entry * sizeof(struct hif_scatter_item);
> scat_req_sz = sizeof(*s_req) + scat_list_sz;
>
> if (!virt_scat)
>
>
> --
> Kalle Valo
^ permalink raw reply
* Re: [PATCH] ipv6: judge the accept_ra_defrtr before calling rt6_route_rcv
From: Hannes Frederic Sowa @ 2013-11-29 6:09 UTC (permalink / raw)
To: Duan Jiong; +Cc: David Miller, netdev
In-Reply-To: <529451F0.1060707@cn.fujitsu.com>
On Tue, Nov 26, 2013 at 03:46:56PM +0800, Duan Jiong wrote:
>
> when dealing with a RA message, if accept_ra_defrtr is false,
> the kernel will not add the default route, and then deal with
> the following route information options. Unfortunately, those
> options maybe contain default route, so let's judge the
> accept_ra_defrtr before calling rt6_route_rcv.
>
> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
I am ambivalent regarding this change.
accept_ra_defrtr protected against adding default routers without routing
options and accept_ra_rt_info_max_plen == -1 disables the acceptance of any
routing options in router advertisments.
I don't have an idea why we need this distinction altough I once used it for
testing. But because this change makes it more understandable for users I am
ok with that.
Greetings,
Hannes
^ permalink raw reply
* [PATCH 1/6][v3] phylib: Add Clause 45 read/write functions
From: shh.xie @ 2013-11-29 5:45 UTC (permalink / raw)
To: davem, jg1.han, mugunthanvnm, f.fainelli, netdev, linux-kernel
Cc: Shaohui.Xie
From: Andy Fleming <afleming@freescale.com>
Need an extra parameter to read or write Clause 45 PHYs, so
need a different API with the extra parameter.
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
---
v3 changes: add C45 check.
include/linux/phy.h | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 48a4dc3..0ff2476 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -498,6 +498,24 @@ static inline int phy_read(struct phy_device *phydev, u32 regnum)
}
/**
+ * phy_read_mmd - Convenience function for reading a register
+ * from an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to read from
+ * @regnum: The register on the MMD to read
+ *
+ * Same rules as for phy_read();
+ */
+static inline int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum)
+{
+ if (!phydev->is_c45)
+ return -EOPNOTSUPP;
+
+ return mdiobus_read(phydev->bus, phydev->addr,
+ MII_ADDR_C45 | (devad << 16) | (regnum & 0xffff));
+}
+
+/**
* phy_write - Convenience function for writing a given PHY register
* @phydev: the phy_device struct
* @regnum: register number to write
@@ -533,6 +551,27 @@ static inline bool phy_is_internal(struct phy_device *phydev)
return phydev->is_internal;
}
+/**
+ * phy_write_mmd - Convenience function for writing a register
+ * on an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to read from
+ * @regnum: The register on the MMD to read
+ * @val: value to write to @regnum
+ *
+ * Same rules as for phy_write();
+ */
+static inline int phy_write_mmd(struct phy_device *phydev, int devad,
+ u32 regnum, u16 val)
+{
+ if (!phydev->is_c45)
+ return -EOPNOTSUPP;
+
+ regnum = MII_ADDR_C45 | ((devad & 0x1f) << 16) | (regnum & 0xffff);
+
+ return mdiobus_write(phydev->bus, phydev->addr, regnum, val);
+}
+
struct phy_device *phy_device_create(struct mii_bus *bus, int addr, int phy_id,
bool is_c45, struct phy_c45_device_ids *c45_ids);
struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45);
--
1.8.4.1
^ permalink raw reply related
* [PATCH 6/6][v3] phylib: Add of_phy_attach
From: shh.xie @ 2013-11-29 5:48 UTC (permalink / raw)
To: davem, jg1.han, mugunthanvnm, f.fainelli, netdev, linux-kernel
Cc: Shaohui.Xie
From: Andy Fleming <afleming@freescale.com>
10G PHYs don't currently support running the state machine, which
is implicitly setup via of_phy_connect(). Therefore, it is necessary
to implement an OF version of phy_attach(), which does everything
except start the state machine.
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
v3: no changes.
drivers/of/of_mdio.c | 19 +++++++++++++++++++
include/linux/of_mdio.h | 9 +++++++++
2 files changed, 28 insertions(+)
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index d5a57a9..21076ac 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -247,3 +247,22 @@ struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
return IS_ERR(phy) ? NULL : phy;
}
EXPORT_SYMBOL(of_phy_connect_fixed_link);
+
+/**
+ * of_phy_attach - Attach to a PHY without starting the state machine
+ * @dev: pointer to net_device claiming the phy
+ * @phy_np: Node pointer for the PHY
+ * @flags: flags to pass to the PHY
+ * @iface: PHY data interface type
+ */
+struct phy_device *of_phy_attach(struct net_device *dev,
+ struct device_node *phy_np, u32 flags, phy_interface_t iface)
+{
+ struct phy_device *phy = of_phy_find_device(phy_np);
+
+ if (!phy)
+ return NULL;
+
+ return phy_attach_direct(dev, phy, flags, iface) ? NULL : phy;
+}
+EXPORT_SYMBOL(of_phy_attach);
diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
index 8163107..108583a 100644
--- a/include/linux/of_mdio.h
+++ b/include/linux/of_mdio.h
@@ -19,6 +19,9 @@ extern struct phy_device *of_phy_connect(struct net_device *dev,
struct device_node *phy_np,
void (*hndlr)(struct net_device *),
u32 flags, phy_interface_t iface);
+struct phy_device *of_phy_attach(struct net_device *dev,
+ struct device_node *phy_np, u32 flags,
+ phy_interface_t iface);
extern struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
void (*hndlr)(struct net_device *),
phy_interface_t iface);
@@ -44,6 +47,12 @@ static inline struct phy_device *of_phy_connect(struct net_device *dev,
return NULL;
}
+static inline struct phy_device *of_phy_attach(struct net_device *dev,
+ struct device_node *phy_np, u32 flags, phy_interface_t iface)
+{
+ return NULL;
+}
+
static inline struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
void (*hndlr)(struct net_device *),
phy_interface_t iface)
--
1.8.4.1
^ permalink raw reply related
* Re: [PATCH net] diag: fix netlink API attributes
From: Nicolas Dichtel @ 2013-11-29 8:28 UTC (permalink / raw)
To: Thomas Graf; +Cc: davem, netdev, Samuel.gauthier@6wind.com
In-Reply-To: <20131128221916.GB4100@casper.infradead.org>
Le 28/11/2013 23:19, Thomas Graf a écrit :
> On 11/28/13 at 06:37pm, Nicolas Dichtel wrote:
>> Le 28/11/2013 17:38, Thomas Graf a écrit :
>>> On 11/28/13 at 02:57pm, Nicolas Dichtel wrote:
>>>> The first netlink attribute (value 0) must always be defined as none/unspec.
>>>> This is correctly done in inet_diag.h, but other diag interfaces are broken.
>>>>
>>>> Libraries like libnl skip this kind of attributes, thus it's never reported to
>>>> the application.
>>>>
>>>> CC: Thomas Graf <tgraf@suug.ch>
>>>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>>>
>>> First of all, thanks for the notification Nicolas. I'll fix libnl to
>>> pass through these attributes.
>> Fine :)
>> Thank you!
>
> Fixed in:
>
> commit 6a8d90f5fec48b6e376ff29ccf3e0c620a41e758
> Author: Thomas Graf <tgraf@suug.ch>
> Date: Thu Nov 28 23:14:38 2013 +0100
>
> attr: Allow attribute type 0
>
> {netlink,packet,unix}_diag use attribute type 0 for valid
> attributes. The value was reserved and usage was prohibited
> by the protocol but we can't undo the breakge.
>
> Make libnl accept attribute type 0 to allow parsing these
> attributes.
>
> Reported-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
I think the following patch is also needed (not based on HEAD):
From 8aa4397d43fbd34deea9ed11677c04b460895f15 Mon Sep 17 00:00:00 2001
From: Samuel Gauthier <samuel.gauthier@6wind.com>
Date: Fri, 29 Nov 2013 09:15:34 +0100
Subject: [PATCH] attr: Allow attribute type 0 parsing
The commit 6a8d90f5fec4 "attr: Allow attribute type 0" intended to
allow the parsing of {netlink,packet,unix}_diag, even if they are
using type 0 for valid attributes.
It lacked this part in nla_parse.
Signed-off-by: Samuel Gauthier <samuel.gauthier@6wind.com>
---
lib/attr.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/lib/attr.c b/lib/attr.c
index 535f10c..1e2d57f 100644
--- a/lib/attr.c
+++ b/lib/attr.c
@@ -250,10 +250,6 @@ int nla_parse(struct nlattr *tb[], int maxtype, struct
nlattr *head, int len,
nla_for_each_attr(nla, head, len, rem) {
int type = nla_type(nla);
- /* Padding attributes */
- if (type == 0)
- continue;
-
if (type > maxtype)
continue;
--
1.8.0
^ permalink raw reply related
* DMA-API warning from sunhme - unchecked dma_map_single error
From: Meelis Roos @ 2013-11-29 8:40 UTC (permalink / raw)
To: netdev, sparclinux
I turned on DMA API debugging among other debug options to help catch an
error. So far I have only found probably unrelated things. One of them
is this splat:
WARNING: CPU: 6 PID: 1948 at lib/dma-debug.c:937 check_unmap+0x784/0x840()
hme 0000:00:01.1: DMA-API: device driver failed to check map error[device address=0x00000000c006e002] [size=342 bytes] [mapped as single]
Modules linked in:
CPU: 6 PID: 1948 Comm: dhclient Tainted: G W 3.13.0-rc1 #16
Call Trace:
[00000000004585cc] warn_slowpath_common+0x4c/0x80
[00000000004586ac] warn_slowpath_fmt+0x2c/0x40
[00000000006407e4] check_unmap+0x784/0x840
[0000000000640944] debug_dma_unmap_page+0x44/0x60
[000000000073f8c8] happy_meal_tx+0x128/0x260
[000000000073fed8] happy_meal_interrupt+0x78/0xc0
[00000000004a4b84] handle_irq_event_percpu+0x44/0x1a0
[00000000004a4d18] handle_irq_event+0x38/0x80
[00000000004a7dcc] handle_fasteoi_irq+0x10c/0x1c0
[00000000004a4300] generic_handle_irq+0x40/0x60
[000000000042bb38] handler_irq+0xb8/0xe0
[0000000000426b2c] valid_addr_bitmap_patch+0x74/0x248
[000000000049bf88] lock_acquire+0x68/0x80
[0000000000494be4] down_read_trylock+0x44/0x60
[000000000044bf54] do_sparc64_fault+0x1d4/0x700
[0000000000407964] sparc64_realfault_common+0x10/0x20
---[ end trace 9a1420108ebfd592 ]---
Mapped at:
[<0000000000740314>] happy_meal_start_xmit+0x1d4/0x4c0
[<000000000077a8f0>] dev_hard_start_xmit+0x370/0x500
[<0000000000795f8c>] sch_direct_xmit+0x4c/0x2a0
[<000000000077ae18>] dev_queue_xmit+0x398/0x7c0
[<00000000008015a8>] packet_sendmsg_spkt+0x388/0x4c0
It seems to be correct warning - dma_map_single is used unchecked in
sunhme.c. I can try fixing it - the error handling will be the only
problem. Is it considered worthwile?
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: [PATCH net] diag: fix netlink API attributes
From: Thomas Graf @ 2013-11-29 8:42 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: davem, netdev, Samuel.gauthier@6wind.com
In-Reply-To: <5298503C.6080100@6wind.com>
On 11/29/13 at 09:28am, Nicolas Dichtel wrote:
> I think the following patch is also needed (not based on HEAD):
>
> From 8aa4397d43fbd34deea9ed11677c04b460895f15 Mon Sep 17 00:00:00 2001
> From: Samuel Gauthier <samuel.gauthier@6wind.com>
> Date: Fri, 29 Nov 2013 09:15:34 +0100
> Subject: [PATCH] attr: Allow attribute type 0 parsing
>
> The commit 6a8d90f5fec4 "attr: Allow attribute type 0" intended to
> allow the parsing of {netlink,packet,unix}_diag, even if they are
> using type 0 for valid attributes.
>
> It lacked this part in nla_parse.
>
> Signed-off-by: Samuel Gauthier <samuel.gauthier@6wind.com>
Good catch, applied, thanks!
^ permalink raw reply
* Re: [PATCH] update consumers of MSG_MORE to recognize MSG_SENDPAGE_NOTLAST
From: Richard Weinberger @ 2013-11-29 8:50 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Shawn Landden, Eric Dumazet, linux-kernel, linux-fsdevel, viro,
linux-crypto, netdev, Herbert Xu, Tom Herbert, David S. Miller,
stable
In-Reply-To: <20131129054704.GI24171@order.stressinduktion.org>
Shawn,
Am Freitag, 29. November 2013, 06:47:04 schrieb Hannes Frederic Sowa:
> On Sun, Nov 24, 2013 at 10:36:28PM -0800, Shawn Landden wrote:
> > Commit 35f9c09fe (tcp: tcp_sendpages() should call tcp_push() once)
> > added an internal flag MSG_SENDPAGE_NOTLAST, similar to
> > MSG_MORE.
> >
> > algif_hash, algif_skcipher, and udp used MSG_MORE from tcp_sendpages()
> > and need to see the new flag as identical to MSG_MORE.
> >
> > This fixes sendfile() on AF_ALG.
> >
> > v3: also fix udp
>
> The UDP bits look fine to me.
please don't forget to resend the patch (only the UDP fix).
I sent the AF_ALG part already.
Thanks,
//richard
^ permalink raw reply
* TSN#:3579220329 E-mail ID Won! Congratulations
From: FreeLotto Services @ 2013-11-29 8:52 UTC (permalink / raw)
Congratulations - TSN#:3579220329
Your e-Mail has won $1,500,000.00 USD in our ongoing FREELOTTO online
International program. To begin your claims therefore, Email us your FULL NAME,
ADDRESS/COUNTRY & MOBILE No to our e-mail below: FreeLotto® Services (Government
Accredited Licensed Office) E-mal: fls.licenseduk@gmail.com
Office Tel on: 07011127802 (intl. +447011127802)
Sincerely Yours,
Vera Kepla Mrs.,
(Coordinator/Online Publicity).
SEND YOUR RESPONSE TO fls.licenseduk@gmail.com TO CLAIM YOUR PRIZE.
^ permalink raw reply
* [PATCH v2 net] af_packet: block BH in prb_shutdown_retire_blk_timer()
From: Veaceslav Falico @ 2013-11-29 8:53 UTC (permalink / raw)
To: netdev
Cc: jstancek, Veaceslav Falico, David S. Miller, Daniel Borkmann,
Willem de Bruijn, Phil Sutter, Eric Dumazet
Currently we're using plain spin_lock() in prb_shutdown_retire_blk_timer(),
however the timer might fire right in the middle and thus try to re-aquire
the same spinlock, leaving us in a endless loop.
To fix that, use the spin_lock_bh() to block it.
CC: "David S. Miller" <davem@davemloft.net>
CC: Daniel Borkmann <dborkman@redhat.com>
CC: Willem de Bruijn <willemb@google.com>
CC: Phil Sutter <phil@nwl.cc>
CC: Eric Dumazet <edumazet@google.com>
Reported-by: Jan Stancek <jstancek@redhat.com>
Tested-by: Jan Stancek <jstancek@redhat.com>
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
---
Notes:
v1 -> v2:
Per Eric's suggestion, reward the commit message to actually match the
patch (thanks a lot!).
net/packet/af_packet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index ac27c86..ba2548b 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -439,9 +439,9 @@ static void prb_shutdown_retire_blk_timer(struct packet_sock *po,
pkc = tx_ring ? &po->tx_ring.prb_bdqc : &po->rx_ring.prb_bdqc;
- spin_lock(&rb_queue->lock);
+ spin_lock_bh(&rb_queue->lock);
pkc->delete_blk_timer = 1;
- spin_unlock(&rb_queue->lock);
+ spin_unlock_bh(&rb_queue->lock);
prb_del_retire_blk_timer(pkc);
}
--
1.8.4
^ permalink raw reply related
* [PATCH] virtio_net: Fixed a trivial typo (fitler --> filter)
From: Thomas Huth @ 2013-11-29 9:02 UTC (permalink / raw)
To: virtualization; +Cc: netdev, rusty, mst, trivial, Thomas Huth
"MAC filter" sounds more reasonable than "MAC fitler".
Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
---
drivers/net/virtio_net.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 01f4eb5..fd96f09 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1075,7 +1075,7 @@ static void virtnet_set_rx_mode(struct net_device *dev)
if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_MAC,
VIRTIO_NET_CTRL_MAC_TABLE_SET,
sg, NULL))
- dev_warn(&dev->dev, "Failed to set MAC fitler table.\n");
+ dev_warn(&dev->dev, "Failed to set MAC filter table.\n");
kfree(buf);
}
--
1.7.1
^ permalink raw reply related
* RE: [PATCH net v2] xen-netback: fix fragment detection in checksum setup
From: Paul Durrant @ 2013-11-29 9:10 UTC (permalink / raw)
To: annie li
Cc: xen-devel@lists.xen.org, netdev@vger.kernel.org, Wei Liu,
Ian Campbell, David Vrabel
In-Reply-To: <529827BC.8050207@oracle.com>
> -----Original Message-----
> From: annie li [mailto:annie.li@oracle.com]
> Sent: 29 November 2013 05:36
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org; netdev@vger.kernel.org; Wei Liu; Ian Campbell;
> David Vrabel
> Subject: Re: [PATCH net v2] xen-netback: fix fragment detection in checksum
> setup
>
>
> On 2013/11/28 21:23, Paul Durrant wrote:
> > The code to detect fragments in checksum_setup() was missing for IPv4
> and
> > too eager for IPv6. (It transpires that Windows seems to send IPv6 packets
> > with a fragment header even if they are not a fragment - i.e. offset is zero,
> > and M bit is not set).
> >
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > Cc: David Vrabel <david.vrabel@citrix.com>
> > ---
> > v2
> >
> > - Added comments noting what fragment/offset masks mean
> >
> > drivers/net/xen-netback/netback.c | 33
> ++++++++++++++++++++++++++++++---
> > 1 file changed, 30 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-
> netback/netback.c
> > index 919b650..c7464d8 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -1165,15 +1165,28 @@ static int checksum_setup_ip(struct xenvif *vif,
> struct sk_buff *skb,
> > struct iphdr *iph = (void *)skb->data;
> > unsigned int header_size;
> > unsigned int off;
> > + bool fragment;
> > int err = -EPROTO;
> >
> > + fragment = false;
>
> Is it better to initialize fragment directly as following?
> bool fragment = false;
>
I think that's a matter of personal taste. I tend to favour this style.
Paul
> > +
> > off = sizeof(struct iphdr);
> >
> > header_size = skb->network_header + off + MAX_IPOPTLEN;
> > maybe_pull_tail(skb, header_size);
> >
> > + /* 3fff -> fragment offset != 0 OR more fragments */
> > + if (ntohs(iph->frag_off) & 0x3fff)
> > + fragment = true;
> > +
> > off = iph->ihl * 4;
> >
> > + if (fragment) {
> > + if (net_ratelimit())
> > + netdev_err(vif->dev, "Packet is a fragment!\n");
> > + goto out;
> > + }
> > +
> > switch (iph->protocol) {
> > case IPPROTO_TCP:
> > if (!skb_partial_csum_set(skb, off,
> > @@ -1237,6 +1250,7 @@ static int checksum_setup_ipv6(struct xenvif *vif,
> struct sk_buff *skb,
> > bool fragment;
> > bool done;
> >
> > + fragment = false;
> > done = false;
>
> Same as above for "done" and "fragment"...
>
> Thanks
> Annie
^ permalink raw reply
* Re: [PATCH v2 net] af_packet: block BH in prb_shutdown_retire_blk_timer()
From: Daniel Borkmann @ 2013-11-29 9:19 UTC (permalink / raw)
To: Veaceslav Falico
Cc: netdev, jstancek, David S. Miller, Willem de Bruijn, Phil Sutter,
Eric Dumazet
In-Reply-To: <1385715203-14712-1-git-send-email-vfalico@redhat.com>
On 11/29/2013 09:53 AM, Veaceslav Falico wrote:
> Currently we're using plain spin_lock() in prb_shutdown_retire_blk_timer(),
> however the timer might fire right in the middle and thus try to re-aquire
> the same spinlock, leaving us in a endless loop.
>
> To fix that, use the spin_lock_bh() to block it.
>
> CC: "David S. Miller" <davem@davemloft.net>
> CC: Daniel Borkmann <dborkman@redhat.com>
> CC: Willem de Bruijn <willemb@google.com>
> CC: Phil Sutter <phil@nwl.cc>
> CC: Eric Dumazet <edumazet@google.com>
> Reported-by: Jan Stancek <jstancek@redhat.com>
> Tested-by: Jan Stancek <jstancek@redhat.com>
> Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.")
Acked-by: Daniel Borkmann <dborkman@redhat.com>
Thanks everyone!
^ permalink raw reply
* Re: [Xen-devel] [PATCH net v2] xen-netback: fix fragment detection in checksum setup
From: annie li @ 2013-11-29 9:57 UTC (permalink / raw)
To: Paul Durrant
Cc: netdev@vger.kernel.org, David Vrabel, Wei Liu, Ian Campbell,
xen-devel@lists.xen.org
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD0195CB0@AMSPEX01CL01.citrite.net>
On 2013/11/29 17:10, Paul Durrant wrote:
>> -----Original Message-----
>> From: annie li [mailto:annie.li@oracle.com]
>> Sent: 29 November 2013 05:36
>> To: Paul Durrant
>> Cc: xen-devel@lists.xen.org; netdev@vger.kernel.org; Wei Liu; Ian Campbell;
>> David Vrabel
>> Subject: Re: [PATCH net v2] xen-netback: fix fragment detection in checksum
>> setup
>>
>>
>> On 2013/11/28 21:23, Paul Durrant wrote:
>>> The code to detect fragments in checksum_setup() was missing for IPv4
>> and
>>> too eager for IPv6. (It transpires that Windows seems to send IPv6 packets
>>> with a fragment header even if they are not a fragment - i.e. offset is zero,
>>> and M bit is not set).
>>>
>>> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>> Cc: Ian Campbell <ian.campbell@citrix.com>
>>> Cc: David Vrabel <david.vrabel@citrix.com>
>>> ---
>>> v2
>>>
>>> - Added comments noting what fragment/offset masks mean
>>>
>>> drivers/net/xen-netback/netback.c | 33
>> ++++++++++++++++++++++++++++++---
>>> 1 file changed, 30 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-
>> netback/netback.c
>>> index 919b650..c7464d8 100644
>>> --- a/drivers/net/xen-netback/netback.c
>>> +++ b/drivers/net/xen-netback/netback.c
>>> @@ -1165,15 +1165,28 @@ static int checksum_setup_ip(struct xenvif *vif,
>> struct sk_buff *skb,
>>> struct iphdr *iph = (void *)skb->data;
>>> unsigned int header_size;
>>> unsigned int off;
>>> + bool fragment;
>>> int err = -EPROTO;
>>>
>>> + fragment = false;
>> Is it better to initialize fragment directly as following?
>> bool fragment = false;
>>
> I think that's a matter of personal taste. I tend to favour this style.
>
That is OK, I point this out because it is inconsistent with other
variable initialization in netback.c.
Thanks
Annie
>
>>> +
>>> off = sizeof(struct iphdr);
>>>
>>> header_size = skb->network_header + off + MAX_IPOPTLEN;
>>> maybe_pull_tail(skb, header_size);
>>>
>>> + /* 3fff -> fragment offset != 0 OR more fragments */
>>> + if (ntohs(iph->frag_off) & 0x3fff)
>>> + fragment = true;
>>> +
>>> off = iph->ihl * 4;
>>>
>>> + if (fragment) {
>>> + if (net_ratelimit())
>>> + netdev_err(vif->dev, "Packet is a fragment!\n");
>>> + goto out;
>>> + }
>>> +
>>> switch (iph->protocol) {
>>> case IPPROTO_TCP:
>>> if (!skb_partial_csum_set(skb, off,
>>> @@ -1237,6 +1250,7 @@ static int checksum_setup_ipv6(struct xenvif *vif,
>> struct sk_buff *skb,
>>> bool fragment;
>>> bool done;
>>>
>>> + fragment = false;
>>> done = false;
>> Same as above for "done" and "fragment"...
>>
>> Thanks
>> Annie
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v2 1/2] virtio_net: fix error handling for mergeable buffers
From: Jason Wang @ 2013-11-29 10:13 UTC (permalink / raw)
To: Michael S. Tsirkin, linux-kernel
Cc: netdev, Eric Dumazet, Michael Dalton, virtualization
In-Reply-To: <1385638044-27467-1-git-send-email-mst@redhat.com>
On 11/28/2013 07:30 PM, Michael S. Tsirkin wrote:
> Eric Dumazet noticed that if we encounter an error
> when processing a mergeable buffer, we don't
> dequeue all of the buffers from this packet,
> the result is almost sure to be loss of networking.
>
> Jason Wang noticed that we also leak a page and that we don't decrement
> the rq buf count, so we won't repost buffers (a resource leak).
>
> Fix both issues.
>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Michael Dalton <mwdalton@google.com>
> Reported-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Jason Wang <jasowang@redhat.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>
> Stable patch will be sent later.
>
> drivers/net/virtio_net.c | 82 ++++++++++++++++++++++++++++++------------------
> 1 file changed, 51 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 7bab4de..5408de6 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -299,35 +299,47 @@ static struct sk_buff *page_to_skb(struct receive_queue *rq,
> return skb;
> }
>
> -static int receive_mergeable(struct receive_queue *rq, struct sk_buff *head_skb)
> +static struct sk_buff *receive_mergeable(struct net_device *dev,
> + struct receive_queue *rq,
> + void *buf,
> + unsigned int len)
> {
> - struct skb_vnet_hdr *hdr = skb_vnet_hdr(head_skb);
> + struct skb_vnet_hdr *hdr = buf;
> + int num_buf = hdr->mhdr.num_buffers;
> + struct page *page = virt_to_head_page(buf);
> + int offset = buf - page_address(page);
> + struct sk_buff *head_skb = page_to_skb(rq, page, offset, len,
> + MERGE_BUFFER_LEN);
> struct sk_buff *curr_skb = head_skb;
> - char *buf;
> - struct page *page;
> - int num_buf, len, offset;
>
> - num_buf = hdr->mhdr.num_buffers;
> + if (unlikely(!curr_skb))
> + goto err_skb;
> +
> while (--num_buf) {
> - int num_skb_frags = skb_shinfo(curr_skb)->nr_frags;
> + int num_skb_frags;
> +
> buf = virtqueue_get_buf(rq->vq, &len);
> if (unlikely(!buf)) {
> - pr_debug("%s: rx error: %d buffers missing\n",
> - head_skb->dev->name, hdr->mhdr.num_buffers);
> - head_skb->dev->stats.rx_length_errors++;
> - return -EINVAL;
> + pr_debug("%s: rx error: %d buffers out of %d missing\n",
> + dev->name, num_buf, hdr->mhdr.num_buffers);
> + dev->stats.rx_length_errors++;
> + goto err_buf;
> }
> if (unlikely(len > MERGE_BUFFER_LEN)) {
> pr_debug("%s: rx error: merge buffer too long\n",
> - head_skb->dev->name);
> + dev->name);
> len = MERGE_BUFFER_LEN;
> }
> +
> + page = virt_to_head_page(buf);
> + --rq->num;
> +
> + num_skb_frags = skb_shinfo(curr_skb)->nr_frags;
> if (unlikely(num_skb_frags == MAX_SKB_FRAGS)) {
> struct sk_buff *nskb = alloc_skb(0, GFP_ATOMIC);
> - if (unlikely(!nskb)) {
> - head_skb->dev->stats.rx_dropped++;
> - return -ENOMEM;
> - }
> +
> + if (unlikely(!nskb))
> + goto err_skb;
> if (curr_skb == head_skb)
> skb_shinfo(curr_skb)->frag_list = nskb;
> else
> @@ -341,8 +353,7 @@ static int receive_mergeable(struct receive_queue *rq, struct sk_buff *head_skb)
> head_skb->len += len;
> head_skb->truesize += MERGE_BUFFER_LEN;
> }
> - page = virt_to_head_page(buf);
> - offset = buf - (char *)page_address(page);
> + offset = buf - page_address(page);
> if (skb_can_coalesce(curr_skb, num_skb_frags, page, offset)) {
> put_page(page);
> skb_coalesce_rx_frag(curr_skb, num_skb_frags - 1,
> @@ -351,9 +362,28 @@ static int receive_mergeable(struct receive_queue *rq, struct sk_buff *head_skb)
> skb_add_rx_frag(curr_skb, num_skb_frags, page,
> offset, len, MERGE_BUFFER_LEN);
> }
> + }
> +
> + return head_skb;
> +
> +err_skb:
> + put_page(page);
> + while (--num_buf) {
> + buf = virtqueue_get_buf(rq->vq, &len);
> + if (unlikely(!buf)) {
> + pr_debug("%s: rx error: %d buffers missing\n",
> + dev->name, num_buf);
> + dev->stats.rx_length_errors++;
> + break;
> + }
> + page = virt_to_head_page(buf);
> + put_page(page);
> --rq->num;
> }
> - return 0;
> +err_buf:
> + dev->stats.rx_dropped++;
> + dev_kfree_skb(head_skb);
> + return NULL;
> }
>
> static void receive_buf(struct receive_queue *rq, void *buf, unsigned int len)
> @@ -382,19 +412,9 @@ static void receive_buf(struct receive_queue *rq, void *buf, unsigned int len)
> len -= sizeof(struct virtio_net_hdr);
> skb_trim(skb, len);
> } else if (vi->mergeable_rx_bufs) {
> - struct page *page = virt_to_head_page(buf);
> - skb = page_to_skb(rq, page,
> - (char *)buf - (char *)page_address(page),
> - len, MERGE_BUFFER_LEN);
> - if (unlikely(!skb)) {
> - dev->stats.rx_dropped++;
> - put_page(page);
> + skb = receive_mergeable(dev, rq, buf, len);
> + if (unlikely(!skb))
> return;
> - }
> - if (receive_mergeable(rq, skb)) {
> - dev_kfree_skb(skb);
> - return;
> - }
> } else {
> page = buf;
> skb = page_to_skb(rq, page, 0, len, PAGE_SIZE);
Acked-by: Jason Wang <jasowang@redhat.com>
^ permalink raw reply
* RE: [PATCH net v2] xen-netback: fix fragment detection in checksum setup
From: Paul Durrant @ 2013-11-29 10:32 UTC (permalink / raw)
To: Eric Dumazet
Cc: xen-devel@lists.xen.org, netdev@vger.kernel.org, Wei Liu,
Ian Campbell, David Vrabel
In-Reply-To: <1385659745.5352.23.camel@edumazet-glaptop2.roam.corp.google.com>
> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: 28 November 2013 17:29
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org; netdev@vger.kernel.org; Wei Liu; Ian Campbell;
> David Vrabel
> Subject: Re: [PATCH net v2] xen-netback: fix fragment detection in checksum
> setup
>
> On Thu, 2013-11-28 at 13:23 +0000, Paul Durrant wrote:
> > The code to detect fragments in checksum_setup() was missing for IPv4
> and
> > too eager for IPv6. (It transpires that Windows seems to send IPv6 packets
> > with a fragment header even if they are not a fragment - i.e. offset is zero,
> > and M bit is not set).
>
> > + /* 3fff -> fragment offset != 0 OR more fragments */
> > + if (ntohs(iph->frag_off) & 0x3fff)
> > + fragment = true;
> > +
>
> What about the more self documented and faster :
>
> if (iph->frag_off & htons(IP_OFFSET | IP_MF))
> fragment = true;
>
Nicer definitely. I'll need to add the equivalent def for IP6_OFFSET to use the same style of test there.
Thanks,
Paul
^ permalink raw reply
* Re: Re: [PATCH v2] inet: fix possible seqlock deadlocks
From: Jongman Heo @ 2013-11-29 10:42 UTC (permalink / raw)
To: Eric Dumazet, netdev@vger.kernel.org
Cc: David Miller, Hannes Frederic Sowa, linux-kernel@vger.kernel.org
------- Original Message -------
Sender : Jongman Heo <jongman.heo@samsung.com>
Date : 2013-11-29 11:08 (GMT+09:00)
Title : Re: [PATCH v2] inet: fix possible seqlock deadlocks
>
>
>------ Original Message -------
>Sender : Eric Dumazet
>Date : 2013-11-29 02:51 (GMT+09:00)
>Title : [PATCH v2] inet: fix possible seqlock deadlocks
>>
>> From: Eric Dumazet
>>
>> In commit c9e9042994d3 ("ipv4: fix possible seqlock deadlock") I left
>> another places where IP_INC_STATS_BH() were improperly used.
>>
>> udp_sendmsg(), ping_v4_sendmsg() and tcp_v4_connect() are called from
>> process context, not from softirq context.
>>
>> This was detected by lockdep seqlock support.
>>
>> Reported-by: jongman heo
>> Fixes: 584bdf8cbdf6 ("[IPV4]: Fix "ipOutNoRoutes" counter error for TCP and UDP")
>> Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
>> Signed-off-by: Eric Dumazet
>> Cc: Hannes Frederic Sowa
>> ---
>> net/ipv4/ping.c | 2 +-
>> net/ipv4/tcp_ipv4.c | 2 +-
>> net/ipv4/udp.c | 2 +-
>> 3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
>> index 840cf1b9e6ee..242e7f4ed6f4 100644
>> --- a/net/ipv4/ping.c
>> +++ b/net/ipv4/ping.c
>> @@ -772,7 +772,7 @@ int ping_v4_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
>> err = PTR_ERR(rt);
>> rt = NULL;
>> if (err == -ENETUNREACH)
>> - IP_INC_STATS_BH(net, IPSTATS_MIB_OUTNOROUTES);
>> + IP_INC_STATS(net, IPSTATS_MIB_OUTNOROUTES);
>> goto out;
>> }
>>
>> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
>> index 59a6f8b90cd9..067213924751 100644
>> --- a/net/ipv4/tcp_ipv4.c
>> +++ b/net/ipv4/tcp_ipv4.c
>> @@ -177,7 +177,7 @@ int tcp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
>> if (IS_ERR(rt)) {
>> err = PTR_ERR(rt);
>> if (err == -ENETUNREACH)
>> - IP_INC_STATS_BH(sock_net(sk), IPSTATS_MIB_OUTNOROUTES);
>> + IP_INC_STATS(sock_net(sk), IPSTATS_MIB_OUTNOROUTES);
>> return err;
>> }
>>
>> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
>> index 44dfaa09b584..44e3884f9e4c 100644
>> --- a/net/ipv4/udp.c
>> +++ b/net/ipv4/udp.c
>> @@ -999,7 +999,7 @@ int udp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
>> err = PTR_ERR(rt);
>> rt = NULL;
>> if (err == -ENETUNREACH)
>> - IP_INC_STATS_BH(net, IPSTATS_MIB_OUTNOROUTES);
>> + IP_INC_STATS(net, IPSTATS_MIB_OUTNOROUTES);
>> goto out;
>> }
>>
>
>Hi, Eric,
>
>I've applied your patch, and will let you know the result, after a full day or half day test.
>Usually the issue happens within 10 minutes after boot, but to be sure...
>
>Regards,
>Jongman Heo.
>
Hi, Eric,
It has survived about 9 hours, looks fine. Thanks~.
Tested-by: Jongman Heo <jongman.heo@samsung.com>
^ permalink raw reply
* [PATCH net v3] xen-netback: fix fragment detection in checksum setup
From: Paul Durrant @ 2013-11-29 10:52 UTC (permalink / raw)
To: xen-devel, netdev; +Cc: Paul Durrant, Wei Liu, Ian Campbell, David Vrabel
The code to detect fragments in checksum_setup() was missing for IPv4 and
too eager for IPv6. (It transpires that Windows seems to send IPv6 packets
with a fragment header even if they are not a fragment - i.e. offset is zero,
and M bit is not set).
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: David Vrabel <david.vrabel@citrix.com>
---
v3
- Use defined values for 'fragment offset' and 'more fragments'
v2
- Added comments noting what fragment/offset masks mean
drivers/net/xen-netback/netback.c | 31 ++++++++++++++++++++++++++++---
include/net/ipv6.h | 3 ++-
2 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 64f0e0d..53419f6 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1166,15 +1166,27 @@ static int checksum_setup_ip(struct xenvif *vif, struct sk_buff *skb,
struct iphdr *iph = (void *)skb->data;
unsigned int header_size;
unsigned int off;
+ bool fragment;
int err = -EPROTO;
+ fragment = false;
+
off = sizeof(struct iphdr);
header_size = skb->network_header + off + MAX_IPOPTLEN;
maybe_pull_tail(skb, header_size);
+ if (iph->frag_off & htons(IP_OFFSET | IP_MF))
+ fragment = true;
+
off = iph->ihl * 4;
+ if (fragment) {
+ if (net_ratelimit())
+ netdev_err(vif->dev, "Packet is a fragment!\n");
+ goto out;
+ }
+
switch (iph->protocol) {
case IPPROTO_TCP:
if (!skb_partial_csum_set(skb, off,
@@ -1238,6 +1250,7 @@ static int checksum_setup_ipv6(struct xenvif *vif, struct sk_buff *skb,
bool fragment;
bool done;
+ fragment = false;
done = false;
off = sizeof(struct ipv6hdr);
@@ -1276,9 +1289,21 @@ static int checksum_setup_ipv6(struct xenvif *vif, struct sk_buff *skb,
off += (hp->hdrlen+2)<<2;
break;
}
- case IPPROTO_FRAGMENT:
- fragment = true;
- /* fall through */
+ case IPPROTO_FRAGMENT: {
+ struct frag_hdr *hp = (void *)(skb->data + off);
+
+ header_size = skb->network_header +
+ off +
+ sizeof(struct frag_hdr);
+ maybe_pull_tail(skb, header_size);
+
+ if (hp->frag_off & htons(IP6_OFFSET | IP6_MF))
+ fragment = true;
+
+ nexthdr = hp->nexthdr;
+ off += sizeof(struct frag_hdr);
+ break;
+ }
default:
done = true;
break;
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index eb198ac..488316e 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -110,7 +110,8 @@ struct frag_hdr {
__be32 identification;
};
-#define IP6_MF 0x0001
+#define IP6_MF 0x0001
+#define IP6_OFFSET 0xFFF8
#include <net/sock.h>
--
1.7.10.4
^ permalink raw reply related
* [bugzilla-daemon@bugzilla.kernel.org: [Bug 66111] New: after this message ipv4 bond0 working i no try ipv6 not have this time]
From: Hannes Frederic Sowa @ 2013-11-29 11:08 UTC (permalink / raw)
To: netdev
----- Forwarded message from bugzilla-daemon@bugzilla.kernel.org -----
From: bugzilla-daemon@bugzilla.kernel.org
To: hannes@stressinduktion.org
Date: Fri, 29 Nov 2013 10:24:12 +0000
Subject: [Bug 66111] New: after this message ipv4 bond0 working i no try
ipv6 not have this time
Message-ID: <bug-66111-16487@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=66111
Bug ID: 66111
Summary: after this message ipv4 bond0 working i no try ipv6
not have this time
Product: Networking
Version: 2.5
Kernel Version: Linux 12terr 3.12.1 #1 SMP Thu Nov 28 20:32:48 EET
2013 x86_64 GNU/Linux
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV6
Assignee: yoshfuji@linux-ipv6.org
Reporter: korvin2000@gmail.com
Regression: No
[ 8.449805] bonding: bond0: enslaving eth2 as an active interface with an up
link.
[ 8.633226] RTNL: assertion failed at drivers/net/bonding/bond_main.c (3398)
[ 8.633303] CPU: 0 PID: 2007 Comm: rpcbind Tainted: G O 3.12.1 #1
[ 8.633306] Hardware name: System manufacturer System Product Name/F2A85-V,
BIOS 5023 10/29/2012
[ 8.633309] 0000000000000000 0000000000000000 ffffffff81347bc5
ffff880429ed5000
[ 8.633314] ffffffffa0106ea2 ffff880429ed5000 0000000000000000
ffff880429ed5000
[ 8.633318] ffffffff81297d35 0000000000000001 ffff88042994bc80
ffff88042cd45e4c
[ 8.633321] Call Trace:
[ 8.633331] [<ffffffff81347bc5>] ? dump_stack+0x41/0x51
[ 8.633340] [<ffffffffa0106ea2>] ? bond_set_rx_mode+0x2d/0xa7 [bonding]
[ 8.633345] [<ffffffff81297d35>] ? __dev_mc_add+0x48/0x59
[ 8.633351] [<ffffffff813208fa>] ? igmp6_group_added+0x79/0x1a6
[ 8.633355] [<ffffffff810f82a9>] ? kmem_cache_alloc_trace+0xbc/0xcb
[ 8.633359] [<ffffffff81321c7c>] ? ipv6_dev_mc_inc+0x20e/0x236
[ 8.633363] [<ffffffff81321dba>] ? ipv6_sock_mc_join+0x116/0x171
[ 8.633369] [<ffffffff813174a5>] ? do_ipv6_setsockopt.isra.6+0x8ee/0xc76
[ 8.633373] [<ffffffff8128fc9b>] ? dev_name_hash.isra.59+0x20/0x35
[ 8.633377] [<ffffffff8128fd9d>] ? dev_get_by_name_rcu+0x31/0x52
[ 8.633383] [<ffffffff8111e0c7>] ? __inode_wait_for_writeback+0x67/0xae
[ 8.633388] [<ffffffff8104ee54>] ? wake_atomic_t_function+0x21/0x21
[ 8.633393] [<ffffffff8112e6ed>] ? fsnotify_clear_marks_by_inode+0xa0/0x10e
[ 8.633396] [<ffffffff810f7c8e>] ? kmem_cache_free+0x32/0xbf
[ 8.633401] [<ffffffff8110fb08>] ? dentry_kill+0x13d/0x148
[ 8.633405] [<ffffffff8110fd83>] ? dput+0xe5/0xef
[ 8.633410] [<ffffffff81317940>] ? ipv6_setsockopt+0x4f/0x97
[ 8.633415] [<ffffffff8128210d>] ? SyS_setsockopt+0x80/0xab
[ 8.633418] [<ffffffff813510e2>] ? system_call_fastpath+0x16/0x1b
[ 8.907232] RPC: Registered named UNIX socket transport module.
[ 8.907237] RPC: Registered udp transport module.
[ 8.907239] RPC: Registered tcp transport module.
[ 8.907241] RPC: Registered tcp NFSv4.1 backchannel transport module.
--
You are receiving this mail because:
You are watching the assignee of the bug.
----- End forwarded message -----
^ permalink raw reply
* Re: [bugzilla-daemon@bugzilla.kernel.org: [Bug 66111] New: after this message ipv4 bond0 working i no try ipv6 not have this time]
From: Nikolay Aleksandrov @ 2013-11-29 12:28 UTC (permalink / raw)
To: netdev; +Cc: Veaceslav Falico
In-Reply-To: <20131129110828.GO4118@order.stressinduktion.org>
On 11/29/2013 12:08 PM, Hannes Frederic Sowa wrote:
> ----- Forwarded message from bugzilla-daemon@bugzilla.kernel.org -----
>
> From: bugzilla-daemon@bugzilla.kernel.org
> To: hannes@stressinduktion.org
> Date: Fri, 29 Nov 2013 10:24:12 +0000
> Subject: [Bug 66111] New: after this message ipv4 bond0 working i no try
> ipv6 not have this time
> Message-ID: <bug-66111-16487@https.bugzilla.kernel.org/>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=66111
>
> Bug ID: 66111
> Summary: after this message ipv4 bond0 working i no try ipv6
> not have this time
> Product: Networking
> Version: 2.5
> Kernel Version: Linux 12terr 3.12.1 #1 SMP Thu Nov 28 20:32:48 EET
> 2013 x86_64 GNU/Linux
> Hardware: x86-64
> OS: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV6
> Assignee: yoshfuji@linux-ipv6.org
> Reporter: korvin2000@gmail.com
> Regression: No
>
> [ 8.449805] bonding: bond0: enslaving eth2 as an active interface with an up
> link.
> [ 8.633226] RTNL: assertion failed at drivers/net/bonding/bond_main.c (3398)
> [ 8.633303] CPU: 0 PID: 2007 Comm: rpcbind Tainted: G O 3.12.1 #1
> [ 8.633306] Hardware name: System manufacturer System Product Name/F2A85-V,
> BIOS 5023 10/29/2012
> [ 8.633309] 0000000000000000 0000000000000000 ffffffff81347bc5
> ffff880429ed5000
> [ 8.633314] ffffffffa0106ea2 ffff880429ed5000 0000000000000000
> ffff880429ed5000
> [ 8.633318] ffffffff81297d35 0000000000000001 ffff88042994bc80
> ffff88042cd45e4c
> [ 8.633321] Call Trace:
> [ 8.633331] [<ffffffff81347bc5>] ? dump_stack+0x41/0x51
> [ 8.633340] [<ffffffffa0106ea2>] ? bond_set_rx_mode+0x2d/0xa7 [bonding]
> [ 8.633345] [<ffffffff81297d35>] ? __dev_mc_add+0x48/0x59
> [ 8.633351] [<ffffffff813208fa>] ? igmp6_group_added+0x79/0x1a6
> [ 8.633355] [<ffffffff810f82a9>] ? kmem_cache_alloc_trace+0xbc/0xcb
> [ 8.633359] [<ffffffff81321c7c>] ? ipv6_dev_mc_inc+0x20e/0x236
> [ 8.633363] [<ffffffff81321dba>] ? ipv6_sock_mc_join+0x116/0x171
> [ 8.633369] [<ffffffff813174a5>] ? do_ipv6_setsockopt.isra.6+0x8ee/0xc76
> [ 8.633373] [<ffffffff8128fc9b>] ? dev_name_hash.isra.59+0x20/0x35
> [ 8.633377] [<ffffffff8128fd9d>] ? dev_get_by_name_rcu+0x31/0x52
> [ 8.633383] [<ffffffff8111e0c7>] ? __inode_wait_for_writeback+0x67/0xae
> [ 8.633388] [<ffffffff8104ee54>] ? wake_atomic_t_function+0x21/0x21
> [ 8.633393] [<ffffffff8112e6ed>] ? fsnotify_clear_marks_by_inode+0xa0/0x10e
> [ 8.633396] [<ffffffff810f7c8e>] ? kmem_cache_free+0x32/0xbf
> [ 8.633401] [<ffffffff8110fb08>] ? dentry_kill+0x13d/0x148
> [ 8.633405] [<ffffffff8110fd83>] ? dput+0xe5/0xef
> [ 8.633410] [<ffffffff81317940>] ? ipv6_setsockopt+0x4f/0x97
> [ 8.633415] [<ffffffff8128210d>] ? SyS_setsockopt+0x80/0xab
> [ 8.633418] [<ffffffff813510e2>] ? system_call_fastpath+0x16/0x1b
> [ 8.907232] RPC: Registered named UNIX socket transport module.
> [ 8.907237] RPC: Registered udp transport module.
> [ 8.907239] RPC: Registered tcp transport module.
> [ 8.907241] RPC: Registered tcp NFSv4.1 backchannel transport module.
>
Hm, I believe this should be fixed by commit
b32418705107265dfca5edfe2b547643e53a732e ("bonding: RCUify bond_set_rx_mode()").
$ git tag --contains b32418705107265dfca5edfe2b547643e53a732e
v3.13-rc1
Nik
^ permalink raw reply
* Re: [bugzilla-daemon@bugzilla.kernel.org: [Bug 66111] New: after this message ipv4 bond0 working i no try ipv6 not have this time]
From: Veaceslav Falico @ 2013-11-29 12:37 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: netdev
In-Reply-To: <5298886D.8090400@redhat.com>
On Fri, Nov 29, 2013 at 01:28:29PM +0100, Nikolay Aleksandrov wrote:
>On 11/29/2013 12:08 PM, Hannes Frederic Sowa wrote:
>> ----- Forwarded message from bugzilla-daemon@bugzilla.kernel.org -----
>>
>> From: bugzilla-daemon@bugzilla.kernel.org
>> To: hannes@stressinduktion.org
>> Date: Fri, 29 Nov 2013 10:24:12 +0000
>> Subject: [Bug 66111] New: after this message ipv4 bond0 working i no try
>> ipv6 not have this time
>> Message-ID: <bug-66111-16487@https.bugzilla.kernel.org/>
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=66111
>>
>> Bug ID: 66111
>> Summary: after this message ipv4 bond0 working i no try ipv6
>> not have this time
>> Product: Networking
>> Version: 2.5
>> Kernel Version: Linux 12terr 3.12.1 #1 SMP Thu Nov 28 20:32:48 EET
>> 2013 x86_64 GNU/Linux
>> Hardware: x86-64
>> OS: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: normal
>> Priority: P1
>> Component: IPV6
>> Assignee: yoshfuji@linux-ipv6.org
>> Reporter: korvin2000@gmail.com
>> Regression: No
>>
>> [ 8.449805] bonding: bond0: enslaving eth2 as an active interface with an up
>> link.
>> [ 8.633226] RTNL: assertion failed at drivers/net/bonding/bond_main.c (3398)
>> [ 8.633303] CPU: 0 PID: 2007 Comm: rpcbind Tainted: G O 3.12.1 #1
>> [ 8.633306] Hardware name: System manufacturer System Product Name/F2A85-V,
>> BIOS 5023 10/29/2012
>> [ 8.633309] 0000000000000000 0000000000000000 ffffffff81347bc5
>> ffff880429ed5000
>> [ 8.633314] ffffffffa0106ea2 ffff880429ed5000 0000000000000000
>> ffff880429ed5000
>> [ 8.633318] ffffffff81297d35 0000000000000001 ffff88042994bc80
>> ffff88042cd45e4c
>> [ 8.633321] Call Trace:
>> [ 8.633331] [<ffffffff81347bc5>] ? dump_stack+0x41/0x51
>> [ 8.633340] [<ffffffffa0106ea2>] ? bond_set_rx_mode+0x2d/0xa7 [bonding]
>> [ 8.633345] [<ffffffff81297d35>] ? __dev_mc_add+0x48/0x59
>> [ 8.633351] [<ffffffff813208fa>] ? igmp6_group_added+0x79/0x1a6
>> [ 8.633355] [<ffffffff810f82a9>] ? kmem_cache_alloc_trace+0xbc/0xcb
>> [ 8.633359] [<ffffffff81321c7c>] ? ipv6_dev_mc_inc+0x20e/0x236
>> [ 8.633363] [<ffffffff81321dba>] ? ipv6_sock_mc_join+0x116/0x171
>> [ 8.633369] [<ffffffff813174a5>] ? do_ipv6_setsockopt.isra.6+0x8ee/0xc76
>> [ 8.633373] [<ffffffff8128fc9b>] ? dev_name_hash.isra.59+0x20/0x35
>> [ 8.633377] [<ffffffff8128fd9d>] ? dev_get_by_name_rcu+0x31/0x52
>> [ 8.633383] [<ffffffff8111e0c7>] ? __inode_wait_for_writeback+0x67/0xae
>> [ 8.633388] [<ffffffff8104ee54>] ? wake_atomic_t_function+0x21/0x21
>> [ 8.633393] [<ffffffff8112e6ed>] ? fsnotify_clear_marks_by_inode+0xa0/0x10e
>> [ 8.633396] [<ffffffff810f7c8e>] ? kmem_cache_free+0x32/0xbf
>> [ 8.633401] [<ffffffff8110fb08>] ? dentry_kill+0x13d/0x148
>> [ 8.633405] [<ffffffff8110fd83>] ? dput+0xe5/0xef
>> [ 8.633410] [<ffffffff81317940>] ? ipv6_setsockopt+0x4f/0x97
>> [ 8.633415] [<ffffffff8128210d>] ? SyS_setsockopt+0x80/0xab
>> [ 8.633418] [<ffffffff813510e2>] ? system_call_fastpath+0x16/0x1b
>> [ 8.907232] RPC: Registered named UNIX socket transport module.
>> [ 8.907237] RPC: Registered udp transport module.
>> [ 8.907239] RPC: Registered tcp transport module.
>> [ 8.907241] RPC: Registered tcp NFSv4.1 backchannel transport module.
>>
>Hm, I believe this should be fixed by commit
>b32418705107265dfca5edfe2b547643e53a732e ("bonding: RCUify bond_set_rx_mode()").
>$ git tag --contains b32418705107265dfca5edfe2b547643e53a732e
>v3.13-rc1
Yep, indeed, commented on that BZ already.
>
>Nik
^ permalink raw reply
* Re: net: stmmac: DT clock parameter and behavior?
From: Giuseppe CAVALLARO @ 2013-11-29 12:43 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: netdev, Srinivas KANDAGATLA
In-Reply-To: <CAGb2v65G70x-nqg2pJ2dTovgT-b9n+5JCeABzD0ft1JqPm6f4Q@mail.gmail.com>
Hi
On 11/19/2013 3:17 PM, Chen-Yu Tsai wrote:
> I am currently porting the Linux stmmac driver to an AllWinner SoC
> board. The AllWinner A20 SoC has a GMAC, and the drivers they provided
> seems to be an early version of stmmac, with the names replaced.
> I assume the IP in the SoC is an early version of dwmac. So far I have
> managed to get a running system. I would like to clarify a few details
> to clean up the code.
>
> The stmmac core code references a clock named "stmmaceth".
> This clock does not seem to be documented in "networking/stmmac.txt"
yes you are right and I will improve the doc for this clk soon.
Let me provide you some details. I hope useful to go head on your
porting.
The MAC Control Interface, CSR, and Station Management Agent of the MAC
run on the clock named "stmmaceth".
For example the CSR is tuned according to this main clock (as poorly
documented in the stmmac.txt ... I'll improve it as well )
> nor in "devicetree/bindings/net/stmmac.txt".
> STMicroelectronics SPEAr board DTs do not mention this clock.
> But I do see Altera SoCFPGA and Samsung Exynos DTs defining it.
>
> The latest patch series for dwmac-sti on netdev suggests that this
> clock is a 25MHz clock for the phy device. Is this true?
this is reported in
Documentation/devicetree/bindings/net/sti-dwmac.txt
The problem is that, on ST platforms, e.g. in rgmii mode, it is
necessary to dynamically change the phy clk according to the
speed that is negotiated. (e.g. speed = 1000, frq = 125MHz
25 for 100 etc)
This is a quite complex logic that has been added to manage
the phy clock that can be routed by the SoC or PHY.
There is no relationship with the stmmaceth clk.
>
> Then the driver does not consider that the dwmac might have a gated
> clock that needs to be enabled as well. I ran into problems when
> the dwmac was not initialized by the bootloader. I assume this can
> be dealt with using AUXDATA and .init/.exit callbacks?
AUXDATA is not the preferred solution.
this how we are managing stmmac from DT
ethernet1: ethernet1 {
#address-cells = <1>;
#size-cells = <1>;
status = "disabled";
compatible = "st,stih416-dwmac";
reg = <0x7f0 0x4>;
st,syscon = <&syscfg_sbc>;
resets = <&softreset STIH416_ETH1_SOFTRESET>;
ranges;
dwmac@fef08000 {
device_type = "network";
compatible = "snps,dwmac", "snps,dwmac-3.710";
status = "disabled";
reg = <0xfef08000 0x8000>;
interrupts = <0 136 0>, <0 137 0>, <0 138 0>;
interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
snps,pbl = <32>;
snps,mixed-burst;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_mii1>;
clock-names = "stmmaceth";
clocks = <&CLK_S_ETH1_PHY>;
};
};
> Also, earlier versions of stmmac seemed to only give a warning if
> "stmmaceth" clock was not found. But in
>
> 6a81c26f net/stmmac: remove conditional compilation of clk code
>
> the behavior changed to failing completely. Was this intended?
in the beginning, when I pushed the stmmac, we used an old approach
to manage the tx/rx processes by using an external timer.
For example for SH4 we used the TMU channel 2.
The patch you mentioned (IIRC) was for a code that has been removed
long time ago because the logic behind it became obsolete due to the
introduction of the RX watchdog inside the SYNP.
> Last, given the supported device is actually Synopsys DesignWare
> Ethernet MAC, is there any chance the driver could be renamed to dwmac?
we discussed about that long time ago when the driver was moved to
ethernet/stmicro directory. We can reopen the discussion.
I accept it because, indeed, the stmmac is really generic and for
dwmac synp chips.
BR
peppe
^ permalink raw reply
* Hi friend I am a banker in IDB BANK
From: ERCK BENSON @ 2013-11-29 12:42 UTC (permalink / raw)
Hi friend I am a banker in IDB BANK. I want to transfer an abandoned USD5.
5Million to your Bank account. 40/percent will be your share. No risk involved
but keep it as secret. Contact me for more details.
^ permalink raw reply
* ACKNOWLEDGE YOUR PAYMENT
From: David Garcka X @ 2013-11-27 20:27 UTC (permalink / raw)
To: Recipients
After my intensive search, I understand that you share same last name with our late client who passed on few years ago, and am seeking your consent to present you as heir to his estate estimated 30.5mUSD.if you interest, please send your cell/phone, fax and names, for more details. Mr. David Garcka Send from my iPad
^ permalink raw reply
* [RFC] Should skb->csum include 8021Q header for CHECKSUM_COMPLETE && NETIF_F_HW_VLAN_CTAG_RX
From: Thomas Graf @ 2013-11-29 13:28 UTC (permalink / raw)
To: netdev
Hi
Given CHECKSUM_COMPLETE, is skb->csum supposed to include the
checksum of the VLAN header if the header was stripped by the
NIC?
The answer is clear for non accelerated VLAN: it covers all of
the packet without ethernet CRC.
For the accelerated path the answer is less clear after staring
at drivers. The stack currently only fixes the csum for the
software path.
We are seeing hw csum failure warnings for drivers like enic if
OVS pops a VLAN header that was previously stripped in hardware.
Should we force CHECKSUM_NONE like VXLAN does or are all drivers
guaranteed to include VLAN bits for CHECK_COMPLETE regardless of
acceleration?
Best,
Thomas
^ 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