linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Chuck Lever" <chuck.lever@oracle.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	"Arnd Bergmann" <arnd@arndb.de>,
	linux-nfs@vger.kernel.org
Subject: Re: still nfs problems [Was: Linux 2.6.37-rc8]
Date: Thu, 30 Dec 2010 14:25:15 -0500	[thread overview]
Message-ID: <1293737115.4919.47.camel@heimdal.trondhjem.org> (raw)
In-Reply-To: <AANLkTi=sO9M8m1Fpntu_YscVU4SrppKfxBf2eRZ2Dr+L@mail.gmail.com>

On Thu, 2010-12-30 at 10:50 -0800, Linus Torvalds wrote: 
> On Thu, Dec 30, 2010 at 10:24 AM, Trond Myklebust
> <Trond.Myklebust@netapp.com> wrote:
> >
> > There is nothing we can do to protect ourselves against an infinite loop
> > if the server (or underlying filesystem) is breaking the rules w.r.t.
> > cookie generation. It should be possible to recover from all other
> > situations.
> 
> Umm. Sure there is. Just make sure that you return the uncached entry
> to user space, rather than loop forever.
> 
> Looping forever in kernel space is a bad idea. How about just changing
> the "continue" into a "break" for the "uncached readdir returned
> success".

uncached_readdir is not really a problem. The real problem is
filesystems that generate "infinite directories" by producing looping
combinations of cookies.

IOW: I've seen servers that generate cookies in a sequence of a form
vaguely resembling

1 2 3 4 5 6 7 8 9 10 11 12 3...

(with possibly a thousand or so entries between the first and second
copy of '3')

The kernel won't loop forever with something like that (because
eventually filldir() will declare it is out of buffer space), but
userland has a halting problem: it needs to detect that every
sys_getdents() call it is making is generating another copy of the
sequence associated with '4 5 6 7 8 9 10 11 12 3'...

> No halting problems, no excuses. There is absolutely _no_ excuse for
> an endless loop in kernel mode. Certainly not "the other end is
> incompetent".

We should never get an endless loop in _kernel mode_ with the current
scheme, and I can't see that anyone has demonstrated that yet.

> EVERYBODY is incompetent sometimes. That just means that you must
> never trust the other end too much. You can't say "we require the
> server to be sane in order not to lock up".

