* [PATCH v8 net-next 1/2] bonding: display xmit_hash_policy for non-dynamic-tlb mode
From: Mahesh Bandewar @ 2014-10-05 0:44 UTC (permalink / raw)
To: Jay Vosburgh, Andy Gospodarek, Veaceslav Falico,
Nikolay Aleksandrov, David Miller
Cc: netdev, Mahesh Bandewar, Eric Dumazet, Maciej Zenczykowski
It's a trivial fix to display xmit_hash_policy for this new TLB mode
since it uses transmit-hash-poilicy as part of bonding-master info
(/proc/net/bonding/<bonding-interface).
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Reviewed-by: Nikolay Aleksandrov <nikolay@redhat.com>
---
v1
Rebase
v2
Added bond_mode_uses_xmit_hash() inline function
v3-v8
Rebase
drivers/net/bonding/bond_procfs.c | 3 +--
drivers/net/bonding/bonding.h | 7 +++++++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_procfs.c b/drivers/net/bonding/bond_procfs.c
index bb09d0442aa8..a3948f8d1e53 100644
--- a/drivers/net/bonding/bond_procfs.c
+++ b/drivers/net/bonding/bond_procfs.c
@@ -73,8 +73,7 @@ static void bond_info_show_master(struct seq_file *seq)
seq_printf(seq, "\n");
- if (BOND_MODE(bond) == BOND_MODE_XOR ||
- BOND_MODE(bond) == BOND_MODE_8023AD) {
+ if (bond_mode_uses_xmit_hash(bond)) {
optval = bond_opt_get_val(BOND_OPT_XMIT_HASH,
bond->params.xmit_policy);
seq_printf(seq, "Transmit Hash Policy: %s (%d)\n",
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 57917e63b4e6..5b022da9cad2 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -274,6 +274,13 @@ static inline bool bond_is_nondyn_tlb(const struct bonding *bond)
(bond->params.tlb_dynamic_lb == 0);
}
+static inline bool bond_mode_uses_xmit_hash(const struct bonding *bond)
+{
+ return (BOND_MODE(bond) == BOND_MODE_8023AD ||
+ BOND_MODE(bond) == BOND_MODE_XOR ||
+ bond_is_nondyn_tlb(bond));
+}
+
static inline bool bond_mode_uses_arp(int mode)
{
return mode != BOND_MODE_8023AD && mode != BOND_MODE_TLB &&
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* Re: [PATCH net-next v2 1/2] if_link: add client name to port profile
From: David Miller @ 2014-10-05 0:43 UTC (permalink / raw)
To: _govind; +Cc: netdev, ssujith, benve
In-Reply-To: <1412289683-8278-2-git-send-email-_govind@gmx.com>
From: Govindarajulu Varadarajan <_govind@gmx.com>
Date: Fri, 3 Oct 2014 04:11:22 +0530
> This patch adds client name to port profile.
>
> This is used by netlink client to send the client name in port profile.
>
> Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
I really want to see what other developers think of this thing
because it seems extremely ad-hoc to me.
^ permalink raw reply
* Re: macvlan: optimizing the receive path?
From: David Miller @ 2014-10-05 0:42 UTC (permalink / raw)
To: jbaron; +Cc: netdev, kaber
In-Reply-To: <542DB55D.3090601@akamai.com>
From: Jason Baron <jbaron@akamai.com>
Date: Thu, 02 Oct 2014 16:28:13 -0400
> --- a/drivers/net/macvlan.c
> +++ b/drivers/net/macvlan.c
> @@ -321,8 +321,8 @@ static rx_handler_result_t macvlan_handle_frame(struct sk_buff **pskb)
> skb->dev = dev;
> skb->pkt_type = PACKET_HOST;
>
> - ret = netif_rx(skb);
> -
> + macvlan_count_rx(vlan, len, true, 0);
> + return RX_HANDLER_ANOTHER;
> out:
> macvlan_count_rx(vlan, len, ret == NET_RX_SUCCESS, 0);
> return RX_HANDLER_CONSUMED;
That last argument to macvlan_count_rx() is a bool and thus should be
specified as "false". Yes I know other areas of this file get it
wrong too.
Also, what about GRO? Won't we get GRO processing if we do this via
netif_rx() but not via the RX_HANDLER_ANOTHER route? Just curious...
^ permalink raw reply
* Re: [PATCH net-next] Removed unused inet6 address state
From: David Miller @ 2014-10-05 0:37 UTC (permalink / raw)
To: sebastien.barre; +Cc: netdev, christoph.paasch, herbert
In-Reply-To: <1412277322-27823-1-git-send-email-sebastien.barre@uclouvain.be>
From: Sébastien Barré <sebastien.barre@uclouvain.be>
Date: Thu, 2 Oct 2014 21:15:22 +0200
> the inet6 state INET6_IFADDR_STATE_UP only appeared in its definition.
>
> Cc: Christoph Paasch <christoph.paasch@uclouvain.be>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Sébastien Barré <sebastien.barre@uclouvain.be>
Looks good, applied.
^ permalink raw reply
* Re: [PATCH V2 net-next] net: Cleanup skb cloning by adding SKB_FCLONE_FREE
From: David Miller @ 2014-10-05 0:34 UTC (permalink / raw)
To: subramanian.vijay; +Cc: netdev, edumazet
In-Reply-To: <1412269243-5583-1-git-send-email-subramanian.vijay@gmail.com>
From: Vijay Subramanian <subramanian.vijay@gmail.com>
Date: Thu, 2 Oct 2014 10:00:43 -0700
> SKB_FCLONE_UNAVAILABLE has overloaded meaning depending on type of skb.
> 1: If skb is allocated from head_cache, it indicates fclone is not available.
> 2: If skb is a companion fclone skb (allocated from fclone_cache), it indicates
> it is available to be used.
>
> To avoid confusion for case 2 above, this patch replaces
> SKB_FCLONE_UNAVAILABLE with SKB_FCLONE_FREE where appropriate. For fclone
> companion skbs, this indicates it is free for use.
>
> SKB_FCLONE_UNAVAILABLE will now simply indicate skb is from head_cache and
> cannot / will not have a companion fclone.
>
> Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
> ---
> V1-->V2: Comment all states
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] net: systemport: fix bcm_sysport_insert_tsb()
From: David Miller @ 2014-10-05 0:33 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev
In-Reply-To: <1412268196-16086-1-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 2 Oct 2014 09:43:16 -0700
> Similar to commit bc23333ba11fb7f959b7e87e121122f5a0fbbca8 ("net:
> bcmgenet: fix bcmgenet_put_tx_csum()"), we need to return the skb
> pointer in case we had to reallocate the SKB headroom.
>
> Fixes: 80105befdb4b8 ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied and queued up for -stable, thanks Florian.
^ permalink raw reply
* Re: [PATCH net-next] net: better IFF_XMIT_DST_RELEASE support
From: David Miller @ 2014-10-05 0:29 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1412267647.22242.3.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 02 Oct 2014 09:34:07 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Testing xmit_more support with netperf and connected UDP sockets,
> I found strange dst refcount false sharing.
>
> Current handling of IFF_XMIT_DST_RELEASE is not optimal.
>
> dropping dst in validate_xmit_skb() is certainly too late in case
> packet was queued by cpu X but dequeued by cpu Y
>
> The logical point to take care of drop/force is in __dev_queue_xmit()
> before even taking qdisc lock.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
I assume you are going to rework this to use a counter indication
in order to deal with the packet scheduler issues Julian brought
up.
^ permalink raw reply
* Re: [PATCH v7 net-next 2/2] bonding: Simplify the xmit function for modes that use xmit_hash
From: Mahesh Bandewar @ 2014-10-05 0:22 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, David Miller,
netdev, Eric Dumazet, Maciej Zenczykowski, Cong Wang
In-Reply-To: <542FA3C1.9080405@redhat.com>
On Sat, Oct 4, 2014 at 1:07 PM, Nikolay Aleksandrov <nikolay@redhat.com> wrote:
> On 10/04/2014 02:48 AM, Mahesh Bandewar wrote:
>> Earlier change to use usable slave array for TLB mode had an additional
>> performance advantage. So extending the same logic to all other modes
>> that use xmit-hash for slave selection (viz 802.3AD, and XOR modes).
>> Also consolidating this with the earlier TLB change.
>>
>> The main idea is to build the usable slaves array in the control path
>> and use that array for slave selection during xmit operation.
>>
>> Measured performance in a setup with a bond of 4x1G NICs with 200
>> instances of netperf for the modes involved (3ad, xor, tlb)
>> cmd: netperf -t TCP_RR -H <TargetHost> -l 60 -s 5
>>
>> Mode TPS-Before TPS-After
>>
>> 802.3ad : 468,694 493,101
>> TLB (lb=0): 392,583 392,965
>> XOR : 475,696 484,517
>>
>> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
>> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
>> ---
>> v1:
>> (a) If bond_update_slave_arr() fails to allocate memory, it will overwrite
>> the slave that need to be removed.
>> (b) Freeing of array will assign NULL (to handle bond->down to bond->up
>> transition gracefully.
>> (c) Change from pr_debug() to pr_err() if bond_update_slave_arr() returns
>> failure.
>> (d) XOR: bond_update_slave_arr() will consider mii-mon, arp-mon cases and
>> will populate the array even if these parameters are not used.
>> (e) 3AD: Should handle the ad_agg_selection_logic correctly.
>> v2:
>> (a) Removed rcu_read_{un}lock() calls from array manipulation code.
>> (b) Slave link-events now refresh array for all these modes.
>> (c) Moved free-array call from bond_close() to bond_uninit().
>> v3:
>> (a) Fixed null pointer dereference.
>> (b) Removed bond->lock lockdep dependency.
>> v4:
>> (a) Made to changes to comply with Nikolay's locking changes
>> (b) Added a work-queue to refresh slave-array when RTNL is not held
>> (c) Array refresh happens ONLY with RTNL now.
>> (d) alloc changed from GFP_ATOMIC to GFP_KERNEL
>> v5:
>> (a) Consolidated all delayed slave-array updates at one place in
>> 3ad_state_machine_handler()
>> v6:
>> (a) Free slave array when there is no active aggregator
>> v7:
>> (a) Couple of trivial changes.
>>
>> drivers/net/bonding/bond_3ad.c | 140 +++++++++++------------------
>> drivers/net/bonding/bond_alb.c | 51 ++---------
>> drivers/net/bonding/bond_alb.h | 8 --
>> drivers/net/bonding/bond_main.c | 192 +++++++++++++++++++++++++++++++++++++---
>> drivers/net/bonding/bonding.h | 10 +++
>> 5 files changed, 249 insertions(+), 152 deletions(-)
>>
> <<<snip>>>
>> +/* Build the usable slaves array in control path for modes that use xmit-hash
>> + * to determine the slave interface -
>> + * (a) BOND_MODE_8023AD
>> + * (b) BOND_MODE_XOR
>> + * (c) BOND_MODE_TLB && tlb_dynamic_lb == 0
>> + *
>> + * The caller is expected to hold RTNL only and NO other lock!
>> + */
>> +int bond_update_slave_arr(struct bonding *bond, struct slave *skipslave)
>> +{
>> + struct slave *slave;
>> + struct list_head *iter;
>> + struct bond_up_slave *new_arr, *old_arr;
>> + int slaves_in_agg;
>> + int agg_id = 0;
>> + int ret = 0;
>> +
>> +#ifdef CONFIG_LOCKDEP
>> + lockdep_assert_held(&bond->mode_lock);
>> +#endif
> ^^^^^^^^^
> This is wrong now, the logic is inverted.
> It will WARN every time mode_lock is _not_ held:
>
> #define lockdep_assert_held(l) do { \
> WARN_ON(debug_locks && !lockdep_is_held(l)); \
> } while (0)
>
> The previous version was correct which did a WARN when mode_lock was
> actually held as that is the wrong condition, not when it's not held.
> I've missed that comment earlier.
>
Thanks Nik, I missed that. I'll revert it!
> (also switched Veaceslav's email address with the correct one in the CC list)
>
>> +
>> + new_arr = kzalloc(offsetof(struct bond_up_slave, arr[bond->slave_cnt]),
>> + GFP_KERNEL);
>> + if (!new_arr) {
>> + ret = -ENOMEM;
>> + pr_err("Failed to build slave-array.\n");
>> + goto out;
>> + }
>> + if (BOND_MODE(bond) == BOND_MODE_8023AD) {
>> + struct ad_info ad_info;
>> +
>> + if (bond_3ad_get_active_agg_info(bond, &ad_info)) {
>> + pr_debug("bond_3ad_get_active_agg_info failed\n");
>> + kfree_rcu(new_arr, rcu);
>> + /* No active aggragator means it's not safe to use
>> + * the previous array.
>> + */
>> + old_arr = rtnl_dereference(bond->slave_arr);
>> + if (old_arr) {
>> + RCU_INIT_POINTER(bond->slave_arr, NULL);
>> + kfree_rcu(old_arr, rcu);
>> + }
>> + goto out;
>> + }
>> + slaves_in_agg = ad_info.ports;
>> + agg_id = ad_info.aggregator_id;
>> + }
>> + bond_for_each_slave(bond, slave, iter) {
>> + if (BOND_MODE(bond) == BOND_MODE_8023AD) {
>> + struct aggregator *agg;
>> +
>> + agg = SLAVE_AD_INFO(slave)->port.aggregator;
>> + if (!agg || agg->aggregator_identifier != agg_id)
>> + continue;
>> + }
>> + if (!bond_slave_can_tx(slave))
>> + continue;
>> + if (skipslave == slave)
>> + continue;
>> + new_arr->arr[new_arr->count++] = slave;
>> + }
>> +
>> + old_arr = rtnl_dereference(bond->slave_arr);
>> + rcu_assign_pointer(bond->slave_arr, new_arr);
>> + if (old_arr)
>> + kfree_rcu(old_arr, rcu);
>> +out:
>> + if (ret != 0 && skipslave) {
>> + int idx;
>> +
>> + /* Rare situation where caller has asked to skip a specific
>> + * slave but allocation failed (most likely!). BTW this is
>> + * only possible when the call is initiated from
>> + * __bond_release_one(). In this situation; overwrite the
>> + * skipslave entry in the array with the last entry from the
>> + * array to avoid a situation where the xmit path may choose
>> + * this to-be-skipped slave to send a packet out.
>> + */
>> + old_arr = rtnl_dereference(bond->slave_arr);
>> + for (idx = 0; idx < old_arr->count; idx++) {
>> + if (skipslave == old_arr->arr[idx]) {
>> + old_arr->arr[idx] =
>> + old_arr->arr[old_arr->count-1];
>> + old_arr->count--;
>> + break;
>> + }
>> + }
>> + }
>> + return ret;
>> +}
>> +
> <<<snip>>>
>
^ permalink raw reply
* Re: [PATCH net] ip6_gre: fix flowi6_proto value in xmit path
From: David Miller @ 2014-10-05 0:09 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <1412267209-893-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 2 Oct 2014 18:26:49 +0200
> In xmit path, we build a flowi6 which will be used for the output route lookup.
> We are sending a GRE packet, neither IPv4 nor IPv6 encapsulated packet, thus the
> protocol should be IPPROTO_GRE.
>
> Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
> Reported-by: Matthieu Ternisien d'Ouville <matthieu.tdo@6wind.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] mlx4: add a new xmit_more counter
From: David Miller @ 2014-10-05 0:04 UTC (permalink / raw)
To: eric.dumazet
Cc: amirv, brouer, therbert, netdev, hannes, fw, dborkman, jhs,
alexander.duyck, john.r.fastabend, dave.taht, toke
In-Reply-To: <1412263461.16704.107.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 02 Oct 2014 08:24:21 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> ethtool -S reports a new counter, tracking number of time doorbell
> was not triggered, because skb->xmit_more was set.
>
> $ ethtool -S eth0 | egrep "tx_packet|xmit_more"
> tx_packets: 2413288400
> xmit_more: 666121277
>
> I merged the tso_packet false sharing avoidance in this patch as well.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: adjust fixed_phy_register() return value
From: David Miller @ 2014-10-05 0:02 UTC (permalink / raw)
To: thomas.petazzoni; +Cc: pgynther, netdev, f.fainelli
In-Reply-To: <20141004140731.15c18a77@free-electrons.com>
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Sat, 4 Oct 2014 14:07:31 +0200
> I am not sure this return (!phy || IS_ERR(phy)) is doing the right
> thing. This function is supposed to return an error code on failure, or
> 0 on success. I don't see how your error handling returns an error code
> on failure. What about doing the more explicit:
>
> phy = fixed_phy_register(PHY_POLL, &status, np);
> if (IS_ERR(phy))
> return PTR_ERR(phy);
> else
> return 0;
>
> Or am I missing something?
Agreed, there is no circumstance under which the new fixed_phy_register()
should return a NULL pointer.
^ permalink raw reply
* Re: bridge: Do not compile options in br_parse_ip_options
From: Florian Westphal @ 2014-10-04 18:06 UTC (permalink / raw)
To: Herbert Xu
Cc: Florian Westphal, netfilter-devel, bsd, stephen, netdev,
eric.dumazet, davidn, David S. Miller
In-Reply-To: <20141004141802.GA10878@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Sat, Oct 04, 2014 at 09:55:08PM +0800, Herbert Xu wrote:
> >
> > I'll try to create a patch that essentially reverts the patch
> > that led us here.
>
> Here is a patch that's only compile-tested:
>
> bridge: Do not compile options in br_parse_ip_options
>
> Commit 462fb2af9788a82a534f8184abfde31574e1cfa0
>
> bridge : Sanitize skb before it enters the IP stack
>
> broke when IP options are actually used because it mangles the
> skb as if it entered the IP stack which is wrong because the
> bridge is supposed to operate below the IP stack.
>
> Since nobody has actually requested for parsing of IP options
> this patch fixes it by simply reverting to the previous approach
> of ignoring all IP options, i.e., zeroing the IPCB.
Fair enough. We lose frag_max_size information from ipv4 defrag,
plus netfilter hooks are called without validating ip options.
The former has not worked ever with bridge, and the latter
evidentily isn't a problem either since this has not worked at all
for three years...
So I am fine with it, provided we rename br_parse_ip_options() --
thats not what it does after this patch (br_validate_iphdr(), for
example?)
> If and when somebody who uses IP options and actually needs them
> to be parsed by the bridge complains then we can revisit this.
Ok, fair enough.
Thanks Herbert.
^ permalink raw reply
* Fw: [Bug 85571] New: wakeup from hibernate does not bring up networking (hard freeze, soft lockups and unusable system)
From: Stephen Hemminger @ 2014-10-04 17:32 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Begin forwarded message:
Date: Fri, 3 Oct 2014 21:22:46 -0700
From: "bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org" <bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org>
To: "stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org" <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
Subject: [Bug 85571] New: wakeup from hibernate does not bring up networking (hard freeze, soft lockups and unusable system)
https://bugzilla.kernel.org/show_bug.cgi?id=85571
Bug ID: 85571
Summary: wakeup from hibernate does not bring up networking
(hard freeze, soft lockups and unusable system)
Product: Networking
Version: 2.5
Kernel Version: 3.16.3-200.fc20.x86_64
Hardware: Intel
OS: Linux
Tree: Fedora
Status: NEW
Severity: blocking
Priority: P1
Component: Other
Assignee: shemminger-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org
Reporter: itsme_410-/E1597aS9LQAvxtiuMwx3w@public.gmane.org
Regression: No
The subject line is pretty explanatory. On my Dell Precision M3800, my system
does not wake up from hibernate correctly. (I have no issues with either a Dell
Latitude E6400 or a Dell XPS 13). The latop is unusable and needs a hard
reboot. Here are my hardware details. I also occassionally get the message:
BUG: soft lockup - CPU#0 stuck for 22s! and so on all the way till CPU#1
And I also get the following messages from systemd:
kernel:[43026.180173] do_IRQ: 0.81 No irq handler for vector (irq -1)
kernel:do_IRQ: 0.81 No irq handler for vector (irq -1)
Here is the output from cat /proc/cpuinfo, lsmod, lsb, lspci, etc:
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i7-4702HQ CPU @ 2.20GHz
stepping : 3
microcode : 0x1a
cpu MHz : 2196.132
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2
ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt
pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1
avx2 smep bmi2 erms invpcid
bogomips : 4389.99
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i7-4702HQ CPU @ 2.20GHz
stepping : 3
microcode : 0x1a
cpu MHz : 1900.335
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 1
cpu cores : 4
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2
ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt
pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1
avx2 smep bmi2 erms invpcid
bogomips : 4389.99
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i7-4702HQ CPU @ 2.20GHz
stepping : 3
microcode : 0x1a
cpu MHz : 2039.382
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 2
cpu cores : 4
apicid : 4
initial apicid : 4
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2
ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt
pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1
avx2 smep bmi2 erms invpcid
bogomips : 4389.99
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i7-4702HQ CPU @ 2.20GHz
stepping : 3
microcode : 0x1a
cpu MHz : 2199.312
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 3
cpu cores : 4
apicid : 6
initial apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2
ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt
pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1
avx2 smep bmi2 erms invpcid
bogomips : 4389.99
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 4
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i7-4702HQ CPU @ 2.20GHz
stepping : 3
microcode : 0x1a
cpu MHz : 1176.656
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2
ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt
pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1
avx2 smep bmi2 erms invpcid
bogomips : 4389.99
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 5
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i7-4702HQ CPU @ 2.20GHz
stepping : 3
microcode : 0x1a
cpu MHz : 1218.250
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 1
cpu cores : 4
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2
ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt
pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1
avx2 smep bmi2 erms invpcid
bogomips : 4389.99
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 6
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i7-4702HQ CPU @ 2.20GHz
stepping : 3
microcode : 0x1a
cpu MHz : 2200.000
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 2
cpu cores : 4
apicid : 5
initial apicid : 5
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2
ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt
pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1
avx2 smep bmi2 erms invpcid
bogomips : 4389.99
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i7-4702HQ CPU @ 2.20GHz
stepping : 3
microcode : 0x1a
cpu MHz : 1901.453
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 3
cpu cores : 4
apicid : 7
initial apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2
ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt
pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1
avx2 smep bmi2 erms invpcid
bogomips : 4389.99
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
$ lsmod
Module Size Used by
ccm 17773 1
tun 27153 3
ip6t_rpfilter 12546 1
ip6t_REJECT 12939 2
xt_conntrack 12760 9
bnep 19624 2
ebtable_nat 12807 0
ebtable_broute 12731 0
bridge 116006 1 ebtable_broute
stp 12868 1 bridge
llc 13941 2 stp,bridge
ebtable_filter 12827 0
ebtables 30758 3 ebtable_broute,ebtable_nat,ebtable_filter
ip6table_nat 12974 1
nf_conntrack_ipv6 18738 6
nf_defrag_ipv6 34712 1 nf_conntrack_ipv6
nf_nat_ipv6 13213 1 ip6table_nat
ip6table_mangle 12700 1
ip6table_security 12710 1
ip6table_raw 12683 1
ip6table_filter 12815 1
ip6_tables 26809 5
ip6table_filter,ip6table_mangle,ip6table_security,ip6table_nat,ip6table_raw
iptable_nat 12970 1
nf_conntrack_ipv4 14656 5
nf_defrag_ipv4 12702 1 nf_conntrack_ipv4
nf_nat_ipv4 13199 1 iptable_nat
nf_nat 25178 4
nf_nat_ipv4,nf_nat_ipv6,ip6table_nat,iptable_nat
nf_conntrack 99420 8
nf_nat,nf_nat_ipv4,nf_nat_ipv6,xt_conntrack,ip6table_nat,iptable_nat,nf_conntrack_ipv4,nf_conntrack_ipv6
iptable_mangle 12695 1
iptable_security 12705 1
iptable_raw 12678 1
arc4 12608 2
x86_pkg_temp_thermal 14205 0
coretemp 13441 0
kvm_intel 147547 0
kvm 452677 1 kvm_intel
crct10dif_pclmul 14307 0
crc32_pclmul 13133 0
iwlmvm 222115 0
crc32c_intel 22094 0
ghash_clmulni_intel 13230 0
mac80211 623787 1 iwlmvm
pn544_mei 12802 0
mei_phy 13574 1 pn544_mei
pn544 18073 1 pn544_mei
hci 43298 2 pn544,mei_phy
rtsx_pci_sdmmc 22998 0
snd_hda_codec_realtek 72791 1
mmc_core 121087 1 rtsx_pci_sdmmc
nfc 98285 2 hci,pn544
snd_hda_codec_generic 67662 1 snd_hda_codec_realtek
snd_hda_codec_hdmi 47489 1
rtsx_pci_ms 18168 0
iTCO_wdt 13480 0
memstick 16199 1 rtsx_pci_ms
iTCO_vendor_support 13419 1 iTCO_wdt
snd_hda_intel 30379 7
dell_wmi 12681 0
sparse_keymap 13584 1 dell_wmi
dell_laptop 18168 0
snd_hda_controller 30139 1 snd_hda_intel
uvcvideo 81022 0
dcdbas 14875 1 dell_laptop
videobuf2_vmalloc 13163 1 uvcvideo
snd_hda_codec 131298 5
snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller
videobuf2_memops 13161 1 videobuf2_vmalloc
videobuf2_core 57175 1 uvcvideo
v4l2_common 14542 1 videobuf2_core
snd_hwdep 17650 1 snd_hda_codec
joydev 17344 0
iwlwifi 125702 1 iwlmvm
snd_seq 62266 0
videodev 147660 3 uvcvideo,v4l2_common,videobuf2_core
snd_seq_device 14136 1 snd_seq
btusb 32448 0
cfg80211 500115 3 iwlwifi,mac80211,iwlmvm
lpc_ich 21093 0
microcode 44710 0
serio_raw 13434 0
snd_pcm 104333 4
snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_controller
i2c_i801 18146 0
rtsx_pci 44989 2 rtsx_pci_ms,rtsx_pci_sdmmc
mei_me 19568 0
mfd_core 13182 2 lpc_ich,rtsx_pci
bluetooth 433970 21 bnep,btusb
mei 86597 3 pn544_mei,mei_phy,mei_me
hid_multitouch 17419 0
rfkill 21979 6 nfc,cfg80211,bluetooth,dell_laptop
snd_timer 28778 2 snd_pcm,snd_seq
media 20846 2 uvcvideo,videodev
snd 75905 24
snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device
soundcore 14491 2 snd,snd_hda_codec
shpchp 37047 0
nfsd 283833 1
auth_rpcgss 58761 1 nfsd
nfs_acl 12741 1 nfsd
int3403_thermal 12967 0
lockd 93436 1 nfsd
sunrpc 279214 5 nfsd,auth_rpcgss,lockd,nfs_acl
dell_smo8800 13154 0
nouveau 1222531 1
i915 904304 5
ttm 80772 1 nouveau
i2c_algo_bit 13257 2 i915,nouveau
drm_kms_helper 58041 2 i915,nouveau
drm 291361 7 ttm,i915,drm_kms_helper,nouveau
i2c_core 55486 8
drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit,v4l2_common,nouveau,videodev
mxm_wmi 12865 1 nouveau
video 19777 2 i915,nouveau
wmi 18820 3 dell_wmi,mxm_wmi,nouveau
$ lspci
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor
DRAM Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor
PCI Express x16 Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor
Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor
HD Audio Controller (rev 06)
00:04.0 Signal processing controller: Intel Corporation Device 0c03 (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family
USB xHCI (rev 05)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series
Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family
USB EHCI #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High
Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI
Express Root Port #1 (rev d5)
00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI
Express Root Port #3 (rev d5)
00:1c.3 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI
Express Root Port #4 (rev d5)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family
USB EHCI #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation HM87 Express LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family
6-port SATA Controller 1 [AHCI mode] (rev 05)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus
Controller (rev 05)
00:1f.6 Signal processing controller: Intel Corporation 8 Series Chipset Family
Thermal Management Controller (rev 05)
Please let me know if more information is needed and what I can provide!
--
You are receiving this mail because:
You are the assignee for the bug.
--
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
* [PATCH net-next] net: sched: avoid costly atomic operation in fq_dequeue()
From: Eric Dumazet @ 2014-10-04 17:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
Standard qdisc API to setup a timer implies an atomic operation on every
packet dequeue : qdisc_unthrottled()
It turns out this is not really needed for FQ, as FQ has no concept of
global qdisc throttling, being a qdisc handling many different flows,
some of them can be throttled, while others are not.
Fix is straightforward : add a 'bool throttle' to
qdisc_watchdog_schedule_ns(), and remove calls to qdisc_unthrottled()
in sch_fq.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/pkt_sched.h | 4 ++--
net/sched/sch_api.c | 5 +++--
net/sched/sch_fq.c | 6 ++----
net/sched/sch_tbf.c | 3 ++-
4 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/net/pkt_sched.h b/include/net/pkt_sched.h
index e4b3c828c1c2..27a33833ff4a 100644
--- a/include/net/pkt_sched.h
+++ b/include/net/pkt_sched.h
@@ -65,12 +65,12 @@ struct qdisc_watchdog {
};
void qdisc_watchdog_init(struct qdisc_watchdog *wd, struct Qdisc *qdisc);
-void qdisc_watchdog_schedule_ns(struct qdisc_watchdog *wd, u64 expires);
+void qdisc_watchdog_schedule_ns(struct qdisc_watchdog *wd, u64 expires, bool throttle);
static inline void qdisc_watchdog_schedule(struct qdisc_watchdog *wd,
psched_time_t expires)
{
- qdisc_watchdog_schedule_ns(wd, PSCHED_TICKS2NS(expires));
+ qdisc_watchdog_schedule_ns(wd, PSCHED_TICKS2NS(expires), true);
}
void qdisc_watchdog_cancel(struct qdisc_watchdog *wd);
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index aa8329508dba..ab70e7dddb04 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -592,13 +592,14 @@ void qdisc_watchdog_init(struct qdisc_watchdog *wd, struct Qdisc *qdisc)
}
EXPORT_SYMBOL(qdisc_watchdog_init);
-void qdisc_watchdog_schedule_ns(struct qdisc_watchdog *wd, u64 expires)
+void qdisc_watchdog_schedule_ns(struct qdisc_watchdog *wd, u64 expires, bool throttle)
{
if (test_bit(__QDISC_STATE_DEACTIVATED,
&qdisc_root_sleeping(wd->qdisc)->state))
return;
- qdisc_throttled(wd->qdisc);
+ if (throttle)
+ qdisc_throttled(wd->qdisc);
hrtimer_start(&wd->timer,
ns_to_ktime(expires),
diff --git a/net/sched/sch_fq.c b/net/sched/sch_fq.c
index c9b9fcb53206..cbd7e1fd23b4 100644
--- a/net/sched/sch_fq.c
+++ b/net/sched/sch_fq.c
@@ -377,7 +377,6 @@ static int fq_enqueue(struct sk_buff *skb, struct Qdisc *sch)
if (time_after(jiffies, f->age + q->flow_refill_delay))
f->credit = max_t(u32, f->credit, q->quantum);
q->inactive_flows--;
- qdisc_unthrottled(sch);
}
/* Note: this overwrites f->age */
@@ -385,7 +384,6 @@ static int fq_enqueue(struct sk_buff *skb, struct Qdisc *sch)
if (unlikely(f == &q->internal)) {
q->stat_internal_packets++;
- qdisc_unthrottled(sch);
}
sch->q.qlen++;
@@ -433,7 +431,8 @@ begin:
if (!head->first) {
if (q->time_next_delayed_flow != ~0ULL)
qdisc_watchdog_schedule_ns(&q->watchdog,
- q->time_next_delayed_flow);
+ q->time_next_delayed_flow,
+ false);
return NULL;
}
}
@@ -495,7 +494,6 @@ begin:
}
out:
qdisc_bstats_update(sch, skb);
- qdisc_unthrottled(sch);
return skb;
}
diff --git a/net/sched/sch_tbf.c b/net/sched/sch_tbf.c
index 77edffe329c4..a4afde14e865 100644
--- a/net/sched/sch_tbf.c
+++ b/net/sched/sch_tbf.c
@@ -268,7 +268,8 @@ static struct sk_buff *tbf_dequeue(struct Qdisc *sch)
}
qdisc_watchdog_schedule_ns(&q->watchdog,
- now + max_t(long, -toks, -ptoks));
+ now + max_t(long, -toks, -ptoks),
+ true);
/* Maybe we have a shorter packet in the queue,
which can be sent now. It sounds cool,
^ permalink raw reply related
* [PATCH net-next] fec: Fix fec_enet_alloc_buffers() error path
From: Fabio Estevam @ 2014-10-04 16:40 UTC (permalink / raw)
To: davem; +Cc: rmk+kernel, Frank.Li, netdev, Fabio Estevam
From: Fabio Estevam <fabio.estevam@freescale.com>
When fec_enet_alloc_buffers() fails we should better undo the previous actions,
which consists of: disabling the FEC clocks and putting the FEC pins into
inactive state.
The error path for fec_enet_mii_probe() is kept unchanged.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
drivers/net/ethernet/freescale/fec_main.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 1f07db8..620feaf 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2746,16 +2746,12 @@ fec_enet_open(struct net_device *ndev)
ret = fec_enet_alloc_buffers(ndev);
if (ret)
- return ret;
+ goto err_enet_alloc;
/* Probe and connect to PHY when open the interface */
ret = fec_enet_mii_probe(ndev);
- if (ret) {
- fec_enet_free_buffers(ndev);
- fec_enet_clk_enable(ndev, false);
- pinctrl_pm_select_sleep_state(&fep->pdev->dev);
- return ret;
- }
+ if (ret)
+ goto err_enet_mii_probe;
fec_restart(ndev);
napi_enable(&fep->napi);
@@ -2763,6 +2759,13 @@ fec_enet_open(struct net_device *ndev)
netif_tx_start_all_queues(ndev);
return 0;
+
+err_enet_mii_probe:
+ fec_enet_free_buffers(ndev);
+err_enet_alloc:
+ fec_enet_clk_enable(ndev, false);
+ pinctrl_pm_select_sleep_state(&fep->pdev->dev);
+ return ret;
}
static int
--
1.9.1
^ permalink raw reply related
* Re: [RFC 1/1] net: fix rcu access on phonet_routes
From: Eric Dumazet @ 2014-10-04 15:30 UTC (permalink / raw)
To: Fabian Frederick
Cc: linux-kernel, Josh Triplett, Remi Denis-Courmont, David S. Miller,
netdev
In-Reply-To: <1412416676-21698-1-git-send-email-fabf@skynet.be>
On Sat, 2014-10-04 at 11:57 +0200, Fabian Frederick wrote:
> -Add __rcu annotation on table to fix sparse warnings:
> net/phonet/pn_dev.c:279:25: warning: incorrect type in assignment (different address spaces)
> net/phonet/pn_dev.c:279:25: expected struct net_device *<noident>
> net/phonet/pn_dev.c:279:25: got void [noderef] <asn:4>*<noident>
> net/phonet/pn_dev.c:376:17: warning: incorrect type in assignment (different address spaces)
> net/phonet/pn_dev.c:376:17: expected struct net_device *volatile <noident>
> net/phonet/pn_dev.c:376:17: got struct net_device [noderef] <asn:4>*<noident>
> net/phonet/pn_dev.c:392:17: warning: incorrect type in assignment (different address spaces)
> net/phonet/pn_dev.c:392:17: expected struct net_device *<noident>
> net/phonet/pn_dev.c:392:17: got void [noderef] <asn:4>*<noident>
>
> -Access table with rcu_dereference (fixes the following sparse errors):
> net/phonet/pn_dev.c:278:25: error: incompatible types in comparison expression (different address spaces)
> net/phonet/pn_dev.c:391:17: error: incompatible types in comparison expression (different address spaces)
>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
> ---
> net/phonet/pn_dev.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/phonet/pn_dev.c b/net/phonet/pn_dev.c
> index 56a6146..5c9c0b2f1 100644
> --- a/net/phonet/pn_dev.c
> +++ b/net/phonet/pn_dev.c
> @@ -36,7 +36,7 @@
>
> struct phonet_routes {
> struct mutex lock;
> - struct net_device *table[64];
> + struct net_device __rcu *table[64];
> };
>
> struct phonet_net {
> @@ -275,7 +275,7 @@ static void phonet_route_autodel(struct net_device *dev)
> bitmap_zero(deleted, 64);
> mutex_lock(&pnn->routes.lock);
> for (i = 0; i < 64; i++)
> - if (dev == pnn->routes.table[i]) {
> + if (rcu_dereference(pnn->routes.table[i]) == dev) {
> RCU_INIT_POINTER(pnn->routes.table[i], NULL);
> set_bit(i, deleted);
> }
> @@ -388,7 +388,7 @@ int phonet_route_del(struct net_device *dev, u8 daddr)
>
> daddr = daddr >> 2;
> mutex_lock(&routes->lock);
> - if (dev == routes->table[daddr])
> + if (rcu_dereference(routes->table[daddr]) == dev)
> RCU_INIT_POINTER(routes->table[daddr], NULL);
> else
> dev = NULL;
Hi Fabian
Have you tested this running the kernel with following config options :
CONFIG_LOCKDEP=y
CONFIG_PROVE_RCU=y
LOCKDEP should complain loudly, if not, we should file a bug !
Hint : Use rcu_access_pointer(), and check that LOCKDEP is happy with
that.
Thanks !
^ permalink raw reply
* [PATCH iproute2] ip tunnel: fix 'ip -oneline tunnel show' for some GRE tunnels
From: Dmitry Popov @ 2014-10-04 15:00 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
'ip -oneline tunnel show' was not "oneline" for GRE tunnels with iseq:
# ip tun add gre_test remote 1.1.1.1 local 2.2.2.2 mode gre iseq oseq
# ip -oneline tun show gre_test | wc -l
2
The problem existed because of a typo: '\n' was printed when it shouldn't be.
Fixed.
Signed-off-by: Dmitry Popov <ixaphire@qrator.net>
---
ip/ip6tunnel.c | 2 +-
ip/iptunnel.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/ip/ip6tunnel.c b/ip/ip6tunnel.c
index 4b73ec6..b83534e 100644
--- a/ip/ip6tunnel.c
+++ b/ip/ip6tunnel.c
@@ -117,7 +117,7 @@ static void print_tunnel(struct ip6_tnl_parm2 *p)
}
if (p->i_flags&GRE_SEQ)
- printf("%s Drop packets out of sequence.\n", _SL_);
+ printf("%s Drop packets out of sequence.", _SL_);
if (p->i_flags&GRE_CSUM)
printf("%s Checksum in received packet is required.", _SL_);
if (p->o_flags&GRE_SEQ)
diff --git a/ip/iptunnel.c b/ip/iptunnel.c
index 0844a4f..caf8a28 100644
--- a/ip/iptunnel.c
+++ b/ip/iptunnel.c
@@ -409,7 +409,7 @@ static void print_tunnel(struct ip_tunnel_parm *p)
}
if (p->i_flags&GRE_SEQ)
- printf("%s Drop packets out of sequence.\n", _SL_);
+ printf("%s Drop packets out of sequence.", _SL_);
if (p->i_flags&GRE_CSUM)
printf("%s Checksum in received packet is required.", _SL_);
if (p->o_flags&GRE_SEQ)
^ permalink raw reply related
* bridge: Do not compile options in br_parse_ip_options
From: Herbert Xu @ 2014-10-04 14:18 UTC (permalink / raw)
To: Florian Westphal
Cc: netfilter-devel, bsd, stephen, netdev, eric.dumazet, davidn,
David S. Miller
In-Reply-To: <20141004135508.GA10705@gondor.apana.org.au>
On Sat, Oct 04, 2014 at 09:55:08PM +0800, Herbert Xu wrote:
>
> I'll try to create a patch that essentially reverts the patch
> that led us here.
Here is a patch that's only compile-tested:
bridge: Do not compile options in br_parse_ip_options
Commit 462fb2af9788a82a534f8184abfde31574e1cfa0
bridge : Sanitize skb before it enters the IP stack
broke when IP options are actually used because it mangles the
skb as if it entered the IP stack which is wrong because the
bridge is supposed to operate below the IP stack.
Since nobody has actually requested for parsing of IP options
this patch fixes it by simply reverting to the previous approach
of ignoring all IP options, i.e., zeroing the IPCB.
If and when somebody who uses IP options and actually needs them
to be parsed by the bridge complains then we can revisit this.
Reported-by: David Newall <davidn@davidnewall.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index a615264..c0fdb4d 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -260,7 +260,6 @@ static inline void nf_bridge_update_protocol(struct sk_buff *skb)
static int br_parse_ip_options(struct sk_buff *skb)
{
- struct ip_options *opt;
const struct iphdr *iph;
struct net_device *dev = skb->dev;
u32 len;
@@ -269,7 +268,6 @@ static int br_parse_ip_options(struct sk_buff *skb)
goto inhdr_error;
iph = ip_hdr(skb);
- opt = &(IPCB(skb)->opt);
/* Basic sanity checks */
if (iph->ihl < 5 || iph->version != 4)
@@ -295,23 +293,11 @@ static int br_parse_ip_options(struct sk_buff *skb)
}
memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
- if (iph->ihl == 5)
- return 0;
-
- opt->optlen = iph->ihl*4 - sizeof(struct iphdr);
- if (ip_options_compile(dev_net(dev), opt, skb))
- goto inhdr_error;
-
- /* Check correct handling of SRR option */
- if (unlikely(opt->srr)) {
- struct in_device *in_dev = __in_dev_get_rcu(dev);
- if (in_dev && !IN_DEV_SOURCE_ROUTE(in_dev))
- goto drop;
-
- if (ip_options_rcv_srr(skb))
- goto drop;
- }
-
+ /* We should really parse IP options here but until
+ * somebody who actually uses IP options complains to
+ * us we'll just silently ignore the options because
+ * we're lazy!
+ */
return 0;
inhdr_error:
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: [PATCH nf next 0/3] bridge: netfilter: fix handling of ipv4 packets w. options
From: Herbert Xu @ 2014-10-04 13:55 UTC (permalink / raw)
To: Florian Westphal
Cc: netfilter-devel, bsd, stephen, netdev, eric.dumazet, davidn,
Bandan Das
In-Reply-To: <20141004100413.GA1241@breakpoint.cc>
On Sat, Oct 04, 2014 at 12:04:13PM +0200, Florian Westphal wrote:
>
> > The reason I asked for the IPCB to be built is to handle exactly
> > that case.
>
> Why do we need to compile ip options, exactly? If the packet
> is locally delivered, we hand it up to the ip stack which will
> compile ip options normally.
Good point. I thought we added this because Bandan Das wanted
options. But rereading the thread in question
http://lkml.org/lkml/2010/9/3/16
it seems that he doesn't actually need options. So what happened
appears to be a misunderstanding. Bandan tried to improve my
original memset hack by compiling options which would have been
fine except that his approach ended up mangling the packet which
is a big no-no.
So the most straightforward solution is to go back to my original
hack and just do a straight memset zero of the cb area before
each entry into the IP stack from the bridge.
I'll try to create a patch that essentially reverts the patch
that led us here.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH net-next] net: phy: adjust fixed_phy_register() return value
From: Thomas Petazzoni @ 2014-10-04 12:07 UTC (permalink / raw)
To: Petri Gynther; +Cc: netdev, davem, f.fainelli
In-Reply-To: <20141001214509.2BF4F10070D@puck.mtv.corp.google.com>
Dear Petri Gynther,
Sorry for the late answer.
On Wed, 1 Oct 2014 14:45:09 -0700 (PDT), Petri Gynther wrote:
> Adjust fixed_phy_register() to return struct phy_device *, so that
> it becomes easy to use fixed PHYs without device tree support:
>
> phydev = fixed_phy_register(PHY_POLL, &fixed_phy_status, NULL);
> fixed_phy_set_link_update(phydev, fixed_phy_link_update);
> phy_connect_direct(netdev, phydev, handler_fn, phy_interface);
>
> This change is a prerequisite for modifying bcmgenet driver to work
> without a device tree on Broadcom's MIPS-based 7xxx platforms.
>
> Signed-off-by: Petri Gynther <pgynther@google.com>
On the principle, I'm obviously fine, but I have one comment below.
> /* New binding */
> fixed_link_node = of_get_child_by_name(np, "fixed-link");
> @@ -299,7 +300,8 @@ int of_phy_register_fixed_link(struct device_node *np)
> status.asym_pause = of_property_read_bool(fixed_link_node,
> "asym-pause");
> of_node_put(fixed_link_node);
> - return fixed_phy_register(PHY_POLL, &status, np);
> + phy = fixed_phy_register(PHY_POLL, &status, np);
> + return (!phy || IS_ERR(phy));
> }
>
> /* Old binding */
> @@ -310,7 +312,8 @@ int of_phy_register_fixed_link(struct device_node *np)
> status.speed = be32_to_cpu(fixed_link_prop[2]);
> status.pause = be32_to_cpu(fixed_link_prop[3]);
> status.asym_pause = be32_to_cpu(fixed_link_prop[4]);
> - return fixed_phy_register(PHY_POLL, &status, np);
> + phy = fixed_phy_register(PHY_POLL, &status, np);
> + return (!phy || IS_ERR(phy));
I am not sure this return (!phy || IS_ERR(phy)) is doing the right
thing. This function is supposed to return an error code on failure, or
0 on success. I don't see how your error handling returns an error code
on failure. What about doing the more explicit:
phy = fixed_phy_register(PHY_POLL, &status, np);
if (IS_ERR(phy))
return PTR_ERR(phy);
else
return 0;
Or am I missing something?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH] drivers/net/can/m_can/Kconfig: Let CAN_M_CAN depend on HAS_IOMEM
From: Chen Gang @ 2014-10-04 11:49 UTC (permalink / raw)
To: Varka Bhadram, wg, mkl, fengguang.wu, b29396
Cc: linux-can, netdev, linux-kernel
In-Reply-To: <542FD466.6080603@gmail.com>
On 10/4/14 19:05, Varka Bhadram wrote:
> Hi Chen Gang
>
>
> I think commit message should be short and proper.
>
> We can remove *drivers/net/can/m_can/Kconfig* in the commit, just
> give *can: Kconfig: *
>
> commit message like : *can: Kconfig: Fix CAN_M_CAN dependency*
>
OK, thanks, it sounds good to me. If necessary to send patch v2 for it,
please let me know.
Thanks.
> On Saturday 04 October 2014 03:30 PM, Chen Gang wrote:
>> CAN_M_CAN needs HAS_IOMEM, so depend on it, the related error (with
>> allmodconfig under um):
>>
>> MODPOST 1205 modules
>> ERROR: "devm_ioremap" [drivers/net/can/m_can/m_can.ko] undefined!
>> ERROR: "devm_ioremap_resource" [drivers/net/can/m_can/m_can.ko] undefined!
>>
>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
>> ---
>> drivers/net/can/m_can/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
>> index fca5482..14c9fcf 100644
>> --- a/drivers/net/can/m_can/Kconfig
>> +++ b/drivers/net/can/m_can/Kconfig
>> @@ -1,4 +1,5 @@
>> config CAN_M_CAN
>> tristate "Bosch M_CAN devices"
>> + depends on HAS_IOMEM
>> ---help---
>> Say Y here if you want to support for Bosch M_CAN controller.
>
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
^ permalink raw reply
* Re: [RFC 1/1] net: fix rcu access on phonet_routes
From: Rémi Denis-Courmont @ 2014-10-04 11:24 UTC (permalink / raw)
To: Fabian Frederick, David S. Miller; +Cc: linux-kernel, Josh Triplett, netdev
In-Reply-To: <1412416676-21698-1-git-send-email-fabf@skynet.be>
Le samedi 4 octobre 2014, 11:57:56 Fabian Frederick a écrit :
(snip)
> -Access table with rcu_dereference (fixes the following sparse errors):
> net/phonet/pn_dev.c:278:25: error: incompatible types in comparison
> expression (different address spaces) net/phonet/pn_dev.c:391:17: error:
> incompatible types in comparison expression (different address spaces)
Acked-by: Rémi Denis-Courmont <remi@remlab.net>
--
Rémi Denis-Courmont
http://www.remlab.net/
^ permalink raw reply
* Re: [PATCH] drivers/net/can/m_can/Kconfig: Let CAN_M_CAN depend on HAS_IOMEM
From: Varka Bhadram @ 2014-10-04 11:05 UTC (permalink / raw)
To: Chen Gang, wg, mkl, fengguang.wu, b29396; +Cc: linux-can, netdev, linux-kernel
In-Reply-To: <542FC556.6060306@gmail.com>
Hi Chen Gang
I think commit message should be short and proper.
We can remove *drivers/net/can/m_can/Kconfig* in the commit, just
give *can: Kconfig: *
commit message like : *can: Kconfig: Fix CAN_M_CAN dependency*
On Saturday 04 October 2014 03:30 PM, Chen Gang wrote:
> CAN_M_CAN needs HAS_IOMEM, so depend on it, the related error (with
> allmodconfig under um):
>
> MODPOST 1205 modules
> ERROR: "devm_ioremap" [drivers/net/can/m_can/m_can.ko] undefined!
> ERROR: "devm_ioremap_resource" [drivers/net/can/m_can/m_can.ko] undefined!
>
> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
> ---
> drivers/net/can/m_can/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
> index fca5482..14c9fcf 100644
> --- a/drivers/net/can/m_can/Kconfig
> +++ b/drivers/net/can/m_can/Kconfig
> @@ -1,4 +1,5 @@
> config CAN_M_CAN
> tristate "Bosch M_CAN devices"
> + depends on HAS_IOMEM
> ---help---
> Say Y here if you want to support for Bosch M_CAN controller.
--
Thanks and Regards,
Varka Bhadram.
^ permalink raw reply
* Re: [PATCH nf next 0/3] bridge: netfilter: fix handling of ipv4 packets w. options
From: Florian Westphal @ 2014-10-04 10:04 UTC (permalink / raw)
To: Herbert Xu
Cc: Florian Westphal, netfilter-devel, bsd, stephen, netdev,
eric.dumazet, davidn, Bandan Das
In-Reply-To: <20141004035606.GA8228@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> wrote:
[ fix netdev mail address, sorry about that ]
> On Sat, Oct 04, 2014 at 03:04:27AM +0200, Florian Westphal wrote:
> > David Newall reported that bridge causes bad checksums:
> > http://thread.gmane.org/gmane.linux.network/315705/focus=1706769
> >
> > The proposal was to revert
> > 462fb2af9788a82a5 (bridge : Sanitize skb before it enters the IP stack).
> >
> > However, this has some other adverse effects since bridge netfilter
> > and ip stack both use skb->cb (and we thus memset skb->cb whenever
> > we hand skb off to the ip stack).
> >
> > So, this series attemps to resolve this a bit differently.
> >
> > First, lets add the inet_param padding that Eric suggested previously.
> > This means that any earlier setup of IPCB will be preserved inside the
> > bridge layer.
> >
> > This is also useful for netfilter since it will preserve
> > IPCB(skb)->frag_max_size set up by ip defrag.
> >
> > Second, this gets rid of the option parsing/memset calls in
> > to forward and output cases.
> >
> > Third, the pre-routing path is changed to not mangle the packets
> > but to only validate the ip options.
> >
> > This patch series is vs. next instead of net/nf tree.
> >
> > This has been broken for so long that I don't think we need
> > to rush this.
>
> I'm unsure whether this is the right approach. So if I understand
> this correctly your problem is coming from packets that are
>
> IP stack => bridge => IP stack
Just to clarify, right now this doesn't work:
ping -R <addr-of-bridge>
ping -R <addr-behind-bridge>
> in which case preserving IP options may work.
>
> But does your patch handle packets that are
>
> external => bridge => IP stack
Aside from above record-route test I also played with a bogus bridge
setup where incoming packets can exceed br0 mtu, in this case we emit
frag error without echoing/acting on the options.
IP (.. flags [DF], proto ICMP (1), length 1508, options (NOP,RR 192.168.1.1, 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0))
192.168.1.1 > 192.168.1.16: ICMP echo request, id 26676, seq 1, length 1448
IP (.. flags [none], proto ICMP (1), length 576) 192.168.1.10 > 192.168.1.1: ICMP 192.168.1.16 unreachable - need to frag (mtu 1500), length 556
1.10 is br0 IP, 1.16 and 1.1 are on different bridge ports, 1.1 has
bogus (larger) mtu than all other hosts.
The fragment error does not echo any RR information.
Is that your concern?
> The reason I asked for the IPCB to be built is to handle exactly
> that case.
Why do we need to compile ip options, exactly? If the packet
is locally delivered, we hand it up to the ip stack which will
compile ip options normally.
If its forwarded, it only travels through netfilter hooks.
The preserved ip_options_compile() call will make sure options
look sane (we don't preserve the built opts information in
this patch).
The only case where it can reenter in fwd case, AFAICS, is when the
skb exceeds the mtu due to nf_defrag (reenter via call to ip_fragment()).
And we used to get crash here when calling icmp_send since skb->cb
was pointing to bridge cb, which then would crash in __ip_options_echo()
because the various IPCB->opts offsets were garbage.
But, why would we want to echo options?
We're just a bridge (so yes, strictly speaking the icmp response
is already wrong, but silently tossing packets doesn't seem right
either).
Are you saying we should act like router and set the options?
> In fact, even preserving IPCB in the IP stack reentry case is
> a hack since if we ever change the IP stack in future such that
> on exit the IPCB is no longer valid for reentry your approach
> will fail.
True. I guess in that case, we'd have to resort to less
straightforward approach, i.e. explicitly add the IPCB parts
we wish to retain to br_input_skb_cb, then translate back-and-forth
where needed.
> Now as to your original problem that ip_options_compile mangles
> the packet this is something I explicitly said we should fix
> before we added br_parse_ip_options (point 2 in that email):
>
> https://lkml.org/lkml/2010/9/3/16
>
> Unfortunately it looks like nobody actually did the audit.
Right.
> So my suggestion would be to fix br_parse_ip_options so that
> it never mangles the packet.
This patch avoids the option mangling by passing in a NULL skb.
So to do what you want all that is needed is to remember
the parsed opts result. If we add Erics suggested inet cb pad
we can just place the parsed option struct into IPCB()->opts.
If not, we could add struct ip_options to br_input_skb_cb
and stash it there (we'd still need to re-arrange skb->cb to
what ip stack expects though when calling back into it in output
path).
Alternatively, we could call the ipv4 parsing function again
to re-construct IPCB->opts.
I'm just not yet sure if this is the right idea.
Remembering the information will cause the icmp frag error
above to list br0 ip address in the icmp frag error.
Under which circumstances would we want/need to remember the
parsed options (i.e. retain struct ip_options in ->cb[]), or
act upon them?
Thanks,
Florian
^ permalink raw reply
* [PATCH] drivers/net/can/m_can/Kconfig: Let CAN_M_CAN depend on HAS_IOMEM
From: Chen Gang @ 2014-10-04 10:00 UTC (permalink / raw)
To: wg, mkl, fengguang.wu, b29396, varkabhadram
Cc: linux-can, netdev, linux-kernel
CAN_M_CAN needs HAS_IOMEM, so depend on it, the related error (with
allmodconfig under um):
MODPOST 1205 modules
ERROR: "devm_ioremap" [drivers/net/can/m_can/m_can.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/net/can/m_can/m_can.ko] undefined!
Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
---
drivers/net/can/m_can/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
index fca5482..14c9fcf 100644
--- a/drivers/net/can/m_can/Kconfig
+++ b/drivers/net/can/m_can/Kconfig
@@ -1,4 +1,5 @@
config CAN_M_CAN
tristate "Bosch M_CAN devices"
+ depends on HAS_IOMEM
---help---
Say Y here if you want to support for Bosch M_CAN controller.
--
1.9.3
^ 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