* Re: [PATCH V2 net-next] udp: Neaten and reduce size of compute_score functions
From: David Miller @ 2014-12-09 1:29 UTC (permalink / raw)
To: joe; +Cc: eric.dumazet, netdev, linux-kernel
In-Reply-To: <1417494546.4894.12.camel@perches.com>
From: Joe Perches <joe@perches.com>
Date: Mon, 01 Dec 2014 20:29:06 -0800
> The compute_score functions are a bit difficult to read.
>
> Neaten them a bit to reduce object sizes and make them a
> bit more intelligible.
>
> Return early to avoid indentation and avoid unnecessary
> initializations.
>
> (allyesconfig, but w/ -O2 and no profiling)
>
> $ size net/ipv[46]/udp.o.*
> text data bss dec hex filename
> 28680 1184 25 29889 74c1 net/ipv4/udp.o.new
> 28756 1184 25 29965 750d net/ipv4/udp.o.old
> 17600 1010 2 18612 48b4 net/ipv6/udp.o.new
> 17632 1010 2 18644 48d4 net/ipv6/udp.o.old
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied, thanks Joe.
^ permalink raw reply
* Re: [PATCH net-next 0/8] tipc: convert name table read-write lock to RCU
From: David Miller @ 2014-12-09 1:41 UTC (permalink / raw)
To: ying.xue
Cc: jon.maloy, Paul.Gortmaker, erik.hugne, richard.alpe, tero.aho,
netdev, tipc-discussion
In-Reply-To: <1417503630-31352-1-git-send-email-ying.xue@windriver.com>
From: Ying Xue <ying.xue@windriver.com>
Date: Tue, 2 Dec 2014 15:00:22 +0800
> Now TIPC name table is statically allocated and is protected with a
> Read-Write lock. To enhance the performance of TIPC name table lookup,
> we are going to involve RCU lock to protect the name table. As a
> consequence, it becomes lockless to concurrently look up name table on
> read side. However, before the conversion can be successfully made,
> the following two things must be first done:
>
> - change allocation way of name table from static to dynamic
> - fix several incorrect locking policy issues
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/2] r8169:change hardware setting
From: David Miller @ 2014-12-09 1:44 UTC (permalink / raw)
To: hau; +Cc: netdev, nic_swsd, linux-kernel
In-Reply-To: <1417510111-3568-1-git-send-email-hau@realtek.com>
From: Chunhao Lin <hau@realtek.com>
Date: Tue, 2 Dec 2014 16:48:29 +0800
> This patch series contains two hardware setting modification to prevent
> hardware become abnormal.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: mvneta: fix Tx interrupt delay
From: David Miller @ 2014-12-09 1:44 UTC (permalink / raw)
To: w
Cc: netdev, maggie.mae.roxas, thomas.petazzoni, gregory.clement,
ezequiel.garcia
In-Reply-To: <20141202071304.GA22512@1wt.eu>
From: Willy Tarreau <w@1wt.eu>
Date: Tue, 2 Dec 2014 08:13:04 +0100
> The mvneta driver sets the amount of Tx coalesce packets to 16 by
> default. Normally that does not cause any trouble since the driver
> uses a much larger Tx ring size (532 packets). But some sockets
> might run with very small buffers, much smaller than the equivalent
> of 16 packets. This is what ping is doing for example, by setting
> SNDBUF to 324 bytes rounded up to 2kB by the kernel.
>
> The problem is that there is no documented method to force a specific
> packet to emit an interrupt (eg: the last of the ring) nor is it
> possible to make the NIC emit an interrupt after a given delay.
>
> In this case, it causes trouble, because when ping sends packets over
> its raw socket, the few first packets leave the system, and the first
> 15 packets will be emitted without an IRQ being generated, so without
> the skbs being freed. And since the socket's buffer is small, there's
> no way to reach that amount of packets, and the ping ends up with
> "send: no buffer available" after sending 6 packets. Running with 3
> instances of ping in parallel is enough to hide the problem, because
> with 6 packets per instance, that's 18 packets total, which is enough
> to grant a Tx interrupt before all are sent.
>
> The original driver in the LSP kernel worked around this design flaw
> by using a software timer to clean up the Tx descriptors. This timer
> was slow and caused terrible network performance on some Tx-bound
> workloads (such as routing) but was enough to make tools like ping
> work correctly.
>
> Instead here, we simply set the packet counts before interrupt to 1.
> This ensures that each packet sent will produce an interrupt. NAPI
> takes care of coalescing interrupts since the interrupt is disabled
> once generated.
>
> No measurable performance impact nor CPU usage were observed on small
> nor large packets, including when saturating the link on Tx, and this
> fixes tools like ping which rely on too small a send buffer. If one
> wants to increase this value for certain workloads where it is safe
> to do so, "ethtool -C $dev tx-frames" will override this default
> setting.
>
> This fix needs to be applied to stable kernels starting with 3.10.
>
> Tested-By: Maggie Mae Roxas <maggie.mae.roxas@gmail.com>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] rtnetlink: delay RTM_DELLINK notification until after ndo_uninit()
From: David Miller @ 2014-12-09 1:44 UTC (permalink / raw)
To: tgraf; +Cc: maheshb, netdev, edumazet, roopa, makita.toshiaki
In-Reply-To: <20141202100746.GA13717@casper.infradead.org>
From: Thomas Graf <tgraf@suug.ch>
Date: Tue, 2 Dec 2014 10:07:46 +0000
> I think it would be cleaner to introduce a new function, for example
> rtmsg_ifinfo_build_skb() which is called from rtmsg_ifinfo(). The
> single caller that requires delayed sending can use the build skb
> function directly and then send it off.
+1
^ permalink raw reply
* Re: [PATCH net-next 0/9] mlx5 driver updates
From: David Miller @ 2014-12-09 1:46 UTC (permalink / raw)
To: eli-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb
Cc: roland-DgEjT+Ai2ygdnm+yROfE0A, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, ogerlitz-VPRAkNaXOzVWk0Htik3J/w,
amirv-VPRAkNaXOzVWk0Htik3J/w, eli-VPRAkNaXOzVWk0Htik3J/w
In-Reply-To: <1417515979-22418-1-git-send-email-eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
From: Eli Cohen <eli-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
Date: Tue, 2 Dec 2014 12:26:10 +0200
> The following series contains some fixes to mlx5 as well as update to the list
> of supported devices.
Series applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 0/6] net: Add helper for padding short Ethernet frames
From: David Miller @ 2014-12-09 1:48 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev
In-Reply-To: <20141203161440.9223.39633.stgit@ahduyck-vm-fedora20>
From: Alexander Duyck <alexander.h.duyck@redhat.com>
Date: Wed, 03 Dec 2014 08:17:26 -0800
> This patch series adds a pair of helpers to pad short Ethernet frames. The
> general idea is to clean up a number of code paths that were all writing
> their own versions of the same or similar function.
>
> An added advantage is that this will help to discourage introducing new
> bugs as in at least one case I found the skb->len had been updated, but the
> tail pointer update was overlooked.
>
> v2: Added skb_put_padto for cases where length is not ETH_ZLEN
> Updated intel drivers and emulex driver to use skb_put_padto
> Updated eth_skb_pad to use skb_put_padto
Series applied, thanks Alex.
^ permalink raw reply
* Re: [net-next v2 00/16][pull request] Intel Wired LAN Driver Updates 2014-12-06
From: David Miller @ 2014-12-09 1:50 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <1417870933-17248-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sat, 6 Dec 2014 05:01:57 -0800
> This series contains updates to i40e and i40evf.
Pulled, thanks Jeff.
Please take into consideration Joe Perches's feedback to use static
inlines instead of macros.
Thanks.
^ permalink raw reply
* Re: [patch net-next 0/6] net_sched: cls_*: couple of fixes
From: David Miller @ 2014-12-09 1:53 UTC (permalink / raw)
To: jiri; +Cc: netdev, jhs
In-Reply-To: <1417539636-12710-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 2 Dec 2014 18:00:30 +0100
> Jiri Pirko (6):
> net_sched: cls_basic: remove unnecessary iteration and use passed arg
> net_sched: cls_bpf: remove unnecessary iteration and use passed arg
> net_sched: cls_bpf: remove faulty use of list_for_each_entry_rcu
> net_sched: cls_flow: remove faulty use of list_for_each_entry_rcu
> net_sched: cls_flow: remove duplicate assignments
> net_sched: cls_cgroup: remove unnecessary if
Series applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH] net: mvneta: fix race condition in mvneta_tx()
From: David Miller @ 2014-12-09 1:55 UTC (permalink / raw)
To: w
Cc: eric.dumazet, netdev, maggie.mae.roxas, thomas.petazzoni,
gregory.clement, ezequiel.garcia
In-Reply-To: <20141202124043.GB16347@1wt.eu>
From: Willy Tarreau <w@1wt.eu>
Date: Tue, 2 Dec 2014 13:40:43 +0100
> On Tue, Dec 02, 2014 at 04:37:15AM -0800, Eric Dumazet wrote:
>> On Tue, 2014-12-02 at 04:30 -0800, Eric Dumazet wrote:
>> > From: Eric Dumazet <edumazet@google.com>
>> >
>> > mvneta_tx() dereferences skb to get skb->len too late,
>> > as hardware might have completed the transmit and TX completion
>> > could have freed the skb from another cpu.
>> >
>> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>>
>>
>>
>> For completeness, this bug was added in linux-3.14 and seems a stable
>> candidate.
>>
>> Fixes: 71f6d1b31fb1 ("net: mvneta: replace Tx timer with a real interrupt")
>
> Absolutely, we backported this one back to 3.10.
Applied, and queued up for -stable, thanks everyone.
^ permalink raw reply
* Re: [RFC][PATCHES] iov_iter.c rewrite
From: Al Viro @ 2014-12-09 1:56 UTC (permalink / raw)
To: Linus Torvalds
Cc: Kirill A. Shutemov, Linux Kernel Mailing List, linux-fsdevel,
Network Development
In-Reply-To: <20141208192816.GH22149@ZenIV.linux.org.uk>
On Mon, Dec 08, 2014 at 07:28:17PM +0000, Al Viro wrote:
> On Mon, Dec 08, 2014 at 10:57:31AM -0800, Linus Torvalds wrote:
> > So the whole "get_page()" thing is broken. Iterating over pages in a
> > KVEC is simply wrong, wrong, wrong. It needs to fail.
>
> Well, _that_ is easy to do, of course... E.g. by replacing that thing in
> iov_iter_get_pages()/iov_iter_get_pages_alloc() with ({ return -EFAULT; })
> will do it.
OK, folded and pushed (i.e. in vfs.git#iov_iter and vfs.git#for-next).
Matches earlier behaviour; oops reproducer is easy -
dd if=/dev/zero of=foo.ko bs=4096 count=1
cat >a.c <<'EOF'
#define _GNU_SOURCE
#include <unistd.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <sys/syscall.h>
main()
{
int fd = open("foo.ko", 00040000);
syscall(__NR_finit_module, fd, "", 0);
}
EOF
gcc a.c
strace ./a.out
Correct behaviour (both the mainline and this series with fixes folded):
open("foo.ko", O_RDONLY|O_DIRECT) = 3
finit_module(3, "", 0) = -1 EFAULT (Bad address)
Incorrect one:
open("foo.ko", O_RDONLY|O_DIRECT) = 3
finit_module(3, "", 0 <unfinished ...>
+++ killed by SIGKILL +++
Killed
with that oops reproduced. Not sure if it's a proper LTP or xfstests fodder,
but anyway, here it is.
Incremental from previous for-next is
diff --git a/mm/iov_iter.c b/mm/iov_iter.c
index e0605c1..a1599ca 100644
--- a/mm/iov_iter.c
+++ b/mm/iov_iter.c
@@ -560,15 +560,7 @@ ssize_t iov_iter_get_pages(struct iov_iter *i,
get_page(*pages = v.bv_page);
return v.bv_len;
}),({
- unsigned long addr = (unsigned long)v.iov_base, end;
- size_t len = v.iov_len + (*start = addr & (PAGE_SIZE - 1));
-
- if (len > maxpages * PAGE_SIZE)
- len = maxpages * PAGE_SIZE;
- addr &= ~(PAGE_SIZE - 1);
- for (end = addr + len; addr < end; addr += PAGE_SIZE)
- get_page(*pages++ = virt_to_page(addr));
- return len - *start;
+ return -EFAULT;
})
)
return 0;
@@ -622,18 +614,7 @@ ssize_t iov_iter_get_pages_alloc(struct iov_iter *i,
get_page(*p = v.bv_page);
return v.bv_len;
}),({
- unsigned long addr = (unsigned long)v.iov_base, end;
- size_t len = v.iov_len + (*start = addr & (PAGE_SIZE - 1));
- int n;
-
- addr &= ~(PAGE_SIZE - 1);
- n = DIV_ROUND_UP(len, PAGE_SIZE);
- *pages = p = get_pages_array(n);
- if (!p)
- return -ENOMEM;
- for (end = addr + len; addr < end; addr += PAGE_SIZE)
- get_page(*p++ = virt_to_page(addr));
- return len - *start;
+ return -EFAULT;
})
)
return 0;
^ permalink raw reply related
* Re: [net-next v2 00/16][pull request] Intel Wired LAN Driver Updates 2014-12-06
From: Jeff Kirsher @ 2014-12-09 2:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20141208.205031.1761143065244503062.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 451 bytes --]
On Mon, 2014-12-08 at 20:50 -0500, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Sat, 6 Dec 2014 05:01:57 -0800
>
> > This series contains updates to i40e and i40evf.
>
> Pulled, thanks Jeff.
>
> Please take into consideration Joe Perches's feedback to use static
> inlines instead of macros.
>
> Thanks.
Thanks, already on-top of it. It should be in the next round of "fixes"
I submit upstream.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next V3 0/2] ethtool, net/mlx4_en: RSS hash function selection
From: David Miller @ 2014-12-09 2:07 UTC (permalink / raw)
To: amirv; +Cc: ben, netdev, ogerlitz, eyalpe, yevgenyp
In-Reply-To: <1417536731-11211-1-git-send-email-amirv@mellanox.com>
From: Amir Vadai <amirv@mellanox.com>
Date: Tue, 2 Dec 2014 18:12:09 +0200
> This patchset by Eyal adds support in set/get of RSS hash function. Current
> supported functions are Toeplitz and XOR. The API is design to enable adding
> new hash functions without breaking backward compatibility.
> Userspace patch will be sent after API is available in kernel.
>
> The patchset was applied and tested over commit cd4c910 ("netpoll: delete
> defconfig references to obsolete NETPOLL_TRAP")
Series applied, thanks.
^ permalink raw reply
* Re: [net PATCH] fib_trie: Fix /proc/net/fib_trie when CONFIG_IP_MULTIPLE_TABLES is not defined
From: David Miller @ 2014-12-09 2:14 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev
In-Reply-To: <20141202185238.1540.48554.stgit@ahduyck-vm-fedora20>
From: Alexander Duyck <alexander.h.duyck@redhat.com>
Date: Tue, 02 Dec 2014 10:58:21 -0800
> In recent testing I had disabled CONFIG_IP_MULTIPLE_TABLES and as a result
> when I ran "cat /proc/net/fib_trie" the main trie was displayed multiple
> times. I found that the problem line of code was in the function
> fib_trie_seq_next. Specifically the line below caused the indexes to go in
> the opposite direction of our traversal:
>
> h = tb->tb_id & (FIB_TABLE_HASHSZ - 1);
>
> This issue was that the RT tables are defined such that RT_TABLE_LOCAL is ID
> 255, while it is located at TABLE_LOCAL_INDEX of 0, and RT_TABLE_MAIN is 254
> with a TABLE_MAIN_INDEX of 1. This means that the above line will return 1
> for the local table and 0 for main. The result is that fib_trie_seq_next
> will return NULL at the end of the local table, fib_trie_seq_start will
> return the start of the main table, and then fib_trie_seq_next will loop on
> main forever as h will always return 0.
>
> The fix for this is to reverse the ordering of the two tables. It has the
> advantage of making it so that the tables now print in the same order
> regardless of if multiple tables are enabled or not. In order to make the
> definition consistent with the multiple tables case I simply masked the to
> RT_TABLE_XXX values by (FIB_TABLE_HASHSZ - 1). This way the two table
> layouts should always stay consistent.
>
> Fixes: 93456b6 ("[IPV4]: Unify access to the routing tables")
> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH net-next 0/6] sunvnet: add SG, HW_CSUM, GSO, and TSO support
From: David Miller @ 2014-12-09 2:19 UTC (permalink / raw)
To: david.stevens; +Cc: netdev, sowmini.varadhan
In-Reply-To: <547E216F.4000307@oracle.com>
From: David L Stevens <david.stevens@oracle.com>
Date: Tue, 02 Dec 2014 15:30:39 -0500
> This patch set adds everything needed for TSO support in sunvnet. On my
> test hardware, this increases the single-stream TCP throughput for the
> default 1500-byte MTU Linux-Linux from ~2Gbps to 10Gbps and Linux-Solaris
> from ~2Gbps to 6Gbps.
Looks great, series applied, thanks!
^ permalink raw reply
* net-next merge window closure
From: Jeff Kirsher @ 2014-12-09 2:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 530 bytes --]
With Linus releasing 3.18, and you parsing through the 100+ patches
currently in the queue getting net-next ready to push to Linus for 3.19,
I have a request/question. I have 13 more i40e patches I was hoping to
submit to net-next before the closure (it was twelve until Joe's last
suggestion). I can get them submitted later tonight, but if it is going
to cause to much of an issue, I can wait for net-next to open later this
month.
Just wanted to check with you before dumping more patches onto your work
load. :-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [RFC][PATCHES] iov_iter.c rewrite
From: Kirill A. Shutemov @ 2014-12-09 2:21 UTC (permalink / raw)
To: Al Viro
Cc: Linus Torvalds, Linux Kernel Mailing List, linux-fsdevel,
Network Development
In-Reply-To: <20141209015651.GI22149@ZenIV.linux.org.uk>
On Tue, Dec 09, 2014 at 01:56:51AM +0000, Al Viro wrote:
> On Mon, Dec 08, 2014 at 07:28:17PM +0000, Al Viro wrote:
> > On Mon, Dec 08, 2014 at 10:57:31AM -0800, Linus Torvalds wrote:
> > > So the whole "get_page()" thing is broken. Iterating over pages in a
> > > KVEC is simply wrong, wrong, wrong. It needs to fail.
> >
> > Well, _that_ is easy to do, of course... E.g. by replacing that thing in
> > iov_iter_get_pages()/iov_iter_get_pages_alloc() with ({ return -EFAULT; })
> > will do it.
>
> OK, folded and pushed (i.e. in vfs.git#iov_iter and vfs.git#for-next).
> Matches earlier behaviour; oops reproducer is easy -
>
> dd if=/dev/zero of=foo.ko bs=4096 count=1
> cat >a.c <<'EOF'
> #define _GNU_SOURCE
> #include <unistd.h>
> #include <fcntl.h>
> #include <sys/stat.h>
> #include <sys/syscall.h>
> main()
> {
> int fd = open("foo.ko", 00040000);
> syscall(__NR_finit_module, fd, "", 0);
> }
> EOF
> gcc a.c
> strace ./a.out
>
> Correct behaviour (both the mainline and this series with fixes folded):
> open("foo.ko", O_RDONLY|O_DIRECT) = 3
> finit_module(3, "", 0) = -1 EFAULT (Bad address)
> Incorrect one:
> open("foo.ko", O_RDONLY|O_DIRECT) = 3
> finit_module(3, "", 0 <unfinished ...>
> +++ killed by SIGKILL +++
> Killed
>
> with that oops reproduced. Not sure if it's a proper LTP or xfstests fodder,
> but anyway, here it is.
>
> Incremental from previous for-next is
Works for me.
--
Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH net-next] net: bcmgenet: add support for Rx priority queues
From: David Miller @ 2014-12-09 2:22 UTC (permalink / raw)
To: f.fainelli; +Cc: pgynther, netdev
In-Reply-To: <547E3192.4080400@gmail.com>
Florian, whilst your feedback is very valuable, you are causing incredible
headaches for me every time you quote an entire patch like this.
Please use your email client properly and edit out all except the most
pertinent quoted material when reviewing patches.
Every time someone quotes the whole patch, I have to scroll through the
entire patch that many times to read people's feedback in patchwork.
Thanks!
^ permalink raw reply
* Re: pull request (net-next): ipsec-next 2014-12-03
From: David Miller @ 2014-12-09 2:30 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <1417601101-18625-1-git-send-email-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Wed, 3 Dec 2014 11:04:56 +0100
> 1) Fix a set but not used warning. From Fabian Frederick.
>
> 2) Currently we make sequence number values available to userspace
> only if we use ESN. Make the sequence number values also available
> for non ESN states. From Zhi Ding.
>
> 3) Remove socket policy hashing. We don't need it because socket
> policies are always looked up via a linked list. From Herbert Xu.
>
> 4) After removing socket policy hashing, we can use __xfrm_policy_link
> in xfrm_policy_insert. From Herbert Xu.
>
> 5) Add a lookup method for vti6 tunnels with wildcard endpoints.
> I forgot this when I initially implemented vti6.
>
> Please pull or let me know if there are problems.
Pulled, thanks a lot Steffen.
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] net: bcmgenet: support for new GPHY revision scheme
From: David Miller @ 2014-12-09 2:33 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev
In-Reply-To: <1417629420-31146-1-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 3 Dec 2014 09:56:58 -0800
> These two patches update the GENET GPHY revision logic to account for some
> of our newer designs starting with GPHY rev G0.
Series applied, thanks.
^ permalink raw reply
* [PATCH net-next] sunvnet: fix incorrect rcu_read_unlock() in vnet_start_xmit()
From: David L Stevens @ 2014-12-09 2:46 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sowmini Varadhan, Rashmi Narasimhan
This patch removes an extra rcu_read_unlock() on an allocation failure
in vnet_skb_shape(). The needed rcu_read_unlock() is already done in
the out_dropped label.
Reported-by: Rashmi Narasimhan <rashmi.narasimhan@oracle.com>
Signed-off-by: David L Stevens <david.stevens@oracle.com>
---
drivers/net/ethernet/sun/sunvnet.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/sun/sunvnet.c b/drivers/net/ethernet/sun/sunvnet.c
index b883add..36fdf52 100644
--- a/drivers/net/ethernet/sun/sunvnet.c
+++ b/drivers/net/ethernet/sun/sunvnet.c
@@ -1317,10 +1317,8 @@ static int vnet_start_xmit(struct sk_buff *skb, struct net_device *dev)
skb = vnet_skb_shape(skb, 2);
- if (unlikely(!skb)) {
- rcu_read_unlock();
+ if (unlikely(!skb))
goto out_dropped;
- }
if (skb->ip_summed == CHECKSUM_PARTIAL)
vnet_fullcsum(skb);
--
1.7.1
^ permalink raw reply related
* Re: net-next merge window closure
From: David Miller @ 2014-12-09 2:54 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev
In-Reply-To: <1418091638.2410.21.camel@jtkirshe-mobl>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 08 Dec 2014 18:20:38 -0800
> With Linus releasing 3.18, and you parsing through the 100+ patches
> currently in the queue getting net-next ready to push to Linus for 3.19,
> I have a request/question. I have 13 more i40e patches I was hoping to
> submit to net-next before the closure (it was twelve until Joe's last
> suggestion). I can get them submitted later tonight, but if it is going
> to cause to much of an issue, I can wait for net-next to open later this
> month.
>
> Just wanted to check with you before dumping more patches onto your work
> load. :-)
Just send it in, it'll be noise in the backlog I'll be processing today
and tomorrow.
Thanks for asking.
^ permalink raw reply
* Re: [PATCH net-next] sunvnet: fix incorrect rcu_read_unlock() in vnet_start_xmit()
From: David Miller @ 2014-12-09 2:55 UTC (permalink / raw)
To: david.stevens; +Cc: netdev, sowmini.varadhan, rashmi.narasimhan
In-Reply-To: <54866271.1020005@oracle.com>
From: David L Stevens <david.stevens@oracle.com>
Date: Mon, 08 Dec 2014 21:46:09 -0500
> This patch removes an extra rcu_read_unlock() on an allocation failure
> in vnet_skb_shape(). The needed rcu_read_unlock() is already done in
> the out_dropped label.
>
> Reported-by: Rashmi Narasimhan <rashmi.narasimhan@oracle.com>
> Signed-off-by: David L Stevens <david.stevens@oracle.com>
Applied, thanks.
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Greg Kroah-Hartman @ 2014-12-09 4:08 UTC (permalink / raw)
To: Ming Lei
Cc: Pali Rohár, Pavel Machek, John W. Linville,
Grazvydas Ignotas, linux-wireless@vger.kernel.org,
Network Development, Linux Kernel Mailing List, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <CACVXFVO+pX29UE53EDP4va0hoWQw8h0E9Ji9t3OL=e0FyERxyA@mail.gmail.com>
On Tue, Dec 09, 2014 at 08:48:28AM +0800, Ming Lei wrote:
> On Tue, Dec 9, 2014 at 4:57 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Mon, Dec 08, 2014 at 05:47:30PM +0100, Pali Rohár wrote:
> >> On Monday 08 December 2014 17:37:14 Greg Kroah-Hartman wrote:
> >> > On Mon, Dec 08, 2014 at 11:18:18PM +0800, Ming Lei wrote:
> >> > > On Sat, Dec 6, 2014 at 9:02 PM, Pali Rohár
> >> <pali.rohar@gmail.com> wrote:
> >> > > > On Saturday 06 December 2014 13:49:54 Pavel Machek wrote:
> >> > > > /**
> >> > > >
> >> > > > + * request_firmware_prefer_user: - prefer usermode helper
> >> > > > for loading firmware + * @firmware_p: pointer to firmware
> >> > > > image
> >> > > > + * @name: name of firmware file
> >> > > > + * @device: device for which firmware is being loaded
> >> > > > + *
> >> > > > + * This function works pretty much like
> >> > > > request_firmware(), but it prefer + * usermode helper. If
> >> > > > usermode helper fails then it fallback to direct access.
> >> > > > + * Usefull for dynamic or model specific firmware data.
> >> > > > + **/
> >> > > > +int request_firmware_prefer_user(const struct firmware
> >> > > > **firmware_p, + const char
> >> > > > *name, struct device *device) +{
> >> > > > + int ret;
> >> > > > + __module_get(THIS_MODULE);
> >> > > > + ret = _request_firmware(firmware_p, name, device,
> >> > > > + FW_OPT_UEVENT |
> >> > > > FW_OPT_PREFER_USER); + module_put(THIS_MODULE);
> >> > > > + return ret;
> >> > > > +}
> >> > > > +EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
> >> > >
> >> > > I'd like to introduce request_firmware_user() which only
> >> > > requests firmware from user space, and this way is simpler
> >> > > and more flexible since we have request_firmware_direct()
> >> > > already.
> >> >
> >> > Why would a driver care about what program provides the
> >> > firmware? It shouldn't at all, and we want to get rid of the
> >> > userspace firmware loader, not encourage drivers to use it
> >> > "exclusively" at all.
> >> >
> >>
> >> Do not remove it! Without userspace firmware loader it is
> >> impossible to load dynamic firmware files.
> >
> > You should not be loading "dynamic" firmware files with the firmware
> > interface, as that's not a "firmware" file anymore, it's a "special
> > binary file that my driver needs to be created and sent into the
> > kernel."
>
> It is reasonable to put firmware somewhere instead of default
> search path, maybe in network.
That's why we allow you to change the firmware search path at build
time, and kernel boot time (or firmware class module load time.) To do
this on a per-firmware-file basis is crazy.
thanks,
greg k-h
^ permalink raw reply
* RE: TO WHOM IT MAY CONCERN!!!
From: Mr. Stephen Odufore @ 2014-12-09 11:44 UTC (permalink / raw)
Hello
My Name is Mr. Stephen Odufore, A staff of Sunrise Bank Team, and an account officer to Engineer Shang Lee Sukchai(Late) It might interest you to know that engineer Shang Lee Sukchai is a Gold Merchant here in Ghana and he deposited a large sum of money with Sunrise Bank Team (Ghana).
On one faithful Wednesday, 7 November 2012, We received a shocking news that Melcom building at Achimota-Accra COLLAPSED and that 78 persons were rescued from the rubble. Out of this figure ten persons are reported DEAD, 14 on admission at 37 Military Hospital as well as Achimota, and the Korle-Bu Teaching Hospitals. for more information visit the TWO links below:
http://edition.myjoyonline.com/pages/news/201211/96847.php
http://edition.myjoyonline.com/pages/news/201211/96960.php
Based on the information reaching us, Engineer Shang Lee Sukchai with his house hold (Wife, son and 2 daughters) died in the accident and left this large sum of money behind. Apparently, the management are seriously searching for any of his relative to claim this money so I want you to stand as a relative to the decease and once the funds are paid to you, I will visit you in your country so we can share the money.
I can assure you that this deal is 100% risk-free, and if you follow my advice we will succeed within the shortest possible time. All I need is your assurance that you are solvent and capable of handling a transaction of this magnitude, and that our share of the money will be safe with you.
The money is going to be shared among THREE parties and it's going to be in this way, 10% of the money will go to the orphanage in your country, another 10% to the widow and widowers association, 30% for your good work and cooperation whilst the remaining 50% goes to me and my colleague who is in support of this transaction.
If you are interested in this business, then send your Full name, House address, direct contact number for easy communication. Remember, this transaction most be kept strictly Confidential hence my job will e astake
Yours Faithfully
Mr. Stephen Odufore
^ 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