Re: [PATCH v2 03/11] tty: kbd: reduce stack size with KASAN

2017-06-14 Thread Greg Kroah-Hartman
On Thu, Jun 15, 2017 at 06:52:21AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jun 14, 2017 at 11:15:38PM +0200, Arnd Bergmann wrote:
> > As reported by kernelci, some functions in the VT code use significant
> > amounts of kernel stack when local variables get inlined into the caller
> > multiple times:
> > 
> > drivers/tty/vt/keyboard.c: In function 'kbd_keycode':
> > drivers/tty/vt/keyboard.c:1452:1: error: the frame size of 2240 bytes is 
> > larger than 2048 bytes [-Werror=frame-larger-than=]
> > 
> > Annotating those functions as noinline_if_stackbloat prevents the inlining
> > and reduces the overall stack usage in this driver.
> > 
> > Signed-off-by: Arnd Bergmann 
> > ---
> >  drivers/tty/vt/keyboard.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> > index f4166263bb3a..c0d111444a0e 100644
> > --- a/drivers/tty/vt/keyboard.c
> > +++ b/drivers/tty/vt/keyboard.c
> > @@ -301,13 +301,13 @@ int kbd_rate(struct kbd_repeat *rpt)
> >  /*
> >   * Helper Functions.
> >   */
> > -static void put_queue(struct vc_data *vc, int ch)
> > +static noinline_if_stackbloat void put_queue(struct vc_data *vc, int ch)
> >  {
> > tty_insert_flip_char(>port, ch, 0);
> > tty_schedule_flip(>port);
> >  }
> 
> Ugh, really?  We have to start telling gcc not to be stupid here?
> That's not going to be easy, and will just entail us doing this all over
> the place, right?
> 
> The code isn't asking to be inlined, so why is gcc allowing it to be
> done that way?  Doesn't that imply gcc is the problem here?

Wait, you are now, in this patch, _asking_ for it to be inlined.  How is
that solving anything?

greg k-h


Re: [PATCH v2 03/11] tty: kbd: reduce stack size with KASAN

2017-06-14 Thread Greg Kroah-Hartman
On Wed, Jun 14, 2017 at 11:15:38PM +0200, Arnd Bergmann wrote:
> As reported by kernelci, some functions in the VT code use significant
> amounts of kernel stack when local variables get inlined into the caller
> multiple times:
> 
> drivers/tty/vt/keyboard.c: In function 'kbd_keycode':
> drivers/tty/vt/keyboard.c:1452:1: error: the frame size of 2240 bytes is 
> larger than 2048 bytes [-Werror=frame-larger-than=]
> 
> Annotating those functions as noinline_if_stackbloat prevents the inlining
> and reduces the overall stack usage in this driver.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/tty/vt/keyboard.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> index f4166263bb3a..c0d111444a0e 100644
> --- a/drivers/tty/vt/keyboard.c
> +++ b/drivers/tty/vt/keyboard.c
> @@ -301,13 +301,13 @@ int kbd_rate(struct kbd_repeat *rpt)
>  /*
>   * Helper Functions.
>   */
> -static void put_queue(struct vc_data *vc, int ch)
> +static noinline_if_stackbloat void put_queue(struct vc_data *vc, int ch)
>  {
>   tty_insert_flip_char(>port, ch, 0);
>   tty_schedule_flip(>port);
>  }

Ugh, really?  We have to start telling gcc not to be stupid here?
That's not going to be easy, and will just entail us doing this all over
the place, right?

The code isn't asking to be inlined, so why is gcc allowing it to be
done that way?  Doesn't that imply gcc is the problem here?

thanks,

greg k-h


[PATCH 4/5 net-next v2] ibmvnic: Remove VNIC_CLOSING check from pending_scrq

2017-06-14 Thread Thomas Falcon
Fix a kernel panic resulting from data access of a NULL
pointer during device close. The pending_scrq routine is
meant to determine whether there is a valid sub-CRQ message
awaiting processing. When the device is closing, however,
there is a possibility that NULL messages can be processed
because pending_scrq will always return 1 even if there
no valid message in the queue.

It's not clear what this closing state check was originally
meant to accomplish, so just remove it.  

Signed-off-by: Thomas Falcon 
---
 drivers/net/ethernet/ibm/ibmvnic.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index 167b47b..5378b21 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -2268,8 +2268,7 @@ static int pending_scrq(struct ibmvnic_adapter *adapter,
 {
union sub_crq *entry = >msgs[scrq->cur];
 
-   if (entry->generic.first & IBMVNIC_CRQ_CMD_RSP ||
-   adapter->state == VNIC_CLOSING)
+   if (entry->generic.first & IBMVNIC_CRQ_CMD_RSP)
return 1;
else
return 0;
-- 
1.8.5.6



[PATCH 3/5 net-next v2] ibmvnic: Sanitize entire SCRQ buffer on reset

2017-06-14 Thread Thomas Falcon
Fixup a typo so that the entire SCRQ buffer is cleaned.

Signed-off-by: Thomas Falcon 
---
 drivers/net/ethernet/ibm/ibmvnic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index d5fbf45..167b47b 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1745,7 +1745,7 @@ static int reset_one_sub_crq_queue(struct ibmvnic_adapter 
*adapter,
scrq->irq = 0;
}
 
-   memset(scrq->msgs, 0, 2 * PAGE_SIZE);
+   memset(scrq->msgs, 0, 4 * PAGE_SIZE);
scrq->cur = 0;
 
rc = h_reg_sub_crq(adapter->vdev->unit_address, scrq->msg_token,
-- 
1.8.5.6



[PATCH 5/5 net-next v2] ibmvnic: Exit polling routine correctly during adapter reset

2017-06-14 Thread Thomas Falcon
This patch fixes a bug where, in the case of a device reset,
the polling routine will never complete, causing napi_disable
to sleep indefinitely when attempting to close the device. 

Signed-off-by: Thomas Falcon 
---
 drivers/net/ethernet/ibm/ibmvnic.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index 5378b21..ba4c79d 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1504,9 +1504,6 @@ static int ibmvnic_poll(struct napi_struct *napi, int 
budget)
int scrq_num = (int)(napi - adapter->napi);
int frames_processed = 0;
 
-   if (adapter->resetting)
-   return 0;
-
 restart_poll:
while (frames_processed < budget) {
struct sk_buff *skb;
@@ -1516,6 +1513,12 @@ static int ibmvnic_poll(struct napi_struct *napi, int 
budget)
u16 offset;
u8 flags = 0;
 
+   if (unlikely(adapter->resetting)) {
+   enable_scrq_irq(adapter, adapter->rx_scrq[scrq_num]);
+   napi_complete_done(napi, frames_processed);
+   return frames_processed;
+   }
+
if (!pending_scrq(adapter, adapter->rx_scrq[scrq_num]))
break;
next = ibmvnic_next_scrq(adapter, adapter->rx_scrq[scrq_num]);
-- 
1.8.5.6



[PATCH 2/5 net-next v2] ibmvnic: Ensure that TX queues are disabled in __ibmvnic_close

2017-06-14 Thread Thomas Falcon
Use netif_tx_disable to guarantee that TX queues are disabled 
when __ibmvnic_close is called by the device reset routine.

Signed-off-by: Thomas Falcon 
---
 drivers/net/ethernet/ibm/ibmvnic.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index 000cd15..d5fbf45 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -886,7 +886,13 @@ static int __ibmvnic_close(struct net_device *netdev)
int i;
 
adapter->state = VNIC_CLOSING;
-   netif_tx_stop_all_queues(netdev);
+
+   /* ensure that transmissions are stopped if called by do_reset */
+   if (adapter->resetting)
+   netif_tx_disable(netdev);
+   else
+   netif_tx_stop_all_queues(netdev);
+
ibmvnic_napi_disable(adapter);
 
if (adapter->tx_scrq) {
-- 
1.8.5.6



[PATCH 1/5 net-next v2] ibmvnic: Activate disabled RX buffer pools on reset

2017-06-14 Thread Thomas Falcon
RX buffer pools are disabled while awaiting a device
reset if firmware indicates that the resource is closed.

This patch fixes a bug where pools were not being 
subsequently enabled after the device reset, causing
the device to become inoperable.

Signed-off-by: Thomas Falcon 

---
 drivers/net/ethernet/ibm/ibmvnic.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index 7e585fd..000cd15 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -383,6 +383,7 @@ static int reset_rx_pools(struct ibmvnic_adapter *adapter)
atomic_set(_pool->available, 0);
rx_pool->next_alloc = 0;
rx_pool->next_free = 0;
+   rx_pool->active = 1;
}
 
return 0;
-- 
1.8.5.6



[PATCH 0/5 net-next v2] ibmvnic: LPM bug fixes

2017-06-14 Thread Thomas Falcon
This series of small patches is meant to resolve a number of
bugs, mostly occurring during an ibmvnic driver reset when
recovering from a logical partition migration (LPM).

The first patch ensures that RX buffer pools are properly
activated following an adapter reset by setting the proper
flag in the pool data structure.

The second patch uses netif_tx_disable to stop TX queues when
closing the device during a reset.

Third, fixup a typo that resulted in partial sanitization of
TX/RX descriptor queues following a device reset.

Fourth, remove an ambiguous conditional check that was resulting
in a kernel panic as null RX/TX completion descriptors were being
processed during napi polling while the device is closing.

Finally, fix a condition where the napi polling routine exits
before it has completed its work budget without notifying the
upper network layers. This omission could result in the
napi_disable function sleeping indefinitely under certain conditions.

v2: Attempt to provide a proper cover letter

Thomas Falcon (5):
  ibmvnic: Activate disabled RX buffer pools on reset
  ibmvnic: Ensure that TX queues are disabled in __ibmvnic_close
  ibmvnic: Sanitize entire SCRQ buffer on reset
  ibmvnic: Remove VNIC_CLOSING check from pending_scrq
  ibmvnic: Exit polling routine correctly during adapter reset

 drivers/net/ethernet/ibm/ibmvnic.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

-- 
1.8.3.1



[GIT] Networking

2017-06-14 Thread David Miller

1) The netlink attribute passed in to dev_set_alias() is not
   necessarily NULL terminated, don't use strlcpy() on it.
   From Alexander Potapenko.

2) Fix implementation of atomics in arm64 bpf JIT, from Daniel
   Borkmann.

3) Correct the release of netdevs and driver private data in
   certain circumstances.

4) Sanitize netlink message length properly in decnet, from
   Mateusz Jurczyk.

5) Don't leak kernel data in rtnl_fill_vfinfo() netlink blobs.
   From Yuval Mintz.

6) Hash secret is never initialized in ipv6 ILA translation code, from
   Arnd Bergmann.  I guess those clang warnings about unused inline
   functions are useful for something!

7) Fix endian selection in bpf_endian.h, from Daniel Borkmann.

8) Sanitize sockaddr length before dereferncing any fields in
   AF_UNIX and CAIF.  From Mateusz Jurczyk.

9) Fix timestamping for GMAC3 chips in stmmac driver, from Mario
   Molitor.

10) Do not leak netdev on dev_alloc_name() errors in mac80211, from
Johannes Berg.

11) Fix locking in sctp_for_each_endpoint(), from Xin Long.

12) Fix wrong memset size on 32-bit in snmp6, from Christian Perle.

13) Fix use after free in ip_mc_clear_src(), from WANG Cong.

14) Fix regressions caused by ICMP rate limiting changes in 4.11,
from Jesper Dangaard Brouer.

Please pull, thanks a lot!

The following changes since commit b29794ec95c6856b316c2295904208bf11ffddd9:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-06-06 
14:30:17 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to 640f93cc6ea7327588be3cc0849d1342aac0393a:

  i40e: Fix a sleep-in-atomic bug (2017-06-14 23:45:22 -0400)


Alexander Potapenko (1):
  net: don't call strlen on non-terminated string in dev_set_alias()

Andreas Pape (1):
  batman-adv: fix memory leak when dropping packet from other gateway

Antoine Tenart (1):
  net: mvpp2: do not bypass the mvpp22_port_mii_set function

Arnd Bergmann (1):
  ila_xlat: add missing hash secret initialization

Ashwanth Goli (1):
  net: rps: fix uninitialized symbol warning

Avraham Stern (1):
  mac80211: Fix incorrect condition when checking rx timestamp

Bjørn Mork (1):
  qmi_wwan: new Telewell and Sierra device IDs

Christian Lamparter (2):
  net: emac: fix reset timeout with AR8035 phy
  net: emac: fix and unify emac_mdio functions

Christian Perle (1):
  proc: snmp6: Use correct type in memset

Dan Carpenter (1):
  net/act_pedit: fix an error code

Daniel Borkmann (2):
  bpf, arm64: use separate register for state in stxr
  bpf, tests: fix endianness selection

David Ahern (2):
  net: ipv6: Release route when device is unregistering
  net: vrf: Make add_fib_rules per network namespace flag

David S. Miller (13):
  net: Fix inconsistent teardown and release of private netdev state.
  hsi: Fix build regression due to netdev destructor fix.
  Revert "decnet: dn_rtmsg: Improve input length sanitization in 
dnrmg_receive_user_skb"
  Merge branch 'netvsc-bug-fixes'
  net: Fix build regression in rtl8723bs staging driver.
  Merge tag 'linux-can-fixes-for-4.12-20170609' of 
git://git.kernel.org/.../mkl/linux-can
  Merge branch 'bnx2x-Fix-malicious-VFs-indication'
  Revert "net: fec: Add a fec_enet_clear_ethtool_stats() stub for 
CONFIG_M5272"
  Merge branch 'mvpp2-fixes'
  Merge branch 'ena-fixes'
  Merge tag 'mlx5-fixes-2017-06-11' of git://git.kernel.org/.../saeed/linux
  Merge tag 'mac80211-for-davem-2017-06-13' of 
git://git.kernel.org/.../jberg/mac80211
  Merge tag 'batadv-net-for-davem-20170613' of 
git://git.open-mesh.org/linux-merge

Dominik Heidler (1):
  l2tp: cast l2tp traffic counter to unsigned

Donald Sharp (1):
  net: ipmr: Fix some mroute forwarding issues in vrf's

Emmanuel Grumbach (2):
  mac80211: don't look at the PM bit of BAR frames
  mac80211: don't send SMPS action frame in AP mode when not needed

Fabio Estevam (1):
  net: fec: Add a fec_enet_clear_ethtool_stats() stub for CONFIG_M5272

Florian Fainelli (1):
  net: phy: Fix MDIO_THUNDER dependencies

Huy Nguyen (1):
  net/mlx5: Remove several module events out of ethtool stats

Jacob Keller (1):
  i40e: fix handling of HW ATR eviction

Jason A. Donenfeld (1):
  mac80211/wpa: use constant time memory comparison for MACs

Jesper Dangaard Brouer (1):
  net: don't global ICMP rate limit packets originating from loopback

Jia-Ju Bai (3):
  net: caif: Fix a sleep-in-atomic bug in cfpkt_create_pfx
  net: tipc: Fix a sleep-in-atomic bug in tipc_msg_reverse
  i40e: Fix a sleep-in-atomic bug

Joe Perches (2):
  net: phy: add missing SPEED_14000
  netconsole: Remove duplicate "netconsole: " logging prefix

Johan Hovold (1):
  can: peak_usb: fix product-id endianness in error message


Re: [PATCH v2] ip6_tunnel: Correct tos value in collect_md mode

2017-06-14 Thread Peter Dawson
On Thu, 15 Jun 2017 10:30:29 +0800
Haishuang Yan  wrote:

