* [PATCH net-next 1/2] be2net: fix multicast filter programming Multicast programming has been broken since commit 5b8821b7. Setting the MULTICAST flag while sending the cmd to the FW was missing. Fixed this.
From: Sathya Perla @ 2011-09-27 11:13 UTC (permalink / raw)
To: netdev
Also fixed-up some indentation in the adjacent lines.
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_cmds.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
index bebeee6..6bc07c7 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -1580,14 +1580,16 @@ int be_cmd_rx_filter(struct be_adapter *adapter, u32 flags, u32 value)
BE_IF_FLAGS_VLAN_PROMISCUOUS);
if (value == ON)
req->if_flags = cpu_to_le32(BE_IF_FLAGS_PROMISCUOUS |
- BE_IF_FLAGS_VLAN_PROMISCUOUS);
+ BE_IF_FLAGS_VLAN_PROMISCUOUS);
} else if (flags & IFF_ALLMULTI) {
req->if_flags_mask = req->if_flags =
- cpu_to_le32(BE_IF_FLAGS_MCAST_PROMISCUOUS);
+ cpu_to_le32(BE_IF_FLAGS_MCAST_PROMISCUOUS);
} else {
struct netdev_hw_addr *ha;
int i = 0;
+ req->if_flags_mask = req->if_flags =
+ cpu_to_le32(BE_IF_FLAGS_MULTICAST);
req->mcast_num = cpu_to_le16(netdev_mc_count(adapter->netdev));
netdev_for_each_mc_addr(ha, adapter->netdev)
memcpy(req->mcast_mac[i++].byte, ha->addr, ETH_ALEN);
--
1.7.4
^ permalink raw reply related
* [PATCH net-next 2/2] be2net: Show newly flashed FW ver in ethtool
From: Sathya Perla @ 2011-09-27 11:13 UTC (permalink / raw)
To: netdev; +Cc: Suresh Reddy
In-Reply-To: <1317122035-5533-1-git-send-email-sathya.perla@emulex.com>
This fix provides a newly flashed FW version (appended, in braces) along with
the currently running FW version via ethtool. The newly flashed version runs only after a system reset.
Signed-off-by: Suresh Reddy <Suresh.Reddy@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_cmds.c | 31 ++++++++++++++----------
drivers/net/ethernet/emulex/benet/be_cmds.h | 3 +-
drivers/net/ethernet/emulex/benet/be_ethtool.c | 14 +++++++++-
drivers/net/ethernet/emulex/benet/be_main.c | 5 +---
4 files changed, 33 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 6bc07c7..4b655b8 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -1444,32 +1444,37 @@ err:
spin_unlock_bh(&adapter->mcc_lock);
}
-/* Uses Mbox */
-int be_cmd_get_fw_ver(struct be_adapter *adapter, char *fw_ver)
+/* Uses synchronous mcc */
+int be_cmd_get_fw_ver(struct be_adapter *adapter, char *fw_ver,
+ char *fw_on_flash)
{
struct be_mcc_wrb *wrb;
struct be_cmd_req_get_fw_version *req;
int status;
- if (mutex_lock_interruptible(&adapter->mbox_lock))
- return -1;
+ spin_lock_bh(&adapter->mcc_lock);
- wrb = wrb_from_mbox(adapter);
- req = embedded_payload(wrb);
+ wrb = wrb_from_mccq(adapter);
+ if (!wrb) {
+ status = -EBUSY;
+ goto err;
+ }
+ req = embedded_payload(wrb);
be_wrb_hdr_prepare(wrb, sizeof(*req), true, 0,
- OPCODE_COMMON_GET_FW_VERSION);
-
+ OPCODE_COMMON_GET_FW_VERSION);
be_cmd_hdr_prepare(&req->hdr, CMD_SUBSYSTEM_COMMON,
- OPCODE_COMMON_GET_FW_VERSION, sizeof(*req));
+ OPCODE_COMMON_GET_FW_VERSION, sizeof(*req));
- status = be_mbox_notify_wait(adapter);
+ status = be_mcc_notify_wait(adapter);
if (!status) {
struct be_cmd_resp_get_fw_version *resp = embedded_payload(wrb);
- strncpy(fw_ver, resp->firmware_version_string, FW_VER_LEN);
+ strcpy(fw_ver, resp->firmware_version_string);
+ if (fw_on_flash)
+ strcpy(fw_on_flash, resp->fw_on_flash_version_string);
}
-
- mutex_unlock(&adapter->mbox_lock);
+err:
+ spin_unlock_bh(&adapter->mcc_lock);
return status;
}
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.h b/drivers/net/ethernet/emulex/benet/be_cmds.h
index b61eac7..abaa90c 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.h
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.h
@@ -1444,7 +1444,8 @@ extern int be_cmd_get_stats(struct be_adapter *adapter,
struct be_dma_mem *nonemb_cmd);
extern int lancer_cmd_get_pport_stats(struct be_adapter *adapter,
struct be_dma_mem *nonemb_cmd);
-extern int be_cmd_get_fw_ver(struct be_adapter *adapter, char *fw_ver);
+extern int be_cmd_get_fw_ver(struct be_adapter *adapter, char *fw_ver,
+ char *fw_on_flash);
extern int be_cmd_modify_eqd(struct be_adapter *adapter, u32 eq_id, u32 eqd);
extern int be_cmd_vlan_config(struct be_adapter *adapter, u32 if_id,
diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c b/drivers/net/ethernet/emulex/benet/be_ethtool.c
index f144a6f..bf8153e 100644
--- a/drivers/net/ethernet/emulex/benet/be_ethtool.c
+++ b/drivers/net/ethernet/emulex/benet/be_ethtool.c
@@ -118,14 +118,24 @@ static const char et_self_tests[][ETH_GSTRING_LEN] = {
#define BE_ONE_PORT_EXT_LOOPBACK 0x2
#define BE_NO_LOOPBACK 0xff
-static void
-be_get_drvinfo(struct net_device *netdev, struct ethtool_drvinfo *drvinfo)
+static void be_get_drvinfo(struct net_device *netdev,
+ struct ethtool_drvinfo *drvinfo)
{
struct be_adapter *adapter = netdev_priv(netdev);
+ char fw_on_flash[FW_VER_LEN];
+
+ memset(fw_on_flash, 0 , sizeof(fw_on_flash));
+ be_cmd_get_fw_ver(adapter, adapter->fw_ver, fw_on_flash);
strcpy(drvinfo->driver, DRV_NAME);
strcpy(drvinfo->version, DRV_VER);
strncpy(drvinfo->fw_version, adapter->fw_ver, FW_VER_LEN);
+ if (memcmp(adapter->fw_ver, fw_on_flash, FW_VER_LEN) != 0) {
+ strcat(drvinfo->fw_version, " [");
+ strcat(drvinfo->fw_version, fw_on_flash);
+ strcat(drvinfo->fw_version, "]");
+ }
+
strcpy(drvinfo->bus_info, pci_name(adapter->pdev));
drvinfo->testinfo_len = 0;
drvinfo->regdump_len = 0;
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 2b7d1ba..1a7b24c 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -2528,6 +2528,7 @@ static int be_setup(struct be_adapter *adapter)
adapter->link_speed = -1;
+ be_cmd_get_fw_ver(adapter, adapter->fw_ver, NULL);
return 0;
rx_qs_destroy:
@@ -3147,10 +3148,6 @@ static int be_get_config(struct be_adapter *adapter)
int status;
u8 mac[ETH_ALEN];
- status = be_cmd_get_fw_ver(adapter, adapter->fw_ver);
- if (status)
- return status;
-
status = be_cmd_query_fw_cfg(adapter, &adapter->port_num,
&adapter->function_mode, &adapter->function_caps);
if (status)
--
1.7.4
^ permalink raw reply related
* Re: [PATCH 1/2] virtio-net: Verify page list size before fitting into skb
From: Sasha Levin @ 2011-09-27 11:20 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, Rusty Russell, virtualization, netdev, kvm
In-Reply-To: <20110927070034.GB4690@redhat.com>
On Tue, 2011-09-27 at 10:00 +0300, Michael S. Tsirkin wrote:
> > skb = page_to_skb(vi, page, len);
> > ...
>
> Sorry I don't get it yet. Where is mergeable ignored here?
The NULL deref happens in page_to_skb(), before merge buffers are
handled.
I'll test it and see if it's really the case.
--
Sasha.
^ permalink raw reply
* [PATCH net-next 1/2] be2net: fix multicast filter programming
From: Sathya Perla @ 2011-09-27 11:25 UTC (permalink / raw)
To: netdev
Re-posting with subject fixed!
Multicast programming has been broken since commit 5b8821b7. Setting the
MULTICAST flag while sending the cmd to the FW was missing. Fixed this.
Also fixed-up some indentation in the adjacent lines.
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_cmds.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
index bebeee6..6bc07c7 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -1580,14 +1580,16 @@ int be_cmd_rx_filter(struct be_adapter *adapter, u32 flags, u32 value)
BE_IF_FLAGS_VLAN_PROMISCUOUS);
if (value == ON)
req->if_flags = cpu_to_le32(BE_IF_FLAGS_PROMISCUOUS |
- BE_IF_FLAGS_VLAN_PROMISCUOUS);
+ BE_IF_FLAGS_VLAN_PROMISCUOUS);
} else if (flags & IFF_ALLMULTI) {
req->if_flags_mask = req->if_flags =
- cpu_to_le32(BE_IF_FLAGS_MCAST_PROMISCUOUS);
+ cpu_to_le32(BE_IF_FLAGS_MCAST_PROMISCUOUS);
} else {
struct netdev_hw_addr *ha;
int i = 0;
+ req->if_flags_mask = req->if_flags =
+ cpu_to_le32(BE_IF_FLAGS_MULTICAST);
req->mcast_num = cpu_to_le16(netdev_mc_count(adapter->netdev));
netdev_for_each_mc_addr(ha, adapter->netdev)
memcpy(req->mcast_mac[i++].byte, ha->addr, ETH_ALEN);
--
1.7.4
^ permalink raw reply related
* [PATCHv2] wireless: at76c50x: use native hex_pack_byte() method
From: Andy Shevchenko @ 2011-09-27 11:51 UTC (permalink / raw)
To: linux-kernel; +Cc: Andy Shevchenko, John W. Linville, linux-wireless, netdev
In-Reply-To: <71d8213731be21f26a82255a4fffdbe1b6dd4a44.1316774801.git.andriy.shevchenko@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
---
drivers/net/wireless/at76c50x-usb.c | 16 ++++++----------
1 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/at76c50x-usb.c b/drivers/net/wireless/at76c50x-usb.c
index 2986014..96daaad 100644
--- a/drivers/net/wireless/at76c50x-usb.c
+++ b/drivers/net/wireless/at76c50x-usb.c
@@ -500,7 +500,6 @@ exit:
#define HEX2STR_BUFFERS 4
#define HEX2STR_MAX_LEN 64
-#define BIN2HEX(x) ((x) < 10 ? '0' + (x) : (x) + 'A' - 10)
/* Convert binary data into hex string */
static char *hex2str(void *buf, int len)
@@ -514,18 +513,15 @@ static char *hex2str(void *buf, int len)
if (len > HEX2STR_MAX_LEN)
len = HEX2STR_MAX_LEN;
- if (len <= 0) {
- ret[0] = '\0';
- return ret;
- }
-
while (len--) {
- *obuf++ = BIN2HEX(*ibuf >> 4);
- *obuf++ = BIN2HEX(*ibuf & 0xf);
+ obuf = pack_hex_byte(obuf, *ibuf++);
*obuf++ = '-';
- ibuf++;
}
- *(--obuf) = '\0';
+
+ if (*obuf == '-')
+ obuf--;
+
+ *obuf = '\0';
return ret;
}
--
1.7.6.3
^ permalink raw reply related
* [PATCHv2.1] wireless: at76c50x: use native hex_pack_byte() method
From: Andy Shevchenko @ 2011-09-27 12:01 UTC (permalink / raw)
To: linux-kernel; +Cc: Andy Shevchenko, John W. Linville, linux-wireless, netdev
In-Reply-To: <71d8213731be21f26a82255a4fffdbe1b6dd4a44.1316774801.git.andriy.shevchenko@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
---
drivers/net/wireless/at76c50x-usb.c | 18 +++++++-----------
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/at76c50x-usb.c b/drivers/net/wireless/at76c50x-usb.c
index 2986014..2dde5f6 100644
--- a/drivers/net/wireless/at76c50x-usb.c
+++ b/drivers/net/wireless/at76c50x-usb.c
@@ -500,10 +500,9 @@ exit:
#define HEX2STR_BUFFERS 4
#define HEX2STR_MAX_LEN 64
-#define BIN2HEX(x) ((x) < 10 ? '0' + (x) : (x) + 'A' - 10)
/* Convert binary data into hex string */
-static char *hex2str(void *buf, int len)
+static char *hex2str(void *buf, size_t len)
{
static atomic_t a = ATOMIC_INIT(0);
static char bufs[HEX2STR_BUFFERS][3 * HEX2STR_MAX_LEN + 1];
@@ -514,18 +513,15 @@ static char *hex2str(void *buf, int len)
if (len > HEX2STR_MAX_LEN)
len = HEX2STR_MAX_LEN;
- if (len <= 0) {
- ret[0] = '\0';
- return ret;
- }
-
while (len--) {
- *obuf++ = BIN2HEX(*ibuf >> 4);
- *obuf++ = BIN2HEX(*ibuf & 0xf);
+ obuf = pack_hex_byte(obuf, *ibuf++);
*obuf++ = '-';
- ibuf++;
}
- *(--obuf) = '\0';
+
+ if (*obuf == '-')
+ obuf--;
+
+ *obuf = '\0';
return ret;
}
--
1.7.6.3
^ permalink raw reply related
* Re: [PATCH 2/2] net: Fix potential memory leak
From: Eric Dumazet @ 2011-09-27 12:07 UTC (permalink / raw)
To: Huajun Li; +Cc: David Miller, netdev
In-Reply-To: <CA+v9cxbd3GjAigHC+P8coconkdHxNF3dBgoRDtbxqZ6oK_Mw0A@mail.gmail.com>
Le mardi 27 septembre 2011 à 17:58 +0800, Huajun Li a écrit :
> To emulate memory allocation fail case, I added code to return
> '-ENOMEM' from flow_cache_cpu_prepare(...) even if it could allocate
> memory correctly, but did not find panic on my box, maybe the latest
> code changed greatly than 2.6.37. :)
To panic the box, you need to leave a NULL pointer somewhere and
dereference it later, when code assumes it cant be NULL ;)
^ permalink raw reply
* Re: [PATCH v2] net/flow: Fix potential memory leak
From: Eric Dumazet @ 2011-09-27 12:11 UTC (permalink / raw)
To: Huajun Li; +Cc: David Miller, netdev
In-Reply-To: <CA+v9cxZMwTPXw-_pWc-SRsTs5GqmqK2-46Mr06HxhVN4aH93Yg@mail.gmail.com>
Le mardi 27 septembre 2011 à 18:34 +0800, Huajun Li a écrit :
> While preparing net flow caches, once fail may cause potential memory
> leak , fix it.
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Hmm, please dont add "Acked-by" yourself, when submitting a new patch
version. Let us review the new version and ACK it eventually.
> Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
> ---
> net/core/flow.c | 16 +++++++++++++++-
> 1 files changed, 15 insertions(+), 1 deletions(-)
>
> diff --git a/net/core/flow.c b/net/core/flow.c
> index 555a456..4e60fce 100644
> --- a/net/core/flow.c
> +++ b/net/core/flow.c
> @@ -413,7 +413,7 @@ static int __init flow_cache_init(struct flow_cache *fc)
>
> for_each_online_cpu(i) {
> if (flow_cache_cpu_prepare(fc, i))
> - return -ENOMEM;
> + goto err;
> }
> fc->hotcpu_notifier = (struct notifier_block){
> .notifier_call = flow_cache_cpu,
> @@ -426,6 +426,20 @@ static int __init flow_cache_init(struct flow_cache *fc)
> add_timer(&fc->rnd_timer);
>
> return 0;
> +
> +err:
> + for_each_possible_cpu(i) {
> + struct flow_cache_percpu *fcp = per_cpu_ptr(fc->percpu, i);
> + kfree(fcp->hash_table);
> + fcp->hash_table = NULL;
> + }
> +
> + if (fc->percpu) {
test not needed here, fc->percpu is not NULL
> + free_percpu(fc->percpu);
> + fc->percpu = NULL;
> + }
> +
> + return -ENOMEM;
> }
>
> static int __init flow_cache_init_global(void)
^ permalink raw reply
* Re: [PATCH 1/2] virtio-net: Verify page list size before fitting into skb
From: Michael S. Tsirkin @ 2011-09-27 12:37 UTC (permalink / raw)
To: Sasha Levin; +Cc: linux-kernel, Rusty Russell, virtualization, netdev, kvm
In-Reply-To: <1317122429.3467.5.camel@lappy>
On Tue, Sep 27, 2011 at 02:20:29PM +0300, Sasha Levin wrote:
> On Tue, 2011-09-27 at 10:00 +0300, Michael S. Tsirkin wrote:
> > > skb = page_to_skb(vi, page, len);
> > > ...
> >
> > Sorry I don't get it yet. Where is mergeable ignored here?
>
> The NULL deref happens in page_to_skb(), before merge buffers are
> handled.
The len here is a single buffer length, so for mergeable
buffers it is <= the size of the buffer we gave to hardware,
which is PAGE_SIZE.
err = virtqueue_add_buf_single(vi->rvq, page_address(page),
PAGE_SIZE, false, page, gfp);
Unless of course we are trying to work around broken hardware again,
which I don't have a problem with, but should probably
get appropriate comments in code and trigger a warning.
> I'll test it and see if it's really the case.
>
> --
>
> Sasha.
^ permalink raw reply
* Re: linux-next: manual merge of the net tree with the wireless-current tree
From: John W. Linville @ 2011-09-27 13:09 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev, linux-next, linux-kernel, Johannes Berg,
Wey-Yi Guy, Emmanuel Grumbach
In-Reply-To: <20110927125132.002db8176a66f85286dcd027@canb.auug.org.au>
On Tue, Sep 27, 2011 at 12:51:32PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net tree got a conflict in
> drivers/net/wireless/iwlwifi/iwl-scan.c between commit 6c80c39d9a69
> ("iwlagn: fix dangling scan request") from the wireless-current tree and
> commits 63013ae30159 ("iwlagn: priv->status moves to iwl_shared") and
> 6ac2f839b0b2 ("iwlagn: priv->mutex moves to iwl_shared") from the net
> tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Looks good, thanks!
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 01/15] add Documentation/namespaces/user_namespace.txt (v3)
From: Serge E. Hallyn @ 2011-09-27 13:21 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: Serge Hallyn, akpm, linux-kernel, netdev, containers, dhowells,
ebiederm, rdunlap, kernel-hardening
In-Reply-To: <20110926191737.GA4562@albatros>
Quoting Vasiliy Kulikov (segoon@openwall.com):
> (cc'ed kernel-hardening)
>
>
> Hi Serge,
>
> I didn't deeply studied the patches yet (sorry!), but I have some
> long-term question about the technique in general. I couldn't find
> answers to the questions in the documentation.
Great - thanks for your time, Vasiliy.
There is documentation at https://wiki.ubuntu.com/UserNamespace,
and I was adding a Documentation/namespaces/user_namespace.txt file
(which hasn't gone in yet) which you can see here:
https://lkml.org/lkml/2011/7/26/351
But those don't answer your questions sufficiently.
> First, the patches by design expose much kernel code to unprivileged
> userspace processes. This code doesn't expect malformed data (e.g. VFS,
> specific filesystems, block layer, char drivers, sysadmin part of LSMs,
> etc. etc.). By relaxing permission rules you greatly increase attack
> surface of the kernel from unprivileged users. Are you (or somebody
> else) planning to audit this code?
I had wanted to (but didn't) propose a discussion at ksummit about how
best to approach the filesystem code. That's not even just for user
namespaces - patches have been floated in the past to make mount an
unprivileged operation depending on the FS and the user's permission
over the device and target. So I don't know if a combination of auditing
and fuzzing is the way to go, or what, and wanted to get input from
some people who are more knowledgeable on that topic than me.
You're right about other kernel code as well.
I'll certainly join in this effort, but don't want to go blindly
charging in without some advice/guidance about the best way to do
this and, if others are interested, coordinate it.
We can start by looking through all code which is currently under
ns_capable(), and analyzing that. But what tools do we have
available to perform the analysis?
Do you think a kernel summit discussion (i suppose given the late
timing, a beer bof) would be beneficial? (I wouldn't be there)
> Also, will it be possible to somehow restrict what specific kernel
> facilities are accessible from users (IOW, what root emulation
> limitations are in action)? It is userful from both points of sysadmin,
> who might not want to allow users to do such things, and from the
> security POV in sense of attack surface reduction.
You're probably thinking along different lines, but this is why I've
been wanting seccomp2 to get pushed through. So that we can deny a
container the syscalls we know it won't need, especially newer ones,
to reduce the attack surface available to it.
> The patches explicitly enable some features for users on white list
> basis. It's possible to do it for simple cases, but what are you going
> to do with multiplexing functions where there is a permission check
> before the actual multiplexing? FS, networking drivers, etc. Are you
> going to do the same thing as net_namespace does? - For each multiplexed
> entity create bool ->ns_aware which is false by default for all
> "untrusted"/not prepared protocols and is true for audited/prepared
> protocols. Or probably you have something else in mind?
Ah, I typed the bottom paragraph before realizing what you were actually
asking. The filesystems are a good example. In the unprivileged mounts
patchsets, for instance, a flag was added to each filesystem indicating
if it was safe for unprivileged mounting (turned off for all real block
filesystems :). For targeted capabilities, my goal would be simply to
make sure that each non-netns-aware entity do a (untargeted) capable()
check. Without pointing to a specific example it's hard to say what I
will do. It depends on how the code was previously laid out, and what
the maintainer of that subsystem prefers.
The way we're approaching it right now is that by default everything
stays 'capable(X)', so that a non-init user namespace doesn't get the
privileges. While some of my patchsets this summer didn't follow this,
Eric reminded me that we should first clamp down on the user namespaces
as much as possible, and relax permissions in child namespaces later.
So the small (1-2 patch sized) sets I've been sending the last few
weeks are just trying to fix existing inadequate userid or capability
checks.
-serge
^ permalink raw reply
* Re: linux-next: manual merge of the net tree with the wireless-current tree
From: wwguy @ 2011-09-27 14:41 UTC (permalink / raw)
To: John W. Linville
Cc: Stephen Rothwell, David Miller, netdev@vger.kernel.org,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Berg, Johannes, Grumbach, Emmanuel
In-Reply-To: <20110927130926.GA2824@tuxdriver.com>
On Tue, 2011-09-27 at 06:09 -0700, John W. Linville wrote:
> On Tue, Sep 27, 2011 at 12:51:32PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the net tree got a conflict in
> > drivers/net/wireless/iwlwifi/iwl-scan.c between commit 6c80c39d9a69
> > ("iwlagn: fix dangling scan request") from the wireless-current tree and
> > commits 63013ae30159 ("iwlagn: priv->status moves to iwl_shared") and
> > 6ac2f839b0b2 ("iwlagn: priv->mutex moves to iwl_shared") from the net
> > tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary.
>
> Looks good, thanks!
>
Thanks a lot for fixing it.
Wey
^ permalink raw reply
* Re: [PATCH net-next-2.6] can/sja1000: driver for PEAK PCAN PCI/PCIe cards
From: Thomas Wiedemann @ 2011-09-27 14:58 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: linux, Netdev, Oliver Hartkopp, SocketCAN Core Mailing List
In-Reply-To: <4E6F0891.8030600@grandegger.com>
Hi together,
i'll test the patch as soon as the system is available again, which is not
before next week.
Thomas
Wolfgang Grandegger <wg@grandegger.com> schrieb am 13.09.2011 09:38:57:
> Hi Oliver,
>
> On 09/12/2011 05:49 PM, Oliver Hartkopp wrote:
> > On 09/09/11 17:20, Wolfgang Grandegger wrote:
> >
> >
> >>
> >>> I'll also test your driver on Monday.
> >>
> >> Thanks,
> >
> >
> > Hi Wolfgang,
> >
> > even if i only had my hardware-patched PEAK PCI ExpressCard hardware
here
> > (which is to be removed in the supported PCI device list due to the
missing
> > I2C initialization), i successfully tested your driver.
> >
> > Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
>
> Thanks, I have just sent v2.
>
> > So let's wait for some feedback from Thomas, when he's back to the
office ;-)
>
> Yep, some testing on a 4 channel card would be nice.
>
> Wolfgang.
>
^ permalink raw reply
* Re: intel 82599 multi-port performance
From: Martin Millnert @ 2011-09-27 15:30 UTC (permalink / raw)
To: J.Hwan Kim; +Cc: Alexander Duyck, netdev
In-Reply-To: <4E811C8E.8020508@gmail.com>
Hi J.Hwan,
On Tue, Sep 27, 2011 at 2:45 AM, J.Hwan Kim <frog1120@gmail.com> wrote:
> I tested the 10G - 64byte frames.
> With ixgbe-modified driver, in single port, 92% of packet received in driver
> level and in 2 port we received around 42% packets.
Are you reading packet drops in the 82599's own registries (ie ethtool)?
Regards,
Martin
^ permalink raw reply
* Re: [PATCH 01/15] add Documentation/namespaces/user_namespace.txt (v3)
From: Vasiliy Kulikov @ 2011-09-27 15:56 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Serge Hallyn, akpm, linux-kernel, netdev, containers, dhowells,
ebiederm, rdunlap, kernel-hardening
In-Reply-To: <20110927132157.GB3111@sergelap>
On Tue, Sep 27, 2011 at 08:21 -0500, Serge E. Hallyn wrote:
> > First, the patches by design expose much kernel code to unprivileged
> > userspace processes. This code doesn't expect malformed data (e.g. VFS,
> > specific filesystems, block layer, char drivers, sysadmin part of LSMs,
> > etc. etc.). By relaxing permission rules you greatly increase attack
> > surface of the kernel from unprivileged users. Are you (or somebody
> > else) planning to audit this code?
>
> I had wanted to (but didn't) propose a discussion at ksummit about how
> best to approach the filesystem code. That's not even just for user
> namespaces - patches have been floated in the past to make mount an
> unprivileged operation depending on the FS and the user's permission
> over the device and target.
This is a dangerous operation by itself. AFAICS, this is the reason why
e.g. FUSE doesn't pass user mount points to other users and even root.
Beginning from violating some rules like existance of single "." and
".." in each directory and ending with filename charsets with /, \000
and things like `, ", ', \ inside.
> So I don't know if a combination of auditing
> and fuzzing is the way to go,
Maybe the combination of both. There are no generic recommendations,
it's always limited to the subsystem, checked property, and the
auditor.
> > Also, will it be possible to somehow restrict what specific kernel
> > facilities are accessible from users (IOW, what root emulation
> > limitations are in action)? It is userful from both points of sysadmin,
> > who might not want to allow users to do such things, and from the
> > security POV in sense of attack surface reduction.
>
> You're probably thinking along different lines, but this is why I've
> been wanting seccomp2 to get pushed through. So that we can deny a
> container the syscalls we know it won't need, especially newer ones,
> to reduce the attack surface available to it.
This dependency greatly complicates the things.
First, there is a big misunderstanding between Will and Ingo in what
needs seccompv2 should serve. Will wants to reduce kernel attack
surface by limiting syscalls and syscall arguments available to a user
(a single task, btw). Ingo wants to see a full featured filtering
engine, which needs code changes all over the kernel. Given the needed
changes amounts, it will unlikely reduce attack surface.
You probably don't want Will's version as syscalls filtering is a very
bad abstraction in your case. user_namespaces likely need Ingo's
version of seccomp as it will be possible to filter e.g. fs-specific
events, but even if it is implemented, it will take a looong time for
your needs IMHO.
Also, I'm afraid for _good_ user_namespace filtering the policy
definition will be too complicated (like SELinux policy definition for
non-trivial applications) if it is implemented in events filtering
terms.
> The way we're approaching it right now is that by default everything
> stays 'capable(X)', so that a non-init user namespace doesn't get the
> privileges.
Great. I was not sure about it.
> While some of my patchsets this summer didn't follow this,
> Eric reminded me that we should first clamp down on the user namespaces
> as much as possible, and relax permissions in child namespaces later.
I think it is the only sane way.
> So the small (1-2 patch sized) sets I've been sending the last few
> weeks are just trying to fix existing inadequate userid or capability
> checks.
>
> -serge
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ permalink raw reply
* RE: [net-next 02/10] ixgbevf: Fix broken trunk vlan
From: Rose, Gregory V @ 2011-09-27 16:39 UTC (permalink / raw)
To: Jesse Gross
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com, Jiri Pirko
In-Reply-To: <CAEP_g=-OhrQ5QMbj5_d4BhLHEdDim1_STgy96Vdx5mYFagpVGg@mail.gmail.com>
> -----Original Message-----
> From: Jesse Gross [mailto:jesse@nicira.com]
> Sent: Monday, September 26, 2011 5:54 PM
> To: Rose, Gregory V
> Cc: Kirsher, Jeffrey T; davem@davemloft.net; netdev@vger.kernel.org;
> gospo@redhat.com; Jiri Pirko
> Subject: Re: [net-next 02/10] ixgbevf: Fix broken trunk vlan
>
>
> OK, maybe due to hardware limitations what I'm looking for just really
> isn't possible.
From what I can tell that is the case.
> However, what I'm trying to emphasize is that vconfig
> is not the only way that vlans can be consumed by the network stack
> and active_vlans is just an indication of whether a vlan filter was
> set, nothing more (perhaps I should have picked a better name when I
> originally designed this stuff).
Understood. The VF is incapable of receiving VLAN traffic unless a filter has been set. It doesn't do promiscuous mode and any path that doesn't actually end up setting a VLAN filter won't receive any VLAN traffic.
> In particular, it is not intended to
> determine whether a tag should be stripped off or not because
> non-vconfig users don't necessarily know which vlans they care about
> (think tcpdump or trunking over a bridge). A major goal of the
> existing vlan infrastructure is to avoid having drivers make
> assumptions about the consumer of the tag and instead just hand all
> information over to the network stack so it can behave in a consistent
> manner. That's why I was looking for alternate ways to get this
> information without depending on active_vlans as this driver behaves
> quite a bit differently from others, include the ixgbe PF driver.
There are only two paths for the ixgbevf driver to receive VLAN traffic. Either a VLAN filter has been set, which will result in a bit tag in active_vlans being set or the system administrator in the host VMM has put the VF device in trunk VLAN mode using the 'ip link set <dev> vf <n> <vlanid>' path. There is no other way for it to receive VLAN traffic, so I think we're fine. And keep in mind, once the system admin has put the VF device in trunk vlan mode, the VF is no longer allowed, as a policy implemented in the PF driver, to set any other VLAN filters. Even if it did, it wouldn't work due to the operational characteristics of the VF device HW.
The methods by which the ixgbe driver, as a fully featured Physical Function device, are quite a bit more varied. I believe you're thinking of the VF device as a typical Ethernet device and that is just not the case.
- Greg
^ permalink raw reply
* Re: [net-next 02/10] ixgbevf: Fix broken trunk vlan
From: Jesse Gross @ 2011-09-27 16:49 UTC (permalink / raw)
To: Rose, Gregory V
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com, Jiri Pirko
In-Reply-To: <43F901BD926A4E43B106BF17856F0755019C5E5E44@orsmsx508.amr.corp.intel.com>
On Tue, Sep 27, 2011 at 9:39 AM, Rose, Gregory V
<gregory.v.rose@intel.com> wrote:
>> -----Original Message-----
>> From: Jesse Gross [mailto:jesse@nicira.com]
>> Sent: Monday, September 26, 2011 5:54 PM
>> To: Rose, Gregory V
>> Cc: Kirsher, Jeffrey T; davem@davemloft.net; netdev@vger.kernel.org;
>> gospo@redhat.com; Jiri Pirko
>> Subject: Re: [net-next 02/10] ixgbevf: Fix broken trunk vlan
>>
>>
>> OK, maybe due to hardware limitations what I'm looking for just really
>> isn't possible.
>
> From what I can tell that is the case.
>
>> However, what I'm trying to emphasize is that vconfig
>> is not the only way that vlans can be consumed by the network stack
>> and active_vlans is just an indication of whether a vlan filter was
>> set, nothing more (perhaps I should have picked a better name when I
>> originally designed this stuff).
>
> Understood. The VF is incapable of receiving VLAN traffic unless a filter has been set. It doesn't do promiscuous mode and any path that doesn't actually end up setting a VLAN filter won't receive any VLAN traffic.
>
>> In particular, it is not intended to
>> determine whether a tag should be stripped off or not because
>> non-vconfig users don't necessarily know which vlans they care about
>> (think tcpdump or trunking over a bridge). A major goal of the
>> existing vlan infrastructure is to avoid having drivers make
>> assumptions about the consumer of the tag and instead just hand all
>> information over to the network stack so it can behave in a consistent
>> manner. That's why I was looking for alternate ways to get this
>> information without depending on active_vlans as this driver behaves
>> quite a bit differently from others, include the ixgbe PF driver.
>
> There are only two paths for the ixgbevf driver to receive VLAN traffic. Either a VLAN filter has been set, which will result in a bit tag in active_vlans being set or the system administrator in the host VMM has put the VF device in trunk VLAN mode using the 'ip link set <dev> vf <n> <vlanid>' path. There is no other way for it to receive VLAN traffic, so I think we're fine. And keep in mind, once the system admin has put the VF device in trunk vlan mode, the VF is no longer allowed, as a policy implemented in the PF driver, to set any other VLAN filters. Even if it did, it wouldn't work due to the operational characteristics of the VF device HW.
>
> The methods by which the ixgbe driver, as a fully featured Physical Function device, are quite a bit more varied. I believe you're thinking of the VF device as a typical Ethernet device and that is just not the case.
Yes, I think you're right. Thanks for the explanation.
^ permalink raw reply
* Re: Question about memory leak detector giving false positive report for net/core/flow.c
From: Catalin Marinas @ 2011-09-27 16:58 UTC (permalink / raw)
To: Eric Dumazet
Cc: Huajun Li, linux-mm@kvack.org, netdev, linux-kernel, Tejun Heo,
Christoph Lameter
In-Reply-To: <1317102918.2796.22.camel@edumazet-laptop>
On Tue, Sep 27, 2011 at 06:55:18AM +0100, Eric Dumazet wrote:
> Yes, it was not a patch, but the general idea for Catalin ;)
>
> You hit the fact that same zone (embedded percpu space) is now in a
> mixed state.
>
> In current kernels, the embedded percpu zone is already known by
> kmemleak, but with a large granularity. kmemleak is not aware of
> individual allocations/freeing in this large zone.
>
> Once kmemleak and percpu allocator are cooperating, we might find more
> kmemleaks. Right now, kmemleak can find pointers in percpu chunks that
> are not anymore reachable (they were freed), and therefore doesnt warn
> of possible memory leaks.
Thanks for suggestions. I need to understand the percpu code a bit
better as it looks that kmemleak is told about some memory blocks twice.
--
Catalin
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* RE: Thanks
From: Song Li @ 2011-09-28 7:51 UTC (permalink / raw)
To: Recipients
l am a Staff of Hang Seng Bank HongKong, I do not know if we can work
together in transferring $19,500,000.USD from my bank.
Finally if you are interested I shall provide you with more details.
Email: mrsong.lile@yahoo.cn
^ permalink raw reply
* Re: Question about memory leak detector giving false positive report for net/core/flow.c
From: Catalin Marinas @ 2011-09-27 17:01 UTC (permalink / raw)
To: Eric Dumazet
Cc: Huajun Li, linux-mm@kvack.org, netdev, linux-kernel, Tejun Heo,
Christoph Lameter
In-Reply-To: <1317102918.2796.22.camel@edumazet-laptop>
On Tue, Sep 27, 2011 at 06:55:18AM +0100, Eric Dumazet wrote:
> Yes, it was not a patch, but the general idea for Catalin ;)
>
> You hit the fact that same zone (embedded percpu space) is now in a
> mixed state.
>
> In current kernels, the embedded percpu zone is already known by
> kmemleak, but with a large granularity. kmemleak is not aware of
> individual allocations/freeing in this large zone.
It looks like this comes via the bootmem allocator. Maybe we could
simply call kmemleak_free() on the embedded percpu space and just track
those via the standard percpu API.
--
Catalin
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: intel 82599 multi-port performance
From: Alexander Duyck @ 2011-09-27 17:14 UTC (permalink / raw)
To: J.Hwan Kim; +Cc: netdev
In-Reply-To: <4E811C8E.8020508@gmail.com>
On 09/26/2011 05:45 PM, J.Hwan Kim wrote:
> On 2011년 09월 27일 01:04, Alexander Duyck wrote:
>> On 09/26/2011 08:42 AM, J.Hwan.Kim wrote:
>>> On 2011년 09월 26일 23:20, Chris Friesen wrote:
>>>> On 09/26/2011 04:26 AM, J.Hwan Kim wrote:
>>>>> Hi, everyone
>>>>>
>>>>> Now, I'm testing a network card including intel 82599.
>>>>> In our experiment, with the driver modified with ixgbe and multi-port
>>>>> enabled,
>>>>
>>>> What do you mean by "modified with ixgbe and multi-port enabled"? You
>>>> shouldn't need to do anything special to use both ports.
>>>>
>>>>> rx performance of each port with 10Gbps of 64bytes frame is
>>>>> a half than when only 1 port is used.
>>>>
>>>> Sounds like a cpu limitation. What is your cpu usage? How are your
>>>> interrupts routed? Are you using multiple rx queues?
>>>>
>>>
>>> Our server is XEON 2.4GHz with 8 cores.
>>> I'm using 4 RSS queues for each port and distributed it's interrupts
>>> to different cores respectively.
>>> I checked the CPU utilization with TOP, I guess ,it is not cpu
>>> imitation problem.
>>
>> What kind of rates are you seeing on a single port versus multiple
>> ports? There are multiple possibilities in terms of what could be
>> limiting your performance.
>>
>
> I tested the 10G - 64byte frames.
> With ixgbe-modified driver, in single port, 92% of packet received in
> driver level and in 2 port we received around 42% packets.
When you say 92% of packets are received are you talking about 92% of
line rate which would be somewhere around 14.8Mpps?
>> It sounds like you are using a single card, would that be correct?
>
> Yes, I tested a single card with 2 ports.
>
>> If you are running close to line rate on both ports this could be
>> causing you to saturate the PCIe x8 link. If you have a second card
>> available you may want to try installing that in a secondary Gen2
>> PCIe slot and seeing if you can improve the performance by using 2
>> PCIe slots instead of one.
>
> I tested it also, if it is tested with 2 card, it seems that the
> performance of each port is almost same with a single port. (maximum
> performance)
This more or less confirms what I was thinking. You are likely hitting
the PCIe limits of the adapters. The overhead for 64 byte packets is
too great and as a result you are exceeding the PCIe bandwidth available
to the adapter. In order to achieve line rate on both ports you would
likely need to increase your packet size to something along the lines of
256 bytes so that the additional PCIe overhead only contributes 50% or
less to the total PCIe traffic across the bus. Then the 2.5Gb/s of
network traffic should consume less than 4.0GT/s of PCIe traffic.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH net-next] tcp: rename tcp_skb_cb flags
From: David Miller @ 2011-09-27 17:25 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1317117114.2541.13.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 27 Sep 2011 11:51:54 +0200
> Rename struct tcp_skb_cb "flags" to "tcp_flags" to ease code review and
> maintenance.
>
> Its content is a combination of FIN/SYN/RST/PSH/ACK/URG/ECE/CWR flags
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* [PATCH net-next] skge: handle irq better on single port card
From: Stephen Hemminger @ 2011-09-27 17:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Most boards with SysKonnect/Marvell Ethernet have only a single port.
For the single port case, use the standard Ethernet driver convention
of allocating IRQ when device is brought up rather than at probe time.
This patch also adds some additional read after writes to avoid any
PCI posting problems when setting the IRQ mask.
The error handling of dual port cards is also changed. If second port
can not be brought up, then just fail. No point in continuing, since
the failure is most certainly because of out of memory.
It is worth noting that the dual port skge device has a single irq but two
seperate status rings and therefore has two NAPI objects, one for
each port.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/ethernet/marvell/skge.c 2011-09-27 08:46:08.893778800 -0700
+++ b/drivers/net/ethernet/marvell/skge.c 2011-09-27 10:23:37.557144935 -0700
@@ -113,6 +113,7 @@ static void yukon_init(struct skge_hw *h
static void genesis_mac_init(struct skge_hw *hw, int port);
static void genesis_link_up(struct skge_port *skge);
static void skge_set_multicast(struct net_device *dev);
+static irqreturn_t skge_intr(int irq, void *dev_id);
/* Avoid conditionals by using array */
static const int txqaddr[] = { Q_XA1, Q_XA2 };
@@ -2568,6 +2569,16 @@ static int skge_up(struct net_device *de
if (err)
goto free_rx_ring;
+ if (hw->ports == 1) {
+ err = request_irq(hw->pdev->irq, skge_intr, IRQF_SHARED,
+ dev->name, hw);
+ if (err) {
+ netdev_err(dev, "Unable to allocate interrupt %d error: %d\n",
+ hw->pdev->irq, err);
+ goto free_tx_ring;
+ }
+ }
+
/* Initialize MAC */
spin_lock_bh(&hw->phy_lock);
if (is_genesis(hw))
@@ -2595,11 +2606,14 @@ static int skge_up(struct net_device *de
spin_lock_irq(&hw->hw_lock);
hw->intr_mask |= portmask[port];
skge_write32(hw, B0_IMSK, hw->intr_mask);
+ skge_read32(hw, B0_IMSK);
spin_unlock_irq(&hw->hw_lock);
napi_enable(&skge->napi);
return 0;
+ free_tx_ring:
+ kfree(skge->tx_ring.start);
free_rx_ring:
skge_rx_clean(skge);
kfree(skge->rx_ring.start);
@@ -2640,9 +2654,13 @@ static int skge_down(struct net_device *
spin_lock_irq(&hw->hw_lock);
hw->intr_mask &= ~portmask[port];
- skge_write32(hw, B0_IMSK, hw->intr_mask);
+ skge_write32(hw, B0_IMSK, (hw->ports == 1) ? 0 : hw->intr_mask);
+ skge_read32(hw, B0_IMSK);
spin_unlock_irq(&hw->hw_lock);
+ if (hw->ports == 1)
+ free_irq(hw->pdev->irq, hw);
+
skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_OFF);
if (is_genesis(hw))
genesis_stop(skge);
@@ -3603,7 +3621,8 @@ static int skge_reset(struct skge_hw *hw
skge_write32(hw, B2_IRQM_INI, skge_usecs2clk(hw, 100));
skge_write32(hw, B2_IRQM_CTRL, TIM_START);
- skge_write32(hw, B0_IMSK, hw->intr_mask);
+ /* Leave irq disabled until first port is brought up. */
+ skge_write32(hw, B0_IMSK, 0);
for (i = 0; i < hw->ports; i++) {
if (is_genesis(hw))
@@ -3930,31 +3949,39 @@ static int __devinit skge_probe(struct p
goto err_out_free_netdev;
}
- err = request_irq(pdev->irq, skge_intr, IRQF_SHARED, hw->irq_name, hw);
- if (err) {
- dev_err(&pdev->dev, "%s: cannot assign irq %d\n",
- dev->name, pdev->irq);
- goto err_out_unregister;
- }
skge_show_addr(dev);
if (hw->ports > 1) {
dev1 = skge_devinit(hw, 1, using_dac);
- if (dev1 && register_netdev(dev1) == 0)
- skge_show_addr(dev1);
- else {
- /* Failure to register second port need not be fatal */
- dev_warn(&pdev->dev, "register of second port failed\n");
- hw->dev[1] = NULL;
- hw->ports = 1;
- if (dev1)
- free_netdev(dev1);
+ if (!dev1) {
+ err = -ENOMEM;
+ goto err_out_unregister;
}
+
+ err = register_netdev(dev1);
+ if (err) {
+ dev_err(&pdev->dev, "cannot register second net device\n");
+ goto err_out_free_dev1;
+ }
+
+ err = request_irq(pdev->irq, skge_intr, IRQF_SHARED,
+ hw->irq_name, hw);
+ if (err) {
+ dev_err(&pdev->dev, "cannot assign irq %d\n",
+ pdev->irq);
+ goto err_out_unregister_dev1;
+ }
+
+ skge_show_addr(dev1);
}
pci_set_drvdata(pdev, hw);
return 0;
+err_out_unregister_dev1:
+ unregister_netdev(dev1);
+err_out_free_dev1:
+ free_netdev(dev1);
err_out_unregister:
unregister_netdev(dev);
err_out_free_netdev:
@@ -3992,14 +4019,19 @@ static void __devexit skge_remove(struct
spin_lock_irq(&hw->hw_lock);
hw->intr_mask = 0;
- skge_write32(hw, B0_IMSK, 0);
- skge_read32(hw, B0_IMSK);
+
+ if (hw->ports > 1) {
+ skge_write32(hw, B0_IMSK, 0);
+ skge_read32(hw, B0_IMSK);
+ free_irq(pdev->irq, hw);
+ }
spin_unlock_irq(&hw->hw_lock);
skge_write16(hw, B0_LED, LED_STAT_OFF);
skge_write8(hw, B0_CTST, CS_RST_SET);
- free_irq(pdev->irq, hw);
+ if (hw->ports > 1)
+ free_irq(pdev->irq, hw);
pci_release_regions(pdev);
pci_disable_device(pdev);
if (dev1)
^ permalink raw reply
* Re: [PATCH] net: fix a typo in Documentation/networking/scaling.txt
From: David Miller @ 2011-09-27 17:26 UTC (permalink / raw)
To: jasowang; +Cc: netdev, linux-kernel, rdunlap, linux-doc
In-Reply-To: <20110927100354.18039.92505.stgit@dhcp-91-7.nay.redhat.com.englab.nay.redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Tue, 27 Sep 2011 18:03:55 +0800
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] RDSRDMA: Fix cleanup of rds_iw_mr_pool
From: Jonathan Lallinger @ 2011-09-27 17:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110927.013247.336618301904552114.davem@davemloft.net>
Hello David,
I am ashamed I made the same mistake twice. This happened because I had
two git trees (I made a second one when kernel.org went down based off
the github remote). I fixed, built, and ran several tests on the patch,
and then sent the wrong patch from an old git tree (which was never
build tested).
I can assure you I have a working patch, and it has been tested by the
QA group at Chelsio and it builds/runs but there are still additional
bugs in rds. So once I resolve those I will resend the correct patch
with some additional fixes.
I am sorry about this and it won't happen again.
Thanks,
Jonathan
David Miller wrote:
> From: Jonathan Lallinger <jonathan@ogc.us>
> Date: Tue, 13 Sep 2011 14:41:01 -0500
>
>
>> @@ -548,6 +550,7 @@ static int rds_iw_flush_mr_pool(struct rds_iw_mr_pool *pool, int free_all)
>> spin_unlock_irqrestore(&pool->list_lock, flags);
>> }
>>
>> + atomic_sub(unpinned, &poll->free_pinned);
>> atomic_sub(ncleaned, &pool->dirty_count);
>> atomic_sub(nfreed, &pool->item_count);
>>
>>
>
> net/rds/iw_rdma.c: In function ‘rds_iw_flush_mr_pool’:
> net/rds/iw_rdma.c:553:24: error: ‘poll’ undeclared (first use in this function)
> net/rds/iw_rdma.c:553:24: note: each undeclared identifier is reported only once for each function it appears in
>
> If you didn't even build test it, I know you didn't test it's
> functionality either.
>
> This is crazy.
>
> Well if it's not important enough to even build test this change
> before you post it, then it obviously doesn't matter if the RDMA
> module crashes the kernel when it's unloaded.
>
^ 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