* Re: [PATCH] bpf: devmap: Check attr->max_entries more carefully
From: Daniel Borkmann @ 2017-10-17 10:32 UTC (permalink / raw)
To: Mark Rutland
Cc: Richard Weinberger, netdev, linux-kernel, ast, sp3485, tj,
john.fastabend
In-Reply-To: <20171017102935.5i4dqa7h44v4acft@lakrids.cambridge.arm.com>
On 10/17/2017 12:29 PM, Mark Rutland wrote:
> On Mon, Oct 16, 2017 at 08:52:13PM +0200, Daniel Borkmann wrote:
>> [ +Tejun, Mark, John ]
>>
>> On 10/16/2017 12:00 AM, Richard Weinberger wrote:
>>> max_entries is user controlled and used as input for __alloc_percpu().
>>> This function expects that the allocation size is a power of two and
>>> less than PCPU_MIN_UNIT_SIZE.
>>> Otherwise a WARN() is triggered.
>>>
>>> Fixes: 11393cc9b9be ("xdp: Add batching support to redirect map")
>>> Reported-by: Shankara Pailoor <sp3485@columbia.edu>
>>> Reported-by: syzkaller <syzkaller@googlegroups.com>
>>> Signed-off-by: Richard Weinberger <richard@nod.at>
>>
>> Thanks for the patch, Richard. There was a prior discussion here [1] on
>> the same issue, I thought this would have been resolved by now, but looks
>> like it's still open and there was never a follow-up, at least I don't see
>> it in the percpu tree if I didn't miss anything.
>
> Sorry, this was on my todo list, but I've been bogged down with some
> other work.
Ok, no problem.
>> I would suggest, we do the following below and pass __GFP_NOWARN from BPF
>> side to the per-cpu allocs. This is kind of a generic 'issue' and we shouldn't
>> add more code which bails out anyway just to work around the WARN(). Lets
>> handle it properly instead.
>
> Agreed. The below patch looks good to me, (with the suggested change to
> the BPF side).
>
>> If Tejun is fine with the one below, I could cook and official patch and
>> cleanup the remaining call-sites from BPF which have similar pattern.
>
> That would be great; thanks for taking this on.
I'll prepare a set including BPF side for today.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 07/58] net/usb/usbnet: Convert timers to use timer_setup()
From: Oliver Neukum @ 2017-10-17 10:30 UTC (permalink / raw)
To: Kees Cook, David S. Miller
Cc: Thomas Gleixner, linux-kernel, linux-usb, netdev
In-Reply-To: <1508200182-104605-8-git-send-email-keescook@chromium.org>
Am Montag, den 16.10.2017, 17:28 -0700 schrieb Kees Cook:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly. Since the callback is called from
> both a timer and a tasklet, adjust the tasklet to pass the timer address
> too. When tasklets have their .data field removed, this can be refactored
> to call a central function after resolving the correct container_of() for a
> separate callback function for timer and tasklet.
>
> Cc: Oliver Neukum <oneukum@suse.com>
> Cc: netdev@vger.kernel.org
> Cc: linux-usb@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Oliver Neukum <oneukum@suse.com>
^ permalink raw reply
* Re: [PATCH] bpf: devmap: Check attr->max_entries more carefully
From: Mark Rutland @ 2017-10-17 10:29 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Richard Weinberger, netdev, linux-kernel, ast, sp3485, tj,
john.fastabend
In-Reply-To: <59E4FFDD.7010402@iogearbox.net>
On Mon, Oct 16, 2017 at 08:52:13PM +0200, Daniel Borkmann wrote:
> [ +Tejun, Mark, John ]
>
> On 10/16/2017 12:00 AM, Richard Weinberger wrote:
> > max_entries is user controlled and used as input for __alloc_percpu().
> > This function expects that the allocation size is a power of two and
> > less than PCPU_MIN_UNIT_SIZE.
> > Otherwise a WARN() is triggered.
> >
> > Fixes: 11393cc9b9be ("xdp: Add batching support to redirect map")
> > Reported-by: Shankara Pailoor <sp3485@columbia.edu>
> > Reported-by: syzkaller <syzkaller@googlegroups.com>
> > Signed-off-by: Richard Weinberger <richard@nod.at>
>
> Thanks for the patch, Richard. There was a prior discussion here [1] on
> the same issue, I thought this would have been resolved by now, but looks
> like it's still open and there was never a follow-up, at least I don't see
> it in the percpu tree if I didn't miss anything.
Sorry, this was on my todo list, but I've been bogged down with some
other work.
> I would suggest, we do the following below and pass __GFP_NOWARN from BPF
> side to the per-cpu allocs. This is kind of a generic 'issue' and we shouldn't
> add more code which bails out anyway just to work around the WARN(). Lets
> handle it properly instead.
Agreed. The below patch looks good to me, (with the suggested change to
the BPF side).
> If Tejun is fine with the one below, I could cook and official patch and
> cleanup the remaining call-sites from BPF which have similar pattern.
That would be great; thanks for taking this on.
Thanks,
Mark.
>
> [1] https://patchwork.kernel.org/patch/9975851/
>
> Thanks,
> Daniel
>
> mm/percpu.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/mm/percpu.c b/mm/percpu.c
> index 59d44d6..5d9414e 100644
> --- a/mm/percpu.c
> +++ b/mm/percpu.c
> @@ -1357,7 +1357,8 @@ static void __percpu *pcpu_alloc(size_t size, size_t align, bool reserved,
>
> if (unlikely(!size || size > PCPU_MIN_UNIT_SIZE || align > PAGE_SIZE ||
> !is_power_of_2(align))) {
> - WARN(true, "illegal size (%zu) or align (%zu) for percpu allocation\n",
> + WARN(!(gfp & __GFP_NOWARN),
> + "illegal size (%zu) or align (%zu) for percpu allocation\n",
> size, align);
> return NULL;
> }
> @@ -1478,7 +1479,7 @@ static void __percpu *pcpu_alloc(size_t size, size_t align, bool reserved,
> fail:
> trace_percpu_alloc_percpu_fail(reserved, is_atomic, size, align);
>
> - if (!is_atomic && warn_limit) {
> + if (!is_atomic && warn_limit && !(gfp & __GFP_NOWARN)) {
> pr_warn("allocation failed, size=%zu align=%zu atomic=%d, %s\n",
> size, align, is_atomic, err);
> dump_stack();
> --
> 1.9.3
^ permalink raw reply
* Re: [PATCH net 0/3] bonding: void calling rtmsg_ifinfo for netlink notifications
From: Xin Long @ 2017-10-17 10:28 UTC (permalink / raw)
To: Jiri Pirko; +Cc: network dev, davem
In-Reply-To: <20171017095943.GE2112@nanopsycho>
On Tue, Oct 17, 2017 at 5:59 PM, Jiri Pirko <jiri@resnulli.us> wrote:
> Tue, Oct 17, 2017 at 11:39:38AM CEST, lucien.xin@gmail.com wrote:
>>It's better to send notifications to userspace by the events
>>in rtnetlink_event, instead of calling rtmsg_ifinfo directly.
>>
>>This patcheset is to remove rtmsg_ifinfo called in bonding,
>>the notifications can be handled by NETDEV_CHANGEUPPER and
>>NETDEV_CHANGELOWERSTATE events in rtnetlink_event.
>>
>>It could also fix some redundant notifications from bonding.
>
> This should go to net-next.
NETDEV_CHANGEUPPER is not yet in rtnetlink_event in net-next tree.
patches can only work on net tree by now.
Hi, David, you want me to hold them until the patches for NETDEV_CHANGEUPPER
are copied to net-next, or you would apply them to net ?
>
>
>>
>>Xin Long (3):
>> bonding: remove rtmsg_ifinfo called in bond_master_upper_dev_link
>> rtnetlink: bring NETDEV_CHANGELOWERSTATE event process back to
>> rtnetlink_event
>> bonding: remove rtmsg_ifinfo called after bond_lower_state_changed
>>
>> drivers/net/bonding/bond_main.c | 11 +++--------
>> include/net/bonding.h | 4 ----
>> net/core/rtnetlink.c | 2 +-
>> 3 files changed, 4 insertions(+), 13 deletions(-)
>>
>>--
>>2.1.0
>>
^ permalink raw reply
* Re: linux-next: net/sched/cls_flower.c
From: Mark Brown @ 2017-10-17 10:27 UTC (permalink / raw)
To: Jiri Pirko
Cc: David Miller, Networking, Or Gerlitz, Roi Dayan, Jiri Pirko,
Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20171017102107.GF2112@nanopsycho>
[-- Attachment #1: Type: text/plain, Size: 934 bytes --]
On Tue, Oct 17, 2017 at 12:21:07PM +0200, Jiri Pirko wrote:
> Tue, Oct 17, 2017 at 12:15:09PM CEST, broonie@kernel.org wrote:
> >/home/broonie/tmpfs/next/net/sched/cls_flower.c:270:27: error: 'struct cls_fl_filter' has no member named 'hw_dev'
> > cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
> This fix ("net/sched: cls_flower: Set egress_dev mark when calling into the HW driver")
> went to -net tree, should not go to -next. Apparently there is some mixup.
> DaveM?
The issue is that:
> > 7578d7b45ed870b1 ("net: sched: remove unused tcf_exts_get_dev helper and cls_flower->egress_dev")
> >both in the net-next tree. Falling back to previous net-next trees
> >introduced other issues so I reverted that commit for today.
the removal happened in the net-next tree, breaking the commit that was
previously introduced in the net tree (sorry, didn't notice that the
immediate commit was in there not net-next).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: net/sched/cls_flower.c
From: Mark Brown @ 2017-10-17 10:26 UTC (permalink / raw)
To: David Miller, Networking, Or Gerlitz, Roi Dayan, Jiri Pirko
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20171017101509.soy55d4ipx3dusbo@sirena.co.uk>
[-- Attachment #1: Type: text/plain, Size: 315 bytes --]
On Tue, Oct 17, 2017 at 11:15:09AM +0100, Mark Brown wrote:
> Caused by commit
>
> 7578d7b45ed870b13a8ace57e32feaed623c2a94 ("net/sched: cls_flower: Set egress_dev mark when calling into the HW driver")
Cut'n'paste error, this should be
c019b5166e11faaf9ed3b64316ed338eaa19de60
Sorry about that.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 11/15] stm class: make config_item_type const
From: Greg KH @ 2017-10-17 10:25 UTC (permalink / raw)
To: Bhumika Goyal
Cc: julia.lawall, rjw, lenb, alexander.shishkin, jic23, knaack.h,
lars, pmeerw, dledford, sean.hefty, hal.rosenstock, hch, sagi,
kishon, bhelgaas, nab, balbi, laurent.pinchart, jlbec, ccaulfie,
teigland, mfasheh, linux-acpi, linux-kernel, linux-iio,
linux-rdma, netdev, linux-nvme, linux-pci, linux-scsi,
target-devel, linux-usb, cluster-devel, ocfs2-devel
In-Reply-To: <1508167134-6243-12-git-send-email-bhumirks@gmail.com>
On Mon, Oct 16, 2017 at 05:18:50PM +0200, Bhumika Goyal wrote:
> Make config_item_type structures const as they are either passed to a
> function having the argument as const or used inside a if statement or
> stored in the const "ci_type" field of a config_item structure.
>
> Done using Coccinelle.
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
> ---
> * Changes in v2- Combine all the followup patches and the constification
> patches into a series.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH v2 01/15] configfs: make ci_type field, some pointers and function arguments const
From: Greg KH @ 2017-10-17 10:24 UTC (permalink / raw)
To: Bhumika Goyal
Cc: julia.lawall, rjw, lenb, alexander.shishkin, jic23, knaack.h,
lars, pmeerw, dledford, sean.hefty, hal.rosenstock, hch, sagi,
kishon, bhelgaas, nab, balbi, laurent.pinchart, jlbec, ccaulfie,
teigland, mfasheh, linux-acpi, linux-kernel, linux-iio,
linux-rdma, netdev, linux-nvme, linux-pci, linux-scsi,
target-devel, linux-usb, cluster-devel, ocfs2-devel
In-Reply-To: <1508167134-6243-2-git-send-email-bhumirks@gmail.com>
On Mon, Oct 16, 2017 at 05:18:40PM +0200, Bhumika Goyal wrote:
> The ci_type field of the config_item structure do not modify the fields
> of the config_item_type structure it points to. And the other pointers
> initialized with ci_type do not modify the fields as well.
> So, make the ci_type field and the pointers initialized with ci_type
> as const.
>
> Make the struct config_item_type *type function argument of functions
> config_{item/group}_init_type_name const as the argument in both the
> functions is only stored in the ci_type field of a config_item structure
> which is now made const.
> Make the argument of configfs_register_default_group const as it is
> only passed to the argument of the function config_group_init_type_name
> which is now const.
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
> ---
> * Changes in v2- Combine all the followup patches and the constification
> patches into a series.
>
> fs/configfs/dir.c | 10 +++++-----
> fs/configfs/item.c | 6 +++---
> fs/configfs/symlink.c | 4 ++--
> include/linux/configfs.h | 8 ++++----
> 4 files changed, 14 insertions(+), 14 deletions(-)
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH v2 00/15] make structure field, function arguments and structures const
From: Greg KH @ 2017-10-17 10:23 UTC (permalink / raw)
To: Julia Lawall
Cc: Bhumika Goyal, rjw-LthD3rsA81gm4RdzfppkhA,
lenb-DgEjT+Ai2ygdnm+yROfE0A,
alexander.shishkin-VuQAYsv1563Yd54FQh9/CA,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w, hch-jcswGhMUV9g,
sagi-NQWnxTmZq1alnMjI0IkVqw, kishon-l0cyMroinI0,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, nab-IzHhD5pYlfBP7FQvKIMDCQ,
balbi-DgEjT+Ai2ygdnm+yROfE0A,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
jlbec-aKy9MeLSZ9dg9hUCZPvPmw, ccaulfie-H+wXaHxf7aLQT0dZR+AlfA,
teigland-H+wXaHxf7aLQT0dZR+AlfA, mfasheh-rOS7oXVqrJRBDgjK7y7TUQ,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
target-devel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
cluster-devel-H+wXaHxf7aLQT0dZR+AlfA, ocfs2-
In-Reply-To: <alpine.DEB.2.20.1710171216060.5035@hadrien>
On Tue, Oct 17, 2017 at 12:16:18PM +0200, Julia Lawall wrote:
>
>
> On Tue, 17 Oct 2017, Greg KH wrote:
>
> > On Mon, Oct 16, 2017 at 05:18:39PM +0200, Bhumika Goyal wrote:
> > > Make the ci_type field and some function arguments as const. After this
> > > change, make config_item_type structures as const.
> > >
> > > * Changes in v2- Combine all the followup patches and the constification
> > > patches into a series.
> >
> > Who do you want to take these patches? If you want, I can take them
> > through my driver-core tree, which has done other configfs stuff like
> > this in the past.
>
> Christoph Hellwig proposed to take care of it.
Great! I'll go ack the individual ones that I might need to...
thanks,
greg k-h
^ permalink raw reply
* [PATCH, net-next] i40e: avoid 64-bit division where possible
From: Arnd Bergmann @ 2017-10-17 10:23 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Arnd Bergmann, Jacob Keller, Mitch Williams, Alexander Duyck,
Amritha Nambiar, Filip Sadowski, David S. Miller,
Björn Töpel, intel-wired-lan, netdev, linux-kernel
The new bandwidth calculation causes a link error on 32-bit
architectures, like
ERROR: "__aeabi_uldivmod" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
The problem is the max_tx_rate calculation that uses 64-bit integers.
This is not really necessary since the numbers are in MBit/s so
they won't be higher than 40000 for the highest support rate, and
are guaranteed to not exceed 2^32 in future generations either.
This changes the representation to 'u32' when dealing with MBit/s
and uses div_u64() to convert from u64 numbers in byte/s.
Fixes: 2027d4deacb1 ("i40e: Add support setting TC max bandwidth rates")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/intel/i40e/i40e.h | 4 ++--
drivers/net/ethernet/intel/i40e/i40e_main.c | 27 ++++++++++++++-------------
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e.h b/drivers/net/ethernet/intel/i40e/i40e.h
index 266e1dc5e786..45155ef15d24 100644
--- a/drivers/net/ethernet/intel/i40e/i40e.h
+++ b/drivers/net/ethernet/intel/i40e/i40e.h
@@ -359,7 +359,7 @@ struct i40e_channel {
u8 enabled_tc;
struct i40e_aqc_vsi_properties_data info;
- u64 max_tx_rate;
+ u32 max_tx_rate; /* in Mbits/s */
/* track this channel belongs to which VSI */
struct i40e_vsi *parent_vsi;
@@ -1045,5 +1045,5 @@ static inline bool i40e_enabled_xdp_vsi(struct i40e_vsi *vsi)
}
int i40e_create_queue_channel(struct i40e_vsi *vsi, struct i40e_channel *ch);
-int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 seid, u64 max_tx_rate);
+int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 seid, u32 max_tx_rate);
#endif /* _I40E_H_ */
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 624a2bc8a1df..e71fece72506 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -5439,7 +5439,7 @@ int i40e_get_link_speed(struct i40e_vsi *vsi)
*
* Helper function to set BW limit for a given VSI
**/
-int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 seid, u64 max_tx_rate)
+int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 seid, u32 max_tx_rate)
{
struct i40e_pf *pf = vsi->back;
int speed = 0;
@@ -5448,7 +5448,7 @@ int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 seid, u64 max_tx_rate)
speed = i40e_get_link_speed(vsi);
if (max_tx_rate > speed) {
dev_err(&pf->pdev->dev,
- "Invalid max tx rate %llu specified for VSI seid %d.",
+ "Invalid max tx rate %u specified for VSI seid %d.",
max_tx_rate, seid);
return -EINVAL;
}
@@ -5464,7 +5464,7 @@ int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 seid, u64 max_tx_rate)
I40E_MAX_BW_INACTIVE_ACCUM, NULL);
if (ret)
dev_err(&pf->pdev->dev,
- "Failed set tx rate (%llu Mbps) for vsi->seid %u, err %s aq_err %s\n",
+ "Failed set tx rate (%u Mbps) for vsi->seid %u, err %s aq_err %s\n",
max_tx_rate, seid, i40e_stat_str(&pf->hw, ret),
i40e_aq_str(&pf->hw, pf->hw.aq.asq_last_status));
return ret;
@@ -6067,7 +6067,7 @@ int i40e_create_queue_channel(struct i40e_vsi *vsi,
return -EINVAL;
dev_dbg(&pf->pdev->dev,
- "Set tx rate of %llu Mbps (count of 50Mbps %llu) for vsi->seid %u\n",
+ "Set tx rate of %u Mbps (count of 50Mbps %u) for vsi->seid %u\n",
ch->max_tx_rate,
ch->max_tx_rate / I40E_BW_CREDIT_DIVISOR, ch->seid);
}
@@ -6110,8 +6110,8 @@ static int i40e_configure_queue_channels(struct i40e_vsi *vsi)
/* Bandwidth limit through tc interface is in bytes/s,
* change to Mbit/s
*/
- ch->max_tx_rate =
- vsi->mqprio_qopt.max_rate[i] / (1000000 / 8);
+ ch->max_tx_rate = div_u64(vsi->mqprio_qopt.max_rate[i],
+ 1000000 / 8);
list_add_tail(&ch->list, &vsi->ch_list);
@@ -6554,7 +6554,7 @@ static int i40e_validate_mqprio_qopt(struct i40e_vsi *vsi,
"Invalid min tx rate (greater than 0) specified\n");
return -EINVAL;
}
- sum_max_rate += (mqprio_qopt->max_rate[i] / (1000000 / 8));
+ sum_max_rate += div_u64(mqprio_qopt->max_rate[i], 1000000 / 8);
if (i >= mqprio_qopt->qopt.num_tc - 1)
break;
@@ -6698,12 +6698,12 @@ static int i40e_setup_tc(struct net_device *netdev, void *type_data)
if (pf->flags & I40E_FLAG_TC_MQPRIO) {
if (vsi->mqprio_qopt.max_rate[0]) {
- u64 max_tx_rate = vsi->mqprio_qopt.max_rate[0] /
- (1000000 / 8);
+ u32 max_tx_rate = div_u64(vsi->mqprio_qopt.max_rate[0],
+ 1000000 / 8);
ret = i40e_set_bw_limit(vsi, vsi->seid, max_tx_rate);
if (!ret) {
dev_dbg(&vsi->back->pdev->dev,
- "Set tx rate of %llu Mbps (count of 50Mbps %llu) for vsi->seid %u\n",
+ "Set tx rate of %u Mbps (count of 50Mbps %u) for vsi->seid %u\n",
max_tx_rate,
max_tx_rate / I40E_BW_CREDIT_DIVISOR,
vsi->seid);
@@ -8171,7 +8171,7 @@ static int i40e_rebuild_channels(struct i40e_vsi *vsi)
return -EINVAL;
dev_dbg(&vsi->back->pdev->dev,
- "Set tx rate of %llu Mbps (count of 50Mbps %llu) for vsi->seid %u\n",
+ "Set tx rate of %u Mbps (count of 50Mbps %u) for vsi->seid %u\n",
ch->max_tx_rate,
ch->max_tx_rate / I40E_BW_CREDIT_DIVISOR,
ch->seid);
@@ -8446,12 +8446,13 @@ static void i40e_rebuild(struct i40e_pf *pf, bool reinit, bool lock_acquired)
}
if (vsi->mqprio_qopt.max_rate[0]) {
- u64 max_tx_rate = vsi->mqprio_qopt.max_rate[0] / (1000000 / 8);
+ u32 max_tx_rate = div_u64(vsi->mqprio_qopt.max_rate[0],
+ 1000000 / 8);
ret = i40e_set_bw_limit(vsi, vsi->seid, max_tx_rate);
if (!ret)
dev_dbg(&vsi->back->pdev->dev,
- "Set tx rate of %llu Mbps (count of 50Mbps %llu) for vsi->seid %u\n",
+ "Set tx rate of %u Mbps (count of 50Mbps %u) for vsi->seid %u\n",
max_tx_rate,
max_tx_rate / I40E_BW_CREDIT_DIVISOR,
vsi->seid);
--
2.9.0
^ permalink raw reply related
* Re: linux-next: net/sched/cls_flower.c
From: Jiri Pirko @ 2017-10-17 10:21 UTC (permalink / raw)
To: Mark Brown
Cc: David Miller, Networking, Or Gerlitz, Roi Dayan, Jiri Pirko,
Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20171017101509.soy55d4ipx3dusbo@sirena.co.uk>
Tue, Oct 17, 2017 at 12:15:09PM CEST, broonie@kernel.org wrote:
>Hi all,
>
>After merging the net-next tree, today's linux-next build
>(x86_allmodconfig) failed like this:
>
>/home/broonie/tmpfs/next/net/sched/cls_flower.c: In function 'fl_hw_destroy_filter':
>/home/broonie/tmpfs/next/net/sched/cls_flower.c:208:12: error: 'struct tc_cls_flower_offload' has no member named 'egress_dev'
> cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
> ^
>/home/broonie/tmpfs/next/net/sched/cls_flower.c:208:27: error: 'struct cls_fl_filter' has no member named 'hw_dev'
> cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
> ^
>/home/broonie/tmpfs/next/net/sched/cls_flower.c: In function 'fl_hw_update_stats':
>/home/broonie/tmpfs/next/net/sched/cls_flower.c:270:12: error: 'struct tc_cls_flower_offload' has no member named 'egress_dev'
> cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
> ^
>/home/broonie/tmpfs/next/net/sched/cls_flower.c:270:27: error: 'struct cls_fl_filter' has no member named 'hw_dev'
> cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
This fix ("net/sched: cls_flower: Set egress_dev mark when calling into the HW driver")
went to -net tree, should not go to -next. Apparently there is some mixup.
DaveM?
> ^
>/home/broonie/tmpfs/next/scripts/Makefile.build:319: recipe for target 'net/sched/cls_flower.o' failed
>
>Caused by commit
>
> 7578d7b45ed870b13a8ace57e32feaed623c2a94 ("net/sched: cls_flower: Set egress_dev mark when calling into the HW driver")
>
>interacting with
>
> 7578d7b45ed870b1 ("net: sched: remove unused tcf_exts_get_dev helper and cls_flower->egress_dev")
>
>both in the net-next tree. Falling back to previous net-next trees
>introduced other issues so I reverted that commit for today.
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: sh_eth: implement R-Car Gen[12] fallback compatibility strings
From: Sergei Shtylyov @ 2017-10-17 10:20 UTC (permalink / raw)
To: Simon Horman, David Miller; +Cc: Magnus Damm, netdev, linux-renesas-soc
In-Reply-To: <20171017074747.24159-4-horms+renesas@verge.net.au>
On 10/17/2017 10:47 AM, Simon Horman wrote:
> Implement fallback compatibility strings for R-Car Gen 1 and 2.
>
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship
> between IP blocks might be. For example, I believe that r8a7790 is older
> than r8a7791 but that doesn't imply that the latter is a descendant of the
> former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
>
> Note that R-Car Gen2 and RZ/G1 have many compatible IP blocks. The
> approach that has been consistently taken for other IP blocks is to name
> common code, compatibility strings and so on after Rcar Gen2.
R-Car again. :-)
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Re: Linux 4.12+ memory leak on router with i40e NICs
From: Paweł Staszewski @ 2017-10-17 10:20 UTC (permalink / raw)
To: Alexander Duyck
Cc: Pavlos Parissis, Anders K. Pedersen | Cohaesio,
netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
alexander.h.duyck@intel.com
In-Reply-To: <f6e2208a-4cdf-3303-5999-92186b437b62@itcare.pl>
W dniu 2017-10-17 o 11:48, Paweł Staszewski pisze:
>
>
> W dniu 2017-10-17 o 02:44, Paweł Staszewski pisze:
>>
>>
>> W dniu 2017-10-17 o 01:56, Alexander Duyck pisze:
>>> On Mon, Oct 16, 2017 at 4:34 PM, Paweł Staszewski
>>> <pstaszewski@itcare.pl> wrote:
>>>>
>>>> W dniu 2017-10-16 o 18:26, Paweł Staszewski pisze:
>>>>
>>>>>
>>>>> W dniu 2017-10-16 o 13:20, Pavlos Parissis pisze:
>>>>>> On 15/10/2017 02:58 πμ, Alexander Duyck wrote:
>>>>>>> Hi Pawel,
>>>>>>>
>>>>>>> To clarify is that Dave Miller's tree or Linus's that you are
>>>>>>> talking
>>>>>>> about? If it is Dave's tree how long ago was it you pulled it
>>>>>>> since I
>>>>>>> think the fix was just pushed by Jeff Kirsher a few days ago.
>>>>>>>
>>>>>>> The issue should be fixed in the following commit:
>>>>>>>
>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/drivers/net/ethernet/intel/i40e/i40e_txrx.c?id=2b9478ffc550f17c6cd8c69057234e91150f5972
>>>>>>>
>>>>>>>
>>>>>> Do you know when it is going to be available on net-next and
>>>>>> linux-stable
>>>>>> repos?
>>>>>>
>>>>>> Cheers,
>>>>>> Pavlos
>>>>>>
>>>>>>
>>>>> I will make some tests today night with "net" git tree where this
>>>>> patch is
>>>>> included.
>>>>> Starting from 0:00 CET
>>>>> :)
>>>>>
>>>>>
>>>> Upgraded and looks like problem is not solved with that patch
>>>> Currently running system with
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/
>>>> kernel
>>>>
>>>> Still about 0.5GB of memory is leaking somewhere
>>>>
>>>> Also can confirm that the latest kernel where memory is not leaking
>>>> (with
>>>> use i40e driver intel 710 cards) is 4.11.12
>>>> With kernel 4.11.12 - after hour no change in memory usage.
>>>>
>>>> also checked that with ixgbe instead of i40e with same net.git
>>>> kernel there
>>>> is no memleak - after hour same memory usage - so for 100% this is
>>>> i40e
>>>> driver problem.
>>> So how long was the run to get the .5GB of memory leaking?
>> 1 hour
>>
>>>
>>> Also is there any chance of you being able to bisect to determine
>>> where the memory leak was introduced since as you pointed out it
>>> didn't exist in 4.11.12 so odds are it was introduced somewhere
>>> between 4.11 and the latest kernel release.
>> Can be hard cause currently need to back to 4.11.12 - this is
>> production host/router
>> Will try to find some free/test router for tests/bicects with i40e
>> driver (intel 710 cards)
>>
>>>
>>> Thanks.
>>>
>>> - Alex
>>>
>>
>>
> Also forgoto to add errors for i40e when driver initialize:
> [ 15.760569] i40e 0000:02:00.1: Error I40E_AQ_RC_ENOSPC adding RX
> filters on PF, promiscuous mode forced on
> [ 16.365587] i40e 0000:03:00.3: Error I40E_AQ_RC_ENOSPC adding RX
> filters on PF, promiscuous mode forced on
> [ 16.367686] i40e 0000:02:00.2: Error I40E_AQ_RC_ENOSPC adding RX
> filters on PF, promiscuous mode forced on
> [ 16.368816] i40e 0000:03:00.0: Error I40E_AQ_RC_ENOSPC adding RX
> filters on PF, promiscuous mode forced on
> [ 16.369877] i40e 0000:03:00.2: Error I40E_AQ_RC_ENOSPC adding RX
> filters on PF, promiscuous mode forced on
> [ 16.370941] i40e 0000:02:00.3: Error I40E_AQ_RC_ENOSPC adding RX
> filters on PF, promiscuous mode forced on
> [ 16.372005] i40e 0000:02:00.0: Error I40E_AQ_RC_ENOSPC adding RX
> filters on PF, promiscuous mode forced on
> [ 16.373029] i40e 0000:03:00.1: Error I40E_AQ_RC_ENOSPC adding RX
> filters on PF, promiscuous mode forced on
>
> some params that are set for this nic's
> ip link set up dev $i
> ethtool -A $i autoneg off rx off tx off
> ethtool -G $i rx 1024 tx 2048
> ip link set $i txqueuelen 1000
> ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 512
> tx-usecs 128
> ethtool -L $i combined 6
> #ethtool -N $i rx-flow-hash udp4 sdfn
> ethtool -K $i ntuple on
> ethtool -K $i gro off
> ethtool -K $i tso off
>
>
>
>
Also after TSO/GRO on there is memory usage change - and leaking faster
Below image from memory usage before change with TSO/GRO OFF and after
enabling TSO/GRO
https://ibb.co/dTqBY6
Thanks
Pawel
^ permalink raw reply
* Re: [PATCH net-next 1/3] dt-bindings: net: sh_eth: add R-Car Gen[12] fallback compatibility strings
From: Sergei Shtylyov @ 2017-10-17 10:18 UTC (permalink / raw)
To: Simon Horman, David Miller; +Cc: Magnus Damm, netdev, linux-renesas-soc
In-Reply-To: <20171017074747.24159-2-horms+renesas@verge.net.au>
On 10/17/2017 10:47 AM, Simon Horman wrote:
> Add fallback compatibility strings for R-Car Gen 1 and 2.
>
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship
> between IP blocks might be. For example, I believe that r8a7790 is older
> than r8a7791 but that doesn't imply that the latter is a descendant of the
> former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
>
> Note that R-Car Gen2 and RZ/G1 have many compatible IP blocks. The
> approach that has been consistently taken for other IP blocks is to name
> common code, compatibility strings and so on after Rcar Gen2.
R-Car here too. :-)
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 08/15] nvmet: make config_item_type const
From: Sagi Grimberg @ 2017-10-17 10:18 UTC (permalink / raw)
To: Bhumika Goyal, julia.lawall, rjw, lenb, alexander.shishkin, jic23,
knaack.h, lars, pmeerw, dledford, sean.hefty, hal.rosenstock, hch,
kishon, bhelgaas, nab, balbi, gregkh, laurent.pinchart, jlbec,
ccaulfie, teigland, mfasheh, linux-acpi, linux-kernel, linux-iio,
linux-rdma, netdev, linux-nvme, linux-pci, linux-scsi,
target-devel, linux-usb
In-Reply-To: <1508167134-6243-9-git-send-email-bhumirks@gmail.com>
Acked-by: Sagi Grimberg <sagi@grimberg.me>
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: sh_eth: rename name structures as rcar_gen[12]_*
From: Sergei Shtylyov @ 2017-10-17 10:17 UTC (permalink / raw)
To: Simon Horman, David Miller; +Cc: Magnus Damm, netdev, linux-renesas-soc
In-Reply-To: <20171017074747.24159-3-horms+renesas@verge.net.au>
Hello!
On 10/17/2017 10:47 AM, Simon Horman wrote:
> Rename structures describing R-Car SoCs as rcar_gen[12]_*
> rather than r8a77[79]x_*. This seems a little easier on the
> eyes will make things slightly cleaner in a follow-up
^
"And" missing here?
> patch that adds fallback-compatibility strings for these SoCs.
>
> Note that R-Car Gen2 and RZ/G1 have many compatible IP blocks. The
> approach that has been consistently taken for other IP blocks is to name
> common code, compatibility strings and so on after Rcar Gen2.
R-Car.
> Also rename sh_eth_set_rate_r8a777x as sh_eth_set_rate_rcar as
> it it is used by the R-Car generations supported by the driver.
>
> This patch should have no run-time effect and
> is compile-tested only.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
[...]
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 00/15] make structure field, function arguments and structures const
From: Julia Lawall @ 2017-10-17 10:16 UTC (permalink / raw)
To: Greg KH
Cc: Bhumika Goyal, julia.lawall, rjw, lenb, alexander.shishkin, jic23,
knaack.h, lars, pmeerw, dledford, sean.hefty, hal.rosenstock, hch,
sagi, kishon, bhelgaas, nab, balbi, laurent.pinchart, jlbec,
ccaulfie, teigland, mfasheh, linux-acpi, linux-kernel, linux-iio,
linux-rdma, netdev, linux-nvme, linux-pci, linux-scsi,
target-devel, linux-usb, cluster-de
In-Reply-To: <20171017101245.GA4646@kroah.com>
On Tue, 17 Oct 2017, Greg KH wrote:
> On Mon, Oct 16, 2017 at 05:18:39PM +0200, Bhumika Goyal wrote:
> > Make the ci_type field and some function arguments as const. After this
> > change, make config_item_type structures as const.
> >
> > * Changes in v2- Combine all the followup patches and the constification
> > patches into a series.
>
> Who do you want to take these patches? If you want, I can take them
> through my driver-core tree, which has done other configfs stuff like
> this in the past.
Christoph Hellwig proposed to take care of it.
julia
>
> thanks,
>
> greg k-h
>
^ permalink raw reply
* linux-next: net/sched/cls_flower.c
From: Mark Brown @ 2017-10-17 10:15 UTC (permalink / raw)
To: David Miller, Networking, Or Gerlitz, Roi Dayan, Jiri Pirko
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]
Hi all,
After merging the net-next tree, today's linux-next build
(x86_allmodconfig) failed like this:
/home/broonie/tmpfs/next/net/sched/cls_flower.c: In function 'fl_hw_destroy_filter':
/home/broonie/tmpfs/next/net/sched/cls_flower.c:208:12: error: 'struct tc_cls_flower_offload' has no member named 'egress_dev'
cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
^
/home/broonie/tmpfs/next/net/sched/cls_flower.c:208:27: error: 'struct cls_fl_filter' has no member named 'hw_dev'
cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
^
/home/broonie/tmpfs/next/net/sched/cls_flower.c: In function 'fl_hw_update_stats':
/home/broonie/tmpfs/next/net/sched/cls_flower.c:270:12: error: 'struct tc_cls_flower_offload' has no member named 'egress_dev'
cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
^
/home/broonie/tmpfs/next/net/sched/cls_flower.c:270:27: error: 'struct cls_fl_filter' has no member named 'hw_dev'
cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
^
/home/broonie/tmpfs/next/scripts/Makefile.build:319: recipe for target 'net/sched/cls_flower.o' failed
Caused by commit
7578d7b45ed870b13a8ace57e32feaed623c2a94 ("net/sched: cls_flower: Set egress_dev mark when calling into the HW driver")
interacting with
7578d7b45ed870b1 ("net: sched: remove unused tcf_exts_get_dev helper and cls_flower->egress_dev")
both in the net-next tree. Falling back to previous net-next trees
introduced other issues so I reverted that commit for today.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 1/3] dt-bindings: net: sh_eth: add R-Car Gen[12] fallback compatibility strings
From: Sergei Shtylyov @ 2017-10-17 10:14 UTC (permalink / raw)
To: Simon Horman, David Miller; +Cc: Magnus Damm, netdev, linux-renesas-soc
In-Reply-To: <20171017074747.24159-2-horms+renesas@verge.net.au>
Hello!
On 10/17/2017 10:47 AM, Simon Horman wrote:
> Add fallback compatibility strings for R-Car Gen 1 and 2.
>
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship
> between IP blocks might be. For example, I believe that r8a7790 is older
> than r8a7791 but that doesn't imply that the latter is a descendant of the
> former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
>
> Note that R-Car Gen2 and RZ/G1 have many compatible IP blocks. The
> approach that has been consistently taken for other IP blocks is to name
> common code, compatibility strings and so on after Rcar Gen2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> ---
> Documentation/devicetree/bindings/net/sh_eth.txt | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/sh_eth.txt b/Documentation/devicetree/bindings/net/sh_eth.txt
> index 0115c85a2425..48cab94dd056 100644
> --- a/Documentation/devicetree/bindings/net/sh_eth.txt
> +++ b/Documentation/devicetree/bindings/net/sh_eth.txt
> @@ -4,7 +4,8 @@ This file provides information on what the device node for the SH EtherMAC
> interface contains.
>
> Required properties:
> -- compatible: "renesas,gether-r8a7740" if the device is a part of R8A7740 SoC.
> +- compatible: Must contain one or more of the following:
> + "renesas,gether-r8a7740" if the device is a part of R8A7740 SoC.
> "renesas,ether-r8a7743" if the device is a part of R8A7743 SoC.
> "renesas,ether-r8a7745" if the device is a part of R8A7745 SoC.
> "renesas,ether-r8a7778" if the device is a part of R8A7778 SoC.
> @@ -14,6 +15,14 @@ Required properties:
> "renesas,ether-r8a7793" if the device is a part of R8A7793 SoC.
> "renesas,ether-r8a7794" if the device is a part of R8A7794 SoC.
> "renesas,ether-r7s72100" if the device is a part of R7S72100 SoC.
> + "renesas,rcar-gen1-ether" for a generic R-Car Gen1 device.
> + "renesas,rcar-gen2-ether" for a generic R-Car Gen2 or RZ/G1
> + device.
> +
> + When compatible with the generic version nodes must list
> + the SoC-specific version corresponding to the platform
> + first followed by the generic version.
> +
The original text uses the different indentation, tab and then spaces),
while you use only spaces here (but not above).
> - reg: offset and length of (1) the E-DMAC/feLic register block (required),
> (2) the TSU register block (optional).
> - interrupts: interrupt specifier for the sole interrupt.
> @@ -36,7 +45,8 @@ Optional properties:
> Example (Lager board):
>
> ethernet@ee700000 {
> - compatible = "renesas,ether-r8a7790";
> + compatible = "renesas,ether-r8a7790",
> + "renesas,rcar-gen2-ether";
Again, using one more tab seems possible here...
> reg = <0 0xee700000 0 0x400>;
> interrupt-parent = <&gic>;
> interrupts = <0 162 IRQ_TYPE_LEVEL_HIGH>;
>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH net v2] bpf: disallow arithmetic operations on context pointer
From: Edward Cree @ 2017-10-17 10:14 UTC (permalink / raw)
To: Jakub Kicinski, netdev; +Cc: oss-drivers, alexei.starovoitov, daniel
In-Reply-To: <20171016181655.16366-1-jakub.kicinski@netronome.com>
On 16/10/17 19:16, Jakub Kicinski wrote:
> Commit f1174f77b50c ("bpf/verifier: rework value tracking")
> removed the crafty selection of which pointer types are
> allowed to be modified. This is OK for most pointer types
> since adjust_ptr_min_max_vals() will catch operations on
> immutable pointers. One exception is PTR_TO_CTX which is
> now allowed to be offseted freely.
>
> The intent of aforementioned commit was to allow context
> access via modified registers. The offset passed to
> ->is_valid_access() verifier callback has been adjusted
> by the value of the variable offset.
>
> What is missing, however, is taking the variable offset
> into account when the context register is used. Or in terms
> of the code adding the offset to the value passed to the
> ->convert_ctx_access() callback. This leads to the following
> eBPF user code:
>
> r1 += 68
> r0 = *(u32 *)(r1 + 8)
> exit
>
> being translated to this in kernel space:
>
> 0: (07) r1 += 68
> 1: (61) r0 = *(u32 *)(r1 +180)
> 2: (95) exit
>
> Offset 8 is corresponding to 180 in the kernel, but offset
> 76 is valid too. Verifier will "accept" access to offset
> 68+8=76 but then "convert" access to offset 8 as 180.
> Effective access to offset 248 is beyond the kernel context.
> (This is a __sk_buff example on a debug-heavy kernel -
> packet mark is 8 -> 180, 76 would be data.)
>
> Dereferencing the modified context pointer is not as easy
> as dereferencing other types, because we have to translate
> the access to reading a field in kernel structures which is
> usually at a different offset and often of a different size.
> To allow modifying the pointer we would have to make sure
> that given eBPF instruction will always access the same
> field or the fields accessed are "compatible" in terms of
> offset and size...
>
> Disallow dereferencing modified context pointers and add
> to selftests the test case described here.
>
> Fixes: f1174f77b50c ("bpf/verifier: rework value tracking")
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
> Dave, a merge note - in net-next this will need env to be passed
> to verbose().
>
> v2:
> - spell dereference correctly.
>
> kernel/bpf/verifier.c | 8 ++++++--
> tools/testing/selftests/bpf/test_verifier.c | 14 ++++++++++++++
> 2 files changed, 20 insertions(+), 2 deletions(-)
Acked-by: Edward Cree <ecree@solarflare.com>
^ permalink raw reply
* Re: [PATCH v2 00/15] make structure field, function arguments and structures const
From: Greg KH @ 2017-10-17 10:12 UTC (permalink / raw)
To: Bhumika Goyal
Cc: julia.lawall, rjw, lenb, alexander.shishkin, jic23, knaack.h,
lars, pmeerw, dledford, sean.hefty, hal.rosenstock, hch, sagi,
kishon, bhelgaas, nab, balbi, laurent.pinchart, jlbec, ccaulfie,
teigland, mfasheh, linux-acpi, linux-kernel, linux-iio,
linux-rdma, netdev, linux-nvme, linux-pci, linux-scsi,
target-devel, linux-usb, cluster-devel, ocfs2-devel
In-Reply-To: <1508167134-6243-1-git-send-email-bhumirks@gmail.com>
On Mon, Oct 16, 2017 at 05:18:39PM +0200, Bhumika Goyal wrote:
> Make the ci_type field and some function arguments as const. After this
> change, make config_item_type structures as const.
>
> * Changes in v2- Combine all the followup patches and the constification
> patches into a series.
Who do you want to take these patches? If you want, I can take them
through my driver-core tree, which has done other configfs stuff like
this in the past.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] net: export netdev_txq_to_tc to allow sch_mqprio to compile as module
From: Henrik Austad @ 2017-10-17 10:10 UTC (permalink / raw)
To: netdev
Cc: David S . Miller, Eric Dumazet, Daniel Borkmann, David Ahern,
Alexander Duyck, Willem de Bruijn, John Fastabend, tcharding,
linux-kernel, Henrik Austad, Jesus Sanchez-Palencia
In commit 32302902ff09 ("mqprio: Reserve last 32 classid values for HW
traffic classes and misc IDs") sch_mqprio started using netdev_txq_to_tc
to find the correct tc instead of dev->tc_to_txq[]
However, when mqprio is compiled as a module, it cannot resolve the
symbol, leading to this error:
ERROR: "netdev_txq_to_tc" [net/sched/sch_mqprio.ko] undefined!
This adds an EXPORT_SYMBOL() since the other user in the kernel
(netif_set_xps_queue) is also EXPORT_SYMBOL() (and not _GPL) or in a
sysfs-callback.
Cc: Alexander Duyck <alexander.h.duyck@intel.com>
Cc: Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Henrik Austad <haustad@cisco.com>
---
net/core/dev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index fcddccb..d2b20e7 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2040,6 +2040,7 @@ int netdev_txq_to_tc(struct net_device *dev, unsigned int txq)
return 0;
}
+EXPORT_SYMBOL(netdev_txq_to_tc);
#ifdef CONFIG_XPS
static DEFINE_MUTEX(xps_map_mutex);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net 0/3] bonding: void calling rtmsg_ifinfo for netlink notifications
From: Jiri Pirko @ 2017-10-17 9:59 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, davem
In-Reply-To: <cover.1508233044.git.lucien.xin@gmail.com>
Tue, Oct 17, 2017 at 11:39:38AM CEST, lucien.xin@gmail.com wrote:
>It's better to send notifications to userspace by the events
>in rtnetlink_event, instead of calling rtmsg_ifinfo directly.
>
>This patcheset is to remove rtmsg_ifinfo called in bonding,
>the notifications can be handled by NETDEV_CHANGEUPPER and
>NETDEV_CHANGELOWERSTATE events in rtnetlink_event.
>
>It could also fix some redundant notifications from bonding.
This should go to net-next.
>
>Xin Long (3):
> bonding: remove rtmsg_ifinfo called in bond_master_upper_dev_link
> rtnetlink: bring NETDEV_CHANGELOWERSTATE event process back to
> rtnetlink_event
> bonding: remove rtmsg_ifinfo called after bond_lower_state_changed
>
> drivers/net/bonding/bond_main.c | 11 +++--------
> include/net/bonding.h | 4 ----
> net/core/rtnetlink.c | 2 +-
> 3 files changed, 4 insertions(+), 13 deletions(-)
>
>--
>2.1.0
>
^ permalink raw reply
* Re: Linux 4.12+ memory leak on router with i40e NICs
From: Paweł Staszewski @ 2017-10-17 9:48 UTC (permalink / raw)
To: Alexander Duyck
Cc: Pavlos Parissis, Anders K. Pedersen | Cohaesio,
netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
alexander.h.duyck@intel.com
In-Reply-To: <310ce203-0d65-bdf4-d9e4-897a349b3277@itcare.pl>
W dniu 2017-10-17 o 02:44, Paweł Staszewski pisze:
>
>
> W dniu 2017-10-17 o 01:56, Alexander Duyck pisze:
>> On Mon, Oct 16, 2017 at 4:34 PM, Paweł Staszewski
>> <pstaszewski@itcare.pl> wrote:
>>>
>>> W dniu 2017-10-16 o 18:26, Paweł Staszewski pisze:
>>>
>>>>
>>>> W dniu 2017-10-16 o 13:20, Pavlos Parissis pisze:
>>>>> On 15/10/2017 02:58 πμ, Alexander Duyck wrote:
>>>>>> Hi Pawel,
>>>>>>
>>>>>> To clarify is that Dave Miller's tree or Linus's that you are
>>>>>> talking
>>>>>> about? If it is Dave's tree how long ago was it you pulled it
>>>>>> since I
>>>>>> think the fix was just pushed by Jeff Kirsher a few days ago.
>>>>>>
>>>>>> The issue should be fixed in the following commit:
>>>>>>
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/drivers/net/ethernet/intel/i40e/i40e_txrx.c?id=2b9478ffc550f17c6cd8c69057234e91150f5972
>>>>>>
>>>>>>
>>>>> Do you know when it is going to be available on net-next and
>>>>> linux-stable
>>>>> repos?
>>>>>
>>>>> Cheers,
>>>>> Pavlos
>>>>>
>>>>>
>>>> I will make some tests today night with "net" git tree where this
>>>> patch is
>>>> included.
>>>> Starting from 0:00 CET
>>>> :)
>>>>
>>>>
>>> Upgraded and looks like problem is not solved with that patch
>>> Currently running system with
>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/
>>> kernel
>>>
>>> Still about 0.5GB of memory is leaking somewhere
>>>
>>> Also can confirm that the latest kernel where memory is not leaking
>>> (with
>>> use i40e driver intel 710 cards) is 4.11.12
>>> With kernel 4.11.12 - after hour no change in memory usage.
>>>
>>> also checked that with ixgbe instead of i40e with same net.git
>>> kernel there
>>> is no memleak - after hour same memory usage - so for 100% this is i40e
>>> driver problem.
>> So how long was the run to get the .5GB of memory leaking?
> 1 hour
>
>>
>> Also is there any chance of you being able to bisect to determine
>> where the memory leak was introduced since as you pointed out it
>> didn't exist in 4.11.12 so odds are it was introduced somewhere
>> between 4.11 and the latest kernel release.
> Can be hard cause currently need to back to 4.11.12 - this is
> production host/router
> Will try to find some free/test router for tests/bicects with i40e
> driver (intel 710 cards)
>
>>
>> Thanks.
>>
>> - Alex
>>
>
>
Also forgoto to add errors for i40e when driver initialize:
[ 15.760569] i40e 0000:02:00.1: Error I40E_AQ_RC_ENOSPC adding RX
filters on PF, promiscuous mode forced on
[ 16.365587] i40e 0000:03:00.3: Error I40E_AQ_RC_ENOSPC adding RX
filters on PF, promiscuous mode forced on
[ 16.367686] i40e 0000:02:00.2: Error I40E_AQ_RC_ENOSPC adding RX
filters on PF, promiscuous mode forced on
[ 16.368816] i40e 0000:03:00.0: Error I40E_AQ_RC_ENOSPC adding RX
filters on PF, promiscuous mode forced on
[ 16.369877] i40e 0000:03:00.2: Error I40E_AQ_RC_ENOSPC adding RX
filters on PF, promiscuous mode forced on
[ 16.370941] i40e 0000:02:00.3: Error I40E_AQ_RC_ENOSPC adding RX
filters on PF, promiscuous mode forced on
[ 16.372005] i40e 0000:02:00.0: Error I40E_AQ_RC_ENOSPC adding RX
filters on PF, promiscuous mode forced on
[ 16.373029] i40e 0000:03:00.1: Error I40E_AQ_RC_ENOSPC adding RX
filters on PF, promiscuous mode forced on
some params that are set for this nic's
ip link set up dev $i
ethtool -A $i autoneg off rx off tx off
ethtool -G $i rx 1024 tx 2048
ip link set $i txqueuelen 1000
ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 512
tx-usecs 128
ethtool -L $i combined 6
#ethtool -N $i rx-flow-hash udp4 sdfn
ethtool -K $i ntuple on
ethtool -K $i gro off
ethtool -K $i tso off
^ permalink raw reply
* [PATCH net 3/3] bonding: remove rtmsg_ifinfo called after bond_lower_state_changed
From: Xin Long @ 2017-10-17 9:39 UTC (permalink / raw)
To: network dev; +Cc: davem, Jiri Pirko
In-Reply-To: <cover.1508233044.git.lucien.xin@gmail.com>
After the patch 'rtnetlink: bring NETDEV_CHANGELOWERSTATE event
process back to rtnetlink_event', bond_lower_state_changed would
generate NETDEV_CHANGEUPPER event which would send a notification
to userspace in rtnetlink_event.
There's no need to call rtmsg_ifinfo to send the notification
any more. So this patch is to remove it from these places after
bond_lower_state_changed.
Besides, after this, rtmsg_ifinfo is not needed to be exported.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/net/bonding.h | 4 ----
net/core/rtnetlink.c | 1 -
2 files changed, 5 deletions(-)
diff --git a/include/net/bonding.h b/include/net/bonding.h
index b2e6865..1b7631c 100644
--- a/include/net/bonding.h
+++ b/include/net/bonding.h
@@ -330,7 +330,6 @@ static inline void bond_set_active_slave(struct slave *slave)
slave->backup = 0;
bond_queue_slave_event(slave);
bond_lower_state_changed(slave);
- rtmsg_ifinfo(RTM_NEWLINK, slave->dev, 0, GFP_ATOMIC);
}
}
@@ -340,7 +339,6 @@ static inline void bond_set_backup_slave(struct slave *slave)
slave->backup = 1;
bond_queue_slave_event(slave);
bond_lower_state_changed(slave);
- rtmsg_ifinfo(RTM_NEWLINK, slave->dev, 0, GFP_ATOMIC);
}
}
@@ -353,7 +351,6 @@ static inline void bond_set_slave_state(struct slave *slave,
slave->backup = slave_state;
if (notify) {
bond_lower_state_changed(slave);
- rtmsg_ifinfo(RTM_NEWLINK, slave->dev, 0, GFP_ATOMIC);
bond_queue_slave_event(slave);
slave->should_notify = 0;
} else {
@@ -385,7 +382,6 @@ static inline void bond_slave_state_notify(struct bonding *bond)
bond_for_each_slave(bond, tmp, iter) {
if (tmp->should_notify) {
bond_lower_state_changed(tmp);
- rtmsg_ifinfo(RTM_NEWLINK, tmp->dev, 0, GFP_ATOMIC);
tmp->should_notify = 0;
}
}
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 24cb403..1574ab5 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2910,7 +2910,6 @@ void rtmsg_ifinfo(int type, struct net_device *dev, unsigned int change,
{
rtmsg_ifinfo_event(type, dev, change, rtnl_get_event(0), flags);
}
-EXPORT_SYMBOL(rtmsg_ifinfo);
static int nlmsg_populate_fdb_fill(struct sk_buff *skb,
struct net_device *dev,
--
2.1.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox