* Re: [PATCH net-next] qed: Mark expected switch fall-through
From: David Miller @ 2019-01-23 17:07 UTC (permalink / raw)
To: gustavo; +Cc: Ariel.Elior, everest-linux-l2, netdev, linux-kernel
In-Reply-To: <20190123075912.GA28104@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Wed, 23 Jan 2019 01:59:12 -0600
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> This patch fixes the following warning:
>
> drivers/net/ethernet/qlogic/qed/qed_cxt.c:2126:4: warning: this statement may fall through [-Wimplicit-fallthrough=]
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> This patch is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bna: Mark expected switch fall-throughs
From: David Miller @ 2019-01-23 17:07 UTC (permalink / raw)
To: skalluru
Cc: gustavo, rasesh.mody, sudarsana.kalluru, Dept-GELinuxNICDev,
netdev, linux-kernel
In-Reply-To: <CY4PR18MB125398716A4A84409D301F7AD3990@CY4PR18MB1253.namprd18.prod.outlook.com>
From: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Date: Wed, 23 Jan 2019 08:03:12 +0000
> -----Original Message-----
> From: Gustavo A. R. Silva [mailto:gustavo@embeddedor.com]
> Sent: 23 January 2019 13:23
> To: Rasesh Mody <rasesh.mody@cavium.com>; Sudarsana Kalluru <sudarsana.kalluru@cavium.com>; Dept-GELinuxNICDev@cavium.com; David S. Miller <davem@davemloft.net>
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Gustavo A. R. Silva <gustavo@embeddedor.com>
> Subject: [PATCH net-next] bna: Mark expected switch fall-throughs
>
> External Email
>
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warnings:
>
> drivers/net/ethernet/brocade/bna/bfa_ioc.c:790:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
> drivers/net/ethernet/brocade/bna/bfa_ioc.c:860:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net/mlx4: Mark expected switch fall-through
From: David Miller @ 2019-01-23 17:08 UTC (permalink / raw)
To: gustavo; +Cc: tariqt, netdev, linux-rdma, linux-kernel
In-Reply-To: <20190123080511.GA32528@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Wed, 23 Jan 2019 02:05:11 -0600
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> This patch fixes the following warning:
>
> drivers/net/ethernet/mellanox/mlx4/eq.c: In function ‘mlx4_eq_int’:
> drivers/net/ethernet/mellanox/mlx4/mlx4.h:219:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
> if (mlx4_debug_level) \
> ^
> drivers/net/ethernet/mellanox/mlx4/eq.c:558:4: note: in expansion of macro ‘mlx4_dbg’
> mlx4_dbg(dev, "%s: MLX4_EVENT_TYPE_SRQ_LIMIT. srq_no=0x%x, eq 0x%x\n",
> ^~~~~~~~
> drivers/net/ethernet/mellanox/mlx4/eq.c:561:3: note: here
> case MLX4_EVENT_TYPE_SRQ_CATAS_ERROR:
> ^~~~
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> This patch is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 05/10] net: phy: introduce a phy_driver macsec helper
From: Andrew Lunn @ 2019-01-23 17:08 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, sd, f.fainelli, hkallweit1, netdev, linux-kernel,
thomas.petazzoni, alexandre.belloni, quentin.schulz,
allan.nielsen
In-Reply-To: <20190123155638.13852-6-antoine.tenart@bootlin.com>
> +int phy_macsec(struct phy_device *phydev, struct netdev_macsec *macsec)
> +{
> + int ret = -EOPNOTSUPP;
> +
> + if (!phydev->drv)
> + return -EIO;
> +
> + mutex_lock(&phydev->lock);
> +
> + if (phydev->drv->macsec)
> + ret = phydev->drv->macsec(phydev, macsec);
> +
> + mutex_unlock(&phydev->lock);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_macsec);
> +
> @@ -630,6 +634,10 @@ struct phy_driver {
> struct ethtool_tunable *tuna,
> const void *data);
> int (*set_loopback)(struct phy_device *dev, bool enable);
> +
> +#ifdef CONFIG_MACSEC
> + int (*macsec)(struct phy_device *dev, struct netdev_macsec *macsec);
> +#endif
Hi Antoine
So the member only exists if CONFIG_MACSEC is defined. So i think you
need similar protection in phy_macsec() or you are going to try to
access a member which sometimes does not exist.
Andrew
^ permalink raw reply
* Re: stable backport for the BPF speculation series? [was: Re: [PATCH bpf v3 0/9] bpf fix to prevent oob under speculation]
From: Jann Horn @ 2019-01-23 17:12 UTC (permalink / raw)
To: Greg Kroah-Hartman, Daniel Borkmann
Cc: David S. Miller, Alexei Starovoitov, Alexei Starovoitov,
jakub.kicinski, Network Development
In-Reply-To: <20190123170454.GC30381@kroah.com>
On Wed, Jan 23, 2019 at 6:04 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Tue, Jan 22, 2019 at 03:36:54PM +0100, Jann Horn wrote:
> > On Thu, Jan 3, 2019 at 1:08 AM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > > On Thu, Jan 03, 2019 at 12:58:26AM +0100, Daniel Borkmann wrote:
> > > > This set fixes an out of bounds case under speculative execution
> > > > by implementing masking of pointer alu into the verifier. For
> > > > details please see the individual patches.
> > > >
> > > > Thanks!
> > > >
> > > > v2 -> v3:
> > > > - 8/9: change states_equal condition into old->speculative &&
> > > > !cur->speculative, thanks Jakub!
> > > > - 8/9: remove incorrect speculative state test in
> > > > propagate_liveness(), thanks Jakub!
> > > > v1 -> v2:
> > > > - Typo fixes in commit msg and a comment, thanks David!
> > >
> > > Applied, Thanks
> >
> > This series and the followup fix ("bpf: fix sanitation of alu op with
> > pointer / scalar type from different paths") have been in Linus' tree
> > for six days, but from what I can tell, they aren't queued up for
> > stable yet.
>
> What are the git commit ids of the patches you think should be
> backported?
Daniel Borkmann said at
https://marc.info/?l=linux-netdev&m=154820859831443&w=2 :
| Will get this to stable towards end of week. We wanted to let this sit
| for a while in Linus' tree given the complexity of the fix to get some
| more coverage. We also need 9d5564ddcf2a ("bpf: fix inner map masking
|to prevent oob under speculation") in addition.
, so I expect that he's going to submit a request for stable inclusion
in the next few days. The git commits are:
c08435ec7f2bc8f4109401f696fd55159b4b40cb
144cd91c4c2bced6eb8a7e25e590f6618a11e854
9b73bfdd08e73231d6a90ae6db4b46b3fbf56c30
0d6303db7970e6f56ae700fa07e11eb510cda125
e4298d25830a866cc0f427d4bccb858e76715859
9d7eceede769f90b66cfa06ad5b357140d5141ed
b7137c4eab85c1cf3d46acdde90ce1163b28c873
979d63d50c0c0f7bc537bf821e056cc9fe5abd38
d3bd7413e0ca40b60cf60d4003246d067cafdeda
9d5564ddcf2a0f5ba3fa1c3a1f8a1b59ad309553
^ permalink raw reply
* [PATCH net-next] bonding: count master 3ad stats separately
From: Nikolay Aleksandrov @ 2019-01-23 17:14 UTC (permalink / raw)
To: netdev; +Cc: j.vosburgh, roopa, vfalico, andy, davem, Nikolay Aleksandrov
I made a dumb mistake when I summed up the slave stats, obviously slaves
can come and go which would make the master stats unreliable.
Count and export the master stats separately.
Fixes: a258aeacd7f0 ("bonding: add support for xstats and export 3ad stats")
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
drivers/net/bonding/bond_3ad.c | 39 ++++++++++--------------------
drivers/net/bonding/bond_netlink.c | 18 ++++++--------
include/net/bond_3ad.h | 2 +-
3 files changed, 21 insertions(+), 38 deletions(-)
diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index d30c21b34858..9274dcc6e9b0 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
@@ -853,6 +853,7 @@ static int ad_lacpdu_send(struct port *port)
return -ENOMEM;
atomic64_inc(&SLAVE_AD_INFO(slave)->stats.lacpdu_tx);
+ atomic64_inc(&BOND_AD_INFO(slave->bond).stats.lacpdu_tx);
skb->dev = slave->dev;
skb_reset_mac_header(skb);
@@ -898,9 +899,11 @@ static int ad_marker_send(struct port *port, struct bond_marker *marker)
switch (marker->tlv_type) {
case AD_MARKER_INFORMATION_SUBTYPE:
atomic64_inc(&SLAVE_AD_INFO(slave)->stats.marker_tx);
+ atomic64_inc(&BOND_AD_INFO(slave->bond).stats.marker_tx);
break;
case AD_MARKER_RESPONSE_SUBTYPE:
atomic64_inc(&SLAVE_AD_INFO(slave)->stats.marker_resp_tx);
+ atomic64_inc(&BOND_AD_INFO(slave->bond).stats.marker_resp_tx);
break;
}
@@ -1098,9 +1101,10 @@ static void ad_rx_machine(struct lacpdu *lacpdu, struct port *port)
*/
last_state = port->sm_rx_state;
- if (lacpdu)
+ if (lacpdu) {
atomic64_inc(&SLAVE_AD_INFO(port->slave)->stats.lacpdu_rx);
-
+ atomic64_inc(&BOND_AD_INFO(port->slave->bond).stats.lacpdu_rx);
+ }
/* check if state machine should change state */
/* first, check if port was reinitialized */
@@ -1938,6 +1942,7 @@ static void ad_marker_info_received(struct bond_marker *marker_info,
struct bond_marker marker;
atomic64_inc(&SLAVE_AD_INFO(port->slave)->stats.marker_rx);
+ atomic64_inc(&BOND_AD_INFO(port->slave->bond).stats.marker_rx);
/* copy the received marker data to the response marker */
memcpy(&marker, marker_info, sizeof(struct bond_marker));
@@ -1964,6 +1969,7 @@ static void ad_marker_response_received(struct bond_marker *marker,
struct port *port)
{
atomic64_inc(&SLAVE_AD_INFO(port->slave)->stats.marker_resp_rx);
+ atomic64_inc(&BOND_AD_INFO(port->slave->bond).stats.marker_resp_rx);
/* DO NOTHING, SINCE WE DECIDED NOT TO IMPLEMENT THIS FEATURE FOR NOW */
}
@@ -2374,6 +2380,7 @@ void bond_3ad_state_machine_handler(struct work_struct *work)
*/
static int bond_3ad_rx_indication(struct lacpdu *lacpdu, struct slave *slave)
{
+ struct bonding *bond = slave->bond;
int ret = RX_HANDLER_ANOTHER;
struct bond_marker *marker;
struct port *port;
@@ -2419,10 +2426,13 @@ static int bond_3ad_rx_indication(struct lacpdu *lacpdu, struct slave *slave)
port->actor_port_number);
stat = &SLAVE_AD_INFO(slave)->stats.marker_unknown_rx;
atomic64_inc(stat);
+ stat = &BOND_AD_INFO(bond).stats.marker_unknown_rx;
+ atomic64_inc(stat);
}
break;
default:
atomic64_inc(&SLAVE_AD_INFO(slave)->stats.lacpdu_unknown_rx);
+ atomic64_inc(&BOND_AD_INFO(bond).stats.lacpdu_unknown_rx);
}
return ret;
@@ -2662,6 +2672,7 @@ int bond_3ad_lacpdu_recv(const struct sk_buff *skb, struct bonding *bond,
lacpdu = skb_header_pointer(skb, 0, sizeof(_lacpdu), &_lacpdu);
if (!lacpdu) {
atomic64_inc(&SLAVE_AD_INFO(slave)->stats.lacpdu_illegal_rx);
+ atomic64_inc(&BOND_AD_INFO(bond).stats.lacpdu_illegal_rx);
return RX_HANDLER_ANOTHER;
}
@@ -2698,30 +2709,6 @@ void bond_3ad_update_lacp_rate(struct bonding *bond)
spin_unlock_bh(&bond->mode_lock);
}
-void bond_3ad_stats_add(struct slave *slave, struct bond_3ad_stats *stats)
-{
- struct bond_3ad_stats *rstats = &SLAVE_AD_INFO(slave)->stats;
- u64 stat;
-
- atomic64_add(atomic64_read(&rstats->lacpdu_rx), &stats->lacpdu_rx);
- atomic64_add(atomic64_read(&rstats->lacpdu_tx), &stats->lacpdu_tx);
-
- stat = atomic64_read(&rstats->lacpdu_unknown_rx);
- atomic64_add(stat, &stats->lacpdu_unknown_rx);
- stat = atomic64_read(&rstats->lacpdu_illegal_rx);
- atomic64_add(stat, &stats->lacpdu_illegal_rx);
-
- atomic64_add(atomic64_read(&rstats->marker_rx), &stats->marker_rx);
- atomic64_add(atomic64_read(&rstats->marker_tx), &stats->marker_tx);
-
- stat = atomic64_read(&rstats->marker_resp_rx);
- atomic64_add(stat, &stats->marker_resp_rx);
- stat = atomic64_read(&rstats->marker_resp_tx);
- atomic64_add(stat, &stats->marker_resp_tx);
- stat = atomic64_read(&rstats->marker_unknown_rx);
- atomic64_add(stat, &stats->marker_unknown_rx);
-}
-
size_t bond_3ad_stats_size(void)
{
return nla_total_size_64bit(sizeof(u64)) + /* BOND_3AD_STAT_LACPDU_RX */
diff --git a/drivers/net/bonding/bond_netlink.c b/drivers/net/bonding/bond_netlink.c
index d1338fbe1830..b286f591242e 100644
--- a/drivers/net/bonding/bond_netlink.c
+++ b/drivers/net/bonding/bond_netlink.c
@@ -715,16 +715,12 @@ static int bond_fill_linkxstats(struct sk_buff *skb,
if (!nest)
return -EMSGSIZE;
if (BOND_MODE(bond) == BOND_MODE_8023AD) {
- struct bond_3ad_stats stats;
- struct list_head *iter;
-
- memset(&stats, 0, sizeof(stats));
- if (slave) {
- bond_3ad_stats_add(slave, &stats);
- } else {
- bond_for_each_slave(bond, slave, iter)
- bond_3ad_stats_add(slave, &stats);
- }
+ struct bond_3ad_stats *stats;
+
+ if (slave)
+ stats = &SLAVE_AD_INFO(slave)->stats;
+ else
+ stats = &BOND_AD_INFO(bond).stats;
nest2 = nla_nest_start(skb, BOND_XSTATS_3AD);
if (!nest2) {
@@ -732,7 +728,7 @@ static int bond_fill_linkxstats(struct sk_buff *skb,
return -EMSGSIZE;
}
- if (bond_3ad_stats_fill(skb, &stats)) {
+ if (bond_3ad_stats_fill(skb, stats)) {
nla_nest_cancel(skb, nest2);
nla_nest_end(skb, nest);
return -EMSGSIZE;
diff --git a/include/net/bond_3ad.h b/include/net/bond_3ad.h
index 25aaf49d19be..c781e1afd683 100644
--- a/include/net/bond_3ad.h
+++ b/include/net/bond_3ad.h
@@ -278,6 +278,7 @@ struct ad_system {
struct ad_bond_info {
struct ad_system system; /* 802.3ad system structure */
+ struct bond_3ad_stats stats;
u32 agg_select_timer; /* Timer to select aggregator after all adapter's hand shakes */
u16 aggregator_identifier;
};
@@ -321,7 +322,6 @@ int bond_3ad_lacpdu_recv(const struct sk_buff *skb, struct bonding *bond,
int bond_3ad_set_carrier(struct bonding *bond);
void bond_3ad_update_lacp_rate(struct bonding *bond);
void bond_3ad_update_ad_actor_settings(struct bonding *bond);
-void bond_3ad_stats_add(struct slave *slave, struct bond_3ad_stats *stats);
int bond_3ad_stats_fill(struct sk_buff *skb, struct bond_3ad_stats *stats);
size_t bond_3ad_stats_size(void);
#endif /* _NET_BOND_3AD_H */
--
2.20.1
^ permalink raw reply related
* [PATCH v3 bpf-next] bpf: allow BPF programs access skb_shared_info->gso_segs field
From: Eric Dumazet @ 2019-01-23 17:22 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Daniel Borkmann, netdev, Eric Dumazet, Eric Dumazet, Eddie Hao,
Martin KaFai Lau
This adds the ability to read gso_segs from a BPF program.
v3: Use BPF_REG_AX instead of BPF_REG_TMP for the temporary register,
as suggested by Martin.
v2: refined Eddie Hao patch to address Alexei feedback.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Eddie Hao <eddieh@google.com>
Cc: Martin KaFai Lau <kafai@fb.com>
---
include/uapi/linux/bpf.h | 1 +
net/core/filter.c | 21 ++++++++++++
tools/include/uapi/linux/bpf.h | 1 +
tools/testing/selftests/bpf/test_verifier.c | 36 +++++++++++++++++++++
4 files changed, 59 insertions(+)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 91c43884f295f60a85268ddf0020bf8aa47f8329..2940a9854f6d8e493518ca894e0c9c630ae4ab7a 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -2540,6 +2540,7 @@ struct __sk_buff {
__bpf_md_ptr(struct bpf_flow_keys *, flow_keys);
__u64 tstamp;
__u32 wire_len;
+ __u32 gso_segs;
};
struct bpf_tunnel_key {
diff --git a/net/core/filter.c b/net/core/filter.c
index 2b3b436ef5457bf44c99780d6dec0b5f403f005c..8e587dd1da200494b900bd14eec7f875f5453773 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -6700,6 +6700,27 @@ static u32 bpf_convert_ctx_access(enum bpf_access_type type,
target_size));
break;
+ case offsetof(struct __sk_buff, gso_segs):
+ /* si->dst_reg = skb_shinfo(SKB); */
+#ifdef NET_SKBUFF_DATA_USES_OFFSET
+ *insn++ = BPF_LDX_MEM(BPF_FIELD_SIZEOF(struct sk_buff, head),
+ si->dst_reg, si->src_reg,
+ offsetof(struct sk_buff, head));
+ *insn++ = BPF_LDX_MEM(BPF_FIELD_SIZEOF(struct sk_buff, end),
+ BPF_REG_AX, si->src_reg,
+ offsetof(struct sk_buff, end));
+ *insn++ = BPF_ALU64_REG(BPF_ADD, si->dst_reg, BPF_REG_AX);
+#else
+ *insn++ = BPF_LDX_MEM(BPF_FIELD_SIZEOF(struct sk_buff, end),
+ si->dst_reg, si->src_reg,
+ offsetof(struct sk_buff, end));
+#endif
+ *insn++ = BPF_LDX_MEM(BPF_FIELD_SIZEOF(struct skb_shared_info, gso_segs),
+ si->dst_reg, si->dst_reg,
+ bpf_target_off(struct skb_shared_info,
+ gso_segs, 2,
+ target_size));
+ break;
case offsetof(struct __sk_buff, wire_len):
BUILD_BUG_ON(FIELD_SIZEOF(struct qdisc_skb_cb, pkt_len) != 4);
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 91c43884f295f60a85268ddf0020bf8aa47f8329..2940a9854f6d8e493518ca894e0c9c630ae4ab7a 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -2540,6 +2540,7 @@ struct __sk_buff {
__bpf_md_ptr(struct bpf_flow_keys *, flow_keys);
__u64 tstamp;
__u32 wire_len;
+ __u32 gso_segs;
};
struct bpf_tunnel_key {
diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
index 2fd90d4568926d13542783c870507d43a6d6bb64..2c46531044bdf9ec1e4fa47e2c94c9edb0ac3d08 100644
--- a/tools/testing/selftests/bpf/test_verifier.c
+++ b/tools/testing/selftests/bpf/test_verifier.c
@@ -5663,6 +5663,42 @@ static struct bpf_test tests[] = {
.result = ACCEPT,
.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
},
+ {
+ "read gso_segs from CGROUP_SKB",
+ .insns = {
+ BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_1,
+ offsetof(struct __sk_buff, gso_segs)),
+ BPF_MOV64_IMM(BPF_REG_0, 0),
+ BPF_EXIT_INSN(),
+ },
+ .result = ACCEPT,
+ .prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+ },
+ {
+ "write gso_segs from CGROUP_SKB",
+ .insns = {
+ BPF_MOV64_IMM(BPF_REG_0, 0),
+ BPF_STX_MEM(BPF_W, BPF_REG_1, BPF_REG_0,
+ offsetof(struct __sk_buff, gso_segs)),
+ BPF_MOV64_IMM(BPF_REG_0, 0),
+ BPF_EXIT_INSN(),
+ },
+ .result = REJECT,
+ .result_unpriv = REJECT,
+ .errstr = "invalid bpf_context access off=164 size=4",
+ .prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+ },
+ {
+ "read gso_segs from CLS",
+ .insns = {
+ BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_1,
+ offsetof(struct __sk_buff, gso_segs)),
+ BPF_MOV64_IMM(BPF_REG_0, 0),
+ BPF_EXIT_INSN(),
+ },
+ .result = ACCEPT,
+ .prog_type = BPF_PROG_TYPE_SCHED_CLS,
+ },
{
"multiple registers share map_lookup_elem result",
.insns = {
--
2.20.1.321.g9e740568ce-goog
^ permalink raw reply related
* Re: [PATCH net-next V4 0/5] vhost: accelerate metadata access through vmap()
From: David Miller @ 2019-01-23 17:24 UTC (permalink / raw)
To: mst; +Cc: jasowang, virtualization, netdev, linux-kernel, kvm
In-Reply-To: <20190123085652-mutt-send-email-mst@kernel.org>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Wed, 23 Jan 2019 08:58:07 -0500
> On Wed, Jan 23, 2019 at 05:55:52PM +0800, Jason Wang wrote:
>> This series tries to access virtqueue metadata through kernel virtual
>> address instead of copy_user() friends since they had too much
>> overheads like checks, spec barriers or even hardware feature
>> toggling.
>>
>> Test shows about 24% improvement on TX PPS. It should benefit other
>> cases as well.
>
> ok I think this addresses most comments but it's a big change and we
> just started 1.1 review so to pls give me a week to review this ok?
Ok. :)
^ permalink raw reply
* [PATCH bpf-next] selftests/bpf: suppress readelf stderr when probing for BTF support
From: Stanislav Fomichev @ 2019-01-23 17:24 UTC (permalink / raw)
To: netdev; +Cc: davem, ast, daniel, Stanislav Fomichev
Before:
$ make -s -C tools/testing/selftests/bpf
readelf: Error: Missing knowledge of 32-bit reloc types used in DWARF
sections of machine number 247
readelf: Warning: unable to apply unsupported reloc type 10 to section
.debug_info
readelf: Warning: unable to apply unsupported reloc type 1 to section
.debug_info
readelf: Warning: unable to apply unsupported reloc type 10 to section
.debug_info
After:
$ make -s -C tools/testing/selftests/bpf
Signed-off-by: Stanislav Fomichev <sdf@google.com>
---
tools/testing/selftests/bpf/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index 70229de510f5..ff3cab5525c1 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -131,7 +131,7 @@ BTF_PAHOLE_PROBE := $(shell $(BTF_PAHOLE) --help 2>&1 | grep BTF)
BTF_OBJCOPY_PROBE := $(shell $(LLVM_OBJCOPY) --help 2>&1 | grep -i 'usage.*llvm')
BTF_LLVM_PROBE := $(shell echo "int main() { return 0; }" | \
$(CLANG) -target bpf -O2 -g -c -x c - -o ./llvm_btf_verify.o; \
- readelf -S ./llvm_btf_verify.o | grep BTF; \
+ readelf -S ./llvm_btf_verify.o 2>/dev/null | grep BTF; \
/bin/rm -f ./llvm_btf_verify.o)
ifneq ($(BTF_LLVM_PROBE),)
--
2.20.1.321.g9e740568ce-goog
^ permalink raw reply related
* Want to edit your photos
From: Judy @ 2019-01-23 6:57 UTC (permalink / raw)
To: netdev
We want to work for you to edit your photos.
We can do your photos with white background, sharpen, retouching is
included for all your photos.
Waiting for the test photos to start with.
Thanks,
Judy
^ permalink raw reply
* Re: [PATCH v2 net] ravb: expand rx descriptor data to accommodate hw checksum
From: David Miller @ 2019-01-23 17:25 UTC (permalink / raw)
To: horms+renesas; +Cc: sergei.shtylyov, magnus.damm, netdev, linux-renesas-soc
In-Reply-To: <20190123111452.27845-1-horms+renesas@verge.net.au>
From: Simon Horman <horms+renesas@verge.net.au>
Date: Wed, 23 Jan 2019 12:14:52 +0100
> EtherAVB may provide a checksum of packet data appended to packet data. In
> order to allow this checksum to be received by the host descriptor data
> needs to be enlarged by 2 bytes to accommodate the checksum.
>
> In the case of MTU-sized packets without a VLAN tag the
> checksum were already accommodated by virtue of the space reserved for the
> VLAN tag. However, a packet of MTU-size with a VLAN tag consumed all
> packet data space provided by a descriptor leaving no space for the
> trailing checksum.
>
> This was not detected by the driver which incorrectly used the last two
> bytes of packet data as the checksum and truncate the packet by two bytes.
> This resulted all such packets being dropped.
>
> A work around is to disable RX checksum offload
> # ethtool -K eth0 rx off
>
> This patch resolves this problem by increasing the size available for
> packet data in RX descriptors by two bytes.
>
> Tested on R-Car E3 (r8a77990) ES1.0 based Ebisu-4D board
>
> v2
> * Use sizeof(__sum16) directly rather than adding a driver-local
> #define for the size of the checksum provided by the hw (2 bytes).
>
> Fixes: 4d86d3818627 ("ravb: RX checksum offload")
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next 0/4] mlxsw: Add VXLAN support for Spectrum-2
From: David Miller @ 2019-01-23 17:28 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, petrm, mlxsw
In-Reply-To: <20190123143217.17735-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Wed, 23 Jan 2019 14:32:53 +0000
> This patchset adds support for VXLAN tunneling on the Spectrum-2 ASIC.
> Spectrum-1 and Spectrum-2 are largely backward compatible in this area,
> so not too many changes are required.
>
> Patches #1-#2 expose a function and perform small refactoring towards
> the actual Spectrum-2 implementation in patches #3-#4.
>
> Patch #3 adds the required initialization steps on Spectrum-2.
>
> Patch #4 finally enables VXLAN on Spectrum-2.
Series applied, thanks!
^ permalink raw reply
* Re: [PATCH net-next] intel: Mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2019-01-23 17:11 UTC (permalink / raw)
To: jeffrey.t.kirsher, David S. Miller; +Cc: intel-wired-lan, netdev, linux-kernel
In-Reply-To: <e356e64d3267bbca1cfa0373b7ce965edaf159bd.camel@intel.com>
Hi Jeffrey,
On 1/23/19 11:04 AM, Jeff Kirsher wrote:
> On Wed, 2019-01-23 at 01:48 -0600, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>>
>> This patch fixes the following warnings:
>>
>> drivers/net/ethernet/intel/igb/e1000_82575.c:636:6: warning: this
>> statement may fall through [-Wimplicit-fallthrough=]
>> drivers/net/ethernet/intel/igb/igb_main.c:6710:6: warning: this
>> statement may fall through [-Wimplicit-fallthrough=]
>> drivers/net/ethernet/intel/i40e/i40e_xsk.c:237:3: warning: this
>> statement may fall through [-Wimplicit-fallthrough=]
>>
>> Warning level 3 was used: -Wimplicit-fallthrough=3
>>
>> This patch is part of the ongoing efforts to enabling
>> -Wimplicit-fallthrough.
>>
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>> ---
>> drivers/net/ethernet/intel/i40e/i40e_xsk.c | 3 ++-
>> drivers/net/ethernet/intel/igb/e1000_82575.c | 2 +-
>> drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
>> 3 files changed, 4 insertions(+), 3 deletions(-)
>
> NAK on the igb changes. There is already a "fall through" code comment
> which is fine, adding a hyphen does not make the comment any more
> readable.
>
Those comments are not fine. They trigger the warnings I mention in the
commit log. With this patch such warnings are fixed.
Notice that warning level 3 was used: -Wimplicit-fallthrough=3
Thanks
--
Gustavo
^ permalink raw reply
* Re: [PATCH net-next] intel: Mark expected switch fall-throughs
From: Jeff Kirsher @ 2019-01-23 17:44 UTC (permalink / raw)
To: Gustavo A. R. Silva, David S. Miller
Cc: intel-wired-lan, netdev, linux-kernel
In-Reply-To: <368769c1-bb6c-b137-14c4-ef0ade488c2e@embeddedor.com>
[-- Attachment #1: Type: text/plain, Size: 2121 bytes --]
On Wed, 2019-01-23 at 11:11 -0600, Gustavo A. R. Silva wrote:
> Hi Jeffrey,
>
> On 1/23/19 11:04 AM, Jeff Kirsher wrote:
> > On Wed, 2019-01-23 at 01:48 -0600, Gustavo A. R. Silva wrote:
> > > In preparation to enabling -Wimplicit-fallthrough, mark switch
> > > cases
> > > where we are expecting to fall through.
> > >
> > > This patch fixes the following warnings:
> > >
> > > drivers/net/ethernet/intel/igb/e1000_82575.c:636:6: warning: this
> > > statement may fall through [-Wimplicit-fallthrough=]
> > > drivers/net/ethernet/intel/igb/igb_main.c:6710:6: warning: this
> > > statement may fall through [-Wimplicit-fallthrough=]
> > > drivers/net/ethernet/intel/i40e/i40e_xsk.c:237:3: warning: this
> > > statement may fall through [-Wimplicit-fallthrough=]
> > >
> > > Warning level 3 was used: -Wimplicit-fallthrough=3
> > >
> > > This patch is part of the ongoing efforts to enabling
> > > -Wimplicit-fallthrough.
> > >
> > > Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> > > ---
> > > drivers/net/ethernet/intel/i40e/i40e_xsk.c | 3 ++-
> > > drivers/net/ethernet/intel/igb/e1000_82575.c | 2 +-
> > > drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
> > > 3 files changed, 4 insertions(+), 3 deletions(-)
> >
> > NAK on the igb changes. There is already a "fall through" code
> > comment
> > which is fine, adding a hyphen does not make the comment any more
> > readable.
> >
>
> Those comments are not fine. They trigger the warnings I mention in
> the
> commit log. With this patch such warnings are fixed.
>
> Notice that warning level 3 was used: -Wimplicit-fallthrough=3
This is a "false positive" based on the compiler option definition:
-Wimplicit-fallthrough=3 case sensitively matches a wide range of
regular expressions, listed in the GCC manual. E.g., all of these are
accepted:
/* Falls through. */
/* fall-thru */
/* Else falls through. */
/* FALLTHRU */
/* … falls through … */
etc.
You should be looking to fix the problem with the compiler option,
which is reporting "acceptable" code comments.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] Bluetooth: Mark expected switch fall-throughs
From: Marcel Holtmann @ 2019-01-23 17:46 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Johan Hedberg, David S. Miller, Bluez mailing list, netdev,
linux-kernel
In-Reply-To: <20190123072031.GA9678@embeddedor>
Hi Gustavo,
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> This patch fixes the following warnings:
>
> net/bluetooth/rfcomm/core.c:479:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
> net/bluetooth/l2cap_core.c:4223:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> This patch is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
> net/bluetooth/l2cap_core.c | 1 +
> net/bluetooth/rfcomm/core.c | 1 +
> 2 files changed, 2 insertions(+)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v3 bpf-next] bpf: allow BPF programs access skb_shared_info->gso_segs field
From: Martin Lau @ 2019-01-23 17:56 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alexei Starovoitov, Daniel Borkmann, netdev, Eric Dumazet,
Eddie Hao
In-Reply-To: <20190123172227.203429-1-edumazet@google.com>
On Wed, Jan 23, 2019 at 09:22:27AM -0800, Eric Dumazet wrote:
> This adds the ability to read gso_segs from a BPF program.
Acked-by: Martin KaFai Lau <kafai@fb.com>
^ permalink raw reply
* Re: [PATCH net-next] Bluetooth: Mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2019-01-23 18:04 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Johan Hedberg, David S. Miller, Bluez mailing list, netdev,
linux-kernel
In-Reply-To: <1AA1243F-A0CD-4124-A2D8-DB3648E4C922@holtmann.org>
On 1/23/19 11:46 AM, Marcel Holtmann wrote:
> Hi Gustavo,
>
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>>
>> This patch fixes the following warnings:
>>
>> net/bluetooth/rfcomm/core.c:479:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
>> net/bluetooth/l2cap_core.c:4223:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
>>
>> Warning level 3 was used: -Wimplicit-fallthrough=3
>>
>> This patch is part of the ongoing efforts to enabling
>> -Wimplicit-fallthrough.
>>
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>> ---
>> net/bluetooth/l2cap_core.c | 1 +
>> net/bluetooth/rfcomm/core.c | 1 +
>> 2 files changed, 2 insertions(+)
>
> patch has been applied to bluetooth-next tree.
>
Thank you, Marcel.
--
Gustavo
^ permalink raw reply
* [GIT PULL] Hyper-V hv_netvsc commits for 5.0
From: Sasha Levin @ 2019-01-23 18:30 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, kys, haiyangz, sthemmin, linux-kernel, netdev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:
Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git tags/hyperv-fixes-signed
for you to fetch changes up to 52d3b4949192e93b948daaa40678fcd4b94bcbd0:
hv_netvsc: fix typos in code comments (2019-01-23 13:21:34 -0500)
- ----------------------------------------------------------------
Three patches from Haiyang Zhang to fix settings hash key using ethtool,
and Adrian Vladu's first patch fixing a few spelling mistakes.
- ----------------------------------------------------------------
Adrian Vladu (1):
hv_netvsc: fix typos in code comments
Haiyang Zhang (3):
hv_netvsc: Fix ethtool change hash key error
hv_netvsc: Refactor assignments of struct netvsc_device_info
hv_netvsc: Fix hash key value reset after other ops
drivers/net/hyperv/hyperv_net.h | 12 ++--
drivers/net/hyperv/netvsc.c | 4 +-
drivers/net/hyperv/netvsc_drv.c | 145 ++++++++++++++++++++++++--------------
drivers/net/hyperv/rndis_filter.c | 36 +++++++---
4 files changed, 129 insertions(+), 68 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAlxIssUACgkQ3qZv95d3
LNyezg/5ARp4trV4xYrKn9KY3ctgk2MQMBWfJyTnJP/MMwH9U7c0c7xlWke+2+vp
B+9tbRdPU1amHMSeounLiQNrkqBQlqYUtJdTXx5Yq9r76IEh7qTkDsMdBOq1Uxpn
DpmcbfelylTEcmMj8XbYokAKgNWdLIJZbcbYQjuHv+2pEO6DfH/SnB1zh25dHWNt
TO1zXRiTISJN2yLD1rayUzvx9KwMiQAfhMCtvfo8X/8us5X96WH/Isvzjfuon1Aa
iq7PuwV8gm2OFFzR+mlLoE33TmtytvUyWOdBDj3I7QNmhvCa4uMlJrFh0smML3yU
SAtBLDGkCOsREDVCwe7R/P2NFvAf8gCn1NZ3Vnaywwb3nvgUTdqUZqEiv3T7cePv
Eossh4hhKDWTkBxk6iSqP2L+SiSYbg845TZTP+iPhgBGEnlEn04YIUdftT/i5sYE
K1awGnE8DOmaOFhgG+rpHvBnOhb5azepTpbs0ajxAVec6+vVXtdKf3STa+xqKOOd
JS2uHj/aF+PeS1FuZbaZxfBEOzy7PVP6wAfu6ZkzIlpy6XKXnyiPvW8zRvs2YqfG
0XsKn7e/hZelZ2bQXLNllYyXZTNh54E/vvfC/4uGrHSgSMxBuW2N5s3oC75VJtLw
II+2oIsRuUU8v5EwvyNxsXxjvIU/BxNAYz9Vb5CQE3gaxjOAQgg=
=OV99
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH net-next] net/mlx4: Mark expected switch fall-through
From: Gustavo A. R. Silva @ 2019-01-23 18:09 UTC (permalink / raw)
To: David Miller; +Cc: tariqt, netdev, linux-rdma, linux-kernel
In-Reply-To: <20190123.090803.438719975498577995.davem@davemloft.net>
On 1/23/19 11:08 AM, David Miller wrote:
> From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
> Date: Wed, 23 Jan 2019 02:05:11 -0600
>
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>>
>> This patch fixes the following warning:
>>
>> drivers/net/ethernet/mellanox/mlx4/eq.c: In function ‘mlx4_eq_int’:
>> drivers/net/ethernet/mellanox/mlx4/mlx4.h:219:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
>> if (mlx4_debug_level) \
>> ^
>> drivers/net/ethernet/mellanox/mlx4/eq.c:558:4: note: in expansion of macro ‘mlx4_dbg’
>> mlx4_dbg(dev, "%s: MLX4_EVENT_TYPE_SRQ_LIMIT. srq_no=0x%x, eq 0x%x\n",
>> ^~~~~~~~
>> drivers/net/ethernet/mellanox/mlx4/eq.c:561:3: note: here
>> case MLX4_EVENT_TYPE_SRQ_CATAS_ERROR:
>> ^~~~
>>
>> Warning level 3 was used: -Wimplicit-fallthrough=3
>>
>> This patch is part of the ongoing efforts to enabling
>> -Wimplicit-fallthrough.
>>
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>
> Applied.
>
Thank you both, Tariq and David.
--
Gustavo
^ permalink raw reply
* Re: [PATCH] net: core: dev: Initialise napi state correctly
From: Eric Dumazet @ 2019-01-23 19:00 UTC (permalink / raw)
To: David McKay, Linux Networking
In-Reply-To: <CAOhhRxvVAts0N=ptDSaL5FoY_Uo2UseH5Zow2Q2nOYO6ujAS0Q@mail.gmail.com>
On 01/23/2019 10:49 AM, David McKay wrote:
> On Fri, 18 Jan 2019 at 17:15, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>
>>
>>
>> On 01/18/2019 04:46 AM, Dave McKay wrote:
>>> The state member of the napi_struct is not initialised correctly, it
>>> sets the SCHED bit without initialising the state to zero first. This
>>> results in peculiar behaviour if the original napi_struct didn't come
>>> from a zero initialised region to start with.
>>>
>>> This patch just sets it directly using the appropriate bitfield
>>> constant.
>>>
>>> Signed-off-by: Dave McKay <mckay.david@gmail.com>
>>> ---
>>> net/core/dev.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/net/core/dev.c b/net/core/dev.c
>>> index 82f20022259d..250f97bf1973 100644
>>> --- a/net/core/dev.c
>>> +++ b/net/core/dev.c
>>> @@ -6276,7 +6276,7 @@ void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
>>> #ifdef CONFIG_NETPOLL
>>> napi->poll_owner = -1;
>>> #endif
>>> - set_bit(NAPI_STATE_SCHED, &napi->state);
>>> + napi->state = NAPIF_STATE_SCHED;
>>> napi_hash_add(napi);
>>> }
>>> EXPORT_SYMBOL(netif_napi_add);
>>>
>>
>> I am curious, which driver has exhibit any issue with current code ?
>>
>
> gro_cell_init() maybe?
>
Perfect example of something that would break with your patch :/
alloc_percpu() clears all memory.
gro_cells_init() does :
set_bit(NAPI_STATE_NO_BUSY_POLL, &cell->napi.state);
netif_napi_add(dev, &cell->napi, gro_cell_poll, ...)
So clearing napi->state in netif_napi_add() would remove the NAPI_STATE_NO_BUSY_POLL setting.
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches
From: Kees Cook @ 2019-01-23 18:55 UTC (permalink / raw)
To: Jani Nikula
Cc: Edwin Zimmerman, Greg KH, dev, Ard Biesheuvel,
Network Development, intel-gfx, linux-usb, LKML,
Maling list - DRI developers, Linux-MM, linux-security-module,
Kernel Hardening, intel-wired-lan, linux-fsdevel@vger.kernel.org,
xen-devel, Laura Abbott, linux-kbuild, Alexander Popov
In-Reply-To: <87va2f1int.fsf@intel.com>
On Thu, Jan 24, 2019 at 4:44 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
>
> On Wed, 23 Jan 2019, Edwin Zimmerman <edwin@211mainstreet.net> wrote:
> > On Wed, 23 Jan 2019, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> >> On Wed, 23 Jan 2019, Greg KH <gregkh@linuxfoundation.org> wrote:
> >> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> >> >> Variables declared in a switch statement before any case statements
> >> >> cannot be initialized, so move all instances out of the switches.
> >> >> After this, future always-initialized stack variables will work
> >> >> and not throw warnings like this:
> >> >>
> >> >> fs/fcntl.c: In function ‘send_sigio_to_task’:
> >> >> fs/fcntl.c:738:13: warning: statement will never be executed [-Wswitch-unreachable]
> >> >> siginfo_t si;
> >> >> ^~
> >> >
> >> > That's a pain, so this means we can't have any new variables in { }
> >> > scope except for at the top of a function?
Just in case this wasn't clear: no, it's just the switch statement
before the first "case". I cannot imagine how bad it would be if we
couldn't have block-scoped variables! Heh. :)
> >> >
> >> > That's going to be a hard thing to keep from happening over time, as
> >> > this is valid C :(
> >>
> >> Not all valid C is meant to be used! ;)
> >
> > Very true. The other thing to keep in mind is the burden of enforcing
> > a prohibition on a valid C construct like this. It seems to me that
> > patch reviewers and maintainers have enough to do without forcing them
> > to watch for variable declarations in switch statements. Automating
> > this prohibition, should it be accepted, seems like a good idea to me.
>
> Considering that the treewide diffstat to fix this is:
>
> 18 files changed, 45 insertions(+), 46 deletions(-)
>
> and using the gcc plugin in question will trigger the switch-unreachable
> warning, I think we're good. There'll probably be the occasional
> declarations that pass through, and will get fixed afterwards.
Yeah, that was my thinking as well: it's a rare use, and we get a
warning when it comes up.
Thanks!
--
Kees Cook
^ permalink raw reply
* Re: [PATCH V2 net-next 00/12] code optimizations & bugfixes for HNS3 driver
From: David Miller @ 2019-01-23 19:13 UTC (permalink / raw)
To: tanhuazhong
Cc: eric.dumazet, netdev, linux-kernel, huangdaode, yisen.zhuang,
salil.mehta, linuxarm
In-Reply-To: <20190122233938.7188-1-tanhuazhong@huawei.com>
From: Huazhong Tan <tanhuazhong@huawei.com>
Date: Wed, 23 Jan 2019 07:39:26 +0800
> This patchset includes bugfixes and code optimizations for the HNS3
> ethernet controller driver
>
> Change log:
> V1->V2: fixes comment from Eric Dumazet
Series applied.
^ permalink raw reply
* Re: [PATCH net] sfc: suppress duplicate nvmem partition types in efx_ef10_mtd_probe
From: David Miller @ 2019-01-23 19:16 UTC (permalink / raw)
To: ecree; +Cc: linux-net-drivers, netdev
In-Reply-To: <8da9e562-4a07-f8b7-a870-a8b73dfc9ea7@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Tue, 22 Jan 2019 19:02:17 +0000
> Use a bitmap to keep track of which partition types we've already seen;
> for duplicates, return -EEXIST from efx_ef10_mtd_probe_partition() and
> thus skip adding that partition.
> Duplicate partitions occur because of the A/B backup scheme used by newer
> sfc NICs. Prior to this patch they cause sysfs_warn_dup errors because
> they have the same name, causing us not to expose any MTDs at all.
>
> Signed-off-by: Edward Cree <ecree@solarflare.com>
Applied, thanks.
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches
From: Matthew Wilcox @ 2019-01-23 19:18 UTC (permalink / raw)
To: Jani Nikula
Cc: Greg KH, Kees Cook, dev, Ard Biesheuvel, netdev, intel-gfx,
linux-usb, linux-kernel, dri-devel, linux-mm,
linux-security-module, kernel-hardening, intel-wired-lan,
linux-fsdevel, xen-devel, Laura Abbott, linux-kbuild,
Alexander Popov
In-Reply-To: <874l9z31c5.fsf@intel.com>
On Wed, Jan 23, 2019 at 04:17:30PM +0200, Jani Nikula wrote:
> Can't have:
>
> switch (i) {
> int j;
> case 0:
> /* ... */
> }
>
> because it can't be turned into:
>
> switch (i) {
> int j = 0; /* not valid C */
> case 0:
> /* ... */
> }
>
> but can have e.g.:
>
> switch (i) {
> case 0:
> {
> int j = 0;
> /* ... */
> }
> }
>
> I think Kees' approach of moving such variable declarations to the
> enclosing block scope is better than adding another nesting block.
Another nesting level would be bad, but I think this is OK:
switch (i) {
case 0: {
int j = 0;
/* ... */
}
case 1: {
void *p = q;
/* ... */
}
}
I can imagine Kees' patch might have a bad effect on stack consumption,
unless GCC can be relied on to be smart enough to notice the
non-overlapping liveness of the vriables and use the same stack slots
for both.
^ permalink raw reply
* Re: [PATCH net] ax25: fix possible use-after-free
From: David Miller @ 2019-01-23 19:18 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, ralf, syzkaller
In-Reply-To: <20190122184059.220252-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Tue, 22 Jan 2019 10:40:59 -0800
> syzbot found that ax25 routes where not properly protected
> against concurrent use [1].
>
> In this particular report the bug happened while
> copying ax25->digipeat.
>
> Fix this problem by making sure we call ax25_get_route()
> while ax25_route_lock is held, so that no modification
> could happen while using the route.
>
> The current two ax25_get_route() callers do not sleep,
> so this change should be fine.
>
> Once we do that, ax25_get_route() no longer needs to
> grab a reference on the found route.
>
> [1]
...
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Reported-by: syzbot <syzkaller@googlegroups.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