linux-next: manual merge of the crypto tree with the net-next tree

linux-next: manual merge of the crypto tree with the net-next tree

[Stephen Rothwell]

Hi Herbert,

Today's linux-next merge of the crypto tree got a conflict in:

  drivers/net/ethernet/chelsio/cxgb4/cxgb4.h

between commit:

  9d5fd927d20b ("cxgb4/cxgb4vf: add support for ndo_set_vf_vlan")

from the net-next tree and commit:

  a6ec572bfa7d ("cxgb4: Add support for Inline IPSec Tx")

from the crypto tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 429467364219,c48a7521d63e..000000000000
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@@ -1739,6 -1713,14 +1752,16 @@@ void free_rspq_fl(struct adapter *adap
  void free_tx_desc(struct adapter *adap, struct sge_txq *q,
  		  unsigned int n, bool unmap);
  void free_txq(struct adapter *adap, struct sge_txq *q);
 +int t4_set_vlan_acl(struct adapter *adap, unsigned int mbox, unsigned int vf,
 +		    u16 vlan);
+ void cxgb4_reclaim_completed_tx(struct adapter *adap,
+ 				struct sge_txq *q, bool unmap);
+ int cxgb4_map_skb(struct device *dev, const struct sk_buff *skb,
+ 		  dma_addr_t *addr);
+ void cxgb4_inline_tx_skb(const struct sk_buff *skb, const struct sge_txq *q,
+ 			 void *pos);
+ void cxgb4_write_sgl(const struct sk_buff *skb, struct sge_txq *q,
+ 		     struct ulptx_sgl *sgl, u64 *end, unsigned int start,
+ 		     const dma_addr_t *addr);
+ void cxgb4_ring_tx_db(struct adapter *adap, struct sge_txq *q, int n);
  #endif /* __CXGB4_H__ */

Re: linux-next: manual merge of the crypto tree with the net-next tree

[Ayush Sawal]

Hi Herbert,

On 3/30/2020 6:19 AM, Herbert Xu wrote:
> On Mon, Mar 30, 2020 at 11:42:09AM +1100, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the crypto tree got a conflict in:
>>
>>    drivers/crypto/chelsio/chcr_core.c
>>
>> between commit:
>>
>>    34aba2c45024 ("cxgb4/chcr : Register to tls add and del callback")
>>
>> from the net-next tree and commit:
>>
>>    53351bb96b6b ("crypto: chelsio/chcr - Fixes a deadlock between rtnl_lock and uld_mutex")
>>
>> from the crypto tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging.  You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.
> Thanks for the heads up Stephen.
>
> Ayush, I'm going to drop the two chelsio patches.  Going forward,
> please send all chelsio patches via netdev.
Ok, We will using netdev tree for sending all chelsio patches from now on.

Thanks,
Ayush

Re: linux-next: manual merge of the crypto tree with the net-next tree

[Herbert Xu]

On Mon, Mar 30, 2020 at 11:42:09AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the crypto tree got a conflict in:
> 
>   drivers/crypto/chelsio/chcr_core.c
> 
> between commit:
> 
>   34aba2c45024 ("cxgb4/chcr : Register to tls add and del callback")
> 
> from the net-next tree and commit:
> 
>   53351bb96b6b ("crypto: chelsio/chcr - Fixes a deadlock between rtnl_lock and uld_mutex")
> 
> from the crypto tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Thanks for the heads up Stephen.

Ayush, I'm going to drop the two chelsio patches.  Going forward,
please send all chelsio patches via netdev.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

linux-next: manual merge of the crypto tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]

Hi all,

Today's linux-next merge of the crypto tree got a conflict in:

  drivers/crypto/chelsio/chcr_core.c

between commit:

  34aba2c45024 ("cxgb4/chcr : Register to tls add and del callback")

from the net-next tree and commit:

  53351bb96b6b ("crypto: chelsio/chcr - Fixes a deadlock between rtnl_lock and uld_mutex")

