[PATCH] net: cavium: Add fine-granular dependencies on PCI

[Alexander Sverdlin]

Add dependencies on PCI where necessary.

Fixes: 7e2bc7fb65 ("net: cavium: Drop dependency of NET_VENDOR_CAVIUM on PCI")
Signed-off-by: Alexander Sverdlin 
---
 drivers/net/ethernet/cavium/Kconfig | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/cavium/Kconfig 
b/drivers/net/ethernet/cavium/Kconfig
index 4c3a5c354497..ba65ed49f480 100644
--- a/drivers/net/ethernet/cavium/Kconfig
+++ b/drivers/net/ethernet/cavium/Kconfig
@@ -14,7 +14,7 @@ if NET_VENDOR_CAVIUM
 
 config THUNDER_NIC_PF
tristate "Thunder Physical function driver"
-   depends on 64BIT
+   depends on 64BIT && PCI
select THUNDER_NIC_BGX
---help---
  This driver supports Thunder's NIC physical function.
@@ -27,13 +27,13 @@ config THUNDER_NIC_PF
 config THUNDER_NIC_VF
tristate "Thunder Virtual function driver"
imply CAVIUM_PTP
-   depends on 64BIT
+   depends on 64BIT && PCI
---help---
  This driver supports Thunder's NIC virtual function
 
 config THUNDER_NIC_BGX
tristate "Thunder MAC interface driver (BGX)"
-   depends on 64BIT
+   depends on 64BIT && PCI
select PHYLIB
select MDIO_THUNDER
select THUNDER_NIC_RGX
@@ -43,7 +43,7 @@ configTHUNDER_NIC_BGX
 
 config THUNDER_NIC_RGX
tristate "Thunder MAC interface driver (RGX)"
-   depends on 64BIT
+   depends on 64BIT && PCI
select PHYLIB
select MDIO_THUNDER
---help---
@@ -52,7 +52,7 @@ configTHUNDER_NIC_RGX
 
 config CAVIUM_PTP
tristate "Cavium PTP coprocessor as PTP clock"
-   depends on 64BIT
+   depends on 64BIT && PCI
imply PTP_1588_CLOCK
default y
---help---
@@ -64,7 +64,7 @@ config CAVIUM_PTP
 
 config LIQUIDIO
tristate "Cavium LiquidIO support"
-   depends on 64BIT
+   depends on 64BIT && PCI
depends on MAY_USE_DEVLINK
imply PTP_1588_CLOCK
select FW_LOADER
-- 
2.18.0

[PATCH v2] net: cavium: Drop dependency of NET_VENDOR_CAVIUM on PCI

[Alexander Sverdlin]

Octeon Ethernet drivers work perfectly without PCI.

Signed-off-by: Alexander Sverdlin 
---
 drivers/net/ethernet/cavium/Kconfig | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/cavium/Kconfig 
b/drivers/net/ethernet/cavium/Kconfig
index 043e3c11c42b..ba65ed49f480 100644
--- a/drivers/net/ethernet/cavium/Kconfig
+++ b/drivers/net/ethernet/cavium/Kconfig
@@ -4,7 +4,6 @@
 
 config NET_VENDOR_CAVIUM
bool "Cavium ethernet drivers"
-   depends on PCI
default y
---help---
  Select this option if you want enable Cavium network support.
@@ -15,7 +14,7 @@ if NET_VENDOR_CAVIUM
 
 config THUNDER_NIC_PF
tristate "Thunder Physical function driver"
-   depends on 64BIT
+   depends on 64BIT && PCI
select THUNDER_NIC_BGX
---help---
  This driver supports Thunder's NIC physical function.
@@ -28,13 +27,13 @@ config THUNDER_NIC_PF
 config THUNDER_NIC_VF
tristate "Thunder Virtual function driver"
imply CAVIUM_PTP
-   depends on 64BIT
+   depends on 64BIT && PCI
---help---
  This driver supports Thunder's NIC virtual function
 
 config THUNDER_NIC_BGX
