* Re: [bisected] xfrm: TCP connection initiating PMTU discovery stalls on v3.12+
From: Thomas Jarosch @ 2014-12-09 8:54 UTC (permalink / raw)
To: Wolfgang Walter
Cc: Eric Dumazet, netdev, Eric Dumazet, Herbert Xu, Steffen Klassert
In-Reply-To: <5642727.qTG53DqrAk@h2o.as.studentenwerk.mhn.de>
On Monday, 8. December 2014 23:20:42 Wolfgang Walter wrote:
> Am Freitag, 5. Dezember 2014, 05:26:25 schrieb Eric Dumazet:
> > On Fri, 2014-12-05 at 13:09 +0100, Wolfgang Walter wrote:
> > > Hello,
> > >
> > > as reverting this patch fixes this rather annoying problem: is it
> > > dangerous to revert it as a workaround until the root cause is found?
> >
> > Unfortunately no, this patch fixes a serious issue.
> >
> > We need to find the root cause of your problem instead of trying to work
> > around it.
>
> I only wanted to use it as local workaround here.
>
>
> I looked a bit at at code. I'm not familiar with the network code, though
> :-).
If it helps, I'm running the reverted patch on five production boxes hitherto
without a hiccup. As far as I understood the original commit message,
some packet counters might me wrong without it.
@Eric: What could possibly go wrong(tm)? :)
Of course a real fix is preferred over this band-aid.
Cheers,
Thomas
^ permalink raw reply
* Re: [PATCH net-next v5 3/3] bridge: remove mode BRIDGE_MODE_SWDEV
From: Jiri Pirko @ 2014-12-09 7:56 UTC (permalink / raw)
To: roopa
Cc: sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen, linville,
vyasevic, netdev, davem, shm, gospo
In-Reply-To: <1418076261-24593-4-git-send-email-roopa@cumulusnetworks.com>
Mon, Dec 08, 2014 at 11:04:21PM CET, roopa@cumulusnetworks.com wrote:
>From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
>This patch removes bridge mode swdev.
>Users can use BRIDGE_FLAGS_SELF to indicate swdev offload
>if needed.
>
>Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Thanks Roopa for taking care of this!
>---
> include/uapi/linux/if_bridge.h | 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
>index 05f0869..b03ee8f 100644
>--- a/include/uapi/linux/if_bridge.h
>+++ b/include/uapi/linux/if_bridge.h
>@@ -105,7 +105,6 @@ struct __fdb_entry {
>
> #define BRIDGE_MODE_VEB 0 /* Default loopback mode */
> #define BRIDGE_MODE_VEPA 1 /* 802.1Qbg defined VEPA mode */
>-#define BRIDGE_MODE_SWDEV 2 /* Full switch device offload */
> #define BRIDGE_MODE_UNDEF 0xFFFF /* mode undefined */
>
> /* Bridge management nested attributes
>--
>1.7.10.4
>
^ permalink raw reply
* Re: [PATCH net-next v5 2/3] rocker: remove swdev mode
From: Jiri Pirko @ 2014-12-09 7:55 UTC (permalink / raw)
To: roopa
Cc: sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen, linville,
vyasevic, netdev, davem, shm, gospo
In-Reply-To: <1418076261-24593-3-git-send-email-roopa@cumulusnetworks.com>
Mon, Dec 08, 2014 at 11:04:20PM CET, roopa@cumulusnetworks.com wrote:
>From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
>Remove use of 'swdev' mode in rocker. rocker dev offloads
>can use the BRIDGE_FLAGS_SELF to indicate offload to hardware.
>
>Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>---
> drivers/net/ethernet/rocker/rocker.c | 18 +-----------------
> net/core/rtnetlink.c | 10 ++++++++--
> 2 files changed, 9 insertions(+), 19 deletions(-)
>
>diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
>index fded127..a841f7a 100644
>--- a/drivers/net/ethernet/rocker/rocker.c
>+++ b/drivers/net/ethernet/rocker/rocker.c
>@@ -3700,27 +3700,11 @@ static int rocker_port_bridge_setlink(struct net_device *dev,
> {
> struct rocker_port *rocker_port = netdev_priv(dev);
> struct nlattr *protinfo;
>- struct nlattr *afspec;
> struct nlattr *attr;
>- u16 mode;
> int err;
>
> protinfo = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg),
> IFLA_PROTINFO);
>- afspec = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_AF_SPEC);
>-
>- if (afspec) {
>- attr = nla_find_nested(afspec, IFLA_BRIDGE_MODE);
>- if (attr) {
>- if (nla_len(attr) < sizeof(mode))
>- return -EINVAL;
>-
>- mode = nla_get_u16(attr);
>- if (mode != BRIDGE_MODE_SWDEV)
>- return -EINVAL;
>- }
>- }
>-
> if (protinfo) {
> attr = nla_find_nested(protinfo, IFLA_BRPORT_LEARNING);
> if (attr) {
>@@ -3755,7 +3739,7 @@ static int rocker_port_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
> u32 filter_mask)
> {
> struct rocker_port *rocker_port = netdev_priv(dev);
>- u16 mode = BRIDGE_MODE_SWDEV;
>+ u16 mode = BRIDGE_MODE_UNDEF;
> u32 mask = BR_LEARNING | BR_LEARNING_SYNC;
>
> return ndo_dflt_bridge_getlink(skb, pid, seq, dev, mode,
>diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>index 61cb7e7..3863e3b 100644
>--- a/net/core/rtnetlink.c
>+++ b/net/core/rtnetlink.c
>@@ -2734,11 +2734,17 @@ int ndo_dflt_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
> if (!br_afspec)
> goto nla_put_failure;
>
>- if (nla_put_u16(skb, IFLA_BRIDGE_FLAGS, BRIDGE_FLAGS_SELF) ||
>- nla_put_u16(skb, IFLA_BRIDGE_MODE, mode)) {
>+ if (nla_put_u16(skb, IFLA_BRIDGE_FLAGS, BRIDGE_FLAGS_SELF)) {
> nla_nest_cancel(skb, br_afspec);
> goto nla_put_failure;
> }
>+
>+ if (mode != BRIDGE_MODE_UNDEF) {
>+ if (nla_put_u16(skb, IFLA_BRIDGE_MODE, mode)) {
>+ nla_nest_cancel(skb, br_afspec);
>+ goto nla_put_failure;
>+ }
>+ }
> nla_nest_end(skb, br_afspec);
>
> protinfo = nla_nest_start(skb, IFLA_PROTINFO | NLA_F_NESTED);
>--
>1.7.10.4
>
^ permalink raw reply
* Re: [PATCH net-next v5 1/3] bridge: new mode flag to indicate mode 'undefined'
From: Jiri Pirko @ 2014-12-09 7:54 UTC (permalink / raw)
To: roopa
Cc: sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen, linville,
vyasevic, netdev, davem, shm, gospo
In-Reply-To: <1418076261-24593-2-git-send-email-roopa@cumulusnetworks.com>
Mon, Dec 08, 2014 at 11:04:19PM CET, roopa@cumulusnetworks.com wrote:
>From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
>This patch adds mode BRIDGE_MODE_UNDEF for cases where mode is not needed.
>
>Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>
>---
> include/uapi/linux/if_bridge.h | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
>index 296a556..05f0869 100644
>--- a/include/uapi/linux/if_bridge.h
>+++ b/include/uapi/linux/if_bridge.h
>@@ -106,6 +106,7 @@ struct __fdb_entry {
> #define BRIDGE_MODE_VEB 0 /* Default loopback mode */
> #define BRIDGE_MODE_VEPA 1 /* 802.1Qbg defined VEPA mode */
> #define BRIDGE_MODE_SWDEV 2 /* Full switch device offload */
>+#define BRIDGE_MODE_UNDEF 0xFFFF /* mode undefined */
>
> /* Bridge management nested attributes
> * [IFLA_AF_SPEC] = {
>--
>1.7.10.4
>
^ permalink raw reply
* [PATCH net-next] tipc: avoid double lock 'spin_lock:&seq->lock'
From: Ying Xue @ 2014-12-09 7:17 UTC (permalink / raw)
To: davem; +Cc: jon.maloy, dan.carpenter, erik.hugne, netdev, tipc-discussion
The commit fb9962f3cefe ("tipc: ensure all name sequences are properly
protected with its lock") involves below errors:
net/tipc/name_table.c:980 tipc_purge_publications() error: double lock 'spin_lock:&seq->lock'
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
---
net/tipc/name_table.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
index aafa684c..c8df022 100644
--- a/net/tipc/name_table.c
+++ b/net/tipc/name_table.c
@@ -979,7 +979,7 @@ static void tipc_purge_publications(struct name_seq *seq)
}
hlist_del_init_rcu(&seq->ns_list);
kfree(seq->sseqs);
- spin_lock_bh(&seq->lock);
+ spin_unlock_bh(&seq->lock);
kfree_rcu(seq, rcu);
}
--
1.7.9.5
^ permalink raw reply related
* 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
* 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 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
* 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 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: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: 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: 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: 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: 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: [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: 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
* [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: [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
* 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] 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: [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
* 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: [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
* 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
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