> Same as ip_gre, geneve and vxlan, use key->tos as tos value.
> 
> CC: Peter Dawson 
> Fixes: 0e9a709560db ("ip6_tunnel, ip6_gre: fix setting of DSCP on
> encapsulated packets”)
> Suggested-by: Daniel Borkmann 
> Signed-off-by: Haishuang Yan 
> 
> ---
> Changes since v2:
>   * Add fixes information
>   * mask key->tos with RT_TOS() suggested by Daniel
> ---
>  net/ipv6/ip6_tunnel.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
> index ef99d59..6400726 100644
> --- a/net/ipv6/ip6_tunnel.c
> +++ b/net/ipv6/ip6_tunnel.c
> @@ -1249,7 +1249,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device 
> *dev, __u8 dsfield,
>   fl6.flowi6_proto = IPPROTO_IPIP;
>   fl6.daddr = key->u.ipv6.dst;
>   fl6.flowlabel = key->label;
> - dsfield = ip6_tclass(key->label);
> + dsfield =  RT_TOS(key->tos);
>   } else {
>   if (!(t->parms.flags & IP6_TNL_F_IGN_ENCAP_LIMIT))
>   encap_limit = t->parms.encap_limit;
> @@ -1320,7 +1320,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device 
> *dev, __u8 dsfield,
>   fl6.flowi6_proto = IPPROTO_IPV6;
>   fl6.daddr = key->u.ipv6.dst;
>   fl6.flowlabel = key->label;
> - dsfield = ip6_tclass(key->label);
> + dsfield = RT_TOS(key->tos);
>   } else {
>   offset = ip6_tnl_parse_tlv_enc_lim(skb, 
> skb_network_header(skb));
>   /* ip6_tnl_parse_tlv_enc_lim() might have reallocated skb->head 
> */

I don't think it is correct to apply RT_TOS

Here is my understanding based on the RFCs.

IPv4/6 Header:0 |0 1 2 3 |0 1 2 3 |0 1 2 3 |0 1 2 3 |
RFC2460(IPv6)   |Version | Traffic Class   ||
RFC2474(IPv6)   |Version | DSCP|ECN||
RFC2474(IPv4)   |Version |  IHL   |DSCP |ECN|
RFC1349(IPv4)   |Version |  IHL   | PREC |  TOS   |X| 
RFC791 (IPv4)   |Version |  IHL   |  TOS|

u8 key->tos stores the full 8bits of Traffic class from an IPv6 header and;
u8 key->tos stores the full 8bits of TOS(RFC791) from an IPv4 header
u8 ip6_tclass will return the full 8bits of Traffic Class from an IPv6 flowlabel

RT_TOS will return the RFC1349 4bit TOS field.

Applying RT_TOS to a key->tos will result in lost information and the inclusion 
of 1 bit of ECN if the original field was a DSCP+ECN.

Based on this understanding of the RFCs (but not years of experience) and since 
RFC1349 has been obsoleted by RFC2474 I think the use of RT_TOS should be 
deprecated.

This being said, dsfield = ip6_tclass(key->label) = key->tos isn't fully 
correct either because the result will contain the ECN bits as well as the DSCP.

I agree that code should be consistent, but not where there is a potential 
issue.



Re: [PATCH 1/5 net-next] ibmvnic: Activate disabled RX buffer pools on reset

2017-06-14 Thread Thomas Falcon
On 06/14/2017 10:42 PM, David Miller wrote:
> Please always provide a proper "[PATCH 0/N ...] " header posting
> explaining what the patch series is doing, how it is doing it, and why
> it is doing it that way.
>
> I am getting kind of tired asking people for this FWIW...
>
Sorry, I will send a v2 with a proper header patch shortly.  Thanks for the 
prompt feedback.



Re: [net] i40e: Fix a sleep-in-atomic bug

2017-06-14 Thread David Miller
From: Jeff Kirsher 
Date: Wed, 14 Jun 2017 16:35:31 -0700

> From: Jia-Ju Bai 
> 
> The driver may sleep under a spin lock, and the function call path is:
> i40e_ndo_set_vf_port_vlan (acquire the lock by spin_lock_bh)
>   i40e_vsi_remove_pvid
> i40e_vlan_stripping_disable
>   i40e_aq_update_vsi_params
> i40e_asq_send_command
>   mutex_lock --> may sleep
> 
> To fixed it, the spin lock is released before "i40e_vsi_remove_pvid", and
> the lock is acquired again after this function.
> 
> Signed-off-by: Jia-Ju Bai 
> Tested-by: Andrew Bowers 
> Signed-off-by: Jeff Kirsher 

Applied, thanks Jeff.


Re: [PATCH 1/5 net-next] ibmvnic: Activate disabled RX buffer pools on reset

2017-06-14 Thread David Miller

Please always provide a proper "[PATCH 0/N ...] " header posting
explaining what the patch series is doing, how it is doing it, and why
it is doing it that way.

I am getting kind of tired asking people for this FWIW...


Investment portfolio

2017-06-14 Thread Hassan Dako
Hello,

How are you today?

we have the financial capability to finance any investment portfolio as far as 
is it genuine, all we need is a capable business partner that possesses 
investment strategies or profitable business information for good turn over 
within 10-20years.

We can provide proof of funds on demand Please write me back if you can work 
with me on this project.

Thank You,

Best Regards
Hassan Dako


[PATCH 5/5 net-next] ibmvnic: Exit polling routine correctly during adapter reset

2017-06-14 Thread Thomas Falcon
This patch fixes a bug where, in the case of a device reset,
the polling routine will never complete, causing napi_disable
to sleep indefinitely when attempting to close the device. 

Signed-off-by: Thomas Falcon 
---
 drivers/net/ethernet/ibm/ibmvnic.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index 5378b21..ba4c79d 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1504,9 +1504,6 @@ static int ibmvnic_poll(struct napi_struct *napi, int 
budget)
int scrq_num = (int)(napi - adapter->napi);
int frames_processed = 0;
 
-   if (adapter->resetting)
-   return 0;
-
 restart_poll:
while (frames_processed < budget) {
struct sk_buff *skb;
@@ -1516,6 +1513,12 @@ static int ibmvnic_poll(struct napi_struct *napi, int 
budget)
u16 offset;
u8 flags = 0;
 
+   if (unlikely(adapter->resetting)) {
+   enable_scrq_irq(adapter, adapter->rx_scrq[scrq_num]);
+   napi_complete_done(napi, frames_processed);
+   return frames_processed;
+   }
+
if (!pending_scrq(adapter, adapter->rx_scrq[scrq_num]))
break;
next = ibmvnic_next_scrq(adapter, adapter->rx_scrq[scrq_num]);
-- 
1.8.5.6



[PATCH 1/5 net-next] ibmvnic: Activate disabled RX buffer pools on reset

2017-06-14 Thread Thomas Falcon
RX buffer pools are disabled while awaiting a device
reset if firmware indicates that the resource is closed.

This patch fixes a bug where pools were not being 
subsequently enabled after the device reset, causing
the device to become inoperable.

Signed-off-by: Thomas Falcon 

---
 drivers/net/ethernet/ibm/ibmvnic.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index 7e585fd..000cd15 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -383,6 +383,7 @@ static int reset_rx_pools(struct ibmvnic_adapter *adapter)
atomic_set(_pool->available, 0);
rx_pool->next_alloc = 0;
rx_pool->next_free = 0;
+   rx_pool->active = 1;
}
 
return 0;
-- 
1.8.5.6



[PATCH 2/5 net-next] ibmvnic: Ensure that TX queues are disabled in __ibmvnic_close

2017-06-14 Thread Thomas Falcon
Use netif_tx_disable to guarantee that TX queues are disabled 
when __ibmvnic_close is called by the device reset routine.

Signed-off-by: Thomas Falcon 
---
 drivers/net/ethernet/ibm/ibmvnic.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index 000cd15..d5fbf45 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -886,7 +886,13 @@ static int __ibmvnic_close(struct net_device *netdev)
int i;
 
adapter->state = VNIC_CLOSING;
-   netif_tx_stop_all_queues(netdev);
+
+   /* ensure that transmissions are stopped if called by do_reset */
+   if (adapter->resetting)
+   netif_tx_disable(netdev);
+   else
+   netif_tx_stop_all_queues(netdev);
+
ibmvnic_napi_disable(adapter);
 
if (adapter->tx_scrq) {
-- 
1.8.5.6



[PATCH 3/5 net-next] ibmvnic: Sanitize entire SCRQ buffer on reset

2017-06-14 Thread Thomas Falcon
Fixup a typo so that the entire SCRQ buffer is cleaned.

Signed-off-by: Thomas Falcon 
---
 drivers/net/ethernet/ibm/ibmvnic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index d5fbf45..167b47b 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1745,7 +1745,7 @@ static int reset_one_sub_crq_queue(struct ibmvnic_adapter 
*adapter,
scrq->irq = 0;
}
 
-   memset(scrq->msgs, 0, 2 * PAGE_SIZE);
+   memset(scrq->msgs, 0, 4 * PAGE_SIZE);
scrq->cur = 0;
 
rc = h_reg_sub_crq(adapter->vdev->unit_address, scrq->msg_token,
-- 
1.8.5.6



[PATCH 4/5 net-next] ibmvnic: Remove VNIC_CLOSING check from pending_scrq

2017-06-14 Thread Thomas Falcon
Fix a kernel panic resulting from data access of a NULL
pointer during device close. The pending_scrq routine is
meant to determine whether there is a valid sub-CRQ message
awaiting processing. When the device is closing, however,
there is a possibility that NULL messages can be processed
because pending_scrq will always return 1 even if there
no valid message in the queue.

It's not clear what this closing state check was originally
meant to accomplish, so just remove it.  

Signed-off-by: Thomas Falcon 
---
 drivers/net/ethernet/ibm/ibmvnic.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index 167b47b..5378b21 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -2268,8 +2268,7 @@ static int pending_scrq(struct ibmvnic_adapter *adapter,
 {
union sub_crq *entry = >msgs[scrq->cur];
 
-   if (entry->generic.first & IBMVNIC_CRQ_CMD_RSP ||
-   adapter->state == VNIC_CLOSING)
+   if (entry->generic.first & IBMVNIC_CRQ_CMD_RSP)
return 1;
else
return 0;
-- 
1.8.5.6



[PATCH] net: s2io: remove useless variable in fill_rx_buffers

2017-06-14 Thread Gustavo A. R. Silva
Remove useless variable rxd_index and code related.

Addresses-Coverity-ID: 1397691
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/net/ethernet/neterion/s2io.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/net/ethernet/neterion/s2io.c 
b/drivers/net/ethernet/neterion/s2io.c
index 118723e..fd2ec36 100644
--- a/drivers/net/ethernet/neterion/s2io.c
+++ b/drivers/net/ethernet/neterion/s2io.c
@@ -2459,7 +2459,6 @@ static int fill_rx_buffers(struct s2io_nic *nic, struct 
ring_info *ring,
struct buffAdd *ba;
struct RxD_t *first_rxdp = NULL;
u64 Buffer0_ptr = 0, Buffer1_ptr = 0;
-   int rxd_index = 0;
struct RxD1 *rxdp1;
struct RxD3 *rxdp3;
struct swStat *swstats = >nic->mac_control.stats_info->sw_stat;
@@ -2474,10 +2473,6 @@ static int fill_rx_buffers(struct s2io_nic *nic, struct 
ring_info *ring,
 
rxdp = ring->rx_blocks[block_no].rxds[off].virt_addr;
 
-   rxd_index = off + 1;
-   if (block_no)
-   rxd_index += (block_no * ring->rxd_count);
-
if ((block_no == block_no1) &&
(off == ring->rx_curr_get_info.offset) &&
(rxdp->Host_Control)) {
-- 
2.5.0



[PATCH] intel: i40e: virtchnl: fix incorrect variable assignment

2017-06-14 Thread Gustavo A. R. Silva
Fix incorrect variable assignment.
Based on line 1511: aq_ret = I40_ERR_PARAM; the correct variable to be
used in this instance is aq_ret instead of ret. Also, variable ret is
updated at line 1602 just before return, so assigning a value to this
variable in this code block is useless.

Addresses-Coverity-ID: 1397693
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c 
b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 6bee254..fb1f018 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -1567,7 +1567,7 @@ static int i40e_vc_get_vf_resources_msg(struct i40e_vf 
*vf, u8 *msg)
dev_err(>pdev->dev,
"VF %d requested polling mode: this feature is 
supported only when the device is running in single function per port (SFP) 
mode\n",
 vf->vf_id);
-   ret = I40E_ERR_PARAM;
+   aq_ret = I40E_ERR_PARAM;
goto err;
}
vfres->vf_offload_flags |= VIRTCHNL_VF_OFFLOAD_RX_POLLING;
-- 
2.5.0



[PATCH v2] ip6_tunnel: Correct tos value in collect_md mode

2017-06-14 Thread Haishuang Yan
Same as ip_gre, geneve and vxlan, use key->tos as tos value.

CC: Peter Dawson 
Fixes: 0e9a709560db ("ip6_tunnel, ip6_gre: fix setting of DSCP on
encapsulated packets”)
Suggested-by: Daniel Borkmann 
Signed-off-by: Haishuang Yan 

---
Changes since v2:
  * Add fixes information
  * mask key->tos with RT_TOS() suggested by Daniel
---
 net/ipv6/ip6_tunnel.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index ef99d59..6400726 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1249,7 +1249,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device 
*dev, __u8 dsfield,
fl6.flowi6_proto = IPPROTO_IPIP;
fl6.daddr = key->u.ipv6.dst;
fl6.flowlabel = key->label;
-   dsfield = ip6_tclass(key->label);
+   dsfield =  RT_TOS(key->tos);
} else {
if (!(t->parms.flags & IP6_TNL_F_IGN_ENCAP_LIMIT))
encap_limit = t->parms.encap_limit;
@@ -1320,7 +1320,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device 
*dev, __u8 dsfield,
fl6.flowi6_proto = IPPROTO_IPV6;
fl6.daddr = key->u.ipv6.dst;
fl6.flowlabel = key->label;
-   dsfield = ip6_tclass(key->label);
+   dsfield = RT_TOS(key->tos);
} else {
offset = ip6_tnl_parse_tlv_enc_lim(skb, 
skb_network_header(skb));
/* ip6_tnl_parse_tlv_enc_lim() might have reallocated skb->head 
*/
-- 
1.8.3.1





Re: [PATCH iproute2 net-next] ip neigh: allow flush FAILED neighbour entry

2017-06-14 Thread Hangbin Liu
Hi Stephen,
On Wed, Jun 14, 2017 at 09:54:50AM -0700, Stephen Hemminger wrote:
> On Mon,  5 Jun 2017 16:31:29 +0800
> Hangbin Liu  wrote:
> 
> > After upstream commit 5071034e4af7 ('neigh: Really delete an arp/neigh entry
> > on "ip neigh delete" or "arp -d"'), we could delete a single FAILED 
> > neighbour
> > entry now. But `ip neigh flush` still skip the FAILED entry.
> > 
> > Let's remove this filter so we can also flush FAILED entry.
> > 
> > Signed-off-by: Hangbin Liu 
> 
> This might create a problem. iproute2 has to be forward/backwards compatiable
> with multiple kernel versions. Users must be able to run newer versions of ip
> command on older kernels.
> 
> What happens if you run the ip command with your patch on older kernels?
> 
On older kernel with tihs patch. The result is same, we could not delete
FAILED entry. Since we could not delete it, `ip neigh` will try MAX_ROUNDS
and fail at the end. But IMHO, this should be the correct behavoir. Because
this is just what kernel did and what kernel fixed now.

Here is the result on old kernel:

With unpatched ip cmd
# ip -4 neigh show dev eth1
192.168.1.5  FAILED
192.168.1.4  FAILED
192.168.1.3  FAILED
192.168.1.6  FAILED
192.168.1.2  FAILED
# ip -4 neigh flush dev eth1
# ip -4 -s neigh flush dev eth1
Nothing to flush.
# echo $?
0

With patched ip cmd
# ./ip -4 neigh flush dev eth1
*** Flush not complete bailing out after 10 rounds
# ./ip -4 -s neigh flush dev eth1

*** Round 1, deleting 5 entries ***

*** Round 2, deleting 5 entries ***

*** Round 3, deleting 5 entries ***

*** Round 4, deleting 5 entries ***

*** Round 5, deleting 5 entries ***

*** Round 6, deleting 5 entries ***

*** Round 7, deleting 5 entries ***

*** Round 8, deleting 5 entries ***

*** Round 9, deleting 5 entries ***

*** Round 10, deleting 5 entries ***
*** Flush not complete bailing out after 10 rounds
# echo $?
255

But if you thought the message reallly annoying. Then how about this patch,
which is a little tricky.

diff --git a/ip/ipneigh.c b/ip/ipneigh.c
index 4d8fc85..9088a05 100644
--- a/ip/ipneigh.c
+++ b/ip/ipneigh.c
@@ -445,7 +445,7 @@ static int do_show_or_flush(int argc, char **argv, int 
flush)
filter.flushb = flushb;
filter.flushp = 0;
filter.flushe = sizeof(flushb);
-   filter.state &= ~NUD_FAILED;

while (round < MAX_ROUNDS) {
if (rtnl_dump_request_n(, ) < 0) {
@@ -474,6 +474,7 @@ static int do_show_or_flush(int argc, char **argv, int 
flush)
printf("\n*** Round %d, deleting %d entries 
***\n", round, filter.flushed);
fflush(stdout);
}
+   filter.state &= ~NUD_FAILED;
}
printf("*** Flush not complete bailing out after %d rounds\n",
MAX_ROUNDS);


With this patch, the result will looks almost the same with old behavior,
except it will filter out the FAILED entry the first time.

# ./ip -4 neigh flush dev eth1
# ./ip -4 -s neigh flush dev eth1

*** Round 1, deleting 5 entries ***
*** Flush is complete after 1 round ***
# echo $?
0


Thanks
Hangbin


[PATCH v4 2/2] ip6_tunnel: fix potential issue in __ip6_tnl_rcv

2017-06-14 Thread Haishuang Yan
When __ip6_tnl_rcv fails, the tun_dst won't be freed, so call
dst_release to free it in error code path.

Fixes: 8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnels")
CC: Alexei Starovoitov 
Tested-by: Zhang Shengju 
Signed-off-by: Haishuang Yan 

---
Changes since v4:
  * Add the the missing Fixes information
  * Free tun_dst from error code path
  * Add tester information
---
 net/ipv6/ip6_tunnel.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 9b37f97..ef99d59 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -859,6 +859,8 @@ static int __ip6_tnl_rcv(struct ip6_tnl *tunnel, struct 
sk_buff *skb,
return 0;
 
 drop:
+   if (tun_dst)
+   dst_release((struct dst_entry *)tun_dst);
kfree_skb(skb);
return 0;
 }
-- 
1.8.3.1





[PATCH v4 1/2] ip_tunnel: fix potential issue in ip_tunnel_rcv

2017-06-14 Thread Haishuang Yan
When ip_tunnel_rcv fails, the tun_dst won't be freed, so call
dst_release to free it in error code path.

Fixes: 2e15ea390e6f ("ip_gre: Add support to collect tunnel metadata.")
Acked-by: Eric Dumazet 
Acked-by: Pravin B Shelar 
Tested-by: Zhang Shengju 
Signed-off-by: Haishuang Yan 

---
Change since v4:
  * Add the the missing Fixes information
  * Free tun_dst from error code path
  * Add tester information
---
 net/ipv4/ip_tunnel.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index b878ecb..0f1d876 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -446,6 +446,8 @@ int ip_tunnel_rcv(struct ip_tunnel *tunnel, struct sk_buff 
*skb,
return 0;
 
 drop:
+   if (tun_dst)
+   dst_release((struct dst_entry *)tun_dst);
kfree_skb(skb);
return 0;
 }
-- 
1.8.3.1





June 14, 2017

2017-06-14 Thread Johnson King
Attn,

My name is Johnson King, the principal attorney of my law firm., Johnson King & 
Co. A deceased client Mr. Henry died in 2010 and left a sum little above US$ 28 
million in his account here in Unity Bank Plc. Normally banking procedures 
requires that the bank declares the account forfeitable and transfer the 
proceeds to the Registry of Unclaimed Property for government use after 8 years 
from the time of the death of the deceased client.

The present situation made me to contact you given that you and my deceased 
client share the same last name and nationality which made it favorably 
disposed towards this proposals to present you as the Cestui Que trust and 
administrator of the account. It may also interest you to know that the 
transaction will be executed within the ambit of law and nothing shall be done 
outside of it.If you are not familiar with estate and probate measures, I shall 
send further information to you concerning these once i get a positive 
response. Whereas We will discuss the ratios succinctly and promote them in 
written signed agreement before commencement.

I wish to submit that I would expect nothing less but honesty and transparency. 
I will uncover to you further information on the matter in our following 
communications. If this business interests you kindly revert with your direct 
phone number for further exhaustive phone talk.

I look forward to having a good business relationship with you.

Yours sincerely,
Johnson King & Co


Re: [PATCH] ip6_tunnel: Correct tos value in collect_md mode

2017-06-14 Thread 严海双

> On 14 Jun 2017, at 1:28 PM, Peter Dawson  wrote:
> 
> On Wed, 14 Jun 2017 10:54:31 +0800
> 严海双  wrote:
> 
> 
>>> Changes since v2:
>>> * mask key->tos with RT_TOS() suggested by Daniel
> 
> Can you help me understand the rationale for this change? Is there are bug 
> introduced by dsfield = ip6_tclass(key->label); ?
> 
> The RT_TOS masks out 4bits of the 8bit tos field in accordance with RFC1349 
> (obsoleted by RFC2474). IPv6 does not have a TOS field. So it dosen't make 
> sense to apply a TOS value to the outer header of an IPv6 tunnel.
> 
> 

Hi, Peter

Here the tos also means Traffic Class in IPv6, see the define in struct 
ip_tunnel_key:

u8  tos;/* TOS for IPv4, TC for IPv6 */

RT_TOS mask is suggested by Daniel, please refer to the implement in vxlan or 
geneve code:

fl6.flowlabel = ip6_make_flowinfo(RT_TOS(tos), label);

Thanks.



RE: [RFC] networking: convert many more places to skb_put_zero()

2017-06-14 Thread YUAN Linyu
Hi, 
Indeed, it find more.
Compare with my patch, still lost pattern like below,
1. sctp and openvswitch
--- a/net/sctp/output.c
+++ b/net/sctp/output.c
@@ -463,7 +463,7 @@ static int sctp_packet_pack(struct sctp_packet *packet,
 
padding = SCTP_PAD4(chunk->skb->len) - chunk->skb->len;
if (padding)
-   memset(skb_put(chunk->skb, padding), 0, 
padding);
+   skb_put_zero(chunk->skb, padding);

--- a/net/dsa/tag_trailer.c
+++ b/net/dsa/tag_trailer.c
@@ -43,8 +43,7 @@ static struct sk_buff *trailer_xmit(struct sk_buff *skb, 
struct net_device *dev)
kfree_skb(skb);
 
if (padlen) {
-   u8 *pad = skb_put(nskb, padlen);
-   memset(pad, 0, padlen);
+   skb_put_zero(nskb, padlen);

I will send a separate patch for ipv6/ndisc.c once spatch done.



> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Johannes Berg
> Sent: Thursday, June 15, 2017 4:18 AM
> To: netdev@vger.kernel.org
> Cc: Johannes Berg
> Subject: [RFC] networking: convert many more places to skb_put_zero()
> 
> From: Johannes Berg 
> 
> There were many places that my previous spatch didn't find,
> as pointed out by yuan linyu in various patches.
> 
> The following spatch found many more and also removes the
> now unnecessary casts:
> 
> @@
> identifier p, p2;
> expression len;
> expression skb;
> type t, t2;
> @@
> (
> -p = skb_put(skb, len);
> +p = skb_put_zero(skb, len);
> |
> -p = (t)skb_put(skb, len);
> +p = skb_put_zero(skb, len);
> )
> (
> p2 = (t2)p;
> -memset(p2, 0, len);
> |
> -memset(p, 0, len);
> )
> 
> @@
> type t, t2;
> identifier p, p2;
> expression skb;
> @@
> t *p;
> ...
> (
> -p = skb_put(skb, sizeof(t));
> +p = skb_put_zero(skb, sizeof(t));
> |
> -p = (t *)skb_put(skb, sizeof(t));
> +p = skb_put_zero(skb, sizeof(t));
> )
> (
> p2 = (t2)p;
> -memset(p2, 0, sizeof(*p));
> |
> -memset(p, 0, sizeof(*p));
> )
> 


RE: [PATCH net-next 00/11] skb_put_zero() used to optimize code

2017-06-14 Thread YUAN Linyu


> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Johannes Berg
> Sent: Thursday, June 15, 2017 12:32 AM
> To: cug...@163.com; netdev@vger.kernel.org
> Cc: David S . Miller; YUAN Linyu
> Subject: Re: [PATCH net-next 00/11] skb_put_zero() used to optimize code
> 
> On Wed, 2017-06-14 at 18:29 +0200, Johannes Berg wrote:
> > On Wed, 2017-06-14 at 23:00 +0800, yuan linyu wrote:
> >
> > > sorry, I do them by hand.
> >
> > oh, ok.
> >
> > This seems to work:
> >
> > @@
> > identifier p;
> > expression len;
> > expression skb;
> > type t;
> > @@
> > -p = (t)skb_put(skb, len);
> > -memset(p, 0, len);
> > +p = (t)skb_put_zero(skb, len);
> 
> Nope, still didn't find everything - not the batman and atm cases for
> example. But still a few more, I think that you didn't find, e.g. in
> mac80211.
Yes, I thought you already done in mac80211
> 
> Anyway - I think none of this is really critical.
> 
> johannes


[net] i40e: Fix a sleep-in-atomic bug

2017-06-14 Thread Jeff Kirsher
From: Jia-Ju Bai 

The driver may sleep under a spin lock, and the function call path is:
i40e_ndo_set_vf_port_vlan (acquire the lock by spin_lock_bh)
  i40e_vsi_remove_pvid
i40e_vlan_stripping_disable
  i40e_aq_update_vsi_params
i40e_asq_send_command
  mutex_lock --> may sleep

To fixed it, the spin lock is released before "i40e_vsi_remove_pvid", and
the lock is acquired again after this function.

Signed-off-by: Jia-Ju Bai 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c 
b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 95c23fbaa211..0fb38ca78900 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -3017,10 +3017,12 @@ int i40e_ndo_set_vf_port_vlan(struct net_device 
*netdev, int vf_id,
   VLAN_VID_MASK));
}
 
+   spin_unlock_bh(>mac_filter_hash_lock);
if (vlan_id || qos)
ret = i40e_vsi_add_pvid(vsi, vlanprio);
else
i40e_vsi_remove_pvid(vsi);
+   spin_lock_bh(>mac_filter_hash_lock);
 
if (vlan_id) {
dev_info(>pdev->dev, "Setting VLAN %d, QOS 0x%x on VF %d\n",
-- 
2.12.2



Re: [PATCH iproute2 master] bpf: provide fallback defs for __NR_bpf when not avail

2017-06-14 Thread Stephen Hemminger
On Thu, 15 Jun 2017 01:01:14 +0200
Daniel Borkmann  wrote:

> On 06/15/2017 12:56 AM, Stephen Hemminger wrote:
> > On Thu, 15 Jun 2017 00:47:15 +0200
> > Daniel Borkmann  wrote:
> >  
> >> panji reported that he wasn't able to build iproute2's bpf library
> >> due to lack of __NR_bpf in his system headers. Providing a fallback
> >> definition when __NR_bpf is not available in the system lets the
> >> loader compile just fine, so lets add them for majority of archs.
> >>
> >> Reported-by: panji 
> >> Signed-off-by: Daniel Borkmann 
> >> ---
> >>   lib/bpf.c | 20 
> >>   1 file changed, 20 insertions(+)
> >>
> >> diff --git a/lib/bpf.c b/lib/bpf.c
> >> index ae4d97d..e1e29cc 100644
> >> --- a/lib/bpf.c
> >> +++ b/lib/bpf.c
> >> @@ -128,6 +128,26 @@ static inline __u64 bpf_ptr_to_u64(const void *ptr)
> >>return (__u64)(unsigned long)ptr;
> >>   }
> >>
> >> +#ifndef __NR_bpf
> >> +# if defined(__i386__)
> >> +#  define __NR_bpf 357
> >> +# elif defined(__x86_64__)
> >> +#  define __NR_bpf 321
> >> +# elif defined(__aarch64__)
> >> +#  define __NR_bpf 280
> >> +# elif defined(__sparc__)
> >> +#  define __NR_bpf 349
> >> +# elif defined(__arm__)
> >> +#  define __NR_bpf 386
> >> +# elif defined(__powerpc__)
> >> +#  define __NR_bpf 361
> >> +# elif defined(__s390__)
> >> +#  define __NR_bpf 351
> >> +# else
> >> +#  error __NR_bpf not defined. Update kernel headers.
> >> +# endif
> >> +#endif
> >> +
> >>   static int bpf(int cmd, union bpf_attr *attr, unsigned int size)
> >>   {
> >>   #ifdef __NR_bpf  
> >
> > Sorry this looks like a mess. enumerating architectures in two different
> > projects is likely to break in future.  
> 
> It says ifndef __NR_bpf, so only used then. And the numbers are uabi,
> what will break here exactly? libbpf in kernel tree is having a similar
> approach by the way.

You are defining values in two places (kernel and userspace) which has caused
lots of mismatch in the past. Why isn't this in a kernel uapi header somewhere?


Re: [PATCH v3 net-next 0/4] kernel TLS

2017-06-14 Thread Tom Herbert
On Wed, Jun 14, 2017 at 3:17 PM, Dave Watson  wrote:
> On 06/14/17 01:54 PM, Tom Herbert wrote:
>> On Wed, Jun 14, 2017 at 11:36 AM, Dave Watson  wrote:
>> > This series adds support for kernel TLS encryption over TCP sockets.
>> > A standard TCP socket is converted to a TLS socket using a setsockopt.
>> > Only symmetric crypto is done in the kernel, as well as TLS record
>> > framing.  The handshake remains in userspace, and the negotiated
>> > cipher keys/iv are provided to the TCP socket.
>> >
>> I don't see support for TLS receive path in the kernel, only the send
>> path. Am I missing something?
>
> Correct, this is only TX.  Since it sounds likely some hardware might
> only be able to offload TX, we decided to configure TX and RX
> separately.  Using the OpenSSL patches, it should be transparent to
> users even if only one side is offloaded.
>
> The software RX patches exist but haven't been polished up yet.

Thanks for the clarification, looking forward to RX patches also!

Tom


[PATCH net] rxrpc: Fix several cases where a padded len isn't checked in ticket decode

2017-06-14 Thread David Howells
This fixes CVE-2017-7482.

When a kerberos 5 ticket is being decoded so that it can be loaded into an
rxrpc-type key, there are several places in which the length of a
variable-length field is checked to make sure that it's not going to
overrun the available data - but the data is padded to the nearest
four-byte boundary and the code doesn't check for this extra.  This could
lead to the size-remaining variable wrapping and the data pointer going
over the end of the buffer.

Fix this by making the various variable-length data checks use the padded
length.

Reported-by: 石磊 
Signed-off-by: David Howells 
Reviewed-by: Marc Dionne 
Reviewed-by: Dan Carpenter 
---

 net/rxrpc/key.c |   64 +--
 1 file changed, 34 insertions(+), 30 deletions(-)

diff --git a/net/rxrpc/key.c b/net/rxrpc/key.c
index 0a4e28477ad9..54369225766e 100644
--- a/net/rxrpc/key.c
+++ b/net/rxrpc/key.c
@@ -217,7 +217,7 @@ static int rxrpc_krb5_decode_principal(struct 
krb5_principal *princ,
   unsigned int *_toklen)
 {
const __be32 *xdr = *_xdr;
-   unsigned int toklen = *_toklen, n_parts, loop, tmp;
+   unsigned int toklen = *_toklen, n_parts, loop, tmp, paddedlen;
 
/* there must be at least one name, and at least #names+1 length
 * words */
@@ -247,16 +247,16 @@ static int rxrpc_krb5_decode_principal(struct 
krb5_principal *princ,
toklen -= 4;
if (tmp <= 0 || tmp > AFSTOKEN_STRING_MAX)
return -EINVAL;
-   if (tmp > toklen)
+   paddedlen = (tmp + 3) & ~3;
+   if (paddedlen > toklen)
return -EINVAL;
princ->name_parts[loop] = kmalloc(tmp + 1, GFP_KERNEL);
if (!princ->name_parts[loop])
return -ENOMEM;
memcpy(princ->name_parts[loop], xdr, tmp);
princ->name_parts[loop][tmp] = 0;
-   tmp = (tmp + 3) & ~3;
-   toklen -= tmp;
-   xdr += tmp >> 2;
+   toklen -= paddedlen;
+   xdr += paddedlen >> 2;
}
 
if (toklen < 4)
@@ -265,16 +265,16 @@ static int rxrpc_krb5_decode_principal(struct 
krb5_principal *princ,
toklen -= 4;
if (tmp <= 0 || tmp > AFSTOKEN_K5_REALM_MAX)
return -EINVAL;
-   if (tmp > toklen)
+   paddedlen = (tmp + 3) & ~3;
+   if (paddedlen > toklen)
return -EINVAL;
princ->realm = kmalloc(tmp + 1, GFP_KERNEL);
if (!princ->realm)
return -ENOMEM;
memcpy(princ->realm, xdr, tmp);
princ->realm[tmp] = 0;
-   tmp = (tmp + 3) & ~3;
-   toklen -= tmp;
-   xdr += tmp >> 2;
+   toklen -= paddedlen;
+   xdr += paddedlen >> 2;
 
_debug("%s/...@%s", princ->name_parts[0], princ->realm);
 
@@ -293,7 +293,7 @@ static int rxrpc_krb5_decode_tagged_data(struct 
krb5_tagged_data *td,
 unsigned int *_toklen)
 {
const __be32 *xdr = *_xdr;
-   unsigned int toklen = *_toklen, len;
+   unsigned int toklen = *_toklen, len, paddedlen;
 
/* there must be at least one tag and one length word */
if (toklen <= 8)
@@ -307,15 +307,17 @@ static int rxrpc_krb5_decode_tagged_data(struct 
krb5_tagged_data *td,
toklen -= 8;
if (len > max_data_size)
return -EINVAL;
+   paddedlen = (len + 3) & ~3;
+   if (paddedlen > toklen)
+   return -EINVAL;
td->data_len = len;
 
if (len > 0) {
td->data = kmemdup(xdr, len, GFP_KERNEL);
if (!td->data)
return -ENOMEM;
-   len = (len + 3) & ~3;
-   toklen -= len;
-   xdr += len >> 2;
+   toklen -= paddedlen;
+   xdr += paddedlen >> 2;
}
 
_debug("tag %x len %x", td->tag, td->data_len);
@@ -387,7 +389,7 @@ static int rxrpc_krb5_decode_ticket(u8 **_ticket, u16 
*_tktlen,
const __be32 **_xdr, unsigned int *_toklen)
 {
const __be32 *xdr = *_xdr;
-   unsigned int toklen = *_toklen, len;
+   unsigned int toklen = *_toklen, len, paddedlen;
 
/* there must be at least one length word */
if (toklen <= 4)
@@ -399,6 +401,9 @@ static int rxrpc_krb5_decode_ticket(u8 **_ticket, u16 
*_tktlen,
toklen -= 4;
if (len > AFSTOKEN_K5_TIX_MAX)
return -EINVAL;
+   paddedlen = (len + 3) & ~3;
+   if (paddedlen > toklen)
+   return -EINVAL;
*_tktlen = len;
 
_debug("ticket len %u", len);
@@ -407,9 +412,8 @@ static int rxrpc_krb5_decode_ticket(u8 **_ticket, u16 
*_tktlen,
*_ticket = kmemdup(xdr, len, GFP_KERNEL);
if 

Re: [PATCH iproute2 master] bpf: provide fallback defs for __NR_bpf when not avail

2017-06-14 Thread Daniel Borkmann

On 06/15/2017 12:56 AM, Stephen Hemminger wrote:

On Thu, 15 Jun 2017 00:47:15 +0200
Daniel Borkmann  wrote:


panji reported that he wasn't able to build iproute2's bpf library
due to lack of __NR_bpf in his system headers. Providing a fallback
definition when __NR_bpf is not available in the system lets the
loader compile just fine, so lets add them for majority of archs.

Reported-by: panji 
Signed-off-by: Daniel Borkmann 
---
  lib/bpf.c | 20 
  1 file changed, 20 insertions(+)

diff --git a/lib/bpf.c b/lib/bpf.c
index ae4d97d..e1e29cc 100644
--- a/lib/bpf.c
+++ b/lib/bpf.c
@@ -128,6 +128,26 @@ static inline __u64 bpf_ptr_to_u64(const void *ptr)
return (__u64)(unsigned long)ptr;
  }

+#ifndef __NR_bpf
+# if defined(__i386__)
+#  define __NR_bpf 357
+# elif defined(__x86_64__)
+#  define __NR_bpf 321
+# elif defined(__aarch64__)
+#  define __NR_bpf 280
+# elif defined(__sparc__)
+#  define __NR_bpf 349
+# elif defined(__arm__)
+#  define __NR_bpf 386
+# elif defined(__powerpc__)
+#  define __NR_bpf 361
+# elif defined(__s390__)
+#  define __NR_bpf 351
+# else
+#  error __NR_bpf not defined. Update kernel headers.
+# endif
+#endif
+
  static int bpf(int cmd, union bpf_attr *attr, unsigned int size)
  {
  #ifdef __NR_bpf


Sorry this looks like a mess. enumerating architectures in two different
projects is likely to break in future.


It says ifndef __NR_bpf, so only used then. And the numbers are uabi,
what will break here exactly? libbpf in kernel tree is having a similar
approach by the way.


Re: [PATCH iproute2 master] bpf: provide fallback defs for __NR_bpf when not avail

2017-06-14 Thread Stephen Hemminger
On Thu, 15 Jun 2017 00:47:15 +0200
Daniel Borkmann  wrote:

> panji reported that he wasn't able to build iproute2's bpf library
> due to lack of __NR_bpf in his system headers. Providing a fallback
> definition when __NR_bpf is not available in the system lets the
> loader compile just fine, so lets add them for majority of archs.
> 
> Reported-by: panji 
> Signed-off-by: Daniel Borkmann 
> ---
>  lib/bpf.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/lib/bpf.c b/lib/bpf.c
> index ae4d97d..e1e29cc 100644
> --- a/lib/bpf.c
> +++ b/lib/bpf.c
> @@ -128,6 +128,26 @@ static inline __u64 bpf_ptr_to_u64(const void *ptr)
>   return (__u64)(unsigned long)ptr;
>  }
>  
> +#ifndef __NR_bpf
> +# if defined(__i386__)
> +#  define __NR_bpf 357
> +# elif defined(__x86_64__)
> +#  define __NR_bpf 321
> +# elif defined(__aarch64__)
> +#  define __NR_bpf 280
> +# elif defined(__sparc__)
> +#  define __NR_bpf 349
> +# elif defined(__arm__)
> +#  define __NR_bpf 386
> +# elif defined(__powerpc__)
> +#  define __NR_bpf 361
> +# elif defined(__s390__)
> +#  define __NR_bpf 351
> +# else
> +#  error __NR_bpf not defined. Update kernel headers.
> +# endif
> +#endif
> +
>  static int bpf(int cmd, union bpf_attr *attr, unsigned int size)
>  {
>  #ifdef __NR_bpf

Sorry this looks like a mess. enumerating architectures in two different
projects is likely to break in future.


[PATCH iproute2 master] bpf: provide fallback defs for __NR_bpf when not avail

2017-06-14 Thread Daniel Borkmann
panji reported that he wasn't able to build iproute2's bpf library
due to lack of __NR_bpf in his system headers. Providing a fallback
definition when __NR_bpf is not available in the system lets the
loader compile just fine, so lets add them for majority of archs.

Reported-by: panji 
Signed-off-by: Daniel Borkmann 
---
 lib/bpf.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/lib/bpf.c b/lib/bpf.c
index ae4d97d..e1e29cc 100644
--- a/lib/bpf.c
+++ b/lib/bpf.c
@@ -128,6 +128,26 @@ static inline __u64 bpf_ptr_to_u64(const void *ptr)
return (__u64)(unsigned long)ptr;
 }
 
+#ifndef __NR_bpf
+# if defined(__i386__)
+#  define __NR_bpf 357
+# elif defined(__x86_64__)
+#  define __NR_bpf 321
+# elif defined(__aarch64__)
+#  define __NR_bpf 280
+# elif defined(__sparc__)
+#  define __NR_bpf 349
+# elif defined(__arm__)
+#  define __NR_bpf 386
+# elif defined(__powerpc__)
+#  define __NR_bpf 361
+# elif defined(__s390__)
+#  define __NR_bpf 351
+# else
+#  error __NR_bpf not defined. Update kernel headers.
+# endif
+#endif
+
 static int bpf(int cmd, union bpf_attr *attr, unsigned int size)
 {
 #ifdef __NR_bpf
-- 
1.9.3



[PATCH net-next] sunvnet: restrict advertized checksum offloads to just IP

2017-06-14 Thread Shannon Nelson
As much as we'd like to play well with others, we really aren't
handling the checksums on non-IP protocol packets very well.  This
is easily seen when trying to do TCP over ipv6 - the checksums are
garbage.

Here we restrict the checksum feature flag to just IP traffic so
that we aren't given work we can't yet do.

Orabug: 26175391, 26259755

Signed-off-by: Shannon Nelson 
---
 drivers/net/ethernet/sun/ldmvsw.c  |2 +-
 drivers/net/ethernet/sun/sunvnet.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/sun/ldmvsw.c 
b/drivers/net/ethernet/sun/ldmvsw.c
index 5b56c24..8603e39 100644
--- a/drivers/net/ethernet/sun/ldmvsw.c
+++ b/drivers/net/ethernet/sun/ldmvsw.c
@@ -248,7 +248,7 @@ static void vsw_poll_controller(struct net_device *dev)
dev->ethtool_ops = _ethtool_ops;
dev->watchdog_timeo = VSW_TX_TIMEOUT;
 
-   dev->hw_features = NETIF_F_HW_CSUM | NETIF_F_SG;
+   dev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG;
dev->features = dev->hw_features;
 
/* MTU range: 68 - 65535 */
diff --git a/drivers/net/ethernet/sun/sunvnet.c 
b/drivers/net/ethernet/sun/sunvnet.c
index 0b95105..75b167e 100644
--- a/drivers/net/ethernet/sun/sunvnet.c
+++ b/drivers/net/ethernet/sun/sunvnet.c
@@ -312,7 +312,7 @@ static void vnet_poll_controller(struct net_device *dev)
dev->watchdog_timeo = VNET_TX_TIMEOUT;
 
dev->hw_features = NETIF_F_TSO | NETIF_F_GSO | NETIF_F_GSO_SOFTWARE |
-  NETIF_F_HW_CSUM | NETIF_F_SG;
+  NETIF_F_IP_CSUM | NETIF_F_SG;
dev->features = dev->hw_features;
 
/* MTU range: 68 - 65535 */
-- 
1.7.1



Re: Repeatable inet6_dump_fib crash in stock 4.12.0-rc4+

2017-06-14 Thread David Ahern
On 6/14/17 4:23 PM, Ben Greear wrote:
> On 06/13/2017 07:27 PM, David Ahern wrote:
> 
>> Let's try a targeted debug patch. See attached
> 
> I had to change it to pr_err so it would go to our serial console
> since the system locked hard on crash,
> and that appears to be enough to change the timing where we can no longer
> reproduce the problem.


ok, let's figure out which one is doing that. There are 3 debug
statements. I suspect fib6_del_route is the one setting the state to
FWS_U. Can you remove the debug prints in fib6_repair_tree and
fib6_walk_continue and try again?


Re: Repeatable inet6_dump_fib crash in stock 4.12.0-rc4+

2017-06-14 Thread Ben Greear

On 06/13/2017 07:27 PM, David Ahern wrote:


Let's try a targeted debug patch. See attached


I had to change it to pr_err so it would go to our serial console
since the system locked hard on crash,
and that appears to be enough to change the timing where we can no longer
reproduce the problem.

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com



Re: [PATCH v3 net-next 0/4] kernel TLS

2017-06-14 Thread Dave Watson
On 06/14/17 01:54 PM, Tom Herbert wrote:
> On Wed, Jun 14, 2017 at 11:36 AM, Dave Watson  wrote:
> > This series adds support for kernel TLS encryption over TCP sockets.
> > A standard TCP socket is converted to a TLS socket using a setsockopt.
> > Only symmetric crypto is done in the kernel, as well as TLS record
> > framing.  The handshake remains in userspace, and the negotiated
> > cipher keys/iv are provided to the TCP socket.
> >
> I don't see support for TLS receive path in the kernel, only the send
> path. Am I missing something?

Correct, this is only TX.  Since it sounds likely some hardware might
only be able to offload TX, we decided to configure TX and RX
separately.  Using the OpenSSL patches, it should be transparent to
users even if only one side is offloaded.

The software RX patches exist but haven't been polished up yet.


Re: [PATCH v2 03/11] tty: kbd: reduce stack size with KASAN

2017-06-14 Thread Samuel Thibault
Arnd Bergmann, on mer. 14 juin 2017 23:56:39 +0200, wrote:
> > I however agree that it's a bad idea to inline it in functions where
> > it's called so many times (and we're talking about the keyboard anyway).
> >
> >> -static void puts_queue(struct vc_data *vc, char *cp)
> >> +static noinline_if_stackbloat void puts_queue(struct vc_data *vc, char 
> >> *cp)
> >
> > I don't see why, it's only called once in the callers. k_fn, however, is
> > called several times in k_pad, so that could be why, but then it's
> > rather be the inlining of k_fn which is a bad idea.
> 
> It's called by applkey, which in turn is called by k_pad(),

k_pad calls applkey twice only. Is that really to be considered bloat?

> >> -static void fn_send_intr(struct vc_data *vc)
> >> +static noinline_if_stackbloat void fn_send_intr(struct vc_data *vc)
> >
> > This one is only referenced, not called, I don't see how that could pose
> > problem.
> 
> I was surprised by this as well, but it seems that gcc these days is
> smart enough to turn the indirect function calls for k_handler[type]
> and/or f_handler[value] into inlines again when it has already
> determined the index to be constant.

Cool :) But I don't see how it can see find it out constant. The only
fn_handler[] caller is k_spec, using value as index. The only caller of
f_handler[] is kbd_keycode, using type as index, and keysym&0xff as
value.  That is definitely not constant :)  And it's only one caller, I
don't see how that can bloat.

Samuel


Re: [PATCH v3 net-next 0/4] kernel TLS

2017-06-14 Thread Dave Watson
Hi Hannes, 

On 06/14/17 10:15 PM, Hannes Frederic Sowa wrote:
> one question for this patch set:
> 
> What is the reason for not allowing key updates for the TX path? I was
> always loud pointing out the problems with TLSv1.2 renegotiation and
> TLSv1.3 key update alerts. This patch set uses encryption in a
> synchronous way directly in the socket layer and thus wouldn't suffer
> from problems regarding updates of the key. My hunch is that you leave
> this option open so you can later on introduce asynchronous crypto which
> might be used on hardware? It looks also be doable in case of MSG_MORE.
> Otherwise by allowing key updates to the data path I would not see any
> problems with key updates in TLS.

I don't currently have any reasons to not support renegotation, we
just don't currently use it, so I didn't add support for it.  I don't
work on the hardware, but yes it looks like it would have to keep the
old keys around until everything sent using them has been acked.

> Anyway, this patch seems easy and maybe with key updates added later on
> doesn't seem to have any problems pointed out by me so far.

Indeed, it would be easy to flush any unencrypted data, and then
change the keys.


Re: [PATCH v2 03/11] tty: kbd: reduce stack size with KASAN

2017-06-14 Thread Arnd Bergmann
On Wed, Jun 14, 2017 at 11:28 PM, Samuel Thibault
 wrote:
> Hello,
>
> Arnd Bergmann, on mer. 14 juin 2017 23:15:38 +0200, wrote:
>> As reported by kernelci, some functions in the VT code use significant
>> amounts of kernel stack when local variables get inlined into the caller
>> multiple times:
>>
>> drivers/tty/vt/keyboard.c: In function 'kbd_keycode':
>> drivers/tty/vt/keyboard.c:1452:1: error: the frame size of 2240 bytes is 
>> larger than 2048 bytes [-Werror=frame-larger-than=]
>>
>> Annotating those functions as noinline_if_stackbloat prevents the inlining
>> and reduces the overall stack usage in this driver.
>
>
>> --- a/drivers/tty/vt/keyboard.c
>> +++ b/drivers/tty/vt/keyboard.c
>> @@ -301,13 +301,13 @@ int kbd_rate(struct kbd_repeat *rpt)
>>  /*
>>   * Helper Functions.
>>   */
>> -static void put_queue(struct vc_data *vc, int ch)
>> +static noinline_if_stackbloat void put_queue(struct vc_data *vc, int ch)
>>  {
>>   tty_insert_flip_char(>port, ch, 0);
>>   tty_schedule_flip(>port);
>>  }
>
> I'm surprised that this be able generate so much stack use: the
> tty_insert_flip_char inline only uses a pointer and an int.
>
> And I'm surprised that multiple inlines can accumulate stack usage.

The reason is that CONFIG_KASAN forces each local variable
to have a separate location on the stack whenever it gets
passed into an external function (tty_insert_flip_string_flags in this
case), so the sanitizer is able to report exactly which instance
caused the problem.

> I however agree that it's a bad idea to inline it in functions where
> it's called so many times (and we're talking about the keyboard anyway).
>
>> -static void puts_queue(struct vc_data *vc, char *cp)
>> +static noinline_if_stackbloat void puts_queue(struct vc_data *vc, char *cp)
>
> I don't see why, it's only called once in the callers. k_fn, however, is
> called several times in k_pad, so that could be why, but then it's
> rather be the inlining of k_fn which is a bad idea.

It's called by applkey, which in turn is called by k_pad(), and this
all gets inlined by default.

>> -static void fn_send_intr(struct vc_data *vc)
>> +static noinline_if_stackbloat void fn_send_intr(struct vc_data *vc)
>
> This one is only referenced, not called, I don't see how that could pose
> problem.

I was surprised by this as well, but it seems that gcc these days is
smart enough to turn the indirect function calls for k_handler[type]
and/or f_handler[value] into inlines again when it has already
determined the index to be constant.

It's been a while since I looked at the patch, and I'd have to
disassemble it again to figure out the details, but I'm pretty sure
I needed this to get the stack usage down to normal levels.

   Arnd


Re: [PATCH net-next 0/3] ipmr/ip6mr: add Netlink notifications on cache reports

2017-06-14 Thread Julien Gomes
Hi Nikolay,

On 06/14/2017 05:04 AM, Nikolay Aleksandrov wrote:

> This has been on our todo list and I'm definitely interested in the 
> implementation.
> A few things that need careful consideration from my POV. First are the 
> security
> implications - this sends rtnl multicast messages but the rtnl socket has
> the NL_CFG_F_NONROOT_RECV flag thus allowing any user on the system to listen 
> in.
> This would allow them to see the full packets and all reports (granted they 
> can see
> the notifications even now), but the full packet is like giving them the 
> opportunity
> to tcpdump the PIM traffic.

I definitely see how this can be an issue.
>From what I see, this means that either the packet should be
transmitted another way, or another Netlink family should be used.

NETLINK_ROUTE looks to be the logical family to choose though,
but then I do not see a proper other way to handle this.

However I may just not be looking into the right direction,
maybe you currently have another approach in mind?

> My second (more fixable and minor) concern is about the packet itself, how do 
> you
> know that the packet is all linear so you can directly copy it ?

Indeed, I overlooked this possibility in this version.
I will improve that.

-- 
Julien Gomes



Re: [PATCH v2 03/11] tty: kbd: reduce stack size with KASAN

2017-06-14 Thread Samuel Thibault
Hello,

Arnd Bergmann, on mer. 14 juin 2017 23:15:38 +0200, wrote:
> As reported by kernelci, some functions in the VT code use significant
> amounts of kernel stack when local variables get inlined into the caller
> multiple times:
> 
> drivers/tty/vt/keyboard.c: In function 'kbd_keycode':
> drivers/tty/vt/keyboard.c:1452:1: error: the frame size of 2240 bytes is 
> larger than 2048 bytes [-Werror=frame-larger-than=]
> 
> Annotating those functions as noinline_if_stackbloat prevents the inlining
> and reduces the overall stack usage in this driver.


> --- a/drivers/tty/vt/keyboard.c
> +++ b/drivers/tty/vt/keyboard.c
> @@ -301,13 +301,13 @@ int kbd_rate(struct kbd_repeat *rpt)
>  /*
>   * Helper Functions.
>   */
> -static void put_queue(struct vc_data *vc, int ch)
> +static noinline_if_stackbloat void put_queue(struct vc_data *vc, int ch)
>  {
>   tty_insert_flip_char(>port, ch, 0);
>   tty_schedule_flip(>port);
>  }

I'm surprised that this be able generate so much stack use: the
tty_insert_flip_char inline only uses a pointer and an int.

And I'm surprised that multiple inlines can accumulate stack usage.

I however agree that it's a bad idea to inline it in functions where
it's called so many times (and we're talking about the keyboard anyway).

> -static void puts_queue(struct vc_data *vc, char *cp)
> +static noinline_if_stackbloat void puts_queue(struct vc_data *vc, char *cp)

I don't see why, it's only called once in the callers. k_fn, however, is
called several times in k_pad, so that could be why, but then it's
rather be the inlining of k_fn which is a bad idea.

> -static void fn_send_intr(struct vc_data *vc)
> +static noinline_if_stackbloat void fn_send_intr(struct vc_data *vc)

This one is only referenced, not called, I don't see how that could pose
problem.

Samuel


[PATCH v2 11/11] kasan: rework Kconfig settings

2017-06-14 Thread Arnd Bergmann
We get a lot of very large stack frames using gcc-7.0.1 with the default
-fsanitize-address-use-after-scope --param asan-stack=1 options, which
can easily cause an overflow of the kernel stack, e.g.

drivers/acpi/nfit/core.c:2686:1: warning: the frame size of 4080 bytes is 
larger than 2048 bytes [-Wframe-larger-than=]
drivers/gpu/drm/amd/amdgpu/si.c:1756:1: warning: the frame size of 7304 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
drivers/gpu/drm/i915/gvt/handlers.c:2200:1: warning: the frame size of 43752 
bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:952:1: warning: the frame size of 6032 
bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/isdn/hardware/avm/b1.c:637:1: warning: the frame size of 13200 bytes is 
larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:3089:1: warning: the frame size of 5880 
bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/i2c/cx25840/cx25840-core.c:4964:1: warning: the frame size of 
93992 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:4994:1: warning: the frame size 
of 23928 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/staging/dgnc/dgnc_tty.c:2788:1: warning: the frame size of 7072 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
fs/ntfs/mft.c:2762:1: warning: the frame size of 7432 bytes is larger than 2048 
bytes [-Wframe-larger-than=]
lib/atomic64_test.c:242:1: warning: the frame size of 12648 bytes is larger 
than 2048 bytes [-Wframe-larger-than=]

To reduce this risk, -fsanitize-address-use-after-scope is now split out
into a separate Kconfig option, vhich cannot be selected at the same
time as KMEMCHECK, leading to stack frames that are smaller than 2
kilobytes most of the time on x86_64. An earlier version of this
patch also prevented combining KASAN_EXTRA with KASAN_INLINE, but that
is no longer necessary with gcc-7.0.1.

A lot of warnings with KASAN_EXTRA go away if we disable KMEMCHECK,
as -fsanitize-address-use-after-scope seems to understand the builtin
memcpy, but adds checking code around an extern memcpy call. I had
to work around a circular dependency, as DEBUG_SLAB/SLUB depended
on !KMEMCHECK, while KASAN did it the other way round. Now we handle
both the same way.

All patches to get the frame size below 2048 bytes with CONFIG_KASAN=y
and CONFIG_KASAN_EXTRA=n have been submitted along with this patch,
so we can bring back that default now. KASAN_EXTRA=y still causes lots
of warnings but now defaults to !COMPILE_TEST to disable it in
allmodconfig, and it remains disabled in all other defconfigs since
it is a new option.

This reverts parts of commit commit 3f181b4 ("lib/Kconfig.debug:
disable -Wframe-larger-than warnings with KASAN=y").

I experimented a bit more with smaller stack frames and have another
follow-up series that reduces the warning limit for 64-bit architectures
to 1280 bytes and 1536 when CONFIG_KASAN (but not KASAN_EXTRA) is
enabled, this requires another ~25 patches to address the additional
warnings. I also have patches for all KASAN_EXTRA warnings, but we
should look at those separately and then decide whether to remove
it completely, leaving out -fsanitize-address-use-after-scope.

Signed-off-by: Arnd Bergmann 
---
 lib/Kconfig.debug  |  4 ++--
 lib/Kconfig.kasan  | 11 ++-
 lib/Kconfig.kmemcheck  |  1 +
 scripts/Makefile.kasan |  3 +++
 4 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index ddbef2cac189..02ec4a4da7b1 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -217,7 +217,7 @@ config ENABLE_MUST_CHECK
 config FRAME_WARN
int "Warn for stack frames larger than (needs gcc 4.4)"
range 0 8192
-   default 0 if KASAN
+   default 3072 if KASAN_EXTRA
default 2048 if GCC_PLUGIN_LATENT_ENTROPY
default 1024 if !64BIT
default 2048 if 64BIT
@@ -500,7 +500,7 @@ config DEBUG_OBJECTS_ENABLE_DEFAULT
 
 config DEBUG_SLAB
bool "Debug slab memory allocations"
-   depends on DEBUG_KERNEL && SLAB && !KMEMCHECK
+   depends on DEBUG_KERNEL && SLAB && !KMEMCHECK && !KASAN
help
  Say Y here to have the kernel do limited verification on memory
  allocation as well as poisoning memory on free to catch use of freed
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index bd38aab05929..4d17a8f4742f 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -5,7 +5,7 @@ if HAVE_ARCH_KASAN
 
 config KASAN
bool "KASan: runtime memory debugger"
-   depends on SLUB || (SLAB && !DEBUG_SLAB)
+   depends on SLUB || SLAB
select CONSTRUCTORS
select STACKDEPOT
help
@@ -20,6 +20,15 @@ config KASAN
  Currently CONFIG_KASAN doesn't work with CONFIG_DEBUG_SLAB
  (the resulting kernel does not boot).
 
+config KASAN_EXTRA
+   bool "KAsan: 

[PATCH v2 09/11] brcmsmac: split up wlc_phy_workarounds_nphy

2017-06-14 Thread Arnd Bergmann
The stack consumption in this driver is still relatively high, with one
remaining warning if the warning level is lowered to 1536 bytes:

drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: error: 
the frame size of 1880 bytes is larger than 1536 bytes 
[-Werror=frame-larger-than=]

The affected function is actually a collection of three separate 
implementations,
and each of them is fairly large by itself. Splitting them up is done easily
and improves readability at the same time.

I'm leaving the original indentation to make the review easier.

Acked-by: Arend van Spriel 
Signed-off-by: Arnd Bergmann 
---
 .../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 178 -
 1 file changed, 104 insertions(+), 74 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index ef685465f80a..ed409a80f3d2 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -16061,52 +16061,8 @@ static void wlc_phy_workarounds_nphy_gainctrl(struct 
brcms_phy *pi)
}
 }
 
-static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
+static void wlc_phy_workarounds_nphy_rev7(struct brcms_phy *pi)
 {
-   static const u8 rfseq_rx2tx_events[] = {
-   NPHY_RFSEQ_CMD_NOP,
-   NPHY_RFSEQ_CMD_RXG_FBW,
-   NPHY_RFSEQ_CMD_TR_SWITCH,
-   NPHY_RFSEQ_CMD_CLR_HIQ_DIS,
-   NPHY_RFSEQ_CMD_RXPD_TXPD,
-   NPHY_RFSEQ_CMD_TX_GAIN,
-   NPHY_RFSEQ_CMD_EXT_PA
-   };
-   u8 rfseq_rx2tx_dlys[] = { 8, 6, 6, 2, 4, 60, 1 };
-   static const u8 rfseq_tx2rx_events[] = {
-   NPHY_RFSEQ_CMD_NOP,
-   NPHY_RFSEQ_CMD_EXT_PA,
-   NPHY_RFSEQ_CMD_TX_GAIN,
-   NPHY_RFSEQ_CMD_RXPD_TXPD,
-   NPHY_RFSEQ_CMD_TR_SWITCH,
-   NPHY_RFSEQ_CMD_RXG_FBW,
-   NPHY_RFSEQ_CMD_CLR_HIQ_DIS
-   };
-   static const u8 rfseq_tx2rx_dlys[] = { 8, 6, 2, 4, 4, 6, 1 };
-   static const u8 rfseq_tx2rx_events_rev3[] = {
-   NPHY_REV3_RFSEQ_CMD_EXT_PA,
-   NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
-   NPHY_REV3_RFSEQ_CMD_TX_GAIN,
-   NPHY_REV3_RFSEQ_CMD_RXPD_TXPD,
-   NPHY_REV3_RFSEQ_CMD_TR_SWITCH,
-   NPHY_REV3_RFSEQ_CMD_RXG_FBW,
-   NPHY_REV3_RFSEQ_CMD_CLR_HIQ_DIS,
-   NPHY_REV3_RFSEQ_CMD_END
-   };
-   static const u8 rfseq_tx2rx_dlys_rev3[] = { 8, 4, 2, 2, 4, 4, 6, 1 };
-   u8 rfseq_rx2tx_events_rev3[] = {
-   NPHY_REV3_RFSEQ_CMD_NOP,
-   NPHY_REV3_RFSEQ_CMD_RXG_FBW,
-   NPHY_REV3_RFSEQ_CMD_TR_SWITCH,
-   NPHY_REV3_RFSEQ_CMD_CLR_HIQ_DIS,
-   NPHY_REV3_RFSEQ_CMD_RXPD_TXPD,
-   NPHY_REV3_RFSEQ_CMD_TX_GAIN,
-   NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
-   NPHY_REV3_RFSEQ_CMD_EXT_PA,
-   NPHY_REV3_RFSEQ_CMD_END
-   };
-   u8 rfseq_rx2tx_dlys_rev3[] = { 8, 6, 6, 4, 4, 18, 42, 1, 1 };
-
static const u8 rfseq_rx2tx_events_rev3_ipa[] = {
NPHY_REV3_RFSEQ_CMD_NOP,
NPHY_REV3_RFSEQ_CMD_RXG_FBW,
@@ -16120,29 +16076,15 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy 
*pi)
};
static const u8 rfseq_rx2tx_dlys_rev3_ipa[] = { 8, 6, 6, 4, 4, 16, 43, 
1, 1 };
static const u16 rfseq_rx2tx_dacbufpu_rev7[] = { 0x10f, 0x10f };
-
-   s16 alpha0, alpha1, alpha2;
-   s16 beta0, beta1, beta2;
-   u32 leg_data_weights, ht_data_weights, nss1_data_weights,
-   stbc_data_weights;
+   u32 leg_data_weights;
u8 chan_freq_range = 0;
static const u16 dac_control = 0x0002;
u16 aux_adc_vmid_rev7_core0[] = { 0x8e, 0x96, 0x96, 0x96 };
u16 aux_adc_vmid_rev7_core1[] = { 0x8f, 0x9f, 0x9f, 0x96 };
-   u16 aux_adc_vmid_rev4[] = { 0xa2, 0xb4, 0xb4, 0x89 };
-   u16 aux_adc_vmid_rev3[] = { 0xa2, 0xb4, 0xb4, 0x89 };
-   u16 *aux_adc_vmid;
u16 aux_adc_gain_rev7[] = { 0x02, 0x02, 0x02, 0x02 };
-   u16 aux_adc_gain_rev4[] = { 0x02, 0x02, 0x02, 0x00 };
-   u16 aux_adc_gain_rev3[] = { 0x02, 0x02, 0x02, 0x00 };
-   u16 *aux_adc_gain;
-   static const u16 sk_adc_vmid[] = { 0xb4, 0xb4, 0xb4, 0x24 };
-   static const u16 sk_adc_gain[] = { 0x02, 0x02, 0x02, 0x02 };
s32 min_nvar_val = 0x18d;
s32 min_nvar_offset_6mbps = 20;
u8 pdetrange;
-   u8 triso;
-   u16 regval;
u16 afectrl_adc_ctrl1_rev7 = 0x20;
u16 afectrl_adc_ctrl2_rev7 = 0x0;
u16 rfseq_rx2tx_lpf_h_hpc_rev7 = 0x77;
@@ -16171,17 +16113,6 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy 
*pi)
u16 freq;
int coreNum;
 
-   if (CHSPEC_IS5G(pi->radio_chanspec))
-   

[PATCH v2 10/11] brcmsmac: reindent split functions

2017-06-14 Thread Arnd Bergmann
In the previous commit I left the indentation alone to help reviewing
the patch, this one now runs the three new functions through 'indent -kr -8'
with some manual fixups to avoid silliness.

No changes other than whitespace are intended here.

Signed-off-by: Arnd Bergmann 
Acked-by: Arend van Spriel 
---
 .../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 1507 +---
 1 file changed, 697 insertions(+), 810 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index ed409a80f3d2..763e8ba6b178 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -16074,7 +16074,8 @@ static void wlc_phy_workarounds_nphy_rev7(struct 
brcms_phy *pi)
NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
NPHY_REV3_RFSEQ_CMD_END
};
-   static const u8 rfseq_rx2tx_dlys_rev3_ipa[] = { 8, 6, 6, 4, 4, 16, 43, 
1, 1 };
+   static const u8 rfseq_rx2tx_dlys_rev3_ipa[] =
+   { 8, 6, 6, 4, 4, 16, 43, 1, 1 };
static const u16 rfseq_rx2tx_dacbufpu_rev7[] = { 0x10f, 0x10f };
u32 leg_data_weights;
u8 chan_freq_range = 0;
@@ -16114,526 +16115,452 @@ static void wlc_phy_workarounds_nphy_rev7(struct 
brcms_phy *pi)
int coreNum;
 
 
-   if (NREV_IS(pi->pubpi.phy_rev, 7)) {
-   mod_phy_reg(pi, 0x221, (0x1 << 4), (1 << 4));
-
-   mod_phy_reg(pi, 0x160, (0x7f << 0), (32 << 0));
-   mod_phy_reg(pi, 0x160, (0x7f << 8), (39 << 8));
-   mod_phy_reg(pi, 0x161, (0x7f << 0), (46 << 0));
-   mod_phy_reg(pi, 0x161, (0x7f << 8), (51 << 8));
-   mod_phy_reg(pi, 0x162, (0x7f << 0), (55 << 0));
-   mod_phy_reg(pi, 0x162, (0x7f << 8), (58 << 8));
-   mod_phy_reg(pi, 0x163, (0x7f << 0), (60 << 0));
-   mod_phy_reg(pi, 0x163, (0x7f << 8), (62 << 8));
-   mod_phy_reg(pi, 0x164, (0x7f << 0), (62 << 0));
-   mod_phy_reg(pi, 0x164, (0x7f << 8), (63 << 8));
-   mod_phy_reg(pi, 0x165, (0x7f << 0), (63 << 0));
-   mod_phy_reg(pi, 0x165, (0x7f << 8), (64 << 8));
-   mod_phy_reg(pi, 0x166, (0x7f << 0), (64 << 0));
-   mod_phy_reg(pi, 0x166, (0x7f << 8), (64 << 8));
-   mod_phy_reg(pi, 0x167, (0x7f << 0), (64 << 0));
-   mod_phy_reg(pi, 0x167, (0x7f << 8), (64 << 8));
-   }
-
-   if (NREV_LE(pi->pubpi.phy_rev, 8)) {
-   write_phy_reg(pi, 0x23f, 0x1b0);
-   write_phy_reg(pi, 0x240, 0x1b0);
-   }
+   if (NREV_IS(pi->pubpi.phy_rev, 7)) {
+   mod_phy_reg(pi, 0x221, (0x1 << 4), (1 << 4));
+
+   mod_phy_reg(pi, 0x160, (0x7f << 0), (32 << 0));
+   mod_phy_reg(pi, 0x160, (0x7f << 8), (39 << 8));
+   mod_phy_reg(pi, 0x161, (0x7f << 0), (46 << 0));
+   mod_phy_reg(pi, 0x161, (0x7f << 8), (51 << 8));
+   mod_phy_reg(pi, 0x162, (0x7f << 0), (55 << 0));
+   mod_phy_reg(pi, 0x162, (0x7f << 8), (58 << 8));
+   mod_phy_reg(pi, 0x163, (0x7f << 0), (60 << 0));
+   mod_phy_reg(pi, 0x163, (0x7f << 8), (62 << 8));
+   mod_phy_reg(pi, 0x164, (0x7f << 0), (62 << 0));
+   mod_phy_reg(pi, 0x164, (0x7f << 8), (63 << 8));
+   mod_phy_reg(pi, 0x165, (0x7f << 0), (63 << 0));
+   mod_phy_reg(pi, 0x165, (0x7f << 8), (64 << 8));
+   mod_phy_reg(pi, 0x166, (0x7f << 0), (64 << 0));
+   mod_phy_reg(pi, 0x166, (0x7f << 8), (64 << 8));
+   mod_phy_reg(pi, 0x167, (0x7f << 0), (64 << 0));
+   mod_phy_reg(pi, 0x167, (0x7f << 8), (64 << 8));
+   }
 
-   if (NREV_GE(pi->pubpi.phy_rev, 8))
-   mod_phy_reg(pi, 0xbd, (0xff << 0), (114 << 0));
+   if (NREV_LE(pi->pubpi.phy_rev, 8)) {
+   write_phy_reg(pi, 0x23f, 0x1b0);
+   write_phy_reg(pi, 0x240, 0x1b0);
+   }
 
-   wlc_phy_table_write_nphy(pi, NPHY_TBL_ID_AFECTRL, 1, 0x00, 16,
-_control);
-   wlc_phy_table_write_nphy(pi, NPHY_TBL_ID_AFECTRL, 1, 0x10, 16,
-_control);
+   if (NREV_GE(pi->pubpi.phy_rev, 8))
+   mod_phy_reg(pi, 0xbd, (0xff << 0), (114 << 0));
 
-   wlc_phy_table_read_nphy(pi, NPHY_TBL_ID_CMPMETRICDATAWEIGHTTBL,
-   1, 0, 32, _data_weights);
-   leg_data_weights = leg_data_weights & 0xff;
-   wlc_phy_table_write_nphy(pi, NPHY_TBL_ID_CMPMETRICDATAWEIGHTTBL,
-  

[PATCH v2 08/11] brcmsmac: make some local variables 'static const' to reduce stack size

2017-06-14 Thread Arnd Bergmann
With KASAN and a couple of other patches applied, this driver is one
of the few remaining ones that actually use more than 2048 bytes of
kernel stack:

broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 
'wlc_phy_workarounds_nphy_gainctrl':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:16065:1: warning: the frame size of 
3264 bytes is larger than 2048 bytes [-Wframe-larger-than=]
broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:17138:1: warning: the frame size of 
2864 bytes is larger than 2048 bytes [-Wframe-larger-than=]

Here, I'm reducing the stack size by marking as many local variables as
'static const' as I can without changing the actual code.

Acked-by: Arend van Spriel 
Signed-off-by: Arnd Bergmann 
---
 .../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 197 ++---
 1 file changed, 97 insertions(+), 100 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index b3aab2fe96eb..ef685465f80a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -14764,8 +14764,8 @@ static void 
wlc_phy_ipa_restore_tx_digi_filts_nphy(struct brcms_phy *pi)
 }
 
 static void
-wlc_phy_set_rfseq_nphy(struct brcms_phy *pi, u8 cmd, u8 *events, u8 *dlys,
-  u8 len)
+wlc_phy_set_rfseq_nphy(struct brcms_phy *pi, u8 cmd, const u8 *events,
+  const u8 *dlys, u8 len)
 {
u32 t1_offset, t2_offset;
u8 ctr;
@@ -15240,16 +15240,16 @@ static void 
wlc_phy_workarounds_nphy_gainctrl_2057_rev5(struct brcms_phy *pi)
 static void wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
 {
u16 currband;
-   s8 lna1G_gain_db_rev7[] = { 9, 14, 19, 24 };
-   s8 *lna1_gain_db = NULL;
-   s8 *lna1_gain_db_2 = NULL;
-   s8 *lna2_gain_db = NULL;
-   s8 tiaA_gain_db_rev7[] = { -9, -6, -3, 0, 3, 3, 3, 3, 3, 3 };
-   s8 *tia_gain_db;
-   s8 tiaA_gainbits_rev7[] = { 0, 1, 2, 3, 4, 4, 4, 4, 4, 4 };
-   s8 *tia_gainbits;
-   u16 rfseqA_init_gain_rev7[] = { 0x624f, 0x624f };
-   u16 *rfseq_init_gain;
+   static const s8 lna1G_gain_db_rev7[] = { 9, 14, 19, 24 };
+   const s8 *lna1_gain_db = NULL;
+   const s8 *lna1_gain_db_2 = NULL;
+   const s8 *lna2_gain_db = NULL;
+   static const s8 tiaA_gain_db_rev7[] = { -9, -6, -3, 0, 3, 3, 3, 3, 3, 3 
};
+   const s8 *tia_gain_db;
+   static const s8 tiaA_gainbits_rev7[] = { 0, 1, 2, 3, 4, 4, 4, 4, 4, 4 };
+   const s8 *tia_gainbits;
+   static const u16 rfseqA_init_gain_rev7[] = { 0x624f, 0x624f };
+   const u16 *rfseq_init_gain;
u16 init_gaincode;
u16 clip1hi_gaincode;
u16 clip1md_gaincode = 0;
@@ -15310,10 +15310,9 @@ static void 
wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
 
if ((freq <= 5080) || (freq == 5825)) {
 
-   s8 lna1A_gain_db_rev7[] = { 11, 16, 20, 24 };
-   s8 lna1A_gain_db_2_rev7[] = {
-   11, 17, 22, 25};
-   s8 lna2A_gain_db_rev7[] = { -1, 6, 10, 14 };
+   static const s8 lna1A_gain_db_rev7[] = { 11, 
16, 20, 24 };
+   static const s8 lna1A_gain_db_2_rev7[] = { 11, 
17, 22, 25};
+   static const s8 lna2A_gain_db_rev7[] = { -1, 6, 
10, 14 };
 
crsminu_th = 0x3e;
lna1_gain_db = lna1A_gain_db_rev7;
@@ -15321,10 +15320,9 @@ static void 
wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
lna2_gain_db = lna2A_gain_db_rev7;
} else if ((freq >= 5500) && (freq <= 5700)) {
 
-   s8 lna1A_gain_db_rev7[] = { 11, 17, 21, 25 };
-   s8 lna1A_gain_db_2_rev7[] = {
-   12, 18, 22, 26};
-   s8 lna2A_gain_db_rev7[] = { 1, 8, 12, 16 };
+   static const s8 lna1A_gain_db_rev7[] = { 11, 
17, 21, 25 };
+   static const s8 lna1A_gain_db_2_rev7[] = { 12, 
18, 22, 26};
+   static const s8 lna2A_gain_db_rev7[] = { 1, 8, 
12, 16 };
 
crsminu_th = 0x45;
clip1md_gaincode_B = 0x14;
@@ -15335,10 +15333,9 @@ static void 
wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
lna2_gain_db = lna2A_gain_db_rev7;
} else {
 
-   s8 lna1A_gain_db_rev7[] = { 12, 18, 22, 26 };
-   s8 

[PATCH v2 07/11] r820t: mark register functions as noinline_if_stackbloat

2017-06-14 Thread Arnd Bergmann
With KASAN, we get an overly long stack frame due to inlining
the register access function:

drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7':
drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is 
larger than 2048 bytes [-Werror=frame-larger-than=]

An earlier patch I tried used an open-coded r820t_write_reg()
implementation that may have been more efficent, while this
version simply adds the annotation, which has a lower risk for
regressions.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/tuners/r820t.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/tuners/r820t.c b/drivers/media/tuners/r820t.c
index ba80376a3b86..a26d0eb64555 100644
--- a/drivers/media/tuners/r820t.c
+++ b/drivers/media/tuners/r820t.c
@@ -396,7 +396,7 @@ static int r820t_write(struct r820t_priv *priv, u8 reg, 
const u8 *val,
return 0;
 }
 
-static int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val)
+static noinline_if_stackbloat int r820t_write_reg(struct r820t_priv *priv, u8 
reg, u8 val)
 {
return r820t_write(priv, reg, , 1);
 }
@@ -411,7 +411,7 @@ static int r820t_read_cache_reg(struct r820t_priv *priv, 
int reg)
return -EINVAL;
 }
 
-static int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val,
+static noinline_if_stackbloat int r820t_write_reg_mask(struct r820t_priv 
*priv, u8 reg, u8 val,
u8 bit_mask)
 {
int rc = r820t_read_cache_reg(priv, reg);
-- 
2.9.0



[PATCH v2 06/11] dvb-frontends: reduce stack size in i2c access

2017-06-14 Thread Arnd Bergmann
A typical code fragment was copied across many dvb-frontend
drivers and causes large stack frames when built with
-fsanitize-address-use-after-scope, e.g.

drivers/media/dvb-frontends/cxd2841er.c:3225:1: error: the frame size of 3992 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/cxd2841er.c:3404:1: error: the frame size of 3136 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv0367.c:3143:1: error: the frame size of 4016 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv090x.c:4248:1: error: the frame size of 4872 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]

By marking the register access functions as noinline_if_stackbloat,
we can completely avoid this problem.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/dvb-frontends/ascot2e.c   |  3 ++-
 drivers/media/dvb-frontends/cxd2841er.c |  4 ++--
 drivers/media/dvb-frontends/drx39xyj/drxj.c | 14 +++---
 drivers/media/dvb-frontends/helene.c|  4 ++--
 drivers/media/dvb-frontends/horus3a.c   |  2 +-
 drivers/media/dvb-frontends/itd1000.c   |  2 +-
 drivers/media/dvb-frontends/mt312.c |  2 +-
 drivers/media/dvb-frontends/si2165.c| 14 +++---
 drivers/media/dvb-frontends/stb0899_drv.c   |  2 +-
 drivers/media/dvb-frontends/stb6100.c   |  2 +-
 drivers/media/dvb-frontends/stv0367.c   |  2 +-
 drivers/media/dvb-frontends/stv090x.c   |  2 +-
 drivers/media/dvb-frontends/stv6110.c   |  2 +-
 drivers/media/dvb-frontends/stv6110x.c  |  2 +-
 drivers/media/dvb-frontends/tda8083.c   |  2 +-
 drivers/media/dvb-frontends/zl10039.c   |  2 +-
 16 files changed, 31 insertions(+), 30 deletions(-)

diff --git a/drivers/media/dvb-frontends/ascot2e.c 
b/drivers/media/dvb-frontends/ascot2e.c
index 0ee0df53b91b..da1d1fc03c5e 100644
--- a/drivers/media/dvb-frontends/ascot2e.c
+++ b/drivers/media/dvb-frontends/ascot2e.c
@@ -153,7 +153,8 @@ static int ascot2e_write_regs(struct ascot2e_priv *priv,
return 0;
 }
 
-static int ascot2e_write_reg(struct ascot2e_priv *priv, u8 reg, u8 val)
+static noinline_if_stackbloat int ascot2e_write_reg(struct ascot2e_priv *priv,
+   u8 reg, u8 val)
 {
return ascot2e_write_regs(priv, reg, , 1);
 }
diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
b/drivers/media/dvb-frontends/cxd2841er.c
index ce37dc2e89c7..6b851a948ce0 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -258,7 +258,7 @@ static int cxd2841er_write_regs(struct cxd2841er_priv *priv,
return 0;
 }
 
-static int cxd2841er_write_reg(struct cxd2841er_priv *priv,
+static noinline_if_stackbloat int cxd2841er_write_reg(struct cxd2841er_priv 
*priv,
   u8 addr, u8 reg, u8 val)
 {
return cxd2841er_write_regs(priv, addr, reg, , 1);
@@ -306,7 +306,7 @@ static int cxd2841er_read_regs(struct cxd2841er_priv *priv,
return 0;
 }
 
-static int cxd2841er_read_reg(struct cxd2841er_priv *priv,
+static noinline_if_stackbloat int cxd2841er_read_reg(struct cxd2841er_priv 
*priv,
  u8 addr, u8 reg, u8 *val)
 {
return cxd2841er_read_regs(priv, addr, reg, val, 1);
diff --git a/drivers/media/dvb-frontends/drx39xyj/drxj.c 
b/drivers/media/dvb-frontends/drx39xyj/drxj.c
index 14040c915dbb..ec5b13ca630b 100644
--- a/drivers/media/dvb-frontends/drx39xyj/drxj.c
+++ b/drivers/media/dvb-frontends/drx39xyj/drxj.c
@@ -1516,7 +1516,7 @@ static int drxdap_fasi_read_block(struct i2c_device_addr 
*dev_addr,
 *
 **/
 
-static int drxdap_fasi_read_reg16(struct i2c_device_addr *dev_addr,
+static noinline_if_stackbloat int drxdap_fasi_read_reg16(struct 
i2c_device_addr *dev_addr,
 u32 addr,
 u16 *data, u32 flags)
 {
@@ -1549,7 +1549,7 @@ static int drxdap_fasi_read_reg16(struct i2c_device_addr 
*dev_addr,
 *
 **/
 
-static int drxdap_fasi_read_reg32(struct i2c_device_addr *dev_addr,
+static noinline_if_stackbloat int drxdap_fasi_read_reg32(struct 
i2c_device_addr *dev_addr,
 u32 addr,
 u32 *data, u32 flags)
 {
@@ -1722,7 +1722,7 @@ static int drxdap_fasi_write_block(struct i2c_device_addr 
*dev_addr,
 *
 **/
 
-static int drxdap_fasi_write_reg16(struct i2c_device_addr *dev_addr,
+static noinline_if_stackbloat int drxdap_fasi_write_reg16(struct 
i2c_device_addr *dev_addr,
  u32 addr,
  u16 data, u32 flags)
 {
@@ -1795,7 +1795,7 @@ static 

[PATCH v2 05/11] mtd: cfi: reduce stack size with KASAN

2017-06-14 Thread Arnd Bergmann
When CONFIG_KASAN is used, we consume a lot of extra stack space:

drivers/mtd/chips/cfi_cmdset_0020.c: In function 'do_write_buffer':
drivers/mtd/chips/cfi_cmdset_0020.c:603:1: error: the frame size of 2184 bytes 
is larger than 1536 bytes [-Werror=frame-larger-than=]
drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_erase_varsize':
drivers/mtd/chips/cfi_cmdset_0020.c:972:1: error: the frame size of 1936 bytes 
is larger than 1536 bytes [-Werror=frame-larger-than=]
drivers/mtd/chips/cfi_cmdset_0001.c: In function 'do_write_buffer':
drivers/mtd/chips/cfi_cmdset_0001.c:1841:1: error: the frame size of 1776 bytes 
is larger than 1536 bytes [-Werror=frame-larger-than=]

This marks some functions as noinline_if_stackbloat to keep reduce the
overall stack size.

Signed-off-by: Arnd Bergmann 
---
 drivers/mtd/chips/cfi_cmdset_0020.c | 8 
 include/linux/mtd/map.h | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0020.c 
b/drivers/mtd/chips/cfi_cmdset_0020.c
index 7d342965f392..5eee5e883f55 100644
--- a/drivers/mtd/chips/cfi_cmdset_0020.c
+++ b/drivers/mtd/chips/cfi_cmdset_0020.c
@@ -244,7 +244,7 @@ static struct mtd_info *cfi_staa_setup(struct map_info *map)
 }
 
 
-static inline int do_read_onechip(struct map_info *map, struct flchip *chip, 
loff_t adr, size_t len, u_char *buf)
+static noinline_if_stackbloat int do_read_onechip(struct map_info *map, struct 
flchip *chip, loff_t adr, size_t len, u_char *buf)
 {
map_word status, status_OK;
unsigned long timeo;
@@ -728,7 +728,7 @@ cfi_staa_writev(struct mtd_info *mtd, const struct kvec 
*vecs,
 }
 
 
-static inline int do_erase_oneblock(struct map_info *map, struct flchip *chip, 
unsigned long adr)
+static noinline_if_stackbloat int do_erase_oneblock(struct map_info *map, 
struct flchip *chip, unsigned long adr)
 {
struct cfi_private *cfi = map->fldrv_priv;
map_word status, status_OK;
@@ -1029,7 +1029,7 @@ static void cfi_staa_sync (struct mtd_info *mtd)
}
 }
 
-static inline int do_lock_oneblock(struct map_info *map, struct flchip *chip, 
unsigned long adr)
+static noinline_if_stackbloat int do_lock_oneblock(struct map_info *map, 
struct flchip *chip, unsigned long adr)
 {
struct cfi_private *cfi = map->fldrv_priv;
map_word status, status_OK;
@@ -1175,7 +1175,7 @@ static int cfi_staa_lock(struct mtd_info *mtd, loff_t 
ofs, uint64_t len)
}
return 0;
 }
-static inline int do_unlock_oneblock(struct map_info *map, struct flchip 
*chip, unsigned long adr)
+static noinline_if_stackbloat int do_unlock_oneblock(struct map_info *map, 
struct flchip *chip, unsigned long adr)
 {
struct cfi_private *cfi = map->fldrv_priv;
map_word status, status_OK;
diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h
index 3aa56e3104bb..29db74314db8 100644
--- a/include/linux/mtd/map.h
+++ b/include/linux/mtd/map.h
@@ -316,7 +316,7 @@ static inline map_word map_word_or(struct map_info *map, 
map_word val1, map_word
return r;
 }
 
-static inline int map_word_andequal(struct map_info *map, map_word val1, 
map_word val2, map_word val3)
+static noinline_if_stackbloat int map_word_andequal(struct map_info *map, 
map_word val1, map_word val2, map_word val3)
 {
int i;
 
@@ -328,7 +328,7 @@ static inline int map_word_andequal(struct map_info *map, 
map_word val1, map_wor
return 1;
 }
 
-static inline int map_word_bitsset(struct map_info *map, map_word val1, 
map_word val2)
+static noinline_if_stackbloat int map_word_bitsset(struct map_info *map, 
map_word val1, map_word val2)
 {
int i;
 
@@ -362,7 +362,7 @@ static inline map_word map_word_load(struct map_info *map, 
const void *ptr)
return r;
 }
 
-static inline map_word map_word_load_partial(struct map_info *map, map_word 
orig, const unsigned char *buf, int start, int len)
+static noinline_if_stackbloat map_word map_word_load_partial(struct map_info 
*map, map_word orig, const unsigned char *buf, int start, int len)
 {
int i;
 
@@ -392,7 +392,7 @@ static inline map_word map_word_load_partial(struct 
map_info *map, map_word orig
 #define MAP_FF_LIMIT 8
 #endif
 
-static inline map_word map_word_ff(struct map_info *map)
+static noinline_if_stackbloat map_word map_word_ff(struct map_info *map)
 {
map_word r;
int i;
-- 
2.9.0


From reviews-return-15279-archive=mail-archive@impala.incubator.apache.org 
Wed Jun 14 14:20:27 2017
Return-path: 

[PATCH v2 03/11] tty: kbd: reduce stack size with KASAN

2017-06-14 Thread Arnd Bergmann
As reported by kernelci, some functions in the VT code use significant
amounts of kernel stack when local variables get inlined into the caller
multiple times:

drivers/tty/vt/keyboard.c: In function 'kbd_keycode':
drivers/tty/vt/keyboard.c:1452:1: error: the frame size of 2240 bytes is larger 
than 2048 bytes [-Werror=frame-larger-than=]

Annotating those functions as noinline_if_stackbloat prevents the inlining
and reduces the overall stack usage in this driver.

Signed-off-by: Arnd Bergmann 
---
 drivers/tty/vt/keyboard.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index f4166263bb3a..c0d111444a0e 100644
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -301,13 +301,13 @@ int kbd_rate(struct kbd_repeat *rpt)
 /*
  * Helper Functions.
  */
-static void put_queue(struct vc_data *vc, int ch)
+static noinline_if_stackbloat void put_queue(struct vc_data *vc, int ch)
 {
tty_insert_flip_char(>port, ch, 0);
tty_schedule_flip(>port);
 }
 
-static void puts_queue(struct vc_data *vc, char *cp)
+static noinline_if_stackbloat void puts_queue(struct vc_data *vc, char *cp)
 {
while (*cp) {
tty_insert_flip_char(>port, *cp, 0);
@@ -555,7 +555,7 @@ static void fn_inc_console(struct vc_data *vc)
set_console(i);
 }
 
-static void fn_send_intr(struct vc_data *vc)
+static noinline_if_stackbloat void fn_send_intr(struct vc_data *vc)
 {
tty_insert_flip_char(>port, 0, TTY_BREAK);
tty_schedule_flip(>port);
-- 
2.9.0



[PATCH v2 04/11] rocker: mark rocker_tlv_put_* functions as noinline_if_stackbloat

2017-06-14 Thread Arnd Bergmann
Inlining these functions creates lots of stack variables when KASAN is
enabled, leading to this warning about potential stack overflow:

drivers/net/ethernet/rocker/rocker_ofdpa.c: In function 
'ofdpa_cmd_flow_tbl_add':
drivers/net/ethernet/rocker/rocker_ofdpa.c:621:1: error: the frame size of 2752 
bytes is larger than 1536 bytes [-Werror=frame-larger-than=]

This marks all of them noinline_if_stackbloat, which solves the problem by
keeping the redzone inside of the separate stack frames.

Signed-off-by: Arnd Bergmann 
---
 drivers/net/ethernet/rocker/rocker_tlv.h | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/rocker/rocker_tlv.h 
b/drivers/net/ethernet/rocker/rocker_tlv.h
index a63ef82e7c72..8970a414eb5b 100644
--- a/drivers/net/ethernet/rocker/rocker_tlv.h
+++ b/drivers/net/ethernet/rocker/rocker_tlv.h
@@ -139,38 +139,38 @@ rocker_tlv_start(struct rocker_desc_info *desc_info)
 int rocker_tlv_put(struct rocker_desc_info *desc_info,
   int attrtype, int attrlen, const void *data);
 
-static inline int rocker_tlv_put_u8(struct rocker_desc_info *desc_info,
-   int attrtype, u8 value)
+static noinline_if_stackbloat int
+rocker_tlv_put_u8(struct rocker_desc_info *desc_info, int attrtype, u8 value)
 {
return rocker_tlv_put(desc_info, attrtype, sizeof(u8), );
 }
 
-static inline int rocker_tlv_put_u16(struct rocker_desc_info *desc_info,
-int attrtype, u16 value)
+static noinline_if_stackbloat int
+rocker_tlv_put_u16(struct rocker_desc_info *desc_info, int attrtype, u16 value)
 {
return rocker_tlv_put(desc_info, attrtype, sizeof(u16), );
 }
 
-static inline int rocker_tlv_put_be16(struct rocker_desc_info *desc_info,
- int attrtype, __be16 value)
+static noinline_if_stackbloat int
+rocker_tlv_put_be16(struct rocker_desc_info *desc_info, int attrtype, __be16 
value)
 {
return rocker_tlv_put(desc_info, attrtype, sizeof(__be16), );
 }
 
-static inline int rocker_tlv_put_u32(struct rocker_desc_info *desc_info,
-int attrtype, u32 value)
+static noinline_if_stackbloat int
+rocker_tlv_put_u32(struct rocker_desc_info *desc_info, int attrtype, u32 value)
 {
return rocker_tlv_put(desc_info, attrtype, sizeof(u32), );
 }
 
-static inline int rocker_tlv_put_be32(struct rocker_desc_info *desc_info,
- int attrtype, __be32 value)
+static noinline_if_stackbloat int
+rocker_tlv_put_be32(struct rocker_desc_info *desc_info, int attrtype, __be32 
value)
 {
return rocker_tlv_put(desc_info, attrtype, sizeof(__be32), );
 }
 
-static inline int rocker_tlv_put_u64(struct rocker_desc_info *desc_info,
-int attrtype, u64 value)
+static noinline_if_stackbloat int
+rocker_tlv_put_u64(struct rocker_desc_info *desc_info, int attrtype, u64 value)
 {
return rocker_tlv_put(desc_info, attrtype, sizeof(u64), );
 }
-- 
2.9.0



[PATCH v2 02/11] netlink: mark nla_put_{u8,u16,u32} noinline_if_stackbloat

2017-06-14 Thread Arnd Bergmann
When CONFIG_KASAN is enabled, the "--param asan-stack=1" causes rather large
stack frames in some functions. This goes unnoticed normally because
CONFIG_FRAME_WARN is disabled with CONFIG_KASAN by default as of commit
3f181b4d8652 ("lib/Kconfig.debug: disable -Wframe-larger-than warnings with
KASAN=y").

The kernelci.org build bot however has the warning enabled and that led
me to investigate it a little further, as every build produces these warnings:

net/wireless/nl80211.c:4389:1: warning: the frame size of 2240 bytes is larger 
than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:1895:1: warning: the frame size of 3776 bytes is larger 
than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:1410:1: warning: the frame size of 2208 bytes is larger 
than 2048 bytes [-Wframe-larger-than=]
net/bridge/br_netlink.c:1282:1: warning: the frame size of 2544 bytes is larger 
than 2048 bytes [-Wframe-larger-than=]

With the new noinline_if_stackbloat annotation, we can avoid the problem
when KASAN is enabled but not change anything otherwise.

Cc: Andrey Ryabinin 
Cc: Alexander Potapenko 
Cc: Dmitry Vyukov 
Cc: kasan-...@googlegroups.com
Signed-off-by: Arnd Bergmann 
---
 include/net/netlink.h | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/include/net/netlink.h b/include/net/netlink.h
index 01709172b3d3..24b4badd6eaf 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -766,7 +766,7 @@ static inline int nla_parse_nested(struct nlattr *tb[], int 
maxtype,
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_u8(struct sk_buff *skb, int attrtype, u8 value)
+static noinline_if_stackbloat int nla_put_u8(struct sk_buff *skb, int 
attrtype, u8 value)
 {
return nla_put(skb, attrtype, sizeof(u8), );
 }
@@ -777,7 +777,7 @@ static inline int nla_put_u8(struct sk_buff *skb, int 
attrtype, u8 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_u16(struct sk_buff *skb, int attrtype, u16 value)
+static noinline_if_stackbloat int nla_put_u16(struct sk_buff *skb, int 
attrtype, u16 value)
 {
return nla_put(skb, attrtype, sizeof(u16), );
 }
@@ -788,7 +788,7 @@ static inline int nla_put_u16(struct sk_buff *skb, int 
attrtype, u16 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_be16(struct sk_buff *skb, int attrtype, __be16 value)
+static noinline_if_stackbloat int nla_put_be16(struct sk_buff *skb, int 
attrtype, __be16 value)
 {
return nla_put(skb, attrtype, sizeof(__be16), );
 }
@@ -799,7 +799,7 @@ static inline int nla_put_be16(struct sk_buff *skb, int 
attrtype, __be16 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_net16(struct sk_buff *skb, int attrtype, __be16 
value)
+static noinline_if_stackbloat int nla_put_net16(struct sk_buff *skb, int 
attrtype, __be16 value)
 {
return nla_put_be16(skb, attrtype | NLA_F_NET_BYTEORDER, value);
 }
@@ -810,7 +810,7 @@ static inline int nla_put_net16(struct sk_buff *skb, int 
attrtype, __be16 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_le16(struct sk_buff *skb, int attrtype, __le16 value)
+static noinline_if_stackbloat int nla_put_le16(struct sk_buff *skb, int 
attrtype, __le16 value)
 {
return nla_put(skb, attrtype, sizeof(__le16), );
 }
@@ -821,7 +821,7 @@ static inline int nla_put_le16(struct sk_buff *skb, int 
attrtype, __le16 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_u32(struct sk_buff *skb, int attrtype, u32 value)
+static noinline_if_stackbloat int nla_put_u32(struct sk_buff *skb, int 
attrtype, u32 value)
 {
return nla_put(skb, attrtype, sizeof(u32), );
 }
@@ -832,7 +832,7 @@ static inline int nla_put_u32(struct sk_buff *skb, int 
attrtype, u32 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_be32(struct sk_buff *skb, int attrtype, __be32 value)
+static noinline_if_stackbloat int nla_put_be32(struct sk_buff *skb, int 
attrtype, __be32 value)
 {
return nla_put(skb, attrtype, sizeof(__be32), );
 }
@@ -843,7 +843,7 @@ static inline int nla_put_be32(struct sk_buff *skb, int 
attrtype, __be32 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_net32(struct sk_buff *skb, int attrtype, __be32 
value)
+static noinline_if_stackbloat int nla_put_net32(struct sk_buff *skb, int 
attrtype, __be32 value)
 {
return nla_put_be32(skb, attrtype | NLA_F_NET_BYTEORDER, value);
 }
@@ -854,7 +854,7 @@ static inline int nla_put_net32(struct sk_buff *skb, int 
attrtype, __be32 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_le32(struct sk_buff *skb, int attrtype, __le32 

Re: [PATCH] skbuff: make skb_put_zero() return void

2017-06-14 Thread Joe Perches
On Wed, 2017-06-14 at 22:40 +0200, Johannes Berg wrote:
> On Wed, 2017-06-14 at 13:36 -0700, Joe Perches wrote:
> > 
> > Given you are adding a lot of these, it might be better
> > to add an exported function that duplicates most of
> > skb_put with a memset at the end.
> 
> Yeah, could be done. I'm not sure why you'd want to duplicate it rather
> than call it though? To make it about as fast?

Yeah, that and reduced stack use.

Dunno how performance sensitive these uses really are
but it seems some might be for slow cpu wireless APs in
both the rx and tx paths.



[PATCH v2 01/11] compiler: introduce noinline_if_stackbloat annotation

2017-06-14 Thread Arnd Bergmann
When CONFIG_KASAN is set, we can run into some code that uses incredible
amounts of kernel stack:

drivers/staging/dgnc/dgnc_neo.c:1056:1: error: the frame size of 2 bytes is 
larger than 2048 bytes [-Werror=frame-larger-than=]
drivers/media/i2c/cx25840/cx25840-core.c:4960:1: error: the frame size of 94000 
bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]

This happens when a sanitizer uses stack memory each time an inline function
gets called. This introduces a new annotation for those functions to make
them either 'inline' or 'noinline' depending on the CONFIG_KASAN symbol.

Signed-off-by: Arnd Bergmann 
---
 include/linux/compiler.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 219f82f3ec1a..a402c43c07d2 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -412,6 +412,17 @@ static __always_inline void __write_once_size(volatile 
void *p, void *res, int s
  */
 #define noinline_for_stack noinline
 
+/*
+ * CONFIG_KASAN can lead to extreme stack usage with certain patterns when
+ * one function gets inlined many times and each instance requires a stack
+ * ckeck.
+ */
+#ifdef CONFIG_KASAN
+#define noinline_if_stackbloat noinline __maybe_unused
+#else
+#define noinline_if_stackbloat inline
+#endif
+
 #ifndef __always_inline
 #define __always_inline inline
 #endif
-- 
2.9.0



[PATCH v2 00/11] bring back stack frame warning with KASAN

2017-06-14 Thread Arnd Bergmann
This is a new version of patches I originally submitted back in
March [1], this time reducing the size of the series even further.

This minimal set of patches only makes sure that we do get
frame size warnings in allmodconfig for x86_64 and arm64 again,
even with KASAN enabled.

The changes this time are reduced to:

- I'm introducing "noinline_if_stackbloat" and use it in a number
  of places that suffer from inline functions with local variables
  - netlink, as used in various parts of the kernel
  - a number of drivers/media drivers
  - a handful of wireless network drivers
- a rework for the brcmsmac driver
- -fsanitize-address-use-after-scope is moved to a separate
  CONFIG_KASAN_EXTRA option that increases the warning limit
- CONFIG_KASAN_EXTRA is disabled with CONFIG_COMPILE_TEST,
  improving compile speed and disabling code that leads to
  valid warnings on gcc-7.0.1
- kmemcheck conflicts with CONFIG_KASAN_EXTRA

Compared to the previous version, I no longer have patches
to fix all the CONFIG_KASAN_EXTRA warnings:

- READ_ONCE/WRITE_ONCE cause problems in lots of code
- typecheck() causes huge problems in a few places
- many more uses of noinline_if_stackbloat

This series lets us add back a stack frame warning for the regular
2048 bytes without CONFIG_KASAN_EXTRA. I set the warning limit with
KASAN_EXTRA to 3072, since I have an additional set of patches
to address all files that surpass that limit. We can debate whether
we want to apply those as a follow-up, or instead remove the option
entirely.

Another follow-up series I have reduces the warning limit with
KASAN to 1536, and without KASAN to 1280 for 64-bit architectures.

I hope that Andrew can pick up the entire series for mmotm, and
we can eventually backport most of it to stable kernels and
address the warnings that kernelci still reports for this problem [2].

 Arnd

[1] https://lkml.org/lkml/2017/3/2/508
[2] https://kernelci.org/build/id/593f89a659b51463306b958d/logs/

 kasan: rework Kconfig settings
 brcmsmac: reindent split functions
 brcmsmac: split up wlc_phy_workarounds_nphy
 brcmsmac: make some local variables 'static const' to reduce stack size
 r820t: mark register functions as noinline_if_stackbloat
 dvb-frontends: reduce stack size in i2c access
 mtd: cfi: reduce stack size with KASAN
 rocker: mark rocker_tlv_put_* functions as noinline_if_stackbloat
 tty: kbd: reduce stack size with KASAN
 netlink: mark nla_put_{u8,u16,u32} noinline_if_stackbloat
 compiler: introduce noinline_if_stackbloat annotation

Arnd Bergmann (11):
 drivers/media/dvb-frontends/ascot2e.c|3 +-
 drivers/media/dvb-frontends/cxd2841er.c  |4 +-
 drivers/media/dvb-frontends/drx39xyj/drxj.c  |   14 +-
 drivers/media/dvb-frontends/helene.c |4 +-
 drivers/media/dvb-frontends/horus3a.c|2 +-
 drivers/media/dvb-frontends/itd1000.c|2 +-
 drivers/media/dvb-frontends/mt312.c  |2 +-
 drivers/media/dvb-frontends/si2165.c |   14 +-
 drivers/media/dvb-frontends/stb0899_drv.c|2 +-
 drivers/media/dvb-frontends/stb6100.c|2 +-
 drivers/media/dvb-frontends/stv0367.c|2 +-
 drivers/media/dvb-frontends/stv090x.c|2 +-
 drivers/media/dvb-frontends/stv6110.c|2 +-
 drivers/media/dvb-frontends/stv6110x.c   |2 +-
 drivers/media/dvb-frontends/tda8083.c|2 +-
 drivers/media/dvb-frontends/zl10039.c|2 +-
 drivers/media/tuners/r820t.c |4 +-
 drivers/mtd/chips/cfi_cmdset_0020.c  |8 +-
 drivers/net/ethernet/rocker/rocker_tlv.h |   24 +-
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c | 1856 
+++-
 drivers/tty/vt/keyboard.c|6 +-
 include/linux/compiler.h |   11 +
 include/linux/mtd/map.h  |8 +-
 include/net/netlink.h|   36 +-
 lib/Kconfig.debug|4 +-
 lib/Kconfig.kasan|   11 +-
 lib/Kconfig.kmemcheck|1 +
 scripts/Makefile.kasan   |3 +
 28 files changed, 986 insertions(+), 1047 deletions(-)

-- 
2.9.0



Re: [PATCH net-next 2/3] ipmr: add netlink notifications on igmpmsg cache reports

2017-06-14 Thread Julien Gomes
On 06/14/2017 12:56 AM, Nicolas Dichtel wrote:
> Le 13/06/2017 à 19:08, Julien Gomes a écrit :
>> Add Netlink notifications on cache reports in ipmr, in addition to the
>> existing igmpmsg sent to mroute_sk.
>> Send RTM_NEWCACHEREPORT notifications to RTNLGRP_IPV4_MROUTE.
>>
>> MSGTYPE, VIF_ID, SRC_ADDR and DST_ADDR Netlink attributes contain the
>> same data as their equivalent fields in the igmpmsg header.
>> PKT attribute is the packet sent to mroute_sk, without the added igmpmsg
>> header.
>>
>> Suggested-by: Ryan Halbrook 
>> Signed-off-by: Julien Gomes 
>> ---
>>  include/uapi/linux/mroute.h | 11 
>>  net/ipv4/ipmr.c | 63 
>> +++--
>>  2 files changed, 72 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/uapi/linux/mroute.h b/include/uapi/linux/mroute.h
>> index f904367c0cee..f6f9e01ee734 100644
>> --- a/include/uapi/linux/mroute.h
>> +++ b/include/uapi/linux/mroute.h
>> @@ -152,6 +152,17 @@ enum {
>>  };
>>  #define IPMRA_VIFA_MAX (__IPMRA_VIFA_MAX - 1)
>>  
>> +/* ipmr netlink cache report attributes */
>> +enum {
> IPMRA_CACHEREPORTA_UNSPEC is missing.

Indeed, I will add it.

> By the way, maybe something shorter than IPMRA_CACHEREPORTA_ would be better.
> What about IPMR_CREPORTA_? IPMR_CACHEA_? IPMR_IGMPA_? or whatever.

I see absolutely no issue in shortening them.
IPMRA_CREPORT_ sounds good to me.

> What is the signification of the two 'A'? One for 'attribute', but the other?

Now that you mention it, the second 'A' is simply redundant.
I will remove it and go with IPMRA_CREPORT_.

-- 
Julien Gomes



Re: [PATCH v3 net-next 0/4] kernel TLS

2017-06-14 Thread Tom Herbert
On Wed, Jun 14, 2017 at 11:36 AM, Dave Watson  wrote:
> This series adds support for kernel TLS encryption over TCP sockets.
> A standard TCP socket is converted to a TLS socket using a setsockopt.
> Only symmetric crypto is done in the kernel, as well as TLS record
> framing.  The handshake remains in userspace, and the negotiated
> cipher keys/iv are provided to the TCP socket.
>
I don't see support for TLS receive path in the kernel, only the send
path. Am I missing something?

Thanks,
Tom

> We implemented support for this API in OpenSSL 1.1.0, the code is
> available at https://github.com/Mellanox/tls-openssl/tree/master
>
> It should work with any TLS library with similar modifications,
> a test tool using gnutls is here: https://github.com/Mellanox/tls-af_ktls_tool
>
> RFC patch to openssl:
> https://mta.openssl.org/pipermail/openssl-dev/2017-June/009384.html
>
> Changes from V2:
>
> * EXPORT_SYMBOL_GPL in patch 1
> * Ensure cleanup code always called before sk_stream_kill_queues to
>   avoid warnings
>
> Changes from V1:
>
> * EXPORT_SYMBOL GPL in patch 2
> * Add link to OpenSSL patch & gnutls example in documentation patch.
> * sk_write_pending check was rolled in to wait_for_memory path,
>   avoids special case and fixes lock inbalance issue.
> * Unify flag handling for sendmsg/sendfile
>
> Changes from RFC V2:
>
> * Generic ULP (upper layer protocol) framework instead of TLS specific
>   setsockopts
> * Dropped Mellanox hardware patches, will come as separate series.
>   Framework will work for both.
>
> RFC V2:
>
> http://www.mail-archive.com/netdev@vger.kernel.org/msg160317.html
>
> Changes from RFC V1:
>
> * Socket based on changing TCP proto_ops instead of crypto framework
> * Merged code with Mellanox's hardware tls offload
> * Zerocopy sendmsg support added - sendpage/sendfile is no longer
>   necessary for zerocopy optimization
>
> RFC V1:
>
> http://www.mail-archive.com/netdev@vger.kernel.org/msg88021.html
>
> * Socket based on crypto userspace API framework, required two
>   sockets in userspace, one encrypted, one unencrypted.
>
> Paper: https://netdevconf.org/1.2/papers/ktls.pdf
>
> Aviad Yehezkel (1):
>   tcp: export do_tcp_sendpages and tcp_rate_check_app_limited functions
>
> Boris Pismenny (2):
>   tcp: ULP infrastructure
>   tls: Documentation
>
> Ilya Lesokhin (1):
>   tls: kernel TLS support
>
>  Documentation/networking/tls.txt   | 135 +++
>  MAINTAINERS|  10 +
>  include/linux/socket.h |   1 +
>  include/net/inet_connection_sock.h |   4 +
>  include/net/tcp.h  |  27 ++
>  include/net/tls.h  | 237 
>  include/uapi/linux/tcp.h   |   1 +
>  include/uapi/linux/tls.h   |  79 
>  net/Kconfig|   1 +
>  net/Makefile   |   1 +
>  net/ipv4/Makefile  |   2 +-
>  net/ipv4/sysctl_net_ipv4.c |  25 ++
>  net/ipv4/tcp.c |  33 +-
>  net/ipv4/tcp_ipv4.c|   2 +
>  net/ipv4/tcp_rate.c|   1 +
>  net/ipv4/tcp_ulp.c | 134 +++
>  net/tls/Kconfig|  12 +
>  net/tls/Makefile   |   7 +
>  net/tls/tls_main.c | 487 +++
>  net/tls/tls_sw.c   | 772 
> +
>  20 files changed, 1968 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/networking/tls.txt
>  create mode 100644 include/net/tls.h
>  create mode 100644 include/uapi/linux/tls.h
>  create mode 100644 net/ipv4/tcp_ulp.c
>  create mode 100644 net/tls/Kconfig
>  create mode 100644 net/tls/Makefile
>  create mode 100644 net/tls/tls_main.c
>  create mode 100644 net/tls/tls_sw.c
>
> --
> 2.9.3
>


Re: [net-next,v2] openvswitch: add macro MODULE_ALIAS_VPORT_TYPE for vport type alias

2017-06-14 Thread Pravin Shelar
On Tue, Jun 13, 2017 at 12:00 AM, Zhang Shengju
 wrote:
> Add a new macro MODULE_ALIAS_VPORT_TYPE to unify and simplify the
> declaration of vport type alias.
>
> Signed-off-by: Zhang Shengju 
> ---
>  net/openvswitch/vport-geneve.c | 2 +-
>  net/openvswitch/vport-gre.c| 2 +-
>  net/openvswitch/vport-vxlan.c  | 2 +-
>  net/openvswitch/vport.h| 3 +++
>  4 files changed, 6 insertions(+), 3 deletions(-)
>
The change looks fine. But I do not see value in it. This is compat
tunnel code, there should not be any more vports added to OVS. So
adding this new API does not help for future code changes either.


> diff --git a/net/openvswitch/vport-geneve.c b/net/openvswitch/vport-geneve.c
> index 5aaf3ba..0ebf023 100644
> --- a/net/openvswitch/vport-geneve.c
> +++ b/net/openvswitch/vport-geneve.c
> @@ -141,4 +141,4 @@ static void __exit ovs_geneve_tnl_exit(void)
>
>  MODULE_DESCRIPTION("OVS: Geneve switching port");
>  MODULE_LICENSE("GPL");
> -MODULE_ALIAS("vport-type-5");
> +MODULE_ALIAS_VPORT_TYPE(5);
> diff --git a/net/openvswitch/vport-gre.c b/net/openvswitch/vport-gre.c
> index 0e72d95..97fc4d5 100644
> --- a/net/openvswitch/vport-gre.c
> +++ b/net/openvswitch/vport-gre.c
> @@ -113,4 +113,4 @@ static void __exit ovs_gre_tnl_exit(void)
>
>  MODULE_DESCRIPTION("OVS: GRE switching port");
>  MODULE_LICENSE("GPL");
> -MODULE_ALIAS("vport-type-3");
> +MODULE_ALIAS_VPORT_TYPE(3);
> diff --git a/net/openvswitch/vport-vxlan.c b/net/openvswitch/vport-vxlan.c
> index 869acb3..0375b6a 100644
> --- a/net/openvswitch/vport-vxlan.c
> +++ b/net/openvswitch/vport-vxlan.c
> @@ -179,4 +179,4 @@ static void __exit ovs_vxlan_tnl_exit(void)
>
>  MODULE_DESCRIPTION("OVS: VXLAN switching port");
>  MODULE_LICENSE("GPL");
> -MODULE_ALIAS("vport-type-4");
> +MODULE_ALIAS_VPORT_TYPE(4);
> diff --git a/net/openvswitch/vport.h b/net/openvswitch/vport.h
> index cda66c2..1d1584f 100644
> --- a/net/openvswitch/vport.h
> +++ b/net/openvswitch/vport.h
> @@ -199,4 +199,7 @@ static inline const char *ovs_vport_name(struct vport 
> *vport)
>  void ovs_vport_ops_unregister(struct vport_ops *ops);
>  void ovs_vport_send(struct vport *vport, struct sk_buff *skb, u8 mac_proto);
>
> +#define MODULE_ALIAS_VPORT_TYPE(type) \
> +   MODULE_ALIAS("vport-type-" __stringify(type))
> +
>  #endif /* vport.h */
> --
> 1.8.3.1
>
>
>


Re: [PATCH] skbuff: make skb_put_zero() return void

2017-06-14 Thread Johannes Berg
On Wed, 2017-06-14 at 13:36 -0700, Joe Perches wrote:
> 
> Given you are adding a lot of these, it might be better
> to add an exported function that duplicates most of
> skb_put with a memset at the end.

Yeah, could be done. I'm not sure why you'd want to duplicate it rather
than call it though? To make it about as fast?

Anyway, no objections really - just originally thought of it more as a
typing aid than an optimisation.

johannes


Re: [PATCH iproute2 2/2] tc: m_tunnel_key: add csum/nocsum option

2017-06-14 Thread Stephen Hemminger
On Wed, 14 Jun 2017 21:30:18 +0200
Jiri Benc  wrote:

> Allows control of UDP zero checksum.
> 
> Signed-off-by: Jiri Benc 
> ---
>  man/man8/tc-tunnel_key.8 | 18 ++
>  tc/m_tunnel_key.c| 21 -
>  2 files changed, 38 insertions(+), 1 deletion(-)
> 
> diff --git a/man/man8/tc-tunnel_key.8 b/man/man8/tc-tunnel_key.8
> index 2e569730abbb..e979a74715cb 100644
> --- a/man/man8/tc-tunnel_key.8
> +++ b/man/man8/tc-tunnel_key.8
> @@ -16,6 +16,7 @@ tunnel_key - Tunnel metadata manipulation
>  .IR ADDRESS
>  .BI id " KEY_ID"
>  .BI dst_port " UDP_PORT"
> +.RB "[ " csum " | " nocsum " ]"
>  
>  .SH DESCRIPTION
>  The
> @@ -77,6 +78,23 @@ Outer header destination IP address (IPv4 or IPv6)
>  .TP
>  .B dst_port
>  Outer header destination UDP port
> +.TP
> +.RB [ no ] csum
> +Controlls outer UDP checksum. When set to
> +.B csum
> +(which is default), the outer UDP checksum is calculated and included in the
> +packets. When set to
> +.BR nocsum ,

Does this change the default? Before your patches what was the checksum
setting for the new tunnel.


Re: [PATCH] skbuff: make skb_put_zero() return void

2017-06-14 Thread Joe Perches
On Wed, 2017-06-14 at 22:17 +0200, Johannes Berg wrote:
> From: Johannes Berg 
> 
> It's nicer to return void, since then there's no need to
> cast to any structures. Currently none of the users have
> a cast, but a number of future conversions do.
> 
> Signed-off-by: Johannes Berg 
> ---
>  include/linux/skbuff.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 1151b50892d1..01ea64d0783a 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -1904,9 +1904,9 @@ static inline unsigned char *__skb_put(struct sk_buff 
> *skb, unsigned int len)
>   return tmp;
>  }
>  
> -static inline unsigned char *skb_put_zero(struct sk_buff *skb, unsigned int 
> len)
> +static inline void *skb_put_zero(struct sk_buff *skb, unsigned int len)
>  {
> - unsigned char *tmp = skb_put(skb, len);
> + void *tmp = skb_put(skb, len);
>  
>   memset(tmp, 0, len);

Given you are adding a lot of these, it might be better
to add an exported function that duplicates most of
skb_put with a memset at the end.

That would probably create a smaller kernel and might
be a bit faster.

Perhaps:
---
 include/linux/skbuff.h | 10 +-
 net/core/skbuff.c  | 22 ++
 2 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 78213b3f9552..f725cbe30c9c 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1895,6 +1895,7 @@ static inline void skb_set_tail_pointer(struct sk_buff 
*skb, const int offset)
  */
 unsigned char *pskb_put(struct sk_buff *skb, struct sk_buff *tail, int len);
 unsigned char *skb_put(struct sk_buff *skb, unsigned int len);
+void *skb_put_zero(struct sk_buff *skb, unsigned int len);
 static inline unsigned char *__skb_put(struct sk_buff *skb, unsigned int len)
 {
unsigned char *tmp = skb_tail_pointer(skb);
@@ -1904,15 +1905,6 @@ static inline unsigned char *__skb_put(struct sk_buff 
*skb, unsigned int len)
return tmp;
 }
 
-static inline unsigned char *skb_put_zero(struct sk_buff *skb, unsigned int 
len)
-{
-   unsigned char *tmp = skb_put(skb, len);
-
-   memset(tmp, 0, len);
-
-   return tmp;
-}
-
 unsigned char *skb_push(struct sk_buff *skb, unsigned int len);
 static inline unsigned char *__skb_push(struct sk_buff *skb, unsigned int len)
 {
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 304602784c3b..e70aa414b139 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -1454,6 +1454,28 @@ unsigned char *skb_put(struct sk_buff *skb, unsigned int 
len)
 EXPORT_SYMBOL(skb_put);
 
 /**
+ * skb_put_zero - add zeroed data to a buffer
+ * @skb: buffer to use
+ * @len: amount of zeroed data to add
+ *
+ * This function extends the used data area of the buffer. If this would
+ * exceed the total buffer size the kernel will panic. A pointer to the
+ * first byte of the extra data is returned.
+ */
+void *skb_put_zero(struct sk_buff *skb, unsigned int len)
+{
+   unsigned char *tmp = skb_tail_pointer(skb);
+
+   SKB_LINEAR_ASSERT(skb);
+   skb->tail += len;
+   skb->len  += len;
+   if (unlikely(skb->tail > skb->end))
+   skb_over_panic(skb, len, __builtin_return_address(0));
+   return memset(tmp, 0, len);
+}
+EXPORT_SYMBOL(skb_put_zero);
+
+/**
  * skb_push - add data to the start of a buffer
  * @skb: buffer to use
  * @len: amount of data to add


Re: [PATCH iproute2] ip: mroute: Add table output to show command

2017-06-14 Thread Stephen Hemminger
On Wed, 14 Jun 2017 08:08:12 -0400
Donald Sharp  wrote:

> When the user specifies `table all` or `table 0` to
> the `ip mroute show` command we dump the entirety of
> the known mroute tables.  Without some sort of
> divisor to tell us what table we are looking at
> the command is useless.
> 
> Add `Table: ` to the output of 'ip mroute show table 0'
> 
> Follow the convention established by 'ip route show table 0'
> for when to display
> 
> Signed-off-by: Donald Sharp 

Applied, thanks.


Re: [PATCH v2] arm: eBPF JIT compiler

2017-06-14 Thread Daniel Borkmann

On 06/13/2017 08:56 AM, Shubham Bansal wrote:

Hi Daniel, Kees, David, Russel,


Any plans to implement above especially BPF_JMP | BPF_CALL in near future?
Reason why I'm asking is that i) currently the arm32 cBPF JIT implements
all of the cBPF extensions (except SKF_AD_RANDOM and SKF_AD_VLAN_TPID).
Some of the programs that were JITed before e.g. using SKF_AD_CPU would now
fall back to the eBPF interpreter due to lack of translation in JIT, but
also ii) that probably most (if not all) of eBPF programs use BPF helper
calls heavily, which will still redirect them to the interpreter right now
due to lack of BPF_JMP | BPF_CALL support, so it's really quite essential
to have it implemented.


I can try for BPF_JMP | BPF_CALL. I didn't do it last time because I
thought, it would make the code look messy and become pain to get it
through the review.
For this, I have to map eBPF arguments with arm ABI arguments and move
ebpf arguments to corresponding arm ABI arguments, as eBPF arguments
doesn't match with arm ABI arguments.
Let me try that if its possible.


Okay. I looked at it, tried few different solutions also. There is a
problem with implementing BPF_JMP | BPF_CALL.
Problem is transition between 4 byte and 8 byte arguments. Lets take a
look a the following example to get a more clear look at the problem.

Lets consider this function :
CASE 1:foo(int a, int b, long long c, int d)
For calling this function in arm 32 arch, I have to pass the arguments
as following:
  a -> r0
  b -> r1
  c -> r2, r3
  d -> stack_top

Now consider an another example function :
CASE 2:   bar(int a, int b, int c, int d)
For calling this function in arm32 arch, I have to pass the arguments
as following:
a -> r0
b -> r1
c -> r2
d -> r3

So, you can clearly see the problem with it. There is no way of
knowing which of the above way to pass the arguments. There are
solutions possible:


Right.


1. One thing I can do is look at the address of the function to call
and pass the argument accordingly but thats not really a robust
solution as we have to change the arm32 JIT each time we add any new
BPF helper function.


Yeah, that would be rather ugly.


2. Another solution is, if any of you guys can assure/confirm me that
there will be only 4 byte argument passed to BPF helper functions in
arm32 as of now and in future including the pointer as well, then I
can just assume that each argument is passed as 4 byte value and my
trimming the 8byte arguments to 4 bytes arguments wouldn't be a
problem. In that case, arguments for CASE 1 and CASE 2 will be passed
in the same way, i.e.
a -> r0
b -> r1
c -> r2
d -> r3

Let me know what you think. I don't think I can find the solution to
this problem other than those mentioned above. Would love to here any
ideas from you guys.


Not all of the helpers have 4 or less byte arguments only, there are a
few with 8 byte arguments, so making that general assumption wouldn't
work. I guess what could be done is that helpers have a flag in struct
bpf_func_proto which indicates for JITs that all args are 4 byte on 32bit
so you could probably use convention similar to case2 for them. Presumably
for that information to process, the JIT might need to be reworked to
extract that via bpf_analyzer() that does a verifier run to re-analyze
the program like in nfp JIT case.

The other option could perhaps be to check the interpreter disasm of
___bpf_prog_run() with regards to how it handles BPF_JMP | BPF_CALL
helper call and do something similarly generic in the JIT as well.


Did you also manage to get the BPF selftest suite running in the meantime
(tools/testing/selftests/bpf/)? There are a couple of programs that clang
will compile (test_pkt_access.o, test_xdp.o, test_l4lb.o, test_tcp_estats.o)
and then test run.

I will run these tests tonight. Hopefully I will be able to run them.


Ok.


Any comments are welcome. Would love to here what you think about my
solutions above.


Re: [PATCH iproute2] link_gre6: really support encaplimit option

2017-06-14 Thread Stephen Hemminger
On Wed, 14 Jun 2017 18:45:42 +0200
Nicolas Dichtel  wrote:

> This option is documented in gre6 help, but was not supported.
> 
> Fixes: af89576d7a8c ("iproute2: GRE over IPv6 tunnel support.")
> Signed-off-by: Nicolas Dichtel 

Sure applied.


[RFC] networking: convert many more places to skb_put_zero()

2017-06-14 Thread Johannes Berg
From: Johannes Berg 

There were many places that my previous spatch didn't find,
as pointed out by yuan linyu in various patches.

The following spatch found many more and also removes the
now unnecessary casts:

@@
identifier p, p2;
expression len;
expression skb;
type t, t2;
@@
(
-p = skb_put(skb, len);
+p = skb_put_zero(skb, len);
|
-p = (t)skb_put(skb, len);
+p = skb_put_zero(skb, len);
)
(
p2 = (t2)p;
-memset(p2, 0, len);
|
-memset(p, 0, len);
)

@@
type t, t2;
identifier p, p2;
expression skb;
@@
t *p;
...
(
-p = skb_put(skb, sizeof(t));
+p = skb_put_zero(skb, sizeof(t));
|
-p = (t *)skb_put(skb, sizeof(t));
+p = skb_put_zero(skb, sizeof(t));
)
(
p2 = (t2)p;
-memset(p2, 0, sizeof(*p));
|
-memset(p, 0, sizeof(*p));
)

Apply it to the tree (with one manual fixup to keep the
comment in vxlan.c, which spatch removed.)

Signed-off-by: Johannes Berg 
---
 drivers/infiniband/hw/cxgb3/cxio_hal.c |  6 ++--
 drivers/infiniband/hw/cxgb3/iwch_cm.c  |  3 +-
 drivers/infiniband/hw/cxgb3/iwch_qp.c  |  6 ++--
 drivers/infiniband/hw/cxgb4/cm.c   |  9 ++
 drivers/net/vxlan.c|  4 +--
 drivers/net/wireless/ath/ath9k/channel.c   |  3 +-
 drivers/net/wireless/intersil/hostap/hostap_main.c |  4 +--
 drivers/net/wireless/marvell/mwifiex/tdls.c|  3 +-
 drivers/net/wireless/quantenna/qtnfmac/commands.c  |  8 ++---
 drivers/net/wireless/realtek/rtlwifi/base.c|  6 ++--
 drivers/net/wireless/ti/wlcore/cmd.c   |  3 +-
 drivers/net/wireless/ti/wlcore/main.c  |  3 +-
 drivers/scsi/fcoe/fcoe_ctlr.c  |  3 +-
 drivers/usb/gadget/function/f_ncm.c| 15 +++--
 net/atm/signaling.c|  3 +-
 net/batman-adv/bat_v_elp.c |  3 +-
 net/bridge/netfilter/nft_reject_bridge.c   |  6 ++--
 net/ipv4/ipconfig.c|  3 +-
 net/ipv4/netfilter/nf_reject_ipv4.c|  3 +-
 net/ipv6/mcast.c   |  3 +-
 net/key/af_key.c   |  9 ++
 net/mac80211/agg-rx.c  |  3 +-
 net/mac80211/agg-tx.c  |  6 ++--
 net/mac80211/debugfs_netdev.c  |  3 +-
 net/mac80211/ht.c  |  3 +-
 net/mac80211/mesh.c|  3 +-
 net/mac80211/mesh_hwmp.c   |  6 ++--
 net/mac80211/mesh_plink.c  |  3 +-
 net/mac80211/mlme.c|  6 ++--
 net/mac80211/rx.c  |  3 +-
 net/mac80211/spectmgmt.c   |  3 +-
 net/mac80211/tdls.c|  6 ++--
 net/mac80211/tx.c  | 10 ++
 net/mac80211/util.c|  6 ++--
 net/ncsi/ncsi-cmd.c| 36 --
 net/qrtr/qrtr.c|  9 ++
 36 files changed, 69 insertions(+), 143 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb3/cxio_hal.c 
b/drivers/infiniband/hw/cxgb3/cxio_hal.c
index 558d6a03375d..97f7f9544e70 100644
--- a/drivers/infiniband/hw/cxgb3/cxio_hal.c
+++ b/drivers/infiniband/hw/cxgb3/cxio_hal.c
@@ -142,8 +142,7 @@ static int cxio_hal_clear_qp_ctx(struct cxio_rdev *rdev_p, 
u32 qpid)
pr_debug("%s alloc_skb failed\n", __func__);
return -ENOMEM;
}
-   wqe = (struct t3_modify_qp_wr *) skb_put(skb, sizeof(*wqe));
-   memset(wqe, 0, sizeof(*wqe));
+   wqe = skb_put_zero(skb, sizeof(*wqe));
build_fw_riwrh((struct fw_riwrh *) wqe, T3_WR_QP_MOD,
   T3_COMPLETION_FLAG | T3_NOTIFY_FLAG, 0, qpid, 7,
   T3_SOPEOP);
@@ -561,8 +560,7 @@ static int cxio_hal_init_ctrl_qp(struct cxio_rdev *rdev_p)
ctx1 |= ((u64) (V_EC_BASE_HI((u32) base_addr & 0xf) | V_EC_RESPQ(0) |
V_EC_TYPE(0) | V_EC_GEN(1) |
V_EC_UP_TOKEN(T3_CTL_QP_TID) | F_EC_VALID)) << 32;
-   wqe = (struct t3_modify_qp_wr *) skb_put(skb, sizeof(*wqe));
-   memset(wqe, 0, sizeof(*wqe));
+   wqe = skb_put_zero(skb, sizeof(*wqe));
build_fw_riwrh((struct fw_riwrh *) wqe, T3_WR_QP_MOD, 0, 0,
   T3_CTL_QP_TID, 7, T3_SOPEOP);
wqe->flags = cpu_to_be32(MODQP_WRITE_EC);
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c 
b/drivers/infiniband/hw/cxgb3/iwch_cm.c
index b61630eba912..f4c23a74f18c 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_cm.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_cm.c
@@ -417,8 +417,7 @@ static int send_abort(struct iwch_ep *ep, struct 

[PATCH] skbuff: make skb_put_zero() return void

2017-06-14 Thread Johannes Berg
From: Johannes Berg 

It's nicer to return void, since then there's no need to
cast to any structures. Currently none of the users have
a cast, but a number of future conversions do.

Signed-off-by: Johannes Berg 
---
 include/linux/skbuff.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 1151b50892d1..01ea64d0783a 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1904,9 +1904,9 @@ static inline unsigned char *__skb_put(struct sk_buff 
*skb, unsigned int len)
return tmp;
 }
 
-static inline unsigned char *skb_put_zero(struct sk_buff *skb, unsigned int 
len)
+static inline void *skb_put_zero(struct sk_buff *skb, unsigned int len)
 {
-   unsigned char *tmp = skb_put(skb, len);
+   void *tmp = skb_put(skb, len);
 
memset(tmp, 0, len);
 
-- 
2.11.0



Re: [PATCH v3 net-next 0/4] kernel TLS

2017-06-14 Thread Hannes Frederic Sowa
Hello Dave,

On Wed, Jun 14, 2017, at 21:47, David Miller wrote:
> From: Dave Watson 
> Date: Wed, 14 Jun 2017 11:36:54 -0700
> 
> > This series adds support for kernel TLS encryption over TCP sockets.
> > A standard TCP socket is converted to a TLS socket using a setsockopt.
> > Only symmetric crypto is done in the kernel, as well as TLS record
> > framing.  The handshake remains in userspace, and the negotiated
> > cipher keys/iv are provided to the TCP socket.
> > 
> > We implemented support for this API in OpenSSL 1.1.0, the code is
> > available at https://github.com/Mellanox/tls-openssl/tree/master
> > 
> > It should work with any TLS library with similar modifications,
> > a test tool using gnutls is here: 
> > https://github.com/Mellanox/tls-af_ktls_tool
> > 
> > RFC patch to openssl:
> > https://mta.openssl.org/pipermail/openssl-dev/2017-June/009384.html
>  ...
> 
> I really want to apply this, so everyone give it a good review :-)

one question for this patch set:

What is the reason for not allowing key updates for the TX path? I was
always loud pointing out the problems with TLSv1.2 renegotiation and
TLSv1.3 key update alerts. This patch set uses encryption in a
synchronous way directly in the socket layer and thus wouldn't suffer
from problems regarding updates of the key. My hunch is that you leave
this option open so you can later on introduce asynchronous crypto which
might be used on hardware? It looks also be doable in case of MSG_MORE.
Otherwise by allowing key updates to the data path I would not see any
problems with key updates in TLS.

The reason why I am asking is that it is hard to predict how many bytes
will be send through a connection. TLSv1.3 recommends (SHOULD)
implementation writes to update the key after 362GB, afaik NIST even has
a lower margin. After that the symmetric crypto might become too weak.

Anyway, this patch seems easy and maybe with key updates added later on
doesn't seem to have any problems pointed out by me so far.

Thanks,
Hannes


Re: [PATCH net-next 00/11] skb_put_zero() used to optimize code

2017-06-14 Thread David Miller
From: Johannes Berg 
Date: Wed, 14 Jun 2017 22:11:54 +0200

> On Wed, 2017-06-14 at 15:38 -0400, David Miller wrote:
> 
>> What do you think about Stephen Hemminger's feedback to make
>> skb_put_zero() return "void *".  It will avoid a lot of casts and
>> make the conversions look nicer.
> 
> I think it's a good idea. I can send a patch, and remove some casts
> where they exist - I guess we could also do it even for skb_put()
> eventually.
> 
>> I'll also defer on this patch series until we have the spatch thing
>> which can catch all of them.
> 
> I think I have something that covers most cases, will send out an RFC
> in a minute (since I'm not sure I was able to build it all yet).

All sounds great.

> Note that some of the cases like in ipv6/ndisc.c certainly can't be
> done automatically, they look correct but are more complicated because
> there's not just a single big memset(), but they're doing it piece by
> piece (fill some bytes, clear some others, etc.) Might be worth
> checking which aren't covered by the spatch.

Understood.


Re: [PATCH net-next 00/11] skb_put_zero() used to optimize code

2017-06-14 Thread Johannes Berg
On Wed, 2017-06-14 at 15:38 -0400, David Miller wrote:

> What do you think about Stephen Hemminger's feedback to make
> skb_put_zero() return "void *".  It will avoid a lot of casts and
> make the conversions look nicer.

I think it's a good idea. I can send a patch, and remove some casts
where they exist - I guess we could also do it even for skb_put()
eventually.

> I'll also defer on this patch series until we have the spatch thing
> which can catch all of them.

I think I have something that covers most cases, will send out an RFC
in a minute (since I'm not sure I was able to build it all yet).

Note that some of the cases like in ipv6/ndisc.c certainly can't be
done automatically, they look correct but are more complicated because
there's not just a single big memset(), but they're doing it piece by
piece (fill some bytes, clear some others, etc.) Might be worth
checking which aren't covered by the spatch.

johannes


Re: [patch iproute2 v2 repost 2/3] tc: actions: add helpers to parse and print control actions

2017-06-14 Thread Jiri Pirko
Wed, Jun 14, 2017 at 09:28:24PM CEST, jb...@redhat.com wrote:
>On Wed, 14 Jun 2017 21:18:50 +0200, Jiri Pirko wrote:
>> Isn't it fixed by:
>> 
>> https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/commit/?h=net-next=18f05d06016d9492c87fd105d831de0d6d858f43
>> 
>> ?
>
>Doesn't seem so. The current net-next branch with this commit included
>fails in the same way.

Will fix tmrw. Thanks!


>
> Jiri


Re: [PATCH net-next 01/11] ipv6: skb_put_zero() used to optimize code

2017-06-14 Thread Johannes Berg
On Wed, 2017-06-14 at 12:14 -0700, Stephen Hemminger wrote:
> 
> > I just copied it from skb_put() - you could ask the same there? :)
> 
> My taste is to  have less casts. Never understood why so many skb_
> functions returned char *, probably a leftover from older Unix style.

I agree, for many of them it's awkward and I often just put a (void *)
cast in there ...

I guess we can just make them void, and if anyone wants it I can easily
cook up an spatch to remove casts.

johannes


Re: [PATCH v3 net-next 0/4] kernel TLS

2017-06-14 Thread David Miller
From: Dave Watson 
Date: Wed, 14 Jun 2017 11:36:54 -0700

> This series adds support for kernel TLS encryption over TCP sockets.
> A standard TCP socket is converted to a TLS socket using a setsockopt.
> Only symmetric crypto is done in the kernel, as well as TLS record
> framing.  The handshake remains in userspace, and the negotiated
> cipher keys/iv are provided to the TCP socket.
> 
> We implemented support for this API in OpenSSL 1.1.0, the code is
> available at https://github.com/Mellanox/tls-openssl/tree/master
> 
> It should work with any TLS library with similar modifications,
> a test tool using gnutls is here: https://github.com/Mellanox/tls-af_ktls_tool
> 
> RFC patch to openssl:
> https://mta.openssl.org/pipermail/openssl-dev/2017-June/009384.html
 ...

I really want to apply this, so everyone give it a good review :-)


Re: [pull request][for-next 0/6] Mellanox mlx5 updates 2017-05-23

2017-06-14 Thread David Miller
From: Doug Ledford 
Date: Wed, 14 Jun 2017 15:30:13 -0400

> On Thu, 2017-05-25 at 12:02 -0400, David Miller wrote:
>> From: Saeed Mahameed 
>> Date: Tue, 23 May 2017 14:43:58 +0300
>> 
>> > Hi Dave and Doug,
>> > 
>> > This series introduces some small updates and FPGA support to the
>> mlx5
>> > core/ethernet and IB drivers.
>> > 
>> > For more details please see below.
>> > 
>> > Please pull and let me know if there's any problem.
>> 
>> Ok, I've pulled this into net-next.
>> 
>> Doug let me know if there are any merge hassles we need to coordinate
>> on.
> 
> Turns out that you had pulled this prior to your net-next tree making
> it up to v4.12-rc3, while I had my -rc branch based on v4.12-rc3, so
> when I pulled just up to your merge commit for this pull request, it
> meant a later merge of my -rc branch would pull in a bunch of stuff
> between here and -rc3.  So I ended up pulling your latest net-next as
> of today as the easiest way to resolve that issue.  Now I can merge my
> -rc branch in and it won't cause any extra noise in the merge.  It
> seems to be a fairly regular pattern that I'm going to have to hold my
> pull request to Linus until after your tree is pulled, so I might just
> start planning on that from now on ;-)

Hehe, ok :)


Re: [PATCH net-next] rxrpc: Cache the congestion window setting

2017-06-14 Thread David Miller
From: David Howells 
Date: Wed, 14 Jun 2017 17:56:50 +0100

> Cache the congestion window setting that was determined during a call's
> transmission phase when it finishes so that it can be used by the next call
> to the same peer, thereby shortcutting the slow-start algorithm.
> 
> The value is stored in the rxrpc_peer struct and is accessed without
> locking.  Each call takes the value that happens to be there when it starts
> and just overwrites the value when it finishes.
> 
> Signed-off-by: David Howells 

Applied, thanks David.


Re: [PATCH net-next] liquidio: fix VF driver off-by-one bug when setting ethtool -C ethX rx-frames

2017-06-14 Thread David Miller
From: Felix Manlunas 
Date: Wed, 14 Jun 2017 09:11:31 -0700

> From: Weilin Chang 
> 
> Signed-off-by: Weilin Chang 
> Signed-off-by: Derek Chickles 
> Signed-off-by: Felix Manlunas 

Applied.


Re: [PATCH] batman-adv: Remove unnecessary length qualifier in %14pM

2017-06-14 Thread Sven Eckelmann
On Mittwoch, 14. Juni 2017 02:33:52 CEST Joe Perches wrote:
> It's misleading and unnecessary.
> 
> Signed-off-by: Joe Perches 
> ---
>  net/batman-adv/distributed-arp-table.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

The patch was applied and is currently queued up as 
454ea1866ef45c6f1b747bd27a8203318be72b5d in batadv/net-next.

Thanks,
Sven

signature.asc
Description: This is a digitally signed message part.


Re: [PATCH net-next 00/11] skb_put_zero() used to optimize code

2017-06-14 Thread David Miller
From: Johannes Berg 
Date: Wed, 14 Jun 2017 18:31:48 +0200

> On Wed, 2017-06-14 at 18:29 +0200, Johannes Berg wrote:
>> On Wed, 2017-06-14 at 23:00 +0800, yuan linyu wrote:
>> 
>> > sorry, I do them by hand. 
>> 
>> oh, ok.
>> 
>> This seems to work:
>> 
>> @@
>> identifier p;
>> expression len;
>> expression skb;
>> type t;
>> @@
>> -p = (t)skb_put(skb, len);
>> -memset(p, 0, len);
>> +p = (t)skb_put_zero(skb, len);
> 
> Nope, still didn't find everything - not the batman and atm cases for
> example. But still a few more, I think that you didn't find, e.g. in
> mac80211.
> 
> Anyway - I think none of this is really critical.

What do you think about Stephen Hemminger's feedback to make skb_put_zero()
return "void *".  It will avoid a lot of casts and make the conversions
look nicer.

I'll also defer on this patch series until we have the spatch thing
which can catch all of them.

Thanks.


Re: [PATCH 0/3] wext: fix an ancient bug

2017-06-14 Thread David Miller
From: Johannes Berg 
Date: Wed, 14 Jun 2017 13:55:20 +0200

> Robert O'Callahan reported that since struct iwreq is smaller than
> struct ifreq, if it happens to land at the end of a mapped section
> userspace will erroneously get -EFAULT.
> 
> Bug report is https://bugzilla.kernel.org/show_bug.cgi?id=195869.
> 
> This bug is ancient, it kernel 2.1.15 was the first to contain the
> bug, and was released almost exactly 20.5 years ago.
> 
> Dave, I don't know if we should even bother sending this to stable,
> but if so, the third patch will apply by itself but not compile, a
> smaller patch consist of only the net/core/dev_ioctl.c modifications
> with a cast thrown in where the compile fails/warns due to passing
> the wrong struct type.
> 
> Should I merge this through my tree?

Agreed that -stable is probably not appropriate, and yes feel free to
merge it via your tree.

20.5 years... makes me feel old :-)


[PATCH 0/2] Fix OPA_VNIC issues with debug kernel

2017-06-14 Thread Vishwanathapura, Niranjana
Hi Doug,
Here are couple OPA_VNIC bug fixes.
As OPA_VNIC is alredy included for 4.12, it would be great
to get them into the RC release.

Thanks,
Niranjana

Vishwanathapura, Niranjana (2):
  IB/opa_vnic: Use GFP_ATOMIC while sending trap
  IB/opa_vnic: Use spinlock instead of mutex for stats_lock

 drivers/infiniband/ulp/opa_vnic/opa_vnic_ethtool.c| 4 ++--
 drivers/infiniband/ulp/opa_vnic/opa_vnic_internal.h   | 2 +-
 drivers/infiniband/ulp/opa_vnic/opa_vnic_netdev.c | 8 +++-
 drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c   | 2 +-
 drivers/infiniband/ulp/opa_vnic/opa_vnic_vema_iface.c | 8 
 5 files changed, 11 insertions(+), 13 deletions(-)

-- 
1.8.3.1



Re: [PATCH net] net: don't global ICMP rate limit packets originating from loopback

2017-06-14 Thread David Miller
From: Jesper Dangaard Brouer 
Date: Wed, 14 Jun 2017 13:27:37 +0200

> Florian Weimer seems to have a glibc test-case which requires that
> loopback interfaces does not get ICMP ratelimited.  This was broken by
> commit c0303efeab73 ("net: reduce cycles spend on ICMP replies that
> gets rate limited").
> 
> An ICMP response will usually be routed back-out the same incoming
> interface.  Thus, take advantage of this and skip global ICMP
> ratelimit when the incoming device is loopback.  In the unlikely event
> that the outgoing it not loopback, due to strange routing policy
> rules, ICMP rate limiting still works via peer ratelimiting via
> icmpv4_xrlim_allow().  Thus, we should still comply with RFC1812
> (section 4.3.2.8 "Rate Limiting").
> 
> This seems to fix the reproducer given by Florian.  While still
> avoiding to perform expensive and unneeded outgoing route lookup for
> rate limited packets (in the non-loopback case).
> 
> Fixes: c0303efeab73 ("net: reduce cycles spend on ICMP replies that gets rate 
> limited")
> Reported-by: Florian Weimer 
> Reported-by: "H.J. Lu" 
> Signed-off-by: Jesper Dangaard Brouer 

Applied and queued up for -stable, thanks Jesper.


Re: [PATCH net-next] net/mlxfw: fix a NULL dereference

2017-06-14 Thread David Miller
From: Dan Carpenter 
Date: Wed, 14 Jun 2017 13:41:52 +0300

> If we hit this error path we end up returning ERR_PTR(0) which is NULL.
> The caller is not expecting that so it results in a NULL dereference.
> 
> Fixes: 410ed13cae39 ("Add the mlxfw module for Mellanox firmware flash 
> process")
> Signed-off-by: Dan Carpenter 

Applied.


Re: [PATCH net] net/act_pedit: fix an error code

2017-06-14 Thread David Miller
From: Dan Carpenter 
Date: Wed, 14 Jun 2017 13:29:31 +0300

> I'm reviewing static checker warnings where we do ERR_PTR(0), which is
> the same as NULL.  I'm pretty sure we intended to return ERR_PTR(-EINVAL)
> here.  Sometimes these bugs lead to a NULL dereference but I don't
> immediately see that problem here.
> 
> Fixes: 71d0ed7079df ("net/act_pedit: Support using offset relative to the 
> conventional network headers")
> Signed-off-by: Dan Carpenter 

Applied.


Re: [pull request][for-next 0/6] Mellanox mlx5 updates 2017-05-23

2017-06-14 Thread Doug Ledford
On Thu, 2017-05-25 at 12:02 -0400, David Miller wrote:
> From: Saeed Mahameed 
> Date: Tue, 23 May 2017 14:43:58 +0300
> 
> > Hi Dave and Doug,
> > 
> > This series introduces some small updates and FPGA support to the
> mlx5
> > core/ethernet and IB drivers.
> > 
> > For more details please see below.
> > 
> > Please pull and let me know if there's any problem.
> 
> Ok, I've pulled this into net-next.
> 
> Doug let me know if there are any merge hassles we need to coordinate
> on.

Turns out that you had pulled this prior to your net-next tree making
it up to v4.12-rc3, while I had my -rc branch based on v4.12-rc3, so
when I pulled just up to your merge commit for this pull request, it
meant a later merge of my -rc branch would pull in a bunch of stuff
between here and -rc3.  So I ended up pulling your latest net-next as
of today as the easiest way to resolve that issue.  Now I can merge my
-rc branch in and it won't cause any extra noise in the merge.  It
seems to be a fairly regular pattern that I'm going to have to hold my
pull request to Linus until after your tree is pulled, so I might just
start planning on that from now on ;-)

-- 
Doug Ledford 
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD



[PATCH iproute2 2/2] tc: m_tunnel_key: add csum/nocsum option

2017-06-14 Thread Jiri Benc
Allows control of UDP zero checksum.

Signed-off-by: Jiri Benc 
---
 man/man8/tc-tunnel_key.8 | 18 ++
 tc/m_tunnel_key.c| 21 -
 2 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/man/man8/tc-tunnel_key.8 b/man/man8/tc-tunnel_key.8
index 2e569730abbb..e979a74715cb 100644
--- a/man/man8/tc-tunnel_key.8
+++ b/man/man8/tc-tunnel_key.8
@@ -16,6 +16,7 @@ tunnel_key - Tunnel metadata manipulation
 .IR ADDRESS
 .BI id " KEY_ID"
 .BI dst_port " UDP_PORT"
+.RB "[ " csum " | " nocsum " ]"
 
 .SH DESCRIPTION
 The
@@ -77,6 +78,23 @@ Outer header destination IP address (IPv4 or IPv6)
 .TP
 .B dst_port
 Outer header destination UDP port
+.TP
+.RB [ no ] csum
+Controlls outer UDP checksum. When set to
+.B csum
+(which is default), the outer UDP checksum is calculated and included in the
+packets. When set to
+.BR nocsum ,
+outer UDP checksum is zero. Note that when using zero UDP checksums with
+IPv6, the other tunnel endpoint must be configured to accept such packets.
+In Linux, this would be the
+.B udp6zerocsumrx
+option for the VXLAN tunnel interface.
+.IP
+If using
+.B nocsum
+with IPv6, be sure you know what you are doing. Zero UDP checksums provide
+weaker protection against corrupted packets. See RFC6935 for details.
 .RE
 .SH EXAMPLES
 The following example encapsulates incoming ICMP packets on eth0 into a vxlan
diff --git a/tc/m_tunnel_key.c b/tc/m_tunnel_key.c
index 6faf9632058a..1cdd03560c35 100644
--- a/tc/m_tunnel_key.c
+++ b/tc/m_tunnel_key.c
@@ -28,7 +28,8 @@ static void explain(void)
"id  (mandatory)\n"
"src_ip  (mandatory)\n"
"dst_ip  (mandatory)\n"
-   "dst_port \n");
+   "dst_port \n"
+   "csum | nocsum (default is \"csum\")\n");
 }
 
 static void usage(void)
@@ -92,6 +93,7 @@ static int parse_tunnel_key(struct action_util *a, int 
*argc_p, char ***argv_p,
int has_src_ip = 0;
int has_dst_ip = 0;
int has_key_id = 0;
+   int csum = 1;
 
if (matches(*argv, "tunnel_key") != 0)
return -1;
@@ -156,6 +158,10 @@ static int parse_tunnel_key(struct action_util *a, int 
*argc_p, char ***argv_p,
fprintf(stderr, "Illegal \"dst port\"\n");
return -1;
}
+   } else if (matches(*argv, "csum") == 0) {
+   csum = 1;
+   } else if (matches(*argv, "nocsum") == 0) {
+   csum = 0;
} else if (matches(*argv, "help") == 0) {
usage();
} else {
@@ -164,6 +170,8 @@ static int parse_tunnel_key(struct action_util *a, int 
*argc_p, char ***argv_p,
NEXT_ARG_FWD();
}
 
+   addattr8(n, MAX_MSG, TCA_TUNNEL_KEY_NO_CSUM, !csum);
+
parse_action_control_dflt(, , ,
  false, TC_ACT_PIPE);
 
@@ -233,6 +241,15 @@ static void tunnel_key_print_dst_port(FILE *f, char *name,
fprintf(f, "\n\t%s %d", name, rta_getattr_be16(attr));
 }
 
+static void tunnel_key_print_flag(FILE *f, const char *name_on,
+ const char *name_off,
+ struct rtattr *attr)
+{
+   if (!attr)
+   return;
+   fprintf(f, "\n\t%s", rta_getattr_u8(attr) ? name_on : name_off);
+}
+
 static int print_tunnel_key(struct action_util *au, FILE *f, struct rtattr 
*arg)
 {
struct rtattr *tb[TCA_TUNNEL_KEY_MAX + 1];
@@ -269,6 +286,8 @@ static int print_tunnel_key(struct action_util *au, FILE 
*f, struct rtattr *arg)
tb[TCA_TUNNEL_KEY_ENC_KEY_ID]);
tunnel_key_print_dst_port(f, "dst_port",
  tb[TCA_TUNNEL_KEY_ENC_DST_PORT]);
+   tunnel_key_print_flag(f, "nocsum", "csum",
+ tb[TCA_TUNNEL_KEY_NO_CSUM]);
break;
}
print_action_control(f, " ", parm->action, "");
-- 
1.8.3.1



[PATCH iproute2 1/2] tc: m_tunnel_key: reformat the usage text

2017-06-14 Thread Jiri Benc
Adding new tunnel key fields would cause the usage line overflow 80 chars.
Make the usage text similar to other commands.

Signed-off-by: Jiri Benc 
---
 tc/m_tunnel_key.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tc/m_tunnel_key.c b/tc/m_tunnel_key.c
index fb418a76bd79..6faf9632058a 100644
--- a/tc/m_tunnel_key.c
+++ b/tc/m_tunnel_key.c
@@ -22,7 +22,13 @@
 static void explain(void)
 {
fprintf(stderr, "Usage: tunnel_key unset\n");
-   fprintf(stderr, "   tunnel_key set id TUNNELID src_ip IP dst_ip IP 
dst_port UDP_PORT\n");
+   fprintf(stderr, "   tunnel_key set \n");
+   fprintf(stderr,
+   "Where TUNNEL_KEY is a combination of:\n"
+   "id  (mandatory)\n"
+   "src_ip  (mandatory)\n"
+   "dst_ip  (mandatory)\n"
+   "dst_port \n");
 }
 
 static void usage(void)
-- 
1.8.3.1



Re: [patch iproute2 v2 repost 2/3] tc: actions: add helpers to parse and print control actions

2017-06-14 Thread Jiri Benc
On Wed, 14 Jun 2017 21:18:50 +0200, Jiri Pirko wrote:
> Isn't it fixed by:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/commit/?h=net-next=18f05d06016d9492c87fd105d831de0d6d858f43
> 
> ?

Doesn't seem so. The current net-next branch with this commit included
fails in the same way.

 Jiri


Re: [PATCH net-next] net: use skb_unref() in napi_consume_skb()

2017-06-14 Thread David Miller
From: Paolo Abeni 
Date: Wed, 14 Jun 2017 11:48:48 +0200

> The commit 83ada39bb79d ("net: factor out a helper to decrement the
> skb refcount") provided and used a helper for decrementing skb usage,
> but I missed at least a spot for it.
> 
> This change remove some more duplicated code reusing skb_unref() in
> napi_consume_skb(), too. The helper uses an additional, unneeded
> unlikely(!skb) test - napi_consume_skb() already check it a few lines
> above - but the compiler is smart enough to optimize the duplicated
> test out.
> 
> Signed-off-by: Paolo Abeni 

Applied.


[PATCH net-next 1/2] net: sched: act_tunnel_key: request UDP checksum by default

2017-06-14 Thread Jiri Benc
There's currently no way to request (outer) UDP checksum with
act_tunnel_key. This is problem especially for IPv6. Right now, tunnel_key
action with IPv6 does not work without going through hassles: both sides
have to have udp6zerocsumrx configured on the tunnel interface. This is
obviously not a good solution universally.

It makes more sense to compute the UDP checksum by default even for IPv4.
Just set the default to request the checksum when using act_tunnel_key.

Signed-off-by: Jiri Benc 
---
 net/sched/act_tunnel_key.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/sched/act_tunnel_key.c b/net/sched/act_tunnel_key.c
index b9a2f241a5b3..b90effa10eb5 100644
--- a/net/sched/act_tunnel_key.c
+++ b/net/sched/act_tunnel_key.c
@@ -125,7 +125,7 @@ static int tunnel_key_init(struct net *net, struct nlattr 
*nla,
daddr = 
nla_get_in_addr(tb[TCA_TUNNEL_KEY_ENC_IPV4_DST]);
 
metadata = __ip_tun_set_dst(saddr, daddr, 0, 0,
-   dst_port, TUNNEL_KEY,
+   dst_port, TUNNEL_KEY | 
TUNNEL_CSUM,
key_id, 0);
} else if (tb[TCA_TUNNEL_KEY_ENC_IPV6_SRC] &&
   tb[TCA_TUNNEL_KEY_ENC_IPV6_DST]) {
@@ -136,7 +136,7 @@ static int tunnel_key_init(struct net *net, struct nlattr 
*nla,
daddr = 
nla_get_in6_addr(tb[TCA_TUNNEL_KEY_ENC_IPV6_DST]);
 
metadata = __ipv6_tun_set_dst(, , 0, 0, 
dst_port,
- 0, TUNNEL_KEY,
+ 0, TUNNEL_KEY | 
TUNNEL_CSUM,
  key_id, 0);
}
 
-- 
1.8.3.1



[PATCH net-next 0/2] net: sched: act_tunnel_key: UDP checksums

2017-06-14 Thread Jiri Benc
Currently, the tunnel_key tc action does not set TUNNEL_CSUM, thus
transmitting packets with zero UDP checksum. This is inconsistent with how
we treat non-lwt UDP tunnels where the default is to fill in the UDP
checksum. Non-zero UDP checksum is the better default anyway for various
reasons previously discussed.

Make this configurable for the tunnel_key tc action with the default being
non-zero checksum. Saves a lot of surprises especially with IPv6.

Signed-off-by: Jiri Benc 


Jiri Benc (2):
  net: sched: act_tunnel_key: request UDP checksum by default
  net: sched: act_tunnel_key: make UDP checksum configurable

 include/uapi/linux/tc_act/tc_tunnel_key.h |  1 +
 net/sched/act_tunnel_key.c| 15 ---
 2 files changed, 13 insertions(+), 3 deletions(-)

-- 
1.8.3.1



[PATCH net-next 2/2] net: sched: act_tunnel_key: make UDP checksum configurable

2017-06-14 Thread Jiri Benc
Allow requesting of zero UDP checksum for encapsulated packets. The name and
meaning of the attribute is "NO_CSUM" in order to have the same meaning of
the attribute missing and being 0.

Signed-off-by: Jiri Benc 
---
 include/uapi/linux/tc_act/tc_tunnel_key.h |  1 +
 net/sched/act_tunnel_key.c| 15 ---
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/include/uapi/linux/tc_act/tc_tunnel_key.h 
b/include/uapi/linux/tc_act/tc_tunnel_key.h
index 84ea55e1076b..afcd4be953e2 100644
--- a/include/uapi/linux/tc_act/tc_tunnel_key.h
+++ b/include/uapi/linux/tc_act/tc_tunnel_key.h
@@ -34,6 +34,7 @@ enum {
TCA_TUNNEL_KEY_ENC_KEY_ID,  /* be64 */
TCA_TUNNEL_KEY_PAD,
TCA_TUNNEL_KEY_ENC_DST_PORT,/* be16 */
+   TCA_TUNNEL_KEY_NO_CSUM, /* u8 */
__TCA_TUNNEL_KEY_MAX,
 };
 
diff --git a/net/sched/act_tunnel_key.c b/net/sched/act_tunnel_key.c
index b90effa10eb5..fd7e75679c69 100644
--- a/net/sched/act_tunnel_key.c
+++ b/net/sched/act_tunnel_key.c
@@ -67,6 +67,7 @@ static int tunnel_key_act(struct sk_buff *skb, const struct 
tc_action *a,
[TCA_TUNNEL_KEY_ENC_IPV6_DST] = { .len = sizeof(struct in6_addr) },
[TCA_TUNNEL_KEY_ENC_KEY_ID]   = { .type = NLA_U32 },
[TCA_TUNNEL_KEY_ENC_DST_PORT] = {.type = NLA_U16},
+   [TCA_TUNNEL_KEY_NO_CSUM]  = { .type = NLA_U8 },
 };
 
 static int tunnel_key_init(struct net *net, struct nlattr *nla,
@@ -83,6 +84,7 @@ static int tunnel_key_init(struct net *net, struct nlattr 
*nla,
bool exists = false;
__be16 dst_port = 0;
__be64 key_id;
+   __be16 flags;
int ret = 0;
int err;
 
@@ -113,6 +115,11 @@ static int tunnel_key_init(struct net *net, struct nlattr 
*nla,
 
key_id = 
key32_to_tunnel_id(nla_get_be32(tb[TCA_TUNNEL_KEY_ENC_KEY_ID]));
 
+   flags = TUNNEL_KEY | TUNNEL_CSUM;
+   if (tb[TCA_TUNNEL_KEY_NO_CSUM] &&
+   nla_get_u8(tb[TCA_TUNNEL_KEY_NO_CSUM]))
+   flags &= ~TUNNEL_CSUM;
+
if (tb[TCA_TUNNEL_KEY_ENC_DST_PORT])
dst_port = 
nla_get_be16(tb[TCA_TUNNEL_KEY_ENC_DST_PORT]);
 
@@ -125,7 +132,7 @@ static int tunnel_key_init(struct net *net, struct nlattr 
*nla,
daddr = 
nla_get_in_addr(tb[TCA_TUNNEL_KEY_ENC_IPV4_DST]);
 
metadata = __ip_tun_set_dst(saddr, daddr, 0, 0,
-   dst_port, TUNNEL_KEY | 
TUNNEL_CSUM,
+   dst_port, flags,
key_id, 0);
} else if (tb[TCA_TUNNEL_KEY_ENC_IPV6_SRC] &&
   tb[TCA_TUNNEL_KEY_ENC_IPV6_DST]) {
@@ -136,7 +143,7 @@ static int tunnel_key_init(struct net *net, struct nlattr 
*nla,
daddr = 
nla_get_in6_addr(tb[TCA_TUNNEL_KEY_ENC_IPV6_DST]);
 
metadata = __ipv6_tun_set_dst(, , 0, 0, 
dst_port,
- 0, TUNNEL_KEY | 
TUNNEL_CSUM,
+ 0, flags,
  key_id, 0);
}
 
@@ -266,7 +273,9 @@ static int tunnel_key_dump(struct sk_buff *skb, struct 
tc_action *a,
if (nla_put_be32(skb, TCA_TUNNEL_KEY_ENC_KEY_ID, key_id) ||
tunnel_key_dump_addresses(skb,
  
>tcft_enc_metadata->u.tun_info) ||
-   nla_put_be16(skb, TCA_TUNNEL_KEY_ENC_DST_PORT, key->tp_dst))
+   nla_put_be16(skb, TCA_TUNNEL_KEY_ENC_DST_PORT, key->tp_dst) 
||
+   nla_put_u8(skb, TCA_TUNNEL_KEY_NO_CSUM,
+  !(key->tun_flags & TUNNEL_CSUM)))
goto nla_put_failure;
}
 
-- 
1.8.3.1



Re: pull request: bluetooth-next 2017-06-14

2017-06-14 Thread David Miller
From: Johan Hedberg 
Date: Wed, 14 Jun 2017 12:44:21 +0300

> Here's another batch of Bluetooth patches for the 4.13 kernel:
> 
>  - Fix for Broadcom controllers not supporting Event Mask Page 2
>  - New QCA ROME USB ID for btusb
>  - Fix for Security Manager Protocol to use constant-time memcmp
>  - Improved support for TI WiLink chips
> 
> Please let me know if there are any issues pulling. Thanks.

Pulled, thanks Johan.


Re: [PATCH] batman-adv: Remove unnecessary length qualifier in %14pM

2017-06-14 Thread David Miller
From: Joe Perches 
Date: Wed, 14 Jun 2017 02:33:52 -0700

> It's misleading and unnecessary.
> 
> Signed-off-by: Joe Perches 

Simon will you take this into your batman-adv tree?

Thanks.


Re: [PATCH net-next] qed: Fix an off by one bug

2017-06-14 Thread David Miller
From: Dan Carpenter 
Date: Wed, 14 Jun 2017 12:10:10 +0300

> The p_l2_info->pp_qid_usage[] array has "p_l2_info->queues" elements so
> the > here should be a >= or we write beyond the end of the array.
> 
> Fixes: bbe3f233ec5e ("qed: Assign a unique per-queue index to queue-cid")
> Signed-off-by: Dan Carpenter 

Applied.


Re: [patch net-next 0/2] mlxsw: Add support for cable info access

2017-06-14 Thread David Miller
From: Jiri Pirko 
Date: Wed, 14 Jun 2017 09:27:38 +0200

> Add support for cable info access via ethtool. This is done by
> accessing the SFP+/QSFP internal EEPROM.

Series applied, thanks Jiri.


Re: [patch iproute2 v2 repost 2/3] tc: actions: add helpers to parse and print control actions

2017-06-14 Thread Jiri Pirko
Wed, Jun 14, 2017 at 08:32:22PM CEST, jb...@redhat.com wrote:
>On Tue, 16 May 2017 19:29:36 +0200, Jiri Pirko wrote:
>> From: Jiri Pirko 
>> 
>> Each tc action is terminated by a control action. Each action parses and
>> prints then intividually. Introduce set of helpers and allow to share
>> this code.
>
>This patch, as indicated by git bisect, broke tc if there are multiple
>actions specified. This somehow non-real life reproducer (the real case
>where this broke for me was more complex) works fine with 732f03461bc4:
>
># tc filter add dev eth0 parent 1: matchall action vlan push id 1 action drop
>
>while with both the current net-next and with e67aba559581, the result
>is:
>
># tc filter add dev eth0 parent 1: matchall action vlan push id 1 action drop
>Bad action type action

Isn't it fixed by:

https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/commit/?h=net-next=18f05d06016d9492c87fd105d831de0d6d858f43

?

I will try this tomorrow


Re: [PATCH] net: update undefined ->ndo_change_mtu() comment

2017-06-14 Thread David Miller
From: Magnus Damm 
Date: Wed, 14 Jun 2017 16:15:24 +0900

> From: Magnus Damm 
> 
> Update ->ndo_change_mtu() callback comment to remove text
> about returning error in case of undefined callback. This
> change makes the comment match the existing code behavior.
> 
> Signed-off-by: Magnus Damm 

Applied, thanks Magnus.


Re: [PATCH net-next 01/11] ipv6: skb_put_zero() used to optimize code

2017-06-14 Thread Stephen Hemminger
On Wed, 14 Jun 2017 21:01:32 +0200
Johannes Berg  wrote:

> On Wed, 2017-06-14 at 08:44 -0700, Stephen Hemminger wrote:
> >   
> > >   memcpy(skb_put(skb, sizeof(ra)), ra, sizeof(ra));
> > >  
> > > - hdr = (struct mld_msg *) skb_put(skb, sizeof(struct
> > > mld_msg));
> > > - memset(hdr, 0, sizeof(struct mld_msg));
> > > + hdr = (struct mld_msg *) skb_put_zero(skb, sizeof(struct
> > > mld_msg));  
> > 
> > Why does skb_put_zero return char * instead of void *?
> > If returned void * it would save having to add lots of casts.
> > 
> > One could even go farther by making skb_put_zero a macro and
> > use typeof().  
> 
> I just copied it from skb_put() - you could ask the same there? :)

My taste is to  have less casts. Never understood why so many skb_
functions returned char *, probably a leftover from older Unix style.


  1   2   3   >