Skip to contentSkip to conversation

Question about the export of symbol lockdep_init_map

PATCH Larry Finger 2 participants 2 messages Jun 24, 2012 – Jun 25, 2012

lore
Share & tools
lore
#0 lore raw

Ingo,

when you added the locking correctness validator code in commit fbb9ce95, you exported lockdep_init_map() with EXPORT_SYMBOL_GPL. This choice is causing a problem with the latest version of Broadcom's hybrid wl driver. Although I do not agree with their policies regarding drivers with binary blobs, there are some devices such as the BCM43228 (14e4:4359) for which no open-source driver is yet available. As a result, owners of such devices are forced to use solutions such as ndiswrapper, which is worse than using wl.

would you accept the following patch?

kernel/lockdep.c +1 -1
Index: wireless-testing/kernel/lockdep.c
===================================================================
@@ -2994,7 +2994,7 @@ void lockdep_init_map(struct lockdep_map
        if (subclass)
                register_lock_class(lock, subclass, 1);
 }
-EXPORT_SYMBOL_GPL(lockdep_init_map);
+EXPORT_SYMBOL(lockdep_init_map);
 
 struct lock_class_key __lockdep_no_validate__;
 

Thanks,

Larry

#1 lore raw
Quoted 17 lines · Larry Finger

Ingo,

when you added the locking correctness validator code in commit fbb9ce95, you exported lockdep_init_map() with EXPORT_SYMBOL_GPL. This choice is causing a problem with the latest version of Broadcom's hybrid wl driver. Although I do not agree with their policies regarding drivers with binary blobs, there are some devices such as the BCM43228 (14e4:4359) for which no open-source driver is yet available. As a result, owners of such devices are forced to use solutions such as ndiswrapper, which is worse than using wl.

would you accept the following patch?

Index: wireless-testing/kernel/lockdep.c
===================================================================

kernel/lockdep.c void lockdep_init_map(struct lockdep_map · line 3000

Quoted 8 lines
kernel/lockdep.c +1 -1
@@ -2994,7 +2994,7 @@ void lockdep_init_map(struct lockdep_map
         if (subclass)
                 register_lock_class(lock, subclass, 1);
  }
-EXPORT_SYMBOL_GPL(lockdep_init_map);
+EXPORT_SYMBOL(lockdep_init_map);
 
  struct lock_class_key __lockdep_no_validate__;
 

I can't speak for Ingo, but I would object to it. Owners of such devices can send them back to wherever they got them from and demand a refund.

Loading binary blobs pretty much wrecks your kernel validation anyway, who knows what they do.