* 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 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-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: [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: [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: [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: [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 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: [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 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: 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 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-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 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 v3 net-next] net: bcmgenet: enable driver to work without a device tree
From: David Miller @ 2014-12-09 1:27 UTC (permalink / raw)
To: pgynther; +Cc: netdev, f.fainelli
In-Reply-To: <20141202001808.9B0E6220728@puck.mtv.corp.google.com>
From: Petri Gynther <pgynther@google.com>
Date: Mon, 1 Dec 2014 16:18:08 -0800 (PST)
> Modify bcmgenet driver so that it can be used on Broadcom 7xxx
> MIPS-based STB platforms without a device tree.
>
> Signed-off-by: Petri Gynther <pgynther@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] hyperv: Add support for vNIC hot removal
From: David Miller @ 2014-12-09 1:24 UTC (permalink / raw)
To: haiyangz; +Cc: olaf, netdev, jasowang, driverdev-devel, linux-kernel
In-Reply-To: <1417469319-7356-1-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Mon, 1 Dec 2014 13:28:39 -0800
> This patch adds proper handling of the vNIC hot removal event, which includes
> a rescind-channel-offer message from the host side that triggers vNIC close and
> removal. In this case, the notices to the host during close and removal is not
> necessary because the channel is rescinded. This patch blocks these unnecessary
> messages, and lets vNIC removal process complete normally.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] test: bpf: expand DIV_KX to DIV_MOD_KX
From: David Miller @ 2014-12-09 1:23 UTC (permalink / raw)
To: kda; +Cc: netdev, ast
In-Reply-To: <1417428745-20199-1-git-send-email-kda@linux-powerpc.org>
From: Denis Kirjanov <kda@linux-powerpc.org>
Date: Mon, 1 Dec 2014 13:12:25 +0300
> Expand DIV_KX to use BPF_MOD operation in the
> DIV_KX bpf 'classic' test.
>
> CC: Alexei Starovoitov <ast@plumgrid.com>
> Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] mips: bpf: Fix broken BPF_MOD
From: David Miller @ 2014-12-09 1:23 UTC (permalink / raw)
To: kda; +Cc: netdev, markos.chandras
In-Reply-To: <1417427822-12729-1-git-send-email-kda@linux-powerpc.org>
From: Denis Kirjanov <kda@linux-powerpc.org>
Date: Mon, 1 Dec 2014 12:57:02 +0300
> Remove optimize_div() from BPF_MOD | BPF_K case
> since we don't know the dividend and fix the
> emit_mod() by reading the mod operation result from HI register
>
> Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
Applied and queue up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/3] timestamping updates
From: David Miller @ 2014-12-09 1:21 UTC (permalink / raw)
To: willemb; +Cc: netdev, luto, richardcochran
In-Reply-To: <1417404155-28607-1-git-send-email-willemb@google.com>
From: Willem de Bruijn <willemb@google.com>
Date: Sun, 30 Nov 2014 22:22:32 -0500
> The main goal for this patchset is to allow correlating timestamps
> with the egress interface. Also introduce a warning, as discussed
> previously, and update the tests to verify the new feature.
Series applied, thanks.
^ permalink raw reply
* Re: [patch v2] ipvs: uninitialized data with IP_VS_IPV6
From: Simon Horman @ 2014-12-09 0:52 UTC (permalink / raw)
To: Julian Anastasov
Cc: Dan Carpenter, Wensong Zhang, Pablo Neira Ayuso, Patrick McHardy,
Jozsef Kadlecsik, David S. Miller, netdev, lvs-devel,
netfilter-devel, coreteam, kernel-janitors
In-Reply-To: <alpine.LFD.2.11.1412072032420.1885@ja.home.ssi.bg>
On Sun, Dec 07, 2014 at 08:39:35PM +0200, Julian Anastasov wrote:
>
> Hello,
>
> On Sat, 6 Dec 2014, Dan Carpenter wrote:
>
> > The app_tcp_pkt_out() function expects "*diff" to be set and ends up
> > using uninitialized data if CONFIG_IP_VS_IPV6 is turned on.
> >
> > The same issue is there in app_tcp_pkt_in(). Thanks to Julian Anastasov
> > for noticing that.
> >
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > ---
> > v2: fix app_tcp_pkt_in() as well. This is an old bug.
>
> Thanks! It will not break seqs for IPv6 control
> connection, only that we do not support FTP yet :( I have
> the doubt whether this should be classified as bugfix :)
> I guess, it is a net-next material, right?
Agreed, I have queued it up in ipvs-next.
I'll send a pull request to Pablo if Dan doesn't object
to it going there.
> Simon, please apply.
>
> Acked-by: Julian Anastasov <ja@ssi.bg>
>
> > diff --git a/net/netfilter/ipvs/ip_vs_ftp.c b/net/netfilter/ipvs/ip_vs_ftp.c
> > index 1d5341f..5d3daae 100644
> > --- a/net/netfilter/ipvs/ip_vs_ftp.c
> > +++ b/net/netfilter/ipvs/ip_vs_ftp.c
> > @@ -183,6 +183,8 @@ static int ip_vs_ftp_out(struct ip_vs_app *app, struct ip_vs_conn *cp,
> > struct nf_conn *ct;
> > struct net *net;
> >
> > + *diff = 0;
> > +
> > #ifdef CONFIG_IP_VS_IPV6
> > /* This application helper doesn't work with IPv6 yet,
> > * so turn this into a no-op for IPv6 packets
> > @@ -191,8 +193,6 @@ static int ip_vs_ftp_out(struct ip_vs_app *app, struct ip_vs_conn *cp,
> > return 1;
> > #endif
> >
> > - *diff = 0;
> > -
> > /* Only useful for established sessions */
> > if (cp->state != IP_VS_TCP_S_ESTABLISHED)
> > return 1;
> > @@ -322,6 +322,9 @@ static int ip_vs_ftp_in(struct ip_vs_app *app, struct ip_vs_conn *cp,
> > struct ip_vs_conn *n_cp;
> > struct net *net;
> >
> > + /* no diff required for incoming packets */
> > + *diff = 0;
> > +
> > #ifdef CONFIG_IP_VS_IPV6
> > /* This application helper doesn't work with IPv6 yet,
> > * so turn this into a no-op for IPv6 packets
> > @@ -330,9 +333,6 @@ static int ip_vs_ftp_in(struct ip_vs_app *app, struct ip_vs_conn *cp,
> > return 1;
> > #endif
> >
> > - /* no diff required for incoming packets */
> > - *diff = 0;
> > -
> > /* Only useful for established sessions */
> > if (cp->state != IP_VS_TCP_S_ESTABLISHED)
> > return 1;
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
>
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Ming Lei @ 2014-12-09 0:48 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Pali Rohár, Pavel Machek, John W. Linville,
Grazvydas Ignotas,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Network Development, Linux Kernel Mailing List, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <20141208205721.GA14895-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Tue, Dec 9, 2014 at 4:57 AM, Greg Kroah-Hartman
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.
>
> Use your own custom usermode helper for stuff like this, not the
> firmware interface. But use a binary sysfs file if you want, that seems
> to make sense for it...
It sounds like implementing an variant of request_firmware_user(), :-)
Thanks,
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: is the commit 571dcfde2371 (net-next) a proper fix?
From: David Miller @ 2014-12-09 0:35 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: chenhc, peppe.cavallaro, netdev
In-Reply-To: <1418034200.17201.45.camel@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Mon, 08 Dec 2014 12:23:20 +0200
> It seems for me that commit 571dcfde2371 (stmmac: platform: fix default
> values of the filter bins setting) is redundant (moreover, it could be a
> cause of crash in some cases when there is no platform data defined in
> case of CONFIG_OF).
>
> In case of no OF the platform data should be provided by platform code
> where the defaults are set. What did I miss?
You missed follow-up fix:
commit 28603d13997e2ef47f18589cc9a44553aad49c86
Author: Huacai Chen <chenhc@lemote.com>
Date: Thu Nov 27 21:05:34 2014 +0800
stmmac: platform: Move plat_dat checking earlier
^ permalink raw reply
* Nothing is better than you!
From: Jessica Kuku @ 2014-12-08 18:00 UTC (permalink / raw)
Hi Dear,
May peace be with you. I am Miss Jessica. Actually, We may not known in person but relationship can start like this!. Please, I'm sorry if I am embarrassing you by my gesture.
I really wish to be your friend, learn to know you and to have a place in your heart for an ideal relationship with us. I will be very happy if you contact me for my picture and more about me.
See you soon?
Thanks in advance and remain blessed!
Jessica
^ permalink raw reply
* [PATCH net-next] net: systemport: allow changing MAC address
From: Florian Fainelli @ 2014-12-08 23:59 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
Hook a ndo_set_mac_address callback, update the internal Ethernet MAC in
the netdevice structure, and finally write that address down to the
UniMAC registers. If the interface is down, and most likely clock gated,
we do not update the registers but just the local copy, such that next
ndo_open() call will effectively write down the address.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/broadcom/bcmsysport.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c
index c1d255972dae..a91a8c263391 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -1409,6 +1409,27 @@ static void topctrl_flush(struct bcm_sysport_priv *priv)
topctrl_writel(priv, 0, TX_FLUSH_CNTL);
}
+static int bcm_sysport_change_mac(struct net_device *dev, void *p)
+{
+ struct bcm_sysport_priv *priv = netdev_priv(dev);
+ struct sockaddr *addr = p;
+
+ if (!is_valid_ether_addr(addr->sa_data))
+ return -EINVAL;
+
+ memcpy(dev->dev_addr, addr->sa_data, dev->addr_len);
+
+ /* interface is disabled, changes to MAC will be reflected on next
+ * open call
+ */
+ if (!netif_running(dev))
+ return 0;
+
+ umac_set_hw_addr(priv, dev->dev_addr);
+
+ return 0;
+}
+
static void bcm_sysport_netif_start(struct net_device *dev)
{
struct bcm_sysport_priv *priv = netdev_priv(dev);
@@ -1628,6 +1649,7 @@ static const struct net_device_ops bcm_sysport_netdev_ops = {
.ndo_stop = bcm_sysport_stop,
.ndo_set_features = bcm_sysport_set_features,
.ndo_set_rx_mode = bcm_sysport_set_rx_mode,
+ .ndo_set_mac_address = bcm_sysport_change_mac,
};
#define REV_FMT "v%2x.%02x"
--
2.1.0
^ permalink raw reply related
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-12-08 23:52 UTC (permalink / raw)
To: Dan Williams
Cc: Marcel Holtmann, Greg Kroah-Hartman, Ming Lei, 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: <1418082137.31640.14.camel@dcbw.local>
[-- Attachment #1: Type: Text/Plain, Size: 973 bytes --]
On Tuesday 09 December 2014 00:42:17 Dan Williams wrote:
> On Tue, 2014-12-09 at 00:23 +0100, Pali Rohár wrote:
> > On Monday 08 December 2014 23:51:07 Dan Williams wrote:
> > > Is the CAL data format generic to all wl1251 devices? Or
> > > is the stuff in the CAL partition Nokia-specific?
> >
> > Specific for Nokia devices.
>
> Ok, but then something must transform that data into a format
> that the wl1251 chip can consume, correct? What do other
> wl1251 platforms do to retrieve this information and set
> regulatory region?
>
> Dan
It looks like wl1251 driver supports standard way to set
regulatory settings. There is application which reads CAL data,
cellular network info, ... and sent it to kernel (via Nokia
specific netlink interface patch). And binary data which are sent
are in same format as file wl1251-nvs.bin. And some bits which
deterministically send to kernl depends on fcc.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ 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