* Re: [patch net-next v2 01/10] net: rename netdev_phys_port_id to more generic name
From: Jamal Hadi Salim @ 2014-11-10 12:56 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David Miller, jiri, netdev, nhorman, andy, tgraf, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, sfeldma, f.fainelli,
roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl
In-Reply-To: <5460B090.7080106@redhat.com>
On 11/10/14 07:33, Daniel Borkmann wrote:
> $ git grep -n MAX_PHYS_PORT_ID_LEN
> include/linux/netdevice.h:756:#define MAX_PHYS_PORT_ID_LEN 32
> include/linux/netdevice.h:762: unsigned char id[MAX_PHYS_PORT_ID_LEN];
> net/core/rtnetlink.c:871: +
> nla_total_size(MAX_PHYS_PORT_ID_LEN); /* IFLA_PHYS_PORT_ID */
> net/core/rtnetlink.c:1199: [IFLA_PHYS_PORT_ID] = { .type =
> NLA_BINARY, .len = MAX_PHYS_PORT_ID_LEN },
>
> ... and based on commit 66cae9ed6bc4 ("rtnl: export physical port id
> via RT netlink") only exported as read-only.
>
I guess it is *not exported* if no user space code sees it.
If that is the case, I agree that my suggestion is unneeded.
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v2 06/10] bridge: introduce fdb offloading via switchdev
From: Jamal Hadi Salim @ 2014-11-10 12:47 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, sfeldma, f.fainelli,
roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl
In-Reply-To: <20141110081552.GD1850@nanopsycho.orion>
On 11/10/14 03:15, Jiri Pirko wrote:
> Mon, Nov 10, 2014 at 04:47:48AM CET, jhs@mojatatu.com wrote:
>> On 11/09/14 05:51, Jiri Pirko wrote:
>>> From: Scott Feldman <sfeldma@gmail.com>
>>>
> Jamal, I believe we discussed this already.
I cant remember how that ended.
> The thing is that current
> fdb_add/del does not need vlanid and master/self flags, because it
> already has that (struct nlattr *tb[]). Here is the whole list of
> parameters to these functions:
> NDA_DST,
> NDA_LLADDR,
> NDA_CACHEINFO,
> NDA_PROBES,
> NDA_VLAN,
> NDA_PORT,
> NDA_VNI,
> NDA_IFINDEX,
> NDA_MASTER,
>
> There are few problems in re-using this. It is netlink based so for calling
> it from bridge code, we would have to construct netlink message. But
> that could be probably changed.
Trying to understand.
A netlink message for a bridge to add an fdb is targeted at the
*bridge port*.
That message has semantic which says "please add this entry
to the software bridge and/or offloaded hardware".
If something is targetted at the bridge port, ->ndo_fdb_add()
is invoked with an internally chewed structure.
Why would you have to construct a new netlink message to the driver?
> As you can see from the list of parameters, this is no longer about fdb (addr,
> vlanid) but this has been extended to something else.
I am still missing understanding that part.
Or maybe are you saying that you dont want to pass netlink
constructs to the driver?
> See vxlan code for
> what this is used for. I believe that fdb_add/del should be renamed to
> something else, perhaps l2neigh_add/del or something like that.
> The other problem is that fdb_add/del is currently used by various
> drivers for different purpose (adding macs to unicast list).
>
Ok, now a small spark ignited in my brain. You did talk about renaming
things to neighXXX in one of the exchanges. I think this is a separate
issue from the question of why you cant refactor ndo_fdb_add/del
The abuse of using this interface for unicast addresses is probably
driven by the fact some of the hardware probably offloads vlanid 0 or
something speacial like 4095 to point to the underlying hardware that
"this belongs to host cpu".
I am not a fan of it (and have posted in exchanges with Vlad in the
past).
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v2 01/10] net: rename netdev_phys_port_id to more generic name
From: Daniel Borkmann @ 2014-11-10 12:33 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: David Miller, jiri, netdev, nhorman, andy, tgraf, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, sfeldma, f.fainelli,
roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl
In-Reply-To: <5460AA45.6000007@mojatatu.com>
On 11/10/2014 01:06 PM, Jamal Hadi Salim wrote:
> On 11/10/14 00:23, David Miller wrote:
>> From: Jamal Hadi Salim <jhs@mojatatu.com>
>> Date: Sun, 09 Nov 2014 22:35:12 -0500
>>
>>> wouldnt this just break an existing ABI? You may need to introduce a
>>> new attribute.
>>
>> He isn't breaking anything Jamal, he's just changing the internal
>> macro name we use for the attribute's maximum length.
>
> It is a _user space visible rename_, how about:
>
> #define MAX_PHYS_ITEM_ID_LEN 32
> #define MAX_PHYS_PORT_ID_LEN MAX_PHYS_ITEM_ID_LEN
>
> I did miss the fact that the size didnt change.
Actually, it's currently not exposed via any uapi header ...
$ git grep -n MAX_PHYS_PORT_ID_LEN
include/linux/netdevice.h:756:#define MAX_PHYS_PORT_ID_LEN 32
include/linux/netdevice.h:762: unsigned char id[MAX_PHYS_PORT_ID_LEN];
net/core/rtnetlink.c:871: + nla_total_size(MAX_PHYS_PORT_ID_LEN); /* IFLA_PHYS_PORT_ID */
net/core/rtnetlink.c:1199: [IFLA_PHYS_PORT_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_PORT_ID_LEN },
... and based on commit 66cae9ed6bc4 ("rtnl: export physical port id
via RT netlink") only exported as read-only.
Best,
Daniel
^ permalink raw reply
* Re: [patch net-next v2 10/10] rocker: implement L2 bridge offloading
From: Jamal Hadi Salim @ 2014-11-10 12:27 UTC (permalink / raw)
To: Scott Feldman
Cc: Jiri Pirko, Netdev, David S. Miller, nhorman, Andy Gospodarek,
Thomas Graf, dborkman, ogerlitz, jesse, pshelar, azhou, ben,
stephen, Kirsher, Jeffrey T, vyasevic, xiyou.wangcong,
Fastabend, John R, edumazet, Florian Fainelli, Roopa Prabhu,
John Linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.ho
In-Reply-To: <CAE4R7bCdfn6rzvY5J5d_aj=eNKoT00iEphGJMnQOWy=WeLePTw@mail.gmail.com>
On 11/10/14 03:46, Scott Feldman wrote:
>
> IFLA_BRPORT_LEARNING is u8 attr and we're only using lower bit to turn
> learning on/off. Maybe we can use another bit to indicate learning to
> be done in sw or hw. I don't think adding another bit would break
> existing iproute2.
>
> LEARNING_ENABLED (1 << 0)
> LEARNING_HW (1 << 1)
>
> Would this work?
>
Yes to making it a bit. But:
This is not *learning*. You are doing a *sync*.
Those are two different things.
Learning on/off exists today. It signals to the L2 whether you
should learn or not.
I like the way fdb_add/del work with a flag which says
it is the software and/or offloaded version. Please keep that
semantic.
What you are doing above is letting the hardware learn then
syncing to software. You need a different flag there. something
like:
SYNC_HW_FDB (1<<1)
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v2 01/10] net: rename netdev_phys_port_id to more generic name
From: Jamal Hadi Salim @ 2014-11-10 12:17 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, sfeldma, f.fainelli,
roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl
In-Reply-To: <20141110074344.GB1850@nanopsycho.orion>
On 11/10/14 02:43, Jiri Pirko wrote:
> Mon, Nov 10, 2014 at 04:35:12AM CET, jhs@mojatatu.com wrote:
> I don't see a reason why this would break kabi:
>
> -#define MAX_PHYS_PORT_ID_LEN 32
> +#define MAX_PHYS_ITEM_ID_LEN 32
>
refer to my response to Dave. Just define MAX_PHYS_PORT_ID_LEN to
MAX_PHYS_ITEM_ID_LEN so people dont have to change their code
because a name change.
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v2 00/10] introduce rocker switch driver with hardware accelerated datapath api - phase 1: bridge fdb offload
From: Jamal Hadi Salim @ 2014-11-10 12:16 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, sfeldma, f.fainelli,
roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl
In-Reply-To: <20141110072301.GA1850@nanopsycho.orion>
On 11/10/14 02:23, Jiri Pirko wrote:
>
> Yes I looked over their patches. Roopas patche's are about new class of
> device which, as I commented in the cover letter, I left out for now and
> can be safely added later on.
>
> I went over the Ben's work very carefully as well. The patches are very
> rough, mostly rtl-chip specific. But again, my patchset is a base on
> which this patches can be build on. I see no issues in that.
>
>> At least please get their sign on - this is such an important piece of
>> new work that you should make sure you get consensus.
>
> Since I did not use their code now, I only put sign off of Scott.
>
Your last comment was "i am going to merge the patches" ;->
At least send an email explaining your plan to people who have worked
hard to cooperate with you or say it in the cover letter.
>> Otherwise we are back to square one and everyone is going their way with
>> their patches;
>
> I do think that we are in sync. I do not see any counter ways. As I
> said, their work can be added on to the base made of this patchset.
>
Ok, I hope so. I spoke for myself - it is important for this patches
you get their sign-on in my opinion.
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v2 01/10] net: rename netdev_phys_port_id to more generic name
From: Jamal Hadi Salim @ 2014-11-10 12:06 UTC (permalink / raw)
To: David Miller
Cc: jiri, netdev, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, sfeldma, f.fainelli,
roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl
In-Reply-To: <20141110.002336.70350092543746386.davem@davemloft.net>
On 11/10/14 00:23, David Miller wrote:
> From: Jamal Hadi Salim <jhs@mojatatu.com>
> Date: Sun, 09 Nov 2014 22:35:12 -0500
>
>> wouldnt this just break an existing ABI? You may need to introduce a
>> new attribute.
>
> He isn't breaking anything Jamal, he's just changing the internal
> macro name we use for the attribute's maximum length.
It is a _user space visible rename_, how about:
#define MAX_PHYS_ITEM_ID_LEN 32
#define MAX_PHYS_PORT_ID_LEN MAX_PHYS_ITEM_ID_LEN
I did miss the fact that the size didnt change.
cheers,
jamal
^ permalink raw reply
* [PATCH 4/4] qlcnic: remove pci_assigned_vfs() check while disabling VFs
From: Sathya Perla @ 2014-11-10 11:53 UTC (permalink / raw)
To: linux-pci, netdev; +Cc: ariel.elior, linux.nics, shahed.shaikh, ddutile
In-Reply-To: <1415620410-4937-1-git-send-email-sathya.perla@emulex.com>
From: Vasundhara Volam <vasundhara.volam@emulex.com>
The pci_assigned_vfs() check (while disabling VFs) is being moved to the
pci-sysfs.c file and will be done before invoking sriov_configure().
Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
.../net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c | 10 ----------
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c
index a29538b..9802914 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c
@@ -465,16 +465,6 @@ static int qlcnic_pci_sriov_disable(struct qlcnic_adapter *adapter)
{
struct net_device *netdev = adapter->netdev;
- if (pci_vfs_assigned(adapter->pdev)) {
- netdev_err(adapter->netdev,
- "SR-IOV VFs belonging to port %d are assigned to VMs. SR-IOV can not be disabled on this port\n",
- adapter->portnum);
- netdev_info(adapter->netdev,
- "Please detach SR-IOV VFs belonging to port %d from VMs, and then try to disable SR-IOV on this port\n",
- adapter->portnum);
- return -EPERM;
- }
-
qlcnic_sriov_pf_disable(adapter);
rtnl_lock();
--
1.7.1
^ permalink raw reply related
* [PATCH 3/4] i40e: remove pci_assigned_vfs() check while disabling VFs
From: Sathya Perla @ 2014-11-10 11:53 UTC (permalink / raw)
To: linux-pci, netdev; +Cc: ariel.elior, linux.nics, shahed.shaikh, ddutile
In-Reply-To: <1415620410-4937-1-git-send-email-sathya.perla@emulex.com>
From: Vasundhara Volam <vasundhara.volam@emulex.com>
The pci_assigned_vfs() check (while disabling VFs) is being moved to the
pci-sysfs.c file and will be done before invoking sriov_configure().
Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 7 +------
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index fff3c27..0028a9a 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -951,12 +951,7 @@ int i40e_pci_sriov_configure(struct pci_dev *pdev, int num_vfs)
if (num_vfs)
return i40e_pci_sriov_enable(pdev, num_vfs);
- if (!pci_vfs_assigned(pf->pdev)) {
- i40e_free_vfs(pf);
- } else {
- dev_warn(&pdev->dev, "Unable to free VFs because some are assigned to VMs.\n");
- return -EINVAL;
- }
+ i40e_free_vfs(pf);
return 0;
}
--
1.7.1
^ permalink raw reply related
* [PATCH 2/4] bnx2x: remove pci_assigned_vfs() check while disabling VFs
From: Sathya Perla @ 2014-11-10 11:53 UTC (permalink / raw)
To: linux-pci, netdev; +Cc: ariel.elior, linux.nics, shahed.shaikh, ddutile
In-Reply-To: <1415620410-4937-1-git-send-email-sathya.perla@emulex.com>
From: Vasundhara Volam <vasundhara.volam@emulex.com>
The pci_assigned_vfs() check (while disabling VFs) is being moved to the
pci-sysfs.c file and will be done before invoking sriov_configure().
Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
index c88b20a..e90a10b 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
@@ -2481,7 +2481,7 @@ int bnx2x_sriov_configure(struct pci_dev *dev, int num_vfs_param)
bp->requested_nr_virtfn = num_vfs_param;
if (num_vfs_param == 0) {
bnx2x_set_pf_tx_switching(bp, false);
- bnx2x_disable_sriov(bp);
+ pci_disable_sriov(bp->pdev);
return 0;
} else {
return bnx2x_enable_sriov(bp);
--
1.7.1
^ permalink raw reply related
* [PATCH 0/4] move pci_assivned_vfs() check (while disabling VFs) to pci sub-system
From: Sathya Perla @ 2014-11-10 11:53 UTC (permalink / raw)
To: linux-pci, netdev; +Cc: ariel.elior, linux.nics, shahed.shaikh, ddutile
A user must not be allowed to disable VFs while they are already assigned to
a guest. This check is being made in each individual driver that implements
the sriov_configure PCI method.
This patch-set fixes this code duplication by moving this check from
drivers to the sriov_nuvfs_store() routine just before invoking
sriov_configure() when num_vfs is equal to 0.
Vasundhara Volam (4):
pci: move pci_assivned_vfs() check while disabling VFs to pci
sub-system
bnx2x: remove pci_assigned_vfs() check while disabling VFs
i40e: remove pci_assigned_vfs() check while disabling VFs
qlcnic: remove pci_assigned_vfs() check while disabling VFs
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 2 +-
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 7 +------
.../net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c | 10 ----------
drivers/pci/pci-sysfs.c | 5 +++++
4 files changed, 7 insertions(+), 17 deletions(-)
^ permalink raw reply
* [PATCH 1/4] pci: move pci_assivned_vfs() check while disabling VFs to pci sub-system
From: Sathya Perla @ 2014-11-10 11:53 UTC (permalink / raw)
To: linux-pci, netdev; +Cc: ariel.elior, linux.nics, shahed.shaikh, ddutile
In-Reply-To: <1415620410-4937-1-git-send-email-sathya.perla@emulex.com>
From: Vasundhara Volam <vasundhara.volam@emulex.com>
A user must not be allowed to disable VFs while they are already assigned to
a guest. This check is being made in each individual driver that implements
the sriov_configure PCI method.
This patch fixes this code duplication by moving this check to the
sriov_nuvfs_store() routine just before invoking sriov_configure() when
num_vfs is equal to 0.
Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/pci/pci-sysfs.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 2c6643f..6e65b47 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -477,6 +477,11 @@ static ssize_t sriov_numvfs_store(struct device *dev,
}
if (num_vfs == 0) {
+ if (pci_vfs_assigned(pdev)) {
+ dev_warn(&pdev->dev, "Cannot disable VFs while they are assigned\n");
+ return -EBUSY;
+ }
+
/* disable VFs */
ret = pdev->driver->sriov_configure(pdev, 0);
if (ret < 0)
--
1.7.1
^ permalink raw reply related
* skbuff_fclone_cache poison overwritten
From: Sitsofe Wheeler @ 2014-11-10 11:32 UTC (permalink / raw)
To: David S. Miller
Cc: K. Y. Srinivasan, Haiyang Zhang, Long Li, netdev, linux-kernel
While using 3.18.0-rc3.x86_64-00116-g6ac94d3 on a Hyper-V 2012 R2 the
poison in skbuff_fclone_cache was overwritten:
[39099.484435] sd 7:0:0:0: [sdi] Attached SCSI disk
[39099.484688] sd 6:0:0:0: [sdh] Attached SCSI disk
[45285.786640] =============================================================================
[45285.787543] BUG skbuff_fclone_cache (Not tainted): Poison overwritten
[45285.787543] -----------------------------------------------------------------------------
[45285.787543] Disabling lock debugging due to kernel taint
[45285.787543] INFO: 0xffff8800d144c056-0xffff8800d144c056. First byte 0x6f instead of 0x6b
[45285.787543] INFO: Allocated in __alloc_skb+0x4e/0x240 age=11 cpu=1 pid=17444
[45285.787543] __slab_alloc+0x50a/0x563
[45285.787543] kmem_cache_alloc_node+0xfe/0x2a0
[45285.787543] __alloc_skb+0x4e/0x240
[45285.787543] sk_stream_alloc_skb+0x3d/0x110
[45285.787543] tcp_sendmsg+0x36d/0xc60
[45285.787543] inet_sendmsg+0xd7/0xf0
[45285.787543] sock_sendmsg+0x90/0xb0
[45285.787543] SYSC_sendto+0x10e/0x150
[45285.787543] SyS_sendto+0xe/0x10
[45285.787543] system_call_fastpath+0x12/0x17
[45285.787543] INFO: Freed in kfree_skbmem+0x6f/0xa0 age=21 cpu=1 pid=17444
[45285.787543] __slab_free+0x39/0x2a0
[45285.787543] kmem_cache_free+0x1ce/0x280
[45285.787543] kfree_skbmem+0x6f/0xa0
[45285.787543] __kfree_skb+0x1e/0x30
[45285.787543] tcp_ack+0x66e/0x11f0
[45285.787543] tcp_rcv_established+0x514/0x6e0
[45285.787543] tcp_v4_do_rcv+0xb4/0x330
[45285.787543] release_sock+0xfd/0x1f0
[45285.787543] tcp_sendmsg+0xa65/0xc60
[45285.787543] inet_sendmsg+0xd7/0xf0
[45285.787543] sock_sendmsg+0x90/0xb0
[45285.787543] SYSC_sendto+0x10e/0x150
[45285.787543] SyS_sendto+0xe/0x10
[45285.787543] system_call_fastpath+0x12/0x17
[45285.787543] INFO: Slab 0xffffea0003451200 objects=42 used=42 fp=0x (null) flags=0x3ffe0000004080
[45285.787543] INFO: Object 0xffff8800d144bf00 @offset=16128 fp=0xffff8800d1448f00
[45285.787543] Bytes b4 ffff8800d144bef0: 88 3d ad 02 01 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a .=......ZZZZZZZZ
[45285.787543] Object ffff8800d144bf00: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144bf10: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144bf20: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144bf30: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144bf40: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144bf50: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144bf60: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144bf70: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144bf80: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144bf90: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144bfa0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144bfb0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144bfc0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144bfd0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144bfe0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144bff0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144c000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144c010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144c020: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144c030: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144c040: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144c050: 6b 6b 6b 6b 6b 6b 6f 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkokkkkkkkkk
[45285.787543] Object ffff8800d144c060: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144c070: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144c080: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144c090: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144c0a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[45285.787543] Object ffff8800d144c0b0: 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkk.
[45285.787543] Redzone ffff8800d144c0b8: bb bb bb bb bb bb bb bb ........
[45285.787543] Padding ffff8800d144c1f8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
[45285.787543] CPU: 7 PID: 16678 Comm: phantomjs Tainted: G B 3.18.0-rc3.x86_64-00116-g6ac94d3 #160
[45285.787543] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006 05/23/2012
[45285.787543] ffff8800d144bf00 ffff8801eb41b928 ffffffff816db38f 0000000000000000
[45285.787543] ffff8801fbd34e00 ffff8801eb41b968 ffffffff811a6187 0000000000000008
[45285.787543] ffff880000000001 ffff8800d144c057 ffff8801fbd34e00 000000000000006b
[45285.787543] Call Trace:
[45285.787543] [<ffffffff816db38f>] dump_stack+0x4e/0x68
[45285.787543] [<ffffffff811a6187>] print_trailer+0x1c7/0x1e0
[45285.787543] [<ffffffff811a6b7b>] check_bytes_and_report+0xbb/0x110
[45285.787543] [<ffffffff811a76ee>] check_object+0x10e/0x240
[45285.787543] [<ffffffff815fb11e>] ? __alloc_skb+0x4e/0x240
[45285.787543] [<ffffffff816d8b65>] alloc_debug_processing+0x76/0x118
[45285.787543] [<ffffffff816d981b>] __slab_alloc+0x50a/0x563
[45285.787543] [<ffffffff815fb11e>] ? __alloc_skb+0x4e/0x240
[45285.787543] [<ffffffff810b7ad8>] ? mark_held_locks+0x88/0xa0
[45285.787543] [<ffffffff811a9dbe>] kmem_cache_alloc_node+0xfe/0x2a0
[45285.787543] [<ffffffff815fb11e>] __alloc_skb+0x4e/0x240
[45285.787543] [<ffffffff81655c3d>] sk_stream_alloc_skb+0x3d/0x110
[45285.787543] [<ffffffff8165666d>] tcp_sendmsg+0x36d/0xc60
[45285.787543] [<ffffffff81683847>] inet_sendmsg+0xd7/0xf0
[45285.787543] [<ffffffff81683775>] ? inet_sendmsg+0x5/0xf0
[45285.787543] [<ffffffff815f2980>] sock_sendmsg+0x90/0xb0
[45285.787543] [<ffffffff811e4541>] ? __fget_light+0x61/0x80
[45285.787543] [<ffffffff811e4ee3>] ? __fdget+0x13/0x20
[45285.787543] [<ffffffff815f2aae>] SYSC_sendto+0x10e/0x150
[45285.787543] [<ffffffff811cab6f>] ? SYSC_newstat+0x2f/0x40
[45285.787543] [<ffffffff816e5a5c>] ? retint_swapgs+0x13/0x1b
[45285.787543] [<ffffffff813aa1fe>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[45285.787543] [<ffffffff815f3afe>] SyS_sendto+0xe/0x10
[45285.787543] [<ffffffff816e4e29>] system_call_fastpath+0x12/0x17
[45285.787543] FIX skbuff_fclone_cache: Restoring 0xffff8800d144c056-0xffff8800d144c056=0x6b
[45285.787543] FIX skbuff_fclone_cache: Marking all objects used
[46810.070997] =============================================================================
[46810.071289] BUG skbuff_fclone_cache (Tainted: G B ): Poison overwritten
[46810.071289] -----------------------------------------------------------------------------
[46810.071289] INFO: 0xffff8801c48fe756-0xffff8801c48fe756. First byte 0x6f instead of 0x6b
[46810.071289] INFO: Allocated in __alloc_skb+0x4e/0x240 age=9 cpu=6 pid=1220
[46810.071289] __slab_alloc+0x50a/0x563
[46810.071289] kmem_cache_alloc_node+0xfe/0x2a0
[46810.071289] __alloc_skb+0x4e/0x240
[46810.071289] sk_stream_alloc_skb+0x3d/0x110
[46810.071289] tcp_sendmsg+0x36d/0xc60
[46810.071289] inet_sendmsg+0xd7/0xf0
[46810.071289] sock_sendmsg+0x90/0xb0
[46810.071289] SYSC_sendto+0x10e/0x150
[46810.071289] SyS_sendto+0xe/0x10
[46810.071289] system_call_fastpath+0x12/0x17
[46810.071289] INFO: Freed in kfree_skbmem+0x6f/0xa0 age=23 cpu=6 pid=1220
[46810.071289] __slab_free+0x39/0x2a0
[46810.071289] kmem_cache_free+0x1ce/0x280
[46810.071289] kfree_skbmem+0x6f/0xa0
[46810.071289] __kfree_skb+0x1e/0x30
[46810.071289] tcp_ack+0x66e/0x11f0
[46810.071289] tcp_rcv_established+0x107/0x6e0
[46810.071289] tcp_v4_do_rcv+0xb4/0x330
[46810.071289] release_sock+0xfd/0x1f0
[46810.071289] tcp_sendmsg+0xa65/0xc60
[46810.071289] inet_sendmsg+0xd7/0xf0
[46810.071289] sock_sendmsg+0x90/0xb0
[46810.071289] SYSC_sendto+0x10e/0x150
[46810.071289] SyS_sendto+0xe/0x10
[46810.071289] system_call_fastpath+0x12/0x17
[46810.071289] INFO: Slab 0xffffea0007123e00 objects=42 used=42 fp=0x (null) flags=0x5ffe0000004080
[46810.071289] INFO: Object 0xffff8801c48fe600 @offset=26112 fp=0xffff8801c48fd700
[46810.071289] Bytes b4 ffff8801c48fe5f0: c2 89 c4 02 01 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ
[46810.071289] Object ffff8801c48fe600: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.071289] Object ffff8801c48fe610: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.071289] Object ffff8801c48fe620: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.071289] Object ffff8801c48fe630: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.071289] Object ffff8801c48fe640: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.071289] Object ffff8801c48fe650: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.071289] Object ffff8801c48fe660: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.071289] Object ffff8801c48fe670: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.071289] Object ffff8801c48fe680: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.071289] Object ffff8801c48fe690: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.071289] Object ffff8801c48fe6a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.071289] Object ffff8801c48fe6b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.071289] Object ffff8801c48fe6c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.071289] Object ffff8801c48fe6d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.071289] Object ffff8801c48fe6e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.071289] Object ffff8801c48fe6f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.071289] Object ffff8801c48fe700: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.228303] Object ffff8801c48fe710: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.228303] Object ffff8801c48fe720: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.240204] Object ffff8801c48fe730: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.240204] Object ffff8801c48fe740: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.240204] Object ffff8801c48fe750: 6b 6b 6b 6b 6b 6b 6f 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkokkkkkkkkk
[46810.240204] Object ffff8801c48fe760: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.240204] Object ffff8801c48fe770: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.240204] Object ffff8801c48fe780: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.240204] Object ffff8801c48fe790: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.240204] Object ffff8801c48fe7a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46810.291135] Object ffff8801c48fe7b0: 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkk.
[46810.291135] Redzone ffff8801c48fe7b8: bb bb bb bb bb bb bb bb ........
[46810.291135] Padding ffff8801c48fe8f8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
[46810.291135] CPU: 6 PID: 1233 Comm: phantomjs Tainted: G B 3.18.0-rc3.x86_64-00116-g6ac94d3 #160
[46810.291135] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006 05/23/2012
[46810.291135] ffff8801c48fe600 ffff8801f2ebbc08 ffffffff816db38f ffff8801b6b59350
[46810.291135] ffff8801fbd34e00 ffff8801f2ebbc48 ffffffff811a6187 0000000000000008
[46810.291135] ffff880100000001 ffff8801c48fe757 ffff8801fbd34e00 000000000000006b
[46810.291135] Call Trace:
[46810.291135] [<ffffffff816db38f>] dump_stack+0x4e/0x68
[46810.291135] [<ffffffff811a6187>] print_trailer+0x1c7/0x1e0
[46810.291135] [<ffffffff811a6b7b>] check_bytes_and_report+0xbb/0x110
[46810.291135] [<ffffffff811a76ee>] check_object+0x10e/0x240
[46810.291135] [<ffffffff815fb11e>] ? __alloc_skb+0x4e/0x240
[46810.291135] [<ffffffff816d8b65>] alloc_debug_processing+0x76/0x118
[46810.291135] [<ffffffff816d981b>] __slab_alloc+0x50a/0x563
[46810.291135] [<ffffffff810b7f4d>] ? trace_hardirqs_on+0xd/0x10
[46810.291135] [<ffffffff815fb11e>] ? __alloc_skb+0x4e/0x240
[46810.291135] [<ffffffff811a9dbe>] kmem_cache_alloc_node+0xfe/0x2a0
[46810.291135] [<ffffffff815fb11e>] __alloc_skb+0x4e/0x240
[46810.291135] [<ffffffff81666caa>] tcp_send_fin+0x7a/0x1a0
[46810.291135] [<ffffffff81657fe6>] tcp_shutdown+0x46/0x60
[46810.291135] [<ffffffff81682125>] inet_shutdown+0xb5/0x110
[46810.291135] [<ffffffff815f3d17>] SyS_shutdown+0x47/0x70
[46810.291135] [<ffffffff816e4e29>] system_call_fastpath+0x12/0x17
[46810.291135] FIX skbuff_fclone_cache: Restoring 0xffff8801c48fe756-0xffff8801c48fe756=0x6b
[46810.291135] FIX skbuff_fclone_cache: Marking all objects used
[46994.744143] =============================================================================
[46994.744548] BUG skbuff_fclone_cache (Tainted: G B ): Poison overwritten
[46994.744548] -----------------------------------------------------------------------------
[46994.744548] INFO: 0xffff8801eb7df056-0xffff8801eb7df056. First byte 0x6f instead of 0x6b
[46994.744548] INFO: Allocated in __alloc_skb+0x4e/0x240 age=10 cpu=0 pid=17426
[46994.744548] __slab_alloc+0x50a/0x563
[46994.744548] kmem_cache_alloc_node+0xfe/0x2a0
[46994.744548] __alloc_skb+0x4e/0x240
[46994.744548] sk_stream_alloc_skb+0x3d/0x110
[46994.744548] tcp_sendmsg+0x36d/0xc60
[46994.744548] inet_sendmsg+0xd7/0xf0
[46994.744548] sock_sendmsg+0x90/0xb0
[46994.744548] SYSC_sendto+0x10e/0x150
[46994.744548] SyS_sendto+0xe/0x10
[46994.744548] system_call_fastpath+0x12/0x17
[46994.744548] INFO: Freed in kfree_skbmem+0x6f/0xa0 age=21 cpu=0 pid=17426
[46994.744548] __slab_free+0x39/0x2a0
[46994.744548] kmem_cache_free+0x1ce/0x280
[46994.744548] kfree_skbmem+0x6f/0xa0
[46994.744548] __kfree_skb+0x1e/0x30
[46994.744548] tcp_ack+0x66e/0x11f0
[46994.744548] tcp_rcv_established+0x514/0x6e0
[46994.744548] tcp_v4_do_rcv+0xb4/0x330
[46994.744548] release_sock+0xfd/0x1f0
[46994.744548] tcp_sendmsg+0xa65/0xc60
[46994.744548] inet_sendmsg+0xd7/0xf0
[46994.744548] sock_sendmsg+0x90/0xb0
[46994.744548] SYSC_sendto+0x10e/0x150
[46994.744548] SyS_sendto+0xe/0x10
[46994.744548] system_call_fastpath+0x12/0x17
[46994.744548] INFO: Slab 0xffffea0007adf600 objects=42 used=42 fp=0x (null) flags=0x5ffe0000004080
[46994.744548] INFO: Object 0xffff8801eb7def00 @offset=28416 fp=0xffff8801eb7db900
[46994.744548] Bytes b4 ffff8801eb7deef0: f0 cd b1 02 01 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ
[46994.744548] Object ffff8801eb7def00: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7def10: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7def20: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7def30: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7def40: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7def50: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7def60: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7def70: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7def80: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7def90: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7defa0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7defb0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7defc0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7defd0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7defe0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7deff0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7df000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7df010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7df020: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7df030: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7df040: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7df050: 6b 6b 6b 6b 6b 6b 6f 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkokkkkkkkkk
[46994.744548] Object ffff8801eb7df060: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7df070: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7df080: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7df090: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7df0a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[46994.744548] Object ffff8801eb7df0b0: 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkk.
[46994.744548] Redzone ffff8801eb7df0b8: bb bb bb bb bb bb bb bb ........
[46994.744548] Padding ffff8801eb7df1f8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
[46994.744548] CPU: 4 PID: 24686 Comm: phantomjs Tainted: G B 3.18.0-rc3.x86_64-00116-g6ac94d3 #160
[46994.744548] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006 05/23/2012
[46994.744548] ffff8801eb7def00 ffff8801c4823928 ffffffff816db38f 0000000000000000
[46994.744548] ffff8801fbd34e00 ffff8801c4823968 ffffffff811a6187 0000000000000008
[46994.744548] ffff880100000001 ffff8801eb7df057 ffff8801fbd34e00 000000000000006b
[46994.744548] Call Trace:
[46994.744548] [<ffffffff816db38f>] dump_stack+0x4e/0x68
[46994.744548] [<ffffffff811a6187>] print_trailer+0x1c7/0x1e0
[46994.744548] [<ffffffff811a6b7b>] check_bytes_and_report+0xbb/0x110
[46994.744548] [<ffffffff811a76ee>] check_object+0x10e/0x240
[46994.744548] [<ffffffff815fb11e>] ? __alloc_skb+0x4e/0x240
[46994.744548] [<ffffffff816d8b65>] alloc_debug_processing+0x76/0x118
[46994.744548] [<ffffffff816d981b>] __slab_alloc+0x50a/0x563
[46994.744548] [<ffffffff815fb11e>] ? __alloc_skb+0x4e/0x240
[46994.744548] [<ffffffff8100611b>] ? print_context_stack+0xdb/0x100
[46994.744548] [<ffffffff811a9dbe>] kmem_cache_alloc_node+0xfe/0x2a0
[46994.744548] [<ffffffff815fb11e>] __alloc_skb+0x4e/0x240
[46994.744548] [<ffffffff81655c3d>] sk_stream_alloc_skb+0x3d/0x110
[46994.744548] [<ffffffff8165666d>] tcp_sendmsg+0x36d/0xc60
[46994.744548] [<ffffffff81683847>] inet_sendmsg+0xd7/0xf0
[46994.744548] [<ffffffff81683775>] ? inet_sendmsg+0x5/0xf0
[46994.744548] [<ffffffff815f2980>] sock_sendmsg+0x90/0xb0
[46994.744548] [<ffffffff811e4541>] ? __fget_light+0x61/0x80
[46994.744548] [<ffffffff811e4ee3>] ? __fdget+0x13/0x20
[46994.744548] [<ffffffff815f2aae>] SYSC_sendto+0x10e/0x150
[46994.744548] [<ffffffff811cab6f>] ? SYSC_newstat+0x2f/0x40
[46994.744548] [<ffffffff810db34e>] ? getnstimeofday64+0xe/0x30
[46994.744548] [<ffffffff813aa1fe>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[46994.744548] [<ffffffff815f3afe>] SyS_sendto+0xe/0x10
[46994.744548] [<ffffffff816e4e29>] system_call_fastpath+0x12/0x17
[46994.744548] FIX skbuff_fclone_cache: Restoring 0xffff8801eb7df056-0xffff8801eb7df056=0x6b
[46994.744548] FIX skbuff_fclone_cache: Marking all objects used
[71820.156136] =============================================================================
[71820.156461] BUG skbuff_fclone_cache (Tainted: G B ): Poison overwritten
[71820.156461] -----------------------------------------------------------------------------
[71820.156461] INFO: 0xffff8801eb42e756-0xffff8801eb42e756. First byte 0x6f instead of 0x6b
[71820.156461] INFO: Allocated in __alloc_skb+0x4e/0x240 age=11 cpu=3 pid=4181
[71820.156461] __slab_alloc+0x50a/0x563
[71820.156461] kmem_cache_alloc_node+0xfe/0x2a0
[71820.156461] __alloc_skb+0x4e/0x240
[71820.156461] sk_stream_alloc_skb+0x3d/0x110
[71820.156461] tcp_sendmsg+0x36d/0xc60
[71820.156461] inet_sendmsg+0xd7/0xf0
[71820.156461] sock_sendmsg+0x90/0xb0
[71820.156461] SYSC_sendto+0x10e/0x150
[71820.156461] SyS_sendto+0xe/0x10
[71820.156461] system_call_fastpath+0x12/0x17
[71820.156461] INFO: Freed in kfree_skbmem+0x6f/0xa0 age=30 cpu=3 pid=4181
[71820.156461] __slab_free+0x39/0x2a0
[71820.156461] kmem_cache_free+0x1ce/0x280
[71820.156461] kfree_skbmem+0x6f/0xa0
[71820.156461] __kfree_skb+0x1e/0x30
[71820.156461] tcp_ack+0x66e/0x11f0
[71820.156461] tcp_rcv_established+0x107/0x6e0
[71820.156461] tcp_v4_do_rcv+0xb4/0x330
[71820.156461] release_sock+0xfd/0x1f0
[71820.156461] tcp_sendmsg+0xa65/0xc60
[71820.156461] inet_sendmsg+0xd7/0xf0
[71820.156461] sock_sendmsg+0x90/0xb0
[71820.156461] SYSC_sendto+0x10e/0x150
[71820.156461] SyS_sendto+0xe/0x10
[71820.156461] system_call_fastpath+0x12/0x17
[71820.156461] INFO: Slab 0xffffea0007ad0a00 objects=42 used=42 fp=0x (null) flags=0x5ffe0000004080
[71820.156461] INFO: Object 0xffff8801eb42e600 @offset=26112 fp=0xffff8801eb42b600
[71820.156461] Bytes b4 ffff8801eb42e5f0: 48 1d 41 04 01 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a H.A.....ZZZZZZZZ
[71820.156461] Object ffff8801eb42e600: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.156461] Object ffff8801eb42e610: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.156461] Object ffff8801eb42e620: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.156461] Object ffff8801eb42e630: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.156461] Object ffff8801eb42e640: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.156461] Object ffff8801eb42e650: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.156461] Object ffff8801eb42e660: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.156461] Object ffff8801eb42e670: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.156461] Object ffff8801eb42e680: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.290941] Object ffff8801eb42e690: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.290941] Object ffff8801eb42e6a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.290941] Object ffff8801eb42e6b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.290941] Object ffff8801eb42e6c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.290941] Object ffff8801eb42e6d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.290941] Object ffff8801eb42e6e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.290941] Object ffff8801eb42e6f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.290941] Object ffff8801eb42e700: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.290941] Object ffff8801eb42e710: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.290941] Object ffff8801eb42e720: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.290941] Object ffff8801eb42e730: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.290941] Object ffff8801eb42e740: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.290941] Object ffff8801eb42e750: 6b 6b 6b 6b 6b 6b 6f 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkokkkkkkkkk
[71820.290941] Object ffff8801eb42e760: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.290941] Object ffff8801eb42e770: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.290941] Object ffff8801eb42e780: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.290941] Object ffff8801eb42e790: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.290941] Object ffff8801eb42e7a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[71820.290941] Object ffff8801eb42e7b0: 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkk.
[71820.290941] Redzone ffff8801eb42e7b8: bb bb bb bb bb bb bb bb ........
[71820.290941] Padding ffff8801eb42e8f8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
[71820.290941] CPU: 3 PID: 4219 Comm: phantomjs Tainted: G B 3.18.0-rc3.x86_64-00116-g6ac94d3 #160
[71820.290941] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006 05/23/2012
[71820.290941] ffff8801eb42e600 ffff8800d1743c08 ffffffff816db38f 0000000000000000
[71820.290941] ffff8801fbd34e00 ffff8800d1743c48 ffffffff811a6187 0000000000000008
[71820.290941] ffff880100000001 ffff8801eb42e757 ffff8801fbd34e00 000000000000006b
[71820.290941] Call Trace:
[71820.290941] [<ffffffff816db38f>] dump_stack+0x4e/0x68
[71820.290941] [<ffffffff811a6187>] print_trailer+0x1c7/0x1e0
[71820.290941] [<ffffffff811a6b7b>] check_bytes_and_report+0xbb/0x110
[71820.290941] [<ffffffff811a76ee>] check_object+0x10e/0x240
[71820.290941] [<ffffffff815fb11e>] ? __alloc_skb+0x4e/0x240
[71820.290941] [<ffffffff816d8b65>] alloc_debug_processing+0x76/0x118
[71820.290941] [<ffffffff816d981b>] __slab_alloc+0x50a/0x563
[71820.290941] [<ffffffff810b7f4d>] ? trace_hardirqs_on+0xd/0x10
[71820.290941] [<ffffffff815fb11e>] ? __alloc_skb+0x4e/0x240
[71820.290941] [<ffffffff811a9dbe>] kmem_cache_alloc_node+0xfe/0x2a0
[71820.290941] [<ffffffff815fb11e>] __alloc_skb+0x4e/0x240
[71820.290941] [<ffffffff81666caa>] tcp_send_fin+0x7a/0x1a0
[71820.290941] [<ffffffff81657fe6>] tcp_shutdown+0x46/0x60
[71820.290941] [<ffffffff81682125>] inet_shutdown+0xb5/0x110
[71820.290941] [<ffffffff815f3d17>] SyS_shutdown+0x47/0x70
[71820.290941] [<ffffffff816e4e29>] system_call_fastpath+0x12/0x17
[71820.290941] FIX skbuff_fclone_cache: Restoring 0xffff8801eb42e756-0xffff8801eb42e756=0x6b
[71820.290941] FIX skbuff_fclone_cache: Marking all objects used
As I don't know where to file this I'm sending it to networking and
Hyper-V people initially... If anyone can give tips on narrowing down
the true cause that would be helpful. The workload is new and older
kernels on Hyper-V hit other issues so bisection isn't an easy start...
--
Sitsofe | http://sucs.org/~sits/
^ permalink raw reply
* Re: [PATCH] brcmfmac: unlink URB when request timed out
From: Arend van Spriel @ 2014-11-10 11:18 UTC (permalink / raw)
To: Mathy Vanhoef, brudley, frankyl, meuleman, linville, pieterpg,
linux-wireless, brcm80211-dev-list, netdev, Oliver Neukum
In-Reply-To: <545FAE05.2030701@gmail.com>
On 09-11-14 19:10, Mathy Vanhoef wrote:
> From: Mathy Vanhoef <vanhoefm@gmail.com>
>
> Unlink the submitted URB in brcmf_usb_dl_cmd if the request timed out. This
> assures the URB is never submitted twice, preventing a driver crash.
Hi Mathy,
What driver crash are you referring to? The log only shows the WARNING
ending in a USB disconnect but no actual crash. Does your patch get the
driver running properly or does it only avoid the warning.
With that said, it seems there is some need for improvement, but I also
notice you are running this on a virtual machine so could that affect
the timeout to kick in before completion. Could you try to increase the
timeout. Still when a timeout occurs this needs to be handled properly.
Could you also try the following patch?
Regards,
Arend
---
drivers/net/wireless/brcm80211/brcmfmac/usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
b/drivers/net/wireles
index dc13591..786c40b 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
@@ -640,7 +640,7 @@ static int brcmf_usb_dl_cmd(struct brcmf_usbdev_info
*devinf
char *tmpbuf;
u16 size;
- if ((!devinfo) || (devinfo->ctl_urb == NULL))
+ if (!devinfo || !devinfo->ctl_urb || !devinfo->ctl_completed)
return -EINVAL;
tmpbuf = kmalloc(buflen, GFP_ATOMIC);
> Signed-off-by: Mathy Vanhoef <vanhoefm@gmail.com>
> ---
> Currently brcmfmac may crash when a USB device is attached (tested with a LG
> TWFM-B003D). In particular it fails on the second call to brcmf_usb_dl_cmd in
> the while loop of brcmf_usb_resetcfg. The problem is that an URB is being
> submitted twice:
>
> [ 169.861800] brcmfmac: brcmf_usb_dl_writeimage Enter, fw f14db000, len 348160
> [ 171.787791] brcmfmac: brcmf_usb_dl_writeimage Exit, err=0
> [ 171.787797] brcmfmac: brcmf_usb_dlstart Exit, err=0
> [ 171.787799] brcmfmac: brcmf_usb_dlrun Enter
> [ 171.791794] brcmfmac: brcmf_usb_resetcfg Enter
> [ 173.988072] ------------[ cut here ]------------
> [ 173.988083] WARNING: CPU: 0 PID: 369 at drivers/usb/core/urb.c:339 usb_submit_urb+0x4e6/0x500()
> [ 173.988085] URB eaf45f00 submitted while active
> [ 173.988086] Modules linked in: brcmfmac brcmutil vmw_pvscsi pcnet32 mptspi mptscsih mptbase
> [ 173.988100] CPU: 0 PID: 369 Comm: kworker/0:2 Not tainted 3.18.0-rc3-wl #1
> [ 173.988102] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
> [ 173.988106] Workqueue: events request_firmware_work_func
> [ 173.988108] 00000000 00000000 ee747db8 c1711f4a ee747df8 ee747de8 c103edaf c18d1e10
> [ 173.988112] ee747e14 00000171 c18a8b29 00000153 c1490556 c1490556 eaf45f00 eafdc660
> [ 173.988115] f14b8fa0 ee747e00 c103ee4e 00000009 ee747df8 c18d1e10 ee747e14 ee747e50
> [ 173.988119] Call Trace:
> [ 173.988129] [<c1711f4a>] dump_stack+0x41/0x52
> [ 173.988136] [<c103edaf>] warn_slowpath_common+0x7f/0xa0
> [ 173.988139] [<c1490556>] ? usb_submit_urb+0x4e6/0x500
> [ 173.988141] [<c1490556>] ? usb_submit_urb+0x4e6/0x500
> [ 173.988147] [<f14b8fa0>] ? brcmf_usb_ioctl_resp_wake+0x40/0x40 [brcmfmac]
> [ 173.988150] [<c103ee4e>] warn_slowpath_fmt+0x2e/0x30
> [ 173.988152] [<c1490556>] usb_submit_urb+0x4e6/0x500
> [ 173.988156] [<c1123de1>] ? __kmalloc+0x21/0x140
> [ 173.988161] [<f14b91c3>] ? brcmf_usb_dl_cmd+0x33/0x120 [brcmfmac]
> [ 173.988166] [<f14b9243>] brcmf_usb_dl_cmd+0xb3/0x120 [brcmfmac]
> [ 173.988170] [<f14ba6c4>] brcmf_usb_probe_phase2+0x4e4/0x640 [brcmfmac]
> [ 173.988176] [<f14b4900>] brcmf_fw_request_code_done+0xd0/0xf0 [brcmfmac]
> [ 173.988178] [<c1400876>] request_firmware_work_func+0x26/0x50
> [ 173.988182] [<c10513ee>] process_one_work+0x11e/0x360
> [ 173.988184] [<c1051750>] worker_thread+0xf0/0x3c0
> [ 173.988205] [<c106e14a>] ? __wake_up_locked+0x1a/0x20
> [ 173.988208] [<c1051660>] ? process_scheduled_works+0x30/0x30
> [ 173.988211] [<c1055b56>] kthread+0x96/0xb0
> [ 173.988214] [<c1719c81>] ret_from_kernel_thread+0x21/0x30
> [ 173.988217] [<c1055ac0>] ? kthread_worker_fn+0x110/0x110
> [ 173.988219] ---[ end trace 0c88bf46801de083 ]---
> [ 173.988221] brcmf_usb_dl_cmd: usb_submit_urb failed -16
> [ 173.988396] brcmfmac: brcmf_usb_probe_phase2 failed: dev=1-1, err=-19
> [ 173.989503] brcmfmac: brcmf_usb_disconnect Enter
>
> This patch fixes the brcmf_usb_dl_cmd function to prevent an URB from being
> submitted twice. Tested using a LG TWFM-B003D, which now works properly.
>
>
> drivers/net/wireless/brcm80211/brcmfmac/usb.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
> index 5265aa7..1bc7858 100644
> --- a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
> +++ b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
> @@ -738,10 +738,12 @@ static int brcmf_usb_dl_cmd(struct brcmf_usbdev_info *devinfo, u8 cmd,
> goto finalize;
> }
>
> - if (!brcmf_usb_ioctl_resp_wait(devinfo))
> + if (!brcmf_usb_ioctl_resp_wait(devinfo)) {
> + usb_unlink_urb(devinfo->ctl_urb);
> ret = -ETIMEDOUT;
> - else
> + } else {
> memcpy(buffer, tmpbuf, buflen);
> + }
>
> finalize:
> kfree(tmpbuf);
>
^ permalink raw reply related
* [PATCH resent] net: ppp: Don't call bpf_prog_create() in ppp_lock
From: Takashi Iwai @ 2014-11-10 10:50 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Paul Mackerras, linux-ppp, Stefan Seyfried
In ppp_ioctl(), bpf_prog_create() is called inside ppp_lock, which
eventually calls vmalloc() and hits BUG_ON() in vmalloc.c. This patch
works around the problem by moving the allocation outside the lock.
The bug was revealed by the recent change in net/core/filter.c, as it
allocates via vmalloc() instead of kmalloc() now.
Reported-and-tested-by: Stefan Seyfried <stefan.seyfried@googlemail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
drivers/net/ppp/ppp_generic.c | 40 ++++++++++++++++++++--------------------
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index 68c3a3f4e0ab..794a47329368 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -755,23 +755,23 @@ static long ppp_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
err = get_filter(argp, &code);
if (err >= 0) {
+ struct bpf_prog *pass_filter = NULL;
struct sock_fprog_kern fprog = {
.len = err,
.filter = code,
};
- ppp_lock(ppp);
- if (ppp->pass_filter) {
- bpf_prog_destroy(ppp->pass_filter);
- ppp->pass_filter = NULL;
+ err = 0;
+ if (fprog.filter)
+ err = bpf_prog_create(&pass_filter, &fprog);
+ if (!err) {
+ ppp_lock(ppp);
+ if (ppp->pass_filter)
+ bpf_prog_destroy(ppp->pass_filter);
+ ppp->pass_filter = pass_filter;
+ ppp_unlock(ppp);
}
- if (fprog.filter != NULL)
- err = bpf_prog_create(&ppp->pass_filter,
- &fprog);
- else
- err = 0;
kfree(code);
- ppp_unlock(ppp);
}
break;
}
@@ -781,23 +781,23 @@ static long ppp_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
err = get_filter(argp, &code);
if (err >= 0) {
+ struct bpf_prog *active_filter = NULL;
struct sock_fprog_kern fprog = {
.len = err,
.filter = code,
};
- ppp_lock(ppp);
- if (ppp->active_filter) {
- bpf_prog_destroy(ppp->active_filter);
- ppp->active_filter = NULL;
+ err = 0;
+ if (fprog.filter)
+ err = bpf_prog_create(&active_filter, &fprog);
+ if (!err) {
+ ppp_lock(ppp);
+ if (ppp->active_filter)
+ bpf_prog_destroy(ppp->active_filter);
+ ppp->active_filter = active_filter;
+ ppp_unlock(ppp);
}
- if (fprog.filter != NULL)
- err = bpf_prog_create(&ppp->active_filter,
- &fprog);
- else
- err = 0;
kfree(code);
- ppp_unlock(ppp);
}
break;
}
--
2.1.3
^ permalink raw reply related
* [PATCH] stmmac: split to core library and probe drivers
From: Andy Shevchenko @ 2014-11-10 10:38 UTC (permalink / raw)
To: Giuseppe Cavallaro, netdev, Kweh Hock Leong, David S . Miller,
Vince Bridgers
Cc: Andy Shevchenko
Instead of registering the platform and PCI drivers in one module let's move
necessary bits to where it belongs. During this procedure we convert the module
registration part to use module_*_driver() macros which makes code simplier.
>From now on the driver consists three parts: core library, PCI, and platform
drivers.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 4 +-
drivers/net/ethernet/stmicro/stmmac/Makefile | 15 +++---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 61 ----------------------
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 36 ++-----------
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 +-
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 13 ++---
6 files changed, 25 insertions(+), 108 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 33b85ba..7d3af19 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -14,7 +14,7 @@ config STMMAC_ETH
if STMMAC_ETH
config STMMAC_PLATFORM
- bool "STMMAC Platform bus support"
+ tristate "STMMAC Platform bus support"
depends on STMMAC_ETH
default y
---help---
@@ -27,7 +27,7 @@ config STMMAC_PLATFORM
If unsure, say N.
config STMMAC_PCI
- bool "STMMAC PCI bus support"
+ tristate "STMMAC PCI bus support"
depends on STMMAC_ETH && PCI
---help---
This is to select the Synopsys DWMAC available on PCI devices,
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 034da70..ac4d562 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -1,9 +1,12 @@
obj-$(CONFIG_STMMAC_ETH) += stmmac.o
-stmmac-$(CONFIG_STMMAC_PCI) += stmmac_pci.o
-stmmac-$(CONFIG_STMMAC_PLATFORM) += stmmac_platform.o dwmac-meson.o \
- dwmac-sunxi.o dwmac-sti.o \
- dwmac-socfpga.o
stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o ring_mode.o \
- chain_mode.o dwmac_lib.o dwmac1000_core.o dwmac1000_dma.o \
- dwmac100_core.o dwmac100_dma.o enh_desc.o norm_desc.o \
+ chain_mode.o dwmac_lib.o dwmac1000_core.o dwmac1000_dma.o \
+ dwmac100_core.o dwmac100_dma.o enh_desc.o norm_desc.o \
mmc_core.o stmmac_hwtstamp.o stmmac_ptp.o $(stmmac-y)
+
+obj-$(CONFIG_STMMAC_PLATFORM) += stmmac-platform.o
+stmmac-platform-objs:= stmmac_platform.o dwmac-meson.o dwmac-sunxi.o \
+ dwmac-sti.o dwmac-socfpga.o
+
+obj-$(CONFIG_STMMAC_PCI) += stmmac-pci.o
+stmmac-pci-objs:= stmmac_pci.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index bd75ee8..c0a3919 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -134,65 +134,4 @@ struct stmmac_priv *stmmac_dvr_probe(struct device *device,
void stmmac_disable_eee_mode(struct stmmac_priv *priv);
bool stmmac_eee_init(struct stmmac_priv *priv);
-#ifdef CONFIG_STMMAC_PLATFORM
-extern struct platform_driver stmmac_pltfr_driver;
-
-static inline int stmmac_register_platform(void)
-{
- int err;
-
- err = platform_driver_register(&stmmac_pltfr_driver);
- if (err)
- pr_err("stmmac: failed to register the platform driver\n");
-
- return err;
-}
-
-static inline void stmmac_unregister_platform(void)
-{
- platform_driver_unregister(&stmmac_pltfr_driver);
-}
-#else
-static inline int stmmac_register_platform(void)
-{
- pr_debug("stmmac: do not register the platf driver\n");
-
- return 0;
-}
-
-static inline void stmmac_unregister_platform(void)
-{
-}
-#endif /* CONFIG_STMMAC_PLATFORM */
-
-#ifdef CONFIG_STMMAC_PCI
-extern struct pci_driver stmmac_pci_driver;
-static inline int stmmac_register_pci(void)
-{
- int err;
-
- err = pci_register_driver(&stmmac_pci_driver);
- if (err)
- pr_err("stmmac: failed to register the PCI driver\n");
-
- return err;
-}
-
-static inline void stmmac_unregister_pci(void)
-{
- pci_unregister_driver(&stmmac_pci_driver);
-}
-#else
-static inline int stmmac_register_pci(void)
-{
- pr_debug("stmmac: do not register the PCI driver\n");
-
- return 0;
-}
-
-static inline void stmmac_unregister_pci(void)
-{
-}
-#endif /* CONFIG_STMMAC_PCI */
-
#endif /* __STMMAC_H__ */
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 53db11b..0f1c146 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2885,6 +2885,7 @@ error_clk_get:
return ERR_PTR(ret);
}
+EXPORT_SYMBOL_GPL(stmmac_dvr_probe);
/**
* stmmac_dvr_remove
@@ -2914,8 +2915,8 @@ int stmmac_dvr_remove(struct net_device *ndev)
return 0;
}
+EXPORT_SYMBOL_GPL(stmmac_dvr_remove);
-#ifdef CONFIG_PM
int stmmac_suspend(struct net_device *ndev)
{
struct stmmac_priv *priv = netdev_priv(ndev);
@@ -2957,6 +2958,7 @@ int stmmac_suspend(struct net_device *ndev)
priv->oldduplex = -1;
return 0;
}
+EXPORT_SYMBOL_GPL(stmmac_suspend);
int stmmac_resume(struct net_device *ndev)
{
@@ -3003,37 +3005,7 @@ int stmmac_resume(struct net_device *ndev)
return 0;
}
-#endif /* CONFIG_PM */
-
-/* Driver can be configured w/ and w/ both PCI and Platf drivers
- * depending on the configuration selected.
- */
-static int __init stmmac_init(void)
-{
- int ret;
-
- ret = stmmac_register_platform();
- if (ret)
- goto err;
- ret = stmmac_register_pci();
- if (ret)
- goto err_pci;
- return 0;
-err_pci:
- stmmac_unregister_platform();
-err:
- pr_err("stmmac: driver registration failed\n");
- return ret;
-}
-
-static void __exit stmmac_exit(void)
-{
- stmmac_unregister_platform();
- stmmac_unregister_pci();
-}
-
-module_init(stmmac_init);
-module_exit(stmmac_exit);
+EXPORT_SYMBOL_GPL(stmmac_resume);
#ifndef MODULE
static int __init stmmac_cmdline_opt(char *str)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 5084699..77a6d68 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -158,7 +158,7 @@ static const struct pci_device_id stmmac_id_table[] = {
MODULE_DEVICE_TABLE(pci, stmmac_id_table);
-struct pci_driver stmmac_pci_driver = {
+static struct pci_driver stmmac_pci_driver = {
.name = STMMAC_RESOURCE_NAME,
.id_table = stmmac_id_table,
.probe = stmmac_pci_probe,
@@ -168,6 +168,8 @@ struct pci_driver stmmac_pci_driver = {
},
};
+module_pci_driver(stmmac_pci_driver);
+
MODULE_DESCRIPTION("STMMAC 10/100/1000 Ethernet PCI driver");
MODULE_AUTHOR("Rayagond Kokatanur <rayagond.kokatanur@vayavyalabs.com>");
MODULE_AUTHOR("Giuseppe Cavallaro <peppe.cavallaro@st.com>");
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 9f18401..e22a960 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -362,7 +362,7 @@ static int stmmac_pltfr_remove(struct platform_device *pdev)
return ret;
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int stmmac_pltfr_suspend(struct device *dev)
{
int ret;
@@ -388,13 +388,12 @@ static int stmmac_pltfr_resume(struct device *dev)
return stmmac_resume(ndev);
}
-
-#endif /* CONFIG_PM */
+#endif /* CONFIG_PM_SLEEP */
static SIMPLE_DEV_PM_OPS(stmmac_pltfr_pm_ops,
- stmmac_pltfr_suspend, stmmac_pltfr_resume);
+ stmmac_pltfr_suspend, stmmac_pltfr_resume);
-struct platform_driver stmmac_pltfr_driver = {
+static struct platform_driver stmmac_pltfr_driver = {
.probe = stmmac_pltfr_probe,
.remove = stmmac_pltfr_remove,
.driver = {
@@ -402,9 +401,11 @@ struct platform_driver stmmac_pltfr_driver = {
.owner = THIS_MODULE,
.pm = &stmmac_pltfr_pm_ops,
.of_match_table = of_match_ptr(stmmac_dt_ids),
- },
+ },
};
+module_platform_driver(stmmac_pltfr_driver);
+
MODULE_DESCRIPTION("STMMAC 10/100/1000 Ethernet PLATFORM driver");
MODULE_AUTHOR("Giuseppe Cavallaro <peppe.cavallaro@st.com>");
MODULE_LICENSE("GPL");
--
2.1.3
^ permalink raw reply related
* Re: [PATCH net-next 05/13] ethtool,net/mlx4_en: Add 100M, 20G, 56G speeds ethtool reporting support
From: Saeed Mahameed @ 2014-11-10 10:30 UTC (permalink / raw)
To: Ben Hutchings, Amir Vadai
Cc: David S. Miller, netdev, Yevgeny Petrilin, Or Gerlitz,
Saeed Mahameed
In-Reply-To: <1415227117.3398.31.camel@decadent.org.uk>
On 11/6/2014 12:38 AM, Ben Hutchings wrote:
> On Mon, 2014-10-27 at 11:37 +0200, Amir Vadai wrote:
>> From: Saeed Mahameed <saeedm@mellanox.com>
>>
>> Added 100M, 20G and 56G ethtool speed reporting support.
>> Update mlx4_en_test_speed self test with the new speeds.
>>
>> Defined new link speeds in include/uapi/linux/ethtool.h:
>> +#define SPEED_20000 20000
>> +#define SPEED_40000 40000
>> +#define SPEED_56000 56000
>>
>> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
>> Signed-off-by: Amir Vadai <amirv@mellanox.com>
> [...]
>> --- a/include/uapi/linux/ethtool.h
>> +++ b/include/uapi/linux/ethtool.h
>> @@ -1213,6 +1213,10 @@ enum ethtool_sfeatures_retval_bits {
>> #define SUPPORTED_40000baseCR4_Full (1 << 24)
>> #define SUPPORTED_40000baseSR4_Full (1 << 25)
>> #define SUPPORTED_40000baseLR4_Full (1 << 26)
>> +#define SUPPORTED_56000baseKR4_Full (1 << 27)
>> +#define SUPPORTED_56000baseCR4_Full (1 << 28)
>> +#define SUPPORTED_56000baseSR4_Full (1 << 29)
>> +#define SUPPORTED_56000baseLR4_Full (1 << 30)
>>
>> #define ADVERTISED_10baseT_Half (1 << 0)
>> #define ADVERTISED_10baseT_Full (1 << 1)
>> @@ -1241,6 +1245,10 @@ enum ethtool_sfeatures_retval_bits {
>> #define ADVERTISED_40000baseCR4_Full (1 << 24)
>> #define ADVERTISED_40000baseSR4_Full (1 << 25)
>> #define ADVERTISED_40000baseLR4_Full (1 << 26)
>> +#define ADVERTISED_56000baseKR4_Full (1 << 27)
>> +#define ADVERTISED_56000baseCR4_Full (1 << 28)
>> +#define ADVERTISED_56000baseSR4_Full (1 << 29)
>> +#define ADVERTISED_56000baseLR4_Full (1 << 30)
> Can these modes be auto-negotiated? If not then they don't need
> advertised/supported bits.
Hi Ben,
At least 56000baseKR4_Full and 56000baseCR4_Full can be negotiated for sure,
regarding SR and LR i will check with arch team.
>> /* The following are all involved in forcing a particular link
>> * mode for the device for setting things. When getting the
>> @@ -1248,12 +1256,16 @@ enum ethtool_sfeatures_retval_bits {
>> * it was forced up into this mode or autonegotiated.
>> */
>>
>> -/* The forced speed, 10Mb, 100Mb, gigabit, 2.5Gb, 10GbE. */
>> +/* The forced speed, 10Mb, 100Mb, gigabit, [2.5|10|20|40|56]GbE. */
>> #define SPEED_10 10
>> #define SPEED_100 100
>> #define SPEED_1000 1000
>> #define SPEED_2500 2500
>> #define SPEED_10000 10000
>> +#define SPEED_20000 20000
>> +#define SPEED_40000 40000
>> +#define SPEED_56000 56000
> We shouldn't add new SPEED macros. The speed is just a number of Mbit/s
> and we don't need to enumerate the possible values.
It is a little bit confusing that some speeds still use the defines
above, and new speeds should be hardcoded.
Why those speeds still there? is it some kind of work that need to be
done (i.e remove all of those defines) or are they needed in other
situations.
I thought it is nice that well-known speeds are organized in such MACROs
and this will prevent drivers from using magic numbers in their code.
Thanks for your time,
-Saeed.
>
> Ben.
>
>> #define SPEED_UNKNOWN -1
>>
>> /* Duplex, half or full. */
^ permalink raw reply
* Re: BUG ? - natsemi: Allow users to disable workaround for DspCfg reset
From: Mark Brown @ 2014-11-10 10:20 UTC (permalink / raw)
To: devzero; +Cc: netdev, Jeff Garzik
In-Reply-To: <trinity-83a3e1d0-0840-4d1e-98c1-e9e968c4af05-1415562288729@3capp-webde-bs47>
[-- Attachment #1: Type: text/plain, Size: 210 bytes --]
On Sun, Nov 09, 2014 at 08:44:48PM +0100, devzero@web.de wrote:
> Hi,
>
> i wanted to get rid of some heavy natsemi driver dmesg spamming like
You've sent the same message twice in quick succession...
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: Michael S. Tsirkin @ 2014-11-10 10:14 UTC (permalink / raw)
To: Al Viro; +Cc: David Miller, herbert, netdev, linux-kernel, bcrl
In-Reply-To: <20141109211908.GF7996@ZenIV.linux.org.uk>
On Sun, Nov 09, 2014 at 09:19:08PM +0000, Al Viro wrote:
> [Michael Cc'd]
>
> On Fri, Nov 07, 2014 at 11:42:53PM +0000, Al Viro wrote:
>
> > I'll finish RTFS drivers/vhost and if it turns out to be OK I'll post the
> > series moving those checks to the moment of copying iovec from userland,
> > so that kernel-side we could always rely on ->msg_iov elements having been
> > verified.
>
> Two questions:
> 1) does sparc64 access_ok() need to differ for 32bit and 64bit tasks?
> AFAICS, x86 and ppc just check that address is OK for 64bit process -
> if a 32bit process passes the kernel an address that would be valid
> for 64bit process, but not for 32bit one, we just get a pagefault in
> __copy_from_user() and friends. No kernel objects are going to have
> a virtual address in that range, so access_ok() doesn't bother preventing
> such access attempts there...
>
> 2) shouldn't vhost_dev_cleanup() stop the worker thread before doing anything
> else?
> AFAICS, we do parts of vhost_dev teardown while the thread is
> still running; granted, we keep dev->mm pinned down until after it stops
> (or we would be _really_ screwed), but is it safe to do all those fput()s, etc.
> while it's still running? Michael?
Before invoking vhost_dev_cleanup,
the caller for vhost-net (vhost_net_release) sets private data to NULL
(using vhost_net_stop_vq) which guarantees thread will do nothing at all.
vhost scsi does it in vhost_scsi_clear_endpoint.
--
MST
^ permalink raw reply
* Re: [patch net-next v2 06/10] bridge: introduce fdb offloading via switchdev
From: Scott Feldman @ 2014-11-10 9:30 UTC (permalink / raw)
To: Jiri Pirko
Cc: Jamal Hadi Salim, Netdev, David S. Miller, nhorman,
Andy Gospodarek, Thomas Graf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, Kirsher, Jeffrey T, vyasevic, Cong Wang,
Fastabend, John R, Eric Dumazet, Florian Fainelli, Roopa Prabhu,
John Linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, Alexei Starovoitov
In-Reply-To: <20141110081552.GD1850@nanopsycho.orion>
On Sun, Nov 9, 2014 at 10:15 PM, Jiri Pirko <jiri@resnulli.us> wrote:
> Mon, Nov 10, 2014 at 04:47:48AM CET, jhs@mojatatu.com wrote:
>>On 11/09/14 05:51, Jiri Pirko wrote:
>>>From: Scott Feldman <sfeldma@gmail.com>
>>>
>>>Add two new ndos: ndo_sw_port_fdb_add/del to offload static bridge
>>>fdb entries. Static bridge FDB entries are installed, for example,
>>>using iproute2 bridge cmd:
>>>
>>> bridge fdb add ADDR dev DEV master vlan VID
>>>
>>>This would install ADDR into the bridge's FDB for port DEV on vlan VID. The
>>>switch driver implements two ndo_swdev ops to add/delete FDB entries in the
>>>switch device:
>>>
>>> int ndo_sw_port_fdb_add(struct net_device *dev,
>>> const unsigned char *addr,
>>> u16 vid);
>>>
>>> int ndo_sw_port_fdb_del(struct net_device *dev,
>>> const unsigned char *addr,
>>> u16 vid);
>>>
>>>The driver returns 0 on success, negative error code on failure.
>>>
>>>Note: the switch driver would not implement ndo_fdb_add/del/dump on a port
>>>netdev as these are intended for devices maintaining their own FDB. In our
>>>case, we want the Linux bridge to own the FBD.
>>>
>>>Note: by default, the bridge does not filter on VLAN and only bridges untagged
>>>traffic. To enable VLAN support, turn on VLAN filtering:
>>>
>>> echo 1 >/sys/class/net/<bridge>/bridge/vlan_filtering
>>>
>>
>>Sorry - why is the current fdb_add/del insufficient? It needs a vlanid
>>and the master/self flags should indicate intent to add to h/w vs s/w.
>
> Jamal, I believe we discussed this already. The thing is that current
> fdb_add/del does not need vlanid and master/self flags, because it
> already has that (struct nlattr *tb[]). Here is the whole list of
> parameters to these functions:
> NDA_DST,
> NDA_LLADDR,
> NDA_CACHEINFO,
> NDA_PROBES,
> NDA_VLAN,
> NDA_PORT,
> NDA_VNI,
> NDA_IFINDEX,
> NDA_MASTER,
>
> There are few problems in re-using this. It is netlink based so for calling
> it from bridge code, we would have to construct netlink message. But
> that could be probably changed.
> As you can see from the list of parameters, this is no longer about fdb (addr,
> vlanid) but this has been extended to something else. See vxlan code for
> what this is used for. I believe that fdb_add/del should be renamed to
> something else, perhaps l2neigh_add/del or something like that.
> The other problem is that fdb_add/del is currently used by various
> drivers for different purpose (adding macs to unicast list).
>
> Scott, you may probably want to add something to this.
You hit the main point: having to synthesize netlink msg in the bridge
driver and pass it down to port driver using .ndo_fdb_add/del is
awkward. And then, if the port driver implements .ndo_fdb_add/del
(and dump), then user could by-pass bridge and install fdbs directly
on port, as if the port maintains its own fdb. We want the bridge fdb
to be the single fdb, and static fdbs installed by user on bridge to
be pushed down to sw port driver to be installed in hw.
>>
>>cheers,
>>jamal
>>
^ permalink raw reply
* Re: [patch net-next v2 10/10] rocker: implement L2 bridge offloading
From: Nicolas Dichtel @ 2014-11-10 9:10 UTC (permalink / raw)
To: Jiri Pirko, Jamal Hadi Salim
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, sfeldma, f.fainelli,
roopa, linville, jasowang, ebiederm, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl
In-Reply-To: <20141110081826.GE1850@nanopsycho.orion>
Le 10/11/2014 09:18, Jiri Pirko a écrit :
> Mon, Nov 10, 2014 at 04:53:07AM CET, jhs@mojatatu.com wrote:
>> On 11/09/14 05:51, Jiri Pirko wrote:
>>> From: Scott Feldman <sfeldma@gmail.com>
>>>
>>> Add L2 bridge offloading support to rocker driver. Here, the Linux bridge
>>> driver is used to collect swdev ports into a tagged (or untagged) VLAN
>>> bridge. The swdev will offload from the bridge driver the following L2
>>> bridging functions:
>>>
>>> - Learning of neighbor MAC addresses on VLAN X Learned mac/vlan is
>>> installed in bridge FDB. (And removed when device unlearns mac/vlan).
>>> Learning must be turned off on each bridge port to disable the feature in
>>> the bridge driver.
>>>
>>
>> I have quiet a few use cases where the above is a no-no. I dont want
>> learning of any sort (we have a knob for that in the bridge).
>
> I would love to see your code. Please do share.
>
>> And i dont want learning in hardware to be reflected in software.
>> Basically this is a policy decision. Introduce a knob to choose whether
>> hardware learnt addresses should be reflected in software.
>
> This can be easily done as a bridge option I believe. If you are ok with
> that, I will add a patch (either in re-post or as a follow-up)
An option will be nice.
Regards,
Nicolas
^ permalink raw reply
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: Al Viro @ 2014-11-10 9:09 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev, linux-kernel, bcrl, mst
In-Reply-To: <20141110.023000.1275181784917275552.davem@davemloft.net>
On Mon, Nov 10, 2014 at 02:30:00AM -0500, David Miller wrote:
> From: Al Viro <viro@ZenIV.linux.org.uk>
> Date: Mon, 10 Nov 2014 06:58:17 +0000
>
> > On Mon, Nov 10, 2014 at 12:20:20AM -0500, David Miller wrote:
> >> From: Al Viro <viro@ZenIV.linux.org.uk>
> >> Date: Sun, 9 Nov 2014 21:19:08 +0000
> >>
> >> > 1) does sparc64 access_ok() need to differ for 32bit and 64bit tasks?
> >>
> >> sparc64 will just fault no matter what kind of task it is.
> >>
> >> It is impossible for a user task to generate a reference to
> >> a kernel virtual address, as kernel and user accesses each
> >> go via a separate address space identifier.
> >
> > Sure, but why do we have access_ok() there at all? I.e. why not just have
> > it constant 1?
>
> Since access_ok() is in fact constant 1 on sparc64, where we use it,
> does it really matter?
*blink*
My apologies - I've got confused by the maze of twisty includes, all alike.
Right you are; in biarch case it *doesn't* depend on 32bit vs. 64bit.
STACK_TOP-using one is sparc32 variant where we obviously don't have
biarch at all.
Anyway, the series switching to {compat_,}rw_copy_check_uvector() and
getting rid of duplicate checks is in vfs.git#iov_iter-net. Warning:
it's almost completely untested. It survives boot, ssh into it and
runltp -f syscalls (no regressions), but that's about it. BTW, what's
the usual regression suite used for net/* stuff?
3 commits in there, on top of net-next#master; head should be at 555126.
There's a bunch of fairly obvious followups becoming possible after that,
but let's keep those separate...
^ permalink raw reply
* Re: [PATCH] brcmfmac: unlink URB when request timed out
From: Oliver Neukum @ 2014-11-10 9:08 UTC (permalink / raw)
To: Mathy Vanhoef
Cc: brudley, arend, frankyl, meuleman, linville, pieterpg,
linux-wireless, brcm80211-dev-list, netdev, linux-kernel
In-Reply-To: <545FAE05.2030701@gmail.com>
On Sun, 2014-11-09 at 13:10 -0500, Mathy Vanhoef wrote:
> From: Mathy Vanhoef <vanhoefm@gmail.com>
>
> Unlink the submitted URB in brcmf_usb_dl_cmd if the request timed out. This
> assures the URB is never submitted twice, preventing a driver crash.
Hi,
I am afrad this patch is no good. The diagnosis is good,
but the fix introduces serious problems.
> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
> index 5265aa7..1bc7858 100644
> --- a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
> +++ b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
> @@ -738,10 +738,12 @@ static int brcmf_usb_dl_cmd(struct brcmf_usbdev_info *devinfo, u8 cmd,
> goto finalize;
> }
>
> - if (!brcmf_usb_ioctl_resp_wait(devinfo))
> + if (!brcmf_usb_ioctl_resp_wait(devinfo)) {
> + usb_unlink_urb(devinfo->ctl_urb);
This is the asynchronous unlink. You have no guarantee it is finished
after this point.
> ret = -ETIMEDOUT;
> - else
> + } else {
> memcpy(buffer, tmpbuf, buflen);
> + }
>
> finalize:
> kfree(tmpbuf);
Which means that you are freeing memory that may still be used by DMA
at this time.
In addition you have no guarantee that the unlink is indeed finished
by the time the URB is reused.
If you wish to take this approach you better forget about this URB
and allocate a new one and free the buffer from the callback.
Regards
Oliver
--
Oliver Neukum <oneukum@suse.de>
^ permalink raw reply
* Re: [PATCH v4 6/8] net: can: c_can: Disable pins when CAN interface is down
From: Roger Quadros @ 2014-11-10 9:00 UTC (permalink / raw)
To: Marc Kleine-Budde, wg
Cc: wsa, tony, tglx, mugunthanvnm, george.cherian, balbi, nsekhar, nm,
sergei.shtylyov, linux-omap, linux-can, netdev
In-Reply-To: <545CDD30.2070508@pengutronix.de>
On 11/07/2014 04:54 PM, Marc Kleine-Budde wrote:
> On 11/07/2014 03:49 PM, Roger Quadros wrote:
>> DRA7 CAN IP suffers from a problem which causes it to be prevented
>> from fully turning OFF (i.e. stuck in transition) if the module was
>> disabled while there was traffic on the CAN_RX line.
>>
>> To work around this issue we select the SLEEP pin state by default
>> on probe and use the DEFAULT pin state on CAN up and back to the
>> SLEEP pin state on CAN down.
>>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>> drivers/net/can/c_can/c_can.c | 20 ++++++++++++++++++++
>> drivers/net/can/c_can/c_can.h | 1 +
>> drivers/net/can/c_can/c_can_platform.c | 20 ++++++++++++++++++++
>> 3 files changed, 41 insertions(+)
>>
>> diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
>> index 8e78bb4..4dfc3ce 100644
>> --- a/drivers/net/can/c_can/c_can.c
>> +++ b/drivers/net/can/c_can/c_can.c
>> @@ -35,6 +35,7 @@
>> #include <linux/list.h>
>> #include <linux/io.h>
>> #include <linux/pm_runtime.h>
>> +#include <linux/pinctrl/consumer.h>
>>
>> #include <linux/can.h>
>> #include <linux/can/dev.h>
>> @@ -603,6 +604,15 @@ static int c_can_start(struct net_device *dev)
>>
>> priv->can.state = CAN_STATE_ERROR_ACTIVE;
>>
>> + /* activate pins */
>> + if (!IS_ERR(priv->pinctrl)) {
>> + struct pinctrl_state *s;
>> +
>> + s = pinctrl_lookup_state(priv->pinctrl, PINCTRL_STATE_DEFAULT);
>> + if (!IS_ERR(s))
>> + pinctrl_select_state(priv->pinctrl, s);
>> + }
>
> Please put this common code into a seperate function.
Oops, forgot this one in a hurry.
cheers,
-roger
^ permalink raw reply
* Re: [patch net-next v2 10/10] rocker: implement L2 bridge offloading
From: Scott Feldman @ 2014-11-10 8:46 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Jiri Pirko, Netdev, David S. Miller, nhorman, Andy Gospodarek,
Thomas Graf, dborkman, ogerlitz, jesse, pshelar, azhou, ben,
stephen, Kirsher, Jeffrey T, vyasevic, xiyou.wangcong,
Fastabend, John R, edumazet, Florian Fainelli, Roopa Prabhu,
John Linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.ho
In-Reply-To: <546036A3.3010404@mojatatu.com>
On Sun, Nov 9, 2014 at 5:53 PM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>
> On 11/09/14 05:51, Jiri Pirko wrote:
>>
>> From: Scott Feldman <sfeldma@gmail.com>
>>
>> Add L2 bridge offloading support to rocker driver. Here, the Linux bridge
>> driver is used to collect swdev ports into a tagged (or untagged) VLAN
>> bridge. The swdev will offload from the bridge driver the following L2
>> bridging functions:
>>
>> - Learning of neighbor MAC addresses on VLAN X Learned mac/vlan is
>> installed in bridge FDB. (And removed when device unlearns mac/vlan).
>> Learning must be turned off on each bridge port to disable the feature in
>> the bridge driver.
>>
>
> I have quiet a few use cases where the above is a no-no. I dont want
> learning of any sort (we have a knob for that in the bridge).
> And i dont want learning in hardware to be reflected in software.
> Basically this is a policy decision. Introduce a knob to choose whether
> hardware learnt addresses should be reflected in software.
IFLA_BRPORT_LEARNING is u8 attr and we're only using lower bit to turn
learning on/off. Maybe we can use another bit to indicate learning to
be done in sw or hw. I don't think adding another bit would break
existing iproute2.
LEARNING_ENABLED (1 << 0)
LEARNING_HW (1 << 1)
Would this work?
>
>
> Have to run, but will comment when i get the time.
>
> cheers,
> jamal
>
^ 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