Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 17 Mar 2003 16:08:21 +0100 (CET)
From:      Harti Brandt <brandt@fokus.fraunhofer.de>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        smp@FreeBSD.ORG, jeff@FreeBSD.ORG
Subject:   Re: malloc.9 locking section
Message-ID:  <20030317152235.M52165@beagle.fokus.fraunhofer.de>
In-Reply-To: <20030315230514.A9013@gamplex.bde.org>
References:  <20030315123530.X45650@beagle.fokus.fraunhofer.de> <20030315230514.A9013@gamplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 15 Mar 2003, Bruce Evans wrote:

BE>On Sat, 15 Mar 2003, Harti Brandt wrote:
BE>
BE>These functions (like most (should be all) functions that aren't in
BE><machine/atomic.h> or <machine/cpufunc.h>) may NOT be called from fast
BE>interrupt handlers.  You may be confused by the bogus and broken check
BE>of td_intr_nesting_level in malloc().  This is supposed to check that
BE>normal interrupt handlers don't call malloc() with M_WAITOK, but has
BE>rotted to only checking that fast interrupt handlers don't do this.
BE>But fast interrupt handlers shouldn't even think of calling malloc().

Ok.

BE>> +When called from threaded interrupts
BE>> +.Ar flag
BE>> +should contain
BE>
BE>s/should/must/

Ok.

BE>> +.Pp
BE>> +.Fn malloc ,
BE>> +.Fn realloc
BE>> +and
BE>> +.Fn reallocf
BE>> +must not be called with
BE>> +.Dv M_WAIT
BE>> +while a mutex other than Giant is held.
BE>
BE>I think you mean M_WAITOK (M_WAIT is only for mbufs).  It's confusing to
BE>say "flag must contain M_NOWAIT" for ithreads and "must not be called
BE>with M_WAITOK" while a mutex other than Giant is held.  The requirements
BE>are the same, and the conditions are almost the same too -- ithreads
BE>might even be implemented using a mutex other than Giant to prevent
BE>them being reentred, though in practice they use a different type of
BE>locking.

Why are these requirements the same? I may have an MPSAFE driver. In this
case I don't have Giant in the interrupt routine. On the other hand there
are supposed to be places in the kernel, which are not interrupts and
where you don't have Giant, but may have another mutex.

I would rather have a couple of 'don't do that' rules in this section of
the man page, so someone without intimate knowledge of how things work
behind the scene will understand it.

As I see it there are six situations:

1. fast interrupts
2. interrupt threads
3. no mutexes
4. Giant
5. Giant + N other mutexes (N > 0)
6. N mutexes (N > 0)

malloc and Co. can be called as:

1. never
2. M_NOWAIT
3. M_NOWAIT || M_WAIT
4. M_NOWAIT || M_WAIT
5. M_NOWAIT
6. M_NOWAIT

Is this correct?

BE>> +Giant may or may not be held when
BE>> +.Fn malloc ,
BE>> +.Fn realloc ,
BE>> +.Fn reallocf
BE>> +or
BE>> +.Fn free
BE>> +are called.
BE>
BE>This is redundant.

Yes, except for free() that wasn't mentioned earlier.

BE>(*)  The man page doesn't seem to say that exactly one of {M_NOWAIT,
BE>M_WAITOK}, must be set, perhaps because it has rotted and still
BE>essentially says that M_WAITOK is 0.  Changes like the above should
BE>be merged into the rotted bits to fix them and avoid redundancy.  Here
BE>are some of the rotted bits:

I added this.

BE>
BE>% Note that
BE>% .Dv M_NOWAIT
BE>% is defined to be 0, meaning that blocking operation is the default.
BE>
BE>Nope.  Clearly no one reads man section 9 manpages.

I read them, but I'm disappointed about their quality. Especially mbuf(9)
is bad. I decided just to start with the easier one :-)
I have removed the above sentence.

