mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: torvalds@osdl.org, fcusack@fcusack.com
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	NFS maillist <nfs@lists.sourceforge.net>
Subject: Re: [PATCH] Allow unattended nfs3/krb5 mounts
Date: Fri, 18 Jul 2003 00:01:26 +0200	[thread overview]
Message-ID: <16151.7350.505992.554003@charged.uio.no> (raw)
In-Reply-To: <20030717190428.GA4735@spaans.vs19.net>


Linus,

  Could we please back off the merging of these particular patches,
in order to give time for some critical debate?

  I'm glad Frank has been working on this, but if there has been a
proper debate on the merits of these patches, then I must have missed
it. I have indeed seen the patches pass through my inbox once, but I
have not had time yet to review them properly, and feed back my
comments to Frank.


  I have clear doubts about this patch.


  The 'fake root' inode does not appear to have a well defined
behaviour when it tries to circumvent revalidation rules. AFAICS
things like 'stat()', etc will at times tend to give odd results even
if the user does have the correct credentials.

  On a similar vein, I'm also unconvinced that there exist no races
between the lookup of new files, and the first setting of the
NFS_FILEID() on the root directory. fileid=1 is *not* a reserved inode
number under NFS v2 or v3, so it is perfectly legitimate for the
server to have other inodes with that number. In this case,
iget5_locked() may end up assigning the same inode to the root inode +
some other file.

  I also have questions about smaller issues, such as why we need a
full second RPC client in the superblock just in order to (very
temporarily) add a second authentication flavour.

Cheers,
  Trond

      reply	other threads:[~2003-07-17 21:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-16  6:26 Frank Cusack
2003-07-16  8:44 ` Frank Cusack
2003-07-17 19:04 ` Jasper Spaans
2003-07-17 22:01   ` Trond Myklebust [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=16151.7350.505992.554003@charged.uio.no \
    --to=trond.myklebust@fys.uio.no \
    --cc=fcusack@fcusack.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nfs@lists.sourceforge.net \
    --cc=torvalds@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®