* Re: [PATCH v3 iproute2-next 1/8] rdma: include rdma-core <rdma/rdma_cma.h>
From: David Ahern @ 2018-03-27 13:23 UTC (permalink / raw)
To: Leon Romanovsky, Steve Wise; +Cc: stephen, netdev, linux-rdma
In-Reply-To: <20180327054622.GU1877@mtr-leonro.local>
On 3/26/18 11:46 PM, Leon Romanovsky wrote:
> On Mon, Mar 26, 2018 at 01:57:32PM -0700, Steve Wise wrote:
>> This avoids requiring rdma-core be installed on systems.
>>
>> Signed-off-by: Steve Wise <swise@opengridcomputing.com>
>> ---
>> rdma/include/rdma/rdma_cma.h | 728 +++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 728 insertions(+)
>> create mode 100644 rdma/include/rdma/rdma_cma.h
>>
>
> Steve,
>
> Sorry for not spotting it before, you actually need only 3 enums for the
> cm_id_ps_to_str() from rdma_cma.h.
>
> Simply copy/paste that enum into cm_id_ps_to_str().
>
> Thanks
>
I think this is Jason's point: if that enum is part of the UAPI why
isn't it part of a uapi header file?
We definitely do not want that entire header file brought in to iproute2
^ permalink raw reply
* Re: [net-next PATCH 3/5] net: netcp: ethss enhancements to support 2u cpsw h/w on K2G SoC
From: Murali Karicheri @ 2018-03-27 13:23 UTC (permalink / raw)
To: Andrew Lunn
Cc: robh+dt, mark.rutland, ssantosh, malat, w-kwok2, devicetree,
linux-kernel, linux-arm-kernel, davem, netdev
In-Reply-To: <20180326202842.GB5862@lunn.ch>
On 03/26/2018 04:28 PM, Andrew Lunn wrote:
> On Mon, Mar 26, 2018 at 04:15:10PM -0400, Murali Karicheri wrote:
>> K2G SoC uses 2u cpsw h/w. It uses RGMII instead of SGMII to interface with
>> Phy. This patch enhances the driver to check RGMII status instead of SGMII
>> status for link state determination. Also map all of the vlan priorities
>> to zero as the packet DMA is enabled to receive only flow id 0 which maps
>> to priority zero.
>>
>> Additionally, When a phy with rgmii interface requires internal delay, the
>> same is set in the phy driver. To support such phy devices, add a phy-mode
>> handling code in the driver using of_get_phy_mode() and pass the obtained
>> phy mode to of_phy_connect()
>
> Hi Murali
>
> Please break this patch up. One patch should do one thing. That makes
> it easy to review. There are too many things going on at once here.
>
> Andrew
>
Hello Andrew,
Thanks for the comment. But I am not sure how to break this up as this is
an enhancement to the driver to support a newer version of the cspw
hardware. Without all these pieces together, the driver can't
function. Probably I can make the below break up based on different functions
added. Let me know if this looks good to you. Beware that patch #2 and
#3 are small patches and majority of code change will be in patch #1
which has to go together.
Patch #1. Add support new link interface, RGMII_LINK_MAC_PHY, for K2G
- Most of the code is for this
Patch #2. Add support for configuring phy_mode
- This just add phy_mode handling code
Patch #3. map all vlan priorities to flow id 0
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] kernel: add support to collect hardware logs in crash recovery kernel
From: Eric W. Biederman @ 2018-03-27 13:17 UTC (permalink / raw)
To: Rahul Lakkireddy
Cc: netdev@vger.kernel.org, linux-fsdevel@vger.kernel.org,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
davem@davemloft.net, viro@zeniv.linux.org.uk,
stephen@networkplumber.org, akpm@linux-foundation.org,
torvalds@linux-foundation.org, Ganesh GR, Nirranjan Kirubaharan,
Indranil Choudhury
In-Reply-To: <20180326134539.GA15852@chelsio.com>
Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> writes:
> On Saturday, March 03/24/18, 2018 at 20:50:52 +0530, Eric W. Biederman wrote:
>>
>> Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> writes:
>>
>> > On production servers running variety of workloads over time, kernel
>> > panic can happen sporadically after days or even months. It is
>> > important to collect as much debug logs as possible to root cause
>> > and fix the problem, that may not be easy to reproduce. Snapshot of
>> > underlying hardware/firmware state (like register dump, firmware
>> > logs, adapter memory, etc.), at the time of kernel panic will be very
>> > helpful while debugging the culprit device driver.
>> >
>> > This series of patches add new generic framework that enable device
>> > drivers to collect device specific snapshot of the hardware/firmware
>> > state of the underlying device in the crash recovery kernel. In crash
>> > recovery kernel, the collected logs are exposed via /sys/kernel/crashdd/
>> > directory, which is copied by user space scripts for post-analysis.
>> >
>> > A kernel module crashdd is newly added. In crash recovery kernel,
>> > crashdd exposes /sys/kernel/crashdd/ directory containing device
>> > specific hardware/firmware logs.
>>
>> Have you looked at instead of adding a sysfs file adding the dumps
>> as additional elf notes in /proc/vmcore?
>>
>
> I see the crash recovery kernel's memory is not present in any of the
> the PT_LOAD headers. So, makedumpfile is not collecting the dumps
> that are in crash recovery kernel's memory.
>
> Also, are you suggesting exporting the dumps themselves as PT_NOTE
> instead? I'll look into doing it this way.
Yes. I was suggesting exporting the dumps themselves as PT_NOTE
in /proc/vmcore. I think that will allow makedumpfile to collect
your new information without modification.
Eric
^ permalink raw reply
* [PATCH] staging: fsl-dpaa2/ethsw: Fix TCI values overwrite
From: Razvan Stefanescu @ 2018-03-27 13:10 UTC (permalink / raw)
To: gregkh
Cc: devel, linux-kernel, netdev, andrew, alexandru.marginean,
ruxandra.radulescu, ioana.ciornei, laurentiu.tudor, stuyoder
Previous implementation overwrites PCP value, assuming the default value is
0, instead of 7.
Avoid this by modifying helper function ethsw_port_set_tci() to
ethsw_port_set_pvid() and make it update only the vlan_id of the tci_cfg
struct.
Signed-off-by: Razvan Stefanescu <razvan.stefanescu@nxp.com>
---
drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h | 13 +++++++++
drivers/staging/fsl-dpaa2/ethsw/dpsw.c | 42 ++++++++++++++++++++++++++++++
drivers/staging/fsl-dpaa2/ethsw/dpsw.h | 6 +++++
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 37 +++++++++++++-------------
4 files changed, 79 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h b/drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h
index 1c203e6..da744f2 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h
+++ b/drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h
@@ -49,6 +49,8 @@
#define DPSW_CMDID_IF_SET_FLOODING DPSW_CMD_ID(0x047)
#define DPSW_CMDID_IF_SET_BROADCAST DPSW_CMD_ID(0x048)
+#define DPSW_CMDID_IF_GET_TCI DPSW_CMD_ID(0x04A)
+
#define DPSW_CMDID_IF_SET_LINK_CFG DPSW_CMD_ID(0x04C)
#define DPSW_CMDID_VLAN_ADD DPSW_CMD_ID(0x060)
@@ -206,6 +208,17 @@ struct dpsw_cmd_if_set_tci {
__le16 conf;
};
+struct dpsw_cmd_if_get_tci {
+ __le16 if_id;
+};
+
+struct dpsw_rsp_if_get_tci {
+ __le16 pad;
+ __le16 vlan_id;
+ u8 dei;
+ u8 pcp;
+};
+
#define DPSW_STATE_SHIFT 0
#define DPSW_STATE_SIZE 4
diff --git a/drivers/staging/fsl-dpaa2/ethsw/dpsw.c b/drivers/staging/fsl-dpaa2/ethsw/dpsw.c
index 9b9bc60..3ea957c 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/dpsw.c
+++ b/drivers/staging/fsl-dpaa2/ethsw/dpsw.c
@@ -529,6 +529,48 @@ int dpsw_if_set_tci(struct fsl_mc_io *mc_io,
}
/**
+ * dpsw_if_get_tci() - Get default VLAN Tag Control Information (TCI)
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @token: Token of DPSW object
+ * @if_id: Interface Identifier
+ * @cfg: Tag Control Information Configuration
+ *
+ * Return: Completion status. '0' on Success; Error code otherwise.
+ */
+int dpsw_if_get_tci(struct fsl_mc_io *mc_io,
+ u32 cmd_flags,
+ u16 token,
+ u16 if_id,
+ struct dpsw_tci_cfg *cfg)
+{
+ struct mc_command cmd = { 0 };
+ struct dpsw_cmd_if_get_tci *cmd_params;
+ struct dpsw_rsp_if_get_tci *rsp_params;
+ int err;
+
+ /* prepare command */
+ cmd.header = mc_encode_cmd_header(DPSW_CMDID_IF_GET_TCI,
+ cmd_flags,
+ token);
+ cmd_params = (struct dpsw_cmd_if_get_tci *)cmd.params;
+ cmd_params->if_id = cpu_to_le16(if_id);
+
+ /* send command to mc*/
+ err = mc_send_command(mc_io, &cmd);
+ if (err)
+ return err;
+
+ /* retrieve response parameters */
+ rsp_params = (struct dpsw_rsp_if_get_tci *)cmd.params;
+ cfg->pcp = rsp_params->pcp;
+ cfg->dei = rsp_params->dei;
+ cfg->vlan_id = le16_to_cpu(rsp_params->vlan_id);
+
+ return 0;
+}
+
+/**
* dpsw_if_set_stp() - Function sets Spanning Tree Protocol (STP) state.
* @mc_io: Pointer to MC portal's I/O object
* @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
diff --git a/drivers/staging/fsl-dpaa2/ethsw/dpsw.h b/drivers/staging/fsl-dpaa2/ethsw/dpsw.h
index 3335add..82f80c40 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/dpsw.h
+++ b/drivers/staging/fsl-dpaa2/ethsw/dpsw.h
@@ -306,6 +306,12 @@ int dpsw_if_set_tci(struct fsl_mc_io *mc_io,
u16 if_id,
const struct dpsw_tci_cfg *cfg);
+int dpsw_if_get_tci(struct fsl_mc_io *mc_io,
+ u32 cmd_flags,
+ u16 token,
+ u16 if_id,
+ struct dpsw_tci_cfg *cfg);
+
/**
* enum dpsw_stp_state - Spanning Tree Protocol (STP) states
* @DPSW_STP_STATE_BLOCKING: Blocking state
diff --git a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
index c723a04..ab81a6c 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
+++ b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
@@ -50,14 +50,23 @@ static int ethsw_add_vlan(struct ethsw_core *ethsw, u16 vid)
return 0;
}
-static int ethsw_port_set_tci(struct ethsw_port_priv *port_priv,
- struct dpsw_tci_cfg *tci_cfg)
+static int ethsw_port_set_pvid(struct ethsw_port_priv *port_priv, u16 pvid)
{
struct ethsw_core *ethsw = port_priv->ethsw_data;
struct net_device *netdev = port_priv->netdev;
+ struct dpsw_tci_cfg tci_cfg = { 0 };
bool is_oper;
int err, ret;
+ err = dpsw_if_get_tci(ethsw->mc_io, 0, ethsw->dpsw_handle,
+ port_priv->idx, &tci_cfg);
+ if (err) {
+ netdev_err(netdev, "dpsw_if_get_tci err %d\n", err);
+ return err;
+ }
+
+ tci_cfg.vlan_id = pvid;
+
/* Interface needs to be down to change PVID */
is_oper = netif_oper_up(netdev);
if (is_oper) {
@@ -71,17 +80,16 @@ static int ethsw_port_set_tci(struct ethsw_port_priv *port_priv,
}
err = dpsw_if_set_tci(ethsw->mc_io, 0, ethsw->dpsw_handle,
- port_priv->idx, tci_cfg);
+ port_priv->idx, &tci_cfg);
if (err) {
netdev_err(netdev, "dpsw_if_set_tci err %d\n", err);
goto set_tci_error;
}
/* Delete previous PVID info and mark the new one */
- if (port_priv->pvid)
- port_priv->vlans[port_priv->pvid] &= ~ETHSW_VLAN_PVID;
- port_priv->vlans[tci_cfg->vlan_id] |= ETHSW_VLAN_PVID;
- port_priv->pvid = tci_cfg->vlan_id;
+ port_priv->vlans[port_priv->pvid] &= ~ETHSW_VLAN_PVID;
+ port_priv->vlans[pvid] |= ETHSW_VLAN_PVID;
+ port_priv->pvid = pvid;
set_tci_error:
if (is_oper) {
@@ -133,13 +141,7 @@ static int ethsw_port_add_vlan(struct ethsw_port_priv *port_priv,
}
if (flags & BRIDGE_VLAN_INFO_PVID) {
- struct dpsw_tci_cfg tci_cfg = {
- .pcp = 0,
- .dei = 0,
- .vlan_id = vid,
- };
-
- err = ethsw_port_set_tci(port_priv, &tci_cfg);
+ err = ethsw_port_set_pvid(port_priv, vid);
if (err)
return err;
}
@@ -819,9 +821,7 @@ static int ethsw_port_del_vlan(struct ethsw_port_priv *port_priv, u16 vid)
return -ENOENT;
if (port_priv->vlans[vid] & ETHSW_VLAN_PVID) {
- struct dpsw_tci_cfg tci_cfg = { 0 };
-
- err = ethsw_port_set_tci(port_priv, &tci_cfg);
+ err = ethsw_port_set_pvid(port_priv, 0);
if (err)
return err;
}
@@ -1254,7 +1254,6 @@ static int ethsw_port_init(struct ethsw_port_priv *port_priv, u16 port)
const char def_mcast[ETH_ALEN] = {0x01, 0x00, 0x5e, 0x00, 0x00, 0x01};
struct net_device *netdev = port_priv->netdev;
struct ethsw_core *ethsw = port_priv->ethsw_data;
- struct dpsw_tci_cfg tci_cfg = {0};
struct dpsw_vlan_if_cfg vcfg;
int err;
@@ -1272,7 +1271,7 @@ static int ethsw_port_init(struct ethsw_port_priv *port_priv, u16 port)
return err;
}
- err = ethsw_port_set_tci(port_priv, &tci_cfg);
+ err = ethsw_port_set_pvid(port_priv, 0);
if (err)
return err;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net V2] vhost: correctly remove wait queue during poll failure
From: Darren Kenny @ 2018-03-27 13:07 UTC (permalink / raw)
To: Jason Wang; +Cc: mst, kvm, virtualization, netdev, linux-kernel
In-Reply-To: <1522155052-13347-1-git-send-email-jasowang@redhat.com>
On Tue, Mar 27, 2018 at 08:50:52PM +0800, Jason Wang wrote:
>We tried to remove vq poll from wait queue, but do not check whether
>or not it was in a list before. This will lead double free. Fixing
>this by switching to use vhost_poll_stop() which zeros poll->wqh after
>removing poll from waitqueue to make sure it won't be freed twice.
>
>Cc: Darren Kenny <darren.kenny@oracle.com>
>Reported-by: syzbot+c0272972b01b872e604a@syzkaller.appspotmail.com
>Fixes: 2b8b328b61c79 ("vhost_net: handle polling errors when setting backend")
>Signed-off-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
>---
>Changes from V1:
>- tweak the commit log for to match the code
>---
> drivers/vhost/vhost.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
>diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
>index 1b3e8d2d..5d5a9d9 100644
>--- a/drivers/vhost/vhost.c
>+++ b/drivers/vhost/vhost.c
>@@ -212,8 +212,7 @@ int vhost_poll_start(struct vhost_poll *poll, struct file *file)
> if (mask)
> vhost_poll_wakeup(&poll->wait, 0, 0, poll_to_key(mask));
> if (mask & EPOLLERR) {
>- if (poll->wqh)
>- remove_wait_queue(poll->wqh, &poll->wait);
>+ vhost_poll_stop(poll);
> ret = -EINVAL;
> }
>
>--
>2.7.4
>
^ permalink raw reply
* Re: [Patch net] llc: properly handle dev_queue_xmit() return value
From: Noam Rathaus @ 2018-03-27 13:05 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev
In-Reply-To: <20180326220833.17351-1-xiyou.wangcong@gmail.com>
Hi,
I am not sure what is the next step from this?
Does it mean that a patch is out in the kernel's GIT/Beta version?
Or is this just a proposal?
On Tue, Mar 27, 2018 at 1:08 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> llc_conn_send_pdu() pushes the skb into write queue and
> calls llc_conn_send_pdus() to flush them out. However, the
> status of dev_queue_xmit() is not returned to caller,
> in this case, llc_conn_state_process().
>
> llc_conn_state_process() needs hold the skb no matter
> success or failure, because it still uses it after that,
> therefore we should hold skb before dev_queue_xmit() when
> that skb is the one being processed by llc_conn_state_process().
>
> For other callers, they can just pass NULL and ignore
> the return value as they are.
>
> Reported-by: Noam Rathaus <noamr@beyondsecurity.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
> include/net/llc_conn.h | 2 +-
> net/llc/llc_c_ac.c | 15 +++++++++------
> net/llc/llc_conn.c | 32 +++++++++++++++++++++++---------
> 3 files changed, 33 insertions(+), 16 deletions(-)
>
> diff --git a/include/net/llc_conn.h b/include/net/llc_conn.h
> index fe994d2e5286..5c40f118c0fa 100644
> --- a/include/net/llc_conn.h
> +++ b/include/net/llc_conn.h
> @@ -103,7 +103,7 @@ void llc_sk_reset(struct sock *sk);
>
> /* Access to a connection */
> int llc_conn_state_process(struct sock *sk, struct sk_buff *skb);
> -void llc_conn_send_pdu(struct sock *sk, struct sk_buff *skb);
> +int llc_conn_send_pdu(struct sock *sk, struct sk_buff *skb);
> void llc_conn_rtn_pdu(struct sock *sk, struct sk_buff *skb);
> void llc_conn_resend_i_pdu_as_cmd(struct sock *sk, u8 nr, u8 first_p_bit);
> void llc_conn_resend_i_pdu_as_rsp(struct sock *sk, u8 nr, u8 first_f_bit);
> diff --git a/net/llc/llc_c_ac.c b/net/llc/llc_c_ac.c
> index f59648018060..163121192aca 100644
> --- a/net/llc/llc_c_ac.c
> +++ b/net/llc/llc_c_ac.c
> @@ -389,7 +389,7 @@ static int llc_conn_ac_send_i_cmd_p_set_0(struct sock *sk, struct sk_buff *skb)
> llc_pdu_init_as_i_cmd(skb, 0, llc->vS, llc->vR);
> rc = llc_mac_hdr_init(skb, llc->dev->dev_addr, llc->daddr.mac);
> if (likely(!rc)) {
> - llc_conn_send_pdu(sk, skb);
> + rc = llc_conn_send_pdu(sk, skb);
> llc_conn_ac_inc_vs_by_1(sk, skb);
> }
> return rc;
> @@ -916,7 +916,7 @@ static int llc_conn_ac_send_i_rsp_f_set_ackpf(struct sock *sk,
> llc_pdu_init_as_i_cmd(skb, llc->ack_pf, llc->vS, llc->vR);
> rc = llc_mac_hdr_init(skb, llc->dev->dev_addr, llc->daddr.mac);
> if (likely(!rc)) {
> - llc_conn_send_pdu(sk, skb);
> + rc = llc_conn_send_pdu(sk, skb);
> llc_conn_ac_inc_vs_by_1(sk, skb);
> }
> return rc;
> @@ -935,14 +935,17 @@ static int llc_conn_ac_send_i_rsp_f_set_ackpf(struct sock *sk,
> int llc_conn_ac_send_i_as_ack(struct sock *sk, struct sk_buff *skb)
> {
> struct llc_sock *llc = llc_sk(sk);
> + int ret;
>
> if (llc->ack_must_be_send) {
> - llc_conn_ac_send_i_rsp_f_set_ackpf(sk, skb);
> + ret = llc_conn_ac_send_i_rsp_f_set_ackpf(sk, skb);
> llc->ack_must_be_send = 0 ;
> llc->ack_pf = 0;
> - } else
> - llc_conn_ac_send_i_cmd_p_set_0(sk, skb);
> - return 0;
> + } else {
> + ret = llc_conn_ac_send_i_cmd_p_set_0(sk, skb);
> + }
> +
> + return ret;
> }
>
> /**
> diff --git a/net/llc/llc_conn.c b/net/llc/llc_conn.c
> index 9177dbb16dce..110e32bcb399 100644
> --- a/net/llc/llc_conn.c
> +++ b/net/llc/llc_conn.c
> @@ -30,7 +30,7 @@
> #endif
>
> static int llc_find_offset(int state, int ev_type);
> -static void llc_conn_send_pdus(struct sock *sk);
> +static int llc_conn_send_pdus(struct sock *sk, struct sk_buff *skb);
> static int llc_conn_service(struct sock *sk, struct sk_buff *skb);
> static int llc_exec_conn_trans_actions(struct sock *sk,
> struct llc_conn_state_trans *trans,
> @@ -193,11 +193,11 @@ int llc_conn_state_process(struct sock *sk, struct sk_buff *skb)
> return rc;
> }
>
> -void llc_conn_send_pdu(struct sock *sk, struct sk_buff *skb)
> +int llc_conn_send_pdu(struct sock *sk, struct sk_buff *skb)
> {
> /* queue PDU to send to MAC layer */
> skb_queue_tail(&sk->sk_write_queue, skb);
> - llc_conn_send_pdus(sk);
> + return llc_conn_send_pdus(sk, skb);
> }
>
> /**
> @@ -255,7 +255,7 @@ void llc_conn_resend_i_pdu_as_cmd(struct sock *sk, u8 nr, u8 first_p_bit)
> if (howmany_resend > 0)
> llc->vS = (llc->vS + 1) % LLC_2_SEQ_NBR_MODULO;
> /* any PDUs to re-send are queued up; start sending to MAC */
> - llc_conn_send_pdus(sk);
> + llc_conn_send_pdus(sk, NULL);
> out:;
> }
>
> @@ -296,7 +296,7 @@ void llc_conn_resend_i_pdu_as_rsp(struct sock *sk, u8 nr, u8 first_f_bit)
> if (howmany_resend > 0)
> llc->vS = (llc->vS + 1) % LLC_2_SEQ_NBR_MODULO;
> /* any PDUs to re-send are queued up; start sending to MAC */
> - llc_conn_send_pdus(sk);
> + llc_conn_send_pdus(sk, NULL);
> out:;
> }
>
> @@ -340,12 +340,16 @@ int llc_conn_remove_acked_pdus(struct sock *sk, u8 nr, u16 *how_many_unacked)
> /**
> * llc_conn_send_pdus - Sends queued PDUs
> * @sk: active connection
> + * @hold_skb: the skb held by caller, or NULL if does not care
> *
> - * Sends queued pdus to MAC layer for transmission.
> + * Sends queued pdus to MAC layer for transmission. When @hold_skb is
> + * NULL, always return 0. Otherwise, return 0 if @hold_skb is sent
> + * successfully, or 1 for failure.
> */
> -static void llc_conn_send_pdus(struct sock *sk)
> +static int llc_conn_send_pdus(struct sock *sk, struct sk_buff *hold_skb)
> {
> struct sk_buff *skb;
> + int ret = 0;
>
> while ((skb = skb_dequeue(&sk->sk_write_queue)) != NULL) {
> struct llc_pdu_sn *pdu = llc_pdu_sn_hdr(skb);
> @@ -357,10 +361,20 @@ static void llc_conn_send_pdus(struct sock *sk)
> skb_queue_tail(&llc_sk(sk)->pdu_unack_q, skb);
> if (!skb2)
> break;
> - skb = skb2;
> + dev_queue_xmit(skb2);
> + } else {
> + bool is_target = skb == hold_skb;
> + int rc;
> +
> + if (is_target)
> + skb_get(skb);
> + rc = dev_queue_xmit(skb);
> + if (is_target)
> + ret = rc;
> }
> - dev_queue_xmit(skb);
> }
> +
> + return ret;
> }
>
> /**
> --
> 2.13.0
>
--
Thanks,
Noam Rathaus
Beyond Security
PGP Key ID: 7EF920D3C045D63F (Exp 2019-03)
^ permalink raw reply
* Re: [PATCH] net: fec: set dma_coherent_mask
From: Geert Uytterhoeven @ 2018-03-27 12:59 UTC (permalink / raw)
To: Greg Ungerer; +Cc: netdev, Linux/m68k
In-Reply-To: <1522071386-29743-1-git-send-email-gerg@linux-m68k.org>
Hi Greg,
On Mon, Mar 26, 2018 at 3:36 PM, Greg Ungerer <gerg@linux-m68k.org> wrote:
> As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
> coherent_dma_mask") the Freescale FEC driver is issuing the following
> warning on driver initialization on ColdFire systems:
>
> WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4
> Stack from 41833dd8:
> 41833dd8 40259c53 40025534 40279e26 00000003 00000000 4004e514 41827000
> 400255de 40244e42 00000204 40159e20 00000009 00000000 00000000 4024531d
> 40159e20 40244e42 00000204 00000000 00000000 00000000 00000007 00000000
> 00000000 40279e26 4028d040 40226576 4003ae88 40279e26 418273f6 41833ef8
> 7fffffff 418273f2 41867028 4003c9a2 4180ac6c 00000004 41833f8c 4013e71c
> 40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58 4028d040 00000000
> Call Trace:
> [<40025534>] 0x40025534
> [<4004e514>] 0x4004e514
> [<400255de>] 0x400255de
> [<40159e20>] 0x40159e20
> [<40159e20>] 0x40159e20
>
> It is not fatal, the driver and the system continue to function normally.
>
> As per the warning the coherent_dma_mask is not set on this device.
> There is nothing special about the DMA memory coherency on this hardware
> so we can just set the mask to 32bits during probe.
>
> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Thanks for your patch!
> ---
> drivers/net/ethernet/freescale/fec_main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> Is this the best way to handle this problem?
> Comments welcome...
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
> index d4604bc..3cb130a 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -2702,6 +2702,8 @@ static int fec_enet_alloc_queue(struct net_device *ndev)
> int ret = 0;
> struct fec_enet_priv_tx_q *txq;
>
> + dma_set_coherent_mask(&fep->pdev->dev, DMA_BIT_MASK(32));
> +
> for (i = 0; i < fep->num_tx_queues; i++) {
> txq = kzalloc(sizeof(*txq), GFP_KERNEL);
> if (!txq) {
As per your other email, this does not trigger on iMX systems using DT.
Hence I'm wondering if the Coldfire platform code shouldn't just do the
same what drivers/of/device.c does, cfr.
https://www.spinics.net/lists/linux-m68k/msg10929.html?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH net V2] vhost: correctly remove wait queue during poll failure
From: Jason Wang @ 2018-03-27 12:50 UTC (permalink / raw)
To: mst, jasowang; +Cc: kvm, virtualization, netdev, linux-kernel, Darren Kenny
We tried to remove vq poll from wait queue, but do not check whether
or not it was in a list before. This will lead double free. Fixing
this by switching to use vhost_poll_stop() which zeros poll->wqh after
removing poll from waitqueue to make sure it won't be freed twice.
Cc: Darren Kenny <darren.kenny@oracle.com>
Reported-by: syzbot+c0272972b01b872e604a@syzkaller.appspotmail.com
Fixes: 2b8b328b61c79 ("vhost_net: handle polling errors when setting backend")
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
Changes from V1:
- tweak the commit log for to match the code
---
drivers/vhost/vhost.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 1b3e8d2d..5d5a9d9 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -212,8 +212,7 @@ int vhost_poll_start(struct vhost_poll *poll, struct file *file)
if (mask)
vhost_poll_wakeup(&poll->wait, 0, 0, poll_to_key(mask));
if (mask & EPOLLERR) {
- if (poll->wqh)
- remove_wait_queue(poll->wqh, &poll->wait);
+ vhost_poll_stop(poll);
ret = -EINVAL;
}
--
2.7.4
^ permalink raw reply related
* [PATCH] net/9p: fix potential refcnt problem of trans module
From: Chengguang Xu @ 2018-03-27 12:49 UTC (permalink / raw)
To: ericvh, rminnich, lucho, davem; +Cc: v9fs-developer, netdev, Chengguang Xu
When specifying trans_mod multiple times in a mount,
it may cause inaccurate refcount of trans module. Also,
in the error case of option parsing, we should put the
trans module if we have already got.
Signed-off-by: Chengguang Xu <cgxu519@gmx.com>
---
net/9p/client.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/9p/client.c b/net/9p/client.c
index b433aff..7ccfb4b 100644
--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -190,7 +190,9 @@ static int parse_opts(char *opts, struct p9_client *clnt)
p9_debug(P9_DEBUG_ERROR,
"problem allocating copy of trans arg\n");
goto free_and_return;
- }
+ }
+
+ v9fs_put_trans(clnt->trans_mod);
clnt->trans_mod = v9fs_get_trans_by_name(s);
if (clnt->trans_mod == NULL) {
pr_info("Could not find request transport: %s\n",
@@ -226,6 +228,7 @@ static int parse_opts(char *opts, struct p9_client *clnt)
}
free_and_return:
+ v9fs_put_trans(clnt->trans_mod);
kfree(tmp_options);
return ret;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next] net: Export net->ipv6.sysctl.ip_nonlocal_bind to /proc
From: Kirill Tkhai @ 2018-03-27 12:44 UTC (permalink / raw)
To: davem, yoshfuji, netdev
In-Reply-To: <152214982810.20128.7674341091677928948.stgit@localhost.localdomain>
Please, ignore this.
Thanks,
Kirill
On 27.03.2018 14:24, Kirill Tkhai wrote:
> Currenly, this parameter can be configured via sysctl
> only. But sysctl is considered as depricated interface
> (man 2 sysctl), and it only can applied to current's net
> namespace (this requires to do setns() to change it in
> not current's net ns).
>
> So, let's export the parameter to /proc in standard way,
> and this allows to access another process namespace
> via /proc/[pid]/net/ip6_nonlocal_bind.
>
> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
> ---
> net/ipv6/proc.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
>
> diff --git a/net/ipv6/proc.c b/net/ipv6/proc.c
> index 6e57028d2e91..2d0aa59c2d0d 100644
> --- a/net/ipv6/proc.c
> +++ b/net/ipv6/proc.c
> @@ -312,6 +312,47 @@ int snmp6_unregister_dev(struct inet6_dev *idev)
> return 0;
> }
>
> +static int nonlocal_bind_show(struct seq_file *seq, void *v)
> +{
> + struct net *net = seq->private;
> +
> + seq_printf(seq, "%d\n", !!net->ipv6.sysctl.ip_nonlocal_bind);
> + return 0;
> +}
> +
> +static int open_nonlocal_bind(struct inode *inode, struct file *file)
> +{
> + return single_open_net(inode, file, nonlocal_bind_show);
> +}
> +
> +static ssize_t write_nonlocal_bind(struct file *file, const char __user *ubuf,
> + size_t count, loff_t *ppos)
> +{
> + struct net *net = ((struct seq_file *)file->private_data)->private;
> + char buf[3];
> +
> + if (*ppos || count <= 0 || count > sizeof(buf))
> + return -EINVAL;
> +
> + if (copy_from_user(buf, ubuf, count))
> + return -EFAULT;
> + buf[0] -= '0';
> + if ((count == 3 && buf[2] != '\0') ||
> + (count >= 2 && buf[1] != '\n') ||
> + (buf[0] != 0 && buf[0] != 1))
> + return -EINVAL;
> +
> + net->ipv6.sysctl.ip_nonlocal_bind = buf[0];
> + return count;
> +}
> +
> +static const struct file_operations nonlocal_bind_ops = {
> + .open = open_nonlocal_bind,
> + .read = seq_read,
> + .write = write_nonlocal_bind,
> + .release = single_release_net,
> +};
> +
> static int __net_init ipv6_proc_init_net(struct net *net)
> {
> if (!proc_create("sockstat6", 0444, net->proc_net,
> @@ -321,12 +362,18 @@ static int __net_init ipv6_proc_init_net(struct net *net)
> if (!proc_create("snmp6", 0444, net->proc_net, &snmp6_seq_fops))
> goto proc_snmp6_fail;
>
> + if (!proc_create_data("ip6_nonlocal_bind", 0644,
> + net->proc_net, &nonlocal_bind_ops, net))
> + goto proc_bind_fail;
> +
> net->mib.proc_net_devsnmp6 = proc_mkdir("dev_snmp6", net->proc_net);
> if (!net->mib.proc_net_devsnmp6)
> goto proc_dev_snmp6_fail;
> return 0;
>
> proc_dev_snmp6_fail:
> + remove_proc_entry("ip6_nonlocal_bind", net->proc_net);
> +proc_bind_fail:
> remove_proc_entry("snmp6", net->proc_net);
> proc_snmp6_fail:
> remove_proc_entry("sockstat6", net->proc_net);
> @@ -337,6 +384,7 @@ static void __net_exit ipv6_proc_exit_net(struct net *net)
> {
> remove_proc_entry("sockstat6", net->proc_net);
> remove_proc_entry("dev_snmp6", net->proc_net);
> + remove_proc_entry("ip6_nonlocal_bind", net->proc_net);
> remove_proc_entry("snmp6", net->proc_net);
> }
>
>
^ permalink raw reply
* Re: [PATCH v7 0/7] netdev: intel: Eliminate duplicate barriers on weakly-ordered archs
From: Sinan Kaya @ 2018-03-27 12:42 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Alexander Duyck, intel-wired-lan, Netdev, Timur Tabi, sulrich,
linux-arm-msm, linux-arm-kernel
In-Reply-To: <862cdbeafb9cfd272a426b010943ffc5@codeaurora.org>
Jeff,
On 3/23/2018 10:34 PM, okaya@codeaurora.org wrote:
> On 2018-03-23 19:58, Jeff Kirsher wrote:
>> On Fri, 2018-03-23 at 14:53 -0700, Alexander Duyck wrote:
>>> On Fri, Mar 23, 2018 at 11:52 AM, Sinan Kaya <okaya@codeaurora.org>
>>> wrote:
>>> > Code includes wmb() followed by writel() in multiple places. writel()
>>> > already has a barrier on some architectures like arm64.
>>> >
>>> > This ends up CPU observing two barriers back to back before executing
>>> > the
>>> > register write.
>>> >
>>> > Since code already has an explicit barrier call, changing writel() to
>>> > writel_relaxed().
>>> >
>>> > I did a regex search for wmb() followed by writel() in each drivers
>>> > directory.
>>> > I scrubbed the ones I care about in this series.
>>> >
>>> > I considered "ease of change", "popular usage" and "performance
>>> > critical
>>> > path" as the determining criteria for my filtering.
>>> >
>>> > We used relaxed API heavily on ARM for a long time but
>>> > it did not exist on other architectures. For this reason, relaxed
>>> > architectures have been paying double penalty in order to use the
>>> > common
>>> > drivers.
>>> >
>>> > Now that relaxed API is present on all architectures, we can go and
>>> > scrub
>>> > all drivers to see what needs to change and what can remain.
>>> >
>>> > We start with mostly used ones and hope to increase the coverage over
>>> > time.
>>> > It will take a while to cover all drivers.
>>> >
>>> > Feel free to apply patches individually.
>>>
>>> I looked over the set and they seem good.
>>>
>>> Reviewed-by: Alexander Duyck <alexander.h.duyck@intel.com>
>>
>> Grrr, patch 1 does not apply cleanly to my next-queue tree (dev-queue
>> branch). I will deal with this series in a day or two, after I have dealt
>> with my driver pull requests.
>
> Sorry, you will have to replace the ones you took from me.
Double sorry now.
I don't know if you have been following "RFC on writel and writel_relaxed" thread
or not but there are some new developments about wmb() requirement.
Basically, wmb() should never be used before writel() as writel() seem to
provide coherency and observability guarantee.
wmb()+writel_relaxed() is slower on some architectures than plain writel()
I'll have to rework these patches to have writel() only.
Are you able to drop the applied ones so that I can post V8 or is it too late?
Sinan
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH v7 0/7] netdev: Eliminate duplicate barriers on weakly-ordered archs
From: Sinan Kaya @ 2018-03-27 12:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev, timur, sulrich, linux-arm-msm, linux-arm-kernel
In-Reply-To: <20180326.124846.2182144342929084561.davem@davemloft.net>
Dave,
On 3/26/2018 12:48 PM, David Miller wrote:
> From: Sinan Kaya <okaya@codeaurora.org>
> Date: Sun, 25 Mar 2018 10:39:14 -0400
>
>> Code includes wmb() followed by writel() in multiple places. writel()
>> already has a barrier on some architectures like arm64.
>>
>> This ends up CPU observing two barriers back to back before executing the
>> register write.
>>
>> Since code already has an explicit barrier call, changing writel() to
>> writel_relaxed().
>>
>> I did a regex search for wmb() followed by writel() in each drivers
>> directory.
>> I scrubbed the ones I care about in this series.
>>
>> I considered "ease of change", "popular usage" and "performance critical
>> path" as the determining criteria for my filtering.
>>
>> We used relaxed API heavily on ARM for a long time but
>> it did not exist on other architectures. For this reason, relaxed
>> architectures have been paying double penalty in order to use the common
>> drivers.
>>
>> Now that relaxed API is present on all architectures, we can go and scrub
>> all drivers to see what needs to change and what can remain.
>>
>> We start with mostly used ones and hope to increase the coverage over time.
>> It will take a while to cover all drivers.
>>
>> Feel free to apply patches individually.
>>
>> Changes since v6:
>> - bring back amazon ena and add mmiowb, remove
>> ena_com_write_sq_doorbell_rel().
>> - remove extra mmiowb in bnx2x
>> - correct spelling mistake in bnx2x: Replace doorbell barrier() with wmb()
>
> Series applied, thank you.
>
I don't know if you have been following "RFC on writel and writel_relaxed" thread
or not but there are some new developments about wmb() requirement.
Basically, wmb() should never be used before writel() as writel() seem to
provide coherency and observability guarantee.
wmb()+writel_relaxed() is slower on some architectures than plain writel()
I'll have to rework these patches to have writel() only.
Are you able to drop the applied ones so that I can post V7 or is it too late?
Sinan
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: possible deadlock in rtnl_lock (5)
From: Florian Westphal @ 2018-03-27 11:50 UTC (permalink / raw)
To: syzbot; +Cc: netdev, syzkaller-bugs, ja
In-Reply-To: <000000000000f7826f0568630354@google.com>
syzbot <syzbot+a46d6abf9d56b1365a72@syzkaller.appspotmail.com> wrote:
[ cc Julian and trimming cc list ]
> syzkaller688027/4497 is trying to acquire lock:
> (rtnl_mutex){+.+.}, at: [<00000000bb14d7fb>] rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:74
> but task is already holding lock:
> IPVS: stopping backup sync thread 4495 ...
> (rtnl_mutex){+.+.}, at: [<00000000bb14d7fb>] rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:74
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
> CPU0
> ----
> lock(rtnl_mutex);
> lock(rtnl_mutex);
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
Looks like this is real, commit e0b26cc997d57305b4097711e12e13992580ae34
("ipvs: call rtnl_lock early") added rtnl_lock when starting sync thread
but socket close invokes rtnl_lock too:
> stack backtrace:
> rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
> ip_mc_drop_socket+0x88/0x230 net/ipv4/igmp.c:2643
> inet_release+0x4e/0x1c0 net/ipv4/af_inet.c:413
> sock_release+0x8d/0x1e0 net/socket.c:595
> start_sync_thread+0x2213/0x2b70 net/netfilter/ipvs/ip_vs_sync.c:1924
> do_ip_vs_set_ctl+0x1139/0x1cc0 net/netfilter/ipvs/ip_vs_ctl.c:2389
^ permalink raw reply
* [PATCH net 1/2] net/mlx4_en: Fix mixed PFC and Global pause user control requests
From: Tariq Toukan @ 2018-03-27 11:41 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Tariq Toukan
In-Reply-To: <1522150879-16501-1-git-send-email-tariqt@mellanox.com>
From: Eran Ben Elisha <eranbe@mellanox.com>
Global pause and PFC configuration should be mutually exclusive (i.e. only
one of them at most can be set). However, once PFC was turned off,
driver automatically turned Global pause on. This is a bug.
Fix the driver behaviour to turn off PFC/Global once the user turned the
other on.
This also fixed a weird behaviour that at a current time, the profile
had both PFC and global pause configuration turned on, which is
Hardware-wise impossible and caused returning false positive indication
to query tools.
In addition, fix error code when setting global pause or PFC to change
metadata only upon successful change.
Also, removed useless debug print.
Fixes: af7d51852631 ("net/mlx4_en: Add DCB PFC support through CEE netlink commands")
Fixes: c27a02cd94d6 ("mlx4_en: Add driver for Mellanox ConnectX 10GbE NIC")
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c | 72 ++++++++++++++-----------
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 33 +++++++-----
drivers/net/ethernet/mellanox/mlx4/en_main.c | 4 +-
3 files changed, 62 insertions(+), 47 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c b/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c
index 1a0c3bf86ead..752a72499b4f 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c
@@ -156,57 +156,63 @@ static int mlx4_en_dcbnl_getnumtcs(struct net_device *netdev, int tcid, u8 *num)
static u8 mlx4_en_dcbnl_set_all(struct net_device *netdev)
{
struct mlx4_en_priv *priv = netdev_priv(netdev);
+ struct mlx4_en_port_profile *prof = priv->prof;
struct mlx4_en_dev *mdev = priv->mdev;
+ u8 tx_pause, tx_ppp, rx_pause, rx_ppp;
if (!(priv->dcbx_cap & DCB_CAP_DCBX_VER_CEE))
return 1;
if (priv->cee_config.pfc_state) {
int tc;
+ rx_ppp = prof->rx_ppp;
+ tx_ppp = prof->tx_ppp;
- priv->prof->rx_pause = 0;
- priv->prof->tx_pause = 0;
for (tc = 0; tc < CEE_DCBX_MAX_PRIO; tc++) {
u8 tc_mask = 1 << tc;
switch (priv->cee_config.dcb_pfc[tc]) {
case pfc_disabled:
- priv->prof->tx_ppp &= ~tc_mask;
- priv->prof->rx_ppp &= ~tc_mask;
+ tx_ppp &= ~tc_mask;
+ rx_ppp &= ~tc_mask;
break;
case pfc_enabled_full:
- priv->prof->tx_ppp |= tc_mask;
- priv->prof->rx_ppp |= tc_mask;
+ tx_ppp |= tc_mask;
+ rx_ppp |= tc_mask;
break;
case pfc_enabled_tx:
- priv->prof->tx_ppp |= tc_mask;
- priv->prof->rx_ppp &= ~tc_mask;
+ tx_ppp |= tc_mask;
+ rx_ppp &= ~tc_mask;
break;
case pfc_enabled_rx:
- priv->prof->tx_ppp &= ~tc_mask;
- priv->prof->rx_ppp |= tc_mask;
+ tx_ppp &= ~tc_mask;
+ rx_ppp |= tc_mask;
break;
default:
break;
}
}
- en_dbg(DRV, priv, "Set pfc on\n");
+ rx_pause = !!(rx_ppp || tx_ppp) ? 0 : prof->rx_pause;
+ tx_pause = !!(rx_ppp || tx_ppp) ? 0 : prof->tx_pause;
} else {
- priv->prof->rx_pause = 1;
- priv->prof->tx_pause = 1;
- en_dbg(DRV, priv, "Set pfc off\n");
+ rx_ppp = 0;
+ tx_ppp = 0;
+ rx_pause = prof->rx_pause;
+ tx_pause = prof->tx_pause;
}
if (mlx4_SET_PORT_general(mdev->dev, priv->port,
priv->rx_skb_size + ETH_FCS_LEN,
- priv->prof->tx_pause,
- priv->prof->tx_ppp,
- priv->prof->rx_pause,
- priv->prof->rx_ppp)) {
+ tx_pause, tx_ppp, rx_pause, rx_ppp)) {
en_err(priv, "Failed setting pause params\n");
return 1;
}
+ prof->tx_ppp = tx_ppp;
+ prof->rx_ppp = rx_ppp;
+ prof->tx_pause = tx_pause;
+ prof->rx_pause = rx_pause;
+
return 0;
}
@@ -408,6 +414,7 @@ static int mlx4_en_dcbnl_ieee_setpfc(struct net_device *dev,
struct mlx4_en_priv *priv = netdev_priv(dev);
struct mlx4_en_port_profile *prof = priv->prof;
struct mlx4_en_dev *mdev = priv->mdev;
+ u32 tx_pause, tx_ppp, rx_pause, rx_ppp;
int err;
en_dbg(DRV, priv, "cap: 0x%x en: 0x%x mbc: 0x%x delay: %d\n",
@@ -416,23 +423,26 @@ static int mlx4_en_dcbnl_ieee_setpfc(struct net_device *dev,
pfc->mbc,
pfc->delay);
- prof->rx_pause = !pfc->pfc_en;
- prof->tx_pause = !pfc->pfc_en;
- prof->rx_ppp = pfc->pfc_en;
- prof->tx_ppp = pfc->pfc_en;
+ rx_pause = prof->rx_pause && !pfc->pfc_en;
+ tx_pause = prof->tx_pause && !pfc->pfc_en;
+ rx_ppp = pfc->pfc_en;
+ tx_ppp = pfc->pfc_en;
err = mlx4_SET_PORT_general(mdev->dev, priv->port,
priv->rx_skb_size + ETH_FCS_LEN,
- prof->tx_pause,
- prof->tx_ppp,
- prof->rx_pause,
- prof->rx_ppp);
- if (err)
+ tx_pause, tx_ppp, rx_pause, rx_ppp);
+ if (err) {
en_err(priv, "Failed setting pause params\n");
- else
- mlx4_en_update_pfc_stats_bitmap(mdev->dev, &priv->stats_bitmap,
- prof->rx_ppp, prof->rx_pause,
- prof->tx_ppp, prof->tx_pause);
+ return err;
+ }
+
+ mlx4_en_update_pfc_stats_bitmap(mdev->dev, &priv->stats_bitmap,
+ rx_ppp, rx_pause, tx_ppp, tx_pause);
+
+ prof->tx_ppp = tx_ppp;
+ prof->rx_ppp = rx_ppp;
+ prof->rx_pause = rx_pause;
+ prof->tx_pause = tx_pause;
return err;
}
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
index ebc1f566a4d9..f3302edba8b4 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@ -1046,27 +1046,32 @@ static int mlx4_en_set_pauseparam(struct net_device *dev,
{
struct mlx4_en_priv *priv = netdev_priv(dev);
struct mlx4_en_dev *mdev = priv->mdev;
+ u8 tx_pause, tx_ppp, rx_pause, rx_ppp;
int err;
if (pause->autoneg)
return -EINVAL;
- priv->prof->tx_pause = pause->tx_pause != 0;
- priv->prof->rx_pause = pause->rx_pause != 0;
+ tx_pause = !!(pause->tx_pause);
+ rx_pause = !!(pause->rx_pause);
+ rx_ppp = priv->prof->rx_ppp && !(tx_pause || rx_pause);
+ tx_ppp = priv->prof->tx_ppp && !(tx_pause || rx_pause);
+
err = mlx4_SET_PORT_general(mdev->dev, priv->port,
priv->rx_skb_size + ETH_FCS_LEN,
- priv->prof->tx_pause,
- priv->prof->tx_ppp,
- priv->prof->rx_pause,
- priv->prof->rx_ppp);
- if (err)
- en_err(priv, "Failed setting pause params\n");
- else
- mlx4_en_update_pfc_stats_bitmap(mdev->dev, &priv->stats_bitmap,
- priv->prof->rx_ppp,
- priv->prof->rx_pause,
- priv->prof->tx_ppp,
- priv->prof->tx_pause);
+ tx_pause, tx_ppp, rx_pause, rx_ppp);
+ if (err) {
+ en_err(priv, "Failed setting pause params, err = %d\n", err);
+ return err;
+ }
+
+ mlx4_en_update_pfc_stats_bitmap(mdev->dev, &priv->stats_bitmap,
+ rx_ppp, rx_pause, tx_ppp, tx_pause);
+
+ priv->prof->tx_pause = tx_pause;
+ priv->prof->rx_pause = rx_pause;
+ priv->prof->tx_ppp = tx_ppp;
+ priv->prof->rx_ppp = rx_ppp;
return err;
}
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_main.c b/drivers/net/ethernet/mellanox/mlx4/en_main.c
index 2c2965497ed3..d25e16d2c319 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_main.c
@@ -163,9 +163,9 @@ static void mlx4_en_get_profile(struct mlx4_en_dev *mdev)
params->udp_rss = 0;
}
for (i = 1; i <= MLX4_MAX_PORTS; i++) {
- params->prof[i].rx_pause = 1;
+ params->prof[i].rx_pause = !(pfcrx || pfctx);
params->prof[i].rx_ppp = pfcrx;
- params->prof[i].tx_pause = 1;
+ params->prof[i].tx_pause = !(pfcrx || pfctx);
params->prof[i].tx_ppp = pfctx;
params->prof[i].tx_ring_size = MLX4_EN_DEF_TX_RING_SIZE;
params->prof[i].rx_ring_size = MLX4_EN_DEF_RX_RING_SIZE;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 2/2] net/mlx4_core: Fix memory leak while delete slave's resources
From: Tariq Toukan @ 2018-03-27 11:41 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Moshe Shemesh, Tariq Toukan
In-Reply-To: <1522150879-16501-1-git-send-email-tariqt@mellanox.com>
From: Moshe Shemesh <moshe@mellanox.com>
mlx4_delete_all_resources_for_slave in resource tracker should free all
memory allocated for a slave.
While releasing memory of fs_rule, it misses releasing memory of
fs_rule->mirr_mbox.
Fixes: 78efed275117 ('net/mlx4_core: Support mirroring VF DMFS rules on both ports')
Signed-off-by: Moshe Shemesh <moshe@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
index 606a0e0beeae..29e50f787349 100644
--- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
+++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
@@ -5088,6 +5088,7 @@ static void rem_slave_fs_rule(struct mlx4_dev *dev, int slave)
&tracker->res_tree[RES_FS_RULE]);
list_del(&fs_rule->com.list);
spin_unlock_irq(mlx4_tlock(dev));
+ kfree(fs_rule->mirr_mbox);
kfree(fs_rule);
state = 0;
break;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 0/2] mlx4 misc fixes for 4.16
From: Tariq Toukan @ 2018-03-27 11:41 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Tariq Toukan
Hi Dave,
This patchset contains misc bug fixes from the team
to the mlx4 Core and Eth drivers.
Patch 1 by Eran fixes a control mix of PFC and Global pauses, please queue it
to -stable for >= v4.8.
Patch 2 by Moshe fixes a resource leak in slave's delete flow, please queue it
to -stable for >= v4.5.
Series generated against net commit:
3c82b372a9f4 net: dsa: mt7530: fix module autoloading for OF platform drivers
Thanks,
Tariq.
Eran Ben Elisha (1):
net/mlx4_en: Fix mixed PFC and Global pause user control requests
Moshe Shemesh (1):
net/mlx4_core: Fix memory leak while delete slave's resources
drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c | 72 ++++++++++++----------
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 33 +++++-----
drivers/net/ethernet/mellanox/mlx4/en_main.c | 4 +-
.../net/ethernet/mellanox/mlx4/resource_tracker.c | 1 +
4 files changed, 63 insertions(+), 47 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH net 1/1] net sched actions: fix dumping which requires several messages to user space
From: Jamal Hadi Salim @ 2018-03-27 11:26 UTC (permalink / raw)
To: Craig Dillabaugh, davem; +Cc: netdev, kernel, xiyou.wangcong, jiri
In-Reply-To: <1522090712-9154-1-git-send-email-cdillaba@mojatatu.com>
On 18-03-26 02:58 PM, Craig Dillabaugh wrote:
> Fixes a bug in the tcf_dump_walker function that can cause some actions
> to not be reported when dumping a large number of actions. This issue
> became more aggrevated when cookies feature was added. In particular
> this issue is manifest when large cookie values are assigned to the
> actions and when enough actions are created that the resulting table
> must be dumped in multiple batches.
>
> The number of actions returned in each batch is limited by the total
> number of actions and the memory buffer size. With small cookies
> the numeric limit is reached before the buffer size limit, which avoids
> the code path triggering this bug. When large cookies are used buffer
> fills before the numeric limit, and the erroneous code path is hit.
>
> For example after creating 32 csum actions with the cookie
> aaaabbbbccccdddd
>
> $ tc actions ls action csum
> total acts 26
>
> action order 0: csum (tcp) action continue
> index 1 ref 1 bind 0
> cookie aaaabbbbccccdddd
>
> .....
>
> action order 25: csum (tcp) action continue
> index 26 ref 1 bind 0
> cookie aaaabbbbccccdddd
> total acts 6
>
> action order 0: csum (tcp) action continue
> index 28 ref 1 bind 0
> cookie aaaabbbbccccdddd
>
> ......
>
> action order 5: csum (tcp) action continue
> index 32 ref 1 bind 0
> cookie aaaabbbbccccdddd
>
> Note that the action with index 27 is omitted from the report.
>
> Fixes: 4b3550ef530c ("[NET_SCHED]: Use nla_nest_start/nla_nest_end")"
> Signed-off-by: Craig Dillabaugh <cdillaba@mojatatu.com>
Good catch.
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* [PATCH net-next] net: Export net->ipv6.sysctl.ip_nonlocal_bind to /proc
From: Kirill Tkhai @ 2018-03-27 11:24 UTC (permalink / raw)
To: davem, yoshfuji, ktkhai, netdev
Currenly, this parameter can be configured via sysctl
only. But sysctl is considered as depricated interface
(man 2 sysctl), and it only can applied to current's net
namespace (this requires to do setns() to change it in
not current's net ns).
So, let's export the parameter to /proc in standard way,
and this allows to access another process namespace
via /proc/[pid]/net/ip6_nonlocal_bind.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
---
net/ipv6/proc.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/net/ipv6/proc.c b/net/ipv6/proc.c
index 6e57028d2e91..2d0aa59c2d0d 100644
--- a/net/ipv6/proc.c
+++ b/net/ipv6/proc.c
@@ -312,6 +312,47 @@ int snmp6_unregister_dev(struct inet6_dev *idev)
return 0;
}
+static int nonlocal_bind_show(struct seq_file *seq, void *v)
+{
+ struct net *net = seq->private;
+
+ seq_printf(seq, "%d\n", !!net->ipv6.sysctl.ip_nonlocal_bind);
+ return 0;
+}
+
+static int open_nonlocal_bind(struct inode *inode, struct file *file)
+{
+ return single_open_net(inode, file, nonlocal_bind_show);
+}
+
+static ssize_t write_nonlocal_bind(struct file *file, const char __user *ubuf,
+ size_t count, loff_t *ppos)
+{
+ struct net *net = ((struct seq_file *)file->private_data)->private;
+ char buf[3];
+
+ if (*ppos || count <= 0 || count > sizeof(buf))
+ return -EINVAL;
+
+ if (copy_from_user(buf, ubuf, count))
+ return -EFAULT;
+ buf[0] -= '0';
+ if ((count == 3 && buf[2] != '\0') ||
+ (count >= 2 && buf[1] != '\n') ||
+ (buf[0] != 0 && buf[0] != 1))
+ return -EINVAL;
+
+ net->ipv6.sysctl.ip_nonlocal_bind = buf[0];
+ return count;
+}
+
+static const struct file_operations nonlocal_bind_ops = {
+ .open = open_nonlocal_bind,
+ .read = seq_read,
+ .write = write_nonlocal_bind,
+ .release = single_release_net,
+};
+
static int __net_init ipv6_proc_init_net(struct net *net)
{
if (!proc_create("sockstat6", 0444, net->proc_net,
@@ -321,12 +362,18 @@ static int __net_init ipv6_proc_init_net(struct net *net)
if (!proc_create("snmp6", 0444, net->proc_net, &snmp6_seq_fops))
goto proc_snmp6_fail;
+ if (!proc_create_data("ip6_nonlocal_bind", 0644,
+ net->proc_net, &nonlocal_bind_ops, net))
+ goto proc_bind_fail;
+
net->mib.proc_net_devsnmp6 = proc_mkdir("dev_snmp6", net->proc_net);
if (!net->mib.proc_net_devsnmp6)
goto proc_dev_snmp6_fail;
return 0;
proc_dev_snmp6_fail:
+ remove_proc_entry("ip6_nonlocal_bind", net->proc_net);
+proc_bind_fail:
remove_proc_entry("snmp6", net->proc_net);
proc_snmp6_fail:
remove_proc_entry("sockstat6", net->proc_net);
@@ -337,6 +384,7 @@ static void __net_exit ipv6_proc_exit_net(struct net *net)
{
remove_proc_entry("sockstat6", net->proc_net);
remove_proc_entry("dev_snmp6", net->proc_net);
+ remove_proc_entry("ip6_nonlocal_bind", net->proc_net);
remove_proc_entry("snmp6", net->proc_net);
}
^ permalink raw reply related
* possible deadlock in rtnl_lock (5)
From: syzbot @ 2018-03-27 11:16 UTC (permalink / raw)
To: christian.brauner, daniel, davem, dsahern, fw, jakub.kicinski,
jbenc, linux-kernel, lucien.xin, netdev, syzkaller-bugs,
vyasevich
Hello,
syzbot hit the following crash on upstream commit
3eb2ce825ea1ad89d20f7a3b5780df850e4be274 (Sun Mar 25 22:44:30 2018 +0000)
Linux 4.16-rc7
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=a46d6abf9d56b1365a72
So far this crash happened 27 times on net-next, upstream.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6524202618191872
syzkaller reproducer:
https://syzkaller.appspot.com/x/repro.syz?id=5383267238805504
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=5136472378179584
Kernel config:
https://syzkaller.appspot.com/x/.config?id=-8440362230543204781
compiler: gcc (GCC) 7.1.1 20170620
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+a46d6abf9d56b1365a72@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
IPVS: sync thread started: state = BACKUP, mcast_ifn = sit0, syncid = 0, id
= 0
IPVS: sync thread started: state = BACKUP, mcast_ifn = sit0, syncid = 0, id
= 0
============================================
IPVS: stopping backup sync thread 4500 ...
WARNING: possible recursive locking detected
4.16.0-rc7+ #3 Not tainted
--------------------------------------------
syzkaller688027/4497 is trying to acquire lock:
(rtnl_mutex){+.+.}, at: [<00000000bb14d7fb>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
but task is already holding lock:
IPVS: stopping backup sync thread 4495 ...
(rtnl_mutex){+.+.}, at: [<00000000bb14d7fb>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(rtnl_mutex);
lock(rtnl_mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by syzkaller688027/4497:
#0: (rtnl_mutex){+.+.}, at: [<00000000bb14d7fb>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
#1: (ipvs->sync_mutex){+.+.}, at: [<00000000703f78e3>]
do_ip_vs_set_ctl+0x10f8/0x1cc0 net/netfilter/ipvs/ip_vs_ctl.c:2388
stack backtrace:
CPU: 1 PID: 4497 Comm: syzkaller688027 Not tainted 4.16.0-rc7+ #3
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x24d lib/dump_stack.c:53
print_deadlock_bug kernel/locking/lockdep.c:1761 [inline]
check_deadlock kernel/locking/lockdep.c:1805 [inline]
validate_chain kernel/locking/lockdep.c:2401 [inline]
__lock_acquire+0xe8f/0x3e00 kernel/locking/lockdep.c:3431
lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3920
__mutex_lock_common kernel/locking/mutex.c:756 [inline]
__mutex_lock+0x16f/0x1a80 kernel/locking/mutex.c:893
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
ip_mc_drop_socket+0x88/0x230 net/ipv4/igmp.c:2643
inet_release+0x4e/0x1c0 net/ipv4/af_inet.c:413
sock_release+0x8d/0x1e0 net/socket.c:595
start_sync_thread+0x2213/0x2b70 net/netfilter/ipvs/ip_vs_sync.c:1924
do_ip_vs_set_ctl+0x1139/0x1cc0 net/netfilter/ipvs/ip_vs_ctl.c:2389
nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
nf_setsockopt+0x67/0xc0 net/netfilter/nf_sockopt.c:115
ip_setsockopt+0x97/0xa0 net/ipv4/ip_sockglue.c:1261
udp_setsockopt+0x45/0x80 net/ipv4/udp.c:2406
sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2975
SYSC_setsockopt net/socket.c:1849 [inline]
SyS_setsockopt+0x189/0x360 net/socket.c:1828
do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x446a69
RSP: 002b:00007fa1c3a64da8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000446a69
RDX: 000000000000048b RSI: 0000000000000000 RDI: 0000000000000003
RBP: 00000000006e29fc R08: 0000000000000018 R09: 0000000000000000
R10: 00000000200000c0 R11: 0000000000000246 R12: 00000000006e29f8
R13: 00676e697279656b R14: 00007fa1c3a659c0 R15: 00000000006e2b60
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* Re: [PATCH 1/6] rhashtable: improve documentation for rhashtable_walk_peek()
From: Sergei Shtylyov @ 2018-03-27 10:55 UTC (permalink / raw)
To: NeilBrown, Thomas Graf, Herbert Xu; +Cc: netdev, linux-kernel
In-Reply-To: <152210718418.11435.11573013181393548255.stgit@noble>
Hello!
On 3/27/2018 2:33 AM, NeilBrown wrote:
> The documentation for rhashtable_walk_peek() wrong. It claims to
> return the *next* entry, whereas it in fact returns the *previous*
> entry.
> However if no entries have yet been returned - or if the iterator
> was reset due to a resize event, then rhashtable_walk_peek()
> *does* return the next entry, but also advances the iterator.
>
> I suspect that this interface should be discarded and the one user
> should be changed to not require it. Possibly this patch should be
> seen as a first step in that conversation.
>
> This patch mostly corrects the documentation, but does make a
> small code change so that the documentation can be correct without
> listing too many special cases. I don't think the one user will
> be affected by the code change.
>
> Signed-off-by: NeilBrown <neilb@suse.com>
> ---
> lib/rhashtable.c | 17 +++++++++++++----
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/lib/rhashtable.c b/lib/rhashtable.c
> index 3825c30aaa36..24a57ca494cb 100644
> --- a/lib/rhashtable.c
> +++ b/lib/rhashtable.c
> @@ -853,13 +853,17 @@ void *rhashtable_walk_next(struct rhashtable_iter *iter)
> EXPORT_SYMBOL_GPL(rhashtable_walk_next);
>
> /**
> - * rhashtable_walk_peek - Return the next object but don't advance the iterator
> + * rhashtable_walk_peek - Return the previously returned object without advancing the iterator
> * @iter: Hash table iterator
> *
> - * Returns the next object or NULL when the end of the table is reached.
> + * Returns the last object returned,
Sounds somewhat tautological. :-)
> or NULL if no object has yet been returned.
> + * If the previously returned object has since been removed, then some other arbitrary
> + * object maybe returned, or possibly NULL will be returned. In that case, the
> + * iterator might be advanced.
> *
> * Returns -EAGAIN if resize event occurred. Note that the iterator
> - * will rewind back to the beginning and you may continue to use it.
> + * will rewind back to the beginning and rhashtable_walk_next() should be
> + * used to get the next object.
> */
> void *rhashtable_walk_peek(struct rhashtable_iter *iter)
> {
> @@ -880,7 +884,12 @@ void *rhashtable_walk_peek(struct rhashtable_iter *iter)
> * the table hasn't changed.
> */
> iter->skip--;
> - }
> + } else
> + /* ->skip is only zero after rhashtable_walk_start()
> + * or when the iterator is reset. In this case there
> + * is no previous object to return.
> + */
> + return NULL;
CodingStyle: need {} on the *else* branch if the 1st branch has them.
>
> return __rhashtable_walk_find_next(iter);
> }
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 4/4] selftests/bpf: fix compiling errors
From: Du, Changbin @ 2018-03-27 10:19 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Du, Changbin, Alexei Starovoitov, shuah, linux-kselftest,
linux-kernel, netdev
In-Reply-To: <90ce8146-cecd-c928-f9c6-470db97b2051@iogearbox.net>
On Tue, Mar 27, 2018 at 11:52:27AM +0200, Daniel Borkmann wrote:
> On 03/27/2018 11:00 AM, Du, Changbin wrote:
> > On Tue, Mar 27, 2018 at 10:52:57AM +0200, Daniel Borkmann wrote:
> >> On 03/27/2018 05:06 AM, Du, Changbin wrote:
> >>> On Mon, Mar 26, 2018 at 08:02:30PM -0700, Alexei Starovoitov wrote:
> >>>> On Tue, Mar 27, 2018 at 10:20:10AM +0800, Du, Changbin wrote:
> >>>>> On Mon, Mar 26, 2018 at 07:55:13AM -0700, Alexei Starovoitov wrote:
> >>>>>> On Mon, Mar 26, 2018 at 05:23:28PM +0800, changbin.du@intel.com wrote:
> >>>>>>> Signed-off-by: Changbin Du <changbin.du@intel.com>
> >>>>>>> ---
> >>>>>>> tools/testing/selftests/bpf/Makefile | 5 +++--
> >>>>>>> 1 file changed, 3 insertions(+), 2 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> >>>>>>> index 5c43c18..dc0fdc8 100644
> >>>>>>> --- a/tools/testing/selftests/bpf/Makefile
> >>>>>>> +++ b/tools/testing/selftests/bpf/Makefile
> >>>>>>> @@ -10,7 +10,8 @@ ifneq ($(wildcard $(GENHDR)),)
> >>>>>>> GENFLAGS := -DHAVE_GENHDR
> >>>>>>> endif
> >>>>>>>
> >>>>>>> -CFLAGS += -Wall -O2 -I$(APIDIR) -I$(LIBDIR) -I$(GENDIR) $(GENFLAGS) -I../../../include
> >>>>>>> +CFLAGS += -Wall -O2 -I$(APIDIR) -I$(LIBDIR) -I$(GENDIR) $(GENFLAGS) \
> >>>>>>> + -I../../../include -I../../../../usr/include
> >>>>>>> LDLIBS += -lcap -lelf -lrt -lpthread
> >>>>>>>
> >>>>>>> # Order correspond to 'make run_tests' order
> >>>>>>> @@ -62,7 +63,7 @@ else
> >>>>>>> CPU ?= generic
> >>>>>>> endif
> >>>>>>>
> >>>>>>> -CLANG_FLAGS = -I. -I./include/uapi -I../../../include/uapi \
> >>>>>>> +CLANG_FLAGS = -I. -I./include/uapi -I../../../include/uapi -I../../../../usr/include \
> >>>>>>> -Wno-compare-distinct-pointer-types
> >>>>>>
> >>>>>> Nack.
> >>>>>> I suspect that will break the build for everyone else who's doing it in the directory
> >>>>>> itself instead of the outer one.
> >>>>>
> >>>>> This one? But I didn't see any problem.
> >>>>
> >>>> because the build was lucky and additional path ../../../../usr/include didn't point
> >>>> to a valid dir?
> >>
> >> Agree.
> >>
> >>> I am sorry but I don't understand why you mean *lucky*. Of cause, the path is valid.
> >>
> >> The problem is that this suddenly requires users to do a 'make headers_install' in
> >> order to populate usr/include/ directory in the first place. While it's annoying
> >> enough for BPF samples where this is needed, I absolutely don't want to introduce
> >> this for BPF kselftests. It's the wrong approach. Besides, in tools infra, there is
> >> a tools/arch/*/include/uapi/asm/bitsperlong.h header copy already, so we really need
> >> to use that instead. Please adapt your patch accordingly and respin. Please also Cc
> >> us and netdev@vger.kernel.org for BPF kselftests changes.
> >>
> > Thanks for the explanation. So we expect that tools/arch/*/include is in the searching list, right?
> > The corrent makefile seems not. How do you get this built?
>
> E.g. take a look at tools/include/asm/barrier.h or tools/include/uapi/asm/bpf_perf_event.h
> just to name two examples. We'd need something similar to this which then points to the
> arch specific includes.
>
> Thanks,
> Daniel
>
ok, I see. But I am going to skip this fix this time. Because one get fixed, another appears.
IMHO, It doesn't sound like a good idea to sync all these files manually. We should have
better solution I think.
clang -I. -I./include/uapi -I../../../include/uapi -Wno-compare-distinct-pointer-types \
-O2 -target bpf -emit-llvm -c test_pkt_access.c -o - | \
llc -march=bpf -mcpu=generic -filetype=obj -o /home/changbin/work/linux/tools/testing/selftests/bpf/test_pkt_access.o
In file included from test_pkt_access.c:12:
/usr/include/linux/ip.h:20:10: fatal error: 'asm/byteorder.h' file not found
#include <asm/byteorder.h>
> > changbin@gvt-dell-host:~/work/linux/tools/testing/selftests/bpf$ make -p
> > [...]
> > clang -I. -I./include/uapi -I../../../include/uapi -Wno-compare-distinct-pointer-types \
> > -O2 -target bpf -emit-llvm -c test_pkt_access.c -o - | \
> > llc -march=bpf -mcpu=generic -filetype=obj -o /home/changbin/work/linux/tools/testing/selftests/bpf/test_pkt_access.o
> > In file included from test_pkt_access.c:9:
> > In file included from ../../../include/uapi/linux/bpf.h:11:
> > In file included from ./include/uapi/linux/types.h:5:
> > /usr/include/asm-generic/int-ll64.h:11:10: fatal error: 'asm/bitsperlong.h' file not found
> > #include <asm/bitsperlong.h>
> >
> >
>
--
Thanks,
Changbin Du
^ permalink raw reply
* RE: [RFC PATCH v2] net: phy: Added device tree binding for dev-addr and dev-addr code check-up
From: Vicenţiu Galanopulo @ 2018-03-27 10:02 UTC (permalink / raw)
To: Florian Fainelli, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, davem@davemloft.net, marcel@holtmann.org,
devicetree@vger.kernel.org
Cc: Madalin-cristian Bucur, Alexandru Marginean
In-Reply-To: <5726f7e4-49eb-e87e-8548-82fac6aa0452@gmail.com>
> -----Original Message-----
> From: Florian Fainelli [mailto:f.fainelli@gmail.com]
> Sent: Tuesday, March 27, 2018 1:45 AM
> To: Vicenţiu Galanopulo <vicentiu.galanopulo@nxp.com>;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; robh+dt@kernel.org;
> mark.rutland@arm.com; davem@davemloft.net; marcel@holtmann.org;
> devicetree@vger.kernel.org
> Cc: Madalin-cristian Bucur <madalin.bucur@nxp.com>; Alexandru Marginean
> <alexandru.marginean@nxp.com>
> Subject: Re: [RFC PATCH v2] net: phy: Added device tree binding for dev-addr
> and dev-addr code check-up
>
> On 03/23/2018 08:05 AM, Vicentiu Galanopulo wrote:
> > Reason for this patch is that the Inphi PHY has a vendor specific
> > address space for accessing the
> > C45 MDIO registers - starting from 0x1e.
> >
> > A search of the dev-addr property is done in of_mdiobus_register.
> > If the property is found in the PHY node,
> > of_mdiobus_register_static_phy is called. This is a wrapper function
> > for of_mdiobus_register_phy which finds the device in package based on
> > dev-addr and fills devices_addrs:
> > devices_addrs is a new field added to phy_c45_device_ids.
> > This new field will store the dev-addr property on the same index
> > where the device in package has been found.
> > In order to have dev-addr in get_phy_c45_ids(), mdio_c45_ids is passed
> > from of_mdio.c to phy_device.c as an external variable.
> > In get_phy_device a copy of the mdio_c45_ids is done over the local
> > c45_ids (wich are empty). After the copying, the c45_ids will also
> > contain the static device found from dev-addr.
> > Having dev-addr stored in devices_addrs, in get_phy_c45_ids(), when
> > probing the identifiers, dev-addr can be extracted from devices_addrs
> > and probed if devices_addrs[current_identifier] is not 0.
> > This way changing the kernel API is avoided completely.
> >
> > As a plus to this patch, num_ids in get_phy_c45_ids, has the value 8
> > (ARRAY_SIZE(c45_ids->device_ids)),
> > but the u32 *devs can store 32 devices in the bitfield.
> > If a device is stored in *devs, in bits 32 to 9, it will not be found.
> > This is the reason for changing in phy.h, the size of device_ids
> > array.
> >
> > Signed-off-by: Vicentiu Galanopulo <vicentiu.galanopulo@nxp.com>
> > ---
>
> Correct me if I am completely misunderstanding the problem, but have you
> considered doing the following:
>
> - if all you need to is to replace instances of loops that do:
>
> if (phydev->is_c45) {
> for (i = 1; i < num_ids; i++) {
> if (!(phydev->c45_ids.devices_in_package & (1 <<
> i)))
> continue;
>
> with one that starts at dev-addr, as specified by Device Tree, then I suspect
> there is an easier way to do what you want rather than your fairly intrusive
> patch to do that:
>
Sorry for the lengthy comment and sorry if this is redundant, I'm just trying to explain
best that I can my patch:
The loop goes through the devices_in_packages, and where it finds a bit that is set, it
continues to get the PHY device ID.
But, to have devices_in_package with those bits set, a previous querying of the
MDIO_DEVS2 and MDIO_DEVS1 is necessary. And in the MDIO bus query,
dev-addr, from the device tree, is part of the whole register address:
reg_addr = MII_ADDR_C45 | dev_addr << 16 | MDIO_DEVS2;
Andrew suggested in his first comment that the device tree lookup could be done
in of_mdiobus_register(), probably because of the loop which already checks the
<reg> property of the PHY.
My understanding of his comments was that I could propagate, as a parameter,
dev-addr, down the hierarchy call of_mdiobus_register_phy()-> get_phy_device()->
get_phy_id()->get_phy_c45_ids()->get_phy_c45_devs_in_pkg(dev_addr param existed here).
This is where the loop you're mentioning needed some altering, because the loop index is
actually the dev_addr parameter from get_phy_c45_devs_in_pkg(), and it's from 1 to 7 (num_ids = 8)
This worked for the other PHYs which had dev-addr in this range, but it doesn't work for the INPHI,
which has dev_add = 30 (0x1e).
After I did the extension of the device_ids from 8 to 32 to match
the devs (u32 *devs = &c45_ids->devices_in_package;) in get_phy_c45_ids() :
- u32 device_ids[8];
+ u32 device_ids[32];
I realized that dev_addr for other PHY vendors could be larger than 31 (just a coincidence that
for INPHI is 30 and it fits), and that dev-addr should be a separate parameter, that still
has to match the bit position from *devs (&c45_ids->devices_in_package)
So, I didn't had to change the loop to start from dev-addr, just to let it check if the bit is set in *devs (as before),
and if that bit corresponds to the INPHI PHY (dev-addr has been set in the PHY device tree node), use
dev-addr in getting the PHY ID.
The loop start index has to remain the same because other PHY vendors have dev-addr 1 to 7, and
PHY discovering succeeds.
For other issues that I had with the above solution (plus Andrew's comment about the SMP), I uploaded
a v3... probably slightly before you made this comment. Please have look at it, and paste the below
comments if they still apply. I was not able to match them with my latest patch...
Thanks,
Vicentiu
> - patch of_mdiobus_register_phy() to lookup both the c45 compatible string as
> well as fetch the "dev-addr" property
>
> - provide a PHY Device Tree node that has its OUI as a compatible string (see
> of_get_phy_id() for details), or if it has a specified 'dev-addr'
> property, use that in lieu of the default get_phy_device() logic
>
> - pass both to phy_device_create() and eventually introduce a helper function
> that lets you populate the c45_ids structure
>
> Then for each function that does the loop above, as long as you have a phydev
> reference, you can have phydev->dev_addr = 0x1e be where to start from, if it is
> 0, then start at 1 (like it currently is). If you don't have a phy device reference,
> which would be get_phy_c45_ids() then just make sure you don't call that
> function :)
>
> > struct phy_c45_device_ids {
> > u32 devices_in_package;
> > - u32 device_ids[8];
> > + u32 device_ids[32];
> > + u32 devices_addrs[32];
> > };
>
> This looks like a fix in itself, so it is worth a separate patch.
> --
> Florian
^ permalink raw reply
* Re: [PATCH 4/4] selftests/bpf: fix compiling errors
From: Daniel Borkmann @ 2018-03-27 9:52 UTC (permalink / raw)
To: Du, Changbin
Cc: Alexei Starovoitov, shuah, linux-kselftest, linux-kernel, netdev
In-Reply-To: <20180327090000.fou6oyvr663lbyuq@intel.com>
On 03/27/2018 11:00 AM, Du, Changbin wrote:
> On Tue, Mar 27, 2018 at 10:52:57AM +0200, Daniel Borkmann wrote:
>> On 03/27/2018 05:06 AM, Du, Changbin wrote:
>>> On Mon, Mar 26, 2018 at 08:02:30PM -0700, Alexei Starovoitov wrote:
>>>> On Tue, Mar 27, 2018 at 10:20:10AM +0800, Du, Changbin wrote:
>>>>> On Mon, Mar 26, 2018 at 07:55:13AM -0700, Alexei Starovoitov wrote:
>>>>>> On Mon, Mar 26, 2018 at 05:23:28PM +0800, changbin.du@intel.com wrote:
>>>>>>> Signed-off-by: Changbin Du <changbin.du@intel.com>
>>>>>>> ---
>>>>>>> tools/testing/selftests/bpf/Makefile | 5 +++--
>>>>>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
>>>>>>> index 5c43c18..dc0fdc8 100644
>>>>>>> --- a/tools/testing/selftests/bpf/Makefile
>>>>>>> +++ b/tools/testing/selftests/bpf/Makefile
>>>>>>> @@ -10,7 +10,8 @@ ifneq ($(wildcard $(GENHDR)),)
>>>>>>> GENFLAGS := -DHAVE_GENHDR
>>>>>>> endif
>>>>>>>
>>>>>>> -CFLAGS += -Wall -O2 -I$(APIDIR) -I$(LIBDIR) -I$(GENDIR) $(GENFLAGS) -I../../../include
>>>>>>> +CFLAGS += -Wall -O2 -I$(APIDIR) -I$(LIBDIR) -I$(GENDIR) $(GENFLAGS) \
>>>>>>> + -I../../../include -I../../../../usr/include
>>>>>>> LDLIBS += -lcap -lelf -lrt -lpthread
>>>>>>>
>>>>>>> # Order correspond to 'make run_tests' order
>>>>>>> @@ -62,7 +63,7 @@ else
>>>>>>> CPU ?= generic
>>>>>>> endif
>>>>>>>
>>>>>>> -CLANG_FLAGS = -I. -I./include/uapi -I../../../include/uapi \
>>>>>>> +CLANG_FLAGS = -I. -I./include/uapi -I../../../include/uapi -I../../../../usr/include \
>>>>>>> -Wno-compare-distinct-pointer-types
>>>>>>
>>>>>> Nack.
>>>>>> I suspect that will break the build for everyone else who's doing it in the directory
>>>>>> itself instead of the outer one.
>>>>>
>>>>> This one? But I didn't see any problem.
>>>>
>>>> because the build was lucky and additional path ../../../../usr/include didn't point
>>>> to a valid dir?
>>
>> Agree.
>>
>>> I am sorry but I don't understand why you mean *lucky*. Of cause, the path is valid.
>>
>> The problem is that this suddenly requires users to do a 'make headers_install' in
>> order to populate usr/include/ directory in the first place. While it's annoying
>> enough for BPF samples where this is needed, I absolutely don't want to introduce
>> this for BPF kselftests. It's the wrong approach. Besides, in tools infra, there is
>> a tools/arch/*/include/uapi/asm/bitsperlong.h header copy already, so we really need
>> to use that instead. Please adapt your patch accordingly and respin. Please also Cc
>> us and netdev@vger.kernel.org for BPF kselftests changes.
>>
> Thanks for the explanation. So we expect that tools/arch/*/include is in the searching list, right?
> The corrent makefile seems not. How do you get this built?
E.g. take a look at tools/include/asm/barrier.h or tools/include/uapi/asm/bpf_perf_event.h
just to name two examples. We'd need something similar to this which then points to the
arch specific includes.
Thanks,
Daniel
> changbin@gvt-dell-host:~/work/linux/tools/testing/selftests/bpf$ make -p
> [...]
> clang -I. -I./include/uapi -I../../../include/uapi -Wno-compare-distinct-pointer-types \
> -O2 -target bpf -emit-llvm -c test_pkt_access.c -o - | \
> llc -march=bpf -mcpu=generic -filetype=obj -o /home/changbin/work/linux/tools/testing/selftests/bpf/test_pkt_access.o
> In file included from test_pkt_access.c:9:
> In file included from ../../../include/uapi/linux/bpf.h:11:
> In file included from ./include/uapi/linux/types.h:5:
> /usr/include/asm-generic/int-ll64.h:11:10: fatal error: 'asm/bitsperlong.h' file not found
> #include <asm/bitsperlong.h>
>
>
^ permalink raw reply
* [PATCH v3 2/2] net: macb: Try to retrieve MAC addess from nvmem provider
From: Mike Looijmans @ 2018-03-27 9:52 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, devicetree, andrew, f.fainelli, robh+dt,
frowand.list, Mike Looijmans
In-Reply-To: <1522144346-32367-1-git-send-email-mike.looijmans@topic.nl>
Call of_get_nvmem_mac_address() to fetch the MAC address from an nvmem
cell, if one is provided in the device tree. This allows the address to
be stored in an I2C EEPROM device for example.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
---
drivers/net/ethernet/cadence/macb_main.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index e84afcf..eabe14f 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -3950,10 +3950,16 @@ static int macb_probe(struct platform_device *pdev)
dev->max_mtu = ETH_DATA_LEN;
mac = of_get_mac_address(np);
- if (mac)
+ if (mac) {
ether_addr_copy(bp->dev->dev_addr, mac);
- else
- macb_get_hwaddr(bp);
+ } else {
+ err = of_get_nvmem_mac_address(np, bp->dev->dev_addr);
+ if (err) {
+ if (err == -EPROBE_DEFER)
+ goto err_out_free_netdev;
+ macb_get_hwaddr(bp);
+ }
+ }
err = of_get_phy_mode(np);
if (err < 0) {
--
1.9.1
^ permalink raw reply related
* [PATCH v3 1/2] of_net: Implement of_get_nvmem_mac_address helper
From: Mike Looijmans @ 2018-03-27 9:52 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, devicetree, andrew, f.fainelli, robh+dt,
frowand.list, Mike Looijmans
In-Reply-To: <1522144346-32367-1-git-send-email-mike.looijmans@topic.nl>
It's common practice to store MAC addresses for network interfaces into
nvmem devices. However the code to actually do this in the kernel lacks,
so this patch adds of_get_nvmem_mac_address() for drivers to obtain the
address from an nvmem cell provider.
This is particulary useful on devices where the ethernet interface cannot
be configured by the bootloader, for example because it's in an FPGA.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
---
Documentation/devicetree/bindings/net/ethernet.txt | 2 ++
drivers/of/of_net.c | 40 ++++++++++++++++++++++
include/linux/of_net.h | 6 ++++
3 files changed, 48 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/ethernet.txt b/Documentation/devicetree/bindings/net/ethernet.txt
index 2974e63..cfc376b 100644
--- a/Documentation/devicetree/bindings/net/ethernet.txt
+++ b/Documentation/devicetree/bindings/net/ethernet.txt
@@ -10,6 +10,8 @@ Documentation/devicetree/bindings/phy/phy-bindings.txt.
the boot program; should be used in cases where the MAC address assigned to
the device by the boot program is different from the "local-mac-address"
property;
+- nvmem-cells: phandle, reference to an nvmem node for the MAC address;
+- nvmem-cell-names: string, should be "mac-address" if nvmem is to be used;
- max-speed: number, specifies maximum speed in Mbit/s supported by the device;
- max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather than
the maximum frame size (there's contradiction in the Devicetree
diff --git a/drivers/of/of_net.c b/drivers/of/of_net.c
index d820f3e..1c5d372 100644
--- a/drivers/of/of_net.c
+++ b/drivers/of/of_net.c
@@ -7,6 +7,7 @@
*/
#include <linux/etherdevice.h>
#include <linux/kernel.h>
+#include <linux/nvmem-consumer.h>
#include <linux/of_net.h>
#include <linux/phy.h>
#include <linux/export.h>
@@ -80,3 +81,42 @@ const void *of_get_mac_address(struct device_node *np)
return of_get_mac_addr(np, "address");
}
EXPORT_SYMBOL(of_get_mac_address);
+
+/**
+ * Obtain the MAC address from an nvmem provider named 'mac-address' through
+ * device tree.
+ * On success, copies the new address into memory pointed to by addr and
+ * returns 0. Returns a negative error code otherwise.
+ * @np: Device tree node containing the nvmem-cells phandle
+ * @addr: Pointer to receive the MAC address using ether_addr_copy()
+ */
+int of_get_nvmem_mac_address(struct device_node *np, void *addr)
+{
+ struct nvmem_cell *cell;
+ const void *mac;
+ size_t len;
+ int ret;
+
+ cell = of_nvmem_cell_get(np, "mac-address");
+ if (IS_ERR(cell))
+ return PTR_ERR(cell);
+
+ mac = nvmem_cell_read(cell, &len);
+
+ nvmem_cell_put(cell);
+
+ if (IS_ERR(mac))
+ return PTR_ERR(mac);
+
+ if (len < 6 || !is_valid_ether_addr(mac)) {
+ ret = -EINVAL;
+ } else {
+ ether_addr_copy(addr, mac);
+ ret = 0;
+ }
+
+ kfree(mac);
+
+ return ret;
+}
+EXPORT_SYMBOL(of_get_nvmem_mac_address);
diff --git a/include/linux/of_net.h b/include/linux/of_net.h
index 9cd72aa..90d81ee 100644
--- a/include/linux/of_net.h
+++ b/include/linux/of_net.h
@@ -13,6 +13,7 @@
struct net_device;
extern int of_get_phy_mode(struct device_node *np);
extern const void *of_get_mac_address(struct device_node *np);
+extern int of_get_nvmem_mac_address(struct device_node *np, void *addr);
extern struct net_device *of_find_net_device_by_node(struct device_node *np);
#else
static inline int of_get_phy_mode(struct device_node *np)
@@ -25,6 +26,11 @@ static inline const void *of_get_mac_address(struct device_node *np)
return NULL;
}
+static inline int of_get_nvmem_mac_address(struct device_node *np, void *addr)
+{
+ return -ENODEV;
+}
+
static inline struct net_device *of_find_net_device_by_node(struct device_node *np)
{
return NULL;
--
1.9.1
^ 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