BE>% Also note that
BE>% .Dv M_NOWAIT
BE>% is required when running in an interrupt context.
BE>
BE>Still correct.
BE>
BE>% .Pp
BE>% Programmers should be careful not to confuse
BE>% .Dv M_NOWAIT ,
BE>% the
BE>% .Fn malloc
BE>% flag, with
BE>% .Dv M_DONTWAIT ,
BE>% an
BE>% .Xr mbuf 9
BE>% allocation flag, which is not a valid argument to
BE>% .Fn malloc .
BE>% .It Dv M_WAITOK
BE>% Indicates that it is Ok to wait for resources.  It is unconveniently
BE>% defined as 0 so care should be taken never to compare against this value
BE>% directly or try to AND it as a flag.  The default operation is to block
BE>% until the memory allocation succeeds.
BE>
BE>Mostly rotted.

Mostly removed.

Attached is a new diff (to the original page).

Do you know, whether the first paragraph of 'IMPLEMENTATION NOTES' still
holds? Jeff?

I suppose also, that the disagnostics are not very up to date. What
purpose do they server? Perhaps we should simply believe them?

harti


Index: malloc.9
===================================================================
RCS file: /home/ncvs/src/share/man/man9/malloc.9,v
retrieving revision 1.30
diff -u -r1.30 malloc.9
--- malloc.9	24 Feb 2003 05:53:27 -0000	1.30
+++ malloc.9	17 Mar 2003 15:06:14 -0000
@@ -147,44 +147,22 @@
 to return
 .Dv NULL
 if the request cannot be immediately fulfilled due to resource shortage.
-Otherwise, the current process may be put to sleep to wait for
-resources to be released by other processes.
-If this flag is set,
-.Fn malloc
-will return
-.Dv NULL
-rather than block.
 Note that
 .Dv M_NOWAIT
-is defined to be 0, meaning that blocking operation is the default.
-Also note that
-.Dv M_NOWAIT
 is required when running in an interrupt context.
-.Pp
-Programmers should be careful not to confuse
-.Dv M_NOWAIT ,
-the
-.Fn malloc
-flag, with
-.Dv M_DONTWAIT ,
-an
-.Xr mbuf 9
-allocation flag, which is not a valid argument to
-.Fn malloc .
 .It Dv M_WAITOK
-Indicates that it is Ok to wait for resources.  It is unconveniently
-defined as 0 so care should be taken never to compare against this value
-directly or try to AND it as a flag.  The default operation is to block
-until the memory allocation succeeds.
+Indicates that it is ok to wait for resources.
+If the request cannot be immediately fulfilled the current process is put
+to sleep to wait for resources to be released by other processes.
 The
 .Fn malloc ,
 .Fn realloc ,
 and
 .Fn reallocf
-functions can only return
+functions cannot return
 .Dv NULL
 if
-.Dv M_NOWAIT
+.Dv M_WAITOK
 is specified.
 .It Dv M_USE_RESERVE
 Indicates that the system can dig into its reserve in order to obtain the
@@ -194,6 +172,12 @@
 programming.
 .El
 .Pp
+Exactly one of either
+.Dv M_WAITOK
+or
+.Dv M_NOWAIT
+must be specified.
+.Pp
 The
 .Fa type
 argument is used to perform statistics on memory usage, and for
@@ -244,11 +228,37 @@
 While it should not be relied upon, this information may be useful for
 optimizing the efficiency of memory use.
 .Pp
-Malloc flags documented above should
-.Em NOT
-be used with
+Programmers should be careful not to confuse the malloc flags
+.Dv M_NOWAIT
+and
+.Dv M_WAITOK
+with the
 .Xr mbuf 9
-routines as it will cause undesired results.
+flags
+.Dv M_DONTWAIT
+and
+.Dv M_TRYWAIT .
+.Sh LOCKING CONSIDERATIONS
+.Fn malloc ,
+.Fn realloc
+and
+.Fn reallocf
+may not be called from fast interrupts handlers.
+When called from threaded interrupts
+.Ar flag
+must contain
+.Dv M_NOWAIT .
+.Pp
+.Fn malloc ,
+.Fn realloc
+and
+.Fn reallocf
+must not be called with
+.Dv M_WAITOK
+while a mutex other than Giant is held.
+Giant may or may not be held when
+.Fn free
+is called.
 .Pp
 Any calls to
 .Fn malloc

-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
brandt@fokus.fraunhofer.de, harti@freebsd.org

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030317152235.M52165>