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).