All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Richard MUSIL <richard.musil@st.com>
Cc: netdev@vger.kernel.org
Subject: Re: [GENETLINK]: Question: global lock (genl_mutex) possible refinement?
Date: Fri, 20 Jul 2007 16:00:31 +0200	[thread overview]
Message-ID: <46A0BFFF.5020000@trash.net> (raw)
In-Reply-To: <46A0BF7F.80001@st.com>

[ Please quote and break your lines appropriately ]

Richard MUSIL wrote:
> Patrick McHardy wrote:
>>
>>The usual way to do this for auto-loading of modules that register
>>things that take a mutex that is already held during netlink queue
>>processing, like qdiscs, classifiers, .. is:
>>
>>- look for <qdisc/classifier/...>, if not found:
>>- drop mutex (using the __ unlock variant to avoid reentering queue
>>processing)
>>- perform module loading (which takes the mutex and registers itself)
>>- grab mutex again
>>- look for <qdisc/classifier/...> again
>>- if not found return -ENOENT
>>- if found drop reference, return -EAGAIN
>>
>>The caller is changed to handle -EAGAIN by replaying the entire
>>request. Your problem sounds very similar, look at net/sched/sch_api.c
>>for an example.
> 
> 
> The aforementioned mutex is local to genetlink module, so I cannot temporarily drop it, call the stuff and grab it again (which was mine original thought too).

Export the lock/unlock/.. functions. You'll also need a new version
similar to __rtnl_unlock.

  reply	other threads:[~2007-07-20 14:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-20 12:52 [GENETLINK]: Question: global lock (genl_mutex) possible refinement? Richard MUSIL
2007-07-20 13:21 ` Patrick McHardy
2007-07-20 13:58   ` Richard MUSIL
2007-07-20 14:00     ` Patrick McHardy [this message]
2007-07-20 16:15       ` Richard MUSIL
2007-07-23 10:29         ` Thomas Graf
2007-07-23 16:45           ` Richard MUSIL
2007-07-24  9:35             ` Thomas Graf
2007-07-24 11:09               ` Richard MUSIL
2007-08-10  8:52                 ` Richard MUSIL
2007-08-16 15:58                 ` Thomas Graf
2007-08-17  8:38                   ` Richard MUSIL

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46A0BFFF.5020000@trash.net \
    --to=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    --cc=richard.musil@st.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.