cra_priority usage

2010-03-31 Thread Nicolas, Mario
Hi,
 
I have written a module that implements GCM algorithm for LKCF (by calling 
dedicated hardware).

I would like to understand how the priority mechanism works in order to be sure 
that my module will be selected when I need to. At the moment it seems it is 
always used, which is great but I'd like to understand why :)
 

Here is the crypto_alg structure I am using to register the algorithm: 

static struct crypto_alg aead_authenc_aes_gcm = {
.cra_name   =   rfc4106(gcm(aes)),
.cra_driver_name=   icp_aead,
.cra_priority   =   ICP_AES_ASYNC_PRIORITY, /* 3001*/
.cra_flags  =   
CRYPTO_ALG_TYPE_AEAD|CRYPTO_ALG_GENIV|CRYPTO_ALG_ASYNC,
.cra_blocksize  =   AES_BLOCK_SIZE /*16*/,
.cra_ctxsize=   0,
.cra_type   =   crypto_aead_type,
.cra_module =   THIS_MODULE,
.cra_list   =   
LIST_HEAD_INIT(aead_authenc_aes_gcm.cra_list),
.cra_exit   =   aead_auth_exit,
.cra_u  =   {
.aead = {
.ivsize   = AES_GCM_IV_SIZE, /*8*/
.maxauthsize  = AES_GCM_AUTH_TAG_LEN, /*16*/
.setkey   = setkey_aes_gcm,
.setauthsize  = qat_setauthsize,
.encrypt  = encrypt_aes_gcm,
.decrypt  = decrypt_aes_gcm,
.givencrypt   = geniv_encrypt_aes_gcm,
.givdecrypt   = geniv_decrypt_aes_gcm,
}
}
};
 

The algorithm is registered by calling crypto_register_alg in the module_init 
function.

It seems that my module is always used regardless of the value of the priority 
(I tried to set it to 0 or even to -1).
I have also tried to load the default gcm kernel module before (or after) mine 
but my module is selected in both cases.

I have checked in the kernel code and I did not see any location where 
cra_priority is used.

So my questions are: 
-What is this variable used for?
-If there are multiple implementations of the same algorithm, how is one 
version chosen as opposed to another one?

I guess that the reason is that an asynchronous version always has a higher 
priority than a synchronous one. Is that correct?

Thanks

Mario
--
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.


--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Fixing gave up waiting for init of module libcrc32c.

2010-03-31 Thread Brandon Philips
On 09:36 Tue 30 Mar 2010, Rusty Russell wrote:
 The real fix here is to drop the lock, like Brandon suggested, but
 we need to do it more carefully: when we re-acquire the lock we need
 to re-lookup the symbol in case the module has vanished or changed.
 
 Brandon, I can't see how libcrc32c's module_init calls
 crypto_alloc_shash, but the problem is reproducible with simple
 example modules.  Does it fix your problem?

Did you see my email yesterday explaining how this came about? Does
that answer your question?

http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg04363.html

 module: drop the lock while waiting for module to complete initialization.
 
 This fixes gave up waiting for init of module libcrc32c. which
 happened at boot time due to multiple parallel module loads.

Since the root cause is known a bit more detail can be added:

This fixes gave up waiting for init of module libcrc32c. which is
triggered by parallel modprobes by udev for the same driver. For
example on a machine with two network interfaces:

02:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme II
BCM5709 Gigabit Ethernet [14e4:1639] (rev 01)
02:00.1 Ethernet controller [0200]: Broadcom Corporation NetXtreme II
BCM5709 Gigabit Ethernet [14e4:1639] (rev 01)

udev will fork off two modprobe processes:

/sbin/modprobe pci:v14E4d1639sv1014sd037Cbc02sc00i00
/sbin/modprobe pci:v14E4d1639sv1014sd037Cbc02sc00i00

 The problem was a deadlock: we wait for a module to finish
 initializing, but we keep the module_lock mutex so it can't
 complete.  In particular, this could reasonably happen if libcrc32c
 does a request_module() in its initialization routine.
 
 So we change use_module() to return an errno rather than a bool, and if
 it's -EBUSY we drop the lock and wait in the caller, then reaquire the
 lock.
 
 Reported-by: Brandon Philips bran...@ifup.org
 Signed-off-by: Rusty Russell ru...@rustcorp.com.au

