From: "Michael S. Tsirkin" <mst@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Evgeniy Polyakov <zbr@ioremap.net>,
Ben Greear <greearb@candelatech.com>,
David Miller <davem@davemloft.net>,
Gaspar Chilingarov <gasparch@gmail.com>,
netdev <netdev@vger.kernel.org>
Subject: Re: PROBLEM: Linux kernel 2.6.31 IPv4 TCP fails to open huge amount of outgoing connections (unable to bind ... )
Date: Sun, 25 Apr 2010 17:26:42 +0300 [thread overview]
Message-ID: <20100425142642.GA11411@redhat.com> (raw)
In-Reply-To: <1271877975.7895.3171.camel@edumazet-laptop>
On Wed, Apr 21, 2010 at 09:26:15PM +0200, Eric Dumazet wrote:
> Le mercredi 21 avril 2010 à 22:58 +0400, Evgeniy Polyakov a écrit :
>
> > Damn it, I tried multiple times :)
> > You are right of course!
> >
>
> Here is a formal patch then :)
>
> [PATCH] tcp: bind() fix when many ports are bound
>
> Port autoselection done by kernel only works when number of bound
> sockets is under a threshold (typically 30000).
>
> When this threshold is over, we must check if there is a conflict before
> exiting first loop in inet_csk_get_port()
>
> Change inet_csk_bind_conflict() to forbid two reuse-enabled sockets to
> bind on same (address,port) tuple (with a non ANY address)
>
> Same change for inet6_csk_bind_conflict()
>
> Reported-by: Gaspar Chilingarov <gasparch@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> net/ipv4/inet_connection_sock.c | 16 +++++++++++-----
> net/ipv6/inet6_connection_sock.c | 15 ++++++++++-----
> 2 files changed, 21 insertions(+), 10 deletions(-)
>
> diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
> index e0a3e35..78cbc39 100644
> --- a/net/ipv4/inet_connection_sock.c
> +++ b/net/ipv4/inet_connection_sock.c
> @@ -70,13 +70,17 @@ int inet_csk_bind_conflict(const struct sock *sk,
> (!sk->sk_bound_dev_if ||
> !sk2->sk_bound_dev_if ||
> sk->sk_bound_dev_if == sk2->sk_bound_dev_if)) {
> + const __be32 sk2_rcv_saddr = inet_rcv_saddr(sk2);
> +
> if (!reuse || !sk2->sk_reuse ||
> sk2->sk_state == TCP_LISTEN) {
> - const __be32 sk2_rcv_saddr = inet_rcv_saddr(sk2);
> if (!sk2_rcv_saddr || !sk_rcv_saddr ||
> sk2_rcv_saddr == sk_rcv_saddr)
> break;
> - }
> + } else if (reuse && sk2->sk_reuse &&
> + sk2_rcv_saddr &&
> + sk2_rcv_saddr == sk_rcv_saddr)
> + break;
> }
> }
> return node != NULL;
> @@ -120,9 +124,11 @@ again:
> smallest_size = tb->num_owners;
> smallest_rover = rover;
> if (atomic_read(&hashinfo->bsockets) > (high - low) + 1) {
> - spin_unlock(&head->lock);
> - snum = smallest_rover;
> - goto have_snum;
> + if (!inet_csk(sk)->icsk_af_ops->bind_conflict(sk, tb)) {
> + spin_unlock(&head->lock);
> + snum = smallest_rover;
> + goto have_snum;
> + }
> }
> }
> goto next;
> diff --git a/net/ipv6/inet6_connection_sock.c b/net/ipv6/inet6_connection_sock.c
> index 0c5e3c3..fb6959c 100644
> --- a/net/ipv6/inet6_connection_sock.c
> +++ b/net/ipv6/inet6_connection_sock.c
> @@ -42,11 +42,16 @@ int inet6_csk_bind_conflict(const struct sock *sk,
> if (sk != sk2 &&
> (!sk->sk_bound_dev_if ||
> !sk2->sk_bound_dev_if ||
> - sk->sk_bound_dev_if == sk2->sk_bound_dev_if) &&
> - (!sk->sk_reuse || !sk2->sk_reuse ||
> - sk2->sk_state == TCP_LISTEN) &&
> - ipv6_rcv_saddr_equal(sk, sk2))
> - break;
> + sk->sk_bound_dev_if == sk2->sk_bound_dev_if)) {
> + if ((!sk->sk_reuse || !sk2->sk_reuse ||
> + sk2->sk_state == TCP_LISTEN) &&
> + ipv6_rcv_saddr_equal(sk, sk2))
> + break;
> + else if (sk->sk_reuse && sk2->sk_reuse &&
> + !ipv6_addr_any(inet6_rcv_saddr(sk2)) &&
> + ipv6_rcv_saddr_equal(sk, sk2))
> + break;
> + }
> }
>
> return node != NULL;
>
With this applied, my box crashes on boot:
rhel6 beta userspace, v2.6.34-rc5-204-gddc9b34 kernel.
2.6.34-rc5 kernel boots fine.
the crash seems to be around net/ipv6/inet6_connection_sock.c:50
after reverting fda48a0d7a8412cedacda46a9c0bf8ef9cd13559,
the crash goes away.
I created https://bugzilla.kernel.org/show_bug.cgi?id=15847
to track this.
Oops below:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000004
IP: [<ffffffffa02b99aa>] inet6_csk_bind_conflict+0x6a/0x110 [ipv6]
PGD 0
Oops: 0000 [#1] SMP
last sysfs file:
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/net/eth0/ifindex
CPU 9
Modules linked in: ip6t_REJECT nf_conntrack_ipv6 ip6table_filter
ip6_tables ipv6 dm_mirror dm_region_hash dm_log igb i2c_i801 sg iTCO_wdt
iTCO_vendor_support shpchp ioatdma dca pcspkr sr_mod cdrom ext4 mbcache
jbd2 sd_mod ata_generic crc_t10dif pata_acpi ahci pata_jmicron radeon
ttm drm_kms_helper drm i2c_algo_bit i2c_core dm_mod [last unloaded:
scsi_wait_scan]
Pid: 1640, comm: master Not tainted 2.6.34-rc5-mst #1 X8DTN/X8DTN
RIP: 0010:[<ffffffffa02b99aa>] [<ffffffffa02b99aa>]
inet6_csk_bind_conflict+0x6a/0x110 [ipv6]
RSP: 0018:ffff8803357a7d98 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff880335709440 RCX: 0000000000000000
RDX: 0000000000020011 RSI: ffff880335709440 RDI: ffff880334c61e78
RBP: ffff8803357a7db8 R08: 0000000000000019 R09: 0000000000000019
R10: 00000000000000d4 R11: 0000000000000400 R12: ffff880335709468
R13: ffff880334c61800 R14: ffff880335489500 R15: ffffffff8225d700
FS: 00007feacd26f7c0(0000) GS:ffff8801c5700000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000004 CR3: 00000003341ef000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process master (pid: 1640, threadinfo ffff8803357a6000, task
ffff880334225540)
Stack:
0000000000000000 ffffffff8225b500 ffffc9001251ced0 ffff880334c61800
<0> ffff8803357a7e48 ffffffff81418fa8 ffff880300000019 ffffffff8149ceb6
<0> 0000000536306140 0000000000000246 ffff8803357a7e08 0000000000000246
Call Trace:
[<ffffffff81418fa8>] inet_csk_get_port+0x238/0x450
[<ffffffff8149ceb6>] ? _raw_spin_lock_bh+0x16/0x40
[<ffffffff8149ce15>] ? _raw_read_unlock_bh+0x15/0x20
[<ffffffffa0290226>] ? ipv6_chk_addr+0xe6/0x100 [ipv6]
--
MST
next prev parent reply other threads:[~2010-04-25 14:30 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-20 22:17 PROBLEM: Linux kernel 2.6.31 IPv4 TCP fails to open huge amount of outgoing connections (unable to bind ... ) Gaspar Chilingarov
2010-04-20 22:31 ` Eric Dumazet
2010-04-20 23:18 ` Gaspar Chilingarov
2010-04-20 23:42 ` Eric Dumazet
2010-04-21 0:14 ` Evgeniy Polyakov
2010-04-20 23:07 ` Ben Greear
2010-04-20 23:20 ` Gaspar Chilingarov
2010-04-20 23:20 ` Gaspar Chilingarov
2010-04-20 23:30 ` Ben Greear
2010-04-20 23:35 ` Gaspar Chilingarov
2010-04-20 23:49 ` Ben Greear
2010-04-20 23:57 ` Gaspar Chilingarov
2010-04-21 0:14 ` Eric Dumazet
2010-04-21 0:05 ` Eric Dumazet
2010-04-21 0:12 ` Gaspar Chilingarov
2010-04-21 0:14 ` David Miller
2010-04-21 0:30 ` Evgeniy Polyakov
2010-04-21 2:04 ` David Miller
2010-04-21 5:46 ` Eric Dumazet
2010-04-21 8:25 ` Evgeniy Polyakov
2010-04-21 9:02 ` Eric Dumazet
2010-04-21 9:58 ` Evgeniy Polyakov
2010-04-21 10:21 ` Eric Dumazet
2010-04-21 11:27 ` Eric Dumazet
2010-04-21 16:52 ` George B.
2010-04-21 18:27 ` Evgeniy Polyakov
2010-04-21 18:43 ` Eric Dumazet
2010-04-21 18:58 ` Evgeniy Polyakov
2010-04-21 19:26 ` Eric Dumazet
2010-04-21 20:08 ` Evgeniy Polyakov
2010-04-23 2:06 ` David Miller
2010-04-25 14:26 ` Michael S. Tsirkin [this message]
2010-04-25 15:56 ` Evgeniy Polyakov
2010-04-25 16:13 ` Eric Dumazet
2010-04-25 16:21 ` Eric Dumazet
2010-04-25 16:35 ` Michael S. Tsirkin
2010-04-25 22:08 ` David Miller
2010-04-21 19:03 ` Narendra Choyal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100425142642.GA11411@redhat.com \
--to=mst@redhat.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=gasparch@gmail.com \
--cc=greearb@candelatech.com \
--cc=netdev@vger.kernel.org \
--cc=zbr@ioremap.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.