netdev
[Top] [All Lists]

migrating to lock_sock()

To: netdev@xxxxxxxxxxx
Subject: migrating to lock_sock()
From: Henner Eisen <eis@xxxxxxxxxxxxx>
Date: Mon, 18 Dec 2000 23:06:11 +0100
Sender: owner-netdev@xxxxxxxxxxx
Hi,

while thinking about how to fully replace the BKL-based by lock_sock()-based
socket locking inside the AF_X25 stack, I encountered some questions:

The X.25 stack currently uses the network core's support function
sock_alloc_send_skb() to allocate outgoing buffer space. It seems that
this is not designed for use with lock_sock()-based socket locking.
All other connection oriented protocols which apply lock_sock()
(currently only tcp and decnet) seem to implement their private equivalent
of sock_alloc_send_skb() which releases the lock while waiting for write
buffer space. Should I also do so for X.25 or would it make sense to
rework sock_alloc_send_skb() such that socket lock is released while
waiting for write buffer space?

With current BKL based locking, the kernel lock is released whenever
the process is waiting for GFP_KERNEL memory. But with lock_sock(),
the socket remains locked in such situations. Couldn't that cause
problems during low-memory conditions? The process could be blocked
-- with the lock hold -- for a rather long time.


While socket is locked, all incoming packets are queued at
sk->backlock without any precautions (neither seize limits nor
flow control affect sk->backlog queuing). It seems like feeding
lots of incoming packets while socket is locked could eat up
lots of kernel memory and even be exploited for a denial-of-service attack.


Henner

<Prev in Thread] Current Thread [Next in Thread>