* Re: [PATCH net-next] netfilter: nf_conntrack.h: use this_cpu_inc()
From: Pablo Neira Ayuso @ 2012-04-19 18:16 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, netdev, Christoph Lameter, Tejun Heo,
Patrick McHardy, Netfilter Development Mailing list
In-Reply-To: <1334723800.2472.88.camel@edumazet-glaptop>
On Wed, Apr 18, 2012 at 06:36:40AM +0200, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> this_cpu_inc() is IRQ safe and faster than
> local_bh_disable()/__this_cpu_inc()/local_bh_enable(), at least on x86.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: Christoph Lameter <cl@linux.com>
> Cc: Tejun Heo <tj@kernel.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] ip6_tunnel: dont drop packet but consume it
From: David Miller @ 2012-04-19 18:24 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1334838257.2395.150.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 19 Apr 2012 14:24:17 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> When we need to reallocate skb, we dont drop a packet.
> Call consume_skb() to not confuse dropwatch.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] netlink: dont drop packet but consume it
From: David Miller @ 2012-04-19 18:24 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1334838268.2395.151.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 19 Apr 2012 14:24:28 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> When we need to clone skb, we dont drop a packet.
> Call consume_skb() to not confuse dropwatch.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: tcp: dont drop packet but consume it
From: David Miller @ 2012-04-19 18:24 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1334838276.2395.152.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 19 Apr 2012 14:24:36 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> When we need to clone skb, we dont drop a packet.
> Call consume_skb() to not confuse dropwatch.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] packet: dont drop packet but consume it
From: David Miller @ 2012-04-19 18:24 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1334838282.2395.153.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 19 Apr 2012 14:24:42 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> When we need to clone skb, we dont drop a packet.
> Call consume_skb() to not confuse dropwatch.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: dccp: dont drop packet but consume it
From: David Miller @ 2012-04-19 18:24 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1334838288.2395.156.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 19 Apr 2012 14:24:48 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> When we need to clone skb, we dont drop a packet.
> Call consume_skb() to not confuse dropwatch.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: dont drop packet but consume it
From: David Miller @ 2012-04-19 18:24 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1334838293.2395.157.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 19 Apr 2012 14:24:53 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> When we need to clone skb, we dont drop a packet.
> Call consume_skb() to not confuse dropwatch.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: dont drop packet in defrag but consume it
From: David Miller @ 2012-04-19 18:25 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1334851826.2395.192.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 19 Apr 2012 18:10:26 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> When defragmentation is finalized, we clone a packet and kfree_skb() it.
>
> Call consume_skb() to not confuse dropwatch, since its not a drop.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: gro: GRO_MERGED_FREE consumes packets
From: David Miller @ 2012-04-19 18:25 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1334855260.2395.195.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 19 Apr 2012 19:07:40 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> As part of GRO processing, merged skbs should be consumed, not freed, to
> not confuse dropwatch/drop_monitor.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] workqueue: Catch more locking problems with flush_work()
From: Stephen Boyd @ 2012-04-19 18:36 UTC (permalink / raw)
To: Yong Zhang; +Cc: linux-kernel, Tejun Heo, netdev, Ben Dooks
In-Reply-To: <20120419081002.GB3963@zhy>
On 04/19/12 01:10, Yong Zhang wrote:
> On Wed, Apr 18, 2012 at 08:25:57PM -0700, Stephen Boyd wrote:
>> If a workqueue is flushed but the work item is not scheduled to
>> run, lockdep checking will be circumvented. For example:
>>
>> static DEFINE_MUTEX(mutex);
>>
>> static void my_work(struct work_struct *w)
>> {
>> mutex_lock(&mutex);
>> mutex_unlock(&mutex);
>> }
>>
>> static DECLARE_WORK(work, my_work);
>>
>> static int __init start_test_module(void)
>> {
>> schedule_work(&work);
>> return 0;
>> }
>> module_init(start_test_module);
>>
>> static void __exit stop_test_module(void)
>> {
>> mutex_lock(&mutex);
>> flush_work(&work);
>> mutex_unlock(&mutex);
>> }
>> module_exit(stop_test_module);
>>
>> would only print a warning if the work item was actively running
>> when flush_work() was called. Otherwise flush_work() returns
>> early. In this trivial example nothing could go wrong, but if the
>> work item is schedule via an interrupt we could potentially have a
>> scenario where the work item is running just at the time flush_work()
> You mean flush_work() could be called in interupt? I don't it is
> possible.
No.
>
>> is called. This could become a classic AB-BA locking problem.
> I don't see how the deadlock happen, could you please be more
> specific?
>
Does looking at the second patch help? Basically schedule_work() can run
the callback right between the time the mutex is acquired and
flush_work() is called:
CPU0 CPU1
<irq>
schedule_work() mutex_lock(&mutex)
<irq return>
my_work() flush_work()
mutex_lock(&mutex)
<deadlock>
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH 1/2 v2] pch_gbe: Do not abort probe on bad MAC
From: Greg KH @ 2012-04-19 18:41 UTC (permalink / raw)
To: Tomoya MORINAGA
Cc: stable, Darren Hart, Arjan van de Ven, Alan Cox, Jeff Kirsher,
David S. Miller, Paul Gortmaker, Jon Mason, netdev, Mark Brown,
David Laight, Joe Perches
In-Reply-To: <1333335645-14413-1-git-send-email-tomoya.rohm@gmail.com>
On Mon, Apr 02, 2012 at 12:00:44PM +0900, Tomoya MORINAGA wrote:
> If the MAC is invalid or not implemented, do not abort the probe. Issue
> a warning and prevent bringing the interface up until a MAC is set manually
> (via ifconfig $IFACE hw ether $MAC).
>
> Tested on two platforms, one with a valid MAC, the other without a MAC. The real
> MAC is used if present, the interface fails to come up until the MAC is set on
> the other. They successfully get an IP over DHCP and pass a simple ping and
> login over ssh test.
>
> This is meant to allow the Inforce SYS940X development board:
> http://www.inforcecomputing.com/SYS940X_ECX.html
> (and others suffering from a missing MAC) to work with the mainline kernel.
> Without this patch, the probe will fail and the interface will not be created,
> preventing the user from configuring the MAC manually.
>
> This does not make any attempt to address a missing or invalid MAC for the
> pch_phub driver.
>
> commit: 2b53d07891630dead46d65c8f896955fd3ae0302
> kernel version: 3.0, 3.2
How can you want this in 3.0, when the file this patches is not in the
3.0 kernel tree?
Please be more careful.
greg k-h
^ permalink raw reply
* Re: [PATCH net-next] nf_bridge: remove holes in struct nf_bridge_info
From: David Miller @ 2012-04-19 19:19 UTC (permalink / raw)
To: shemminger; +Cc: eric.dumazet, netdev
In-Reply-To: <20120419075246.0df140e9@s6510.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 19 Apr 2012 07:52:46 -0700
> On Thu, 19 Apr 2012 11:19:25 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> From: Eric Dumazet <edumazet@google.com>
>>
>> Put use & mask on same location to avoid two holes on 64bit arches
>>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks.
^ permalink raw reply
* Re: [patch] bnx2x: off by one in bnx2x_ets_e3b0_sp_pri_to_cos_set()
From: David Miller @ 2012-04-19 19:23 UTC (permalink / raw)
To: eilong; +Cc: dan.carpenter, netdev, kernel-janitors
In-Reply-To: <1334741227.12363.5.camel@lb-tlvb-eilong.il.broadcom.com>
From: "Eilon Greenstein" <eilong@broadcom.com>
Date: Wed, 18 Apr 2012 12:27:07 +0300
> On Wed, 2012-04-18 at 09:53 +0300, Dan Carpenter wrote:
>> The sp_pri_to_cos[] array size depends on the config but lets say it is
>> BX_E3B0_MAX_NUM_COS_PORT0 and max_num_of_cos is also
>> DCBX_E3B0_MAX_NUM_COS_PORT0. In the original code
>> "pri == max_num_of_cos" was accepted but it is one past the end of the
>> array.
>>
>> Also we used "pri" before capping it. It's a harmless read past the end
>> of the array, but it would affect which error message gets printed.
>>
>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>>
>
> Acked-by: Eilon Greenstein <eilong@broadcom.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [net-next PATCH v3] bonding: start slaves with link down for ARP monitor
From: David Miller @ 2012-04-19 19:25 UTC (permalink / raw)
To: fbl; +Cc: mkubecek, netdev, fubar, andy
In-Reply-To: <20120418161912.1c0e2f4e@asterix.rh>
From: Flavio Leitner <fbl@redhat.com>
Date: Wed, 18 Apr 2012 16:19:12 -0300
> On Tue, 17 Apr 2012 14:02:06 +0200
> Michal Kubecek <mkubecek@suse.cz> wrote:
>
>> Initialize slave device link state as down if ARP monitor is
>> active and net_carrier_ok() returns zero. Also shift initial
>> value of its last_arp_tx so that it doesn't immediately cause
>> fake detection of "up" state.
>>
>> When ARP monitoring is used, initializing the slave device with
>> up link state can cause ARP monitor to detect link failure
>> before the device is really up (with igb driver, this can take
>> more than two seconds).
>>
>> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
>
> Signed-off-by: Flavio Leitner <fbl@redhat.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: support Sierra Wireless MC77xx devices in QMI mode
From: David Miller @ 2012-04-19 19:33 UTC (permalink / raw)
To: bjorn; +Cc: netdev
In-Reply-To: <1334691503-31787-1-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Tue, 17 Apr 2012 21:38:23 +0200
> The MC77xx devices can operate in two modes: "Direct IP" or "QMI",
> switchable using a password protected AT command. Both product ID
> and USB interface configuration will change when switched.
>
> The "sierra_net" driver supports the "Direct IP" mode. This driver
> supports the "QMI" mode.
>
> There are also multiple possible USB interface configurations in each
> mode, some providing more than one wwan interface. Like many other
> devices made for Windows, different interface types are identified
> using a static interface number. We define a Sierra specific
> interface whitelist to support this.
>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] icplus: fix interrupt for IC+ 101A/G and 1001LF
From: David Miller @ 2012-04-19 19:34 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1334733400-29340-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Wed, 18 Apr 2012 09:16:40 +0200
> This patch fixes and adds the irq handler for the
> IC+ 101A/G where we need to read the reg17 to clean
> the irq.
> Also remove the flag for the 1001LF where no interrupt
> can be used for this device.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net ax25: Reorder ax25_exit to remove races.
From: David Miller @ 2012-04-19 19:38 UTC (permalink / raw)
To: ebiederm; +Cc: netdev, ralf, linux-hams
In-Reply-To: <m1hawgjws4.fsf@fess.ebiederm.org>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Wed, 18 Apr 2012 19:11:23 -0700
> While reviewing the sysctl code in ax25 I spotted races in ax25_exit
> where it is possible to receive notifications and packets after already
> freeing up some of the data structures needed to process those
> notifications and updates.
>
> Call unregister_netdevice_notifier early so that the rest of the cleanup
> code does not need to deal with network devices. This takes advantage
> of my recent enhancement to unregister_netdevice_notifier to send
> unregister notifications of all network devices that are current
> registered.
>
> Move the unregistration for packet types, socket types and protocol
> types before we cleanup any of the ax25 data structures to remove the
> possibilities of other races.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Applied, thanks a lot Eric.
^ permalink raw reply
* [PATCH net-next] net: allow better page reuse in splice(sock -> pipe)
From: Eric Dumazet @ 2012-04-19 19:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
splice() from socket to pipe needs linear_to_page() helper to transfert
skb header to part of page.
We can reset the offset in the current sk->sk_sndmsg_page if we are the
last user of the page.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/core/skbuff.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 43c490d..bf257de 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -1565,6 +1565,9 @@ new_page:
} else {
unsigned int mlen;
+ /* If we are the only user of the page, we can reset offset */
+ if (page_count(p) == 1)
+ sk->sk_sndmsg_off = 0;
off = sk->sk_sndmsg_off;
mlen = PAGE_SIZE - off;
if (mlen < 64 && mlen < *len) {
^ permalink raw reply related
* RE: net-next iwlwifi breaks compile - was Re: pull request: wireless-next 2012-04-18
From: Venkataraman, Meenakshi @ 2012-04-19 19:47 UTC (permalink / raw)
To: Oliver Hartkopp, David Miller, Guy, Wey-Yi W
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Spinadel, David
In-Reply-To: <4F8F9977.9040703-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Hey Oliver,
>Commit "iwlwifi: move scan related declarations out of iwl-core.h"
>
>http://git.kernel.org/?p=linux/kernel/git/davem/net-
>next.git;a=commitdiff;h=8fb96d6e176cbf0a97b2391fa1fa09e608ee86f8
>
>breaks the compile when CONFIG_IWLWIFI_DEBUGFS is not set, see:
[MV] Sorry about breaking net-next. I took a look at the patch that you've pointed to, and actually it's a patch that caused the problem. The commit that broke it is actually:
iwlwifi: expose static methods for MVM use
http://git.kernel.org/?p=linux/kernel/git/davem/net-next.git;a=commit;h=50c1e9a9e3b086465b1467d448c10f7fa1e0eb5c
It was fixed internally in a subsequent patch, but that patch has not made it into net-next. I don't see it in the public iwlwifi repository either. We'll add the fix to the repository so you can pick it up.
Thanks & sorry,
Meenakshi
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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: net-next iwlwifi breaks compile - was Re: pull request: wireless-next 2012-04-18
From: David Miller @ 2012-04-19 19:49 UTC (permalink / raw)
To: meenakshi.venkataraman
Cc: socketcan, wey-yi.w.guy, linville, linux-wireless, netdev,
david.spinadel
In-Reply-To: <4595B4D22AB93C4FABBA84AAD5AA37FD1258AA@ORSMSX103.amr.corp.intel.com>
From: "Venkataraman, Meenakshi" <meenakshi.venkataraman@intel.com>
Date: Thu, 19 Apr 2012 19:47:58 +0000
> It was fixed internally in a subsequent patch, but that patch has
> not made it into net-next. I don't see it in the public iwlwifi
> repository either. We'll add the fix to the repository so you can
> pick it up.
That's not how this works.
You should submit a patch to fix the build directly to me, immediately,
so that I can push it directly into net-next as fast as possible.
^ permalink raw reply
* Re: RTM_NEWLINK not received by application when connecting multiple devices simultaneously
From: Kristian Evensen @ 2012-04-19 19:54 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Ben Greear, netdev
In-Reply-To: <CAKfDRXjCr0aDSDT8zN8A7_iNX6KAJwrR3NxaB8GAgz5oEiCB3w@mail.gmail.com>
I spent some more time debugging this now. It turns out that which
interface is seen by my application is not random, it is always the
first one that is connected. This indicates that the bug is that the
netlink message contains information about more than one interface.
However, I am not able to prove this.
When I check for the presence of NLM_F_MULTI, it is always NULL. Also,
the length of the received nlmsg (including payload) always equals the
numbers of bytes I receive from the netlink socket, i.e., all the data
is received.
Based on my understanding of netlink, an nlmsg will only contain one
packet (for example ifinfomsg), unless the NLM_F_MULTI flag is set. Or
am I mistaken?
-Kristian
^ permalink raw reply
* Re: net-next iwlwifi breaks compile - was Re: pull request: wireless-next 2012-04-18
From: Guy, Wey-Yi @ 2012-04-19 20:10 UTC (permalink / raw)
To: David Miller
Cc: meenakshi.venkataraman-ral2JQCrhuEAvxtiuMwx3w,
socketcan-fJ+pQTUTwRTk1uMJSBkQmQ, linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
david.spinadel-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20120419.154954.1322943404183128381.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 744 bytes --]
Hi David,
On Thu, 2012-04-19 at 15:49 -0400, David Miller wrote:
> From: "Venkataraman, Meenakshi" <meenakshi.venkataraman-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Date: Thu, 19 Apr 2012 19:47:58 +0000
>
> > It was fixed internally in a subsequent patch, but that patch has
> > not made it into net-next. I don't see it in the public iwlwifi
> > repository either. We'll add the fix to the repository so you can
> > pick it up.
>
> That's not how this works.
>
> You should submit a patch to fix the build directly to me, immediately,
> so that I can push it directly into net-next as fast as possible.
The patch "iwlwifi-Remove-inconsistent-and-redundant-declaratio.patch"
already being push to John to address this issue
Thanks
Wey
[-- Attachment #2: 0012-iwlwifi-Remove-inconsistent-and-redundant-declaratio.patch --]
[-- Type: text/x-patch, Size: 1354 bytes --]
>From c27cf685d185cc4604776252fdcaca5ad24abcca Mon Sep 17 00:00:00 2001
From: David Spinadel <david.spinadel-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date: Tue, 27 Mar 2012 10:22:29 +0200
Subject: [PATCH 12/15] iwlwifi: Remove inconsistent and redundant declaration
Remove declaration of iwl_alloc_traffic_mem from iwl-agn.h,
from methods that was exposed to support MVM.
MVM doesn't have to use this declaration.
Signed-off-by: David Spinadel <david.spinadel-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
drivers/net/wireless/iwlwifi/iwl-agn.h | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.h b/drivers/net/wireless/iwlwifi/iwl-agn.h
index 67cd123..3d6f3e2 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.h
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.h
@@ -510,7 +510,6 @@ void iwl_setup_deferred_work(struct iwl_priv *priv);
int iwl_send_wimax_coex(struct iwl_priv *priv);
int iwl_send_bt_env(struct iwl_priv *priv, u8 action, u8 type);
void iwl_debug_config(struct iwl_priv *priv);
-int iwl_alloc_traffic_mem(struct iwl_priv *priv);
void iwl_set_hw_params(struct iwl_priv *priv);
void iwl_init_context(struct iwl_priv *priv, u32 ucode_flags);
int iwl_init_drv(struct iwl_priv *priv);
--
1.7.0.4
^ permalink raw reply related
* [PATCH net-next] tcp: move duplicate code from tcp_v4_init_sock()/tcp_v6_init_sock()
From: Neal Cardwell @ 2012-04-19 19:55 UTC (permalink / raw)
To: David Miller
Cc: netdev, Eric Dumazet, Nandita Dukkipati, Yuchung Cheng,
ilpo.jarvinen, maze, Tom Herbert, Neal Cardwell
This commit moves the (substantial) common code shared between
tcp_v4_init_sock() and tcp_v6_init_sock() to a new address-family
independent function, tcp_init_sock().
Centralizing this functionality should help avoid drift issues,
e.g. where the IPv4 side is updated without a corresponding update to
IPv6. There was already some drift: IPv4 initialized snd_cwnd to
TCP_INIT_CWND, while the IPv6 side was still initializing snd_cwnd to
2 (in this case it should not matter, since snd_cwnd is also
initialized in tcp_init_metrics(), but the general risks and
maintenance overhead remain).
When diffing the old and new code, note that new tcp_init_sock()
function uses the order of steps from the tcp_v4_init_sock()
implementation (the order is slightly different in
tcp_v6_init_sock()).
Signed-off-by: Neal Cardwell <ncardwell@google.com>
---
include/net/tcp.h | 1 +
net/ipv4/tcp.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++
net/ipv4/tcp_ipv4.c | 52 +---------------------------------------
net/ipv6/tcp_ipv6.c | 50 +---------------------------------------
4 files changed, 68 insertions(+), 99 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index d5984e3..eff4249 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -395,6 +395,7 @@ extern void tcp_enter_loss(struct sock *sk, int how);
extern void tcp_clear_retrans(struct tcp_sock *tp);
extern void tcp_update_metrics(struct sock *sk);
extern void tcp_close(struct sock *sk, long timeout);
+extern void tcp_init_sock(struct sock *sk);
extern unsigned int tcp_poll(struct file * file, struct socket *sock,
struct poll_table_struct *wait);
extern int tcp_getsockopt(struct sock *sk, int level, int optname,
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index c53e8a8..f87bebf 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -363,6 +363,70 @@ static int retrans_to_secs(u8 retrans, int timeout, int rto_max)
return period;
}
+/* Address-family independent initialization for a tcp_sock.
+ *
+ * NOTE: A lot of things set to zero explicitly by call to
+ * sk_alloc() so need not be done here.
+ */
+void tcp_init_sock(struct sock *sk)
+{
+ struct inet_connection_sock *icsk = inet_csk(sk);
+ struct tcp_sock *tp = tcp_sk(sk);
+
+ skb_queue_head_init(&tp->out_of_order_queue);
+ tcp_init_xmit_timers(sk);
+ tcp_prequeue_init(tp);
+
+ icsk->icsk_rto = TCP_TIMEOUT_INIT;
+ tp->mdev = TCP_TIMEOUT_INIT;
+
+ /* So many TCP implementations out there (incorrectly) count the
+ * initial SYN frame in their delayed-ACK and congestion control
+ * algorithms that we must have the following bandaid to talk
+ * efficiently to them. -DaveM
+ */
+ tp->snd_cwnd = TCP_INIT_CWND;
+
+ /* See draft-stevens-tcpca-spec-01 for discussion of the
+ * initialization of these values.
+ */
+ tp->snd_ssthresh = TCP_INFINITE_SSTHRESH;
+ tp->snd_cwnd_clamp = ~0;
+ tp->mss_cache = TCP_MSS_DEFAULT;
+
+ tp->reordering = sysctl_tcp_reordering;
+ icsk->icsk_ca_ops = &tcp_init_congestion_ops;
+
+ sk->sk_state = TCP_CLOSE;
+
+ sk->sk_write_space = sk_stream_write_space;
+ sock_set_flag(sk, SOCK_USE_WRITE_QUEUE);
+
+ icsk->icsk_sync_mss = tcp_sync_mss;
+
+ /* TCP Cookie Transactions */
+ if (sysctl_tcp_cookie_size > 0) {
+ /* Default, cookies without s_data_payload. */
+ tp->cookie_values =
+ kzalloc(sizeof(*tp->cookie_values),
+ sk->sk_allocation);
+ if (tp->cookie_values != NULL)
+ kref_init(&tp->cookie_values->kref);
+ }
+ /* Presumed zeroed, in order of appearance:
+ * cookie_in_always, cookie_out_never,
+ * s_data_constant, s_data_in, s_data_out
+ */
+ sk->sk_sndbuf = sysctl_tcp_wmem[1];
+ sk->sk_rcvbuf = sysctl_tcp_rmem[1];
+
+ local_bh_disable();
+ sock_update_memcg(sk);
+ sk_sockets_allocated_inc(sk);
+ local_bh_enable();
+}
+EXPORT_SYMBOL(tcp_init_sock);
+
/*
* Wait for a TCP event.
*
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 0cb86ce..abfbeec 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1877,62 +1877,14 @@ static int tcp_v4_init_sock(struct sock *sk)
struct inet_connection_sock *icsk = inet_csk(sk);
struct tcp_sock *tp = tcp_sk(sk);
- skb_queue_head_init(&tp->out_of_order_queue);
- tcp_init_xmit_timers(sk);
- tcp_prequeue_init(tp);
-
- icsk->icsk_rto = TCP_TIMEOUT_INIT;
- tp->mdev = TCP_TIMEOUT_INIT;
-
- /* So many TCP implementations out there (incorrectly) count the
- * initial SYN frame in their delayed-ACK and congestion control
- * algorithms that we must have the following bandaid to talk
- * efficiently to them. -DaveM
- */
- tp->snd_cwnd = TCP_INIT_CWND;
-
- /* See draft-stevens-tcpca-spec-01 for discussion of the
- * initialization of these values.
- */
- tp->snd_ssthresh = TCP_INFINITE_SSTHRESH;
- tp->snd_cwnd_clamp = ~0;
- tp->mss_cache = TCP_MSS_DEFAULT;
-
- tp->reordering = sysctl_tcp_reordering;
- icsk->icsk_ca_ops = &tcp_init_congestion_ops;
-
- sk->sk_state = TCP_CLOSE;
-
- sk->sk_write_space = sk_stream_write_space;
- sock_set_flag(sk, SOCK_USE_WRITE_QUEUE);
+ tcp_init_sock(sk);
icsk->icsk_af_ops = &ipv4_specific;
- icsk->icsk_sync_mss = tcp_sync_mss;
+
#ifdef CONFIG_TCP_MD5SIG
tp->af_specific = &tcp_sock_ipv4_specific;
#endif
- /* TCP Cookie Transactions */
- if (sysctl_tcp_cookie_size > 0) {
- /* Default, cookies without s_data_payload. */
- tp->cookie_values =
- kzalloc(sizeof(*tp->cookie_values),
- sk->sk_allocation);
- if (tp->cookie_values != NULL)
- kref_init(&tp->cookie_values->kref);
- }
- /* Presumed zeroed, in order of appearance:
- * cookie_in_always, cookie_out_never,
- * s_data_constant, s_data_in, s_data_out
- */
- sk->sk_sndbuf = sysctl_tcp_wmem[1];
- sk->sk_rcvbuf = sysctl_tcp_rmem[1];
-
- local_bh_disable();
- sock_update_memcg(sk);
- sk_sockets_allocated_inc(sk);
- local_bh_enable();
-
return 0;
}
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 86cfe60..a73dff0 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1831,62 +1831,14 @@ static int tcp_v6_init_sock(struct sock *sk)
struct inet_connection_sock *icsk = inet_csk(sk);
struct tcp_sock *tp = tcp_sk(sk);
- skb_queue_head_init(&tp->out_of_order_queue);
- tcp_init_xmit_timers(sk);
- tcp_prequeue_init(tp);
-
- icsk->icsk_rto = TCP_TIMEOUT_INIT;
- tp->mdev = TCP_TIMEOUT_INIT;
-
- /* So many TCP implementations out there (incorrectly) count the
- * initial SYN frame in their delayed-ACK and congestion control
- * algorithms that we must have the following bandaid to talk
- * efficiently to them. -DaveM
- */
- tp->snd_cwnd = 2;
-
- /* See draft-stevens-tcpca-spec-01 for discussion of the
- * initialization of these values.
- */
- tp->snd_ssthresh = TCP_INFINITE_SSTHRESH;
- tp->snd_cwnd_clamp = ~0;
- tp->mss_cache = TCP_MSS_DEFAULT;
-
- tp->reordering = sysctl_tcp_reordering;
-
- sk->sk_state = TCP_CLOSE;
+ tcp_init_sock(sk);
icsk->icsk_af_ops = &ipv6_specific;
- icsk->icsk_ca_ops = &tcp_init_congestion_ops;
- icsk->icsk_sync_mss = tcp_sync_mss;
- sk->sk_write_space = sk_stream_write_space;
- sock_set_flag(sk, SOCK_USE_WRITE_QUEUE);
#ifdef CONFIG_TCP_MD5SIG
tp->af_specific = &tcp_sock_ipv6_specific;
#endif
- /* TCP Cookie Transactions */
- if (sysctl_tcp_cookie_size > 0) {
- /* Default, cookies without s_data_payload. */
- tp->cookie_values =
- kzalloc(sizeof(*tp->cookie_values),
- sk->sk_allocation);
- if (tp->cookie_values != NULL)
- kref_init(&tp->cookie_values->kref);
- }
- /* Presumed zeroed, in order of appearance:
- * cookie_in_always, cookie_out_never,
- * s_data_constant, s_data_in, s_data_out
- */
- sk->sk_sndbuf = sysctl_tcp_wmem[1];
- sk->sk_rcvbuf = sysctl_tcp_rmem[1];
-
- local_bh_disable();
- sock_update_memcg(sk);
- sk_sockets_allocated_inc(sk);
- local_bh_enable();
-
return 0;
}
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH net-next] tcp: move duplicate code from tcp_v4_init_sock()/tcp_v6_init_sock()
From: Eric Dumazet @ 2012-04-19 20:21 UTC (permalink / raw)
To: Neal Cardwell
Cc: David Miller, netdev, Eric Dumazet, Nandita Dukkipati,
Yuchung Cheng, ilpo.jarvinen, maze, Tom Herbert
In-Reply-To: <1334865321-20288-1-git-send-email-ncardwell@google.com>
On Thu, 2012-04-19 at 15:55 -0400, Neal Cardwell wrote:
> This commit moves the (substantial) common code shared between
> tcp_v4_init_sock() and tcp_v6_init_sock() to a new address-family
> independent function, tcp_init_sock().
>
> Centralizing this functionality should help avoid drift issues,
> e.g. where the IPv4 side is updated without a corresponding update to
> IPv6. There was already some drift: IPv4 initialized snd_cwnd to
> TCP_INIT_CWND, while the IPv6 side was still initializing snd_cwnd to
> 2 (in this case it should not matter, since snd_cwnd is also
> initialized in tcp_init_metrics(), but the general risks and
> maintenance overhead remain).
>
> When diffing the old and new code, note that new tcp_init_sock()
> function uses the order of steps from the tcp_v4_init_sock()
> implementation (the order is slightly different in
> tcp_v6_init_sock()).
>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
> ---
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* compat-wireless-3.4-rc3-1.tar.bz2 released
From: Luis R. Rodriguez @ 2012-04-19 20:26 UTC (permalink / raw)
To: lf_driver_backport; +Cc: linux-kernel, linux-wireless, linux-bluetooth, netdev
I've kicked out a new compat-wireless release based on 3.4-rc3 [0],
check out the ChangeLog-3.4-rc3 [1] for more details and if you are
interested in the build log check out the ckmake-3.4-rc1-2.log.bz2
[2]. Below are the code metrics and the ckmake log summary:
compat-wireless code metrics
829063 - Total upstream lines of code being pulled
2748 - backport code changes
2333 - backport code additions
415 - backport code deletions
9575 - backport from compat module
12323 - total backport code
1.4864 - % of code consists of backport work
Base tree: linux-stable.git
Base tree version: v3.4-rc3
compat-wireless release: compat-wireless-v3.4-rc3-1
Trying kernel 3.2.2-030202-generic [OK]
Trying kernel 3.1.10-030110-generic [OK]
Trying kernel 3.0.18-030018-generic [OK]
Trying kernel 2.6.39-02063904-generic [OK]
Trying kernel 2.6.38-02063808-generic [OK]
Trying kernel 2.6.37-02063706-generic [OK]
Trying kernel 2.6.36-02063604-generic [OK]
Trying kernel 2.6.35-02063512-generic [OK]
Trying kernel 2.6.34-02063410-generic [OK]
Trying kernel 2.6.33-02063305-generic [OK]
Trying kernel 2.6.32-02063255-generic [OK]
Trying kernel 2.6.31-02063113-generic [OK]
Trying kernel 2.6.30-02063010-generic [OK]
Trying kernel 2.6.29-02062906-generic [OK]
Trying kernel 2.6.28-02062810-generic [OK]
Trying kernel 2.6.27-020627-generic [OK]
Trying kernel 2.6.26-020626-generic [OK]
Trying kernel 2.6.25-020625-generic [OK]
Trying kernel 2.6.24-020624-generic [OK]
[0] http://www.orbit-lab.org/kernel/compat-wireless-3-stable/v3.4/compat-wireless-3.4-rc3-1.tar.bz2
[1] http://www.orbit-lab.org/kernel/compat-wireless-3-stable/v3.4/ChangeLog-3.4-rc3
[2] http://www.orbit-lab.org/kernel/compat-wireless-3-stable/v3.4/ckmake-3.4-rc1-2.log.bz2
Luis
^ 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