All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislav Kinsbursky <skinsbursky@parallels.com>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
Cc: "Isaman, Fred" <Fred.Isaman@netapp.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] SUNRPC: fix use-after-free of rpc pipes
Date: Mon, 27 Feb 2012 16:51:23 +0400	[thread overview]
Message-ID: <4F4B7C4B.5000901@parallels.com> (raw)
In-Reply-To: <1330300376.18817.0.camel@lade.trondhjem.org>

27.02.2012 03:52, Myklebust, Trond пишет:
> On Fri, 2012-02-24 at 22:14 +0400, Stanislav Kinsbursky wrote:
>> 23.02.2012 21:48, Fred Isaman пишет:
>>> This needs to be looked at closely by someone more familiar with the
>>> pipe code.
>>>
>>> It fixes an issue with the current nfs_for_next branch which causes a
>>> chain of oopses on umount every time if sufficient CONFIG_* debug
>>> options are set.
>>>
>>> A git-bisect shows that the problem was introduced by
>>> commit c239d83b  SUNRPC: split SUNPRC PipeFS dentry and private pipe data creation
>>>
>>
>>
>>
>> Fred, thanks for the config.
>> The problem is caused by destroying pipe data on NFS client umount after
>> unlinking pipe dentry. This is valid approach, but it looks like idmap daemon
>> holds dentry by eventfd.
>> This is a race between idmap daemon release of this dentry and releasing of pipe
>> data...
>> I need some time to find out how to fix this properly.
>>
>
> How about something like the following (still untested) patch?
>
> Cheers
>    Trond


Hi, Trond. Thanks for participating.
Frankly, I don't like the idea of put'ing pipe data on dentry unlink. IOW, I 
don't like that this data will be controlled somehow in PipeFS.
I'll send my version soon.

-- 
Best regards,
Stanislav Kinsbursky

  reply	other threads:[~2012-02-27 12:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-23 17:48 [PATCH] SUNRPC: fix use-after-free of rpc pipes Fred Isaman
2012-02-24 11:03 ` Stanislav Kinsbursky
2012-02-24 13:11   ` Fred Isaman
2012-02-24 11:47 ` Stanislav Kinsbursky
2012-02-24 13:17   ` Fred Isaman
2012-02-24 14:01     ` Stanislav Kinsbursky
2012-02-24 18:14 ` Stanislav Kinsbursky
2012-02-26 23:52   ` Myklebust, Trond
2012-02-27 12:51     ` Stanislav Kinsbursky [this message]
2012-02-27 13:44       ` Myklebust, Trond
2012-02-27 13:55         ` Stanislav Kinsbursky
  -- strict thread matches above, loose matches on Subject: below --
2012-02-22 18:44 Fred Isaman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F4B7C4B.5000901@parallels.com \
    --to=skinsbursky@parallels.com \
    --cc=Fred.Isaman@netapp.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.