Reviewed the patch and it looks good and I tested it on the machine
and it works. A couple of trivial things inline below if you care.

Signed-off-by: Brandon Philips bran...@ifup.org
Cc: sta...@kernel.org

Thanks Rusty.

Cheers,

Brandon


 - if (b == NULL || already_uses(a, b)) return 1;
 + if (b == NULL || already_uses(a, b)) return 0;

if (b == NULL || already_uses(a, b))
return 0;

   /* If we're interrupted or time out, we fail. */
 - if (wait_event_interruptible_timeout(
 - module_wq, (err = strong_try_module_get(b)) != -EBUSY,
 - 30 * HZ) = 0) {
 - printk(%s: gave up waiting for init of module %s.\n,
 -a-name, b-name);
 - return 0;
 - }
 -
 - /* If strong_try_module_get() returned a different error, we fail. */
 + err = strong_try_module_get(b);
   if (err)
 - return 0;
 + return err;
  
   DEBUGP(Allocating new usage for %s.\n, a-name);
   use = kmalloc(sizeof(*use), GFP_ATOMIC);
   if (!use) {
   printk(%s: out of memory loading\n, a-name);

printk(KERN_ERR %s: out of memory loading\n, a-name);

   module_put(b);
 - return 0;
 + return -ENOMEM;
   }
  
   use-module_which_uses = a;
   list_add(use-list, b-modules_which_use_me);
   no_warn = sysfs_create_link(b-holders_dir, a-mkobj.kobj, a-name);
 - return 1;
 + return 0;
  }
  EXPORT_SYMBOL_GPL(use_module);
  
 @@ -823,7 +815,7 @@ static inline void module_unload_free(st
  
  int use_module(struct module *a, struct module *b)
  {
 - return strong_try_module_get(b) == 0;
 + return strong_try_module_get(b);
  }
  EXPORT_SYMBOL_GPL(use_module);
  
 @@ -994,17 +986,39 @@ static const struct kernel_symbol *resol
   struct module *owner;
   const struct kernel_symbol *sym;
   const unsigned long *crc;
 + DEFINE_WAIT(wait);
 + int err;
 + long timeleft = 30 * HZ;
  
 +again:
   sym = find_symbol(name, owner, crc,
 !(mod-taints  (1  TAINT_PROPRIETARY_MODULE)), 
 true);
 - /* use_module can fail due to OOM,
 -or module initialization or unloading */
 - if (sym) {
 - if (!check_version(sechdrs, versindex, name, mod, crc, owner)
 - || !use_module(mod, owner))
 - sym = NULL;
 + if (!sym)
 + return NULL;
 +
 + if (!check_version(sechdrs, versindex, name, mod, crc, owner))
 + return NULL;
 +
 + prepare_to_wait(module_wq, wait, TASK_INTERRUPTIBLE);
 + err = use_module(mod, owner);
 + if (likely(!err) || err != -EBUSY || signal_pending(current)) {
 + finish_wait(module_wq, wait);
 + return err ? NULL : sym;
   }
 - return sym;
 +
 + /* Module is still loading.  Drop lock and wait. */
 + mutex_unlock(module_mutex);
 + timeleft = schedule_timeout(timeleft);
 + 

Re: Fixing gave up waiting for init of module libcrc32c.

2010-03-31 Thread Rusty Russell
On Thu, 1 Apr 2010 05:33:51 am Brandon Philips wrote:
 On 09:36 Tue 30 Mar 2010, Rusty Russell wrote:
  The real fix here is to drop the lock, like Brandon suggested, but
  we need to do it more carefully: when we re-acquire the lock we need
  to re-lookup the symbol in case the module has vanished or changed.
  
  Brandon, I can't see how libcrc32c's module_init calls
  crypto_alloc_shash, but the problem is reproducible with simple
  example modules.  Does it fix your problem?
 
 Did you see my email yesterday explaining how this came about? Does
 that answer your question?

Yep, thanks.

 Reviewed the patch and it looks good and I tested it on the machine
 and it works. A couple of trivial things inline below if you care.
 
 Signed-off-by: Brandon Philips bran...@ifup.org
 Cc: sta...@kernel.org
 
 Thanks Rusty.

Thanks; already had the two caught by checkpatch; changing the other
printk is not something I like to do in the same patch.

Thanks!
Rusty.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html