* Re: [PATCH v2] ipv6: fix incorrect ipsec fragment
From: David Miller @ 2012-05-27 5:12 UTC (permalink / raw)
To: gaofeng; +Cc: netdev, steffen.klassert, lw
In-Reply-To: <1338031853-24938-1-git-send-email-gaofeng@cn.fujitsu.com>
From: Gao feng <gaofeng@cn.fujitsu.com>
Date: Sat, 26 May 2012 19:30:53 +0800
> Since commit ad0081e43a
> "ipv6: Fragment locally generated tunnel-mode IPSec6 packets as needed"
> the fragment of packets is incorrect.
> because tunnel mode needs IPsec headers and trailer for all fragments,
> while on transport mode it is sufficient to add the headers to the
> first fragment and the trailer to the last.
>
> so modify mtu and maxfraglen base on ipsec mode and if fragment is first
> or last.
>
> with my test,it work well(every fragment's size is the mtu)
> and does not trigger slow fragment path.
>
> Changes from v1:
> though optimization, mtu_prev and maxfraglen_prev can be delete.
> replace xfrm mode codes with dst_entry's new frag DST_XFRM_TUNNEL.
> add fuction ip6_append_data_mtu to make codes clearer.
>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Applied, and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] Bluetooth: Really fix registering hci with duplicate name
From: Marcel Holtmann @ 2012-05-27 7:10 UTC (permalink / raw)
To: Sasha Levin
Cc: gustavo-THi1TnShQwVAfugRpC6u6w,
johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1338060231-31108-1-git-send-email-levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Sasha,
> Commit fc50744 ("Bluetooth: Fix registering hci with duplicate name") didn't
> fully fix the duplicate naming issue with devices, and duplicate device names
> could still be created:
>
> [ 142.484097] device: 'hci1': device_add
> [...]
> [ 150.545263] device: 'hci1': device_add
> [ 150.550128] kobject: 'hci1' (ffff880014cc4e58): kobject_add_internal: parent: 'bluetooth', set: 'devices'
> [ 150.558979] ------------[ cut here ]------------
> [ 150.561438] WARNING: at fs/sysfs/dir.c:529 sysfs_add_one+0xb0/0xd0()
> [ 150.572974] Hardware name: Bochs
> [ 150.580502] sysfs: cannot create duplicate filename '/devices/virtual/bluetooth/hci1'
> [ 150.584444] Pid: 7563, comm: trinity-child1 Tainted: G W 3.4.0-next-20120524-sasha #296
> [...]
>
> Instead of the weird logic and the attempt at keeping the device list sorted,
> just use an IDA.
>
> Signed-off-by: Sasha Levin <levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> net/bluetooth/hci_core.c | 30 ++++++++++++++++--------------
> 1 files changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 9c586fb..eca6dd1 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -26,6 +26,7 @@
> /* Bluetooth HCI core. */
>
> #include <linux/export.h>
> +#include <linux/idr.h>
>
> #include <linux/rfkill.h>
>
> @@ -46,6 +47,9 @@ DEFINE_RWLOCK(hci_dev_list_lock);
> LIST_HEAD(hci_cb_list);
> DEFINE_RWLOCK(hci_cb_list_lock);
>
> +/* HCI ID Numbering */
> +static DEFINE_IDA(hci_index_ida);
> +
> /* ---- HCI notifications ---- */
>
> static void hci_notify(struct hci_dev *hdev, int event)
> @@ -1689,7 +1693,6 @@ EXPORT_SYMBOL(hci_free_dev);
> /* Register HCI device */
> int hci_register_dev(struct hci_dev *hdev)
> {
> - struct list_head *head, *p;
> int id, error;
>
> if (!hdev->open || !hdev->close)
> @@ -1701,25 +1704,19 @@ int hci_register_dev(struct hci_dev *hdev)
> * so the index can be used as the AMP controller ID.
> */
> id = (hdev->dev_type == HCI_BREDR) ? 0 : 1;
> - head = &hci_dev_list;
>
> - /* Find first available device id */
> - list_for_each(p, &hci_dev_list) {
> - int nid = list_entry(p, struct hci_dev, list)->id;
> - if (nid > id)
> - break;
> - if (nid == id)
> - id++;
> - head = p;
> - }
> + error = ida_simple_get(&hci_index_ida, id, 0, GFP_KERNEL);
> + if (error < 0)
> + return error;
>
> + id = error;
I do not really like this "error" thing here.
Why not something simple like this:
switch (hdev->dev_type) {
case HCI_BREDR:
id = ida_simple_get(&hci_index_ida, 0, 0, GFP_KERNEL);
break;
case HCI_AMP:
id = ida_simple_get(&hci_index_idx, 1, 0, GFP_KERNEL);
break;
default:
return -EINVAL;
}
if (id < 0)
return id;
It would have the side effect to also check for valid dev_type at the
same time.
Or just just an extra variable start_id to avoid the "error" naming for
what is expected to be a positive result in almost all cases.
> sprintf(hdev->name, "hci%d", id);
> hdev->id = id;
>
> BT_DBG("%p name %s bus %d", hdev, hdev->name, hdev->bus);
>
> - list_add(&hdev->list, head);
> -
> + write_lock(&hci_dev_list_lock);
> + list_add(&hdev->list, &hci_dev_list);
> write_unlock(&hci_dev_list_lock);
>
> hdev->workqueue = alloc_workqueue(hdev->name, WQ_HIGHPRI | WQ_UNBOUND |
> @@ -1755,6 +1752,7 @@ int hci_register_dev(struct hci_dev *hdev)
> err_wqueue:
> destroy_workqueue(hdev->workqueue);
> err:
> + ida_simple_remove(&hci_index_ida, hdev->id);
> write_lock(&hci_dev_list_lock);
> list_del(&hdev->list);
> write_unlock(&hci_dev_list_lock);
> @@ -1766,12 +1764,14 @@ EXPORT_SYMBOL(hci_register_dev);
> /* Unregister HCI device */
> void hci_unregister_dev(struct hci_dev *hdev)
> {
> - int i;
> + int i, id;
>
> BT_DBG("%p name %s bus %d", hdev, hdev->name, hdev->bus);
>
> set_bit(HCI_UNREGISTER, &hdev->dev_flags);
>
> + id = hdev->id;
> +
> write_lock(&hci_dev_list_lock);
> list_del(&hdev->list);
> write_unlock(&hci_dev_list_lock);
> @@ -1812,6 +1812,8 @@ void hci_unregister_dev(struct hci_dev *hdev)
> hci_dev_unlock(hdev);
>
> hci_dev_put(hdev);
> +
> + ida_simple_remove(&hci_index_ida, id);
> }
> EXPORT_SYMBOL(hci_unregister_dev);
>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] net: compute a more reasonable default ip6_rt_max_size
From: Eric Dumazet @ 2012-05-27 13:18 UTC (permalink / raw)
To: Arun Sharma; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <4FC1A57A.7080807@fb.com>
On Sat, 2012-05-26 at 20:54 -0700, Arun Sharma wrote:
> On 5/25/12 8:39 PM, Eric Dumazet wrote:
> >
> > But your patch is not a "modest increase", so whats the deal ?
> >
> > A modest increase would be 8192 instead of 4096, regardless of RAM size.
> >
>
> Yes - 8192 solves our immediate problem, but I was worrying that the
> problem might resurface as ipv6 adoption becomes more widespread.
>
Going from 4096 to 8192 is modest increase. If you put 65536, it should
be enough for the next years.
Your patch was increasing 4096 to 524288 (for 2GB of ram), which sounds
not modest at all.
> We were testing a pre-3.0 kernel that didn't have Dave's DST_NOCOUNT
> patch. Will retest with that patch applied.
Good
>
> > More over, a boot parameter to tweak it is absolutely not needed
>
> Agreed. Will remove that part.
>
> Still not sure why you'd like to go for one size regardless of
> totalram_pages.
Because size of IPv6 route table is not depending on RAM size, but on
number or IPv6 routes.
A router runs a piece of software complex enough to be able to adjust
the limit when needed, don't you think so ?
Your patch basically removes the whole idea of having a limit in the
first place. Why do we have a limit if you set it to four order of
magnitudes bigger than necessary ?
^ permalink raw reply
* Re: WARNING: at net/ipv4/tcp.c:1610 tcp_recvmsg+0xb1b/0xc70()
From: Eric Dumazet @ 2012-05-27 13:59 UTC (permalink / raw)
To: Jack Stone; +Cc: davem, netdev, Linux Kernel
In-Reply-To: <4FC0BCE1.6070601@fastmail.fm>
On Sat, 2012-05-26 at 12:22 +0100, Jack Stone wrote:
> I'm still getting this with da89fb1 which includes the above
>
> Linux hover1 3.4.0-07797-gda89fb1 #4 SMP Fri May 25 22:23:14 BST 2012 x86_64 x86_64 x86_64 GNU/Linux
Thanks
Could you add following debugging patch ?
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 3ba605f..b56c63c 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1606,8 +1606,9 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
if (tcp_hdr(skb)->fin)
goto found_fin_ok;
WARN(!(flags & MSG_PEEK),
- "recvmsg bug 2: copied %X seq %X rcvnxt %X fl %X\n",
- *seq, TCP_SKB_CB(skb)->seq, tp->rcv_nxt, flags);
+ "recvmsg bug 2: copied %X seq %X end_seq %X rcvnxt %X fl %X offset %u len %u syn %d\n",
+ *seq, TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb)->end_seq,
+ tp->rcv_nxt, flags, offset, skb->len, tcp_hdr(skb)->syn);
}
/* Well, if we have backlog, try to process it now yet. */
^ permalink raw reply related
* [RFC] skb: avoid unnecessary reallocations in __skb_cow
From: Felix Fietkau @ 2012-05-27 15:26 UTC (permalink / raw)
To: netdev
At the beginning of __skb_cow, headroom gets set to a minimum of
NET_SKB_PAD. This causes unnecessary reallocations if the buffer was not
cloned and the headroom is just below NET_SKB_PAD, but still more than the
amount requested by the caller.
This was showing up frequently in my tests on VLAN tx, where
vlan_insert_tag calls skb_cow_head(skb, VLAN_HLEN).
Fix this by only setting the headroom delta if either there is less
headroom than specified by the caller, or if reallocation has to be done
anyway because the skb was cloned.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
include/linux/skbuff.h | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 0e50171..1898471 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1894,12 +1894,15 @@ static inline int skb_clone_writable(const struct sk_buff *skb, unsigned int len
static inline int __skb_cow(struct sk_buff *skb, unsigned int headroom,
int cloned)
{
+ unsigned int alloc_headroom = headroom;
int delta = 0;
if (headroom < NET_SKB_PAD)
- headroom = NET_SKB_PAD;
- if (headroom > skb_headroom(skb))
- delta = headroom - skb_headroom(skb);
+ alloc_headroom = NET_SKB_PAD;
+ if (headroom > skb_headroom(skb) ||
+ (cloned && alloc_headroom > skb_headroom(skb))) {
+ delta = alloc_headroom - skb_headroom(skb);
+ }
if (delta || cloned)
return pskb_expand_head(skb, ALIGN(delta, NET_SKB_PAD), 0,
--
1.7.3.2
^ permalink raw reply related
* Re: WARNING: at net/ipv4/tcp.c:1610 tcp_recvmsg+0xb1b/0xc70()
From: Jack Stone @ 2012-05-27 15:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev, Linux Kernel
In-Reply-To: <1338127184.3670.50.camel@edumazet-glaptop>
On 05/27/2012 02:59 PM, Eric Dumazet wrote:
> On Sat, 2012-05-26 at 12:22 +0100, Jack Stone wrote:
>
>> I'm still getting this with da89fb1 which includes the above
>>
>> Linux hover1 3.4.0-07797-gda89fb1 #4 SMP Fri May 25 22:23:14 BST 2012 x86_64 x86_64 x86_64 GNU/Linux
>
> Thanks
>
> Could you add following debugging patch ?
>
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 3ba605f..b56c63c 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -1606,8 +1606,9 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
> if (tcp_hdr(skb)->fin)
> goto found_fin_ok;
> WARN(!(flags & MSG_PEEK),
> - "recvmsg bug 2: copied %X seq %X rcvnxt %X fl %X\n",
> - *seq, TCP_SKB_CB(skb)->seq, tp->rcv_nxt, flags);
> + "recvmsg bug 2: copied %X seq %X end_seq %X rcvnxt %X fl %X offset %u len %u syn %d\n",
> + *seq, TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb)->end_seq,
> + tp->rcv_nxt, flags, offset, skb->len, tcp_hdr(skb)->syn);
> }
>
> /* Well, if we have backlog, try to process it now yet. */
>
>
uname: Linux hover1 3.4.0-07822-g786f02b-dirty #1 SMP Sun May 27 15:23:39 BST 2012 x86_64 x86_64 x86_64 GNU/Linux
Here's the new output:
May 27 16:32:30 hover1 kernel: [ 1907.804613] ------------[ cut here ]------------
May 27 16:32:30 hover1 kernel: [ 1907.804622] WARNING: at net/ipv4/tcp.c:1611 tcp_recvmsg+0xb36/0xc90()
May 27 16:32:30 hover1 kernel: [ 1907.804624] Hardware name: System Product Name
May 27 16:32:30 hover1 kernel: [ 1907.804626] recvmsg bug 2: copied 8F322DEB seq 8F322DEB end_seq 8F322F2A rcvnxt 8F322F2A fl 0 offset 4294967295 len 319 syn 1
May 27 16:32:30 hover1 kernel: [ 1907.804665] Modules linked in: fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle bridge rfcomm lockd 8021q garp stp llc bnep ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_netbios_ns nf_conntrack_broadcast ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack snd_hda_codec_hdmi snd_hda_codec_realtek coretemp vhost_net macvtap macvlan tun virtio_net kvm_intel snd_hda_intel kvm snd_hda_codec btusb bluetooth snd_hwdep e1000e snd_seq eeepc_wmi asus_wmi sparse_keymap microcode r8712u(C) snd_seq_device rfkill snd_pcm joydev sunrpc snd_timer snd mxm_wmi hid_logitech_dj iTCO_wdt wmi iTCO_vendor_support i2c_i801 soundcore snd_page_alloc binfmt_misc serio_raw pcspkr uinput crc32c_intel ghash
_clmulni_intel firewire_ohci firewire_core crc_itu_t [last unloaded: scsi_wait_scan]
May 27 16:32:30 hover1 kernel: [ 1907.804669] Pid: 2275, comm: thunderbird-bin Tainted: G C 3.4.0-07822-g786f02b-dirty #1
May 27 16:32:30 hover1 kernel: [ 1907.804670] Call Trace:
May 27 16:32:30 hover1 kernel: [ 1907.804674] [<ffffffff8106010f>] warn_slowpath_common+0x7f/0xc0
May 27 16:32:30 hover1 kernel: [ 1907.804676] [<ffffffff81060206>] warn_slowpath_fmt+0x46/0x50
May 27 16:32:30 hover1 kernel: [ 1907.804679] [<ffffffff8163f7f5>] ? tcp_recvmsg+0x35/0xc90
May 27 16:32:30 hover1 kernel: [ 1907.804681] [<ffffffff816402f6>] tcp_recvmsg+0xb36/0xc90
May 27 16:32:30 hover1 kernel: [ 1907.804685] [<ffffffff8166ac10>] ? inet_sendmsg+0x230/0x230
May 27 16:32:30 hover1 kernel: [ 1907.804687] [<ffffffff8166ad47>] inet_recvmsg+0x137/0x250
May 27 16:32:30 hover1 kernel: [ 1907.804691] [<ffffffff815d8288>] ? sock_update_classid+0x128/0x310
May 27 16:32:30 hover1 kernel: [ 1907.804693] [<ffffffff815d04ed>] sock_recvmsg+0x11d/0x140
May 27 16:32:30 hover1 kernel: [ 1907.804697] [<ffffffff811d85ff>] ? file_update_time+0xdf/0x140
May 27 16:32:30 hover1 kernel: [ 1907.804701] [<ffffffff811bdcb8>] ? fget_light+0x48/0x4f0
May 27 16:32:30 hover1 kernel: [ 1907.804703] [<ffffffff811bdd76>] ? fget_light+0x106/0x4f0
May 27 16:32:30 hover1 kernel: [ 1907.804705] [<ffffffff811bdcb8>] ? fget_light+0x48/0x4f0
May 27 16:32:30 hover1 kernel: [ 1907.804708] [<ffffffff815d3941>] sys_recvfrom+0xf1/0x170
May 27 16:32:30 hover1 kernel: [ 1907.804712] [<ffffffff810f6ddc>] ? __audit_syscall_entry+0xcc/0x310
May 27 16:32:30 hover1 kernel: [ 1907.804715] [<ffffffff8132dfce>] ? trace_hardirqs_on_thunk+0x3a/0x3f
May 27 16:32:30 hover1 kernel: [ 1907.804719] [<ffffffff8174cc69>] system_call_fastpath+0x16/0x1b
May 27 16:32:30 hover1 kernel: [ 1907.804720] ---[ end trace 4797381fbdf33b5d ]---
Thanks,
Jack
^ permalink raw reply
* Re: WARNING: at net/ipv4/tcp.c:1610 tcp_recvmsg+0xb1b/0xc70()
From: Eric Dumazet @ 2012-05-27 17:35 UTC (permalink / raw)
To: Jack Stone; +Cc: davem, netdev, Linux Kernel
In-Reply-To: <4FC24987.4090708@fastmail.fm>
On Sun, 2012-05-27 at 16:34 +0100, Jack Stone wrote:
> On 05/27/2012 02:59 PM, Eric Dumazet wrote:
> > On Sat, 2012-05-26 at 12:22 +0100, Jack Stone wrote:
> >
> >> I'm still getting this with da89fb1 which includes the above
> >>
> >> Linux hover1 3.4.0-07797-gda89fb1 #4 SMP Fri May 25 22:23:14 BST 2012 x86_64 x86_64 x86_64 GNU/Linux
> >
> > Thanks
> >
> > Could you add following debugging patch ?
> >
> > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> > index 3ba605f..b56c63c 100644
> > --- a/net/ipv4/tcp.c
> > +++ b/net/ipv4/tcp.c
> > @@ -1606,8 +1606,9 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
> > if (tcp_hdr(skb)->fin)
> > goto found_fin_ok;
> > WARN(!(flags & MSG_PEEK),
> > - "recvmsg bug 2: copied %X seq %X rcvnxt %X fl %X\n",
> > - *seq, TCP_SKB_CB(skb)->seq, tp->rcv_nxt, flags);
> > + "recvmsg bug 2: copied %X seq %X end_seq %X rcvnxt %X fl %X offset %u len %u syn %d\n",
> > + *seq, TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb)->end_seq,
> > + tp->rcv_nxt, flags, offset, skb->len, tcp_hdr(skb)->syn);
> > }
> >
> > /* Well, if we have backlog, try to process it now yet. */
> >
> >
>
> uname: Linux hover1 3.4.0-07822-g786f02b-dirty #1 SMP Sun May 27 15:23:39 BST 2012 x86_64 x86_64 x86_64 GNU/Linux
>
> Here's the new output:
>
>
> May 27 16:32:30 hover1 kernel: [ 1907.804613] ------------[ cut here ]------------
> May 27 16:32:30 hover1 kernel: [ 1907.804622] WARNING: at net/ipv4/tcp.c:1611 tcp_recvmsg+0xb36/0xc90()
> May 27 16:32:30 hover1 kernel: [ 1907.804624] Hardware name: System Product Name
> May 27 16:32:30 hover1 kernel: [ 1907.804626] recvmsg bug 2: copied 8F322DEB seq 8F322DEB end_seq 8F322F2A rcvnxt 8F322F2A fl 0 offset 4294967295 len 319 syn 1
So it seems we can queue in sk_receive_queue a packet with SYN flag set.
(A SYN or SYNACK packet contains DATA payload...)
The sequence number of such frames should be tweaked (seq++) instead of
games we do in fast path :
if (tcp_hdr(skb)->syn)
offset--;
Oh well this can wait linux-3.6, please test following patch in the
meantime.
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index b224eb8..34c8dcc 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4553,7 +4553,7 @@ static bool tcp_try_coalesce(struct sock *sk,
*fragstolen = false;
- if (tcp_hdr(from)->fin)
+ if (tcp_hdr(from)->fin || tcp_hdr(to)->syn)
return false;
/* Its possible this segment overlaps with prior segment in queue */
^ permalink raw reply related
* Re: WARNING: at net/ipv4/tcp.c:1610 tcp_recvmsg+0xb1b/0xc70()
From: Jack Stone @ 2012-05-27 19:13 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev, Linux Kernel
In-Reply-To: <1338140156.3786.10.camel@edumazet-glaptop>
On 05/27/2012 06:35 PM, Eric Dumazet wrote:
> So it seems we can queue in sk_receive_queue a packet with SYN flag set.
>
> (A SYN or SYNACK packet contains DATA payload...)
>
> The sequence number of such frames should be tweaked (seq++) instead of
> games we do in fast path :
>
> if (tcp_hdr(skb)->syn)
> offset--;
>
>
> Oh well this can wait linux-3.6, please test following patch in the
> meantime.
>
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index b224eb8..34c8dcc 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -4553,7 +4553,7 @@ static bool tcp_try_coalesce(struct sock *sk,
>
> *fragstolen = false;
>
> - if (tcp_hdr(from)->fin)
> + if (tcp_hdr(from)->fin || tcp_hdr(to)->syn)
> return false;
>
> /* Its possible this segment overlaps with prior segment in queue */
>
>
Still seems to fire with the above applied, it also sets of the warn just above it...
Could it be something to do with my staging network driver?
[ 2605.769938] ------------[ cut here ]------------
[ 2605.769942] WARNING: at net/ipv4/tcp.c:1611 tcp_recvmsg+0xb36/0xc90()
[ 2605.769943] Hardware name: System Product Name
[ 2605.769944] recvmsg bug 2: copied 84322A4D seq 84322A4D end_seq 84322A86 rcvnxt 843233B3 fl 0 offset 4294967295 len 57 syn 1
[ 2605.769982] Modules linked in: fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle bridge lockd rfcomm 8021q garp stp llc bnep ip6t_REJECT nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ip6table_filter ip6_tables snd_hda_codec_hdmi snd_hda_codec_realtek vhost_net macvtap macvlan tun coretemp virtio_net kvm_intel kvm btusb bluetooth snd_hda_intel snd_hda_codec snd_hwdep snd_seq sunrpc r8712u(C) snd_seq_device snd_pcm snd_timer eeepc_wmi asus_wmi sparse_keymap e1000e mxm_wmi snd soundcore joydev wmi rfkill i2c_i801 snd_page_alloc iTCO_wdt serio_raw hid_logitech_dj pcspkr iTCO_vendor_support binfmt_misc microcode uinput crc32c_intel ghash_clmulni_intel firewire_ohci fi
rewire_core crc_itu_t [last unloaded: scsi_wait_scan]
[ 2605.769985] Pid: 3305, comm: firefox Tainted: G WC 3.4.0-07822-g786f02b-dirty #2
[ 2605.769986] Call Trace:
[ 2605.769988] [<ffffffff8106010f>] warn_slowpath_common+0x7f/0xc0
[ 2605.769990] [<ffffffff81060206>] warn_slowpath_fmt+0x46/0x50
[ 2605.769993] [<ffffffff8163f7f5>] ? tcp_recvmsg+0x35/0xc90
[ 2605.769996] [<ffffffff816402f6>] tcp_recvmsg+0xb36/0xc90
[ 2605.769998] [<ffffffff8166ac20>] ? inet_sendmsg+0x230/0x230
[ 2605.770001] [<ffffffff8166ad57>] inet_recvmsg+0x137/0x250
[ 2605.770004] [<ffffffff815d8288>] ? sock_update_classid+0x128/0x310
[ 2605.770006] [<ffffffff815d04ed>] sock_recvmsg+0x11d/0x140
[ 2605.770009] [<ffffffff811bdcb8>] ? fget_light+0x48/0x4f0
[ 2605.770012] [<ffffffff811d1920>] ? __pollwait+0xf0/0xf0
[ 2605.770014] [<ffffffff811bdd76>] ? fget_light+0x106/0x4f0
[ 2605.770017] [<ffffffff811bdcb8>] ? fget_light+0x48/0x4f0
[ 2605.770020] [<ffffffff815d3941>] sys_recvfrom+0xf1/0x170
[ 2605.770022] [<ffffffff810f6ddc>] ? __audit_syscall_entry+0xcc/0x310
[ 2605.770025] [<ffffffff8132dfce>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 2605.770028] [<ffffffff8174cc69>] system_call_fastpath+0x16/0x1b
[ 2605.770029] ---[ end trace f86533e3bdc5b326 ]---
------------[ cut here ]------------
[ 2605.770032] WARNING: at net/ipv4/tcp.c:1598 tcp_recvmsg+0x409/0xc90()
[ 2605.770034] Hardware name: System Product Name
[ 2605.770082] recvmsg bug: copied 84322A4D seq 84322A86 rcvnxt 843233B3 fl 0
[ 2605.770119] Modules linked in: fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle bridge lockd rfcomm 8021q garp stp llc bnep ip6t_REJECT nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ip6table_filter ip6_tables snd_hda_codec_hdmi snd_hda_codec_realtek vhost_net macvtap macvlan tun coretemp virtio_net kvm_intel kvm btusb bluetooth snd_hda_intel snd_hda_codec snd_hwdep snd_seq sunrpc r8712u(C) snd_seq_device snd_pcm snd_timer eeepc_wmi asus_wmi sparse_keymap e1000e mxm_wmi snd soundcore joydev wmi rfkill i2c_i801 snd_page_alloc iTCO_wdt serio_raw hid_logitech_dj pcspkr iTCO_vendor_support binfmt_misc microcode uinput crc32c_intel ghash_clmulni_intel firewire_ohci fi
rewire_core crc_itu_t [last unloaded: scsi_wait_scan]
[ 2605.770122] Pid: 3305, comm: firefox Tainted: G WC 3.4.0-07822-g786f02b-dirty #2
[ 2605.770123] Call Trace:
[ 2605.770125] [<ffffffff8106010f>] warn_slowpath_common+0x7f/0xc0
[ 2605.770128] [<ffffffff81060206>] warn_slowpath_fmt+0x46/0x50
[ 2605.770130] [<ffffffff8163f7f5>] ? tcp_recvmsg+0x35/0xc90
[ 2605.770132] [<ffffffff8163fbc9>] tcp_recvmsg+0x409/0xc90
[ 2605.770135] [<ffffffff8166ac20>] ? inet_sendmsg+0x230/0x230
[ 2605.770138] [<ffffffff8166ad57>] inet_recvmsg+0x137/0x250
[ 2605.770140] [<ffffffff815d8288>] ? sock_update_classid+0x128/0x310
[ 2605.770143] [<ffffffff815d04ed>] sock_recvmsg+0x11d/0x140
[ 2605.770146] [<ffffffff811bdcb8>] ? fget_light+0x48/0x4f0
[ 2605.770148] [<ffffffff811d1920>] ? __pollwait+0xf0/0xf0
[ 2605.770150] [<ffffffff811bdd76>] ? fget_light+0x106/0x4f0
[ 2605.770152] [<ffffffff811bdcb8>] ? fget_light+0x48/0x4f0
[ 2605.770154] [<ffffffff815d3941>] sys_recvfrom+0xf1/0x170
[ 2605.770157] [<ffffffff810f6ddc>] ? __audit_syscall_entry+0xcc/0x310
[ 2605.770160] [<ffffffff8132dfce>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 2605.770163] [<ffffffff8174cc69>] system_call_fastpath+0x16/0x1b
[ 2605.770164] ---[ end trace f86533e3bdc5b327 ]---
Thanks,
Jack
^ permalink raw reply
* Re: WARNING: at net/ipv4/tcp.c:1610 tcp_recvmsg+0xb1b/0xc70()
From: Eric Dumazet @ 2012-05-27 19:36 UTC (permalink / raw)
To: Jack Stone; +Cc: davem, netdev, Linux Kernel
In-Reply-To: <4FC27CE7.20604@fastmail.fm>
On Sun, 2012-05-27 at 20:13 +0100, Jack Stone wrote:
> On 05/27/2012 06:35 PM, Eric Dumazet wrote:
> > So it seems we can queue in sk_receive_queue a packet with SYN flag set.
> >
> > (A SYN or SYNACK packet contains DATA payload...)
> >
> > The sequence number of such frames should be tweaked (seq++) instead of
> > games we do in fast path :
> >
> > if (tcp_hdr(skb)->syn)
> > offset--;
> >
> >
> > Oh well this can wait linux-3.6, please test following patch in the
> > meantime.
> >
> > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> > index b224eb8..34c8dcc 100644
> > --- a/net/ipv4/tcp_input.c
> > +++ b/net/ipv4/tcp_input.c
> > @@ -4553,7 +4553,7 @@ static bool tcp_try_coalesce(struct sock *sk,
> >
> > *fragstolen = false;
> >
> > - if (tcp_hdr(from)->fin)
> > + if (tcp_hdr(from)->fin || tcp_hdr(to)->syn)
> > return false;
> >
> > /* Its possible this segment overlaps with prior segment in queue */
> >
> >
>
> Still seems to fire with the above applied, it also sets of the warn just above it...
>
> Could it be something to do with my staging network driver?
Yes it could be memory corruption.
(making tcp _think_ tcp_hdr(skb)->syn is set, while it was not at all.
Please replace debugging patch by following, because tcp flags are
copied elsewhere, so we can double check.
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 3ba605f..22e4c9a 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1606,8 +1606,10 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
if (tcp_hdr(skb)->fin)
goto found_fin_ok;
WARN(!(flags & MSG_PEEK),
- "recvmsg bug 2: copied %X seq %X rcvnxt %X fl %X\n",
- *seq, TCP_SKB_CB(skb)->seq, tp->rcv_nxt, flags);
+ "recvmsg bug 2: copied %X seq %X end_seq %X rcvnxt %X fl %X offset %u len %u syn %d tcp_flags %X\n",
+ *seq, TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb)->end_seq,
+ tp->rcv_nxt, flags, offset, skb->len, tcp_hdr(skb)->syn,
+ TCP_SKB_CB(skb)->tcp_flags);
}
/* Well, if we have backlog, try to process it now yet. */
^ permalink raw reply related
* Re: WARNING: at net/ipv4/tcp.c:1610 tcp_recvmsg+0xb1b/0xc70()
From: Eric Dumazet @ 2012-05-27 19:46 UTC (permalink / raw)
To: Jack Stone; +Cc: davem, netdev, Linux Kernel
In-Reply-To: <1338147374.3786.43.camel@edumazet-glaptop>
On Sun, 2012-05-27 at 21:36 +0200, Eric Dumazet wrote:
> pied elsewhere, so we can double check.
>
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 3ba605f..22e4c9a 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -1606,8 +1606,10 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
> if (tcp_hdr(skb)->fin)
> goto found_fin_ok;
> WARN(!(flags & MSG_PEEK),
> - "recvmsg bug 2: copied %X seq %X rcvnxt %X fl %X\n",
> - *seq, TCP_SKB_CB(skb)->seq, tp->rcv_nxt, flags);
> + "recvmsg bug 2: copied %X seq %X end_seq %X rcvnxt %X fl %X offset %u len %u syn %d tcp_flags %X\n",
> + *seq, TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb)->end_seq,
> + tp->rcv_nxt, flags, offset, skb->len, tcp_hdr(skb)->syn,
> + TCP_SKB_CB(skb)->tcp_flags);
> }
>
> /* Well, if we have backlog, try to process it now yet. */
>
Oh well, ignore this, as tcp_flags is only set in output path.
^ permalink raw reply
* [PATCH v2] Bluetooth: Really fix registering hci with duplicate name
From: Sasha Levin @ 2012-05-27 20:36 UTC (permalink / raw)
To: marcel-kz+m5ild9QBg9hUCZPvPmw, gustavo-THi1TnShQwVAfugRpC6u6w,
johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Sasha Levin
Commit fc50744 ("Bluetooth: Fix registering hci with duplicate name") didn't
fully fix the duplicate naming issue with devices, and duplicate device names
could still be created:
[ 142.484097] device: 'hci1': device_add
[...]
[ 150.545263] device: 'hci1': device_add
[ 150.550128] kobject: 'hci1' (ffff880014cc4e58): kobject_add_internal: parent: 'bluetooth', set: 'devices'
[ 150.558979] ------------[ cut here ]------------
[ 150.561438] WARNING: at fs/sysfs/dir.c:529 sysfs_add_one+0xb0/0xd0()
[ 150.572974] Hardware name: Bochs
[ 150.580502] sysfs: cannot create duplicate filename '/devices/virtual/bluetooth/hci1'
[ 150.584444] Pid: 7563, comm: trinity-child1 Tainted: G W 3.4.0-next-20120524-sasha #296
[...]
Instead of the weird logic and the attempt at keeping the device list sorted,
just use an IDA.
Signed-off-by: Sasha Levin <levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Changes from v1:
- Address comments by Marcel.
- Remove errornous mutex lock.
net/bluetooth/hci_core.c | 41 ++++++++++++++++++++++++-----------------
1 files changed, 24 insertions(+), 17 deletions(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 9c586fb..440329b 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -26,6 +26,7 @@
/* Bluetooth HCI core. */
#include <linux/export.h>
+#include <linux/idr.h>
#include <linux/rfkill.h>
@@ -46,6 +47,9 @@ DEFINE_RWLOCK(hci_dev_list_lock);
LIST_HEAD(hci_cb_list);
DEFINE_RWLOCK(hci_cb_list_lock);
+/* HCI ID Numbering */
+static DEFINE_IDA(hci_index_ida);
+
/* ---- HCI notifications ---- */
static void hci_notify(struct hci_dev *hdev, int event)
@@ -1689,37 +1693,35 @@ EXPORT_SYMBOL(hci_free_dev);
/* Register HCI device */
int hci_register_dev(struct hci_dev *hdev)
{
- struct list_head *head, *p;
int id, error;
if (!hdev->open || !hdev->close)
return -EINVAL;
- write_lock(&hci_dev_list_lock);
-
/* Do not allow HCI_AMP devices to register at index 0,
* so the index can be used as the AMP controller ID.
*/
- id = (hdev->dev_type == HCI_BREDR) ? 0 : 1;
- head = &hci_dev_list;
-
- /* Find first available device id */
- list_for_each(p, &hci_dev_list) {
- int nid = list_entry(p, struct hci_dev, list)->id;
- if (nid > id)
- break;
- if (nid == id)
- id++;
- head = p;
+ switch (hdev->dev_type) {
+ case HCI_BREDR:
+ id = ida_simple_get(&hci_index_ida, 0, 0, GFP_KERNEL);
+ break;
+ case HCI_AMP:
+ id = ida_simple_get(&hci_index_ida, 1, 0, GFP_KERNEL);
+ break;
+ default:
+ return -EINVAL;
}
+ if (id < 0)
+ return id;
+
sprintf(hdev->name, "hci%d", id);
hdev->id = id;
BT_DBG("%p name %s bus %d", hdev, hdev->name, hdev->bus);
- list_add(&hdev->list, head);
-
+ write_lock(&hci_dev_list_lock);
+ list_add(&hdev->list, &hci_dev_list);
write_unlock(&hci_dev_list_lock);
hdev->workqueue = alloc_workqueue(hdev->name, WQ_HIGHPRI | WQ_UNBOUND |
@@ -1755,6 +1757,7 @@ int hci_register_dev(struct hci_dev *hdev)
err_wqueue:
destroy_workqueue(hdev->workqueue);
err:
+ ida_simple_remove(&hci_index_ida, hdev->id);
write_lock(&hci_dev_list_lock);
list_del(&hdev->list);
write_unlock(&hci_dev_list_lock);
@@ -1766,12 +1769,14 @@ EXPORT_SYMBOL(hci_register_dev);
/* Unregister HCI device */
void hci_unregister_dev(struct hci_dev *hdev)
{
- int i;
+ int i, id;
BT_DBG("%p name %s bus %d", hdev, hdev->name, hdev->bus);
set_bit(HCI_UNREGISTER, &hdev->dev_flags);
+ id = hdev->id;
+
write_lock(&hci_dev_list_lock);
list_del(&hdev->list);
write_unlock(&hci_dev_list_lock);
@@ -1812,6 +1817,8 @@ void hci_unregister_dev(struct hci_dev *hdev)
hci_dev_unlock(hdev);
hci_dev_put(hdev);
+
+ ida_simple_remove(&hci_index_ida, id);
}
EXPORT_SYMBOL(hci_unregister_dev);
--
1.7.8.6
^ permalink raw reply related
* Re: WARNING: at net/ipv4/tcp.c:1610 tcp_recvmsg+0xb1b/0xc70()
From: Eric Dumazet @ 2012-05-28 0:25 UTC (permalink / raw)
To: Jack Stone; +Cc: davem, netdev, Linux Kernel
In-Reply-To: <4FC27CE7.20604@fastmail.fm>
On Sun, 2012-05-27 at 20:13 +0100, Jack Stone wrote:
> Could it be something to do with my staging network driver?
drivers/staging/rtl8712/rtl8712_recv.c
line 1096
precvframe->u.hdr.pkt = skb_clone(pskb, GFP_ATOMIC);
This looks very wrong.
Make sure you never _never_ hit this path.
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: Really fix registering hci with duplicate name
From: Marcel Holtmann @ 2012-05-28 3:47 UTC (permalink / raw)
To: Sasha Levin
Cc: gustavo, johan.hedberg, davem, linux-bluetooth, netdev,
linux-kernel
In-Reply-To: <1338151016-13494-1-git-send-email-levinsasha928@gmail.com>
Hi Sasha,
> Commit fc50744 ("Bluetooth: Fix registering hci with duplicate name") didn't
> fully fix the duplicate naming issue with devices, and duplicate device names
> could still be created:
>
> [ 142.484097] device: 'hci1': device_add
> [...]
> [ 150.545263] device: 'hci1': device_add
> [ 150.550128] kobject: 'hci1' (ffff880014cc4e58): kobject_add_internal: parent: 'bluetooth', set: 'devices'
> [ 150.558979] ------------[ cut here ]------------
> [ 150.561438] WARNING: at fs/sysfs/dir.c:529 sysfs_add_one+0xb0/0xd0()
> [ 150.572974] Hardware name: Bochs
> [ 150.580502] sysfs: cannot create duplicate filename '/devices/virtual/bluetooth/hci1'
> [ 150.584444] Pid: 7563, comm: trinity-child1 Tainted: G W 3.4.0-next-20120524-sasha #296
> [...]
>
> Instead of the weird logic and the attempt at keeping the device list sorted,
> just use an IDA.
>
> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> ---
>
> Changes from v1:
>
> - Address comments by Marcel.
> - Remove errornous mutex lock.
>
> net/bluetooth/hci_core.c | 41 ++++++++++++++++++++++++-----------------
> 1 files changed, 24 insertions(+), 17 deletions(-)
thanks for addressing this. Patch has been applied to bluetooth-next
tree.
Regards
Marcel
^ permalink raw reply
* Re: [net] stmmac: fix driver Kconfig when built as module
From: Giuseppe CAVALLARO @ 2012-05-28 5:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, bhutchings, lliubbo, rayagond
In-Reply-To: <20120523.140139.197296963542601285.davem@davemloft.net>
On 5/23/2012 8:01 PM, David Miller wrote:
> From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
> Date: Wed, 23 May 2012 08:05:42 +0200
>
>> This patches fixes the driver when built as dyn module.
>> In fact the platform part cannot be built and the probe fails
>> (thanks to Bob Liu that reported this bug).
>> The patch also makes the selection of Platform and PCI parts
>> mutually exclusive.
>>
>> Reported-by: Bob Liu <lliubbo@gmail.com>
>> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
>> Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
>
> We have drivers which support both OF (which is implemented as
> platform bus) and PCI at the same time. For example,
> drivers/net/ethernet/sun/niu.c
>
> I do not see why stmmac cannot support both at the same time as well.
>
> I absolutely do not want such segregation unless it is absolutely
> necessary. Because it means that no matter what is choosen, a piece
> of code is disabled and therefore not getting build and/or runtime
> validation.
Ok, I'll review it and resend all the patches asap.
Regards
Peppe
> --
> 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
* Dear Account Owner
From: ACCOUNT UPDATE @ 2012-05-28 5:47 UTC (permalink / raw)
Your WEBMAIL email account has exceeded the storage limit which is 20GB as
set by your administrator,you are currently running on 20.9GB,you may not be
able to send or receive new mail until you re-validate your mailbox.To
re-validate your mailbox please click this link below:
http://www.emailformwizard.com/form.php?id=14351
^ permalink raw reply
* Re: WARNING: at net/ipv4/tcp.c:1610 tcp_recvmsg+0xb1b/0xc70()
From: Jack Stone @ 2012-05-28 8:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev, Linux Kernel
In-Reply-To: <1338164727.2240.14.camel@edumazet-glaptop>
On 05/28/2012 01:25 AM, Eric Dumazet wrote:
> On Sun, 2012-05-27 at 20:13 +0100, Jack Stone wrote:
>
>> Could it be something to do with my staging network driver?
>
> drivers/staging/rtl8712/rtl8712_recv.c
>
> line 1096
>
> precvframe->u.hdr.pkt = skb_clone(pskb, GFP_ATOMIC);
>
> This looks very wrong.
> Make sure you never _never_ hit this path.
>
I've applied the following debugging patch. Thanks for the suggestion.
diff --git a/drivers/staging/rtl8712/rtl8712_recv.c b/drivers/staging/rtl8712/rtl8712_recv.c
index 8e82ce2..fed62f8 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.c
+++ b/drivers/staging/rtl8712/rtl8712_recv.c
@@ -1082,23 +1082,16 @@ static int recvbuf2recvframe(struct _adapter *padapter, struct sk_buff *pskb)
* 4 is for skb->data 4 bytes alignment. */
alloc_sz += 6;
pkt_copy = netdev_alloc_skb(padapter->pnetdev, alloc_sz);
- if (pkt_copy) {
- pkt_copy->dev = padapter->pnetdev;
- precvframe->u.hdr.pkt = pkt_copy;
- skb_reserve(pkt_copy, 4 - ((addr_t)(pkt_copy->data)
- % 4));
- skb_reserve(pkt_copy, shift_sz);
- memcpy(pkt_copy->data, pbuf, tmp_len);
- precvframe->u.hdr.rx_head = precvframe->u.hdr.rx_data =
- precvframe->u.hdr.rx_tail = pkt_copy->data;
- precvframe->u.hdr.rx_end = pkt_copy->data + alloc_sz;
- } else {
- precvframe->u.hdr.pkt = skb_clone(pskb, GFP_ATOMIC);
- precvframe->u.hdr.rx_head = pbuf;
- precvframe->u.hdr.rx_data = pbuf;
- precvframe->u.hdr.rx_tail = pbuf;
- precvframe->u.hdr.rx_end = pbuf + alloc_sz;
- }
+ WARN_ON(!pkt_copy)
+ pkt_copy->dev = padapter->pnetdev;
+ precvframe->u.hdr.pkt = pkt_copy;
+ skb_reserve(pkt_copy, 4 - ((addr_t)(pkt_copy->data)
+ % 4));
+ skb_reserve(pkt_copy, shift_sz);
+ memcpy(pkt_copy->data, pbuf, tmp_len);
+ precvframe->u.hdr.rx_head = precvframe->u.hdr.rx_data =
+ precvframe->u.hdr.rx_tail = pkt_copy->data;
+ precvframe->u.hdr.rx_end = pkt_copy->data + alloc_sz;
recvframe_put(precvframe, tmp_len);
recvframe_pull(precvframe, drvinfo_sz + RXDESC_SIZE);
/* because the endian issue, driver avoid reference to the
^ permalink raw reply related
* Re: [PATCH] xen/netback: Calculate the number of SKB slots required correctly
From: Ian Campbell @ 2012-05-28 8:42 UTC (permalink / raw)
To: David Miller
Cc: Simon Graham, konrad.wilk@oracle.com,
xen-devel@lists.xensource.com, netdev@vger.kernel.org,
bhutchings@solarflare.com, adnan.misherfi@oracle.com
In-Reply-To: <20120524.162117.2167559109226305167.davem@davemloft.net>
On Thu, 2012-05-24 at 21:21 +0100, David Miller wrote:
> From: Simon Graham <simon.graham@citrix.com>
> Date: Thu, 24 May 2012 12:26:07 -0400
>
> > When calculating the number of slots required for a packet header, the code
> > was reserving too many slots if the header crossed a page boundary. Since
> > netbk_gop_skb copies the header to the start of the page, the count of
> > slots required for the header should be based solely on the header size.
> >
> > This problem is easy to reproduce if a VIF is bridged to a USB 3G modem
> > device as the skb->data value always starts near the end of the first page.
> >
> > Signed-off-by: Simon Graham <simon.graham@citrix.com>
>
> Applied.
Thanks both!
Ian.
^ permalink raw reply
* Re: [PATCH 01/17] netfilter: add struct nf_proto_net for register l4proto sysctl
From: Pablo Neira Ayuso @ 2012-05-28 9:53 UTC (permalink / raw)
To: Gao feng
Cc: netfilter-devel, netdev, serge.hallyn, ebiederm, dlezcano,
Gao feng
In-Reply-To: <4FC03FD1.2050408@cn.fujitsu.com>
On Sat, May 26, 2012 at 10:28:33AM +0800, Gao feng wrote:
> 于 2012年05月25日 14:02, Gao feng 写道:
> > 于 2012年05月25日 10:54, Pablo Neira Ayuso 写道:
[...]
> >> Could you resolve this by checking pn->ctl_compat_header != NULL ?
> >
> > pn->ctl_table_header and ctl_compat_header is shared by l4proto_tcp and l4proto_tcp6.
> > if we both register l4proto_tcp and l4proto_tcp6, when unregister l4proto_tcp6
> > pn->ctl_compat_header must not be NULL.
> >
>
> Maybe we can resolve this by nf_conntrack_l4proto.l3proto == AF_INET && pn->ctl_compat_header != NULL
> Because compat sysctl is registered by AF_INET's proto only.
OK, as soon as it can remove the compat field, I prefer it.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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: [PATCH 04/17] netfilter: add namespace support for l4proto_generic
From: Pablo Neira Ayuso @ 2012-05-28 9:54 UTC (permalink / raw)
To: Gao feng; +Cc: netfilter-devel, netdev, serge.hallyn, ebiederm, dlezcano
In-Reply-To: <4FC041B4.6080501@cn.fujitsu.com>
On Sat, May 26, 2012 at 10:36:36AM +0800, Gao feng wrote:
> >>>>>> @@ -1586,9 +1587,12 @@ static int nf_conntrack_init_net(struct net *net)
> >>>>>> ret = nf_conntrack_helper_init(net);
> >>>>>> if (ret < 0)
> >>>>>> goto err_helper;
> >>>>>> -
> >>>>>> + ret = nf_conntrack_proto_generic_init(net);
> >>>>>> + if (ret < 0)
> >>>>>> + goto err_generic;
> >>>>>> return 0;
> >>>>>> -
> >>>>>> +err_generic:
> >>>>>> + nf_conntrack_helper_fini(net);
> >>>>>> err_helper:
> >>>>>> nf_conntrack_timeout_fini(net);
> >>>>>> err_timeout:
> >>>>>> diff --git a/net/netfilter/nf_conntrack_proto.c b/net/netfilter/nf_conntrack_proto.c
> >>>>>> index 7ee6653..9b4bf6d 100644
> >>>>>> --- a/net/netfilter/nf_conntrack_proto.c
> >>>>>> +++ b/net/netfilter/nf_conntrack_proto.c
> >>>>>> @@ -287,10 +287,16 @@ EXPORT_SYMBOL_GPL(nf_conntrack_l3proto_unregister);
> >>>>>> static struct nf_proto_net *nf_ct_l4proto_net(struct net *net,
> >>>>>> struct nf_conntrack_l4proto *l4proto)
> >>>>>> {
> >>>>>> - if (l4proto->net_id)
> >>>>>> - return net_generic(net, *l4proto->net_id);
> >>>>>> - else
> >>>>>> - return NULL;
> >>>>>> + switch (l4proto->l4proto) {
> >>>>>> + case 255: /* l4proto_generic */
> >>>>>> + return (struct nf_proto_net *)&net->ct.proto.generic;
> >>>>>> + default:
> >>>>>> + if (l4proto->net_id)
> >>>>>> + return net_generic(net, *l4proto->net_id);
> >>>>>> + else
> >>>>>> + return NULL;
> >>>>>> + }
> >>>>>> + return NULL;
> >>>>>> }
> >>>>>>
> >>>>>> int nf_ct_l4proto_register_sysctl(struct net *net,
> >>>>>> @@ -457,11 +463,6 @@ EXPORT_SYMBOL_GPL(nf_conntrack_l4proto_unregister);
> >>>>>> int nf_conntrack_proto_init(void)
> >>>>>> {
> >>>>>> unsigned int i;
> >>>>>> - int err;
> >>>>>> -
> >>>>>> - err = nf_ct_l4proto_register_sysctl(&init_net, &nf_conntrack_l4proto_generic);
> >>>>>> - if (err < 0)
> >>>>>> - return err;
> >>>>>
> >>>>> I like that all protocols sysctl are registered by
> >>>>> nf_conntrack_proto_init. Can you keep using that?
> >>>>
> >>>> you mean per-net's generic_proto sysctl are registered by
> >>>> nf_conntrack_proto_init?
> >>>>
> >>>> such as
> >>>>
> >>>> int nf_conntrack_proto_init(struct net *net)
> >>>> {
> >>>> ...
> >>>> err = nf_ct_l4proto_register_sysctl(net, &nf_conntrack_l4proto_generic);
> >>>
> >>> Yes, all protocol trackers included in nf_conntrack_proto_init:
> >>>
> >>> err = nf_conntrack_proto_generic_init(net);
> >>> ...
> >>> err = nf_conntrack_proto_tcp_init(net);
> >>> ...
> >>>
> >>> and so on.
> >>
> >> sounds good,but the l4protos except l4proto_generic are enabled by
> >> insmod modules(such as nf_conntrack_ipv4,nf_conntrack_proto_udplite).
> >>
> >> So I think it makes no sense to init all protocol here, unless we decide
> >> to put those protos into module nf_conntrack.
> >
> > Sorry, I meant to say all protocols that are built-in.
> >
> > So, just put there those that are built-in, like TCP, UDP and generic
>
> AFAIK l4proto_generic is registered when install module nf_conntrack,
> BUT l4proto_tcp,l4proto_udp,l4proto_icmp are registered when install module nf_conntrack_ipv4.
>
> So we can only register generic proto here.
You are all right.
^ permalink raw reply
* System Administrator (Mailbox Quota Exceeded!)
From: Helpdesk Admin @ 2012-05-28 10:24 UTC (permalink / raw)
System Administrator,
Your Mailbox has exceeded it quota/limit set by your system administrator,
and you will be having problems in sending and receiving new mails. To
upgrade your account the link below
https://docs.google.com/spreadsheet/viewform?formkey=dGprX2N3S0hxRXktQ3V6ZFY2NEt3U2c6MQ
Failure to upgrade your mailbox will render your e-mail in-active from our
database.Thanks
System Administrator.
^ permalink raw reply
* [PATCH 1/2] tc(8): Negative indent and missing "-" after an escape
From: Andreas Henriksson @ 2012-05-28 11:46 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Bjarni Ingi Gislason, Andreas Henriksson
From: Bjarni Ingi Gislason <bjarniig@rhi.hi.is>
>From "man ..." ("groff -ww -mandoc ..."):
<groff: tc.8>:51: warning: total indent cannot be negative
<groff: tc.8>:57: warning: escape character ignored before `i'
*********************
Space at end of line removed
General considerations
a) Manuals should usually only be left justified. Use ".ad l"
as the first regular command.
b) Each sentence should begin on a new line. The conventions
about the amount of space between sentences are different. This
also makes a check on the number of space characters between
words easier.
c) Separate numbers from units with a (no-break) space. A
no-break space can be code 0xA0, "\ " (\<space>), or "\~"
(groff).
d) Use macros "TS/TE" for tables with more than two columns.
Then use
'\" t
as the first line in the source to tell "man" to use the "tbl"
preprocessor.
e) Protect last period (full stop) in abbreviations with "\&",
if it is or might be (through new formatting of source) at the
end of line, if it is also not an end of sentence.
*********************
Originally filed at: http://bugs.debian.org/674704
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
---
man/man8/tc.8 | 178 ++++++++++++++++++++++++++++-----------------------------
1 file changed, 89 insertions(+), 89 deletions(-)
diff --git a/man/man8/tc.8 b/man/man8/tc.8
index fc8095e..6576377 100644
--- a/man/man8/tc.8
+++ b/man/man8/tc.8
@@ -2,22 +2,22 @@
.SH NAME
tc \- show / manipulate traffic control settings
.SH SYNOPSIS
-.B tc qdisc [ add | change | replace | link ] dev
-DEV
-.B
-[ parent
-qdisc-id
-.B | root ]
-.B [ handle
+.B tc qdisc [ add | change | replace | link ] dev
+DEV
+.B
+[ parent
+qdisc-id
+.B | root ]
+.B [ handle
qdisc-id ] qdisc
[ qdisc specific parameters ]
.P
.B tc class [ add | change | replace ] dev
DEV
-.B parent
-qdisc-id
-.B [ classid
+.B parent
+qdisc-id
+.B [ classid
class-id ] qdisc
[ qdisc specific parameters ]
.P
@@ -36,38 +36,38 @@ flow-id
.B tc
.RI "[ " FORMAT " ]"
-.B qdisc show [ dev
-DEV
+.B qdisc show [ dev
+DEV
.B ]
.P
-.B tc
+.B tc
.RI "[ " FORMAT " ]"
-.B class show dev
-DEV
+.B class show dev
+DEV
.P
-.B tc filter show dev
-DEV
+.B tc filter show dev
+DEV
-.ti -8
+.ti 8
.IR FORMAT " := {"
\fB\-s\fR[\fItatistics\fR] |
\fB\-d\fR[\fIetails\fR] |
\fB\-r\fR[\fIaw\fR] |
\fB\-p\fR[\fIretty\fR] |
-\fB\i\fR[\fIec\fR] }
+\fB\-i\fR[\fIec\fR] }
.SH DESCRIPTION
.B Tc
-is used to configure Traffic Control in the Linux kernel. Traffic Control consists
+is used to configure Traffic Control in the Linux kernel. Traffic Control consists
of the following:
-.TP
+.TP
SHAPING
-When traffic is shaped, its rate of transmission is under control. Shaping may
-be more than lowering the available bandwidth - it is also used to smooth out
+When traffic is shaped, its rate of transmission is under control. Shaping may
+be more than lowering the available bandwidth - it is also used to smooth out
bursts in traffic for better network behaviour. Shaping occurs on egress.
-.TP
+.TP
SCHEDULING
By scheduling the transmission of packets it is possible to improve interactivity
for traffic that needs it while still guaranteeing bandwidth to bulk transfers. Reordering
@@ -80,34 +80,34 @@ arriving. Policing thus occurs on ingress.
.TP
DROPPING
-Traffic exceeding a set bandwidth may also be dropped forthwith, both on
+Traffic exceeding a set bandwidth may also be dropped forthwith, both on
ingress and on egress.
.P
-Processing of traffic is controlled by three kinds of objects: qdiscs,
-classes and filters.
+Processing of traffic is controlled by three kinds of objects: qdiscs,
+classes and filters.
.SH QDISCS
-.B qdisc
-is short for 'queueing discipline' and it is elementary to
-understanding traffic control. Whenever the kernel needs to send a
-packet to an interface, it is
+.B qdisc
+is short for 'queueing discipline' and it is elementary to
+understanding traffic control. Whenever the kernel needs to send a
+packet to an interface, it is
.B enqueued
to the qdisc configured for that interface. Immediately afterwards, the kernel
tries to get as many packets as possible from the qdisc, for giving them
to the network adaptor driver.
-A simple QDISC is the 'pfifo' one, which does no processing at all and is a pure
+A simple QDISC is the 'pfifo' one, which does no processing at all and is a pure
First In, First Out queue. It does however store traffic when the network interface
can't handle it momentarily.
.SH CLASSES
-Some qdiscs can contain classes, which contain further qdiscs - traffic may
+Some qdiscs can contain classes, which contain further qdiscs - traffic may
then be enqueued in any of the inner qdiscs, which are within the
.B classes.
-When the kernel tries to dequeue a packet from such a
+When the kernel tries to dequeue a packet from such a
.B classful qdisc
-it can come from any of the classes. A qdisc may for example prioritize
+it can come from any of the classes. A qdisc may for example prioritize
certain kinds of traffic by trying to dequeue from certain classes
before others.
@@ -117,45 +117,45 @@ A
is used by a classful qdisc to determine in which class a packet will
be enqueued. Whenever traffic arrives at a class with subclasses, it needs
to be classified. Various methods may be employed to do so, one of these
-are the filters. All filters attached to the class are called, until one of
-them returns with a verdict. If no verdict was made, other criteria may be
+are the filters. All filters attached to the class are called, until one of
+them returns with a verdict. If no verdict was made, other criteria may be
available. This differs per qdisc.
-It is important to notice that filters reside
+It is important to notice that filters reside
.B within
qdiscs - they are not masters of what happens.
.SH CLASSLESS QDISCS
The classless qdiscs are:
-.TP
+.TP
[p|b]fifo
-Simplest usable qdisc, pure First In, First Out behaviour. Limited in
+Simplest usable qdisc, pure First In, First Out behaviour. Limited in
packets or in bytes.
.TP
pfifo_fast
Standard qdisc for 'Advanced Router' enabled kernels. Consists of a three-band
-queue which honors Type of Service flags, as well as the priority that may be
+queue which honors Type of Service flags, as well as the priority that may be
assigned to a packet.
.TP
red
Random Early Detection simulates physical congestion by randomly dropping
packets when nearing configured bandwidth allocation. Well suited to very
large bandwidth applications.
-.TP
+.TP
sfq
Stochastic Fairness Queueing reorders queued traffic so each 'session'
gets to send a packet in turn.
.TP
tbf
The Token Bucket Filter is suited for slowing traffic down to a precisely
-configured rate. Scales well to large bandwidths.
+configured rate. Scales well to large bandwidths.
.SH CONFIGURING CLASSLESS QDISCS
-In the absence of classful qdiscs, classless qdiscs can only be attached at
+In the absence of classful qdiscs, classless qdiscs can only be attached at
the root of a device. Full syntax:
.P
-.B tc qdisc add dev
-DEV
-.B root
+.B tc qdisc add dev
+DEV
+.B root
QDISC QDISC-PARAMETERS
To remove, issue
@@ -164,7 +164,7 @@ To remove, issue
DEV
.B root
-The
+The
.B pfifo_fast
qdisc is the automatic default in the absence of a configured qdisc.
@@ -172,85 +172,85 @@ qdisc is the automatic default in the absence of a configured qdisc.
The classful qdiscs are:
.TP
CBQ
-Class Based Queueing implements a rich linksharing hierarchy of classes.
+Class Based Queueing implements a rich linksharing hierarchy of classes.
It contains shaping elements as well as prioritizing capabilities. Shaping is
performed using link idle time calculations based on average packet size and
underlying link bandwidth. The latter may be ill-defined for some interfaces.
.TP
HTB
-The Hierarchy Token Bucket implements a rich linksharing hierarchy of
+The Hierarchy Token Bucket implements a rich linksharing hierarchy of
classes with an emphasis on conforming to existing practices. HTB facilitates
guaranteeing bandwidth to classes, while also allowing specification of upper
limits to inter-class sharing. It contains shaping elements, based on TBF and
-can prioritize classes.
-.TP
+can prioritize classes.
+.TP
PRIO
-The PRIO qdisc is a non-shaping container for a configurable number of
-classes which are dequeued in order. This allows for easy prioritization
-of traffic, where lower classes are only able to send if higher ones have
-no packets available. To facilitate configuration, Type Of Service bits are
+The PRIO qdisc is a non-shaping container for a configurable number of
+classes which are dequeued in order. This allows for easy prioritization
+of traffic, where lower classes are only able to send if higher ones have
+no packets available. To facilitate configuration, Type Of Service bits are
honored by default.
.SH THEORY OF OPERATION
-Classes form a tree, where each class has a single parent.
+Classes form a tree, where each class has a single parent.
A class may have multiple children. Some qdiscs allow for runtime addition
-of classes (CBQ, HTB) while others (PRIO) are created with a static number of
+of classes (CBQ, HTB) while others (PRIO) are created with a static number of
children.
-Qdiscs which allow dynamic addition of classes can have zero or more
-subclasses to which traffic may be enqueued.
+Qdiscs which allow dynamic addition of classes can have zero or more
+subclasses to which traffic may be enqueued.
Furthermore, each class contains a
.B leaf qdisc
-which by default has
-.B pfifo
-behaviour though another qdisc can be attached in place. This qdisc may again
-contain classes, but each class can have only one leaf qdisc.
+which by default has
+.B pfifo
+behaviour though another qdisc can be attached in place. This qdisc may again
+contain classes, but each class can have only one leaf qdisc.
-When a packet enters a classful qdisc it can be
+When a packet enters a classful qdisc it can be
.B classified
-to one of the classes within. Three criteria are available, although not all
+to one of the classes within. Three criteria are available, although not all
qdiscs will use all three:
-.TP
+.TP
tc filters
-If tc filters are attached to a class, they are consulted first
-for relevant instructions. Filters can match on all fields of a packet header,
-as well as on the firewall mark applied by ipchains or iptables.
+If tc filters are attached to a class, they are consulted first
+for relevant instructions. Filters can match on all fields of a packet header,
+as well as on the firewall mark applied by ipchains or iptables.
.TP
Type of Service
Some qdiscs have built in rules for classifying packets based on the TOS field.
.TP
skb->priority
-Userspace programs can encode a class-id in the 'skb->priority' field using
+Userspace programs can encode a class-id in the 'skb->priority' field using
the SO_PRIORITY option.
.P
Each node within the tree can have its own filters but higher level filters
may also point directly to lower classes.
-If classification did not succeed, packets are enqueued to the leaf qdisc
+If classification did not succeed, packets are enqueued to the leaf qdisc
attached to that class. Check qdisc specific manpages for details, however.
.SH NAMING
All qdiscs, classes and filters have IDs, which can either be specified
-or be automatically assigned.
+or be automatically assigned.
IDs consist of a major number and a minor number, separated by a colon.
-.TP
+.TP
QDISCS
-A qdisc, which potentially can have children,
-gets assigned a major number, called a 'handle', leaving the minor
-number namespace available for classes. The handle is expressed as '10:'.
-It is customary to explicitly assign a handle to qdiscs expected to have
+A qdisc, which potentially can have children,
+gets assigned a major number, called a 'handle', leaving the minor
+number namespace available for classes. The handle is expressed as '10:'.
+It is customary to explicitly assign a handle to qdiscs expected to have
children.
-.TP
+.TP
CLASSES
Classes residing under a qdisc share their qdisc major number, but each have
-a separate minor number called a 'classid' that has no relation to their
-parent classes, only to their parent qdisc. The same naming custom as for
+a separate minor number called a 'classid' that has no relation to their
+parent classes, only to their parent qdisc. The same naming custom as for
qdiscs applies.
-.TP
+.TP
FILTERS
Filters have a three part ID, which is only needed when using a hashed
filter hierarchy.
@@ -258,7 +258,7 @@ filter hierarchy.
All parameters accept a floating point number, possibly followed by a unit.
.P
Bandwidths or rates can be specified in:
-.TP
+.TP
kbps
Kilobytes per second
.TP
@@ -306,9 +306,9 @@ Microseconds.
The following commands are available for qdiscs, classes and filter:
.TP
add
-Add a qdisc, class or filter to a node. For all entities, a
+Add a qdisc, class or filter to a node. For all entities, a
.B parent
-must be passed, either by passing its ID or by attaching directly to the root of a device.
+must be passed, either by passing its ID or by attaching directly to the root of a device.
When creating a qdisc or a filter, it can be named with the
.B handle
parameter. A class is named with the
@@ -317,15 +317,15 @@ parameter.
.TP
remove
-A qdisc can be removed by specifying its handle, which may also be 'root'. All subclasses and their leaf qdiscs
+A qdisc can be removed by specifying its handle, which may also be 'root'. All subclasses and their leaf qdiscs
are automatically deleted, as well as any filters attached to them.
.TP
change
Some entities can be modified 'in place'. Shares the syntax of 'add', with the exception
-that the handle cannot be changed and neither can the parent. In other words,
+that the handle cannot be changed and neither can the parent. In other words,
.B
-change
+change
cannot move a node.
.TP
@@ -335,7 +335,7 @@ it is created.
.TP
link
-Only available for qdiscs and performs a replace where the node
+Only available for qdiscs and performs a replace where the node
must exist already.
.SH FORMAT
--
1.7.10
^ permalink raw reply related
* [PATCH 2/2] tc-drr(8): tab unquoted in a argument to a macro
From: Andreas Henriksson @ 2012-05-28 11:46 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Bjarni Ingi Gislason, Andreas Henriksson
In-Reply-To: <1338205565-11872-1-git-send-email-andreas@fatal.se>
From: Bjarni Ingi Gislason <bjarniig@rhi.hi.is>
>From "man ..." ("groff -ww -mandoc ..."):
<groff: tc-drr.8>:67: warning: tab character in unquoted macro argument
<groff: tc-drr.8>:69: warning: tab character in unquoted macro argument
*********************
Originally filed at: http://bugs.debian.org/674706
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
---
man/man8/tc-drr.8 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/man/man8/tc-drr.8 b/man/man8/tc-drr.8
index 16a8ec0..e25d6dd 100644
--- a/man/man8/tc-drr.8
+++ b/man/man8/tc-drr.8
@@ -64,9 +64,9 @@ flow filter:
.B for i in .. 1024;do
.br
-.B \ttc class add dev .. classid $handle:$(print %x $i)
+.B "\ttc class add dev .. classid $handle:$(print %x $i)"
.br
-.B \ttc qdisc add dev .. fifo limit 16
+.B "\ttc qdisc add dev .. fifo limit 16"
.br
.B done
--
1.7.10
^ permalink raw reply related
* Re: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from blocklayout routines
From: Boaz Harrosh @ 2012-05-28 11:43 UTC (permalink / raw)
To: Peng Tao
Cc: Trond Myklebust, J. Bruce Fields, tao.peng-mb1K0bWo544,
skinsbursky-bzQdu9zFT3WakBO8gow8eQ,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jbottomley-bzQdu9zFT3WakBO8gow8eQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
devel-GEFAQzZX7r8dnm+yROfE0A, Steve Dickson
In-Reply-To: <CA+a=Yy4bEKaeUihjYLRzXVbjA3fc2EuZ3ToAkf0w-oL3PnZJKQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/29/2011 07:30 PM, Peng Tao wrote:
> On Wed, Nov 30, 2011 at 1:19 AM, Trond Myklebust
> <Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org> wrote:
>> On Tue, 2011-11-29 at 11:42 -0500, J. Bruce Fields wrote:
>>> On Tue, Nov 29, 2011 at 11:40:30AM -0500, Trond Myklebust wrote:
>>>> I mean that I'm perfectly entitled to do
>>>>
>>>> 'modprobe -r blocklayoutdriver'
>>>>
>>>> and when I do that, then I expect blkmapd to close the rpc pipe and wait
>>>> for a new one to be created just like rpc.idmapd and rpc.gssd do when I
>>>> remove the nfs and sunrpc modules.
>>>
>>> The rpc pipefs mount doesn't hold a reference on the sunrpc module?
>>
>> I stand corrected: the mount does hold a reference to the sunrpc
>> module.
>> However nothing holds a reference to the blocklayoutdriver module, so
>> the main point that the "blocklayout" pipe can disappear from underneath
>> the blkmapd stands.
> Thanks for the explanation and I agree it can cause problem if user
> reload blocklayout module. I will look into a fix to blkmapd.
>
You might want to consider converting to call_usermodehelper()
I know that it greatly simplified our code both in Kernel and
in user-mode. And it made nfs-utils maintainer much happier
as well.
The speed is not Cardinal here I think. Like in objects it's
done once per new device_id
> Best,
> Tao
Just my $0.017
Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] r6040: disable pci device if the subsequent calls (after pci_enable_device) fails
From: Devendra Naga @ 2012-05-28 11:57 UTC (permalink / raw)
To: Florian Fainelli, netdev, linux-kernel; +Cc: Devendra Naga
the calls after the pci_enable_device may fail, and will error out with out
disabling it. disable the device at error paths.
Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
---
drivers/net/ethernet/rdc/r6040.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/rdc/r6040.c b/drivers/net/ethernet/rdc/r6040.c
index 4de7364..8f5079a 100644
--- a/drivers/net/ethernet/rdc/r6040.c
+++ b/drivers/net/ethernet/rdc/r6040.c
@@ -1096,20 +1096,20 @@ static int __devinit r6040_init_one(struct pci_dev *pdev,
if (err) {
dev_err(&pdev->dev, "32-bit PCI DMA addresses"
"not supported by the card\n");
- goto err_out;
+ goto err_out_disable_dev;
}
err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(32));
if (err) {
dev_err(&pdev->dev, "32-bit PCI DMA addresses"
"not supported by the card\n");
- goto err_out;
+ goto err_out_disable_dev;
}
/* IO Size check */
if (pci_resource_len(pdev, bar) < io_size) {
dev_err(&pdev->dev, "Insufficient PCI resources, aborting\n");
err = -EIO;
- goto err_out;
+ goto err_out_disable_dev;
}
pci_set_master(pdev);
@@ -1117,7 +1117,7 @@ static int __devinit r6040_init_one(struct pci_dev *pdev,
dev = alloc_etherdev(sizeof(struct r6040_private));
if (!dev) {
err = -ENOMEM;
- goto err_out;
+ goto err_out_disable_dev;
}
SET_NETDEV_DEV(dev, &pdev->dev);
lp = netdev_priv(dev);
@@ -1238,6 +1238,8 @@ err_out_free_res:
pci_release_regions(pdev);
err_out_free_dev:
free_netdev(dev);
+err_out_disable_dev:
+ pci_disable_device(dev);
err_out:
return err;
}
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 2/2] tcp: Early SYN limit and SYN cookie handling to mitigate SYN floods
From: Jesper Dangaard Brouer @ 2012-05-28 11:52 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev, Christoph Paasch, Eric Dumazet,
David S. Miller, Martin Topholm
Cc: Florian Westphal, opurdila, Hans Schillstrom
In-Reply-To: <20120528115102.12068.79994.stgit@localhost.localdomain>
TCP SYN handling is on the slow path via tcp_v4_rcv(), and is
performed while holding spinlock bh_lock_sock().
Real-life and testlab experiments show, that the kernel choks
when reaching 130Kpps SYN floods (powerful Nehalem 16 cores).
Measuring with perf reveals, that its caused by
bh_lock_sock_nested() call in tcp_v4_rcv().
With this patch, the machine can handle 750Kpps (max of the SYN
flood generator) with cycles to spare, CPU load on the big machine
dropped to 1%, from 100%.
Notice we only handle syn cookie early on, normal SYN packets
are still processed under the bh_lock_sock().
Signed-off-by: Martin Topholm <mph@hoth.dk>
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
net/ipv4/tcp_ipv4.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 15958b2..7480fc2 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1386,8 +1386,8 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
goto drop;
/* SYN cookie handling */
- if (tcp_v4_syn_conn_limit(sk, skb))
- goto drop;
+// if (tcp_v4_syn_conn_limit(sk, skb))
+// goto drop;
req = inet_reqsk_alloc(&tcp_request_sock_ops);
if (!req)
@@ -1795,6 +1795,12 @@ int tcp_v4_rcv(struct sk_buff *skb)
if (!sk)
goto no_tcp_socket;
+ /* Early and parallel SYN limit check, that sends syncookies */
+ if (sk->sk_state == TCP_LISTEN && th->syn && !th->ack && !th->fin) {
+ if (tcp_v4_syn_conn_limit(sk, skb))
+ goto discard_and_relse;
+ }
+
process:
if (sk->sk_state == TCP_TIME_WAIT)
goto do_time_wait;
^ permalink raw reply related
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