* [PATCH net-next 7/9] r8169:update rtl8168dp ephy parameter
From: Chunhao Lin @ 2014-12-09 16:46 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1418143563-7652-1-git-send-email-hau@realtek.com>
Update rtl8168dp ephy parameter to improve pcie compatibility.
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 39 ++++++++----------------------------
1 file changed, 8 insertions(+), 31 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index a979519..42eda35 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5730,45 +5730,25 @@ static void rtl_hw_start_8168d(struct rtl8169_private *tp)
RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) & ~R8168_CPCMD_QUIRK_MASK);
}
-static void rtl_hw_start_8168dp(struct rtl8169_private *tp)
-{
- void __iomem *ioaddr = tp->mmio_addr;
- struct pci_dev *pdev = tp->pci_dev;
-
- rtl_csi_access_enable_1(tp);
-
- if (tp->dev->mtu <= ETH_DATA_LEN)
- rtl_tx_performance_tweak(pdev, 0x5 << MAX_READ_REQUEST_SHIFT);
-
- RTL_W8(MaxTxPacketSize, TxPacketMax);
-
- rtl_disable_clock_request(pdev);
-}
-
static void rtl_hw_start_8168d_4(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
struct pci_dev *pdev = tp->pci_dev;
static const struct ephy_info e_info_8168d_4[] = {
- { 0x0b, ~0, 0x48 },
- { 0x19, 0x20, 0x50 },
- { 0x0c, ~0, 0x20 }
+ { 0x0b, 0x0000, 0x0048 },
+ { 0x19, 0x0020, 0x0050 },
+ { 0x0c, 0x0100, 0x0020 },
+ { 0x10, 0x0004, 0x0000 }
};
- int i;
rtl_csi_access_enable_1(tp);
- rtl_tx_performance_tweak(pdev, 0x5 << MAX_READ_REQUEST_SHIFT);
+ if (tp->dev->mtu <= ETH_DATA_LEN)
+ rtl_tx_performance_tweak(pdev, 0x5 << MAX_READ_REQUEST_SHIFT);
RTL_W8(MaxTxPacketSize, TxPacketMax);
- for (i = 0; i < ARRAY_SIZE(e_info_8168d_4); i++) {
- const struct ephy_info *e = e_info_8168d_4 + i;
- u16 w;
-
- w = rtl_ephy_read(tp, e->offset);
- rtl_ephy_write(tp, 0x03, (w & e->mask) | e->bits);
- }
+ rtl_ephy_init(tp, e_info_8168d_4, ARRAY_SIZE(e_info_8168d_4));
rtl_enable_clock_request(pdev);
}
@@ -6328,11 +6308,8 @@ static void rtl_hw_start_8168(struct net_device *dev)
break;
case RTL_GIGA_MAC_VER_28:
- rtl_hw_start_8168d_4(tp);
- break;
-
case RTL_GIGA_MAC_VER_31:
- rtl_hw_start_8168dp(tp);
+ rtl_hw_start_8168d_4(tp);
break;
case RTL_GIGA_MAC_VER_32:
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 8/9] r8169:update rtl8105e ephy parameter
From: Chunhao Lin @ 2014-12-09 16:46 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1418143563-7652-1-git-send-email-hau@realtek.com>
Update rtl8105e ephy parameter to improve pcie compatibility.
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 42eda35..56bcd96 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -6450,7 +6450,8 @@ static void rtl_hw_start_8105e_1(struct rtl8169_private *tp)
{ 0x03, 0, 0x0001 },
{ 0x19, 0, 0x0100 },
{ 0x19, 0, 0x0004 },
- { 0x0a, 0, 0x0020 }
+ { 0x0a, 0, 0x0020 },
+ { 0x05, 0, 0x2000 }
};
/* Force LAN exit from ASPM if Rx/Tx are not idle */
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 9/9] r8169:update rtl8402 ephy parameter
From: Chunhao Lin @ 2014-12-09 16:46 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1418143563-7652-1-git-send-email-hau@realtek.com>
Update rtl8402 ephy parameter to improve pcie compatibility.
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 56bcd96..d6b64f5 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -6478,8 +6478,7 @@ static void rtl_hw_start_8402(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
static const struct ephy_info e_info_8402[] = {
- { 0x19, 0xffff, 0xff64 },
- { 0x1e, 0, 0x4000 }
+ { 0x19, 0xffff, 0xff64 }
};
rtl_csi_access_enable_2(tp);
--
1.9.1
^ permalink raw reply related
* Re: [bisect] 3.18 oops in tcp_v4_send_reset()
From: Daniel Borkmann @ 2014-12-09 16:13 UTC (permalink / raw)
To: dann frazier; +Cc: netdev, Eric Dumazet, Alexander Duyck, David S. Miller
In-Reply-To: <20141209160023.GA31520@fluid.dannf>
On 12/09/2014 05:00 PM, dann frazier wrote:
> I'm observing a very reproducible oops which I have bisected down to
> commit ca777ef:
>
> tcp: remove dst refcount false sharing for prequeue mode
>
> I'm reproducing using the juju application, and this occurs when
> tearing down a local lxc container (juju bootstrap/juju
> destroy-environment local). Also worth noting that I'm on an
> arm64 system. I'll follow up w/ results once I've attempted to
> reproduce on x86, and if I'm able to create a simpler reproducer.
It should be fixed in:
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=c3658e8d0f10147fc86018be7f11668246c156d3
Does your kernel include that commit?
> [ 540.914174] Unable to handle kernel NULL pointer dereference at virtual address 00000018
> [ 540.922254] pgd = ffffffc3ea9bb000
> [ 540.925646] [00000018] *pgd=00000043e7bfb003, *pud=00000043e7bfb003, *pmd=0000000000000000
> [ 540.933902] Internal error: Oops: 96000006 [#1] SMP
> [ 540.938754] Modules linked in: veth xt_CHECKSUM xt_tcpudp iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf
> _conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack bridge stp llc ip_tables x_tables ahci_xgene libahci_platform lib
> ahci xgene_enet
> [ 540.962592] CPU: 4 PID: 2788 Comm: mongod Not tainted 3.18.0 #65
> [ 540.968566] task: ffffffc0fe45d400 ti: ffffffc3e6510000 task.ti: ffffffc3e6510000
> [ 540.976014] PC is at tcp_v4_send_reset+0x2ec/0x3e4
> [ 540.980778] LR is at tcp_v4_send_reset+0x3c8/0x3e4
> [ 540.985542] pc : [<ffffffc00069b5dc>] lr : [<ffffffc00069b6b8>] pstate: 80000145
> [ 540.992897] sp : ffffffc3e6513a60
> [ 540.996192] x29: ffffffc3e6513a60 x28: ffffffc3e7a8c600
> [ 541.001494] x27: 0000000000000000 x26: ffffffc3e6510000
> [ 541.006796] x25: 0000000000000000 x24: ffffffc3e6513ab8
> [ 541.012099] x23: 0000000000000000 x22: 0000000000000000
> [ 541.017401] x21: ffffffc3e7a8c600 x20: ffffffc000b65000
> [ 541.022703] x19: ffffffc3e655e6e0 x18: 000000000000000d
> [ 541.028005] x17: 0000007fb2735e10 x16: ffffffc00012052c
> [ 541.033306] x15: 0000007fb2728590 x14: 282039363638333a
> [ 541.038608] x13: 0000000062df7dbf x12: 206e6f697463656e
> [ 541.043910] x11: 0000000000000000 x10: 0000000000000000
> [ 541.049212] x9 : 00000000000012d1 x8 : 00000000000346db
> [ 541.054515] x7 : 0000000000000018 x6 : 0000000000000014
> [ 541.059817] x5 : ffffffc3e6513ae0 x4 : 0000000000000000
> [ 541.065118] x3 : ffffffc0fe6d70ac x2 : ffffffc3e655e71c
> [ 541.070420] x1 : ffffffc3e655e6e0 x0 : 00000000000000ac
> [ 541.075722]
> [ 541.077202] Process mongod (pid: 2788, stack limit = 0xffffffc3e6510058)
> [ 541.083868] Stack: (0xffffffc3e6513a60 to 0xffffffc3e6514000)
> [ 541.089585] 3a60: e6513b20 ffffffc3 0069bc08 ffffffc0 e655e6e0 ffffffc3 e7a8c600 ffffffc3
> [ 541.097720] 3a80: 00000000 00000000 00000001 00000000 009be3c0 ffffffc0 e7a8cacc ffffffc3
> [ 541.105855] 3aa0: e7a8c690 ffffffc3 e7a8c600 ffffffc3 00000000 00000000 bccb9990 bf7ddf62
> [ 541.113990] 3ac0: 00000000 00000450 00000000 00000000 00000000 00000000 00000000 00000000
> [ 541.122124] 3ae0: e6513ab8 ffffffc3 00000014 00000000 00000000 02001afe 00000008 00000000
> [ 541.130259] 3b00: 00000000 00000000 00628130 ffffffc0 e6513b40 ffffffc3 dc8cb000 cb88537f
> [ 541.138394] 3b20: e6513b80 ffffffc3 00686ff4 ffffffc0 e7a8c600 ffffffc3 e7a8cb08 ffffffc3
> [ 541.146528] 3b40: 00000000 00000000 00000001 00000000 009be3c0 ffffffc0 e7a8cacc ffffffc3
> [ 541.154662] 3b60: 00000000 00000000 00628130 ffffffc0 e7a8c600 ffffffc3 00000000 00000000
> [ 541.162797] 3b80: e6513ba0 ffffffc3 006880d0 ffffffc0 00000000 00000000 00000005 00000000
> [ 541.170931] 3ba0: e6513c50 ffffffc3 006b1f14 ffffffc0 e6513d20 ffffffc3 e6513de8 ffffffc3
> [ 541.179066] 3bc0: 00000000 00000000 e6513de8 ffffffc3 efc54f00 ffffffc3 00000005 00000000
> [ 541.187200] 3be0: 00000119 00000000 0000003f 00000000 00ab8000 ffffffc0 e6510000 ffffffc3
> [ 541.195335] 3c00: efc54f00 ffffffc3 0000003d 00000000 e6513ba0 ffffffc3 00000040 00000000
> [ 541.203469] 3c20: e6513d20 ffffffc3 009be400 ffffffc0 92000007 00000000 fe45d400 ffffffc0
> [ 541.211604] 3c40: eb2fc7e0 ffffffc3 ffffffff 7fffffff e6513ca0 ffffffc3 006241ac ffffffc0
> [ 541.219738] 3c60: 00000005 00000000 e6513d20 ffffffc3 e6513ca0 ffffffc3 efc54f00 ffffffc3
> [ 541.227873] 3c80: 00000005 00000000 ffffffff 00000000 e6513d20 ffffffc3 00000005 00000000
> [ 541.236009] 3ca0: e6513d60 ffffffc3 0062421c ffffffc0 e6513de8 ffffffc3 e99e1d00 ffffffc3
> [ 541.244144] 3cc0: 00000005 00000000 18006fe3 0000007f 80000000 00000000 00000015 00000000
> [ 541.252278] 3ce0: e6513ec8 ffffffc3 e99e1d00 ffffffc3 0000003d 00000000 00000000 00000005
> [ 541.260413] 3d00: efc54f00 ffffffc3 00000015 00000000 00000000 00000000 e6513d20 ffffffc3
> [ 541.268547] 3d20: 00000000 00000000 00000000 ffffffc3 e6513dd8 ffffffc3 00000001 00000000
> [ 541.276682] 3d40: 00000000 00000000 00000000 00000000 00000000 00000000 e6513de8 ffffffc3
> [ 541.284817] 3d60: e6513da0 ffffffc3 002006c0 ffffffc0 e6513ec8 ffffffc3 00364ea0 ffffffc0
> [ 541.292952] 3d80: e99e1d00 ffffffc3 e6513dd8 ffffffc3 00000001 00000000 00000000 00000000
> [ 541.301086] 3da0: e6513e40 ffffffc3 00201294 ffffffc0 00000005 00000000 e99e1d00 ffffffc3
> [ 541.309221] 3dc0: 18006fe3 0000007f e6513ec8 ffffffc3 e6513e00 ffffffc3 18006fe3 0000007f
> [ 541.317355] 3de0: 00000005 00000000 e99e1d00 ffffffc3 00000000 00000000 00000000 00000000
> [ 541.325490] 3e00: e6513ce8 ffffffc3 fe45d400 ffffffc0 00000000 00000000 00000000 00000000
> [ 541.333624] 3e20: 00000005 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 541.341758] 3e40: e6513e80 ffffffc3 00201c38 ffffffc0 e99e1d01 ffffffc3 e99e1d00 ffffffc3
> [ 541.349893] 3e60: ffffffff ffffffff b273b864 0000007f 80000000 00000000 b2737188 0000007f
> [ 541.358027] 3e80: 841faef0 0000007f 0008425c ffffffc0 00000000 00000000 00000005 00000000
> [ 541.366162] 3ea0: ffffffff ffffffff 00000001 00000000 18006fe3 0000007f 00000005 00000000
> [ 541.374296] 3ec0: 00000000 00000000 00000000 00000000 00000024 00000000 18006fe3 0000007f
> [ 541.382431] 3ee0: 00000005 00000000 841fbeb8 0000007f 841faeac 0000007f 841fc4a0 0000007f
> [ 541.390565] 3f00: ffffffbb 00000000 00000000 00000000 0000003f 00000000 93ccf8ed 00e370ef
> [ 541.398700] 3f20: 0000009e 00000000 00000070 00000000 93ccf8ed 000000ef 00000009 00000000
> [ 541.406834] 3f40: 0000009b 00000000 00000095 00000000 00000000 00000000 b273b810 0000007f
> [ 541.414968] 3f60: 000000aa 00000000 180016b0 0000007f 00000005 00000000 18006fe3 0000007f
> [ 541.423103] 3f80: 00000005 00000000 00000005 00000000 18006fe3 0000007f 00000000 00000000
> [ 541.431237] 3fa0: 841fc900 0000007f 0000feff 00000000 180012e0 0000007f 841faef0 0000007f
> [ 541.439372] 3fc0: b273b84c 0000007f 841faee0 0000007f b273b864 0000007f 80000000 00000000
> [ 541.447506] 3fe0: 00000024 00000000 0000003f 00000000 ed238e70 ffffffbe ed238ea8 ffffffbe
> [ 541.455640] Call trace:
> [ 541.458074] [<ffffffc00069b5dc>] tcp_v4_send_reset+0x2ec/0x3e4
> [ 541.463877] [<ffffffc00069bc04>] tcp_v4_do_rcv+0xfc/0x350
> [ 541.469247] [<ffffffc000686ff0>] tcp_prequeue_process+0x98/0xdc
> [ 541.475134] [<ffffffc0006880cc>] tcp_recvmsg+0x4c8/0xa0c
> [ 541.480419] [<ffffffc0006b1f10>] inet_recvmsg+0x98/0xb4
> [ 541.485618] [<ffffffc0006241a8>] sock_aio_read.part.12+0xf0/0x118
> [ 541.491679] [<ffffffc000624218>] sock_aio_read+0x48/0x74
> [ 541.496964] [<ffffffc0002006bc>] do_sync_read+0x8c/0xd0
> [ 541.502161] [<ffffffc000201290>] vfs_read+0x128/0x1a8
> [ 541.507185] [<ffffffc000201c34>] SyS_read+0x50/0xb0
> [ 541.512037] Code: 927ff884 b9408ba6 910203a5 8b000063 (f9400c80)
> [ 541.518108] ---[ end trace 524a277a323ba5bd ]---
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [bisect] 3.18 oops in tcp_v4_send_reset()
From: Dann Frazier @ 2014-12-09 17:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Eric Dumazet, Alexander Duyck, David S. Miller
In-Reply-To: <1418142520.14835.22.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Dec 9, 2014 at 9:28 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-12-09 at 08:18 -0800, Eric Dumazet wrote:
>> On Tue, 2014-12-09 at 08:16 -0800, Eric Dumazet wrote:
>> > On Tue, 2014-12-09 at 09:00 -0700, dann frazier wrote:
>> > > I'm observing a very reproducible oops which I have bisected down to
>> > > commit ca777ef:
>>
>> >
>> > Following patch should have fixed this
>> >
>> > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c3658e8d0f10147fc86018be7f11668246c156d3
>> >
>>
>> Oh well, fix was not complete. I'll submit a followup patch.
>>
>
> Could you try following fix before I send official patch ?
This patch does appear to resolve the issue, thanks Eric!
-dann
> Thanks !
>
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index 33f5ff068c7958515e0f63792883a58fb5d6a341..a3f72d7fc06c07c43e1c00b67970eaee074e4593 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -623,6 +623,7 @@ static void tcp_v4_send_reset(struct sock *sk, struct sk_buff *skb)
> arg.iov[0].iov_base = (unsigned char *)&rep;
> arg.iov[0].iov_len = sizeof(rep.th);
>
> + net = sk ? sock_net(sk) : dev_net(skb_dst(skb)->dev);
> #ifdef CONFIG_TCP_MD5SIG
> hash_location = tcp_parse_md5sig_option(th);
> if (!sk && hash_location) {
> @@ -633,7 +634,7 @@ static void tcp_v4_send_reset(struct sock *sk, struct sk_buff *skb)
> * Incoming packet is checked with md5 hash with finding key,
> * no RST generated if md5 hash doesn't match.
> */
> - sk1 = __inet_lookup_listener(dev_net(skb_dst(skb)->dev),
> + sk1 = __inet_lookup_listener(net,
> &tcp_hashinfo, ip_hdr(skb)->saddr,
> th->source, ip_hdr(skb)->daddr,
> ntohs(th->source), inet_iif(skb));
> @@ -681,7 +682,6 @@ static void tcp_v4_send_reset(struct sock *sk, struct sk_buff *skb)
> if (sk)
> arg.bound_dev_if = sk->sk_bound_dev_if;
>
> - net = dev_net(skb_dst(skb)->dev);
> arg.tos = ip_hdr(skb)->tos;
> ip_send_unicast_reply(net, skb, &TCP_SKB_CB(skb)->header.h4.opt,
> ip_hdr(skb)->saddr, ip_hdr(skb)->daddr,
>
>
^ permalink raw reply
* Re: [net-next 00/13][pull request] Intel Wired LAN Driver Updates 2014-12-09
From: David Miller @ 2014-12-09 17:13 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <1418124170-7495-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 9 Dec 2014 03:22:37 -0800
> This series contains updates to i40e and i40evf.
Please address Sergei's feecback on patch #5 and resubmit.
Thank you.
^ permalink raw reply
* Re: [RFC PATCH net-next 04/11] atl1c: remove disable_irq from netpoll controller, use netpoll_irq_lock
From: Sabrina Dubroca @ 2014-12-09 17:23 UTC (permalink / raw)
To: Chris Snook; +Cc: davem, netdev, Jay Cliburn
In-Reply-To: <CAMXMK6t5NfPQFBxK1Qny45LCS6rwX4Ys1n4C7fsTPHXu=x_vuQ@mail.gmail.com>
2014-12-09, 16:13:33 +0000, Chris Snook wrote:
> Could you explain the bug a little more for us? It's not obvious to me how
> sleeping there is a problem.
>
> -- Chris
Sorry for the lack of context.
A might_sleep() check in disable_irq() was added in commit
e22b886a8a43b ("sched/wait: Add might_sleep() checks") [1], and it
triggers when using netconsole:
BUG: sleeping function called from invalid context at kernel/irq/manage.c:104
in_atomic(): 1, irqs_disabled(): 1, pid: 1, name: systemd
no locks held by systemd/1.
irq event stamp: 10102965
hardirqs last enabled at (10102965): [<ffffffff810cbafd>] vprintk_emit+0x2dd/0x6a0
hardirqs last disabled at (10102964): [<ffffffff810cb897>] vprintk_emit+0x77/0x6a0
softirqs last enabled at (10102342): [<ffffffff810666aa>] __do_softirq+0x27a/0x6f0
softirqs last disabled at (10102337): [<ffffffff81066e86>] irq_exit+0x56/0xe0
Preemption disabled at:[<ffffffff817de50d>] printk_emit+0x31/0x33
CPU: 1 PID: 1 Comm: systemd Not tainted 3.18.0-rc2-next-20141029-dirty #222
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140617_173321-var-lib-archbuild-testing-x86_64-tobias 04/01/2014
ffffffff81a82291 ffff88001e743978 ffffffff817df31d 0000000000000000
0000000000000000 ffff88001e7439a8 ffffffff8108dfa2 ffff88001e7439a8
ffffffff81a82291 0000000000000068 0000000000000000 ffff88001e7439d8
Call Trace:
[<ffffffff817df31d>] dump_stack+0x4f/0x7c
[<ffffffff8108dfa2>] ___might_sleep+0x182/0x2b0
[<ffffffff8108e10a>] __might_sleep+0x3a/0xc0
[<ffffffff810ce358>] synchronize_irq+0x38/0xa0
[<ffffffff810ce633>] ? __disable_irq_nosync+0x43/0x70
[<ffffffff810ce690>] disable_irq+0x20/0x30
[<ffffffff815d7253>] e1000_netpoll+0x23/0x60
[<ffffffff81678d02>] netpoll_poll_dev+0x72/0x3a0
[<ffffffff817e9993>] ? _raw_spin_trylock+0x73/0x90
[<ffffffff8167920f>] ? netpoll_send_skb_on_dev+0x1df/0x2e0
[<ffffffff816791e7>] netpoll_send_skb_on_dev+0x1b7/0x2e0
[<ffffffff816795f3>] netpoll_send_udp+0x2e3/0x490
The initial discussion of this problem is here: https://lkml.org/lkml/2014/10/29/523
[1] https://lkml.org/lkml/2014/10/28/427
> On Tue, Dec 9, 2014, 06:39 Sabrina Dubroca <sd@queasysnail.net> wrote:
>
> > disable_irq() may sleep, replace it with a spin_lock in the interrupt
> > handler.
> >
> > No actual testing done, only compiled.
> >
> > Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> > Cc: Jay Cliburn <jcliburn@gmail.com>
> > Cc: Chris Snook <chris.snook@gmail.com>
> > ---
> > drivers/net/ethernet/atheros/atl1c/atl1c.h | 3 +++
> > drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 12 ++++++++----
> > 2 files changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c.h
> > b/drivers/net/ethernet/atheros/atl1c/atl1c.h
> > index b9203d928938..8d97791e1516 100644
> > --- a/drivers/net/ethernet/atheros/atl1c/atl1c.h
> > +++ b/drivers/net/ethernet/atheros/atl1c/atl1c.h
> > @@ -49,6 +49,7 @@
> > #include <linux/workqueue.h>
> > #include <net/checksum.h>
> > #include <net/ip6_checksum.h>
> > +#include <linux/netpoll.h>
> >
> > #include "atl1c_hw.h"
> >
> > @@ -555,6 +556,8 @@ struct atl1c_adapter {
> > struct atl1c_rfd_ring rfd_ring;
> > struct atl1c_rrd_ring rrd_ring;
> > u32 bd_number; /* board number;*/
> > +
> > + struct netpoll_irq_lock netpoll_lock;
> > };
> >
> > #define AT_WRITE_REG(a, reg, value) ( \
> > diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> > b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> > index 72fb86b9aa24..7a1b11eb8e4e 100644
> > --- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> > +++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> > @@ -826,6 +826,7 @@ static int atl1c_sw_init(struct atl1c_adapter *adapter)
> > atomic_set(&adapter->irq_sem, 1);
> > spin_lock_init(&adapter->mdio_lock);
> > spin_lock_init(&adapter->tx_lock);
> > + netpoll_irq_lock_init(&adapter->netpoll_lock);
> > set_bit(__AT_DOWN, &adapter->flags);
> >
> > return 0;
> > @@ -1584,10 +1585,11 @@ static irqreturn_t atl1c_intr(int irq, void *data)
> > struct pci_dev *pdev = adapter->pdev;
> > struct atl1c_hw *hw = &adapter->hw;
> > int max_ints = AT_MAX_INT_WORK;
> > - int handled = IRQ_NONE;
> > + irqreturn_t handled = IRQ_NONE;
> > u32 status;
> > u32 reg_data;
> >
> > + netpoll_irq_lock(&adapter->netpoll_lock);
> > do {
> > AT_READ_REG(hw, REG_ISR, ®_data);
> > status = reg_data & hw->intr_mask;
> > @@ -1622,7 +1624,8 @@ static irqreturn_t atl1c_intr(int irq, void *data)
> > /* reset MAC */
> > set_bit(ATL1C_WORK_EVENT_RESET,
> > &adapter->work_event);
> > schedule_work(&adapter->common_task);
> > - return IRQ_HANDLED;
> > + handled = IRQ_HANDLED;
> > + goto out;
> > }
> >
> > if (status & ISR_OVER)
> > @@ -1641,6 +1644,9 @@ static irqreturn_t atl1c_intr(int irq, void *data)
> > } while (--max_ints > 0);
> > /* re-enable Interrupt*/
> > AT_WRITE_REG(&adapter->hw, REG_ISR, 0);
> > +
> > +out:
> > + netpoll_irq_unlock(&adapter->netpoll_lock);
> > return handled;
> > }
> >
> > @@ -1900,9 +1906,7 @@ static void atl1c_netpoll(struct net_device *netdev)
> > {
> > struct atl1c_adapter *adapter = netdev_priv(netdev);
> >
> > - disable_irq(adapter->pdev->irq);
> > atl1c_intr(adapter->pdev->irq, netdev);
> > - enable_irq(adapter->pdev->irq);
> > }
> > #endif
> >
> > --
> > 2.1.3
> >
> >
--
Sabrina
^ permalink raw reply
* Re: [bisect] 3.18 oops in tcp_v4_send_reset()
From: Eric Dumazet @ 2014-12-09 17:23 UTC (permalink / raw)
To: Dann Frazier; +Cc: netdev, Eric Dumazet, Alexander Duyck, David S. Miller
In-Reply-To: <CALdTtnuazPdMNsOHzzersmyHvLjwxSq1BZoA5ZAdU-0QZtwUsg@mail.gmail.com>
On Tue, 2014-12-09 at 10:10 -0700, Dann Frazier wrote:
> This patch does appear to resolve the issue, thanks Eric!
Thanks Dann
I need to cook a proper patch including ipv6 changes.
^ permalink raw reply
* Re: [PATCH RFC] pci: Control whether VFs are probed on pci_enable_sriov
From: Don Dutile @ 2014-12-09 17:24 UTC (permalink / raw)
To: Yuval Mintz, Eli Cohen
Cc: bhelgaas@google.com, David Miller, linux-pci, netdev,
ogerlitz@mellanox.com, yevgenyp@mellanox.com
In-Reply-To: <B5657A6538887040AD3A81F1008BEC63BA78ED@avmb3.qlogic.org>
On 12/09/2014 02:07 AM, Yuval Mintz wrote:
>>>> Currently the kerenl will call probe for any device for which there
>>>> is a supporting driver and I did not want to change that.
>>>
>>> But what's next? How will this feature be activated?
>>>
>>> Adding a parameter to pci_enable_sriov() might give developers the
>>> false impression they can change behavior by passing `0' to this
>>> function; But that shouldn't be the method to control this - we should
>>> have uniform control of the feature across different drivers, e.g., by an
>> additional sysfs node.
>>
>> I was planning on using this on mlx5 SRIOV support which is not available
>> upstream yet. So this could be a driver developer's decision how to use this.
>
> I think it shouldn't - from user perspective, you can't have such fundamental
> difference between different drivers - that enabling sriov on one device would
> create VFs in the hypervisors and another one won't.
>
>> I think adding another sysfs entry to control this behavior is unnecessary since the
>> administrator has the freedom to later do any bidnings he wishes to do.
>>
>> Keeping things as they are today is not so "nice". I mean, I could fail probe for
>> VFs to avoid them from being initialized at the hypervisor but there are other
>> questions: which error should I return and how can I be sure how the bus driver
>> will refer to such failures.
>
> Again - you could say that this is solely in your drivers decision-making-area,
> but failing the VF probe would lead to the same difference between drivers I've
> stated before.
>
>> So, maybe the solution I suggested is not the best one but do we agree that this
>> needs to be addressed this way or another?
>
> All-in-all, I agree. But I think the solution should be user-controlled and not driver-based.
>
So, I still haven't heard the reasons why the VF driver does not want
to be configured in the host/hypervisor. Please expound. As this solution only
solves it on the first sriov_enable(), and not subsequent deassign of VFs from VMs.
If the desire is to never have the VF driver running on the host, just
blacklist the VF driver. If you use the same driver for both, then
make a simple VF shell driver (includes the same driver), and have it
pci-id match the VF only, and blacklist it in modprobe.conf .
That only wastes some binary space for the dupe'd driver, but it resolves
this situation in a user-driven manner.
^ permalink raw reply
* [PATCH net v3 4/6] cxgb4i: handle non-pdu-aligned rx data
From: Karen Xie @ 2014-12-09 17:32 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v3 4/6] cxgb4i: handle non-pdu-aligned rx data
From: Karen Xie <kxie@chelsio.com>
Abort the connection upon receiving of cpl_rx_data, which means the pdu cannot be recovered from the tcp stream. This generally is due to pdu header corruption.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index e7a26c0..5c7961a 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -1033,6 +1033,27 @@ rel_skb:
__kfree_skb(skb);
}
+static void do_rx_data(struct cxgbi_device *cdev, struct sk_buff *skb)
+{
+ struct cxgbi_sock *csk;
+ struct cpl_rx_data *cpl = (struct cpl_rx_data *)skb->data;
+ unsigned int tid = GET_TID(cpl);
+ struct cxgb4_lld_info *lldi = cxgbi_cdev_priv(cdev);
+ struct tid_info *t = lldi->tids;
+
+ csk = lookup_tid(t, tid);
+ if (!csk) {
+ pr_err("can't find connection for tid %u.\n", tid);
+ } else {
+ /* not expecting this, reset the connection. */
+ pr_err("csk 0x%p, tid %u, rcv cpl_rx_data.\n", csk, tid);
+ spin_lock_bh(&csk->lock);
+ send_abort_req(csk);
+ spin_unlock_bh(&csk->lock);
+ }
+ __kfree_skb(skb);
+}
+
static void do_rx_iscsi_hdr(struct cxgbi_device *cdev, struct sk_buff *skb)
{
struct cxgbi_sock *csk;
@@ -1452,6 +1473,7 @@ cxgb4i_cplhandler_func cxgb4i_cplhandlers[NUM_CPL_CMDS] = {
[CPL_SET_TCB_RPL] = do_set_tcb_rpl,
[CPL_RX_DATA_DDP] = do_rx_data_ddp,
[CPL_RX_ISCSI_DDP] = do_rx_data_ddp,
+ [CPL_RX_DATA] = do_rx_data,
};
int cxgb4i_ofld_init(struct cxgbi_device *cdev)
^ permalink raw reply related
* [PATCH net v3 5/6] cxgb4i: use set_wr_txq() to set tx queues
From: Karen Xie @ 2014-12-09 17:32 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v3 5/6] cxgb4i: use set_wr_txq() to set tx queues
From: Karen Xie <kxie@chelsio.com>
use cxgb4's set_wr_txq() for setting of the tx queue for a outgoing packet. Remove the similar function in cxgb4i.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 16 +++++-----------
1 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 051adab..3c99e5d 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -157,12 +157,6 @@ static struct scsi_transport_template *cxgb4i_stt;
#define RCV_BUFSIZ_MASK 0x3FFU
#define MAX_IMM_TX_PKT_LEN 128
-static inline void set_queue(struct sk_buff *skb, unsigned int queue,
- const struct cxgbi_sock *csk)
-{
- skb->queue_mapping = queue;
-}
-
static int push_tx_frames(struct cxgbi_sock *, int);
/*
@@ -404,7 +398,7 @@ static void send_abort_req(struct cxgbi_sock *csk)
csk->cpl_abort_req = NULL;
req = (struct cpl_abort_req *)skb->head;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
req->cmd = CPL_ABORT_SEND_RST;
t4_set_arp_err_handler(skb, csk, abort_arp_failure);
INIT_TP_WR(req, csk->tid);
@@ -430,7 +424,7 @@ static void send_abort_rpl(struct cxgbi_sock *csk, int rst_status)
csk, csk->state, csk->flags, csk->tid, rst_status);
csk->cpl_abort_rpl = NULL;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
INIT_TP_WR(rpl, csk->tid);
OPCODE_TID(rpl) = cpu_to_be32(MK_OPCODE_TID(CPL_ABORT_RPL, csk->tid));
rpl->cmd = rst_status;
@@ -555,7 +549,7 @@ static inline int send_tx_flowc_wr(struct cxgbi_sock *csk)
flowc->mnemval[8].mnemonic = FW_FLOWC_MNEM_TXDATAPLEN_MAX;
flowc->mnemval[8].val = 16384;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
log_debug(1 << CXGBI_DBG_TOE | 1 << CXGBI_DBG_SOCK,
"csk 0x%p, tid 0x%x, %u,%u,%u,%u,%u,%u,%u.\n",
@@ -659,7 +653,7 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
break;
}
__skb_unlink(skb, &csk->write_queue);
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
skb->csum = credits_needed + flowclen16;
csk->wr_cred -= credits_needed;
csk->wr_una_cred += credits_needed;
@@ -1551,7 +1545,7 @@ static int ddp_ppod_write_idata(struct cxgbi_device *cdev, unsigned int port_id,
return -ENOMEM;
}
req = (struct ulp_mem_io *)skb->head;
- set_queue(skb, CPL_PRIORITY_CONTROL, NULL);
+ set_wr_txq(skb, CPL_PRIORITY_CONTROL, 0);
ulp_mem_io_set_hdr(lldi, req, wr_len, dlen, pm_addr);
idata = (struct ulptx_idata *)(req + 1);
^ permalink raw reply related
* [PATCH net v3 6/6] libcxgbi: free skb after debug prints
From: Karen Xie @ 2014-12-09 17:32 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v3 6/6] libcxgbi: free skb after debug prints
From: Karen Xie <kxie@chelsio.com>
The debug print was accessing the skb after it was freed.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/libcxgbi.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
index 7da59c3..eb58afc 100644
--- a/drivers/scsi/cxgbi/libcxgbi.c
+++ b/drivers/scsi/cxgbi/libcxgbi.c
@@ -2294,10 +2294,12 @@ int cxgbi_conn_xmit_pdu(struct iscsi_task *task)
return err;
}
- kfree_skb(skb);
log_debug(1 << CXGBI_DBG_ISCSI | 1 << CXGBI_DBG_PDU_TX,
"itt 0x%x, skb 0x%p, len %u/%u, xmit err %d.\n",
task->itt, skb, skb->len, skb->data_len, err);
+
+ kfree_skb(skb);
+
iscsi_conn_printk(KERN_ERR, task->conn, "xmit err %d.\n", err);
iscsi_conn_failure(task->conn, ISCSI_ERR_XMIT_FAILED);
return err;
^ permalink raw reply related
* [PATCH net v3 2/6] cxgb4/cxgb4i: set the max. pdu length in firmware
From: Karen Xie @ 2014-12-09 17:32 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v3 2/6] cxgb4/cxgb4i: set the max. pdu length in firmware.
From: Karen Xie <kxie@chelsio.com>
Programs the firmware of the maximum outgoing iscsi pdu length per connection.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 1
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 69 ++++++++++++++++++-------
2 files changed, 52 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
index 3409756..743a350 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
@@ -529,6 +529,7 @@ enum fw_flowc_mnem {
FW_FLOWC_MNEM_RCVNXT,
FW_FLOWC_MNEM_SNDBUF,
FW_FLOWC_MNEM_MSS,
+ FW_FLOWC_MNEM_TXDATAPLEN_MAX,
};
struct fw_flowc_mnemval {
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 5c3f15d..b834bde 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -75,6 +75,7 @@ typedef void (*cxgb4i_cplhandler_func)(struct cxgbi_device *, struct sk_buff *);
static void *t4_uld_add(const struct cxgb4_lld_info *);
static int t4_uld_rx_handler(void *, const __be64 *, const struct pkt_gl *);
static int t4_uld_state_change(void *, enum cxgb4_state state);
+static inline int send_tx_flowc_wr(struct cxgbi_sock *);
static const struct cxgb4_uld_info cxgb4i_uld_info = {
.name = DRV_MODULE_NAME,
@@ -391,6 +392,12 @@ static void send_abort_req(struct cxgbi_sock *csk)
if (unlikely(csk->state == CTP_ABORTING) || !skb || !csk->cdev)
return;
+
+ if (!cxgbi_sock_flag(csk, CTPF_TX_DATA_SENT)) {
+ send_tx_flowc_wr(csk);
+ cxgbi_sock_set_flag(csk, CTPF_TX_DATA_SENT);
+ }
+
cxgbi_sock_set_state(csk, CTP_ABORTING);
cxgbi_sock_set_flag(csk, CTPF_ABORT_RPL_PENDING);
cxgbi_sock_purge_write_queue(csk);
@@ -493,20 +500,40 @@ static inline unsigned int calc_tx_flits_ofld(const struct sk_buff *skb)
return flits + sgl_len(cnt);
}
-static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
+#define FLOWC_WR_NPARAMS_MIN 9
+static inline int tx_flowc_wr_credits(int *nparamsp, int *flowclenp)
+{
+ int nparams, flowclen16, flowclen;
+
+ nparams = FLOWC_WR_NPARAMS_MIN;
+ flowclen = offsetof(struct fw_flowc_wr, mnemval[nparams]);
+ flowclen16 = DIV_ROUND_UP(flowclen, 16);
+ flowclen = flowclen16 * 16;
+ /*
+ * Return the number of 16-byte credits used by the FlowC request.
+ * Pass back the nparams and actual FlowC length if requested.
+ */
+ if (nparamsp)
+ *nparamsp = nparams;
+ if (flowclenp)
+ *flowclenp = flowclen;
+
+ return flowclen16;
+}
+
+static inline int send_tx_flowc_wr(struct cxgbi_sock *csk)
{
struct sk_buff *skb;
struct fw_flowc_wr *flowc;
- int flowclen, i;
+ int nparams, flowclen16, flowclen;
- flowclen = 80;
+ flowclen16 = tx_flowc_wr_credits(&nparams, &flowclen);
skb = alloc_wr(flowclen, 0, GFP_ATOMIC);
flowc = (struct fw_flowc_wr *)skb->head;
flowc->op_to_nparams =
- htonl(FW_WR_OP(FW_FLOWC_WR) | FW_FLOWC_WR_NPARAMS(8));
+ htonl(FW_WR_OP(FW_FLOWC_WR) | FW_FLOWC_WR_NPARAMS(nparams));
flowc->flowid_len16 =
- htonl(FW_WR_LEN16(DIV_ROUND_UP(72, 16)) |
- FW_WR_FLOWID(csk->tid));
+ htonl(FW_WR_LEN16(flowclen16) | FW_WR_FLOWID(csk->tid));
flowc->mnemval[0].mnemonic = FW_FLOWC_MNEM_PFNVFN;
flowc->mnemval[0].val = htonl(csk->cdev->pfvf);
flowc->mnemval[1].mnemonic = FW_FLOWC_MNEM_CH;
@@ -525,11 +552,9 @@ static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
flowc->mnemval[7].val = htonl(csk->advmss);
flowc->mnemval[8].mnemonic = 0;
flowc->mnemval[8].val = 0;
- for (i = 0; i < 9; i++) {
- flowc->mnemval[i].r4[0] = 0;
- flowc->mnemval[i].r4[1] = 0;
- flowc->mnemval[i].r4[2] = 0;
- }
+ flowc->mnemval[8].mnemonic = FW_FLOWC_MNEM_TXDATAPLEN_MAX;
+ flowc->mnemval[8].val = 16384;
+
set_queue(skb, CPL_PRIORITY_DATA, csk);
log_debug(1 << CXGBI_DBG_TOE | 1 << CXGBI_DBG_SOCK,
@@ -539,6 +564,8 @@ static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
csk->advmss);
cxgb4_ofld_send(csk->cdev->ports[csk->port_id], skb);
+
+ return flowclen16;
}
static inline void make_tx_data_wr(struct cxgbi_sock *csk, struct sk_buff *skb,
@@ -600,6 +627,7 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
int dlen = skb->len;
int len = skb->len;
unsigned int credits_needed;
+ int flowclen16 = 0;
skb_reset_transport_header(skb);
if (is_ofld_imm(skb))
@@ -612,6 +640,17 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
credits_needed += DIV_ROUND_UP(
sizeof(struct fw_ofld_tx_data_wr), 16);
+ /*
+ * Assumes the initial credits is large enough to support
+ * fw_flowc_wr plus largest possible first payload
+ */
+ if (!cxgbi_sock_flag(csk, CTPF_TX_DATA_SENT)) {
+ flowclen16 = send_tx_flowc_wr(csk);
+ csk->wr_cred -= flowclen16;
+ csk->wr_una_cred += flowclen16;
+ cxgbi_sock_set_flag(csk, CTPF_TX_DATA_SENT);
+ }
+
if (csk->wr_cred < credits_needed) {
log_debug(1 << CXGBI_DBG_PDU_TX,
"csk 0x%p, skb %u/%u, wr %d < %u.\n",
@@ -621,7 +660,7 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
}
__skb_unlink(skb, &csk->write_queue);
set_queue(skb, CPL_PRIORITY_DATA, csk);
- skb->csum = credits_needed;
+ skb->csum = credits_needed + flowclen16;
csk->wr_cred -= credits_needed;
csk->wr_una_cred += credits_needed;
cxgbi_sock_enqueue_wr(csk, skb);
@@ -632,12 +671,6 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
csk->wr_cred, csk->wr_una_cred);
if (likely(cxgbi_skcb_test_flag(skb, SKCBF_TX_NEED_HDR))) {
- if (!cxgbi_sock_flag(csk, CTPF_TX_DATA_SENT)) {
- send_tx_flowc_wr(csk);
- skb->csum += 5;
- csk->wr_cred -= 5;
- csk->wr_una_cred += 5;
- }
len += cxgbi_ulp_extra_len(cxgbi_skcb_ulp_mode(skb));
make_tx_data_wr(csk, skb, dlen, len, credits_needed,
req_completion);
^ permalink raw reply related
* [PATCH net v3 1/6] cxgb4i: fix tx credit calculation
From: Karen Xie @ 2014-12-09 17:32 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v3 1/6] cxgb4i: fix tx credit calculation
From: Karen Xie <kxie@chelsio.com>
- Only data skbs need the wr header added while control skbs do not. Make sure they are treated differently.
- Any credit related checking should be done before adding the wr header.
- Fixed compiler warning resulted from added cxgbi_skb_test_flag() call in is_ofld_imm().
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 26 +++++++++++++++++---------
drivers/scsi/cxgbi/libcxgbi.h | 4 ++--
2 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 1508125..5c3f15d 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -173,8 +173,12 @@ static int push_tx_frames(struct cxgbi_sock *, int);
*/
static inline int is_ofld_imm(const struct sk_buff *skb)
{
- return skb->len <= (MAX_IMM_TX_PKT_LEN -
- sizeof(struct fw_ofld_tx_data_wr));
+ int length = skb->len;
+
+ if (likely(cxgbi_skcb_test_flag(skb, SKCBF_TX_NEED_HDR)))
+ length += sizeof(struct fw_ofld_tx_data_wr);
+
+ return length <= MAX_IMM_TX_PKT_LEN;
}
static void send_act_open_req(struct cxgbi_sock *csk, struct sk_buff *skb,
@@ -544,15 +548,17 @@ static inline void make_tx_data_wr(struct cxgbi_sock *csk, struct sk_buff *skb,
unsigned int submode = cxgbi_skcb_ulp_mode(skb) & 3;
unsigned int wr_ulp_mode = 0;
- req = (struct fw_ofld_tx_data_wr *)__skb_push(skb, sizeof(*req));
-
if (is_ofld_imm(skb)) {
+ req = (struct fw_ofld_tx_data_wr *)__skb_push(skb,
+ sizeof(*req));
req->op_to_immdlen = htonl(FW_WR_OP(FW_OFLD_TX_DATA_WR) |
FW_WR_COMPL(1) |
FW_WR_IMMDLEN(dlen));
req->flowid_len16 = htonl(FW_WR_FLOWID(csk->tid) |
FW_WR_LEN16(credits));
} else {
+ req = (struct fw_ofld_tx_data_wr *)__skb_push(skb,
+ sizeof(*req));
req->op_to_immdlen =
cpu_to_be32(FW_WR_OP(FW_OFLD_TX_DATA_WR) |
FW_WR_COMPL(1) |
@@ -597,12 +603,14 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
skb_reset_transport_header(skb);
if (is_ofld_imm(skb))
- credits_needed = DIV_ROUND_UP(dlen +
- sizeof(struct fw_ofld_tx_data_wr), 16);
+ credits_needed = DIV_ROUND_UP(dlen, 16);
else
- credits_needed = DIV_ROUND_UP(8*calc_tx_flits_ofld(skb)
- + sizeof(struct fw_ofld_tx_data_wr),
- 16);
+ credits_needed = DIV_ROUND_UP(8*calc_tx_flits_ofld(skb),
+ 16);
+
+ if (likely(cxgbi_skcb_test_flag(skb, SKCBF_TX_NEED_HDR)))
+ credits_needed += DIV_ROUND_UP(
+ sizeof(struct fw_ofld_tx_data_wr), 16);
if (csk->wr_cred < credits_needed) {
log_debug(1 << CXGBI_DBG_PDU_TX,
diff --git a/drivers/scsi/cxgbi/libcxgbi.h b/drivers/scsi/cxgbi/libcxgbi.h
index 2c7cb1c..aba1af7 100644
--- a/drivers/scsi/cxgbi/libcxgbi.h
+++ b/drivers/scsi/cxgbi/libcxgbi.h
@@ -317,8 +317,8 @@ static inline void cxgbi_skcb_clear_flag(struct sk_buff *skb,
__clear_bit(flag, &(cxgbi_skcb_flags(skb)));
}
-static inline int cxgbi_skcb_test_flag(struct sk_buff *skb,
- enum cxgbi_skcb_flags flag)
+static inline int cxgbi_skcb_test_flag(const struct sk_buff *skb,
+ enum cxgbi_skcb_flags flag)
{
return test_bit(flag, &(cxgbi_skcb_flags(skb)));
}
^ permalink raw reply related
* [PATCH net v3 0/6] cxgb4/cxgbi: misc. fixes for cxgb4i
From: Karen Xie @ 2014-12-09 17:32 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v3 0/6] cxgb4/cxgbi: misc. fixes for cxgb4i
This patch set fixes cxgb4i's tx credit calculation and adds handling of additional rx message and negative advice types. It also removes the duplicate code in cxgb4i to set the outgoing queues of a packet.
Karen Xie (6):
cxgb4i: check if wr header is required when calculating tx credit
cxgb4/cxgb4i: set max. outgoing pdu length in the f/w
cxgb4i: add more types of negative advice
cxgb4i: handle non pdu-aligned rx data
cxgb4i: use cxgb4's set_wr_txq() for setting outgoing queues
libcxgbi: fix the debug print accessing skb after it is freed
Sending to net as the fixes are mostly in the network area and it touches cxgb4's header file (t4fw_api.h).
v2 corrects the "CHECK"s flagged by checkpatch.pl --strict.
v3 splits the 3rd patch from v2 to two seperate patches. Adds detailed commit messages and makes subject more concise. Patch 3/6 also changes the return value of is_neg_adv() from int to bool as recommended by Sergei.
^ permalink raw reply
* [PATCH net v3 3/6] cxgb4i: additional types of negative advice
From: Karen Xie @ 2014-12-09 17:32 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v3 3/6] cxgb4i: additional types of negative advice
From: Karen Xie <kxie@chelsio.com>
Treat both CPL_ERR_KEEPALV_NEG_ADVICE and CPL_ERR_PERSIST_NEG_ADVICE as negative advice.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index b834bde..e7a26c0 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -845,6 +845,13 @@ static void csk_act_open_retry_timer(unsigned long data)
}
+static inline bool is_neg_adv(unsigned int status)
+{
+ return status == CPL_ERR_RTX_NEG_ADVICE ||
+ status == CPL_ERR_KEEPALV_NEG_ADVICE ||
+ status == CPL_ERR_PERSIST_NEG_ADVICE;
+}
+
static void do_act_open_rpl(struct cxgbi_device *cdev, struct sk_buff *skb)
{
struct cxgbi_sock *csk;
@@ -866,7 +873,7 @@ static void do_act_open_rpl(struct cxgbi_device *cdev, struct sk_buff *skb)
"csk 0x%p,%u,0x%lx. ", (&csk->saddr), (&csk->daddr),
atid, tid, status, csk, csk->state, csk->flags);
- if (status == CPL_ERR_RTX_NEG_ADVICE)
+ if (is_neg_adv(status))
goto rel_skb;
module_put(THIS_MODULE);
@@ -972,8 +979,7 @@ static void do_abort_req_rss(struct cxgbi_device *cdev, struct sk_buff *skb)
(&csk->saddr), (&csk->daddr),
csk, csk->state, csk->flags, csk->tid, req->status);
- if (req->status == CPL_ERR_RTX_NEG_ADVICE ||
- req->status == CPL_ERR_PERSIST_NEG_ADVICE)
+ if (is_neg_adv(req->status))
goto rel_skb;
cxgbi_sock_get(csk);
^ permalink raw reply related
* Re: [ovs-dev] OVS Kernel Datapath development
From: Pravin Shelar @ 2014-12-09 17:34 UTC (permalink / raw)
To: thomasfherbert; +Cc: Thomas Graf, dev@openvswitch.org, netdev
In-Reply-To: <54870E56.30305@gmail.com>
On Tue, Dec 9, 2014 at 6:59 AM, Thomas F Herbert
<thomasfherbert@gmail.com> wrote:
> Thanks.
>
> What is the impact on a developer submitting a patch. Do we now submit the
> linux datapath portion of the patch to both netdev and ovs-dev?
>
Yes, if a feature needs kernel datapath changes the feature series
should be posted on both mailing lists.
> --Tom
>
>
> On 12/8/14, 1:30 PM, Pravin Shelar wrote:
>>
>> On Mon, Dec 8, 2014 at 9:15 AM, Thomas Graf <tgraf@noironetworks.com>
>> wrote:
>>>
>>> On 12/07/14 at 08:47pm, Pravin Shelar wrote:
>>>>
>>>> Since the beginning OVS kernel datapath development is primarily done
>>>> on external OVS repo. Now we have mostly synced upstream and external
>>>> OVS. So we have decided to change this process. New process is as
>>>> follows.
>>>>
>>>> 1. OVS feature development that involves kernel datapath should be
>>>> done on net-next tree datapath.
>>>> 2. Such feature patch series should be posted on netdev and ovs-dev
>>>> mailing list.
>>>> 3. Once review is done for entire series, kernel and OVS userspace
>>>> patches will be merged in respective repo.
>>>> 4. After the merge developer is suppose to send patches for external
>>>> kernel datapath along with old kernel compatibility code. So that we
>>>> can keep external datapath insync.
>>>
>>> +1
>>>
>>> Just to be clear, by respective repo do you mean net-next/net or will
>>> you maintain a net-next branch on git.kernel.org and continue doing
>>> pull requests?
>>
>> OVS patches will directly go to net-next/net tree. I am not planning
>> on maintaining any tree on git.kernel.org.
>> _______________________________________________
>> dev mailing list
>> dev@openvswitch.org
>> http://openvswitch.org/mailman/listinfo/dev
>
>
>
> --
> Thomas F. Herbert
>
^ permalink raw reply
* [PATCH 1/1] net: dsa: Fix of kernel panic in case of missing PHY.
From: Andrey Volkov @ 2014-12-09 17:31 UTC (permalink / raw)
To: netdev; +Cc: Florian Fainelli
Fix of kernel panic in case of missing PHY.
Signed-off-by: Andrey Volkov <andrey.volkov@nexvision.fr>
---
net/dsa/slave.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 528380a..6f89caa 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -512,7 +512,7 @@ static int dsa_slave_fixed_link_update(struct net_device *dev,
}
/* slave device setup *******************************************************/
-static void dsa_slave_phy_setup(struct dsa_slave_priv *p,
+static int dsa_slave_phy_setup(struct dsa_slave_priv *p,
struct net_device *slave_dev)
{
struct dsa_switch *ds = p->parent;
@@ -533,7 +533,7 @@ static void dsa_slave_phy_setup(struct dsa_slave_priv *p,
ret = of_phy_register_fixed_link(port_dn);
if (ret) {
netdev_err(slave_dev, "failed to register fixed PHY\n");
- return;
+ return ret;
}
phy_is_fixed = true;
phy_dn = port_dn;
@@ -555,12 +555,17 @@ static void dsa_slave_phy_setup(struct dsa_slave_priv *p,
*/
if (!p->phy) {
p->phy = ds->slave_mii_bus->phy_map[p->port];
- phy_connect_direct(slave_dev, p->phy, dsa_slave_adjust_link,
+ if(p->phy)
+ phy_connect_direct(slave_dev, p->phy, dsa_slave_adjust_link,
p->phy_interface);
+ else
+ return -ENODEV;
+
} else {
netdev_info(slave_dev, "attached PHY at address %d [%s]\n",
p->phy->addr, p->phy->drv->name);
}
+ return 0;
}
int dsa_slave_suspend(struct net_device *slave_dev)
@@ -653,7 +658,13 @@ dsa_slave_create(struct dsa_switch *ds, struct device *parent,
p->old_link = -1;
p->old_duplex = -1;
- dsa_slave_phy_setup(p, slave_dev);
+ ret = dsa_slave_phy_setup(p, slave_dev);
+ if (ret) {
+ netdev_err(master, "error %d registering interface %s\n",
+ ret, slave_dev->name);
+ free_netdev(slave_dev);
+ return NULL;
+ }
ret = register_netdev(slave_dev);
if (ret) {
^ permalink raw reply related
* linux-next 20141208 - net/sched/sch_fq_codel.c:97 suspicious RCU
From: Valdis Kletnieks @ 2014-12-09 17:51 UTC (permalink / raw)
To: John Fastabend, Eric Dumazet, David S. Miller; +Cc: linux-kernel, netdev
[-- Attachment #1: Type: text/plain, Size: 3478 bytes --]
Spotted this in dmesg while investigating why my wireless broke
sometime between next-20141201 and next-20141208. Probably not
related, as wireless has been broken on several boot attempts of -1208,
but this has popped only once....
Looks like the fault of
commit 46e5da40aec256155cfedee96dd21a75da941f2c
Author: John Fastabend <john.fastabend@gmail.com>
Date: Fri Sep 12 20:04:52 2014 -0700
net: qdisc: use rcu prefix and silence sparse warnings
but I freely admit that exhausts my RCU debugging skills. :)
[ 104.743212] ===============================
[ 104.743214] [ INFO: suspicious RCU usage. ]
[ 104.743218] 3.18.0-next-20141208 #27 Tainted: G OE
[ 104.743219] -------------------------------
[ 104.743224] net/sched/sch_fq_codel.c:97 suspicious rcu_dereference_check() usage!
[ 104.743227]
other info that might help us debug this:
[ 104.743231]
rcu_scheduler_active = 1, debug_locks = 1
[ 104.743236] 4 locks held by unbound/1873:
[ 104.743239] #0: (rcu_read_lock_bh){......}, at: [<ffffffff8a537066>] rcu_lock_acquire+0x0/0x22
[ 104.743257] #1: (rcu_read_lock_bh){......}, at: [<ffffffff8a4ebd44>] rcu_lock_acquire+0x0/0x22
[ 104.743274] #2: (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+.....}, at: [<ffffffff8a4f3ea4>] __dev_queue_xmit+0x32a/0x66a
[ 104.743292] #3: (&qdisc_tx_lock){+.-...}, at: [<ffffffff8a4f3ead>] __dev_queue_xmit+0x333/0x66a
[ 104.743302]
stack backtrace:
[ 104.743307] CPU: 2 PID: 1873 Comm: unbound Tainted: G OE 3.18.0-next-20141208 #27
[ 104.743309] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A15 06/20/2014
[ 104.743312] 0000000000000001 ffff8800b9f3f978 ffffffff8a6ba925 ffff880223bac210
[ 104.743317] 0000000000000001 ffff8800b9f3f9a8 ffffffff8a07f124 ffff8800b9ce4e00
[ 104.743323] ffff880223fea600 0000000000000000 ffff8800c6e2c000 ffff8800b9f3f9f8
[ 104.743329] Call Trace:
[ 104.743336] [<ffffffff8a6ba925>] dump_stack+0x50/0xa8
[ 104.743343] [<ffffffff8a07f124>] lockdep_rcu_suspicious+0xea/0xf3
[ 104.743348] [<ffffffff8a514903>] fq_codel_enqueue+0x79/0x21c
[ 104.743353] [<ffffffff8a6c5228>] ? _raw_spin_lock+0x37/0x3f
[ 104.743357] [<ffffffff8a4f3fb5>] __dev_queue_xmit+0x43b/0x66a
[ 104.743362] [<ffffffff8a4f41ef>] dev_queue_xmit+0xb/0xd
[ 104.743367] [<ffffffff8a537beb>] ip_finish_output2+0x42b/0x46c
[ 104.743371] [<ffffffff8a53838f>] ip_finish_output+0x13c/0x144
[ 104.743376] [<ffffffff8a5393f1>] ip_output+0x4c/0x70
[ 104.743381] [<ffffffff8a538d92>] ip_local_out_sk+0x54/0x5f
[ 104.743385] [<ffffffff8a539c2f>] ip_send_skb+0x12/0x37
[ 104.743390] [<ffffffff8a55d145>] udp_send_skb+0x176/0x1db
[ 104.743394] [<ffffffff8a55d839>] udp_sendmsg+0x63e/0x87c
[ 104.743398] [<ffffffff8a537379>] ? skb_set_owner_w+0x56/0x56
[ 104.743404] [<ffffffff8a09011d>] ? __rcu_read_unlock+0xf5/0xfd
[ 104.743408] [<ffffffff8a568135>] ? rcu_read_unlock+0x3e/0x5d
[ 104.743413] [<ffffffff8a568af9>] inet_sendmsg+0x3d/0x66
[ 104.743419] [<ffffffff8a4d6a4b>] __sock_sendmsg_nosec+0x25/0x27
[ 104.743422] [<ffffffff8a4d80da>] sock_sendmsg+0x5a/0x7b
[ 104.743429] [<ffffffff8a12581b>] ? might_fault+0xae/0xb0
[ 104.743433] [<ffffffff8a4d6c22>] ? audit_sockaddr+0x2b/0x44
[ 104.743437] [<ffffffff8a4da1ff>] SYSC_sendto+0x119/0x15c
[ 104.743443] [<ffffffff8a00e2b5>] ? do_audit_syscall_entry+0xb8/0xc7
[ 104.743447] [<ffffffff8a4da85d>] SyS_sendto+0x9/0xb
[ 104.743453] [<ffffffff8a6c5fd2>] system_call_fastpath+0x12/0x17
[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]
^ permalink raw reply
* [PATCH net] tcp: fix more NULL deref after prequeue changes
From: Eric Dumazet @ 2014-12-09 17:56 UTC (permalink / raw)
To: Dann Frazier, David S. Miller; +Cc: netdev
In-Reply-To: <1418145804.27198.0.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
When I cooked commit c3658e8d0f1 ("tcp: fix possible NULL dereference in
tcp_vX_send_reset()") I missed other spots we could deref a NULL
skb_dst(skb)
Again, if a socket is provided, we do not need skb_dst() to get a
pointer to network namespace : sock_net(sk) is good enough.
Reported-by: Dann Frazier <dann.frazier@canonical.com>
Bisected-by: Dann Frazier <dann.frazier@canonical.com>
Tested-by: Dann Frazier <dann.frazier@canonical.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Fixes: ca777eff51f7 ("tcp: remove dst refcount false sharing for prequeue mode")
---
net/ipv4/tcp_ipv4.c | 4 ++--
net/ipv6/tcp_ipv6.c | 28 ++++++++++++++--------------
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 147be2024290..ef7089ca86e2 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -623,6 +623,7 @@ static void tcp_v4_send_reset(struct sock *sk, struct sk_buff *skb)
arg.iov[0].iov_base = (unsigned char *)&rep;
arg.iov[0].iov_len = sizeof(rep.th);
+ net = sk ? sock_net(sk) : dev_net(skb_dst(skb)->dev);
#ifdef CONFIG_TCP_MD5SIG
hash_location = tcp_parse_md5sig_option(th);
if (!sk && hash_location) {
@@ -633,7 +634,7 @@ static void tcp_v4_send_reset(struct sock *sk, struct sk_buff *skb)
* Incoming packet is checked with md5 hash with finding key,
* no RST generated if md5 hash doesn't match.
*/
- sk1 = __inet_lookup_listener(dev_net(skb_dst(skb)->dev),
+ sk1 = __inet_lookup_listener(net,
&tcp_hashinfo, ip_hdr(skb)->saddr,
th->source, ip_hdr(skb)->daddr,
ntohs(th->source), inet_iif(skb));
@@ -681,7 +682,6 @@ static void tcp_v4_send_reset(struct sock *sk, struct sk_buff *skb)
if (sk)
arg.bound_dev_if = sk->sk_bound_dev_if;
- net = dev_net(skb_dst(skb)->dev);
arg.tos = ip_hdr(skb)->tos;
ip_send_unicast_reply(net, skb, &TCP_SKB_CB(skb)->header.h4.opt,
ip_hdr(skb)->saddr, ip_hdr(skb)->daddr,
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index dc495ae2ead0..c277951d783b 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -787,16 +787,16 @@ static const struct tcp_request_sock_ops tcp_request_sock_ipv6_ops = {
.queue_hash_add = inet6_csk_reqsk_queue_hash_add,
};
-static void tcp_v6_send_response(struct sk_buff *skb, u32 seq, u32 ack, u32 win,
- u32 tsval, u32 tsecr, int oif,
- struct tcp_md5sig_key *key, int rst, u8 tclass,
- u32 label)
+static void tcp_v6_send_response(struct sock *sk, struct sk_buff *skb, u32 seq,
+ u32 ack, u32 win, u32 tsval, u32 tsecr,
+ int oif, struct tcp_md5sig_key *key, int rst,
+ u8 tclass, u32 label)
{
const struct tcphdr *th = tcp_hdr(skb);
struct tcphdr *t1;
struct sk_buff *buff;
struct flowi6 fl6;
- struct net *net = dev_net(skb_dst(skb)->dev);
+ struct net *net = sk ? sock_net(sk) : dev_net(skb_dst(skb)->dev);
struct sock *ctl_sk = net->ipv6.tcp_sk;
unsigned int tot_len = sizeof(struct tcphdr);
struct dst_entry *dst;
@@ -946,7 +946,7 @@ static void tcp_v6_send_reset(struct sock *sk, struct sk_buff *skb)
(th->doff << 2);
oif = sk ? sk->sk_bound_dev_if : 0;
- tcp_v6_send_response(skb, seq, ack_seq, 0, 0, 0, oif, key, 1, 0, 0);
+ tcp_v6_send_response(sk, skb, seq, ack_seq, 0, 0, 0, oif, key, 1, 0, 0);
#ifdef CONFIG_TCP_MD5SIG
release_sk1:
@@ -957,13 +957,13 @@ release_sk1:
#endif
}
-static void tcp_v6_send_ack(struct sk_buff *skb, u32 seq, u32 ack,
- u32 win, u32 tsval, u32 tsecr, int oif,
+static void tcp_v6_send_ack(struct sock *sk, struct sk_buff *skb, u32 seq,
+ u32 ack, u32 win, u32 tsval, u32 tsecr, int oif,
struct tcp_md5sig_key *key, u8 tclass,
u32 label)
{
- tcp_v6_send_response(skb, seq, ack, win, tsval, tsecr, oif, key, 0, tclass,
- label);
+ tcp_v6_send_response(sk, skb, seq, ack, win, tsval, tsecr, oif, key, 0,
+ tclass, label);
}
static void tcp_v6_timewait_ack(struct sock *sk, struct sk_buff *skb)
@@ -971,7 +971,7 @@ static void tcp_v6_timewait_ack(struct sock *sk, struct sk_buff *skb)
struct inet_timewait_sock *tw = inet_twsk(sk);
struct tcp_timewait_sock *tcptw = tcp_twsk(sk);
- tcp_v6_send_ack(skb, tcptw->tw_snd_nxt, tcptw->tw_rcv_nxt,
+ tcp_v6_send_ack(sk, skb, tcptw->tw_snd_nxt, tcptw->tw_rcv_nxt,
tcptw->tw_rcv_wnd >> tw->tw_rcv_wscale,
tcp_time_stamp + tcptw->tw_ts_offset,
tcptw->tw_ts_recent, tw->tw_bound_dev_if, tcp_twsk_md5_key(tcptw),
@@ -986,10 +986,10 @@ static void tcp_v6_reqsk_send_ack(struct sock *sk, struct sk_buff *skb,
/* sk->sk_state == TCP_LISTEN -> for regular TCP_SYN_RECV
* sk->sk_state == TCP_SYN_RECV -> for Fast Open.
*/
- tcp_v6_send_ack(skb, (sk->sk_state == TCP_LISTEN) ?
+ tcp_v6_send_ack(sk, skb, (sk->sk_state == TCP_LISTEN) ?
tcp_rsk(req)->snt_isn + 1 : tcp_sk(sk)->snd_nxt,
- tcp_rsk(req)->rcv_nxt,
- req->rcv_wnd, tcp_time_stamp, req->ts_recent, sk->sk_bound_dev_if,
+ tcp_rsk(req)->rcv_nxt, req->rcv_wnd,
+ tcp_time_stamp, req->ts_recent, sk->sk_bound_dev_if,
tcp_v6_md5_do_lookup(sk, &ipv6_hdr(skb)->daddr),
0, 0);
}
^ permalink raw reply related
* Re: OVS Kernel Datapath development
From: Lori Jakab @ 2014-12-09 18:02 UTC (permalink / raw)
To: Pravin Shelar, netdev,
dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org
In-Reply-To: <CALnjE+rn_Giv+8TM1_E2faBftRkivXMYHcjn-4Eq4Gu15r=CiQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 12/08/2014 06:47 AM, Pravin Shelar wrote:
> Since the beginning OVS kernel datapath development is primarily done
> on external OVS repo. Now we have mostly synced upstream and external
> OVS. So we have decided to change this process. New process is as
> follows.
Patch series that have previous revisions already reviewed with the old
process should now switch to the new process? Or does the change apply
only to new patch series?
-Lori
>
> 1. OVS feature development that involves kernel datapath should be
> done on net-next tree datapath.
> 2. Such feature patch series should be posted on netdev and ovs-dev
> mailing list.
> 3. Once review is done for entire series, kernel and OVS userspace
> patches will be merged in respective repo.
> 4. After the merge developer is suppose to send patches for external
> kernel datapath along with old kernel compatibility code. So that we
> can keep external datapath insync.
>
>
> Thanks,
> Pravin.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* RE: [net-next 05/13] i40e: add range check to i40e_aq_rc_to_posix
From: Nelson, Shannon @ 2014-12-09 17:35 UTC (permalink / raw)
To: Sergei Shtylyov, Kirsher, Jeffrey T, davem@davemloft.net
Cc: netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com
In-Reply-To: <548705FC.6020805@cogentembedded.com>
> -----Original Message-----
> From: Sergei Shtylyov [mailto:sergei.shtylyov@cogentembedded.com]
> Sent: Tuesday, December 09, 2014 6:24 AM
> To: Kirsher, Jeffrey T; davem@davemloft.net
> Cc: Nelson, Shannon; netdev@vger.kernel.org; nhorman@redhat.com;
> sassmann@redhat.com; jogreene@redhat.com
> Subject: Re: [net-next 05/13] i40e: add range check to
> i40e_aq_rc_to_posix
>
> Hello.
>
> On 12/9/2014 2:22 PM, Jeff Kirsher wrote:
>
> > From: Shannon Nelson <shannon.nelson@intel.com>
>
> > Just to be sure, add a range check to avoid any possible
> > array index-out-of-bound issues.
>
> > Change-ID: I9323bee6732c2a47599816e1d6c6b3a1f8dcbf54
> > Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
> > Acked-by: Michal Kosiarz <michal.kosiarz@intel.com>
> > Tested-by: Jim Young <jamesx.m.young@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > ---
> > drivers/net/ethernet/intel/i40e/i40e_adminq.h | 2 ++
> > drivers/net/ethernet/intel/i40evf/i40e_adminq.h | 2 ++
> > 2 files changed, 4 insertions(+)
>
> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_adminq.h
> b/drivers/net/ethernet/intel/i40e/i40e_adminq.h
> > index 618fe96..4064b1e 100644
> > --- a/drivers/net/ethernet/intel/i40e/i40e_adminq.h
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_adminq.h
> > @@ -136,6 +136,8 @@ static inline int i40e_aq_rc_to_posix(u16 aq_rc)
> > -EFBIG, /* I40E_AQ_RC_EFBIG */
> > };
> >
> > + if (aq_rc >= (sizeof(aq_to_posix) / sizeof((aq_to_posix)[0])))
>
> There's ARRAY_SIZE() macro exactly for such computations. And parens
> around the last 'aq_to_posix' are not needed.
Yep, you're right. I'll see about getting Jeff to push a v2 of this patch soon.
Thanks,
sln
^ permalink raw reply
* Re: [net_test_tools] udpflood: Add IPv6 support
From: David Miller @ 2014-12-09 18:05 UTC (permalink / raw)
To: kafai; +Cc: netdev
In-Reply-To: <1417545706-31249-1-git-send-email-kafai@fb.com>
From: Martin KaFai Lau <kafai@fb.com>
Date: Tue, 2 Dec 2014 10:41:46 -0800
> This patch:
> 1. Add IPv6 support
> 2. Print timing for every 65536 fib insert operations to observe
> the gc effect (mostly for IPv6 fib).
Applied, thanks.
^ permalink raw reply
* Re: linux-next 20141208 - net/sched/sch_fq_codel.c:97 suspicious RCU
From: Eric Dumazet @ 2014-12-09 18:07 UTC (permalink / raw)
To: Valdis Kletnieks; +Cc: John Fastabend, David S. Miller, linux-kernel, netdev
In-Reply-To: <6468.1418147500@turing-police.cc.vt.edu>
On Tue, Dec 9, 2014 at 9:51 AM, Valdis Kletnieks
<Valdis.Kletnieks@vt.edu> wrote:
> Spotted this in dmesg while investigating why my wireless broke
> sometime between next-20141201 and next-20141208. Probably not
> related, as wireless has been broken on several boot attempts of -1208,
> but this has popped only once....
>
> Looks like the fault of
>
> commit 46e5da40aec256155cfedee96dd21a75da941f2c
> Author: John Fastabend <john.fastabend@gmail.com>
> Date: Fri Sep 12 20:04:52 2014 -0700
Well, its a (harmless) typo : this should really be an
rcu_dereference_bh() instead of rcu_dereference()
^ permalink raw reply
* Re: [PATCH v7 2/3] net: Add Keystone NetCP ethernet driver
From: David Miller @ 2014-12-09 18:10 UTC (permalink / raw)
To: m-karicheri2-l0cyMroinI0
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
grant.likely-QSEj5FYQhm4dnm+yROfE0A, sandeep_n-l0cyMroinI0,
santosh.shilimkar-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <1417556503-22290-3-git-send-email-m-karicheri2-l0cyMroinI0@public.gmane.org>
From: Murali Karicheri <m-karicheri2-l0cyMroinI0@public.gmane.org>
Date: Tue, 2 Dec 2014 16:41:42 -0500
> +static void set_pkt_info_le(u32 buff, u32 buff_len, u32 ndesc,
> + struct knav_dma_desc *desc)
> +{
> + desc->buff_len = cpu_to_le32(buff_len);
> + desc->buff = cpu_to_le32(buff);
> + desc->next_desc = cpu_to_le32(ndesc);
> +}
The members of knav_dma_desc are "u32", so you are going to get tons of
static checker warnings from trying to assign cpu_to_le32()'s result
(which is a le32) into them.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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
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