On Wed, 16 Apr 2014 09:00:02 -0400 (EDT) David Miller
wrote:
> From: Eric Dumazet
> Date: Tue, 15 Apr 2014 22:13:46 -0700
>
> > For applications handling millions of sockets, this makes a difference.
>
> Indeed, this really is not acceptable.
As you say...
I've just discovered that I can get
From: Eric Dumazet
Date: Tue, 15 Apr 2014 22:13:46 -0700
> For applications handling millions of sockets, this makes a difference.
Indeed, this really is not acceptable.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.o
On Tue, 15 Apr 2014 22:13:46 -0700 Eric Dumazet
wrote:
> On Wed, 2014-04-16 at 14:03 +1000, NeilBrown wrote:
> > sk_lock can be taken while reclaiming memory (in nfsd for loop-back
> > NFS mounts, and presumably in nfs), and memory can be allocated while
> > holding sk_lock, at least via:
> >
>
On Wed, 2014-04-16 at 14:03 +1000, NeilBrown wrote:
> sk_lock can be taken while reclaiming memory (in nfsd for loop-back
> NFS mounts, and presumably in nfs), and memory can be allocated while
> holding sk_lock, at least via:
>
> inet_listen -> inet_csk_listen_start ->reqsk_queue_alloc
>
> So t
sk_lock can be taken while reclaiming memory (in nfsd for loop-back
NFS mounts, and presumably in nfs), and memory can be allocated while
holding sk_lock, at least via:
inet_listen -> inet_csk_listen_start ->reqsk_queue_alloc
So to avoid deadlocks, always set PF_FSTRANS while holding sk_lock.
T
5 matches
Mail list logo