netdev - Re: [PATCH v2] RDS: fix rds-ping spinlock recursion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 09 Oct 2012 13:58:08 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	jeff.liu@...cle.com
Cc:	rds-devel@....oracle.com, venkat.x.venkatsubra@...cle.com,
	dan.carpenter@...cle.com, james.l.morris@...cle.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH v2] RDS: fix rds-ping spinlock recursion

From: Jeff Liu <jeff.liu@...cle.com>
Date: Tue, 09 Oct 2012 12:57:27 +0800

> This is the revised patch for fixing rds-ping spinlock recursion according to Venkat's suggestions.
> 
> RDS ping/pong over TCP feature has been broken for years(2.6.39 to 3.6.0) since we
> have to set TCP cork and call kernel_sendmsg() between ping/pong which both need to
> lock "struct sock *sk". However, this lock has already been hold before rds_tcp_data_ready()
> callback is triggerred. As a result, we always facing spinlock resursion which would resulting
> in system panic.
> 
> Given that RDS ping is only used to test the connectivity and not for serious performance measurements,
> we can queue the pong transmit to rds_wq as a delayed response.
> 
> Reported-by: Dan Carpenter <dan.carpenter@...cle.com>
> CC: Venkat Venkatsubra <venkat.x.venkatsubra@...cle.com>
> CC: David S. Miller <davem@...emloft.net>
> CC: James Morris <james.l.morris@...cle.com>
> Signed-off-by: Jie Liu <jeff.liu@...cle.com>

Applied and queued up for -stable, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html