Hi The root cause for getting the "Badness in local_bh_enable" messages is that some HW accelerators are calling the crypto_done in interrupt context which call the callback (if CBIMM is set) and that cause that we run the net task code in irq mode which is not recommended.
After some performance measurements, I found that using a waiting q for the ocf callbacks is a killer. Instead of using working q, I used a tasklet (since a tasklet priority is higher then a working q) only then I received nice performance. Attached two patches: ipsec_ocf.patch - for using Tasklet in ipsec ocf callback. Crypto.patch - to add option to call callback through a tasklet and not through a waiting Q (although gives good performance for IPsec) Regards Ronen Shitrit -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ronen Shitrit Sent: Sunday, December 04, 2005 6:23 PM To: David McCullough; Kim Phillips Cc: linux-crypto@vger.kernel.org Subject: RE: OCF/KLIPS: Badness in local_bh_enable Hi I had the same problem, I set USE_CBIMM to one and USETASKQ to 1, since I don't want 2 task to be created for each completion -> and it works :) Just one little thing: In ipsec_ocf.c need to fix typo: shedule_work to schedule_work. Regards Ronen Shitrit -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David McCullough Sent: Tuesday, November 22, 2005 3:45 AM To: Kim Phillips Cc: linux-crypto@vger.kernel.org Subject: Re: OCF/KLIPS: Badness in local_bh_enable Jivin Kim Phillips lays it down ... > Hello all, > > I'm trying out the latest OCF patch for openswan, and it's generating 'Badness in local_bh_enable' messages when I ping across the tunnel (session details below). It seems irq's are disabled when they shouldn't be? > > This is a vanilla 2.6.11+ocf-linux-20051110 kernel, with openswan 2.4.3, using the cryptosoft algorithm interface, running on powerpc. Openswan KLIPS alone (without the OCF patch) does not produce this warning. The patch seems to properly match existing spin_lock_* usage. Is the patch adding a new lock that overlays the domain of an existing lock? > Ok, I only tested this with crypto HW on 2.6, and it was working fine, I will try out the cryptosoft driver when I get a chance, it may be the cause/trigger of the problem. If you set USE_TASKQ to 1 in ipsec_ocf.c does the problem go away ? We cryptosoft it is possible that we call back into ourselves. You could also try setting USE_CBIMM to 0 in the same file, Cheers, Davidm
ipsec_ocf.patch
Description: ipsec_ocf.patch
crypto.patch
Description: crypto.patch
