lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 10 Nov 2009 11:10:08 +0000
From:	Steven Whitehouse <>
To:	David Teigland <>
Cc:	Andrew Morton <>,
	Thadeu Lima de Souza Cascardo <>,,,,,
Subject: Re: [Cluster-devel] Re: [PATCH] misc: use a proper range for minor
 number dynamic allocation


On Mon, 2009-11-09 at 17:03 -0600, David Teigland wrote:
> On Mon, Nov 09, 2009 at 01:28:36PM -0800, Andrew Morton wrote:
> > On Fri, 23 Oct 2009 21:28:17 -0200
> > Thadeu Lima de Souza Cascardo <> wrote:
> > 
> > > The current dynamic allocation of minor number for misc devices has some
> > > drawbacks.
> > > 
> > > First of all, the range for dynamic numbers include some statically
> > > allocated numbers. It goes from 63 to 0, and we have numbers in the
> > > range from 1 to 15 already allocated. Although, it gives priority to the
> > > higher and not allocated numbers, we may end up in a situation where we
> > > must reject registering a driver which got a static number because a
> > > driver got its number with dynamic allocation. Considering fs/dlm/user.c
> > > allocates as many misc devices as lockspaces are created, and that we
> > > have more than 50 users around, it's not unreasonable to reach that
> > > situation.
> > 
> > What is this DLM behaviour of which you speak?  It sounds broken.
> One for each userland lockspace, I know of three userland apps using dlm:
> 1. rgmanager which is at the end of its life
> 2. clvmd which is switching to a different lock manager
> 3. ocfs2 tools, where the userland portion is transient; it only exists
>    while the tool executes.
> That said, it shouldn't be a problem to switch to a single device in the
> next version of the interface.
> Dave
As well as the per-userland lockspace misc devices there are also the
misc devices of which there are only one instance shared between all
lock spaces:

dlm_lock - Used for userland communication with posix locks
dlm-monitor - Used to only to check that dlm_controld is running (so far
as I can tell)
dlm-control - Used to create/remove userland dlm lockspaces

I also had a look at other methods used by the dlm to communicate with
userspace, and this is what I've come up with so far:

configfs - Used to set up lockspaces
debugfs - Used to get lock state information for debugging
netlink - Used only to notify lock timeouts to dlm_controld
sysfs - Used to implement a wait for a userland event (wait for write to
a sysfs file)
uevents - Used to trigger dlm_controld into performing an action which
          results in the write to sysfs mentioned above. This is
          netlink again, but with a layer over the top of it.

If a change to the misc devices is planned, I'm wondering if it would be
possible to merge some of the other functions into a single interface to
simplify things a bit. In particular the netlink interface looks dubious
to me since I think it should be doing a broadcast rather than the
rather strange (and possibly a security issue with any process able to
send messages to it and set their own pid so far as I can see). I have
to say that I didn't test that, but there is no obvious check for privs
that I can see in the dlm netlink code.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists