* Re: [net PATCH v2] net: sched, fix OOO packets with pfifo_fast
From: Paolo Abeni @ 2018-05-08 16:17 UTC (permalink / raw)
To: John Fastabend, Cong Wang, Jamal Hadi Salim
Cc: Eric Dumazet, Jiri Pirko, David Miller,
Linux Kernel Network Developers
In-Reply-To: <36a89ed1-d6ff-ddad-c736-4e68909d61c4@gmail.com>
Hi all,
I'm still crashing my head on this item...
On Wed, 2018-04-18 at 09:44 -0700, John Fastabend wrote:
> There is a set of conditions
> that if met we can run without the lock. Possibly ONETXQUEUE and
> aligned cpu_map is sufficient. We could detect this case and drop
> the locking. For existing systems and high Gbps NICs I think (feel
> free to correct me) assuming a core per cpu is OK. At some point
> though we probably need to revisit this assumption.
I think we can improve measurably moving the __QDISC_STATE_RUNNING bit
fiddling around the __qdisc_run() call in the 'lockless' path, instead
of keeping it inside __qdisc_restart().
Currently, in the single sender, pkt rate below link-limit scenario we
hit the atomic bit overhead twice per xmitted packet: one for each
dequeue, plus another one for the next, failing, dequeue attempt. With
the wider scope we will hit it always only once.
After that change __QDISC_STATE_RUNNING usage will look a bit like
qdisc_lock(), for the dequeue part at least. So I'm wondering if we
could replace __QDISC_STATE_RUNNING with spin_trylock(qdisc_lock())
_and_ keep such lock held for the whole qdisc_run() !?!
The comment above qdisc_restart() states clearly we can't, but I don't
see why !?! Acquiring qdisc_lock() and xmit lock always in the given
sequence looks safe to me. Can someone please explain? Is there some
possible deathlock condition I'm missing ?!?
It looks like the comment itself cames directly from the pre-bitkeeper
era (modulo locks name change).
Performance wise, acquiring the qdisc_lock only once per xmitted packet
should improve considerably 'locked' qdisc performance, both in the
contented and in the uncontended scenario (and some quick experiments
seems to confirm that).
Thanks,
Paolo
^ permalink raw reply
* [PATCH net-next] tun: Do SIOCGSKNS out of rtnl_lock()
From: Kirill Tkhai @ 2018-05-08 16:21 UTC (permalink / raw)
To: davem, jasowang, edumazet, mst, brouer, peterpenkov96, sd, netdev,
ktkhai
Since net ns of tun device is assigned on the device creation,
and it never changes, we do not need to use any lock to get it
from alive tun.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
---
drivers/net/tun.c | 18 +++++++-----------
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index d3c04ab9752a..44d4f3d25350 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2850,10 +2850,10 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
unsigned long arg, int ifreq_len)
{
struct tun_file *tfile = file->private_data;
+ struct net *net = sock_net(&tfile->sk);
struct tun_struct *tun;
void __user* argp = (void __user*)arg;
struct ifreq ifr;
- struct net *net;
kuid_t owner;
kgid_t group;
int sndbuf;
@@ -2877,14 +2877,18 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
*/
return put_user(IFF_TUN | IFF_TAP | TUN_FEATURES,
(unsigned int __user*)argp);
- } else if (cmd == TUNSETQUEUE)
+ } else if (cmd == TUNSETQUEUE) {
return tun_set_queue(file, &ifr);
+ } else if (cmd == SIOCGSKNS) {
+ if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
+ return -EPERM;
+ return open_related_ns(&net->ns, get_net_ns);
+ }
ret = 0;
rtnl_lock();
tun = tun_get(tfile);
- net = sock_net(&tfile->sk);
if (cmd == TUNSETIFF) {
ret = -EEXIST;
if (tun)
@@ -2914,14 +2918,6 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
tfile->ifindex = ifindex;
goto unlock;
}
- if (cmd == SIOCGSKNS) {
- ret = -EPERM;
- if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
- goto unlock;
-
- ret = open_related_ns(&net->ns, get_net_ns);
- goto unlock;
- }
ret = -EBADFD;
if (!tun)
^ permalink raw reply related
* Re: general protection fault in encode_rpcb_string
From: Chuck Lever @ 2018-05-08 16:34 UTC (permalink / raw)
To: Bruce Fields
Cc: Trond Myklebust,
syzbot+4b98281f2401ab849f4b@syzkaller.appspotmail.com,
syzkaller-bugs@googlegroups.com, Anna Schumaker,
davem@davemloft.net, linux-kernel@vger.kernel.org,
Linux NFS Mailing List, jlayton@kernel.org,
netdev@vger.kernel.org
In-Reply-To: <20180508161529.GD6151@fieldses.org>
> On May 8, 2018, at 12:15 PM, bfields@fieldses.org wrote:
>
> On Tue, Apr 17, 2018 at 09:54:36PM +0000, Trond Myklebust wrote:
>> Yes, and we can probably convert it, and the other GFP_ATOMIC
>> allocations in the rpcbind client to use GFP_NOFS in order to improve
>> reliability.
>
> Chuck, I think the GFP_ATOMIC is unnecessary here as well?
>
> --b.
>
> diff --git a/net/sunrpc/xprtrdma/rpc_rdma.c b/net/sunrpc/xprtrdma/rpc_rdma.c
> index e8adad33d0bb..de90c6c90cde 100644
> --- a/net/sunrpc/xprtrdma/rpc_rdma.c
> +++ b/net/sunrpc/xprtrdma/rpc_rdma.c
> @@ -228,7 +228,7 @@ rpcrdma_convert_iovs(struct rpcrdma_xprt *r_xprt, struct xdr_buf *xdrbuf,
> /* XXX: Certain upper layer operations do
> * not provide receive buffer pages.
> */
> - *ppages = alloc_page(GFP_ATOMIC);
> + *ppages = alloc_page(GFP_NOFS);
> if (!*ppages)
> return -EAGAIN;
> }
This code can't sleep, as I understand it. Caller is holding
the transport write lock. This logic was copied from
xdr_partial_copy_from_skb, which uses GFP_ATOMIC.
Recall that this is here because of GETACL. As I've stated in
the past, the correct solution is to ensure that these pages
are provided in every case by the upper layer, making this
alloc_page call site unnecessary.
--
Chuck Lever
chucklever@gmail.com
^ permalink raw reply
* Performance regression between 4.13 and 4.14
From: Ben Greear @ 2018-05-08 16:44 UTC (permalink / raw)
To: netdev
Hello,
I am trying to track down a performance regression that appears to be between 4.13
and 4.14.
I first saw the problem with a hacked version of pktgen on some ixgbe NICs. 4.13 can do
right at 10G bi-directional on two ports, and 4.14 and later can do only about 6Gbps.
I also tried with user-space UDP traffic on a stock kernel, and I can get about 3.2Gbps combined tx+rx
on 4.14 and about 4.4Gbps on 4.13.
Attempting to bisect seems to be triggering a weirdness in git, and also lots of commits
crash or do not bring up networking, which makes the bisect difficult.
Looking at perf top, it would appear that some lock is probably to blame.
Any ideas what might have been introduced during this interval that
would cause this?
Anyone else seen similar?
I'm going to attempt some more manual steps to try to find the commit that
introduces this...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] net: phy: DP83811: Add support for the phy
From: Andrew Lunn @ 2018-05-08 16:49 UTC (permalink / raw)
To: Dan Murphy; +Cc: f.fainelli, netdev, linux-kernel
In-Reply-To: <1b6877db-61cf-101a-054e-9c1fbe95a813@ti.com>
On Tue, May 08, 2018 at 10:56:55AM -0500, Dan Murphy wrote:
> All
>
> On 05/08/2018 09:11 AM, Dan Murphy wrote:
> > Add support for the DP83811 phy by extending
> > the DP83822 driver to recognize the PHY IDs.
> >
> > The DP83811 supports both rgmii and sgmii interfaces.
> > There are 2 part numbers for this the DP83811R does not
> > reliably support the SGMII interface but the DP83811S will.
> >
> > There is not a way to differentiate these parts from the
> > hardware or register set. So this is controlled via the DT
> > to indicate which phy mode is required. Or the part can be
> > strapped to a certain interface.
> >
> > Data sheet can be found here:
> > http://www.ti.com/product/DP83TC811S-Q1/description
> > http://www.ti.com/product/DP83TC811R-Q1/description
> >
>
> I am withdrawing this patch for comment.
> Some of the future features have varying register definitions between the DP83811
> and DP83822
Hi Dan
It might be worth talking to the ASIC engineers and the
test/qualification engineers. There are sometime undocumented
registers for testing. You might be able to identify the exact device
from these registers.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] dt-bindings: dsa: Remove unnecessary #address/#size-cells
From: Rob Herring @ 2018-05-08 16:53 UTC (permalink / raw)
To: Fabio Estevam
Cc: davem, f.fainelli, andrew, netdev, devicetree, Fabio Estevam
In-Reply-To: <1525695471-19984-1-git-send-email-festevam@gmail.com>
On Mon, May 07, 2018 at 09:17:51AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> If the example binding is used on a real dts file, the following DTC
> warning is seen with W=1:
>
> arch/arm/boot/dts/imx6q-b450v3.dtb: Warning (avoid_unnecessary_addr_size): /mdio-gpio/switch@0: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
>
> Remove unnecessary #address-cells/#size-cells to improve the binding
> document examples.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> Documentation/devicetree/bindings/net/dsa/dsa.txt | 6 ------
> 1 file changed, 6 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [net-next 2/6] fm10k: reduce duplicate fm10k_stat macro code
From: Joe Perches @ 2018-05-08 16:59 UTC (permalink / raw)
To: Jeff Kirsher, davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene
In-Reply-To: <20180507144521.6979-3-jeffrey.t.kirsher@intel.com>
On Mon, 2018-05-07 at 07:45 -0700, Jeff Kirsher wrote:
> Share some of the code for setting up fm10k_stat macros by implementing
> an FM10K_STAT_FIELDS macro which we can use when setting up the type
> specific macros.
[]
> diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
[]
> @@ -11,12 +11,16 @@ struct fm10k_stats {
> int stat_offset;
> };o
>
> -#define FM10K_NETDEV_STAT(_net_stat) { \
> - .stat_string = #_net_stat, \
> - .sizeof_stat = FIELD_SIZEOF(struct net_device_stats, _net_stat), \
> - .stat_offset = offsetof(struct net_device_stats, _net_stat) \
> +#define FM10K_STAT_FIELDS(_type, _name, _stat) { \
> + .stat_string = _name, \
> + .sizeof_stat = FIELD_SIZEOF(_type, _stat), \
> + .stat_offset = offsetof(_type, _stat) \
> }
>
> +/* netdevice statistics */
> +#define FM10K_NETDEV_STAT(_net_stat) \
> + FM10K_STAT_FIELDS(struct net_device_stats, #_net_stat, _net_stat)
trivia:
It's somewhat unusual to use # in a macro argument.
Perhaps this would be slightly easier to understand using __stringify
#define FM10K_NETDEV_STAT(_net_stat) \
FM10K_STAT_FIELDS(struct net_device_stats, __stringify(_net_stat), _net_stat)
^ permalink raw reply
* Re: [PATCH] selinux: add AF_UNSPEC and INADDR_ANY checks to selinux_socket_bind()
From: Paul Moore @ 2018-05-08 17:05 UTC (permalink / raw)
To: Alexey Kodanev, Richard Haines
Cc: selinux, Stephen Smalley, Eric Paris, linux-security-module,
netdev
In-Reply-To: <1525788303-23244-1-git-send-email-alexey.kodanev@oracle.com>
On Tue, May 8, 2018 at 10:05 AM, Alexey Kodanev
<alexey.kodanev@oracle.com> wrote:
> Commit d452930fd3b9 ("selinux: Add SCTP support") breaks compatibility
> with the old programs that can pass sockaddr_in with AF_UNSPEC and
> INADDR_ANY to bind(). As a result, bind() returns EAFNOSUPPORT error.
> It was found with LTP/asapi_01 test.
>
> Similar to commit 29c486df6a20 ("net: ipv4: relax AF_INET check in
> bind()"), which relaxed AF_INET check for compatibility, add AF_UNSPEC
> case to AF_INET and make sure that the address is INADDR_ANY.
>
> Also, in the end of selinux_socket_bind(), instead of adding AF_UNSPEC
> to 'address->sa_family == AF_INET', verify AF_INET6 first.
>
> Fixes: d452930fd3b9 ("selinux: Add SCTP support")
> Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
> ---
> security/selinux/hooks.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
Thanks for finding and reporting this regression.
I think I would prefer to avoid having to duplicate the
AF_UNSPEC/INADDR_ANY checking logic in the SELinux hook, even though
it is a small bit of code and unlikely to change. I'm wondering if it
would be better to check both the socket and sockaddr address family
in the main if conditional inside selinux_socket_bind(), what do you
think? Another option would be to go back to just checking the
soackaddr address family; we moved away from that for a reason which
escapes at the moment (code cleanliness?), but perhaps that was a
mistake.
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 4cafe6a19167..a3789b167667 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -4577,6 +4577,7 @@ static int selinux_socket_bind(struct socket *sock, struc>
{
struct sock *sk = sock->sk;
u16 family;
+ u16 family_sa;
int err;
err = sock_has_perm(sk, SOCKET__BIND);
@@ -4585,7 +4586,9 @@ static int selinux_socket_bind(struct socket *sock, struc>
/* If PF_INET or PF_INET6, check name_bind permission for the port. */
family = sk->sk_family;
- if (family == PF_INET || family == PF_INET6) {
+ family_sa = address->sa_family;
+ if ((family == PF_INET || family == PF_INET6) &&
+ (family_sa == PF_INET || family_sa == PF_INET6)) {
char *addrp;
struct sk_security_struct *sksec = sk->sk_security;
struct common_audit_data ad;
@@ -4601,7 +4604,7 @@ static int selinux_socket_bind(struct socket *sock, struc>
* need to check address->sa_family as it is possible to have
* sk->sk_family = PF_INET6 with addr->sa_family = AF_INET.
*/
- switch (address->sa_family) {
+ switch (family_sa) {
case AF_INET:
if (addrlen < sizeof(struct sockaddr_in))
return -EINVAL;
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 4cafe6a..649a3be 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -4602,10 +4602,16 @@ static int selinux_socket_bind(struct socket *sock, struct sockaddr *address, in
> * sk->sk_family = PF_INET6 with addr->sa_family = AF_INET.
> */
> switch (address->sa_family) {
> + case AF_UNSPEC:
> case AF_INET:
> if (addrlen < sizeof(struct sockaddr_in))
> return -EINVAL;
> addr4 = (struct sockaddr_in *)address;
> +
> + if (address->sa_family == AF_UNSPEC &&
> + addr4->sin_addr.s_addr != htonl(INADDR_ANY))
> + return -EAFNOSUPPORT;
> +
> snum = ntohs(addr4->sin_port);
> addrp = (char *)&addr4->sin_addr.s_addr;
> break;
> @@ -4681,10 +4687,10 @@ static int selinux_socket_bind(struct socket *sock, struct sockaddr *address, in
> ad.u.net->sport = htons(snum);
> ad.u.net->family = family;
>
> - if (address->sa_family == AF_INET)
> - ad.u.net->v4info.saddr = addr4->sin_addr.s_addr;
> - else
> + if (address->sa_family == AF_INET6)
> ad.u.net->v6info.saddr = addr6->sin6_addr;
> + else
> + ad.u.net->v4info.saddr = addr4->sin_addr.s_addr;
>
> err = avc_has_perm(&selinux_state,
> sksec->sid, sid,
> --
> 1.8.3.1
>
--
paul moore
www.paul-moore.com
^ permalink raw reply related
* Re: [net-next PATCH 0/3] Symmetric queue selection using XPS for Rx queues
From: Eric Dumazet @ 2018-05-08 17:07 UTC (permalink / raw)
To: Alexander Duyck, Tom Herbert
Cc: Eric Dumazet, Amritha Nambiar, netdev, David Miller,
Alexander Duyck, Samudrala, Sridhar, Hannes Frederic Sowa
In-Reply-To: <CAKgT0UdtjZeY8-vw-BGKW-QRqqpkJSS83VUM9Dgueh312h1omg@mail.gmail.com>
On 05/08/2018 09:02 AM, Alexander Duyck wrote:
> On Tue, May 8, 2018 at 8:15 AM, Tom Herbert <tom@herbertland.com> wrote:
>> On Thu, Apr 19, 2018 at 7:41 PM, Eric Dumazet <edumazet@google.com> wrote:
>>> On Thu, Apr 19, 2018 at 6:07 PM Amritha Nambiar <amritha.nambiar@intel.com>
>>> wrote:
>>>
>>>> This patch series implements support for Tx queue selection based on
>>>> Rx queue map. This is done by configuring Rx queue map per Tx-queue
>>>> using sysfs attribute. If the user configuration for Rx queues does
>>>> not apply, then the Tx queue selection falls back to XPS using CPUs and
>>>> finally to hashing.
>>>
>>>> XPS is refactored to support Tx queue selection based on either the
>>>> CPU map or the Rx-queue map. The config option CONFIG_XPS needs to be
>>>> enabled. By default no receive queues are configured for the Tx queue.
>>>
>>>> - /sys/class/net/eth0/queues/tx-*/xps_rxqs
>>>
>>>> This is to enable sending packets on the same Tx-Rx queue pair as this
>>>> is useful for busy polling multi-threaded workloads where it is not
>>>> possible to pin the threads to a CPU. This is a rework of Sridhar's
>>>> patch for symmetric queueing via socket option:
>>>> https://www.spinics.net/lists/netdev/msg453106.html
>>>
>> I suspect this is an artifact of flow director which I believe
>> required queue pairs to be able to work (i.e. receive queue chose
>> hardware is determined send queue). But that was only required because
>> of hardware design, I don't see the rationale for introducing queue
>> pairs in the software stack. There's no need to correlate the transmit
>> path with receive path, no need to enforce a 1-1 mapping between RX
>> and TX queues, and the OOO mitigations should be sufficient when TX
>> queue changes for a flow.
>>
>> Tom
>
> If I am not mistaken I think there are benefits to doing this sort of
> thing with polling as it keeps the Tx work locked into the same queue
> pair that a given application is polling on. So as a result you can
> keep the interrupts contained to the queue pair that is being busy
> polled on and if the application cleans up the packets during the busy
> poll it ends up being a net savings in terms of both latency and power
> since the Tx clean-up happens sooner, and it happens on the queue that
> is already busy polling instead of possibly triggering an interrupt on
> another CPU.
>
> So for example in the case of routing and bridging workloads we
> already had code that would take the Rx queue and associate it to a Tx
> queue. One of the ideas behind doing this is to try and keep the CPU
> overhead low by having a 1:1 mapping. In the case of this code we
> allow for a little more flexibility in that you could have
> many-to-many mappings but the general idea and common use case is the
> same which is a 1:1 mapping.
I thought we had everything in place to be able to have this already.
Setting IRQ affinities and XPS is certainly something doable.
This is why I wanted a proper documentation of yet another way to reach the
same behavior.
^ permalink raw reply
* Re: Performance regression between 4.13 and 4.14
From: Eric Dumazet @ 2018-05-08 17:10 UTC (permalink / raw)
To: Ben Greear, netdev
In-Reply-To: <9115910b-dd8b-e7f3-be53-f739b8382032@candelatech.com>
On 05/08/2018 09:44 AM, Ben Greear wrote:
> Hello,
>
> I am trying to track down a performance regression that appears to be between 4.13
> and 4.14.
>
> I first saw the problem with a hacked version of pktgen on some ixgbe NICs. 4.13 can do
> right at 10G bi-directional on two ports, and 4.14 and later can do only about 6Gbps.
>
> I also tried with user-space UDP traffic on a stock kernel, and I can get about 3.2Gbps combined tx+rx
> on 4.14 and about 4.4Gbps on 4.13.
>
> Attempting to bisect seems to be triggering a weirdness in git, and also lots of commits
> crash or do not bring up networking, which makes the bisect difficult.
>
> Looking at perf top, it would appear that some lock is probably to blame.
perf record -a -g -e cycles:pp sleep 5
perf report
Then you'll be able to tell us which lock (or call graph) is killing your perf.
^ permalink raw reply
* Re: [PATCH] net: phy: DP83811: Add support for the phy
From: Dan Murphy @ 2018-05-08 17:13 UTC (permalink / raw)
To: Andrew Lunn; +Cc: f.fainelli, netdev, linux-kernel
In-Reply-To: <20180508164944.GE2888@lunn.ch>
Andrew
On 05/08/2018 11:49 AM, Andrew Lunn wrote:
> On Tue, May 08, 2018 at 10:56:55AM -0500, Dan Murphy wrote:
>> All
>>
>> On 05/08/2018 09:11 AM, Dan Murphy wrote:
>>> Add support for the DP83811 phy by extending
>>> the DP83822 driver to recognize the PHY IDs.
>>>
>>> The DP83811 supports both rgmii and sgmii interfaces.
>>> There are 2 part numbers for this the DP83811R does not
>>> reliably support the SGMII interface but the DP83811S will.
>>>
>>> There is not a way to differentiate these parts from the
>>> hardware or register set. So this is controlled via the DT
>>> to indicate which phy mode is required. Or the part can be
>>> strapped to a certain interface.
>>>
>>> Data sheet can be found here:
>>> http://www.ti.com/product/DP83TC811S-Q1/description
>>> http://www.ti.com/product/DP83TC811R-Q1/description
>>>
>>
>> I am withdrawing this patch for comment.
>> Some of the future features have varying register definitions between the DP83811
>> and DP83822
>
> Hi Dan
>
> It might be worth talking to the ASIC engineers and the
> test/qualification engineers. There are sometime undocumented
> registers for testing. You might be able to identify the exact device
> from these registers.
>
Thanks. I talked to them prior to submitting this patch about determining which part is on the board.
I will ping them again and poke a little harder.
It turns out that we will probably need a new driver for this part anyway as there are
additional features that need to be supported that the 811 just does not support.
They want to support Master/Slave configurations.
The 822 supports fiber and eee while the 811 does not.
The 811 supports the IEEE802.3bw specific fields in MMD1 and MMD3, which are not in the 822.
The 811 does not support auto-negotiation on the MDI so all the auto-neg registers are invalid for the 811 but are valid for the 822.
Our Customer engineers felt that combining these two devices into a single driver may confuse the customer.
Dan
> Andrew
>
--
------------------
Dan Murphy
^ permalink raw reply
* Re: [PATCH] net: phy: DP83811: Add support for the phy
From: Florian Fainelli @ 2018-05-08 17:14 UTC (permalink / raw)
To: Dan Murphy, Andrew Lunn; +Cc: netdev, linux-kernel
In-Reply-To: <f4cfe325-f462-e965-3bd8-629acf460fbf@ti.com>
On 05/08/2018 10:13 AM, Dan Murphy wrote:
> Andrew
>
> On 05/08/2018 11:49 AM, Andrew Lunn wrote:
>> On Tue, May 08, 2018 at 10:56:55AM -0500, Dan Murphy wrote:
>>> All
>>>
>>> On 05/08/2018 09:11 AM, Dan Murphy wrote:
>>>> Add support for the DP83811 phy by extending
>>>> the DP83822 driver to recognize the PHY IDs.
>>>>
>>>> The DP83811 supports both rgmii and sgmii interfaces.
>>>> There are 2 part numbers for this the DP83811R does not
>>>> reliably support the SGMII interface but the DP83811S will.
>>>>
>>>> There is not a way to differentiate these parts from the
>>>> hardware or register set. So this is controlled via the DT
>>>> to indicate which phy mode is required. Or the part can be
>>>> strapped to a certain interface.
>>>>
>>>> Data sheet can be found here:
>>>> http://www.ti.com/product/DP83TC811S-Q1/description
>>>> http://www.ti.com/product/DP83TC811R-Q1/description
>>>>
>>>
>>> I am withdrawing this patch for comment.
>>> Some of the future features have varying register definitions between the DP83811
>>> and DP83822
>>
>> Hi Dan
>>
>> It might be worth talking to the ASIC engineers and the
>> test/qualification engineers. There are sometime undocumented
>> registers for testing. You might be able to identify the exact device
>> from these registers.
>>
>
> Thanks. I talked to them prior to submitting this patch about determining which part is on the board.
> I will ping them again and poke a little harder.
>
> It turns out that we will probably need a new driver for this part anyway as there are
> additional features that need to be supported that the 811 just does not support.
>
> They want to support Master/Slave configurations.
> The 822 supports fiber and eee while the 811 does not.
> The 811 supports the IEEE802.3bw specific fields in MMD1 and MMD3, which are not in the 822.
> The 811 does not support auto-negotiation on the MDI so all the auto-neg registers are invalid for the 811 but are valid for the 822.
>
> Our Customer engineers felt that combining these two devices into a single driver may confuse the customer.
Why? Having a single Kconfig option to enable and "automatically"
gaining support for new hardware is nice.
--
Florian
^ permalink raw reply
* Re: [net-next PATCH 0/3] Symmetric queue selection using XPS for Rx queues
From: Alexander Duyck @ 2018-05-08 17:19 UTC (permalink / raw)
To: Eric Dumazet
Cc: Tom Herbert, Eric Dumazet, Amritha Nambiar, netdev, David Miller,
Alexander Duyck, Samudrala, Sridhar, Hannes Frederic Sowa
In-Reply-To: <439f729f-8a1d-1d2b-b59a-3f13786aab77@gmail.com>
On Tue, May 8, 2018 at 10:07 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
> On 05/08/2018 09:02 AM, Alexander Duyck wrote:
>> On Tue, May 8, 2018 at 8:15 AM, Tom Herbert <tom@herbertland.com> wrote:
>>> On Thu, Apr 19, 2018 at 7:41 PM, Eric Dumazet <edumazet@google.com> wrote:
>>>> On Thu, Apr 19, 2018 at 6:07 PM Amritha Nambiar <amritha.nambiar@intel.com>
>>>> wrote:
>>>>
>>>>> This patch series implements support for Tx queue selection based on
>>>>> Rx queue map. This is done by configuring Rx queue map per Tx-queue
>>>>> using sysfs attribute. If the user configuration for Rx queues does
>>>>> not apply, then the Tx queue selection falls back to XPS using CPUs and
>>>>> finally to hashing.
>>>>
>>>>> XPS is refactored to support Tx queue selection based on either the
>>>>> CPU map or the Rx-queue map. The config option CONFIG_XPS needs to be
>>>>> enabled. By default no receive queues are configured for the Tx queue.
>>>>
>>>>> - /sys/class/net/eth0/queues/tx-*/xps_rxqs
>>>>
>>>>> This is to enable sending packets on the same Tx-Rx queue pair as this
>>>>> is useful for busy polling multi-threaded workloads where it is not
>>>>> possible to pin the threads to a CPU. This is a rework of Sridhar's
>>>>> patch for symmetric queueing via socket option:
>>>>> https://www.spinics.net/lists/netdev/msg453106.html
>>>>
>>> I suspect this is an artifact of flow director which I believe
>>> required queue pairs to be able to work (i.e. receive queue chose
>>> hardware is determined send queue). But that was only required because
>>> of hardware design, I don't see the rationale for introducing queue
>>> pairs in the software stack. There's no need to correlate the transmit
>>> path with receive path, no need to enforce a 1-1 mapping between RX
>>> and TX queues, and the OOO mitigations should be sufficient when TX
>>> queue changes for a flow.
>>>
>>> Tom
>>
>> If I am not mistaken I think there are benefits to doing this sort of
>> thing with polling as it keeps the Tx work locked into the same queue
>> pair that a given application is polling on. So as a result you can
>> keep the interrupts contained to the queue pair that is being busy
>> polled on and if the application cleans up the packets during the busy
>> poll it ends up being a net savings in terms of both latency and power
>> since the Tx clean-up happens sooner, and it happens on the queue that
>> is already busy polling instead of possibly triggering an interrupt on
>> another CPU.
>>
>> So for example in the case of routing and bridging workloads we
>> already had code that would take the Rx queue and associate it to a Tx
>> queue. One of the ideas behind doing this is to try and keep the CPU
>> overhead low by having a 1:1 mapping. In the case of this code we
>> allow for a little more flexibility in that you could have
>> many-to-many mappings but the general idea and common use case is the
>> same which is a 1:1 mapping.
>
>
> I thought we had everything in place to be able to have this already.
>
> Setting IRQ affinities and XPS is certainly something doable.
>
> This is why I wanted a proper documentation of yet another way to reach the
> same behavior.
IRQ affinities and XPS work for pure NAPI setups, but the problem is
you have to also do application affinity in the case of busy polling
which can provide some additional challenges since then you have to
add code in your application to associate a given queue/CPU to a given
application thread. I believe this is a way of simplifying this.
I agree on the documentation aspect. The usage of this should be well
documented as well as the why of using it.
- Alex
^ permalink raw reply
* Re: [PATCH] net: phy: DP83811: Add support for the phy
From: Dan Murphy @ 2018-05-08 17:21 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn; +Cc: netdev, linux-kernel
In-Reply-To: <cc5acc63-bcb5-2bda-9c9d-fd18e0a7740a@gmail.com>
Florian
On 05/08/2018 12:14 PM, Florian Fainelli wrote:
> On 05/08/2018 10:13 AM, Dan Murphy wrote:
>> Andrew
>>
>> On 05/08/2018 11:49 AM, Andrew Lunn wrote:
>>> On Tue, May 08, 2018 at 10:56:55AM -0500, Dan Murphy wrote:
>>>> All
>>>>
>>>> On 05/08/2018 09:11 AM, Dan Murphy wrote:
>>>>> Add support for the DP83811 phy by extending
>>>>> the DP83822 driver to recognize the PHY IDs.
>>>>>
>>>>> The DP83811 supports both rgmii and sgmii interfaces.
>>>>> There are 2 part numbers for this the DP83811R does not
>>>>> reliably support the SGMII interface but the DP83811S will.
>>>>>
>>>>> There is not a way to differentiate these parts from the
>>>>> hardware or register set. So this is controlled via the DT
>>>>> to indicate which phy mode is required. Or the part can be
>>>>> strapped to a certain interface.
>>>>>
>>>>> Data sheet can be found here:
>>>>> http://www.ti.com/product/DP83TC811S-Q1/description
>>>>> http://www.ti.com/product/DP83TC811R-Q1/description
>>>>>
>>>>
>>>> I am withdrawing this patch for comment.
>>>> Some of the future features have varying register definitions between the DP83811
>>>> and DP83822
>>>
>>> Hi Dan
>>>
>>> It might be worth talking to the ASIC engineers and the
>>> test/qualification engineers. There are sometime undocumented
>>> registers for testing. You might be able to identify the exact device
>>> from these registers.
>>>
>>
>> Thanks. I talked to them prior to submitting this patch about determining which part is on the board.
>> I will ping them again and poke a little harder.
>>
>> It turns out that we will probably need a new driver for this part anyway as there are
>> additional features that need to be supported that the 811 just does not support.
>>
>> They want to support Master/Slave configurations.
>> The 822 supports fiber and eee while the 811 does not.
>> The 811 supports the IEEE802.3bw specific fields in MMD1 and MMD3, which are not in the 822.
>> The 811 does not support auto-negotiation on the MDI so all the auto-neg registers are invalid for the 811 but are valid for the 822.
>>
>> Our Customer engineers felt that combining these two devices into a single driver may confuse the customer.
>
> Why? Having a single Kconfig option to enable and "automatically"
> gaining support for new hardware is nice.
>
I do agree that it is nice to have. But with additional features or lack of features the driver source will get pretty messy
differentiating between devices.
What I added was just the basic if 811 & SGMII check.
Dan
--
------------------
Dan Murphy
^ permalink raw reply
* [PATCH] hv_netvsc: Fix net device attach on older Windows hosts
From: Mohammed Gamal @ 2018-05-08 17:40 UTC (permalink / raw)
To: netdev, sthemmin
Cc: kys, haiyangz, devel, vkuznets, linux-kernel, Mohammed Gamal
On older windows hosts the net_device instance is returned to
the caller of rndis_filter_device_add() without having the presence
bit set first. This would cause any subsequent calls to network device
operations (e.g. MTU change, channel change) to fail after the device
is detached once, returning -ENODEV.
Make sure we explicitly call netif_device_attach() before returning
the net_device instance to make sure the presence bit is set
Fixes: 7b2ee50c0cd5 ("hv_netvsc: common detach logic")
Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
---
drivers/net/hyperv/rndis_filter.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/hyperv/rndis_filter.c b/drivers/net/hyperv/rndis_filter.c
index 6b127be..09a3c1d 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -1287,8 +1287,10 @@ struct netvsc_device *rndis_filter_device_add(struct hv_device *dev,
rndis_device->hw_mac_adr,
rndis_device->link_state ? "down" : "up");
- if (net_device->nvsp_version < NVSP_PROTOCOL_VERSION_5)
+ if (net_device->nvsp_version < NVSP_PROTOCOL_VERSION_5) {
+ netif_device_attach(net);
return net_device;
+ }
rndis_filter_query_link_speed(rndis_device, net_device);
--
1.8.3.1
^ permalink raw reply related
* RE: [net-next 2/6] fm10k: reduce duplicate fm10k_stat macro code
From: Keller, Jacob E @ 2018-05-08 17:40 UTC (permalink / raw)
To: Joe Perches, Kirsher, Jeffrey T, davem@davemloft.net
Cc: netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com
In-Reply-To: <63a9f68a10b1b4754918df527b0697ee9d435753.camel@perches.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Joe Perches
> Sent: Tuesday, May 08, 2018 10:00 AM
> To: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>; davem@davemloft.net
> Cc: Keller, Jacob E <jacob.e.keller@intel.com>; netdev@vger.kernel.org;
> nhorman@redhat.com; sassmann@redhat.com; jogreene@redhat.com
> Subject: Re: [net-next 2/6] fm10k: reduce duplicate fm10k_stat macro code
>
> On Mon, 2018-05-07 at 07:45 -0700, Jeff Kirsher wrote:
> > Share some of the code for setting up fm10k_stat macros by implementing
> > an FM10K_STAT_FIELDS macro which we can use when setting up the type
> > specific macros.
> []
> > diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
> b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
> []
> > @@ -11,12 +11,16 @@ struct fm10k_stats {
> > int stat_offset;
> > };o
> >
> > -#define FM10K_NETDEV_STAT(_net_stat) { \
> > - .stat_string = #_net_stat, \
> > - .sizeof_stat = FIELD_SIZEOF(struct net_device_stats, _net_stat), \
> > - .stat_offset = offsetof(struct net_device_stats, _net_stat) \
> > +#define FM10K_STAT_FIELDS(_type, _name, _stat) { \
> > + .stat_string = _name, \
> > + .sizeof_stat = FIELD_SIZEOF(_type, _stat), \
> > + .stat_offset = offsetof(_type, _stat) \
> > }
> >
> > +/* netdevice statistics */
> > +#define FM10K_NETDEV_STAT(_net_stat) \
> > + FM10K_STAT_FIELDS(struct net_device_stats, #_net_stat, _net_stat)
>
> trivia:
>
> It's somewhat unusual to use # in a macro argument.
> Perhaps this would be slightly easier to understand using __stringify
>
> #define FM10K_NETDEV_STAT(_net_stat) \
> FM10K_STAT_FIELDS(struct net_device_stats, __stringify(_net_stat),
> _net_stat)
Makes sense. Will change.
Thanks,
Jake
^ permalink raw reply
* Re: KASAN: use-after-free Read in sctp_do_sm
From: Xin Long @ 2018-05-08 17:41 UTC (permalink / raw)
To: syzbot
Cc: davem, LKML, linux-sctp, Marcelo Ricardo Leitner, network dev,
Neil Horman, syzkaller-bugs, Vlad Yasevich
In-Reply-To: <000000000000c10690056bb22ccd@google.com>
On Tue, May 8, 2018 at 9:58 PM, syzbot
<syzbot+141d898c5f24489db4aa@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: f142f08bf7ec Fix typo in comment.
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1159ade7800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=31f4b3733894ef79
> dashboard link: https://syzkaller.appspot.com/bug?extid=141d898c5f24489db4aa
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+141d898c5f24489db4aa@syzkaller.appspotmail.com
>
> RDX: 0000000000000008 RSI: 0000000020000000 RDI: 0000000000000014
> RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000015
> R13: 000000000000071e R14: 00000000006feb70 R15: 0000000000000007
> ==================================================================
> BUG: KASAN: use-after-free in sctp_cmd_interpreter
> net/sctp/sm_sideeffect.c:1817 [inline]
> BUG: KASAN: use-after-free in sctp_side_effects
> net/sctp/sm_sideeffect.c:1220 [inline]
> BUG: KASAN: use-after-free in sctp_do_sm+0x6015/0x7160
> net/sctp/sm_sideeffect.c:1191
> Read of size 1 at addr ffff8801c7883cb8 by task syz-executor6/18616
>
> CPU: 1 PID: 18616 Comm: syz-executor6 Not tainted 4.17.0-rc4+ #38
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> print_address_description+0x6c/0x20b mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
> __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1817 [inline]
> sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> sctp_do_sm+0x6015/0x7160 net/sctp/sm_sideeffect.c:1191
> sctp_assoc_bh_rcv+0x30f/0x520 net/sctp/associola.c:1065
> sctp_inq_push+0x263/0x320 net/sctp/inqueue.c:95
> sctp_backlog_rcv+0x192/0xc00 net/sctp/input.c:350
> sk_backlog_rcv include/net/sock.h:909 [inline]
> __release_sock+0x12f/0x3a0 net/core/sock.c:2335
> release_sock+0xa4/0x2b0 net/core/sock.c:2850
> sctp_sendmsg+0x13cc/0x1d70 net/sctp/socket.c:2128
> inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:629 [inline]
> sock_sendmsg+0xd5/0x120 net/socket.c:639
> sock_write_iter+0x35a/0x5a0 net/socket.c:908
> call_write_iter include/linux/fs.h:1784 [inline]
> new_sync_write fs/read_write.c:474 [inline]
> __vfs_write+0x64d/0x960 fs/read_write.c:487
> vfs_write+0x1f8/0x560 fs/read_write.c:549
> ksys_write+0xf9/0x250 fs/read_write.c:598
> __do_sys_write fs/read_write.c:610 [inline]
> __se_sys_write fs/read_write.c:607 [inline]
> __x64_sys_write+0x73/0xb0 fs/read_write.c:607
> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x455979
> RSP: 002b:00007f6fad842c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
> RAX: ffffffffffffffda RBX: 00007f6fad8436d4 RCX: 0000000000455979
> RDX: 0000000000000008 RSI: 0000000020000000 RDI: 0000000000000014
> RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000015
> R13: 000000000000071e R14: 00000000006feb70 R15: 0000000000000007
>
> Allocated by task 18616:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
> kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554
> kmem_cache_zalloc include/linux/slab.h:691 [inline]
> sctp_chunkify+0xce/0x400 net/sctp/sm_make_chunk.c:1355
> sctp_rcv+0xc65/0x3a60 net/sctp/input.c:221
> sctp6_rcv+0x15/0x30 net/sctp/ipv6.c:1045
> ip6_input_finish+0x3ff/0x1a30 net/ipv6/ip6_input.c:284
> NF_HOOK include/linux/netfilter.h:288 [inline]
> ip6_input+0xe1/0x5e0 net/ipv6/ip6_input.c:327
> dst_input include/net/dst.h:450 [inline]
> ip6_rcv_finish+0x29c/0xa10 net/ipv6/ip6_input.c:71
> NF_HOOK include/linux/netfilter.h:288 [inline]
> ipv6_rcv+0xed6/0x22a0 net/ipv6/ip6_input.c:208
> __netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592
> __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657
> process_backlog+0x219/0x760 net/core/dev.c:5337
> napi_poll net/core/dev.c:5735 [inline]
> net_rx_action+0x7b7/0x1930 net/core/dev.c:5801
> __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
>
> Freed by task 18616:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
> __cache_free mm/slab.c:3498 [inline]
> kmem_cache_free+0x86/0x2d0 mm/slab.c:3756
> sctp_chunk_destroy net/sctp/sm_make_chunk.c:1481 [inline]
> sctp_chunk_put+0x321/0x440 net/sctp/sm_make_chunk.c:1504
> sctp_ulpevent_make_rcvmsg+0x955/0xd40 net/sctp/ulpevent.c:718
There's no reason to put the chunk in sctp_ulpevent_make_rcvmsg's
fail_mark err path before holding this chunk later there.
We should just remove it.
@@ -715,7 +715,6 @@ struct sctp_ulpevent
*sctp_ulpevent_make_rcvmsg(struct sctp_association *asoc,
return event;
fail_mark:
- sctp_chunk_put(chunk);
kfree_skb(skb);
fail:
return NULL;
> sctp_ulpq_tail_data+0xa8/0x12b0 net/sctp/ulpqueue.c:108
> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1478 [inline]
> sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> sctp_do_sm+0x1658/0x7160 net/sctp/sm_sideeffect.c:1191
> sctp_assoc_bh_rcv+0x30f/0x520 net/sctp/associola.c:1065
> sctp_inq_push+0x263/0x320 net/sctp/inqueue.c:95
> sctp_backlog_rcv+0x192/0xc00 net/sctp/input.c:350
> sk_backlog_rcv include/net/sock.h:909 [inline]
> __release_sock+0x12f/0x3a0 net/core/sock.c:2335
> release_sock+0xa4/0x2b0 net/core/sock.c:2850
> sctp_sendmsg+0x13cc/0x1d70 net/sctp/socket.c:2128
> inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:629 [inline]
> sock_sendmsg+0xd5/0x120 net/socket.c:639
> sock_write_iter+0x35a/0x5a0 net/socket.c:908
> call_write_iter include/linux/fs.h:1784 [inline]
> new_sync_write fs/read_write.c:474 [inline]
> __vfs_write+0x64d/0x960 fs/read_write.c:487
> vfs_write+0x1f8/0x560 fs/read_write.c:549
> ksys_write+0xf9/0x250 fs/read_write.c:598
> __do_sys_write fs/read_write.c:610 [inline]
> __se_sys_write fs/read_write.c:607 [inline]
> __x64_sys_write+0x73/0xb0 fs/read_write.c:607
> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The buggy address belongs to the object at ffff8801c7883bc0
> which belongs to the cache sctp_chunk of size 256
> The buggy address is located 248 bytes inside of
> 256-byte region [ffff8801c7883bc0, ffff8801c7883cc0)
> The buggy address belongs to the page:
> page:ffffea00071e20c0 count:1 mapcount:0 mapping:ffff8801c7883080 index:0x0
> flags: 0x2fffc0000000100(slab)
> raw: 02fffc0000000100 ffff8801c7883080 0000000000000000 000000010000000c
> raw: ffffea000723a220 ffff8801cdb66f48 ffff8801cdb65600 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801c7883b80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
> ffff8801c7883c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>
>> ffff8801c7883c80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>
> ^
> ffff8801c7883d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801c7883d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at 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.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: general protection fault in encode_rpcb_string
From: Bruce Fields @ 2018-05-08 17:44 UTC (permalink / raw)
To: Chuck Lever
Cc: Trond Myklebust,
syzbot+4b98281f2401ab849f4b@syzkaller.appspotmail.com,
syzkaller-bugs@googlegroups.com, Anna Schumaker,
davem@davemloft.net, linux-kernel@vger.kernel.org,
Linux NFS Mailing List, jlayton@kernel.org,
netdev@vger.kernel.org
In-Reply-To: <4B24FAE4-C7E8-4D01-9808-B8F4E9E59D64@gmail.com>
On Tue, May 08, 2018 at 12:34:48PM -0400, Chuck Lever wrote:
>
>
> > On May 8, 2018, at 12:15 PM, bfields@fieldses.org wrote:
> >
> > On Tue, Apr 17, 2018 at 09:54:36PM +0000, Trond Myklebust wrote:
> >> Yes, and we can probably convert it, and the other GFP_ATOMIC
> >> allocations in the rpcbind client to use GFP_NOFS in order to improve
> >> reliability.
> >
> > Chuck, I think the GFP_ATOMIC is unnecessary here as well?
> >
> > --b.
> >
> > diff --git a/net/sunrpc/xprtrdma/rpc_rdma.c b/net/sunrpc/xprtrdma/rpc_rdma.c
> > index e8adad33d0bb..de90c6c90cde 100644
> > --- a/net/sunrpc/xprtrdma/rpc_rdma.c
> > +++ b/net/sunrpc/xprtrdma/rpc_rdma.c
> > @@ -228,7 +228,7 @@ rpcrdma_convert_iovs(struct rpcrdma_xprt *r_xprt, struct xdr_buf *xdrbuf,
> > /* XXX: Certain upper layer operations do
> > * not provide receive buffer pages.
> > */
> > - *ppages = alloc_page(GFP_ATOMIC);
> > + *ppages = alloc_page(GFP_NOFS);
> > if (!*ppages)
> > return -EAGAIN;
> > }
>
> This code can't sleep, as I understand it. Caller is holding
> the transport write lock. This logic was copied from
> xdr_partial_copy_from_skb, which uses GFP_ATOMIC.
OK.
> Recall that this is here because of GETACL. As I've stated in
> the past, the correct solution is to ensure that these pages
> are provided in every case by the upper layer, making this
> alloc_page call site unnecessary.
Got it.
--b.
^ permalink raw reply
* Failed to clone net-next.git
From: Song Liu @ 2018-05-08 17:46 UTC (permalink / raw)
To: Networking; +Cc: Alexei Starovoitov, Konstantin Ryabitsev
We are seeing the following error on multiple different systems while
cloning net-next tree.
$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
Cloning into 'net-next'...
remote: Counting objects: 6017287, done.
remote: Compressing objects: 100% (2458/2458), done.
fatal: The remote end hung up unexpectedly 1.00 GiB | 8.13 MiB/s
fatal: early EOF
fatal: index-pack failed
It looks like the size of the data being fetched reached server side
limit of 1.00 GiB. So we probably need change server side configuration.
Could someone please look into it?
If you see same problem. Here is a work-around for it:
1. clone a smaller tree, for example net.git;
2. add net-next as a new remote, and fetch it.
Thanks,
Song
^ permalink raw reply
* Re: [net-next PATCH 0/3] Symmetric queue selection using XPS for Rx queues
From: Nambiar, Amritha @ 2018-05-08 17:56 UTC (permalink / raw)
To: Alexander Duyck, Eric Dumazet
Cc: Tom Herbert, Eric Dumazet, netdev, David Miller, Alexander Duyck,
Samudrala, Sridhar, Hannes Frederic Sowa
In-Reply-To: <CAKgT0Ud=msT46kmEASzxD-0gL7EEKSB6hkSJ6BDx0gE3wpMxow@mail.gmail.com>
On 5/8/2018 10:19 AM, Alexander Duyck wrote:
> On Tue, May 8, 2018 at 10:07 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>
>>
>> On 05/08/2018 09:02 AM, Alexander Duyck wrote:
>>> On Tue, May 8, 2018 at 8:15 AM, Tom Herbert <tom@herbertland.com> wrote:
>>>> On Thu, Apr 19, 2018 at 7:41 PM, Eric Dumazet <edumazet@google.com> wrote:
>>>>> On Thu, Apr 19, 2018 at 6:07 PM Amritha Nambiar <amritha.nambiar@intel.com>
>>>>> wrote:
>>>>>
>>>>>> This patch series implements support for Tx queue selection based on
>>>>>> Rx queue map. This is done by configuring Rx queue map per Tx-queue
>>>>>> using sysfs attribute. If the user configuration for Rx queues does
>>>>>> not apply, then the Tx queue selection falls back to XPS using CPUs and
>>>>>> finally to hashing.
>>>>>
>>>>>> XPS is refactored to support Tx queue selection based on either the
>>>>>> CPU map or the Rx-queue map. The config option CONFIG_XPS needs to be
>>>>>> enabled. By default no receive queues are configured for the Tx queue.
>>>>>
>>>>>> - /sys/class/net/eth0/queues/tx-*/xps_rxqs
>>>>>
>>>>>> This is to enable sending packets on the same Tx-Rx queue pair as this
>>>>>> is useful for busy polling multi-threaded workloads where it is not
>>>>>> possible to pin the threads to a CPU. This is a rework of Sridhar's
>>>>>> patch for symmetric queueing via socket option:
>>>>>> https://www.spinics.net/lists/netdev/msg453106.html
>>>>>
>>>> I suspect this is an artifact of flow director which I believe
>>>> required queue pairs to be able to work (i.e. receive queue chose
>>>> hardware is determined send queue). But that was only required because
>>>> of hardware design, I don't see the rationale for introducing queue
>>>> pairs in the software stack. There's no need to correlate the transmit
>>>> path with receive path, no need to enforce a 1-1 mapping between RX
>>>> and TX queues, and the OOO mitigations should be sufficient when TX
>>>> queue changes for a flow.
>>>>
>>>> Tom
>>>
>>> If I am not mistaken I think there are benefits to doing this sort of
>>> thing with polling as it keeps the Tx work locked into the same queue
>>> pair that a given application is polling on. So as a result you can
>>> keep the interrupts contained to the queue pair that is being busy
>>> polled on and if the application cleans up the packets during the busy
>>> poll it ends up being a net savings in terms of both latency and power
>>> since the Tx clean-up happens sooner, and it happens on the queue that
>>> is already busy polling instead of possibly triggering an interrupt on
>>> another CPU.
>>>
>>> So for example in the case of routing and bridging workloads we
>>> already had code that would take the Rx queue and associate it to a Tx
>>> queue. One of the ideas behind doing this is to try and keep the CPU
>>> overhead low by having a 1:1 mapping. In the case of this code we
>>> allow for a little more flexibility in that you could have
>>> many-to-many mappings but the general idea and common use case is the
>>> same which is a 1:1 mapping.
>>
>>
>> I thought we had everything in place to be able to have this already.
>>
>> Setting IRQ affinities and XPS is certainly something doable.
>>
>> This is why I wanted a proper documentation of yet another way to reach the
>> same behavior.
>
> IRQ affinities and XPS work for pure NAPI setups, but the problem is
> you have to also do application affinity in the case of busy polling
> which can provide some additional challenges since then you have to
> add code in your application to associate a given queue/CPU to a given
> application thread. I believe this is a way of simplifying this.
>
> I agree on the documentation aspect. The usage of this should be well
> documented as well as the why of using it.
>
> - Alex
>
I'll submit another version of the series with the documentation added.
- Amritha
^ permalink raw reply
* Re: Failed to clone net-next.git
From: Konstantin Ryabitsev @ 2018-05-08 18:06 UTC (permalink / raw)
To: Song Liu, Networking; +Cc: Alexei Starovoitov
In-Reply-To: <FB252D9C-2FB2-437C-8646-4F61406AC96D@fb.com>
[-- Attachment #1.1: Type: text/plain, Size: 878 bytes --]
On 05/08/18 13:46, Song Liu wrote:
> We are seeing the following error on multiple different systems while
> cloning net-next tree.
>
> $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
> Cloning into 'net-next'...
> remote: Counting objects: 6017287, done.
> remote: Compressing objects: 100% (2458/2458), done.
> fatal: The remote end hung up unexpectedly 1.00 GiB | 8.13 MiB/s
> fatal: early EOF
> fatal: index-pack failed
>
> It looks like the size of the data being fetched reached server side
> limit of 1.00 GiB. So we probably need change server side configuration.
> Could someone please look into it?
It was probably due to a timeout value. Can you try it now, I've bumped
it to a much larger number.
Regards,
--
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v6 00/13] firmware_loader changes for v4.18
From: Luis R. Rodriguez @ 2018-05-08 18:12 UTC (permalink / raw)
To: gregkh
Cc: akpm, keescook, josh, maco, andy.gross, david.brown,
bjorn.andersson, teg, wagi, hdegoede, andresx7, zohar, kubakici,
shuah, mfuzzey, dhowells, pali.rohar, tiwai, kvalo,
arend.vanspriel, zajec5, nbroeking, markivx, broonie,
dmitry.torokhov, dwmw2, torvalds, Abhay_Salunke, jewalt, oneukum,
cantabile.desu, ast, hare, jejb, martin.petersen, khc, davem
Greg,
Here is what I have queued up for the firmware_loader for v4.18. It
includes a slew of cleanup work, and the new firmware_request_nowarn()
which is quiet but enables the sysfs fallback mechanism. I've gone ahead
and also queued up a few minor fixes for the firmware loader documentation
which have come up recently. These changes are available on my git tree
both based on linux-next [0] and Linus' latest tree [1]. Folks working
on new developments for the firmware loader can use my linux-next
branch 20180508-firmware_loader_for-v4.18-try2 for now.
0-day sends its blessings.
The patches from Mimi's series still require a bit more discussion and
review. The discussion over the EFI firmware fallback mechanism is still
ongoing.
As for the rename that you wanted, perhaps we can do this late in the
merge window considering we're at rc4 now. I can prep something up for
that later.
Question, and specially rants are warmly welcomed.
[0] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20180508-firmware_loader_for-v4.18-try2
[1] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=20180508-firmware_loader_for-v4.18-try2
Andres Rodriguez (6):
firmware: wrap FW_OPT_* into an enum
firmware: use () to terminate kernel-doc function names
firmware: rename fw_sysfs_fallback to firmware_fallback_sysfs()
firmware: add firmware_request_nowarn() - load firmware without
warnings
ath10k: use firmware_request_nowarn() to load firmware
ath10k: re-enable the firmware fallback mechanism for testmode
Luis R. Rodriguez (7):
firmware_loader: document firmware_sysfs_fallback()
firmware_loader: enhance Kconfig documentation over FW_LOADER
firmware_loader: move kconfig FW_LOADER entries to its own file
firmware_loader: make firmware_fallback_sysfs() print more useful
Documentation: fix few typos and clarifications for the firmware
loader
Documentation: remove stale firmware API reference
Documentation: clarify firmware_class provenance and why we can't
rename the module
Documentation/dell_rbu.txt | 3 -
.../firmware/fallback-mechanisms.rst | 14 +-
.../driver-api/firmware/firmware_cache.rst | 4 +-
.../driver-api/firmware/request_firmware.rst | 5 +
drivers/base/Kconfig | 90 ++--------
drivers/base/firmware_loader/Kconfig | 154 ++++++++++++++++++
drivers/base/firmware_loader/fallback.c | 53 ++++--
drivers/base/firmware_loader/fallback.h | 18 +-
drivers/base/firmware_loader/firmware.h | 37 ++++-
drivers/base/firmware_loader/main.c | 57 +++++--
drivers/net/wireless/ath/ath10k/core.c | 2 +-
drivers/net/wireless/ath/ath10k/testmode.c | 2 +-
include/linux/firmware.h | 10 ++
13 files changed, 319 insertions(+), 130 deletions(-)
create mode 100644 drivers/base/firmware_loader/Kconfig
--
2.17.0
^ permalink raw reply
* [PATCH v6 01/13] firmware: wrap FW_OPT_* into an enum
From: Luis R. Rodriguez @ 2018-05-08 18:12 UTC (permalink / raw)
To: gregkh
Cc: akpm, keescook, josh, maco, andy.gross, david.brown,
bjorn.andersson, teg, wagi, hdegoede, andresx7, zohar, kubakici,
shuah, mfuzzey, dhowells, pali.rohar, tiwai, kvalo,
arend.vanspriel, zajec5, nbroeking, markivx, broonie,
dmitry.torokhov, dwmw2, torvalds, Abhay_Salunke, jewalt, oneukum,
cantabile.desu, ast, hare, jejb, martin.petersen, khc, davem
In-Reply-To: <20180508181247.19431-1-mcgrof@kernel.org>
From: Andres Rodriguez <andresx7@gmail.com>
This should let us associate enum kdoc to these values.
While at it, kdocify the fw_opt.
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
[mcgrof: coding style fixes, merge kdoc with enum move]
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/base/firmware_loader/fallback.c | 12 ++++----
drivers/base/firmware_loader/fallback.h | 6 ++--
drivers/base/firmware_loader/firmware.h | 37 +++++++++++++++++++------
drivers/base/firmware_loader/main.c | 6 ++--
4 files changed, 42 insertions(+), 19 deletions(-)
diff --git a/drivers/base/firmware_loader/fallback.c b/drivers/base/firmware_loader/fallback.c
index 358354148dec..b57a7b3b4122 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -512,7 +512,7 @@ static const struct attribute_group *fw_dev_attr_groups[] = {
static struct fw_sysfs *
fw_create_instance(struct firmware *firmware, const char *fw_name,
- struct device *device, unsigned int opt_flags)
+ struct device *device, enum fw_opt opt_flags)
{
struct fw_sysfs *fw_sysfs;
struct device *f_dev;
@@ -545,7 +545,7 @@ fw_create_instance(struct firmware *firmware, const char *fw_name,
* In charge of constructing a sysfs fallback interface for firmware loading.
**/
static int fw_load_sysfs_fallback(struct fw_sysfs *fw_sysfs,
- unsigned int opt_flags, long timeout)
+ enum fw_opt opt_flags, long timeout)
{
int retval = 0;
struct device *f_dev = &fw_sysfs->dev;
@@ -599,7 +599,7 @@ static int fw_load_sysfs_fallback(struct fw_sysfs *fw_sysfs,
static int fw_load_from_user_helper(struct firmware *firmware,
const char *name, struct device *device,
- unsigned int opt_flags)
+ enum fw_opt opt_flags)
{
struct fw_sysfs *fw_sysfs;
long timeout;
@@ -640,7 +640,7 @@ static int fw_load_from_user_helper(struct firmware *firmware,
return ret;
}
-static bool fw_force_sysfs_fallback(unsigned int opt_flags)
+static bool fw_force_sysfs_fallback(enum fw_opt opt_flags)
{
if (fw_fallback_config.force_sysfs_fallback)
return true;
@@ -649,7 +649,7 @@ static bool fw_force_sysfs_fallback(unsigned int opt_flags)
return true;
}
-static bool fw_run_sysfs_fallback(unsigned int opt_flags)
+static bool fw_run_sysfs_fallback(enum fw_opt opt_flags)
{
if (fw_fallback_config.ignore_sysfs_fallback) {
pr_info_once("Ignoring firmware sysfs fallback due to sysctl knob\n");
@@ -664,7 +664,7 @@ static bool fw_run_sysfs_fallback(unsigned int opt_flags)
int fw_sysfs_fallback(struct firmware *fw, const char *name,
struct device *device,
- unsigned int opt_flags,
+ enum fw_opt opt_flags,
int ret)
{
if (!fw_run_sysfs_fallback(opt_flags))
diff --git a/drivers/base/firmware_loader/fallback.h b/drivers/base/firmware_loader/fallback.h
index f8255670a663..a3b73a09db6c 100644
--- a/drivers/base/firmware_loader/fallback.h
+++ b/drivers/base/firmware_loader/fallback.h
@@ -5,6 +5,8 @@
#include <linux/firmware.h>
#include <linux/device.h>
+#include "firmware.h"
+
/**
* struct firmware_fallback_config - firmware fallback configuration settings
*
@@ -31,7 +33,7 @@ struct firmware_fallback_config {
#ifdef CONFIG_FW_LOADER_USER_HELPER
int fw_sysfs_fallback(struct firmware *fw, const char *name,
struct device *device,
- unsigned int opt_flags,
+ enum fw_opt opt_flags,
int ret);
void kill_pending_fw_fallback_reqs(bool only_kill_custom);
@@ -43,7 +45,7 @@ void unregister_sysfs_loader(void);
#else /* CONFIG_FW_LOADER_USER_HELPER */
static inline int fw_sysfs_fallback(struct firmware *fw, const char *name,
struct device *device,
- unsigned int opt_flags,
+ enum fw_opt opt_flags,
int ret)
{
/* Keep carrying over the same error */
diff --git a/drivers/base/firmware_loader/firmware.h b/drivers/base/firmware_loader/firmware.h
index 64acbb1a392c..4f433b447367 100644
--- a/drivers/base/firmware_loader/firmware.h
+++ b/drivers/base/firmware_loader/firmware.h
@@ -2,6 +2,7 @@
#ifndef __FIRMWARE_LOADER_H
#define __FIRMWARE_LOADER_H
+#include <linux/bitops.h>
#include <linux/firmware.h>
#include <linux/types.h>
#include <linux/kref.h>
@@ -10,13 +11,33 @@
#include <generated/utsrelease.h>
-/* firmware behavior options */
-#define FW_OPT_UEVENT (1U << 0)
-#define FW_OPT_NOWAIT (1U << 1)
-#define FW_OPT_USERHELPER (1U << 2)
-#define FW_OPT_NO_WARN (1U << 3)
-#define FW_OPT_NOCACHE (1U << 4)
-#define FW_OPT_NOFALLBACK (1U << 5)
+/**
+ * enum fw_opt - options to control firmware loading behaviour
+ *
+ * @FW_OPT_UEVENT: Enables the fallback mechanism to send a kobject uevent
+ * when the firmware is not found. Userspace is in charge to load the
+ * firmware using the sysfs loading facility.
+ * @FW_OPT_NOWAIT: Used to describe the firmware request is asynchronous.
+ * @FW_OPT_USERHELPER: Enable the fallback mechanism, in case the direct
+ * filesystem lookup fails at finding the firmware. For details refer to
+ * fw_sysfs_fallback().
+ * @FW_OPT_NO_WARN: Quiet, avoid printing warning messages.
+ * @FW_OPT_NOCACHE: Disables firmware caching. Firmware caching is used to
+ * cache the firmware upon suspend, so that upon resume races against the
+ * firmware file lookup on storage is avoided. Used for calls where the
+ * file may be too big, or where the driver takes charge of its own
+ * firmware caching mechanism.
+ * @FW_OPT_NOFALLBACK: Disable the fallback mechanism. Takes precedence over
+ * &FW_OPT_UEVENT and &FW_OPT_USERHELPER.
+ */
+enum fw_opt {
+ FW_OPT_UEVENT = BIT(0),
+ FW_OPT_NOWAIT = BIT(1),
+ FW_OPT_USERHELPER = BIT(2),
+ FW_OPT_NO_WARN = BIT(3),
+ FW_OPT_NOCACHE = BIT(4),
+ FW_OPT_NOFALLBACK = BIT(5),
+};
enum fw_status {
FW_STATUS_UNKNOWN,
@@ -110,6 +131,6 @@ static inline void fw_state_done(struct fw_priv *fw_priv)
}
int assign_fw(struct firmware *fw, struct device *device,
- unsigned int opt_flags);
+ enum fw_opt opt_flags);
#endif /* __FIRMWARE_LOADER_H */
diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c
index eb34089e4299..9919f0e6a7cc 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -443,7 +443,7 @@ static int fw_add_devm_name(struct device *dev, const char *name)
#endif
int assign_fw(struct firmware *fw, struct device *device,
- unsigned int opt_flags)
+ enum fw_opt opt_flags)
{
struct fw_priv *fw_priv = fw->priv;
int ret;
@@ -558,7 +558,7 @@ static void fw_abort_batch_reqs(struct firmware *fw)
static int
_request_firmware(const struct firmware **firmware_p, const char *name,
struct device *device, void *buf, size_t size,
- unsigned int opt_flags)
+ enum fw_opt opt_flags)
{
struct firmware *fw = NULL;
int ret;
@@ -734,7 +734,7 @@ struct firmware_work {
struct device *device;
void *context;
void (*cont)(const struct firmware *fw, void *context);
- unsigned int opt_flags;
+ enum fw_opt opt_flags;
};
static void request_firmware_work_func(struct work_struct *work)
--
2.17.0
^ permalink raw reply related
* [PATCH v6 02/13] firmware: use () to terminate kernel-doc function names
From: Luis R. Rodriguez @ 2018-05-08 18:12 UTC (permalink / raw)
To: gregkh
Cc: akpm, keescook, josh, maco, andy.gross, david.brown,
bjorn.andersson, teg, wagi, hdegoede, andresx7, zohar, kubakici,
shuah, mfuzzey, dhowells, pali.rohar, tiwai, kvalo,
arend.vanspriel, zajec5, nbroeking, markivx, broonie,
dmitry.torokhov, dwmw2, torvalds, Abhay_Salunke, jewalt, oneukum,
cantabile.desu, ast, hare, jejb, martin.petersen, khc, davem
In-Reply-To: <20180508181247.19431-1-mcgrof@kernel.org>
From: Andres Rodriguez <andresx7@gmail.com>
The kernel-doc spec dictates a function name ends in ().
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
[mcgrof: adjust since the wide API rename is not yet merged]
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/base/firmware_loader/fallback.c | 8 ++++----
drivers/base/firmware_loader/main.c | 22 +++++++++++-----------
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/base/firmware_loader/fallback.c b/drivers/base/firmware_loader/fallback.c
index b57a7b3b4122..529f7013616f 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -125,7 +125,7 @@ static ssize_t timeout_show(struct class *class, struct class_attribute *attr,
}
/**
- * firmware_timeout_store - set number of seconds to wait for firmware
+ * firmware_timeout_store() - set number of seconds to wait for firmware
* @class: device class pointer
* @attr: device attribute pointer
* @buf: buffer to scan for timeout value
@@ -239,7 +239,7 @@ static int map_fw_priv_pages(struct fw_priv *fw_priv)
}
/**
- * firmware_loading_store - set value in the 'loading' control file
+ * firmware_loading_store() - set value in the 'loading' control file
* @dev: device pointer
* @attr: device attribute pointer
* @buf: buffer to scan for loading control value
@@ -431,7 +431,7 @@ static int fw_realloc_pages(struct fw_sysfs *fw_sysfs, int min_size)
}
/**
- * firmware_data_write - write method for firmware
+ * firmware_data_write() - write method for firmware
* @filp: open sysfs file
* @kobj: kobject for the device
* @bin_attr: bin_attr structure
@@ -537,7 +537,7 @@ fw_create_instance(struct firmware *firmware, const char *fw_name,
}
/**
- * fw_load_sysfs_fallback - load a firmware via the sysfs fallback mechanism
+ * fw_load_sysfs_fallback() - load a firmware via the sysfs fallback mechanism
* @fw_sysfs: firmware sysfs information for the firmware to load
* @opt_flags: flags of options, FW_OPT_*
* @timeout: timeout to wait for the load
diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c
index 9919f0e6a7cc..4d11efadb3a4 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -597,7 +597,7 @@ _request_firmware(const struct firmware **firmware_p, const char *name,
}
/**
- * request_firmware: - send firmware request and wait for it
+ * request_firmware() - send firmware request and wait for it
* @firmware_p: pointer to firmware image
* @name: name of firmware file
* @device: device for which firmware is being loaded
@@ -632,7 +632,7 @@ request_firmware(const struct firmware **firmware_p, const char *name,
EXPORT_SYMBOL(request_firmware);
/**
- * request_firmware_direct: - load firmware directly without usermode helper
+ * request_firmware_direct() - load firmware directly without usermode helper
* @firmware_p: pointer to firmware image
* @name: name of firmware file
* @device: device for which firmware is being loaded
@@ -657,7 +657,7 @@ int request_firmware_direct(const struct firmware **firmware_p,
EXPORT_SYMBOL_GPL(request_firmware_direct);
/**
- * firmware_request_cache: - cache firmware for suspend so resume can use it
+ * firmware_request_cache() - cache firmware for suspend so resume can use it
* @name: name of firmware file
* @device: device for which firmware should be cached for
*
@@ -681,7 +681,7 @@ int firmware_request_cache(struct device *device, const char *name)
EXPORT_SYMBOL_GPL(firmware_request_cache);
/**
- * request_firmware_into_buf - load firmware into a previously allocated buffer
+ * request_firmware_into_buf() - load firmware into a previously allocated buffer
* @firmware_p: pointer to firmware image
* @name: name of firmware file
* @device: device for which firmware is being loaded and DMA region allocated
@@ -713,7 +713,7 @@ request_firmware_into_buf(const struct firmware **firmware_p, const char *name,
EXPORT_SYMBOL(request_firmware_into_buf);
/**
- * release_firmware: - release the resource associated with a firmware image
+ * release_firmware() - release the resource associated with a firmware image
* @fw: firmware resource to release
**/
void release_firmware(const struct firmware *fw)
@@ -755,7 +755,7 @@ static void request_firmware_work_func(struct work_struct *work)
}
/**
- * request_firmware_nowait - asynchronous version of request_firmware
+ * request_firmware_nowait() - asynchronous version of request_firmware
* @module: module requesting the firmware
* @uevent: sends uevent to copy the firmware image if this flag
* is non-zero else the firmware copy must be done manually.
@@ -824,7 +824,7 @@ EXPORT_SYMBOL(request_firmware_nowait);
static ASYNC_DOMAIN_EXCLUSIVE(fw_cache_domain);
/**
- * cache_firmware - cache one firmware image in kernel memory space
+ * cache_firmware() - cache one firmware image in kernel memory space
* @fw_name: the firmware image name
*
* Cache firmware in kernel memory so that drivers can use it when
@@ -866,7 +866,7 @@ static struct fw_priv *lookup_fw_priv(const char *fw_name)
}
/**
- * uncache_firmware - remove one cached firmware image
+ * uncache_firmware() - remove one cached firmware image
* @fw_name: the firmware image name
*
* Uncache one firmware image which has been cached successfully
@@ -1042,7 +1042,7 @@ static void __device_uncache_fw_images(void)
}
/**
- * device_cache_fw_images - cache devices' firmware
+ * device_cache_fw_images() - cache devices' firmware
*
* If one device called request_firmware or its nowait version
* successfully before, the firmware names are recored into the
@@ -1075,7 +1075,7 @@ static void device_cache_fw_images(void)
}
/**
- * device_uncache_fw_images - uncache devices' firmware
+ * device_uncache_fw_images() - uncache devices' firmware
*
* uncache all firmwares which have been cached successfully
* by device_uncache_fw_images earlier
@@ -1092,7 +1092,7 @@ static void device_uncache_fw_images_work(struct work_struct *work)
}
/**
- * device_uncache_fw_images_delay - uncache devices firmwares
+ * device_uncache_fw_images_delay() - uncache devices firmwares
* @delay: number of milliseconds to delay uncache device firmwares
*
* uncache all devices's firmwares which has been cached successfully
--
2.17.0
^ permalink raw reply related
* [PATCH v6 03/13] firmware: rename fw_sysfs_fallback to firmware_fallback_sysfs()
From: Luis R. Rodriguez @ 2018-05-08 18:12 UTC (permalink / raw)
To: gregkh
Cc: akpm, keescook, josh, maco, andy.gross, david.brown,
bjorn.andersson, teg, wagi, hdegoede, andresx7, zohar, kubakici,
shuah, mfuzzey, dhowells, pali.rohar, tiwai, kvalo,
arend.vanspriel, zajec5, nbroeking, markivx, broonie,
dmitry.torokhov, dwmw2, torvalds, Abhay_Salunke, jewalt, oneukum,
cantabile.desu, ast, hare, jejb, martin.petersen, khc, davem
In-Reply-To: <20180508181247.19431-1-mcgrof@kernel.org>
From: Andres Rodriguez <andresx7@gmail.com>
This is done since this call is now exposed through kernel-doc,
and since this also paves the way for different future types of
fallback mechanims.
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
[mcgrof: small coding style changes]
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/base/firmware_loader/fallback.c | 8 ++++----
drivers/base/firmware_loader/fallback.h | 16 ++++++++--------
drivers/base/firmware_loader/firmware.h | 2 +-
drivers/base/firmware_loader/main.c | 2 +-
4 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/base/firmware_loader/fallback.c b/drivers/base/firmware_loader/fallback.c
index 529f7013616f..3db9e0f225ac 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -662,10 +662,10 @@ static bool fw_run_sysfs_fallback(enum fw_opt opt_flags)
return fw_force_sysfs_fallback(opt_flags);
}
-int fw_sysfs_fallback(struct firmware *fw, const char *name,
- struct device *device,
- enum fw_opt opt_flags,
- int ret)
+int firmware_fallback_sysfs(struct firmware *fw, const char *name,
+ struct device *device,
+ enum fw_opt opt_flags,
+ int ret)
{
if (!fw_run_sysfs_fallback(opt_flags))
return ret;
diff --git a/drivers/base/firmware_loader/fallback.h b/drivers/base/firmware_loader/fallback.h
index a3b73a09db6c..21063503e4ea 100644
--- a/drivers/base/firmware_loader/fallback.h
+++ b/drivers/base/firmware_loader/fallback.h
@@ -31,10 +31,10 @@ struct firmware_fallback_config {
};
#ifdef CONFIG_FW_LOADER_USER_HELPER
-int fw_sysfs_fallback(struct firmware *fw, const char *name,
- struct device *device,
- enum fw_opt opt_flags,
- int ret);
+int firmware_fallback_sysfs(struct firmware *fw, const char *name,
+ struct device *device,
+ enum fw_opt opt_flags,
+ int ret);
void kill_pending_fw_fallback_reqs(bool only_kill_custom);
void fw_fallback_set_cache_timeout(void);
@@ -43,10 +43,10 @@ void fw_fallback_set_default_timeout(void);
int register_sysfs_loader(void);
void unregister_sysfs_loader(void);
#else /* CONFIG_FW_LOADER_USER_HELPER */
-static inline int fw_sysfs_fallback(struct firmware *fw, const char *name,
- struct device *device,
- enum fw_opt opt_flags,
- int ret)
+static inline int firmware_fallback_sysfs(struct firmware *fw, const char *name,
+ struct device *device,
+ enum fw_opt opt_flags,
+ int ret)
{
/* Keep carrying over the same error */
return ret;
diff --git a/drivers/base/firmware_loader/firmware.h b/drivers/base/firmware_loader/firmware.h
index 4f433b447367..4c1395f8e7ed 100644
--- a/drivers/base/firmware_loader/firmware.h
+++ b/drivers/base/firmware_loader/firmware.h
@@ -20,7 +20,7 @@
* @FW_OPT_NOWAIT: Used to describe the firmware request is asynchronous.
* @FW_OPT_USERHELPER: Enable the fallback mechanism, in case the direct
* filesystem lookup fails at finding the firmware. For details refer to
- * fw_sysfs_fallback().
+ * firmware_fallback_sysfs().
* @FW_OPT_NO_WARN: Quiet, avoid printing warning messages.
* @FW_OPT_NOCACHE: Disables firmware caching. Firmware caching is used to
* cache the firmware upon suspend, so that upon resume races against the
diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c
index 4d11efadb3a4..abdc4e4d55f1 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -581,7 +581,7 @@ _request_firmware(const struct firmware **firmware_p, const char *name,
dev_warn(device,
"Direct firmware load for %s failed with error %d\n",
name, ret);
- ret = fw_sysfs_fallback(fw, name, device, opt_flags, ret);
+ ret = firmware_fallback_sysfs(fw, name, device, opt_flags, ret);
} else
ret = assign_fw(fw, device, opt_flags);
--
2.17.0
^ permalink raw reply related
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