bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ufs-utils/dlabel.c (was: Hurd and UFS)


From: Michael Teichgraeber
Subject: ufs-utils/dlabel.c (was: Hurd and UFS)
Date: 07 Dec 2001 01:18:42 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

Roland McGrath <roland@gnu.org> writes:

> [...] Some call somewhere either clobbers the _hurd_fd[fd] data
> structure, or consumes the send right.  With these techniques, you
> should be able to tell which and where.

Thanks for your helpful advice; fd_get_device() in `dlabel.c' -- this
file is used for providing a disklabel determining function for being
used by mkfs.ufs -- is the place, where the behaviour comes from:

,----------------------------------------------------------------------------
|  file_t node = getdport (fd);
|
|  if (node == MACH_PORT_NULL)
|    return errno;
|
|  err = store_create (node, 0, 0, &store);
|  if (! err)
|    {
|      [...]
|      store_free (store);
|    }
|
|  mach_port_deallocate (mach_task_self (), node);
ยด---------------------------------------------------------------------------

If run as non-root user, there's no store created, `err' is EPERM; so
mach_port_deallocate() correctly ends the use of `node' (I don't know
whether I am using the right terms, when speaking of freeing or
deallocating ports etc.).

When run as root, a store is created that has store->source set to
`node'. `err' is zero, so that after some lines of code the store will
be freed. But within the implementation of store_free() there already
is a call to mach_port_deallocate(self, store->source), if
store->source is not MACH_PORT_NULL.

Since store->source == node, the next call to mach_...(self, node)
seems to destroy the send right or make the port invalid.

A line `store->source = MACH_PORT_NULL;' before the store_free() call
does it fix, but maybe that's dirty. As far as I unterstand it, the
store mechanism takes over the control of the source port when
creating a store, so the source port is deallocated when calling
store_free(). If this is wanted, the line above could probably be one
solution.

The Store Library info entry for store_free() only tells about
deallocation of the underlying stores. Maybe the source should not be
deallocated there since there is store_close_source() to do that?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]