On 5/5/19 11:25 AM, David Miller wrote:
> From: Al Viro
> Date: Sun, 5 May 2019 18:59:43 +0100
>
>> On Sun, May 05, 2019 at 10:04:21AM -0700, David Miller wrote:
>>> From: Al Viro
>>> Date: Thu, 2 May 2019 17:32:23 +0100
>>>
it appears that we might take freeing the socket itself to the
From: Al Viro
Date: Sun, 5 May 2019 18:59:43 +0100
> On Sun, May 05, 2019 at 10:04:21AM -0700, David Miller wrote:
>> From: Al Viro
>> Date: Thu, 2 May 2019 17:32:23 +0100
>>
>> > it appears that we might take freeing the socket itself to the
>> > RCU-delayed part, along with socket->wq. And d
On Sun, May 05, 2019 at 10:04:21AM -0700, David Miller wrote:
> From: Al Viro
> Date: Thu, 2 May 2019 17:32:23 +0100
>
> > it appears that we might take freeing the socket itself to the
> > RCU-delayed part, along with socket->wq. And doing that has
> > an interesting benefit - the only reason t
From: Al Viro
Date: Thu, 2 May 2019 17:32:23 +0100
> it appears that we might take freeing the socket itself to the
> RCU-delayed part, along with socket->wq. And doing that has
> an interesting benefit - the only reason to do two separate
> allocation disappears.
I'm pretty sure we looked into
I'm not sure what's the right way to handle that.
Background: new inode method (->free_inode()) allows to
do RCU-delayed parts of ->destroy_inode() conveniently,
killing a lot of boilerplate code in process.
It's optional, so sockfs doesn't have to be
converted; however, looking at
