FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Cluster Development

 
 
LinkBack Thread Tools
 
Old 11-09-2009, 08:32 PM
"H. Peter Anvin"
 
Default misc: use a proper range for minor number dynamic allocation

On 11/09/2009 01:28 PM, Andrew Morton wrote:
>
>> The proposed solution uses the not yet reserved range from 64 to 127. If
>> more devices are needed, we may push 64 to 16. Moreover, if we don't
>> need to give priority to the higher numbers anymore, we can start using
>> the bitmap/bitops functions.
>
> So... misc minors 64 to 127 are presently unused?
>

Perhaps we should just start at 256 and go upward, or even 1048575 and
go downward.

-hpa
 
Old 11-09-2009, 10:03 PM
David Teigland
 
Default misc: use a proper range for minor number dynamic allocation

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 <cascardo@holoscopio.com> 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
 
Old 11-10-2009, 10:10 AM
Steven Whitehouse
 
Default misc: use a proper range for minor number dynamic allocation

Hi,

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 <cascardo@holoscopio.com> 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.

Steve.
 
Old 11-10-2009, 10:16 AM
Alan Cox
 
Default misc: use a proper range for minor number dynamic allocation

> 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

Three is not a problem but the original report is for a lot more - so
something funny is going on and that wants debugging first before
anything gets changed or name/number spaces allocated.

So LANANA firstly wants to know *why* the report is occuring and if the
whole issue is arising due to a bug in something not to a real need.

Alan
(with a LANANA hat on)
 

Thread Tools




All times are GMT. The time now is 03:30 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org