tristate "Thunder MAC interface driver (BGX)"
-   depends on 64BIT
+   depends on 64BIT && PCI
select PHYLIB
select MDIO_THUNDER
select THUNDER_NIC_RGX
@@ -44,7 +43,7 @@ configTHUNDER_NIC_BGX
 
 config THUNDER_NIC_RGX
tristate "Thunder MAC interface driver (RGX)"
-   depends on 64BIT
+   depends on 64BIT && PCI
select PHYLIB
select MDIO_THUNDER
---help---
@@ -53,7 +52,7 @@ configTHUNDER_NIC_RGX
 
 config CAVIUM_PTP
tristate "Cavium PTP coprocessor as PTP clock"
-   depends on 64BIT
+   depends on 64BIT && PCI
imply PTP_1588_CLOCK
default y
---help---
@@ -65,7 +64,7 @@ config CAVIUM_PTP
 
 config LIQUIDIO
tristate "Cavium LiquidIO support"
-   depends on 64BIT
+   depends on 64BIT && PCI
depends on MAY_USE_DEVLINK
imply PTP_1588_CLOCK
select FW_LOADER
-- 
2.18.0

[PATCH] octeon_mgmt: Fix MIX registers configuration on MTU setup

[Alexander Sverdlin]

From: Alexander Sverdlin 

octeon_mgmt driver doesn't drop RX frames that are 1-4 bytes bigger than
MTU set for the corresponding interface. The problem is in the
AGL_GMX_RX0/1_FRM_MAX register setting, which should not account for VLAN
tagging.

According to Octeon HW manual:
"For tagged frames, MAX increases by four bytes for each VLAN found up to a
maximum of two VLANs, or MAX + 8 bytes."

OCTEON_FRAME_HEADER_LEN "define" is fine for ring buffer management, but
should not be used for AGL_GMX_RX0/1_FRM_MAX.

The problem could be easily reproduced using "ping" command. If affected
system has default MTU 1500, other host (having MTU >= 1504) can
successfully "ping" the affected system with payload size 1473-1476,
resulting in IP packets of size 1501-1504 accepted by the mgmt driver.
Fixed system still accepts IP packets of 1500 bytes even with VLAN tagging,
because the limits are lifted in HW as expected, for every VLAN tag.

Signed-off-by: Alexander Sverdlin 
---
 drivers/net/ethernet/cavium/octeon/octeon_mgmt.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c 
b/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
index 3f6afb54a5eb..bb43ddb7539e 100644
--- a/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
+++ b/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
@@ -643,13 +643,21 @@ static int octeon_mgmt_set_mac_address(struct net_device 
*netdev, void *addr)
 static int octeon_mgmt_change_mtu(struct net_device *netdev, int new_mtu)
 {
struct octeon_mgmt *p = netdev_priv(netdev);
-   int size_without_fcs = new_mtu + OCTEON_MGMT_RX_HEADROOM;
+   int max_packet = new_mtu + ETH_HLEN + ETH_FCS_LEN;
 
netdev->mtu = new_mtu;
 
-   cvmx_write_csr(p->agl + AGL_GMX_RX_FRM_MAX, size_without_fcs);
+   /* HW lifts the limit if the frame is VLAN tagged
+* (+4 bytes per each tag, up to two tags)
+*/
+   cvmx_write_csr(p->agl + AGL_GMX_RX_FRM_MAX, max_packet);
+   /* Set the hardware to truncate packets larger than the MTU. The jabber
+* register must be set to a multiple of 8 bytes, so round up. JABBER is
+* an unconditional limit, so we need to account for two possible VLAN
+* tags.
+*/
cvmx_write_csr(p->agl + AGL_GMX_RX_JABBER,
-  (size_without_fcs + 7) & 0xfff8);
+  (max_packet + 7 + VLAN_HLEN * 2) & 0xfff8);
 
