* Re: [PATCH 0/6] bonding:fix checkpatch errors or warning.
From: David Miller @ 2014-02-14 21:22 UTC (permalink / raw)
To: wangyufen; +Cc: netdev
In-Reply-To: <1392369317-8072-1-git-send-email-wangyufen@huawei.com>
From: Wangyufen <wangyufen@huawei.com>
Date: Fri, 14 Feb 2014 17:15:11 +0800
> From: Wang Yufen <wangyufen@huawei.com>
>
> Wang Yufen (6):
> bonding:fix checkpatch errors with foo* bar|foo * bar
> bonding:fix checkpatch errors comments and space
> bonding:fix checkpatch warnings braces {}
> bonding:fix checkpatch warnings braces {}
> bonding:fix checkpatch warnings braces {}
> bonding:fix checkpatch warnings braces {}
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 4/4] appletalk: fix checkpatch error with indent
From: David Miller @ 2014-02-14 21:21 UTC (permalink / raw)
To: wangweidong1; +Cc: acme, netdev
In-Reply-To: <1392363826-8256-5-git-send-email-wangweidong1@huawei.com>
From: Wang Weidong <wangweidong1@huawei.com>
Date: Fri, 14 Feb 2014 15:43:46 +0800
> checkpatch error: switch and case should be at the same indent.
>
> Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 3/4] appletalk: convert printks to pr_<level>
From: David Miller @ 2014-02-14 21:21 UTC (permalink / raw)
To: wangweidong1; +Cc: acme, netdev
In-Reply-To: <1392363826-8256-4-git-send-email-wangweidong1@huawei.com>
From: Wang Weidong <wangweidong1@huawei.com>
Date: Fri, 14 Feb 2014 15:43:45 +0800
> Prefer pr_<level> then printk(LEVEL).
>
> Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
Not applied, please sort out the pr_debug() vs. printk(KERN_DEBUG
differences pointed out to you.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 2/4] appletalk: fix checkpatch errors with foo* bar|foo * bar
From: David Miller @ 2014-02-14 21:21 UTC (permalink / raw)
To: wangweidong1; +Cc: acme, netdev
In-Reply-To: <1392363826-8256-3-git-send-email-wangweidong1@huawei.com>
From: Wang Weidong <wangweidong1@huawei.com>
Date: Fri, 14 Feb 2014 15:43:44 +0800
> fix checkpatch errors below:
> ERROR: "foo* bar" should be "foo *bar"
> ERROR: "foo * bar" should be "foo *bar"
>
> Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/4] appletalk: fix checkpatch errors with space required or prohibited
From: David Miller @ 2014-02-14 21:21 UTC (permalink / raw)
To: wangweidong1; +Cc: acme, netdev
In-Reply-To: <1392363826-8256-2-git-send-email-wangweidong1@huawei.com>
From: Wang Weidong <wangweidong1@huawei.com>
Date: Fri, 14 Feb 2014 15:43:43 +0800
> fix checkpatch errors while the space is required or prohibited
>
> Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
Applied.
^ permalink raw reply
* Re: [patch] net,bonding: fix bond_options.c direct rwlock.h include
From: David Miller @ 2014-02-14 21:21 UTC (permalink / raw)
To: bitbucket; +Cc: netdev, linux-kernel
In-Reply-To: <1392362464.5579.41.camel@marge.simpson.net>
From: Mike Galbraith <bitbucket@online.de>
Date: Fri, 14 Feb 2014 08:21:04 +0100
> drivers/net/bonding/bond_options.c includes rwlock.h directly,
> which is a nono, and which also breaks RT kernel build.
>
> Signed-off-by: Mike Galbraith <bitbucket@online.de>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] bonding: 802.3ad: make aggregator_identifier bond-private
From: Jay Vosburgh @ 2014-02-14 21:16 UTC (permalink / raw)
To: Jiri Bohac; +Cc: Flavio Leitner, Veaceslav Falico, Andy Gospodarek, netdev
In-Reply-To: <20140214205147.GA1798@midget.suse.cz>
Jiri Bohac <jbohac@suse.cz> wrote:
>On Fri, Feb 14, 2014 at 05:12:43PM -0200, Flavio Leitner wrote:
>> On Fri, Feb 14, 2014 at 06:13:50PM +0100, Jiri Bohac wrote:
>> > Fix this by making aggregator_identifier private to the bond.
>>
>> I don't see how you fix the duplicate agg id with this patch because
>> you initialize for each bond to 0, then use the same algo further on.
>> So, what is changing?
>
>My understanding is that the aggregator identifier is used
>internally by the bond and never appears anywhere in the LACP
>traffic.
>
>So having duplicate aggregator ids between two bonds on the same
>machine does not matter. But it is a problem if two aggregators
>in the same bond share the same id.
>
>Is my understanding wrong?
Your understanding is correct.
>> Actually, aggregator_identifier is a global variable to make sure the
>> counter is always increasing for new bonds. So, the fix would be to
>> not reset it to zero, isn't it?
>
>I was considering this fix, but my concern was that the variable
>(u16) would overflow sooner than it does now. It would take 2^16
>enslavings on the machine, while with my patch you need 2^16
>enslavings on a single bond.
>
>Hypothetically, a rogue NET_ADMIN in one net namespace may cause
>this overflow to break a bond in another nemespace.
>
>Maybe I'm being paranoid? ;)
Personally, for ease of reading debug messages, I would prefer
the globally unique ID (or a patch to update the pr_debugs to add the
bond name). From a technical point of view either way will function
correctly. I'm not too worried about the overflow of the ID.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH net-next] tcp: add pacing_rate information into tcp_info
From: David Miller @ 2014-02-14 21:10 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1392330460.1752.42.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 13 Feb 2014 14:27:40 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Add two new fields to struct tcp_info, to report sk_pacing_rate
> and sk_max_pacing_rate to monitoring applications, as ss from iproute2.
>
> User exported fields are 64bit, even if kernel is currently using 32bit
> fields.
>
> lpaa5:~# ss -i
> ..
> skmem:(r0,rb357120,t0,tb2097152,f1584,w1980880,o0,bl0) ts sack cubic
> wscale:6,6 rto:400 rtt:0.875/0.75 mss:1448 cwnd:1 ssthresh:12 send
> 13.2Mbps pacing_rate 3336.2Mbps unacked:15 retrans:1/5448 lost:15
> rcv_space:29200
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Looks good, applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net] packet: check for ndo_select_queue during queue selection
From: Daniel Borkmann @ 2014-02-14 21:03 UTC (permalink / raw)
To: David Miller; +Cc: mathias.kretschmer, netdev, brouer
In-Reply-To: <20140214.134843.1912150240271947468.davem@davemloft.net>
Thanks for the feedback Dave, will fix that up tomorrow.
^ permalink raw reply
* Re: [PATCH net] net: of_mdio: fix of_set_phy_supported after driver probing
From: David Miller @ 2014-02-14 20:52 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev
In-Reply-To: <1392326088-3990-1-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 13 Feb 2014 13:14:48 -0800
> Commit 8fdade4 ("net: of_mdio: parse "max-speed" property to set PHY
> supported features") introduced a typo in of_set_phy_supported for the
> first assignment of phydev->supported which will not effectively limit
> the PHY device supported features bits if the PHY driver contains
> "higher" features (e.g: max-speed = <100> and PHY driver has
> PHY_GBIT_FEATURES set).
>
> Fix this by making sure that the very first thing is to reset to sane
> defaults (PHY_BASIC_FEATURES) and then progressively add speed features
> as we parse them.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] bonding: 802.3ad: make aggregator_identifier bond-private
From: Jiri Bohac @ 2014-02-14 20:51 UTC (permalink / raw)
To: Flavio Leitner; +Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, netdev
In-Reply-To: <20140214191243.GA3173@localhost.localdomain>
On Fri, Feb 14, 2014 at 05:12:43PM -0200, Flavio Leitner wrote:
> On Fri, Feb 14, 2014 at 06:13:50PM +0100, Jiri Bohac wrote:
> > Fix this by making aggregator_identifier private to the bond.
>
> I don't see how you fix the duplicate agg id with this patch because
> you initialize for each bond to 0, then use the same algo further on.
> So, what is changing?
My understanding is that the aggregator identifier is used
internally by the bond and never appears anywhere in the LACP
traffic.
So having duplicate aggregator ids between two bonds on the same
machine does not matter. But it is a problem if two aggregators
in the same bond share the same id.
Is my understanding wrong?
> Actually, aggregator_identifier is a global variable to make sure the
> counter is always increasing for new bonds. So, the fix would be to
> not reset it to zero, isn't it?
I was considering this fix, but my concern was that the variable
(u16) would overflow sooner than it does now. It would take 2^16
enslavings on the machine, while with my patch you need 2^16
enslavings on a single bond.
Hypothetically, a rogue NET_ADMIN in one net namespace may cause
this overflow to break a bond in another nemespace.
Maybe I'm being paranoid? ;)
--
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ
--
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ
^ permalink raw reply
* Re: [Patch net-next] net: introduce netdev_alloc_pcpu_stats() for drivers
From: David Miller @ 2014-02-14 20:50 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev
In-Reply-To: <1392320788-17962-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Thu, 13 Feb 2014 11:46:28 -0800
> There are many drivers calling alloc_percpu() to allocate pcpu stats
> and then initializing ->syncp. So just introduce a helper function for them.
>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Looks good, applied, thanks.
^ permalink raw reply
* Re: [PATCH Resend] net: asix: add missing flag to struct driver_info
From: David Miller @ 2014-02-14 20:48 UTC (permalink / raw)
To: emilgoode
Cc: ming.lei, broonie, jeffrey.t.kirsher, gdt, linux-usb, netdev,
linux-kernel
In-Reply-To: <1392316239-17335-1-git-send-email-emilgoode@gmail.com>
From: Emil Goode <emilgoode@gmail.com>
Date: Thu, 13 Feb 2014 19:30:39 +0100
> The struct driver_info ax88178_info is assigned the function
> asix_rx_fixup_common as it's rx_fixup callback. This means that
> FLAG_MULTI_PACKET must be set as this function is cloning the
> data and calling usbnet_skb_return. Not setting this flag leads
> to usbnet_skb_return beeing called a second time from within
> the rx_process function in the usbnet module.
>
> Signed-off-by: Emil Goode <emilgoode@gmail.com>
> Reported-by: Bjørn Mork <bjorn@mork.no>
Applied and queued up for -stable.
It would be great if there were some way to validate these
callback flags requirements and catch such errors.
^ permalink raw reply
* Re: [PATCH net-next] net-sysfs: get_netdev_queue_index() cleanup
From: David Miller @ 2014-02-14 20:47 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1392314833.1752.30.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 13 Feb 2014 10:07:13 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Remove one inline keyword, and no need for a loop to find
> an index into a table.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next 3/4] appletalk: convert printks to pr_<level>
From: Sergei Shtylyov @ 2014-02-14 21:45 UTC (permalink / raw)
To: Wang Weidong, acme, davem; +Cc: netdev
In-Reply-To: <1392363826-8256-4-git-send-email-wangweidong1@huawei.com>
Hello.
On 02/14/2014 10:43 AM, Wang Weidong wrote:
> Prefer pr_<level> then printk(LEVEL).
> Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
[...]
> diff --git a/net/appletalk/ddp.c b/net/appletalk/ddp.c
> index 06e0d19..9189d3c 100644
> --- a/net/appletalk/ddp.c
> +++ b/net/appletalk/ddp.c
> @@ -704,9 +704,9 @@ static int atif_ioctl(int cmd, void __user *arg)
> if ((dev->flags & IFF_POINTOPOINT) &&
> atalk_find_interface(sa->sat_addr.s_net,
> sa->sat_addr.s_node)) {
> - printk(KERN_DEBUG "AppleTalk: point-to-point "
> - "interface added with "
> - "existing address\n");
> + pr_debug("AppleTalk: point-to-point "
> + "interface added with "
> + "existing address\n");
> add_route = 0;
> }
>
[...]
> @@ -1329,8 +1328,8 @@ static int atalk_route_packet(struct sk_buff *skb, struct net_device *dev,
> * needs to be broadcast onto the default network?
> */
> if (dev->type == ARPHRD_PPP)
> - printk(KERN_DEBUG "AppleTalk: didn't forward broadcast "
> - "packet received from PPP iface\n");
> + pr_debug("AppleTalk: didn't forward broadcast "
> + "packet received from PPP iface\n");
pr_debug() is not equivalent to printk(KERN_DEBUG). It will only print a
message if DEBUG is defined or if dynamic debugging is enabled.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next v5 10/10] MAINTAINERS: add entry for the Broadcom GENET driver
From: Sergei Shtylyov @ 2014-02-14 21:37 UTC (permalink / raw)
To: Florian Fainelli, netdev
Cc: davem, devicetree, cernekee, mark.rutland, romieu
In-Reply-To: <1392336531-28875-11-git-send-email-f.fainelli@gmail.com>
Hello.
On 02/14/2014 03:08 AM, Florian Fainelli wrote:
> Add myself as a maintainer of the Broadcom GENET driver.
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
[...]
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 091b50e..5a7b3ec 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1845,6 +1845,12 @@ L: netdev@vger.kernel.org
> S: Supported
> F: drivers/net/ethernet/broadcom/b44.*
>
> +BROADCOM GENET ETHERNET DRIVER
> +M: Florian Fainelli <f.fainelli@gmail.com>
> +L: netdev@vger.kernel.org
> +S: Supported
> +F: drivers/net/ethernet/broadcom/genet/
> +
Aren't these entries supposed to be sorted alphabetically? If so, in my
alphabet BNX2 comes before GENET...
> BROADCOM BNX2 GIGABIT ETHERNET DRIVER
> M: Michael Chan <mchan@broadcom.com>
> L: netdev@vger.kernel.org
PS: I'm probably wrong, the entries don't appear to be sorted on the 2nd word...
WBR, Sergei
^ permalink raw reply
* [PATCH 26/48] net: Replace get_cpu_var through this_cpu_ptr
From: Christoph Lameter @ 2014-02-14 20:19 UTC (permalink / raw)
To: Tejun Heo
Cc: akpm, rostedt, linux-kernel, Ingo Molnar, Peter Zijlstra,
Thomas Gleixner, netdev, Eric Dumazet, David S. Miller
In-Reply-To: <20140214201841.826179349@linux.com>
[-- Attachment #1: this_net --]
[-- Type: text/plain, Size: 7879 bytes --]
[Patch depends on another patch in this series that introduces raw_cpu_ops]
Replace uses of get_cpu_var for address calculation through this_cpu_ptr.
Cc: netdev@vger.kernel.org
Cc: Eric Dumazet <edumazet@google.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Christoph Lameter <cl@linux.com>
Index: linux/net/core/dev.c
===================================================================
--- linux.orig/net/core/dev.c 2014-02-03 13:23:33.324833855 -0600
+++ linux/net/core/dev.c 2014-02-03 13:25:26.382485504 -0600
@@ -2134,7 +2134,7 @@
unsigned long flags;
local_irq_save(flags);
- sd = &__get_cpu_var(softnet_data);
+ sd = this_cpu_ptr(&softnet_data);
q->next_sched = NULL;
*sd->output_queue_tailp = q;
sd->output_queue_tailp = &q->next_sched;
@@ -3125,7 +3125,7 @@
static int rps_ipi_queued(struct softnet_data *sd)
{
#ifdef CONFIG_RPS
- struct softnet_data *mysd = &__get_cpu_var(softnet_data);
+ struct softnet_data *mysd = this_cpu_ptr(&softnet_data);
if (sd != mysd) {
sd->rps_ipi_next = mysd->rps_ipi_list;
@@ -3152,7 +3152,7 @@
if (qlen < (netdev_max_backlog >> 1))
return false;
- sd = &__get_cpu_var(softnet_data);
+ sd = this_cpu_ptr(&softnet_data);
rcu_read_lock();
fl = rcu_dereference(sd->flow_limit);
@@ -3303,7 +3303,7 @@
static void net_tx_action(struct softirq_action *h)
{
- struct softnet_data *sd = &__get_cpu_var(softnet_data);
+ struct softnet_data *sd = this_cpu_ptr(&softnet_data);
if (sd->completion_queue) {
struct sk_buff *clist;
@@ -3733,7 +3733,7 @@
static void flush_backlog(void *arg)
{
struct net_device *dev = arg;
- struct softnet_data *sd = &__get_cpu_var(softnet_data);
+ struct softnet_data *sd = this_cpu_ptr(&softnet_data);
struct sk_buff *skb, *tmp;
rps_lock(sd);
@@ -4205,7 +4205,7 @@
unsigned long flags;
local_irq_save(flags);
- ____napi_schedule(&__get_cpu_var(softnet_data), n);
+ ____napi_schedule(this_cpu_ptr(&softnet_data), n);
local_irq_restore(flags);
}
EXPORT_SYMBOL(__napi_schedule);
@@ -4326,7 +4326,7 @@
static void net_rx_action(struct softirq_action *h)
{
- struct softnet_data *sd = &__get_cpu_var(softnet_data);
+ struct softnet_data *sd = this_cpu_ptr(&softnet_data);
unsigned long time_limit = jiffies + 2;
int budget = netdev_budget;
void *have;
Index: linux/net/core/drop_monitor.c
===================================================================
--- linux.orig/net/core/drop_monitor.c 2014-02-03 13:23:33.324833855 -0600
+++ linux/net/core/drop_monitor.c 2014-02-03 13:23:33.314834063 -0600
@@ -146,7 +146,7 @@
unsigned long flags;
local_irq_save(flags);
- data = &__get_cpu_var(dm_cpu_data);
+ data = this_cpu_ptr(&dm_cpu_data);
spin_lock(&data->lock);
dskb = data->skb;
Index: linux/net/core/skbuff.c
===================================================================
--- linux.orig/net/core/skbuff.c 2014-02-03 13:23:33.324833855 -0600
+++ linux/net/core/skbuff.c 2014-02-03 13:23:33.314834063 -0600
@@ -344,7 +344,7 @@
unsigned long flags;
local_irq_save(flags);
- nc = &__get_cpu_var(netdev_alloc_cache);
+ nc = this_cpu_ptr(&netdev_alloc_cache);
if (unlikely(!nc->frag.page)) {
refill:
for (order = NETDEV_FRAG_PAGE_MAX_ORDER; ;) {
Index: linux/net/ipv4/tcp_output.c
===================================================================
--- linux.orig/net/ipv4/tcp_output.c 2014-02-03 13:23:33.324833855 -0600
+++ linux/net/ipv4/tcp_output.c 2014-02-03 13:23:33.314834063 -0600
@@ -817,7 +817,7 @@
/* queue this socket to tasklet queue */
local_irq_save(flags);
- tsq = &__get_cpu_var(tsq_tasklet);
+ tsq = this_cpu_ptr(&tsq_tasklet);
list_add(&tp->tsq_node, &tsq->head);
tasklet_schedule(&tsq->tasklet);
local_irq_restore(flags);
Index: linux/net/ipv6/syncookies.c
===================================================================
--- linux.orig/net/ipv6/syncookies.c 2014-02-03 13:23:33.324833855 -0600
+++ linux/net/ipv6/syncookies.c 2014-02-03 13:23:33.314834063 -0600
@@ -67,7 +67,7 @@
net_get_random_once(syncookie6_secret, sizeof(syncookie6_secret));
- tmp = __get_cpu_var(ipv6_cookie_scratch);
+ tmp = this_cpu_ptr(ipv6_cookie_scratch);
/*
* we have 320 bits of information to hash, copy in the remaining
Index: linux/net/rds/ib_rdma.c
===================================================================
--- linux.orig/net/rds/ib_rdma.c 2014-02-03 13:23:33.324833855 -0600
+++ linux/net/rds/ib_rdma.c 2014-02-03 13:23:33.314834063 -0600
@@ -267,7 +267,7 @@
unsigned long *flag;
preempt_disable();
- flag = &__get_cpu_var(clean_list_grace);
+ flag = this_cpu_ptr(&clean_list_grace);
set_bit(CLEAN_LIST_BUSY_BIT, flag);
ret = llist_del_first(&pool->clean_list);
if (ret)
Index: linux/include/net/netfilter/nf_conntrack.h
===================================================================
--- linux.orig/include/net/netfilter/nf_conntrack.h 2014-02-03 13:23:33.324833855 -0600
+++ linux/include/net/netfilter/nf_conntrack.h 2014-02-03 13:23:33.314834063 -0600
@@ -235,7 +235,7 @@
DECLARE_PER_CPU(struct nf_conn, nf_conntrack_untracked);
static inline struct nf_conn *nf_ct_untracked_get(void)
{
- return &__raw_get_cpu_var(nf_conntrack_untracked);
+ return raw_cpu_ptr(&nf_conntrack_untracked);
}
void nf_ct_untracked_status_or(unsigned long bits);
Index: linux/include/net/snmp.h
===================================================================
--- linux.orig/include/net/snmp.h 2014-02-03 13:23:33.324833855 -0600
+++ linux/include/net/snmp.h 2014-02-03 13:23:33.314834063 -0600
@@ -170,7 +170,7 @@
#define SNMP_ADD_STATS64_BH(mib, field, addend) \
do { \
- __typeof__(*mib[0]) *ptr = __this_cpu_ptr((mib)[0]); \
+ __typeof__(*mib[0]) *ptr = raw_cpu_ptr((mib)[0]); \
u64_stats_update_begin(&ptr->syncp); \
ptr->mibs[field] += addend; \
u64_stats_update_end(&ptr->syncp); \
@@ -192,7 +192,7 @@
#define SNMP_UPD_PO_STATS64_BH(mib, basefield, addend) \
do { \
__typeof__(*mib[0]) *ptr; \
- ptr = __this_cpu_ptr((mib)[0]); \
+ ptr = raw_cpu_ptr((mib)[0]); \
u64_stats_update_begin(&ptr->syncp); \
ptr->mibs[basefield##PKTS]++; \
ptr->mibs[basefield##OCTETS] += addend; \
Index: linux/net/ipv4/route.c
===================================================================
--- linux.orig/net/ipv4/route.c 2014-02-03 13:23:33.324833855 -0600
+++ linux/net/ipv4/route.c 2014-02-03 13:23:33.314834063 -0600
@@ -1303,7 +1303,7 @@
if (rt_is_input_route(rt)) {
p = (struct rtable **)&nh->nh_rth_input;
} else {
- p = (struct rtable **)__this_cpu_ptr(nh->nh_pcpu_rth_output);
+ p = (struct rtable **)raw_cpu_ptr(nh->nh_pcpu_rth_output);
}
orig = *p;
@@ -1929,7 +1929,7 @@
do_cache = false;
goto add;
}
- prth = __this_cpu_ptr(nh->nh_pcpu_rth_output);
+ prth = raw_cpu_ptr(nh->nh_pcpu_rth_output);
}
rth = rcu_dereference(*prth);
if (rt_cache_valid(rth)) {
Index: linux/net/ipv4/tcp.c
===================================================================
--- linux.orig/net/ipv4/tcp.c 2014-02-03 13:23:33.324833855 -0600
+++ linux/net/ipv4/tcp.c 2014-02-03 13:23:33.314834063 -0600
@@ -3024,7 +3024,7 @@
local_bh_disable();
p = ACCESS_ONCE(tcp_md5sig_pool);
if (p)
- return __this_cpu_ptr(p);
+ return raw_cpu_ptr(p);
local_bh_enable();
return NULL;
Index: linux/net/ipv4/syncookies.c
===================================================================
--- linux.orig/net/ipv4/syncookies.c 2014-02-03 13:23:33.324833855 -0600
+++ linux/net/ipv4/syncookies.c 2014-02-03 13:23:33.324833855 -0600
@@ -40,7 +40,7 @@
net_get_random_once(syncookie_secret, sizeof(syncookie_secret));
- tmp = __get_cpu_var(ipv4_cookie_scratch);
+ tmp = this_cpu_ptr(ipv4_cookie_scratch);
memcpy(tmp + 4, syncookie_secret[c], sizeof(syncookie_secret[c]));
tmp[0] = (__force u32)saddr;
tmp[1] = (__force u32)daddr;
^ permalink raw reply
* [PATCH 04/48] net: Replace __this_cpu_inc in route.c with raw_cpu_inc
From: Christoph Lameter @ 2014-02-14 20:18 UTC (permalink / raw)
To: Tejun Heo
Cc: akpm, rostedt, linux-kernel, Ingo Molnar, Peter Zijlstra,
Thomas Gleixner, netdev, edumazet, David S. Miller
In-Reply-To: <20140214201841.826179349@linux.com>
[-- Attachment #1: preempt_rt_cache_stat --]
[-- Type: text/plain, Size: 3607 bytes --]
[Patch depends on another patch in this series that introduces raw_cpu_ops]
The RT_CACHE_STAT_INC macro triggers the new preemption checks
for __this_cpu ops.
I do not see any other synchronization that would allow the use
of a __this_cpu operation here however in commit
dbd2915ce87e811165da0717f8e159276ebb803e Andrew justifies
the use of raw_smp_processor_id() here because "we do not care"
about races. In the past we agreed that the price of disabling
interrupts here to get consistent counters would be too high.
These counters may be inaccurate due to race conditions.
The use of __this_cpu op improves the situation already from what commit
dbd2915ce87e811165da0717f8e159276ebb803e did since the single instruction
emitted on x86 does not allow the race to occur anymore. However,
non x86 platforms could still experience a race here.
Trace:
[ 1277.189084] __this_cpu_add operation in preemptible [00000000] code: avahi-daemon/1193
[ 1277.189085] caller is __this_cpu_preempt_check+0x38/0x60
[ 1277.189086] CPU: 1 PID: 1193 Comm: avahi-daemon Tainted: GF 3.12.0-rc4+ #187
[ 1277.189087] Hardware name: FUJITSU CELSIUS W530 Power/D3227-A1, BIOS V4.6.5.4 R1.10.0 for D3227-A1x 09/16/2013
[ 1277.189088] 0000000000000001 ffff8807ef78fa00 ffffffff816d5a57 ffff8807ef78ffd8
[ 1277.189089] ffff8807ef78fa30 ffffffff8137359c ffff8807ef78fba0 ffff88079f822b40
[ 1277.189091] 0000000020000000 ffff8807ee32c800 ffff8807ef78fa70 ffffffff813735f8
[ 1277.189093] Call Trace:
[ 1277.189094] [<ffffffff816d5a57>] dump_stack+0x4e/0x82
[ 1277.189096] [<ffffffff8137359c>] check_preemption_disabled+0xec/0x110
[ 1277.189097] [<ffffffff813735f8>] __this_cpu_preempt_check+0x38/0x60
[ 1277.189098] [<ffffffff81610d65>] __ip_route_output_key+0x575/0x8c0
[ 1277.189100] [<ffffffff816110d7>] ip_route_output_flow+0x27/0x70
[ 1277.189101] [<ffffffff81616c80>] ? ip_copy_metadata+0x1a0/0x1a0
[ 1277.189102] [<ffffffff81640b15>] udp_sendmsg+0x825/0xa20
[ 1277.189104] [<ffffffff811b4aa9>] ? do_sys_poll+0x449/0x5d0
[ 1277.189105] [<ffffffff8164c695>] inet_sendmsg+0x85/0xc0
[ 1277.189106] [<ffffffff815c6e3c>] sock_sendmsg+0x9c/0xd0
[ 1277.189108] [<ffffffff813735f8>] ? __this_cpu_preempt_check+0x38/0x60
[ 1277.189109] [<ffffffff815c7550>] ? move_addr_to_kernel+0x40/0xa0
[ 1277.189111] [<ffffffff815c71ec>] ___sys_sendmsg+0x37c/0x390
[ 1277.189112] [<ffffffff8136613a>] ? string.isra.3+0x3a/0xd0
[ 1277.189113] [<ffffffff8136613a>] ? string.isra.3+0x3a/0xd0
[ 1277.189115] [<ffffffff81367b54>] ? vsnprintf+0x364/0x650
[ 1277.189116] [<ffffffff81367ee9>] ? snprintf+0x39/0x40
[ 1277.189118] [<ffffffff813735f8>] ? __this_cpu_preempt_check+0x38/0x60
[ 1277.189119] [<ffffffff815c7ff9>] __sys_sendmsg+0x49/0x90
[ 1277.189121] [<ffffffff815c8052>] SyS_sendmsg+0x12/0x20
[ 1277.189122] [<ffffffff816e4fd3>] tracesys+0xe1/0xe6
Cc: netdev@vger.kernel.org
Cc: edumazet@google.com
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Christoph Lameter <cl@linux.com>
Index: linux/net/ipv4/route.c
===================================================================
--- linux.orig/net/ipv4/route.c 2014-01-30 14:40:44.276650882 -0600
+++ linux/net/ipv4/route.c 2014-01-30 14:40:44.276650882 -0600
@@ -194,7 +194,7 @@
EXPORT_SYMBOL(ip_tos2prio);
static DEFINE_PER_CPU(struct rt_cache_stat, rt_cache_stat);
-#define RT_CACHE_STAT_INC(field) __this_cpu_inc(rt_cache_stat.field)
+#define RT_CACHE_STAT_INC(field) raw_cpu_inc(rt_cache_stat.field)
#ifdef CONFIG_PROC_FS
static void *rt_cache_seq_start(struct seq_file *seq, loff_t *pos)
^ permalink raw reply
* Re: [RFC PATCH v2 tip 0/7] 64-bit BPF insn set and tracing filters
From: Alexei Starovoitov @ 2014-02-14 20:17 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Ingo Molnar, David S. Miller, Steven Rostedt, Peter Zijlstra,
H. Peter Anvin, Thomas Gleixner, Masami Hiramatsu, Tom Zanussi,
Jovi Zhangwei, Eric Dumazet, Linus Torvalds, Andrew Morton,
Frederic Weisbecker, Arnaldo Carvalho de Melo, Pekka Enberg,
Arjan van de Ven, Christoph Hellwig, linux-kernel, netdev
In-Reply-To: <52FE51E9.8000203@redhat.com>
On Fri, Feb 14, 2014 at 9:27 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
> On 02/14/2014 05:47 AM, Alexei Starovoitov wrote:
> ...
>>>
>>> Do you see a possibility to integrate your work step by step? That is,
>>
>>
>> Sure. let's see how we can do it.
>>
>>> to first integrate the interpreter part only; meaning, to detect "old"
>>> BPF programs e.g. coming from SO_ATTACH_FILTER et al and run them in
>>> compatibility mode while extended BPF is fully integrated and replaces
>>> the old engine in net/core/filter.c. Maybe, "old" programs can be
>>
>>
>> do you mean drop bfp64_jit, checker and just have bpf32->bpf64 converter
>> and bpf64 interpreter as phase 1 ?
>> Checking is done by old bpf32,
>> all existing bpf32 jits, if available, can convert bpf32 to native,
>> but interpreter will be running on bpf64 ?
>> phase 2 to introduce bpf64_x86 jit and so on?
>> Sounds fine.
>
>
> If that's possible, so first step would be to migrate bpf_run() from patch1
> into sk_run_filter() form net/core/filter.c, and also bring in related
> include file into include/linux/filter.h resp. include/uapi/linux/filter.h.
> Plus code that is needed to verify the image in new (and old) format e.g.
> bpf_load_image() et al, and to either convert old programs into the new
> format, for example; generally, to find a way to still handle them
> (bpf/seccomp)
> while having the new code included and leaving new JITs aside. That I think
> could be phase 1. Phase 2 would be to successively replace current JITs,
> etc.
Sounds good.
Let me rephrase.
step 1:
sk_attach_filter() -> __sk_prepare_filter() -> sk_chk_filter() all stays as-is.
sk_chk_filter() calls new bpf_convert() that converts old bpf to new bpf insns.
Old sk_run_filter() is gone and replaced with bpf_run() that iterates
over new insns.
Here would need to make sure that all sk_run_filter() users (seccomp,
ppp, isdn, team)
are unaffected.
step 2:
use 'len' field of 'struct sock_fprog' to differentiate between old and new bpf.
len < 4096 -> old bpf insns, go to step 1
len > 4096 -> new bpf insns, verify them through new bpf_check()
and run them via the same new sk_run_filter()==bpf_run()
This way all current users of bpf can load new programs through the
same interfaces.
step 3:
replace bpf32_x86 jit with bpf64_jit.
step 4:
old filter attach interfaces do not allow the most interesting bpf64 programs
with bpf_tables (like the one for kernel tracing), extend them or add new
Initially I extended include/uapi/linux/filter.h, but then decided
it's too aggressive
to change uapi header and split it into include/linux/bpf.h instead.
It's definitely cleaner to have one. I guess with a comment that bpf64 insn set
may change, it should be ok. I'll go back to single filter.h
As far as making bpf64 interpreter to perform at bpf32 speeds on i386 and arm32,
I think I have to reconsider 32-bit subregs. Peter Anvin should be happy :)
If old bpf is like 8086, bpf64 with 32-bit subregs and 64-bit
registers is like x86-64 with x32.
Sounds like we're converging. What other stake holders have to say?
Thanks
Alexei
^ permalink raw reply
* Re: [PATCH] bonding: 802.3ad: make aggregator_identifier bond-private
From: Flavio Leitner @ 2014-02-14 19:12 UTC (permalink / raw)
To: Jiri Bohac; +Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, netdev
In-Reply-To: <20140214171350.GC11688@midget.suse.cz>
On Fri, Feb 14, 2014 at 06:13:50PM +0100, Jiri Bohac wrote:
> aggregator_identifier is used to assign unique aggregator identifiers
> to aggregators of a bond during device enslaving.
>
> aggregator_identifier is currently a global variable that is zeroed in
> bond_3ad_initialize().
>
> This sequence will lead to duplicate aggregator identifiers for eth1 and eth3:
>
> create bond0
> change bond0 mode to 802.3ad
> enslave eth0 to bond0 //eth0 gets agg id 1
> enslave eth1 to bond0 //eth1 gets agg id 2
> create bond1
> change bond1 mode to 802.3ad
> enslave eth2 to bond1 //aggregator_identifier is reset to 0
> //eth2 gets agg id 1
> enslave eth3 to bond0 //eth3 gets agg id 2
>
> Fix this by making aggregator_identifier private to the bond.
I don't see how you fix the duplicate agg id with this patch because
you initialize for each bond to 0, then use the same algo further on.
So, what is changing?
Actually, aggregator_identifier is a global variable to make sure the
counter is always increasing for new bonds. So, the fix would be to
not reset it to zero, isn't it?
Thanks,
fbl
> Signed-off-by: Jiri Bohac <jbohac@suse.cz>
> ---
> drivers/net/bonding/bond_3ad.c | 6 ++----
> drivers/net/bonding/bond_3ad.h | 1 +
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
> index 4ced594..dcf2ee8 100644
> --- a/drivers/net/bonding/bond_3ad.c
> +++ b/drivers/net/bonding/bond_3ad.c
> @@ -1806,8 +1806,6 @@ void bond_3ad_initiate_agg_selection(struct bonding *bond, int timeout)
> BOND_AD_INFO(bond).agg_select_timer = timeout;
> }
>
> -static u16 aggregator_identifier;
> -
> /**
> * bond_3ad_initialize - initialize a bond's 802.3ad parameters and structures
> * @bond: bonding struct to work on
> @@ -1821,7 +1819,7 @@ void bond_3ad_initialize(struct bonding *bond, u16 tick_resolution)
> if (MAC_ADDRESS_COMPARE(&(BOND_AD_INFO(bond).system.sys_mac_addr),
> bond->dev->dev_addr)) {
>
> - aggregator_identifier = 0;
> + BOND_AD_INFO(bond).aggregator_identifier = 0;
>
> BOND_AD_INFO(bond).system.sys_priority = 0xFFFF;
> BOND_AD_INFO(bond).system.sys_mac_addr = *((struct mac_addr *)bond->dev->dev_addr);
> @@ -1892,7 +1890,7 @@ int bond_3ad_bind_slave(struct slave *slave)
> ad_initialize_agg(aggregator);
>
> aggregator->aggregator_mac_address = *((struct mac_addr *)bond->dev->dev_addr);
> - aggregator->aggregator_identifier = (++aggregator_identifier);
> + aggregator->aggregator_identifier = ++BOND_AD_INFO(bond).aggregator_identifier;
> aggregator->slave = slave;
> aggregator->is_active = 0;
> aggregator->num_of_ports = 0;
> diff --git a/drivers/net/bonding/bond_3ad.h b/drivers/net/bonding/bond_3ad.h
> index 5d91ad0..1f081c8 100644
> --- a/drivers/net/bonding/bond_3ad.h
> +++ b/drivers/net/bonding/bond_3ad.h
> @@ -253,6 +253,7 @@ struct ad_system {
> struct ad_bond_info {
> struct ad_system system; /* 802.3ad system structure */
> u32 agg_select_timer; // Timer to select aggregator after all adapter's hand shakes
> + u16 aggregator_identifier;
> };
>
> struct ad_slave_info {
>
> --
> Jiri Bohac
> e-mail/jabber: jiri@boha.cz
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] net: usb: sr9800: Use '%zu' to print size_t format
From: David Miller @ 2014-02-14 18:59 UTC (permalink / raw)
To: fabio.estevam; +Cc: liujunliang_ljl, netdev
In-Reply-To: <1392384335-19707-1-git-send-email-fabio.estevam@freescale.com>
From: Fabio Estevam <fabio.estevam@freescale.com>
Date: Fri, 14 Feb 2014 11:25:35 -0200
> Fix the following build warning on ARM:
>
> drivers/net/usb/sr9800.c:826:2: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'size_t' [-Wformat]
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Already fixed in the 'net' tree, thanks.
^ permalink raw reply
* Re: [PATCH net] packet: check for ndo_select_queue during queue selection
From: David Miller @ 2014-02-14 18:48 UTC (permalink / raw)
To: dborkman; +Cc: mathias.kretschmer, netdev, brouer
In-Reply-To: <52FDEE22.9010503@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Fri, 14 Feb 2014 11:21:22 +0100
> The other two possibilities I see is 1) to check for
> dev->ieee80211_ptr on setsockopt(2) and bind(2) (which could happen
> _after_ the option was set) and just disallow that option for those
> cases (doesn't make sense to use it for ieee80211 devs anyway, and
> they seem to be the only special-cased users), or, preferably 2) to
> just leave the code as it currently is, that is, similar to pktgen.
Don't sell yourself so short, think out of the box:
typedef u16 (*select_queue_fallback_t)(struct net_device *dev, struct sk_buff *skb);
...
u16 (*ndo_select_queue)(struct net_device *dev, struct sk_buff *skb,
void *accel_priv, select_queue_fallback_t fallback);
And your packet code would do something like:
static u16 __packet_pick_tx_queue(struct net_device *dev, struct sk_buff *skb)
{
return (u16) raw_smp_processor_id() % dev->real_num_tx_queues;
}
static u16 packet_pick_tx_queue(struct net_device *dev, struct sk_buff *skb)
{
u16 queue_index;
if (ops->ndo_select_queue)
queue_index = ops->ndo_select_queue(dev, skb, NULL, __packet_pick_tx_queue);
else
queue_index = __packet_pick_tx_queue(dev, skb);
skb_set_queue_mapping(skb, queue_index);
}
Then you go through the existing ndo_select_queue implementations, you'll notice
a lot of them are of the form:
if (special_stuff)
queue_index = whatever;
else
queue_index = __netdev_pick_tx(...);
replace that __netdev_pick_tx call with one to "fallback".
^ permalink raw reply
* Re: [PATCH net-next] net: remove unnecessary return's
From: Dave Jones @ 2014-02-14 18:48 UTC (permalink / raw)
To: David Miller; +Cc: julia.lawall, joe, stephen, netdev
In-Reply-To: <20140214.134137.2289581685154413307.davem@davemloft.net>
On Fri, Feb 14, 2014 at 01:41:37PM -0500, David Miller wrote:
> From: Julia Lawall <julia.lawall@lip6.fr>
> Date: Fri, 14 Feb 2014 10:58:00 +0100 (CET)
>
> > On Thu, 13 Feb 2014, David Miller wrote:
> >
> >> I think it is valuable, it's so much easier to audit the return paths
> >> via a process of elimination with that kind of layout. A return in
> >> the middle of that looks out of place at best.
> >
> > Actually, I had a student who made a tool that went the other way around,
> > and introduced goto labels for sharable error handling code. We didn't
> > get around to using it to send patches, though. In that tool, we didn't
> > create labels just for returns, with the thought that in that case there
> > was no point to introduce a goto if there was nothing to share.
>
> That's one perspective.
>
> But think of it this way, if there is a seqeuence of labels already and
> you're scanning for a large body of code for control transfers during
> an audit, what are your eyes more likely to miss?
>
> A sequence goto statements targetting well named and distinct labels
> or that "return" hidding there somewhere in the middle?
No argument about 'in the middle', but the suggestion upthread was for
the very first case before there are any allocations etc that need unwinding.
Dave
^ permalink raw reply
* Re: [PATCH net-next] net: remove unnecessary return's
From: David Miller @ 2014-02-14 18:41 UTC (permalink / raw)
To: julia.lawall; +Cc: davej, joe, stephen, netdev
In-Reply-To: <alpine.DEB.2.10.1402141055270.2118@hadrien>
From: Julia Lawall <julia.lawall@lip6.fr>
Date: Fri, 14 Feb 2014 10:58:00 +0100 (CET)
> On Thu, 13 Feb 2014, David Miller wrote:
>
>> I think it is valuable, it's so much easier to audit the return paths
>> via a process of elimination with that kind of layout. A return in
>> the middle of that looks out of place at best.
>
> Actually, I had a student who made a tool that went the other way around,
> and introduced goto labels for sharable error handling code. We didn't
> get around to using it to send patches, though. In that tool, we didn't
> create labels just for returns, with the thought that in that case there
> was no point to introduce a goto if there was nothing to share.
That's one perspective.
But think of it this way, if there is a seqeuence of labels already and
you're scanning for a large body of code for control transfers during
an audit, what are your eyes more likely to miss?
A sequence goto statements targetting well named and distinct labels
or that "return" hidding there somewhere in the middle?
^ permalink raw reply
* Re: [PATCH v3 0/3] dp83640: Get pin and master/slave configuration from DT
From: David Miller @ 2014-02-14 18:36 UTC (permalink / raw)
To: richardcochran-Re5JQEeQqe8AvxtiuMwx3w
Cc: stefan.sorensen-usnHOLptxrsHrNJx0XZkJA,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140214090601.GA3906@netboy>
From: Richard Cochran <richardcochran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Fri, 14 Feb 2014 10:06:01 +0100
> People want to be able to configure the auxiliary functions on the
> pins of their PTP devices. My preference for supporting this is:
>
> 1. additional ioctl on the PTP character device
> 2. ethtool ioctl
> 3. DT and/or ACPI
>
> The first option seems best because that is how you activate the
> auxiliary functions. I am working on something in this direction.
Probably since PTP already uses ioctls, and that is the activation
point, yes that seems the best approach.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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
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