From: Pavel Emelyanov <xemul@openvz.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
devel@openvz.org
Subject: [PATCH 1/5] Use existing macros for distinguishing mandatory locks
Date: Wed, 12 Sep 2007 15:17:58 +0400 [thread overview]
Message-ID: <46E7CAE6.8040803@openvz.org> (raw)
The combination of S_ISGID bit set and S_IXGRP bit unset is
used to mark the inode as "mandatory lockable" and there's a
macro for this check called MANDATORY_LOCK(inode). However,
fs/locks.c and some filesystems still perform the explicit
i_mode checking.
Switch the fs/locks.c to macro making the code shorter and
more readable.
The __MANDATORY_LOCK() macro is to be used in places where
the IS_MANDLOCK() for superblock is already known to be true.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
fs/locks.c | 14 ++++----------
include/linux/fs.h | 4 ++--
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 291d40b..035ffda 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1488,8 +1488,8 @@ extern int locks_mandatory_area(int, str
* Candidates for mandatory locking have the setgid bit set
* but no group execute bit - an otherwise meaningless combination.
*/
-#define MANDATORY_LOCK(inode) \
- (IS_MANDLOCK(inode) && ((inode)->i_mode & (S_ISGID | S_IXGRP)) == S_ISGID)
+#define __MANDATORY_LOCK(ino) (((ino)->i_mode & (S_ISGID | S_IXGRP)) == S_ISGID)
+#define MANDATORY_LOCK(inode) (IS_MANDLOCK(inode) && __MANDATORY_LOCK(inode))
static inline int locks_verify_locked(struct inode *inode)
{
diff --git a/fs/locks.c b/fs/locks.c
index 0db1a14..f90fe6d 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1112,7 +1112,7 @@ int locks_mandatory_area(int read_write,
* If we've been sleeping someone might have
* changed the permissions behind our back.
*/
- if ((inode->i_mode & (S_ISGID | S_IXGRP)) == S_ISGID)
+ if (__MANDATORY_LOCK(inode))
continue;
}
@@ -1751,9 +1751,7 @@ int fcntl_setlk(unsigned int fd, struct
/* Don't allow mandatory locks on files that may be memory mapped
* and shared.
*/
- if (IS_MANDLOCK(inode) &&
- (inode->i_mode & (S_ISGID | S_IXGRP)) == S_ISGID &&
- mapping_writably_mapped(filp->f_mapping)) {
+ if (MANDATORY_LOCK(inode) && mapping_writably_mapped(filp->f_mapping)) {
error = -EAGAIN;
goto out;
}
@@ -1877,9 +1875,7 @@ int fcntl_setlk64(unsigned int fd, struc
/* Don't allow mandatory locks on files that may be memory mapped
* and shared.
*/
- if (IS_MANDLOCK(inode) &&
- (inode->i_mode & (S_ISGID | S_IXGRP)) == S_ISGID &&
- mapping_writably_mapped(filp->f_mapping)) {
+ if (MANDATORY_LOCK(inode) && mapping_writably_mapped(filp->f_mapping)) {
error = -EAGAIN;
goto out;
}
@@ -2073,9 +2069,7 @@ static void lock_get_status(char* out, s
out += sprintf(out, "%6s %s ",
(fl->fl_flags & FL_ACCESS) ? "ACCESS" : "POSIX ",
(inode == NULL) ? "*NOINODE*" :
- (IS_MANDLOCK(inode) &&
- (inode->i_mode & (S_IXGRP | S_ISGID)) == S_ISGID) ?
- "MANDATORY" : "ADVISORY ");
+ MANDATORY_LOCK(inode) ? "MANDATORY" : "ADVISORY ");
} else if (IS_FLOCK(fl)) {
if (fl->fl_type & LOCK_MAND) {
out += sprintf(out, "FLOCK MSNFS ");
next reply other threads:[~2007-09-12 11:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-12 11:17 Pavel Emelyanov [this message]
2007-09-14 23:42 ` [PATCH 1/5] Use existing macros for distinguishing mandatory locks Andrew Morton
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=46E7CAE6.8040803@openvz.org \
--to=xemul@openvz.org \
--cc=akpm@osdl.org \
--cc=devel@openvz.org \
--cc=linux-kernel@vger.kernel.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