Discussion:
Offtopic question.
(too old to reply)
Stef Bon
2013-01-02 21:59:11 UTC
Permalink
Hi,

sorry for the offtopic question here, but I do not know a better place for
it.

I'm building a lockmonitor. I thought that would be just as easy as with
the /proc/self/mountinfo "file".

But that is not the case. It's not pollable, like the mountinfo fle is.
I've looked into the code of the kernel, (fs/locks.c versus
fs/proc_namespace.c) and there it's abvious. The file_operations with the
locks file misses the .poll operation.

Now first howto implement this? Someone a hint?

The mountinfo poll function is related to changes in namespace, but for the
locks that is different I guess. That "changes" when a lock has been set or
released.

And by the way, isn't this locks file not namespace specific?

Stef
Dave Reisner
2013-01-02 22:24:37 UTC
Permalink
Post by Stef Bon
Hi,
sorry for the offtopic question here, but I do not know a better place
for it.
Post by Stef Bon
I'm building a lockmonitor. I thought that would be just as easy as with
the /proc/self/mountinfo "file".
Post by Stef Bon
But that is not the case. It's not pollable, like the mountinfo fle is.
I've looked into the code of the kernel, (fs/locks.c versus
fs/proc_namespace.c) and there it's abvious. The file_operations with the
locks file misses the .poll operation.

Hmmm, regardless, the file is pollable. findmnt polls it (systemd as well?)
-- you need to watch for POLLERR events.
Post by Stef Bon
Now first howto implement this? Someone a hint?
The mountinfo poll function is related to changes in namespace, but for
the locks that is different I guess. That "changes" when a lock has been
set or released.
Post by Stef Bon
And by the way, isn't this locks file not namespace specific?
Stef
_______________________________________________
systemd-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Stef Bon
2013-01-02 22:40:54 UTC
Permalink
You are sure?? I mean the locks file, not the mounts file.
I think you haven't understood my post very good.

Stef
Dave Reisner
2013-01-02 22:52:08 UTC
Permalink
Post by Stef Bon
You are sure?? I mean the locks file, not the mounts file.
I think you haven't understood my post very good.
Not a lack of understanding, just misread it. My bad.
Stef Bon
2013-01-02 22:56:55 UTC
Permalink
No problem. Just a misunderstading or how you want to call it.

Stef
Post by Dave Reisner
Post by Stef Bon
You are sure?? I mean the locks file, not the mounts file.
I think you haven't understood my post very good.
Not a lack of understanding, just misread it. My bad.
Lennart Poettering
2013-01-03 17:38:53 UTC
Permalink
Post by Stef Bon
Hi,
sorry for the offtopic question here, but I do not know a better place for
it.
I'm building a lockmonitor. I thought that would be just as easy as with
the /proc/self/mountinfo "file".
The poll-ability of /proc/self/mountinfo is a feature that has been
added specifically for that one file. Only very few other files in /proc
can do this (only swaps and the host/domainname files afaik). If you
want this for for other files in /proc you'd first have to patch the
kernel.

That said, file locking on Linux/Unix is unusably broken anyway, why
would you want to monitor that?

Lennart
--
Lennart Poettering - Red Hat, Inc.
Kay Sievers
2013-01-03 18:48:34 UTC
Permalink
On Thu, Jan 3, 2013 at 6:38 PM, Lennart Poettering
Post by Lennart Poettering
Post by Stef Bon
sorry for the offtopic question here, but I do not know a better place for
it.
I'm building a lockmonitor. I thought that would be just as easy as with
the /proc/self/mountinfo "file".
The poll-ability of /proc/self/mountinfo is a feature that has been
added specifically for that one file. Only very few other files in /proc
can do this (only swaps and the host/domainname files afaik). If you
want this for for other files in /proc you'd first have to patch the
kernel.
FWIW, adding poll() support would look like something like this:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=66d7dd518ae413a383ab2c6c263cc30617329842

Kay
Stef Bon
2013-01-03 22:34:40 UTC
Permalink
Post by Kay Sievers
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=66d7dd518ae413a383ab2c6c263cc30617329842
Kay
Thanks a lot. I will try to write a patch with it, although the way linux
handles locking is troublesome.

