* [net-next v3 2/5] net/tls: Use socket data_ready callback on record availability
From: Vakul Garg @ 2018-07-19 11:16 UTC (permalink / raw)
To: netdev; +Cc: borisp, aviadye, davejwatson, davem, Vakul Garg
In-Reply-To: <20180719111643.12787-1-vakul.garg@nxp.com>
On receipt of a complete tls record, use socket's saved data_ready
callback instead of state_change callback.
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
---
net/tls/tls_sw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index e94cb54a6994..186152dced25 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -1019,7 +1019,7 @@ static void tls_queue(struct strparser *strp, struct sk_buff *skb)
ctx->recv_pkt = skb;
strp_pause(strp);
- strp->sk->sk_state_change(strp->sk);
+ ctx->saved_data_ready(strp->sk);
}
static void tls_data_ready(struct sock *sk)
--
2.13.6
^ permalink raw reply related
* [net-next v3 1/5] net/tls: Do not enable zero-copy prematurely
From: Vakul Garg @ 2018-07-19 11:16 UTC (permalink / raw)
To: netdev; +Cc: borisp, aviadye, davejwatson, davem, Vakul Garg
In-Reply-To: <20180719111643.12787-1-vakul.garg@nxp.com>
Zero-copy mode was left enabled even when zerocopy_from_iter() failed.
Set the zero-copy mode only when zerocopy_from_iter() succeeds. This
leads to removal of argument 'zc' of function decrypt_skb_update().
Function decrypt_skb_update() does not need to check whether
ctx->decrypted is set since it is never called if ctx->decrypted is
true.
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
---
net/tls/tls_sw.c | 22 +++++++++-------------
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 7d194c0cd6cf..e94cb54a6994 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -656,7 +656,7 @@ static struct sk_buff *tls_wait_data(struct sock *sk, int flags,
}
static int decrypt_skb_update(struct sock *sk, struct sk_buff *skb,
- struct scatterlist *sgout, bool *zc)
+ struct scatterlist *sgout)
{
struct tls_context *tls_ctx = tls_get_ctx(sk);
struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
@@ -668,13 +668,9 @@ static int decrypt_skb_update(struct sock *sk, struct sk_buff *skb,
if (err < 0)
return err;
#endif
- if (!ctx->decrypted) {
- err = decrypt_skb(sk, skb, sgout);
- if (err < 0)
- return err;
- } else {
- *zc = false;
- }
+ err = decrypt_skb(sk, skb, sgout);
+ if (err < 0)
+ return err;
rxm->offset += tls_ctx->rx.prepend_size;
rxm->full_len -= tls_ctx->rx.overhead_size;
@@ -819,7 +815,6 @@ int tls_sw_recvmsg(struct sock *sk,
struct scatterlist sgin[MAX_SKB_FRAGS + 1];
int pages = 0;
- zc = true;
sg_init_table(sgin, MAX_SKB_FRAGS + 1);
sg_set_buf(&sgin[0], ctx->rx_aad_plaintext,
TLS_AAD_SPACE_SIZE);
@@ -830,8 +825,10 @@ int tls_sw_recvmsg(struct sock *sk,
MAX_SKB_FRAGS, false, true);
if (err < 0)
goto fallback_to_reg_recv;
+ else
+ zc = true;
- err = decrypt_skb_update(sk, skb, sgin, &zc);
+ err = decrypt_skb_update(sk, skb, sgin);
for (; pages > 0; pages--)
put_page(sg_page(&sgin[pages]));
if (err < 0) {
@@ -840,7 +837,7 @@ int tls_sw_recvmsg(struct sock *sk,
}
} else {
fallback_to_reg_recv:
- err = decrypt_skb_update(sk, skb, NULL, &zc);
+ err = decrypt_skb_update(sk, skb, NULL);
if (err < 0) {
tls_err_abort(sk, EBADMSG);
goto recv_end;
@@ -895,7 +892,6 @@ ssize_t tls_sw_splice_read(struct socket *sock, loff_t *ppos,
int err = 0;
long timeo;
int chunk;
- bool zc;
lock_sock(sk);
@@ -912,7 +908,7 @@ ssize_t tls_sw_splice_read(struct socket *sock, loff_t *ppos,
}
if (!ctx->decrypted) {
- err = decrypt_skb_update(sk, skb, NULL, &zc);
+ err = decrypt_skb_update(sk, skb, NULL);
if (err < 0) {
tls_err_abort(sk, EBADMSG);
--
2.13.6
^ permalink raw reply related
* [net-next v3 0/5] net/tls: Minor code cleanup patches
From: Vakul Garg @ 2018-07-19 11:16 UTC (permalink / raw)
To: netdev; +Cc: borisp, aviadye, davejwatson, davem, Vakul Garg
This patch series improves tls_sw.c code by:
1) Removing redundant function decrypt_skb_update() argument.
2) Using correct socket callback for flagging data availability.
3) Removing redundant variable assignments and wakeup callbacks.
4) Removing redundant dynamic array allocation.
5) Using common error checking code for zero-copy, non zero-copy modes.
The patches do not fix any functional bug. Hence "Fixes:" tag has not
been used.
Vakul Garg (5):
net/tls: Do not enable zero-copy prematurely
net/tls: Use socket data_ready callback on record availability
net/tls: Remove redundant variable assignments and wakeup
net/tls: Remove redundant array allocation.
net/tls: Rework error checking after decrypt_skb_update()
net/tls/tls_sw.c | 45 ++++++++++++++++-----------------------------
1 file changed, 16 insertions(+), 29 deletions(-)
--
2.13.6
^ permalink raw reply
* Re: [PATCH net-next] net: phy: add GBit master / slave error detection
From: Heiner Kallweit @ 2018-07-19 5:54 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <a2e47fd0-f9a1-b8bd-c84d-6940d75dd453@gmail.com>
On 18.07.2018 11:22, Florian Fainelli wrote:
>
>
> On 07/17/2018 11:14 PM, Heiner Kallweit wrote:
>> Certain PHY's have issues when operating in GBit slave mode and can
>> be forced to master mode. Examples are RTL8211C, also the Micrel PHY
>> driver has a DT setting to force master mode.
>> If two such chips are link partners the autonegotiation will fail.
>> Standard defines a self-clearing on read, latched-high bit to
>> indicate this error. Check this bit to inform the user.
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> ---
>> drivers/net/phy/phy_device.c | 5 +++++
>> include/uapi/linux/mii.h | 1 +
>> 2 files changed, 6 insertions(+)
>>
>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>> index b9f5f40a..249c6f75 100644
>> --- a/drivers/net/phy/phy_device.c
>> +++ b/drivers/net/phy/phy_device.c
>> @@ -1551,6 +1551,11 @@ int genphy_read_status(struct phy_device *phydev)
>> if (lpagb < 0)
>> return lpagb;
>>
>> + if (lpagb & LPA_1000MSFAIL) {
>> + phydev_err(phydev, "Master/Slave resolution failed, maybe conflicting manual settings?\n");
>> + return -ENOLINK;
>> + }
>> +
>
> You should also be able to read whether Master/Slave was configured as
> automatic or manual, and possibly issue a different message when
> automatic/forced is specified?
>
Indeed, this could be done, based on the local automatic/manual setting.
> AFAIR there was a patch a while ago from Mellanox guys that was possibly
> extending the link notification with an error cause, this sounds like
> something that could be useful to report to user space somehow to help
> troubleshoot link down events.
>
Do you by chance have a reference to this patch? There's heavy development
on the Mellanox drivers with a lot of patches.
> Thanks for your improvements to PHYLIB.
>
^ permalink raw reply
* [PATCH net 3/3] qed: Correct Multicast API to reflect existence of 256 approximate buckets.
From: Sudarsana Reddy Kalluru @ 2018-07-19 5:50 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon, ariel.elior
In-Reply-To: <20180719055004.23556-1-sudarsana.kalluru@cavium.com>
FW hsi contains 256 approximation buckets which are split in ramrod into
eight u32 values, but driver is using eight 'unsigned long' variables.
This patch fixes the mcast logic by making the API utilize u32.
Fixes: 83aeb933 ("qed*: Trivial modifications")
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_l2.c | 15 +++++++--------
drivers/net/ethernet/qlogic/qed/qed_l2.h | 2 +-
drivers/net/ethernet/qlogic/qed/qed_sriov.c | 2 +-
drivers/net/ethernet/qlogic/qed/qed_vf.c | 4 ++--
drivers/net/ethernet/qlogic/qed/qed_vf.h | 7 ++++++-
5 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_l2.c b/drivers/net/ethernet/qlogic/qed/qed_l2.c
index 99973e1..5ede640 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_l2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_l2.c
@@ -665,7 +665,7 @@ static int qed_sp_vport_start(struct qed_hwfn *p_hwfn,
p_ramrod->common.update_approx_mcast_flg = 1;
for (i = 0; i < ETH_MULTICAST_MAC_BINS_IN_REGS; i++) {
- u32 *p_bins = (u32 *)p_params->bins;
+ u32 *p_bins = p_params->bins;
p_ramrod->approx_mcast.bins[i] = cpu_to_le32(p_bins[i]);
}
@@ -1476,8 +1476,8 @@ u8 qed_mcast_bin_from_mac(u8 *mac)
enum spq_mode comp_mode,
struct qed_spq_comp_cb *p_comp_data)
{
- unsigned long bins[ETH_MULTICAST_MAC_BINS_IN_REGS];
struct vport_update_ramrod_data *p_ramrod = NULL;
+ u32 bins[ETH_MULTICAST_MAC_BINS_IN_REGS];
struct qed_spq_entry *p_ent = NULL;
struct qed_sp_init_data init_data;
u8 abs_vport_id = 0;
@@ -1513,26 +1513,25 @@ u8 qed_mcast_bin_from_mac(u8 *mac)
/* explicitly clear out the entire vector */
memset(&p_ramrod->approx_mcast.bins, 0,
sizeof(p_ramrod->approx_mcast.bins));
- memset(bins, 0, sizeof(unsigned long) *
- ETH_MULTICAST_MAC_BINS_IN_REGS);
+ memset(bins, 0, sizeof(bins));
/* filter ADD op is explicit set op and it removes
* any existing filters for the vport
*/
if (p_filter_cmd->opcode == QED_FILTER_ADD) {
for (i = 0; i < p_filter_cmd->num_mc_addrs; i++) {
- u32 bit;
+ u32 bit, nbits;
bit = qed_mcast_bin_from_mac(p_filter_cmd->mac[i]);
- __set_bit(bit, bins);
+ nbits = sizeof(u32) * BITS_PER_BYTE;
+ bins[bit / nbits] |= 1 << (bit % nbits);
}
/* Convert to correct endianity */
for (i = 0; i < ETH_MULTICAST_MAC_BINS_IN_REGS; i++) {
struct vport_update_ramrod_mcast *p_ramrod_bins;
- u32 *p_bins = (u32 *)bins;
p_ramrod_bins = &p_ramrod->approx_mcast;
- p_ramrod_bins->bins[i] = cpu_to_le32(p_bins[i]);
+ p_ramrod_bins->bins[i] = cpu_to_le32(bins[i]);
}
}
diff --git a/drivers/net/ethernet/qlogic/qed/qed_l2.h b/drivers/net/ethernet/qlogic/qed/qed_l2.h
index 806a8da..8d80f10 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_l2.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_l2.h
@@ -215,7 +215,7 @@ struct qed_sp_vport_update_params {
u8 anti_spoofing_en;
u8 update_accept_any_vlan_flg;
u8 accept_any_vlan;
- unsigned long bins[8];
+ u32 bins[8];
struct qed_rss_params *rss_params;
struct qed_filter_accept_flags accept_flags;
struct qed_sge_tpa_params *sge_tpa_params;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
index fd59cf4..26e918d 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -2831,7 +2831,7 @@ void *qed_iov_search_list_tlvs(struct qed_hwfn *p_hwfn,
p_data->update_approx_mcast_flg = 1;
memcpy(p_data->bins, p_mcast_tlv->bins,
- sizeof(unsigned long) * ETH_MULTICAST_MAC_BINS_IN_REGS);
+ sizeof(u32) * ETH_MULTICAST_MAC_BINS_IN_REGS);
*tlvs_mask |= 1 << QED_IOV_VP_UPDATE_MCAST;
}
diff --git a/drivers/net/ethernet/qlogic/qed/qed_vf.c b/drivers/net/ethernet/qlogic/qed/qed_vf.c
index 2d7fcd6..be6ddde 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_vf.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_vf.c
@@ -1126,7 +1126,7 @@ int qed_vf_pf_vport_update(struct qed_hwfn *p_hwfn,
resp_size += sizeof(struct pfvf_def_resp_tlv);
memcpy(p_mcast_tlv->bins, p_params->bins,
- sizeof(unsigned long) * ETH_MULTICAST_MAC_BINS_IN_REGS);
+ sizeof(u32) * ETH_MULTICAST_MAC_BINS_IN_REGS);
}
update_rx = p_params->accept_flags.update_rx_mode_config;
@@ -1272,7 +1272,7 @@ void qed_vf_pf_filter_mcast(struct qed_hwfn *p_hwfn,
u32 bit;
bit = qed_mcast_bin_from_mac(p_filter_cmd->mac[i]);
- __set_bit(bit, sp_params.bins);
+ sp_params.bins[bit / 32] |= 1 << (bit % 32);
}
}
diff --git a/drivers/net/ethernet/qlogic/qed/qed_vf.h b/drivers/net/ethernet/qlogic/qed/qed_vf.h
index 4f05d5e..033409d 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_vf.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_vf.h
@@ -392,7 +392,12 @@ struct vfpf_vport_update_mcast_bin_tlv {
struct channel_tlv tl;
u8 padding[4];
- u64 bins[8];
+ /* There are only 256 approx bins, and in HSI they're divided into
+ * 32-bit values. As old VFs used to set-bit to the values on its side,
+ * the upper half of the array is never expected to contain any data.
+ */
+ u64 bins[4];
+ u64 obsolete_bins[4];
};
struct vfpf_vport_update_accept_param_tlv {
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 2/3] qed: Fix possible race for the link state value.
From: Sudarsana Reddy Kalluru @ 2018-07-19 5:50 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon, ariel.elior
In-Reply-To: <20180719055004.23556-1-sudarsana.kalluru@cavium.com>
There's a possible race where driver can read link status in mid-transition
and see that virtual-link is up yet speed is 0. Since in this
mid-transition we're guaranteed to see a mailbox from MFW soon, we can
afford to treat this as link down.
Fixes: cc875c2e ("qed: Add link support")
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
index fcd3466..1a12093 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
@@ -1208,6 +1208,7 @@ static void qed_mcp_handle_link_change(struct qed_hwfn *p_hwfn,
break;
default:
p_link->speed = 0;
+ p_link->link_up = 0;
}
if (p_link->link_up && p_link->speed)
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 0/3] qed: Fix series II.
From: Sudarsana Reddy Kalluru @ 2018-07-19 5:50 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon, ariel.elior, Sudarsana Reddy Kalluru
From: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
The patch series fixes few issues in the qed driver.
Please consider applying it to 'net' branch.
Sudarsana Reddy Kalluru (3):
qed: Fix link flap issue due to mismatching EEE capabilities.
qed: Fix possible race for the link state value.
qed: Correct Multicast API to reflect existence of 256 approximate
buckets.
drivers/net/ethernet/qlogic/qed/qed_l2.c | 15 +++++++--------
drivers/net/ethernet/qlogic/qed/qed_l2.h | 2 +-
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 13 ++++++++++---
drivers/net/ethernet/qlogic/qed/qed_sriov.c | 2 +-
drivers/net/ethernet/qlogic/qed/qed_vf.c | 4 ++--
drivers/net/ethernet/qlogic/qed/qed_vf.h | 7 ++++++-
6 files changed, 27 insertions(+), 16 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH net 1/3] qed: Fix link flap issue due to mismatching EEE capabilities.
From: Sudarsana Reddy Kalluru @ 2018-07-19 5:50 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon, ariel.elior
In-Reply-To: <20180719055004.23556-1-sudarsana.kalluru@cavium.com>
Apparently, MFW publishes EEE capabilities even for Fiber-boards that don't
support them, and later since qed internally sets adv_caps it would cause
link-flap avoidance (LFA) to fail when driver would initiate the link.
This in turn delays the link, causing traffic to fail.
Driver has been modified to not to ask MFW for any EEE config if EEE isn't
to be enabled.
Fixes: 645874e5 ("qed: Add support for Energy efficient ethernet.")
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
index 4e0b443..fcd3466 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
@@ -1305,9 +1305,15 @@ int qed_mcp_set_link(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt, bool b_up)
phy_cfg.pause |= (params->pause.forced_tx) ? ETH_PAUSE_TX : 0;
phy_cfg.adv_speed = params->speed.advertised_speeds;
phy_cfg.loopback_mode = params->loopback_mode;
- if (p_hwfn->mcp_info->capabilities & FW_MB_PARAM_FEATURE_SUPPORT_EEE) {
- if (params->eee.enable)
- phy_cfg.eee_cfg |= EEE_CFG_EEE_ENABLED;
+
+ /* There are MFWs that share this capability regardless of whether
+ * this is feasible or not. And given that at the very least adv_caps
+ * would be set internally by qed, we want to make sure LFA would
+ * still work.
+ */
+ if ((p_hwfn->mcp_info->capabilities &
+ FW_MB_PARAM_FEATURE_SUPPORT_EEE) && params->eee.enable) {
+ phy_cfg.eee_cfg |= EEE_CFG_EEE_ENABLED;
if (params->eee.tx_lpi_enable)
phy_cfg.eee_cfg |= EEE_CFG_TX_LPI;
if (params->eee.adv_caps & QED_EEE_1G_ADV)
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 1/2] net: netsec: enable tx-irq during open callback
From: Jassi Brar @ 2018-07-19 5:37 UTC (permalink / raw)
To: David Miller
Cc: <netdev@vger.kernel.org>, Masahisa Kojima, Ard Biesheuvel,
Jassi Brar
In-Reply-To: <20180418.133051.751780152476672314.davem@davemloft.net>
Hi David,
On Wed, Apr 18, 2018 at 11:00 PM, David Miller <davem@davemloft.net> wrote:
> From: Jassi Brar <jassisinghbrar@gmail.com>
> Date: Wed, 18 Apr 2018 18:27:59 +0530
>
>> Just to make sure, let me please mention that c009f413b79de52 and
>> 9a00b697ce31e are very much needed in stable kernel. Without these we
>> couldn't install any OS over network.
>
> Ok, both patches in this series queued up for -stable.
>
I don't see the patches still. Could you please have a relook.
Thanks.
^ permalink raw reply
* Re: linux-next: build warning after merge of the net-next tree
From: Stephen Rothwell @ 2018-07-19 5:29 UTC (permalink / raw)
To: Guenter Roeck
Cc: David Miller, Networking, Linux-Next Mailing List,
Linux Kernel Mailing List, Masahiro Yamada, Andrew Lunn
In-Reply-To: <cbc20089-6847-c0eb-5b5a-735245986be1@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
Hi Guenter,
On Wed, 18 Jul 2018 20:52:56 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 07/18/2018 07:04 PM, Stephen Rothwell wrote:
> >
> > After merging the net-next tree, today's linux-next build (x86_64
> > allmodconfig) produced this warning:
> >
> > *
> > * Restart config...
> > *
> > ....
> >
> > This is output by my "make allmodconfig" and only started after merging
> > the net-next tree today. It has continued for further merges/builds.
> >
> > I suspect commit
> >
> > 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")
> >
> > which added an "imply" clause.
> >
> I thought "imply" was better than "depends on HWMON || HWMON=n", but maybe
> not. Is that a caveat when using "imply", and does it mean that "imply"
> should better not be used ?
I don't know, sorry. It was just my best guess from what I could see
had changed.
I wonder if it makes a difference that I am doing my "make
allmodconfig" on top of a previous "make allmodconfig" and some symbols
are marked as "NEW" (though they are not symbols related to the changes
that happened during the net-next tree merge)?
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] net: sched: use PTR_ERR_OR_ZERO macro in tcf_block_cb_register
From: Gustavo A. R. Silva @ 2018-07-19 4:14 UTC (permalink / raw)
To: Jamal Hadi Salim, Cong Wang, Jiri Pirko, David S. Miller
Cc: netdev, linux-kernel, Gustavo A. R. Silva
This line makes up what macro PTR_ERR_OR_ZERO already does. So,
make use of PTR_ERR_OR_ZERO rather than an open-code version.
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
net/sched/cls_api.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index c51b1b1..570325f 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -818,7 +818,7 @@ int tcf_block_cb_register(struct tcf_block *block,
block_cb = __tcf_block_cb_register(block, cb, cb_ident, cb_priv,
extack);
- return IS_ERR(block_cb) ? PTR_ERR(block_cb) : 0;
+ return PTR_ERR_OR_ZERO(block_cb);
}
EXPORT_SYMBOL(tcf_block_cb_register);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] rxrpc: Reuse SKCIPHER_REQUEST_ON_STACK buffer
From: Kees Cook @ 2018-07-19 4:31 UTC (permalink / raw)
To: Eric Biggers
Cc: David Howells, Herbert Xu, Arnd Bergmann, Gustavo A. R. Silva,
David S. Miller, Network Development, LKML
In-Reply-To: <20180716174223.GE77258@google.com>
On Mon, Jul 16, 2018 at 10:42 AM, Eric Biggers <ebiggers@google.com> wrote:
> On Sun, Jul 15, 2018 at 08:49:47PM -0700, Kees Cook wrote:
>> The use of SKCIPHER_REQUEST_ON_STACK() will trigger FRAME_WARN warnings
>> (when less than 2048) once the VLA is no longer hidden from the check:
>>
>> net/rxrpc/rxkad.c:398:1: warning: the frame size of 1152 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>> net/rxrpc/rxkad.c:242:1: warning: the frame size of 1152 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>>
>> This passes the initial SKCIPHER_REQUEST_ON_STACK allocation to the leaf
>> functions for reuse. Two requests allocated on the stack are not needed
>> when only one is used at a time.
>>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>> ---
>> net/rxrpc/rxkad.c | 25 +++++++++++++------------
>> 1 file changed, 13 insertions(+), 12 deletions(-)
>> [...]
> How about doing the 'skcipher_request_set_tfm(req, call->conn->cipher)' and
> 'skcipher_request_zero(req);' just once, in the top-level function
> rxkad_verify_packet(), instead of before/after every time the request is used?
Hm. While that does sound reasonable, I like having it be
operationally unchanged. And changing this makes the caller function a
bit more weird. Right now it's doing direct returns, and we'd need to
cover error paths, etc. Having the "zero" _right_ after the
encrypt/decrypt seems more robust to me.
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* Re: [PATCH] rxrpc: Reuse SKCIPHER_REQUEST_ON_STACK buffer
From: Kees Cook @ 2018-07-19 4:29 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David Howells, Herbert Xu, Eric Biggers, Gustavo A. R. Silva,
David S. Miller, Networking, Linux Kernel Mailing List
In-Reply-To: <CAK8P3a3Owx8SMtenkOwXtqLCk_P8B18CNRkLfyL+GFUW9rYU1w@mail.gmail.com>
On Mon, Jul 16, 2018 at 3:17 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Jul 16, 2018 at 5:49 AM, Kees Cook <keescook@chromium.org> wrote:
>> The use of SKCIPHER_REQUEST_ON_STACK() will trigger FRAME_WARN warnings
>> (when less than 2048) once the VLA is no longer hidden from the check:
>>
>> net/rxrpc/rxkad.c:398:1: warning: the frame size of 1152 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>> net/rxrpc/rxkad.c:242:1: warning: the frame size of 1152 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>>
>> This passes the initial SKCIPHER_REQUEST_ON_STACK allocation to the leaf
>> functions for reuse. Two requests allocated on the stack are not needed
>> when only one is used at a time.
>>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>
> This looks like a very nice solution to the problem.
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> Since the large stack usage could already cause problems in older kernels,
> should this be backported to stable kernels as well?
I don't think this hits the bar for doing a -stable patch, but if you
think I should, I can do it.
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* Re: linux-next: build warning after merge of the net-next tree
From: Guenter Roeck @ 2018-07-19 3:52 UTC (permalink / raw)
To: Stephen Rothwell, David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Masahiro Yamada, Andrew Lunn
In-Reply-To: <20180719120447.6e7ba23d@canb.auug.org.au>
On 07/18/2018 07:04 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> *
> * Restart config...
> *
> ....
>
> This is output by my "make allmodconfig" and only started after merging
> the net-next tree today. It has continued for further merges/builds.
>
> I suspect commit
>
> 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")
>
> which added an "imply" clause.
>
I thought "imply" was better than "depends on HWMON || HWMON=n", but maybe
not. Is that a caveat when using "imply", and does it mean that "imply"
should better not be used ?
Guenter
^ permalink raw reply
* Re: [PATCH v3 net-next 0/3] rds: IPv6 support
From: Ka-Cheong Poon @ 2018-07-19 3:10 UTC (permalink / raw)
To: David Miller, sowmini.varadhan; +Cc: netdev, santosh.shilimkar, rds-devel
In-Reply-To: <20180719.023124.1179208187513867868.davem@davemloft.net>
On 07/19/2018 01:31 AM, David Miller wrote:
> From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
> Date: Wed, 18 Jul 2018 03:33:40 -0700
>
>> On (07/18/18 15:19), Ka-Cheong Poon wrote:
>>>> bind() and connect() are using the sa_family/ss_family to have
>>>> the application signal to the kernel about whether ipv4 or ipv6 is
>>>> desired. (and bind and connect are doing the right thing for
>>>> v4mapped, so that doesnt seem to be a problem there)
>>>>
>>>> In this case you want the application to signal that info via
>>>> the optlen. (And the reason for this inconsistency is that you dont
>>>> want to deal with the user->kernel copy in the same way?)
>>>
>>>
>>> Because doing that can break existing RDS apps. Existing code
>>> does not check the address family in processing this socket
>>> option. It only cares about the address and port. If the new
>>
>> I'll leave this up to DaveM. Existing code only handles IPv4,
>>
>> everywhere else, we always check the sa_family or ss_family
>> first and verify the length afterward. This was DaveM's original
>> point about bind/connect/sendmsg. I dont know why rds sockopts have
>> to be special.
>
> Yes, but the above point is valid.
>
> If the code never verified the sa_family value before, it is a very
> real possibility that code exists out that which is not initializing
> it or setting it incorrectly.
>
> Those apps have worked for a long time, and suddenly will break.
>
> We often have to deal with unfortunate mistakes like this.
>
> But for now, I guess the check can be added but we have to look out
> for any regressions this causes and revert if necessary.
Is it OK not to do the check for this patch? From a
customer's perspective, breaking working apps is a
really bad thing unless there is a very special
reason, such as security issue. Do you see a very
important problem, such as security issue, for not
adding the check in this patch?
Thanks.
--
K. Poon
ka-cheong.poon@oracle.com
^ permalink raw reply
* [PATCH v2 2/2] tools/bpftool: Fix segfault case regarding 'pin' arguments
From: Taeung Song @ 2018-07-19 2:45 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann; +Cc: netdev, linux-kernel
In-Reply-To: <20180719024515.6659-1-treeze.taeung@gmail.com>
Arguments of 'pin' subcommand should be checked
at the very beginning of do_pin_any().
Otherwise segfault errors can occur when using
'map pin' or 'prog pin' commands, so fix it.
# bpftool prog pin id
Segmentation fault
Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool")
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reported-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
---
tools/bpf/bpftool/common.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/tools/bpf/bpftool/common.c b/tools/bpf/bpftool/common.c
index 32f9e397a6c0..3f140eff039f 100644
--- a/tools/bpf/bpftool/common.c
+++ b/tools/bpf/bpftool/common.c
@@ -217,6 +217,14 @@ int do_pin_any(int argc, char **argv, int (*get_fd_by_id)(__u32))
int err;
int fd;
+ if (argc < 3) {
+ p_err("too few arguments, id ID and FILE path is required");
+ return -1;
+ } else if (argc > 3) {
+ p_err("too many arguments");
+ return -1;
+ }
+
if (!is_prefix(*argv, "id")) {
p_err("expected 'id' got %s", *argv);
return -1;
@@ -230,9 +238,6 @@ int do_pin_any(int argc, char **argv, int (*get_fd_by_id)(__u32))
}
NEXT_ARG();
- if (argc != 1)
- usage();
-
fd = get_fd_by_id(id);
if (fd < 0) {
p_err("can't get prog by id (%u): %s", id, strerror(errno));
--
2.17.1
^ permalink raw reply related
* [PATCH v2 1/2] tools/bpftool: ignore build products
From: Taeung Song @ 2018-07-19 2:45 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann; +Cc: netdev, linux-kernel
For untracked things of tools/bpf, add this.
Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
---
tools/bpf/.gitignore | 5 +++++
1 file changed, 5 insertions(+)
create mode 100644 tools/bpf/.gitignore
diff --git a/tools/bpf/.gitignore b/tools/bpf/.gitignore
new file mode 100644
index 000000000000..dfe2bd5a4b95
--- /dev/null
+++ b/tools/bpf/.gitignore
@@ -0,0 +1,5 @@
+FEATURE-DUMP.bpf
+bpf_asm
+bpf_dbg
+bpf_exp.yacc.*
+bpf_jit_disasm
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 2/2] tools/bpftool: Fix segfault case regarding 'pin' arguments
From: Taeung Song @ 2018-07-19 2:44 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Alexei Starovoitov, Daniel Borkmann, netdev, linux-kernel
In-Reply-To: <20180718111949.325c985b@cakuba.lan>
On 07/19/2018 03:19 AM, Jakub Kicinski wrote:
> On Wed, 18 Jul 2018 22:35:26 +0900, Taeung Song wrote:
>> Arguments of 'pin' subcommand should be checked
>> at the very beginning of do_pin_any().
>> Otherwise segfault errors can occur when using
>> 'map pin' or 'prog pin' commands, so fix it.
>>
>> # bpftool prog pin id
>> Segmentation fault
>>
>> Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool")
>> Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
>> Reported-by: Taehee Yoo <ap420073@gmail.com>
>> Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
>> ---
>> tools/bpf/bpftool/common.c | 11 ++++++++---
>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/bpf/bpftool/common.c b/tools/bpf/bpftool/common.c
>> index 32f9e397a6c0..b1e1ba9e1c90 100644
>> --- a/tools/bpf/bpftool/common.c
>> +++ b/tools/bpf/bpftool/common.c
>> @@ -217,6 +217,14 @@ int do_pin_any(int argc, char **argv, int (*get_fd_by_id)(__u32))
>> int err;
>> int fd;
>>
>> + if (argc < 3) {
>> + p_err("too few arguments, id PROG_ID and FILE path is required");
>
> Thanks for the fix! You can't say PROG_ID here, because this function
> is also called by bpftool map pin id X. How about s/PROG_ID/ID/ ?
>
Yep! will fix it :)
--
Thanks,
Taeung
>> + return -1;
>> + } else if (argc > 3) {
>> + p_err("too many arguments");
>> + return -1;
>> + }
>> +
>> if (!is_prefix(*argv, "id")) {
>> p_err("expected 'id' got %s", *argv);
>> return -1;
>> @@ -230,9 +238,6 @@ int do_pin_any(int argc, char **argv, int (*get_fd_by_id)(__u32))
>> }
>> NEXT_ARG();
>>
>> - if (argc != 1)
>> - usage();
>> -
>> fd = get_fd_by_id(id);
>> if (fd < 0) {
>> p_err("can't get prog by id (%u): %s", id, strerror(errno));
>
^ permalink raw reply
* Re: [net-next 10/16] net/mlx5: Support PCIe buffer congestion handling via Devlink
From: Jakub Kicinski @ 2018-07-19 1:49 UTC (permalink / raw)
To: Saeed Mahameed, Jiri Pirko; +Cc: David S. Miller, netdev, Eran Ben Elisha
In-Reply-To: <20180719010107.22363-11-saeedm@mellanox.com>
On Wed, 18 Jul 2018 18:01:01 -0700, Saeed Mahameed wrote:
> +static const struct devlink_param mlx5_devlink_params[] = {
> + DEVLINK_PARAM_DRIVER(MLX5_DEVLINK_PARAM_ID_CONGESTION_ACTION,
> + "congestion_action",
> + DEVLINK_PARAM_TYPE_U8,
> + BIT(DEVLINK_PARAM_CMODE_RUNTIME),
> + mlx5_devlink_get_congestion_action,
> + mlx5_devlink_set_congestion_action, NULL),
> + DEVLINK_PARAM_DRIVER(MLX5_DEVLINK_PARAM_ID_CONGESTION_MODE,
> + "congestion_mode",
> + DEVLINK_PARAM_TYPE_U8,
> + BIT(DEVLINK_PARAM_CMODE_RUNTIME),
> + mlx5_devlink_get_congestion_mode,
> + mlx5_devlink_set_congestion_mode, NULL),
> +};
The devlink params haven't been upstream even for a full cycle and
already you guys are starting to use them to configure standard
features like queuing.
I know your HW is not capable of doing full RED offload, it's a
snowflake. You tell us you're doing custom DCB configuration hacks on
one side (previous argument we had) and custom devlink parameter
configuration hacks on PCIe.
Perhaps the idea that we're trying to use the existing Linux APIs for
HW configuration only applies to forwarding behaviour.
^ permalink raw reply
* [PATCH net-next] net: caif: Add a missing rcu_read_unlock() in caif_flow_cb
From: YueHaibing @ 2018-07-19 2:27 UTC (permalink / raw)
To: davem, dmitry.tarnyagin; +Cc: linux-kernel, netdev, YueHaibing
Add a missing rcu_read_unlock in the error path
Fixes: c95567c80352 ("caif: added check for potential null return")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/caif/caif_dev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/caif/caif_dev.c b/net/caif/caif_dev.c
index e0adcd1..711d715 100644
--- a/net/caif/caif_dev.c
+++ b/net/caif/caif_dev.c
@@ -131,8 +131,10 @@ static void caif_flow_cb(struct sk_buff *skb)
caifd = caif_get(skb->dev);
WARN_ON(caifd == NULL);
- if (caifd == NULL)
+ if (!caifd) {
+ rcu_read_unlock();
return;
+ }
caifd_hold(caifd);
rcu_read_unlock();
--
2.7.0
^ permalink raw reply related
* [net 7/8] net/mlx5: Fix QP fragmented buffer allocation
From: Saeed Mahameed @ 2018-07-19 1:26 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Tariq Toukan, Saeed Mahameed
In-Reply-To: <20180719012612.25907-1-saeedm@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Fix bad alignment of SQ buffer in fragmented QP allocation.
It should start directly after RQ buffer ends.
Take special care of the end case where the RQ buffer does not occupy
a whole page. RQ size is a power of two, so would be the case only for
small RQ sizes (RQ size < PAGE_SIZE).
Fix wrong assignments for sqb->size (mistakenly assigned RQ size),
and for npages value of RQ and SQ.
Fixes: 3a2f70331226 ("net/mlx5: Use order-0 allocations for all WQ types")
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
.../net/ethernet/mellanox/mlx5/core/alloc.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/wq.c | 34 ++++++++++++-------
include/linux/mlx5/driver.h | 18 ++++++++--
3 files changed, 38 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/alloc.c b/drivers/net/ethernet/mellanox/mlx5/core/alloc.c
index 323ffe8bf7e4..456f30007ad6 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/alloc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/alloc.c
@@ -123,7 +123,7 @@ int mlx5_frag_buf_alloc_node(struct mlx5_core_dev *dev, int size,
int i;
buf->size = size;
- buf->npages = 1 << get_order(size);
+ buf->npages = DIV_ROUND_UP(size, PAGE_SIZE);
buf->page_shift = PAGE_SHIFT;
buf->frags = kcalloc(buf->npages, sizeof(struct mlx5_buf_list),
GFP_KERNEL);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/wq.c b/drivers/net/ethernet/mellanox/mlx5/core/wq.c
index b97bb72b4db4..86478a6b99c5 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/wq.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/wq.c
@@ -113,35 +113,45 @@ int mlx5_wq_cyc_create(struct mlx5_core_dev *mdev, struct mlx5_wq_param *param,
return err;
}
-static void mlx5e_qp_set_frag_buf(struct mlx5_frag_buf *buf,
- struct mlx5_wq_qp *qp)
+static void mlx5_qp_set_frag_buf(struct mlx5_frag_buf *buf,
+ struct mlx5_wq_qp *qp)
{
+ struct mlx5_frag_buf_ctrl *sq_fbc;
struct mlx5_frag_buf *rqb, *sqb;
- rqb = &qp->rq.fbc.frag_buf;
+ rqb = &qp->rq.fbc.frag_buf;
*rqb = *buf;
rqb->size = mlx5_wq_cyc_get_byte_size(&qp->rq);
- rqb->npages = 1 << get_order(rqb->size);
+ rqb->npages = DIV_ROUND_UP(rqb->size, PAGE_SIZE);
- sqb = &qp->sq.fbc.frag_buf;
- *sqb = *buf;
- sqb->size = mlx5_wq_cyc_get_byte_size(&qp->rq);
- sqb->npages = 1 << get_order(sqb->size);
+ sq_fbc = &qp->sq.fbc;
+ sqb = &sq_fbc->frag_buf;
+ *sqb = *buf;
+ sqb->size = mlx5_wq_cyc_get_byte_size(&qp->sq);
+ sqb->npages = DIV_ROUND_UP(sqb->size, PAGE_SIZE);
sqb->frags += rqb->npages; /* first part is for the rq */
+ if (sq_fbc->strides_offset)
+ sqb->frags--;
}
int mlx5_wq_qp_create(struct mlx5_core_dev *mdev, struct mlx5_wq_param *param,
void *qpc, struct mlx5_wq_qp *wq,
struct mlx5_wq_ctrl *wq_ctrl)
{
+ u32 sq_strides_offset;
int err;
mlx5_fill_fbc(MLX5_GET(qpc, qpc, log_rq_stride) + 4,
MLX5_GET(qpc, qpc, log_rq_size),
&wq->rq.fbc);
- mlx5_fill_fbc(ilog2(MLX5_SEND_WQE_BB),
- MLX5_GET(qpc, qpc, log_sq_size),
- &wq->sq.fbc);
+
+ sq_strides_offset =
+ ((wq->rq.fbc.frag_sz_m1 + 1) % PAGE_SIZE) / MLX5_SEND_WQE_BB;
+
+ mlx5_fill_fbc_offset(ilog2(MLX5_SEND_WQE_BB),
+ MLX5_GET(qpc, qpc, log_sq_size),
+ sq_strides_offset,
+ &wq->sq.fbc);
err = mlx5_db_alloc_node(mdev, &wq_ctrl->db, param->db_numa_node);
if (err) {
@@ -156,7 +166,7 @@ int mlx5_wq_qp_create(struct mlx5_core_dev *mdev, struct mlx5_wq_param *param,
goto err_db_free;
}
- mlx5e_qp_set_frag_buf(&wq_ctrl->buf, wq);
+ mlx5_qp_set_frag_buf(&wq_ctrl->buf, wq);
wq->rq.db = &wq_ctrl->db.db[MLX5_RCV_DBR];
wq->sq.db = &wq_ctrl->db.db[MLX5_SND_DBR];
diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
index 80cbb7fdce4a..83957920653a 100644
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@ -358,6 +358,7 @@ struct mlx5_frag_buf_ctrl {
struct mlx5_frag_buf frag_buf;
u32 sz_m1;
u32 frag_sz_m1;
+ u32 strides_offset;
u8 log_sz;
u8 log_stride;
u8 log_frag_strides;
@@ -983,14 +984,22 @@ static inline u32 mlx5_base_mkey(const u32 key)
return key & 0xffffff00u;
}
-static inline void mlx5_fill_fbc(u8 log_stride, u8 log_sz,
- struct mlx5_frag_buf_ctrl *fbc)
+static inline void mlx5_fill_fbc_offset(u8 log_stride, u8 log_sz,
+ u32 strides_offset,
+ struct mlx5_frag_buf_ctrl *fbc)
{
fbc->log_stride = log_stride;
fbc->log_sz = log_sz;
fbc->sz_m1 = (1 << fbc->log_sz) - 1;
fbc->log_frag_strides = PAGE_SHIFT - fbc->log_stride;
fbc->frag_sz_m1 = (1 << fbc->log_frag_strides) - 1;
+ fbc->strides_offset = strides_offset;
+}
+
+static inline void mlx5_fill_fbc(u8 log_stride, u8 log_sz,
+ struct mlx5_frag_buf_ctrl *fbc)
+{
+ mlx5_fill_fbc_offset(log_stride, log_sz, 0, fbc);
}
static inline void mlx5_core_init_cq_frag_buf(struct mlx5_frag_buf_ctrl *fbc,
@@ -1004,7 +1013,10 @@ static inline void mlx5_core_init_cq_frag_buf(struct mlx5_frag_buf_ctrl *fbc,
static inline void *mlx5_frag_buf_get_wqe(struct mlx5_frag_buf_ctrl *fbc,
u32 ix)
{
- unsigned int frag = (ix >> fbc->log_frag_strides);
+ unsigned int frag;
+
+ ix += fbc->strides_offset;
+ frag = ix >> fbc->log_frag_strides;
return fbc->frag_buf.frags[frag].buf +
((fbc->frag_sz_m1 & ix) << fbc->log_stride);
--
2.17.0
^ permalink raw reply related
* [net 8/8] net/mlx5e: Only allow offloading decap egress (egdev) flows
From: Saeed Mahameed @ 2018-07-19 1:26 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Roi Dayan, Paul Blakey, Saeed Mahameed
In-Reply-To: <20180719012612.25907-1-saeedm@mellanox.com>
From: Roi Dayan <roid@mellanox.com>
We get egress rules through the egdev mechanism when the ingress device
is not supporting offload, with the expected use-case of tunnel decap
ingress rule set on shared tunnel device.
Make sure to offload egress/egdev rules only if decap action (tunnel key
unset) exists there and err otherwise.
Fixes: 717503b9cf57 ("net: sched: convert cls_flower->egress_dev users to tc_setup_cb_egdev infra")
Signed-off-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Paul Blakey <paulb@mellanox.com>
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 0edf4751a8ba..3a2c4e548226 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -1957,6 +1957,10 @@ static bool actions_match_supported(struct mlx5e_priv *priv,
else
actions = flow->nic_attr->action;
+ if (flow->flags & MLX5E_TC_FLOW_EGRESS &&
+ !(actions & MLX5_FLOW_CONTEXT_ACTION_DECAP))
+ return false;
+
if (actions & MLX5_FLOW_CONTEXT_ACTION_MOD_HDR)
return modify_header_match_supported(&parse_attr->spec, exts);
--
2.17.0
^ permalink raw reply related
* [net 6/8] net/mlx5: Fix 'DON'T_TRAP' functionality
From: Saeed Mahameed @ 2018-07-19 1:26 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Raed Salem, Saeed Mahameed
In-Reply-To: <20180719012612.25907-1-saeedm@mellanox.com>
From: Raed Salem <raeds@mellanox.com>
The flow counters binding support commit introduced a code change where
none NULL 'rule_dest' is always passed to mlx5_add_flow_rules, this breaks
'DON'T_TRAP' rules insertion.
The fix uses the equivalent 'dest_num' value instead of dest pointer
at the failed check.
fixes: 3b3233fbf02e ('IB/mlx5: Add flow counters binding support')
Signed-off-by: Raed Salem <raeds@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
index f1a86cea86a0..6ddb2565884d 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
@@ -1887,7 +1887,7 @@ mlx5_add_flow_rules(struct mlx5_flow_table *ft,
if (flow_act->action == MLX5_FLOW_CONTEXT_ACTION_FWD_NEXT_PRIO) {
if (!fwd_next_prio_supported(ft))
return ERR_PTR(-EOPNOTSUPP);
- if (dest)
+ if (dest_num)
return ERR_PTR(-EINVAL);
mutex_lock(&root->chain_lock);
next_ft = find_next_chained_ft(prio);
--
2.17.0
^ permalink raw reply related
* [net 5/8] net/mlx5: E-Switch, UBSAN fix undefined behavior in mlx5_eswitch_mode
From: Saeed Mahameed @ 2018-07-19 1:26 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Saeed Mahameed
In-Reply-To: <20180719012612.25907-1-saeedm@mellanox.com>
With debug kernel UBSAN detects the following issue, which might happen
when eswitch instance is not created, fix this by testing the eswitch
pointer before returning the eswitch mode, if not set return mode =
SRIOV_NONE.
[ 32.528951] UBSAN: Undefined behaviour in drivers/net/ethernet/mellanox/mlx5/core/eswitch.c:2219:12
[ 32.528951] member access within null pointer of type 'struct mlx5_eswitch'
[ 32.528951] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc3-dirty #181
[ 32.528951] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014
[ 32.528951] Call Trace:
[ 32.528951] dump_stack+0xc7/0x13b
[ 32.528951] ? show_regs_print_info+0x5/0x5
[ 32.528951] ? __pm_runtime_use_autosuspend+0x140/0x140
[ 32.528951] ubsan_epilogue+0x9/0x49
[ 32.528951] ubsan_type_mismatch_common+0x1f9/0x2c0
[ 32.528951] ? ucs2_as_utf8+0x310/0x310
[ 32.528951] ? device_initialize+0x229/0x2e0
[ 32.528951] __ubsan_handle_type_mismatch+0x9f/0xc9
[ 32.528951] ? __ubsan_handle_divrem_overflow+0x19b/0x19b
[ 32.578008] ? ib_device_get_by_index+0xf0/0xf0
[ 32.578008] mlx5_eswitch_mode+0x30/0x40
[ 32.578008] mlx5_ib_add+0x1e0/0x4a0
Fixes: 57cbd893c4c5 ("net/mlx5: E-Switch, Move representors definition to a global scope")
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index b79d74860a30..dd01ad4c0b54 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -2216,6 +2216,6 @@ int mlx5_eswitch_get_vport_stats(struct mlx5_eswitch *esw,
u8 mlx5_eswitch_mode(struct mlx5_eswitch *esw)
{
- return esw->mode;
+ return ESW_ALLOWED(esw) ? esw->mode : SRIOV_NONE;
}
EXPORT_SYMBOL_GPL(mlx5_eswitch_mode);
--
2.17.0
^ permalink raw reply related
* [net 4/8] net/mlx5e: Don't allow aRFS for encapsulated packets
From: Saeed Mahameed @ 2018-07-19 1:26 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Saeed Mahameed
In-Reply-To: <20180719012612.25907-1-saeedm@mellanox.com>
From: Eran Ben Elisha <eranbe@mellanox.com>
Driver is yet to support aRFS for encapsulated packets, return early
error in such case.
Fixes: 18c908e477dc ("net/mlx5e: Add accelerated RFS support")
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c b/drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c
index 7b54a4999cf3..d258bb679271 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c
@@ -711,6 +711,9 @@ int mlx5e_rx_flow_steer(struct net_device *dev, const struct sk_buff *skb,
skb->protocol != htons(ETH_P_IPV6))
return -EPROTONOSUPPORT;
+ if (skb->encapsulation)
+ return -EPROTONOSUPPORT;
+
arfs_t = arfs_get_table(arfs, arfs_get_ip_proto(skb), skb->protocol);
if (!arfs_t)
return -EPROTONOSUPPORT;
--
2.17.0
^ permalink raw reply related
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