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
next prev parent 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