From: Peter Staubach <staubach@redhat.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: ASANO Masahiro <masano@tnes.nec.co.jp>,
trond.myklebust@fys.uio.no, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] fix posix lock on NFS
Date: Tue, 03 Jan 2006 15:09:03 -0500 [thread overview]
Message-ID: <43BAD9DF.4090401@redhat.com> (raw)
In-Reply-To: <20060103194630.GL19769@parisc-linux.org>
Matthew Wilcox wrote:
>On Tue, Jan 03, 2006 at 02:39:24PM -0500, Peter Staubach wrote:
>
>
>>> /* No mandatory locks over NFS */
>>>- if ((inode->i_mode & (S_ISGID | S_IXGRP)) == S_ISGID)
>>>+ if ((inode->i_mode & (S_ISGID | S_IXGRP)) == S_ISGID &&
>>>+ fl->fl_type != F_UNLCK)
>>>
>>>
>>Just out of curiosity, what is this if() statement intended to protect?
>>For locking purposes, why would the client care if the file has the
>>mandatory lock bits set?
>>
>>
>
>Mandatory locks aren't mandatory for other clients.
>
>
So?
I guess that I don't understand this response.
The server is responsible for keeping itself from attempting to access
a mandatory lock file. The client is not responsible for doing so and
trying to help the server is kind of a waste of time, mostly.
The mandatory lock mode bits really only come into play when attempting
to read or write the file. In this case, the system will automatically
try to take a lock for the process, if that process does not already
have a lock. The server should prevent itself from trying to access
files like this in order to avoid DoS attacks.
The NFS client does not support mandatory locking, mostly due to the
possibility of DoS attacks and also due to the locking and NFS protocols
not being sufficiently aware of each other. NFSv4 can be used to address
this latter problem, but probably not the former.
So, why deny lock requests for such files? Especially on the client?
Thanx...
ps
next prev parent reply other threads:[~2006-01-03 20:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-22 4:24 [PATCH] fix posix lock on NFS ASANO Masahiro
2006-01-03 19:39 ` Peter Staubach
2006-01-03 19:46 ` Matthew Wilcox
2006-01-03 20:09 ` Peter Staubach [this message]
2006-01-04 1:24 ` Trond Myklebust
2006-01-04 14:16 ` 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=43BAD9DF.4090401@redhat.com \
--to=staubach@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masano@tnes.nec.co.jp \
--cc=matthew@wil.cx \
--cc=trond.myklebust@fys.uio.no \
/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).