* Re: [PATCH] netback: fix typo in comment
From: David Miller @ 2011-12-06 18:21 UTC (permalink / raw)
To: Ian.Campbell; +Cc: wei.liu2, xen-devel, netdev
In-Reply-To: <1323178854.23681.75.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 6 Dec 2011 13:40:54 +0000
> On Tue, 2011-12-06 at 12:04 +0000, Wei Liu wrote:
>> "variables a used" should be "variables are used".
>>
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Applied.
^ permalink raw reply
* Highly Important Read and Reply.
From: May Aphradee @ 2011-12-06 18:13 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 97 bytes --]
I hereby write you regarding some vital fund issue. Read the attached message and reply ASAP.
[-- Attachment #2: from may.rtf --]
[-- Type: application/octet-stream, Size: 2909 bytes --]
From the desk of the Director General
Association of South East Asian Nations (ASEAN)
Anti Fraud & Crimes Commission.
Hello,
In the fourteenth summit of the Association of South East Asian Nation which was held in the resort city of Pattaya Thailand , one of the issues raised in the summit was the effect of fraud and crimes on the citizenry of this great association and the world in general. There was an outcry with a lot of people having been swindled of their life earnings and are left to wallop in abject poverty as the effect of fraud and crimes rages in the society. To this, efforts has been made with the help of the regional branch of the United Nations (UN) and World Bank which both agreed to come to the aid of all victims. It was agreed by all the parties and a settlement committee was set up with its secretariat in the resort city of Pattaya as well. A huge amount of half a billion dollars (US$500,000,000.00) was earmarked for this project while they set out fishing out victims of this barbaric act. Since the inauguration of this committee frantic efforts has been made in contacting victims by way of announcements and other mass media and victims has been coming forward for claim, a large sum has been paid out irrespective of their countries and geo-political regions.
Recently your name has come up as a victim and we are happy to contact you. First you have to desist from contacting anybody and focus on regaining all you have lost, and here is a chance for this association helping you in recovering part of what you have lost, your names are in the quota for fourth quarterly payment for this year which resumes in the month of November and will last until the end of the year 2011 (we will e-mail you names of persons and their compensation amounts as approved by the association and the paying bank). You have been approved for a compensational amount of One Million Two Hundred And Fifty thousand dollars (US$1,250,000.00) in cash or ATM through our paying bank. All you have to do right now is to contact the undersigned person at the e-mail provided below.
Mr. Wanchai Pracha
Email. wanchaipracha@gmail.com
and furnish this office with the following data of yours immediately for cross checking as we intend finalizing this payment in a few days-time.
1. Your Full Name.
2.Your Address
3.Your direct Telephone number
NOTE: You are advice to stop further communication with anybody in other not to compound your problems as we are going to protect you and guide you on how you are going to receive your compensational fund while avoiding you getting into the hands of these fraudsters so we shall direct you on how to receive your compensation immediately.
We assure you of our unalloyed and most sincere cooperation.
Yours truly
Ms. May Aphradee
Secretary ASEAN Thailand
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: fix crash while ethtool -t
From: David Miller @ 2011-12-06 18:22 UTC (permalink / raw)
To: dmitry; +Cc: netdev, eilong
In-Reply-To: <1323173112-30577-1-git-send-email-dmitry@broadcom.com>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Tue, 6 Dec 2011 14:05:12 +0200
> commit 2df1a70aaf70e8dff11b89b938a5f317556ee640 "bnx2x: Support
> for byte queue limits" has introduced an asymmetry in usage of
> netdev_tx_completed_queue and netdev_tx_sent_queue. Missing
> call to netdev_tx_sent_queue causes the crash during ethtool -t.
>
> The patch adds the missing call.
>
>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ipv4: cleanups to use IS_ENABLED(CONFIG_FOO)
From: David Miller @ 2011-12-06 18:23 UTC (permalink / raw)
To: kinwin2008; +Cc: netdev, ronyjin
In-Reply-To: <1323174289-2289-1-git-send-email-kinwin2008@gmail.com>
From: Feng King <kinwin2008@gmail.com>
Date: Tue, 6 Dec 2011 20:24:49 +0800
> From: Feng Jin <ronyjin@tencent.com>
>
> use #if IS_ENABLED(CONFIG_FOO) defined in include/linux/kconfig.h
> instead of #if defined(CONFIG_FOO) || defined(CONFIG_FOO_MODULE).
>
> Signed-off-by: Feng Jin <ronyjin@tencent.com>
This patch does not apply to net-next properly.
^ permalink raw reply
* Re: [PATCH 1/11] inet_diag: Partly rename inet_ to sock_
From: Stephen Hemminger @ 2011-12-06 18:24 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: David Miller, Linux Netdev List
In-Reply-To: <4EDE575B.3010507@parallels.com>
On Tue, 06 Dec 2011 21:56:43 +0400
Pavel Emelyanov <xemul@parallels.com> wrote:
> diff --git a/include/linux/netlink.h b/include/linux/netlink.h
> index 8374d29..9827ebf 100644
> --- a/include/linux/netlink.h
> +++ b/include/linux/netlink.h
> @@ -8,7 +8,7 @@
> #define NETLINK_UNUSED 1 /* Unused number */
> #define NETLINK_USERSOCK 2 /* Reserved for user mode socket protocols */
> #define NETLINK_FIREWALL 3 /* Firewalling hook */
> -#define NETLINK_INET_DIAG 4 /* INET socket monitoring */
> +#define NETLINK_SOCK_DIAG 4 /* socket monitoring */
> #define NETLINK_NFLOG 5 /* netfilter/iptables ULOG */
> #define NETLINK_XFRM 6 /* ipsec */
> #define NETLINK_SELINUX 7 /* SELinux event notifications */
This is a header file that is stripped and exported by other
tools. You can add new entries but need to keep existing define's
to avoid breaking source compatibility.
^ permalink raw reply
* Re: [PATCH net-next 3/4] caif-shm: Bugfixes for caif_shmcore.c
From: David Miller @ 2011-12-06 18:27 UTC (permalink / raw)
To: sjur.brandeland; +Cc: netdev
In-Reply-To: <1323175740-1952-3-git-send-email-sjur.brandeland@stericsson.com>
From: Sjur Brændeland <sjur.brandeland@stericsson.com>
Date: Tue, 6 Dec 2011 13:48:59 +0100
> - don't call dev_kfree_skb() with irqs disabled,
> use dev_kfree_skb_any() instead.
You unconditionally will always have IRQs disabled here, therefore
use dev_kfree_skb_irq() and avoid a test.
^ permalink raw reply
* Re: pull request: wireless-next 2011-12-06
From: David Miller @ 2011-12-06 18:31 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20111206160234.GB30288@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 6 Dec 2011 11:02:34 -0500
> This round of updates is intended for 3.3. Highlights include ath5k
> updates, ath9k updates, brcm80211 updates (particularly for brcmfmac),
> some NFC logging cleanups, some mesh updates, and the "NoAck per tid"
> work from Simon Wunderlich. Also included is a pull of the wireless
> tree to resolve a merge conflict.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH net-next] caif-spi: Bugfix for dump upon device removal
From: David Miller @ 2011-12-06 18:34 UTC (permalink / raw)
To: sjur.brandeland; +Cc: netdev, erwan.bracq
In-Reply-To: <1323192305-10843-1-git-send-email-sjur.brandeland@stericsson.com>
From: Sjur Brændeland <sjur.brandeland@stericsson.com>
Date: Tue, 6 Dec 2011 18:25:05 +0100
> From: Erwan Bracq <erwan.bracq@stericsson.com>
>
> Fix dump upon device removal, by moving deinitialization from
> platform-device-remove to network-interface-uninit.
>
> Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
Applied, thanks.
^ permalink raw reply
* Re: Latency difference between fifo and pfifo_fast
From: Dave Taht @ 2011-12-06 18:39 UTC (permalink / raw)
To: Rick Jones; +Cc: John A. Sullivan III, Eric Dumazet, netdev
In-Reply-To: <4EDE5D09.1060404@hp.com>
On Tue, Dec 6, 2011 at 7:20 PM, Rick Jones <rick.jones2@hp.com> wrote:
> On 12/06/2011 12:51 AM, Eric Dumazet wrote:
>>
>> Le mardi 06 décembre 2011 à 03:39 -0500, John A. Sullivan III a écrit :
>>
>>>> ifconfig eth2 txqueuelen 0
>>>> tc qdisc add dev eth2 root pfifo
>>>> tc qdisc del dev eth2 root
>>>>
>>>>
>>>>
>>>>
>>> Really? I didn't know one could do that. Thanks. However, with no
>>> queue length, do I have a significant risk of dropping packets? To
>>> answer your other response's question, these are Intel quad port e1000
>>> cards. We are frequently pushing them to near line speed so
>>> 1,000,000,000 / 1534 / 8 = 81,486 pps - John
>>
>>
>> You can remove qdisc layer, since NIC itself has a TX ring queue
>>
>> (check exact value with ethtool -g ethX)
>>
>> # ethtool -g eth2
>> Ring parameters for eth2:
>> Pre-set maximums:
>> RX: 4078
>> RX Mini: 0
>> RX Jumbo: 0
>> TX: 4078
>> Current hardware settings:
>> RX: 254
>> RX Mini: 0
>> RX Jumbo: 0
>> TX: 4078 ---- HERE ----
>
>
> And while you are down at the NIC, if every microsecond is precious (no
> matter how close to epsilon compared to the latencies of spinning rust :)
> you might consider disabling interrupt coalescing via ethtool -C.
>
> rick jones
Ya know, me being me, and if latency is your real problem, I can't help
but think you'd do better by reducing those tx queues enormously,
applying QFQ and maybe something like RED on top, would balance
out the differences between flows and result in a net benefit.
I realize that you are struggling to achieve line rate in the first place...
but from where I sit (with asbestos suit on), it would be an interesting
experiment. (I have no data on how much cpu this stuff uses at these
sort of speeds)
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
^ permalink raw reply
* Re: [PATCH 1/11] inet_diag: Partly rename inet_ to sock_
From: David Miller @ 2011-12-06 18:42 UTC (permalink / raw)
To: shemminger; +Cc: xemul, netdev
In-Reply-To: <20111206102447.25cc60f4@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 6 Dec 2011 10:24:47 -0800
> On Tue, 06 Dec 2011 21:56:43 +0400
> Pavel Emelyanov <xemul@parallels.com> wrote:
>
>> diff --git a/include/linux/netlink.h b/include/linux/netlink.h
>> index 8374d29..9827ebf 100644
>> --- a/include/linux/netlink.h
>> +++ b/include/linux/netlink.h
>> @@ -8,7 +8,7 @@
>> #define NETLINK_UNUSED 1 /* Unused number */
>> #define NETLINK_USERSOCK 2 /* Reserved for user mode socket protocols */
>> #define NETLINK_FIREWALL 3 /* Firewalling hook */
>> -#define NETLINK_INET_DIAG 4 /* INET socket monitoring */
>> +#define NETLINK_SOCK_DIAG 4 /* socket monitoring */
>> #define NETLINK_NFLOG 5 /* netfilter/iptables ULOG */
>> #define NETLINK_XFRM 6 /* ipsec */
>> #define NETLINK_SELINUX 7 /* SELinux event notifications */
>
> This is a header file that is stripped and exported by other
> tools. You can add new entries but need to keep existing define's
> to avoid breaking source compatibility.
Indeed, NETLINK_INET_DIAG must be kept around forever because that's what userland
source code references.
I'll fix this up when applying Pavel's patches, by simply adding a new alias that
userland can start being coverted over to use.
^ permalink raw reply
* Re: v6: faster tree-based sysctl implementation
From: Benjamin LaHaise @ 2011-12-06 18:42 UTC (permalink / raw)
To: Damien Millescamps
Cc: netdev, Eric W . Biederman, linux-kernel, Octavian Purdila,
David S . Miller, Alexey Dobriyan
In-Reply-To: <4EDE470D.3070808@6wind.com>
On Tue, Dec 06, 2011 at 05:47:09PM +0100, Damien Millescamps wrote:
> A use-case for wanting to be able to create several interfaces is to
> have a "tunnel" server handling several dynamic point to point connections.
I can chime in that this is also an issue for edge routers terminating
lots of PPPoE, L2TP or even DHCP sessions. Interfaces numbering in the
thousands or tens of thousands are common for 1G or 10G worth of bandwidth
aggregation.
-ben
--
"Thought is the essence of where you are now."
^ permalink raw reply
* Re: Latency difference between fifo and pfifo_fast
From: John A. Sullivan III @ 2011-12-06 19:44 UTC (permalink / raw)
To: Dave Taht; +Cc: Eric Dumazet, netdev, Rick Jones
In-Reply-To: <CAA93jw4rRsp0t0g4E0YOB=_N-rvTXj9aY+2qfN5hGXvi6R0auw@mail.gmail.com>
----- Original Message -----
> From: "Dave Taht" <dave.taht@gmail.com>
> To: "Rick Jones" <rick.jones2@hp.com>
> Cc: "John A. Sullivan III" <jsullivan@opensourcedevel.com>, "Eric Dumazet" <eric.dumazet@gmail.com>,
> netdev@vger.kernel.org
> Sent: Tuesday, December 6, 2011 1:39:13 PM
> Subject: Re: Latency difference between fifo and pfifo_fast
>
> On Tue, Dec 6, 2011 at 7:20 PM, Rick Jones <rick.jones2@hp.com>
> wrote:
> > On 12/06/2011 12:51 AM, Eric Dumazet wrote:
> >>
> >> Le mardi 06 décembre 2011 à 03:39 -0500, John A. Sullivan III a
> >> écrit :
> >>
> >>>> ifconfig eth2 txqueuelen 0
> >>>> tc qdisc add dev eth2 root pfifo
> >>>> tc qdisc del dev eth2 root
> >>>>
> >>>>
> >>>>
> >>>>
> >>> Really? I didn't know one could do that. Thanks. However, with
> >>> no
> >>> queue length, do I have a significant risk of dropping packets?
> >>> To
> >>> answer your other response's question, these are Intel quad port
> >>> e1000
> >>> cards. We are frequently pushing them to near line speed so
> >>> 1,000,000,000 / 1534 / 8 = 81,486 pps - John
> >>
> >>
> >> You can remove qdisc layer, since NIC itself has a TX ring queue
> >>
> >> (check exact value with ethtool -g ethX)
> >>
> >> # ethtool -g eth2
> >> Ring parameters for eth2:
> >> Pre-set maximums:
> >> RX: 4078
> >> RX Mini: 0
> >> RX Jumbo: 0
> >> TX: 4078
> >> Current hardware settings:
> >> RX: 254
> >> RX Mini: 0
> >> RX Jumbo: 0
> >> TX: 4078 ---- HERE ----
> >
> >
> > And while you are down at the NIC, if every microsecond is precious
> > (no
> > matter how close to epsilon compared to the latencies of spinning
> > rust :)
> > you might consider disabling interrupt coalescing via ethtool -C.
> >
> > rick jones
>
> Ya know, me being me, and if latency is your real problem, I can't
> help
> but think you'd do better by reducing those tx queues enormously,
> applying QFQ and maybe something like RED on top, would balance
> out the differences between flows and result in a net benefit.
>
> I realize that you are struggling to achieve line rate in the first
> place...
>
> but from where I sit (with asbestos suit on), it would be an
> interesting
> experiment. (I have no data on how much cpu this stuff uses at these
> sort of speeds)
> <snip>
>
Interesting. Would that still be true if all the traffic is the same, i.e., nothing but iSCSI packets on the network? Or would just dumping packets with minimal processing be fastest? Thanks - John
^ permalink raw reply
* Re: [PATCH 0/11] Generalize the inet_diag infrastructure
From: David Miller @ 2011-12-06 18:58 UTC (permalink / raw)
To: xemul; +Cc: netdev
In-Reply-To: <4EDE573A.6040607@parallels.com>
From: Pavel Emelyanov <xemul@parallels.com>
Date: Tue, 06 Dec 2011 21:56:10 +0400
> This is an attempt to prepare the existing inet_diag infrastructure to work with
> arbitrary address family and protocol pair, not only AF_INET(6) and TCP/DCCP.
>
> This set adds the sock_diag infrastructure, that handles the new SOCK_DIAG_BY_FAMILY
> message type by the NETLINK_INET_DIAG socket. The core API struct for this (called
> sock_diag_req) contains two fields - family and type - which specify which sockets
> to dump. Additional information is considered to be family handler specific.
>
> The existing inet_diag code is patched to register himself inside the sock_diag and
> provide callbacks for dumping AF_INET/AF_INET6 IPPROTO_TCP/IPPROTO_DCCP sockets. The
> existing API facilities such as state filtering and bytecode is of course preserved
> and is treated by inet_diag specific data.
>
> Binary compatibility with existing NETLINK_INET_DIAG is also kept.
>
> No additional stuff in this set. The support for IPPROTO_UDP protocol and AF_UNIX
> family will come later if this set is approved.
>
> Applies to net-next, patch for iproute2's ss tool (proving that the new code ... pretends
> to work) is at the end of the thread.
>
> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Applied, with the retention of a NETLINK_INET_DIAG define in patch #1 for
userspace compatability.
^ permalink raw reply
* Re: [PATCHv2] net: Silence seq_scale() unused warning
From: David Miller @ 2011-12-06 19:00 UTC (permalink / raw)
To: sboyd; +Cc: linux-kernel, netdev
In-Reply-To: <1323194680-32127-1-git-send-email-sboyd@codeaurora.org>
From: Stephen Boyd <sboyd@codeaurora.org>
Date: Tue, 6 Dec 2011 10:04:40 -0800
> On a CONFIG_NET=y build
>
> net/core/secure_seq.c:22: warning: 'seq_scale' defined but not
> used
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Applied, thanks.
^ permalink raw reply
* Re: [RFC] socket sk_sndmsg_page waste
From: David Miller @ 2011-12-06 19:01 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1323188117.2448.24.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 06 Dec 2011 17:15:17 +0100
> Le mardi 06 décembre 2011 à 07:53 +0100, Eric Dumazet a écrit :
>> TCP can steer one page of memory per socket to cook outgoing frames.
>>
>> This means a machine handling long living sockets can consume a lot of
>> ram.
>>
>> 1.000.000 tcp sockets : up to 4GB of allocated memory, if some writes
>> had been done on these sockets.
>>
>> It would make sense to use a per thread page as a pool, instead of a per
>> socket pool, and remove sk_sndmsg_page/off fields.
>>
>> Problem with this strategy is impact outside of net tree, and a cost at
>> thread creation/destruction.
>>
>> [ But this could be used in fs/pipe.c or fs/splice.c code..., so that
>> small writes() dont allocate a full page but try to reuse the "per
>> task_struct" page ]
>>
>>
>
> Another idea would be to use a percpu variable, to get proper NUMA
> affinity as well, and no extra cost at thread create/delete time.
>
> Only 'problem' is we can sleep (pagefault) in
> skb_copy_to_page_nocache(), so special care must be taken (disabling
> preemption wont prevent another thread on same cpu can use the same
> page)
I think you're going to end up adding overhead to implement this properly,
first you'll make it per-thread but then you'll want a per-cpu array
per-thread to get NUMA affinities et al. right.
Also, keeping the page per-socket gives a certain piece of mind, that
leaking socket data from one connection to another accidently is that
much less likely.
^ permalink raw reply
* Re: [PATCH net-next 4/4 v3] bnx2x, cnic: support DRV_INFO upon FW request
From: Eric Dumazet @ 2011-12-06 19:45 UTC (permalink / raw)
To: David Miller; +Cc: mchan, netdev, barak, eilong
In-Reply-To: <20111206.130654.1235461360535098349.davem@davemloft.net>
Le mardi 06 décembre 2011 à 13:06 -0500, David Miller a écrit :
> From: "Michael Chan" <mchan@broadcom.com>
> Date: Tue, 6 Dec 2011 00:41:50 -0800
>
> > From: Barak Witkowski <barak@broadcom.com>
> >
> > Add support to send driver capabilities, settings and statistics to
> > management firmware.
> >
> > [ Redone using many local variables, removed many unnecessary inlines,
> > and put #defines at the left margin suggested by Joe Perches ]
> >
> > Signed-off-by: Barak Witkowski <barak@broadcom.com>
> > Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> > Signed-off-by: Eddie Wai <eddie.wai@broadcom.com>
> > Signed-off-by: Michael Chan <mchan@broadcom.com>
>
> Applied.
Build error here if :
# grep CNIC .config
# CONFIG_CNIC is not set
# CONFIG_QLCNIC is not set
CC [M] drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.o
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: In function
‘bnx2x_drv_info_fcoe_stat’:
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:2950:33: erreur:
‘struct bnx2x’ has no member named ‘fip_mac’
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: In function
‘bnx2x_drv_info_iscsi_stat’:
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3041:34: erreur:
‘struct bnx2x’ has no member named ‘cnic_eth_dev’
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2011-12-06 19:59 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) RTO_ONLINK state bit can be lost in routing cache entries, fix from
Julian Anastasov.
2) INET peer validation fix could result in an OOPS if the call fails,
but allowing this operation to fail in the first place is the real
issue. If we can't lookup the neighbour for the new gateway, simply
revert back to the old one. We'll end up with another ICMP redirect
but that's fine and better than failing and having to add ugly recovery
code all over the place.
3) FIFO overflow and packet processing race fixes in r8169 from
François Reomieu.
4) pasemi_mac build was broken accidently, fix from Ben Hutchings.
5) cfg80211 wireless race fixes from Luis R. Rodriguez.
6) Reconfiguring HT40 after assosciation in iwlwifi results in a firmware
abort, so don't do it. From Wey-Yi Guy.
Please pull, thanks a lot.
The following changes since commit 45e713efe2fa574b6662e7fb63fae9497c5e03d4:
Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2011-12-05 16:54:15 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
Ben Hutchings (1):
pasemi_mac: Fix building as module
David S. Miller (2):
ipv4: Fix peer validation on cached lookup.
Merge branch 'for-davem' of git://git.kernel.org/.../linville/wireless
Johannes Berg (1):
iwlagn: fix HW crypto for TX-only keys
John W. Linville (2):
Revert "mac80211: clear sta.drv_priv on reconfiguration"
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Julian Anastasov (1):
ipv4: make sure RTO_ONLINK is saved in routing cache
Luis R. Rodriguez (2):
cfg80211: fix race on init and driver registration
cfg80211: amend regulatory NULL dereference fix
Peter Pan(潘卫平) (1):
ipv4:correct description for tcp_max_syn_backlog
Simon Wunderlich (1):
mac80211: fill rate filter for internal scan requests
Stephen Boyd (1):
net: Silence seq_scale() unused warning
Wei Liu (1):
netback: Fix alert message.
Wey-Yi Guy (2):
iwlwifi: do not re-configure HT40 after associated
iwlwifi: change the default behavior of watchdog timer
françois romieu (2):
r8169: Rx FIFO overflow fixes.
r8169: fix Rx index race between FIFO overflow recovery and NAPI handler.
Documentation/networking/ip-sysctl.txt | 10 +++---
drivers/net/ethernet/pasemi/Makefile | 3 +-
drivers/net/ethernet/realtek/r8169.c | 53 ++++++++++-----------------
drivers/net/wireless/iwlwifi/iwl-1000.c | 1 +
drivers/net/wireless/iwlwifi/iwl-5000.c | 1 +
drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 36 ++++++++++++-------
drivers/net/wireless/iwlwifi/iwl-agn-sta.c | 5 ---
drivers/net/wireless/iwlwifi/iwl-agn.c | 34 +++++++++---------
drivers/net/wireless/iwlwifi/iwl-agn.h | 2 +
drivers/net/wireless/iwlwifi/iwl-core.c | 22 +++++++++---
drivers/net/wireless/iwlwifi/iwl-core.h | 2 +
drivers/net/wireless/iwlwifi/iwl-shared.h | 4 +-
drivers/net/xen-netback/netback.c | 2 +-
net/core/request_sock.c | 7 ++--
net/core/secure_seq.c | 2 +
net/ipv4/route.c | 47 ++++++++++--------------
net/mac80211/main.c | 6 +++
net/mac80211/util.c | 1 -
net/wireless/reg.c | 49 ++++++++++++++++---------
19 files changed, 155 insertions(+), 132 deletions(-)
^ permalink raw reply
* [PATCH net-next] remove an outdated reference to T/TCP
From: Rick Jones @ 2011-12-06 20:00 UTC (permalink / raw)
To: netdev
Remove a particularly out of date bit of comment referring to T/TCP.
Signed-off-by: Rick Jones <rick.jones2@hp.com>
---
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 0cbb440..123e1be 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5824,14 +5824,6 @@ int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb,
* we just ignore it, that fits the spec precisely
* and avoids incompatibilities. It would be nice in
* future to drop through and process the data.
- *
- * Now that TTCP is starting to be used we ought to
- * queue this data.
- * But, this leaves one open to an easy denial of
- * service attack, and SYN cookies can't defend
- * against this problem. So, we drop the data
- * in the interest of security over speed unless
- * it's still in use.
*/
kfree_skb(skb);
return 0;
^ permalink raw reply related
* Re: [PATCH net-next 4/4 v3] bnx2x, cnic: support DRV_INFO upon FW request
From: Michael Chan @ 2011-12-06 20:15 UTC (permalink / raw)
To: 'Eric Dumazet', 'David Miller'
Cc: 'netdev@vger.kernel.org', Barak Witkowski,
Eilon Greenstein
In-Reply-To: <1323200721.2690.22.camel@edumazet-laptop>
Eric Dumazet wrote:
> Build error here if :
>
> # grep CNIC .config
> # CONFIG_CNIC is not set
> # CONFIG_QLCNIC is not set
>
>
> CC [M] drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.o
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: In function
> ‘bnx2x_drv_info_fcoe_stat’:
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:2950:33: erreur:
> ‘struct bnx2x’ has no member named ‘fip_mac’
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: In function
> ‘bnx2x_drv_info_iscsi_stat’:
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3041:34: erreur:
> ‘struct bnx2x’ has no member named ‘cnic_eth_dev’
>
Thanks for reporting this. I'll send a patch to fix this shortly.
^ permalink raw reply
* Re: [PATCH net-next] remove an outdated reference to T/TCP
From: David Miller @ 2011-12-06 20:19 UTC (permalink / raw)
To: rick.jones2; +Cc: netdev
In-Reply-To: <20111206200005.836D529006DD@tardy>
From: Rick Jones <rick.jones2@hp.com>
Date: Tue, 6 Dec 2011 12:00:05 -0800 (PST)
>
> Remove a particularly out of date bit of comment referring to T/TCP.
>
> Signed-off-by: Rick Jones <rick.jones2@hp.com>
I think it should stay because it discusses the potential bad side
effects of queueing any data that might be in the SYN.
^ permalink raw reply
* Re: [PATCH] SUNRPC: create svc_xprt in proper network namespace
From: J. Bruce Fields @ 2011-12-06 20:48 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Trond.Myklebust, linux-nfs, xemul, neilb, netdev, linux-kernel,
jbottomley, davem, devel
In-Reply-To: <20111206101910.1878.21798.stgit@localhost6.localdomain6>
On Tue, Dec 06, 2011 at 02:19:10PM +0300, Stanislav Kinsbursky wrote:
> This patch makes svc_xprt inherit network namespace link from it's socket.
And poor rdma gets left out. OK. Applying for 3.3 (with changelog typo
fixed).
--b.
>
> Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
>
> ---
> include/linux/sunrpc/svc_xprt.h | 2 +-
> net/sunrpc/svc_xprt.c | 6 +++---
> net/sunrpc/svcsock.c | 8 +++++---
> net/sunrpc/xprtrdma/svc_rdma_transport.c | 2 +-
> 4 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/sunrpc/svc_xprt.h b/include/linux/sunrpc/svc_xprt.h
> index 8620f79..18df516 100644
> --- a/include/linux/sunrpc/svc_xprt.h
> +++ b/include/linux/sunrpc/svc_xprt.h
> @@ -109,7 +109,7 @@ static inline int register_xpt_user(struct svc_xprt *xpt, struct svc_xpt_user *u
>
> int svc_reg_xprt_class(struct svc_xprt_class *);
> void svc_unreg_xprt_class(struct svc_xprt_class *);
> -void svc_xprt_init(struct svc_xprt_class *, struct svc_xprt *,
> +void svc_xprt_init(struct net *, struct svc_xprt_class *, struct svc_xprt *,
> struct svc_serv *);
> int svc_create_xprt(struct svc_serv *, const char *, struct net *,
> const int, const unsigned short, int);
> diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
> index 447cd0e..f8f0627 100644
> --- a/net/sunrpc/svc_xprt.c
> +++ b/net/sunrpc/svc_xprt.c
> @@ -147,8 +147,8 @@ EXPORT_SYMBOL_GPL(svc_xprt_put);
> * Called by transport drivers to initialize the transport independent
> * portion of the transport instance.
> */
> -void svc_xprt_init(struct svc_xprt_class *xcl, struct svc_xprt *xprt,
> - struct svc_serv *serv)
> +void svc_xprt_init(struct net *net, struct svc_xprt_class *xcl,
> + struct svc_xprt *xprt, struct svc_serv *serv)
> {
> memset(xprt, 0, sizeof(*xprt));
> xprt->xpt_class = xcl;
> @@ -163,7 +163,7 @@ void svc_xprt_init(struct svc_xprt_class *xcl, struct svc_xprt *xprt,
> spin_lock_init(&xprt->xpt_lock);
> set_bit(XPT_BUSY, &xprt->xpt_flags);
> rpc_init_wait_queue(&xprt->xpt_bc_pending, "xpt_bc_pending");
> - xprt->xpt_net = get_net(&init_net);
> + xprt->xpt_net = get_net(net);
> }
> EXPORT_SYMBOL_GPL(svc_xprt_init);
>
> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> index 71bed1c..277909e 100644
> --- a/net/sunrpc/svcsock.c
> +++ b/net/sunrpc/svcsock.c
> @@ -739,7 +739,8 @@ static void svc_udp_init(struct svc_sock *svsk, struct svc_serv *serv)
> {
> int err, level, optname, one = 1;
>
> - svc_xprt_init(&svc_udp_class, &svsk->sk_xprt, serv);
> + svc_xprt_init(sock_net(svsk->sk_sock->sk), &svc_udp_class,
> + &svsk->sk_xprt, serv);
> clear_bit(XPT_CACHE_AUTH, &svsk->sk_xprt.xpt_flags);
> svsk->sk_sk->sk_data_ready = svc_udp_data_ready;
> svsk->sk_sk->sk_write_space = svc_write_space;
> @@ -1343,7 +1344,8 @@ static void svc_tcp_init(struct svc_sock *svsk, struct svc_serv *serv)
> {
> struct sock *sk = svsk->sk_sk;
>
> - svc_xprt_init(&svc_tcp_class, &svsk->sk_xprt, serv);
> + svc_xprt_init(sock_net(svsk->sk_sock->sk), &svc_tcp_class,
> + &svsk->sk_xprt, serv);
> set_bit(XPT_CACHE_AUTH, &svsk->sk_xprt.xpt_flags);
> if (sk->sk_state == TCP_LISTEN) {
> dprintk("setting up TCP socket for listening\n");
> @@ -1659,7 +1661,7 @@ static struct svc_xprt *svc_bc_create_socket(struct svc_serv *serv,
> return ERR_PTR(-ENOMEM);
>
> xprt = &svsk->sk_xprt;
> - svc_xprt_init(&svc_tcp_bc_class, xprt, serv);
> + svc_xprt_init(net, &svc_tcp_bc_class, xprt, serv);
>
> serv->sv_bc_xprt = xprt;
>
> diff --git a/net/sunrpc/xprtrdma/svc_rdma_transport.c b/net/sunrpc/xprtrdma/svc_rdma_transport.c
> index ba1296d..894cb42 100644
> --- a/net/sunrpc/xprtrdma/svc_rdma_transport.c
> +++ b/net/sunrpc/xprtrdma/svc_rdma_transport.c
> @@ -453,7 +453,7 @@ static struct svcxprt_rdma *rdma_create_xprt(struct svc_serv *serv,
>
> if (!cma_xprt)
> return NULL;
> - svc_xprt_init(&svc_rdma_class, &cma_xprt->sc_xprt, serv);
> + svc_xprt_init(&init_net, &svc_rdma_class, &cma_xprt->sc_xprt, serv);
> INIT_LIST_HEAD(&cma_xprt->sc_accept_q);
> INIT_LIST_HEAD(&cma_xprt->sc_dto_q);
> INIT_LIST_HEAD(&cma_xprt->sc_rq_dto_q);
>
^ permalink raw reply
* [PATCH net-next] bnx2x: Fix compile errors if CONFIG_CNIC is not set
From: Michael Chan @ 2011-12-06 20:58 UTC (permalink / raw)
To: davem; +Cc: netdev, barak, eilong, eric.dumazet
Don't provide FCoE and iSCSI statistics to management firmware if
CONFIG_CNIC is not set. Some needed structure fields are not defined
without CONFIG_CNIC.
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 86d36f8..418e7d3 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -2943,6 +2943,7 @@ static void bnx2x_drv_info_ether_stat(struct bnx2x *bp)
static void bnx2x_drv_info_fcoe_stat(struct bnx2x *bp)
{
+#ifdef BCM_CNIC
struct bnx2x_dcbx_app_params *app = &bp->dcbx_port_params.app;
struct fcoe_stats_info *fcoe_stat =
&bp->slowpath->drv_info_to_mcp.fcoe_stat;
@@ -3026,7 +3027,6 @@ static void bnx2x_drv_info_fcoe_stat(struct bnx2x *bp)
fcoe_q_xstorm_stats->mcast_pkts_sent);
}
-#ifdef BCM_CNIC
/* ask L5 driver to add data to the struct */
bnx2x_cnic_notify(bp, CNIC_CTL_FCOE_STATS_GET_CMD);
#endif
@@ -3034,6 +3034,7 @@ static void bnx2x_drv_info_fcoe_stat(struct bnx2x *bp)
static void bnx2x_drv_info_iscsi_stat(struct bnx2x *bp)
{
+#ifdef BCM_CNIC
struct bnx2x_dcbx_app_params *app = &bp->dcbx_port_params.app;
struct iscsi_stats_info *iscsi_stat =
&bp->slowpath->drv_info_to_mcp.iscsi_stat;
@@ -3043,7 +3044,6 @@ static void bnx2x_drv_info_iscsi_stat(struct bnx2x *bp)
iscsi_stat->qos_priority =
app->traffic_type_priority[LLFC_TRAFFIC_TYPE_ISCSI];
-#ifdef BCM_CNIC
/* ask L5 driver to add data to the struct */
bnx2x_cnic_notify(bp, CNIC_CTL_ISCSI_STATS_GET_CMD);
#endif
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next] bnx2x: Fix compile errors if CONFIG_CNIC is not set
From: Eric Dumazet @ 2011-12-06 21:03 UTC (permalink / raw)
To: Michael Chan; +Cc: davem, netdev, barak, eilong
In-Reply-To: <1323205088-29693-1-git-send-email-mchan@broadcom.com>
Le mardi 06 décembre 2011 à 12:58 -0800, Michael Chan a écrit :
> Don't provide FCoE and iSCSI statistics to management firmware if
> CONFIG_CNIC is not set. Some needed structure fields are not defined
> without CONFIG_CNIC.
>
> Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> ---
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
Thanks for the fast answer, and yes, no more build error :)
^ permalink raw reply
* Re: [PATCH net-next v2 2/4] can: cc770: add legacy ISA bus driver for the CC770 and AN82527
From: Wolfgang Zarre @ 2011-12-06 21:08 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Oliver Hartkopp, linux-can-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w
In-Reply-To: <4EDBC25D.50405-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Hello Wolfgang,
> Hi Wolfgang,
>
> On 12/04/2011 07:47 PM, Wolfgang Zarre wrote:
>> Hello Wolfgang,
> ...
>>> Wolfgang, I just sent out v4. Any chance to give this patch a try? It
>>> would be best to use a recent kernel version but I could also adapt the
>>> patch to your kernel version, 2.6.39, I think!?
>>
>> Sorry for my delayed reply, but wasn't earlier possible.
>> Yes, of course, as long as I have the hardware available I can do some
>> tests, even
>> on a recent kernel due the fact having the project so far completed,
>> just another
>> test run on the 9th of December.
>>
>> Due the flood of emails I lost now track which version You would be
>> interested in
>> and maybe also which kernel version, so, please let me know and maybe
>> were I may
>> download the patches.
>
> Well, yes, I was spinning too fast but the patches have been accepted in
> the meantime (actually v6 made it). So you just need to clone the most
> recent version of Dave's net-next tree.
>
>>> As you are using a CC770 chip, I'm especially interested in the relevant
>>> kernel log (dmesg) and "ip -d -s link show".
>>
>> Should be not a problem at all.
>
> Great, thanks.
Ok, here we go:
uname -r: 3.2.0-rc4
modprobe cc770_isa irq=0xa port=0x384 indirect=1 cir=0x61 bcr=0x4A
ip link set can0 up type can bitrate 500000;
kern.log
Dec 6 20:42:19 svserv01 kernel: [ 2111.900735] CAN device driver interface
Dec 6 20:42:19 svserv01 kernel: [ 2111.903072] cc770: CAN netdevice driver
Dec 6 20:42:19 svserv01 kernel: [ 2111.904692] cc770_isa: platform device 0: port=0x384, mem=0x0, irq=10
Dec 6 20:42:19 svserv01 kernel: [ 2111.904726] cc770_isa cc770_isa.0: probing idx=0: port=0x384, mem=0x0, irq=10
Dec 6 20:42:19 svserv01 kernel: [ 2111.904779] cc770_isa cc770_isa.0: (unregistered net_device): i82527 mode with additional functions
Dec 6 20:42:19 svserv01 kernel: [ 2111.906407] cc770_isa cc770_isa.0: device registered (reg_base=0x00000384, irq=10)
Dec 6 20:42:19 svserv01 kernel: [ 2111.906457] cc770_isa: driver for max. 8 devices registered
6 20:44:17 svserv01 kernel: [ 2229.886845] cc770_isa cc770_isa.0: can0: setting BTR0=0x00 BTR1=0x1c
Dec 6 20:44:17 svserv01 kernel: [ 2229.886920] cc770_isa cc770_isa.0: can0: Message object 15 for RX data, RTR, SFF and EFF
Dec 6 20:44:17 svserv01 kernel: [ 2229.886937] cc770_isa cc770_isa.0: can0: Message object 11 for TX data, RTR, SFF and EFF
Dec 6 20:52:40 svserv01 kernel: [ 2733.172845] can: controller area network core (rev 20090105 abi 8)
Dec 6 20:52:40 svserv01 kernel: [ 2733.172967] NET: Registered protocol family 29
Dec 6 20:52:40 svserv01 kernel: [ 2733.178187] can: raw protocol (rev 20090105)
ip -d -s link show
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
link/can
can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
bitrate 500000 sample-point 0.875
tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
cc770: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
clock 8000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 0 0 0
RX: bytes packets errors dropped overrun mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
After rebooting the PLC with proprietary buggy kernel:
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
link/can
can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
bitrate 500000 sample-point 0.875
tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
cc770: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
clock 8000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 0 0 0
RX: bytes packets errors dropped overrun mcast
414 267 0 267 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
After sending 100,000 PDO's with 13ms displacement:
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
link/can
can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
bitrate 500000 sample-point 0.875
tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
cc770: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
clock 8000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 0 0 0
RX: bytes packets errors dropped overrun mcast
4544 4284 0 331 0 0
TX: bytes packets errors dropped carrier collsns
802660 202653 0 0 0 0
The dropped ones of RX may be the not processed input packages and therefore ok.
Let me know if You need more or some other tests.
>
> Wolfgang.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: Fix compile errors if CONFIG_CNIC is not set
From: Joe Perches @ 2011-12-06 21:25 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Michael Chan, davem, netdev, barak, eilong
In-Reply-To: <1323205383.2690.25.camel@edumazet-laptop>
On Tue, 2011-12-06 at 22:03 +0100, Eric Dumazet wrote:
> Le mardi 06 décembre 2011 à 12:58 -0800, Michael Chan a écrit :
> > Don't provide FCoE and iSCSI statistics to management firmware if
> > CONFIG_CNIC is not set. Some needed structure fields are not defined
> > without CONFIG_CNIC.
> Thanks for the fast answer, and yes, no more build error :)
That works, but is that the best solution?
Another option is for bnx2x_handle_drv_info_req
to return DRV_MSG_CODE_DRV_INFO_NACK
Maybe like:
switch (op_code) {
case ETH_STATS_OPCODE:
bnx2x_drv_info_ether_stat(bp);
break;
#ifdef BCM_CNIC
case FCOE_STATS_OPCODE:
bnx2x_drv_info_fcoe_stat(bp);
break;
case ISCSI_STATS_OPCODE:
bnx2x_drv_info_iscsi_stat(bp);
break;
#endif
default:
/* if op code isn't supported - send NACK */
bnx2x_fw_command(bp, DRV_MSG_CODE_DRV_INFO_NACK, 0);
return;
}
^ 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