* [PATCH v1 2/4] crypto:chcr- Fix panic on dma_unmap_sg
From: Harsh Jain @ 2017-01-13 12:29 UTC (permalink / raw)
To: hariprasad, netdev, herbert, linux-crypto; +Cc: Harsh Jain, Atul Gupta
In-Reply-To: <cover.1484309965.git.harsh@chelsio.com>
Save DMA mapped sg list addresses to request context buffer.
Signed-off-by: Atul Gupta <atul.gupta@chelsio.com>
---
drivers/crypto/chelsio/chcr_algo.c | 49 +++++++++++++++++++-----------------
drivers/crypto/chelsio/chcr_crypto.h | 3 +++
2 files changed, 29 insertions(+), 23 deletions(-)
diff --git a/drivers/crypto/chelsio/chcr_algo.c b/drivers/crypto/chelsio/chcr_algo.c
index 1d7dfcf..deec7c0 100644
--- a/drivers/crypto/chelsio/chcr_algo.c
+++ b/drivers/crypto/chelsio/chcr_algo.c
@@ -158,7 +158,7 @@ int chcr_handle_resp(struct crypto_async_request *req, unsigned char *input,
case CRYPTO_ALG_TYPE_AEAD:
ctx_req.req.aead_req = (struct aead_request *)req;
ctx_req.ctx.reqctx = aead_request_ctx(ctx_req.req.aead_req);
- dma_unmap_sg(&u_ctx->lldi.pdev->dev, ctx_req.req.aead_req->dst,
+ dma_unmap_sg(&u_ctx->lldi.pdev->dev, ctx_req.ctx.reqctx->dst,
ctx_req.ctx.reqctx->dst_nents, DMA_FROM_DEVICE);
if (ctx_req.ctx.reqctx->skb) {
kfree_skb(ctx_req.ctx.reqctx->skb);
@@ -1364,8 +1364,7 @@ static struct sk_buff *create_authenc_wr(struct aead_request *req,
struct chcr_wr *chcr_req;
struct cpl_rx_phys_dsgl *phys_cpl;
struct phys_sge_parm sg_param;
- struct scatterlist *src, *dst;
- struct scatterlist src_sg[2], dst_sg[2];
+ struct scatterlist *src;
unsigned int frags = 0, transhdr_len;
unsigned int ivsize = crypto_aead_ivsize(tfm), dst_size = 0;
unsigned int kctx_len = 0;
@@ -1385,19 +1384,21 @@ static struct sk_buff *create_authenc_wr(struct aead_request *req,
if (sg_nents_for_len(req->src, req->assoclen + req->cryptlen) < 0)
goto err;
- src = scatterwalk_ffwd(src_sg, req->src, req->assoclen);
- dst = src;
+ src = scatterwalk_ffwd(reqctx->srcffwd, req->src, req->assoclen);
+ reqctx->dst = src;
+
if (req->src != req->dst) {
err = chcr_copy_assoc(req, aeadctx);
if (err)
return ERR_PTR(err);
- dst = scatterwalk_ffwd(dst_sg, req->dst, req->assoclen);
+ reqctx->dst = scatterwalk_ffwd(reqctx->dstffwd, req->dst,
+ req->assoclen);
}
if (get_aead_subtype(tfm) == CRYPTO_ALG_SUB_TYPE_AEAD_NULL) {
null = 1;
assoclen = 0;
}
- reqctx->dst_nents = sg_nents_for_len(dst, req->cryptlen +
+ reqctx->dst_nents = sg_nents_for_len(reqctx->dst, req->cryptlen +
(op_type ? -authsize : authsize));
if (reqctx->dst_nents <= 0) {
pr_err("AUTHENC:Invalid Destination sg entries\n");
@@ -1462,7 +1463,7 @@ static struct sk_buff *create_authenc_wr(struct aead_request *req,
sg_param.obsize = req->cryptlen + (op_type ? -authsize : authsize);
sg_param.qid = qid;
sg_param.align = 0;
- if (map_writesg_phys_cpl(&u_ctx->lldi.pdev->dev, phys_cpl, dst,
+ if (map_writesg_phys_cpl(&u_ctx->lldi.pdev->dev, phys_cpl, reqctx->dst,
&sg_param))
goto dstmap_fail;
@@ -1713,8 +1714,7 @@ static struct sk_buff *create_aead_ccm_wr(struct aead_request *req,
struct chcr_wr *chcr_req;
struct cpl_rx_phys_dsgl *phys_cpl;
struct phys_sge_parm sg_param;
- struct scatterlist *src, *dst;
- struct scatterlist src_sg[2], dst_sg[2];
+ struct scatterlist *src;
unsigned int frags = 0, transhdr_len, ivsize = AES_BLOCK_SIZE;
unsigned int dst_size = 0, kctx_len;
unsigned int sub_type;
@@ -1730,17 +1730,19 @@ static struct sk_buff *create_aead_ccm_wr(struct aead_request *req,
if (sg_nents_for_len(req->src, req->assoclen + req->cryptlen) < 0)
goto err;
sub_type = get_aead_subtype(tfm);
- src = scatterwalk_ffwd(src_sg, req->src, req->assoclen);
- dst = src;
+ src = scatterwalk_ffwd(reqctx->srcffwd, req->src, req->assoclen);
+ reqctx->dst = src;
+
if (req->src != req->dst) {
err = chcr_copy_assoc(req, aeadctx);
if (err) {
pr_err("AAD copy to destination buffer fails\n");
return ERR_PTR(err);
}
- dst = scatterwalk_ffwd(dst_sg, req->dst, req->assoclen);
+ reqctx->dst = scatterwalk_ffwd(reqctx->dstffwd, req->dst,
+ req->assoclen);
}
- reqctx->dst_nents = sg_nents_for_len(dst, req->cryptlen +
+ reqctx->dst_nents = sg_nents_for_len(reqctx->dst, req->cryptlen +
(op_type ? -authsize : authsize));
if (reqctx->dst_nents <= 0) {
pr_err("CCM:Invalid Destination sg entries\n");
@@ -1779,7 +1781,7 @@ static struct sk_buff *create_aead_ccm_wr(struct aead_request *req,
sg_param.obsize = req->cryptlen + (op_type ? -authsize : authsize);
sg_param.qid = qid;
sg_param.align = 0;
- if (map_writesg_phys_cpl(&u_ctx->lldi.pdev->dev, phys_cpl, dst,
+ if (map_writesg_phys_cpl(&u_ctx->lldi.pdev->dev, phys_cpl, reqctx->dst,
&sg_param))
goto dstmap_fail;
@@ -1811,8 +1813,7 @@ static struct sk_buff *create_gcm_wr(struct aead_request *req,
struct chcr_wr *chcr_req;
struct cpl_rx_phys_dsgl *phys_cpl;
struct phys_sge_parm sg_param;
- struct scatterlist *src, *dst;
- struct scatterlist src_sg[2], dst_sg[2];
+ struct scatterlist *src;
unsigned int frags = 0, transhdr_len;
unsigned int ivsize = AES_BLOCK_SIZE;
unsigned int dst_size = 0, kctx_len;
@@ -1834,13 +1835,14 @@ static struct sk_buff *create_gcm_wr(struct aead_request *req,
if (sg_nents_for_len(req->src, req->assoclen + req->cryptlen) < 0)
goto err;
- src = scatterwalk_ffwd(src_sg, req->src, req->assoclen);
- dst = src;
+ src = scatterwalk_ffwd(reqctx->srcffwd, req->src, req->assoclen);
+ reqctx->dst = src;
if (req->src != req->dst) {
err = chcr_copy_assoc(req, aeadctx);
if (err)
return ERR_PTR(err);
- dst = scatterwalk_ffwd(dst_sg, req->dst, req->assoclen);
+ reqctx->dst = scatterwalk_ffwd(reqctx->dstffwd, req->dst,
+ req->assoclen);
}
if (!req->cryptlen)
@@ -1850,7 +1852,7 @@ static struct sk_buff *create_gcm_wr(struct aead_request *req,
crypt_len = AES_BLOCK_SIZE;
else
crypt_len = req->cryptlen;
- reqctx->dst_nents = sg_nents_for_len(dst, req->cryptlen +
+ reqctx->dst_nents = sg_nents_for_len(reqctx->dst, req->cryptlen +
(op_type ? -authsize : authsize));
if (reqctx->dst_nents <= 0) {
pr_err("GCM:Invalid Destination sg entries\n");
@@ -1925,7 +1927,7 @@ static struct sk_buff *create_gcm_wr(struct aead_request *req,
sg_param.obsize = req->cryptlen + (op_type ? -authsize : authsize);
sg_param.qid = qid;
sg_param.align = 0;
- if (map_writesg_phys_cpl(&u_ctx->lldi.pdev->dev, phys_cpl, dst,
+ if (map_writesg_phys_cpl(&u_ctx->lldi.pdev->dev, phys_cpl, reqctx->dst,
&sg_param))
goto dstmap_fail;
@@ -1939,7 +1941,8 @@ static struct sk_buff *create_gcm_wr(struct aead_request *req,
write_sg_to_skb(skb, &frags, src, req->cryptlen);
} else {
aes_gcm_empty_pld_pad(req->dst, authsize - 1);
- write_sg_to_skb(skb, &frags, dst, crypt_len);
+ write_sg_to_skb(skb, &frags, reqctx->dst, crypt_len);
+
}
create_wreq(ctx, chcr_req, req, skb, kctx_len, size, 1,
diff --git a/drivers/crypto/chelsio/chcr_crypto.h b/drivers/crypto/chelsio/chcr_crypto.h
index d5af7d6..7ec0a8f 100644
--- a/drivers/crypto/chelsio/chcr_crypto.h
+++ b/drivers/crypto/chelsio/chcr_crypto.h
@@ -158,6 +158,9 @@ struct ablk_ctx {
};
struct chcr_aead_reqctx {
struct sk_buff *skb;
+ struct scatterlist *dst;
+ struct scatterlist srcffwd[2];
+ struct scatterlist dstffwd[2];
short int dst_nents;
u16 verify;
u8 iv[CHCR_MAX_CRYPTO_IV_LEN];
--
1.8.2.3
^ permalink raw reply related
* [PATCH v1 4/4] crypto:chcr-fix itnull.cocci warnings
From: Harsh Jain @ 2017-01-13 12:29 UTC (permalink / raw)
To: hariprasad, netdev, herbert, linux-crypto
Cc: Harsh Jain, Julia Lawall, Fengguang Wu
In-Reply-To: <cover.1484309965.git.harsh@chelsio.com>
The first argument to list_for_each_entry cannot be NULL.
Generated by: scripts/coccinelle/iterators/itnull.cocci
Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Harsh Jain <harsh@chelsio.com>
---
drivers/crypto/chelsio/chcr_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/chelsio/chcr_core.c b/drivers/crypto/chelsio/chcr_core.c
index 1c65f07..2bfd61a 100644
--- a/drivers/crypto/chelsio/chcr_core.c
+++ b/drivers/crypto/chelsio/chcr_core.c
@@ -61,7 +61,7 @@ int assign_chcr_device(struct chcr_dev **dev)
*/
mutex_lock(&dev_mutex); /* TODO ? */
list_for_each_entry(u_ctx, &uld_ctx_list, entry)
- if (u_ctx && u_ctx->dev) {
+ if (u_ctx->dev) {
*dev = u_ctx->dev;
ret = 0;
break;
--
1.8.2.3
^ permalink raw reply related
* [PATCH net] ravb: do not use zero-length alighment DMA request
From: Simon Horman @ 2017-01-13 13:09 UTC (permalink / raw)
To: David Miller, Sergei Shtylyov
Cc: Magnus Damm, netdev, linux-renesas-soc, Masaru Nagai,
Simon Horman
From: Masaru Nagai <masaru.nagai.vx@renesas.com>
Due to alignment requirements of the hardware transmissions are split into
two DMA descriptors, a small padding descriptor of 0 - 3 bytes in length
followed by a descriptor for rest of the packet.
In the case of IP packets the first descriptor will never be zero due to
the way that the stack aligns buffers for IP packets. However, for non-IP
packets it may be zero.
In that case it has been reported that timeouts occur, presumably because
transmission stops at the first zero-length DMA descriptor and thus the
packet is not transmitted. However, in my environment a BUG is triggered as
follows:
[ 20.381417] ------------[ cut here ]------------
[ 20.386054] kernel BUG at lib/swiotlb.c:495!
[ 20.390324] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 20.395805] Modules linked in:
[ 20.398862] CPU: 0 PID: 2089 Comm: mz Not tainted 4.10.0-rc3-00001-gf13ad2db193f #162
[ 20.406689] Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
[ 20.413474] task: ffff80063b1f1900 task.stack: ffff80063a71c000
[ 20.419404] PC is at swiotlb_tbl_map_single+0x178/0x2ec
[ 20.424625] LR is at map_single+0x4c/0x98
[ 20.428629] pc : [<ffff00000839c4c0>] lr : [<ffff00000839c680>] pstate: 800001c5
[ 20.436019] sp : ffff80063a71f9b0
[ 20.439327] x29: ffff80063a71f9b0 x28: ffff80063a20d500
[ 20.444636] x27: ffff000008ed5000 x26: 0000000000000000
[ 20.449944] x25: 000000067abe2adc x24: 0000000000000000
[ 20.455252] x23: 0000000000200000 x22: 0000000000000001
[ 20.460559] x21: 0000000000175ffe x20: ffff80063b2a0010
[ 20.465866] x19: 0000000000000000 x18: 0000ffffcae6fb20
[ 20.471173] x17: 0000ffffa09ba018 x16: ffff0000087c8b70
[ 20.476480] x15: 0000ffffa084f588 x14: 0000ffffa09cfa14
[ 20.481787] x13: 0000ffffcae87ff0 x12: 000000000063abe2
[ 20.487098] x11: ffff000008096360 x10: ffff80063abe2adc
[ 20.492407] x9 : 0000000000000000 x8 : 0000000000000000
[ 20.497718] x7 : 0000000000000000 x6 : ffff000008ed50d0
[ 20.503028] x5 : 0000000000000000 x4 : 0000000000000001
[ 20.508338] x3 : 0000000000000000 x2 : 000000067abe2adc
[ 20.513648] x1 : 00000000bafff000 x0 : 0000000000000000
[ 20.518958]
[ 20.520446] Process mz (pid: 2089, stack limit = 0xffff80063a71c000)
[ 20.526798] Stack: (0xffff80063a71f9b0 to 0xffff80063a720000)
[ 20.532543] f9a0: ffff80063a71fa30 ffff00000839c680
[ 20.540374] f9c0: ffff80063b2a0010 ffff80063b2a0010 0000000000000001 0000000000000000
[ 20.548204] f9e0: 000000000000006e ffff80063b23c000 ffff80063b23c000 0000000000000000
[ 20.556034] fa00: ffff80063b23c000 ffff80063a20d500 000000013b1f1900 0000000000000000
[ 20.563864] fa20: ffff80063ffd18e0 ffff80063b2a0010 ffff80063a71fa60 ffff00000839cd10
[ 20.571694] fa40: ffff80063b2a0010 0000000000000000 ffff80063ffd18e0 000000067abe2adc
[ 20.579524] fa60: ffff80063a71fa90 ffff000008096380 ffff80063b2a0010 0000000000000000
[ 20.587353] fa80: 0000000000000000 0000000000000001 ffff80063a71fac0 ffff00000864f770
[ 20.595184] faa0: ffff80063b23caf0 0000000000000000 0000000000000000 0000000000000140
[ 20.603014] fac0: ffff80063a71fb60 ffff0000087e6498 ffff80063a20d500 ffff80063b23c000
[ 20.610843] fae0: 0000000000000000 ffff000008daeaf0 0000000000000000 ffff000008daeb00
[ 20.618673] fb00: ffff80063a71fc0c ffff000008da7000 ffff80063b23c090 ffff80063a44f000
[ 20.626503] fb20: 0000000000000000 ffff000008daeb00 ffff80063a71fc0c ffff000008da7000
[ 20.634333] fb40: ffff80063b23c090 0000000000000000 ffff800600000037 ffff0000087e63d8
[ 20.642163] fb60: ffff80063a71fbc0 ffff000008807510 ffff80063a692400 ffff80063a20d500
[ 20.649993] fb80: ffff80063a44f000 ffff80063b23c000 ffff80063a69249c 0000000000000000
[ 20.657823] fba0: 0000000000000000 ffff80063a087800 ffff80063b23c000 ffff80063a20d500
[ 20.665653] fbc0: ffff80063a71fc10 ffff0000087e67dc ffff80063a20d500 ffff80063a692400
[ 20.673483] fbe0: ffff80063b23c000 0000000000000000 ffff80063a44f000 ffff80063a69249c
[ 20.681312] fc00: ffff80063a5f1a10 000000103a087800 ffff80063a71fc70 ffff0000087e6b24
[ 20.689142] fc20: ffff80063a5f1a80 ffff80063a71fde8 000000000000000f 00000000000005ea
[ 20.696972] fc40: ffff80063a5f1a10 0000000000000000 000000000000000f ffff00000887fbd0
[ 20.704802] fc60: fffffff43a5f1a80 0000000000000000 ffff80063a71fc80 ffff000008880240
[ 20.712632] fc80: ffff80063a71fd90 ffff0000087c7a34 ffff80063afc7180 0000000000000000
[ 20.720462] fca0: 0000ffffcae6fe18 0000000000000014 0000000060000000 0000000000000015
[ 20.728292] fcc0: 0000000000000123 00000000000000ce ffff0000088d2000 ffff80063b1f1900
[ 20.736122] fce0: 0000000000008933 ffff000008e7cb80 ffff80063a71fd80 ffff0000087c50a4
[ 20.743951] fd00: 0000000000008933 ffff000008e7cb80 ffff000008e7cb80 000000100000000e
[ 20.751781] fd20: ffff80063a71fe4c 0000ffff00000300 0000000000000123 0000000000000000
[ 20.759611] fd40: 0000000000000000 ffff80063b1f0000 000000000000000e 0000000000000300
[ 20.767441] fd60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 20.775271] fd80: 0000000000000000 0000000000000000 ffff80063a71fda0 ffff0000087c8c20
[ 20.783100] fda0: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
[ 20.790930] fdc0: ffffffffffffffff 0000ffffa0903078 0000000000000000 000000001ea87232
[ 20.798760] fde0: 000000000000000f ffff80063a71fe40 ffff800600000014 ffff000000000001
[ 20.806590] fe00: 0000000000000000 0000000000000000 ffff80063a71fde8 0000000000000000
[ 20.814420] fe20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
[ 20.822249] fe40: 0000000203000011 0000000000000000 0000000000000000 ffff80063a68aa00
[ 20.830079] fe60: ffff80063a68aa00 0000000000000003 0000000000008933 ffff0000081f1b9c
[ 20.837909] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
[ 20.845739] fea0: ffffffffffffffff 0000ffffa07ca81c 0000000060000000 0000000000000015
[ 20.853569] fec0: 0000000000000003 000000001ea87232 000000000000000f 0000000000000000
[ 20.861399] fee0: 0000ffffcae6fe18 0000000000000014 0000000000000300 0000000000000000
[ 20.869228] ff00: 00000000000000ce 0000000000000000 00000000ffffffff 0000000000000000
[ 20.877059] ff20: 0000000000000002 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
[ 20.884888] ff40: 0000000000000000 0000ffffa09ba018 0000ffffcae6fb20 000000001ea87010
[ 20.892718] ff60: 0000ffffa09b9000 0000ffffcae6fe30 0000ffffcae6fe18 000000000000000f
[ 20.900548] ff80: 0000000000000003 000000001ea87232 0000000000000000 0000000000000000
[ 20.908378] ffa0: 0000000000000000 0000ffffcae6fdc0 0000ffffa09a7824 0000ffffcae6fdc0
[ 20.916208] ffc0: 0000ffffa0903078 0000000060000000 0000000000000003 00000000000000ce
[ 20.924038] ffe0: 0000000000000000 0000000000000000 ffffffffffffffff ffffffffffffffff
[ 20.931867] Call trace:
[ 20.934312] Exception stack(0xffff80063a71f7e0 to 0xffff80063a71f910)
[ 20.940750] f7e0: 0000000000000000 0001000000000000 ffff80063a71f9b0 ffff00000839c4c0
[ 20.948580] f800: ffff80063a71f840 ffff00000888a6e4 ffff80063a24c418 ffff80063a24c448
[ 20.956410] f820: 0000000000000000 ffff00000811cd54 ffff80063a71f860 ffff80063a24c458
[ 20.964240] f840: ffff80063a71f870 ffff00000888b258 ffff80063a24c418 0000000000000001
[ 20.972070] f860: ffff80063a71f910 ffff80063a7b7028 ffff80063a71f890 ffff0000088825e4
[ 20.979899] f880: 0000000000000000 00000000bafff000 000000067abe2adc 0000000000000000
[ 20.987729] f8a0: 0000000000000001 0000000000000000 ffff000008ed50d0 0000000000000000
[ 20.995560] f8c0: 0000000000000000 0000000000000000 ffff80063abe2adc ffff000008096360
[ 21.003390] f8e0: 000000000063abe2 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
[ 21.011219] f900: ffff0000087c8b70 0000ffffa09ba018
[ 21.016097] [<ffff00000839c4c0>] swiotlb_tbl_map_single+0x178/0x2ec
[ 21.022362] [<ffff00000839c680>] map_single+0x4c/0x98
[ 21.027411] [<ffff00000839cd10>] swiotlb_map_page+0xa4/0x138
[ 21.033072] [<ffff000008096380>] __swiotlb_map_page+0x20/0x7c
[ 21.038821] [<ffff00000864f770>] ravb_start_xmit+0x174/0x668
[ 21.044484] [<ffff0000087e6498>] dev_hard_start_xmit+0x8c/0x120
[ 21.050407] [<ffff000008807510>] sch_direct_xmit+0x108/0x1a0
[ 21.056064] [<ffff0000087e67dc>] __dev_queue_xmit+0x194/0x4cc
[ 21.061807] [<ffff0000087e6b24>] dev_queue_xmit+0x10/0x18
[ 21.067214] [<ffff000008880240>] packet_sendmsg+0xf40/0x1220
[ 21.072873] [<ffff0000087c7a34>] sock_sendmsg+0x18/0x2c
[ 21.078097] [<ffff0000087c8c20>] SyS_sendto+0xb0/0xf0
[ 21.083150] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
[ 21.088462] Code: d34bfef7 2a1803f3 1a9f86d6 35fff878 (d4210000)
[ 21.094611] ---[ end trace 5bc544ad491f3814 ]---
[ 21.099234] Kernel panic - not syncing: Fatal exception in interrupt
[ 21.105587] Kernel Offset: disabled
[ 21.109073] Memory Limit: none
[ 21.112126] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
Fixes: 2f45d1902acf ("ravb: minimize TX data copying")
Signed-off-by: Masaru Nagai <masaru.nagai.vx@renesas.com
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
v1 [Simon Horman]
* don't handle skb->len < 4; it is always at least 60
* add comment
* dropped RFC designation
v1 [Simon Horman]
* rewrote changelog
* handle skb->len < 4
v0 [Masaru Nagai]
---
drivers/net/ethernet/renesas/ravb_main.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 5e5ad978eab9..1cd6ba986669 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -1504,6 +1504,19 @@ static netdev_tx_t ravb_start_xmit(struct sk_buff *skb, struct net_device *ndev)
buffer = PTR_ALIGN(priv->tx_align[q], DPTR_ALIGN) +
entry / NUM_TX_DESC * DPTR_ALIGN;
len = PTR_ALIGN(skb->data, DPTR_ALIGN) - skb->data;
+ /* Zero length DMA descriptors are problematic as they terminate
+ * DMA requests. Avoid them by simply using a length of DPTR_ALIGN (4)
+ * when skb data is aligned to DPTR_ALIGN.
+ *
+ * As skb is guaranteed to have at least ETH_ZLEN (60) bytes of
+ * data by the call to skb_put_padto() above this is safe with
+ * respect to both the length of the first DMA descriptor (len)
+ * overflowing the available data and the length of the second DMA
+ * descriptor (skb->len - len) being negative.
+ */
+ if (len == 0)
+ len = DPTR_ALIGN;
+
memcpy(buffer, skb->data, len);
dma_addr = dma_map_single(ndev->dev.parent, buffer, len, DMA_TO_DEVICE);
if (dma_mapping_error(ndev->dev.parent, dma_addr))
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* Re: [PATCH net] ravb: do not use zero-length alighment DMA request
From: Simon Horman @ 2017-01-13 13:14 UTC (permalink / raw)
To: David Miller, Sergei Shtylyov
Cc: Magnus Damm, netdev, linux-renesas-soc, Masaru Nagai
In-Reply-To: <1484312940-11147-1-git-send-email-horms+renesas@verge.net.au>
On Fri, Jan 13, 2017 at 02:09:00PM +0100, Simon Horman wrote:
> From: Masaru Nagai <masaru.nagai.vx@renesas.com>
>
> Due to alignment requirements of the hardware transmissions are split into
> two DMA descriptors, a small padding descriptor of 0 - 3 bytes in length
> followed by a descriptor for rest of the packet.
>
> In the case of IP packets the first descriptor will never be zero due to
> the way that the stack aligns buffers for IP packets. However, for non-IP
> packets it may be zero.
...
Apologies, I forgot to include v2 in the subject prefix.
^ permalink raw reply
* Re: [Patch net] atm: remove an unnecessary loop
From: Francois Romieu @ 2017-01-13 13:23 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, mhocko, 3chas3, andreyknvl
In-Reply-To: <CAM_iQpX2TipBW2Pm-OHRobfZaVoV9_D8Se8u9oKryt96SZFRkA@mail.gmail.com>
Cong Wang <xiyou.wangcong@gmail.com> :
[...]
> alloc_skb(GFP_KERNEL) itself is sleeping, so the new wait api is still
> needed.
The task state change warning is the symptom.
The deeply nested alloc_skb is the problem.
Diagnosis: nesting is wrong. It makes zero sense. Fix it and the
implicit task state change problem automagically goes away.
alloc_skb() does not need to be in the "while" loop.
alloc_skb() does not need to be in the {prepare_to_wait/add_wait_queue ...
finish_wait/remove_wait_queue} block.
alloc_tx() is not correctly named: given its original content, it deserves
to be called something like:
"wait_for_decent_tx_drain_and_alloc_by_hand_coz_i_dont_trust_the_mm_subsystem_and_i_dont_know_what_i_want"
I claim that:
- alloc_tx() should only perform the "wait_for_decent_tx_drain" part
- alloc_skb() ought to be done directly in vcc_sendmsg
- alloc_skb() failure can be handled gracefully in vcc_sendmsg
- alloc_skb() may use a (m->msg_flags & MSG_DONTWAIT) dependant
GFP_{KERNEL / ATOMIC} flag
- most of it can be done in a longterm maintenance pain minimizing
way. Call it a side-effect: I don't claim that it *must* be done
this way.
--
Ueimor
^ permalink raw reply
* [PATCH] flow disector: check if arp_eth is null rather than arp
From: Colin King @ 2017-01-13 13:34 UTC (permalink / raw)
To: David S . Miller, Alexander Duyck, Jiri Pirko, Tom Herbert,
Eric Dumazet, Simon Horman, Hadar Hen Zion, Gao Feng, Amir Vadai,
netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
arp is being checked instead of arp_eth to see if the call to
__skb_header_pointer failed. Fix this by checking arp_eth is
null instead of arp.
CoverityScan CID#1396428 ("Logically dead code") on 2nd
arp comparison (which should be arp_eth instead).
Fixes: commit 55733350e5e8b70c5 ("flow disector: ARP support")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/core/flow_dissector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index e3dffc7..fec48e9 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -409,7 +409,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
sizeof(_arp_eth), data,
hlen - sizeof(_arp),
&_arp_eth);
- if (!arp)
+ if (!arp_eth)
goto out_bad;
if (dissector_uses_key(flow_dissector,
--
2.10.2
^ permalink raw reply related
* Re: To netlink or not to netlink, that is the question
From: Nicolas Dichtel @ 2017-01-13 13:36 UTC (permalink / raw)
To: Johannes Berg, Jason A. Donenfeld, Dan Williams; +Cc: Stephen Hemminger, Netdev
In-Reply-To: <1484291830.19860.3.camel@sipsolutions.net>
Le 13/01/2017 à 08:17, Johannes Berg a écrit :
[snip]
> In addition to what others have said - netlink typically includes (and
> has helpers to do so) a generation counter that's updated whenever this
> list changes, and included in each message, so if userspace really
> cares (often not) it can retry the dump until the system was idle
> enough to get a consistent snapshot.
Look at NLM_F_DUMP_INTR to get details.
>
> It also looks to me like your existing API isn't even compat-safe due
> to u64 alignment (e.g. in wgpeer), proving once again that ioctl is a
> bad idea.
+1
Regards,
Nicolas
^ permalink raw reply
* [PATCH ipsec-next] xfrm: fix possible null deref in xfrm_init_tempstate
From: Florian Westphal @ 2017-01-13 13:55 UTC (permalink / raw)
To: netdev; +Cc: dan.carpenter, Florian Westphal
Dan reports following smatch warning:
net/xfrm/xfrm_state.c:659
error: we previously assumed 'afinfo' could be null (see line 651)
649 struct xfrm_state_afinfo *afinfo = xfrm_state_afinfo_get_rcu(family);
651 if (afinfo)
...
658 }
659 afinfo->init_temprop(x, tmpl, daddr, saddr);
I am resonably sure afinfo cannot be NULL here.
xfrm_state4.c and state6.c are both part of ipv4/ipv6 (depends on
CONFIG_XFRM, a boolean) but even if ipv6 is a module state6.c can't
be removed (ipv6 lacks module_exit so it cannot be removed).
The only callers for xfrm6_fini that leads to state backend unregister
are error unwinding paths that can be called during ipv6 init function.
So after ipv6 module is loaded successfully the state backend cannot go
away anymore.
The family value from policy lookup path is taken from dst_entry, so
that should always be AF_INET(6).
However, since this silences the warning and avoids readers of this
code wondering about possible null deref it seems preferrable to
be defensive and just add the old check back.
Fixes: 711059b9752ad0 ("xfrm: add and use xfrm_state_afinfo_get_rcu")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index a62097e640b5..5a597dbbe564 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -648,8 +648,10 @@ xfrm_init_tempstate(struct xfrm_state *x, const struct flowi *fl,
{
struct xfrm_state_afinfo *afinfo = xfrm_state_afinfo_get_rcu(family);
- if (afinfo)
- afinfo->init_tempsel(&x->sel, fl);
+ if (!afinfo)
+ return;
+
+ afinfo->init_tempsel(&x->sel, fl);
if (family != tmpl->encap_family) {
afinfo = xfrm_state_afinfo_get_rcu(tmpl->encap_family);
--
2.7.3
^ permalink raw reply related
* pull-request: mac80211 2017-01-13
From: Johannes Berg @ 2017-01-13 13:55 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Hi Dave,
Here's another update for the current cycle. Some of those
patches have been sitting in our tree and I haven't been
pulling them out quickly enough - will try to do better...
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 03430fa10b99e95e3a15eb7c00978fb1652f3b24:
Merge branch 'bcm_sf2-fixes' (2017-01-08 22:01:22 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2017-01-13
for you to fetch changes up to dbef53621116474bb883f76f0ba6b7640bc42332:
mac80211: prevent skb/txq mismatch (2017-01-13 14:47:21 +0100)
----------------------------------------------------------------
We have a number of fixes, in part because I was late
in actually sending them out - will try to do better in
the future:
* handle VHT opmode properly when hostapd is controlling
full station state
* two fixes for minimum channel width in mac80211
* don't leave SMPS set to junk in HT capabilities
* fix headroom when forwarding mesh packets, recently
broken by another fix that failed to take into account
frame encryption
* fix the TID in null-data packets indicating EOSP (end
of service period) in U-APSD
* prevent attempting to use (and then failing which
results in crashes) TXQs on stations that aren't added
to the driver yet
----------------------------------------------------------------
Beni Lev (1):
cfg80211: consider VHT opmode on station update
Cedric Izoard (1):
mac80211: Fix headroom allocation when forwarding mesh pkt
Emmanuel Grumbach (1):
mac80211: fix the TID on NDPs sent as EOSP carrier
Felix Fietkau (1):
mac80211: initialize SMPS field in HT capabilities
Johannes Berg (3):
mac80211: implement multicast forwarding on fast-RX path
mac80211: calculate min channel width correctly
mac80211: recalculate min channel width on VHT opmode changes
Michal Kazior (1):
mac80211: prevent skb/txq mismatch
include/uapi/linux/nl80211.h | 4 +++-
net/mac80211/chan.c | 3 ---
net/mac80211/iface.c | 21 +++++++++++++++++++++
net/mac80211/main.c | 13 +++++++++----
net/mac80211/rate.c | 2 ++
net/mac80211/rx.c | 38 +++++++++++++++++++++-----------------
net/mac80211/sta_info.c | 4 ++--
net/mac80211/tx.c | 17 +++++++----------
net/mac80211/vht.c | 4 +++-
net/wireless/nl80211.c | 15 +++++++++++++++
10 files changed, 83 insertions(+), 38 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next] net/mlx5e: Support bpf_xdp_adjust_head()
From: Saeed Mahameed @ 2017-01-13 13:58 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: Linux Netdev List, Saeed Mahameed, Tariq Toukan, Kernel Team
In-Reply-To: <20170112232546.GA1595@kafai-mba.local>
On Fri, Jan 13, 2017 at 1:25 AM, Martin KaFai Lau <kafai@fb.com> wrote:
> On Thu, Jan 12, 2017 at 03:10:30PM +0200, Saeed Mahameed wrote:
>> On Thu, Jan 12, 2017 at 4:09 AM, Martin KaFai Lau <kafai@fb.com> wrote:
>> > This patch adds bpf_xdp_adjust_head() support to mlx5e.
>>
>> Hi Martin, Thanks for the patch !
>>
>> you can find some comments below.
>>
>> >
>> > 1. rx_headroom is added to struct mlx5e_rq. It uses
>> > an existing 4 byte hole in the struct.
>> > 2. The adjusted data length is checked against
>> > MLX5E_XDP_MIN_INLINE and MLX5E_SW2HW_MTU(rq->netdev->mtu).
>> > 3. The macro MLX5E_SW2HW_MTU is moved from en_main.c to en.h.
>> > MLX5E_HW2SW_MTU is also moved to en.h for symmetric reason
>> > but it is not a must.
>> >
>> > Signed-off-by: Martin KaFai Lau <kafai@fb.com>
>> > ---
>> > drivers/net/ethernet/mellanox/mlx5/core/en.h | 4 ++
>> > drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 18 +++----
>> > drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 63 ++++++++++++++---------
>> > 3 files changed, 51 insertions(+), 34 deletions(-)
>> >
>> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h b/drivers/net/ethernet/mellanox/mlx5/core/en.h
>> > index a473cea10c16..0d9dd860a295 100644
>> > --- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
>> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
>> > @@ -51,6 +51,9 @@
>> >
>> > #define MLX5_SET_CFG(p, f, v) MLX5_SET(create_flow_group_in, p, f, v)
>> >
>> > +#define MLX5E_HW2SW_MTU(hwmtu) ((hwmtu) - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN))
>> > +#define MLX5E_SW2HW_MTU(swmtu) ((swmtu) + (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN))
>> > +
>> > #define MLX5E_MAX_NUM_TC 8
>> >
>> > #define MLX5E_PARAMS_MINIMUM_LOG_SQ_SIZE 0x6
>> > @@ -369,6 +372,7 @@ struct mlx5e_rq {
>> >
>> > unsigned long state;
>> > int ix;
>> > + u16 rx_headroom;
>> >
>> > struct mlx5e_rx_am am; /* Adaptive Moderation */
>> > struct bpf_prog *xdp_prog;
>> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>> > index f74ba73c55c7..aba3691e0919 100644
>> > --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>> > @@ -343,9 +343,6 @@ static void mlx5e_disable_async_events(struct mlx5e_priv *priv)
>> > synchronize_irq(mlx5_get_msix_vec(priv->mdev, MLX5_EQ_VEC_ASYNC));
>> > }
>> >
>> > -#define MLX5E_HW2SW_MTU(hwmtu) (hwmtu - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN))
>> > -#define MLX5E_SW2HW_MTU(swmtu) (swmtu + (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN))
>> > -
>> > static inline int mlx5e_get_wqe_mtt_sz(void)
>> > {
>> > /* UMR copies MTTs in units of MLX5_UMR_MTT_ALIGNMENT bytes.
>> > @@ -534,9 +531,13 @@ static int mlx5e_create_rq(struct mlx5e_channel *c,
>> > goto err_rq_wq_destroy;
>> > }
>> >
>> > - rq->buff.map_dir = DMA_FROM_DEVICE;
>> > - if (rq->xdp_prog)
>> > + if (rq->xdp_prog) {
>> > rq->buff.map_dir = DMA_BIDIRECTIONAL;
>> > + rq->rx_headroom = XDP_PACKET_HEADROOM;
>> > + } else {
>> > + rq->buff.map_dir = DMA_FROM_DEVICE;
>> > + rq->rx_headroom = MLX5_RX_HEADROOM;
>> > + }
>> >
>> > switch (priv->params.rq_wq_type) {
>> > case MLX5_WQ_TYPE_LINKED_LIST_STRIDING_RQ:
>> > @@ -586,7 +587,7 @@ static int mlx5e_create_rq(struct mlx5e_channel *c,
>> > byte_count = rq->buff.wqe_sz;
>> >
>> > /* calc the required page order */
>> > - frag_sz = MLX5_RX_HEADROOM +
>> > + frag_sz = rq->rx_headroom +
>> > byte_count /* packet data */ +
>> > SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>> > frag_sz = SKB_DATA_ALIGN(frag_sz);
>> > @@ -3153,11 +3154,6 @@ static int mlx5e_xdp_set(struct net_device *netdev, struct bpf_prog *prog)
>> > bool reset, was_opened;
>> > int i;
>> >
>> > - if (prog && prog->xdp_adjust_head) {
>> > - netdev_err(netdev, "Does not support bpf_xdp_adjust_head()\n");
>> > - return -EOPNOTSUPP;
>> > - }
>> > -
>> > mutex_lock(&priv->state_lock);
>> >
>> > if ((netdev->features & NETIF_F_LRO) && prog) {
>> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
>> > index 0e2fb3ed1790..914e00132e08 100644
>> > --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
>> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
>> > @@ -264,7 +264,7 @@ int mlx5e_alloc_rx_wqe(struct mlx5e_rq *rq, struct mlx5e_rx_wqe *wqe, u16 ix)
>> > if (unlikely(mlx5e_page_alloc_mapped(rq, di)))
>> > return -ENOMEM;
>> >
>> > - wqe->data.addr = cpu_to_be64(di->addr + MLX5_RX_HEADROOM);
>> > + wqe->data.addr = cpu_to_be64(di->addr + rq->rx_headroom);
>> > return 0;
>> > }
>> >
>> > @@ -646,8 +646,7 @@ static inline void mlx5e_xmit_xdp_doorbell(struct mlx5e_sq *sq)
>> >
>> > static inline void mlx5e_xmit_xdp_frame(struct mlx5e_rq *rq,
>> > struct mlx5e_dma_info *di,
>> > - unsigned int data_offset,
>> > - int len)
>> > + const struct xdp_buff *xdp)
>> > {
>> > struct mlx5e_sq *sq = &rq->channel->xdp_sq;
>> > struct mlx5_wq_cyc *wq = &sq->wq;
>> > @@ -659,9 +658,17 @@ static inline void mlx5e_xmit_xdp_frame(struct mlx5e_rq *rq,
>> > struct mlx5_wqe_eth_seg *eseg = &wqe->eth;
>> > struct mlx5_wqe_data_seg *dseg;
>> >
>> > + ptrdiff_t data_offset = xdp->data - xdp->data_hard_start;
>> > dma_addr_t dma_addr = di->addr + data_offset + MLX5E_XDP_MIN_INLINE;
>> > - unsigned int dma_len = len - MLX5E_XDP_MIN_INLINE;
>> > - void *data = page_address(di->page) + data_offset;
>> > + unsigned int dma_len = xdp->data_end - xdp->data;
>> > +
>> > + if (unlikely(dma_len < MLX5E_XDP_MIN_INLINE ||
>>
>> I don't think this can happen, MLX5E_XDP_MIN_INLINE is 18 bytes and
>> should not get bigger in the future,
>> Also i don't think it is possible for XDP prog to xmit packets smaller
>> than 18 bytes, let's remove this
> The bpf_xdp_adjust_head() only checks for a min of ETH_HLEN which is 14.
> Hence, <18 bytes is still possible here.
>
>>
>> > + MLX5E_SW2HW_MTU(rq->netdev->mtu) < dma_len)) {
>> > + rq->stats.xdp_drop++;
>> > + mlx5e_page_release(rq, di, true);
>> > + return;
>> > + }
>> > + dma_len -= MLX5E_XDP_MIN_INLINE;
>>
>> Move this to after the below sanity check, it is better to separate
>> logic from pre-conditions
> Will do.
>
>>
>> >
>> > if (unlikely(!mlx5e_sq_has_room_for(sq, MLX5E_XDP_TX_WQEBBS))) {
>> > if (sq->db.xdp.doorbell) {
>> > @@ -680,7 +687,7 @@ static inline void mlx5e_xmit_xdp_frame(struct mlx5e_rq *rq,
>> > memset(wqe, 0, sizeof(*wqe));
>> >
>> > /* copy the inline part */
>> > - memcpy(eseg->inline_hdr_start, data, MLX5E_XDP_MIN_INLINE);
>> > + memcpy(eseg->inline_hdr_start, xdp->data, MLX5E_XDP_MIN_INLINE);
>> > eseg->inline_hdr_sz = cpu_to_be16(MLX5E_XDP_MIN_INLINE);
>> >
>> > dseg = (struct mlx5_wqe_data_seg *)cseg + (MLX5E_XDP_TX_DS_COUNT - 1);
>> > @@ -706,22 +713,16 @@ static inline void mlx5e_xmit_xdp_frame(struct mlx5e_rq *rq,
>> > static inline bool mlx5e_xdp_handle(struct mlx5e_rq *rq,
>> > const struct bpf_prog *prog,
>> > struct mlx5e_dma_info *di,
>> > - void *data, u16 len)
>> > + struct xdp_buff *xdp)
>> > {
>> > - struct xdp_buff xdp;
>> > u32 act;
>> >
>> > - if (!prog)
>> > - return false;
>> > -
>> > - xdp.data = data;
>> > - xdp.data_end = xdp.data + len;
>> > - act = bpf_prog_run_xdp(prog, &xdp);
>> > + act = bpf_prog_run_xdp(prog, xdp);
>> > switch (act) {
>> > case XDP_PASS:
>> > return false;
>> > case XDP_TX:
>> > - mlx5e_xmit_xdp_frame(rq, di, MLX5_RX_HEADROOM, len);
>> > + mlx5e_xmit_xdp_frame(rq, di, xdp);
>> > return true;
>> > default:
>> > bpf_warn_invalid_xdp_action(act);
>> > @@ -737,18 +738,19 @@ static inline
>> > struct sk_buff *skb_from_cqe(struct mlx5e_rq *rq, struct mlx5_cqe64 *cqe,
>> > u16 wqe_counter, u32 cqe_bcnt)
>> > {
>> > + const struct bpf_prog *xdp_prog;
>> > struct mlx5e_dma_info *di;
>> > struct sk_buff *skb;
>> > void *va, *data;
>> > - bool consumed;
>> > + u16 rx_headroom = rq->rx_headroom;
>> >
>> > di = &rq->dma_info[wqe_counter];
>> > va = page_address(di->page);
>> > - data = va + MLX5_RX_HEADROOM;
>> > + data = va + rx_headroom;
>> >
>> > dma_sync_single_range_for_cpu(rq->pdev,
>> > di->addr,
>> > - MLX5_RX_HEADROOM,
>> > + rx_headroom,
>> > rq->buff.wqe_sz,
>> > DMA_FROM_DEVICE);
>> > prefetch(data);
>> > @@ -760,11 +762,26 @@ struct sk_buff *skb_from_cqe(struct mlx5e_rq *rq, struct mlx5_cqe64 *cqe,
>> > }
>> >
>> > rcu_read_lock();
>> > - consumed = mlx5e_xdp_handle(rq, READ_ONCE(rq->xdp_prog), di, data,
>> > - cqe_bcnt);
>> > + xdp_prog = READ_ONCE(rq->xdp_prog);
>> > + if (xdp_prog) {
>> > + struct xdp_buff xdp;
>> > + bool consumed;
>> > +
>> > + xdp.data = data;
>> > + xdp.data_end = xdp.data + cqe_bcnt;
>> > + xdp.data_hard_start = va;
>> > +
>> > + consumed = mlx5e_xdp_handle(rq, xdp_prog, di, &xdp);
>> > +
>> > + if (consumed) {
>> > + rcu_read_unlock();
>> > + return NULL; /* page/packet was consumed by XDP */
>> > + }
>> > +
>> > + rx_headroom = xdp.data - xdp.data_hard_start;
>> > + cqe_bcnt = xdp.data_end - xdp.data;
>> > + }
>>
>> This whole new logic belongs to mlx5e_xdp_handle, I would like to keep
>> xdp related code in one place.
>>
>> move the xdp_buff initialization back to there and keep the xdp_prog
>> check in mlx5e_xdp_handle;
>> + xdp_prog = READ_ONCE(rq->xdp_prog);
>> + if (!xdp_prog)
>> + return false
>>
>> you can remove "const struct bpf_prog *prog" parameter from
>> mlx5e_xdp_handle and take it directly from rq.
>>
>> if you need va for xdp_buff you can pass it as a paramter to
>> mlx5e_xdp_handle as well:
>> mlx5e_xdp_handle(rq, di, va, data, cqe_bcnt);
>> Make sense ?
> I moved them because xdp.data could be adjusted which then
> rx_headroom and cqe_bcnt have to be adjusted accordingly
> in skb_from_cqe() also.
>
> I understand your point. After another quick thought,
> the adjusted xdp.data is the only one that we want in skb_from_cqe().
> I will try to make mlx5e_xdp_handle() to return the adjusted xdp.data
> instead of bool.
>
hmm, You also need the adjusted cqe_bcnt! this will make
mlx5e_xdp_handle stuffed with parameters,
what if, in skb_from_cqe we warp data, rx_headroom and cqe_bcnt in one struct.
struct mlx5e_rx_buff {
void *data;
u6 headroom;
u32 bcnt;
}
initialize it at the start of skb_from_cqe:
struct mlx5e_rx_buff rxb;
rxb.headroom = rq->headroom;
rxb.data = va + rxb.headroom;
rxb.bcnt = cqe_bcnt;
pass it to mlx5e_xdp_handle(rq, di, va, &rxb) in case xdp_prog is ON
and rxb needs adjustment.
At the end use it to build the SKB:
skb = build_skb(va, RQ_PAGE_SIZE(rq));
skb_reserve(skb, rxb.headroom);
skb_put(skb, rxb.bcnt);
Thanks,
Saeed.
> Thanks,
> --Martin
>
>>
>> > rcu_read_unlock();
>> > - if (consumed)
>> > - return NULL; /* page/packet was consumed by XDP */
>> >
>> > skb = build_skb(va, RQ_PAGE_SIZE(rq));
>> > if (unlikely(!skb)) {
>> > @@ -777,7 +794,7 @@ struct sk_buff *skb_from_cqe(struct mlx5e_rq *rq, struct mlx5_cqe64 *cqe,
>> > page_ref_inc(di->page);
>> > mlx5e_page_release(rq, di, true);
>> >
>> > - skb_reserve(skb, MLX5_RX_HEADROOM);
>> > + skb_reserve(skb, rx_headroom);
>> > skb_put(skb, cqe_bcnt);
>> >
>> > return skb;
>> > --
>> > 2.5.1
>> >
^ permalink raw reply
* Re: [3/5] ath10k: Remove unused wmi_p2p_noa_descriptor 'noa' in wmi-tlv
From: Kalle Valo @ 2017-01-13 14:01 UTC (permalink / raw)
To: Kirtika Ruchandani
Cc: Arnd Bergmann, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Raja Mani, Michal Kazior
In-Reply-To: <99d0ff42e57d5f62560e72d926b4d69d5d7c418b.1479974100.git.kirtika-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Kirtika Ruchandani <kirtika.ruchandani-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Commit ca996ec56608 (ath10k: implement wmi-tlv backend)
> introduced ath10k_wmi_tlv_op_gen_vdev_start() where
> 'struct wmi_p2p_noa_descriptor *noa' is defined and set but not used.
> Compiling with W=1 gives the following warning, fix it.
> drivers/net/wireless/ath/ath10k/wmi-tlv.c: In function ‘ath10k_wmi_tlv_op_gen_vdev_start’:
> drivers/net/wireless/ath/ath10k/wmi-tlv.c:1647:33: warning: variable ‘noa’ set but not used [-Wunused-but-set-variable]
>
> Fixes: ca996ec56608 ("ath10k: implement wmi-tlv backend")
> Cc: Michal Kazior <michal.kazior-++hxYGjEMp0AvxtiuMwx3w@public.gmane.org>
> Cc: Kalle Valo <kvalo-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>
> Signed-off-by: Kirtika Ruchandani <kirtika-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
No response to Michal's comment by the author
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9444937/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH net-next v2 08/10] net: dsa: Add support for platform data
From: Andrew Lunn @ 2017-01-13 14:04 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, Jason Cooper, Sebastian Hesselbarth, Gregory Clement,
Russell King, Vivien Didelot, David S. Miller,
moderated list:ARM SUB-ARCHITECTURES, open list, gregkh
In-Reply-To: <20170112034121.27697-9-f.fainelli@gmail.com>
> index cd91070b5467..d326fc4afad7 100644
> --- a/net/dsa/dsa2.c
> +++ b/net/dsa/dsa2.c
> @@ -81,17 +81,23 @@ static void dsa_dst_del_ds(struct dsa_switch_tree *dst,
>
> static bool dsa_port_is_valid(struct dsa_port *port)
> {
> - return !!port->dn;
> + return !!(port->dn || port->name);
> }
Does this clash with Viviens recent change to make names optional and
have the kernel assign it?
I suppose you could use an name of "eth%d"? Is it worth adding a
comment to the platform data structure?
Andrew
^ permalink raw reply
* [PATCH] xfrm: state: fix potential null pointer dereference on afinfo
From: Colin King @ 2017-01-13 14:07 UTC (permalink / raw)
To: Steffen Klassert, Herbert Xu, David S . Miller, netdev; +Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
afinfo is being null checked before a call afinfo->init_tempsel
so afinfo may be potentially null. ifinfo may still be null in
the case were it is not updated when family == tmpl->encap_family,
hence we may hit a null pointer dereference in the call to
afinfo->init_temprop.
Fix this by adding a null ptr check before calling init_temprop.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/xfrm/xfrm_state.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index a62097e..5083418 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -656,7 +656,8 @@ xfrm_init_tempstate(struct xfrm_state *x, const struct flowi *fl,
if (!afinfo)
return;
}
- afinfo->init_temprop(x, tmpl, daddr, saddr);
+ if (afinfo)
+ afinfo->init_temprop(x, tmpl, daddr, saddr);
}
static struct xfrm_state *__xfrm_state_lookup(struct net *net, u32 mark,
--
2.10.2
^ permalink raw reply related
* Re: [PATCH net-next v2 08/10] net: dsa: Add support for platform data
From: Andrew Lunn @ 2017-01-13 14:11 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, Jason Cooper, Sebastian Hesselbarth, Gregory Clement,
Russell King, Vivien Didelot, David S. Miller,
moderated list:ARM SUB-ARCHITECTURES, open list, gregkh
In-Reply-To: <20170112034121.27697-9-f.fainelli@gmail.com>
> static int _dsa_register_switch(struct dsa_switch *ds, struct device *dev)
> {
> + struct dsa_chip_data *pdata = dev->platform_data;
> struct device_node *np = dev->of_node;
> struct dsa_switch_tree *dst;
> struct device_node *ports;
> u32 tree, index;
> int i, err;
>
> - err = dsa_parse_member_dn(np, &tree, &index);
> - if (err)
> - return err;
> + if (np) {
> + err = dsa_parse_member_dn(np, &tree, &index);
> + if (err)
> + return err;
>
> - ports = dsa_get_ports(ds, np);
> - if (IS_ERR(ports))
> - return PTR_ERR(ports);
> + ports = dsa_get_ports(ds, np);
> + if (IS_ERR(ports))
> + return PTR_ERR(ports);
>
> - err = dsa_parse_ports_dn(ports, ds);
> - if (err)
> - return err;
> + err = dsa_parse_ports_dn(ports, ds);
> + if (err)
> + return err;
> + } else {
> + err = dsa_parse_member(pdata, &tree, &index);
Hi Florian
Maybe it is hiding, but i don't see anywhere you check that pdata !=
NULL.
At least for x86 platforms, i don't expect we are booting using
platform data like ARM systems used to do. I think it is more likely a
glue module will be loaded. It looks up the MDIO bus and appends a
platform data to an MDIO device. The switch driver then needs to load
and use the platform data. But if things happen in a different order,
it could be the switch driver probes before the glue driver, meaning
pdata is NULL.
Do we even want to return -EPROBE_DEFERED?
Andrew
^ permalink raw reply
* tcp: performance issue with fastopen connections (mss > window)
From: Alexey Kodanev @ 2017-01-13 14:17 UTC (permalink / raw)
To: David Miller, Eric Dumazet; +Cc: netdev, Vasily Isaenko
Hi,
Got the issue when running LTP/netstress test on localhost with mss
greater than the send window advertised by client (right after 3WHS).
Here is the testscenario that can reproduce this:
TCP client is sending 32 bytes request, TCP server replies with 65KB answer.
net.ipv4.tcp_fastopen set to 3. Also notethat the first TCP Fastopen
connectionprocessed without delay as tcp_send_mss()setshalf of the window
sizeto the'size_goal' inside tcp_sendmsg().
Though on the 2nd and subsequent connections:
< S seq 0:0 win 43690 options [mss 65495 wscale 7
tfo cookie ac6246a51d5422fc] length 32
> S.seq 0:0ack 1win 43690 options [mss 65495wscale 7] length 0
<.ack 1 win 342 length 0
Inside tcp_sendmsg(), tcp_send_mss() returns 65483 in 'mss_now',as well as
in 'size_goal'. This results the segment not queued for transmition
until all
data copied from userbuffer. Then, inside __tcp_push_pending_frames() it
breaks on send window test,continue with the check probe timer, thus
introducing 200ms delay here.
Fragmentationoccurs in tcp_write_wakeup()...
+0.2> P. seq 1:43777 ack 1 win 342 length 43776
<. ack 43777, win 1365 length 0
> P. seq 43777:65001 ack 1 win 342 optionslength 21224
...
Not sure what is the right fix for this, I guess we could limit 'size_goal'
to the current window or mss, what is currently less, e.g:
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 4a04496..3d3bd97 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -860,7 +860,12 @@ static unsigned int tcp_xmit_size_goal(struct sock
*sk, u32 mss_now,
size_goal = tp->gso_segs * mss_now;
}
- return max(size_goal, mss_now);
+ size_goal = max(size_goal, mss_now);
+
+ if (tp->snd_wnd > TCP_MSS_DEFAULT)
+ return min(tp->snd_wnd, size_goal);
+
+ return size_goal;
}
static int tcp_send_mss(struct sock *sk, int *size_goal, int flags)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 1d5331a..0ac133f 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2445,7 +2445,7 @@ void tcp_push_one(struct sock *sk, unsigned int
mss_now)
{
struct sk_buff *skb = tcp_send_head(sk);
- BUG_ON(!skb || skb->len < mss_now);
+ BUG_ON(!skb);
tcp_write_xmit(sk, mss_now, TCP_NAGLE_PUSH, 1, sk->sk_allocation);
}
Any ideas?
Thanks,
Alexey
^ permalink raw reply related
* [PATCH] net: phy: dp83867: allow RGMII_TXID/RGMII_RXID interface types
From: Murali Karicheri @ 2017-01-13 14:32 UTC (permalink / raw)
To: robh+dt, mark.rutland, f.fainelli, netdev, devicetree,
linux-kernel, nsekhar
Currently dp83867 driver returns error if phy interface type
PHY_INTERFACE_MODE_RGMII_RXID is used to set the rx only internal
delay. Similarly issue happens for PHY_INTERFACE_MODE_RGMII_TXID.
Fix this by checking also the interface type if a particular delay
value is missing in the phy dt bindings. Also update the DT document
accordingly.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
- I had sent this earlier and some how it didn't get through and
I haven't seen any comment for this. So sending this again.
- Applies to master.
Documentation/devicetree/bindings/net/ti,dp83867.txt | 6 ++++--
drivers/net/phy/dp83867.c | 8 ++++++--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt
index 85bf945..afe9630 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
@@ -3,9 +3,11 @@
Required properties:
- reg - The ID number for the phy, usually a small integer
- ti,rx-internal-delay - RGMII Receive Clock Delay - see dt-bindings/net/ti-dp83867.h
- for applicable values
+ for applicable values. Required only if interface type is
+ PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_RXID
- ti,tx-internal-delay - RGMII Transmit Clock Delay - see dt-bindings/net/ti-dp83867.h
- for applicable values
+ for applicable values. Required only if interface type is
+ PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_TXID
- ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
for applicable values
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index e84ae08..ca1b462 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -132,12 +132,16 @@ static int dp83867_of_init(struct phy_device *phydev)
ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
&dp83867->rx_id_delay);
- if (ret)
+ if (ret &&
+ (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+ phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID))
return ret;
ret = of_property_read_u32(of_node, "ti,tx-internal-delay",
&dp83867->tx_id_delay);
- if (ret)
+ if (ret &&
+ (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+ phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID))
return ret;
return of_property_read_u32(of_node, "ti,fifo-depth",
--
1.9.1
^ permalink raw reply related
* Re: [PATCH V2] audit: log 32-bit socketcalls
From: Eric Paris @ 2017-01-13 14:42 UTC (permalink / raw)
To: Richard Guy Briggs, netdev, linux-kernel, linux-audit
Cc: Kangkook Jee, Paul Moore, Steve Grubb
In-Reply-To: <dd937da01da72da9277e44ed79abd1f4618c14c5.1484297765.git.rgb@redhat.com>
On Fri, 2017-01-13 at 04:51 -0500, Richard Guy Briggs wrote:
> 32-bit socketcalls were not being logged by audit on x86_64 systems.
> Log them. This is basically a duplicate of the call from
> net/socket.c:sys_socketcall(), but it addresses the impedance
> mismatch
> between 32-bit userspace process and 64-bit kernel audit.
>
> See: https://github.com/linux-audit/audit-kernel/issues/14
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
>
> --
> v2:
> Move work to audit_socketcall_compat() and use
> audit_dummy_context().
> ---
> include/linux/audit.h | 16 ++++++++++++++++
> net/compat.c | 15 +++++++++++++--
> 2 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 9d4443f..43d8003 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -387,6 +387,18 @@ static inline int audit_socketcall(int nargs,
> unsigned long *args)
> return __audit_socketcall(nargs, args);
> return 0;
> }
> +static inline int audit_socketcall_compat(int nargs, u32 *args)
> +{
> + if (unlikely(!audit_dummy_context())) {
I've always hated these likely/unlikely. Mostly because I think they
are so often wrong. I believe this says that you compiled audit in but
you expect it to be explicitly disabled. While that is (recently) true
in Fedora I highly doubt that's true on the vast majority of systems
that have audit compiled in.
I think all of the likely/unlikely need to just be abandoned, but at
least don't add more? It certainly wouldn't be the first time I was
wrong, and I haven't profiled it. But the function would definitely
look better if coded
static inline int audit_socketcall_compat(int nargs, u32 *args)
{
if (audit_cummy_context()) {
return 0
}
int i;
unsigned long a[AUDITSC_ARGS];
[...]
}
> + int i;
> + unsigned long a[AUDITSC_ARGS];
> +
> + for (i=0; i<nargs; i++)
> + a[i] = (unsigned long)args[i];
> + return __audit_socketcall(nargs, a);
> + }
> + return 0;
> +}
> static inline int audit_sockaddr(int len, void *addr)
> {
> if (unlikely(!audit_dummy_context()))
> @@ -513,6 +525,10 @@ static inline int audit_socketcall(int nargs,
> unsigned long *args)
> {
> return 0;
> }
> +static inline int audit_socketcall_compat(int nargs, u32 *args)
> +{
> + return 0;
> +}
> static inline void audit_fd_pair(int fd1, int fd2)
> { }
> static inline int audit_sockaddr(int len, void *addr)
> diff --git a/net/compat.c b/net/compat.c
> index 1cd2ec0..f0404d4 100644
> --- a/net/compat.c
> +++ b/net/compat.c
> @@ -22,6 +22,7 @@
> #include <linux/filter.h>
> #include <linux/compat.h>
> #include <linux/security.h>
> +#include <linux/audit.h>
> #include <linux/export.h>
>
> #include <net/scm.h>
> @@ -781,14 +782,24 @@ COMPAT_SYSCALL_DEFINE5(recvmmsg, int, fd,
> struct compat_mmsghdr __user *, mmsg,
>
> COMPAT_SYSCALL_DEFINE2(socketcall, int, call, u32 __user *, args)
> {
> + unsigned int len;
> int ret;
> - u32 a[6];
> + u32 a[AUDITSC_ARGS];
> u32 a0, a1;
>
> if (call < SYS_SOCKET || call > SYS_SENDMMSG)
> return -EINVAL;
> - if (copy_from_user(a, args, nas[call]))
> + len = nas[call];
> + if (len > sizeof(a))
> + return -EINVAL;
> +
> + if (copy_from_user(a, args, len))
> return -EFAULT;
> +
> + ret = audit_socketcall_compat(len/sizeof(a[0]), a);
> + if (ret)
> + return ret;
> +
> a0 = a[0];
> a1 = a[1];
>
^ permalink raw reply
* [PATCH net-next] afs: Conditionalise a new unused variable
From: David Howells @ 2017-01-13 14:46 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
The bulk readpages support introduced a harmless warning:
fs/afs/file.c: In function 'afs_readpages_page_done':
fs/afs/file.c:270:20: error: unused variable 'vnode' [-Werror=unused-variable]
This adds an #ifdef to match the user of that variable. The user of the
variable has to be conditional because it accesses a member of a struct
that is also conditional.
Fixes: 91b467e0a3f5 ("afs: Make afs_readpages() fetch data in bulk")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David Howells <dhowells@redhat.com>
---
fs/afs/file.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/afs/file.c b/fs/afs/file.c
index 82897a78abc7..ba7b71fba34b 100644
--- a/fs/afs/file.c
+++ b/fs/afs/file.c
@@ -267,7 +267,9 @@ static int afs_readpage(struct file *file, struct page *page)
*/
static void afs_readpages_page_done(struct afs_call *call, struct afs_read *req)
{
+#ifdef CONFIG_AFS_FSCACHE
struct afs_vnode *vnode = call->reply;
+#endif
struct page *page = req->pages[req->index];
req->pages[req->index] = NULL;
^ permalink raw reply related
* [PATCH net v1 1/1] tipc: allocate user memory with GFP_KERNEL flag
From: Parthasarathy Bhuvaragan @ 2017-01-13 14:46 UTC (permalink / raw)
To: netdev, ying.xue; +Cc: jon.maloy, tipc-discussion
Until now, we allocate memory always with GFP_ATOMIC flag.
When the system is under memory pressure and a user tries to send,
the send fails due to low memory. However, the user application
can wait for free memory if we allocate it using GFP_KERNEL flag.
In this commit, we use allocate memory with GFP_KERNEL for all user
allocation.
Reported-by: Rune Torgersen <runet@innovsys.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
---
net/tipc/discover.c | 4 ++--
net/tipc/link.c | 2 +-
net/tipc/msg.c | 16 ++++++++--------
net/tipc/msg.h | 2 +-
net/tipc/name_distr.c | 2 +-
5 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/net/tipc/discover.c b/net/tipc/discover.c
index 6b109a808d4c..02462d67d191 100644
--- a/net/tipc/discover.c
+++ b/net/tipc/discover.c
@@ -169,7 +169,7 @@ void tipc_disc_rcv(struct net *net, struct sk_buff *skb,
/* Send response, if necessary */
if (respond && (mtyp == DSC_REQ_MSG)) {
- rskb = tipc_buf_acquire(MAX_H_SIZE);
+ rskb = tipc_buf_acquire(MAX_H_SIZE, GFP_ATOMIC);
if (!rskb)
return;
tipc_disc_init_msg(net, rskb, DSC_RESP_MSG, bearer);
@@ -278,7 +278,7 @@ int tipc_disc_create(struct net *net, struct tipc_bearer *b,
req = kmalloc(sizeof(*req), GFP_ATOMIC);
if (!req)
return -ENOMEM;
- req->buf = tipc_buf_acquire(MAX_H_SIZE);
+ req->buf = tipc_buf_acquire(MAX_H_SIZE, GFP_ATOMIC);
if (!req->buf) {
kfree(req);
return -ENOMEM;
diff --git a/net/tipc/link.c b/net/tipc/link.c
index b758ca8b2f79..b0f8646e0631 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1384,7 +1384,7 @@ void tipc_link_tnl_prepare(struct tipc_link *l, struct tipc_link *tnl,
msg_set_seqno(hdr, seqno++);
pktlen = msg_size(hdr);
msg_set_size(&tnlhdr, pktlen + INT_H_SIZE);
- tnlskb = tipc_buf_acquire(pktlen + INT_H_SIZE);
+ tnlskb = tipc_buf_acquire(pktlen + INT_H_SIZE, GFP_ATOMIC);
if (!tnlskb) {
pr_warn("%sunable to send packet\n", link_co_err);
return;
diff --git a/net/tipc/msg.c b/net/tipc/msg.c
index a22be502f1bd..ab02d0742476 100644
--- a/net/tipc/msg.c
+++ b/net/tipc/msg.c
@@ -58,12 +58,12 @@ static unsigned int align(unsigned int i)
* NOTE: Headroom is reserved to allow prepending of a data link header.
* There may also be unrequested tailroom present at the buffer's end.
*/
-struct sk_buff *tipc_buf_acquire(u32 size)
+struct sk_buff *tipc_buf_acquire(u32 size, gfp_t gfp)
{
struct sk_buff *skb;
unsigned int buf_size = (BUF_HEADROOM + size + 3) & ~3u;
- skb = alloc_skb_fclone(buf_size, GFP_ATOMIC);
+ skb = alloc_skb_fclone(buf_size, gfp);
if (skb) {
skb_reserve(skb, BUF_HEADROOM);
skb_put(skb, size);
@@ -95,7 +95,7 @@ struct sk_buff *tipc_msg_create(uint user, uint type,
struct tipc_msg *msg;
struct sk_buff *buf;
- buf = tipc_buf_acquire(hdr_sz + data_sz);
+ buf = tipc_buf_acquire(hdr_sz + data_sz, GFP_ATOMIC);
if (unlikely(!buf))
return NULL;
@@ -261,7 +261,7 @@ int tipc_msg_build(struct tipc_msg *mhdr, struct msghdr *m,
/* No fragmentation needed? */
if (likely(msz <= pktmax)) {
- skb = tipc_buf_acquire(msz);
+ skb = tipc_buf_acquire(msz, GFP_KERNEL);
if (unlikely(!skb))
return -ENOMEM;
skb_orphan(skb);
@@ -282,7 +282,7 @@ int tipc_msg_build(struct tipc_msg *mhdr, struct msghdr *m,
msg_set_importance(&pkthdr, msg_importance(mhdr));
/* Prepare first fragment */
- skb = tipc_buf_acquire(pktmax);
+ skb = tipc_buf_acquire(pktmax, GFP_KERNEL);
if (!skb)
return -ENOMEM;
skb_orphan(skb);
@@ -313,7 +313,7 @@ int tipc_msg_build(struct tipc_msg *mhdr, struct msghdr *m,
pktsz = drem + INT_H_SIZE;
else
pktsz = pktmax;
- skb = tipc_buf_acquire(pktsz);
+ skb = tipc_buf_acquire(pktsz, GFP_KERNEL);
if (!skb) {
rc = -ENOMEM;
goto error;
@@ -448,7 +448,7 @@ bool tipc_msg_make_bundle(struct sk_buff **skb, struct tipc_msg *msg,
if (msz > (max / 2))
return false;
- _skb = tipc_buf_acquire(max);
+ _skb = tipc_buf_acquire(max, GFP_ATOMIC);
if (!_skb)
return false;
@@ -496,7 +496,7 @@ bool tipc_msg_reverse(u32 own_node, struct sk_buff **skb, int err)
/* Never return SHORT header; expand by replacing buffer if necessary */
if (msg_short(hdr)) {
- *skb = tipc_buf_acquire(BASIC_H_SIZE + dlen);
+ *skb = tipc_buf_acquire(BASIC_H_SIZE + dlen, GFP_ATOMIC);
if (!*skb)
goto exit;
memcpy((*skb)->data + BASIC_H_SIZE, msg_data(hdr), dlen);
diff --git a/net/tipc/msg.h b/net/tipc/msg.h
index 850ae0e469f5..f07b51e3f6f1 100644
--- a/net/tipc/msg.h
+++ b/net/tipc/msg.h
@@ -818,7 +818,7 @@ static inline bool msg_is_reset(struct tipc_msg *hdr)
return (msg_user(hdr) == LINK_PROTOCOL) && (msg_type(hdr) == RESET_MSG);
}
-struct sk_buff *tipc_buf_acquire(u32 size);
+struct sk_buff *tipc_buf_acquire(u32 size, gfp_t gfp);
bool tipc_msg_validate(struct sk_buff *skb);
bool tipc_msg_reverse(u32 own_addr, struct sk_buff **skb, int err);
void tipc_msg_init(u32 own_addr, struct tipc_msg *m, u32 user, u32 type,
diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
index c1cfd92de17a..23f8899e0f8c 100644
--- a/net/tipc/name_distr.c
+++ b/net/tipc/name_distr.c
@@ -69,7 +69,7 @@ static struct sk_buff *named_prepare_buf(struct net *net, u32 type, u32 size,
u32 dest)
{
struct tipc_net *tn = net_generic(net, tipc_net_id);
- struct sk_buff *buf = tipc_buf_acquire(INT_H_SIZE + size);
+ struct sk_buff *buf = tipc_buf_acquire(INT_H_SIZE + size, GFP_ATOMIC);
struct tipc_msg *msg;
if (buf != NULL) {
--
2.1.4
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
^ permalink raw reply related
* Re: tcp: performance issue with fastopen connections (mss > window)
From: Alexey Kodanev @ 2017-01-13 14:58 UTC (permalink / raw)
To: David Miller, Eric Dumazet; +Cc: netdev, Vasily Isaenko
In-Reply-To: <5878E166.8080800@oracle.com>
On 13.01.2017 17:17, Alexey Kodanev wrote:
> Hi,
>
> Got the issue when running LTP/netstress test on localhost with mss
> greater than the send window advertised by client (right after 3WHS).
> Here is the testscenario that can reproduce this:
Please ignore this message with 'flowed' format. Will resend.
Thanks,
Alexey
^ permalink raw reply
* resend: tcp: performance issue with fastopen connections (mss > window)
From: Alexey Kodanev @ 2017-01-13 15:01 UTC (permalink / raw)
To: David Miller, Eric Dumazet; +Cc: netdev, Vasily Isaenko
Hi,
Got the issue when running LTP/netstress test on localhost with mss
greater than the send window advertised by client (right after 3WHS).
Here is the testscenario that can reproduce this:
TCP client is sending 32 bytes request, TCP server replies with 65KB answer.
net.ipv4.tcp_fastopen set to 3. Also notethat first TCP Fastopen connection
processed without delay as tcp_send_mss()setshalf of the window size
to the'size_goal' inside tcp_sendmsg().
Though on the 2nd and subsequent connections:
< S seq 0:0 win 43690 options [mss 65495 wscale 7
tfo cookie ac6246a51d5422fc] length 32
> S.seq 0:0ack 1win 43690 options [mss 65495wscale 7] length 0
<. ack 1 win 342 length 0
Inside tcp_sendmsg(), tcp_send_mss() returns 65483 in 'mss_now',as well as
in 'size_goal'. This results the segment not queued for transmition
until all
data copied from userbuffer. Then, inside __tcp_push_pending_frames() it
breaks on send window test,continue with the check probe timer, thus
introducing 200ms delay here.
Fragmentationoccurs in tcp_write_wakeup()...
+0.2> P. seq 1:43777 ack 1 win 342 length 43776
< . ack 43777, win 1365 length 0
> P. seq 43777:65001 ack 1 win 342 optionslength 21224
...
Not sure what is the right fix for this, I guess we could limit size_goal
to the current window or mss, what is currently less, e.g:
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 4a04496..3d3bd97 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -860,7 +860,12 @@ static unsigned int tcp_xmit_size_goal(struct sock
*sk, u32 mss_now,
size_goal = tp->gso_segs * mss_now;
}
- return max(size_goal, mss_now);
+ size_goal = max(size_goal, mss_now);
+
+ if (tp->snd_wnd > TCP_MSS_DEFAULT)
+ return min(tp->snd_wnd, size_goal);
+
+ return size_goal;
}
static int tcp_send_mss(struct sock *sk, int *size_goal, int flags)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 1d5331a..0ac133f 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2445,7 +2445,7 @@ void tcp_push_one(struct sock *sk, unsigned int
mss_now)
{
struct sk_buff *skb = tcp_send_head(sk);
- BUG_ON(!skb || skb->len < mss_now);
+ BUG_ON(!skb);
tcp_write_xmit(sk, mss_now, TCP_NAGLE_PUSH, 1, sk->sk_allocation);
}
Any ideas?
Best regards,
Alexey
^ permalink raw reply related
* Re: [PATCH] rtlwifi: rtl8192ee: New firmware from Realtek
From: Kyle McMartin @ 2017-01-13 15:03 UTC (permalink / raw)
To: Larry Finger
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Troy Tan,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-firmware-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <20161217185054.15017-1-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
On Sat, Dec 17, 2016 at 12:50:54PM -0600, Larry Finger wrote:
> -Info: Taken from Realtek version rtl_92ce_92se_92de_8723ae_88ee_8723be_92ee_linux_mac80211_0017.1224.2013
> +Info: Initial version taken from Realtek version
> + rtl_92ce_92se_92de_8723ae_88ee_8723be_92ee_linux_mac80211_0017.1224.2013
> + Updated Jan. 14, 2015 with file added by Realtek to
> + http://github.com/lwfinger/rtlwifi_new.git.
> File: rtlwifi/rtl8192eefw.bin
>
Uh, did something weird happen here? This patch was applied in 2015. ;-)
cheers, Kyle
^ permalink raw reply
* Re: [PATCH V2] audit: log 32-bit socketcalls
From: Richard Guy Briggs @ 2017-01-13 15:06 UTC (permalink / raw)
To: Eric Paris
Cc: netdev, linux-kernel, linux-audit, Kangkook Jee, Paul Moore,
Steve Grubb
In-Reply-To: <1484318543.5300.1.camel@redhat.com>
On 2017-01-13 09:42, Eric Paris wrote:
> On Fri, 2017-01-13 at 04:51 -0500, Richard Guy Briggs wrote:
> > 32-bit socketcalls were not being logged by audit on x86_64 systems.
> > Log them. This is basically a duplicate of the call from
> > net/socket.c:sys_socketcall(), but it addresses the impedance
> > mismatch
> > between 32-bit userspace process and 64-bit kernel audit.
> >
> > See: https://github.com/linux-audit/audit-kernel/issues/14
> >
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> >
> > --
> > v2:
> > Move work to audit_socketcall_compat() and use
> > audit_dummy_context().
> > ---
> > include/linux/audit.h | 16 ++++++++++++++++
> > net/compat.c | 15 +++++++++++++--
> > 2 files changed, 29 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index 9d4443f..43d8003 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -387,6 +387,18 @@ static inline int audit_socketcall(int nargs,
> > unsigned long *args)
> > return __audit_socketcall(nargs, args);
> > return 0;
> > }
> > +static inline int audit_socketcall_compat(int nargs, u32 *args)
> > +{
> > + if (unlikely(!audit_dummy_context())) {
>
> I've always hated these likely/unlikely. Mostly because I think they
> are so often wrong. I believe this says that you compiled audit in but
> you expect it to be explicitly disabled. While that is (recently) true
> in Fedora I highly doubt that's true on the vast majority of systems
> that have audit compiled in.
It has been argued that audit should have pretty much no performance
impact if it is not in use and that if it is, we're willing to take the
more significant overhead of the rest of the code for the sake of one
test to determine whether or not to follow this code path. The audit
subsystem isn't everyone's favourite baby so not making performance
worse for non-audit-users might help play nice in the community. I did
contemplate Hanlon's Razor when wondering if this call had been left out
to avoid thunking complications or overhead.
In this case, compat users are less likely to raise a stink about
performance issues, so this situation is not particularly critical.
> I think all of the likely/unlikely need to just be abandoned, but at
> least don't add more? It certainly wouldn't be the first time I was
> wrong, and I haven't profiled it. But the function would definitely
> look better if coded
This is a seperate issue and I agree about simply bailing early rather
than putting the rest of the function in one conditional. Given the
scoping though, the local variables aren't needed to be allocated in the
unlikely case, but I'm sure the compiler optimizer knows better than we
do how to make this go fast...
In both cases, I thought there was value in making
audit_socketcall_compat() as similar in logic to audit_socketcall() as
possible to make them easier to maintain.
Is either issue a cause for patch respin? If so, I'll want to normalize
the two functions for consistency.
> static inline int audit_socketcall_compat(int nargs, u32 *args)
> {
> if (audit_cummy_context()) {
> return 0
> }
> int i;
> unsigned long a[AUDITSC_ARGS];
>
> [...]
> }
>
> > + int i;
> > + unsigned long a[AUDITSC_ARGS];
> > +
> > + for (i=0; i<nargs; i++)
> > + a[i] = (unsigned long)args[i];
> > + return __audit_socketcall(nargs, a);
> > + }
> > + return 0;
> > +}
> > static inline int audit_sockaddr(int len, void *addr)
> > {
> > if (unlikely(!audit_dummy_context()))
> > @@ -513,6 +525,10 @@ static inline int audit_socketcall(int nargs,
> > unsigned long *args)
> > {
> > return 0;
> > }
> > +static inline int audit_socketcall_compat(int nargs, u32 *args)
> > +{
> > + return 0;
> > +}
> > static inline void audit_fd_pair(int fd1, int fd2)
> > { }
> > static inline int audit_sockaddr(int len, void *addr)
> > diff --git a/net/compat.c b/net/compat.c
> > index 1cd2ec0..f0404d4 100644
> > --- a/net/compat.c
> > +++ b/net/compat.c
> > @@ -22,6 +22,7 @@
> > #include <linux/filter.h>
> > #include <linux/compat.h>
> > #include <linux/security.h>
> > +#include <linux/audit.h>
> > #include <linux/export.h>
> >
> > #include <net/scm.h>
> > @@ -781,14 +782,24 @@ COMPAT_SYSCALL_DEFINE5(recvmmsg, int, fd,
> > struct compat_mmsghdr __user *, mmsg,
> >
> > COMPAT_SYSCALL_DEFINE2(socketcall, int, call, u32 __user *, args)
> > {
> > + unsigned int len;
> > int ret;
> > - u32 a[6];
> > + u32 a[AUDITSC_ARGS];
> > u32 a0, a1;
> >
> > if (call < SYS_SOCKET || call > SYS_SENDMMSG)
> > return -EINVAL;
> > - if (copy_from_user(a, args, nas[call]))
> > + len = nas[call];
> > + if (len > sizeof(a))
> > + return -EINVAL;
> > +
> > + if (copy_from_user(a, args, len))
> > return -EFAULT;
> > +
> > + ret = audit_socketcall_compat(len/sizeof(a[0]), a);
> > + if (ret)
> > + return ret;
> > +
> > a0 = a[0];
> > a1 = a[1];
> >
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH V2] audit: log 32-bit socketcalls
From: Eric Paris @ 2017-01-13 15:18 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: netdev, linux-kernel, linux-audit, Kangkook Jee, Paul Moore,
Steve Grubb
In-Reply-To: <20170113150637.GB3087@madcap2.tricolour.ca>
On Fri, 2017-01-13 at 10:06 -0500, Richard Guy Briggs wrote:
> On 2017-01-13 09:42, Eric Paris wrote:
> > On Fri, 2017-01-13 at 04:51 -0500, Richard Guy Briggs wrote:
> > > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > > index 9d4443f..43d8003 100644
> > > --- a/include/linux/audit.h
> > > +++ b/include/linux/audit.h
> > > @@ -387,6 +387,18 @@ static inline int audit_socketcall(int
> > > nargs,
> > > unsigned long *args)
> > > return __audit_socketcall(nargs, args);
> > > return 0;
> > > }
> > > +static inline int audit_socketcall_compat(int nargs, u32 *args)
> > > +{
> > > + if (unlikely(!audit_dummy_context())) {
> >
> > I've always hated these likely/unlikely. Mostly because I think
> > they
> > are so often wrong. I believe this says that you compiled audit in
> > but
> > you expect it to be explicitly disabled. While that is (recently)
> > true
> > in Fedora I highly doubt that's true on the vast majority of
> > systems
> > that have audit compiled in.
>
> It has been argued that audit should have pretty much no performance
> impact if it is not in use and that if it is, we're willing to take
> the
> more significant overhead of the rest of the code for the sake of one
> test to determine whether or not to follow this code path.
Ok, I can buy that argument. Not sure its where I would have settled,
but it does make sense. I'll obviously defer to Paul on what he wants
out of style. I always assume the compiler is brilliant and write
stupid code but your logic is sound there too.
You can/should pretend I said nothing.
^ permalink raw reply
* Re: Setting link down or up in software
From: Mason @ 2017-01-13 15:17 UTC (permalink / raw)
To: Zefir Kurtisi, netdev
Cc: Mans Rullgard, Florian Fainelli, Andrew Lunn, Thibaud Cornic
In-Reply-To: <0273a4ad-46f7-d7b9-a206-6bd713e6165e@neratec.com>
On 13/01/2017 10:20, Zefir Kurtisi wrote:
> On 01/12/2017 04:16 PM, Mason wrote:
>> On 12/01/2017 14:05, Mason wrote:
>>
>>> I'm wondering what are the semantics of calling
>>>
>>> ip link set dev eth0 down
>>>
>>> I was expecting that to somehow instruct the device's ethernet driver
>>> to shut everything down, have the PHY tell the peer that it's going
>>> away, maybe even put the PHY in some low-power mode, etc.
>>>
>>> But it doesn't seem to be doing any of that on my HW.
>>>
>>> So what exactly is it supposed to do?
>>>
>>>
>>> And on top of that, I am seeing random occurrences of
>>>
>>> nb8800 26000.ethernet eth0: Link is Down
>>>
>>> Sometimes it is printed immediately.
>>> Sometimes it is printed as soon as I run "ip link set dev eth0 up" (?!)
>>> Sometimes it is not printed at all.
>>>
>>> I find this erratic behavior very confusing.
>>>
>>> Is it the symptom of some deeper bug?
>>
>> Here's an example of "Link is Down" printed when I set link up:
>>
>> At [ 62.750220] I run ip link set dev eth0 down
>> Then leave the system idle for 10 minutes.
>> At [ 646.263041] I run ip link set dev eth0 up
>> At [ 647.364079] it prints "Link is Down"
>> At [ 649.417434] it prints "Link is Up - 1Gbps/Full - flow control rx/tx"
>>
>> I think whether I set up the PHY to use interrupts or polling
>> does have an influence on the weirdness I observe.
>>
>> AFAICT, changing the interface flags is done in dev_change_flags
>> which calls __dev_change_flags and __dev_notify_flags
>>
>> Is one of these supposed to call the device driver through a
>> callback at some point?
>>
>> How/when is the phy_state_machine notified of the change in
>> interface flags?
>>
>> Regards.
>>
> Hm, reminds me of something at my side that I recently fixed with [1]. For me it
> was pulling the cable got randomly unnoticed at PHY layer - but might be related.
>
> Do you by chance have some component that polls the link states over the ethtool
> interface very often (like once per second)? At my side it was a snmpd agent that
> pro-actively updated the interface states every second and with that 'stole' the
> link change information from the phy link state machine. What you need to have to
> run in such a failing situation is:
> 1) an ETH driver that updates link status in ethtool GSET path (e.g. dsa does)
> 2) some component that continuously polls states via ethtool GSET
>
>
> Cheers,
> Zefir
>
>
> [1] https://patchwork.ozlabs.org/patch/711839/
Hello Zefir,
Thanks for the insightful comment.
This is a minimal buildroot system, with no frills, and not much running.
There definitely is no SNMP daemon running, but I can't be 100% sure that
busybox isn't polling the link state once in a while. (It's unlikely.)
I'm surprised that there are still bugs lurking in the phy state machine,
I expected this to be a "solved problem", but I suppose power management
has broken many assumptions that were once safe...
By the way, I did come across code paths where phy->state was read or
written without taking the lock. Isn't that never supposed to happen?
Regards.
^ 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