return 0;
 }
-- 
2.18.0

[PATCH] net: cavium: Drop dependency of NET_VENDOR_CAVIUM on PCI

[Alexander Sverdlin]

Octeon Ethernet drivers work perfectly without PCI.

Signed-off-by: Alexander Sverdlin 
---
 drivers/net/ethernet/cavium/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/cavium/Kconfig 
b/drivers/net/ethernet/cavium/Kconfig
index 043e3c11c42b..4c3a5c354497 100644
--- a/drivers/net/ethernet/cavium/Kconfig
+++ b/drivers/net/ethernet/cavium/Kconfig
@@ -4,7 +4,6 @@
 
 config NET_VENDOR_CAVIUM
bool "Cavium ethernet drivers"
-   depends on PCI
default y
---help---
  Select this option if you want enable Cavium network support.
-- 
2.18.0

Re: [PATCH v2 net-next 06/12] ep93xx_eth: add GRO support

[Alexander Sverdlin]

Hello all,

On 15/05/17 23:02, Alexander Sverdlin wrote:
>>> I don't know if we really care about this hardware anymore (I don't),
>>> but the ep93xx platform is still listed as being maintained in the
>>> MAINTAINERS file -- adding Ryan and Hartley.
>> I no longer have any ep93xx hardware to test with, and I never looked at
>> the Ethernet, so don't know the details. I think there are still a
>> handful of users. Adding Alexander who sent an ADC support series this
>> week, who might be able to test this?
> Yes, I very much care about ep93xx code being functional :)
> I'll test the patches tomorrow.

it turns out I've used this patch two weeks long already in 4.11; but I've spent
a couple of hours now torturing the new driver and was not able to provoke
any inadequate behavior. It either receives all packets in time or not at all.
If IRQs would be edge-triggered, I'd expect some stale packets, which do not
arrive at first, but then appear with the packets coming next. This is not
the case. I've used pktgen module for this, with minimal packets and
different bursts.

netperf shows 45Mbit/s on UDP_STREAM test, which is also fair amount for
200MHz CPU.

So, I see no problems with the change.

--
Alexander.

Re: [PATCH v2 net-next 06/12] ep93xx_eth: add GRO support

[Alexander Sverdlin]

Hi!

On Mon May 15 22:43:20 2017 Ryan Mallon  wrote:
> > I don't know if we really care about this hardware anymore (I don't),
> > but the ep93xx platform is still listed as being maintained in the
> > MAINTAINERS file -- adding Ryan and Hartley.
> 
> I no longer have any ep93xx hardware to test with, and I never looked at
> the Ethernet, so don't know the details. I think there are still a
> handful of users. Adding Alexander who sent an ADC support series this
> week, who might be able to test this?

Yes, I very much care about ep93xx code being functional :)
I'll test the patches tomorrow.

Alexander.

Re: [PATCH 3/4] xfrm: Prepare for CRYPTO_MAX_ALG_NAME expansion

[Alexander Sverdlin]

On 06/04/17 10:16, Herbert Xu wrote:
> This patch fixes the xfrm_user code to use the actual array size
> rather than the hard-coded CRYPTO_MAX_ALG_NAME length.  This is
> because the array size is fixed at 64 bytes while we want to increase
> the in-kernel CRYPTO_MAX_ALG_NAME value.
> 
> Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>

Acked-by: Alexander Sverdlin <alexander.sverd...@nokia.com>
Tested-by: Alexander Sverdlin <alexander.sverd...@nokia.com>

