linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Joseph D. Wagner" <theman@josephdwagner.info>
To: Jamie Lokier <jamie@shareable.org>,
	Nikita Danilov <Nikita@Namesys.COM>,
	Matthew Wilcox <willy@debian.org>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH] VERSION 2: fs/locks.c fcntl_setlease did not check if a file was opened for writing before granting a read lease
Date: Fri, 28 Nov 2003 00:11:59 +0600	[thread overview]
Message-ID: <200311280011.59287.theman@josephdwagner.info> (raw)

> Sorry, it won't work.

Then try this.  A half-@$$ed patch is better than no patch at all.

Joseph D. Wagner

--- /old/src/linux-2.4.22/fs/locks.c	2003-08-25 17:44:43.000000000 +0600
+++ /new/src/linux-2.4.22/fs/locks.c	2003-11-28 00:05:11.000000000 +0600
@@ -111,10 +111,17 @@
  *  Matthew Wilcox <willy@thepuffingroup.com>, March, 2000.
  *
  *  Leases and LOCK_MAND
  *  Matthew Wilcox <willy@linuxcare.com>, June, 2000.
  *  Stephen Rothwell <sfr@canb.auug.org.au>, June, 2000.
+ *
+ *  PARTIALLY FIXED Leases Issue -- Function fcntl_setlease would only
+ *  check if a file had been opened before granting a F_WRLCK, a.k.a. a
+ *  write lease.  It would not check if the file had be opened for
+ *  writing before granting a F_RDLCK, a.k.a. a read lease.  This issue
+ *  has been partially resolved.  See FIXME below.
+ *  Joseph D. Wagner <wagnerjd@users.sourceforge.net> November 2003
  */

 #include <linux/slab.h>
 #include <linux/file.h>
 #include <linux/smp_lock.h>
@@ -1287,14 +1294,33 @@

 	lock_kernel();

 	time_out_leases(inode);
 
-	/*
-	 * FIXME: What about F_RDLCK and files open for writing?
-	 */
 	error = -EAGAIN;
+	if ((arg == F_RDLCK)
+	    && ((atomic_read(&dentry->d_count) > 1)
+		|| (atomic_read(&inode->i_count) > 1))) {
+
+		/*
+		 * FIXME: Theoretically, what would happen next
+		 * is a loop which checks each open file to see
+		 * if the file is open for writing (i.e. O_WRONLY,
+		 * O_RDWR, O_CREAT, or O_TRUNC).  However, since
+		 * that would require major overhauls in other
+		 * files, it is simply assumed that if a file is
+		 * open that the file is open for writing.  In
+		 * effect, this creates an exclusive read lease
+		 * such that only one process can obtain a read
+		 * lease at any given time.  Theoretically, a file
+		 * should be able to have a virtually limitless
+		 * number of read leases provided that no process
+		 * has the file open for writing.
+		 */
+
+		goto out_unlock;
+	}
 	if ((arg == F_WRLCK)
 	    && ((atomic_read(&dentry->d_count) > 1)
 		|| (atomic_read(&inode->i_count) > 1)))
 		goto out_unlock;



                 reply	other threads:[~2003-11-28  6:12 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=200311280011.59287.theman@josephdwagner.info \
    --to=theman@josephdwagner.info \
    --cc=Nikita@Namesys.COM \
    --cc=jamie@shareable.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=willy@debian.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;
as well as URLs for NNTP newsgroup(s).