All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: <Daniel.Muntz@emc.com>
Cc: <Trond.Myklebust@netapp.com>, <peter.staubach@emc.com>,
	<bfields@fieldses.org>, <bjschuma@netapp.com>,
	<linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 3/3] NFS: Detect loops in a readdir due to bad cookies
Date: Thu, 24 Mar 2011 08:55:17 +1100	[thread overview]
Message-ID: <20110324085517.77584ced@notabene.brown> (raw)
In-Reply-To: <DE966DA98A4ABE438D726BDF1699CF6104B53F7F0C@MX05A.corp.emc.com>

On Wed, 23 Mar 2011 17:36:38 -0400 <Daniel.Muntz@emc.com> wrote:

>  
> 
> > -----Original Message-----
> > From: linux-nfs-owner@vger.kernel.org 
> > [mailto:linux-nfs-owner@vger.kernel.org] On Behalf Of NeilBrown
> > Sent: Wednesday, March 23, 2011 2:28 PM
> > To: Trond Myklebust
> > Cc: Staubach, Peter; bfields@fieldses.org; 
> > bjschuma@netapp.com; linux-nfs@vger.kernel.org
> > Subject: Re: [PATCH 3/3] NFS: Detect loops in a readdir due 
> > to bad cookies
> > 
> > On Wed, 23 Mar 2011 14:48:35 -0400 Trond Myklebust
> > <Trond.Myklebust@netapp.com> wrote:
> > 
> > > On Wed, 2011-03-23 at 14:42 -0400, peter.staubach@emc.com wrote:
> > > > Although I think that it is a good thing to protect the 
> > client against broken servers, it does seem like the right 
> > solution is to get the server fixed...
> > > 
> > > Don't get me wrong: I fully agree with that!
> > 
> > Ack.
> > 
> > As I understand it, ext4 (and ext3) use the hash of the 
> > basename as the
> > cookie.  This hash has a per-directory random seed which is 
> > hidden so it is
> > not possible to deliberately create files with the same hash, 
> > but thanks to
> > the birthday paradox it isn't too hard to get collisions in a 
> > suitably large
> > directory.
> > 
> > For 'readdir' ext4 keeps extra state in the 'struct file' so 
> > that it knows
> > where it was up to in a list of names with the same hash and 
> > so won't return
> > duplicates.  
> 
> Would it be possible to use this "extra state" to uniqify the cookie used by NFS?  Having no idea what this extra state is, I'm just wildly speculating.
> 

No, it is all hidden inside filp->private_data.  It is just a linked-list of
file names  (see 'extra_fname' in fs/ext4/dir.c).
The best you could do would be to shift the cookie up a few bits (ext4
cookies are 62 bit already!) and add a sequence counter.
But I don't think that approach will really give more reliability than just
trying to hide cookie-runs by making sure they don't cross from one packet to
the next.

NeilBrown

  reply	other threads:[~2011-03-23 21:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-23 17:39 [PATCH 3/3] NFS: Detect loops in a readdir due to bad cookies Bryan Schumaker
2011-03-23 18:10 ` peter.staubach
2011-03-23 18:17   ` Trond Myklebust
2011-03-23 18:11 ` Trond Myklebust
2011-03-23 18:25 ` J. Bruce Fields
2011-03-23 18:34   ` Trond Myklebust
2011-03-23 18:42     ` peter.staubach
2011-03-23 18:48       ` Trond Myklebust
2011-03-23 21:27         ` NeilBrown
2011-03-23 21:36           ` Daniel.Muntz
2011-03-23 21:55             ` NeilBrown [this message]
2011-03-23 18:43     ` peter.staubach

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=20110324085517.77584ced@notabene.brown \
    --to=neilb@suse.de \
    --cc=Daniel.Muntz@emc.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=bfields@fieldses.org \
    --cc=bjschuma@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=peter.staubach@emc.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.