Messages in this thread | | | From | kuznet@ms2 ... | Subject | Re: [patch] af_unix fix for a panic a DoS and a memory leak [Re: | Date | Wed, 3 Mar 1999 18:33:00 +0300 (MSK) |
| |
Hello!
> +int unix_nr_socks = 0;
I'd make:
atomic_t unix_nr_socks;
and coverted all bh protected ++/-- to atomic_dec/atomic_inc. The only race is in limit checking and it is harmless, because it can result in only in small overestimate of unix_nr_socks (when timer ticks between atomic_read() and < max_files) and does not affect anything, nobody could guarantee that the same timer will not tick 1 usec later.
start_bh_atomic() is pretty expensive on SMP boxen. I'd avoid this, when it is possible.
> + /* Fail if the listen backlog is just full. -arca */ > + if (other->ack_backlog >= other->max_ack_backlog) > + goto out; > +
Ough, guys: it is wrong. Let's make it in more liberal way yet, f.e.
struct wait_queue *unix_global_ack_queue; ....
restart: /* Find listening sock */ other=unix_find_other(sunaddr, addr_len, sk->type, hash, &err);
if (other && other->ack_backlog >= other->max_ack_backlog) { if (other->dead || other->state != TCP_LISTEN) { unix_unlock(other); return -ECONNREFUSED; }
unix_unlock(other);
if (nonblock) return -EAGAIN; sleep_on_interruptible(&unix_global_ack_queue); if (signal_pending(current)) return -ERESTARTSYS; goto restart; }
/* create new sock for complete connection */ newsk = unix_create1(NULL, 1);
.... and wake_up_interruptible(&unix_global_ack_queue) on all --ack_backlog
Now behaviour in non-blocking case is still wrong, (it should fall to EINPROGRESS), but it is not fatal: I do not remember that someone used nonblocked connect() on af_unix seriously.
On dgrams the same trick can be used, only using sk->receive_queue.qlen instead of ack_backlog and some reasonable bound.
What do you think?
Alexey
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |