* Re: [PATCH 08/36] aio: implement io_pgetevents
From: Jeff Moyer @ 2018-03-20 15:34 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Darrick J. Wong, viro, Avi Kivity, linux-aio, linux-fsdevel,
netdev, linux-api, linux-kernel
In-Reply-To: <20180320153145.GA24313@lst.de>
Christoph Hellwig <hch@lst.de> writes:
> On Tue, Mar 20, 2018 at 11:30:29AM -0400, Jeff Moyer wrote:
>> > In this commit:
>> >
>> > http://git.infradead.org/users/hch/libaio.git/commitdiff/49f77d595210393ce7b125cb00233cf737402f56
>>
>> BTW, the man pages are shipped in the man-pages package, now.
>> Christoph, I can forward the change to Michael after this series goes
>> in. Just let me know what's easiest for you.
>
> I'd be more than happy to send patch to Michael if we get these
> patches merged finally :)
hahaha, least of your problems, I know. :)
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* [PATCH net-next] net: mvpp2: Don't use dynamic allocs for local variables
From: Maxime Chevallier @ 2018-03-20 15:34 UTC (permalink / raw)
To: davem
Cc: Maxime Chevallier, netdev, linux-kernel, Antoine Tenart,
thomas.petazzoni, gregory.clement, miquel.raynal, nadavh, stefanc,
ymarkman, mw
Some helper functions that search for given entries in the TCAM filter
on PPv2 controller make use of dynamically alloced temporary variables,
allocated with GFP_KERNEL. These functions can be called in atomic
context, and dynamic alloc is not really needed in these cases anyways.
This commit gets rid of dynamic allocs and use stack allocation in the
following functions, and where they're used :
- mvpp2_prs_flow_find
- mvpp2_prs_vlan_find
- mvpp2_prs_double_vlan_find
- mvpp2_prs_mac_da_range_find
For all these functions, instead of returning an temporary object
representing the TCAM entry, we simply return the TCAM id that matches
the requested entry.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 282 +++++++++++++++--------------------
1 file changed, 124 insertions(+), 158 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 9bd35f2291d6..2c4f096b21c3 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -1913,16 +1913,11 @@ static void mvpp2_prs_sram_offset_set(struct mvpp2_prs_entry *pe,
}
/* Find parser flow entry */
-static struct mvpp2_prs_entry *mvpp2_prs_flow_find(struct mvpp2 *priv, int flow)
+static int mvpp2_prs_flow_find(struct mvpp2 *priv, int flow)
{
- struct mvpp2_prs_entry *pe;
+ struct mvpp2_prs_entry pe;
int tid;
- pe = kzalloc(sizeof(*pe), GFP_KERNEL);
- if (!pe)
- return NULL;
- mvpp2_prs_tcam_lu_set(pe, MVPP2_PRS_LU_FLOWS);
-
/* Go through the all entires with MVPP2_PRS_LU_FLOWS */
for (tid = MVPP2_PRS_TCAM_SRAM_SIZE - 1; tid >= 0; tid--) {
u8 bits;
@@ -1931,17 +1926,16 @@ static struct mvpp2_prs_entry *mvpp2_prs_flow_find(struct mvpp2 *priv, int flow)
priv->prs_shadow[tid].lu != MVPP2_PRS_LU_FLOWS)
continue;
- pe->index = tid;
- mvpp2_prs_hw_read(priv, pe);
- bits = mvpp2_prs_sram_ai_get(pe);
+ pe.index = tid;
+ mvpp2_prs_hw_read(priv, &pe);
+ bits = mvpp2_prs_sram_ai_get(&pe);
/* Sram store classification lookup ID in AI bits [5:0] */
if ((bits & MVPP2_PRS_FLOW_ID_MASK) == flow)
- return pe;
+ return tid;
}
- kfree(pe);
- return NULL;
+ return -ENOENT;
}
/* Return first free tcam index, seeking from start to end */
@@ -2189,16 +2183,12 @@ static void mvpp2_prs_dsa_tag_ethertype_set(struct mvpp2 *priv, int port,
}
/* Search for existing single/triple vlan entry */
-static struct mvpp2_prs_entry *mvpp2_prs_vlan_find(struct mvpp2 *priv,
- unsigned short tpid, int ai)
+static int mvpp2_prs_vlan_find(struct mvpp2 *priv, unsigned short tpid, int ai)
{
- struct mvpp2_prs_entry *pe;
+ struct mvpp2_prs_entry pe;
int tid;
- pe = kzalloc(sizeof(*pe), GFP_KERNEL);
- if (!pe)
- return NULL;
- mvpp2_prs_tcam_lu_set(pe, MVPP2_PRS_LU_VLAN);
+ memset(&pe, 0, sizeof(pe));
/* Go through the all entries with MVPP2_PRS_LU_VLAN */
for (tid = MVPP2_PE_FIRST_FREE_TID;
@@ -2210,19 +2200,19 @@ static struct mvpp2_prs_entry *mvpp2_prs_vlan_find(struct mvpp2 *priv,
priv->prs_shadow[tid].lu != MVPP2_PRS_LU_VLAN)
continue;
- pe->index = tid;
+ pe.index = tid;
- mvpp2_prs_hw_read(priv, pe);
- match = mvpp2_prs_tcam_data_cmp(pe, 0, swab16(tpid));
+ mvpp2_prs_hw_read(priv, &pe);
+ match = mvpp2_prs_tcam_data_cmp(&pe, 0, swab16(tpid));
if (!match)
continue;
/* Get vlan type */
- ri_bits = mvpp2_prs_sram_ri_get(pe);
+ ri_bits = mvpp2_prs_sram_ri_get(&pe);
ri_bits &= MVPP2_PRS_RI_VLAN_MASK;
/* Get current ai value from tcam */
- ai_bits = mvpp2_prs_tcam_ai_get(pe);
+ ai_bits = mvpp2_prs_tcam_ai_get(&pe);
/* Clear double vlan bit */
ai_bits &= ~MVPP2_PRS_DBL_VLAN_AI_BIT;
@@ -2231,33 +2221,30 @@ static struct mvpp2_prs_entry *mvpp2_prs_vlan_find(struct mvpp2 *priv,
if (ri_bits == MVPP2_PRS_RI_VLAN_SINGLE ||
ri_bits == MVPP2_PRS_RI_VLAN_TRIPLE)
- return pe;
+ return tid;
}
- kfree(pe);
- return NULL;
+ return -ENOENT;
}
/* Add/update single/triple vlan entry */
static int mvpp2_prs_vlan_add(struct mvpp2 *priv, unsigned short tpid, int ai,
unsigned int port_map)
{
- struct mvpp2_prs_entry *pe;
+ struct mvpp2_prs_entry pe;
int tid_aux, tid;
int ret = 0;
- pe = mvpp2_prs_vlan_find(priv, tpid, ai);
+ tid = mvpp2_prs_vlan_find(priv, tpid, ai);
- if (!pe) {
+ if (tid < 0) {
/* Create new tcam entry */
tid = mvpp2_prs_tcam_first_free(priv, MVPP2_PE_LAST_FREE_TID,
MVPP2_PE_FIRST_FREE_TID);
if (tid < 0)
return tid;
- pe = kzalloc(sizeof(*pe), GFP_KERNEL);
- if (!pe)
- return -ENOMEM;
+ memset(&pe, 0, sizeof(pe));
/* Get last double vlan tid */
for (tid_aux = MVPP2_PE_LAST_FREE_TID;
@@ -2268,49 +2255,47 @@ static int mvpp2_prs_vlan_add(struct mvpp2 *priv, unsigned short tpid, int ai,
priv->prs_shadow[tid_aux].lu != MVPP2_PRS_LU_VLAN)
continue;
- pe->index = tid_aux;
- mvpp2_prs_hw_read(priv, pe);
- ri_bits = mvpp2_prs_sram_ri_get(pe);
+ pe.index = tid_aux;
+ mvpp2_prs_hw_read(priv, &pe);
+ ri_bits = mvpp2_prs_sram_ri_get(&pe);
if ((ri_bits & MVPP2_PRS_RI_VLAN_MASK) ==
MVPP2_PRS_RI_VLAN_DOUBLE)
break;
}
- if (tid <= tid_aux) {
- ret = -EINVAL;
- goto free_pe;
- }
+ if (tid <= tid_aux)
+ return -EINVAL;
- memset(pe, 0, sizeof(*pe));
- mvpp2_prs_tcam_lu_set(pe, MVPP2_PRS_LU_VLAN);
- pe->index = tid;
+ memset(&pe, 0, sizeof(pe));
+ mvpp2_prs_tcam_lu_set(&pe, MVPP2_PRS_LU_VLAN);
+ pe.index = tid;
- mvpp2_prs_match_etype(pe, 0, tpid);
+ mvpp2_prs_match_etype(&pe, 0, tpid);
/* VLAN tag detected, proceed with VID filtering */
- mvpp2_prs_sram_next_lu_set(pe, MVPP2_PRS_LU_VID);
+ mvpp2_prs_sram_next_lu_set(&pe, MVPP2_PRS_LU_VID);
/* Clear all ai bits for next iteration */
- mvpp2_prs_sram_ai_update(pe, 0, MVPP2_PRS_SRAM_AI_MASK);
+ mvpp2_prs_sram_ai_update(&pe, 0, MVPP2_PRS_SRAM_AI_MASK);
if (ai == MVPP2_PRS_SINGLE_VLAN_AI) {
- mvpp2_prs_sram_ri_update(pe, MVPP2_PRS_RI_VLAN_SINGLE,
+ mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_VLAN_SINGLE,
MVPP2_PRS_RI_VLAN_MASK);
} else {
ai |= MVPP2_PRS_DBL_VLAN_AI_BIT;
- mvpp2_prs_sram_ri_update(pe, MVPP2_PRS_RI_VLAN_TRIPLE,
+ mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_VLAN_TRIPLE,
MVPP2_PRS_RI_VLAN_MASK);
}
- mvpp2_prs_tcam_ai_update(pe, ai, MVPP2_PRS_SRAM_AI_MASK);
+ mvpp2_prs_tcam_ai_update(&pe, ai, MVPP2_PRS_SRAM_AI_MASK);
- mvpp2_prs_shadow_set(priv, pe->index, MVPP2_PRS_LU_VLAN);
+ mvpp2_prs_shadow_set(priv, pe.index, MVPP2_PRS_LU_VLAN);
+ } else {
+ mvpp2_prs_hw_read(priv, &pe);
}
/* Update ports' mask */
- mvpp2_prs_tcam_port_map_set(pe, port_map);
+ mvpp2_prs_tcam_port_map_set(&pe, port_map);
- mvpp2_prs_hw_write(priv, pe);
-free_pe:
- kfree(pe);
+ mvpp2_prs_hw_write(priv, &pe);
return ret;
}
@@ -2329,17 +2314,14 @@ static int mvpp2_prs_double_vlan_ai_free_get(struct mvpp2 *priv)
}
/* Search for existing double vlan entry */
-static struct mvpp2_prs_entry *mvpp2_prs_double_vlan_find(struct mvpp2 *priv,
- unsigned short tpid1,
- unsigned short tpid2)
+static int mvpp2_prs_double_vlan_find(struct mvpp2 *priv, unsigned short tpid1,
+ unsigned short tpid2)
{
- struct mvpp2_prs_entry *pe;
+ struct mvpp2_prs_entry pe;
int tid;
- pe = kzalloc(sizeof(*pe), GFP_KERNEL);
- if (!pe)
- return NULL;
- mvpp2_prs_tcam_lu_set(pe, MVPP2_PRS_LU_VLAN);
+ memset(&pe, 0, sizeof(pe));
+ mvpp2_prs_tcam_lu_set(&pe, MVPP2_PRS_LU_VLAN);
/* Go through the all entries with MVPP2_PRS_LU_VLAN */
for (tid = MVPP2_PE_FIRST_FREE_TID;
@@ -2351,22 +2333,21 @@ static struct mvpp2_prs_entry *mvpp2_prs_double_vlan_find(struct mvpp2 *priv,
priv->prs_shadow[tid].lu != MVPP2_PRS_LU_VLAN)
continue;
- pe->index = tid;
- mvpp2_prs_hw_read(priv, pe);
+ pe.index = tid;
+ mvpp2_prs_hw_read(priv, &pe);
- match = mvpp2_prs_tcam_data_cmp(pe, 0, swab16(tpid1))
- && mvpp2_prs_tcam_data_cmp(pe, 4, swab16(tpid2));
+ match = mvpp2_prs_tcam_data_cmp(&pe, 0, swab16(tpid1)) &&
+ mvpp2_prs_tcam_data_cmp(&pe, 4, swab16(tpid2));
if (!match)
continue;
- ri_mask = mvpp2_prs_sram_ri_get(pe) & MVPP2_PRS_RI_VLAN_MASK;
+ ri_mask = mvpp2_prs_sram_ri_get(&pe) & MVPP2_PRS_RI_VLAN_MASK;
if (ri_mask == MVPP2_PRS_RI_VLAN_DOUBLE)
- return pe;
+ return tid;
}
- kfree(pe);
- return NULL;
+ return -ENOENT;
}
/* Add or update double vlan entry */
@@ -2374,28 +2355,24 @@ static int mvpp2_prs_double_vlan_add(struct mvpp2 *priv, unsigned short tpid1,
unsigned short tpid2,
unsigned int port_map)
{
- struct mvpp2_prs_entry *pe;
+ struct mvpp2_prs_entry pe;
int tid_aux, tid, ai, ret = 0;
- pe = mvpp2_prs_double_vlan_find(priv, tpid1, tpid2);
+ tid = mvpp2_prs_double_vlan_find(priv, tpid1, tpid2);
- if (!pe) {
+ if (tid < 0) {
/* Create new tcam entry */
tid = mvpp2_prs_tcam_first_free(priv, MVPP2_PE_FIRST_FREE_TID,
MVPP2_PE_LAST_FREE_TID);
if (tid < 0)
return tid;
- pe = kzalloc(sizeof(*pe), GFP_KERNEL);
- if (!pe)
- return -ENOMEM;
+ memset(&pe, 0, sizeof(pe));
/* Set ai value for new double vlan entry */
ai = mvpp2_prs_double_vlan_ai_free_get(priv);
- if (ai < 0) {
- ret = ai;
- goto free_pe;
- }
+ if (ai < 0)
+ return ai;
/* Get first single/triple vlan tid */
for (tid_aux = MVPP2_PE_FIRST_FREE_TID;
@@ -2406,9 +2383,9 @@ static int mvpp2_prs_double_vlan_add(struct mvpp2 *priv, unsigned short tpid1,
priv->prs_shadow[tid_aux].lu != MVPP2_PRS_LU_VLAN)
continue;
- pe->index = tid_aux;
- mvpp2_prs_hw_read(priv, pe);
- ri_bits = mvpp2_prs_sram_ri_get(pe);
+ pe.index = tid_aux;
+ mvpp2_prs_hw_read(priv, &pe);
+ ri_bits = mvpp2_prs_sram_ri_get(&pe);
ri_bits &= MVPP2_PRS_RI_VLAN_MASK;
if (ri_bits == MVPP2_PRS_RI_VLAN_SINGLE ||
ri_bits == MVPP2_PRS_RI_VLAN_TRIPLE)
@@ -2416,36 +2393,36 @@ static int mvpp2_prs_double_vlan_add(struct mvpp2 *priv, unsigned short tpid1,
}
if (tid >= tid_aux) {
- ret = -ERANGE;
- goto free_pe;
+ return -ERANGE;
}
- memset(pe, 0, sizeof(*pe));
- mvpp2_prs_tcam_lu_set(pe, MVPP2_PRS_LU_VLAN);
- pe->index = tid;
+ memset(&pe, 0, sizeof(pe));
+ mvpp2_prs_tcam_lu_set(&pe, MVPP2_PRS_LU_VLAN);
+ pe.index = tid;
priv->prs_double_vlans[ai] = true;
- mvpp2_prs_match_etype(pe, 0, tpid1);
- mvpp2_prs_match_etype(pe, 4, tpid2);
+ mvpp2_prs_match_etype(&pe, 0, tpid1);
+ mvpp2_prs_match_etype(&pe, 4, tpid2);
- mvpp2_prs_sram_next_lu_set(pe, MVPP2_PRS_LU_VLAN);
+ mvpp2_prs_sram_next_lu_set(&pe, MVPP2_PRS_LU_VLAN);
/* Shift 4 bytes - skip outer vlan tag */
- mvpp2_prs_sram_shift_set(pe, MVPP2_VLAN_TAG_LEN,
+ mvpp2_prs_sram_shift_set(&pe, MVPP2_VLAN_TAG_LEN,
MVPP2_PRS_SRAM_OP_SEL_SHIFT_ADD);
- mvpp2_prs_sram_ri_update(pe, MVPP2_PRS_RI_VLAN_DOUBLE,
+ mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_VLAN_DOUBLE,
MVPP2_PRS_RI_VLAN_MASK);
- mvpp2_prs_sram_ai_update(pe, ai | MVPP2_PRS_DBL_VLAN_AI_BIT,
+ mvpp2_prs_sram_ai_update(&pe, ai | MVPP2_PRS_DBL_VLAN_AI_BIT,
MVPP2_PRS_SRAM_AI_MASK);
- mvpp2_prs_shadow_set(priv, pe->index, MVPP2_PRS_LU_VLAN);
+ mvpp2_prs_shadow_set(priv, pe.index, MVPP2_PRS_LU_VLAN);
+ } else {
+ mvpp2_prs_hw_read(priv, &pe);
}
/* Update ports' mask */
- mvpp2_prs_tcam_port_map_set(pe, port_map);
- mvpp2_prs_hw_write(priv, pe);
-free_pe:
- kfree(pe);
+ mvpp2_prs_tcam_port_map_set(&pe, port_map);
+ mvpp2_prs_hw_write(priv, &pe);
+
return ret;
}
@@ -3528,7 +3505,7 @@ static int mvpp2_prs_vid_range_find(struct mvpp2 *priv, int pmap, u16 vid,
return tid;
}
- return 0;
+ return -ENOENT;
}
/* Write parser entry for VID filtering */
@@ -3551,7 +3528,7 @@ static int mvpp2_prs_vid_entry_add(struct mvpp2_port *port, u16 vid)
shift = MVPP2_VLAN_TAG_LEN;
/* No such entry */
- if (!tid) {
+ if (tid < 0) {
memset(&pe, 0, sizeof(pe));
/* Go through all entries from first to last in vlan range */
@@ -3604,7 +3581,7 @@ static void mvpp2_prs_vid_entry_remove(struct mvpp2_port *port, u16 vid)
tid = mvpp2_prs_vid_range_find(priv, (1 << port->id), vid, 0xfff);
/* No such entry */
- if (tid)
+ if (tid < 0)
return;
mvpp2_prs_hw_inv(priv, tid);
@@ -3771,18 +3748,13 @@ static bool mvpp2_prs_mac_range_equals(struct mvpp2_prs_entry *pe,
}
/* Find tcam entry with matched pair <MAC DA, port> */
-static struct mvpp2_prs_entry *
+static int
mvpp2_prs_mac_da_range_find(struct mvpp2 *priv, int pmap, const u8 *da,
unsigned char *mask, int udf_type)
{
- struct mvpp2_prs_entry *pe;
+ struct mvpp2_prs_entry pe;
int tid;
- pe = kzalloc(sizeof(*pe), GFP_ATOMIC);
- if (!pe)
- return NULL;
- mvpp2_prs_tcam_lu_set(pe, MVPP2_PRS_LU_MAC);
-
/* Go through the all entires with MVPP2_PRS_LU_MAC */
for (tid = MVPP2_PE_MAC_RANGE_START;
tid <= MVPP2_PE_MAC_RANGE_END; tid++) {
@@ -3793,17 +3765,16 @@ mvpp2_prs_mac_da_range_find(struct mvpp2 *priv, int pmap, const u8 *da,
(priv->prs_shadow[tid].udf != udf_type))
continue;
- pe->index = tid;
- mvpp2_prs_hw_read(priv, pe);
- entry_pmap = mvpp2_prs_tcam_port_map_get(pe);
+ pe.index = tid;
+ mvpp2_prs_hw_read(priv, &pe);
+ entry_pmap = mvpp2_prs_tcam_port_map_get(&pe);
- if (mvpp2_prs_mac_range_equals(pe, da, mask) &&
+ if (mvpp2_prs_mac_range_equals(&pe, da, mask) &&
entry_pmap == pmap)
- return pe;
+ return tid;
}
- kfree(pe);
- return NULL;
+ return -ENOENT;
}
/* Update parser's mac da entry */
@@ -3813,15 +3784,15 @@ static int mvpp2_prs_mac_da_accept(struct mvpp2_port *port, const u8 *da,
unsigned char mask[ETH_ALEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
struct mvpp2 *priv = port->priv;
unsigned int pmap, len, ri;
- struct mvpp2_prs_entry *pe;
+ struct mvpp2_prs_entry pe;
int tid;
/* Scan TCAM and see if entry with this <MAC DA, port> already exist */
- pe = mvpp2_prs_mac_da_range_find(priv, BIT(port->id), da, mask,
- MVPP2_PRS_UDF_MAC_DEF);
+ tid = mvpp2_prs_mac_da_range_find(priv, BIT(port->id), da, mask,
+ MVPP2_PRS_UDF_MAC_DEF);
/* No such entry */
- if (!pe) {
+ if (tid < 0) {
if (!add)
return 0;
@@ -3833,39 +3804,39 @@ static int mvpp2_prs_mac_da_accept(struct mvpp2_port *port, const u8 *da,
if (tid < 0)
return tid;
- pe = kzalloc(sizeof(*pe), GFP_ATOMIC);
- if (!pe)
- return -ENOMEM;
- mvpp2_prs_tcam_lu_set(pe, MVPP2_PRS_LU_MAC);
- pe->index = tid;
+ memset(&pe, 0, sizeof(pe));
+
+ pe.index = tid;
/* Mask all ports */
- mvpp2_prs_tcam_port_map_set(pe, 0);
+ mvpp2_prs_tcam_port_map_set(&pe, 0);
+ } else {
+ mvpp2_prs_hw_read(priv, &pe);
}
+ mvpp2_prs_tcam_lu_set(&pe, MVPP2_PRS_LU_MAC);
+
/* Update port mask */
- mvpp2_prs_tcam_port_set(pe, port->id, add);
+ mvpp2_prs_tcam_port_set(&pe, port->id, add);
/* Invalidate the entry if no ports are left enabled */
- pmap = mvpp2_prs_tcam_port_map_get(pe);
+ pmap = mvpp2_prs_tcam_port_map_get(&pe);
if (pmap == 0) {
if (add) {
- kfree(pe);
return -EINVAL;
}
- mvpp2_prs_hw_inv(priv, pe->index);
- priv->prs_shadow[pe->index].valid = false;
- kfree(pe);
+ mvpp2_prs_hw_inv(priv, pe.index);
+ priv->prs_shadow[pe.index].valid = false;
return 0;
}
/* Continue - set next lookup */
- mvpp2_prs_sram_next_lu_set(pe, MVPP2_PRS_LU_DSA);
+ mvpp2_prs_sram_next_lu_set(&pe, MVPP2_PRS_LU_DSA);
/* Set match on DA */
len = ETH_ALEN;
while (len--)
- mvpp2_prs_tcam_data_byte_set(pe, len, da[len], 0xff);
+ mvpp2_prs_tcam_data_byte_set(&pe, len, da[len], 0xff);
/* Set result info bits */
if (is_broadcast_ether_addr(da)) {
@@ -3879,21 +3850,19 @@ static int mvpp2_prs_mac_da_accept(struct mvpp2_port *port, const u8 *da,
ri |= MVPP2_PRS_RI_MAC_ME_MASK;
}
- mvpp2_prs_sram_ri_update(pe, ri, MVPP2_PRS_RI_L2_CAST_MASK |
+ mvpp2_prs_sram_ri_update(&pe, ri, MVPP2_PRS_RI_L2_CAST_MASK |
MVPP2_PRS_RI_MAC_ME_MASK);
- mvpp2_prs_shadow_ri_set(priv, pe->index, ri, MVPP2_PRS_RI_L2_CAST_MASK |
+ mvpp2_prs_shadow_ri_set(priv, pe.index, ri, MVPP2_PRS_RI_L2_CAST_MASK |
MVPP2_PRS_RI_MAC_ME_MASK);
/* Shift to ethertype */
- mvpp2_prs_sram_shift_set(pe, 2 * ETH_ALEN,
+ mvpp2_prs_sram_shift_set(&pe, 2 * ETH_ALEN,
MVPP2_PRS_SRAM_OP_SEL_SHIFT_ADD);
/* Update shadow table and hw entry */
- priv->prs_shadow[pe->index].udf = MVPP2_PRS_UDF_MAC_DEF;
- mvpp2_prs_shadow_set(priv, pe->index, MVPP2_PRS_LU_MAC);
- mvpp2_prs_hw_write(priv, pe);
-
- kfree(pe);
+ priv->prs_shadow[pe.index].udf = MVPP2_PRS_UDF_MAC_DEF;
+ mvpp2_prs_shadow_set(priv, pe.index, MVPP2_PRS_LU_MAC);
+ mvpp2_prs_hw_write(priv, &pe);
return 0;
}
@@ -4014,13 +3983,13 @@ static int mvpp2_prs_tag_mode_set(struct mvpp2 *priv, int port, int type)
/* Set prs flow for the port */
static int mvpp2_prs_def_flow(struct mvpp2_port *port)
{
- struct mvpp2_prs_entry *pe;
+ struct mvpp2_prs_entry pe;
int tid;
- pe = mvpp2_prs_flow_find(port->priv, port->id);
+ tid = mvpp2_prs_flow_find(port->priv, port->id);
/* Such entry not exist */
- if (!pe) {
+ if (tid < 0) {
/* Go through the all entires from last to first */
tid = mvpp2_prs_tcam_first_free(port->priv,
MVPP2_PE_LAST_FREE_TID,
@@ -4028,24 +3997,21 @@ static int mvpp2_prs_def_flow(struct mvpp2_port *port)
if (tid < 0)
return tid;
- pe = kzalloc(sizeof(*pe), GFP_KERNEL);
- if (!pe)
- return -ENOMEM;
-
- mvpp2_prs_tcam_lu_set(pe, MVPP2_PRS_LU_FLOWS);
- pe->index = tid;
+ pe.index = tid;
/* Set flow ID*/
- mvpp2_prs_sram_ai_update(pe, port->id, MVPP2_PRS_FLOW_ID_MASK);
- mvpp2_prs_sram_bits_set(pe, MVPP2_PRS_SRAM_LU_DONE_BIT, 1);
+ mvpp2_prs_sram_ai_update(&pe, port->id, MVPP2_PRS_FLOW_ID_MASK);
+ mvpp2_prs_sram_bits_set(&pe, MVPP2_PRS_SRAM_LU_DONE_BIT, 1);
/* Update shadow table */
- mvpp2_prs_shadow_set(port->priv, pe->index, MVPP2_PRS_LU_FLOWS);
+ mvpp2_prs_shadow_set(port->priv, pe.index, MVPP2_PRS_LU_FLOWS);
+ } else {
+ mvpp2_prs_hw_read(port->priv, &pe);
}
- mvpp2_prs_tcam_port_map_set(pe, (1 << port->id));
- mvpp2_prs_hw_write(port->priv, pe);
- kfree(pe);
+ mvpp2_prs_tcam_lu_set(&pe, MVPP2_PRS_LU_FLOWS);
+ mvpp2_prs_tcam_port_map_set(&pe, (1 << port->id));
+ mvpp2_prs_hw_write(port->priv, &pe);
return 0;
}
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 08/36] aio: implement io_pgetevents
From: Christoph Hellwig @ 2018-03-20 15:31 UTC (permalink / raw)
To: Jeff Moyer
Cc: Christoph Hellwig, Darrick J. Wong, viro, Avi Kivity, linux-aio,
linux-fsdevel, netdev, linux-api, linux-kernel
In-Reply-To: <x49muz2pxwq.fsf@segfault.boston.devel.redhat.com>
On Tue, Mar 20, 2018 at 11:30:29AM -0400, Jeff Moyer wrote:
> > In this commit:
> >
> > http://git.infradead.org/users/hch/libaio.git/commitdiff/49f77d595210393ce7b125cb00233cf737402f56
>
> BTW, the man pages are shipped in the man-pages package, now.
> Christoph, I can forward the change to Michael after this series goes
> in. Just let me know what's easiest for you.
I'd be more than happy to send patch to Michael if we get these
patches merged finally :)
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [PATCH 08/36] aio: implement io_pgetevents
From: Jeff Moyer @ 2018-03-20 15:30 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Darrick J. Wong, viro, Avi Kivity, linux-aio, linux-fsdevel,
netdev, linux-api, linux-kernel
In-Reply-To: <20180320152220.GC23920@lst.de>
Christoph Hellwig <hch@lst.de> writes:
> On Mon, Mar 19, 2018 at 07:12:41PM -0700, Darrick J. Wong wrote:
>> > Note that unlike many other signal related calls we do not pass a sigmask
>> > size, as that would get us to 7 arguments, which aren't easily supported
>> > by the syscall infrastructure. It seems a lot less painful to just add a
>> > new syscall variant in the unlikely case we're going to increase the
>> > sigset size.
>>
>> I'm assuming there's a proposed manpage update for this somewhere? :)
>
> In this commit:
>
> http://git.infradead.org/users/hch/libaio.git/commitdiff/49f77d595210393ce7b125cb00233cf737402f56
BTW, the man pages are shipped in the man-pages package, now.
Christoph, I can forward the change to Michael after this series goes
in. Just let me know what's easiest for you.
Cheers,
Jeff
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [PATCH iproute2 net-next] bridge: add option extern_learn to set NTF_EXT_LEARNED on fdb entries
From: David Ahern @ 2018-03-20 15:30 UTC (permalink / raw)
To: Roopa Prabhu; +Cc: Stephen Hemminger, netdev, Nikolay Aleksandrov
In-Reply-To: <CAJieiUi39DnWpqpu_Y38uBvB8zGEZv23AkwVxoefJQ+nFX7zLg@mail.gmail.com>
On 3/19/18 12:05 PM, Roopa Prabhu wrote:
> On Mon, Mar 19, 2018 at 10:56 AM, David Ahern <dsahern@gmail.com> wrote:
>> On 3/19/18 11:54 AM, Stephen Hemminger wrote:
>>> On Mon, 19 Mar 2018 10:20:10 -0700
>>> Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
>>>
>>>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>>>
>>>> NTF_EXT_LEARNED can be set by a user on bridge fdb entry.
>>>> Provide a bridge command option to allow a user to set
>>>> NTF_EXT_LEARNED on a bridge fdb entry.
>>>>
>>>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>>>> ---
>>>> bridge/fdb.c | 4 +++-
>>>> man/man8/bridge.8 | 8 +++++++-
>>>> 2 files changed, 10 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/bridge/fdb.c b/bridge/fdb.c
>>>> index 205b4fa..4dbc894 100644
>>>> --- a/bridge/fdb.c
>>>> +++ b/bridge/fdb.c
>>>> @@ -36,7 +36,7 @@ static void usage(void)
>>>> {
>>>> fprintf(stderr,
>>>> "Usage: bridge fdb { add | append | del | replace } ADDR dev DEV\n"
>>>> - " [ self ] [ master ] [ use ] [ router ]\n"
>>>> + " [ self ] [ master ] [ use ] [ router ] [ extern_learn ]\n"
>>>> " [ local | static | dynamic ] [ dst IPADDR ] [ vlan VID ]\n"
>>>> " [ port PORT] [ vni VNI ] [ via DEV ]\n"
>>>> " bridge fdb [ show [ br BRDEV ] [ brport DEV ] [ vlan VID ] [ state STATE ] ]\n");
>>>> @@ -412,6 +412,8 @@ static int fdb_modify(int cmd, int flags, int argc, char **argv)
>>>> vid = atoi(*argv);
>>>> } else if (matches(*argv, "use") == 0) {
>>>> req.ndm.ndm_flags |= NTF_USE;
>>>> + } else if (matches(*argv, "extern_learn") == 0) {
>>>> + req.ndm.ndm_flags |= NTF_EXT_LEARNED;
>>>> } else {
>>>> if (strcmp(*argv, "to") == 0)
>>>> NEXT_ARG();
>>>> diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
>>>> index 05512b0..e7f7148 100644
>>>> --- a/man/man8/bridge.8
>>>> +++ b/man/man8/bridge.8
>>>> @@ -61,7 +61,7 @@ bridge \- show / manipulate bridge addresses and devices
>>>> .B dev
>>>> .IR DEV " { "
>>>> .BR local " | " static " | " dynamic " } [ "
>>>> -.BR self " ] [ " master " ] [ " router " ] [ " use " ] [ "
>>>> +.BR self " ] [ " master " ] [ " router " ] [ " use " ] [ " extern_learn " ] [ "
>>>> .B dst
>>>> .IR IPADDR " ] [ "
>>>> .B vni
>>>> @@ -414,6 +414,12 @@ route shortcircuit enabled.
>>>> indicate to the kernel that the fdb entry is in use.
>>>> .sp
>>>>
>>>> +.B extern_learn
>>>> +- this entry was learned externally. This option can be used to
>>>> +indicate to the kernel that an entry was hardware or user-space
>>>> +controller learnt dynamic entry. Kernel will not age such an entry.
>>>> +.sp
>>>> +
>>>> .in -8
>>>> The next command line parameters apply only
>>>> when the specified device
>>>
>>>
>>> What about displaying the flag as well?
>>>
>>
>> Also, I believe other commands have converged on 'external' for the keyword.
>
>
> There is already code to display it and it displays it as
> 'extern_learn' (hence the choice of extern_learn)
>
> static void fdb_print_flags(FILE *fp, unsigned int flags)
>
> {
>
> ....
>
>
> if (flags & NTF_EXT_LEARNED)
>
> print_string(PRINT_ANY, NULL, "%s ", "extern_learn");
>
> ....
> }
>
ok. Applied to iproute2-next
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: dsa: Plug in PHYLINK support
From: David Miller @ 2018-03-20 15:28 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, privat, andrew, vivien.didelot, rmk+kernel, sean.wang,
Woojung.Huh, john, cphealy
In-Reply-To: <20180318185246.19311-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Sun, 18 Mar 2018 11:52:42 -0700
> This patch series adds PHYLINK support to DSA which is necessary to
> support more complex PHY and pluggable modules setups.
This series is kinda stuck in the mud because of the discussion about
putting a phylink reference into netdevice.
I think the only way to move forward is for Russell to submit his
patches again, that way we can see the requirements and discuss
them properly.
Thanks.
^ permalink raw reply
* Re: [PATCH 08/36] aio: implement io_pgetevents
From: Christoph Hellwig @ 2018-03-20 15:22 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Christoph Hellwig, viro, Avi Kivity, linux-aio, linux-fsdevel,
netdev, linux-api, linux-kernel
In-Reply-To: <20180320021241.GE7282@magnolia>
On Mon, Mar 19, 2018 at 07:12:41PM -0700, Darrick J. Wong wrote:
> > Note that unlike many other signal related calls we do not pass a sigmask
> > size, as that would get us to 7 arguments, which aren't easily supported
> > by the syscall infrastructure. It seems a lot less painful to just add a
> > new syscall variant in the unlikely case we're going to increase the
> > sigset size.
>
> I'm assuming there's a proposed manpage update for this somewhere? :)
In this commit:
http://git.infradead.org/users/hch/libaio.git/commitdiff/49f77d595210393ce7b125cb00233cf737402f56
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* RE: interdependencies with cxgb4 and iw_cxgb4
From: Steve Wise @ 2018-03-20 15:20 UTC (permalink / raw)
To: 'David Miller'
Cc: rajur, dledford, linux-rdma, jgg, netdev, bharat, ganeshgr,
rahul.lakkireddy
In-Reply-To: <20180320.111824.2214262102648467414.davem@davemloft.net>
>
> From: "Steve Wise" <swise@opengridcomputing.com>
> Date: Tue, 20 Mar 2018 10:08:44 -0500
>
> > For the maintainers, yes. But it avoids setting up k.o accounts and
> > git repos for each device driver maintainer that has this issue.
>
> I think this is quite a reasonable requirement for submitters wishing
> to make significant changes across two subsystems with complex
> interdependencies.
>
> It is critical to get the changes tested in both the RDMA and net-next
> tree contexts as early as possible, and to shake out any intergration
> issues (which happens transparently via linux-next).
>
> I know it's easy to see the personal "burdon" it causes you as an
> individual developer, but you really have to consider how much is
> in-flight and being dealt with by maintainers of very active
> subsystems like the networking.
>
> Thank you.
Fair enough. Thanks Dave.
^ permalink raw reply
* Re: [PATCH 07/36] aio: add delayed cancel support
From: Christoph Hellwig @ 2018-03-20 15:20 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Christoph Hellwig, viro, Avi Kivity, linux-aio, linux-fsdevel,
netdev, linux-api, linux-kernel
In-Reply-To: <20180320031957.GJ7282@magnolia>
On Mon, Mar 19, 2018 at 08:19:57PM -0700, Darrick J. Wong wrote:
> On Mon, Mar 05, 2018 at 01:27:14PM -0800, Christoph Hellwig wrote:
> > The upcoming aio poll support would like to be able to complete the
> > iocb inline from the cancellation context, but that would cause
> > a lock order reversal. Add support for optionally moving the cancelation
> > outside the context lock to avoid this reversal.
>
> I started to wonder which lock order reversal the commit message refers
> to?
>
> I think the reason for adding delayed cancellations is that we want to
> be able to call io_cancel -> kiocb_cancel -> aio_poll_cancel ->
> aio_complete without double locking ctx_lock?
It is. I've updated the commit message.
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [PATCH] mlx5: Remove call to ida_pre_get
From: Matthew Wilcox @ 2018-03-20 15:20 UTC (permalink / raw)
To: David Miller; +Cc: maorg, saeedm, matanb, netdev, linux-rdma, leon
In-Reply-To: <20180320.104620.1702410080256879438.davem@davemloft.net>
On Tue, Mar 20, 2018 at 10:46:20AM -0400, David Miller wrote:
> From: Maor Gottlieb <maorg@mellanox.com>
> Date: Tue, 20 Mar 2018 14:41:49 +0200
>
> > Saeed, Matan and I okay with this fix as well, it looks like it
> > shouldn't impact on the insertion rate.
>
> I've applied this to net-next, thanks everyone.
Thanks, Dave.
I realised why this made sense when it was originally written. Before
December 2016 (commit 7ad3d4d85c7a), ida_pre_get used to allocate one
bitmap per ida. I moved it to a percpu variable, and at that point this
stopped making sense.
^ permalink raw reply
* Re: interdependencies with cxgb4 and iw_cxgb4
From: David Miller @ 2018-03-20 15:18 UTC (permalink / raw)
To: swise
Cc: rajur, dledford, linux-rdma, jgg, netdev, bharat, ganeshgr,
rahul.lakkireddy
In-Reply-To: <3d6501d3c05d$571a28a0$054e79e0$@opengridcomputing.com>
From: "Steve Wise" <swise@opengridcomputing.com>
Date: Tue, 20 Mar 2018 10:08:44 -0500
> For the maintainers, yes. But it avoids setting up k.o accounts and
> git repos for each device driver maintainer that has this issue.
I think this is quite a reasonable requirement for submitters wishing
to make significant changes across two subsystems with complex
interdependencies.
It is critical to get the changes tested in both the RDMA and net-next
tree contexts as early as possible, and to shake out any intergration
issues (which happens transparently via linux-next).
I know it's easy to see the personal "burdon" it causes you as an
individual developer, but you really have to consider how much is
in-flight and being dealt with by maintainers of very active
subsystems like the networking.
Thank you.
^ permalink raw reply
* linux-next: ip6tables *broken* - last base chain position %u doesn't match underflow %u (hook %u
From: valdis.kletnieks @ 2018-03-20 15:17 UTC (permalink / raw)
To: Florian Westphal, Pablo Neira Ayuso; +Cc: netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2255 bytes --]
(Resending because I haven't heard anything)
Am hitting an issue with this commit:
commit 0d7df906a0e78079a02108b06d32c3ef2238ad25
Author: Florian Westphal <fw@strlen.de>
Date: Tue Feb 27 19:42:37 2018 +0100
netfilter: x_tables: ensure last rule in base chain matches underflow/policy
This trips on my system:
[ 64.402790] ip6_tables: last base chain position 1136 doesn't match underflow 1344 (hook 1)
More annoyingly, the return value means that ip6tables aren't initialized
so there's no firewall protection. (In other words, this:
If a (syzkaller generated) ruleset doesn't have the underflow/policy
stored as the last rule in the base chain, then iptables will abort()
because it doesn't find the chain policy.
ends up meaning iptables aborts anyhow.
My iptables isn't syzkaller generated - it's mostly crufty vi-generated. ;)
Messages generated as I tried to build smaller tables to narrow down the problem:
(not sure where it gets the numbers from, as I reduced it from 50 lines down to 3
and no real correlation to the tables I was trying to load - in particular the numbers
went up once and remained unchanged once, even though between each try I was
whacking out another 5-10 lines...)
[ 64.402790] ip6_tables: last base chain position 1136 doesn't match underflow 1344 (hook 1)
[ 1897.914828] ip6_tables: last base chain position 928 doesn't match underflow 1136 (hook 1)
[ 1954.032735] ip6_tables: last base chain position 720 doesn't match underflow 928 (hook 1)
[ 2021.813719] ip6_tables: last base chain position 920 doesn't match underflow 1128 (hook 1)
[ 2035.044103] ip6_tables: last base chain position 920 doesn't match underflow 1128 (hook 1)
[ 2060.594412] ip6_tables: last base chain position 616 doesn't match underflow 824 (hook 1)
I finally got /etc/sysconfig/ip6tables down to this:
# Generated by ip6tables-save v1.6.2 on Thu Mar 8 08:20:04 2018
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [208207395:46346275671]
[120166037:34218429901] -A INPUT -i lo+ -j ACCEPT
[129329499:129691207309] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[0:0] -A INPUT -j DROP
COMMIT
# Completed on Thu Mar 8 08:20:04 2018
About as minimal as it can get. :)
Any ideas?
[-- Attachment #2: Type: application/pgp-signature, Size: 486 bytes --]
^ permalink raw reply
* RE: [RFC PATCH 0/3] kernel: add support for 256-bit IO access
From: David Laight @ 2018-03-20 15:10 UTC (permalink / raw)
To: 'Andy Lutomirski', Ingo Molnar
Cc: Thomas Gleixner, Rahul Lakkireddy, x86@kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
mingo@redhat.com, hpa@zytor.com, davem@davemloft.net,
akpm@linux-foundation.org, torvalds@linux-foundation.org,
ganeshgr@chelsio.com, nirranjan@chelsio.com, indranil@chelsio.com,
Peter Zijlstra, Fenghua Yu, Eric Biggers, Rik van Riel
In-Reply-To: <CALCETrVMF140-XZLi9nARPeAmyi8QRRzLRm6SSpB0BkAUSGakg@mail.gmail.com>
From: Andy Lutomirski
> Sent: 20 March 2018 14:57
...
> I'd rather see us finally finish the work that Rik started to rework
> this differently. I'd like kernel_fpu_begin() to look like:
>
> if (test_thread_flag(TIF_NEED_FPU_RESTORE)) {
> return; // we're already okay. maybe we need to check
> in_interrupt() or something, though?
> } else {
> XSAVES/XSAVEOPT/XSAVE;
> set_thread_flag(TIF_NEED_FPU_RESTORE):
> }
>
> and kernel_fpu_end() does nothing at all.
I guess it might need to set (clear?) the CFLAGS bit for a process
that isn't using the fpu at all - which seems a sensible feature.
> We take the full performance hit for a *single* kernel_fpu_begin() on
> an otherwise short syscall or interrupt, but there's no additional
> cost for more of them or for long-enough-running things that we
> schedule in the middle.
It might be worth adding a parameter to kernel_fpu_begin() to indicate
which registers are needed, and a return value to say what has been
granted.
Then a driver could request AVX2 (for example) and use a fallback path
if the register set isn't available (for any reason).
A call from an ISR could always fail.
> As I remember, the main hangup was that this interacts a bit oddly
> with PKRU, but that's manageable.
WTF PKRU ??
Dvaid
^ permalink raw reply
* RE: interdependencies with cxgb4 and iw_cxgb4
From: Steve Wise @ 2018-03-20 15:08 UTC (permalink / raw)
To: 'David Miller'
Cc: rajur, dledford, linux-rdma, jgg, netdev, bharat, ganeshgr,
rahul.lakkireddy
In-Reply-To: <20180320.104046.957152577341740274.davem@davemloft.net>
> >> > Let me ask a dumb question:� Why cannot one of the maintaners pull
> the
> >> > commit from the other mainainer's git repo directly?� IE why have
this
> >> > third trusted/signed git repo that has to be on k.o, from which both
> >> > maintainers pull?� If one of you can pull it in via a patch series,
> >> > like you do for all other patches, and then notify the other
> >> > maintainer to pull it from the first maintainers' repo if the series
> >> > meets the requirements that it needs to be in both maintainers'
> >> > repositories?� This avoids adding more staging git repos on k.o.� But
> >> > probably I'm missing something...
> >>
> >> Tree A may not want all of tree B's changes, and vice versa.
> >
> > I was thinking the special commit would go into a branch that was based
> on,
> > say rc1 or rc2 of one of the maintainers. Then both maintainers pull
that
> > into their -next branch. Would that work?
>
> That makes things more complicated.
For the maintainers, yes. But it avoids setting up k.o accounts and git
repos for each device driver maintainer that has this issue.
>
> The simplest design is that "identical" commits end up in both the
> RDMA and the net-next tree.
>
> Then it absolutely doesn't matter whose tree goes into Linus's first.
>
Yes, and that would still be the case, from my understanding: Instead of
each driver having a k.o. signed git repo, we ask the maintainers to stage
this common branch that both maintainers pull from into their -next
branches/repos.
> Also, we should not be merging "merge window" code after -rc1. "-rc1"
> means the merge window is closed.
I meant using rc-1 for the current release when submitting these shared
commits for the _following merge window_.
Steve.
^ permalink raw reply
* Re: [PATCH net] ipv6: sr: fix scheduling in RCU when creating seg6 lwtunnel state
From: Eric Dumazet @ 2018-03-20 15:07 UTC (permalink / raw)
To: David Lebrun, netdev; +Cc: David Lebrun
In-Reply-To: <20180320144456.223556-1-dav.lebrun@gmail.com>
On 03/20/2018 07:44 AM, David Lebrun wrote:
> From: David Lebrun <dlebrun@google.com>
>
> The seg6_build_state() function is called with RCU read lock held,
> so we cannot use GFP_KERNEL. This patch uses GFP_ATOMIC instead.
>
>
> Fixes: 6c8702c60b886 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
> Signed-off-by: David Lebrun <dlebrun@google.com>
> ---
> net/ipv6/seg6_iptunnel.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c
> index bd6cc688bd19..8367b859a934 100644
> --- a/net/ipv6/seg6_iptunnel.c
> +++ b/net/ipv6/seg6_iptunnel.c
> @@ -418,7 +418,7 @@ static int seg6_build_state(struct nlattr *nla,
>
> slwt = seg6_lwt_lwtunnel(newts);
>
> - err = dst_cache_init(&slwt->cache, GFP_KERNEL);
> + err = dst_cache_init(&slwt->cache, GFP_ATOMIC);
>
This is not the proper fix.
Control path holds RTNL and can sleeep if needed.
RCU should be avoided in lwtunnel_build_state()
^ permalink raw reply
* Re: [PATCH net] devlink: Remove redundant free on error path
From: David Miller @ 2018-03-20 15:00 UTC (permalink / raw)
To: arkadis; +Cc: netdev, mlxsw, jiri
In-Reply-To: <1521387442-31494-1-git-send-email-arkadis@mellanox.com>
From: Arkadi Sharshevsky <arkadis@mellanox.com>
Date: Sun, 18 Mar 2018 17:37:22 +0200
> The current code performs unneeded free. Remove the redundant skb freeing
> during the error path.
>
> Fixes: 1555d204e743 ("devlink: Support for pipeline debug (dpipe)")
> Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
Applied and queued up for -stable, thank you.
^ permalink raw reply
* Re: [PATCH] vmxnet3: fix LRO feature check
From: David Miller @ 2018-03-20 14:57 UTC (permalink / raw)
To: lkp; +Cc: ipylypiv, kbuild-all, skhare, pv-drivers, netdev
In-Reply-To: <201803181411.VTfldbIf%fengguang.wu@intel.com>
From: kbuild test robot <lkp@intel.com>
Date: Sun, 18 Mar 2018 14:37:35 +0800
> All warnings (new ones prefixed by >>):
>
> drivers/net/vmxnet3/vmxnet3_drv.c: In function 'vmxnet3_rq_rx_complete':
>>> drivers/net/vmxnet3/vmxnet3_drv.c:1474:8: warning: suggest parentheses around operand of '!' or change '&' to '&&' or '!' to '~' [-Wparentheses]
> !adapter->netdev->features & NETIF_F_LRO) {
> ^~~~~~~~~~~~~~~~~~~~~~~~~~
Igor, I will fix this up for you. But it is clear that this patch wasn't tested
very well.
Because !adapter->netdev->features evaluates wholly before the "& NETIF_F_LRO",
the flags aren't being tested properly at all.
^ permalink raw reply
* Re: [RFC PATCH 0/3] kernel: add support for 256-bit IO access
From: Andy Lutomirski @ 2018-03-20 14:57 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, David Laight, Rahul Lakkireddy, x86@kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
mingo@redhat.com, hpa@zytor.com, davem@davemloft.net,
akpm@linux-foundation.org, torvalds@linux-foundation.org,
ganeshgr@chelsio.com, nirranjan@chelsio.com, indranil@chelsio.com,
Andy Lutomirski, Peter Zijlstra, Fenghua Yu
In-Reply-To: <20180320082651.jmxvvii2xvmpyr2s@gmail.com>
On Tue, Mar 20, 2018 at 8:26 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Thomas Gleixner <tglx@linutronix.de> wrote:
>
>> > Useful also for code that needs AVX-like registers to do things like CRCs.
>>
>> x86/crypto/ has a lot of AVX optimized code.
>
> Yeah, that's true, but the crypto code is processing fundamentally bigger blocks
> of data, which amortizes the cost of using kernel_fpu_begin()/_end().
>
> kernel_fpu_begin()/_end() is a pretty heavy operation because it does a full FPU
> save/restore via the XSAVE[S] and XRSTOR[S] instructions, which can easily copy a
> thousand bytes around! So kernel_fpu_begin()/_end() is probably a non-starter for
> something small, like a single 256-bit or 512-bit word access.
>
> But there's actually a new thing in modern kernels: we got rid of (most of) lazy
> save/restore FPU code, our new x86 FPU model is very "direct" with no FPU faults
> taken normally.
>
> So assuming the target driver will only load on modern FPUs I *think* it should
> actually be possible to do something like (pseudocode):
>
> vmovdqa %ymm0, 40(%rsp)
> vmovdqa %ymm1, 80(%rsp)
>
> ...
> # use ymm0 and ymm1
> ...
>
> vmovdqa 80(%rsp), %ymm1
> vmovdqa 40(%rsp), %ymm0
>
I think this kinda sorts works, but only kinda sorta:
- I'm a bit worried about newer CPUs where, say, a 256-bit vector
operation will implicitly clear the high 768 bits of the regs. (IIRC
that's how it works for the new VEX stuff.)
- This code will cause XINUSE to be set, which is user-visible and
may have performance and correctness effects. I think the kernel may
already have some but where it occasionally sets XINUSE on its own,
and this caused problems for rr in the past. This might not be a
total showstopper, but it's odd.
I'd rather see us finally finish the work that Rik started to rework
this differently. I'd like kernel_fpu_begin() to look like:
if (test_thread_flag(TIF_NEED_FPU_RESTORE)) {
return; // we're already okay. maybe we need to check
in_interrupt() or something, though?
} else {
XSAVES/XSAVEOPT/XSAVE;
set_thread_flag(TIF_NEED_FPU_RESTORE):
}
and kernel_fpu_end() does nothing at all.
We take the full performance hit for a *single* kernel_fpu_begin() on
an otherwise short syscall or interrupt, but there's no additional
cost for more of them or for long-enough-running things that we
schedule in the middle.
As I remember, the main hangup was that this interacts a bit oddly
with PKRU, but that's manageable.
--Andy
^ permalink raw reply
* Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
From: David Miller @ 2018-03-20 14:47 UTC (permalink / raw)
To: liran.alon; +Cc: netdev, linux-kernel, idan.brown, yuval.shaia
In-Reply-To: <1520953642-8145-1-git-send-email-liran.alon@oracle.com>
From: Liran Alon <liran.alon@oracle.com>
Date: Tue, 13 Mar 2018 17:07:22 +0200
> Before this commit, dev_forward_skb() always cleared packet's
> per-network-namespace info. Even if the packet doesn't cross
> network namespaces.
There was a lot of discussion about this patch.
Particularly whether it could potentially break current
users or not.
If this is resolved and the patch should still be applied,
please repost and the folks involved in this dicussion should
add their ACKs.
Thanks.
^ permalink raw reply
* Re: [PATCH] mlx5: Remove call to ida_pre_get
From: David Miller @ 2018-03-20 14:46 UTC (permalink / raw)
To: maorg; +Cc: saeedm, willy, matanb, netdev, linux-rdma, leon
In-Reply-To: <5d362a5b-9697-e1c1-c48c-3d64564f09e7@mellanox.com>
From: Maor Gottlieb <maorg@mellanox.com>
Date: Tue, 20 Mar 2018 14:41:49 +0200
> Saeed, Matan and I okay with this fix as well, it looks like it
> shouldn't impact on the insertion rate.
I've applied this to net-next, thanks everyone.
^ permalink raw reply
* [PATCH net] ipv6: sr: fix NULL pointer dereference when setting encap source address
From: David Lebrun @ 2018-03-20 14:44 UTC (permalink / raw)
To: netdev; +Cc: David Lebrun, David Lebrun
From: David Lebrun <dlebrun@google.com>
When using seg6 in encap mode, we call ipv6_dev_get_saddr() to set the
source address of the outer IPv6 header, in case none was specified.
Using skb->dev can lead to BUG() when it is in an inconsistent state.
This patch uses the net_device attached to the skb's dst instead.
[940807.667429] BUG: unable to handle kernel NULL pointer dereference at 000000000000047c
[940807.762427] IP: ipv6_dev_get_saddr+0x8b/0x1d0
[940807.815725] PGD 0 P4D 0
[940807.847173] Oops: 0000 [#1] SMP PTI
[940807.890073] Modules linked in:
[940807.927765] CPU: 6 PID: 0 Comm: swapper/6 Tainted: G W 4.16.0-rc1-seg6bpf+ #2
[940808.028988] Hardware name: HP ProLiant DL120 G6/ProLiant DL120 G6, BIOS O26 09/06/2010
[940808.128128] RIP: 0010:ipv6_dev_get_saddr+0x8b/0x1d0
[940808.187667] RSP: 0018:ffff88043fd836b0 EFLAGS: 00010206
[940808.251366] RAX: 0000000000000005 RBX: ffff88042cb1c860 RCX: 00000000000000fe
[940808.338025] RDX: 00000000000002c0 RSI: ffff88042cb1c860 RDI: 0000000000004500
[940808.424683] RBP: ffff88043fd83740 R08: 0000000000000000 R09: ffffffffffffffff
[940808.511342] R10: 0000000000000040 R11: 0000000000000000 R12: ffff88042cb1c850
[940808.598012] R13: ffffffff8208e380 R14: ffff88042ac8da00 R15: 0000000000000002
[940808.684675] FS: 0000000000000000(0000) GS:ffff88043fd80000(0000) knlGS:0000000000000000
[940808.783036] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[940808.852975] CR2: 000000000000047c CR3: 00000004255fe000 CR4: 00000000000006e0
[940808.939634] Call Trace:
[940808.970041] <IRQ>
[940808.995250] ? ip6t_do_table+0x265/0x640
[940809.043341] seg6_do_srh_encap+0x28f/0x300
[940809.093516] ? seg6_do_srh+0x1a0/0x210
[940809.139528] seg6_do_srh+0x1a0/0x210
[940809.183462] seg6_output+0x28/0x1e0
[940809.226358] lwtunnel_output+0x3f/0x70
[940809.272370] ip6_xmit+0x2b8/0x530
[940809.313185] ? ac6_proc_exit+0x20/0x20
[940809.359197] inet6_csk_xmit+0x7d/0xc0
[940809.404173] tcp_transmit_skb+0x548/0x9a0
[940809.453304] __tcp_retransmit_skb+0x1a8/0x7a0
[940809.506603] ? ip6_default_advmss+0x40/0x40
[940809.557824] ? tcp_current_mss+0x24/0x90
[940809.605925] tcp_retransmit_skb+0xd/0x80
[940809.654016] tcp_xmit_retransmit_queue.part.17+0xf9/0x210
[940809.719797] tcp_ack+0xa47/0x1110
[940809.760612] tcp_rcv_established+0x13c/0x570
[940809.812865] tcp_v6_do_rcv+0x151/0x3d0
[940809.858879] tcp_v6_rcv+0xa5c/0xb10
[940809.901770] ? seg6_output+0xdd/0x1e0
[940809.946745] ip6_input_finish+0xbb/0x460
[940809.994837] ip6_input+0x74/0x80
[940810.034612] ? ip6_rcv_finish+0xb0/0xb0
[940810.081663] ipv6_rcv+0x31c/0x4c0
...
Fixes: 6c8702c60b886 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
Reported-by: Tom Herbert <tom@quantonium.net>
Signed-off-by: David Lebrun <dlebrun@google.com>
---
net/ipv6/seg6_iptunnel.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c
index 8367b859a934..7a78dcfda68a 100644
--- a/net/ipv6/seg6_iptunnel.c
+++ b/net/ipv6/seg6_iptunnel.c
@@ -93,7 +93,8 @@ static void set_tun_src(struct net *net, struct net_device *dev,
/* encapsulate an IPv6 packet within an outer IPv6 header with a given SRH */
int seg6_do_srh_encap(struct sk_buff *skb, struct ipv6_sr_hdr *osrh, int proto)
{
- struct net *net = dev_net(skb_dst(skb)->dev);
+ struct dst_entry *dst = skb_dst(skb);
+ struct net *net = dev_net(dst->dev);
struct ipv6hdr *hdr, *inner_hdr;
struct ipv6_sr_hdr *isrh;
int hdrlen, tot_len, err;
@@ -134,7 +135,7 @@ int seg6_do_srh_encap(struct sk_buff *skb, struct ipv6_sr_hdr *osrh, int proto)
isrh->nexthdr = proto;
hdr->daddr = isrh->segments[isrh->first_segment];
- set_tun_src(net, skb->dev, &hdr->daddr, &hdr->saddr);
+ set_tun_src(net, ip6_dst_idev(dst)->dev, &hdr->daddr, &hdr->saddr);
#ifdef CONFIG_IPV6_SEG6_HMAC
if (sr_has_hmac(isrh)) {
--
2.16.2.804.g6dcf76e118-goog
^ permalink raw reply related
* [PATCH net] ipv6: sr: fix scheduling in RCU when creating seg6 lwtunnel state
From: David Lebrun @ 2018-03-20 14:44 UTC (permalink / raw)
To: netdev; +Cc: David Lebrun, David Lebrun
From: David Lebrun <dlebrun@google.com>
The seg6_build_state() function is called with RCU read lock held,
so we cannot use GFP_KERNEL. This patch uses GFP_ATOMIC instead.
[ 92.770271] =============================
[ 92.770628] WARNING: suspicious RCU usage
[ 92.770921] 4.16.0-rc4+ #12 Not tainted
[ 92.771277] -----------------------------
[ 92.771585] ./include/linux/rcupdate.h:302 Illegal context switch in RCU read-side critical section!
[ 92.772279]
[ 92.772279] other info that might help us debug this:
[ 92.772279]
[ 92.773067]
[ 92.773067] rcu_scheduler_active = 2, debug_locks = 1
[ 92.773514] 2 locks held by ip/2413:
[ 92.773765] #0: (rtnl_mutex){+.+.}, at: [<00000000e5461720>] rtnetlink_rcv_msg+0x441/0x4d0
[ 92.774377] #1: (rcu_read_lock){....}, at: [<00000000df4f161e>] lwtunnel_build_state+0x59/0x210
[ 92.775065]
[ 92.775065] stack backtrace:
[ 92.775371] CPU: 0 PID: 2413 Comm: ip Not tainted 4.16.0-rc4+ #12
[ 92.775791] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc27 04/01/2014
[ 92.776608] Call Trace:
[ 92.776852] dump_stack+0x7d/0xbc
[ 92.777130] __schedule+0x133/0xf00
[ 92.777393] ? unwind_get_return_address_ptr+0x50/0x50
[ 92.777783] ? __sched_text_start+0x8/0x8
[ 92.778073] ? rcu_is_watching+0x19/0x30
[ 92.778383] ? kernel_text_address+0x49/0x60
[ 92.778800] ? __kernel_text_address+0x9/0x30
[ 92.779241] ? unwind_get_return_address+0x29/0x40
[ 92.779727] ? pcpu_alloc+0x102/0x8f0
[ 92.780101] _cond_resched+0x23/0x50
[ 92.780459] __mutex_lock+0xbd/0xad0
[ 92.780818] ? pcpu_alloc+0x102/0x8f0
[ 92.781194] ? seg6_build_state+0x11d/0x240
[ 92.781611] ? save_stack+0x9b/0xb0
[ 92.781965] ? __ww_mutex_wakeup_for_backoff+0xf0/0xf0
[ 92.782480] ? seg6_build_state+0x11d/0x240
[ 92.782925] ? lwtunnel_build_state+0x1bd/0x210
[ 92.783393] ? ip6_route_info_create+0x687/0x1640
[ 92.783846] ? ip6_route_add+0x74/0x110
[ 92.784236] ? inet6_rtm_newroute+0x8a/0xd0
Fixes: 6c8702c60b886 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
Signed-off-by: David Lebrun <dlebrun@google.com>
---
net/ipv6/seg6_iptunnel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c
index bd6cc688bd19..8367b859a934 100644
--- a/net/ipv6/seg6_iptunnel.c
+++ b/net/ipv6/seg6_iptunnel.c
@@ -418,7 +418,7 @@ static int seg6_build_state(struct nlattr *nla,
slwt = seg6_lwt_lwtunnel(newts);
- err = dst_cache_init(&slwt->cache, GFP_KERNEL);
+ err = dst_cache_init(&slwt->cache, GFP_ATOMIC);
if (err) {
kfree(newts);
return err;
--
2.16.2.804.g6dcf76e118-goog
^ permalink raw reply related
* Re: [RFC PATCH 2/3] x86/io: implement 256-bit IO read and write
From: Alexander Duyck @ 2018-03-20 14:42 UTC (permalink / raw)
To: Rahul Lakkireddy
Cc: Thomas Gleixner, x86@kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
davem@davemloft.net, akpm@linux-foundation.org,
torvalds@linux-foundation.org, Ganesh GR, Nirranjan Kirubaharan,
Indranil Choudhury
In-Reply-To: <20180320133206.GB25574@chelsio.com>
On Tue, Mar 20, 2018 at 6:32 AM, Rahul Lakkireddy
<rahul.lakkireddy@chelsio.com> wrote:
> On Monday, March 03/19/18, 2018 at 20:13:10 +0530, Thomas Gleixner wrote:
>> On Mon, 19 Mar 2018, Rahul Lakkireddy wrote:
>>
>> > Use VMOVDQU AVX CPU instruction when available to do 256-bit
>> > IO read and write.
>>
>> That's not what the patch does. See below.
>>
>> > Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
>> > Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
>>
>> That Signed-off-by chain is wrong....
>>
>> > +#ifdef CONFIG_AS_AVX
>> > +#include <asm/fpu/api.h>
>> > +
>> > +static inline u256 __readqq(const volatile void __iomem *addr)
>> > +{
>> > + u256 ret;
>> > +
>> > + kernel_fpu_begin();
>> > + asm volatile("vmovdqu %0, %%ymm0" :
>> > + : "m" (*(volatile u256 __force *)addr));
>> > + asm volatile("vmovdqu %%ymm0, %0" : "=m" (ret));
>> > + kernel_fpu_end();
>> > + return ret;
>>
>> You _cannot_ assume that the instruction is available just because
>> CONFIG_AS_AVX is set. The availability is determined by the runtime
>> evaluated CPU feature flags, i.e. X86_FEATURE_AVX.
>>
>
> Ok. Will add boot_cpu_has(X86_FEATURE_AVX) check as well.
>
>> Aside of that I very much doubt that this is faster than 4 consecutive
>> 64bit reads/writes as you have the full overhead of
>> kernel_fpu_begin()/end() for each access.
>>
>> You did not provide any numbers for this so its even harder to
>> determine.
>>
>
> Sorry about that. Here are the numbers with and without this series.
>
> When reading up to 2 GB on-chip memory via MMIO, the time taken:
>
> Without Series With Series
> (64-bit read) (256-bit read)
>
> 52 seconds 26 seconds
>
> As can be seen, we see good improvement with doing 256-bits at a
> time.
Instead of framing this as an enhanced version of the read/write ops
why not look at replacing or extending something like the
memcpy_fromio or memcpy_toio operations? It would probably be more
comparable to what you are doing if you are wanting to move large
chunks of memory from one region to another, and it should translate
into something like AVX instructions once the CPU optimizations kick
in for a memcpy.
- Alex
^ permalink raw reply
* Re: interdependencies with cxgb4 and iw_cxgb4
From: David Miller @ 2018-03-20 14:40 UTC (permalink / raw)
To: swise
Cc: rajur, dledford, linux-rdma, jgg, netdev, bharat, ganeshgr,
rahul.lakkireddy
In-Reply-To: <01a201d3c051$eebbded0$cc339c70$@opengridcomputing.com>
From: "Steve Wise" <swise@opengridcomputing.com>
Date: Tue, 20 Mar 2018 08:47:04 -0500
>> From: Steve Wise <swise@opengridcomputing.com>
>> Date: Mon, 19 Mar 2018 14:50:57 -0500
>>
>> > Let me ask a dumb question:� Why cannot one of the maintaners pull the
>> > commit from the other mainainer's git repo directly?� IE why have this
>> > third trusted/signed git repo that has to be on k.o, from which both
>> > maintainers pull?� If one of you can pull it in via a patch series,
>> > like you do for all other patches, and then notify the other
>> > maintainer to pull it from the first maintainers' repo if the series
>> > meets the requirements that it needs to be in both maintainers'
>> > repositories?� This avoids adding more staging git repos on k.o.� But
>> > probably I'm missing something...
>>
>> Tree A may not want all of tree B's changes, and vice versa.
>
> I was thinking the special commit would go into a branch that was based on,
> say rc1 or rc2 of one of the maintainers. Then both maintainers pull that
> into their -next branch. Would that work?
That makes things more complicated.
The simplest design is that "identical" commits end up in both the
RDMA and the net-next tree.
Then it absolutely doesn't matter whose tree goes into Linus's first.
Also, we should not be merging "merge window" code after -rc1. "-rc1"
means the merge window is closed.
^ permalink raw reply
* RE: [RFC PATCH 2/3] x86/io: implement 256-bit IO read and write
From: David Laight @ 2018-03-20 14:40 UTC (permalink / raw)
To: 'Rahul Lakkireddy', Thomas Gleixner
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
davem@davemloft.net, akpm@linux-foundation.org,
torvalds@linux-foundation.org, Ganesh GR, Nirranjan Kirubaharan,
Indranil Choudhury
In-Reply-To: <20180320133206.GB25574@chelsio.com>
From: Rahul Lakkireddy
> Sent: 20 March 2018 13:32
...
> On High Availability Server, the logs of the failing system must be
> collected as quickly as possible. So, we're concerned with the amount
> of time taken to collect our large on-chip memory. We see improvement
> in doing 256-bit reads at a time.
Two other options:
1) Get the device to DMA into host memory.
2) Use mmap() (and vm_iomap_memory() in your driver) to get direct
userspace access to the (I assume) PCIe memory space.
You can then use whatever copy instructions the cpu has.
(Just don't use memcpy().)
David
^ 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