All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yan, Zheng" <zheng.z.yan@intel.com>
To: Sage Weil <sage@inktank.com>
Cc: ceph-devel@vger.kernel.org
Subject: Re: [PATCH] ceph: Fix oops when mounting cephfs with non-existing path
Date: Mon, 20 Aug 2012 10:47:15 +0800	[thread overview]
Message-ID: <5031A533.8070603@intel.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1208170850380.26904@cobra.newdream.net>

On 08/17/2012 11:54 PM, Sage Weil wrote:
> Hi Yan,
> 
> On Fri, 17 Aug 2012, Yan, Zheng wrote:
>> From: "Yan, Zheng" <zheng.z.yan@intel.com>
>>
>> req->r_locked_dir is NULL if the request was created by
>> open_root_dentry(). ceph_fill_trace() lacks check for this case.
>> It causes oops when mounting cephfs with non-existing path.
> 
> This is actually an MDS bug.  The problem is that the client is issuing a 
> GETATTR request and isn't prepared to handle a dentry in the reply, but 
> the MDS sees that there is a relative path in the request and behaves like 
> this is a lookup.  We were distinguishing correctly between the two cases 
> on success, but not on error.  I've pushed branch bug-2969 to ceph.git 
> which fixes this for me.  Can you please test and verify it resolves 
> the problem?
It does resolve the problem.

> 
> We may want to have a check like the below, but it should probably be 
> accompanied by a pr_warning or WARN_ON() since it is a protocol error.  
> Generally speaking, the client isn't allowed to ignore state the MDS has 
> issued it (in this case, caps on the directory inode; lower down in 
> fill_trace possibly a dentry lease) without messing up the protocol.
> 

Thank you for your explanation. 

Yan, Zheng

      parent reply	other threads:[~2012-08-20  2:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-17  5:55 [PATCH] ceph: Fix oops when mounting cephfs with non-existing path Yan, Zheng
2012-08-17 15:54 ` Sage Weil
2012-08-17 16:01   ` Tommi Virtanen
2012-08-20  2:47   ` Yan, Zheng [this message]

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=5031A533.8070603@intel.com \
    --to=zheng.z.yan@intel.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=sage@inktank.com \
    /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.