Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 9月, 2016 3 次提交
  3. 19 9月, 2016 25 次提交
  5. 17 9月, 2016 9 次提交
    • C
      mwifiex: fix null pointer deference when adapter is null · 80ba4f1d
      由 Colin Ian King 提交于 
      If adapter is null the error exit path in mwifiex_shutdown_sw is
to down the semaphore sem and print some debug via mwifiex_dbg.
However, passing a NULL adapter to mwifiex_dbg causes a null
pointer deference when accessing adapter->dev.  This fix checks
for a null adapter at the start of the function and to exit
without the need to up the semaphore and we also skip the debug
to avoid the null pointer dereference.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      80ba4f1d
    • B
      mwifiex: fix error handling in mwifiex_create_custom_regdomain · 92ca4f92
      由 Bob Copeland 提交于 
      smatch reports:

sta_cmdresp.c:1053 mwifiex_create_custom_regdomain() warn: possible memory leak of 'regd'

Indeed, mwifiex_create_custom_regdomain() returns NULL in the
case that channel is missing in the TLV without freeing regd.

Moreover, some other error paths in this function return ERR_PTR
values which are assigned without checking to the regd field in
the mwifiex_adapter struct.  The latter is only null-checked where
used.

Fix by freeing regd in the error path, and only update
priv->adapter->regd if the returned pointer is valid.

Cc: Amitkumar Karwar <akarwar@marvell.com>
Cc: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      92ca4f92
    • J
      rtl8xxxu: Implement 8192e specific power down sequence · f1785fbf
      由 Jes Sorensen 提交于 
      This powers down the 8192e correctly, or at least to the point where
the firmware will load again, when reloading the driver module.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      f1785fbf
    • J
      dwc_eth_qos: constify net_device_ops structures · 37307504
      由 Julia Lawall 提交于 
      Check for net_device_ops structures that are only stored in the netdev_ops
field of a net_device structure.  This field is declared const, so
net_device_ops structures that have this property can be declared as const
also.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct net_device_ops i@p = { ... };

@ok@
identifier r.i;
struct net_device e;
position p;
@@
e.netdev_ops = &i@p;

@bad@
position p != {r.p,ok.p};
identifier r.i;
struct net_device_ops e;
@@
e@i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
 struct net_device_ops i = { ... };
// </smpl>

The result of size on this file before the change is:
   text	      data     bss     dec         hex	  filename
  21623       1316      40   22979        59c3
   drivers/net/ethernet/synopsys/dwc_eth_qos.o

and after the change it is:
   text	     data        bss	    dec	    hex	filename
  22199       724         40      22963    59b3
   drivers/net/ethernet/synopsys/dwc_eth_qos.o
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      37307504
    • J
      hisilicon: constify net_device_ops structures · 66f58ec4
      由 Julia Lawall 提交于 
      Check for net_device_ops structures that are only stored in the netdev_ops
field of a net_device structure.  This field is declared const, so
net_device_ops structures that have this property can be declared as const
also.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct net_device_ops i@p = { ... };

@ok@
identifier r.i;
struct net_device e;
position p;
@@
e.netdev_ops = &i@p;

@bad@
position p != {r.p,ok.p};
identifier r.i;
struct net_device_ops e;
@@
e@i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
 struct net_device_ops i = { ... };
// </smpl>

The result of size on this file before the change is:

   text	      data     bss     dec         hex	  filename
   7995	       848       8    8851        2293
   drivers/net/ethernet/hisilicon/hip04_eth.o

and after the change it is:

   text	     data        bss	    dec	    hex	filename
   8571	      256          8       8835    2283
   drivers/net/ethernet/hisilicon/hip04_eth.o
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      66f58ec4
    • D
      net: vrf: Remove RT_FL_TOS · e1fb9d03
      由 David Ahern 提交于 
      No longer used after d66f6c0a ("net: ipv4: Remove l3mdev_get_saddr")
Signed-off-by: NDavid Ahern <dsa@cumulusnetworks.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e1fb9d03
    • T
      net/mlx5e: Implement RX mapped page cache for page recycle · 4415a031
      由 Tariq Toukan 提交于 
      Instead of reallocating and mapping pages for RX data-path,
recycle already used pages in a per ring cache.

Performance tests:
The following results were measured on a freshly booted system,
giving optimal baseline performance, as high-order pages are yet to
be fragmented and depleted.

We ran pktgen single-stream benchmarks, with iptables-raw-drop:

Single stride, 64 bytes:
* 4,739,057 - baseline
* 4,749,550 - order0 no cache
* 4,786,899 - order0 with cache
1% gain

Larger packets, no page cross, 1024 bytes:
* 3,982,361 - baseline
* 3,845,682 - order0 no cache
* 4,127,852 - order0 with cache
3.7% gain

Larger packets, every 3rd packet crosses a page, 1500 bytes:
* 3,731,189 - baseline
* 3,579,414 - order0 no cache
* 3,931,708 - order0 with cache
5.4% gain
Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4415a031
    • T
      net/mlx5e: Introduce API for RX mapped pages · a5a0c590
      由 Tariq Toukan 提交于 
      Manage the allocation and deallocation of mapped RX pages only
through dedicated API functions.
Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a5a0c590
    • T
      net/mlx5e: Single flow order-0 pages for Striding RQ · 7e426671
      由 Tariq Toukan 提交于 
      To improve the memory consumption scheme, we omit the flow that
demands and splits high-order pages in Striding RQ, and stay
with a single Striding RQ flow that uses order-0 pages.

Moving to fragmented memory allows the use of larger MPWQEs,
which reduces the number of UMR posts and filler CQEs.

Moving to a single flow allows several optimizations that improve
performance, especially in production servers where we would
anyway fallback to order-0 allocations:
- inline functions that were called via function pointers.
- improve the UMR post process.

This patch alone is expected to give a slight performance reduction.
However, the new memory scheme gives the possibility to use a page-cache
of a fair size, that doesn't inflate the memory footprint, which will
dramatically fix the reduction and even give a performance gain.

Performance tests:
The following results were measured on a freshly booted system,
giving optimal baseline performance, as high-order pages are yet to
be fragmented and depleted.

We ran pktgen single-stream benchmarks, with iptables-raw-drop:

Single stride, 64 bytes:
* 4,739,057 - baseline
* 4,749,550 - this patch
no reduction

Larger packets, no page cross, 1024 bytes:
* 3,982,361 - baseline
* 3,845,682 - this patch
3.5% reduction

Larger packets, every 3rd packet crosses a page, 1500 bytes:
* 3,731,189 - baseline
* 3,579,414 - this patch
4% reduction

Fixes: 461017cb ("net/mlx5e: Support RX multi-packet WQE (Striding RQ)")
Fixes: bc77b240 ("net/mlx5e: Add fragmented memory support for RX multi packet WQE")
Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7e426671
  7. 16 9月, 2016 3 次提交