* Re: [PATCH net-next] tcp: avoid tx starvation by SYNACK packets
From: Vijay Subramanian @ 2012-06-23 7:34 UTC (permalink / raw)
To: Eric Dumazet
Cc: Dave Taht, Hans Schillstrom, netdev, Neal Cardwell, Tom Herbert,
Jesper Dangaard Brouer
In-Reply-To: <1338615992.2760.1665.camel@edumazet-glaptop>
On 1 June 2012 22:46, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Fri, 2012-06-01 at 18:28 -0700, Dave Taht wrote:
>> On Thu, May 31, 2012 at 2:56 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > From: Eric Dumazet <edumazet@google.com>
>> >
>> > pfifo_fast being the default Qdisc, its pretty easy to fill it with
>> > SYNACK (small) packets while host is under SYNFLOOD attack.
>> >
>> > Packets of established TCP sessions are dropped and host appears almost
>> > dead.
>> >
>> > Avoid this problem assigning TC_PRIO_FILLER priority to SYNACK
>> > generated in SYNCOOKIE mode, so that these packets are enqueued into
>> > pfifo_fast band 2.
>> >
>> > Other packets, queued to band 0 or 1 are dequeued before any SYNACK
>> > packets waiting in band 2.
>>
This patch ([PATCH net-next] tcp: avoid tx starvation by SYNACK
packets) is neither in net/net-next trees nor on patchwork. Maybe it
was missed since it was sent during the merge window. Is this not
needed anymore or is it being tested currently?
Thanks,
Vijay
^ permalink raw reply
* Linux 3.4.2 doesn't detect Intel 82579V on Supermicro X9SCL-F
From: Denys Fedoryshchenko @ 2012-06-23 8:05 UTC (permalink / raw)
To: Jeff Kirsher, Jesse Brandeburg, Bruce Allan, Carolyn Wyborny,
Don Skidmore, Greg Rose, Peter P Waskiewicz Jr, Alex Duyck,
John Ronciak, e1000-devel, netdev, linux-kernel
I have motherboard X9SCL-F with two onboard network cards, one of them
are not detected.
First i notice that on Ubuntu, now i tried also vanilla 3.4.2, on same
motherboard model, but different server.
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network
Connection (rev 05)
02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
Connection
Particular adapter that are not working:
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network
Connection (rev 05)
Subsystem: Intel Corporation Device 0000
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 20
Region 0: Memory at f7a00000 (32-bit, non-prefetchable)
[size=128K]
Region 1: Memory at f7a23000 (32-bit, non-prefetchable)
[size=4K]
Region 2: I/O ports at f020 [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 00000000fee00378 Data: 0000
Capabilities: [e0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel modules: e1000e
corresponding log entries:
[ 3.189176] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k
[ 3.197950] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
[ 3.206540] md: raid0 personality registered for level 0
[ 3.206693] e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) ->
IRQ 20
[ 3.206723] e1000e 0000:00:19.0: setting latency timer to 64
[ 3.207412] e1000e 0000:00:19.0: irq 42 for MSI/MSI-X
[ 3.224410] input: Winbond Electronics Corp Hermon USB hidmouse Device
as
/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input2
[ 3.241969] md: raid1 personality registered for level 1
[ 3.242538] generic-usb 0003:0557:2221.0001: input,hidraw0: USB HID
v1.00 Mouse [Winbond Electronics Corp Hermon USB hidmouse Device] on
usb-0000:00:1a.0-1.2/input0
[ 3.243563] input: Winbond Electronics Corp Hermon USB hidmouse Device
as
/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.1/input/input3
[ 3.243978] generic-usb 0003:0557:2221.0002: input,hidraw1: USB HID
v1.00 Keyboard [Winbond Electronics Corp Hermon USB hidmouse Device] on
usb-0000:00:1a.0-1.2/input1
[ 3.243988] usbcore: registered new interface driver usbhid
[ 3.243989] usbhid: USB HID core driver
[ 3.271808] e1000e 0000:00:19.0: PCI INT A disabled
[ 3.271813] e1000e: probe of 0000:00:19.0 failed with error -3
[ 3.271821] e1000e 0000:02:00.0: Disabling ASPM L0s
[ 3.272000] e1000e 0000:02:00.0: PCI INT A -> GSI 16 (level, low) ->
IRQ 16
[ 3.272082] e1000e 0000:02:00.0: setting latency timer to 64
[ 3.381646] e1000e 0000:02:00.0: irq 42 for MSI/MSI-X
[ 3.381652] e1000e 0000:02:00.0: irq 43 for MSI/MSI-X
[ 3.381658] e1000e 0000:02:00.0: irq 44 for MSI/MSI-X
[ 3.382503] async_tx: api initialized (async)
root@central:~# ethtool -i eth0
driver: e1000e
version: 1.5.1-k
firmware-version: 2.1-2
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
root@central:~# ethtool -i eth1
Cannot get driver information: No such device
---
AlsaDevices:
total 0
crw-rw---T 1 root audio 116, 1 Jun 17 13:22 seq
crw-rw---T 1 root audio 116, 33 Jun 17 13:22 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.0.1-0ubuntu8
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq',
'/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory
DistroRelease: Ubuntu 12.04
HibernationDevice: RESUME=UUID=6bdcd41e-069d-48e1-831d-5789badf4aab
InstallationMedia: Ubuntu-Server 12.04 LTS "Precise Pangolin" - Release
amd64 (20120424.1)
Lsusb:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching
Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching
Hub
Bus 001 Device 003: ID 0557:2221 ATEN International Co., Ltd
MachineType: Supermicro X9SCL/X9SCM
Package: linux (not installed)
PciMultimedia:
ProcEnviron:
TERM=xterm
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcFB: 0 EFI VGA
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-25-generic
root=UUID=49e8b23b-7eb0-41ac-8343-d6586659c879 ro
ProcVersionSignature: Ubuntu 3.2.0-25.40-generic 3.2.18
RelatedPackageVersions:
linux-restricted-modules-3.2.0-25-generic N/A
linux-backports-modules-3.2.0-25-generic N/A
linux-firmware 1.79
RfKill: Error: [Errno 2] No such file or directory
Tags: precise
Uname: Linux 3.2.0-25-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:
dmi.bios.date: 05/08/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 2.00
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: X9SCL/X9SCM
dmi.board.vendor: Supermicro
dmi.board.version: 0123456789
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: Supermicro
dmi.chassis.version: 0123456789
dmi.modalias:
dmi:bvnAmericanMegatrendsInc.:bvr2.00:bd05/08/2012:svnSupermicro:pnX9SCL/X9SCM:pvr0123456789:rvnSupermicro:rnX9SCL/X9SCM:rvr0123456789:cvnSupermicro:ct3:cvr0123456789:
dmi.product.name: X9SCL/X9SCM
dmi.product.version: 0123456789
dmi.sys.vendor: Supermicro
Detailed hardware information and ticket on ubuntu
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1014490
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [PATCH v2 net-next] tcp: avoid tx starvation by SYNACK packets
From: Eric Dumazet @ 2012-06-23 8:42 UTC (permalink / raw)
To: Vijay Subramanian
Cc: Dave Taht, Hans Schillstrom, netdev, Neal Cardwell, Tom Herbert,
Jesper Dangaard Brouer
In-Reply-To: <CAGK4HS8Hae_4sNQeGXGc4ocK1-2DVtCUdBAPj7+DY_iF6-2zOA@mail.gmail.com>
From: Eric Dumazet <edumazet@google.com>
On Sat, 2012-06-23 at 00:34 -0700, Vijay Subramanian wrote:
> This patch ([PATCH net-next] tcp: avoid tx starvation by SYNACK
> packets) is neither in net/net-next trees nor on patchwork. Maybe it
> was missed since it was sent during the merge window. Is this not
> needed anymore or is it being tested currently?
You're right, thanks for the reminder !
[PATCH v2 net-next] tcp: avoid tx starvation by SYNACK packets
pfifo_fast being the default Qdisc, its pretty easy to fill it with
SYNACK (small) packets while host is under synflood attack.
Packets of established TCP sessions are dropped at Qdisc layer and
host appears almost dead.
Avoid this problem assigning TC_PRIO_FILLER priority to SYNACK
generated in SYNCOOKIE mode, so that these packets are enqueued into
pfifo_fast lowest priority (band 2).
Other packets, queued to band 0 or 1 are dequeued before any SYNACK
packets waiting in band 2.
If not under synflood, SYNACK priority is as requested by listener
sk_priority policy.
Reported-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Tom Herbert <therbert@google.com>
Cc: Vijay Subramanian <subramanian.vijay@gmail.com>
---
net/dccp/ipv4.c | 2 ++
net/ipv4/ip_output.c | 2 +-
net/ipv4/tcp_ipv4.c | 7 ++++++-
net/ipv6/inet6_connection_sock.c | 1 +
net/ipv6/ip6_output.c | 2 +-
net/ipv6/tcp_ipv6.c | 11 ++++++++---
6 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 3eb76b5..045176f 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -515,6 +515,7 @@ static int dccp_v4_send_response(struct sock *sk, struct request_sock *req,
dh->dccph_checksum = dccp_v4_csum_finish(skb, ireq->loc_addr,
ireq->rmt_addr);
+ skb->priority = sk->sk_priority;
err = ip_build_and_send_pkt(skb, sk, ireq->loc_addr,
ireq->rmt_addr,
ireq->opt);
@@ -556,6 +557,7 @@ static void dccp_v4_ctl_send_reset(struct sock *sk, struct sk_buff *rxskb)
skb_dst_set(skb, dst_clone(dst));
bh_lock_sock(ctl_sk);
+ skb->priority = ctl_sk->sk_priority;
err = ip_build_and_send_pkt(skb, ctl_sk,
rxiph->daddr, rxiph->saddr, NULL);
bh_unlock_sock(ctl_sk);
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 0f3185a..71c6c20 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -155,7 +155,7 @@ int ip_build_and_send_pkt(struct sk_buff *skb, struct sock *sk,
ip_options_build(skb, &opt->opt, daddr, rt, 0);
}
- skb->priority = sk->sk_priority;
+ /* skb->priority is set by the caller */
skb->mark = sk->sk_mark;
/* Send it out. */
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index b52934f..5ef4131 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -81,7 +81,7 @@
#include <linux/stddef.h>
#include <linux/proc_fs.h>
#include <linux/seq_file.h>
-
+#include <linux/pkt_sched.h>
#include <linux/crypto.h>
#include <linux/scatterlist.h>
@@ -821,6 +821,7 @@ static void tcp_v4_reqsk_send_ack(struct sock *sk, struct sk_buff *skb,
* Send a SYN-ACK after having received a SYN.
* This still operates on a request_sock only, not on a big
* socket.
+ * nocache is set for SYN-ACK sent in SYNCOOKIE mode
*/
static int tcp_v4_send_synack(struct sock *sk, struct dst_entry *dst,
struct request_sock *req,
@@ -843,6 +844,10 @@ static int tcp_v4_send_synack(struct sock *sk, struct dst_entry *dst,
__tcp_v4_send_check(skb, ireq->loc_addr, ireq->rmt_addr);
skb_set_queue_mapping(skb, queue_mapping);
+
+ /* SYNACK sent in SYNCOOKIE mode have low priority */
+ skb->priority = nocache ? TC_PRIO_FILLER : sk->sk_priority;
+
err = ip_build_and_send_pkt(skb, sk, ireq->loc_addr,
ireq->rmt_addr,
ireq->opt);
diff --git a/net/ipv6/inet6_connection_sock.c b/net/ipv6/inet6_connection_sock.c
index e6cee52..5812a74 100644
--- a/net/ipv6/inet6_connection_sock.c
+++ b/net/ipv6/inet6_connection_sock.c
@@ -248,6 +248,7 @@ int inet6_csk_xmit(struct sk_buff *skb, struct flowi *fl_unused)
/* Restore final destination back after routing done */
fl6.daddr = np->daddr;
+ skb->priority = sk->sk_priority;
res = ip6_xmit(sk, skb, &fl6, np->opt, np->tclass);
rcu_read_unlock();
return res;
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index a233a7c..a93378a 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -228,7 +228,7 @@ int ip6_xmit(struct sock *sk, struct sk_buff *skb, struct flowi6 *fl6,
hdr->saddr = fl6->saddr;
hdr->daddr = *first_hop;
- skb->priority = sk->sk_priority;
+ /* skb->priority is set by the caller */
skb->mark = sk->sk_mark;
mtu = dst_mtu(dst);
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 26a8862..f664452 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -43,6 +43,7 @@
#include <linux/ipv6.h>
#include <linux/icmpv6.h>
#include <linux/random.h>
+#include <linux/pkt_sched.h>
#include <net/tcp.h>
#include <net/ndisc.h>
@@ -479,7 +480,8 @@ out:
static int tcp_v6_send_synack(struct sock *sk, struct request_sock *req,
struct request_values *rvp,
- u16 queue_mapping)
+ u16 queue_mapping,
+ bool syncookie)
{
struct inet6_request_sock *treq = inet6_rsk(req);
struct ipv6_pinfo *np = inet6_sk(sk);
@@ -515,6 +517,7 @@ static int tcp_v6_send_synack(struct sock *sk, struct request_sock *req,
if (skb) {
__tcp_v6_send_check(skb, &treq->loc_addr, &treq->rmt_addr);
+ skb->priority = syncookie ? TC_PRIO_FILLER : sk->sk_priority;
fl6.daddr = treq->rmt_addr;
skb_set_queue_mapping(skb, queue_mapping);
err = ip6_xmit(sk, skb, &fl6, opt, np->tclass);
@@ -531,7 +534,7 @@ static int tcp_v6_rtx_synack(struct sock *sk, struct request_sock *req,
struct request_values *rvp)
{
TCP_INC_STATS_BH(sock_net(sk), TCP_MIB_RETRANSSEGS);
- return tcp_v6_send_synack(sk, req, rvp, 0);
+ return tcp_v6_send_synack(sk, req, rvp, 0, false);
}
static void tcp_v6_reqsk_destructor(struct request_sock *req)
@@ -909,6 +912,7 @@ static void tcp_v6_send_response(struct sk_buff *skb, u32 seq, u32 ack, u32 win,
dst = ip6_dst_lookup_flow(ctl_sk, &fl6, NULL, false);
if (!IS_ERR(dst)) {
skb_dst_set(buff, dst);
+ skb->priority = ctl_sk->sk_priority;
ip6_xmit(ctl_sk, buff, &fl6, NULL, tclass);
TCP_INC_STATS_BH(net, TCP_MIB_OUTSEGS);
if (rst)
@@ -1217,7 +1221,8 @@ have_isn:
if (tcp_v6_send_synack(sk, req,
(struct request_values *)&tmp_ext,
- skb_get_queue_mapping(skb)) ||
+ skb_get_queue_mapping(skb),
+ want_cookie) ||
want_cookie)
goto drop_and_free;
^ permalink raw reply related
* Re: [PATCH net] net: qmi_wwan: fix Oops while disconnecting
From: Bjørn Mork @ 2012-06-23 8:45 UTC (permalink / raw)
To: Ming Lei
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Marius Bjørnstad Kotsbak
In-Reply-To: <CACVXFVMJSrLjOyKUnZWr3CY2HJT6Wfm6AugZOhSCRUubV0hNMQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> On Sat, Jun 23, 2012 at 11:32 AM, Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Fri, Jun 22, 2012 at 5:11 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
>>
>>>
>>> Reported-by: Marius Bjørnstad Kotsbak <marius.kotsbak-Re5JQEeQqe8@public.gmane.orgm>
>>> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v3.4
>>> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
>>> ---
>>> drivers/net/usb/qmi_wwan.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
>>> index 3767a12..b01960f 100644
>>> --- a/drivers/net/usb/qmi_wwan.c
>>> +++ b/drivers/net/usb/qmi_wwan.c
>>> @@ -197,6 +197,10 @@ err:
>>> static int qmi_wwan_cdc_wdm_manage_power(struct usb_interface *intf, int on)
>>> {
>>> struct usbnet *dev = usb_get_intfdata(intf);
>>> +
>>> + /* can be called while disconnecting */
>>> + if (!dev)
>>> + return 0;
>>> return qmi_wwan_manage_power(dev, on);
>>> }
>>
>
> Considered there isn't any protection between usbnet_disconnet and
> wdm_open/wdm_close, you patch still doesn't work on the race, see
> below:
>
> + if (!dev)
> + return 0;
>
> -> usbnet_disconnect() is triggered and completed here, so
> dev may point to a freed usbnet instance.
> return qmi_wwan_manage_power(dev, on);
usbnet_disconnect() cannot continue to the point where it frees the
netdev before wdm_open/wdm_close has completed, because it waits for
qmi_wwan_unbind which waits for wdm_disconnect. And wdm_disconnect
takes the both read and write mutexes.
So I do not think there is any race there.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: fix Gobi device probing
From: Bjørn Mork @ 2012-06-23 9:26 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
H.Siebmanns-zqRNUXuvxA0b1SvskN2V4Q
In-Reply-To: <20120622.171735.637204872051168180.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:
> From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> Date: Thu, 21 Jun 2012 14:45:58 +0200
>
>> Ignoring interfaces with additional descriptors is not a reliable
>> method for locating the correct interface on Gobi devices. There
>> is at least one device where this method fails:
>> https://bbs.archlinux.org/viewtopic.php?id=143506
>>
>> The result is that the AT command port (interface #2) is hidden
>> from qcserial, preventing traditional serial modem usage:
> ...
>> Use static interface numbers taken from the interface map in
>> qcserial for all Gobi devices instead:
> ...
>> This should be more reliable over all, and will also prevent the
>> noisy "probe failed" messages. The whitelisting logic is expected
>> to be replaced by direct interface number matching in 3.6.
>>
>> Reported-by: Heinrich Siebmanns (Harvey) <H.Siebmanns-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>
>> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v3.4: 0000188 USB: qmi_wwan: Make forced int 4 whitelist generic
>> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v3.4: f7142e6 USB: qmi_wwan: Add ZTE (Vodafone) K3520-Z
>> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v3.4
>> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
>
> Applied.
Thanks.
Note that this patch will conflict with the qmi_wwan changes already in
net-next. I can prepare a minimal forward port if you like.
But I would really prefer to rewrite it completely for 3.6 instead,
taking advantage of the USB interface number matching in usb-next. That
will allow us to get rid of the ugly whitelisting logic and just match
directly on the USB interface number instead. Would that be OK? It
will depend on
81df2d5 USB: allow match on bInterfaceNumber
fec1868 USB: properly pad out usb_device_id.driver_info
from usb-next, so those must go into net-next before this is possible.
Is waiting for 3.6-rc1 the best alternative, or is cherry-picking them
an option?
I can of course also do the basic forward port now and then fix it up
later during the 3.6 cycle if you prefer that.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: fix Gobi device probing
From: David Miller @ 2012-06-23 9:37 UTC (permalink / raw)
To: bjorn-yOkvZcmFvRU
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
H.Siebmanns-zqRNUXuvxA0b1SvskN2V4Q
In-Reply-To: <87y5neidk1.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Date: Sat, 23 Jun 2012 11:26:54 +0200
> Is waiting for 3.6-rc1 the best alternative, or is cherry-picking them
> an option?
I'm extremely reluctant to have a dependency on another tree.
The USB tree, on the other hand, could pull the net-next tree
in so you can continue your dependent work there.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: fix Gobi device probing
From: Bjørn Mork @ 2012-06-23 10:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-usb, H.Siebmanns
In-Reply-To: <20120623.023749.1066357959466872561.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Bjørn Mork <bjorn@mork.no>
> Date: Sat, 23 Jun 2012 11:26:54 +0200
>
>> Is waiting for 3.6-rc1 the best alternative, or is cherry-picking them
>> an option?
>
> I'm extremely reluctant to have a dependency on another tree.
fair enough
> The USB tree, on the other hand, could pull the net-next tree
> in so you can continue your dependent work there.
OK, that will be up to Greg then.
But failing that, would it be OK to let the 3.6 version of the fix wait
for -rc2? It's not a crash or any other kind of data loss bug, just a
usability regression with a workaround.
Bjørn
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: fix Gobi device probing
From: David Miller @ 2012-06-23 10:35 UTC (permalink / raw)
To: bjorn-yOkvZcmFvRU
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
H.Siebmanns-zqRNUXuvxA0b1SvskN2V4Q
In-Reply-To: <87txy2ibr8.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Date: Sat, 23 Jun 2012 12:05:46 +0200
> But failing that, would it be OK to let the 3.6 version of the fix wait
> for -rc2? It's not a crash or any other kind of data loss bug, just a
> usability regression with a workaround.
I'm shortly going to merge net into net-next as I periodically do,
so I'm going to have to resolve the conflict regardless of how you
finally want to fix this Gobi device probing problem.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net-next] net: qmi_wwan: fix Gobi device probing
From: Bjørn Mork @ 2012-06-23 10:42 UTC (permalink / raw)
To: netdev; +Cc: linux-usb, H.Siebmanns, Bjørn Mork
(forward port of commit b9f90eb27)
Ignoring interfaces with additional descriptors is not a reliable
method for locating the correct interface on Gobi devices. There
is at least one device where this method fails:
https://bbs.archlinux.org/viewtopic.php?id=143506
The result is that the AT command port (interface #2) is hidden
from qcserial, preventing traditional serial modem usage:
[ 15.562552] qmi_wwan 4-1.6:1.0: cdc-wdm0: USB WDM device
[ 15.562691] qmi_wwan 4-1.6:1.0: wwan0: register 'qmi_wwan' at usb-0000:00:1d.0-1.6, Qualcomm Gobi wwan/QMI device, 1e:df:3c:3a:4e:3b
[ 15.563383] qmi_wwan: probe of 4-1.6:1.1 failed with error -22
[ 15.564189] qmi_wwan 4-1.6:1.2: cdc-wdm1: USB WDM device
[ 15.564302] qmi_wwan 4-1.6:1.2: wwan1: register 'qmi_wwan' at usb-0000:00:1d.0-1.6, Qualcomm Gobi wwan/QMI device, 1e:df:3c:3a:4e:3b
[ 15.564328] qmi_wwan: probe of 4-1.6:1.3 failed with error -22
[ 15.569376] qcserial 4-1.6:1.1: Qualcomm USB modem converter detected
[ 15.569440] usb 4-1.6: Qualcomm USB modem converter now attached to ttyUSB0
[ 15.570372] qcserial 4-1.6:1.3: Qualcomm USB modem converter detected
[ 15.570430] usb 4-1.6: Qualcomm USB modem converter now attached to ttyUSB1
Use static interface numbers taken from the interface map in
qcserial for all Gobi devices instead:
Gobi 1K USB layout:
0: serial port (doesn't respond)
1: serial port (doesn't respond)
2: AT-capable modem port
3: QMI/net
Gobi 2K+ USB layout:
0: QMI/net
1: DM/DIAG (use libqcdm from ModemManager for communication)
2: AT-capable modem port
3: NMEA
This should be more reliable over all, and will also prevent the
noisy "probe failed" messages. The whitelisting logic is expected
to be replaced by direct interface number matching in 3.6.
Reported-by: Heinrich Siebmanns (Harvey) <H.Siebmanns@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
drivers/net/usb/qmi_wwan.c | 83 +++++++++++++++++++++-----------------------
1 file changed, 40 insertions(+), 43 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index f1e7791..68ca676 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -269,29 +269,6 @@ err:
return rv;
}
-/* Gobi devices uses identical class/protocol codes for all interfaces regardless
- * of function. Some of these are CDC ACM like and have the exact same endpoints
- * we are looking for. This leaves two possible strategies for identifying the
- * correct interface:
- * a) hardcoding interface number, or
- * b) use the fact that the wwan interface is the only one lacking additional
- * (CDC functional) descriptors
- *
- * Let's see if we can get away with the generic b) solution.
- */
-static int qmi_wwan_bind_gobi(struct usbnet *dev, struct usb_interface *intf)
-{
- int rv = -EINVAL;
-
- /* ignore any interface with additional descriptors */
- if (intf->cur_altsetting->extralen)
- goto err;
-
- rv = qmi_wwan_bind_shared(dev, intf);
-err:
- return rv;
-}
-
static void qmi_wwan_unbind(struct usbnet *dev, struct usb_interface *intf)
{
struct qmi_wwan_state *info = (void *)&dev->data;
@@ -375,15 +352,15 @@ static const struct driver_info qmi_wwan_shared = {
.manage_power = qmi_wwan_manage_power,
};
-static const struct driver_info qmi_wwan_gobi = {
- .description = "Qualcomm Gobi wwan/QMI device",
+static const struct driver_info qmi_wwan_force_int0 = {
+ .description = "Qualcomm WWAN/QMI device",
.flags = FLAG_WWAN,
- .bind = qmi_wwan_bind_gobi,
+ .bind = qmi_wwan_bind_shared,
.unbind = qmi_wwan_unbind,
.manage_power = qmi_wwan_manage_power,
+ .data = BIT(0), /* interface whitelist bitmap */
};
-/* ZTE suck at making USB descriptors */
static const struct driver_info qmi_wwan_force_int1 = {
.description = "Qualcomm WWAN/QMI device",
.flags = FLAG_WWAN,
@@ -393,6 +370,15 @@ static const struct driver_info qmi_wwan_force_int1 = {
.data = BIT(1), /* interface whitelist bitmap */
};
+static const struct driver_info qmi_wwan_force_int3 = {
+ .description = "Qualcomm WWAN/QMI device",
+ .flags = FLAG_WWAN,
+ .bind = qmi_wwan_bind_shared,
+ .unbind = qmi_wwan_unbind,
+ .manage_power = qmi_wwan_manage_power,
+ .data = BIT(3), /* interface whitelist bitmap */
+};
+
static const struct driver_info qmi_wwan_force_int4 = {
.description = "Qualcomm WWAN/QMI device",
.flags = FLAG_WWAN,
@@ -418,16 +404,23 @@ static const struct driver_info qmi_wwan_force_int4 = {
static const struct driver_info qmi_wwan_sierra = {
.description = "Sierra Wireless wwan/QMI device",
.flags = FLAG_WWAN,
- .bind = qmi_wwan_bind_gobi,
+ .bind = qmi_wwan_bind_shared,
.unbind = qmi_wwan_unbind,
.manage_power = qmi_wwan_manage_power,
.data = BIT(8) | BIT(19), /* interface whitelist bitmap */
};
#define HUAWEI_VENDOR_ID 0x12D1
+
+/* Gobi 1000 QMI/wwan interface number is 3 according to qcserial */
+#define QMI_GOBI1K_DEVICE(vend, prod) \
+ USB_DEVICE(vend, prod), \
+ .driver_info = (unsigned long)&qmi_wwan_force_int3
+
+/* Gobi 2000 and Gobi 3000 QMI/wwan interface number is 0 according to qcserial */
#define QMI_GOBI_DEVICE(vend, prod) \
USB_DEVICE(vend, prod), \
- .driver_info = (unsigned long)&qmi_wwan_gobi
+ .driver_info = (unsigned long)&qmi_wwan_force_int0
static const struct usb_device_id products[] = {
{ /* Huawei E392, E398 and possibly others sharing both device id and more... */
@@ -538,20 +531,24 @@ static const struct usb_device_id products[] = {
.bInterfaceProtocol = 0xff,
.driver_info = (unsigned long)&qmi_wwan_sierra,
},
- {QMI_GOBI_DEVICE(0x05c6, 0x9212)}, /* Acer Gobi Modem Device */
- {QMI_GOBI_DEVICE(0x03f0, 0x1f1d)}, /* HP un2400 Gobi Modem Device */
- {QMI_GOBI_DEVICE(0x03f0, 0x371d)}, /* HP un2430 Mobile Broadband Module */
- {QMI_GOBI_DEVICE(0x04da, 0x250d)}, /* Panasonic Gobi Modem device */
- {QMI_GOBI_DEVICE(0x413c, 0x8172)}, /* Dell Gobi Modem device */
- {QMI_GOBI_DEVICE(0x1410, 0xa001)}, /* Novatel Gobi Modem device */
- {QMI_GOBI_DEVICE(0x0b05, 0x1776)}, /* Asus Gobi Modem device */
- {QMI_GOBI_DEVICE(0x19d2, 0xfff3)}, /* ONDA Gobi Modem device */
- {QMI_GOBI_DEVICE(0x05c6, 0x9001)}, /* Generic Gobi Modem device */
- {QMI_GOBI_DEVICE(0x05c6, 0x9002)}, /* Generic Gobi Modem device */
- {QMI_GOBI_DEVICE(0x05c6, 0x9202)}, /* Generic Gobi Modem device */
- {QMI_GOBI_DEVICE(0x05c6, 0x9203)}, /* Generic Gobi Modem device */
- {QMI_GOBI_DEVICE(0x05c6, 0x9222)}, /* Generic Gobi Modem device */
- {QMI_GOBI_DEVICE(0x05c6, 0x9009)}, /* Generic Gobi Modem device */
+
+ /* Gobi 1000 devices */
+ {QMI_GOBI1K_DEVICE(0x05c6, 0x9212)}, /* Acer Gobi Modem Device */
+ {QMI_GOBI1K_DEVICE(0x03f0, 0x1f1d)}, /* HP un2400 Gobi Modem Device */
+ {QMI_GOBI1K_DEVICE(0x03f0, 0x371d)}, /* HP un2430 Mobile Broadband Module */
+ {QMI_GOBI1K_DEVICE(0x04da, 0x250d)}, /* Panasonic Gobi Modem device */
+ {QMI_GOBI1K_DEVICE(0x413c, 0x8172)}, /* Dell Gobi Modem device */
+ {QMI_GOBI1K_DEVICE(0x1410, 0xa001)}, /* Novatel Gobi Modem device */
+ {QMI_GOBI1K_DEVICE(0x0b05, 0x1776)}, /* Asus Gobi Modem device */
+ {QMI_GOBI1K_DEVICE(0x19d2, 0xfff3)}, /* ONDA Gobi Modem device */
+ {QMI_GOBI1K_DEVICE(0x05c6, 0x9001)}, /* Generic Gobi Modem device */
+ {QMI_GOBI1K_DEVICE(0x05c6, 0x9002)}, /* Generic Gobi Modem device */
+ {QMI_GOBI1K_DEVICE(0x05c6, 0x9202)}, /* Generic Gobi Modem device */
+ {QMI_GOBI1K_DEVICE(0x05c6, 0x9203)}, /* Generic Gobi Modem device */
+ {QMI_GOBI1K_DEVICE(0x05c6, 0x9222)}, /* Generic Gobi Modem device */
+ {QMI_GOBI1K_DEVICE(0x05c6, 0x9009)}, /* Generic Gobi Modem device */
+
+ /* Gobi 2000 and 3000 devices */
{QMI_GOBI_DEVICE(0x413c, 0x8186)}, /* Dell Gobi 2000 Modem device (N0218, VU936) */
{QMI_GOBI_DEVICE(0x05c6, 0x920b)}, /* Generic Gobi 2000 Modem device */
{QMI_GOBI_DEVICE(0x05c6, 0x9225)}, /* Sony Gobi 2000 Modem device (N0279, VU730) */
--
1.7.10
^ permalink raw reply related
* Re: [PATCH net] net: qmi_wwan: fix Gobi device probing
From: Bjørn Mork @ 2012-06-23 10:44 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
H.Siebmanns-zqRNUXuvxA0b1SvskN2V4Q
In-Reply-To: <20120623.033546.563917179592608418.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:
> From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> Date: Sat, 23 Jun 2012 12:05:46 +0200
>
>> But failing that, would it be OK to let the 3.6 version of the fix wait
>> for -rc2? It's not a crash or any other kind of data loss bug, just a
>> usability regression with a workaround.
>
> I'm shortly going to merge net into net-next as I periodically do,
> so I'm going to have to resolve the conflict regardless of how you
> finally want to fix this Gobi device probing problem.
OK. I just sent a forward ported version for net-next. Feel free to
use it instead of the conflicting one, or drop it if not necessary.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: pull request: wireless 2012-06-22
From: Mohammed Shafi @ 2012-06-23 10:45 UTC (permalink / raw)
To: David Miller; +Cc: c_manoha, linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <20120622.165611.2220193371527786713.davem@davemloft.net>
On Sat, Jun 23, 2012 at 5:26 AM, David Miller <davem@davemloft.net> wrote:
> From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
> Date: Sat, 23 Jun 2012 05:05:10 +0530
>
>> Sujith Manoharan wrote:
>>> John W. Linville wrote:
>>> > Mohammed Shafi Shajakhan (1):
>>> > ath9k_hw: avoid possible infinite loop in ar9003_get_pll_sqsum_dvc
>>>
>>> Um, this commit doesn't really fix anything - the timeout is also
>>> arbitrary. Can you remove this from the 3.5 queue ? Thanks.
>>
>> A review of the patch later, I think it's good. At least there's a
>> WARN_ON_ONCE() to indicate the situation in which the measurement fails.
>> It might come in handy as a debugging aid.
>
> Thanks for wasting our time.
>
> Make these determinations when changes to into John's tree, not
> later when he asks me to pull them into mine.
apologies for the confusion, i haven't got a better timeout from very
few of the folks
queried, I should have updated that. As the patch is being already
pushed in, if we get
a proper timeout, we would fix it later with a proper timeout.
--
thanks,
shafi
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: fix Oops while disconnecting
From: Ming Lei @ 2012-06-23 14:55 UTC (permalink / raw)
To: Bjørn Mork; +Cc: netdev, linux-usb, Marius Bjørnstad Kotsbak
In-Reply-To: <8762aiju27.fsf@nemi.mork.no>
On Sat, Jun 23, 2012 at 4:45 PM, Bjørn Mork <bjorn@mork.no> wrote:
> usbnet_disconnect() cannot continue to the point where it frees the
> netdev before wdm_open/wdm_close has completed, because it waits for
> qmi_wwan_unbind which waits for wdm_disconnect. And wdm_disconnect
> takes the both read and write mutexes.
Thanks for your explanation.
I see, and your patch is correct, but it might not be generic enough.
So driver_info->unbind will sync with .open/.close of the subdriver,
just like unregister_netdev will sync with .open/.close of usbnet interface.
IMO, the general solution is to keep intfdata's lifetime after ->unbind,
which can guarantee that intfdata can be accessed safely in .open/.close
of usbnet interface and the other subdrivers' device.
Suppose there will be another usbnet driver which has its own subdriver
too, the same trick of checking need to be added again if not taking the
general way of simply removing 'usb_set_intfdata(intf, NULL);' in
usbnet_disconnect.
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH 3/3 net-next] tg3: Add sysfs file to export sensor data
From: Ben Hutchings @ 2012-06-23 15:02 UTC (permalink / raw)
To: Michael Chan; +Cc: David Miller, netdev, nsujir, mcarlson
In-Reply-To: <1340413453.4344.16.camel@LTIRV-MCHAN1.corp.ad.broadcom.com>
On Fri, 2012-06-22 at 18:04 -0700, Michael Chan wrote:
> On Fri, 2012-06-22 at 17:26 -0700, David Miller wrote:
> > From: "Michael Chan" <mchan@broadcom.com>
> > Date: Wed, 20 Jun 2012 17:06:32 -0700
> >
> > > Some tg3 devices have management firmware that can export data such as
> > > temperature and other real time diagnostics data. Export this data to
> > > sysfs so that userspace can access this information.
> > >
> > > Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> > > Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
> > > Signed-off-by: Michael Chan <mchan@broadcom.com>
> >
> > I do not agree that sysfs is the appropriate place to export binary
> > data.
> >
>
> What's your suggestion? ethtool?
Temperature and voltage can be exposed through an hwmon device (which
practically means you use multiple attributes with conventional names).
Other diagnostics might possible be suitable for ethtool stats,
depending on what they are.
If the driver can't easily parse the information (e.g. it varies greatly
between the different chips and firmware versions) then a binary
attribute or private ioctl might be appropriate. But generic interfaces
really should be considered first.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH 2/2 net] batman-adv: fix race condition in TT full-table replacement
From: Antonio Quartulli @ 2012-06-23 15:30 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <1340465459-2949-1-git-send-email-ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
bug introduced with cea194d90b11aff7fc289149e4c7f305fad3535a
In the current TT code, when a TT_Response containing a full table is received
from an originator, first the node purges all the clients for that originator in
the global translation-table and then merges the newly received table.
During the purging phase each client deletion is done by means of a call_rcu()
invocation and at the end of this phase the global entry counter for that
originator is set to 0. However the invoked rcu function decreases the global
entry counter for that originator by one too and since the rcu invocation is
likely to be postponed, the node will end up in first setting the counter to 0
and then decreasing it one by one for each deleted client.
This bug leads to having a wrong global entry counter for the related node, say
X. Then when the node with the broken counter will answer to a TT_REQUEST on
behalf of node X, it will create faulty TT_RESPONSE that will generate an
unrecoverable situation on the node that asked for the full table recover.
The non-recoverability is given by the fact that the node with the broken
counter will keep answering on behalf of X because its knowledge about X's state
(ttvn + tt_crc) is correct.
To solve this problem the counter is not explicitly set to 0 anymore and the
counter decrement is performed right before the invocation of call_rcu().
Signed-off-by: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
---
net/batman-adv/translation-table.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index 660c40f..2ab83d7 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -141,13 +141,14 @@ static void tt_orig_list_entry_free_rcu(struct rcu_head *rcu)
struct tt_orig_list_entry *orig_entry;
orig_entry = container_of(rcu, struct tt_orig_list_entry, rcu);
- atomic_dec(&orig_entry->orig_node->tt_size);
orig_node_free_ref(orig_entry->orig_node);
kfree(orig_entry);
}
static void tt_orig_list_entry_free_ref(struct tt_orig_list_entry *orig_entry)
{
+ /* to avoid race conditions, immediately decrease the tt counter */
+ atomic_dec(&orig_entry->orig_node->tt_size);
call_rcu(&orig_entry->rcu, tt_orig_list_entry_free_rcu);
}
@@ -910,7 +911,6 @@ void tt_global_del_orig(struct bat_priv *bat_priv,
}
spin_unlock_bh(list_lock);
}
- atomic_set(&orig_node->tt_size, 0);
orig_node->tt_initialised = false;
}
--
1.7.9.4
^ permalink raw reply related
* [PATCH 1/2 net] batman-adv: only drop packets of known wifi clients
From: Antonio Quartulli @ 2012-06-23 15:30 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n, Marek Lindner, Antonio Quartulli
In-Reply-To: <1340465459-2949-1-git-send-email-ordex@autistici.org>
From: Marek Lindner <lindner_marek@yahoo.de>
bug introduced with 59b699cdee039d75915c354da06937102d1f9a84
If the source or destination mac address of an ethernet packet
could not be found in the translation table the packet was
dropped if AP isolation was turned on. This behavior would
make it impossible to send broadcast packets over the mesh as
the broadcast address will never enter the translation table.
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Acked-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
---
net/batman-adv/translation-table.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index a66c2dc..660c40f 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -2031,10 +2031,10 @@ bool is_ap_isolated(struct bat_priv *bat_priv, uint8_t *src, uint8_t *dst)
{
struct tt_local_entry *tt_local_entry = NULL;
struct tt_global_entry *tt_global_entry = NULL;
- bool ret = true;
+ bool ret = false;
if (!atomic_read(&bat_priv->ap_isolation))
- return false;
+ goto out;
tt_local_entry = tt_local_hash_find(bat_priv, dst);
if (!tt_local_entry)
@@ -2044,10 +2044,10 @@ bool is_ap_isolated(struct bat_priv *bat_priv, uint8_t *src, uint8_t *dst)
if (!tt_global_entry)
goto out;
- if (_is_ap_isolated(tt_local_entry, tt_global_entry))
+ if (!_is_ap_isolated(tt_local_entry, tt_global_entry))
goto out;
- ret = false;
+ ret = true;
out:
if (tt_global_entry)
--
1.7.9.4
^ permalink raw reply related
* [PATCH 0/2 net] Bug fixes for batman-adv 2012-06-23
From: Antonio Quartulli @ 2012-06-23 15:30 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n
Hello David,
here are two fixes intended for net/linux-3.5.
Patch 1 is a fix for the AP-Isolation feature. A wrong check made all the
broadcast packets coming from any client be dropped before delivery to the
interface.
Patch 2 instead fixes a "real" race condition in the TranslationTable code.
Please, tell me if there is any problem.
Thank you,
Antonio
The following changes since commit a18e08bdcf845efb7344cea146e683df746bbfb4:
net: sh_eth: fix the condition to fix the cur_tx/dirty_rx (2012-06-22 21:50:37 -0700)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git batman-adv/maint
for you to fetch changes up to 8b8e4bc0391f8abbcdb9e1c54415bcc0f4f5a2a0:
batman-adv: fix race condition in TT full-table replacement (2012-06-23 17:21:35 +0200)
----------------------------------------------------------------
Included changes:
- fix for the AP-isolation feature
- fix for a race condition in the TranslationTable code
----------------------------------------------------------------
Antonio Quartulli (1):
batman-adv: fix race condition in TT full-table replacement
Marek Lindner (1):
batman-adv: only drop packets of known wifi clients
net/batman-adv/translation-table.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
^ permalink raw reply
* Re: [PATCH 0/2 net] Bug fixes for batman-adv 2012-06-23
From: Antonio Quartulli @ 2012-06-23 15:45 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <1340465459-2949-1-git-send-email-ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2959 bytes --]
On Sat, Jun 23, 2012 at 05:30:57 +0200, Antonio Quartulli wrote:
> Hello David,
>
> here are two fixes intended for net/linux-3.5.
>
> Patch 1 is a fix for the AP-Isolation feature. A wrong check made all the
> broadcast packets coming from any client be dropped before delivery to the
> interface.
> Patch 2 instead fixes a "real" race condition in the TranslationTable code.
>
> Please, tell me if there is any problem.
> Thank you,
> Antonio
>
>
>
> The following changes since commit a18e08bdcf845efb7344cea146e683df746bbfb4:
>
> net: sh_eth: fix the condition to fix the cur_tx/dirty_rx (2012-06-22 21:50:37 -0700)
>
> are available in the git repository at:
>
> git://git.open-mesh.org/linux-merge.git batman-adv/maint
>
> for you to fetch changes up to 8b8e4bc0391f8abbcdb9e1c54415bcc0f4f5a2a0:
>
> batman-adv: fix race condition in TT full-table replacement (2012-06-23 17:21:35 +0200)
>
Hello David,
after pulling these patchset in net, you should hit a conflict while trying to
merge net into net-next. The conflict is caused by the renaming patches that you
already have in the next tree.
Here are our instructions about how to solve it. Hope they will help.
Thank you.
Conflict 1:
<<<<<<<
orig_entry = container_of(rcu, struct batadv_tt_orig_list_entry, rcu);
atomic_dec(&orig_entry->orig_node->tt_size);
batadv_orig_node_free_ref(orig_entry->orig_node);
=======
orig_entry = container_of(rcu, struct tt_orig_list_entry, rcu);
orig_node_free_ref(orig_entry->orig_node);
>>>>>>>
Resolves to:
=======
orig_entry = container_of(rcu, struct batadv_tt_orig_list_entry, rcu);
batadv_orig_node_free_ref(orig_entry->orig_node);
=======
Conflict 2:
<<<<<<<
call_rcu(&orig_entry->rcu, batadv_tt_orig_list_entry_free_rcu);
=======
/* to avoid race conditions, immediately decrease the tt counter */
atomic_dec(&orig_entry->orig_node->tt_size);
call_rcu(&orig_entry->rcu, batadv_tt_orig_list_entry_free_rcu);
>>>>>>>
Resolves to:
=======
/* to avoid race conditions, immediately decrease the tt counter */
atomic_dec(&orig_entry->orig_node->tt_size);
call_rcu(&orig_entry->rcu, batadv_tt_orig_list_entry_free_rcu);
=======
Conflict 3:
<<<<<<<
struct batadv_tt_local_entry *tt_local_entry = NULL;
struct batadv_tt_global_entry *tt_global_entry = NULL;
bool ret = true;
=======
struct tt_local_entry *tt_local_entry = NULL;
struct tt_global_entry *tt_global_entry = NULL;
bool ret = false;
>>>>>>>
Resolves to:
=======
struct batadv_tt_local_entry *tt_local_entry = NULL;
struct batadv_tt_global_entry *tt_global_entry = NULL;
bool ret = false;
=======
Conflict 4:
<<<<<<<
if (_batadv_is_ap_isolated(tt_local_entry, tt_global_entry))
=======
if (!_is_ap_isolated(tt_local_entry, tt_global_entry))
>>>>>>>
Resolves to:
=======
if (!_batadv_is_ap_isolated(tt_local_entry, tt_global_entry))
=======
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: fix Oops while disconnecting
From: Bjørn Mork @ 2012-06-23 15:32 UTC (permalink / raw)
To: Ming Lei; +Cc: netdev, linux-usb, Marius Bjørnstad Kotsbak
In-Reply-To: <CACVXFVOZUvyNDzEoWT5o7JQRKjuw1pUgkipxV7dxT1w2Dd0H+A@mail.gmail.com>
Ming Lei <tom.leiming@gmail.com> writes:
> On Sat, Jun 23, 2012 at 4:45 PM, Bjørn Mork <bjorn@mork.no> wrote:
>
>> usbnet_disconnect() cannot continue to the point where it frees the
>> netdev before wdm_open/wdm_close has completed, because it waits for
>> qmi_wwan_unbind which waits for wdm_disconnect. And wdm_disconnect
>> takes the both read and write mutexes.
>
> Thanks for your explanation.
>
> I see, and your patch is correct, but it might not be generic enough.
>
> So driver_info->unbind will sync with .open/.close of the subdriver,
> just like unregister_netdev will sync with .open/.close of usbnet interface.
>
> IMO, the general solution is to keep intfdata's lifetime after ->unbind,
> which can guarantee that intfdata can be accessed safely in .open/.close
> of usbnet interface and the other subdrivers' device.
>
> Suppose there will be another usbnet driver which has its own subdriver
> too, the same trick of checking need to be added again if not taking the
> general way of simply removing 'usb_set_intfdata(intf, NULL);' in
> usbnet_disconnect.
Yes, I guess so.
I am just worrying (maybe too much) about the unknown consequences of
removing that code in usbnet, not fully understanding why it was there
in the first place. And I do not want to take the blame and cleanup
work if anything goes wrong :-) Fixing it in qmi_wwan feels much safer.
But if you want to remove the 'usb_set_intfdata(intf, NULL)', and the
other USB gurus agree, then I'm of course not going to object to that
alternative solution to this bug.
I still think it's unlikely this will ever hit another driver though.
Bjørn
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: fix Oops while disconnecting
From: Oliver Neukum @ 2012-06-23 20:55 UTC (permalink / raw)
To: Bjørn Mork
Cc: Ming Lei, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Marius Bjørnstad Kotsbak
In-Reply-To: <87hau2hwna.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
Am Samstag, 23. Juni 2012, 17:32:09 schrieb Bjørn Mork:
> Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> > On Sat, Jun 23, 2012 at 4:45 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
> > Suppose there will be another usbnet driver which has its own subdriver
> > too, the same trick of checking need to be added again if not taking the
> > general way of simply removing 'usb_set_intfdata(intf, NULL);' in
> > usbnet_disconnect.
>
> Yes, I guess so.
>
> I am just worrying (maybe too much) about the unknown consequences of
> removing that code in usbnet, not fully understanding why it was there
> in the first place. And I do not want to take the blame and cleanup
> work if anything goes wrong :-) Fixing it in qmi_wwan feels much safer.
void usbnet_cdc_unbind(struct usbnet *dev, struct usb_interface *intf)
{
struct cdc_state *info = (void *) &dev->data;
struct usb_driver *driver = driver_of(intf);
/* disconnect master --> disconnect slave */
if (intf == info->control && info->data) {
/* ensure immediate exit from usbnet_disconnect */
usb_set_intfdata(info->data, NULL);
usb_driver_release_interface(driver, info->data);
info->data = NULL;
1. We mirror the minidrivers closely, which reduces errors
2. unbind() is called with the data anyway and after disconnect()
the intfdata is not valid anyway, because the interface may have been
reprobed.
Regarsd
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Bug in net/ipv6/ip6_fib.c:fib6_dump_table()
From: Alexey Kuznetsov @ 2012-06-23 20:55 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, johunt, kaber, dbavatar, netdev, yoshfuji, jmorris,
pekkas, linux-kernel, Ben Greear
In-Reply-To: <1340429851.4604.11942.camel@edumazet-glaptop>
On Sat, Jun 23, 2012 at 07:37:31AM +0200, Eric Dumazet wrote:
> All other /proc/net files don't have a such sophisticated walkers aware
> mechanism
I can explain why.
IPv6 routing table has a capital management drawback: core policy rules are mixed
with dynamic cache and addrconf routes in one structure.
(BTW it is one of reasons why I did not want to integrate routing cache to fib for IPv4)
Do you see the problem? F.e. when you do iptables-save, you do not expect
that it can occasionally miss some rules (unless you mess with it in parallel, of course)
The same is here. When you dump routing table, you are allowed to miss some cache routes,
but if you have a chance to miss at least one of important routes just because
unimportant dynamic part is alway under change, it is fatal.
There are a lot of ways to solve the problem, all of them have some flaws.
F.e. I can remember:
* atomic dump like bsd sysctl.
* keeping administrative routes in a separate list, which can be walked using skip/count
etc.
This way with walkers I chose because it looked quite optimal and because
it was an exciting little task for brains . :-)
> (easily DOSable by the way, if some guy opens 10.000 handles
> and suspend in the middle the dumps).
This is true. The easiest way to fix this is just to limit amount of readers,
putting them on hold.
Alexey
^ permalink raw reply
* Re: Bug in net/ipv6/ip6_fib.c:fib6_dump_table()
From: David Miller @ 2012-06-23 23:02 UTC (permalink / raw)
To: kuznet
Cc: eric.dumazet, johunt, kaber, dbavatar, netdev, yoshfuji, jmorris,
pekkas, linux-kernel, greearb
In-Reply-To: <20120623205546.GA15964@ms2.inr.ac.ru>
From: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Date: Sun, 24 Jun 2012 00:55:46 +0400
> IPv6 routing table has a capital management drawback: core policy
> rules are mixed with dynamic cache and addrconf routes in one
> structure. (BTW it is one of reasons why I did not want to
> integrate routing cache to fib for IPv4)
Yes, and this causes other problems too. Recently I had to make the
dst cache not count pure ipv6 routes otherwise cache size limited how
many actual routes administrator could add.
I would like to eventually make ipv4 and ipv6 more similar rather than
more different. BTW, decision to use different host models (weak vs.
strong) in the two stacks was another idiotic move which makes
consolidation and code auditing harder.
I think once my long work to kill the ipv4 routing cache is complete
and successful we can model ipv6 after the results.
Major blockers are in two areas, reliance upon rt->rt_dst and...
performance :-)
Main reliance upon rt->rt_dst are:
1) Neighbours, which I plan to move to a model where lookups are
done on demand using RCU and lack of refcounts.
There are a few stragglers in infiniband and elsewhere that still
want to get a neighbour from a dst and I haven't converted over to
a lookup-on-demand model. I'm slowly working through those but it
is painful and thankless work.
It also involved trying to figure out reliable replacements for
magic tests like:
if (!dst_get_neighbour_noref_raw(&rt->dst) && !(rt->rt6i_flags & RTF_NONEXTHOP))
in ipv6. Really, the set of ipv6 dsts which have a neighbour
pre-attached is non-trivial to describe via other means.
dst_confirm() is left, which I'll handle by setting a "neigh
confirm pending bit", and next packet output when we have the neigh
looked up we'll update it's state and clear the bit in the dst. Or
something like this. Maybe a u8 or an int instead of a flag so we
don't need atomic ops.
Divorcing neigh from dst can have another huge benefit, no more
neighbour table overflow because small prefixed route for very
active subnets with improperly adjusted neighbour cache sizing.
We'll have more freedom to toss neighs because they'll be largely
ref-less unlike now where every route to external place holds onto
neigh.
2) Metrics, which really must be done differently.
Currently the scheme I have in mind is:
a) Pure TCP metrics move into RCU ref-count-free table and are
accessed on-demand. When TCP connection starts up, TCP fetches
metrics block from table. When TCP connection closes, TCP
pushes new metrics values into table.
b) PMTU and redirect information is moved back into route.
We clone new routes in FIB trie when PMTU or redirects are
received.
Metric table will be rooted in FIB table like inetpeer is now.
Inetpeer will become nearly orphan once more, only used for IP ID
generation and IPv4 fragment ID wrap detection.
Then we have no more need for rt->rt_dst to point to a specific IP
address once the routing cache is removed. It means we can use
routes constructed completely inside of FIB trie entries.
Next is worse area, performance. I can easily make output route
lookups fast without the routing cache, but input... mama mia!
Problems are two-fold:
1) Separation of local and main table, I plan to combine them. Well,
this applies to output and input routes.
This was really a terrible design decision. Only the most obscure
critters take advantage of this separation, yet everyone pays the
price. What's more their goals can be achieved by other means.
It means that every fib_lookup() is essentially two FIB trie
traversals instead of just one.
2) fib_validate_source(), really it is the most painful monster and
should never have been put into the FIB. It is really a netfilter
service, at best.
It means that, for forwarding global routes, we currently make 4
FIB trie traversals. FOUR. So no matter how fast Robert Olsson
made fib_trie, it still needs to be consulted 4 times.
I've tried to come up with algorithms that do this validation
cheaply. Especially for default typical configuration where this
kind of check is especially stupid and pointless. I have not had
any major breakthroughs.
For a workstation or typical one-interface server, it we eliminate
loopback anomalies earlier in the path, it can be a simple check I
suppose.
I plan to facilitate this also by making non-unicast specific
destination determination on-demand. Then there is class ID
determination, another huge hardship on everyone created by a
feature with a tiny class of users.
Anyways, that is brain dump.
^ permalink raw reply
* [PATCH 0/4] netfilter updates for net-next (upcoming 3.6), batch 4
From: pablo @ 2012-06-23 23:53 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
From: Pablo Neira Ayuso <pablo@netfilter.org>
Hi David,
The following four patches provide Netfilter fixes for the cthelper
infrastructure that was recently merged mainstream, they are:
* two fixes for compilation breakage with two different configurations:
- CONFIG_NF_NAT=m and CONFIG_NF_CT_NETLINK=y
- NF_CONNTRACK_EVENTS=n and CONFIG_NETFILTER_NETLINK_QUEUE_CT=y
* two fixes for sparse warnings.
You can pull this changes from:
git://1984.lsi.us.es/nf-next master
Thanks!
Pablo Neira Ayuso (4):
netfilter: nfq_ct_hook needs __rcu and __read_mostly
netfilter: nfnetlink_queue: fix compilation with CONFIG_NF_NAT=m and CONFIG_NF_CT_NETLINK=y
netfilter: nfnetlink_queue: fix sparse warning due to missing include
netfilter: ctnetlink: fix compilation with NF_CONNTRACK_EVENTS=n
include/linux/netfilter.h | 6 +++++-
net/ipv4/netfilter/nf_nat_core.c | 6 ++++++
net/netfilter/core.c | 5 ++++-
net/netfilter/nf_conntrack_netlink.c | 5 +----
net/netfilter/nfnetlink_queue_ct.c | 9 +++++----
5 files changed, 21 insertions(+), 10 deletions(-)
--
1.7.10
^ permalink raw reply
* [PATCH 2/4] netfilter: nfnetlink_queue: fix compilation with CONFIG_NF_NAT=m and CONFIG_NF_CT_NETLINK=y
From: pablo @ 2012-06-23 23:53 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1340495609-26250-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
LD init/built-in.o
net/built-in.o:(.data+0x4408): undefined reference to `nf_nat_tcp_seq_adjust'
make: *** [vmlinux] Error 1
This patch adds a new pointer hook (nfq_ct_nat_hook) similar to other existing
in Netfilter to solve our complicated configuration dependencies.
Reported-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/linux/netfilter.h | 6 +++++-
net/ipv4/netfilter/nf_nat_core.c | 6 ++++++
net/netfilter/core.c | 3 +++
net/netfilter/nf_conntrack_netlink.c | 3 ---
net/netfilter/nfnetlink_queue_ct.c | 8 ++++----
5 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h
index 38b96a5..c613cf0 100644
--- a/include/linux/netfilter.h
+++ b/include/linux/netfilter.h
@@ -401,10 +401,14 @@ struct nfq_ct_hook {
size_t (*build_size)(const struct nf_conn *ct);
int (*build)(struct sk_buff *skb, struct nf_conn *ct);
int (*parse)(const struct nlattr *attr, struct nf_conn *ct);
+};
+extern struct nfq_ct_hook __rcu *nfq_ct_hook;
+
+struct nfq_ct_nat_hook {
void (*seq_adjust)(struct sk_buff *skb, struct nf_conn *ct,
u32 ctinfo, int off);
};
-extern struct nfq_ct_hook __rcu *nfq_ct_hook;
+extern struct nfq_ct_nat_hook __rcu *nfq_ct_nat_hook;
#else
static inline void nf_ct_attach(struct sk_buff *new, struct sk_buff *skb) {}
#endif
diff --git a/net/ipv4/netfilter/nf_nat_core.c b/net/ipv4/netfilter/nf_nat_core.c
index abb52ad..44b082f 100644
--- a/net/ipv4/netfilter/nf_nat_core.c
+++ b/net/ipv4/netfilter/nf_nat_core.c
@@ -691,6 +691,10 @@ static struct nf_ct_helper_expectfn follow_master_nat = {
.expectfn = nf_nat_follow_master,
};
+static struct nfq_ct_nat_hook nfq_ct_nat = {
+ .seq_adjust = nf_nat_tcp_seq_adjust,
+};
+
static int __init nf_nat_init(void)
{
size_t i;
@@ -731,6 +735,7 @@ static int __init nf_nat_init(void)
nfnetlink_parse_nat_setup);
BUG_ON(nf_ct_nat_offset != NULL);
RCU_INIT_POINTER(nf_ct_nat_offset, nf_nat_get_offset);
+ RCU_INIT_POINTER(nfq_ct_nat_hook, &nfq_ct_nat);
return 0;
cleanup_extend:
@@ -747,6 +752,7 @@ static void __exit nf_nat_cleanup(void)
RCU_INIT_POINTER(nf_nat_seq_adjust_hook, NULL);
RCU_INIT_POINTER(nfnetlink_parse_nat_setup_hook, NULL);
RCU_INIT_POINTER(nf_ct_nat_offset, NULL);
+ RCU_INIT_POINTER(nfq_ct_nat_hook, NULL);
synchronize_net();
}
diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index 4cd10ed..0bc6b60 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -268,6 +268,9 @@ EXPORT_SYMBOL(nf_conntrack_destroy);
struct nfq_ct_hook __rcu *nfq_ct_hook __read_mostly;
EXPORT_SYMBOL_GPL(nfq_ct_hook);
+struct nfq_ct_nat_hook __rcu *nfq_ct_nat_hook __read_mostly;
+EXPORT_SYMBOL_GPL(nfq_ct_nat_hook);
+
#endif /* CONFIG_NF_CONNTRACK */
#ifdef CONFIG_PROC_FS
diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index 31d1d8f..8bb4733 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -1757,9 +1757,6 @@ static struct nfq_ct_hook ctnetlink_nfqueue_hook = {
.build_size = ctnetlink_nfqueue_build_size,
.build = ctnetlink_nfqueue_build,
.parse = ctnetlink_nfqueue_parse,
-#ifdef CONFIG_NF_NAT_NEEDED
- .seq_adjust = nf_nat_tcp_seq_adjust,
-#endif
};
#endif /* CONFIG_NETFILTER_NETLINK_QUEUE_CT */
diff --git a/net/netfilter/nfnetlink_queue_ct.c b/net/netfilter/nfnetlink_queue_ct.c
index 68ef550..01247b7 100644
--- a/net/netfilter/nfnetlink_queue_ct.c
+++ b/net/netfilter/nfnetlink_queue_ct.c
@@ -86,12 +86,12 @@ nla_put_failure:
void nfqnl_ct_seq_adjust(struct sk_buff *skb, struct nf_conn *ct,
enum ip_conntrack_info ctinfo, int diff)
{
- struct nfq_ct_hook *nfq_ct;
+ struct nfq_ct_nat_hook *nfq_nat_ct;
- nfq_ct = rcu_dereference(nfq_ct_hook);
- if (nfq_ct == NULL)
+ nfq_nat_ct = rcu_dereference(nfq_ct_nat_hook);
+ if (nfq_nat_ct == NULL)
return;
if ((ct->status & IPS_NAT_MASK) && diff)
- nfq_ct->seq_adjust(skb, ct, ctinfo, diff);
+ nfq_nat_ct->seq_adjust(skb, ct, ctinfo, diff);
}
--
1.7.10
^ permalink raw reply related
* [PATCH 4/4] netfilter: ctnetlink: fix compilation with NF_CONNTRACK_EVENTS=n
From: pablo @ 2012-06-23 23:53 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1340495609-26250-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
This patch fixes compilation with NF_CONNTRACK_EVENTS=n and
NETFILTER_NETLINK_QUEUE_CT=y.
I'm leaving all those static inline functions that calculate the size
of the event message out of the ifdef area of NF_CONNTRACK_EVENTS since
they will not be included by gcc in case they are unused.
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_conntrack_netlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index 8bb4733..b9b8f4a 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -478,7 +478,6 @@ nla_put_failure:
return -1;
}
-#ifdef CONFIG_NF_CONNTRACK_EVENTS
static inline size_t
ctnetlink_proto_size(const struct nf_conn *ct)
{
@@ -565,6 +564,7 @@ ctnetlink_nlmsg_size(const struct nf_conn *ct)
;
}
+#ifdef CONFIG_NF_CONNTRACK_EVENTS
static int
ctnetlink_conntrack_event(unsigned int events, struct nf_ct_event *item)
{
--
1.7.10
^ permalink raw reply related
* [PATCH 1/4] netfilter: nfq_ct_hook needs __rcu and __read_mostly
From: pablo @ 2012-06-23 23:53 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1340495609-26250-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
This removes some sparse warnings.
Reported-by: Fengguang Wu <wfg@linux.intel.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/linux/netfilter.h | 2 +-
net/netfilter/core.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h
index dca19e6..38b96a5 100644
--- a/include/linux/netfilter.h
+++ b/include/linux/netfilter.h
@@ -404,7 +404,7 @@ struct nfq_ct_hook {
void (*seq_adjust)(struct sk_buff *skb, struct nf_conn *ct,
u32 ctinfo, int off);
};
-extern struct nfq_ct_hook *nfq_ct_hook;
+extern struct nfq_ct_hook __rcu *nfq_ct_hook;
#else
static inline void nf_ct_attach(struct sk_buff *new, struct sk_buff *skb) {}
#endif
diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index 7eef845..4cd10ed 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -265,7 +265,7 @@ void nf_conntrack_destroy(struct nf_conntrack *nfct)
}
EXPORT_SYMBOL(nf_conntrack_destroy);
-struct nfq_ct_hook *nfq_ct_hook;
+struct nfq_ct_hook __rcu *nfq_ct_hook __read_mostly;
EXPORT_SYMBOL_GPL(nfq_ct_hook);
#endif /* CONFIG_NF_CONNTRACK */
--
1.7.10
^ 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