from the crypto tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/crypto/chelsio/chcr_core.c
index 0015810214a9,7e24c4881c34..000000000000
--- a/drivers/crypto/chelsio/chcr_core.c
+++ b/drivers/crypto/chelsio/chcr_core.c
@@@ -35,12 -35,12 +35,16 @@@ static int chcr_uld_state_change(void *
  
  static chcr_handler_func work_handlers[NUM_CPL_CMDS] = {
  	[CPL_FW6_PLD] = cpl_fw6_pld_handler,
 +#ifdef CONFIG_CHELSIO_TLS_DEVICE
 +	[CPL_ACT_OPEN_RPL] = chcr_ktls_cpl_act_open_rpl,
 +	[CPL_SET_TCB_RPL] = chcr_ktls_cpl_set_tcb_rpl,
 +#endif
  };
  
+ #ifdef CONFIG_CHELSIO_IPSEC_INLINE
+ static void update_netdev_features(void);
+ #endif /* CONFIG_CHELSIO_IPSEC_INLINE */
+ 
  static struct cxgb4_uld_info chcr_uld_info = {
  	.name = DRV_MODULE_NAME,
  	.nrxq = MAX_ULD_QSETS,
@@@ -204,15 -204,6 +207,11 @@@ static void *chcr_uld_add(const struct 
  	}
  	u_ctx->lldi = *lld;
  	chcr_dev_init(u_ctx);
- #ifdef CONFIG_CHELSIO_IPSEC_INLINE
- 	if (lld->crypto & ULP_CRYPTO_IPSEC_INLINE)
- 		chcr_add_xfrmops(lld);
- #endif /* CONFIG_CHELSIO_IPSEC_INLINE */
 +
 +#ifdef CONFIG_CHELSIO_TLS_DEVICE
 +	if (lld->ulp_crypto & ULP_CRYPTO_KTLS_INLINE)
 +		chcr_enable_ktls(padap(&u_ctx->dev));
 +#endif
  out:
  	return u_ctx;
  }

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the crypto tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]

Hi all,

On Mon, 30 Jul 2018 13:22:53 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the crypto tree got conflicts in:
> 
>   drivers/net/ethernet/freescale/fec_main.c
>   drivers/net/ethernet/freescale/fs_enet/mac-fec.c
> 
> between commits:
> 
>   16f6e9835bcd ("net: ethernet: freescale: Use generic CRC32 implementation")
>   d805f6a86829 ("net: ethernet: fs-enet: Use generic CRC32 implementation")
> 
> from the net-next tree and commit:
> 
>   5d258b48efbd ("net: ethernet: Use existing define with polynomial")
> 
> from the crypto tree.
> 
> I fixed it up (I used the net-next tree versions (but kept the rmeoval
> of the CRC32_POLY and FEC_CRC_POLY defines) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

This is now a conflict between the crypto-current tree and the net-next
tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 484 bytes --]

Re: linux-next: manual merge of the crypto tree with the net-next tree

[Krzysztof Kozlowski]

Hi All,

