* 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
* Re: wl1251: NVS firmware data
From: Marcel Holtmann @ 2014-12-09 5:10 UTC (permalink / raw)
To: Dan Williams
Cc: Ivaylo Dimitrov, Pali Rohár, Greg Kroah-Hartman, Ming Lei,
Pavel Machek, John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Aaro Koskinen, Kalle Valo,
Sebastian Reichel, David Gnedt
In-Reply-To: <1418078493.31640.4.camel@dcbw.local>
Hi Dan,
>>> a) change driver to prefer a new "wl1251-nvs-n900.bin" file, but fall
>>> back to "wl1251-nvs.bin" if the first one isn't present
>>> b) have a "wl1251-cal-nvs-update" service that, if wl1521-nvs-n900.bin
>>> is *not* present mounts the CAL MTD, reads the data, writes it out into
>>> wl1521-nvs-n900.bin, and the rmmod/modprobes the driver
>>>
>>> and done? Stuff that's not N900 just wouldn't ship the update service
>>> and would proceed like none of this happened.
>>>
>>> Dan
>>>
>>>
>>
>> That would mean that the driver should not be built-in, as afaik we
>> cannot rmmod built-in drivers. Sure, it will work after a reboot, but
>> this is a bit hacky, agree?
>>
>> Also, new NVS file needs to be loaded when fcc regulation changes(flying
>> abroad), so that would mean that the device would be outside of those
>> until reboot (in case of built-in driver)
>
> Regulatory stuff needs to be hooked into CRDA or the existing regulatory
> codepaths, not some other path. So when cfg80211 sets the regulatory
> domain on the driver the driver needs to get the necessary NVS data.
> Either the NVS for every domain (which cannot be a lot of them) gets
> hardcoded into the driver, and then selected based on what cfg80211
> says, or the driver needs to ask userspace for the NVS data based on
> what cfg80211 says. In all cases, cfg80211 drives the regulatory domain
> [1].
>
> a) How many regulatory domains does the driver support, how much data is
> there for each domain, and can that be put into the driver instead of
> getting it from the CAL partition?
>
> b) what do *other* (non-N900) wl1251 devices do for regulatory data?
>
> Dan
>
> [1] unless there's some *restriction* hardcoded into the EEPROM of the
> device, which in the case of the N900 there isn't, since the regulatory
> data changes based on the MCC/MNC of the cellular side.
and even these ones would all work just fine. The regulatory handling of cfg80211 is already multi-layer anyway. I will intersect from the driver provided information and userspace provided information.
I mean if userspace can just make up some NVS data to change the regulatory enforcement or let cfg80211 do it for you, there is no difference. So the real question is why bother with this at all in the first place. We already have a solution that does exactly what you want. Use CRDA and be done with it.
And calibration data should be rather static for each device. It might differ from device a to device b, but on device a it would stay the same. These calibration data are normally programmed at the factory line and then never changed again.
For me this sounds all a bit like that everybody is buying into this NVS file solution for everything and now trying to hack that into something workable. But nobody actually looks at the existing solutions out there and really tries to fix the mess that Nokia and TI left behind for this chipset.
Regards
Marcel
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Marcel Holtmann @ 2014-12-09 5:25 UTC (permalink / raw)
To: Pali Rohár
Cc: 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: <201412090027.46485@pali>
Hi Pali,
>> 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...
>>
>> greg k-h
>
> Patch for telling permanent mac address from userspace via sysfs
> file was rejected for inclusion into mainline kernel.
>
> So I do not think that now maintainers of network subsystem allow
> it for nvs data...
>
> https://lkml.org/lkml/2013/12/8/35
this magic sysfs that has to be written to at the right time of the boot process to make this all work is something that will not work. I does not work for WiFi and it does not work for Bluetooth. Seems the discussion come full circle now and we are back to square one.
The problem is that either the driver does not register the device with mac80211 until it gets the MAC address provided by userspace or mac80211 should get an unconfigured state. The unconfigured state is something telling userspace that the device is present, but needs a few extra configuration information before it can become useful.
For Bluetooth, I went the later route. Mainly because the missing address is such a generic problem that solving it in the core makes a lot more sense. The driver just tells the core that it has no address for this device and provides a custom callback to configure the address when provided. After that everything resumes as normal.
However userspace gets informed when an unconfigured device gets added and at boot it can just query the list of unconfigured devices, or at runtime wait to be told there is a new unconfigured device that needs its attention. And then just provide the information. Once all information are present, the devices disappears as unconfigured and shows up as configured device ready for normal operation.
https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/mgmt-api.txt#n2006
http://permalink.gmane.org/gmane.linux.bluez.kernel/50716
Can something similar be added to cfg80211 + nl80211. It bet it can, but that is up to Johannes to decide and someone to actually do the work and implement it.
Regards
Marcel
^ permalink raw reply
* Re: Possible regression: "gre: Use inner mac length when computing tunnel length"
From: Timo Teras @ 2014-12-09 6:26 UTC (permalink / raw)
To: Tom Herbert; +Cc: Alexander Duyck, Linux Netdev List
In-Reply-To: <CA+mtBx-se+u4j8WHzZ+AXeiFN2uevrvcTb6xFpeNrhjOv=EVng@mail.gmail.com>
On Thu, 4 Dec 2014 08:00:19 -0800
Tom Herbert <therbert@google.com> wrote:
> A fix is pending for net. Please try if you can.
Finally got to testing this. Unfortunately, this does not seem to fix
the issue I am experiencing.
Any suggestions?
>
> Tom
>
> diff --git a/net/ipv4/gre_offload.c b/net/ipv4/gre_offload.c
> index bb5947b..51973dd 100644
> --- a/net/ipv4/gre_offload.c
> +++ b/net/ipv4/gre_offload.c
> @@ -247,6 +247,9 @@ static int gre_gro_complete(struct sk_buff *skb,
> int nhoff) err = ptype->callbacks.gro_complete(skb, nhoff + grehlen);
>
> rcu_read_unlock();
> +
> + skb_set_inner_mac_header(skb, nhoff + grehlen);
> +
> return err;
> }
>
> On Thu, Dec 4, 2014 at 4:16 AM, Timo Teras <timo.teras@iki.fi> wrote:
> > Hi,
> >
> > After upgrading to latest 3.14.24 or newer, I noticed a weird TSO
> > bug in the "dmvpn" setup I use. And seems 3.14.23 works just fine.
> > So the commit 14051f0452a2c26a "gre: Use inner mac length when
> > computing tunnel length" would appear to be the related commit (but
> > have not yet tested this).
> >
> > In practice what happens is that forwarding path between ethX (or
> > vlanX) and gre1 gets broken.
> >
> > There's probably two differences to the "regular" gre tunnel case:
> > - it's nbma mode, meaning the gre header is inserted via slightly
> > different code path
> > - the gre1 packets are IPsec encrypted in transport mode
> >
> > As additional detail, doing "ethtool -K gre1 tso off" will
> > workaround the issue, so it is clearly tso issue pointing even
> > further to the commit in question.
> >
> > Is this something the suspected patch could cause? Any suggestions
> > what to test more?
> >
> > Thanks,
> > Timo
> >
^ permalink raw reply
* Re: [PATCH RFC] pci: Control whether VFs are probed on pci_enable_sriov
From: Eli Cohen @ 2014-12-09 6:43 UTC (permalink / raw)
To: Yuval Mintz
Cc: Eli Cohen, bhelgaas@google.com, David Miller, linux-pci, netdev,
ogerlitz@mellanox.com, yevgenyp@mellanox.com, Donald Dutile
In-Reply-To: <B5657A6538887040AD3A81F1008BEC63BA7746@avmb3.qlogic.org>
On Mon, Dec 08, 2014 at 07:25:24PM +0000, Yuval Mintz wrote:
>
> >Currently the kerenl will call probe for any device for which there is
> >a supporting driver and I did not want to change that.
>
> But what's next? How will this feature be activated?
>
> Adding a parameter to pci_enable_sriov() might give developers the false
> impression they can change behavior by passing `0' to this function;
> But that shouldn't be the method to control this - we should have uniform
> control of the feature across different drivers, e.g., by an additional sysfs node.
I was planning on using this on mlx5 SRIOV support which is not
available upstream yet. So this could be a driver developer's decision
how to use this. I think adding another sysfs entry to control this
behavior is unnecessary since the administrator has the freedom to
later do any bidnings he wishes to do.
Keeping things as they are today is not so "nice". I mean, I could
fail probe for VFs to avoid them from being initialized at the
hypervisor but there are other questions: which error should I return
and how can I be sure how the bus driver will refer to such failures.
So, maybe the solution I suggested is not the best one but do we agree
that this needs to be addressed this way or another?
^ permalink raw reply
* Re: Possible regression: "gre: Use inner mac length when computing tunnel length"
From: Timo Teras @ 2014-12-09 6:44 UTC (permalink / raw)
To: Tom Herbert; +Cc: Alexander Duyck, Linux Netdev List
In-Reply-To: <20141209082645.5cf70f55@vostro>
On Tue, 9 Dec 2014 08:26:45 +0200
Timo Teras <timo.teras@iki.fi> wrote:
> On Thu, 4 Dec 2014 08:00:19 -0800
> Tom Herbert <therbert@google.com> wrote:
>
> > A fix is pending for net. Please try if you can.
>
> Finally got to testing this. Unfortunately, this does not seem to fix
> the issue I am experiencing.
>
> Any suggestions?
I think this fix is required, but does not fix the issue.
I suspect my problem is with the fact that I have NBMA GRE tunnel.
In ipgre_xmit() it is gre_handle_offloads() that is called first.
However, in my case, the GRE header was already pushed earlier via
header_ops. That's why the packet is skb_pull()'ed in the
"if (dev->header_ops)" path, so that __gre_xmit can push back the
header again on it.
I wonder if it is correct to just move the gre_handle_offloads() call
after the if() block, or if additional fixing is needed to make
offloads work with nbma tunnels.
/Timo
^ permalink raw reply
* Re: [patch v2] ipvs: uninitialized data with IP_VS_IPV6
From: Dan Carpenter @ 2014-12-09 6:49 UTC (permalink / raw)
To: Simon Horman
Cc: Julian Anastasov, Wensong Zhang, Pablo Neira Ayuso,
Patrick McHardy, Jozsef Kadlecsik, David S. Miller, netdev,
lvs-devel, netfilter-devel, coreteam, kernel-janitors
In-Reply-To: <20141209005215.GH8897@verge.net.au>
On Tue, Dec 09, 2014 at 09:52:15AM +0900, Simon Horman wrote:
> 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.
No objections from me.
regards,
dan carpenter
^ permalink raw reply
* Antw: Re: Q: need effective backlog for listen()
From: Ulrich Windl @ 2014-12-09 7:01 UTC (permalink / raw)
To: phil; +Cc: netdev
In-Reply-To: <1418056540.384.5.camel@niobium.home.fifi.org>
>>> Philippe Troin <phil@fifi.org> schrieb am 08.12.2014 um 17:35 in Nachricht
<1418056540.384.5.camel@niobium.home.fifi.org>:
> On Mon, 2014-12-08 at 13:51 +0100, Ulrich Windl wrote:
>> (not subscribed to the list, plese keep me on CC:)
>>
>> I have a problem I could not find the answer. I suspect the problem
>> arises from Linux derivating from standard functionality...
>>
>> I have written a server that should accept n TCP connections at most.
>> I was expecting that the backlog parameter of listen will cause extra
>> connection requests either
>> 1) to be refused
>> or
>> 2) to time out eventually
>>
>> (The standard seems to say that extra connections are refused)
>
> The argument to listen() specifies how many connections the system is
> allow to keep waiting to be accept()ed.
> As soon as you accept() the connection, the count is decremented.
> So that won't help for your use case.
>
>> However none of the above see ms true. Even if my server delays
>> accept()ing new connections, no client ever sees a "connection
>> refused" or "connection timed out". Is there any chance to signal the
>> client that no more connections are accepted at the moment?
>
> Close the listening socket. No new connections will be accepted.
> When you reopen the socket for accepting new connections, you may have
> to use SO_REUSEADDR before bind()ing to the port.
This is what I had done, but those connections who are waiting to be accepted: If I close the listening socket, will the clients see a connection abort, or will they see a connection refused?
Connection aborts could confuse clients.
Ulrich
^ permalink raw reply
* RE: [PATCH RFC] pci: Control whether VFs are probed on pci_enable_sriov
From: Yuval Mintz @ 2014-12-09 7:07 UTC (permalink / raw)
To: Eli Cohen
Cc: bhelgaas@google.com, David Miller, linux-pci, netdev,
ogerlitz@mellanox.com, yevgenyp@mellanox.com, Donald Dutile
In-Reply-To: <20141209064339.GA1806@mtldesk30>
[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]
> > >Currently the kerenl will call probe for any device for which there
> > >is a supporting driver and I did not want to change that.
> >
> > But what's next? How will this feature be activated?
> >
> > Adding a parameter to pci_enable_sriov() might give developers the
> > false impression they can change behavior by passing `0' to this
> > function; But that shouldn't be the method to control this - we should
> > have uniform control of the feature across different drivers, e.g., by an
> additional sysfs node.
>
> I was planning on using this on mlx5 SRIOV support which is not available
> upstream yet. So this could be a driver developer's decision how to use this.
I think it shouldn't - from user perspective, you can't have such fundamental
difference between different drivers - that enabling sriov on one device would
create VFs in the hypervisors and another one won't.
> I think adding another sysfs entry to control this behavior is unnecessary since the
> administrator has the freedom to later do any bidnings he wishes to do.
>
> Keeping things as they are today is not so "nice". I mean, I could fail probe for
> VFs to avoid them from being initialized at the hypervisor but there are other
> questions: which error should I return and how can I be sure how the bus driver
> will refer to such failures.
Again - you could say that this is solely in your drivers decision-making-area,
but failing the VF probe would lead to the same difference between drivers I've
stated before.
> So, maybe the solution I suggested is not the best one but do we agree that this
> needs to be addressed this way or another?
All-in-all, I agree. But I think the solution should be user-controlled and not driver-based.
[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 5068 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