> ---
> 
>  net/xfrm/xfrm_user.c |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
> index 9705c27..96557cf 100644
> --- a/net/xfrm/xfrm_user.c
> +++ b/net/xfrm/xfrm_user.c
> @@ -55,7 +55,7 @@ static int verify_one_alg(struct nlattr **attrs, enum 
> xfrm_attr_type_t type)
>   return -EINVAL;
>   }
>  
> - algp->alg_name[CRYPTO_MAX_ALG_NAME - 1] = '\0';
> + algp->alg_name[sizeof(algp->alg_name) - 1] = '\0';
>   return 0;
>  }
>  
> @@ -71,7 +71,7 @@ static int verify_auth_trunc(struct nlattr **attrs)
>   if (nla_len(rt) < xfrm_alg_auth_len(algp))
>   return -EINVAL;
>  
> - algp->alg_name[CRYPTO_MAX_ALG_NAME - 1] = '\0';
> + algp->alg_name[sizeof(algp->alg_name) - 1] = '\0';
>   return 0;
>  }
>  
> @@ -87,7 +87,7 @@ static int verify_aead(struct nlattr **attrs)
>   if (nla_len(rt) < aead_len(algp))
>   return -EINVAL;
>  
> -     algp->alg_name[CRYPTO_MAX_ALG_NAME - 1] = '\0';
> + algp->alg_name[sizeof(algp->alg_name) - 1] = '\0';
>   return 0;
>  }
>  
> 

-- 
Best regards,
Alexander Sverdlin.

Re: [PATCH 4/4] crypto: api - Extend algorithm name limit to 128 bytes

[Alexander Sverdlin]

On 06/04/17 10:16, Herbert Xu wrote:
> With the new explicit IV generators, we may now exceed the 64-byte
> length limit on the algorithm name, e.g., with
> 
>   echainiv(authencesn(hmac(sha256-generic),cbc(des3_ede-generic)))
> 
> This patch extends the length limit to 128 bytes.
> 
> Reported-by: Alexander Sverdlin <alexander.sverd...@nokia.com>
> Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>

Acked-by: Alexander Sverdlin <alexander.sverd...@nokia.com>
Tested-by: Alexander Sverdlin <alexander.sverd...@nokia.com>

