lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 16 Mar 2010 09:18:31 -0700
From:	"Luis R. Rodriguez" <mcgrof@...il.com>
To:	Jiri Slaby <jirislaby@...il.com>
Cc:	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"John W. Linville" <linville@...driver.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: regd: sleeping in atomic

2010/3/16 Jiri Slaby <jirislaby@...il.com>:
> Hi,
>
> Stanse found an atomic error in reg_copy_regd:
>
> static int reg_copy_regd(const struct ieee80211_regdomain **dst_regd,
>                         const struct ieee80211_regdomain *src_regd)
> {
>        struct ieee80211_regdomain *regd;
>        int size_of_regd = 0;
>        unsigned int i;
>
>        size_of_regd = sizeof(struct ieee80211_regdomain) +
>          ((src_regd->n_reg_rules + 1) * sizeof(struct ieee80211_reg_rule));
>
>        regd = kzalloc(size_of_regd, GFP_KERNEL);       <---- here
>
> Called from:
>
> static void reg_regdb_search(struct work_struct *work)
> {
>        spin_lock(&reg_regdb_search_lock);
>        while (!list_empty(&reg_regdb_search_list)) {
> ...
>                for (i=0; i<reg_regdb_size; i++) {
>                        curdom = reg_regdb[i];
>
>                        if (!memcmp(request->alpha2, curdom->alpha2, 2)) {
>                                r = reg_copy_regd(&regdom, curdom);
> ...
>        spin_unlock(&reg_regdb_search_lock);
> }
>
> Whole error temporarily available at:
> http://decibel.fi.muni.cz/~xslaby/stanse/error.cgi?db=34-rc&id=578
>
> It is introduced by 3b377ea9d4efc94dc52fe41b4dfdb463635ab298.
>
> Do you plan to extend it somehow or may the spinlock be converted to mutex?

I don't think you can convert this directly to a mutex. The spin_lock
in question (&reg_regdb_search_lock) gets also used by
reg_regdb_query() which in turn gets called by call_crda(). There is
one iteration of call_crda() which happens during module
initialization and from what I gather I don't think the kernel is
happy when you mutex_lock on load routines, please correct my foggy
memory if I am mistaken. So during module load we directly end up
hitting the spin_lock in question, prior to the workqueue using it.

Not sure yet how to address this, any ideas John?

> If not how much may size_of_regd be -- can we safely switch to GFP_ATOMIC?

The count is up to 117 right now. It should be around the number of
countries of the world today, tomorrow even different countries could
have different regulatory domains. This happened with Japan a while
back when they required manufacturers to apply certification rules
depending on the year the product went out.. and this changed many
times in that country. But another reason why this number may also
increase in any given country without regards to silly legislation is
for experimenters who want to enhance the use of the spectrum in
certain areas and would use sha1sums instead of alpha2s for the
regdomains. But we're light years away from that happening.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