Unfortunately we must. Call it an NFS protocol failure, but it really
boils down to the fact that POSIX readdir() generates a data stream with
no well-defined concept of an offset. As a result, each and every
filesystem has their own interesting ways of generating cookies to
represent that 'offset'.

Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com


  reply	other threads:[~2010-12-30 19:25 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AANLkTi=-dNeeDjcSoznKtwcaNyw1mMXSqepFY89R2i+2@mail.gmail.com>
     [not found] ` <20101230171453.GA5787@pengutronix.de>
2010-12-30 17:59   ` still nfs problems [Was: Linux 2.6.37-rc8] Trond Myklebust
2010-12-30 19:18     ` Uwe Kleine-König
2011-01-03 21:38       ` Uwe Kleine-König
2011-01-04  0:22         ` Trond Myklebust
2011-01-05  8:40           ` Uwe Kleine-König
2011-01-05 11:05             ` Uwe Kleine-König
2011-01-05 11:27               ` Russell King - ARM Linux
2011-01-05 12:14                 ` Marc Kleine-Budde
2011-01-05 13:02                   ` Nori, Sekhar
2011-01-05 15:34                     ` Russell King - ARM Linux
2011-01-05 13:40                 ` Uwe Kleine-König
2011-01-05 14:29                   ` Jim Rees
2011-01-05 14:42                     ` Marc Kleine-Budde
2011-01-05 15:38                       ` Jim Rees
2011-01-05 14:53                   ` Trond Myklebust
2011-01-05 15:01                     ` Marc Kleine-Budde
2011-01-05 15:14                       ` Trond Myklebust
2011-01-05 15:29                         ` Trond Myklebust
2011-01-05 15:39                           ` Marc Kleine-Budde
2011-01-05 15:52                         ` Russell King - ARM Linux
2011-01-05 17:17                           ` Trond Myklebust
2011-01-05 17:26                             ` Russell King - ARM Linux
2011-01-05 18:12                               ` Trond Myklebust
2011-01-05 18:27                                 ` Russell King - ARM Linux
2011-01-05 18:55                                   ` Trond Myklebust
2011-01-05 19:07                                     ` Russell King - ARM Linux
2011-01-14  2:25                     ` Andy Isaacson
2011-01-14  2:40                       ` Trond Myklebust
2011-01-14  4:22                         ` Andy Isaacson
     [not found]   ` <AANLkTikvZF6Q1k0rETLHUffkUT3grxAh3FoB_0vs96B8@mail.gmail.com>
2010-12-30 18:24     ` Trond Myklebust
2010-12-30 18:50       ` Linus Torvalds
2010-12-30 19:25         ` Trond Myklebust [this message]
2010-12-30 20:02           ` Linus Torvalds
2010-12-31  3:17 George Spelvin
2010-12-31  4:32 ` Trond Myklebust
2011-01-01  1:03   ` George Spelvin
2011-01-01  1:18     ` Trond Myklebust
2011-01-01  5:44       ` George Spelvin
  -- strict thread matches above, loose matches on Subject: below --
2011-01-05 19:05 James Bottomley
2011-01-05 19:18 ` Linus Torvalds
2011-01-05 19:36   ` James Bottomley
2011-01-05 19:49     ` Linus Torvalds
2011-01-05 20:35       ` James Bottomley
2011-01-05 20:00     ` Russell King - ARM Linux
2011-01-05 20:33       ` James Bottomley
2011-01-05 20:48         ` Linus Torvalds
2011-01-05 21:04           ` Russell King - ARM Linux
2011-01-05 21:08             ` Linus Torvalds
2011-01-05 21:16               ` Trond Myklebust
2011-01-05 21:30                 ` Linus Torvalds
2011-01-05 23:06                   ` Trond Myklebust
2011-01-05 23:28                     ` James Bottomley
2011-01-06 17:40                       ` James Bottomley
2011-01-06 17:47                         ` Trond Myklebust
2011-01-06 17:51                           ` James Bottomley
2011-01-06 17:55                           ` Linus Torvalds
2011-01-07 18:53                             ` Trond Myklebust
2011-01-07 19:02                               ` Russell King - ARM Linux
2011-01-07 19:11                                 ` James Bottomley
2011-01-08 16:49                                   ` Trond Myklebust
2011-01-08 23:15                                     ` Trond Myklebust
2011-01-10 10:50                                       ` Uwe Kleine-König
2011-01-10 16:25                                         ` Trond Myklebust
2011-01-10 17:08                                           ` Marc Kleine-Budde
2011-01-10 17:20                                             ` Trond Myklebust
     [not found]                                               ` <1294680035.3349.19.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2011-01-10 17:26                                                 ` Marc Kleine-Budde
2011-01-10 19:25                                               ` Uwe Kleine-König
2011-01-10 19:29                                                 ` Trond Myklebust
2011-01-10 19:31                                                   ` James Bottomley
2011-01-10 19:34                                                   ` Linus Torvalds
2011-01-10 20:15                                                     ` Trond Myklebust
2011-01-10 12:44                                       ` Marc Kleine-Budde
2011-01-07 19:13                                 ` Trond Myklebust
2011-01-07 19:05                               ` James Bottomley
2011-01-06 18:05                         ` Russell King - ARM Linux
2011-01-06 18:14                           ` James Bottomley
2011-01-06 18:25                             ` James Bottomley
2011-01-06 21:07                               ` James Bottomley
2011-01-06 20:19                         ` John Stoffel
2011-01-05 23:28                     ` Linus Torvalds
2011-01-05 23:59                       ` Russell King - ARM Linux
2011-01-05 21:16           ` James Bottomley

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=1293737115.4919.47.camel@heimdal.trondhjem.org \
    --to=trond.myklebust@netapp.com \
    --cc=arnd@arndb.de \
    --cc=chuck.lever@oracle.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=u.kleine-koenig@pengutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).