* Re: [RFC PATCH v2] net: phy: Added device tree binding for dev-addr and dev-addr code check-up
From: Andrew Lunn @ 2018-03-27 14:24 UTC (permalink / raw)
To: Vicenţiu Galanopulo
Cc: Rob Herring, netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
mark.rutland@arm.com, davem@davemloft.net, marcel@holtmann.org,
devicetree@vger.kernel.org, Madalin-cristian Bucur,
Alexandru Marginean
In-Reply-To: <HE1PR0402MB3578B3D33160EBE59C2FD7D7EEAC0@HE1PR0402MB3578.eurprd04.prod.outlook.com>
> > This is a 2nd MDIO address, right? Can't you just append this to reg property?
Hi Rob
It is a sub address.
There are two different MDIO addressing schemes. Clause 22 allowed for
32 different addresses on an MDIO bus. Clause 45 extended that. You
have the existing 32 addresses for a package. However, within a
package, you can have 32 devices.
You are supposed to be able to look are registers inside the package,
and it will tell you which devices in the packages are in use. You can
then look at those devices and figure out what they are using ID
registers.
However some vendors get this wrong, they don't fill in the devices in
package information. So the generic probe code never finds them. We
need to pass it a hint, go looking at this specific device in the
package.
You can mix Clause 22 and Clause 45 on the same bus. Does DT allow two
different reg formats to be used at once? Can we have some reg
properties with a single value, and some with two values? I thought
#address-cells = <1> means there should be a single address in reg.
Andrew
^ permalink raw reply
* Re: [net-next PATCH 2/5] soc: ti: K2G: provide APIs to support driver probe deferral
From: Murali Karicheri @ 2018-03-27 14:31 UTC (permalink / raw)
To: Andrew Lunn
Cc: mark.rutland, devicetree, malat, netdev, linux-kernel, w-kwok2,
robh+dt, ssantosh, davem, linux-arm-kernel
In-Reply-To: <20180327140310.GK5862@lunn.ch>
Hello Andrew,
On 03/27/2018 10:03 AM, Andrew Lunn wrote:
>> Could you please elaborate? These knav dma and qmss drivers are
>> introduced to support packet DMA hardware available in Keystone
>> NetCP which couldn't be implemented using the DMA APIs available
>> at the time this driver was introduced. Another reason was that
>> the performance was really bad. We had an internal implementation
>> based on DMA API before which couldn't be upstreamed at that time
>> due to the reason that we were mis-using the API for this driver.
>> So we introduced these knav_dma driver to support NetCP. We don't
>> have any plan to re-write the driver at this time.
>>
>> If your question is about EPROBE_DEFER being returned from an
>> existing knav_dma API and using the return code to achieve probe
>> defer instead of introducing these APIs, I can take a look into
>> that and respond. So please clarify.
>
> Hi Murali
>
> So if i understood you right, at the time these drivers were written,
> the linux DMA API did not do what you wanted. You could hack something
> together by using the API wrongly, but that could not be mainlined. So
> rather than fixing the DMA API to make it work for this hardware, you
> ignored it, and made up your own API? This API now has its own
> problems, it does not correctly handle ordering? So you are hacking
> your own API further.
>
> Does the Linux DMA API correctly handle probing order issues? Has the
> Linux DMA API evolved so that it now does do what is needed by your
> hardware?
>
Thanks once again for your review and response!
I don't think dma API was meant to support hardware like pkt dma and was the
reason quoted when this driver was introduced and the same is valid even
today. AFAIK, Without hacking the API, we will not be able to support our
driver even today. Besides Keystone itself is an old platform that is
matured and have been there for long. K2G SoC was also introduced almost
3 years ago and we were late to port it to upstream due to various reasons.
We now have the SoC and most of the drivers upstreamed and this is a
missing driver to support networking. Given that we don't have any other
new devices planned from this SoC familty in the future, and the platform
itself is old and matured, I don't think the extra effort needed to
explore DMA API usage and re-write the driver is justified.
knav dma API is a TI SoC specific driver API and IMO, it should be fine\
to extend it to support probe deferral. I have also looked at the driver
and I don't see any other way to handle this since the channels are
allocated and used in ndo_open() and EPROBE_DEFER is not useful here.
Btw, I will re-write patch 3/5 as you have suggested as there is scope
for adding one more patch besides what I have mentioned in my response.
I will be sending v2 of the series soon with your comment on 3/5 addressed.
Regards,
Murali
> If this was an old hardware which is slowly going away, it would not
> be an issue. But it seems like there are new variants of the hardware
> being released. So maybe you should go back and re-write the DMA
> driver, rather than paper over the cracks?
>
> Andrew
>
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply
* Aw: Re: [PATCH v7 0/7] netdev: intel: Eliminate duplicate barriers on weakly-ordered archs
From: Lino Sanfilippo @ 2018-03-27 14:33 UTC (permalink / raw)
To: Sinan Kaya
Cc: Jeff Kirsher, Alexander Duyck, intel-wired-lan, Netdev,
Timur Tabi, sulrich, linux-arm-msm, linux-arm-kernel
In-Reply-To: <dcbd4406-73f7-4afa-850d-5f5d9f97ab02@codeaurora.org>
>
> On 3/27/2018 10:04 AM, Lino Sanfilippo wrote:
> > Hi,
> >
> >> Double sorry now.
> >>
> >> I don't know if you have been following "RFC on writel and writel_relaxed" thread
> >> or not but there are some new developments about wmb() requirement.
> >
> > Just out of interest: Where can this thread be found?
>
> https://www.spinics.net/lists/linux-rdma/msg62570.html
>
> https://patchwork.kernel.org/patch/10309913/
>
>
> >
> >>
> >> Basically, wmb() should never be used before writel() as writel() seem to
> >> provide coherency and observability guarantee.
> >>
> >
> > AFAIU memory-barriers.txt writel() only guarantees correct order of accesses to
> > IO-memory not RAM vs. IO-memory (this may be the case for some architectures
> > where the writel() implementation contains a wmb() but not for all).
> > For the RAM vs. IO-memory case at least a a wmb()/rmb() has to be used.
> > Is this not correct?
>
> We are being told that if you use writel(), then you don't need a wmb() on
> all architectures.
>
> Jason is seeking behavior clarification for write combined buffers.
>
Interesting, thanks for the information!
Lino
^ permalink raw reply
* Re: linux-next: manual merge of the ipsec tree with the net tree
From: Petr Machata @ 2018-03-27 14:33 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Steffen Klassert, David Miller, Networking,
Linux-Next Mailing List, Linux Kernel Mailing List,
Stefano Brivio
In-Reply-To: <20180326091610.148fc62d@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi Steffen,
>
> Today's linux-next merge of the ipsec tree got a conflict in:
>
> net/ipv4/ip_tunnel.c
>
> between commit:
>
> f6cc9c054e77 ("ip_tunnel: Emit events for post-register MTU changes")
>
> from the net tree and commit:
>
> 24fc79798b8d ("ip_tunnel: Clamp MTU to bounds on new link")
>
> from the ipsec tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Hi, this conflict needs to be resolved differently. Below I'm adding a
patch on top of linux-next. Squash or apply as you see fit.
What's the right way to proceed from here? It looks to me like Stefano
or Steffen should take this into the ipsec tree (possibly just squash to
the clamping fix), as they'll hit this conflict the next time they
rebase on top of net...? Let me know what to do, please.
Thanks,
Petr
>From 2c2210e59cd94571ac67d491026d6ea0f4d69ae4 Mon Sep 17 00:00:00 2001
Message-Id: <2c2210e59cd94571ac67d491026d6ea0f4d69ae4.1522155963.git.petrm@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Date: Tue, 27 Mar 2018 16:00:38 +0300
Subject: [PATCH linux-next] net: ip_tunnel: Call dev_set_mtu to set
clamped MTU
When adding a new IP tunnel link, MTU is clamped to sane bounds.
However, since the new MTU value is directly assigned to the netdevice,
instead of going through dev_set_mtu, the change is done without sending
the usual NETDEV_PRECHANGEMTU and NETDEV_CHANGEMTU events. Thus drivers
don't get to learn about the clamped MTU value.
Signed-off-by: Petr Machata <petrm@mellanox.com>
---
net/ipv4/ip_tunnel.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index a57cf0d..de6d944 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -1108,14 +1108,14 @@ int ip_tunnel_newlink(struct net_device *dev, struct nlattr *tb[],
if (tb[IFLA_MTU]) {
unsigned int max = 0xfff8 - dev->hard_header_len - nt->hlen;
- dev->mtu = clamp(dev->mtu, (unsigned int)ETH_MIN_MTU,
- (unsigned int)(max - sizeof(struct iphdr)));
- } else {
- err = dev_set_mtu(dev, mtu);
- if (err)
- goto err_dev_set_mtu;
+ mtu = clamp(dev->mtu, (unsigned int)ETH_MIN_MTU,
+ (unsigned int)(max - sizeof(struct iphdr)));
}
+ err = dev_set_mtu(dev, mtu);
+ if (err)
+ goto err_dev_set_mtu;
+
ip_tunnel_add(itn, nt);
return 0;
--
2.4.11
^ permalink raw reply related
* Re: [PATCH v7 0/7] netdev: intel: Eliminate duplicate barriers on weakly-ordered archs
From: Alexander Duyck @ 2018-03-27 14:38 UTC (permalink / raw)
To: Sinan Kaya
Cc: Lino Sanfilippo, Jeff Kirsher, intel-wired-lan, Netdev,
Timur Tabi, sulrich, linux-arm-msm, linux-arm-kernel
In-Reply-To: <dcbd4406-73f7-4afa-850d-5f5d9f97ab02@codeaurora.org>
On Tue, Mar 27, 2018 at 7:23 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
> On 3/27/2018 10:04 AM, Lino Sanfilippo wrote:
>> Hi,
>>
>>> Double sorry now.
>>>
>>> I don't know if you have been following "RFC on writel and writel_relaxed" thread
>>> or not but there are some new developments about wmb() requirement.
>>
>> Just out of interest: Where can this thread be found?
>
> https://www.spinics.net/lists/linux-rdma/msg62570.html
>
> https://patchwork.kernel.org/patch/10309913/
>
>
>>
>>>
>>> Basically, wmb() should never be used before writel() as writel() seem to
>>> provide coherency and observability guarantee.
>>>
>>
>> AFAIU memory-barriers.txt writel() only guarantees correct order of accesses to
>> IO-memory not RAM vs. IO-memory (this may be the case for some architectures
>> where the writel() implementation contains a wmb() but not for all).
>> For the RAM vs. IO-memory case at least a a wmb()/rmb() has to be used.
>> Is this not correct?
>
> We are being told that if you use writel(), then you don't need a wmb() on
> all architectures.
I'm not sure who told you that but that is incorrect, at least for
x86. If you attempt to use writel() without the wmb() we will have to
NAK the patches. We will accept the wmb() with writel_releaxed() since
that solves things for ARM.
> Jason is seeking behavior clarification for write combined buffers.
Don't bother. I can tell you right now that for x86 you have to have a
wmb() before the writel().
Based on the comment in
(https://www.spinics.net/lists/linux-rdma/msg62666.html):
Replacing wmb() + writel() with wmb() + writel_relaxed() will work on
PPC, it will just not give you a benefit today.
I say the patch set stays. This gives benefit on ARM, and has no
effect on x86 and PowerPC. If you want to look at trying to optimize
things further on PowerPC and such then go for it in terms of trying
to implement the writel_relaxed(). Otherwise I say we call the ARM
goodness a win and don't get ourselves too wrapped up in trying to fix
this for all architectures.
Thanks.
- Alex
^ permalink raw reply
* Re: [PATCH] net/ncsi: check for null return from call to nla_nest_start
From: David Miller @ 2018-03-27 14:39 UTC (permalink / raw)
To: colin.king; +Cc: dan.carpenter, sam, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20180326112712.31165-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Mon, 26 Mar 2018 12:27:12 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> The call to nla_nest_start calls nla_put which can lead to a NULL
> return so it's possible for attr to become NULL and we can potentially
> get a NULL pointer dereference on attr. Fix this by checking for
> a NULL return.
>
> Detected by CoverityScan, CID#1466125 ("Dereference null return")
>
> Fixes: 955dc68cb9b2 ("net/ncsi: Add generic netlink family")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied, but...
Colin, please start marking your Subject lines properly with "[PATCH
net-next]" for patches targetting net-next as opposed to net.
Thank you.
^ permalink raw reply
* Re: [PATCH 0/2] pull request for net: batman-adv 2018-03-26
From: David Miller @ 2018-03-27 14:40 UTC (permalink / raw)
To: sw; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <20180326124754.5897-1-sw@simonwunderlich.de>
From: Simon Wunderlich <sw@simonwunderlich.de>
Date: Mon, 26 Mar 2018 14:47:52 +0200
> here are two late bugfixes for batman-adv which we would like to have in net
> if still possible.
>
> Please pull or let me know of any problem!
Pulled, thank you Simon.
^ permalink raw reply
* Re: [PATCH v6 bpf-next 07/11] tracepoint: introduce kernel_tracepoint_find_by_name
From: Steven Rostedt @ 2018-03-27 14:42 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Alexei Starovoitov, David S. Miller, Daniel Borkmann,
Linus Torvalds, Peter Zijlstra, netdev, kernel-team, linux-api
In-Reply-To: <1566743692.1117.1522160304471.JavaMail.zimbra@efficios.com>
On Tue, 27 Mar 2018 10:18:24 -0400 (EDT)
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> ----- On Mar 27, 2018, at 10:07 AM, rostedt rostedt@goodmis.org wrote:
>
> > On Mon, 26 Mar 2018 19:47:02 -0700
> > Alexei Starovoitov <ast@fb.com> wrote:
> >
> >> From: Alexei Starovoitov <ast@kernel.org>
> >>
> >> introduce kernel_tracepoint_find_by_name() helper to let bpf core
> >> find tracepoint by name and later attach bpf probe to a tracepoint
> >>
> >> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> >
> > Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
>
> Steven showed preference for tracepoint_kernel_find_by_name() at some
> point (starting with a tracepoint_ prefix). I'm find with either of
> the names.
Yeah, I do prefer tracepoint_kernel_find_by_name() to stay consistent
with the other tracepoint functions. But we have
"for_each_kernel_tracepoint()" and not "for_each_tracepoint_kernel()",
thus we need to pick being consistent with one or the other. One answer
is to use tracpoint_kernel_find_by_name() and rename the for_each to
for_each_tracpoint_kernel().
-- Steve
>
> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>
> Thanks,
>
> Mathieu
>
> >
> > Thanks for doing this Alexei!
> >
> > One nit below.
^ permalink raw reply
* Re: [PATCH v2 iproute2-next 3/6] rdma: Add CM_ID resource tracking information
From: Jason Gunthorpe @ 2018-03-27 14:44 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: Steve Wise, David Ahern, stephen, netdev, linux-rdma
In-Reply-To: <20180327032141.GS1877@mtr-leonro.local>
On Tue, Mar 27, 2018 at 06:21:41AM +0300, Leon Romanovsky wrote:
> On Mon, Mar 26, 2018 at 04:30:33PM -0600, Jason Gunthorpe wrote:
> > On Mon, Mar 26, 2018 at 04:34:44PM -0500, Steve Wise wrote:
> > >
> > > On 3/26/2018 4:15 PM, Jason Gunthorpe wrote:
> > > > On Mon, Mar 26, 2018 at 09:30:41AM -0500, Steve Wise wrote:
> > > >>
> > > >> On 3/26/2018 9:17 AM, David Ahern wrote:
> > > >>> On 2/27/18 9:07 AM, Steve Wise wrote:
> > > >>>> diff --git a/rdma/rdma.h b/rdma/rdma.h
> > > >>>> index 5809f70..e55205b 100644
> > > >>>> +++ b/rdma/rdma.h
> > > >>>> @@ -18,10 +18,12 @@
> > > >>>> #include <libmnl/libmnl.h>
> > > >>>> #include <rdma/rdma_netlink.h>
> > > >>>> #include <time.h>
> > > >>>> +#include <net/if_arp.h>
> > > >>>>
> > > >>>> #include "list.h"
> > > >>>> #include "utils.h"
> > > >>>> #include "json_writer.h"
> > > >>>> +#include <rdma/rdma_cma.h>
> > > >>>>
> > > >>> did you forget to add rdma_cma.h? I don't see that file in my repo.
> > > >> It is provided by the rdma-core package, upon which rdma tool now
> > > >> depends for the rdma_port_space enum.
> > > > It is a kernel bug that enum is not in an include/uapi/rdma header
> > > >
> > > > Fix it there and don't try to use rdma-core headers to get kernel ABI.
> > > >
> > > > Jason
> > >
> > > I wish you'd commented on this just a little sooner. I just resent v3
> > > of this series... with rdma_cma.h included. :)
> > >
> > > How about the restrack/nldev code just translates the port space from
> > > enum rdma_port_space to a new ABI enum, say nldev_rdma_port_space, that
> > > i add to rdma_netlink.h? I'd hate to open the can of worms of trying to
> > > split rdma_cma.h into uabi and no uabi headers. :(
> >
> > If port space is already part of the ABI there isn't much reason to
> > translate it.
> >
> > You just need to pick the right header to put it in, since it is a verbs
> > define it doesn't belong in the netlink header.
>
> I completely understand Steve's concerns.
>
> I tried to do such thing (expose kernel headers) in first incarnation of
> rdmatool with attempt to clean IB/core as well to ensure that we won't expose
> anything that is not implemented. It didn't go well.
rdma-core is now using the kernel uapi/ headers natively, seems to be
going OK. What problem did you face?
Jason
^ permalink raw reply
* Re: RFC on writel and writel_relaxed
From: Sinan Kaya @ 2018-03-27 14:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Arnd Bergmann, Jason Gunthorpe
Cc: David Laight, Oliver,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
linux-rdma@vger.kernel.org, Alexander Duyck, Will Deacon,
Paul E. McKenney, netdev@vger.kernel.org, Alexander Duyck
In-Reply-To: <1522101616.7364.13.camel@kernel.crashing.org>
+netdev, +Alex
On 3/26/2018 6:00 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2018-03-26 at 23:30 +0200, Arnd Bergmann wrote:
>> Most of the drivers have a unwound loop with writeq() or something to
>>> do it.
>>
>> But isn't the writeq() barrier much more expensive than anything you'd
>> do in function calls?
>
> It is for us, and will break any write combining.
>
>>>>> The same document says that _relaxed() does not give that guarentee.
>>>>>
>>>>> The lwn articule on this went into some depth on the interaction with
>>>>> spinlocks.
>>>>>
>>>>> As far as I can see, containment in a spinlock seems to be the only
>>>>> different between writel and writel_relaxed..
>>>>
>>>> I was always puzzled by this: The intention of _relaxed() on ARM
>>>> (where it originates) was to skip the barrier that serializes DMA
>>>> with MMIO, not to skip the serialization between MMIO and locks.
>>>
>>> But that was never a requirement of writel(),
>>> Documentation/memory-barriers.txt gives an explicit example demanding
>>> the wmb() before writel() for ordering system memory against writel.
>
> This is a bug in the documentation.
>
>> Indeed, but it's in an example for when to use dma_wmb(), not wmb().
>> Adding Alexander Duyck to Cc, he added that section as part of
>> 1077fa36f23e ("arch: Add lightweight memory barriers dma_rmb() and
>> dma_wmb()"). Also adding the other people that were involved with that.
>
> Linus himself made it very clear years ago. readl and writel have to
> order vs memory accesses.
>
>>> I actually have no idea why ARM had that barrier, I always assumed it
>>> was to give program ordering to the accesses and that _relaxed allowed
>>> re-ordering (the usual meaning of relaxed)..
>>>
>>> But the barrier document makes it pretty clear that the only
>>> difference between the two is spinlock containment, and WillD wrote
>>> this text, so I belive it is accurate for ARM.
>>>
>>> Very confusing.
>>
>> It does mention serialization with both DMA and locks in the
>> section about readX_relaxed()/writeX_relaxed(). The part
>> about DMA is very clear here, and I must have just forgotten
>> the exact semantics with regards to spinlocks. I'm still not
>> sure what prevents a writel() from leaking out the end of a
>> spinlock section that doesn't happen with writel_relaxed(), since
>> the barrier in writel() comes before the access, and the
>> spin_unlock() shouldn't affect the external buses.
>
> So...
>
> Historically, what happened is that we (we means whoever participated
> in the discussion on the list with Linus calling the shots really)
> decided that there was no sane way for drivers to understand a world
> where readl/writel didn't fully order things vs. memory accesses (ie,
> DMA).
>
> So it should always be correct to do:
>
> - Write to some in-memory buffer
> - writel() to kick the DMA read of that buffer
>
> without any extra barrier.
>
> The spinlock situation however got murky. Mostly that came up because
> on architecture (I forgot who, might have been ia64) has a hard time
> providing that consistency without making writel insanely expensive.
>
> Thus they created mmiowb whose main purpose was precisely to order
> writel with a following spin_unlock.
>
> I decided not to go down that path on power because getting all drivers
> "fixed" to do the right thing was going to be a losing battle, and
> instead added per-cpu tracking of writel in order to "escalate" to a
> heavier barrier in spin_unlock itself when necessary.
>
> Now, all this happened more than a decade ago and it's possible that
> the understanding or expectations "shifted" over time...
Alex is raising concerns on the netdev list.
Sinan
"We are being told that if you use writel(), then you don't need a wmb() on
all architectures."
Alex:
"I'm not sure who told you that but that is incorrect, at least for
x86. If you attempt to use writel() without the wmb() we will have to
NAK the patches. We will accept the wmb() with writel_releaxed() since
that solves things for ARM."
> Jason is seeking behavior clarification for write combined buffers.
Alex:
"Don't bother. I can tell you right now that for x86 you have to have a
wmb() before the writel().
Based on the comment in
(https://www.spinics.net/lists/linux-rdma/msg62666.html):
Replacing wmb() + writel() with wmb() + writel_relaxed() will work on
PPC, it will just not give you a benefit today.
I say the patch set stays. This gives benefit on ARM, and has no
effect on x86 and PowerPC. If you want to look at trying to optimize
things further on PowerPC and such then go for it in terms of trying
to implement the writel_relaxed(). Otherwise I say we call the ARM
goodness a win and don't get ourselves too wrapped up in trying to fix
this for all architectures."
>
> Cheers,
> Ben.
>
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH net-next 0/2] net: mvpp2: Remove unnecessary dynamic allocs
From: David Miller @ 2018-03-27 14:47 UTC (permalink / raw)
To: maxime.chevallier
Cc: netdev, linux-kernel, antoine.tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, ymarkman, mw
In-Reply-To: <20180326133423.14779-1-maxime.chevallier@bootlin.com>
From: Maxime Chevallier <maxime.chevallier@bootlin.com>
Date: Mon, 26 Mar 2018 15:34:21 +0200
> Some utility functions in mvpp2 make use of dynamic alloc to exchange temporary
> objects representing Parser Entries (which are generic filtering entries in the
> PPv2 controller).
>
> These objects are small (44 bytes each), we can use the stack to exchange them.
>
> Some previous discussion on this topic showed that the mvpp2_prs_hw_read, which
> initializes a struct mvpp2_prs_entry based on one of its fields, can easily lead
> to erroneous code if we don't zero-out the struct beforehand :
>
> https://lkml.org/lkml/2018/3/21/739
>
> To fix this, I propose to rename mvpp2_prs_hw_read into mvpp2_prs_init_from_hw,
> make it zero-out the struct and take the index as a parameter. That's what's
> done in the first patch of the series.
>
> The second patch is the V3 of
> ("net: mvpp2: Don't use dynamic allocs for local variables"), making use of
> mvpp2_prs_init_from_hw and taking previous comments into account.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH v7 0/7] netdev: intel: Eliminate duplicate barriers on weakly-ordered archs
From: Sinan Kaya @ 2018-03-27 14:48 UTC (permalink / raw)
To: Alexander Duyck
Cc: Lino Sanfilippo, Jeff Kirsher, intel-wired-lan, Netdev,
Timur Tabi, sulrich, linux-arm-msm, linux-arm-kernel
In-Reply-To: <CAKgT0UfeMY0WsJGARrVxNsHzr8OnNSJ2jaYbBTGQNkR_uizJuQ@mail.gmail.com>
On 3/27/2018 10:38 AM, Alexander Duyck wrote:
>> We are being told that if you use writel(), then you don't need a wmb() on
>> all architectures.
> I'm not sure who told you that but that is incorrect, at least for
> x86. If you attempt to use writel() without the wmb() we will have to
> NAK the patches. We will accept the wmb() with writel_releaxed() since
> that solves things for ARM.
>
I added netdev and you to the RFC on writel and writel_relaxed list.
Feel free to raise your concerns.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH net-next] net: mvpp2: Use relaxed I/O in data path
From: Maxime Chevallier @ 2018-03-27 14:49 UTC (permalink / raw)
To: davem
Cc: Yan Markman, netdev, linux-kernel, Antoine Tenart,
thomas.petazzoni, gregory.clement, miquel.raynal, nadavh, stefanc,
mw, Maxime Chevallier
From: Yan Markman <ymarkman@marvell.com>
Use relaxed I/O on the hot path. This achieves significant performance
improvements. On a 10G link, this makes a basic iperf TCP test go from
an average of 4.5 Gbits/sec to about 9.40 Gbits/sec.
Signed-off-by: Yan Markman <ymarkman@marvell.com>
[Maxime: Commit message, cosmetic changes]
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
David, this patch should not conflict with other the pending PPv2 series I sent
earlier ("[PATCH net-next 0/2] net: mvpp2: Remove unnecessary dynamic allocs")
drivers/net/ethernet/marvell/mvpp2.c | 43 +++++++++++++++++++++++++-----------
1 file changed, 30 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index f8bc3d4a39ff..5a68e00e9c5b 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -1359,6 +1359,10 @@ static u32 mvpp2_read(struct mvpp2 *priv, u32 offset)
return readl(priv->swth_base[0] + offset);
}
+static u32 mvpp2_read_relaxed(struct mvpp2 *priv, u32 offset)
+{
+ return readl_relaxed(priv->swth_base[0] + offset);
+}
/* These accessors should be used to access:
*
* - per-CPU registers, where each CPU has its own copy of the
@@ -1407,6 +1411,18 @@ static u32 mvpp2_percpu_read(struct mvpp2 *priv, int cpu,
return readl(priv->swth_base[cpu] + offset);
}
+static void mvpp2_percpu_write_relaxed(struct mvpp2 *priv, int cpu,
+ u32 offset, u32 data)
+{
+ writel_relaxed(data, priv->swth_base[cpu] + offset);
+}
+
+static u32 mvpp2_percpu_read_relaxed(struct mvpp2 *priv, int cpu,
+ u32 offset)
+{
+ return readl_relaxed(priv->swth_base[cpu] + offset);
+}
+
static dma_addr_t mvpp2_txdesc_dma_addr_get(struct mvpp2_port *port,
struct mvpp2_tx_desc *tx_desc)
{
@@ -4488,8 +4504,8 @@ static inline void mvpp2_bm_pool_put(struct mvpp2_port *port, int pool,
<< MVPP22_BM_ADDR_HIGH_VIRT_RLS_SHIFT) &
MVPP22_BM_ADDR_HIGH_VIRT_RLS_MASK;
- mvpp2_percpu_write(port->priv, cpu,
- MVPP22_BM_ADDR_HIGH_RLS_REG, val);
+ mvpp2_percpu_write_relaxed(port->priv, cpu,
+ MVPP22_BM_ADDR_HIGH_RLS_REG, val);
}
/* MVPP2_BM_VIRT_RLS_REG is not interpreted by HW, and simply
@@ -4497,10 +4513,10 @@ static inline void mvpp2_bm_pool_put(struct mvpp2_port *port, int pool,
* descriptor. Instead of storing the virtual address, we
* store the physical address
*/
- mvpp2_percpu_write(port->priv, cpu,
- MVPP2_BM_VIRT_RLS_REG, buf_phys_addr);
- mvpp2_percpu_write(port->priv, cpu,
- MVPP2_BM_PHY_RLS_REG(pool), buf_dma_addr);
+ mvpp2_percpu_write_relaxed(port->priv, cpu,
+ MVPP2_BM_VIRT_RLS_REG, buf_phys_addr);
+ mvpp2_percpu_write_relaxed(port->priv, cpu,
+ MVPP2_BM_PHY_RLS_REG(pool), buf_dma_addr);
put_cpu();
}
@@ -5592,7 +5608,8 @@ static int mvpp2_aggr_desc_num_check(struct mvpp2 *priv,
if ((aggr_txq->count + num) > MVPP2_AGGR_TXQ_SIZE) {
/* Update number of occupied aggregated Tx descriptors */
int cpu = smp_processor_id();
- u32 val = mvpp2_read(priv, MVPP2_AGGR_TXQ_STATUS_REG(cpu));
+ u32 val = mvpp2_read_relaxed(priv,
+ MVPP2_AGGR_TXQ_STATUS_REG(cpu));
aggr_txq->count = val & MVPP2_AGGR_TXQ_PENDING_MASK;
}
@@ -5616,9 +5633,9 @@ static int mvpp2_txq_alloc_reserved_desc(struct mvpp2 *priv,
int cpu = smp_processor_id();
val = (txq->id << MVPP2_TXQ_RSVD_REQ_Q_OFFSET) | num;
- mvpp2_percpu_write(priv, cpu, MVPP2_TXQ_RSVD_REQ_REG, val);
+ mvpp2_percpu_write_relaxed(priv, cpu, MVPP2_TXQ_RSVD_REQ_REG, val);
- val = mvpp2_percpu_read(priv, cpu, MVPP2_TXQ_RSVD_RSLT_REG);
+ val = mvpp2_percpu_read_relaxed(priv, cpu, MVPP2_TXQ_RSVD_RSLT_REG);
return val & MVPP2_TXQ_RSVD_RSLT_MASK;
}
@@ -5723,8 +5740,8 @@ static inline int mvpp2_txq_sent_desc_proc(struct mvpp2_port *port,
u32 val;
/* Reading status reg resets transmitted descriptor counter */
- val = mvpp2_percpu_read(port->priv, smp_processor_id(),
- MVPP2_TXQ_SENT_REG(txq->id));
+ val = mvpp2_percpu_read_relaxed(port->priv, smp_processor_id(),
+ MVPP2_TXQ_SENT_REG(txq->id));
return (val & MVPP2_TRANSMITTED_COUNT_MASK) >>
MVPP2_TRANSMITTED_COUNT_OFFSET;
@@ -7090,8 +7107,8 @@ static int mvpp2_poll(struct napi_struct *napi, int budget)
*
* Each CPU has its own Rx/Tx cause register
*/
- cause_rx_tx = mvpp2_percpu_read(port->priv, qv->sw_thread_id,
- MVPP2_ISR_RX_TX_CAUSE_REG(port->id));
+ cause_rx_tx = mvpp2_percpu_read_relaxed(port->priv, qv->sw_thread_id,
+ MVPP2_ISR_RX_TX_CAUSE_REG(port->id));
cause_misc = cause_rx_tx & MVPP2_CAUSE_MISC_SUM_MASK;
if (cause_misc) {
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next] net: aquantia: Make function hw_atl_utils_mpi_set_speed() static
From: David Miller @ 2018-03-27 14:50 UTC (permalink / raw)
To: weiyongjun1; +Cc: igor.russkikh, pavel.belous, netdev, kernel-janitors
In-Reply-To: <1522074747-22610-1-git-send-email-weiyongjun1@huawei.com>
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Mon, 26 Mar 2018 14:32:27 +0000
> Fixes the following sparse warning:
>
> drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c:508:5: warning:
> symbol 'hw_atl_utils_mpi_set_speed' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] tipc: fix error handling in tipc_udp_enable()
From: David Miller @ 2018-03-27 14:50 UTC (permalink / raw)
To: weiyongjun1; +Cc: jon.maloy, ying.xue, netdev, tipc-discussion, kernel-janitors
In-Reply-To: <1522074764-22678-1-git-send-email-weiyongjun1@huawei.com>
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Mon, 26 Mar 2018 14:32:44 +0000
> Release alloced resource before return from the error handling
> case in tipc_udp_enable(), otherwise will cause memory leak.
>
> Fixes: 52dfae5c85a4 ("tipc: obtain node identity from interface by default")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] tipc: tipc_node_create() can be static
From: David Miller @ 2018-03-27 14:50 UTC (permalink / raw)
To: weiyongjun1; +Cc: kernel-janitors, tipc-discussion, netdev
In-Reply-To: <1522074793-22753-1-git-send-email-weiyongjun1@huawei.com>
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Mon, 26 Mar 2018 14:33:13 +0000
> Fixes the following sparse warning:
>
> net/tipc/node.c:336:18: warning:
> symbol 'tipc_node_create' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply
* Re: [PATCH v2] net-usb: add qmi_wwan if on lte modem wistron neweb d18q1
From: David Miller @ 2018-03-27 14:51 UTC (permalink / raw)
To: giu.lippolis; +Cc: netdev
In-Reply-To: <1522074879-2349-1-git-send-email-giu.lippolis@gmail.com>
From: Giuseppe Lippolis <giu.lippolis@gmail.com>
Date: Mon, 26 Mar 2018 16:34:39 +0200
> This modem is embedded on dlink dwr-921 router.
> The oem configuration states:
...
> Tested on openwrt distribution
>
> Signed-off-by: Giuseppe Lippolis <giu.lippolis@gmail.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next 1/1] tc-testing: Correct compound statements for namespace execution
From: David Miller @ 2018-03-27 14:52 UTC (permalink / raw)
To: lucasb; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri
In-Reply-To: <1522075574-11028-1-git-send-email-lucasb@mojatatu.com>
From: Lucas Bates <lucasb@mojatatu.com>
Date: Mon, 26 Mar 2018 10:46:14 -0400
> If tdc is executing test cases inside a namespace, only the
> first command in a compound statement will be executed inside
> the namespace by tdc. As a result, the subsequent commands
> are not executed inside the namespace and the test will fail.
>
> Example:
>
> for i in {x..y}; do args="foo"; done && tc actions add $args
>
> The namespace execution feature will prepend 'ip netns exec'
> to the command:
>
> ip netns exec tcut for i in {x..y}; do args="foo"; done && \
> tc actions add $args
>
> So the actual tc command is not parsed by the shell as being
> part of the namespace execution.
>
> Enclosing these compound statements inside a bash invocation
> with proper escape characters resolves the problem by creating
> a subshell inside the namespace.
>
> Signed-off-by: Lucas Bates <lucasb@mojatatu.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net] net: fix possible out-of-bound read in skb_network_protocol()
From: David Miller @ 2018-03-27 14:53 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, pshelar
In-Reply-To: <20180326150807.68287-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Mon, 26 Mar 2018 08:08:07 -0700
> skb mac header is not necessarily set at the time skb_network_protocol()
> is called. Use skb->data instead.
>
> BUG: KASAN: slab-out-of-bounds in skb_network_protocol+0x46b/0x4b0 net/core/dev.c:2739
> Read of size 2 at addr ffff8801b3097a0b by task syz-executor5/14242
>
> CPU: 1 PID: 14242 Comm: syz-executor5 Not tainted 4.16.0-rc6+ #280
> 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
> print_address_description+0x73/0x250 mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report+0x23c/0x360 mm/kasan/report.c:412
> __asan_report_load_n_noabort+0xf/0x20 mm/kasan/report.c:443
> skb_network_protocol+0x46b/0x4b0 net/core/dev.c:2739
> harmonize_features net/core/dev.c:2924 [inline]
> netif_skb_features+0x509/0x9b0 net/core/dev.c:3011
> validate_xmit_skb+0x81/0xb00 net/core/dev.c:3084
> validate_xmit_skb_list+0xbf/0x120 net/core/dev.c:3142
> packet_direct_xmit+0x117/0x790 net/packet/af_packet.c:256
> packet_snd net/packet/af_packet.c:2944 [inline]
> packet_sendmsg+0x3aed/0x60b0 net/packet/af_packet.c:2969
> sock_sendmsg_nosec net/socket.c:629 [inline]
> sock_sendmsg+0xca/0x110 net/socket.c:639
> ___sys_sendmsg+0x767/0x8b0 net/socket.c:2047
> __sys_sendmsg+0xe5/0x210 net/socket.c:2081
>
> Fixes: 19acc327258a ("gso: Handle Trans-Ether-Bridging protocol in skb_network_protocol()")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Pravin B Shelar <pshelar@ovn.org>
> Reported-by: Reported-by: syzbot <syzkaller@googlegroups.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH] ipv6: addrconf: Use normal debugging style
From: David Miller @ 2018-03-27 14:54 UTC (permalink / raw)
To: joe; +Cc: kuznet, yoshfuji, netdev, linux-kernel
In-Reply-To: <40e88b53c25ddb95d36bb7a061806f2f95f5ccf2.1522078288.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Mon, 26 Mar 2018 08:35:01 -0700
> Remove local ADBG macro and use netdev_dbg/pr_debug
>
> Miscellanea:
>
> o Remove unnecessary debug message after allocation failure as there
> already is a dump_stack() on the failure paths
> o Leave the allocation failure message on snmp6_alloc_dev as there
> is one code path that does not do a dump_stack()
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
>
> Remerged resend of http://patchwork.ozlabs.org/patch/826028/
> back in October 2017
Applied to net-next, thanks Joe.
^ permalink raw reply
* Re: [PATCH v2 net] r8169: fix setting driver_data after register_netdev
From: David Miller @ 2018-03-27 14:56 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <2e728314-2f34-1e51-7a4a-ae227eb2a2c6@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Mon, 26 Mar 2018 19:19:30 +0200
> pci_set_drvdata() is called only after registering the net_device,
> therefore we could run into a NPE if one of the functions using
> driver_data is called before it's set.
>
> Fix this by calling pci_set_drvdata() before registering the
> net_device.
>
> This fix is a candidate for stable. As far as I can see the
> bug has been there in kernel version 3.2 already, therefore
> I can't provide a reference which commit is fixed by it.
>
> The fix may need small adjustments per kernel version because
> due to other changes the label which is jumped to if
> register_netdev() fails has changed over time.
>
> Reported-by: David Miller <davem@davemloft.net>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> v2:
> - rebased based on net instead of net-next
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net 1/1] net sched actions: fix dumping which requires several messages to user space
From: David Miller @ 2018-03-27 14:59 UTC (permalink / raw)
To: cdillaba; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri
In-Reply-To: <1522090712-9154-1-git-send-email-cdillaba@mojatatu.com>
From: Craig Dillabaugh <cdillaba@mojatatu.com>
Date: Mon, 26 Mar 2018 14:58:32 -0400
> Fixes a bug in the tcf_dump_walker function that can cause some actions
> to not be reported when dumping a large number of actions. This issue
> became more aggrevated when cookies feature was added. In particular
> this issue is manifest when large cookie values are assigned to the
> actions and when enough actions are created that the resulting table
> must be dumped in multiple batches.
>
> The number of actions returned in each batch is limited by the total
> number of actions and the memory buffer size. With small cookies
> the numeric limit is reached before the buffer size limit, which avoids
> the code path triggering this bug. When large cookies are used buffer
> fills before the numeric limit, and the erroneous code path is hit.
>
> For example after creating 32 csum actions with the cookie
> aaaabbbbccccdddd
...
> Note that the action with index 27 is omitted from the report.
>
> Fixes: 4b3550ef530c ("[NET_SCHED]: Use nla_nest_start/nla_nest_end")"
> Signed-off-by: Craig Dillabaugh <cdillaba@mojatatu.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: RFC on writel and writel_relaxed
From: Jose Abreu @ 2018-03-27 15:01 UTC (permalink / raw)
To: Sinan Kaya, Benjamin Herrenschmidt, Arnd Bergmann,
Jason Gunthorpe
Cc: David Laight, Oliver,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
linux-rdma@vger.kernel.org, Alexander Duyck, Will Deacon,
Paul E. McKenney, netdev@vger.kernel.org, Alexander Duyck
In-Reply-To: <1e077f6a-90b6-cce9-6f0f-a8c003fec850@codeaurora.org>
Hi,
On 27-03-2018 15:46, Sinan Kaya wrote:
>
> Sinan
> "We are being told that if you use writel(), then you don't need a wmb() on
> all architectures."
>
> Alex:
> "I'm not sure who told you that but that is incorrect, at least for
> x86. If you attempt to use writel() without the wmb() we will have to
> NAK the patches. We will accept the wmb() with writel_releaxed() since
> that solves things for ARM."
>
So this means we should always use writel() + wmb() in *all*
accesses? I don't know about x86 but arc architecture doesn't
have a wmb() in the writel() function (in some configs).
I see the point in net drivers while you have dma + io accesses
but for most drivers this shouldn't be needed, right?
What about ordering of writes? Is it guaranteed that one write
will happen before the next one ?
Best Regards,
Jose Miguel Abreu
^ permalink raw reply
* [PATCH net-next 0/5] Make pernet_operations always read locked
From: Kirill Tkhai @ 2018-03-27 15:01 UTC (permalink / raw)
To: davem, ktkhai, nicolas.dichtel, vyasevic, paulmck, vyasevich,
mark.rutland, leonro, avagin, fw, ebiederm, roman.kapl, dsahern,
netdev, bfields
All the pernet_operations are converted, and the last one
is in this patchset (nfsd_net_ops acked by J. Bruce Fields).
So, it's the time to kill pernet_operations::async field,
and make setup_net() and cleanup_net() always require
the rwsem only read locked.
All further pernet_operations have to be developed to fit
this rule. Some of previous patches added a comment to
struct pernet_operations about that.
Also, this patchset renames net_sem to pernet_ops_rwsem
to make the target area of the rwsem is more clear visible,
and adds more comments.
Thanks,
Kirill
---
Kirill Tkhai (5):
net: Convert nfsd_net_ops
net: Reflect all pernet_operations are converted
net: Drop pernet_operations::async
net: Rename net_sem to pernet_ops_rwsem
net: Add more comments
drivers/infiniband/core/cma.c | 1
drivers/net/bonding/bond_main.c | 1
drivers/net/geneve.c | 1
drivers/net/gtp.c | 1
drivers/net/ipvlan/ipvlan_main.c | 1
drivers/net/loopback.c | 1
drivers/net/ppp/ppp_generic.c | 1
drivers/net/ppp/pppoe.c | 1
drivers/net/vrf.c | 1
drivers/net/vxlan.c | 1
drivers/net/wireless/mac80211_hwsim.c | 1
fs/lockd/svc.c | 1
fs/nfs/blocklayout/rpc_pipefs.c | 1
fs/nfs/dns_resolve.c | 1
fs/nfs/inode.c | 1
fs/nfs_common/grace.c | 1
fs/proc/proc_net.c | 1
include/linux/rtnetlink.h | 2 -
include/net/net_namespace.h | 22 +++----
kernel/audit.c | 1
lib/kobject_uevent.c | 1
net/8021q/vlan.c | 1
net/bridge/br.c | 1
net/bridge/br_netfilter_hooks.c | 1
net/bridge/netfilter/ebtable_broute.c | 1
net/bridge/netfilter/ebtable_filter.c | 1
net/bridge/netfilter/ebtable_nat.c | 1
net/bridge/netfilter/nf_log_bridge.c | 1
net/caif/caif_dev.c | 1
net/can/af_can.c | 1
net/can/bcm.c | 1
net/can/gw.c | 1
net/core/dev.c | 2 -
net/core/fib_notifier.c | 1
net/core/fib_rules.c | 1
net/core/net-procfs.c | 2 -
net/core/net_namespace.c | 77 +++++++-----------------
net/core/pktgen.c | 1
net/core/rtnetlink.c | 7 +-
net/core/sock.c | 2 -
net/core/sock_diag.c | 1
net/core/sysctl_net_core.c | 1
net/dccp/ipv4.c | 1
net/dccp/ipv6.c | 1
net/ieee802154/6lowpan/reassembly.c | 1
net/ieee802154/core.c | 1
net/ipv4/af_inet.c | 2 -
net/ipv4/arp.c | 1
net/ipv4/devinet.c | 1
net/ipv4/fib_frontend.c | 1
net/ipv4/fou.c | 1
net/ipv4/icmp.c | 1
net/ipv4/igmp.c | 1
net/ipv4/ip_fragment.c | 1
net/ipv4/ip_gre.c | 3 -
net/ipv4/ip_vti.c | 1
net/ipv4/ipip.c | 1
net/ipv4/ipmr.c | 1
net/ipv4/netfilter/arp_tables.c | 1
net/ipv4/netfilter/arptable_filter.c | 1
net/ipv4/netfilter/ip_tables.c | 1
net/ipv4/netfilter/ipt_CLUSTERIP.c | 1
net/ipv4/netfilter/iptable_filter.c | 1
net/ipv4/netfilter/iptable_mangle.c | 1
net/ipv4/netfilter/iptable_nat.c | 1
net/ipv4/netfilter/iptable_raw.c | 1
net/ipv4/netfilter/iptable_security.c | 1
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 1
net/ipv4/netfilter/nf_defrag_ipv4.c | 1
net/ipv4/netfilter/nf_log_arp.c | 1
net/ipv4/netfilter/nf_log_ipv4.c | 1
net/ipv4/ping.c | 1
net/ipv4/proc.c | 1
net/ipv4/raw.c | 1
net/ipv4/route.c | 4 -
net/ipv4/sysctl_net_ipv4.c | 1
net/ipv4/tcp_ipv4.c | 2 -
net/ipv4/tcp_metrics.c | 1
net/ipv4/udp.c | 2 -
net/ipv4/udplite.c | 1
net/ipv4/xfrm4_policy.c | 1
net/ipv6/addrconf.c | 2 -
net/ipv6/addrlabel.c | 1
net/ipv6/af_inet6.c | 1
net/ipv6/fib6_rules.c | 1
net/ipv6/icmp.c | 1
net/ipv6/ila/ila_xlat.c | 1
net/ipv6/ip6_fib.c | 1
net/ipv6/ip6_flowlabel.c | 1
net/ipv6/ip6_gre.c | 1
net/ipv6/ip6_tunnel.c | 1
net/ipv6/ip6_vti.c | 1
net/ipv6/ip6mr.c | 1
net/ipv6/mcast.c | 1
net/ipv6/ndisc.c | 1
net/ipv6/netfilter/ip6_tables.c | 1
net/ipv6/netfilter/ip6table_filter.c | 1
net/ipv6/netfilter/ip6table_mangle.c | 1
net/ipv6/netfilter/ip6table_nat.c | 1
net/ipv6/netfilter/ip6table_raw.c | 1
net/ipv6/netfilter/ip6table_security.c | 1
net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c | 1
net/ipv6/netfilter/nf_conntrack_reasm.c | 1
net/ipv6/netfilter/nf_defrag_ipv6_hooks.c | 1
net/ipv6/netfilter/nf_log_ipv6.c | 1
net/ipv6/ping.c | 1
net/ipv6/proc.c | 1
net/ipv6/raw.c | 1
net/ipv6/reassembly.c | 1
net/ipv6/route.c | 3 -
net/ipv6/seg6.c | 1
net/ipv6/sit.c | 1
net/ipv6/sysctl_net_ipv6.c | 1
net/ipv6/tcp_ipv6.c | 1
net/ipv6/udplite.c | 1
net/ipv6/xfrm6_policy.c | 1
net/ipv6/xfrm6_tunnel.c | 1
net/kcm/kcmproc.c | 1
net/kcm/kcmsock.c | 1
net/key/af_key.c | 1
net/l2tp/l2tp_core.c | 1
net/l2tp/l2tp_ppp.c | 1
net/mpls/af_mpls.c | 1
net/netfilter/core.c | 1
net/netfilter/ipset/ip_set_core.c | 1
net/netfilter/ipvs/ip_vs_core.c | 2 -
net/netfilter/ipvs/ip_vs_ftp.c | 1
net/netfilter/ipvs/ip_vs_lblc.c | 1
net/netfilter/ipvs/ip_vs_lblcr.c | 1
net/netfilter/nf_conntrack_netlink.c | 1
net/netfilter/nf_conntrack_proto_gre.c | 1
net/netfilter/nf_conntrack_standalone.c | 1
net/netfilter/nf_log.c | 1
net/netfilter/nf_log_netdev.c | 1
net/netfilter/nf_synproxy_core.c | 1
net/netfilter/nf_tables_api.c | 1
net/netfilter/nfnetlink.c | 1
net/netfilter/nfnetlink_acct.c | 1
net/netfilter/nfnetlink_cttimeout.c | 1
net/netfilter/nfnetlink_log.c | 1
net/netfilter/nfnetlink_queue.c | 1
net/netfilter/x_tables.c | 1
net/netfilter/xt_hashlimit.c | 1
net/netfilter/xt_recent.c | 1
net/netlink/af_netlink.c | 2 -
net/netlink/genetlink.c | 1
net/openvswitch/datapath.c | 1
net/packet/af_packet.c | 1
net/phonet/pn_dev.c | 1
net/rds/tcp.c | 1
net/rxrpc/net_ns.c | 1
net/sched/act_api.c | 1
net/sched/act_bpf.c | 1
net/sched/act_connmark.c | 1
net/sched/act_csum.c | 1
net/sched/act_gact.c | 1
net/sched/act_ife.c | 1
net/sched/act_ipt.c | 2 -
net/sched/act_mirred.c | 1
net/sched/act_nat.c | 1
net/sched/act_pedit.c | 1
net/sched/act_police.c | 1
net/sched/act_sample.c | 1
net/sched/act_simple.c | 1
net/sched/act_skbedit.c | 1
net/sched/act_skbmod.c | 1
net/sched/act_tunnel_key.c | 1
net/sched/act_vlan.c | 1
net/sched/cls_api.c | 1
net/sched/sch_api.c | 1
net/sctp/protocol.c | 2 -
net/sunrpc/auth_gss/auth_gss.c | 1
net/sunrpc/sunrpc_syms.c | 1
net/sysctl_net.c | 1
net/tipc/core.c | 1
net/unix/af_unix.c | 1
net/wireless/core.c | 1
net/wireless/wext-core.c | 1
net/xfrm/xfrm_policy.c | 1
net/xfrm/xfrm_user.c | 1
security/selinux/hooks.c | 1
security/smack/smack_netfilter.c | 1
182 files changed, 38 insertions(+), 266 deletions(-)
^ permalink raw reply
* [PATCH net-next 1/5] net: Convert nfsd_net_ops
From: Kirill Tkhai @ 2018-03-27 15:01 UTC (permalink / raw)
To: davem, ktkhai, nicolas.dichtel, vyasevic, paulmck, vyasevich,
mark.rutland, leonro, avagin, fw, ebiederm, roman.kapl, dsahern,
netdev, bfields
In-Reply-To: <152216238129.1634.4807322431520445566.stgit@localhost.localdomain>
These pernet_operations look similar to rpcsec_gss_net_ops,
they just create and destroy another caches. So, they also
can be async.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Acked-by: J. Bruce Fields <bfields@redhat.com>
---
fs/nfsd/nfsctl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
index d107b4426f7e..1e3824e6cce0 100644
--- a/fs/nfsd/nfsctl.c
+++ b/fs/nfsd/nfsctl.c
@@ -1263,6 +1263,7 @@ static struct pernet_operations nfsd_net_ops = {
.exit = nfsd_exit_net,
.id = &nfsd_net_id,
.size = sizeof(struct nfsd_net),
+ .async = true,
};
static int __init init_nfsd(void)
^ 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