* Re: [PATCH net-next] dccp: Convert DCCP_WARN to net_warn_ratelimited
From: David Miller @ 2014-11-09 1:42 UTC (permalink / raw)
To: joe; +Cc: netdev, linux-kernel, gerrit
In-Reply-To: <1415307221.21526.0.camel@perches.com>
From: Joe Perches <joe@perches.com>
Date: Thu, 06 Nov 2014 12:53:41 -0800
> Remove the dependency on the "warning" sysctl (net_msg_warn)
> which is only used by the LIMIT_NETDEBUG macro.
>
> Convert the LIMIT_NETDEBUG use in DCCP_WARN to the more
> common net_warn_ratelimited mechanism.
>
> This still ratelimits based on the net_ratelimit()
> function, but removes the check for the sysctl.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied, thanks Joe.
> What about the LIMIT_NETDEBUG stuff now?
>
> Maybe all of them might as well be net_dbg_ratelimited
> even if it changes some of the logging levels.
I think a straight conversion to net_dbg_ratelimited would
be fine.
^ permalink raw reply
* [PATCH 1/3 net-next] sunvnet: Fix race between vnet_start_xmit() and vnet_ack()
From: Sowmini Varadhan @ 2014-11-09 1:41 UTC (permalink / raw)
To: davem, sowmini.varadhan; +Cc: netdev, david.stevens
When vnet_start_xmit() is concurrent with vnet_ack(), we may
have a race that looks like:
thread 1 thread 2
vnet_start_xmit vnet_event_napi -> vnet_rx
__vnet_tx_trigger for some desc X
at this point dr->prod == X
peer sends back a stopped ack for X
we process X, but X == dr->prod
so we bail out in vnet_ack with
!idx_is_pending
update dr->prod
As a result of the fact that we never processed the stopped ack for X,
the Tx path is led to incorrectly believe that the peer is still
"started" and reading, but the peer has stopped reading, which will
ultimately end in flow-control assertions.
The fix is to synchronize the above 2 paths on the netif_tx_lock.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
---
drivers/net/ethernet/sun/sunvnet.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/sun/sunvnet.c b/drivers/net/ethernet/sun/sunvnet.c
index 5c5fb59..deb395a 100644
--- a/drivers/net/ethernet/sun/sunvnet.c
+++ b/drivers/net/ethernet/sun/sunvnet.c
@@ -559,15 +559,17 @@ static int vnet_ack(struct vnet_port *port, void *msgbuf)
return 0;
end = pkt->end_idx;
- if (unlikely(!idx_is_pending(dr, end)))
- return 0;
-
vp = port->vp;
dev = vp->dev;
+ netif_tx_lock(dev);
+ if (unlikely(!idx_is_pending(dr, end))) {
+ netif_tx_unlock(dev);
+ return 0;
+ }
+
/* sync for race conditions with vnet_start_xmit() and tell xmit it
* is time to send a trigger.
*/
- netif_tx_lock(dev);
dr->cons = next_idx(end, dr);
desc = vio_dring_entry(dr, dr->cons);
if (desc->hdr.state == VIO_DESC_READY && port->start_cons) {
--
1.8.4.2
^ permalink raw reply related
* [PATCH 0/3 net-next] sunvnet: edge-case/race-conditions bug fixes
From: Sowmini Varadhan @ 2014-11-09 1:41 UTC (permalink / raw)
To: davem, sowmini.varadhan; +Cc: netdev, david.stevens
This patch series contains fixes for race-conditions in sunvnet,
that can encountered when there is a difference in latency between
producer and consumer.
Patch 1 addresses a case when the STOPPED LDC ack from a peer is
processed before vnet_start_xmit can finish updating the dr->prod
state.
Patch 2 fixes the edge-case when outgoing data and incoming
stopped-ack cross each other in flight.
Patch 3 adds a missing rcu_read_unlock(), found by code-inspection.
Sowmini Varadhan (3):
Fix race between vnet_start_xmit() and vnet_ack()
vnet_ack() should check if !start_cons to send a missed trigger
Add missing rcu_read_unlock() in vnet_start_xmit
drivers/net/ethernet/sun/sunvnet.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
--
1.8.4.2
^ permalink raw reply
* e100: Laptop battery drain and WoL settings from EEPROM
From: Ondrej Zary @ 2014-11-08 23:15 UTC (permalink / raw)
To: e1000-devel; +Cc: netdev, Kernel development list
Hello,
there is long-standing problem with battery drain after turning off at least
some Toshiba laptops, see
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/110784
I have the same problem with Toshiba Portege R100. When I shut it down in
Linux, the battery is drained to zero in a couple of days. I noticed that the
LAN port is still active, even when AC disconnected.
The WoL is enabled by default by e100 driver:
# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: No
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: g
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
By this code:
/* Wol magic packet can be enabled from eeprom */
if ((nic->mac >= mac_82558_D101_A4) &&
(nic->eeprom[eeprom_id] & eeprom_id_wol)) {
nic->flags |= wol_magic;
device_set_wakeup_enable(&pdev->dev, true);
}
because the WoL bit is set in EEPROM ID word:
# ethtool -e eth0
Offset Values
------ ------
0x0000: xx xx xx xx xx xx 03 1b 00 00 01 02 01 47 00 00
0x0010: 00 00 00 00 a2 49 01 00 79 11 7f 00 00 00 00 00
^^ bit 5 here
0x0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0040: 00 00 00 00 00 00 3d 10 00 00 00 00 00 00 00 00
0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0060: e4 00 3f 40 09 41 00 00 00 00 00 00 00 00 00 00
0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f7 fe
Looks like this laptop is probably WoL-capable even on battery.
Measured the current from AC adapter:
around 20mA with WoL inactive (shut down from Windows or by power button in GRUB)
around 40mA with WoL active (shut down from Linux)
So to work-around this problem, users must disable WoL manually on each boot.
Maybe the driver should ignore the EEPROM WoL bit on Toshiba susbsystem IDs?
Or completely, like Windows driver does?
Ethernet controller details:
02:08.0 Ethernet controller [0200]: Intel Corporation 82801DB PRO/100 VE (MOB) Ethernet Controller [8086:103d] (rev 83)
Subsystem: Toshiba America Info Systems Device [1179:0001]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 11
Region 0: Memory at dfdff000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at cf40 [size=64]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME-
Kernel driver in use: e100
--
Ondrej Zary
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] r8152: clear theflagofSCHEDULE_TASKLETin tasklet
From: Francois Romieu @ 2014-11-08 22:11 UTC (permalink / raw)
To: Hayes Wang
Cc: David Miller, netdev@vger.kernel.org, nic_swsd,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB2ECDFC2@RTITMBSV03.realtek.com.tw>
Hayes Wang <hayeswang@realtek.com> :
> Francois Romieu [mailto:romieu@fr.zoreil.com]
> > Sent: Monday, November 03, 2014 6:53 AM
> [...]
> > test_and_clear_bit (dense) or clear_bit would be more idiomatic.
>
> Excuse me. Any suggestion?
> Should I use clear_bit directly, or something else?
> Or, do I have to remove this patch?
The performance explanation leaves me a bit unconvinced. Without any
figure one could simply go for the always locked clear_bit because of:
1. the "I'm racy" message that the open-coded test + set sends
2. the extra work needed to avoid 1 (comment, explain, ...).
The extra time could thus be used to see what happens when napi is
shoehorned in this tasklet machinery. I'd naively expect it to be
relevant for efficiency.
I won't mind if your agenda is completely different. :o)
--
Ueimor
^ permalink raw reply
* Re: [PATCH net-next] PPC: bpf_jit_comp: add SKF_AD_HATYPE instruction
From: Alexei Starovoitov @ 2014-11-08 17:59 UTC (permalink / raw)
To: Denis Kirjanov
Cc: netdev@vger.kernel.org, linuxppc-dev, Daniel Borkmann,
Philippe Bergheaud
In-Reply-To: <1415253755-4001-1-git-send-email-kda@linux-powerpc.org>
On Wed, Nov 5, 2014 at 10:02 PM, Denis Kirjanov <kda@linux-powerpc.org> wrote:
> Add BPF extension SKF_AD_HATYPE to ppc JIT to check
> the hw type of the interface
>
> JIT off:
> [ 69.106783] test_bpf: #20 LD_HATYPE 48 48 PASS
> JIT on:
> [ 64.721757] test_bpf: #20 LD_HATYPE 7 6 PASS
>
> CC: Alexei Starovoitov<alexei.starovoitov@gmail.com>
> CC: Daniel Borkmann<dborkman@redhat.com>
> CC: Philippe Bergheaud<felix@linux.vnet.ibm.com>
> Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
> ---
> arch/powerpc/net/bpf_jit_comp.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
> index d110e28..8bf4fc2 100644
> --- a/arch/powerpc/net/bpf_jit_comp.c
> +++ b/arch/powerpc/net/bpf_jit_comp.c
> @@ -412,6 +412,22 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
> PPC_ANDI(r_A, r_A, PKT_TYPE_MAX);
> PPC_SRWI(r_A, r_A, 5);
> break;
> + case BPF_ANC | SKF_AD_HATYPE:
> + BUILD_BUG_ON(FIELD_SIZEOF(struct net_device, type) != 2);
> + PPC_LD_OFFS(r_scratch1, r_skb, offsetof(struct sk_buff,
> + dev));
> + PPC_CMPDI(r_scratch1, 0);
> + if (ctx->pc_ret0 != -1) {
> + PPC_BCC(COND_EQ, addrs[ctx->pc_ret0]);
> + } else {
> + /* Exit, returning 0; first pass hits here. */
> + PPC_BCC_SHORT(COND_NE, (ctx->idx*4)+12);
please use canonical formatting ctx->idx * 4 + 12
> + PPC_LI(r_ret, 0);
> + PPC_JMP(exit_addr);
> + }
> + PPC_LHZ_OFFS(r_A, r_scratch1,
> + offsetof(struct net_device, type));
the whole thing looks like copy paste from 'case ifindex'.
Would be nice to handle them together to reduce
duplicated code, sine only last load is different.
Also in commit log please do _both_ runs with JIT on.
You should see a difference before/after applying this patch.
^ permalink raw reply
* [PATCH] drivers: atm: eni: Add pci_dma_mapping_error() call
From: Tina Johnson @ 2014-11-08 16:18 UTC (permalink / raw)
To: chas; +Cc: linux-atm-general, netdev, linux-kernel, julia.lawall,
Tina Johnson
Added a pci_dma_mapping_error() call to check for mapping errors before
further using the dma handle. Unchecked dma handles were found using
Coccinelle:
@rule1@
expression e1;
identifier x;
@@
*x = pci_map_single(...);
... when != pci_dma_mapping_error(e1,x)
Signed-off-by: Tina Johnson <tinajohnson.1234@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
---
drivers/atm/eni.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/atm/eni.c b/drivers/atm/eni.c
index d65975a..6450a36 100644
--- a/drivers/atm/eni.c
+++ b/drivers/atm/eni.c
@@ -356,6 +356,8 @@ static int do_rx_dma(struct atm_vcc *vcc,struct sk_buff *skb,
if (skb) {
paddr = pci_map_single(eni_dev->pci_dev,skb->data,skb->len,
PCI_DMA_FROMDEVICE);
+ if (pci_dma_mapping_error(eni_dev->pci_dev, paddr))
+ goto trouble;
ENI_PRV_PADDR(skb) = paddr;
if (paddr & 3)
printk(KERN_CRIT DEV_LABEL "(itf %d): VCI %d has "
--
1.7.10.4
^ permalink raw reply related
* alx can't send packet larger than 750 bytes
From: Konrad Mosoń @ 2014-11-08 16:06 UTC (permalink / raw)
To: netdev, nic-devel
Hello there,
I just submitted bug to bugzilla.redhat.com (not to mail kernel, cause i
didn't have problem on ArchLinux).
https://bugzilla.redhat.com/show_bug.cgi?id=1161861
Could be nice if you could look into it. It's kinda critical — network
just doesn't works.
Thanks for help,
Konrad Mosoń
PS
nic-devel@qca.qualcomm — sorry for doublemail but netdev@vger rejected
my mail at first time cause i used html.
^ permalink raw reply
* [PATCH 2/2] 8139too: Allow using the largest possible MTU
From: Alban Bedel @ 2014-11-08 11:48 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, Bjorn Helgaas, Benoit Taine, Eric W. Biederman,
David S. Miller, Alban Bedel
In-Reply-To: <1415447316-12424-1-git-send-email-albeu@free.fr>
This driver allows MTU up to 1518 bytes which is not enought to run
batman-adv. Simply raise the maximum packet size up to the maximum
allowed by the transmit descriptor, 1792 bytes, giving a maximum MTU
of 1774 bytes.
Signed-off-by: Alban Bedel <albeu@free.fr>
---
drivers/net/ethernet/realtek/8139too.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/8139too.c b/drivers/net/ethernet/realtek/8139too.c
index 8387de9..e157541 100644
--- a/drivers/net/ethernet/realtek/8139too.c
+++ b/drivers/net/ethernet/realtek/8139too.c
@@ -183,7 +183,7 @@ static int debug = -1;
#define NUM_TX_DESC 4
/* max supported ethernet frame size -- must be at least (dev->mtu+14+4).*/
-#define MAX_ETH_FRAME_SIZE 1536
+#define MAX_ETH_FRAME_SIZE 1792
/* max supported payload size */
#define MAX_ETH_DATA_SIZE (MAX_ETH_FRAME_SIZE - ETH_HLEN - ETH_FCS_LEN)
--
2.0.0
^ permalink raw reply related
* [PATCH 1/2] 8139too: Allow setting MTU larger than 1500
From: Alban Bedel @ 2014-11-08 11:48 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, Bjorn Helgaas, Benoit Taine, Eric W. Biederman,
David S. Miller, Alban Bedel
Replace the default ndo_change_mtu callback with one that allow
setting MTU that the driver can handle.
Signed-off-by: Alban Bedel <albeu@free.fr>
---
drivers/net/ethernet/realtek/8139too.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/8139too.c b/drivers/net/ethernet/realtek/8139too.c
index 007b38c..8387de9 100644
--- a/drivers/net/ethernet/realtek/8139too.c
+++ b/drivers/net/ethernet/realtek/8139too.c
@@ -185,6 +185,9 @@ static int debug = -1;
/* max supported ethernet frame size -- must be at least (dev->mtu+14+4).*/
#define MAX_ETH_FRAME_SIZE 1536
+/* max supported payload size */
+#define MAX_ETH_DATA_SIZE (MAX_ETH_FRAME_SIZE - ETH_HLEN - ETH_FCS_LEN)
+
/* Size of the Tx bounce buffers -- must be at least (dev->mtu+14+4). */
#define TX_BUF_SIZE MAX_ETH_FRAME_SIZE
#define TX_BUF_TOT_LEN (TX_BUF_SIZE * NUM_TX_DESC)
@@ -920,11 +923,19 @@ static int rtl8139_set_features(struct net_device *dev, netdev_features_t featur
return 0;
}
+static int rtl8139_change_mtu(struct net_device *dev, int new_mtu)
+{
+ if (new_mtu < 68 || new_mtu > MAX_ETH_DATA_SIZE)
+ return -EINVAL;
+ dev->mtu = new_mtu;
+ return 0;
+}
+
static const struct net_device_ops rtl8139_netdev_ops = {
.ndo_open = rtl8139_open,
.ndo_stop = rtl8139_close,
.ndo_get_stats64 = rtl8139_get_stats64,
- .ndo_change_mtu = eth_change_mtu,
+ .ndo_change_mtu = rtl8139_change_mtu,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_mac_address = rtl8139_set_mac_address,
.ndo_start_xmit = rtl8139_start_xmit,
--
2.0.0
^ permalink raw reply related
* Re: [PATCH] ipvs: Keep skb->sk when allocating headroom on tunnel xmit
From: Julian Anastasov @ 2014-11-08 6:16 UTC (permalink / raw)
To: Calvin Owens
Cc: Simon Horman, Wensong Zhang, lvs-devel, linux-kernel, netdev,
agartrell, kernel-team
In-Reply-To: <545D43BD.8030203@fb.com>
Hello,
On Fri, 7 Nov 2014, Calvin Owens wrote:
> On 11/05/2014 01:21 AM, Julian Anastasov wrote:
> >
> > Hello,
> >
> > On Tue, 4 Nov 2014, Calvin Owens wrote:
> >
> > > ip_vs_prepare_tunneled_skb() ignores ->sk when allocating a new
> > > skb, either unconditionally setting ->sk to NULL or allowing
> > > the uninitialized ->sk from a newly allocated skb to leak through
> > > to the caller.
> > >
> > > This patch properly copies ->sk and increments its reference count.
> > >
> > > Signed-off-by: Calvin Owens <calvinowens@fb.com>
> >
> > Good catch. Please, extend your patch to
> > fix also the second place that has such error,
> > ip_vs_tunnel_xmit_v6. This call is missing from long time,
> > it was not needed. But commits that allow skb->sk (local
> > clients) already need it, eg.
>
> I'm not sure where exactly you mean: ip_vs_tunnel_xmit_v6() calls
> ip_vs_prepare_tunneled_skb() to do the allocation, so this patch covers that
> case.
>
> In older versions of the kernel, ip_vs_tunnel_xmit_v6() does it directly,
> could that be what you're looking at?
Sorry, it seems I was checking old branch.
Simon, please apply.
Acked-by: Julian Anastasov <ja@ssi.bg>
> > - f2428ed5e7bc89c7 ("ipvs: load balance ipv6 connections from a local
> > process"), 2.6.28
> > - 4856c84c1358b798 ("ipvs: load balance IPv4 connections from a local
> > process"), 2.6.28
> >
> > > ---
> > > net/netfilter/ipvs/ip_vs_xmit.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/net/netfilter/ipvs/ip_vs_xmit.c
> > > b/net/netfilter/ipvs/ip_vs_xmit.c
> > > index 437a366..bd90bf8 100644
> > > --- a/net/netfilter/ipvs/ip_vs_xmit.c
> > > +++ b/net/netfilter/ipvs/ip_vs_xmit.c
> > > @@ -846,6 +846,8 @@ ip_vs_prepare_tunneled_skb(struct sk_buff *skb, int
> > > skb_af,
> > > new_skb = skb_realloc_headroom(skb, max_headroom);
> > > if (!new_skb)
> > > goto error;
> > > + if (skb->sk)
> > > + skb_set_owner_w(new_skb, skb->sk);
> > > consume_skb(skb);
> > > skb = new_skb;
> > > }
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* FROM Ms Faith Titi Attah
From: Ms Faith Titi Attah @ 2014-11-06 21:01 UTC (permalink / raw)
faithattah27@cantv.net
FROM Ms Faith Titi Attah
Dearest one
I wish you and your family happy moments of life
now and forever more amen.Please, I do not have formal relationship
with you but because of my present predicament and circumstances I am
made to contact you.I have been suffering from cancer of the Lungs and
has a short life to leave.I have made up my mind to donate my
inheritance of 21.5 million US to the less privileged please help me
to fulfill my last wish.please CONTACT ME TO MY EMAIL
faithattah27@cantv.net
Thanks CONTACT ME TO MY EMAIL faithattah27@cantv.net
Ms Faith Titi Attah
^ permalink raw reply
* Re: [ovs-discuss] kernel panic receiving flooded VXLAN traffic with OVS
From: Jay Vosburgh @ 2014-11-08 5:13 UTC (permalink / raw)
To: Pravin Shelar; +Cc: netdev, discuss-yBygre7rU0TnMu66kgdUjQ@public.gmane.org
In-Reply-To: <CALnjE+q1t0dbC6-EvxsQvvNafKsk2HNKXBjDrALA9S-gon68PQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Pravin Shelar <pshelar@nicira.com> wrote:
>On Fri, Nov 7, 2014 at 2:29 PM, Jesse Gross <jesse@nicira.com> wrote:
>> On Fri, Nov 7, 2014 at 1:13 PM, Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
>>> Jesse Gross <jesse@nicira.com> wrote:
>>>
>>>>On Fri, Nov 7, 2014 at 10:34 AM, Jesse Gross <jesse@nicira.com> wrote:
>>>>> On Fri, Nov 7, 2014 at 9:40 AM, Pravin Shelar <pshelar@nicira.com> wrote:
>>>>>> On Thu, Nov 6, 2014 at 5:58 PM, Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
>>> [...]
>>>>>>> I'm not sure if this is an error on the part of the RX / GRO
>>>>>>> processing in assembling the GRO skb, or in how OVS calls skb_segment.
>>>>>>>
>>>>>>
>>>>>> I think this is related skb_segment() issue where it is not able to
>>>>>> handle this type of skb geometry. We need to fix skb-segmentation. I
>>>>>> will investigate it more.
>>>>>
>>>>> One problem that I see is that vxlan_gro_complete() doesn't add
>>>>> SKB_GSO_UDP_TUNNEL to gso_type. This causes us to attempt
>>>>> fragmentation as UDP rather than continuing down to do TCP
>>>>> segmentation. That probably screws up the skb geometry.
>>>>
>>>>I sent out a patch to fix this issue. I'm pretty sure that it is the
>>>>root cause of the originally reported case but I don't have a good way
>>>>to reproduce it so it would be great if you could test it Jay.
>>>
>>> I'm having an issue there; when I set up my recreation on
>>> current net-next (3.18-rc2) without your new patch, I get the following
>>> oops when my ovs script does "ovs-vsctl --if-exists del-br br-ex":
>>
>> Hmm, that looks like a totally different problem. Pravin - any ideas?
>
>I am not able to reproduce with above command. Jay, Can you send me
>steps to reproduce this issue?
Well, at the moment a 3.18.0-rc2 kernel panics in
ovs_flow_tbl_insert as soon as ovs-vswitchd starts up. Booting to an
earlier kernel (3.17, for example) with no other changes doesn't panic.
I moved /etc/openvswitch/conf.db away and rebooted the system
(which I think will eliminate the stored configuration), and the kernel
still hits this oops when ovs-vswitchd starts up.
A bit of poking with crash
[ 22.180002] RIP: 0010:[<ffffffffa01a55ec>] [<ffffffffa01a55ec>] ovs_flow_tbl_insert+0xdc/0x1f0 [openvswitch]
[ 22.180002] RSP: 0018:ffff8801391a77a8 EFLAGS: 00010203
[ 22.180002] RAX: 00000000076cc6f1 RBX: ffff8800b35c2020 RCX: 00000000fb994f19
[ 22.180002] RDX: 000000009cc907e5 RSI: 00000000a490ff19 RDI: ffff8800b0c1c19c
[ 22.180002] RBP: ffff8801391a77f8 R08: 000000006867223a R09: 00000000819d92a7
[ 22.180002] R10: ffffffffa01a5696 R11: 0000000000000004 R12: ffff8800b35c2028
[ 22.180002] R13: ffff8801391a7850 R14: ffff8800b35c2028 R15: ffff880134827800
[ 22.180002] FS: 00007f0ef491a980(0000) GS:ffff88013fc80000(0000) knlGS:0000000000000000
0xffffffffa01a55e7 <ovs_flow_tbl_insert+0xd7>: callq 0xffffffff813a75c0 <__jhash2>
0xffffffffa01a55ec <ovs_flow_tbl_insert+0xdc>: mov %eax,0x30(%r8)
0xffffffffa01a55f0 <ovs_flow_tbl_insert+0xe0>: mov (%rbx),%r13
0xffffffffa01a55f3 <ovs_flow_tbl_insert+0xe3>: mov %r8,%rsi
0xffffffffa01a55f6 <ovs_flow_tbl_insert+0xe6>: mov %r13,%rdi
0xffffffffa01a55f9 <ovs_flow_tbl_insert+0xe9>: callq 0xffffffffa01a4ba0 <table_instance_insert>
So it panics on return from __jhash2 because %r8 is invalid;
this is presumably
int ovs_flow_tbl_insert(struct flow_table *table, struct sw_flow *flow,
struct sw_flow_mask *mask)
{
[...]
flow->hash = flow_hash(&flow->key, flow->mask->range.start,
flow->mask->range.end);
ti = ovsl_dereference(table->ti);
table_instance_insert(ti, flow);
Looking at __jash2, it uses %r8 internally, but %r8 doesn't
appear to be saved and restored either around the call to, or within,
__jhash2. In ovs_flow_tbl_insert %r8 appears to hold the "flow"
variable, so this panic might have nothing to do with ovs itself.
I'll have to look at this further on Monday.
-J
---
-Jay Vosburgh, jay.vosburgh@canonical.com
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
^ permalink raw reply
* Re: [PATCH net] udptunnel: Add SKB_GSO_UDP_TUNNEL during gro_complete.
From: Jesse Gross @ 2014-11-08 3:54 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: David Miller, netdev
In-Reply-To: <28743.1415411491@famine>
On Fri, Nov 7, 2014 at 5:51 PM, Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
> Jesse Gross <jesse@nicira.com> wrote:
>
>>When doing GRO processing for UDP tunnels, we never add
>>SKB_GSO_UDP_TUNNEL to gso_type - only the type of the inner protocol
>>is added (such as SKB_GSO_TCPV4). The result is that if the packet is
>>later resegmented we will do GSO but not treat it as a tunnel. This
>>results in UDP fragmentation and since that is not the original layout
>>of the skb, a panic in skb_segment().
>>
>>Reported-by: Jay Vosburgh <jay.vosburgh@canonical.com>
>>Signed-off-by: Jesse Gross <jesse@nicira.com>
>>---
>>This problem occurs back to 3.14 for VXLAN but the FOU portion needs to
>>be removed for kernels other than the 'net' tree.
>
> This patch does not resolve the problem when applied to a
> 3.17-ish kernel; the panic message is below, and appears to be
> unchanged.
Hmm, OK, thanks for testing. I think this patch is probably still good
to apply as it may solve a problem after we get this one figured out.
^ permalink raw reply
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: Herbert Xu @ 2014-11-08 2:21 UTC (permalink / raw)
To: Al Viro; +Cc: David Miller, netdev, linux-kernel, bcrl
In-Reply-To: <20141107234253.GE7996@ZenIV.linux.org.uk>
On Fri, Nov 07, 2014 at 11:42:53PM +0000, Al Viro wrote:
> I'll finish RTFS drivers/vhost and if it turns out to be OK I'll post the
> series moving those checks to the moment of copying iovec from userland,
> so that kernel-side we could always rely on ->msg_iov elements having been
> verified.
Great thanks!
Dave, please hold off on my skb_copy_datagram_iter series until
this verify_iovec change is added.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH net] udptunnel: Add SKB_GSO_UDP_TUNNEL during gro_complete.
From: Jay Vosburgh @ 2014-11-08 1:51 UTC (permalink / raw)
To: Jesse Gross; +Cc: David Miller, netdev
In-Reply-To: <1415391969-108511-1-git-send-email-jesse@nicira.com>
Jesse Gross <jesse@nicira.com> wrote:
>When doing GRO processing for UDP tunnels, we never add
>SKB_GSO_UDP_TUNNEL to gso_type - only the type of the inner protocol
>is added (such as SKB_GSO_TCPV4). The result is that if the packet is
>later resegmented we will do GSO but not treat it as a tunnel. This
>results in UDP fragmentation and since that is not the original layout
>of the skb, a panic in skb_segment().
>
>Reported-by: Jay Vosburgh <jay.vosburgh@canonical.com>
>Signed-off-by: Jesse Gross <jesse@nicira.com>
>---
>This problem occurs back to 3.14 for VXLAN but the FOU portion needs to
>be removed for kernels other than the 'net' tree.
This patch does not resolve the problem when applied to a
3.17-ish kernel; the panic message is below, and appears to be
unchanged.
-J
[ 146.960891] kernel BUG at net/core/skbuff.c:3011!
[ 146.960891] invalid opcode: 0000 [#1] SMP
[ 146.960891] Modules linked in: veth 8021q garp mrp bonding xt_tcpudp bridge s
tp llc iptable_filter ip_tables x_tables openvswitch vxlan udp_tunnel gre libcrc
32c i915 video drm_kms_helper coretemp kvm_intel drm kvm gpio_ich serio_raw i2c_
algo_bit ppdev lpc_ich parport_pc lp parport mac_hid hid_generic usbhid hid psmo
use r8169 mii sky2
[ 146.960891] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0-rc7 #11
[ 146.960891] Hardware name: LENOVO 0829F3U/To be filled by O.E.M., BIOS 90KT15
AUS 07/21/2010
[ 146.960891] task: ffffffff81c1d480 ti: ffffffff81c00000 task.ti: ffffffff81c0
0000
[ 146.960891] RIP: 0010:[<ffffffff816117d2>] [<ffffffff816117d2>] skb_segment+
0x962/0x990
[ 146.960891] RSP: 0018:ffff88013fc03908 EFLAGS: 00010216
[ 146.960891] RAX: 00000000000002dc RBX: ffff8800a62f0a00 RCX: ffff88003215e4f0
[ 146.960891] RDX: 0000000000000074 RSI: ffff88003215e400 RDI: ffff88003215f800
[ 146.960891] RBP: ffff88013fc039d0 R08: 0000000000000022 R09: 0000000000000000
[ 146.960891] R10: ffff8800a62f0b00 R11: 00000000000005ca R12: ffff88003215f8f0
[ 146.960891] R13: 0000000000000000 R14: ffff8800320e4100 R15: 0000000000000074
[ 146.960891] FS: 0000000000000000(0000) GS:ffff88013fc00000(0000) knlGS:00000
00000000000
[ 146.960891] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 146.960891] CR2: 000000000218c818 CR3: 00000000b1e4e000 CR4: 00000000000407f0
[ 146.960891] Stack:
[ 146.960891] ffff8800320e4c00 ffffffffffffffde ffff8800000005ca 0000000000000
022
[ 146.960891] 0000000000000040 ffff8800a62f0b00 00000001000005a8 0000000000000
000
[ 146.960891] 0000000000000022 00000000000005a8 ffff8800a62f0a00 ffff88003215e
4f0
[ 146.960891] Call Trace:
[ 146.960891] <IRQ>
[ 146.960891] [<ffffffff81686612>] udp4_ufo_fragment+0xc2/0x130
[ 146.960891] [<ffffffff8168f372>] inet_gso_segment+0x132/0x360
[ 146.960891] [<ffffffff8161fbe6>] ? dev_hard_start_xmit+0x316/0x5c0
[ 146.960891] [<ffffffff8161f5cb>] skb_mac_gso_segment+0x9b/0x170
[ 146.960891] [<ffffffff8161f700>] __skb_gso_segment+0x60/0xc0
[ 147.148004] [<ffffffffa01a7231>] queue_gso_packets+0x41/0x1b0 [openvswitch]
[ 147.148004] [<ffffffff81616ab3>] ? skb_flow_dissect+0x173/0x430
[ 147.148004] [<ffffffff81616d90>] ? __skb_get_hash+0x20/0x140
[ 147.148004] [<ffffffffa01a7c6e>] ovs_dp_upcall+0x2e/0x70 [openvswitch] [ 147.148004] [<ffffffffa01a7d9e>] ovs_dp_process_received_packet+0xee/0x110 [
openvswitch]
[ 147.148004] [<ffffffffa01adaea>] ovs_vport_receive+0x2a/0x30 [openvswitch]
[ 147.148004] [<ffffffffa01ae381>] netdev_frame_hook+0xc1/0x120 [openvswitch]
[ 147.148004] [<ffffffff8161daf2>] __netif_receive_skb_core+0x1b2/0x790
[ 147.148004] [<ffffffff8161e0e8>] __netif_receive_skb+0x18/0x60
[ 147.148004] [<ffffffff8161e153>] netif_receive_skb_internal+0x23/0x90
[ 147.148004] [<ffffffff81685e5b>] ? udp_gro_complete+0x5b/0x70
[ 147.148004] [<ffffffff8161e2d4>] napi_gro_complete+0xa4/0xe0
[ 147.148004] [<ffffffff8161e82f>] dev_gro_receive+0x1ef/0x2f0
[ 147.148004] [<ffffffff8161ec1c>] napi_gro_receive+0x2c/0xf0
[ 147.148004] [<ffffffffa001f28f>] sky2_poll+0x78f/0xd70 [sky2]
[ 147.148004] [<ffffffff8161e542>] net_rx_action+0x152/0x250
[ 147.148004] [<ffffffff81070925>] __do_softirq+0xf5/0x2e0
[ 147.148004] [<ffffffff81070de5>] irq_exit+0x105/0x110
[ 147.148004] [<ffffffff81724a78>] do_IRQ+0x58/0xf0
[ 147.148004] [<ffffffff817228ed>] common_interrupt+0x6d/0x6d
[ 147.148004] <EOI>
[ 147.148004] [<ffffffff810c9578>] ? rcu_nocb_kthread+0x158/0x510
[ 147.148004] [<ffffffff81055056>] ? native_safe_halt+0x6/0x10
[ 147.148004] [<ffffffff8101d1af>] default_idle+0x1f/0xc0
[ 147.148004] [<ffffffff8101db1f>] arch_cpu_idle+0xf/0x20
[ 147.148004] [<ffffffff810aadcd>] cpu_startup_entry+0x30d/0x340
[ 147.148004] [<ffffffff8170b307>] rest_init+0x77/0x80
[ 147.148004] [<ffffffff81d37084>] start_kernel+0x42f/0x43a
[ 147.148004] [<ffffffff81d36a4e>] ? set_init_arg+0x53/0x53
[ 147.148004] [<ffffffff81d36120>] ? early_idt_handlers+0x120/0x120
[ 147.148004] [<ffffffff81d365ee>] x86_64_start_reservations+0x2a/0x2c
[ 147.148004] [<ffffffff81d36733>] x86_64_start_kernel+0x143/0x152
[ 147.148004] Code: 24 70 4c 8b 54 24 58 44 8b 44 24 68 44 8b 4c 24 28 48 8b 4c
24 10 44 8b 5c 24 04 8b 14 24 0f 85 19 fd ff ff e9 10 fd ff ff 0f 0b <0f> 0b 0f
0b c6 44 24 33 01 e9 92 f7 ff ff e8 33 ad 10 00 0f 0b
[ 147.148004] RIP [<ffffffff816117d2>] skb_segment+0x962/0x990
[ 147.148004] RSP <ffff88013fc03908>
> drivers/net/vxlan.c | 2 ++
> include/net/udp_tunnel.h | 9 +++++++++
> net/ipv4/fou.c | 2 ++
> 3 files changed, 13 insertions(+)
>
>diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
>index ca30982..cfb892b 100644
>--- a/drivers/net/vxlan.c
>+++ b/drivers/net/vxlan.c
>@@ -621,6 +621,8 @@ static int vxlan_gro_complete(struct sk_buff *skb, int nhoff)
> int vxlan_len = sizeof(struct vxlanhdr) + sizeof(struct ethhdr);
> int err = -ENOSYS;
>
>+ udp_tunnel_gro_complete(skb, nhoff);
>+
> eh = (struct ethhdr *)(skb->data + nhoff + sizeof(struct vxlanhdr));
> type = eh->h_proto;
>
>diff --git a/include/net/udp_tunnel.h b/include/net/udp_tunnel.h
>index a47790b..2a50a70 100644
>--- a/include/net/udp_tunnel.h
>+++ b/include/net/udp_tunnel.h
>@@ -100,6 +100,15 @@ static inline struct sk_buff *udp_tunnel_handle_offloads(struct sk_buff *skb,
> return iptunnel_handle_offloads(skb, udp_csum, type);
> }
>
>+static inline void udp_tunnel_gro_complete(struct sk_buff *skb, int nhoff)
>+{
>+ struct udphdr *uh;
>+
>+ uh = (struct udphdr *)(skb->data + nhoff - sizeof(struct udphdr));
>+ skb_shinfo(skb)->gso_type |= uh->check ?
>+ SKB_GSO_UDP_TUNNEL_CSUM : SKB_GSO_UDP_TUNNEL;
>+}
>+
> static inline void udp_tunnel_encap_enable(struct socket *sock)
> {
> #if IS_ENABLED(CONFIG_IPV6)
>diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
>index 32e7892..606c520 100644
>--- a/net/ipv4/fou.c
>+++ b/net/ipv4/fou.c
>@@ -133,6 +133,8 @@ static int fou_gro_complete(struct sk_buff *skb, int nhoff)
> int err = -ENOSYS;
> const struct net_offload **offloads;
>
>+ udp_tunnel_gro_complete(skb, nhoff);
>+
> rcu_read_lock();
> offloads = NAPI_GRO_CB(skb)->is_ipv6 ? inet6_offloads : inet_offloads;
> ops = rcu_dereference(offloads[proto]);
>--
>1.9.1
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* Re: [PATCH net 3/5] fm10k: Implement ndo_gso_check()
From: Vick, Matthew @ 2014-11-08 0:51 UTC (permalink / raw)
To: Joe Stringer
Cc: alexander.duyck@gmail.com, netdev@vger.kernel.org,
Dept-GELinuxNICDev@qlogic.com, linux-kernel@vger.kernel.org,
sathya.perla@emulex.com, Kirsher, Jeffrey T, Linux NICS,
amirv@mellanox.com, shahed.shaikh@qlogic.com, therbert@google.com,
Or Gerlitz
In-Reply-To: <201411071435.56628.joestringer@nicira.com>
On 11/7/14, 2:35 PM, "Joe Stringer" <joestringer@nicira.com> wrote:
>Sure, I think fm10k_tx_encap_offload() is a good place for the header
>length
>check. Separately, my question above was regarding the idea of a helper
>for
>SKB_GSO_{GRE,UDP_TUNNEL}. The only reason it might be useful for the
>fm10k
>driver is because all encap is checked in the fm10k_tx_encap_offload()
>function.
>Other drivers don't seem to handle different tunnels together like this
>though,
>so I'm inclined to stick with the below for now.
>
>
>static bool fm10k_gso_check(struct sk_buff *skb, struct net_device *dev)
>
>{
>
> return (!(skb_shinfo(skb)->gso_type &
>
> (SKB_GSO_UDP_TUNNEL | SKB_GSO_GRE)) ||
>
> fm10k_tx_encap_offload(skb));
>
>}
>
>Cheers,
>Joe
I agree. I think that makes the most sense.
Cheers,
Matthew
^ permalink raw reply
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: Al Viro @ 2014-11-07 23:42 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev, linux-kernel, bcrl
In-Reply-To: <20141107221114.GB7996@ZenIV.linux.org.uk>
On Fri, Nov 07, 2014 at 10:11:14PM +0000, Al Viro wrote:
> I'm looking through the tree right now; so far it looks like we can just
> move those suckers to the point where we validate iovec and lose them
> from low-level iovec and csum copying completely. I still haven't finished
> tracing all possible paths for address to arrive at the points where we
> currently check that stuff, but so far it looks very doable.
Definitely doable. The only remaining interesting part is drivers/vhost
with the stuff it puts in vq->iov[]. If we can guarantee that it satisfies
the sanity checks (access_ok() and size-related ones), we are done -
making verify_iovec() use rw_copy_check_uvector() (and verify_compat_iov()
use compat_rw_copy_check_uvector()) will suffice to guarantee that none of
csum_partial_copy_fromiovecend
memcpy_fromiovec
memcpy_toiovec
memcpy_toiovecend
memcpy_fromiovecend
skb_copy_datagram_iovec
skb_copy_datagram_iter
skb_copy_datagram_from_iter
zerocopy_sg_from_iter
skb_copy_and_csum_datagram
skb_copy_and_csum_datagram_iovec
csum_and_copy_from_user
csum_and_copy_to_user
csum_partial_copy_from_user
will ever see an address that doesn't satisfy access_ok() checks. And
having looked at the data flow... we definitely want to do those checks
on intake of iovec - as it is, we usually repeat them quite a few times
for the same iovec segment, and we practically never end up _not_ doing them
for some segment of iovec, unless we hit a failure exit before we get around
to copying any data at all.
I'll finish RTFS drivers/vhost and if it turns out to be OK I'll post the
series moving those checks to the moment of copying iovec from userland,
so that kernel-side we could always rely on ->msg_iov elements having been
verified.
^ permalink raw reply
* [PATCH net] cxgb4 : Fix bug in DCB app deletion
From: Anish Bhatt @ 2014-11-07 23:41 UTC (permalink / raw)
To: netdev; +Cc: davem, hariprasad, leedom, Anish Bhatt
Unlike CEE, IEEE has a bespoke app delete call and does not rely on priority
for app deletion
Fixes : 2376c879b80c ('cxgb4 : Improve handling of DCB negotiation or loss
thereof')
Signed-off-by: Anish Bhatt <anish@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c
index 6fe300e..b6fdb14 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c
@@ -79,8 +79,9 @@ static void cxgb4_dcb_cleanup_apps(struct net_device *dev)
app.protocol = dcb->app_priority[i].protocolid;
if (dcb->dcb_version == FW_PORT_DCB_VER_IEEE) {
+ app.priority = dcb->app_priority[i].user_prio_map;
app.selector = dcb->app_priority[i].sel_field + 1;
- err = dcb_ieee_setapp(dev, &app);
+ err = dcb_ieee_delapp(dev, &app);
} else {
app.selector = !!(dcb->app_priority[i].sel_field);
err = dcb_setapp(dev, &app);
--
2.1.3
^ permalink raw reply related
* Re: [PATCH net-next] net: introduce SO_INCOMING_CPU
From: Eric Dumazet @ 2014-11-07 23:26 UTC (permalink / raw)
To: Tom Herbert
Cc: David Miller, netdev, Ying Cai, Willem de Bruijn, Neal Cardwell
In-Reply-To: <CA+mtBx9kpW8Q4HgTyNE+O4yPRmMcOgjshrBfZXVnPu=EMVh4Qg@mail.gmail.com>
On Fri, 2014-11-07 at 15:02 -0800, Tom Herbert wrote:
> Would it be better to get the incoming CPU before packet steering? Or
> maybe return this in addition to the CPU where ULP processes packet?
No packet steering : RFS is off.
If for some reason RPS is on (say NIC has a limited number of RX queues)
we'd like to have the cpu processing the packet in TCP stack for better
affinities.
^ permalink raw reply
* Re: kernel panic receiving flooded VXLAN traffic with OVS
From: Pravin Shelar @ 2014-11-07 23:06 UTC (permalink / raw)
To: Jesse Gross; +Cc: Jay Vosburgh, netdev, discuss@openvswitch.org
In-Reply-To: <CAEP_g=9gWZYtWGiF-JbVwmesa1n7FXYEJSQKdZi3L_yhPGPkAA@mail.gmail.com>
On Fri, Nov 7, 2014 at 2:29 PM, Jesse Gross <jesse@nicira.com> wrote:
> On Fri, Nov 7, 2014 at 1:13 PM, Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
>> Jesse Gross <jesse@nicira.com> wrote:
>>
>>>On Fri, Nov 7, 2014 at 10:34 AM, Jesse Gross <jesse@nicira.com> wrote:
>>>> On Fri, Nov 7, 2014 at 9:40 AM, Pravin Shelar <pshelar@nicira.com> wrote:
>>>>> On Thu, Nov 6, 2014 at 5:58 PM, Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
>> [...]
>>>>>> I'm not sure if this is an error on the part of the RX / GRO
>>>>>> processing in assembling the GRO skb, or in how OVS calls skb_segment.
>>>>>>
>>>>>
>>>>> I think this is related skb_segment() issue where it is not able to
>>>>> handle this type of skb geometry. We need to fix skb-segmentation. I
>>>>> will investigate it more.
>>>>
>>>> One problem that I see is that vxlan_gro_complete() doesn't add
>>>> SKB_GSO_UDP_TUNNEL to gso_type. This causes us to attempt
>>>> fragmentation as UDP rather than continuing down to do TCP
>>>> segmentation. That probably screws up the skb geometry.
>>>
>>>I sent out a patch to fix this issue. I'm pretty sure that it is the
>>>root cause of the originally reported case but I don't have a good way
>>>to reproduce it so it would be great if you could test it Jay.
>>
>> I'm having an issue there; when I set up my recreation on
>> current net-next (3.18-rc2) without your new patch, I get the following
>> oops when my ovs script does "ovs-vsctl --if-exists del-br br-ex":
>
> Hmm, that looks like a totally different problem. Pravin - any ideas?
I am not able to reproduce with above command. Jay, Can you send me
steps to reproduce this issue?
Thanks,
Pravin.
^ permalink raw reply
* Re: [net-next 1/9] i40e: poll firmware slower
From: Jesse Brandeburg @ 2014-11-07 23:02 UTC (permalink / raw)
To: Or Gerlitz
Cc: Jeff Kirsher, David Miller, Kamil Krawczyk, Linux Netdev List,
nhorman, sassmann, jogreene, jesse.brandeburg
In-Reply-To: <CAJ3xEMghFwT8Tm9wONzLPL4MLvgL+3w=CNRNg0Hb=yGJ9uR0Mg@mail.gmail.com>
On Fri, 7 Nov 2014 15:29:15 +0200
Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Fri, Nov 7, 2014 at 10:57 AM, Jeff Kirsher
> <jeffrey.t.kirsher@intel.com> wrote:
> > The code was polling the firmware tail register for completion
>
> any reason not to sleep while waiting for this completion? can the
> firmware generate an interrupt?
The code path in question is called from the drivers when they are in
a synchronous context and can sleep or be rescheduled without issue.
An async mode is possible, but not here, because the code complexity
required to change to async mode is unmaintainable (if even doable, how
do you handle an interrupt while you're in probe?). We use async when
it is practical.
Thanks for your comments,
Jesse
^ permalink raw reply
* Re: [PATCH net-next] net: introduce SO_INCOMING_CPU
From: Tom Herbert @ 2014-11-07 23:02 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Ying Cai, Willem de Bruijn, Neal Cardwell
In-Reply-To: <1415393472.13896.119.camel@edumazet-glaptop2.roam.corp.google.com>
On Fri, Nov 7, 2014 at 12:51 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Alternative to RPS/RFS is to use hardware support for multi queue.
>
> Then split a set of million of sockets into worker threads, each
> one using epoll() to manage events on its own socket pool.
>
> Ideally, we want one thread per RX/TX queue/cpu, but we have no way to
> know after accept() or connect() on which queue/cpu a socket is managed.
>
> We normally use one cpu per RX queue (IRQ smp_affinity being properly
> set), so remembering on socket structure which cpu delivered last packet
> is enough to solve the problem.
>
> After accept(), connect(), or even file descriptor passing around
> processes, applications can use :
>
> int cpu;
> socklen_t len = sizeof(cpu);
>
> getsockopt(fd, SOL_SOCKET, SO_INCOMING_CPU, &cpu, &len);
>
> And use this information to put the socket into the right silo
> for optimal performance, as all networking stack should run
> on the appropriate cpu, without need to send IPI (RPS/RFS).
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> arch/alpha/include/uapi/asm/socket.h | 2 ++
> arch/avr32/include/uapi/asm/socket.h | 2 ++
> arch/cris/include/uapi/asm/socket.h | 2 ++
> arch/frv/include/uapi/asm/socket.h | 2 ++
> arch/ia64/include/uapi/asm/socket.h | 2 ++
> arch/m32r/include/uapi/asm/socket.h | 2 ++
> arch/mips/include/uapi/asm/socket.h | 2 ++
> arch/mn10300/include/uapi/asm/socket.h | 2 ++
> arch/parisc/include/uapi/asm/socket.h | 2 ++
> arch/powerpc/include/uapi/asm/socket.h | 2 ++
> arch/s390/include/uapi/asm/socket.h | 2 ++
> arch/sparc/include/uapi/asm/socket.h | 2 ++
> arch/xtensa/include/uapi/asm/socket.h | 2 ++
> include/net/sock.h | 12 ++++++++++++
> include/uapi/asm-generic/socket.h | 2 ++
> net/core/sock.c | 5 +++++
> net/ipv4/tcp_ipv4.c | 1 +
> net/ipv4/udp.c | 1 +
> net/ipv6/tcp_ipv6.c | 1 +
> net/ipv6/udp.c | 1 +
> net/sctp/ulpqueue.c | 5 +++--
> 21 files changed, 52 insertions(+), 2 deletions(-)
>
> diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h
> index 3de1394bcab821984674e89a3ee022cc6dd5f0f2..e2fe0700b3b442bffc1f606b1b8b0bb7759aa157 100644
> --- a/arch/alpha/include/uapi/asm/socket.h
> +++ b/arch/alpha/include/uapi/asm/socket.h
> @@ -87,4 +87,6 @@
>
> #define SO_BPF_EXTENSIONS 48
>
> +#define SO_INCOMING_CPU 49
> +
> #endif /* _UAPI_ASM_SOCKET_H */
> diff --git a/arch/avr32/include/uapi/asm/socket.h b/arch/avr32/include/uapi/asm/socket.h
> index 6e6cd159924b1855aa5f1811ad4e4c60b403c431..92121b0f5b989a61c008e0be24030725bab88e36 100644
> --- a/arch/avr32/include/uapi/asm/socket.h
> +++ b/arch/avr32/include/uapi/asm/socket.h
> @@ -80,4 +80,6 @@
>
> #define SO_BPF_EXTENSIONS 48
>
> +#define SO_INCOMING_CPU 49
> +
> #endif /* _UAPI__ASM_AVR32_SOCKET_H */
> diff --git a/arch/cris/include/uapi/asm/socket.h b/arch/cris/include/uapi/asm/socket.h
> index ed94e5ed0a238c2750e677ccb806a6bc0a94041a..60f60f5b9b35bd219d7a9834fe5394e8ac5fdbab 100644
> --- a/arch/cris/include/uapi/asm/socket.h
> +++ b/arch/cris/include/uapi/asm/socket.h
> @@ -82,6 +82,8 @@
>
> #define SO_BPF_EXTENSIONS 48
>
> +#define SO_INCOMING_CPU 49
> +
> #endif /* _ASM_SOCKET_H */
>
>
> diff --git a/arch/frv/include/uapi/asm/socket.h b/arch/frv/include/uapi/asm/socket.h
> index ca2c6e6f31c6817780d31a246652adcc9847e373..2c6890209ea60c149bf097c2a1b369519cb8c301 100644
> --- a/arch/frv/include/uapi/asm/socket.h
> +++ b/arch/frv/include/uapi/asm/socket.h
> @@ -80,5 +80,7 @@
>
> #define SO_BPF_EXTENSIONS 48
>
> +#define SO_INCOMING_CPU 49
> +
> #endif /* _ASM_SOCKET_H */
>
> diff --git a/arch/ia64/include/uapi/asm/socket.h b/arch/ia64/include/uapi/asm/socket.h
> index a1b49bac7951929127ed08db549218c2c16ccf89..09a93fb566f6c6c6fe29c10c95b931881843d1cd 100644
> --- a/arch/ia64/include/uapi/asm/socket.h
> +++ b/arch/ia64/include/uapi/asm/socket.h
> @@ -89,4 +89,6 @@
>
> #define SO_BPF_EXTENSIONS 48
>
> +#define SO_INCOMING_CPU 49
> +
> #endif /* _ASM_IA64_SOCKET_H */
> diff --git a/arch/m32r/include/uapi/asm/socket.h b/arch/m32r/include/uapi/asm/socket.h
> index 6c9a24b3aefa3a4f3048c17a7fa06d97b585ec14..e8589819c2743c6e112b15a245fc3ebd146e6313 100644
> --- a/arch/m32r/include/uapi/asm/socket.h
> +++ b/arch/m32r/include/uapi/asm/socket.h
> @@ -80,4 +80,6 @@
>
> #define SO_BPF_EXTENSIONS 48
>
> +#define SO_INCOMING_CPU 49
> +
> #endif /* _ASM_M32R_SOCKET_H */
> diff --git a/arch/mips/include/uapi/asm/socket.h b/arch/mips/include/uapi/asm/socket.h
> index a14baa218c76f14de988ef106bdac5dadc48aceb..2e9ee8c55a103a0337d9f80f71fe9ef28be1154b 100644
> --- a/arch/mips/include/uapi/asm/socket.h
> +++ b/arch/mips/include/uapi/asm/socket.h
> @@ -98,4 +98,6 @@
>
> #define SO_BPF_EXTENSIONS 48
>
> +#define SO_INCOMING_CPU 49
> +
> #endif /* _UAPI_ASM_SOCKET_H */
> diff --git a/arch/mn10300/include/uapi/asm/socket.h b/arch/mn10300/include/uapi/asm/socket.h
> index 6aa3ce1854aa9523d46bc28851eddabd59edeb37..f3492e8c9f7009c33e07168df916f7337bef3929 100644
> --- a/arch/mn10300/include/uapi/asm/socket.h
> +++ b/arch/mn10300/include/uapi/asm/socket.h
> @@ -80,4 +80,6 @@
>
> #define SO_BPF_EXTENSIONS 48
>
> +#define SO_INCOMING_CPU 49
> +
> #endif /* _ASM_SOCKET_H */
> diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h
> index fe35ceacf0e72cad69a43d9b1ce7b8f5ec3da98a..7984a1cab3da980f1f810827967b4b67616eb89b 100644
> --- a/arch/parisc/include/uapi/asm/socket.h
> +++ b/arch/parisc/include/uapi/asm/socket.h
> @@ -79,4 +79,6 @@
>
> #define SO_BPF_EXTENSIONS 0x4029
>
> +#define SO_INCOMING_CPU 0x402A
> +
> #endif /* _UAPI_ASM_SOCKET_H */
> diff --git a/arch/powerpc/include/uapi/asm/socket.h b/arch/powerpc/include/uapi/asm/socket.h
> index a9c3e2e18c054a1e952fe33599401de57c6a6544..3474e4ef166df4a573773916b325d0fa9f3b45d0 100644
> --- a/arch/powerpc/include/uapi/asm/socket.h
> +++ b/arch/powerpc/include/uapi/asm/socket.h
> @@ -87,4 +87,6 @@
>
> #define SO_BPF_EXTENSIONS 48
>
> +#define SO_INCOMING_CPU 49
> +
> #endif /* _ASM_POWERPC_SOCKET_H */
> diff --git a/arch/s390/include/uapi/asm/socket.h b/arch/s390/include/uapi/asm/socket.h
> index e031332096d7c7b23b5953680289e8f3bcc3b378..8457636c33e1b67a9b7804daa05627839035a8fb 100644
> --- a/arch/s390/include/uapi/asm/socket.h
> +++ b/arch/s390/include/uapi/asm/socket.h
> @@ -86,4 +86,6 @@
>
> #define SO_BPF_EXTENSIONS 48
>
> +#define SO_INCOMING_CPU 49
> +
> #endif /* _ASM_SOCKET_H */
> diff --git a/arch/sparc/include/uapi/asm/socket.h b/arch/sparc/include/uapi/asm/socket.h
> index 54d9608681b6947ae25dab008f808841d96125c0..4a8003a9416348006cfa85d5bcdf7553c8d23958 100644
> --- a/arch/sparc/include/uapi/asm/socket.h
> +++ b/arch/sparc/include/uapi/asm/socket.h
> @@ -76,6 +76,8 @@
>
> #define SO_BPF_EXTENSIONS 0x0032
>
> +#define SO_INCOMING_CPU 0x0033
> +
> /* Security levels - as per NRL IPv6 - don't actually do anything */
> #define SO_SECURITY_AUTHENTICATION 0x5001
> #define SO_SECURITY_ENCRYPTION_TRANSPORT 0x5002
> diff --git a/arch/xtensa/include/uapi/asm/socket.h b/arch/xtensa/include/uapi/asm/socket.h
> index 39acec0cf0b1d500c1c40f9b523ef3a9a142c2f1..c46f6a696849c6f7f8a34b2cc522b48e04b17380 100644
> --- a/arch/xtensa/include/uapi/asm/socket.h
> +++ b/arch/xtensa/include/uapi/asm/socket.h
> @@ -91,4 +91,6 @@
>
> #define SO_BPF_EXTENSIONS 48
>
> +#define SO_INCOMING_CPU 49
> +
> #endif /* _XTENSA_SOCKET_H */
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 6767d75ecb17693eb59a99b8218da4319854ccc0..7789b59c0c400eb99f65d1f0e03cd9773664cf93 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -273,6 +273,7 @@ struct cg_proto;
> * @sk_rcvtimeo: %SO_RCVTIMEO setting
> * @sk_sndtimeo: %SO_SNDTIMEO setting
> * @sk_rxhash: flow hash received from netif layer
> + * @sk_incoming_cpu: record cpu processing incoming packets
> * @sk_txhash: computed flow hash for use on transmit
> * @sk_filter: socket filtering instructions
> * @sk_protinfo: private area, net family specific, when not using slab
> @@ -350,6 +351,12 @@ struct sock {
> #ifdef CONFIG_RPS
> __u32 sk_rxhash;
> #endif
> + u16 sk_incoming_cpu;
> + /* 16bit hole
> + * Warned : sk_incoming_cpu can be set from softirq,
> + * Do not use this hole without fully understanding possible issues.
> + */
> +
> __u32 sk_txhash;
> #ifdef CONFIG_NET_RX_BUSY_POLL
> unsigned int sk_napi_id;
> @@ -833,6 +840,11 @@ static inline int sk_backlog_rcv(struct sock *sk, struct sk_buff *skb)
> return sk->sk_backlog_rcv(sk, skb);
> }
>
> +static inline void sk_incoming_cpu_update(struct sock *sk)
> +{
> + sk->sk_incoming_cpu = raw_smp_processor_id();
> +}
> +
> static inline void sock_rps_record_flow_hash(__u32 hash)
> {
> #ifdef CONFIG_RPS
> diff --git a/include/uapi/asm-generic/socket.h b/include/uapi/asm-generic/socket.h
> index ea0796bdcf88404ef0f127eb6e64ba00c16ea856..f541ccefd4acbeb4ad757be9dbf4b67f204bf21d 100644
> --- a/include/uapi/asm-generic/socket.h
> +++ b/include/uapi/asm-generic/socket.h
> @@ -82,4 +82,6 @@
>
> #define SO_BPF_EXTENSIONS 48
>
> +#define SO_INCOMING_CPU 49
> +
> #endif /* __ASM_GENERIC_SOCKET_H */
> diff --git a/net/core/sock.c b/net/core/sock.c
> index ac56dd06c306f3712e57ce8e4724c79565589499..0725cf0cb685787b2122606437da53299fb24621 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -1213,6 +1213,10 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
> v.val = sk->sk_max_pacing_rate;
> break;
>
> + case SO_INCOMING_CPU:
> + v.val = sk->sk_incoming_cpu;
> + break;
> +
> default:
> return -ENOPROTOOPT;
> }
> @@ -1517,6 +1521,7 @@ struct sock *sk_clone_lock(const struct sock *sk, const gfp_t priority)
>
> newsk->sk_err = 0;
> newsk->sk_priority = 0;
> + newsk->sk_incoming_cpu = raw_smp_processor_id();
> /*
> * Before updating sk_refcnt, we must commit prior changes to memory
> * (Documentation/RCU/rculist_nulls.txt for details)
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index 9c7d7621466b1241f404a5ca11de809dcff2d02a..3893f51972f28271a6d27a763c05495c5c2554f7 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -1662,6 +1662,7 @@ process:
> goto discard_and_relse;
>
> sk_mark_napi_id(sk, skb);
> + sk_incoming_cpu_update(sk);
Would it be better to get the incoming CPU before packet steering? Or
maybe return this in addition to the CPU where ULP processes packet?
> skb->dev = NULL;
>
> bh_lock_sock_nested(sk);
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index df19027f44f3d6fbe13dec78d3b085968dbf2329..f52b6081158e87caa5df32e8e5d27dbf314a01b1 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1445,6 +1445,7 @@ static int __udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
> if (inet_sk(sk)->inet_daddr) {
> sock_rps_save_rxhash(sk, skb);
> sk_mark_napi_id(sk, skb);
> + sk_incoming_cpu_update(sk);
> }
>
> rc = sock_queue_rcv_skb(sk, skb);
> diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
> index ace29b60813cf8a1d7182ad2262cbcbd21810fa7..ac40d23204b5e55da5172c80dafd1d4854b370d5 100644
> --- a/net/ipv6/tcp_ipv6.c
> +++ b/net/ipv6/tcp_ipv6.c
> @@ -1455,6 +1455,7 @@ process:
> goto discard_and_relse;
>
> sk_mark_napi_id(sk, skb);
> + sk_incoming_cpu_update(sk);
> skb->dev = NULL;
>
> bh_lock_sock_nested(sk);
> diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
> index 9b6809232b178c16d699ce3d152196b8c4cb096b..0125ca3daf47a4a3333e7462a11550d3e2f96875 100644
> --- a/net/ipv6/udp.c
> +++ b/net/ipv6/udp.c
> @@ -577,6 +577,7 @@ static int __udpv6_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
> if (!ipv6_addr_any(&sk->sk_v6_daddr)) {
> sock_rps_save_rxhash(sk, skb);
> sk_mark_napi_id(sk, skb);
> + sk_incoming_cpu_update(sk);
> }
>
> rc = sock_queue_rcv_skb(sk, skb);
> diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
> index d49dc2ed30adb97a809eb37902b9956c366a2862..ce469d648ffbe166f9ae1c5650f481256f31a7f8 100644
> --- a/net/sctp/ulpqueue.c
> +++ b/net/sctp/ulpqueue.c
> @@ -205,9 +205,10 @@ int sctp_ulpq_tail_event(struct sctp_ulpq *ulpq, struct sctp_ulpevent *event)
> if (sock_flag(sk, SOCK_DEAD) || (sk->sk_shutdown & RCV_SHUTDOWN))
> goto out_free;
>
> - if (!sctp_ulpevent_is_notification(event))
> + if (!sctp_ulpevent_is_notification(event)) {
> sk_mark_napi_id(sk, skb);
> -
> + sk_incoming_cpu_update(sk);
> + }
> /* Check if the user wishes to receive this event. */
> if (!sctp_ulpevent_is_enabled(event, &sctp_sk(sk)->subscribe))
> goto out_free;
>
>
> --
> 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: [net-next 1/9] i40e: poll firmware slower
From: Jesse Brandeburg @ 2014-11-07 22:58 UTC (permalink / raw)
To: David Laight
Cc: 'Jeff Kirsher', davem@davemloft.net, Kamil Krawczyk,
netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com, jesse.brandeburg
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1C9EAE27@AcuExch.aculab.com>
Thanks for the review David, comments follow.
On Fri, 7 Nov 2014 09:40:08 +0000
David Laight <David.Laight@ACULAB.COM> wrote:
> From: Jeff Kirsher
> > From: Kamil Krawczyk <kamil.krawczyk@intel.com>
> >
> > The code was polling the firmware tail register for completion every
> > 10 microseconds, which is way faster than the firmware can respond.
> > This changes the poll interval to 1ms, which reduces polling CPU
> > utilization, and the number of times we loop.
>
> Are you sure the code path is allowed to sleep?
Yes, we are never (should never be) in interrupt context when calling
these routines.
>
> > The maximum delay is still 100ms.
>
> Actually it is now likely to be up to 200ms or more.
> You could convert the maximum delay check to one that
> looks at jiffies - but maybe it doesn't matter.
Thats okay, this is all init or reset or shutdown level code. If the
delay goes up it won't hurt anything.
>
> > --- a/drivers/net/ethernet/intel/i40e/i40e_adminq.c
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_adminq.c
> > @@ -853,7 +853,6 @@ i40e_status i40e_asq_send_command(struct i40e_hw *hw,
> > */
> > if (!details->async && !details->postpone) {
> > u32 total_delay = 0;
> > - u32 delay_len = 10;
> >
> > do {
> > /* AQ designers suggest use of head for better
> > @@ -862,8 +861,8 @@ i40e_status i40e_asq_send_command(struct i40e_hw *hw,
> > if (i40e_asq_done(hw))
> > break;
> > /* ugh! delay while spin_lock */
>
> The comment is not right any more.
yes it should have been removed.
>
> > - udelay(delay_len);
> > - total_delay += delay_len;
> > + usleep_range(1000, 2000);
> > + total_delay++;
> > } while (total_delay < hw->aq.asq_cmd_timeout);
> > }
> >
> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_adminq.h
> > b/drivers/net/ethernet/intel/i40e/i40e_adminq.h
> > index ba38a89..df0bd09 100644
> > --- a/drivers/net/ethernet/intel/i40e/i40e_adminq.h
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_adminq.h
> > @@ -141,7 +141,7 @@ static inline int i40e_aq_rc_to_posix(u16 aq_rc)
> >
> > /* general information */
> > #define I40E_AQ_LARGE_BUF 512
> > -#define I40E_ASQ_CMD_TIMEOUT 100000 /* usecs */
> > +#define I40E_ASQ_CMD_TIMEOUT 100 /* msecs */
>
> It looks like this value is written to asq_cmd_timeout, that makes
> be wonder whether anything else can change it - otherwise the compile
> time constant would be used.
> Changing the units has broken anything else that modifies the value.
I pretty much agree with you, but I can tell you why it's there.
Currently nothing in the code changes it. The code was designed such
that it can run on hardware requiring different timeouts.
^ permalink raw reply
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: Al Viro @ 2014-11-07 22:35 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev, linux-kernel, bcrl
In-Reply-To: <20141107223153.GC7996@ZenIV.linux.org.uk>
On Fri, Nov 07, 2014 at 10:31:53PM +0000, Al Viro wrote:
> On Fri, Nov 07, 2014 at 10:11:14PM +0000, Al Viro wrote:
>
> > I'm looking through the tree right now; so far it looks like we can just
> > move those suckers to the point where we validate iovec and lose them
> > from low-level iovec and csum copying completely. I still haven't finished
> > tracing all possible paths for address to arrive at the points where we
> > currently check that stuff, but so far it looks very doable.
>
> BTW, csum side of that is also chock-full of duplicate access_ok() -
> e.g. generic csum_and_copy_from_user() checks before calling
> csum_partial_copy_from_user(). And generic instance of that is using
> __copy_from_user(), all right, but a _lot_ of non-default instances
> repeat that access_ok().
While we are at it: here's the default csum_and_copy_to_user()
static __inline__ __wsum csum_and_copy_to_user
(const void *src, void __user *dst, int len, __wsum sum, int *err_ptr)
{
sum = csum_partial(src, len, sum);
if (access_ok(VERIFY_WRITE, dst, len)) {
if (copy_to_user(dst, src, len) == 0)
return sum;
}
if (len)
*err_ptr = -EFAULT;
return (__force __wsum)-1; /* invalid checksum */
}
Note that we do that access_ok() and follow it with copy_to_user() on exact
same range, i.e. repeat the same damn check...
^ 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