The resolution looks correct. The other way would be to amend the
commit 5d258b48efbd ("net: ethernet: Use existing define with
polynomial") in crypto tree and remove changes to freescale drivers.

Best regards,
Krzysztof

On 30 July 2018 at 05:22, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Herbert,
>
> Today's linux-next merge of the crypto tree got conflicts in:
>
>   drivers/net/ethernet/freescale/fec_main.c
>   drivers/net/ethernet/freescale/fs_enet/mac-fec.c
>
> between commits:
>
>   16f6e9835bcd ("net: ethernet: freescale: Use generic CRC32 implementation")
>   d805f6a86829 ("net: ethernet: fs-enet: Use generic CRC32 implementation")
>
> from the net-next tree and commit:
>
>   5d258b48efbd ("net: ethernet: Use existing define with polynomial")
>
> from the crypto tree.
>
> I fixed it up (I used the net-next tree versions (but kept the rmeoval
> of the CRC32_POLY and FEC_CRC_POLY defines) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell

linux-next: manual merge of the crypto tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

Hi Herbert,

Today's linux-next merge of the crypto tree got conflicts in:

  drivers/net/ethernet/freescale/fec_main.c
  drivers/net/ethernet/freescale/fs_enet/mac-fec.c

between commits:

  16f6e9835bcd ("net: ethernet: freescale: Use generic CRC32 implementation")
  d805f6a86829 ("net: ethernet: fs-enet: Use generic CRC32 implementation")

from the net-next tree and commit:

  5d258b48efbd ("net: ethernet: Use existing define with polynomial")

from the crypto tree.

I fixed it up (I used the net-next tree versions (but kept the rmeoval
of the CRC32_POLY and FEC_CRC_POLY defines) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the crypto tree with the net-next tree

[Stephen Rothwell]

Hi David,

On Tue, 08 Mar 2016 16:48:07 +0000 David Howells <dhowells@redhat.com> wrote:
>
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > > What's the best way to deal with this?  Should I take Herbert's
> > > 
> > > 	[PATCH 18/26] rxrpc: Use skcipher
> > > 
> > > patch into my rxrpc tree also and pass it on to Dave?  
> > 
> > Linus can deal with it when he merges the latter of the crypto or
> > net-next trees.  It might be worth a mention in the respective pull
> > requests.  
> 
> Do you mean I should take it - or just let Linus merge it?

Just leave it to Linus.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the crypto tree with the net-next tree

[David Howells]

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> > What's the best way to deal with this?  Should I take Herbert's
> > 
> > 	[PATCH 18/26] rxrpc: Use skcipher
> > 
> > patch into my rxrpc tree also and pass it on to Dave?
> 
> Linus can deal with it when he merges the latter of the crypto or
> net-next trees.  It might be worth a mention in the respective pull
> requests.

Do you mean I should take it - or just let Linus merge it?

I tried to apply the rxrpc skcipher patch to net-next, but
skcipher_request_zero() isn't available there or in any of the patches in the
series.

David

Re: linux-next: manual merge of the crypto tree with the net-next tree

[Stephen Rothwell]

Hi David,

On Mon, 07 Mar 2016 11:08:25 +0000 David Howells <dhowells@redhat.com> wrote:
>
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Today's linux-next merge of the crypto tree got a conflict in:
> > 
> >   net/rxrpc/rxkad.c
> > 
> > between commit:
> > 
> >   0d12f8a4027d ("rxrpc: Keep the skb private record of the Rx header in host byte order")
> > 
> > from the net-next tree and commit:
> > 
> >   1afe593b4239 ("rxrpc: Use skcipher")
> > 
> > from the crypto tree.  
> 
> What's the best way to deal with this?  Should I take Herbert's
> 
> 	[PATCH 18/26] rxrpc: Use skcipher
> 
> patch into my rxrpc tree also and pass it on to Dave?

Linus can deal with it when he merges the latter of the crypto or
net-next trees.  It might be worth a mention in the respective pull
requests.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the crypto tree with the net-next tree

[David Howells]

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Today's linux-next merge of the crypto tree got a conflict in:
> 
>   net/rxrpc/rxkad.c
> 
> between commit:
> 
>   0d12f8a4027d ("rxrpc: Keep the skb private record of the Rx header in host byte order")
> 
> from the net-next tree and commit:
> 
>   1afe593b4239 ("rxrpc: Use skcipher")
> 
> from the crypto tree.

What's the best way to deal with this?  Should I take Herbert's

	[PATCH 18/26] rxrpc: Use skcipher

patch into my rxrpc tree also and pass it on to Dave?

David

linux-next: manual merge of the crypto tree with the net-next tree

[Stephen Rothwell]

Hi Herbert,

Today's linux-next merge of the crypto tree got a conflict in:

  net/rxrpc/rxkad.c

between commit:

  0d12f8a4027d ("rxrpc: Keep the skb private record of the Rx header in host byte order")

from the net-next tree and commit:

  1afe593b4239 ("rxrpc: Use skcipher")

from the crypto tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc net/rxrpc/rxkad.c
index 3106a0c4960b,0d96b48a6492..000000000000
--- a/net/rxrpc/rxkad.c
+++ b/net/rxrpc/rxkad.c
@@@ -128,21 -128,23 +128,23 @@@ static void rxkad_prime_packet_security
  	token = conn->key->payload.data[0];
  	memcpy(&iv, token->kad->session_key, sizeof(iv));
  
- 	desc.tfm = conn->cipher;
- 	desc.info = iv.x;
- 	desc.flags = 0;
- 
 -	tmpbuf.x[0] = conn->epoch;
 -	tmpbuf.x[1] = conn->cid;
 +	tmpbuf.x[0] = htonl(conn->epoch);
 +	tmpbuf.x[1] = htonl(conn->cid);
  	tmpbuf.x[2] = 0;
  	tmpbuf.x[3] = htonl(conn->security_ix);
  
  	sg_init_one(&sg[0], &tmpbuf, sizeof(tmpbuf));
  	sg_init_one(&sg[1], &tmpbuf, sizeof(tmpbuf));
- 	crypto_blkcipher_encrypt_iv(&desc, &sg[0], &sg[1], sizeof(tmpbuf));
+ 
+ 	skcipher_request_set_tfm(req, conn->cipher);
+ 	skcipher_request_set_callback(req, 0, NULL, NULL);
+ 	skcipher_request_set_crypt(req, &sg[1], &sg[0], sizeof(tmpbuf), iv.x);
+ 
+ 	crypto_skcipher_encrypt(req);
+ 	skcipher_request_zero(req);
  
  	memcpy(&conn->csum_iv, &tmpbuf.x[2], sizeof(conn->csum_iv));
 -	ASSERTCMP(conn->csum_iv.n[0], ==, tmpbuf.x[2]);
 +	ASSERTCMP((u32 __force)conn->csum_iv.n[0], ==, (u32 __force)tmpbuf.x[2]);
  
  	_leave("");
  }
@@@ -251,12 -267,12 +267,12 @@@ out
   * checksum an RxRPC packet header
   */
  static int rxkad_secure_packet(const struct rxrpc_call *call,
 -				struct sk_buff *skb,
 -				size_t data_size,
 -				void *sechdr)
 +			       struct sk_buff *skb,
 +			       size_t data_size,
 +			       void *sechdr)
  {
  	struct rxrpc_skb_priv *sp;
- 	struct blkcipher_desc desc;
+ 	SKCIPHER_REQUEST_ON_STACK(req, call->conn->cipher);
  	struct rxrpc_crypt iv;
  	struct scatterlist sg[2];
  	struct {
@@@ -280,15 -297,12 +296,12 @@@
  
  	/* continue encrypting from where we left off */
  	memcpy(&iv, call->conn->csum_iv.x, sizeof(iv));
- 	desc.tfm = call->conn->cipher;
- 	desc.info = iv.x;
- 	desc.flags = 0;
  
  	/* calculate the security checksum */
 -	x = htonl(call->channel << (32 - RXRPC_CIDSHIFT));
 -	x |= sp->hdr.seq & cpu_to_be32(0x3fffffff);
 -	tmpbuf.x[0] = sp->hdr.callNumber;
 -	tmpbuf.x[1] = x;
 +	x = call->channel << (32 - RXRPC_CIDSHIFT);
 +	x |= sp->hdr.seq & 0x3fffffff;
 +	tmpbuf.x[0] = htonl(sp->hdr.callNumber);
 +	tmpbuf.x[1] = htonl(x);
  
  	sg_init_one(&sg[0], &tmpbuf, sizeof(tmpbuf));
  	sg_init_one(&sg[1], &tmpbuf, sizeof(tmpbuf));
@@@ -513,25 -539,29 +536,28 @@@ static int rxkad_verify_packet(const st
  
  	/* continue encrypting from where we left off */
  	memcpy(&iv, call->conn->csum_iv.x, sizeof(iv));
- 	desc.tfm = call->conn->cipher;
- 	desc.info = iv.x;
- 	desc.flags = 0;
  
  	/* validate the security checksum */
 -	x = htonl(call->channel << (32 - RXRPC_CIDSHIFT));
 -	x |= sp->hdr.seq & cpu_to_be32(0x3fffffff);
 -	tmpbuf.x[0] = call->call_id;
 -	tmpbuf.x[1] = x;
 +	x = call->channel << (32 - RXRPC_CIDSHIFT);
 +	x |= sp->hdr.seq & 0x3fffffff;
 +	tmpbuf.x[0] = htonl(call->call_id);
 +	tmpbuf.x[1] = htonl(x);
  
  	sg_init_one(&sg[0], &tmpbuf, sizeof(tmpbuf));
  	sg_init_one(&sg[1], &tmpbuf, sizeof(tmpbuf));
- 	crypto_blkcipher_encrypt_iv(&desc, &sg[0], &sg[1], sizeof(tmpbuf));
+ 
+ 	skcipher_request_set_tfm(req, call->conn->cipher);
+ 	skcipher_request_set_callback(req, 0, NULL, NULL);
+ 	skcipher_request_set_crypt(req, &sg[1], &sg[0], sizeof(tmpbuf), iv.x);
+ 
+ 	crypto_skcipher_encrypt(req);
+ 	skcipher_request_zero(req);
  
  	y = ntohl(tmpbuf.x[1]);
 -	y = (y >> 16) & 0xffff;
 -	if (y == 0)
 -		y = 1; /* zero checksums are not permitted */
 +	cksum = (y >> 16) & 0xffff;
 +	if (cksum == 0)
 +		cksum = 1; /* zero checksums are not permitted */
  
 -	cksum = htons(y);
  	if (sp->hdr.cksum != cksum) {
  		*_abort_code = RXKADSEALEDINCON;
  		_leave(" = -EPROTO [csum failed]");

linux-next: manual merge of the crypto tree with the net-next tree

[Stephen Rothwell]

Hi Herbert,

Today's linux-next merge of the crypto tree got a conflict in:

  net/rxrpc/rxkad.c

between commit:

  0d12f8a4027d ("rxrpc: Keep the skb private record of the Rx header in host byte order")

from the net-next tree and commit:

  1afe593b4239 ("rxrpc: Use skcipher")

from the crypto tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc net/rxrpc/rxkad.c
index 3106a0c4960b,0d96b48a6492..000000000000
--- a/net/rxrpc/rxkad.c
+++ b/net/rxrpc/rxkad.c
@@@ -128,21 -128,23 +128,23 @@@ static void rxkad_prime_packet_security
  	token = conn->key->payload.data[0];
  	memcpy(&iv, token->kad->session_key, sizeof(iv));
  
- 	desc.tfm = conn->cipher;
- 	desc.info = iv.x;
- 	desc.flags = 0;
- 
 -	tmpbuf.x[0] = conn->epoch;
 -	tmpbuf.x[1] = conn->cid;
 +	tmpbuf.x[0] = htonl(conn->epoch);
 +	tmpbuf.x[1] = htonl(conn->cid);
  	tmpbuf.x[2] = 0;
  	tmpbuf.x[3] = htonl(conn->security_ix);
  
  	sg_init_one(&sg[0], &tmpbuf, sizeof(tmpbuf));
  	sg_init_one(&sg[1], &tmpbuf, sizeof(tmpbuf));
- 	crypto_blkcipher_encrypt_iv(&desc, &sg[0], &sg[1], sizeof(tmpbuf));
+ 
+ 	skcipher_request_set_tfm(req, conn->cipher);
+ 	skcipher_request_set_callback(req, 0, NULL, NULL);
+ 	skcipher_request_set_crypt(req, &sg[1], &sg[0], sizeof(tmpbuf), iv.x);
+ 
+ 	crypto_skcipher_encrypt(req);
+ 	skcipher_request_zero(req);
  
  	memcpy(&conn->csum_iv, &tmpbuf.x[2], sizeof(conn->csum_iv));
 -	ASSERTCMP(conn->csum_iv.n[0], ==, tmpbuf.x[2]);
 +	ASSERTCMP((u32 __force)conn->csum_iv.n[0], ==, (u32 __force)tmpbuf.x[2]);
  
  	_leave("");
  }
@@@ -251,12 -267,12 +267,12 @@@ out
   * checksum an RxRPC packet header
   */
  static int rxkad_secure_packet(const struct rxrpc_call *call,
 -				struct sk_buff *skb,
 -				size_t data_size,
 -				void *sechdr)
 +			       struct sk_buff *skb,
 +			       size_t data_size,
 +			       void *sechdr)
  {
  	struct rxrpc_skb_priv *sp;
- 	struct blkcipher_desc desc;
+ 	SKCIPHER_REQUEST_ON_STACK(req, call->conn->cipher);
  	struct rxrpc_crypt iv;
  	struct scatterlist sg[2];
  	struct {
@@@ -280,15 -297,12 +296,12 @@@
  
  	/* continue encrypting from where we left off */
  	memcpy(&iv, call->conn->csum_iv.x, sizeof(iv));
- 	desc.tfm = call->conn->cipher;
- 	desc.info = iv.x;
- 	desc.flags = 0;
  
  	/* calculate the security checksum */
 -	x = htonl(call->channel << (32 - RXRPC_CIDSHIFT));
 -	x |= sp->hdr.seq & cpu_to_be32(0x3fffffff);
 -	tmpbuf.x[0] = sp->hdr.callNumber;
 -	tmpbuf.x[1] = x;
 +	x = call->channel << (32 - RXRPC_CIDSHIFT);
 +	x |= sp->hdr.seq & 0x3fffffff;
 +	tmpbuf.x[0] = htonl(sp->hdr.callNumber);
 +	tmpbuf.x[1] = htonl(x);
  
  	sg_init_one(&sg[0], &tmpbuf, sizeof(tmpbuf));
  	sg_init_one(&sg[1], &tmpbuf, sizeof(tmpbuf));
@@@ -513,25 -539,29 +536,28 @@@ static int rxkad_verify_packet(const st
  
  	/* continue encrypting from where we left off */
  	memcpy(&iv, call->conn->csum_iv.x, sizeof(iv));
- 	desc.tfm = call->conn->cipher;
- 	desc.info = iv.x;
- 	desc.flags = 0;
  
  	/* validate the security checksum */
 -	x = htonl(call->channel << (32 - RXRPC_CIDSHIFT));
 -	x |= sp->hdr.seq & cpu_to_be32(0x3fffffff);
 -	tmpbuf.x[0] = call->call_id;
 -	tmpbuf.x[1] = x;
 +	x = call->channel << (32 - RXRPC_CIDSHIFT);
 +	x |= sp->hdr.seq & 0x3fffffff;
 +	tmpbuf.x[0] = htonl(call->call_id);
 +	tmpbuf.x[1] = htonl(x);
  
  	sg_init_one(&sg[0], &tmpbuf, sizeof(tmpbuf));
  	sg_init_one(&sg[1], &tmpbuf, sizeof(tmpbuf));
- 	crypto_blkcipher_encrypt_iv(&desc, &sg[0], &sg[1], sizeof(tmpbuf));
+ 
+ 	skcipher_request_set_tfm(req, call->conn->cipher);
+ 	skcipher_request_set_callback(req, 0, NULL, NULL);
+ 	skcipher_request_set_crypt(req, &sg[1], &sg[0], sizeof(tmpbuf), iv.x);
+ 
+ 	crypto_skcipher_encrypt(req);
+ 	skcipher_request_zero(req);
  
  	y = ntohl(tmpbuf.x[1]);
 -	y = (y >> 16) & 0xffff;
 -	if (y == 0)
 -		y = 1; /* zero checksums are not permitted */
 +	cksum = (y >> 16) & 0xffff;
 +	if (cksum == 0)
 +		cksum = 1; /* zero checksums are not permitted */
  
 -	cksum = htons(y);
  	if (sp->hdr.cksum != cksum) {
  		*_abort_code = RXKADSEALEDINCON;
  		_leave(" = -EPROTO [csum failed]");

Re: linux-next: manual merge of the crypto tree with the net-next tree

[Herbert Xu]

On Wed, Feb 06, 2013 at 01:20:11PM +1100, Stephen Rothwell wrote:
> Hi Herbert,
> 
> Today's linux-next merge of the crypto tree got a conflict in
> crypto/ctr.c between commit 69d3150cfc20 ("crypto: ctr - make rfc3686
> asynchronous block cipher") from the net-next tree and commit
> 3e8afe35c36f ("crypto: use ERR_CAST") from the crypto tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks good.  Thanks Stephen!
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: linux-next: manual merge of the crypto tree with the net-next tree

[Herbert Xu]

On Wed, Feb 06, 2013 at 01:20:11PM +1100, Stephen Rothwell wrote:
> Hi Herbert,
> 
> Today's linux-next merge of the crypto tree got a conflict in
> crypto/ctr.c between commit 69d3150cfc20 ("crypto: ctr - make rfc3686
> asynchronous block cipher") from the net-next tree and commit
> 3e8afe35c36f ("crypto: use ERR_CAST") from the crypto tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks good.  Thanks Stephen!
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

linux-next: manual merge of the crypto tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]

Hi Herbert,

Today's linux-next merge of the crypto tree got a conflict in
crypto/ctr.c between commit 69d3150cfc20 ("crypto: ctr - make rfc3686
asynchronous block cipher") from the net-next tree and commit
3e8afe35c36f ("crypto: use ERR_CAST") from the crypto tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc crypto/ctr.c
index 1f2997c,095dcb6..0000000
--- a/crypto/ctr.c
+++ b/crypto/ctr.c
@@@ -335,40 -324,18 +335,38 @@@ static void crypto_rfc3686_exit_tfm(str
  
  static struct crypto_instance *crypto_rfc3686_alloc(struct rtattr **tb)
  {
 +	struct crypto_attr_type *algt;
  	struct crypto_instance *inst;
  	struct crypto_alg *alg;
 +	struct crypto_skcipher_spawn *spawn;
 +	const char *cipher_name;
  	int err;
  
 -	err = crypto_check_attr_type(tb, CRYPTO_ALG_TYPE_BLKCIPHER);
 +	algt = crypto_get_attr_type(tb);
- 	err = PTR_ERR(algt);
 +	if (IS_ERR(algt))
- 		return ERR_PTR(err);
++		return ERR_CAST(algt);
 +
 +	if ((algt->type ^ CRYPTO_ALG_TYPE_BLKCIPHER) & algt->mask)
 +		return ERR_PTR(-EINVAL);
 +
 +	cipher_name = crypto_attr_alg_name(tb[1]);
- 	err = PTR_ERR(cipher_name);
 +	if (IS_ERR(cipher_name))
- 		return ERR_PTR(err);
++		return ERR_CAST(cipher_name);
 +
 +	inst = kzalloc(sizeof(*inst) + sizeof(*spawn), GFP_KERNEL);
 +	if (!inst)
 +		return ERR_PTR(-ENOMEM);
 +
 +	spawn = crypto_instance_ctx(inst);
 +
 +	crypto_set_skcipher_spawn(spawn, inst);
 +	err = crypto_grab_skcipher(spawn, cipher_name, 0,
 +				   crypto_requires_sync(algt->type,
 +							algt->mask));
  	if (err)
 -		return ERR_PTR(err);
 +		goto err_free_inst;
  
 -	alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_BLKCIPHER,
 -				  CRYPTO_ALG_TYPE_MASK);
 -	if (IS_ERR(alg))
 -		return ERR_CAST(alg);
 +	alg = crypto_skcipher_spawn_alg(spawn);
  
  	/* We only support 16-byte blocks. */
  	err = -EINVAL;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the crypto tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]

Hi Herbert,

Today's linux-next merge of the crypto tree got a conflict in
crypto/ctr.c between commit 69d3150cfc20 ("crypto: ctr - make rfc3686
asynchronous block cipher") from the net-next tree and commit
3e8afe35c36f ("crypto: use ERR_CAST") from the crypto tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc crypto/ctr.c
index 1f2997c,095dcb6..0000000
--- a/crypto/ctr.c
+++ b/crypto/ctr.c
@@@ -335,40 -324,18 +335,38 @@@ static void crypto_rfc3686_exit_tfm(str
  
  static struct crypto_instance *crypto_rfc3686_alloc(struct rtattr **tb)
  {
 +	struct crypto_attr_type *algt;
  	struct crypto_instance *inst;
  	struct crypto_alg *alg;
 +	struct crypto_skcipher_spawn *spawn;
 +	const char *cipher_name;
  	int err;
  
 -	err = crypto_check_attr_type(tb, CRYPTO_ALG_TYPE_BLKCIPHER);
 +	algt = crypto_get_attr_type(tb);
- 	err = PTR_ERR(algt);
 +	if (IS_ERR(algt))
- 		return ERR_PTR(err);
++		return ERR_CAST(algt);
 +
 +	if ((algt->type ^ CRYPTO_ALG_TYPE_BLKCIPHER) & algt->mask)
 +		return ERR_PTR(-EINVAL);
 +
 +	cipher_name = crypto_attr_alg_name(tb[1]);
- 	err = PTR_ERR(cipher_name);
 +	if (IS_ERR(cipher_name))
- 		return ERR_PTR(err);
++		return ERR_CAST(cipher_name);
 +
 +	inst = kzalloc(sizeof(*inst) + sizeof(*spawn), GFP_KERNEL);
 +	if (!inst)
 +		return ERR_PTR(-ENOMEM);
 +
 +	spawn = crypto_instance_ctx(inst);
 +
 +	crypto_set_skcipher_spawn(spawn, inst);
 +	err = crypto_grab_skcipher(spawn, cipher_name, 0,
 +				   crypto_requires_sync(algt->type,
 +							algt->mask));
  	if (err)
 -		return ERR_PTR(err);
 +		goto err_free_inst;
  
 -	alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_BLKCIPHER,
 -				  CRYPTO_ALG_TYPE_MASK);
 -	if (IS_ERR(alg))
 -		return ERR_CAST(alg);
 +	alg = crypto_skcipher_spawn_alg(spawn);
  
  	/* We only support 16-byte blocks. */
  	err = -EINVAL;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the crypto tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]

Hi Herbert,

Today's linux-next merge of the crypto tree got a conflict in
crypto/ctr.c between commit 69d3150cfc20 ("crypto: ctr - make rfc3686
asynchronous block cipher") from the net-next tree and commit
3e8afe35c36f ("crypto: use ERR_CAST") from the crypto tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc crypto/ctr.c
index 1f2997c,095dcb6..0000000
--- a/crypto/ctr.c
+++ b/crypto/ctr.c
@@@ -335,40 -324,18 +335,38 @@@ static void crypto_rfc3686_exit_tfm(str
  
  static struct crypto_instance *crypto_rfc3686_alloc(struct rtattr **tb)
  {
 +	struct crypto_attr_type *algt;
  	struct crypto_instance *inst;
  	struct crypto_alg *alg;
 +	struct crypto_skcipher_spawn *spawn;
 +	const char *cipher_name;
  	int err;
  
 -	err = crypto_check_attr_type(tb, CRYPTO_ALG_TYPE_BLKCIPHER);
 +	algt = crypto_get_attr_type(tb);
- 	err = PTR_ERR(algt);
 +	if (IS_ERR(algt))
- 		return ERR_PTR(err);
++		return ERR_CAST(algt);
 +
 +	if ((algt->type ^ CRYPTO_ALG_TYPE_BLKCIPHER) & algt->mask)
 +		return ERR_PTR(-EINVAL);
 +
 +	cipher_name = crypto_attr_alg_name(tb[1]);
- 	err = PTR_ERR(cipher_name);
 +	if (IS_ERR(cipher_name))
- 		return ERR_PTR(err);
++		return ERR_CAST(cipher_name);
 +
 +	inst = kzalloc(sizeof(*inst) + sizeof(*spawn), GFP_KERNEL);
 +	if (!inst)
 +		return ERR_PTR(-ENOMEM);
 +
 +	spawn = crypto_instance_ctx(inst);
 +
 +	crypto_set_skcipher_spawn(spawn, inst);
 +	err = crypto_grab_skcipher(spawn, cipher_name, 0,
 +				   crypto_requires_sync(algt->type,
 +							algt->mask));
  	if (err)
 -		return ERR_PTR(err);
 +		goto err_free_inst;
  
 -	alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_BLKCIPHER,
 -				  CRYPTO_ALG_TYPE_MASK);
 -	if (IS_ERR(alg))
 -		return ERR_CAST(alg);
 +	alg = crypto_skcipher_spawn_alg(spawn);
  
  	/* We only support 16-byte blocks. */
  	err = -EINVAL;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]