Linux NFS development
 help / color / mirror / Atom feed
From: Rajat <sharma.rajat@hcl.in>
To: nfs@lists.sourceforge.net
Subject: Re: Unlocked pages flushed
Date: Mon, 2 Jul 2007 13:24:45 +0000 (UTC)	[thread overview]
Message-ID: <loom.20070702T150607-90@post.gmane.org> (raw)
In-Reply-To: 1183379648.6479.7.camel@heimdal.trondhjem.org

Trond Myklebust <trond.myklebust <at> fys.uio.no> writes:

> 
> On Mon, 2007-07-02 at 10:51 +0000, Rajat wrote:
> > Hi List,
> > 
> > While flushing the data through nfs_file_flush, I observed that pages are 
> > being flushed in unlocked state. nfs_file_flush call graph reaches to 
> > nfs_flush_one where the comment above this definition states "The page 
must 
> > have been locked by the caller." However I have checked with PageLocked() 
call 
> > that the pages which enter into nfs_flush_one are not locked. 
> > 
> > What I could make out of it is: this is done porbably to avoid deadlock 
with 
> > other functions like prepare_write, commit_write, writepage, readpage 
where 
> > page is grabbed first then lock_kernel (HEAVILY used in NFS) is called. 
> > Whereas nfs_file_flush calls lock_kernel, then enters into nfs_wb_all. So, 
to 
> > avoid deadlock, logical place for lock_page loop would have been in 
> > nfs_file_flush before lock_kernel (still not sure about this, will it 
help?). 
> > 
> > Here we are flushing pages without honouring page_lock OR am I going wrong 
> > somewhere???
> > 
> > Rajat
> 
> When you hit contention on a mutex or page lock, that puts the process
> to sleep: at that point the BKL is automatically released, and so no
> deadlock occurs.
> 
> IOW: it is impossible to get the BKL to ABBA deadlock with any form of
> "sleeping lock".

Yes I missed out on this. page lock is sleeping on bit. But then if ABBA 
deadlock is not the case, why pages are being flushed unlocked? I mean is it 
not required to lock these pages before flushing? In that case it should be 
safe to place page_lock loop to wait on any pending work on these pages. 

Also there is one more spinlock in the scene, nfs_inode->req_lock and spinning 
for this lock should not release BKL. I am assuming that lock ordering of BKL 
and req_lock is maintained. 



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2007-07-02 13:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-02 10:51 Unlocked pages flushed Rajat
2007-07-02 12:34 ` Trond Myklebust
2007-07-02 13:24   ` Rajat [this message]
2007-07-03  0:53     ` Trond Myklebust
2007-07-03  5:39       ` Rajat

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=loom.20070702T150607-90@post.gmane.org \
    --to=sharma.rajat@hcl.in \
    --cc=nfs@lists.sourceforge.net \
    /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