* [PATCH net-next] net: dsa: mv88e6xxx: bitwise vs logical bug
From: Dan Carpenter @ 2018-08-14 9:06 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vivien Didelot, Florian Fainelli, David S. Miller, netdev,
kernel-janitors
We are trying to test if these flags are set but there are some && vs &
typos.
Fixes: efd1ba6af93f ("net: dsa: mv88e6xxx: Add SERDES phydev_mac_change up for 6390")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/dsa/mv88e6xxx/serdes.c b/drivers/net/dsa/mv88e6xxx/serdes.c
index f007d109b385..e82983975754 100644
--- a/drivers/net/dsa/mv88e6xxx/serdes.c
+++ b/drivers/net/dsa/mv88e6xxx/serdes.c
@@ -502,8 +502,8 @@ static irqreturn_t mv88e6390_serdes_thread_fn(int irq, void *dev_id)
err = mv88e6390_serdes_irq_status_sgmii(chip, lane, &status);
if (err)
goto out;
- if (status && (MV88E6390_SGMII_INT_LINK_DOWN ||
- MV88E6390_SGMII_INT_LINK_UP)) {
+ if (status & (MV88E6390_SGMII_INT_LINK_DOWN |
+ MV88E6390_SGMII_INT_LINK_UP)) {
ret = IRQ_HANDLED;
mv88e6390_serdes_irq_link_sgmii(chip, port->port, lane);
}
^ permalink raw reply related
* Re: [PATCH net 2/2] net/mlx5e: Cleanup of dcbnl related fields
From: Yuval Shaia @ 2018-08-14 9:01 UTC (permalink / raw)
To: Saeed Mahameed, Haakon Bugge
Cc: David S. Miller, netdev, Huy Nguyen, yuval.shaia
In-Reply-To: <20180808224808.12600-3-saeedm@mellanox.com>
On Wed, Aug 08, 2018 at 03:48:08PM -0700, Saeed Mahameed wrote:
> From: Huy Nguyen <huyn@mellanox.com>
>
> Remove unused netdev_registered_init/remove in en.h
> Return ENOSUPPORT if the check MLX5_DSCP_SUPPORTED fails.
s/ENOSUPPORT/EOPNOTSUPP
(noted by Haakon)
> Remove extra white space
>
> Fixes: 2a5e7a1344f4 ("net/mlx5e: Add dcbnl dscp to priority support")
> Signed-off-by: Huy Nguyen <huyn@mellanox.com>
> Cc: Yuval Shaia <yuval.shaia@oracle.com>
> Reviewed-by: Parav Pandit <parav@mellanox.com>
> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 --
> .../ethernet/mellanox/mlx5/core/en_dcbnl.c | 30 +++++++------------
> 2 files changed, 11 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h b/drivers/net/ethernet/mellanox/mlx5/core/en.h
> index eb9eb7aa953a..405236cf0b04 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
> @@ -858,8 +858,6 @@ struct mlx5e_profile {
> mlx5e_fp_handle_rx_cqe handle_rx_cqe;
> mlx5e_fp_handle_rx_cqe handle_rx_cqe_mpwqe;
> } rx_handlers;
> - void (*netdev_registered_init)(struct mlx5e_priv *priv);
> - void (*netdev_registered_remove)(struct mlx5e_priv *priv);
> int max_tc;
> };
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
> index e33afa8d2417..722998d68564 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
> @@ -443,16 +443,12 @@ static int mlx5e_dcbnl_ieee_setapp(struct net_device *dev, struct dcb_app *app)
> bool is_new;
> int err;
>
> - if (app->selector != IEEE_8021QAZ_APP_SEL_DSCP)
> - return -EINVAL;
> -
> - if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager))
> - return -EINVAL;
> -
> - if (!MLX5_DSCP_SUPPORTED(priv->mdev))
> - return -EINVAL;
> + if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager) ||
> + !MLX5_DSCP_SUPPORTED(priv->mdev))
> + return -EOPNOTSUPP;
>
> - if (app->protocol >= MLX5E_MAX_DSCP)
> + if ((app->selector != IEEE_8021QAZ_APP_SEL_DSCP) ||
> + (app->protocol >= MLX5E_MAX_DSCP))
> return -EINVAL;
>
> /* Save the old entry info */
> @@ -500,16 +496,12 @@ static int mlx5e_dcbnl_ieee_delapp(struct net_device *dev, struct dcb_app *app)
> struct mlx5e_priv *priv = netdev_priv(dev);
> int err;
>
> - if (app->selector != IEEE_8021QAZ_APP_SEL_DSCP)
> - return -EINVAL;
> -
> - if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager))
> - return -EINVAL;
> -
> - if (!MLX5_DSCP_SUPPORTED(priv->mdev))
> - return -EINVAL;
> + if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager) ||
> + !MLX5_DSCP_SUPPORTED(priv->mdev))
> + return -EOPNOTSUPP;
>
> - if (app->protocol >= MLX5E_MAX_DSCP)
> + if ((app->selector != IEEE_8021QAZ_APP_SEL_DSCP) ||
> + (app->protocol >= MLX5E_MAX_DSCP))
> return -EINVAL;
>
> /* Skip if no dscp app entry */
> @@ -1146,7 +1138,7 @@ static int mlx5e_set_trust_state(struct mlx5e_priv *priv, u8 trust_state)
> {
> int err;
>
> - err = mlx5_set_trust_state(priv->mdev, trust_state);
> + err = mlx5_set_trust_state(priv->mdev, trust_state);
> if (err)
> return err;
> priv->dcbx_dp.trust_state = trust_state;
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH net-next][RFC] net/tls: Add support for async decryption of tls records
From: Vakul Garg @ 2018-08-14 14:17 UTC (permalink / raw)
To: netdev; +Cc: borisp, aviadye, davejwatson, davem, Vakul Garg
Incoming TLS records which are directly decrypted into user space
application buffer i.e. records which are decrypted in zero-copy mode
are submitted for async decryption. When the decryption cryptoapi
returns -EINPROGRESS, the next tls record is parsed and then submitted
for decryption. The references to records which has been sent for async
decryption are dropped. This happens in a loop for all the records that
can be decrypted in zero-copy mode. For records for which decryption is
not possible in zero-copy mode, asynchronous decryption is not used and
we wait for decryption crypto api to complete.
For crypto requests executing in async fashion, the memory for
aead_request, sglists and skb etc is freed from the decryption
completion handler. The decryption completion handler wakesup the
sleeping user context. This happens when the user context is done
enqueueing all the crypto requests and is waiting for all the async
operations to finish. Since the splice() operation does not use
zero-copy decryption, async remains disabled for splice().
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
---
include/net/tls.h | 6 +++
net/tls/tls_sw.c | 134 +++++++++++++++++++++++++++++++++++++++++++++++++-----
2 files changed, 129 insertions(+), 11 deletions(-)
diff --git a/include/net/tls.h b/include/net/tls.h
index d5c683e8bb22..cd0a65bd92f9 100644
--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -124,6 +124,12 @@ struct tls_sw_context_rx {
struct sk_buff *recv_pkt;
u8 control;
bool decrypted;
+ atomic_t decrypt_pending;
+ bool async_notify;
+};
+
+struct decrypt_req_ctx {
+ struct sock *sk;
};
struct tls_record_info {
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 52fbe727d7c1..e2f0df18b6cf 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -43,12 +43,50 @@
#define MAX_IV_SIZE TLS_CIPHER_AES_GCM_128_IV_SIZE
+static void tls_decrypt_done(struct crypto_async_request *req, int err)
+{
+ struct aead_request *aead_req = (struct aead_request *)req;
+ struct decrypt_req_ctx *req_ctx =
+ (struct decrypt_req_ctx *)(aead_req + 1);
+
+ struct scatterlist *sgout = aead_req->dst;
+
+ struct tls_context *tls_ctx = tls_get_ctx(req_ctx->sk);
+ struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
+ int pending = atomic_dec_return(&ctx->decrypt_pending);
+ struct scatterlist *sg;
+ unsigned int pages;
+
+ /* Propagate if there was an err */
+ if (err) {
+ ctx->async_wait.err = err;
+ tls_err_abort(req_ctx->sk, err);
+ }
+
+ /* Release the skb, pages and memory allocated for crypto req */
+ kfree_skb(req->data);
+
+ /* Skip the first S/G entry as it points to AAD */
+ for_each_sg(sg_next(sgout), sg, UINT_MAX, pages) {
+ if (!sg)
+ break;
+ put_page(sg_page(sg));
+ }
+
+ kfree(aead_req);
+
+ if (!pending && READ_ONCE(ctx->async_notify))
+ complete(&ctx->async_wait.completion);
+}
+
static int tls_do_decryption(struct sock *sk,
+ struct sk_buff *skb,
struct scatterlist *sgin,
struct scatterlist *sgout,
char *iv_recv,
size_t data_len,
- struct aead_request *aead_req)
+ struct aead_request *aead_req,
+ bool async)
{
struct tls_context *tls_ctx = tls_get_ctx(sk);
struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
@@ -59,10 +97,34 @@ static int tls_do_decryption(struct sock *sk,
aead_request_set_crypt(aead_req, sgin, sgout,
data_len + tls_ctx->rx.tag_size,
(u8 *)iv_recv);
- aead_request_set_callback(aead_req, CRYPTO_TFM_REQ_MAY_BACKLOG,
- crypto_req_done, &ctx->async_wait);
- ret = crypto_wait_req(crypto_aead_decrypt(aead_req), &ctx->async_wait);
+ if (async) {
+ struct decrypt_req_ctx *req_ctx;
+
+ req_ctx = (struct decrypt_req_ctx *)(aead_req + 1);
+ req_ctx->sk = sk;
+
+ aead_request_set_callback(aead_req,
+ CRYPTO_TFM_REQ_MAY_BACKLOG,
+ tls_decrypt_done, skb);
+ atomic_inc(&ctx->decrypt_pending);
+ } else {
+ aead_request_set_callback(aead_req,
+ CRYPTO_TFM_REQ_MAY_BACKLOG,
+ crypto_req_done, &ctx->async_wait);
+ }
+
+ ret = crypto_aead_decrypt(aead_req);
+ if (ret == -EINPROGRESS) {
+ if (async)
+ return ret;
+
+ ret = crypto_wait_req(ret, &ctx->async_wait);
+ }
+
+ if (async)
+ atomic_dec(&ctx->decrypt_pending);
+
return ret;
}
@@ -763,7 +825,10 @@ static int decrypt_internal(struct sock *sk, struct sk_buff *skb,
}
/* Prepare and submit AEAD request */
- err = tls_do_decryption(sk, sgin, sgout, iv, data_len, aead_req);
+ err = tls_do_decryption(sk, skb, sgin, sgout, iv,
+ data_len, aead_req, *zc);
+ if (err == -EINPROGRESS)
+ return err;
/* Release the pages in case iov was mapped to pages */
for (; pages > 0; pages--)
@@ -788,8 +853,12 @@ static int decrypt_skb_update(struct sock *sk, struct sk_buff *skb,
#endif
if (!ctx->decrypted) {
err = decrypt_internal(sk, skb, dest, NULL, chunk, zc);
- if (err < 0)
+ if (err < 0) {
+ if (err == -EINPROGRESS)
+ tls_advance_record_sn(sk, &tls_ctx->rx);
+
return err;
+ }
} else {
*zc = false;
}
@@ -851,6 +920,7 @@ int tls_sw_recvmsg(struct sock *sk,
int target, err = 0;
long timeo;
bool is_kvec = msg->msg_iter.type & ITER_KVEC;
+ int num_async = 0;
flags |= nonblock;
@@ -862,7 +932,10 @@ int tls_sw_recvmsg(struct sock *sk,
target = sock_rcvlowat(sk, flags & MSG_WAITALL, len);
timeo = sock_rcvtimeo(sk, flags & MSG_DONTWAIT);
do {
+ int full_len;
+ int offset;
bool zc = false;
+ bool async = false;
int chunk = 0;
skb = tls_wait_data(sk, flags, timeo, &err);
@@ -870,6 +943,9 @@ int tls_sw_recvmsg(struct sock *sk,
goto recv_end;
rxm = strp_msg(skb);
+ full_len = rxm->full_len;
+ offset = rxm->offset;
+
if (!cmsg) {
int cerr;
@@ -888,7 +964,7 @@ int tls_sw_recvmsg(struct sock *sk,
}
if (!ctx->decrypted) {
- int to_copy = rxm->full_len - tls_ctx->rx.overhead_size;
+ int to_copy = full_len - tls_ctx->rx.overhead_size;
if (!is_kvec && to_copy <= len &&
likely(!(flags & MSG_PEEK)))
@@ -896,42 +972,76 @@ int tls_sw_recvmsg(struct sock *sk,
err = decrypt_skb_update(sk, skb, &msg->msg_iter,
&chunk, &zc);
- if (err < 0) {
+ if (err < 0 && err != -EINPROGRESS) {
tls_err_abort(sk, EBADMSG);
goto recv_end;
}
+
+ if (err == -EINPROGRESS) {
+ async = true;
+ num_async++;
+ goto pick_next_record;
+ }
+
ctx->decrypted = true;
}
if (!zc) {
- chunk = min_t(unsigned int, rxm->full_len, len);
- err = skb_copy_datagram_msg(skb, rxm->offset, msg,
+ chunk = min_t(unsigned int, full_len, len);
+
+ err = skb_copy_datagram_msg(skb, offset, msg,
chunk);
if (err < 0)
goto recv_end;
}
+pick_next_record:
copied += chunk;
len -= chunk;
if (likely(!(flags & MSG_PEEK))) {
u8 control = ctx->control;
- if (tls_sw_advance_skb(sk, skb, chunk)) {
+ if (async) {
+ /* Finished with current record, pick up next */
+ ctx->recv_pkt = NULL;
+ __strp_unpause(&ctx->strp);
+ goto mark_eor_chk_ctrl;
+ } else if (tls_sw_advance_skb(sk, skb, chunk)) {
/* Return full control message to
* userspace before trying to parse
* another message type
*/
+mark_eor_chk_ctrl:
msg->msg_flags |= MSG_EOR;
if (control != TLS_RECORD_TYPE_DATA)
goto recv_end;
+ } else {
+ break;
}
}
+
/* If we have a new message from strparser, continue now. */
if (copied >= target && !ctx->recv_pkt)
break;
} while (len);
recv_end:
+ if (num_async) {
+ /* Wait for all previously submitted records to be decrypted */
+ smp_store_mb(ctx->async_notify, true);
+ if (atomic_read(&ctx->decrypt_pending)) {
+ err = crypto_wait_req(-EINPROGRESS, &ctx->async_wait);
+ if (err) {
+ /* one of async decrypt failed */
+ tls_err_abort(sk, err);
+ copied = 0;
+ }
+ } else {
+ reinit_completion(&ctx->async_wait.completion);
+ }
+ WRITE_ONCE(ctx->async_notify, false);
+ }
+
release_sock(sk);
return copied ? : err;
}
@@ -1271,6 +1381,8 @@ int tls_set_sw_offload(struct sock *sk, struct tls_context *ctx, int tx)
goto free_aead;
if (sw_ctx_rx) {
+ (*aead)->reqsize = sizeof(struct decrypt_req_ctx);
+
/* Set up strparser */
memset(&cb, 0, sizeof(cb));
cb.rcv_msg = tls_queue;
--
2.13.6
^ permalink raw reply related
* [PATCH] 9p/xen: fix check for xenbus_read error in front_probe
From: Dominique Martinet @ 2018-08-14 8:40 UTC (permalink / raw)
To: v9fs-developer
Cc: Dominique Martinet, netdev, Stefano Stabellini,
Eric Van Hensbergen, Latchesar Ionkov
From: Dominique Martinet <dominique.martinet@cea.fr>
If the xen bus exists but does not expose the proper interface, it is
possible to get a non-zero length but still some error, leading to
strcmp failing trying to load invalid memory addresses e.g.
fffffffffffffffe.
There is then no need to check length when there is no error, as the
xenbus driver guarantees that the string is nul-terminated.
Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Eric Van Hensbergen <ericvh@gmail.com>
Cc: Latchesar Ionkov <lucho@ionkov.net>
---
This is a trivial bug I stumbled on when setting up xen with p9fs and
running the VM in pvm: it had enough in the bus to trigger the probe
but then there was no version and it tried to return ENOENT but len
was set to the lower-level message size.
net/9p/trans_xen.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index 1a5b38892eb4..f76beadddfc3 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -391,9 +391,9 @@ static int xen_9pfs_front_probe(struct xenbus_device *dev,
unsigned int max_rings, max_ring_order, len = 0;
versions = xenbus_read(XBT_NIL, dev->otherend, "versions", &len);
- if (!len)
- return -EINVAL;
+ if (IS_ERR(versions))
+ return PTR_ERR(versions);
if (strcmp(versions, "1")) {
kfree(versions);
return -EINVAL;
}
--
2.17.1
^ permalink raw reply related
* Re: [RFC PATCH net-next V2 0/6] XDP rx handler
From: Jesper Dangaard Brouer @ 2018-08-14 10:17 UTC (permalink / raw)
To: Jason Wang; +Cc: Alexei Starovoitov, netdev, linux-kernel, ast, daniel, mst
In-Reply-To: <5de3d14f-f21a-c806-51f4-b5efd7d809b7@redhat.com>
On Tue, 14 Aug 2018 15:59:01 +0800
Jason Wang <jasowang@redhat.com> wrote:
> On 2018年08月14日 08:32, Alexei Starovoitov wrote:
> > On Mon, Aug 13, 2018 at 11:17:24AM +0800, Jason Wang wrote:
> >> Hi:
> >>
> >> This series tries to implement XDP support for rx hanlder. This would
> >> be useful for doing native XDP on stacked device like macvlan, bridge
> >> or even bond.
> >>
> >> The idea is simple, let stacked device register a XDP rx handler. And
> >> when driver return XDP_PASS, it will call a new helper xdp_do_pass()
> >> which will try to pass XDP buff to XDP rx handler directly. XDP rx
> >> handler may then decide how to proceed, it could consume the buff, ask
> >> driver to drop the packet or ask the driver to fallback to normal skb
> >> path.
> >>
> >> A sample XDP rx handler was implemented for macvlan. And virtio-net
> >> (mergeable buffer case) was converted to call xdp_do_pass() as an
> >> example. For ease comparision, generic XDP support for rx handler was
> >> also implemented.
> >>
> >> Compared to skb mode XDP on macvlan, native XDP on macvlan (XDP_DROP)
> >> shows about 83% improvement.
> > I'm missing the motiviation for this.
> > It seems performance of such solution is ~1M packet per second.
>
> Notice it was measured by virtio-net which is kind of slow.
>
> > What would be a real life use case for such feature ?
>
> I had another run on top of 10G mlx4 and macvlan:
>
> XDP_DROP on mlx4: 14.0Mpps
> XDP_DROP on macvlan: 10.05Mpps
>
> Perf shows macvlan_hash_lookup() and indirect call to
> macvlan_handle_xdp() are the reasons for the number drop. I think the
> numbers are acceptable. And we could try more optimizations on top.
>
> So here's real life use case is trying to have an fast XDP path for rx
> handler based device:
>
> - For containers, we can run XDP for macvlan (~70% of wire speed). This
> allows a container specific policy.
> - For VM, we can implement macvtap XDP rx handler on top. This allow us
> to forward packet to VM without building skb in the setup of macvtap.
> - The idea could be used by other rx handler based device like bridge,
> we may have a XDP fast forwarding path for bridge.
>
> >
> > Another concern is that XDP users expect to get line rate performance
> > and native XDP delivers it. 'generic XDP' is a fallback only
> > mechanism to operate on NICs that don't have native XDP yet.
>
> So I can replace generic XDP TX routine with a native one for macvlan.
If you simply implement ndo_xdp_xmit() for macvlan, and instead use
XDP_REDIRECT, then we are basically done.
> > Toshiaki's veth XDP work fits XDP philosophy and allows
> > high speed networking to be done inside containers after veth.
> > It's trying to get to line rate inside container.
>
> This is one of the goal of this series as well. I agree veth XDP work
> looks pretty fine, but it only work for a specific setup I believe since
> it depends on XDP_REDIRECT which is supported by few drivers (and
> there's no VF driver support).
The XDP_REDIRECT (RX-side) is trivial to add to drivers. It is a bad
argument that only a few drivers implement this. Especially since all
drivers also need to be extended with your proposed xdp_do_pass() call.
(rant) The thing that is delaying XDP_REDIRECT adaption in drivers, is
that it is harder to implement the TX-side, as the ndo_xdp_xmit() call
have to allocate HW TX-queue resources. If we disconnect RX and TX
side of redirect, then we can implement RX-side in an afternoon.
> And in order to make it work for a end
> user, the XDP program still need logic like hash(map) lookup to
> determine the destination veth.
That _is_ the general idea behind XDP and eBPF, that we need to add logic
that determine the destination. The kernel provides the basic
mechanisms for moving/redirecting packets fast, and someone else
builds an orchestration tool like Cilium, that adds the needed logic.
Did you notice that we (Ahern) added bpf_fib_lookup a FIB route lookup
accessible from XDP.
For macvlan, I imagine that we could add a BPF helper that allows you
to lookup/call macvlan_hash_lookup().
> > This XDP rx handler stuff is destined to stay at 1Mpps speeds forever
> > and the users will get confused with forever slow modes of XDP.
> >
> > Please explain the problem you're trying to solve.
> > "look, here I can to XDP on top of macvlan" is not an explanation of the problem.
> >
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: serdev: How to attach serdev devices to USB based tty devices?
From: Oliver Neukum @ 2018-08-14 7:23 UTC (permalink / raw)
To: Andreas Färber, Rob Herring, linux-serial@vger.kernel.org,
linux-usb
Cc: Jian-Hong Pan, Xue Liu, Ben Whitten, Linux-MIPS,
linux-arm-kernel@lists.infradead.org, Stefan Rehm,
LoRa_Community_Support@semtech.com, Alexander Graf, devicetree,
netdev@vger.kernel.org
In-Reply-To: <3639955d-5990-1c82-7158-ac07b33c41f2@suse.de>
On Di, 2018-08-14 at 04:28 +0200, Andreas Färber wrote:
> My idea then was that if we had some unique criteria like vendor and
> product IDs (or whatever is supported in usb_device_id), we could write
> a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> could call into the existing tty driver's probe function and afterwards
> try creating and attaching the appropriate serdev device, i.e. a fixed
> USB-to-serdev driver mapping. Problem is that most devices don't seem to
> implement any unique identifier I could make this depend on - either by
> using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> virtual com port identifiers in CDC firmware and only differing in the
> textual description [3] the usb_device_id does not seem to match on.
If you really must do this you can benignly fail probe(). Thus you
can compare strings within your probe() method.
This sucks because you need to make sure your drivers are always
loaded in a certain order and you really rely on undocumented
properties, but it can be done.
Regards
Oliver
^ permalink raw reply
* Re: TJA1100 100Base-T1 PHY features via ethtool?
From: Michael Grzeschik @ 2018-08-14 7:13 UTC (permalink / raw)
To: Florian Fainelli; +Cc: davem, netdev, kernel
In-Reply-To: <d7ce5ce0-665e-2b27-72e3-24656999b7c7@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2467 bytes --]
On Mon, Aug 13, 2018 at 12:53:35PM -0700, Florian Fainelli wrote:
> On 08/13/2018 12:35 PM, Michael Grzeschik wrote:
> > Hi David,
> >
> > I use a special 100Base-T1 phy (NXP TJA1100 [1]) that has some features
> > like:
> >
> > - enabling/disabling test modes
> > - fault detection
> > - switching managed/autonomous mode
> > - signal quality indication
> > - ...
> >
> > I already implemented the support of the features with the
> > ethtool --get/set-phy-tunables features by adding ethtool_phy_tunables:
> >
> > ETHTOOL_PHY_TEST_MODE
> > ETHTOOL_PHY_FAULT_DETECTION
> > ETHTOOL_PHY_MANAGED_MODE
> > ETHTOOL_PHY_SIGNAL_QUALITY
> >
> > Before posting my series I wanted to ensure that this is the preferred
> > interface for those options.
>
> The tunable interface is there, but is very limited. A few months ago, I
> had started proposing an interface to support PHY test modes [1] (the
> standard IEEE 802.3 defined ones) but a lot of it should now be migrated
> to the work that Michal is doing on the conversion of ethtool to netlink
> [2].
>
> [1]: https://lkml.org/lkml/2018/4/27/1172
> [2]: https://www.spinics.net/lists/netdev/msg516233.html
The ethtool userspace tool is somehow odd to program on,
so switching to netlink is definitively a great idea!
> >
> > I found a series from 2016 [2] that implements the userspace part for
> > the loopback feature of some phys, that did not get mainline so far
> > which makes me wonder if ethtool is still the way to go.
>
> ethtool is being converted to netlink, and that will be a much more
> flexible interface to work with since it is basically easily extensible
> (unlike the current ethtool + ioctl approach).
Yes, netlink sounds absolutely more useful here.
> Back when the patches were proposed, we just had mild disagreement on
> the loopback terminology being used, and then nothing happened.
Right, thanks for clarification!
>
> >
> > [1] https://www.nxp.com/docs/en/data-sheet/TJA1100.pdf
> > [2] https://www.spinics.net/lists/netdev/msg406614.html
> >
> > Thanks,
> > Michael
> >
>
>
> --
> Florian
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] NFC: Fix possible memory corruption when handling SHDLC I-Frame commands
From: Dan Carpenter @ 2018-08-14 9:54 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: security, kdeus, Samuel Ortiz, David S. Miller, Allen Pais,
Kees Cook, linux-wireless, netdev, linux-kernel
In-Reply-To: <20180813223910.26276-1-surenb@google.com>
Thanks. This is great. I'm so glad these are finally getting fixed.
Do we need to fix nfc_hci_msg_rx_work() and nfc_hci_recv_from_llc() as
well? In nfc_hci_recv_from_llc() we allow pipe to be NFC_HCI_FRAGMENT
(0x7f) so that's one element beyond the end of the array and the
NFC_HCI_HCP_RESPONSE isn't checked.
Also nci_hci_msg_rx_work() and nci_hci_data_received_cb() use
NCI_HCP_MSG_GET_PIPE() so those could be off by one.
regards,
dan carpenter
^ permalink raw reply
* WARNING: suspicious RCU usage in bpf_prog_array_copy_core
From: syzbot @ 2018-08-14 9:40 UTC (permalink / raw)
To: ast, daniel, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 4110b42356f3 Add linux-next specific files for 20180810
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=109bac02400000
kernel config: https://syzkaller.appspot.com/x/.config?x=1d80606e3795a4f5
dashboard link: https://syzkaller.appspot.com/bug?extid=6e72317008eef84a216b
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=157ef48a400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12e16cf8400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+6e72317008eef84a216b@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
=============================
WARNING: suspicious RCU usage
4.18.0-rc8-next-20180810+ #36 Not tainted
-----------------------------
kernel/bpf/core.c:1582 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
2 locks held by syz-executor287/4449:
#0: 00000000d8131c0c (&ctx->mutex){+.+.}, at:
perf_event_ctx_lock_nested+0x375/0x600 kernel/events/core.c:1276
#1: 000000006c916250 (bpf_event_mutex){+.+.}, at:
perf_event_query_prog_array+0x1c6/0x380 kernel/trace/bpf_trace.c:1062
stack backtrace:
CPU: 1 PID: 4449 Comm: syz-executor287 Not tainted
4.18.0-rc8-next-20180810+ #36
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+0x1c9/0x2b4 lib/dump_stack.c:113
lockdep_rcu_suspicious+0x14a/0x153 kernel/locking/lockdep.c:4562
bpf_prog_array_copy_core+0x2d9/0x360 kernel/bpf/core.c:1582
bpf_prog_array_copy_info+0x9a/0x110 kernel/bpf/core.c:1720
perf_event_query_prog_array+0x22e/0x380 kernel/trace/bpf_trace.c:1063
_perf_ioctl+0x986/0x1600 kernel/events/core.c:5079
perf_ioctl+0x59/0x80 kernel/events/core.c:5110
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:501 [inline]
do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
__do_sys_ioctl fs/ioctl.c:709 [inline]
__se_sys_ioctl fs/ioctl.c:707 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x440409
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fffc5fc1488 EFLAGS: 00000217 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440409
RDX: 0000000020000180 RSI: 00000000c008240a RDI: 0000000000000003
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000217 R12: 0000000000401c90
R13: 0000000000401d20 R14: 0000000000000000
---
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: [RFC PATCH net-next V2 6/6] virtio-net: support XDP rx handler
From: Jesper Dangaard Brouer @ 2018-08-14 9:22 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, linux-kernel, ast, daniel, mst
In-Reply-To: <1534130250-5302-7-git-send-email-jasowang@redhat.com>
On Mon, 13 Aug 2018 11:17:30 +0800
Jason Wang <jasowang@redhat.com> wrote:
> This patch tries to add the support of XDP rx handler to
> virtio-net. This is straight-forward, just call xdp_do_pass() and
> behave depends on its return value.
>
> Test was done by using XDP_DROP (xdp1) for macvlan on top of
> virtio-net. PPS of SKB mode was ~1.2Mpps while PPS of native XDP mode
> was ~2.2Mpps. About 83% improvement was measured.
I'm not convinced...
Why are you not using XDP_REDIRECT, which is already implemented in
receive_mergeable (which you modify below).
The macvlan driver just need to implement ndo_xdp_xmit(), and then you
can redirect (with XDP prog from physical driver into the guest). It
should be much faster...
> Notes: for RFC, only mergeable buffer case was implemented.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> drivers/net/virtio_net.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 62311dd..1e22ad9 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -777,6 +777,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
> rcu_read_lock();
> xdp_prog = rcu_dereference(rq->xdp_prog);
> if (xdp_prog) {
> + rx_xdp_handler_result_t ret;
> struct xdp_frame *xdpf;
> struct page *xdp_page;
> struct xdp_buff xdp;
> @@ -825,6 +826,15 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
>
> switch (act) {
> case XDP_PASS:
> + ret = xdp_do_pass(&xdp);
> + if (ret == RX_XDP_HANDLER_DROP)
> + goto drop;
> + if (ret != RX_XDP_HANDLER_FALLBACK) {
> + if (unlikely(xdp_page != page))
> + put_page(page);
> + rcu_read_unlock();
> + goto xdp_xmit;
> + }
> /* recalculate offset to account for any header
> * adjustments. Note other cases do not build an
> * skb and avoid using offset
> @@ -881,6 +891,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
> case XDP_ABORTED:
> trace_xdp_exception(vi->dev, xdp_prog, act);
> /* fall through */
> +drop:
> case XDP_DROP:
> if (unlikely(xdp_page != page))
> __free_pages(xdp_page, 0);
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH 1/1] NFC: Fix possible memory corruption when handling SHDLC I-Frame commands
From: Greg KH @ 2018-08-14 9:21 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: security, kdeus, Samuel Ortiz, David S. Miller, Allen Pais,
Kees Cook, linux-wireless, netdev, linux-kernel
In-Reply-To: <20180813223910.26276-1-surenb@google.com>
On Mon, Aug 13, 2018 at 03:39:08PM -0700, Suren Baghdasaryan wrote:
> When handling SHDLC I-Frame commands "pipe" field used for indexing
> into an array should be checked before usage. If left unchecked it
> might access memory outside of the array of size NFC_HCI_MAX_PIPES(127).
>
> Malformed NFC HCI frames could be injected by a malicious NFC device
> communicating with the device being attacked (remote attack vector),
> or even by an attacker with physical access to the I2C bus such that
> they could influence the data transfers on that bus (local attack vector).
> skb->data is controlled by the attacker and has only been sanitized in
> the most trivial ways (CRC check), therefore we can consider the
> create_info struct and all of its members to tainted. 'create_info->pipe'
> with max value of 255 (uint8) is used to take an offset of the
> hdev->pipes array of 127 elements which can lead to OOB write.
>
> Suggested-by: Kevin Deus <kdeus@google.com>
> Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* [PATCH] rds: fix building with IPV6=m
From: Arnd Bergmann @ 2018-08-14 9:07 UTC (permalink / raw)
To: Santosh Shilimkar, David S. Miller
Cc: Arnd Bergmann, Anders Roxell, Greg Thelen, Ka-Cheong Poon,
Stephen Hemminger, netdev, linux-rdma, rds-devel, linux-kernel
When CONFIG_RDS_TCP is built-in and CONFIG_IPV6 is a loadable
module, we get a link error agains the modular ipv6_chk_addr()
function:
net/rds/tcp.o: In function `rds_tcp_laddr_check':
tcp.c:(.text+0x3b2): undefined reference to `ipv6_chk_addr'
This adds back a dependency that forces RDS_TCP to also be
a loadable module when IPV6 is one.
Fixes: e65d4d96334e ("rds: Remove IPv6 dependency")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
net/rds/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/rds/Kconfig b/net/rds/Kconfig
index 41f75563b54b..01b3bd6a3708 100644
--- a/net/rds/Kconfig
+++ b/net/rds/Kconfig
@@ -16,6 +16,7 @@ config RDS_RDMA
config RDS_TCP
tristate "RDS over TCP"
depends on RDS
+ depends on IPV6 || !IPV6
---help---
Allow RDS to use TCP as a transport.
This transport does not support RDMA operations.
--
2.18.0
^ permalink raw reply related
* Re: [PATCH next-queue 3/8] ixgbe: add VF ipsec management
From: kbuild test robot @ 2018-08-14 5:31 UTC (permalink / raw)
To: Shannon Nelson
Cc: kbuild-all, intel-wired-lan, jeffrey.t.kirsher, steffen.klassert,
netdev
In-Reply-To: <1534185825-12451-4-git-send-email-shannon.nelson@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 4616 bytes --]
Hi Shannon,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on jkirsher-next-queue/dev-queue]
[also build test ERROR on v4.18 next-20180813]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Shannon-Nelson/ixgbe-ixgbevf-IPsec-offload-support-for-VFs/20180814-074800
base: https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git dev-queue
config: x86_64-randconfig-v0-08131550 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.o: In function `ixgbe_ipsec_vf_add_sa':
>> drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c:917: undefined reference to `xfrm_aead_get_byname'
make[1]: *** [vmlinux] Error 1
make[1]: Target '_all' not remade because of errors.
vim +917 drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
862
863 /**
864 * ixgbe_ipsec_vf_add_sa - translate VF request to SA add
865 * @adapter: board private structure
866 * @msgbuf: The message buffer
867 * @vf: the VF index
868 *
869 * Make up a new xs and algorithm info from the data sent by the VF.
870 * We only need to sketch in just enough to set up the HW offload.
871 * Put the resulting offload_handle into the return message to the VF.
872 *
873 * Returns 0 or error value
874 **/
875 int ixgbe_ipsec_vf_add_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf)
876 {
877 struct ixgbe_ipsec *ipsec = adapter->ipsec;
878 struct xfrm_algo_desc *algo;
879 struct sa_mbx_msg *sam;
880 struct xfrm_state *xs;
881 size_t aead_len;
882 u16 sa_idx;
883 u32 pfsa;
884 int err;
885
886 sam = (struct sa_mbx_msg *)(&msgbuf[1]);
887 if (!adapter->vfinfo[vf].trusted) {
888 e_warn(drv, "VF %d attempted to add an IPsec SA\n", vf);
889 err = -EACCES;
890 goto err_out;
891 }
892
893 /* Tx IPsec offload doesn't seem to work on this
894 * device, so block these requests for now.
895 */
896 if (!(sam->flags & XFRM_OFFLOAD_INBOUND)) {
897 err = -ENXIO;
898 goto err_out;
899 }
900
901 xs = kzalloc(sizeof(*xs), GFP_KERNEL);
902 if (unlikely(!xs)) {
903 err = -ENOMEM;
904 goto err_out;
905 }
906
907 xs->xso.flags = sam->flags;
908 xs->id.spi = sam->spi;
909 xs->id.proto = sam->proto;
910 xs->props.family = sam->family;
911 if (xs->props.family == AF_INET6)
912 memcpy(&xs->id.daddr.a6, sam->addr, sizeof(xs->id.daddr.a6));
913 else
914 memcpy(&xs->id.daddr.a4, sam->addr, sizeof(xs->id.daddr.a4));
915 xs->xso.dev = adapter->netdev;
916
> 917 algo = xfrm_aead_get_byname(aes_gcm_name, IXGBE_IPSEC_AUTH_BITS, 1);
918 if (unlikely(!algo)) {
919 err = -ENOENT;
920 goto err_xs;
921 }
922
923 aead_len = sizeof(*xs->aead) + IXGBE_IPSEC_KEY_BITS / 8;
924 xs->aead = kzalloc(aead_len, GFP_KERNEL);
925 if (unlikely(!xs->aead)) {
926 err = -ENOMEM;
927 goto err_xs;
928 }
929
930 xs->props.ealgo = algo->desc.sadb_alg_id;
931 xs->geniv = algo->uinfo.aead.geniv;
932 xs->aead->alg_icv_len = IXGBE_IPSEC_AUTH_BITS;
933 xs->aead->alg_key_len = IXGBE_IPSEC_KEY_BITS;
934 memcpy(xs->aead->alg_key, sam->key, sizeof(sam->key));
935 memcpy(xs->aead->alg_name, aes_gcm_name, sizeof(aes_gcm_name));
936
937 /* set up the HW offload */
938 err = ixgbe_ipsec_add_sa(xs);
939 if (err)
940 goto err_aead;
941
942 pfsa = xs->xso.offload_handle;
943 if (pfsa < IXGBE_IPSEC_BASE_TX_INDEX) {
944 sa_idx = pfsa - IXGBE_IPSEC_BASE_RX_INDEX;
945 ipsec->rx_tbl[sa_idx].vf = vf;
946 ipsec->rx_tbl[sa_idx].mode |= IXGBE_RXTXMOD_VF;
947 } else {
948 sa_idx = pfsa - IXGBE_IPSEC_BASE_TX_INDEX;
949 ipsec->tx_tbl[sa_idx].vf = vf;
950 ipsec->tx_tbl[sa_idx].mode |= IXGBE_RXTXMOD_VF;
951 }
952
953 msgbuf[1] = xs->xso.offload_handle;
954
955 return 0;
956
957 err_aead:
958 memset(xs->aead, 0, sizeof(*xs->aead));
959 kfree(xs->aead);
960 err_xs:
961 memset(xs, 0, sizeof(*xs));
962 kfree(xs);
963 err_out:
964 msgbuf[1] = err;
965 return err;
966 }
967
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 32985 bytes --]
^ permalink raw reply
* Re: [RFC PATCH net-next V2 0/6] XDP rx handler
From: Jason Wang @ 2018-08-14 7:59 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: netdev, linux-kernel, ast, daniel, jbrouer, mst
In-Reply-To: <20180814003253.fkgl6lyklc7fclvq@ast-mbp>
On 2018年08月14日 08:32, Alexei Starovoitov wrote:
> On Mon, Aug 13, 2018 at 11:17:24AM +0800, Jason Wang wrote:
>> Hi:
>>
>> This series tries to implement XDP support for rx hanlder. This would
>> be useful for doing native XDP on stacked device like macvlan, bridge
>> or even bond.
>>
>> The idea is simple, let stacked device register a XDP rx handler. And
>> when driver return XDP_PASS, it will call a new helper xdp_do_pass()
>> which will try to pass XDP buff to XDP rx handler directly. XDP rx
>> handler may then decide how to proceed, it could consume the buff, ask
>> driver to drop the packet or ask the driver to fallback to normal skb
>> path.
>>
>> A sample XDP rx handler was implemented for macvlan. And virtio-net
>> (mergeable buffer case) was converted to call xdp_do_pass() as an
>> example. For ease comparision, generic XDP support for rx handler was
>> also implemented.
>>
>> Compared to skb mode XDP on macvlan, native XDP on macvlan (XDP_DROP)
>> shows about 83% improvement.
> I'm missing the motiviation for this.
> It seems performance of such solution is ~1M packet per second.
Notice it was measured by virtio-net which is kind of slow.
> What would be a real life use case for such feature ?
I had another run on top of 10G mlx4 and macvlan:
XDP_DROP on mlx4: 14.0Mpps
XDP_DROP on macvlan: 10.05Mpps
Perf shows macvlan_hash_lookup() and indirect call to
macvlan_handle_xdp() are the reasons for the number drop. I think the
numbers are acceptable. And we could try more optimizations on top.
So here's real life use case is trying to have an fast XDP path for rx
handler based device:
- For containers, we can run XDP for macvlan (~70% of wire speed). This
allows a container specific policy.
- For VM, we can implement macvtap XDP rx handler on top. This allow us
to forward packet to VM without building skb in the setup of macvtap.
- The idea could be used by other rx handler based device like bridge,
we may have a XDP fast forwarding path for bridge.
>
> Another concern is that XDP users expect to get line rate performance
> and native XDP delivers it. 'generic XDP' is a fallback only
> mechanism to operate on NICs that don't have native XDP yet.
So I can replace generic XDP TX routine with a native one for macvlan.
> Toshiaki's veth XDP work fits XDP philosophy and allows
> high speed networking to be done inside containers after veth.
> It's trying to get to line rate inside container.
This is one of the goal of this series as well. I agree veth XDP work
looks pretty fine, but it only work for a specific setup I believe since
it depends on XDP_REDIRECT which is supported by few drivers (and
there's no VF driver support). And in order to make it work for a end
user, the XDP program still need logic like hash(map) lookup to
determine the destination veth.
> This XDP rx handler stuff is destined to stay at 1Mpps speeds forever
> and the users will get confused with forever slow modes of XDP.
>
> Please explain the problem you're trying to solve.
> "look, here I can to XDP on top of macvlan" is not an explanation of the problem.
>
Thanks
^ permalink raw reply
* Re: lock recursion - was: Re: [4.18 rc7] BUG: sleeping function called from invalid context at mm/slab.h:421
From: Mikhail Gavrilov @ 2018-08-14 5:10 UTC (permalink / raw)
To: pmladek
Cc: vbabka, davem, marcel, johan.hedberg, linux-bluetooth, netdev,
linux-mm, rostedt, sergey.senozhatsky, peterz
In-Reply-To: <20180808113615.qzdzifpkmt5yktbx@pathway.suse.cz>
That's all?
Issue happens everytime when I paired computer with bluetooth peripherals.
And this is not dependent on the bluetooth adapter used. I see this on
three different systems.
--
Best Regards,
Mike Gavrilov.
On Wed, 8 Aug 2018 at 16:36, Petr Mladek <pmladek@suse.com> wrote:
>
> On Wed 2018-08-08 11:05:00, Vlastimil Babka wrote:
> > On 08/08/2018 11:01 AM, Vlastimil Babka wrote:
> > > fbcon_startup() calls kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL) so
> > > it tells slab it can sleep. The problem must be higher in the stack,
> > > CCing printk people.
> >
> > Uh just noticed there was also attached dmesg which my reply converted
> > to inline. The first problem there is a lockdep splat.
>
> The lockdep splat might eventually be a valid issue (recursive lock) in the
> networking code. But it seems to be unrelated to the later problems
> with sleeping in fbcon_startup().
>
> Adding networking people into CC. Please, find below the relevant part
> from the dmesg. The full log can be found in the original message at
> https://marc.info/?l=linux-mm&m=153370024009996&w=2
>
> Lock recursion in bluetooth code:
>
> [ 32.050660] Bluetooth: RFCOMM TTY layer initialized
> [ 32.050675] Bluetooth: RFCOMM socket layer initialized
> [ 32.050719] Bluetooth: RFCOMM ver 1.11
> [ 34.413359] fuse init (API version 7.27)
> [ 40.562871] rfkill: input handler disabled
> [ 42.272301] pool (2344) used greatest stack depth: 11320 bytes left
> [ 42.701283] ISO 9660 Extensions: Microsoft Joliet Level 3
> [ 42.704062] ISO 9660 Extensions: Microsoft Joliet Level 3
> [ 42.710375] ISO 9660 Extensions: RRIP_1991A
> [ 64.930766] tracker-extract (2229) used greatest stack depth: 11176 bytes left
> [ 465.911281] TaskSchedulerFo (3362) used greatest stack depth: 11112 bytes left
> [ 491.743600] TaskSchedulerFo (3364) used greatest stack depth: 11032 bytes left
> [ 507.733884] nf_conntrack: default automatic helper assignment has been turned off \
> for security reasons and CT-based firewall rule not found. Use the iptables CT \
> target to attach helpers instead. [ 660.384586] kworker/dying (155) used greatest \
> stack depth: 10888 bytes left [ 699.910094] device enp2s0 entered promiscuous mode
> [ 1098.658964] kworker/dying (7) used greatest stack depth: 10712 bytes left
> [ 1843.488301] perf: interrupt took too long (2510 > 2500), lowering \
> kernel.perf_event_max_sample_rate to 79000 [ 2819.896469] perf: interrupt took too \
> long (3138 > 3137), lowering kernel.perf_event_max_sample_rate to 63000 [ \
> 6120.247124] perf: interrupt took too long (3923 > 3922), lowering \
> kernel.perf_event_max_sample_rate to 50000
>
> [ 6829.212232] ============================================
> [ 6829.212234] WARNING: possible recursive locking detected
> [ 6829.212236] 4.18.0-0.rc7.git1.1.fc29.x86_64 #1 Not tainted
> [ 6829.212237] --------------------------------------------
> [ 6829.212239] kworker/u17:2/28441 is trying to acquire lock:
> [ 6829.212242] 000000004025b723 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: \
> bt_accept_enqueue+0x3c/0xb0 [bluetooth] [ 6829.212260]
> but task is already holding lock:
> [ 6829.212262] 000000004cb71eef (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: \
> l2cap_sock_new_connection_cb+0x18/0xa0 [bluetooth] [ 6829.212278]
> other info that might help us debug this:
> [ 6829.212279] Possible unsafe locking scenario:
>
> [ 6829.212281] CPU0
> [ 6829.212282] ----
> [ 6829.212284] lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
> [ 6829.212286] lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
> [ 6829.212288]
> *** DEADLOCK ***
>
> [ 6829.212290] May be due to missing lock nesting notation
>
> [ 6829.212293] 5 locks held by kworker/u17:2/28441:
> [ 6829.212294] #0: 000000009af6a4dc ((wq_completion)"%s"hdev->name#2){+.+.}, at: \
> process_one_work+0x1f3/0x650 [ 6829.212301] #1: 000000006f7488f4 \
> ((work_completion)(&hdev->rx_work)){+.+.}, at: process_one_work+0x1f3/0x650 [ \
> 6829.212306] #2: 000000003dba8333 (&conn->chan_lock){+.+.}, at: \
> l2cap_connect+0x8f/0x5a0 [bluetooth] [ 6829.212321] #3: 00000000aaa813b9 \
> (&chan->lock/2){+.+.}, at: l2cap_connect+0xa9/0x5a0 [bluetooth] [ 6829.212335] #4: \
> 000000004cb71eef (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: \
> l2cap_sock_new_connection_cb+0x18/0xa0 [bluetooth] [ 6829.212350]
> stack backtrace:
> [ 6829.212354] CPU: 6 PID: 28441 Comm: kworker/u17:2 Not tainted \
> 4.18.0-0.rc7.git1.1.fc29.x86_64 #1 [ 6829.212355] Hardware name: Gigabyte Technology \
> Co., Ltd. Z87M-D3H/Z87M-D3H, BIOS F11 08/12/2014 [ 6829.212365] Workqueue: hci0 \
> hci_rx_work [bluetooth] [ 6829.212367] Call Trace:
> [ 6829.212373] dump_stack+0x85/0xc0
> [ 6829.212377] __lock_acquire.cold.64+0x158/0x227
> [ 6829.212381] ? mark_held_locks+0x57/0x80
> [ 6829.212384] lock_acquire+0x9e/0x1b0
> [ 6829.212394] ? bt_accept_enqueue+0x3c/0xb0 [bluetooth]
> [ 6829.212398] lock_sock_nested+0x72/0xa0
> [ 6829.212407] ? bt_accept_enqueue+0x3c/0xb0 [bluetooth]
> [ 6829.212417] bt_accept_enqueue+0x3c/0xb0 [bluetooth]
> [ 6829.212429] l2cap_sock_new_connection_cb+0x5d/0xa0 [bluetooth]
> [ 6829.212441] l2cap_connect+0x110/0x5a0 [bluetooth]
> [ 6829.212454] ? l2cap_recv_frame+0x6d0/0x2cb0 [bluetooth]
> [ 6829.212458] ? __mutex_unlock_slowpath+0x4b/0x2b0
> [ 6829.212470] l2cap_recv_frame+0x6e8/0x2cb0 [bluetooth]
> [ 6829.212474] ? __mutex_unlock_slowpath+0x4b/0x2b0
> [ 6829.212484] hci_rx_work+0x1c6/0x5d0 [bluetooth]
> [ 6829.212488] process_one_work+0x27d/0x650
> [ 6829.212492] worker_thread+0x3c/0x390
> [ 6829.212494] ? process_one_work+0x650/0x650
> [ 6829.212498] kthread+0x120/0x140
> [ 6829.212501] ? kthread_create_worker_on_cpu+0x70/0x70
> [ 6829.212504] ret_from_fork+0x3a/0x50
> [ 6829.285343] BUG: sleeping function called from invalid context at \
> net/core/sock.c:2833 [ 6829.285349] in_atomic(): 1, irqs_disabled(): 0, pid: 1743, \
> name: krfcommd [ 6829.285351] INFO: lockdep is turned off.
> [ 6829.285355] CPU: 6 PID: 1743 Comm: krfcommd Not tainted \
> 4.18.0-0.rc7.git1.1.fc29.x86_64 #1 [ 6829.285358] Hardware name: Gigabyte Technology \
> Co., Ltd. Z87M-D3H/Z87M-D3H, BIOS F11 08/12/2014 [ 6829.285360] Call Trace:
> [ 6829.285368] dump_stack+0x85/0xc0
> [ 6829.285373] ___might_sleep.cold.72+0xac/0xbc
> [ 6829.285378] lock_sock_nested+0x29/0xa0
> [ 6829.285394] bt_accept_enqueue+0x3c/0xb0 [bluetooth]
> [ 6829.285401] rfcomm_connect_ind+0x21b/0x260 [rfcomm]
> [ 6829.285406] rfcomm_run+0x1611/0x1820 [rfcomm]
> [ 6829.285411] ? do_wait_intr_irq+0xb0/0xb0
> [ 6829.285416] ? rfcomm_check_accept+0x90/0x90 [rfcomm]
> [ 6829.285419] kthread+0x120/0x140
> [ 6829.285422] ? kthread_create_worker_on_cpu+0x70/0x70
> [ 6829.285426] ret_from_fork+0x3a/0x50
> [ 6829.476282] input: 04:5D:4B:5F:34:57 as /devices/virtual/input/input35
> [ 7273.090391] show_signal_msg: 23 callbacks suppressed
> [ 7273.090393] CFileWriterThre[29422]: segfault at 7f078bfe7240 ip 00007f079137843c \
> sp 00007f078bb8dcf0 error 4 in steamclient.so[7f0790880000+14d2000] [ 7273.090404] \
> Code: 89 df ff d2 8b 45 00 83 f8 02 0f 84 9e 00 00 00 83 f8 03 0f 84 55 05 00 00 83 \
> f8 01 74 48 31 ed 4d 85 e4 74 11 48 85 db 74 0c <48> 8b 03 4c 89 e6 48 89 df ff 50 10 \
> 48 8b b4 24 e8 00 00 00 64 48 [ 7755.656023] rfkill: input handler enabled
> [ 7773.439895] rfkill: input handler disabled
> [ 8075.232946] BUG: sleeping function called from invalid context at \
> net/core/sock.c:2833 [ 8075.232951] in_atomic(): 1, irqs_disabled(): 0, pid: 1743, \
> name: krfcommd [ 8075.232952] INFO: lockdep is turned off.
> [ 8075.232956] CPU: 5 PID: 1743 Comm: krfcommd Tainted: G W \
> 4.18.0-0.rc7.git1.1.fc29.x86_64 #1 [ 8075.232957] Hardware name: Gigabyte Technology \
> Co., Ltd. Z87M-D3H/Z87M-D3H, BIOS F11 08/12/2014 [ 8075.232959] Call Trace:
> [ 8075.232965] dump_stack+0x85/0xc0
> [ 8075.232969] ___might_sleep.cold.72+0xac/0xbc
> [ 8075.232973] lock_sock_nested+0x29/0xa0
> [ 8075.232987] bt_accept_enqueue+0x3c/0xb0 [bluetooth]
> [ 8075.232992] rfcomm_connect_ind+0x21b/0x260 [rfcomm]
> [ 8075.232997] rfcomm_run+0x1611/0x1820 [rfcomm]
> [ 8075.233001] ? do_wait_intr_irq+0xb0/0xb0
> [ 8075.233005] ? rfcomm_check_accept+0x90/0x90 [rfcomm]
> [ 8075.233008] kthread+0x120/0x140
> [ 8075.233011] ? kthread_create_worker_on_cpu+0x70/0x70
> [ 8075.233014] ret_from_fork+0x3a/0x50
> [ 8075.413187] input: 04:5D:4B:5F:34:57 as /devices/virtual/input/input36
> [13538.300352] steam[4385]: segfault at 0 ip 00000000eabc32d9 sp 00000000ffdca1b0 \
> error 4 in vgui2_s.so[eab26000+292000] [13538.300365] Code: 74 03 00 00 00 00 00 00 \
> c7 44 24 08 02 00 00 00 c7 44 24 04 10 00 00 00 c7 04 24 44 ac 00 00 e8 1d 40 fb ff \
> 89 86 74 03 00 00 <8b> 00 8b 78 10 e8 3d 1a fb ff 8b 86 74 03 00 00 dd 5c 24 04 89 04 \
> [14324.004275] pool[443]: segfault at 0 ip 00007f53e2399556 sp 00007f53ceffcc40 \
> error 4 in libnssutil3.so[7f53e2395000+12000] [14324.004286] Code: d8 5b 5d 41 5c c3 \
> 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e fa 41 54 41 bc ff ff ff ff 55 53 \
> 48 89 fb e8 7a bc ff ff <48> 8b 3b 48 89 c5 e8 9f c1 ff ff 48 8b 43 38 48 39 c5 75 23 \
> eb 2d [14324.007764] rfkill: input handler enabled
> [14348.933385] rfkill: input handler disabled
> [15930.680376] DMA-API: debugging out of memory - disabling
> [16087.451698] vaapi-queue:src (10166) used greatest stack depth: 10616 bytes left
> [19689.192082] BUG: sleeping function called from invalid context at \
> net/core/sock.c:2833 [19689.192087] in_atomic(): 1, irqs_disabled(): 0, pid: 1743, \
> name: krfcommd [19689.192089] INFO: lockdep is turned off.
> [19689.192093] CPU: 6 PID: 1743 Comm: krfcommd Tainted: G W \
> 4.18.0-0.rc7.git1.1.fc29.x86_64 #1 [19689.192096] Hardware name: Gigabyte Technology \
> Co., Ltd. Z87M-D3H/Z87M-D3H, BIOS F11 08/12/2014 [19689.192098] Call Trace:
> [19689.192106] dump_stack+0x85/0xc0
> [19689.192112] ___might_sleep.cold.72+0xac/0xbc
> [19689.192117] lock_sock_nested+0x29/0xa0
> [19689.192142] bt_accept_enqueue+0x3c/0xb0 [bluetooth]
> [19689.192150] rfcomm_connect_ind+0x21b/0x260 [rfcomm]
> [19689.192157] rfcomm_run+0x1611/0x1820 [rfcomm]
> [19689.192163] ? do_wait_intr_irq+0xb0/0xb0
> [19689.192179] ? rfcomm_check_accept+0x90/0x90 [rfcomm]
> [19689.192183] kthread+0x120/0x140
> [19689.192186] ? kthread_create_worker_on_cpu+0x70/0x70
> [19689.192190] ret_from_fork+0x3a/0x50
> [19689.377451] input: 04:5D:4B:5F:34:57 as /devices/virtual/input/input37
>
>
> Best Regards,
> Petr
^ permalink raw reply
* inconsistent lock state in ila_xlat_nl_cmd_del_mapping
From: syzbot @ 2018-08-14 4:40 UTC (permalink / raw)
To: davem, gregkh, keescook, ktkhai, kuznet, linux-kernel, netdev,
pombredanne, stephen, syzkaller-bugs, tom, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 36d2f761b5aa cxgb4: update 1.20.8.0 as the latest firmware..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=17f429c8400000
kernel config: https://syzkaller.appspot.com/x/.config?x=dbf55ebfa6bfd517
dashboard link: https://syzkaller.appspot.com/bug?extid=3db64bd48b29a825d2db
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=14ed8a3c400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17a4c622400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3db64bd48b29a825d2db@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
8021q: adding VLAN 0 to HW filter on device team0
================================
WARNING: inconsistent lock state
4.18.0-rc8+ #179 Not tainted
--------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
syz-executor551/4387 [HC0[0]:SC0[0]:HE1:SE1] takes:
(____ptrval____) (&(&tlocks[i])->rlock){+.?.}, at: spin_lock
include/linux/spinlock.h:310 [inline]
(____ptrval____) (&(&tlocks[i])->rlock){+.?.}, at: ila_del_mapping
net/ipv6/ila/ila_xlat.c:290 [inline]
(____ptrval____) (&(&tlocks[i])->rlock){+.?.}, at:
ila_xlat_nl_cmd_del_mapping+0x46b/0xb00 net/ipv6/ila/ila_xlat.c:368
{IN-SOFTIRQ-W} state was registered at:
lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
_raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168
spin_lock_bh include/linux/spinlock.h:315 [inline]
__rhashtable_insert_fast include/linux/rhashtable.h:596 [inline]
rhashtable_lookup_insert_fast include/linux/rhashtable.h:784 [inline]
fdb_create+0x5cc/0x1710 net/bridge/br_fdb.c:508
br_fdb_update+0x4e7/0xd40 net/bridge/br_fdb.c:605
br_handle_frame_finish+0xa23/0x1960 net/bridge/br_input.c:97
br_nf_hook_thresh+0x48d/0x5f0 net/bridge/br_netfilter_hooks.c:1011
br_nf_pre_routing_finish_ipv6+0x7bc/0xef0
net/bridge/br_netfilter_ipv6.c:209
NF_HOOK include/linux/netfilter.h:287 [inline]
br_nf_pre_routing_ipv6+0x4af/0xac0 net/bridge/br_netfilter_ipv6.c:237
br_nf_pre_routing+0xb33/0x17d0 net/bridge/br_netfilter_hooks.c:494
nf_hook_entry_hookfn include/linux/netfilter.h:119 [inline]
nf_hook_slow+0xc2/0x1c0 net/netfilter/core.c:511
nf_hook include/linux/netfilter.h:242 [inline]
NF_HOOK include/linux/netfilter.h:285 [inline]
br_handle_frame+0xc0d/0x1a20 net/bridge/br_input.c:303
__netif_receive_skb_core+0x1455/0x3af0 net/core/dev.c:4821
__netif_receive_skb_one_core+0xd0/0x200 net/core/dev.c:4890
__netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5002
process_backlog+0x219/0x760 net/core/dev.c:5808
napi_poll net/core/dev.c:6228 [inline]
net_rx_action+0x7a5/0x1920 net/core/dev.c:6294
__do_softirq+0x2e8/0xb17 kernel/softirq.c:292
invoke_softirq kernel/softirq.c:372 [inline]
irq_exit+0x1d4/0x210 kernel/softirq.c:412
exiting_irq arch/x86/include/asm/apic.h:527 [inline]
smp_apic_timer_interrupt+0x186/0x730 arch/x86/kernel/apic/apic.c:1055
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:54
arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
default_idle+0xc7/0x450 arch/x86/kernel/process.c:500
arch_cpu_idle+0x10/0x20 arch/x86/kernel/process.c:491
default_idle_call+0x6d/0x90 kernel/sched/idle.c:93
cpuidle_idle_call kernel/sched/idle.c:153 [inline]
do_idle+0x3aa/0x570 kernel/sched/idle.c:262
cpu_startup_entry+0x10c/0x120 kernel/sched/idle.c:368
start_secondary+0x433/0x5d0 arch/x86/kernel/smpboot.c:270
secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
irq event stamp: 51111
hardirqs last enabled at (51111): [<ffffffff814fca78>]
queue_work_on+0xe8/0x1e0 kernel/workqueue.c:1490
hardirqs last disabled at (51110): [<ffffffff814fca2f>]
queue_work_on+0x9f/0x1e0 kernel/workqueue.c:1483
softirqs last enabled at (51088): [<ffffffff85079b7c>] spin_unlock_bh
include/linux/spinlock.h:355 [inline]
softirqs last enabled at (51088): [<ffffffff85079b7c>]
release_sock+0x1ec/0x2c0 net/core/sock.c:2860
softirqs last disabled at (51086): [<ffffffff85079a0d>] spin_lock_bh
include/linux/spinlock.h:315 [inline]
softirqs last disabled at (51086): [<ffffffff85079a0d>]
release_sock+0x7d/0x2c0 net/core/sock.c:2847
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&tlocks[i])->rlock);
<Interrupt>
lock(&(&tlocks[i])->rlock);
*** DEADLOCK ***
1 lock held by syz-executor551/4387:
#0: (____ptrval____) (cb_lock){++++}, at: genl_rcv+0x19/0x40
net/netlink/genetlink.c:636
stack backtrace:
CPU: 0 PID: 4387 Comm: syz-executor551 Not tainted 4.18.0-rc8+ #179
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+0x1c9/0x2b4 lib/dump_stack.c:113
print_usage_bug.cold.63+0x320/0x41a kernel/locking/lockdep.c:2546
valid_state kernel/locking/lockdep.c:2559 [inline]
mark_lock_irq kernel/locking/lockdep.c:2753 [inline]
mark_lock+0x1048/0x19f0 kernel/locking/lockdep.c:3151
mark_irqflags kernel/locking/lockdep.c:3047 [inline]
__lock_acquire+0x7ca/0x5020 kernel/locking/lockdep.c:3392
lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:310 [inline]
ila_del_mapping net/ipv6/ila/ila_xlat.c:290 [inline]
ila_xlat_nl_cmd_del_mapping+0x46b/0xb00 net/ipv6/ila/ila_xlat.c:368
genl_family_rcv_msg+0x8a3/0x1140 net/netlink/genetlink.c:601
genl_rcv_msg+0xc6/0x168 net/netlink/genetlink.c:626
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454
genl_rcv+0x28/0x40 net/netlink/genetlink.c:637
netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908
sock_sendmsg_nosec net/socket.c:640 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:650
___sys_sendmsg+0x7fd/0x930 net/socket.c:2133
__sys_sendmsg+0x11d/0x290 net/socket.c:2171
__do_sys_sendmsg net/socket.c:2180 [inline]
__se_sys_sendmsg net/socket.c:2178 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2178
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x441109
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 db 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffd2c44eb68 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000441109
RDX: 0000000000000000 RSI: 0000000020000040 RDI: 0000000000000003
RBP: 00000000006cc018 R08: 00000000000001
---
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: linux-next: build warning after merge of the net-next tree
From: Masahiro Yamada @ 2018-08-14 7:05 UTC (permalink / raw)
To: Guenter Roeck
Cc: Stephen Rothwell, David Miller, Networking,
Linux-Next Mailing List, Linux Kernel Mailing List, Andrew Lunn
In-Reply-To: <CAK7LNARfZH=ZEdFuRq_g1HsJ+Pv1m=v343JLyE-6+uM_d+3eWA@mail.gmail.com>
2018-07-20 8:19 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> 2018-07-20 7:35 GMT+09:00 Guenter Roeck <linux@roeck-us.net>:
>> On Fri, Jul 20, 2018 at 08:09:06AM +1000, Stephen Rothwell wrote:
>>> Hi Guenter,
>>>
>>> On Thu, 19 Jul 2018 06:49:01 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
>>> >
>>> > On 07/18/2018 10:29 PM, Stephen Rothwell wrote:
>>> > >
>>> > > On Wed, 18 Jul 2018 20:52:56 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
>>> > >>
>>> > >> On 07/18/2018 07:04 PM, Stephen Rothwell wrote:
>>> > >>>
>>> > >>> After merging the net-next tree, today's linux-next build (x86_64
>>> > >>> allmodconfig) produced this warning:
>>> > >>>
>>> > >>> *
>>> > >>> * Restart config...
>>> > >>> *
>>> > >>> ....
>>> > >>>
>>> > >>> This is output by my "make allmodconfig" and only started after merging
>>> > >>> the net-next tree today. It has continued for further merges/builds.
>>> > >>>
>>> > >>> I suspect commit
>>> > >>>
>>> > >>> 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")
>>> > >>>
>>> > >>> which added an "imply" clause.
>>> > >>>
>>> > >> I thought "imply" was better than "depends on HWMON || HWMON=n", but maybe
>>> > >> not. Is that a caveat when using "imply", and does it mean that "imply"
>>> > >> should better not be used ?
>>> > >
>>> > > I don't know, sorry. It was just my best guess from what I could see
>>> > > had changed.
>>> > >
>>> > > I wonder if it makes a difference that I am doing my "make
>>> > > allmodconfig" on top of a previous "make allmodconfig" and some symbols
>>> > > are marked as "NEW" (though they are not symbols related to the changes
>>> > > that happened during the net-next tree merge)?
>>> > >
>>> >
>>> > I tried to reproduce the problem, but I don't see the message.
>>> >
>>> > What I do see, though, is that "make allmodconfig" on a clean tree,
>>> > followed by "make menuconfig", results in configuration changes.
>>> > Specifically,
>>> >
>>> > > CONFIG_ARC_EMAC_CORE=m
>>> > > CONFIG_ARC_EMAC=m
>>> > > CONFIG_EMAC_ROCKCHIP=m
>>> >
>>> > is removed by menuconfig, and a large number of "# ... is not set"
>>> > configuration lines are added. Weird and bad, since several of the
>>> > disabled configurations _should_ be enabled by "make allmodconfig",
>>> > and a large number of hwmon drivers are affected. Bisect does point
>>> > to "net: phy: sfp: Add HWMON support for module sensors", meaning
>>> > "imply hwmon" does have severe side effects and can not be used.
>>> >
>>> > I'll try to find a fix.
>>>
>>> OK, my mistake, the "make allmodconfig" works, the following "make"
>>> causes the config restart. (I am actually doing cross builds and using
>>> an external object directory, in case that matters.)
>>>
>>> I removed the "imply HWMON" line added by the above commit and the
>>> problem went away. Also, using "depends on HWMON || HWMON=n" instead
>>> of the imply fixes it.
>>
>> Yes, replacing imply with the dependency is what I did in the fixup patch.
>> Sorry, I should have copied you: https://patchwork.kernel.org/patch/10534925/
>>
>> It is a bit different - imply was supposed to enforce HWMON={y,n} if SFP=y,
>> and the depends line enforces SFP={n,m} if HWMON=m. I have no idea why
>> imply doesn't work, but I think I'll stay away from it in the future.
>>
>> Guenter
>
>
> Hmm, this could be a Kconfig bug.
>
> I will take a look.
Today, I took a look at it.
The cause of the problem was the circular dependency.
Somehow, 'imply' is not checked in the circular dependency.
So, I wrote patches to report this.
https://patchwork.kernel.org/patch/10565061/
https://patchwork.kernel.org/patch/10565063/
If you apply those two patches on top of commit
1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")
It is reported in allmodconfig stage, like this:
masahiro@grover:~/ref/linux-next$ make allmodconfig
HOSTCC scripts/kconfig/conf.o
YACC scripts/kconfig/zconf.tab.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --allmodconfig Kconfig
drivers/of/Kconfig:68:error: recursive dependency detected!
drivers/of/Kconfig:68: symbol OF_IRQ depends on IRQ_DOMAIN
kernel/irq/Kconfig:63: symbol IRQ_DOMAIN is selected by REGMAP
drivers/base/regmap/Kconfig:6: symbol REGMAP is selected by SENSORS_ASPEED
drivers/hwmon/Kconfig:352: symbol SENSORS_ASPEED depends on HWMON
drivers/hwmon/Kconfig:5: symbol HWMON is implied by SFP
drivers/net/phy/Kconfig:214: symbol SFP depends on PHYLIB
drivers/net/phy/Kconfig:181: symbol PHYLIB is selected by ARC_EMAC_CORE
drivers/net/ethernet/arc/Kconfig:18: symbol ARC_EMAC_CORE is selected
by ARC_EMAC
drivers/net/ethernet/arc/Kconfig:24: symbol ARC_EMAC depends on OF_IRQ
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
#
# configuration written to .config
#
>
>
> BTW,
> 'depends on HWMON || HWMON=n' is pointless
> because it is always true.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH net-next 02/10] dt-bindings: net: ocelot: remove hsio from the list of register address spaces
From: Quentin Schulz @ 2018-08-14 6:49 UTC (permalink / raw)
To: Rob Herring
Cc: alexandre.belloni, ralf, paul.burton, jhogan, mark.rutland, davem,
kishon, andrew, f.fainelli, linux-mips, devicetree, linux-kernel,
netdev, allan.nielsen, thomas.petazzoni
In-Reply-To: <20180813223103.GA16669@rob-hp-laptop>
[-- Attachment #1: Type: text/plain, Size: 3549 bytes --]
Hi Rob,
On Mon, Aug 13, 2018 at 04:31:03PM -0600, Rob Herring wrote:
> On Mon, Jul 30, 2018 at 02:43:47PM +0200, Quentin Schulz wrote:
> > HSIO register address space should be handled outside of the MAC
> > controller as there are some registers for PLL5 configuring,
> > SerDes/switch port muxing and a thermal sensor IP, so let's remove it.
> >
> > Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
> > ---
> > Documentation/devicetree/bindings/mips/mscc.txt | 16 ++++++++++++-
> > Documentation/devicetree/bindings/net/mscc-ocelot.txt | 9 ++-----
> > 2 files changed, 19 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mips/mscc.txt b/Documentation/devicetree/bindings/mips/mscc.txt
> > index ae15ec3..bc817e9 100644
> > --- a/Documentation/devicetree/bindings/mips/mscc.txt
> > +++ b/Documentation/devicetree/bindings/mips/mscc.txt
> > @@ -41,3 +41,19 @@ Example:
> > compatible = "mscc,ocelot-cpu-syscon", "syscon";
> > reg = <0x70000000 0x2c>;
> > };
> > +
> > +o HSIO regs:
> > +
> > +The SoC has a few registers (HSIO) handling miscellaneous functionalities:
> > +configuration and status of PLL5, RCOMP, SyncE, SerDes configurations and
> > +status, SerDes muxing and a thermal sensor.
> > +
> > +Required properties:
> > +- compatible: Should be "mscc,ocelot-hsio", "syscon", "simple-mfd"
> > +- reg : Should contain registers location and length
> > +
> > +Example:
> > + syscon@10d0000 {
> > + compatible = "mscc,ocelot-hsio", "syscon", "simple-mfd";
>
> simple-mfd is not appropriate without child nodes, so drop it.
>
Understood but it's an intermediate patch. Later (patch 8), the SerDes
muxing "controller" is added as a child to this node. There most likely
will be some others in the future (temperature sensor for example).
Furthermore, there's already a simple-mfd without children in this file:
https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/mips/mscc.txt#L19
How should we handle this case?
Thanks,
Quentin
> > + reg = <0x10d0000 0x10000>;
> > + };
> > diff --git a/Documentation/devicetree/bindings/net/mscc-ocelot.txt b/Documentation/devicetree/bindings/net/mscc-ocelot.txt
> > index 0a84711..9e5c17d 100644
> > --- a/Documentation/devicetree/bindings/net/mscc-ocelot.txt
> > +++ b/Documentation/devicetree/bindings/net/mscc-ocelot.txt
> > @@ -12,7 +12,6 @@ Required properties:
> > - "sys"
> > - "rew"
> > - "qs"
> > - - "hsio"
> > - "qsys"
> > - "ana"
> > - "portX" with X from 0 to the number of last port index available on that
> > @@ -45,7 +44,6 @@ Example:
> > reg = <0x1010000 0x10000>,
> > <0x1030000 0x10000>,
> > <0x1080000 0x100>,
> > - <0x10d0000 0x10000>,
> > <0x11e0000 0x100>,
> > <0x11f0000 0x100>,
> > <0x1200000 0x100>,
> > @@ -59,10 +57,9 @@ Example:
> > <0x1280000 0x100>,
> > <0x1800000 0x80000>,
> > <0x1880000 0x10000>;
> > - reg-names = "sys", "rew", "qs", "hsio", "port0",
> > - "port1", "port2", "port3", "port4", "port5",
> > - "port6", "port7", "port8", "port9", "port10",
> > - "qsys", "ana";
> > + reg-names = "sys", "rew", "qs", "port0", "port1", "port2",
> > + "port3", "port4", "port5", "port6", "port7",
> > + "port8", "port9", "port10", "qsys", "ana";
> > interrupts = <21 22>;
> > interrupt-names = "xtr", "inj";
> >
> > --
> > git-series 0.9.1
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] net: systemport: fix unused function warning
From: David Miller @ 2018-08-14 3:46 UTC (permalink / raw)
To: arnd
Cc: f.fainelli, talgi, alexander.h.duyck, jeffrey.t.kirsher, netdev,
linux-kernel
In-Reply-To: <20180813221041.219857-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 14 Aug 2018 00:10:34 +0200
> The only remaining caller of this function is inside of an #ifdef
> after another caller got removed. This causes a harmless warning
> in some configurations:
>
> drivers/net/ethernet/broadcom/bcmsysport.c:1068:13: error: 'bcm_sysport_resume_from_wol' defined but not used [-Werror=unused-function]
>
> Removing the #ifdef around the PM functions simplifies the code
> and avoids the problem but letting the compiler drop the unused
> functions silently.
>
> Fixes: 9e85e22713d6 ("net: systemport: Do not re-configure upon WoL interrupt")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* Re: [PATCH] net: stmmac: mark PM functions as __maybe_unused
From: David Miller @ 2018-08-14 3:46 UTC (permalink / raw)
To: arnd; +Cc: peppe.cavallaro, alexandre.torgue, joabreu, netdev, linux-kernel
In-Reply-To: <20180813215046.3663828-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 13 Aug 2018 23:50:41 +0200
> The newly added suspend/resume functions cause a build warning
> when CONFIG_PM is disabled:
>
> drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:324:12: error: 'stmmac_pci_resume' defined but not used [-Werror=unused-function]
> drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:306:12: error: 'stmmac_pci_suspend' defined but not used [-Werror=unused-function]
>
> Mark them as __maybe_unused so gcc can drop them silently.
>
> Fixes: b7d0f08e9129 ("net: stmmac: Fix WoL for PCI-based setups")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] net: lan743x: select CRC16
From: David Miller @ 2018-08-14 3:44 UTC (permalink / raw)
To: arnd; +Cc: Bryan.Whitehead, andrew, netdev, linux-kernel
In-Reply-To: <20180813211938.2375199-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 13 Aug 2018 23:19:21 +0200
> lan743x now fails to build when CONFIG_CRC16 is disabled:
>
> drivers/net/ethernet/microchip/lan743x_main.o: In function crc16'
>
> Force it on like all other users do.
>
> Fixes: 4d94282afd95 ("lan743x: Add power management support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* possible deadlock in rhashtable_lookup_insert_fast
From: syzbot @ 2018-08-14 6:20 UTC (permalink / raw)
To: davem, gregkh, keescook, ktkhai, kuznet, linux-kernel, netdev,
pombredanne, stephen, syzkaller-bugs, tom, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 36d2f761b5aa cxgb4: update 1.20.8.0 as the latest firmware..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=134b323c400000
kernel config: https://syzkaller.appspot.com/x/.config?x=dbf55ebfa6bfd517
dashboard link: https://syzkaller.appspot.com/bug?extid=b66a5a554991a8ed027c
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=103285f0400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12859d72400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+b66a5a554991a8ed027c@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
netlink: 'syz-executor077': attribute type 8 has an invalid length.
============================================
WARNING: possible recursive locking detected
4.18.0-rc8+ #179 Not tainted
--------------------------------------------
syz-executor077/4391 is trying to acquire lock:
(____ptrval____) (&(&tlocks[i])->rlock){+.+.}, at: spin_lock_bh
include/linux/spinlock.h:315 [inline]
(____ptrval____) (&(&tlocks[i])->rlock){+.+.}, at: __rhashtable_insert_fast
include/linux/rhashtable.h:596 [inline]
(____ptrval____) (&(&tlocks[i])->rlock){+.+.}, at:
rhashtable_lookup_insert_fast.constprop.26+0x436/0x13a0
include/linux/rhashtable.h:784
but task is already holding lock:
(____ptrval____) (&(&tlocks[i])->rlock){+.+.}, at: spin_lock
include/linux/spinlock.h:310 [inline]
(____ptrval____) (&(&tlocks[i])->rlock){+.+.}, at: ila_add_mapping
net/ipv6/ila/ila_xlat.c:233 [inline]
(____ptrval____) (&(&tlocks[i])->rlock){+.+.}, at:
ila_xlat_nl_cmd_add_mapping+0x6bb/0x17e0 net/ipv6/ila/ila_xlat.c:355
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&tlocks[i])->rlock);
lock(&(&tlocks[i])->rlock);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by syz-executor077/4391:
#0: (____ptrval____) (cb_lock){++++}, at: genl_rcv+0x19/0x40
net/netlink/genetlink.c:636
#1: (____ptrval____) (&(&tlocks[i])->rlock){+.+.}, at: spin_lock
include/linux/spinlock.h:310 [inline]
#1: (____ptrval____) (&(&tlocks[i])->rlock){+.+.}, at: ila_add_mapping
net/ipv6/ila/ila_xlat.c:233 [inline]
#1: (____ptrval____) (&(&tlocks[i])->rlock){+.+.}, at:
ila_xlat_nl_cmd_add_mapping+0x6bb/0x17e0 net/ipv6/ila/ila_xlat.c:355
#2: (____ptrval____) (rcu_read_lock){....}, at: __rhashtable_insert_fast
include/linux/rhashtable.h:579 [inline]
#2: (____ptrval____) (rcu_read_lock){....}, at:
rhashtable_lookup_insert_fast.constprop.26+0x1d7/0x13a0
include/linux/rhashtable.h:784
stack backtrace:
CPU: 1 PID: 4391 Comm: syz-executor077 Not tainted 4.18.0-rc8+ #179
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+0x1c9/0x2b4 lib/dump_stack.c:113
print_deadlock_bug kernel/locking/lockdep.c:1765 [inline]
check_deadlock kernel/locking/lockdep.c:1809 [inline]
validate_chain kernel/locking/lockdep.c:2405 [inline]
__lock_acquire.cold.65+0x1fb/0x486 kernel/locking/lockdep.c:3435
lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
_raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168
spin_lock_bh include/linux/spinlock.h:315 [inline]
__rhashtable_insert_fast include/linux/rhashtable.h:596 [inline]
rhashtable_lookup_insert_fast.constprop.26+0x436/0x13a0
include/linux/rhashtable.h:784
ila_add_mapping net/ipv6/ila/ila_xlat.c:240 [inline]
ila_xlat_nl_cmd_add_mapping+0xafe/0x17e0 net/ipv6/ila/ila_xlat.c:355
genl_family_rcv_msg+0x8a3/0x1140 net/netlink/genetlink.c:601
genl_rcv_msg+0xc6/0x168 net/netlink/genetlink.c:626
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454
genl_rcv+0x28/0x40 net/netlink/genetlink.c:637
netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908
sock_sendmsg_nosec net/socket.c:640 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:650
___sys_sendmsg+0x7fd/0x930 net/socket.c:2133
__sys_sendmsg+0x11d/0x290 net/socket.c:2171
__do_sys_sendmsg net/socket.c:2180 [inline]
__se_sys_sendmsg net/socket.c:2178 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2178
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4400e9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffd14495758 EFLAG
---
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
* [PATCH v2 iproute2-next] Add SKB Priority qdisc support in tc(8)
From: Nishanth Devarajan @ 2018-08-14 2:57 UTC (permalink / raw)
To: dsahern; +Cc: netdev, doucette, michel
sch_skbprio is a qdisc that prioritizes packets according to their skb->priority
field. Under congestion, it drops already-enqueued lower priority packets to
make space available for higher priority packets. Skbprio was conceived as a
solution for denial-of-service defenses that need to route packets with
different priorities as a means to overcome DoS attacks.
Signed-off-by: Nishanth Devarajan <ndev2021@gmail.com>
Reviewed-by: Michel Machado <michel@digirati.com.br>
---
v2
*Patch applies cleanly, fixes for proper code indentation.
---
man/man8/tc-skbprio.8 | 70 ++++++++++++++++++++++++++++++++++++++++++
tc/Makefile | 1 +
tc/q_skbprio.c | 84 +++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 155 insertions(+)
create mode 100644 man/man8/tc-skbprio.8
create mode 100644 tc/q_skbprio.c
diff --git a/man/man8/tc-skbprio.8 b/man/man8/tc-skbprio.8
new file mode 100644
index 0000000..844bbf4
--- /dev/null
+++ b/man/man8/tc-skbprio.8
@@ -0,0 +1,70 @@
+.TH SKBPRIO 8 "13 August 2018" "iproute2" "Linux"
+.SH NAME
+skbprio \- SKB Priority Queue
+
+.SH SYNOPSIS
+.B tc qdisc ... add skbprio
+.B [ limit
+packets
+.B ]
+
+.SH DESCRIPTION
+SKB Priority Queue is a queueing discipline intended to prioritize
+the most important packets during a denial-of-service (
+.B DoS
+) attack. The priority of a packet is given by
+.B skb->priority
+, where a higher value places the packet closer to the exit of the queue. When
+the queue is full, the lowest priority packet in the queue is dropped to make
+room for the packet to be added if it has higher priority. If the packet to be
+added has lower priority than all packets in the queue, it is dropped.
+
+Without SKB priority queue, queue length limits must be imposed
+on individual sub-queues, and there is no straightforward way to enforce
+a global queue length limit across all priorities. SKBprio queue enforces
+a global queue length limit while not restricting the lengths of
+individual sub-queues.
+
+While SKB Priority Queue is agnostic to how
+.B skb->priority
+is assigned. A typical use case is to copy
+the 6-bit DS field of IPv4 and IPv6 packets using
+.BR tc-skbedit (8)
+. If
+.B skb->priority
+is greater or equal to 64, the priority is assumed to be 63.
+Priorities less than 64 are taken at face value.
+
+SKB Priority Queue enables routers to locally decide which
+packets to drop under a DoS attack.
+Priorities should be assigned to packets such that the higher the priority,
+the more expected behavior a source shows.
+So sources have an incentive to play by the rules.
+
+.SH ALGORITHM
+
+Skbprio maintains 64 lists (priorities go from 0 to 63).
+When a packet is enqueued, it gets inserted at the
+.B tail
+of its priority list. When a packet needs to be sent out to the network, it is
+taken from the head of the highest priority list. When the queue is full,
+the packet at the tail of the lowest priority list is dropped to serve the
+ingress packet - if it is of higher priority, otherwise the ingress packet is
+dropped. This algorithm allocates as much bandwidth as possible to high
+priority packets, while only servicing low priority packets when
+there is enough bandwidth.
+
+.SH PARAMETERS
+.TP
+limit
+Maximum queue size specified in packets. It defaults to 64.
+The range for this parameter is [0, UINT32_MAX].
+
+.SH SEE ALSO
+.BR tc-prio (8),
+.BR tc-skbedit (8)
+
+.SH AUTHORS
+Nishanth Devarajan <devarajn@uci.edu>, Michel Machado <michel@digirati.com.br>
+
+This manpage maintained by Bert Hubert <ahu@ds9a.nl>
diff --git a/tc/Makefile b/tc/Makefile
index 36cde2f..5a1a7ff 100644
--- a/tc/Makefile
+++ b/tc/Makefile
@@ -12,6 +12,7 @@ TCMODULES += q_fifo.o
TCMODULES += q_sfq.o
TCMODULES += q_red.o
TCMODULES += q_prio.o
+TCMODULES += q_skbprio.o
TCMODULES += q_tbf.o
TCMODULES += q_cbq.o
TCMODULES += q_rr.o
diff --git a/tc/q_skbprio.c b/tc/q_skbprio.c
new file mode 100644
index 0000000..2b6d78f
--- /dev/null
+++ b/tc/q_skbprio.c
@@ -0,0 +1,84 @@
+/*
+ * q_skbprio.c SKB PRIORITY QUEUE.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Authors: Nishanth Devarajan, <ndev2021@gmail.com>
+ *
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <syslog.h>
+#include <fcntl.h>
+#include <sys/socket.h>
+#include <netinet/in.h>
+#include <arpa/inet.h>
+#include <string.h>
+
+#include "utils.h"
+#include "tc_util.h"
+
+static void explain(void)
+{
+ fprintf(stderr, "Usage: ... <skbprio> [ limit NUMBER ]\n");
+}
+
+static int skbprio_parse_opt(struct qdisc_util *qu, int argc, char **argv,
+ struct nlmsghdr *n, const char *dev)
+{
+ int ok = 0;
+ struct tc_skbprio_qopt opt = {};
+
+ while (argc > 0) {
+ if (strcmp(*argv, "limit") == 0) {
+ NEXT_ARG();
+ if (get_size(&opt.limit, *argv)) {
+ fprintf(stderr,
+ "%s: Illegal \"limit\" value:\"%s\"\n",
+ qu->id, *argv);
+ return -1;
+ }
+ ok++;
+ }
+ else if (strcmp(*argv, "help") == 0) {
+ explain();
+ return -1;
+ } else {
+ fprintf(stderr,
+ "%s: unknown parameter \"%s\"\n",
+ qu->id, *argv);
+ explain();
+ return -1;
+ }
+ argc--; argv++;
+ }
+
+ if (ok)
+ addattr_l(n, 1024, TCA_OPTIONS, &opt, sizeof(opt));
+ return 0;
+}
+
+static int skbprio_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
+{
+ struct tc_skbprio_qopt *qopt;
+
+ if (opt == NULL)
+ return 0;
+
+ if (RTA_PAYLOAD(opt) < sizeof(*qopt))
+ return -1;
+ qopt = RTA_DATA(opt);
+ fprintf(f, "limit %u ", qopt->limit);
+ return 0;
+}
+
+struct qdisc_util skbprio_qdisc_util = {
+ .id = "skbprio",
+ .parse_qopt = skbprio_parse_opt,
+ .print_qopt = skbprio_print_opt,
+};
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net 0/2] net_sched: Fix two tc_index filter init issues
From: David Miller @ 2018-08-14 2:40 UTC (permalink / raw)
To: liuhangbin; +Cc: netdev, xiyou.wangcong
In-Reply-To: <1534157044-19753-1-git-send-email-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Mon, 13 Aug 2018 18:44:02 +0800
> These two patches fix two tc_index filter init issues. The first one fixes
> missing exts info in new filter, which will cause NULL pointer dereference
> when delete tcindex filter. The second one fixes missing res info when create
> new filter, which will make filter unbind failed.
Series applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] nfp: clean up return types in kdoc comments
From: David Miller @ 2018-08-14 2:36 UTC (permalink / raw)
To: jakub.kicinski; +Cc: netdev
In-Reply-To: <20180814013105.19180-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Mon, 13 Aug 2018 18:31:05 -0700
> Remove 'Return:' information from functions which no longer
> return a value. Also update name and return types of nfp_nffw_info
> access functions.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Applied, thanks Jakub.
^ 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