[net][PATCH v2 0/2] RDS: couple of fixes for 4.6

[net][PATCH v2 0/2] RDS: couple of fixes for 4.6

[Santosh Shilimkar]

v2:
Rebased fixes against 'net' instead of 'net-next' Patches are also
available at below git tree.

The following changes since commit e013b7780c41b471c4269ac9ccafb65ba7c9ec86:

  Merge branch 'dsa-voidify-ops' (2016-04-08 16:51:15 -0400)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_4.6/net/rds-fixes

for you to fetch changes up to e9155afb1902380938ca83ba8504aaa2d7ee5210:

  RDS: Fix the atomicity for congestion map update (2016-04-08 15:08:13 -0700)

----------------------------------------------------------------
Qing Huang (1):
      RDS: fix endianness for dp_ack_seq

Santosh Shilimkar (1):
      RDS: Fix the atomicity for congestion map update

 net/rds/cong.c  | 4 ++--
 net/rds/ib_cm.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

Regards,
Santosh

[net][PATCH v2 1/2] RDS: fix endianness for dp_ack_seq

[Santosh Shilimkar]

From: Qing Huang <qing.huang@oracle.com>

dp->dp_ack_seq is used in big endian format. We need to do the
big endianness conversion when we assign a value in host format
to it.

Signed-off-by: Qing Huang <qing.huang@oracle.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
---
 net/rds/ib_cm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rds/ib_cm.c b/net/rds/ib_cm.c
index 8764970..310cabc 100644
--- a/net/rds/ib_cm.c
+++ b/net/rds/ib_cm.c
@@ -194,7 +194,7 @@ static void rds_ib_cm_fill_conn_param(struct rds_connection *conn,
 		dp->dp_protocol_major = RDS_PROTOCOL_MAJOR(protocol_version);
 		dp->dp_protocol_minor = RDS_PROTOCOL_MINOR(protocol_version);
 		dp->dp_protocol_minor_mask = cpu_to_be16(RDS_IB_SUPPORTED_PROTOCOLS);
-		dp->dp_ack_seq = rds_ib_piggyb_ack(ic);
+		dp->dp_ack_seq = cpu_to_be64(rds_ib_piggyb_ack(ic));
 
 		/* Advertise flow control */
 		if (ic->i_flowctl) {
-- 
1.9.1

[net][PATCH v2 2/2] RDS: Fix the atomicity for congestion map update

[Santosh Shilimkar]

Two different threads with different rds sockets may be in
rds_recv_rcvbuf_delta() via receive path. If their ports
both map to the same word in the congestion map, then
using non-atomic ops to update it could cause the map to
be incorrect. Lets use atomics to avoid such an issue.

Full credit to Wengang <wen.gang.wang@oracle.com> for
finding the issue, analysing it and also pointing out
to offending code with spin lock based fix.

Reviewed-by: Leon Romanovsky <leon@leon.nu>
Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
---
 net/rds/cong.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/rds/cong.c b/net/rds/cong.c
index e6144b8..6641bcf 100644
--- a/net/rds/cong.c
+++ b/net/rds/cong.c
@@ -299,7 +299,7 @@ void rds_cong_set_bit(struct rds_cong_map *map, __be16 port)
 	i = be16_to_cpu(port) / RDS_CONG_MAP_PAGE_BITS;
 	off = be16_to_cpu(port) % RDS_CONG_MAP_PAGE_BITS;
 
-	__set_bit_le(off, (void *)map->m_page_addrs[i]);
+	set_bit_le(off, (void *)map->m_page_addrs[i]);
 }
 
 void rds_cong_clear_bit(struct rds_cong_map *map, __be16 port)
@@ -313,7 +313,7 @@ void rds_cong_clear_bit(struct rds_cong_map *map, __be16 port)
 	i = be16_to_cpu(port) / RDS_CONG_MAP_PAGE_BITS;
 	off = be16_to_cpu(port) % RDS_CONG_MAP_PAGE_BITS;
 
-	__clear_bit_le(off, (void *)map->m_page_addrs[i]);
+	clear_bit_le(off, (void *)map->m_page_addrs[i]);
 }
 
 static int rds_cong_test_bit(struct rds_cong_map *map, __be16 port)
-- 
1.9.1

Re: [net][PATCH v2 0/2] RDS: couple of fixes for 4.6

[David Miller]

From: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Date: Thu, 14 Apr 2016 10:43:25 -0700

>   git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_4.6/net/rds-fixes

I have no idea how you set this up, but there is no WAY this can be
pulled from by me.

When I try to pull it into 'net' I get 2690 objects.  That means you
didn't base it upon the 'net' tree which you must do.  You can't base
it upon Linus's tree, because if you do I'll get a ton of changes that
are absolutely not appropriate to be pulled into my 'net' tree.

Are you always doing this?  Working against Linus's tree instead of
mine?

Re: [net][PATCH v2 1/2] RDS: fix endianness for dp_ack_seq

[David Miller]

From: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Date: Thu, 14 Apr 2016 10:43:26 -0700

> From: Qing Huang <qing.huang@oracle.com>
> 
> dp->dp_ack_seq is used in big endian format. We need to do the
> big endianness conversion when we assign a value in host format
> to it.
> 
> Signed-off-by: Qing Huang <qing.huang@oracle.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>

Applied.

Re: [net][PATCH v2 2/2] RDS: Fix the atomicity for congestion map update

[David Miller]

From: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Date: Thu, 14 Apr 2016 10:43:27 -0700

> Two different threads with different rds sockets may be in
> rds_recv_rcvbuf_delta() via receive path. If their ports
> both map to the same word in the congestion map, then
> using non-atomic ops to update it could cause the map to
> be incorrect. Lets use atomics to avoid such an issue.
> 
> Full credit to Wengang <wen.gang.wang@oracle.com> for
> finding the issue, analysing it and also pointing out
> to offending code with spin lock based fix.
> 
> Reviewed-by: Leon Romanovsky <leon@leon.nu>
> Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>

Applied.

Re: [net][PATCH v2 0/2] RDS: couple of fixes for 4.6

[santosh shilimkar]

On 4/16/2016 3:53 PM, David Miller wrote:
> From: Santosh Shilimkar <santosh.shilimkar@oracle.com>
> Date: Thu, 14 Apr 2016 10:43:25 -0700
>
>>    git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_4.6/net/rds-fixes
>
> I have no idea how you set this up, but there is no WAY this can be
> pulled from by me.
>
Thought I did based it against 'net' after your last comment.
Just checked again and the 'net' remote added by me points
to wrong url(net-next).

> When I try to pull it into 'net' I get 2690 objects.  That means you
> didn't base it upon the 'net' tree which you must do.  You can't base
> it upon Linus's tree, because if you do I'll get a ton of changes that
> are absolutely not appropriate to be pulled into my 'net' tree.
>
> Are you always doing this?  Working against Linus's tree instead of
> mine?
>
No, its not Linus's tree. Its yours but not the right one.
Sorry for the trouble. Won't happen again.

Thanks for picking up the matches from patchworks.

Regards,
Santosh