Stef
Stef Bon
2013-01-03 19:06:46 UTC
Permalink
Well, I'm working on notifyfs, a fuse fs which is a cache for gui clients
and a filesystem event notifier. It uses inotify on linux to notify clients
about changes. I want to be complete and add information about locks as
well (new, changed and removed).
On the localhost this requires monitoring the locks file.

But what do you mean by it's broken. I know it's not mandatory, so clients
can ignore it. But is it totally useless??

I'm planning to add lockinfo also for network filesystems like cifs and
nfs, by monitoring the remote host.

Stef
Lennart Poettering
2013-01-03 19:21:51 UTC
Permalink
Post by Stef Bon
Well, I'm working on notifyfs, a fuse fs which is a cache for gui clients
and a filesystem event notifier. It uses inotify on linux to notify clients
about changes. I want to be complete and add information about locks as
well (new, changed and removed).
On the localhost this requires monitoring the locks file.
But what do you mean by it's broken. I know it's not mandatory, so clients
can ignore it. But is it totally useless??
It's about the semantics of the various APIs...

http://0pointer.de/blog/projects/locking.html
http://0pointer.de/blog/projects/locking2.html

Lennart
--
Lennart Poettering - Red Hat, Inc.
Stef Bon
2013-01-03 22:21:07 UTC
Permalink
Yes, thanks a lot. I've read it, understood, maybe this whole locking thing
should be replaced with a better approach. First you mention in the first
blog entry:

"Mandatory locking is available too. It's based on the POSIX locking API
but not portable in itself. It's dangerous business and should generally be
avoided in cleanly written software.
"

Now, what do you mean? I think that mandatory locking is actually better. A
lock by definition is a way to prevent other processes/threads to use a
specific range in a file. What's the use of it when it's not mandatory?
I've read the paper:

http://kernel.org/doc/Documentation/filesystems/mandatory-locking.txt

which is clear to me.


Stef
Lennart Poettering
2013-01-03 22:52:27 UTC
Permalink
Post by Stef Bon
Yes, thanks a lot. I've read it, understood, maybe this whole locking thing
should be replaced with a better approach. First you mention in the first
"Mandatory locking is available too. It's based on the POSIX locking API
but not portable in itself. It's dangerous business and should generally be
avoided in cleanly written software.
"
Now, what do you mean? I think that mandatory locking is actually better. A
lock by definition is a way to prevent other processes/threads to use a
specific range in a file. What's the use of it when it's not mandatory?
http://kernel.org/doc/Documentation/filesystems/mandatory-locking.txt
Well, on Linux file access is generally considered "fast", i.e. it's
always synchronous and difficult to distuingish from access to allocated
memory backed by swap... Mandatory locking also gets really weird when
mmap() is used. Then, you open up an entirely new can of worms when it
comes to security: i.e. when somebody can take a mandatory lock on a
file he can block everybody else, and they can't do anything against
this, and end up hanging just because they tried to read a
file. Advisory locking at least has the benefit that everybody knows
that it might block, and that they are actually specifically are calling
it to block.

Also see fcntl(2) man page in this regard, the section about Mandatory
Locking and the one about Bugs.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Stef Bon
2013-01-04 09:16:54 UTC
Permalink
Hi,

I've read about the possible bugs.
About the combination between mmap and mandatory locks:
of course the mapping of memory is causing troubles when a mandatory lock
is set. The mapped region should or forward the lock to the new memory
location (where remapped) or the mmap should be denied, unless the locking
allows it (when the mandatory lock is read, allow read access, if a write
lock, deny all others, also mmap). The first is causing too much overhead,
so the second is in my opinion the best option.

Second, when a write is allowed, and a read lock is set (which is possible
according to

http://kernel.org/doc/Documentation/filesystems/mandatory-locking.txt

then the implementation is not right.

Like other operations which require exclusive access to a region of a file,
like writes do, denying other writes to the same region at the same moment,
I guess this locking should also behave like that. If this isn't the case
(where theoretically it is possible that writes are done when a read lock
is set) then there is something wrong.

Stef

Continue reading on narkive:
Loading...