* FWD: [PATCH][next] net: phy: mdio-bcm-unimac: fix unsigned wrap-around when decrementing timeout
From: Andrew Lunn @ 2017-08-08 14:07 UTC (permalink / raw)
To: Florian Fainelli; +Cc: colin.king, netdev
----- Forwarded message from Colin King <colin.king@canonical.com> -----
Date: Tue, 8 Aug 2017 10:52:32 +0100
From: Colin King <colin.king@canonical.com>
To: Andrew Lunn <andrew@lunn.ch>, Florian Fainelli <f.fainelli@gmail.com>, netdev@vger.kernel.org
Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH][next] net: phy: mdio-bcm-unimac: fix unsigned wrap-around when decrementing timeout
X-Spam-Status: No, score=-7.4 required=4.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD,T_HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham
autolearn_force=no version=3.4.0
From: Colin Ian King <colin.king@canonical.com>
Change post-decrement compare to pre-decrement to avoid an
unsigned integer wrap-around on timeout. This leads to the following
!timeout check to never to be true so -ETIMEDOUT is never returned.
Detected by CoverityScan, CID#1452623 ("Logically dead code")
Fixes: 69a60b0579a4 ("net: phy: mdio-bcm-unimac: factor busy polling loop")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/phy/mdio-bcm-unimac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/mdio-bcm-unimac.c b/drivers/net/phy/mdio-bcm-unimac.c
index 89425ca48412..73c5267a11fd 100644
--- a/drivers/net/phy/mdio-bcm-unimac.c
+++ b/drivers/net/phy/mdio-bcm-unimac.c
@@ -71,7 +71,7 @@ static int unimac_mdio_poll(void *wait_func_data)
return 0;
usleep_range(1000, 2000);
- } while (timeout--);
+ } while (--timeout);
if (!timeout)
return -ETIMEDOUT;
--
2.11.0
----- End forwarded message -----
Hi Florian
You might want to look at bcm_sf2_cfp_op() and bcm_sf2_cfp_rst().
Colin, do you have more of these patches? Have you done a tree wide
search?
Andrew
^ permalink raw reply related
* Re: [PATCHv2] bluetooth: document config options
From: Marcel Holtmann @ 2017-08-08 14:04 UTC (permalink / raw)
To: Pavel Machek
Cc: Gustavo F. Padovan, Johan Hedberg, open list:BLUETOOTH DRIVERS,
kernel list, Netdev list
In-Reply-To: <20170808134839.GA801@amd>
Hi Pavel,
> On Aug 8, 2017, at 15:48, Pavel Machek <pavel@ucw.cz> wrote:
>
> Kernel config options should include useful help text; I had to look
> up the terms on wikipedia.
>
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
>
> ---
>
>> are you planning to send a patch with updated wording for this?
>
> Sorry for the delay, it is above. I added word "wifi" to 802.11
> description.
>
> Pavel
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH net-next 0/1] netvsc: another VF datapath fix
From: Vitaly Kuznetsov @ 2017-08-08 14:03 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: kys, haiyangz, sthemmin, devel, netdev
In-Reply-To: <20170807183000.10827-1-sthemmin@microsoft.com>
Stephen Hemminger <stephen@networkplumber.org> writes:
> Previous fix was incomplete.
>
Not really related to this patch series (which btw fixes my issue,
thanks!), but I found one addition issue. Systemd fails to rename VF
interface:
kernel: mlx4_core 0002:00:02.0 eth2: joined to eth1
kernel: hv_netvsc 33b7a6f9-6736-451f-8fce-b382eaa50bee eth1: VF registering: eth2
kernel: hv_netvsc 33b7a6f9-6736-451f-8fce-b382eaa50bee eth1: Data path switched to VF: eth2
kernel: mlx4_en: eth2: Link Up
NetworkManager[750]: <info> [1502200557.0821] device (eth2): link connected
NetworkManager[750]: <info> [1502200557.1004] manager: (eth2): new Ethernet device (/org/freedesktop/NetworkManager/Devices/6)
systemd-udevd[6942]: Error changing net interface name 'eth2' to 'enP2p0s2': Device or resource busy
systemd-udevd[6942]: could not rename interface '6' from 'eth2' to 'enP2p0s2': Device or resource busy
With some debug added I figured out what's wrong: __netvsc_vf_setup()
does dev_open() which sets IFF_UP flag on the interface. When systemd
tries to rename the interface we get into dev_change_name() and this
fails with -EBUSY when (dev->flags & IFF_UP).
The issue is of less importance as we're not supposed to configure VF
interface now. However, we may still want to get a stable name for it.
Any idea how this can be fixed?
--
Vitaly
^ permalink raw reply
* Re: [PATCH net] ppp: fix xmit recursion detection on ppp channels
From: Guillaume Nault @ 2017-08-08 13:58 UTC (permalink / raw)
To: Gao Feng; +Cc: netdev, Liu Jianying, David Miller, linux-ppp, Paul Mackerras
In-Reply-To: <5a62fd3f.e0c3.15dc1fd5f1b.Coremail.gfree.wind@vip.163.com>
On Tue, Aug 08, 2017 at 09:16:33PM +0800, Gao Feng wrote:
> At 2017-08-08 17:43:24, "Guillaume Nault" <g.nault@alphalink.fr> wrote:
> >--- a/drivers/net/ppp/ppp_generic.c
> >+++ b/drivers/net/ppp/ppp_generic.c
> >@@ -1915,21 +1915,23 @@ static void __ppp_channel_push(struct channel *pch)
> > spin_unlock(&pch->downl);
> > /* see if there is anything from the attached unit to be sent */
> > if (skb_queue_empty(&pch->file.xq)) {
> >- read_lock(&pch->upl);
> > ppp = pch->ppp;
> > if (ppp)
> >- ppp_xmit_process(ppp);
> >- read_unlock(&pch->upl);
> >+ __ppp_xmit_process(ppp);
> > }
> > }
> >
> > static void ppp_channel_push(struct channel *pch)
> > {
> >- local_bh_disable();
> >-
> >- __ppp_channel_push(pch);
> >-
> >- local_bh_enable();
> >+ read_lock_bh(&pch->upl);
> >+ if (pch->ppp) {
> >+ (*this_cpu_ptr(pch->ppp->xmit_recursion))++;
> >+ __ppp_channel_push(pch);
> >+ (*this_cpu_ptr(pch->ppp->xmit_recursion))--;
> >+ } else {
> >+ __ppp_channel_push(pch);
> >+ }
> >+ read_unlock_bh(&pch->upl);
>
> If invoked read_lock_bh in ppp_channel_push, it would be unnecessary to invoke read_lock(&pch->upl)
> in the __ppp_channel_push.
>
But this patch does remove read_lock(&pch->upl) from
__ppp_channel_push(). Or have I misunderstood your point?
^ permalink raw reply
* Re: Driver profiles RFC
From: Andrew Lunn @ 2017-08-08 13:54 UTC (permalink / raw)
To: Arkadi Sharshevsky
Cc: netdev, David Miller, ivecera, roopa, Florian Fainelli,
Vivien Didelot, john.fastabend, Jiri Pirko, mlxsw
In-Reply-To: <6d8560fa-8346-0c43-272d-d39be65ea82f@mellanox.com>
On Tue, Aug 08, 2017 at 04:15:41PM +0300, Arkadi Sharshevsky wrote:
> Drivers may require driver specific information during the init stage.
> For example, memory based shared resource which should be segmented for
> different ASIC processes, such as FDB and LPM lookups.
Hi Arkadi
Have you looked around other subsystems to see if they have already
solved this problem?
How about GPUs? Do they have a similar requirement?
This seems like a generic problem for 'smart' peripherals. How would
you use dpipe with a GPU for example?
Andrew
^ permalink raw reply
* [PATCH] hv_set_ifconfig.sh double check before setting ip
From: Eduardo Otubo @ 2017-08-08 13:53 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, devel, Stephen Hemminger, Haiyang Zhang,
K . Y . Srinivasan
This patch fixes the behavior of the hv_set_ifconfig script when setting
the interface ip. Sometimes the interface has already been configured by
network daemon, in this case hv_set_ifconfig causes "RTNETLINK: file
exists error"; in order to avoid this error this patch makes sure double
checks the interface before trying anything.
Signed-off-by: Eduardo Otubo <otubo@redhat.com>
---
tools/hv/hv_set_ifconfig.sh | 29 ++++++++++++++++++-----------
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/tools/hv/hv_set_ifconfig.sh b/tools/hv/hv_set_ifconfig.sh
index 735aafd64a3f..ba5e4aa4efe2 100755
--- a/tools/hv/hv_set_ifconfig.sh
+++ b/tools/hv/hv_set_ifconfig.sh
@@ -46,19 +46,26 @@
# is expected to return the configuration that is set via the SET
# call.
#
+interface=$(echo $1 | awk -F - '{ print $2 }')
+current_ip=$(ip addr show $interface|grep "inet ");
+config_file_ip=$(grep IPADDR $1|cut -d"=" -f2);
+current_ipv6=$(ip addr show $interface|grep "inet6 ");
+config_file_ipv6=$(grep IPV6ADDR $1|cut -d"=" -f2);
+config_file_ipv6_netmask=$(grep IPV6NETMASK $1|cut -d"=" -f2);
+config_file_ipv6=${config_file_ipv6}/${config_file_ipv6_netmask};
-echo "IPV6INIT=yes" >> $1
-echo "NM_CONTROLLED=no" >> $1
-echo "PEERDNS=yes" >> $1
-echo "ONBOOT=yes" >> $1
-
-
-cp $1 /etc/sysconfig/network-scripts/
-
+# only set the IP if it's not configured yet
+if [[ $(test "${current_ip#*$config_file_ip}") == "$config_file_ip" \
+ || $(test "${current_ipv6#*$config_file_ipv6}") == "$current_ipv6" ]]; then
+ echo "IPV6INIT=yes" >> $1
+ echo "NM_CONTROLLED=no" >> $1
+ echo "PEERDNS=yes" >> $1
+ echo "ONBOOT=yes" >> $1
-interface=$(echo $1 | awk -F - '{ print $2 }')
+ cp $1 /etc/sysconfig/network-scripts/
-/sbin/ifdown $interface 2>/dev/null
-/sbin/ifup $interface 2>/dev/null
+ /sbin/ifdown $interface 2>/dev/null
+ /sbin/ifup $interface 2>/dev/null
+fi
--
2.13.4
^ permalink raw reply related
* تحية طيبة
From: infoinfo @ 2017-08-08 13:51 UTC (permalink / raw)
تحية طيبة
أنا السيدة إيس عمر، زوجة رئيس الوفد السابق المتوفى لدى البنك الدولي في
غرب أفريقيا. وكان زوجي هو الرابط بين منظمة الدول المصدرة للنفط (اوبك)
وقطاع النفط في بلد في غرب افريقيا، توفي بسبب سكتة قلبية في بلدتنا بعد
ان حضر اجتماعات منظمة الدول المصدرة للنفط (اوبك) في جنيف.
كان قادرا على جعل (عشرة ملايين دولار أمريكي) من خلال مبيعات حصص النفط
المخصصة في أوبك والودائع في أحد البنوك حيث لا يعرف زملاؤه عن ذلك، أريدك
أن تساعدني في المطالبة بهذه الأموال كما أنا لا يمكن أن يدعي ذلك مباشرة
لأنه جعل الودائع كصندوق ينتمي إلى شركته التجارية من أجل عدم رفع
الحاجبين منذ كان موظفا مدنيا خلال ذلك الوقت، ومكتب مدونة السلوك يمنعه
أو زوجته من الحصول على هذا المبلغ من المال .
يمكنك مساعدتي لتحويل الأموال إلى حسابك؟ وسوف نقدم لكم 30 في المئة
لعملك. إذا كنت يمكن أن تضمن لي مريح من قدرتك على الحفاظ على هذا العمل
سرية جدا وسرية، يمكنك الكتابة لي لمزيد من التفاصيل.
تحياتي حارة،
السيدة إيس عمر
البريد الإلكتروني: mrsesseomar@gmail.com
--------------------------------------
عذرا، إذا تلقيت هذه الرسالة في الرسائل غير المرغوب فيها، يرجع ذلك إلى
حدوث خطأ في الاتصال مؤخرا هنا في البلد.
^ permalink raw reply
* [PATCHv2] bluetooth: document config options
From: Pavel Machek @ 2017-08-08 13:48 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Gustavo F. Padovan, Johan Hedberg, linux-bluetooth, kernel list,
Netdev list
In-Reply-To: <EDDC23EF-C82E-41EE-8530-E86B9B4756A5@holtmann.org>
[-- Attachment #1: Type: text/plain, Size: 1601 bytes --]
Kernel config options should include useful help text; I had to look
up the terms on wikipedia.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
---
> are you planning to send a patch with updated wording for this?
Sorry for the delay, it is above. I added word "wifi" to 802.11
description.
Pavel
diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig
index 68f951b..48add1e 100644
--- a/net/bluetooth/Kconfig
+++ b/net/bluetooth/Kconfig
@@ -45,6 +45,11 @@ config BT_BREDR
bool "Bluetooth Classic (BR/EDR) features"
depends on BT
default y
+ help
+ Bluetooth Classic includes support for Basic Rate (BR)
+ available with Bluetooth version 1.0b or later and support
+ for Enhanced Data Rate (EDR) available with Bluetooth
+ version 2.0 or later.
source "net/bluetooth/rfcomm/Kconfig"
@@ -58,12 +63,19 @@ config BT_HS
bool "Bluetooth High Speed (HS) features"
depends on BT_BREDR
default y
+ help
+ Bluetooth High Speed includes support for off-loading
+ Bluetooth connections via 802.11 (wifi) physical layer
+ available with Bluetooth version 3.0 or later.
config BT_LE
bool "Bluetooth Low Energy (LE) features"
depends on BT
default y
-
+ help
+ Bluetooth Low Energy includes support low-energy physical
+ layer available with Bluetooth version 4.0 or later.
+
config BT_6LOWPAN
tristate "Bluetooth 6LoWPAN support"
depends on BT_LE && 6LOWPAN
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply related
* Re: [PATCH net-next] ibmvnic: Add netdev_dbg output for debugging
From: Nathan Fontenot @ 2017-08-08 13:39 UTC (permalink / raw)
To: Joe Perches, netdev; +Cc: jallen, tlfalcon
In-Reply-To: <1502119795.2219.21.camel@perches.com>
On 08/07/2017 10:29 AM, Joe Perches wrote:
> On Mon, 2017-08-07 at 15:02 -0400, Nathan Fontenot wrote:
>> To ease debugging of the ibmvnic driver add a series of netdev_dbg()
>> statements to track driver status, especially during initialization,
>> removal, and resetting of the driver.
>
> For some of the function entry logging, it seems
> better to use ftrace instead.
>
>> diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
> []
>> @@ -389,6 +389,8 @@ static int init_stats_token(struct ibmvnic_adapter *adapter)
>> struct device *dev = &adapter->vdev->dev;
>> dma_addr_t stok;
>>
>> + netdev_dbg(adapter->netdev, "Initializing stats token\n");
>
> here and subsequent.
Thanks for the tip. I'm not very familiar with ftrace so I'll have to
investigate and send a revised patch.
-Nathan
^ permalink raw reply
* Re: Driver profiles RFC
From: Jiri Pirko @ 2017-08-08 13:24 UTC (permalink / raw)
To: Arkadi Sharshevsky
Cc: netdev, David Miller, ivecera, roopa, Florian Fainelli,
Vivien Didelot, john.fastabend, Andrew Lunn, mlxsw
In-Reply-To: <6d8560fa-8346-0c43-272d-d39be65ea82f@mellanox.com>
Tue, Aug 08, 2017 at 03:15:41PM CEST, arkadis@mellanox.com wrote:
>Drivers may require driver specific information during the init stage.
>For example, memory based shared resource which should be segmented for
>different ASIC processes, such as FDB and LPM lookups.
>
>The current mlxsw implementation assumes some default values, which are
>const and cannot be changed due to lack of UAPI for its configuration
>(module params is not an option). Those values can greatly impact the
>scale of the hardware processes, such as the maximum sizes of the FDB/LPM
>tables. Furthermore, those values should be consistent between driver
>reloads.
>
>The interface called DPIPE [1] was introduced in order to provide
>abstraction of the hardware pipeline. This RFC letter suggests solving
>this problem by enhancing the DPIPE hardware abstraction model.
>
>DPIPE Resource
>==============
>
>In order to represent ASIC wide resources space a new object should be
>introduced called "resource". It was originally suggested as future
>extension in [1] in order to give the user visibility about the tables
>limitation due to some shared resource. For example FDB and LPM share
>a common hash based memory. This abstraction can be also used for
>providing static configuration for such resources.
>
>Resource
>--------
>The resource object defines generic hardware resource like memory,
>counter pool, etc. which can be described by name and size. The resource
>can be nested, for example the internal ASIC's memory can be split into
>two parts, as can be seen in the following diagram:
>
> +---------------+
> | Internal Mem |
> | |
> | Size: 3M* |
> +---------------+
> / \
> / \
> / \
> / \
> / \
> +--------------+ +--------------+
> | Linear | | Hash |
> | | | |
> | Size: 1M | | Size: 2M |
> +--------------+ +--------------+
>
>*The number are provided as an example and do not reflect real ASIC
> resource sizes
>
>Where the hash portion is used for FDB/LPM table lookups, and the linear
>one is used by the routing adjacency table. Each resource can be described
>by a name, size and list of children. Example for dumping the described
>above structure:
>
>#devlink dpipe resource dump tree pci/0000:03:00.0 Mem
>{
> "resource": {
> "pci/0000:03:00.0": [{
> "name": "Mem",
> "size": 3M,
> "resource": [{
> "name": "Mem_Linear",
> "size": "1M",
> }, {
> "name": "Mem_Hash",
> "size": "2MK",
> }
> }]
> }]
This is dumped from kernel either by list or tree using nesting.
I think that list makes more sense and userspace can assemble the tree
according to references.
> }
>}
>
>Each DPIPE table can be connected to one resource.
>
>Driver <--> Devlink API
>=======================
>Each driver will register his resources with default values at init in
>a similar way to DPIPE table registration. In case those resources already
>exist the default values are discarded. The user will be able to dump and
>update the resources. In order for the changes to take place the user will
>need to re-initiate the driver by a specific devlink knob.
>
>The above described procedure will require extra reload of the driver.
>This can be improved as a future optimization.
>
>UAPI
>====
>The user will be able to update the resources on a per resource basis:
>
>$devlink dpipe resource set pci/0000:03:00.0 Mem_Linear 2M
>
>For some resources the size is fixed, for example the size of the internal
>memory cannot be changed. It is provided merely in order to reflect the
>nested structure of the resource and to imply the user that Mem = Linear +
>Hash, thus a set operation on it will fail.
>
>The user can dump the current resource configuration:
>
>#devlink dpipe resource dump tree pci/0000:03:00.0 Mem
>
>The user can specify 'tree' in order to show all the nested resources under
>the specified one. In case no 'resource name' is specified the TOP hierarchy
>will be dumped.
>
>After successful resource update the drivers hould be re-instantiated in
>order for the changes to take place:
>
>$devlink reload pci/0000:03:00.0
>
>User Configuration
>------------------
>Such an UAPI is very low level, and thus an average user may not know how to
>adjust this sizes according to his needs. The vendor can provide several
>tested configuration files that the user can choose from. Each config file
>will be measured in terms of: MAC addresses, L3 Neighbors (IPv4, IPv6),
>LPM entries (IPv4,IPv6) in order to provide approximate results. By this an
>average user will choose one of the provided ones. Furthermore, a more
>advanced user could play with the numbers for his personal benefit.
>
>Reference
>=========
>[1] https://netdevconf.org/2.1/papers/dpipe_netdev_2_1.odt
>
This provides great visibility and ability to tweak the ASIC in very
well defined way.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* xen/9pfs: check return value of xenbus_read correctly
From: Pan Bian @ 2017-08-08 13:23 UTC (permalink / raw)
To: Eric Van Hensbergen, Ron Minnich, Latchesar Ionkov,
David S. Miller
Cc: v9fs-developer, netdev, linux-kernel, Pan Bian
In function xen_9pfs_front_probe(), variable len is checked against 0 to
to check the case that xenbus_read() fails. However, xenbus_read() may
return an ERR_PTR pointer even aften assigning a non-zero value to len.
As a result, the check of len cannot prevent from accessing bad memory.
Signed-off-by: Pan Bian <bianpan2016@163.com>
---
net/9p/trans_xen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index 6ad3e04..c548781 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -389,7 +389,7 @@ static int xen_9pfs_front_probe(struct xenbus_device *dev,
unsigned int max_rings, max_ring_order, len = 0;
versions = xenbus_read(XBT_NIL, dev->otherend, "versions", &len);
- if (!len)
+ if (IS_ERR(versions))
return -EINVAL;
if (strcmp(versions, "1")) {
kfree(versions);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net] rds: Reintroduce statistics counting
From: Shamir Rabinovitch @ 2017-08-08 13:20 UTC (permalink / raw)
To: Håkon Bugge
Cc: Santosh Shilimkar, David S . Miller,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
knut.omang-QHcLZuEGTsvQT0dZR+AlfA,
wei.lin-guay-QHcLZuEGTsvQT0dZR+AlfA
In-Reply-To: <20170808091332.5413-1-Haakon.Bugge-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
On Tue, Aug 08, 2017 at 11:13:32AM +0200, Håkon Bugge wrote:
> In commit 7e3f2952eeb1 ("rds: don't let RDS shutdown a connection
> while senders are present"), refilling the receive queue was removed
> from rds_ib_recv(), along with the increment of
> s_ib_rx_refill_from_thread.
>
> Commit 73ce4317bf98 ("RDS: make sure we post recv buffers")
> re-introduces filling the receive queue from rds_ib_recv(), but does
> not add the statistics counter. rds_ib_recv() was later renamed to
> rds_ib_recv_path().
>
> This commit reintroduces the statistics counting of
> s_ib_rx_refill_from_thread and s_ib_rx_refill_from_cq.
>
> Signed-off-by: Håkon Bugge <haakon.bugge-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Knut Omang <knut.omang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Wei Lin Guay <wei.lin.guay-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> ---
> net/rds/ib_recv.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/rds/ib_recv.c b/net/rds/ib_recv.c
> index e10624a..9722bf8 100644
> --- a/net/rds/ib_recv.c
> +++ b/net/rds/ib_recv.c
> @@ -1015,8 +1015,10 @@ void rds_ib_recv_cqe_handler(struct rds_ib_connection *ic,
> if (rds_ib_ring_empty(&ic->i_recv_ring))
> rds_ib_stats_inc(s_ib_rx_ring_empty);
>
> - if (rds_ib_ring_low(&ic->i_recv_ring))
> + if (rds_ib_ring_low(&ic->i_recv_ring)) {
> rds_ib_recv_refill(conn, 0, GFP_NOWAIT);
> + rds_ib_stats_inc(s_ib_rx_refill_from_cq);
> + }
> }
>
> int rds_ib_recv_path(struct rds_conn_path *cp)
> @@ -1029,6 +1031,7 @@ int rds_ib_recv_path(struct rds_conn_path *cp)
> if (rds_conn_up(conn)) {
> rds_ib_attempt_ack(ic);
> rds_ib_recv_refill(conn, 0, GFP_KERNEL);
> + rds_ib_stats_inc(s_ib_rx_refill_from_thread);
> }
>
> return ret;
> --
> 2.9.3
>
Reviewed-by: Shamir Rabinovitch <shamir.rabinovitch-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
--
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] ppp: fix xmit recursion detection on ppp channels
From: Gao Feng @ 2017-08-08 13:16 UTC (permalink / raw)
To: Guillaume Nault
Cc: netdev, Liu Jianying, David Miller, linux-ppp, Paul Mackerras
In-Reply-To: <e45ed6ea02e2665ec8b868279ad9afcb9b34fc81.1502185216.git.g.nault@alphalink.fr>
At 2017-08-08 17:43:24, "Guillaume Nault" <g.nault@alphalink.fr> wrote:
>Commit e5dadc65f9e0 ("ppp: Fix false xmit recursion detect with two ppp
>devices") dropped the xmit_recursion counter incrementation in
>ppp_channel_push() and relied on ppp_xmit_process() for this task.
>But __ppp_channel_push() can also send packets directly (using the
>.start_xmit() channel callback), in which case the xmit_recursion
You're right. We lost this case.
>counter isn't incremented anymore. If such packets get routed back to
>the parent ppp unit, ppp_xmit_process() won't notice the recursion and
>will call ppp_channel_push() on the same channel, effectively creating
>the deadlock situation that the xmit_recursion mechanism was supposed
>to prevent.
>
>This patch re-introduces the xmit_recursion counter incrementation in
>ppp_channel_push(). Since the xmit_recursion variable is now part of
>the parent ppp unit, incrementation is skipped if the channel doesn't
>have any. This is fine because only packets routed through the parent
>unit may enter the channel recursively.
>
>Finally, we have to ensure that pch->ppp is not going to be modified
>while executing ppp_channel_push(). Instead of taking this lock only
>while calling ppp_xmit_process(), we now have to hold it for the full
>ppp_channel_push() execution. This respects the ppp locks ordering
>which requires locking ->upl before ->downl.
>
>Fixes: e5dadc65f9e0 ("ppp: Fix false xmit recursion detect with two ppp devices")
>Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
>---
> drivers/net/ppp/ppp_generic.c | 18 ++++++++++--------
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
>diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
>index bd4303944e44..a404552555d4 100644
>--- a/drivers/net/ppp/ppp_generic.c
>+++ b/drivers/net/ppp/ppp_generic.c
>@@ -1915,21 +1915,23 @@ static void __ppp_channel_push(struct channel *pch)
> spin_unlock(&pch->downl);
> /* see if there is anything from the attached unit to be sent */
> if (skb_queue_empty(&pch->file.xq)) {
>- read_lock(&pch->upl);
> ppp = pch->ppp;
> if (ppp)
>- ppp_xmit_process(ppp);
>- read_unlock(&pch->upl);
>+ __ppp_xmit_process(ppp);
> }
> }
>
> static void ppp_channel_push(struct channel *pch)
> {
>- local_bh_disable();
>-
>- __ppp_channel_push(pch);
>-
>- local_bh_enable();
>+ read_lock_bh(&pch->upl);
>+ if (pch->ppp) {
>+ (*this_cpu_ptr(pch->ppp->xmit_recursion))++;
>+ __ppp_channel_push(pch);
>+ (*this_cpu_ptr(pch->ppp->xmit_recursion))--;
>+ } else {
>+ __ppp_channel_push(pch);
>+ }
>+ read_unlock_bh(&pch->upl);
If invoked read_lock_bh in ppp_channel_push, it would be unnecessary to invoke read_lock(&pch->upl)
in the __ppp_channel_push.
Best Regards
Feng
> }
>
> /*
>--
>2.14.0
>
^ permalink raw reply
* Driver profiles RFC
From: Arkadi Sharshevsky @ 2017-08-08 13:15 UTC (permalink / raw)
To: netdev
Cc: David Miller, ivecera, roopa, Florian Fainelli, Vivien Didelot,
john.fastabend, Andrew Lunn, Jiri Pirko, mlxsw
Drivers may require driver specific information during the init stage.
For example, memory based shared resource which should be segmented for
different ASIC processes, such as FDB and LPM lookups.
The current mlxsw implementation assumes some default values, which are
const and cannot be changed due to lack of UAPI for its configuration
(module params is not an option). Those values can greatly impact the
scale of the hardware processes, such as the maximum sizes of the FDB/LPM
tables. Furthermore, those values should be consistent between driver
reloads.
The interface called DPIPE [1] was introduced in order to provide
abstraction of the hardware pipeline. This RFC letter suggests solving
this problem by enhancing the DPIPE hardware abstraction model.
DPIPE Resource
==============
In order to represent ASIC wide resources space a new object should be
introduced called "resource". It was originally suggested as future
extension in [1] in order to give the user visibility about the tables
limitation due to some shared resource. For example FDB and LPM share
a common hash based memory. This abstraction can be also used for
providing static configuration for such resources.
Resource
--------
The resource object defines generic hardware resource like memory,
counter pool, etc. which can be described by name and size. The resource
can be nested, for example the internal ASIC's memory can be split into
two parts, as can be seen in the following diagram:
+---------------+
| Internal Mem |
| |
| Size: 3M* |
+---------------+
/ \
/ \
/ \
/ \
/ \
+--------------+ +--------------+
| Linear | | Hash |
| | | |
| Size: 1M | | Size: 2M |
+--------------+ +--------------+
*The number are provided as an example and do not reflect real ASIC
resource sizes
Where the hash portion is used for FDB/LPM table lookups, and the linear
one is used by the routing adjacency table. Each resource can be described
by a name, size and list of children. Example for dumping the described
above structure:
#devlink dpipe resource dump tree pci/0000:03:00.0 Mem
{
"resource": {
"pci/0000:03:00.0": [{
"name": "Mem",
"size": 3M,
"resource": [{
"name": "Mem_Linear",
"size": "1M",
}, {
"name": "Mem_Hash",
"size": "2MK",
}
}]
}]
}
}
Each DPIPE table can be connected to one resource.
Driver <--> Devlink API
=======================
Each driver will register his resources with default values at init in
a similar way to DPIPE table registration. In case those resources already
exist the default values are discarded. The user will be able to dump and
update the resources. In order for the changes to take place the user will
need to re-initiate the driver by a specific devlink knob.
The above described procedure will require extra reload of the driver.
This can be improved as a future optimization.
UAPI
====
The user will be able to update the resources on a per resource basis:
$devlink dpipe resource set pci/0000:03:00.0 Mem_Linear 2M
For some resources the size is fixed, for example the size of the internal
memory cannot be changed. It is provided merely in order to reflect the
nested structure of the resource and to imply the user that Mem = Linear +
Hash, thus a set operation on it will fail.
The user can dump the current resource configuration:
#devlink dpipe resource dump tree pci/0000:03:00.0 Mem
The user can specify 'tree' in order to show all the nested resources under
the specified one. In case no 'resource name' is specified the TOP hierarchy
will be dumped.
After successful resource update the drivers hould be re-instantiated in
order for the changes to take place:
$devlink reload pci/0000:03:00.0
User Configuration
------------------
Such an UAPI is very low level, and thus an average user may not know how to
adjust this sizes according to his needs. The vendor can provide several
tested configuration files that the user can choose from. Each config file
will be measured in terms of: MAC addresses, L3 Neighbors (IPv4, IPv6),
LPM entries (IPv4,IPv6) in order to provide approximate results. By this an
average user will choose one of the provided ones. Furthermore, a more
advanced user could play with the numbers for his personal benefit.
Reference
=========
[1] https://netdevconf.org/2.1/papers/dpipe_netdev_2_1.odt
^ permalink raw reply
* Re: [net-next v1] net: ipv6: avoid overhead when no custom FIB rules are installed
From: Jiri Pirko @ 2017-08-08 12:51 UTC (permalink / raw)
To: Vincent Bernat
Cc: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, Jiri Pirko,
netdev, David Ahern
In-Reply-To: <20170808115121.21283-1-vincent@bernat.im>
Tue, Aug 08, 2017 at 01:51:21PM CEST, vincent@bernat.im wrote:
>If the user hasn't installed any custom rules, don't go through the
>whole FIB rules layer. This is pretty similar to f4530fa574df (ipv4:
>Avoid overhead when no custom FIB rules are installed).
>
>Using a micro-benchmark module [1], timing ip6_route_output() using
>get_cycles(), on my laptop with performance governor (so, subject to
>some caution due to thermal throttling), with 40,000 routes in the main
>routing table, before this patch:
>
> min=603 max=12477 count=627 average=1926 95th=4518 90th=3661 50th=1600 mad=724
> table=254 avgdepth=21.8 maxdepth=39
> value │ ┊ count
> 600 │▒▒▒▒▒▒▒▒▒▒ 134
> 860 │▒▒▒▒▒▒▒░░░░░░░░░░ 91
> 1120 │▒▒▒░░░░░░░░░░░░░░░░░░ 39
> 1380 │▒▒▒▒░░░░░░░░░░░░░░░░░░░░░ 58
> 1640 │▒▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░ 57
> 1900 │▒▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 58
> 2160 │▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 46
> 2420 │▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 26
> 2680 │▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 27
> 2940 │▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 15
> 3200 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 8
> 3460 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 8
> 3720 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 12
> 3980 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 9
> 4240 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 7
> 4500 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 6
>
>After:
>
> min=486 max=12390 count=627 average=1715 95th=4365 90th=3352 50th=1324 mad=631
> table=254 avgdepth=21.8 maxdepth=39
> value │ ┊ count
> 480 │▒▒▒▒▒▒▒▒▒▒▒▒ 153
> 730 │▒▒▒▒▒▒▒░░░░░░░░░░░░ 88
> 980 │▒▒▒▒░░░░░░░░░░░░░░░░░░░ 57
> 1230 │▒▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░ 56
> 1480 │▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 43
> 1730 │▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 50
> 1980 │▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 31
> 2230 │▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 23
> 2480 │▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 15
> 2730 │▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 23
> 2980 │▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 20
> 3230 │▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 14
> 3480 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 4
> 3730 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 8
> 3980 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 9
> 4230 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 4
Cool graphs!
>
>At the frequency of the laptop during the bench (~ 2.3 GHz), this is
>about a 130 ns difference on the median value and 50 ns on the minimal
>value.
>
>A next step would be to collapse local and main tables, as in
>0ddcf43d5d4a (ipv4: FIB Local/MAIN table collapse).
>
>[1]: https://github.com/vincentbernat/network-lab/blob/master/lab-routes-ipv6/kbench_mod.c
>
>Signed-off-by: Vincent Bernat <vincent@bernat.im>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [v2] rtlwifi: constify rate_control_ops structure
From: Kalle Valo @ 2017-08-08 11:53 UTC (permalink / raw)
To: Bhumika Goyal
Cc: julia.lawall, Larry.Finger, chaoming_li, linux-wireless, netdev,
linux-kernel, Bhumika Goyal
In-Reply-To: <1502082051-4904-1-git-send-email-bhumirks@gmail.com>
Bhumika Goyal <bhumirks@gmail.com> wrote:
> rate_control_ops structure is only passed as an argument to the
> function ieee80211_rate_control_{register/unregister}. This argument
> is of type const, so declare the structure as const.
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
cb1b82625de7 rtlwifi: constify rate_control_ops structure
--
https://patchwork.kernel.org/patch/9884393/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/2] wlcore: add const to bin_attribute structure
From: Kalle Valo @ 2017-08-08 11:52 UTC (permalink / raw)
To: Bhumika Goyal
Cc: julia.lawall, linux-wireless, netdev, linux-kernel, harish.patil,
manish.chopra, Dept-GELinuxNICDev, Bhumika Goyal
In-Reply-To: <1501696634-15765-2-git-send-email-bhumirks@gmail.com>
Bhumika Goyal <bhumirks@gmail.com> wrote:
> Add const to bin_attribute structure as it is only passed to the
> functions sysfs_{remove/create}_bin_file. The corresponding arguments
> are of type const, so declare the structure to be const.
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
4f2949febc22 wlcore: add const to bin_attribute structure
--
https://patchwork.kernel.org/patch/9877341/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [net-next v1] net: ipv6: avoid overhead when no custom FIB rules are installed
From: Vincent Bernat @ 2017-08-08 11:51 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, Jiri Pirko,
netdev, David Ahern
Cc: Vincent Bernat
If the user hasn't installed any custom rules, don't go through the
whole FIB rules layer. This is pretty similar to f4530fa574df (ipv4:
Avoid overhead when no custom FIB rules are installed).
Using a micro-benchmark module [1], timing ip6_route_output() using
get_cycles(), on my laptop with performance governor (so, subject to
some caution due to thermal throttling), with 40,000 routes in the main
routing table, before this patch:
min=603 max=12477 count=627 average=1926 95th=4518 90th=3661 50th=1600 mad=724
table=254 avgdepth=21.8 maxdepth=39
value │ ┊ count
600 │▒▒▒▒▒▒▒▒▒▒ 134
860 │▒▒▒▒▒▒▒░░░░░░░░░░ 91
1120 │▒▒▒░░░░░░░░░░░░░░░░░░ 39
1380 │▒▒▒▒░░░░░░░░░░░░░░░░░░░░░ 58
1640 │▒▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░ 57
1900 │▒▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 58
2160 │▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 46
2420 │▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 26
2680 │▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 27
2940 │▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 15
3200 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 8
3460 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 8
3720 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 12
3980 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 9
4240 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 7
4500 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 6
After:
min=486 max=12390 count=627 average=1715 95th=4365 90th=3352 50th=1324 mad=631
table=254 avgdepth=21.8 maxdepth=39
value │ ┊ count
480 │▒▒▒▒▒▒▒▒▒▒▒▒ 153
730 │▒▒▒▒▒▒▒░░░░░░░░░░░░ 88
980 │▒▒▒▒░░░░░░░░░░░░░░░░░░░ 57
1230 │▒▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░ 56
1480 │▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 43
1730 │▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 50
1980 │▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 31
2230 │▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 23
2480 │▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 15
2730 │▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 23
2980 │▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 20
3230 │▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 14
3480 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 4
3730 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 8
3980 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 9
4230 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 4
At the frequency of the laptop during the bench (~ 2.3 GHz), this is
about a 130 ns difference on the median value and 50 ns on the minimal
value.
A next step would be to collapse local and main tables, as in
0ddcf43d5d4a (ipv4: FIB Local/MAIN table collapse).
[1]: https://github.com/vincentbernat/network-lab/blob/master/lab-routes-ipv6/kbench_mod.c
Signed-off-by: Vincent Bernat <vincent@bernat.im>
---
include/net/netns/ipv6.h | 1 +
net/ipv6/fib6_rules.c | 34 ++++++++++++++++++++++++----------
net/ipv6/route.c | 1 +
3 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/include/net/netns/ipv6.h b/include/net/netns/ipv6.h
index abdf3b40303b..0e50bf3ed097 100644
--- a/include/net/netns/ipv6.h
+++ b/include/net/netns/ipv6.h
@@ -65,6 +65,7 @@ struct netns_ipv6 {
unsigned int ip6_rt_gc_expire;
unsigned long ip6_rt_last_gc;
#ifdef CONFIG_IPV6_MULTIPLE_TABLES
+ bool fib6_has_custom_rules;
struct rt6_info *ip6_prohibit_entry;
struct rt6_info *ip6_blk_hole_entry;
struct fib6_table *fib6_local_tbl;
diff --git a/net/ipv6/fib6_rules.c b/net/ipv6/fib6_rules.c
index 2f29e4e33bd3..693c27ede40e 100644
--- a/net/ipv6/fib6_rules.c
+++ b/net/ipv6/fib6_rules.c
@@ -63,19 +63,32 @@ unsigned int fib6_rules_seq_read(struct net *net)
struct dst_entry *fib6_rule_lookup(struct net *net, struct flowi6 *fl6,
int flags, pol_lookup_t lookup)
{
- struct fib_lookup_arg arg = {
- .lookup_ptr = lookup,
- .flags = FIB_LOOKUP_NOREF,
- };
-
/* update flow if oif or iif point to device enslaved to l3mdev */
l3mdev_update_flow(net, flowi6_to_flowi(fl6));
- fib_rules_lookup(net->ipv6.fib6_rules_ops,
- flowi6_to_flowi(fl6), flags, &arg);
-
- if (arg.result)
- return arg.result;
+ if (net->ipv6.fib6_has_custom_rules) {
+ struct fib_lookup_arg arg = {
+ .lookup_ptr = lookup,
+ .flags = FIB_LOOKUP_NOREF,
+ };
+
+ fib_rules_lookup(net->ipv6.fib6_rules_ops,
+ flowi6_to_flowi(fl6), flags, &arg);
+
+ if (arg.result)
+ return arg.result;
+ } else {
+ struct rt6_info *rt;
+
+ rt = lookup(net, net->ipv6.fib6_local_tbl, fl6, flags);
+ if (rt != net->ipv6.ip6_null_entry && rt->dst.error != -EAGAIN)
+ return &rt->dst;
+ ip6_rt_put(rt);
+ rt = lookup(net, net->ipv6.fib6_main_tbl, fl6, flags);
+ if (rt->dst.error != -EAGAIN)
+ return &rt->dst;
+ ip6_rt_put(rt);
+ }
dst_hold(&net->ipv6.ip6_null_entry->dst);
return &net->ipv6.ip6_null_entry->dst;
@@ -245,6 +258,7 @@ static int fib6_rule_configure(struct fib_rule *rule, struct sk_buff *skb,
rule6->dst.plen = frh->dst_len;
rule6->tclass = frh->tos;
+ net->ipv6.fib6_has_custom_rules = true;
err = 0;
errout:
return err;
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index aba07fce67fb..7ecbe5eb19f8 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -3934,6 +3934,7 @@ static int __net_init ip6_route_net_init(struct net *net)
ip6_template_metrics, true);
#ifdef CONFIG_IPV6_MULTIPLE_TABLES
+ net->ipv6.fib6_has_custom_rules = false;
net->ipv6.ip6_prohibit_entry = kmemdup(&ip6_prohibit_entry_template,
sizeof(*net->ipv6.ip6_prohibit_entry),
GFP_KERNEL);
--
2.13.3
^ permalink raw reply related
* Re: l3mdev: Support for sockets bound to enslaved device
From: Ondrej Zajicek @ 2017-08-08 11:29 UTC (permalink / raw)
To: David Ahern; +Cc: netdev
Hi
We noticed that TCP outgoing sockets that are bound to enslaved devices
by SO_BINDTODEVICE fail to connect, while they work when bound to vrf
device instead. We noticed similar behavior on ICMP (i.e. ping -I vrf0
worked, while ping -I eth0 does not if eth0 is enslaved to vrf0). On
the contrary, UDP outgoing sockets bound to enslaved devices worked
as expected. We tested that on Linux 4.9.30-2 from Debian.
I found your patchset 'Support for sockets bound to enslaved device'
( http://www.spinics.net/lists/netdev/msg448040.html ), which seems
to be related to the issue, but the description mentions services,
i.e. listening sockets. Does the patchset (or some other one) fixes
the issue also for outgoing sockets?
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
^ permalink raw reply
* Re: qmi_wwan: Null pointer dereference when removing driver
From: Nathaniel Roach @ 2017-08-08 11:32 UTC (permalink / raw)
To: Bjørn Mork; +Cc: netdev, Daniele Palmas
In-Reply-To: <87d1861h5x.fsf@miraculix.mork.no>
I probably should have put the model in the original report, but it's a
E371. I'll put it back in the machine and test it when I'm back home.
Thanks for the work!
On 08/08/17 18:35, Bjørn Mork wrote:
> Nathaniel Roach <nroach44@gmail.com> writes:
>
>> Unsure at which point was added, but issue not present in stock debian 4.11 kernel.
>>
>> Running on a Thinkpad X220 with coreboot.
>>
>> I'm building from upstream. When I attempt to remove the qmi_wwan module (which also happens pre-suspend) the rmmod process gets killed, and the following shows in dmesg:
>>
>> [ 59.979791] usb 2-1.4: USB disconnect, device number 4
>> [ 59.980102] qmi_wwan 2-1.4:1.6 wwp0s29u1u4i6: unregister 'qmi_wwan' usb-0000:00:1d.0-1.4, WWAN/QMI device
>> [ 60.006821] BUG: unable to handle kernel NULL pointer dereference at 00000000000000e0
>> [ 60.006879] IP: qmi_wwan_disconnect+0x25/0xc0 [qmi_wwan]
>> [ 60.006911] PGD 0
>> [ 60.006911] P4D 0
>> [ 60.006957] Oops: 0000 [#1] SMP
>> [ 60.006978] Modules linked in: fuse(E) ccm(E) rfcomm(E) cmac(E) bnep(E) qmi_wwan(E) cdc_wdm(E) cdc_ether(E) usbnet(E) mii(E) btusb(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) joydev(E) xpad(E) ecdh_generic(E) ff_memless(E) binfmt_misc(E) snd_hda_codec_hdmi(E) snd_hda_codec_conexant(E) snd_hda_codec_generic(E) arc4(E) iTCO_wdt(E) iTCO_vendor_support(E) intel_rapl(E) x86_pkg_temp_thermal(E) kvm_intel(E) kvm(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) ghash_clmulni_intel(E) aesni_intel(E) iwlmvm(E) aes_x86_64(E) crypto_simd(E) mac80211(E) cryptd(E) glue_helper(E) snd_hda_intel(E) snd_hda_codec(E) iwlwifi(E) snd_hwdep(E) psmouse(E) snd_hda_core(E) snd_pcm(E) serio_raw(E) sdhci_pci(E) pcspkr(E) snd_timer(E) ehci_pci(E) e1000e(E) i2c_i801(E) ehci_hcd(E) snd(E) sg(E
) i915(E) lpc_ich(E)
>> [ 60.007366] ptp(E) usbcore(E) cfg80211(E) mfd_core(E) pps_core(E) shpchp(E) ac(E) battery(E) tpm_tis(E) tpm_tis_core(E) evdev(E) tpm(E) parport_pc(E) ppdev(E) lp(E) parport(E) ip_tables(E) x_tables(E) autofs4(E)
>> [ 60.007474] CPU: 2 PID: 33 Comm: kworker/2:1 Tainted: G E 4.12.3-nr44-normandy-r1500619820+ #1
>> [ 60.007524] Hardware name: LENOVO 4291LR7/4291LR7, BIOS CBET4000 4.6-810-g50522254fb 07/21/2017
>> [ 60.007580] Workqueue: usb_hub_wq hub_event [usbcore]
>> [ 60.007609] task: ffff8c882b716040 task.stack: ffffb8e800d84000
>> [ 60.007644] RIP: 0010:qmi_wwan_disconnect+0x25/0xc0 [qmi_wwan]
>> [ 60.007678] RSP: 0018:ffffb8e800d87b38 EFLAGS: 00010246
>> [ 60.007711] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
>> [ 60.007752] RDX: 0000000000000001 RSI: ffff8c8824f3f1d0 RDI: ffff8c8824ef6400
>> [ 60.007792] RBP: ffff8c8824ef6400 R08: 0000000000000000 R09: 0000000000000000
>> [ 60.007833] R10: ffffb8e800d87780 R11: 0000000000000011 R12: ffffffffc07ea0e8
>> [ 60.007874] R13: ffff8c8824e2e000 R14: ffff8c8824e2e098 R15: 0000000000000000
>> [ 60.007915] FS: 0000000000000000(0000) GS:ffff8c8835300000(0000) knlGS:0000000000000000
>> [ 60.007960] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [ 60.007994] CR2: 00000000000000e0 CR3: 0000000229ca5000 CR4: 00000000000406e0
>> [ 60.008035] Call Trace:
>> [ 60.008065] ? usb_unbind_interface+0x71/0x270 [usbcore]
>> [ 60.008101] ? device_release_driver_internal+0x154/0x210
>> [ 60.008135] ? qmi_wwan_unbind+0x6d/0xc0 [qmi_wwan]
>> [ 60.008168] ? usbnet_disconnect+0x6c/0xf0 [usbnet]
>> [ 60.008194] ? qmi_wwan_disconnect+0x87/0xc0 [qmi_wwan]
>> [ 60.008232] ? usb_unbind_interface+0x71/0x270 [usbcore]
>> [ 60.008264] ? device_release_driver_internal+0x154/0x210
>> [ 60.008296] ? bus_remove_device+0xf5/0x160
>> [ 60.008324] ? device_del+0x1dc/0x310
>> [ 60.008355] ? usb_remove_ep_devs+0x1b/0x30 [usbcore]
>> [ 60.008393] ? usb_disable_device+0x93/0x250 [usbcore]
>> [ 60.008430] ? usb_disconnect+0x90/0x260 [usbcore]
>> [ 60.008468] ? hub_event+0x1d9/0x14a0 [usbcore]
>> [ 60.008500] ? process_one_work+0x175/0x370
>> [ 60.008528] ? worker_thread+0x4a/0x380
>> [ 60.008555] ? kthread+0xfc/0x130
>> [ 60.008579] ? process_one_work+0x370/0x370
>> [ 60.008606] ? kthread_park+0x60/0x60
>> [ 60.008631] ? ret_from_fork+0x22/0x30
>> [ 60.008656] Code: 66 0f 1f 44 00 00 66 66 66 66 90 55 48 89 fd 53 48 83 ec 10 48 8b 9f c8 00 00 00 65 48 8b 04 25 28 00 00 00 48 89 44 24 08 31 c0 <f6> 83 e0 00 00 00 02 74 51 e8 0d b3 2b cd 85 c0 74 67 48 8b bb
>> [ 60.011925] RIP: qmi_wwan_disconnect+0x25/0xc0 [qmi_wwan] RSP: ffffb8e800d87b38
>> [ 60.013564] CR2: 00000000000000e0
>> [ 60.022125] ---[ end trace e536b59f45bc0f25 ]---
>> [ 60.025385] IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready
>>
>> If I attempt a second rmmod, the process hangs. If I attempt it on 4.11.x it works as expected:
>>
>> [ 16.897783] fuse init (API version 7.26)
>> [ 68.073552] usbcore: deregistering interface driver qmi_wwan
>> [ 68.075808] qmi_wwan 2-1.4:1.6 wwp0s29u1u4i6: unregister 'qmi_wwan' usb-0000:00:1d.0-1.4, WWAN/QMI device
>> [ 72.431403] e1000e: enp0s25 NIC Link is Down
>>
>> So I'm pretty certain it's not coreboot causing the issue.
>
> Thanks a lot for the report! Just one question: Does your modem have
> separate control and data interfaces? If so, then I believe the
> attached patch will fix the issue. Are you able to test it?
>
> If the modem use the more common cobined interface model. then I need to
> investigate this further..
>
>
> Bjørn
^ permalink raw reply
* Re: [PATCH 0/6] In-kernel QMI handling
From: Marcel Holtmann @ 2017-08-08 11:13 UTC (permalink / raw)
To: Bjørn Mork
Cc: Bjorn Andersson, David S. Miller, Andy Gross, David Brown,
linux-arm-msm, linux-soc, Netdev list, linux-kernel
In-Reply-To: <8737921fw2.fsf@miraculix.mork.no>
Hi Bjorn,
>> This series starts by moving the common definitions of the QMUX protocol to the
>> uapi header, as they are shared with clients - both in kernel and userspace.
>>
>> This series then introduces in-kernel helper functions for aiding the handling
>> of QMI encoded messages in the kernel. QMI encoding is a wire-format used in
>> exchanging messages between the majority of QRTR clients and services.
>
> Interesting! I tried to add some QMI handling in the kernel a few years
> ago, but was thankfully voted down. See
> https://www.spinics.net/lists/netdev/msg183101.html and the following
> discussion. I am convinced that was the right decision, for the client
> side at least. The protocol is just too extensive and ever-growing to be
> implemented in the kernel. We would be catching up forever.
I think that even back then I said, that it has to be done as a proper subsystem if it has a chance to be in the kernel. So something similar to Phonet and CAIF where the service registration is handled by the kernel, but applications can be fully in userspace. None of this is actually brand new Qualcomm design since Nokia has had its Phonet long before QMI existed.
The real importance is that Qualcomm is behind this and wants to get this done a clean way with a proper API. The /dev/qmi thing was a pretty broken interface. Any subsystem has to support multiple QMI devices. Even if this is unlikely in a phone design, it has to be supported so that attaching two USB QMI based dongles does not end up with some pointless errors.
Regards
Marcel
^ permalink raw reply
* Re: ath9k: make ath_ps_ops structures as const
From: Kalle Valo @ 2017-08-08 11:09 UTC (permalink / raw)
To: Bhumika Goyal
Cc: julia.lawall, ath9k-devel, kvalo, linux-wireless, netdev,
linux-kernel, Bhumika Goyal
In-Reply-To: <1501772131-13038-1-git-send-email-bhumirks@gmail.com>
Bhumika Goyal <bhumirks@gmail.com> wrote:
> ath_ps_ops structures are only stored as a reference in the ps_ops
> field of a ath_common structure. This field is of type const, so make
> the structures as const.
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
3588e1110e49 ath9k: make ath_ps_ops structures as const
--
https://patchwork.kernel.org/patch/9879297/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: wcn36xx: Introduce mutual exclusion of fw configuration
From: Kalle Valo @ 2017-08-08 11:08 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Eugene Krasnikov, Kalle Valo, wcn36xx, linux-wireless, netdev,
linux-kernel, stable
In-Reply-To: <20170803012800.15974-1-bjorn.andersson@linaro.org>
Bjorn Andersson <bjorn.andersson@linaro.org> wrote:
> As the association status changes the driver needs to configure the
> hardware. This is done based on information in the "sta" acquired by
> ieee80211_find_sta(), which requires the caller to ensure that the "sta"
> is valid while its being used; generally by entering an rcu read
> section.
>
> But the operations acting on the "sta" has to communicate with the
> firmware and may therefor sleep, resulting in the following report:
>
> [ 31.418190] BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:238
> [ 31.425919] in_atomic(): 0, irqs_disabled(): 0, pid: 34, name:
> kworker/u8:1
> [ 31.434609] CPU: 0 PID: 34 Comm: kworker/u8:1 Tainted: G W
> 4.12.0-rc4-next-20170607+ #993
> [ 31.441002] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC
> (DT)
> [ 31.450380] Workqueue: phy0 ieee80211_iface_work
> [ 31.457226] Call trace:
> [ 31.461830] [<ffffff8008088c58>] dump_backtrace+0x0/0x260
> [ 31.464004] [<ffffff8008088f7c>] show_stack+0x14/0x20
> [ 31.469557] [<ffffff8008392e70>] dump_stack+0x98/0xb8
> [ 31.474592] [<ffffff80080e4330>] ___might_sleep+0xf0/0x118
> [ 31.479626] [<ffffff80080e43a8>] __might_sleep+0x50/0x88
> [ 31.485010] [<ffffff80088ff9a4>] mutex_lock+0x24/0x60
> [ 31.490479] [<ffffff8008595c38>] wcn36xx_smd_set_link_st+0x30/0x130
> [ 31.495428] [<ffffff8008591ed8>] wcn36xx_bss_info_changed+0x148/0x448
> [ 31.501504] [<ffffff80088ab3c4>]
> ieee80211_bss_info_change_notify+0xbc/0x118
> [ 31.508102] [<ffffff80088f841c>] ieee80211_assoc_success+0x664/0x7f8
> [ 31.515220] [<ffffff80088e13d4>]
> ieee80211_rx_mgmt_assoc_resp+0x144/0x2d8
> [ 31.521555] [<ffffff80088e1e20>]
> ieee80211_sta_rx_queued_mgmt+0x190/0x698
> [ 31.528239] [<ffffff80088bc44c>] ieee80211_iface_work+0x234/0x368
> [ 31.535011] [<ffffff80080d81ac>] process_one_work+0x1cc/0x340
> [ 31.541086] [<ffffff80080d8368>] worker_thread+0x48/0x430
> [ 31.546814] [<ffffff80080de448>] kthread+0x108/0x138
> [ 31.552195] [<ffffff8008082ec0>] ret_from_fork+0x10/0x50
>
> In order to ensure that the "sta" remains alive (and consistent) for the
> duration of bss_info_changed() mutual exclusion has to be ensured with
> sta_remove().
>
> This is done by introducing a mutex to cover firmware configuration
> changes, which is made to also ensure mutual exclusion between other
> operations changing the state or configuration of the firmware. With
> this we can drop the rcu read lock.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
39efc7cc7ccf wcn36xx: Introduce mutual exclusion of fw configuration
--
https://patchwork.kernel.org/patch/9877987/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v3] ath10k: ath10k_htt_rx_amsdu_allowed() use ath10k_dbg()
From: Kalle Valo @ 2017-08-08 11:06 UTC (permalink / raw)
To: Gabriel C
Cc: ath10k, ryanhsu, joe, linux-wireless, linux-kernel, netdev,
Gabriel Craciunescu
In-Reply-To: <20170719191955.11518-1-nix.or.die@gmail.com>
Gabriel C <nix.or.die@gmail.com> wrote:
> Each time we get disconnected from AP we get flooded with messages like:
>
> ...
> ath10k_pci 0000:03:00.0: no channel configured; ignoring frame(s)!
> <until ratelimit kicks in>
> ath10k_warn: 155 callbacks suppressed
> ...
>
> Use ath10k_dbg() here too.
>
> Signed-off-by: Gabriel Craciunescu <nix.or.die@gmail.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
984eb9053280 ath10k: ath10k_htt_rx_amsdu_allowed() use ath10k_dbg()
--
https://patchwork.kernel.org/patch/9853129/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 0/6] In-kernel QMI handling
From: Bjørn Mork @ 2017-08-08 11:02 UTC (permalink / raw)
To: Bjorn Andersson
Cc: David S. Miller, Andy Gross, David Brown, linux-arm-msm,
linux-soc, netdev, linux-kernel
In-Reply-To: <20170804145938.25427-1-bjorn.andersson@linaro.org>
Bjorn Andersson <bjorn.andersson@linaro.org> writes:
> This series starts by moving the common definitions of the QMUX protocol to the
> uapi header, as they are shared with clients - both in kernel and userspace.
>
> This series then introduces in-kernel helper functions for aiding the handling
> of QMI encoded messages in the kernel. QMI encoding is a wire-format used in
> exchanging messages between the majority of QRTR clients and services.
Interesting! I tried to add some QMI handling in the kernel a few years
ago, but was thankfully voted down. See
https://www.spinics.net/lists/netdev/msg183101.html and the following
discussion. I am convinced that was the right decision, for the client
side at least. The protocol is just too extensive and ever-growing to be
implemented in the kernel. We would be catching up forever.
Note that I had very limited knowledge of the protocol at the time I
wrote that driver. Still have, in fact :-)
Bjørn
^ 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