[Top] [All Lists]

Re: [PATCH 10/19] NET: set PF_FSTRANS while holding sk_lock

To: David Miller <davem@xxxxxxxxxxxxx>
Subject: Re: [PATCH 10/19] NET: set PF_FSTRANS while holding sk_lock
From: NeilBrown <neilb@xxxxxxx>
Date: Thu, 17 Apr 2014 12:38:37 +1000
Cc: eric.dumazet@xxxxxxxxx, linux-mm@xxxxxxxxx, linux-nfs@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, netdev@xxxxxxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140416.090002.2186526865564557549.davem@xxxxxxxxxxxxx>
References: <20140416033623.10604.69237.stgit@xxxxxxxxxxxxxx> <20140416040336.10604.96000.stgit@xxxxxxxxxxxxxx> <1397625226.4222.113.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20140416.090002.2186526865564557549.davem@xxxxxxxxxxxxx>
On Wed, 16 Apr 2014 09:00:02 -0400 (EDT) David Miller <davem@xxxxxxxxxxxxx>

> From: Eric Dumazet <eric.dumazet@xxxxxxxxx>
> 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 rid of the lockdep message (and hence
presumably the deadlock risk) with a well placed:

                newsock->sk->sk_allocation = GFP_NOFS;

which surprised me as it seemed to be an explicit GFP_KERNEL allocation that
was mentioned in the lockdep trace.  Obviously these traces require quite
some sophistication to understand.

So - thanks for the feedback, patch can be ignored.


Attachment: signature.asc
Description: PGP signature

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