* 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: 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
* 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: [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
* 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: 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
* [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-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
* 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: 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 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 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
* [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: 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
* 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: [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 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 v4] xfrm: take net hdr len into account for esp payload size calculation
From: David Miller @ 2012-05-27 5:09 UTC (permalink / raw)
To: bpoirier
Cc: netdev, kuznet, jmorris, yoshfuji, kaber, linux-kernel,
steffen.klassert, diego.beltrami
In-Reply-To: <1337895158-23521-1-git-send-email-bpoirier@suse.de>
From: Benjamin Poirier <bpoirier@suse.de>
Date: Thu, 24 May 2012 17:32:38 -0400
> Corrects the function that determines the esp payload size. The calculations
> done in esp{4,6}_get_mtu() lead to overlength frames in transport mode for
> certain mtu values and suboptimal frames for others.
>
> According to what is done, mainly in esp{,6}_output() and tcp_mtu_to_mss(),
> net_header_len must be taken into account before doing the alignment
> calculation.
>
> Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v7 2/2] decrement static keys on real destroy time
From: David Miller @ 2012-05-27 5:10 UTC (permalink / raw)
To: glommer
Cc: akpm, linux-mm, cgroups, devel, kamezawa.hiroyu, netdev, tj,
lizefan, hannes, mhocko
In-Reply-To: <1337938328-11537-3-git-send-email-glommer@parallels.com>
From: Glauber Costa <glommer@parallels.com>
Date: Fri, 25 May 2012 13:32:08 +0400
...
> Signed-off-by: Glauber Costa <glommer@parallels.com>
Acked-by: David S. Miller <davem@davemloft.net>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] net: compute a more reasonable default ip6_rt_max_size
From: Arun Sharma @ 2012-05-27 3:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <1338003580.10135.6.camel@edumazet-glaptop>
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.
We were testing a pre-3.0 kernel that didn't have Dave's DST_NOCOUNT
patch. Will retest with that patch applied.
> 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.
-Arun
^ permalink raw reply
* Re: [PATCH 1/2] nfct-extensions/timeout: adjust for changed nfct_timeout_snprintf API
From: spiro @ 2012-05-27 2:35 UTC (permalink / raw)
To: Pablo Neira Ayuso, netfilter-announce-bounces, Jan Engelhardt
Cc: netdev, netfilter, netfilter-devel, netfilter-announce
In-Reply-To: <20120526202105.GB452@1984>
remove me from this list and your lists
Sent via BlackBerry from T-Mobile
-----Original Message-----
From: Pablo Neira Ayuso <pablo@netfilter.org>
Sender: netfilter-announce-bounces@lists.netfilter.org
Date: Sat, 26 May 2012 22:21:05
To: Jan Engelhardt<jengelh@inai.de>
Cc: <netdev@vger.kernel.org>; <netfilter@vger.kernel.org>; <netfilter-devel@vger.kernel.org>; <netfilter-announce@lists.netfilter.org>
Subject: Re: [PATCH 1/2] nfct-extensions/timeout: adjust for changed
nfct_timeout_snprintf API
On Sat, May 26, 2012 at 09:02:34PM +0200, Jan Engelhardt wrote:
> Despite requiring libnetfilter_cttimeout >= 1.0.0, it did not
> use the new API.
>
> nfct-extensions/timeout.c: In function 'nfct_timeout_cb':
> nfct-extensions/timeout.c:99:2: error: too few arguments to function
> 'nfct_timeout_snprintf'
> In file included from nfct-extensions/timeout.c:26:0:
> /usr/include/libnetfilter_cttimeout-1.0.0/libnetfilter_cttimeout/
> libnetfilter_cttimeout.h:114:5: note: declared here
>
> 114: int nfct_timeout_snprintf(char *buf, size_t size,
> const struct nfct_timeout *, unsigned int type, unsigned int flags);
We noticed at the same time.
It's fixed now, and conntrack-tools 1.2.1 is out. Thanks!
^ permalink raw reply
* I NEED YOUR ASSISTANCE
From: mrleungcheungkong12 @ 2012-05-26 18:18 UTC (permalink / raw)
Hello,
I need your assistance to transfer $22,500,000.00 Dollars from Hong Kong
to your country
^ permalink raw reply
* Re: [PATCH 1/2] nfct-extensions/timeout: adjust for changed nfct_timeout_snprintf API
From: Pablo Neira Ayuso @ 2012-05-26 20:21 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter, netfilter-devel, netfilter-announce, netdev
In-Reply-To: <1338058955-5789-2-git-send-email-jengelh@inai.de>
On Sat, May 26, 2012 at 09:02:34PM +0200, Jan Engelhardt wrote:
> Despite requiring libnetfilter_cttimeout >= 1.0.0, it did not
> use the new API.
>
> nfct-extensions/timeout.c: In function 'nfct_timeout_cb':
> nfct-extensions/timeout.c:99:2: error: too few arguments to function
> 'nfct_timeout_snprintf'
> In file included from nfct-extensions/timeout.c:26:0:
> /usr/include/libnetfilter_cttimeout-1.0.0/libnetfilter_cttimeout/
> libnetfilter_cttimeout.h:114:5: note: declared here
>
> 114: int nfct_timeout_snprintf(char *buf, size_t size,
> const struct nfct_timeout *, unsigned int type, unsigned int flags);
We noticed at the same time.
It's fixed now, and conntrack-tools 1.2.1 is out. Thanks!
^ permalink raw reply
* Re: [PATCH 2/2] Update .gitignore
From: Pablo Neira Ayuso @ 2012-05-26 20:19 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter, netfilter-devel, netfilter-announce, netdev
In-Reply-To: <1338058955-5789-3-git-send-email-jengelh@inai.de>
Applied, thanks Jan.
On Sat, May 26, 2012 at 09:02:35PM +0200, Jan Engelhardt wrote:
> ---
> .gitignore | 1 +
> src/.gitignore | 1 +
> 2 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/.gitignore b/.gitignore
> index 928e44b..f7a5fc7 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -1,5 +1,6 @@
> .deps/
> .libs/
> +.dirstamp
> Makefile
> Makefile.in
> *.o
> diff --git a/src/.gitignore b/src/.gitignore
> index 6e6763d..55a0d27 100644
> --- a/src/.gitignore
> +++ b/src/.gitignore
> @@ -1,5 +1,6 @@
> /conntrack
> /conntrackd
> +/nfct
>
> /read_config_lex.c
> /read_config_yy.c
> --
> 1.7.7
>
^ permalink raw reply
* Re: [PATCH] STA2X11 CAN: CAN driver for the STA2X11 board
From: Wolfgang Grandegger @ 2012-05-26 19:57 UTC (permalink / raw)
To: Federico Vaga
Cc: Marc Kleine-Budde, linux-can, netdev, linux-kernel,
Giancarlo Asnaghi, Alan Cox
In-Reply-To: <CAH5GJ0rFB4xaR7o-wVR3ze_UogeDW84dehh0rx5z+300ghB4uA@mail.gmail.com>
On 05/26/2012 10:36 AM, Federico Vaga wrote:
>> Thanks for your contribution. At a first glance, this driver looks
>> similar to the pch_can and the c_can driver. It seems that a C_CAN based
>> controller is used on that board as well. If that's true, it should be
>> handled by the C_CAN driver. To get ride of the obsolete pch_can driver,
>> I sent some time ago the patch "[RFC/PATCH] c_can: add driver for the
>> PCH CAN controller":
>>
>> http://marc.info/?t=132991563600003&r=1&w=4
>>
>> I could serve as base of a generic c_can_pci driver.
>
> You are right, this is a C-CAN but it isn't specified on the board manual.
> I compared the board manual with the Bosch C-CAN manual, and it is the same.
Like with the Intel EG20T PCH CAN controller.
> I'm working on a PCI module for this board, when it is ready we can think for
> a generic c_can_pci
That would be nice, thanks. You might have realized that AnilKumar has
provided support for the D_CAN controllers to the C_CAN driver which
will show up mainline soon.
Wolfgang.
^ 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