* [PATCH] USBNET: fix handling padding packet
From: Ming Lei @ 2013-09-17 9:10 UTC (permalink / raw)
To: David S. Miller, Greg Kroah-Hartman
Cc: Oliver Neukum, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Ming Lei, Oliver Neukum
Commit 638c5115a7949(USBNET: support DMA SG) introduces DMA SG
if the usb host controller is capable of building packet from
discontinuous buffers, but missed handling padding packet when
building DMA SG.
This patch attachs the pre-allocated padding packet at the
end of the sg list, so padding packet can be sent to device
if drivers require that.
Reported-by: David Laight <David.Laight-JxhZ9S5GRejQT0dZR+AlfA@public.gmane.org>
Cc: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
Signed-off-by: Ming Lei <ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
---
drivers/net/usb/usbnet.c | 27 +++++++++++++++++++++------
include/linux/usb/usbnet.h | 1 +
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 7b331e6..4a9bed3 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1241,7 +1241,9 @@ static int build_dma_sg(const struct sk_buff *skb, struct urb *urb)
if (num_sgs == 1)
return 0;
- urb->sg = kmalloc(num_sgs * sizeof(struct scatterlist), GFP_ATOMIC);
+ /* reserve one for zero packet */
+ urb->sg = kmalloc((num_sgs + 1) * sizeof(struct scatterlist),
+ GFP_ATOMIC);
if (!urb->sg)
return -ENOMEM;
@@ -1305,7 +1307,7 @@ netdev_tx_t usbnet_start_xmit (struct sk_buff *skb,
if (build_dma_sg(skb, urb) < 0)
goto drop;
}
- entry->length = length = urb->transfer_buffer_length;
+ length = urb->transfer_buffer_length;
/* don't assume the hardware handles USB_ZERO_PACKET
* NOTE: strictly conforming cdc-ether devices should expect
@@ -1317,15 +1319,18 @@ netdev_tx_t usbnet_start_xmit (struct sk_buff *skb,
if (length % dev->maxpacket == 0) {
if (!(info->flags & FLAG_SEND_ZLP)) {
if (!(info->flags & FLAG_MULTI_PACKET)) {
- urb->transfer_buffer_length++;
- if (skb_tailroom(skb)) {
+ length++;
+ if (skb_tailroom(skb) && !dev->can_dma_sg) {
skb->data[skb->len] = 0;
__skb_put(skb, 1);
- }
+ } else if (dev->can_dma_sg)
+ sg_set_buf(&urb->sg[urb->num_sgs++],
+ dev->padding_pkt, 1);
}
} else
urb->transfer_flags |= URB_ZERO_PACKET;
}
+ entry->length = urb->transfer_buffer_length = length;
spin_lock_irqsave(&dev->txq.lock, flags);
retval = usb_autopm_get_interface_async(dev->intf);
@@ -1509,6 +1514,7 @@ void usbnet_disconnect (struct usb_interface *intf)
usb_kill_urb(dev->interrupt);
usb_free_urb(dev->interrupt);
+ kfree(dev->padding_pkt);
free_netdev(net);
}
@@ -1679,9 +1685,16 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
/* initialize max rx_qlen and tx_qlen */
usbnet_update_max_qlen(dev);
+ if (dev->can_dma_sg && !(info->flags & FLAG_SEND_ZLP) &&
+ !(info->flags & FLAG_MULTI_PACKET)) {
+ dev->padding_pkt = kzalloc(1, GFP_KERNEL);
+ if (!dev->padding_pkt)
+ goto out4;
+ }
+
status = register_netdev (net);
if (status)
- goto out4;
+ goto out5;
netif_info(dev, probe, dev->net,
"register '%s' at usb-%s-%s, %s, %pM\n",
udev->dev.driver->name,
@@ -1699,6 +1712,8 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
return 0;
+out5:
+ kfree(dev->padding_pkt);
out4:
usb_free_urb(dev->interrupt);
out3:
diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
index 9cb2fe8..e303eef 100644
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -42,6 +42,7 @@ struct usbnet {
struct usb_host_endpoint *status;
unsigned maxpacket;
struct timer_list delay;
+ const char *padding_pkt;
/* protocol/interface state */
struct net_device *net;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] vhost/scsi: use vmalloc for order-10 allocation
From: Asias He @ 2013-09-17 8:55 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kvm, netdev, linux-kernel, virtualization, Dan Aloni
In-Reply-To: <1379401998-5131-1-git-send-email-mst@redhat.com>
On Tue, Sep 17, 2013 at 10:21:07AM +0300, Michael S. Tsirkin wrote:
> As vhost scsi device struct is large, if the device is
> created on a busy system, kzalloc() might fail, so this patch does a
> fallback to vzalloc().
>
> As vmalloc() adds overhead on data-path, add __GFP_REPEAT
> to kzalloc() flags to do this fallback only when really needed.
>
> Reported-by: Dan Aloni <alonid@stratoscale.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Asias He <asias@redhat.com>
> ---
>
> I put this on my vhost fixes branch, intend to merge for 3.12.
> Dan, could you please confirm this works for you?
>
> drivers/vhost/scsi.c | 41 +++++++++++++++++++++++++++--------------
> 1 file changed, 27 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
> index 4b79a1f..2c30bb0 100644
> --- a/drivers/vhost/scsi.c
> +++ b/drivers/vhost/scsi.c
> @@ -1373,21 +1373,30 @@ static int vhost_scsi_set_features(struct vhost_scsi *vs, u64 features)
> return 0;
> }
>
> +static void vhost_scsi_free(struct vhost_scsi *vs)
> +{
> + if (is_vmalloc_addr(vs))
> + vfree(vs);
> + else
> + kfree(vs);
> +}
> +
> static int vhost_scsi_open(struct inode *inode, struct file *f)
> {
> struct vhost_scsi *vs;
> struct vhost_virtqueue **vqs;
> - int r, i;
> + int r = -ENOMEM, i;
>
> - vs = kzalloc(sizeof(*vs), GFP_KERNEL);
> - if (!vs)
> - return -ENOMEM;
> + vs = kzalloc(sizeof(*vs), GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT);
> + if (!vs) {
> + vs = vzalloc(sizeof(*vs));
> + if (!vs)
> + goto err_vs;
> + }
>
> vqs = kmalloc(VHOST_SCSI_MAX_VQ * sizeof(*vqs), GFP_KERNEL);
> - if (!vqs) {
> - kfree(vs);
> - return -ENOMEM;
> - }
> + if (!vqs)
> + goto err_vqs;
>
> vhost_work_init(&vs->vs_completion_work, vhost_scsi_complete_cmd_work);
> vhost_work_init(&vs->vs_event_work, tcm_vhost_evt_work);
> @@ -1407,14 +1416,18 @@ static int vhost_scsi_open(struct inode *inode, struct file *f)
>
> tcm_vhost_init_inflight(vs, NULL);
>
> - if (r < 0) {
> - kfree(vqs);
> - kfree(vs);
> - return r;
> - }
> + if (r < 0)
> + goto err_init;
>
> f->private_data = vs;
> return 0;
> +
> +err_init:
> + kfree(vqs);
> +err_vqs:
> + vhost_scsi_free(vs);
> +err_vs:
> + return r;
> }
>
> static int vhost_scsi_release(struct inode *inode, struct file *f)
> @@ -1431,7 +1444,7 @@ static int vhost_scsi_release(struct inode *inode, struct file *f)
> /* Jobs can re-queue themselves in evt kick handler. Do extra flush. */
> vhost_scsi_flush(vs);
> kfree(vs->dev.vqs);
> - kfree(vs);
> + vhost_scsi_free(vs);
> return 0;
> }
>
> --
> MST
--
Asias
^ permalink raw reply
* RE: [PATCH 8/8 V2] rtlwifi: Remove variable 'noise' from rtl_stats struct
From: David Laight @ 2013-09-17 8:48 UTC (permalink / raw)
To: Larry Finger, linville; +Cc: linux-wireless, netdev
In-Reply-To: <1379357722-17687-9-git-send-email-Larry.Finger@lwfinger.net>
> diff --git a/drivers/net/wireless/rtlwifi/wifi.h b/drivers/net/wireless/rtlwifi/wifi.h
> index cc03e7c..284ee8d 100644
> --- a/drivers/net/wireless/rtlwifi/wifi.h
> +++ b/drivers/net/wireless/rtlwifi/wifi.h
> @@ -1535,7 +1535,6 @@ struct rtl_stats {
> u32 mac_time[2];
> s8 rssi;
> u8 signal;
> - u8 noise;
> u8 rate; /* hw desc rate */
> u8 received_channel;
> u8 control;
> --
Is 'struct rtl_stats' exposed to userspace?
(or even to loadable drivers)
If so you probably ought to replace 'noise' with an explicit
pad in order to avoid changing the offsets of the other fields.
David
^ permalink raw reply
* RE: [RFC PATCH v2 net-next 0/2] BPF and OVS extensions
From: David Laight @ 2013-09-17 8:40 UTC (permalink / raw)
To: Alexei Starovoitov, David S. Miller, netdev, Eric Dumazet,
Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Daniel Borkmann, Paul E. McKenney, Xi Wang, David Howells,
Cong Wang, Jesse Gross, Pravin B Shelar, Ben Pfaff, Thomas Graf,
dev
In-Reply-To: <1379386119-4157-1-git-send-email-ast@plumgrid.com>
> Patch 1/2: generic BPF extension
> Original A and X 32-bit BPF registers are replaced with ten 64-bit registers.
> bpf opcode encoding kept the same. load/store were generalized to access stack,
> bpf_tables and bpf_context.
> BPF program interfaces to outside world via tables that it can read and write,
> and via bpf_context which is in/out blob of data.
> Other kernel components can provide callbacks to tailor BPF to specific needs.
As has been recently pointed out on some of the NetBSD lists
one of the points about BPF is that the filters are deterministic
and easily proven to both terminate and have no unwanted side effects.
The functionality you are proposing breaks both of these assumptions.
It is understood that parsing IPv6 headers is currently impossible
(needs loops of some form) but a specific helper instruction is
probably a better solution.
What you seem to be proposing is a completely different beast,
so you should call it something else - it isn't BPF.
Whether the Linux kernel needs a (another?) byte code interpreter
is a separate issue.
David
^ permalink raw reply
* [PATCH net-next] gen_estimator: change the lock order for better perfermance
From: Hong Zhiguo @ 2013-09-17 8:38 UTC (permalink / raw)
To: netdev; +Cc: davem, stephen, Hong Zhiguo
From: Hong Zhiguo <zhiguohong@tencent.com>
e->stats_lock is usually taken by fast path to update stats.
In the old order, fast path should wait for write_lock(&est_lock).
Even though it's only one line inside the write_lock(&est_lock),
but if there's interrupt or page fault, a lot of spin on
e->stats_lock will be wasted in fast path.
Signed-off-by: Hong Zhiguo <zhiguohong@tencent.com>
---
net/core/gen_estimator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/gen_estimator.c b/net/core/gen_estimator.c
index 6b5b6e7..bad7f5f 100644
--- a/net/core/gen_estimator.c
+++ b/net/core/gen_estimator.c
@@ -120,11 +120,11 @@ static void est_timer(unsigned long arg)
u32 npackets;
u32 rate;
- spin_lock(e->stats_lock);
read_lock(&est_lock);
if (e->bstats == NULL)
goto skip;
+ spin_lock(e->stats_lock);
nbytes = e->bstats->bytes;
npackets = e->bstats->packets;
brate = (nbytes - e->last_bytes)<<(7 - idx);
@@ -136,9 +136,9 @@ static void est_timer(unsigned long arg)
e->last_packets = npackets;
e->avpps += (rate >> e->ewma_log) - (e->avpps >> e->ewma_log);
e->rate_est->pps = (e->avpps+0x1FF)>>10;
+ spin_unlock(e->stats_lock);
skip:
read_unlock(&est_lock);
- spin_unlock(e->stats_lock);
}
if (!list_empty(&elist[idx].list))
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH net 0/4] bridge: Fix problems around the PVID
From: Toshiaki Makita @ 2013-09-17 8:12 UTC (permalink / raw)
To: vyasevic
Cc: Toshiaki Makita, David Miller, netdev, Fernando Luis Vazquez Cao,
Patrick McHardy
In-Reply-To: <523744A6.5090001@redhat.com>
On Mon, 2013-09-16 at 13:49 -0400, Vlad Yasevich wrote:
> On 09/13/2013 08:06 AM, Toshiaki Makita wrote:
> > On Thu, 2013-09-12 at 16:00 -0400, David Miller wrote:
> >> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> >> Date: Tue, 10 Sep 2013 19:27:54 +0900
> >>
> >>> There seem to be some undesirable behaviors related with PVID.
> >>> 1. It has no effect assigning PVID to a port. PVID cannot be applied
> >>> to any frame regardless of whether we set it or not.
> >>> 2. FDB entries learned via frames applied PVID are registered with
> >>> VID 0 rather than VID value of PVID.
> >>> 3. We can set 0 or 4095 as a PVID that are not allowed in IEEE 802.1Q.
> >>> This leads interoperational problems such as sending frames with VID
> >>> 4095, which is not allowed in IEEE 802.1Q, and treating frames with VID
> >>> 0 as they belong to VLAN 0, which is expected to be handled as they have
> >>> no VID according to IEEE 802.1Q.
> >>>
> >>> Note: 2nd and 3rd problems are potential and not exposed unless 1st problem
> >>> is fixed, because we cannot activate PVID due to it.
> >>
> >> Please work out the issues in patch #2 with Vlad and resubmit this
> >> series.
> >>
> >> Thank you.
> >
> > I'm hovering between whether we should fix the issue by changing vlan 0
> > interface behavior in 8021q module or enabling a bridge port to sending
> > priority-tagged frames, or another better way.
> >
> > If you could comment it, I'd appreciate it :)
> >
> >
> > BTW, I think what is discussed in patch #2 is another problem about
> > handling priority-tags, and it exists without this patch set applied.
> > It looks like that we should prepare another patch set than this to fix
> > that problem.
> >
> > Should I include patches that fix the priority-tags problem in this
> > patch set and resubmit them all together?
> >
>
> I am thinking that we might need to do it in bridge and it looks like
> the simplest way to do it is to have default priority regeneration table
> (table 6-5 from 802.1Q doc).
>
> That way I think we would conform to the spec.
>
> -vlad
Unfortunately I don't think the default priority regeneration table
resolves the problem because IEEE 802.1Q says that a VLAN-aware bridge
can transmit untagged or VLAN-tagged frames only (the end of section 7.5
and 8.1.7).
No mechanism to send priority-tagged frames is found as far as I can see
the standard. I think the regenerated priority is used for outgoing PCP
field only if egress policy is not untagged (i.e. transmitting as
VLAN-tagged), and unused if untagged (Section 6.9.2 3rd/4th Paragraph).
If we want to transmit priority-tagged frames from a bridge port, I
think we need to implement a new (optional) feature that is above the
standard, as I stated previously.
How do you feel about adding a per-port policy that enables a bridge to
send priority-tagged frames instead of untagged frames when egress
policy for the port is untagged?
With this change, we can transmit frames for a given vlan as either all
untagged, all priority-tagged or all VLAN-tagged.
Thanks,
Toshiaki Makita
>
> >
> > Thanks,
> >
> > Toshiaki Makita
> >
> >>
> >> --
> >> 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
* [PATCH net-next] bridge: change the order of actions in addif/delif
From: Hong Zhiguo @ 2013-09-17 7:44 UTC (permalink / raw)
To: netdev; +Cc: stephen, davem, eric.dumazet, vyasevic, Hong Zhiguo
From: Hong Zhiguo <zhiguohong@tencent.com>
netdev_rx_handler_register turns on the bridge traffic. It should
be the last action of br_add_if, after the installation of fdb and
stp staff. _Maybe_ traffic coming in before preparation of fdb and
stp is taken care of, but we could make it easier.
Vise versa, netdev_rx_handler_unregister actually turns off bridge
traffic from the dev. It should be the first action of br_del_if,
before fdb and stp staff is uninstalled.
Signed-off-by: Hong Zhiguo <zhiguohong@tencent.com>
---
net/bridge/br_if.c | 20 ++++++++------------
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index c41d5fb..6544154 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -133,6 +133,8 @@ static void del_nbp(struct net_bridge_port *p)
sysfs_remove_link(br->ifobj, p->dev->name);
+ netdev_rx_handler_unregister(dev);
+
dev_set_promiscuity(dev, -1);
spin_lock_bh(&br->lock);
@@ -148,8 +150,6 @@ static void del_nbp(struct net_bridge_port *p)
dev->priv_flags &= ~IFF_BRIDGE_PORT;
- netdev_rx_handler_unregister(dev);
-
netdev_upper_dev_unlink(dev, br->dev);
br_multicast_del_port(p);
@@ -336,8 +336,8 @@ int br_add_if(struct net_bridge *br, struct net_device *dev)
if (dev->netdev_ops->ndo_start_xmit == br_dev_xmit)
return -ELOOP;
- /* Device is already being bridged */
- if (br_port_exists(dev))
+ /* Device is already being bridged or registered with other handler */
+ if (br_port_exists(dev) || dev->rx_handler)
return -EBUSY;
/* No bridging devices that dislike that (e.g. wireless) */
@@ -371,10 +371,6 @@ int br_add_if(struct net_bridge *br, struct net_device *dev)
if (err)
goto err4;
- err = netdev_rx_handler_register(dev, br_handle_frame, p);
- if (err)
- goto err5;
-
dev->priv_flags |= IFF_BRIDGE_PORT;
dev_disable_lro(dev);
@@ -394,8 +390,6 @@ int br_add_if(struct net_bridge *br, struct net_device *dev)
br_stp_enable_port(p);
spin_unlock_bh(&br->lock);
- br_ifinfo_notify(RTM_NEWLINK, p);
-
if (changed_addr)
call_netdevice_notifiers(NETDEV_CHANGEADDR, br->dev);
@@ -404,12 +398,14 @@ int br_add_if(struct net_bridge *br, struct net_device *dev)
if (br_fdb_insert(br, p, dev->dev_addr, 0))
netdev_err(dev, "failed insert local address bridge forwarding table\n");
+ /* rx_handler is already tested, no fail here */
+ netdev_rx_handler_register(dev, br_handle_frame, p);
+
+ br_ifinfo_notify(RTM_NEWLINK, p);
kobject_uevent(&p->kobj, KOBJ_ADD);
return 0;
-err5:
- netdev_upper_dev_unlink(dev, br->dev);
err4:
br_netpoll_disable(p);
err3:
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCHv3 linux-next] hrtimer: Add notifier when clock_was_set was called
From: Fan Du @ 2013-09-17 7:47 UTC (permalink / raw)
To: Thomas Gleixner
Cc: David Miller, herbert, steffen.klassert, dborkman, linux-kernel,
netdev, John Stultz
In-Reply-To: <alpine.DEB.2.02.1309161059220.4089@ionos.tec.linutronix.de>
On 2013年09月16日 17:01, Thomas Gleixner wrote:
> On Mon, 16 Sep 2013, Fan Du wrote:
>> On 2013年09月13日 22:32, Thomas Gleixner wrote:
>>> On Fri, 13 Sep 2013, Fan Du wrote:
>>>> (2) What I have been bugging you around here for this long time is really
>>>> the
>>>> second
>>>> problem, I'm sorry I didn't make it clearly to you and others, which
>>>> is
>>>> below:
>>>>
>>>> Why using wall clock time to calculate soft/hard IPsec events when
>>>> xfrm_state timer
>>>> out happens in its timeout handler? Because even if xfrm_state using
>>>> CLOCK_BOOTTIME,
>>>> system wall clock time changing will surely disturb soft/hard IPsec
>>>> events, which
>>>> you raised your concern about in (*a*).
>>>
>>> No CLOCK_BOOTTIME is not affected by wall clock time changes. It's
>>> basically CLOCK_MONOTONIC, it just keeps counting the suspend time as
>>> well. So without a suspend/resume cycle CLOCK_MONOTONIC and
>>> CLOCK_BOOTTIME are the same. After a suspend/resume cycle
>>> CLOCK_BOOTTIME will be N seconds ahead of CLOCK_MONOTONIC, where N is
>>> the number of seconds spent in suspend.
>>
>> Sorry for the ambiguity. Yes, CLOCK_BOOTTIME is monotonic *and* counting
>> suspend/resume time as well as not affected by wall clock time change.
>>
>> Using CLOCK_BOOTTIME guarantees b- will timeout in a right manner, i.e., not
>> affected by wall clock time change, as well as keep the timer valid when
>> suspend/resume.
>>
>> A classic way of using timer is:
>> a- Arm a timer with specified interval
>> b- Wait for the timer to timeout
>> c- After the timeout, notify the event to other place in the timer handler.
>>
>> IPsec key lifetime timer does its this way:
>> a- Arm a timer with specified interval
>> b- Wait for the timer to timeout
>> c- After timeout, in the timer handler, using wall clock time to calculate
>> which kind of event to notify user(soft or hard for both key use time,
>> and key created time). So the problem arises at this stage if wall clock
>> time changed.
>
> And why on earth must it use wall clock time for selecting the event
> type?
/*shivering... sorry to bother you again.*/
Yep, it's a bit twisted. This parts of codes come a long way from v2.5.67
Beyond this fact, I barely know its original design goal by doing so.
The first version of this patch is to remove the wall clock time things
by myself, it's a pity that the feedback is not very welcome at the end.
So later on adding notifier at clock_was_set is suggested by David.
> Thanks,
>
> tglx
--
浮沉随浪只记今朝笑
--fan
^ permalink raw reply
* Re: [PATCH v3 net-next 07/27] net: add for_each iterators through neighbour lower link's private
From: Veaceslav Falico @ 2013-09-17 7:36 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev, jiri, David S. Miller, Eric Dumazet, Alexander Duyck
In-Reply-To: <1379381203.23881.22.camel@deadeye.wl.decadent.org.uk>
On Tue, Sep 17, 2013 at 02:26:43AM +0100, Ben Hutchings wrote:
>On Tue, 2013-09-17 at 02:46 +0200, Veaceslav Falico wrote:
>[...]
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -4537,6 +4537,72 @@ struct net_device *netdev_all_upper_get_next_dev_rcu(struct net_device *dev,
>> }
>> EXPORT_SYMBOL(netdev_all_upper_get_next_dev_rcu);
>>
>> +/* netdev_lower_get_next_private - Get the next ->private from the
>> + * lower neighbour list
>[...]
>
>This is not correct kernel-doc syntax. You must begin the comment like
>this:
>
>/**
> * function_name - summary on one physical line, no wrapping allowed
I've thought that netdev specifically requires that type of comments*. But
I don't have any strong opinion on that, so if needed - can change easily
in the next version.
Thanks a lot!
*Documentation/networking/netdev-FAQ.txt
Q: Someone said that the comment style and coding convention is different
for the networking content. Is this true?
A: Yes, in a largely trivial way. Instead of this:
/*
* foobar blah blah blah
* another line of text
*/
it is requested that you make it look like this:
/* foobar blah blah blah
* another line of text
*/
>
>Ben.
>
>--
>Ben Hutchings, Staff Engineer, Solarflare
>Not speaking for my employer; that's the marketing department's job.
>They asked us to note that Solarflare product names are trademarked.
>
^ permalink raw reply
* Re: [PATCH v3 net-next 02/27] net: add RCU variant to search for netdev_adjacent link
From: Veaceslav Falico @ 2013-09-17 7:34 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev, jiri, David S. Miller, Eric Dumazet, Alexander Duyck,
Cong Wang
In-Reply-To: <1379380998.23881.20.camel@deadeye.wl.decadent.org.uk>
On Tue, Sep 17, 2013 at 02:23:18AM +0100, Ben Hutchings wrote:
>On Tue, 2013-09-17 at 02:46 +0200, Veaceslav Falico wrote:
>> Currently we have only the RTNL flavour, however we can traverse it while
>> holding only RCU, so add the RCU search. Add only one function that will be
>> used further, other functions can be added easily afterwards, if anyone
>> would need them.
>[...]
>> +static struct netdev_adjacent *__netdev_find_adj_rcu(struct net_device *dev,
>> + struct net_device *adj_dev,
>> + bool upper, bool neighbour)
>> +{
>> + struct netdev_adjacent *adj;
>> + struct list_head *adj_list;
>> +
>> + if (neighbour)
>> + adj_list = upper ? &dev->adj_list.upper :
>> + &dev->adj_list.lower;
>> + else
>> + adj_list = upper ? &dev->all_adj_list.upper :
>> + &dev->all_adj_list.lower;
>
>I think it would be clearer to make adj_list a parameter, rather than
>taking the dev and a pair of booleans.
Hm, true, indeed, will try to change in the next version.
Thank you!
>
>Ben.
>
>> + list_for_each_entry_rcu(adj, adj_list, list) {
>> + if (adj->dev == adj_dev)
>> + return adj;
>> + }
>> + return NULL;
>> +}
>> +
>> +static struct netdev_adjacent *__netdev_lower_find_rcu(struct net_device *dev,
>> + struct net_device *ldev)
>> +{
>> + return __netdev_find_adj_rcu(dev, ldev, false, true);
>> +}
>> +
>> static struct netdev_adjacent *__netdev_find_adj(struct net_device *dev,
>> struct net_device *adj_dev,
>> bool upper, bool neighbour)
>
>--
>Ben Hutchings, Staff Engineer, Solarflare
>Not speaking for my employer; that's the marketing department's job.
>They asked us to note that Solarflare product names are trademarked.
>
^ permalink raw reply
* Re: [PATCH net-next v4] ptp: add the PTP_SYS_OFFSET ioctl to the testptp program
From: Dong Zhu @ 2013-09-17 7:32 UTC (permalink / raw)
To: Richard Cochran; +Cc: Rob Landley, netdev, linux-doc, linux-kernel
In-Reply-To: <20130915084811.GA10163@netboy>
Hi Richard,
I developed a new patch and added a method to estimate the time offset
between system and phc clock.
Could you help reviewing it again ? If it do make sense I hope it could
be accepted.
Thanks !
>From e524e3b68f3df3cd91acd814490d092bad05386b Mon Sep 17 00:00:00 2001
This patch add a method into testptp.c to measure the time offset
between phc and system clock through the ioctl PTP_SYS_OFFSET.
Signed-off-by: Dong Zhu <bluezhudong@gmail.com>
---
Documentation/ptp/testptp.c | 65 +++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 63 insertions(+), 2 deletions(-)
diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c
index f59ded0..a74d0a8 100644
--- a/Documentation/ptp/testptp.c
+++ b/Documentation/ptp/testptp.c
@@ -100,6 +100,11 @@ static long ppb_to_scaled_ppm(int ppb)
return (long) (ppb * 65.536);
}
+static int64_t pctns(struct ptp_clock_time *t)
+{
+ return t->sec * 1000000000LL + t->nsec;
+}
+
static void usage(char *progname)
{
fprintf(stderr,
@@ -112,6 +117,8 @@ static void usage(char *progname)
" -f val adjust the ptp clock frequency by 'val' ppb\n"
" -g get the ptp clock time\n"
" -h prints this message\n"
+ " -k val measure the time offset between system and phc clock\n"
+ " for 'val' times (Maximum 25)\n"
" -p val enable output with a period of 'val' nanoseconds\n"
" -P val enable or disable (val=1|0) the system clock PPS\n"
" -s set the ptp clock time from the system time\n"
@@ -133,8 +140,12 @@ int main(int argc, char *argv[])
struct itimerspec timeout;
struct sigevent sigevent;
+ struct ptp_clock_time *pct;
+ struct ptp_sys_offset *sysoff;
+
+
char *progname;
- int c, cnt, fd;
+ int i, c, cnt, fd;
char *device = DEVICE;
clockid_t clkid;
@@ -144,14 +155,19 @@ int main(int argc, char *argv[])
int extts = 0;
int gettime = 0;
int oneshot = 0;
+ int pct_offset = 0;
+ int n_samples = 0;
int periodic = 0;
int perout = -1;
int pps = -1;
int settime = 0;
+ int64_t t1, t2, tp;
+ int64_t interval, offset;
+
progname = strrchr(argv[0], '/');
progname = progname ? 1+progname : argv[0];
- while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghp:P:sSt:v"))) {
+ while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghk:p:P:sSt:v"))) {
switch (c) {
case 'a':
oneshot = atoi(optarg);
@@ -174,6 +190,10 @@ int main(int argc, char *argv[])
case 'g':
gettime = 1;
break;
+ case 'k':
+ pct_offset = 1;
+ n_samples = atoi(optarg);
+ break;
case 'p':
perout = atoi(optarg);
break;
@@ -376,6 +396,47 @@ int main(int argc, char *argv[])
}
}
+ if (pct_offset) {
+ if (n_samples <= 0 || n_samples > 25) {
+ puts("n_samples should be between 1 and 25");
+ usage(progname);
+ return -1;
+ }
+
+ sysoff = calloc(1, sizeof(*sysoff));
+ if (!sysoff) {
+ perror("calloc");
+ return -1;
+ }
+ sysoff->n_samples = n_samples;
+
+ if (ioctl(fd, PTP_SYS_OFFSET, sysoff))
+ perror("PTP_SYS_OFFSET");
+ else
+ puts("system and phc clock time offset request okay");
+
+ pct = &sysoff->ts[0];
+ for (i = 0; i < sysoff->n_samples; i++) {
+ t1 = pctns(pct+2*i);
+ tp = pctns(pct+2*i+1);
+ t2 = pctns(pct+2*i+2);
+ interval = t2 - t1;
+ offset = (t2 + t1) / 2 - tp;
+
+ printf("system time: %ld.%ld\n",
+ (pct+2*i)->sec, (pct+2*i)->nsec);
+ printf("phc time: %ld.%ld\n",
+ (pct+2*i+1)->sec, (pct+2*i+1)->nsec);
+ printf("system time: %ld.%ld\n",
+ (pct+2*i+2)->sec, (pct+2*i+2)->nsec);
+ printf("system/phc clock time offset is %ld ns\n"
+ "system clock time delay is %ld ns\n",
+ offset, interval);
+ }
+
+ free(sysoff);
+ }
+
close(fd);
return 0;
}
--
1.7.11.7
--
Best Regards,
Dong Zhu
^ permalink raw reply related
* [PATCH] vhost/scsi: use vmalloc for order-10 allocation
From: Michael S. Tsirkin @ 2013-09-17 7:21 UTC (permalink / raw)
To: linux-kernel; +Cc: kvm, netdev, virtualization, Dan Aloni
As vhost scsi device struct is large, if the device is
created on a busy system, kzalloc() might fail, so this patch does a
fallback to vzalloc().
As vmalloc() adds overhead on data-path, add __GFP_REPEAT
to kzalloc() flags to do this fallback only when really needed.
Reported-by: Dan Aloni <alonid@stratoscale.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
I put this on my vhost fixes branch, intend to merge for 3.12.
Dan, could you please confirm this works for you?
drivers/vhost/scsi.c | 41 +++++++++++++++++++++++++++--------------
1 file changed, 27 insertions(+), 14 deletions(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 4b79a1f..2c30bb0 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -1373,21 +1373,30 @@ static int vhost_scsi_set_features(struct vhost_scsi *vs, u64 features)
return 0;
}
+static void vhost_scsi_free(struct vhost_scsi *vs)
+{
+ if (is_vmalloc_addr(vs))
+ vfree(vs);
+ else
+ kfree(vs);
+}
+
static int vhost_scsi_open(struct inode *inode, struct file *f)
{
struct vhost_scsi *vs;
struct vhost_virtqueue **vqs;
- int r, i;
+ int r = -ENOMEM, i;
- vs = kzalloc(sizeof(*vs), GFP_KERNEL);
- if (!vs)
- return -ENOMEM;
+ vs = kzalloc(sizeof(*vs), GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT);
+ if (!vs) {
+ vs = vzalloc(sizeof(*vs));
+ if (!vs)
+ goto err_vs;
+ }
vqs = kmalloc(VHOST_SCSI_MAX_VQ * sizeof(*vqs), GFP_KERNEL);
- if (!vqs) {
- kfree(vs);
- return -ENOMEM;
- }
+ if (!vqs)
+ goto err_vqs;
vhost_work_init(&vs->vs_completion_work, vhost_scsi_complete_cmd_work);
vhost_work_init(&vs->vs_event_work, tcm_vhost_evt_work);
@@ -1407,14 +1416,18 @@ static int vhost_scsi_open(struct inode *inode, struct file *f)
tcm_vhost_init_inflight(vs, NULL);
- if (r < 0) {
- kfree(vqs);
- kfree(vs);
- return r;
- }
+ if (r < 0)
+ goto err_init;
f->private_data = vs;
return 0;
+
+err_init:
+ kfree(vqs);
+err_vqs:
+ vhost_scsi_free(vs);
+err_vs:
+ return r;
}
static int vhost_scsi_release(struct inode *inode, struct file *f)
@@ -1431,7 +1444,7 @@ static int vhost_scsi_release(struct inode *inode, struct file *f)
/* Jobs can re-queue themselves in evt kick handler. Do extra flush. */
vhost_scsi_flush(vs);
kfree(vs->dev.vqs);
- kfree(vs);
+ vhost_scsi_free(vs);
return 0;
}
--
MST
^ permalink raw reply related
* [PATCHv2 net] xfrm: Guard IPsec anti replay window against replay bitmap
From: Fan Du @ 2013-09-17 7:14 UTC (permalink / raw)
To: steffen.klassert; +Cc: davem, netdev
For legacy IPsec anti replay mechanism:
bitmap in struct xfrm_replay_state could only provide a 32 bits
window size limit in current design, thus user level parameter
sadb_sa_replay should honor this limit, otherwise misleading
outputs("replay=244") by setkey -D will be:
192.168.25.2 192.168.22.2
esp mode=transport spi=147561170(0x08cb9ad2) reqid=0(0x00000000)
E: aes-cbc 9a8d7468 7655cf0b 719d27be b0ddaac2
A: hmac-sha1 2d2115c2 ebf7c126 1c54f186 3b139b58 264a7331
seq=0x00000000 replay=244 flags=0x00000000 state=mature
created: Sep 17 14:00:00 2013 current: Sep 17 14:00:22 2013
diff: 22(s) hard: 30(s) soft: 26(s)
last: Sep 17 14:00:00 2013 hard: 0(s) soft: 0(s)
current: 1408(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 22 hard: 0 soft: 0
sadb_seq=1 pid=4854 refcnt=0
192.168.22.2 192.168.25.2
esp mode=transport spi=255302123(0x0f3799eb) reqid=0(0x00000000)
E: aes-cbc 6485d990 f61a6bd5 e5660252 608ad282
A: hmac-sha1 0cca811a eb4fa893 c47ae56c 98f6e413 87379a88
seq=0x00000000 replay=244 flags=0x00000000 state=mature
created: Sep 17 14:00:00 2013 current: Sep 17 14:00:22 2013
diff: 22(s) hard: 30(s) soft: 26(s)
last: Sep 17 14:00:00 2013 hard: 0(s) soft: 0(s)
current: 1408(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 22 hard: 0 soft: 0
sadb_seq=0 pid=4854 refcnt=0
And also, optimizing xfrm_replay_check window checking by setting the
desirable x->props.replay_window with only doing the comparison once
for all when xfrm_state is first born.
Signed-off-by: Fan Du <fan.du@windriver.com>
---
v2:
Update state replay_window created through netlink advised by Steffen.
---
net/key/af_key.c | 3 ++-
net/xfrm/xfrm_replay.c | 3 +--
net/xfrm/xfrm_user.c | 3 ++-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/key/af_key.c b/net/key/af_key.c
index 9d58537..911ef03 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -1098,7 +1098,8 @@ static struct xfrm_state * pfkey_msg2xfrm_state(struct net *net,
x->id.proto = proto;
x->id.spi = sa->sadb_sa_spi;
- x->props.replay_window = sa->sadb_sa_replay;
+ x->props.replay_window = min_t(unsigned int, sa->sadb_sa_replay,
+ (sizeof(x->replay.bitmap) * 8));
if (sa->sadb_sa_flags & SADB_SAFLAGS_NOECN)
x->props.flags |= XFRM_STATE_NOECN;
if (sa->sadb_sa_flags & SADB_SAFLAGS_DECAP_DSCP)
diff --git a/net/xfrm/xfrm_replay.c b/net/xfrm/xfrm_replay.c
index 8dafe6d3..eeca388 100644
--- a/net/xfrm/xfrm_replay.c
+++ b/net/xfrm/xfrm_replay.c
@@ -129,8 +129,7 @@ static int xfrm_replay_check(struct xfrm_state *x,
return 0;
diff = x->replay.seq - seq;
- if (diff >= min_t(unsigned int, x->props.replay_window,
- sizeof(x->replay.bitmap) * 8)) {
+ if (diff >= x->props.replay_window) {
x->stats.replay_window++;
goto err;
}
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 3f565e4..56d3e45 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -446,7 +446,8 @@ static void copy_from_user_state(struct xfrm_state *x, struct xfrm_usersa_info *
memcpy(&x->sel, &p->sel, sizeof(x->sel));
memcpy(&x->lft, &p->lft, sizeof(x->lft));
x->props.mode = p->mode;
- x->props.replay_window = p->replay_window;
+ x->props.replay_window = min_t(unsigned int, p->replay_window,
+ sizeof(x->replay.bitmap) * 8);
x->props.reqid = p->reqid;
x->props.family = p->family;
memcpy(&x->props.saddr, &p->saddr, sizeof(x->props.saddr));
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH net] xfrm: Guard IPsec anti replay window against replay bitmap
From: Fan Du @ 2013-09-17 7:12 UTC (permalink / raw)
To: Steffen Klassert; +Cc: davem, netdev
In-Reply-To: <20130917065647.GO7660@secunet.com>
On 2013年09月17日 14:56, Steffen Klassert wrote:
> On Tue, Sep 17, 2013 at 02:26:05PM +0800, Fan Du wrote:
>>
>> diff --git a/net/key/af_key.c b/net/key/af_key.c
>> index 9d58537..911ef03 100644
>> --- a/net/key/af_key.c
>> +++ b/net/key/af_key.c
>> @@ -1098,7 +1098,8 @@ static struct xfrm_state * pfkey_msg2xfrm_state(struct net *net,
>>
>> x->id.proto = proto;
>> x->id.spi = sa->sadb_sa_spi;
>> - x->props.replay_window = sa->sadb_sa_replay;
>> + x->props.replay_window = min_t(unsigned int, sa->sadb_sa_replay,
>> + (sizeof(x->replay.bitmap) * 8));
>> if (sa->sadb_sa_flags& SADB_SAFLAGS_NOECN)
>> x->props.flags |= XFRM_STATE_NOECN;
>> if (sa->sadb_sa_flags& SADB_SAFLAGS_DECAP_DSCP)
>> diff --git a/net/xfrm/xfrm_replay.c b/net/xfrm/xfrm_replay.c
>> index 8dafe6d3..eeca388 100644
>> --- a/net/xfrm/xfrm_replay.c
>> +++ b/net/xfrm/xfrm_replay.c
>> @@ -129,8 +129,7 @@ static int xfrm_replay_check(struct xfrm_state *x,
>> return 0;
>>
>> diff = x->replay.seq - seq;
>> - if (diff>= min_t(unsigned int, x->props.replay_window,
>> - sizeof(x->replay.bitmap) * 8)) {
>> + if (diff>= x->props.replay_window) {
>
> So x->props.replay_window will be valid if the state was added with the
> pfkey interface, but what if the netlink interface was used? You should
> also update the netlink part to always hold a valid replay window.
>
Smell positively, v2 in seconds。。。
Thanks, Steffen.
--
浮沉随浪只记今朝笑
--fan
^ permalink raw reply
* Re: [PATCH net] xfrm: Guard IPsec anti replay window against replay bitmap
From: Steffen Klassert @ 2013-09-17 6:56 UTC (permalink / raw)
To: Fan Du; +Cc: davem, netdev
In-Reply-To: <1379399165-8955-1-git-send-email-fan.du@windriver.com>
On Tue, Sep 17, 2013 at 02:26:05PM +0800, Fan Du wrote:
>
> diff --git a/net/key/af_key.c b/net/key/af_key.c
> index 9d58537..911ef03 100644
> --- a/net/key/af_key.c
> +++ b/net/key/af_key.c
> @@ -1098,7 +1098,8 @@ static struct xfrm_state * pfkey_msg2xfrm_state(struct net *net,
>
> x->id.proto = proto;
> x->id.spi = sa->sadb_sa_spi;
> - x->props.replay_window = sa->sadb_sa_replay;
> + x->props.replay_window = min_t(unsigned int, sa->sadb_sa_replay,
> + (sizeof(x->replay.bitmap) * 8));
> if (sa->sadb_sa_flags & SADB_SAFLAGS_NOECN)
> x->props.flags |= XFRM_STATE_NOECN;
> if (sa->sadb_sa_flags & SADB_SAFLAGS_DECAP_DSCP)
> diff --git a/net/xfrm/xfrm_replay.c b/net/xfrm/xfrm_replay.c
> index 8dafe6d3..eeca388 100644
> --- a/net/xfrm/xfrm_replay.c
> +++ b/net/xfrm/xfrm_replay.c
> @@ -129,8 +129,7 @@ static int xfrm_replay_check(struct xfrm_state *x,
> return 0;
>
> diff = x->replay.seq - seq;
> - if (diff >= min_t(unsigned int, x->props.replay_window,
> - sizeof(x->replay.bitmap) * 8)) {
> + if (diff >= x->props.replay_window) {
So x->props.replay_window will be valid if the state was added with the
pfkey interface, but what if the netlink interface was used? You should
also update the netlink part to always hold a valid replay window.
^ permalink raw reply
* Re: [CFT][PATCH] net: Delay default_device_exit_batch until no devices are unregistering
From: Francesco Ruggeri @ 2013-09-17 6:54 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David S. Miller, Eric Dumazet, Jiri Pirko, Alexander Duyck,
Cong Wang, netdev
In-Reply-To: <87mwncaz04.fsf_-_@xmission.com>
On Mon, Sep 16, 2013 at 8:49 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
>
> The implementation is a little rough but the logic should be right.
>
> Device registration and unregistration is serialized with the rtnl_lock.
> The final pieces of device unregistration do not happen under the
> rtnl_lock resulting in the possibility that while we wait for the
> refcount of a device to drop to zero the network namespace is
> unregistered while no locks are held.
>
> Prevent that by keeping a count of the network devices that are being
> unregistered and before we make the final pass through a network
> namespace to flush out all of the network devices, wait for the count of
> network devices being unregistered to drop to zero.
>
> Reported-by: Francesco Ruggeri <fruggeri@aristanetworks.com>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
> ---
>
> Francesco could you take a look at this. I am about 99% certain this is
> right but I am starting to fade. So it is entirely possible I missed
> something.
Same here ...
The logic looks right to me and I think it should address the original
issue I ran into.
Would it make sense to have netdev_unregistering and
netdev_unregistering_wait be per-namespace, and have
default_device_exit_batch only wait for the namespaces in net_list? It
would require some extra loops and locking, but it may help avoid
unnecessary waits.
Francesco
>
> net/core/dev.c | 12 ++++++++++++
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 5d702fe..c25e6f3 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5002,10 +5002,13 @@ static int dev_new_index(struct net *net)
>
> /* Delayed registration/unregisteration */
> static LIST_HEAD(net_todo_list);
> +static atomic_t netdev_unregistering = ATOMIC_INIT(0);
> +static DECLARE_WAIT_QUEUE_HEAD(netdev_unregistering_wait);
>
> static void net_set_todo(struct net_device *dev)
> {
> list_add_tail(&dev->todo_list, &net_todo_list);
> + atomic_inc(&netdev_unregistering);
> }
>
> static void rollback_registered_many(struct list_head *head)
> @@ -5673,6 +5676,9 @@ void netdev_run_todo(void)
> if (dev->destructor)
> dev->destructor(dev);
>
> + if (atomic_dec_and_test(&netdev_unregistering))
> + wake_up(&netdev_unregistering_wait);
> +
> /* Free network device */
> kobject_put(&dev->dev.kobj);
> }
> @@ -6369,7 +6375,13 @@ static void __net_exit default_device_exit_batch(struct list_head *net_list)
> struct net *net;
> LIST_HEAD(dev_kill_list);
>
> +retry:
> + wait_event(netdev_unregistering_wait, (atomic_read(&netdev_unregistering) == 0));
> rtnl_lock();
> + if (atomic_read(&netdev_unregistering) != 0) {
> + __rtnl_unlock();
> + goto retry;
> + }
> list_for_each_entry(net, net_list, exit_list) {
> for_each_netdev_reverse(net, dev) {
> if (dev->rtnl_link_ops)
> --
> 1.7.5.4
>
^ permalink raw reply
* [PATCH net] xfrm: Guard IPsec anti replay window against replay bitmap
From: Fan Du @ 2013-09-17 6:26 UTC (permalink / raw)
To: steffen.klassert; +Cc: davem, netdev
For legacy IPsec anti replay mechanism:
bitmap in struct xfrm_replay_state could only provide a 32 bits
window size limit in current design, thus user level parameter
sadb_sa_replay should honor this limit, otherwise misleading
outputs("replay=244") by setkey -D will be:
192.168.25.2 192.168.22.2
esp mode=transport spi=147561170(0x08cb9ad2) reqid=0(0x00000000)
E: aes-cbc 9a8d7468 7655cf0b 719d27be b0ddaac2
A: hmac-sha1 2d2115c2 ebf7c126 1c54f186 3b139b58 264a7331
seq=0x00000000 replay=244 flags=0x00000000 state=mature
created: Sep 17 14:00:00 2013 current: Sep 17 14:00:22 2013
diff: 22(s) hard: 30(s) soft: 26(s)
last: Sep 17 14:00:00 2013 hard: 0(s) soft: 0(s)
current: 1408(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 22 hard: 0 soft: 0
sadb_seq=1 pid=4854 refcnt=0
192.168.22.2 192.168.25.2
esp mode=transport spi=255302123(0x0f3799eb) reqid=0(0x00000000)
E: aes-cbc 6485d990 f61a6bd5 e5660252 608ad282
A: hmac-sha1 0cca811a eb4fa893 c47ae56c 98f6e413 87379a88
seq=0x00000000 replay=244 flags=0x00000000 state=mature
created: Sep 17 14:00:00 2013 current: Sep 17 14:00:22 2013
diff: 22(s) hard: 30(s) soft: 26(s)
last: Sep 17 14:00:00 2013 hard: 0(s) soft: 0(s)
current: 1408(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 22 hard: 0 soft: 0
sadb_seq=0 pid=4854 refcnt=0
And also, optimizing xfrm_replay_check window checking by setting the
desirable x->props.replay_window with only doing the comparison once
for all when xfrm_state is first born.
Signed-off-by: Fan Du <fan.du@windriver.com>
---
net/key/af_key.c | 3 ++-
net/xfrm/xfrm_replay.c | 3 +--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/key/af_key.c b/net/key/af_key.c
index 9d58537..911ef03 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -1098,7 +1098,8 @@ static struct xfrm_state * pfkey_msg2xfrm_state(struct net *net,
x->id.proto = proto;
x->id.spi = sa->sadb_sa_spi;
- x->props.replay_window = sa->sadb_sa_replay;
+ x->props.replay_window = min_t(unsigned int, sa->sadb_sa_replay,
+ (sizeof(x->replay.bitmap) * 8));
if (sa->sadb_sa_flags & SADB_SAFLAGS_NOECN)
x->props.flags |= XFRM_STATE_NOECN;
if (sa->sadb_sa_flags & SADB_SAFLAGS_DECAP_DSCP)
diff --git a/net/xfrm/xfrm_replay.c b/net/xfrm/xfrm_replay.c
index 8dafe6d3..eeca388 100644
--- a/net/xfrm/xfrm_replay.c
+++ b/net/xfrm/xfrm_replay.c
@@ -129,8 +129,7 @@ static int xfrm_replay_check(struct xfrm_state *x,
return 0;
diff = x->replay.seq - seq;
- if (diff >= min_t(unsigned int, x->props.replay_window,
- sizeof(x->replay.bitmap) * 8)) {
+ if (diff >= x->props.replay_window) {
x->stats.replay_window++;
goto err;
}
--
1.7.9.5
^ permalink raw reply related
* Re: mvneta: oops in __rcu_read_lock on mirabox
From: Willy Tarreau @ 2013-09-17 6:01 UTC (permalink / raw)
To: Ethan Tuttle
Cc: Russell King - ARM Linux, Thomas Petazzoni, Andrew Lunn,
Jason Cooper, netdev, Ezequiel Garcia, Gregory Clément,
linux-arm-kernel
In-Reply-To: <CACzLR4suLD90p=sEhB-qg1u35t66zKfrGQref1jX42fEfu3D8g@mail.gmail.com>
Hi Ethan,
On Mon, Sep 16, 2013 at 08:43:19PM -0700, Ethan Tuttle wrote:
> I just built 3.11.1 with the posted config and got the usual crash in
> about 2 minutes with a ping flood.
>
> The kernel image is available here:
>
> https://www.dropbox.com/s/cqkqop3jjb1stk3/uImage-dtb.armada-370-mirabox
OK thank you. Unfortunately I can't boot it here as my only rootfs is
a squashfs and it is not enabled in this kernel.
> The md5 is 05f350a193c6c60d9dac40bea810bbdd. You may notice the
> version string reveals a patch on top of 3.11.1, this is just a
> makefile patch to "Build a uImage with dtb already appended".
Interesting one, I was not aware of it, I'll probably add it to my
trees to stop relying on build scripts.
> Tcpdump captured about 2,800 icmp packets per second while the ping
> flood was running.
OK I've been running mine at this exact rate as well (2803 pps) for
11 minutes now. I disabled icmp_ratelimit to ensure that I got as
many responses as requests. No problem so far.
> Hope this helps! If Willy wants to share a kernel image I'll see if I
> can crash it :)
I've put my working images here :
http://1wt.eu/ethan-kernel/
One is done with my config, the other one with your config in which
I added support for squashfs and blk_dev_ram that I'm using to boot
a rootfs loaded in memory by the boot loader.
I can't make it fail either. I'm really starting to suspect a hardware
issue...
Next step should be that you test both kernels to be sure.
Cheers,
Willy
^ permalink raw reply
* Potential out-of-bounds access in ip6_finish_output2
From: Dmitry Vyukov @ 2013-09-17 5:13 UTC (permalink / raw)
To: yoshfuji, hannes, netdev, Paul Turner, Andrey Konovalov,
Kostya Serebryany, Tom Herbert
Hi,
I am working on AddressSanitizer -- a tool that detects use-after-free
and out-of-bounds bugs
(https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel).
I've got a dozen of reports in ip6_finish_output2. Below are 2 of
them. They are always followed by kernel crash. Unfortunately I don't
have a reproducer because I am using trinity fuzzer. I would
appreciate if somebody familiar with the code look at sources and
maybe spot the bug.
The reports are obtained on revision 6a7492a4b2e05051a44458d7187023e22d580666.
[ 977.765485] ERROR: AddressSanitizer: heap-buffer-overflow on
address ffff8800521e8730
[ 977.767205] ffff8800521e8730 is located 16 bytes to the left of
512-byte region [ffff8800521e8740, ffff8800521e8940)
[ 977.769399] Accessed by thread T11464:
[ 977.770274] #0 ffffffff810dd2a6 (asan_report_error+0x306/0x410)
[ 977.771570] #1 ffffffff810dc6a0 (asan_check_region+0x30/0x40)
[ 977.772883] #2 ffffffff810dc9ff (asan_memcpy+0x1f/0x60)
[ 977.774033] #3 ffffffffa0003b1c (ip6_finish_output2+0x54c/0x840 [ipv6])
[ 977.775451] #4 ffffffffa00088dc (ip6_fragment+0xe2c/0x1520 [ipv6])
[ 977.776710] #5 ffffffffa00090f7 (ip6_finish_output+0x127/0x190 [ipv6])
[ 977.777649] #6 ffffffffa00091e1 (ip6_output+0x81/0x140 [ipv6])
[ 977.778503] #7 ffffffffa000630c (ip6_local_out+0x4c/0x60 [ipv6])
[ 977.779379] #8 ffffffffa0006afd
(ip6_push_pending_frames+0x7dd/0xac0 [ipv6])
[ 977.780391] #9 ffffffffa00319de (rawv6_sendmsg+0x12ae/0x15c0 [ipv6])
[ 977.781295] #10 ffffffff818bb498 (inet_sendmsg+0x108/0x160)
[ 977.782094] #11 ffffffff817d0016 (sock_aio_write+0x296/0x2e0)
[ 977.782885] #12 ffffffff8129dcb1 (do_sync_write+0x111/0x170)
[ 977.783699] #13 ffffffff8129e9fd (vfs_write+0x2dd/0x300)
[ 977.784468] #14 ffffffff8129f9a0 (SyS_write+0x80/0xe0)
[ 977.785214] #15 ffffffff81928582 (system_call_fastpath+0x16/0x1b)
[ 977.786066]
[ 977.786284] Allocated by thread T11464:
[ 977.786858] #0 ffffffff810dc768 (asan_slab_alloc+0x48/0xc0)
[ 977.787661] #1 ffffffff81283d89 (kmem_cache_alloc_node_trace+0x99/0x4f0)
[ 977.788860] #2 ffffffff81284211 (__kmalloc_node_track_caller+0x31/0x40)
[ 977.790359] #3 ffffffff817ded6a (__kmalloc_reserve.isra.27+0x4a/0xb0)
[ 977.791800] #4 ffffffff817e0201 (__alloc_skb+0x91/0x280)
[ 977.792985] #5 ffffffff817d807a (sock_wmalloc+0x6a/0xe0)
[ 977.794183] #6 ffffffffa0005ea6 (ip6_append_data+0x1906/0x1c20 [ipv6])
[ 977.795597] #7 ffffffffa0030dd7 (rawv6_sendmsg+0x6a7/0x15c0 [ipv6])
[ 977.796831] #8 ffffffff818bb498 (inet_sendmsg+0x108/0x160)
[ 977.798035] #9 ffffffff817d0016 (sock_aio_write+0x296/0x2e0)
[ 977.799260] #10 ffffffff8129dcb1 (do_sync_write+0x111/0x170)
[ 977.800495] #11 ffffffff8129e9fd (vfs_write+0x2dd/0x300)
[ 977.801709] #12 ffffffff8129f9a0 (SyS_write+0x80/0xe0)
[ 977.802882] #13 ffffffff81928582 (system_call_fastpath+0x16/0x1b)
[ 977.804209]
[ 977.804529] Shadow bytes around the buggy address:
[ 977.805588] ffff8800521e8480: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[ 977.807192] ffff8800521e8500: 00 00 00 00 00 00 00 fb fb fb fb fb
fb fb fb fb
[ 977.808655] ffff8800521e8580: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 977.810122] ffff8800521e8600: fa fa fa fa fa fa fa fa fa fa fa fa
fa fa fa fa
[ 977.811776] ffff8800521e8680: fa fa fa fa fa fa fa fa fa fa fa fa
fa fa fa fa
[ 977.813128] =>ffff8800521e8700: fa fa fa fa fa fa[fa]fa 00 00 00 00
00 00 00 00
[ 977.814463] ffff8800521e8780: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[ 977.815625] ffff8800521e8800: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[ 977.816685] ffff8800521e8880: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[ 977.817814] ffff8800521e8900: 00 00 00 00 00 00 00 00 fa fa fa fa
fa fa fa fa
[ 977.818907] ffff8800521e8980: fa fa fa fa fa fa fa fa fa fa fa fa
fa fa fa fa
[ 977.819917] Shadow byte legend (one shadow byte represents 8
application bytes):
[ 977.820929] Addressable: 00
[ 977.821479] Partially addressable: 01 02 03 04 05 06 07
[ 977.822251] Heap redzone: fa
[ 977.822841] Heap kmalloc redzone: fb
[ 977.823414] Freed heap region: fd
[ 977.823955] Shadow gap: fe
[ 977.824512] =========================================================================
[ 977.825607] skbuff: skb_under_panic: text:ffffffffa0003b35 len:125
put:14 head:ffff8800521e8740 data:ffff8800521e8732 tail:0x6f end:0xc0
dev:lo
[ 977.827336] ------------[ cut here ]------------
[ 977.828000] kernel BUG at net/core/skbuff.c:126!
[ 977.828270] invalid opcode: 0000 [#1] SMP
[ 977.828270] Modules linked in: snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device tun 8021q snd_pcm_oss
snd_pcm snd_page_alloc snd_timer snd_mixer_oss snd sr_mod cdrom loop
bridge stp llc st ipt_ULOG nfnetlink iptable_mangle tg3 ptp pps_core
i2c_piix4 i2c_core msr cpuid e1000 ipv6
[ 977.828270] CPU: 1 PID: 11464 Comm: trinity-child28 Not tainted
3.11.0-smp-DEV #8
[ 977.828270] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[ 977.828270] task: ffff880053321280 ti: ffff880049194000 task.ti:
ffff880049194000
[ 977.828270] RIP: 0010:[<ffffffff81913878>] [<ffffffff81913878>]
skb_panic+0xd5/0xd7
[ 977.828270] RSP: 0018:ffff8800491957a0 EFLAGS: 00010286
[ 977.828270] RAX: 0000000000000083 RBX: ffff8800485be6c0 RCX: 0000000000000000
[ 977.828270] RDX: ffff880000000000 RSI: 0000000000000008 RDI: ffffffff81c44cd8
[ 977.828270] RBP: ffff880049195808 R08: 000000000000006f R09: 0000000000000000
[ 977.828270] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88005bf8b400
[ 977.828270] R13: ffff8800521e8732 R14: 000000000000006f R15: 00000000000000c0
[ 977.828270] FS: 0000000001642880(0063) GS:ffff88005fd00000(0000)
knlGS:0000000000000000
[ 977.828270] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 977.828270] CR2: 0000000000000009 CR3: 0000000049eef000 CR4: 00000000000006e0
[ 977.828270] Stack:
[ 977.828270] ffff8800521e8732 000000000000006f 00000000000000c0
ffff88005bf8b400
[ 977.828270] 0000000e485be6c0 ffffffffa0003b35 ffffffff81aa3940
ffff8800521e8740
[ 977.828270] ffff8800485be6c0 ffff8800521e8732 000000000000000e
ffff8800485be720
[ 977.828270] Call Trace:
[ 977.828270] [<ffffffffa0003b35>] ? ip6_finish_output2+0x565/0x840 [ipv6]
[ 977.828270] [<ffffffff817ddb59>] skb_push+0xa9/0xb0
[ 977.828270] [<ffffffffa0003b35>] ip6_finish_output2+0x565/0x840 [ipv6]
[ 977.828270] [<ffffffffa00088dc>] ip6_fragment+0xe2c/0x1520 [ipv6]
[ 977.828270] [<ffffffffa00035d0>] ?
ip6_flush_pending_frames+0x1d0/0x1d0 [ipv6]
[ 977.828270] [<ffffffffa00090f7>] ip6_finish_output+0x127/0x190 [ipv6]
[ 977.828270] [<ffffffffa00091e1>] ip6_output+0x81/0x140 [ipv6]
[ 977.828270] [<ffffffffa000630c>] ip6_local_out+0x4c/0x60 [ipv6]
[ 977.828270] [<ffffffff810dc689>] ? asan_check_region+0x19/0x40
[ 977.828270] [<ffffffffa0006afd>] ip6_push_pending_frames+0x7dd/0xac0 [ipv6]
[ 977.828270] [<ffffffffa00319de>] rawv6_sendmsg+0x12ae/0x15c0 [ipv6]
[ 977.828270] [<ffffffff810dc689>] ? asan_check_region+0x19/0x40
[ 977.828270] [<ffffffff818bb498>] inet_sendmsg+0x108/0x160
[ 977.828270] [<ffffffff817d0016>] sock_aio_write+0x296/0x2e0
[ 977.828270] [<ffffffff8129dcb1>] do_sync_write+0x111/0x170
[ 977.828270] [<ffffffff8129e9fd>] vfs_write+0x2dd/0x300
[ 977.828270] [<ffffffff8129f9a0>] SyS_write+0x80/0xe0
[ 977.828270] [<ffffffff81928582>] system_call_fastpath+0x16/0x1b
[ 977.828270] Code: c7 f0 a2 ba 81 44 8b 45 bc 48 8b 55 c0 31 c0 48
8b 75 c8 4c 89 64 24 18 4c 89 7c 24 10 4c 89 74 24 08 4c 89 2c 24 e8
7d 73 ff ff <0f> 0b 55 48 89 e5 48 8b 7d 08 e8 39 9b 7c ff 0f 0b 55 48
89 e5
[ 977.828270] RIP [<ffffffff81913878>] skb_panic+0xd5/0xd7
[ 977.828270] RSP <ffff8800491957a0>
[ 977.871681] ---[ end trace 20970757dd5daf11 ]---
[ 521.772929] ERROR: AddressSanitizer: heap-buffer-overflow on
address ffff88004965fbe8
[ 521.774073] ffff88004965fbe8 is located 24 bytes to the left of
512-byte region [ffff88004965fc00, ffff88004965fe00)
[ 521.775741] Accessed by thread T2167:
[ 521.776475] #0 ffffffff810dd2a6 (asan_report_error+0x306/0x410)
[ 521.777728] #1 ffffffff810dc6a0 (asan_check_region+0x30/0x40)
[ 521.778966] #2 ffffffff810dc9ff (asan_memcpy+0x1f/0x60)
[ 521.780145] #3 ffffffffa0003b1c (ip6_finish_output2+0x54c/0x840 [ipv6])
[ 521.781570] #4 ffffffffa00088dc (ip6_fragment+0xe2c/0x1520 [ipv6])
[ 521.782912] #5 ffffffffa00090f7 (ip6_finish_output+0x127/0x190 [ipv6])
[ 521.784032] #6 ffffffffa00091e1 (ip6_output+0x81/0x140 [ipv6])
[ 521.785157] #7 ffffffffa000630c (ip6_local_out+0x4c/0x60 [ipv6])
[ 521.786460] #8 ffffffffa0006afd
(ip6_push_pending_frames+0x7dd/0xac0 [ipv6])
[ 521.787977] #9 ffffffffa00319de (rawv6_sendmsg+0x12ae/0x15c0 [ipv6])
[ 521.789366] #10 ffffffff818bb498 (inet_sendmsg+0x108/0x160)
[ 521.790597] #11 ffffffff817d0016 (sock_aio_write+0x296/0x2e0)
[ 521.791826] #12 ffffffff8129dcb1 (do_sync_write+0x111/0x170)
[ 521.792975] #13 ffffffff8129e9fd (vfs_write+0x2dd/0x300)
[ 521.793821] #14 ffffffff8129f9a0 (SyS_write+0x80/0xe0)
[ 521.794684] #15 ffffffff81928582 (system_call_fastpath+0x16/0x1b)
[ 521.795640]
[ 521.795878] Allocated by thread T6026:
[ 521.796474] #0 ffffffff810dc768 (asan_slab_alloc+0x48/0xc0)
[ 521.797360] #1 ffffffff81283d89 (kmem_cache_alloc_node_trace+0x99/0x4f0)
[ 521.798365] #2 ffffffff81284211 (__kmalloc_node_track_caller+0x31/0x40)
[ 521.799406] #3 ffffffff817ded6a (__kmalloc_reserve.isra.27+0x4a/0xb0)
[ 521.800436] #4 ffffffff817e0201 (__alloc_skb+0x91/0x280)
[ 521.801328] #5 ffffffff817d807a (sock_wmalloc+0x6a/0xe0)
[ 521.802170] #6 ffffffffa0005ea6 (ip6_append_data+0x1906/0x1c20 [ipv6])
[ 521.803073] #7 ffffffffa0030dd7 (rawv6_sendmsg+0x6a7/0x15c0 [ipv6])
[ 521.804068] #8 ffffffff818bb498 (inet_sendmsg+0x108/0x160)
[ 521.804919] #9 ffffffff817d18e3 (sock_sendmsg+0x133/0x170)
[ 521.805760] #10 ffffffff817d2009 (SYSC_sendto+0x1e9/0x2d0)
[ 521.806618] #11 ffffffff817d2cc9 (SyS_sendto+0x49/0x70)
[ 521.807598] #12 ffffffff81928582 (system_call_fastpath+0x16/0x1b)
[ 521.808826]
[ 521.809188] Shadow bytes around the buggy address:
[ 521.810231] ffff88004965f900: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[ 521.811752] ffff88004965f980: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[ 521.813253] ffff88004965fa00: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[ 521.814743] ffff88004965fa80: 00 00 00 00 00 00 00 00 fa fa fa fa
fa fa fa fa
[ 521.816052] ffff88004965fb00: fa fa fa fa fa fa fa fa fa fa fa fa
fa fa fa fa
[ 521.817113] =>ffff88004965fb80: fa fa fa fa fa fa fa fa fa fa fa fa
fa[fa]fa fa
[ 521.818149] ffff88004965fc00: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[ 521.819224] ffff88004965fc80: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[ 521.820280] ffff88004965fd00: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[ 521.821357] ffff88004965fd80: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[ 521.822398] ffff88004965fe00: fa fa fa fa fa fa fa fa fa fa fa fa
fa fa fa fa
[ 521.823392] Shadow byte legend (one shadow byte represents 8
application bytes):
[ 521.824388] Addressable: 00
[ 521.824901] Partially addressable: 01 02 03 04 05 06 07
[ 521.825667] Heap redzone: fa
[ 521.826260] Heap kmalloc redzone: fb
[ 521.826802] Freed heap region: fd
[ 521.827347] Shadow gap: fe
[ 521.827884] =========================================================================
[ 521.828976] skbuff: skb_under_panic: text:ffffffffa0003b35 len:133
put:14 head:ffff88004965fc00 data:ffff88004965fbea tail:0x6f end:0xc0
dev:lo
[ 521.830736] ------------[ cut here ]------------
[ 521.831372] kernel BUG at net/core/skbuff.c:126!
Dec 31 18[:5 4: 035 21.831680] invalid opcode: 0000 [#1] SMP
[ 521.831680] Modules linked in: snd_mixer_oss snd sr_mod cdrom loop
tun 8021qasa n3b krerinedl:g [e 5s21t.8p28976] slkblc st ipt_ULOG
nfnetlink iptable_mangle tg3 ptp pps_core i2c_piix4 i2c_core msr cpuid
e1000 ipv6
[ 521.831680] CPU: 1 PID: 2167 Comm: trinity-child52 Not tainted
3.11.0-smp-DEV #8
[ 521.831680] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
uff:[ s kb _u5nd2er1_p.831680] task: ffff88004b720be0 ti:
ffff88004fc54000 task.ti: ffff88004fc54000
[ 521.831680] RIP: 0010:[<ffffffff81913878>] anic :
[te<xtf:ffffffffffff81913878>] skb_panic+0xd5/0xd7
[ 521.831680] RSP: 0018:ffff88004fc557a0 EFLAGS: 00010286
fffa[00 03 b355 2le1n:.831680] RAX: 0000000000000083 RBX:
ffff88004a919d80 RCX: 0000000000000000
[ 521.831680] RDX: ffff880000000000 RSI: 0000000000000008 RDI: ffffffff81c44cd8
133 [pu t: 145 h2ea1d:.831680] RBP: ffff88004fc55808 R08:
000000000000006f R09: 0000000000000000
[fff f8 8050429615f.c08031680] R10: 0000000000000000 R11:
0000000007f70a60 R12: ffff88005bf89400
[ 521.831680] R13: ffff88004965fbea R14: 000000000000006f R15: 00000000000000c0
d[at a: ff5ff8280104.9831680] FS: 0000000001a48880(0063)
GS:ffff88005fd00000(0000) knlGS:0000000000000000
[ 521.831680] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 521.831680] CR2: 0000000000000000 CR3: 0000000013404000 CR4: 00000000000006e0
65fbe[a ta il52:01x.6f831680] Stack:
[ 521.831680] ffff88004965fbea 000000000000006f en d:00x0c00
d0ev0:l0o00000000c0 ffff88005bf89400
[ 521.831680] 0000000e4a919d80 ffffffffa0003b35 ffffffff81aa3940
ffff88004965fc00
[ 521.831680] ffff88004a919d80 ffff88004965fbea 000000000000000e
ffff88004a919de0
[ 521.831680] Call Trace:
[ 521.831680] [<ffffffffa0003b35>] ? ip6_finish_output2+0x565/0x840 [ipv6]
[ 521.831680] [<ffffffff817ddb59>] skb_push+0xa9/0xb0
[ 521.831680] [<ffffffffa0003b35>] ip6_finish_output2+0x565/0x840 [ipv6]
[ 521.831680] [<ffffffffa00088dc>] ip6_fragment+0xe2c/0x1520 [ipv6]
[ 521.831680] [<ffffffffa00035d0>] ?
ip6_flush_pending_frames+0x1d0/0x1d0 [ipv6]
[ 521.831680] [<ffffffff810dcd19>] ? asan_region_is_poisoned+0x89/0x1a0
[ 521.831680] [<ffffffffa00090f7>] ip6_finish_output+0x127/0x190 [ipv6]
[ 521.831680] [<ffffffffa00091e1>] ip6_output+0x81/0x140 [ipv6]
[ 521.831680] [<ffffffffa000630c>] ip6_local_out+0x4c/0x60 [ipv6]
[ 521.831680] [<ffffffff810dc689>] ? asan_check_region+0x19/0x40
[ 521.831680] [<ffffffffa0006afd>] ip6_push_pending_frames+0x7dd/0xac0 [ipv6]
[ 521.831680] [<ffffffffa00319de>] rawv6_sendmsg+0x12ae/0x15c0 [ipv6]
[ 521.831680] [<ffffffff810dc689>] ? asan_check_region+0x19/0x40
[ 521.831680] [<ffffffff818bb498>] inet_sendmsg+0x108/0x160
[ 521.831680] [<ffffffff817d0016>] sock_aio_write+0x296/0x2e0
[ 521.831680] [<ffffffff8129dcb1>] do_sync_write+0x111/0x170
[ 521.831680] [<ffffffff8129e9fd>] vfs_write+0x2dd/0x300
[ 521.831680] [<ffffffff8129f9a0>] SyS_write+0x80/0xe0
[ 521.831680] [<ffffffff81928582>] system_call_fastpath+0x16/0x1b
[ 521.831680] Code: c7 f0 a2 ba 81 44 8b 45 bc 48 8b 55 c0 31 c0 48
8b 75 c8 4c 89 64 24 18 4c 89 7c 24 10 4c 89 74 24 08 4c 89 2c 24 e8
7d 73 ff ff <0f> 0b 55 48 89 e5 48 8b 7d 08 e8 39 9b 7c ff 0f 0b 55 48
89 e5
[ 521.831680] RIP [<ffffffff81913878>] skb_panic+0xd5/0xd7
[ 521.831680] RSP <ffff88004fc557a0>
[ 521.876810] ---[ end trace 4037fd48810bceeb ]---
^ permalink raw reply
* Re: [PATCH 1/1] net: race condition when removing virtual net_device
From: Francesco Ruggeri @ 2013-09-17 5:12 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David S. Miller, Eric Dumazet, Jiri Pirko, Alexander Duyck,
Cong Wang, netdev
In-Reply-To: <87r4cocn0n.fsf@xmission.com>
On Mon, Sep 16, 2013 at 5:25 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
>
> If you could verify that my patch to dev_close solves the ordering
> issues you were seeing I would appreciate that.
>
I have not run extensive tests, but your patch fixes the reordering
issue I was seeing in dev_close_many. When I destroyed a namespace
with only v0 and lo the order was preserved from
unregister_netdevice_many to netdev_run_todo.
Francesco
====== lo down, v0 down
unregister_netdevice_queue: v0 (ns ffff880136bc8000)
unregister_netdevice_queue: lo (ns ffff880136bc8000)
unregister_netdevice_many: v0 (ns ffff880136bc8000) lo (ns ffff880136bc8000)
netdev_run_todo: v0 (ns ffff880136bc8000) lo (ns ffff880136bc8000)
====== lo up, v0 down
unregister_netdevice_queue: v0 (ns ffff880037ac8000)
unregister_netdevice_queue: lo (ns ffff880037ac8000)
unregister_netdevice_many: v0 (ns ffff880037ac8000) lo (ns ffff880037ac8000)
netdev_run_todo: v0 (ns ffff880037ac8000) lo (ns ffff880037ac8000)
====== lo down, v0 up
unregister_netdevice_queue: v0 (ns ffff880136bc8000)
unregister_netdevice_queue: lo (ns ffff880136bc8000)
unregister_netdevice_many: v0 (ns ffff880136bc8000) lo (ns ffff880136bc8000)
netdev_run_todo: v0 (ns ffff880136bc8000) lo (ns ffff880136bc8000)
====== lo up, v0 up
unregister_netdevice_queue: v0 (ns ffff880037ac8000)
unregister_netdevice_queue: lo (ns ffff880037ac8000)
unregister_netdevice_many: v0 (ns ffff880037ac8000) lo (ns ffff880037ac8000)
netdev_run_todo: v0 (ns ffff880037ac8000) lo (ns ffff880037ac8000)
^ permalink raw reply
* Re: Why we discard all rtt samples when only some of the acked skbs have been retransmited in processing ack?
From: Eric Dumazet @ 2013-09-17 5:11 UTC (permalink / raw)
To: LovelyLich, Yuchung Cheng; +Cc: netdev
In-Reply-To: <CAAA3+BpsxtyM2uAvX6B4ys73ZC6fX5K1ib3Acsk0fp5cQBNgWg@mail.gmail.com>
On Tue, 2013-09-17 at 12:01 +0800, LovelyLich wrote:
> Hi Eric,
>
> In tcp_clean_rtx_queue(), we set the flag FLAG_RETRANS_DATA_ACKED when we
>
> encounter one ever retransmited skb A. But if there is one( or more) skb B
>
> after this retransmited skb, and we calculate the rtt for skb B. The question
>
> is because we have set the flag FLAG_RETRANS_DATA_ACKED, and we will just
>
> return in tcp_ack_no_tstamp() !
>
> Two questions:
>
> 1. if we will just ignore all packets in this ack, we do not need to calculate
>
> skb B's rtt sample.
>
> 2. what I want to know, even if A's rtt sample is not reliable, but B's rtt
>
> sample can be trusted. Why we discard it ?
>
>
>
> Thanks in advanced.
>
Good point !
Yuchung, what do you think of following patch ?
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 25a89ea..7f12b96 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2971,7 +2971,7 @@ static int tcp_clean_rtx_queue(struct sock *sk, int prior_fackets,
struct sk_buff *skb;
u32 now = tcp_time_stamp;
int fully_acked = true;
- int flag = 0;
+ int flag = FLAG_RETRANS_DATA_ACKED;
u32 pkts_acked = 0;
u32 reord = tp->packets_out;
u32 prior_sacked = tp->sacked_out;
@@ -3002,7 +3002,6 @@ static int tcp_clean_rtx_queue(struct sock *sk, int prior_fackets,
if (sacked & TCPCB_RETRANS) {
if (sacked & TCPCB_SACKED_RETRANS)
tp->retrans_out -= acked_pcount;
- flag |= FLAG_RETRANS_DATA_ACKED;
} else {
ca_seq_rtt = now - scb->when;
last_ackt = skb->tstamp;
@@ -3013,6 +3012,7 @@ static int tcp_clean_rtx_queue(struct sock *sk, int prior_fackets,
reord = min(pkts_acked, reord);
if (!after(scb->end_seq, tp->high_seq))
flag |= FLAG_ORIG_SACK_ACKED;
+ flag &= ~FLAG_RETRANS_DATA_ACKED;
}
if (sacked & TCPCB_SACKED_ACKED)
^ permalink raw reply related
* [CFT][PATCH] net: Delay default_device_exit_batch until no devices are unregistering
From: Eric W. Biederman @ 2013-09-17 3:49 UTC (permalink / raw)
To: Francesco Ruggeri
Cc: David S. Miller, Eric Dumazet, Jiri Pirko, Alexander Duyck,
Cong Wang, netdev
In-Reply-To: <CA+HUmGih9akzhpRrb_0WEapi4jGcuSV8qO==QeRWHoqnxzFyng@mail.gmail.com>
The implementation is a little rough but the logic should be right.
Device registration and unregistration is serialized with the rtnl_lock.
The final pieces of device unregistration do not happen under the
rtnl_lock resulting in the possibility that while we wait for the
refcount of a device to drop to zero the network namespace is
unregistered while no locks are held.
Prevent that by keeping a count of the network devices that are being
unregistered and before we make the final pass through a network
namespace to flush out all of the network devices, wait for the count of
network devices being unregistered to drop to zero.
Reported-by: Francesco Ruggeri <fruggeri@aristanetworks.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
Francesco could you take a look at this. I am about 99% certain this is
right but I am starting to fade. So it is entirely possible I missed
something.
net/core/dev.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 5d702fe..c25e6f3 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5002,10 +5002,13 @@ static int dev_new_index(struct net *net)
/* Delayed registration/unregisteration */
static LIST_HEAD(net_todo_list);
+static atomic_t netdev_unregistering = ATOMIC_INIT(0);
+static DECLARE_WAIT_QUEUE_HEAD(netdev_unregistering_wait);
static void net_set_todo(struct net_device *dev)
{
list_add_tail(&dev->todo_list, &net_todo_list);
+ atomic_inc(&netdev_unregistering);
}
static void rollback_registered_many(struct list_head *head)
@@ -5673,6 +5676,9 @@ void netdev_run_todo(void)
if (dev->destructor)
dev->destructor(dev);
+ if (atomic_dec_and_test(&netdev_unregistering))
+ wake_up(&netdev_unregistering_wait);
+
/* Free network device */
kobject_put(&dev->dev.kobj);
}
@@ -6369,7 +6375,13 @@ static void __net_exit default_device_exit_batch(struct list_head *net_list)
struct net *net;
LIST_HEAD(dev_kill_list);
+retry:
+ wait_event(netdev_unregistering_wait, (atomic_read(&netdev_unregistering) == 0));
rtnl_lock();
+ if (atomic_read(&netdev_unregistering) != 0) {
+ __rtnl_unlock();
+ goto retry;
+ }
list_for_each_entry(net, net_list, exit_list) {
for_each_netdev_reverse(net, dev) {
if (dev->rtnl_link_ops)
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] ethernet/arc/arc_emac: Fix huge delays in large file copies
From: David Miller @ 2013-09-17 4:17 UTC (permalink / raw)
To: Vineet.Gupta1; +Cc: gregkh, netdev, Alexey.Brodkin, linux-kernel, stable
In-Reply-To: <C2D7FE5348E1B147BCA15975FBA2307514C1F4@IN01WEMBXA.internal.synopsys.com>
From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Date: Tue, 17 Sep 2013 04:07:23 +0000
> Can you please do the needful for stable 3.11 backport of this patch.
Queued up for -stable.
^ permalink raw reply
* Re: [PATCH] ethernet/arc/arc_emac: Fix huge delays in large file copies
From: Vineet Gupta @ 2013-09-17 4:07 UTC (permalink / raw)
To: David Miller
Cc: greg Kroah-Hartman, netdev@vger.kernel.org,
Alexey.Brodkin@synopsys.com, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <20130916194012.GA23656@kroah.com>
On 09/17/2013 01:10 AM, greg Kroah-Hartman wrote:
> On Mon, Sep 16, 2013 at 11:13:48AM +0530, Vineet Gupta wrote:
>> On 09/10/2013 11:57 AM, Vineet Gupta wrote:
>>> On 09/05/2013 11:55 PM, David Miller wrote:
>>>> From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
>>>> Date: Wed, 4 Sep 2013 17:17:15 +0530
>>>>
>>>>> copying large files to a NFS mounted host was taking absurdly large
>>>>> time.
>>>>>
>>>>> Turns out that TX BD reclaim had a sublte bug.
>>>>>
>>>>> Loop starts off from @txbd_dirty cursor and stops when it hits a BD
>>>>> still in use by controller. However when it stops it needs to keep the
>>>>> cursor at that very BD to resume scanning in next iteration. However it
>>>>> was erroneously incrementing the cursor, causing the next scan(s) to
>>>>> fail too, unless the BD chain was completely drained out.
>>>>>
>>>>> [ARCLinux]$ ls -l -sh /disk/log.txt
>>>>> 17976 -rw-r--r-- 1 root root 17.5M Sep /disk/log.txt
>>>>>
>>>>> ========== Before =====================
>>>>> [ARCLinux]$ time cp /disk/log.txt /mnt/.
>>>>> real 31m 7.95s
>>>>> user 0m 0.00s
>>>>> sys 0m 0.10s
>>>>>
>>>>> ========== After =====================
>>>>> [ARCLinux]$ time cp /disk/log.txt /mnt/.
>>>>> real 0m 24.33s
>>>>> user 0m 0.00s
>>>>> sys 0m 0.19s
>>>>>
>>>>> Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
>>>> Applied.
>>>>
>>> Hi Greg,
>>>
>>> This needs a stable backport (3.11).
>>> Mainline commit 27082ee1b92f4d41e78b85
>>>
>>> Thx,
>>> -Vineet
>> Hi Greg,
>>
>> I didn't spot this one in your stable-queue for 3.11.
>> Please apply.
> Network patches for the stable tree needs to go through the networking
> maintainer. Please let them know about this and they will forward it on
> to me if needed.
>
> thanks,
>
> greg k-h
Hi David,
Can you please do the needful for stable 3.11 backport of this patch.
Thx,
-Vineet
^ permalink raw reply
* Why we discard all rtt samples when only some of the acked skbs have been retransmited in processing ack?
From: LovelyLich @ 2013-09-17 4:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
Hi Eric,
In tcp_clean_rtx_queue(), we set the flag FLAG_RETRANS_DATA_ACKED when we
encounter one ever retransmited skb A. But if there is one( or more) skb B
after this retransmited skb, and we calculate the rtt for skb B. The question
is because we have set the flag FLAG_RETRANS_DATA_ACKED, and we will just
return in tcp_ack_no_tstamp() !
Two questions:
1. if we will just ignore all packets in this ack, we do not need to calculate
skb B's rtt sample.
2. what I want to know, even if A's rtt sample is not reliable, but B's rtt
sample can be trusted. Why we discard it ?
Thanks in advanced.
regards,
Yi
^ 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