* Re: [PATCH 2/2] net: gmii2rgmii: Switch priv field in mdio device structure
From: Harini Katakam @ 2019-08-13 11:16 UTC (permalink / raw)
To: Andrew Lunn
Cc: Harini Katakam, Florian Fainelli, Heiner Kallweit, David Miller,
Michal Simek, netdev, linux-arm-kernel, linux-kernel,
radhey.shyam.pandey
In-Reply-To: <20190801040648.GJ2713@lunn.ch>
Hi Andrew,
On Thu, Aug 1, 2019 at 9:36 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Wed, Jul 31, 2019 at 03:06:19PM +0530, Harini Katakam wrote:
> > Use the priv field in mdio device structure instead of the one in
> > phy device structure. The phy device priv field may be used by the
> > external phy driver and should not be overwritten.
>
> Hi Harini
>
> I _think_ you could use dev_set_drvdata(&mdiodev->dev) in xgmiitorgmii_probe() and
> dev_get_drvdata(&phydev->mdiomdio.dev) in _read_status()
Thanks for the review. This works if I do:
dev_set_drvdata(&priv->phy_dev->mdio.dev->dev) in probe
and then
dev_get_drvdata(&phydev->mdio.dev) in _read_status()
i.e mdiodev in gmii2rgmii probe and priv->phy_dev->mdio are not the same.
If this is acceptable, I can send a v2.
Regards,
Harini
^ permalink raw reply
* Re: [PATCH] virtio-net: parameterize min ring num_free for virtio receive
From: Michael S. Tsirkin @ 2019-08-13 10:55 UTC (permalink / raw)
To: 冉 jiang
Cc: Jason Wang, davem@davemloft.net, ast@kernel.org,
daniel@iogearbox.net, jakub.kicinski@netronome.com,
hawk@kernel.org, john.fastabend@gmail.com, kafai@fb.com,
songliubraving@fb.com, yhs@fb.com,
virtualization@lists.linux-foundation.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, xdp-newbies@vger.kernel.org,
bpf@vger.kernel.org, jiangran.jr@alibaba-inc.com
In-Reply-To: <DM6PR14MB3212E9CD5E95249564B8FBCFA6C70@DM6PR14MB3212.namprd14.prod.outlook.com>
On Tue, Jul 23, 2019 at 12:05:03PM +0000, 冉 jiang wrote:
>
> On 2019/7/20 0:13, Michael S. Tsirkin wrote:
> > On Fri, Jul 19, 2019 at 03:31:29PM +0000, 冉 jiang wrote:
> >> On 2019/7/19 22:29, Jiang wrote:
> >>> On 2019/7/19 10:36, Jason Wang wrote:
> >>>> On 2019/7/18 下午10:43, Michael S. Tsirkin wrote:
> >>>>> On Thu, Jul 18, 2019 at 10:42:47AM -0400, Michael S. Tsirkin wrote:
> >>>>>> On Thu, Jul 18, 2019 at 10:01:05PM +0800, Jason Wang wrote:
> >>>>>>> On 2019/7/18 下午9:04, Michael S. Tsirkin wrote:
> >>>>>>>> On Thu, Jul 18, 2019 at 12:55:50PM +0000, ? jiang wrote:
> >>>>>>>>> This change makes ring buffer reclaim threshold num_free
> >>>>>>>>> configurable
> >>>>>>>>> for better performance, while it's hard coded as 1/2 * queue now.
> >>>>>>>>> According to our test with qemu + dpdk, packet dropping happens
> >>>>>>>>> when
> >>>>>>>>> the guest is not able to provide free buffer in avail ring timely.
> >>>>>>>>> Smaller value of num_free does decrease the number of packet
> >>>>>>>>> dropping
> >>>>>>>>> during our test as it makes virtio_net reclaim buffer earlier.
> >>>>>>>>>
> >>>>>>>>> At least, we should leave the value changeable to user while the
> >>>>>>>>> default value as 1/2 * queue is kept.
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: jiangkidd<jiangkidd@hotmail.com>
> >>>>>>>> That would be one reason, but I suspect it's not the
> >>>>>>>> true one. If you need more buffer due to jitter
> >>>>>>>> then just increase the queue size. Would be cleaner.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> However are you sure this is the reason for
> >>>>>>>> packet drops? Do you see them dropped by dpdk
> >>>>>>>> due to lack of space in the ring? As opposed to
> >>>>>>>> by guest?
> >>>>>>>>
> >>>>>>>>
> >>>>>>> Besides those, this patch depends on the user to choose a suitable
> >>>>>>> threshold
> >>>>>>> which is not good. You need either a good value with demonstrated
> >>>>>>> numbers or
> >>>>>>> something smarter.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>> I do however think that we have a problem right now: try_fill_recv can
> >>>>>> take up a long time during which net stack does not run at all.
> >>>>>> Imagine
> >>>>>> a 1K queue - we are talking 512 packets. That's exceessive.
> >>>>
> >>>> Yes, we will starve a fast host in this case.
> >>>>
> >>>>
> >>>>>> napi poll
> >>>>>> weight solves a similar problem, so it might make sense to cap this at
> >>>>>> napi_poll_weight.
> >>>>>>
> >>>>>> Which will allow tweaking it through a module parameter as a
> >>>>>> side effect :) Maybe just do NAPI_POLL_WEIGHT.
> >>>>> Or maybe NAPI_POLL_WEIGHT/2 like we do at half the queue ;). Please
> >>>>> experiment, measure performance and let the list know
> >>>>>
> >>>>>> Need to be careful though: queues can also be small and I don't
> >>>>>> think we
> >>>>>> want to exceed queue size / 2, or maybe queue size - napi_poll_weight.
> >>>>>> Definitely must not exceed the full queue size.
> >>>>
> >>>> Looking at intel, it uses 16 and i40e uses 32. It looks to me
> >>>> NAPI_POLL_WEIGHT/2 is better.
> >>>>
> >>>> Jiang, want to try that and post a new patch?
> >>>>
> >>>> Thanks
> >>>>
> >>>>
> >>>>>> --
> >>>>>> MST
> >>> We did have completed several rounds of test with setting the value to
> >>> budget (64 as the default value). It does improve a lot with pps is
> >>> below 400pps for a single stream. Let me consolidate the data and will
> >>> send it soon. Actually, we are confident that it runs out of free
> >>> buffer in avail ring when packet dropping happens with below systemtap:
> >>>
> >>> Just a snippet:
> >>>
> >>> probe module("virtio_ring").function("virtqueue_get_buf")
> >>> {
> >>> x = (@cast($_vq, "vring_virtqueue")->vring->used->idx)-
> >>> (@cast($_vq, "vring_virtqueue")->last_used_idx) ---> we use this one
> >>> to verify if the queue is full, which means guest is not able to take
> >>> buffer from the queue timely
> >>>
> >>> if (x<0 && (x+65535)<4096)
> >>> x = x+65535
> >>>
> >>> if((x==1024) && @cast($_vq, "vring_virtqueue")->vq->callback ==
> >>> callback_addr)
> >>> netrxcount[x] <<< gettimeofday_s()
> >>> }
> >>>
> >>>
> >>> probe module("virtio_ring").function("virtqueue_add_inbuf")
> >>> {
> >>> y = (@cast($vq, "vring_virtqueue")->vring->avail->idx)-
> >>> (@cast($vq, "vring_virtqueue")->vring->used->idx) ---> we use this one
> >>> to verify if we run out of free buffer in avail ring
> >>> if (y<0 && (y+65535)<4096)
> >>> y = y+65535
> >>>
> >>> if(@2=="debugon")
> >>> {
> >>> if(y==0 && @cast($vq, "vring_virtqueue")->vq->callback ==
> >>> callback_addr)
> >>> {
> >>> netrxfreecount[y] <<< gettimeofday_s()
> >>>
> >>> printf("no avail ring left seen, printing most recent 5
> >>> num free, vq: %lx, current index: %d\n", $vq, recentfreecount)
> >>> for(i=recentfreecount; i!=((recentfreecount+4) % 5);
> >>> i=((i+1) % 5))
> >>> {
> >>> printf("index: %d, num free: %d\n", i, recentfree[$vq,
> >>> i])
> >>> }
> >>>
> >>> printf("index: %d, num free: %d\n", i, recentfree[$vq, i])
> >>> //exit()
> >>> }
> >>> }
> >>> }
> >>>
> >>>
> >>> probe
> >>> module("virtio_net").statement("virtnet_receive@drivers/net/virtio_net.c:732")
> >>> {
> >>> recentfreecount++
> >>> recentfreecount = recentfreecount % 5
> >>> recentfree[$rq->vq, recentfreecount] = $rq->vq->num_free --->
> >>> record the num_free for the last 5 calls to virtnet_receive, so we can
> >>> see if lowering the bar helps.
> >>> }
> >>>
> >>>
> >>> Here is the result:
> >>>
> >>> no avail ring left seen, printing most recent 5 num free, vq:
> >>> ffff9c13c1200000, current index: 1
> >>> index: 1, num free: 561
> >>> index: 2, num free: 305
> >>> index: 3, num free: 369
> >>> index: 4, num free: 433
> >>> index: 0, num free: 497
> >>> no avail ring left seen, printing most recent 5 num free, vq:
> >>> ffff9c13c1200000, current index: 1
> >>> index: 1, num free: 543
> >>> index: 2, num free: 463
> >>> index: 3, num free: 469
> >>> index: 4, num free: 476
> >>> index: 0, num free: 479
> >>> no avail ring left seen, printing most recent 5 num free, vq:
> >>> ffff9c13c1200000, current index: 2
> >>> index: 2, num free: 555
> >>> index: 3, num free: 414
> >>> index: 4, num free: 420
> >>> index: 0, num free: 427
> >>> index: 1, num free: 491
> >>>
> >>> You can see in the last 4 calls to virtnet_receive before we run out
> >>> of free buffer and start to relaim, num_free is quite high. So if we
> >>> can do the reclaim earlier, it will certainly help.
> >>>
> >>> Meanwhile, the patch I proposed actually keeps the default value as
> >>> 1/2 * queue. So the default behavior remains and only leave the
> >>> interface to advanced users, who really understands what they are
> >>> doing. Also, the best value may vary in different environment. Do you
> >>> still think hardcoding this is better option?
> >>>
> >>>
> >>> Jiang
> >>>
> >> Here is the snippet from our test result. Test1 was done with default
> >> driver with the value of 1/2 * queue, while test2 is with my patch and
> >> min_numfree set to 64 (the default budget value). We can see average
> >> drop packets do decrease a lot in test2. Let me know if you need the
> >> full testing data.
> >>
> >> test1Time avgDropPackets test2Time avgDropPackets pps
> >>
> >>> 16:21.0 12.295 56:50.4 0 300k
> >>> 17:19.1 15.244 56:50.4 0 300k
> >>> 18:17.5 18.789 56:50.4 0 300k
> >>> 19:15.1 14.208 56:50.4 0 300k
> >>> 20:13.2 20.818 56:50.4 0.267 300k
> >>> 21:11.2 12.397 56:50.4 0 300k
> >>> 22:09.3 12.599 56:50.4 0 300k
> >>> 23:07.3 15.531 57:48.4 0 300k
> >>> 24:05.5 13.664 58:46.5 0 300k
> >>> 25:03.7 13.158 59:44.5 4.73 300k
> >>> 26:01.1 2.486 00:42.6 0 300k
> >>> 26:59.1 11.241 01:40.6 0 300k
> >>> 27:57.2 20.521 02:38.6 0 300k
> >>> 28:55.2 30.094 03:36.7 0 300k
> >>> 29:53.3 16.828 04:34.7 0.963 300k
> >>> 30:51.3 46.916 05:32.8 0 400k
> >>> 31:49.3 56.214 05:32.8 0 400k
> >>> 32:47.3 58.69 05:32.8 0 400k
> >>> 33:45.3 61.486 05:32.8 0 400k
> >>> 34:43.3 72.175 05:32.8 0.598 400k
> >>> 35:41.3 56.699 05:32.8 0 400k
> >>> 36:39.3 61.071 05:32.8 0 400k
> >>> 37:37.3 43.355 06:30.8 0 400k
> >>> 38:35.4 44.644 06:30.8 0 400k
> >>> 39:33.4 72.336 06:30.8 0 400k
> >>> 40:31.4 70.676 06:30.8 0 400k
> >>> 41:29.4 108.009 06:30.8 0 400k
> >>> 42:27.4 65.216 06:30.8 0 400k
> >>
> >> Jiang
> >
> > OK I find this surprising but I accept what you see.
> > I'm inclined not to add a tunable and just select
> > a value ourselves.
> > I'm also fine with using the napi poll module parameter
> > which will give you a bit of tunability.
>
> OK, kindly take a look if you prefer the below code change. I tested
> budget/2 and the result is almost the same as budget when pps below
> 400k, but a little better when it goes beyond 400k in my environment.
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>
> index 0d4115c9e20b..bc08be7925eb 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1331,7 +1331,7 @@ static int virtnet_receive(struct receive_queue
> *rq, int budget,
> }
> }
>
> - if (rq->vq->num_free > virtqueue_get_vring_size(rq->vq) / 2) {
> + if (rq->vq->num_free > min((unsigned int)budget,
> virtqueue_get_vring_size(rq->vq)) / 2) {
> if (!try_fill_recv(vi, rq, GFP_ATOMIC))
> schedule_delayed_work(&vi->refill, 0);
> }
>
>
> Jiang
>
Looks good to me.
Pls post for inclusion in -net.
--
MST
^ permalink raw reply
* Re: [PATCH iproute2-next v2 4/4] devlink: Add man page for devlink-trap
From: Jiri Pirko @ 2019-08-13 10:52 UTC (permalink / raw)
To: Ido Schimmel; +Cc: netdev, dsahern, stephen, jiri, mlxsw, Ido Schimmel
In-Reply-To: <20190813103904.GA16305@splinter>
Tue, Aug 13, 2019 at 12:39:04PM CEST, idosch@idosch.org wrote:
>On Tue, Aug 13, 2019 at 12:20:37PM +0200, Jiri Pirko wrote:
>> Tue, Aug 13, 2019 at 10:31:43AM CEST, idosch@idosch.org wrote:
>> >From: Ido Schimmel <idosch@mellanox.com>
>> >
>> >Signed-off-by: Ido Schimmel <idosch@mellanox.com>
>> >---
>> > man/man8/devlink-monitor.8 | 3 +-
>> > man/man8/devlink-trap.8 | 138 +++++++++++++++++++++++++++++++++++++
>> > man/man8/devlink.8 | 11 ++-
>> > 3 files changed, 150 insertions(+), 2 deletions(-)
>> > create mode 100644 man/man8/devlink-trap.8
>> >
>> >diff --git a/man/man8/devlink-monitor.8 b/man/man8/devlink-monitor.8
>> >index 13fe641dc8f5..fffab3a4ce88 100644
>> >--- a/man/man8/devlink-monitor.8
>> >+++ b/man/man8/devlink-monitor.8
>> >@@ -21,7 +21,7 @@ command is the first in the command line and then the object list.
>> > .I OBJECT-LIST
>> > is the list of object types that we want to monitor.
>> > It may contain
>> >-.BR dev ", " port ".
>> >+.BR dev ", " port ", " trap ", " trap-group .
>>
>> Looks like "trap-group" is a leftover here, isn't it?
>
>You get events when traps and groups are created / destroyed. See below output
>when creating a new netdevsim device:
Ah! Makes sense. Thanks!
>
>$ devlink mon trap-group
>[trap-group,new] netdevsim/netdevsim20: name l2_drops generic true
>[trap-group,new] netdevsim/netdevsim20: name l3_drops generic true
>[trap-group,new] netdevsim/netdevsim20: name buffer_drops generic true
>
>$ devlink mon trap
>[trap,new] netdevsim/netdevsim10: name source_mac_is_multicast type drop generic true action drop group l2_drops
>[trap,new] netdevsim/netdevsim10: name vlan_tag_mismatch type drop generic true action drop group l2_drops
>[trap,new] netdevsim/netdevsim10: name ingress_vlan_filter type drop generic true action drop group l2_drops
>[trap,new] netdevsim/netdevsim10: name ingress_spanning_tree_filter type drop generic true action drop group l2_drops
>[trap,new] netdevsim/netdevsim10: name port_list_is_empty type drop generic true action drop group l2_drops
>[trap,new] netdevsim/netdevsim10: name port_loopback_filter type drop generic true action drop group l2_drops
>[trap,new] netdevsim/netdevsim10: name fid_miss type exception generic false action trap group l2_drops
>[trap,new] netdevsim/netdevsim10: name blackhole_route type drop generic true action drop group l3_drops
>[trap,new] netdevsim/netdevsim10: name ttl_value_is_too_small type exception generic true action trap group l3_drops
>[trap,new] netdevsim/netdevsim10: name tail_drop type drop generic true action drop group buffer_drops
^ permalink raw reply
* tc - mirred ingress not supported at the moment
From: Martin Olsson @ 2019-08-13 10:51 UTC (permalink / raw)
To: netdev
In-Reply-To: <CAAT+qEa6Yw-tf3L_R-phzSvLiGOdW9uLhFGNTz+i9eWhBT_+DA@mail.gmail.com>
Two questions regarding tc-mirred:
1)
The manual ( https://www.linux.org/docs/man8/tc-mirred.html ) states:
OPTIONS
ingress
egress
Specify the direction in which the packet shall appear on the
destination interface.
Currently only egress is implemented.
I verify to see if this is still true, and unfortunately it is:
# tc filter add dev eno2 parent ffff: prio 999 protocol all matchall
action mirred ingress redirect dev mon0
mirred ingress not supported at the moment
bad action parsing
parse_action: bad value (5:mirred)!
Illegal "action"
Q1: Why was 'ingress' not implemented at the same time as 'egress'?
2)
Ok, so I have to use 'egress':
# tc filter add dev eno2 parent ffff: prio 999 protocol all matchall
action mirred egress redirect dev mon0
Since the mirred action forces me to use 'egress' as the direction on
the dest interface, all kinds of network statistics tools show
incorrect counters. :-(
eno2 is a pure sniffer interface (it is connected to the SPAN dest
port of a switch).
All packets (matchall) on eno2 are mirrored to mon0.
# ip -s link show dev eno2
...
...
RX: bytes packets errors dropped overrun mcast
13660757 16329 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
# ip -s link show dev mon0
...
...
RX: bytes packets errors dropped overrun mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
13660757 16329 0 0 0 0
eno2 and mon0 should be identical, but they are inverted.
When I graph all interfaces of the machine, the traffic graph for
'mon0' is incorrect since it shows 100% egress when the traffic really
is ingress.
As a human I can re-enterpret the mon0 graph when looking at it, but
it is harder for automated tools to do the right thing without
explicit node configuration/exceptions in the tool. This is annoying
when you have tools that graph hundreds of different types of nodes
with different kinds of interface types, and want all graphs to be
visually simillar for easy comparison.
Tool output that mon0 has sent 16329 packets is also plain wrong. It
has really *received* these packets.
Q2: So... Can the 'ingress' option please be implemented? (I'm no
programmer, so unfortunetly I can't do it myself).
/Martin
^ permalink raw reply
* RE: [EXT] [PATCH] qed: Add cleanup in qed_slowpath_start()
From: Sudarsana Reddy Kalluru @ 2019-08-13 10:46 UTC (permalink / raw)
To: Wenwen Wang
Cc: Ariel Elior, GR-everest-linux-l2, David S. Miller,
open list:QLOGIC QL4xxx ETHERNET DRIVER, open list
In-Reply-To: <1565690709-3186-1-git-send-email-wenwen@cs.uga.edu>
> -----Original Message-----
> From: Wenwen Wang <wenwen@cs.uga.edu>
> Sent: Tuesday, August 13, 2019 3:35 PM
> To: Wenwen Wang <wenwen@cs.uga.edu>
> Cc: Ariel Elior <aelior@marvell.com>; GR-everest-linux-l2 <GR-everest-linux-
> l2@marvell.com>; David S. Miller <davem@davemloft.net>; open
> list:QLOGIC QL4xxx ETHERNET DRIVER <netdev@vger.kernel.org>; open list
> <linux-kernel@vger.kernel.org>
> Subject: [EXT] [PATCH] qed: Add cleanup in qed_slowpath_start()
>
> External Email
>
> ----------------------------------------------------------------------
> If qed_mcp_send_drv_version() fails, no cleanup is executed, leading to
> memory leaks. To fix this issue, redirect the execution to the label 'err3'
> before returning the error.
>
> Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
> ---
> drivers/net/ethernet/qlogic/qed/qed_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c
> b/drivers/net/ethernet/qlogic/qed/qed_main.c
> index 829dd60..d16a251 100644
> --- a/drivers/net/ethernet/qlogic/qed/qed_main.c
> +++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
> @@ -1325,7 +1325,7 @@ static int qed_slowpath_start(struct qed_dev
> *cdev,
> &drv_version);
> if (rc) {
> DP_NOTICE(cdev, "Failed sending drv version
> command\n");
> - return rc;
> + goto err3;
In this case, we might need to free the ll2-buf allocated at the below path (?),
1312 /* Allocate LL2 interface if needed */
1313 if (QED_LEADING_HWFN(cdev)->using_ll2) {
1314 rc = qed_ll2_alloc_if(cdev);
May be by adding a new goto label 'err4'.
> }
> }
>
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH iproute2-next v2 4/4] devlink: Add man page for devlink-trap
From: Ido Schimmel @ 2019-08-13 10:39 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, dsahern, stephen, jiri, mlxsw, Ido Schimmel
In-Reply-To: <20190813102037.GP2428@nanopsycho>
On Tue, Aug 13, 2019 at 12:20:37PM +0200, Jiri Pirko wrote:
> Tue, Aug 13, 2019 at 10:31:43AM CEST, idosch@idosch.org wrote:
> >From: Ido Schimmel <idosch@mellanox.com>
> >
> >Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> >---
> > man/man8/devlink-monitor.8 | 3 +-
> > man/man8/devlink-trap.8 | 138 +++++++++++++++++++++++++++++++++++++
> > man/man8/devlink.8 | 11 ++-
> > 3 files changed, 150 insertions(+), 2 deletions(-)
> > create mode 100644 man/man8/devlink-trap.8
> >
> >diff --git a/man/man8/devlink-monitor.8 b/man/man8/devlink-monitor.8
> >index 13fe641dc8f5..fffab3a4ce88 100644
> >--- a/man/man8/devlink-monitor.8
> >+++ b/man/man8/devlink-monitor.8
> >@@ -21,7 +21,7 @@ command is the first in the command line and then the object list.
> > .I OBJECT-LIST
> > is the list of object types that we want to monitor.
> > It may contain
> >-.BR dev ", " port ".
> >+.BR dev ", " port ", " trap ", " trap-group .
>
> Looks like "trap-group" is a leftover here, isn't it?
You get events when traps and groups are created / destroyed. See below output
when creating a new netdevsim device:
$ devlink mon trap-group
[trap-group,new] netdevsim/netdevsim20: name l2_drops generic true
[trap-group,new] netdevsim/netdevsim20: name l3_drops generic true
[trap-group,new] netdevsim/netdevsim20: name buffer_drops generic true
$ devlink mon trap
[trap,new] netdevsim/netdevsim10: name source_mac_is_multicast type drop generic true action drop group l2_drops
[trap,new] netdevsim/netdevsim10: name vlan_tag_mismatch type drop generic true action drop group l2_drops
[trap,new] netdevsim/netdevsim10: name ingress_vlan_filter type drop generic true action drop group l2_drops
[trap,new] netdevsim/netdevsim10: name ingress_spanning_tree_filter type drop generic true action drop group l2_drops
[trap,new] netdevsim/netdevsim10: name port_list_is_empty type drop generic true action drop group l2_drops
[trap,new] netdevsim/netdevsim10: name port_loopback_filter type drop generic true action drop group l2_drops
[trap,new] netdevsim/netdevsim10: name fid_miss type exception generic false action trap group l2_drops
[trap,new] netdevsim/netdevsim10: name blackhole_route type drop generic true action drop group l3_drops
[trap,new] netdevsim/netdevsim10: name ttl_value_is_too_small type exception generic true action trap group l3_drops
[trap,new] netdevsim/netdevsim10: name tail_drop type drop generic true action drop group buffer_drops
^ permalink raw reply
* [PATCH bpf-next 0/3] xdpsock: allow mmap2 usage for 32bits
From: Ivan Khoronzhuk @ 2019-08-13 10:23 UTC (permalink / raw)
To: magnus.karlsson, bjorn.topel
Cc: davem, hawk, john.fastabend, jakub.kicinski, daniel, netdev, bpf,
xdp-newbies, linux-kernel, Ivan Khoronzhuk
This patchset contains several improvements for af_xdp socket umem
mappings for 32bit systems. Also, there is one more patch outside of
othis series that can be applied to another tree and related to mmap2
af_xdp umem offsets:
"mm: mmap: increase sockets maximum memory size pgoff for 32bits"
https://lkml.org/lkml/2019/8/12/549
Based on bpf-next/master
Ivan Khoronzhuk (3):
libbpf: add asm/unistd.h to xsk to get __NR_mmap2
xdp: xdp_umem: replace kmap on vmap for umem map
samples: bpf: syscal_nrs: use mmap2 if defined
net/xdp/xdp_umem.c | 16 ++++++++++++----
samples/bpf/syscall_nrs.c | 5 +++++
samples/bpf/tracex5_kern.c | 11 +++++++++++
tools/lib/bpf/xsk.c | 1 +
4 files changed, 29 insertions(+), 4 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH bpf-next 2/3] xdp: xdp_umem: replace kmap on vmap for umem map
From: Ivan Khoronzhuk @ 2019-08-13 10:23 UTC (permalink / raw)
To: magnus.karlsson, bjorn.topel
Cc: davem, hawk, john.fastabend, jakub.kicinski, daniel, netdev, bpf,
xdp-newbies, linux-kernel, Ivan Khoronzhuk
In-Reply-To: <20190813102318.5521-1-ivan.khoronzhuk@linaro.org>
For 64-bit there is no reason to use vmap/vunmap, so use page_address
as it was initially. For 32 bits, in some apps, like in samples
xdpsock_user.c when number of pgs in use is quite big, the kmap
memory can be not enough, despite on this, kmap looks like is
deprecated in such cases as it can block and should be used rather
for dynamic mm.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
net/xdp/xdp_umem.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
index a0607969f8c0..907c9019fe21 100644
--- a/net/xdp/xdp_umem.c
+++ b/net/xdp/xdp_umem.c
@@ -14,7 +14,7 @@
#include <linux/netdevice.h>
#include <linux/rtnetlink.h>
#include <linux/idr.h>
-#include <linux/highmem.h>
+#include <linux/vmalloc.h>
#include "xdp_umem.h"
#include "xsk_queue.h"
@@ -167,10 +167,12 @@ void xdp_umem_clear_dev(struct xdp_umem *umem)
static void xdp_umem_unmap_pages(struct xdp_umem *umem)
{
+#if BITS_PER_LONG == 32
unsigned int i;
for (i = 0; i < umem->npgs; i++)
- kunmap(umem->pgs[i]);
+ vunmap(umem->pages[i].addr);
+#endif
}
static void xdp_umem_unpin_pages(struct xdp_umem *umem)
@@ -378,8 +380,14 @@ static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
goto out_account;
}
- for (i = 0; i < umem->npgs; i++)
- umem->pages[i].addr = kmap(umem->pgs[i]);
+ for (i = 0; i < umem->npgs; i++) {
+#if BITS_PER_LONG == 32
+ umem->pages[i].addr = vmap(&umem->pgs[i], 1, VM_MAP,
+ PAGE_KERNEL);
+#else
+ umem->pages[i].addr = page_address(umem->pgs[i]);
+#endif
+ }
return 0;
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 3/3] samples: bpf: syscal_nrs: use mmap2 if defined
From: Ivan Khoronzhuk @ 2019-08-13 10:23 UTC (permalink / raw)
To: magnus.karlsson, bjorn.topel
Cc: davem, hawk, john.fastabend, jakub.kicinski, daniel, netdev, bpf,
xdp-newbies, linux-kernel, Ivan Khoronzhuk
In-Reply-To: <20190813102318.5521-1-ivan.khoronzhuk@linaro.org>
For arm32 xdp sockets mmap2 is preferred, so use it if it's defined.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
samples/bpf/syscall_nrs.c | 5 +++++
samples/bpf/tracex5_kern.c | 11 +++++++++++
2 files changed, 16 insertions(+)
diff --git a/samples/bpf/syscall_nrs.c b/samples/bpf/syscall_nrs.c
index 516e255cbe8f..2dec94238350 100644
--- a/samples/bpf/syscall_nrs.c
+++ b/samples/bpf/syscall_nrs.c
@@ -9,5 +9,10 @@ void syscall_defines(void)
COMMENT("Linux system call numbers.");
SYSNR(__NR_write);
SYSNR(__NR_read);
+#ifdef __NR_mmap2
+ SYSNR(__NR_mmap2);
+#else
SYSNR(__NR_mmap);
+#endif
+
}
diff --git a/samples/bpf/tracex5_kern.c b/samples/bpf/tracex5_kern.c
index f57f4e1ea1ec..300350ad299a 100644
--- a/samples/bpf/tracex5_kern.c
+++ b/samples/bpf/tracex5_kern.c
@@ -68,12 +68,23 @@ PROG(SYS__NR_read)(struct pt_regs *ctx)
return 0;
}
+#ifdef __NR_mmap2
+PROG(SYS__NR_mmap2)(struct pt_regs *ctx)
+{
+ char fmt[] = "mmap2\n";
+
+ bpf_trace_printk(fmt, sizeof(fmt));
+ return 0;
+}
+#else
PROG(SYS__NR_mmap)(struct pt_regs *ctx)
{
char fmt[] = "mmap\n";
+
bpf_trace_printk(fmt, sizeof(fmt));
return 0;
}
+#endif
char _license[] SEC("license") = "GPL";
u32 _version SEC("version") = LINUX_VERSION_CODE;
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 1/3] libbpf: add asm/unistd.h to xsk to get __NR_mmap2
From: Ivan Khoronzhuk @ 2019-08-13 10:23 UTC (permalink / raw)
To: magnus.karlsson, bjorn.topel
Cc: davem, hawk, john.fastabend, jakub.kicinski, daniel, netdev, bpf,
xdp-newbies, linux-kernel, Ivan Khoronzhuk
In-Reply-To: <20190813102318.5521-1-ivan.khoronzhuk@linaro.org>
That's needed to get __NR_mmap2 when mmap2 syscall is used.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
tools/lib/bpf/xsk.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
index 5007b5d4fd2c..f2fc40f9804c 100644
--- a/tools/lib/bpf/xsk.c
+++ b/tools/lib/bpf/xsk.c
@@ -12,6 +12,7 @@
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
+#include <asm/unistd.h>
#include <arpa/inet.h>
#include <asm/barrier.h>
#include <linux/compiler.h>
--
2.17.1
^ permalink raw reply related
* Re: [PATCH iproute2-next v2 4/4] devlink: Add man page for devlink-trap
From: Jiri Pirko @ 2019-08-13 10:20 UTC (permalink / raw)
To: Ido Schimmel; +Cc: netdev, dsahern, stephen, jiri, mlxsw, Ido Schimmel
In-Reply-To: <20190813083143.13509-5-idosch@idosch.org>
Tue, Aug 13, 2019 at 10:31:43AM CEST, idosch@idosch.org wrote:
>From: Ido Schimmel <idosch@mellanox.com>
>
>Signed-off-by: Ido Schimmel <idosch@mellanox.com>
>---
> man/man8/devlink-monitor.8 | 3 +-
> man/man8/devlink-trap.8 | 138 +++++++++++++++++++++++++++++++++++++
> man/man8/devlink.8 | 11 ++-
> 3 files changed, 150 insertions(+), 2 deletions(-)
> create mode 100644 man/man8/devlink-trap.8
>
>diff --git a/man/man8/devlink-monitor.8 b/man/man8/devlink-monitor.8
>index 13fe641dc8f5..fffab3a4ce88 100644
>--- a/man/man8/devlink-monitor.8
>+++ b/man/man8/devlink-monitor.8
>@@ -21,7 +21,7 @@ command is the first in the command line and then the object list.
> .I OBJECT-LIST
> is the list of object types that we want to monitor.
> It may contain
>-.BR dev ", " port ".
>+.BR dev ", " port ", " trap ", " trap-group .
Looks like "trap-group" is a leftover here, isn't it?
>
> .B devlink
> opens Devlink Netlink socket, listens on it and dumps state changes.
>@@ -31,6 +31,7 @@ opens Devlink Netlink socket, listens on it and dumps state changes.
> .BR devlink-dev (8),
> .BR devlink-sb (8),
> .BR devlink-port (8),
>+.BR devlink-trap (8),
> .br
>
> .SH AUTHOR
>diff --git a/man/man8/devlink-trap.8 b/man/man8/devlink-trap.8
>new file mode 100644
>index 000000000000..4f079eb86d7b
>--- /dev/null
>+++ b/man/man8/devlink-trap.8
>@@ -0,0 +1,138 @@
>+.TH DEVLINK\-TRAP 8 "2 August 2019" "iproute2" "Linux"
>+.SH NAME
>+devlink-trap \- devlink trap configuration
>+.SH SYNOPSIS
>+.sp
>+.ad l
>+.in +8
>+.ti -8
>+.B devlink
>+.RI "[ " OPTIONS " ]"
>+.B trap
>+.RI "{ " COMMAND " |"
>+.BR help " }"
>+.sp
>+
>+.ti -8
>+.IR OPTIONS " := { "
>+\fB\-v\fR[\fIerbose\fR] |
>+\fB\-s\fR[\fItatistics\fR] }
Not sure you need to put generic option here. But I don't mind much.
Otherwise this looks fine.
Acked-by: Jiri Pirko <jiri@mellanox.com>
[...]
^ permalink raw reply
* Re: [PATCH iproute2-next v2 3/4] devlink: Add devlink trap group set and show commands
From: Jiri Pirko @ 2019-08-13 10:15 UTC (permalink / raw)
To: Ido Schimmel; +Cc: netdev, dsahern, stephen, jiri, mlxsw, Ido Schimmel
In-Reply-To: <20190813083143.13509-4-idosch@idosch.org>
Tue, Aug 13, 2019 at 10:31:42AM CEST, idosch@idosch.org wrote:
>From: Ido Schimmel <idosch@mellanox.com>
>
>These commands are similar to the trap set and show commands, but
>operate on a trap group and not individual traps. Example:
>
># devlink trap group set netdevsim/netdevsim10 group l3_drops action trap
># devlink -jps trap group show netdevsim/netdevsim10 group l3_drops
>{
> "trap_group": {
> "netdevsim/netdevsim10": [ {
> "name": "l3_drops",
> "generic": true,
> "stats": {
> "rx": {
> "bytes": 0,
> "packets": 0
> }
> }
> } ]
> }
>}
>
>Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next v1 0/8] netfilter: header compilation fixes
From: Pablo Neira Ayuso @ 2019-08-13 10:14 UTC (permalink / raw)
To: Jeremy Sowden; +Cc: Netfilter Devel, Net Dev, Masahiro Yamada
In-Reply-To: <20190813100424.GA4840@azazel.net>
On Tue, Aug 13, 2019 at 11:04:24AM +0100, Jeremy Sowden wrote:
> On 2019-08-13, at 11:55:29 +0200, Pablo Neira Ayuso wrote:
> > On Wed, Aug 07, 2019 at 03:16:57PM +0100, Jeremy Sowden wrote:
> > > A number of netfilter header files are on the header-test blacklist
> > > becuse they cannot be compiled stand-alone. There are two main
> > > reasons for this: missing inclusions of other headers, and missing
> > > conditionals checking for CONFIG_* symbols.
> > >
> > > The first six of these patches rectify these omissions, the seventh
> > > removes some unnecessary "#ifdef __KERNEL__" checks, and the last
> > > removes all the NF headers from the blacklist.
> > >
> > > I've cc'ed Masahiro Yamada because the last patch removes 74 lines
> > > from include/Kbuild and may conflict with his kbuild tree.
> >
> > Series applied, one comment below.
> >
> > > Jeremy Sowden (8):
> > > netfilter: inlined four headers files into another one.
> > > netfilter: added missing includes to a number of header-files.
> > > netfilter: added missing IS_ENABLED(CONFIG_BRIDGE_NETFILTER) checks to
> > > header-file.
> > > netfilter: added missing IS_ENABLED(CONFIG_NF_TABLES) check to
> > > header-file.
> > > netfilter: added missing IS_ENABLED(CONFIG_NF_CONNTRACK) checks to
> > > some header-files.
> > > netfilter: added missing IS_ENABLED(CONFIG_NETFILTER) checks to some
> > > header-files.
> > > netfilter: removed "#ifdef __KERNEL__" guards from some headers.
> > > kbuild: removed all netfilter headers from header-test blacklist.
> >
> > Would you mind if - before pushing this out - I do this string
> > replacement for the patch subject?
> >
> > s/added/add
> > s/removed/remove
> > s/inlined/inline
> >
> > I was told present tense is preferred for description. Otherwise, I'll
> > leave them as is.
>
> I adopted past tenses because at the point at which one is reading the
> description of a commit, one is usually reading about old behaviour and
> what has been done to change it. However, I wasn't aware that there was
> a preference and I am happy to switch to the present tense instead, so
> by all means feel free to change them.
This is not in the Documentation tree, or I could not find this in a
quick git grep:
https://kernelnewbies.org/PatchPhilosophy
"In patch descriptions and in the subject, it is common and preferable
to use present-tense, imperative language. Write as if you are telling
git what to do with your patch."
I remember though that maintainers have been asking for this in the
past.
Thanks!
^ permalink raw reply
* Re: [PATCH v2] net/netfilter: remove unnecessary spaces
From: Pablo Neira Ayuso @ 2019-08-13 10:10 UTC (permalink / raw)
To: yangxingwu
Cc: wensong, horms, ja, kadlec, fw, davem, netdev, lvs-devel,
netfilter-devel, coreteam, linux-kernel, joe
In-Reply-To: <20190716021301.27753-1-xingwu.yang@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH rdma-next 0/4] Add XRQ and SRQ support to DEVX interface
From: Leon Romanovsky @ 2019-08-13 10:06 UTC (permalink / raw)
To: Doug Ledford
Cc: Jason Gunthorpe, RDMA mailing list, Edward Srouji, Saeed Mahameed,
Yishai Hadas, linux-netdev
In-Reply-To: <dc88624d6632f23a1b0ca77f45ed21a20158d3e6.camel@redhat.com>
On Mon, Aug 12, 2019 at 11:43:58AM -0400, Doug Ledford wrote:
> On Thu, 2019-08-08 at 10:11 +0000, Leon Romanovsky wrote:
> > On Thu, Aug 08, 2019 at 11:43:54AM +0300, Leon Romanovsky wrote:
> > > From: Leon Romanovsky <leonro@mellanox.com>
> > >
> > > Hi,
> > >
> > > This small series extends DEVX interface with SRQ and XRQ legacy
> > > commands.
> >
> > Sorry for typo in cover letter, there is no SRQ here.
>
> Series looks fine to me. Are you planning on the first two via mlx5-
> next and the remainder via RDMA tree?
>
Thanks, applied to mlx5-next
b1635ee6120c net/mlx5: Add XRQ legacy commands opcodes
647d58a989b3 net/mlx5: Use debug message instead of warn
^ permalink raw reply
* [PATCH] qed: Add cleanup in qed_slowpath_start()
From: Wenwen Wang @ 2019-08-13 10:05 UTC (permalink / raw)
To: Wenwen Wang
Cc: Ariel Elior, supporter:QLOGIC QL4xxx ETHERNET DRIVER,
David S. Miller, open list:QLOGIC QL4xxx ETHERNET DRIVER,
open list
If qed_mcp_send_drv_version() fails, no cleanup is executed, leading to
memory leaks. To fix this issue, redirect the execution to the label 'err3'
before returning the error.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
---
drivers/net/ethernet/qlogic/qed/qed_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index 829dd60..d16a251 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -1325,7 +1325,7 @@ static int qed_slowpath_start(struct qed_dev *cdev,
&drv_version);
if (rc) {
DP_NOTICE(cdev, "Failed sending drv version command\n");
- return rc;
+ goto err3;
}
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v1 0/8] netfilter: header compilation fixes
From: Jeremy Sowden @ 2019-08-13 10:04 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: Netfilter Devel, Net Dev, Masahiro Yamada
In-Reply-To: <20190813095529.aisgjjwl6rzt5xeh@salvia>
[-- Attachment #1: Type: text/plain, Size: 2026 bytes --]
On 2019-08-13, at 11:55:29 +0200, Pablo Neira Ayuso wrote:
> On Wed, Aug 07, 2019 at 03:16:57PM +0100, Jeremy Sowden wrote:
> > A number of netfilter header files are on the header-test blacklist
> > becuse they cannot be compiled stand-alone. There are two main
> > reasons for this: missing inclusions of other headers, and missing
> > conditionals checking for CONFIG_* symbols.
> >
> > The first six of these patches rectify these omissions, the seventh
> > removes some unnecessary "#ifdef __KERNEL__" checks, and the last
> > removes all the NF headers from the blacklist.
> >
> > I've cc'ed Masahiro Yamada because the last patch removes 74 lines
> > from include/Kbuild and may conflict with his kbuild tree.
>
> Series applied, one comment below.
>
> > Jeremy Sowden (8):
> > netfilter: inlined four headers files into another one.
> > netfilter: added missing includes to a number of header-files.
> > netfilter: added missing IS_ENABLED(CONFIG_BRIDGE_NETFILTER) checks to
> > header-file.
> > netfilter: added missing IS_ENABLED(CONFIG_NF_TABLES) check to
> > header-file.
> > netfilter: added missing IS_ENABLED(CONFIG_NF_CONNTRACK) checks to
> > some header-files.
> > netfilter: added missing IS_ENABLED(CONFIG_NETFILTER) checks to some
> > header-files.
> > netfilter: removed "#ifdef __KERNEL__" guards from some headers.
> > kbuild: removed all netfilter headers from header-test blacklist.
>
> Would you mind if - before pushing this out - I do this string
> replacement for the patch subject?
>
> s/added/add
> s/removed/remove
> s/inlined/inline
>
> I was told present tense is preferred for description. Otherwise, I'll
> leave them as is.
I adopted past tenses because at the point at which one is reading the
description of a commit, one is usually reading about old behaviour and
what has been done to change it. However, I wasn't aware that there was
a preference and I am happy to switch to the present tense instead, so
by all means feel free to change them.
J.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] net/netfilter/nf_nat_proto.c - make tables static
From: Pablo Neira Ayuso @ 2019-08-13 9:58 UTC (permalink / raw)
To: Valdis Klētnieks
Cc: Jozsef Kadlecsik, Florian Westphal, netfilter-devel, coreteam,
netdev, linux-kernel
In-Reply-To: <55481.1565243002@turing-police>
On Thu, Aug 08, 2019 at 01:43:22AM -0400, Valdis Klētnieks wrote:
> Sparse warns about two tables not being declared.
>
> CHECK net/netfilter/nf_nat_proto.c
> net/netfilter/nf_nat_proto.c:725:26: warning: symbol 'nf_nat_ipv4_ops' was not declared. Should it be static?
> net/netfilter/nf_nat_proto.c:964:26: warning: symbol 'nf_nat_ipv6_ops' was not declared. Should it be static?
>
> And in fact they can indeed be static.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net/netfilter - add missing prototypes.
From: Pablo Neira Ayuso @ 2019-08-13 9:56 UTC (permalink / raw)
To: Valdis Klētnieks
Cc: Jozsef Kadlecsik, Florian Westphal, netfilter-devel, coreteam,
netdev, linux-kernel
In-Reply-To: <54079.1565242088@turing-police>
On Thu, Aug 08, 2019 at 01:28:08AM -0400, Valdis Klētnieks wrote:
> Sparse rightly complains about undeclared symbols.
>
> CHECK net/netfilter/nft_set_hash.c
> net/netfilter/nft_set_hash.c:647:21: warning: symbol 'nft_set_rhash_type' was not declared. Should it be static?
> net/netfilter/nft_set_hash.c:670:21: warning: symbol 'nft_set_hash_type' was not declared. Should it be static?
> net/netfilter/nft_set_hash.c:690:21: warning: symbol 'nft_set_hash_fast_type' was not declared. Should it be static?
> CHECK net/netfilter/nft_set_bitmap.c
> net/netfilter/nft_set_bitmap.c:296:21: warning: symbol 'nft_set_bitmap_type' was not declared. Should it be static?
> CHECK net/netfilter/nft_set_rbtree.c
> net/netfilter/nft_set_rbtree.c:470:21: warning: symbol 'nft_set_rbtree_type' was not declared. Should it be static?
>
> Include nf_tables_core.h rather than nf_tables.h to pick up the additional definitions.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v1 0/8] netfilter: header compilation fixes
From: Pablo Neira Ayuso @ 2019-08-13 9:55 UTC (permalink / raw)
To: Jeremy Sowden; +Cc: Netfilter Devel, Net Dev, Masahiro Yamada
In-Reply-To: <20190807141705.4864-1-jeremy@azazel.net>
On Wed, Aug 07, 2019 at 03:16:57PM +0100, Jeremy Sowden wrote:
> A number of netfilter header files are on the header-test blacklist
> becuse they cannot be compiled stand-alone. There are two main reasons
> for this: missing inclusions of other headers, and missing conditionals
> checking for CONFIG_* symbols.
>
> The first six of these patches rectify these omissions, the seventh
> removes some unnecessary "#ifdef __KERNEL__" checks, and the last
> removes all the NF headers from the blacklist.
>
> I've cc'ed Masahiro Yamada because the last patch removes 74 lines from
> include/Kbuild and may conflict with his kbuild tree.
Series applied, one comment below.
> Jeremy Sowden (8):
> netfilter: inlined four headers files into another one.
> netfilter: added missing includes to a number of header-files.
> netfilter: added missing IS_ENABLED(CONFIG_BRIDGE_NETFILTER) checks to
> header-file.
> netfilter: added missing IS_ENABLED(CONFIG_NF_TABLES) check to
> header-file.
> netfilter: added missing IS_ENABLED(CONFIG_NF_CONNTRACK) checks to
> some header-files.
> netfilter: added missing IS_ENABLED(CONFIG_NETFILTER) checks to some
> header-files.
> netfilter: removed "#ifdef __KERNEL__" guards from some headers.
> kbuild: removed all netfilter headers from header-test blacklist.
Would you mind if - before pushing this out - I do this string
replacement for the patch subject?
s/added/add
s/removed/remove
s/inlined/inline
I was told present tense is preferred for description. Otherwise, I'll
leave them as is.
Thanks.
^ permalink raw reply
* Re: [PATCH v4 3/9] nvmem: core: add nvmem_device_find
From: Srinivas Kandagatla @ 2019-08-13 9:40 UTC (permalink / raw)
To: Thomas Bogendoerfer, Ralf Baechle, Paul Burton, James Hogan,
Dmitry Torokhov, Lee Jones, David S. Miller, Alessandro Zummo,
Alexandre Belloni, Greg Kroah-Hartman, Jiri Slaby,
Evgeniy Polyakov, linux-mips, linux-kernel, linux-input, netdev,
linux-rtc, linux-serial
In-Reply-To: <20190809103235.16338-4-tbogendoerfer@suse.de>
On 09/08/2019 11:32, Thomas Bogendoerfer wrote:
> nvmem_device_find provides a way to search for nvmem devices with
> the help of a match function simlair to bus_find_device.
>
> Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
> ---
> drivers/nvmem/core.c | 62 ++++++++++++++++++++++--------------------
> include/linux/nvmem-consumer.h | 9 ++++++
> 2 files changed, 41 insertions(+), 30 deletions(-)
Have you considered using nvmem_register_notifier() ?
--srini
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in usbnet_generic_cdc_bind
From: Oliver Neukum @ 2019-08-13 9:27 UTC (permalink / raw)
To: Andrey Konovalov, syzbot
Cc: David S. Miller, syzkaller-bugs, Alan Stern, LKML, USB list,
netdev
In-Reply-To: <CAAeHK+wELVfuQPJaOeG7KggR2BDTOuzCYLC+dzqbhrRRPNf9cA@mail.gmail.com>
Am Montag, den 12.08.2019, 14:27 +0200 schrieb Andrey Konovalov:
> On
> This one is funny, we do sizeof(struct usb_cdc_mdlm_desc *) instead of
> sizeof(struct usb_cdc_mdlm_desc) and the same for
> usb_cdc_mdlm_detail_desc in cdc_parse_cdc_header().
You are right. Old copy & paste error presumably.
Patch is on the way.
Regards
Oliver
^ permalink raw reply
* Re: [PATCH v3 11/17] qca: no need to check return value of debugfs_create functions
From: Stefan Wahren @ 2019-08-13 9:21 UTC (permalink / raw)
To: Greg Kroah-Hartman, netdev; +Cc: David S. Miller, Michael Heimpold, Yangtao Li
In-Reply-To: <20190810101732.26612-12-gregkh@linuxfoundation.org>
On 10.08.19 12:17, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Stefan Wahren <stefan.wahren@i2se.com>
> Cc: Michael Heimpold <michael.heimpold@i2se.com>
> Cc: Yangtao Li <tiny.windzz@gmail.com>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
^ permalink raw reply
* [PATCH] cxgb4: fix a memory leak bug
From: Wenwen Wang @ 2019-08-13 9:18 UTC (permalink / raw)
To: Wenwen Wang
Cc: Vishal Kulkarni, David S. Miller,
open list:CXGB4 ETHERNET DRIVER (CXGB4), open list
In blocked_fl_write(), 't' is not deallocated if bitmap_parse_user() fails,
leading to a memory leak bug. To fix this issue, free t before returning
the error.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index 0295903..d692251 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -3236,8 +3236,10 @@ static ssize_t blocked_fl_write(struct file *filp, const char __user *ubuf,
return -ENOMEM;
err = bitmap_parse_user(ubuf, count, t, adap->sge.egr_sz);
- if (err)
+ if (err) {
+ kvfree(t);
return err;
+ }
bitmap_copy(adap->sge.blocked_fl, t, adap->sge.egr_sz);
kvfree(t);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 bpf-next] mm: mmap: increase sockets maximum memory size pgoff for 32bits
From: Ivan Khoronzhuk @ 2019-08-13 9:12 UTC (permalink / raw)
To: Magnus Karlsson
Cc: Björn Töpel, linux-mm, Xdp, Network Development, bpf,
linux-kernel, akpm, Alexei Starovoitov, Karlsson, Magnus
In-Reply-To: <CAJ8uoz0bBhdQSocQz8Y9tvrGCsCE9TDf3m1u6=sL4Eo5tZ17YQ@mail.gmail.com>
On Tue, Aug 13, 2019 at 10:02:54AM +0200, Magnus Karlsson wrote:
>On Mon, Aug 12, 2019 at 2:45 PM Ivan Khoronzhuk
><ivan.khoronzhuk@linaro.org> wrote:
>>
>> The AF_XDP sockets umem mapping interface uses XDP_UMEM_PGOFF_FILL_RING
>> and XDP_UMEM_PGOFF_COMPLETION_RING offsets. The offsets seems like are
>> established already and are part of configuration interface.
>>
>> But for 32-bit systems, while AF_XDP socket configuration, the values
>> are to large to pass maximum allowed file size verification.
>> The offsets can be tuned ofc, but instead of changing existent
>> interface - extend max allowed file size for sockets.
>
>Can you use mmap2() instead that takes a larger offset (2^44) even on
>32-bit systems?
That's for mmap2.
>
>/Magnus
>
>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>> ---
>>
>> Based on bpf-next/master
>>
>> v2..v1:
>> removed not necessarily #ifdev as ULL and UL for 64 has same size
>>
>> mm/mmap.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index 7e8c3e8ae75f..578f52812361 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -1358,6 +1358,9 @@ static inline u64 file_mmap_size_max(struct file *file, struct inode *inode)
>> if (S_ISBLK(inode->i_mode))
>> return MAX_LFS_FILESIZE;
>>
>> + if (S_ISSOCK(inode->i_mode))
>> + return MAX_LFS_FILESIZE;
>> +
>> /* Special "we do even unsigned file positions" case */
>> if (file->f_mode & FMODE_UNSIGNED_OFFSET)
>> return 0;
>> --
>> 2.17.1
>>
--
Regards,
Ivan Khoronzhuk
^ 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