All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Staubach <staubach@redhat.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Matthew Wilcox <matthew@wil.cx>,
	ASANO Masahiro <masano@tnes.nec.co.jp>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] fix posix lock on NFS
Date: Wed, 04 Jan 2006 09:16:10 -0500	[thread overview]
Message-ID: <43BBD8AA.2010906@redhat.com> (raw)
In-Reply-To: <1136337847.7846.50.camel@lade.trondhjem.org>

Trond Myklebust wrote:

>On Tue, 2006-01-03 at 15:09 -0500, Peter Staubach wrote:
>  
>
>>Matthew Wilcox wrote:
>>    
>>
>>>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?
>>    
>>
>
>I agree, however that would have been a change in behaviour that would
>have been hard to find time to test properly in an -rc6(?) release, so
>we went for the quick and dirty fix.
>

Okay.

Are we going to be able to fix this properly once things open up a bit then?

    Thanx...

       ps

      reply	other threads:[~2006-01-04 14:16 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
2006-01-04  1:24       ` Trond Myklebust
2006-01-04 14:16         ` Peter Staubach [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=43BBD8AA.2010906@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 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.