* Re: [PATCH v1 net-next 00/15] tc-taprio offload for SJA1105 DSA
From: David Miller @ 2019-09-07 13:55 UTC (permalink / raw)
To: olteanv
Cc: f.fainelli, vivien.didelot, andrew, vinicius.gomes, vedang.patel,
richardcochran, weifeng.voon, jiri, m-karicheri2, Jose.Abreu,
ilias.apalodimas, jhs, xiyou.wangcong, kurt.kanzenbach, netdev
In-Reply-To: <20190902162544.24613-1-olteanv@gmail.com>
This is a warning that I will toss this patch series if it receives no series
review in the next couple of days.
Thank you.
^ permalink raw reply
* Re: iproute2: tc: potential buffer overflow
From: tomaspaukrt @ 2019-09-07 13:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20190831083751.3814ee37@hermes.lan>
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
The updated patch is in the attachment.
---------- Původní e-mail ----------
Od: Stephen Hemminger <stephen@networkplumber.org>
Komu: tomaspaukrt@email.cz
Datum: 31. 8. 2019 17:38:01
Předmět: Re: iproute2: tc: potential buffer overflow
On Sat, 31 Aug 2019 15:13:27 +0200 (CEST)
<tomaspaukrt@email.cz> wrote:
> Hi,
>
> there are two potentially dangerous calls of strcpy function in the program "tc". In the attachment is a patch that fixes this issue.
>
> Tomas
This looks correct.
Please fix with strlcpy() instead; that is clearer.
Plus you can use XT_EXTENSION_MAX_NAMELEN here (optional).
[-- Attachment #2: iproute2-overflow-fix.patch --]
[-- Type: text/x-diff, Size: 1109 bytes --]
commit 46be35fbded24c75786ce178c516d7fba991a90a
Author: Tomas Paukrt <tomaspaukrt@email.cz>
Date: Sat Sep 7 15:34:30 2019 +0200
tc: fix potential buffer overflow
diff --git a/tc/m_ipt.c b/tc/m_ipt.c
index cc95eab..e47ae6b 100644
--- a/tc/m_ipt.c
+++ b/tc/m_ipt.c
@@ -269,7 +269,8 @@ static int build_st(struct xtables_target *target, struct ipt_entry_target *t)
} else {
target->t = t;
}
- strcpy(target->t->u.user.name, target->name);
+ strlcpy(target->t->u.user.name, target->name,
+ sizeof(target->t->u.user.name));
return 0;
}
diff --git a/tc/m_xt_old.c b/tc/m_xt_old.c
index 6a4509a..dd27adf 100644
--- a/tc/m_xt_old.c
+++ b/tc/m_xt_old.c
@@ -177,7 +177,8 @@ build_st(struct xtables_target *target, struct xt_entry_target *t)
if (t == NULL) {
target->t = fw_calloc(1, size);
target->t->u.target_size = size;
- strcpy(target->t->u.user.name, target->name);
+ strlcpy(target->t->u.user.name, target->name,
+ sizeof(target->t->u.user.name));
set_revision(target->t->u.user.name, target->revision);
if (target->init != NULL)
^ permalink raw reply related
* Re: [PATCH 0/8] Netfilter updates for net-next
From: David Miller @ 2019-09-07 14:34 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20190905160400.25399-1-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Thu, 5 Sep 2019 18:03:52 +0200
> The following patchset contains Netfilter updates for net-next:
>
> 1) Add nft_reg_store64() and nft_reg_load64() helpers, from Ander Juaristi.
>
> 2) Time matching support, also from Ander Juaristi.
>
> 3) VLAN support for nfnetlink_log, from Michael Braun.
>
> 4) Support for set element deletions from the packet path, also from Ander.
>
> 5) Remove __read_mostly from conntrack spinlock, from Li RongQing.
>
> 6) Support for updating stateful objects, this also includes the initial
> client for this infrastructure: the quota extension. A follow up fix
> for the control plane also comes in this batch. Patches from
> Fernando Fernandez Mancera.
>
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH v1 net-next 00/15] tc-taprio offload for SJA1105 DSA
From: Andrew Lunn @ 2019-09-07 14:45 UTC (permalink / raw)
To: David Miller, olteanv
Cc: olteanv, f.fainelli, vivien.didelot, vinicius.gomes, vedang.patel,
richardcochran, weifeng.voon, jiri, m-karicheri2, Jose.Abreu,
ilias.apalodimas, jhs, xiyou.wangcong, kurt.kanzenbach, netdev
In-Reply-To: <20190906.145403.657322945046640538.davem@davemloft.net>
On Fri, Sep 06, 2019 at 02:54:03PM +0200, David Miller wrote:
> From: Vladimir Oltean <olteanv@gmail.com>
> Date: Mon, 2 Sep 2019 19:25:29 +0300
>
> > This is the first attempt to submit the tc-taprio offload model for
> > inclusion in the net tree.
>
> Someone really needs to review this.
Hi Vladimir
You might have more chance getting this reviewed if you split it up
into a number of smaller series. Richard could probably review the
plain PTP changes. Who else has worked on tc-taprio recently? A series
purely about tc-taprio might be more likely reviewed by a tc-taprio
person, if it does not contain PTP changes.
Andrew
^ permalink raw reply
* Re: [PATCH 0/2] Revert and rework on the metadata accelreation
From: Jason Gunthorpe @ 2019-09-07 15:03 UTC (permalink / raw)
To: Jason Wang
Cc: mst@redhat.com, kvm@vger.kernel.org,
virtualization@lists.linux-foundation.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, aarcange@redhat.com,
jglisse@redhat.com, linux-mm@kvack.org
In-Reply-To: <7785d39b-b4e7-8165-516c-ee6a08ac9c4e@redhat.com>
On Fri, Sep 06, 2019 at 06:02:35PM +0800, Jason Wang wrote:
>
> On 2019/9/5 下午9:59, Jason Gunthorpe wrote:
> > On Thu, Sep 05, 2019 at 08:27:34PM +0800, Jason Wang wrote:
> > > Hi:
> > >
> > > Per request from Michael and Jason, the metadata accelreation is
> > > reverted in this version and rework in next version.
> > >
> > > Please review.
> > >
> > > Thanks
> > >
> > > Jason Wang (2):
> > > Revert "vhost: access vq metadata through kernel virtual address"
> > > vhost: re-introducing metadata acceleration through kernel virtual
> > > address
> > There are a bunch of patches in the queue already that will help
> > vhost, and I a working on one for next cycle that will help alot more
> > too.
>
>
> I will check those patches, but if you can give me some pointers or keywords
> it would be much appreciated.
You can look here:
https://github.com/jgunthorpe/linux/commits/mmu_notifier
The first parts, the get/put are in the hmm tree, and the last part,
the interval tree in the last commit is still a WIP, but it would
remove alot of that code from vhost as well.
Jason
^ permalink raw reply
* Re: [patch net-next 3/3] net: devlink: move reload fail indication to devlink core and expose to user
From: David Ahern @ 2019-09-07 15:08 UTC (permalink / raw)
To: Jiri Pirko, netdev; +Cc: davem, idosch, jakub.kicinski, tariqt, mlxsw
In-Reply-To: <20190906184419.5101-4-jiri@resnulli.us>
On 9/6/19 7:44 PM, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> Currently the fact that devlink failed is stored in drivers. Move this
> flag into devlink core. Also, expose it to the user.
you mean 'reload failed', not 'devlink failed'?
^ permalink raw reply
* Re: [PATCH] ethernet: micrel: Use DIV_ROUND_CLOSEST directly to make it readable
From: David Miller @ 2019-09-07 15:17 UTC (permalink / raw)
To: zhongjiang; +Cc: kstewart, gregkh, netdev, linux-kernel
In-Reply-To: <1567698828-26825-1-git-send-email-zhongjiang@huawei.com>
From: zhong jiang <zhongjiang@huawei.com>
Date: Thu, 5 Sep 2019 23:53:48 +0800
> The kernel.h macro DIV_ROUND_CLOSEST performs the computation (x + d/2)/d
> but is perhaps more readable.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Applied to net-next.
^ permalink raw reply
* [PATCH] libertas: use mesh_wdev->ssid instead of priv->mesh_ssid
From: Lubomir Rintel @ 2019-09-07 15:18 UTC (permalink / raw)
To: Kalle Valo
Cc: libertas-dev, linux-wireless, netdev, linux-kernel,
Lubomir Rintel
With the commit e86dc1ca4676 ("Libertas: cfg80211 support") we've lost
the ability to actually set the Mesh SSID from userspace.
NL80211_CMD_SET_INTERFACE with NL80211_ATTR_MESH_ID sets the mesh point
interface's ssid field. Let's use that one for the Libertas Mesh
operation
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
drivers/net/wireless/marvell/libertas/dev.h | 2 --
drivers/net/wireless/marvell/libertas/mesh.c | 31 +++++++++++++-------
drivers/net/wireless/marvell/libertas/mesh.h | 3 +-
3 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/marvell/libertas/dev.h b/drivers/net/wireless/marvell/libertas/dev.h
index 4691349300265..4b6e05a8e5d54 100644
--- a/drivers/net/wireless/marvell/libertas/dev.h
+++ b/drivers/net/wireless/marvell/libertas/dev.h
@@ -58,8 +58,6 @@ struct lbs_private {
#ifdef CONFIG_LIBERTAS_MESH
struct lbs_mesh_stats mstats;
uint16_t mesh_tlv;
- u8 mesh_ssid[IEEE80211_MAX_SSID_LEN + 1];
- u8 mesh_ssid_len;
u8 mesh_channel;
#endif
diff --git a/drivers/net/wireless/marvell/libertas/mesh.c b/drivers/net/wireless/marvell/libertas/mesh.c
index 2315fdff56c2f..2747c957d18c9 100644
--- a/drivers/net/wireless/marvell/libertas/mesh.c
+++ b/drivers/net/wireless/marvell/libertas/mesh.c
@@ -86,6 +86,7 @@ static int lbs_mesh_config_send(struct lbs_private *priv,
static int lbs_mesh_config(struct lbs_private *priv, uint16_t action,
uint16_t chan)
{
+ struct wireless_dev *mesh_wdev;
struct cmd_ds_mesh_config cmd;
struct mrvl_meshie *ie;
@@ -105,10 +106,17 @@ static int lbs_mesh_config(struct lbs_private *priv, uint16_t action,
ie->val.active_protocol_id = MARVELL_MESH_PROTO_ID_HWMP;
ie->val.active_metric_id = MARVELL_MESH_METRIC_ID;
ie->val.mesh_capability = MARVELL_MESH_CAPABILITY;
- ie->val.mesh_id_len = priv->mesh_ssid_len;
- memcpy(ie->val.mesh_id, priv->mesh_ssid, priv->mesh_ssid_len);
+
+ if (priv->mesh_dev) {
+ mesh_wdev = priv->mesh_dev->ieee80211_ptr;
+ ie->val.mesh_id_len = mesh_wdev->mesh_id_up_len;
+ memcpy(ie->val.mesh_id, mesh_wdev->ssid,
+ mesh_wdev->mesh_id_up_len);
+ }
+
ie->len = sizeof(struct mrvl_meshie_val) -
- IEEE80211_MAX_SSID_LEN + priv->mesh_ssid_len;
+ IEEE80211_MAX_SSID_LEN + ie->val.mesh_id_len;
+
cmd.length = cpu_to_le16(sizeof(struct mrvl_meshie_val));
break;
case CMD_ACT_MESH_CONFIG_STOP:
@@ -117,8 +125,8 @@ static int lbs_mesh_config(struct lbs_private *priv, uint16_t action,
return -1;
}
lbs_deb_cmd("mesh config action %d type %x channel %d SSID %*pE\n",
- action, priv->mesh_tlv, chan, priv->mesh_ssid_len,
- priv->mesh_ssid);
+ action, priv->mesh_tlv, chan, ie->val.mesh_id_len,
+ ie->val.mesh_id);
return __lbs_mesh_config_send(priv, &cmd, action, priv->mesh_tlv);
}
@@ -863,12 +871,6 @@ int lbs_init_mesh(struct lbs_private *priv)
/* Stop meshing until interface is brought up */
lbs_mesh_config(priv, CMD_ACT_MESH_CONFIG_STOP, 1);
- if (priv->mesh_tlv) {
- sprintf(priv->mesh_ssid, "mesh");
- priv->mesh_ssid_len = 4;
- ret = 1;
- }
-
return ret;
}
@@ -997,6 +999,13 @@ static int lbs_add_mesh(struct lbs_private *priv)
mesh_wdev->iftype = NL80211_IFTYPE_MESH_POINT;
mesh_wdev->wiphy = priv->wdev->wiphy;
+
+ if (priv->mesh_tlv) {
+ sprintf(mesh_wdev->ssid, "mesh");
+ mesh_wdev->mesh_id_up_len = 4;
+ ret = 1;
+ }
+
mesh_wdev->netdev = mesh_dev;
mesh_dev->ml_priv = priv;
diff --git a/drivers/net/wireless/marvell/libertas/mesh.h b/drivers/net/wireless/marvell/libertas/mesh.h
index dfe22c91aade0..1561018f226fd 100644
--- a/drivers/net/wireless/marvell/libertas/mesh.h
+++ b/drivers/net/wireless/marvell/libertas/mesh.h
@@ -24,8 +24,7 @@ void lbs_remove_mesh(struct lbs_private *priv);
static inline bool lbs_mesh_activated(struct lbs_private *priv)
{
- /* Mesh SSID is only programmed after successful init */
- return priv->mesh_ssid_len != 0;
+ return !!priv->mesh_tlv;
}
int lbs_mesh_set_channel(struct lbs_private *priv, u8 channel);
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 1/2] net: phy: dp83867: Add documentation for SGMII mode type
From: David Miller @ 2019-09-07 15:24 UTC (permalink / raw)
To: vitaly.gaiduk
Cc: robh+dt, f.fainelli, mark.rutland, tpiepho, andrew, netdev,
devicetree, linux-kernel
In-Reply-To: <1567700761-14195-2-git-send-email-vitaly.gaiduk@cloudbear.ru>
From: Vitaly Gaiduk <vitaly.gaiduk@cloudbear.ru>
Date: Thu, 5 Sep 2019 19:26:00 +0300
> + - ti,sgmii-type - This denotes the fact which SGMII mode is used (4 or 6-wire).
You need to document this more sufficiently as per Andrew's feedback.
^ permalink raw reply
* Re: [PATCH] net: phylink: Fix flow control resolution
From: David Miller @ 2019-09-07 15:27 UTC (permalink / raw)
To: stefanc
Cc: linux, andrew, netdev, linux-kernel, shaulb, nadavh, ymarkman,
marcin
In-Reply-To: <1567701978-16056-1-git-send-email-stefanc@marvell.com>
From: <stefanc@marvell.com>
Date: Thu, 5 Sep 2019 19:46:18 +0300
> From: Stefan Chulski <stefanc@marvell.com>
>
> Regarding to IEEE 802.3-2015 standard section 2
> 28B.3 Priority resolution - Table 28-3 - Pause resolution
>
> In case of Local device Pause=1 AsymDir=0, Link partner
> Pause=1 AsymDir=1, Local device resolution should be enable PAUSE
> transmit, disable PAUSE receive.
> And in case of Local device Pause=1 AsymDir=1, Link partner
> Pause=1 AsymDir=0, Local device resolution should be enable PAUSE
> receive, disable PAUSE transmit.
>
> Signed-off-by: Stefan Chulski <stefanc@marvell.com>
> Reported-by: Shaul Ben-Mayor <shaulb@marvell.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [patch net-next] net: fib_notifier: move fib_notifier_ops from struct net into per-net struct
From: David Miller @ 2019-09-07 15:28 UTC (permalink / raw)
To: jiri; +Cc: netdev, idosch, dsahern, mlxsw
In-Reply-To: <20190905180656.4756-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 5 Sep 2019 20:06:56 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> No need for fib_notifier_ops to be in struct net. It is used only by
> fib_notifier as a private data. Use net_generic to introduce per-net
> fib_notifier struct and move fib_notifier_ops there.
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] tcp: ulp: fix possible crash in tcp_diag_get_aux_size()
From: David Miller @ 2019-09-07 15:34 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, lukehsiao, ncardwell, dcaratti
In-Reply-To: <20190905202041.138085-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Thu, 5 Sep 2019 13:20:41 -0700
> tcp_diag_get_aux_size() can be called with sockets in any state.
>
> icsk_ulp_ops is only present for full sockets.
>
> For SYN_RECV or TIME_WAIT ones we would access garbage.
>
> Fixes: 61723b393292 ("tcp: ulp: add functions to dump ulp-specific information")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Luke Hsiao <lukehsiao@google.com>
> Reported-by: Neal Cardwell <ncardwell@google.com>
Applied to net-next, thanks Eric.
^ permalink raw reply
* Re: [PATCH] net/ibmvnic: free reset work of removed device from queue
From: David Miller @ 2019-09-07 15:37 UTC (permalink / raw)
To: julietk; +Cc: netdev, linuxppc-dev
In-Reply-To: <20190905213001.19818-1-julietk@linux.vnet.ibm.com>
From: Juliet Kim <julietk@linux.vnet.ibm.com>
Date: Thu, 5 Sep 2019 17:30:01 -0400
> Commit 36f1031c51a2 ("ibmvnic: Do not process reset during or after
> device removal") made the change to exit reset if the driver has been
> removed, but does not free reset work items of the adapter from queue.
>
> Ensure all reset work items are freed when breaking out of the loop early.
>
> Fixes: 36f1031c51a2 ("ibmnvic: Do not process reset during or after
> device removal”)
Please do not break up Fixes: tags into mutliple lines, also please do
not put an empty line between the Fixes: tag and other tags like the
Signed-off-by:
> Signed-off-by: Juliet Kim <julietk@linux.vnet.ibm.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] net: phy: dp83867: Add documentation for SGMII mode type
From: Andrew Lunn @ 2019-09-07 15:39 UTC (permalink / raw)
To: Vitaly Gaiduk
Cc: davem, robh+dt, f.fainelli, Mark Rutland, Trent Piepho, netdev,
devicetree, linux-kernel
In-Reply-To: <1567700761-14195-2-git-send-email-vitaly.gaiduk@cloudbear.ru>
On Thu, Sep 05, 2019 at 07:26:00PM +0300, Vitaly Gaiduk wrote:
> Add documentation of ti,sgmii-type which can be used to select
> SGMII mode type (4 or 6-wire).
>
> Signed-off-by: Vitaly Gaiduk <vitaly.gaiduk@cloudbear.ru>
> ---
> Documentation/devicetree/bindings/net/ti,dp83867.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt
> index db6aa3f2215b..18e7fd52897f 100644
> --- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
> +++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
> @@ -37,6 +37,7 @@ Optional property:
> for applicable values. The CLK_OUT pin can also
> be disabled by this property. When omitted, the
> PHY's default will be left as is.
> + - ti,sgmii-type - This denotes the fact which SGMII mode is used (4 or 6-wire).
Hi Vitaly
You probably want to make this a Boolean. I don't think SGMII type is
a good idea. This is about enabling the receive clock to be passed to
the MAC. So how about ti,sgmii-ref-clock-output-enable.
Andrew
^ permalink raw reply
* Re: [pull request][net-next 00/14] Mellanox, mlx5 cleanups & port congestion stats
From: David Miller @ 2019-09-07 15:40 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20190905215034.22713-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Thu, 5 Sep 2019 21:50:52 +0000
> This series provides 12 mlx5 cleanup patches and last 2 patches provide
> port congestion stats to ethtool.
>
> For more information please see tag log below.
>
> Please pull and let me know if there is any problem.
Pulled, thanks Saeed.
^ permalink raw reply
* Re: [PATCH 1/2] net: phy: dp83867: Add documentation for SGMII mode type
From: Florian Fainelli @ 2019-09-07 15:41 UTC (permalink / raw)
To: Vitaly Gaiduk, Andrew Lunn
Cc: davem, robh+dt, Mark Rutland, Trent Piepho, netdev, devicetree,
linux-kernel
In-Reply-To: <23dc47ea-209f-9f51-d4a5-161e62e2a69e@cloudbear.ru>
On 9/6/2019 1:45 PM, Vitaly Gaiduk wrote:
> Hi, Andrew.
>
> I'm not familiar with generic PHY HW archs but suppose that it is
> proprietary to TI.
>
> I'v never seen such feature so moved it in TI dts field.
My search engine results seem to indicate that this is indeed TI
specific only and this is not something that exists with other vendors
apparently. The "ti," prefix is therefore appropriate.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next,v2, 0/2] Enable sg as tunable, sync offload settings to VF NIC
From: David Miller @ 2019-09-07 15:43 UTC (permalink / raw)
To: haiyangz
Cc: sashal, linux-hyperv, netdev, kys, sthemmin, olaf, vkuznets,
linux-kernel
In-Reply-To: <1567725722-33552-1-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Thu, 5 Sep 2019 23:22:58 +0000
> This patch set fixes an issue in SG tuning, and sync
> offload settings from synthetic NIC to VF NIC.
Series applied to net-next.
^ permalink raw reply
* Re: [PATCH net v2] isdn/capi: check message length in capi_write()
From: David Miller @ 2019-09-07 15:47 UTC (permalink / raw)
To: ebiggers; +Cc: netdev, isdn, syzkaller-bugs
In-Reply-To: <20190906023637.768-1-ebiggers@kernel.org>
From: Eric Biggers <ebiggers@kernel.org>
Date: Thu, 5 Sep 2019 19:36:37 -0700
> From: Eric Biggers <ebiggers@google.com>
>
> syzbot reported:
>
> BUG: KMSAN: uninit-value in capi_write+0x791/0xa90 drivers/isdn/capi/capi.c:700
> CPU: 0 PID: 10025 Comm: syz-executor379 Not tainted 4.20.0-rc7+ #2
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x173/0x1d0 lib/dump_stack.c:113
> kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613
> __msan_warning+0x82/0xf0 mm/kmsan/kmsan_instr.c:313
> capi_write+0x791/0xa90 drivers/isdn/capi/capi.c:700
> do_loop_readv_writev fs/read_write.c:703 [inline]
> do_iter_write+0x83e/0xd80 fs/read_write.c:961
> vfs_writev fs/read_write.c:1004 [inline]
> do_writev+0x397/0x840 fs/read_write.c:1039
> __do_sys_writev fs/read_write.c:1112 [inline]
> __se_sys_writev+0x9b/0xb0 fs/read_write.c:1109
> __x64_sys_writev+0x4a/0x70 fs/read_write.c:1109
> do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
> entry_SYSCALL_64_after_hwframe+0x63/0xe7
> [...]
>
> The problem is that capi_write() is reading past the end of the message.
> Fix it by checking the message's length in the needed places.
>
> Reported-and-tested-by: syzbot+0849c524d9c634f5ae66@syzkaller.appspotmail.com
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] net-ipv6: addrconf_f6i_alloc - fix non-null pointer check to !IS_ERR()
From: David Miller @ 2019-09-07 15:48 UTC (permalink / raw)
To: zenczykowski; +Cc: maze, netdev, dsahern, lorenzo, edumazet
In-Reply-To: <20190906035637.47097-1-zenczykowski@gmail.com>
From: Maciej Żenczykowski <zenczykowski@gmail.com>
Date: Thu, 5 Sep 2019 20:56:37 -0700
> From: Maciej Żenczykowski <maze@google.com>
>
> Fixes a stupid bug I recently introduced...
> ip6_route_info_create() returns an ERR_PTR(err) and not a NULL on error.
>
> Fixes: d55a2e374a94 ("net-ipv6: fix excessive RTF_ADDRCONF flag on ::1/128 local route (and others)'")
> Cc: David Ahern <dsahern@gmail.com>
> Cc: Lorenzo Colitti <lorenzo@google.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
Applied and queued up for -stable since I queued up the patch this fixes.
^ permalink raw reply
* Re: [PATCHv3 net-next] ipmr: remove hard code cache_resolve_queue_len limit
From: David Miller @ 2019-09-07 15:49 UTC (permalink / raw)
To: liuhangbin; +Cc: netdev, karn, sukumarg1973, kuznet, yoshfuji, eric.dumazet
In-Reply-To: <20190906073601.10525-1-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Fri, 6 Sep 2019 15:36:01 +0800
> This is a re-post of previous patch wrote by David Miller[1].
>
> Phil Karn reported[2] that on busy networks with lots of unresolved
> multicast routing entries, the creation of new multicast group routes
> can be extremely slow and unreliable.
>
> The reason is we hard-coded multicast route entries with unresolved source
> addresses(cache_resolve_queue_len) to 10. If some multicast route never
> resolves and the unresolved source addresses increased, there will
> be no ability to create new multicast route cache.
>
> To resolve this issue, we need either add a sysctl entry to make the
> cache_resolve_queue_len configurable, or just remove cache_resolve_queue_len
> limit directly, as we already have the socket receive queue limits of mrouted
> socket, pointed by David.
>
> From my side, I'd perfer to remove the cache_resolve_queue_len limit instead
> of creating two more(IPv4 and IPv6 version) sysctl entry.
>
> [1] https://lkml.org/lkml/2018/7/22/11
> [2] https://lkml.org/lkml/2018/7/21/343
>
> v3: instead of remove cache_resolve_queue_len totally, let's only remove
> the hard code limit when allocate the unresolved cache, as Eric Dumazet
> suggested, so we don't need to re-count it in other places.
>
> v2: hold the mfc_unres_lock while walking the unresolved list in
> queue_count(), as Nikolay Aleksandrov remind.
>
> Reported-by: Phil Karn <karn@ka9q.net>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net-next 0/5] net: stmmac: Improvements and fixes for -next
From: David Miller @ 2019-09-07 15:57 UTC (permalink / raw)
To: Jose.Abreu
Cc: netdev, Joao.Pinto, peppe.cavallaro, alexandre.torgue,
mcoquelin.stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1567755423.git.joabreu@synopsys.com>
From: Jose Abreu <Jose.Abreu@synopsys.com>
Date: Fri, 6 Sep 2019 09:41:12 +0200
> Improvements and fixes for recently introduced features. All for -next tree.
> More info in commit logs.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] ethernet: micrel: Use DIV_ROUND_CLOSEST directly to make it readable
From: Andrew Lunn @ 2019-09-07 15:58 UTC (permalink / raw)
To: zhong jiang; +Cc: davem, kstewart, gregkh, netdev, linux-kernel
In-Reply-To: <5D732078.6080902@huawei.com>
On Sat, Sep 07, 2019 at 11:14:00AM +0800, zhong jiang wrote:
> On 2019/9/7 3:40, Andrew Lunn wrote:
> > On Thu, Sep 05, 2019 at 11:53:48PM +0800, zhong jiang wrote:
> >> The kernel.h macro DIV_ROUND_CLOSEST performs the computation (x + d/2)/d
> >> but is perhaps more readable.
> > Hi Zhong
> >
> > Did you find this by hand, or did you use a tool. If a tool is used,
> > it is normal to give some credit to the tool.
> With the following help of Coccinelle.
It is good to mention Coccinelle or other such tools. They often exist
because of university research work, and funding for such tools does
depend on publicity of the tools, getting the credit they deserve.
Andrew
^ permalink raw reply
* Re: [PATCH v2 net] net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list
From: David Miller @ 2019-09-07 16:00 UTC (permalink / raw)
To: shmulik
Cc: alexander.duyck, daniel, eric.dumazet, willemdebruijn.kernel,
netdev, eyal, shmulik.ladkani
In-Reply-To: <20190906092350.13929-1-shmulik.ladkani@gmail.com>
From: Shmulik Ladkani <shmulik@metanetworks.com>
Date: Fri, 6 Sep 2019 12:23:50 +0300
> Historically, support for frag_list packets entering skb_segment() was
> limited to frag_list members terminating on exact same gso_size
> boundaries. This is verified with a BUG_ON since commit 89319d3801d1
> ("net: Add frag_list support to skb_segment"), quote:
>
> As such we require all frag_list members terminate on exact MSS
> boundaries. This is checked using BUG_ON.
> As there should only be one producer in the kernel of such packets,
> namely GRO, this requirement should not be difficult to maintain.
>
> However, since commit 6578171a7ff0 ("bpf: add bpf_skb_change_proto helper"),
> the "exact MSS boundaries" assumption no longer holds:
> An eBPF program using bpf_skb_change_proto() DOES modify 'gso_size', but
> leaves the frag_list members as originally merged by GRO with the
> original 'gso_size'. Example of such programs are bpf-based NAT46 or
> NAT64.
>
> This lead to a kernel BUG_ON for flows involving:
> - GRO generating a frag_list skb
> - bpf program performing bpf_skb_change_proto() or bpf_skb_adjust_room()
> - skb_segment() of the skb
>
> See example BUG_ON reports in [0].
>
> In commit 13acc94eff12 ("net: permit skb_segment on head_frag frag_list skb"),
> skb_segment() was modified to support the "gso_size mangling" case of
> a frag_list GRO'ed skb, but *only* for frag_list members having
> head_frag==true (having a page-fragment head).
>
> Alas, GRO packets having frag_list members with a linear kmalloced head
> (head_frag==false) still hit the BUG_ON.
>
> This commit adds support to skb_segment() for a 'head_skb' packet having
> a frag_list whose members are *non* head_frag, with gso_size mangled, by
> disabling SG and thus falling-back to copying the data from the given
> 'head_skb' into the generated segmented skbs - as suggested by Willem de
> Bruijn [1].
>
> Since this approach involves the penalty of skb_copy_and_csum_bits()
> when building the segments, care was taken in order to enable this
> solution only when required:
> - untrusted gso_size, by testing SKB_GSO_DODGY is set
> (SKB_GSO_DODGY is set by any gso_size mangling functions in
> net/core/filter.c)
> - the frag_list is non empty, its item is a non head_frag, *and* the
> headlen of the given 'head_skb' does not match the gso_size.
>
> [0]
> https://lore.kernel.org/netdev/20190826170724.25ff616f@pixies/
> https://lore.kernel.org/netdev/9265b93f-253d-6b8c-f2b8-4b54eff1835c@fb.com/
>
> [1]
> https://lore.kernel.org/netdev/CA+FuTSfVsgNDi7c=GUU8nMg2hWxF2SjCNLXetHeVPdnxAW5K-w@mail.gmail.com/
>
> Fixes: 6578171a7ff0 ("bpf: add bpf_skb_change_proto helper")
> Suggested-by: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Alexander Duyck <alexander.duyck@gmail.com>
> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
> ---
> v2: reorder the test conditions, as suggested by Alexander Duyck
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] ionic: Remove unused including <linux/version.h>
From: David Miller @ 2019-09-07 16:01 UTC (permalink / raw)
To: yuehaibing; +Cc: snelson, drivers, netdev, kernel-janitors
In-Reply-To: <20190906095410.107596-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Fri, 6 Sep 2019 09:54:09 +0000
> Remove including <linux/version.h> that don't need it.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH] be2net: make two arrays static const, makes object smaller
From: David Miller @ 2019-09-07 16:02 UTC (permalink / raw)
To: colin.king
Cc: sathya.perla, ajit.khaparde, sriharsha.basavapatna, somnath.kotur,
netdev, kernel-janitors, linux-kernel
In-Reply-To: <20190906111943.5285-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 6 Sep 2019 12:19:43 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Don't populate the arrays on the stack but instead make them
> static const. Makes the object code smaller by 281 bytes.
>
> Before:
> text data bss dec hex filename
> 87553 5672 0 93225 16c29 benet/be_cmds.o
>
> After:
> text data bss dec hex filename
> 87112 5832 0 92944 16b10 benet/be_cmds.o
>
> (gcc version 9.2.1, amd64)
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ 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