* Re: [PATCH net-next v2 0/5] bonding: patchset for rcu use in bonding
From: David Miller @ 2013-10-28 4:00 UTC (permalink / raw)
To: vfalico; +Cc: dingtianhong, fubar, andy, nikolay, netdev
In-Reply-To: <20131027221027.GA11209@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Sun, 27 Oct 2013 23:10:27 +0100
> On Sun, Oct 27, 2013 at 05:44:58PM -0400, David Miller wrote:
>>I would have preferred that he did all of this in the initial 0/N
>>patch posting, but I can't defer forever.
>
> Maybe I'm too picky. Anyway - understood, thanks.
I'm happy to revert his changes if you find real problems with them,
but I'd rather you two work more closely together in the future so I
don't have to break the deadlock like I did this time.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] bonding: patchset for rcu use in bonding
From: David Miller @ 2013-10-28 4:01 UTC (permalink / raw)
To: vfalico; +Cc: dingtianhong, fubar, andy, nikolay, netdev
In-Reply-To: <20131027225317.GB11209@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Sun, 27 Oct 2013 23:53:17 +0100
> This patch introduces a regression by boot-test with active backup
> mode:
Ok I'm reverting.
^ permalink raw reply
* Re: [PATCH v2] pkt_sched: fq: clear time_next_packet for reused flows
From: David Miller @ 2013-10-28 4:19 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1382916403.4045.17.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 27 Oct 2013 16:26:43 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> When a socket is freed/reallocated, we need to clear time_next_packet
> or else we can inherit a prior value and delay first packets of the
> new flow.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2013-10-28 4:23 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Somnath Kotur, Sathya Perla
[-- Attachment #1: Type: text/plain, Size: 4320 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/emulex/benet/be.h between commit e9e2a904ef0a
("be2net: Warn users of possible broken functionality on BE2 cards with
very old FW versions with latest driver") from the net tree and commit
6384a4d0dcf9 ("be2net: add support for ndo_busy_poll") from the net-next
tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/ethernet/emulex/benet/be.h
index c99dac6a9ddf,b2765ebb0268..000000000000
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@@ -696,23 -733,114 +733,123 @@@ static inline int qnq_async_evt_rcvd(st
return adapter->flags & BE_FLAGS_QNQ_ASYNC_EVT_RCVD;
}
+static inline int fw_major_num(const char *fw_ver)
+{
+ int fw_major = 0;
+
+ sscanf(fw_ver, "%d.", &fw_major);
+
+ return fw_major;
+}
+
- extern void be_cq_notify(struct be_adapter *adapter, u16 qid, bool arm,
- u16 num_popped);
- extern void be_link_status_update(struct be_adapter *adapter, u8 link_status);
- extern void be_parse_stats(struct be_adapter *adapter);
- extern int be_load_fw(struct be_adapter *adapter, u8 *func);
- extern bool be_is_wol_supported(struct be_adapter *adapter);
- extern bool be_pause_supported(struct be_adapter *adapter);
- extern u32 be_get_fw_log_level(struct be_adapter *adapter);
+ #ifdef CONFIG_NET_RX_BUSY_POLL
+ static inline bool be_lock_napi(struct be_eq_obj *eqo)
+ {
+ bool status = true;
+
+ spin_lock(&eqo->lock); /* BH is already disabled */
+ if (eqo->state & BE_EQ_LOCKED) {
+ WARN_ON(eqo->state & BE_EQ_NAPI);
+ eqo->state |= BE_EQ_NAPI_YIELD;
+ status = false;
+ } else {
+ eqo->state = BE_EQ_NAPI;
+ }
+ spin_unlock(&eqo->lock);
+ return status;
+ }
+
+ static inline void be_unlock_napi(struct be_eq_obj *eqo)
+ {
+ spin_lock(&eqo->lock); /* BH is already disabled */
+
+ WARN_ON(eqo->state & (BE_EQ_POLL | BE_EQ_NAPI_YIELD));
+ eqo->state = BE_EQ_IDLE;
+
+ spin_unlock(&eqo->lock);
+ }
+
+ static inline bool be_lock_busy_poll(struct be_eq_obj *eqo)
+ {
+ bool status = true;
+
+ spin_lock_bh(&eqo->lock);
+ if (eqo->state & BE_EQ_LOCKED) {
+ eqo->state |= BE_EQ_POLL_YIELD;
+ status = false;
+ } else {
+ eqo->state |= BE_EQ_POLL;
+ }
+ spin_unlock_bh(&eqo->lock);
+ return status;
+ }
+
+ static inline void be_unlock_busy_poll(struct be_eq_obj *eqo)
+ {
+ spin_lock_bh(&eqo->lock);
+
+ WARN_ON(eqo->state & (BE_EQ_NAPI));
+ eqo->state = BE_EQ_IDLE;
+
+ spin_unlock_bh(&eqo->lock);
+ }
+
+ static inline void be_enable_busy_poll(struct be_eq_obj *eqo)
+ {
+ spin_lock_init(&eqo->lock);
+ eqo->state = BE_EQ_IDLE;
+ }
+
+ static inline void be_disable_busy_poll(struct be_eq_obj *eqo)
+ {
+ local_bh_disable();
+
+ /* It's enough to just acquire napi lock on the eqo to stop
+ * be_busy_poll() from processing any queueus.
+ */
+ while (!be_lock_napi(eqo))
+ mdelay(1);
+
+ local_bh_enable();
+ }
+
+ #else /* CONFIG_NET_RX_BUSY_POLL */
+
+ static inline bool be_lock_napi(struct be_eq_obj *eqo)
+ {
+ return true;
+ }
+
+ static inline void be_unlock_napi(struct be_eq_obj *eqo)
+ {
+ }
+
+ static inline bool be_lock_busy_poll(struct be_eq_obj *eqo)
+ {
+ return false;
+ }
+
+ static inline void be_unlock_busy_poll(struct be_eq_obj *eqo)
+ {
+ }
+
+ static inline void be_enable_busy_poll(struct be_eq_obj *eqo)
+ {
+ }
+
+ static inline void be_disable_busy_poll(struct be_eq_obj *eqo)
+ {
+ }
+ #endif /* CONFIG_NET_RX_BUSY_POLL */
+
+ void be_cq_notify(struct be_adapter *adapter, u16 qid, bool arm,
+ u16 num_popped);
+ void be_link_status_update(struct be_adapter *adapter, u8 link_status);
+ void be_parse_stats(struct be_adapter *adapter);
+ int be_load_fw(struct be_adapter *adapter, u8 *func);
+ bool be_is_wol_supported(struct be_adapter *adapter);
+ bool be_pause_supported(struct be_adapter *adapter);
+ u32 be_get_fw_log_level(struct be_adapter *adapter);
int be_update_queues(struct be_adapter *adapter);
int be_poll(struct napi_struct *napi, int budget);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] inet: restore gso for vxlan
From: David Miller @ 2013-10-28 4:25 UTC (permalink / raw)
To: eric.dumazet; +Cc: ast, netdev
In-Reply-To: <1382923096.13037.10.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 27 Oct 2013 18:18:16 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Alexei reported a performance regression on vxlan, caused
> by commit 3347c9602955 "ipv4: gso: make inet_gso_segment() stackable"
>
> GSO vxlan packets were not properly segmented, adding IP fragments
> while they were not expected.
>
> Rename 'bool tunnel' to 'bool encap', and add a new boolean
> to express the fact that UDP should be fragmented.
> This fragmentation is triggered by skb->encapsulation being set.
>
> Remove a "skb->encapsulation = 1" added in above commit,
> as its not needed, as frags inherit skb->frag from original
> GSO skb.
>
> Reported-by: Alexei Starovoitov <ast@plumgrid.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Tested-by: Alexei Starovoitov <ast@plumgrid.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 2/8] farsync: Fix confusion about DMA address and buffer offset types
From: David Miller @ 2013-10-28 4:26 UTC (permalink / raw)
To: ben; +Cc: kevin.curtis, linux-kernel, netdev
In-Reply-To: <1382910704.2994.46.camel@deadeye.wl.decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sun, 27 Oct 2013 21:51:44 +0000
> - dbg(DBG_TX, "In fst_tx_dma %p %p %d\n", skb, mem, len);
> + dbg(DBG_TX, "In fst_tx_dma %x %x %d\n", (u32)skb, mem, len);
Please use %p for the skb pointer instead of casting it (which btw
will introduce a warning on 64-bit).
^ permalink raw reply
* Re: [PATCH 7/8] rds: Pass pointers to virt_to_page(), not integers
From: David Miller @ 2013-10-28 4:26 UTC (permalink / raw)
To: ben; +Cc: venkat.x.venkatsubra, linux-kernel, rds-devel, netdev
In-Reply-To: <1382910856.2994.51.camel@deadeye.wl.decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sun, 27 Oct 2013 21:54:16 +0000
> Most architectures define virt_to_page() as a macro that casts its
> argument such that an argument of type unsigned long will be accepted
> without complaint. However, the proper type is void *, and passing
> unsigned long results in a warning on MIPS.
>
> Compile-tested only.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
This looks fine:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 1/3] vxlan: silence one build warning
From: David Miller @ 2013-10-28 4:38 UTC (permalink / raw)
To: stephen; +Cc: zwu.kernel, netdev, linux-kernel, wuzhy
In-Reply-To: <20131025084134.6cfa153a@samsung-9>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Fri, 25 Oct 2013 08:41:34 -0700
> I would rather not fix the warning this way since it risks masking
> later bugs if this code ever changes.
But this is suboptimally coded, and is asking for the warning.
Anything returning a pointer by reference is asking for trouble
in my opinion.
The correct thing to do is to make create_v{4,6}_sock() return
the "struct socket *" as an error pointer.
No more ambiguous initializations, no more warnings.
^ permalink raw reply
* Re: [PATCH 2/3] net, datagram: fix the uncorrect comment in zerocopy_sg_from_iovec()
From: David Miller @ 2013-10-28 4:39 UTC (permalink / raw)
To: zwu.kernel; +Cc: netdev, linux-kernel, wuzhy
In-Reply-To: <1382687360-27794-2-git-send-email-zwu.kernel@gmail.com>
"uncorrect" is not a word, you mean to say "incorrect".
Same goes for patch #3.
^ permalink raw reply
* Re: Big performance loss from 3.4.63 to 3.10.13 when routing ipv4
From: David Miller @ 2013-10-28 4:43 UTC (permalink / raw)
To: steffen.klassert; +Cc: eric.dumazet, linux, hannes, netdev, klassert
In-Reply-To: <20131025092043.GD31491@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Fri, 25 Oct 2013 11:20:43 +0200
> On Fri, Oct 25, 2013 at 01:50:28AM -0700, Eric Dumazet wrote:
>>
>> 32768 as the default seems fine to me
>>
>> 448 bytes per dst -> thats less than 30 Mbytes of memory if we hit 65536
>> dst.
>>
>
> Ok, I'll add the patch below to to the ipsec tree if everyone is fine
> with that threshold.
No objections from me.
^ permalink raw reply
* Re: [PATCH 2/8] farsync: Fix confusion about DMA address and buffer offset types
From: Ben Hutchings @ 2013-10-28 4:51 UTC (permalink / raw)
To: David Miller; +Cc: kevin.curtis, linux-kernel, netdev
In-Reply-To: <20131028.002627.2095063739326406659.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 743 bytes --]
On Mon, 2013-10-28 at 00:26 -0400, David Miller wrote:
> From: Ben Hutchings <ben@decadent.org.uk>
> Date: Sun, 27 Oct 2013 21:51:44 +0000
>
> > - dbg(DBG_TX, "In fst_tx_dma %p %p %d\n", skb, mem, len);
> > + dbg(DBG_TX, "In fst_tx_dma %x %x %d\n", (u32)skb, mem, len);
>
> Please use %p for the skb pointer instead of casting it (which btw
> will introduce a warning on 64-bit).
skb is the DMA address of the data in the sk_buff. Yes, this is really
unusual naming.
Ben.
--
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had thought.
... I realized that a large part of my life from then on was going to be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] veth: extend features to support tunneling
From: David Miller @ 2013-10-28 4:58 UTC (permalink / raw)
To: eric.dumazet; +Cc: ast, edumazet, stephen, netdev
In-Reply-To: <1382750703.4032.32.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 25 Oct 2013 18:25:03 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> While investigating on a recent vxlan regression, I found veth
> was using a zero features set for vxlan tunnels.
>
> We have to segment GSO frames, copy the payload, and do the checksum.
>
> This patch brings a ~200% performance increase
>
> We probably have to add hw_enc_features support
> on other virtual devices.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next] tcp: gso: fix truesize tracking
From: David Miller @ 2013-10-28 4:58 UTC (permalink / raw)
To: eric.dumazet; +Cc: ast, edumazet, stephen, netdev
In-Reply-To: <1382747177.4032.21.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 25 Oct 2013 17:26:17 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> commit 6ff50cd55545 ("tcp: gso: do not generate out of order packets")
> had an heuristic that can trigger a warning in skb_try_coalesce(),
> because skb->truesize of the gso segments were exactly set to mss.
>
> This breaks the requirement that
>
> skb->truesize >= skb->len + truesizeof(struct sk_buff);
>
> It can trivially be reproduced by :
>
> ifconfig lo mtu 1500
> ethtool -K lo tso off
> netperf
>
> As the skbs are looped into the TCP networking stack, skb_try_coalesce()
> warns us of these skb under-estimating their truesize.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Alexei Starovoitov <ast@plumgrid.com>
> ---
> Based on net-next but applies as well on net tree with some fuzz.
>
> David, we might backport this one to 3.12 and stable later, I let you
> decide.
I'm still thinking about what to do with this one.
^ permalink raw reply
* Re: [PATCH 2/8] farsync: Fix confusion about DMA address and buffer offset types
From: David Miller @ 2013-10-28 4:59 UTC (permalink / raw)
To: ben; +Cc: kevin.curtis, linux-kernel, netdev
In-Reply-To: <1382935885.3524.38.camel@deadeye.wl.decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Mon, 28 Oct 2013 04:51:25 +0000
> On Mon, 2013-10-28 at 00:26 -0400, David Miller wrote:
>> From: Ben Hutchings <ben@decadent.org.uk>
>> Date: Sun, 27 Oct 2013 21:51:44 +0000
>>
>> > - dbg(DBG_TX, "In fst_tx_dma %p %p %d\n", skb, mem, len);
>> > + dbg(DBG_TX, "In fst_tx_dma %x %x %d\n", (u32)skb, mem, len);
>>
>> Please use %p for the skb pointer instead of casting it (which btw
>> will introduce a warning on 64-bit).
>
> skb is the DMA address of the data in the sk_buff. Yes, this is really
> unusual naming.
Hmmm, Ok then I guess. :-/
^ permalink raw reply
* Re: [PATCH v2 0/3] sctp: do some clean up and fix comments
From: David Miller @ 2013-10-28 5:02 UTC (permalink / raw)
To: wangweidong1; +Cc: nhorman, vyasevich, dingtianhong, linux-sctp, netdev
In-Reply-To: <1382774792-13440-1-git-send-email-wangweidong1@huawei.com>
From: Wang Weidong <wangweidong1@huawei.com>
Date: Sat, 26 Oct 2013 16:06:29 +0800
> This patch series includes some comments fix, merge tow if-statements,
> remove the repeat initialize with 0.
>
> v1 -> v2:
> - patch1: combine two comment typos fix patches into one,
> as suggested by Vlad, and add his ACK.
> - patch2: add Vlad's ACK.
> - patch3: line up 2 parts of 'if' statements, as suggested by Vlad.
> fix some comment typos, as suggested by Sergei.
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next 2/3] tipc: message reassembly using fragment chain
From: David Miller @ 2013-10-28 5:07 UTC (permalink / raw)
To: jon.maloy; +Cc: netdev, tipc-discussion
In-Reply-To: <1382812863-23571-3-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Sat, 26 Oct 2013 14:41:02 -0400
> + int ret = tipc_link_recv_fragment(
> + &node->bclink.reasm_head,
> + &node->bclink.reasm_tail,
> + &buf);
This is not the correct way to indent a function call that spans
multiple lines. In such a situation the arguments that appear
on the second and subsequent lines must start at the first column
after the openning parenthesis of the function call.
Like this:
func(a, b, c,
d, e, f);
Please audit this in your entire set of patches and resubmit,
thanks.
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
^ permalink raw reply
* Re: [virtio-net] BUG: sleeping function called from invalid context at kernel/mutex.c:616
From: Jason Wang @ 2013-10-28 5:44 UTC (permalink / raw)
To: Fengguang Wu; +Cc: netdev, linux-kernel, virtualization
In-Reply-To: <20131023232033.GA7404@localhost>
On 10/24/2013 07:20 AM, Fengguang Wu wrote:
> Yes it reduces the sleeping function bug:
>
> /kernel/x86_64-lkp-CONFIG_SCSI_DEBUG/7c4ed2767afb813493b0a8fb18d666cd44550963
>
> +------------------------------------------------------------------------------------+-----------+--------------+--------------+
> | | v3.12-rc3 | 3ab098df35f8 | 7c4ed2767afb |
> +------------------------------------------------------------------------------------+-----------+--------------+--------------+
> | good_boots | 30 | 0 | 93 |
> | has_kernel_error_warning | 0 | 20 | 7 |
> | BUG:sleeping_function_called_from_invalid_context_at_kernel/mutex.c | 0 | 20 | |
> | INFO:rcu_sched_self-detected_stall_on_CPU(t=jiffies_g=c=q=) | 0 | 0 | 1 |
> | INFO:task_blocked_for_more_than_seconds | 0 | 0 | 2 |
> | INFO:NMI_handler(arch_trigger_all_cpu_backtrace_handler)took_too_long_to_run:msecs | 0 | 0 | 1 |
> | Kernel_panic-not_syncing:hung_task:blocked_tasks | 0 | 0 | 1 |
> | BUG:kernel_test_crashed | 0 | 0 | 3 |
> | BUG:kernel_test_hang | 0 | 0 | 1 |
> +------------------------------------------------------------------------------------+-----------+--------------+--------------+
>
> However I'll need to increase tests on v3.12-rc3 to make sure it's not
> the patch that added the other error messages.
>
> Thanks,
> Fengguang
Thanks, any more update on the result of v3.12-rc3 for this?
^ permalink raw reply
* Re: [PATCH 01/16] mac80211: fix TX device statistics for monitor interfaces
From: Kalle Valo @ 2013-10-28 5:53 UTC (permalink / raw)
To: Pali Rohár
Cc: Luciano Coelho, John W. Linville, Johannes Berg, David S. Miller,
linux-wireless, netdev, linux-kernel, freemangordon,
aaro.koskinen, pavel, sre, joni.lapilainen, David Gnedt
In-Reply-To: <1382819655-30430-2-git-send-email-pali.rohar@gmail.com>
Pali Rohár <pali.rohar@gmail.com> writes:
> From: David Gnedt <david.gnedt@davizone.at>
>
> Count TX packets and bytes also for monitor interfaces.
>
> Signed-of-by: David Gnedt <david.gnedt@davizone.at>
You should send mac80211 patches separately, not inside a wl1251 patchset.
--
Kalle Valo
^ permalink raw reply
* [PATCH v2 1/3] vxlan: silence one build warning
From: Zhi Yong Wu @ 2013-10-28 6:01 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, stephen, davem, Zhi Yong Wu
From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
drivers/net/vxlan.c: In function ‘vxlan_sock_add’:
drivers/net/vxlan.c:2298:11: warning: ‘sock’ may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/net/vxlan.c:2275:17: note: ‘sock’ was declared here
LD drivers/net/built-in.o
Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
---
drivers/net/vxlan.c | 31 ++++++++++++++-----------------
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 2ef5b62..019e1f4 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2180,7 +2180,7 @@ static void vxlan_del_work(struct work_struct *work)
* could be used for both IPv4 and IPv6 communications, but
* users may set bindv6only=1.
*/
-static int create_v6_sock(struct net *net, __be16 port, struct socket **psock)
+static struct socket *create_v6_sock(struct net *net, __be16 port)
{
struct sock *sk;
struct socket *sock;
@@ -2193,7 +2193,7 @@ static int create_v6_sock(struct net *net, __be16 port, struct socket **psock)
rc = sock_create_kern(AF_INET6, SOCK_DGRAM, IPPROTO_UDP, &sock);
if (rc < 0) {
pr_debug("UDPv6 socket create failed\n");
- return rc;
+ return ERR_PTR(rc);
}
/* Put in proper namespace */
@@ -2208,28 +2208,27 @@ static int create_v6_sock(struct net *net, __be16 port, struct socket **psock)
pr_debug("bind for UDPv6 socket %pI6:%u (%d)\n",
&vxlan_addr.sin6_addr, ntohs(vxlan_addr.sin6_port), rc);
sk_release_kernel(sk);
- return rc;
+ return ERR_PTR(rc);
}
/* At this point, IPv6 module should have been loaded in
* sock_create_kern().
*/
BUG_ON(!ipv6_stub);
- *psock = sock;
/* Disable multicast loopback */
inet_sk(sk)->mc_loop = 0;
- return 0;
+ return sock;
}
#else
-static int create_v6_sock(struct net *net, __be16 port, struct socket **psock)
+static struct socket *create_v6_sock(struct net *net, __be16 port)
{
- return -EPFNOSUPPORT;
+ return ERR_PTR(-EPFNOSUPPORT);
}
#endif
-static int create_v4_sock(struct net *net, __be16 port, struct socket **psock)
+static struct socket *create_v4_sock(struct net *net, __be16 port)
{
struct sock *sk;
struct socket *sock;
@@ -2244,7 +2243,7 @@ static int create_v4_sock(struct net *net, __be16 port, struct socket **psock)
rc = sock_create_kern(AF_INET, SOCK_DGRAM, IPPROTO_UDP, &sock);
if (rc < 0) {
pr_debug("UDP socket create failed\n");
- return rc;
+ return ERR_PTR(rc);
}
/* Put in proper namespace */
@@ -2257,13 +2256,12 @@ static int create_v4_sock(struct net *net, __be16 port, struct socket **psock)
pr_debug("bind for UDP socket %pI4:%u (%d)\n",
&vxlan_addr.sin_addr, ntohs(vxlan_addr.sin_port), rc);
sk_release_kernel(sk);
- return rc;
+ return ERR_PTR(rc);
}
- *psock = sock;
/* Disable multicast loopback */
inet_sk(sk)->mc_loop = 0;
- return 0;
+ return sock;
}
/* Create new listen socket if needed */
@@ -2274,7 +2272,6 @@ static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port,
struct vxlan_sock *vs;
struct socket *sock;
struct sock *sk;
- int rc = 0;
unsigned int h;
vs = kmalloc(sizeof(*vs), GFP_KERNEL);
@@ -2287,12 +2284,12 @@ static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port,
INIT_WORK(&vs->del_work, vxlan_del_work);
if (ipv6)
- rc = create_v6_sock(net, port, &sock);
+ sock = create_v6_sock(net, port);
else
- rc = create_v4_sock(net, port, &sock);
- if (rc < 0) {
+ sock = create_v4_sock(net, port);
+ if (IS_ERR(sock)) {
kfree(vs);
- return ERR_PTR(rc);
+ return ERR_PTR(PTR_ERR(sock));
}
vs->sock = sock;
--
1.7.11.7
^ permalink raw reply related
* [PATCH v2 2/3] net, datagram: fix the incorrect comment in zerocopy_sg_from_iovec()
From: Zhi Yong Wu @ 2013-10-28 6:01 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, stephen, davem, Zhi Yong Wu
In-Reply-To: <1382940110-10737-1-git-send-email-zwu.kernel@gmail.com>
From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
---
net/core/datagram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/datagram.c b/net/core/datagram.c
index af814e7..a16ed7b 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -577,7 +577,7 @@ EXPORT_SYMBOL(skb_copy_datagram_from_iovec);
/**
* zerocopy_sg_from_iovec - Build a zerocopy datagram from an iovec
* @skb: buffer to copy
- * @from: io vector to copy to
+ * @from: io vector to copy from
* @offset: offset in the io vector to start copying from
* @count: amount of vectors to copy to buffer from
*
--
1.7.11.7
^ permalink raw reply related
* [PATCH v2 3/3] net, iovec: fix the incorrect comment in memcpy_fromiovecend()
From: Zhi Yong Wu @ 2013-10-28 6:01 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, stephen, davem, Zhi Yong Wu
In-Reply-To: <1382940110-10737-1-git-send-email-zwu.kernel@gmail.com>
From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
---
net/core/iovec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/iovec.c b/net/core/iovec.c
index b77eeec..4cdb7c4 100644
--- a/net/core/iovec.c
+++ b/net/core/iovec.c
@@ -100,7 +100,7 @@ int memcpy_toiovecend(const struct iovec *iov, unsigned char *kdata,
EXPORT_SYMBOL(memcpy_toiovecend);
/*
- * Copy iovec from kernel. Returns -EFAULT on error.
+ * Copy iovec to kernel. Returns -EFAULT on error.
*/
int memcpy_fromiovecend(unsigned char *kdata, const struct iovec *iov,
--
1.7.11.7
^ permalink raw reply related
* Re: Big performance loss from 3.4.63 to 3.10.13 when routing ipv4
From: Eric Dumazet @ 2013-10-28 6:17 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Wolfgang Walter, David Miller, hannes, netdev, klassert
In-Reply-To: <20131025092043.GD31491@secunet.com>
On Fri, 2013-10-25 at 11:20 +0200, Steffen Klassert wrote:
> On Fri, Oct 25, 2013 at 01:50:28AM -0700, Eric Dumazet wrote:
> >
> > 32768 as the default seems fine to me
> >
> > 448 bytes per dst -> thats less than 30 Mbytes of memory if we hit 65536
> > dst.
> >
>
> Ok, I'll add the patch below to to the ipsec tree if everyone is fine
> with that threshold.
>
> Subject: [PATCH RFC] xfrm: Increase the garbage collector threshold
>
> With the removal of the routing cache, we lost the
> option to tweak the garbage collector threshold
> along with the maximum routing cache size. So git
> commit 703fb94ec ("xfrm: Fix the gc threshold value
> for ipv4") moved back to a static threshold.
>
> It turned out that the current threshold before we
> start garbage collecting is much to small for some
> workloads, so increase it from 1024 to 32768. This
> means that we start the garbage collector if we have
> more than 32768 dst entries in the system and refuse
> new allocations if we are above 65536.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
> ---
Sure please add :
Reported-by: Wolfgang Walter <linux@stwm.de>
Thanks !
^ permalink raw reply
* Re: [Xen-devel] [PATCH net] xen-netback: use jiffies_64 value to calculate credit timeout
From: jianhai luan @ 2013-10-28 6:28 UTC (permalink / raw)
To: annie li, Wei Liu; +Cc: Ian Campbell, netdev, xen-devel, david.vrabel, jbeulich
In-Reply-To: <526DD2D8.5030405@oracle.com>
On 2013-10-28 10:58, annie li wrote:
>
> On 2013-10-28 10:36, annie li wrote:
>>
>> On 2013-10-27 19:11, Wei Liu wrote:
>>> time_after_eq() only works if the delta is < MAX_ULONG/2.
>>>
>>> For a 32bit Dom0, if netfront sends packets at a very low rate, the
>>> time
>>> between subsequent calls to tx_credit_exceeded() may exceed MAX_ULONG/2
>>> and the test for timer_after_eq() will be incorrect. Credit will not be
>>> replenished and the guest may become unable to send packets (e.g., if
>>> prior to the long gap, all credit was exhausted).
>>>
>>> Use jiffies_64 variant to mitigate this problem for 32bit Dom0.
>>>
>>> Suggested-by: Jan Beulich <jbeulich@suse.com>
>>> Suggested-by: David Vrabel <david.vrabel@citrix.com>
>>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>>> Cc: Ian Campbell <ian.campbell@citrix.com>
>>> Cc: Jason Luan <jianhai.luan@oracle.com>
>>> ---
>>> drivers/net/xen-netback/common.h | 1 +
>>> drivers/net/xen-netback/interface.c | 4 ++--
>>> drivers/net/xen-netback/netback.c | 13 ++++++-------
>>> 3 files changed, 9 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/net/xen-netback/common.h
>>> b/drivers/net/xen-netback/common.h
>>> index 5715318..400fea1 100644
>>> --- a/drivers/net/xen-netback/common.h
>>> +++ b/drivers/net/xen-netback/common.h
>>> @@ -163,6 +163,7 @@ struct xenvif {
>>> unsigned long credit_usec;
>>> unsigned long remaining_credit;
>>> struct timer_list credit_timeout;
>>> + u64 credit_window_start;
>>> /* Statistics */
>>> unsigned long rx_gso_checksum_fixup;
>>> diff --git a/drivers/net/xen-netback/interface.c
>>> b/drivers/net/xen-netback/interface.c
>>> index 01bb854..8c45b63 100644
>>> --- a/drivers/net/xen-netback/interface.c
>>> +++ b/drivers/net/xen-netback/interface.c
>>> @@ -312,8 +312,8 @@ struct xenvif *xenvif_alloc(struct device
>>> *parent, domid_t domid,
>>> vif->credit_bytes = vif->remaining_credit = ~0UL;
>>> vif->credit_usec = 0UL;
>>> init_timer(&vif->credit_timeout);
>>> - /* Initialize 'expires' now: it's used to track the credit
>>> window. */
>>> - vif->credit_timeout.expires = jiffies;
>>> + /* credit window is tracked in credit_window_start */
>>> + vif->credit_window_start = get_jiffies_64();
>>> dev->netdev_ops = &xenvif_netdev_ops;
>>> dev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO;
>>> diff --git a/drivers/net/xen-netback/netback.c
>>> b/drivers/net/xen-netback/netback.c
>>> index f3e591c..1bc0688 100644
>>> --- a/drivers/net/xen-netback/netback.c
>>> +++ b/drivers/net/xen-netback/netback.c
>>> @@ -1185,18 +1185,17 @@ out:
>>> static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
>>> {
>>> - unsigned long now = jiffies;
>>> - unsigned long next_credit =
>>> - vif->credit_timeout.expires +
>>> - msecs_to_jiffies(vif->credit_usec / 1000);
>>> + u64 now = get_jiffies_64();
>>> + u64 next_credit = vif->credit_window_start +
>>> + (u64)msecs_to_jiffies(vif->credit_usec / 1000);
>>
>> You simply replace "credit_timeout.expires" with
>> "vif->credit_window_start" here, and never update
>> "vif->credit_window_start" in following code.
>>
>>> /* Timer could already be pending in rare cases. */
>>> if (timer_pending(&vif->credit_timeout))
>>> return true;
>>> /* Passed the point where we can replenish credit? */
>>> - if (time_after_eq(now, next_credit)) {
>>> - vif->credit_timeout.expires = now;
>>> + if (time_after_eq64(now, next_credit)) {
>>> + vif->credit_timeout.expires = (unsigned long)now;
>>
>> updates credit_window_start as following,
>> vif->credit_window_start = (unsigned long)now;
>
> both credit_window_start and credit_timeout.expires need to be updated
> here,
>
> vif->credit_window_start = (unsigned long)now;
> vif->credit_timeout.expires = (unsigned long)now;
Annie should be correct.
It is good to me but i afraid that get_jiffies_64() and
time_after_eq64() will bring some performance's load when transmit is
busy in 32bit. I will do some test about the patch.
No matter what, i prefer own patch.
Thanks,
Jason
>
>>
>>> tx_add_credit(vif);
>>> }
>>> @@ -1207,7 +1206,7 @@ static bool tx_credit_exceeded(struct xenvif
>>> *vif, unsigned size)
>>> vif->credit_timeout.function =
>>> tx_credit_callback;
>>> mod_timer(&vif->credit_timeout,
>>> - next_credit);
>>> + (unsigned long)next_credit);
>>
>> vif->credit_timeout.expires is unsigned long, and this still causes
>> original issue on 32bit system, which works well on 64bit. Or
>> rewriting code to avoid uses of vif->credit_timeout.expires, but it
>> is complex.
> My understanding here is wrong, please ignore this.
>
> Thanks
> Annie
^ permalink raw reply
* Re: [PATCH 4/4] wl1251: spi: add device tree support
From: Kumar Gala @ 2013-10-28 6:37 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sebastian Reichel, Luciano Coelho, Rob Herring, Pawel Moll,
Mark Rutland, Stephen Warren, Ian Campbell, Rob Landley,
Tony Lindgren, Russell King, John W. Linville, Felipe Balbi,
Sachin Kamat, Greg Kroah-Hartman, Bill Pemberton, devicetree,
linux-doc, linux-kernel, linux-omap, linux-arm-kernel,
linux-wireless, netdev
In-Reply-To: <1382890469-25286-5-git-send-email-sre@debian.org>
On Oct 27, 2013, at 11:14 AM, Sebastian Reichel wrote:
> Add device tree support for the spi variant of wl1251
> and document the binding.
>
> Signed-off-by: Sebastian Reichel <sre@debian.org>
> ---
> .../devicetree/bindings/net/wireless/ti,wl1251.txt | 36 ++++++++++++++++++++++
> drivers/net/wireless/ti/wl1251/spi.c | 23 ++++++++++----
> 2 files changed, 53 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
> new file mode 100644
> index 0000000..5f8a154
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
> @@ -0,0 +1,36 @@
> +* Texas Instruments wl1251 controller
> +
> +The wl1251 chip can be connected via SPI or via SDIO. The linux
> +kernel currently only supports device tree for the SPI variant.
> +
>From the binding I have no idea what this chip actually does, also we don't normally reference linux kernel support in bindings specs (so please remove it).
However, what would expect the SDIO binding to look like? Or more specifically, how would you distinguish the SPI vs SDIO binding/connection? I'm wondering if the compatible should be something like "ti,wl1251-spi" and than the sdio can be "ti,wl1251-sdio"
> +Required properties:
> +- compatible : Should be "ti,wl1251"
reg is not listed as a required prop.
> +- interrupts : Should contain interrupt line
> +- interrupt-parent : Should be the phandle for the interrupt
> + controller that services interrupts for this device
> +- vio-supply : phandle to regulator providing VIO
> +- power-gpio : GPIO connected to chip's PMEN pin
should be vendor prefixed: ti,power-gpio
> +- For additional required properties on SPI, please consult
> + Documentation/devicetree/bindings/spi/spi-bus.txt
> +
> +Optional properties:
> +- ti,use-eeprom : If found, configuration will be loaded from eeprom.
can you be a bit more specific on what cfg will be loaded. Also, is this property a boolean, if so how do I know which eeprom the cfg is loaded from (is it one that is directly connected to the wl1251?
> +
> +Examples:
> +
> +&spi1 {
> + wl1251_spi@0 {
> + compatible = "ti,wl1251";
> +
> + reg = <0>;
> + spi-max-frequency = <48000000>;
> + spi-cpol;
> + spi-cpha;
> +
> + interrupt-parent = <&gpio2>;
> + interrupts = <10 IRQ_TYPE_NONE>; /* gpio line 42 */
> +
> + vio-supply = <&vio>;
> + power-gpio = <&gpio3 23 GPIO_ACTIVE_HIGH>; /* 87 */
> + };
> +};
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH] pkt_sched: fq: clear time_next_packet for reused flows
From: Vijay Subramanian @ 2013-10-28 7:02 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1382916945.4045.22.camel@edumazet-glaptop.roam.corp.google.com>
>>
>
> What exact RB corruptions do you see ?
>
> RB trees allow items with the same key.
>
Thanks for the clarification. I incorrectly thought duplicates are not allowed.
Sorry for the noise.
Vijay
^ 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