* [PATCH net-next V1 06/11] net/mlx4_core: Fix struct mlx4_vhcr_cmd to make implicit padding explicit
From: Amir Vadai @ 2015-01-27 13:58 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Amir Vadai, Yevgeny Petrilin,
Jack Morgenstein
In-Reply-To: <1422367089-13419-1-git-send-email-amirv@mellanox.com>
From: Jack Morgenstein <jackm@dev.mellanox.co.il>
Struct mlx4_vhcr was implicitly padded by the gcc compiler on 64-bit
architectures.
This commit makes that padding explicit, to prevent issues with
changing compilers and with incompatibilities between 32-bit architecture
implicit padding and 64-bit architecture implicit padding.
This structure is used in virtualization for communication between
the Host and its Guests. The explicit padding allows 64-bit Hosts
(old and new) to continue to interoperate with 64-bit Guests (old and new).
However, without this fix, 64-bit Hosts could not interoperate with 32-bit
Guests (since these did not insert the padding dword). With this fix,
32-bit Guests will be able to interoperate with 64-bit Hosts (since
the structure offsets will be identical on both).
Reported-by: Alexander Schmidt <alexs@linux.vnet.ibm.com>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/mlx4.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4.h b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
index 096a81c..148dc09 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
@@ -196,6 +196,7 @@ struct mlx4_vhcr {
struct mlx4_vhcr_cmd {
__be64 in_param;
__be32 in_modifier;
+ u32 reserved1;
__be64 out_param;
__be16 token;
u16 reserved;
--
1.9.3
^ permalink raw reply related
* [PATCH net-next V1 03/11] net/mlx4_core: Fix mem leak in SRIOV mlx4_init_one error flow
From: Amir Vadai @ 2015-01-27 13:58 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Amir Vadai, Yevgeny Petrilin,
Jack Morgenstein
In-Reply-To: <1422367089-13419-1-git-send-email-amirv@mellanox.com>
From: Jack Morgenstein <jackm@dev.mellanox.co.il>
Structs allocated for the resource tracker must be freed in
the error flow.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index 46531c2..ab990f9 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -2980,8 +2980,10 @@ err_free_eq:
mlx4_free_eq_table(dev);
err_master_mfunc:
- if (mlx4_is_master(dev))
+ if (mlx4_is_master(dev)) {
+ mlx4_free_resource_tracker(dev, RES_TR_FREE_STRUCTS_ONLY);
mlx4_multi_func_cleanup(dev);
+ }
if (mlx4_is_slave(dev)) {
kfree(dev->caps.qp0_qkey);
--
1.9.3
^ permalink raw reply related
* Re: [PATCH net 0/2] netns: audit netdevice creation with IFLA_NET_NS_[PID|FD]
From: Alexander Aring @ 2015-01-27 14:06 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev, davem, arvid.brodin, linux-wpan
In-Reply-To: <54C7928F.9010002@6wind.com>
Hi,
On Tue, Jan 27, 2015 at 02:28:47PM +0100, Nicolas Dichtel wrote:
...
> >With the check of "!net_eq(src_net, &init_net)" we need to be sure
> >that the wpan interface is always in "init_net". This means we need
> >definitely a dev->features |= NETIF_F_NETNS_LOCAL; somewhere in [0].
> >
> >To adding "dev->features |= NETIF_F_NETNS_LOCAL;" for a 6LoWPAN interface,
> >I am not sure about this. I didn't test it yet and it will not break
> >anything, but we will lost the support for making net namespaces stuff
> >inside the IPv6/(netfilter) stack.
> Adding NETIF_F_NETNS_LOCAL does not mean that the netdevice can be used only
> in init_net, this flag means that the netdevice cannot be moved to another
> netns. You can still create a netdevice in another netns (if wpan0 is in netns
> foo):
>
> $ ip netns exec foo ip link add link wpan0 name lowpan0 type lowpan
>
> I don't know how wpan0 is created and if this interface can be created directly
> in another netns than init_net.
>
no it can't. The wpan0 interface can be created via the 802.15.4
userspace tools and we don't have such option for namespaces. It
should be always to init_net while creation.
> >
> >
> >Summarize:
> >
> >I would add the dev->features |= NETIF_F_NETNS_LOCAL; while wpan
> >interface generation and add only the !net_eq(src_net, &init_net) check
> >above. I suppose that src_net is the net namespace from "underlaying"
> >interface wpan by calling:
> >
> >$ ip link add link wpan0 name lowpan0 type lowpan
> No. src_net is the netns where the ip command is launched. With this patch, my
ah, and when no "ip netns" is given it's default to init_net?
Okay, then I agree with that both interfaces should be set
dev->features |= NETIF_F_NETNS_LOCAL
because both interfaces should started with "init_net" as default
namespace. For wpan interface this should always be in "init_net",
because we don't set anything while creation.
For 6LoWPAN interface this should also always in the same namespace like
the wpan interface and not diffrent namespace between link (wpan) and
virtual (6LoWPAN) interface.
Do you agree with that?
- Alex
^ permalink raw reply
* [PATCH] csiostor:T5 Firmware fix and cleanup.
From: Praveen Madhavan @ 2015-01-27 14:16 UTC (permalink / raw)
To: netdev, linux-scsi; +Cc: davem, JBottomley, hch, hariprasad, praveenm, varun
This patch fix is to use default firmware configuration files
present in the adapter incase if not available in standard
/lib/firmware/* dir. Additional cleanup is done to reuse flash
related defines from cxgb4 header file.
Please apply over net-next since it depends on previous commit.
Signed-off-by: Praveen Madhavan <praveenm@chelsio.com>
---
drivers/scsi/csiostor/csio_hw.c | 342 +++++++++++++----------------------
drivers/scsi/csiostor/csio_hw.h | 40 +---
drivers/scsi/csiostor/csio_hw_chip.h | 1 -
3 files changed, 127 insertions(+), 256 deletions(-)
diff --git a/drivers/scsi/csiostor/csio_hw.c b/drivers/scsi/csiostor/csio_hw.c
index 35c5f83..c81b06b 100644
--- a/drivers/scsi/csiostor/csio_hw.c
+++ b/drivers/scsi/csiostor/csio_hw.c
@@ -636,7 +636,7 @@ csio_hw_print_fw_version(struct csio_hw *hw, char *str)
static int
csio_hw_get_fw_version(struct csio_hw *hw, uint32_t *vers)
{
- return csio_hw_read_flash(hw, FW_IMG_START +
+ return csio_hw_read_flash(hw, FLASH_FW_START +
offsetof(struct fw_hdr, fw_ver), 1,
vers, 0);
}
@@ -696,9 +696,9 @@ csio_hw_fw_dload(struct csio_hw *hw, uint8_t *fw_data, uint32_t size)
return -EINVAL;
}
- if (size > FW_MAX_SIZE) {
+ if (size > FLASH_FW_MAX_SIZE) {
csio_err(hw, "FW image too large, max is %u bytes\n",
- FW_MAX_SIZE);
+ FLASH_FW_MAX_SIZE);
return -EINVAL;
}
@@ -714,10 +714,10 @@ csio_hw_fw_dload(struct csio_hw *hw, uint8_t *fw_data, uint32_t size)
i = DIV_ROUND_UP(size, sf_sec_size); /* # of sectors spanned */
csio_dbg(hw, "Erasing sectors... start:%d end:%d\n",
- FW_START_SEC, FW_START_SEC + i - 1);
+ FLASH_FW_START_SEC, FLASH_FW_START_SEC + i - 1);
- ret = csio_hw_flash_erase_sectors(hw, FW_START_SEC,
- FW_START_SEC + i - 1);
+ ret = csio_hw_flash_erase_sectors(hw, FLASH_FW_START_SEC,
+ FLASH_FW_START_SEC + i - 1);
if (ret) {
csio_err(hw, "Flash Erase failed\n");
goto out;
@@ -730,14 +730,14 @@ csio_hw_fw_dload(struct csio_hw *hw, uint8_t *fw_data, uint32_t size)
*/
memcpy(first_page, fw_data, SF_PAGE_SIZE);
((struct fw_hdr *)first_page)->fw_ver = htonl(0xffffffff);
- ret = csio_hw_write_flash(hw, FW_IMG_START, SF_PAGE_SIZE, first_page);
+ ret = csio_hw_write_flash(hw, FLASH_FW_START, SF_PAGE_SIZE, first_page);
if (ret)
goto out;
csio_dbg(hw, "Writing Flash .. start:%d end:%d\n",
FW_IMG_START, FW_IMG_START + size);
- addr = FW_IMG_START;
+ addr = FLASH_FW_START;
for (size -= SF_PAGE_SIZE; size; size -= SF_PAGE_SIZE) {
addr += SF_PAGE_SIZE;
fw_data += SF_PAGE_SIZE;
@@ -747,7 +747,7 @@ csio_hw_fw_dload(struct csio_hw *hw, uint8_t *fw_data, uint32_t size)
}
ret = csio_hw_write_flash(hw,
- FW_IMG_START +
+ FLASH_FW_START +
offsetof(struct fw_hdr, fw_ver),
sizeof(hdr->fw_ver),
(const uint8_t *)&hdr->fw_ver);
@@ -1250,116 +1250,6 @@ csio_hw_fw_upgrade(struct csio_hw *hw, uint32_t mbox,
return csio_hw_fw_restart(hw, mbox, reset);
}
-
-/*
- * csio_hw_fw_config_file - setup an adapter via a Configuration File
- * @hw: the HW module
- * @mbox: mailbox to use for the FW command
- * @mtype: the memory type where the Configuration File is located
- * @maddr: the memory address where the Configuration File is located
- * @finiver: return value for CF [fini] version
- * @finicsum: return value for CF [fini] checksum
- * @cfcsum: return value for CF computed checksum
- *
- * Issue a command to get the firmware to process the Configuration
- * File located at the specified mtype/maddress. If the Configuration
- * File is processed successfully and return value pointers are
- * provided, the Configuration File "[fini] section version and
- * checksum values will be returned along with the computed checksum.
- * It's up to the caller to decide how it wants to respond to the
- * checksums not matching but it recommended that a prominant warning
- * be emitted in order to help people rapidly identify changed or
- * corrupted Configuration Files.
- *
- * Also note that it's possible to modify things like "niccaps",
- * "toecaps",etc. between processing the Configuration File and telling
- * the firmware to use the new configuration. Callers which want to
- * do this will need to "hand-roll" their own CAPS_CONFIGS commands for
- * Configuration Files if they want to do this.
- */
-static int
-csio_hw_fw_config_file(struct csio_hw *hw,
- unsigned int mtype, unsigned int maddr,
- uint32_t *finiver, uint32_t *finicsum, uint32_t *cfcsum)
-{
- struct csio_mb *mbp;
- struct fw_caps_config_cmd *caps_cmd;
- int rv = -EINVAL;
- enum fw_retval ret;
-
- mbp = mempool_alloc(hw->mb_mempool, GFP_ATOMIC);
- if (!mbp) {
- CSIO_INC_STATS(hw, n_err_nomem);
- return -ENOMEM;
- }
- /*
- * Tell the firmware to process the indicated Configuration File.
- * If there are no errors and the caller has provided return value
- * pointers for the [fini] section version, checksum and computed
- * checksum, pass those back to the caller.
- */
- caps_cmd = (struct fw_caps_config_cmd *)(mbp->mb);
- CSIO_INIT_MBP(mbp, caps_cmd, CSIO_MB_DEFAULT_TMO, hw, NULL, 1);
- caps_cmd->op_to_write =
- htonl(FW_CMD_OP_V(FW_CAPS_CONFIG_CMD) |
- FW_CMD_REQUEST_F |
- FW_CMD_READ_F);
- caps_cmd->cfvalid_to_len16 =
- htonl(FW_CAPS_CONFIG_CMD_CFVALID_F |
- FW_CAPS_CONFIG_CMD_MEMTYPE_CF_V(mtype) |
- FW_CAPS_CONFIG_CMD_MEMADDR64K_CF_V(maddr >> 16) |
- FW_LEN16(*caps_cmd));
-
- if (csio_mb_issue(hw, mbp)) {
- csio_err(hw, "Issue of FW_CAPS_CONFIG_CMD failed!\n");
- goto out;
- }
-
- ret = csio_mb_fw_retval(mbp);
- if (ret != FW_SUCCESS) {
- csio_dbg(hw, "FW_CAPS_CONFIG_CMD returned %d!\n", rv);
- goto out;
- }
-
- if (finiver)
- *finiver = ntohl(caps_cmd->finiver);
- if (finicsum)
- *finicsum = ntohl(caps_cmd->finicsum);
- if (cfcsum)
- *cfcsum = ntohl(caps_cmd->cfcsum);
-
- /* Validate device capabilities */
- if (csio_hw_validate_caps(hw, mbp)) {
- rv = -ENOENT;
- goto out;
- }
-
- /*
- * And now tell the firmware to use the configuration we just loaded.
- */
- caps_cmd->op_to_write =
- htonl(FW_CMD_OP_V(FW_CAPS_CONFIG_CMD) |
- FW_CMD_REQUEST_F |
- FW_CMD_WRITE_F);
- caps_cmd->cfvalid_to_len16 = htonl(FW_LEN16(*caps_cmd));
-
- if (csio_mb_issue(hw, mbp)) {
- csio_err(hw, "Issue of FW_CAPS_CONFIG_CMD failed!\n");
- goto out;
- }
-
- ret = csio_mb_fw_retval(mbp);
- if (ret != FW_SUCCESS) {
- csio_dbg(hw, "FW_CAPS_CONFIG_CMD returned %d!\n", rv);
- goto out;
- }
-
- rv = 0;
-out:
- mempool_free(mbp, hw->mb_mempool);
- return rv;
-}
-
/*
* csio_get_device_params - Get device parameters.
* @hw: HW module
@@ -1762,11 +1652,13 @@ leave:
static int
csio_hw_use_fwconfig(struct csio_hw *hw, int reset, u32 *fw_cfg_param)
{
+ struct csio_mb *mbp = NULL;
+ struct fw_caps_config_cmd *caps_cmd;
unsigned int mtype, maddr;
- int rv;
+ int rv = -EINVAL;
uint32_t finiver = 0, finicsum = 0, cfcsum = 0;
- int using_flash;
char path[64];
+ char *config_name = NULL;
/*
* Reset device if necessary
@@ -1786,51 +1678,106 @@ csio_hw_use_fwconfig(struct csio_hw *hw, int reset, u32 *fw_cfg_param)
rv = csio_hw_flash_config(hw, fw_cfg_param, path);
spin_lock_irq(&hw->lock);
if (rv != 0) {
- if (rv == -ENOENT) {
- /*
- * config file was not found. Use default
- * config file from flash.
- */
- mtype = FW_MEMTYPE_CF_FLASH;
- maddr = hw->chip_ops->chip_flash_cfg_addr(hw);
- using_flash = 1;
- } else {
- /*
- * we revert back to the hardwired config if
- * flashing failed.
- */
- goto bye;
- }
+ /*
+ * config file was not found. Use default
+ * config file from flash.
+ */
+ config_name = "On FLASH";
+ mtype = FW_MEMTYPE_CF_FLASH;
+ maddr = hw->chip_ops->chip_flash_cfg_addr(hw);
} else {
+ config_name = path;
mtype = FW_PARAMS_PARAM_Y_G(*fw_cfg_param);
maddr = FW_PARAMS_PARAM_Z_G(*fw_cfg_param) << 16;
- using_flash = 0;
}
- hw->cfg_store = (uint8_t)mtype;
+ mbp = mempool_alloc(hw->mb_mempool, GFP_ATOMIC);
+ if (!mbp) {
+ CSIO_INC_STATS(hw, n_err_nomem);
+ return -ENOMEM;
+ }
+ /*
+ * Tell the firmware to process the indicated Configuration File.
+ * If there are no errors and the caller has provided return value
+ * pointers for the [fini] section version, checksum and computed
+ * checksum, pass those back to the caller.
+ */
+ caps_cmd = (struct fw_caps_config_cmd *)(mbp->mb);
+ CSIO_INIT_MBP(mbp, caps_cmd, CSIO_MB_DEFAULT_TMO, hw, NULL, 1);
+ caps_cmd->op_to_write =
+ htonl(FW_CMD_OP_V(FW_CAPS_CONFIG_CMD) |
+ FW_CMD_REQUEST_F |
+ FW_CMD_READ_F);
+ caps_cmd->cfvalid_to_len16 =
+ htonl(FW_CAPS_CONFIG_CMD_CFVALID_F |
+ FW_CAPS_CONFIG_CMD_MEMTYPE_CF_V(mtype) |
+ FW_CAPS_CONFIG_CMD_MEMADDR64K_CF_V(maddr >> 16) |
+ FW_LEN16(*caps_cmd));
+
+ if (csio_mb_issue(hw, mbp)) {
+ rv = -EINVAL;
+ goto bye;
+ }
+
+ rv = csio_mb_fw_retval(mbp);
+ /* If the CAPS_CONFIG failed with an ENOENT (for a Firmware
+ * Configuration File in FLASH), our last gasp effort is to use the
+ * Firmware Configuration File which is embedded in the
+ * firmware. A very few early versions of the firmware didn't
+ * have one embedded but we can ignore those.
+ */
+ if (rv == ENOENT) {
+ CSIO_INIT_MBP(mbp, caps_cmd, CSIO_MB_DEFAULT_TMO, hw, NULL, 1);
+ caps_cmd->op_to_write = htonl(FW_CMD_OP_V(FW_CAPS_CONFIG_CMD) |
+ FW_CMD_REQUEST_F |
+ FW_CMD_READ_F);
+ caps_cmd->cfvalid_to_len16 = htonl(FW_LEN16(*caps_cmd));
+
+ if (csio_mb_issue(hw, mbp)) {
+ rv = -EINVAL;
+ goto bye;
+ }
+
+ rv = csio_mb_fw_retval(mbp);
+ config_name = "Firmware Default";
+ }
+ if (rv != FW_SUCCESS)
+ goto bye;
+
+ finiver = ntohl(caps_cmd->finiver);
+ finicsum = ntohl(caps_cmd->finicsum);
+ cfcsum = ntohl(caps_cmd->cfcsum);
/*
- * Issue a Capability Configuration command to the firmware to get it
- * to parse the Configuration File.
+ * And now tell the firmware to use the configuration we just loaded.
*/
- rv = csio_hw_fw_config_file(hw, mtype, maddr, &finiver,
- &finicsum, &cfcsum);
- if (rv != 0)
+ caps_cmd->op_to_write =
+ htonl(FW_CMD_OP_V(FW_CAPS_CONFIG_CMD) |
+ FW_CMD_REQUEST_F |
+ FW_CMD_WRITE_F);
+ caps_cmd->cfvalid_to_len16 = htonl(FW_LEN16(*caps_cmd));
+
+ if (csio_mb_issue(hw, mbp)) {
+ rv = -EINVAL;
goto bye;
+ }
- hw->cfg_finiver = finiver;
- hw->cfg_finicsum = finicsum;
- hw->cfg_cfcsum = cfcsum;
- hw->cfg_csum_status = true;
+ rv = csio_mb_fw_retval(mbp);
+ if (rv != FW_SUCCESS) {
+ csio_dbg(hw, "FW_CAPS_CONFIG_CMD returned %d!\n", rv);
+ goto bye;
+ }
+ mempool_free(mbp, hw->mb_mempool);
if (finicsum != cfcsum) {
csio_warn(hw,
"Config File checksum mismatch: csum=%#x, computed=%#x\n",
finicsum, cfcsum);
-
- hw->cfg_csum_status = false;
}
+ /* Validate device capabilities */
+ if (csio_hw_validate_caps(hw, mbp))
+ goto bye;
/*
* Note that we're operating with parameters
* not supplied by the driver, rather than from hard-wired
@@ -1853,55 +1800,19 @@ csio_hw_use_fwconfig(struct csio_hw *hw, int reset, u32 *fw_cfg_param)
/* Post event to notify completion of configuration */
csio_post_event(&hw->sm, CSIO_HWE_INIT);
- csio_info(hw,
- "Firmware Configuration File %s, version %#x, computed checksum %#x\n",
- (using_flash ? "in device FLASH" : path), finiver, cfcsum);
-
+ csio_info(hw, "Successfully configure using Firmware "
+ "Configuration File %s, version %#x, computed checksum %#x\n",
+ config_name, finiver, cfcsum);
return 0;
/*
* Something bad happened. Return the error ...
*/
bye:
+ if (mbp)
+ mempool_free(mbp, hw->mb_mempool);
hw->flags &= ~CSIO_HWF_USING_SOFT_PARAMS;
- csio_dbg(hw, "Configuration file error %d\n", rv);
- return rv;
-}
-
-/*
- * Attempt to initialize the adapter via hard-coded, driver supplied
- * parameters ...
- */
-static int
-csio_hw_no_fwconfig(struct csio_hw *hw, int reset)
-{
- int rv;
- /*
- * Reset device if necessary
- */
- if (reset) {
- rv = csio_do_reset(hw, true);
- if (rv != 0)
- goto out;
- }
-
- /* Get and set device capabilities */
- rv = csio_config_device_caps(hw);
- if (rv != 0)
- goto out;
-
- /* device parameters */
- rv = csio_get_device_params(hw);
- if (rv != 0)
- goto out;
-
- /* Configure SGE */
- csio_wr_sge_init(hw);
-
- /* Post event to notify completion of configuration */
- csio_post_event(&hw->sm, CSIO_HWE_INIT);
-
-out:
+ csio_warn(hw, "Configuration file error %d\n", rv);
return rv;
}
@@ -2101,7 +2012,9 @@ csio_hw_flash_fw(struct csio_hw *hw, int *reset)
if (request_firmware(&fw, FW_FNAME_T5, dev) < 0) {
csio_err(hw, "could not find firmware image %s, err: %d\n",
FW_FNAME_T5, ret);
- return -EINVAL;
+ } else {
+ fw_data = fw->data;
+ fw_size = fw->size;
}
/* allocate memory to read the header of the firmware on the
@@ -2109,9 +2022,6 @@ csio_hw_flash_fw(struct csio_hw *hw, int *reset)
*/
card_fw = kmalloc(sizeof(*card_fw), GFP_KERNEL);
- fw_data = fw->data;
- fw_size = fw->size;
-
/* upgrade FW logic */
ret = csio_hw_prep_fw(hw, fw_info, fw_data, fw_size, card_fw,
hw->fw_state, reset);
@@ -2190,31 +2100,31 @@ csio_hw_configure(struct csio_hw *hw)
if (rv != 0)
goto out;
- /*
- * If the firmware doesn't support Configuration
- * Files, use the old Driver-based, hard-wired
- * initialization. Otherwise, try using the
- * Configuration File support and fall back to the
- * Driver-based initialization if there's no
- * Configuration File found.
+ /* If the firmware doesn't support Configuration Files,
+ * return an error.
*/
- if (csio_hw_check_fwconfig(hw, param) == 0) {
- rv = csio_hw_use_fwconfig(hw, reset, param);
- if (rv == -ENOENT)
- goto out;
- if (rv != 0) {
- csio_info(hw,
- "No Configuration File present "
- "on adapter. Using hard-wired "
- "configuration parameters.\n");
- rv = csio_hw_no_fwconfig(hw, reset);
- }
- } else {
- rv = csio_hw_no_fwconfig(hw, reset);
+ rv = csio_hw_check_fwconfig(hw, param);
+ if (rv != 0) {
+ csio_info(hw, "Firmware doesn't support "
+ "Firmware Configuration files\n");
+ goto out;
}
- if (rv != 0)
+ /* The firmware provides us with a memory buffer where we can
+ * load a Configuration File from the host if we want to
+ * override the Configuration File in flash.
+ */
+ rv = csio_hw_use_fwconfig(hw, reset, param);
+ if (rv == -ENOENT) {
+ csio_info(hw, "Could not initialize "
+ "adapter, error%d\n", rv);
goto out;
+ }
+ if (rv != 0) {
+ csio_info(hw, "Could not initialize "
+ "adapter, error%d\n", rv);
+ goto out;
+ }
} else {
if (hw->fw_state == CSIO_DEV_STATE_INIT) {
diff --git a/drivers/scsi/csiostor/csio_hw.h b/drivers/scsi/csiostor/csio_hw.h
index 1fe8fde..029bef8 100644
--- a/drivers/scsi/csiostor/csio_hw.h
+++ b/drivers/scsi/csiostor/csio_hw.h
@@ -48,6 +48,7 @@
#include <scsi/scsi_device.h>
#include <scsi/scsi_transport_fc.h>
+#include "t4_hw.h"
#include "csio_hw_chip.h"
#include "csio_wr.h"
#include "csio_mb.h"
@@ -174,16 +175,12 @@ struct csio_evt_msg {
};
enum {
- EEPROMVSIZE = 32768, /* Serial EEPROM virtual address space size */
SERNUM_LEN = 16, /* Serial # length */
EC_LEN = 16, /* E/C length */
ID_LEN = 16, /* ID length */
- TRACE_LEN = 112, /* length of trace data and mask */
};
enum {
- SF_PAGE_SIZE = 256, /* serial flash page size */
- SF_SEC_SIZE = 64 * 1024, /* serial flash sector size */
SF_SIZE = SF_SEC_SIZE * 16, /* serial flash size */
};
@@ -199,38 +196,8 @@ enum {
SF_RD_DATA_FAST = 0xb, /* read flash */
SF_RD_ID = 0x9f, /* read ID */
SF_ERASE_SECTOR = 0xd8, /* erase sector */
-
- FW_START_SEC = 8, /* first flash sector for FW */
- FW_IMG_START = FW_START_SEC * SF_SEC_SIZE,
- FW_MAX_SIZE = 16 * SF_SEC_SIZE,
-
- FLASH_CFG_MAX_SIZE = 0x10000 , /* max size of the flash config file*/
- FLASH_CFG_OFFSET = 0x1f0000,
- FLASH_CFG_START_SEC = FLASH_CFG_OFFSET / SF_SEC_SIZE,
};
-/*
- * Flash layout.
- */
-#define FLASH_START(start) ((start) * SF_SEC_SIZE)
-#define FLASH_MAX_SIZE(nsecs) ((nsecs) * SF_SEC_SIZE)
-
-enum {
- /*
- * Location of firmware image in FLASH.
- */
- FLASH_FW_START_SEC = 8,
- FLASH_FW_NSECS = 16,
- FLASH_FW_START = FLASH_START(FLASH_FW_START_SEC),
- FLASH_FW_MAX_SIZE = FLASH_MAX_SIZE(FLASH_FW_NSECS),
-
- /* Location of Firmware Configuration File in FLASH. */
- FLASH_CFG_START = FLASH_START(FLASH_CFG_START_SEC),
-};
-
-#undef FLASH_START
-#undef FLASH_MAX_SIZE
-
/* Management module */
enum {
CSIO_MGMT_EQ_WRSIZE = 512,
@@ -481,11 +448,6 @@ struct csio_hw {
uint32_t tp_vers;
char chip_ver;
uint16_t chip_id; /* Tells T4/T5 chip */
- uint32_t cfg_finiver;
- uint32_t cfg_finicsum;
- uint32_t cfg_cfcsum;
- uint8_t cfg_csum_status;
- uint8_t cfg_store;
enum csio_dev_state fw_state;
struct csio_vpd vpd;
diff --git a/drivers/scsi/csiostor/csio_hw_chip.h b/drivers/scsi/csiostor/csio_hw_chip.h
index e962d3d..a5f624f 100644
--- a/drivers/scsi/csiostor/csio_hw_chip.h
+++ b/drivers/scsi/csiostor/csio_hw_chip.h
@@ -95,7 +95,6 @@ enum { MEM_EDC0, MEM_EDC1, MEM_MC, MEM_MC0 = MEM_MC, MEM_MC1 };
enum {
MEMWIN_APERTURE = 2048,
MEMWIN_BASE = 0x1b800,
- MEMWIN_CSIOSTOR = 6, /* PCI-e Memory Window access */
};
/* Slow path handlers */
--
2.0.2
^ permalink raw reply related
* Re: [PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
From: Vlad Yasevich @ 2015-01-27 14:26 UTC (permalink / raw)
To: Hannes Frederic Sowa, Michael S. Tsirkin
Cc: netdev, Vladislav Yasevich, Ben Hutchings, edumazet,
virtualization
In-Reply-To: <1422366458.13969.11.camel@stressinduktion.org>
On 01/27/2015 08:47 AM, Hannes Frederic Sowa wrote:
> On Di, 2015-01-27 at 10:42 +0200, Michael S. Tsirkin wrote:
>> On Tue, Jan 27, 2015 at 02:47:54AM +0000, Ben Hutchings wrote:
>>> On Mon, 2015-01-26 at 09:37 -0500, Vladislav Yasevich wrote:
>>>> If the IPv6 fragment id has not been set and we perform
>>>> fragmentation due to UFO, select a new fragment id.
>>>> When we store the fragment id into skb_shinfo, set the bit
>>>> in the skb so we can re-use the selected id.
>>>> This preserves the behavior of UFO packets generated on the
>>>> host and solves the issue of id generation for packet sockets
>>>> and tap/macvtap devices.
>>>>
>>>> This patch moves ipv6_select_ident() back in to the header file.
>>>> It also provides the helper function that sets skb_shinfo() frag
>>>> id and sets the bit.
>>>>
>>>> It also makes sure that we select the fragment id when doing
>>>> just gso validation, since it's possible for the packet to
>>>> come from an untrusted source (VM) and be forwarded through
>>>> a UFO enabled device which will expect the fragment id.
>>>>
>>>> CC: Eric Dumazet <edumazet@google.com>
>>>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
>>>> ---
>>>> include/linux/skbuff.h | 3 ++-
>>>> include/net/ipv6.h | 2 ++
>>>> net/ipv6/ip6_output.c | 4 ++--
>>>> net/ipv6/output_core.c | 9 ++++++++-
>>>> net/ipv6/udp_offload.c | 10 +++++++++-
>>>> 5 files changed, 23 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>>>> index 85ab7d7..3ad5203 100644
>>>> --- a/include/linux/skbuff.h
>>>> +++ b/include/linux/skbuff.h
>>>> @@ -605,7 +605,8 @@ struct sk_buff {
>>>> __u8 ipvs_property:1;
>>>> __u8 inner_protocol_type:1;
>>>> __u8 remcsum_offload:1;
>>>> - /* 3 or 5 bit hole */
>>>> + __u8 ufo_fragid_set:1;
>>> [...]
>>>
>>> Doesn't the flag belong in struct skb_shared_info, rather than struct
>>> sk_buff? Otherwise this looks fine.
>>>
>>> Ben.
>>
>> Hmm we seem to be out of tx flags.
>> Maybe ip6_frag_id == 0 should mean "not set".
>
> Maybe that is the best idea. Definitely the ufo_fragid_set bit should
> move into the skb_shared_info area.
That's what I originally wanted to do, but had to move and grow txflags thus
skb_shinfo ended up growing. I wanted to avoid that, so stole an skb flag.
I considered treating fragid == 0 as unset, but a 0 fragid is perfectly valid
from the protocol perspective and could actually be generated by the id generator
functions. This may cause us to call the id generation multiple times.
-vlad
>
> Thanks,
> Hannes
>
>
^ permalink raw reply
* RE: [PATCH net-next V1 04/11] net/mlx4_core: Adjust command timeouts to conform to the firmware spec
From: David Laight @ 2015-01-27 14:30 UTC (permalink / raw)
To: 'Amir Vadai', David S. Miller
Cc: netdev@vger.kernel.org, Or Gerlitz, Yevgeny Petrilin,
Jack Morgenstein
In-Reply-To: <1422367089-13419-5-git-send-email-amirv@mellanox.com>
From: Amir Vadai
> From: Jack Morgenstein <jackm@dev.mellanox.co.il>
>
> The firmware spec states that the timeout for all commands should be 60 seconds.
Hmmm... 60 seconds seems a long time to wait for a device to do something.
I'll have given up and reset the machine before that expires.
David
^ permalink raw reply
* [PATCH net-next] cxgb4: Move firmware version MACRO to t4fw_version.h
From: Hariprasad Shenai @ 2015-01-27 14:42 UTC (permalink / raw)
To: netdev; +Cc: davem, leedom, anish, nirranjan, praveenm, Hariprasad Shenai
Move firmware version MACRO to a new t4fw_version.h file so that csiostor driver
can also use it.
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 10 ----
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 1 +
drivers/net/ethernet/chelsio/cxgb4/t4fw_version.h | 48 +++++++++++++++++++++
3 files changed, 49 insertions(+), 10 deletions(-)
create mode 100644 drivers/net/ethernet/chelsio/cxgb4/t4fw_version.h
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index d98a446..fb6980a 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -49,16 +49,6 @@
#include <asm/io.h>
#include "cxgb4_uld.h"
-#define T4FW_VERSION_MAJOR 0x01
-#define T4FW_VERSION_MINOR 0x0C
-#define T4FW_VERSION_MICRO 0x19
-#define T4FW_VERSION_BUILD 0x00
-
-#define T5FW_VERSION_MAJOR 0x01
-#define T5FW_VERSION_MINOR 0x0C
-#define T5FW_VERSION_MICRO 0x19
-#define T5FW_VERSION_BUILD 0x00
-
#define CH_WARN(adap, fmt, ...) dev_warn(adap->pdev_dev, fmt, ## __VA_ARGS__)
enum {
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index c27dcd9..5bf490a 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -70,6 +70,7 @@
#include "t4_values.h"
#include "t4_msg.h"
#include "t4fw_api.h"
+#include "t4fw_version.h"
#include "cxgb4_dcb.h"
#include "cxgb4_debugfs.h"
#include "clip_tbl.h"
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4fw_version.h b/drivers/net/ethernet/chelsio/cxgb4/t4fw_version.h
new file mode 100644
index 0000000..e2bd3f7
--- /dev/null
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4fw_version.h
@@ -0,0 +1,48 @@
+/*
+ * This file is part of the Chelsio T4 Ethernet driver for Linux.
+ *
+ * Copyright (c) 2003-2014 Chelsio Communications, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials
+ * provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#ifndef __T4FW_VERSION_H__
+#define __T4FW_VERSION_H__
+
+#define T4FW_VERSION_MAJOR 0x01
+#define T4FW_VERSION_MINOR 0x0C
+#define T4FW_VERSION_MICRO 0x19
+#define T4FW_VERSION_BUILD 0x00
+
+#define T5FW_VERSION_MAJOR 0x01
+#define T5FW_VERSION_MINOR 0x0C
+#define T5FW_VERSION_MICRO 0x19
+#define T5FW_VERSION_BUILD 0x00
+
+#endif
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
From: Eric Dumazet @ 2015-01-27 14:38 UTC (permalink / raw)
To: vyasevic
Cc: Michael S. Tsirkin, netdev, Vladislav Yasevich, virtualization,
edumazet, Hannes Frederic Sowa, Ben Hutchings
In-Reply-To: <54C7A007.6050707@redhat.com>
On Tue, 2015-01-27 at 09:26 -0500, Vlad Yasevich wrote:
> That's what I originally wanted to do, but had to move and grow txflags thus
> skb_shinfo ended up growing. I wanted to avoid that, so stole an skb flag.
>
> I considered treating fragid == 0 as unset, but a 0 fragid is perfectly valid
> from the protocol perspective and could actually be generated by the id generator
> functions. This may cause us to call the id generation multiple times.
With 32bit ID, you certainly can replace fragid=0 by fragid=0x80000000
and nobody will notice.
I certainly vote for not adding an extra bit in skb or skb_shared_info,
considering we already consume 32bits for this thing.
fragid are best effort, otherwise they would have 128bits.
^ permalink raw reply
* Re: [PATCH net-next 2/2] flow_dissector: add tipc support
From: Eric Dumazet @ 2015-01-27 14:40 UTC (permalink / raw)
To: Erik Hugne
Cc: David Miller, richard.alpe, netdev, jon.maloy, ying.xue,
tipc-discussion
In-Reply-To: <20150127120852.GB11522@haze>
On Tue, 2015-01-27 at 13:08 +0100, Erik Hugne wrote:
>
> About time we do something about this.. I'll post a patch with proper header
> definitions soon.
Thanks for following up ;)
^ permalink raw reply
* Re: [PATCH net-next 06/10] net/mlx4_core: Fix struct mlx4_vhcr_cmd to make implicit padding explicit
From: Jack Morgenstein @ 2015-01-27 14:43 UTC (permalink / raw)
To: David Laight
Cc: 'Amir Vadai', David S. Miller, netdev@vger.kernel.org,
Or Gerlitz, Yevgeny Petrilin
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CAD3D71@AcuExch.aculab.com>
On Tue, 27 Jan 2015 13:38:28 +0000
David Laight <David.Laight@ACULAB.COM> wrote:
> Haven't you broken communication between an old and new
> 32bit Guests and 32bit hosts (assuming they exist)?
Yes, but I don't see any interest on the net in running 32-bit Hosts
with virtualization and SR IOV. I do see that there is interest in
running 32-bit Guests over 64-bit Hosts (which configuration KVM
supports).
Since this change is *required* for supporting 32-bit Guests on 64-bit
Hosts, I don't see that we have much choice here.
As you say, an old 32-bit Host will not be compatible with a new 32-bit
guest, and vice-versa. However, I would assume that almost all Hosts
would have 64-bit architectures, because of the performance and
memory-space requirements for running SRIOV and virtualization.
Therefore, I don't see this as a stopper.
-Jack
^ permalink raw reply
* Re: [net-next] net: netcp: remove unused kconfig option and code
From: Murali Karicheri @ 2015-01-27 14:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20150123.222120.467596005244092508.davem@davemloft.net>
On 01/24/2015 01:21 AM, David Miller wrote:
> From: Murali Karicheri<m-karicheri2@ti.com>
> Date: Tue, 20 Jan 2015 14:22:36 -0500
>
>> Currently CPTS is built into the netcp driver even though there is no
>> call out to the CPTS driver. This patch removes the dependency in Kconfig
>> and remove cpts.o from the Makefile for NetCP.
>>
>> Signed-off-by: Murali Karicheri<m-karicheri2@ti.com>
>> ---
>> drivers/net/ethernet/ti/Kconfig | 2 +-
>> drivers/net/ethernet/ti/Makefile | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
>> index e11bcfa..824e376 100644
>> --- a/drivers/net/ethernet/ti/Kconfig
>> +++ b/drivers/net/ethernet/ti/Kconfig
>> @@ -73,7 +73,7 @@ config TI_CPSW
>> config TI_CPTS
>> boolean "TI Common Platform Time Sync (CPTS) Support"
>> depends on TI_CPSW
>> - depends on TI_CPSW || TI_KEYSTONE_NET
>> + depends on TI_CPSW
>
> Just remove the second dependency line, it's redundant because you've
> made it identical to the line before it.
Ok. Will post it with the change
--
Murali Karicheri
Linux Kernel, Texas Instruments
^ permalink raw reply
* Re: [PATCH] net: Linn Ethernet Packet Sniffer driver
From: Daniel Borkmann @ 2015-01-27 14:46 UTC (permalink / raw)
To: Stathis Voukelatos
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, abrestic@chromium.org, f.fainelli
In-Reply-To: <54C7736C.8090704@linn.co.uk>
Hi Stathis,
On 01/27/2015 12:15 PM, Stathis Voukelatos wrote:
> On 26/01/15 10:10, Daniel Borkmann wrote:
>>> Hello Daniel. Thank you for your feedback.
>>> Packet sockets could also be used for the driver interface to
>>> user space, however I think that both approaches would require the same
>>> amount of maintenance. We need to maintain a protocol consisting of
>>> a set of messages or commands that user space can use to communicate
>>> with the driver in order to configure the H/W and retrieve results.
>>> We could use packet sockets to send those messages too, but I thought
>>> netlink already provides a message exchange framework that we could
>>> make use of.
>>
>> When using packet sockets and your driver as a backend feeding them,
>> users can see that there's an extra capturing/monitoring netdev present,
>> all libpcap-based tools such as tcpdump et al would work out of the box
>> w/o adapting any code, and as an admin you can also see what users/tools
>> are making of use of the device through packet sockets. I couldn't parse
>> the exact motivation from the commit message of why avoiding all this is
>> better?
>
> Just wanted to clarify some implementation details for your approach.
> - The driver would need to create and register two net_device instances.
> One for sniffing Ethernet TX packets and one for RX.
Hm, I would represent the whole device as a single monitoring-only netdev.
I'm somehow still missing the big advantage of all this as compared to
using packet sockets on the normal netdev? I couldn't parse that from your
commit message.
> - Would the control interface for the sniffer in that case need to be
> through private socket ioctls (ie SIOCDEVPRIVATE + x ioctl ids)?
Nope, please have a look at Documentation/networking/packet_mmap.txt.
^ permalink raw reply
* [PATCH net-next v1] net: netcp: remove unused kconfig option and code
From: Murali Karicheri @ 2015-01-27 14:49 UTC (permalink / raw)
To: davem, netdev, linux-kernel; +Cc: Murali Karicheri
Currently CPTS is built into the netcp driver even though there is no
call out to the CPTS driver. This patch removes the dependency in Kconfig
and remove cpts.o from the Makefile for NetCP.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
---
v1 - removed the dependancy line introduced earlier as per comment
drivers/net/ethernet/ti/Kconfig | 1 -
drivers/net/ethernet/ti/Makefile | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index e11bcfa..4ea1663 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -73,7 +73,6 @@ config TI_CPSW
config TI_CPTS
boolean "TI Common Platform Time Sync (CPTS) Support"
depends on TI_CPSW
- depends on TI_CPSW || TI_KEYSTONE_NET
select PTP_1588_CLOCK
---help---
This driver supports the Common Platform Time Sync unit of
diff --git a/drivers/net/ethernet/ti/Makefile b/drivers/net/ethernet/ti/Makefile
index 465d03d..0a9813b 100644
--- a/drivers/net/ethernet/ti/Makefile
+++ b/drivers/net/ethernet/ti/Makefile
@@ -13,4 +13,4 @@ ti_cpsw-y := cpsw_ale.o cpsw.o cpts.o
obj-$(CONFIG_TI_KEYSTONE_NETCP) += keystone_netcp.o
keystone_netcp-y := netcp_core.o netcp_ethss.o netcp_sgmii.o \
- netcp_xgbepcsr.o cpsw_ale.o cpts.o
+ netcp_xgbepcsr.o cpsw_ale.o
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH net 0/2] netns: audit netdevice creation with IFLA_NET_NS_[PID|FD]
From: Nicolas Dichtel @ 2015-01-27 14:50 UTC (permalink / raw)
To: Alexander Aring; +Cc: netdev, davem, arvid.brodin, linux-wpan
In-Reply-To: <20150127140620.GA8941@omega>
Le 27/01/2015 15:06, Alexander Aring a écrit :
> Hi,
>
> On Tue, Jan 27, 2015 at 02:28:47PM +0100, Nicolas Dichtel wrote:
> ...
[snip]
>>
>> I don't know how wpan0 is created and if this interface can be created directly
>> in another netns than init_net.
>>
>
> no it can't. The wpan0 interface can be created via the 802.15.4
> userspace tools and we don't have such option for namespaces. It
> should be always to init_net while creation.
Even with 'ip netns exec foo iwpan ...'?
>
>>>
>>>
>>> Summarize:
>>>
>>> I would add the dev->features |= NETIF_F_NETNS_LOCAL; while wpan
>>> interface generation and add only the !net_eq(src_net, &init_net) check
>>> above. I suppose that src_net is the net namespace from "underlaying"
>>> interface wpan by calling:
>>>
>>> $ ip link add link wpan0 name lowpan0 type lowpan
>> No. src_net is the netns where the ip command is launched. With this patch, my
>
> ah, and when no "ip netns" is given it's default to init_net?
The default netns is the netns where your shell is running :)
It may be different from init_net when you are playing on a virtual machine. On
a physical machine, it's usually init_net.
>
>
> Okay, then I agree with that both interfaces should be set
>
> dev->features |= NETIF_F_NETNS_LOCAL
Ok.
>
> because both interfaces should started with "init_net" as default
> namespace. For wpan interface this should always be in "init_net",
> because we don't set anything while creation.
Not sure this is true. It's probably possible to create it directly in another
netns (with 'ip netns exec' or because your system is a virtual machine that
runs over a namespaces construction (see docker [0], lxc [1], etc).
[0] https://www.docker.com/
[1] https://linuxcontainers.org/
>
> For 6LoWPAN interface this should also always in the same namespace like
> the wpan interface and not diffrent namespace between link (wpan) and
> virtual (6LoWPAN) interface.
>
> Do you agree with that?
Yes.
But I still wonder if we should add a check about dev_net(dev) != init_net in
net/ieee802154/6lowpan/core.c.
If my understanding is correct:
- wpan can be created directly in a netns != init_net
- 6lowpan must be in the same netns than wpan
- code under net/ieee802154 only works in init_net, thus 6lowpan only works
in init_net.
Do you agree?
What about this (based on net-next)?
From 5ca1c46c68e4e4381b2f7e284f5dadeb28a53b2f Mon Sep 17 00:00:00 2001
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Tue, 27 Jan 2015 11:26:20 +0100
Subject: [PATCH] wpan/6lowpan: fix netns settings
6LoWPAN currently doesn't supports x-netns and works only in init_net.
With this patch, we ensure that:
- the wpan interface cannot be moved to another netns;
- the 6lowpan interface cannot be moved to another netns;
- the wpan interface is in the same netns than the 6lowpan interface;
- the 6lowpan interface is in init_net.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ieee802154/6lowpan/core.c | 6 ++++--
net/mac802154/iface.c | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/ieee802154/6lowpan/core.c b/net/ieee802154/6lowpan/core.c
index 055fbb71ba6f..dfd3c6007f60 100644
--- a/net/ieee802154/6lowpan/core.c
+++ b/net/ieee802154/6lowpan/core.c
@@ -126,6 +126,7 @@ static void lowpan_setup(struct net_device *dev)
dev->header_ops = &lowpan_header_ops;
dev->ml_priv = &lowpan_mlme;
dev->destructor = free_netdev;
+ dev->features |= NETIF_F_NETNS_LOCAL;
}
static int lowpan_validate(struct nlattr *tb[], struct nlattr *data[])
@@ -148,10 +149,11 @@ static int lowpan_newlink(struct net *src_net, struct
net_device *dev,
pr_debug("adding new link\n");
- if (!tb[IFLA_LINK])
+ if (!tb[IFLA_LINK] ||
+ !net_eq(dev_net(dev), &init_net))
return -EINVAL;
/* find and hold real wpan device */
- real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
+ real_dev = dev_get_by_index(dev_net(dev), nla_get_u32(tb[IFLA_LINK]));
if (!real_dev)
return -ENODEV;
if (real_dev->type != ARPHRD_IEEE802154) {
diff --git a/net/mac802154/iface.c b/net/mac802154/iface.c
index 6fb6bdf9868c..b67da8d578b4 100644
--- a/net/mac802154/iface.c
+++ b/net/mac802154/iface.c
@@ -475,6 +475,7 @@ static void ieee802154_if_setup(struct net_device *dev)
dev->mtu = IEEE802154_MTU;
dev->tx_queue_len = 300;
dev->flags = IFF_NOARP | IFF_BROADCAST;
+ dev->features |= NETIF_F_NETNS_LOCAL;
}
static int
--
2.2.2
^ permalink raw reply related
* Re: [RFC PATCH] net: ipv6: Make address flushing on ifdown optional
From: David Ahern @ 2015-01-27 14:55 UTC (permalink / raw)
To: Hannes Frederic Sowa, Andy Gospodarek; +Cc: Stephen Hemminger, netdev
In-Reply-To: <1422351861.13969.5.camel@stressinduktion.org>
On 1/27/15 2:44 AM, Hannes Frederic Sowa wrote:
>> You are probably correct that many will not switch, but this sysctl
>> gives those who want to switch a nice option without having to carry
>> extra kernel patches. I like it.
>
> I don't see any problem with the patch in general but DAD should
> definitely happen on reenabling interfaces. Current behavior does not
> seem fine to me. It's ok if this patch doesn't change this behavior now
> but a follow-up one will be needed then.
>
> David, will you look after the DAD logic and do you plan a follow-up
> patch?
Yes, I do plan a follow-up patch for this change. Will work on that this
week.
From the discussion a second patch is needed to make sure DAD is done
on a link up if there is an address configured.
David
^ permalink raw reply
* Re: [RFC PATCH] net: ipv6: Make address flushing on ifdown optional
From: Hannes Frederic Sowa @ 2015-01-27 15:28 UTC (permalink / raw)
To: David Ahern; +Cc: Andy Gospodarek, Stephen Hemminger, netdev
In-Reply-To: <54C7A6D6.8020805@gmail.com>
On Di, 2015-01-27 at 07:55 -0700, David Ahern wrote:
> On 1/27/15 2:44 AM, Hannes Frederic Sowa wrote:
> >> You are probably correct that many will not switch, but this sysctl
> >> gives those who want to switch a nice option without having to carry
> >> extra kernel patches. I like it.
> >
> > I don't see any problem with the patch in general but DAD should
> > definitely happen on reenabling interfaces. Current behavior does not
> > seem fine to me. It's ok if this patch doesn't change this behavior now
> > but a follow-up one will be needed then.
> >
> > David, will you look after the DAD logic and do you plan a follow-up
> > patch?
>
> Yes, I do plan a follow-up patch for this change. Will work on that this
> week.
>
> From the discussion a second patch is needed to make sure DAD is done
> on a link up if there is an address configured.
Thank you!
Let's see if the DAD patch isn't complex, maybe it is a candidate for
stable?
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: Jamal Hadi Salim @ 2015-01-27 15:54 UTC (permalink / raw)
To: Andy Gospodarek, David Ahern
Cc: Simon Horman, John Fastabend, Thomas Graf, Jiri Pirko,
Pablo Neira Ayuso, sfeldma, netdev, davem, gerlitz.or, andy, ast
In-Reply-To: <20150127045820.GC13164@gospo.home.greyhouse.net>
On 01/26/15 23:58, Andy Gospodarek wrote:
> On Mon, Jan 26, 2015 at 09:28:57PM -0700, David Ahern wrote:
>> Will someone be taking copious notes or recording the sessions and then
>> making those available for those not in attendance?
>>
>
> I'm not sure if the sessions will be recorded, but notes will be taken
> for those wise enough not to come to Ottawa this time of year. :)
>
We hope the content is hot enough it will melt all the ice around the
building but not down the street.
Tourists are welcome as well ;->
We are soliciting volunteers to do videos that we can post.
Having volunteers taking notes certainly is an excellent idea.
cheers,
janmal
^ permalink raw reply
* Re: [PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
From: Hannes Frederic Sowa @ 2015-01-27 16:02 UTC (permalink / raw)
To: vyasevic
Cc: Michael S. Tsirkin, netdev, Vladislav Yasevich, virtualization,
edumazet, Ben Hutchings
In-Reply-To: <54C7A007.6050707@redhat.com>
On Di, 2015-01-27 at 09:26 -0500, Vlad Yasevich wrote:
> On 01/27/2015 08:47 AM, Hannes Frederic Sowa wrote:
> > On Di, 2015-01-27 at 10:42 +0200, Michael S. Tsirkin wrote:
> >> On Tue, Jan 27, 2015 at 02:47:54AM +0000, Ben Hutchings wrote:
> >>> On Mon, 2015-01-26 at 09:37 -0500, Vladislav Yasevich wrote:
> >>>> If the IPv6 fragment id has not been set and we perform
> >>>> fragmentation due to UFO, select a new fragment id.
> >>>> When we store the fragment id into skb_shinfo, set the bit
> >>>> in the skb so we can re-use the selected id.
> >>>> This preserves the behavior of UFO packets generated on the
> >>>> host and solves the issue of id generation for packet sockets
> >>>> and tap/macvtap devices.
> >>>>
> >>>> This patch moves ipv6_select_ident() back in to the header file.
> >>>> It also provides the helper function that sets skb_shinfo() frag
> >>>> id and sets the bit.
> >>>>
> >>>> It also makes sure that we select the fragment id when doing
> >>>> just gso validation, since it's possible for the packet to
> >>>> come from an untrusted source (VM) and be forwarded through
> >>>> a UFO enabled device which will expect the fragment id.
> >>>>
> >>>> CC: Eric Dumazet <edumazet@google.com>
> >>>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> >>>> ---
> >>>> include/linux/skbuff.h | 3 ++-
> >>>> include/net/ipv6.h | 2 ++
> >>>> net/ipv6/ip6_output.c | 4 ++--
> >>>> net/ipv6/output_core.c | 9 ++++++++-
> >>>> net/ipv6/udp_offload.c | 10 +++++++++-
> >>>> 5 files changed, 23 insertions(+), 5 deletions(-)
> >>>>
> >>>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> >>>> index 85ab7d7..3ad5203 100644
> >>>> --- a/include/linux/skbuff.h
> >>>> +++ b/include/linux/skbuff.h
> >>>> @@ -605,7 +605,8 @@ struct sk_buff {
> >>>> __u8 ipvs_property:1;
> >>>> __u8 inner_protocol_type:1;
> >>>> __u8 remcsum_offload:1;
> >>>> - /* 3 or 5 bit hole */
> >>>> + __u8 ufo_fragid_set:1;
> >>> [...]
> >>>
> >>> Doesn't the flag belong in struct skb_shared_info, rather than struct
> >>> sk_buff? Otherwise this looks fine.
> >>>
> >>> Ben.
> >>
> >> Hmm we seem to be out of tx flags.
> >> Maybe ip6_frag_id == 0 should mean "not set".
> >
> > Maybe that is the best idea. Definitely the ufo_fragid_set bit should
> > move into the skb_shared_info area.
>
> That's what I originally wanted to do, but had to move and grow txflags thus
> skb_shinfo ended up growing. I wanted to avoid that, so stole an skb flag.
>
> I considered treating fragid == 0 as unset, but a 0 fragid is perfectly valid
> from the protocol perspective and could actually be generated by the id generator
> functions. This may cause us to call the id generation multiple times.
Are there plans in the long run to let virtio_net transmit auxiliary
data to the other end so we can clean all of this this up one day?
I don't like the whole situation: looking into the virtio_net headers
just adding a field for ipv6 fragmentation ids to those small structs
seems bloated, not doing it feels incorrect. :/
Thoughts?
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
From: Michael S. Tsirkin @ 2015-01-27 16:08 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: netdev, Vladislav Yasevich, virtualization, edumazet,
Ben Hutchings
In-Reply-To: <1422374551.13969.35.camel@stressinduktion.org>
On Tue, Jan 27, 2015 at 05:02:31PM +0100, Hannes Frederic Sowa wrote:
> On Di, 2015-01-27 at 09:26 -0500, Vlad Yasevich wrote:
> > On 01/27/2015 08:47 AM, Hannes Frederic Sowa wrote:
> > > On Di, 2015-01-27 at 10:42 +0200, Michael S. Tsirkin wrote:
> > >> On Tue, Jan 27, 2015 at 02:47:54AM +0000, Ben Hutchings wrote:
> > >>> On Mon, 2015-01-26 at 09:37 -0500, Vladislav Yasevich wrote:
> > >>>> If the IPv6 fragment id has not been set and we perform
> > >>>> fragmentation due to UFO, select a new fragment id.
> > >>>> When we store the fragment id into skb_shinfo, set the bit
> > >>>> in the skb so we can re-use the selected id.
> > >>>> This preserves the behavior of UFO packets generated on the
> > >>>> host and solves the issue of id generation for packet sockets
> > >>>> and tap/macvtap devices.
> > >>>>
> > >>>> This patch moves ipv6_select_ident() back in to the header file.
> > >>>> It also provides the helper function that sets skb_shinfo() frag
> > >>>> id and sets the bit.
> > >>>>
> > >>>> It also makes sure that we select the fragment id when doing
> > >>>> just gso validation, since it's possible for the packet to
> > >>>> come from an untrusted source (VM) and be forwarded through
> > >>>> a UFO enabled device which will expect the fragment id.
> > >>>>
> > >>>> CC: Eric Dumazet <edumazet@google.com>
> > >>>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> > >>>> ---
> > >>>> include/linux/skbuff.h | 3 ++-
> > >>>> include/net/ipv6.h | 2 ++
> > >>>> net/ipv6/ip6_output.c | 4 ++--
> > >>>> net/ipv6/output_core.c | 9 ++++++++-
> > >>>> net/ipv6/udp_offload.c | 10 +++++++++-
> > >>>> 5 files changed, 23 insertions(+), 5 deletions(-)
> > >>>>
> > >>>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > >>>> index 85ab7d7..3ad5203 100644
> > >>>> --- a/include/linux/skbuff.h
> > >>>> +++ b/include/linux/skbuff.h
> > >>>> @@ -605,7 +605,8 @@ struct sk_buff {
> > >>>> __u8 ipvs_property:1;
> > >>>> __u8 inner_protocol_type:1;
> > >>>> __u8 remcsum_offload:1;
> > >>>> - /* 3 or 5 bit hole */
> > >>>> + __u8 ufo_fragid_set:1;
> > >>> [...]
> > >>>
> > >>> Doesn't the flag belong in struct skb_shared_info, rather than struct
> > >>> sk_buff? Otherwise this looks fine.
> > >>>
> > >>> Ben.
> > >>
> > >> Hmm we seem to be out of tx flags.
> > >> Maybe ip6_frag_id == 0 should mean "not set".
> > >
> > > Maybe that is the best idea. Definitely the ufo_fragid_set bit should
> > > move into the skb_shared_info area.
> >
> > That's what I originally wanted to do, but had to move and grow txflags thus
> > skb_shinfo ended up growing. I wanted to avoid that, so stole an skb flag.
> >
> > I considered treating fragid == 0 as unset, but a 0 fragid is perfectly valid
> > from the protocol perspective and could actually be generated by the id generator
> > functions. This may cause us to call the id generation multiple times.
>
> Are there plans in the long run to let virtio_net transmit auxiliary
> data to the other end so we can clean all of this this up one day?
>
> I don't like the whole situation: looking into the virtio_net headers
> just adding a field for ipv6 fragmentation ids to those small structs
> seems bloated, not doing it feels incorrect. :/
>
> Thoughts?
>
> Bye,
> Hannes
I'm not sure - what will be achieved by generating the IDs guest side as
opposed to host side? It's certainly harder to get hold of entropy
guest-side.
--
MST
^ permalink raw reply
* Re: [RFC PATCH] net: ipv6: Make address flushing on ifdown optional
From: Andy Gospodarek @ 2015-01-27 16:09 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Stephen Hemminger, David Ahern, netdev
In-Reply-To: <1422351861.13969.5.camel@stressinduktion.org>
On Tue, Jan 27, 2015 at 10:44:21AM +0100, Hannes Frederic Sowa wrote:
> Hi,
>
> On Mo, 2015-01-26 at 23:56 -0500, Andy Gospodarek wrote:
> > On Fri, Jan 23, 2015 at 01:22:17PM +0100, Hannes Frederic Sowa wrote:
> > > On Do, 2015-01-22 at 22:40 -0800, Stephen Hemminger wrote:
> > > > On Wed, 14 Jan 2015 12:17:19 -0700
> > > > David Ahern <dsahern@gmail.com> wrote:
> > > >
> > > > > Currently, ipv6 addresses are flushed when the interface is configured down:
> > > > >
> > > > > [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
> > > > > [root@f20 ~]# ip addr show dev eth1
> > > > > 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
> > > > > link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> > > > > inet6 2000:11:1:1::1/64 scope global tentative
> > > > > valid_lft forever preferred_lft forever
> > > > > [root@f20 ~]# ip link set dev eth1 up
> > > > > [root@f20 ~]# ip link set dev eth1 down
> > > > > [root@f20 ~]# ip addr show dev eth1
> > > > > 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
> > > > > link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> > > > >
> > > > > Add a new sysctl to make this behavior optional. Setting defaults to flush
> > > > > addresses to maintain backwards compatibility. When reset flushing is bypassed:
> > > > >
> > > > > [root@f20 ~]# echo 0 > /proc/sys/net/ipv6/conf/eth1/flush_addr_on_down
> > > > > [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
> > > > > [root@f20 ~]# ip addr show dev eth1
> > > > > 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
> > > > > link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> > > > > inet6 2000:11:1:1::1/64 scope global tentative
> > > > > valid_lft forever preferred_lft forever
> > > > > [root@f20 ~]# ip link set dev eth1 up
> > > > > [root@f20 ~]# ip link set dev eth1 down
> > > > > [root@f20 ~]# ip addr show dev eth1
> > > > > 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
> > > > > link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> > > > > inet6 2000:11:1:1::1/64 scope global
> > > > > valid_lft forever preferred_lft forever
> > > > > inet6 fe80::4:11ff:fe22:3301/64 scope link
> > > > > valid_lft forever preferred_lft forever
> > > > >
> > > > > Suggested-by: Hannes Frederic Sowa <hannes@redhat.com>
> > > > > Signed-off-by: David Ahern <dsahern@gmail.com>
> > > > > Cc: Hannes Frederic Sowa <hannes@redhat.com>
> > > >
> > > > Would this break existing application expecting a particular semantic
> > > > by listening to netlink? What happens to packets received with the static
> > > > address when interface is down? With IPv4 Linux is mostly a weak host
> > > > model, and IPv6 somewhere in between.
> > >
> > > IPv6 is mostly a weak end model, too, but IFA_LINK addresses are used
> > > much more. So yes, it is somewhere in between.
> > >
> > > Addresses bound to interfaces which are currently down will work with
> > > IPv6 (in contrast to IPv4).
> > >
> > > > For vendors that control the application stack or have limited number
> > > > of services this would work fine, but what about RHEL?
> > >
> > > The new model is only enabled if the sysctl is set. I don't expect a lot
> > > of vendors or distributions switching anytime soon.
> >
> > You are probably correct that many will not switch, but this sysctl
> > gives those who want to switch a nice option without having to carry
> > extra kernel patches. I like it.
>
> I don't see any problem with the patch in general but DAD should
> definitely happen on reenabling interfaces. Current behavior does not
> seem fine to me. It's ok if this patch doesn't change this behavior now
> but a follow-up one will be needed then.
>
> David, will you look after the DAD logic and do you plan a follow-up
> patch?
>
> > I have been pondering a few different changes to interface address and
> > route behavior on both interface and link (gasp!) down and would like to
> > use sysctls to make those options available to those who are interested
> > without changing the current model.
>
> Can you be more specific? In the last year we added some per interface
> flags to e.g. handle the creation of on-link routes in case of an
> address gets added to the interface. Maybe this is the better approach,
> because quite a lot of stuff happens interface local in IPv6.
Unfortunately some of the work I've been doing is on a 3.2 long-term
kernel, but I've also been testing some of my hacks^Wpatches on the
latest tree as well to make control/mark FIB entries based on
link-status (carrier not I would call 'admin state' set via 'ip link
set').
Overloading the use of the onlink could be a good option -- I'll review
your patches and the functionality a bit more closely to see if I can
merge my changes with those and clean everything up.
I know that NM, netplugd, ifplugd, networkd, etc. could be used to
handle issue like this, but an in-kernel solution has a much better
chance of being reliable when you are dealing with ~100 network
interfaces and do not want to black-hole traffic when link is down to a
router in your datacenter and there is another possible route to get to
the network that was previously directly connected.
^ permalink raw reply
* Re: [PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
From: Vlad Yasevich @ 2015-01-27 16:25 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Michael S. Tsirkin, netdev, Vladislav Yasevich, virtualization,
edumazet, Ben Hutchings
In-Reply-To: <1422374551.13969.35.camel@stressinduktion.org>
On 01/27/2015 11:02 AM, Hannes Frederic Sowa wrote:
> On Di, 2015-01-27 at 09:26 -0500, Vlad Yasevich wrote:
>> On 01/27/2015 08:47 AM, Hannes Frederic Sowa wrote:
>>> On Di, 2015-01-27 at 10:42 +0200, Michael S. Tsirkin wrote:
>>>> On Tue, Jan 27, 2015 at 02:47:54AM +0000, Ben Hutchings wrote:
>>>>> On Mon, 2015-01-26 at 09:37 -0500, Vladislav Yasevich wrote:
>>>>>> If the IPv6 fragment id has not been set and we perform
>>>>>> fragmentation due to UFO, select a new fragment id.
>>>>>> When we store the fragment id into skb_shinfo, set the bit
>>>>>> in the skb so we can re-use the selected id.
>>>>>> This preserves the behavior of UFO packets generated on the
>>>>>> host and solves the issue of id generation for packet sockets
>>>>>> and tap/macvtap devices.
>>>>>>
>>>>>> This patch moves ipv6_select_ident() back in to the header file.
>>>>>> It also provides the helper function that sets skb_shinfo() frag
>>>>>> id and sets the bit.
>>>>>>
>>>>>> It also makes sure that we select the fragment id when doing
>>>>>> just gso validation, since it's possible for the packet to
>>>>>> come from an untrusted source (VM) and be forwarded through
>>>>>> a UFO enabled device which will expect the fragment id.
>>>>>>
>>>>>> CC: Eric Dumazet <edumazet@google.com>
>>>>>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
>>>>>> ---
>>>>>> include/linux/skbuff.h | 3 ++-
>>>>>> include/net/ipv6.h | 2 ++
>>>>>> net/ipv6/ip6_output.c | 4 ++--
>>>>>> net/ipv6/output_core.c | 9 ++++++++-
>>>>>> net/ipv6/udp_offload.c | 10 +++++++++-
>>>>>> 5 files changed, 23 insertions(+), 5 deletions(-)
>>>>>>
>>>>>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>>>>>> index 85ab7d7..3ad5203 100644
>>>>>> --- a/include/linux/skbuff.h
>>>>>> +++ b/include/linux/skbuff.h
>>>>>> @@ -605,7 +605,8 @@ struct sk_buff {
>>>>>> __u8 ipvs_property:1;
>>>>>> __u8 inner_protocol_type:1;
>>>>>> __u8 remcsum_offload:1;
>>>>>> - /* 3 or 5 bit hole */
>>>>>> + __u8 ufo_fragid_set:1;
>>>>> [...]
>>>>>
>>>>> Doesn't the flag belong in struct skb_shared_info, rather than struct
>>>>> sk_buff? Otherwise this looks fine.
>>>>>
>>>>> Ben.
>>>>
>>>> Hmm we seem to be out of tx flags.
>>>> Maybe ip6_frag_id == 0 should mean "not set".
>>>
>>> Maybe that is the best idea. Definitely the ufo_fragid_set bit should
>>> move into the skb_shared_info area.
>>
>> That's what I originally wanted to do, but had to move and grow txflags thus
>> skb_shinfo ended up growing. I wanted to avoid that, so stole an skb flag.
>>
>> I considered treating fragid == 0 as unset, but a 0 fragid is perfectly valid
>> from the protocol perspective and could actually be generated by the id generator
>> functions. This may cause us to call the id generation multiple times.
>
> Are there plans in the long run to let virtio_net transmit auxiliary
> data to the other end so we can clean all of this this up one day?
Yes, and I am working on this. Part of that is UFO/UFO6 split so that the
fragment id is carried for UFO6.
>
> I don't like the whole situation: looking into the virtio_net headers
> just adding a field for ipv6 fragmentation ids to those small structs
> seems bloated, not doing it feels incorrect. :/
>
We are thinking right now how to extend virtio_net header as this is
not the only extension people have thought off. It'll probably only
happen for virtio 1.0 spec, so we may still have to support legacy
devices that may still rely on UFO being available.
-vlad
> Thoughts?
>
> Bye,
> Hannes
>
>
^ permalink raw reply
* Re: Fw: [Bug 92081] New: skb->len=0 and getting "EOF on netlink" with "ip monitor all" (of iproute) when adding a vlan with "bridge vlan add"
From: roopa @ 2015-01-27 16:36 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20150127120123.4550d9ca@uryu.home.lan>
I noticed this during my recent cleanup of
rtnl_bridge_setlink/rtnl_bridge_dellink.
I think my below commit fixed one case of such error:
commit 02dba4388d1691a087f40fe8acd2e1ffd577a07f
Author: Roopa Prabhu <roopa@cumulusnetworks.com>
Date: Wed Jan 14 20:02:25 2015 -0800
bridge: fix setlink/dellink notifications
The reason for the zero length message in this case is that the user is
sending
the setlink request to the bridge with self flag set.
And since the getlink on the bridge device only returns bytes when its
a bridge port,
there are no bytes in the skb.
I will reconfirm that the above is true and submit a patch (I can update
the bugzilla link below as well).
Thanks,
Roopa
On 1/27/15, 4:01 AM, Stephen Hemminger wrote:
>
> Begin forwarded message:
>
> Date: Mon, 26 Jan 2015 10:15:12 -0800
> From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
> To: "stephen@networkplumber.org" <stephen@networkplumber.org>
> Subject: [Bug 92081] New: skb->len=0 and getting "EOF on netlink" with "ip monitor all" (of iproute) when adding a vlan with "bridge vlan add"
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=92081
>
> Bug ID: 92081
> Summary: skb->len=0 and getting "EOF on netlink" with "ip
> monitor all" (of iproute) when adding a vlan with
> "bridge vlan add"
> Product: Networking
> Version: 2.5
> Kernel Version: 3.17.6-300
> Hardware: All
> OS: Linux
> Tree: Fedora
> Status: NEW
> Severity: high
> Priority: P1
> Component: Other
> Assignee: shemminger@linux-foundation.org
> Reporter: ramirose@gmail.com
> Regression: No
>
> On Fedora 21, with 3.17.6-300.fc21.x86_64, with iproute-3.16.0-3 (installed
> from rpm),
> ip -V:
> ip utility, iproute2-ss140804
>
> Running in one terminal:
> ip monitor all
>
> And then running in a second terminal this sequence:
> ip link add br0 type bridge
> bridge vlan add vid 10 dev br0 self
>
> causes the "ip monitor all" to terminate, with "EOF on netlink".
>
> This happens also on older distros of Fedora (Fedora 20 and downward) with
> older kernels.
>
> It seems that the reason is that an skb->len is 0 for the netlink notification
> which is sent from
> with rtnl_notify() which is invoked from rtnl_bridge_notify(), which in turn
> is invoked from rtnl_bridge_setlink().
>
> See:
> http://lxr.free-electrons.com/source/net/core/rtnetlink.c#L2773
>
> Rami Rosen
>
^ permalink raw reply
* [PATCH v1] stmmac: prevent probe drivers to crash kernel
From: Andy Shevchenko @ 2015-01-27 16:38 UTC (permalink / raw)
To: Giuseppe Cavallaro, netdev; +Cc: Andy Shevchenko
In the case when alloc_netdev fails we return NULL to a caller. But there is no
check for NULL in the probe drivers. This patch changes NULL to an error
pointer. The function description is amended to reflect what we may get
returned.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 8c6b7c1..cf62ff4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2778,6 +2778,9 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
* @addr: iobase memory address
* Description: this is the main probe function used to
* call the alloc_etherdev, allocate the priv structure.
+ * Return:
+ * on success the new private structure is returned, otherwise the error
+ * pointer.
*/
struct stmmac_priv *stmmac_dvr_probe(struct device *device,
struct plat_stmmacenet_data *plat_dat,
@@ -2789,7 +2792,7 @@ struct stmmac_priv *stmmac_dvr_probe(struct device *device,
ndev = alloc_etherdev(sizeof(struct stmmac_priv));
if (!ndev)
- return NULL;
+ return ERR_PTR(-ENOMEM);
SET_NETDEV_DEV(ndev, device);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] stmmac: platform: adjust messages and move to dev level
From: Andy Shevchenko @ 2015-01-27 16:41 UTC (permalink / raw)
To: David Miller; +Cc: peppe.cavallaro, netdev
In-Reply-To: <20141209.182837.2218983730769727387.davem@davemloft.net>
On Tue, 2014-12-09 at 18:28 -0500, David Miller wrote:
> From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Date: Tue, 9 Dec 2014 11:59:13 +0200
>
> > This patch amendes error and warning messages across the platform driver. It
> > includes the following changes:
> > - remove unneccessary message when no memory is available
> > - change info level to warn in the validation functions
> > - append \n to the end of messages
> > - change pr_* macros to dev_*
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> This does not apply to the net-next tree, please respin.
Gently ping on this patch. It smoothly applies to the current net-next,
IIUC.
--
Andy Shevchenko <andriy.shevchenko@intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [PATCH] net: Linn Ethernet Packet Sniffer driver
From: Stathis Voukelatos @ 2015-01-27 17:22 UTC (permalink / raw)
To: Daniel Borkmann
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, abrestic@chromium.org, f.fainelli
In-Reply-To: <54C7A4DD.7030109@redhat.com>
Hi Daniel,
On 27/01/15 14:46, Daniel Borkmann wrote:
>> Just wanted to clarify some implementation details for your approach.
>> - The driver would need to create and register two net_device instances.
>> One for sniffing Ethernet TX packets and one for RX.
>
> Hm, I would represent the whole device as a single monitoring-only
> netdev.
> I'm somehow still missing the big advantage of all this as compared to
> using packet sockets on the normal netdev? I couldn't parse that from
> your
> commit message.
This H/W module was developed to allow accurate timestamping of selected
outgoing or incoming data packets. Timestamp values are provided by an
external implementation-dependent clock or timer that is of suitable
quality for the application.
Example: multiple audio receivers synchronizing their clocks to a
single transmitter, for synchronized playback.
The TX and RX blocks of the sniffer can be operated (eg. started, stopped,
configured) independently, that is why I believe two netdev instances would
be a better match to the H/W architecture.
>
>> - Would the control interface for the sniffer in that case need to be
>> through private socket ioctls (ie SIOCDEVPRIVATE + x ioctl ids)?
>
> Nope, please have a look at Documentation/networking/packet_mmap.txt.
>
>
Thanks for the link to the document. That is the way forward for retrieving
data from sniffer match events from user space very efficiently.
However, I am not sure about configuration, where we want to eg set the
command string, or query device attributes such as the size of the command
memory. That looks more suitable to an ioctl or a netlink message to me
and better use the packet socket just for data from sniffer match events.
Thanks,
Stathis
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox