* [PATCH v2 net-next 0/2] do not allow adding routes if disable_ipv6 is enabled
From: Lorenzo Bianconi @ 2018-03-29 9:02 UTC (permalink / raw)
To: davem; +Cc: netdev
Do not allow userspace to add static ipv6 routes if disable_ipv6 is enabled.
Update disable_ipv6 documentation according to that change
Changes since v1:
- added an extack message telling the user that IPv6 is disabled on the nexthop
device
- rebased on-top of net-next
Lorenzo Bianconi (2):
ipv6: do not set routes if disable_ipv6 has been enabled
Documentation: ip-sysctl.txt: clarify disable_ipv6
Documentation/networking/ip-sysctl.txt | 4 +++-
net/ipv6/route.c | 6 ++++++
2 files changed, 9 insertions(+), 1 deletion(-)
--
2.14.3
^ permalink raw reply
* Re: [RFC PATCH ghak32 V2 01/13] audit: add container id
From: Richard Guy Briggs @ 2018-03-29 9:01 UTC (permalink / raw)
To: Jonathan Corbet
Cc: ebiederm-aS9lmoZGLiVWk0Htik3J/w, simo-H+wXaHxf7aLQT0dZR+AlfA,
jlayton-H+wXaHxf7aLQT0dZR+AlfA, carlos-H+wXaHxf7aLQT0dZR+AlfA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, LKML,
eparis-FjpueFixGhCM4zKIHC2jIg, dhowells-H+wXaHxf7aLQT0dZR+AlfA,
madzcar-Re5JQEeQqe8AvxtiuMwx3w, Linux-Audit Mailing List,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
luto-DgEjT+Ai2ygdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180328123912.49b11c98-T1hC0tSOHrs@public.gmane.org>
On 2018-03-28 12:39, Jonathan Corbet wrote:
> On Fri, 16 Mar 2018 05:00:28 -0400
> Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > Implement the proc fs write to set the audit container ID of a process,
> > emitting an AUDIT_CONTAINER record to document the event.
>
> A little detail, but still...
I am understanding that you would prefer more context (as opposed to
operational detail) in the description, laying out the use case for this
patch(set)?
> > +static int audit_set_containerid_perm(struct task_struct *task, u64 containerid)
> > +{
> > + struct task_struct *parent;
> > + u64 pcontainerid, ccontainerid;
> > +
> > + /* Don't allow to set our own containerid */
> > + if (current == task)
> > + return -EPERM;
> > + /* Don't allow the containerid to be unset */
> > + if (!cid_valid(containerid))
> > + return -EINVAL;
>
> I went looking for cid_valid(), but it turns out you don't add it until
> patch 5. That, I expect, will not be good for bisectability (or patch
> review).
Nice catch, thanks Jon. That is very likely another victim of a git
rebase to re-order afterthoughts in the right place. I'll need to be
more careful of that class of bug, rethink my workflow, or script builds
to verify each commit is compilable.
> Thanks,
>
> jon
- RGB
--
Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH 07/30] aio: add delayed cancel support
From: Christoph Hellwig @ 2018-03-29 8:53 UTC (permalink / raw)
To: Al Viro
Cc: Christoph Hellwig, Avi Kivity, linux-aio, linux-fsdevel, netdev,
linux-api, linux-kernel
In-Reply-To: <20180328163526.GV30522@ZenIV.linux.org.uk>
On Wed, Mar 28, 2018 at 05:35:26PM +0100, Al Viro wrote:
> > ret = vfs_fsync(req->file, req->datasync);
> > - fput(req->file);
> > - aio_complete(container_of(req, struct aio_kiocb, fsync), ret, 0);
> > + if (aio_complete(iocb, ret, 0, 0))
> > + fput(file);
>
> IDGI.
> 1) can aio_complete() ever return false here?
It won't. But sometimes checking the return value and sometimes not
seems like a bad pattern.
> 2) do we ever have aio_kiocb that would not have an associated
> struct file * that needs to be dropped on successful aio_complete()? AFAICS,
> rw, fsync and poll variants all have one, and I'm not sure what kind of
> async IO *could* be done without an opened file.
All have a file assoiated at least right now. As mentioned last time
finding a struct to pass that file would be rather annoying, so we'd either
have to pass it explicitly, or do something nasty like duplicating the
pointer in the aio_kiocb in addition to struct kiocb. Which might not
be that bad after all, as it would only bloat the aio_kiocb and not
struct kiocb used on stack all over.
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [PATCH net-next 0/6] net: Allow FIB notifiers to fail add and replace
From: Ido Schimmel @ 2018-03-29 8:29 UTC (permalink / raw)
To: David Ahern
Cc: netdev, davem, roopa, shm, jiri, idosch, jakub.kicinski,
andy.roulin
In-Reply-To: <20180328012200.15175-1-dsa@cumulusnetworks.com>
On Tue, Mar 27, 2018 at 06:21:54PM -0700, David Ahern wrote:
> I wanted to revisit how resource overload is handled for hardware offload
> of FIB entries and rules. At the moment, the in-kernel fib notifier can
> tell a driver about a route or rule add, replace, and delete, but the
> notifier can not affect the action. Specifically, in the case of mlxsw
> if a route or rule add is going to overflow the ASIC resources the only
> recourse is to abort hardware offload. Aborting offload is akin to taking
> down the switch as the path from data plane to the control plane simply
> can not support the traffic bandwidth of the front panel ports. Further,
> the current state of FIB notifiers is inconsistent with other resources
> where a driver can affect a user request - e.g., enslavement of a port
> into a bridge or a VRF.
>
> As a result of the work done over the past 3+ years, I believe we are
> at a point where we can bring consistency to the stack and offloads,
> and reliably allow the FIB notifiers to fail a request, pushing an error
> along with a suitable error message back to the user. Rather than
> aborting offload when the switch is out of resources, userspace is simply
> prevented from adding more routes and has a clear indication of why.
Nice work, David. Ran various tests and didn't see any regressions.
I know you already know this, but for the record, we plan to add
accounting to KVD hash resources which will eventually allow us to
return errors when resources are exceeded.
^ permalink raw reply
* Re: [PATCH net-next 5/6] net/ipv6: Move call_fib6_entry_notifiers up for route adds
From: Ido Schimmel @ 2018-03-29 8:23 UTC (permalink / raw)
To: David Ahern
Cc: netdev, davem, roopa, shm, jiri, idosch, jakub.kicinski,
andy.roulin
In-Reply-To: <20180328012200.15175-6-dsa@cumulusnetworks.com>
On Tue, Mar 27, 2018 at 06:21:59PM -0700, David Ahern wrote:
> Move call to call_fib6_entry_notifiers for new IPv6 routes to right
> before the insertion into the FIB. At this point notifier handlers can
> decide the fate of the new route with a clean path to delete the
> potential new entry if the notifier returns non-0.
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 4/6] net/ipv4: Allow notifier to fail route replace
From: Ido Schimmel @ 2018-03-29 8:23 UTC (permalink / raw)
To: David Ahern
Cc: netdev, davem, roopa, shm, jiri, idosch, jakub.kicinski,
andy.roulin
In-Reply-To: <20180328012200.15175-5-dsa@cumulusnetworks.com>
On Tue, Mar 27, 2018 at 06:21:58PM -0700, David Ahern wrote:
> Add checking to call to call_fib_entry_notifiers for IPv4 route replace.
> Allows a notifier handler to fail the replace.
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 3/6] net/ipv4: Move call_fib_entry_notifiers up for new routes
From: Ido Schimmel @ 2018-03-29 8:22 UTC (permalink / raw)
To: David Ahern
Cc: netdev, davem, roopa, shm, jiri, idosch, jakub.kicinski,
andy.roulin
In-Reply-To: <20180328012200.15175-4-dsa@cumulusnetworks.com>
On Tue, Mar 27, 2018 at 06:21:57PM -0700, David Ahern wrote:
> Move call to call_fib_entry_notifiers for new IPv4 routes to right
> before the call to fib_insert_alias. At this point the only remaining
> failure path is memory allocations in fib_insert_node. Handle that
> very unlikely failure with a call to call_fib_entry_notifiers to
> tell drivers about it.
>
> At this point notifier handlers can decide the fate of the new route
> with a clean path to delete the potential new entry if the notifier
> returns non-0.
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 2/6] net: Move call_fib_rule_notifiers up in fib_nl_newrule
From: Ido Schimmel @ 2018-03-29 8:22 UTC (permalink / raw)
To: David Ahern
Cc: netdev, davem, roopa, shm, jiri, idosch, jakub.kicinski,
andy.roulin
In-Reply-To: <20180328012200.15175-3-dsa@cumulusnetworks.com>
On Tue, Mar 27, 2018 at 06:21:56PM -0700, David Ahern wrote:
> Move call_fib_rule_notifiers up in fib_nl_newrule to the point right
> before the rule is inserted into the list. At this point there are no
> more failure paths within the core rule code, so if the notifier
> does not fail then the rule will be inserted into the list.
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
BTW, this means we can now return an error from mlxsw instead of only
emitting an extack warning when an unsupported FIB rule is configured.
Will add that.
^ permalink raw reply
* Re: [PATCH net-next 2/6] net: Move call_fib_rule_notifiers up in fib_nl_newrule
From: Ido Schimmel @ 2018-03-29 8:20 UTC (permalink / raw)
To: David Ahern
Cc: netdev, davem, roopa, shm, jiri, idosch, jakub.kicinski,
andy.roulin
In-Reply-To: <20180328012200.15175-3-dsa@cumulusnetworks.com>
On Tue, Mar 27, 2018 at 06:21:56PM -0700, David Ahern wrote:
> Move call_fib_rule_notifiers up in fib_nl_newrule to the point right
> before the rule is inserted into the list. At this point there are no
> more failure paths within the core rule code, so if the notifier
> does not fail then the rule will be inserted into the list.
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 1/6] net: Fix fib notifer to return errno
From: Ido Schimmel @ 2018-03-29 8:19 UTC (permalink / raw)
To: David Ahern
Cc: netdev, davem, roopa, shm, jiri, idosch, jakub.kicinski,
andy.roulin
In-Reply-To: <20180328012200.15175-2-dsa@cumulusnetworks.com>
On Tue, Mar 27, 2018 at 06:21:55PM -0700, David Ahern wrote:
> Notifier handlers use notifier_from_errno to convert any potential error
> to an encoded format. As a consequence the other side, call_fib_notifier{s}
> in this case, needs to use notifier_to_errno to return the error from
> the handler back to its caller.
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 1/2] ipv6: do not set routes if disable_ipv6 has been enabled
From: Lorenzo Bianconi @ 2018-03-29 8:19 UTC (permalink / raw)
To: David Ahern; +Cc: davem, netdev
In-Reply-To: <d7815ad8-c1a2-9444-deb9-b3a9c8fb3b50@gmail.com>
> On 3/27/18 11:11 AM, Lorenzo Bianconi wrote:
> > Do not allow to set ipv6 routes from userspace if disable_ipv6 has been
> > enabled. The issue can be triggered using the following reproducer:
> >
> > - sysctl net.ipv6.conf.all.disable_ipv6=1
> > - ip -6 route add a:b:c:d::/64 dev em1
> > - ip -6 route show
> > a:b:c:d::/64 dev em1 metric 1024 pref medium
> >
> > Fix it checking disable_ipv6 value in ip6_route_info_create routine
> >
> > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
> > ---
> > net/ipv6/route.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> > index 1d0eaa69874d..672fd7fdb037 100644
> > --- a/net/ipv6/route.c
> > +++ b/net/ipv6/route.c
> > @@ -2917,6 +2917,11 @@ static struct rt6_info *ip6_route_info_create(struct fib6_config *cfg,
> > if (!dev)
> > goto out;
> >
> > + if (idev->cnf.disable_ipv6) {
> > + err = -EACCES;
>
> you need an extack message telling the user that IPv6 is disabled on the
> nexthop device.
>
Ack, will do in v2.
Regards,
Lorenzo
> > + goto out;
> > + }
> > +
> > if (!(dev->flags & IFF_UP)) {
> > NL_SET_ERR_MSG(extack, "Nexthop device is not up");
> > err = -ENETDOWN;
> >
>
^ permalink raw reply
* Re: [PATCH net V2] vhost: correctly remove wait queue during poll failure
From: Jason Wang @ 2018-03-29 8:01 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, virtualization, netdev, linux-kernel, Darren Kenny
In-Reply-To: <20180329071801-mutt-send-email-mst@kernel.org>
On 2018年03月29日 12:20, Michael S. Tsirkin wrote:
> On Tue, Mar 27, 2018 at 08:50:52PM +0800, Jason Wang wrote:
>> We tried to remove vq poll from wait queue, but do not check whether
>> or not it was in a list before. This will lead double free. Fixing
>> this by switching to use vhost_poll_stop() which zeros poll->wqh after
>> removing poll from waitqueue to make sure it won't be freed twice.
>>
>> Cc: Darren Kenny<darren.kenny@oracle.com>
>> Reported-by:syzbot+c0272972b01b872e604a@syzkaller.appspotmail.com
>> Fixes: 2b8b328b61c79 ("vhost_net: handle polling errors when setting backend")
>> Signed-off-by: Jason Wang<jasowang@redhat.com>
> OK with this the only bug we have is where get user pages returns 0
> (Reported-by:syzbot+6304bf97ef436580fede@syzkaller.appspotmail.com)
>
>
>
Thanks for the reminder.
I post a patch to avoid this.
^ permalink raw reply
* [PATCH net] vhost: validate log when IOTLB is enabled
From: Jason Wang @ 2018-03-29 8:00 UTC (permalink / raw)
To: mst, jasowang; +Cc: netdev, linux-kernel, kvm, virtualization
Vq log_base is the userspace address of bitmap which has nothing to do
with IOTLB. So it needs to be validated unconditionally otherwise we
may try use 0 as log_base which may lead to pin pages that will lead
unexpected result (e.g trigger BUG_ON() in set_bit_to_user()).
Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API")
Reported-by: syzbot+6304bf97ef436580fede@syzkaller.appspotmail.com
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/vhost.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 5d5a9d9..5320039 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1244,14 +1244,12 @@ static int vq_log_access_ok(struct vhost_virtqueue *vq,
/* Caller should have vq mutex and device mutex */
int vhost_vq_access_ok(struct vhost_virtqueue *vq)
{
- if (vq->iotlb) {
- /* When device IOTLB was used, the access validation
- * will be validated during prefetching.
- */
- return 1;
- }
- return vq_access_ok(vq, vq->num, vq->desc, vq->avail, vq->used) &&
- vq_log_access_ok(vq, vq->log_base);
+ int ret = vq_log_access_ok(vq, vq->log_base);
+
+ if (ret || vq->iotlb)
+ return ret;
+
+ return vq_access_ok(vq, vq->num, vq->desc, vq->avail, vq->used);
}
EXPORT_SYMBOL_GPL(vhost_vq_access_ok);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] wcn36xx: Disable 5GHz for wcn3610
From: Kalle Valo @ 2018-03-29 7:45 UTC (permalink / raw)
To: Ramon Fried
Cc: loic.poulain, wcn36xx, linux-wireless, netdev, linux-kernel,
devicetree, bjorn.andersson
In-Reply-To: <2d978343-2057-8424-a249-83a0394da5a7@codeaurora.org>
(really adding Bjorn)
Ramon Fried <rfried@codeaurora.org> writes:
> (adding Bjorn Andersson)
>
>
> On 3/29/2018 10:15 AM, Kalle Valo wrote:
>> (adding devicetree list)
>>
>> Ramon Fried <rfried@codeaurora.org> writes:
>>
>>> wcn3610 can only operate on 2.4GHz band due to RF limitation.
>>> If wcn36xx digital block is associated with an external IRIS
>>> RF module, retrieve the id and disable 5GHz band in case of
>>> wcn3610 id.
>>>
>>> Signed-off-by: Ramon Fried <rfried@codeaurora.org>
>>> ---
>>> v2: fixed wrong assignment, which is logically introduces the
>>> same behaviour, but for correctness.
>>>
>>> drivers/net/wireless/ath/wcn36xx/main.c | 4 +++-
>>> drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 1 +
>>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c b/drivers/net/wireless/ath/wcn36xx/main.c
>>> index ab5be6d2c691..833531a68c95 100644
>>> --- a/drivers/net/wireless/ath/wcn36xx/main.c
>>> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
>>> @@ -1146,7 +1146,7 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
>>> BIT(NL80211_IFTYPE_MESH_POINT);
>>>
>>> wcn->hw->wiphy->bands[NL80211_BAND_2GHZ] = &wcn_band_2ghz;
>>> - if (wcn->rf_id != RF_IRIS_WCN3620)
>>> + if (wcn->rf_id != RF_IRIS_WCN3610 && wcn->rf_id != RF_IRIS_WCN3620)
>>> wcn->hw->wiphy->bands[NL80211_BAND_5GHZ] = &wcn_band_5ghz;
>>>
>>> wcn->hw->wiphy->max_scan_ssids = WCN36XX_MAX_SCAN_SSIDS;
>>> @@ -1248,6 +1248,8 @@ static int wcn36xx_platform_get_resources(struct wcn36xx *wcn,
>>> if (iris_node) {
>>> if (of_device_is_compatible(iris_node, "qcom,wcn3620"))
>>> wcn->rf_id = RF_IRIS_WCN3620;
>>> + else if (of_device_is_compatible(iris_node, "qcom,wcn3610"))
>>> + wcn->rf_id = RF_IRIS_WCN3610;
>>> of_node_put(iris_node);
>>> }
>> Should we document qcom,wcn3610 just like wcn3620 is:
>>
>> Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt:
>> "qcom,wcn3620",
>
> IMHO the mentioned bindings is related to the PIL (peripheral image
> loaded) which is just the firmware part and has
> nothing to do with wifi frontend(IRIS).
Should we then have a bindings document for wcn36xx or is it ok to use
compatible strings like this without any docs? I'm not very familiar
with the devicetree stuff.
--
Kalle Valo
^ permalink raw reply
* Re: [EXT] [PATCH net-next v2 0/2] phylink: API changes
From: Russell King - ARM Linux @ 2018-03-29 7:44 UTC (permalink / raw)
To: Yan Markman
Cc: Florian Fainelli, netdev@vger.kernel.org, Thomas Petazzoni,
Andrew Lunn, David S. Miller, open list, Antoine Tenart,
Stefan Chulski, Maxime Chevallier, Miquel Raynal, Marcin Wojtas,
Yelena Krivosheev
In-Reply-To: <98b31575864f474fa7177c39ff06f81b@IL-EXCH01.marvell.com>
On Thu, Mar 29, 2018 at 05:58:43AM +0000, Yan Markman wrote:
> Hi Florian
> Please keep CC Yelena Krivosheev <yelena@marvell.com>
> for changes with drivers/net/ethernet/marvell/mvneta.c
> Thanks
We have a way to ensure such things happen - it's the MAINTAINERS
file. Please use the established community methods rather than
sending emails asking for people to remember such quirks. Thanks.
> Yan Markman
> Tel. 05-44732819
>
>
> -----Original Message-----
> From: Florian Fainelli [mailto:f.fainelli@gmail.com]
> Sent: Thursday, March 29, 2018 1:44 AM
> To: netdev@vger.kernel.org
> Cc: Florian Fainelli <f.fainelli@gmail.com>; Thomas Petazzoni <thomas.petazzoni@free-electrons.com>; Andrew Lunn <andrew@lunn.ch>; David S. Miller <davem@davemloft.net>; Russell King <rmk+kernel@armlinux.org.uk>; open list <linux-kernel@vger.kernel.org>; Antoine Tenart <antoine.tenart@bootlin.com>; Yan Markman <ymarkman@marvell.com>; Stefan Chulski <stefanc@marvell.com>; Maxime Chevallier <maxime.chevallier@bootlin.com>; Miquel Raynal <miquel.raynal@free-electrons.com>; Marcin Wojtas <mw@semihalf.com>
> Subject: [EXT] [PATCH net-next v2 0/2] phylink: API changes
>
> External Email
>
> ----------------------------------------------------------------------
> Hi all,
>
> This patch series contains two API changes to PHYLINK which will later be used by DSA to migrate to PHYLINK. Because these are API changes that impact other outstanding work (e.g: MVPP2) I would rather get them included sooner to minimize conflicts.
>
> Thank you!
>
> Changes in v2:
>
> - added missing documentation to mac_link_{up,down} that the interface
> must be configured in mac_config()
>
> - added Russell's, Andrew's and my tags
>
> Florian Fainelli (1):
> net: phy: phylink: Provide PHY interface to mac_link_{up,down}
>
> Russell King (1):
> sfp/phylink: move module EEPROM ethtool access into netdev core
> ethtool
>
> drivers/net/ethernet/marvell/mvneta.c | 22 +++-------------------
> drivers/net/phy/phylink.c | 32 +++-----------------------------
> drivers/net/phy/sfp-bus.c | 6 ++----
> include/linux/netdevice.h | 3 +++
> include/linux/phylink.h | 17 +++++++++++------
> net/core/ethtool.c | 7 +++++++
> 6 files changed, 29 insertions(+), 58 deletions(-)
>
> --
> 2.14.1
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net: systemport: Fix coalescing settings handling
From: Tal Gilboa @ 2018-03-29 7:42 UTC (permalink / raw)
To: Florian Fainelli, netdev
Cc: davem, jaedon.shin, pgynther, opendmb, Michael Chan, gospo,
saeedm
In-Reply-To: <20180328221538.29290-3-f.fainelli@gmail.com>
On 3/29/2018 1:15 AM, Florian Fainelli wrote:
> There were a number of issues with setting the RX coalescing parameters:
>
> - we would not be preserving values that would have been configured
> across close/open calls, instead we would always reset to no timeout
> and 1 interrupt per packet, this would also prevent DIM from setting its
> default usec/pkts values
>
> - when adaptive RX would be turned on, we woud not be fetching the
> default parameters, we would stay with no timeout/1 packet per
> interrupt until the estimator kicks in and changes that
>
> - finally disabling adaptive RX coalescing while providing parameters
> would not be honored, and we would stay with whatever DIM had
> previously determined instead of the user requested parameters
>
> Fixes: b6e0e875421e ("net: systemport: Implement adaptive interrupt coalescing")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/ethernet/broadcom/bcmsysport.c | 62 +++++++++++++++++++++---------
> drivers/net/ethernet/broadcom/bcmsysport.h | 4 +-
> 2 files changed, 46 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c
> index 1e52bb7d822e..4a75b1de22e0 100644
> --- a/drivers/net/ethernet/broadcom/bcmsysport.c
> +++ b/drivers/net/ethernet/broadcom/bcmsysport.c
> @@ -574,16 +574,16 @@ static int bcm_sysport_set_wol(struct net_device *dev,
> return 0;
> }
>
> -static void bcm_sysport_set_rx_coalesce(struct bcm_sysport_priv *priv)
> +static void bcm_sysport_set_rx_coalesce(struct bcm_sysport_priv *priv,
> + u32 usecs, u32 pkts)
> {
> u32 reg;
>
> reg = rdma_readl(priv, RDMA_MBDONE_INTR);
> reg &= ~(RDMA_INTR_THRESH_MASK |
> RDMA_TIMEOUT_MASK << RDMA_TIMEOUT_SHIFT);
> - reg |= priv->dim.coal_pkts;
> - reg |= DIV_ROUND_UP(priv->dim.coal_usecs * 1000, 8192) <<
> - RDMA_TIMEOUT_SHIFT;
> + reg |= pkts;
> + reg |= DIV_ROUND_UP(usecs * 1000, 8192) << RDMA_TIMEOUT_SHIFT;
> rdma_writel(priv, reg, RDMA_MBDONE_INTR);
> }
>
> @@ -626,6 +626,8 @@ static int bcm_sysport_set_coalesce(struct net_device *dev,
> struct ethtool_coalesce *ec)
> {
> struct bcm_sysport_priv *priv = netdev_priv(dev);
> + struct net_dim_cq_moder moder;
> + u32 usecs, pkts;
> unsigned int i;
>
> /* Base system clock is 125Mhz, DMA timeout is this reference clock
> @@ -646,15 +648,21 @@ static int bcm_sysport_set_coalesce(struct net_device *dev,
> for (i = 0; i < dev->num_tx_queues; i++)
> bcm_sysport_set_tx_coalesce(&priv->tx_rings[i], ec);
>
> - priv->dim.coal_usecs = ec->rx_coalesce_usecs;
> - priv->dim.coal_pkts = ec->rx_max_coalesced_frames;
> + priv->rx_coalesce_usecs = ec->rx_coalesce_usecs;
> + priv->rx_max_coalesced_frames = ec->rx_max_coalesced_frames;
> + usecs = priv->rx_coalesce_usecs;
> + pkts = priv->rx_max_coalesced_frames;
>
> - if (!ec->use_adaptive_rx_coalesce && priv->dim.use_dim) {
> - priv->dim.coal_pkts = 1;
> - priv->dim.coal_usecs = 0;
> + if (ec->use_adaptive_rx_coalesce && !priv->dim.use_dim) {
> + moder = net_dim_get_def_profile(priv->dim.dim.mode);
> + usecs = moder.usec;
> + pkts = moder.pkts;
> }
> +
> priv->dim.use_dim = ec->use_adaptive_rx_coalesce;
> - bcm_sysport_set_rx_coalesce(priv);
> +
> + /* Apply desired coalescing parameters */
> + bcm_sysport_set_rx_coalesce(priv, usecs, pkts);
>
> return 0;
> }
> @@ -1058,10 +1066,7 @@ static void bcm_sysport_dim_work(struct work_struct *work)
> struct net_dim_cq_moder cur_profile =
> net_dim_get_profile(dim->mode, dim->profile_ix);
>
> - priv->dim.coal_usecs = cur_profile.usec;
> - priv->dim.coal_pkts = cur_profile.pkts;
> -
> - bcm_sysport_set_rx_coalesce(priv);
> + bcm_sysport_set_rx_coalesce(priv, cur_profile.usec, cur_profile.pkts);
> dim->state = NET_DIM_START_MEASURE;
> }
>
> @@ -1408,9 +1413,11 @@ static void bcm_sysport_adj_link(struct net_device *dev)
> phy_print_status(phydev);
> }
>
> -static void bcm_sysport_init_dim(struct bcm_sysport_net_dim *dim,
> +static void bcm_sysport_init_dim(struct bcm_sysport_priv *priv,
> void (*cb)(struct work_struct *work))
> {
> + struct bcm_sysport_net_dim *dim = &priv->dim;
> +
> INIT_WORK(&dim->dim.work, cb);
> dim->dim.mode = NET_DIM_CQ_PERIOD_MODE_START_FROM_EQE;
> dim->event_ctr = 0;
> @@ -1418,6 +1425,25 @@ static void bcm_sysport_init_dim(struct bcm_sysport_net_dim *dim,
> dim->bytes = 0;
> }
>
> +static void bcm_sysport_init_rx_coalesce(struct bcm_sysport_priv *priv)
> +{
> + struct bcm_sysport_net_dim *dim = &priv->dim;
> + struct net_dim_cq_moder moder;
> + u32 usecs, pkts;
> +
> + usecs = priv->rx_coalesce_usecs;
> + pkts = priv->rx_max_coalesced_frames;
> +
> + /* If DIM was enabled, re-apply default parameters */
> + if (dim->use_dim) {
> + moder = net_dim_get_def_profile(dim->dim.mode);
> + usecs = moder.usec;
> + pkts = moder.pkts;
> + }
> +
> + bcm_sysport_set_rx_coalesce(priv, usecs, pkts);
> +}
> +
> static int bcm_sysport_init_tx_ring(struct bcm_sysport_priv *priv,
> unsigned int index)
> {
> @@ -1658,8 +1684,6 @@ static int bcm_sysport_init_rx_ring(struct bcm_sysport_priv *priv)
> rdma_writel(priv, 0, RDMA_END_ADDR_HI);
> rdma_writel(priv, priv->num_rx_desc_words - 1, RDMA_END_ADDR_LO);
>
> - rdma_writel(priv, 1, RDMA_MBDONE_INTR);
> -
> netif_dbg(priv, hw, priv->netdev,
> "RDMA cfg, num_rx_bds=%d, rx_bds=%p\n",
> priv->num_rx_bds, priv->rx_bds);
> @@ -1827,7 +1851,8 @@ static void bcm_sysport_netif_start(struct net_device *dev)
> struct bcm_sysport_priv *priv = netdev_priv(dev);
>
> /* Enable NAPI */
> - bcm_sysport_init_dim(&priv->dim, bcm_sysport_dim_work);
> + bcm_sysport_init_dim(priv, bcm_sysport_dim_work);
> + bcm_sysport_init_rx_coalesce(priv);
> napi_enable(&priv->napi);
>
> /* Enable RX interrupt and TX ring full interrupt */
> @@ -2333,6 +2358,7 @@ static int bcm_sysport_probe(struct platform_device *pdev)
> /* libphy will adjust the link state accordingly */
> netif_carrier_off(dev);
>
> + priv->rx_max_coalesced_frames = 1;
Do you still want to keep {usecs,frames}={0,1} as default static
configuration? Is the latency so important for the static case? I'm
assuming RT latency is at least 10us so you can somewhat increase the
timer and counter without causing an increase in latency. This should be
properly tested of course so maybe in a future patch.
> u64_stats_init(&priv->syncp);
>
> priv->dsa_notifier.notifier_call = bcm_sysport_dsa_notifier;
> diff --git a/drivers/net/ethernet/broadcom/bcmsysport.h b/drivers/net/ethernet/broadcom/bcmsysport.h
> index 57e18ef8f206..d6e5d0cbf3a3 100644
> --- a/drivers/net/ethernet/broadcom/bcmsysport.h
> +++ b/drivers/net/ethernet/broadcom/bcmsysport.h
> @@ -701,8 +701,6 @@ struct bcm_sysport_net_dim {
> u16 event_ctr;
> unsigned long packets;
> unsigned long bytes;
> - u32 coal_usecs;
> - u32 coal_pkts;
> struct net_dim dim;
> };
>
> @@ -755,6 +753,8 @@ struct bcm_sysport_priv {
> unsigned int rx_c_index;
>
> struct bcm_sysport_net_dim dim;
> + u32 rx_max_coalesced_frames;
> + u32 rx_coalesce_usecs;
>
> /* PHY device */
> struct device_node *phy_dn;
>
Reviewed-by: Tal Gilboa <talgi@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: bcmgenet: Fix coalescing settings handling
From: Tal Gilboa @ 2018-03-29 7:42 UTC (permalink / raw)
To: Florian Fainelli, netdev
Cc: davem, jaedon.shin, pgynther, opendmb, Michael Chan, gospo,
saeedm
In-Reply-To: <20180328221538.29290-4-f.fainelli@gmail.com>
On 3/29/2018 1:15 AM, Florian Fainelli wrote:
> There were a number of issues with setting the RX coalescing parameters:
>
> - we would not be preserving values that would have been configured
> across close/open calls, instead we would always reset to no timeout
> and 1 interrupt per packet, this would also prevent DIM from setting its
> default usec/pkts values
>
> - when adaptive RX would be turned on, we woud not be fetching the
> default parameters, we would stay with no timeout/1 packet per interrupt
> until the estimator kicks in and changes that
>
> - finally disabling adaptive RX coalescing while providing parameters
> would not be honored, and we would stay with whatever DIM had previously
> determined instead of the user requested parameters
>
> Fixes: 9f4ca05827a2 ("net: bcmgenet: Add support for adaptive RX coalescing")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/ethernet/broadcom/genet/bcmgenet.c | 92 +++++++++++++++++---------
> drivers/net/ethernet/broadcom/genet/bcmgenet.h | 4 +-
> 2 files changed, 61 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> index 7db8edc643ec..f8af472f324f 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> @@ -625,26 +625,46 @@ static int bcmgenet_get_coalesce(struct net_device *dev,
> return 0;
> }
>
> -static void bcmgenet_set_rx_coalesce(struct bcmgenet_rx_ring *ring)
> +static void bcmgenet_set_rx_coalesce(struct bcmgenet_rx_ring *ring,
> + u32 usecs, u32 pkts)
> {
> struct bcmgenet_priv *priv = ring->priv;
> unsigned int i = ring->index;
> u32 reg;
>
> - bcmgenet_rdma_ring_writel(priv, i, ring->dim.coal_pkts,
> - DMA_MBUF_DONE_THRESH);
> + bcmgenet_rdma_ring_writel(priv, i, pkts, DMA_MBUF_DONE_THRESH);
>
> reg = bcmgenet_rdma_readl(priv, DMA_RING0_TIMEOUT + i);
> reg &= ~DMA_TIMEOUT_MASK;
> - reg |= DIV_ROUND_UP(ring->dim.coal_usecs * 1000, 8192);
> + reg |= DIV_ROUND_UP(usecs * 1000, 8192);
> bcmgenet_rdma_writel(priv, reg, DMA_RING0_TIMEOUT + i);
> }
>
> +static void bcmgenet_set_ring_rx_coalesce(struct bcmgenet_rx_ring *ring,
> + struct ethtool_coalesce *ec)
> +{
> + struct net_dim_cq_moder moder;
> + u32 usecs, pkts;
> +
> + ring->rx_coalesce_usecs = ec->rx_coalesce_usecs;
> + ring->rx_max_coalesced_frames = ec->rx_max_coalesced_frames;
> + usecs = ring->rx_coalesce_usecs;
> + pkts = ring->rx_max_coalesced_frames;
> +
> + if (ec->use_adaptive_rx_coalesce && !ring->dim.use_dim) {
> + moder = net_dim_get_def_profile(ring->dim.dim.mode);
> + usecs = moder.usec;
> + pkts = moder.pkts;
> + }
> +
> + ring->dim.use_dim = ec->use_adaptive_rx_coalesce;
> + bcmgenet_set_rx_coalesce(ring, usecs, pkts);
> +}
> +
> static int bcmgenet_set_coalesce(struct net_device *dev,
> struct ethtool_coalesce *ec)
> {
> struct bcmgenet_priv *priv = netdev_priv(dev);
> - struct bcmgenet_rx_ring *ring;
> unsigned int i;
>
> /* Base system clock is 125Mhz, DMA timeout is this reference clock
> @@ -680,27 +700,9 @@ static int bcmgenet_set_coalesce(struct net_device *dev,
> ec->tx_max_coalesced_frames,
> DMA_MBUF_DONE_THRESH);
>
> - for (i = 0; i < priv->hw_params->rx_queues; i++) {
> - ring = &priv->rx_rings[i];
> - ring->dim.coal_usecs = ec->rx_coalesce_usecs;
> - ring->dim.coal_pkts = ec->rx_max_coalesced_frames;
> - if (!ec->use_adaptive_rx_coalesce && ring->dim.use_dim) {
> - ring->dim.coal_pkts = 1;
> - ring->dim.coal_usecs = 0;
> - }
> - ring->dim.use_dim = ec->use_adaptive_rx_coalesce;
> - bcmgenet_set_rx_coalesce(ring);
> - }
> -
> - ring = &priv->rx_rings[DESC_INDEX];
> - ring->dim.coal_usecs = ec->rx_coalesce_usecs;
> - ring->dim.coal_pkts = ec->rx_max_coalesced_frames;
> - if (!ec->use_adaptive_rx_coalesce && ring->dim.use_dim) {
> - ring->dim.coal_pkts = 1;
> - ring->dim.coal_usecs = 0;
> - }
> - ring->dim.use_dim = ec->use_adaptive_rx_coalesce;
> - bcmgenet_set_rx_coalesce(ring);
> + for (i = 0; i < priv->hw_params->rx_queues; i++)
> + bcmgenet_set_ring_rx_coalesce(&priv->rx_rings[i], ec);
> + bcmgenet_set_ring_rx_coalesce(&priv->rx_rings[DESC_INDEX], ec);
>
> return 0;
> }
> @@ -1924,10 +1926,7 @@ static void bcmgenet_dim_work(struct work_struct *work)
> struct net_dim_cq_moder cur_profile =
> net_dim_get_profile(dim->mode, dim->profile_ix);
>
> - ring->dim.coal_usecs = cur_profile.usec;
> - ring->dim.coal_pkts = cur_profile.pkts;
> -
> - bcmgenet_set_rx_coalesce(ring);
> + bcmgenet_set_rx_coalesce(ring, cur_profile.usec, cur_profile.pkts);
> dim->state = NET_DIM_START_MEASURE;
> }
>
> @@ -2079,9 +2078,11 @@ static void init_umac(struct bcmgenet_priv *priv)
> dev_dbg(kdev, "done init umac\n");
> }
>
> -static void bcmgenet_init_dim(struct bcmgenet_net_dim *dim,
> +static void bcmgenet_init_dim(struct bcmgenet_rx_ring *ring,
> void (*cb)(struct work_struct *work))
> {
> + struct bcmgenet_net_dim *dim = &ring->dim;
> +
> INIT_WORK(&dim->dim.work, cb);
> dim->dim.mode = NET_DIM_CQ_PERIOD_MODE_START_FROM_EQE;
> dim->event_ctr = 0;
> @@ -2089,6 +2090,25 @@ static void bcmgenet_init_dim(struct bcmgenet_net_dim *dim,
> dim->bytes = 0;
> }
>
> +static void bcmgenet_init_rx_coalesce(struct bcmgenet_rx_ring *ring)
> +{
> + struct bcmgenet_net_dim *dim = &ring->dim;
> + struct net_dim_cq_moder moder;
> + u32 usecs, pkts;
> +
> + usecs = ring->rx_coalesce_usecs;
> + pkts = ring->rx_max_coalesced_frames;
> +
> + /* If DIM was enabled, re-apply default parameters */
> + if (dim->use_dim) {
> + moder = net_dim_get_def_profile(dim->dim.mode);
> + usecs = moder.usec;
> + pkts = moder.pkts;
> + }
> +
> + bcmgenet_set_rx_coalesce(ring, usecs, pkts);
> +}
> +
> /* Initialize a Tx ring along with corresponding hardware registers */
> static void bcmgenet_init_tx_ring(struct bcmgenet_priv *priv,
> unsigned int index, unsigned int size,
> @@ -2178,7 +2198,8 @@ static int bcmgenet_init_rx_ring(struct bcmgenet_priv *priv,
> if (ret)
> return ret;
>
> - bcmgenet_init_dim(&ring->dim, bcmgenet_dim_work);
> + bcmgenet_init_dim(ring, bcmgenet_dim_work);
> + bcmgenet_init_rx_coalesce(ring);
>
> /* Initialize Rx NAPI */
> netif_napi_add(priv->dev, &ring->napi, bcmgenet_rx_poll,
> @@ -2186,7 +2207,6 @@ static int bcmgenet_init_rx_ring(struct bcmgenet_priv *priv,
>
> bcmgenet_rdma_ring_writel(priv, index, 0, RDMA_PROD_INDEX);
> bcmgenet_rdma_ring_writel(priv, index, 0, RDMA_CONS_INDEX);
> - bcmgenet_rdma_ring_writel(priv, index, 1, DMA_MBUF_DONE_THRESH);
> bcmgenet_rdma_ring_writel(priv, index,
> ((size << DMA_RING_SIZE_SHIFT) |
> RX_BUF_LENGTH), DMA_RING_BUF_SIZE);
> @@ -3424,6 +3444,7 @@ static int bcmgenet_probe(struct platform_device *pdev)
> struct net_device *dev;
> const void *macaddr;
> struct resource *r;
> + unsigned int i;
> int err = -EIO;
> const char *phy_mode_str;
>
> @@ -3552,6 +3573,11 @@ static int bcmgenet_probe(struct platform_device *pdev)
> netif_set_real_num_tx_queues(priv->dev, priv->hw_params->tx_queues + 1);
> netif_set_real_num_rx_queues(priv->dev, priv->hw_params->rx_queues + 1);
>
> + /* Set default coalescing parameters */
> + for (i = 0; i < priv->hw_params->rx_queues; i++)
> + priv->rx_rings[i].rx_max_coalesced_frames = 1;
> + priv->rx_rings[DESC_INDEX].rx_max_coalesced_frames = 1;
> +
Do you still want to keep {usecs,frames}={0,1} as default static
configuration? Is the latency so important for the static case? I'm
assuming RT latency is at least 10us so you can somewhat increase the
timer and counter without causing an increase in latency. This should be
properly tested of course so maybe in a future patch.
> /* libphy will determine the link state */
> netif_carrier_off(dev);
>
> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.h b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
> index 22c41e0430fb..b773bc07edf7 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.h
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
> @@ -578,8 +578,6 @@ struct bcmgenet_net_dim {
> u16 event_ctr;
> unsigned long packets;
> unsigned long bytes;
> - u32 coal_usecs;
> - u32 coal_pkts;
> struct net_dim dim;
> };
>
> @@ -598,6 +596,8 @@ struct bcmgenet_rx_ring {
> unsigned int end_ptr; /* Rx ring end CB ptr */
> unsigned int old_discards;
> struct bcmgenet_net_dim dim;
> + u32 rx_max_coalesced_frames;
> + u32 rx_coalesce_usecs;
> void (*int_enable)(struct bcmgenet_rx_ring *);
> void (*int_disable)(struct bcmgenet_rx_ring *);
> struct bcmgenet_priv *priv;
>
Reviewed-by: Tal Gilboa <talgi@mellanox.com>
^ permalink raw reply
* Re: [PATCH v2] wcn36xx: Disable 5GHz for wcn3610
From: Loic Poulain @ 2018-03-29 7:40 UTC (permalink / raw)
To: Ramon Fried
Cc: Kalle Valo, wcn36xx, linux-wireless, netdev, linux-kernel,
devicetree
In-Reply-To: <2d978343-2057-8424-a249-83a0394da5a7@codeaurora.org>
Hi Ramon,
On 29 March 2018 at 09:32, Ramon Fried <rfried@codeaurora.org> wrote:
>> Should we document qcom,wcn3610 just like wcn3620 is:
>>
>> Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt: "qcom,wcn3620",
> IMHO the mentioned bindings is related to the PIL (peripheral image loaded) which is just the firmware part and has
> nothing to do with wifi frontend(IRIS).
>
It seems that the RF is a subnode of the PIL node:
"= SUBNODES
A required subnode of the WCNSS PIL is used to describe the attached rf module
and its resource dependencies. It is described by the following properties:"
So we should add qcom,wcn3610 to the exiting list of 'compatible' rf modules.
Regards,
Loic
^ permalink raw reply
* Re: [PATCH v2] wcn36xx: Disable 5GHz for wcn3610
From: Ramon Fried @ 2018-03-29 7:32 UTC (permalink / raw)
To: Kalle Valo
Cc: loic.poulain, wcn36xx, linux-wireless, netdev, linux-kernel,
devicetree
In-Reply-To: <874lkzmjxu.fsf@kamboji.qca.qualcomm.com>
(adding Bjorn Andersson)
On 3/29/2018 10:15 AM, Kalle Valo wrote:
> (adding devicetree list)
>
> Ramon Fried <rfried@codeaurora.org> writes:
>
>> wcn3610 can only operate on 2.4GHz band due to RF limitation.
>> If wcn36xx digital block is associated with an external IRIS
>> RF module, retrieve the id and disable 5GHz band in case of
>> wcn3610 id.
>>
>> Signed-off-by: Ramon Fried <rfried@codeaurora.org>
>> ---
>> v2: fixed wrong assignment, which is logically introduces the
>> same behaviour, but for correctness.
>>
>> drivers/net/wireless/ath/wcn36xx/main.c | 4 +++-
>> drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 1 +
>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c b/drivers/net/wireless/ath/wcn36xx/main.c
>> index ab5be6d2c691..833531a68c95 100644
>> --- a/drivers/net/wireless/ath/wcn36xx/main.c
>> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
>> @@ -1146,7 +1146,7 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
>> BIT(NL80211_IFTYPE_MESH_POINT);
>>
>> wcn->hw->wiphy->bands[NL80211_BAND_2GHZ] = &wcn_band_2ghz;
>> - if (wcn->rf_id != RF_IRIS_WCN3620)
>> + if (wcn->rf_id != RF_IRIS_WCN3610 && wcn->rf_id != RF_IRIS_WCN3620)
>> wcn->hw->wiphy->bands[NL80211_BAND_5GHZ] = &wcn_band_5ghz;
>>
>> wcn->hw->wiphy->max_scan_ssids = WCN36XX_MAX_SCAN_SSIDS;
>> @@ -1248,6 +1248,8 @@ static int wcn36xx_platform_get_resources(struct wcn36xx *wcn,
>> if (iris_node) {
>> if (of_device_is_compatible(iris_node, "qcom,wcn3620"))
>> wcn->rf_id = RF_IRIS_WCN3620;
>> + else if (of_device_is_compatible(iris_node, "qcom,wcn3610"))
>> + wcn->rf_id = RF_IRIS_WCN3610;
>> of_node_put(iris_node);
>> }
> Should we document qcom,wcn3610 just like wcn3620 is:
>
> Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt: "qcom,wcn3620",
IMHO the mentioned bindings is related to the PIL (peripheral image loaded) which is just the firmware part and has
nothing to do with wifi frontend(IRIS).
^ permalink raw reply
* [PATCH 3/4] esp: check the NETIF_F_HW_ESP_TX_CSUM bit before segmenting
From: Steffen Klassert @ 2018-03-29 7:25 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <20180329072549.2880-1-steffen.klassert@secunet.com>
From: Shannon Nelson <shannon.nelson@oracle.com>
If I understand correctly, we should not be asking for a
checksum offload on an ipsec packet if the netdev isn't
advertising NETIF_F_HW_ESP_TX_CSUM. In that case, we should
clear the NETIF_F_CSUM_MASK bits.
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv4/esp4_offload.c | 2 ++
net/ipv6/esp6_offload.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/net/ipv4/esp4_offload.c b/net/ipv4/esp4_offload.c
index da5635fc52c2..7cf755ef9efb 100644
--- a/net/ipv4/esp4_offload.c
+++ b/net/ipv4/esp4_offload.c
@@ -138,6 +138,8 @@ static struct sk_buff *esp4_gso_segment(struct sk_buff *skb,
if (!(features & NETIF_F_HW_ESP) || !x->xso.offload_handle ||
(x->xso.dev != skb->dev))
esp_features = features & ~(NETIF_F_SG | NETIF_F_CSUM_MASK);
+ else if (!(features & NETIF_F_HW_ESP_TX_CSUM))
+ esp_features = features & ~NETIF_F_CSUM_MASK;
xo->flags |= XFRM_GSO_SEGMENT;
diff --git a/net/ipv6/esp6_offload.c b/net/ipv6/esp6_offload.c
index 3fd1ec775dc2..27f59b61f70f 100644
--- a/net/ipv6/esp6_offload.c
+++ b/net/ipv6/esp6_offload.c
@@ -165,6 +165,8 @@ static struct sk_buff *esp6_gso_segment(struct sk_buff *skb,
if (!(features & NETIF_F_HW_ESP) || !x->xso.offload_handle ||
(x->xso.dev != skb->dev))
esp_features = features & ~(NETIF_F_SG | NETIF_F_CSUM_MASK);
+ else if (!(features & NETIF_F_HW_ESP_TX_CSUM))
+ esp_features = features & ~NETIF_F_CSUM_MASK;
xo->flags |= XFRM_GSO_SEGMENT;
--
2.14.1
^ permalink raw reply related
* pull request (net-next): ipsec-next 2018-03-29
From: Steffen Klassert @ 2018-03-29 7:25 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
1) Remove a redundant pointer initialization esp_input_set_header().
From Colin Ian King.
2) Mark the xfrm kmem_caches as __ro_after_init.
From Alexey Dobriyan.
3) Do the checksum for an ipsec offlad packet in software
if the device does not advertise NETIF_F_HW_ESP_TX_CSUM.
From Shannon Nelson.
4) Use booleans for true and false instead of integers
in xfrm_policy_cache_flush().
From Gustavo A. R. Silva
Please pull or let me know if there are problems.
Thanks!
The following changes since commit cf19e5e2054f5172c07a152f9e04eb3bae3d86dd:
Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue (2018-02-12 19:55:33 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git master
for you to fetch changes up to 415a13296a1a49639cabf9d2fe92267810caa47a:
xfrm_policy: use true and false for boolean values (2018-03-07 10:55:13 +0100)
----------------------------------------------------------------
Alexey Dobriyan (1):
xfrm: mark kmem_caches as __ro_after_init
Colin Ian King (1):
esp4: remove redundant initialization of pointer esph
Gustavo A. R. Silva (1):
xfrm_policy: use true and false for boolean values
Shannon Nelson (1):
esp: check the NETIF_F_HW_ESP_TX_CSUM bit before segmenting
net/ipv4/esp4.c | 2 +-
net/ipv4/esp4_offload.c | 2 ++
net/ipv6/esp6_offload.c | 2 ++
net/xfrm/xfrm_input.c | 3 ++-
net/xfrm/xfrm_policy.c | 4 ++--
5 files changed, 9 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH 2/4] xfrm: mark kmem_caches as __ro_after_init
From: Steffen Klassert @ 2018-03-29 7:25 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <20180329072549.2880-1-steffen.klassert@secunet.com>
From: Alexey Dobriyan <adobriyan@gmail.com>
Kmem caches aren't relocated once set up.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/xfrm_input.c | 3 ++-
net/xfrm/xfrm_policy.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index 1472c0857975..44fc54dc013c 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -9,6 +9,7 @@
*/
#include <linux/bottom_half.h>
+#include <linux/cache.h>
#include <linux/interrupt.h>
#include <linux/slab.h>
#include <linux/module.h>
@@ -31,7 +32,7 @@ struct xfrm_trans_cb {
#define XFRM_TRANS_SKB_CB(__skb) ((struct xfrm_trans_cb *)&((__skb)->cb[0]))
-static struct kmem_cache *secpath_cachep __read_mostly;
+static struct kmem_cache *secpath_cachep __ro_after_init;
static DEFINE_SPINLOCK(xfrm_input_afinfo_lock);
static struct xfrm_input_afinfo const __rcu *xfrm_input_afinfo[AF_INET6 + 1];
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 7a23078132cf..12bd415d349e 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -51,7 +51,7 @@ static DEFINE_SPINLOCK(xfrm_policy_afinfo_lock);
static struct xfrm_policy_afinfo const __rcu *xfrm_policy_afinfo[AF_INET6 + 1]
__read_mostly;
-static struct kmem_cache *xfrm_dst_cache __read_mostly;
+static struct kmem_cache *xfrm_dst_cache __ro_after_init;
static __read_mostly seqcount_t xfrm_policy_hash_generation;
static void xfrm_init_pmtu(struct xfrm_dst **bundle, int nr);
--
2.14.1
^ permalink raw reply related
* [PATCH 4/4] xfrm_policy: use true and false for boolean values
From: Steffen Klassert @ 2018-03-29 7:25 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <20180329072549.2880-1-steffen.klassert@secunet.com>
From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Assign true or false to boolean variables instead of an integer value.
This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/xfrm_policy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 12bd415d349e..2b7babb66175 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1740,7 +1740,7 @@ static void xfrm_pcpu_work_fn(struct work_struct *work)
void xfrm_policy_cache_flush(void)
{
struct xfrm_dst *old;
- bool found = 0;
+ bool found = false;
int cpu;
might_sleep();
--
2.14.1
^ permalink raw reply related
* [PATCH 1/4] esp4: remove redundant initialization of pointer esph
From: Steffen Klassert @ 2018-03-29 7:25 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <20180329072549.2880-1-steffen.klassert@secunet.com>
From: Colin Ian King <colin.king@canonical.com>
Pointer esph is being assigned a value that is never read, esph is
re-assigned and only read inside an if statement, hence the
initialization is redundant and can be removed.
Cleans up clang warning:
net/ipv4/esp4.c:657:21: warning: Value stored to 'esph' during
its initialization is never read
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv4/esp4.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 296d0b956bfe..97689012b357 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -654,7 +654,7 @@ static void esp_input_restore_header(struct sk_buff *skb)
static void esp_input_set_header(struct sk_buff *skb, __be32 *seqhi)
{
struct xfrm_state *x = xfrm_input_state(skb);
- struct ip_esp_hdr *esph = (struct ip_esp_hdr *)skb->data;
+ struct ip_esp_hdr *esph;
/* For ESN we move the header forward by 4 bytes to
* accomodate the high bits. We will move it back after
--
2.14.1
^ permalink raw reply related
* INFO: task hung in stop_sync_thread (2)
From: syzbot @ 2018-03-29 7:25 UTC (permalink / raw)
To: coreteam, davem, fw, horms, ja, kadlec, linux-kernel, lvs-devel,
netdev, netfilter-devel, pablo, syzkaller-bugs, wensong
Hello,
syzbot hit the following crash on net-next commit
5d22d47b9ed96eddb35821dc2cc4f629f45827f7 (Tue Mar 27 17:33:21 2018 +0000)
Merge branch 'sfc-filter-locking'
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=5fe074c01b2032ce9618
Unfortunately, I don't have any reproducer for this crash yet.
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=6119456711376896
Kernel config:
https://syzkaller.appspot.com/x/.config?id=4372867303600475372
compiler: gcc (GCC) 7.1.1 20170620
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+5fe074c01b2032ce9618@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
IPVS: sync thread started: state = BACKUP, mcast_ifn = syz_tun, syncid = 4,
id = 0
IPVS: stopping backup sync thread 25415 ...
INFO: task syz-executor7:25421 blocked for more than 120 seconds.
Not tainted 4.16.0-rc6+ #284
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor7 D23688 25421 4408 0x00000004
Call Trace:
context_switch kernel/sched/core.c:2862 [inline]
__schedule+0x8fb/0x1ec0 kernel/sched/core.c:3440
schedule+0xf5/0x430 kernel/sched/core.c:3499
schedule_timeout+0x1a3/0x230 kernel/time/timer.c:1777
do_wait_for_common kernel/sched/completion.c:86 [inline]
__wait_for_common kernel/sched/completion.c:107 [inline]
wait_for_common kernel/sched/completion.c:118 [inline]
wait_for_completion+0x415/0x770 kernel/sched/completion.c:139
kthread_stop+0x14a/0x7a0 kernel/kthread.c:530
stop_sync_thread+0x3d9/0x740 net/netfilter/ipvs/ip_vs_sync.c:1996
do_ip_vs_set_ctl+0x2b1/0x1cc0 net/netfilter/ipvs/ip_vs_ctl.c:2394
nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
nf_setsockopt+0x67/0xc0 net/netfilter/nf_sockopt.c:115
ip_setsockopt+0x97/0xa0 net/ipv4/ip_sockglue.c:1253
sctp_setsockopt+0x2ca/0x63e0 net/sctp/socket.c:4154
sock_common_setsockopt+0x95/0xd0 net/core/sock.c:3039
SYSC_setsockopt net/socket.c:1850 [inline]
SyS_setsockopt+0x189/0x360 net/socket.c:1829
do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x454889
RSP: 002b:00007fc927626c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00007fc9276276d4 RCX: 0000000000454889
RDX: 000000000000048c RSI: 0000000000000000 RDI: 0000000000000017
RBP: 000000000072bf58 R08: 0000000000000018 R09: 0000000000000000
R10: 0000000020000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 000000000000051c R14: 00000000006f9b40 R15: 0000000000000001
Showing all locks held in the system:
2 locks held by khungtaskd/868:
#0: (rcu_read_lock){....}, at: [<00000000a1a8f002>]
check_hung_uninterruptible_tasks kernel/hung_task.c:175 [inline]
#0: (rcu_read_lock){....}, at: [<00000000a1a8f002>] watchdog+0x1c5/0xd60
kernel/hung_task.c:249
#1: (tasklist_lock){.+.+}, at: [<0000000037c2f8f9>]
debug_show_all_locks+0xd3/0x3d0 kernel/locking/lockdep.c:4470
1 lock held by rsyslogd/4247:
#0: (&f->f_pos_lock){+.+.}, at: [<000000000d8d6983>]
__fdget_pos+0x12b/0x190 fs/file.c:765
2 locks held by getty/4338:
#0: (&tty->ldisc_sem){++++}, at: [<00000000bee98654>]
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000c1d180aa>]
n_tty_read+0x2ef/0x1a40 drivers/tty/n_tty.c:2131
2 locks held by getty/4339:
#0: (&tty->ldisc_sem){++++}, at: [<00000000bee98654>]
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000c1d180aa>]
n_tty_read+0x2ef/0x1a40 drivers/tty/n_tty.c:2131
2 locks held by getty/4340:
#0: (&tty->ldisc_sem){++++}, at: [<00000000bee98654>]
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000c1d180aa>]
n_tty_read+0x2ef/0x1a40 drivers/tty/n_tty.c:2131
2 locks held by getty/4341:
#0: (&tty->ldisc_sem){++++}, at: [<00000000bee98654>]
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000c1d180aa>]
n_tty_read+0x2ef/0x1a40 drivers/tty/n_tty.c:2131
2 locks held by getty/4342:
#0: (&tty->ldisc_sem){++++}, at: [<00000000bee98654>]
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000c1d180aa>]
n_tty_read+0x2ef/0x1a40 drivers/tty/n_tty.c:2131
2 locks held by getty/4343:
#0: (&tty->ldisc_sem){++++}, at: [<00000000bee98654>]
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000c1d180aa>]
n_tty_read+0x2ef/0x1a40 drivers/tty/n_tty.c:2131
2 locks held by getty/4344:
#0: (&tty->ldisc_sem){++++}, at: [<00000000bee98654>]
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: (&ldata->atomic_read_lock){+.+.}, at: [<00000000c1d180aa>]
n_tty_read+0x2ef/0x1a40 drivers/tty/n_tty.c:2131
3 locks held by kworker/0:5/6494:
#0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
[<00000000a062b18e>] work_static include/linux/workqueue.h:198 [inline]
#0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
[<00000000a062b18e>] set_work_data kernel/workqueue.c:619 [inline]
#0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
[<00000000a062b18e>] set_work_pool_and_clear_pending kernel/workqueue.c:646
[inline]
#0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
[<00000000a062b18e>] process_one_work+0xb12/0x1bb0 kernel/workqueue.c:2084
#1: ((addr_chk_work).work){+.+.}, at: [<00000000278427d5>]
process_one_work+0xb89/0x1bb0 kernel/workqueue.c:2088
#2: (rtnl_mutex){+.+.}, at: [<00000000066e35ac>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by syz-executor7/25421:
#0: (ipvs->sync_mutex){+.+.}, at: [<00000000d414a689>]
do_ip_vs_set_ctl+0x277/0x1cc0 net/netfilter/ipvs/ip_vs_ctl.c:2393
2 locks held by syz-executor7/25427:
#0: (rtnl_mutex){+.+.}, at: [<00000000066e35ac>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
#1: (ipvs->sync_mutex){+.+.}, at: [<00000000e6d48489>]
do_ip_vs_set_ctl+0x10f8/0x1cc0 net/netfilter/ipvs/ip_vs_ctl.c:2388
1 lock held by syz-executor7/25435:
#0: (rtnl_mutex){+.+.}, at: [<00000000066e35ac>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
1 lock held by ipvs-b:2:0/25415:
#0: (rtnl_mutex){+.+.}, at: [<00000000066e35ac>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
=============================================
NMI backtrace for cpu 1
CPU: 1 PID: 868 Comm: khungtaskd Not tainted 4.16.0-rc6+ #284
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x24d lib/dump_stack.c:53
nmi_cpu_backtrace+0x1d2/0x210 lib/nmi_backtrace.c:103
nmi_trigger_cpumask_backtrace+0x123/0x180 lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_all_cpu_backtrace include/linux/nmi.h:138 [inline]
check_hung_task kernel/hung_task.c:132 [inline]
check_hung_uninterruptible_tasks kernel/hung_task.c:190 [inline]
watchdog+0x90c/0xd60 kernel/hung_task.c:249
kthread+0x33c/0x400 kernel/kthread.c:238
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:406
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0 skipped: idling at native_safe_halt+0x6/0x10
arch/x86/include/asm/irqflags.h:54
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ 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