* synchronize_net()?
@ 2003-09-13 3:46 Mitchell Blank Jr
2003-09-14 2:09 ` synchronize_net()? David S. Miller
0 siblings, 1 reply; 2+ messages in thread
From: Mitchell Blank Jr @ 2003-09-13 3:46 UTC (permalink / raw)
To: netdev
In 2.6.0-test5, synchronize_net() is simply:
/* Synchronize with packet receive processing. */
void synchronize_net(void)
{
might_sleep();
synchronize_kernel();
}
The "might_sleep()" isn't needed -- synchronize_kernel() calls
wait_for_completion() which also calls it. Is there any reason for
keeping synchronize_net() around as a seperate function? Maybe
it should just be a #define instead.
-Mitch
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: synchronize_net()?
2003-09-13 3:46 synchronize_net()? Mitchell Blank Jr
@ 2003-09-14 2:09 ` David S. Miller
0 siblings, 0 replies; 2+ messages in thread
From: David S. Miller @ 2003-09-14 2:09 UTC (permalink / raw)
To: Mitchell Blank Jr; +Cc: netdev
On Fri, 12 Sep 2003 20:46:11 -0700
Mitchell Blank Jr <mitch@sfgoth.com> wrote:
> /* Synchronize with packet receive processing. */
> void synchronize_net(void)
> {
> might_sleep();
> synchronize_kernel();
> }
>
> The "might_sleep()" isn't needed
As a matter of taste and ease of debugging it could be.
I think it's logical to place the might_sleep() calls as high
up in the call chain as is reasonable. This is especially true
for important oft-used interfaces for a subsystem.
In this way, you don't risk so much having a hard to decode backtrace
that misses the true culprit sleep'able call.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2003-09-14 2:09 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-09-13 3:46 synchronize_net()? Mitchell Blank Jr
2003-09-14 2:09 ` synchronize_net()? David S. Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).