* [PATCH net 2/2] s390: qeth: Fix potential array overrun in cmd/rc lookup
From: Julian Wiedmann @ 2018-09-26 16:07 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-s390, Martin Schwidefsky, Heiko Carstens,
Stefan Raspl, Ursula Braun, Jean Delvare, Julian Wiedmann
In-Reply-To: <20180926160710.64739-1-jwi@linux.ibm.com>
From: Jean Delvare <jdelvare@suse.de>
Functions qeth_get_ipa_msg and qeth_get_ipa_cmd_name are modifying
the last member of global arrays without any locking that I can see.
If two instances of either function are running at the same time,
it could cause a race ultimately leading to an array overrun (the
contents of the last entry of the array is the only guarantee that
the loop will ever stop).
Performing the lookups without modifying the arrays is admittedly
slower (two comparisons per iteration instead of one) but these
are operations which are rare (should only be needed in error
cases or when debugging, not during successful operation) and it
seems still less costly than introducing a mutex to protect the
arrays in question.
As a side bonus, it allows us to declare both arrays as const data.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Julian Wiedmann <jwi@linux.ibm.com>
Cc: Ursula Braun <ubraun@linux.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
---
drivers/s390/net/qeth_core_main.c | 2 +-
drivers/s390/net/qeth_core_mpc.c | 30 ++++++++++++++++--------------
drivers/s390/net/qeth_core_mpc.h | 4 ++--
3 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c
index de8282420f96..ffce6f39828a 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -610,7 +610,7 @@ static void qeth_put_reply(struct qeth_reply *reply)
static void qeth_issue_ipa_msg(struct qeth_ipa_cmd *cmd, int rc,
struct qeth_card *card)
{
- char *ipa_name;
+ const char *ipa_name;
int com = cmd->hdr.command;
ipa_name = qeth_get_ipa_cmd_name(com);
if (rc)
diff --git a/drivers/s390/net/qeth_core_mpc.c b/drivers/s390/net/qeth_core_mpc.c
index e8263ded0af0..e891c0b52f4c 100644
--- a/drivers/s390/net/qeth_core_mpc.c
+++ b/drivers/s390/net/qeth_core_mpc.c
@@ -148,10 +148,10 @@ EXPORT_SYMBOL_GPL(IPA_PDU_HEADER);
struct ipa_rc_msg {
enum qeth_ipa_return_codes rc;
- char *msg;
+ const char *msg;
};
-static struct ipa_rc_msg qeth_ipa_rc_msg[] = {
+static const struct ipa_rc_msg qeth_ipa_rc_msg[] = {
{IPA_RC_SUCCESS, "success"},
{IPA_RC_NOTSUPP, "Command not supported"},
{IPA_RC_IP_TABLE_FULL, "Add Addr IP Table Full - ipv6"},
@@ -219,22 +219,23 @@ static struct ipa_rc_msg qeth_ipa_rc_msg[] = {
-char *qeth_get_ipa_msg(enum qeth_ipa_return_codes rc)
+const char *qeth_get_ipa_msg(enum qeth_ipa_return_codes rc)
{
- int x = 0;
- qeth_ipa_rc_msg[ARRAY_SIZE(qeth_ipa_rc_msg) - 1].rc = rc;
- while (qeth_ipa_rc_msg[x].rc != rc)
- x++;
+ int x;
+
+ for (x = 0; x < ARRAY_SIZE(qeth_ipa_rc_msg) - 1; x++)
+ if (qeth_ipa_rc_msg[x].rc == rc)
+ return qeth_ipa_rc_msg[x].msg;
return qeth_ipa_rc_msg[x].msg;
}
struct ipa_cmd_names {
enum qeth_ipa_cmds cmd;
- char *name;
+ const char *name;
};
-static struct ipa_cmd_names qeth_ipa_cmd_names[] = {
+static const struct ipa_cmd_names qeth_ipa_cmd_names[] = {
{IPA_CMD_STARTLAN, "startlan"},
{IPA_CMD_STOPLAN, "stoplan"},
{IPA_CMD_SETVMAC, "setvmac"},
@@ -266,11 +267,12 @@ static struct ipa_cmd_names qeth_ipa_cmd_names[] = {
{IPA_CMD_UNKNOWN, "unknown"},
};
-char *qeth_get_ipa_cmd_name(enum qeth_ipa_cmds cmd)
+const char *qeth_get_ipa_cmd_name(enum qeth_ipa_cmds cmd)
{
- int x = 0;
- qeth_ipa_cmd_names[ARRAY_SIZE(qeth_ipa_cmd_names) - 1].cmd = cmd;
- while (qeth_ipa_cmd_names[x].cmd != cmd)
- x++;
+ int x;
+
+ for (x = 0; x < ARRAY_SIZE(qeth_ipa_cmd_names) - 1; x++)
+ if (qeth_ipa_cmd_names[x].cmd == cmd)
+ return qeth_ipa_cmd_names[x].name;
return qeth_ipa_cmd_names[x].name;
}
diff --git a/drivers/s390/net/qeth_core_mpc.h b/drivers/s390/net/qeth_core_mpc.h
index aa8b9196b089..aa5de1fe01e1 100644
--- a/drivers/s390/net/qeth_core_mpc.h
+++ b/drivers/s390/net/qeth_core_mpc.h
@@ -797,8 +797,8 @@ enum qeth_ipa_arp_return_codes {
QETH_IPA_ARP_RC_Q_NO_DATA = 0x0008,
};
-extern char *qeth_get_ipa_msg(enum qeth_ipa_return_codes rc);
-extern char *qeth_get_ipa_cmd_name(enum qeth_ipa_cmds cmd);
+extern const char *qeth_get_ipa_msg(enum qeth_ipa_return_codes rc);
+extern const char *qeth_get_ipa_cmd_name(enum qeth_ipa_cmds cmd);
#define QETH_SETASS_BASE_LEN (sizeof(struct qeth_ipacmd_hdr) + \
sizeof(struct qeth_ipacmd_setassparms_hdr))
--
2.16.4
^ permalink raw reply related
* [PATCH net 1/2] s390: qeth_core_mpc: Use ARRAY_SIZE instead of reimplementing its function
From: Julian Wiedmann @ 2018-09-26 16:07 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-s390, Martin Schwidefsky, Heiko Carstens,
Stefan Raspl, Ursula Braun, zhong jiang, Julian Wiedmann
In-Reply-To: <20180926160710.64739-1-jwi@linux.ibm.com>
From: zhong jiang <zhongjiang@huawei.com>
Use the common code ARRAY_SIZE macro instead of a private implementation.
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
---
drivers/s390/net/qeth_core_mpc.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/s390/net/qeth_core_mpc.c b/drivers/s390/net/qeth_core_mpc.c
index 5bcb8dafc3ee..e8263ded0af0 100644
--- a/drivers/s390/net/qeth_core_mpc.c
+++ b/drivers/s390/net/qeth_core_mpc.c
@@ -222,8 +222,7 @@ static struct ipa_rc_msg qeth_ipa_rc_msg[] = {
char *qeth_get_ipa_msg(enum qeth_ipa_return_codes rc)
{
int x = 0;
- qeth_ipa_rc_msg[sizeof(qeth_ipa_rc_msg) /
- sizeof(struct ipa_rc_msg) - 1].rc = rc;
+ qeth_ipa_rc_msg[ARRAY_SIZE(qeth_ipa_rc_msg) - 1].rc = rc;
while (qeth_ipa_rc_msg[x].rc != rc)
x++;
return qeth_ipa_rc_msg[x].msg;
@@ -270,9 +269,7 @@ static struct ipa_cmd_names qeth_ipa_cmd_names[] = {
char *qeth_get_ipa_cmd_name(enum qeth_ipa_cmds cmd)
{
int x = 0;
- qeth_ipa_cmd_names[
- sizeof(qeth_ipa_cmd_names) /
- sizeof(struct ipa_cmd_names)-1].cmd = cmd;
+ qeth_ipa_cmd_names[ARRAY_SIZE(qeth_ipa_cmd_names) - 1].cmd = cmd;
while (qeth_ipa_cmd_names[x].cmd != cmd)
x++;
return qeth_ipa_cmd_names[x].name;
--
2.16.4
^ permalink raw reply related
* [PATCH net 0/2] s390/qeth: fixes 2019-09-26
From: Julian Wiedmann @ 2018-09-26 16:07 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-s390, Martin Schwidefsky, Heiko Carstens,
Stefan Raspl, Ursula Braun, Julian Wiedmann
Hi Dave,
please apply two qeth patches for -net. The first is a trivial cleanup
required for patch #2 by Jean, which fixes a potential endless loop.
Thanks,
Julian
Jean Delvare (1):
s390: qeth: Fix potential array overrun in cmd/rc lookup
zhong jiang (1):
s390: qeth_core_mpc: Use ARRAY_SIZE instead of reimplementing its
function
drivers/s390/net/qeth_core_main.c | 2 +-
drivers/s390/net/qeth_core_mpc.c | 33 ++++++++++++++++-----------------
drivers/s390/net/qeth_core_mpc.h | 4 ++--
3 files changed, 19 insertions(+), 20 deletions(-)
--
2.16.4
^ permalink raw reply
* Re: [PATCH net-next v6 23/23] net: WireGuard secure network tunnel
From: Ivan Labáth @ 2018-09-26 16:00 UTC (permalink / raw)
To: Jason A. Donenfeld, linux-kernel, netdev, linux-crypto, davem,
gregkh
In-Reply-To: <20180925145622.29959-24-Jason@zx2c4.com>
On 25.09.2018 16:56, Jason A. Donenfeld wrote:
> Extensive documentation and description of the protocol and
> considerations, along with formal proofs of the cryptography, are> available at:
>
> * https://www.wireguard.com/
> * https://www.wireguard.com/papers/wireguard.pdf
[]
> +enum { HANDSHAKE_DSCP = 0x88 /* AF41, plus 00 ECN */ };
[]
> + if (skb->protocol == htons(ETH_P_IP)) {
> + len = ntohs(ip_hdr(skb)->tot_len);
> + if (unlikely(len < sizeof(struct iphdr)))
> + goto dishonest_packet_size;
> + if (INET_ECN_is_ce(PACKET_CB(skb)->ds))
> + IP_ECN_set_ce(ip_hdr(skb));
> + } else if (skb->protocol == htons(ETH_P_IPV6)) {
> + len = ntohs(ipv6_hdr(skb)->payload_len) +
> + sizeof(struct ipv6hdr);
> + if (INET_ECN_is_ce(PACKET_CB(skb)->ds))
> + IP6_ECN_set_ce(skb, ipv6_hdr(skb));
> + } else
[]
> + skb_queue_walk (&packets, skb) {
> + /* 0 for no outer TOS: no leak. TODO: should we use flowi->tos
> + * as outer? */
> + PACKET_CB(skb)->ds = ip_tunnel_ecn_encap(0, ip_hdr(skb), skb);
> + PACKET_CB(skb)->nonce =
> + atomic64_inc_return(&key->counter.counter) - 1;
> + if (unlikely(PACKET_CB(skb)->nonce >= REJECT_AFTER_MESSAGES))
> + goto out_invalid;
> + }
Hi,
is there documentation and/or rationale for ecn handling?
Quick search for ecn and dscp didn't reveal any.
Regards,
Ivan
^ permalink raw reply
* Re: [RFC 1/3 net] lorawan: Add LoRaWAN class module
From: Jian-Hong Pan @ 2018-09-26 15:52 UTC (permalink / raw)
To: Andreas Färber
Cc: netdev, <linux-arm-kernel@lists.infradead.org\,
linux-kernel@vger.kernel.org>,, Jiri Pirko, Marcel Holtmann,
David S. Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm,
Jan Jongboom, Jon Ortego, linux-kernel@vger.kernel.org>,,
Ben Whitten, Brian Ray, lora
In-Reply-To: <cebcea44-9db3-5564-574c-038d9af79995@suse.de>
Andreas Färber <afaerber@suse.de> 於 2018年9月24日 週一 上午12:40寫道：
>
> Hi Jian-Hong,
>
> [+ Afonso]
>
> Am 23.08.18 um 19:15 schrieb Jian-Hong Pan:
> > LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa devices.
> >
> > This patch implements part of Class A end-devices features defined in
> > LoRaWAN(TM) Specification Ver. 1.0.2:
> > 1. End-device receive slot timing
> > 2. Only single channel and single data rate for now
> > 3. Unconfirmed data up/down message types
> > 4. Encryption/decryption for up/down link data messages
> >
> > It also implements the the functions and maps to Datagram socket for
> > LoRaWAN unconfirmed data messages.
> >
> > On the other side, it defines the basic interface and operation
> > functions for compatible LoRa device drivers.
> >
> > Signed-off-by: Jian-Hong Pan <starnight@g.ncu.edu.tw>
> > ---
> > include/linux/maclorawan/lora.h | 239 +++++++++++
> > net/maclorawan/Kconfig | 14 +
> > net/maclorawan/Makefile | 2 +
> > net/maclorawan/lorawan.h | 219 ++++++++++
> > net/maclorawan/lrwsec.c | 237 +++++++++++
> > net/maclorawan/lrwsec.h | 57 +++
> > net/maclorawan/mac.c | 552 +++++++++++++++++++++++++
> > net/maclorawan/main.c | 665 ++++++++++++++++++++++++++++++
> > net/maclorawan/socket.c | 700 ++++++++++++++++++++++++++++++++
> > 9 files changed, 2685 insertions(+)
> > create mode 100644 include/linux/maclorawan/lora.h
>
> Can we use include/linux/lora/lorawan.h for simplicity?
Technically, yes
> > create mode 100644 net/maclorawan/Kconfig
> > create mode 100644 net/maclorawan/Makefile
> > create mode 100644 net/maclorawan/lorawan.h
> > create mode 100644 net/maclorawan/lrwsec.c
> > create mode 100644 net/maclorawan/lrwsec.h
> > create mode 100644 net/maclorawan/mac.c
> > create mode 100644 net/maclorawan/main.c
> > create mode 100644 net/maclorawan/socket.c
>
> This patch is much too large for me to review...
>
> It also doesn't seem to follow the structure I suggested: 802.15.4 has
> two separate directories, net/ieee802154/ and net/mac802154/. Therefore
> I had suggested net/maclorawan/ only for code that translates from
> ETH_P_LORAWAN to ETH_P_LORA socket buffers, i.e. your soft MAC. Generic
> socket code that applies also to hard MAC drivers I expected to go
> either to net/lora/lorawan/ or better net/lorawan/ or some other clearly
> separate location, with its own Kconfig symbol - any reason not to?
> Consider which parts can be enabled/used independently of each other,
> then you can put them into two (or more?) different patches.
Maybe I misunderstood before. Besides, the header files need to be
split for different paths or folders.
Anyway, I will try to separate it into parts in version 2 patches.
> Also please use SPDX license identifiers in your headers.
> And please don't put the whole world in To, use CC.
Regards,
Jian-Hong Pan
^ permalink raw reply
* Re: [PATCH RFC,net-next 00/10] add flow_rule infrastructure
From: Jakub Kicinski @ 2018-09-26 15:51 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netdev, davem, thomas.lendacky, f.fainelli, ariel.elior,
michael.chan, santosh, madalin.bucur, yisen.zhuang, salil.mehta,
jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch, ganeshgr,
linux-net-drivers, peppe.cavallaro, alexandre.torgue, joabreu,
grygorii.strashko, andrew, vivien.didelot
In-Reply-To: <20180925192001.2482-1-pablo@netfilter.org>
On Tue, 25 Sep 2018 21:19:51 +0200, Pablo Neira Ayuso wrote:
> This patchset is adding a new layer between drivers and the existing
> software frontends, so it's a bit more code, but it is core
> infrastructure common to everyone and this comes with benefits for
> driver developers:
Thanks a lot for doing this!!
^ permalink raw reply
* Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations
From: Ard Biesheuvel @ 2018-09-26 15:51 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Herbert Xu, Thomas Gleixner, Linux Kernel Mailing List,
<netdev@vger.kernel.org>,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, David S. Miller,
Greg Kroah-Hartman, Samuel Neves, Andy Lutomirski,
Jean-Philippe Aumasson, Russell King, linux-arm-kernel
In-Reply-To: <CAHmME9ru=kJO8QiW+uNNgt5NgFVZzRsQ4tNSgo+f+KfHs3fAKQ@mail.gmail.com>
On Wed, 26 Sep 2018 at 17:50, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> On Wed, Sep 26, 2018 at 5:45 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> > So what you have in mind is something like calling simd_relax() every
> > 4096 bytes or so?
>
> That was actually pretty easy, putting together both of your suggestions:
>
> static inline bool chacha20_arch(struct chacha20_ctx *state, u8 *dst,
> u8 *src, size_t len,
> simd_context_t *simd_context)
> {
> while (len > PAGE_SIZE) {
> chacha20_arch(state, dst, src, PAGE_SIZE, simd_context);
> len -= PAGE_SIZE;
> src += PAGE_SIZE;
> dst += PAGE_SIZE;
> simd_relax(simd_context);
> }
> if (IS_ENABLED(CONFIG_KERNEL_MODE_NEON) && chacha20_use_neon &&
> len >= CHACHA20_BLOCK_SIZE * 3 && simd_use(simd_context))
> chacha20_neon(dst, src, len, state->key, state->counter);
> else
> chacha20_arm(dst, src, len, state->key, state->counter);
>
> state->counter[0] += (len + 63) / 64;
> return true;
> }
Nice one :-)
This works for me (but perhaps add a comment as well)
^ permalink raw reply
* Re: [PATCH RFC,net-next 04/10] cls_flower: add translator to flow_action representation
From: Jakub Kicinski @ 2018-09-26 15:47 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netdev, davem, thomas.lendacky, f.fainelli, ariel.elior,
michael.chan, santosh, madalin.bucur, yisen.zhuang, salil.mehta,
jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch, ganeshgr,
linux-net-drivers, peppe.cavallaro, alexandre.torgue, joabreu,
grygorii.strashko, andrew, vivien.didelot
In-Reply-To: <20180925192001.2482-5-pablo@netfilter.org>
On Tue, 25 Sep 2018 21:19:55 +0200, Pablo Neira Ayuso wrote:
> This implements TC action to flow_action translation from cls_flower.
>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> ---
> net/sched/cls_flower.c | 124 ++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 123 insertions(+), 1 deletion(-)
>
> diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
> index e1dd60a2ecb8..a96a80f01c6d 100644
> --- a/net/sched/cls_flower.c
> +++ b/net/sched/cls_flower.c
> @@ -28,6 +28,14 @@
>
> #include <net/dst.h>
> #include <net/dst_metadata.h>
> +#include <net/tc_act/tc_mirred.h>
> +#include <net/tc_act/tc_vlan.h>
> +#include <net/tc_act/tc_tunnel_key.h>
> +#include <net/tc_act/tc_pedit.h>
> +#include <net/tc_act/tc_csum.h>
> +#include <net/tc_act/tc_gact.h>
> +#include <net/tc_act/tc_skbedit.h>
> +#include <net/tc_act/tc_mirred.h>
>
> struct fl_flow_key {
> int indev_ifindex;
> @@ -101,6 +109,7 @@ struct cls_fl_filter {
> u32 in_hw_count;
> struct rcu_work rwork;
> struct net_device *hw_dev;
> + struct flow_action action;
> };
>
> static const struct rhashtable_params mask_ht_params = {
> @@ -294,6 +303,107 @@ static void fl_hw_destroy_filter(struct tcf_proto *tp, struct cls_fl_filter *f,
> tcf_block_offload_dec(block, &f->flags);
> }
>
> +static int fl_hw_setup_action(struct flow_action *flow_action,
> + const struct tcf_exts *exts)
The function doesn't seem very flower-specific?
> +{
> + const struct tc_action *act;
> + int num_acts = 0, i, j, k;
> +
> + if (!exts)
> + return 0;
> +
> + tcf_exts_for_each_action(i, act, exts) {
> + if (is_tcf_pedit(act))
> + num_acts += tcf_pedit_nkeys(act);
> + else
> + num_acts++;
> + }
> +
> + if (!num_acts)
> + return 0;
> +
> + if (flow_action_init(flow_action, num_acts) < 0)
> + return -ENOMEM;
> +
> + j = 0;
> + tcf_exts_for_each_action(i, act, exts) {
> + struct flow_action_key *key;
> +
> + key = &flow_action->keys[j];
> + if (is_tcf_gact_ok(act)) {
> + key->id = FLOW_ACTION_KEY_ACCEPT;
> + } else if (is_tcf_gact_shot(act)) {
> + key->id = FLOW_ACTION_KEY_DROP;
> + } else if (is_tcf_gact_trap(act)) {
> + key->id = FLOW_ACTION_KEY_TRAP;
> + } else if (is_tcf_gact_goto_chain(act)) {
> + key->id = FLOW_ACTION_KEY_GOTO;
> + key->chain_index = tcf_gact_goto_chain_index(act);
> + } else if (is_tcf_mirred_egress_redirect(act)) {
> + key->id = FLOW_ACTION_KEY_REDIRECT;
> + key->dev = tcf_mirred_dev(act);
> + } else if (is_tcf_mirred_egress_mirror(act)) {
> + key->id = FLOW_ACTION_KEY_MIRRED;
> + key->dev = tcf_mirred_dev(act);
> + } else if (is_tcf_vlan(act)) {
> + switch (tcf_vlan_action(act)) {
> + case TCA_VLAN_ACT_PUSH:
> + key->id = FLOW_ACTION_KEY_VLAN_PUSH;
> + key->vlan.vid = tcf_vlan_push_vid(act);
> + key->vlan.proto = tcf_vlan_push_proto(act);
> + key->vlan.prio = tcf_vlan_push_prio(act);
> + break;
> + case TCA_VLAN_ACT_POP:
> + key->id = FLOW_ACTION_KEY_VLAN_POP;
> + break;
> + case TCA_VLAN_ACT_MODIFY:
> + key->id = FLOW_ACTION_KEY_VLAN_MANGLE;
> + key->vlan.vid = tcf_vlan_push_vid(act);
> + key->vlan.proto = tcf_vlan_push_proto(act);
> + key->vlan.prio = tcf_vlan_push_prio(act);
> + break;
> + }
> + } else if (is_tcf_tunnel_set(act)) {
> + key->id = FLOW_ACTION_KEY_TUNNEL_ENCAP;
> + key->tunnel = tcf_tunnel_info(act);
> + } else if (is_tcf_tunnel_release(act)) {
> + key->id = FLOW_ACTION_KEY_TUNNEL_DECAP;
> + key->tunnel = tcf_tunnel_info(act);
> + } else if (is_tcf_pedit(act)) {
> + for (k = 0; k < tcf_pedit_nkeys(act); k++) {
> + switch (tcf_pedit_cmd(act, k)) {
> + case TCA_PEDIT_KEY_EX_CMD_SET:
> + key->id = FLOW_ACTION_KEY_MANGLE;
> + break;
> + case TCA_PEDIT_KEY_EX_CMD_ADD:
> + key->id = FLOW_ACTION_KEY_ADD;
> + break;
> + default:
> + WARN_ON_ONCE(1);
> + break;
> + }
> +
> + key->mangle.htype = tcf_pedit_htype(act, k);
> + key->mangle.mask = tcf_pedit_mask(act, k);
> + key->mangle.val = tcf_pedit_val(act, k);
> + key->mangle.offset = tcf_pedit_offset(act, k);
> + key = &flow_action->keys[++j];
> + }
> + } else if (is_tcf_csum(act)) {
> + key->id = FLOW_ACTION_KEY_CSUM;
> + key->csum_flags = tcf_csum_update_flags(act);
> + } else if (is_tcf_skbedit_mark(act)) {
> + key->id = FLOW_ACTION_KEY_MARK;
> + key->mark = tcf_skbedit_mark(act);
> + }
Why the permissiveness? Shouldn't we error out if we there is an
unknown action?
else -EOPNOTSUPP + extack?
> +
> + if (!is_tcf_pedit(act))
> + j++;
> + }
> +
> + return 0;
> +}
> +
> static int fl_hw_replace_filter(struct tcf_proto *tp,
> struct cls_fl_filter *f,
> struct netlink_ext_ack *extack)
^ permalink raw reply
* KASAN: use-after-free Read in tcf_block_find
From: syzbot @ 2018-09-26 15:44 UTC (permalink / raw)
To: davem, jhs, jiri, linux-kernel, netdev, syzkaller-bugs,
xiyou.wangcong
Hello,
syzbot found the following crash on:
HEAD commit: 4b1bd6976945 net: phy: marvell: Fix build.
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16f763fa400000
kernel config: https://syzkaller.appspot.com/x/.config?x=443816db871edd66
dashboard link: https://syzkaller.appspot.com/bug?extid=37b8770e6d5a8220a039
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17a5614e400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=141a532a400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+37b8770e6d5a8220a039@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
8021q: adding VLAN 0 to HW filter on device team0
==================================================================
BUG: KASAN: use-after-free in tcf_block_find+0x9d1/0xb90
net/sched/cls_api.c:646
Read of size 4 at addr ffff8801cc126978 by task syz-executor002/5646
CPU: 1 PID: 5646 Comm: syz-executor002 Not tainted 4.19.0-rc5+ #232
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+0x1c4/0x2b4 lib/dump_stack.c:113
print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
__asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
tcf_block_find+0x9d1/0xb90 net/sched/cls_api.c:646
tc_new_tfilter+0x497/0x1d20 net/sched/cls_api.c:1331
rtnetlink_rcv_msg+0x46a/0xc20 net/core/rtnetlink.c:4730
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2447
rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4748
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x5a5/0x760 net/netlink/af_netlink.c:1336
netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1901
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:631
___sys_sendmsg+0x7fd/0x930 net/socket.c:2116
__sys_sendmsg+0x11d/0x280 net/socket.c:2154
__do_sys_sendmsg net/socket.c:2163 [inline]
__se_sys_sendmsg net/socket.c:2161 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x441979
Code: e8 0c ac 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 fb 04 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffd8b1e9178 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000441979
RDX: 0000000000000000 RSI: 0000000020000100 RDI: 0000000000000003
RBP: 0000000000009641 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000001bb6880 R11: 0000000000000213 R12: 0000000000000000
R13: 0000000000402390 R14: 0000000000000000 R15: 0000000000000000
Allocated by task 5522:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
__do_kmalloc_node mm/slab.c:3682 [inline]
__kmalloc_node+0x47/0x70 mm/slab.c:3689
kmalloc_node include/linux/slab.h:555 [inline]
kzalloc_node include/linux/slab.h:718 [inline]
qdisc_alloc+0x10f/0xb50 net/sched/sch_generic.c:820
qdisc_create_dflt+0x7a/0x1e0 net/sched/sch_generic.c:894
attach_one_default_qdisc net/sched/sch_generic.c:1041 [inline]
netdev_for_each_tx_queue include/linux/netdevice.h:2114 [inline]
attach_default_qdiscs net/sched/sch_generic.c:1060 [inline]
dev_activate+0x82f/0xcb0 net/sched/sch_generic.c:1103
__dev_open+0x2cb/0x410 net/core/dev.c:1400
__dev_change_flags+0x730/0x9b0 net/core/dev.c:7448
dev_change_flags+0x89/0x150 net/core/dev.c:7517
do_setlink+0xb5f/0x3f20 net/core/rtnetlink.c:2441
rtnl_newlink+0x136f/0x1d40 net/core/rtnetlink.c:3054
rtnetlink_rcv_msg+0x46a/0xc20 net/core/rtnetlink.c:4730
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2447
rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4748
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x5a5/0x760 net/netlink/af_netlink.c:1336
netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1901
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:631
___sys_sendmsg+0x7fd/0x930 net/socket.c:2116
__sys_sendmsg+0x11d/0x280 net/socket.c:2154
__do_sys_sendmsg net/socket.c:2163 [inline]
__se_sys_sendmsg net/socket.c:2161 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 0:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xcf/0x230 mm/slab.c:3813
qdisc_free+0x89/0x100 net/sched/sch_generic.c:941
qdisc_free_cb+0x19/0x20 net/sched/sch_generic.c:948
__rcu_reclaim kernel/rcu/rcu.h:236 [inline]
rcu_do_batch kernel/rcu/tree.c:2576 [inline]
invoke_rcu_callbacks kernel/rcu/tree.c:2880 [inline]
__rcu_process_callbacks kernel/rcu/tree.c:2847 [inline]
rcu_process_callbacks+0xf23/0x2670 kernel/rcu/tree.c:2864
__do_softirq+0x30b/0xad8 kernel/softirq.c:292
The buggy address belongs to the object at ffff8801cc126940
which belongs to the cache kmalloc-1024 of size 1024
The buggy address is located 56 bytes inside of
1024-byte region [ffff8801cc126940, ffff8801cc126d40)
The buggy address belongs to the page:
page:ffffea0007304980 count:1 mapcount:0 mapping:ffff8801da800ac0 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffffea0007304808 ffffea0007302788 ffff8801da800ac0
raw: 0000000000000000 ffff8801cc126040 0000000100000007 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801cc126800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801cc126880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801cc126900: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
ffff8801cc126980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801cc126a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: KASAN: use-after-free Read in tcf_block_find
From: Cong Wang @ 2018-09-26 21:55 UTC (permalink / raw)
To: Eric Dumazet
Cc: syzbot+37b8770e6d5a8220a039, David Miller, Jamal Hadi Salim,
Jiri Pirko, LKML, Linux Kernel Network Developers, syzkaller-bugs
In-Reply-To: <7fcb1c03-6976-9b34-601d-5f50b74c5b0a@gmail.com>
On Wed, Sep 26, 2018 at 2:50 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 09/26/2018 02:44 PM, Cong Wang wrote:
> > On Wed, Sep 26, 2018 at 8:44 AM syzbot
> > <syzbot+37b8770e6d5a8220a039@syzkaller.appspotmail.com> wrote:
> >>
> >> Hello,
> >>
> >> syzbot found the following crash on:
> >>
> >> HEAD commit: 4b1bd6976945 net: phy: marvell: Fix build.
> >> git tree: net-next
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=16f763fa400000
> >> kernel config: https://syzkaller.appspot.com/x/.config?x=443816db871edd66
> >> dashboard link: https://syzkaller.appspot.com/bug?extid=37b8770e6d5a8220a039
> >> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17a5614e400000
> >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=141a532a400000
> >>
> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> Reported-by: syzbot+37b8770e6d5a8220a039@syzkaller.appspotmail.com
> >>
> >> IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
> >> 8021q: adding VLAN 0 to HW filter on device team0
> >> ==================================================================
> >> BUG: KASAN: use-after-free in tcf_block_find+0x9d1/0xb90
> >> net/sched/cls_api.c:646
> >> Read of size 4 at addr ffff8801cc126978 by task syz-executor002/5646
> >>
> >> CPU: 1 PID: 5646 Comm: syz-executor002 Not tainted 4.19.0-rc5+ #232
> >> 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+0x1c4/0x2b4 lib/dump_stack.c:113
> >> print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
> >> kasan_report_error mm/kasan/report.c:354 [inline]
> >> kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
> >> __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
> >> tcf_block_find+0x9d1/0xb90 net/sched/cls_api.c:646
> >
> > Hmm. looks like missing a rcu_dereference() here:
> >
> > if (!*parent) {
> > *q = dev->qdisc;
> > *parent = (*q)->handle;
> >
>
> We hold RTNL here.
>
> Have we already done the changes allowing dev->qdisc being changed
> without RTNL being required ?
That transition is not completed yet, but holding RTNL doesn't help
any more after we now free qdisc in rcu callback.
More interestingly, rcu read lock is already held in this context,
so it seems we still have to use rcu_deference() to read dev->qdisc
and of course mark it with __rcu too.
^ permalink raw reply
* Re: KASAN: use-after-free Read in tcf_block_find
From: Eric Dumazet @ 2018-09-26 21:50 UTC (permalink / raw)
To: Cong Wang, syzbot+37b8770e6d5a8220a039
Cc: David Miller, Jamal Hadi Salim, Jiri Pirko, LKML,
Linux Kernel Network Developers, syzkaller-bugs
In-Reply-To: <CAM_iQpXxzR3GP4wK7z+wW_0-vC9cuyiwnrCYqx+NpBgDvBXLcg@mail.gmail.com>
On 09/26/2018 02:44 PM, Cong Wang wrote:
> On Wed, Sep 26, 2018 at 8:44 AM syzbot
> <syzbot+37b8770e6d5a8220a039@syzkaller.appspotmail.com> wrote:
>>
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: 4b1bd6976945 net: phy: marvell: Fix build.
>> git tree: net-next
>> console output: https://syzkaller.appspot.com/x/log.txt?x=16f763fa400000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=443816db871edd66
>> dashboard link: https://syzkaller.appspot.com/bug?extid=37b8770e6d5a8220a039
>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17a5614e400000
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=141a532a400000
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+37b8770e6d5a8220a039@syzkaller.appspotmail.com
>>
>> IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
>> 8021q: adding VLAN 0 to HW filter on device team0
>> ==================================================================
>> BUG: KASAN: use-after-free in tcf_block_find+0x9d1/0xb90
>> net/sched/cls_api.c:646
>> Read of size 4 at addr ffff8801cc126978 by task syz-executor002/5646
>>
>> CPU: 1 PID: 5646 Comm: syz-executor002 Not tainted 4.19.0-rc5+ #232
>> 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+0x1c4/0x2b4 lib/dump_stack.c:113
>> print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
>> kasan_report_error mm/kasan/report.c:354 [inline]
>> kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
>> __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
>> tcf_block_find+0x9d1/0xb90 net/sched/cls_api.c:646
>
> Hmm. looks like missing a rcu_dereference() here:
>
> if (!*parent) {
> *q = dev->qdisc;
> *parent = (*q)->handle;
>
We hold RTNL here.
Have we already done the changes allowing dev->qdisc being changed
without RTNL being required ?
^ permalink raw reply
* Re: Marvell phy errata origins?
From: Daniel Walker @ 2018-09-26 15:35 UTC (permalink / raw)
To: Harini Katakam, Andrew Lunn
Cc: Florian Fainelli, afleming, Harini Katakam, netdev, hramdasi,
jpitti, gcasheek
In-Reply-To: <CAFcVECKWf8JS7W2s2zRBU0txeaERF-zUHTcMcF9xqXtphObM5g@mail.gmail.com>
On 09/25/2018 10:42 PM, Harini Katakam wrote:
> Hi,
> On Tue, Sep 25, 2018 at 11:00 PM Harini Katakam <harinik@xilinx.com> wrote:
>>
>> Hi Daniel,
>>
>> On Tue, Sep 25, 2018 at 9:10 PM Andrew Lunn <andrew@lunn.ch> wrote:
>>>
>>>> I hope this this thread isn't too old to bring back to life. So it seems
>>>> that Harini found that m88e1111 did not need this errata, and Cisco
>>>> previously found that Harini's patch fixed m88e1112, we included it
>>>> internally for that reason
>>>>
>>>> Now I'm getting reports that this errata fixes issues we're seeing on
>>>> m88e1111. We see an interrupt storm without the errata, despite the errata
>>>> not being defined in the datasheet.
>>>
>>> Is everybody actually using interrupts? It could be in one system
>>> phylib is polling.
>>>
>>
>> Yes, we weren't using interrupts; we used phy poll.
>>
>> As I recall, the register and page combination was reserved and
>> the access seemed to fail.
>> It will be useful if we can the errata description or version details.
>> I'll check if I can get any more information.
>
> One of the PHY parts used was "88E1111-B2-bab1i000"
I doubt I can find this level of detail .. We have many of these
machines in the field so they may have different part numbers.
I may have been given some incorrect details on the issue. I'm not
currently sure this errata code is related. I'll let you know when I
have more information.
Daniel
^ permalink raw reply
* Re: KASAN: use-after-free Read in tcf_block_find
From: Cong Wang @ 2018-09-26 21:44 UTC (permalink / raw)
To: syzbot+37b8770e6d5a8220a039
Cc: David Miller, Jamal Hadi Salim, Jiri Pirko, LKML,
Linux Kernel Network Developers, syzkaller-bugs
In-Reply-To: <00000000000084e2450576c817cc@google.com>
On Wed, Sep 26, 2018 at 8:44 AM syzbot
<syzbot+37b8770e6d5a8220a039@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 4b1bd6976945 net: phy: marvell: Fix build.
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=16f763fa400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=443816db871edd66
> dashboard link: https://syzkaller.appspot.com/bug?extid=37b8770e6d5a8220a039
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17a5614e400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=141a532a400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+37b8770e6d5a8220a039@syzkaller.appspotmail.com
>
> IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
> 8021q: adding VLAN 0 to HW filter on device team0
> ==================================================================
> BUG: KASAN: use-after-free in tcf_block_find+0x9d1/0xb90
> net/sched/cls_api.c:646
> Read of size 4 at addr ffff8801cc126978 by task syz-executor002/5646
>
> CPU: 1 PID: 5646 Comm: syz-executor002 Not tainted 4.19.0-rc5+ #232
> 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+0x1c4/0x2b4 lib/dump_stack.c:113
> print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
> __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
> tcf_block_find+0x9d1/0xb90 net/sched/cls_api.c:646
Hmm. looks like missing a rcu_dereference() here:
if (!*parent) {
*q = dev->qdisc;
*parent = (*q)->handle;
^ permalink raw reply
* Re: [PATCH net-next v3 09/11] dt-bindings: add constants for Microsemi Ocelot SerDes driver
From: Rob Herring @ 2018-09-26 21:36 UTC (permalink / raw)
To: Quentin Schulz
Cc: alexandre.belloni, ralf, paul.burton, jhogan, robh+dt,
mark.rutland, davem, kishon, andrew, f.fainelli, allan.nielsen,
linux-mips, devicetree, linux-kernel, netdev, thomas.petazzoni,
Quentin Schulz
In-Reply-To: <73113ea4b3d8d34c05d88413b3d15cc1733cf25e.1536912834.git-series.quentin.schulz@bootlin.com>
On Fri, 14 Sep 2018 10:16:07 +0200, Quentin Schulz wrote:
> The Microsemi Ocelot has multiple SerDes and requires that the SerDes be
> muxed accordingly to the hardware representation.
>
> Let's add a constant for each SerDes available in the Microsemi Ocelot.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
> ---
> include/dt-bindings/phy/phy-ocelot-serdes.h | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
> create mode 100644 include/dt-bindings/phy/phy-ocelot-serdes.h
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next v3 07/11] dt-bindings: phy: add DT binding for Microsemi Ocelot SerDes muxing
From: Rob Herring @ 2018-09-26 21:35 UTC (permalink / raw)
To: Quentin Schulz
Cc: alexandre.belloni, ralf, paul.burton, jhogan, mark.rutland, davem,
kishon, andrew, f.fainelli, allan.nielsen, linux-mips, devicetree,
linux-kernel, netdev, thomas.petazzoni
In-Reply-To: <f392dafca9165800439fc09cd7d16e6a9506d457.1536912834.git-series.quentin.schulz@bootlin.com>
On Fri, Sep 14, 2018 at 10:16:05AM +0200, Quentin Schulz wrote:
> Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
> ---
> Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt | 40 +++++++-
> 1 file changed, 40 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt b/Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt
> new file mode 100644
> index 0000000..2a88cc3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt
> @@ -0,0 +1,40 @@
> +Microsemi Ocelot SerDes muxing driver
> +-------------------------------------
> +
> +On Microsemi Ocelot, there is a handful of registers in HSIO address
> +space for setting up the SerDes to switch port muxing.
> +
> +A SerDes X can be "muxed" to work with switch port Y or Z for example.
> +One specific SerDes can also be used as a PCIe interface.
> +
> +Hence, a SerDes represents an interface, be it an Ethernet or a PCIe one.
> +
> +There are two kinds of SerDes: SERDES1G supports 10/100Mbps in
> +half/full-duplex and 1000Mbps in full-duplex mode while SERDES6G supports
> +10/100Mbps in half/full-duplex and 1000/2500Mbps in full-duplex mode.
> +
> +Also, SERDES6G number (aka "macro") 0 is the only interface supporting
> +QSGMII.
> +
> +Required properties:
> +
> +- compatible: should be "mscc,vsc7514-serdes"
> +- #phy-cells : from the generic phy bindings, must be 2.
> + The first number defines the input port to use for a given
> + SerDes macro. The second defines the macro to use. They are
> + defined in dt-bindings/phy/phy-ocelot-serdes.h
You need to define what this is a child of.
> +
> +Example:
> +
> + serdes: serdes {
> + compatible = "mscc,vsc7514-serdes";
> + #phy-cells = <2>;
However, if there are no other resources associated with this, then you
don't even need this child node. The parent can be a phy provider and
provider of other functions too.
> + };
> +
> + ethernet {
> + port1 {
> + phy-handle = <&phy_foo>;
> + /* Link SERDES1G_5 to port1 */
> + phys = <&serdes 1 SERDES1G_5>;
> + };
> + };
> --
> git-series 0.9.1
^ permalink raw reply
* Re: netlink: 16 bytes leftover after parsing attributes in process `ip'.
From: Stephen Hemminger @ 2018-09-26 15:02 UTC (permalink / raw)
To: David Ahern
Cc: Jiri Benc, Christian Brauner, netdev@vger.kernel.org,
David Miller
In-Reply-To: <7ffc4951-0d2e-5bf1-8d64-62ae5d6bc477@gmail.com>
On Wed, 26 Sep 2018 08:54:43 -0600
David Ahern <dsahern@gmail.com> wrote:
> On 9/25/18 11:51 PM, Jiri Benc wrote:
> > On Tue, 25 Sep 2018 09:37:41 -0600, David Ahern wrote:
> >> For ifaddrmsg ifa_flags aligns with ifi_type which is set by kernel side
> >> so this should be ok.
> >
> > Does the existing user space set ifi_type to anything? Does it zero out
> > the field?
> >
> > Are we able to find a flag value that is not going to be set by unaware
> > user space? I.e., a bit that is unused by the current ARPHRD values on
> > both little and big endian? (ARPHRD_NONE might be a problem, though...)
>
> The goal is for userpsace to pass something to the kernel to
> definitively state which header is used.
>
You can not safely assume anything about older code.
iproute2 is not the only thing using the API, others include Quagga, and other tools.
Sorry, this API is frozen.
^ permalink raw reply
* Re: [PATCH net-next 2/9] net: bridge: add bitfield for options and convert vlan opts
From: Andrew Lunn @ 2018-09-26 15:01 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: netdev, roopa, davem, stephen, bridge
In-Reply-To: <e5b4f87d-c665-9476-c9d3-a7254394c13f@cumulusnetworks.com>
On Wed, Sep 26, 2018 at 05:55:47PM +0300, Nikolay Aleksandrov wrote:
> On 26/09/18 17:48, Andrew Lunn wrote:
> > Hi Nikolay
> >
> >> struct net_bridge {
> >> spinlock_t lock;
> >> spinlock_t hash_lock;
> >> struct list_head port_list;
> >> struct net_device *dev;
> >> struct pcpu_sw_netstats __percpu *stats;
> >> + unsigned long options;
> >
> > Maybe a u32 would be better, so we run out of bits at the same time on
> > 32 and 64 bit systems?
> >
> > Andrew
> >
>
> Bitops operate on an unsigned long, I actually had a BUILD_BUG_ON() for
> 32 bits initially, but checked other places and they seem to be using it
> as-is without any checks so I decided to leave it as well (e.g.
> sock_flags).
O.K.
I assume we get compiler warnings anyway, when we use bit 32 on a
32bit system. The build-bots should let us know.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 2/9] net: bridge: add bitfield for options and convert vlan opts
From: Nikolay Aleksandrov @ 2018-09-26 14:55 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, roopa, davem, stephen, bridge
In-Reply-To: <20180926144808.GM1676@lunn.ch>
On 26/09/18 17:48, Andrew Lunn wrote:
> Hi Nikolay
>
>> struct net_bridge {
>> spinlock_t lock;
>> spinlock_t hash_lock;
>> struct list_head port_list;
>> struct net_device *dev;
>> struct pcpu_sw_netstats __percpu *stats;
>> + unsigned long options;
>
> Maybe a u32 would be better, so we run out of bits at the same time on
> 32 and 64 bit systems?
>
> Andrew
>
Bitops operate on an unsigned long, I actually had a BUILD_BUG_ON() for
32 bits initially, but checked other places and they seem to be using it
as-is without any checks so I decided to leave it as well (e.g.
sock_flags).
^ permalink raw reply
* Re: netlink: 16 bytes leftover after parsing attributes in process `ip'.
From: David Ahern @ 2018-09-26 14:54 UTC (permalink / raw)
To: Jiri Benc; +Cc: Christian Brauner, netdev@vger.kernel.org, David Miller
In-Reply-To: <20180926075115.4ca7c527@redhat.com>
On 9/25/18 11:51 PM, Jiri Benc wrote:
> On Tue, 25 Sep 2018 09:37:41 -0600, David Ahern wrote:
>> For ifaddrmsg ifa_flags aligns with ifi_type which is set by kernel side
>> so this should be ok.
>
> Does the existing user space set ifi_type to anything? Does it zero out
> the field?
>
> Are we able to find a flag value that is not going to be set by unaware
> user space? I.e., a bit that is unused by the current ARPHRD values on
> both little and big endian? (ARPHRD_NONE might be a problem, though...)
The goal is for userpsace to pass something to the kernel to
definitively state which header is used.
ifaddrmsg (proper header and one Christian's patch wants to use) is 8
bytes; ifinfomsg (legacy header from broken userspace) is 16. If you can
not trust that ifi_type is currently 0 on a dump request then you can
not trust ifi_flags to be correct or ifi_change to be correct and so you
can not move past the header and parse attributes. If that is the case
we are done - Christian's patches should be reverted as you can never
trust what is beyond the family entry.
But I do not believe that to be the case because of the route dump
analogy. As I mentioned route dumps have the same problem: sometimes
ifinfomsg is passed and sometimes rtmsg. Yet the kernel always looks at
rtm_flags.
In terms of which field to use the most logical to me is to pass in a
flag. Current address dumps have no reason to pass in a flag so it is
not like the field can be misinterpreted. ifa_flags is a single byte so
are there really endian issues to worry about?
^ permalink raw reply
* Re: [PATCH net-next 2/9] net: bridge: add bitfield for options and convert vlan opts
From: Andrew Lunn @ 2018-09-26 14:48 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: netdev, roopa, davem, stephen, bridge
In-Reply-To: <20180926121802.27851-3-nikolay@cumulusnetworks.com>
Hi Nikolay
> struct net_bridge {
> spinlock_t lock;
> spinlock_t hash_lock;
> struct list_head port_list;
> struct net_device *dev;
> struct pcpu_sw_netstats __percpu *stats;
> + unsigned long options;
Maybe a u32 would be better, so we run out of bits at the same time on
32 and 64 bit systems?
Andrew
^ permalink raw reply
* Re: [PATCH 3/5] ixgbe: add AF_XDP zero-copy Rx support
From: Björn Töpel @ 2018-09-26 14:29 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Jeff Kirsher, intel-wired-lan, Björn Töpel,
Karlsson, Magnus, Magnus Karlsson, ast, Daniel Borkmann, Netdev,
Jesper Dangaard Brouer, William Tu, tuc
In-Reply-To: <20180925075714.75db73ac@cakuba.netronome.com>
Den tis 25 sep. 2018 kl 16:57 skrev Jakub Kicinski
<jakub.kicinski@netronome.com>:
>
> On Mon, 24 Sep 2018 18:35:55 +0200, Björn Töpel wrote:
> > + if (adapter->flags & IXGBE_FLAG_SRIOV_ENABLED)
> > + return -EINVAL;
> > +
> > + if (adapter->flags & IXGBE_FLAG_DCB_ENABLED)
> > + return -EINVAL;
>
> Hm, should you add UMEM checks to all the places these may get
> enabled? Like fabf1bce103a ("ixgbe: Prevent unsupported configurations
> with XDP") did?
Actually, I can remove these checks, since it's already checked by the
XDP path. AF_XDP ZC is enabled only when XDP is enabled. So there's no
need to have the XDP checks in the AF_XDP path.
Björn
^ permalink raw reply
* KMSAN: uninit-value in __dev_mc_add
From: syzbot @ 2018-09-26 14:24 UTC (permalink / raw)
To: davem, edumazet, linux-kernel, netdev, sunlw.fnst, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: eb2e67596de2 kmsan: minor code cleanup
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=136e3b11400000
kernel config: https://syzkaller.appspot.com/x/.config?x=94a9ed72288f7fef
dashboard link: https://syzkaller.appspot.com/bug?extid=001516d86dbe88862cec
compiler: clang version 8.0.0 (trunk 339414)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+001516d86dbe88862cec@syzkaller.appspotmail.com
==================================================================
BUG: KMSAN: uninit-value in memcmp+0x11d/0x180 lib/string.c:863
CPU: 0 PID: 14033 Comm: kworker/0:3 Not tainted 4.19.0-rc4+ #58
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: ipv6_addrconf addrconf_dad_work
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x2f6/0x430 lib/dump_stack.c:113
kmsan_report+0x183/0x2b0 mm/kmsan/kmsan.c:917
__msan_warning+0x70/0xc0 mm/kmsan/kmsan_instr.c:500
memcmp+0x11d/0x180 lib/string.c:863
__hw_addr_add_ex net/core/dev_addr_lists.c:61 [inline]
__dev_mc_add+0x215/0x8c0 net/core/dev_addr_lists.c:670
dev_mc_add+0x6d/0x80 net/core/dev_addr_lists.c:687
igmp6_group_added+0x2c8/0xaa0 net/ipv6/mcast.c:676
__ipv6_dev_mc_inc+0xf4b/0x1270 net/ipv6/mcast.c:934
ipv6_dev_mc_inc+0x70/0x80 net/ipv6/mcast.c:941
addrconf_join_solict net/ipv6/addrconf.c:2098 [inline]
addrconf_dad_begin net/ipv6/addrconf.c:3879 [inline]
addrconf_dad_work+0x437/0x29b0 net/ipv6/addrconf.c:4006
process_one_work+0x197f/0x2490 kernel/workqueue.c:2153
worker_thread+0x1f6a/0x2b00 kernel/workqueue.c:2296
kthread+0x59c/0x5d0 kernel/kthread.c:247
ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:416
Local variable description: ----buf@igmp6_group_added
Variable was created at:
igmp6_group_added+0x46/0xaa0 net/ipv6/mcast.c:664
__ipv6_dev_mc_inc+0xf4b/0x1270 net/ipv6/mcast.c:934
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: [PATCH net-next] net: ti: fix return type of ndo_start_xmit function
From: Grygorii Strashko @ 2018-09-26 20:36 UTC (permalink / raw)
To: David Miller, yuehaibing
Cc: f.fainelli, w-kwok2, m-karicheri2, lukas, bgolaszewski,
ivan.khoronzhuk, dan.carpenter, linux-kernel, netdev, linux-omap
In-Reply-To: <20180926.101733.2070254569725987062.davem@davemloft.net>
Hi All,
On 09/26/2018 12:17 PM, David Miller wrote:
> From: YueHaibing <yuehaibing@huawei.com>
> Date: Wed, 26 Sep 2018 17:09:51 +0800
>
>> @@ -1290,7 +1291,7 @@ static int netcp_ndo_start_xmit(struct sk_buff *skb, struct net_device *ndev)
>> dev_warn(netcp->ndev_dev, "padding failed (%d), packet dropped\n",
>> ret);
>> tx_stats->tx_dropped++;
>> - return ret;
>> + return NETDEV_TX_BUSY;
>> }
>> skb->len = NETCP_MIN_PACKET_SIZE;
>> }
>> @@ -1298,7 +1299,6 @@ static int netcp_ndo_start_xmit(struct sk_buff *skb, struct net_device *ndev)
>> desc = netcp_tx_map_skb(skb, netcp);
>> if (unlikely(!desc)) {
>> netif_stop_subqueue(ndev, subqueue);
>> - ret = -ENOBUFS;
>> goto drop;
>> }
>>
>> @@ -1319,7 +1319,7 @@ static int netcp_ndo_start_xmit(struct sk_buff *skb, struct net_device *ndev)
>> if (desc)
>> netcp_free_tx_desc_chain(netcp, desc, sizeof(*desc));
>> dev_kfree_skb(skb);
>> - return ret;
>> + return NETDEV_TX_BUSY;
>> }
>
> These conversions are not correct.
>
> If the driver frees the SKB you must not return NETDEV_TX_BUSY.
>
> NETDEV_TX_BUSY tells the caller that the driver could not process the
> packet and that it should reqeueu up the SKB and try again later when
> there is more TX queue room.
>
Sry, but I still do not understand the reason for these changes (as I asked already [1])
May be there are some patches on the fly or long term decisions were made in this area.
According to the code include/linux/netdevice.h the .ndo_start_xmit() can return 3 type of values
1) enum netdev_tx, expected to be used by regular netdev drivers, but
2) "error while transmitting (rc < 0)" is also acceptable values
3) NET_XMIT_SUCCESS/DROP/CN (qdisc ->enqueue() return codes) for Virtual network devices
So, are there plans to move NET_XMIT_XXX in enum?
or any patches to change include/linux/netdevice.h "Transmit return codes:" section?
Not sure, that blindly following coccinelle recommendations is a good
choice in this particular case.
[1] https://lkml.org/lkml/2018/9/20/881
--
regards,
-grygorii
^ permalink raw reply
* Re: [PATCH] netlink: add policy attribute range validation
From: Johannes Berg @ 2018-09-26 20:35 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1537993066.28767.29.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
On Wed, 2018-09-26 at 22:17 +0200, Johannes Berg wrote:
> On Wed, 2018-09-26 at 22:06 +0200, Johannes Berg wrote:
> > From: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >
> > Without further bloating the policy structs, we can overload
> > the `validation_data' pointer with a struct of s16 min, max
> > and use those to validate ranges in NLA_{U,S}{8,16,32,64}
> > attributes.
> >
> > It may sound strange to validate NLA_U32 with a s16 max, but
> > in many cases NLA_U32 is used for enums etc. since there's no
> > size benefit in using a smaller attribute width anyway, due
> > to netlink attribute alignment; in cases like that it's still
> > useful, particularly when the attribute really transports an
> > enum value.
>
> That said, I did find a few places where we could benefit from a larger
> type here - e.g. having a NLA_U16 that must be non-zero cannot be
> represented in the policy as is, since you can't set max to 65535.
We could also fix that, btw, by taking two bits out of the "type" field,
and letting those indicate "check_min" and "check_max". That would also
fix the other thing I noted regarding the union, I suppose.
I didn't really like that too much because it makes the whole thing far
more complex, but perhaps if we hide it behind macros like
#define NLA_POLICY_RANGE(tp, _min, _max) {
.type = tp,
.min = _min, .check_min = 1,
.max = _max, .check_max = 1,
}
#define NLA_POLICY_MIN(tp, _min) {
.type = tp,
.min = _min, .check_min = 1,
}
#define NLA_POLICY_MAX(tp, _max) {
.type = tp,
.max = _max, .check_max = 1,
}
it becomes more palatable?
johannes
^ permalink raw reply
* Re: [PATCH stable 4.4 V2 0/6] fix SegmentSmack in stable branch (CVE-2018-5390)
From: Greg KH @ 2018-09-26 20:21 UTC (permalink / raw)
To: maowenan; +Cc: netdev, dwmw2, eric.dumazet, davem, stable, linux-kernel
In-Reply-To: <83856420-af5a-e469-5b5b-e24634fc290f@huawei.com>
On Tue, Sep 25, 2018 at 10:10:15PM +0800, maowenan wrote:
> Hi Greg:
>
> can you review this patch set?
It is still in the queue, don't worry. It will take some more time to
properly review and test it.
Ideally you could get someone else to test this and provide a
"tested-by:" tag for it?
thanks,
greg k-h
^ 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