> ---
> 
>  include/linux/crypto.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/crypto.h b/include/linux/crypto.h
> index c0b0cf3..84da997 100644
> --- a/include/linux/crypto.h
> +++ b/include/linux/crypto.h
> @@ -123,7 +123,7 @@
>  /*
>   * Miscellaneous stuff.
>   */
> -#define CRYPTO_MAX_ALG_NAME  64
> +#define CRYPTO_MAX_ALG_NAME  128
>  
>  /*
>   * The macro CRYPTO_MINALIGN_ATTR (along with the void * type in the actual
> 

-- 
Best regards,
Alexander Sverdlin.

Re: [PATCH 1/4] crypto: user - Prepare for CRYPTO_MAX_ALG_NAME expansion

[Alexander Sverdlin]

On 06/04/17 10:16, Herbert Xu wrote:
> This patch hard-codes CRYPTO_MAX_NAME in the user-space API to
> 64, which is the current value of CRYPTO_MAX_ALG_NAME.  This patch
> also replaces all remaining occurences of CRYPTO_MAX_ALG_NAME
> in the user-space API with CRYPTO_MAX_NAME.
> 
> This way the user-space API will not be modified when we raise
> the value of CRYPTO_MAX_ALG_NAME.
> 
> Furthermore, the code has been updated to handle names longer than
> the user-space API.  They will be truncated.
> 
> Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>

Acked-by: Alexander Sverdlin <alexander.sverd...@nokia.com>
Tested-by: Alexander Sverdlin <alexander.sverd...@nokia.com>

> ---
> 
>  crypto/crypto_user.c|   18 +-
>  include/uapi/linux/cryptouser.h |   10 +-
>  2 files changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/crypto/crypto_user.c b/crypto/crypto_user.c
> index a90404a..89acaab 100644
> --- a/crypto/crypto_user.c
> +++ b/crypto/crypto_user.c
> @@ -83,7 +83,7 @@ static int crypto_report_cipher(struct sk_buff *skb, struct 
> crypto_alg *alg)
>  {
>   struct crypto_report_cipher rcipher;
>  
> - strncpy(rcipher.type, "cipher", sizeof(rcipher.type));
> + strlcpy(rcipher.type, "cipher", sizeof(rcipher.type));
>  
>   rcipher.blocksize = alg->cra_blocksize;
>   rcipher.min_keysize = alg->cra_cipher.cia_min_keysize;
> @@ -102,7 +102,7 @@ static int crypto_report_comp(struct sk_buff *skb, struct 
> crypto_alg *alg)
>  {
>   struct crypto_report_comp rcomp;
>  
> - strncpy(rcomp.type, "compression", sizeof(rcomp.type));
> + strlcpy(rcomp.type, "compression", sizeof(rcomp.type));
>   if (nla_put(skb, CRYPTOCFGA_REPORT_COMPRESS,
>   sizeof(struct crypto_report_comp), ))
>   goto nla_put_failure;
> @@ -116,7 +116,7 @@ static int crypto_report_acomp(struct sk_buff *skb, 
> struct crypto_alg *alg)
>  {
>   struct crypto_report_acomp racomp;
>  
> - strncpy(racomp.type, "acomp", sizeof(racomp.type));
> + strlcpy(racomp.type, "acomp", sizeof(racomp.type));
>  
>   if (nla_put(skb, CRYPTOCFGA_REPORT_ACOMP,
>   sizeof(struct crypto_report_acomp), ))
> @@ -131,7 +131,7 @@ static int crypto_report_akcipher(struct sk_buff *skb, 
> struct crypto_alg *alg)
>  {
>   struct crypto_report_akcipher rakcipher;
>  
> - strncpy(rakcipher.type, "akcipher", sizeof(rakcipher.type));
> + strlcpy(rakcipher.type, "akcipher", sizeof(rakcipher.type));
>  
>   if (nla_put(skb, CRYPTOCFGA_REPORT_AKCIPHER,
>   sizeof(struct crypto_report_akcipher), ))
> @@ -146,7 +146,7 @@ static int crypto_report_kpp(struct sk_buff *skb, struct 
> crypto_alg *alg)
>  {
>   struct crypto_report_kpp rkpp;
>  
> - strncpy(rkpp.type, "kpp", sizeof(rkpp.type));
> + strlcpy(rkpp.type, "kpp", sizeof(rkpp.type));
>  
>   if (nla_put(skb, CRYPTOCFGA_REPORT_KPP,
>   sizeof(struct crypto_report_kpp), ))
> @@ -160,10 +160,10 @@ static int crypto_report_kpp(struct sk_buff *skb, 
> struct crypto_alg *alg)
>  static int crypto_report_one(struct crypto_alg *alg,
>struct crypto_user_alg *ualg, struct sk_buff *skb)
>  {
> - strncpy(ualg->cru_name, alg->cra_name, sizeof(ualg->cru_name));
> - strncpy(ualg->cru_driver_name, alg->cra_driver_name,
> + strlcpy(ualg->cru_name, alg->cra_name, sizeof(ualg->cru_name));
> + strlcpy(ualg->cru_driver_name, alg->cra_driver_name,
>   sizeof(ualg->cru_driver_name));
> - strncpy(ualg->cru_module_name, module_name(alg->cra_module),
> + strlcpy(ualg->cru_module_name, module_name(alg->cra_module),
>   sizeof(ualg->cru_module_name));
>  
>   ualg->cru_type = 0;
> @@ -176,7 +176,7 @@ static int crypto_report_one(struct crypto_alg *alg,
>   if (alg->cra_flags & CRYPTO_ALG_LARVAL) {
>   struct crypto_report_larval rl;
>  
> - strncpy(rl.type, "larval", sizeof(rl.type));
> + strlcpy(rl.type, "larval", sizeof(rl.type));
>   if (nla_put(skb, CRYPTOCFGA_REPORT_LARVAL,
>   sizeof(struct crypto_report_larval), ))
>   goto nla_put_failure;
> diff --git a/include/uapi/linux/cryptouser.h b/include/uapi/linux/cryptouser.h
> index 11d21fc..b4def5c 100644
> --- a/include/uapi/linux/cryptouser.h
> +++ b/include/uapi/linux/cryptouser.h
> @@ -31,7 +31,7 @@ enum {
>  #define CR

Re: [PATCH 0/4] crypto: CRYPTO_MAX_ALG_NAME is too low

[Alexander Sverdlin]

Hi!

On 06/04/17 10:15, Herbert Xu wrote:
> On Thu, Mar 16, 2017 at 03:16:29PM +0100, Alexander Sverdlin wrote:
>> This is a regression caused by 856e3f4092
>> ("crypto: seqiv - Add support for new AEAD interface")
>>
>> As I've said above, I can offer one of the two solutions, which patch should 
>> I send?
>> Or do you see any better alternatives?
> Here is a series of patches which should fix the problem.
> 
> The first three patches prepare the user-space interfaces to deal
> with longer names.  The final patch extends it.
> 
> Note that with crypto_user I haven't actually extended it to
> configure longer names.  It'll only be able to configure names
> less than 64 bytes.  However, it should be able to dump/read
> algorithms with longer names, albeit the name will be truncated
> to 64 bytes length.
> 
> Steffen, when convenient could you look into extending the crypto
> user interface to handle longer names (preferably arbitraty length
> since netlink should be able to deal with that)?
> 
> Likewise xfrm is still fixed to 64 bytes long.  But this should
> be OK as the problematic case only arises with IV generators for
> now and we do not allow IV generators to be specified through xfrm.
> 
> af_alg on the other hand now allows arbitrarily long names.

I'm not sure about patch 2 (as I've replied separately), but I've applied
and tested the whole series and it at least solves the original problem
with long algorithm name.

> As the final patch depends on all three it would be easiest if
> we pushed the xfrm patch through the crypto tree.  Steffen/David?

-- 
Best regards,
Alexander Sverdlin.

Re: [PATCH 2/4] crypto: af_alg - Allow arbitrarily long algorithm names

[Alexander Sverdlin]

Hi!

On 06/04/17 10:16, Herbert Xu wrote:
> This patch removes the hard-coded 64-byte limit on the length
> of the algorithm name through bind(2).  The address length can
> now exceed that.  The user-space structure remains unchanged.
> In order to use a longer name simply extend the salg_name array
> beyond its defined 64 bytes length.
> 
> Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
> ---
> 
>  crypto/af_alg.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/crypto/af_alg.c b/crypto/af_alg.c
> index 690deca..3556d8e 100644
> --- a/crypto/af_alg.c
> +++ b/crypto/af_alg.c
> @@ -160,11 +160,11 @@ static int alg_bind(struct socket *sock, struct 
> sockaddr *uaddr, int addr_len)
>   if (sock->state == SS_CONNECTED)
>   return -EINVAL;
>  
> - if (addr_len != sizeof(*sa))
> + if (addr_len < sizeof(*sa))
>   return -EINVAL;
>  
>   sa->salg_type[sizeof(sa->salg_type) - 1] = 0;
> - sa->salg_name[sizeof(sa->salg_name) - 1] = 0;
> + sa->salg_name[sizeof(sa->salg_name) + addr_len - sizeof(*sa) - 1] = 0;
>  
>   type = alg_get_type(sa->salg_type);
>   if (IS_ERR(type) && PTR_ERR(type) == -ENOENT) {

Why should userspace ever extend the structure if salg_name is hardcoded to 64 
in if_alg.h?
This patch doesn't change the behavior at all, or am I missing something?

-- 
Best regards,
Alexander Sverdlin.

Re: [PATCH] rionet: Don't try to corrupt skbuff assigning data pointer directly

[Alexander Sverdlin]

Hi David,

On 02/07/15 21:12, ext David Miller wrote:
 It's not allowed to assign data pointer of skbuff directly, this makes no 
 sense
  if the assigned pointer is the very same as already existing one, or it 
  brakes
  all the pointer arithmetics in all other cases. We cannot do better as just
  compare them and report BUG() in case of mismatch.
  
  Signed-off-by: Alexander Sverdlin alexander.sverd...@nokia.com
 BUG takes the entire machine out, which is worse than corrupting the
 skb-data
 
 If you really want to assert this condition, do it in a way that
 doesn't kill the entire machine.

In fact, the machine goes down, some milliseconds later, but because of the 
following
inconsistencies, which are misleading. The function has no way to signal an 
error and
this line of code is simply wrong. To prevent others from copying this error, 
we can
simply delete it. Would it be fine from your PoV?

-- 
Best regards,
Alexander Sverdlin.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] rionet: Don't try to corrupt skbuff assigning data pointer directly

[Alexander Sverdlin]

It's not allowed to assign data pointer of skbuff directly, this makes no sense
if the assigned pointer is the very same as already existing one, or it brakes
all the pointer arithmetics in all other cases. We cannot do better as just
compare them and report BUG() in case of mismatch.

Signed-off-by: Alexander Sverdlin alexander.sverd...@nokia.com
---

We came across this problem developing new code for Octeon2 RAPIDIO. For the 
last
10 years since original commit of the code this assignment did nothing as the
pointers were always same. But the bug in the new code discovered this one. So
better do BUG() immediately here, this would prevent longer debugging of the
following skbuff corruption.

 drivers/net/rionet.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/rionet.c b/drivers/net/rionet.c
index dac7a0d..34c27b8 100644
--- a/drivers/net/rionet.c
+++ b/drivers/net/rionet.c
@@ -104,7 +104,8 @@ static int rionet_rx_clean(struct net_device *ndev)
if (!(data = rio_get_inb_message(rnet-mport, RIONET_MAILBOX)))
break;

-   rnet-rx_skb[i]-data = data;
+   if (rnet-rx_skb[i]-data != data)
+   BUG();
skb_put(rnet-rx_skb[i], RIO_MAX_MSG_SIZE);
rnet-rx_skb[i]-protocol =
eth_type_trans(rnet-rx_skb[i], ndev);
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH resend] sctp: Fix race between OOTB responce and route removal

[Alexander Sverdlin]

: 0x0 from 0x8100 (relocation range: 
0x8000-0x9fff)
drm_kms_helper: panic occurred, switching back to text console
---[ end Kernel panic - not syncing: Fatal exception in interrupt

Signed-off-by: Alexander Sverdlin alexander.sverd...@nokia.com
Acked-by: Neil Horman nhor...@tuxdriver.com
Acked-by: Marcelo Ricardo Leitner marcelo.leit...@gmail.com
Acked-by: Vlad Yasevich vyasev...@gmail.com
---

This patch was already published in linux-sctp, now sending to netdev, as nobody
has picked it up.

Stable info: This patch would be beneficial for stable kernels down to 3.2, I 
believe.

 net/sctp/output.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/net/sctp/output.c b/net/sctp/output.c
index fc5e45b..abe7c2d 100644
--- a/net/sctp/output.c
+++ b/net/sctp/output.c
@@ -599,7 +599,9 @@ out:
return err;
 no_route:
kfree_skb(nskb);
-   IP_INC_STATS(sock_net(asoc-base.sk), IPSTATS_MIB_OUTNOROUTES);
+
+   if (asoc)
+   IP_INC_STATS(sock_net(asoc-base.sk), IPSTATS_MIB_OUTNOROUTES);
 
/* FIXME: Returning the 'err' will effect all the associations
 * associated with a socket, although only one of the paths of the
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html