* Re: RTL8723BE performance regression
From: Larry Finger @ 2018-04-04 2:51 UTC (permalink / raw)
To: João Paulo Rechi Vita
Cc: Yan-Hsuan Chuang, Ping-Ke Shih, Birming Chiu, Shaofu, Steven Ting,
Chaoming Li, Kalle Valo, linux-wireless, Network Development,
LKML, Daniel Drake, João Paulo Rechi Vita, linux
In-Reply-To: <CA+A7VXWjWaSSUiX3h_rpFXrSwtUkynKR9tpvnsSe=DZrC+mF-Q@mail.gmail.com>
On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
> (...)
>
>> As the antenna selection code changes affected your first bisection, do you
>> have one of those HP laptops with only one antenna and the incorrect coding
>> in the FUSE?
>
> Yes, that is why I've been passing ant_sel=1 during my tests -- this
> was needed to achieve a good performance in the past, before this
> regression. I've also opened the laptop chassis and confirmed the
> antenna cable is plugged to the connector labeled with "1" on the
> card.
>
>> If so, please make sure that you still have the same signal
>> strength for good and bad cases. I have tried to keep the driver and the
>> btcoex code in sync, but there may be some combinations of antenna
>> configuration and FUSE contents that cause the code to fail.
>>
>
> What is the recommended way to monitor the signal strength?
The btcoex code is developed for multiple platforms by a different group than
the Linux driver. I think they made a change that caused ant_sel to switch from
1 to 2. At least numerous comments at github.com/lwfinger/rtlwifi_new claimed
they needed to make that change.
Mhy recommended method is to verify the wifi device name with "iw dev". Then
using that device
sudo iw dev <dev_name> scan | egrep "SSID|signal"
Larry
^ permalink raw reply
* Re: [PATCH v15 ] net/veth/XDP: Line-rate packet forwarding in kernel
From: Md. Islam @ 2018-04-04 3:15 UTC (permalink / raw)
To: David Ahern
Cc: netdev, David Miller, Stephen Hemminger, Anton Gary Ceph,
Pavel Emelyanov, Eric Dumazet, alexei.starovoitov, brouer
In-Reply-To: <5395c7a0-2c1f-27f1-2490-dd4db68fbdc1@gmail.com>
On Tue, Apr 3, 2018 at 9:16 PM, David Ahern <dsahern@gmail.com> wrote:
> On 4/1/18 6:47 PM, Md. Islam wrote:
>> This patch implements IPv4 forwarding on xdp_buff. I added a new
>> config option XDP_ROUTER. Kernel would forward packets through fast
>> path when this option is enabled. But it would require driver support.
>> Currently it only works with veth. Here I have modified veth such that
>> it outputs xdp_buff. I created a testbed in Mininet. The Mininet
>> script (topology.py) is attached. Here the topology is:
>>
>> h1 -----r1-----h2 (r1 acts as a router)
>>
>> This patch improves the throughput from 53.8Gb/s to 60Gb/s on my
>> machine. Median RTT also improved from around .055 ms to around .035
>> ms.
>>
>> Then I disabled hyperthreading and cpu frequency scaling in order to
>> utilize CPU cache (DPDK also utilizes CPU cache to improve
>> forwarding). This further improves per-packet forwarding latency from
>> around 400ns to 200 ns. More specifically, header parsing and fib
>> lookup only takes around 82 ns. This shows that this could be used to
>> implement linerate packet forwarding in kernel.
>>
>> The patch has been generated on 4.15.0+. Please let me know your
>> feedback and suggestions. Please feel free to let me know if this
>> approach make sense.
>
> This patch is not really using eBPF and XDP but rather trying to
> shortcircuit forwarding through a veth pair.
>
> Have you looked at the loss in performance with this config enabled if
> there is no r1? i.e., h1 {veth1} <---> {veth2} / h2. You are adding a
> lookup per-packet to the Tx path.
Yes, it works. If there is no r1, it falls back to dev_forward_skb()
to forward the packet. My main objective here was to implement router
datapath. Personally I feel like it should be a part of kernel rather
than an eBPF. But still looking forward to your patch and performance
number.
>
> Have you looked at what I would consider a more interesting use case of
> packets into a node and delivered to a namespace via veth?
>
> +--------------------------+---------------
> | Host | container
> | |
> | +-------{ veth1 }-|-{veth2}----
> | | |
> +----{ eth1 }------------------
>
> Can xdp / bpf on eth1 be used to speed up delivery to the container?
I didn't consider that, but it sounds like an important use case. How
do we determine which namespace gets the packet?
^ permalink raw reply
* Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
From: Stuart Yoder @ 2018-04-04 3:22 UTC (permalink / raw)
To: Andrew Lunn
Cc: Arnd Bergmann, Ioana Ciornei, gregkh, Laurentiu Tudor,
Linux Kernel Mailing List, Ruxandra Ioana Ciocoi Radulescu,
Razvan Stefanescu, Roy Pledge, Networking
In-Reply-To: <20180404010549.GA12443@lunn.ch>
On Tue, Apr 3, 2018 at 8:05 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> Suppose you want to create and assign a network interface to a KVM
>> virtual machine, you would do something like the following using
>> a user space tool like restool:
>> -create a new (empty) dprc object
>> -create a new dpni and assign it to the dprc
>> -create a new dpio and assign it to the dprc
>> -create a new dpbp and assign it to the dprc
>> -create a new dpmcp and assign it to the dprc
>> -create a new dpmac and assign it to the dprc
>> -connect the dpni to the dpmac
>
> Hi Stuart
>
> It this connecting to a physical port at the bottom?
Yes.
> If so, i would expect that when you probe the device you just create
> all these for each physical port.
The problem is that there is not just one set of objects to implement a network
interface. For the highest throughput packet processing you need one dpio
per core. So, it will depend on what the requirements are. You might want
multiple dpbp (buffer pools) and set up pools of different size
buffers for different
packet classifications.
You might want to have other objects like a crypto accelerator (dpseci) in the
container as well.
The dprc is a container holding any combination of those objects. So you have
complete flexibility.
> You then just need to map one of
> them into the KVM, in the same way you map one PCI device into a KVM.
>
> If these are virtual devices, VF devices you would normally do
>
> echo 4 > /sys/class/net/<device name>/device/sriov_numvfs
>
> on the physical device to create virtual devices.
>
>> The fsl-mc bus and DPAA2 is very NXP-specific, so there doesn't
>> seem to be anything that can be made generic here to provide
>> more common benefit.
>
> Which is why you should try to avoid all of this. The user knows how
> to use standard linux commands and concepts. They don't want to have
> to learn the inside plumbing of your hardware.
I hear you. It is more complicated this way...having all these individual
objects vs just a single "bundle" of them that represents a NIC. But, that's
the way the DPAA2 hardware is, and we're implementing kernel support for
the hardware as it is.
Thanks,
Stuart
^ permalink raw reply
* Re: possible deadlock in skb_queue_tail
From: Cong Wang @ 2018-04-04 5:08 UTC (permalink / raw)
To: Kirill Tkhai
Cc: Dmitry Vyukov, Ingo Molnar, syzbot, David Miller, David Herrmann,
Denys Vlasenko, David Windsor, Reshetova, Elena, ishkamiel,
Kees Cook, LKML, matthew, Mateusz Jurczyk, netdev, syzkaller-bugs,
Al Viro, xemul
In-Reply-To: <0eb5ed24-012a-89c9-bac9-796a0276221a@virtuozzo.com>
On Tue, Apr 3, 2018 at 4:42 AM, Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
> On 03.04.2018 14:25, Dmitry Vyukov wrote:
>> On Tue, Apr 3, 2018 at 11:50 AM, Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
>>> sk_diag_dump_icons() dumps only sockets in TCP_LISTEN state.
>>> TCP_LISTEN state may be assigned in only place in net/unix/af_unix.c:
>>> it's unix_listen(). The function is applied to stream and seqpacket
>>> socket types.
>>>
>>> It can't be stream because of the second stack, and seqpacket also can't,
>>> as I don't think it's possible for gcc to inline unix_seqpacket_sendmsg()
>>> in the way, we don't see it in the stack.
>>>
>>> So, this is looks like false positive result for me.
>>>
>>> Kirill
>>
>> Do you mean that these &(&u->lock)->rlock/1 referenced in 2 stacks are
>> always different?
>
> In these 2 particular stacks they have to be different.
So actually my patch could fix this false positive? I thought it couldn't.
https://patchwork.ozlabs.org/patch/894342/
^ permalink raw reply
* Re: [PATCH iproute2 rdma: Ignore unknown netlink attributes
From: Leon Romanovsky @ 2018-04-04 5:42 UTC (permalink / raw)
To: Steve Wise
Cc: 'Stephen Hemminger', 'netdev',
'RDMA mailing list', 'David Ahern'
In-Reply-To: <016b01d3cb50$3adc88b0$b0959a10$@opengridcomputing.com>
[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]
On Tue, Apr 03, 2018 at 08:32:36AM -0500, Steve Wise wrote:
>
>
> > -----Original Message-----
> > From: Leon Romanovsky <leon@kernel.org>
> > Sent: Tuesday, April 3, 2018 2:29 AM
> > To: Stephen Hemminger <stephen@networkplumber.org>
> > Cc: Leon Romanovsky <leonro@mellanox.com>; netdev
> > <netdev@vger.kernel.org>; RDMA mailing list <linux-
> > rdma@vger.kernel.org>; David Ahern <dsahern@gmail.com>; Steve Wise
> > <swise@opengridcomputing.com>
> > Subject: [PATCH iproute2 rdma: Ignore unknown netlink attributes
> >
> > From: Leon Romanovsky <leonro@mellanox.com>
> >
> > The check if netlink attributes supplied more than maximum supported
> > is to strict and may lead to backward compatibility issues with old
> > application with a newer kernel that supports new attribute.
> >
> > CC: Steve Wise <swise@opengridcomputing.com>
> > Fixes: 74bd75c2b68d ("rdma: Add basic infrastructure for RDMA tool")
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > ---
> > rdma/utils.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/rdma/utils.c b/rdma/utils.c
> > index a2e08e91..5c1e736a 100644
> > --- a/rdma/utils.c
> > +++ b/rdma/utils.c
> > @@ -399,7 +399,8 @@ int rd_attr_cb(const struct nlattr *attr, void *data)
> > int type;
> >
> > if (mnl_attr_type_valid(attr, RDMA_NLDEV_ATTR_MAX) < 0)
> > - return MNL_CB_ERROR;
> > + /* We received uknown attribute */
> > + return MNL_CB_OK;
> >
> > type = mnl_attr_get_type(attr);
> >
>
> Hey Leon,
>
> So the resource parsing functions correctly ignore the unkown attrs and
> print everything else?
Yes.
>
> Looks good.
>
> Reviewed-by: Steve Wise <swise@opengridcomputing.com>
>
Thanks a lot.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v15 ] net/veth/XDP: Line-rate packet forwarding in kernel
From: Jesper Dangaard Brouer @ 2018-04-04 6:16 UTC (permalink / raw)
To: Md. Islam
Cc: netdev, David Miller, David Ahern, stephen, agaceph,
Pavel Emelyanov, Eric Dumazet, alexei.starovoitov, brouer
In-Reply-To: <CAFgPn1DX9cOpDRGj=wFwvZq_bpq6VFnEOzR1YbMuC0+=DFEWxA@mail.gmail.com>
On Sun, 1 Apr 2018 20:47:28 -0400 Md. Islam" <mislam4@kent.edu> wrote:
> [...] More specifically, header parsing and fib
> lookup only takes around 82 ns. This shows that this could be used to
> implement linerate packet forwarding in kernel.
I cannot resist correcting you...
You didn't specify the link speed, but assuming 10Gbit/s, then the
linerate is 14.88Mpps, which is 67.2 ns between arriving packets. Thus,
if the lookup cost is 82 ns, thus you cannot claim linerate performance
with these numbers.
Details:
This is calculated based on the the minimum Ethernet frame size
84-bytes, see https://en.wikipedia.org/wiki/Ethernet_frame for why this
is the minimum size.
10*10^9/(84*8) = 14,880,952 pps
1/last*10^9 = 67.2 ns
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
From: Jiri Pirko @ 2018-04-04 6:19 UTC (permalink / raw)
To: David Ahern
Cc: Si-Wei Liu, mst, stephen, alexander.h.duyck, davem,
jesse.brandeburg, kubakici, jasowang, sridhar.samudrala, netdev,
virtualization, virtio-dev
In-Reply-To: <3bdfc39f-4935-2433-7982-9ce28c3aa166@gmail.com>
Wed, Apr 04, 2018 at 03:04:26AM CEST, dsahern@gmail.com wrote:
>On 4/3/18 9:42 AM, Jiri Pirko wrote:
>>>
>>> There are other use cases that want to hide a device from userspace. I
>>
>> What usecases do you have in mind?
>
>As mentioned in a previous response some kernel drivers create control
>netdevs. Just as in this case users should not be mucking with it, and
virtio_net. Any other drivers?
>S/W like lldpd should ignore it.
It's just a matter of identification of the netdevs, so the user knows
what to do.
>
>>
>>> would prefer a better solution than playing games with name prefixes and
>>> one that includes an API for users to list all devices -- even ones
>>> hidden by default.
>>
>> Netdevice hiding feels a bit scarry for me. This smells like a workaround
>> for userspace issues. Why can't the netdevice be visible always and
>> userspace would know what is it and what should it do with it?
>>
>> Once we start with hiding, there are other things related to that which
>> appear. Like who can see what, levels of visibility etc...
>>
>
>I would not advocate for any API that does not allow users to have full
>introspection. The intent is to hide the netdev by default but have an
>option to see it.
As an administrator, I want to see all by default. I think it is
reasonable requirements. Again, this awfully smells like a workaround...
^ permalink raw reply
* Re: [PATCH net-next 09/11] devlink: convert occ_get op to separate registration
From: Jiri Pirko @ 2018-04-04 6:25 UTC (permalink / raw)
To: David Ahern; +Cc: Ido Schimmel, netdev, davem, jiri, petrm, mlxsw
In-Reply-To: <289e6c36-5e8d-139a-9fa4-575cf9fe86a1@gmail.com>
Wed, Apr 04, 2018 at 02:47:19AM CEST, dsahern@gmail.com wrote:
>On 4/3/18 9:30 AM, Jiri Pirko wrote:
>> Tue, Apr 03, 2018 at 04:33:11PM CEST, dsahern@gmail.com wrote:
>>> On 4/3/18 1:32 AM, Jiri Pirko wrote:
>>>> Fri, Mar 30, 2018 at 04:45:50PM CEST, dsahern@gmail.com wrote:
>>>>> On 3/29/18 2:33 PM, Ido Schimmel wrote:
>>>>>> From: Jiri Pirko <jiri@mellanox.com>
>>>>>>
>>>>>> This resolves race during initialization where the resources with
>>>>>> ops are registered before driver and the structures used by occ_get
>>>>>> op is initialized. So keep occ_get callbacks registered only when
>>>>>> all structs are initialized.
>>>>>
>>>>> Why can't the occ_get handler look at some flag in an mlxsw struct to
>>>>> know if the system has initialized?
>>>>>
>>>>> Separate registration here is awkward. You register a resource and then
>>>>> register its op later.
>>>>
>>>> The separation is exactly why this patch is made. Note that devlink
>>>> resouce is registered by core way before the initialization is done and
>>>> the driver is actually able to perform the op. Also consider "reload"
>>>
>>> That's how you have chose to code it. I hit this problem adding devlink
>>> to netdevsim; the solution was to fix the init order.
>>
>> This is not about init order, at all. On reaload netdevs and internal
>> driver structures disappear and appear again. And in between currently,
>> the op is working with memory which is freed. That's the reason for this
>> patch.
>>
>>
>>>
>>>> case, when the resource is still registered and the driver unloads and
>>>> loads again. For that makes perfect sense to have that separated.
>>>> Flag would just make things odd. Also, the priv could not be used in
>>>> that case.
>>>>
>>>
>>> I am not aware of any other API where you invoked the register function
>>> at point A and then later add the operations at point B. In every API
>>> that comes to mind the ops are part of the register.
>>
>> I think that you just don't see any similar API.
>>
>>
>>>
>>> I am sure there are options for you to fix the init order of mlxsw
>>> without making the devlink API awkward.
>>
>> Again, not about init order, at all. I have no clue why you think so...
>>
>
>Jiri, I am not aware of any other API where a driver registers with it
>yet doesn't want the handler to be called so either waits to register
Again, the thing is, this is kind of unusual because of the reload
thing. There is one instance registering the resources, another instance
fills up the ops. I spent some time to think this through, I did not
find the other good solution (all are more or less ugly).
>the handler later or unregisters the handler. That is an awkward design.
>There are other options to have a sane API and handle the conditions you
>need.
Also, this is in-kernel API so it is not set in stone and can be very
easily changed whenever we need to. Not sure why you are trying to be so
strict about this...
Okay, please propose some solution you consider "not awkward". Thanks!
^ permalink raw reply
* Re: [PATCH v2] net: thunderx: nicvf_main: Fix potential NULL pointer dereferences
From: Eric Dumazet @ 2018-04-04 6:36 UTC (permalink / raw)
To: Gustavo A. R. Silva, Sunil Goutham, Robert Richter
Cc: linux-arm-kernel, netdev, linux-kernel
In-Reply-To: <20180403220423.GA718@embeddedor.com>
On 04/03/2018 03:04 PM, Gustavo A. R. Silva wrote:
> Add null check on kmalloc() return value in order to prevent
> a null pointer dereference.
>
> Addresses-Coverity-ID: 1467429 ("Dereference null return value")
> Fixes: 37c3347eb247 ("net: thunderx: add ndo_set_rx_mode callback implementation for VF")
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
> Changes in v2:
> - Add a null check on a second kmalloc a few lines below. Thanks to
> Eric Dumazet for pointing this out.
>
> drivers/net/ethernet/cavium/thunder/nicvf_main.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> index 1e9a31f..f7b5ca5 100644
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> @@ -1999,10 +1999,14 @@ static void nicvf_set_rx_mode(struct net_device *netdev)
> struct xcast_addr *xaddr;
>
> mc_list = kmalloc(sizeof(*mc_list), GFP_ATOMIC);
> + if (unlikely(!mc_list))
> + return;
> INIT_LIST_HEAD(&mc_list->list);
> netdev_hw_addr_list_for_each(ha, &netdev->mc) {
> xaddr = kmalloc(sizeof(*xaddr),
> GFP_ATOMIC);
> + if (unlikely(!xaddr))
> + return;
So now you leak memory :/
If you fix bugs, please do not add new ones.
> xaddr->addr =
> ether_addr_to_u64(ha->addr);
> list_add_tail(&xaddr->list,
>
^ permalink raw reply
* Re: [PATCH v2] net: thunderx: nicvf_main: Fix potential NULL pointer dereferences
From: Gustavo A. R. Silva @ 2018-04-04 6:41 UTC (permalink / raw)
To: Eric Dumazet, Sunil Goutham, Robert Richter
Cc: linux-arm-kernel, netdev, linux-kernel
In-Reply-To: <6aa876e8-c94c-1ab8-2a3a-02b2b77df65f@gmail.com>
On 04/04/2018 01:36 AM, Eric Dumazet wrote:
>
>
> On 04/03/2018 03:04 PM, Gustavo A. R. Silva wrote:
>> Add null check on kmalloc() return value in order to prevent
>> a null pointer dereference.
>>
>> Addresses-Coverity-ID: 1467429 ("Dereference null return value")
>> Fixes: 37c3347eb247 ("net: thunderx: add ndo_set_rx_mode callback implementation for VF")
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>> ---
>> Changes in v2:
>> - Add a null check on a second kmalloc a few lines below. Thanks to
>> Eric Dumazet for pointing this out.
>>
>> drivers/net/ethernet/cavium/thunder/nicvf_main.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
>> index 1e9a31f..f7b5ca5 100644
>> --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
>> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
>> @@ -1999,10 +1999,14 @@ static void nicvf_set_rx_mode(struct net_device *netdev)
>> struct xcast_addr *xaddr;
>>
>> mc_list = kmalloc(sizeof(*mc_list), GFP_ATOMIC);
>> + if (unlikely(!mc_list))
>> + return;
>> INIT_LIST_HEAD(&mc_list->list);
>> netdev_hw_addr_list_for_each(ha, &netdev->mc) {
>> xaddr = kmalloc(sizeof(*xaddr),
>> GFP_ATOMIC);
>> + if (unlikely(!xaddr))
>> + return;
>
> So now you leak memory :/
>
Oh god. I'm sorry.
I had problems with this file since the beginning.
I'll send v3 shortly.
Thanks
--
Gustavo
^ permalink raw reply
* Re: [PATCH net-next 02/12] clk: sunxi-ng: r40: export a regmap to access the GMAC register
From: Icenowy Zheng @ 2018-04-04 6:45 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai
Cc: Mark Rutland, devicetree, Stephen Boyd, netdev, Michael Turquette,
Rob Herring, Corentin Labbe, Mark Brown, Giuseppe Cavallaro,
linux-clk, linux-arm-kernel
In-Reply-To: <20180403095005.skflxb7m2qzbhjix@flea>
在 2018-04-03二的 11:50 +0200，Maxime Ripard写道：
> On Tue, Apr 03, 2018 at 11:48:45AM +0200, Maxime Ripard wrote:
> > On Tue, Mar 20, 2018 at 03:15:02PM +0800, Chen-Yu Tsai wrote:
> > > On Mon, Mar 19, 2018 at 5:31 AM, Maxime Ripard
> > > <maxime.ripard@bootlin.com> wrote:
> > > > On Sat, Mar 17, 2018 at 05:28:47PM +0800, Chen-Yu Tsai wrote:
> > > > > From: Icenowy Zheng <icenowy@aosc.io>
> > > > >
> > > > > There's a GMAC configuration register, which exists on
> > > > > A64/A83T/H3/H5 in
> > > > > the syscon part, in the CCU of R40 SoC.
> > > > >
> > > > > Export a regmap of the CCU.
> > > > >
> > > > > Read access is not restricted to all registers, but only the
> > > > > GMAC
> > > > > register is allowed to be written.
> > > > >
> > > > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > > > > Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> > > >
> > > > Gah, this is crazy. I'm really starting to regret letting that
> > > > syscon
> > > > in in the first place...
> > >
> > > IMHO syscon is really a better fit. It's part of the glue layer
> > > and
> > > most other dwmac user platforms treat it as such and use a
> > > syscon.
> > > Plus the controls encompass delays (phase), inverters (polarity),
> > > and even signal routing. It's not really just a group of clock
> > > controls,
> > > like what we poorly modeled for A20/A31. I think that was really
> > > a
> > > mistake.
> > >
> > > As I mentioned in the cover letter, a slightly saner approach
> > > would
> > > be to let drivers add custom syscon entries, which would then
> > > require
> > > less custom plumbing.
> >
> > A syscon is convenient, sure, but it also bypasses any abstraction
> > layer we have everywhere else, which means that we'll have to
> > maintain
> > the register layout in each and every driver that uses it.
> >
> > So far, it's only be the GMAC, but it can also be others (the SRAM
> > controller comes to my mind), and then, if there's any difference
> > in
> > the design in a future SoC, we'll have to maintain that in the GMAC
> > driver as well.
>
> I guess I forgot to say something, I'm fine with using a syscon we
> already have.
As we finally need the SRAM controller on these new SoCs (for VE on all
SoCs targeted by dwmac-sun8i, and for DE on A64), should we deprecate
the syscon and all switch to device regmap (and let sunxi-dram driver
to export a regmap)? (As in the A64 DE2 thread discussed, two device
nodes shouldn't cover the same MMIO region.)
In addition, there might be multiple registers in the syscon/sram zone
that are needed (for example, if a version driver is written, it will
need the "0x24 Version Register"; and GMAC needs "0x30 EMAC Clock
Register"). How to deal with this if we export the syscon/sram zone as
a generic device regmap?
>
> I'm just questionning if merging any other driver using one is the
> right move.
>
> Maxime
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next 02/12] clk: sunxi-ng: r40: export a regmap to access the GMAC register
From: Chen-Yu Tsai @ 2018-04-04 7:00 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Maxime Ripard, Mark Rutland, devicetree, Stephen Boyd, netdev,
Michael Turquette, Rob Herring, Corentin Labbe, Mark Brown,
Giuseppe Cavallaro, linux-clk, linux-arm-kernel
In-Reply-To: <1522824302.2049.7.camel@aosc.io>
On Wed, Apr 4, 2018 at 2:45 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> 在 2018-04-03二的 11:50 +0200，Maxime Ripard写道：
>> On Tue, Apr 03, 2018 at 11:48:45AM +0200, Maxime Ripard wrote:
>> > On Tue, Mar 20, 2018 at 03:15:02PM +0800, Chen-Yu Tsai wrote:
>> > > On Mon, Mar 19, 2018 at 5:31 AM, Maxime Ripard
>> > > <maxime.ripard@bootlin.com> wrote:
>> > > > On Sat, Mar 17, 2018 at 05:28:47PM +0800, Chen-Yu Tsai wrote:
>> > > > > From: Icenowy Zheng <icenowy@aosc.io>
>> > > > >
>> > > > > There's a GMAC configuration register, which exists on
>> > > > > A64/A83T/H3/H5 in
>> > > > > the syscon part, in the CCU of R40 SoC.
>> > > > >
>> > > > > Export a regmap of the CCU.
>> > > > >
>> > > > > Read access is not restricted to all registers, but only the
>> > > > > GMAC
>> > > > > register is allowed to be written.
>> > > > >
>> > > > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> > > > > Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> > > >
>> > > > Gah, this is crazy. I'm really starting to regret letting that
>> > > > syscon
>> > > > in in the first place...
>> > >
>> > > IMHO syscon is really a better fit. It's part of the glue layer
>> > > and
>> > > most other dwmac user platforms treat it as such and use a
>> > > syscon.
>> > > Plus the controls encompass delays (phase), inverters (polarity),
>> > > and even signal routing. It's not really just a group of clock
>> > > controls,
>> > > like what we poorly modeled for A20/A31. I think that was really
>> > > a
>> > > mistake.
>> > >
>> > > As I mentioned in the cover letter, a slightly saner approach
>> > > would
>> > > be to let drivers add custom syscon entries, which would then
>> > > require
>> > > less custom plumbing.
>> >
>> > A syscon is convenient, sure, but it also bypasses any abstraction
>> > layer we have everywhere else, which means that we'll have to
>> > maintain
>> > the register layout in each and every driver that uses it.
>> >
>> > So far, it's only be the GMAC, but it can also be others (the SRAM
>> > controller comes to my mind), and then, if there's any difference
>> > in
>> > the design in a future SoC, we'll have to maintain that in the GMAC
>> > driver as well.
>>
>> I guess I forgot to say something, I'm fine with using a syscon we
>> already have.
>
> As we finally need the SRAM controller on these new SoCs (for VE on all
> SoCs targeted by dwmac-sun8i, and for DE on A64), should we deprecate
> the syscon and all switch to device regmap (and let sunxi-dram driver
> to export a regmap)? (As in the A64 DE2 thread discussed, two device
> nodes shouldn't cover the same MMIO region.)
Sounds like a plan.
> In addition, there might be multiple registers in the syscon/sram zone
> that are needed (for example, if a version driver is written, it will
> need the "0x24 Version Register"; and GMAC needs "0x30 EMAC Clock
> Register"). How to deal with this if we export the syscon/sram zone as
> a generic device regmap?
You can have multiple regmaps for a device. And the API allows you to
request them up by name.
ChenYu
>>
>> I'm just questionning if merging any other driver using one is the
>> right move.
>>
>> Maxime
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Build failure due commit 9217e566bdee
From: Jarkko Nikula @ 2018-04-04 7:22 UTC (permalink / raw)
To: Mike Looijmans
Cc: linux-kernel, netdev, Andrew Lunn, Florian Fainelli,
David S. Miller
Hi
Today's head and linux-next doesn't compile due commit 9217e566bdee
("of_net: Implement of_get_nvmem_mac_address helper"):
drivers/of/of_net.o: In function `of_get_nvmem_mac_address':
.../drivers/of/of_net.c:100: undefined reference to `of_nvmem_cell_get'
.../drivers/of/of_net.c:104: undefined reference to `nvmem_cell_read'
.../drivers/of/of_net.c:106: undefined reference to `nvmem_cell_put'
Makefile:1033: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1
Builds if I set CONFIG_NVMEM=y from CONFIG_NVMEM=m or revert above commit.
--
Jarkko
^ permalink raw reply
* Re: [RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
From: Siwei Liu @ 2018-04-04 7:36 UTC (permalink / raw)
To: David Ahern
Cc: Jiri Pirko, Si-Wei Liu, Michael S. Tsirkin, Stephen Hemminger,
Alexander Duyck, David Miller, Brandeburg, Jesse, Jakub Kicinski,
Jason Wang, Samudrala, Sridhar, Netdev, virtualization,
virtio-dev
In-Reply-To: <3bdfc39f-4935-2433-7982-9ce28c3aa166@gmail.com>
On Tue, Apr 3, 2018 at 6:04 PM, David Ahern <dsahern@gmail.com> wrote:
> On 4/3/18 9:42 AM, Jiri Pirko wrote:
>>>
>>> There are other use cases that want to hide a device from userspace. I
>>
>> What usecases do you have in mind?
>
> As mentioned in a previous response some kernel drivers create control
> netdevs. Just as in this case users should not be mucking with it, and
> S/W like lldpd should ignore it.
>
>>
>>> would prefer a better solution than playing games with name prefixes and
>>> one that includes an API for users to list all devices -- even ones
>>> hidden by default.
>>
>> Netdevice hiding feels a bit scarry for me. This smells like a workaround
>> for userspace issues. Why can't the netdevice be visible always and
>> userspace would know what is it and what should it do with it?
>>
>> Once we start with hiding, there are other things related to that which
>> appear. Like who can see what, levels of visibility etc...
>>
>
> I would not advocate for any API that does not allow users to have full
> introspection. The intent is to hide the netdev by default but have an
> option to see it.
I'm fine with having a link dump API to inspect the hidden netdev. As
said, the name for hidden netdevs should be in a separate device
namespace, and we did not even get closer to what it should look like
as I don't want to make it just an option for ip link. Perhaps a new
set of sub-commands of, say, 'ip device'.
-Siwei
^ permalink raw reply
* Re: Build failure due commit 9217e566bdee
From: Mike Looijmans @ 2018-04-04 8:00 UTC (permalink / raw)
To: Jarkko Nikula
Cc: linux-kernel, netdev, Andrew Lunn, Florian Fainelli,
David S. Miller
In-Reply-To: <76f98816-9f0a-3eb7-e00e-82cf5935afd6@linux.intel.com>
On 04-04-18 09:22, Jarkko Nikula wrote:
> Hi
>
> Today's head and linux-next doesn't compile due commit 9217e566bdee ("of_net:
> Implement of_get_nvmem_mac_address helper"):
>
> drivers/of/of_net.o: In function `of_get_nvmem_mac_address':
> .../drivers/of/of_net.c:100: undefined reference to `of_nvmem_cell_get'
> .../drivers/of/of_net.c:104: undefined reference to `nvmem_cell_read'
> .../drivers/of/of_net.c:106: undefined reference to `nvmem_cell_put'
> Makefile:1033: recipe for target 'vmlinux' failed
> make: *** [vmlinux] Error 1
>
> Builds if I set CONFIG_NVMEM=y from CONFIG_NVMEM=m or revert above commit.
>
I've been looking into it, but haven't come up with a proper solution.
The issue is that OF_NET now requires NVMEM as either not-present or built-in,
but cannot support it as module.
I don't know if that requirement can be expressed. I think having nvnmem_core
as a module doesn't make much sense anyway, but that's not up to me.
Moving the code from of to nvmem seems weird, but would solve it.
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
^ permalink raw reply
* Re: [RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
From: Siwei Liu @ 2018-04-04 8:01 UTC (permalink / raw)
To: Jiri Pirko
Cc: David Ahern, Si-Wei Liu, Michael S. Tsirkin, Stephen Hemminger,
Alexander Duyck, David Miller, Brandeburg, Jesse, Jakub Kicinski,
Jason Wang, Samudrala, Sridhar, Netdev, virtualization,
virtio-dev
In-Reply-To: <20180404061945.GN3313@nanopsycho>
On Tue, Apr 3, 2018 at 11:19 PM, Jiri Pirko <jiri@resnulli.us> wrote:
> Wed, Apr 04, 2018 at 03:04:26AM CEST, dsahern@gmail.com wrote:
>>On 4/3/18 9:42 AM, Jiri Pirko wrote:
>>>>
>>>> There are other use cases that want to hide a device from userspace. I
>>>
>>> What usecases do you have in mind?
>>
>>As mentioned in a previous response some kernel drivers create control
>>netdevs. Just as in this case users should not be mucking with it, and
>
> virtio_net. Any other drivers?
netvsc if factoring out virtio_bypass to a common driver.
>
>
>>S/W like lldpd should ignore it.
>
> It's just a matter of identification of the netdevs, so the user knows
> what to do.
>
>
>>
>>>
>>>> would prefer a better solution than playing games with name prefixes and
>>>> one that includes an API for users to list all devices -- even ones
>>>> hidden by default.
>>>
>>> Netdevice hiding feels a bit scarry for me. This smells like a workaround
>>> for userspace issues. Why can't the netdevice be visible always and
>>> userspace would know what is it and what should it do with it?
>>>
>>> Once we start with hiding, there are other things related to that which
>>> appear. Like who can see what, levels of visibility etc...
>>>
>>
>>I would not advocate for any API that does not allow users to have full
>>introspection. The intent is to hide the netdev by default but have an
>>option to see it.
>
> As an administrator, I want to see all by default. I think it is
> reasonable requirements. Again, this awfully smells like a workaround...
If the requirement is just for dumping the link info i.e. perform
read-only operation on the hidden netdev, it's completely fine.
However, I am not a big fan of creating a weird mechanism to allow
user deliberately manipulate the visibility (hide/unhide) of a netdev
in any case at any time. This is subject to becoming a slippery slope
to work around any software issue that should get fixed in the right
place.
Let's treat IFF_HIDDEN as a means to hide auto-managed netdevices. If
it's just the name is misleading, I can get it renamed to something
like IFF_AUTO_MANAGED which might reflect its nature more properly.
Thanks,
-Siwei
^ permalink raw reply
* Re: [virtio-dev] Re: [RFC PATCH 1/3] qemu: virtio-bypass should explicitly bind to a passthrough device
From: Siwei Liu @ 2018-04-04 8:02 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Si-Wei Liu, Jiri Pirko, Stephen Hemminger, Alexander Duyck,
David Miller, Brandeburg, Jesse, Jakub Kicinski, Jason Wang,
Samudrala, Sridhar, Netdev, virtualization, virtio-dev
In-Reply-To: <20180403152308-mutt-send-email-mst@kernel.org>
On Tue, Apr 3, 2018 at 5:25 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Sun, Apr 01, 2018 at 05:13:08AM -0400, Si-Wei Liu wrote:
>> @@ -896,6 +898,68 @@ void qmp_device_del(const char *id, Error **errp)
>> }
>> }
>>
>> +int pci_get_busdevfn_by_id(const char *id, uint16_t *busnr,
>> + uint16_t *devfn, Error **errp)
>> +{
>> + uint16_t busnum = 0, slot = 0, func = 0;
>> + const char *pc, *pd, *pe;
>> + Error *local_err = NULL;
>> + ObjectClass *class;
>> + char value[1024];
>> + BusState *bus;
>> + uint64_t u64;
>> +
>> + if (!(pc = strchr(id, ':'))) {
>> + error_setg(errp, "Invalid id: backup=%s, "
>> + "correct format should be backup="
>> + "'<bus-id>:<slot>[.<function>]'", id);
>> + return -1;
>> + }
>> + get_opt_name(value, sizeof(value), id, ':');
>> + if (pc != id + 1) {
>> + bus = qbus_find(value, errp);
>> + if (!bus)
>> + return -1;
>> +
>> + class = object_get_class(OBJECT(bus));
>> + if (class != object_class_by_name(TYPE_PCI_BUS) &&
>> + class != object_class_by_name(TYPE_PCIE_BUS)) {
>> + error_setg(errp, "%s is not a device on pci bus", id);
>> + return -1;
>> + }
>> + busnum = (uint16_t)pci_bus_num(PCI_BUS(bus));
>> + }
>
> pci_bus_num is almost always a bug if not done within
> a context of a PCI host, bridge, etc.
>
> In particular this will not DTRT if run before guest assigns bus
> numbers.
>
I was seeking means to reserve a specific pci bus slot from drivers,
and update the driver when guest assigns the bus number but it seems
there's no low-hanging fruits. Because of that reason the bus_num is
only obtained until it's really needed (during get_config) and I
assume at that point the pci bus assignment is already done. I know
the current one is not perfect, but we need that information (PCI
bus:slot.func number) to name the guest device correctly.
Regards,
-Siwei
>
>> +
>> + if (!devfn)
>> + goto out;
>> +
>> + pd = strchr(pc, '.');
>> + pe = get_opt_name(value, sizeof(value), pc + 1, '.');
>> + if (pe != pc + 1) {
>> + parse_option_number("slot", value, &u64, &local_err);
>> + if (local_err) {
>> + error_propagate(errp, local_err);
>> + return -1;
>> + }
>> + slot = (uint16_t)u64;
>> + }
>> + if (pd && *(pd + 1) != '\0') {
>> + parse_option_number("function", pd, &u64, &local_err);
>> + if (local_err) {
>> + error_propagate(errp, local_err);
>> + return -1;
>> + }
>> + func = (uint16_t)u64;
>> + }
>> +
>> +out:
>> + if (busnr)
>> + *busnr = busnum;
>> + if (devfn)
>> + *devfn = ((slot & 0x1F) << 3) | (func & 0x7);
>> + return 0;
>> +}
>> +
>> BlockBackend *blk_by_qdev_id(const char *id, Error **errp)
>> {
>> DeviceState *dev;
>> --
>> 1.8.3.1
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
^ permalink raw reply
* Re: [virtio-dev] Re: [RFC PATCH 3/3] virtio_net: make lower netdevs for virtio_bypass hidden
From: Siwei Liu @ 2018-04-04 8:03 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Si-Wei Liu, Jiri Pirko, Stephen Hemminger, Alexander Duyck,
David Miller, Brandeburg, Jesse, Jakub Kicinski, Jason Wang,
Samudrala, Sridhar, Netdev, virtualization, virtio-dev
In-Reply-To: <20180403151915-mutt-send-email-mst@kernel.org>
On Tue, Apr 3, 2018 at 5:20 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Sun, Apr 01, 2018 at 05:13:10AM -0400, Si-Wei Liu wrote:
>> diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
>> index aa40664..0827b7e 100644
>> --- a/include/uapi/linux/virtio_net.h
>> +++ b/include/uapi/linux/virtio_net.h
>> @@ -80,6 +80,8 @@ struct virtio_net_config {
>> __u16 max_virtqueue_pairs;
>> /* Default maximum transmit unit advice */
>> __u16 mtu;
>> + /* Device at bus:slot.function backed up by virtio_net */
>> + __u16 bsf2backup;
>> } __attribute__((packed));
>
> I'm not sure this is a good interface. This isn't unique even on some
> PCI systems, not to speak of non-PCI ones.
Are you suggesting adding PCI address domain besides to make it
universally unique? And what the non-PCI device you envisioned that
the main target, essetially live migration, can/should cover? Or is
there better option in your mind already?
Thanks,
-Siwei
>
>> /*
>> --
>> 1.8.3.1
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
^ permalink raw reply
* Re: [RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
From: Siwei Liu @ 2018-04-04 8:28 UTC (permalink / raw)
To: David Ahern
Cc: Jiri Pirko, Si-Wei Liu, Michael S. Tsirkin, Stephen Hemminger,
Alexander Duyck, David Miller, Brandeburg, Jesse, Jakub Kicinski,
Jason Wang, Samudrala, Sridhar, Netdev, virtualization,
virtio-dev
In-Reply-To: <3bdfc39f-4935-2433-7982-9ce28c3aa166@gmail.com>
On Tue, Apr 3, 2018 at 6:04 PM, David Ahern <dsahern@gmail.com> wrote:
> On 4/3/18 9:42 AM, Jiri Pirko wrote:
>>>
>>> There are other use cases that want to hide a device from userspace. I
>>
>> What usecases do you have in mind?
>
> As mentioned in a previous response some kernel drivers create control
> netdevs. Just as in this case users should not be mucking with it, and
> S/W like lldpd should ignore it.
I'm still not sure I understand your case: why you want to hide the
control netdev, as I assume those devices could choose either to
silently ignore the request, or fail loudly against user operations?
Is it creating issues already, or what problem you want to solve if
not making the netdev invisible. Why couldn't lldpd check some
specific flag and ignore the control netdevice (can you please give an
example of a concrete driver for control netdevice *in tree*).
And I'm completely lost why you want an API to make a hidden netdev
visible again for these control devices.
Thanks,
-Siwei
>
>>
>>> would prefer a better solution than playing games with name prefixes and
>>> one that includes an API for users to list all devices -- even ones
>>> hidden by default.
>>
>> Netdevice hiding feels a bit scarry for me. This smells like a workaround
>> for userspace issues. Why can't the netdevice be visible always and
>> userspace would know what is it and what should it do with it?
>>
>> Once we start with hiding, there are other things related to that which
>> appear. Like who can see what, levels of visibility etc...
>>
>
> I would not advocate for any API that does not allow users to have full
> introspection. The intent is to hide the netdev by default but have an
> option to see it.
^ permalink raw reply
* Re: [net-next V9 PATCH 00/16] XDP redirect memory return API
From: Daniel Borkmann @ 2018-04-04 8:41 UTC (permalink / raw)
To: Saeed Mahameed, David Miller
Cc: Jesper Dangaard Brouer, Linux Netdev List, bjorn.topel,
magnus.karlsson, Eugenia Emantayev, jasowang, John Fastabend,
Eran Ben Elisha, Saeed Mahameed, Gal Pressman, Daniel Borkmann,
Alexei Starovoitov, Tariq Toukan
In-Reply-To: <CALzJLG8bbMnBWvnKP-OvhZ2NF2=KzHVqyuiepnsJRQEMv86_JQ@mail.gmail.com>
On 04/03/2018 07:03 PM, Saeed Mahameed wrote:
> On Tue, Apr 3, 2018 at 9:23 AM, David Miller <davem@davemloft.net> wrote:
>> From: Jesper Dangaard Brouer <brouer@redhat.com>
>> Date: Tue, 3 Apr 2018 18:07:16 +0200
>>> On Tue, 03 Apr 2018 10:54:27 -0400 (EDT)
>>> David Miller <davem@davemloft.net> wrote:
>>>
>>>> Don't worry, just resubmit when net-next opens back up.
>>>
>>> At that point in time, should I got back to posting it against the
>>> bpf-next git-tree again? Any preferences from Mellanox or BPF-guys?
>>
>> I have no personal preference, although it's probably best to go
>> through the bpf-next tree.
I'm fine either way as well.
>>> ... It have been a bit of a pain to keep track of driver changes in
>>> net-next, and waiting for them to get merged into bpf-next.
>>
>> I totally understand :)
>
> it depends on how often bpf-next gets synced with net-next, mlx5
> constantly changes and
> I can't gurantee no merge conflicts will occur.
We push out bpf and bpf-next typically once a week to sync, but in case
of potential merge conflict or a dependency that we need to pull into
bpf-next we can always push it out immediately and re-sync if we get a
heads up.
^ permalink raw reply
* PROBLEM: Using BPF_PROG_TEST_RUN with data_out != NULL is unsafe
From: Lorenz Bauer @ 2018-04-04 9:04 UTC (permalink / raw)
To: ast, daniel; +Cc: netdev, linux-kernel
Hello,
I’ve encountered an issue when using BPF_PROG_TEST_RUN and capturing the output.
The kernel copies data into user space without checking the length of
the destination buffer.
In bpf_test_finish(), size is the amount of data in the XDP buffer /
skb after the program is run. This can be larger than data_size_in due
to bpf_xdp_adjust_head() and friends.
bpf_test_finish doesn’t clamp size to data_size_out, which is what I
was expecting.
What is the correct way to use this interface?
Best,
Lorenz
--
Lorenz Bauer | Systems Engineer
25 Lavington St., London SE1 0NZ
www.cloudflare.com
^ permalink raw reply
* Re: [bpf-next PATCH 1/2] bpf: sockmap, free memory on sock close with cork data
From: Daniel Borkmann @ 2018-04-04 9:14 UTC (permalink / raw)
To: John Fastabend, ast; +Cc: netdev, davem
In-Reply-To: <df37e283-a37d-131c-9450-d80a160073ee@gmail.com>
On 04/02/2018 09:58 PM, John Fastabend wrote:
> On 04/02/2018 12:50 PM, John Fastabend wrote:
>> If a socket with pending cork data is closed we do not return the
>> memory to the socket until the garbage collector free's the psock
>> structure. The garbage collector though can run after the sock has
>> completed its close operation. If this ordering happens the sock code
>> will through a WARN_ON because there is still outstanding memory
>> accounted to the sock.
>>
>> To resolve this ensure we return memory to the sock when a socket
>> is closed.
>>
>> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
>> Fixes: 91843d540a13 ("bpf: sockmap, add msg_cork_bytes() helper")
>> ---
>
> Hi Alexei, Daniel,
>
> These two fixes apply against current bpf-next or bpf after
> bpf-next is merged. I could resend later I suppose but I think
> it makes sense to get these in sooner rather than later.
Applied to bpf tree, thanks John!
^ permalink raw reply
* Re: [PATCH] kernel/bpf/syscall: fix warning defined but not used
From: Daniel Borkmann @ 2018-04-04 9:15 UTC (permalink / raw)
To: Anders Roxell, ast; +Cc: netdev, linux-kernel
In-Reply-To: <20180403120947.9321-1-anders.roxell@linaro.org>
On 04/03/2018 02:09 PM, Anders Roxell wrote:
> There will be a build warning -Wunused-function if CONFIG_CGROUP_BPF
> isn't defined, since the only user is inside #ifdef CONFIG_CGROUP_BPF:
> kernel/bpf/syscall.c:1229:12: warning: ‘bpf_prog_attach_check_attach_type’
> defined but not used [-Wunused-function]
> static int bpf_prog_attach_check_attach_type(const struct bpf_prog *prog,
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Current code moves function bpf_prog_attach_check_attach_type inside
> ifdef CONFIG_CGROUP_BPF.
>
> Fixes: 5e43f899b03a ("bpf: Check attach type at prog load time")
> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Applied to bpf tree, thanks Anders!
^ permalink raw reply
* bpf-next is CLOSED
From: Daniel Borkmann @ 2018-04-04 9:21 UTC (permalink / raw)
To: netdev; +Cc: ast
Given the merge window is open right now, please only submit bug
fixes to bpf tree at this time, thank you!
^ permalink raw reply
* Re: [PATCH net-next RFC 0/5] ipv6: sr: introduce seg6local End.BPF action
From: Mathieu Xhonneux @ 2018-04-04 9:34 UTC (permalink / raw)
To: David Lebrun; +Cc: Alexei Starovoitov, netdev, David Lebrun, Daniel Borkmann
In-Reply-To: <c4e374e8-d385-1f86-cafe-85d983f6c45e@gmail.com>
2018-04-03 16:25 GMT+02:00 David Lebrun <dav.lebrun@gmail.com>:
> Actually I'm wrong here. dst_input() will call either ip6_input() or
> ip6_forward(), not ipv6_rcv(). Both functions expect IP6CB() to be set,
> so using skb->cb here will interfere with them.
>
> What about saving and restoring the IPv6 CB, similarly to what TCP does with
> tcp_v6_restore_cb() ?
Yes. I can change the call to bpf_prog_run_save_cb to bpf_prog_run_clear_cb,
and then manually save/restore the IPv6 CB in input_action_end_bpf.
Or is there maybe a better solution to share some state between the bpf caller
and helpers, that does not need access to skb->cb ?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox