From: Pavel Emelyanov <xemul@openvz.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Paul Menage <menage@google.com>,
Sukadev Bhattiprolu <sukadev@us.ibm.com>,
Serge Hallyn <serue@us.ibm.com>
Subject: [PATCH 3/9] Add a mode on the struct probe
Date: Wed, 05 Mar 2008 20:32:44 +0300 [thread overview]
Message-ID: <47CED93C.5030107@openvz.org> (raw)
In-Reply-To: <47CED717.60406@openvz.org>
The idea of the set is to make the dev_t to struct kobj map
be per-cgroup, and provide a permissions for this mapping.
This mode mask will operate with FMODE_xxx modes.
To achieve this, I add the mode_t mode on the struct probe,
which sets this mapping, and move the locked part of the
kobj_map() into a separate function, which also accepts the
mode to be set on the probe.
By default all the modes are provided for a map.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
drivers/base/map.c | 31 ++++++++++++++++++++++++++-----
1 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/drivers/base/map.c b/drivers/base/map.c
index 7de565f..c7e28a1 100644
--- a/drivers/base/map.c
+++ b/drivers/base/map.c
@@ -15,6 +15,7 @@
#include <linux/kdev_t.h>
#include <linux/kobject.h>
#include <linux/kobj_map.h>
+#include <linux/fs.h>
#define KOBJ_MAP_PROBES 255
@@ -22,6 +23,7 @@ struct kobj_map {
struct probe {
struct probe *next;
dev_t dev;
+ mode_t mode;
unsigned long range;
struct module *owner;
kobj_probe_t *get;
@@ -31,9 +33,9 @@ struct kobj_map {
struct mutex *lock;
};
-int kobj_map(struct kobj_map *domain, dev_t dev, unsigned long range,
- struct module *module, kobj_probe_t *probe,
- int (*lock)(dev_t, void *), void *data)
+static int __kobj_map(struct kobj_map *domain, dev_t dev, mode_t mode,
+ unsigned long range, struct module *module,
+ kobj_probe_t *probe, int (*lock)(dev_t, void *), void *data)
{
unsigned n = MAJOR(dev + range - 1) - MAJOR(dev) + 1;
unsigned index = MAJOR(dev);
@@ -55,8 +57,15 @@ int kobj_map(struct kobj_map *domain, dev_t dev, unsigned long range,
p->dev = dev;
p->range = range;
p->data = data;
+ /*
+ * When opening a device we want to (dis)allow only
+ * read or write. But sys_open() can provide more
+ * modes like lseek or pread. So, these FMODE-s are
+ * always 'on'.
+ */
+ p->mode = mode | FMODE_LSEEK | FMODE_PREAD | FMODE_PWRITE;
}
- mutex_lock(domain->lock);
+
for (i = 0, p -= n; i < n; i++, p++, index++) {
struct probe **s = &domain->probes[index % KOBJ_MAP_PROBES];
while (*s && (*s)->range < range)
@@ -64,10 +73,22 @@ int kobj_map(struct kobj_map *domain, dev_t dev, unsigned long range,
p->next = *s;
*s = p;
}
- mutex_unlock(domain->lock);
return 0;
}
+int kobj_map(struct kobj_map *domain, dev_t dev, unsigned long range,
+ struct module *module, kobj_probe_t *probe,
+ int (*lock)(dev_t, void *), void *data)
+{
+ int err;
+
+ mutex_lock(domain->lock);
+ err = __kobj_map(domain, dev, FMODE_READ | FMODE_WRITE, range,
+ module, probe, lock, data);
+ mutex_unlock(domain->lock);
+ return err;
+}
+
void kobj_unmap(struct kobj_map *domain, dev_t dev, unsigned long range)
{
unsigned n = MAJOR(dev + range - 1) - MAJOR(dev) + 1;
--
1.5.3.4
next prev parent reply other threads:[~2008-03-05 17:42 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-05 17:23 [PATCH 0/9] Devices accessibility control group (v4) Pavel Emelyanov
2008-03-05 17:25 ` [PATCH 1/9] Avoid magic constants in drivers/base/map.c Pavel Emelyanov
2008-03-05 17:28 ` [PATCH 2/9] Cleanup the get_gendisk() a bit Pavel Emelyanov
2008-03-05 17:32 ` Pavel Emelyanov [this message]
2008-03-05 17:34 ` [PATCH 4/9] Make kobj_lookup() return the mapping's permissions Pavel Emelyanov
2008-03-05 17:37 ` [PATCH 5/9] Make use of permissions, returned by kobj_lookup Pavel Emelyanov
2008-03-06 1:13 ` Andrew Morton
2008-03-06 8:48 ` Pavel Emelyanov
2008-03-07 9:22 ` Pavel Emelyanov
2008-03-07 9:35 ` Andrew Morton
2008-03-07 9:52 ` Pavel Emelyanov
2008-03-07 15:59 ` Greg KH
2008-03-07 16:38 ` Pavel Emelyanov
2008-03-07 17:01 ` Greg KH
2008-03-07 17:08 ` Al Viro
2008-03-07 17:35 ` Serge E. Hallyn
2008-03-07 17:57 ` Casey Schaufler
2008-03-07 18:30 ` Serge E. Hallyn
2008-03-07 19:46 ` Stephen Smalley
2008-03-07 20:57 ` Casey Schaufler
2008-03-07 21:32 ` Serge E. Hallyn
2008-03-07 18:14 ` Greg KH
2008-03-07 18:50 ` Serge E. Hallyn
2008-03-08 6:04 ` Greg KH
2008-03-08 21:47 ` Serge E. Hallyn
2008-03-09 3:15 ` Greg KH
2008-03-10 20:35 ` Serge E. Hallyn
2008-03-11 9:57 ` Pavel Emelyanov
2008-03-11 17:36 ` Greg KH
2008-03-12 8:26 ` Pavel Emelyanov
2008-03-12 13:09 ` Serge E. Hallyn
2008-03-12 13:18 ` Stephen Smalley
2008-03-12 13:27 ` Stephen Smalley
2008-03-12 14:18 ` Serge E. Hallyn
2008-03-12 14:15 ` Serge E. Hallyn
2008-03-12 16:21 ` Casey Schaufler
2008-03-12 13:36 ` Pavel Emelyanov
2008-03-05 17:40 ` [PATCH 6/9] Extend the drivers/base/map.c functionality Pavel Emelyanov
2008-03-05 17:43 ` [PATCH 7/9] Provide functions to manipulate char device mappings Pavel Emelyanov
2008-03-05 17:46 ` [PATCH 8/9] Provide functions to manipulate block " Pavel Emelyanov
2008-03-05 17:47 ` [PATCH 9/9] Devices accessibility control group itself Pavel Emelyanov
2008-03-06 2:02 ` Greg KH
2008-03-06 1:55 ` [PATCH 0/9] Devices accessibility control group (v4) Greg KH
2008-03-06 3:15 ` Serge E. Hallyn
2008-03-06 4:34 ` Greg KH
2008-03-06 8:36 ` Pavel Emelyanov
2008-03-07 4:58 ` Greg KH
2008-03-07 8:42 ` Pavel Machek
2008-03-07 8:54 ` Pavel Emelyanov
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=47CED93C.5030107@openvz.org \
--to=xemul@openvz.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
--cc=serue@us.ibm.com \
--cc=sukadev@us.ibm.com \
/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